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
the
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 a
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 unrea
On Tue, Apr 22, 2014 at 01:14:57PM -0700, Russ Allbery wrote:
> Santiago Vila 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 diff.
> > Mo
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, withou
Santiago Vila 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 life incred
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
On Tue, Apr 22, 2014 at 11:36:52AM -0700, Russ Allbery wrote:
> Santiago Vila 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
> > debian/patches/aur
Santiago Vila 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 position tha
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 confi
Florian Weimer 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.
> Oh dear
* Russ Allbery:
> Florian Weimer 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, bu
Florian Weimer 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 re-run autoconf
* 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
> config.{su
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 run
Wookey 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 how to determine w
+++ Russ Allbery [2014-04-18 11:43 -0700]:
> Wookey 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 found
> > and u
Wookey 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 autoconf package (con
+++ Russ Allbery [2014-04-17 14:24 -0700]:
> Florian Weimer 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 t
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 expli
Florian Weimer 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 packages now
Florian Weimer 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 are about unde
* 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 com
* 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 al
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 distrib
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
On 2014-04-16, Santiago Vila 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.
Other build s
Ian Jackson 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 architecture is").
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
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 archite
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 harde
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
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
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 patc
+++ 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 w
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 reques
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
(
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.
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 ow
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 writes:
> > > But I think we ought to switch to autoreconfing by default.
> > Agreed, particularly given that we now have a good and fairly reliabl
Le Mon, Apr 14, 2014 at 05:25:47PM -0700, Russ Allbery a écrit :
> Steve Langasek 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 tur
* Russ Allbery [140415 02:06]:
> Charles Plessy 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
Steve Langasek 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 to take ov
On Mon, Apr 14, 2014 at 05:05:48PM -0700, Russ Allbery wrote:
> Charles Plessy 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 ?
Charles Plessy 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 autoreconf, than p
+++ 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
> >
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,
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.
T
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 wrote:
> You report a bug against staden-io-lib 1.13.2-3, which is not t
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
50 matches
Mail list logo
