Re: RFC: advise against using Proton Mail for Debian work?
While I do think that PM generating a PGP key by default is a good thing. Even if they are compromised, it is still better than no encryption for the vast majority of user *as long as they are not used for something else*. The problem for us is that it is not possible to upload subkeys to PM, which allow to DM/DDs to create a subkey just for PM use. But even then I'm not aware on how to push a public key without that subkey to the Debian keyring, so maybe it doesn't matter. In any case, I don't think condemning the use of PM is justified here. Their software is open source and they are one of the only email provider that actually care about encryption. Yes, it doesn't work well with the Debian workflow, but that is not really their (nor our) fault. The percentage of people that just use mail on PM is probably significantly larger than those that also use their PGP mail to sign/encrypt other stuff like Debian packages. Cheers, Stephan
Re: debian/copyright format and SPDX
On Mon, Sep 25, 2023 at 7:15 AM Steve Langasek wrote: > > So can you tell me where in that specification this "flat text file" format > is actually described? The specification is not on the page that includes > this quote. The text does not link to the place in the spec where this > format is described. The site's search page (because it's reasonable for a > spec to require a server-side search engine in order for users to be able to > find information in it...) doesn't return any results for the string > 'tag:value', and a search for 'tag value' points first to > https://spdx.github.io/spdx-spec/v2.3/file-tags/ which > describes embedding tags in a source file, not constructing a tag:value > file. > > Frankly, the fact that the SPDX spec itself is as bad as it is should be > disqualifying for using any file format specified within. But I would still > be willing to give it a fair shake, if I could actually find it. E.g. here under examples? https://spdx.github.io/spdx-spec/v2.3/document-creation-information/ Cheers, Stephan
Re: debian/copyright format and SPDX
On Fri, Sep 22, 2023 at 11:11 AM Steve Langasek wrote: > > > SPDX defines an xml format only. They lost before they'd even started. > > debian/copyright is supposed to be human-readable first and foremost. XML > need not apply. Not true. From [1]: > Shall be in a human readable form. > [...] > Multiple serialization formats may be used to represent the information being > exchanged. Current supported formats include: > [...] > tag:value flat text file as described in this specification It's the same format that REUSE [2] uses. It is very much human readable, or at least as human readable as DEP5 (I don't think any human will ever read a DEP5 file with 200 lines of CC-BY-4.0 but that's besides the point). Cheers, Stephan [1]: https://spdx.github.io/spdx-spec/v2.3/conformance/#44-standard-data-format-requirements [2]: https://reuse.software/
Re: Bug#1052421: ITP: control -- Python Control Systems Library
Hi, please go with python-control for the source package name. This is required for consistency with https://repology.org/. Regards, Stephan On Fri, Sep 22, 2023 at 12:30 AM Kurva Prashanth wrote: > > On 2023-09-21 23:50, Christoph Biedl wrote: > > Kurva Prashanth wrote... > > > >> * Package name: control > >> Version : 0.9.4 > >> Upstream Author : >> > > >> * URL : http://python-control.org/ > > > > While I cannot judge whether this package is a sensible addition to > > Debian - I strongly ask you to re-consider the package name as "control" > > can apply to many different areas, and is therefore not helping when > > trying to figure if that package helps in a particular situation. > > Also, as there's the debian/control file in each source package, this > > will create some confusion and possibly even to users asking you for > > help with their packaging. > > > > Just from the above website, perhaps something like > > python-feedback-control-systems or a bit shorter variant would be more > > appropriate. I might be wrong. > > > > Christoph > I get what you're saying. Yes, "control" is a bit too general in deb > source packages. Your suggestion of "python-feedback-control-systems" > makes sense, and we'll I change package name. > > Regards, > Kurva Prashanth >
Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
I think it's a good idea now that dpkg supports it [1]. Ubuntu already did it years ago [2], and some non-deb based distros as well (e.g. Fedora, Arch). Cheers, Stephan [1]: https://bugs.debian.org/892664 [2]: https://balintreczey.hu/blog/hello-zstd-compressed-debs-in-ubuntu/
Bug#1030392: ITP: python-moddb -- python module to scrape the ModDB.com website
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-Cc: debian-devel@lists.debian.org, stephanlach...@debian.org * Package name: python-moddb Version : 0.8.1 Upstream Contact: Clement Julia * URL : https://github.com/ClementJ18/moddb/ * License : MIT Programming Lang: python Description : python module to scrape the ModDB.com website Dependency for upcoming lutris version. Will be maintained in Games Team.
Bug#1029969: ITP: clad -- automatic differentiation for C/C++
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-Cc: debian-devel@lists.debian.org, stephanlach...@debian.org * Package name: clad Version : 1.1 Upstream Contact: Vassil Vassilev * URL : https://github.com/vgvassilev/clad * License : LGPL-3.0 Programming Lang: C, C++ Description : automatic differentiation for C/C++ Clad enables automatic differentiation (AD) for C++. It is based on LLVM compiler infrastructure and is a plugin for Clang compiler. Clad is based on source code transformation. Given C++ source code of a mathematical function, it can automatically generate C++ code for computing derivatives of the function. It supports both forward-mode and reverse-mode AD. Clad has extensive coverage of modern C++ features and a robust fallback and recovery system in place. Will maintain in the science team. Feature for ROOT.
Bug#1028207: ITP: vkroots -- framework for writing Vulkan layers that takes all the complexity away
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-Cc: debian-devel@lists.debian.org, stephanlach...@debian.org * Package name: vkroots Version : git Upstream Contact: Joshua Ashton * URL : https://github.com/Joshua-Ashton/vkroots * License : Apache-2.0 OR MIT Programming Lang: C++ Description : framework for writing Vulkan layers that takes all the complexity away Required for latest gamescope. Will be maintained under the Games Team.
Re: debian/watch: Ignoring pre-release on GittHub
You can try to take a look at the GitHub API, e.g. [1]. Inside is an `prerelease` entry. Not sure how easy this is to implement in uscan though. Cheers, Stephan [1]: https://api.github.com/repos/lutris/lutris/releases?per_page=100
Re: Sunsetting sso.debian.org
On Mon, Oct 17, 2022 at 5:29 PM Sam Hartman wrote: > > I think the minimal solution here, which I'm not volunteering to do, is > for tracker.debian.org to gain salsa sso support instead of client cert > support. Can point out the tracker.d.o code? Maybe I'll take a look, I find this topic interesting (but I can't promising anything - short on time and never done stuff like this before). On Tue, Oct 18, 2022 at 4:53 AM Paul Wise wrote: > > On Mon, 2022-10-17 at 21:28 +0200, Joerg Jaspert wrote: > > > Salsa should be there for git (related) things. > > NOT as an identity/login provider for Debian > > There are already Debian services that do not offer any other option > for auth than Salsa. > > Personally I do not like GitLab, Salsa nor OIDC/Oauth2, vastly prefer > TLS client certs and thus usually never use Salsa authed services. > > Arguably it is probably a good thing to use Salsa, since it means > services can have an auth option for all of the Debian contributors, > including those who are not currently DDs or DMs. I think this more an argument against Salsa than one for it - just having a Salsa account does not really put you into any "box" except whether you are part of the Debian group or not. Having a "proper" SSO that connects to db.d.o and has proper groups such as DD, non-uploading DD, DM, etc is not a bad idea. Again, not saying that it is worth the effort. On Mon, Oct 17, 2022 at 2:04 PM Yadd wrote: > > Also lemonldap-ng, already packaged Cool, didn't know that one, thanks for pointing out. Do you by any chance know whether it supports client certs or not? Since it seems there are ppl prefering client certs, it would be nice to have an option that supports both.
Re: Sunsetting sso.debian.org
On Mon, Oct 17, 2022 at 11:57 AM Bastian Blank wrote: > > Everyone coming up with solutions, please review the old thread about > that > https://lists.debian.org/msgid-search/20200405184610.ga581...@waldi.eu.org Keycloak also provides OpenID Connect / OAuth2 and can connect to LDAP servers - so it is not really "intrusive" in that sense. For websites using the SSO the switch would probably just changing a URL, which of course opens the question what the advantage of Keycloak over the current Gitlab based solution would be. I guess Keycloak integrates better to LDAP and has more user management tools, but that doesn't mean the work is worth it. I just wanted to point out a solution in case we want a new SSO. Cheers, Stephan
Re: Sunsetting sso.debian.org
On Sun, Oct 16, 2022 at 7:23 PM Enrico Zini wrote: > > I would welcome better single sign-on systems for Debian than Salsa, and > sso.debian.org is not it. I think Keycloak [1] is quite nice and used more and more by other FOSS projects (it is RedHat sponsored after all). Opinions about using this as potential SSO? Can be easily integrated to Salsa/Gitlab as well (packaging might not be easy though). Cheers, Stephan [1]: https://www.keycloak.org/
Re: Q: uscan with GitHub
On Sun, Oct 9, 2022 at 7:06 PM Volans wrote: > > I've encountered the same problem and come out with a version of the watch > file using the GitHub APIs. In my case I also needed to download the PGP > signature. I've add some comments to the watch file for an easier > understanding. > > The approach should be generic enough to work for others [1]. > > The package name in the URL could also be replaced with @PACKAGE@ if that's > the same of the GitHub project name. > In my case too, tags are prefixed with a 'v' (i.e. v1.2.3), but that's easily > adaptable to different formats. > > What is the process to find an agreement on which updated version should be > published on the wiki [2] ? I mentioned it before, one should increase the limit of results per page to the maximum (which is 100). Also I don't think using `@PACKAGE@` is a good idea inside the URL as it is maybe different from the Debian source package name. For releases I use something like (w/o signatures): ``` version=4 opts="searchmode=plain,\ filenamemangle=s%v?@ANY_VERSION@%@PACKAGE@-$1.tar.gz%" \ https://api.github.com/repos///releases?per_page=100 \ https://api.github.com/repos/[^/]+/[^/]+/tarball/v?@ANY_VERSION@ ``` For tags: ``` version=4 opts="searchmode=plain,\ filenamemangle=s%v?@ANY_VERSION@%@PACKAGE@-$1.tar.gz%" \ https://api.github.com/repos///tags?per_page=100 \ https://api.github.com/repos/[^/]+/[^/]+/tarball/refs/tags/v?@ANY_VERSION@ ``` One could probably combine the tarball search link into a unified regex expression, didn't try that yet. Overall I agree that the Github API thing should be documented in the Wiki and in the uscan man page. Cheers, Stephan
Re: Q: uscan with GitHub
On Tue, Sep 20, 2022 at 10:36 AM Samuel Henrique wrote: > On Tue 20 Sept 2022, 01:39 Paul Wise, wrote: > > On Mon, 2022-09-19 at 18:54 +0200, Andrea Pappacoda wrote: > > > Hi, what I usually do with GitHub is to use its API, since it has the > > advantage of not breaking uscan when they do changes to the web UI. > > Since the API uses pagination, this has the minor downside of making it > harder to use the uscan --download-version option with older versions. > > > The GitHub pages are also paginated, so you get the same issue whether > using the API or not. > There is a per_page parameter: https://docs.github.com/en/rest/releases/releases#list-releases E.g. https://api.github.com/repos/torvalds/linux/tags?per_page=100 The maximum is 100 though. Cheers, Stephan
Bug#1016347: ITP: cppzmq -- C++ bindings for libzmq (headers)
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-Cc: debian-devel@lists.debian.org, stephanlach...@debian.org, gor...@chronitis.net, g...@debian.org * Package name: cppzmq Version : 4.8.1 Upstream Author : Gudmundur Adalsteinsson * URL : https://github.com/zeromq/cppzmq * License : MIT Programming Lang: C++ Description : C++ bindings for libzmq (headers) This package constains the default C++ headers for libzmq. The two headers (zmq.hpp and zmq_addon.hpp) are currently already contained in libzmq3-dev (src:zeromq3). However, the package does not provide the CMake packaging scripts. Also, there is a pending pull request to add a pkg-config file, so it makes sense to split this into a separate package. There was already an discussion to separate the headers in #972785 [2], but nothing happened from there. The packaging is done at https://salsa.debian.org/debian/cppzmq. [1]: https://github.com/zeromq/cppzmq/pull/564 [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972785
Bug#1010638: ITP: gnome-shell-extension-proxy-switcher -- Gnome Shell Extension to switch the proxy mode
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-Cc: debian-devel@lists.debian.org, stephanlach...@debian.org, pkg-gnome-maintain...@lists.alioth.debian.org * Package name: gnome-shell-extension-proxy-switcher Version : 1.5.1 Upstream Author : Tom Flannaghan * URL : https://github.com/tomflannaghan/proxy-switcher * License : GPL-2.0 Programming Lang: JavaScript Description : Gnome Shell Extension to switch the proxy mode The title pretty much says it all. If wanted I would maintain it the Debian GNOME Maintainers team. Cheers, Stephan
Re: isa-support -- exit strategy?
On Sat, Mar 26, 2022 at 2:36 AM M. Zhou wrote: > > Indeed supporting number crunching programs on ancient > hardware is not meaningful, but the demand on Debian's > support for number crunching is not that strong according > to my years of observation. > > For popular applications that can take advantage of above-baseline > instruction sets, they will eventually write the dynamic code > dispatcher and add the fallback. > > For applications seriously need performance, they will > leave CPU and go to GPU or other hardware. If the user correctly > write the code and fully leverage GPU, the non-optimal CPU > code won't necessarily be a bottleneck. > > For applications seriously need CPU performance, they are > possibly going to tell the users how to tweak compiling > parameters and how to compile locally. I have to disagree on this one. Yes, runtime detection and GPU acceleration is great and all, but not every scientific library does it and I think it's unrealistic for us to patch them all up. Also I don't like the point "since there is low demand for number crunching on Debian, so let's just continue to ignore this problem". At least I know a decent amount of people that use Debian (or downstream distros) for scientific number crunching. Compiling optimized for large workloads will always be a thing no matter the baseline, but when getting started distro packages are just one less thing to care about. On Sat, Mar 26, 2022 at 7:25 AM Andrey Rahmatullin wrote: > > A partial arch (whatever that is, yeah) with the x86-64-v3 baseline, and > optionally raise the main amd64 baseline to x86-64-v2? +1
Re: Bug#1007970: ITP: cloudflare-ddns -- dynamically update a DNS record using Cloudflare
Hi Andrea, This sounds really cool and useful to have in Debian! Do you need a sponsor? If so, I would be willing to sponsor it. Regards, Stephan On Sat, Mar 19, 2022 at 8:09 PM Andrea Pappacoda wrote: > > Package: wnpp > Severity: wishlist > Owner: Andrea Pappacoda > X-Debbugs-Cc: debian-devel@lists.debian.org > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > * Package name: cloudflare-ddns > Version : 1.0.0 > Upstream Author : Andrea Pappacoda > * URL : https://github.com/Tachi107/cloudflare-ddns > * License : AGPL-3.0-or-later OR LGPL-3.0-or-later > Programming Lang: C++ > Description : dynamically update a DNS record using Cloudflare > > This is a little program that is really useful when you want to host something > but your ISP only provides you a dynamic IP address. It uses Cloudflare's API > to update a given DNS record when needed. It is a simple script, so to run it > periodically you can configure a cron job or a systemd timer (provided > upstream). > > It is written in C++, performs a low number of memory allocations, and is > really lightweight, making it a valid choice for constrained environments. > > It also provides a C API, so that third party programs can embed its > functionalities. > > The library portion of the project is licensed under the LGPL 3, while > everything else is under the AGPL 3. > > I couldn't find any alternative in the Debian archive, and while there are > some > other open source alternatives out there they are mostly written in more > resource-intensive languages and/or are harder to deploy for simple use cases. > And also because I'm the one who wrote this :D > > > -BEGIN PGP SIGNATURE- > > iIoEARYIADIWIQSlw/BqXszDGx3GlQz/yQfijUdG7QUCYjYplRQcYW5kcmVhQHBh > cHBhY29kYS5pdAAKCRD/yQfijUdG7T7cAQCTCY67bva7wnXpVjKrixLVsWeOy/cU > orsLD1f6BauB8wD/Rbs4w72xiM46pcQLMBkd0YivhGs9hshRqKk64eTqUwg= > =3xxd > -END PGP SIGNATURE- >
Re: Gmail bounce unauthenticated @debian.org addresses
On Fri, Mar 4, 2022 at 12:47 PM Baptiste Beauplat wrote: > > My debian address is also affected, and probably others that did not > setup DKIM for their @debian.org address. > > As a reminder debian.org addresses does support DKIM. After > configuration on your mail server, you can publish your DKIM public key > to db.debian.org [1][2]. Can you point to some quick guide on how to do this for gmail? The support page seems kinda confusing to me. Regards, Stephan
Bug#1005875: ITP: python-headerparser -- Python module to parse key-value pairs in the style of RFC 822 headers
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-Cc: debian-devel@lists.debian.org, stephanlach...@debian.org * Package name: python-headerparser Version : 0.4.0 Upstream Author : John T. Wodder II * URL : https://github.com/jwodder/headerparser * License : MIT Programming Lang: Python Description : Python module to parse key-value pairs in the style of RFC 822 headers I intend this maintain this in the Debian Python Team. I will use this library for my ongoing work to convert SPDX documents to DEP5 documents [1]. The reason I won't use python-debian is that it is apparently a bit buggy on non-Debian systems. Regards, Stephan [1] https://lists.debian.org/debian-devel/2022/02/msg00207.html The long description from the readme: headerparser parses key-value pairs in the style of RFC 822 (e-mail) headers and converts them into case-insensitive dictionaries with the trailing message body (if any) attached. Fields can be converted to other types, marked required, or given default values using an API based on the standard library’s argparse module. (Everyone loves argparse, right?) Low-level functions for just scanning header fields (breaking them into sequences of key-value pairs without any further processing) are also included. RFC 822-style headers are header fields that follow the general format of e-mail headers as specified by RFC 822 and friends: each field is a line of the form “Name: Value”, with long values continued onto multiple lines (“folded”) by indenting the extra lines. A blank line marks the end of the header section and the beginning of the message body. This basic grammar has been used by numerous textual formats besides e-mail, including but not limited to: HTTP request & response headers Usenet messages most Python packaging metadata files Debian packaging control files META-INF/MANIFEST.MF files in Java JARs a subset of the YAML serialization format - all of which this package can parse.
Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5
FYI, I started working on a SPDX->DEP5 and DEP5->SPDX converter tool, the code (or rather a basic concept) is here [1]. My goal is to produce an internal representation that collects copyright information on a per-file basis, and convert between SPDX/DEP5 and this format. Regards, Stephan [1] https://github.com/stephanlachnit/dep5convert
Re: write-only copyright information
On Thu, Feb 10, 2022 at 2:10 PM Simon McVittie wrote: > > On Thu, 10 Feb 2022 at 11:59:11 +0100, Stephan Lachnit wrote: > > No, you don't have to master SPDX! That's the point: you don't > > interact with it at all. It's created by tools, and shipped to satisfy > > the legal obligation to provide copyright information. > > So, are you saying this is something you are doing to satisfy the "letter > of the law" for licenses that require copyright notices to be reproduced > alongside binaries, to avoid having that noise reduce the clarity of the > information we are providing for other, arguably more useful reasons? I think I don't fully get the question, but yes, essentially this would be a write-only format that I expect no human to read. Users don't care about it and it's more than enough from the legal side. Regards, Stephan
Re: developers-reference "vs" wiki.debian.org/DebianMaintainer
On Thu, Feb 10, 2022 at 12:49 PM Holger Levsen wrote: > > So what do you all think? > > I'm leaning towards explaining the basics in devref (mostly by copying bits > from the wiki page) and adding a pointer to the wiki page, but if there's > consensus that the wiki page is supposed to be made obsolete by *moving* > the contents to src:devref and leaving a pointer on the wiki page, I could > also do that. As already mentioned on IRC, I think in this case I would move the information for the DDs to the devref and reference it on the wiki with "if you are a DD, see also section X in devref". Currently when I search something related to general DD tasks I first look in the devref and not in the wiki. In particular most of the DebianMaintainer wiki page is for those wanting to become a DM, I only found the granting permissions section after looking a second time. In general I would put information specific for people who are already DDs in the devref written with the assumption that everyone who reads it is a DD. The wiki on the other hand is more "public facing", so I would put here more introductory content (like "what can I do as a DM" and "how I can become a DM"). Regards, Stephan
Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5
On Tue, Feb 8, 2022 at 8:45 PM Russ Allbery wrote: > > I recommend thinking about how to generate an existing debian/copyright > file and putting the SPDX-formatted one in a different location. You're > going to want to decouple the new work from any transition that requires > other people change tools. There are a lot of tools that make assumptions > about debian/copyright, and trying to track them all down will be > counterproductive for trying to make forward progress on exposing > information in a more interoperable format. > > The way I see this, there are three different things that have been > discussed on this thread: > > 1. Consuming upstream data in SPDX or REUSE format and automating the >generation of required Debian files using it. > > 2. Exposing SPDX data for our packages for downstream consumption. > > 3. Aligning the standard way to present Debian copyright information with >other standards. > > I can tell you from prior experience with DEP-5 that 3 is wildly > controversial and will produce the most pushback. There are a lot of > packagers who flatly refuse to even use the DEP-5 format, and (pace > Jonas's aspirations) I don't expect that to change any time soon. > > I think that's fine for what you're trying to accomplish, because I think > 1 and 2 are where the biggest improvements can be found. As long as your > system for managing copyright and license information can spit out a DEP-5 > debian/copyright file (in its current or a minorly modified format, not > with new files elsewhere that would have to be extracted from the > package), you are then backward-compatible with the existing system and > that takes 3 largely off the table (which is what you want). Then you can > demonstrate the advantages of the new system and people can choose to be > convinced by those advantages or not, similar to DEP-5, and we can reach > an organic consensus without anyone feeling like they're forced to change > how they do things. Thanks for this input, Russ! I think you're right: it will be easier to output the DEP5 format in addition to SPDX at the beginning, and see from there how it works. I would install the source SPDX document then to /usr/share/doc/PACKAGE/copyright_spdx in addition to the DEP5 file in the usual place. I will write a SPDX -> DEP5 tool for this, which should be "fairly trivial". Regarding concerns about the different file formats SPDX can come in: for us only the tag:value format makes sense, I don't want to support other formats. On Tue, Feb 8, 2022 at 8:36 PM Jonas Smedegaard wrote: > > For starters, the format adds one SHA1 hash per source file, right? Yes, one checksum per file. > Sure I can "just" ignore all FileChecksum: lines, but anyone working > with XML will know that plaintext does not equal human-readable. This comparison is a bit off, XML is a representation. The SPDX format I want to use is tag:value just like DEP5, so in this regard "human-readable". There is more cruft content, but it takes less than 5 minutes to understand where the per file copyright and license information is. > > However, I also think the human-readable aspect is less important here > > because it is an output format. What I mean with this is that the > > information is already there in a human readable way: either via REUSE > > or in the file headers directly. While it is theoretically possible to > > write SPDX documents by hand, I would not treat them with the same > > trust as one created by REUSE. > > Here you seem to assume that humans need not be involved in authoring > the contents or at least that human-facing interfaces for smart tools > exist and is expressive enough to cover all that is needed. > > That is quite an assumption, I dare say. I think this is a misconception: I don't want people to write SPDX documents by hand at all. IMHO for this scenario, DEP5 is still superior (that's e.g. why REUSE can also use DEP5). > Writing the debian/copyright file for ghostscript took quite some time. > Singularity is imminent, I know, and I wouldn't mind machines taking > over the task of classifying tights statements, when they are up to the > task - but until then I will want to proof-read and intervene as needed. > My own experience is that they are not yet there - you seem to claim > they have already surpassed humans for this task... > > Can you show me (off list if too long for an attachment) how your new > not-really-needing-manual-editing file for ghostscript looks like, so I > can compare with my lesser trusted human-laboured product? No, because if ghostscript doesn't have the information to automatically generate a SPDX document, don't do it by hand, use DEP5 instead. What you can do is to put your DEP5 in .reuse/dep5 in the top-level dir and run "reuse spdx" if you want to see how it looks. > > Regarding reviews: I plan to write a SPDX-to-DEP5 converter anyway to > > get a better feel for the spec. I will probably also write a copyright > > review
Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5
The easy solution would just be allow both. Either only a single file with verbatim text or an SPDX document with licenses in a separate folder. Regards, Stephan On Tue, 8 Feb 2022, 19:12 Scott Kitterman, wrote: > On Tuesday, February 8, 2022 12:53:22 PM EST Stephan Lachnit wrote: > > On Tue, Feb 8, 2022 at 5:00 PM Scott Kitterman > wrote: > > > Since Debian policy requires verbatim copies of licenses (or links to > > > /usr/ > > > share/common-licenses), I think any policy compliant debian/copyright > will > > > have to be human readable, but I'm not that familiar with SPDX, so > maybe > > > it > > > will surprise me. > > > > You can find an example in my initial mail [1]. > > > > > I would be good to understand how this proposal supports Debian Policy. > > > > It would require a minor change: putting the verbatim license texts in > > a single file is not possible anymore. But I don't why just copying > > the licenses to "/usr/share/doc/PACKAGE/licenses/LICENSE" in addition > > to the SPDX formatted debian/copyright would be any worse than the > > current way. > > > > > > Regards, > > Stephan > > > > [1] https://lists.debian.org/debian-devel/2022/01/msg00309.html > > Personally, I don't view that as a minor change. > > I think before starting a DEP on this you ought to work out the policy > implications. Currently any package using your proposed approach would be > instantly RC buggy. > > Scott K
Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5
Hi Jonas, On Tue, Feb 8, 2022 at 4:39 PM Jonas Smedegaard wrote: > > I am sceptical towards this proposal. > > An important feature to me with current machine-readable format is that > really it is machine-and-human-readable. Thank you for your input! I'm aware of this concern, however I think it is not something that can't be solved. For one, while not as trivial to under as the current machine-readable copyright, it's still "human-readable" (i.e. a tag:value style text file). I would do the following comparison: if you only know Python (DEP-5), C++ (SPDX) might look a bit weird, but you can get the gist of it. However, I also think the human-readable aspect is less important here because it is an output format. What I mean with this is that the information is already there in a human readable way: either via REUSE or in the file headers directly. While it is theoretically possible to write SPDX documents by hand, I would not treat them with the same trust as one created by REUSE. > Another important feature to me is that there is only one format (in > addition to unformatted content, which hopefully we can put past us at > some point). > > Today, I can as DD help proof-read and change *any* package in Debian. Regarding reviews: I plan to write a SPDX-to-DEP5 converter anyway to get a better feel for the spec. I will probably also write a copyright review tool that will show you the copyright header of each file based on DEP5 or SPDX information for validation / manual review. This will make proof-reading copyright information much easier. But to stress this again: the goal is to *replace* the manual copyright reviews by something much better: automatic copyright reviews. There are three areas of interest for copyright information: a) for developers writing it b) for the user receiving it and c) the legal side. Regarding a: From hand DEP5 is better, but for automation SPDX is equally good. Regarding b: I think they don't care anyway. Like which user reads the debian/copyright really? If at all, you are interested in the copyright of a certain library you wish to use, but this doesn't require the extensive file-by-file information of DEP5. Most likely the documentation provides much clearer information. Regarding c: SPDX is as good as DEP5 if not even better due to file hashes. > If we permit a debian/copyright format that is not human-readable, it > means that I cannot confidently proof-read and change the contents of > the debian subdir without the help of machine-parsers, and I would need > to know two formats with different goals.> I don't see the problem with machine parsers. We already use a lot of different tools for our processes (git, dput, dpkg, debhelper, lintian, uscan, a mail program, a text editor, ...), adding one more shouldn't be a big deal. It needs to be provided of course, but I plan to do that. > I would like to instead welcome the REUSE developers in helping Debian > evolve next version of the existing machine-readable format to better > align with SPDX. While this would be nice, I think this is just unrealistic. While I may implement DEP5 output to REUSE, I still want to use SPDX because it is already an existing industry standard having all the "features" we want. Adding things like file hashes and referencing / merging other DEP5 documents is certainly possible, it would make the format less readable and in the end just SPDX looking differently. On Tue, Feb 8, 2022 at 5:00 PM Scott Kitterman wrote: > > Since Debian policy requires verbatim copies of licenses (or links to /usr/ > share/common-licenses), I think any policy compliant debian/copyright will > have to be human readable, but I'm not that familiar with SPDX, so maybe it > will surprise me. You can find an example in my initial mail [1]. > I would be good to understand how this proposal supports Debian Policy. It would require a minor change: putting the verbatim license texts in a single file is not possible anymore. But I don't why just copying the licenses to "/usr/share/doc/PACKAGE/licenses/LICENSE" in addition to the SPDX formatted debian/copyright would be any worse than the current way. Regards, Stephan [1] https://lists.debian.org/debian-devel/2022/01/msg00309.html
Legal advice regarding the NEW queue
On Mon, Jan 31, 2022 at 10:47 AM Jonathan Carter wrote: > > As for getting legal advice, we do have an existing contract with Aaron > K. Williamson of Williamson Legal, PLLC (https://www.akwlc.com/). His > specialty is Open Source softwware, technology, licensing and contracts, > so he would be a good person to ask specific questions about this, and > since we have an existing contract with him, it's really easy to set up > a video call / email thread with him if anyone wants to get some advice > from him. So if anyone has some time / energy to put together some > concrete questions / examples (and ideally also recruit one or more > people from FTP team to be involved), then I'd be happy to do the > introductions and set that up. Thanks for this information, Jonathan. I would volunteer for gathering and formulating questions and asking them to Aaron Williamson. I suggest the best would be to start with an IRC or video call session for everyone interested to formulate a "call for questions to ask", looking through the questions and formulating a document we can send to Aaron Williamson. Then we can discuss the question in a video call, and again formulate a document with the answers from Aaron Williamson. The next step would then probably be a GR. However I am currently in my exam phase until February 14th, but after this I have quite a lot of time. Regards, Stephan
Re: Do we need to hide packages in NEW queue
On Sun, Jan 30, 2022 at 8:35 PM Russ Allbery wrote: > > I do think that the amount of effort that the project puts into this > pre-screening is of sufficiently high magnitude that it would be worth > paying a lawyer for a legal opinion about whether or not we need to do > it. The savings to the project if we found out that we didn't, or that we > could do something simpler and more easily automated, would be more than > the cost of the legal opinion. +1 Looking at the last financial numbers I found [1], we have at least ~750k USD we could use for this purpose. I don't really know how expensive lawyers are, but I doubt that this would cost more than 10k. Heck, we could even hire two lawyers without any significant financial impact (maybe in the US and EU as I think these are probably the most prominent areas for potential copyright lawsuits), even if it costs 50k. IMHO that would be totally worth it. And instead of investing scarce man-hours into pre-screening, we could create a money pool for financial support in case there is a copyright lawsuit. The pre-screening in NEW doesn't prevent someone from claiming copyright infringement anyway, there is just a smaller chance that the lawsuit is justified. But sadly even winning a lawsuit can still cost a significant amount of money. If I compare how other mediums handle copyright violations, most services have a "file a claim infringed copyright here" button on their site (e.g. YouTube). For example, we could write a DMCA policy like e.g. Github [2], hyperlink in the footer of all our official websites, make a small "debian-dmca" tool that is always available in our builds to file claims and provide infrastructure to process such claims. I highly doubt that anyone will ever directly start a lawsuit instead of sending a cease-and-desist letter first, I'm not even sure if it is legal to start a lawsuit without doing this first. IANAL of course, but that's why we should actually pay one. If we just keep discussing and amending "IANAL" to our messages we won't fix any of our problems. And of course in addition to paying a lawyer, we should ask what other distros do (especially Ubuntu, SUSE and RedHat as they are from large companies with a legal department). Regards, Stephan [1] https://lists.debian.org/debian-devel-announce/2021/08/msg5.html [2] https://docs.github.com/en/github/site-policy/dmca-takedown-policy
Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5
On Fri, Jan 28, 2022 at 9:42 AM Phil Morrell wrote: > > On Thu, Jan 27, 2022 at 11:27:45AM +0100, Stephan Lachnit wrote: > > On Thu, Jan 27, 2022 at 12:39 AM Phil Morrell wrote: > > > > > > TLDR: I think REUSE.software is a bad idea that is worse than what > > > Debian already invented with Machine-readable debian/copyright file. I > > > guess if upstream uses it, there's no reason not to ignore that as a > > > source of copyright assertions. > > > > I expected some concerns about the complexity of the SPDX document, > > but certainly not about standardized copyright information in source > > files. > > > > Yes, Debian may have invented the machine-readable copyright bill, but > > not machine-readable copyright information in source files. > > Erm, no that's not what I'm saying? I'll requote my agreement with > > > > I *am* a big fan of SPDX-License-Identifier Yes I saw that line, but you also wrote > TLDR: I think REUSE.software is a bad idea I apologize for the misunderstanding. Maybe next time write something like "While I am a big fan of copyright information in source files, I find certain aspects of REUSE bad". Because there may be valid concerns about the spec, however this is not really relevant for my proposal: It's mainly about allowing a different copyright format than [DEP-5 style], which _can_ be created automatically via REUSE. > I will admit I'm somewhat skeptical in how often file-level copies > happen these days, rather than folder-level or whole project forks. But > it's easy enough to convince people to slap a single-line license > comment in to avoid ambiguity. Obviously we as Debian are not a big fan of file-level copies anyways, but let's just say that REUSE wasn't written just for Debian. There are enough industry projects that use tons of imported code whether we like it or not, but it's certainly better with standardized copyright information than without. > > what REUSE is all about, and it greatly reduces manual labor - I don't > > understand how this can be seen as bad. > > Because being REUSE-compliant IMO greatly *increases* manual labor as > soon as you're dealing with non-text forms, multiple authors and > aggregation of differing copyright assertions. These are all things that > the debian copyright-format has already solved without (as much) manual > busywork, so if upstream is agreeable to formally documenting their > copyrights, I'd much rather they just used that format in LICENSE. But it does not increase the manual labor for us! It actually decreases our work, that's what this is all about! The main point of my proposal: we, as package maintainers, don't have to do the bulk work anymore, upstream does it. We can just use this information which we would have done by hand otherwise. This is not about pushing REUSE to upstream projects from our side at all, but rather using it downstream to decrease manual labor if it already exists upstream. > > Yes it is called "Machine-readable debian/copyright file Version 1.0", > > but everybody knows it _is_ DEP-5, it is even in the spec in the > > second sentence of the abstract. > > Sure, and that's fine as a colloquialism, but you haven't addressed my > objection to REUSE formalising that as part of the spec. If you look at [1]: > Definitions > [...] > DEP5 — Machine-readable debian/copyright file, Version 1.0. Where the REUSE > Specification and DEP5 state different things, the REUSE Specification takes > precedence. Specifically in the case of the Copyright and License tags. And they link to the proper spec, so it is nothing but an abbreviation. > > The spec _is_ still DEP-5, being accepted doesn't change that. > > Sure it does, compare `#files-field` in both specs, from 2019 policy > upgrading checklist 4.4.1. Perhaps that change should have bumped a > version number, but it's a bit late now. Oh, thanks, I didn't know that! > That has not been my experience for projects without a long history, > they tend to not care about copyright initially, slap a generic > assertion on it at some point, but without noticing they've included > e.g. an embedded copy of zlib or less formally - used an image with a > vague gratis use but omitting a formal license. > > It's only either later, or from the ITP scrutiny that some confusion > over pedigree comes to light, someone fires off an email to an early > contributor and gets the accurate license information. Or for Debian, > the path gets added to Files-Excluded and patched out of compilation. Yes, surely copyright assertion mistakes happen from time to time. But these can happen everywhere, whether they slap a generic assertion on it or not. Just using the information REUSE provides doesn't mean th
Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5
On Thu, Jan 27, 2022 at 12:39 AM Phil Morrell wrote: > > TLDR: I think REUSE.software is a bad idea that is worse than what > Debian already invented with Machine-readable debian/copyright file. I > guess if upstream uses it, there's no reason not to ignore that as a > source of copyright assertions. I expected some concerns about the complexity of the SPDX document, but certainly not about standardized copyright information in source files. Yes, Debian may have invented the machine-readable copyright bill, but not machine-readable copyright information in source files. This is what REUSE is all about, and it greatly reduces manual labor - I don't understand how this can be seen as bad. On Thu, Jan 27, 2022 at 12:39 AM Phil Morrell wrote: > > I *am* a big fan of SPDX-License-Identifier, but the above being > straightforward is only true for the most trivial of examples. REUSE > advocate for sprinkling .license files around your repo for e.g. logos > and other binaries. Same story with multiple authors, they recommend > using multiple FileCopyrightText's initially, then split it out to a > separate AUTHORS file and use something like "Project X contributors". No, it does not only work for trivial examples. Take any project with a significant amount of code, e.g. [1], and most of the time you will find that every source file has the copyright information in the header. The problem is, there has been no standardized way to parse them. That's why we have tools like licensecheck that try to find it out. With REUSE, it gets much much easier. Wrt to the .license files: yes they're ugly, but still better than no automation at all. With the new yaml spec, I suspect that these will go away. Wrt to multiple authors: this is not the fault of REUSE, but just how copyright works. > Ultimately, when everything becomes too much, REUSE falls back to > recommending Debian's copyright format anyway! So even if upstream sees > the value in taking some copyright busywork off our hands, why not > suggest they just use it in the first place in e.g. the LICENSE file. Sight, yes, because Debian's format is afaik the only standardized, easy to parse format out there. But the reason why it is there is *not* for "when everything becomes", but for files that you cannot and don't want to alter. For example, if you regularly import 3rd-party code that does not follow REUSE and you don't want to edit the header all the time. Note that if everyone would use REUSE, that would not be a problem. Another example is when you have tiny example code or configs that you want to present to a user, but without any distracting comments (think beginner tutorials). However, they want to switch from DEP-5 to a more flexible (i.e. non-central, relocatable) spec [2]. And there is good reason to do so: for example we as Debian can specify the copyright information from our packaging separate from the upstream code, without conflict. DEP-5 does not allow that. > Firstly, I didn't think it was called DEP-5 anymore - it was accepted > into policy in 2012 as "copyright-format" titled "Machine-readable > debian/copyright file", so no longer a proposal for enhancement. This > would be a minor pedantic point (a colloquialism) except for the fact > that REUSE encourages it as part of their interface: `.reuse/dep5`. Yes it is called "Machine-readable debian/copyright file Version 1.0", but everybody knows it _is_ DEP-5, it is even in the spec in the second sentence of the abstract. The spec _is_ still DEP-5, being accepted doesn't change that. > I think this undermines your previous point about it being less prone to > failure - if we could trust upstream assertions on copyright, the NEW > review wouldn't be a problem in the first place. I strongly disagree. First of all, upstream knows way better where they copy the code from than packagers do. And projects that use REUSE are more likely to write that somewhere down as your average NPM package that puts a "under MIT license" in the readme and copies minified code from everywhere. And as a second point, if you write a debian/copyright, you are most likely to trust what is in the header, and I suspect the copyright review in NEW is not different from this regard. I mean how can one even know if the copyright information is wrong? Yes there are cases where copyright information is missing and one can try to search it, I've done this not just once, but if a project uses REUSE headers, this doesn't happen. Regards, Stephan [1] https://gitlab.cern.ch/geant4/geant4 [2] https://github.com/fsfe/reuse-docs/issues/81
Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5
On Wed, Jan 26, 2022 at 1:59 PM Max Mehl wrote: > > FWIW, as you may have already noticed, REUSE makes use of DEP-5 as well, > as one (and honestly the least preferred) of the three ways how you can > label your files. We have a better file-based format in the works [^3], > and would probably also provide a converter from DEP-5 to this new > REUSE.yaml format. > > That would mean that the REUSE helper tool in the future could take > DEP-5 files, convert them to the modern format, and run a lint to check > whether everything is fine – and if you want, also generate a SBOM. > > But already now, a DEP-5 file could be provided to REUSE. One would have > to check whether the ones Debian provides would work in the default > location for DEP-5 files in REUSE (`.reuse/dep5`). If not, I suspect > there would be no large changes needed. Probably too technical at this stage, but a conversion tool in combination with the yaml format could actually be quite useful. E.g. one could have a debian/REUSE.yaml sub-file for the copyright information of the package build files and a debian/REUSE-source.yaml file in case the source does not follow the REUSE spec. If the reuse-tool would have an option to specify a different file for the root REUSE.yaml, we could actually use it for all packages with relatively low migration work on the maintainer side. Regards, Stephan
Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not
On Wed, Jan 26, 2022 at 11:43 AM Adam Borowski wrote: > > On Tue, Jan 25, 2022 at 09:38:01PM +0100, Vincent Bernat wrote: > > > > I think we should forego the NEW queue. If people want to check > > packages, they can do it once they are in unstable with regular bugs. > > Without the NEW queue, there would be no point at which packaging receives > any sort of review. I'd prefer Debian to deliver at least some level of > quality. > > Otherwise, we'd fall to the level of NPM. And there's ample examples what > that would mean. I disagree with the comparison to NPM. Simply because not everyone can upload - you have to be DD or DM to do that, which means you have to go through a non-trivial process where it is checked that you know what you do. As of right now, a malicious acting DD can already upload harmful packages without NEW stopping this at all. Regards, Stephan
Automated copyright reviews using REUSE/SPDX as alternative to DEP-5
d: 2022-01-26T10:42:59Z CreatorComment: This document was created automatically using available reuse information consistent with REUSE. Relationship: SPDXRef-DOCUMENT describes SPDXRef-3c8056cd1f4f60322830f1e79d55ea13 FileName: ./update_copyright_years.py SPDXID: SPDXRef-3c8056cd1f4f60322830f1e79d55ea13 FileChecksum: SHA1: 65fc75079eb9d85953b39c6fb832e86c7b7e113a LicenseConcluded: NOASSERTION LicenseInfoInFile: MIT FileCopyrightText: SPDX-FileCopyrightText: 2022 Stephan Lachnit """
Re: Back to the topic of changed binary named (Was: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not))
On Mon, Jan 24, 2022 at 8:15 AM Andreas Tille wrote: > > However, my point was that I want to know what policy ftpmaster applies > to new binary names and to focus on this topic. I really want to know > that policy of ftpmaster and I really would like to see that documented > and I'm afraid that thread is drifting away from the original topic > that I will not get any answer on this. > > So again: I see a conflict in my interpretation of the mail[1] (original > posters again in CC) which suggests "an auto-approver" and what I'm > currently observing and I would be really happy if we can document the > policy for changed (and new) binary names of existing source packages. Since I feel my mail went lost in the discussion, here again my opinion: Option C. New binary packages where the src is already in Debian can still go through NEW for sanity checks, but do not require a d/copyright review. These packages should be checked with priority since they should be quick to review. Same goes for source packages renames. Instead, I suggest starting a "d/copyright review lottery" working group with the goal to review the d/copyright of every package in testing if changed since the last stable release, especially before the next stable release. I would personally join this endeavor and help to write tools to keep track of which packages are "eligible" for the lottery. This offloads a lot of work from the ftp-masters and in making regular d/copyright reviews for all packages split among project members should also increase the quality of these. On Mon, Jan 24, 2022 at 8:15 AM Andreas Tille wrote: > > To give another example which has nothing todo with ABI changes: > Currently I'm afraid of splitting some Arch: all data from some > Arch: any package since I'm simply afraid of the changed package > sticking long in new queue. I know this is bad - but I consider > users waiting for package updates worse. On Mon, Jan 24, 2022 at 7:49 PM Theodore Y. Ts'o wrote: > > As far as I know, ftpmaster requires a long, laborious review every > single time there is a new binary package released. As a result, it > strongly disincentivizes maintainers from packaging up new releases > because it's a pain in the posterior. A while back, people asked me I > could update f2fs-tools, and it was shortly before the release freeze, > and even though there was apparently security fixes involved that > would be fixed in the latest version of f2fs-tools, I knew there would > be no point, since there was no way the package would squirt out the > review pipeline before the release freeze. > > Even if it isn't formal policy, the long delay has happened enough > times that I just assume it will be there, and it influences my > behavior accordingly. These are just two examples where the delay of updates in the NEW queue affects the quality of a package or a Debian release - while it should do the opposite. I'm sure there are many more, I'm not a DD for a long time but I heard the "won't make improvement xyz because of the NEW queue" argument regularly. IMHO if there is not a sudden increase of review time from the ftp-masters, something needs to be done before packages start losing quality due to NEW. Regards, Stephan
Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not
On Fri, Jan 21, 2022 at 7:04 PM Paul Gevers wrote: > > It's not only the copyright that the ftp-master are responsible for. New > binaries fill a place in the Debian namespace and they *are* the keepers > of that. One could say that for new binaries packages whose src is already in Debian, the ftp-masters skip the d/copyright review and only do the other tasks. This should allow for way quicker transitions of simple SOVERSION bumps. In general I prefer a random d/copyright check more than one based on the introduction of a new binary, as I just don't see any connection between a new binary name and a change of copyright. Regards, Stephan
Bug#1003337: ITP: node-grunt-timer -- times the duration of your grunt tasks
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-CC: debian-devel@lists.debian.org Control: block 1003321 by -1 Control: block -1 by 1003326 1003329 1003334 * Package name: node-grunt-timer * Version : 0.6.0 * Upstream Author : Lee Crossley * URL : http://ilee.co.uk * License : MIT * Programming Lang: JavaScript * Description : times the duration of your grunt tasks This Node.js module times the duration of each of your grunt tasks automatically and outputs the execution time in milliseconds to the console after each task. It also logs the total time for all logged tasks at the end. Node.js is an event-based server-side JavaScript engine. This package is a dependency for openui5, which itself is a dependency for ROOT. I intend to maintain this in the JS team. I don't have a lot of JS experience, but the package seems simple enough to be consistently maintained.
Bug#1003334: ITP: node-functional.js -- Node.js module facilitating currying and tacit programming
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-CC: debian-devel@lists.debian.org Control: block 1003321 by -1 * Package name: node-functional.js * Version : 0.8.0 * Upstream Author : Lee Crossley * URL : https://github.com/functionaljs/functional-js * License : MIT * Programming Lang: JavaScript * Description : Node.js module facilitating currying and tacit programming This Node.js module is a functional JavaScript library. It facilitates currying and point-free / tacit programming, with optional lambda expressions. Node.js is an event-based server-side JavaScript engine. This package is a dependency for node-grunt-timer, which itself is a dependency for openui5, which itself is a dependency for ROOT. I intend to maintain this in the JS team. I don't have a lot of JS experience, but the package seems simple enough to be consistently maintained.
Bug#1003329: ITP: node-bash-color -- wrap strings in color codes for pretty printing in bash
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-CC: debian-devel@lists.debian.org Control: block 1003321 by -1 * Package name: node-bash-color * Version : 0.0.4 * Upstream Author : mykola bilokonsky * URL : https://github.com/mbilokonsky/bash-color#readme * License : Expat * Programming Lang: JavaScript * Description : wrap strings in color codes for pretty printing in bash This is a Node.js module for wrapping strings in color codes for pretty printing in bash. Node.js is an event-based server-side JavaScript engine. This package is a recursive dependency for OpenUI5. I intend to maintain this in the JS team. I don't have a lot of JS experience, but the package seems simple enough to be consistently maintained.
Bug#1003326: ITP: node-duration -- time duration utilities for Node.js
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-CC: debian-devel@lists.debian.org Control: block 1003321 by -1 * Package name: node-duration * Version : 0.2.2 * Upstream Author : Mariusz Nowak * URL : https://github.com/medikoo/duration#readme * License : ISC * Programming Lang: JavaScript * Description : time duration utilities for Node.js This Node.js module provides functions to calculate, convert and display the duration between JavaScript Date objects. Node.js is an event-based server-side JavaScript engine. I intend to maintain this in the JS team. I don't have a lot of JS experience, but the package seems simple enough to be consistently maintained.
Re: Using release-monitoring.org [was: uscan roadmap]
On Sat, Dec 4, 2021 at 3:34 AM Paul Wise wrote: > > Repology gets you mappings for all the source packages in Debian in one > download (assuming it has an export of the mappings, that may need to > be added), while the Anitya mapping requires a human to manually add a > mapping for each of the thousands of source packages in Debian. Not all > maintainers are going to bother and repetitive clicking is going to get > boring for the folks trying to make up for that. I'm sure there would be a way to automate this with repology data. > > Also, mapping on Repology sometimes needs to be adjusted manually. And > > sometimes they disagree and instead tell you to rename the source > > package in the distro (happened to me once), which is not really > > viable in Debian. > > I wasn't aware of the renaming part, seems kind of weird. See e.g. [1]: "Will not merge: Modules (e.g. python) without consistent prefix (e.g. python- or python3-) (common problem for Slackbuilds and Debian source packages). [...]" > > Yes it can't, but also I don't think this is something *release > > monitoring* should do. It is definitely a good use case and that is > > why there is a link to repology on the tracker (called "other > > distros"), but it has IMHO nothing to do with *automatic* release > > monitoring. Don't get me wrong, I actually like repology exactly for > > this particular reason. > > I was taking the thread topic to be the slightly more general area of > "monitoring when a package needs updating to a new upstream release, > snapshot or fork". New VCS snapshots in other distros fits that IMO. Ah right I see, I guess we then should separate more between fetching the tarball and scanning for versions to inform the maintainer - I don't think that these necessarily need to use the same technique. For informing the maintainer, repology might as well be an additional very useful tool. > The other issue with using Anitya is that Debian and Fedora have > different policies and culture for choosing which upstream versions to > update to. Debian strongly prefers LTS versions while Fedora are all > about the latest and greatest, which is a bit of a culture clash and is > likely to mean for some packages we couldn't use Anitya. I don't think this is an issue here - see [2]. The response differentiates between stable versions and other versions. I'm not sure how RCs are handled, but it would not be that difficult to implement. > In addition to independence there is the issue Jonas mentioned > elsewhere in the initial uscan thread that some Debian people prefer > the info to be maintained in the source package instead of elsewhere. Of course this would be optional. Regarding bootstrapping it might not be that good of an idea to use it for essential packages anyway. > > This sounds more reasonable to me than writing a tool that converts a > > new standard to the old one just as backup. > > Given the above, perhaps a way to sync a locally stored file and the > Anitya one, and then have uscan understand the Anitya format? I've been looking at the api (see [2]) for a bit and while not trying it out myself, afaik there is no functionality to download a tarball. While I like the idea of release-monitoring, I now feel like it doesn't fulfill the needs of Debian and probably newer will. So putting all watch files in a single salsa repo probably makes more sense, or something similar to offload it. On Sat, Dec 4, 2021 at 3:44 AM Scott Kitterman wrote: > > I think that there's a security consideration associated with all these > proposals for externalizing finding upstream updates. Currently watch files > and at least the redirectors I know of all run on Debian infrastructure or on > the systems of the Debian person doing the update. > > If one of these services were ever compromised it would provide a vector for > offering substitute upstream code (at least for the cases where upstream > releases aren't both signed by upstream and verified in Debian). I find that > prospect concerning. Good point, but I think this can be mitigated relatively easily - just always print the url of the tarball that is downloaded (which is a good idea anyway). The maintainer should know the url where the sources are hosted, and if the printed url somehow looks weird, it can be easily checked. Stephan [1] https://repology.org/project/symfit/report [2] https://release-monitoring.org/static/docs/api.html#post--api-v2-versions-
Re: Using release-monitoring.org [was: uscan roadmap]
On Thu, Dec 2, 2021 at 11:52 PM Paul Wise wrote: > > On Thu, 2021-12-02 at 23:36 +0100, Stephan Lachnit wrote: > > > If I understand correctly, release-monitoring already offers such a > > mapping [1]. > > It seems like the Ayanita distro mapping needs to be done manually once > per package, while using the Repology data would automatically get us > the mapping for each existing package and all future packages. I mean it looks rather easy to do, just a couple of mouse clicks. Compare that to writing a watch file at the moment (assuming one has to do more than copy and paste the github example). > > Hm, I can't really think of an example where such a thing couldn't > > also be implemented in release-monitoring.org. > > None of the three use-cases I listed can be done by it AFAICT. > > It can't check things that it doesn't have a check for, while > individual package maintainers in various distros will update their > packages and Repology will notice the new versions. Then the maintainer would just have to write a check, just like they have to do now. Also, mapping on Repology sometimes needs to be adjusted manually. And sometimes they disagree and instead tell you to rename the source package in the distro (happened to me once), which is not really viable in Debian. > It presumably doesn't look at the versions for all distros, so it can't > do the cross-distro VCS snapshot choice check, while individual package > maintainers in various distros know their packages well and might > upgrade to a VCS snapshot in their distro, which Repology notices. Yes it can't, but also I don't think this is something *release monitoring* should do. It is definitely a good use case and that is why there is a link to repology on the tracker (called "other distros"), but it has IMHO nothing to do with *automatic* release monitoring. Don't get me wrong, I actually like repology exactly for this particular reason. > It also isn't going to check locations it doesn't check yet, while > individual package maintainers in other distros might do that after > noticing their package hasn't been updated recently and then going > searching for a new upstream and updating, which Repology notices. Fair point, but if we would work together on release-monitoring.org with Fedora, there are more eyes on it as well as in the current situation. Repology still has more eyes of course, but then again the link to Repology is right there on the tracker already if one is curious. > > Just one quick idea I had: what about a "fake" uscan backend? I.e. > > something like `Version: release-monitoring.org` in d/watch. In that > > case uscan will launch an external program that fetches the data from > > there and gives it back to uscan, so that other tools stay unaffected > > until a full transition is done. > > Excellent idea, that would be great to have. One more thought on this. If we go with version 5, maybe something like: Version: 5 Source: release-monitoring.org Would also work for multiple sources then and in general would fit nicely to the current idea for v5. It also solves the problem with the tooling, watch files and uscan would still exist, but the "searching" portion is offloaded. > The one issue I can think of with using release-monitoring.org is that > Debian becomes more reliant on an external service, while currently we > are completely independent of other distros for version checking. > > Converting the release-monitoring.org check to a watch file might be an > alternative to using it directly that maintains our independence. Hm right, independence is a valid concern. Anitya itself is open source [1] so we could host it easily, but of course the real problem would be the stored data of the projects. I don't know if they are hosted somewhere, but I'm sure the Fedora guys would be open to share them with us, so that we could easily spin up a mirror in case there are any problems (it's probably a good idea to host a read-only mirror just in case). This sounds more reasonable to me than writing a tool that converts a new standard to the old one just as backup. Regards, Stephan [1] https://github.com/fedora-infra/anitya
Re: Using release-monitoring.org [was: uscan roadmap]
On Thu, 2 Dec 2021, 23:17 Paul Wise, wrote: > At minimum we would need a way to map from release-monitoring.org > package names to Debian source package names. Assuming they use Fedora > source package names, then the Repology service provides such a mapping > and we could presumably could get a periodic export of that. > If I understand correctly, release-monitoring already offers such a mapping [1]. > I see using Repology as a complement to release-monitoring.org and > uscan, not as an alternative to them. It enables use-cases that aren't > possible with the other two. We automatically get version monitoring > for packages that don't have other version monitoring mechanisms. We > get monitoring of whether or not a particular package needs updating to > a VCS snapshot instead of waiting for an official release. We get > monitoring of versions even when upstream has moved to a different > location not monitored by other mechanisms. There are probably other > use-cases I can't think of right now. > Hm, I can't really think of an example where such a thing couldn't also be implemented in release-monitoring.org. > > Yes that makes sense, what I wonder is how much change is needed for > > putting watch files in a separate repo compared to going with > > release-monitoring.org (I don't know enough about the inner workings > > of our tools to answer this question). > > For the VCS idea it would be minimal, just vcswatch needs to also pull > debian/watch files out of VCS repos with commits not yet pushed to > Debian and then the version checking infra (zero idea where that went) > needs to pay attention to that data. > Oh right, that actually sounds pretty smart. > For fully moving debian/watch (and Homepage) out of Debian source > packages there would need to be a lot more work, probably migrating to > release-monitoring.org would be the way to go. > Just one quick idea I had: what about a "fake" uscan backend? I.e. something like `Version: release-monitoring.org` in d/watch. In that case uscan will launch an external program that fetches the data from there and gives it back to uscan, so that other tools stay unaffected until a full transition is done. In case there are others interested in this approach, I would be down to do some coding (when I find time). Regards, Stephan [1] https://release-monitoring.org/static/docs/user-guide.html#creating-new-distribution-mapping
Using release-monitoring.org [was: uscan roadmap]
On Thu, Dec 2, 2021 at 12:51 AM Paul Wise wrote: > > It might be a idea to look at how other distributions do checking for > new upstream releases and adopt some of their improvements. > > I note Fedora uses a service (that isn't Fedora specific) for this: > > https://release-monitoring.org > https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring/ I think this would be the best path forward - it would probably be not easy given that it changes entirely how the current system works, but it might be well worth the effort. Working together with another distribution would share the work for the distro. I'm sure if we are willing to join them they would accommodate us if there are any changes we would require (e.g. login via salsa instead of a fedora account). > Another idea would be to use the Repology service to notice when other > distros include a newer version of a package than Debian does. > > https://repology.org/ This however I think is not a good idea. Repology is very nice to check what versions other distros have, but for projects that don't have any external language-specific package repository like e.g. python, it would mean that we could easily miss a new release (think small projects written in C that are not in any other distro) and wrongly formatted version from other distros would impact us (unlikely, but still bad in theory). And since it requires the same infrastructure changes as going with release-monitoring.org, it would be better to just use that. > I also wonder if it is time to split debian/watch out of Debian source > packages, since upstream download locations generally change > independently of the Debian package and so information about upstream > download locations probably should be maintained independently. Yes that makes sense, what I wonder is how much change is needed for putting watch files in a separate repo compared to going with release-monitoring.org (I don't know enough about the inner workings of our tools to answer this question). Anyway, if using release-monitoring.org is too much work or nobody is willing to do it, I like the proposals for version 5 so far. Regards, Stephan
Re: Consequences of the NEW queue's length [Was: Remove packages from NEW queue?]
On Thu, Nov 18, 2021 at 4:16 PM Simon Richter wrote: > > On 11/18/21 4:08 PM, Stephan Lachnit wrote: > > > I guess this raises the (maybe already answered) question if the > > additional license QA from NEW is for the end-product (i.e. Debian > > stable) or for the servers that run the Debian infrastructure, which > > of course includes experimental. > > The latter. On Thu, Nov 18, 2021 at 4:29 PM Andrey Rahmatullin wrote: > > On Thu, Nov 18, 2021 at 04:08:23PM +0100, Stephan Lachnit wrote: > > > I think this is exactly why it makes sense. I think we can trust the > > DDs to not make any large mistakes (e.g. putting steam in main). > The existence of NEW means we currently don't, for completely new > packages. I guess these two answers sum it up then. Thanks. Regards, Stephan
Re: Consequences of the NEW queue's length [Was: Remove packages from NEW queue?]
On Thu, Nov 18, 2021 at 3:28 PM Andrey Rahmatullin wrote: > > On Thu, Nov 18, 2021 at 02:52:56PM +0100, Stephan Lachnit wrote: > > I don't know if that has been proposed before, but how about waiving > > the NEW queue requirement for experimental packages as a start? > > [...] Since packages in experimental will never land in any > > official release, I think dropping the NEW queue requirement has no > > negative impact. > This makes no sense as NEW is mostly about checking licenses. I think this is exactly why it makes sense. I think we can trust the DDs to not make any large mistakes (e.g. putting steam in main). Since packages in experimental aren't supposed to be used by anyone else but the DDs themselves, the "damage" of a potentially missing / wrong license is minimal, considering that DDs are aware of the fact that the packages aren't "official". I guess this raises the (maybe already answered) question if the additional license QA from NEW is for the end-product (i.e. Debian stable) or for the servers that run the Debian infrastructure, which of course includes experimental. If it's the latter, then of course this proposal doesn't work. However I find that view a bit weird. Any update can change the license or add new files with different licenses, nothing is ever checked by the ftp-masters (that would be insanity). My conclusion thus is that the NEW queue is more of an additional QA than a full legal coverage for the archive, and thus I don't see a problem with unchecked packages in experimental. Regards, Stephan
Re: Consequences of the NEW queue's length [Was: Remove packages from NEW queue?]
On Thu, Nov 18, 2021 at 11:52 AM Gard Spreemann wrote: > > Every time I see stories like this, I wonder what the consequences of > the NEW queue's current workings are. This is *not* criticism of the > heroic work of the FTP Masters, nor is it criticism of the objectives > they have in processing the NEW queue. I do, however, worry that months > of waiting to see the fruits of one's labor might be detrimental to > attracting new contributors, or indeed to motivate already active > ones. It also seems to be a not insigificant impediment to getting > useful work, such as a SONAME bump, done quickly. At least personally, I > find it harder to put in small pieces of work that result in incremental > improvements if the result is having to wait months – with the added > uncertainty of having to do it all again (for good reasons, but > nevertheless). > > It may well be that I'm asking the impossible here, but it does seem to > be a problem that other distributions don't suffer under to the same > extent. Is it merely a matter of their standards being lower, or is > there some room for improvement on our part? I don't know if that has been proposed before, but how about waiving the NEW queue requirement for experimental packages as a start? This would allow us to work with new packages or soversion updates, and the transition through NEW to "unstable" could happen at the same time (i.e. upload to unstable for NEW and uploading again for experimental). Since packages in experimental will never land in any official release, I think dropping the NEW queue requirement has no negative impact. One could also go further and do this automatically for unstable -> testing (all package uploads allowed to unstable, new ones have to be approved by the ftp-masters before they can transition). Regards, Stephan
Remove packages from NEW queue?
I tried to remove a package from NEW with `dcut rm package.deb`, `dcut rm package.changes` and `dcut cancel package.changes`, but nothing worked. Is there even a way to remove a package from NEW? Regards, Stephan
Re: Proposal to create unstable-proposed-updates suite for use during freeze
On Fri, Aug 20, 2021 at 11:03 AM Andrey Rahmatullin wrote: > If you mean keeping unstable as is and uploading stuff for testing into > t-p-u, that's was always called a bad idea, as nobody tests stuff in > t-p-u. If you don't change anything else, then you're right. If you enable t-p-u by default for testing installations, this can be mitigated a bit.
Re: Proposal to create unstable-proposed-updates suite for use during freeze
On Tue, Aug 17, 2021 at 10:32 AM Pirate Praveen wrote: > Problem: Currently uploading new upstream versions to unstable during freeze > is discouraged. It means users using unstable don't get new updates and > developers are forced to upload to experimental. Using experimental directly > is risky as it can have changes not ready for unstable also. > Proposed solution: open unstable-proposed-updates with freeze and close it > when freeze is lifted. The packages in this suite can migrate to testing, > this avoids manual reuploads to unstable after freeze is lifted. > Optional: create a companion testing suite say rolling which may be used > during this time and a second Britney instance can manage migration to this > suite. I agree that the situation with experimental during the freeze is a problem. I think it makes more sense to do a testing-proposed-updates instead of an unstable-proposed-updates suite, as that more closely reflects what's actually happening. I do have a proposal for a more conceptual change for Sid towards a rolling release laying around, which I'll post to d-d hopefully soon. Cheers, Stephan
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)
On Mon, Jul 19, 2021 at 3:37 AM Guillem Jover wrote: > What I've also said multiple times, is that > merged-usr-via-moves-and-symlink-farms could have been implemented in > a fully automated way, by debhelper, w/o requiring any maintainer scripts, > all with full cooperation and managed by dpkg, with .debs shipping > actual tracked pathnames, if it had not been for the mess required > by merged-usr-via-aliased-dirs. :/ Maybe I get this wrong, but I don't think this conflicts with the decision from the TC. Until Debian 12 gets released, we have a lot of time for a transition. Maybe we should start discussing the transition and less whether or not we do it, as this has been decided now anyway. We could start with collecting the packages that install to /bin* instead of /usr/bin, and adjust the packaging so that they don't do that. Of course, we would need to add a maintainer script that detects un-merged usr and creates a symlink. Actually, I think it would be enough to just let debhelper detect if a package installs to /bin, and adjust the package automatically. For packages not using debhelper, lintian can add a warning if the package installs to /bin. After all packages that installed to /bin have been rebuilt, nothing would install to /bin except for symlinks. At this point, it shouldn't matter if you run a merged usr system or not, or am I forgetting something? IMHO it would make way more sense to discuss how to merge usr once the packages are fixed. Anyway, I think the discussion made clear that we shouldn't immediately start with merging usr once bullseye is released, and I wouldn't interpret the TC decision as such. Regards, Stephan * using /bin as an example, same goes for /lib etc
Regarding the new "Debian User Repository"
Today I discovered a relatively new project called "Debian User Repository" [1]. It's similar to the AUR, and much more than just in principle. Packages are defined as PKGBUILD files and built via makepkg [2], the tool used in the AUR. The packages are then converted to binary debs using makedeb [3]. Overall, the build process is designed to avoid "standard" Debian packaging as much as possible. I was trying to find out who made it - and this project is not related to Debian at all (the creator, Hunter Wittenborn, is not in Debian's contributor database). Also, it's goal is not creating an "AUR" for Debian, but a central replacement PPAs for Ubuntu LTS [4, 5]. For those of you who want to see my conversation with the creator, it's in a public (though encrypted) Matrix room [6]. Why do I think this is relevant for Debian? This was not the first attempt of building a "DUR" [7], and at least I personally think the name has too much weight for a project that is not related to Debian. Thus, I think we should discuss whether we should ask the creator to change the name (he is open for that, I asked him). The creator responded quite nicely and I think we shouldn't actively oppose the project itself. I think the project *can* be beneficial to Debian (at least until someone creates a DUR that actually uses the Debian build process). - Stephan [1] https://dur.hunterwittenborn.com/ [2] https://wiki.archlinux.org/title/makepkg [3] https://github.com/hwittenborn/makedeb [4] https://docs.hunterwittenborn.com/makedeb/debian-user-repository/intro [5] https://docs.hunterwittenborn.com/makedeb/debian-user-repository/dur-user-guidelines/package-relationships [6] https://matrix.to/#/!MlOxXUNnNLifAJrRHM:hunterwittenborn.com/$-0F8SG0pk8RH3cPkhifBCT3lnyYiZdEn1XC3sE6WxRg?via=hunterwittenborn.com=matrix.org=grin.hu [7] https://lists.debian.org/debian-devel/2019/04/msg00064.html
Re: Reconsider sending ITP bugs to debian-devel: a new list?
On Mon, Jun 14, 2021 at 6:01 PM Jeremy Stanley wrote: > > On 2021-06-14 16:22:31 +0200 (+0200), Stephan Lachnit wrote: > [...] > > How about sending a digest of a potential debian-itp to d-d on a > > weekly basis? I think we wouldn't lose any reviews with this, I > > would even go as far and claim that there will be more reviews, > > since it's less of an "annoyance" and more of a weekly "let's see > > what people are up to". > > I don't think that's a valid assumption. The current copies, since > they're one to an ITP, include the name of the software being > packaged in the subject line. If there's one which mentions software > I'm familiar with, I'm far more likely to read the ITP message and > possibly subscribe to it in the BTS to get further updates. The vast > majority of ITP messages I simply delete unread, having seen only > their subject lines. > > If these were aggregated into a digest, fitting the names of all the > relevant software into the subject would be unlikely a lot of the > time. As such, list subscribers are far less likely to spot one for > software they might care about. I guess the discussion is over by now, but I still don't think this a valid argument. If you are the type of person that reads the subjects of ITP mails, you can still subscribe to the potential debian-itp list and get the same experience. In fact, in the beginning it would probably make sense to just subscribe to all current subscribers of debian-devel, and add it to the list of lists that DDs should subscribe to. The new list would have two major advantages: 1) easier filtering 2) potential more people joining d-d to discuss actual development, but aren't interested in ITPs. The digest would be basically the same as the wnpp digest that already exists. A short list of all subjects with links to BTS. On Mon, Jun 14, 2021 at 6:10 PM Geert Stappers wrote: > > On Mon, Jun 14, 2021 at 04:22:31PM +0200, Stephan Lachnit wrote: > > On Fri, Jun 11, 2021 at 4:26 PM Steve McIntyre wrote: > > > > > > To be honest, I think if we did that we'd lose just about all the > > > reviews that currently happen. The whole point of sending ITPs to > > > d-devel is that they will be seen by a wider audience, but I can't see > > > many signing up for YA mailing list for them. > > > > How about sending a digest of a potential debian-itp to d-d on a weekly > > basis? > > If, and only if, that gets implemented: > > * The burden of matching Subject: with subject of email > * The burden of adding the correct BTS-number as email To address I don't think it needs a lot of change. You basically only need to change "X-Debbugs-Cc: debian-devel@lists.debian.org" to "X-Debbugs-Cc: debian-...@lists.debian.org" in the reportbug package and add a new list. - Stephan
Re: Reconsider sending ITP bugs to debian-devel: a new list?
On Fri, Jun 11, 2021 at 4:26 PM Steve McIntyre wrote: > > Jon Dowland wrote: > > > >I think the ITP mails can make reading the rest of the list difficult > >without extra local filtering or steps. Some times they are the > >majority of the list traffic. I think it would be better if > >ITP mail went to a separate, dedicated list, e.g. "debian-itp" to which > >contributors are encouraged to subscribe and participate. > > To be honest, I think if we did that we'd lose just about all the > reviews that currently happen. The whole point of sending ITPs to > d-devel is that they will be seen by a wider audience, but I can't see > many signing up for YA mailing list for them. How about sending a digest of a potential debian-itp to d-d on a weekly basis? I think we wouldn't lose any reviews with this, I would even go as far and claim that there will be more reviews, since it's less of an "annoyance" and more of a weekly "let's see what people are up to". - Stephan
Bug#989101: ITP: libliftoff -- lightweight hardware composer library for libdrm
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-Cc: debian-devel@lists.debian.org, stephanlach...@debian.org * Package name: libliftoff Version : 0.0.0~git20210430.799 Upstream Author : Simon Ser <~emersion/public-in...@lists.sr.ht> * URL : https://github.com/emersion/libliftoff * License : MIT) Programming Lang: C Description : lightweight hardware composer library for libdrm Dependency for gamescope. Not sure where to maintain, will probably talk to the X Strike Force team. Description: libliftoff eases the use of KMS planes from userspace without standing in your way. Users create "virtual planes" called layers, set KMS properties on them, and libliftoff will pick planes for these layers if possible. Longer explaination: https://emersion.fr/blog/2019/xdc2019-wrap-up/#libliftoff - Stephan
Bug#989085: ITP: gamescope -- micro-compositor for games
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-Cc: debian-devel@lists.debian.org, stephanlach...@debian.org.com * Package name: gamescope Version : 3.8.1 Upstream Author : Pierre-Loup A. Griffais * URL : https://github.com/Plagman/gamescope * License : BSD-2-Clause Programming Lang: C Description : micro-compositor for games Will maintain in Games team. Description on GitHub: In an embedded session usecase, gamescope does the same thing as steamcompmgr, but with less extra copies and latency: It's getting game frames through Wayland by way of Xwayland, so there's no copy within X itself before it gets the frame. It can use DRM/KMS to directly flip game frames to the screen, even when stretching or when notifications are up, removing another copy. When it does need to composite with the GPU, it does so with async Vulkan compute, meaning you get to see your frame quick even if the game already has the GPU busy with the next frame. It also runs on top of a regular desktop, the 'nested' usecase steamcompmgr didn't support. Because the game is running in its own personal Xwayland sandbox desktop, it can't interfere with your desktop and your desktop can't interfere with it. You can spoof a virtual screen with a desired resolution and refresh rate as the only thing the game sees, and control/resize the output as needed. This can be useful in exotic display configurations like ultrawide or multi-monitor setups that involve rotation. It runs on Mesa+AMDGPU, and could be made to run on other Mesa/DRM drivers with minimal work. Can support NVIDIA if/when they support accelerated Xwayland. - Stephan
Bug#988524: ITP: vc -- portable, zero-overhead C++ types for explicitly data-parallel programming
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-Cc: debian-devel@lists.debian.org, stephanlach...@debian.org * Package name: vc Version : 1.4.1 Upstream Author : Matthias Kretz * URL : https://github.com/VcDevel/Vc * License : BSD 3-Clause Programming Lang: C++ Description : portable, zero-overhead C++ types for explicitly data- parallel programming Library providing C++ types for parallel programming. Needed for VecCore / VecGeom, which in turn is an optional feature of Geant4 and ROOT. Will maintain in the science team. - Stephan
Bug#988526: ITP: vecgeom -- vectorized geometry library for particle-detector simulation
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-Cc: debian-devel@lists.debian.org, stephanlach...@debian.org * Package name: vecgeom Version : 1.1.14 Upstream Author : Geant4 Collaboration * URL : https://gitlab.cern.ch/VecGeom/VecGeom * License : Apache-2.0 Programming Lang: C++ Description : vectorized geometry library for particle-detector simulation Library mainly for Geant4, enabling better performance. Will maintain in science team. - Stephan
Bug#988525: ITP: veccore -- simple abstraction layer on top of other vectorization libraries
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-Cc: debian-devel@lists.debian.org, stephanlach...@debian.org * Package name: veccore Version : 0.7.0 Upstream Author : Guilherme Amadio * URL : https://github.com/root-project/veccore * License : Apache-2.0 Programming Lang: C++ Description : simple abstraction layer on top of other vectorization libraries Feature for Geant4 and ROOT. Will maintain in science team. - Stephan
Re: ***UNCHECKED*** Packages in contrib solely because they allow using non-free software
On 4/8/21 12:50 PM, Dominik George wrote: The argument raised earlier, that although these games are DFSG-free, they do not fulfill the requirement for Debian main being self-contained holds, imho (lutris ignores the Debian packages and installs copies of the games from who-knows-where). That is something that I dislike, independent of the main vs. contrib discussion. If lutris gained support for the package system, and the ability to install free games from the distribution's repository if available, I think it should definitely be moved to main (I will probably open a feature request upstream for that; it might not even be too hard to implement). If you open a feature request, please ping me (@stephanlachnit). Regarding Lutris: when winetricks decides to go to main, Lutris will follow. I don't see anything that Lutris does more in terms of sideloading external code. Regards, Stephan OpenPGP_0xB35B49EA5D563EFE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#986382: DPL Jonathan Carter's passport number is *******
> Why does the toxic woman want to destroy reputations? If you refer to Jonathan Carter, that isn't even the person that started the vote, nor an original author of the open letter. Do your research, tbh to me it seems like you are a complete outsider. > Destroy nobody - Or destroy everybody! You can't have it both ways. First of all, nobody wants to "destroy" RMS. Calling someone to resign isn't destroying them, especially if they were just (secretly) elected. Secondly, why are you so toxic and want to "destroy" everybody? There is really no point, all you do is make the FLOSS community weaker and more divided. And since you seem to care about RMS and his ideas, I don't think that is something you would like. > If Debian is a vehicle for defamation, every one of you faces full > consequences. Debian is a democracy. Assume one person votes in favor of RMS (which as you can see some people will do), why do you want them to face your alleged consequences? That doesn't make sense. They have no power to do the things you ask for. In fact, nobody in Debian has. Again, I don't think you understand the Debian project at all. > Your jobs are the targets. Your families are targets. I can understand that you are angry even if I don't agree with your views, but I don't think anyone here wants to harm RMS. Everyone here just wants the best for the FLOSS community. Why do you want to harm them so badly? Opinions on how what's the best for the community may differ, but that's fine. Discussions are healthy, as long as they stay friendly (btw your mails aren't). I have learned a lot from discussions, and yes sometimes people (me included) get unfriendly or say things that turn out to be false. But as long as we apologize for mistakes, we can grow from it. > No volunteer should have to suffer you toxic people Don't you think, just maybe, that we shouldn't suffer from your toxicity as well? Especially since we will suffer much more than you can ever suffer from this. I mean, what's the worst that can happen from your point of view? RMS resigns again? Then everything would be just like a month ago. Regards, Stephan
Re: Bug#986382: DPL Jonathan Carter's passport number is *******
> We are contributors to Debian > > The contribution of every one of us makes the name Debian respectable If you were, why do you try to destroy it with this attempt? > Please stop! Delete all fascism and defamation about any volunteer that has > been instigated from Debian in any form whatsoever. Delete it from the vote, > web pages, search engines. > > Please stop! Delete all negative options from the RMS vote. We only want > positive options or nothing. We will not tolerate any outcome that is > negative for a volunteer > > If the mob does not respect our request, we are making a data dump of all the > DebConf personal data. Wtf please relax. The vote isn't even finished. And let's assume the project would vote against it, why do you want everything to be deleted? That's just stupid. Also, let's suppose you are a contributor to Debian (which I doubt), why do you contribute to a project which rules you don't respect? Why do you try to hurt everyone, even those who might vote in favor of supporting RMS? Regards, Stephan PS: if you reply to this, please don't share the alleged last digits to the passport number.
Re: Packages in contrib solely because they allow using non-free software
Hi Doinik, I'm the Lutris Maintainer for Debian, and I completely agree with you. However, at least for Lutris, there is no choice since we recommend winetricks. Thus, I simply copied the copyright comment from winetricks. For winetricks it is a bit more tricky as it can download non-free dlls afaik. On the other hand, Lutris downloads tons of files as part of the runtime, and there might be non-free files in there (I'm aware of at least one icon that has an unknown origin). In both cases, nothing is installed system-wide, so one could argue it's more like automatically wget-ing files to your home directory. There was a larger discussion about this on debian-devel-games [1], you might be interested in that. Regards, Stephan [1] https://lists.debian.org/debian-devel-games/2021/01/msg00013.html
Re: Cancel "culture" is a threat to Debian
On Tue, Mar 30, 2021 at 10:17 AM Dmitry Smirnov wrote: > Cancel "culture" arrived in Debian and it threatens the project: > > * https://www.debian.org/vote/2021/vote_002 > > Cancel "culture" activists want Debian to sign a petition regarding > Richard Stallman's membership in the Board of Directors of the Free Software > Foundation. I don't want to start yet another big discussion, but I think this isn't about cancel culture. Nobody wants to disregard the achievements of RMS. I feel this is more about the picture the FSF as *the* free software foundation represents. It's supposed to represent everyone who fights for a future where software is open, just like we do. But the way RMS got back on the board (I mean not even the fr*cking FSFE knew about that before the public announcement), is just something that shouldn't happen. And there was no apology from RMS (afaik) whatsoever for anything he was criticized for, which is bad for a foundation that wants to represent free software as a whole and everyone involved. Calling for RMS to step back, and everyone who was involved in that decision, really has nothing to do with cancel culture. We as a project that believes that diversity and democracy is important should *at least* publish a statement addressing these issues without signing (e.g. like KDE or the FSFE). Doing nothing is just straight ignorant, it's like saying "yeah we do free software but we don't really care what *the* free software foundation does". It just doesn't fit together. Obviously, everyone is free to disagree and can sign the support letter. There is no problem with that even if the project as a whole signs the opposite letter. I have yet to see someone that blames someone for not signing the open letter, I only really saw it the other way around (so much for cancel culture btw). Please, let this stay peaceful without conspiracy theories about cancel culture. Regards, Stephan
Contributing without your real name
I had a discussion with someone who wants to contribute to Debian, but doesn't want to publish their real name in fear of getting doxed. I never really thought of this, and I'm not sure how much one can contribute to Debian without posting some kind of real name (sorry if that is already answered somewhere). I'm aware that for sponsored work the name doesn't really matter, but can one become a DM or even a DD? Regards, Stephan
Bug#981113: ITP: root -- open-source data analysis framework
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-Cc: debian-devel@lists.debian.org, stephanlach...@protonmail.com, debian-scie...@lists.debian.org * Package name: root Version : 6.22.06 Upstream Author : CERN <https://root.cern/> * URL : https://github.com/root-project/root * License : LGPL-2.1 Programming Lang: C++ Description : open-source data analysis framework The ROOT system provides a set of OO frameworks with all the functionality needed to handle and analyze large amounts of data in a very efficient way. Having the data defined as a set of objects, specialized storage methods are used to get direct access to the separate attributes of the selected objects, without having to touch the bulk of the data. Included are histograming methods in an arbitrary number of dimensions, curve fitting, function evaluation, minimization, graphics and visualization classes to allow the easy setup of an analysis system that can query and process the data interactively or in batch mode, as well as a general parallel processing framework, PROOF, that can considerably speed up an analysis. Thanks to the built-in C++ interpreter cling, the command, the scripting and the programming language are all C++. The interpreter allows for fast prototyping of the macros since it removes the time consuming compile/link cycle. It also provides a good environment to learn C++. If more performance is needed the interactively developed macros can be compiled using a C++ compiler via a machine independent transparent compiler interface called ACliC. The system has been designed in such a way that it can query its databases in parallel on clusters of workstations or many-core machines. ROOT is an open system that can be dynamically extended by linking external libraries. This makes ROOT a premier platform on which to build data acquisition, simulation and data analysis systems. I want to maintain ROOT in the science team. ROOT was already in Debian as `root-system` [1], but hasn't been updated since 2015. I will probably go with a more easy maintainable route like I did with Geant4 for the start and do package splitting later. [1] https://tracker.debian.org/pkg/root-system
CentOS and Debian/Ubuntu release cycles
Hi all, maybe you already have heard it, CentOS is basically dead now. It used to be an exact RHEL clone, but now it's kind of an RHEL beta [1]. Now what does that have to do with Debian? When we look into why people use CentOS, the reason is pretty simple: it is (or was) binary-compatible with RHEL, just without the support [2]. I was reading comments from people that use RHEL on their production, but CentOS at home or for testing, because you don't need to pay for it. These use cases now don't work anymore, forcing them into either paying for RHEL, or moving to a different ecosystem. The more I started thinking about it, the more I wondered about why Debian Stable and Ubuntu LTS are *not* binary-compatible. It just doesn't make sense to me. Both Debian Stable and Ubuntu LTS provide a more "long term" approach than let's say Fedora. And while Ubuntu LTS is based on Debian, it is not based on Debian Stable, even though they have release cycle of two years. It would seem kinda obvious that Debian and Ubuntu have a common freeze period and work on LTS maintenance together. Does anyone know why this is not the case? I suspect some historical reasons, but I couldn't find anything quickly. - Stephan [1] https://blog.centos.org/2020/12/future-is-centos-stream/ [2] It's easy to find comments on various blogs or social media, but for sake of completeness let me just mention that CERN [3], [4]. [3] https://linux.web.cern.ch/centos/ [4] https://linux.web.cern.ch/other/
Bug#974696: ITP: reuse -- tool for compliance with the REUSE recommendations
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-Cc: debian-devel@lists.debian.org * Package name : reuse * Version : 0.11.1 * Upstream Author : Free Software Foundation Europe <https://fsfe.org/> * URL : https://github.com/fsfe/reuse-tool * License : GPL-3.0-or-later * Programming Lang: Python * Description : tool for compliance with the REUSE recommendations REUSE is a standard by the FSFE to use copyright information and SPDX IDs on every file in a project. This information can be used to automatically create an SPDX copyright report. Some dependencies need to be packaged. Would maintain it in the DPT. Cheers, Stephan Lachnit
Bug#965964: ITP: geant4 -- physics simulation toolit from CERN
Package: wnpp Severity: wishlist Owner: Stephan Lachnit X-Debbugs-Cc: debian-devel@lists.debian.org, stephanlach...@protonmail.com Package name: geant4 Version : 10.6.2 Upstream Author : CERN URL : http://geant4.web.cern.ch/ License : a custom (MIT-like) license but looks DFSG compliant Programming Lang: C++ Description : physics simulation toolkit Geant4 is a toolkit for the simulation of the passage of particles through matter. Its areas of application include high energy, nuclear and accelerator physics, as well as studies in medical and space science. Overall, it is pretty hard to build Geant4 nicely. Besides it's size and long compilation time (~15 minutes for me), the CMake build system breaks with a lot of Debian conventions. There is nothing really I can do about that in a reasonable amount of time, so the lintian output is pretty ugly and that probably won't change any time soon if there are no upstream changes. The endresult is usable though, so I will publish the my build files soon. If there is interest to help on this, please let me know. Cheers, Stephan
Bug#963503: ITP: symfit -- Symbolic Fitting in Python, fitting as it should be
Package: wnpp Severity: wishlist Owner: Stephan Lachnit Package name: symfit Version : 0.5.2 Upstream Author : Martin Roelfs URL : https://github.com/tBuLi/symfit License : GPLv2 Programming Lang: python3 Description : Symbolic Fitting in Python, fitting as it should be The goal of this project is simple: to make fitting in Python pythonic. The project aims to marry the power of scipy.optimize with the readability of sympy to create a highly readable and easy to use fitting package which works for projects of any scale. Documentation: https://symfit.readthedocs.io/en/stable/ I would maintain this in Debian Python Modules Team or Debian Science team, depdending on interest. Cheers, Stephan Lachnit
Bug#961012: ITP: gamehub -- unified library for all your games
Package: wnpp Severity: wishlist Owner: Stephan Lachnit Package name: gamehub Version : 0.16 Upstream Author : Anatoliy Kashkin URL : https://github.com/tkashkin/GameHub License : GPL-3.0 Programming Lang: Vala Description : unified library for all your games GameHub is similar to Lutris (in the Debian NEW queue), but with a slightly more "casual" focus. It manages your game collection, with simple "click and play no tinkering around". I would maintain it in the Debian Games Team. Project Description (copied from GitHub): GameHub allows to view, download, install, run and uninstall games from supported sources. GameHub supports non-native games as well as native games for Linux. It supports multiple compatibility layers for non-native games: Wine / Proton DOSBox RetroArch ScummVM It also allows to add custom emulators. GameHub supports WineWrap — a set of preconfigured wrappers for supported games. GameHub supports multiple game sources and services: Steam GOG Humble Bundle Humble Trove Locally installed games can also be added to GameHub. GameHub makes storing and managing your DRM-free game collection easier. Download installers, DLCs and bonus content and GameHub will save your downloads according to settings. Cheers, Stephan
Bug#961010: ITP: vkbasalt -- Vulkan post processing layer to enhance the visual graphics of games
Package: wnpp Severity: wishlist Owner: Stephan Lachnit Package name: vkbasalt Version : >0.3.1 Upstream Author : Georg Lehmann <https://github.com/DadSchoorse> URL : https://github.com/DadSchoorse/vkBasalt License : Zlib Programming Lang: C++ Description : Vulkan post processing layer to enhance the visual graphics of games Currently, the build in effects are: Contrast Adaptive Sharpening Denoised Luma Sharpening Fast Approximate Anti-Aliasing Enhanced Subpixel Morphological Anti-Aliasing Deband/Dithering 3D color LookUp Table It is also possible to use Reshade Fx shaders. The project recently switched to Meson, so it should be easy to package the next version. It also fits well to my ITPs/RFSs for MangoHud (another Vulkan layer) and GOverlay (a GUI application to configure MangoHud and vkBasalt). I would maintain it in the Debian Games Team. Cheers, Stephan
Bug#959739: ITP: editorconfig-checker -- tool to verify that your files are in harmony with your .editorconfig
Package: wnpp Severity: wishlist Owner: Stephan Lachnit Package name: editorconfig-checker Version : 2.0.3 Upstream Author : editorconfig-checker team <https://github.com/editorconfig- checker> URL : https://github.com/editorconfig-checker/editorconfig- checker License : MIT Programming Lang: Go Description : tool to verify that your files are in harmony with your .editorconfig This is a tool to check if your files consider your .editorconfig-rules. Most tools - like linters for example - only test one filetype and need an extra configuration. This tool only needs your .editorconfig to check all files. Cheers, Stephan
Bug#958862: ITP: goverlay -- Graphical UI to help manage Linux overlays
Package: wnpp Severity: wishlist Owner: Stephan Lachnit Package name: goverlay Version : 0.3.1 Upstream Author : Benjamimg Gois URL : https://github.com/benjamimgois/goverlay License : GPL v3 Programming Lang: Pascal (project uses Lazarus) Description : Graphical UI to help manage Linux overlays GOverlay is a program to manage overlays for games, currently it supports MangoHud, an overlay to display informations about fps, gpu temp etc, and vkBasalt, a vulkan post processing layer. Since I currently plan to pack MangoHud for Debian (see #954844 on BTS), this would be a nice addition to that. I'll probably will look packaging into vkBasalt as well. My packaging current packaging attempt is on Salsa: https://salsa.debian.org/stephanlachnit/goverlay GOverlay is written in Pascal with Lazarus, meaning it doesn't work natively with dh. As one can see in my rules file, I basically used dh everywhere and just changed the build target. I wasn't able to get it working with the default dh-sequencer, but I think it should be possible to do that. Any feedback is appreciated. Cheers, Stephan
Bug#954847: ITP: setzer -- Simple yet full-featured LaTeX editor
Package: wnpp Severity: wishlist Owner: Stephan Lachnit Package name: setzer Version : >0.2.1 Upstream Author : cvfosa <https://www.cvfosa.org> URL : https://github.com/cvfosa/Setzer License : GPL3+ Programming Lang: Python with Gtk Description : Simple yet full-featured LaTeX editor Setzer is a LaTeX with very high content-per-window-size ratio, and has a very clean Gtk interface. It also features side bars with a lot of symbols commonly used in mathmode, so one doesn't have to look up the name in the internet, and features spell checking. The latest release doesn't have an install system yet (local only), but I wired up some basic meson support, which was merged into master. Still some things to do, but once that's done it can be easily build in Debian. Could be maintained with the Debian TeX team if someone is interested there, otherwise I'll maintain it myself. Best Regards Stephan
Bug#954844: ITP: mangohud -- An overlay for monitoring FPS, temperatures, and more
Package: wnpp Severity: wishlist Owner: Stephan Lachnit Package name: mangohud Version : >0.3.1 Upstream Author : flightlessmango <https://github.com/flightlessmango> URL : https://github.com/flightlessmango/MangoHud License : MIT Programming Lang: C, C++ Description : An overlay for monitoring FPS, temperatures, and more A modification of the Mesa Vulkan overlay. Including GUI improvements, temperature reporting, and logging capabilities. Helpful to analyze performance in games (works under OpenGL as well). Building under Debian should works, current version has no release tarball with the git submodules included, so I'll wait for the next release before starting a repo on salsa. More on this topic here: https://github.com/flightlessmango/MangoHud/issues/34 It would be possible to release this under the Debian Games Team, if anyone there is interested, otherwise I'll maintain it myself. Best Regards Stephan
Accepted piper 0.3-1 (source all) into unstable, unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 07 Nov 2019 18:27:18 +0100 Source: piper Binary: piper Architecture: source all Version: 0.3-1 Distribution: unstable Urgency: medium Maintainer: Stephan Lachnit Changed-By: Stephan Lachnit Description: piper - graphical frontend for libratbag Closes: 816836 Changes: piper (0.3-1) unstable; urgency=medium . * Initial release (Closes: #816836) Checksums-Sha1: ca5ac7271c9d84735e058e0645e638804e505c5d 1860 piper_0.3-1.dsc 8681d67d6dd20522317072027697caf1b783e340 180248 piper_0.3.orig.tar.gz a2edf7e598ee2b537fd4f8ad3a1e33df47275219 2364 piper_0.3-1.debian.tar.xz 3bb73b9e7afe0405dcb4ac2ba362cf5ee5170bfe 121808 piper_0.3-1_all.deb 2419dae0d8479f3ce54b7362e1dc9dede4a4674a 7241 piper_0.3-1_amd64.buildinfo Checksums-Sha256: 0cdfe03064b8f85cc550ff74868c1e2c0efeedf837734e1a814b34780a395d7f 1860 piper_0.3-1.dsc c7210c058de6a6803db462754386785cf5b9ab36dd9e69de6b7a3ca583451401 180248 piper_0.3.orig.tar.gz f316925a8692e9a1f82d2bbff9562884dedae25e10bd369762101d0c2e6faf1f 2364 piper_0.3-1.debian.tar.xz c9b34696c3012d08d1cceeb7c9b119e680d92ab4e7dca5093d513cd774879431 121808 piper_0.3-1_all.deb a7ef35c38a223ceee449f6f46becf4aa737c454584f9758b3ffd018a6f21277c 7241 piper_0.3-1_amd64.buildinfo Files: ab6d5a4c46a56b140a95ae94ec174e06 1860 misc optional piper_0.3-1.dsc 0a14c618d42ff35daeaebb0aeda20772 180248 misc optional piper_0.3.orig.tar.gz b9e752f68e61c117ada1dd19cc208d93 2364 misc optional piper_0.3-1.debian.tar.xz c7fc23cdadedf071adbc55d2543436e1 121808 misc optional piper_0.3-1_all.deb 399d9e4945dc14ab8c9fb5ff32666043 7241 misc optional piper_0.3-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEnPVX/hPLkMoq7x0ggNMC9Yhtg5wFAl3QUsEACgkQgNMC9Yht g5wOww//RpIEJKq08/ul+KIz9CK8hWfJXejliDjL2yipZ/JLuS74ONVfWjVEuOE0 j2zlzifdl1NL2tuqKOajjSM1yk56iRwt8QMiM1uMUI6pyJQa1jr+jW7jBJwVGtkJ NDiMrjtgpGWiy//k5G/uhjiP0JUdJ9f0Y8AGtJ1MhDVlf6fEVlLb4B9nmJ7vY6yj mPCcDt6+BAi+t1IN4+TMafEERzla5Wjq7zXzF1cS9nX/7/iWbu8WvJnHohPwcytF 0UJezUz5fqDoe3fZ/4q91vPXimlz8XT4HwSHg/7z7zH76sbS+qhU4rsujM8g2YVy m2wNcXhBwI79gtXSRAhwVRr9jI36yzcDeJn7MaURFiUam9R0MzExqipQOPJZX5t4 CK9hesLj3HKFw8xtWgUl6CyTZqXQGTnMEQixUOIYb1HQlzPrHv4DF8zeUnYiHX6s 0RdXZevF5PeSTn/lXthVAbZkmRi5nyCa5wgxccNqc/hC3uQ4dyu0N2TLdTCSHxsi WpTAAY4QCKMVHGGd80eUXRyur3QCmxI4pKSQaeUFUXTGfRj89TGHT7Tev/99qZyz jc4Dmh6uTV2cEdiGB5QQC7T4BW0VfdIIyD/18EBYPS7bkfLe5cDa4c7G6AdrCrxg 3C7OUF7nzqDnUzuoGtixHCgHs6sSfEfJmzj6TaepsaOUGAV4qCw= =U7aw -END PGP SIGNATURE-
Accepted gamemode 1.4+git20190722.4ecac89-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 21 Jul 2019 15:39:35 +0200 Source: gamemode Architecture: source Version: 1.4+git20190722.4ecac89-1 Distribution: unstable Urgency: medium Maintainer: Jonathan Carter Changed-By: Stephan Lachnit Changes: gamemode (1.4+git20190722.4ecac89-1) unstable; urgency=medium . [ Stephan Lachnit ] * New upstream release * Update standards version to 4.4.0 . [ Jonathan Carter ] * New build-dependency: libdbus-1-dev Checksums-Sha1: 8507f08e8e857675e1f104d5b4fa79535e03118f 2350 gamemode_1.4+git20190722.4ecac89-1.dsc 5508818c220abc3e4828e483ddd344e13b9a4c06 64872 gamemode_1.4+git20190722.4ecac89.orig.tar.xz 19a4207d8426eca4fe95a62d84984cce979211bc 3320 gamemode_1.4+git20190722.4ecac89-1.debian.tar.xz 78ff05932fae189a97624089497f1882d89b0143 7364 gamemode_1.4+git20190722.4ecac89-1_source.buildinfo Checksums-Sha256: 0e60e994328754c2dbde1a2305711db0f5a7eef547ed0d9fd8d27290304ebd38 2350 gamemode_1.4+git20190722.4ecac89-1.dsc 905d800fa10b99493ec19679f30bc703ffd4669e0e5a26ddb383ca8c580434d9 64872 gamemode_1.4+git20190722.4ecac89.orig.tar.xz b828c5e6ec265c56f0381fc463b49c45b4438710fca3e456b2298569e1c72ef6 3320 gamemode_1.4+git20190722.4ecac89-1.debian.tar.xz 0b41928b9fa7b90117ab8fa9cfc66dc38f9ca0bb4e78a5757a71f6358c78a35a 7364 gamemode_1.4+git20190722.4ecac89-1_source.buildinfo Files: f25339a2209ccc20bffea72279ccba45 2350 libs optional gamemode_1.4+git20190722.4ecac89-1.dsc f809847ea70dbfcf5f50e9e8bd62f708 64872 libs optional gamemode_1.4+git20190722.4ecac89.orig.tar.xz 812342d153bd5402ce6ec3bd38b54e37 3320 libs optional gamemode_1.4+git20190722.4ecac89-1.debian.tar.xz 753ea723054fbbf6fe3de3c015aee8b9 7364 libs optional gamemode_1.4+git20190722.4ecac89-1_source.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEExyA8CpIGcL+U8AuxsB0acqyNyaEFAl1H/gAPHGpjY0BkZWJp YW4ub3JnAAoJELAdGnKsjcmhElQQAL2jD4wRDFhlE+yk9fWc4YSCRM+sx6c2bGwX 34ws1gdoMtbXqLoqPFZUhz8L/8iiuuaX8MGMD92nwlzHKsLbt2SKlmbCewvKkaTf VO3YuWkQYp7Ce7iRrHa81ntXXfhlUBCCHR6YQXYQuN6bd7B5H4nLPybcXGed4FmC iQBhqjaYYPxjJz43yukGdD7JyMJkJZ73cZfqhwzNdRR4djcU55NElOOm71HaqHcg ohnGUFaKQt4XYtLvP20meGR1maZAXl7CyrooErOyQ8YoyprIQwY1waBnfPUOA9ZP mvHy0glE1d8nU5li79Dh18Yiee4iTUU4h3stS3tayLhiAlmG9jdaN306PgR31sOk w9R/B+anoY8Yt5qNRxJljkF+EU07IMbF0fZnThsg6bEqWG0VVGCODV4N7r1ZcFVj LdrqCF4JTmvWuRDtFXEYhEChzgdLroZoCHTRaYK2nddlrBU5ibAbptsUr3Ji6X52 bxAyrEIA/HkdzaxoTd8ovh33po39e+wlT9ooRHGg/HxrhjSPsUeQCnONk7A9zH5B It11SLceud3QRZ61/FBPPe2KQKaSzHrzKQ1e2x9X7iiLql4Ic4dsSlKR5K90bOSr JzsQwrV8GzlLjlHbKdbdAu1TLshmovYZRzV71BNxavAl4b1o13pjnrsPC9Z1zQU+ hOJPuZJO =jAZL -END PGP SIGNATURE-
Bug#930912: ITP: psu-targets -- adds power supply targets to systemd
Package: wnpp Severity: wishlist Owner: Stephan Lachnit -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: psu-targets Version : 1 Upstream Author : Stephan Lachnit * URL : https://github.com/stephanlachnit/psu-targets * License : GPL-3 Programming Lang: none Description : adds power supply targets to systemd This software adds two new system targets to systemd: psu-adp.target and psu- bat.target These targets will be activated if the system psu is either a power adapter or a battery. The events will be triggered by acpid, so it only depends on acpid and systemd. Overall is this a useful package for laptop users, who want to automate their power saving tools, and other software that needs a simple way to check what the current power supply unit is. Although it is possible to use acpid directly, it is way less flexible because you need to restart the daemon to detect new events and you have to check yourself if you switched to or from a power adapter. I'm the upstream author, and i maintain the upstream code as well as the necessary files for the debian package on github: https://github.com/stephanlachnit/psu-targets (debian files are in the debian branch). -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEu0Wws/9WG9vUXuips1tJ6l1WPv4FAl0OB+QACgkQs1tJ6l1W Pv4ohQ/+MoX89rku9y0U/iu7YXZnmiytlJs3Z/U5Eu/b+xpeRFNuAiw5O3hg1svB 6ReytWVA4XRqSFvvAXq1ln1md/uhkQOftcvAMROnwYCaxp8PxMml8wCOs7Qf8aD2 +8OgdvjGxBw7B+y2thPmrjmT/YYvKnmNIpebA7bRggOd3OD/bLMgX0XVsjy+f1HQ cG6mCJeyod5WzjiI5//Vn9ZMua8HjyIldZSmoOOi03hSee96FyvbBYZyQRAOtkLO qCyRDaPzLgE4EI1x59wBI2Tw+rb6MBInzPlJgddm1mh5EYQM+/qKK3PBNlmmP5sv vHbyURkUAfIfxSyME8USplyO2+aQmYMkqXs+R1L5lsq8gSvxkaFaMXv0Yc2d5gGf 9NBZ9CBbMPrFa64STboDmfm59YURK6NLID+XFjVGy39uNlBD/8AMDqk65SbuwGFP mwh/Dw7LerYXYPKJmMrA9HT/0daCX/W7kLIlG+Y/GbQPOPaTcYvUuLq+XFgJLVKe 0TcScGHIgURebyfAsYhStPDL66y0X4lirBODhN6MytFnJvlNZlTKsJKP8sWCW1YI XQoBLKgpH0F14CbsbU8SgO83nFTRt19cTlO+E7e/8Upji0hTlCsZeQZWvBMhzk7v q9RSboChGP+njJMMjHkShPdBNYEMMcUrXGTAJSyuw9dHY6Y5aAI= =01Td -END PGP SIGNATURE-
Bug#930500: ITP: intel-undervolt -- tool for undervolting Intel CPUs
Package: wnpp Severity: wishlist Owner: Stephan Lachnit -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: intel-undervolt Version : 1.6 Upstream Author : kitsunyan <https://github.com/kitsunyan> * URL : https://github.com/kitsunyan/intel-undervolt * License : GPL-3 Programming Lang: C Description : tool for undervolting Intel CPUs intel-undervolt is a tool for undervolting CPUs, working with Intel CPUs since Generation Haswell. It can also change power and temperature limits. Note: undervolting can cause stability issues I think this is a useful tool for users where power- consumption matters. This include for example laptops or servers which run permanently. Although there are packages which can limit power consumption, for example powercap, I haven't found any packages which can read or change voltages. I already started packaging, but there is still some things I have to figure out, since this is my first debian package. I plan to maintain this package publicly on github: (debian branch) https://github.com/stephanlachnit/intel_undervolt_deb -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEu0Wws/9WG9vUXuips1tJ6l1WPv4FAl0C3S4ACgkQs1tJ6l1W Pv6eaxAAh9sAjB7apEYfGosygtmXVp58Rt5WJhP7dTIx1MCaFJ0NskA/I1UUKK8R B3UCQLiZKTNwFhJmwrSkZO3u4fhyeAkRD/4w5+TNAaxZABHlCvRwlWz0PxIjfiaj 1uvLHvcK11TV6rcj0ya3IjKHS0kV5eXqrFyKs/0NlXy09BWXd/MtxFMzWfV6IwH5 1vcho74FQq9fY5IUkUDIbgr/IxAlRuA35p4iKqGLOOZ7du+BhBGU4k+5zrB+Ec4K z06UdBXikYplBTmeyrLavLqDJaxFrF2xgrf6eEC4o2OYcp6mE+NJlAPu86XTAujP TBio3BmIbEKQeC3QmDb5mtaam147iXTkoNx1vZzjZgeCgm4aaGUOPHPp/bmDFa35 llHNeWUkXYSKRh9JLQqTiD7yzhUq6zXYN3H4QQx8lnyGzxcVvOxXxDUcQpCNP8SN JEBnimITxKn0SQetjbrJhNUCzW3/h/rJ8rCLJ9cEtPrppsebENLOwh/ZQ0Lorl+n CEXV+ZQdAkfRZqKmzLwlMM4okcLuDUpmz1ME+DK0BJOn6UdOxYCONui9RAeBOmp/ TEs3CZ6GrKIPrw9I34qsjiBylX6mXE667lLsw71pQ6AaoixkwfXtNOHgYffGaDUW G3Pk+61u9+Hl3FwqWJsSFdkp0gA2dh23q1tZRGyDfXGJDdd98NE= =82kQ -END PGP SIGNATURE-
