devel September 2009

devel@lists.fedoraproject.org

270 participants
251 discussions

Opinions on packaging ATLAS (for the x86 architecture)
by Deji Akingunola 07 Oct '09

07 Oct '09

Hi all, I would like to know your opinion (or any guideline, if it exists) for the best way to package the ATLAS library for the x86 arch ATM. ATLAS (Automatically Tuned Linear Algebra Software) basically provides lapack and blas libraries tuned and optimized for specific cpu instruction sets, and speed-ups derived from it are very significant. The library is mostly used for scientific applications, but I've heard gnome-games also uses it to enhance one of its games. Currently its packaging for Fedora on the x86_32 arch creates 3 variants (sub-packages) based on the SSE instruction sets - atlas-sse(1), atlas-sse2, and atlas-sse3, and just recently we gained the ability to build it for CPUs without SSE. I am trying to decide which variant to provide as the default one that would be picked to satisfy atlas library dependency out of the following 2 possibilities; i). Create a generic x86 'atlas' main package for the P6 architecture, which is a non-SSE and minimum CPU that Fedora can support ATM. atlas-sse, atlas-sse2, and atlas-sse3 would then be sub-packages that users will have to specifically install to benefit from the atlas optimizations. ii). According to smolt statistics, cpus with speeds <= 512 MHz (which is a superset of the non-SSE P6 architecture) is only 0.8% of Fedora install-base, and cpus with speed >2 GHz (which are subset of SSE2 capable cpus) are more than 58%. Therefore to support the majority, the main 'atlas' package will be the sse2 variants, which will provides 'atlas-sse2' and there will be sub-packages for atlas-no_sse, atlas-sse, and atlas-sse3. I personally favour the second option, as I think most people just installing 'atlas' (who might not have seen the package descriptions) will likely get the better optimized variant. Right now the 'atlas-sse2' subpackage provides 'atlas', but yum will select the 'atlas-sse' subpackage to satisfy library dependence for libatlas (shortest name win scenario). Thanks for your contribution. Deji

18 34

crypto consolidation status?
by Ken Dreyer 07 Oct '09

07 Oct '09

I read the wiki page[1] on Fedora's effort to consolidate all the crypto libraries. Quite an ambitious task! FWN [2] reported on the rather large discussion back in '07, but I didn't see any resolution. Is this still a goal for Fedora? The main wiki page hasn't been edited in almost a year (although the scorecard is still being maintained). The reason I bring all of this up is that Server Name Indication has recently been implemented into httpd's mod_ssl, but SNI is not present in mod_nss[3]. If we abandon mod_ssl for mod_nss, we would lose this functionality. - Ken [1] https://fedoraproject.org/wiki/FedoraCryptoConsolidation [2] https://fedoraproject.org/wiki/FWN/Issue107#Crypto_Consolidation [3] https://bugzilla.mozilla.org/show_bug.cgi?id=360421

3 5

another spin of TeX Live 2009 packages
by Jindrich Novy 06 Oct '09

06 Oct '09

Hi, first off, thanks many people who sent me RFE and bugfix proposals. I've tried to fix most of them in the current package set in the testing repository: rpm -i http://jnovy.fedorapeople.org/texlive/texlive-release-2009-0.1.fc11.noarch.… If you use the older TeX Live 2009 packages, please reinstall them completely: yum remove texlive (and to be sure rm -rf /usr/share/texlive, due to ordering it could leave some directories there) yum clean all yum install texlive <or other packages> The reason for it is the following list of improvements: - binary packages do no more have the '.ARCH' postfix, the postfix changed to '-bin' - new font support add new 'fedora-fonts' packages which allows you to use TeX Live 2009 fonts (TrueType and OpenType for now) in Fedora - packages for TeX Live t1utils and psutils are no more built but dependencies to existing utilities in Fedora are added - kpathsea packages should now be correctly obsoleted. The lcdf-typetools dep errors you might see installing texlive-collection-fontutils is caused by the fact that lcdf-typetools in Fedora is linked against kpathsea libraries and TeX Live 2009 increases the soname so lcdf-typetools will work after rebuilt with the new kpathsea - fixed texlive-xetex conflict with older TL2007 packages - added older tetex-latex, etc. provides for compatibility (you are now able to install TL2009 together with R analysis package, etc.) - new packages should automatically clear /var/lib/texmf in %post scriptlets to avoid format incompatibilities I haven't added obsoletes to .ARCH packages to keep spes files readable and because TL2009 packages are not yet imported. The spec format should be final now. Only some font formats can be added or the Fedora font support updated for a bit. I will announce next repo updates here: http://fedoraproject.org/wiki/Talk:Features/TeXLive Thanks, Jindrich -- Jindrich Novy <jnovy(a)redhat.com> http://people.redhat.com/jnovy/

