Bug#932957: Please migrate Release Notes to reStructuredText
Hi Stuart, Stuart Prescott wrote (Sat, 3 Jun 2023 14:45:46 +1000): > > - The list of archs is hardcoded in the Makefile for now. > > The following might provide you with some useful way of not hard-coding > such information: > > curl -s 'https://api.ftp-master.debian.org/suite/bookworm' > > (pipe that into « jq -r '.architectures[]' » to get just the archs as > plain text) I managed to get a list of all relevant architectures via curl -s 'https://api.ftp-master.debian.org/suite/testing' | jq -r '.architectures[]' | grep -v all | grep -v source > You might want to make that a 'maintainer-run' step rather than is run > occasionally as part of preparing a release, rather than as a build time > step. That is, the maintainer runs that from a machine with internet > access to find the list of archs that should be used; this is then > cached in the repo until it is next refreshed. There is precedent for > this 'maintainer-run' step in various "make dist' mechanisms (from the > autotools world) and how the dh-python packages prepares a cache of > known python modules in the archive for later module→package translation. I created a prepare-release.sh script, which can be used to prepare the release-notes for the next stable. That script creates an archlist file, which holds the relevant archs for the current testing. Thanks for helping me with that! > There has been talk for a while about how we might avoid baking in > internal metadata in packages and there might be more inspiration on how > to do this in other parts of the project: > > https://wiki.debian.org/SuitesAndReposExtension > > (there are already a couple of entries there for the release notes) Shouldn't the above solution be added to that wiki page? (I don't see it there, right?) Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#1033065: release-notes: i386 notes should specify minimum CPU requirements
On Mon, 29 May 2023 06:52:22 +0200 Paul Gevers wrote: > On 28-05-2023 17:32, Paul Gevers wrote: > > On 11-05-2023 20:20, Paul Gevers wrote: > >> Please review my proposal here: > >> > >> https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/166 > > > > The release notes now document that the baseline has been bumped. > > I ment this message to close the bug, but I failed to adjust the mail To > header. As commented both on Salsa and in response to your previous e-mail, I still don't think that the release notes adequately describe the updated baseline for i386. As previously stated, the Geode LX (but not older Geodes) does fulfill the baseline requirement for i686. NOPL, PAE and others were marked by Intel as optional features. If what the new Debian baseline really means is something that can run the -686-pae kernel, the release notes should explicitly say so. On a related issue, something in dpkg or apt should check the CPU features and refuse to perform an upgrade/dist-upgrade on an host whose CPU doesn't meet the new baseline requirements. Martin-Éric
Bug#1033065: release-notes: i386 notes should specify minimum CPU requirements
Hi Martin-Éric, On 04-06-2023 21:28, Martin-Éric Racine wrote: As previously stated, the Geode LX (but not older Geodes) does fulfill the baseline requirement for i686. NOPL, PAE and others were marked by Intel as optional features. If what the new Debian baseline really means is something that can run the -686-pae kernel, the release notes should explicitly say so. I believe you are more aware of the problems with the Geode than I, as it were your bugs that lead to the update in the release notes. If I understand correctly the kernel still runs fine, but a bunch of important binaries use NOPL and hence fail on the Geode. We could add a check for NOPL, like I mentioned in the MR. On a related issue, something in dpkg or apt should check the CPU features and refuse to perform an upgrade/dist-upgrade on an host whose CPU doesn't meet the new baseline requirements. Please file a bug with the respective packages. Mentioning it in a bug against the release notes isn't going to achieve that feature. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1037103: release-notes: MariaDB 10.11, versionless package names, potential upgrade issue
Package: release-notes Severity: normal Tags: patch Hi! Please consider including https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/187 in release notes for Bookworm. Details in submission.
Re: release notes mentioning dropped support?
Hi Kernel team, Last release I sent out the message below and in the end we included something [1] in the Release Notes mentioning dropped support. Is there something like that worth mentioning this time around? Paul [1] https://www.debian.org/releases/bullseye/armel/release-notes/ch-information.en.html#no-longer-supported-hardware On 24-05-2021 06:55, Paul Gevers wrote: Hi Kernel team, I happen to own a QNAP (armel) and I spotted in the changelog that it's not going to be supported in bullseye. I was wondering, is that something that should be mentioned in the release notes? Obviously I don't mean because I own it, but I'm betting that support for particular hardware pieces has been dropped in the past too. I don't recall something like that in the buster release notes, but even if we didn't do it in the past, now could be a good moment to start if we think we should add it. Either way, I was wondering what would happen if I try to upgrade such a device. I'm *assuming* that the linux package would detect that the image is too big, but what would that leave me? A fully upgraded system with an old kernel, or is there any detection before any upgrade happens? For owners of such devices, is their only option to stay at buster? E.g. is there any chance in building a smaller custom kernel with less options enabled or is that impossible because nearly everything is build as module? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1033065: release-notes: i386 notes should specify minimum CPU requirements
Hey Paul, On Sun, Jun 4, 2023 at 10:36 PM Paul Gevers wrote: > On 04-06-2023 21:28, Martin-Éric Racine wrote: > > As previously stated, the Geode LX (but not older Geodes) does fulfill > > the baseline requirement for i686. NOPL, PAE and others were marked by > > Intel as optional features. If what the new Debian baseline really > > means is something that can run the -686-pae kernel, the release notes > > should explicitly say so. > > I believe you are more aware of the problems with the Geode than I, as > it were your bugs that lead to the update in the release notes. If I > understand correctly the kernel still runs fine, but a bunch of > important binaries use NOPL and hence fail on the Geode. We could add a > check for NOPL, like I mentioned in the MR. I pasted the result of 'uname -a' and 'cat /proc/cpuinfo' on the Salsa merge request. It should give someone a good idea of what the LX (but not earlier Geodes) supports. > > On a related issue, something in dpkg or apt should check the CPU > > features and refuse to perform an upgrade/dist-upgrade on an host > > whose CPU doesn't meet the new baseline requirements. > > Please file a bug with the respective packages. Mentioning it in a bug > against the release notes isn't going to achieve that feature. Oh, totally. I'm just not sure of which one typically handles this. Last time the baseline was raised from 586 to 686 (before that from 486 to 586), something in the upgrade process performed the CPU check and loudly aborted the proceedings. Something similar was done when the baseline was raised on SPARC ages ago; upgrade aborted early if the host hardware didn't meet the new baseline. Martin-Éric
Re: Any discussion of replacing MoinMoin?
On Sun, 2023-06-04 at 05:45 +, Martin wrote: > To me, the most desperately missing feature is having wiki content in a > VCS, such as git. I like to work on documentation like on code. This is a different kind of wiki to what Franklin and Kamaraju are used to; MediaWiki is backed by a database instead of a VCS and has solely web based editing with all the edit features provided by browsers and JavaScript instead of local software. > I'm not sure, which wiki software does work that way. IIRC MoinMoin 2.x has an option for this. Steve McIntyre planned on working on packaging it for Debian so that we can switch to it later. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1037084: bookworm: When using gdm3 to start non-GNOME wayland sessions, PATH may be set differently
Package: release-notes X-Debbugs-Cc: jlsan...@protonmail.com Severity: important Starting non-GNOME wayland sessions through GDM leads to a user's PATH being set to /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin instead of /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games (from /etc/profile). Example: Starting sway or plasma-workspace-wayland through gdm and trying to launch lutris or gnome-chess only to find out that they won't start even though they are installed. It can take some time for a user to find out that the PATH environment variable is different. This is a regression in bookworm and can surprise users upgrading from bullseye. Possible workarounds are: Using a different display manager such as sddm or starting the wayland session through tty. I first discovered this bug after installing lutris a few months ago[0] and filed a few bug reports[1][2]. As bookworm is about to be released, I thought it may be worthwhile to document this unexpected behavior in its release notes. 0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028543 1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942131 2: https://gitlab.gnome.org/GNOME/gdm/-/issues/846
wiki.debian.org / Re: Any discussion of replacing MoinMoin?
Hi Franklin, Thanks for your interest. On Sat, Jun 03, 2023 at 10:07:00PM +, Franklin Yu wrote: > > MoinMoin, the wiki software backing the Debian Wiki, has suffered from slow > development recently; the latest release is in 2020, and it is written in > Python > 2.7. The Python 3.5 support is still under development. > > Has anyone considered switching to any alternative? The Debian Wiki UI does > not > attract users to contribute (no Wiki syntax highlight in the editor, for > example). I guess it could be useful, and would need someone willing to do the (lots of) work and migration. See also https://bugs.debian.org/501954 wiki.debian.org: #501954: "use MediaWiki instead of MoinMoin" for some (old) background. Bye, Joost
Re: Any discussion of replacing MoinMoin?
Hi Raju, Yes, I fully agree that editing a single section would be a nice feature. We may come up with a list of new features we want, such as: 1. Edit a single section or subsection. 2. Preview diff before submitting a new version. MoinMoin only supports previewing the final result, not the diff; in contrast, MediaWiki supports it. This way we can confirm what was changed, before submitting. 3. Nice to have: source code editor with Wiki syntax highlighting We might also benefit from a list of features in MoinMoin that we want to preserve, but I don’t have much idea about that. Anyway, it’s up to Debian developers to decide, of which I’m not a part. Regards, Franklin signature.asc Description: Message signed with OpenPGP
Re: Any discussion of replacing MoinMoin?
On 2023-06-03 22:07, Franklin Yu wrote: > Has anyone considered switching to any alternative? The Debian Wiki UI does > not > attract users to contribute (no Wiki syntax highlight in the editor, for > example). To me, the most desperately missing feature is having wiki content in a VCS, such as git. I like to work on documentation like on code. That would also solve the problem of syntax highlighting, because editing is just done in ones favourite text editor. I'm not sure, which wiki software does work that way. I assume gitit, gollum, and ikiwiki do. Cheers
