[arch-dev-public] [signoff] devtools 0.9.1
Am Samstag, 13. Februar 2010 00:18:30 schrieb Eric Bélanger:
I found the cause of this error. This error happens when the CacheDir is undefined. The chroot_mount function in mkarchroot then fails to create the cache_dir directory. It should be fixed by the commit to give cache_dir a default value.
Thanks, that explains a lot. I have put 0.9.1 into [testing] fixing this issue and being a little more verbose when an action might take longer (like svn commit) -- Pierre Schmitz, https://users.archlinux.de/~pierre
On 13/02/10 13:10, Pierre Schmitz wrote:
Am Samstag, 13. Februar 2010 00:18:30 schrieb Eric Bélanger:
I found the cause of this error. This error happens when the CacheDir is undefined. The chroot_mount function in mkarchroot then fails to create the cache_dir directory. It should be fixed by the commit to give cache_dir a default value.
Thanks, that explains a lot. I have put 0.9.1 into [testing] fixing this issue and being a little more verbose when an action might take longer (like svn commit)
Is it possible to run the svn commit only once in archrelease instead of after the rm and copy parts? We now get 5 messages per update to arch-commits instead of three. That will take that list from ~200 messages a day to ~350. Not that this really matters...
Am Samstag, 13. Februar 2010 06:02:39 schrieb Allan McRae:
Is it possible to run the svn commit only once in archrelease instead of after the rm and copy parts? We now get 5 messages per update to arch-commits instead of three. That will take that list from ~200 messages a day to ~350. Not that this really matters...
I also like to know how to do this in one transaction. Svn simply does not want you to and complains about it. We have the same problem in db-move of db- scripts. -- Pierre Schmitz, https://users.archlinux.de/~pierre
This commit needs to be fixed: http://projects.archlinux.org/devtools.git/commit/?id=7ce9cd69 It results in a lot of: warning: directory permissions differ on etc/ when creating a chroot. "umask 0022" would be correct. As an aside, the only way to current make a chroot with [testing] enabled is to create one without testing, enable it and then upgrade from there. Otherwise there are lots of conflicts when attempting to install "base". Allan
Am Samstag, 13. Februar 2010 06:43:54 schrieb Allan McRae:
This commit needs to be fixed: http://projects.archlinux.org/devtools.git/commit/?id=7ce9cd69
It results in a lot of: warning: directory permissions differ on etc/
when creating a chroot. "umask 0022" would be correct.
done: http://projects.archlinux.org/devtools.git/commit/?id=70d7baee6833b5d68de6a8... -- Pierre Schmitz, https://users.archlinux.de/~pierre
On 13/02/2010 07:24, Pierre Schmitz wrote:
Am Samstag, 13. Februar 2010 06:43:54 schrieb Allan McRae:
This commit needs to be fixed: http://projects.archlinux.org/devtools.git/commit/?id=7ce9cd69
It results in a lot of: warning: directory permissions differ on etc/
when creating a chroot. "umask 0022" would be correct.
done: http://projects.archlinux.org/devtools.git/commit/?id=70d7baee6833b5d68de6a8...
No problem here either using latest git version. F
Am Samstag, 13. Februar 2010 20:29:59 schrieb Firmicus:
No problem here either using latest git version.
Thanks for testing; I have uploaded 0.9.2 to [testing]. Let's see how many updates it will need until we can move it to [extra]. ;-) -- Pierre Schmitz, https://users.archlinux.de/~pierre
On 14/02/10 06:07, Pierre Schmitz wrote:
Am Samstag, 13. Februar 2010 20:29:59 schrieb Firmicus:
No problem here either using latest git version.
Thanks for testing; I have uploaded 0.9.2 to [testing]. Let's see how many updates it will need until we can move it to [extra]. ;-)
I now need no adjusted scripts to support both arches, only an alias adding "linux64" for x86_64 builds. Made a chroot, built a package and uploaded it without issue. Signoff, Allan
On Sat, Feb 13, 2010 at 6:32 PM, Allan McRae <allan@archlinux.org> wrote:
On 14/02/10 06:07, Pierre Schmitz wrote:
Am Samstag, 13. Februar 2010 20:29:59 schrieb Firmicus:
No problem here either using latest git version.
Thanks for testing; I have uploaded 0.9.2 to [testing]. Let's see how many updates it will need until we can move it to [extra]. ;-)
I now need no adjusted scripts to support both arches, only an alias adding "linux64" for x86_64 builds.
Made a chroot, built a package and uploaded it without issue.
No signoff from me, this is completely busted. I'm curious to see what it just uploaded and committed: dmcgee@galway ~/projects/arch-repos/git/trunk $ extrapkg 'update to 1.7 series' committing changes to trunk...Killed by signal 15. done skipping i686 uploading skipping non-regular file "git-1.7.0-1-x86_64.pkg.tar.gz" sent 50 bytes received 12 bytes 24.80 bytes/sec total size is 52 speedup is 0.84 releasing package...Killed by signal 15. Killed by signal 15. Killed by signal 15. Killed by signal 15. Killed by signal 15. Killed by signal 15. done Note that "git-1.7.0-1-x86_64.pkg.tar.gz" is a symlink in the cwd created by makepkg-git because of this awesome idea when using PKGDEST (http://projects.archlinux.org/pacman.git/commit/?id=93862bd7cb91129cece07391...). -Dan
This is a regression introduced after switching to rsync in place of scp; scp dereferenced symlinks automatically without need for a command-line option. Signed-off-by: Dan McGee <dan@archlinux.org> --- commitpkg | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/commitpkg b/commitpkg index 58d4e25..52ca2ac 100755 --- a/commitpkg +++ b/commitpkg @@ -84,7 +84,7 @@ for _arch in ${arch[@]}; do fi echo -n 'uploading ' - rsync -c -h --progress $rsyncopts "${pkgfile}" -e ssh $server:staging/$repo || abort + rsync -c -h -L --progress $rsyncopts "${pkgfile}" -e ssh $server:staging/$repo || abort done archrelease $repo-${_arch} || abort done -- 1.7.0
Am Mittwoch, 17. Februar 2010 04:34:38 schrieb Dan McGee:
This is a regression introduced after switching to rsync in place of scp; scp dereferenced symlinks automatically without need for a command-line option.
Applied. I guess you'll need this if PKGDEST is set, correct? I never used that. :-) -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Tue, Feb 16, 2010 at 9:17 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Sat, Feb 13, 2010 at 6:32 PM, Allan McRae <allan@archlinux.org> wrote:
On 14/02/10 06:07, Pierre Schmitz wrote:
Am Samstag, 13. Februar 2010 20:29:59 schrieb Firmicus:
No problem here either using latest git version.
Thanks for testing; I have uploaded 0.9.2 to [testing]. Let's see how many updates it will need until we can move it to [extra]. ;-)
I now need no adjusted scripts to support both arches, only an alias adding "linux64" for x86_64 builds.
Made a chroot, built a package and uploaded it without issue.
No signoff from me, this is completely busted. I'm curious to see what it just uploaded and committed:
Patch sent for this issue. However, while testing it I also noticed another regression. Before if you run extrapkg twice, it did not cause any SVN activity at all on the second run. Now it deletes and re-adds the architecture directory every time you run it even if nothing changed. I guess that was the advantage of the merges? -Dan
Am Mittwoch, 17. Februar 2010 04:37:30 schrieb Dan McGee:
However, while testing it I also noticed another regression. Before if you run extrapkg twice, it did not cause any SVN activity at all on the second run. Now it deletes and re-adds the architecture directory every time you run it even if nothing changed. I guess that was the advantage of the merges?
Why would you run extrapkg twice with nothing changed? Anyway, I could fix this by do a svn diff trunk repos/extra-i686 etc. I guess. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Wed, Feb 17, 2010 at 12:03 AM, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Mittwoch, 17. Februar 2010 04:37:30 schrieb Dan McGee:
However, while testing it I also noticed another regression. Before if you run extrapkg twice, it did not cause any SVN activity at all on the second run. Now it deletes and re-adds the architecture directory every time you run it even if nothing changed. I guess that was the advantage of the merges?
Why would you run extrapkg twice with nothing changed? Anyway, I could fix this by do a svn diff trunk repos/extra-i686 etc. I guess.
Why? 1. An upload failed, either not my fault or I had to hit Ctrl-C because of something else 2. The tools fail and I'm forced to hack and re-upload (see my patch) 3. Automation These all hold especially true since we moved the commit before the upload, so it is much more likely now. -Dan
Am Mittwoch, 17. Februar 2010 14:25:17 schrieb Dan McGee:
Why? 1. An upload failed, either not my fault or I had to hit Ctrl-C because of something else 2. The tools fail and I'm forced to hack and re-upload (see my patch) 3. Automation
These all hold especially true since we moved the commit before the upload, so it is much more likely now.
svn does not commit twice. The problem is archrelease. I have added a check if trunk and the target repo are the same. That should do it as we check if trunk was commited before. The downside is that this slows us down again. See http://projects.archlinux.org/devtools.git/commit/?id=849e6c6de51415888146f2... -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Wed, Feb 17, 2010 at 8:29 AM, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Mittwoch, 17. Februar 2010 14:25:17 schrieb Dan McGee:
Why? 1. An upload failed, either not my fault or I had to hit Ctrl-C because of something else 2. The tools fail and I'm forced to hack and re-upload (see my patch) 3. Automation
These all hold especially true since we moved the commit before the upload, so it is much more likely now.
svn does not commit twice. The problem is archrelease. I have added a check if trunk and the target repo are the same. That should do it as we check if trunk was commited before.
The downside is that this slows us down again. How does it slow us down? svn diff is a local-only operation.
See http://projects.archlinux.org/devtools.git/commit/?id=849e6c6de51415888146f2...
Am Mittwoch, 17. Februar 2010 15:38:40 schrieb Dan McGee:
The downside is that this slows us down again.
How does it slow us down? svn diff is a local-only operation.
No, I use svn diff on the remtoe server here. svn diff used locally behaves differently. It just checks if local changes haven't been commited. It's really non-intuitive imho. Just try "svn diff somefile someotherfile" and it will allways return nothing. If you use remote urls instead you get the expected behavior. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Wed, Feb 17, 2010 at 8:42 AM, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Mittwoch, 17. Februar 2010 15:38:40 schrieb Dan McGee:
The downside is that this slows us down again.
How does it slow us down? svn diff is a local-only operation.
No, I use svn diff on the remtoe server here. svn diff used locally behaves differently. It just checks if local changes haven't been commited. It's really non-intuitive imho.
Just try "svn diff somefile someotherfile" and it will allways return nothing. If you use remote urls instead you get the expected behavior.
/me didn't pay attention. Why don't we just do a regular diff to keep it local and compare the two trees?? -Dan
On 18/02/10 00:50, Dan McGee wrote:
On Wed, Feb 17, 2010 at 8:42 AM, Pierre Schmitz<pierre@archlinux.de> wrote:
Am Mittwoch, 17. Februar 2010 15:38:40 schrieb Dan McGee:
The downside is that this slows us down again.
How does it slow us down? svn diff is a local-only operation.
No, I use svn diff on the remtoe server here. svn diff used locally behaves differently. It just checks if local changes haven't been commited. It's really non-intuitive imho.
Just try "svn diff somefile someotherfile" and it will allways return nothing. If you use remote urls instead you get the expected behavior.
/me didn't pay attention. Why don't we just do a regular diff to keep it local and compare the two trees??
From talking to Pierre earlier, this was because there is likely to be other crap in the truck (e.g. packages) so a plain diff between the two directories is not good. But could we just diff each of the "${source[@]} $install" files individually? We could do this as we loop to check all source files are present in SVN. Allan
Am Mittwoch, 17. Februar 2010 16:02:26 schrieb Allan McRae:
But could we just diff each of the "${source[@]} $install" files individually? We could do this as we loop to check all source files are present in SVN.
and what about files that are not part of the PKGBUILD? e.g. scripts that create the source tar, install files (ok, those are easy to check, except for split packages). Before I do such complicated stuff I prefer the current method which is absolutely safe. Half-OT: Does anybody know a way to optimize svn on gerolde? It really got extreme slow on every operation. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Wed, 2010-02-17 at 16:09 +0100, Pierre Schmitz wrote:
Am Mittwoch, 17. Februar 2010 16:02:26 schrieb Allan McRae:
But could we just diff each of the "${source[@]} $install" files individually? We could do this as we loop to check all source files are present in SVN.
and what about files that are not part of the PKGBUILD? e.g. scripts that create the source tar, install files (ok, those are easy to check, except for split packages).
Before I do such complicated stuff I prefer the current method which is absolutely safe.
Half-OT: Does anybody know a way to optimize svn on gerolde? It really got extreme slow on every operation.
(maybe set LANG/LC_ALL/whatever to C first) _trunk=$(svn info | grep 'Last Changed Rev:' | awk '{ print $4 }') _repo=$(svn info ../repos/extra-i686 | grep 'Last Changed Rev:' | awk '{ print $4 }') if [ $_trunk -gt $_repo ]; then do your voodoo here fi I think this covers most issues here. When repos/* is newer than trunk, it has already been committed, or someone did local commits inside repos/. In the first case there's no need to commit, in the last case we don't want to commit without manual inspection first.
Am Mittwoch, 17. Februar 2010 16:41:06 schrieb Jan de Groot:
(maybe set LANG/LC_ALL/whatever to C first)
_trunk=$(svn info | grep 'Last Changed Rev:' | awk '{ print $4 }') _repo=$(svn info ../repos/extra-i686 | grep 'Last Changed Rev:' | awk '{ print $4 }')
if [ $_trunk -gt $_repo ]; then do your voodoo here fi
I think this covers most issues here. When repos/* is newer than trunk, it has already been committed, or someone did local commits inside repos/. In the first case there's no need to commit, in the last case we don't want to commit without manual inspection first.
Nice idea and I think it could even work. Committed as http://projects.archlinux.org/devtools.git/commit/?id=53a864a5aa2e273154e4e3... -- Pierre Schmitz, https://users.archlinux.de/~pierre
Am Mittwoch, 17. Februar 2010 15:50:39 schrieb Dan McGee:
/me didn't pay attention. Why don't we just do a regular diff to keep it local and compare the two trees??
Then you would need to exclude untracked files like the recently build pkg.tar.gz. And you need to make sure that the local repo dir is in sync with the remote one. I am not sure if that's worth the effort. But maybe it's easier than I guess. -- Pierre Schmitz, https://users.archlinux.de/~pierre
Am Mittwoch, 17. Februar 2010 04:17:29 schrieb Dan McGee:
No signoff from me, this is completely busted. I'm curious to see what it just uploaded and committed:
dmcgee@galway ~/projects/arch-repos/git/trunk $ extrapkg 'update to 1.7 series' committing changes to trunk...Killed by signal 15. done skipping i686 uploading skipping non-regular file "git-1.7.0-1-x86_64.pkg.tar.gz"
sent 50 bytes received 12 bytes 24.80 bytes/sec total size is 52 speedup is 0.84 releasing package...Killed by signal 15. Killed by signal 15. Killed by signal 15. Killed by signal 15. Killed by signal 15. Killed by signal 15. done
Note that "git-1.7.0-1-x86_64.pkg.tar.gz" is a symlink in the cwd created by makepkg-git because of this awesome idea when using PKGDEST (http://projects.archlinux.org/pacman.git/commit/?id=93862bd7cb91129cece073 91c00ab9e6f81111d0).
You are using pacman-git, correct? -- Pierre Schmitz, https://users.archlinux.de/~pierre
participants (6)
-
Allan McRae
-
Dan McGee
-
Dan McGee
-
Firmicus
-
Jan de Groot
-
Pierre Schmitz