Bug#575059: Should Package-Type be included in udebs or not?

Frans Pop elen...@planet.nl (23/03/2010): Please note that I have not promoted the lintian warning as I'm well aware of the background of this. From Cyril's PoV the lintian warning may have seemed logical, And practical, since it makes sure we don't actually add some unneeded stuff in the

Bug#681687: Using FreeDesktop MIME entries directly in mime-support (Re: Fixing the mime horror ini Debian).

Laszlo Boszormenyi (GCS) g...@debian.org (16/07/2012): I think that's a perfect use case for collab-maint. László, do you really need a dedicated group for that? My intention was to limit people who can commit to mime-support. It seems there are multiple viewpoints for example about

Re: Please do not unblock gnome-meta just yet

Ian Jackson ijack...@chiark.greenend.org.uk (25/09/2012): As you may be aware, the TC recently overruled the maintainers of the gnome-core metapackage, deciding that the dependency from gnome-core to network-manager should be weakened from Depends to Recommends. (The full TC decision is

Bug#699808: tech-ctte: syslinux vs the wheezy release

Daniel Baumann daniel.baum...@progress-technologies.net (05/02/2013): or: * apply the following tested and working patch from #699742 in debian-installer, […] Except that this “tested and working patch” doesn't fix anything. Same issue, as seen by Michael and myself. KiBi.

Bug#699808: tech-ctte: syslinux vs the wheezy release

Bdale Garbee bd...@gag.com (06/02/2013): I personally consider this a regrettable situation, and hope that for jessie and beyond we can work out how to do this better. It is unacceptable to me to freeze anything in sid for more than a week or two at a time. Holding d-i's build dependencies

Bug#699808: Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release

Daniel Baumann daniel.baum...@progress-technologies.net (07/02/2013): On 02/07/2013 08:12 AM, Michael Biebl wrote: This list is getting longer with each email. Seeing that syslinux 5 has been in sid for less then 10 days, I'm worried what other issues might show up. apart from the two

Bug#699808: Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release

Daniel Baumann daniel.baum...@progress-technologies.net (07/02/2013): i'm not commenting on unfair accusations, so only to the relevant part: On 02/07/2013 09:00 AM, Cyril Brulebois wrote: again, note that any other virtualization software, be it in wheezy directly (qemu, kvm) or otherwise

Bug#699808: Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release

Daniel Baumann daniel.baum...@progress-technologies.net (07/02/2013): (ftr) which is where i disagree, with the mentioned patch against d-i and debian-cd, you can release d-i wheezy rc1, even with syslinux 5.x in sid. even more so: since steve uses a local copy of syslinux anyway (judging

Bug#699808: Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release

Daniel Baumann daniel.baum...@progress-technologies.net (07/02/2013): On 02/07/2013 10:27 AM, Cyril Brulebois wrote: That means at least broken mini.iso, which is totally unacceptable. broken without the patch i send for debian-installer, yes. If that can't be used with virtualbox (and we

Bug#699808: tech-ctte: syslinux vs the wheezy release

Joey Hess jo...@debian.org (07/02/2013): This can be done easily, just upload d-i to t-p-u. d-i uploads are already built with udebs from testing, for similar reasons. There seems to be an unholy fear of using t-p-u for anything these days, which I don't really understand. Even when not

Bug#727708: Call for votes on init system resolution

Colin Watson cjwat...@debian.org (2014-02-05): The only people who might reasonably be described as vaguely current maintainers of parts of d-i whom I can immediately find on a quick scan of the early parts of this bug are Wouter and myself; Tollef also contributed a good deal in the past, and

Bug#741573: On menu systems.

Russ Allbery r...@debian.org (2014-03-25): For most, but definitely not all, of our users, providing the desktop file is more important than providing the menu configuration. If we do nothing, the likely outcome is that more and more packagers who are using, e.g., GNOME or KDE will install or

Bug#746715: the foreseeable outcome of the TC vote on init systems

Ian Jackson ijack...@chiark.greenend.org.uk (2014-05-02): (It appears that archive.debian.org doesn't keep snapshots of experimental so it isn't easy to see exactly what was done.) You probably want: http://snapshot.debian.org/package/tftp-hpa/ Packages are easily downloaded this way:

Bug#746715: the foreseeable outcome of the TC vote on init systems

Bdale Garbee bd...@gag.com (2014-05-02): However, since this is in experimental, and not in a released tree or release candidate, this particular case is hard for me to get worked up about. http://packages.qa.debian.org/t/tftp-hpa.html has the timeline for the last few dozens uploads. Last

Bug#765803: tech-ctte: Ask before changing init system when upgrading to jessie and Inform about init systems when installing jessie

[ I would usually add debian-boot@ in Cc so that my peers get into the loop but let's not add extra noise. ] Russ Allbery r...@debian.org (2014-10-18): Svante Signell svante.sign...@gmail.com writes: In summary, the CTTE is asked to make a decision on debconf warnings on: 1) Changing init

Bug#741573: Investigation of the bug log

Hi Sam, Thanks for taking a look at this old thread/topic. Sam Hartman hartm...@debian.org (2015-06-23): If you seconded the proposal, I'd like to confirm that as part of your second, you believed that there was rough consensus and that objections that were raised had been addressed. That

Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

Since I've been asked in an IRC query whether I might be willing to consider this suggestion: Philip Hands (2017-02-03): > I think this is in part a symptom of mixing up multiple questions in > one request. > > There seems to be a consensus that the priority change was

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Hi Raphaël and all, Raphael Hertzog (2016-12-08): > I'm thus suggesting that blends-tasks should be removed and merged in > tasksel-data. At the same time, we should fix the installer to bypass > that confusing tasksel screen that we always get by default. > > On Wed, 07 Dec

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Hi, Philip Hands (2016-12-20): > Just as a reminder for the upcoming alpha that I was trying to do > something about this by adding an extra simplified tasksel promt: Thanks. I need to allocate time to test this, which this week doesn't permit. Without having looked at it yet,

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Hi, Ole Streicher (2016-12-20): > As I already wrote several times: before you do so, please show some > evidence that in the half year that the current version of the installer > containing a blends selection has added an unacceptable amount of > confusion and that we can't

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Hi, Philip Hands (2016-12-20): > Just as a reminder for the upcoming alpha that I was trying to do > something about this by adding an extra simplified tasksel promt: > > Philip Hands writes: > ... > > The menu is now: > > > > --> standard ("${DESKTOP}") desktop

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Raphael Hertzog (2016-12-24): > I would suggest to commit this to git, do a call for translators to > update this new translation and then judge on the result to see if you > have enough translations to release it for stretch. > > I know it's late in the release cycle, but

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Philip Hands (2016-12-24): > OK, this is tiresome -- you're complaining about question marks when I > was still exploring the options and looking for feedback -- I could > instead have been definite about an earlier option, but that would > have deprived you of choices, and would

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

Ole Streicher (2016-12-20): > This is for sure. Cyril just states that he rather would love to remove > the blends completely, and this is something I am arguing against. No, I said this was the default action, until I have looked at proposed changes, and assessed what to do

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

ut on this specific topic: I'm not aware of blockers that should prevent us from keeping this new default setting. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

tte/blob/master/914897_merged_usr/ballot.md Thanks, Didier. While I haven't dived into it as deep as you did (e.g. I didn't proofread the big table at the end), that seems like a reasonable characterization of the current situation; many thanks for your highly detailed summary. Cheers, -- Cyr

Re: Transition to usrmerge in full swing [was: Re: transition to usrmerge to start around 2022-09-15 (next Thursday)]

g, d-i works fine again since then. > - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020783 libdebian-installer just uploaded, sorry for the delay. cdebootstrap confirmed to be happy again with deploying an unstable or testing chroot once that's in place. Cheers, -- Cyril Brulebois (