Re: Release sprint results - team changes, auto-rm and arch status
Some precision about the MIPS machines: On Thu, Nov 28, 2013 at 09:04:56PM +0100, Niels Thykier wrote: > * [mips, mipsel] buildds/porterboxes run on hardware which is very old or > has known defects: >- mips octeon is unstable Better me more precise there, Octeon machines in general are very stable. That said out of the three machines we have in Debian, two are unstable, the other one is very stable. We never really understood why, we only have remarked they have different CPU revision number. >- mipsel loongson have CPU bugs I see on http://release.debian.org/jessie/arch_qualify.html that it concerns the "NOP implementation error" from Loongson 2F. Debian is using Loongson 2E for buildds and porters machines, which are not affected by this issue. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131129082243.ga9...@hall.aurel32.net
Re: Release sprint results - team changes, auto-rm and arch status
On Thu, Nov 28, 2013 at 09:04:56PM +0100, Niels Thykier wrote: > Note that s390x and powerpc could also do with more porters, but at > this time we are not giving an official warning for them. I see on http://release.debian.org/jessie/arch_qualify.html that you are concerned by the fact s390x is still using gcc 4.6. This has been decided to switch to gcc-4.8 a few weeks ago and it has been already implemented in the SVN. It's only waiting for an upload from Matthias Klose. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131129082250.ga10...@hall.aurel32.net
Re: Release sprint results - team changes, auto-rm and arch status
Le jeudi 28 novembre 2013 à 21:04 +0100, Niels Thykier a écrit : > We have stopped considering ia64 as a blocker for testing > migration. > The architectures sparc, mips and mipsel also cause concern: > kFreeBSD was a technology preview, and has not generated enough user > interest to bring in sufficient install base to continue in this > state. > s390 and Hurd will not be release architectures for Jessie. Two words: THANK. YOU. -- .''`.Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1385714898.24216.1074.camel@dsp0698014
Re: Release sprint results - team changes, auto-rm and arch status
On 11/29/2013 09:48 AM, Josselin Mouette wrote: >> s390 and Hurd will not be release architectures for Jessie. > > Two words: THANK. YOU. However, m68k will be. *preparing to run as fast as I can* -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/529855e3.5040...@physik.fu-berlin.de
Re: Release sprint results - team changes, auto-rm and arch status
Le 28/11/2013 21:52, Niels Thykier a écrit : >> I've found the builds on the less used architectures have been useful >> for flushing out unusual bugs, particularly when the code ships with >> many test cases and it exposes problems for big endian machines, etc. >> >> Also, kFreeBSD and HURD are both kind of special in that they are not >> Linux, it would be good to keep one or the other around even if other >> architectures are culled more aggressively. >> > > Keeping them around is different from them being considered as release > architectures (or even just keeping them in testing). Keeping these > architectures in testing do involve a burden, like blocking testing > migration when they FTBFS[1]. And what about (somehow automatically, like RC-buggy packages) removing packages from testing only on these architectures? Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52985e1f.2080...@debian.org
Re: Release sprint results - team changes, auto-rm and arch status
On Thu, 2013-11-28 at 21:04 +0100, Niels Thykier wrote: > In this new and exciting update from your Debian Release Team... > kFreeBSD was a technology preview, and has not generated enough user > interest to bring in sufficient install base to continue in this > state. > > We will review this situation after 28th January 2014. > s390 and Hurd will not be release architectures for Jessie. s390 was > replaced by s390x in Wheezy and this completes that transition. As > for Hurd; we do not believe it is ready. Particularly, we believe > that it does not surpass kFreeBSD in user interest or install base. Any chances of having Hurd as a technology preview, like kFreeBSD was for squeeze? A lot of development has been going on lately, and the number of committed people is higher than for many of the release architectures. Of course RC bugs for GNU/Hurd should not hinder transitions of packages to testing, as pointed out earlier. Thanks! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1385718518.3926.24.ca...@g3620.my.own.domain
Re: Release sprint results - team changes, auto-rm and arch status
On 11/29/13 10:22, Aurelien Jarno wrote: On Thu, Nov 28, 2013 at 09:04:56PM +0100, Niels Thykier wrote: * [mips, mipsel] buildds/porterboxes run on hardware which is very old or has known defects: - mips octeon is unstable Better me more precise there, Octeon machines in general are very stable. That said out of the three machines we have in Debian, two are unstable, the other one is very stable. We never really understood why, we only have remarked they have different CPU revision number. Octeon is one of the most active MIPS ports in Linux upstream. Lately, there is renewed interest in this platform, due to some new Octeon-based router products by Ubiquity being extremely cheap, performant and hence, relatively speaking, very popular. Those run a modified Debian distribution (*not* a derivative, Debian's apt sources are recommended by the vendor) This obviously isn't sufficient for Debian to consider mips as a release architecture, but the statement "octeon is unstable" is obviously overly broad and incorrect, as Aurelien also points out. Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52985dce.3080...@debian.org
Role of Release Goals (Was: Release sprint results - team changes, auto-rm and arch status)
On 28/11/13 at 21:04 +0100, Niels Thykier wrote: > Release Goals > = > > We discussed release goals in some depth at the recent sprint. > > The general consensus was that, whilst release goals have been useful > in the past to introduce archive-wide changes, we should review > whether this remains the case and whether the release team is really > the right place to determine them. We intend to consult with the > project on this point in due course. Indeed. To elaborate a bit more: Release Goals are usually distribution-wide changes to Debian. We have had release goals for a long time (see e.g. [1] about etch release goals, in 2006). Release Goals seem to have several purposes: - in the past, specific NMU rules applied to release goals. However, that is no longer the case. It is already possible to NMU for any bug (including wishlist ones) provided that reasonable advance notice and effort to consult the maintainer is applied. - in the past, uploads fixing release goals bugs were allowed during freeze. However, at this point, it is not clear whether this will be the case for jessie. It would be better to aim for fixing all release goals bugs before the freeze, and do a shorter freeze. - Release Goals kind-of define Debian's technical agenda. However, one could question whether it's really the role of the release team to decide on this, rather than the one of the project at large. Shouldn't this be discussed the usual Debian way (= discussion on mailing list to gather feedback and reach consensus on the global picture; then do-ocracy for the smaller implementation details)? I personnally think that we should give up on the release goals process in its current form, and instead advertise recommended practices, built on the existing recommended practices for mass-bug filings[2], such as: - aim for a consensus-building discussion on -devel@ - provide a clear plan of what you are trying to achieve (with rationale, evaluation of impact, etc.) (using a wiki page or another type of structured document is a good idea) - provide objectives that are S.M.A.R.T[3] (specific, measurable, attainable, relevant and time-bound), so that it's easy to understand where you want to go. - use usertags to track progress - etc. If there is consensus that a given change and its implementation is desired by the project, I don't see what some validation from the release team would add. And if some maintainers refuse to integrate patches for a consensual change, we already have existing processes, such as bringing issues to the TC. Comments? Lucas [1] https://lists.debian.org/debian-devel-announce/2006/07/msg5.html [2] http://www.debian.org/doc/manuals/developers-reference/beyond-pkging.en.html#submit-many-bugs [3] http://en.wikipedia.org/wiki/SMART_criteria -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131129100255.ga19...@xanadu.blop.info
Re: Release sprint results - team changes, auto-rm and arch status
On Fri, 2013-11-29 at 09:22 +0100, Aurelien Jarno wrote: > Some precision about the MIPS machines: > > On Thu, Nov 28, 2013 at 09:04:56PM +0100, Niels Thykier wrote: > > * [mips, mipsel] buildds/porterboxes run on hardware which is very old or > > has known defects: > >- mips octeon is unstable > > Better me more precise there, Octeon machines in general are very > stable. That said out of the three machines we have in Debian, two are > unstable, the other one is very stable. We never really understood why, > we only have remarked they have different CPU revision number. Whatever, mips has one reliable buildd which is not enough. > >- mipsel loongson have CPU bugs > > I see on http://release.debian.org/jessie/arch_qualify.html that it > concerns the "NOP implementation error" from Loongson 2F. Debian is > using Loongson 2E for buildds and porters machines, which are not > affected by this issue. They are affected by that or a very similar issue, as demonstrated by Jo Shields recently: http://apebox.org/wordpress/rants/545/ Ben. -- Ben Hutchings Usenet is essentially a HUGE group of people passing notes in class. - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette' signature.asc Description: This is a digitally signed message part
Re: Release sprint results - team changes, auto-rm and arch status
On Fri, Nov 29, 2013 at 01:57:39PM +, Ben Hutchings wrote: > On Fri, 2013-11-29 at 09:22 +0100, Aurelien Jarno wrote: > > Some precision about the MIPS machines: > > > > On Thu, Nov 28, 2013 at 09:04:56PM +0100, Niels Thykier wrote: > > > * [mips, mipsel] buildds/porterboxes run on hardware which is very old > > > or has known defects: > > >- mips octeon is unstable > > > > Better me more precise there, Octeon machines in general are very > > stable. That said out of the three machines we have in Debian, two are > > unstable, the other one is very stable. We never really understood why, > > we only have remarked they have different CPU revision number. > > Whatever, mips has one reliable buildd which is not enough. Two actually with ball.d.o which is not an octeon. My point is to say that Octeon boxes are not unstable, but the Octeon boxes *we have* as part of the Debian infrastructure are unstable. This of course has to be fixed. > > >- mipsel loongson have CPU bugs > > > > I see on http://release.debian.org/jessie/arch_qualify.html that it > > concerns the "NOP implementation error" from Loongson 2F. Debian is > > using Loongson 2E for buildds and porters machines, which are not > > affected by this issue. > > They are affected by that or a very similar issue, as demonstrated by Jo > Shields recently: http://apebox.org/wordpress/rants/545/ > MUL is a MIPS32 instruction, which is not present on MIPS3 CPUs like the Loongson 2, MULT + MFLO should be used instead. There is no CPU bug there, it's like trying to build x86 code with SSE4 instructions, and then saying that all x86 CPUs which do not support the SSE4 instructions are buggy. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131129141214.gb14...@ohm.rr44.fr
Re: Release sprint results - team changes, auto-rm and arch status
On 2013-11-28 21:04, Niels Thykier wrote: > In this new and exciting update from your Debian Release Team... Thanks for the updates! > Architecture Status > === > > ia64 causes us concern for the following reasons: > We have stopped considering ia64 as a blocker for testing > migration. This means that the out-of-date and uninstallability > criteria on ia64 will not hold up transitions from unstable to testing > for packages. It is expected that unless drastic improvement occurs, > ia64 will be removed from testing on Friday 24th January 2014. What is the correct way to handle FTBFS (or other RC) bugs that only affect ia64 (and therefore will block migration): * downgrade severity to non-RC? * tag jessie-ignore? * wait for 2014-01-24? * ... E.g. #650753 Andreas PS: I remember some recent discussion about arch or port tags/pseudopackages/... that seems to have died without actions :-( -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5298a6e8.1020...@debian.org
Bug#730785: ITP: libcatalyst-actionrole-queryparameter-perl -- Dispatch rules using query parameters
Package: wnpp Owner: Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 (CPAN/PAUSE) Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libcatalyst-actionrole-queryparameter-perl Version : 0.04 Upstream Author : John Napiorkowski * URL : https://metacpan.org/release/Catalyst-ActionRole-QueryParameter * License : Artistic or GPL-1+ Programming Lang: Perl Description : Dispatch rules using query parameters Catalyst::ActionRole::QueryParameter provides a Catalyst reusable action role that lets you require conditions on request query parameters as part of your dispatch matching. It can be useful for for delegating work to various actions inside your controller based on what the incoming query parameters say. signature.asc Description: PGP signature
Bug#730786: ITP: libcatalyst-actionrole-checktrailingslash-perl -- Test URI path for trailing slash and redirect if needed
Package: wnpp Owner: Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 (CPAN/PAUSE) Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libcatalyst-actionrole-checktrailingslash-perl Version : 0.01 Upstream Author : Anatoliy Lapitskiy * URL : https://metacpan.org/release/Catalyst-ActionRole-CheckTrailingSlash * License : Artistic or GPL-1+ Programming Lang: Perl Description : Test URI path for trailing slash and redirect if needed Catalyst::ActionRole::CheckTrailingSlash provides a Catalyst reusable action role that tests whether the request URI ends with a slash. If not, it permanently redirects to the URI with a trailing slash. signature.asc Description: PGP signature
Bug#730787: ITP: libjson-multivalueordered-perl -- handle JSON like {"a":1, "a":2}
Package: wnpp
Owner: Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 (CPAN/PAUSE)
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org
* Package name: libjson-multivalueordered-perl
Version : 0.004
Upstream Author : Toby Inkster
* URL : https://metacpan.org/release/JSON-MultiValueOrdered
* License : Artistic or GPL-1+
Programming Lang: Perl
Description : handle JSON like {"a":1, "a":2}
A hash tied to this class acts more or less like a standard hash,
except that when you assign a new value to an existing key, the old
value is retained underneath. An explicit delete deletes all values
associated with a key.
By default, the old values are inaccessible through the hash interface,
but can be retrieved via the tied object:
my @values = tied(%hash)->get($key);
However, the fetch_* methods provide a means to alter the behaviour of
the hash.
signature.asc
Description: PGP signature
Bug#730791: ITP: libjson-pointer-perl -- Perl implementation of JSON Pointer
Package: wnpp Owner: Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 (CPAN/PAUSE) Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libjson-pointer-perl Version : 0.01 Upstream Author : Toru Yamaguchi * URL : https://metacpan.org/release/JSON-Pointer * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl implementation of JSON Pointer JSON::Pointer implements JSON Pointer draft-09 (http://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-09) and some useful operators from JSON Patch draft-10 (http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-10). JSON Pointer is able to retrieve a value from a specific location with a syntax similar to XPath. signature.asc Description: PGP signature
Bug#730790: ITP: libcatalyst-actionrole-requiressl-perl -- Force an action to be secure only.
Package: wnpp Owner: Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 (CPAN/PAUSE) Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libcatalyst-actionrole-requiressl-perl Version : 0.07 Upstream Author : Simon Elliott * URL : https://metacpan.org/release/Catalyst-ActionRole-RequireSSL * License : Artistic or GPL-1+ Programming Lang: Perl Description : Force an action to be secure only. Catalyst::ActionRole::RequireSSL provides a Catalyst reusable action role that lets you enforce that a request/response must happen over secure sockets. signature.asc Description: PGP signature
Re: Release sprint results - team changes, auto-rm and arch status
On 29/11/13 04:14, Steve Langasek wrote: > Hi Niels, > > On Thu, Nov 28, 2013 at 09:04:56PM +0100, Niels Thykier wrote: >> kFreeBSD was a technology preview, and has not generated enough user >> interest to bring in sufficient install base to continue in this >> state. > I wonder, how is the release team measuring this? For the other ports that > you mention, you've pointed to concrete technical problems that are in line > with the previously-documented release qualification guidelines. kfreebsd, > OTOH, is only listed as having "insufficient install base". But what is > sufficient? http://popcon.debian.org/ shows numbers for kfreebsd-* that are > greater than a number of our ports. > > You rightly point out that keeping the architectures in testing has a cost, > because the architectures will block testing migration. But are the > kfreebsd archs actually causing testing blockages, in practice? If there > are such blockages, can you give us more information about how this has been > the case? I have had unusual issues on kFreeBSD with reSIProcate although that is partly because the unit tests are so exhaustive that they expose obscure bugs, e.g. http://list.resiprocate.org/archive/resiprocate-devel/msg08488.html It could be argued that the "cost" of these other architectures is not a one-sided equation - their presence contributes in some way to the overall quality of the software that people include in Debian. So the net cost may be lower than people really think, but of course that doesn't take away the fact that it is a cost that has to be paid to keep these ports there. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5298b686.8030...@pocock.com.au
Bug#730794: ITP: libcatalyst-plugin-enablemiddleware-perl -- Enable Plack Middleware via Configuration
Package: wnpp Owner: Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 (CPAN/PAUSE) Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libcatalyst-plugin-enablemiddleware-perl Version : 0.006 Upstream Author : John Napiorkowski * URL : https://metacpan.org/release/Catalyst-Plugin-EnableMiddleware * License : Artistic or GPL-1+ Programming Lang: Perl Description : Enable Plack Middleware via Configuration Catalyst::Plugin::EnableMiddleware is a plug-in for the Catalyst framework that allows you to enable Plack middlewares from within the application via configuration. The middlewares serve to better componentize and re-use your code. signature.asc Description: PGP signature
Bug#730793: ITP: libdigest-sha3-perl -- Perl extension for SHA-3
Package: wnpp Owner: Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 (CPAN/PAUSE) Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libdigest-sha3-perl Version : 0.08 Upstream Author : Mark Shelor, mshe...@cpan.org * URL : https://metacpan.org/release/Digest-SHA3 * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl extension for SHA-3 Digest::SHA3 is a complete implementation of the NIST SHA-3 cryptographic hash function, known originally as Keccak. It gives Perl programmers a convenient way to calculate SHA3-224, SHA3-256, SHA3-384, and SHA3-512 message digests, as well as variable-length hashes using the SHA3-0 variant. The module can handle all types of input, including partial-byte data. signature.asc Description: PGP signature
Re: Release sprint results - team changes, auto-rm and arch status
Daniel Pocock writes ("Re: Release sprint results - team changes, auto-rm and
arch status"):
> I have had unusual issues on kFreeBSD with reSIProcate although that is
> partly because the unit tests are so exhaustive that they expose obscure
> bugs, e.g.
> http://list.resiprocate.org/archive/resiprocate-devel/msg08488.html
I think this is a good example of the kind of bug that is sometimes
blamed on a port even though it probably isn't really a port-specific
bug.
It seems likely to me that that bug is, at root, a race of some kind.
And it just so happens that the race is lost on kFreeBSD - sometimes.
Detecting such a race is valuable to the project; it's certainly not a
disbenefit. After all, a race that happens to us sometimes is likely
to happen to users sometimes. Debugging races in the field is very
difficult. Much better to have them show up in a porter's build test,
than to have them show up later on users' machines.
So if anything, I think bugs like this one are an argument for keeping
kFreeBSD (and other minority ports) with as high a status as
practical; not an argument for throwing it out.
> It could be argued that the "cost" of these other architectures is not a
> one-sided equation - their presence contributes in some way to the
> overall quality of the software that people include in Debian.
Exactly.
> So the net cost may be lower than people really think, but of
> course that doesn't take away the fact that it is a cost that has to
> be paid to keep these ports there.
We should be wary of setting the clearly visible and accountable costs
of keeping a port, up against the difficult to measure and mostly
invisible benefits in terms of reduced need to do in-the-field
diagnosis of obscure bugs (for us and our users).
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/21144.49806.334906.353...@chiark.greenend.org.uk
Re: Release sprint results - team changes, auto-rm and arch status
On 29/11/13 16:36, Ian Jackson wrote: > It seems likely to me that that bug is, at root, a race of some kind. > And it just so happens that the race is lost on kFreeBSD - sometimes. > > Detecting such a race is valuable to the project; it's certainly not a > disbenefit. After all, a race that happens to us sometimes is likely > to happen to users sometimes. Yes, to a point. On the other hand, each RC architecture where build-time tests are fatal inflates some subset of "ordinary bugs" to Severity:serious - if we'd seen this bug (or a similar "sometimes-fails" bug) "in real life", even if there's a way to reproduce it on (say) x86 Linux, would it necessarily have RC severity? Perhaps this particular bug would - I have no idea how often it happens, or what functionality it breaks - but Daniel's phrasing implied that this particular regression test suite is far more thorough than what we'd consider to be "a major effect on the usability of a package" (Severity:important). S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5298cda1.1060...@debian.org
Re: Technical committee appointment
Lucas Nussbaum writes: > Keith, welcome to our Technical Committee! Thanks, Lucas, and all of the rest of the Debian Tech Committee for your support. I look forward to serving the Debian project in this additional role to the best of my ability. -- keith.pack...@intel.com pgpWC0RklOgW2.pgp Description: PGP signature
Re: Role of Release Goals (Was: Release sprint results - team changes, auto-rm and arch status)
On Fri, Nov 29, 2013 at 11:02:55AM +0100, Lucas Nussbaum wrote: > On 28/11/13 at 21:04 +0100, Niels Thykier wrote: > > Release Goals > > = > > > > We discussed release goals in some depth at the recent sprint. > > > > The general consensus was that, whilst release goals have been useful > > in the past to introduce archive-wide changes, we should review > > whether this remains the case and whether the release team is really > > the right place to determine them. We intend to consult with the > > project on this point in due course. > Indeed. To elaborate a bit more: > Release Goals are usually distribution-wide changes to Debian. We have had > release goals for a long time (see e.g. [1] about etch release goals, in > 2006). Release Goals seem to have several purposes: > - in the past, specific NMU rules applied to release goals. However, that > is no longer the case. It is already possible to NMU for any bug (including > wishlist ones) provided that reasonable advance notice and effort to > consult the maintainer is applied. I think that misstates the rationale for release goals. It was *always* possible to NMU for any bug "provided reasonable advanced notice and consultation". The point of declaring a release goal is that, for a distribution-wide change that touches many packages, following the standard SRU process where each upload requires a built-in waiting period significantly slows down progress. So having a relaxed NMU policy for recognized project-wide goals, allowing release goal NMUs to be done quickly as part of bug squashing parties, benefits the project by letting us reach these goals much more effectively. > - Release Goals kind-of define Debian's technical agenda. However, one could > question whether it's really the role of the release team to decide on > this, rather than the one of the project at large. Shouldn't this be > discussed the usual Debian way (= discussion on mailing list to gather > feedback and reach consensus on the global picture; then do-ocracy for > the smaller implementation details)? We're not talking about small implementation details. What do you propose as a mechanism for agreeing to a reduced NMU delay for archive-wide changes? The release team may not be the right way to get this done organizationally, but a strict consensus-driven process on debian-devel is also not realistic as we will never converge on a decision in a reasonable amount of time. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Role of Release Goals (Was: Release sprint results - team changes, auto-rm and arch status)
On Fri, 29 Nov 2013 12:01:31 -0600, Steve Langasek wrote: > On Fri, Nov 29, 2013 at 11:02:55AM +0100, Lucas Nussbaum wrote: > >> - Release Goals kind-of define Debian's technical agenda. However, one >> could >> question whether it's really the role of the release team to decide >> on this, rather than the one of the project at large. Shouldn't this >> be discussed the usual Debian way (= discussion on mailing list to >> gather feedback and reach consensus on the global picture; then >> do-ocracy for the smaller implementation details)? > > We're not talking about small implementation details. What do you > propose as a mechanism for agreeing to a reduced NMU delay for > archive-wide changes? > The release team may not be the right way to get this done > organizationally, > but a strict consensus-driven process on debian-devel is also not > realistic as we will never converge on a decision in a reasonable amount > of time. Something similar to DEPs could be useful in this regard. For the purposes of release goals, though, the requirements for passing from DRAFT to CANDIDATE should be defined, to avoid endless discussions (say, a number N of seconds). -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/l7ao87$qot$1...@ger.gmane.org
Re: Release sprint results - team changes, auto-rm and arch status
On 29/11/13 18:23, Simon McVittie wrote: > On 29/11/13 16:36, Ian Jackson wrote: >> It seems likely to me that that bug is, at root, a race of some kind. >> And it just so happens that the race is lost on kFreeBSD - sometimes. >> >> Detecting such a race is valuable to the project; it's certainly not a >> disbenefit. After all, a race that happens to us sometimes is likely >> to happen to users sometimes. > > Yes, to a point. On the other hand, each RC architecture where > build-time tests are fatal inflates some subset of "ordinary bugs" to > Severity:serious - if we'd seen this bug (or a similar "sometimes-fails" > bug) "in real life", even if there's a way to reproduce it on (say) x86 > Linux, would it necessarily have RC severity? > > Perhaps this particular bug would - I have no idea how often it happens, > or what functionality it breaks - but Daniel's phrasing implied that > this particular regression test suite is far more thorough than what > we'd consider to be "a major effect on the usability of a package" > (Severity:important). > The test suite is executed on every upload and if it isn't 100% successful the build fails and the package does not propagate on any platform. This race condition is 100% reproducible on the porter boxes too, I'm yet to find the root cause though. Of particular note, it only occurs on some of the more recent builds, so it appears to have been introduced by some upstream change in the last 6 months. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5298ec78.70...@pocock.com.au
Re: Release sprint results - team changes, auto-rm and arch status
On Friday, November 29, 2013, Aurelien Jarno wrote: > Some precision about the MIPS machines: > > On Thu, Nov 28, 2013 at 09:04:56PM +0100, Niels Thykier wrote: > > * [mips, mipsel] buildds/porterboxes run on hardware which is very old > or has known defects: >- mips octeon is unstable > > Better me more precise there, Octeon machines in general are very > stable. That said out of the three machines we have in Debian, two are > unstable, the other one is very stable. We never really understood why, > we only have remarked they have different CPU revision number. > > >- mipsel loongson have CPU bugs > > I see on http://release.debian.org/jessie/arch_qualify.html that it > concerns the "NOP implementation error" from Loongson 2F. Debian is > using Loongson 2E for buildds and porters machines, which are not > affected by this issue. > > I've got anther 3A board today, which is an official product of Loongson, Inc. that can be purchased on the market. We have made
Re: Release sprint results - team changes, auto-rm and arch status
(Re-posting, pressed send accidentally.) On Friday, November 29, 2013, Aurelien Jarno wrote: > Some precision about the MIPS machines: > > On Thu, Nov 28, 2013 at 09:04:56PM +0100, Niels Thykier wrote: > > * [mips, mipsel] buildds/porterboxes run on hardware which is very old > or has known defects: > >- mips octeon is unstable > > Better me more precise there, Octeon machines in general are very > stable. That said out of the three machines we have in Debian, two are > unstable, the other one is very stable. We never really understood why, > we only have remarked they have different CPU revision number. > > >- mipsel loongson have CPU bugs > > I see on http://release.debian.org/jessie/arch_qualify.html that it > concerns the "NOP implementation error" from Loongson 2F. Debian is > using Loongson 2E for buildds and porters machines, which are not > affected by this issue. > > We've got anther 3A board today, which is an official product of Loongson, Inc. that can be purchased on the market. We are able to run a Sid mips64el system on the board without any visible glitch like the previous one from Lemote, so I think 3A boards like the ones we have are really good candidates for replacing old mipsel buildds and porter boxes. They are much faster (by being quad-core, and some boards have 2 CPU config), and support larger memory (standard config is 4GB). Also there are willing party that is considering donating several to Debian. What we need to fix are their kernels and PMON: 1. Kernel support isn't upstreamed, and we have only succeeded in merging the patch set to 3.6 and some lower versions which can produce a working binary. We are running 3.6 for Lemote products and 2.6.36 for Loongson ones. 2. Different boards use quite different PMON, most of them support 2GB DDR3 RDIMM, so the maximum configuration will be limited to 4x2GB. This could be a smaller issue comparing with the first one though, we are working with Lemote to see if 8GB UDIMM can be officially supported on their boards. Thanks, Aron -- Regards, Aron Xu
git-cache-proxy (in chiark-scripts 4.3.0)
chiark-scripts now contains a program called "git-cache-proxy", which
does what its name suggests. I thought people might find this useful
enough that it would be worth plugging it here.
The doc comment follows.
Sadly there is no manpage yet, and it isn't suitable for exposing to
completely untrustworthy clients since it can probably be DoSsed by a
sufficiently broken (or sufficiently malicious) client. I have ideas
about how to fix that, but it involves a lot more code than there is
right now.
(4.3.0 is in incoming right now; source already available from alioth
with dgit.)
Ian.
# git caching proxy
# Suitable only for exposing to semi-trusted clients: clients are not
# supposed to be able to take over the server. However, clients can
# probably deny service to each other because the current
# implementation is not very good at handling various out-of-course
# situations (notably, clients which are too slow).
# usage: run it on some port, and then clone or fetch
# "git://:/[ ]"
# where is http:///... or git:///...
# and is zero or more (whitespace-separated) of
#[] will be ignored if not recognised
#{} error if not recognised
# options currently known:
#fetch=must fail if the fetch/clone from upstream fails
#fetch=no just use what is in the cache
#fetch=tryuse what is in the cache if the fetch/clone fails
#timeout=length of time to allow for fetch/clone
# example inetd.conf line:
# 9419 stream tcp nowait git-cache /usr/bin/git-cache-proxy git-cache-proxy
# you'll need to
# adduser git-cache
# mkdir /var/cache/git-cache-proxy
# chown git-cache /var/cache/git-cache-proxy
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21145.1193.866342.250...@chiark.greenend.org.uk
Bug#730827: ITP: light-locker -- simple screen locker for LightDM display manager
Package: wnpp Severity: wishlist Owner: pkg-xfce-de...@lists.alioth.debian.org * Package name: light-locker Version : 1.1.0-1 Upstream Author : William Jon McCann, Peter de Ridder, Simon Steinbeiß * URL : https://github.com/the-cavalry/light-locker/ * License : GPL Programming Lang: C Description : simple screen locker for LightDM display manager light-locker is a simple locker that aims to have simple, sane, secure defaults and be well integrated with the desktop while not carrying any desktop-specific dependencies. . It relies on lightdm for locking and unlocking your session via ConsoleKit/UPower or logind/systemd. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131129213658.31627.85528.reportbug@scapa
Re: Release sprint results - team changes, auto-rm and arch status
Le Fri, Nov 29, 2013 at 04:45:10PM +0100, Daniel Pocock a écrit : > > It could be argued that the "cost" of these other architectures is not a > one-sided equation - their presence contributes in some way to the > overall quality of the software that people include in Debian. So the > net cost may be lower than people really think, but of course that > doesn't take away the fact that it is a cost that has to be paid to keep > these ports there. Hello Daniel, I think that the mere ‘presence’ as a release architecture sould not be counted on the positive side of the equation, because one can definitely perform mass screening for bugs by rebuilding the archive on non-release architectureps. This is similar in spirit to the Mayhem project that reported 4,801 bugs this summer (http://forallsecure.com/mayhem.html). Having Debian as an intermediate between mass-screeners and upstream authors is a big work overhead for us, or at least for me. The more we screen, the more it means that I need to concentrate on the old software at the expense of the new software, and become an human email proxy instead of a software packager. I am somehow glad to provide this service from time to time, but I also think that it is the duty of the people interested in mass-screens to innovate and find ways to reach upstream directly. Of course, Debian can help with projects such as the ‘new PTS‘ or http://upstream-metadata.debian.net/. By the way, thanks to the release team for the very nice summary that started this thread, for the auto-removals, and everything else. Have a nice week-end, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131130012105.ga19...@falafel.plessy.net
Bug#730843: ITP: ruby-puppetlabs-spec-helper/ -- contains rake tasks and a standard spec helper for running spec tests on puppet modules
Package: wnpp Severity: wishlist Owner: Thomas Bechtold * Package name: ruby-puppetlabs-spec-helper/ Version : 0.4.1 Upstream Author : Puppet Labs * URL : https://rubygems.org/gems/puppetlabs_spec_helper * License : Apache-2.0 Programming Lang: Ruby Description : contains rake tasks and a standard spec helper for running spec tests on puppet modules Puppet lets you centrally manage every important aspect of your system using a cross-platform specification language that manages all the separate elements normally aggregated in different files, like users, cron jobs, and hosts, along with obviously discrete elements like packages, services, and files. . This ruby module contains some rake tasks for running spec tests on puppet modules. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131130063304.2702.34173.reportbug@steinpilz
