Re: Community survey on network stack for Trixie
On Wed, 4 Sep 2024 21:29:58 +0200, Daniel Baumann
wrote:
>"wild idea": how about just removing ifupdown/ifupdown2/ifupdown-ng and
>decluttering/improving documentation instead then?
I don't see a problem with keeping ifupdown{2,-ng,} if none of those
packages is part of the default install and we remove it from the
beginner- and intermediate-level docs.
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
Re: Community survey on network stack for Trixie
On 9/5/24 10:43, Marc Haber wrote:
> I don't see a problem with keeping ifupdown{2,-ng,} if none of those
> packages is part of the default install and we remove it from the
> beginner- and intermediate-level docs.
right, me neither; but Lukas' argument was that introducing netplan is
"unifying documentation" which there are better ways to get to that (one
of which you just suggested too, thanks).
Regards,
Daniel
Re: Community survey on network stack for Trixie
On 05.09.24 11:36, Daniel Baumann wrote:
On 9/5/24 10:43, Marc Haber wrote:
I don't see a problem with keeping ifupdown{2,-ng,} if none of those
packages is part of the default install and we remove it from the
beginner- and intermediate-level docs.
right, me neither; but Lukas' argument was that introducing netplan is
"unifying documentation" which there are better ways to get to that (one
of which you just suggested too, thanks).
Me neither!
My draft proposal that was shared in the beginning of this thread intents
to keep ifupdown (maybe ifupdown-ng, once it's drop-in compatible) around.
At least for a transitioning period. If we want to drop it from the base
installation eventually or not is fine for me either way. But for the
release where we switch our network stack, we should definitely keep it
around, to give sysadmins some time to adopt to the new recommended tooling.
C'mon, you stated yourself above that "unifying documentation" is an
exaggeration. It is a visible example that leads to user confusion.
In reality it's about unification of network configuration:
I want to cleanup the the scattered networking landscape in Debian, using
modern, maintained and tested tools.
You can read-up on the more detailed reasoning in my [slides] from DebConf.
-- Lukas
[slides] https://people.ubuntu.com/~slyon/slides/debconf24/debian-networking.pdf
Bug#1080526: ITP: python-multiurl -- Python package for downloading multiple URLs at once
Package: wnpp Severity: wishlist Owner: Gard Spreemann X-Debbugs-Cc: debian-devel@lists.debian.org, g...@nonempty.org * Package name: python-multiurl Version : 0.3.1 Upstream Contact: European Centre for Medium-Range Weather Forecasts * URL : https://github.com/ecmwf/multiurl * License : Apache-2.0 Programming Lang: Python Description : Python package for downloading multiple URLs at once Python package for downloading multiple URLs at once This package is a simple prerequisite of python-cads-api-client [1]. I aim to maintain the package myself, together with the reverse dependencies (python-api-cads-client and python-cdsapi). [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078809 signature.asc Description: PGP signature
Re: Community survey on network stack for Trixie
On 04.09.24 21:41, Daniel Baumann wrote: sorry, one more.. On 9/4/24 18:00, Lukas Märdian wrote: But we ought to look at the bigger picture! From that point of view, it doesn't make sense to even consider netplan. No distribution other than ubuntu is using it. If Debian uses network-manager and systemd-networkd, there's hardly any difference in the configuration wrt/ to the other major distributions, so, *that* has the potential to unify documentation. Except that others recommend only ONE tool and stick to it, while Debian would recommend two at the same time. (Three actually, as Netplan is used in our cloud-images.) That's exactly what leads to confusion. * Fedora/RHEL recommends NetworkManager * Ubuntu recommends Netplan * For others like Arch Linux or Gentoo, people choose their stack explicitly, so it doesn't really matter. Debian would recommend NetworkManager for desktop/laptop, systemd-networkd for server, Netplan for cloud. And people would need to do their research to understand what stack they are on, to then better understand how to control it. or in other words: If you would truly care for that then let's use the chance to *remove* some Debian-isms (ifupdown and friends) from the "big picture", rather than further *adding* more divergence by fostering netplan. I'm all for removing Debian-isms, but I guess that's a discussion for another year... Agreeing on Netplan would provide us with the hybrid stack that you described above, but without the confusion. Furthermore, it's been proven in Ubuntu for 7+ years, so lots of edge-cases have already been hit and handled. Cheers, Lukas
Re: LPC: Support for Complex Cameras in Debian
Hi Ricardo, Am Tue, Sep 03, 2024 at 10:37:27PM +0200 schrieb Ricardo Ribalda Delgado: > ... > As a newer DD, I don't feel comfortable speaking on behalf of the > project just yet. I'm hoping someone from debian-dev or > debian-multimedia might be interested in participating, either in > person or virtually.s If you are a "newer DD" but with competence on the actual topic I wonder what some "older DD" who has no idea about the topic can do better than you? > Alternatively, if someone could spare 30-60 > minutes to discuss Debian's best approach with me before the event, > that would be immensely helpful. What actual question do you want to discuss? Kind regards Andreas. -- https://fam-tille.de
Re: Community survey on network stack for Trixie
On Thu, 5 Sep 2024 14:48:49 +0200, Lukas Märdian wrote: >But for the >release where we switch our network stack, we should definitely keep it >around, to give sysadmins some time to adopt to the new recommended tooling. Or to keep the old tooling, yes. Te default is a default for new installs. As a distribution that supports upgrades, we have to. We are not Red Hat where the recommended way to go from one major release to the next one is a full reinstall. 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
Re: Bits from DPL
Hi, Am Wed, Sep 04, 2024 at 11:29:39PM -0400 schrieb Scott Kitterman: > On Wednesday, September 4, 2024 6:22:14 PM EDT Pierre-Elliott Bécue wrote: > > > > OoC, what is your point, especially considering the quote of your own > > opinion Andreas made? > > > > This just seems passive-aggressive, and the fact he stepped up once > > doesn't mean he has the time or will to step up hundreds of times. > > I think it's odd that he would talk about how hesitant people are to touch > other packages when he in fact does it himself. I'm not sure who he thinks > he's speaking for, clearly not himself. I did it *after* someone with insight into the topic gave the according hint[1]. So the sequence was: 1. I filed ITS 2. Someone with insight suggested removal 3. Reassigned ITS to RM I personally see some difference between this sequence and a straight asking for removal. > I don't have statistics, but maintainer filed RM requests a pretty rare. My > impression is it's only a small fraction of the total. I processed a lot of > requests last night and almost none of the requests for package removal were > from maintainers. You are definitely the expert about package removals. > It probably was a little passive aggressive, but I don't appreciate the DPL > using the Bits from DPL message to punch down like that. If he has a point > to > make to further the discussion, it should be made as part of the discussion. My intention was to highlight interesting contributions to the entire discussion. If phrases like 'Scott Kitterman made a valid point' and 'I agree' came across as dismissive, I sincerely apologize—that was not my intent. I genuinely valued your point, and I added my own suggestion "based on defined criteria, it could help reduce some of the social pressure." Item 2. above could possibly be such a criterion, since you pointed to this actual example. > If he's only trying to bring the issue to the wider project's attention, then > I don't think picking one person's opinion to disagree with in Bits is very > appropriate. I'm sorry if there was any misunderstanding, but I'm unsure how my message gave the impression that I disagreed. Could you clarify which part led you to this conclusion? Also, just to clarify, I avoid using sarcasm in electronic communication, especially in Bits from the DPL, as it often doesn't translate well. > FWIW, all an automated process would do is create work for the FTP Team. > Those I would feel I have to scrutinize even more closely than ones filed by > a > human since no one has given it a sanity check before it gets to the FTP Team > to process. I need to trust you here as the one who is doing the work. The discussion also was about a semi-automatic process which. Do you have some opinion about this? Kind regards Andreas. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079816#8 -- https://fam-tille.de
Bug#1080951: ITP: gifcurry -- Video editor for GIF makers
Package: wnpp Severity: wishlist Owner: Pete Ryland X-Debbugs-Cc: debian-devel@lists.debian.org, p...@pdr.cx * Package name: gifcurry Version : 6.0.1.0 Upstream Contact: David Lettier URL : https://github.com/lettier/gifcurry * License : BSD-3-Clause Programming Lang: Haskell Description : Video editor for GIF makers Import a video, trim, crop, add text, pick a font, set the size, enable dithering, import subtitles, and save your creation as either a GIF or a video. Making GIFs with Gifcurry is fun! There are CLI and GTK binaries which I plan to put into separate binary packages, gifcurry-cli and gifcurry-gui. I plan to maintain this within the Debian Haskell Team using the standard tooling.
Bug#1080953: ITP: haskell-gi-gst -- GStreamer bindings
Package: wnpp Severity: wishlist Owner: Pete Ryland X-Debbugs-Cc: debian-devel@lists.debian.org, p...@pdr.cx * Package name: haskell-gi-gst Version : 1.0.29 Upstream Contact: Iñaki García Etxebarria (gare...@gmail.com) URL : https://hackage.haskell.org/package/gi-gst * License : LGPL-2.1-only Programming Lang: Haskell Description : GStreamer bindings Bindings for the GStreamer library. This is a dependency for gifcurry. I will maintain this package within the Debain Haskell Team in the normal way.
Bug#1080954: ITP: haskell-gi-gstbase -- GStreamer Base bindings
Package: wnpp Severity: wishlist Owner: Pete Ryland X-Debbugs-Cc: debian-devel@lists.debian.org, p...@pdr.cx * Package name: haskell-gi-gstbase Version : 1.0.28 Upstream Contact: Iñaki García Etxebarria URL : https://hackage.haskell.org/package/gi-gstbase * License : LGPL-2.1-only Programming Lang: Haskell Description : GStreamer Base bindings Bindings for the GStreamer Base library. Dependency for gifcurry. I will maintain this within the Debian Haskell Team.
Bug#1080955: ITP: haskell-gi-gstvideo -- GStreamer Video bindings
Package: wnpp Severity: wishlist Owner: Pete Ryland X-Debbugs-Cc: debian-devel@lists.debian.org, p...@pdr.cx * Package name: haskell-gi-gstvideo Version : 1.0.28 Upstream Contact: Iñaki García Etxebarria URL : https://hackage.haskell.org/package/gi-gstvideo * License : LGPL-2.1-only Programming Lang: Haskell Description : GStreamer Video bindings Bindings for the GStreamer Video library. Dependency for gifcurry. I plan to maintain this within the Debian Haskell Team.
Bug#1080956: ITP: saunafs -- SaunaFS is a distributed, FUSE filesystem that is focused on reliability and data integrity. It supports erasure-coding for files.
Package: wnpp Severity: wishlist Owner: Urmas Rist X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: saunafs Version : 4.4.0 Upstream Contact: Name * URL : https://github.com/leil-io/saunafs * License : GPL Programming Lang: C, C++ Description : SaunaFS is a distributed, FUSE filesystem that is focused on reliability and data integrity. Some of the features include: * Erasure-coding (EC) for files. * Real-time journaling for recovery of metadata and auditing. * Copy-on write snapshots of files. * Extra protection when reading/writing data through CRC. * High-availability and optional automatic failover to one or more shadow master servers. Disclaimer: I am the upstream maintainer and employed to work on it. My employer was asked by some in the Debian Medical mailing list (https://lists.debian.org/debian-med/2024/07/msg00030.html) to help package this for Debian. While the company declined (since we don't have the manpower for it), I decided I would do help out in my personal free time and capacity. SaunaFS was forked from LizardFS (which was originally forked from MooseFS) a year and half ago, when development completely stopped (in reality, development was already slow to non-existant years prior, or it was closed-source). The developers (most of who worked on LizardFS during the last days of it, and some who worked in the very first days) are employed by the company Leil Storage, which is selling storage hyperscaler solutions. Since forking from LizardFS, there have been many fixes and features added to SaunaFS, and is currently more maintained than LizardFS was in the last 4 years. However, it doesn't support upgrading from LizardFS to SaunaFS directly currently (there are plans to add some level of support for migrating from LizardFS, like metadata conversion). It is similar to MooseFS (they share a lot of the codebase from MooseFS 1.6), however it has a few key advanatages in terms of culture: 1. Many developers have worked on it over the years (from LizardFS to SaunaFS), and has such the code is much more maintainable than MooseFS, which only one developer has worked on. 2. All of the tests (around 200-300) for SaunaFS/LizardFS is open source, whereas MooseFS has four tests and unknown (if any) tests that are closed-sourced, making working on the code difficult in a open-source environment. 3. Combined with the above factors, any fork of MooseFS would be difficult. 4. Many features (e.g EC) and new releases of MooseFS are only offered under proprietary licenses. SaunaFS meanwhile releases frequently (generally around once a month) completely free and open source, with some proprietary plugins for things like SMR drives outside the project. 5. MooseFS project health is also concerning, given that only one developer works on it and if he stops working, other developers would have a difficult time working on it. Thus, SaunaFS could be viewed as a more open-source and free alternative to MooseFS that is being actively maintained and will continue to be for the likely forseeable future. I would start packaging by reviewing the previous LizardFS packages. Some things are likely not relevant anymore. For example, renaming the binaries to not conflict with MooseFS (this was done upstream). I plan to spend about 16 hours per month helping maintain this package. No plans are currently do it in a packaging under a team, however Debian med could be a candidate since this ITP was asked on there. I'm also looking for a sponsor. This package would probably split up into their own sub packages (e.g saunafs-master, saunafs-chunkserver) similar to MooseFS/LizardFS.
Re: Bits from DPL
On September 5, 2024 3:39:35 PM UTC, Andreas Tille wrote: >Hi, > >Am Wed, Sep 04, 2024 at 11:29:39PM -0400 schrieb Scott Kitterman: >> On Wednesday, September 4, 2024 6:22:14 PM EDT Pierre-Elliott Bécue wrote: >> > >> > OoC, what is your point, especially considering the quote of your own >> > opinion Andreas made? >> > >> > This just seems passive-aggressive, and the fact he stepped up once >> > doesn't mean he has the time or will to step up hundreds of times. >> >> I think it's odd that he would talk about how hesitant people are to touch >> other packages when he in fact does it himself. I'm not sure who he thinks >> he's speaking for, clearly not himself. > >I did it *after* someone with insight into the topic gave the according >hint[1]. >So the sequence was: > 1. I filed ITS > 2. Someone with insight suggested removal > 3. Reassigned ITS to RM >I personally see some difference between this sequence and a straight asking >for >removal. > >> I don't have statistics, but maintainer filed RM requests a pretty rare. My >> impression is it's only a small fraction of the total. I processed a lot of >> requests last night and almost none of the requests for package removal were >> from maintainers. > >You are definitely the expert about package removals. > >> It probably was a little passive aggressive, but I don't appreciate the DPL >> using the Bits from DPL message to punch down like that. If he has a point >> to >> make to further the discussion, it should be made as part of the discussion. >> > >My intention was to highlight interesting contributions to the entire >discussion. If phrases like 'Scott Kitterman made a valid point' and 'I >agree' came across as dismissive, I sincerely apologize—that was not my >intent. I genuinely valued your point, and I added my own suggestion >"based on defined criteria, it could help reduce some of the social >pressure." > >Item 2. above could possibly be such a criterion, since you pointed to >this actual example. > >> If he's only trying to bring the issue to the wider project's attention, >> then >> I don't think picking one person's opinion to disagree with in Bits is very >> appropriate. > >I'm sorry if there was any misunderstanding, but I'm unsure how my >message gave the impression that I disagreed. Could you clarify which >part led you to this conclusion? Also, just to clarify, I avoid using >sarcasm in electronic communication, especially in Bits from the DPL, as >it often doesn't translate well. Thanks for the clarification. I read it as I said something and you disagree (since you proposed something different). I think it's inherently abusive for a person in a position of power (DPL speaking as DPL, e.g. in Bits from the FPL) to leverage that position against someone who is not similarly situated, which is how it came across to me. I'm willing to assume good faith and accept that was not your intention. It's in the past. >> FWIW, all an automated process would do is create work for the FTP Team. >> Those I would feel I have to scrutinize even more closely than ones filed by >> a >> human since no one has given it a sanity check before it gets to the FTP >> Team >> to process. > >I need to trust you here as the one who is doing the work. The >discussion also was about a semi-automatic process which. Do you have >some opinion about this? > I don't have any problem with a process that suggests to people doing QA work in Debian that package removal might be appropriate based on some criteria. I don't think that such a semi-automatic process relives the person filing the RM bug from engaging their brain to decide if it makes sense. I can see how having such a tool that used criteria that has been socialized within the project to some degree might reduce social pressure to not file the bug. More people working on QA is always good. Scott K
Bug#1080958: ITP: mimetreeparser -- parser for a MIME tree
Package: wnpp Severity: wishlist Owner: Patrick Franz X-Debbugs-Cc: debian-devel@lists.debian.org, delta...@debian.org * Package name: mimetreeparser Version : 24.08.0 Upstream Contact: KDE * URL : https://invent.kde.org/pim/mimetreeparser * License : GPL-2+ Programming Lang: C++ Description : parser for a MIME tree This repository contains a parser for a MIME tree and is based on KMime. The goal is given a MIME tree to extract a list of parts (e.g. text, html) and a list of attachments, check the validity of the signatures and decrypt any encrypted part. The package is part of KDE PIM and will be maintained by the Debian Qt/KDE team.
