Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#54403 closed defect (wontfix)

ImageMagick: autoconf tries to run non-existing gitversion

Reported by: ballapete (Peter "Pete" Dyballa) Owned by: ryandesign (Ryan Carsten Schmidt)
Priority: Normal Milestone:
Component: ports Version: 2.4.1
Keywords: Cc:
Port: ImageMagick

Description

Although I have git installed some packages are missing a utility gitversion. Then the shell interpreter complains that it cannot find this command.

Change History (18)

comment:1 Changed 7 years ago by Schamschula (Marius Schamschula)

Cc: ciserlohn@… removed
Owner: set to ciserlohn@…
Status: newassigned

Are you sure you didn't mean git version?

comment:2 in reply to:  1 Changed 7 years ago by ballapete (Peter "Pete" Dyballa)

Replying to Schamschula:

Are you sure you didn't mean git version?

Yes, I am sure that a utility gitversion was reported. This could have been a typo…

I am migrating my "vanilla" MacPorts on Snow Leopard to a variant that uses libc++ as cxx_stdliband around 9:30 I started to look for such a file. This morning only these port were built:

-rw-r--r-- 1 root admin    694011 2017-07-01 09:13 /opt/local/var/macports/software/webp/webp-0.6.0_0.darwin_10.x86_64.tbz2
-rw-r--r-- 1 root admin    223261 2017-07-01 09:14 /opt/local/var/macports/software/gd2/gd2-2.2.4_1+x11.darwin_10.x86_64.tbz2
-rw-r--r-- 1 root admin    302114 2017-07-01 09:15 /opt/local/var/macports/software/gts/gts-0.7.6_3.darwin_10.x86_64.tbz2
-rw-r--r-- 1 root admin    114927 2017-07-01 09:15 /opt/local/var/macports/software/libLASi/libLASi-1.1.1_1.darwin_10.x86_64.tbz2
-rw-r--r-- 1 root admin   3246644 2017-07-01 09:15 /opt/local/var/macports/software/urw-fonts/urw-fonts-1.0.7pre44_0.darwin_10.noarch.tbz2
-rw-r--r-- 1 root admin   6372941 2017-07-01 09:21 /opt/local/var/macports/software/graphviz/graphviz-2.40.1_1+gdk_pixbuf+pangocairo+poppler+rsvg+x11.darwin_10.x86_64.tbz2
-rw-r--r-- 1 root admin   1092833 2017-07-01 09:23 /opt/local/var/macports/software/djvulibre/djvulibre-3.5.27_0.darwin_10.x86_64.tbz2
-rw-r--r-- 1 root admin    279774 2017-07-01 09:24 /opt/local/var/macports/software/ilmbase/ilmbase-2.2.0_0.darwin_10.x86_64.tbz2
-rw-r--r-- 1 root admin   4700519 2017-07-01 09:25 /opt/local/var/macports/software/openexr/openexr-2.2.0_1.darwin_10.x86_64.tbz2

Right now a long lasting build is happening so I have to wait until it will have finished. Hopefully the failure will repeat (I do remember that I've already seen it last year but did not report).

comment:3 Changed 7 years ago by ballapete (Peter "Pete" Dyballa)

Well, I can't reproduce it. And looking at the time stamps git was finally installed in the afternoon, this time as the proper variant.

It is possible that git was not installed in the morning that sh tried to invoke git version. With git deactivated port is not forcibly re-building this morning's ports…

There is still a difference of 200 ports that are not yet installed, although some might be relics of former dependencies. git still deactivated might reproduce the failure on Sunday!

comment:4 Changed 7 years ago by ballapete (Peter "Pete" Dyballa)

I have /usr/bin/git version 1.7.5.4 installed. It understands the command git version, so the command git version cannot have failed. When some failure with *git* and *version* in the output was reported than it must have been *gitversion*.

comment:5 Changed 7 years ago by raimue (Rainer Müller)

Can you provide examples of ports that seem to require this gitversion? The exact error message would help to find out what is going on.

I am not aware of a script with that name and could not find any references on the web either, except this python module.

comment:6 Changed 7 years ago by kencu (Ken)

here's one I noticed, although it seemed to have no effect on installing ImageMagick in the end...

--->  Verifying checksums for ImageMagick
--->  Checksumming ImageMagick-6.9.8-4.tar.xz
--->  Extracting ImageMagick
--->  Extracting ImageMagick-6.9.8-4.tar.xz
Executing:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_ImageMagick/ImageMagick/work" && /opt/local/bin/xz -dc '/opt/local/var/macports/distfiles/ImageMagick/ImageMagick-6.9.8-4.tar.xz' | /usr/bin/gnutar --no-same-owner -xf - 
--->  Configuring ImageMagick
Executing:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_ImageMagick/ImageMagick/work/ImageMagick-6.9.8-4" && autoreconf -fvi 
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: /opt/local/bin/aclocal --force -I m4
sh: gitversion: command not found

comment:7 Changed 7 years ago by raimue (Rainer Müller)

Owner: changed from ciserlohn@… to ryandesign
Port: imagemagick added; git removed
Summary: git does not provide gitversionImageMagick: autoconf tries to run non-existing gitversion

Probably it is this: https://github.com/GitTools/GitVersion

It is definitely not part of git, therefore removing this port from the port field.

However, I doubt this is really useful when using a release tarball, as the git history will not be available. I would go as far to say that this is an error at upstream, because they could check for existence of .git and not even try to run such a script.

comment:8 Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)

