January 2010 - Arch-general - lists.archlinux.org

[arch-general] A suggestion for the devs regarding rebuilds
by Jeff Horelick 11 Mar '10

11 Mar '10

Hey all, I have a suggestion to possibly make rebuilds a bit less painful (or non-existant). I think this is a good idea because it seems like right now, even before there was a new rebuild (ffmpeg/x264) in testing, there's already another on the horizon (linjpeg/libpng, and it's a big one) and when this isn't the case, there's usually a rebuild, when it leaves testing, another rebuild comes in within days and so on. My suggestion would be to do what Debian does and when there's a library release with a new soname, bump the old package and "rename" it (or for new packages just do it from the start) and make the package name include the soname version (like libjpeg7, libpng12, libtorrent-rasterbar4 and so on) and when the soname is bumped upstream, just make libjpeg8 or libpng13 or libtorrent-rasterbar5. This does clutter the repos a bit, but it pretty much negates the need for rebuilds since (i believe) when the new GNOME for example is released, it'll automagically build against libjpeg8 and libpng13 instead of the old ones and eventually, almost no packages will be using the old ones. Once the package list for a large rebuild like the libpng/libjpeg one is down to 3 or 4 items after like 3 months, you can probably rebuild them and pull libjpeg7/libpng12 from the repos. This would likely require 2 changes to pacman to implement: 1. Pacman would have to know that libpng8 is the newer version of libpng7 and prompt users to install that (or do it as a upgrade keeping the old package). 2. Pacman would have to know something was removed from the repo and somehow notify the user and possibly give them a [Y/n] to remove it from their system. (I personally think this is a good idea to implement anyway). -JD

33 94

[arch-general] KDE 4.4 + pnm2ppa + CUPS
by Lars Tennstedt 07 Mar '10

07 Mar '10

Hello and a happy new year, I have noticed print problems on my pc sine the release of KDE 4.0.0. I guessed that I had to wait that the KDE 4 or Qt 4 print backend got better. But at the moment I use KDE 4.3.4 on Arch Linux with pnm2ppa from AUR and CUPS. My box is up-to-date. I can print with Firefox, GIMP, OpenOffice and GNOME applications but I cannot still with KDE 4 or Qt 4 applications. I did not find anything about that issue. Can someone help me? Bye Lars

2 5

[arch-general] Xscreensaver corrupts ext4 / partition
by Javier Vasquez 21 Feb '10

21 Feb '10

