Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
Hey Johannes, On Mon, May 15, 2023 at 06:48:04AM +0200, Johannes Schauer Marin Rodrigues wrote: >Quoting Steve McIntyre (2023-05-15 02:54:02) >> >> Pointing at gentoo or nixos as examples of projects that have decided >> to break compatibility doesn't cut it, I'm afraid. They're well known >> for changing fundamental things around Linux and (basically) not caring about >> interoperability. That attitude is *not* Debian's. > >me and Luca have different ideas about how bootstrapping a Debian chroot should >look like and I don't want to make an argument *for* changing PT_INTERP here as >I think that keeping compatibility with others by following ABI is a good thing >and because I think (and hope -- but Helmut is doing that analysis right now) >that the debootstrap problem can be solved in a way I envision without changing >PT_INTERP. But what I do not understand about the argument against Luca's >proposal is: > >Obviously, with Luca's proposal, binaries from packages built with a different >dynamic linker path in them would not work on distributions without merged-/usr >symlinks. But if the property of stuff from Debian being able to run on >non-Debian non-merged-/usr systems is an important one, then why was it okay to >have merged-/usr as the default? Because with merged-/usr we already changed >the interface contract for a lot of things because now binaries and libraries >can also be found at other locations than on non-merged-/usr systems. A script >with a /usr/bin/bash shebang built on and for Debian will not work on a system >without the symlinks. Despite the massive upheavals of merged-/usr in *other* ways, it's actually a *minor* change as far as compatibility is concerned here. The runtime linker (aka interpreter) is responsible for resolving symbols and finding needed libraries. So long as *that* bit works OK, then ~everything else should follow OK. This is how it's possible to have things work across distros: binaries don't actually care where the libraries live, or whether they came from rpm or deb packaging, etc. The issue at hand here is that the interpreter path is the most basic thing that matters for this compatibility. Break this and *nothing* can work. >So did we not years ago decide, that the result of the "cross- and >inter-project discussion" is, that everybody is going merged-/usr and that's >why we need it too and that's why it is okay to build a system where binaries >and scripts built for it just may not run on those other systems that do not do >it? With merged-/usr we already *did* "change fundamental things around" for >reasons that are really not clear to me (but which i do not want to discuss >here) and as a result did not "care about interoperability" (with those who do >not also adopt it). In my own Debian work I so far only got extra work because >of merged-/usr and I do not see the benefits (yet) and I was hoping that >"changing fundamental things around Linux and (basically) not caring about >interoperability" was *not* Debian's attitude but alas here we are. > >So have we not already burned the bridges to the non-merged-/usr world? Why was >it okay back then to say "we can make this change because all other important >players are doing merged-/usr so we can/have to as well". And now in the >PT_INTERP discussion somehow we care again about those systems? I thought we >already had the "cross- and inter-project discussion" about merged-/usr and >because the result was "yes, go for it" we did it too. But if that is the case, >why do we now care for a subset of the interoperability problems caused by >merged-/usr for systems that don't have it? This change is absolutely *not* needed to make merged-/usr work; if anybody is claiming that it is, then they are not being 100% honest with us. All the other distros doing merged-/usr have done it without making this change, and it's also been working OK for us so far without this change. Breaking an agreed interface contract like this is axiomatically *wrong* and will hurt us and the rest of the Linux ecosystem. -- Steve McIntyre, Cambridge, UK.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
I'm *trying* to assume good faith here, but I'm running out of energy to do so. On Mon, May 15, 2023 at 01:42:27AM +0100, Luca Boccassi wrote: >On Mon, 15 May 2023 at 01:14, Russ Allbery wrote: > >> Incidentally, that remains true even if we only do that in distribution >> packages. I certainly have copied binaries from a Debian package to other >> Linux systems before for various reasons and expected them to run. Sure, >> this might not work for other reasons outside of our control, but that's >> no reason to be gratuitously incompatible by breaking the ABI, >> particularly for what seem to be annoyances of our own creation with known >> workarounds. > >Thanks, that's the first actual real example mentioned so far. And >it's an interesting one: taking a $random Debian package and using it >on a completely different, non-Debian system. Is that a supported use >case? If so, does that mean that I can go ahead and raise a Severity: >serious bug on any package that doesn't work in such a way? Russ has described copying *binaries* out of packages and running them elsewhere. I've done that too, from time to time. This is one of the things made possible by the ABI contract being followed. You are the one proposing to break that contract, thereby *guaranteeing* this will fail on systems where otherwise it could work. I think the onus is on *you* to justify why this is a valid and useful thing to do. Your apparent lack of care for agreed standards here is horrifying. -- Steve McIntyre, Cambridge, UK.st...@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On Mon, May 15, 2023 at 12:24:15AM +0100, Luca Boccassi wrote: >On Sun, 14 May 2023 at 22:37, Josh Triplett wrote: > >> The x86-64 ABI is set. Feel free to make the case to the next >> architecture designer that their new ABI should have the dynamic linker >> in `/usr/lib`. That would *not* have the same downsides, as long as >> everyone agrees on a path. > >In practice it is not, though. There are other distributions that >change PT_INTERP for their own purposes, they've already been listed >in this thread. And I am still not hearing any concrete, factual use >case that would be impaired by such a change. I'm beginning to >seriously think there aren't any? Is that really the case? The ABI has been agreed and set down in documentation that *just about* everybody has been following since its inception. This includes the most basic set of definitions of what an x86-64 program must look like, including the interpreter path. If this path is changed, then *at the most basic level* we'd be making programs that are not valid by the ABI we've agreed to. This is an *external interface contract*, not something we should ever consider changing without significant cross- and inter-project discussion. Pointing at gentoo or nixos as examples of projects that have decided to break compatibility doesn't cut it, I'm afraid. They're well known for changing fundamental things around Linux and (basically) not caring about interoperability. That attitude is *not* Debian's. -- Steve McIntyre, Cambridge, UK.st...@einval.com "The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary." -- James D. Nicoll
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote: >On Fri, 12 May 2023 at 12:08, Steve McIntyre wrote: >> >> On Fri, May 12, 2023 at 11:40:05AM +0100, Steve McIntyre wrote: >> >On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote: >> >>On Fri, 12 May 2023 at 09:40, Steve McIntyre wrote: >> >>> >> >>> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote: >> >>> > >> >>> >The core issue as I see it is as follows: >> >>> > >> >>> >- Debian has decided to support only merged-/usr, including possibly >> >>> > moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2 >> >>> > as the interpreter in binaries. >> >>> >> >>> WTF? *Nobody* has been talking about breaking ABI like this, that I've >> >>> seen. The interpreter must *not* be changed willy-nilly. >> >> >> >>Nothing's happening 'willy-nilly'. We are discussing a bunch of >> >>seemingly crazy options, as in, "what would _actually_ explode if we >> >>do this or do that?", on this very d-devel thread. I posted a longer >> >>version here some days ago: >> >> >> >>https://lists.debian.org/debian-gcc/2023/05/msg00030.html >> > >> >Oh holy fuck. >> > >> >You're talking about changing ABI by doing this. That *is* utterly >> >crazy. No. >> >> People have asked me to expand on this further... >> >> I've been involved in defining ABI before, specifically for >> armhf. It's not a quick and easy process. It needs buy-in from all >> sides to make things work, and people *really* value the >> interoperability that it enables. >> >> The interpreter path is one of the most important parts of the ABI >> spec, the bit that makes binaries compatible between all the various >> stakeholders: compiler/tools people, distros, software vendors, >> etc. Lots of the rest of the details downstream of this can be >> changed, and people do this all the time - compare multilib to >> multi-arch for example. That all works fine *so long as* the runtime >> linker can be located and started OK. > >The loader is still available via the old path, so external/third >party/local/other software works unchanged. This should negatively >only affect our 1st party packages, when running on a non-merged >distro. So why the hell do you want to break this in the first place? Does a symlink in the "wrong" place offend you for some reason? For that you want to change a core assumption in *every single binary* in Debian? Believe me, I've been here in the past when we made changes in armhf to accommodate earlier mistakes. That was just for one architecture. What possible benefit do you see in this change? >And are _all_ our packages really 100% compatible with other distros >at all? Are they even supposed to be? > >For example, if I download efibootmgr from Bookworm on an Ubuntu Focal >machine, when I try to run it, it fails: > >root@focal:/tmp# wget >http://ftp.de.debian.org/debian/pool/main/e/efibootmgr/efibootmgr_17-2_amd64.deb >--2023-05-12 12:46:17-- >http://ftp.de.debian.org/debian/pool/main/e/efibootmgr/efibootmgr_17-2_amd64.deb >Resolving ftp.de.debian.org (ftp.de.debian.org)... 141.76.2.4 >Connecting to ftp.de.debian.org (ftp.de.debian.org)|141.76.2.4|:80... >connected. >HTTP request sent, awaiting response... 200 OK >Length: 27572 (27K) [application/vnd.debian.binary-package] >Saving to: 'efibootmgr_17-2_amd64.deb' > >efibootmgr_17-2_amd64.deb >100%[===>] 26.93K >--.-KB/sin 0.04s > >2023-05-12 12:46:17 (740 KB/s) - 'efibootmgr_17-2_amd64.deb' saved >[27572/27572] > >root@focal:/tmp# dpkg -x efibootmgr_17-2_amd64.deb ebm >root@focal:/tmp# ./ebm/bin/efibootmgr >./ebm/bin/efibootmgr: /lib/x86_64-linux-gnu/libc.so.6: version >`GLIBC_2.34' not found (required by ./ebm/bin/efibootmgr) > >Should I file a severity: serious bug against efibootmgr because it is >not interoperable? You're wilfully missing the point, and you know it. >The answer is obviously not, because it would be absurd to expect a >binary compiled against libraries from one distro to "just work" on an >entirely different distro. Glibc itself is not forward compatible, and >is allowed to add new symbols, that are not present in older versions, >and packages are allowed to depend on them. Aren't those also ABI >breakages? What about all the libraries that bump soname? What about >binaries that rely on newer kernel interfaces, or IPC interfaces? > &
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On Fri, May 12, 2023 at 11:40:05AM +0100, Steve McIntyre wrote: >On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote: >>On Fri, 12 May 2023 at 09:40, Steve McIntyre wrote: >>> >>> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote: >>> > >>> >The core issue as I see it is as follows: >>> > >>> >- Debian has decided to support only merged-/usr, including possibly >>> > moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2 >>> > as the interpreter in binaries. >>> >>> WTF? *Nobody* has been talking about breaking ABI like this, that I've >>> seen. The interpreter must *not* be changed willy-nilly. >> >>Nothing's happening 'willy-nilly'. We are discussing a bunch of >>seemingly crazy options, as in, "what would _actually_ explode if we >>do this or do that?", on this very d-devel thread. I posted a longer >>version here some days ago: >> >>https://lists.debian.org/debian-gcc/2023/05/msg00030.html > >Oh holy fuck. > >You're talking about changing ABI by doing this. That *is* utterly >crazy. No. People have asked me to expand on this further... I've been involved in defining ABI before, specifically for armhf. It's not a quick and easy process. It needs buy-in from all sides to make things work, and people *really* value the interoperability that it enables. The interpreter path is one of the most important parts of the ABI spec, the bit that makes binaries compatible between all the various stakeholders: compiler/tools people, distros, software vendors, etc. Lots of the rest of the details downstream of this can be changed, and people do this all the time - compare multilib to multi-arch for example. That all works fine *so long as* the runtime linker can be located and started OK. Changing the interpreter path would mean moving to a Debian-specific ABI, breaking that compatibility. Hand-waving that away with (and I quote): "The vast majority of distros today ship the loader in /usr/lib as /lib is just a symlink, so it would be interoperable." is appalling arrogance. No. You do *not* get to break ABI with that argument. The point of the ABI spec is that *everybody* follows it. You don't change it just because you think it'll make your life a little easier when bootstrapping a system. -- Steve McIntyre, Cambridge, UK.st...@einval.com Welcome my son, welcome to the machine.
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote: >On Fri, 12 May 2023 at 09:40, Steve McIntyre wrote: >> >> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote: >> > >> >The core issue as I see it is as follows: >> > >> >- Debian has decided to support only merged-/usr, including possibly >> > moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2 >> > as the interpreter in binaries. >> >> WTF? *Nobody* has been talking about breaking ABI like this, that I've >> seen. The interpreter must *not* be changed willy-nilly. > >Nothing's happening 'willy-nilly'. We are discussing a bunch of >seemingly crazy options, as in, "what would _actually_ explode if we >do this or do that?", on this very d-devel thread. I posted a longer >version here some days ago: > >https://lists.debian.org/debian-gcc/2023/05/msg00030.html Oh holy fuck. You're talking about changing ABI by doing this. That *is* utterly crazy. No. -- Steve McIntyre, Cambridge, UK.st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote: > >The core issue as I see it is as follows: > >- Debian has decided to support only merged-/usr, including possibly > moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2 > as the interpreter in binaries. WTF? *Nobody* has been talking about breaking ABI like this, that I've seen. The interpreter must *not* be changed willy-nilly. -- Steve McIntyre, Cambridge, UK.st...@einval.com "I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site..." -- Simon Booth
Re: Bug#1000239: Rescue system won't find root partition, but insists on /usr
On Sat, Dec 04, 2021 at 10:42:29PM +, Steve McIntyre wrote: >On Sat, Dec 04, 2021 at 11:37:28PM +0100, Pascal Hambourg wrote: >>Le 03/12/2021 à 22:08, Nicholas D Steeves a écrit : >>> >>> >>> c) parse /target/etc/fstab, and attempt to mount other partitions >> >>The rescue system already offers to do it for separate /boot and /boot/efi, >>so why couldn't it do for separate /usr too ? > >That's exactly what I'm about to do. In fact, it needed more work than that - the code chrooted into /target and ran mount there. That didn't work for a separate /usr. But I've refactored the code and made things work more cleanly inside d-i. I'm pondering backporting the same fix for future bullseye and buster point releases. -- Steve McIntyre, Cambridge, UK.st...@einval.com Dance like no one's watching. Encrypt like everyone is. - @torproject
Re: Bug#1000239: Rescue system won't find root partition, but insists on /usr
On Sat, Dec 04, 2021 at 11:37:28PM +0100, Pascal Hambourg wrote: >Le 03/12/2021 à 22:08, Nicholas D Steeves a écrit : >> >> >> c) parse /target/etc/fstab, and attempt to mount other partitions > >The rescue system already offers to do it for separate /boot and /boot/efi, >so why couldn't it do for separate /usr too ? That's exactly what I'm about to do. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Managing a volunteer open source project is a lot like herding kittens, except the kittens randomly appear and disappear because they have day jobs." -- Matt Mackall
Re: Dispute resolution in Debian
Hi folks, On Mon, Jul 27, 2020 at 07:01:23PM -0700, Sean Whitton wrote: >On Sun 26 Jul 2020 at 07:59PM -07, Felix Lechner wrote: >> >> Like any court, the Community Team and Technical Committee should be >> able provide independent solutions of their own design. Ideally, the >> judges at the lower level, i.e. the Community Team, would be elected. > >I think we think of the community team as mostly about the CoC -- not >just strict violations but conformance with its spirit -- whereas the TC >is about disagreements which do not involve (or do not primarily >involve) CoC issues. In which case, the relationship between the two >would not really fit the model you suggest. Correct - we're *mostly* targeting very different areas. There *can* be some overlap, but I don't see this working as Felix suggests. No harm in proposing new ideas, though! -- Steve McIntyre, Cambridge, UK.st...@einval.com "The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary." -- James D. Nicoll
Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?
Hi Didier, While I'm not necessarily disagreeing with the overall point(s) here, some of the points in this list of arguments seem dubious at best. Maybe you could expand? >* having separate `/` and `/usr` filesystems has been useful in the past for > booting without initramfs onto a minimal root filesystem that carried just > enough to mount the `/usr` filesystem later in the boot process. Given the > evolution of physical hosts' capabilities, initramfs'es have been default in > Debian (and elsewhere) for a long time, and most systems no longer have an > intermediate state during boot in which they have only `/`, but not `/usr`, > mounted. >* another use-case is to be able to share an identical `/usr` over a network > link; hence booting an initramfs, mounting a local `/`, then mounting `/usr` > over the network. It seems that an initramfs with everything needed to mount > a filesystem over a network link directly actually has a smaller footprint. >* booting with `/` only is not systematically tested in Debian anymore; I'm assuming you mean "/ without /usr" here? >* the packaging infrastructure to install files outside of `/usr` is not > standard and represents technical debt: I have no idea what you're suggesting here. >* given its status as remnant "folklore", the distinction between what _needs_ > to be shipped in `/` and what can stay in `/usr` is often interpreted > arbitrarily; >* allowing shipment of identically-named libraries or binaries in different > paths can confuse common understanding of paths precedence. ... >Various valid long-term desireable situations coexist, and while discussing >immediate countermeasures, it is useful to keep the long-term outcome that >those are most likely to produce. > >These are the five possible situations at the time of bullseye (buster + 1): > >* `none`: "merged `/usr`" has been reverted >* `weak`: both directory schemes are allowed, packages only built on classical > hosts >* `middle`: both directory schemes are allowed, packages can be built anywhere >* `hard`: both directory schemes are allowed, packages only built on > "merged `/usr`" hosts >* `all`: only "merged `/usr`" directory schemes are allowed, packages only > built on "merged `/usr`" hosts > >It can be summarized by the following table: > >``` >| | Host types that are allowed | Are merged `/usr` | >Official packages are built on| Packages built on … can break on the other >| >| Codename | classical hosts | merged `/usr` hosts | symlinks allowed | >classical hosts | merged `/usr` hosts | classical hosts | merged `/usr` >hosts | >|--|-|-|---|—|-|-|--| >| none | yes | no | no| >yes | no | yes | yes | >| weak | yes | yes |yes| >yes | no | no | yes | >| middle | yes | yes |yes| >yes | yes | no | no | >| hard | yes | yes |yes| > no | yes | no | no | >| all | no| yes |yes| > no | yes | yes | no | >``` > >The current state of buster is `weak`. > >=== DRAFT Resolution === > >The Technical Committee resolves to: > >* Option A: Ask the debootstrap maintainers to disable "merged `/usr`" by > default > (Using its §6.1.4 "Overrule a Developer" power; requires a 3:1 majority) > > Given that: > * hosts with both directory schemes already exist, > * the "merged `/usr`" directory scheme ought to be reserved for special >use-cases, > * official packages ought to only be built on classical directory schemes, > > … the Technical Committee considers that the desireable solution at the time > of bullseye is `weak`; and asks the debootstrap maintainers to disable > "merged `/usr`" by default. There is a deeper worry about builds that may be done against the "weak" background. Although buildd chroots are easily fixed up, there's going to be a (small, but unknown) set of maintainers who might be uploading binaries from merged systems. I think we're making good progress on source-only uploads and building in clean chroots etc., but... It's also likely not easy to pick up on "wrong" binary packages built this way. -- Steve McIntyre, Cambridge, UK.st...@einval.com The two hard things in computing: * naming things * cache invalidation * off-by-one errors -- Stig Sandbeck Mathisen
Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)
On Sat, Dec 24, 2016 at 02:25:48AM +0100, Philip Hands wrote: >Raphael Hertzog <hert...@debian.org> writes: >... >> So I agree with Cyril and the d-i team, we should be cautious here. >> >> Let's focus everybody's energy on getting Phil's patch merged instead >> of continuing this discussion. > >The latest incarnation of which I think is close to ready: > > https://anonscm.debian.org/cgit/d-i/pkgsel.git/log/?h=pu/simple_tasksel > >I've squashed the commits together, so we now have the first (aae3196) >which implements the feature, and would probably be fine as it is (once >comments to the translators have been added as appropriate). > >The second commit (1bb1feb) adds a level of indirection in the >template, with code to populate it from some new debconf settings, >which allows one to then customise the menu via preseeding. This is not >in any way essential to the task in hand, but might well be useful for >others. I'll be honest - that code scares me right now. If this was simple, obvious stuff then I'd be pushing to try and get this in. But it's not. Comments like + # there is no need to do this twice, and it breaks [back] behaviour if you do don't help, and I honestly don't understand what + db_subst pkgsel/simplified-tasksel $(echo $i | tr "a-z" "A-Z") "$subst" is doing when I read the code at 2am. Can you explain this better please? To make this kind of change for stretch, we'll also need updates to translations directly in the installer and in the installation guide. I'm worried that we're doing this too late in the cycle - as KiBi says. -- Steve McIntyre, Cambridge, UK.st...@einval.com "... the premise [is] that privacy is about hiding a wrong. It's not. Privacy is an inherent human right, and a requirement for maintaining the human condition with dignity and respect." -- Bruce Schneier
Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)
On Tue, Dec 20, 2016 at 03:01:50PM +0100, Cyril Brulebois wrote: > >Ole Streicher <oleb...@debian.org> (2016-12-20): > >> We already have more that 5700 popcon-counted installations with the >> blends selection in the installer. This should give some base for >> that. > >Surely, people asking for blends are using blends selection. That's nice >and I'm pretty sure nobody is going to dispute that. But that shouldn't >make d-i more confusing for others. Nod. I *have* also seen users confused by the addition of the blends into the tasksel list. A better split of the tasks (like Phil is suggesting) would help a lot here. -- Steve McIntyre, Cambridge, UK.st...@einval.com < liw> everything I know about UK hotels I learned from "Fawlty Towers"
Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)
On Tue, Dec 06, 2016 at 05:04:57PM +0100, Tollef Fog Heen wrote: >]] Ole Streicher > >> On 06.12.2016 10:37, Holger Levsen wrote: >> > And this *is* still pretty confusing, though admitly better than it was >> > half a year ago. >> >> The current implementation has a popcon of >5000, without a single >> complaint or confusion documented in the web within the last six months. >> This is at least *some* empirical evidence that it is not "pretty >> confusing", and again I would ask you to show any better empirical data >> here to support your own point. > >It's confusing enough that when I've had engineers from a provider >install Debian for me, I have ended up with a desktop rather than server >installation. Should I have filed a bug about it? Maybe. > >I think it would be better if we moved most of tasksel out of the >installer entirely and had an app store of some sort where applications >and blends could all be better presented with screenshots and >all. That's obviously out of scope for stretch, and it's not something >that the CTTE is going to do (if nothing else because you'd be far into >«detailed design work» territory). This would leave the installer with >a «Do you want a graphical UI and/or sshd?» as a question/questions, >rather than a list of tasks, some which make less sense today (CUPS) and >some which are cryptic (what's the difference between LXDE and >LXQt?). I'm not so sure. I think that what we could really do with is a more intelligent UI here to allow for multi-level choices: + Desktop UI? + Gnome + KDE ... + Server tasks + SSH server + File server + Web server ... + Debian Pure Blends + Astro + Astro option 1 + Astro option 2 + Debian-Edu ... etc. I've pondered about how to do achieve that with the existing debconf code, but not got very far yet. Including more descriptive text and maybe even screen shots with each would be very helpful. -- Steve McIntyre, Cambridge, UK.st...@einval.com Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer
Re: Please restrict posting to #727708
On Thu, Feb 06, 2014 at 03:53:56PM +, Jonathan Wiltshire wrote: Hi, Please give earnest consideration to limiting posting to #727708 (the init system technical committee bug) to only those members of the committee and whomever else they feel needs to contribute to the discussion at this stage. The comments from the public gallery do not help the situation right now, and although they may have been manageable for a while are now becoming nothing but ridiculous. Seconded 100%. :-/ -- Steve McIntyre, Cambridge, UK.st...@einval.com Further comment on how I feel about IBM will appear once I've worked out whether they're being malicious or incompetent. Capital letters are forecast. Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html -- 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/20140207151649.gc29...@einval.com
Bug#727708: systemd jessie - jessie+1 upgrade problems
On Wed, Dec 18, 2013 at 03:10:19PM +0200, Uoti Urpala wrote: In the kdbus case, systemd upstream already mentioned the possibility of shipping kdbus as a new module for older kernels. More generally, you can have solutions like applying some upgrades at boot rather than trying to switch parts from under a fully live system. This does still count as fully supporting upgrades. You might think so. To me, that sounds like a hacky workaround for needlessly inflexible software. Much like Windows. -- Steve McIntyre, Cambridge, UK.st...@einval.com The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary. -- James D. Nicoll -- 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/20131218132425.ga...@einval.com
Bug#727708: Aribtrarily breaking working interfaces?
Hi, committee members! I've been following #725714 with interest in the last few days. It seems that the arbitrary breakage of the module/firmware loading interface in udev last year [1] is now causing major issues for us and our users in debian-installer. I'm very concerned that exactly this kind of long-term breakage is likely to be a future problem with systemd... [1] http://lwn.net/Articles/518942/ -- Steve McIntyre, Cambridge, UK.st...@einval.com Every time you use Tcl, God kills a kitten. -- Malcolm Ray -- 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/20131212232629.gz8...@einval.com
Re: FTP masters willingly blocking OpenStack nova 2013.1 just right before the OpenStack summit
On Mon, Apr 15, 2013 at 07:49:10PM +0800, Thomas Goirand wrote: As a consequence, I am questioning the motivation behind all this, and asking myself if we aren't seeing here (yet) another instance of miss-behavior from Ganneff, who probably disliked the fact that I defended my friend when he expelled him, and when I questioned the possibilities of getting rid of the NEW queue in a debian-devel thread. I have of course no proof to back this up, and will probably never know if this really is an act of revenge, though I would like both the ctte and the DPL to take note of the event as (very) inappropriate. I would also like to point that the tone from Ganneff isn't acceptable. From someone who is both DSA, FTP Master and DAM (why so many powerful roles on a single pair of hands btw?), this isn't to be expected. For the moment, I will just ignore this, but if it was to happen again anytime soon, I will act upon it. Thus turning a technical disagreement with the ftp team into a personal attack on Joerg. Well done. :-( Adam has already pointed out your factual mistakes. -- Steve McIntyre, Cambridge, UK.st...@einval.com We don't need no education. We don't need no thought control. signature.asc Description: Digital signature
Bug#699808: Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On Thu, Feb 07, 2013 at 07:52:13AM +0100, Daniel Baumann wrote: consider such a misfeature to be in critical need of a fix (iirc steve puts a local copy of the 'to be used' syslinux version to be used by debian-cd for release images manually on the local fs; not sure about the same that ends up in the final release copy of debian-installer-images, will check later on)). Correcting - that used to be the case several years ago, but debian-cd now explicitly extracts files from the syslinux(-common) package in the main archive at CD build time, using the same suite as used in d-i for consistency. -- Steve McIntyre, Cambridge, UK.st...@einval.com Every time you use Tcl, God kills a kitten. -- Malcolm Ray -- 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/20130207095224.gb9...@einval.com
Bug#699808: Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On Thu, Feb 07, 2013 at 10:15:42AM +0100, Daniel Baumann wrote: On 02/07/2013 09:59 AM, Cyril Brulebois wrote: That doesn't mean we should be keeping syslinux 5 in sid in the meanwhile, especially since that's preventing us from releasing d-i wheezy rc1. (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 unfortunately the setup of debian-cd on the buildhost is not documented) when invoking debian-cd, it doesn't matter at all what version of syslinux is in sid. Already corrected elsewhere (repeating for clarity for people who may not read all of the thread here) - debian-cd uses syslinux from the archive at build time. -- Steve McIntyre, Cambridge, UK.st...@einval.com Further comment on how I feel about IBM will appear once I've worked out whether they're being malicious or incompetent. Capital letters are forecast. Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html -- 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/20130207095529.gc9...@einval.com
Re: Bug#573745: Please decide on Python interpreter packages maintainership
On Thu, Mar 18, 2010 at 10:31:03PM +0100, Andreas Barth wrote: * Piotr Ożarowski (pi...@debian.org) [100318 21:09]: [Andreas Barth 2010-03-18] I agree. I tried to get one such meeting done some time ago (see below) Here's my reply from that thread (Matthias or DPL never responsed, or at least I wasn't in the loop) The DPL was only in the loop for information. He already agreed to a meeting if it's useful, or basically anything we as group considered useful. So I didn't expact any answer either, unless we would have ask specifically for details of travel sponsorship for a meeting or so. Yup. The offer is still there if we think it will help, of course. -- Steve McIntyre, Debian Project Leader lea...@debian.org signature.asc Description: Digital signature
Re: New Technical Committee Members
On Mon, Jan 12, 2009 at 06:50:02PM +0100, Kurt Roeckx wrote: On Sun, Jan 11, 2009 at 11:57:31AM -0700, Bdale Garbee wrote: It gives me great pleasure to welcome Russ Allbery and Don Armstrong as the newest members of the Technical Committee. If I understand things right, you can add new members until the number reaches 6 and can then proposed new members to the DPL. And Steve organised the vote to add Russ (which got approved), and propose Don to the DPL. Andreas said that with 3 of the 5 votes for proposing Don the vote is over. But I think it's only 3 of 6 at that point, and the DPL still needs to approve it. We've discussed this and I'm entirely happy to accept the TC's recommendations for new members. Doubly so, as I personally recommended both! Until now, I just hadn't said so publically. Fixed. :-) -- Steve McIntyre, Debian Project Leader lea...@debian.org signature.asc Description: Digital signature
Re: Stepping down from tech ctte
On Mon, Jan 05, 2009 at 04:08:33PM +1000, Anthony Towns wrote: Hi *, So, as of today, it's been three years since I was appointed to the technical ctte. To me, that seems about the right length to stay on the committee -- anything you can't get done in three years doesn't seem likely to get finished just by sticking around longer, and in a project with hundreds of other clever folks around, there ought to be plenty of new faces and ideas ready to bubble up if they're given room. So thanks for the privelege of appointment, and best of luck for the future, y'all. Hi Anthony, Thanks very much for your efforts over those three years, I know they've been appreciated. For the rest of the TC: this means you're down to 5 members, which has special significance in the constitution (see 6.2). Do you have any suggestions for more people to increase your numbers again? I've had a couple contact me already to ask about this, and I have some people in mind myself whom I think would be a good fit. -- Steve McIntyre, Debian Project Leader lea...@debian.org signature.asc Description: Digital signature
Re: Processed: Forwarding to the technical committee
On Tue, Apr 04, 2006 at 08:10:50PM +0100, Ian Jackson wrote: Steve McIntyre writes (Re: Processed: Forwarding to the technical committee): I believe that Eduard has already come up with a GPL-compatible build system to use with cdrtools, but he is nervous of the possible consequences of applying such a patch. Joerg Schilling has apparently been getting threatening in email discussion over the last few days; there is a long German thread on this in the alioth pkg-cdrtools-devel mailing list. I can't seem to find a public archive of pkg-cdrtools-devel. Could you help me out by providing a pointer ? For some reason (?), it's not a public archive - it's linked from http://lists.alioth.debian.org/mailman/listinfo/pkg-cdrtools-devel as Joerg points out. In the face of such an aggressive upstream author with strong and controversial opinions about the GPL, forking may be a difficult option. Complete removal from Debian might be a better option, but I'd like some other opinions on this before we go to such lengths. IMO if we can fork it and remain confident of (a) our legal standing and (b) out ability to maintain the code then we should probably do so. What's the state of the alternatives to cdrecord ? As far as I'm aware, there are a few alternatives for the simple functionality of cdrecord, but there is no other Free Software that covers all of its functionality. I'm actually more worried about mkisofs - there isn't any comparable software for making ISO9660 filesystems, and it's a much more complex piece of software. There is a fair amount of expertise available to maintain forked code if necessary. Finding the time to do it is more of an issue, as always... :-/ -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Since phone messaging became popular, the young generation has lost the ability to read or write anything that is longer than one hundred and sixty characters. -- Ignatios Souvatzis signature.asc Description: Digital signature
Cdrtools licensing (was Re: Processed: Forwarding to the technical committee)
On Tue, Apr 04, 2006 at 11:00:16PM +0200, Joerg Jaspert wrote: On 10614 March 1977, Steve Langasek wrote: It's my understanding that Joerg Schilling is not the original author of mkisofs, and is definitely not the exclusive copyright holder. If earlier contributors released their work under the GPL, I'm not the least bit worried about Joerg suppressing a fork. Correct, mkisofs was initially written by someone else. JS claims that there is not that much code left, but I doubt that he could relicense it as he likes it. Yup; if needs be, we could even go back to an ancient version before Joerg got involved and fork from there. As far as not being able to fully replace cdrtools, though, freedom is not always convenient; and we have promised that Debian will remain free. If we have to excise his code from Debian, it's pretty clear that it will be a while before CD burning is again as convenient as it is today, but I don't see that it's avoidable if the copyright holder is not acting in good faith towards distributions he takes a personal dislike to. Well. He did like Debian the most of the distributions until recently (where that Bug came up), as we did only very minimal changes to his code. Seems like one of the last patches, which changed libscg a bit, made him also angry a bit, but overall it was ok. There's a long history of hostility from JS towards several of the distros and the Linux kernel developers; he has a very abrasive style of discussion and seems very rarely (if ever) capable of admitting mistakes. There was some talk quite a while ago between the cdrtools maintainers in several of the large distros about working together to maintain patches and/or a fork, but it bogged down due to lack of time - see freedrtools.freedesktop.org for more details. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] You lock the door And throw away the key There's someone in my head but it's not me signature.asc Description: Digital signature
Re: Cdrtools licensing
On Wed, Apr 05, 2006 at 12:47:42AM +0200, Joerg Jaspert wrote: On 10614 March 1977, Steve McIntyre wrote: Correct, mkisofs was initially written by someone else. JS claims that there is not that much code left, but I doubt that he could relicense it as he likes it. Yup; if needs be, we could even go back to an ancient version before Joerg got involved and fork from there. Only in theory. In practice we wouldnt be able to go back *that* far, we would lose a lot of stuff we need or want in mkisofs. But thats not a problem, there were never claims that any file in mkisofs has license problems. Its only the cdrecord.c part and the build system atm. True (ish) - mkisofs can use parts of cdrecord source and libscg for multi-session work too... Well. He did like Debian the most of the distributions until recently (where that Bug came up), as we did only very minimal changes to his code. Seems like one of the last patches, which changed libscg a bit, made him also angry a bit, but overall it was ok. There's a long history of hostility from JS towards several of the distros and the Linux kernel developers; he has a very abrasive style of discussion and seems very rarely (if ever) capable of admitting mistakes. Yesyes, i know that, im cdrtools debian maintainer for some time now. :) *grin* Just sharing that with the rest... There was some talk quite a while ago between the cdrtools maintainers in several of the large distros about working together to maintain patches and/or a fork, but it bogged down due to lack of time - see freedrtools.freedesktop.org for more details. Yah. If we go the fork way we would do something similar via our existing alioth project probably. But thats for later atm. Yup. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Into the distance, a ribbon of black Stretched to the point of no turning back signature.asc Description: Digital signature
Re: Processed: Forwarding to the technical committee
On Tue, Apr 04, 2006 at 11:37:53PM +0100, Ian Jackson wrote: Later on, Eduard Bloch asked: ] Also um ganz konkrett zu sein: drohst du mir offiziell mit ] Anwendung rechtlicher Mittel? and quotes Schilling's reply: | Ich drohe nicht. Wenn ich den Eindruck bekomme daß Du unwillig | bist durch eine Diskusion zu einem Sinnvollen Ergebnis zu kommen, | dann wende ich sie an. Eduard provided this translation: ] So to be concrete/clear: are you trying to threaten me with use of ] legal/juridistical remedies? | I don't threaten. When I have the impression that you are | unwilling to come to a sensible result within this discussion, I | am going to use them. Minor addition: Eduard later amended that translation: Wait, more appropriate translation for dann wende ich sie an is not going to use them but I am using them or then I will use them. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] There's no sensation to compare with this Suspended animation, A state of bliss signature.asc Description: Digital signature
