Re: RFS: libmusicbrainz-2.1 (QA upload)
Christoph Egger wrote:
> Hm ok I guess I personally would prefer a the see some notice if
> there are some tags > pedantic
If this is a generally desirable thing among sponsors, we'll of course
comply. (Some info tags are only a matter of style, though.)
> OK it took me some more time, however your package seems to
> FTBFS on the GNU/Hurd porter box still (log attached) so other stuff
> might be needed to make it work.
Too bad :-(. My GNU/Hurd box is dead for the time being, so I'm CCing
the patch author and just in case, debian-hurd. It seems that the
`os' variable remains undefined for some reason, thus AC_LINK_FILES
fails.
(Pino, the package I've prepared (with your patch unmodified) is at
http://mentors.debian.net/debian/pool/main/l/libmusicbrainz-2.1/libmusicbrainz-2.1_2.1.5-3.dsc.
Christoph Egger's (the prospective sponsor) complete message that I'm
replying to is at
http://article.gmane.org/gmane.linux.debian.devel.mentors/40887.)
> Makefile:361: .deps/cdlookup.Po: No such file or directory
These things are not supposed to happen; the package builds twice in a
row for me without leaving any cruft behind.
> dpkg-source: warning: the diff modifies the following upstream files:
> config.h
> examples/Makefile
> include/Makefile
> include/musicbrainz/Makefile
> lib/Makefile
> libmusicbrainz.pc
> libtool
> osdep/Makefile
> stamp-h1
This is also weird. Perhaps an automatic rebuild rule got triggered
somewhow?
> checking host system type... i486-pc-gnu
> WARNING: unknown system
Here is the culprit. The system is canonicalized by config.sub, and
*-gnu* is a valid and standard pattern, but `configure' still does not
define the variable as it should in the `case' statement...
Posting config.log might help to figure out why, I guess.
> config.status: linking ./osdep/mb_.cpp to lib/mb.cpp
> config.status: error: ./osdep/mb_.cpp: file not found
Here it chokes, understandably.
Reply to: