xlibs-dev transition; packages with adjusted dependencies needing upload
Justin Pryzby
http://bugs.debian.org/cgi-bin/pkgreport.cgi?usertag=debian-...@lists.debian.org:transition-xlibs-dev&repeatmerged=no&tagexcl=patch#_2_2_5
I've gone and figured out the updated dependences necessary for ~40 of
them to build. So any sufficiently motivated QAish person can close
40 RC bugs if they are so interested. Unfortunately, I can't upload;
but it would be nice if someone else would, so my work doesn't go to
waste :) You could even pbuild lots of them at once.. Hopefully this
can save someone from some trial/error and overhead with NMUing
multiple packages.
Let me know if this is useful.
--
Clear skies,
Justin
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Gustavo Franco
> Packages with RC bugs due to the xlibs-dev transition are listed at:
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?usertag=debian-...@lists.debian.org:transition-xlibs-dev&repeatmerged=no&tagexcl=patch#_2_2_5
>
> I've gone and figured out the updated dependences necessary for ~40 of
> them to build. So any sufficiently motivated QAish person can close
> 40 RC bugs if they are so interested. Unfortunately, I can't upload;
> but it would be nice if someone else would, so my work doesn't go to
> waste :) You could even pbuild lots of them at once.. Hopefully this
> can save someone from some trial/error and overhead with NMUing
> multiple packages.
>
>
Can you publish your list with the new depends for these ~ 40 packages?
I think it would be
better in a wiki.d.o article pointing to RC bugs related (if any).
> Let me know if this is useful.
It's, sure. :)
Thanks,
Gustavo Franco - <str...@debian.org>
Marc Singer
> Justin Pryzby wrote:
> >Packages with RC bugs due to the xlibs-dev transition are listed at:
> > http://bugs.debian.org/cgi-bin/pkgreport.cgi?usertag=debian-...@lists.debian.org:transition-xlibs-dev&repeatmerged=no&tagexcl=patch#_2_2_5
> >
> >I've gone and figured out the updated dependences necessary for ~40 of
> >them to build. So any sufficiently motivated QAish person can close
> >40 RC bugs if they are so interested. Unfortunately, I can't upload;
> >but it would be nice if someone else would, so my work doesn't go to
> >waste :) You could even pbuild lots of them at once.. Hopefully this
> >can save someone from some trial/error and overhead with NMUing
> >multiple packages.
> >
> >
> Hi Justin,
>
> Can you publish your list with the new depends for these ~ 40 packages?
> I think it would be
> better in a wiki.d.o article pointing to RC bugs related (if any).
> >Let me know if this is useful.
> It's, sure. :)
There is a script referenced on the page above that explains how to
generate the new build-depends. It's *really* easy to make this
change.
Justin Pryzby
> On Sat, Jan 14, 2006 at 01:07:36AM -0200, Gustavo Franco wrote:
> > Justin Pryzby wrote:
> > >Packages with RC bugs due to the xlibs-dev transition are listed at:
> > > http://bugs.debian.org/cgi-bin/pkgreport.cgi?usertag=debian-...@lists.debian.org:transition-xlibs-dev&repeatmerged=no&tagexcl=patch#_2_2_5
> > >
> > >I've gone and figured out the updated dependences necessary for ~40 of
> > >them to build. So any sufficiently motivated QAish person can close
> > >40 RC bugs if they are so interested. Unfortunately, I can't upload;
> > >but it would be nice if someone else would, so my work doesn't go to
> > >waste :) You could even pbuild lots of them at once.. Hopefully this
> > >can save someone from some trial/error and overhead with NMUing
> > >multiple packages.
> > >
> > >
> > Hi Justin,
> >
> > Can you publish your list with the new depends for these ~ 40 packages?
change b-d.
> > I think it would be
> > better in a wiki.d.o article pointing to RC bugs related (if any).
> > >Let me know if this is useful.
> > It's, sure. :)
>
> There is a script referenced on the page above that explains how to
> generate the new build-depends. It's *really* easy to make this
> change.
Yea, but probably best to test it, too (:), which is what I did. Of
course, since I can't make uplods someone has to recompile them
anyway.
--
Clear skies,
Justin
Amaya
Justin Pryzby wrote:
> Each of the bugs tagged patch has a short note with the necessary
> change b-d.
I intend to do this:
http://paste.debian.net/3743
And I am very interested in your work... I would like to see a list of
those bugs, specifically the ones *you* fixed.
I am interested in sponsoring your NMUs, by the guidelines of the link I
pasted above.
> Yea, but probably best to test it, too (:), which is what I did. Of
> course, since I can't make uplods someone has to recompile them
> anyway.
True. Sure I will.
--
.''`. sleep: command not found
: :' :
`. `' Proudly running unstable Debian GNU/Linux
`- www.amayita.com www.malapecora.com www.chicasduras.com
Justin Pryzby
> Hi there, Justin
>
> Justin Pryzby wrote:
> > Each of the bugs tagged patch has a short note with the necessary
> > change b-d.
>
> I intend to do this:
> http://paste.debian.net/3743
> And I am very interested in your work... I would like to see a list of
> those bugs, specifically the ones *you* fixed.
Unfortunately my first round didn't use the script (though I was aware
of it), and so many packages say "(no replacement needed)", even
though they have a direct build-dep on some package which used to be
depended on by xlibs-dev. So I'm going back through the bugs and
adding the dependencies from the xlibs-split-check script and
including interdiffs.
The following bugs had no needed build-dep replacement (according to
the checker script) and have nmu diffs attached:
346622 346626 346646 346773 346827 346624 346634 346760 346795 347096
Note that some of the maintainers have already responded, so you
should take a quick look at the bug log before building.
> I am interested in sponsoring your NMUs, by the guidelines of the link I
> pasted above.
>
> > Yea, but probably best to test it, too (:), which is what I did. Of
> > course, since I can't make uplods someone has to recompile them
> > anyway.
>
> True. Sure I will.
Junichi (dancer) had a good idea to debdiff the resulting .deb, which
is something I didn't do (but would in the future).
--
Clear skies,
Justin
Amaya
> Unfortunately my first round didn't use the script (though I was aware
> of it), and so many packages say "(no replacement needed)", even
> though they have a direct build-dep on some package which used to be
> depended on by xlibs-dev. So I'm going back through the bugs and
> adding the dependencies from the xlibs-split-check script and
> including interdiffs.
Thanks, your work is very appreciated indeed.
> The following bugs had no needed build-dep replacement (according to
> the checker script) and have nmu diffs attached:
>
> 346622 346626 346646 346773 346827 346624 346634 346760 346795
> 347096
>
> Note that some of the maintainers have already responded, so you
> should take a quick look at the bug log before building.
Sure, I am über-careful in this regard. I want the NMUs to be friendly,
non-intrussive and don't want to waste my time or the Maintainer's time.
> Junichi (dancer) had a good idea to debdiff the resulting .deb, which
> is something I didn't do (but would in the future).
I am not sure this helps me build, test, and upload an sponsored NMU.
Is there a link you can provide to a more detailed explanation of this
procedure?
Thnaks!
--
.''`. sleep: command not found
: :' :
`. `' Proudly running unstable Debian GNU/Linux
`- www.amayita.com www.malapecora.com www.chicasduras.com
Thomas Viehmann
Justin Pryzby wrote:
> 346622 346626 346646 346773 346827 346624 346634 346760 346795 347096
346622 fixed by maint
347096 fixed by maint
346827 uploaded (maint consent)
346624 uploaded (maint consent)
346634 uploaded
346795 uploaded
Not yet:
346646 346626 346773
346760 maintainer has demands
Kind regards
T.
--
Thomas Viehmann, http://thomas.viehmann.net/
Amaya
Thanks for the update on the status of this.
Thomas Viehmann wrote:
> 346760 maintainer has demands
Just upload and orphan. He doesn't seem to want to do it himself.
Can we tag the bugs you already fixed in an upload as "pending"?
This way it is much easier to keep track of the ones that still need
work.
Thanks for your time and effort!
--
.''`. sleep: command not found
: :' :
`. `' Proudly running unstable Debian GNU/Linux
`- www.amayita.com www.malapecora.com www.chicasduras.com
Marc Singer
reason, the libX11.a librarary isn't being found by ld. It's looking
in /usr/X11R6/lib. Am I misunderstanding another change in the X11
libraries?
Thomas Viehmann
>> 346760 maintainer has demands
> Just upload and orphan. He doesn't seem to want to do it himself.
And now I'm tired and testing xmms-jack moved me from bugs to Beethoven. :)
> Can we tag the bugs you already fixed in an upload as "pending"?
> This way it is much easier to keep track of the ones that still need
> work.
I think they're all tagged fixed now and I'm off for the day.
I'll tag pending when I get back to uploading stuff.
Kind regards
T.
--
Thomas Viehmann, http://thomas.viehmann.net/
Amaya
> I'm getting a build failure on s390 for the updated package. For some
Which one?
> reason, the libX11.a librarary isn't being found by ld. It's looking
> in /usr/X11R6/lib. Am I misunderstanding another change in the X11
> libraries?
Does re-running autoconf help?
--
.''`. sleep: command not found
: :' :
`. `' Proudly running unstable Debian GNU/Linux
`- www.amayita.com www.malapecora.com www.chicasduras.com
Marc Singer
> Marc Singer wrote:
> > I'm getting a build failure on s390 for the updated package. For some
>
> Which one?
buici-clock
It builds on ix86, but I don't use a chroot jail for building.
>
> > reason, the libX11.a librarary isn't being found by ld. It's looking
> > in /usr/X11R6/lib. Am I misunderstanding another change in the X11
> > libraries?
>
> Does re-running autoconf help?
The package doesn't use autoconf.
I guess I'm going to have to pull the s390 x11-dev package to look at
it.
Russ Allbery
> I'm getting a build failure on s390 for the updated package. For some
> reason, the libX11.a librarary isn't being found by ld. It's looking in
> /usr/X11R6/lib. Am I misunderstanding another change in the X11
> libraries?
Maybe I'm missing something obvious, but why would you want the package to
be linking statically with libX11? Or did you mean libX11.so?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Marc Singer
> On Sun, Jan 15, 2006 at 02:02:57AM +0100, Amaya wrote:
> > Marc Singer wrote:
> > > I'm getting a build failure on s390 for the updated package. For some
> >
> > Which one?
>
> buici-clock
>
> It builds on ix86, but I don't use a chroot jail for building.
>
> >
> > > reason, the libX11.a librarary isn't being found by ld. It's looking
> > > in /usr/X11R6/lib. Am I misunderstanding another change in the X11
> > > libraries?
> >
> > Does re-running autoconf help?
I was wrong, the package does use autoconf. I'm not doing the build,
the autobuilder is.
Marc Singer
> Marc Singer wrote:
> > buici-clock
>
> > I guess I'm going to have to pull the s390 x11-dev package to look at
> > it.
>
> that it has been split up into (in the case of buici-clock, those
> probably are libx11-dev, libxext-dev, x-dev).
Already done. This new problem is due to the change. I used the
proscribed script and it told me to replace it with libx11-dev and
libxext-dev. The build is fine on my dev box, but I don't use a
chroot jail.
Anyway, I've asked the build-dd to send me the build log.
Cheers.
Marc Singer
> Marc Singer <e...@buici.com> writes:
>
> > I'm getting a build failure on s390 for the updated package. For some
> > reason, the libX11.a librarary isn't being found by ld. It's looking in
> > /usr/X11R6/lib. Am I misunderstanding another change in the X11
> > libraries?
>
> Maybe I'm missing something obvious, but why would you want the package to
> be linking statically with libX11? Or did you mean libX11.so?
I don't think it is. I erroneously stated the reported error. The
compiler complained that it couldn't find -lX11.
c++ -g -lX11 -lXext -o o/xo o/ldisplay.o o/lwindow.o o/lfont.o o/wbutton.o o/wtext.o o/wdialog.o
+o/lhash.o o/larray.o o/res.o o/dmalloc.o o/dither.o o/lpicture.o o/loupe.o o/stats.o o/res_l.o o/res_y.o
> /usr/bin/ld: cannot find -lX11
> collect2: ld returned 1 exit status
Unfortunately, the reporter omitted the rest of the build log. The
autoconf script should have found the X11 library, but it looks like
it didn't.
Thomas Viehmann
> buici-clock
> I guess I'm going to have to pull the s390 x11-dev package to look at
> it.
You need to replace xlibs-dev dependency by the appropriate dev-packages
that it has been split up into (in the case of buici-clock, those
probably are libx11-dev, libxext-dev, x-dev).
Kind regards
T.
--
Thomas Viehmann, http://thomas.viehmann.net/
Amaya
> I was wrong, the package does use autoconf. I'm not doing the build,
> the autobuilder is.
Here is what vorlon tought me to do:
cd packagesrc-0.0/
autoconf
dpkg-buildpackage -rfakeroot -uc -us -b
cd ..
pbuilder build package*dsc
Do you want me to test this for you and generate a package the
autobuilder might like better?
--
.''`. sleep: command not found
: :' :
`. `' Proudly running unstable Debian GNU/Linux
`- www.amayita.com www.malapecora.com www.chicasduras.com
Steve Langasek
> On Sat, Jan 14, 2006 at 05:22:45PM -0800, Russ Allbery wrote:
> > Marc Singer <e...@buici.com> writes:
> > > I'm getting a build failure on s390 for the updated package. For some
> > > reason, the libX11.a librarary isn't being found by ld. It's looking in
> > > /usr/X11R6/lib. Am I misunderstanding another change in the X11
> > > libraries?
> > Maybe I'm missing something obvious, but why would you want the package to
> > be linking statically with libX11? Or did you mean libX11.so?
> I don't think it is. I erroneously stated the reported error. The
> compiler complained that it couldn't find -lX11.
> c++ -g -lX11 -lXext -o o/xo o/ldisplay.o o/lwindow.o o/lfont.o o/wbutton.o o/wtext.o o/wdialog.o
> +o/lhash.o o/larray.o o/res.o o/dmalloc.o o/dither.o o/lpicture.o o/loupe.o o/stats.o o/res_l.o o/res_y.o
> > /usr/bin/ld: cannot find -lX11
> > collect2: ld returned 1 exit status
> Unfortunately, the reporter omitted the rest of the build log. The
> autoconf script should have found the X11 library, but it looks like
> it didn't.
Explanation for this problem is here:
http://lists.gnu.org/archive/html/bug-autoconf/2005-09/msg00023.html
Simple fix is to re-run autoconf on the package, to pick up a new definition
of the AC_PATH_X macro.
Alternative fix is to add libxt-dev to the build-deps, even though libxt-dev
isn't used for anything but the configure check.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vor...@debian.org http://www.debian.org/
Moritz Muehlenhoff
>> You need to replace xlibs-dev dependency by the appropriate dev-packages
>> that it has been split up into (in the case of buici-clock, those
>> probably are libx11-dev, libxext-dev, x-dev).
>
> Already done. This new problem is due to the change. I used the
> proscribed script and it told me to replace it with libx11-dev and
> libxext-dev. The build is fine on my dev box, but I don't use a
> chroot jail.
xlibs-split-check has been a quick hack, there are some corner cases it
doesn't catch like non-standard includes through special wrappers. That's
why any xlibs transition should always be checked in pbuilder.
Cheers,
Moritz
Justin Pryzby
which needed replacement direct dependencies, are tested in pbuilder,
and have no changes reported by debdiff save for some
version/size/depends stuff.
Build logs are all available at
http://justinpryzby.com/debian/xlibs-dev/
I also confirmed that debdiff against the 10 sponsored NMU uploads
from yesterday have no file changes, and only debian/control changes
for depends/version/size.
Here it is
#347146: xlbiff
#346631: bbkeys
#346630: blast
#346613: canna
#346617: jester
#347138: nitpic
#347109: stardict
#347041: quark
#346965: wmtimer
#347118: wmload
#347119: wmix
#347074: tleenx2
#347042: qiv
I also note the following packages are "hard" to NMU, because of some
problem like another FTBFS or the package being native when it should
not be. I'm untagging these 'patch' now.
arla-0.36.2
ayttm-0.4.6+26
bzflag-2.0.4.20051017.1
gpsim-0.20.14
grabc-1.1
jwm-0.23
rsjog-1.1
wininfo-0.7
wmblob-1.0.3
wmmaiload-1.0.2
wmressel-0.8
xpad-2.10
xscorch-0.2.0
--
Clear skies,
Justin
Justin Pryzby
> I also note the following packages are "hard" to NMU, because of some
> problem like another FTBFS or the package being native when it should
> not be. I'm untagging these 'patch' now.
Let me elaborate on these
> arla-0.36.2
The following packages have unmet dependencies:
kerberos4kth-dev
> ayttm-0.4.6+26
Files in second .deb but not in first
-------------------------------------
/usr/lib/ayttm/img2jpc.a
/usr/lib/ayttm/img2jpc.la
/usr/lib/ayttm/img2jpc.so
> bzflag-2.0.4.20051017.1
native
> gpsim-0.20.14
gui_regwin.c:1795: error: 'GTK_SHEET_CLIP_TEXT' undeclared (first use
in this fu
> grabc-1.1
X11/Xos.h not found; needs include path update
> jwm-0.23
group.c:252:41: error: macro "LoadNamedIcon" passed 2 arguments, but takes just 1
maintainer decision to rerun autoconf or build-dep: libxt-dev
> rsjog-1.1
Files in second .deb but not in first
-------------------------------------
/usr/lib/ruby/1.6/i386-linux/XTest.so
Files in first .deb but not in second
-------------------------------------
/usr/lib/ruby/1.6/i486-linux/XTest.so
> wininfo-0.7
Fails to find -lXRes even when I build-dep on libxres-dev
> wmblob-1.0.3
maintainer decision to rerun autoconf or build-dep: libxt-dev
Fails to find libXpm even when build-dep on libxpm-dev
> wmmaiload-1.0.2
Fails to find libXext even when build-dep on libxext-dev; needs -L
path update?
> wmressel-0.8
Fails to find libXxf86vm even when build-dep on libxext-dev; needs -L
path update?
> xpad-2.10
xpad-session-manager.o: In function `xpad_session_manager_stop_interact':/tmp/buildd/xpad-2.10/src/xpad-session-manager.c:168: undefined reference to
`SmcInteractDone'
> xscorch-0.2.0
maintainer decision to rerun autoconf or build-dep: libxt-dev, libxpm-dev
If someone knows that these ar expected or how to work around them, be
my guest to NMU or fill me in. Otherwise some of these maybe should
be cloned bugs; I don't know.
Justin Pryzby
tag 346808 - patch
tag 346801 - patch
tag 346796 - patch
thanks
These packages are difficult to NMU because they are native when they
should not be.
Justin Pryzby
> Justin Pryzby wrote:
> > #347146: xlbiff
> Today I'll only get that one, but take the liberty to fix this:
> +Build-Depends: debhelper, libxaw7-dev (>> 4.0.3) (>> 4.0.3), xutils,
> libxt-dev, x-dev
> (The second >> is a leftover of the xlibs-dev...)
Doh! Thanks for catching this. pbuilder accepted the syntax..
I just checked the other patched bugs and confirmed it was the only
such fsckup.
Steve Langasek
> On Sun, Jan 15, 2006 at 11:24:56AM -0500, Justin Pryzby wrote:
> > I also note the following packages are "hard" to NMU, because of some
> > problem like another FTBFS or the package being native when it should
> > not be. I'm untagging these 'patch' now.
> Let me elaborate on these
> > arla-0.36.2
> The following packages have unmet dependencies:
> kerberos4kth-dev
krb4 is being removed from etch. This warrants a separate RC bug on arla.
(which brings the total to 4 RC bugs on arla, and it's not in testing
currently... so.)
Still a separate bug, though, so the "patch" tag still belongs.
> > bzflag-2.0.4.20051017.1
> native
Should still be 'patch' if there's a good patch for the issue.
> > gpsim-0.20.14
> gui_regwin.c:1795: error: 'GTK_SHEET_CLIP_TEXT' undeclared (first use
> in this fu
Separate bug, should be tagged 'patch'
> > jwm-0.23
> group.c:252:41: error: macro "LoadNamedIcon" passed 2 arguments, but takes just 1
> maintainer decision to rerun autoconf or build-dep: libxt-dev
> > wmblob-1.0.3
> maintainer decision to rerun autoconf or build-dep: libxt-dev
> Fails to find libXpm even when build-dep on libxpm-dev
> > xscorch-0.2.0
> maintainer decision to rerun autoconf or build-dep: libxt-dev, libxpm-dev
There's no reason why this can't be fixed in NMU.
Russ Allbery
> On Sun, Jan 15, 2006 at 12:21:41PM -0500, Justin Pryzby wrote:
>> On Sun, Jan 15, 2006 at 11:24:56AM -0500, Justin Pryzby wrote:
>>> arla-0.36.2
>> The following packages have unmet dependencies:
>> kerberos4kth-dev
> krb4 is being removed from etch. This warrants a separate RC bug on arla.
> (which brings the total to 4 RC bugs on arla, and it's not in testing
> currently... so.)
> Still a separate bug, though, so the "patch" tag still belongs.
I really need to finish with gnubg before picking up another case like
this, but wow, that's a bunch of very fixable problems. Admittedly, I
personally think people would be better off using OpenAFS, but there are
some advantages to Arla (one being that it's way more portable than
OpenAFS since it does nearly all of its work in userspace).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Justin Pryzby
I created this script allowing many packages to be pbuilt and patched
nearly automatically. It isn't intended to be fully automatic,
because someone should actually read the .diff, of course. It runs
pbuild using the recommended build-deps, and uses debdiff to assert
that nothing changed unexpectedly.
I just ran through the last 3 of these small packages in a matter of
minutes:
jazip 346729
groundhog 346716
flying 346707
gbase 346705
hp2xx 346702
The point is that the result can be more easily consistent, and that
the user doesn't have to concentrate on crap like typing 'pdebuild >&
>(tee log/foo.log)', but can instead just read the final proposed NMU
.diff and debdiff output to make sure they are sane, and hopefully
spend more time and effort doing that instead. It would be good to
read the buildlogs too.
It depends on a hacked copy of xlibs-split script, which is attached.
Justin
Thomas Viehmann
> Here it is
Those are done between Amaya, Steve, and yours truly.
> #347146: xlbiff
> #346631: bbkeys
> #346630: blast
> #346613: canna
> #346617: jester
> #347138: nitpic
> #347109: stardict
> #346965: wmtimer
> #347118: wmload
> #347119: wmix
> #347042: qiv
waiting on maintainer comment
> #347041: quark
maintainer wants to do himself
> #347074: tleenx2
Kind regards
T.
--
Thomas Viehmann, http://thomas.viehmann.net/
Justin Pryzby
Blessed
=======
346698 gnome-randr-applet
346729 jazip
346687 baken
346650 baycomepp
346900 twlog
346688 ibp
Not blessed
===========
346716 groundhog
346707 flying
346705 gbase
346685 euler
346643 conky
346654 d4x
346899 twin
346884 oleo
Please check the bug logs before uploading..some may get comments
between me writing this and someone reading it.
--
Clear skies,
Justin
Marc Singer
thx.
Marc Singer
> Marc Singer wrote:
> > I was wrong, the package does use autoconf. I'm not doing the build,
> > the autobuilder is.
>
> Here is what vorlon tought me to do:
>
> cd packagesrc-0.0/
> autoconf
I don't think that this is valid. You don't know if a package uses
autoconf. Moreover, there may be a reason why the package uses an
older autoconf than the one you have installed.
> dpkg-buildpackage -rfakeroot -uc -us -b
> cd ..
> pbuilder build package*dsc
>
> Do you want me to test this for you and generate a package the
> autobuilder might like better?
This wouldn't have helped in the case of this package. Rerunning
autoconf didn't change the configure script. I updated it to
autoconf2.50 which is the version patched to fix the bug elicited by
these X library changes.
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=327655>
Cheers.
Steve Langasek
> On Sun, Jan 15, 2006 at 03:57:01AM +0100, Amaya wrote:
> > Marc Singer wrote:
> > > I was wrong, the package does use autoconf. I'm not doing the build,
> > > the autobuilder is.
> > Here is what vorlon tought me to do:
> > cd packagesrc-0.0/
> > autoconf
> I don't think that this is valid. You don't know if a package uses
> autoconf. Moreover, there may be a reason why the package uses an
> older autoconf than the one you have installed.
Any reasons for using an older autoconf that aren't transitory are bad
reasons. :) autoconf2.13 is ancient, unsupported, and won't stay around
forever, within Debian or otherwise. And it has bugs. Like this one. :)
Cheers,
Marc Singer
> On Mon, Jan 16, 2006 at 02:17:06PM -0800, Marc Singer wrote:
> > On Sun, Jan 15, 2006 at 03:57:01AM +0100, Amaya wrote:
> > > Marc Singer wrote:
> > > > I was wrong, the package does use autoconf. I'm not doing the build,
> > > > the autobuilder is.
>
> > > Here is what vorlon tought me to do:
>
> > > cd packagesrc-0.0/
> > > autoconf
>
> > I don't think that this is valid. You don't know if a package uses
> > autoconf. Moreover, there may be a reason why the package uses an
> > older autoconf than the one you have installed.
>
> Any reasons for using an older autoconf that aren't transitory are bad
> reasons. :) autoconf2.13 is ancient, unsupported, and won't stay around
> forever, within Debian or otherwise. And it has bugs. Like this one. :)
It was *stuck* on my machine because of a diversion. I had to
uninstall both version and then reinstall 2.50 to get the latest
version to be the default.
So, no there is no good reason to use the older version. It's just
the packages didn't automatically upgrade.
Amaya
> I don't think that this is valid. You don't know if a package uses
> autoconf.
Hey! I didn't even know what package it was LOL
Blind guessing...
> This wouldn't have helped in the case of this package. Rerunning
> autoconf didn't change the configure script. I updated it to
> autoconf2.50 which is the version patched to fix the bug elicited by
> these X library changes.
Good, one less bug to go!
--
.''`. sleep: command not found
: :' :
`. `' Proudly running unstable Debian GNU/Linux
`- www.amayita.com www.malapecora.com www.chicasduras.com
Marc Singer
Looks like updating autoconf was insufficient.
I'd like to be able to inspect the state of the system when configure
is running. The buildd doesn't show me the command it is running. Is
there a way I can emulate it?
Justin Pryzby
> On Mon, Jan 16, 2006 at 01:44:31PM -0800, Marc Singer wrote:
> > On Sat, Jan 14, 2006 at 10:48:48PM -0800, Steve Langasek wrote:
> > > Explanation for this problem is here:
> > >
> > > http://lists.gnu.org/archive/html/bug-autoconf/2005-09/msg00023.html
> > >
> > > Simple fix is to re-run autoconf on the package, to pick up a new definition
> > > of the AC_PATH_X macro.
> > >
> > > Alternative fix is to add libxt-dev to the build-deps, even though libxt-dev
> > > isn't used for anything but the configure check.
> >
>
> Looks like updating autoconf was insufficient.
>
> I'd like to be able to inspect the state of the system when configure
> is running. The buildd doesn't show me the command it is running. Is
> there a way I can emulate it?
need to add a configure option to get the log output, I donno).
--
Clear skies,
Justin
Marc Singer
> > I'd like to be able to inspect the state of the system when configure
> > is running. The buildd doesn't show me the command it is running. Is
> > there a way I can emulate it?
> You could sh -x ./configure, or check the config.log output (you may
> need to add a configure option to get the log output, I donno).
So in other words, not without a chroot build environment.
And it turns out that there were several problems:
o The autoconf in stable is still broken, but my development host
uses stable.
o There were two configuration scripts. I forgot to update both.
o The script to determine which libraries were needed missed a
couple: ICE and SM.
o The newer autoconf changed the way that CFLAGS is created s.t. the
configuration scripts had to be changed to use CXXFLAGS instead of
CFLAGS.
None of this was apparent from my development machine, though I cannot
figure out why the last one didn't show up. I used a chroot install
of unstable which made it much easier to figure out why it wasn't
working.
Cheers.
Marc Singer
> This one time, at band camp, Marc Singer wrote:
> >I'd like to be able to inspect the state of the system when configure
> >is running. The buildd doesn't show me the command it is running. Is
> >there a way I can emulate it?
>
>
> CFLAGS="$(CFLAGS)" ./configure \
> --host=$(DEB_HOST_GNU_TYPE) \
> --build=$(DEB_BUILD_GNU_TYPE) \
> --prefix=/usr \
> --mandir=\$${prefix}/share/man \
> --infodir=\$${prefix}/share/info \
> || cat config.log
>
> You could change that to unconditionally cat it afterwards.
Nice, thanks.
Jamie Wilkinson
>is running. The buildd doesn't show me the command it is running. Is
>there a way I can emulate it?
I get the buildds to cat config.log if the configure fails, like so:
CFLAGS="$(CFLAGS)" ./configure \
--host=$(DEB_HOST_GNU_TYPE) \
--build=$(DEB_BUILD_GNU_TYPE) \
--prefix=/usr \
--mandir=\$${prefix}/share/man \
--infodir=\$${prefix}/share/info \
|| cat config.log
You could change that to unconditionally cat it afterwards.
Steve Langasek
> On Tue, Jan 17, 2006 at 07:12:57PM -0500, Justin Pryzby wrote:
> > > I'd like to be able to inspect the state of the system when configure
> > > is running. The buildd doesn't show me the command it is running. Is
> > > there a way I can emulate it?
> > You could sh -x ./configure, or check the config.log output (you may
> > need to add a configure option to get the log output, I donno).
> So in other words, not without a chroot build environment.
> And it turns out that there were several problems:
> o The autoconf in stable is still broken, but my development host
> uses stable.
Then that's not an appropriate development environment for uploads
targetted at unstable... Please use an unstable chroot when preparing any
uploads to unstable.
> o The script to determine which libraries were needed missed a
> couple: ICE and SM.
The script looks for included headers. If headers from libice-dev and
libsm-dev aren't being included anywhere in the source, I suspect this
build-dependency exists only because the upstream sources are linking to
these libraries incorrectly.
Justin Pryzby
http://bugs.debian.org/cgi-bin/pkgreport.cgi?usertag=debian-...@lists.debian.org:transition-xlibs-dev&repeatmerged=no&tagexcl=patch#_0_2_4
Yesterday I ran a for loop around all the xlibs-dev buggy packages,
pbuiling with s/xlibs-dev/$(xlibs-split)/. There were plenty of
failures, such as for packages needing autofoo updates || libxt-dev,
but I just finished reviewing the logs of successfully compiled
packages and have tagged ~100 of them myself. I guess there are some
uploads happening; thanks for that!
--
Clear skies,
Justin
Steve Langasek
> 79 bugs presently tagged patched:
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?usertag=debian-...@lists.debian.org:transition-xlibs-dev&repeatmerged=no&tagexcl=patch#_0_2_4
> Yesterday I ran a for loop around all the xlibs-dev buggy packages,
> pbuiling with s/xlibs-dev/$(xlibs-split)/. There were plenty of
> failures, such as for packages needing autofoo updates || libxt-dev,
FWIW, I've been using the following script which picks up Xt dependencies in
configure scripts as well.
$ grep -rh '#include.*<X11/' . | sed -e's,>[[:space:]]*\(/\*.*\*/\)*$,,; \
s,^[[:space:]]*#include[[:space:]]*<,/usr/X11R6/include/,' | sort -u \
| xargs dpkg -S | cut -f1 -d: | sort -u
And almost all libxt-dev matches are caused by old autoconf macros, FWIW;
nobody uses Xt by choice. :-P