2014-04-22 22:37 Santiago Vila:
Back in the early kfreebsd-* days, there was a server called
ftp.gnuab.org where every kind of hack was allowed in the source to
make packages build. Moreover, we could make NMUs at will without
having to ask the maintainer for permission, because they were for
On Mon, Apr 21, 2014 at 12:40:10PM -0700, Russ Allbery wrote:
There's no substitute for rebuilding from source. :) I used to be a bit
skeptical of that push for Autoconf and friends, but the more I've worked
with it, the more I've come around to the position that we should treat
the
Santiago Vila sanv...@unex.es writes:
On Mon, Apr 21, 2014 at 12:40:10PM -0700, Russ Allbery wrote:
There's no substitute for rebuilding from source. :) I used to be a
bit skeptical of that push for Autoconf and friends, but the more I've
worked with it, the more I've come around to the
On Tue, Apr 22, 2014 at 11:36:52AM -0700, Russ Allbery wrote:
Santiago Vila sanv...@unex.es writes:
I would rather autoreconf at dpkg-buildpackage time in such a way that
you get an updated Debian source every time you make a new Debian
release for such package (something like
On Tue, Apr 22, 2014 at 07:45:41PM +0200, Santiago Vila wrote:
On Mon, Apr 21, 2014 at 12:40:10PM -0700, Russ Allbery wrote:
There's no substitute for rebuilding from source. :) I used to be a bit
skeptical of that push for Autoconf and friends, but the more I've worked
with it, the more
Santiago Vila sanv...@unex.es writes:
On Tue, Apr 22, 2014 at 11:36:52AM -0700, Russ Allbery wrote:
The one thing that we absolutely should *not* do is ship the results of
autoreconf as a diff. That diff is (a) completely unreadable, (b)
huge, and (c) unstable across versions, which makes
On Sat, Apr 19, 2014 at 06:42:27AM +, PICCA Frederic-Emmanuel wrote:
It may be that libgc upstream's autogen.sh script is not really 'right' in
some way. But there may well be a lot of upstreams like that, which is
why maintainers need clear guidance on how to deal with this, without
On Tue, Apr 22, 2014 at 01:14:57PM -0700, Russ Allbery wrote:
Santiago Vila sanv...@unex.es writes:
(a) Diffs are not made to be readable, they are made to update
things. As those diffs are the result of an automatic processs, you
should only need to look at the updated file, not at the
On Tue, Apr 22, 2014 at 01:14:57PM -0700, Russ Allbery wrote:
(a) Diffs are not made to be readable, they are made to update
things. As those diffs are the result of an automatic processs, you
should only need to look at the updated file, not at the diff.
Moreover, if they are unreadable,
Back in the early kfreebsd-* days, there was a server called
ftp.gnuab.org where every kind of hack was allowed in the source to
make packages build. Moreover, we could make NMUs at will without
having to ask the maintainer for permission, because they were for
the unreleased distribution. This
* Russ Allbery:
Florian Weimer f...@deneb.enyo.de writes:
* Russ Allbery:
This doesn't regenerate the other files from scratch. This only
addresses config.{sub,guess}, which is only a small part of the
problem.
Is the generated libtool file dependent on the package configuration?
No,
Florian Weimer f...@deneb.enyo.de writes:
* Russ Allbery:
No, but you have to re-run autoconf in order to get the changes to the
Libtool m4 files into the actual configure script. So you'd be okay if
you only needed to patch ltmain.sh with no configure support, but not
for anything deeper.
* Russ Allbery:
The correct long-term fix is to change autotools to check a list of
well-known paths for more recent versions of the scripts and use them
instead of what is provided in the package.
This doesn't regenerate the other files from scratch. This only addresses
Florian Weimer f...@deneb.enyo.de writes:
* Russ Allbery:
This doesn't regenerate the other files from scratch. This only
addresses config.{sub,guess}, which is only a small part of the
problem.
Is the generated libtool file dependent on the package configuration?
No, but you have to
+++ Russ Allbery [2014-04-17 14:24 -0700]:
Florian Weimer f...@deneb.enyo.de writes:
* Russ Allbery:
It's an interesting question whether we should just force dh-autoreconf
in debhelper unless the package maintainer explicitly turns it off. It
would save me work, just as I've now been
Wookey woo...@wookware.org writes:
Can someone explain how this works, because so far as I can see this
isn't true (well maybe 'most of the time' is true, but there is a
non-trivial 'rest of the time' and we need to understand when/why that
occurs, so we can make those DTRT too).
The
+++ Russ Allbery [2014-04-18 11:43 -0700]:
Wookey woo...@wookware.org writes:
Now I see that there is a copy of config.{sub,guess} in automake (in
/usr/share/automake-1.14/) so I guess that if automake is also used (or
maybe just installed?) then modern versions of these files will be
Wookey woo...@wookware.org writes:
It may be that libgc upstream's autogen.sh script is not really 'right'
in some way. But there may well be a lot of upstreams like that, which
is why maintainers need clear guidance on how to deal with this, without
having to become autotools experts. i.e
Am 19.04.2014 01:03, schrieb Russ Allbery:
OK, but again maintainers needs enough info to judge whether there is
something important in upstream's autogen.sh or if it's all effectively
boilerplate that a straighforward autoreconf will replace.
I think what I'm arguing for is just running
Hi,
On Mon, Apr 14, 2014 at 05:12:32PM +0200, Matthias Klose wrote:
it would be much more productive for Debian if you wouldn't claim wrong things
and start fixing the issue in at least this package.
Just for the record: The bug is fixed but die to some additional changes
(providing data for
Wookey dixit:
+++ Paul Wise [2014-04-16 19:51 +0800]:
On Wed, Apr 16, 2014 at 7:13 PM, Santiago Vila wrote:
What some people here try to do, update config.guess and related files,
is, IMHO, just a hack. Sure, it will just work, but only for us (Debian).
[…]
Other distributors do the
* Steve Langasek:
But I think we ought to switch to autoreconfing by default.
It's a bit risky if we don't do a mass rebuild after a new
autotools-related package upload. I still see quite a lot of warnings
if I re-run the tools on older sources, but these days, most builds
seem to work out
* Russ Allbery:
It's an interesting question whether we should just force
dh-autoreconf in debhelper unless the package maintainer explicitly
turns it off. It would save me work, just as I've now been able to
take overrides back out of all of my packages now that dpkg defaults
to xz
Florian Weimer f...@deneb.enyo.de writes:
It's a bit risky if we don't do a mass rebuild after a new
autotools-related package upload. I still see quite a lot of warnings
if I re-run the tools on older sources, but these days, most builds seem
to work out alright.
Yeah, most of the warnings
Florian Weimer f...@deneb.enyo.de writes:
* Russ Allbery:
It's an interesting question whether we should just force dh-autoreconf
in debhelper unless the package maintainer explicitly turns it off. It
would save me work, just as I've now been able to take overrides back
out of all of my
On Fri, Apr 18, 2014 at 4:49 AM, Florian Weimer wrote:
The correct long-term fix is to change autotools to check a list of
well-known paths for more recent versions of the scripts and use them
instead of what is provided in the package.
Both the config.guess/sub and autoconf upstreams
+++ Jonathan Nieder [2014-04-15 22:08 -0700]:
Hi,
Wookey wrote:
or perhaps we should collectively decide that dh-autoreconf should
just be used everywhere unles there is a damn good reason not to?
Yes, please. At least that's what I do for packages I have something
to do with. It
On Wed, 16 Apr 2014, Charles Plessy wrote:
I invite people interested in new ports to work on that change: run autoreconf
by default. The other approach, to run autoreconf only when needed, is
never-ending: new packages uploaded today build fine everywhere, but some of
them will need
On Wed, Apr 16, 2014 at 7:13 PM, Santiago Vila wrote:
I would call that a serious design flaw.
I agree
What some people here try to do, update config.guess and related files,
is, IMHO, just a hack. Sure, it will just work, but only for us (Debian).
Other distributors will still have the
Paul Wise writes (Re: About a mass bug report not based on Sid or Jessie.):
On Wed, Apr 16, 2014 at 7:13 PM, Santiago Vila wrote:
I would call that a serious design flaw.
I agree
I also.
I haven't looked at the code but I'm not sure what the purpose of
config.guess is. ISTM likely that
On Mon, Apr 14, 2014 at 05:10:40PM -0700, Steve Langasek wrote:
[..snip..]
So arguably, such a behavior change should be tied to a debhelper compat
level change.
But I think we ought to switch to autoreconfing by default.
I do too but I do wonder if this might make stable backports harder
On 16/04/14 14:12, Ian Jackson wrote:
I haven't looked at the code but I'm not sure what the purpose of
config.guess is. ISTM likely that its whole purpose is a design
error.
AIUI, it's for build systems that make decisions based on the
canonical GNU architecture name of the build
Simon McVittie writes (Re: About a mass bug report not based on Sid or
Jessie.):
AIUI, it's for build systems that make decisions based on the
canonical GNU architecture name of the build architecture (or,
indirectly, the host architecture, since the default host architecture
is whatever the
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Simon McVittie writes:
AIUI, it's for build systems that make decisions based on the
canonical GNU architecture name of the build architecture (or,
indirectly, the host architecture, since the default host architecture
is whatever the build
On 2014-04-16, Santiago Vila sanv...@unex.es wrote:
I would call that a serious design flaw.
The design flaw as I see it is that projects built using autotools can
be built on systems that hasn't got autotools installed.
The way to accomplish that is to have these giant autogenerated scripts.
* Russ Allbery r...@debian.org [140415 02:06]:
Charles Plessy ple...@debian.org writes:
Nevertheless, with these mass filings where we add en masse the same
option to many packages, I wonder if we are doing something wrong.
Don't we use debhelper and CDBS to have reasonable defaults ?
Le Mon, Apr 14, 2014 at 05:25:47PM -0700, Russ Allbery a écrit :
Steve Langasek vor...@debian.org writes:
On Mon, Apr 14, 2014 at 05:05:48PM -0700, Russ Allbery wrote:
It's an interesting question whether we should just force dh-autoreconf
in debhelper unless the package maintainer
On Wed, Apr 16, 2014 at 07:53:27AM +0900, Charles Plessy wrote:
Le Mon, Apr 14, 2014 at 05:25:47PM -0700, Russ Allbery a écrit :
Steve Langasek vor...@debian.org writes:
But I think we ought to switch to autoreconfing by default.
Agreed, particularly given that we now have a good and
Le Tue, Apr 15, 2014 at 04:36:52PM -0700, Steve Langasek a écrit :
As this will likely only be applied by default to packages updated to a new
debhelper compat level, action by the maintainer is still needed for this
change to take effect. It's trivial for you to fix this issue in your own
Am 16.04.2014 02:12, schrieb Charles Plessy:
Le Tue, Apr 15, 2014 at 04:36:52PM -0700, Steve Langasek a écrit :
As this will likely only be applied by default to packages updated to a new
debhelper compat level, action by the maintainer is still needed for this
change to take effect. It's
Hi,
Wookey wrote:
or perhaps we should collectively decide that dh-autoreconf should
just be used everywhere unles there is a damn good reason not to?
Yes, please. At least that's what I do for packages I have something
to do with. It makes getting the benefit of upstream autotools fixes
Le Wed, Apr 16, 2014 at 05:36:40AM +0200, Matthias Klose a écrit :
I have not so mixed feelings, but instead very clear feelings now about your
behaviour. You requested explicit information on the mass bug filing request
without reading the obvious channels yourself. Now *you* are
Charles,
it would be much more productive for Debian if you wouldn't claim wrong things
and start fixing the issue in at least this package. The mass-filing proposal
was sent in January to this very list. It's not my problem if you don't read
this list or ignore proposals for mass bug filings.
Le Mon, Apr 14, 2014 at 05:12:32PM +0200, Matthias Klose a écrit :
it would be much more productive for Debian if you wouldn't claim wrong things
and start fixing the issue in at least this package. The mass-filing proposal
was sent in January to this very list. It's not my problem if you
+++ Charles Plessy [2014-04-15 08:15 +0900]:
Le Mon, Apr 14, 2014 at 05:12:32PM +0200, Matthias Klose a écrit :
it would be much more productive for Debian if you wouldn't claim wrong
things
and start fixing the issue in at least this package. The mass-filing
proposal
was sent in
Charles Plessy ple...@debian.org writes:
Nevertheless, with these mass filings where we add en masse the same
option to many packages, I wonder if we are doing something wrong.
Don't we use debhelper and CDBS to have reasonable defaults ? Are there
more packages that fail to build after
On Mon, Apr 14, 2014 at 05:05:48PM -0700, Russ Allbery wrote:
Charles Plessy ple...@debian.org writes:
Nevertheless, with these mass filings where we add en masse the same
option to many packages, I wonder if we are doing something wrong.
Don't we use debhelper and CDBS to have reasonable
Steve Langasek vor...@debian.org writes:
On Mon, Apr 14, 2014 at 05:05:48PM -0700, Russ Allbery wrote:
It's an interesting question whether we should just force dh-autoreconf
in debhelper unless the package maintainer explicitly turns it off. It
would save me work, just as I've now been able
Le Sun, Apr 13, 2014 at 04:52:11PM +, Matthias Klose a écrit :
Package: src:staden-io-lib
Version: 1.13.2-3
User: debian-devel@lists.debian.org
Usertags: autoreconf
The package fails to build on ppc64el (powerpc64le-linux-gnu), because
the config.{guess,sub} files are out of date, and
Le Sun, Apr 13, 2014 at 04:52:11PM +, Matthias Klose a écrit :
Package: src:staden-io-lib
Version: 1.13.2-3
User: debian-devel@lists.debian.org
Usertags: autoreconf
On Sun, Apr 13, 2014 at 6:44 PM, Charles Plessy ple...@debian.org wrote:
You report a bug against staden-io-lib 1.13.2-3,
50 matches
Mail list logo
