Archive rebuild failures and the clean target

2013-10-07 Thread Thibaut Paumard
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

I see "serious" FTBFS bugs appearing on my packages when people try to
rebuild the entire archive.

Those failures are due to attempting to run the clean target prior to
anything else.

While it's nice when debian/rules clean works even on already clean
source, it's by no means mandated by policy.

I think people who do full archive rebuilds should fix their scripts
to not clean before building, or file "wishlist" bugs instead of
"serious" when the failure occurs in the initial clean.

Regards, Thibaut.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJSUnaQAAoJEJOUU0jg3ChADIoP/RgJ2o3zOHef3JbH+7LlVid0
7YDYoTU9hRqOaVAPPDmQcui9Y4i46yKr+9aW8Vx4fTjP1dBECwrrFlTnA2V0WSVh
KffS/S/qnKJtIQzDThu/rWWpWLqoxH5oxsdaB0RrHxodktTTtTBirFP6funx0Y3s
2tTM5bXjLmdij6+WuV5J3k2hT5B7/FSj8RuSAjc6OEBC+WqNIByMDCIv2TT4AqG+
qWZmtXrxyrz+Az31SiCJZPiHy4OxThbAHIVVdO3LzGDmpjaKxNGb2hZNdLvvvP3Y
WRzNGy7BTvldy68FWCxC0Zhj5+JzOYzH4b2u9ociWOPvpoV1oSPhAEReUhf5fbSN
YsTCokkA14Oz+OMXgW5kFKseJ44W1RuZLednzSNYFD8sNWG47qO7BTr4hhxIBEy8
5ntBnCYpPNYaRR2uByIVnl/AJ/HPDo8gfxm6OscDtaoG67Sy0+GYW2lrLBCDlBMg
JesQIedrJgZ+eWruuyzTGyXyC7HLqk2iBkcSRWlVgMrrkH1CqjqQvxJWkTi9NemL
7Fm+l4ZgvofQdjjRXr6THZL80hzyBICqHSRghuzhj9P+pWQK7DHwdgCfBtYYK0u1
1F/ZHKPrFWe65JBVpH4FNGDVV6uFZem1n5+/3gDWZRv1pwOaYPvXL5ghV4F/A2Km
+3b6GVY8bzTc2h9TSf6x
=r8Hh
-END PGP SIGNATURE-


-- 
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/5252769a.9060...@debian.org



Re: Archive rebuild failures and the clean target

2013-10-07 Thread Paul Wise
Running debian/rules clean is the default behaviour of
dpkg-buildpackage and of the buildds:

https://buildd.debian.org/status/fetch.php?pkg=ibniz&arch=i386&ver=1.18-1&stamp=1380517808

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/CAKTje6HRx6xijaJNjAG59fTWRm+Gw1MozzmWOe7TS7qR=rx...@mail.gmail.com



Re: Archive rebuild failures and the clean target

2013-10-07 Thread Sven Joachim
On 2013-10-07 10:53 +0200, Thibaut Paumard wrote:

> I see "serious" FTBFS bugs appearing on my packages when people try to
> rebuild the entire archive.
>
> Those failures are due to attempting to run the clean target prior to
> anything else.

This is what dpkg-buildpackage does, so it has to work.

> While it's nice when debian/rules clean works even on already clean
> source, it's by no means mandated by policy.

If so, policy should probably be changed, since in practice it has been
required for many years.

> I think people who do full archive rebuilds should fix their scripts
> to not clean before building, or file "wishlist" bugs instead of
> "serious" when the failure occurs in the initial clean.

Those packages will FTBFS on the buildds, so "serious" is the right
severity.

Cheers,
   Sven


-- 
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/87y5651l7o@turtle.gmx.de



Re: Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)

2013-10-07 Thread Riku Voipio
On Wed, Oct 02, 2013 at 04:07:25PM +0100, Wookey wrote:
> +++ Niels Thykier [2013-10-02 09:45 +0200]:
> > armel: Wookey (DD), Gatis Visnevskis (!DD), Nobuhiro Iwamatsu (DD), Steve 
> > McIntyre (DD)
> > armhf: Jeremiah Foster (!DD, but NM?), Wookey (DD), Justus Winter (!DD), 
> > Lennart Sorensen (!DD), Nobuhiro Iwamatsu (DD), Steve McIntyre (DD)
 
