- Arch-general - lists.archlinux.org

[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