10 27

yum-presto not on by default
by Jonathan Dieter 05 Oct '09

05 Oct '09

I don't think yum-presto should be enabled by default in Fedora 12. There are two bugs that really should be fixed before that can happen: https://bugzilla.redhat.com/show_bug.cgi?id=524720 https://bugzilla.redhat.com/show_bug.cgi?id=524982 The first one has to do with the md5 checksum error mentioned earlier on this list. The second one has to do with the fact that when rebuilding the rpms, we have to recompress the data, and xz compression is over 10x slower than gzip. Jonathan

39 106

PPC/PPC64 disabled in Koji for dist-f13
by Josh Boyer 05 Oct '09

05 Oct '09

Hi All, As of today, ppc and ppc64 are no longer primary architectures in koji starting with the dist-f13 tag. This is in accordance with the FESCo approved demotion of PowerPC starting with Fedora 13 development. The dist-f12 and older tags continue to have them as primary. Happy building. josh

22 48

orphaning argus
by L. Gabriel Somlo 04 Oct '09

04 Oct '09

Not using argus anymore, and no cycles to do right by it. Please feel free to pick it up if there's interest. Thx, --G

3 3

Buyer Beware: A Major Change in NFS is about to happen
by Steve Dickson 03 Oct '09

03 Oct '09

Hello, As part of the https://fedoraproject.org/wiki/Features/NFSv4Default feature I am one commit away from changing the default protocol version NFS will be using (or at least trying to use). What does this means to you? Hopefully nothing! In theory this should be a very seamless transition but with all new technology there will be (and are) some rough spots. Why are make the change? See the NFSv4Default wiki for details, but in a nutshell: * Better performance - V4 is now a stateful protocol. Meaning the server keeps state on all the clients access a particular file or directory. This allows the server to give out delegations (or leases) which in turn allows the client to aggressive cache both data and meta data locally * Firewall Friendly- With v4 only one port is used 2049 for all traffic including mounting and file locking. * Finally it enables us use upcoming minor releases of the the protocol. NFS version 4.1 and pNFS are two example of upcoming minor releases. FYI, V4 was introduced in Fedora Core 2 so it has been around for a while. I personally have been using it for my home directory for a couple years now.. For more of the nitty gritty details see http://www.iaps.com/NFSv4-new-features.html That's the good news... Here is the bad.... Because the mount command will try NFS v4 first, mounts to older Linux servers will start failing like: # mount linux-server:/export /mnt mount.nfs: mounting linux-server:/export failed, reason given by server: No such file or directory This is due to a defect in the Linux server exporting code, which is fixed in F-12, *but* there are a number of workarounds On the server (Which is suggested): * Add the following entry to the /etc/exports file: / *(ro,fsid=0) Note: 'fsid=0' is explained in the exports(5) man pages. On the client, go back to v3 mounts by doing one of the following: * Add -o v3 to command line, similar to: mount linux-server:/export /mnt * Change the default mount version in the new /etc/nfsmount.conf file by uncommenting the Nfsvers=3 setting in the 'NFSMount_Global_Options' section. See nfsmount.conf(5) man page for details. The diff would look like: --- /etc/nfsmount.conf 2009-09-29 16:58:13.000000000 -0400 +++ /tmp/nfsmount.conf 2009-09-29 16:56:04.000000000 -0400 @@ -29,7 +29,7 @@ # options that can be applied on all NFS mount. # # Protocol Version [2,3,4] -#Nfsvers=3 +Nfsvers=3 # Network Transport [Udp,Tcp,Rdma] # Proto=Tcp # steved.

25 78

KDE-SIG weekly report (40/2009)
by Jaroslav Reznik 02 Oct '09

02 Oct '09

