- Arch-dev-public - lists.archlinux.org

[arch-dev-public] [signoff] perl 5.10.1-4 both arches
by Paul Mattal 21 Oct '09

21 Oct '09

Please signoff both arches. Minor change to install scriptlet to avoid error message, closing bug #16436. - P

7 10

[arch-dev-public] The udev rule nightmare
by Thomas Bächler 21 Oct '09

21 Oct '09

So, I wanted to revisit the subject of udev rules. Right now, we have rules in /etc/udev/rules.d and /lib/udev/rules.d - the idea was that "upstream" rules goes to /lib and whatever else goes to /etc. This was interpreted by some of our own dev team that we should put whatever udev and packages ship to /lib and whatever we created ourselves to /etc - which is dumb. Right now we have: - rules from upstream packages in /lib - patched rules from upstream packages in /lib - rules from upstream packages in /etc - Arch rules in /etc It is pure chaos and nobody understands what is where and why. It is a nightmare. Back when we had the discussion, I suggested what I will re-suggest now: - All our packages should have udev rules in /lib only. What Arch officially ships is what we consider "upstream". (To put it in the same terminology that perl uses: core-rules and vendor-rules) - User or site specific rules go to /etc, overriding or complementing the "official" rule set (site-rules) This will lead to a clear distinction and a clear rule instead of the chaos we have until now. It is also the only way that makes sense, everything else will lead to the same chaos again. Please comment.

5 9

[arch-dev-public] [signoff] tzdata 2009o
by Jan de Groot 21 Oct '09

21 Oct '09

Please signoff for both architectures. Changelog: - update to 2009o (svn commit says 2009n btw) - add patch from http://bugs.archlinux.org/task/16732

2 1

[arch-dev-public] binutils-2.20 toolchain rebuild in [testing]
by Allan McRae 21 Oct '09

21 Oct '09

Hi The binutils-2.20 toolchain rebuild is in [testing] for i686. I will do the x86_64 rebuilds in the next day or two. A summary of changes: kernel-headers - bump to latest binutils - bump to latest glibc - grab upstream patchset for proposed future stable release, fix overflow bug (FS#16253), patch to build against latest binutils gcc - bump to latest, use package spitting (gcc-libs, gcc, gcc-fortran, gcc-objc), move static libraries from gcc-libs to gcc, add gcc-ada package, do not run fixincludes during build. I will call for a signoff a few days after getting the x86_64 builds done. Allan

4 8

[arch-dev-public] should be esound an optdepends?
by Andrea Scarpino 21 Oct '09

21 Oct '09

>From FS#16502: With GNOME 2.28 arriving, it's time to make esound an optional package, which is currently not the case. Here is the list of the packages which requires esound. I think for all of them that esound should be an optional dependency (except maybe enlightenment?). * bmp * cinelerra-cv * enlightenment * epplet-base * freeciv * gmerlin * gstreamer0.10-good-plugins * kvirc * kvm * libgnome * qemu * vice * xine-lib * xmms What's our decision about this? -- Andrea `bash` Scarpino Arch Linux Developer

3 3

[arch-dev-public] List of packages that could be rebuilt if you have nothing better to do...
by Allan McRae 20 Oct '09

20 Oct '09

Hi, I have created a list of packages the could use a rebuild but for which there is no hurry. These include packages without the arch in their filename, packages containing a .FILELIST file, packages with man pages in /usr/man or uncompress man and info pages. See http://wiki.archlinux.org/index.php/User:Allan/Unimportant_Rebuild_List Do people think this is useful and should I move it to the DeveloperWiki? Allan

3 4

[arch-dev-public] Strange behaviour of pacman
by Daniel Isenmann 19 Oct '09

19 Oct '09

Hi, I'm having some trouble to understand why pacman left some files on the filesystem, but the package was removed. According to this bug report: http://bugs.archlinux.org/task/16414 pacman left the listed directories and files on the filesystem. I have try to reproduce it and it's true, the files are on the filesystem. My first thought was about the 'emptydirs' option in the PKGBUILD (http://repos.archlinux.org/wsvn/packages/wicd/repos/extra-i686/PKGBUILD) but that wasn't the solution, the files are still there. I can't determine why this happens, any ideas from your side? -Daniel

7 19

[arch-dev-public] Xorg 7.5 hits testing
by Andreas Radke 19 Oct '09

19 Oct '09

I've built the new Xorg 7.5 based on xorg-server 1.7.1rc1 and Mesa 7.6. Some very old drivers have been dropped because they are no more developed and won't build anymore. I hope I have updated all essential parts. Some Xorg fonts related packages still need a bump. Mesa 7.6 is built right now plain upstream. This means Gallium 3d stack for Nouveau and Intel. For Intel we might go back to old way DRI when we can't solve some existing issues. Radeon is built the old DRI way. Let's pray the update goes smooth. So far only Jan has played with Intel drivers. We will probably need some time until all important regressions and bugs have been solved. Good luck. -Andy

7 13

[arch-dev-public] Code swarm of Arch Linux SVN repository
by Daniel Isenmann 19 Oct '09

19 Oct '09

Hi, I have created a code swarm (http://vis.cs.ucdavis.edu/~ogawa/codeswarm/) of our PKGBUILD SVN. You can watch it here: http://vimeo.com/7113066 Sadly I haven't any logs from our old CVS, so the video starts with the big commit from Aaron at April 6th, 2008. Have fun... Cheers, Daniel

3 3

[arch-dev-public] Load_Cycle_Count and storage-fixup
by Roman Kyrylych 18 Oct '09

18 Oct '09

Hi all! I wanted to bring this long time ago when I discovered the problem with my old Seagate Momentus 5400.3, but then forgot since my new WD Scorpio Blue is less affected by this. But recently I noticed a couple of reports about the issue on forums and IRC, so I'm bringing this here. The problem is that on some HDDs (and/or with some BIOSes?) HDD head parking is done too often. This can be seen with Load_Cycle_Count in smartctl output being increased quickly (more than once per minute), and heard as relatively frequent clicks during low IO load. More at http://ata.wiki.kernel.org/index.php/Known_issues#Drives_which_perform_freq… Basically, if Load_Cycle_Count divided by Power_On_Hours is more than 30-60 and your HDD is powered for many hours every day - your HDD may reach the limit in a couple of years. More info specifically about WD Green HDDs: http://kerneltrap.org/mailarchive/linux-kernel/2008/4/10/1396844/thread https://lists.ubuntu.com/archives/kernel-bugs/2008-April/035194.html (you can find wdidle3 with google, it's not accessible from WD site). I want to stress that this is _not_specific to WD Green drives. The problem is easy to fix, but that's if you _know_ about it. I think most of users are not aware of it. Now to the point of this message and why it is on this mailing list. What is the best way to handle this? There is a nice script which automatically tunes HDD options to fix this depending on HDD and/or laptop model. http://git.kernel.org/?p=linux/kernel/git/tj/storage-fixup.git Would it be okay if we package it and put it in core & install CD? Would it be enough to put this information in Official Install Guide? Would it be better to not care that much about this, and only mention it in some wiki page plus link in (Post-)Install Guide? I am really not sure what is the best way here. I'd like to hear your feedback on this. -- Roman Kyrylych (Роман Кирилич)

5 5