Re: CTTE requesting questions for DebConf20 BoF
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 > > > - > > > **Proposal 3**: Modify the Constitution to allow the TC to do design > > > work in the form of proposals. These proposals wouldn't override > > > developers or tell individual maintainers what to do, but rather > > > should > > > guide the project towards a technical goal. > > > > I'm continued to be puzzled about this. Clearly you are all individuals, > > why don't you do design work as individuals? > > A few people have asked about this already and I think it's my fault for > not explaining this correctly in the text. We can of course do design work > as individuals. The prohibition from doing design work becomes a problem > when the TC is forced to make a decision using the committee's powers and > none of the available options are deemed good enough (this happened, for > example, in our discussion of the maint-scripts issue). We are asked a > question but we can't "rule" and so we can't answer the question. > > If we _could_ do design work, then we would be able to bring forward a > proposal rather than have to say "we decline to rule because there are > no good options", which is kinda washing our hands. Does that make sense? yes, thanks. I'm now just wondering whether you intentionally just replied to me, or not. (I don't need to know, but I thought I let you know.) > I think I'll try to amend the text in Salsa to clarify this. :) -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C There are no jobs on a dead planet. signature.asc Description: PGP signature
Re: CTTE requesting questions for DebConf20 BoF
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 between developers, when no code-of-conduct violation is > in place. This could be to: > > a. A new group of developers > b. The Community Team > c. The Technical Committee. which of the three options does the tech-ctte (roughly) prefer? > Allow design work > - > **Proposal 3**: Modify the Constitution to allow the TC to do design > work in the form of proposals. These proposals wouldn't override > developers or tell individual maintainers what to do, but rather should > guide the project towards a technical goal. I'm continued to be puzzled about this. Clearly you are all individuals, why don't you do design work as individuals? -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#914897: we do have a complete archive rebuild for buster and sid amd64 (Re: Bug#914897: debating the wrong thing)
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.reproducible-builds.org/debian/index_performance.html and specifically at https://tests.reproducible-builds.org/debian/unstable/amd64/stats_builds_age.png and https://tests.reproducible-builds.org/debian/buster/amd64/stats_builds_age.png it seems that all of unstable and buster has been rebuild on amd64 since we enabled these tests (around Nov 9th). Looking more specifically at https://tests.reproducible-builds.org/debian/index_amd64_oldies.html it actually seems like the amd64 buster rebuild (testing usrmerge diffs) will only be completed in 24h or so ;) arm64 will be done soon as well, armhf will take a bit more time and i386 some more. If you only want to look at one url, look at the last one above, index_oldies... -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#914897: debating the wrong thing
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, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#914897: #914897: debootstrap, buster: Please disabled merged /usr by default
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. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#914897: #914897: debootstrap, buster: Please disabled merged /usr by default
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 with what other people tagged, > about 60 problems were found. (The oldest rebuild result for unstable > is 17 days old, the merged-/usr variation was deployed before that[1].) https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html lists these packages. what surprises me currently, are those 3 packages which are reproducible in buster (even though we also vary usrmerge when testing buster). -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu
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 much better. When working on said fix, nobody will want to be forced to look at the history of this bug again… -- cheers, Holger signature.asc Description: Digital signature
Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)
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 repeat themselves. -- cheers, Holger signature.asc Description: Digital signature
Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)
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 options /me likes. Thanks, Raphael. -- cheers, Holger signature.asc Description: Digital signature
Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)
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: > > What does selecting Debian Desktop Environment, but none of the > desktops do (it gives you Gnome, but there's no real hint here) > > How about if you deselect Debian Desktop Environment, and select Gnome > and KDE? (the desktop tasks all depend on task-desktop, so you get it > anyway AFAIK, but that's not the impression given). > > What is a print server? (CUPS) web server? (apache2) > > What do you get if you install without the standard system utilities, > does that still hold if you install a full desktop? > > Are we really expecting the people that we feel we must protect from > package names by hiding the fact that we're talking about CUPS and > Apache to know what LXQt is? exactly. > After adding the blends, that becomes this (having just used the daily > mini.iso downloaded this morning): > >[x] Debian Desktop Environment >[ ] ... Gnome >[ ] ... Xfce >[ ] ... KDE >[ ] ... Cinnamon >[ ] ... MATE >[ ] ... LXDE >[ ] ... LXQt >[ ] web server >[x] print server >[ ] SSH server >[x] standard system utilities >[ ] Special tasks >[ ] ... astronomy (Debian Astro) >[ ] ... games and fun (Debian Games) >[ ] ... life sciences and medicine (Debian Med) indeed, this is what it looks today. Just verified myself too. And this *is* still pretty confusing, though admitly better than it was half a year ago. > so that then prompts one to wonder: > > what the hell is "Special tasks" and what will I get if I select it? exactly > Do I need to select that to get Debian Med, say? > (no, it's just an empty header AFAIK) > > it also buries the 'standard system utilities' item in the middle of > the list, where it makes even less sense than it did at the end. and it will only get worse, if we would keep it this way… We have *many* more blends in Debian… Debian Parl, Debian Junor, Debian Edu come to my mind immediatly. why list some and not some others? and really, the list is too long already. please read https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758116#320 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758116#340 > So, I'd say that the whole thing was a car-crash anyway, and this just > dropped a cigarette in the spilling petrol. *hahaha* > The real problem is that there's not been the effort available in the > d-i team to come up with some better way of presenting the question. yes. and that this bug should not be about this tasksel menu but *about this was implemented*, which is by forcing an unneeded package on each and every Debian system under the sun. (priority: important…) - while this could have been implemented using udebs, thus not affecting installed systems! (debian-edu-profile-udeb is an existing example how to do that.) But really, there are two issues: how the menu should look like and whether we want "random" packages to be allowed to declare themselves priority: important and to be installed everywhere. I failed to make this clear initially, though I have tried by filing #846003 (and 005+006) as well. -- cheers, Holger, who will try his very best to shut up on this issue now. I have other fish to fry, and as I'm used to do "apt install screen vim less git" on any new system, I will get used to type "apt remove blends-tasks" as well. It's just stupid and bad design. signature.asc Description: Digital signature
Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)
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 advocating his point > instead of answering the arguments given in the bug report. wow. I'll have to let *this* sink. -- cheers, Holger signature.asc Description: Digital signature
agreed (Re: Replace the TC power to depose maintainers)
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 > particular course of action (which I need before I'm willing to override > anybody), and I take the time to explain it to them and discuss with > them, I find we usually end up agreeing. I fully agree with Tollef here. I'm also very sad I utterly failed in #846002 to do just that. I'm sorry. (And disappointed by myself.) Thanks, tech-ctte, that you are there. Please do take your time. -- cheers, Holger, going afk now for some time signature.asc Description: Digital signature
blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)
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 reassign it back. Noted, thanks. And yes, I still think it's really really wrong to have blends-tasks have "priority: important" which makes it getting installed by each and every debootstrap run by default. https://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities (And I'm really in no good position/mood/whatever to argue this any further. To me this issue is very very clear and I'm sometimes not good argueing issues which I think are very very clear.) Thus, the reassign. -- cheers, Holger signature.asc Description: Digital signature
Bug#846002: Lowering severity
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 that. Once again I was naive. -- cheers, Holger signature.asc Description: Digital signature
blends-dev must not be "priority: important" - was Re: Bug#846002: Lowering severity
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 debootstrap by default. https://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities is quite clear what important packages are, and IMO blends-dev clearly doesnt qualify as "noone expects it." IMO blends-tasks rather should be of priority: optional. Dear tech-ctte, please clarify. I don't have the time nor energy for bts-ping-pong, but Ole said he is going to close this bug soon (in addition to setting the severity to "normal") and closing this bug without changing the priority would just be wrong, IMO. Thanks. (And sorry for my lack of patience here.) (I'm also not sure who has the final say on definining priorities, the ftpmasters maybe? Feel free to swiftly re-assign there.) -- cheers, Holger signature.asc Description: Digital signature
Bug#835507: Please clarify that sysvinit support decision is not going to expire
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 to *help* maintain sysvinit compatibility, who
> actually use it, who will notice when it breaks, and who will send
> patches?"
I agree.
> I do think that developers (*not* the TC) with an interest in sysvinit
> support should explicitly say that if anyone needs help maintaining
> sysvinit support for their package, they'd be willing to volunteer to
> provide such help.
I agree.
> Anyone willing to volunteer for that?
I haven't found anybody personally volunteering for that. I just have
seen people saying that (other) people should (or will) do that.
So: do we have anyone, someone(s) who are volunteering to fix any bug
with init scripts in any package? Please raise your hands.
btw, somebody should also do something about #832508 ("O: systemd-shim)
I believe.
--
cheers,
Holger
signature.asc
Description: Digital signature
Bug#727708: piuparts sadly does not test init scripts^w^wdaemon starting (Re: Bug#727708: Bits from linux.conf.au)
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 sponsored cloud resources to support that. It seems like that would be fairly straightforward to duplicate for testing packages with alternative init systems. piuparts has /sbin/policy.rc.d in place with the content of exit 0, IOW, it does not execute init scripts at all. Running, monitoring and killing arbitrary daemons is not trivial. Help and patches welcome! :-) cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#618885: sasl2-bin: unowned files after purge (policy 6.8, 10.8)
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 removed.
Please note that /etc/sasldb2 is not a conffile. So, not removing it
should not be considered a policy violation.
Hm, right, at least on a quick search for config files I cannot find anything
in policy how config files should be treated, I can merely guess from the ucf
description that they exist...
I think that both of us feels strongly about our particular positions.
We may need to seek an alternate means of resolving this. Do you have
any ideas/suggestions on this?
yes, as you've seen by now :) I've now reassigned to policy as I've been
suggested to do on irc.
(And thank you very much indeed for looking for constructive ways out! Much
appreciated!)
cheers,
Holger
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201104291715.10736.hol...@layer-acht.org
Bug#562945: ping
AFAICT the case was quite clear, so whats left to do here? signature.asc Description: This is a digitally signed message part.
