Re: Improvement of headless server upgrades
On Wed, Mar 05, 2025 at 10:12:05PM +0100, Matthias Urlichs wrote: On 05.03.25 21:35, Marc Haber wrote: And which of the millions of changes would that be that would break YOUR system? The number of changes that can adversely impact your ability to boot *or* your network connectivity (but which won't fail the upgrade!) can safely be assumed to be smaller than five or so. And which of the millions are those five? Any small number of "false alerts" already will cause users to stop reading. Maybe we could introduce a new header field where a package might create itself as "probably harmful to the reboot" (like grub, initramfs-tools, network-manager, systemd etc) and have their NEWS entries sorted first by apt-listchanges. But I think that it is unrealistic to expect maintainers to classify their changes whether they might affect reboot. Running a headless server without console access is a challenge. You _really_ need to know your way to debug such a situation. I don't think that we as a distribtion can change that. In the current case, it's only a matter of hooking up a display and keyboard to a physically accessible system. It could be a housing server in a datacenter next time (been there, done that). Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: Change the expectation that emails should wrap at 80 characters
Andrey Rakhmatullin writes: > This (as a mild but easy to get example of pre-formatted text): > >> For sake of argument:- If this re-wrapping is purely client side and >> happens after PGP verification, incoming mail could still show as >> verified (but it may look slightly different)- I could toggle this >> on/off per message, so that I can still write inline replies based >> on the original message's formatting There are many other forms of text where we can't merely consider them as paragraphs of prose. For instance, in technical mailing lists, snippets of source code are quite common. Additionally, one may encounter elements like postal addresses or poetry, where (hard) newlines matter for proper formatting. Some individuals still favor the traditional practice of indenting paragraphs rather than the "block paragraph" style that predominates in today's email culture (most likely due to challenges in this exact issue). It is essential to have a method for distinguishing between hard and soft newlines if you want to reflow text properly.
Re: Improvement of headless server upgrades
On Tue, Mar 04, 2025 at 08:39:43PM -0500, Helmut K. C. Tessarek wrote: > This is my first mail in a Debian mailing list and I hope I've chosen the > correct one. There are way too many lists thus please direct me to the > correct one, in case I messed up. As the matter is intersecting multiple packages, it isn't the worst choice. > In the last few days I ran into a serious issue when upgrading to newer > releases on 3 headless servers: the network connection went dead. > In the first situation the interface name changed from eth0 to end0 and > after the reboot my adapter got a link-local address. I am surprised to see this happen. Back in older times, interfaces used to be named like eth0, but that should not be happening since quite a number of stable releases. Those old systems that still use eth0 today tend to do it due to a file /etc/udev/rules.d/70-persistent-net.rules. Does that exist and list your interface on the affected system? If not, can you try figuring out why it was still named eth0 before upgrading? In principle, I expect that this is an unusual circumstance and therefore do not think it is worth mitigating. > In the second situation dhcpcd was replaced by Network Manager and once > again the network was dead. Can you try figuring out what dependency caused Network Manager to be installed? Your apt or dpkg logs may be helpful here. > Both network "outages" could have been prevented by adding a note at the end > of the dist-upgrade output. There are two difficulties in this proposal. One is finding a responsible package for printing this note and the other is properly detecting the changed network interface name before doing the reboot that actually changes it. As a result of these, I suggest investing time into making the described situations less likely rather than printing a warning. Helmut
Re: Change the expectation that emails should wrap at 80 characters
Hi all, On 2025-02-26 10:21, Soren Stoutner wrote: I started thinking about this a few weeks ago when I received an email from a Debian Developer complaining that replies from my email client (KMail) looked odd because they truncated quoted lines in a way that did not lay out pleasingly. This was because I had set KMail to wrap lines at 80 characters. I see this too with a lot of ML posts - mails are wrapped in a way such that the text only takes up a third of my monitor. This is one of those things where the more I notice it, the more it annoys me :/ However, from a technical perspective, having the *sending* program decide where line breaks should be in an email doesn’t seem like the correct approach to me because, 1) the sending program does not know the screen width of the receiving program, and 2) there is large variability in the screen width of receiving devices, including cell phones who are often less than 80 characters wide. There's plenty of discussion about format=flowed elsewhere in this thread, but unfortunately it never caught on. This got me thinking though: why do email clients *have* to show hard-wrapped text as-is? If I were to write, say, a Thunderbird extension that forcibly unwraps text I receive, regardless of whether format=flowed was specified, what would be the implication? For sake of argument: - If this re-wrapping is purely client side and happens after PGP verification, incoming mail could still show as verified (but it may look slightly different) - I could toggle this on/off per message, so that I can still write inline replies based on the original message's formatting Hacking this in on the client-side won't fix display issues for anyone else, but it wouldn't break other workflows either. -- Soren Stoutner so...@debian.org Best, James
Re: Bug#397761: Bug reports for Uploaders (was: Re #397761: bugs.debian.org: please forward bug reports to Uploaders also)
On Mon, 03 Mar 2025, Blair Noctis wrote:n > Dan Armstrong (don) wontfix'd it after stating that, quote: > > If the maintainer is not given as a mailing list, then the uploaders > > should all subscribe to the PTS for a given package. > > and > > > The problem is that if I start sending mails to Uploaders: in addition > > to the Maintainer, there is no way to opt out of it. > > > > It's far easier to subscribe to the pts and unsubscribe if Maintainer > > is not a list. [It should at least be an address that goes to a real > > person.] This is still correct. Because the way subscriptions in debbugs is implemented isn't complete, there's no way to allow people to opt in or opt out of messages both for submitters, uploaders, or random bystanders. The PTS solves this to some degree, but actually fixing this correctly requires a level of code change to the current version of debbugs which isn't likely to happen any time soon. [This is a design issue which I hope to eventually address, but my track record here is really bad.] -- Don Armstrong https://www.donarmstrong.com Personally, I think my choice in the mostest-superlative-computer wars has to be the HP-48 series of calculators. They'll run almost anything. And if they can't, while I'll just plug a Linux box into the serial port and load up the HP-48 VT-100 emulator. -- Jeff Dege, jd...@winternet.com
Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL)
Hi Sean and everybody, Around 12 years ago, I proposed a peer-review system to increase the quality of the packages in the NEW queue. https://wiki.debian.org/CopyrightReview Maybe we could revisit the idea along these lines: - a Salsa group into which people fork repos and run CI screens for copyright, license and missing source issues. - a peer-review system based on issues or MRs (for instance to a master repository with a text file tracing the outcome of the reviews). - as of today people would use it to ensure their submissions to NEW are to the highest standards and therefore the least likely to waste time of the FTP team members. - the outcome of the NEW processing of the peer review is also recorded by volunteers, allowing to better measure the achievements and usefulness of the system. - The FTP team, if they wish, can provide feedback. - when the FTP team calls for new trainees, applicants who have a track record of peer reviews in that system can show it to the FTP team, who are free to do what they want with this information. - If the FTP team recruits someobody who was peer reviewer and liked that system, a positive loop is made. Have a nice day, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from home https://framapiaf.org/@charles_plessy - You do not have my permission to use this email to train an AI -
Re: Bits from DPL
Hello, On Wed 05 Mar 2025 at 11:35pm +0530, Nilesh Patra wrote: > Do you mind clarifying why that's the case, unless the reason is truly > personal or undisclosable? It's pretty simple -- there is no-one with the free time to train them right now, in which case trainees will simply burn out, because they won't get enough feedback on their NEW reviews. We try to recruit only when there is someone who is able to dedicate some time to training. That depends on what the other team members are busy with, in and outside of Debian, at a given time. This was made very clear to Andreas. -- Sean Whitton signature.asc Description: PGP signature
Re: Proposal for a Yearly Stable Release Cycle for Educational Institutions
Sarbjit Singh Sandhu writes: > I am writing to propose the creation of a new Debian branch that > offers a stable release every year, as opposed to the current 5-year > cycle. It's really great to see young people interested in Debian. I do need to point out that the current cycle has been approximately 2 years long for quite a while, not 5. Best, Gard signature.asc Description: PGP signature
Re: Proposal for a Yearly Stable Release Cycle for Educational Institutions
Am Mittwoch, dem 05.03.2025 um 09:14 +0100 schrieb Gard Spreemann: > I do need to point out that the current cycle has been approximately > 2 years long for quite a while, not 5. That is technically correct, but the freeze period is quite long as well. As a result, the software is significantly older. For example, the Bookworm freeze started in January 2023, so the desktop apps are based on the Gnome release of September 2022. When Trixie will be released, the apps in Bookworm will be almost three years old. This is where average users feel the age. Ubuntu schedules its LTS release always for April (normal releases October), because Gnome is always releasing in March and September. So for Ubuntu LTS users, the age of desktop apps is up to two years. Fortunately, the Debian Gnome team has already included the current release candidate (scheduled for March 19, 2025) for Trixie. Regards signature.asc Description: This is a digitally signed message part
Re: Bits from DPL
unsubsribe Sean Whitton ezt írta (időpont: 2025. márc. 5., Sze, 12:17): > Hello everyone, > > On Tue 04 Mar 2025 at 09:40am +01, Andreas Tille wrote: > > > Dear Debian community, > > > > this is bits from DPL for February. > > > > > > Ftpmaster team is seeking for new team members > > == > > No, we are not. > > Andreas asked us whether we would like a call for volunteers included in > Bits. Multiple team members explicitly told him that we now would not > be a good time for that, for us. > > For the FTP team, > -- > Sean Whitton > -- Jecs Attila Power Alarm Kft.
Bug#1099584: ITP: rocm-docs-core -- ROCm Documentation Core Utilities
Package: wnpp Severity: wishlist Owner: Christian Bayle X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: rocm-docs-core Version : v1.17.1 Upstream Contact: Advanced Micro Devices, Inc. * URL : https://github.com/ROCm/rocm-docs-core * License : Creative Commons Attribution 4.0 International Public License Programming Lang: (CSS, Python, HTML, Jinja, JvaScript) Description : ROCm Documentation Core Utilities This repository is comprised of utilities, styling, scripts, and additional HTML content that is common to all ROCm project's documentation. This greatly aids in maintaining the documentation, as any change to the appearance only needs to be modified in one location.
Growing new FTP-masters (Re: Bits from DPL)
Hi, On Wed, 5 Mar 2025 at 10:24, Nilesh Patra wrote: > On 05/03/25 4:47 pm, Sean Whitton wrote: > > On Tue 04 Mar 2025 at 09:40am +01, Andreas Tille wrote: > > > >> Dear Debian community, > >> > >> this is bits from DPL for February. > >> > >> > >> Ftpmaster team is seeking for new team members > >> == > > > > No, we are not. > > > > Andreas asked us whether we would like a call for volunteers included in > > Bits. Multiple team members explicitly told him that we now would not > > be a good time for that, for us. > > Do you mind clarifying why that's the case, unless the reason is truly > personal or undisclosable? +1 According to https://ftp-master.debian.org/ there are currently no 'FTP Trainees'. I would assume you would like to have some at all time to ensure the team has a healthy pipeline of new members being trained? Looking at the stats for NEW queue length in https://ftp-master.debian.org/stat/new-5years.png it seems to have been the highest ever in November 2024 to January 2025, and the numbers didn't come down until heroic efforts by mainly one person (Thorsten). Many of the aspiring Debian Developers I mentor have been stuck with their work pending in the NEW queue for months. For example an upload of src:godot to change source package name to src:godot3 with almost no other changes has been pending almost two months, and the new contributor Travis Wrightsman has been mostly idle with his Debian work just waiting for the package to pass in order to proceed with new Godot version. With this experience I am surprised that one FTP-team member is saying that no help is needed? I wonder if that really is the opinion of others in the team too? - Otto
Re: Bits from DPL
On Wed, Mar 5, 2025 at 12:52 PM Sean Whitton wrote: > > Hello everyone, > > On Tue 04 Mar 2025 at 09:40am +01, Andreas Tille wrote: > > > Dear Debian community, > > > > this is bits from DPL for February. > > > > > > Ftpmaster team is seeking for new team members > > == > > No, we are not. > > Andreas asked us whether we would like a call for volunteers included in > Bits. Multiple team members explicitly told him that we now would not > be a good time for that, for us. > > For the FTP team, > -- > Sean Whitton Regarding this, when would be a good time? I always see the new queue full of packages for approval by your team and we are grateful when they approve the packages quickly. But at the moment there are no FTP Trainees and wouldn't it be interesting to call them (whoever is interested, of course)? [1] https://ftp-master.debian.org/ -- Cheers, Leandro Cunha
Re: Change the expectation that emails should wrap at 80 characters
Hi! > Given the above four points, I propose the line from the code of conduct > quoted above be changed to read: > > “There is no expectation that emails sent to the mailing lists are wrapped by > the sender at a particular column, but those sending emails may wrap them if > they choose.” > > I like this wording because it does not prevent people from wrapping their > emails if they want. Although I think the superior options for the entire > ecosystem would be that no emails are wrapped by the sender, I can imagine > there are users who need to interact with other ecosystems which require > wrapped emails, and forcing them to switch their settings back and forth when > communicating with Debian would be inconsiderate. > > Therefore, I feel the above wording is fair for everyone. I think this a reasonable suggestion by Soren. Alternatively, Charles suggestion to completely remove mentions of line wrapping requirement from the "Code of conduct" section at https://www.debian.org/MailingLists/ would also work. All those docs and web pages are read by new people interested in contributing to Debian, and I am glad to see people reviewing, updating and cleaning them up. This thread about line wrapping also shows that there are many with two or more decades of experience in Debian, who have over the years formed their own highly optimized workflows and email client and text editor settings which diverge from what "mainstream" today considers easy or optimal. I am hugely grateful for people who have contributed to Debian for decades and I hope to see them continue to contribute for decades to come. At the same time I wonder how we can narrow the evident cultural gap between the Mutt user generation and newer web email generation users, which also manifests in other areas of workflow preferences as we have seen in discussions about email vs web interface for bug reports.
Re: Proposal for a Yearly Stable Release Cycle for Educational Institutions
Am Mittwoch, dem 05.03.2025 um 14:38 + schrieb Jeremy Stanley: > There's also a several-month freeze after taking a snapshot of > packages from sid before the release occurs, so when an Ubuntu LTS > release happens the contemporary age of packages in the prior LTS is > well over two years by then. No. In Ubuntu's freeze, they already include the beta/rc of the upcoming Gnome, regardless of what is in Sid. For example, Ubuntu 24.04 has Gnome 46, which was released in March 2024. There have been few exceptions in the past when they did not want to introduce too big changes in LTS, e.g. Wayland/Unity related stuff. Regards signature.asc Description: This is a digitally signed message part
Re: Improvement of headless server upgrades
On Tue, 4 Mar 2025 20:39:43 -0500, "Helmut K. C. Tessarek" wrote: >Both network "outages" could have been prevented by adding a note at the >end of the dist-upgrade output. > >e.g. something like the following (monospace font required for the >"Attention" text): > > _ _ _ _ _ _ _ ___ ___ _ _ >/ \|_ _|_ _| | \ | |_ _|_ _/ _ \| \ | | > / _ \ | | | | | _| | \| | | | | | | | | \| | > / ___ \| | | | | |___| |\ | | | | | |_| | |\ | >/_/ \_\_| |_| |_|_| \_| |_| |___\___/|_| \_| > >Network interface name changed: please update config files before reboot. Why would people who do not read the NEWS.Debian or the Release Notes read that? And how would you solve the issue of people wanting more and more of those attention banners? Greetings Marc -- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Bug#1099603: ITP: python-atom -- Memory efficient Python objects
Package: wnpp Severity: wishlist Owner: Alexander Sulfrian X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-atom Version : 0.11.0 Upstream Contact: Matthieu C. Dartiailh * URL : https://github.com/nucleic/atom * License : BSD-3-clause Programming Lang: Python Description : Memory efficient Python objects Atom is a framework for creating memory efficient Python objects with enhanced features such as dynamic initialization, validation, and change notification for object attributes. It provides the default model binding behaviour for the "Enaml" UI framework, that is a dependency for InkCut which I also intend to package. I plan to maintain this package as part of the Debian Python team.
Re: Change the expectation that emails should wrap at 80 characters
On Tue Mar 4, 2025 at 7:52 PM GMT, Soren Stoutner wrote: This is an interesting question based on a presumption that I didn’t know was possible. In a plain text email, is it possible to indicate that certain lines are not wrappable? Yes. That's exactly what format=flowed does. Line ends in space? Wrappable. Line doesn't? Not wrappable. For example, on my cell phone I use Thunderbird as my MUA. In portrait mode on my device text wraps at about 40 columns. Are you saying that you can send a plain text email in such a way that Thunderbird or any other MUA on a cell phone will force scrolling left and right to read the lines instead of having the MUA wrap them at the edge of the screen? Force, no. Thunderbird on Android might choose to wrap lines that are not marked as wrappable. As a sender, the best I can do is advise. -- Please do not CC me for listmail. 👱🏻 Jonathan Dowland ✎j...@debian.org 🔗 https://jmtd.net
Bug#1099615: ITP: gitlab-buildpkg-tools -- Build a Gitlab-PPA using GitLab CI
Package: wnpp Severity: wishlist Owner: Christian Bayle X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: gitlab-buildpkg-tools Version : no versionning Upstream Contact: Christian Bayle * URL : https://gitlab.com/Orange-OpenSource/gitlab-buildpkg-tools * License : (GPL-2) Programming Lang: (Bash) Description : Build a Gitlab-PPA using GitLab CI Gitlab-buildpkg-tools is a set of tools to build a "Gitlab-PPA" using GitLab CI, with automatic package rebuild triggered by a push/merge on a branch of your own repository. After a simple configuration step on your own Gitlab-hosted project, whenever you push on master, a pipeline is triggered which distributes the build of packages on docker images that use the present tools. Then, the artefacts produced are collected, signed, and hosted on the Gitlab- Pages of your project under a structure usable remotely by APT or YUM. Currently, the tools produce .deb and .rpm packages for the following systems: Debian: jessie, stretch, buster, bullseye, bookworm Ubuntu: trusty, xenial, bionic, focal, jammy, kinetic, lunar Centos: 6, 7, 8 Fedora: 24, 25, 26, 27, 28, 29, 30 Rockylinux: 8, 9 I am one of the Upstream of this package
Re: Improvement of headless server upgrades
On 05.03.25 17:16, Bjørn Mork wrote: apt install apt-listchanges To be fair, apt-listchanges lists a whole lot of changes, esp. when you do a dist-upgrade. Noticing the one change among the umpteen more-or-less-major NEWS entries that actually affects the ability of your system to safely reboot with the same network configuration is not a trivial task, even for reasonably experienced sysadmins. -- -- regards -- -- Matthias Urlichs OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Change the expectation that emails should wrap at 80 characters
On 2025-03-05 16:17:20 + (+), Jonathan Dowland wrote: On Tue Mar 4, 2025 at 7:52 PM GMT, Soren Stoutner wrote: > This is an interesting question based on a presumption that I didn’t > know was possible. In a plain text email, is it possible to > indicate that certain lines are not wrappable? Yes. That's exactly what format=flowed does. Line ends in space? Wrappable. Line doesn't? Not wrappable. [...] Semantics maybe, but that's not how I interpret the format=flowed spec (or perhaps the question). Having a space at the end of a line indicates the line has been soft-wrapped by the sender, so from the reader's perspective the line should be logically (re)combined with the line following it. That doesn't exactly say whether or not a line *can* be wrapped, but rather that it was preemptively soft-wrapped and so can be automatically "unwrapped" or "rewrapped" after concatenating subsequent lines. Absence of a space at the line end doesn't say not to wrap that line, but merely not to combine it with the line that follows. The line itself can still be wrapped as needed if it exceeds the client's preferred length. -- Jeremy Stanley signature.asc Description: PGP signature
Re: Bits from DPL
On 05/03/25 4:47 pm, Sean Whitton wrote: > On Tue 04 Mar 2025 at 09:40am +01, Andreas Tille wrote: > >> Dear Debian community, >> >> this is bits from DPL for February. >> >> >> Ftpmaster team is seeking for new team members >> == > > No, we are not. > > Andreas asked us whether we would like a call for volunteers included in > Bits. Multiple team members explicitly told him that we now would not > be a good time for that, for us. Do you mind clarifying why that's the case, unless the reason is truly personal or undisclosable?
Re: Change the expectation that emails should wrap at 80 characters
On Wed, Mar 5, 2025 at 4:06 PM Otto Kekäläinen wrote: > > Hi! > > > Given the above four points, I propose the line from the code of conduct > > quoted above be changed to read: > > > > “There is no expectation that emails sent to the mailing lists are wrapped > > by the sender at a particular column, but those sending emails may wrap > > them if they choose.” > > > > I like this wording because it does not prevent people from wrapping their > > emails if they want. Although I think the superior options for the entire > > ecosystem would be that no emails are wrapped by the sender, I can imagine > > there are users who need to interact with other ecosystems which require > > wrapped emails, and forcing them to switch their settings back and forth > > when communicating with Debian would be inconsiderate. > > > > Therefore, I feel the above wording is fair for everyone. > > I think this a reasonable suggestion by Soren. Alternatively, Charles > suggestion to completely remove mentions of line wrapping requirement > from the "Code of conduct" section at > https://www.debian.org/MailingLists/ would also work. > > All those docs and web pages are read by new people interested in > contributing to Debian, and I am glad to see people reviewing, > updating and cleaning them up. > > This thread about line wrapping also shows that there are many with > two or more decades of experience in Debian, who have over the years > formed their own highly optimized workflows and email client and text > editor settings which diverge from what "mainstream" today considers > easy or optimal. I am hugely grateful for people who have contributed > to Debian for decades and I hope to see them continue to contribute > for decades to come. At the same time I wonder how we can narrow the > evident cultural gap between the Mutt user generation and newer web > email generation users, which also manifests in other areas of > workflow preferences as we have seen in discussions about email vs web > interface for bug reports. > Accordingly! :) -- Cheers, Leandro Cunha
useful subjects in replies to Bits mails (was Re: Bits from DPL)
I genuinely love that there is engagement with Andreas's "Bits from the DPL" mails, but, it would be lovely if people adjusted the Subject so we can differentiate sub-topics from each other. -- Please do not CC me for listmail. 👱🏻 Jonathan Dowland ✎j...@debian.org 🔗 https://jmtd.net
Re: Improvement of headless server upgrades
Hi, On Wed, Mar 05, 2025 at 04:06:56PM +0100, Marc Haber wrote: > On Tue, 4 Mar 2025 20:39:43 -0500, "Helmut K. C. Tessarek" > wrote: > >Both network "outages" could have been prevented by adding a note at the > >end of the dist-upgrade output. > > > >e.g. something like the following (monospace font required for the > >"Attention" text): > > > > _ _ _ _ _ _ _ ___ ___ _ _ > >/ \|_ _|_ _| | \ | |_ _|_ _/ _ \| \ | | > > / _ \ | | | | | _| | \| | | | | | | | | \| | > > / ___ \| | | | | |___| |\ | | | | | |_| | |\ | > >/_/ \_\_| |_| |_|_| \_| |_| |___\___/|_| \_| > > > >Network interface name changed: please update config files before reboot. > > Why would people who do not read the NEWS.Debian or the Release Notes > read that? And how would you solve the issue of people wanting more > and more of those attention banners? Presumably because it will be written directly to their terminal. Things in NEWS.Debian or the release notes probably only can caution users to be aware of possible problems; if we are able to detect that there will be a problem and warn the person running the command, that sounds sensible to me, but I have not looked at the details. Michael
Re: Improvement of headless server upgrades
Il 05/03/2025 02:39, Helmut K. C. Tessarek ha scritto: This is my first mail in a Debian mailing list and I hope I've chosen the correct one. There are way too many lists thus please direct me to the correct one, in case I messed up. I would like to make a suggestion for release upgrades. It should not be a huge effort to implement and I can work with someone to make this happen. In the last few days I ran into a serious issue when upgrading to newer releases on 3 headless servers: the network connection went dead. In the first situation the interface name changed from eth0 to end0 and after the reboot my adapter got a link-local address. In the second situation dhcpcd was replaced by Network Manager and once again the network was dead. Hi, when you do upgrade to a new major version you should before read release note for important changes, also read NEWS on packages upgrade (that contain important changes, including the one that can require manual changes). It is also good to test upgrade on a test server or on a minor one for the first time on any major version upgrade, so you can spot other possible unforeseen events. These network changes are documented and well known, I have done many Debian server upgrades over the years and for example those network changes I had seen before by documenting myself and I had made sure to modify correctly before the upgrade and reboot to avoid unexpected events. Alternatively you can also modify to force the old names. Please don't get me wrong, I am not against keeping up with the times and use new technology. Far from it. But in both cases I had to connect my headless machines to a monitor and keyboard and fix the network issues. Usually this is not a problem, but sometimes it might be impossible. In both cases I did not even know that these things would happen. The dist-upgrade made the changes without my input and I was left in the dark. Iamgine my surprise when I couldn't connect to my boxes anymore. Both network "outages" could have been prevented by adding a note at the end of the dist-upgrade output. e.g. something like the following (monospace font required for the "Attention" text): _ _ _ _ _ _ _ ___ ___ _ _ / \|_ _|_ _| | \ | |_ _|_ _/ _ \| \ | | / _ \ | | | | | _| | \| | | | | | | | | \| | / ___ \| | | | | |___| |\ | | | | | |_| | |\ | /_/ \_\_| |_| |_|_| \_| |_| |___\___/|_| \_| Network interface name changed: please update config files before reboot. _ _ _ _ _ _ _ ___ ___ _ _ / \|_ _|_ _| | \ | |_ _|_ _/ _ \| \ | | / _ \ | | | | | _| | \| | | | | | | | | \| | / ___ \| | | | | |___| |\ | | | | | |_| | |\ | /_/ \_\_| |_| |_|_| \_| |_| |___\___/|_| \_| Network subsystem changed: please add a system connection before reboot. Is this something that makes sense? Often you have a remote console like an iLO or whatever cloud systems provide. But in some cases there is nothing. No console, no monitor, no keyboard. Only a power and a network cable. Cheers, K. C. P.S.: I go by KC, trying to avoid the Spaceballs Dark Helmet mixup. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1099600: ITP: play.it-strategy -- ./play.it game scripts collection - Strategy games
Package: wnpp Severity: wishlist Owner: Antoine Le Gonidec X-Debbugs-Cc: debian-devel@lists.debian.org, debian-devel-ga...@lists.debian.org * Package name: play.it-strategy Version : no release yet, we will trigger one soon Upstream Contact: Antoine Le Gonidec * URL : https://git.dotslashplay.it/games-strategy/about/ * License : BSD-2-Clause Programming Lang: Shell Description : ./play.it game scripts collection - Strategy games ./play.it is a free software building native packages from installers for Windows or Linux, mainly those sold by stores focusing on DRM-free games distribution. The goal is that a game installed via ./play.it is indistinguishable from a game installed via the official repositories of your favourite distribution. ./play.it is already packaged in Debian, cf. https://tracker.debian.org/pkg/play.it This specific collection includes only strategy games. These games rely on long-term planning. They often include military troops management, but can be more peaceful with a focus on resource gathering and logistics. Both turn-based and real-time games are included. This games collection is a recent upstream addition, that took over the maintenance of strategy games from the community-maintained games collection (packaged as play.it-community in Debian). So with the next update of play.it-community, support for many games would be lost. Adding support for this games collection as play.it-strategy before updating play.it-community would ensure support for no game ends up temporarily unavailable. As both the upstream of ./play.it and maintainer of the current Debian-provided packages, I plan to maintain this one under the Games Team umbrella.
Re: Proposal for a Yearly Stable Release Cycle for Educational Institutions
On 2025-03-05 10:40:38 + (+), Stephan Verbücheln wrote: [...] Ubuntu schedules its LTS release always for April (normal releases October), because Gnome is always releasing in March and September. So for Ubuntu LTS users, the age of desktop apps is up to two years. [...] Not really. The LTS releases are in April of even-numbered years. The April releases in odd-numbered years are short-term support just like October releases. There's also a several-month freeze after taking a snapshot of packages from sid before the release occurs, so when an Ubuntu LTS release happens the contemporary age of packages in the prior LTS is well over two years by then. -- Jeremy Stanley signature.asc Description: PGP signature
Re: Bug reports for Uploaders (was: Re #397761: bugs.debian.org: please forward bug reports to Uploaders also)
On Sun, Mar 2, 2025 at 12:07 PM Blair Noctis wrote: > (I'm also confused by the fact that follow-ups to bug reports aren't > forwarded to submitters by default, but the submitter must X-Debbugs-Cc > themselves, but then which is basically the default behavior of reportbug(1) > now IIRC, but that's for another time.) X-Debbugs-CC does not forward replies to bug reports. People replying to bug reports need to explicitly CC the bug submitter or hope that the bug submitter is already subscribed because it is a package they maintain. The workflow to manually subscribe to individual bugs is tedious enough that I only do it occasionally for bugs I am interested in, usually where I am not the bug submitter. Thank you, Jeremy Bícha
Re: Improvement of headless server upgrades
Michael Banck writes: > On Wed, Mar 05, 2025 at 04:06:56PM +0100, Marc Haber wrote: >> On Tue, 4 Mar 2025 20:39:43 -0500, "Helmut K. C. Tessarek" >> wrote: >> >Both network "outages" could have been prevented by adding a note at the >> >end of the dist-upgrade output. >> > >> >e.g. something like the following (monospace font required for the >> >"Attention" text): >> > >> > _ _ _ _ _ _ _ ___ ___ _ _ >> >/ \|_ _|_ _| | \ | |_ _|_ _/ _ \| \ | | >> > / _ \ | | | | | _| | \| | | | | | | | | \| | >> > / ___ \| | | | | |___| |\ | | | | | |_| | |\ | >> >/_/ \_\_| |_| |_|_| \_| |_| |___\___/|_| \_| >> > >> >Network interface name changed: please update config files before reboot. >> >> Why would people who do not read the NEWS.Debian or the Release Notes >> read that? And how would you solve the issue of people wanting more >> and more of those attention banners? > > Presumably because it will be written directly to their terminal. apt install apt-listchanges Bjørn
Re: Improvement of headless server upgrades
On Wed, Mar 05, 2025 at 06:29:26PM +0100, Matthias Urlichs wrote: Noticing the one change among the umpteen more-or-less-major NEWS entries that actually affects the ability of your system to safely reboot with the same network configuration is not a trivial task, even for reasonably experienced sysadmins. It is also a challenge for a package maintainer to judge WHEN to drop a higher priority NEWS entry. I think that our release notes recommend one or another way for console access for upgrades for exactly this reason. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: Improvement of headless server upgrades
On 2025-03-05 12:29, Matthias Urlichs wrote: Noticing the one change among the umpteen more-or-less-major NEWS entries that actually affects the ability of your system to safely reboot with the same network configuration is not a trivial task, even for reasonably experienced sysadmins. I couldn't agree more. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Improvement of headless server upgrades
Hello, Thaank you for all the replies so far. On 2025-03-05 10:15, Michael Banck wrote: Presumably because it will be written directly to their terminal. Yes, this is one of the reasons. During a dist-upgrade you receive the changes, but it's many, many pages long and spotting the entry that renders your system dead is not easy. I am not asking to create multiple ATTENTION banners at the end. All issues can be fixed as long as I can connect to the machine. Thus anything that would prevent the machine from booting (e.g. if it's known that the machine would not boot unless a grub-install is done) or having a functioning network connection, should be mentioned explicitly at the end. The subject specifically points out an improvement for headless server upgrades. Chances are that these "special" notifications only happen now and then. But it would certainly make the upgrade experience better. Cheers, K. C. P.S.: I admit that reading NEWS/UPGRADE files and articles is also important and that doing test migrations is best practices. On the other hand, it's not always possible to have a test bed for every single setup. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Improvement of headless server upgrades
On Wednesday, March 5, 2025 12:34:27 PM MST Marc Haber wrote: > On Wed, Mar 05, 2025 at 06:29:26PM +0100, Matthias Urlichs wrote: > >Noticing the one change among the umpteen more-or-less-major NEWS > >entries that actually affects the ability of your system to safely > >reboot with the same network configuration is not a trivial task, even > >for reasonably experienced sysadmins. > > It is also a challenge for a package maintainer to judge WHEN to drop > a higher priority NEWS entry. > > I think that our release notes recommend one or another way for console > access for upgrades for exactly this reason. I would not be opposed to some type of special warning that an upgrade would break remote access on a particular machine if it were possible to produce the warning reliably, but I don't think it would be that easy to implement. Sometimes it might be easy to detect, but I think a lot of times it isn't easy for Debian to know when the change will cause breakage or not, and if people become dependent on these warnings instead of actually reading the release notes and the NEWS entries, then I can see this causing more problems than it solves. If you are doing an upgrade on a remote or headless system, it probably behooves your time to read over the release notes and the NEWS entries to understand how changes may affect your connectivity. As a human you are much more likely to know if the change will break remote access than any automated check Debian can produce. Now, if any of the breakages being discussed were not sufficiently documented in the release notes or NEWS entries, that is a different issue and one which should probably be addressed directly to the package that made the breaking change. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#1099623: ITP: python-pegen -- CPython's PEG parser generator
Package: wnpp Severity: wishlist Owner: Alexander Sulfrian X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-pegen Version : 0.3.0 Upstream Contact: Matthieu C. Dartiailh * URL : https://github.com/we-like-parsers/pegen * License : MIT Programming Lang: Python Description : CPython's PEG parser generator Pegen is the parser generator used in CPython to produce the parser used by the interpreter. It allows one to produce PEG parsers from a description of a formal Grammar. Pegen exists to distribute a version of the Python PEG parser generator used by CPython that can be installed as package, with some improvements. Although the official PEG generator included in CPython can generate both Python and C code, this distribution of the generator only allows one to generate Python code. This is due to the fact that the C code generated by the generator included in CPython includes a lot of implementation details and private headers that are not available for general usage. This is a dependency for the "Enaml" UI framework, which is a dependency for InkCut which I also intend to package. I plan to maintain this package as part of the Debian Python team.
Re: Improvement of headless server upgrades
On 05.03.25 21:35, Marc Haber wrote: And which of the millions of changes would that be that would break YOUR system? The number of changes that can adversely impact your ability to boot *or* your network connectivity (but which won't fail the upgrade!) can safely be assumed to be smaller than five or so. Anything else can be fixed post-upgrade. -- -- regards -- -- Matthias Urlichs OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Improvement of headless server upgrades
Matthias Urlichs writes: > On 05.03.25 17:16, Bjørn Mork wrote: >> apt install apt-listchanges > > To be fair, apt-listchanges lists a whole lot of changes, esp. when > you do a dist-upgrade. > > Noticing the one change among the umpteen more-or-less-major NEWS > entries that actually affects the ability of your system to safely > reboot with the same network configuration is not a trivial task, even > for reasonably experienced sysadmins. I agree. But I don't see what makes the proposal any better. We can (and do, AFAIK) discuss which items belong in NEWS. But there are many more-or-less-major changes which might require attention when you do a dist-upgrade. Filtering this list down to one or two items is not realistic. And prefixing the list with ATTENTION won't make the job any easier. Bjørn
Re: Improvement of headless server upgrades
On 2025-03-05 14:51, Bjørn Mork wrote: We can (and do, AFAIK) discuss which items belong in NEWS. But there are many more-or-less-major changes which might require attention when you do a dist-upgrade. Filtering this list down to one or two items is not realistic. And prefixing the list with ATTENTION won't make the job any easier. I doubt there are more than one or at max two items that would break network connectivity. In both cases it was only one item that broke my ability to connect to the rebooted machine. After the dist-upgrade finishes, people would usually type reboot and hit enter. If above the current prompt (where you enter 'reboot'), something like _ _ _ _ _ _ _ ___ ___ _ _ / \|_ _|_ _| | \ | |_ _|_ _/ _ \| \ | | / _ \ | | | | | _| | \| | | | | | | | | \| | / ___ \| | | | | |___| |\ | | | | | |_| | |\ | /_/ \_\_| |_| |_|_| \_| |_| |___\___/|_| \_| or _ ___ _ ___ / ___|_ _/ _ \| _ \/ ___|_ _/ _ \| _ \ \___ \ | || | | | |_) | \___ \ | || | | | |_) | ___) || || |_| | __/ ___) || || |_| | __/ |/ |_| \___/|_| |/ |_| \___/|_| shows up, I am pretty sure it catches your attention. Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Improvement of headless server upgrades
On Wed, Mar 05, 2025 at 03:32:51PM -0500, Helmut K. C. Tessarek wrote: I doubt there are more than one or at max two items that would break network connectivity. And which of the millions of changes would that be that would break YOUR system? -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: Bits from DPL
On 05.03.25 12:17, Sean Whitton wrote: Ftpmaster team is seeking for new team members == No, we are not. The NEW queue currently contains ~135 packages. The median wait time on the list(*) is three weeks, and the oldest packages have been, well, languishing, for nine months or so. (*) Yes I know that this may well be an inflated median: after all, the packages which ftpmaster *did* process lately are not on the list by definition. However, that's still 50 people who've been waiting for at least a month to get their package into Debian. Of the ITP bugs I spot-checked randomly, none contained a hint why the package was not yet processed. If no current team member has free time for pruning this list, adding new members is the obvious solution. While we all know that bringing new people up to speed eats time too, not fixing the roof because you're too busy emptying buckets is not a viable long-term strategy. If you have a better idea how to improve the situation, by all means let's hear it. NB: "now would not be a good time" begs the question how long you expect said "now" to last. -- -- regards -- -- Matthias Urlichs OpenPGP_signature.asc Description: OpenPGP digital signature