> I am surprised not to see Riku Voipio and Hector Oron on this list as
> I know they help manage the buildds and Riku signs uploads. I don't
> know if they are trying to escape, or just being too slack to send
> mail :-)

Sorry, I missed the fact that this request had a deadline. Anyways,
I am available for arm related issues - just try not to use debian-devel
to reach me, as I tend to just skim subjects here...

Riku


-- 
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/20131007102229.gb16...@afflict.kos.to



Bug#725683: ITP: libdevel-callsite-perl -- Perl module to get caller return OP address and Perl interpreter context

2013-10-07 Thread Salvatore Bonaccorso
Package: wnpp
Owner: Salvatore Bonaccorso 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libdevel-callsite-perl
  Version : 0.07
  Upstream Author : Rocky Bernstein  (current maintainer), Ted 
Zlatanov , Ben Morrow
* URL : https://metacpan.org/release/Devel-Callsite/
* License : Artistic or GPL-2+
  Programming Lang: Perl
  Description : Perl module to get caller return OP address and Perl 
interpreter context

Devel::Callsite module provides subroutines to get the caller return OP
address and perl interpreter context.

The callsite() function returns the OP address of the caller, a number,
one level up from where it was called. It's useful for functions that
need to uniquely know where they were called, such as Every::every();
see Every. Or it can be used to pinpoint a location with finer
granularity than a line number (see
http://www.perlmonks.com/?node_id=987268). In conjunction with an OP
tree disassembly you can know exactly where the caller is located in
the Perl source.

The context() function returns the interpreter context as a number.
This is a fairly unique number together with the call site.


-- 
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/1381148878.537375.20347@lorien



Re: Archive rebuild failures and the clean target

2013-10-07 Thread Thibaut Paumard
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Le 07/10/2013 11:31, Sven Joachim a ←crit :
> On 2013-10-07 10:53 +0200, Thibaut Paumard wrote:
> 
>> I think people who do full archive rebuilds should fix their
>> scripts to not clean before building, or file "wishlist" bugs
>> instead of "serious" when the failure occurs in the initial
>> clean.
> 
> Those packages will FTBFS on the buildds, so "serious" is the
> right severity.

Hi,

Actually, they used not to FTBFS.

Something has changed recently in dh_auto_clean that made it skip
cleaning or ignore cleaning errors when the package was not
configured. Whether it was on purpose or a bug at the time...

My bad anyway, will fix my packages.

Regards, Thibaut.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJSUriCAAoJEJOUU0jg3ChAS9AP/2GUhBdAZKaYVuOAjRGCoMeg
J2saSnjKP3aRM+JJ1nrO/xBOFW8jMbdvVr51r9W4rlS8LIsPzt0hflA8FEbdDYhE
LOw8c8+tzGl7n4phtmtCsv2d+1uN08EJy/6ADMmQ7YIY98HrekoOsFHrZhhIIA/R
bpOke5bkOtgZSrT0TF2QRBV89eXtjIdZ5liIYxPggqA3/fC9CA3cJEsISYTI1XI6
oDAn/1CnTt/shqezL4zSPXhN+yti4jECP3yEodV1DGNzTCaD6DnzET4CCLAB83pu
dRFiGr3OgucRezr6cwns9zn/Mj9p/0TfGqz+pmpbtfsa8iRTVSkEp/Nw5o1fI/85
z3Xp4rLIVFxfq4/SONTRFAd3X+GEl4OUWjBtz60vMlKysiUd0S7/57MVPc3RouMc
tR43qEoOVDBiKSgeHai+Ycwr15tf47DjXp5FVY6c2mvImpyPb2r56JzG0pK7VR+Q
yLQ08JcgAYY5KcAX39kKjTa+6S7Xu71cFahkjOUszF3VaYv972lybKuKtrchTBr8
nG650v4kfXr/vBQYEx4QkQpCp0LEyPG3R6okGp4OcKB6Agslx0FUb394BH8yOLPv
6IyaVmDBsq0GVD/x/EtR5MDmAZqmTzxWB1tmxropoP4bZoIK0z3tnpbRPSxMENgO
iv/ZHiSTCF2AHEFk2Olq
=E7Zj
-END PGP SIGNATURE-


-- 
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/5252b882.7060...@debian.org



Re: Archive rebuild failures and the clean target

2013-10-07 Thread Jonathan Dowland
On Mon, Oct 07, 2013 at 03:34:58PM +0200, Thibaut Paumard wrote:
> Something has changed recently in dh_auto_clean that made it skip
> cleaning or ignore cleaning errors when the package was not
> configured. Whether it was on purpose or a bug at the time...

Possibly it was detecting it had already run in debian/debhelper.log?


-- 
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/20131007145104.GA26516@debian



Re: Collect Suspend Tweaks

2013-10-07 Thread Jonathan Dowland
Eventually, I think, the kernel itself should detect which quirks to
apply for what hardware, and not rely on userspace telling it. Therefore
it would be nice if this could be reported somewhere to be tracked and
eventually fixed in the kernel (probably the kernel bugzilla, if not
already.)


-- 
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/20131007145430.GB26516@debian



Bug#725705: ITP: nfft -- Library for computing the Non-uniform Fast Fourier Transform

2013-10-07 Thread Ghislain Vaillant
Package: wnpp
Severity: wishlist
Owner: Ghislain Vaillant 

* Package name: nfft
  Version : 3.2.3
  Upstream Author : Prof. Dr. Daniel Potts 
* URL : http://www-user.tu-chemnitz.de/~potts/nfft/
* License : GPL
  Programming Lang: C
  Description : Library for computing the Non-uniform Fast Fourier Transform

The NFFT is a C subroutine library for computing the nonequispaced
discrete Fourier transform (NDFT) in one or more dimensions, of
arbitrary input size, and of complex data.


-- 
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/20131007150429.14002.13227.reportbug@LAT643



Bug#725712: ITP: tarix -- Indexing utility for tar archives

2013-10-07 Thread Stanislav Maslovski
Package: wnpp
Severity: wishlist
Owner: Stanislav Maslovski 

* Package name: tarix
  Version : 1.0.7
  Upstream Author : Matthew "Cheetah" Gabeler-Lee
* URL : https://github.com/fastcat/tarix; 
http://sourceforge.net/projects/xtar/
* License : GPL
  Programming Lang: C
  Description : Indexing utility for tar archives

tarix is a program for indexing tar archives so that selective extraction
can be done rapidly, especially on slow devices like tape drives, providing
that you can seek to arbitrary locations (at least on 512 byte boundaries)
within the tar archive.
.
Tarix is designed to work as a compression filter for tar with the
--use-compress-program option.  Tarix can either pass the tar archive
straight through, or it can compress the archive using zlib on the way
through.  Note that tarix does special things when using zlib to enable
random access when extracting.
.
Tarix's index file format is geared for simplicity and ease of use in
a recovery situation.  For those reasons, it is a simple text format.
Using tarix's indexes requires only grep, sed, dd, and tar for basic usage.
tarix itself can use the index for fast extraction without convoluted usage
of grep, sed, and dd.


-- 
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/20131007161918.20593.18916.reportbug@kaiba.homelan



petitioning Crockford to change his license

2013-10-07 Thread Thomas Koch
Hi,

I met another piece of Software (JSHint [sic!]) poisened by Crockfords 
license[1]. My anger was strong enough to let me setup a petition on 
change.org asking him to free the world from this evil license[2].

[1] https://wiki.debian.org/qa.debian.org/jsonevil
[2] https://www.change.org/petitions/douglas-crockford-remove-the-not-evil-
clause-from-your-license-because-it-is-evil-itself

It might seem strange to use change.org for this kind of request. But maybe 
Crockford changes his mind if enough people sign it. After all he argues that 
he would have good intentions. And if he doesn't change his mind than at least 
we have one site to point people to when asking them to remove a json.org 
dependency.

Regards,

Thomas Koch


-- 
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/201310071942.40828.tho...@koch.ro



Re: petitioning Crockford to change his license

2013-10-07 Thread Paul Tagliamonte
On Mon, Oct 07, 2013 at 07:42:40PM +0200, Thomas Koch wrote:
> Hi,
> 
> I met another piece of Software (JSHint [sic!])

They did a rewrite that is no longer subject to his terms.

> poisened by Crockfords 
> license[1]. My anger was strong enough to let me setup a petition on 
> change.org asking him to free the world from this evil license[2].

He just makes fun of such efforts. All the damn time. It's not worth
feeding the troll.

Cheers,
  Paul


-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag


signature.asc
Description: Digital signature


Re: petitioning Crockford to change his license

2013-10-07 Thread Raphael Hertzog
Hi,

On Mon, 07 Oct 2013, Paul Tagliamonte wrote:
> On Mon, Oct 07, 2013 at 07:42:40PM +0200, Thomas Koch wrote:
> > Hi,
> > 
> > I met another piece of Software (JSHint [sic!])
> 
> They did a rewrite that is no longer subject to his terms.

Is that a recent development? Because a few weeks ago the problem was
still real according to the javascript team. And it looks like it still
is:

https://github.com/jshint/jshint/blob/master/src/jshint.js

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
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/20131007185947.gb31...@x230-buxy.home.ouaza.com



Re: Collect Suspend Tweaks

2013-10-07 Thread Ben Hutchings
On Mon, Oct 07, 2013 at 03:54:30PM +0100, Jonathan Dowland wrote:
> Eventually, I think, the kernel itself should detect which quirks to
> apply for what hardware, and not rely on userspace telling it.

Or should be fixed to not require the quirk
(see http://mjg59.dreamwidth.org/14475.html).

> Therefore
> it would be nice if this could be reported somewhere to be tracked and
> eventually fixed in the kernel (probably the kernel bugzilla, if not
> already.)

That is probably better than the Debian BTS, though mail to the relevant
list(s) (linux-acpi, platform-driver-x86 or linux-kernel) may be best.

Ben.

-- 
Ben Hutchings
Never put off till tomorrow what you can avoid all together.


-- 
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/20131007191950.ga4...@decadent.org.uk



Re: petitioning Crockford to change his license

2013-10-07 Thread Thomas Koch
On Monday, October 07, 2013 08:06:47 PM Paul Tagliamonte wrote:
> > I met another piece of Software (JSHint [sic!])
> 
> They did a rewrite that is no longer subject to his terms.
I'm afraid you might be mistaken here:
https://github.com/jshint/jshint/blob/master/src/jshint.js


> > poisened by Crockfords
> > license[1]. My anger was strong enough to let me setup a petition on
> > change.org asking him to free the world from this evil license[2].
> 
> He just makes fun of such efforts. All the damn time. It's not worth
> feeding the troll.
I've already had the honour of receiving a personal reply mail of this sort.

Regards, Thomas Koch


-- 
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/201310072132.18240.tho...@koch.ro



Re: petitioning Crockford to change his license

2013-10-07 Thread Paul Tagliamonte
On Mon, Oct 07, 2013 at 09:32:15PM +0200, Thomas Koch wrote:
> On Monday, October 07, 2013 08:06:47 PM Paul Tagliamonte wrote:
> > > I met another piece of Software (JSHint [sic!])
> > 
> > They did a rewrite that is no longer subject to his terms.
>
> I'm afraid you might be mistaken here:
> https://github.com/jshint/jshint/blob/master/src/jshint.js

I am indeed. I assumed since https://github.com/jshint/jshint-next/
was merged in it was fixed; didn't actually look much further. I could
have sworn the jshint guys were trying to hack around this.

Ugh. Alas.

> > > poisened by Crockfords
> > > license[1]. My anger was strong enough to let me setup a petition on
> > > change.org asking him to free the world from this evil license[2].
> > 
> > He just makes fun of such efforts. All the damn time. It's not worth
> > feeding the troll.
>
> I've already had the honour of receiving a personal reply mail of this sort.

Toldja :)

> Regards, Thomas Koch

Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag


signature.asc
Description: Digital signature


Re: First autoremovals happen in about 8 days

2013-10-07 Thread Bill Allombert
On Sun, Oct 06, 2013 at 09:52:17AM +0200, Niels Thykier wrote:
> Hi,
> 
> This is a friendly reminder.  If you are listed below, then the listed
> packages of yours will be automatically removed from testing within 15
> days.  The "first batch" of automatic removals will happen in about 8
> days.
> 
> Please remember that "fixing" your RC bug(s) can sometimes be as
> simple as correcting the metadata of the bugs (see also #725321[0]) or
> (where inflated) downgrade the severity of the bug.
> 
> This mail was a "one-time public service annoucement"; I *do not*
> intend to send out "reminders" in the future.  Remember that you can
> pull the same data from [1] or [2].

I am concerned that in the event a package is removed from testing,
the people most interested with restoring the package will miss the
removal, since the package will stay installed on their systems.
This, then, cause stable releases to be missing packages that users
are depending on, which reduce the value of the distribution.

This is not a new problem, and it is not entirely clear whether such
early removal will reduce or increase this issue. However we should
address it if we want Debian stable releases to be something users
can rely on.

So while it is possible that the _maintainer_ is not needing a friendly
remainder, other interested third-party might.

Cheers,
Bill.


-- 
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/20131007220421.ga17...@master.debian.org



Re: petitioning Crockford to change his license

2013-10-07 Thread Bastien ROUCARIES
On Mon, Oct 7, 2013 at 7:42 PM, Thomas Koch  wrote:
> Hi,
>
> I met another piece of Software (JSHint [sic!]) poisened by Crockfords
> license[1]. My anger was strong enough to let me setup a petition on
> change.org asking him to free the world from this evil license[2].
>
> [1] https://wiki.debian.org/qa.debian.org/jsonevil
> [2] https://www.change.org/petitions/douglas-crockford-remove-the-not-evil-
> clause-from-your-license-because-it-is-evil-itself

How does you realize the problem ?
Does lintian trip during packaging test ?
If no could you report a bug against lintian?

Bastien


-- 
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/cae2spazfdt7grdfgaggiub9pekbvcr_hynfphfjb1dzqxj_...@mail.gmail.com



Re: First autoremovals happen in about 8 days

2013-10-07 Thread Holger Levsen
Hi,

On Dienstag, 8. Oktober 2013, Bill Allombert wrote:
> So while it is possible that the _maintainer_ is not needing a friendly
> remainder, other interested third-party might.

anyone interested in a package can opt-in via the PTS...


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.


Bug#725753: ITP: krb5-strength -- Password strength checking for Kerberos KDCs

2013-10-07 Thread Russ Allbery
Package: wnpp
Severity: wishlist
Owner: Russ Allbery 

* Package name: krb5-strength
  Version : 2.0
  Upstream Author : Russ Allbery 
* URL : http://www.eyrie.org/~eagle/software/krb5-strength/
* License : Expat
  Programming Lang: C, Perl
  Description : Password strength checking for Kerberos KDCs

krb5-strength provides a password quality plugin for the MIT Kerberos KDC
(specifically the kadmind server) and an external password quality
program for use with the Heimdal kpasswdd server.  Passwords can be
tested with CrackLib, checked against a CDB database of known weak
passwords, checked for length, checked for non-printable or non-ASCII
characters that may be difficult to enter reproducibly, required to
contain a non-alphabetic character, or any combination of these tests.

No dictionary is shipped with this package.  A CrackLib dictionary can be
created with the tools in cracklib-runtime, a CDB database can be created
from a password list (obtained separately) using the tools included in
this package, or both.


-- 
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/20131007235656.23677.9179.report...@windlord.stanford.edu



Re: petitioning Crockford to change his license

2013-10-07 Thread Ben Finney
Bastien ROUCARIES  writes:

> Does lintian trip during packaging test ?
> If no could you report a bug against lintian?

Lintian already has a check for that non-free license:

=
$ lintian-info --tags license-problem-json-evil
E: license-problem-json-evil
N:
N:   The given source file is copyrighted under the non free license of
N:   json and the infamous clause: The Software shall be used for Good, not
N:   Evil.
N:   
N:   Refer to http://wiki.debian.org/qa.debian.org/jsonevil for details.
N:   
N:   Severity: serious, Certainty: possible
N:   
N:   Check: cruft, Type: source
N:
=

-- 
 \“When I was a baby I kept a diary. Recently I was re-reading |
  `\   it, it said ‘Day 1: Still tired from the move. Day 2: Everybody |
_o__)  talks to me like I'm an idiot.’” —Steven Wright |
Ben Finney


-- 
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/7wli24pp8r@benfinney.id.au



Re: First autoremovals happen in about 8 days

2013-10-07 Thread Lisandro Damián Nicanor Pérez Meyer
On Tuesday 08 October 2013 01:51:41 Holger Levsen wrote:
> Hi,
> 
> On Dienstag, 8. Oktober 2013, Bill Allombert wrote:
> > So while it is possible that the _maintainer_ is not needing a friendly
> > remainder, other interested third-party might.
> 
> anyone interested in a package can opt-in via the PTS...

I really doubt that possibly interested people will subscribe to all the 
packages they are interested in.

-- 
Antiguo proverbio del Viejo Machi: "Prefiero que mi cerebro esté en la
cresta de la ola, y mi PC un paso atrás sirviéndolo y no tener mi PC en
el 'estado del arte' y mi cerebro un paso atrás asistiéndola."
  http://www.grulic.org.ar/lurker/message/20090507.020516.ffda0441.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.


Re: First autoremovals happen in about 8 days

2013-10-07 Thread Neil Williams
On Mon, 7 Oct 2013 22:04:21 +
Bill Allombert  wrote:

> On Sun, Oct 06, 2013 at 09:52:17AM +0200, Niels Thykier wrote:
> > 
> > This is a friendly reminder.  If you are listed below, then the
> > listed packages of yours will be automatically removed from testing
> > within 15 days.  The "first batch" of automatic removals will
> > happen in about 8 days.
> > 
> > Please remember that "fixing" your RC bug(s) can sometimes be as
> > simple as correcting the metadata of the bugs (see also #725321[0])
> > or (where inflated) downgrade the severity of the bug.
> > 
> > This mail was a "one-time public service annoucement"; I *do not*
> > intend to send out "reminders" in the future.  Remember that you can
> > pull the same data from [1] or [2].
> 
> I am concerned that in the event a package is removed from testing,
> the people most interested with restoring the package will miss the
> removal, since the package will stay installed on their systems.
> This, then, cause stable releases to be missing packages that users
> are depending on, which reduce the value of the distribution.

rc-alert has existed for quite some time and it gets the alert in
*ahead* of package removal. It alerts users to the real problem - the
RC BUG!

$ man 1 rc-alert

rc-alert - check for installed packages with release-critical bugs

Yes, it's in devscripts but publicising that the best way to install
devscripts is with the --no-install-recommends option to apt-get is all
that's needed to cover that issue.

I'm more concerned with this assumption: 

> the people most interested with restoring the package will miss the
> removal, since the package will stay installed on their systems.

The people with the package installed are those most interested in
"restoring" the package? Honestly? By restoring, I assume you simply
mean "ignore the RC issue - seeing as nobody seems to care to fix it -
and give me a broken package so that I don't have to do anything."

The removal is not the problem, it's the consequence.

The RC bug is the problem, it is *that* which people who care about
the package need to be made aware. The removal is simply one way to fix
the RC bug. Those who may care about avoiding the removal must fix the
bug some other way.

Don't panic about the symptom, fix the cause.

(A huge thank you to Niels for doing this task - he really does not
deserve to be taking all the flak as the messenger.)

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



signature.asc
Description: PGP signature