Re: Linking coreutils against OpenSSL
https://lists.debian.org/debian-arm/2021/06/msg1.html is the start of a thread about support for encryption in HW, which AFAIK uses the Crypto API. That's available on a number of arm64 devices. It may be useful to specify/detail a test so that people can (uniformly) test the performance on their devices (on various architectures). I did an OpenSSH/OpenSSL test, but I actually don't know if those were good tests. Still far from being an expert, but I was recently involved with testing a Crypto implementation for rk3566 (based) devices and noticed the results were rather mixed. It was much slower with 16 bytes, but significantly faster with 16384 bytes and the 'turnover' point was around 1024 bytes. In the discussion that followed, the point was made that HW-based Crypto would be much energy efficient and it would free up the CPU to do other things. So that could also be a factor that could be considered. Personally I don't have a problem with linking to OpenSSL, but I'm not a subject matter expert. HTH PS: The 'argument' wrt a certain package of Priority: important (not Essential) makes my blood boil, so this will likely be my only contribution to this thread. signature.asc Description: This is a digitally signed message part.
Re: Bug#885698: What licenses should be included in /usr/share/common-licenses?
Hopefully I'm not too late and I hope I won't make any ('dumb') mistakes as
I'm not as well-versed in licenses and packaging as other participants.
On Sunday, 10 September 2023 18:16:07 CEST Russ Allbery wrote:
> > * The license is DFSG-free.
> > * Exactly the same license wording is used by all works covered by it.
I think both of these criteria are excellent.
> > * The license applies to at least 100 source packages in Debian.
>
> In the thread so far, there's been a bit of early convergence around my
> threshold of 100 packages above. I want to make sure people realize that
> this is a very conservative threshold that would mean saying no to most
> new license inclusion requests.
On Sunday, 10 September 2023 05:35:27 CEST Russ Allbery wrote:
> Here are various concerns that people have had in this area in the past.
>
> * common-licenses consumes disk space on every installed Debian system of
> any size, and therefore should be kept small to avoid wasting system
> resources.
The only reason for not doing so that I've detected is worry about disk space?
If we were talking about several Megabytes (or even larger) then I could see
that point. But license text is max several Kilobytes?
diederik@bagend:/usr/share/doc$ find . -name copyright | wc -l
3759
I suspect I have an enormous amount of duplicate license texts on this system
and replacing those with references to common-licenses will likely reduce the
waste of system resources.
Optionally the license texts in common-licenses could be gz compressed (gzip
is Priority: required) to reduce disk-space even further.
So I would be in favor of dropping the threshold.
> > * The license text is longer than 25 lines.
The primary reason I'm in favor of dropping this too is consistency.
On Sunday, 10 September 2023 05:35:27 CEST Russ Allbery wrote:
> Here are various concerns that people have had in this area in the past.
>
> * Including long legal texts in debian/copyright, particularly if one
> wants to format them for copyright-format, is tedious and annoying and
> doesn't benefit our users in any significant way, and therefore we
> should include as many licenses as possible in common-licenses to spare
> people that work.
This is an important reason why I'd want to have most/all licenses that are
used in Debian included in common-licenses.
It's not only tedious and annoying, but also (because of that) error prone.
And then you run the risk of the included license text not being (word-for-
word) the same.
Getting rid of tedious/annoying/repeating busy work seems like a win for
everyone.
And IMO it's not only not beneficial to our users, but actually provides extra
work. If I want to make sure the license text is indeed the same as my
(hopefully correct) local copy, I'd have to run a `diff` with the included text
in the copyright file. And that applies to every user who'd want to do that.
And also for a prospective (new) maintainer of a package.
I'm a (big) fan of SPDX because it simplifies and clarifies things (a lot IMO)
and makes things more consistent. And I'm a sucker for consistency.
I do think that the license should be provided locally (and its availability
not be dependent on a build step in some other tool).
Having a link to an online version may be a useful extra service, but having a
working internet connection should not be a requirement (IMO).
Cheers,
Diederik
signature.asc
Description: This is a digitally signed message part.
Re: Proposed MBF: Removal of libfreetype6-dev (causing FTBFS)
On Saturday, 19 August 2023 11:14:02 CEST Andreas Metzler wrote: > > What is the recommended/appropriate way to deal with such issues? > > The agreed reached was not "let's ignore it, lintian has been warning > about it". Instead a way forward that /should/ have avoided any breakage > (versioned provides) was proposed and chosen. Ah, the versioned provides is what makes it *not* FTBFS! I missed that as had been added on 2021-12-28 already (bug #1002049) and I didn't look back in the history far enough. (I may also not have made the connection though) Thanks :-) signature.asc Description: This is a digitally signed message part.
Re: Proposed MBF: Removal of libfreetype6-dev (causing FTBFS)
On Saturday, 19 August 2023 10:54:20 CEST Sven Joachim wrote: > On 2023-08-19 10:03 +0200, Diederik de Haas wrote: > > [please CC me as I'm not subscribed to debian-devel] > > > > On Mon, 17 Jul 2023 at 21:45:13 +1000, Hugh McMaster wrote: > >> On Mon, 17 Jul 2023 at 00:07, Simon McVittie wrote: > >> > On Sun, 16 Jul 2023 at 22:38:20 +1000, Hugh McMaster wrote: > >> > > Currently, there are 219 build-dependencies and 29 (direct) > >> > > dependencies on libfreetype6-dev, which has been released with > >> > > bullseye and bookworm. > >> > > >> > Lintian diagnoses this as "[build-]depends-on-obsolete-package" since > >> > 2.116.0 (MR at [1], instances of the relevant tags listed at [2] and > >> > [3]) which will hopefully help progress towards dropping the > >> > transitional > >> > package. > >> > >> Thanks for pointing this out. I wasn't aware Lintian had started > >> flagging dependencies on obsolete packages some 10 months ago. > >> > >> Having Lintian issue a warning or error instead of bug filing is > >> preferable.> > > While it's true that lintian did issue an error, now that src:freetype has > > been updated and libfreetype6-dev has been dropped, there are a number of > > packages which hadn't been updated and now FTBFS. > > Could you please name an example? Hmm. It appears there is something wrong in my reasoning. I first looked at https://tracker.debian.org/pkg/xft, so that would be my example. It Build-Depends on libfreetype6-dev (and libfontconfig1-dev), so I assumed that when that B-D no longer exists, it would thus FTBFS. So I made https://salsa.debian.org/xorg-team/lib/xft/-/merge_requests/3 to fix that, but while it did make the CI pipeline succeed, it was only after your message that I realized that the 'before' pipeline *did* succeed in the 'build' job ... which indicates it does NOT FTBFS. But I still don't understand why. Can you point out where my reasoning is incorrect and that a 'disappearing' B-D does not (automatically) cause a FTBFS? > At the time I recommended just removing the libfreetype6-dev package[2], > based on my experience with the transitional -dev packages in ncurses, > where this approach worked without a hitch. What is different in > freetype? I did see your message, but as described above I didn't/don't understand why that apparently does work. Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Re: Proposed MBF: Removal of libfreetype6-dev (causing FTBFS)
[please CC me as I'm not subscribed to debian-devel] On Mon, 17 Jul 2023 at 21:45:13 +1000, Hugh McMaster wrote: > On Mon, 17 Jul 2023 at 00:07, Simon McVittie wrote: > > On Sun, 16 Jul 2023 at 22:38:20 +1000, Hugh McMaster wrote: > > > Currently, there are 219 build-dependencies and 29 (direct) > > > dependencies on libfreetype6-dev, which has been released with > > > bullseye and bookworm. > > > > Lintian diagnoses this as "[build-]depends-on-obsolete-package" since > > 2.116.0 (MR at [1], instances of the relevant tags listed at [2] and > > [3]) which will hopefully help progress towards dropping the transitional > > package. > > Thanks for pointing this out. I wasn't aware Lintian had started > flagging dependencies on obsolete packages some 10 months ago. > > Having Lintian issue a warning or error instead of bug filing is preferable. While it's true that lintian did issue an error, now that src:freetype has been updated and libfreetype6-dev has been dropped, there are a number of packages which hadn't been updated and now FTBFS. AFAIUI there are people and/or tools which periodically rebuild packages to see if a 'sudden' change has caused a FTBFS and that then gets followed up by a MBF effort. As the FTBFS wrt libfreetype6-dev was predicted and announced [1], wouldn't it have been better if the MBF had taken place? What is the recommended/appropriate way to deal with such issues? [1] https://lists.debian.org/debian-devel/2023/07/msg00193.html signature.asc Description: This is a digitally signed message part.
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)
On Friday, 2 June 2023 20:59:27 CEST Wouter Verhelst wrote: > "complain on -devel" is not part of the job That wasn't my intend, but I obviously horribly failed at that. Won't happen again o/ signature.asc Description: This is a digitally signed message part.
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)
On Wed May 31, 2023 at 12:44 PM CEST, Wouter Verhelst wrote: > On Wed, May 31, 2023 at 12:51:06AM +0200, Diederik de Haas wrote: > > While it may be a no-brainer for a person with a $/€ 1000 a month residual > > income to just buy new hardware whenever they feel like it, that is not the > > case for everyone. > [...] > > It's absolutely true that modern machines are more energy efficient. What > > is > > also true is that the production of new devices has a big environmental > > impact. > > 20+ year old machines are typically more power hungry, more expensive, > less performant, and less reliable than an up-to-date raspberry pi. If > you want to support people who can't afford shiny new hardware, I think > pointing them to raspberry pi-class hardware is a better idea than I have worked to improve support for Pine64 devices (too), so that people who can afford it, can buy power-efficient SBCs (instead of horrible RPi's where the non-free firmware is the least of their sins). My point is: what about people who don't have the option to *buy* anything (new or used), for financial, logistical or other reasons? I've been keeping an eye on developments in the upstream linux kernel and saw there was a 'spring cleaning' (i.e. removal of old HW support). Reading through the commit messages, I noticed 2 criteria for removal: - Code has (effectively) been unmaintained for MANY years - The maintainers have not seen any indication for several years that ANYONE is actually using that hardware. I think those are very reasonable criteria. In my initial reply I quoted someone who EXPLICITLY said there were people who actually used those i386 devices. On the kernel team I've an actual valid argument why supporting i386 hardware is *difficult* as they don't have the HW (themselves) to reproduce an i386-specific issue or to test a potential fix for that. In the responses here, I've mostly seen the *assumption* that those old devices must be power hungry. While I'm quite sure modern hardware is more power *efficient*, that doesn't mean old hardware is thus power hungry. But most of all, I'm flabbergasted/annoyed that someone who made explicit and clear what they need, namely keeping support for i386, a bunch of people feel the need to respond like "Well, actually, you need this (other thing)". I find that extremely condescending. Maybe it's an option to answer the ACTUAL question? (and that answer could be 'no') > I don't think "but old hardware is still used" is a very good argument > for keeping i386 around. I think that's actually an excellent reason. I've likely missed prior discussions around this subject, but I haven't seen and can't think of the reasons why so many people seem so adament to get rid of i386 ASAP. Assuming there are indeed valid reasons to get rid of i386, I think it would be a far better plan to announce that **Trixie** will be the last release that will support i386. That way people who care about i386 have a full development cycle to make i386 the best it can be for as long as they can still use that HW. Maybe they can also make arrangements with CIP to designate the Trixie kernel as a Super Long Term Support kernel release. But tackling on the release notes at the very last moment that Bookworm will be the last supported release, seems not so 'nice' IMO. Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)
[Please CC me in replies as I'm not subscribed to this list] I hope I'm not too late for this discussion ... Steve McIntyre wrote: > Luca Boccassi wrote: > >On Fri, 19 May 2023 at 12:42, Steve McIntyre wrote: > >> I'm planning on stopping publishing installer images for i386 > >> soon. Why? We should be strongly encouraging users to move away from > >> If they're still running i386 *hardware*, then they should be replacing > >> that hardware with more modern, more capable, more *efficient* stuff. > >> > >+1 for stopping publishing installers for i386, it has been mentioned > >many times but it's always worth repeating: electricity costs to keep > >running i386 hardware are already way higher than what it costs to buy > >a cheap, low-power replacement like a raspberry pi, that also provides > >better performance. > > Exactly. > ... > If people have strong opinions about that plan, let us know please. I have *strong* opinions about this. https://lists.debian.org/debian-kernel/2023/01/msg00372.html was a message/ plea to not forget about supporting OLD systems. While it may be a no-brainer for a person with a $/€ 1000 a month residual income to just buy new hardware whenever they feel like it, that is not the case for everyone. To quote (a part) of that email: > I happen to know of a few derivative projects that have been using > Debian technology that have brought new life to some really aging equipment > and some people in either Third World countries or in communities with low > incomes and either limited or non-existent access to modern equipment. One > such effort, the antiX distribution, has been effective in reaching poor > communities in Brazil recently, and has long been able to reach people with > scaled down Debian technology all over the world. > > I'm wondering if there is some way to provide a "hook" or a way for some of > these ten to twenty year old systems to remain functional for those who may > not otherwise have a way, other than to run insecure, out of date systems. > If there is a way, even a "side project", I hope that the Debian community > can help a few of these derivative distributions assist people worldwide to > have access to modern technology, > even from systems that are barely "modern" any more. Besides people in 'third world countries' (I actually don't like such qualifications at all), there are also people in the '1st world' who work their asses off just to put food on the table, and thus also don't have the money to buy new equipment. But if you want to interact with your own government, you highly likely will need to have some PC (type) equipment. It could also provide a way to learn/develop new skills. It's absolutely true that modern machines are more energy efficient. What is also true is that the production of new devices has a big environmental impact. https://mastodon.green/@gerrymcgovern/110329331475328263 said: > The European Environmental Bureau has stated that extending the lifespan of > smartphones and other electronics by just one year would save the EU as > much carbon emissions as taking two million cars off the roads annually. I would be VERY disappointed if Debian would abandon people who do NOT have the means to just buy new equipment whenever they feel like it. Especially when I see various proposals to make the 'life'/work of companies who make BILLIONS a YEAR, easier. (I'll leave my moral objections to several of those aside this time) Cheers, Diederik PS: Nothing in here should be taken as a personal attack, but as I said I feel rather strongly about this subject. (And communication isn't my strong suit) signature.asc Description: This is a digitally signed message part.
Re: Reducing allowed Vcs for packaging?
[please CC me in replies as I'm not subscribed to d-devel] Russ Allbery wrote: > Diederik de Haas writes: > > Question as I don't know: is that only the package change that gets > > uploaded to the Debian archive, or is there also a place where the (git) > > history of the changes leading up to a new upload gets stored? > > dgit maintains a history of every package in Debian. If you use dgit to > make your upload, that will include the full Git history of the changes, > regardless of where you store your Git repository. If you don't, then it > only has the uploads to work with, so each package upload is a new commit > and the detailed breakdown of the work between those uploads is not > available via dgit. > > But it does provide at least upload-level granularity as a Git history for > every package, even those maintained with no version control system at > all, with the option for each package maintainer of opting into providing > more. I'm not new to git or Debian, but I have ~0 experience with packaging (and I want to change that with id3lib). Therefor I don't have (much) experience with the packaging tools (in general). But AFAIK the Debian Xen Team does use dgit (not surprising given dgit's maintainer (and author?)) ... and that drives me insane. I'm very sure that is due to me not understanding the concepts/idea/etc, but I can't wrap my head around it and it feels *to me* like it constantly rewrites the (git) history and then does a `git push -f` ... every time. I once referenced a patch by number (and a short description iirc) and on the next push, that patch had a different number, thus messing up my commit msg. The most confusing thing for/to me is that it completely rearranges the commit sequence, so I can't follow the changes that happened over time. Right now in https://salsa.debian.org/xen-team/debian-xen/-/commits/master HEAD~30 (and the 2 commits before that) are the most recent (and to me the most relevant), but HEAD~9 was made 8 YEARS ago. I may learn dgit in time, but that'll probably be a (long) while. But as I described in another reply to this thread, the upload-level granularity is mostly useless *to me* as it usually only (tersely) describes the *what*, but not the *why*. signature.asc Description: This is a digitally signed message part.
Re: Reducing allowed Vcs for packaging?
On Sunday, 26 February 2023 22:38:51 CET Adrian Bunk wrote: > On Sun, Feb 26, 2023 at 09:57:34PM +0100, Diederik de Haas wrote: > > On Sunday, 26 February 2023 20:06:26 CET Adrian Bunk wrote: > >... > > > > > For anything in Debian, the package sources in Debian would not > > > disappear when a repository (or salsa) disappears. > > > > Question as I don't know: is that only the package change that gets > > uploaded to the Debian archive, or is there also a place where the (git) > > history of the changes leading up to a new upload gets stored? > > > > To use an analogy: I'd like that not only the 'destination' is preserved, > > but also the lead up to the destination. > > What goes into the Debian archive is based on tarballs and quilt patches. > Nothing is stored there except the files you upload. Thanks, I thought/'feared' so. > But what do you expect to get from the git history? > > There is no requirement that any history in addition to what is in > the Debian archive exists at all, or any guarantee that what is in > some git tree somewhere is actually the same as what is in the > Debian archive. And git history might just be one commit per upload. > > I would rather like to see people write useful changelog entries > that will still be useful in 25 years instead of > * New upstream version (Closes: #1234567, #1234568, #1234569, ... > or > * Add R³ > than hoping that git metadata would contain anything more useful > than that for such packages. What you described and what I mostly see on changelog entries is: What was changed. What I rarely see is *why* I'm a big proponent of the following git commit structure, which then automatically becomes the git history: primary commit msg: what has changed secondary commit msg: why that change was made including context, deliberations made during that change/commit and alternative solutions considered and why the committer didn't choose for those. The secondary commit msg can be LONG and I like that as it also shows the author/committer pays attention to such things. The (upstream) kernel commit history is a treasure trove of excellent commit messages. The reason that I'm such a proponent of that is that 3 weeks or 3 months from now, there's a reasonable chance that you (the author/committer) does no longer remember the details of that commit. In 3+ years that will be close to 0. AFAIK actual mind reading does not exist, so someone else surely wouldn't know. I've already encountered several cases where the commit was 10+ years old and the commit msg what "Disable setting X" and looking at the diff, I can see the X was indeed disabled. But nothing more. But now I want to enable setting X. But I have no context to know why that would be a bad idea, or actually a good idea *now*, or what will break as a consequence of my enabling X. All I can do is enable X and keep an eye out for bug reports. I think that's what you want to achieve with 'better' changelogs is something similar. I think the git commits are a better place as it's easier to make finer grained distinctions and it's more directly linked to the changes. FTR: I don't *expect* to see those extended commit messages in those old SVN repos, but I do hope I can at least derive _some_ information from the various commits itself. When I was using my own SVN repo I started doing that and I know that I benefited from that a couple of months later. I should have a backup of that somewhere and I'm quite curious if I restore it (and convert it to git) if I can still construct enough detail/history/context from those commit msgs. (As described in the debian-qa ML post, that repo should be 15+ y/o ?) Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Re: Reducing allowed Vcs for packaging?
On Sunday, 26 February 2023 20:06:26 CET Adrian Bunk wrote: > On Sun, Feb 26, 2023 at 07:25:57PM +0100, Diederik de Haas wrote: > > Apart from me not liking proprietary systems in general and M$ GitHub in > > particular, you also run the risk of things disappearing entirely without > > any notice and without any recourse. > > Perhaps tomorrow some company like Oracle decides to buy GitLab Inc., > and then Oracle GitLab stops the current Freemium business model > effective immediately. That is a concern afaic, but the critical difference for me is that (all) the *data* is on Debian infrastructure. > For anything in Debian, the package sources in Debian would not > disappear when a repository (or salsa) disappears. Question as I don't know: is that only the package change that gets uploaded to the Debian archive, or is there also a place where the (git) history of the changes leading up to a new upload gets stored? To use an analogy: I'd like that not only the 'destination' is preserved, but also the lead up to the destination. signature.asc Description: This is a digitally signed message part.
Re: Reducing allowed Vcs for packaging?
On Sunday, 26 February 2023 17:59:52 CET Bill Allombert wrote: > > During the last weeks I had a look at the Vcs situation in Debian. > > > > For the allowed systems the situation in unstable is the following: > > ... > > svn is used by ~130 packages, many of which point to bad URLs. > > > > We can see: The Vcs wars are over; with git there is a clear winner and in > > my opinion, we should remove the possibility to use most of them for > > package maintenance. It is one additional barrier to get into package > > maintenance and we should remove the barriers that are not necessary. I have something to say about this too, but I'll do it in a P.S. as that's not the main point I want to make ... > People that use e.g. subversion could just remove the Vcs-svn field and > pretend that they do not use any VCS. What does that gain us ? I'm currently working on doing a mass-migration from (old) SVN repos to git. See https://lists.debian.org/debian-qa/2023/01/msg00031.html for details. As for this specific point: that obsolete/non-working (svn) URL are actually useful for me to figure out which need to be converted. > I have sympathy for maintainers that use the same VCS as usptream. I have > sympathy for upstream of a VCS to use that VCS instead of GIT. > > ... Unfortunately some projects I work with did not convert their whole > history to GIT and I find useful that Debian still provide subversion and > mercurial to access older commits (and dead projects history). One response to my debian-qa mail contained this: > use "gbp import-dscs" to recreate some partial history based on > snapshot.debian.org and I would not put any more effort than this. That would probably be easier/faster, but I'm hoping to (indeed) preserve all (or at least as much as possible) of the original packaging commit history. Diederik PS: I would also like that all packaging data is available on Salsa For some it's not available at all (but apparently permitted per Policy §5.6.26), which makes it hard(er then needed) if someone wants to contribute. And in other cases it's contained in an external (proprietary) system like GitHub, which is not under Debian's control. Apart from me not liking proprietary systems in general and M$ GitHub in particular, you also run the risk of things disappearing entirely without any notice and without any recourse. C.I.P. https://github.com/community/community/discussions/48173 where VundleVim (vim plugin manager) disappeared 'out of the blue'. (that vundlevim isn't packaged for Debian is irrelevant) signature.asc Description: This is a digitally signed message part.
Re: Re: /boot partition too small
On Thu, 6 Oct 2022 17:14:56 +0200 Michael Biebl wrote: > Am 06.10.22 um 16:23 schrieb Diederik de Haas: > > That doesn't change my perspective that the fundamental aspect of /boot > > being too small should be addressed (directly) and not try to workaround > > it. > > Agreed. But automatically resizing existing partitions on a running system > will probably not be possible to do in a safe way. > > At least I can't think of a way how this could be done automatically by a > package during a dist-upgrade. I don't think we should even try to fix it. Every affected problem is different and so is the desired solution for that person/device. In this case I think that recommending a fresh install, isn't a bad solution. signature.asc Description: This is a digitally signed message part.
Re: /boot partition too small
On Thursday, 6 October 2022 16:23:27 CEST Diederik de Haas wrote: > That doesn't change my perspective that the fundamental aspect of /boot > being too small should be addressed (directly) and not try to workaround > it. With workarounds I was thinking of using a better compression scheme (already done by switching to zstd) and such things to 'shave off' a 'few' bytes. On Thursday, 6 October 2022 15:41:52 CEST Ben Hutchings wrote: > The kernel team has had some discussion about changing linux-image > packages to not install vmlinuz directly in /boot: > https://lists.debian.org/debian-kernel/2021/11/msg00091.html I should've read those msgs (again) before replying, but the above linked alternative is not a workaround AFAIC (which ~ makes /boot/ irrelevant IIUC). signature.asc Description: This is a digitally signed message part.
Re: /boot partition too small
On Thursday, 6 October 2022 15:41:52 CEST Ben Hutchings wrote: > > my laptop runs with a default partition layout created by Debian > > Installer 4 years or so ago: > > > > Device StartEnd Sectors Size Type > > /dev/nvme0n1p120481050623 1048576 512M EFI System > > /dev/nvme0n1p2 10506241550335499712 244M Linux filesystem > > /dev/nvme0n1p3 1550336 1000214527 998664192 476.2G Linux filesystem > > > > The boot partition is now big enough to contain 2 kernel version, too > > small to contain 3, and too small to purge one and install another > > (somehow a bit more space is needed during install than is used at the > > end) > > The kernel team has had some discussion about changing linux-image > packages to not install vmlinuz directly in /boot ... > > This would potentially allow for smarter management of the available > space in /boot. That sounds like fixing the wrong problem or in the wrong place to me. The EFI partition gets 512MB, while boot gets 244MB? ... On a ~500GB drive? With the RPi images we had a discussion to increase the partition size* from 300MB to 512MB to accommodate several kernels. And that's on a minimal image which is (normally) written to a SD card. And my hesitation came from that people may be using 4 or 8 GB SD cards. Personally I never use the standard partitioning layout as it didn't make sense to me ... and IIRC that was from ~10 years ago. I don't know, but I expect there is some algorithm which determines what sizes the various partitions should get. Maybe that needs a new look to determine whether it is still the most sensible today? EDIT: I just looked up the thread on debian-devel and saw that d-i already has better defaults. That doesn't change my perspective that the fundamental aspect of /boot being too small should be addressed (directly) and not try to workaround it. *) Technically it's a partition mounted on /boot/firmware, but the kernels get copied into that partition. signature.asc Description: This is a digitally signed message part.
Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio
On 23 February 2022, I wrote this in https://bugs.debian.org/999363#35: On 23 Feb 2022 17:21:29 +0100 Diederik de Haas wrote: > On 10 Nov 2021 15:40:21 +0100 Sebastien Bacher wrote: > > Switching the default sound service is an option but should probably be > > a project discussion and not a consequence of a dependency tweak. > > Is that discussion taking place somewhere? If so, where? > If not, then shouldn't that discussion start ASAP? > > The discussion itself will likely take some time and if the decision is made > to do the switch, then it could very well be that various upstream changes > should take place (where it hasn't already) and then also Debian packages > need to be updated. > > I don't know exactly when the Freeze for Bookworm is scheduled, but assuming > a 2 year release cycle, we now have ~ a year to make that switch happen and > suitable for a Stable release. > If we wait another 6 months or so, it'll become really problematic and we'd > have to carry the technical debt likely into Trixie. I thought ~ a YEAR to make the transition _should_ be doable. But now that 2/3 of that have passed, I think it would be a mistake to switch the default from PA to PW+WP. On Thu, 26 Aug 2021 11:56:05 +0200 Dylan Aïssi wrote: > The best way to deal with that issue is to update all packages that > Depends, Recommends or Suggests pulseaudio to depend either on > pulseaudio or pipewire-pulse (i.e. pulseaudio | pipewire-pulse). This is from more then a YEAR ago and AFAIK very little work on that has been done. Here are some more 'tidbits' from me: - pipewire-media-session (as session manager) was already deprecated upstream since the beginning of the year. It was already then strongly urged to switch to WirePlumber, but that has still not been done in Debian - I saw several references to Wayland and Gnome. Keep in mind there are other Desktop Environments. Some 'daredevils' are (sometimes) trying Wayland with KDE and IIUC, it'll be a while before anyone can safely switch to using it. - IIUC/IIRC, even the RTKit maintainer doesn't (really) want to touch the code in fear of breaking things. And there were quite a number of issues reported wrt RTKit and PW+WP, last time I looked. IIUC that was one of the reasons for the (new) recommendation to using /etc/limits.conf and the pipewire group - When I told/asked upstream how to use PW+WP in an unattended/headless manner, I got treated like I was insane and/or this was an insane use case. My primary use case was a 'soundserver' device connected to my AVR and one of the services it would run was mpd. In the end it was suggested that a systemd system service may be a way to get that to work (bug #1014927) - Tuning the 'quantum' parameter seems to be considered a normal operation. Guess what. Not everyone is a (professional) sound engineer. I'm pretty sure 95+% of Debian users have no idea what that is. I certainly don't. And I've spend quite a bit of time to figure out how to make PW+WP work and eventually just bailed out. I'm sure things have improved since, but at the beginning of the year I wasn't impressed. I think there currently aren't that many Debian users which do use PW and I think that switching the default audio provider in all of Debian (not just Gnome) is FAR more involved then the impression I got from this ML thread. I expect PW+WP to be the future and in several cases it is already superior then the alternatives. And I think a small minority of Debian users need that. I think this is a switch that should be done at the beginning of the Trixie development cycle and then there is plenty of time to work out all the kinks which undoubtedly will surface when making the switch. I thought ~ a year was tight, but 4 months is surely too short a timeframe. My 0.02 signature.asc Description: This is a digitally signed message part.
Re: ifupdown/dhcp
On Sunday, 8 May 2022 21:34:39 CEST Michael Tokarev wrote: > What's up with ISC dhclient? "ISC DHCP Client and Relay End of Maintenance" @ https://www.isc.org/blogs/dhcp-client-relay-eom/ Couple of quotes: "ISC plans to end maintenance of the ISC DHCP client and relay by the end of Q1, 2022." Why: "ISC has no support customers for the ISC DHCP client or relay, and we haven’t for at least a decade, so there is no funding stream to support continuing effort on them." What about users: "ISC DHCP has been, and remains, open source. Anyone can fork it and develop or maintain it. Users still have all the open source freedoms with ISC DHCP that they have always had. We are just announcing that ISC will no longer maintain this code." HTH, Diederik signature.asc Description: This is a digitally signed message part.
Re: Download page/options (was: Firmware - what are we going to do about it?)
> My background is as a longtime debian user and support volunteer in #debian. Thanks for doing that! I haven't been on that channel for a while, but I do remember what an incredible help you've been to many there :) Apologies for my harsh wording wrt auto-download. I shouldn't have have put my unfiltered first reaction onto the ML. > I think pabs's suggestion of improving the visibility of that choice on the > website instead [of in d-i] could improve user friendliness Fully agreed. When the user is visiting the DL page/section, they have a working PC (+browser) with a working network connection, which may not be the case within d-i. On a webpage it's also trivial to include hyperlinks to further reading. Here are some other suggestions (hopefully more constructive): I came to the DL page with my Debian machine ... for which I didn't need an installer, but for an other machine which (hypothetically) didn't have it yet. I think having a (prominent) first DL option is great: "Based on the machine you're currently running, we recommend this DL option for you" Below that a button labeled "Help me choose" which will start a 'wizard' to guide the user to select the appropriate download option for their use case. And below that a section "I want to choose myself" which presents the various options for which several suggestions have already been made. Another idea is to have a multi-platform client program like the RPi Imager program which helps the user select the right 'thing' for them and then writes that onto the appropriate device. Maybe this is only useful for SBC's, but could possibly be wider applicable. F.e. https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/ README.concatenateable_images is very clear and easy to do ... for a person like me. But I wouldn't be surprised if it is too complicated for a novice person (especially if also new to Linux). A Debian Imager client program could download the appropriate components, combine them (behind the scene) and writes it to the, by the user selected and in a friendly way presented, medium. HTH, Diederik signature.asc Description: This is a digitally signed message part.
Re: Firmware - what are we going to do about it?
> 3. We could stop pretending that the non-free images are unofficial, and > maybe move them alongside the normal free images so they're published > together. > This would make them easier to find for people that need them, but is > likely to cause users to question why we still make any images without > firmware if they're otherwise identical. > ... > 5. We could split out the non-free firmware packages into a new > non-free-firmware component in the archive, and allow a specific > exception only to allow inclusion of those packages on our official media. > We would then generate only one set of official media, including those > non-free firmware packages. I'd prefer a combination of those 2 + something more ... I'd want 2 sets of images: - One as it is now - One with the the non-free-firmware integrated Curious to see what the current experience would be, I went to debian.org and saw a 'Download' link, which directed me to debian.org/download. First: do not EVER automatically start a download without me explicitly clicking a link to do so. I associate this behavior with malware sites and I expected to be taken to a download page, which would present me with options. (I prefer debian.org/distrib/ to the current 'download' page) Now what I actually wanted to say: On the download page, start by explaining why there are 2 sets of downloads and present both options on that SAME page. (for some reason the idea of 2 columns with Free on the left and Free+non-free-firmware on the right sticks in my head, but others are undoubtedly better in UX design) Make it easy for our users to find the right medium for them while also emphasizing the importance of Free Software (and hopefully Free firmware too). I think making people aware is important. Only then will they hopefully ask more often for Free firmware and/or deliberately choose hardware that is not dependent on non-free things. Make it clear, but not too long. Several 'Read more...' links seem like a good idea. If it is too long, then people will just (immediately) scroll past it, missing its goal. I believe this has the following benefits: - People who only want Free software can still get what they always got - People who need non-free-firmware don't have to keep (a set of) bookmarks to find the installation mediums they need - While acknowledging the unfortunate necessity of non-free-firmware, we also use this opportunity to stress the importance of Free Software (and firmware). This will hopefully create more demand (both wrt purchases as questions to hardware manufacturers) for free(er) things. (I switched from NVidia to AMD GPUs because of AMD's FLOSS drivers) Only shipping images with non-free-firmware would feel *to me* as rewarding people distributing non-free. Just act bad long enough and people, including Debian, will cave. My 0.02 signature.asc Description: This is a digitally signed message part.
Re: An abrupt End to Debian Live
On Monday 09 November 2015 17:47:09 Daniel Baumann wrote: > An abrupt End to Debian Live I am extremely saddened by what happened and I find it disgraceful the way it happened. I feel very proud that Debian Live was one of the first Debian projects I actually made a contribution to and seeing my name in the changelog is really cool. The whole Debian Live community was really welcoming and you really made a difference by guiding me through my first contributions ... apart from this wonderful project you started. So I'd like to say a BIG thank you, Daniel! signature.asc Description: This is a digitally signed message part.
