Re: DEP5 and spdx shortname of license
Hi Aurélien, On Sat Sep 7, 2024 at 10:56 PM CEST, Aurélien COUDERC wrote: Our spec [2] already defines an equivalence rule between License-X and License-X.0 declarations for SPDX compatibility. For what I’ve seen on the quite vast and diverse KDE source corpus we’d only need 2 additional equivalence rules to be added to matches what that upstream ships : - equivalence between the + and -or-later suffixes (GPL-2+ / GPL-2.0-or-later) There's already an equivalence in the SPDX spec, as described in "Annex D: SPDX license expressions"[1] (kind of. using the plus sign operator "+" is SPDX's general way of saying "this version or later", while "-or-later" is a special case only valid for GPL licenses, as described in [2] and [3]). This means that you can use "GPL-3.0+" in debian/copyright and have it being valid both when interpreted as our format or as an SPDX expression. - equivalence between MIT and Expat. This would be really helful. SPDX clearly defines all the MIT variants, so, if we agree that we are using SDPX names, there's no ambiguity in using "MIT". [1]: https://spdx.github.io/spdx-spec/v2-draft/SPDX-license-expressions/ [2]: https://spdx.dev/license-list-3-0-released/ [3]: https://www.gnu.org/licenses/identify-licenses-clearly.html signature.asc Description: PGP signature
Re: DEP5 and spdx shortname of license
Jonas Smedegaard: [...] DEP5 already encourages (but does not require) use of SPDX shortnames, except where Debian and SPDX disagree on sensible naming. See https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#spdx and the historical notes at https://wiki.debian.org/Proposals/CopyrightFormat#Differences_between_DEP5_and_SPDX Do you have ideas on how to address the documented differences in naming choices? - Jonas Is it really that valuable for us to have a delta here compared to what upstream projects would use? As I understand it, we are at worst talking `GPL-2.0-only` / `GPL-2.0-or-later` (SPDX) vs `GPL-2` / `GPL-2+` (DEP-5). As much as I might prefer the DEP-5 variant, I am struggling to see the advantage outweigh the cost of divergence. With my current knowledge, I would strongly be in favor of deprecating the unique names for DEP-5 and encourage migration to fully compliant SPDX names. Best regards, Niels
Re: DEP5 and spdx shortname of license
Le 8 septembre 2024 09:38:00 GMT+02:00, Andrea Pappacoda a écrit : >Hi Aurélien, > >On Sat Sep 7, 2024 at 10:56 PM CEST, Aurélien COUDERC wrote: >> Our spec [2] already defines an equivalence rule between License-X and >> License-X.0 declarations for SPDX compatibility. >> For what I’ve seen on the quite vast and diverse KDE source corpus we’d only >> need 2 additional equivalence rules to be added to matches what that >> upstream ships : >> - equivalence between the + and -or-later suffixes (GPL-2+ / >> GPL-2.0-or-later) > >There's already an equivalence in the SPDX spec, as described in "Annex D: >SPDX license expressions"[1] (kind of. using the plus sign operator "+" is >SPDX's general way of saying "this version or later", while "-or-later" is a >special case only valid for GPL licenses, as described in [2] and [3]). > >This means that you can use "GPL-3.0+" in debian/copyright and have it being >valid both when interpreted as our format or as an SPDX expression. Thanks, interesting. What I'd like to see is us updating *our* spec to have the equivalence the other way around and I can extract upstream provided SPDX licence identifiers while staying debian-machine-readable-copyright compliant. -- Aurélien
Re: DEP5 and spdx shortname of license
On Sun, 08 Sep 2024 at 09:49:39 +0200, Niels Thykier wrote: > Is it really that valuable for us to have a delta here compared to what > upstream projects would use? IMO: no. If (some) upstream projects are now taking copyright/license tracking in general (and machine-readable copyright/license specifically) more seriously than many did previously, we should take the win, rather than fighting it on the basis that we think our Debian-specific names are better. Perhaps our Debian-specific names *are* better, but the relevant question is whether they are *sufficiently* better to outweigh the benefit of sharing effort and specifications with the rest of the world (and I don't think they are). > As I understand it, we are at worst talking `GPL-2.0-only` / > `GPL-2.0-or-later` (SPDX) vs `GPL-2` / `GPL-2+` (DEP-5). That, and MIT (SPDX) vs Expat (DEP-5) for one particularly popular member of the MIT/X11 license family, as used in Expat and many other projects. smcv
Re: DEP5 and spdx shortname of license
Il 08/09/2024 12:25, Aurélien COUDERC ha scritto: Le 8 septembre 2024 09:38:00 GMT+02:00, Andrea Pappacoda a écrit : Hi Aurélien, On Sat Sep 7, 2024 at 10:56 PM CEST, Aurélien COUDERC wrote: Our spec [2] already defines an equivalence rule between License-X and License-X.0 declarations for SPDX compatibility. For what I’ve seen on the quite vast and diverse KDE source corpus we’d only need 2 additional equivalence rules to be added to matches what that upstream ships : - equivalence between the + and -or-later suffixes (GPL-2+ / GPL-2.0-or-later) There's already an equivalence in the SPDX spec, as described in "Annex D: SPDX license expressions"[1] (kind of. using the plus sign operator "+" is SPDX's general way of saying "this version or later", while "-or-later" is a special case only valid for GPL licenses, as described in [2] and [3]). This means that you can use "GPL-3.0+" in debian/copyright and have it being valid both when interpreted as our format or as an SPDX expression. GPL-3.0+ and GPL-3.0 are deprecated in spdx and from what I saw a tool using spdx consider them not valid Thanks, interesting. What I'd like to see is us updating *our* spec to have the equivalence the other way around and I can extract upstream provided SPDX licence identifiers while staying debian-machine-readable-copyright compliant. spdx license list it's big and it keeps growing, I think this can help in some cases where searching among the Debian ones it is difficult to find there are some cases where even the spdx list is not enough but I found a match in scancode-licensedb.aboutcode.org (now with 2197 licenses) seems that someone tried to add scancode or integrate its detection in decopy (https://wiki.debian.org/JelmerVernooij/scancode) and that would be great if we could succeed -- Aurélien OpenPGP_signature.asc Description: OpenPGP digital signature
Re: DEP5 and spdx shortname of license
Il 08/09/2024 07:38, Jonas Smedegaard ha scritto: [CC'ing Fabio as they seemingly missed my earlier list-only reply] Quoting Fabio Fantoni (2024-09-07 23:57:35) Il 07/09/2024 22:56, Aurélien COUDERC ha scritto: Le samedi 7 septembre 2024, 21:43:35 CEST Fabio Fantoni a écrit : So I wonder, is it possible to put in d/copyright DEP5 the short license names using the spdx ones? we’ve been doing that for KDE packages since upstream started tagging all source files with SPDX-License / SPDX-Copyright headers and so using SPDX license identifiers some years ago. See [1] for example. While not strictly adhering to DEP-5 I consider it useful to have a machine-readable-with-SPDX-identifiers and I’m not sure how useful it is to try and translate upstream-provided SPDX identifiers into something else. Our spec [2] already defines an equivalence rule between License-X and License-X.0 declarations for SPDX compatibility. For what I’ve seen on the quite vast and diverse KDE source corpus we’d only need 2 additional equivalence rules to be added to matches what that upstream ships : - equivalence between the + and -or-later suffixes (GPL-2+ / GPL-2.0-or-later) - equivalence between MIT and Expat. [1] https://salsa.debian.org/qt-kde-team/kde/plasma-workspace/-/blob/debian/experimental/debian/copyright [2] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name Thanks for the information, about tools that help to create and check d/copyright are you experiencing problems? You might already be aware, but (also for others following along) an overview of tools is maintained here: https://wiki.debian.org/CopyrightReviewTools I use a lot decopyand I found that there is this MR of 1 year ago not merged: https://salsa.debian.org/debian/decopy/-/merge_requests/4 it would be useful even if it didn't have spdx generation by default but at least as an option, I was wondering if there was something preventing the use of the spdx name but from the current responses it does not appear. Licensecheck can use strictly SPDX shortnames like this: licensecheck --shortname-scheme spdx --check '.*' --recursive --deb-machine --lines 0 -- * ...or more relaxed use fallbacks for patterns without SPDX shortname: licensecheck --shortname-scheme spdx,debian,internal --check '.*' --recursive --deb-machine --lines 0 -- * If you want another output than the DEP5 file format implied by the option --deb-machine (e.g. one that includes hashes for each file, never shortening file lists with wildcards) then please file a bugreport against licensecheck and let's discuss that in detail there: https://www.debian.org/Bugs/Reporting one more question, is there any tool/script to convert current d/copyright to spdx names? See to tools at https://wiki.debian.org/CopyrightReviewTools and please update that list if you find additional tools helpful. Thanks for interest in copyright and licensing tracking, - Jonas Thanks for your reply and information, I already saw that wiki page. Overall the tool I used the most as a base from which to start creating or updating d/copyright is decopy, then manual changes are always required. Initially if I remember correctly I didn't use any tools but I made rare manual changes to the d/copyright, later I used decopy suggested by Maxy and Marga who taught me a lot about packaging in the early years. A few years ago (to try to reduce the times) I had tried several other tools, I don't remember exactly all which ones, but mainly looking at the list from the wiki page, I didn't find anything better and the only decent one that could be useful in some cases was licensecheck. Recently I retried to look about the tool and I found lrc (licenserecon) that seems useful in identifying some missing or incorrect entries. I did some tests using spdx short name, but seems that currently the tools are not good enough to be able to manage them well (in total) and it would take more time than the debian names. If they were well supported instead it could save some time in some cases to identify the licenses and I suppose it would be easier and faster also for new maintainers who already know/use the spdx names, rather than learning the debian ones and the various differences. licensecheck even if with "--shortname-scheme spdx,debian" seems show some debian name where can show spdx instead, with only spdx is probably good but i haven't tested it enough licenserecon don't support spdx name so show entries with correct license but spdx name as difference decopy don't support spdx name in DEP5 output produced but there is a MR of 1 year ago I'll see if Aurélien COUDERC or someone else from the KDE team who uses spdx names will answer me to know what tools they use I tried also scancode-toolkit after saw that it have a very big license list (more that spdx), support to generate DEP5 output but is bad, I think can be useful only for help detect
Bug#1081155: ITP: openrocket -- Model Rocket Simulator
Package: wnpp Severity: wishlist Owner: Bdale Garbee X-Debbugs-Cc: debian-devel@lists.debian.org Package name: openrocket Version : 23.09 URL : https://openrocket.info License : GPLv3+ Programming Lang: Java Description : Model Rocket Simulator OpenRocket is a free, fully featured model rocket simulator that allows you to design and simulate your rockets before actually building and flying them. . OpenRocket features a full six-degree-of-freedom simulation, realistic wind modeling, a multitude of different components including free-form and canted fins, clustering and staging. Years ago, I packaged OpenRocket for Debian main. It's a Java app, and as upstream embedded more and more third-party class libs in their source tree, often in the form of binary jar files, I eventually "gave up" and replaced the full source build with an installer for the "fat" application jar file provided by upstream in contrib. Then upstream development stalled, and there were no new releases for some years. The installer package gradually became less useful as the release it was designed for from 2015 had a hard dependency on Java versions no longer available in any version of Debian. In recent times, the upstream development community around OpenRocket has gotten healthier, and new releases have been made. Because the existing installer in contrib did not work with them, I agreed with the idea in bug #1079850 that the installer should just be removed from Debian contrib entirely. In the near term, it is possible to use upstream's distribution-agnostic Linux download to obtain and run the program, though that is of course side-stepping Debian policy and the DFSG. For some time, I've been slowly working through the issues that prevent a "proper" build of OpenRocket for Debian main. A couple bugs filed upstream and against class library packages in Debian have been responded to, but there's more to do. I'm filing this ITP as a replacement for both the installer package just removed from contrib, and the RFP filed as bug #1021564 which has of course been closed with the removal of the existing package. To be clear, I'd *LOVE* to have help from anyone who groks Java packaging in Debian to get the remaining embedded class libraries that aren't already packaged taken care of, updating those that have fallen out of date, etc. Feel free to reach out to me directly if you'd like to help get OpenRocket back in Debian main! Bdale
Re: DEP5 and spdx shortname of license
Quoting Fabio Fantoni (2024-09-08 19:29:18) > licensecheck even if with "--shortname-scheme spdx,debian" seems show > some debian name where can show spdx instead, with only spdx is probably > good but i haven't tested it enough Interesting. Please file bugreports, one issue in detail in each bugreport (summarizing multiple ideas/issues is difficult to handle). Similar for the issues you've discovered with other tools. Thanks, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Network stack for Trixie
Hi all, Sorry for the delayed answer. I've been busy at many fronts. And thanks so much to Lukas for friendly taking care of this topic. El 21/08/24 a las 10:30, Lukas Märdian escribió: > Hi Daniel, > > On 20.08.24 16:25, Daniel Gröber wrote: > > Hi Lukas, > > CCing d-devel, > > This email was intended to first gauge opinions from networking maintainers, > before pushing it out to debian-devel@l.d.o.. All the points still hold and > are fine to be public. But let me at least add the preamble and references > that you dropped from the email quotation. > > --- 8< --- > > On 20.08.24 12:58, Lukas Märdian wrote: > > Hi network maintainers! > > > > After our [Networking BoF] at DebConf24 in Busan I had the impression that > > Santiago is primarily interested in sunsetting classic ifupdown while > > avoiding > > to pull in any Python dependency into our base installations. I would like to rephrase my primary interest: replacing ifupdown with ifupdown-ng as soon as feasible (i.e., when it is ready). And yes, I would like to avoid that the decision that will come from this thread (we will decide something, right?) doesn't pull any python dependency. Switching the default network stack configuration tool is a semi-independent question. But in any case, I think that Debian would benefit for moving to something shared with other distros (netplan with Ubuntu, ifupdown-ng with Alpine Linux, ...) [snip] > > From previous discussion on debian-devel@l.d.o I also deduced that Daniel > > is > > interested in making ifupdown-ng a [drop-in replacement] for classic > > ifupdown, > > while the ifupdown2 maintainers are not interested in pushing their tool to > > become a default choice in Debian. I myself have been trying to introduce > > Netplan to a broader audience, after it got adopted by our [cloud-images] > > and > > integrated with [debian-installer]. > > --- 8< --- > > > tl;dr: I'm sorry to say I strongly oppose both removing ifupdown* in forky > > as well as raising netplan to Priority: standard. To move this forward > > without conflict I think we should base the default networking tool > > decision on data not developer opinion. > > In the end it still needs to be a developer decision, because someone needs > to do the work. Otherwise, we would be suffering the same way we did with > classic ifupdown in the past years, as it's becoming harder and harder to > maintain. We need a healthy upstream project and people willing to do the > actual maintenance work in Debian. > > Can you please elaborate why you're opposed to raising "netplan-generator" > to "Priority: standard"? That's independent of keeping ifupdown-ng installed > in Forky+ and I can't find any explanation about that in your comments below. > > > On Tue, Aug 20, 2024 at 12:58:28PM +0200, Lukas Märdian wrote: > > > So I want to find a compromise involving all interested parties. If there > > > are > > > no strong objections, I'd like to move forward with a proposal (and > > > change in > > > priorities via ftpmasters) that is structured as follows: > > > > > > * Keep ifupdown[-ng] installed (Priority: important) as a fallback and for > > >existing installations > > >- Replacing ifupdown with ifupdown-ng, if reaching a drop-in compatible > > > state is feasible in time for Trixie (@Daniel, what's you stance on > > > this?) > > > > If we can find enough testers, yes. The implementation work still to be > > done is small enough. I would be happy to discuss plans to find those testers. Probably we need to fix https://github.com/ifupdown-ng/ifupdown-ng/issues/216 first anyway. > > >- bluca is requesting ifupdown[-ng] to be dropped from the default > > > installation for Forky, which is sensible, IMO. But we also want to > > > keep > > > it around for a transitioning period (in Trixie), so that people > > > relying > > > on specific if-up/down.d hooks are covered and have plenty of time to > > > migrate to new tooling > > > > NACK. I'm not going to do the work to get ifupdown-ng into shape for being > > the default just to have it removed again that's a ridiculous ask. > > > > That being said I realise that without Santiago's support as ifupdown > > maintainer I don't have much of a procedural leg to stand on in opposing > > this. > > It wasn't an ask, the intention was to have it only if feasible, with > acceptable > efforts. Keeping classic ifupdown maintained for a transitioning period in > Trixie > would be an option, too, IMO. That's why we started forming the new "Debian > Networking Team" after our BoF discussions in Busan, so we could bundle > resources > and help each other out with critical maintenance & have a common channel for > communications. Testing new/compat functionality in ifupdown-ng could > certainly > fall into the same category where the [networking team] could provide support. > > Sunsetting classic ifupdown earlier and having a drop-in compatible > ifupdown-ng >
Bug#1081171: ITP: kweathercore -- Library to facilitate retrieval of weather information
Package: wnpp Severity: wishlist Owner: Hefee X-Debbugs-Cc: debian-devel@lists.debian.org, debian-qt-...@lists.debian.org, he...@debian.org * Package name: kweathercore Version : 24.08.0 Upstream Contact: KDE Community * URL : https://invent.kde.org/libraries/kweathercore * License : LGPL-2+ Programming Lang: C++, QT Description : Library forretrieval of weather information Get weather forecast and alerts anywhere on the earth easy. It provides you a highly abstracted library for things related to weather. . Features: * Get local weather forecast. * Get weather of a location by name or coordinate. * Weather alerts of a country. The library is needed for KWeather, that I'll want packackage too and is actually the aim for packaging it. Actually more KDE software may start using it. KWeather is part of the plasma-mobile-desktop. It will be maintained by the Qt/KDE Debian team (debian-devel@lists.debian.org).
Bug#1081180: ITP: kweather -- Weather application for Plasma
Package: wnpp Severity: wishlist Owner: Hefee X-Debbugs-Cc: debian-devel@lists.debian.org, debian-qt-...@lists.debian.org, he...@debian.org Control: block -1 with 1081171 * Package name: kweather Version : 24.8.0 Upstream Contact: KDE Community * URL : https://invent.kde.org/utilities/kweather * License : GPL-2+ Programming Lang: C++, Qt, QML Description : Weather application for Plasma A convergent weather application for Plasma. Has flat and dynamic/animated views for showing dailiy or hourly forecasts and other information. KWeather is part of the plasma-mobile-desktop. It will be maintained by the Qt/KDE Debian team (debian-devel@lists.debian.org).
Re: Intent to MBF: move from fuse to fuse3
* László Böszörményi (GCS) [240829 20:55]: > On Sun, Aug 25, 2024 at 11:14 PM Chris Hofstaedtler wrote: > > Yeah, I agree. Do you want to upload a new src:fuse package dropping > > the fuse binary package? > > fuse3 already Provides: fuse, so that should be fine. > The question is, how many dependent packages use the binaries from > the fuse package or just depend on it. A handful. But given the Provides: and the compat symlinks, packages depending on fuse today do not need to change. > Sure, fuse3 provides fuse but > the names of the binaries are different. For example scripts need to > update fusermount call to fusermount3 call. fuse3 already provides the old names as symlinks. The options of fusermount <> fusermount3 and mount.fuse <> mount.fuse3 are the same. > As such, it might be > better to ping maintainers of those packages about dropping the fuse > binary for testing their packages first. Then after a month actually > drop it. > I was informed that debian-edu and grub-mount-udeb still use > fuse-udeb, but in Trixie packages I don't see that anymore. I can drop > that as well in a month. Yeah, this is resolved. > How do these sound there? I think you can drop both the udeb and the "fuse" package immediately. Chris
universal zcat ?
Dear Debian developpers, I ma looking for a wrapper around the various compressions programs (gzip, bzip2, xz, zstd, etc.) that would provide the same interface as zcat but would automatically pick the right decompressor. I could easily write one but it probably already exists. Cheers, -- Bill. Imagine a large red swirl here.
Re: universal zcat ?
Bill Allombert wrote: > Dear Debian developpers, > > I ma looking for a wrapper around the various compressions programs > (gzip, bzip2, xz, zstd, etc.) > that would provide the same interface as zcat but would automatically > pick the right decompressor. > > I could easily write one but it probably already exists. https://packages.debian.org/sid/zutils: > utilities for dealing with compressed files transparently > > Zutils is a collection of utilities for dealing with any combination > of compressed and non-compressed files transparently. Currently the > supported compressors are gzip, bzip2, lzip, xz, and zstd.
Bug#1081184: ITP: aprs-weather-submit -- Manually submit weather station data to the APRS-IS network.
Package: wnpp Severity: wishlist Owner: Colin Cogle X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: aprs-weather-submit Version : 1.7.1 Upstream Contact: Colin Cogle * URL : https://github.com/rhymeswithmogul/aprs-weather-submit * License : Affero GPL v3 (or later) -- see note below Programming Lang: C (C99 with GNU extensions) Description : Manually submit weather station data to the APRS-IS network. I'm the creator of aprs-weather-submit and I'd like to propose it be a part of the Debian repositories. Amateur radio operators use my app (particularly on the Raspberry Pi platform) to submit their own weather and location information via APRS-IS and broadcast it to the world. I created this app because I couldn't find anything out there quite like it. I have been maintaining this app for several years, and I have been writing free and open-source software in C (and other languages) for even longer. There are no dependencies beyond the standard C library. I currently release this as a Launchpad PPA, but I would like to move it into the repositories for the benefit and convenience of my users. I plan to maintain this myself, but I've never contributed to Debian before, so I would appreciate having a mentor to help me get started. Note that this app can be compiled for other operating systems besides Linux. In the source tarball is a library called "freegetopt" that is licensed under the MIT License. However, this is a dependency only used to build for DOS, and it is never linked, compiled, or included in any Linux builds (as Linux has native getopt_long() support). The Debian binaries would only contain my AGPLv3+-licensed code. OpenPGP_0xB9D51810CEFEEDFC.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: DEP5 and spdx shortname of license
Hello everybody, > On Sun, 08 Sep 2024 at 09:49:39 +0200, Niels Thykier wrote: > > Is it really that valuable for us to have a delta here compared to what > > upstream projects would use? If I remember well, one of the reason for the divergence was that we really wanted a system describing license exceptions, so that we do not need to quote near-identical versions of the GPL two or three times in the same copyright files. Fortunately, SPDX has adopted such a system in the meantime. With the current version of the machine-readable debian/copyright file, we can already use SPDX identifiers as long as they do not clash with the Debian ones, and I am not aware of such a case. But I see the value of deprecating the Debian ones and align on SPDX. For this to happen I think that we need 1) proof of consensus and 2) host the update somewhere. Using the debian-policy pakcage like for version 1.0 would acheive both. Using the DEP process might help (or not) for 1). Le Sun, Sep 08, 2024 at 12:07:16PM +0100, Simon McVittie a écrit : > > That, and MIT (SPDX) vs Expat (DEP-5) for one particularly popular member > of the MIT/X11 license family, as used in Expat and many other projects. About saying MIT instead of Expat, I fully [1] agree [2]. 1: https://lists.debian.org/debian-project/2010/08/msg00109.html 2: https://lists.debian.org/debian-project/2011/12/msg00034.html 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 -