Hi all, I have 4 boxes, all with the same partitioning scheme and using ext4 for all of them. This weird thing has only showed up in one of them. Some time back while playing some video and with xscreensaver active, the timeout for xscreensaver expired and then password was required... Bad thing that xscreensaver corrupted / so that it couldn't be unlocked, and under console there was no way to loging, some misplaced inodes or something... Hard reboot was required, and then at first /tmp was so corrupted that it was necessary a phisical fix... After all that, what happens is that whenever launching xscreensaver-demo, if I had a terminal open then doing cat, or any other thing fails, since no libraries are found... If at that moment I go to console, the message I get is ext4 /dev/sda7 (partition for /) is corrupted with some inode misplacement or similar... Then at that time there's nothing else to do but to hard reset... BTW, when loading xscreensaver-demo from terminal, the 1st thing that shows up is: (xscreensaver-demo:2830): libglade-WARNING **: Could not load support for `gnome': libgnome.so: cannot open shared object file: No such file or directory I think that is due exactly for the same thing, that ext4 got corrupted, since by doing cat or any other command shows that libraries are not found or something... Has anyone seen this? Any way to get xscreensaver working back? It was actually working before, and it is working on all other boxes. Weird thing is that without xscreensaver I don't get any problem, so my work around right now is not to use it. I initially got under the impression that the ext4 corruption wa sdue to something else, so I re-installed all packages, but that didn't help (got list of packages, and install them all through pacman -S)... If this is known and there's way to overcome it, other than just not using xscreesaver at all, please let me know... Thanks, -- Javier.

4 8

Re: [arch-general] [arch-dev-public] [signoff] dcron 4.2
by Jim Pryor 11 Feb '10

11 Feb '10

On Mon, Jan 11, 2010 at 11:36:55AM -0500, Eric Bélanger wrote: > On Mon, Jan 11, 2010 at 8:06 AM, Paul Mattal <paul(a)mattal.com> wrote: > > On 01/06/2010 01:09 AM, Paul Mattal wrote: > > I've just placed dcron 4.2 into [testing]. This is a major update to dcron, > > under a new maintainer (who is an Arch user, and very responsive). With this > > release, I am also taking over maintaining dcron in [core]. > > Why did you put etc/rc.d/crond in the backup array? These daemon > scripts are not intended to be modified by the user. If you want them > to be able to pass different options, you should use a > /etc/conf.d/crond config file. Hi Eric, I did that in a proposed PKGBUILD I sent to Paul. It'll be up to him how to package this, but this prompts a more general question I have. Granted that daemon scripts are not supposed to be modified by the ordinary user; the /etc/conf.d mechanism is the usual way to supply arguments to the daemon scripts. However, it's one thing to say "not usually supposed to be user-modified" and slightly different to say "overwrites user mods without notice." I find myself tweaking a few /etc/rc.d scripts now and then. I know there's an existing mechanism to protect such changes: NoUpgrade in /etc/pacman.conf. But I wondered why more PKGBUILDs didn't just add the daemons to the backup array. So the question is: should we think of it as _policy_ that rc.d scripts don't go in backup array, and should instead always be explicitly protected by the user if user wants to mod? No problem if so, it's actually helpful to know there's an explicit policy to always do it the one way or always do it the other way. As to dcron 4.2, I've already gotten some feedback. Thanks. I'll release a new version shortly, but do keep feedback coming. -- Jim Pryor profjim(a)jimpryor.net

13 27

[arch-general] udev and/or device-mapper problem
by Hussam Al-Tayeb 11 Feb '10

11 Feb '10

I updated to udev, cryptsetup and device mapper from testing the installed kernel 2.6.32.6 and rebooted. now /dev/mapper/root and /dev/dm-0 are not there but /etc/mtab mentions /dev/mapper/root /dev/mapper/home and /dev/dm-1 exist The computer boots till the fsck part then stops because there is no /dev/mapper/root to fsck. I'm trying not to touch any libpng/libjpeg stuff in testing but non of those messes up booting anyway. After fsck fails, it dropped me to a shell. I downgraded udev and device-mapper, recreated the kernel image and I can boot now. Any ideas?

5 7

[arch-general] Syncing the mirrors
by Benedikt Müller 09 Feb '10

09 Feb '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We have a bit update today, and we see: The syncing process is not really good. So I suggest to change the procedure mirrorsyncs are done: We should have primary and secondary mirrors. When al.org is updated, the sync process of the primary mirrors should be started via ssh(or something similar). Then the primary mirrors start the sync process on the secondary mirrors via ssh. So the al.org server isn't overloaded and the mirrors are more up to date because of the push way. - -- Gruß, Benedikt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAktlkM4ACgkQEbgIp8utRvBwAwCgiv9qBi/hEP5Xr447gHrauExn f5kAnAs7uzHXPIhz+Q+JnQAkwfJms2/T =6iqt -----END PGP SIGNATURE-----

21 46

[arch-general] Mounting tmpfs on /dev. Why?
by AlannY 05 Feb '10

05 Feb '10

Hi there. I'm newbie in Archlinux and I have another lame question. Recently, I've found that Arch mounts tmpfs on /dev. And, as you may see, this makes big problem to some applications. I see: "none on /dev type tmpfs" in the output of mount program. This mount is not placed in /etc/fstab. So, I think this is done by some of init scripts. I've looked at the /etc/rc.d folder and grep "mount" `find`. But nothing interesting found. I really don't want to mount tmpfs on /dev. How to don't do it? Thanks for patience.

7 7

[arch-general] Video Resolution, Grub2 and Kernel 2.6.32
by Steve Holmes 04 Feb '10

04 Feb '10

When I installed grub2 a short while back, I was using the kernel 2.6.31.6 and I enjoyed a full screen of 1024.768 32K color depth. I followed the steps outlined here <http://wiki.archlinux.org/index.php/GRUB2#Setting_the_framebuffer_resolution> to the letter and all was great. But when the kernel26 package upgraded to 2.6.32.2, This functionality broke. I ended up having to remove the video related stuff from my grub line to get my system to boot. When I say this didn't work anymore, basically my system wouldn't boot and I end up with a blank screen showing. When I experimented by removing the insmod statement and using vga=790 by itself, the best I get is a 30 line display with 80 columns width. Anyone know what changed? It would appear that we may need to update the wiki page with new info for grub2 and video resolution.

11 15

Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
by Joerg.Schilling＠fokus.fraunhofer.de 04 Feb '10

04 Feb '10

Heiko Baums wrote: >I don't know anything about the technical differences between cdrkit >and cdrtools but http://cdrkit.org says: >News >2009/10/11 >Cdrkit 1.1.10 has been released. >So the last stable release was not a year but only three months ago. >This looks like an active development for me. Please have a closer look on _what_ was changed in this "release". This have been mainly single char typo corrections but the > 100 well known bugs that exist as long as the fork exists have never been fixed. On the original software, you see more changes (enhancements and fixes) in a lazy week than the "cdrkit project" did get since May 6th 2007 in total. In the fork, problems are ignored. In the original software, problems are fixed very soon; typically within hours. This is why there are no known problems in the original software. The fork did not publish a single version that was known to be without bugs at the time of publishing. The original cdrtools project did publish more than 70 releases in the same time and more than 60 of them did have not a single bug when they have been published. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js(a)cs.tu-berlin.de (uni) joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

33 105

[arch-general] Vertical Quicklaunch on the Desktop in KDE4 - It's a Winner
by David C. Rankin 03 Feb '10

03 Feb '10

Guys, The far right-hand sliver of the screen is rarely covered on my desktop. Using the quicklaunch widget turns it into a very useful launch area without placing an entire 'toolbar' on the edge by using the 'quicklaunch' widget. Using the quicklaunch, you can put ~20 of your favorite apps in a very convenient location without losing desktop real estate. See: (42k) http://www.3111skyline.com/dl/ss/kde4/vertical-quicklaunch.jpg Initially the quicklaunch widget orients itself in a horizontal configuration. Simply using the resize handle, you can resize it into a vertical configuration. Right after resize, the whole quicklaunch will look like a mess due to a bug that changes the size of the icons to 128px as the widget is resized vertically. Just click on the preferences access button and set the size back to 16 and you are good to go. (while you are there also increase the maximum number of visible apps to ~30 or so) To populate quicklaunch, just right-click the quicklaunch on the icon above where you want your app located and navigate to the .desktop file for the app you want to add and click OK. The .desktop files are usually located at: /usr/share/applications /opt/kde(3)/share/applications/kde (adjust as required) /usr/share/applications/kde4 To rearrange the application order, just drag the icons where you want them in the quicklaunch. Enjoy! (PS. the multiple konqueror and dolphin icons are the user & su versions) -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

2 2