X-Debbugs-Cc: debian-devel@lists.debian.org,
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter
* Package name: golang-github-d2g-dhcp4
Version : 0.0~git20150413
Upstream Author : Dan Goldsmith
* URL : https://github.com/d2g/dh
X-Debbugs-Cc: debian-devel@lists.debian.org,
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter
* Package name: golang-github-d2g-dhcp4client
Version : 0.0~git20150520
Upstream Author : Dan Goldsmith
* URL : https://github.com/
X-Debbugs-Cc: debian-devel@lists.debian.org,
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter
* Package name: golang-github-coreos-go-iptables
Version : 0.0~git20150805
Upstream Author : Eugene Yakubovich
* URL : https://gi
On Aug 24 2015, Sebastian Ramacher wrote:
> Hi
>
> On 2015-08-24 23:12:41, Niels Thykier wrote:
>> * Up to 5 packages need to change section (see "Implementation-
>>details" below)
>>- See #796834, #796836, #796839, #796840, and #796842.
>
> What's the plan for python(3)-*-dbg packages th
Andreas Barth writes:
> - for i386, there is still sold new hardware with 32bit-only. Are
> there open issues for i386 (apart from the 32bit-generic ones)?
> Discussion that we need to get rid of it one day should be started.
Can we fully support cross-grading to amd64 before we do that? My
On Friday, August 14 2015, Andres Salomon wrote:
>> Your work was done back in June, so if you prefer I can provide
>> patches against your branch to implement/fix the issues I have been
>> working on. It won't really matter much, I think: in the end, we'll
>> have to use the "official" repository
Andreas Barth ayous.org> writes:
> - for i386, there is still sold new hardware with 32bit-only. Are
> there open issues for i386 (apart from the 32bit-generic ones)?
> Discussion that we need to get rid of it one day should be started.
Eh, is this some sort of conspiracy to make Debian even
On Mon, Aug 24, 2015 at 10:25:01PM +0200, Niels Thykier wrote:
> > It is really so much difficult to make this in stages?
> > For example:
> > Stage 1. Make it a policy *recommendation*, with normal severity.
> > Stage 2. Make it a policy "should", with important severity.
> > Stage 3. Make it a r
> Quoting Holger: "This is a lie" (pointing to a graph that was being
> shown on the screen). The current figures we are handling right now
> refer to a modified build environment (i.e. sid + the special
> sources.list line from alioth).
I do not intend to change anything until these changes have
Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant
* Package name: asl
Version : 0.1.6
Upstream Author : Avtech Scientific
* URL : http://asl.org.il/
* License : AGPL-3
Programming Lang: C++
Description : multiphysics simulation software
On Mon, Aug 24, 2015 at 10:25:01PM +0200, Niels Thykier wrote:
> In your opinion, how much of the archive should be fixed before one can
> start bumping the severity?
I don't know, but I think we should have better statistics before
deciding about that.
Quoting Holger: "This is a lie" (pointing t
Santiago Vila wrote...
> Making a great percentage of packages in the archive to be "suddenly"
> buggy is unacceptable.
Nobody would consider making failing r12y "serious" at the current
state where 13 to 17 percent of the packages fail, depending on how
you read the numbers.
> We all want Debia
Hi
On 2015-08-24 23:12:41, Niels Thykier wrote:
> * Up to 5 packages need to change section (see "Implementation-
>details" below)
>- See #796834, #796836, #796839, #796840, and #796842.
What's the plan for python(3)-*-dbg packages that include both Python extensions
built for the python
On 2015-08-24 23:28, Steve Langasek wrote:
> Hi Niels,
>
> On Mon, Aug 24, 2015 at 11:12:41PM +0200, Niels Thykier wrote:
>> [...]
>
> I wonder how this list was arrived at. Offhand, I see the libc6-dbg and
> python3.5-dbg packages are both in section 'debug', both of which are part
> of the bui
❦ 24 août 2015 22:30 +0100, Colin Tuckley :
>> We have pushed other archive-wide goals that were not shared by
>> all upstreams. For example, we have enabled hardening build flags
>> on almost all packages and for packages that don't obey to the
>> appropriate flags, bugs with severity "importan
Hi Niels,
On Mon, Aug 24, 2015 at 11:12:41PM +0200, Niels Thykier wrote:
> * Up to 5 packages need to change section (see "Implementation-
>details" below)
>- See #796834, #796836, #796839, #796840, and #796842.
> Implementation-details
> ==
>
> There are some deta
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 24/08/15 22:02, Vincent Bernat wrote:
> We have pushed other archive-wide goals that were not shared by
> all upstreams. For example, we have enabled hardening build flags
> on almost all packages and for packages that don't obey to the
> appropr
Niels Thykier writes:
> On 2015-08-24 21:24, Santiago Vila wrote:
>> We all want Debian to build reproducibly, but goals are achieved by
>> submitting bugs, changing packages and making uploads, not by rising
>> severities.
> I agree in general that people should make an effort to improve the
>
Hi,
Here is the "post-debconf" status on automatic debug packages ("ddebs").
The previous status from 2015-06-29 can be found in [0].
What is it?
===
* ddebs are Debian packages with the extension .deb that
contain debugging symbols and are built implicitly.
- A package foo_1.23.deb
On 24/08/15 21:42, Niels Thykier wrote:
> Are you aware that 37 out of 40 of your packages can currently be build
> reproducible in unstable using the patched toolchain (e.g. dpkg and
> debhelper). This (I presume) is without you having done anything to
> make them explicitly reproducible.
Actua
❦ 24 août 2015 21:12 +0100, Colin Tuckley :
>> Well, I object strongly.
>
> Same here, in my view reproducibility is a 'nice to have' it should
> *never* be forced on a package.
>
> We are in the business of packaging upstream software for
> distribution. We should not make arbitrary changes to
Hi,
On 2015-08-24 22:06, Matthias Klose wrote:
> [...] So what about identifying categories which should be fixed in any
> case, and maybe which should have special rules for accelerated NMUs and such?
Personally, I find that proposal quite interesting.
> Categories would include:
>
> - runnin
Hi,
On 2015-08-24 22:12, Colin Tuckley wrote:
> [...]
> Same here, in my view reproducibility is a 'nice to have' it should
> *never* be forced on a package.
>
> We are in the business of packaging upstream software for
> distribution. We should not make arbitrary changes to upstream
> software
Package: wnpp
Severity: wishlist
Owner: Daniel Stender
* Package name: afl-cov
Version : 0.3
Upstream Author : Michael Rash
* URL : https://github.com/mrash/afl-cov
* License : GPL-2
Programming Lang: Python
Description : monitor coverage from afl-fuzz
On 2015-08-24 21:24, Santiago Vila wrote:
> [...]
>
Hi Santiago,
> Making a great percentage of packages in the archive to be "suddenly"
> buggy is unacceptable.
>
I can see where you are coming from. I have to admit that I am
personally not too concerned with the severity change. Given it i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 24/08/15 20:24, Santiago Vila wrote:
> Well, I object strongly.
Same here, in my view reproducibility is a 'nice to have' it should
*never* be forced on a package.
We are in the business of packaging upstream software for
distribution. We shoul
On 08/23/2015 12:48 PM, Chris Lamb wrote:
> Hi -devel,
>
> The reproducible-builds team are currently contributing patches with
> "wishlist" severity.
>
> This is because it is not currently possible to build reproducible
> packages within sid itself - we maintain a separate repository whilst
> o
On Sun, Aug 23, 2015 at 12:48:50PM +0200, Chris Lamb wrote:
> The reproducible-builds team are currently contributing patches with
> "wishlist" severity.
>
> This is because it is not currently possible to build reproducible
> packages within sid itself - we maintain a separate repository whilst
>
On Sun, Aug 23, 2015 at 12:48:50PM +0200, Chris Lamb wrote:
> Hi -devel,
>
> The reproducible-builds team are currently contributing patches with
> "wishlist" severity.
>
> This is because it is not currently possible to build reproducible
> packages within sid itself - we maintain a separate rep
On 08/21/2015 01:12 PM, Simon McVittie wrote:
> On 18/08/15 00:37, Steve Langasek wrote:
>> On Mon, Aug 17, 2015 at 01:46:16PM +0100, Simon McVittie wrote:
>>> Having done more rebuilds in Ubuntu, it would be great if you could
>>> publish a complete list of the transitions you believe to be necess
On Aug 22 2015, Steve Langasek wrote:
> On Sat, Aug 22, 2015 at 09:54:10PM -0700, Nikolaus Rath wrote:
>> Hello,
>
>> I'm struggling to understand the testing excuses for s3ql at
>> https://qa.debian.org/excuses.php?package=s3ql. Among other things, it
>> says:
>
>> * s3ql (source, amd64, i386, ar
[crossposting to -devel and -perl; M-F-T set to -devel]
There's a Perl transition (#796345) expected in the next couple of
months: Perl 5.22 packages have been in experimental since June, and
the list of blockers is getting lower. The worst blocker is currently
libapache2-mod-perl2, which needs up
Hi.
Chris Lamb writes:
> Hi -devel,
>
> The reproducible-builds team are currently contributing patches with
> "wishlist" severity.
>
> This is because it is not currently possible to build reproducible
> packages within sid itself - we maintain a separate repository whilst
> our changes to the
On 08/24/2015 01:54 PM, Simon Josefsson wrote:
> I believe the blog post below has relevance to Debian's stance on
> including minified JavaScript in packages:
>
> https://zyan.scripts.mit.edu/blog/backdooring-js/
>
> To me the problem suggests that it is important from a security and
> accountab
I believe the blog post below has relevance to Debian's stance on
including minified JavaScript in packages:
https://zyan.scripts.mit.edu/blog/backdooring-js/
To me the problem suggests that it is important from a security and
accountability perspective to 1) include the human-readable source cod
On Mon, Aug 24, 2015 at 11:32 AM, Paul Wise wrote:
> On Mon, Aug 24, 2015 at 1:41 AM, Jakub Wilk wrote:
>
>> Is BTS version tracking documented in details anywhere?
>
> Some info is here:
Some more here:
https://wiki.debian.org/HowtoUseBTS#Version_tracking
--
bye,
pabs
https://wiki.debian.org/
On Mon, Aug 24, 2015 at 1:41 AM, Jakub Wilk wrote:
> Is BTS version tracking documented in details anywhere?
Some info is here:
https://wiki.debian.org/BugsVersionTracking
--
bye,
pabs
https://wiki.debian.org/PaulWise
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Debian Developers,
due to no replies in the list might seem that nobody is worried about
a brew like tool in Debian.
If nobody has objections, I'll upload in new queue at the end of the
package revision (there are still some issues to address).
38 matches
Mail list logo
