Bug#970903: RM: dms/oldstable -- ROM; removing until have time to revamp it

Package: ftp.debian.org Severity: normal Hi! Could you please remove the package from unstable as I honetly don't have the time at the moment to revamp the package for modern Debian. I am about to take it our ot use probably for myself, as I am focusing on Samba server development and IPv6 for

Re: Removing gnome-shell-pomodoro from s390x

Hi Adam, On Sun, Oct 20, 2019 at 2:29 PM Adam D. Barratt wrote: > If packages need removing on particular architectures, that needs to > happen in unstable, via an ftp.debian.org removal bug. Makes sense. Thanks! Joseph

Re: Removing gnome-shell-pomodoro from s390x

m the wrong side. If packages need removing on particular architectures, that needs to happen in unstable, via an ftp.debian.org removal bug. Regards, Adam

Removing gnome-shell-pomodoro from s390x

Hi guys, As gnome-shell isn't in s390x anymore and is required for the installation (but not the build) of gnome-shell-pomodoro, Jeremy suggested in https://salsa.debian.org/debian/gnome-shell-pomodoro/merge_requests/2 that I release a new version that build-depend on gnome-shell (which I did

removing NBS cruft from (old)stable/updates

Hi, I'm sending this question to several teams since I'm not sure who is reponsible for cleaning up cruft in (old)stable/updates - release team, ftp-master and/or security team? I'd like to request removal of cruft binary packages from (old)stable/updates that are no longer built by the current

Bug#863407: Removing rdeps

Hi, removing rdeps is needed & desired. Please note that this bug is blocked by #863409 which you might want to act upon first. Cheers! ulrike

Re: Wondering about possibility of removing emacs24 from stretch

At this point, I think we're ready to proceed if the release team approves. The short answer is that there doesn't appear to be much difficulty, much risk, or much work required. We'd need to change a few package dependencies and change emacs-defaults to pull in emacs25 instead of emacs24.

Re: Wondering about possibility of removing emacs24 from stretch

OK, we're now down to these outstanding issues: - automake: can't yet sbuild; known sbuild issues (could try porterbox next) - doxymacs: appears fine; need to test resulting deb behavior. This package is orphaned, so we should be relatively free to fix it. - gnuplot: builds fine;

Re: Wondering about possibility of removing emacs24 from stretch