This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply to this email or add it to the related meeting page. ---------------------------------------------------------------------------------- = Weekly KDE Summary = Week: 40/2009 Time: 2009-09-29 14:00 UTC Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-09-29 Meeting minutes: http://meetbot.fedoraproject.org/fedora- meeting/2009-09-29/fedora-meeting.2009-09-29-14.08.html Meeting log: http://meetbot.fedoraproject.org/fedora- meeting/2009-09-29/fedora-meeting.2009-09-29-14.08.log.html ---------------------------------------------------------------------------------- = Participants = * BenBoeckel * JaroslavReznik * KevinKofler * LukasTinkl * RexDieter * StevenParrish * ThanNgo * ThomasJanssen * Mary Ellen Foster ---------------------------------------------------------------------------------- = Agenda = o Topics to discuss: * kde-sig steering committee * k3b/koffice reverts, recommended by upstreams * future of Phonon * upstream (sandsmark) recommends building/packaging phonon from qt, and building/packaging backends separately * mandriva developments integrating pulseaudio support (and improving gstreamer backend) [1] = Summary = o kde-sig steering committee * The KDE SIG Steering Committee will be formed by (in alphabetical order): jreznik, Kevin_Kofler, ltinkl, rdieter, SMParrish, svahl, than. * 4 votes will be required to pass decisions where a vote is called for. * rdieter will summarize the exact rules. o k3b/koffice reverts, recommended by upstreams [2] * F12 will revert to (kde3) k3b-1.0.x and koffice-1.6.x for F-12 (passed 4:2). o future of Phonon * Upstream (sandsmark) recommends building/packaging phonon from qt, and building/packaging backends separately. * Mandriva developments integrating pulseaudio support (and improving gstreamer backend). [1] * We will move back to building a standalone phonon SRPM. * The vote for the default backend is split 3:3, needs the 7th vote from svahl. ---------------------------------------------------------------------------------- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-10-06 = Links = [1] http://mail.kde.org/pipermail/phonon-backends/2009-September/000304.html [2] http://rdieter.livejournal.com/15770.html Jaroslav -- Jaroslav Řezník <jreznik(a)redhat.com> Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/

2 2

yum update vs. blender
by Ralf Corsepius 01 Oct '09

01 Oct '09

Hi, today's yum update came along with this: # yum update ... Updating : blender-2.49b 1.fc11.x86_64 16/57 Unknown media type in type 'all/all' Unknown media type in type 'all/allfiles' Unknown media type in type 'uri/mms' Unknown media type in type 'uri/mmst' Unknown media type in type 'uri/mmsu' Unknown media type in type 'uri/pnm' Unknown media type in type 'uri/rtspt' Unknown media type in type 'uri/rtspu' Unknown media type in type 'fonts/package' Unknown media type in type 'interface/x-winamp-skin' ... Cleanup : blender-2.49a-1.fc11.x86_64 48/57 Unknown media type in type 'all/all' Unknown media type in type 'all/allfiles' Unknown media type in type 'uri/mms' Unknown media type in type 'uri/mmst' Unknown media type in type 'uri/mmsu' Unknown media type in type 'uri/pnm' Unknown media type in type 'uri/rtspt' Unknown media type in type 'uri/rtspu' Unknown media type in type 'fonts/package' Unknown media type in type 'interface/x-winamp-skin' What is this? Seems to me, as is something is very broken with blender's scriptlets? Ralf

2 2

status of forked zlibs in rsync and zsync
by Adam Williamson 01 Oct '09

01 Oct '09

Hi, everyone. We - the QA group - have recently been researching the feasibility of using zsync to reduce the size of live image downloads. This has hit a roadblock in the form of the problem where both rsync and zsync use forked zlibs rather than linking against the system copy. It seems there was a flurry of activity surrounding this problem in April through June - see: https://fedorahosted.org/fesco/ticket/134 https://bugzilla.redhat.com/show_bug.cgi?id=490140 https://bugzilla.redhat.com/show_bug.cgi?id=478617 https://bugzilla.redhat.com/show_bug.cgi?id=495310 but everything seems to have gone quiet since then. At present we are still in the contradictory and unsatisfactory position of shipping rsync with an internal forked zlib but refusing to accept zsync as a package because it does exactly the same thing. I just wondered if there's a roadmap for where we go from here, or if the issue is just sitting idle waiting for someone to apply a kick to it :) Can you guys clarify what's happening with this? Thanks! (kparal - Kamil Paral - is the QA team member who's been investigating the usefulness of zsync). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net

21 57

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel September 2009