Bug#562945: Bug#582755: Bug#562945: fails to install

2010-06-18 Thread Holger Levsen
Hi, btw, thank you all (tech-ctte) for helping in resolving this! Much appreciated. On Freitag, 18. Juni 2010, Steve Langasek wrote: > Personally, I don't think runit-run's behavior here is what's intended to > be allowed under Policy. IMHO, if the question is "do you want to install > this pac

Bug#562945: ping

2010-07-08 Thread Holger Levsen
AFAICT the case was quite clear, so whats left to do here? signature.asc Description: This is a digitally signed message part.

Bug#618885: sasl2-bin: unowned files after purge (policy 6.8, 10.8)

2011-04-29 Thread Holger Levsen
reassign 618885 debian-policy thanks Hi Roberto, hi policy maintainers! On Freitag, 29. April 2011, Roberto C. Sánchez wrote: > Regardless, policy states the following in section 6.8: > > 5. The conffiles and any backup files (~-files, #*# files, %-files, > .dpkg-{old,new,tmp}, etc.) are remov

Bug#727708: piuparts sadly does not test init scripts^w^wdaemon starting (Re: Bug#727708: Bits from linux.conf.au)

2014-01-17 Thread Holger Levsen
Hi, On Donnerstag, 16. Januar 2014, Anthony Towns wrote: > > it's not realistic for a porter to continously test startup > > scripts for thousands of packages. > It's reasonable to semi-continuously test installation scripts for > thousands of packages -- that's what piuparts does, and we have > s

Bug#727708: piuparts sadly does not test init scripts^w^wdaemon starting (Re: Bug#727708: Bits from linux.conf.au)

2014-01-17 Thread Holger Levsen
Hi, On Freitag, 17. Januar 2014, Lars Wirzenius wrote: > Indeed. Early on in my original development of piuparts I realised > that testing, in a chroot, code that starts arbitrary daemons is a bad > idea in oh so many ways. I haven't followed piuparts development in > recent years, so I don't know

Bug#835507: Please clarify that sysvinit support decision is not going to expire

2016-08-27 Thread Holger Levsen
On Fri, Aug 26, 2016 at 10:05:46PM -0700, Josh Triplett wrote: > The reaction to every single instance of someone finding it a pain to > maintain sysvinit support should not be "as a reminder, the TC has a > giant hammer and will hit you with it". The reaction should be "are > there people willing

blends-dev must not be "priority: important" - was Re: Bug#846002: Lowering severity

2016-12-05 Thread Holger Levsen
reassign 846002 tech-ctte thanks On Mon, Dec 05, 2016 at 09:58:03AM +0100, Ole Streicher wrote: > Control: Severity -1 normal src:blends 0.6.93 uploaded on 09 Apr 2016 introduced a new binary package, blends-dev, with "priority: important", causing it to be installed on *all* systems by debootstr

Bug#846002: Lowering severity

2016-12-05 Thread Holger Levsen
On Mon, Dec 05, 2016 at 02:34:56PM +0100, Ole Streicher wrote: > I am quite angry about this: You basically opened this bug by stating > that you will do an NMU within 4-5 days, but you already knew that you > would not have time to discuss the bug before you planned this to happen. I didnt knew t

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

2016-12-05 Thread Holger Levsen
control: reassign -1 tech-ctte control: retitle -1 blends-tasks must not be priority:important thanks On Mon, Dec 05, 2016 at 09:43:18AM -0600, Don Armstrong wrote: > if either of you disagree (or anyone else on the CTTE > disagrees) and still want the CTTE to resolve this (slowly), feel free > to

agreed (Re: Replace the TC power to depose maintainers)

2016-12-05 Thread Holger Levsen
On Mon, Dec 05, 2016 at 09:15:26PM +0100, Tollef Fog Heen wrote: > > Can you explain why the TC is so reluctant to depose or overrule > > maintainers ? > > Because I generally find it's generally the wrong tool for the job. If > I can come up with a good explanation for why somebody should take a

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

2016-12-06 Thread Holger Levsen
On Tue, Dec 06, 2016 at 09:45:27AM +0100, Andreas Tille wrote: > * Holger does not like the look of presenting tasks as they > where half a year ago. wrong. > * The conflict with policy seems artificial to me wrong. > and I have the > bad feeling Holger intends to hire people advoc

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

2016-12-06 Thread Holger Levsen
Thanks, Phil. On Tue, Dec 06, 2016 at 10:18:23AM +0100, Philip Hands wrote: > It makes the "what do you want to install?" menu slightly worse by > introducing some more befuddling options to it. It was already dire > though. exactly. > Before this… [...] > So, this was already a disaster area

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

2016-12-08 Thread Holger Levsen
On Thu, Dec 08, 2016 at 06:27:46PM +0100, Raphael Hertzog wrote: > But more importantly, we need to not show that page at all. I would like > to suggest a first screen: > > Install packages for a: > > [X] standard desktop > [ ] standard server > [ ] minimal server > [ ] Show me more optio

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

2016-12-20 Thread Holger Levsen
On Tue, Dec 20, 2016 at 03:16:50PM +0100, Ole Streicher wrote: > Again: the installer is there to test for 6 months now, but if it is > inacceptably bad: why are there no complaints? the complaints have been there for months, you just choose to consider them invalid. some people dont like to repea

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

2017-02-06 Thread Holger Levsen
On Sat, Feb 04, 2017 at 12:16:01PM +0100, Andreas Tille wrote: > Would it be a sensible compromise to reassign this bug to d-i tagging it > RC for buster to make sure a Blends menu will exist in the buster > installer. besides what Tollef already said about the severity I think a fresh new bug is

Bug#914897: #914897: debootstrap, buster: Please disabled merged /usr by default

2018-12-01 Thread Holger Levsen
Hi, Ansgar, thanks a lot for doing this! On Sat, Dec 01, 2018 at 06:06:28PM +0100, Ansgar Burchardt wrote: > So, I went through all reproducible build failures in unstable without > notes and added notes for differences caused by building in merged-/usr > vs non-merged-/usr packages. Together wi

Bug#914897: #914897: debootstrap, buster: Please disabled merged /usr by default

2018-12-02 Thread Holger Levsen
On Sat, Dec 01, 2018 at 10:21:50PM +, Simon McVittie wrote: > gzip, icecc and mailagent were most recently built for buster on > 2018-11-08, which might be long enough ago that the buster chroot was > not merged-/usr? right. I triggered their builds and now they are all shown as unreproducible

Bug#914897: debating the wrong thing

2018-12-04 Thread Holger Levsen
On Tue, Dec 04, 2018 at 07:21:11PM +0100, Adam Borowski wrote: > Your figure of ~80 packages counts only packages which went through a > reproducible-builds rebuild. We later learned only a part of the archive > got rebuilt since the bad debootstrap backport. wrong, sigh. -- cheers, Ho

Bug#914897: we do have a complete archive rebuild for buster and sid amd64 (Re: Bug#914897: debating the wrong thing)

2018-12-05 Thread Holger Levsen
On Tue, Dec 04, 2018 at 09:58:09PM +0100, Ansgar Burchardt wrote: > > We later learned only a part of the archive got rebuilt since the bad > > debootstrap backport. > Yes, some packages were not yet rebuilt in testing, but having them > rebuilt in unstable is enough. looking at https://tests.repr

Re: CTTE requesting questions for DebConf20 BoF

2020-07-27 Thread Holger Levsen
Hi Sean and the rest of the tech-ctte! 1st, thanks for preparing this BoF! In general I liked what I read, I just have a question or maybe two... On Sun, Jul 26, 2020 at 01:37:10PM -0700, Sean Whitton wrote: > **Proposal 2**: Explicitly delegate the mediation task for solving > social conflict b

Re: CTTE requesting questions for DebConf20 BoF

2020-07-29 Thread Holger Levsen
Hi Marga, On Tue, Jul 28, 2020 at 02:58:51PM +0200, Margarita Manterola wrote: > > which of the three options does the tech-ctte (roughly) prefer? > This is a great question and I hope we'll find the answer to this during the > BoF. :)) > > > Allow design work > > > - > > > **Pr