Rob Browning writes: > And at the moment, we have: > > First category: > - two packages that are likely fine once the deps are broadened > - five still to evaluate > Update regarding the second category: - ten packages that appear fine (plus or minus a

Wondering about possibility of removing emacs24 from stretch

that pace to continue for at least the next 5-10 days. Our intent was to continue with this work until we either had everything sorted out, or we found some issue that made it clear removing emacs24 wasn't going to be feasible right now -- and of course one such issue would be us already being too

Re: Proposal to do regular jenkins updates via jessie-updates (Was: Re: Removing Jenkins from Jessie)

Hi, On Mittwoch, 8. April 2015, Niels Thykier wrote: * There are several jenkins-* packages that will (presumably) need to be updated as often as Jenkins itself. I wondered which packages were jenkins* and figured it out with the help from Adam: holger@coccia:~$ dak rm -Rn jenkins Will

Re: Proposal to do regular jenkins updates via jessie-updates (Was: Re: Removing Jenkins from Jessie)

On Wed, 2015-04-08 at 23:33 +0200, Niels Thykier wrote: On 2015-04-08 22:45, Miguel Landaeta wrote: On Wed, 08 Apr 2015 18:17:59 +0200, Niels Thykier escribió: [...] I had a chat with James Page and Emmanuel Bourg about Jenkins over IRC. We concluded that it was infeasible for Debian

Proposal to do regular jenkins updates via jessie-updates (Was: Re: Removing Jenkins from Jessie)

On 2015-04-08 22:45, Miguel Landaeta wrote: On Wed, 08 Apr 2015 18:17:59 +0200, Niels Thykier escribió: [...] I had a chat with James Page and Emmanuel Bourg about Jenkins over IRC. We concluded that it was infeasible for Debian to maintain Jenkins due to the lack of upstream commitment to

Removing Jenkins from Jessie

Hi, I had a chat with James Page and Emmanuel Bourg about Jenkins over IRC. We concluded that it was infeasible for Debian to maintain Jenkins due to the lack of upstream commitment to a LTS release-cycle of sufficient length to match the length of Jessie[1]. Accordingly, we agreed to remove

Re: Removing Jenkins from Jessie

On Wed, 08 Apr 2015 18:17:59 +0200, Niels Thykier escribió: [...] I had a chat with James Page and Emmanuel Bourg about Jenkins over IRC. We concluded that it was infeasible for Debian to maintain Jenkins due to the lack of upstream commitment to a LTS release-cycle of sufficient length to

Bug#726709: marked as done (transition: removing tcl8.4, tk8.4)

Your message dated Thu, 27 Mar 2014 00:03:29 +0100 with message-id 20140326230329.gr17...@betterave.cristau.org and subject line Re: Bug#726709: transition: removing tcl8.4, tk8.4 has caused the Debian Bug report #726709, regarding transition: removing tcl8.4, tk8.4 to be marked as done

Bug#738616: removing newer libasio-dev (v1.10) from unstable

Package: release.debian.org We would like the version of libasio-dev in unstable to revert to the version currently in testing (1.4.8-2) Can you please remove the v1.10.1-1 libasio-dev from unstable or let me know what action to take, e.g. should I upload a 1.4.8-3 package? Also, could you

Bug#738616: removing newer libasio-dev (v1.10) from unstable

On Tue, Feb 11, 2014 at 10:44:30 +0100, Daniel Pocock wrote: Package: release.debian.org We would like the version of libasio-dev in unstable to revert to the version currently in testing (1.4.8-2) You might want to explain why. Can you please remove the v1.10.1-1 libasio-dev from

Bug#738616: removing newer libasio-dev (v1.10) from unstable

On 11/02/14 11:49, Julien Cristau wrote: On Tue, Feb 11, 2014 at 10:44:30 +0100, Daniel Pocock wrote: Package: release.debian.org We would like the version of libasio-dev in unstable to revert to the version currently in testing (1.4.8-2) You might want to explain why. API changes make it

Bug#738616: removing newer libasio-dev (v1.10) from unstable

On Tuesday, 11. February 2014 11:49:22 Julien Cristau wrote: No, we can't do that. And you shouldn't do that. What you can do is use an epoch to make the version number go backwards. Or if you want to avoid using epochs, reupload 1.4.8 using as 1.10.really.1.4.8 as the upstream version, and

Bug#738616: removing newer libasio-dev (v1.10) from unstable

On 02/11/2014 01:01 PM, Andreas Beckmann wrote: Or if you want to avoid using epochs, reupload 1.4.8 using as 1.10.really.1.4.8 as the upstream version, and upload 1.10 as 1.10.release to experimental. Once you upload upstream 1.11 you are back to normal version numbers without having used

Bug#738616: removing newer libasio-dev (v1.10) from unstable

Hi Daniel, On Tue, Feb 11, 2014 at 12:09:46PM +0100, Daniel Pocock wrote: Looks like the following three packages are impacted by this build dependency: src:abiword src:ball src:resiprocate All those packages need patching to work with the new version of asio due to API changes I

Bug#738616: removing newer libasio-dev (v1.10) from unstable

On 02/11/2014 01:40 PM, Julien Cristau wrote: Please try to avoid versioned -dev packages. Unless you really really have to keep both versions around for years. Why is that? Keep in mind this is a headers-only library, i.e. it only ever ships with a -dev (and a -doc) package. There's no other

Bug#738616: removing newer libasio-dev (v1.10) from unstable

On Tue, Feb 11, 2014 at 13:10:55 +0100, Markus Wanner wrote: On 02/11/2014 01:01 PM, Andreas Beckmann wrote: Or if you want to avoid using epochs, reupload 1.4.8 using as 1.10.really.1.4.8 as the upstream version, and upload 1.10 as 1.10.release to experimental. Once you upload

Bug#738616: removing newer libasio-dev (v1.10) from unstable

On 11/02/14 13:44, Markus Wanner wrote: On 02/11/2014 01:40 PM, Julien Cristau wrote: Please try to avoid versioned -dev packages. Unless you really really have to keep both versions around for years. Why is that? Keep in mind this is a headers-only library, i.e. it only ever ships with a

Bug#738616: removing newer libasio-dev (v1.10) from unstable

On 11/02/14 14:03, Julien Cristau wrote: On Tue, Feb 11, 2014 at 13:58:17 +0100, Daniel Pocock wrote: On 11/02/14 13:44, Markus Wanner wrote: On 02/11/2014 01:40 PM, Julien Cristau wrote: Please try to avoid versioned -dev packages. Unless you really really have to keep both versions around

Bug#738616: removing newer libasio-dev (v1.10) from unstable

On 2014-02-11 13:10, Markus Wanner wrote: On 02/11/2014 01:01 PM, Andreas Beckmann wrote: Or if you want to avoid using epochs, reupload 1.4.8 using as 1.10.really.1.4.8 as the upstream version, and upload 1.10 as 1.10.release to experimental. Once you upload upstream 1.11 you are back to

Bug#738616: removing newer libasio-dev (v1.10) from unstable

On 11/02/14 15:26, Andreas Beckmann wrote: On 2014-02-11 13:10, Markus Wanner wrote: On 02/11/2014 01:01 PM, Andreas Beckmann wrote: Or if you want to avoid using epochs, reupload 1.4.8 using as 1.10.really.1.4.8 as the upstream version, and upload 1.10 as 1.10.release to experimental.

Bug#738616: removing newer libasio-dev (v1.10) from unstable

On 11/02/14 15:41, Daniel Pocock wrote: On 11/02/14 15:26, Andreas Beckmann wrote: On 2014-02-11 13:10, Markus Wanner wrote: On 02/11/2014 01:01 PM, Andreas Beckmann wrote: Or if you want to avoid using epochs, reupload 1.4.8 using as 1.10.really.1.4.8 as the upstream version, and upload

Bug#738616: removing newer libasio-dev (v1.10) from unstable

Daniel, On 02/11/2014 09:46 PM, Daniel Pocock wrote: Has anybody else tried something else to deal with this package transition or reversion to 1.4.8? Or did I do something wrong when adding the epoch? I think you did just fine, but PTS is lagging behind. See here:

Bug#738616: removing newer libasio-dev (v1.10) from unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/02/14 22:18, Markus Wanner wrote: Daniel, On 02/11/2014 09:46 PM, Daniel Pocock wrote: Has anybody else tried something else to deal with this package transition or reversion to 1.4.8? Or did I do something wrong when adding the

Processed: Re: Bug#738616: removing newer libasio-dev (v1.10) from unstable

Processing control commands: reassign -1 asio 1.10.1-1 Bug #738616 [release.debian.org] removing newer libasio-dev (v1.10) from unstable Bug reassigned from package 'release.debian.org' to 'asio'. Ignoring request to alter found versions of bug #738616 to the same values previously set

Bug#738616: removing newer libasio-dev (v1.10) from unstable

Control: reassign -1 asio 1.10.1-1 Control: close -1 1:1.4.8-3 On 2014-02-11 22:26, Daniel Pocock wrote: We should mark 738613 fixed in the new version I think Done. Andreas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact

Re: Removing Tcl/Tk 8.4 from Debian

On Thu, Jan 9, 2014 at 14:13:04 +0400, Sergei Golovan wrote: Hi, release team! I would like to ask some advise in what to do else to get Tcl/Tk 8.4 removed from Debian for jessie. The current situation is the following: 1) There are only 3 packages left in unstable which require tcl8.4

