On 10/26/07, Scott Horowitz wrote:

On 10/26/07, Aaron Griffin wrote:

...

I only have a few comments, which are probably more directed at versionpkg itself.

...

+update_pb() { + sed -i "1,11 s/pkgver=[^ ]*/pkgver=$1/" ./$BUILDSCRIPT +} +

The 1,11 scares me here. It seems kinda arbitrary. To me this seems better:

sed -i "s/^pkgver=[^ ]*/pkgver=$1/" ./$BUILDSCRIPT

But might also fail. I don't know, but the 1,11 choice is off-putting to me.

How might it fail? And yes, that function is pretty much directly from versionpkg..

If the pkgver is not in the first 11 lines of the PKGBUILD? It seems pretty arbitrary for versionpkg to enforce that.

On 10/26/07, Scott Horowitz wrote:

On 10/26/07, Dan McGee wrote:

...

On 10/26/07, Scott Horowitz wrote:

...

On 10/26/07, Aaron Griffin wrote:

...

I only have a few comments, which are probably more directed at versionpkg itself.

...

+update_pb() { + sed -i "1,11 s/pkgver=[^ ]*/pkgver=$1/" ./$BUILDSCRIPT +} +

The 1,11 scares me here. It seems kinda arbitrary. To me this seems better:

sed -i "s/^pkgver=[^ ]*/pkgver=$1/" ./$BUILDSCRIPT

But might also fail. I don't know, but the 1,11 choice is off-putting to me.

How might it fail? And yes, that function is pretty much directly from versionpkg..

If the pkgver is not in the first 11 lines of the PKGBUILD? It seems pretty arbitrary for versionpkg to enforce that.

Oh sorry, I meant to ask how it might fail if you removed that first 11 lines part. Aaron said "But might also fail?" to his own line. And I'm not suggesting it won't, I'm more curious than anything.

By "fail" in MY example, I meant that it will rewrite any pkgver=X that starts at column 0.... so it could brake things like: build() { ./configure --version \ pkgver=1 make } and WON'T work with any space in front of pkgver. Still, it's a better metric than the 11 line one

Scott Horowitz wrote:

Ok, try this out.. git patch is attached to prevent wrapping issues.

Scott

Applied to my working tree. -Dan

On Oct 30, 2007 2:54 AM, Scott Horowitz wrote:

Aside from the handling of darcs and git, I should point out that there seems to be some disagreement about the handling of mercurial. It appears that someone filed a bug report, a line was added to versionpkg's code to handle it, and someone else is having problems with that extra line.

See: http://bugs.archlinux.org/task/7606

and: http://aur.archlinux.org/packages.php?do_Details=1&ID=9272 (second comment, by Xilon)

Scott

_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev

The bug filed is only due to the src directory not being there. I don't know how creating the $_hgrepo directory solved the problem, since mercurial simply doesn't support initting or cloning a repo to a directory that exists. A proper solution would be to create the src directory if it doesn't exist, or wrap the whole path with dirname to remove the last directory.

On Nov 5, 2007 1:56 AM, Xilon wrote:

On Oct 30, 2007 11:28 PM, Xilon wrote:

...

On Oct 30, 2007 2:54 AM, Scott Horowitz wrote:

...

Aside from the handling of darcs and git, I should point out that there seems to be some disagreement about the handling of mercurial. It appears that someone filed a bug report, a line was added to versionpkg's code to handle it, and someone else is having problems with that extra line.

See: http://bugs.archlinux.org/task/7606

and: http://aur.archlinux.org/packages.php?do_Details=1&ID=9272 (second comment, by Xilon)

Scott

_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev

The bug filed is only due to the src directory not being there. I don't know how creating the $_hgrepo directory solved the problem, since mercurial simply doesn't support initting or cloning a repo to a directory that exists. A proper solution would be to create the src directory if it doesn't exist, or wrap the whole path with dirname to remove the last directory.

