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

Re: [arch-general] [arch-dev-public] [signoff] initscripts 2010.01-1, udev 150-1, device-mapper/lvm2 2.02.60, cryptsetup 1.1.0
by Gerardo Exequiel Pozzi 25 Jan '10

25 Jan '10

On 01/24/2010 11:42 AM, Thomas Bächler wrote: > Okay, here are the changes: > > initscripts: > - hwclock improvements by Dan > - some minor crypto fix on shutdown > - moved the prekillall hook so it can be used better with splash > Necessary for device-mapper/udev, as dm-device detection on startup has > needs options introduced in 2009.11-1 (still in testing) > My both i686 and x86_64 (running under a custom kernel 2.6.32.[46] without initramfs) installations boot/shutdown fine, also using the hook shutdown_poweroff to enable full kernel log again, and works very nice. My unofficial sign-off for both archs. (initscripts-2010.01-1) -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

1 0

Re: [arch-general] [arch-dev-public] [signoff] udev-150-3
by Gerardo Exequiel Pozzi 25 Jan '10

25 Jan '10

On 01/25/2010 03:35 AM, Tobias Powalowski wrote: > Am Sonntag 24 Januar 2010 schrieb Tobias Powalowski: > >> Am Sonntag 24 Januar 2010 schrieb Tobias Powalowski: >> >>> Hi guys, >>> udev 150 >>> ======== >>> Bugfixes. >>> >>> Kernels with SYSFS_DEPRECATED=y are not supported since a while. Many >>> users depend on the current sysfs layout and the information not >>> available in the deprecated layout. All remaining support for the >>> deprecated sysfs layout is removed now. >>> > >> fixed consolekit file location. >> >> > cleaned up arch rules file #17993 > > greetings > tpowa > All looks OK with udev-150-3 (and running with my custom kernel 2.6.32.6), devices acl are now working as expected with consolekit. My unofficial sign-off for i686 and x86_64. -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

1 0

[arch-general] problem with video driver ?
by fons＠kokkinizita.net 25 Jan '10

25 Jan '10

Hello all, Today I installed Arch on my desktop which previously had Fedora. All works well except ssh -X zita2 emacs where zita2 is my laptop. It works, but it is ex tre me ly slow, I can count the lines being displayed when scrolling a page. This used to work perfectly before. Other apps doing quite intensive X work don't seem to be affected. OTOH, the emacs running on the laptop is of course the same as before. Video driver is 'nv', but it doesn't show up in lsmod. Some others do: 'drm' and 'ttm' which I haven't seen before. As far as I was able to find out, 'drm' is related to 3D-acceleration. I don't need nor want this, and I'm suspecting it could be related to the problem I'm seeing. Any hints/help will be appreciated ! Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !

5 10

Re: [arch-general] [arch-dev-public] [signoff] linux-api-headers-2.6.32.5-1
by Alexander Duscheleit 25 Jan '10

25 Jan '10

On Mon, 25 Jan 2010 08:37:17 -0600 Dan McGee <dpmcgee(a)gmail.com> wrote: > On Mon, Jan 25, 2010 at 1:46 AM, Allan McRae <allan(a)archlinux.org> > wrote: > > On 25/01/10 17:41, Jan de Groot wrote: > >> > >> On Sun, 2010-01-24 at 12:13 +1000, Allan McRae wrote: > >>> > >>> linux-api-headers-2.6.32.5-1 > >>> - convert to arch=any (built on x86_64, tested on i686) > [...] > > Good point. I had thought about this and decided that they we > > architecture independent on the architectures we support so went > > with arch=any. Should I revert that? > > A comment in the PKGBUILD would probably be nice even if you don't > revert it alluding to the above. That way anyone trying to do some abs > cross-compile could at least have something to go off of. However, > with that logic, making it not arch-independent would help them even > more... > > -Dan +1 for not arch-independent Community projects for different architectures are coming up all the time. Also, ARM is gaining a stronghold on netbooks, a perfect target for Arch. ARM might very well become a new official architecture in a few years, if it really takes of (the way I hope :)). Why introduce (subtle) stumbling blocks to save less than 1M on mirrors? Jinks

1 0

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

25 Jan '10