Removing Tcl/Tk 8.4 from Debian

Hi, release team! I would like to ask some advise in what to do else to get Tcl/Tk 8.4 removed from Debian for jessie. The current situation is the following: 1) There are only 3 packages left in unstable which require tcl8.4 or tk8.4 for building (all of them do that because the fixed packages

Re: Removing a file with unclear license from kdesdk

Hi Pino, [Disclaimer: I am not part of the release-team] On 14-04-13 13:16, Pino Toscano wrote: while reviewing copyright for newer versions of kdesdk, we found out that one of the files, scripts/add_trace.pl, has an unclear license: | ## Written by David Faure fa...@kde.org, licensed under

Re: Removing a file with unclear license from kdesdk

On Sat, 2013-04-20 at 10:45 +0200, Paul Gevers wrote: On 14-04-13 13:16, Pino Toscano wrote: This script is not installed, so it is not part of any binary package we currently ship. Would you, release-team, allow an upload of kdesdk only dropping this file from the source (which is already

Removing a file with unclear license from kdesdk

Hi, while reviewing copyright for newer versions of kdesdk, we found out that one of the files, scripts/add_trace.pl, has an unclear license: | ## Written by David Faure fa...@kde.org, licensed under pizzaware. and there's no associated text on what it would imply. This script is not installed,

Removing block-udeb gtk+3.0?

cycle anyway, so removing that block-udeb would spare some questions/brain cycles on the -boot/-release side when considering unblock{,-udeb}'s. Don't you think? Mraw, KiBi. signature.asc Description: Digital signature

Re: Removing block-udeb gtk+3.0?

, and that wouldn't happen during the wheezy release cycle anyway, so removing that block-udeb would spare some questions/brain cycles on the -boot/-release side when considering unblock{,-udeb}'s. Don't you think? Makes sense, imo. Michael -- Why is it that all of the instruments seeking

Re: Removing block-udeb gtk+3.0?

On Wed, 2012-09-26 at 16:10 +0200, Cyril Brulebois wrote: since gtk+3.0 again appeared on my testing summary page (packages of interest as far as unblock{,-udeb}'s are concerned), I'm wondering whether it shouldn't just get its block-udeb removed? For the record; done. Regards, Adm -- To

Re: Removing Boost 1.46

On Mon, Jun 4, 2012 at 21:08:23 -0500, Steve M. Robbins wrote: Hi, The output from dak for removing source boost1.46 lists a number of broken r-deps, which is to be expected. I had expected that all such packages should be part of the Boost transition tracker [1] but surprisingly, two

Re: Removing Boost 1.46

On 5 June 2012 at 10:51, Julien Cristau wrote: | On Mon, Jun 4, 2012 at 21:08:23 -0500, Steve M. Robbins wrote: | | Hi, | | The output from dak for removing source boost1.46 lists a number of | broken r-deps, which is to be expected. I had expected that all such | packages should be part

Removing Boost 1.46

Hi, The output from dak for removing source boost1.46 lists a number of broken r-deps, which is to be expected. I had expected that all such packages should be part of the Boost transition tracker [1] but surprisingly, two are missing: gpsshogi: gpsshogi [amd64 i386] libosl: libosl1 [amd64

Re: Removing armhf / s390x from broken and/or fucked

Adam D. Barratt a...@adam-barratt.org.uk (19/05/2012): One question which has come up quite a bit recently is whether we should remove armhf and s390x from one or both of {broken,fucked}arches. Doing so doesn't necessarily imply making them release architectures, particularly while we're not

Re: Removing armhf / s390x from broken and/or fucked

On Sat, 2012-05-19 at 22:26 +0200, Cyril Brulebois wrote: Adam D. Barratt a...@adam-barratt.org.uk (19/05/2012): One question which has come up quite a bit recently is whether we should remove armhf and s390x from one or both of {broken,fucked}arches. Doing so doesn't necessarily imply

Re: Removing armhf / s390x from broken and/or fucked

better than armel from an overall perspective, and s390x looks equivalent to s390. Of course, both arches will continue to stay a bit worse until the flag is finally removed. As for fucked, I don't think it actually will make any difference, so removing them there would be recommended but isn't

Re: Bug#596351: Removing ohai and chef?

to my previous suggestion of removing ohai chef from squeeze. Once wheezy is up and running, there should be no problem getting the new libjson-ruby package in. There's always the option of providing packages via backports.debian.org once squeeze is released. Personally, I'd say it's time

Removing ohai and chef?

if the two string buffer implementations have similar APIs). Is there any chance you could do that? :) Bearing in mind Chris' previous comment: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596351#40 If the above is not possible, I return to my previous suggestion of removing ohai chef

Re: Bug#605662: upgrade-reports: removing splashy prevents booting (#512951)

On Sun, Dec 12, 2010 at 23:25:08 +0100, Simon Paillard wrote: Dear splashy maintainers, could you upload a 0.3.13-3+lenny1 in stable-proposed-updates based on 0.3.13-3 patched with 02_lsb-base-logging.sh_bug512951.diff ? http://www.debian.org/doc/developers-reference/pkgs.html#upload-stable

Re: Bug#605662: upgrade-reports: removing splashy prevents booting (#512951)

On Thu, 2010-12-30 at 18:48 +0100, Julien Cristau wrote: On Sun, Dec 12, 2010 at 23:25:08 +0100, Simon Paillard wrote: Dear splashy maintainers, could you upload a 0.3.13-3+lenny1 in stable-proposed-updates based on 0.3.13-3 patched with 02_lsb-base-logging.sh_bug512951.diff ?

Re: Bug#605662: upgrade-reports: removing splashy prevents booting (#512951)

Hi, Though splashy has been removed from testing, lenny users with this package will see their upgrade severely affected. On Thu, Dec 02, 2010 at 10:52:59AM +0100, Christian Meyer wrote: Package: upgrade-reports Severity: critical Justification: breaks the whole system I tried to provide

Re: Removing

On Tue, Oct 5, 2010 at 16:19:04 +0200, Emilio Pozuelo Monfort wrote: Hi, In our effort to remove old libraries, I would like to remove libgmime2.2a-cil from gmime2.2. We would have liked not to ship gmime2.2 with Squeeze at all, but that wasn't possible. However the Mono bindings are not

Re: Removing

On 06/10/10 19:18, Julien Cristau wrote: On Tue, Oct 5, 2010 at 16:19:04 +0200, Emilio Pozuelo Monfort wrote: Hi, In our effort to remove old libraries, I would like to remove libgmime2.2a-cil from gmime2.2. We would have liked not to ship gmime2.2 with Squeeze at all, but that wasn't

Re: Removing

On Wed, Oct 6, 2010 at 19:55:35 +0200, Emilio Pozuelo Monfort wrote: Uploaded, please unblock. Done, thanks for your work. Cheers, Julien signature.asc Description: Digital signature

Removing

Hi, In our effort to remove old libraries, I would like to remove libgmime2.2a-cil from gmime2.2. We would have liked not to ship gmime2.2 with Squeeze at all, but that wasn't possible. However the Mono bindings are not used by any package, and they are superseded by the 2.4 bindings, so I would

Re: Removing

On 10/05/2010 04:19 PM, Emilio Pozuelo Monfort wrote: Hi, In our effort to remove old libraries, I would like to remove libgmime2.2a-cil from gmime2.2. We would have liked not to ship gmime2.2 with Squeeze at all, but that wasn't possible. However the Mono bindings are not used by any

Re: Removing docky from gnome-do

On Wed, Sep 29, 2010 at 10:10:09PM +0100, Adam D. Barratt wrote: On Wed, 2010-09-29 at 20:12 +0100, Adam D. Barratt wrote: On Wed, 2010-09-29 at 18:46 +0100, Iain Lane wrote: We recently got FTBFS bug #598176 on gnome-do-docklets. This indicated me to the fact that we still ship the `docky'

Re: Removing docky from gnome-do

On Thu, September 30, 2010 10:20, Iain Lane wrote: On Wed, Sep 29, 2010 at 10:10:09PM +0100, Adam D. Barratt wrote: On Wed, 2010-09-29 at 20:12 +0100, Adam D. Barratt wrote: On Wed, 2010-09-29 at 18:46 +0100, Iain Lane wrote: It seems to me that the best way to resolve this is to patch docky

Removing docky from gnome-do

Hello release team! We recently got FTBFS bug #598176 on gnome-do-docklets. This indicated me to the fact that we still ship the `docky' theme in gnome-do. This functionality was branched out into a separate docky source package some time ago. The package is currently in Squeeze. It's not

Re: Removing docky from gnome-do

On Wed, Sep 29, 2010 at 06:46:09PM +0100, Iain Lane wrote: Hello release team! [...] I've prepared this update in SVN and attached the diff. Will you unblock such a change if it lands in unstable? Now really attached. Iain diff -u gnome-do-0.8.3.1+dfsg/debian/control

Re: Removing docky from gnome-do

On Wed, 2010-09-29 at 18:46 +0100, Iain Lane wrote: We recently got FTBFS bug #598176 on gnome-do-docklets. This indicated me to the fact that we still ship the `docky' theme in gnome-do. This functionality was branched out into a separate docky source package some time ago. The package is

Re: Removing docky from gnome-do

On Wed, 2010-09-29 at 20:12 +0100, Adam D. Barratt wrote: On Wed, 2010-09-29 at 18:46 +0100, Iain Lane wrote: We recently got FTBFS bug #598176 on gnome-do-docklets. This indicated me to the fact that we still ship the `docky' theme in gnome-do. This functionality was branched out into a

Re: removing swfdec from testing (gnome depends on it)

I wrote: On Tue, 2010-02-16 at 00:29 +0100, Santiago Garcia Mantinan wrote: I'm the maintainer of swfdec and I'd like to have swfdec packages removed from squeeze as upstream is no longer developping it, the problem here is that gnome-desktop-environment is depending on swfdec-gnome,

Re: removing swfdec from testing (gnome depends on it)

Le mercredi 24 février 2010 à 23:53 +, Adam D. Barratt a écrit : The removal won't take effect until the new meta-gnome2 is ready to transition, removing the dependency from g-d-e; that currently appears to be blocked by gnash FTBFS on ia64 and banshee being unbuildable on kfreebsd

Re: removing swfdec from testing (gnome depends on it)

remove swfdec we'll need to change the dependencies of gnome-desktop-environment or otherwise gnome will loose some of its packages. I've added a removal hint for swfdec0.8, swfdec-gnome and swfdec-mozilla. The removal won't take effect until the new meta-gnome2 is ready to transition, removing

removing swfdec from testing (gnome depends on it)

Hi! I'm the maintainer of swfdec and I'd like to have swfdec packages removed from squeeze as upstream is no longer developping it, the problem here is that gnome-desktop-environment is depending on swfdec-gnome, thus if we remove swfdec we'll need to change the dependencies of

Replacing defoma [was: Removing orphaned packages from testing]

On Tue, Feb 17, 2009 at 8:35 PM, Paul Wise p...@debian.org wrote: On Wed, Feb 18, 2009 at 8:44 AM, Raphael Geissert atomo64+deb...@gmail.com wrote: If there are 148 packages there should be at least what, 20 maintainers? (I would hope there are far more) why don't they, or the fonts team,

Re: Replacing defoma [was: Removing orphaned packages from testing]

On Sun, Mar 1, 2009 at 3:36 PM, Paul Hardy unifoun...@gmail.com wrote: Do you have enough familiarity with defoma to put together a guide for font maintainers to transition from defoma to whatever the alternative will be?  Should we just use fontconfig for TrueType/OpenType fonts? I use

Re: Removing orphaned packages from testing

in devscripts, but it would still make sense to provide such a script. I see many people interested in removing packages, I would like people interested in finding maintainers for orphaned packages. It's a task that can be done by everybody (no need to be DD/DM) and we should try to recruit some

Re: Removing orphaned packages from testing

On 16/02/09 at 23:27 -0800, Russ Allbery wrote: Lucas Nussbaum lu...@lucas-nussbaum.net writes: 2) improve awareness of orphaned packages. During the QA BOF, the idea of a script taking as input a list of packages (the list of locally installed packages on a DD's system, for example),

Re: Removing orphaned packages from testing

On Tue, Feb 17, 2009 at 5:30 PM, Raphael Hertzog hert...@debian.org wrote: I see many people interested in removing packages, I would like people interested in finding maintainers for orphaned packages. It's a task that can be done by everybody (no need to be DD/DM) and we should try

Re: Removing orphaned packages from testing

[Raphael Geissert] The idea was to leave them out of *testing*, not immediately dropping them from the archive. Isn't this equivalent to stating that being unmaintained is a release critical bug in a package? And if it is, would it not be better to just register new RC bugs to document the

Re: Removing orphaned packages from testing

On Mon, Feb 16, 2009 at 11:35:27PM +0100, Holger Levsen wrote: On Montag, 16. Februar 2009, Raphael Geissert wrote: The idea was to leave them out of *testing*, not immediately dropping them from the archive. Such a hint file could also (after a while...) be autogenerated and thus

Re: Removing orphaned packages from testing

Hello Raphael and *, is there a list of the orphaned testing packages? Thanks, Greetings and nice Day/Evening Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter,

Re: Removing orphaned packages from testing

Michelle Konzack wrote: Hello Raphael and *, is there a list of the orphaned testing packages? SELECT migrations.source FROM orphaned_packages,migrations WHERE migrations.source=orphaned_packages.source; on UDD should do it. Output as of right now:

Re: Removing orphaned packages from testing

Petter Reinholdtsen wrote: [Raphael Geissert] The idea was to leave them out of *testing*, not immediately dropping them from the archive. Isn't this equivalent to stating that being unmaintained is a release critical bug in a package? Yes, like I mentioned in my original mail. And

Re: Removing orphaned packages from testing

Russ Allbery wrote: Lucas Nussbaum lu...@lucas-nussbaum.net writes: Now, back to the topic. We have a problem, which is: We have too many orphaned packages. Those orphaned packages are orphaned either: (A) because they are 'crap' (poor quality/useless software, or software

Re: Removing orphaned packages from testing

severity: serious bugs and, possibly automated, auto removal hints? some other way? In any case, I think waiting a week since a package was orphaned before it is removed should be enough time in case a package is marked as orphaned by mistake. Removing crap from the archive is something

Re: Removing orphaned packages from testing

Raphael Geissert atomo64+deb...@gmail.com writes: Russ Allbery wrote: I think there's another case here, namely: (D) the software is useful, perhaps only in some corner cases but still useful, but all the people who both use it and have enough Debian experience to maintain it

Getting CC on -release (was Re: Removing orphaned packages from testing)

* Raphael Geissert [Mon, 16 Feb 2009 15:44:13 -0600]: [No CC please, thank] This will be done on a best-effort basis. We tend to always CC people on -release because it's a role address list, where people who may not be subscribed send requests (unblock requests during freezes, coordination for

Re: Removing orphaned packages from testing

Barry deFreese wrote: [...] I'm struggling a little with this. Obviously I'm the first person to want to see cruft removed and I realize we are just talking about testing but I'm thinking about something like Gtk1.2 which is currently orphaned with 60+ r(b)depends. Do we really want to those

Re: Removing orphaned packages from testing

Russ Allbery wrote: [...] If I don't have time to do a proper job of maintaining the package, I *definitely* don't have time to form a team, which takes even more time than just maintaining the package. Is using collab-maint so complicated? pinging the maints of the rdepends so that they all

Re: Removing orphaned packages from testing

Paul Wise wrote: On Tue, Feb 17, 2009 at 11:18 AM, Barry deFreese bdefre...@debian.org wrote: I'm struggling a little with this. Same. For example defoma has 113 rbdepends 148 rdepends. Removing all of them would likely remove all fonts from Debian. I don't think it is acceptable

Re: Removing orphaned packages from testing

) xdvik-ja vflib3 psfontmgr A few already use fontconfig or appear to: gnustep-back0.14-cairo (there are other gnustep-back* packages) ghostscript (via libgs) pango Perhaps removing all the orphaned leaf packages would be a good start though. Or finding an adopter. Sure, for packages

Re: Removing orphaned packages from testing

Raphael Geissert atomo64+deb...@gmail.com writes: Russ Allbery wrote: If I don't have time to do a proper job of maintaining the package, I *definitely* don't have time to form a team, which takes even more time than just maintaining the package. Is using collab-maint so complicated?

Re: Removing orphaned packages from testing

On 17/02/09 at 20:46 -0800, Russ Allbery wrote: If we're talking about a group of people taking collective responsibility for keeping orphaned packages kicking along, I guess I'm not sure how that differs from what we already have right now. (Although using a shared source control system for

Re: Removing orphaned packages from testing

On Sun, Feb 15, 2009 at 10:23:37PM -0600, Raphael Geissert wrote: Lenny is now out, so I think it is time to decide how to proceed with what was discussed during DC8. Is the release team still ok with the idea of keeping orphaned packages out of testing? how should it be done? via severity:

Re: Removing orphaned packages from testing

[No CC please, thanks] Lucas Nussbaum wrote: [...] Something like a DEP about handling of orphaned packages. Do you want to start that? :-) No offence, but DEPs sound like a lot of unneeded bureaucracy to me. A proper RFC should cover all the needs without making it boring and too long.

Re: Removing orphaned packages from testing

[No CC please, thank] Philipp Kern wrote: On Sun, Feb 15, 2009 at 10:23:37PM -0600, Raphael Geissert wrote: Lenny is now out, so I think it is time to decide how to proceed with what was discussed during DC8. Is the release team still ok with the idea of keeping orphaned packages out of

Re: Removing orphaned packages from testing

On 2009-02-16 15:44, Raphael Geissert wrote: The idea was to leave them out of *testing*, not immediately dropping them from the archive. +1 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Removing orphaned packages from testing

W. Martin Borgert wrote: On 2009-02-16 15:44, Raphael Geissert wrote: The idea was to leave them out of *testing*, not immediately dropping them from the archive. +1 I'm struggling a little with this. Obviously I'm the first person to want to see cruft removed and I realize we

Re: Removing orphaned packages from testing

On Tue, Feb 17, 2009 at 11:18 AM, Barry deFreese bdefre...@debian.org wrote: I'm struggling a little with this. Same. For example defoma has 113 rbdepends 148 rdepends. Removing all of them would likely remove all fonts from Debian. I don't think it is acceptable to break testing this much

Re: Removing orphaned packages from testing

), and outputting the list of problems (RC bugs, O/RFA bugs) was raised. There was opposition to providing this as something enabled by default in devscripts, but it would still make sense to provide such a script. Having a policy of not releasing orphaned packages (which would be implemented by removing

Re: Removing orphaned packages from testing

On 16/02/09 at 15:31 -0600, Raphael Geissert wrote: [No CC please, thanks] Lucas Nussbaum wrote: [...] Something like a DEP about handling of orphaned packages. Do you want to start that? :-) No offence, but DEPs sound like a lot of unneeded bureaucracy to me. A proper RFC should

Re: Removing orphaned packages from testing

Lucas Nussbaum lu...@lucas-nussbaum.net writes: Now, back to the topic. We have a problem, which is: We have too many orphaned packages. Those orphaned packages are orphaned either: (A) because they are 'crap' (poor quality/useless software, or software for which better

Removing orphaned packages from testing

Hi all, Lenny is now out, so I think it is time to decide how to proceed with what was discussed during DC8. Is the release team still ok with the idea of keeping orphaned packages out of testing? how should it be done? via severity: serious bugs and, possibly automated, auto removal hints? some

Re: Removing orphaned packages from testing

On 15/02/09 at 22:23 -0600, Raphael Geissert wrote: Hi all, Lenny is now out, so I think it is time to decide how to proceed with what was discussed during DC8. Is the release team still ok with the idea of keeping orphaned packages out of testing? how should it be done? via severity:

Re: Removing fama/... from testing?

Bernd Zeimetz wrote: clone 514255 -1 -2 reassign -1 tapioca-glib reassign -2 telepathy-sharp retitle -1 tapioca-glib: should not be part of a stable release probably retitle -2 telepathy-sharp: should not be part of a stable release probably thanks Hi Release Team, please have a look

Removing fama/... from testing?

clone 514255 -1 -2 reassign -1 tapioca-glib reassign -2 telepathy-sharp retitle -1 tapioca-glib: should not be part of a stable release probably retitle -2 telepathy-sharp: should not be part of a stable release probably thanks Hi Release Team, please have a look at #514255 - I think it makes

  1   2   3   >