Re: Change the expectation that emails should wrap at 80 characters
On Wednesday, March 12, 2025 5:38:40 PM Mountain Standard Time Mario Limonciello wrote: > > > > >Mario Limonciello (hints of format=flowed support) > > > Thanks for the summary. I am of the camp of f=f. > > At least with the MUA I'm using most of the time (Thunderbird) this is > the default, and no one has complained to me directly about it for any > email sent to the Kernel community or Debian community. > > As it seems to be a polarizing discussion I do wonder if maybe it would > make most sense to have a "proper" vote to determine which way the > "silent majority" of developers actually lean? I am planning on proposing a GR, but I want to take the time to make sure I word it well. I expect to be able to do so in the next few days. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#1100501: ITP: blazar-dashboard -- Horizon plugin for the Blazar Reservation Service for OpenStack
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: blazar-dashboard Version : 13.0.0~rc1 Upstream Contact: OpenStack Discuss * URL : https://github.com/openstack/blazar-dashboard * License : Apache-2.0 Programming Lang: Python Description : Horizon plugin for the Blazar Reservation Service for OpenStack Blazar is a resource reservation service for OpenStack. Blazar enables users to reserve a specific type/amount of resources for a specific time period and it leases these resources to users based on their reservations. . This package contains the OpenStack dashboard plugin. I'll maintain this in the OpenStack team.
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
On Wednesday, March 12, 2025 12:11:37 AM Mountain Standard Time Andrey Rakhmatullin wrote: > >As has already been mentioned, nothing of substance has changed since Debian > >held a GR on this issue. However, if down the road open hardware with free > >firmware became more widely available (I’m looking at you, RISC-V, although > >I understand that the most likely short-term outcome is that companies will > >produce non-free firmware for their RISC-V processors), then it might be > >worth reopening the issue for consideration. > That's just processors though, and processors usually contain their > non-free firmware anyway. The original issue was about hardware that > doesn't contain firmware but wants it loaded from the OS. That’s a good point. RISC-V isn’t only being used as main CPUs, but also for all types of other things that require firmware. For example, Western Digital is spending effort to bring RISC-V to their storage controllers. https://blog.westerndigital.com/risc-v-swerv-core-open-source/ The salient point is that the open hardware movement is just in its infancy and it is going to be a long time before there are common production machines that can run securely and well without the need to use and update proprietary firmware. RISC-V has the potential to replace a lot of the current ARM micro controllers. RISC-V uses a permissive license, somewhat akin to the Apache 2.0 License in the sense that anyone who builds upon it can decide if they want the outcome of their work to be open or closed. So, some RISC-V chips will ship with open hardware schematics and information and others won’t. In addition, even if someone chooses to ship open hardware RISC-V, that doesn’t mean they will provide the source information for the corresponding firmware, so you could end up with a situation where there is an open hardware chip running non-free firmware. But it is a beginning, and some day we will probably see wireless chips and ethernet chips and GPUs and TPMs and everything else shipping open hardware running open firmware. At that point, it will be easy to advocate for installers that match. Of course, there is nothing preventing companies from adopting free and open firmware running on closed hardware. That is the current situation for most if not all of the free firmware currently shipping in Debian. But my personal opinion is that the free firmware movement won’t take off without the open hardware movement. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#1100469: ITP: golang-github-apptainer-apptainer -- Apptainer: Application containers for Linux
Package: wnpp Severity: wishlist Owner: Roland Mas * Package name: golang-github-apptainer-apptainer Version : 1.4.0~rc2-1 Upstream Author : The Apptainer Container Project * URL : https://github.com/apptainer/apptainer * License : various permissive licenses (BSD, Apache, ISC, Expat) Programming Lang: Go Description : Apptainer: Application containers for Linux Apptainer is an open source container platform designed to be simple, fast, and secure. Many container platforms are available, but Apptainer is designed for ease-of-use on shared systems and in high performance computing (HPC) environments. It features: . * An immutable single-file container image format, supporting cryptographic signatures and encryption. * Integration over isolation by default. Easily make use of GPUs, high speed networks, parallel filesystems on a cluster or server. * Mobility of compute. The single file SIF container format is easy to transport and share. * A simple, effective security model. You are the same user inside a container as outside, and cannot gain additional privilege on the host system by default. . Apptainer was formerly known as Singularity and is now a part of the Linux Foundation.
Bug#1100490: ITP: blazar -- resource reservation service for OpenStack
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: blazar Version : 15.0.0~rc1 Upstream Contact: OpenStack Discuss * URL : https://github.com/openstack/blazar * License : Apache-2.0 Programming Lang: Python Description : resource reservation service for OpenStack Blazar is a resource reservation service for OpenStack. Blazar enables users to reserve a specific type/amount of resources for a specific time period and it leases these resources to users based on their reservations. . The following two resource types are currently supported: * Compute host: reserve and lease with a unit of a whole host * Instance: reserve and lease with a unit of a flavor This package will be maintained in the OpenStack team.
Re: Need advice on coordinating libkdumpfile update and introducing pykdumpfile
On Sun, 2025-03-09 at 16:39 -0700, Michel Lind wrote: > Hi Breno, > > On Sun, Mar 9, 2025, at 12:29 PM, Breno Leitao wrote: > > Hello Michel, > > > > On Tue, Feb 25, 2025 at 12:37:06PM -0600, Michel Lind wrote: > > > Hi all, > > > > > > On Thu, Feb 13, 2025 at 04:26:12PM -0600, Michel Lind wrote: > > > > On Thu, Feb 13, 2025 at 03:21:04PM -0700, Soren Stoutner wrote: > > > > > Michel, > > > > > > > > > > On Thursday, February 13, 2025 2:36:26 PM MST Michel Lind > > > > > wrote: > > > > > > Ah, OK, so these uploads all require FTP master review > > > > > > right? > > > > > > > > > > > > - soname bump to 0.5.5 in experimental > > > > > > - initial upload of the new pykdumpfile in experimental > > > > > > - dropping python bindings in experimental > > > > > > - 0.5.5 without python in unstable (or can I as a DM do > > > > > > this myself?) > > > > > > - pykdumpfile in unstable > > > > > > > > > > > > If a package that's been cleared for experimental can be > > > > > > uploaded to > > > > > > unstable without FTP master review, even if it has binary > > > > > > subpackage > > > > > > name changes, that would simplify this quite a bit (but if > > > > > > it requires > > > > > > re-review, that's fine too, I just have to know how much to > > > > > > coordinate > > > > > > with the DD sponsoring the upload) > > > > > > > > > > FTP master review is only required when the name of a binary > > > > > package changes. Any > > > > > other change inside the binary package does not require their > > > > > review. > > > > > > > > > > Because FTP master review can take an unpredictable amount of > > > > > time, usually the best > > > > > course of action in this case would be to make all such > > > > > changes in experimental (because > > > > > it is OK for packages in experimental to not be coinstallable > > > > > or otherwise introduce > > > > > breakage with other packages). Once everything is settled, > > > > > you can upload a version of > > > > > these experimental packages that only changes the target to > > > > > unstable and they will all > > > > > drop in immediately. > > > > > > > > > Ah, great, thank you! > > > > > > > > > > Thanks to everyone's feedbacks. I have uploaded this to > > > mentors.debian.net > > > > > > https://mentors.debian.net/package/libkdumpfile/ > > > > I had a look at the package above, but I got the following message > > when > > build. After the test passes, it shows: > > > > dh_missing: error: missing files, aborting > > > > Have you seen anything similar? > > > > Here is the rest of the log, afte the tests passed. > > > > > > Looks like you ran the build on a system with Python headers > installed so it built the Python bindings, then it failed because > there are unpackaged files > > It should not fail in sbuilder or pbuilder, but just in case I can > explicitly disable Python bindings from being built so it’s easier to > do a test build > Hi Breno, The hypothesis is correct; by explicitly passing `--with-python=no` my test build succeeded even when I added python3-dev and python3- setuptools in debian/control Uploaded to mentors as #2 https://mentors.debian.net/package/libkdumpfile/#upload-2 The Salsa CI passed (the previous one has some non-critical failures but I suspect it's due to testing being in flux anyway) https://salsa.debian.org/michel/libkdumpfile/-/pipelines/832412 This is the commit corresponding to the upload https://salsa.debian.org/michel/libkdumpfile/-/commit/2ae62580da65df96c6d5bfe1aeb092cdd57b8acd and this is the added commit disabling Python for inspection https://salsa.debian.org/michel/libkdumpfile/-/commit/9d08aada535d863990a5c293f6e649f61042b6b2 Best regards, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 README: https://fedoraproject.org/wiki/User:Salimma#README signature.asc Description: This is a digitally signed message part
