These changes are done on top of http://mailman.archlinux.org/pipermail/arch-general/2009-September/007635.ht...
--- commitpkg | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/commitpkg b/commitpkg index a8bff51..5abc088 100755 --- a/commitpkg +++ b/commitpkg @@ -88,14 +88,14 @@ for CARCH in ${arch[@]}; do
if [ "$1" != "" ]; then svn commit -m "upgpkg: $pkgbase $pkgver-$pkgrel - $1" > /dev/null + $1" > /dev/null if [ $? -ne 0 ]; then echo "Cancelled" exit 1 fi echo "===> Commited with message: upgpkg: $pkgbase $pkgver-$pkgrel - $1" + $1" else svn commit if [ $? -ne 0 ]; then
--- commitpkg | 42 +++++++++++++----------------------------- 1 files changed, 13 insertions(+), 29 deletions(-)
diff --git a/commitpkg b/commitpkg index 5abc088..ba98490 100755 --- a/commitpkg +++ b/commitpkg @@ -1,11 +1,15 @@ #!/bin/bash
+abort() { + echo ${1:-"Cancelled"} + exit 1 +} + # Source makepkg.conf; fail if it is not found if [ -r "/etc/makepkg.conf" ]; then source "/etc/makepkg.conf" else - echo "/etc/makepkg.conf not found!" - exit 1 + abort "/etc/makepkg.conf not found!" fi
# Source user-specific makepkg.conf overrides @@ -16,8 +20,7 @@ fi cmd=$(basename $0)
if [ ! -f PKGBUILD ]; then - echo "No PKGBUILD file" - exit 1 + abort "No PKGBUILD file" fi
source PKGBUILD @@ -39,8 +42,7 @@ elif [ "$cmd" == "community-testingpkg" ]; then server="aur.archlinux.org" else if [ $# -eq 0 ]; then - echo "usage: commitpkg <reponame> [-l limit] [commit message]" - exit 1 + abort "usage: commitpkg <reponame> [-l limit] [commit message]" fi repo="$1" shift @@ -70,46 +72,28 @@ for CARCH in ${arch[@]}; do uploadto="staging/${repo}/$(basename ${pkgfile})" # don't re-upload the same package (useful for -any sub packages) if [ "$(md5sum "${pkgfile}" | cut -d' ' -f1)" != "$(ssh ${server} md5sum "${uploadto}" | cut -d' ' -f1)" ]; then - scp ${scpopts} "${pkgfile}" "${server}:${uploadto}" + scp ${scpopts} "${pkgfile}" "${server}:${uploadto}" || abort fi if [ "$(md5sum "${pkgfile}" | cut -d' ' -f1)" != "$(ssh ${server} md5sum "${uploadto}" | cut -d' ' -f1)" ]; then - echo "File got corrupted during upload, cancelled." - exit 1 + abort "File got corrupted during upload, cancelled." else echo "File integrity okay." fi - - if [ $? -ne 0 ]; then - echo "Cancelled" - exit 1 - fi echo "===> Uploaded $pkgfile" done
if [ "$1" != "" ]; then svn commit -m "upgpkg: $pkgbase $pkgver-$pkgrel - $1" > /dev/null - if [ $? -ne 0 ]; then - echo "Cancelled" - exit 1 - fi + $1" > /dev/null || abort echo "===> Commited with message: upgpkg: $pkgbase $pkgver-$pkgrel $1" else - svn commit - if [ $? -ne 0 ]; then - echo "Cancelled" - exit 1 - fi + svn commit || abort echo "===> Commited" fi
- archrelease $repo-$CARCH - if [ $? -ne 0 ]; then - echo "Cancelled" - exit 1 - fi + archrelease $repo-$CARCH || abort echo "===> Tagged for $repo-$CARCH" done
On Wed, Sep 23, 2009 at 1:04 PM, Evangelos Foutras foutrelis@gmail.com wrote:
These changes are done on top of http://mailman.archlinux.org/pipermail/arch-general/2009-September/007635.ht...
I pushed all of your patches. The last one didn't apply cleanly, so I had to do some tweaking. It was most likely related to me removing trailing whitespace from the svn spacing commit.
Thanks a lot!
Aaron Griffin wrote:
On Wed, Sep 23, 2009 at 1:04 PM, Evangelos Foutras foutrelis@gmail.com wrote: I pushed all of your patches. The last one didn't apply cleanly, so I had to do some tweaking. It was most likely related to me removing trailing whitespace from the svn spacing commit.
Thanks a lot!
Thanks for applying the patches to devtools.
I have a question. Currently, sub packages can't have a different architecture field than the main package. Are there plans to add this possibility in the future? This could come in handy with packages that have huge data files that are architecture independent and can be split into a sub package with arch=('any').
I'm mainly asking because if the above gets implemented, commitpkg will need to be slightly modified in order to be able to locate -any sub packages (and I have a feeling that it was able to do this before my patches were applied :d ).
On Wed, Sep 23, 2009 at 2:53 PM, Evangelos Foutras foutrelis@gmail.com wrote:
Aaron Griffin wrote:
On Wed, Sep 23, 2009 at 1:04 PM, Evangelos Foutras foutrelis@gmail.com wrote: I pushed all of your patches. The last one didn't apply cleanly, so I had to do some tweaking. It was most likely related to me removing trailing whitespace from the svn spacing commit.
Thanks a lot!
Thanks for applying the patches to devtools.
I have a question. Currently, sub packages can't have a different architecture field than the main package. Are there plans to add this possibility in the future? This could come in handy with packages that have huge data files that are architecture independent and can be split into a sub package with arch=('any').
I'm mainly asking because if the above gets implemented, commitpkg will need to be slightly modified in order to be able to locate -any sub packages (and I have a feeling that it was able to do this before my patches were applied :d ).
Actually, we might even be able to ignore the arch=() field for purposes of uploading here. We could just loop over a hardcoded list of architectures (let's face it, these won't be changing regularly). The dbscripts do something similar - there is an ARCHES=(i686 x86_64) array, and some (not all) for loops do: for _arch in ${ARCHES[@]} any; do ... done
Aaron Griffin wrote:
Actually, we might even be able to ignore the arch=() field for purposes of uploading here. We could just loop over a hardcoded list of architectures (let's face it, these won't be changing regularly). The dbscripts do something similar - there is an ARCHES=(i686 x86_64) array, and some (not all) for loops do: for _arch in ${ARCHES[@]} any; do ... done
Maybe I'm over-thinking it and missing a simpler solution. I'm trying to be as explicit as possible, in order to avoid uploading any unneeded or wrong packages that, for whatever reason, may exist in the same directory where commitpkg is run. Another crucial point is that archrelease must not be executed (for the currently examined repo) if not all packages are present and uploaded.
At any rate, I think we'll have to retrieve sub package variables in the foreseeable future, when this gets implemented: http://bugs.archlinux.org/task/15955. It certainly looks tricky though, as the variables are overridden in package_*() functions which contain other commands as well.
On Wed, Sep 23, 2009 at 4:04 PM, Evangelos Foutras foutrelis@gmail.com wrote:
Aaron Griffin wrote:
Actually, we might even be able to ignore the arch=() field for purposes of uploading here. We could just loop over a hardcoded list of architectures (let's face it, these won't be changing regularly). The dbscripts do something similar - there is an ARCHES=(i686 x86_64) array, and some (not all) for loops do: for _arch in ${ARCHES[@]} any; do ... done
Maybe I'm over-thinking it and missing a simpler solution. I'm trying to be as explicit as possible, in order to avoid uploading any unneeded or wrong packages that, for whatever reason, may exist in the same directory where commitpkg is run. Another crucial point is that archrelease must not be executed (for the currently examined repo) if not all packages are present and uploaded.
I was thinking solely for the purpose of uploading. The db scripts will verify things on the later end. My thoughts didn't extend to the execution of archrelease
At any rate, I think we'll have to retrieve sub package variables in the foreseeable future, when this gets implemented: http://bugs.archlinux.org/task/15955. It certainly looks tricky though, as the variables are overridden in package_*() functions which contain other commands as well.
Yeah this seems a ways off anyway :)
On Wed, Sep 23, 2009 at 11:04 PM, Evangelos Foutras foutrelis@gmail.com wrote:
At any rate, I think we'll have to retrieve sub package variables in the foreseeable future, when this gets implemented: http://bugs.archlinux.org/task/15955. It certainly looks tricky though, as the variables are overridden in package_*() functions which contain other commands as well.
Yeah, I had this problem with check_packages script. Here is the ugly hack I wrote to do it : http://projects.archlinux.org/?p=dbscripts.git;a=commitdiff;h=d455a0b2cd72cd...
On Wed, Sep 23, 2009 at 3:53 PM, Evangelos Foutras foutrelis@gmail.com wrote:
Aaron Griffin wrote:
On Wed, Sep 23, 2009 at 1:04 PM, Evangelos Foutras foutrelis@gmail.com wrote: I pushed all of your patches. The last one didn't apply cleanly, so I had to do some tweaking. It was most likely related to me removing trailing whitespace from the svn spacing commit.
Thanks a lot!
Thanks for applying the patches to devtools.
I have a question. Currently, sub packages can't have a different architecture field than the main package. Are there plans to add this possibility in the future? This could come in handy with packages that have huge data files that are architecture independent and can be split into a sub package with arch=('any').
I'm mainly asking because if the above gets implemented, commitpkg will need to be slightly modified in order to be able to locate -any sub packages (and I have a feeling that it was able to do this before my patches were applied :d ).
There's already a feature request in flyspray: http://bugs.archlinux.org/task/15955
Eric Bélanger wrote:
On Wed, Sep 23, 2009 at 3:53 PM, Evangelos Foutras foutrelis@gmail.com wrote:
Aaron Griffin wrote:
On Wed, Sep 23, 2009 at 1:04 PM, Evangelos Foutras foutrelis@gmail.com wrote: I pushed all of your patches. The last one didn't apply cleanly, so I had to do some tweaking. It was most likely related to me removing trailing whitespace from the svn spacing commit.
Thanks a lot!
Thanks for applying the patches to devtools.
I have a question. Currently, sub packages can't have a different architecture field than the main package. Are there plans to add this possibility in the future? This could come in handy with packages that have huge data files that are architecture independent and can be split into a sub package with arch=('any').
I'm mainly asking because if the above gets implemented, commitpkg will need to be slightly modified in order to be able to locate -any sub packages (and I have a feeling that it was able to do this before my patches were applied :d ).
There's already a feature request in flyspray: http://bugs.archlinux.org/task/15955
I see. So there will be in total three variables that can be overridden in a sub package that affect its final filename; pkgver, pkgrel, and arch. Finding those variables before defining pkgfile as "${_pkgname}-${pkgver}-${pkgrel}-${CARCH}${PKGEXT}" should allow commitpkg to cope with these sub packages.
Hmmm, this definitely needs some more thinking. :)
Evangelos Foutras a écrit :
Eric Bélanger wrote:
On Wed, Sep 23, 2009 at 3:53 PM, Evangelos Foutras foutrelis@gmail.com wrote:
Aaron Griffin wrote:
On Wed, Sep 23, 2009 at 1:04 PM, Evangelos Foutras foutrelis@gmail.com wrote: I pushed all of your patches. The last one didn't apply cleanly, so I had to do some tweaking. It was most likely related to me removing trailing whitespace from the svn spacing commit.
Thanks a lot!
Thanks for applying the patches to devtools.
I have a question. Currently, sub packages can't have a different architecture field than the main package. Are there plans to add this possibility in the future? This could come in handy with packages that have huge data files that are architecture independent and can be split into a sub package with arch=('any').
I'm mainly asking because if the above gets implemented, commitpkg will need to be slightly modified in order to be able to locate -any sub packages (and I have a feeling that it was able to do this before my patches were applied :d ).
There's already a feature request in flyspray: http://bugs.archlinux.org/task/15955
I see. So there will be in total three variables that can be overridden in a sub package that affect its final filename; pkgver, pkgrel, and arch. Finding those variables before defining pkgfile as "${_pkgname}-${pkgver}-${pkgrel}-${CARCH}${PKGEXT}" should allow commitpkg to cope with these sub packages.
Hmmm, this definitely needs some more thinking. :)
Funny, I was thinking of all these things yesterday too...
I have also restructured commitpkg and co. quite a bit, and wanted to send a bunch of 8 patches, but Evangelos was faster :) Now I cannot easily rebase my branch, if at all :) Well, I now think I'll rather setup my own git repo for devtools instead, and I'll send pull requests to Aaron from time to time. That's more convenient than flooding the ML with patches.
I have some ideas for refactoring devtools. I'll wikify them soon and will report back ;)
F
On Thu, Sep 24, 2009 at 5:42 PM, Firmicus Firmicus@gmx.net wrote:
Evangelos Foutras a écrit :
Eric Bélanger wrote:
On Wed, Sep 23, 2009 at 3:53 PM, Evangelos Foutras foutrelis@gmail.com wrote:
Aaron Griffin wrote:
On Wed, Sep 23, 2009 at 1:04 PM, Evangelos Foutras foutrelis@gmail.com wrote: I pushed all of your patches. The last one didn't apply cleanly, so I had to do some tweaking. It was most likely related to me removing trailing whitespace from the svn spacing commit.
Thanks a lot!
Thanks for applying the patches to devtools.
I have a question. Currently, sub packages can't have a different architecture field than the main package. Are there plans to add this possibility in the future? This could come in handy with packages that have huge data files that are architecture independent and can be split into a sub package with arch=('any').
I'm mainly asking because if the above gets implemented, commitpkg will need to be slightly modified in order to be able to locate -any sub packages (and I have a feeling that it was able to do this before my patches were applied :d ).
There's already a feature request in flyspray: http://bugs.archlinux.org/task/15955
I see. So there will be in total three variables that can be overridden in a sub package that affect its final filename; pkgver, pkgrel, and arch. Finding those variables before defining pkgfile as "${_pkgname}-${pkgver}-${pkgrel}-${CARCH}${PKGEXT}" should allow commitpkg to cope with these sub packages.
Hmmm, this definitely needs some more thinking. :)
Funny, I was thinking of all these things yesterday too...
I have also restructured commitpkg and co. quite a bit, and wanted to send a bunch of 8 patches, but Evangelos was faster :) Now I cannot easily rebase my branch, if at all :) Well, I now think I'll rather setup my own git repo for devtools instead, and I'll send pull requests to Aaron from time to time. That's more convenient than flooding the ML with patches.
I have some ideas for refactoring devtools. I'll wikify them soon and will report back ;)
Yes, if anyone plans on doing prolonged changes to any of this, using a remote git repo is the way to do it. No need to do pull requests for 1 patch every 3 months though :)
arch-general@lists.archlinux.org