Hi
Jérémy Bobbio wrote:
On Thu, Jun 05, 2008 at 10:41:16PM +0200, Adeodato Simó wrote:
However, there is no equivilant source of information for packages
apt-installed by d-i.
Could there be one? Well, if you're interested in having the same
safeguard mechanism in place for these packages.
* Andreas Barth [Fri, 06 Jun 2008 07:30:06 +0200]:
The mechanismn: yes. But not FauxPackages itself, as I think we could
generate that list automatic. (For a short-term solution, FauxPackages
might just be ok.)
I meant, yes, adding to FauxPackages an automatically-generated list,
not a list
On Thu, Jun 05, 2008 at 10:41:16PM +0200, Adeodato Simó wrote:
However, there is no equivilant source of information for packages
apt-installed by d-i.
Could there be one? Well, if you're interested in having the same
safeguard mechanism in place for these packages.
I have made a first
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2008-06-04 18:36, Pierre Habouzit wrote:
No it's not. A user that prefers to have broken software rather than
no software (if the option non broken software is absent) should use
unstable. I mean it.
You can easily use testing by default,
* Andreas Barth [Wed, 04 Jun 2008 07:19:07 +0200]:
Is there a reasonable way to
generate pseudo-packages taskel-$task that depend on all the packages
that need to be present to not break anything?
I think britney's FauxPackages would just be very appropriate for this?
(For those reading
Adeodato Simó wrote:
Could there be one? Well, if you're interested in having the same
safeguard mechanism in place for these packages.
It would be nice to have one, but many different parts of d-i decide
what to apt-install, so extracting a list is hard.
--
see shy jo
signature.asc
* Adeodato Simó ([EMAIL PROTECTED]) [080605 22:41]:
* Andreas Barth [Wed, 04 Jun 2008 07:19:07 +0200]:
Is there a reasonable way to
generate pseudo-packages taskel-$task that depend on all the packages
that need to be present to not break anything?
I think britney's FauxPackages would
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2008-06-04 16:11, Johannes Wiedersich wrote:
[1] search +testing +lenny on
The searches were performed without the '+' to have 'testing or lenny' etc.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2008-06-03 19:59, Pierre Habouzit wrote:
It depends of your definition of usable. I don't think it's usable on
a daily basis because:
FWIW, let the users decide what they use or want to use. I took a curde
estimate by counting what the readers
Andreas Barth wrote:
What we should make sure then is that britney recognizes these cases,
and shows breaking task foo for that. Is there a reasonable way to
generate pseudo-packages taskel-$task that depend on all the packages
that need to be present to not break anything?
You could use the
On Wed, Jun 04, 2008 at 02:11:51PM +, Johannes Wiedersich wrote:
Arguments like
On 2008-06-04 15:34, Pierre Habouzit wrote:
(2) To a user who wishes to use a working feature of an imperfect
package, Debian is better with the imperfect package than
without: MISSING PACKAGE
On Mon, Jun 02, 2008 at 11:16:51PM +, Mike Bird wrote:
On Mon June 2 2008 17:38:53 Lucas Nussbaum wrote:
On 02/06/08 at 15:04 -0700, Mike Bird wrote:
Don't create 20-day removal hints for packages with RC bugs
except when its too late for a fix to be included in the
forthcoming
On Mon, Jun 02, 2008 at 04:16:51PM -0700, Mike Bird wrote:
Debian Desktop Edition for most of the release cycle.
There is no Debian Desktop Edition. Perhaps you mean the Debian Desktop
subproject?
This is a useful (but unintended) side-effect. The principal
goal remains that Testing should
On Mon, Jun 02, 2008 at 04:27:08PM +, Raphael Hertzog wrote:
Package: release.debian.org
Severity: wishlist
Following a quick chat with Luk, and following the discussion in #484009
about the removal of update-notifier/update-manager, I want to make the
following suggestions:
- the
Pierre Habouzit wrote:
No, tasks are not our concern directly, as it lists many packages that
any user can live without, without being hurt or even impeded. The sole
thing that matters is the priority, but packages with high priorities
are hardly leaves packages as a general rule.
Tasksel
On Tue, Jun 03, 2008 at 04:42:22PM +, Joey Hess wrote:
Pierre Habouzit wrote:
No, tasks are not our concern directly, as it lists many packages that
any user can live without, without being hurt or even impeded. The sole
thing that matters is the priority, but packages with high
On Tue, Jun 03, 2008 at 08:08:07PM +, Joey Hess wrote:
Pierre Habouzit wrote:
Well in your list, there are several intersting examples. lv for
example, has many replacements. That may not have all the features of
lv, but that are a decent replacement. Moreover lv isn't _that_ known,
Pierre Habouzit wrote:
Well in your list, there are several intersting examples. lv for
example, has many replacements. That may not have all the features of
lv, but that are a decent replacement. Moreover lv isn't _that_ known,
and if this task doesn't install lv, noone will be hurt. OTOH
* Joey Hess ([EMAIL PROTECTED]) [080603 22:24]:
No, as I've already demonstrated, it's much more complicated than that,
and removal of lots of leaf packages that you may not consider important
at all can affect tasksel and the installer in various ways.
What we should make sure then is that
Package: release.debian.org
Severity: wishlist
Following a quick chat with Luk, and following the discussion in #484009
about the removal of update-notifier/update-manager, I want to make the
following suggestions:
- the release team should encourage volunteers to fix in priority RC bugs
that
Mike Bird wrote:
On Mon June 2 2008 09:27:08 Raphael Hertzog wrote:
I think it's important that the release team supports the work done on
tasksel (by the d-i team) by not removing unilateraly packages which are
listed in tasks. They have been added there in the first place for a
reason, it
On 02/06/08 at 11:32 -0700, Mike Bird wrote:
On Mon June 2 2008 19:05:38 Luk Claes wrote:
Mike Bird wrote:
A good idea but it doesn't go far enough. Personally I don't find
d-i tasks to be any more important than the packages I need, and
I suspect millions of Debian users have
On Mon, Jun 2, 2008 at 13:22:28 -0700, Mike Bird wrote:
There are better processes for reducing RC counts and
improving Debian without crippling Debian Desktop Edition.
Thanks for sharing your experience about improving Debian.
Oh, wait...
Cheers,
Julien
--
To UNSUBSCRIBE, email to
On 11404 March 1977, Mike Bird wrote:
Artificially lowering the RC count in Testing is not always
preferential to keeping Testing in a state amenable to testing.
You say yourself that it's not artificially as RC bugs in new packages
don't get that easily in testing anymore...
Removing
On 02/06/08 at 15:04 -0700, Mike Bird wrote:
On Mon June 2 2008 14:39:01 Joerg Jaspert wrote:
Feel free to work on an alternative algorithm to manage testing in a
different way, fixing what you currently dont like.
I am sure that, if you get the work done, the release team will take a
25 matches
Mail list logo
