Your message dated Thu, 17 Oct 2024 14:29:39 +0100
with message-id
and subject line Re: Bug#1080521: transition: Removing gjs and GNOME Shell from
armel
has caused the Debian Bug report #1080521,
regarding transition: Removing gjs and GNOME Shell from armel
to be marked as done.
This means that
Hi,
On 05-09-2024 12:44, Simon McVittie wrote:
gjs is a JavaScript language binding for GLib-based libraries, required
by GNOME Shell, as well as several leaf GNOME applications like foliate
and gnome-maps. As part of GNOME 47, which is the GNOME release that
is likely to be shipped in Debian 13
On Fri, Sep 6, 2024 at 9:16 AM Simon McVittie wrote:
> 0. Adapt some packages to stop depending on gjs or gnome-shell on armel:
> […]
> 1. Wait for release team ack
> 2. Upload gjs/experimental and packages from (0.) to unstable
> 3. Adapt meta-gnome3 so gnome-core and gnome are only built on
>
Hi
On 06-09-2024 17:32, Paul Gevers wrote:
I also think that the faux-packages list is/can be architecture
specific, so it's probably trivial to fix but adding all architectures
but armel.
I have made the constraints arch specific and dropped armel from the
list. Looking at the current britn
Hi,
On 06-09-2024 15:16, Simon McVittie wrote:
When we discussed this in 2022, Paul Gevers said that the release team
could probably disable this check and allow task-gnome-desktop to be
uninstallable on armel...
I recall that we currently can't build d-i on armel anymore because
there are no
On Thu, 05 Sep 2024 at 11:44:31 +0100, Simon McVittie wrote:
> mozjs128 fails several tests on armel (#108) because armel's
> lack of atomic integer operations results in [badness]
Deja vu: we had a very similar situation almost exactly 2 years ago,
when we were integrating the GNOME release t
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org, debian-...@lists.debian.org
Control: affects -1 + src:gjs
User: release.debian@packages.debian.org
Usertags: transition
gjs is a JavaScript language binding for GLib-based libraries, required
by GNOME
Processing control commands:
> affects -1 + src:gjs
Bug #1080521 [release.debian.org] transition: Removing gjs and GNOME Shell from
armel
Added indication that 1080521 affects src:gjs
--
1080521: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1080521
Debian Bug Tracking System
Contact
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 m
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
m from 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
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 yes
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 v
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
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.
Summ
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; ne
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 couple of trivial patches)
ate a few packages a
day lately, and I expect 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 c
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
Wil
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 infeasibl
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 comm
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
> leng
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 the
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.
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? Contac
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
-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
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:
http://metadata.ftp-mast
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,
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
>>> ex
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
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 v
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 for years.
> > Why is that? Ke
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 wit
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 uploa
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
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 chan
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 us
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
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 cha
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 u
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 pleas
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 t
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
F
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 al
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 , licensed under
> pizzawar
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 , licensed under pizzaware.
and there's no associated text on what it would imply.
This script is not installed, so it is not
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
--
T
't heard yet of plans to port d-i to gtk3, 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?
Mak
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?
Mraw,
KiBi.
signature.asc
Description: Digital signature
Dear release team,
for the recent Haskell migration (thanks for that) we had to remove some
packages from testing (on all architectures) because there is a problem
with haskell-cryptocipher on powerpc. It is likely that there will be no
fix available in time for the release. I think our users are
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 su
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 track
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]
libos
h aren't ready".
I think we should definitly remove both from broken. armhf looks
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 thi
On Sat, 2012-05-19 at 22:26 +0200, Cyril Brulebois wrote:
> Adam D. Barratt (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 a
Adam D. Barratt (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 treating arch-specifi
not possible, I return 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
> squ
gs.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 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
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 ?
> >
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-stab
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 provi
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
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
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
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
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 l
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 patc
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'
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 ou
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
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
gnome-do-0.8.3.1+dfsg/d
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
desira
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,
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
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-*.
Regards,
Adam
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscrib
Santiago Garcia Mantinan schrieb:
> 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
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
gnome-desktop-envir
On Sun, Mar 1, 2009 at 3:36 PM, Paul Hardy 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 defoma for installing
On Tue, Feb 17, 2009 at 8:35 PM, Paul Wise wrote:
> On Wed, Feb 18, 2009 at 8:44 AM, Raphael Geissert
> 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, adopt
>> defoma? or replace it with
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 f
Raphael Geissert 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? pinging the maints of t
-conf)
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 ado
Paul Wise wrote:
> On Tue, Feb 17, 2009 at 11:18 AM, Barry deFreese
> 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
"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.
>
> I see many people interested in removing packages, I would like people
> in
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
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 th
* 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
Raphael Geissert 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 don't have enough t
ould it be done? via
> 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&q
Russ Allbery wrote:
> Lucas Nussbaum 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 bette
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.
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:
http://alioth.debian.org/~atomo64-
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, http://
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
> ma
[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 f
On Tue, Feb 17, 2009 at 5:30 PM, Raphael Hertzog 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 to
On 16/02/09 at 23:27 -0800, Russ Allbery wrote:
> Lucas Nussbaum 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), and outputting the
>
> opposition to providing this as something enabled by default 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 don
Lucas Nussbaum 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 alternatives exist)
>(B)
1 - 100 of 268 matches
Mail list logo
