Package: wnpp
Owner: Dominique Dumont
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-r...@lists.debian.org
* Package name: ruby-kpeg
Version : 1.0.0
Upstream Author : Evan Phoenix
* URL : https://github.com/evanphx/kpeg
* License : BSD
Me2 :-)
I have some suggestions:
grub2 , I don't like its/its current integration, and the autogenerated
files are very ugly - I used to use lilo ... sometimes grub fails with
raid(even when debian says it has installed fully), auto updating grub after
upgrading the system can fail sometimes (
On 2014-04-14 17:01:42 -0700, Russ Allbery wrote:
> Vincent Lefevre writes:
> > But what I mean is that it's pointless to emit such a warning when the
> > effect of the potential integer overflow is already visible, for
> > instance in printf below:
>
> > m = d * C;
> > printf ("%d\n", m);
>
On Tue, 15 Apr 2014, Dmitry Smirnov wrote:
> On Mon, 14 Apr 2014 15:40:00 Thorsten Glaser wrote:
> > • even if I disagree with maintainers (things like bugs
> > in mc), I can mostly live with it (although, when I was
> > m68k porter, some pissed me *seriously* off)
[…]
> I see that all bugs in
Package: wnpp
Severity: wishlist
Owner: Florian Schlichting
* Package name: libmce-perl
Version : 1.510
Upstream Author : Mario E. Roy
* URL : https://metacpan.org/release/MCE
* License : GPL-1+, Artistic
Programming Lang: Perl
Description : Many-Core
Hi All!
Just emailing to tell you I have not forgotten this. This Easter I will
have the time to organise this and 'turn the crank handles'.
Cheers,
Matt Grant
--
Matt Grant, Debian and Linux Systems Administration and Consulting
Mobile: 021 0267 0578
Email: m...@mattgrant.net.nz
signature.
On Fri, 11 Apr 2014, Ansgar Burchardt wrote:
> On 04/11/2014 12:42, Ian Jackson wrote:
> > What people expect is that the compiler compiles programs the way C
> > was traditionally compiled.
Actually, I think we need to go further. We need a programming
language (with at least two compiler imple
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. :-)
-
Facing last week's Heartbleed [1] bug the need for improving the
security of our systems became more apparent
Jonathan Dowland writes:
> We go over the same ground over and over. I'm increasingly in favour of *no*
> default. You must pick one from a list on install. Randomize the list if
> necessary.
The day Debian starts to randomize menu items I am going to stop using
it.
--
CYa,
⡍⠁⠗⠊⠕ | Debian De
On 14/04/14 17:40, Thorsten Glaser wrote:
Alberto Salvia Novella dixit:
>Why you choose to develop in Debian over any other distribution?
First of: why “instead”? Many developers are active in other
distributions and/or operating systems. So am I.
I came to Debian for a number of reasons:
>
Pirate Praveen gmail.com> writes:
> I love democracy, where everyone has a say and have a chance to make
> the changes they want
This sentence is *so* wrong…
bye,
//mirabilos (usually part of the minority, no matter where)
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
wit
* 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
* Balint Reczey [140415 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 in some
On Tue, Apr 15, 2014 at 8:15 PM, Christian Hofstaedtler wrote:
> I think that as of today it would help more to fix various upstream
> build tools to actually honor the build flags we (using
> dpkg-buildflags) set. This would benefit both the regular
> architectures and any hypothetical hardened a
2014-04-15 14:23 GMT+02:00 Paul Wise :
> On Tue, Apr 15, 2014 at 8:15 PM, Christian Hofstaedtler wrote:
>
>> I think that as of today it would help more to fix various upstream
>> build tools to actually honor the build flags we (using
>> dpkg-buildflags) set. This would benefit both the regular
>>
On 04/15/2014 06:00 PM, 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. :-)
>
> -
>
> Facing last week's Heartbleed [1] bug the need
On Tue, Apr 15, 2014 at 6:15 PM, Thomas Goirand wrote:
> On 04/15/2014 06:00 PM, 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. :-)
* Thorsten Glaser , 2014-04-15, 11:24:
we need to go further. We need a programming language (with at least
two compiler implementations), which I will call Ͻ, that looks like C
so much that *every* C program¹ is also a valid Ͻ program, and *every*
Ͻ program that does not make use of the additi
On 15/04/14 19:45, Jakub Wilk wrote:
> * Thorsten Glaser , 2014-04-15, 11:24:
>> we need to go further. We need a programming language (with at least
>> two compiler implementations), which I will call Ͻ, that looks like C
>> so much that *every* C program¹ is also a valid Ͻ program, and
>> *every*
Vincent Lefevre writes:
> The cases "m = d * C" and "m >= 0" are mostly the same, i.e. with the
> same false positives in practice. So, there's no reason to provide a
> warning for the second one only.
I don't think the GCC authors are just being dumb here. There probably is
a reason; it's just
Package: wnpp
Severity: wishlist
Owner: Colin Ian King
* Package name: smemstat
Version : 0.01.04
Upstream Author : Colin King
* URL : http://kernel.ubuntu.com/~cking/smemstat
* License : GPL-2+
Programming Lang: C
Description : shared memory usage mon
Jakub Wilk writes:
> * Thorsten Glaser , 2014-04-15, 11:24:
>> we need to go further. We need a programming language (with at least two
>> compiler implementations), which I will call Ͻ, that looks like C so
>> much that *every* C program¹ is also a valid Ͻ program, and *every* Ͻ
>> program that
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 turned on for every package (currently hardening
> > has to be e
Package: wnpp
Severity: wishlist
Owner: Philipp Huebner
* Package name: erlang-lager
Version : 2.0.3
Upstream Author : 2011-2014 Basho Technologies, Inc.
* URL : https://github.com/basho/lager
* License : Apache 2.0
Programming Lang: Erlang
Description
Package: wnpp
Severity: wishlist
Owner: Philipp Huebner
* Package name: erlang-goldrush
Version : 0.1.6
Upstream Author : 2012 Magnus Klaar
* URL : https://github.com/DeadZen/goldrush
* License : ISC
Programming Lang: Erlang
Description : small Erlang
Package: wnpp
Severity: wishlist
Owner: Philipp Huebner
* Package name: erlang-xmlrpc
Version : 0.2014.03.17
Upstream Author : 2003 Joakim Grebenö
2009-2014 Romuald du Song
* URL : https://github.com/rds13/xmlrpc
* License : ZLIB style
P
Package: wnpp
Severity: wishlist
Owner: Philipp Huebner
* Package name: erlang-p1-*
Version : all different
Upstream Author : ProcessOne
* URL : https://github.com/processone/
* License : GPL 2+, Apache 2.0, BSD 3-Clause, EPL 1.1, ...
Programming Lang: C, Erl
* Steve Langasek , 2014-04-15, 11:07:
But I don't imagine that you're going to get signoff on a dpkg
"amd64-secure" architecture,
"amd64-secure"? Why not "amd64-asbestos-free"?
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Tr
On 14/04/14 14:30, Vincent Lefevre wrote:
> On 2014-04-14 14:14:14 +0200, Raphael Geissert wrote:
>> No, there is no optimisation in that case, so there is no warning. It only
>> warns when it uses the knowledge that "(signed) integer overflow isn't
>> possible" to optimise away some redundant co
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
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 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
Mario Lang writes:
> Jonathan Dowland writes:
>
>> We go over the same ground over and over. I'm increasingly in favour of *no*
>> default. You must pick one from a list on install. Randomize the list if
>> necessary.
>
> The day Debian starts to randomize menu items I am going to stop using
> it
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.
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 reques
On Tue, Apr 15, 2014 at 08:52:43PM +1200, Matt Grant wrote:
> Just emailing to tell you I have not forgotten this. This Easter I will
> have the time to organise this and 'turn the crank handles'.
Sounds good, thanks Matt.
You might have also noticed that I just pushed a new branch to the
ipsec-
37 matches
Mail list logo
