Re: Bits from DPL
On Wed, Jan 08, 2025 at 02:59:16PM +, Luca Boccassi wrote: > On Wed, 8 Jan 2025 at 14:35, Peter Pentchev wrote: > > > > On Wed, Jan 08, 2025 at 10:19:34AM +0100, Julien Plissonneau Duquène wrote: > > > Le 2025-01-07 21:52, Peter Pentchev a écrit : > > > > > > > > Hm. That sounds interesting, but I think the Debian project cannot > > > > protect such a mirror from automatically bringing in non-DFSG content > > > > that appears in the remote repository. One might even take this one step > > > > further and go to content forbidden by law in various jurisdictions. > > > > > > Then we are going to have the same issue implementing automated upstream > > > release imports in packaging repositories, e.g. with the Janitor, and this > > > is a service I would very much like to have. > > > > Unfortunately you are correct that the same problem would arise. > > Note that there aren't, and never were, rules concerning DFSG content > and git repositories. In Salsa (and also in its predecessor forge, > Alioth) you can find repositories for packages uploaded to non-free - > firmwares, drivers, etc. And that makes sense, as the rules apply to > the 'main' section of the archive, which is what we ship to users, not > to development infrastructure, otherwise you couldn't upload non-free > packages to buildds to get them built, or deb.debian.org to be > published in the non-free section, and so on. > So it's entirely ok if mirroring brings in non-DFSG content, as long > as packages are uploaded to the appropriate non-free or firmware > sections of the archive. Right, and that's why in my next sentence I mentioned content that might actually be illegal and bring trouble to the administrators. Sorry, the DFSG part was mostly a red herring, although a part of me does wonder whether putting a file up for download is not a type of redistribution, but I guess that has already been discussed many times among the administrators of alioth and salsa. I am mostly concerned with content that may be viewed as illegal, in the context of "this was pulled in automatically, there was no human being who initiated that action, so there is nobody but the site admins to be held responsible". G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com PGP key:https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Bits from DPL
On Wed, Jan 08, 2025 at 10:19:34AM +0100, Julien Plissonneau Duquène wrote: > Le 2025-01-07 21:52, Peter Pentchev a écrit : > > > > Hm. That sounds interesting, but I think the Debian project cannot > > protect such a mirror from automatically bringing in non-DFSG content > > that appears in the remote repository. One might even take this one step > > further and go to content forbidden by law in various jurisdictions. > > Then we are going to have the same issue implementing automated upstream > release imports in packaging repositories, e.g. with the Janitor, and this > is a service I would very much like to have. Unfortunately you are correct that the same problem would arise. > I would worry more about malicious content getting automatically pulled in. > But anyway this can probably be mitigated the way large platforms do: make > it possible to easily report abuse and being diligent in investigating them, > eventually putting the repository offline until the issue is cleared. Hm, I would be really, really surprised if there was even one "large platform" that did not shift the responsibility to the user by having them sign a terms of service document upon account registration. Also, I'm not sure that some issues can really be cleared; see below. > Additional automated checks could be implemented to suspend updates and > require human review e.g. with LICENSE changes unless the file contents > matches a whitelist. That would put the responsibility on the uploader to review not only the actual changes (as in a diff) between the releases, but each and every individual file in each and every commit between the two releases. I don't think this is completely realistic. Why each and every individual file? Well, consider this: - version 3.14.1 is tagged - version 3.14.1 is uploaded to Debian - somebody pushes a commit to the upstream repo that adds a file that really does not belong there - two more "real" commits are pushed - somebody pushes a commit that reverts the "add a bad file" one - three more "real" commits are pushed - version 3.14.2 is tagged - version 3.14.2 is uploaded to Debian ...so, if at this point the mirror pulls in the Git commits between versions 3.14.1 and 3.14.2, there will exist several publicly-accessible blobs that will contain the file that really does not belong there. Clearing the issue would require rewriting Git history, squashing commits or dropping them altogether, which would make the Debian version of the "upstream" Git repository no longer be a mirror. > Alternatively the mirroring could be implemented to pull only the release > tags after a package is uploaded to the archive (which means that someone > reviewed the changes), and dealt with on a case-by-case basis for non-free > packages or packages that have +dfsg repacking. In Git repositories, pulling the release tag involves pulling (and making available) all the commits leading up to it, even the reverted ones, so... see above. In general, automatically mirroring Git repository content is... fraught with various issues. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com PGP key:https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Bits from DPL
On Tue, Jan 07, 2025 at 09:24:54PM +0100, Julien Plissonneau Duquène wrote: > Le 2025-01-07 20:03, Andreas Tille a écrit : > > While I'd love to see all packages on Salsa > > I think that being able to host the primary git repository of packages > elsewhere is a freedom worth maintaining for many reasons. > > What the Debian Project could (and probably should) do in these cases is to > host a read-only mirror of the repository with most features disabled by > default (no issues, no merge requests, no CI unless the maintainers switch > them on), just keeping the possibility to fork the repository. This would > mitigate the risk that the repository just vanishes, maybe help to alleviate > some scaling issues like API rate limits on some platforms, and make it > easier for would-be contributors to maintain a public fork for the platforms > that make it complicated or impossible or have unreasonable ToS. Hm. That sounds interesting, but I think the Debian project cannot protect such a mirror from automatically bringing in non-DFSG content that appears in the remote repository. One might even take this one step further and go to content forbidden by law in various jurisdictions. Having a Git forge where developers (who have manually created accounts and agreed to terms of use) will always choose what to push and what not to push takes care of this problem, or at least moves the responsibility on to the developers themselves. An automatic mirror cannot do that. (and no, even if one says "well the responsibility is on the developer who first marked that remote repo for mirroring", no, I don't think there is a way that developer can know that, two weeks later, somebody will push bad stuff there) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com PGP key:https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Contents indices files
On Wed, Dec 18, 2024 at 07:46:03PM +0100, Frank Guthausen wrote: > Hello. > > Maybe this question belongs more to debian-devel than debian-user: > > According to the repository format wiki page[1] there exists contents > indices files, e.g. in Debian bookworm main[2]. How are they generated? > Is there documentation in the Debian wiki? Some tool to support this? > > I created a repository with reprepro, but this generates Release > and Packages files only, not the Contens-*.gz files. The content > of this repository is invisible to apt-file. > > [1] https://wiki.debian.org/DebianRepository/Format#A.22Contents.22_indices > [2] https://ftp.debian.org/debian/dists/bookworm/main/ I'm pretty sure I could find some info on the format of the Contents files (they seem to be pretty much "path section/pkgname"), but if your question is really about reprepro, then take a look at the "Contents" option in the definition of a distribution (the conf/distributions file); putting "Contents:" on a line by itself will make reprepro generate the files. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com PGP key:https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Musings about Usernames in adduser and Debian
On Fri, Dec 13, 2024 at 11:01:43PM -0500, Michael Stone wrote: > On Fri, Dec 13, 2024 at 07:00:36PM +0200, Peter Pentchev wrote: > > On Fri, Dec 13, 2024 at 10:08:19AM -0500, Michael Stone wrote: > > > On Fri, Dec 13, 2024 at 12:22:38PM +0100, Marc Haber wrote: > > > > They are planning to remove the --badname option from useradd, making > > > > it impossible to even try UTF-8 user names, without patching useradd. > > > > > > Or edit the passwd file (vipw), or use any non-passwd-file authentication > > > mechanism, or use a different user management tool, etc. > > > I think you're overemphasizing the importance of the useradd command > > > here--it just acts as a convenience and sets some baseline policies; > > > it's not actually essential for adding a user. If you don't like the > > > policy > > > that useradd sets...just don't use it. > > > > In the context of the whole thread, are you suggesting that adduser(1) > > should be changed to use something other than useradd(8) under the hood? > > No, I'm suggesting that rhetoric asserting that any adduser/useradd policy > could constrain people is overblown because users can be added to the system > without using either of those tools. The tools' policies should reflect what > is safest and most sensible for the majority of users, but if someone wants > to do something different there is nothing stopping them from doing so. [snip more about adding accounts without useradd/adduser] Thanks, that makes sense. Apologies if my reply came through as snarky. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com PGP key:https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Musings about Usernames in adduser and Debian
On Fri, Dec 13, 2024 at 07:00:36PM +0200, Peter Pentchev wrote: > On Fri, Dec 13, 2024 at 10:08:19AM -0500, Michael Stone wrote: > > On Fri, Dec 13, 2024 at 12:22:38PM +0100, Marc Haber wrote: > > > They are planning to remove the --badname option from useradd, making > > > it impossible to even try UTF-8 user names, without patching useradd. > > > > Or edit the passwd file (vipw), or use any non-passwd-file authentication > > mechanism, or use a different user management tool, etc. > > I think you're overemphasizing the importance of the useradd command > > here--it just acts as a convenience and sets some baseline policies; > > it's not actually essential for adding a user. If you don't like the policy > > that useradd sets...just don't use it. > > In the context of the whole thread, are you suggesting that adduser(1) > should be changed to use something other than useradd(8) under the hood? Sigh, that's adduser(8) too, of course. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com PGP key:https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Musings about Usernames in adduser and Debian
On Fri, Dec 13, 2024 at 10:08:19AM -0500, Michael Stone wrote: > On Fri, Dec 13, 2024 at 12:22:38PM +0100, Marc Haber wrote: > > They are planning to remove the --badname option from useradd, making > > it impossible to even try UTF-8 user names, without patching useradd. > > Or edit the passwd file (vipw), or use any non-passwd-file authentication > mechanism, or use a different user management tool, etc. > I think you're overemphasizing the importance of the useradd command > here--it just acts as a convenience and sets some baseline policies; > it's not actually essential for adding a user. If you don't like the policy > that useradd sets...just don't use it. In the context of the whole thread, are you suggesting that adduser(1) should be changed to use something other than useradd(8) under the hood? G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com PGP key:https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Suitability of Rust for *all* architectures? [WAS Re: Rustc unsoundness on i386]
On Sun, Nov 24, 2024 at 06:23:00PM +0100, Paul Gevers wrote: > Hi, > > On 11/24/24 17:22, Andrew M.A. Cater wrote: > > 5. If we're moving hardware baselines for the sake of Rust (or any other > > software on this architecture) it's already too late. > > Huh? Why? > > [Putting my Release Team hat off] Personally I think Debian should be > raising the baseline for i386. I'm not sure about to which level, but I've > seen proposals in this thread. > > Given that > 1) we're no longer supporting i386 as a full architecture (no kernel, no > installer, only in chroots or as multiarch) > 2) we don't clearly have i386 porters > maybe we should seek consensus in this thread and go with that. > > [Release Team hat on] I would take consensus for a decision on the topic. FWIW from a mostly-lurking small-time DD who often wishes he would allocate more time to help with Rust packaging in Debian: go for it. (not sure if you were actually asking for lurkers to pipe in; thought I would on the off chance of "everyone who agrees is silent") G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com PGP key:https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Program request (dosemu).
Hi Mike, dosemu is in the archive and snapshot. Rather long links I'm afraid! http://archive.debian.org/debian-archive/debian/pool/contrib/d/dosemu/dosemu_1.4.0.7+20130105+b028d3f-2+b1_amd64.deb https://snapshot.debian.org/archive/debian-archive/20240331T102506Z/debian/pool/contrib/d/dosemu/dosemu_1.4.0.7%2B20130105%2Bb028d3f-2%2Bb1_amd64.deb I installed the archive version in Trixie, and it seems to be working. No problems with dependencies. Regards, Peter
Re: Musings about Usernames in adduser and Debian
On Fri, Nov 22, 2024 at 10:01:24PM +0100, Gioele Barabucci wrote: > On 22/11/24 20:42, Étienne Mollier wrote: > > I tried to consider what it would take to have an émollier or an > > Émollier login, and there is one little blocker : I may have to > > login from environments or keyboards lacking the necessary i18n > > and l10n capabilities to transcribe the 'e' acute, let alone the > > uppercase 'e' acute. > > Dear Étienne, > > your case highlights another problem not mentioned in the original list > posted by Marc: comparison (and normalization). > > Some characters can be encoded in more than one way. For instance, "é" in > "émollier" could we stored as "e with acute" U+00E9 (and encoded in UTF-8 as > 0xc3 0xa9) or as "e, combined with an acute accent" U+0065 plus U+0301 > (UTF-8: 0x65 0xcc 0x81). If a keyboard input system provides the former > sequence of bytes, but the username is stored in the login infrastructure > using the latter sequence of bites, then a naive comparison will not find > the user "émollier" in the system. Unicode defines in Annex 15 a few > normalization forms as a way to work around this problem. But a correct use > of these normalization forms still requires coordination and standardization > among all programs accessing the data. > > Does POSIX (or other de-facto standards) prescribe a normalization form for > Unicode-/UTF-8-encoded usernames? POSIX says "if you want your applications to be portable, do not use any funny characters in usernames": https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap03.html#tag_03_409 3.409 User Name A string that is used to identify a user; see also 3.407 User Database. To be portable across systems conforming to POSIX.1-2024, the value is composed of characters from the portable filename character set. The character should not be used as the first character of a portable user name. For people unfamiliar with POSIX terms, the portable filename character set is defined as: https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap03.html#tag_03_265 The set of characters from which portable filenames are constructed. A B C D E F G H I J K L M N O P Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 . _ - The last three characters are the , , and characters, respectively. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com PGP key:https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Simpler git workflow for packaging with upstreamless repositories
On Mon, Nov 18, 2024 at 05:40:55PM +0200, Kari Pahula wrote: > With all the recent talk about increasing the use of git for > packaging, I'd like to address one thing: git-buildpackage is very > complex to use. As an alternative, I'd like to propose a simpler > setup: > > - Only store debian/ in the repository and use origtargz for the rest. > > - One branch per distribution you target. > > - Only tag debian revisions. > > That's it, less is more. The master branch would be just a single > debian directory. What it specifically wouldn't have is an upstream > branch and no extracted upstream sources in any permanent branch. Let me start by saying that I understand where you're coming from; any tool that allows different use scenarios will almost inevitably grow more and more complex with time, and become more and more difficult to use by beginners, unless there are good tutorials and step-by-step recipes for the most common cases. TBH, I think that the git-buildpackage manual is relatively easy to read and understand, but, of course, that opinion of mine is tainted by the fact that I cannot exactly be called a beginner :) (although there are new things I learn about Debian packaging every month) However... different people are used to different workflows. I personally really, really like the fact that I have the Git history of all the upstream files in the same repo and I don't have to go over to a different repo to figure out what changed when. Also, I like that immediately after `gbp import-orig` I can run `git show upstream` to review the diff (TBH, me being very pedantic, I usually have already given it a quick glance using `diff -urN` on unpacked tarballs before even importing it, if only to figure out if there are new files that I need to exclude, but that's not always the case), and that I can at any time later run `git diff upstream/2.17.18..upstream/3.14.15 path` or similar commands. I have even been known to use `git bisect` in a Debian package directory in some weird cases. And yes, all of that can be handled in a separate Git repo with a clean checkout of the upstream repository without any of the Debian fluff; however, that would require me switching between terminals/tmux panes/whatever, and sometimes that seems like too much work when I can have it all in a single repository :) So... yes, a simpler setup would work for some people, and it may be better for beginners. However, there are some benefits to a full repository containing both the upstream source and the Debian changes, and some people like to use them every now and then. Still, thanks for your desire to make working on Debian easier and better! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com PGP key:https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Most optimal way to import NMU into existing git-builpackage repository?
On 25/10/2024 11:49, Jonas Smedegaard wrote: If my understanding is correct, then it sounds wrong for DDs to be granted access to all Salsa projects. Hi Jonas, I was not thinking of all Salsa projects, but those that represent official packages. Cheers, Peter
Re: Most optimal way to import NMU into existing git-builpackage repository?
On 24/10/2024 21:36, Otto Kekäläinen wrote: Hi, I occasionally run into the situation that a package has been NMU'd or otherwise updated directly into the Debian repositories, bypassing/ignoring that a packaging git repository existed. Hi Otto, Are any of these packages team maintained? I understand there is an issue whereby although uploading DDs have unrestricted access to the archive, they cannot update Salsa team repos if they are not a team member. Maybe this ought to be fixed? I can understand restricting access for DMs, but does it make sense for DDs? Regards, Peter
Re: signify and signify-openbsd names
On Wed, Oct 09, 2024 at 11:02:47AM +0200, Simon Josefsson wrote: > Thanks for review! I tried to revise the plan below, does this work? > > I think we should compare this plan to simply remove the 'signify' > package, but haven't fleshed out that plan yet. > > /Simon > > x) Take current non-OpenBSD 'signify' source package and upload NEW > 'signify-mail' package, say version 1.14-8 (?), that provides > /usr/bin/signify-mail instead of /usr/bin/signify, and has d/control: > > Source: signify-mail > ... > Package: signify-mail > Replaces: signify (<= 1.14-7) > Conflicts: signify (<= 1.14-7) Hmm. ICBW, but I've always thought that version specifications like these are best written as (<< fixed-version~) with the added tilde to also accommodate backports of the fixed version. So in this case, this would be (<< 1.14-8~), which would: - catch the 1.14-7 version in the archive (1.14-7) - catch any 1.14-7+something binNMUs or stable updates - catch any 1.14-7.x somethign old-style NMUs - catch any 1.14-7+something local versions that somebody may have installed on their systems (I sometimes rebuild packages with small changes and I add a new changelog entry with a +0~0~ringlet.1 suffix so that any binNMUs or updates will most probably sort later than the 0~0 part) - intentionally not catch any 1.14-8~bpoN backports of the new version Of course, in this particular case the archive only contains 1.14-7, there are no backports, no stable updates, it seems unlikely that somebody will upload a NMU in the middle of this discussion, and the package will most probably not be part of any binNMU campaign, so in this particular case (<= 1.14-7) would probably work, except for the low chance of anybody having a 1.14-7+something local version. Still, I thought I'd mention this for the more general case. And thanks for holding this discussion in the first place! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com PGP key:https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1083079: ITP: libqt6pas -- Qt6 interface bindings for Pascal
Package: wnpp Severity: wishlist Owner: Peter X-Debbugs-Cc: debian-devel@lists.debian.org, pe...@pblackman.plus.com, pkg-pascal-de...@alioth-lists.debian.net * Package name : libqt6pas Version : 1 Upstream Contact: N/A (See URL below) * URL : https://www.lazarus-ide.org/index.php * License : GPL2+ Programming Lang: C++, Pascal Description : Qt6 interface bindings for Pascal Provides interface for Pascal applications to the Qt6 C++ libraries. This binding does not cover the whole Qt6 framework, it just contains all classes needed to use Qt6 as a widgetset. This will enable Lazarus packages to built for Qt6. (Similar functionality is provided by libqtpas for Qt5) Package to be maintained by Debian Pascal Maintainers Regards, Peter
Re: sensible languages for younger contributors (was Re: lintian.debian.org off ?)
On Wed, Sep 25, 2024 at 12:00:47PM +0200, Serafeim (Serafi) Zanikolas wrote: > hi Jonathan, > > On Sun Sep 22, 2024 at 5:05 PM CEST, Jonathan Dowland wrote: > > On Wed Sep 4, 2024 at 8:33 PM BST, Serafeim (Serafi) Zanikolas wrote: > > > incidentally, lots of Debian native code is in perl, and like it or > > > not, we should allow for, or even encourage [0] (partial) rewrites if > > > we want to attract new contributors, especially below the average DD > > > age [snip] > > What criteria are important for such a recommendation? > > I'm not sure that we could converge on a recommendation, nor that it would be > of > any use if we were to -- except perhaps in a team-local scope. fwiw, some > ideas: > > - popularity, accounting for fitness for purpose (e.g. no php and js, as > mentioned elsewhere in this thread) > - readability > - maintainability > > as an example, I've rewritten adequate(1) from perl to go. the perl version > was > absolutely fine, I just couldn't see myself writing perl for fun in my free > time. and I feel more optimistic about finding co/new maintainers given that > it's in go In my personal experience, languages that either have built-in strong type checking or have easy ways (and IMHO mypy invoked via Tox is easy) to run a type checker lead to much more maintainable code over time, at the obvious price of a bit more verbosity. > > (Please, not Python :P) > > not a big fan either, but python scores pretty high in terms of the first two > criteria above ...so lately I have found that I never write new stuff in C and Perl, preferring Rust and Python respectively. (and yes, I know Raku has strong typing, and I do use it for some local projects, but unfortunately I don't think it will ever gain the popularity it deserves) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com PGP key:https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: universal zcat ?
On Sun, Sep 08, 2024 at 08:10:53PM -0400, Josh Triplett wrote: > Bill Allombert wrote: > > Dear Debian developpers, > > > > I ma looking for a wrapper around the various compressions programs > > (gzip, bzip2, xz, zstd, etc.) > > that would provide the same interface as zcat but would automatically > > pick the right decompressor. > > > > I could easily write one but it probably already exists. > > https://packages.debian.org/sid/zutils: > > utilities for dealing with compressed files transparently > > > > Zutils is a collection of utilities for dealing with any combination > > of compressed and non-compressed files transparently. Currently the > > supported compressors are gzip, bzip2, lzip, xz, and zstd. There are also acat in the atool package, and bsdcat in the libarchive-tools package. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com PGP key:https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: DEP-18 discussion summary (Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages)
On 03/09/2024 15:36, Otto Kekäläinen wrote: My information was based on what Salsa admin posted at https://salsa.debian.org/salsa/support/-/issues/395 Hi Otto, Thanks for that link, which took me nearly a minute to open! Quoting from there. Could we keep the issue open for now and only close it once it is fixed? Agreed. I can't reopen it myself, buy maybe you could as reporter. Perhaps people might provide as comments further insights about the issue. More likely if its open. Regards, Peter
Re: DEP-18 discussion summary (Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages)
On 28/08/2024 03:13, Otto Kekäläinen wrote: ## Performance and Reliability Multiple participants, including Salvo Tomaselli, Johannes Schauer Marin Rodrigues, Andrea Pappacoda, and Gioele Barabucci, complained about Salsa/GitLab being slow or unreliable at times, which deterred contribution. Improvements to performance and uptime were seen as important. Hi Otto, Until recently I generally found Salsa response to be adequate, but for the last couple of days it has been so excruciatingly slow as to be almost unusable. In response, Otto Kekäläinen noted that the Salsa admins had posted about upcoming hardware upgrades and other improvements to address these issues at https://salsa.debian.org/salsa/support/-/issues. Which particular issue here relates to the planned hardware upgrade? Regards, Peter
Bug#1078082: ITP: python-test-tunnel -- Write tests for network tunnelling utilities
Package: wnpp Severity: wishlist Owner: Peter Pentchev X-Debbugs-Cc: debian-devel@lists.debian.org, team+pyt...@tracker.debian.org, r...@debian.org * Package name: python-test-tunnel Version : 0.1.1 Upstream Contact: Peter Pentchev * URL : https://devel.ringlet.net/net/test-tunnel/ * License : BSD-2-Clause Programming Lang: Python Description : Write tests for network tunnelling utilities The `test-tunnel` library's purpose is to make it easy to write either command-line tools or test modules that start some network tunnelling server (e.g. stunnel, microsocks, Dante) and verify that it does indeed forward connections and data as expected. I intend to maintain this package within the Debian Python team. signature.asc Description: PGP signature
Re: Bug#1069256: debian-policy: clarify requirement for use of Static-Built-Using
On 14/07/2024 16:54, Maytham Alsudany wrote: Hi, Ping for further feedback or seconds for proposed policy change to clarify and document the use of the Static-Built-Using field. Hi Maytham, could also mention that this field would be useful for fpc & lazarus packages. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997948 Regards, Peter
Bug#1073849: ITP: python-imapclient -- easy-to-use Python IMAP client library
Package: wnpp Severity: wishlist Owner: Peter Wienemann X-Debbugs-Cc: debian-devel@lists.debian.org Package name: python-imapclient Version : 3.0.1 Upstream Author : Menno Smits URL : https://github.com/mjs/imapclient License : BSD-3-Clause Programming Lang: Python Description : Easy-to-use Python IMAP client library IMAPClient is a high-level Python library to access mailboxes via the IMAP protocol. It relieves the user of many low-level tasks like parsing server responses, encoding of unicode strings used as folder names, optional translation of timestamps into local time of the client and more. The information is delivered in handy Python data structures that can be easily used for further processing. To help with code development or for quick inspections IMAPClient also offers easy-to-use interactive sessions. This package will be maintained under the umbrella of the Debian Python Team.
Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On Thu, May 30, 2024 at 08:35:47AM +0200, Johannes Schauer Marin Rodrigues wrote: > Hi, > > Quoting Luca Boccassi (2024-05-28 01:54:08) > > Thanks for the useful input, the following has been done: > > > > - existing installations pre-trixie will get an orphaned tmpfiles.d in > > /etc/ that keeps the existing behaviour unchanged (no cleanup of > > /var/tmp) > > - openssh and tmux have been fixed to provide a tmpfiles.d exception > > to retain their respective files > > - the /tmp/ description in debian-installer has been updated to note > > it is a tmpfs by default (via a commit in partman-basicfilesystems, > > will upload if nobody gets around to it before Trixie's freeze) > > - two paragraphs have been provided for the release notes ticket > > - the changes are also noted in NEWS, with instructions on how to > > override locally > > - as mentioned, the latest upload to unstable makes /tmp/ a tmpfs by > > default and for new installations 10+ days old files in /tmp/ and 30+ days > > old files in /var/tmp/ are cleaned up daily > > thank you for having discussed this change on d-devel and for adding > documentation to NEWS and release notes to announce this change. I also think > it is sensible to roll this only out on new installations and to keep the > behaviour on existing setups. Thank you for implementing that as well. > > That being said, maybe some Perl wizard knows how to do a flock on a directory > in Perl? I wouldn't call myself a Perl wizard by a long stretch, but I can give it a try :) > I tried this: > > use Fcntl qw(LOCK_EX); > opendir(my $handle, ".") or die "opendir: $!"; [snip] Here lies your problem. The flock(2) syscall works on file descriptors, the things returned by open(2), not on the dirent structures returned by opendir(3). So you need something like this: use v5.10; # I really should switch to at least 5.16 if not 5.24 use strict; use warnings; use Fcntl qw(O_RDONLY O_DIRECTORY LOCK_EX); my $dirname = "/tmp/to-be-locked"; sysopen(my $handle, "/tmp/to-be-locked", O_RDONLY | O_DIRECTORY) or die "Could not open $dirname: $!\n"; flock($handle, LOCK_EX) or die "Could not lock $dirname: $!\n"; say "locked, it seems"; sleep(3600);' I only put the sleep() part so I could check using lsof that the directory was indeed locked. And yeah, the v5.10 part is a leftover from the days (...until a month or two ago...) when I still had to support stock CentOS 7 systems; I really should train my fingers to put 5.24 there. Hope that helps! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com PGP key:https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On Tue, May 07, 2024 at 10:38:14AM +0200, Carsten Leonhardt wrote: > Luca Boccassi writes: > > > Defaults are defaults, they are trivially and fully overridable where > > needed if needed. Especially container and VM managers these days can > > super trivially override them via SMBIOS Type11 strings or > > Credentials, ephemerally and without changing the guest image at all. > > That argument goes both ways and I prefer safe defaults. What > you/upstream propose are unsafe defaults, as was shown by several > comments in this thread. Whoever wants the unsafe defaults of deleting > old files and risking OOM situations can than "trivially and fully > override" the safe defaults. So I've been wondering for a couple of days now, following this thread... ...would it be a good idea to make this a debconf prompt, high priority, default "yes", so that it is activated on new automatically installed systems, but people who upgrade their current Debian installations can choose to keep the old behavior? I do realize that more debconf prompts are not always desirable, and such decisions must be taken on a case-by-case basis, so... yeah. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Git and SHA1 collisions
On Sun, Mar 31, 2024 at 10:27:05AM +0200, Simon Josefsson wrote: > Gioele Barabucci writes: > > > But pulling a successful collision attack is not a trivial task. For > > instance, the xz attacker did not have all that was required to carry > > it out (for example they had no direct access to the git > > servers... yet). > > Is that necessary? It seems that if you have push access, you can push > a colliding commit. Does GitLab on Salsa verify (and reject?) colliding > commit ids a'la SHA1-CD? Would the tag2upload git server do that? Was that not what "the second countermeasure" part was? If a first commit has ever been pushed, the second one would not be "visible". G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Bug#1063380: ITP: libuio -- Linux Kernel UserspaceIO helper library
On Wed, Mar 13, 2024 at 10:40:51AM +, Traut Manuel LCPF-CH wrote: > > On Thu, Mar 07, 2024 at 05:02:29PM +0200, Peter Pentchev wrote: > >> On Thu, Mar 07, 2024 at 03:25:01PM +0100, Manuel Traut wrote: > >>> On 7 Feb 2024, at 18:27, Dima Kogan wrote: > >>> > >>> Hi. Thanks for your contribution. I looked at the upstream code a tiny > >>> bit, and it looks like it might have portability bug, at least on > >>> big-endian architectures. For instance: > >>> > >>> https://github.com/missinglinkelectronics/libuio/blob/6ef3d8d096a641686bfdd112035aa04aa16fe81a/irq.c#L78 > >>> > >>> This assumes that sizeof(long)==4. Maybe this is benign, but it would be > >>> nice to fix. Are you upstream or do you know upstream? Can yall fix > >>> these? > >>> > >> The kernel expects a 4 byte write here, since unsigned long is defined as > >> at least 32 bit this shall work on all architectures. > >> > >> If your concern is about endianess this is not in the current scope of > >> libuio and needs to be addressed by a higher layer. > >> > >> I am very familiar with library and in close contact with upstream. > >> > > In the case of uio_disable_irq() the bug is nicely hidden by the fact > > that tmp is guaranteed to be all-zeroes. However, consider the previous > > function in the file, uio_enable_irq(). If sizeof(unsigned long) == 8, > > then the "tmp" variable's value of 1 will be encoded in memory as > > 8 bytes containing the values 0, 0, 0, 0, 0, 0, 0, and 1 respectively. > > When uio_enable_irq() calls write(..., &tmp, 4), it will only send > > the first four bytes to the kernel - and they are 0, 0, 0, and... 0. > > So it turns out that uio_disable_irq() and uio_enable_irq() do > > exactly the same - send a 32-bit zero value to the kernel. > > > > ...of course, this will only happen on a big-endian system, as > > Dima Kogan was concerned about. On a little-endian system, this > > will work by chance. > > > > Is this the expected behavior indeed? > > No it is not :) Thanks for the detailed explanation. > > Looks this fix sane to you? > https://github.com/manut/libuio/commit/1edcf262fbfaf0b7f8519875ed5b357964dd1e55 Yeah, after I sent the e-mails I realized that I forgot to mention that using uint32_t would be one of the best ways to fix that. Thanks for the fast reaction! > I am not sure if users also expect an automatic conversion for the read/write > functions: > https://github.com/manut/libuio/commit/d0319169359bffc73374f1011e942702e9bafb1e > > It will be somehow inconsistent since a user could also access the device > memory by pointer: > https://github.com/manut/libuio/blob/add-ci/mem.c#L93 > and than needs to take care on the endianess by its own anyway. ...and this part I have no opinion about. I don't have any realistic idea about how people actually use libuio (or how they will use it), and I do not think that I will use it soon, so this should be left for others to decide. Thanks again for paying attention to the comments! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Bug#1065669: ITP: raven -- A lightweight http file upload service used for penetration testing and incident response.
On Sat, Mar 09, 2024 at 01:12:06PM +0100, Salvo Tomaselli wrote: > > In data venerdì 8 marzo 2024 18:08:11 CET, aquilamac...@riseup.net ha scritto: > > Package: wnpp > > X-Debbugs-Cc: debian-devel@lists.debian.org > > Owner: Aquila Macedo Costa > > Severity: wishlist > > > > * Package name: raven > > Version : 1.0.1 > > Upstream Contact: Tristram > > * URL : https://github.com/gh0x0st/raven > > * License : MIT > > Programming Lang: Python3 > > Description : A lightweight http file upload service used for > > penetration testing and incident response. > > > > This package contains a Python tool that extends the capabilities of the > > http.server Python module by offering a self-contained file upload web > > server. > > While the common practice is to use python3 -m http.server 80 to serve > > files > > for remote client downloads, Raven addresses the need for a similar > > solution > > when you need the ability to receive files from remote clients. This > > becomes > > especially valuable in scenarios such as penetration testing and > > incident > > response procedures when protocols such as SMB may not be a viable > > option. > > > > I'm writing to submit an Intention to Package (ITP) for raven > > under the pkg-security team's umbrella. > > What's the problem with > > nc -lp 80 > file > > ? > > Does this provide some sort of browser interface? To start with, raven seems to allow uploading more than one file :) The description on the project homepage lists several features such as access control, organizing the uploaded files into subdirectories, etc. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: 64-bit time_t transition in progress in unstable
On Thu, Mar 07, 2024 at 09:16:10PM +0100, Rene Engelhard wrote: > Hi, > > Am 07.03.24 um 21:07 schrieb Eric Valette: > > On 07/03/2024 20:55, Rene Engelhard wrote: > > > > > unstable is unstable. Don't use it if you can't handle stuff like > > > this. And yes, be it even for more days or however it takes. > > > > > > The usual mantra. However, if no one use unstable and debug it to make > > it work correctly, maintainers will discover existing bug very late in > > the process and they will impact more people. > > But not so much for dependency issues like this. Which is my sole point. In > 99,9% of cases this won't even migrate to testing. And unstable won't be > released - testing will. > > > > You should be happy people debug code > > *debug code*, yes. debug *actual* (dependency) issues, yes. > > Insisting on (bogus) bug reports about dependency issues out of maintainer > control which will "magically" be solved once the release team does the > required bin-NMU: no. One might even go so far as to say that this - uncovering problems not foreseen by the people who planned (and put a lot of work into that) the transition, then started it (and put a lot of work into that, too), and are now working every day on analyzing the problems that pop up and resolving them ASAP - so, yeah, this is the *whole point* of unstable. Catching *all* of these problems and making sure none of the libraries that might cause them ever migrates to testing - this is the whole point. So yeah, thanks a lot to the drivers of this transition, to the Release Team, and to DDs (porters and otherwise) who help with that! IMHO, it is going even better than I expected :) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Bug#1063380: ITP: libuio -- Linux Kernel UserspaceIO helper library
On Thu, Mar 07, 2024 at 05:02:29PM +0200, Peter Pentchev wrote: > On Thu, Mar 07, 2024 at 03:25:01PM +0100, Manuel Traut wrote: > > Hi Dima, > > > > > On 7 Feb 2024, at 18:27, Dima Kogan wrote: > > > > > > Hi. Thanks for your contribution. I looked at the upstream code a tiny > > > bit, and it looks like it might have portability bug, at least on > > > big-endian architectures. For instance: > > > > > > > > > https://github.com/missinglinkelectronics/libuio/blob/6ef3d8d096a641686bfdd112035aa04aa16fe81a/irq.c#L78 > > > > > > This assumes that sizeof(long)==4. Maybe this is benign, but it would be > > > nice to fix. Are you upstream or do you know upstream? Can yall fix > > > these? > > > > The kernel expects a 4 byte write here, since unsigned long is defined as > > at least 32 bit this shall work on all architectures. > > > > If your concern is about endianess this is not in the current scope of > > libuio and needs to be addressed by a higher layer. > > > > I am very familiar with library and in close contact with upstream. > > In the case of uio_disable_irq() the bug is nicely hidden by the fact > that tmp is guaranteed to be all-zeroes. However, consider the previous > function in the file, uio_enable_irq(). If sizeof(unsigned long) == 8, > then the "tmp" variable's value of 1 will be encoded in memory as > 8 bytes containing the values 0, 0, 0, 0, 0, 0, 0, and 1 respectively. > When uio_enable_irq() calls write(..., &tmp, 4), it will only send > the first four bytes to the kernel - and they are 0, 0, 0, and... 0. > So it turns out that uio_disable_irq() and uio_enable_irq() do > exactly the same - send a 32-bit zero value to the kernel. ...of course, this will only happen on a big-endian system, as Dima Kogan was concerned about. On a little-endian system, this will work by chance. > Is this the expected behavior indeed? -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Bug#1063380: ITP: libuio -- Linux Kernel UserspaceIO helper library
On Thu, Mar 07, 2024 at 03:25:01PM +0100, Manuel Traut wrote: > Hi Dima, > > > On 7 Feb 2024, at 18:27, Dima Kogan wrote: > > > > Hi. Thanks for your contribution. I looked at the upstream code a tiny > > bit, and it looks like it might have portability bug, at least on > > big-endian architectures. For instance: > > > > > > https://github.com/missinglinkelectronics/libuio/blob/6ef3d8d096a641686bfdd112035aa04aa16fe81a/irq.c#L78 > > > > This assumes that sizeof(long)==4. Maybe this is benign, but it would be > > nice to fix. Are you upstream or do you know upstream? Can yall fix > > these? > > The kernel expects a 4 byte write here, since unsigned long is defined as at > least 32 bit this shall work on all architectures. > > If your concern is about endianess this is not in the current scope of libuio > and needs to be addressed by a higher layer. > > I am very familiar with library and in close contact with upstream. In the case of uio_disable_irq() the bug is nicely hidden by the fact that tmp is guaranteed to be all-zeroes. However, consider the previous function in the file, uio_enable_irq(). If sizeof(unsigned long) == 8, then the "tmp" variable's value of 1 will be encoded in memory as 8 bytes containing the values 0, 0, 0, 0, 0, 0, 0, and 1 respectively. When uio_enable_irq() calls write(..., &tmp, 4), it will only send the first four bytes to the kernel - and they are 0, 0, 0, and... 0. So it turns out that uio_disable_irq() and uio_enable_irq() do exactly the same - send a 32-bit zero value to the kernel. Is this the expected behavior indeed? G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Setting permissions on new users in postinst
On Thu, Feb 29, 2024 at 11:12:27AM +1100, Brian May wrote: > See bug #1064349. > > I think the problem (correct me if I am wrong!) is that the postinst - > debian/amavisd-new.postinst - does (simplified): > > === cut === > #DEBHELPER# > > case "$1" in > configure) > # configure file permissions to use new amavis user > ... > esac > === cut === > > > This means that #DEBHELPER# expands to the code that creates the > users and starts the daemons. > > === cut === [snip the expanded code added by debhelper] > > [ similar for other services that are disabled by default ] > === cut === > > I think we have a race condition, the daemon tries to start before we > setup the file permissions correctly. Both on sysvinit and systemd, but > seems we can get away with this more with systemd. Probably because of > the extra checks in the initd script that systemd version doesn't have. > > But I can't move the #DEBHELPER# to the bottom, because then the setting > the file permissions would fail because we haven't added the user yet. > > How do I fix this? I haven't tested that, but my first attempt would be to add --no-start to the invocation of dh_installsystemd in your rules file (you may need to add an override_dh_installsystemd target to do that), and then your postinst script would look something like that: #DEBHELPER# setup file permissions deb-systemd-invoke start unit1 unit2... Hope that helps! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: On merging bin and sbin
On Wed, Feb 28, 2024 at 08:47:48AM -0600, r...@neoquasar.org wrote:
> > From: Gioele Barabucci
> > Sent: Wednesday, February 28, 2024 08:22
> > To: debian-devel@lists.debian.org
> > Subject: Re: On merging bin and sbin
> >
> > On 28/02/24 14:12, rhys wrote:
> > > Last thing: The idea of detecting cases where multiple binaries have the
> > > same name is a verey good one. It should also be possible to automate
> > > this effort in a number of ways. I would be happy to help with this, if
> > > it's just a matter of someone putting in the effort. A number of "crude
> > > by effective" methods have already come to mind, some of which only
> > > require access to the repos to accomplish. (The laziest method involves
> > > having a test machine with EVERY package installed... but I'm not sure if
> > > that is practical.)
> >
> > Contents-{all,amd64} has most of the info you need. dumat.db has _all_
> > the info you need (and cacin is using that).
> >
> > This is a quick'n'dirty list of binaries present in both /bin and /sbin:
> >
> > arping bin net/iputils-arping sbin net/arping (+ Conflicts:)
> > bitesize bin devel/ubuntu-dev-tools sbin misc/libbpf-tools
> > crm bin mail/crm114 sbin admin/crmsh
> > fai bin python/python3-flask-autoindex sbin admin/fai-client
> > faxq bin comm/mgetty-fax sbin comm/hylafax-server (+ Conflicts:)
> > gearmand bin perl/gearman-server sbin misc/gearman-job-server
> > htpasswd bin httpd/apache2-utils sbin web/merecat (+ Conflicts:)
> > ipp* bin net/ippsample sbin net/cups-ipp-utils (+ Conflicts:)
> > newaliases bin mail/esmtp-run sbin
> > mail/courier-mta,mail/opensmtpd,mail/ssmtp (+ Conflicts: + Provide:)
> > raddebug bin libs/librad0-tools sbin net/freeradius
> > sendfax bin comm/hylafax-client sbin comm/mgetty-fax (+ Conflicts:)
> > sethdlc bin hamradio/ax25-tools sbin comm/dahdi
> > siggen bin sound/siggen sbin utils/tripwire
> > sslh bin perl/libnet-proxy-perl sbin net/sslh (+ Conflicts:)
> > tcpconnect bin net/tcputils sbin misc/libbpf-tools
> > tcpd bin graphics/tcm sbin net/tcpd
> > update-locale bin web/gosa-dev sbin localization/locales
>
> Are any of these (like arping) literally duplicates of the same binary for
> some reason? Or are they true conflicts (different binaries with the same
> name)?
I don't know about many of the others (although I have my suspicions), but
the two programs that just happen to both be called arping are not
the same at all: they have different functionality, conflicting
command-line options, etc.
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
Re: usrmerge breaks POSIX
On Thu, Feb 15, 2024 at 10:34:32PM +, Thorsten Glaser wrote: > Russ Allbery dixit: > > >Thorsten Glaser writes: > > > >> Right… and why does pkexec check against /etc/shells? > > > >pkexec checks against /etc/shells because this is the traditional way to > >determine whether the user is in a restricted shell, and pkexec is > >essentially a type of sudo and should be unavailable to anyone who is > >using a restricted shell. > > Ah okay, makes sense…ish (sudo does not check this). It does if one configures it to by setting runas_check_shell to true. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1063880: ITP: tmpwatch -- tmpwatch is a utility searches for files not accessed in a specific time and deletes them
Package: wnpp Severity: wishlist Owner: Peter Hyman X-Debbugs-Cc: debian-devel@lists.debian.org * Package name : tmpwatch Version : 2.12 * Upstream Contact: Peter Hyman URL : https://github.com/pete4abw/tmpwatch * License : GPL Programming Lang: C Description : tmpwatch is a utility searches for files not accessed in a specific time and deletes them The tmpwatch utility recursively searches through specified directories and removes files which have not been accessed in a specified period of time. tmpwatch is normally used to clean up directories which are used for temporarily holding files (for example, /tmp). - While Debian removes files in the /tmp directory, other files may have temporary files that needs to be cleaned periodically. tmpwatch is ideally used as a cron-job. - how do you plan to maintain it? tmpwatch has not had any activity for over 5 years. Originally written by Erik Troan , Preston Brown , Mike A. Harris , Miloslav Trmač , I have forked off and added some enhancements. However, packaging for Debian has been challenging since the autogen I wrote fetches a submodule which creates lots of files not in the source package. I would need a mentor to help me get this off the ground. Original project URL is at the Fedora project page: https://pagure.io/tmpwatch -- Peter Hyman
Re: Changes to abi=+time64 behavior (was Re: 64-bit time_t transition in progress)
So when introducing a new soname (no just a new package name), then one should move to time64 even on i386 ? The problem with doing this is that 1. A reverse dependency may depend on more than one library that uses time_t in it's API. Said reverse dependency would not be able to be sanely built if libfoo uses 32-bit time_t in it's API and libbar uses 64-bit time_t in it's API. 2. If any of your reverse dependencies are libraries that expose time_t in their API they would have a similar problem.
Re: Proper handling of Lintian warnings due to other packages
On Wed, Jan 31, 2024 at 07:38:52AM +0100, Norwid Behrnd wrote: > @Lauren Because of an earlier post by you, I assume you prepare a package > which eventually requires a sponsorship by a DD. If this were true, the > upload > to https://mentors.debian.net/ would allow you to share an intermediate > version > to document your current progress -- both to replicate potential problems, as > well as to hopefully identify ways how to improve it. Later, a DD then can > use and promote your best upload to the mentors page for an upload to Debian's > repositories. In general, your advice is very good and useful, thanks! In this particular case, Lauren is working on a package maintained by the RPM packaging team, and the work is visible in a salsa.debian.org repository fork; this is another way in which one's work can be reviewed by other developers (and in this particular case, Lauren, I *will* get around to taking a look at yours soon, honest!) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Proposal for how to deal with Go/Rust/etc security bugs (was: Re: Limited security support for Go/Rust? Re ssh3)
On Wed, Jan 24, 2024 at 01:01:34PM +, Luca Boccassi wrote: > On Wed, 24 Jan 2024 at 12:26, Johannes Schauer Marin Rodrigues > wrote: > > > > Hi, > > > > Quoting Luca Boccassi (2024-01-24 12:59:38) > > > There's always option B: recognize that the Rust/Go ecosystems are not > > > designed to be compatible with the Linux distributions model, and are > > > instead > > > designed to be as convenient as possible for a _single_ application > > > developer > > > and its users - at the detriment of everybody else - and for large > > > corporations that ship a handful of applications with swathes of engineers > > > that can manage the churn, and it is not made nor intended to scale to > > > ~60k > > > packages or whatever number we have today in unstable. And simply stop > > > attempting to merge these two incompatible ecosystems against their will, > > > at > > > the very least until and unless they reach feature and stability parity > > > with > > > the C/C++ ecosystems - stable API/ABI and dynamic linking by default. > > > > > > There are many ways to ship applications today that are much better > > > suited for these models, like Flatpak, where the maintenance burden is > > > shifted onto those who choose to opt in to such ecosystems. > > > > how does that work for those applications that require rust, go and friends? > > Are you proposing that everything that needs them should be be distributed > > by a > > flatpak or similar mechanism instead? > > Those applications are not shipped in the distribution. If somebody > wants to use them, they'll have to figure it out, just like for > everything else that is not shipped in the distribution, which is > already a subset of all available software in the world. > > > Just a few days ago I tried building mesa from experimental (otherwise there > > are severe graphics glitches on my platform) on bookworm and everything > > worked > > except its rust build dependencies. I had no luck trying to backport those > > parts of rust that I needed and even if it had worked, it would've meant > > backporting dozens of rust packages just to have a backport of mesa. It > > seemed > > way simpler to just disable the mesa component that requires rust and call > > it a > > day. But that probably doesn't work for all applications and maybe sometimes > > the component written in rust is actually what you want. And in case of > > mesa, a > > flatpak of it probably would also not've helped as that would've meant that > > I > > need to run everything that I want to run with a more modern mesa based on > > that > > flatpak, right? > > > > So how is option B a solution in practice? > > You have found first-hand the exact problem with this ecosystem. Now > try to imagine doing that for 30k packages, all vendoring, pinning and > static linking against each other at different, incompatible versions. > Again, the solution in practice is to simply disable or patch out > those components, and if somebody needs them, they can complain to > upstream and ask them for a solution, if there is one. If there isn't, > though luck. And yes, that is not great - but neither are all other > options, so it seems much wiser to me to push responsibility where it > belongs - with the upstreams choosing to use such ecosystems, and the > owner of said ecosystems choosing to make them incompatible with the > distribution model, as they are in the best position to solve the > problem(s) that happen due to their design choices. This might be a minority, optimistic, rose-tinted-glasses kind of opinion, but I believe that the state of the Rust ecosystem today (I have no experience with the Go one) is quite similar to what Perl and Python modules were 25, 20, bah, even 15 years ago. Gradually, with time, the module authors realized that if they wanted people to use their modules, they would eventually have to settle on a stable API and only make incompatible changes very rarely. With time, with this realization trickling up and down across the most used libraries, things slowly start to get better. Yes, even now there are what can only be called "transitions" in the Perl and Python Debian packaging - some often-used module makes an incompatible change and the packagers need to wait until all the other packaged modules have either caught up or it has somehow been proven through testing that some of the dependent modules are not really affected by the incompatible change. In my experience, nowadays this happens much, much more rarely than 10 or 15 years ag
Re: Static analyzer / linter for debian/rules?
On 10/01/2024 07:20, Otto Kekäläinen wrote: Hi! Is anybody aware if there is some kind of static analyzer for the `debian/rules` file? Not being aware of such a tool, I usually run 'debuild -S' Much faster than a full build.
Bug#1056605: ITP: licenserecon -- Reconcile licenses from debian/copyright against license-check
Package: wnpp Severity: wishlist Owner: Peter X-Debbugs-Cc: debian-devel@lists.debian.org, pe...@pblackman.plus.com * Package name : licenserecon Version : 1.0 Upstream Contact: Peter Blackman * URL : https://salsa.debian.org/PeterB/licenserecon * License : BSD-2-clause Programming Lang: Pascal Description : Reconcile debian/copyright licenses against licensecheck output Uses licensecheck to determine file licences and, if not 'UNKNOWN', checks them against Dep5 debian/copyright. Is intended as a partial replacement for license-reconcile (removed in 2019). I use this package for checking debian/copyright in other packages I maintain. Will need a sponsor. From the man page; === lrc DESCRIPTION Lrc parses a valid DEP-5 copyright file and notes the licenses of files in the source tree. Licensecheck is then run, and the results compared. Differences between licenses in debian/copyright and the output of licensecheck are reported. It should be run in the top level of a cleaned Debian source tree, with a valid DEP-5 copyright file. The source tree should be clean, otherwise results will be contaminated by spurious reports on the build's generated files. It is advisable to run lintian first to ensure correct syntax of debian/copyright. The results are indicative only, and not a substitute for manual checking. It is intended to report obvious errors. The design intends to minimise false positives as much as is practical. However, false positives will occur if the spelling of the license short-string is not identical between the file and debian/copyright. This is quite likely with complex licensing such as 'and'/'or' constructs and specific exceptions. Only files with a copyright header are checked. False negatives may occur if licensecheck cannot determine a file's license. Files named copyright, copying, readme etc. are not checked as they often specify the licenses of other files rather than their own. EXIT CODES 0: No differences found 1: Failure to run (no debian/copyright etc) 3: License differences found SAMPLE OUTPUT Sample output invoking lrc. SUCCESS: Parsing Source Tree Running licensecheck No differences found DIFFERENCES: Parsing Source Tree Running licensecheck d/copyright | licensecheck LGPL-2.1+ | GPL-2+ test/src/config/chan.c GPL-2+ | public-domain share/lua/int/dummy.lua GPL-2+ | LGPL-2.1+ modules/access/sr_common.h AUTHOR Peter Blackman SEE ALSO licensecheck (1) 2023-11-21 1 lrc(1) Manual page lrc(1) line 7/56 (END) (press h for help or q to quit)
Re: Bug#1055198: ITP: lzfse -- LZFSE Compression library
On Sat, Nov 04, 2023 at 06:05:41PM +0100, Andreas Henriksson wrote: > On Thu, Nov 02, 2023 at 01:04:03AM +0100, Tobias Heider wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Tobias Heider > > X-Debbugs-Cc: debian-devel@lists.debian.org > > > > * Package name: lzfse > > Version : 1.0 > > Upstream Authors: > > URL : https://github.com/lzfse/lzfse > > * License : BSD-3-Clause > > Description : LZFSE Compression library > > > > LZFSE is a Lempel-Ziv style data compression algorithm using Finite > > State Entropy coding. It targets similar compression rates at higher > > compression and decompression speed compared to deflate using zlib. > > > > I plan to maintain this as part of the bananas team. > > Calling all SO versioning experts! > > The upstream project does not have any shared object version set. > A downstream patch was introduced to set one: > https://salsa.debian.org/bananas-team/lzfse/-/blob/debian/unstable/debian/patches/0001-debian-set-library-SONAME.patch > > Upstream has seen no activity since 2017, so trying to interact is > assumed to not generate much. (sorry, I imagine you are already aware of what I am about to say, but still I think it's worth saying... Apologies if I'm lecturing, I think you may have been a DD longer than I have :)) This... may be a problem. This means that any fixes you have to make (security fixes, important bug fixes, or just improvements that really, really bug your sense of doing things right) will be specific to the Debian package, and unless the other packaging systems pick them up, with time things will diverge further and further. The best thing to do in this case is to - somehow - try to push things in a direction that ultimately leads to the library having active upstream developers. This may mean having you or somebody you know try to contact the current developers and ask to join them. In a close-to-the-extreme version of this, this may mean you (or somebody you know) taking over upstream development with the consent of the current developers. In a really, really extreme version, it may mean forking the project without the consent of the current developers and facing various kinds of weird things down the road, especially if they wake up one day and decide to carry on as usual, ignoring your fork. One thing to note that I have learned from bitter experience: you may feel that it would be fun and it would not be too difficult to take over upstream development, and doing this too many times may lead to a situation that you are the upstream developer for too many things and you cannot really give most of them enough attention. There is no single right answer here, but it would certainly be much, much, much better for everyone involved (including the end users of your Debian package, people who install something that uses this library) if there were an active upstream. > Also the ABI is unlikely to change (since > no changes are being made). Yeah... see above about the upstream developers waking up one day and deciding to carry on :) Also, it is possible that some packager from antoher packaging system decides to go ahead and fork the project... But still, those are all hypotheticals. > I've previously suggested that maybe it would be better to set a > debian-specific version (0d?), to avoid the theoretical situation > that upstream one day ships a different ABI under the 1 so version. > > I would welcome peoples input here on what you think is best from > the debian perspective. Obviously we're going to be incompatible with > everyone else[1], unless you install/runtime-depend-on the -dev package > for the unversioned so symlink. Please speak now before this is > submitted for NEW. When you say "incompatible with everyone else", how do other packaging systems handle this? Has this library been packaged somewhere else? It might be a good idea to do the same thing as some other packaging system... but it may also turn out that all of the current ones have chosen (possibly different) suboptimal ways to handle this, so being incompatible with them may turn out to be the best option for Debian itself. As above, there is no single right answer here. > FWIW lzfse is needed to extract files compressed by Apple and shipped in macOS > containing embedded firmwares. See asahi-fwextract ITP: #1055206 > > Regards, > Andreas Henriksson > > > [1]: > https://salsa.debian.org/bananas-team/asahi-fwextract/-/blob/debian/unstable/debian/patches/0001-Use-versioned-library-name-for-liblzfse.patch G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Control header sent with done email didn't do what I expected, should it have?
On 25/09/2023 14:25, Jonathan Kamens wrote: So putting a Control: line in the pseudo-header of a message sent to ###-d...@bugs.debian.org doesn't work at all? It should work if the syntax is correct. The + character was missing.
Re: Control header sent with done email didn't do what I expected, should it have?
On 25/09/2023 12:16, Jonathan Kamens wrote: Hi all, I recently tried to close a bug, explain why, and set a "wontfix" tag all at once by sending my explanation to ###-d...@bugs.debian.org with "Control: tags ### wontfix" as the first line of my message body. The bug was closed but the tags command wasn't processed. Looking at the raw message file that I sent, I see that my mailer encoded the text/plain MIME body part with base64 because I had pasted into the body a quote from a web site that used non-ASCII quotation marks (d'oh). Is that why BTS failed to process the "Control:" command? If yes, then is this a known thing that's not going to change that I should just live with ;-), or should I file a bug about it? If no, then can anyone tell me what else I did wrong to cause the "Control:" command not to be processed? Thanks, jik see https://www.debian.org/Bugs/server-refcard It should be tags bugnumber + wontfix sent to cont...@bugs.debian.org best to have package foo on the first line in case of typos in the bug number!
Bug#1052135: ITP: check-build -- Check whether some example programs can be compiled and built
Package: wnpp Severity: wishlist Owner: Peter Pentchev X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Python Team , r...@debian.org * Package name: check-build Version : 0.1.0 Upstream Contact: Peter Pentchev * URL : https://gitlab.com/ppentchev/check-build * License : BSD-2-clause Programming Lang: Python Description : Check whether some example programs can be compiled and built The `check-build` tool can be used to build and test different programs in a temporary build directory. The programs are listed in a TOML configuration file, along with the commands to build and test them. A bundled copy of the check-build library is used in the libzstd autopkgtest to make sure that the C library's -dev package contains enough files so that a program that uses the library can be built. It will be removed in the next libzstd upload as soon as this package hits the archive. I will maintain this package as part of the Debian Python Team. signature.asc Description: PGP signature
Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages
On Sun, Sep 17, 2023 at 09:31:03AM +0530, Hideki Yamane wrote: > On Sat, 16 Sep 2023 13:34:02 +0200 > Guillem Jover wrote: > > That's not correct. dpkg-deb is doing multi-threaded xz decompression > > since 1.21.13, and dpkg-source is doing multi-threaded xz compression > > and decompression since 1.21.14. > > > > Also the Ubuntu zstd implementation did not have multi-threaded support > > at all, the one implemented in dpkg 1.21.18 does have explicit > > multi-threaded support for _compression_, but AFIUI (from zstd code and > > its API being used in libdpkg) not for decompression. > > Thank you, that was my fault, correct information is very welcoming. > > Is there any plan to improve zstd implementation in dpkg? FWIW, if people think that it would be beneficial for libzstd to be built against libpthread (which seems to be the only way it supports multithreaded operation right now), this could be arranged - I just never thought anybody wanted that until now. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Do not plan to support /usr/lib/pam.d for Debian pam
On Fri, Sep 15, 2023 at 09:53:24PM +0100, Luca Boccassi wrote: > On Fri, 15 Sept 2023 at 21:08, Sam Hartman wrote: > > > > > > > > Apropos of the discussion about removing default configuration from > > /etc. > > Upstream PAM now supports doing that. You can set up a vendor directory > > such as /usr/lib where pam.d and security live. > > > > I thought about doing that for Debian PAM, and have decided against. > > My rationale is that I actually think dpkg gives superior handling of > > upstream configuration changes to what we'd get with the pam vendor dir > > *in the specific case of PAM*. > > > > In particular, dpkg will let you know if the conf file has changed > > upstream and you have local changes. > > If we create a vendor directory, you will have to diff yourself to > > discover that. > > > > I do think that in the case of programs like systemd that do a complex > > merge of drop in fragments, the split of vendor dir from sysadmin dir > > makes a lot of sense. > > > > But for the most part PAM appears to just override on a file-by-file > > basis. > > And for that use case, I think dpkg's handling is at least as good. > > I appreciate others might differ. With dpkg's conffile handling you get > > better notification of changes but is it is hard to see at a glance > > which files might be changed. > > > > I am in favor of having a mechanism to easily reset the state in /etc. > > Personally I'm not convinced that deleting /etc is the best way for > > Debian to do that. > > I think we might be able to find dpkg-based solutions that are superior. > > > > If Debian does develop a project consensus behind minimizing > > /etc--especially if there is a policy recommendation or encouragement in > > this direction, then I'll revisit how we handle this for PAM. > > > > If Debian develops another approach for resetting local state, I'll be > > eager to look at that for PAM. > > With the provision that I know next to nothing about pam - if I > understood correctly how it works, why not simply do both? Ship the > default file in the package under both /usr and /etc. Then, you get > the semantics you want with local changes tracking, and /etc wins over > the defaults. And we can have a working, bootable Debian container > with only /usr. As far as I've been told, pam is the only blocker > there - for a minimal image of course, but that's still quite a good > achievement. Wouldn't this work, or am I missing something? Hm, what happens if a sysadmin deliberately removed a file that the distribution ships in /etc, trying to make sure that some specific service could never possibly succeed if it should ever attempt PAM authentication? Then, if there is a default shipped in /usr, the service authentication attempts may suddenly start succeeding when the PAM packages are upgraded on an existing system. Yes, I know that the override/drop-in mechanism provides a way to do that by creating a /dev/null override symlink, but the sysadmin would not have needed to do that - until now, when they suddenly do. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Bug#1050005: ITP: pdftopng -- Convert PDF to PNG
On Tue, Aug 22, 2023 at 01:24:42PM +0200, Mathieu Malaterre wrote: > On Fri, Aug 18, 2023 at 1:19 PM Marvin Renich wrote: > > > > * Elena Grandi [230818 05:27]: > > > Package: wnpp > > > Severity: wishlist > > > Owner: Elena Grandi > > > > > > * Package name: pdftopng > > > Description : Convert PDF to PNG > > > > > > A command line tool and python library to convert PDFs to PNGs, based on > > > pdftoppm from poppler. > > uh ? > > % pdftoppm -h 2>&1| grep png > -png : generate a PNG file > > > > This is a dependency of camelot-py (#1049944) and I intend to maintain > > > it in the Python Team. > > > > Does pdftocairo from the poppler-utils package do what you need? If > > not, would it make sense to submit patches to add pdftopng to the > > poppler-utils package instead of creating a separate package for it? > > ...or at least document why pdftoppm is not suitable. I would imagine, since the original ITP also mentioned a Python project that requires this package, that the "Python library" part may be important: the upstream authors of the other project may have decided to use it, as a Python library, instead of fiddling with child process management by themselves. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: autodep8 test for C/C++ header
On Mon, Aug 07, 2023 at 06:43:36PM +, Benjamin Drung wrote: > Hi, > > while working a whole week on fixing failing C/C++ header compilations > for armhf time_t [1], I noticed a common pattern: The library -dev > packages was missing one or more dependencies on another -dev package. > Over 200 -dev packages are affected. > > I propose to add an autodep8 test for C/C++ header files that tries to > compile the header file. This will catch issues like missing > dependencies and other issues. > > Here is a draft for the autopkgtest check script that takes a binary > -dev package as parameter: > https://github.com/bdrung/bdrung-scripts/blob/compile-header-check/compile-header-check > > What do you think? Should I proceed developing and packaging this check > script and submit support for it in autodep8? > > [1] https://salsa.debian.org/vorlon/armhf-time_t/-/merge_requests/103 Whlie it does seem an interesting tool at first glance (and thanks for doing the work and presenting a proof of concept), I can think of several cases when compilation of the concatenated header files would fail: 1) The library has a "main" header file that must be included before any of the others, and it does not come first in lexicographical order. It may define typedefs and structure definitions that the other header files can use, it may define preprocessor symbols that reflect the availability of this or that system header file or type; there are also other ways in which another header file distributed by the -dev package may depend on the main one. 2) As a variation of the above, the -dev package may distribute the full set of header files included in the library, and some of them may only be included if certain preprocessor symbols are defined. Since their use is guarded by conditionals, they are allowed to unconditionally include system-specific header files that are only available on e.g. Windows or NetBSD or Darwin, etc. Unconditionally compiling the contents of those files would fail. 3) The -dev package may distribute the full set of header files included in the library, and some of them may be mutually exclusive and impossible to combine. For example, a header file may include either this or that other header file based on preprocessor defintions (OS type, features enabled, etc), and the included files may both define a function with the same name, but different contents. 4) Some of the library's header files may not be supposed to be included in all cases; the library's -dev package may suggest (but not depend on or recommend) another -dev package as an optional dependency, and a library's header file may unconditionally include some header file from the latter package. All of these cases are things I've seen in complex libraries with many header files; maybe not all of them can be found in Debian right now. So... yeah. Thanks for your work, I know you mean well and you are trying to make the life of Debian developers better, but this particular approach will likely fail on a non-trivial set of Debian -dev packages. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1042088: ITP: lrzip-next -- lrzip-next is an enhanced version of the lrzip package with many new features.
Package: wnpp Severity: wishlist Owner: Peter Hyman X-Debbugs-Cc: debian-devel@lists.debian.org * Package name : lrzip-next * Version : 0.12.0 * Upstream Contact: Peter Hyman * URL : https://github.com/pete4abw/lrzip-next * License : GPL * Programming Lang: C, C++, Assembler, Bash Shell * Description : lrzip-next is an enhanced version of the lrzip package with many new features. lrzip-next is the successor to Con Kolivas' lrzip program. It is a compression program that uses a two stage process. First, the file is pre-processed using Andrew Tridgell's rzip functions that hashes the source file over long range. Second, the hashed and data streams are compressed by user-selected compression backends. These are: bzip2, bzip3, gzip, lzo, lzma, zpaq, and zstd. Alternately, a pre-processing BCJ filter for multiple architectures can improve binary executable compressions. Finally, a Delta offset filter can be applied. Very useful for WAV or PCM files. lrzip-next is current with lzma SDK 23.01 and zpaq SDK 7.15. Archives can be hashed or compressed using any of thirteen hashes or two different encryption algorithms: AES-128 or AES-256. lrzip-next will coexist with lrzip as no installed filenames overlap. - why is this package useful/relevant? lrzip-next is under active development. it includes additional compression backends: bzip3, zstd. it can optionally use BCJ and Delta filters for pre-processing. it uses the upstream x86_64 Assembler code to improve decompression (up to 40% faster) and compression time. it uses libgcrypt for hashing and encryption functions. - Is it a dependency for another package? NO - Do you use it? YES - If there are other packages providing similar functionality, how does it compare? lrzip uses lzma SDK 9. lrzip-next uses lzma SDK 23.01. lrzip uses zpaq SDK 4, lrzip-next uses the last zpaq SDK 7.15. lrzip-next keeps current with all lzma upstream fixes and enhancements. (zpaq is no longer maintained). lrzip supports 32 bit systems. lrzip-next only support x64 systems. lrzip-next uses all 9 lzma compression levels, lrzip only 7. lrzip-next allows custom lzma dictionary, bzip3 and zpaq block sizes, zstd compression levels to 22. lrzip-next adds BCJ and Delta pre-filters from lzma SDK. lrzip-next allows for archive comments. lrzip-next has improved user output, man pages, and a full wiki. lrzip-next is under active development. lrzip has been on version 0.6xx since 2011. lrzip-next tracks lrzip development and any CVE or other critical fixes are imported where relevant. - How do you plan to maintain it? inside a packaging team? I have written a package for it, but would appreciate being part of a team. I would need support porting and testing lrzip-next to other 64-bit architectures. - Are you looking for co-maintainers? do you need a sponsor? Laszlo Boszormenyi (GCS) is the maintainer for lrzip. As I am new to Debian (Slackware since 1997), It makes sense that he could support me or others involved in compression applications. Thank you -- Peter Hyman
Re: Proposed MBF - removal of pcre3 by Bookworm
On Sun, Jul 02, 2023 at 10:14:58AM +0100, Alastair McKinstry wrote: > > On 01/07/2023 14:44, Michael Stone wrote: > > On Thu, Jun 29, 2023 at 08:55:11PM +0100, Matthew Vernon wrote: > > > Bookworm is now out; I will shortly be increasing the severity of > > > the outstanding bugs to RC, with the intention being to remove > > > src:pcre3 from Debian before the trixie release. > > > > You don't think that marking packages for removal two weeks after the > > bug is filed is a little much? > > There's significant work creating and testing patches for this transition. > Marking removal is too much. On the other hand, the bugs have been open for an year and a half now... G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: FTBFS (reprotest) on all recent uploads
On 20/06/2023 05:31, Joachim Zobel wrote: I can see two logs of successful builds and a diff for them. Looks to me like the 2nd build is aborting. .. I: Building the package I: user script /srv/workspace/pbuilder/1086848/tmp/hooks/A99_set_merged_usr starting Re-configuring usrmerge... removed '/etc/unsupported-skip-usrmerge-conversion' dpkg-query: package 'usrmerge' is not installed and no information is available Use dpkg --info (= dpkg-deb --info) to examine archive files. /usr/sbin/dpkg-reconfigure: usrmerge is not installed I: unmounting dev/ptmx filesystem I: unmounting dev/pts filesystem I: unmounting dev/shm filesystem I: unmounting proc filesystem I: unmounting sys filesystem I: cleaning the build env I: removing directory /srv/workspace/pbuilder/1086848 and its subdirectories This is happening for a lot of packages, but reprotest seems fine on Salsa.
Re: 64-bit time_t transition for 32-bit archs: a proposal
Hi, On Wed, Jun 7, 2023, at 09:19, Sune Vuorela wrote: > lisp runtie. unsure why restricted >> cmucl deb lisp optional arch=i386 >> cmucl-clm deb lisp optional arch=i386 cmucl contains a compiler and is self hosting (the compiler is used to create the new version of the environment). x86 is the last active architecture for this system, but as a whole it is slowly drying. Most people moved on to using sbcl, which supports amd64 and has a more active development. I planned to ask for removal of cmucl after the next release. End of an era... Best regards, Peter
Bug#1035883: general: TMOUT and autologout are set to 3600, but logout occurs much earlier
Dear Jim, On 10.05.23 17:01, Jim Anderson wrote: I realize that auto logout is a general security feature, but in my case, I have a secrure environment where only my wife and I have access to my computer. I strong prefer to NOT have my computer auto logout for 10 hours, allowing me to leave my computer in the evening and return to it in the morning without haveing to log on. I have the enrivonment variables TMOUT and autologout both set to 36000, or 10 hours, but these are not honored by the system. from what does your computer log you out when it logs you out: A graphical user session or a shell session? TMOUT only controls the time-out of shell sessions. Best regards, Peter
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On Mon, May 15, 2023 at 12:24:15AM +0100, Luca Boccassi wrote: > On Sun, 14 May 2023 at 22:37, Josh Triplett wrote: > > > > On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote: > > > The loader is still available via the old path, so external/third > > > party/local/other software works unchanged. This should negatively > > > only affect our 1st party packages, when running on a non-merged > > > distro. > > > And are _all_ our packages really 100% compatible with other distros > > > at all? Are they even supposed to be? > > > > People build things on Debian that are not Debian packages. People > > compile binaries on Debian, and expect them to work on any system that > > has sufficiently new libraries. > > > > This is *not* about Debian packages failing to work on other > > distributions; this is about *software compiled on Debian* faliing to > > work in other environments. > > Why would "software compiled on Debian" fail to work in other > environments? Well, there are many reasons actually, people invented > containers/flatpaks/snaps exactly for that reason. But nothing do with > anything discussed here though, as far as I can tell? If an ELF executable, compiled on Debian, records its interpreter as /usr/lib/ld-linux.so.2, what happens when one tries to run it on a non-usr-merged system? Even one with a recent enough glibc version? G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1035747: ITP: cevomapgen -- External Map Generator for C-Evo
Package: wnpp Severity: wishlist Owner: Peter X-Debbugs-Cc: debian-devel@lists.debian.org, pe...@pblackman.plus.com * Package name : cevomapgen Version : 26 Upstream Contact: * URL : https://sourceforge.net/projects/cevomapgen/ * License : GPL3+ Programming Lang: Lazarus/FPC Description : External Map Generator for C-Evo Generates more varied maps than the in-game generator, with greater control, and allows much faster generation of novel or extreme worlds than using the map editor. Intended for use with c-evo-dh and other versions of C-evo Regards, Peter
Bug#1035103: ITP: cdreaper -- Graphical audio CD ripper and encoder
Package: wnpp Severity: wishlist Owner: Peter X-Debbugs-Cc: debian-devel@lists.debian.org, pe...@pblackman.plus.com * Package name : cdreaper Version : 3.0.0 Upstream Contact: Salamandar * URL : https://gitlab.gnome.org/Salamandar/Reaper * License : GPL2 Programming Lang: C Description : Graphical audio CD ripper and encoder Can be used to save tracks from Audio CDs. Main features: * Supports WAV, MP3, Ogg Vorbis, FLAC, and Wavpack audio files * Uses CDDB to name and tag each track * Can encode to multiple formats in one session * Creates M3U playlists * Allows for each track to be by a different artist * Does not require a specific desktop environment (just Gtk3) This is the Gtk3 fork of asunder (it now has its own name) I have called this package cdreaper, as the name reaper is already in use elsewhere; https://repology.org/project/reaper/versions I will maintain the package myself and need a sponsor. The package has been set up on the AUR and Open Build Service. https://aur.archlinux.org/packages/cdreaper https://build.opensuse.org/package/show/home:PeterBBB/cdreaper
Re: Upgrade package from init script to Systemd, move config folder
On Thu, Apr 27, 2023 at 10:54:58AM +0200, Marc Haber wrote: > On Thu, 27 Apr 2023 08:20:34 +0200, Simon Richter > wrote: > >On Wed, Apr 26, 2023 at 04:25:19PM +0200, Marc Haber wrote: > >> I am not sure whether it is doing non-systemd users a favor to keep a > >> probably outdated, bitrotting and untested init script in the > >> canonical place. My gut feeling is that it might be better to ship the > >> old init script in /usr/share/doc/package/examples unless the package > >> maintainer is reasonably sure that the init script will actually work. > > > >No, that is worse, because if an updated init script is shipped as an > >example only, I will not even get a notification that I might want to > >change my installed init script. > > You have a point here. Maybe it would be a good idea to have a > standardized function in /lib/lsb/init-functions that emits a warning > that the package maintainer has changed the mechanism to invoke the > daemon and that the init script might need additional work, so that a > lazy maintainer like me might just call that function to give the > local admin a heads-up. If systemd runs as init, I do not think such a warning is needed, since trying to run /etc/init.d/foo will be transparently redirected to an invocation of the (supposedly maintained) systemd service (unless, of course, somebody explicitly performs the incantation to really, really run the SysV init script, in which case I would assume they know what they are doing, and also see the next point). If sysv-init runs as init, then I'm not sure such a warning at each invocation of the init script would actually be useful: first, it might be missed, and second, the admin may (consciously or not) learn to ignore it. I think a one-time notification via a (Debian) NEWS entry would be a better choice. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Help with a libzstd sparc64 FTBFS on the buildd
On Thu, Apr 06, 2023 at 05:01:07PM +0200, Paul Gevers wrote: > Hi Peter, > > On 06-04-2023 15:37, Peter Pentchev wrote: > > I feel like I cannot ask for an unblock from the release > > managers since the sparc64 buildd started failing on this package > > at some point in February: > > sparc64 is not a release architecture. sparc64 will not be better or worse > if something migrates. I suggest to consider those problem separately. TBH, that was my own understanding, and I was about to send an unblock request earlier today, but then I decided to take another look at the freeze policy and the phrase "migration for packages only allowed if all their binary packages have been built on buildds" threw me a bit. But yeah, I should have realized that should only apply to release architectures... thanks for correcting my thinking! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Help with a libzstd sparc64 FTBFS on the buildd
On Thu, Apr 06, 2023 at 04:37:16PM +0300, Peter Pentchev wrote: > Hi, > > The libzstd package in testing is currently missing a couple of > build-time tests and a fix for a very rare data corruption bug. > Both of these have been fixed in libstd-1.5.4+dfsg2-5 in unstable; ...of course this should have been libzstd-1.5.4+dfsg2-5 > however, I feel like I cannot ask for an unblock from the release > managers since the sparc64 buildd started failing on this package > at some point in February: > > https://buildd.debian.org/status/logs.php?pkg=libzstd&arch=sparc64 > > Now, the -1, -2, and -4 failures I can explain: there were some > problems in the upstream test suite that were fixed in -3 and -5. > However, -3 and -5 should really not have failed: they built > successfully on all other architectures where the build dependencies > were installable, and they also passed autopkgtest runs: > > https://ci.debian.net/packages/libz/libzstd/ > > I set up a qemu-based sbuild environment on my laptop, and > I built the libzstd package successfully. Is it possible that > something is wrong with the sparc64 buildd? Could somebody with > an actual sparc64 box try to build libstd-1.5.4+dfsg2-5 and > let me know if it works for them? ...and of course this should also have been libzstd-1.5.4+dfsg2-5 > Thanks in advance! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Help with a libzstd sparc64 FTBFS on the buildd
Hi, The libzstd package in testing is currently missing a couple of build-time tests and a fix for a very rare data corruption bug. Both of these have been fixed in libstd-1.5.4+dfsg2-5 in unstable; however, I feel like I cannot ask for an unblock from the release managers since the sparc64 buildd started failing on this package at some point in February: https://buildd.debian.org/status/logs.php?pkg=libzstd&arch=sparc64 Now, the -1, -2, and -4 failures I can explain: there were some problems in the upstream test suite that were fixed in -3 and -5. However, -3 and -5 should really not have failed: they built successfully on all other architectures where the build dependencies were installable, and they also passed autopkgtest runs: https://ci.debian.net/packages/libz/libzstd/ I set up a qemu-based sbuild environment on my laptop, and I built the libzstd package successfully. Is it possible that something is wrong with the sparc64 buildd? Could somebody with an actual sparc64 box try to build libstd-1.5.4+dfsg2-5 and let me know if it works for them? Thanks in advance! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Introducing Declarative Debian
On Wed, Apr 05, 2023 at 07:22:32PM -0600, Gunnar Wolf wrote: > Didier 'OdyX' Raboud dijo [Sun, Apr 02, 2023 at 03:54:55PM +0200]: > > > For example: > > > * httpserver-is-apache > > > * imapserver-is-dovecot > > > > You need to think larger! > > > > * christoph-got-you-to-think-about-this-seriously > > * april-s-fool-is-less-and-less-fun-in-an-era-of-fakenews > > * I-genuinely-giggled-though > > However, I insist on consistent naming. At least we should require all > declarative-named packages to follow a proper foo-is-bar name until > the secret project to include ChatGPT as a dependency for apt is > finally ready to be announced. How are we doing on the main prerequisite for that? I mean, yeah, an effort to get all DDs and DMs to sign an "I, for one, welcome our new robotic overlords" pledge is hard enough, but doing it as a good phishing campaign with a large chance of success makes it a lot harder. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: dh_auto_test: use check target instead of the test target
On Mon, Mar 27, 2023 at 09:55:25PM +0200, Jerome BENOIT wrote: > Hi ! > Is there a simple way to force dh_auto_test(1) to use the `check` target but > not the `test` target ? > Thanks in advance, If I understand you correctly, something like the following might work: override_dh_auto_test: dh_auto_test -- check (any arguments after the ones that the debhelper tools understand will be passed right on through to the build tools that they execute) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1033413: ITP: profile-cleaner -- Reduces browser profile size by cleaning their sqlite databases
Package: wnpp Severity: wishlist Owner: Peter X-Debbugs-Cc: debian-devel@lists.debian.org, pe...@pblackman.plus.com * Package name : profile-cleaner Version : 2.44 * URL : https://github.com/graysky2/profile-cleaner * License : Expat Programming Lang: Bash Description : Reduces browser profile size by cleaning their sqlite databases Reduces the size of browser profiles by organizing their sqlite databases using sqlite3's vacuum and reindex functions. The term "browser" is used loosely since profile-cleaner happily works on some email clients and newsreaders too. I will maintain the package myself, and will need a sponsor.
Re: Adding epoch to kworkflow package to correct a wrong upstream version
Dear IOhannes, On 12.03.23 18:48, IOhannes m zmölnig wrote: Could lintian warn when a date based version is used? Lintian already does this - see [0]. Best regards, Peter [0] https://salsa.debian.org/lintian/lintian/-/blob/f03fc15a45df4965e374b1e3a40c51cf6fe545ed/tags/n/new-package-uses-date-based-version-number.tag
Re: Yearless copyrights: what do people think?
On Wed, Feb 22, 2023 at 03:26:47PM +0200, Peter Pentchev wrote: > On Wed, Feb 22, 2023 at 01:55:02PM +0100, Jonas Smedegaard wrote: > > Quoting Peter Pentchev (2023-02-22 10:49:30) > > > So I've seen this idea floating around in the past couple of years > > > (and in some places even earlier), but I started doing it for > > > the couple of pieces of software that I am upstream for after reading > > > Daniel Stenberg's blog entry: > > > https://daniel.haxx.se/blog/2023/01/08/copyright-without-years/ [snip my original message] > [snip useful information] > > As a redistributor I find it a good practice to include most possible > > copyright and licensing information provided by upstream authors, > > exactly because we are doing a service for our users, and it is a slight > > disservice to omit information that upstream put effort into tracking > > and publishing. > > Wait, I may have been unclear. I did not mean that I want to omit > the upstream copyright years *when they are there*. And, of course, > if upstream does not specify any copyright years, we cannot invent > any out of thin air. So I guess my question was mainly what people > think about dropping the years in the debian/* copyright notice > (packaging files, patches, etc). OK, so it seems I did it again: I sent out my original message before really knowing myself what exactly the questions are that I mean to ask :) So now that I have thought about it a little, here they are: 1. Does the Debian Project consider it okay for an upstream package to include one or more (or all) files with clear license grants (either included or referred to in the files), and with clear copyright notices (again, either in the files or in a central file) that contain the authors' names, but no years? Does such a package comply with the DFSG? I believe the answer ought to be "yes", but I thought it wouldn't hurt to ask. 2. If an upstream project does that, the debian/copyright file should reflect that and have a `Files: *` (or whatever pattern) notice that has a copyright notice without any years... right? And if an upstream project does that between releases, the debian/copyright file should change (drop the years) in the next "new upstream release" upload... right? 3. Now, what about the `Files: debian/*` section of the debian/copyright file? The common wisdom seems to be that, if only to make it easier to submit patches to the upstream project, the debian/* files ought to be licensed under the same terms as the upstream source. Now I know that licensing and copyright are different things :) So would the Debian Project consider it okay for a Debian package to have a `Files: debian/*` section in its copyright file that does not mention any years? This question is both from a DFSG point of view and from a "what would be best for our users" one. And does the answer depend on whether the upstream project's copyright notices include years or not? (as in, should we follow upstream's lead in that, too) Note that none of that comes from any "it's so difficult" positions; I am actually one of the people who would include file-by-file stanzas in the debian/copyright files for upstream files with different copyright years :) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Yearless copyrights: what do people think?
On Wed, Feb 22, 2023 at 01:55:02PM +0100, Jonas Smedegaard wrote: > Quoting Peter Pentchev (2023-02-22 10:49:30) > > So I've seen this idea floating around in the past couple of years > > (and in some places even earlier), but I started doing it for > > the couple of pieces of software that I am upstream for after reading > > Daniel Stenberg's blog entry: > > https://daniel.haxx.se/blog/2023/01/08/copyright-without-years/ > > > > And then, a couple of weeks ago, I quietly checked whether > > the Debian FTP team would be okay with that by uploading two NEW > > packages without any years mentioned in the debian/copyright file: > > either upstream or for my Debian packaging. And, lo and behold, > > they were both accepted (python-parse-stages and python-test-stages). > > > > So how do people feel about this in general, would it be okay for > > me to start doing it: > > a) for other packages that I maintain personally, outside any team > > b) for team-maintained packages (I guess this one might be a per-team > >decision, discussed separately on the appropriate lists) > > > > (obviously, I'm not asking for permission or anything; apparently > > at least one member of the FTP team is okay with me doing it at > > least for some packages. This is more of a "float the idea, see > > what people think about doing this more widely, not just me") [snip useful information] > As a redistributor I find it a good practice to include most possible > copyright and licensing information provided by upstream authors, > exactly because we are doing a service for our users, and it is a slight > disservice to omit information that upstream put effort into tracking > and publishing. Wait, I may have been unclear. I did not mean that I want to omit the upstream copyright years *when they are there*. And, of course, if upstream does not specify any copyright years, we cannot invent any out of thin air. So I guess my question was mainly what people think about dropping the years in the debian/* copyright notice (packaging files, patches, etc). G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Yearless copyrights: what do people think?
Hi, So I've seen this idea floating around in the past couple of years (and in some places even earlier), but I started doing it for the couple of pieces of software that I am upstream for after reading Daniel Stenberg's blog entry: https://daniel.haxx.se/blog/2023/01/08/copyright-without-years/ And then, a couple of weeks ago, I quietly checked whether the Debian FTP team would be okay with that by uploading two NEW packages without any years mentioned in the debian/copyright file: either upstream or for my Debian packaging. And, lo and behold, they were both accepted (python-parse-stages and python-test-stages). So how do people feel about this in general, would it be okay for me to start doing it: a) for other packages that I maintain personally, outside any team b) for team-maintained packages (I guess this one might be a per-team decision, discussed separately on the appropriate lists) (obviously, I'm not asking for permission or anything; apparently at least one member of the FTP team is okay with me doing it at least for some packages. This is more of a "float the idea, see what people think about doing this more widely, not just me") Thanks for reading this far, and keep up the great work! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Bug#1030785: -ffile-prefix-map option and reproducibility
On Tue, Feb 14, 2023 at 09:51:50AM +, Simon McVittie wrote: > On Tue, 14 Feb 2023 at 10:21:31 +0200, Peter Pentchev wrote: > > I can't speak of many other systems, but at least with Perl's XS > > (the standard way to write Perl modules parts of which are compiled C code) > > and two of the ways this can be done in Python, it is the same: > > the C compiler's name and flags are recorded at the time the "wrapper" is > > built, so that they can be used later. At least IMHO, this has two main > > benefits: > > - people (or programs) that want to build a Perl/Python/OCaml/whatever > > module do not have to know anything about C compilers, flags, > > optimization, > > language-specific libraries[1] , etc. The consumers tell their own > > language > > ecosystem "look, I need to compile something that has C parts in it, go do > > something about it", and the wrapper for the C compiler knows exactly what > > to do > > - everything is compiled using the same compiler[2], the same optimization > > flags, the same libraries, etc., so one module that has C parts in it can > > call the C functions from another module directly with no fear of any kind > > of calling convention mismatch or whatever > > I think this is very common, but really a bit too simplistic. Some of > the compiler flags are part of an interface between components, and for > those flags, it makes sense to record them in the compiler-wrapper or > in some metadata file like a pkg-config .pc file; but some of them are > private implementation details of the component currently being compiled, > and don't make sense to replicate between components. > > For instance, -lpython3.11 is certainly part of the interface, -O2 -g > is not part of the interface *on Debian* but might be on other platforms > (on glibc systems there's only one C runtime library, but Microsoft > compilers use different and incompatible runtime libraries for release and > debug builds), but facts about the build directory like > -I/tmp/python3.11-3.11.2/Include or > -ffile-prefix-map=/tmp/python3.11-3.11.2=. are certainly not part of the > interface. > > Neither are warning-control options like -Wall or > -Werror=implicit-function-declaration, really: just because the Python > maintainers want warnings or even errors when comiling Python, that > doesn't necessarily mean it's right to require all Python extension > modules to be built with those same warnings. Right, when I said "record the compiler flags", I did not mean "and always pass them on verbatim". I think you may already know this, since you talk about Python, but yeah, in Python's case things are really not that simple. This command: python3 -c 'import pprint; import sysconfig; pprint.pp(dict(item for item in sysconfig.get_config_vars().items() if "CFLAGS" in item[0]));' ...displays all of the "system configuration variables" (pretty much exactly things recorded at Python build time) that have "CFLAGS" in their name, and at least with Python 3.11 in testing, there are *a lot* of those. Some of them are obviously module-specific configuration for the various Python standard library modules, but there are others, too. Other systems record compiler (and linker, etc) flags with different granularity, but yes, you are correct that it makes a lot of sense to take care what is recorded and how. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Bug#1030785: -ffile-prefix-map option and reproducibility
On Tue, Feb 14, 2023 at 09:04:47AM +0100, Stéphane Glondu wrote: > Hi, > > Le 08/02/2023 à 10:58, Emilio Pozuelo Monfort a écrit : > > What is the purpose of having the build flags in a file in the .deb? > > ocamlc can act as a driver for the C compiler, to compile C stubs with the > "right" flags. These flags are basically the CFLAGS ocaml was compiled with, > plus some additional OCaml-specific flags (like -fwrapv). > > But I wonder now: shouldn't the CFLAGS part be queried from the environment > at use time, rather than at OCaml compilation time? This setting of a non-C > compiler calling a C compiler must happen often... I don't know what's the > practice elsewhere. I can't speak of many other systems, but at least with Perl's XS (the standard way to write Perl modules parts of which are compiled C code) and two of the ways this can be done in Python, it is the same: the C compiler's name and flags are recorded at the time the "wrapper" is built, so that they can be used later. At least IMHO, this has two main benefits: - people (or programs) that want to build a Perl/Python/OCaml/whatever module do not have to know anything about C compilers, flags, optimization, language-specific libraries[1] , etc. The consumers tell their own language ecosystem "look, I need to compile something that has C parts in it, go do something about it", and the wrapper for the C compiler knows exactly what to do - everything is compiled using the same compiler[2], the same optimization flags, the same libraries, etc., so one module that has C parts in it can call the C functions from another module directly with no fear of any kind of calling convention mismatch or whatever - to reinforce the previous point: everything is compiled using the same recorded settings *no matter what* environment variables or paths there may be in the current user's execution environment, so that nothing will break if somebody has the wrong environment variable defined when they build a module a couple of months later. Of course, there are some cases when some such systems allow additional flags to be specified or overridden, but IMHO it is good that this must be done explicitly and is most often not done at all, so that everything is built in the same way and it can all work together [1] At least with Perl and Python, C code very often invokes functions from the Perl/Python standard library, the C code does not know how to create a list or how to invoke a Perl/Python function, so it has to use the language's internal libraries for that. [2] Well, okay, that's not strictly true, since the binary called "gcc" now may not be the same that was provided by the C compiler package a couple of months ago, but it ought to be guaranteed to generate compatible code and object files. So yeah, I'd say that "record the C compiler flags at build time" is pretty much standard practice for such interface providers. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1030757: ITP: python-parse-stages -- Parse a mini-language for selecting objects by tag or name
Package: wnpp Severity: wishlist Owner: Peter Pentchev X-Debbugs-Cc: debian-devel@lists.debian.org, team+pyt...@tracker.debian.org, r...@debian.org * Package name: python-parse-stages Version : 0.1.1 Upstream Contact: Peter Pentchev * URL : https://gitlab.com/ppentchev/parse-stages * License : BSD-2-clause Programming Lang: Python Description : Parse a mini-language for selecting objects by tag or name This library is mostly useful for command-line parsing by other tools like `tox-stages` and `nox-stages`. It may be used to parse e.g. a command-line specification like `@check and not pylint` or `@tests or ruff` and then match it against a list of objects that have names and lists of tags. This package will be maintained as part of the Debian Python Team. signature.asc Description: PGP signature
Bug#1030756: ITP: python-test-stages -- Run Tox, Nox, etc. tests in groups, stopping on errors
Package: wnpp Severity: wishlist Owner: Peter Pentchev X-Debbugs-Cc: debian-devel@lists.debian.org, team+pyt...@tracker.debian.org, r...@debian.org * Package name: python-test-stages Version : 0.1.1 Upstream Contact: Peter Pentchev * URL : https://gitlab.com/ppentchev/test-stages * License : BSD-2-clause Programming Lang: Python Description : Run Tox, Nox, etc. tests in groups, stopping on errors The `test-stages` library provides command-line tools that wrap Python test environment runners such as Tox or Nox, invoking them so as the various tests are run in parallel, in groups, as specified on the command line. This allows the fastest tests to be run first, and the slower ones to only be started if it makes sense (e.g. if tools like [ruff] or [flake8] did not uncover any trivial syntax errors). The `tox-stages` tool runs Tox with the specified groups of test environments, stopping if any of the tests in a group should fail. This allows quick static check tools like e.g. `ruff` to stop the testing process early, and also allows scenarios like running all the static check tools before the package's unit or functional tests to avoid unnecessary failures on simple errors. The syntax for grouping the test environments to be run is described in the `parse-stages` library's documentation. This package will be maintained as part of the Debian Python Team. signature.asc Description: PGP signature
Re: Does removal of global variables from a library break C ABI?
On Tue, Jan 17, 2023 at 08:03:18PM -0800, Russ Allbery wrote: > Scott Talbert writes: > > > In one of the library packages I maintain (hidapi), upstream removed a > > couple of global variables (my .symbols file noticed this). See > > abipkgdiff below. > > > Does this break ABI? My assessment is that it does NOT, but I would > > like to confirm. These variables were not declared in a header file, so > > I can't see how external user code would have referenced them. > > It does technically, but if the variables were never declared in a header > file, it's equivalent to hiding private functions that were previously > exposed by mistake but never prototyped for users. Traditionally, we > don't consider that an ABI break worth bumping the soname unless we have > some reason to believe that software is using those symbols. JFTR (I'm pretty sure that both Scott and Russ know this), https://sources.debian.org/ can help one figure out whether some other Debian package uses them. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: need we support unshadowed passwords from the installer
On Sat, Jan 14, 2023 at 02:11:00PM +0200, Peter Pentchev wrote: > On Fri, Jan 13, 2023 at 09:11:40PM -0500, nick black wrote: > > it's 2023 and imho time to stop supporting unshadowed passwords > > from the installer. > > > > https://salsa.debian.org/installer-team/user-setup/-/merge_requests/5 > > > > 1) nis (and possibly conserver?) seem the primary drivers of an > > unshadowed passwd.=20 > > > > let me freely admit that, despite the advanced age of forty-two > > (seventy-eight in UNIX years), that i know nothing about nis/yp > > except that there was a big o'reilly book about it back when one > > read the security book with the big safe on the front and the > > scripting book with the big drill. i suspect it's basically a > > halfway point between syncing /etc/passwd and /etc/hosts with > > cron+rsh, and hiring someone on whom you can inflict ldap? so > > please correct me wherever i'm woefully ignorant. > > > > ...but it appears that NIS can be made to work with shadowed > > passwords (though without their benefits). this is from a > > cursory reading of a FAQ last updated in 2003, so take it with a > > grain of salt. the "linux network administrators [sic] guide" > > seems to confirm this, and can also help you set up IPX or UUCP. > [snip] > > i'm absolutely not suggesting we stop supporting NIS or other > > programs which rely on unshadowed passwords. it's a big ol' > > tent, and we have more than enough room for you to carry forth > > the torch of Solaris 2. i just don't think this belongs in the > > installer anymore. > > I know what NIS/YP is, I know of a couple of places where it is > still in use, and, as Mark Haber said, the people running those Um. Many apologies. Of course it's Marc. > places know how to find and flip a switch. -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: need we support unshadowed passwords from the installer
On Fri, Jan 13, 2023 at 09:11:40PM -0500, nick black wrote: > it's 2023 and imho time to stop supporting unshadowed passwords > from the installer. > > https://salsa.debian.org/installer-team/user-setup/-/merge_requests/5 > > 1) nis (and possibly conserver?) seem the primary drivers of an > unshadowed passwd.=20 > > let me freely admit that, despite the advanced age of forty-two > (seventy-eight in UNIX years), that i know nothing about nis/yp > except that there was a big o'reilly book about it back when one > read the security book with the big safe on the front and the > scripting book with the big drill. i suspect it's basically a > halfway point between syncing /etc/passwd and /etc/hosts with > cron+rsh, and hiring someone on whom you can inflict ldap? so > please correct me wherever i'm woefully ignorant. > > ...but it appears that NIS can be made to work with shadowed > passwords (though without their benefits). this is from a > cursory reading of a FAQ last updated in 2003, so take it with a > grain of salt. the "linux network administrators [sic] guide" > seems to confirm this, and can also help you set up IPX or UUCP. [snip] > i'm absolutely not suggesting we stop supporting NIS or other > programs which rely on unshadowed passwords. it's a big ol' > tent, and we have more than enough room for you to carry forth > the torch of Solaris 2. i just don't think this belongs in the > installer anymore. I know what NIS/YP is, I know of a couple of places where it is still in use, and, as Mark Haber said, the people running those places know how to find and flip a switch. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Discrepancies between packages.d.o and tracker.d.o
Dear all, I accidentally noticed that the thunderbird package information differs between packages.d.o [0] and tracker.d.o [1]. [0] does not list the package from stable-sec. If I click on the package versions for stable-sec [2] and old-sec [3] on [1], I obtain error pages. Probably something went out-of-sync. Best regards, Peter [0] https://packages.debian.org/search?keywords=thunderbird&searchon=names&suite=all [1] https://tracker.debian.org/pkg/thunderbird [2] https://packages.debian.org/source/stable-security/thunderbird [3] https://packages.debian.org/source/oldstable/updates/thunderbird
Re: setting sysctl net.ipv4.ping_group_range
On Mon, Jan 02, 2023 at 12:01:54PM -0800, Noah Meyerhans wrote: > There are several examples of packages installing files to > /usr/lib/sysctl.d, but I haven't found any specific guidance on policies > about what's appropriate for them. Since sysctl variables change the > system behavior in a way that's not limited to the package changing the > setting, and since the package in question (iputils-ping) is Priority: > important and part of the default install, I won't want to make any > changes without consulting here first. [snip] > After applying this change, I believe it'd be appropriate to drop ping's > setcap/setuid settings from postinst altogether, though I'd be open to > other options. [2] I personally would prefer giving the administrator a way to change that. Maybe add a low priority debconf question with a "ping is not setuid" default, then mention that debconf setting in a comment in the file that the package installs in the sysctl.d/ directory. Other than that, I think making ping not setuid is a great idea. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Build libzstd using cmake; add a non-cmake build profile?
On Mon, Dec 26, 2022 at 04:35:09PM +, Simon McVittie wrote:
> On Mon, 26 Dec 2022 at 14:00:31 +0100, Andrea Pappacoda wrote:
> > or patch zstd's makefiles to install a small Find
> > module itself (this is not really a good practice, as ideally upstreams
> > should install CMake Config files, but should work nonetheless).
Thanks to everyone for the great discussion and several pieces of very
helpful advice! In the end I decided to go with the "small lie" approach that
I mentioned in a previous message: run dh_auto_configure --buildsystem=cmake
so that CMake can create the zstdConfig*.cmake and zstdTargets*.cmake files
that it would install, then run the normal Makefile build, and in the end
install the CMake build glue files generated at configure time. Yes, this is
not perfect, inasmuch as the *.cmake files do not *really* correspond to
the built libraries, but I think it will serve for now (and see below).
> If you're considering patching zstd's makefiles, I believe the preferred
> route is to install CMake "config modules" containing an imported target,
> like dbus and libsdl2 do. The one in dbus is a reasonably simple example
> of wrapping a pkg-config module with a CMake config module, while the one
> in libsdl2 bypasses pkg-config and provides the equivalent information
> more directly. Either way, this is something that would make sense to
> contribute upstream.
>
> Both dbus and libsdl2 have optional-but-not-recommended CMake build
> systems, similar to zstd, which we don't use in Debian; we follow upstream
> recommendations to build dbus with Autotools (in older branches) or Meson
> (in the 1.15.x development branch), and libsdl2 with Autotools. The
> Autotools and Meson build systems for those projects also install a
> simplified CMake config module, which can be consumed by CMake projects
> in the same way as if dbus/libsdl2 had themselves been built with CMake.
> The CMake config module is generated from a template using @variable@
> substitutions.
This - building a trivial zstdConfig.cmake file during the standard build -
is a great idea that I will try to implement and pitch to the libzstd upstream
developers. Thanks!
> In older versions of libsdl2 the config module is not completely compatible
> with what its CMake build system would have installed, but the one in
> bookworm should be reasonably feature-complete.
>
> If dependent projects are expected to call find_package(Foo), then the
> CMake config module should be installed as either
> ${libdir}/cmake/Foo/FooConfig{,Version}.cmake in mixed-case (like dbus
> does) or ${libdir}/cmake/Foo/foo-config{,-version}.cmake in lower-case
> (like libsdl2 does). I don't know whether one of those is preferred over
> the other.
Yeah, I imagine that the fake zstdConfig.cmake file would be installed in
the same place and under the same name as the one that the (not completely
suppored) CMake build system for libzstd already installs.
> It is a good idea to have a test for each supported use-case in the
> package's autopkgtests. dbus and libsdl2 have some tests for this which
> might make useful inspiration.
Right, I have autopkgtests that compile trivial programs for other
library packages, I don't know why I didn't add one (and now, it seems,
at least two) for libzstd when I adopted it. Thanks again for the idea!
Once again, thanks to everyone for the relevant critique and helpful
suggestions!
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
Re: Build libzstd using cmake; add a non-cmake build profile?
On Mon, Dec 26, 2022 at 02:00:31PM +0100, Andrea Pappacoda wrote: > Il giorno lun 26 dic 2022 alle 08:37:51 +02:00:00, Peter Pentchev > ha scritto: > > In #1020403 there is a request to install the CMake build glue for > > the zstd library in its -dev package. I think that this is a good > > idea, and I have a pretty much ready-for-uploading set of changes > > that do that. For the purposes of this discussion I have uploaded > > the proposed "switch to CMake and install the CMake build glue" > > commits to my own fork of the libzstd repository > > Hi Peter. Apart from your bootstrapping concerns, please keep in mind that > upstream's CMake build script is not official; citing the README: > > > make is the officially maintained build system of this project. All other > build systems are "compatible" and 3rd-party maintained, they may feature > small differences in advanced options. When your system allows it, prefer > using make to build zstd and libzstd. Yes, I am aware of this, and I do take additional care to make sure that things work as expected. Still, thanks for mentioning this, and see below... > Using CMake instead of make has caused some interesting issues in the past. > The first that comes to my mind happened in Arch Linux, and got featured on > the Phoronix news site: > <https://www.phoronix.com/news/Arch-Linux-Bizarre-Zstd> Right... thanks for reminding me of that! I had indeed noticed a couple of days ago that the CMake build differed in a couple of minor ways from the Makefile one and I had made a mental note to fix that... and then I forgot. There were two main differences: legacy support and setting the C standard. The former is now handled via a CMake config option passed via `dh_auto_configure`, and the latter is disabled with a patch taken from the upstream development branch, although in my (limited) testing there was no effect on the compression speed, at least with the GCC version in Debian unstable as of now. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Build libzstd using cmake; add a non-cmake build profile?
On Mon, Dec 26, 2022 at 08:37:51AM +0200, Peter Pentchev wrote: > Hi, > > In #1020403 there is a request to install the CMake build glue for > the zstd library in its -dev package. I think that this is a good > idea, and I have a pretty much ready-for-uploading set of changes > that do that. For the purposes of this discussion I have uploaded > the proposed "switch to CMake and install the CMake build glue" > commits to my own fork of the libzstd repository at > https://salsa.debian.org/roam/libzstd > > The main thing that gave me a bit of a pause before running > `dgit push-source` (and *thanks* for making it that easy!) is that > right now libzstd is effectively an essential package (ObXThread: > not in the Policy sense) since dpkg pre-depends on it to support > e.g. recent Ubuntu debs that use zstd as the compression method for > the data part of the package. So... if I introduce a build-time > dependency on CMake, this will probably create a non-trivial dependency > loop for people who try to bootstrap Debian onto new architectures. > Does this mean that it would be best for me to include an e.g. stage1 > build profile that does not build-depend on cmake and falls back to > the old/current way of building directly using `make`? > > Hm, but if I do that, it seems that it might be best to put the CMake > build glue files into a separate package and make libzstd-dev depend on > that new package in the case, since IIUC the stage1 build > profile is not allowed to change the contents of a binary package, so > I cannot simply drop all the files in the /usr/lib//cmake/ directory. > That's not a big hurdle; if people say that this is the way to go, then > this is what will be done. > > Many thanks to all the people who keep working on all the tools and > toolchains that make this message make sense at all! Hm, I just thought of a hybrid solution, but I don't think it would be a really, really good idea: keep the non-cmake build, but also invoke cmake with a modified lists file so that it *only* generates the build glue; then still put that in a separate package, all of that governed by a !stage1 build profile. I'm not sure I like it a lot, since that would mean that the shipped library is not actually compiled using CMake, so one might say the cmake build glue is a lie... but it could be an option if people think it's best. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Build libzstd using cmake; add a non-cmake build profile?
Hi, In #1020403 there is a request to install the CMake build glue for the zstd library in its -dev package. I think that this is a good idea, and I have a pretty much ready-for-uploading set of changes that do that. For the purposes of this discussion I have uploaded the proposed "switch to CMake and install the CMake build glue" commits to my own fork of the libzstd repository at https://salsa.debian.org/roam/libzstd The main thing that gave me a bit of a pause before running `dgit push-source` (and *thanks* for making it that easy!) is that right now libzstd is effectively an essential package (ObXThread: not in the Policy sense) since dpkg pre-depends on it to support e.g. recent Ubuntu debs that use zstd as the compression method for the data part of the package. So... if I introduce a build-time dependency on CMake, this will probably create a non-trivial dependency loop for people who try to bootstrap Debian onto new architectures. Does this mean that it would be best for me to include an e.g. stage1 build profile that does not build-depend on cmake and falls back to the old/current way of building directly using `make`? Hm, but if I do that, it seems that it might be best to put the CMake build glue files into a separate package and make libzstd-dev depend on that new package in the case, since IIUC the stage1 build profile is not allowed to change the contents of a binary package, so I cannot simply drop all the files in the /usr/lib//cmake/ directory. That's not a big hurdle; if people say that this is the way to go, then this is what will be done. Many thanks to all the people who keep working on all the tools and toolchains that make this message make sense at all! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: my package uploads silently rejected
On 30/11/2022 14:03, Jonas Smedegaard wrote: Hi, I am unable to succesfully dput packages. Most likely the cause is my too late updating my PGP key expiry date - but that should be solved by now, and I am unable to figure out how to debug the problem or whom to contact about it. I patiently waited until debian-archive-keyring package was updated with my refreshed key in it, and since then I have regularly tested re-uploading the package rust-criterion where I receive the initial confirmation that the upload was received but the seconed confirmation (typically appearing ~10 minutes later) that the package was accepted does not appear. I have tried ssh into the host ssh.upload.debian.org and (after fumbling around) found the file /srv/upload.debian.org/queued/run/log where I see only succesful notices about rust-criterion, no indication of rejection. What to do next? Who to nudge? Any clues, anyone? - Jonas Same question was asked here back on 27th June this year, but there did not seem to be an easy answer. (Probably a key problem)
Debhelper issue on various architectures
Dear all,
yesterday evening I uploaded an updated version of the charliecloud
package [0]. It built fine locally on the amd64 architecture and the
salsa CI test builds passed on amd64 [1] and i386 [2] prior to upload.
Still on the buildds the builds for the following architectures failed:
- i386 [3]
- mipsel [4]
- arm64 [5]
- armhf [6]
- ppc64el [7]
In all those cases the corresponding error message was a follows:
--
dh_lintian -a
Use of uninitialized value $dest in -l at
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 662.
Use of uninitialized value $to in string eq at
/usr/share/perl/5.36/File/Copy.pm line 64.
Use of uninitialized value $to in -d at
/usr/share/perl/5.36/File/Copy.pm line 96.
Use of uninitialized value $dest in concatenation (.) or string at
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 665.
dh_lintian: error:
copy("debian/charliecloud-tests/usr/share/lintian/overrides/charliecloud-tests",
""): No such file or directory
make: *** [debian/rules:6: binary-arch] Error 25
--
Any hints pointing towards the underlying issue are appreciated.
Best regards,
Peter
[0] https://tracker.debian.org/pkg/charliecloud
[1] https://salsa.debian.org/hpc-team/charliecloud/-/jobs/3544125
[2] https://salsa.debian.org/hpc-team/charliecloud/-/jobs/3544126
[3]
https://buildd.debian.org/status/fetch.php?pkg=charliecloud&arch=i386&ver=0.30-1&stamp=1668982076&file=log
[4]
https://buildd.debian.org/status/fetch.php?pkg=charliecloud&arch=mipsel&ver=0.30-1&stamp=1668980982&file=log
[5]
https://buildd.debian.org/status/fetch.php?pkg=charliecloud&arch=arm64&ver=0.30-1&stamp=1668982133&file=log
[6]
https://buildd.debian.org/status/fetch.php?pkg=charliecloud&arch=armhf&ver=0.30-1&stamp=1668983146&file=log
[7]
https://buildd.debian.org/status/fetch.php?pkg=charliecloud&arch=ppc64el&ver=0.30-1&stamp=1668985252&file=log
Re: Q: Uploading huge size package and memory concern with running lintian
On Sun, Nov 13, 2022 at 03:55:45PM +0100, Micha Lenk wrote: > Am 13. November 2022 04:56:14 MEZ schrieb Hideki Yamane > : > >Hi lintian maintainers, > > > > I'm thinking about uploading new unidic-mecab package, but when I ran > > lintian for it, lintian ate all of my PC's memory (32GB!) since its package > > is huge size (unidic-mecab_3.1.1-1_all.deb is almost 1GB) , and my desktop > > hung. So, I would like to know whether there is any concern about uploading > > such huge package or not. > > Just looking at the size this doesn't look like a regular package you are > talking about. So I'm sorry but I would need more context on that before I > can say why I have a concern. Why would you want to do that? Not offering an opinion on the question asked, but just a note for anybody else who is interested in this: (an older version of) the unidic-mecab package is already in the Debian archive. This is not about a new package, but a package update. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Firmware GR result - what happens next?
On Fri, Oct 14, 2022 at 10:52:01AM +0200, Santiago Ruano Rincón wrote: > El 14/10/22 a las 13:32, Paul Wise escribió: > > On Thu, 2022-10-13 at 17:35 +0200, Julien Cristau wrote: > > > > > I'd prefer if we could make things work vs making things fail, > > > however loudly. > > > > There seem to be a few ways to deal with this transition: > > > > 1. Document it in the release notes and let users handle it. This means > > lots of users won't get security updates for firmware (which are mostly > > only issued for x86 CPU microcode), since lots of folks won't read the > > release notes. This also means lots of support requests when users > > can't find the firmware package they wanted. > > > > 2. Add some code somewhere to automatically modify the apt sources, > > somehow ensure that code is run by all Debian users and hope that other > > automated processes (like ansible/puppet) don't overwrite those changes > > and hope that users aren't storing apt sources config in packages, > > which would mean conffile prompts after the modification happens. > > > > 3. Add some code to apt to download non-free-firmware when non-free is > > available in the sources and the downloaded Release files. This would > > solve the issue for Debian and all other derivatives too, if they > > decide to add a new non-free-firmware component too. This might not > > be accepted by apt developers as it is kind of a hack to special-case > > Debian component semantics in apt, although maybe a component mapping > > config option would be accepted. This might result in extra Debian > > support requests when users notice the new component in `apt update`. > > This might not work for users of tools not based on apt, like cupt? > > This wouldn't result in users without non-free getting any non-free > > firmware though, which maybe we want since it is the new default? > > > > 4. Keep all non-free-firmware packages in non-free too. This would be > > backwards compatible, but may expose bugs in dak, debian-cd, apt and > > other tools, so IIRC this has been vetoed by the archive and CD teams. > > This also wouldn't result in users without non-free getting any of the > > non-free firmware, which maybe we want since it is the new default? > > > > Personally I would choose 4 first, I expect any potential issues could > > be easily fixed before the freeze. Next I would choose 3. Next I would > > choose 1 because I think /etc belongs to the sysadmin not packages. > > 5. transitional packages along with a helper package (that fails or > success during install) to prompt the user so they add non-free-firmware > section when needed. > > Is there any reason why you are not considering 5.? Do you mean having packages with the same names, but different versions (even if only Debian revisions) and totally different contents, and also built from different source packages, in different sections of the same suite in the archive?... I'm... I'm not sure this would work... I think that others already expressed some doubts as to how dak would handle that. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1015863: ITP: qt6ct -- Qt6 Configuration Tool
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org, pe...@pblackman.plus.com Owner: pe...@pblackman.plus.com * Package name : qt6ct Version : 0.5-1 Upstream Author : Ilya Kotov * URL : https://github.com/trialuser02/qt6ct * License : BSD-2-clause Programming Lang: C++ Description : Qt6 Configuration Tool qt6ct allows Qt6 program settings to be adjusted on desktops other than KDE. It provides the same features as qt5ct does for qt5 programs. See https://tracker.debian.org/pkg/qt5ct I'm packaging this program, as I found the fonts for qt6 programs on Xfce4 could not be adjusted without it.
Re: popularity-contest: support for XB-Popcon-Reports: no
On 04/05/2022 19:43, Russ Allbery wrote: I don't know if it currently does this, but it would be useful for popcon to show counts for public third-party packages that aren't in the archive. See https://popcon.debian.org/unknown/by_recent Cheers, Peter
Debian doesn't have a "core team", should it? can it?
Recently andreas-tille sent the following message about libzstd to
debian-devel
I'd like to repeat that I'm really convinced that libzstd should *not*
be maintained in the Debian Med team but rather some core team in
Debian. It is here for historic reasons but should have moved somewhere
more appropriately since it became its general importance.
It ended up being transferred to the rpm team, which got it out of the
med team's
hair but I'm not convinced the rpm team satisfies "some core team" any
better
than the med team does.
As far as I can tell Debian has broadly 3 types of teams.
1. Teams focussed on an application area, for example the med team, the
science team, the games team.
2. Teams focussed on a programming language, for example the python
team, the perl team, the rust team. There is however no such team for
software written in C, C++ or shell script.
3. Teams focussed on a particular piece of software
As far as I can tell this means that there are a bunch of packages that
"fall between the gaps", packages
that are of high importance to Debian as a whole but are not a great fit
for any team. They either end up not associated with a team at all or
sometimes associated with a team who happened to be the first to
use the library.
I decided to get a sample of packages that could be considered "core",
obviously different people have different ideas of what should be
considered core but I decided to do the following to get a list of
packages that hopefully most people would consider core.
debootstrapped a new sid chroot
ran tasksel install standard (a bit less spartan than just the base system)
ran apt-get install build-essential (we are an opensource project,
development tools are essential to us)
ran apt-get install dctrl-tools (arguablly not core, but I needed it to
run the test commands and it's only one package)
There were 355 packages installed, built from 223 source packages. I got
a list of source packages with
the command
grep-dctrl installed /var/lib/dpkg/status -n -ssource:package | cut -d '
' -f 1 | sort | uniq > sourcepks.txt
I then extracted the source stanzas with.
grep-dctrl -e -F Package `sed "s/.*/^&$/" sourcepks.txt | paste -s -d
'|'`
/var/lib/apt/lists/deb.debian.org_debian_dists_sid_main_source_Sources >
sourcestanzas.txt
Then wrote a little python script to extract teams from those stanzas.
#!/usr/bin/python3
from debian import deb822
import collections
import sys
f = open(sys.argv[1])
counts = collections.defaultdict(int)
for source in deb822.Sources.iter_paragraphs(f):
maintainers = [source['maintainer']]
if 'uploaders' in source:
maintainers += source['uploaders'].split(',')
maintainers = [s.strip() for s in maintainers if s.strip() != '']
teams = [s for s in maintainers if ('team' in s.lower()) or
('lists' in s.lower()) or ('maintainers' in s.lower()) or ('group' in
s.lower())]
teams.sort()
counts[tuple(teams)] += 1
#print(repr(maintainers))
#print(repr(teams));
for teams , count in sorted(counts.items(), key = lambda x: x[1]):
if len(teams) == 0:
teamtext = 'no team'
else:
teamtext = ', '.join(teams)
print(str(count) + ' ' + teamtext)
This confirms my suspiscions, of the 223 source packages responsible
for the packages installed in my "reasonablly but not super minimal"
environment more than half of them were not associated with a team at all.
I also saw a couple of packages in there maintained by the science team
and the med team. two source packages telnet and apt-listchanges
were orphaned.
I do not know what the soloution is, whether a "core team" is a good idea
or even whether one is possible at all but I feel this is an elephant that
should have some light shone on it.
Bug#1008207: ITP: remrun -- copy a file to a remote host and execute it there
Package: wnpp Severity: wishlist Owner: Peter Pentchev X-Debbugs-Cc: debian-devel@lists.debian.org, r...@ringlet.net * Package name: remrun Version : 0.2.0 Upstream Author : Peter Pentchev * URL : https://gitlab.com/ppentchev/remrun/ * License : BSD-2-clause Programming Lang: POSIX shell Description : copy a file to a remote host and execute it there The remrun tool may be useful for one-off execution of a series of commands or a complicated command that does not easily lend itself to shell quoting and escaping via SSH. It copies the specified file to the remote host using SSH under a temporary filename, executes it on the remote side, then removes the temporary file. signature.asc Description: PGP signature
Re: libzstd should not be maintained by Debian Med team - could some core team please take over (Was: libzstd 1.5.2 in Debian)
On Mon, Mar 14, 2022 at 05:11:07PM +0100, Andreas Tille wrote: > Hi Peter, > > Am Mon, Feb 21, 2022 at 07:40:26PM +0200 schrieb Peter Pentchev: > > > there was a (private) request to upgrade libzstd to latest 1.5.2. > > > > > > I'd like to repeat that I'm really convinced that libzstd should *not* > > > be maintained in the Debian Med team but rather some core team in > > > Debian. It is here for historic reasons but should have moved somewhere > > > more appropriately since it became its general importance. > > > > > > Please consider this mail a team-orphane of the package. > > > > I'm sorry; I do indeed intend to bring it into pkg-rpm, and I will try > > to do that in the next couple of days. Apologies for the months of > > delay, and thanks a lot for all of your team's work! > > Thanks for your information. Are there any blockers to take over > this package? Hi, Sorry again for the delay. I uploaded an update to libzstd-1.4.9; I will try to update it to 1.5.x really soon. Thanks again for all your work on it over the years! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Debian DSA-5095-1 : linux - security update
Hi Sona, On 17.03.22 15:02, Sona Das wrote: But whenever I tried to upgrade my linux-header it still remains on linux-headers-5.10.0-10 version, it doesn’t gets upgraded to the latest one. have you verified that the metapackage linux-headers-amd64 is installed on your system - as suggested by Ben (see below)? On 17-Mar-2022, at 5:38 AM, Ben Hutchings <mailto:b...@decadent.org.uk>> wrote: So long as you install the metapackage linux-headers-amd64, replacements like this should be upgraded automatically. You can check its status using dpkg -l linux-headers-amd64 Best regards, Peter
Bug#1006606: ITP: python-cfg-diag -- common configuration-storage class with a .diag() method
Package: wnpp Severity: wishlist Owner: Peter Pentchev X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org, r...@debian.org * Package name: python-cfg-diag Version : 0.2.0 Upstream Author : Peter Pentchev * URL : https://github.com/storpool/python-cfg_diag * License : BSD-2-clause Programming Lang: Python Description : common configuration-storage class with a .diag() method This module provides four classes that may be used as base classes for storing program runtime configuration with a `verbose` boolean field. The classes provide a `.diag(msg)` method that decides whether to output the provided message based on the value of the object's `verbose` field. I intend to maintain this package within the Python packaging team. signature.asc Description: PGP signature
Re: libzstd should not be maintained by Debian Med team - could some core team please take over (Was: libzstd 1.5.2 in Debian)
On Mon, Feb 21, 2022 at 11:40:36AM +0100, Andreas Tille wrote: > Hi, > > there was a (private) request to upgrade libzstd to latest 1.5.2. > > I'd like to repeat that I'm really convinced that libzstd should *not* > be maintained in the Debian Med team but rather some core team in > Debian. It is here for historic reasons but should have moved somewhere > more appropriately since it became its general importance. > > Please consider this mail a team-orphane of the package. I'm sorry; I do indeed intend to bring it into pkg-rpm, and I will try to do that in the next couple of days. Apologies for the months of delay, and thanks a lot for all of your team's work! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1006178: ITP: tox-delay -- run some Tox tests after others have completed
Package: wnpp Severity: wishlist Owner: Peter Pentchev X-Debbugs-Cc: debian-devel@lists.debian.org, r...@debian.org * Package name: tox-delay Version : 0.1.0 Upstream Author : Peter Pentchev * URL : https://devel.ringlet.net/devel/tox-delay/ * License : BSD-2-clause Programming Lang: POSIX shell Description : run some Tox tests after others have completed The tox-delay tool postpones the run of the specified Tox environments after the run of all the others has completed successfully. This may be useful if e.g. there are unit or functional test environments, which it would make no sense to run if the static checkers (pylint, mypy, etc) find problems. signature.asc Description: PGP signature
Bug#1005131: ITP: utf8-locale -- detect a UTF-8-capable locale for running child processes in
Package: wnpp Severity: wishlist Owner: Peter Pentchev X-Debbugs-Cc: debian-devel@lists.debian.org, r...@debian.org * Package name: utf8-locale Version : 0.2.0 Upstream Author : Peter Pentchev * URL : https://gitlab.com/ppentchev/utf8-locale * License : BSD-2 Programming Lang: Python, Rust Description : detect a UTF-8-capable locale for running child processes in Sometimes it is useful for a program to be able to run a child process and more or less depend on its output being valid UTF-8. This can usually be accomplished by setting one or more environment variables, but there is the question of what to set them to - what UTF-8-capable locale is present on this particular system? This is where the utf8_locale module comes in.
Re: Adding new language/locale to system via a graphical interface
On Mon, Jan 03, 2022 at 02:59:26AM +0530, Pirate Praveen wrote: > Hi, > > I'm looking for a way to add a new locale/language to system from gnome > (think about gnome on mobile like Purism Librem 5 or Pine Phone). I can do > that from a terminal by running dpkg-reconfigure locales but want to provide > an easier option to users. Is there a way to force gtk interface of debconf > and launch it from graphical interface? In Ubuntu, there is separate add > language tool which can add new languages. The debconf(7) manual page suggests that setting DEBIAN_FRONTEND=gnome after installing the libgtk3-perl package ought to work, and it seems to work for me: sudo env DEBIAN_FRONTEND=gnome dpkg-reconfigure locales ...brings up a GTK+ interface. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#1001612: ITP: deltarpm -- Tools to create and apply deltarpms
Package: wnpp Severity: wishlist Owner: Peter Pentchev X-Debbugs-Cc: debian-devel@lists.debian.org, r...@debian.org, team+pkg-...@tracker.debian.org * Package name: deltarpm Version : 3.6.3 Upstream Author : Michael Schroeder * URL : https://github.com/rpm-software-management/deltarpm * License : BSD-3-clause Programming Lang: C, Python Description : Tools to create and apply deltarpms This will bring the deltarpm package back into Debian. It was removed as part of the clean-up of the old Python-2-only createrepo-related tools; however, it is now possible to use deltarpm with the new set of createrepo-c/libmodulemd2/libdrpm0 packages, and it will help run the libdrpm upstream testsuite to its full extent. This is the long description of the package: A deltarpm contains the differences between an old and a new version of an RPM. This makes it possible to recreate the new RPM from the deltarpm and the old RPM. . On Debian and derived systems these tools may be useful for creating and maintaining repositories of RPM packages. I will maintain this package as part of the Debian RPM packaging team. signature.asc Description: PGP signature
Status of weekly live builds
Dear all, I've just noticed that the weekly live builds (both the free ones [0] and the unofficial non-free ones [1]) have not been updated since August 9, 2021. Is this on purpose or did some machinery get stuck? Best regards, Peter [0] https://cdimage.debian.org/cdimage/weekly-live-builds/amd64/iso-hybrid/ [1] https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/weekly-live-builds/amd64/iso-hybrid/
Re: Mapping Reproducibility Bug Reports to Commits
I am a researcher at the University of Waterloo, conducting a project to study reproducibility issues in Debian packages. The first step for me is to link each Reproducibility-related bug at this link: https://bugs.debian.org/cgi-bin/pkgreport.cgi?usertag=reproducible-bui...@lists.alioth.debian.org to the corresponding commit that fixed the bug. However, I am unable to find an explicit way of doing so programatically. Please assist. There is no explicit link. Most (but not all) debian packages are maintained in a VCS and there are fields in the source package that identify the location and type of the VCS (almost certainly git nowadays), but there are multiple different workflows used (git-buildpackage is the most common and normally uses a "patches-unapplied" git tree, but there is also dgit which uses a "patches applied" git tree. Git trees may or may not contain the upstream source. At least one language community uses a system where the git tree stores files that are used to generate the Debian packaging rather than the final Debian packaging itself. Also maintainer practices for strucuring commits vary, some maintainers update the changelog at the same time as making the actual changes, others update the changelog in a batch later. Sometimes bugs aren't even closed from the changelog at all but instead are closed by the maintainer after the upload. Particularly if the maintainer is not sure whether a change will fix the bug. With all that said, it's probably doable to develop heuristics that map bug numbers to commits in most cases, an outline might be. * Check if the package has a VCS and the relavent changelog can be found in said VCS, if there is no VCS give up and reffer the bug for human attention. * Map the bug number to a changelog line (if there is no such mapping, give up and reffer the bug for human attention) * Determine which commit added the changelog line (e.g. with git blame), see if there are actual code changes in that commit, * if so take it as the probable commit, if not then search backwards a bit for a commit message that matches the changelog line. Another option having guessed a range of commits from the changelog and/or from comparing the VCS to the source packages may be to run a bisection, this would likely require some effort to detect what workflow is in use though.
Re: Debian's branches and release model
> > https://wiki.debian.org/ReleaseProposals > Great list, contains a lot of what I have to say. The fact that debian is laser focused on stable, and does not officially encourage using testing as a rolling release (as evidenced from a couple replies to this email chain), yet there are still people doing it, is a testament of how good debian is. Just don't abandon us:) If testing is part of QA, then popularizing it should benefit. Staying closer to upstream releases gets my vote. Quote from the page, "Looks like it's time for action! Somebody (maybe the Debian project leader) should pick up the hot potato and compile a list of the proposals which are going to be adopted. Flame wars ensue. Then Debian emerges renewed, as a phoenix from the ashes." cheers, P
Debian's branches and release model
Hi, I am enjoying Debian's testing branch as a reasonably stable and up-to-date 'rolling' release, and I have to say it satisfies all my desires, almost. The one thing that bothers me is that every two years, the unstable/testing branches are frozen to certain extent because of the stable releases. This means the testing branch can be quite lagged behind upstream releases. One example is gcc, with gcc-11 released almost 6 months ago, and it is still not default in debian testing - I know it is being worked on right now and probably only a couple days away, but still... So the question is, why not cut a release branch every two years, and at the same time keep the unstable/testing alive? Is it because debian developers think it's too much work to reconcile the differences later, so they prefer freezing? Some ppl recommend arch for this reason, but I am already familiar with apt's way of things, and would hold off switching before I have a better understanding of the bigger picture. I am certainly not qualified to make recommendations here, just wondering what is the reason behind it and if there is some proposal to make testing a better/closer 'rolling' release that ppl like me can enjoy better:) cheers, P
Re: WARNING: dh_installsystemd is moving unit files to /usr/lib/systemd/system
On Thu, 19 Aug 2021, Luca Boccassi wrote:
> > Installing those files in /usr/lib/systemd/system is fine.
>
>
>
> This is indeed the right thing to do moving forward, so updating
> Lintian would be the best outcome. Thanks!
It seems that generators in /usr/lib/systemd are being ignored. This
causes #992554 in tor.
The tor amd64 package build on the buildds has the systemd files in
/usr/lib/systemd, and this results in a broken package.
Moving /usr/lib/systemd/system-generators/tor-generator tor
/lib/systemd/system-generators "fixes" the issue.
Probably debhelper should not move generators to /usr until systemd also
checks that tree for generators. Or I'm missing something else.
Cheers,
--
| .''`. ** Debian **
Peter Palfrader | : :' : The universal
https://www.palfrader.org/ | `. `' Operating System
| `-https://www.debian.org/