Here's a patch which should fix both issues, though I haven't run into the other one mention for which a bug was filled, so I was unable to test it. I have tested the patch for subtle-hg and abraca-hg, both cloning and updating works. I also removed the pointless "make clean", the PKGBUILDs should be building in another directory anyway, as the guidelines suggest.

Thanks for this, I've pulled it into my working branch. And good catch with the "make clean"- we should never do that in makepkg. -Dan

On 10/27/07, Miklos Vajna wrote:

for darcs and git, you could use curl to determine the last update of the repo. they will be still ugly (not as nice as git-describe is), but at least it will show when the master branch is updated

like:

date +%Y%m%d%H%M%S --date '`curl -I $url/HEAD 2>&1|sed -n '/^Last-Modified/s/^[^:]*: //p'`'

and

lynx -source -dump $url/_darcs/inventory|grep ']'|sed -n 's/.*\*\(.*\)\]./\1/;$ p'

Doesn't this require a web interface though? I guess we're already pinned to some sort of web interface, but I'm just thinking outloud. Is there a use-case where a darcs or git repo would NOT be HTTP accessible?

2007/10/29, Dan McGee :

On 10/29/07, Aaron Griffin wrote:

...

On 10/27/07, Miklos Vajna wrote:

...

for darcs and git, you could use curl to determine the last update of the repo. they will be still ugly (not as nice as git-describe is), but at least it will show when the master branch is updated

like:

date +%Y%m%d%H%M%S --date '`curl -I $url/HEAD 2>&1|sed -n '/^Last-Modified/s/^[^:]*: //p'`'

and

lynx -source -dump $url/_darcs/inventory|grep ']'|sed -n 's/.*\*\(.*\)\]./\1/;$ p'

Doesn't this require a web interface though? I guess we're already pinned to some sort of web interface, but I'm just thinking outloud. Is there a use-case where a darcs or git repo would NOT be HTTP accessible?

Well if I use a git:// address in my PKGBUILD, then yeah, this method screws us.

Did we really think the git tools wouldn't do there job? The only reason I didn't do this before is because I was just accepting it the way it currently works for versionpkg, although now might be the time to make this change.

The following will take ANY GIT repo url (local FS, http://, git://, etc) and produce a nice pretty version name for you.

git-ls-remote $_gitroot $_gitname | git-describe

Example: $git ls remote git://projects.archlinux.org/pacman.git master | git-describe v3.0.0-497-g014306e

Now that wasn't too hard, now was it? The only problem is that git-describe uses '-' characters in its version. Do we allow this, or is that reserved as a seperator for the pkgrel? I know there are some funny parsing issues we have to make sure we do right.

I think '-' should not be allowed. It can be replaced with '_'. -- Roman Kyrylych (Роман Кирилич)

On Mon, Oct 29, 2007 at 11:47:40AM -0500, Aaron Griffin wrote:

On 10/27/07, Miklos Vajna wrote:

...

for darcs and git, you could use curl to determine the last update of the repo. they will be still ugly (not as nice as git-describe is), but at least it will show when the master branch is updated

like:

date +%Y%m%d%H%M%S --date '`curl -I $url/HEAD 2>&1|sed -n '/^Last-Modified/s/^[^:]*: //p'`'

and

lynx -source -dump $url/_darcs/inventory|grep ']'|sed -n 's/.*\*\(.*\)\]./\1/;$ p'

Doesn't this require a web interface though? I guess we're already pinned to some sort of web interface, but I'm just thinking outloud. Is there a use-case where a darcs or git repo would NOT be HTTP accessible?

If I'm not mistaken the main darcs interface is http. The only other way to interact with it is over ssh. So this will probably work for darcs. Jason

On Mon, Oct 29, 2007 at 11:47:40AM -0500, Aaron Griffin wrote:

Doesn't this require a web interface though? I guess we're already pinned to some sort of web interface, but I'm just thinking outloud. Is there a use-case where a darcs or git repo would NOT be HTTP accessible?

right, for git this won't work for git://. for darcs, http is the primary anonymous transport, so it will work i think - VMiklos