librelist archives

Re: [homebrew] Need a new ImageMagick brew maintainer

From:

Trevor Wennblom

Date:

2011-07-22 @ 05:28

we should be good. please let me know if there's any issues with my setup.


A)
it appears there is some guesswork involved in determining which svn 
commit to use for a release. for instance, i was attempting to match the 
downloadable source version 6.7.1-0, but in the repository they jump from 
6.7.0-10 to 6.7.1-1. it also appears the SVN_REVISION label can't be 
concretely trusted as in this example it lags one commit behind.

% git co 6.7.1
Switched to branch '6.7.1'
% git log -p config/configure.xml
commit e03504718483e6ab38ce738a239c5a8043e1d4ed
Author: cristy <cristy@aa41f4f7-0bf4-0310-aa73-e5a19afd5a74>
Date:   Sat Jul 9 18:00:04 2011 +0000

    git-svn-id: 
https://www.imagemagick.org/subversion/ImageMagick/branches/ImageMagick-6.7.1@4769
aa41f4f7-0bf4-0310-aa73-e5a19afd5a74

diff --git a/config/configure.xml b/config/configure.xml
index ae02ec0..be106d6 100644
--- a/config/configure.xml
+++ b/config/configure.xml
@@ -7,28 +7,28 @@
 ]>
 <configuremap>
   <configure name="NAME" value="ImageMagick"/>
-  <configure name="VERSION" value="6.7.0"/>
-  <configure name="LIB_VERSION" value="0x670"/>
-  <configure name="LIB_VERSION_NUMBER" value="6,7,0,10"/>
-  <configure name="SVN_REVISION" value="4660" />
-  <configure name="RELEASE_DATE" value="2011-06-30"/>
+  <configure name="VERSION" value="6.7.1"/>
+  <configure name="LIB_VERSION" value="0x671"/>
+  <configure name="LIB_VERSION_NUMBER" value="6,7,1,1"/>
+  <configure name="SVN_REVISION" value="4768" />
+  <configure name="RELEASE_DATE" value="2011-07-09"/>
   <configure name="CONFIGURE" value="./configure "/>
   <configure name="PREFIX" value="/usr/local"/>
[...]



B) users will likely run into this error where the formula cache does not 
know it needs to update the git remote. perhaps we should add some sort of
check in homebrew to ensure the cache matches the formula repository, and 
remove the cache if it doesn't? (my initial thought was to simply update 
the remotes in the cache, but that would only work when the repositories 
are almost interchangeable such as in this case)

[using original formula]

% brew install imagemagick
/usr/local/bin/git
==> Cloning https://github.com/adamv/ImageMagick.git
Cloning into /Users/user/Library/Caches/Homebrew/imagemagick--git...
remote: Counting objects: 2739, done.
remote: Compressing objects: 100% (1695/1695), done.
remote: Total 2739 (delta 1631), reused 1996 (delta 1037)
Receiving objects: 100% (2739/2739), 12.55 MiB | 118 KiB/s, done.
Resolving deltas: 100% (1631/1631), done.
==> Checking out tag 6.6.9-4
==> ./configure --disable-osx-universal-binary --without-perl 
--prefix=/usr/local/Cellar/imagemagick/6.6.9-4 
--disable-dependency-tracking --enable-shared --disable-static 
--with-modules --without-gsl
^C

[update formula to point to new mirror that contains the same tag]

% brew install imagemagick
/usr/local/bin/git
==> Cloning https://github.com/trevor/ImageMagick.git
Updating /Users/user/Library/Caches/Homebrew/imagemagick--git
==> Checking out tag 6.6.9-4
==> ./configure --disable-osx-universal-binary --without-perl 
--prefix=/usr/local/Cellar/imagemagick/6.6.9-4 
--disable-dependency-tracking --enable-shared --disable-static 
--with-modules --without-gsl
^C

[note the original repository on disk]