Allan McRae wrote: >Not anything recent: http://lwn.net/Articles/195167/ . Debian thinks >about these things a lot more than we do so I usually would defer to >them. But given they essentially created the cdrkit fork, I'm not sure >they are ever going to reassess the situation. The article you mention contains a lot of dissinformation and I am not conviced that Debian did even discuss their actions with a lawyer. I am happy to answer questions based on informations I have from various lawyers from Germany and the USA, but please let us ignore the claims from LWN and Debian. They are not helpful. The Sun legal department did check cdrtools in Autumn 2008 and the legal review did take three months. The result from this check is that there is absolutely no legal problem with the original cdrtools software. Note that Sun is the biggest OSS distributor and thus is a potential target for people who like to sue companies for distributing illegal software. Sun thus has a big interest to avoid anything that might cause legal troubles. Sun for this reason decided to distribute the original cdrtools and not to distribute the fork from Debian. 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

2 2

[arch-general] Boot Device Didn't Show Up
by Carlos Williams 25 Jan '10

25 Jan '10

Every time I try and install Arch Linux 2009.08 Netinst .ISO disk on my newly built PC hardware, I get the following error: Waiting for boot device... Error: Boot device didn't show up after 30 seconds... Falling back to interactive prompt. You can try and fix the problem manually, log out when you're finished. ramfs$ The same ISO works perfect on my laptop and other PC's but on my personal $1,000 PC, it doesn't. I can't figure this out. I also tried the 2009.08 Core disk and I get the same thing as with the 'Netinst' disk. I don't know if it's because I have a S-ATA DVD-ROM drive on this machine. I can boot from disk and see the Arch install options...even play "Space Invaders". But when I select the install Arch Linux options, it boots into a 'Live' environment and then hangs on the error above. Someone please help...

4 6

[arch-general] chsh, linux32 and $PATH
by Allan McRae 25 Jan '10

25 Jan '10

I am trying to seamlessly run an x86_64 kernel on my i686 machine. I have enough aliases that most things work right (prefixing with linux32), but bash can not handle setting e.g. "./configure" as an alias and there is always something I have missed. So, I came up with a cunning plan... Create a script /bin/bash32 which just runs "linux32 /bin/bash", then add /bin/bash32 to /etc/shells and run "chsh -s /bin/bash32". It works in a way... when I run uname, it tells me I am using the i686 kernel. Success! Now the bad part... my $PATH gets reduced to: /home/allan/bin:/bin:/usr/bin The /home/allan/bin part tells me that my ~/.bashrc is being sourced, as does my prompt and all my aliases. So something else is being missed. The /bin:/usr/bin is the minimum path defined in /etc/login.defs. All the rest is in /etc/profile and the various /etc/profile.d scripts. Why are they not being sourced... Or are they being sourced and then I open up a new shell with my script which gets rid of them? Allan

3 4

[arch-general] Why is makepkg not using rc.d/functions?
by Andres Perera 25 Jan '10

25 Jan '10

Is it strictly because it shouldn't depend on initscripts, or is there another reason?

2 1

[arch-general] [signoff] pcmciautils-016-1
by Tobias Powalowski 24 Jan '10

24 Jan '10

Hi bump to latest version, please signoff. Changes to initcpio pcmcia hook were needed and added in git tree, on next mkinitcpio bump they will be included. - udev rules and helper programs are now installed to /lib/udev/ greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 2

[arch-general] mkinitcpio 0.6 alpha - testing and help needed
by Thomas Bächler 24 Jan '10

24 Jan '10

Quoted from http://bugs.archlinux.org/task/17298 (which is also to be used for feedback, besides the threads on these mailing lists): So, now something can be tested. I recommend using it in conjunction with testing/udev only: [kill-klibc] Server = http://dev.archlinux.org/~thomas/kill-klibc/i686/ or [kill-klibc] Server = http://dev.archlinux.org/~thomas/kill-klibc/x86_64/ The standard hooks work, so do keymap, lvm2, encrypt. What does NOT work is raid/mdadm/dmraid and root on NFS. I would appreciate any input and patches w.r.t. those, as well as any testing. The v86d package also needs to be fixed, but that is trivial. device-mapper, lvm2 and cryptsetup have a weird "1.local" pkgrel so they won't collide with the ones from the repo, sorry if that bothers anyone. If you upgrade to this repositories, your existing mkinitcpio will be replaced and all klibc packages will be gone too. So, if you try it, please save your existing initramfs to a different filename as a fallback, and do not perform kernel upgrades until you either confirmed that it works, or downgraded to the klibc-based mkinitcpio.

1 0