Re: First autoremovals happen in about 8 days

2013-10-15 Thread Andreas Tille
Hi Niels,

[sorry for the late reply I was on vac]

On Sun, Oct 06, 2013 at 09:52:17AM +0200, Niels Thykier wrote:
 
 Andreas Tille ti...@debian.org
gdpc: bugs 713652, flagged for removal in 8.3 days

Fixed.

gwyddion: bugs 713565, flagged for removal in 8.3 days

Hmmm, that's really strange.  The bug report was closed

   Sat, 29 Jun 2013 13:07:42 +0200

Seems something is wrong with the script.

praat: bugs 713597, flagged for removal in 8.3 days

We'll care about this in Debian Med team.

r-other-mott-happy: bugs 709190,713284, flagged for removal in 8.3 days

Besides the fact that this package should actually removed from testing
(perhaps even from Debian - the actual Uploader in our team should take
action about this) I noticed that something seems to be wrong in
rendering the BTS page.  While the first bug (#709190) is mentioned
the second one (#713284) is missing on the BTS page:

   http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=r-other-mott-happy

Any explanation for this?

Kind regards

  Andreas.

-- 
http://fam-tille.de


-- 
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/20131015133558.gi23...@an3as.eu



Re: First autoremovals happen in about 8 days

2013-10-15 Thread Niels Thykier
On 2013-10-15 15:35, Andreas Tille wrote:
 Hi Niels,
 
 [sorry for the late reply I was on vac]
 

Hi,

No worries.

 On Sun, Oct 06, 2013 at 09:52:17AM +0200, Niels Thykier wrote:

 Andreas Tille ti...@debian.org
gdpc: bugs 713652, flagged for removal in 8.3 days
 
 Fixed.
 

Thank you,

gwyddion: bugs 713565, flagged for removal in 8.3 days
 
 Hmmm, that's really strange.  The bug report was closed
 
Sat, 29 Jun 2013 13:07:42 +0200
 
 Seems something is wrong with the script.
 

I am more inclined to believe that you experienced one of the quirks of
the Debian BTS.  According to the BTS, it is:


Fixed in version src:gwyddion/2.28-2


In the bottom of the bug log you will find:


No longer marked as found in versions gwyddion/2.28-2


meaning that the bug was (or, rather, used to be) marked as fixed in
the same version as it was found.  The BTS handles this by *silently
ignoring the fixed version* and thus concluding the bug is still in
2.28-2.  It then hands that off to Britney and the auto-removal script,
which will consider 2.28-2 as buggy as well.

praat: bugs 713597, flagged for removal in 8.3 days
 
 We'll care about this in Debian Med team.
 

\o/

r-other-mott-happy: bugs 709190,713284, flagged for removal in 8.3 days
 
 Besides the fact that this package should actually removed from testing
 (perhaps even from Debian - the actual Uploader in our team should take
 action about this) I noticed that something seems to be wrong in
 rendering the BTS page.  While the first bug (#709190) is mentioned
 the second one (#713284) is missing on the BTS page:
 
http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=r-other-mott-happy
 
 Any explanation for this?
 

Well, they are merged into each other and thus the BTS decided only to
show one of them in the bug page.  However, both bugs appear when you
reference then directly via [1] and [2].

 Kind regards
 
   Andreas.
 


~Niels

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713284

[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709190



-- 
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/525d48df.3060...@thykier.net



Re: First autoremovals happen in about 8 days

2013-10-15 Thread Andreas Tille
Hi,

On Tue, Oct 15, 2013 at 03:53:35PM +0200, Niels Thykier wrote:
 gwyddion: bugs 713565, flagged for removal in 8.3 days
  
  Hmmm, that's really strange.  The bug report was closed
  
 Sat, 29 Jun 2013 13:07:42 +0200
  
  Seems something is wrong with the script.
  
 
 I am more inclined to believe that you experienced one of the quirks of
 the Debian BTS.  According to the BTS, it is:
 
 
 Fixed in version src:gwyddion/2.28-2
 
 
 In the bottom of the bug log you will find:
 
 
 No longer marked as found in versions gwyddion/2.28-2
 
 
 meaning that the bug was (or, rather, used to be) marked as fixed in
 the same version as it was found.  The BTS handles this by *silently
 ignoring the fixed version* and thus concluding the bug is still in
 2.28-2.  It then hands that off to Britney and the auto-removal script,
 which will consider 2.28-2 as buggy as well.

Ahhh, I was missing this somehow.  I rebuilded the current package
2.32-2 in testing and unstable without any problem and thus closed
the bug (now hopefully for all versions).

  rendering the BTS page.  While the first bug (#709190) is mentioned
  the second one (#713284) is missing on the BTS page:
  
 http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=r-other-mott-happy
  
  Any explanation for this?
  
 
 Well, they are merged into each other and thus the BTS decided only to
 show one of them in the bug page.  However, both bugs appear when you
 reference then directly via [1] and [2].

Hmm, OK, I have noticed the merge.  However, the BTS behaviour seems to
be new to me.  But thinking about it it is reasonable.

Thanks for all your release team work

 Andreas.

-- 
http://fam-tille.de


-- 
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/20131015144308.go23...@an3as.eu



Re: First autoremovals happen in about 8 days

2013-10-15 Thread Kevin Chadwick
xxxterm: bugs 718074, flagged for removal in 8.3 days

I use debian offline so it is of no consequence to me however I
just wanted to say.

xxxterm (now xombrero) is by far my favourite browser and rediculously
faster than any other browser whilst still being highly useful and with
better whitelisting control (javascript, cookies) by default too. Not a
user interface for everyone in being primarily keyboard based but
highly functional.

In fact where firefox is almost useless on an old thinkpad, xombrero
is quite snappy.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or 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/380101.59925...@smtp145.mail.ir2.yahoo.com



Re: First autoremovals happen in about 8 days

2013-10-15 Thread Svante Signell
On Tue, 2013-10-15 at 17:34 +0100, Kevin Chadwick wrote:
 xxxterm: bugs 718074, flagged for removal in 8.3 days
 
 I use debian offline so it is of no consequence to me however I
 just wanted to say.
 
 xxxterm (now xombrero) is by far my favourite browser and rediculously
 faster than any other browser whilst still being highly useful and with
 better whitelisting control (javascript, cookies) by default too. Not a
 user interface for everyone in being primarily keyboard based but
 highly functional.
 
 In fact where firefox is almost useless on an old thinkpad, xombrero
 is quite snappy.

Hi, is it possible to adopt this package? Since I'm not DM yet, I will
need a sponsor for uploading later on, when the latest release of
xombrero is packaged.


-- 
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/1381859486.3860.51.ca...@g3620.my.own.domain



Re: First autoremovals happen in about 8 days

2013-10-15 Thread Paul Wise
On Wed, Oct 16, 2013 at 1:51 AM, Svante Signell wrote:

 Hi, is it possible to adopt this package?

The package is not orphaned yet, so that will have to happen first:

http://www.debian.org/doc/manuals/developers-reference/pkgs.html#orphaning

When it is orphaned you can adopt it:

http://www.debian.org/doc/manuals/developers-reference/pkgs.html#adopting

 Since I'm not DM yet, I will need a sponsor for uploading later on

http://mentors.debian.net/intro-maintainers

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



Re: First autoremovals happen in about 8 days

2013-10-09 Thread Helmut Grohne
On Tue, Oct 08, 2013 at 07:36:57PM +, Bill Allombert wrote:
 Did you try to run rc-alert recently ? The output is totally overwhelming
 for something that is to run on several computers and several times by
 month. Most of the bugs are reported against important packages that cannot
 be removed anyway. This do not give good clue about packages that could be
 NMUed with positive effect. The removal list is much more useful in this
 regard, if only because once a package is removed, the maintainer can hardly
 complain about a NMU.

What would you think about some variant of the attached (qd) script? It
fetches the removal list and matches it to your system. That way it
excludes packages that you would not NMU and it only lists packages that
lack attention.

In order to meet in the middle maybe rc-alert could gain an option to
sort bugs their last change? That would essentially boil down to the
same heuristic as is being used for generating removal hints: Bugs that
are not touched in a long time.

Helmut
#!/usr/bin/python

import urllib
import contextlib
import os

import yaml

pkgs = set()
with contextlib.closing(os.popen(dpkg-query -W -f '${Source:Package}\\n', r)) as f:
for line in f:
pkgs.add(line.strip())

with contextlib.closing(urllib.urlopen(http://udd.debian.org/cgi-bin/autoremovals.yaml.cgi;)) as f:
data = yaml.safe_load(f)
for key, value in data.items():
if key in pkgs:
print(%s: %r % (key, value))


Re: First autoremovals happen in about 8 days

2013-10-09 Thread Lucas Nussbaum
On 08/10/13 at 19:36 +, Bill Allombert wrote:
 On Tue, Oct 08, 2013 at 07:58:03AM +0100, Neil Williams wrote:
  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!
 
 Did you try to run rc-alert recently ? The output is totally overwhelming
 for something that is to run on several computers and several times by
 month. Most of the bugs are reported against important packages that cannot
 be removed anyway. This do not give good clue about packages that could be
 NMUed with positive effect. The removal list is much more useful in this
 regard, if only because once a package is removed, the maintainer can hardly
 complain about a NMU.

I agree that we could use more visibility for packages removed from
testing due to RC bugs, or packages that are going to be removed from
testing.

This is something that could easily be implemented in how-can-i-help[1].
I've filed #725819 to remember about it.

Lucas

[1] how-can-i-help's description: how-can-i-help hooks into APT to list
opportunities for contributions to Debian (orphaned packages, bugs
tagged 'gift') for packages installed locally, after each APT
invocation. It can also be invoked directly, and then lists all
opportunities for contribution (not just the new ones).


-- 
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/20131009104446.ga21...@xanadu.blop.info



Re: First autoremovals happen in about 8 days

2013-10-09 Thread Niels Thykier
On 2013-10-08 00:04, Bill Allombert wrote:
 [...]
 
 So while it is possible that the _maintainer_ is not needing a friendly
 remainder, other interested third-party might.
 
 Cheers,
 Bill.
 
 

Hi,

I, genuinely, hope that these removals-warnings will make people fix
bugs pro-actively rather than reactive.  From my PoV, more visibility
and focus on these bugs is welcome.  However, I know from experience
that I will not be able to maintain a manual friendly reminder (at
least not in a timely/reliable fashion), which is why I made this a
one-time thing.
  You (as in anybody) are more than welcome to implement a
weekly-reminder thing or so.  Not sure if people would welcome such a
thing on debian-devel, but having some way of at least opt-in on such a
reminder/warning would be a great idea.

That said, as much as I think it is a great idea I cannot volunteer to
do it.  I already have a sufficient d-release backlog ... :-/  Even
the current implementation was out-sourced.
  On a related note, kudos to Ivo De Decker for being the Do'er behind
automatic removals!

~Niels



-- 
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/52554881.7060...@thykier.net



Re: First autoremovals happen in about 8 days

2013-10-08 Thread Neil Williams
On Mon, 7 Oct 2013 22:04:21 +
Bill Allombert ballo...@debian.org 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


Re: First autoremovals happen in about 8 days

2013-10-08 Thread intrigeri
Hi Bill,

Bill Allombert wrote (07 Oct 2013 22:04:21 GMT) :
 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.

I believe there are good chances that this kind of people realize that
there's a problem at some point, if they're particularly interested in
this package: either they're directly affected by the RC bugs
affecting this package (it was removed for a reason, uh), or they'll
miss some new feature implemented in a newer upstream version and will
wonder why it's not in testing yet, or they'll suffer from some other
bug and will have a look at the PTS.

In all of this cases, $PACKAGE is not in testing anymore is likely
to be a stronger help is needed signal for them than the mere
presence of RC bugs.

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


-- 
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/857gdop4tb@boum.org



Re: First autoremovals happen in about 8 days

2013-10-08 Thread Jonathan Dowland


 On 8 Oct 2013, at 07:58, Neil Williams codeh...@debian.org wrote:
 
 The removal is simply one way to fix
 the RC bug

I'm broadly in favour of this course of action but in no way does it fix the 
bugs. 

--
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/11dd52b6-4d52-4870-8a2b-e159fe829...@debian.org



Re: First autoremovals happen in about 8 days

2013-10-08 Thread Geoffrey Thomas

On Mon, 7 Oct 2013, Bill Allombert wrote:


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.


Would this be addressed by building some mechanism (making tombstone 
packages comes to mind, but there are many options) for apt to prompt to 
remove packages that were removed in the archive?


I find myself having to do some package-origin queries with aptitude and 
some cross-checking with the PTS _anyway_ when upgrading a 
nontrivially-complicated system (including one that ever ran testing) 
between releases, so this seems like it's likely to be worth building 
regardless.


--
Geoffrey Thomas
http://ldpreload.com
geo...@ldpreload.com


--
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/alpine.deb.2.00.1310080940110.16...@dr-wily.mit.edu



Re: First autoremovals happen in about 8 days

2013-10-08 Thread Neil Williams
On Tue, 8 Oct 2013 09:46:02 -0700 (PDT)
Geoffrey Thomas geo...@ldpreload.com wrote:

 On Mon, 7 Oct 2013, Bill Allombert wrote:
 
  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.
 
 Would this be addressed by building some mechanism (making tombstone 
 packages comes to mind, but there are many options) for apt to prompt
 to remove packages that were removed in the archive?

You mean beyond apt-get autoremove? apt already declares which packages
could be automatically removed. Other managers like synaptic have a
list of local and obsolete packages and packages no longer listed in
any of the apt sources will show up as local or obsolete.

Otherwise, define the archive - very few machines have a single apt
source or even apt sources which only point at a Debian mirror. How
does apt know which archive to look at? what about derivatives and
beyond?

Some users will experience the bug which caused the removal. Others
will find that apt removes the package during an upgrade. If the rest
don't notice, is there any harm done?

-- 


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



signature.asc
Description: PGP signature


Re: First autoremovals happen in about 8 days

2013-10-08 Thread Bill Allombert
On Tue, Oct 08, 2013 at 07:58:03AM +0100, Neil Williams wrote:
 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!

Did you try to run rc-alert recently ? The output is totally overwhelming
for something that is to run on several computers and several times by
month. Most of the bugs are reported against important packages that cannot
be removed anyway. This do not give good clue about packages that could be
NMUed with positive effect. The removal list is much more useful in this
regard, if only because once a package is removed, the maintainer can hardly
complain about a NMU.

 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.

I am not sure how you justify your assumption.
At least, my assumption is that people using a package are more interested by
its availabilty that people that do not use it.

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

If you refer to my email, then you completly missed its purpose (to encourage
Niels to continue to post the list of removal to this list).

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here.


-- 
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/20131008193657.ga29...@master.debian.org



Re: First autoremovals happen in about 8 days

2013-10-08 Thread Vincent Danjean
Le 08/10/2013 18:46, Geoffrey Thomas a écrit :
 On Mon, 7 Oct 2013, Bill Allombert wrote:
 
 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.
 
 Would this be addressed by building some mechanism (making tombstone
 packages comes to mind, but there are many options) for apt to prompt
 to remove packages that were removed in the archive?

For myself, I often use a non-official package made by a friend:
the apt-moreutils pacakge[1] and, more precisely, the apt-origins
tool in this package.
  It allows me to easily see how many and which packages come from
each of my APT sources. If a version of a package is not in any of my
sources (either because I do not upgrade it or because it disappeared
from the APT repo), it is listed into the Installed catch-all final
group.

  Regards,
Vincent

[1] http://debian.dubacq.fr/html/srcpkg.apt-moreutils.html

(truncated) output example on a not up-to-date machine:
vdanjean@eyak:~$ apt-origins
,--.
|  Debian FR unstable  |
`--'
Too many packages (3933). Use --tabular or --lines=X (x=3933).
,--.
|   Unofficial Multimedia Packages unstable|
`--'
autopano-sift-c deb-multimedia-keyring ffmpeg flashplayer-mozilla
[...]
,--.
|  Debian FR testing   |
`--'
bsd-mailx gedit gedit-common geoip-database git-buildpackage gnupg gpgv
[...]
,--.
|   Debian FR stable   |
`--'
biblatex gir1.2-tracker-0.14 gnome-mag libatspi1.0-0 libclucene0ldbl libdconf0
,--.
|  installed   |
`--'
doc-linux-text gcj-4.7-base gcj-4.7-jre gcj-4.7-jre-headless gcj-4.7-jre-lib
[...]

= it seems I will need to remove all gcc 4.7 stuff

-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
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/525466f0.9090...@free.fr



Re: First autoremovals happen in about 8 days

2013-10-08 Thread Neil Williams
On Tue, 8 Oct 2013 19:36:57 +
Bill Allombert ballo...@debian.org wrote:

 On Tue, Oct 08, 2013 at 07:58:03AM +0100, Neil Williams wrote:
  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!
 
 Did you try to run rc-alert recently ?

I ran it during drafting of the reply. I run it before and during every
BSP. I run it intermittently, especially once a release freeze starts.
It's usually the second filter on which RC bugs I think about looking
at. Naturally, the first filter is ones in my own packages, via DDPO.

 The output is totally
 overwhelming for something that is to run on several computers and
 several times by month. 

Compared to the volume of this list? Honestly? The removal email is
large, it contains a long, long list (sadly) of *source* package names
and no matching list of binaries when anyone running a Debian box and
worrying about packages disappearing only actually has a list of
*binaries* to check. rc-alert handles this for you. If the source
package builds a binary not on your system, it excludes it.

The email is fine for it's purpose - alerting maintainers to problems
in their source packages. Alerting others about problems with binary
packages is a different problem with a different solution.

 Most of the bugs are reported against
 important packages that cannot be removed anyway. This do not give
 good clue about packages that could be NMUed with positive effect.

The list of removals has nothing to do with NMUs - that's a job for
rc-alert and UDD. The relevant RC bugs were filed long before the
packages appear in the removal list. There's no need to wait that long,
so scan rc-alert and work on patches in advance of removal if that is
what is the real issue.

 The removal list is much more useful in this regard, if only because
 once a package is removed, the maintainer can hardly complain about a
 NMU.

After removal? If there's going to be an NMU, do it before removal and
save work for the release and ftp teams.
 
  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.
 
 I am not sure how you justify your assumption.
 At least, my assumption is that people using a package are more
 interested by its availabilty that people that do not use it.
 
  (A huge thank you to Niels for doing this task - he really does not
  deserve to be taking all the flak as the messenger.)
 
 If you refer to my email, then you completly missed its purpose (to
 encourage Niels to continue to post the list of removal to this list).

I didn't miss that at all - notifications on a list with the volumes of
debian-devel are much easier to miss than something which is directly
relevant to what is installed on your own machine. Why scan through
several thousand emails in the -devel folder to find this thread -
especially when the thread contains lots of messages like this which
spend time talking about the reminder procedure and not about the
actual bugs or the packages to be removed.

How do you compare the removal list against the list of installed
packages on each machine? That's just as much work as parsing the
rc-alert output to exclude some packages.

Inventive use of existing rc-alert options may well be able to remove
listings for packages with certain criteria. I'm happy with rc-alert
as-is but if it isn't enough for everyone, I'm sure a patch would be
useful.

-- 


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



signature.asc
Description: PGP signature


Re: First autoremovals happen in about 8 days

2013-10-08 Thread Steven Chamberlain
On 07/10/13 23:04, Bill Allombert wrote:
 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.

`aptitude search '?obsolete'` is useful after upgrading a system to a
new stable release, a trick I learned from:
http://raphaelhertzog.com/2011/02/07/debian-cleanup-tip-2-get-rid-of-obsolete-packages/

Not directly related to this:  a side effect of running debsecan is that
if I see security issues accumulating for some package, I would likely
check the PTS to see why it remains unfixed, or decide to remove or
replace the package with something else that's still maintained.

So if `aptitude search '?obsolete'` was run periodically, like debsecan,
it could email the system admin when new items appear on the obsoletes
list.  I imagine that'd be a good way to notify of the situation being
described here?

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


-- 
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/52549549.1050...@pyro.eu.org



Re: First autoremovals happen in about 8 days

2013-10-08 Thread Charles Plessy
Le Mon, Oct 07, 2013 at 10:51:42PM -0300, Lisandro Damián Nicanor Pérez Meyer a 
écrit :
 
 I really doubt that possibly interested people will subscribe to all the 
 packages they are interested in.

Hello everybody,

in one way or the other, there will always be some people who miss the
information because it is sent in a channel that they are not familiar with.

I think that the best solution is to have the information available in a
systematic manner, and then let people rely on that source to automate display
or messaging in the communication channel that is suitable for the use case
that they want to support.

This would make it easy for volunteers to write a script that periodically
sends emails to this list about upcoming removals, or to add this information
to the periodical WNPP email, so that it does not add to the traffic.

By the way, I think that the automated removals (and the automated autopkg
testing) are a big step forward.  Let me take this opportunity to thank to the
Release team for this !

Have a nice day,

-- 
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/20131008233016.gd26...@falafel.plessy.net



Re: First autoremovals happen in about 8 days

2013-10-08 Thread Henrique de Moraes Holschuh
On Tue, 08 Oct 2013, Geoffrey Thomas wrote:
 Would this be addressed by building some mechanism (making tombstone
 packages comes to mind, but there are many options) for apt to
 prompt to remove packages that were removed in the archive?

It is already addressed by the user-oriented package management frontends.
E.g.  aptitude lists them separately.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20131008234424.gb...@khazad-dum.debian.net



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: 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.


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.


First autoremovals happen in about 8 days

2013-10-06 Thread Niels Thykier
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].

~Niels

[0] You may (or may not) find the following blog post about the BTS
interesting as well:

  http://rhonda.deb.at/blog/debian/on-BTS-usage.html

It is admittedly more focused on stable, but some of the remarks may
still apply to bugs filed against your package.  That post can (also)
help you clean up your package's BTS page and ensuring that your
packages have no open RC bugs still affecting stable.

[1] http://udd.debian.org/cgi-bin/autoremovals.cgi

[2] http://udd.debian.org/cgi-bin/autoremovals.yaml.cgi


   8  8  8 

Adam C. Powell, IV hazel...@debian.org
   babel: bugs 723789, flagged for removal in 12.7 days

A Mennucc1 mennu...@debian.org
   wfrog: bugs 717328, flagged for removal in 8.3 days

AGOSTINI Yves agost...@univ-metz.fr
   libjifty-plugin-comment-perl: bugs 720789, flagged for removal in 8.3 days
   libjifty-plugin-oauth-perl: bugs 720791, flagged for removal in 8.3 days
   libjifty-plugin-wikitoolbar-perl: bugs 720792, flagged for removal in 8.3 
days

Adrian Knoth a...@drcomp.erfurt.thur.de
   timemachine: bugs 713592, flagged for removal in 8.3 days

Agney Lopes Roth Ferraz ag...@debian.org
   hardinfo: bugs 713717, flagged for removal in 8.3 days

Al Nikolov cl...@debian.org
   trac-datefieldplugin: bugs 714985, flagged for removal in 8.3 days
   trac-icalviewplugin: bugs 714985, flagged for removal in 8.3 days
   trac-wikitablemacro: bugs 714985, flagged for removal in 8.3 days

Alastair McKinstry mckins...@debian.org
   gramadoir: bugs 723881, flagged for removal in 13.7 days

Alejandro Garrido Mota garridom...@gmail.com
   libnet-dri-perl: bugs 710954, flagged for removal in 8.3 days

Alessandro De Zorzi l...@nonlontano.it
   libapache2-mod-ruid2: bugs 709465, flagged for removal in 8.3 days
   phamm: bugs 669841, flagged for removal in 8.3 days

Alessio Treglia ales...@debian.org
   din: bugs 718165, flagged for removal in 8.3 days
   jack-rack: bugs 705053,713468, flagged for removal in 8.3 days
   lv2proc: bugs 713715, flagged for removal in 8.3 days
   mp3fs: bugs 713614, flagged for removal in 8.3 days
   timemachine: bugs 713592, flagged for removal in 8.3 days
   transmageddon: bugs 713205, flagged for removal in 8.3 days

Alexander Reichle-Schmehl toli...@debian.org
   nagvis: bugs 709956, flagged for removal in 8.3 days

Alexander Wirt formo...@debian.org
   hotkeys: bugs 713671, flagged for removal in 8.3 days
   nagvis: bugs 709956, flagged for removal in 8.3 days
   nsca: bugs 721644, flagged for removal in 8.3 days
   vlock: bugs 702705, flagged for removal in 11.2 days

Alexandre Quessy alexan...@quessy.net
   supercollider: bugs 713670, flagged for removal in 8.3 days

Anders Lennartsson and...@lennartsson.se
   setpwc: bugs 717129, flagged for removal in 8.3 days

Andreas Barth a...@not.so.argh.org
   dpkg-sig: bugs 723867, flagged for removal in 13.4 days

Andreas Hildebrandt andreas.hildebra...@uni-mainz.de
   ball: bugs 720681,718144, flagged for removal in 8.3 days

Andreas Rottmann ro...@debian.org
   g-wrap: bugs 713203, flagged for removal in 8.3 days

Andreas Tille ti...@debian.org
   gdpc: bugs 713652, flagged for removal in 8.3 days
   gwyddion: bugs 713565, flagged for removal in 8.3 days
   praat: bugs 713597, flagged for removal in 8.3 days
   r-other-mott-happy: bugs 709190,713284, flagged for removal in 8.3 days

Andrei Zavada johnhom...@gmail.com
   aghermann: bugs 713574, flagged for removal in 8.3 days

Andres Mejia ame...@debian.org
   vdpau-video: bugs 713612, flagged for removal in 8.3 days

Andrew Lee (李健秋) ajq...@debian.org
   lxappearance-obconf: bugs 722112, flagged for removal in 8.3 days
   lxlauncher: bugs 722110, flagged for removal in 8.3 days
   scim-chewing: bugs 707442, flagged for removal in 8.3 days

Andrew McMillan a...@debian.org
   davical: bugs 717043, flagged for removal in 8.3 days

Andrey Rahmatullin w...@wrar.name
   mpdscribble: bugs 710066, flagged for removal in 8.3 days

Andy Spencer andy753...@gmail.com
   aweather: bugs 713613, flagged for removal in 8.3 days

Angel Abad an...@debian.org
   libjavascript-packer-perl: bugs 711629, flagged for removal in 8.3 days

Ansgar Burchardt ans...@debian.org
   libjavascript-packer-perl: bugs 711629, flagged for removal in 8.3 days

Arjan Oosting ar...@debian.org
   drift: bugs 713313, flagged for removal in 8.3 days

Ask Hjorth Larsen asklar...@gmail.com
   python-ase: bugs 717989, 

Re: First autoremovals happen in about 8 days

2013-10-06 Thread Steven Chamberlain
Hi,

On 06/10/13 08:52, Niels Thykier wrote:
kfreebsd-8: bugs 720470,717959,720476, flagged for removal in 14.7 days

Not sure why that's appearing in this list because:
1. the package was removed from testing over a month ago at the request
of the maintainer, and
2. when that happened the bugs listed were closed?

Perhaps this is because the script does not notice 1. and therefore
despite 2. it still thinks affected versions are in testing?

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


-- 
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/525144dc.6090...@pyro.eu.org



Re: First autoremovals happen in about 8 days

2013-10-06 Thread Niels Thykier
On 2013-10-06 13:09, Steven Chamberlain wrote:
 Hi,
 
 On 06/10/13 08:52, Niels Thykier wrote:
kfreebsd-8: bugs 720470,717959,720476, flagged for removal in 14.7 days
 
 Not sure why that's appearing in this list because:
 1. the package was removed from testing over a month ago at the request
 of the maintainer, and
 2. when that happened the bugs listed were closed?
 
 Perhaps this is because the script does not notice 1. and therefore
 despite 2. it still thinks affected versions are in testing?
 
 Regards,
 

Hey,

Thanks for reporting this.

It looks like this is caused by kfreebsd-8 being marked with
Extra-Source-Only: yes, presumably because something lists it in
Built-Using.  For most parts it means the package is already removed
but not all tools seem to recognise this e.g. the PTS, the BTS
(allegedly) and by extension the auto-removal script.

~Niels



-- 
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/52518ce2.9010...@thykier.net



Re: First autoremovals happen in about 8 days

2013-10-06 Thread Cyril Brulebois
Niels Thykier ni...@thykier.net (2013-10-06):
 It looks like this is caused by kfreebsd-8 being marked with
 Extra-Source-Only: yes, presumably because something lists it in
 Built-Using.  For most parts it means the package is already removed
 but not all tools seem to recognise this e.g. the PTS, the BTS
 (allegedly) and by extension the auto-removal script.

$ apt-cache show debian-installer-7.0-netboot-kfreebsd-amd64|grep 
Built-Using|grep -o 'kfreebsd\S\+'
kfreebsd-8
kfreebsd-9

Mraw,
KiBi.


signature.asc
Description: Digital signature


Re: First autoremovals happen in about 8 days

2013-10-06 Thread Steven Chamberlain
On 06/10/13 08:52, Niels Thykier wrote:
 Laszlo Boszormenyi (GCS) g...@debian.org
vice: bugs 693641, flagged for removal in 8.3 days

Bug #693641 is another interesting edge case:

Found in version vice/2.3.dfsg-4 (testing, unstable, stable)
Fixed in version vice/2.4.dfsg-1 (unstable)
Marked as done

But it didn't quite build everywhere - kfreebsd-amd64 and s390 still
have out-of-date 2.3.dfsg-4 binaries in sid.  I'm not sure if this logic
was intended, but it actually makes sense:  the fixed version cannot
migrate to testing and replace the buggy one.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


-- 
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/5251bd46.8070...@pyro.eu.org