Re: About i386 support
On Fri, May 17, 2024 at 09:58:58PM +0200, Victor Gamper wrote: > Hello everyone, > Is it correct that debian 13 is planned to be released without > an i386 iso and i386 is planned to be deprecated? > If so, I'd like to ask to reconsider this seeing as there is still a > plethora of i386 machines and i386 is as of now still the > second most used architecture according to popcon with 8437 > reports there, if I understand correctly. > I personally use the i386 version on multiple machines, > including a ThinkPad T60 (on which I'm writing this on) and a > Transmeta Efficeon, which I'm using as a router and access point. > The Transmeta _won't_ do x86_64/amd64 - but is obscure (and rare) hardware at this point. The T60 will do amd64. At this point, any i386-only hardware is well over ten years old. There's no real UEFI support - so legacy MBR. Amything else can do amd64. The law of diminishing returns, the lack of real i386 hardware to test on - at this point, i386 32 bit is effectively dead. Several large packages can't be built natively on i386 - things like firefox and libreoffice really need to be built on amd64 hardware for i386. Pretty much every major Linux distribution is dropping _any_ 32 bit: Debian is trying to support 32 bit on armhf, for example, which is more than Ubuntu and Fedora. In reality, i386 should probably have been dropped early (or at the last minute) for bookworm; some libraries will be kept for compatibility but it's not realistic to maintain i386 for the whole of the trixie lifecycle. > I personally don't understand why you'd want to deprecate i386, > especially if you compare it to other official architectures > (s390, ppc64el and armel have way less reports on popcon. I don't > want to suggest to deprecate any of these architectures, but just > compare the amount of users there). For many tasks an i386 > machine still offers more than enough capabilities and deprecating > i386 now would brick many otherwise completely functional machines. > See above. Popcon isn't really an absolute measure: not everyone enables popcon so there may be very many machines running in server farms or whatever. Very few people have an s390 around: ppc64el similarly and armel is valid for less and less hardware (modulo the Raspberry Pi Zero) _Some_ embedded hardware was sold more recently but it wouldn't necessarily run Debian. > Just not shipping an i386 iso would still be deprecating an architecture, > as many people don't have the knowledge and/or patience to set up > debian over debootstrap which would again practically brick i386 machines > for many users. Also, deprecating i386 would probably make it > difficult or downright impossible for downstream distributions to > themself keep the i386 version maintained, > as they'd have to invest much more effort to keep i386. > If downstream versions _REALLY_ need genuine i386, they also need to ask Debian and step up to maintain. Any Ubuntu derivatives - so second order Debian versions - are already out of support on the latest Ubuntu. > Is there a reason to do this? If so, what would be required to keep > the i386 version, seeing as it still is important and used? > > regards, > Maite Gamper (zeldakatze) > It would need several maintainers to step up and maintain hardware and track upstream libraries, compatibility and a recompile farm. Sorry to be the bearer of bad news but I think that's it in a nutshell. Andy (amaca...@debian.org)
Re: How to create a custom Debian ISO
+debian-live Hello Aditya, On 11/05/2024 10:21, Aditya Garg wrote: I wanted to create a custom ISO of Debian, with the following customisations: 1. I want to add a custom kernel that supports my Hardware. 2. I want to add my own Apt repo which hosts various software packages to support my hardware. I am not able to get any good documentation for the same. Please help. Let me chime in on this thread as well. I had a quick peek at the scripts you use [1]. It appears to me that you want to create a custom Debian Live ISO (not a netinst image). If so, you can take a look at live-build, which is used for the Debian live images. Steps describing how to build a live ISO image are at [2] and a generic manual for live-build is at [3]. You can then build an ISO image from their packages, without the need for repacking (and automagically all checksums will match) With kind regards, Roland Clobus Co-maintainer of live-build [1] https://github.com/t2linux/T2-Ubuntu/tree/LTS [2] https://wiki.debian.org/ReproducibleInstalls/LiveImages [3] https://live-team.pages.debian.net/live-manual/html/live-manual/index.en.html OpenPGP_signature.asc Description: OpenPGP digital signature
Re: About i386 support
Hi Andrew, Release team member hat on On 18-05-2024 12:28 p.m., Andrew M.A. Cater wrote: In reality, i386 should probably have been dropped early (or at the last minute) for bookworm; some libraries will be kept for compatibility but it's not realistic to maintain i386 for the whole of the trixie lifecycle. Please elaborate. We aren't planning to drop i386. If you have more information than I have, we'd like to learn. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: About i386 support
On Sat, 2024-05-18 at 10:28 +, Andrew M.A. Cater wrote: > On Fri, May 17, 2024 at 09:58:58PM +0200, Victor Gamper wrote: > > Hello everyone, > > Is it correct that debian 13 is planned to be released without > > an i386 iso and i386 is planned to be deprecated? > > If so, I'd like to ask to reconsider this seeing as there is still a > > plethora of i386 machines and i386 is as of now still the > > second most used architecture according to popcon with 8437 > > reports there, if I understand correctly. > > I personally use the i386 version on multiple machines, > > including a ThinkPad T60 (on which I'm writing this on) and a > > Transmeta Efficeon, which I'm using as a router and access point. > > > > The Transmeta _won't_ do x86_64/amd64 - but is obscure (and rare) hardware > at this point. > > The T60 will do amd64. [...] According to thinkwiki, the T60 had CPU options of Core Solo/Duo (32- bit) and Core 2 Duo (64-bit) CPUs, so this may or may not be correct. Ben. -- Ben Hutchings Horngren's Observation: Among economists, the real world is often a special case. signature.asc Description: This is a digitally signed message part
Re: About i386 support
Hello, Whilst I can't for sure say how much free time I'll have, I'd like to try and contribute. How would you get started with that? regards, Maite Gamper (zeldakatze) On 18.05.24 03:15, r...@neoquasar.org wrote: That depends. What would be required of such a person? I also have several i386-class machines that run Debian (though only one that can run Debian 12). --J Sent from my mobile device. *From:* Johannes Schauer Marin Rodrigues *Sent:* Friday, May 17, 2024 15:48 *To:* Victor Gamper; debian-devel@lists.debian.org *Subject:* Re: About i386 support Quoting Victor Gamper (2024-05-17 21:58:58) > Is there a reason to do this? If so, what would be required to keep the i386 > version, seeing as it still is important and used? anything can be done if there are enough contributors who care. For i386 there is a severe lack of person-power. Do you want to start contributing your free-time for several years to come to d-i and other areas which are needed to keep i386 more alive for longer? Thanks! cheers, josch
Bug#1071392: ITP: guile-curl -- Guile language bindings for cURL
Package: wnpp Severity: wishlist Owner: Shriram Ravindranathan X-Debbugs-Cc: debian-devel@lists.debian.org, s...@ters.dev * Package name: guile-curl Version : 0.9 Upstream Contact: Mike Gran * URL : https://github.com/spk121/guile-curl * License : GPL-3+ Programming Lang: Guile Description : Guile language bindings for cURL guile-curl allows Guile programs to perform client-side HTTP requests and URL transfers, such as retrieving documents from HTTP or FTP servers. guile-curl leverages libcurl for network operations. guile-curl is utilized in many widely-used Guile libraries, such as GNU Artanis. Packaging this library will help in enhancing Guile support on Debian as it is a dependency for many other Guile libraries.
Bug#1071236: general: keyboard, mouse, and trackpad behave inconsistently; seemingly phantom input device events occur unpredictably
Hi, On Fri, 2024-05-17 at 11:44 +0200, Eduardo Casais wrote: > > Everything works perfectly. After several hours, I have yet to > experience any trouble with keyboard, mouse, or trackpad. With kernel > 6.1.0-21, device input starts going haywire after about about 5 > minutes, > at which point the system gets increasingly unstable, and becomes > unusable after 20-30 minutes. do you have an AMD cpu in your laptop? Then it might be https://bugzilla.kernel.org/show_bug.cgi?id=217718 or a similar bug Please install the linux kernel from bookworm-backports and see if its fixed in there. If it is (and you have an AMD CPU), please reopen this bug and reassign it to the src:linux package. Cheers, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
Hi Bill and Wookey! In a recent long thread on debian-devel you had somewhat negative sentiments towards the usefulness of Salsa. I do see you doing good technical work for Debian and recently a MR from Bill too, so I was thinking that maybe you will change your mind when you read more in-depth arguments. This is my attempt to have you think about Salsa in a new light: On Tue, 9 Apr 2024 at 11:41, Bill Allombert wrote: > Having a repository on salsa or even "packaging team" does not prevent > a lack of maintainer, so this is not relevant. > Without a maintainer, no contribution will be merged in any case. Consider this Merge Request to fix debbugs builds immediately, and to include Salsa-CI to keep the build from regressing again: https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 1. If the package was not on git and Salsa, I would have no way to see what the maintainers have been doing in the years 2018-2023 (Debian repos had last upload in 2018) 2. If the package was not on Salsa, and had the MR feature active, I would not be able to submit a MR to fix the issues. Now the MR is up there, and anybody can review and comment it - thus we are not even dependent on the original maintainers alone. 3. The UI is easy and useful. I invite you to read my MR and add your review. I made have some extra instructions to make this very welcoming for people who do not "like" Salsa/GitLab and might feel that something is unintuitive 4. If you don't want to use the web UI, you can also download my patch https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19.patch and review by email. Or you can click in the UI once to subscribe the MR and then continue review/comments by email. Personally I fully agree with the people stating that "Salsa is the best thing in Debian in the past 20 years". So far everyone I talked to who initially had reservations regarding using Salsa have started liking it after they learned a bit more how it works, and have seen things like Salsa-CI in action saving the Debian archive from needless widespread failures. Thanks, Otto