I've never seen this problem. I'll have to investigate.

comment:9 Changed 7 years ago by Schamschula (Marius Schamschula)

Perhaps we are looking for https://github.com/GitTools/GitVersion ?

It seems the gitversion command has been in configure.ac for quite a while: I found it in version 7.0.0.

Last edited 7 years ago by Schamschula (Marius Schamschula) (previous) (diff)

comment:10 Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)

Port: ImageMagick added; imagemagick removed
Resolution: wontfix
Status: assignedclosed

Ok, I can confirm that configuring ImageMagick does result in several occurrences of this error appearing in the log:

sh: gitversion: command not found

This does not prevent the port from building.

This is not our problem. It's what ImageMagick's configure.ac file says to do. The problem should be reported to the developers of ImageMagick. Bug reports are accepted here: https://github.com/ImageMagick/ImageMagick/issues

comment:11 in reply to:  9 ; Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)

Replying to Schamschula:

It seems the gitversion command has been in configure.ac for quite a while: I found it in version 7.0.0.

MacPorts follows ImageMagick 6, not 7. Here's the commit where the use of gitversion was introduced:

https://github.com/ImageMagick/ImageMagick/commit/6b58c59d17ee69125324e55374196229b01f3f13

comment:12 in reply to:  11 ; Changed 7 years ago by ballapete (Peter "Pete" Dyballa)

Replying to ryandesign:

When the red lines are the original ones, and the green ones are the adaptations, then someone from the MacPorts team must have introduced that bug. Svnversion exists… And the bug can easily be correct with "␣".

comment:13 in reply to:  12 ; Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)

Replying to ballapete:

When the red lines are the original ones, and the green ones are the adaptations, then someone from the MacPorts team must have introduced that bug.

That's not the case. This is a commit in the ImageMagick repository, not the MacPorts one.

Svnversion exists… And the bug can easily be correct with "␣".

I'm not sure what you mean.

comment:14 in reply to:  13 Changed 7 years ago by ballapete (Peter "Pete" Dyballa)

Replying to ryandesign:

Replying to ballapete:

And the bug can easily be correct with "␣".

I'm not sure what you mean.

I meant inserting a SPACE character between git and version.

Anyway, I tried to open a case for that case…

comment:15 Changed 7 years ago by raimue (Rainer Müller)

git version is doing something completely different than this gitversion script. The former outputs the version of git itself and the latter is supposed to generate a string representing the current git commit, which of course only makes sense when running autoconf in a git working tree.

comment:16 in reply to:  15 Changed 7 years ago by ballapete (Peter "Pete" Dyballa)

Replying to raimue:

git version is doing something completely different than this gitversion script. The former outputs the version of git itself and the latter is supposed to generate a string representing the current git commit, which of course only makes sense when running autoconf in a git working tree.

Yes, obviously, I received that response:

git_rev ()
{
   d=`date +%Y%m%d`
   c=`git rev-list --full-history --all --abbrev-commit | wc -l | sed -e 's/^ *//'`
   h=`git rev-list --full-history --all --abbrev-commit | head -1`
   echo ${c}:${h}:${d}
}

comment:17 Changed 7 years ago by ballapete (Peter "Pete" Dyballa)

"We can reproduce it and will have a patch to fix it in GIT master branch @ https://github.com/ImageMagick/ImageMagick later today. The patch will be available in the beta releases of ImageMagick @ http://www.imagemagick.org/download/beta/ by sometime tomorrow."

comment:18 Changed 7 years ago by ballapete (Peter "Pete" Dyballa)

The ticket was closed by ImageMagick, so presumingly this ticket can also be closed.

Note: See TracTickets for help on using tickets.