+++ 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
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
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, 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
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
* 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
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
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
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
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 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 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
> "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
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
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
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
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").
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
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
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
+++ 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
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
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
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
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
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
26 matches
Mail list logo