% cat /Users/user/Library/Caches/Homebrew/imagemagick--git/.git/config 
[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
        ignorecase = true
[remote "origin"]
        fetch = +refs/heads/*:refs/remotes/origin/*
        url = https://github.com/adamv/ImageMagick.git
[branch "trunk"]
        remote = origin
        merge = refs/heads/trunk

[update formula to point to new tag]

% brew install imagemagick
/usr/local/bin/git
==> Cloning https://github.com/trevor/ImageMagick.git
Updating /Users/user/Library/Caches/Homebrew/imagemagick--git
==> Checking out tag 6.7.1-1
error: pathspec '6.7.1-1' did not match any file(s) known to git.
Error: Failure while executing: git checkout -q 6.7.1-1

[rm -rf /Users/user/Library/Caches/Homebrew/imagemagick--git]



C)

and success.

% brew install imagemagick
/usr/local/bin/git
==> Cloning https://github.com/trevor/ImageMagick.git
Updating /Users/user/Library/Caches/Homebrew/imagemagick--git
==> Checking out tag 6.7.1-1
==> ./configure --disable-osx-universal-binary --without-perl 
--prefix=/usr/local/Cellar/imagemagick/6.7.1-1 
--disable-dependency-tracking --enable-shared --disable-static 
--with-modules --without-gsl
==> make install
==> Caveats
We are downloading from an unofficial GitHub mirror because of:
* Stable tarballs disappearing
* Bad https cert on official SVN repo
==> Summary
/usr/local/Cellar/imagemagick/6.7.1-1: 1389 files, 32M, built in 3.1 minutes

[checking]

% which identify
/usr/local/bin/identify
% ll `which identify`
lrwxr-xr-x  1 user  staff  42 Jul 22 00:18 /usr/local/bin/identify -> 
../Cellar/imagemagick/6.7.1-1/bin/identify

% identify /Library/Application\ Support/Apple/iChat\ 
Icons/Flags/Argentina.gif

/Library/Application Support/Apple/iChat Icons/Flags/Argentina.gif GIF 
48x48 48x48+0+0 8-bit PseudoClass 256c 2.51KB 0.000u 0:00.000
% identify --version
Version: ImageMagick 6.7.1-1 2011-07-22 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2011 ImageMagick Studio LLC
Features: OpenMP OpenCL

On 22 Jul 2011, at 01:28, Trevor Wennblom wrote:

> it appears there is some guesswork involved in determining which svn 
commit to use for a release. for instance, i was attempting to match the 
downloadable source version 6.7.1-0, but in the repository they jump from 
6.7.0-10 to 6.7.1-1. it also appears the SVN_REVISION label can't be 
concretely trusted as in this example it lags one commit behind.

It may just be easier to mirror their tarballs automatically through 
scraping their webpage.

Thanks!

--
Mike McQuaid
http://mikemcquaid.com

I've amended the formula, but I guess I should hold off pushing then?

Sidenote: the git download_strategy doesn't support changing the git url.

There's an easy way round this I believe. Which will always work provided 
the repos contain identical blobs. So I'll look into that.

>> it appears there is some guesswork involved in determining which svn 
commit to use for a release. for instance, i was attempting to match the 
downloadable source version 6.7.1-0, but in the repository they jump from 
6.7.0-10 to 6.7.1-1. it also appears the SVN_REVISION label can't be 
concretely trusted as in this example it lags one commit behind.
> 
> It may just be easier to mirror their tarballs automatically through 
scraping their webpage.
> 
> Thanks!
> 
> --
> Mike McQuaid
> http://mikemcquaid.com
> 

On 27 Jul 2011, at 12:24, Max Howell wrote:

> I've amended the formula, but I guess I should hold off pushing then?
> 
> Sidenote: the git download_strategy doesn't support changing the git url.
> 
> There's an easy way round this I believe. Which will always work 
provided the repos contain identical blobs. So I'll look into that.

Your thoughts on bottling? That will solve the issue for most users.

--
Mike McQuaid
http://mikemcquaid.com