- Arch-general - lists.archlinux.org

[arch-general] readline GPL violation on two pkgs?
by Gerardo Exequiel Pozzi 25 Jun '09

25 Jun '09

Hi, I just do a quick scan of soft linked with readline and I think that these two pkgs that are linked with readline violates GPL: extra/tftp-hpa community/ngspice Both have the "old" BSD (4-clause) license and is linked with readline that is GPL, so there is an incompatibility [#1] In the case of ngspice recomends to link with libedit to avoid legal issues [#2] Cheers, [#1] http://www.gnu.org/philosophy/license-list.html#OriginalBSD [#2] http://ngspice.sourceforge.net/relinfo.html -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

7 10

[arch-general] Not able to do system updates
by Will Siddall 25 Jun '09

25 Jun '09

I don't know what happened, but overnight, my system doesn't seem to allow me to update or install packages. I tried with 'sudo pacman -Su' and with 'yaourt -Su' and nothing. I know of at least 10 packages that need to be updated from yesterday. And on further testing, I can't install new packages either. I want to try out the go-openoffice and oss packages, but it won't download. When I do an update though (yaourt -Sy), it does download the new package lists and the files in /var/lib/pacman are updated. Anything any of you might want me to try to figure this out, it'll be greatly appreciated. Thanks, Will

6 9

[arch-general] sound busted after upgrade to kernel 2.6.30?
by Chris Brannon 25 Jun '09

25 Jun '09

My sound was busted yesterday when I upgraded from kernel 2.6.29 to 2.6.30. I had to regenerate my asound.state. At first, I thought it was just my problem, because I use the softvol plugin. This gave me trouble in the past. A friend of mine reported the same experience, so someone else had audio problems on upgrade as well. What happened to ALSA? Did anyone else have the same trouble? Regards, -- Chris

9 11

[arch-general] HELP: dmraid-1.0.0rc15 in testing - Possible Bug: All Partitions are GONE??
by David C. Rankin 25 Jun '09

25 Jun '09

On Monday 22 June 2009 05:30:20 pm Heinz Mauelshagen wrote: > David, > > you can run "dmraid -an" after closing (e.g. unmounting) > nvidia_ecaejfdip9, which ain't work now any more, because you already > deleted the partition. It'll of course not reappear on reboot. > > "dmsetup remove nvidia_ecaejfdip9" will do the trick without a reboot. > > Regards, > Heinz > Heinz, I may have run into a bug with dmraid-1.0.0rc15, you may want to look at. Tobias (on the Arch list), you may want to look into this as well. I have included the new information at the end of tis message to try and keep the information in context: > On Mon, 2009-06-22 at 14:48 -0500, David C. Rankin wrote: > > Heinz, > > > > I thought I would forward this one to you just in case there is a bug on the > > delete. It is probably just my limited understanding of dmraid, but I thought > > after I deleted the partition in cfdisk and then deactivated the device > > (nvidia_ecaejfdi) node nvidia_ecaejfdip9 should disappear? It is still there. > > How do I get rid of it? This is on Archlinux. Here is a bit more info about my > > setup: > > > > [14:17 archangel:/home/david/archlinux/dmraid] # l /dev/mapper > > total 0 > > drwxr-xr-x 2 root root 0 2009-06-22 13:44 . > > drwxr-xr-x 23 root root 0 2009-06-22 13:44 .. > > crw-rw---- 1 root root 10, 60 2009-06-22 01:40 control > > brw------- 1 root disk 254, 0 2009-06-22 13:48 nvidia_ecaejfdi > > brw------- 1 root disk 254, 2 2009-06-22 01:40 nvidia_ecaejfdip5 > > brw------- 1 root disk 254, 3 2009-06-22 01:40 nvidia_ecaejfdip6 > > brw------- 1 root disk 254, 4 2009-06-22 01:40 nvidia_ecaejfdip7 > > brw------- 1 root disk 254, 5 2009-06-22 01:40 nvidia_ecaejfdip8 > > brw------- 1 root disk 254, 10 2009-06-22 13:44 nvidia_ecaejfdip9 > > (I have deleted this in cfdisk) ^^^^^^^^^^^^^^^^^^ > > brw------- 1 root disk 254, 1 2009-06-22 01:40 nvidia_fdaacfde > > brw------- 1 root disk 254, 6 2009-06-22 01:40 nvidia_fdaacfdep5 > > brw------- 1 root disk 254, 7 2009-06-22 01:40 nvidia_fdaacfdep6 > > brw------- 1 root disk 254, 8 2009-06-22 01:40 nvidia_fdaacfdep7 > > brw------- 1 root disk 254, 9 2009-06-22 01:40 nvidia_fdaacfdep8 > > > > > > [14:13 archangel:/home/david/archlinux/dmraid] # dmraid -rd -v -v > > NOTICE: /dev/sdd: asr discovering > > NOTICE: /dev/sdd: ddf1 discovering > > NOTICE: /dev/sdd: hpt37x discovering > > NOTICE: /dev/sdd: hpt45x discovering > > NOTICE: /dev/sdd: isw discovering > > NOTICE: /dev/sdd: jmicron discovering > > NOTICE: /dev/sdd: lsi discovering > > NOTICE: /dev/sdd: nvidia discovering > > NOTICE: /dev/sdd: nvidia metadata discovered > > NOTICE: /dev/sdd: pdc discovering > > NOTICE: /dev/sdd: sil discovering > > NOTICE: /dev/sdd: via discovering > > NOTICE: /dev/sdc: asr discovering > > NOTICE: /dev/sdc: ddf1 discovering > > NOTICE: /dev/sdc: hpt37x discovering > > NOTICE: /dev/sdc: hpt45x discovering > > NOTICE: /dev/sdc: isw discovering > > NOTICE: /dev/sdc: jmicron discovering > > NOTICE: /dev/sdc: lsi discovering > > NOTICE: /dev/sdc: nvidia discovering > > NOTICE: /dev/sdc: nvidia metadata discovered > > NOTICE: /dev/sdc: pdc discovering > > NOTICE: /dev/sdc: sil discovering > > NOTICE: /dev/sdc: via discovering > > NOTICE: /dev/sdb: asr discovering > > NOTICE: /dev/sdb: ddf1 discovering > > NOTICE: /dev/sdb: hpt37x discovering > > NOTICE: /dev/sdb: hpt45x discovering > > NOTICE: /dev/sdb: isw discovering > > NOTICE: /dev/sdb: jmicron discovering > > NOTICE: /dev/sdb: lsi discovering > > NOTICE: /dev/sdb: nvidia discovering > > NOTICE: /dev/sdb: nvidia metadata discovered > > NOTICE: /dev/sdb: pdc discovering > > NOTICE: /dev/sdb: sil discovering > > NOTICE: /dev/sdb: via discovering > > NOTICE: /dev/sda: asr discovering > > NOTICE: /dev/sda: ddf1 discovering > > NOTICE: /dev/sda: hpt37x discovering > > NOTICE: /dev/sda: hpt45x discovering > > NOTICE: /dev/sda: isw discovering > > NOTICE: /dev/sda: jmicron discovering > > NOTICE: /dev/sda: lsi discovering > > NOTICE: /dev/sda: nvidia discovering > > NOTICE: /dev/sda: nvidia metadata discovered > > NOTICE: /dev/sda: pdc discovering > > NOTICE: /dev/sda: sil discovering > > NOTICE: /dev/sda: via discovering > > INFO: RAID devices discovered: > > > > /dev/sdd: nvidia, "nvidia_ecaejfdi", mirror, ok, 1465149166 sectors, data@ 0 > > /dev/sdc: nvidia, "nvidia_fdaacfde", mirror, ok, 976773166 sectors, data@ 0 > > /dev/sdb: nvidia, "nvidia_ecaejfdi", mirror, ok, 1465149166 sectors, data@ 0 > > /dev/sda: nvidia, "nvidia_fdaacfde", mirror, ok, 976773166 sectors, data@ 0 > > [14:13 archangel:/home/david/archlinux/dmraid] # mc > > All was fine yesterday. Everything seemed to work well. Today, I am dead in the water and for some reason, all my partitions are gone from my Archlinux install with the new dmraid. Here is the problem: Today, I rebooted the Archlinux (hostname Archangel) install that is using dmraid-1.0.0rc15 the boot failed. Archlinux is running on nvidia_ecaejfdi (sdb/sdd - 2 500 Gig. Seagate Drives: ST3500630AS). However, when I booted to openSuSE 11.0 (hostname Ecstasy) running dmraid-1.0.0.rc14-63.1 sdb/sdd - 2 750 Gig. Seagate Drives: ST3750330AS), I lost all the nvidia_ecaejfdi devices and could not mount any of my archlinux partitions while running openSuSE. Here are the errors and information: 12:52 ecstasy:~> mount_arch Mounting 750G dmraid partitions under /mnt/arch mounting /dev/mapper/nvidia_ecaejfdi_part5 --> /mnt/arch/ mount: special device /dev/mapper/nvidia_ecaejfdi_part5 does not exist /mnt/arch/root/ -- Failed, Cancelling mount & exiting... (OK, I thought I just needed to adjust the mapper label to "ecaejfdip5" here. That wasn't the case) 12:52 ecstasy:~> l /dev/mapper total 0 drwxr-xr-x 2 root root 200 2009-06-23 12:48 ./ drwxr-xr-x 12 root root 4960 2009-06-23 12:49 ../ lrwxrwxrwx 1 root root 16 2009-06-23 12:48 control -> ../device-mapper brw------- 1 root root 253, 0 2009-06-23 12:48 nvidia_ecaejfdi brw------- 1 root root 253, 1 2009-06-23 12:48 nvidia_fdaacfde brw------- 1 root root 253, 2 2009-06-23 12:48 nvidia_fdaacfde_part1 brw------- 1 root root 253, 3 2009-06-23 12:48 nvidia_fdaacfde_part5 brw------- 1 root root 253, 4 2009-06-23 12:48 nvidia_fdaacfde_part6 brw------- 1 root root 253, 5 2009-06-23 12:48 nvidia_fdaacfde_part7 brw------- 1 root root 253, 6 2009-06-23 12:48 nvidia_fdaacfde_part8 12:53 ecstasy:~> su - Password: [12:53 ecstasy:~] # dmraid -ay RAID set "nvidia_ecaejfdi" already active RAID set "nvidia_fdaacfde" already active [12:53 ecstasy:~] # l /dev/mapper total 0 drwxr-xr-x 2 root root 280 Jun 23 12:53 ./ drwxr-xr-x 12 root root 5040 Jun 23 12:54 ../ lrwxrwxrwx 1 root root 16 Jun 23 12:48 control -> ../device-mapper brw------- 1 root root 253, 0 Jun 23 12:48 nvidia_ecaejfdi brw------- 1 root root 253, 1 Jun 23 12:48 nvidia_fdaacfde brw------- 1 root root 253, 7 Jun 23 12:53 nvidia_fdaacfde5 brw------- 1 root root 253, 8 Jun 23 12:53 nvidia_fdaacfde6 brw------- 1 root root 253, 9 Jun 23 12:53 nvidia_fdaacfde7 brw------- 1 root root 253, 10 Jun 23 12:53 nvidia_fdaacfde8 brw------- 1 root root 253, 2 Jun 23 12:48 nvidia_fdaacfde_part1 brw------- 1 root root 253, 3 Jun 23 12:48 nvidia_fdaacfde_part5 brw------- 1 root root 253, 4 Jun 23 12:48 nvidia_fdaacfde_part6 brw------- 1 root root 253, 5 Jun 23 12:48 nvidia_fdaacfde_part7 brw------- 1 root root 253, 6 Jun 23 12:48 nvidia_fdaacfde_part8 You can see above that when booting opensuse with (dmraid-1.0.0.rc14-63.1), All nvidia_fdaacfde partitions have been "Duplicated". Once with a simple number '5-8' and again with the old style '_part5-_part8', -- and -- no partitions were created for "nvidia_ecaejfdi." Now this should not be happening. It is also confirmed with: 16:04 ecstasy:~> cat /proc/partitions major minor #blocks name 8 0 488386584 sda 8 1 1 sda1 8 5 72229 sda5 8 6 2104483 sda6 8 7 20972826 sda7 8 8 465234336 sda8 8 16 732574584 sdb 8 32 488386584 sdc 8 33 1 sdc1 8 37 72229 sdc5 8 38 2104483 sdc6 8 39 20972826 sdc7 8 40 465234336 sdc8 8 48 732574584 sdd 253 0 732574583 dm-0 253 1 488386583 dm-1 253 2 488384001 dm-2 253 3 72229 dm-3 253 4 2104483 dm-4 253 5 20972826 dm-5 253 6 465234336 dm-6 Now this is very scary looking. The sdb[5-8] and sdd[5-8] partitions are GONE?? (Bummer..) Obviously, I can no longer boot archlinux?? As I mentioned earlier, the Archlinux install on this box is just for testing and if there is no way to recover it, I'll just reinstall, but I would like to try and get it back. I have saved all the 'fdisk -l' information for the partitions and I might have the dmraid -D information around somewhere. One more potential culprit is the kernel update that was applied before I rebooted the machine: -rw-r--r-- 1 root root 35338866 2009-06-23 14:23 /var/cache/pacman/pkg/kernel26-2.6.30-5-x86_64.pkg.tar.gz I strongly suspect that is a player in this problem. So I need help from anyone on the Arch list or you Heinz or Tobias that might be able to suggest a way to recover from this problem. Any thoughts? -- 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 3

[arch-general] okular print preview error
by prad 25 Jun '09

25 Jun '09

when i try to do a print preview with okular i get a dialogbox saying it couldn't open an okular.ps file in /tmp. this is weird too because the file has rw permissions for the user. suggestions? -- In friendship, prad ... with you on your journey Towards Freedom http://www.towardsfreedom.com (website) Information, Inspiration, Imagination - truly a site for soaring I's

5 7

Re: [arch-general] [arch-dev-public] [idea] global link database for all packages
by Gerardo Exequiel Pozzi 24 Jun '09

24 Jun '09

Pierre Schmitz wrote: > Hi, > > I just got an idea which might be worth to think about. Namcap is quite useful > but due to its limitation of only seeing a certain pkg file at a time it > cannot answer all questions. > > The idea is to create a database (similar to the file list we already create) > which includes lists of files and to which they are linked. <snip> Hi, Some times ago I sended to the list this: http://github.com/djgera/pkgdyn For the database output and output usable data: http://archlinux.djgera.com.ar/pkgdyn http://archlinux.djgera.com.ar/pkgdyn/out/i686/core.the-BIG-dependency-fami… -- 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] KDE4.3 Beta - Rocks, still a bit rough, but very usable as a primary desktop
by David C. Rankin 24 Jun '09

24 Jun '09

Listmates, Having been a leading pessimist of KDE4 since a crippled 4.04 was dumped on the openSuSE community on 11.0 and then more disappointment dumped again with kde 4.1 in 11.1, I have been skeptical if the desktop, which from first looks was something developed by teenagers on way too much Jolt Soda, would ever get to a usable state. Well for the past week I took the plunge again with openSuSE's 4.3Beta1 1- click install on my spare drive, and ... I never thought I would type these words, but I like it! It is more than usable as a primary desktop. That's not to say it doesn't still need a lot of tlc, but the bugs are largely run of the mill bugs that just need cleanup and aren't showstoppers. One of my biggest bitches has been the fish_kio functionality and the inability to connect to boxes across the internet (fish over lan worked). Well, fish over the internet isn't broken, it's just really screwed up! What that means is that you can actually get fish to connect to a remote box (you just have to repeatedly try the same connection 3-25 times have it connect- crash-disconnect until it actually succeeds in connecting and establishing a session for the first time) The upside? Once you establish the connection to your remote host the first time, fish will re-connect to it as usual. No kidding. Why it craters after connecting and before a fish session is established the on the first 3-25 times is still up in the air, as well as why it continues to work just fine after that... but it does. I have given kde4 on heck of a shakedown and added 15 or so new, along with a couple of old, bugs to bugs.kde.org. Here is a short list of the bugs from the shakedown of kde4 in the past few days (just add the "ID" at the end of: https://bugs.kde.org/show_bug.cgi?id= if you want the details) ID Summary 195247 KDE4.3beta1 knotes causes SegFault in Kontact 195259 kmail "message structure" needs show/hide button 195505 Composer Standard Templates Defaults Not Reset After Default Pressed & OK 195635 Konqueror "Tabbed Browsing" Settings Do Not Take Effect until Restart 195808 File Manager Does Not Restore Saved Profile 195697 F8 (show hidden files) Requires Manual Focus on File List 158985 kbattleship freezes when attempting to join lan game 195528 Detail View: Clicking in space between File/Folder name and Size fails to place Focus 195533 kmail: No indication shown for Unread Messages in Collapsed Thread 195343 New sub-basket does not respect color scheme 195623 Basket Groups Not Expanded and Systray Icon Won't Restore Basket App 195489 Organization should be Formatted Name if no Family or Given present 195493 Groupware Integration Authentication Fails after Session Timeout 195523 "Formatted Name" Listbox needs to be accessible outside "Edit Name" subform 195367 fish_kio Fails in kde4.3 for konqueror, kate, kwrite, etc.. 176599 Wish - KfontViewer needs 'next->file' 'previous->file' and 'mark/tag' features 189583 Ability to add submenu "like editors" to kicker panel from classic menu If you have been staying away from kde4 until it was "usable" (as I was), well, "It's Usable!" in 4.3 Beta. The more users that take the plunge now and find the little snafus in their favorite apps and bug it to bugs.kde.org, the quicker it will be "Cleanly Usable" Now all I have to do is figure out how to get 4.3 Beta loaded on my Arch drive and I'll be golden! Seriously, I thought I would load kde4, see what had improved and be disappointed again, probably trash my elegant kde3 install with cross-configuration issues in the process, and have to dump the drive and reinstall. Was I ever pleasantly surprised. If you have been in the same holding-pattern lately in your thinking about kde4 as well -- I bet you will be pleasantly surprised as well ;-) Thank God .. There is hope for KDE4 after all! P.S. To really see the desktop effects as they should be, you need to adjust the "Animation duration" to something that is reasonable for your hardware (it is set to a terrible default for any newer hardware) In kde control center > appearance > desktop effects (then in the individual effect settings) try a setting of about 250ms and go up (most likely) or down by 50ms at a time until the effects smooth out and look right. 250-280ms worked fine on my laptop. I suspect the default is off by a factor of 10 from its intended setting which makes the effects look jerky and crude compared to the compiz effect they were based on. (the default is probably 25ms when it was intended to be 250ms) Anyway, it sure make the effects look much better. The kde4 desktop effects still don't compare to the equivalent compiz effects and there is no equivalent to certain compiz effects I really like (Expo, etc.), but what is there looks pretty darn good for KDE4 all things considered. Give it a go... Now where can I get 4.3 Beta for Arch? or at least a good howto on how to download the build dependencies needed to build from source. I'll check the wiki ;-) -- 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

10 47

[arch-general] Update to latest [kde-unstable] - It is looking good!, HAL/d-bus/PolicyKit Change?
by David C. Rankin 24 Jun '09

24 Jun '09

Listmates, Couple of thoughts for this day. Latest updates come with the following praise and questions: (1) kde4.3 beta 2 (4.2.92svn984151-1) - Wow, much crisper, behaving ...well, like it should. Even with the radeonhd driver it feels better than (4.2.90 with fglrx on suse)! (2) all dmraid partitions lost with dmraid-1.0.0rc15 and kernel26-2.6.30-5. (subject of another thread) (3) new kernel also did something to Hal/d-bus/PolicyKit, so I can't access my usb drives again with the brute force approach. Any thoughts? -- 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

4 3

[arch-general] konversation 1.2 alpha3 (move to extra's)
by Caleb Cushing 24 Jun '09

24 Jun '09

I've been using the alpha's now for a few weeks, and they appear to be no less stable than the 1.1 version, very few problems (way less buggy than many kde4 apps like koffice, and amarok 2.0 (was). I'd like to suggest moving it to extra's as a way to remove one more package that needs kde3. -- Caleb Cushing http://xenoterracide.blogspot.com

2 1

Re: [arch-general] [arch-dev-public] [announcement] kernel26 2.6.30 announcement draft
by Grigorios Bouzakis 24 Jun '09

24 Jun '09

On Wed, Jun 24, 2009 at 11:16 AM, Thomas Bächler <thomas(a)archlinux.org>wrote: > Andreas Radke schrieb: > >> Just a note. The "early" mkinitcpio way of Intel KMS is broken on my >> gf's system resulting in an instant reboot. "Late" kms way is still >> working. I had to use a rescue disc. >> >> Maybe more user will be affected. >> > > That is confusing, as it does exactly the same, just a bit earlier (and it > works here, obviously). > > Although early KMS is only useful for people who enter passphrases during > boot - and people who care about how pretty their screen is - this is > definitely a bug and a weird one. If we can narrow it down that would be > nice. > > To me it happened with the .30-3 or .30-4 kernel from _testing_ and btw my laptop has an nvidia card. Seems i had updated and hadnt rebooted for about a week to check if it actually works. I revented back to .29, along with a downgrade of klibc, mkinitcpio etc, booted and updated to -5 from core this morning. This one works OK. -- Greg

1 0

Re: [arch-general] deps not being properly recognized?
by Andrei Thorp 24 Jun '09

24 Jun '09

Excerpts from Allan McRae's message of Sat Jun 20 21:37:11 -0400 2009: > Caleb Cushing wrote: > > I can't figure out why pacman thinks that deps aren't being fulfilled. > > > > Targets (1): perl-datetime-0.50-1 > > <snip> > > :: perl-datetime-format-strptime: requires perl-datetime>=0.4304 > > > > 50 is not >= 4304 > > Allan Hmm. That's kind of unfortuante. Chances are, .5x is actually meant to be greater than the .4xxx. Guess the best you can do is force it? :S -AT -- Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com) C:\> WIN Bad command or filename C:\> LOSE Loading Microsoft Windows ...

3 2

[arch-general] portable player, usb plugging/mounting problems
by Guilherme M. Nogueira 24 Jun '09

24 Jun '09

Hello dear Arch users, I have a Sansa e200 portable media player and I'm having problems mounting it. It used to work, but I can't recall when (I have been listening to the same stuff for over 4 months now). I'm using arch i686 with core, extra, community, kdemod-core and kdemod-extragear and updated system. The player has two modes, MSC and MTP. I always use it in Mass Storage Class mode. Thing is, when I plug the device with HAL running I get the following: $ dmesg: usb 1-6: new high speed USB device using ehci_hcd and address 13 usb 1-6: configuration #128 chosen from 1 choice scsi24 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 13 usb-storage: waiting for device to settle before scanning usb 1-6: reset high speed USB device using ehci_hcd and address 13 scsi25 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 13 usb-storage: waiting for device to settle before scanning If I stop HAL deamon, I get this: $ dmesg usb 1-6: new high speed USB device using ehci_hcd and address 4 usb 1-6: configuration #128 chosen from 1 choice scsi14 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 4 usb-storage: waiting for device to settle before scanning scsi 14:0:0:0: Direct-Access SanDisk Sansa e270 PQ: 0 ANSI: 0 sd 14:0:0:0: [sdb] 11780096 512-byte hardware sectors: (6.03 GB/5.61 GiB) sd 14:0:0:0: [sdb] Write Protect is off sd 14:0:0:0: [sdb] Mode Sense: 45 00 00 00 sd 14:0:0:0: [sdb] Assuming drive cache: write through sd 14:0:0:0: [sdb] 11780096 512-byte hardware sectors: (6.03 GB/5.61 GiB) sd 14:0:0:0: [sdb] Write Protect is off sd 14:0:0:0: [sdb] Mode Sense: 45 00 00 00 sd 14:0:0:0: [sdb] Assuming drive cache: write through sdb: sdb1 sdb2 sd 14:0:0:0: [sdb] Attached SCSI removable disk sd 14:0:0:0: Attached scsi generic sg2 type 0 scsi 14:0:0:1: Direct-Access SanDisk Sansa e270 PQ: 0 ANSI: 0 sd 14:0:0:1: [sdc] 246016 512-byte hardware sectors: (125 MB/120 MiB) sd 14:0:0:1: [sdc] Write Protect is off sd 14:0:0:1: [sdc] Mode Sense: 45 00 00 00 sd 14:0:0:1: [sdc] Assuming drive cache: write through sd 14:0:0:1: [sdc] 246016 512-byte hardware sectors: (125 MB/120 MiB) sd 14:0:0:1: [sdc] Write Protect is off sd 14:0:0:1: [sdc] Mode Sense: 45 00 00 00 sd 14:0:0:1: [sdc] Assuming drive cache: write through sdc: sdc1 sd 14:0:0:1: [sdc] Attached SCSI removable disk sd 14:0:0:1: Attached scsi generic sg3 type 0 usb-storage: device scan complete The output of lsusb is: $ lsusb Bus 001 Device 013: ID 0781:7421 SanDisk Corp. Sansa E200 series I don't really understand why is this, since I read that HAL just gets notified of the new device and provides the interface for other apps, but the kernel and udev are the ones that really do the recognizing and mounting. Since in my mind udev is the one that does the job, I tried following a tip I read in the mainling list archive and created a new udev rule in /etc/udev/rules.d/sansa.rules with: UBSYSTEMS=="usb", KERNEL=="sd*", ATTRS{idProduct}=="7421",ATTRS{idVendor}=="0781", SYMLINK+="sansa", GROUP="storage" I ask for you help to understand what is going on here. Thank you very much, Guilherme. -- Malformed message exception

3 4

Re: [arch-general] [arch-dev-public] [announcement] kernel26 2.6.30 announcement draft
by Grigorios Bouzakis 24 Jun '09

24 Jun '09

On Tue, Jun 23, 2009 at 8:44 PM, Andreas Radke <a.radke(a)arcor.de> wrote: > Am Sun, 21 Jun 2009 22:54:01 +0200 > schrieb Tobias Powalowski <t.powa(a)gmx.de>: > > > Am Sonntag 21 Juni 2009 schrieb Pierre Schmitz: > > > On Sunday 21 June 2009 22:38:25 Tobias Powalowski wrote: > > > > - added SCHED_DEBUG=y > > > > > > What does this do? > > One of the bug reports in earlier mails was about it, you can change > > scheduler details with that. > > > > greetings > > tpowa > > Just a note. The "early" mkinitcpio way of Intel KMS is broken on my > gf's system resulting in an instant reboot. "Late" kms way is still > working. I had to use a rescue disc. > > Maybe more user will be affected. > > -Andy > I got this too on one of my laptops. How can i fix this? -- Greg

1 0

[arch-general] Holy Cow -- What happened to bash / vi??
by David C. Rankin 23 Jun '09

23 Jun '09

Listmates, I updated to [testing] and now I am having strange behavior from either bash or vi. (the new vi has many issues, but ignoring those for the moment) I have one of my simple parse scripts open in vi in one console window and I make a few changes to a sed expression, then :w to save the changes and [shift]-> in konsole to get to a second konsole window to run the script and bash won't let me??? I get this new message: [00:08 archangel:/etc] # noc fstab bash: /usr/local/bin/noc: /bin/bash: bad interpreter: Text file busy WTF?? Here is the entire script: [00:11 archangel:/etc] # cat /usr/local/bin/noc #!/bin/bash if [[ -z "$1" ]]; then echo -e "\n\n\tUsage: ${0##*/} <filename>" echo -e "\n\n\tParses the text file <filename> and removes all blank lines and all lines beginning \ \n\twith a first non-blank character of [# ; !] or two character of '//' or '/*'. \ \n\tIt is useful for looking at configuration files without all the comments. \n" exit 1 fi # updated to handle php, C and C++ // comments sed -e '/^[/s]*$/d' -e '/^\s*[#;!]/d' -e '/^\s*[/*]/d' -e 's/[^:]\/\/.*$//' <$1 exit 0 Text file busy?? It's a text file, it's not busy, it's either saved or you get what was present the last time it was saved, but it certainly isn't busy. Apparently bash is not looking for vi tmp file and calling it busy if found??? What gives??? Yep, that is exactly what is happening. If i quit vi and try the script: [00:16 archangel:/etc] # noc fstab none /dev/pts devpts defaults 0 0 none /dev/shm tmpfs defaults 0 0 If I open it back up in vi and then try to run it: [00:16 archangel:/etc] # noc fstab bash: /usr/local/bin/noc: /bin/bash: bad interpreter: Text file busy How (and where) do I tell bash or vi not to do this. I don't even know where to start looking.... (I tested on another box that I have NOT updated anything from [testing] and vi and bash both work properly. Any help would be appreciated, thanks. -- 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

8 9

[arch-general] 2.6.30 kernel
by Baho Utot 23 Jun '09

23 Jun '09

I have completed to setup my new 64-bit system. This new kernel solved some slow down in the open source radeonhd grapihcs driver as it is on par with the open source ati driver... large improvement. I am now going to install the 32-bit arch version on this machine also. I have looked into enable PAE in the kernel. If I am successfull I would like to make a PKGBUILD and .config file as a package. How would I go about to do so. I am looking at calling the thing kernel26-pae or something like that. Would that work for AUR ?

2 1

[arch-general] Presto for pacman?
by Magnus Therning 23 Jun '09

23 Jun '09

Is there something similar to Yum Presto[1] for pacman? Would it be possible to do, or are there limitations in the package format that prevents it? /M [1]: http://fedoraproject.org/wiki/Features/Presto -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

6 8

[arch-general] vi from testing has gone nuts - does not honor virc/~.virc settings
by David C. Rankin 23 Jun '09

23 Jun '09

Listmates, Devs: I upgraded to testing to test the new dmraid. As part of the upgrade, vi was changed in a BIG way. (I could hardly use the thing and I have been using it for 20 years) The screen flashes when you double-escape, in insert mode if you move to colum 1 things go nuts, insert mode is changed into some kind of vampire. None of the normal key mappings work, and I can't get my beloved vi back by restoring the virc from the virc.pacnew - GGRrrrr :-( How do I make my vi return to normal? What's the trick? If restoring the virc and changing the settings has no effect (I even logged out and back) Wher are the magic settings now? And... if the version I have can't be made to behave like my normal vi/vim again, "Then what is the proper way to downgrade vi so I can get my friend back? -- 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

11 16

[arch-general] New Conflict on System Upgrade - license? pear? vi?
by David C. Rankin 23 Jun '09

23 Jun '09

Listmates, Here are some strange conflicts found during an attempted system update. Thankfully they are limited to the license package, pear and vi: (269/269) checking for file conflicts [#################################################] 100% error: could not prepare transaction error: failed to commit transaction (conflicting files) licenses: /usr/share/licenses/common/FDL exists in filesystem licenses: /usr/share/licenses/common/GPL exists in filesystem licenses: /usr/share/licenses/common/GPL2/license.txt exists in filesystem licenses: /usr/share/licenses/common/LGPL exists in filesystem php: /usr/share/pear/.registry/xml_util.reg exists in filesystem php: /usr/share/pear/XML/Util.php exists in filesystem php: /usr/share/pear/doc/PEAR/LICENSE exists in filesystem php: /usr/share/pear/doc/XML_Util/examples/example.php exists in filesystem php: /usr/share/pear/doc/XML_Util/examples/example2.php exists in filesystem php: /usr/share/pear/test/XML_Util/tests/AllTests.php exists in filesystem php: /usr/share/pear/test/XML_Util/tests/testBasic_apiVersion.phpt exists in filesystem php: /usr/share/pear/test/XML_Util/tests/testBasic_attributesToString.phpt exists in filesystem php: /usr/share/pear/test/XML_Util/tests/testBasic_collapseEmptyTags.phpt exists in filesystem php: /usr/share/pear/test/XML_Util/tests/testBasic_createCDataSection.phpt exists in filesystem php: /usr/share/pear/test/XML_Util/tests/testBasic_createComment.phpt exists in filesystem php: /usr/share/pear/test/XML_Util/tests/testBasic_createEndElement.phpt exists in filesystem php: /usr/share/pear/test/XML_Util/tests/testBasic_createStartElement.phpt exists in filesystem php: /usr/share/pear/test/XML_Util/tests/testBasic_createTag.phpt exists in filesystem php: /usr/share/pear/test/XML_Util/tests/testBasic_createTagFromArray.phpt exists in filesystem php: /usr/share/pear/test/XML_Util/tests/testBasic_getDocTypeDeclaration.phpt exists in filesystem php: /usr/share/pear/test/XML_Util/tests/testBasic_getXmlDeclaration.phpt exists in filesystem php: /usr/share/pear/test/XML_Util/tests/testBasic_isValidName.phpt exists in filesystem php: /usr/share/pear/test/XML_Util/tests/testBasic_raiseError.phpt exists in filesystem php: /usr/share/pear/test/XML_Util/tests/testBasic_replaceEntities.phpt exists in filesystem php: /usr/share/pear/test/XML_Util/tests/testBasic_reverseEntities.phpt exists in filesystem php: /usr/share/pear/test/XML_Util/tests/testBasic_splitQualifiedName.phpt exists in filesystem php: /usr/share/pear/test/XML_Util/tests/testBug_4950.phpt exists in filesystem php: /usr/share/pear/test/XML_Util/tests/testBug_5392.phpt exists in filesystem vi: /usr/bin/view exists in filesystem I guess these are left overs from the earlier forced kde-unstable install. I'll try an uninstall of the packages and then a reinstall and see how it goes... -- 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

3 3

[arch-general] Fwd: Re: dmraid-1.0.0rc15 in testing, need you help on this! (possible Bug on Delete)
by David C. Rankin 23 Jun '09

23 Jun '09

Heinz, I thought I would forward this one to you just in case there is a bug on the delete. It is probably just my limited understanding of dmraid, but I thought after I deleted the partition in cfdisk and then deactivated the device (nvidia_ecaejfdi) node nvidia_ecaejfdip9 should disappear? It is still there. How do I get rid of it? This is on Archlinux. Here is a bit more info about my setup: [14:17 archangel:/home/david/archlinux/dmraid] # l /dev/mapper total 0 drwxr-xr-x 2 root root 0 2009-06-22 13:44 . drwxr-xr-x 23 root root 0 2009-06-22 13:44 .. crw-rw---- 1 root root 10, 60 2009-06-22 01:40 control brw------- 1 root disk 254, 0 2009-06-22 13:48 nvidia_ecaejfdi brw------- 1 root disk 254, 2 2009-06-22 01:40 nvidia_ecaejfdip5 brw------- 1 root disk 254, 3 2009-06-22 01:40 nvidia_ecaejfdip6 brw------- 1 root disk 254, 4 2009-06-22 01:40 nvidia_ecaejfdip7 brw------- 1 root disk 254, 5 2009-06-22 01:40 nvidia_ecaejfdip8 brw------- 1 root disk 254, 10 2009-06-22 13:44 nvidia_ecaejfdip9 (I have deleted this in cfdisk) ^^^^^^^^^^^^^^^^^^ brw------- 1 root disk 254, 1 2009-06-22 01:40 nvidia_fdaacfde brw------- 1 root disk 254, 6 2009-06-22 01:40 nvidia_fdaacfdep5 brw------- 1 root disk 254, 7 2009-06-22 01:40 nvidia_fdaacfdep6 brw------- 1 root disk 254, 8 2009-06-22 01:40 nvidia_fdaacfdep7 brw------- 1 root disk 254, 9 2009-06-22 01:40 nvidia_fdaacfdep8 [14:13 archangel:/home/david/archlinux/dmraid] # dmraid -rd -v -v NOTICE: /dev/sdd: asr discovering NOTICE: /dev/sdd: ddf1 discovering NOTICE: /dev/sdd: hpt37x discovering NOTICE: /dev/sdd: hpt45x discovering NOTICE: /dev/sdd: isw discovering NOTICE: /dev/sdd: jmicron discovering NOTICE: /dev/sdd: lsi discovering NOTICE: /dev/sdd: nvidia discovering NOTICE: /dev/sdd: nvidia metadata discovered NOTICE: /dev/sdd: pdc discovering NOTICE: /dev/sdd: sil discovering NOTICE: /dev/sdd: via discovering NOTICE: /dev/sdc: asr discovering NOTICE: /dev/sdc: ddf1 discovering NOTICE: /dev/sdc: hpt37x discovering NOTICE: /dev/sdc: hpt45x discovering NOTICE: /dev/sdc: isw discovering NOTICE: /dev/sdc: jmicron discovering NOTICE: /dev/sdc: lsi discovering NOTICE: /dev/sdc: nvidia discovering NOTICE: /dev/sdc: nvidia metadata discovered NOTICE: /dev/sdc: pdc discovering NOTICE: /dev/sdc: sil discovering NOTICE: /dev/sdc: via discovering NOTICE: /dev/sdb: asr discovering NOTICE: /dev/sdb: ddf1 discovering NOTICE: /dev/sdb: hpt37x discovering NOTICE: /dev/sdb: hpt45x discovering NOTICE: /dev/sdb: isw discovering NOTICE: /dev/sdb: jmicron discovering NOTICE: /dev/sdb: lsi discovering NOTICE: /dev/sdb: nvidia discovering NOTICE: /dev/sdb: nvidia metadata discovered NOTICE: /dev/sdb: pdc discovering NOTICE: /dev/sdb: sil discovering NOTICE: /dev/sdb: via discovering NOTICE: /dev/sda: asr discovering NOTICE: /dev/sda: ddf1 discovering NOTICE: /dev/sda: hpt37x discovering NOTICE: /dev/sda: hpt45x discovering NOTICE: /dev/sda: isw discovering NOTICE: /dev/sda: jmicron discovering NOTICE: /dev/sda: lsi discovering NOTICE: /dev/sda: nvidia discovering NOTICE: /dev/sda: nvidia metadata discovered NOTICE: /dev/sda: pdc discovering NOTICE: /dev/sda: sil discovering NOTICE: /dev/sda: via discovering INFO: RAID devices discovered: /dev/sdd: nvidia, "nvidia_ecaejfdi", mirror, ok, 1465149166 sectors, data@ 0 /dev/sdc: nvidia, "nvidia_fdaacfde", mirror, ok, 976773166 sectors, data@ 0 /dev/sdb: nvidia, "nvidia_ecaejfdi", mirror, ok, 1465149166 sectors, data@ 0 /dev/sda: nvidia, "nvidia_fdaacfde", mirror, ok, 976773166 sectors, data@ 0 [14:13 archangel:/home/david/archlinux/dmraid] # mc How do I remove the nvidia_ecaejfdip9 entry? -- 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 On Monday 22 June 2009 03:13:41 am Tobias Powalowski wrote: > I need to explain this a bit more: > <snip> > > Now i cfdisk this device, are the nodes updated then? > - I mean do i get the /dev/mapper/vidia_fffadgicp1 p2 p3 autimatically or > do I need to run dmraid -ay for every partition i created? > - Also what happens if partitions are deleted? > ADDING NEW PARTITION (PART9) - 10G IN SIZE: cfdisk (util-linux-ng 2.14.2) Disk Drive: /dev/mapper/nvidia_ecaejfdi Size: 750156372992 bytes, 750.1 GB Heads: 255 Sectors per Track: 63 Cylinders: 91201 Name Flags Part Type FS Type [Label] Size (MB) ---------------------------------------------------------------------------------------------------------- nvidia_ecaejfdi5Boot Logical Linux ext3 20003.85 * nvidia_ecaejfdi6 Logical Linux ext3 123.38 nvidia_ecaejfdi7 Logical Linux ext3 39999.54 nvidia_ecaejfdi8 Logical Linux swap / Solaris 1998.75 nvidia_ecaejfdi9 Logical Linux 10001.95 Pri/Log Free Space 678026.29 (write & quit) New node NOT created: [13:39 archangel:~] # l /dev/mapper total 0 drwxr-xr-x 2 root root 0 2009-06-22 01:40 . drwxr-xr-x 23 root root 0 2009-06-22 01:41 .. crw-rw---- 1 root root 10, 60 2009-06-22 01:40 control brw------- 1 root disk 254, 0 2009-06-22 13:38 nvidia_ecaejfdi brw------- 1 root disk 254, 2 2009-06-22 01:40 nvidia_ecaejfdip5 brw------- 1 root disk 254, 3 2009-06-22 01:40 nvidia_ecaejfdip6 brw------- 1 root disk 254, 4 2009-06-22 01:40 nvidia_ecaejfdip7 brw------- 1 root disk 254, 5 2009-06-22 01:40 nvidia_ecaejfdip8 <snip> [13:44 archangel:~] # dmraid -ay nvidia_ecaejfdi RAID set "nvidia_ecaejfdi" already active RAID set "nvidia_ecaejfdip5" already active RAID set "nvidia_ecaejfdip6" already active RAID set "nvidia_ecaejfdip7" already active RAID set "nvidia_ecaejfdip8" already active RAID set "nvidia_ecaejfdip9" was activated [13:44 archangel:~] # l /dev/mapper total 0 drwxr-xr-x 2 root root 0 2009-06-22 13:44 . drwxr-xr-x 23 root root 0 2009-06-22 13:44 .. crw-rw---- 1 root root 10, 60 2009-06-22 01:40 control brw------- 1 root disk 254, 0 2009-06-22 13:38 nvidia_ecaejfdi brw------- 1 root disk 254, 2 2009-06-22 01:40 nvidia_ecaejfdip5 brw------- 1 root disk 254, 3 2009-06-22 01:40 nvidia_ecaejfdip6 brw------- 1 root disk 254, 4 2009-06-22 01:40 nvidia_ecaejfdip7 brw------- 1 root disk 254, 5 2009-06-22 01:40 nvidia_ecaejfdip8 brw------- 1 root disk 254, 10 2009-06-22 13:44 nvidia_ecaejfdip9 <snip> DELETING PARTITION (PART 9) - 10G IN SIZE cfdisk (util-linux-ng 2.14.2) Disk Drive: /dev/mapper/nvidia_ecaejfdi Size: 750156372992 bytes, 750.1 GB Heads: 255 Sectors per Track: 63 Cylinders: 91201 Name Flags Part Type FS Type [Label] Size (MB) ---------------------------------------------------------------------------------------------------------- nvidia_ecaejfdi5Boot Logical Linux ext3 20003.85 * nvidia_ecaejfdi6 Logical Linux ext3 123.38 nvidia_ecaejfdi7 Logical Linux ext3 39999.54 nvidia_ecaejfdi8 Logical Linux swap / Solaris 1998.75 Pri/Log Free Space 688028.23 (write & quit) Partition NOT removed from /dev/mapper: [13:48 archangel:~] # l /dev/mapper total 0 drwxr-xr-x 2 root root 0 2009-06-22 13:44 . drwxr-xr-x 23 root root 0 2009-06-22 13:44 .. crw-rw---- 1 root root 10, 60 2009-06-22 01:40 control brw------- 1 root disk 254, 0 2009-06-22 13:48 nvidia_ecaejfdi brw------- 1 root disk 254, 2 2009-06-22 01:40 nvidia_ecaejfdip5 brw------- 1 root disk 254, 3 2009-06-22 01:40 nvidia_ecaejfdip6 brw------- 1 root disk 254, 4 2009-06-22 01:40 nvidia_ecaejfdip7 brw------- 1 root disk 254, 5 2009-06-22 01:40 nvidia_ecaejfdip8 brw------- 1 root disk 254, 10 2009-06-22 13:44 nvidia_ecaejfdip9 <snip> [13:59 archangel:~] # dmraid -an nvidia_ecaejfdi [13:59 archangel:~] # l /dev/mapper total 0 drwxr-xr-x 2 root root 0 2009-06-22 13:44 . drwxr-xr-x 23 root root 0 2009-06-22 13:44 .. crw-rw---- 1 root root 10, 60 2009-06-22 01:40 control brw------- 1 root disk 254, 0 2009-06-22 13:48 nvidia_ecaejfdi brw------- 1 root disk 254, 2 2009-06-22 01:40 nvidia_ecaejfdip5 brw------- 1 root disk 254, 3 2009-06-22 01:40 nvidia_ecaejfdip6 brw------- 1 root disk 254, 4 2009-06-22 01:40 nvidia_ecaejfdip7 brw------- 1 root disk 254, 5 2009-06-22 01:40 nvidia_ecaejfdip8 brw------- 1 root disk 254, 10 2009-06-22 13:44 nvidia_ecaejfdip9 <snip> Huh??? Why wasn't nvidia_ecaejfdip9 deactivated. I have deleted the partition in cfdisk, tried to activate it (y) and deactivate it (n) and still it is there. Is this a bug? Or do I need to erase the metadata in some other way?? cc: Tobias -- 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

Re: [arch-general] [arch-dev-public] Preparing for libjpeg update
by Gerardo Exequiel Pozzi 23 Jun '09

23 Jun '09

Allan McRae wrote: > Hi all, > > This weekend should see the release of the first update for libjpeg in > several years. Everything remains API compatible so this should be > just a simple rebuild... of 130 packages from [extra]. That is too > many packages for any sane person and double the number of the > readline rebuilds so I will need some help. I will deal with the > packages that are needed as dependencies for many other packages > first. The full list is given below and I will create a TODO list > closer to the time so that we can keep track of what has been done. > > Given this is going to be a rather large rebuild, I will hold off > until the readline rebuilds are moved from [testing]. I guess these > can probably move before the weekend anyway. > > Allan > > > Rebuild list: > <snip> > ruby <snip> 129 :) Ruby don't depends on libjpeg bah, 130 because there are two versions of wxgtk :P And 83 in community: http://bugs.archlinux.org/task/15222 (sorted by maintainer and pkgname) Good Luck! -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

3 3

[arch-general] dmraid-1.0.0rc15 in testing, need you help on this!
by Tobias Powalowski 22 Jun '09

22 Jun '09

Hi guys, I put again a 1.0.0rc15 package to testing, i can't test it myself so i need you to help me on this. Is it true that name scheme changed from: name1 to namep1 for partitions? And how are your arrays named? Are your arrays assembled correct? Does everything work as before? Thanks for helping me on this, it will improve our dmraid support. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

5 14

Re: [arch-general] [arch-dev-public] [signoff] + help needed readline rebuilds
by Gerardo Exequiel Pozzi 22 Jun '09

22 Jun '09

Aaron Griffin wrote: > There are LOTS of packages in extra and community that need rebuilds. > The original output from Allan's script is as follows: > abiword-plugins > abook > afterstep > amule > bc > cdcd > clisp > ecasound > evms > fluidsynth > freeciv > fvwm > fvwm-devel > genius > gftp > gnokii > gnuchess > gnupg > gnupg2 > gnuplot > gnutls > gphoto2 > guile > gutenprint > hugs98 > jack-audio-connection-kit > kdeedu > koffice > lftp > libgda > libqalculate > librep > libxml2 > lua > maxima > mono-debugger > mysql-clients > ntp > ocfs2-tools > octave > pal > parted > php > pilot-link > postgresql > postgresql-libs > python > python24 > r > ruby > smbclient > socat > swi-prolog > texlive-bin > tftp-hpa > twinkle > uml_utilities > unixodbc > vice > wvstreams > xine-ui > These package don't use readline maxima mono-debugger koffice And these are missing in this list: mysql ratpoison I created a ticket for [community] http://bugs.archlinux.org/task/15165 -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

3 5

Re: [arch-general] [arch-dev-public] [signoff] + help needed readline rebuilds
by Gerardo Exequiel Pozzi 21 Jun '09

21 Jun '09

Pierre Schmitz wrote: > On Thursday 18 June 2009 18:12:05 Aaron Griffin wrote: > >> I'm going to slowly work through these throughout the day, but if >> someone can help, that'd be great. >> > > I think we're mostly done here. I am about to build kdeedu for i686 right now. > > Then only koffice is left, which should be updated to 2.0.1 at the same time. > > koffice don't depend on any of lib provided by readline (libreadline and libhistory) Anyway in this case, the update is only for new version :P Seems that this mail was not read by all (maxima and mono-debugger also was rebuilded) Gerardo Exequiel Pozzi wrote: > Aaron Griffin wrote: > >> There are LOTS of packages in extra and community that need rebuilds. >> The original output from Allan's script is as follows: >> >> <snip> > These package don't use readline > > maxima > mono-debugger > koffice > -- 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] [announcement] kernel26 2.6.30 announcement draft
by Tobias Powalowski 21 Jun '09

21 Jun '09

Hi arch community, The new 2.6.30 kernel series moved to the [core] repository. Upstream changes: http://kernelnewbies.org/LinuxChanges Arch Linux changes: - removed the acpi-dsdt-initramfs.patch There is no functional patch anymore available. If you need a custom dsdt, please compile it yourself into your custom kernel. - removed snd-pcspkr module #14958 - added dccp #15071 - added SCHED_DEBUG=y - changed to lzma kernel compression - removed rt2500 module it is supported by in kernel drivers now -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

[arch-general] deps not being properly recognized?
by Caleb Cushing 21 Jun '09

21 Jun '09

I can't figure out why pacman thinks that deps aren't being fulfilled. slave4 cpan # pacman -S perl-datetime warning: perl-datetime-0.50-1 is up to date -- reinstalling resolving dependencies... looking for inter-conflicts... Targets (1): perl-datetime-0.50-1 Total Download Size: 0.00 MB Total Installed Size: 0.29 MB Proceed with installation? [Y/n] Y checking package integrity... (1/1) checking for file conflicts [#####################] 100% (1/1) upgrading perl-datetime [#####################] 100% slave4 cpan # pacman -U perl-datetime-format-strptime/perl-datetime-format-strptime-1.0901-1-any.pkg.tar.gz loading package data... checking dependencies... error: failed to prepare transaction (could not satisfy dependencies) :: perl-datetime-format-strptime: requires perl-datetime>=0.4304 -- Caleb Cushing http://xenoterracide.blogspot.com

2 1