[arch-dev-public] [PATCH 2/2] Accept any *.pkg.tar.* package file name
With this patch packages with different compressions are accepted. It is ensured that one cannot have the same package with different compression extensions. The new functions getpkgfile{,s} are used to sanitize globed filenames. Signed-off-by: Pierre Schmitz <pierre@archlinux.de> --- config | 2 +- db-functions | 28 ++++++++++++++++++++++++++++ db-move | 8 +++----- db-update | 10 +++++----- 4 files changed, 37 insertions(+), 11 deletions(-) diff --git a/config b/config index 92def37..6343bc0 100644 --- a/config +++ b/config @@ -12,7 +12,7 @@ TMPDIR="/srv/tmp" ARCHES=(i686 x86_64) BUILDSCRIPT="PKGBUILD" DBEXT=".db.tar.gz" -PKGEXT=".pkg.tar.gz" +PKGEXT=".pkg.tar.*" SRCEXT=".src.tar.gz" # Allowed licenses: get sourceballs only for licenses in this array diff --git a/db-functions b/db-functions index a4cffd7..915d011 100644 --- a/db-functions +++ b/db-functions @@ -87,6 +87,34 @@ getpkgver() { echo "$_ver" } +getpkgfile() { + if [[ ${#} -ne 1 ]]; then + echo 'ERROR: No canonical package found!' + exit 1 + elif [ ! -f "${1}" ]; then + echo "ERROR: Package ${1} not found!" + exit 1 + fi + + return ${1} +} + +getpkgfiles() { + if [ ! -z "$(echo ${@%\.*} | sed "s/ /\n/g" | sort | uniq -D)" ]; then + echo 'ERROR: Duplicate packages found!' + exit 1 + fi + + for f in ${@}; do + if [ ! -f "${f}" ]; then + echo "ERROR: Package ${f} not found!" + exit 1 + fi + done + + return ${@} +} + check_pkg_arch () { #check_pkg_arch pkgfile arch local _arch _arch="$(_grep_pkginfo "$1" "^arch")" diff --git a/db-move b/db-move index efd54e0..d405ef3 100755 --- a/db-move +++ b/db-move @@ -59,9 +59,7 @@ if [ -d "$packagebase/repos/$svnrepo_from" ]; then for i in ${pkgname[@]}; do _pkgfile="$i-$pkgver-$pkgrel-$_arch$PKGEXT" - if [ ! -f "$ftppath_from/${_arch}/$_pkgfile" ]; then - die "error: package file '$_pkgfile' not found in repo '$repofrom'" - fi + getpkgfile "$ftppath_from/${_arch}/"$_pkgfile done if [ -d "$packagebase/repos/$svnrepo_to" ]; then @@ -101,13 +99,13 @@ if [ -d "$packagebase/repos/$svnrepo_from" ]; then for i in ${pkgname[@]}; do _pkgfile="$i-$pkgver-$pkgrel-$_arch$PKGEXT" - /bin/cp "$ftppath_from/$architecture/$_pkgfile" . + /bin/cp $(getpkgfile "$ftppath_from/$architecture/"$_pkgfile) . /usr/bin/repo-add -q "$repoto$DBEXT" $_pkgfile || die "Error in repo-add $_pkgfile" done #use '*' to move the old DB too mv $repoto$DBEXT* $ftppath_to/$architecture for i in ${pkgname[@]}; do - _pkgfile="$i-$pkgver-$pkgrel-$_arch$PKGEXT" + _pkgfile=$(getpkgfile "$i-$pkgver-$pkgrel-$_arch"$PKGEXT) if [ "${_arch}" == "any" ]; then mv ${_pkgfile} $ftppath_to/any ln -s ../any/${_pkgfile} $ftppath_to/$architecture/ diff --git a/db-update b/db-update index 17d3b71..fc2bac6 100755 --- a/db-update +++ b/db-update @@ -89,7 +89,7 @@ done # Process architecture-independent packages first. if [ -d "$stagedir" ]; then - ANYPKGS="$(/bin/ls $stagedir/*-any$PKGEXT 2>/dev/null)" + ANYPKGS="$(getpkgfiles $stagedir/*-any$PKGEXT)" fi mkdir -p $WORKDIR @@ -155,7 +155,7 @@ for current_arch in ${ARCHES[@]}; do to_add="" if [ -d "$stagedir" ]; then - ADDPKGS="$(/bin/ls $stagedir/*-${current_arch}$PKGEXT 2>/dev/null)" + ADDPKGS="$(getpkgfiles $stagedir/*-${current_arch}$PKGEXT)" fi if [ -n "$ADDPKGS" -o -n "$ANYPKGS" ]; then @@ -186,7 +186,7 @@ for current_arch in ${ARCHES[@]}; do /usr/bin/svn up -q $_pkgbase if [ -d "$_pkgbase/repos/$svnrepo" ]; then . "$_pkgbase/repos/$svnrepo/$BUILDSCRIPT" - if [ "$_pkgfile" = "$_pkgname-$pkgver-$pkgrel-$current_arch$PKGEXT" ]; then + if echo "$_pkgfile" | grep -q "$_pkgname-$pkgver-$pkgrel-$current_arch"; then to_add="$to_add $pkg" else echo " WARNING: $_pkgfile does not match $BUILDSCRIPT in $svnrepo" @@ -216,7 +216,7 @@ for current_arch in ${ARCHES[@]}; do # if non empty, move all build dirs if [ $(/bin/ls "$WORKDIR/build/" 2>/dev/null | wc -l) != 0 ]; then - if [ $(/bin/ls "$WORKDIR/build/"*-$current_arch$PKGEXT 2>/dev/null | wc -l) != 0 ]; then + if [ $(getpkgfiles "$WORKDIR/build/"*-$current_arch$PKGEXT | wc -l) != 0 ]; then echo "Copying new files to '$ftppath'" for f in "$WORKDIR/build/"*-$current_arch$PKGEXT; do if ! /bin/cp "$f" "$ftppath/"; then @@ -224,7 +224,7 @@ for current_arch in ${ARCHES[@]}; do fi done fi - if [ $(/bin/ls "$WORKDIR/build/"*-any$PKGEXT 2>/dev/null | wc -l) != 0 ]; then + if [ $(getpkgfiles "$WORKDIR/build/"*-any$PKGEXT | wc -l) != 0 ]; then echo "Copying new files to '$ftppath_any' and symlinking" for f in "$WORKDIR/build/"*-any$PKGEXT; do if ! /bin/cp "$f" "$ftppath_any"; then -- 1.6.6.1 -- Pierre Schmitz, https://users.archlinux.de/~pierre
Am Dienstag, 16. Februar 2010 01:27:32 schrieb Pierre Schmitz:
With this patch packages with different compressions are accepted. It is ensured that one cannot have the same package with different compression extensions.
The new functions getpkgfile{,s} are used to sanitize globed filenames.
So, here is some kind of draft to accept any package extension without using unsafe globing. I did not really test it and some parts are quite hacky. Please have a look. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Mon, Feb 15, 2010 at 19:29, Pierre Schmitz <pierre@archlinux.de> wrote:
So, here is some kind of draft to accept any package extension without using unsafe globing.
I did not really test it and some parts are quite hacky. Please have a look.
--
Pierre Schmitz, https://users.archlinux.de/~pierre
Looks clean to me, but I haven't tested it.
On 16/02/10 10:29, Pierre Schmitz wrote:
Am Dienstag, 16. Februar 2010 01:27:32 schrieb Pierre Schmitz:
With this patch packages with different compressions are accepted. It is ensured that one cannot have the same package with different compression extensions.
The new functions getpkgfile{,s} are used to sanitize globed filenames.
So, here is some kind of draft to accept any package extension without using unsafe globing.
I did not really test it and some parts are quite hacky. Please have a look.
It looks like it should work... the only way to really test these is to get an updated version on the server and try adding a few xz packages as a test. Allan
Am Dienstag, 16. Februar 2010 13:01:01 schrieb Allan McRae:
the only way to really test these is to get an updated version on the server and try adding a few xz packages as a test.
I think I could do that with a new devtools release into testing. Even if the package will be broken, only we were suffered by this issue. The cleanup script shouldn't do anything to that package as it only looks for *.pkg.tar.gz. Any objections? -- Pierre Schmitz, https://users.archlinux.de/~pierre
Am Dienstag, 16. Februar 2010 01:27:32 schrieb Pierre Schmitz:
With this patch packages with different compressions are accepted. It is ensured that one cannot have the same package with different compression extensions.
The new functions getpkgfile{,s} are used to sanitize globed filenames.
After a few tests with a local repo I guess I am ready to submit my changes. So, here is the plan: 1) Add me to the dbscripts-git group and let me push my patch to the repo 2) Checkout the scripts into /arch or /arch-new (to be discussed) 3) Check which packages need to be kept in gz format for a while.(is it just pacman, libarchive and xz-utils) and add PKGEXT='.pkg.tar.gz' into their PKGBUILDs 4) Start packaging xz compressed packages 5) Should we ask everyone to set PKGEXT to .pkg.tar.xz in makepkg.conf and probably ship it as default? 6) Apply the same changes on sigurd (community server) -- Pierre Schmitz, https://users.archlinux.de/~pierre
Am 21.02.2010 08:47, schrieb Pierre Schmitz:
Am Dienstag, 16. Februar 2010 01:27:32 schrieb Pierre Schmitz:
With this patch packages with different compressions are accepted. It is ensured that one cannot have the same package with different compression extensions.
The new functions getpkgfile{,s} are used to sanitize globed filenames.
After a few tests with a local repo I guess I am ready to submit my changes. So, here is the plan:
1) Add me to the dbscripts-git group and let me push my patch to the repo
Done.
2) Checkout the scripts into /arch or /arch-new (to be discussed)
You say you tested it, so I say /arch. Objections?
3) Check which packages need to be kept in gz format for a while.(is it just pacman, libarchive and xz-utils) and add PKGEXT='.pkg.tar.gz' into their PKGBUILDs
Disregard the bash part below (bash can be any older version). |--pacman |--bash |--readline |--ncurses |--libarchive |--zlib |--bzip2 |--xz-utils |--bash |--acl |--attr |--openssl |--zlib |--perl |--gdbm |--db |--gcc-libs +--bash provides sh |--coreutils |--shadow |--pam |--db |--cracklib |--zlib |--pam |--acl |--gmp |--gcc-libs |--libcap |--attr +--bash provides sh |--expat |--libfetch |--openssl |--pacman-mirrorlist
4) Start packaging xz compressed packages 5) Should we ask everyone to set PKGEXT to .pkg.tar.xz in makepkg.conf and probably ship it as default? 6) Apply the same changes on sigurd (community server)
+1
Am 21.02.2010 14:50, schrieb Thomas Bächler:
3) Check which packages need to be kept in gz format for a while.(is it just pacman, libarchive and xz-utils) and add PKGEXT='.pkg.tar.gz' into their PKGBUILDs
Disregard the bash part below (bash can be any older version).
|--pacman |--bash |--readline |--ncurses |--libarchive |--zlib |--bzip2 |--xz-utils |--bash |--acl |--attr |--openssl |--zlib |--perl |--gdbm |--db |--gcc-libs +--bash provides sh |--coreutils |--shadow |--pam |--db |--cracklib |--zlib |--pam |--acl |--gmp |--gcc-libs |--libcap |--attr +--bash provides sh |--expat |--libfetch |--openssl |--pacman-mirrorlist
Hmm, glibc is missing here. We can probably also omit perl, as openssl doesn't really need it to be up to date to function with pacman.
On 21/02/10 23:50, Thomas Bächler wrote:
Am 21.02.2010 08:47, schrieb Pierre Schmitz:
2) Checkout the scripts into /arch or /arch-new (to be discussed)
You say you tested it, so I say /arch. Objections?
/arch-new gives a fallback if necessary. Fallbacks are good with db-scripts...
3) Check which packages need to be kept in gz format for a while.(is it just pacman, libarchive and xz-utils) and add PKGEXT='.pkg.tar.gz' into their PKGBUILDs
Disregard the bash part below (bash can be any older version).
|--pacman |--bash |--readline |--ncurses |--libarchive |--zlib |--bzip2 |--xz-utils |--bash |--acl |--attr |--openssl |--zlib |--perl |--gdbm |--db |--gcc-libs +--bash provides sh |--coreutils |--shadow |--pam |--db |--cracklib |--zlib |--pam |--acl |--gmp |--gcc-libs |--libcap |--attr +--bash provides sh |--expat |--libfetch |--openssl |--pacman-mirrorlist
The use of --as-needed means we do not need all these. So the list is somewhere between this and the one Pierre gave... has anyone got a really old system we can test this upgrade on? I suppose an old installer is enough. Allan
Am Sonntag, 21. Februar 2010 15:10:12 schrieb Allan McRae:
/arch-new gives a fallback if necessary. Fallbacks are good with db-scripts...
Fair enough. Could anyone fix the permissinos of /arch and create /arch-new with the same? The dbscripts-git group should have g+s permissions here.
3) Check which packages need to be kept in gz format for a while.(is it just
pacman, libarchive and xz-utils) and add PKGEXT='.pkg.tar.gz' into their PKGBUILDs
The use of --as-needed means we do not need all these. So the list is somewhere between this and the one Pierre gave... has anyone got a really old system we can test this upgrade on? I suppose an old installer is enough.
I'll check that. -- Pierre Schmitz, https://users.archlinux.de/~pierre
Am Sonntag, 21. Februar 2010 15:57:38 schrieb Pierre Schmitz:
pacman, libarchive and xz-utils) and add PKGEXT='.pkg.tar.gz' into their PKGBUILDs
The use of --as-needed means we do not need all these. So the list is somewhere between this and the one Pierre gave... has anyone got a really old system we can test this upgrade on? I suppose an old installer is enough.
I'll check that.
I booted a 2009.02 iso which doesn't know about xz and run -Syu. It'll update xz-utils, libarchive, libfetch and pacman. So we should be fine with keeping those in gz archives for a while. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Sun, Feb 21, 2010 at 16:10, Allan McRae <allan@archlinux.org> wrote:
The use of --as-needed means we do not need all these. So the list is somewhere between this and the one Pierre gave... has anyone got a really old system we can test this upgrade on? I suppose an old installer is enough.
I had a VPS with 0.8 (!) installed on it, but it should update pacman first anyway (and everyone should stay away from a provider that offers VPSes with 0.8 preinstalled :-P). -- Roman Kyrylych (Роман Кирилич)
Am 22.02.2010 10:42, schrieb Roman Kyrylych:
On Sun, Feb 21, 2010 at 16:10, Allan McRae <allan@archlinux.org> wrote:
The use of --as-needed means we do not need all these. So the list is somewhere between this and the one Pierre gave... has anyone got a really old system we can test this upgrade on? I suppose an old installer is enough.
I had a VPS with 0.8 (!) installed on it, but it should update pacman first anyway (and everyone should stay away from a provider that offers VPSes with 0.8 preinstalled :-P).
But you'd also need a glibc update, which would require a kernel update, so you're basically screwed.
Am Sonntag, 21. Februar 2010 08:47:27 schrieb Pierre Schmitz:
After a few tests with a local repo I guess I am ready to submit my changes. So, here is the plan:
1) Add me to the dbscripts-git group and let me push my patch to the repo 2) Checkout the scripts into /arch or /arch-new (to be discussed) 3) Check which packages need to be kept in gz format for a while.(is it just pacman, libarchive and xz-utils) and add PKGEXT='.pkg.tar.gz' into their PKGBUILDs 4) Start packaging xz compressed packages 5) Should we ask everyone to set PKGEXT to .pkg.tar.xz in makepkg.conf and probably ship it as default? 6) Apply the same changes on sigurd (community server)
Thomas has added the new scripts to /arch-new The devtools pacakge in testing is the first xz compressed package. Everybody say hurray! If you upload xz packages with the devtools make sure PKGEXT in your makpekg.conf is set to .pkg.tar.xz. PS: we figured out that the dbscripts on sigurd are quite outdated and thus wont remove old packages. So this will be fixed once we update those, too. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Sun, Feb 21, 2010 at 4:26 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Sonntag, 21. Februar 2010 08:47:27 schrieb Pierre Schmitz:
After a few tests with a local repo I guess I am ready to submit my changes. So, here is the plan:
1) Add me to the dbscripts-git group and let me push my patch to the repo 2) Checkout the scripts into /arch or /arch-new (to be discussed) 3) Check which packages need to be kept in gz format for a while.(is it just pacman, libarchive and xz-utils) and add PKGEXT='.pkg.tar.gz' into their PKGBUILDs 4) Start packaging xz compressed packages 5) Should we ask everyone to set PKGEXT to .pkg.tar.xz in makepkg.conf and probably ship it as default? 6) Apply the same changes on sigurd (community server)
Thomas has added the new scripts to /arch-new The devtools pacakge in testing is the first xz compressed package. Everybody say hurray!
If you upload xz packages with the devtools make sure PKGEXT in your makpekg.conf is set to .pkg.tar.xz.
PS: we figured out that the dbscripts on sigurd are quite outdated and thus wont remove old packages. So this will be fixed once we update those, too.
--
Pierre Schmitz, https://users.archlinux.de/~pierre
There seem to be problems (archrelease) with the new devtools package. First when building a i686 package for doxygen, my connection quitted during the process: $ extrapkg committing changes to trunk...done uploading doxygen-1.6.3-1-i686.pkg.tar.xz 1.33M 100% 88.11MB/s 0:00:00 (xfer#1, to-check=0/1) sent 1.33M bytes received 31 bytes 48.23K bytes/sec total size is 1.33M speedup is 1.00 releasing package...svn: Network connection closed unexpectedly done skipping x86_64 I reran extrapkg, thinking that it would work this time but it didn't: $ extrapkg committing changes to trunk...done uploading sent 68 bytes received 12 bytes 53.33 bytes/sec total size is 1.33M speedup is 16577.30 releasing package.../usr/bin/archrelease: line 29: [[: -1M: value too great for base (error token is "1M") svn: In directory 'repos' svn: Error processing command 'modify-entry' in 'repos' svn: Error modifying entry for 'extra-i686' svn: 'extra-i686' is not under version control svn: Working copy '/home/eric/svnroot/doxygen/repos' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) svn: Can't add 'repos/extra-i686/trunk' to a parent directory scheduled for deletion svn: Working copy '/home/eric/svnroot/doxygen/repos' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) done skipping x86_64 I don't know what happened but I had a copy of trunk in repos/extra-i686. I thought that it was a fluke because of the network glitch so I did a new checkout and did the copying/commit by hand. Now with another package (ecasound), it doesn't release at all: $ extrapkg "Upstream update, Improved description" committing changes to trunk...done uploading sent 69 bytes received 12 bytes 54.00 bytes/sec total size is 1.05M speedup is 12930.17 releasing package...already done Cancelled I don't know why it says "already done" because that was the first time that I ran extrapkg so it defenitely not done. I'll probably need to do it by hand. Another thing: it was mentionned on the IRC channel that namcap doesn't work with the new xz packages. It would be nice to have xz support in namcap before we start pushing these changes out.
On Sun, Feb 21, 2010 at 10:05 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
Another thing: it was mentionned on the IRC channel that namcap doesn't work with the new xz packages. It would be nice to have xz support in namcap before we start pushing these changes out.
Yeah, this is IMHO a blocker to going gung-ho on this. It is not going to be super-easy either as we use python's built-in archive support that doesn't know about XZ as far as I know... -Dan
Am Montag, 22. Februar 2010 05:24:50 schrieb Dan McGee:
On Sun, Feb 21, 2010 at 10:05 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
Another thing: it was mentionned on the IRC channel that namcap doesn't work with the new xz packages. It would be nice to have xz support in namcap before we start pushing these changes out.
Yeah, this is IMHO a blocker to going gung-ho on this. It is not going to be super-easy either as we use python's built-in archive support that doesn't know about XZ as far as I know...
Why not? Just call bsdtar to extract the tar somewhere. This way you don#t have to worry how the package is compressed. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Sun, Feb 21, 2010 at 10:27 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Montag, 22. Februar 2010 05:24:50 schrieb Dan McGee:
On Sun, Feb 21, 2010 at 10:05 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
Another thing: it was mentionned on the IRC channel that namcap doesn't work with the new xz packages. It would be nice to have xz support in namcap before we start pushing these changes out.
Yeah, this is IMHO a blocker to going gung-ho on this. It is not going to be super-easy either as we use python's built-in archive support that doesn't know about XZ as far as I know...
Why not? Just call bsdtar to extract the tar somewhere. This way you don#t have to worry how the package is compressed.
Maybe you can get away with this in a shell script, but no one is happy with this BS in a python program. Or at least I wouldn't be, but feel free to send a patch to the namcap maintainer since it is so easy. I'll be impressed when you fix every check that uses tar.getmembers() too... -Dan
Am Montag, 22. Februar 2010 05:33:56 schrieb Dan McGee:
Another thing: it was mentionned on the IRC channel that namcap doesn't work with the new xz packages. It would be nice to have xz support in namcap before we start pushing these changes out.
Yeah, this is IMHO a blocker to going gung-ho on this. It is not going to be super-easy either as we use python's built-in archive support that doesn't know about XZ as far as I know...
Why not? Just call bsdtar to extract the tar somewhere. This way you don#t have to worry how the package is compressed.
Maybe you can get away with this in a shell script, but no one is happy with this BS in a python program. Or at least I wouldn't be, but feel free to send a patch to the namcap maintainer since it is so easy. I'll be impressed when you fix every check that uses tar.getmembers() too...
What's wrong with you? That was meant as a serious question. I am not familiar with the namcap python code. I don't really want to drop the idea of xz compressed packages just because python does not support it. It might sound silly but the probably easiest solution might be to modify namcap to support uncompressed tar archives. Then we can add a simple Bash wrapper script which uncompresses the package and calls namcap with the pure tar. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Mon, 2010-02-22 at 06:15 +0100, Pierre Schmitz wrote:
It might sound silly but the probably easiest solution might be to modify namcap to support uncompressed tar archives. Then we can add a simple Bash wrapper script which uncompresses the package and calls namcap with the pure tar.
+1 for now. Namcap uses the Tarfile module, which supports tarfiles, either uncompressed or compressed by gzip or bzip2. It would be nice if namcap would accept packages from stdin, as you can just xzcat the package in that case.
On 22/02/10 14:24, Dan McGee wrote:
On Sun, Feb 21, 2010 at 10:05 PM, Eric Bélanger<snowmaniscool@gmail.com> wrote:
Another thing: it was mentionned on the IRC channel that namcap doesn't work with the new xz packages. It would be nice to have xz support in namcap before we start pushing these changes out.
Yeah, this is IMHO a blocker to going gung-ho on this. It is not going to be super-easy either as we use python's built-in archive support that doesn't know about XZ as far as I know...
Correct: http://bugs.python.org/issue6715
Am Montag, 22. Februar 2010 05:05:26 schrieb Eric Bélanger:
I don't know why it says "already done" because that was the first time that I ran extrapkg so it defenitely not done. I'll probably need to do it by hand.
The last one was some kind of bug as archrelease shouldn't call exit 1 on "already done" as this would stop commitpkg. I hopefully have fixed this in git and also added a check which might help in your first case where the local svn repo is kind of messed up. The relevant commit is http://projects.archlinux.org/devtools.git/commit/?id=2fe5dbf904d8ded1299fc2... -- Pierre Schmitz, https://users.archlinux.de/~pierre
Am Sonntag, 21. Februar 2010 08:47:27 schrieb Pierre Schmitz:
1) Add me to the dbscripts-git group and let me push my patch to the repo 2) Checkout the scripts into /arch or /arch-new (to be discussed) 3) Check which packages need to be kept in gz format for a while.(is it just pacman, libarchive and xz-utils) and add PKGEXT='.pkg.tar.gz' into their PKGBUILDs 4) Start packaging xz compressed packages 5) Should we ask everyone to set PKGEXT to .pkg.tar.xz in makepkg.conf and probably ship it as default? 6) Apply the same changes on sigurd (community server)
Step 1 to 4 are done by now. We have some xz packages in the repos and the scripts seem to work. So,what about updating the scripts in /arch and on sigurd? -- Pierre Schmitz, https://users.archlinux.de/~pierre
participants (8)
-
Allan McRae
-
Daenyth Blank
-
Dan McGee
-
Eric Bélanger
-
Jan de Groot
-
Pierre Schmitz
-
Roman Kyrylych
-
Thomas Bächler