On Thu, Apr 17, 2014 at 2:42 AM, Russ Allbery wrote:
> Wookey writes:
>
>> So, where in debian should we put responsiblity for updating
>> config.{sub,guess}?
>
> I lean towards being more aggressive than this and running autoreconf or
> the moral equivalent on any package using Autoconf, by defaul
Hi Balint,
Bálint Réczey wrote:
> The upstream project I'm most involved in is Wireshark where we try to
> employ most of the state of the art techniques for improving code
> quality but I think the Wireshark project is in much better position
> than most other projects. Thanks to dedicated team a
previously on this list Cesare Leonardi contributed:
> On 12/04/2014 12:23, alberto fuentes wrote:
>
> While i like Xfce, my current DE, the thing i worry most is that it
> seems almost stagnant: the latest release (4.10) was from 2 years ago
> and from the Xfce main site and blog i see no ad
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
Wookey writes:
> So, where in debian should we put responsiblity for updating
> config.{sub,guess}?
I lean towards being more aggressive than this and running autoreconf or
the moral equivalent on any package using Autoconf, by default. For that
idea, I offer the following defense:
* Just upd
+++ 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 will still have the sam
Hi Steve,
2014-04-15 20:07 GMT+02:00 Steve Langasek :
> On Wed, Apr 16, 2014 at 12:15:22AM +0800, Thomas Goirand wrote:
>> > My proposal for serving those security-focused users is introducing a
>> > new architecture targeting amd64 hardware, but with more security
>> > related C/C++ features turn
Hi Aaron,
2014-04-16 13:49 GMT+02:00 Aaron Zauner :
> Hi Balint,
>
> Balint Reczey wrote:
>> Hi,
>>
>> I have posted the following idea on my blog [7] to get comments from
>> people not on this list, but obviously this is the mailing list where
>> the proposal should be discussed. :-)
> I generall
Package: wnpp
Severity: wishlist
Owner: Andreas Tille
* Package name: smalt
Version : 0.7.6
Upstream Author : Hannes Ponstingl
* URL : http://www.sanger.ac.uk/resources/software/smalt/
* License : GPL
Programming Lang: C
Description : Sequence Mapping
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").
Hi Martin,
2014-04-16 14:53 GMT+02:00 Martin Wuertele :
> * Balint Reczey [2014-04-15 12:01]:
>
> (...)
>
>> My proposal for serving those security-focused users is introducing a
>> new architecture targeting amd64 hardware, but with more security
>> related C/C++ features turned on for every pac
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 "whate
Nico Schlömer writes ("Re: Fwd: Trilinos: to split or not to split"):
> > "libml.*", really ?
> > I wonder if you need to prefix all of the library names :-/.
>
> We're already considering prefixing them all with "trilinos_".
I guess it's probably a pain to do, but yes that would be good.
Thanks
> "libml.*", really ?
> I wonder if you need to prefix all of the library names :-/.
We're already considering prefixing them all with "trilinos_".
--Nico
On Wed, Apr 16, 2014 at 3:16 PM, Ian Jackson
wrote:
> Nico Schlömer writes ("Fwd: Trilinos: to split or not to split"):
>> Downsides of thi
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
On 2014-04-15 21:57:21 +0100, Roger Lynn wrote:
> The purpose of this gcc warning isn't to warn you that overflow
> might happen, but to warn you when gcc's optimisations have broken
> any two's complement overflow behaviour that you might have
> expected. Thus if you have written code that assumes
On 2014-04-15 10:17:04 -0700, Russ Allbery wrote:
> Vincent Lefevre writes:
> > Andrew Pinski said: "For the first warning, even though the warning is
> > correct, I don't think we should warn here as the expressions are split
> > between two different statements.", which is more or less my point
Nico Schlömer writes ("Fwd: Trilinos: to split or not to split"):
> Downsides of this include the size of the package, and the fact that
> the package name "trilinos" does not correspond with the library names
> (libbelos.*, libml.*,...).
"libml.*", really ?
I wonder if you need to prefix all of
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 likel
* Balint Reczey [2014-04-15 12:01]:
(...)
> My proposal for serving those security-focused users is introducing a
> new architecture targeting amd64 hardware, but with more security
> related C/C++ features turned on for every package (currently hardening
> has to be enabled by the maintainers i
OK,
As nobody seems for a against, let's clarify.
2014-04-11 22:31 GMT+02:00 Mathieu Parent (Debian) :
> Hello all,
>
> Currently, Debian, as installed by default (unless a DE is installed
> too) doesn't install security fixes automatically.
>
> An experienced user will activate this and keep all
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
Hi Balint,
Balint Reczey wrote:
> Hi,
>
> I have posted the following idea on my blog [7] to get comments from
> people not on this list, but obviously this is the mailing list where
> the proposal should be discussed. :-)
I generally agree with your concerns. But I have to concur that
hardening
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
26 matches
Mail list logo
