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 Bruleb
rlier stable releases? No objections per se otherwise.
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
an.org/debian/tech-ctte/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 detai
ly, but 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
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 misguided,
> and that's th
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 not have resulted
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 we're not yet in deep
>
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 <--
>
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 with them.
Current
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 solve that by changin
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, I'll just state a
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 2016, Philip Hands w
Sam Hartman (2015-07-18):
> > "Bill" == Bill Allombert writes:
>
> Bill> On Fri, Jul 17, 2015 at 10:08:04PM +, Sam Hartman wrote:
> >> In March of 2014, Charles Plessy asked the Debian Technical
> >> Committee to review one of the policy editors decisions to revert
> >> c
Hi Sam,
Thanks for taking a look at this old thread/topic.
Sam Hartman (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 is, please confirm
Adam Borowski (2014-11-22):
> Hi!
> As Ansgar requests technical solutions, here's one:
>
> just like systemd-shim|systemd-sysv, switch the "init" package from
> Pre-Depends: systemd-sysv | sysvinit-core | upstart
> to
> Pre-Depends: sysvinit-core | systemd-sysv | upstart
>
> The set of pack
[ 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 (2014-10-18):
> Svante Signell writes:
>
> > In summary, the CTTE is asked to make a decision on debconf warnings on:
> > 1) Changing init system on upgrades (including sid)
Bdale Garbee (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 items are:
Ian Jackson (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:
debsnap -d . tftp-hpa 5.2-8
debs
Russ Allbery (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 provide des
Colin Watson (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 I may have miss
Joey Hess (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 using it causes
Daniel Baumann (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 already establi
Daniel Baumann (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 from debian-cd sources as unfortunat
Daniel Baumann (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 otherwis
Daniel Baumann (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 obvious things (debian-installer and
Bdale Garbee (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 static in
Daniel Baumann (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.
signature.asc
Description: Digital signature
Ian Jackson (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 reproduced below.)
>
> In respons
Laszlo Boszormenyi (GCS) (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
> application/x-
Charles Plessy (16/07/2012):
> If nobody else volunteers, I propose to start a maintenance group for
> the mime-support package, that I would store in a Git repository on
> Alioth's collab-maint group.
I think that's a perfect use case for collab-maint.
László, do you really need a dedicated gro
Frans Pop (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 udebs, where size i
31 matches
Mail list logo
