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

[arch-dev-public] [signoff] dmapi 2.2.10-1
by Tobias Powalowski 14 May '09

14 May '09

Hi update to latest version, please signoff for both arches. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 1

[arch-dev-public] [PATCH] use pkgext defined in makepkg.conf
by Pierre Schmitz 13 May '09

13 May '09

Here is some similar patch for our dbscripts. This is also completly untested. Note: this does not support mixing of different pkgext types; so for a possible transition from e.g. gz to xz another workaround is needed to support both. -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre(a)jabber.archlinux.de WWW http://www.archlinux.de

2 3

[arch-dev-public] [PATCH] use pkext defined in makepkg.conf
by Pierre Schmitz 13 May '09

13 May '09

Here is a patch for devtools to use pkgext defined in makepkg.conf instead of hard coded tar.gz. This should make it possible to use something else in future. Pierre -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre(a)jabber.archlinux.de WWW http://www.archlinux.de

2 1

[arch-dev-public] [signoff] findutils 4.4.1-2
by Tobias Powalowski 13 May '09

13 May '09

Hi fixes scriptlet error: http://bugs.archlinux.org/task/14687 greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 3

[arch-dev-public] [signoff] dcron-3.2-4
by Tobias Powalowski 13 May '09

13 May '09

Hi fixed manpath: http://bugs.archlinux.org/task/13764 greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 1

[arch-dev-public] [signoff] sysfsutils 2.1.0-5
by Tobias Powalowski 13 May '09

13 May '09

Hi fixed manpath: http://bugs.archlinux.org/task/13764 greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 2

Re: [arch-dev-public] Status of arch=any ?
by Firmicus 12 May '09

12 May '09

Aaron Griffin: > I made a few small changes and pushed them to git. I have not fully > committed all of the db-update changes, as I'm not entirely sure why > some of these changes were made - for instance: why was the pkglisting > broken out to the top of the file? > > It seems I had forgotten to reply to the above! Sorry. The current dev version of db-update will stop with errors if, for at least one of the three arch categories, no package is present under $staging. In other words, if you run it and there are N packages for arch=any, but none for arch=i686, for instance. The script attempts to copy files for each arch, but if none is there, cp returns an error and db-update will die. I send you a patch to fix that by checking first for the existence of at least one package before attempting to copy it to the ftp tree. I'm also sending you three additional patches: a second one to create the $WORKDIR before cd'ing to it, a third one that fixes an obvious bug in the creation of symlinks, and a fourth one to fix the incorrect redirection of error messages for get_svnpath in db-functions. Hope it helps... > Regarding the new convert2any script you added - I'd prefer to fix the > existing script rather than add a new one - or at least preserve some > of the logic (such as sourcing of makepkg.conf) > > All right, perhaps Abhishek can do that? ;) F

2 1

Re: [arch-dev-public] [arch-general] LZMA - in or out? ([signoff] libarchive 2.6.0 )
by Pierre Schmitz 12 May '09

12 May '09

Am Dienstag, 12. Mai 2009 09:00:30 schrieb Pierre Schmitz: > I am just doing some very simple test right now. (default compression > preset) > > core (x86_64) (decompress time) > none 552M > gzip 186M 12s > xz 121M 17s And here are the numbers for extra; a lot more intersting imho: extra (x86_64) none 13,8G gzip 5,5G 10min xz 4,1G 11min -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre(a)jabber.archlinux.de WWW http://www.archlinux.de

1 0

Re: [arch-dev-public] [arch-general] New vi/vim/gvim in testing requires intervention
by Dan McGee 12 May '09

12 May '09

On Tue, May 12, 2009 at 2:19 AM, Tobias Kieslich <tobias(a)justdreams.de> wrote: > On Tue, 12 May 2009, Magnus Therning wrote: >>>> And a quick guess, it looks like the new vim package puts its colors here: >>>> /usr/share/vim/vim72/colors/ >>>> >>>> Any reason the old /usr/share/vim/ shouldn't be on the default runtimepath? >> >> Looking at other distros it seems using /usr/share/vim/vimX is the place >> for system-wide configurations. Not saying that's right or wrong. > > Well, I tied up quite a few requests into the new vim packages. Becuase > we serve the runtime files with one package(vim) and have other > packages(gvim) depend on it, I used to set the runtime path explicitely. > Users told me that causes vim to search always in two pathes(the > explicite one AND the default one). Hence I started toi stick with the > default path, which is /usr/share/vim/vimxy. > > That means all plugins need to be rebuild and some users that set fixed > pathes in .vimrc will have to adjust. Looks like we have a new rebuild list then: $ pacman -Sqs vim- gvim vim-a vim-bufexplorer vim-buftabs vim-colorsamplerpack vim-doxygentoolkit vim-guicolorscheme vim-matchit vim-minibufexpl vim-omnicppcomplete vim-project vim-taglist vim-vcscommand vim-workspace vim-pastie vim-rails vim-supertab vim-surround vim-timestamp vimpager Why the heck gvim and vimpager showed up in there I'm not sure, but the above plugin packages probably all use the default location. We should additionally make sure they depend on 'vim' and not 'vi', as I rebuilt two or three plugins already that made the assumption they were one and the same. -Dan

1 0

[arch-dev-public] LZMA - in or out? ([signoff] libarchive 2.6.0)
by Dan McGee 12 May '09

12 May '09

On Sat, Jan 3, 2009 at 6:00 AM, Andreas Radke <a.radke(a)arcor.de> wrote: > I'd like to keep unneeded packages out of core. I see no need to move > lzma into core. We only support tar.gz for our repos. Whoever wants to > use a different format can rebuild libarchive easily. > > I also wonder if our new tar package now supports lzma and lzop > compression (no tests so far). Both packages were not present when > building the tar package in he chroot. But even when it's now possible > to use these formats at runtime they should stay in extra until we may > use them for our repos. I don't want to go too back and forth on this on the signoff thread so I'll move it here. I was thinking much more in the context of archives in general rather than just pacman using libarchive. libarchive ships with bsdtar, which I have found to be quicker than GNU tar at extracting (so I use it nearly exclusively). It would be a shame to tell people "we don't support .tar.lzma for anything"- that seems rather arbitrary, doesn't it? I too think [core] should stay as slim as possible, but when that requires we compile our packages with a less than ideal set of features, I want to at least give it some thought. -Dan

11 23