Re: pandoc-filter-diagram_0.2.1-1_amd64.changes REJECTED
Quoting Shengjing Zhu (2024-05-16 12:14:57)
> On Thu, May 16, 2024 at 4:35 PM Jonas Smedegaard wrote:
> >
> > Hi FTP-masters (cc d-devel list),
> >
> > A package, that I had initially introduced to Debian some months ago and
> > had been pending in NEW queue since, was rejected few days ago, like
> > this:
> >
> > Quoting Debian FTP Masters (2024-05-14 12:00:12)
> > >
> > > An exception was raised while processing the package:
> > > Traceback (most recent call last):
> > > File "/srv/ftp-master.debian.org/dak/dak/process_policy.py", line 121,
> > > in wrapper
> > > function(upload, srcqueue, comments, transaction)
> > > File "/srv/ftp-master.debian.org/dak/dak/process_policy.py", line 248,
> > > in comment_accept
> > > transaction.copy_binary(
> > > File "/srv/ftp-master.debian.org/dak/daklib/archive.py", line 390, in
> > > copy_binary
> > > self._ensure_extra_source_exists(filename, db_source, archive,
> > > extra_archives=extra_archives)
> > > File "/srv/ftp-master.debian.org/dak/daklib/archive.py", line 214, in
> > > _ensure_extra_source_exists
> > > raise ArchiveException('{0}: Built-Using refers to package {1} (=
> > > {2}) not in target archive {3}.'.format(filename, source.source,
> > > source.version, archive.archive_name))
> > > daklib.archive.ArchiveException:
> > > p/pandoc-filter-diagram/pandoc-filter-diagram_0.2.1-1_amd64.deb:
> > > Built-Using refers to package rust-ahash (= 0.8.9-2) not in target
> > > archive ftp-master.
> >
> > I it correct to derive from the above, that packages in NEW queue must
> > be freshly built, and that I (and we, generally) therefore should
> > routinely rebuild packages pending in NEW queue to ensure that they are
> > acceptably?
>
> Not a ftp-master, but if you see such a message, it means that your
> package has already been accepted, and you can continue uploading
> without going through the NEW queue again.
Thanks, Shengjing Zhu - you are right, althought the concrete *release*
of the package was rejected, the package was nonetheless approved.
Confusing. I learned something new that day.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Bug#1071475: ITP: rdf2rml -- visual graph modelling using RDF semantic graph notation
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rdf2rml Version : 0~20240410 Upstream Contact: Vladimir Alexiev (valexiev) * URL : https://github.com/VladimirAlexiev/rdf2rml * License : GPL-1+ or Artistic Programming Lang: Perl Description : visual graph modelling using RDF semantic graph notation The rdf2rml provides two command-line tools: . * rdf2rml - convert RDF example to R2RML script * rdfpuml - convert RDF to PlantUML diagram . rdfpuml makes true diagrams directly from Turtle examples using PlantUML and GraphViz. . rdf2rml generates R2RML transformations from examples, which saves about 15x in complexity and ensures compliance of the actual conversion to the model. Typically the example is an rdfpuml model. . Diagram readability is of prime concern. . Resource Description Framework (RDF) is a standard model for data interchange on the Web. This package will be maintained in the collaborative Debian section of salsa, at <https://salsa.debian.org/debian/rdf2rml/>. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmZKdg4ACgkQLHwxRsGg ASGRoxAAkM4Be1fiF/YTCdkF9EomWdprqRPFp17neSS2We/QNZNtXn8SHJfqCP0D CHe63ZJo0dQPpVxOmsklLM02qffC5hwKTZaBj7HpBk0rW2aylb+a1ragJV6/dkkS T4oJRKpbokEH9+toXaSbl1ghi1GRmMfcFG1IpKyZzf36V3qUS/1lMddQ1r/ZEbJm vMgAyNVkq/pYsew/IvkAYDSiIzBAPqhAO9/ZbNZbHsWErKMtrym4QulnZwmZTdex b09B3JbuxCJoa/sk9AM99evS+2jrwRMOpe54pAOXQtMqLIhmgfxk8UmOiLtMI6vO W2gtHKo1lZn8Ogsms6d4xKNMfIHz3ZfBf1gOhbt/Ayn6dXH00SphztdhQQnKncKq AcD4GQm4CMU5vb9VKdAKRXwPj2tCVrCqjaJJOEbANBqDOp9g6x9vJ1mxvTnIFx0V XAChweqiaB1xTMk+lSFamcZDtVpeaJAImWy17ikDZtBvrrRCl0FVRn/2TqSFYHYz 6EWvMxfph9As2Jzr4XR4lXOi0DH67ToktexQrDsbopVPppqgkxcJ+FHvBskOMQXp PMc5Yo3gDMFxupDwXULaaF4XO0wq2sLZp8xzY8cgK6H+yTuwIlyXD+DBsvz2AAHF RxrI8035RdVfi9puCXHVuy1+9vEvSHeoLTTW/Cb2+FcRW+O1Yl4= =pXRE -END PGP SIGNATURE-
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
Quoting Otto Kekäläinen (2024-05-19 21:32:36) > > > My concern about Gitlab is not its *additions* to existing services, but > > > its *duplications* of core services already in Debian. > > > > I agree, that's the key problem. > > I agree that duplication is bad - but I disagree that use of version > control duplicates the use of the Debian archive for source code > storage, or that use of GitLab for code reviews would duplicate > Debbugs. > > > > ...instead of lumping all those discussions into a discussion of ease of > > > user interface for a single catch-all code forge that maybe make all those > > > other complications go away by affecting all those questions and that way > > > implicitly provides *some* answer to them all. > > > > Also, there is a difference between ease of use and intuitivity. GitLab > > does not provide any tools that really make packaging easier. It is > > initially more accessible to non-maintainers, because of familiarity, > > but actual work happens outside of it. > > Would you be kind and try to understand the opposing viewpoint by > trying it for one day? > > You could go to > https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 and > conduct a code review? > > You might discover that GitLab is useful and is not duplicating > Debbugs or anything else in Debian - it is currently the only platform > to conduct code reviews on in a way that has automatic testing and > comment-response-resolved -tracking. Doing code reviews patches > attached in email does not have that. > > If you try it out, and still think Salsa is bad for Debian, then I am > more willing to accept your stanze. But it *is* duplicating Debbugs: None of your valuable contributions posted as part of your code review appears on Debbugs. The developers of FreedomBox (which is a Debian Pure Blend, i.e. a project fully within Debian) has embraced Salsa, and when I asked about an issue with network instability for certain hardware, I was told that it was in the issue tracker - which meant it was missing from Debbugs while actively discussed in Salsa. Salsa is *great* if you fully embrace it. Salsa is not good if you want single features without fully embracing it. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
Quoting Mathias Behrle (2024-05-19 11:08:58) > * Jonas Smedegaard: " Re: Salsa - best thing in Debian in recent years? (Re: > finally end single-person maintainership)" (Sun, 19 May 2024 10:47:38 > +0200): > > > > i.e. you are being > > asocial if you don't, and can expect your behavior being discussed as a > > public-wide issue for the project). > > I very much agree with all what you say, however could we rather say instead > > -> i.e. you are not being collaborator friendly, and can expect your behavior > be > frowned upon... > > I am not a native english speaker, I think we can avoid to trap in a can of > worms with problematic terms like 'asocial, unsocial, anti-social...' which > could have quite special meanings in different cultures. Thanks for raising awareness to this. I was unaware that "asocial" was disruptive to the conversation, but indeed danish dictionaries (I am no native english speaker either) flag that word as condescending. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
Quoting Paul Gevers (2024-05-19 10:05:38) > In this discussion about mandating things, I've been wondering > > On 19-05-2024 9:11 a.m., Jonas Smedegaard wrote: > > * mandate VCS-tracking > > * Yes > > * mandate the use of one specific VCS > > * Yes: git > > What do people think this should mean, a *should* or *must* in policy? > That the package has a RC bug if the packaging isn't tracked in git? And > if the packaging is in git but I forgot to push my latest changes to the > documented git server (this happens regularly to me as I do most uploads > with dgit)? RC? In all suites where the packaging version isn't pushed > for? And how about NMU's? (I just checked a random package without git: > aspell-am, last non-NMU upload was in 2013)? > > If *must* and thus RC, can the issue be fixed by "NMU"? I.e. if the > person that did the changes, (and has nice local commits) somehow isn't > available, will the package (if not key) be auto-removed? Or can > everybody fix the repo? What if you don't have write access to the > existing repo? And then what if the uploader comes back and tries to > push the real history? What if my harddisk with local changes crashes > before I push (again, I forget that sometimes, but for me luckily dgit > will mostly have the commits). > > Or is this "just a bug", maybe even at level important, but no other > consequences. Than I think this discussion is going to be moot. I don't > think there's much forcing possible and I think most already agree that > stuff *should* be in VCS, so this isn't going to change for those in > favor. And does it really add enough value if those that are forced are > just going to do "gbp import-dsc" for each upload to the archive on a > ./debian only repository? Because that (or better) we could already > automate (see also my PS). With "mandate" I do not mean kick out if non-compliant. Same as we (as far as I am aware) mandate declaring Poilcy version followed by a package, but don't kick out packages having mismatching declaration or not following latest policy. I think there is a big difference between saying that Salsa (or git, og Debbugs, or public-wide WNPP work tracking) is an optional addon to Debian, to saying that it is expected of everyone (i.e. you are being asocial if you don't, and can expect your behavior being discussed as a public-wide issue for the project). So I disagree that tool-use severity of "important" makes progress moot. I have met developers who have the view that we are already at the point of non-use of Salsa being asocial behavior, and had at least one very interested (and calm) exchange of such differing views at Debconf in Kosovo. Deciding project-wide where we are on that scale do help, I think. > PS: I've always wondered if the dgit server shouldn't track history, > even if uploads don't happen via it. A dgit clone could (should?) > already provide available history, even if no upload happened via it yet. All the points that I listed are all about optional/expected/required *contributor* streamlining. If I understand your comment above about dgit correctly, it is about automation of history tracking, which is (mostly) orthogonal to *contributor* streamlining. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
t opinion on each of the above is this: * mandate VCS-tracking * Yes * mandate the use of one specific VCS * Yes: git * mandate one specific VCS workflow * Not yet, but require unusual workflow flagged and documented * mandate collaborative packaging * Not yet, but * mandate project-wide issue tracking * Yes: personal/team issues like WNPP work are project issues * mandate a single project-wide issue-tracker * Yes: Debbugs (for now: open to switch but not to duplicate) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: pandoc-filter-diagram_0.2.1-1_amd64.changes REJECTED
Quoting Paul Gevers (2024-05-16 11:37:54) > On 16-05-2024 10:35 a.m., Jonas Smedegaard wrote: > > Just to clarify, the package in question does not directly depend on > > rust-ahash 0.8.9-2, that Built-Using information is (as is the general > > purpose of that field, I believe) transitive. > > Built-Using is used for license compliance so we HAVE TO have the exact > version in the archive. If the version mentioned in the Built-Using > field is no longer in the archive, the package can't be accepted. Makes great sense. Thanks, Paul. I will try in future to pay attention specifically to Built-Using for long-pending NEW packages. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: pandoc-filter-diagram_0.2.1-1_amd64.changes REJECTED
Hi FTP-masters (cc d-devel list),
A package, that I had initially introduced to Debian some months ago and
had been pending in NEW queue since, was rejected few days ago, like
this:
Quoting Debian FTP Masters (2024-05-14 12:00:12)
>
> An exception was raised while processing the package:
> Traceback (most recent call last):
> File "/srv/ftp-master.debian.org/dak/dak/process_policy.py", line 121, in
> wrapper
> function(upload, srcqueue, comments, transaction)
> File "/srv/ftp-master.debian.org/dak/dak/process_policy.py", line 248, in
> comment_accept
> transaction.copy_binary(
> File "/srv/ftp-master.debian.org/dak/daklib/archive.py", line 390, in
> copy_binary
> self._ensure_extra_source_exists(filename, db_source, archive,
> extra_archives=extra_archives)
> File "/srv/ftp-master.debian.org/dak/daklib/archive.py", line 214, in
> _ensure_extra_source_exists
> raise ArchiveException('{0}: Built-Using refers to package {1} (= {2})
> not in target archive {3}.'.format(filename, source.source, source.version,
> archive.archive_name))
> daklib.archive.ArchiveException:
> p/pandoc-filter-diagram/pandoc-filter-diagram_0.2.1-1_amd64.deb: Built-Using
> refers to package rust-ahash (= 0.8.9-2) not in target archive ftp-master.
I it correct to derive from the above, that packages in NEW queue must
be freshly built, and that I (and we, generally) therefore should
routinely rebuild packages pending in NEW queue to ensure that they are
acceptably?
Just to clarify, the package in question does not directly depend on
rust-ahash 0.8.9-2, that Built-Using information is (as is the general
purpose of that field, I believe) transitive.
Kind regards,
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Re: gnulib
Quoting Simon Josefsson (2024-04-18 09:34:26) > Jonas Smedegaard writes: > > > That said, you are welcome to try nudge me if some concrete task > > emerges where you image I might be of help. > > Thanks -- I'm moving this out of 921954@bugs and cc'ing debian-devel to > allow others to help and to allow you from not having to feel a need to > reply at all :) Thanks for releaving me. ...but then you bring up licensing, which has my special interest :-D > One of the things that bothered me with the gnulib Debian package that > I've been too afraid to touch is the debian/copyright file. It triggers > a lot of lintian errors: > > https://udd.debian.org/lintian/?packages=gnulib > > For reference here is current debian/copyright: > > https://salsa.debian.org/debian/gnulib/-/blob/debian/sid/debian/copyright > > I've seen debian/clscan/ and ran the tools there, but I don't yet feel > comfortable patching things, and it didn't produce clean results even > for the last version in testing before I started to work on this > package, so I'm not convinced this toolchain is the best approach going > forward. When I took over maintenance my first thought was also to get rid of the clscan script, but then I realized how enormous a work it would be to approach it differently and wrapped my head around the script and adjusted it. Does it sound like you are in a similar situation now as I was, or is there something in particular that makes you consider abandoning clscan? If you are simply not fluent in perl, then perhaps reach out to the Debian perl team for help? Or perhaps look in the git history the tweaks that I made - perhaps those are of inspiration to whatever issue you are running into now? > One problem is that lintian doesn't like [REF01] in lines like this: > > License: FSFAP [REF01] I agree with lintian about the above (but we disagree on other things - see bug#786450). I am confident that the above syntax is incorrect: copyright format 1.0 requires a single-word shortname. > Is the reason why this is done that you want to record a full copy of > the actual text from the particular file AND some more information? > Sometimes there is a file X with the FSFAP license and some additional > text not part of the core FSFAP license, and another file Y that also > uses FSFAP but has some OTHER additional text that you want to record? I guess so. While I maintained the package I did some cleanup of the copyright file, but did not get around to tightening the [REFnn] syntax, and I have not been in touch with the previous maintainer who introduced it, Ian Beckwith, which is why I am only guessing here. > In some other packages, I've used the Comment: field like this for > situations like that. Maybe it is applicable here? > > Files: * > Copyright: 2016 Google LLC. All Rights Reserved. >2022 Trillian Authors. All Rights Reserved. >2016 The Kubernetes Authors. >2017 Google LLC. All Rights Reserved. > License: Apache-2.0 > Comment: Quoting AUTHORS: > # This is the official list of benchmark authors for copyright purposes. > Antonio Marcedone > Google LLC > Internet Security Research Group > Vishal Kuo > > The idea is that from a legal perspective, the copyright notices and > keywords 'FSFAP' and 'Apache-2.0' with full text copy of the license is > sufficient documentation. However, for reasons like proper attribution > and having more background information, it is useful to say something > more than what's legally required, including properly quoting the > relevant files. I think the Comment: section makes for a better place > than License: fields for this. I generally agree with your approach above. Specifically for your concrete example above, I find the Comment superfluous. Also, one detail: I would avoid content in first line of the Comment field - i.e. I would move the text "Quoting AUTORS:" down on a separate line, indented same as the following lines. Arguably the syntax used above is technically permitted, but I have not seen it used. Details on that is here: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#formatted-text - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Silent hijacking and stripping records from changelog
Quoting Jonathan Dowland (2024-04-18 09:35:41) > On Wed Apr 17, 2024 at 7:26 PM BST, Jonas Smedegaard wrote: > > To be fair, I _was_ upset (not with Jonathan, but) earlier in this > > thread, which makes it harder to err on the side of a mistake when I > > write something that can be read as being sarcastic. > > I would be upset too if my packages were repeatedly hijacked. > > > Sorry, Jonathan, for being difficult to read here. > > No problem: Sorry for lapsing in assuming good faith on my part. > > WRT Haskell and the monorepo, I've just done a bit of digging to try and > remind myself why it was necessary, and I've not found a satisfactory > answer. Perhaps there isn't one! [1] says it's "easier to update them > in bulk" which, in isolation, I personally don't think is sufficient for > the trade-off. I agree with your view. The need for efficiency is the reason that I mentined in my rant previously that the Perl team has made use of myrepos to kinda get a bit of both: Track each package in independent VCS, while easing sweeping operations across a pile of similarly structured packages. > I've just noticed that you upload Pandoc, and it (thankfully) is in an > individual repo. You don't build a library package, perhaps that's > relevant. I haven't traced the history that results in there being a > separate haskell-pandoc source package yet. > > [1] https://lists.debian.org/debian-haskell/2024/02/msg1.html > [2] https://tracker.debian.org/pkg/haskell-hakyll Until recently, Debian source package src:pandoc provided binary packages pandoc (containing an executable binary) and ghc-pandoc-dev (containing a Haskell library). I never liked the Haskell team giant-git-repo thingy, and that source package has been mainained in an independent git repo, with collaboration and coordination with the Haskell team on doing that. The reason for the split was changes to upstream tooling (instead of building lib and binary in concert, they were split into separate git repos and building binary would need library already built), combined with infexible tooling in Debian (Haskell libraries still rely on CDBS which in itself can handle chainloaded builds but it is tricky to do right and even more tricky to do so with the Haskell-specific CDBS addons). I tried but gave up, and handed over maintenance of the Pandoc library part to the Haskell team. I also maintain a few other Haskell libraries and binaries, also outside of the Haskell team giant-git-repo thingy. The Haskell team tolerate that. I am unaware if I am alone in maintaining Haskell packages outside of the team giant-git-repo thingy. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Silent hijacking and stripping records from changelog
Quoting Russ Allbery (2024-04-17 19:53:06) > Jonas Smedegaard writes: > > Quoting Jonathan Dowland (2024-04-17 17:29:11) > >> On Wed Apr 17, 2024 at 10:39 AM BST, Jonas Smedegaard wrote: > > >>> Interesting: Can you elaborate on those examplary contributions of > >>> yours which highlighted a need for maintaining all Haskell packages in > >>> same git repo? > > >> My Haskell contributions (which I did not enumerate) are tangential to > >> the use of a monorepo. But it strikes me as an odd choice for you to > >> describe them as examplary. Paired with you seeming to file me on "the > >> opposing side", your mail reads to me as unnecessarily snarky. Please > >> do not CC me for listmail. > > > I can see why it might come across as snarky. It was not intended that > > way. > > > I just meant to write describe your contributions as examples, but I > > realize now that with your emphasizing it that I wrongly described them > > as extraordinary examples. > > I suspect (based on Jonas's domain) this is one of those subtle problems > when English isn't your first language. The English language is full of > weird connotation traps. > > For anyone else who may not be aware of this subtle shade of meaning, an > English dictionary will partly lie to you about the common meaning of > "exemplary" (which I assume is what Jonas meant by "examplary"). Yes, it > means "serving as an example," but it specifically means serving as an > *ideal* example: something that should be held up as being particularly > excellent or worthy of imitation. > > If you ask someone "could you elaborate on your exemplary contributions," > a native English speaker is going to assume you're being sarcastic about > 90% of the time. In common usage, that phrase usually carries a tone > closer to "please do enlighten us about your amazing contributions" than > what Jonas actually intended. > > I keep having to remind myself of this in Debian since many Debian > contributors have *excellent* written English skills (certainly massively > bettern than my language skills in any language other than English), so > it's easy to fall into the trap of assuming that they're completely > fluent, but English is full of problems like this that will trip up even > highly advanced non-native speakers. Thanks for elaboring, Russ. To be fair, I _was_ upset (not with Jonathan, but) earlier in this thread, which makes it harder to err on the side of a mistake when I write something that can be read as being sarcastic. Sorry, Jonathan, for being difficult to read here. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Silent hijacking and stripping records from changelog
[replying list-only - unable to identify who is subscribed] Quoting Jonathan Dowland (2024-04-17 17:29:11) > On Wed Apr 17, 2024 at 10:39 AM BST, Jonas Smedegaard wrote: > > (or did I misunderstand your point?) > > You misunderstood my point: I was actually supporting your position. Oh! > You've read it entirely backwards. > > > Interesting: Can you elaborate on those examplary contributions of yours > > which highlighted a need for maintaining all Haskell packages in same > > git repo? > > My Haskell contributions (which I did not enumerate) are tangential to > the use of a monorepo. But it strikes me as an odd choice for you to > describe them as examplary. Paired with you seeming to file me on "the > opposing side", your mail reads to me as unnecessarily snarky. > Please do not CC me for listmail. I can see why it might come across as snarky. It was not intended that way. I just meant to write describe your contributions as examples, but I realize now that with your emphasizing it that I wrongly described them as extraordinary examples. I am still curious what you meant - regardless if pro or con Haskell team packaging style. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Silent hijacking and stripping records from changelog
Quoting Jonathan Dowland (2024-04-17 11:14:20) > On Mon Apr 8, 2024 at 9:21 PM BST, Jonas Smedegaard wrote: > > What I am not open to is abandon the one-git-repo-per-source-package > > packaging style that is commonly practiced in Debian. As I understand > > it, only Haskell and Rust teams use giant-git-for-all-team-packages > > style > > I've never interacted with any Rust packaging. > > For Haskell, I believe there are sound technical reasons for the > monorepo. I have found that trying to contribute fixes to Haskell > packages is difficult because it is so different from Debian convention. > I think that's important, so a decision to use a monorepo should not > be taken lightly. Interesting: Can you elaborate on those examplary contributions of yours which highlighted a need for maintaining all Haskell packages in same git repo? (or did I misunderstand your point?) Also, for the record (as the above could be misread as such): I do not take such decision lightly. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1069129: ITP: rust-hypothesis -- wrapper and CLI for the Hypothesis API
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-hypothesis Version : 0.11.1 Upstream Contact: OutOfCheeseError * URL : https://github.com/out-of-cheese-error/rust-hypothesis * License : BSD-2-clause Programming Lang: Rust Description : wrapper and CLI for the Hypothesis API The hypothesis crate provides a lightweight wrapper and CLI for the Hypothesis Web API v1.0.0. It includes all APIKey authorized endpoints related to... * annotations (create / update / delete / search / fetch / flag) * groups (create / update / list / fetch / leave / members) * profile (user information / groups) . This package contains the source for the Rust hypothesis crate, for use with cargo and dh-cargo. This package is needed for gooseberry (bug#106). It will be maintained in the collaborative Debian section of Salsa, at <https://salsa.debian.org/debian/rust-hypothesis>. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmYe1scACgkQLHwxRsGg ASHzMg//TaU1z7OY+DS0MtsAiXpTO9yHdw6DJMogbDtuFS764y6fPK/A5JNC0NUw ZJoY8ycArhOCzWYDbSFGxYz0llwJwO6VuaPtKa3EUy+www8WjxCkQMzmXiqlSbhl 2qnh3Aj03XyUhmFl4hqiCyVeV0RH7B3Ylj4JGEEgOZhvYZL99OdMixwgHtTZDg6y 2yOxUyhU7ULiuGa5JZaOSSnHqpPdygimny0GDdj5FM5KJ4h32v9u7q9QLoyYADQQ eNVa1zT9hukTee9AlpD7uFtxhXF3IReArakTAjmxoEqAssc+DAZBp4DBHVquai/p Mw6AQY2kX8QOTzaGlNVZ3cVmAGXUxjAhUJfxpJswRmou9mtuI+E1L8N0znfmqQJ4 QfUEq2ZCVvaAis6QysBSZ/AvRfzjX4mIrpeChifk1jxsa8CkIjRdwKEUpiqlpaDf bIIr/K/PpTR2duo/b9U+Y62WyZo/7XTjQTe4pqxcR3E6JmuHSB+K7z8IVxDJzOIA gHzllETerCbMoi+fM1qOKZlCzb5SBIRKyERnFUF1grMsQJr/73jFkS2Bxq+B5sSm dfZsf7D4TeXcdIy6kBcAeZwQsNnINZT0xvHjvJ14oekqm3ayg80okAK8lL505aTE VvkgO632KoD4AVG7GJemSmaKO0nF4djhtK1l9lHe6R0QhAs2uZc= =PeP/ -END PGP SIGNATURE-
Bug#1068927: ITP: rust-event-listener-strategy -- block or poll on event_listener easily
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-event-listener-strategy Version : 0.5.1 Upstream Contact: John Nunley * URL : https://github.com/smol-rs/event-listener-strategy * License : Apache-2.0 or Expat Programming Lang: Rust Description : block or poll on event_listener easily event-listener-strategy provides a strategy for using the event-listener crate in both blocking and non-blocking contexts. . One of the stand-out features of the event-listener crate is the ability to use it in both asynchronous and synchronous contexts. However, sometimes using it like this causes a lot of boilerplate to be duplicated. This crate aims to reduce that boilerplate by providing an EventListenerFuture trait that implements both blocking and non-blocking functionality. This package is needed for newer releases of src:rust-async-lock and src:rust-async-channel. It will be maintained in the collaborative Debian section of Salsa, at https://salsa.debian.org/debian/rust-event-listener-strategy -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmYaklcACgkQLHwxRsGg ASHWLhAAoN2U3vUvMe6vng6U0BCHoImeJor7wGb0RsR8SagWtONeDyubBoK/kNgx lWhvgwcLcgc4bTKPdqqfH44svsQ9qMAQFdYp9QZZXXuUJCKwPjlbrgwcEpUu0gy1 H3mVsZOzwWH2ldnlE6F71L+uQSJriaCyN5HbFXfkXIo25WELcE0trGJletqHuiVM cONmMXGSFNjPc6DFNOfIAUrfyIt9qp1urCu4nzLWsvxBV3CgrUyPBZLlcezOa9wd NfVv2A2FVwxDYqst5hwckmemgjr/82Y5jn8Wd644vhlxIHN7cNFq8awQ1wY3Bz8/ C9VuVyz7P0NCotqM0oWosYk+hZyDEGkiapFiGPQlQSbPTSbBdPRLoMd25W6ABSxk wnW9mBPRhebNl30ZODCePM1PRlM8DhVygeIFkXs3kBScLSRjAMtHh3c4EWw3pcls 7e819qb/mHce4xcrHxeybCl5DB3k6pDpn6+0gHYemrbpAsCcr9aWLoRxTMbh9Uin 5vYugGlaROdD13Ojkinbm+HXmwEEWqTXu/y2M+dzNJNIRS45XsOSAq6nHZKot3jg /LlwCresEdWv7UY8PO4Z21EoXUSrStA8pIqqJyzKx+hXvf/l1vIvV8iYLWDgGGmU ht7rS5GLaoXx2HI0o1hFDeMFU51F0D5Vy6unvbKulJNzv7fLVyA= =Cau5 -END PGP SIGNATURE-
Re: Silent hijacking and stripping records from changelog
Quoting James McCoy (2024-04-09 03:25:16) > On Mon, Apr 08, 2024 at 10:21:49PM +0200, Jonas Smedegaard wrote: > > ...and about moving on: Can you please also clarify if you understand > > "moving on" as reverting to me maintaining the package that you > > accidentally hijacked, or if you instead understand it as you (on bhalf > > of the Rust team) now having taken over maintainership of that package? > > I've already filed an RM request for src:rust-lazy-regex-proc-macros, so > your package will prevail. Ah, good to know. Thanks! > > > Den mån 8 apr. 2024 kl 12:41 skrev James McCoy : > > > > Now, that happens because our tooling is based around a 1:1 > > > > relationship of crate to source package where as you've been > > > > packaging an entire workspace as a source package. We need to adapt > > > > our tooling to better detect this so we get accurate information > > > > presented to us and avoid stepping on your work. > > > > Yes, please improve your tooling to better align with Debian packaging > > rules, not assume your team rules apply also outside of your team. > > Having policy for a language ecosystem is pretty common, since that > makes it easier to interoperate. Yes, team-specific policies exist, to ease work within those teams. Team-defined policies do not, however, hold any special powers outside of said team, so it is sensible for them to not conflict with general Debian packaging policies or assume that all packages *outside* of the team are aligned by those team-specific policies - e.g. that a binary package containing cargo crate source files must¹ be built from a source package with same name as that cargo crate. ¹ "Package naming" in https://wiki.debian.org/Teams/RustPackaging/Policy > > > > I'd still prefer if we could consolidate our efforts into the rust > > > > team (and re-integrate your forks of our package helpers), rather > > > > than have two divergent sources of rust packaging. > > > > I would also prefer if we could consolidate our efforts, and am open to > > joining the Rust team and collaborate there, as also stated previously. > > > > What I am not open to is abandon the one-git-repo-per-source-package > > packaging style that is commonly practiced in Debian. As I understand > > it, only Haskell and Rust teams use giant-git-for-all-team-packages > > style, and only the Rust team strictly enforce that style (Perl team > > uses myrepos to work across many packages which I recommend you to > > consider). > > When I first started looking into Rust packaging it was initially going > to be for a workspace of crates. I didn't receive any pushback when I > asked about taking over the one crate that had already been packaged and > handling it from a single source package for that workspace. In the end > I changed my mind and continued using the monorepo for the rest of the > crates. > > It makes certain things easier, while using a repo based on upstream git > makes other things easier. Which method is used is up to the maintainer. > Not using the monorepo just requires better coordination. Well, I received strong pushback by Ximin (on irc - I can share chat log discretely if interested) when I joined the team and published a single-package-repo rust library (possibly the first librust-* in Debian), and the pushback and insisting on strong rules imposed for team members lead me to drop that package and leave the team. I have since, every time I have been approached by Rust team members and suggested to join the team, shared my concern about the Rust team policy, and asked if those policies might have changed, or if those approaching me might see a benefit of working towards changing team policy. I am not quite sure what you are really saying above. Squinting my eyes it kinda sounds like you might be open to relaxing team policy. If that's the case then that's great news. I look forward to that. If you are interested in better understanding my notivation for the crisicism I raise towards the Rust team policy, then feel free to reach out - I am happy to elaborate. > > More important, however, and despite what I can or cannot agree with: > > For as long as the Rust team chooses to deviate from general Debian > > practices, it *must* constrain those deviated rules to team work, and > > *not* make the flawed assumption that all Rust crates in Debian are > > aligned with Rust team packaging rules. At any time any Debian developer > > may upload a rust-* package - that namespace does not belong to the Rust > > team, regardless if/when I join the team. > > As far as I know, no one has claimed that we have sole ownership of the &
Re: Silent hijacking and stripping records from changelog
Hi Alexander and James, Quoting Alexander Kjäll (2024-04-08 16:42:22) > I'll second what James wrote, this was done by mistake by me as our > tooling didn't discover your package and I'm sorry for the extra work > it caused. Thanks for clarifying that it was an accident. Accidents happen. Let's move on. ...and about moving on: Can you please also clarify if you understand "moving on" as reverting to me maintaining the package that you accidentally hijacked, or if you instead understand it as you (on bhalf of the Rust team) now having taken over maintainership of that package? The reason I ask about that so meticulously is that in the recent past, I assumed the former but Sylvestre evidently meant the latter (judging from his later response and his inaction regarding related bugreport). > Den mån 8 apr. 2024 kl 12:41 skrev James McCoy : > > On Sun, Apr 07, 2024 at 09:58:10PM +0200, Jonas Smedegaard wrote: > > > And when you do hijack packages²³, then please be respectful and > > > give credit, by preserving/reviving past contributions in the > > > changelog file. > > > > As the person who uploaded rust-lazy-regex-proc-macros, I wasn't > > aware the crate already existed in Debian and wasn't intending to > > upload a hijack of your package. The Rust team _does_ have a lot of > > automated tooling and when I prepared the upload to NEW, it agreed > > the package was new. Thanks for the clarification. As said above: Understood, accidents happen. > > Now, that happens because our tooling is based around a 1:1 > > relationship of crate to source package where as you've been > > packaging an entire workspace as a source package. We need to adapt > > our tooling to better detect this so we get accurate information > > presented to us and avoid stepping on your work. Yes, please improve your tooling to better align with Debian packaging rules, not assume your team rules apply also outside of your team. > > I'd still prefer if we could consolidate our efforts into the rust > > team (and re-integrate your forks of our package helpers), rather > > than have two divergent sources of rust packaging. I would also prefer if we could consolidate our efforts, and am open to joining the Rust team and collaborate there, as also stated previously. What I am not open to is abandon the one-git-repo-per-source-package packaging style that is commonly practiced in Debian. As I understand it, only Haskell and Rust teams use giant-git-for-all-team-packages style, and only the Rust team strictly enforce that style (Perl team uses myrepos to work across many packages which I recommend you to consider). I am also not open to abandon packaging as Debian source the upstream code files in the preferred form for editing. Rust team instead distributes upstream preferred form for prepackaged distribution, as also practiced elsewhere included in the Perl team, but as far as I am aware is only strictly required in the Rust team. The one-crate-per-Debian-source-package packaging style enforced within the Rust team is a consequence of above preference of tracking upstream not-preferred-form-for-editing-source-but-crates.io-distribution. I find that problematic and as long as you insist on that you will need to be cautious to not wrongly asume the same for the rest of Debian. More important, however, and despite what I can or cannot agree with: For as long as the Rust team chooses to deviate from general Debian practices, it *must* constrain those deviated rules to team work, and *not* make the flawed assumption that all Rust crates in Debian are aligned with Rust team packaging rules. At any time any Debian developer may upload a rust-* package - that namespace does not belong to the Rust team, regardless if/when I join the team. I am happy that you bring up my forks of cargo-related package helpers. I'd be delighted if they were to be adopted in dh-cargo, as that would simplify my packaging. Only reason I haven't filed bugreports was that my past interaction with Wimin and Josh regarding the core packaging choices of those helper script of yours left me with a very clear understanding that the Rust team had made those choices deliberately and was not about to negotiate changes to them. As I've mentioned before, if I am mistaken and Rust team *is* interested in adopting my changes (not only single persons like yourself, and others from the Rust team that have discretely reach out to me in recent years) then great: Please do tell me if you need help adopting them or perhaps understanding them - beyond what I have already attempted to clarify in commit messages here: https://salsa.debian.org/build-common-team/dh-cargo-fork/-/commits/wip/opinionated/ Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Silent hijacking and stripping records from changelog
Hi Sylvestre and Alexander (cc Rust team and debian-devel), Please do not silently hijack packages. If you would like to take over maintenance for some package, then please ask. Then I won't bite¹. And when you do hijack packages²³, then please be respectful and give credit, by preserving/reviving past contributions in the changelog file. Kind regards, - Jonas ¹ Just like I didn't bite at the accidental hijack in February: Quoting Jonas Smedegaard (2024-02-17 02:20:03) > Hi Sylvestre, > > Quoting Sylvestre Ledru (2024-02-16 19:24:00) > > I am really sorry but it seems that I made a mistake with rust > > palette: > > > > https://tracker.debian.org/pkg/rust-palette > > > > I didn't realize that it was already uploaded (probably because I > > uploaded https://tracker.debian.org/pkg/rust-palette-derive ) > > > > Please let me know how to fix this issue :( > > > > I needed it for the new version of eza! > > Ok, I will try fix that. I recognize how that confusion could arise (as > in: I could've easily made the same mistake - and possible did). > > Please take a look at related bug#1063779. And just as I didn't bite when, after ignoring the above mentioned bug and after my work cleaning up after the February accident, that same package *again* was hijacked: https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2024-April/040451.html Only when you shrugged when my pointing out that second hijack did I arguably bite: https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2024-April/040452.html ² This changelog: https://tracker.debian.org/media/packages/r/rust-palette/changelog-0.7.5-1 is missing these entries: https://salsa.debian.org/debian/rust-palette/-/blob/debian/0.7.4.0+dfsg-3/debian/changelog ³ This changelog: https://tracker.debian.org/media/packages/r/rust-lazy-regex-proc-macros/changelog-3.1.0-1 is missing these entries: https://tracker.debian.org/media/packages/r/rust-lazy-regex/changelog-3.1.0-1 -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Is it allowed to remove attribution in public domain "licensed" source code? (and pondering about ftp-level reviews)
Quoting Otto Kekäläinen (2024-03-30 22:09:46) > Is it so that the debian/copyright file is reviewed by ftp-masters > only for packages in NEW queue, and there is probably no automation in > place to flag subsequent copyright changes for re-review? It is my understanding that it is, and always has been, the responsibility of the _uploader_ and not ftp-masters to ensure that debian/copyright data is accurate. True, ftp-masters review, but we should not rely on that. Which means the flagging you ask about is something each package maintainer should (either themselves or through their choice of tooling) put in place. What I do is recheck for changes to copyright and licensing changes each time a package is changed to use a new upstream release. I am greatly helped (but do not fully trust - I also manually look at source files) by an automated licensecheck scan, where I keep a dump of that in the source package, and compare to a rescan after importing the upstream code but before releasing it: https://wiki.debian.org/CopyrightReviewTools#licensecheck - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1067574: ITP: rust-leptess -- rust-leptess
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-leptess Version : 0.14.0 Upstream Contact: QP Hou * URL : https://github.com/houqp/leptess * License : Expat Programming Lang: Rust Description : productive Rust binding for Tesseract and Leptonica Leptess provides productive and safe Rust bindings/wrappers for Leptonica and Tesseract. . This package contains the source for the Rust leptess crate, for use with cargo and dh-cargo. This package is needed for subtile-ocr (bug#1014093). It will be maintained in the collaborative Debian section of salsa, at <https://salsa.debian.org/debian/rust-leptess>. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmX/T4AACgkQLHwxRsGg ASGBUA/+NOIWlXT6DSTueqHMsnrAHe82jM3solSp2amVBhLt9GYdz/sjZtzW+R2s tRx3Fjh/aPPecE57lOtphLmBe7MxN1I+ulsCSfExCga33LJuHd0Cm2LGdM7tnaTK DIa7R4JwQapregebbcvTZOrzSBp1i9iugU7+OOdR1Yiluu5BW5+aaN8bNrjI MWuTcPwQ7YO8gIejQBH5Gh1pZ1KvgZrbeeea41gNksFnMwh2JGfsuTaNvHVUztcL oovJg05sRjblpvbTEVEEg/Ad2cmrw3OUmx2qSCcHbzu5yJtgRTPmXBAwoNjSf+2b ZhTMHtP3WeQkMqWKybj7LPlqD7hlj7VsfdQ7P/GjDpSMx9MAMeTxsZ8wQCc1nMUI 8M1N3i3ArT2VNBYx3t5YcsZxyRo4MLtoPnbUnh5dZdS6YyI65miR5wxbKO4UUSQG koa8u6F3CEQ61dBS6SAzTuz/8CdYhgHTT8ytdQL51z+Tmdt7bG/ecXclsev3ZWEm DTSb5rn2K03pKsBDsAKIbwJNgd/VS18vquAibgQooqgcRigONKR5U/ahYo30sIlJ EWMHhNfRpissfOF1csS0uCV14m2Hwffo3dMreBh0Q3llzPTziykFjwSHonKzsq5x kf3pD3cD4U5lNWY6XwjIXCHAx3vu6MV71Ev6dRARaQogaK/NQV4= =96nN -END PGP SIGNATURE-
Re: Policy: should libraries depend on services (daemons) that they can speak to?
Quoting Vincent Lefevre (2024-03-06 12:17:55) > On 2024-03-06 06:29:24 +0100, Jonas Smedegaard wrote: > > Quoting Arnaud Rebillout (2024-03-06 02:26:00) > > > However it's true that some packages are installed before that, at the > > > debootstrap stage, and I guess debootstrap doesn't honor "Recommends:"? > > > > Correct. This is tracked as bug#742977 > > Bug#742977 is about whether to mark installed packages as > auto-installed or not. It is not about Recommends. Sorry. You are right, of course. It is another related issue. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Policy: should libraries depend on services (daemons) that they can speak to?
Quoting Arnaud Rebillout (2024-03-06 02:26:00) > On 05/03/2024 9:22 pm, Vincent Lefevre wrote: > > On 2024-01-15 11:15:32 -0500, Theodore Ts'o wrote: > >> For example, when I implemented libuuid, if you want to create a huge > >> number of UUID's very quickly, because you're a large enterprise > >> resource planning application, the the uuidd daemon will allow > >> multiple processes to request "chunks" of UUID space, and create > >> unique UUID's without having to having to go through some kind of > >> locking protocol using a single shared state file. > >> > >> So libuuid works just fine without uuidd, but if you are populating a > >> large ERP system, then you very much will want uuidd to be installed. > >> So in that case, you can make the dependency relationship be either > >> suggests or recommends, instead of a hard dependency. > > Except that in Debian, this is a "Recommends:", and "Recommends:" > > are normally installed by default... except by the Debian installer! > > This is inconsistent. > > This is not correct. The majority of the packages installed by the > installer are in fact installed via tasksel, and it does install > "Recommends:". The command is there: > https://salsa.debian.org/installer-team/tasksel/-/blob/546b5b99e81bfb69b88de105b6fc78fceacb5ee1/tasksel.pl#L930. > > However it's true that some packages are installed before that, at the > debootstrap stage, and I guess debootstrap doesn't honor "Recommends:"? Correct. This is tracked as bug#742977 - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1064483: ITP: rust-self-encryption -- self-encrypting files
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-self-encryption Version : 0.29.1 Upstream Contact: MaidSafe.net limited * URL : https://github.com/maidsafe/self_encryption * License : GPL-3 Programming Lang: Rust Description : self-encrypting files self_encryption implements a version of convergent encryption with an additional obfuscation step. This pattern allows secured data that can also be de-duplicated. . Convergent encryption, also known as content hash keying, is a cryptosystem that produces identical ciphertext from identical plaintext files. This package is needed by safenet (bug#1008016). It will be maintained in the collaborative Debian section of Salsa, at <https://salsa.debian.org/debian/rust-self-encryption>. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmXX2mIACgkQLHwxRsGg ASGebBAAlpdeliOH5hFVNQGgEFWTK93RaB+FmdJlp6y8ug8jEZncuxzYZfb7Nf7L K/tccUfifB9lqz6tGQBhqKFRJ8iOtYk0IqxIdhZqjAagmQMSZYS0+lTw/NY4WCrl M3hGcrpu4+dibj59FNxj3uoMBBfe7wLMn5pHzzcBL3BBUl9VLAGH82YcLTAeh0jW heBjdy4Ro3IQ8Y1ZcnXgr7QINlRrm57JtG0LxzSnrIKeISLsDO/YqIaM6e7gUcSd 4giz/2Urv9N3fysMR+JXyxq651z4LICh+jnUmVWB2O+Fbh1v5X4JqwxOAnr0BZQF W667aj1MzOpC8A7wqxDGz24zKcgE0fHAVKoVSP45AG/lkVSWD+ppIiyZXXrX6fwE lWXwwXnN7SaFNXxZzM4/w+GREnvqa7loNZ+AKFSh+qBQVjvd1/1Q4Dkn5jezNbjz ZK6hcL7YmR8eMKOo08OpWBk9e1JRU4TGsLIKFR6PepvZCES71X4Vm8mPshSDSeQ3 Uadv1gQtTW5akLDz8s+SDwZ5V82GYM4H4JDHonaSCyDNR85oxeNASUz9VMCBv3BW uJXMXa7xzDk/T5y7lMIA7D/ioKwEsHL/prYB3Tdfv+RLi0C4Z9VA5I+ftA9adzo5 G0dfPHNkzdLSMBfV7s4GT6Z6dbmsim6Qm7s3VHhqZ5zPAsLb5nA= =mQH1 -END PGP SIGNATURE-
Bug#1064474: ITP: rust-rustls-pki-types -- shared types for the rustls PKI ecosystem
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-rustls-pki-types Version : 1.3.0 Upstream Contact: Dirkjan Ochtman * URL : https://github.com/rustls/pki-types * License : Apache-2.0 or Expat Programming Lang: Rust Description : shared types for the rustls PKI ecosystem This crate provides types for representing X.509 certificates, keys and other types as commonly used in the rustls ecosystem. It is intended to be used by crates that need to work with such X.509 types, such as rustls, rustls-webpki, rustls-pemfile, and others. This package is needed by recent releases of rust-rustls and others. It will be maintained in the collaborative Debian section of salsa, at <https://salsa.debian.org/debian/rust-rustls-pki-types>. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmXXsb4ACgkQLHwxRsGg ASHhSw/+JRLgav5wk3niZQvqMtyKmXTb3DfZlx5DK+GMJL2qFtf3TG3hbrWURe2X iX/OZqGSk5/IFJamgKbEFQI6JBtXjzCti6oXaPfVRIHBCF6ZPyISNdStKA2KAf5K q/mh4NpbsSxDhJ00y5dkHSdg5d2p8DFAH+2ZvoW+TdS8eQHORYJ7Tty4G8N60CY7 YnlqefMIFa9i9AU57PlM1sUhTY71jrnwuCeR1dGL1VavBpeQrQihN+j0UdzDaTO7 jjvpmesrdfRMv9wUgvGaZ9GQLeox/rCFp7m5Cktdp5M4pX0itGhIljUd3iFcnvAq hZoJTGvehWdia8GIJHtGk/Ivf9pajTIb4XFT6VWKeoM74H0zpjQSO4AA+WP/TzBk vliuf5moOXVjV3UnvIKdPeLlsr1PtZm7dAzHryoxuru8rI4Sfz3zAU1uFbGrJ2jR DkMSV9ozwPuOXliCaIdQdKzgITz3UN6lcqC9OqNhxJMpI1MOzx1wgNYYcVGOYGMz FaI1yYakhjfJ4W/Jl+PE2sqjuY5dp/kEa8rL7Dq2346rGFOjzSOVIW6gX98QfiMr eug0EBwYDO3QjEfQ/ziLmrt3ClPlSWw5hEAiISJjEEQaMQM2+4ABfndtP8cHWq77 9inuoMQmFyZuvB0CquuyO1Lx3BsBCe8uSjIAINo2JtMnk98pLLw= =oPvz -END PGP SIGNATURE-
Re: Another take on package relationship substvars
Quoting Boyuan Yang (2024-02-22 20:25:32)
> 在 2024-02-22星期四的 19:32 +0100，Niels Thykier写道：
> > I think our package helper tooling should just automatically aggregate
> > all provided substvars of the format ${*:Depends} and append it the
> > Depends field. Rinse and repeat for other relationship fields.
> >
> > The list of fields where this is applied would be curated, so it only
> > applies to known relationship fields where we feel it makes sense. My
> > starting list would be:
> >
> > * Any dependency field, that is: Pre-Depends, Depends, Recommends, and
> > Suggests
> >
> > * The Provides field.
> >
> > I am omitting Breaks, Conflicts, and Replaces because I am not aware of
> > any users of these at the moment. I am open to adding them, if there is
> > a strong use-case.
>
> Can we also consider ${*:Built-Using} as typically seen in
> ${sphinxdoc:Built-Using}?
> This is another field that people keep forget adding. While missing
> this field is not severely harmful, having it automatically handled
> would be beneficial.
...and related to that, also ${*:Static-Built-Using} which is generated
by Rust (and, I seem to recall having read somewhere, Go) tooling.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Re: Bug#1061323: RFP: rust-toml2json -- A very small CLI for converting TOML to JSON
Quoting Facundo Gaich (2024-02-22 17:12:22) > I can work on packaging this if you're still interested, I'd need a sponsor. > > I've already done some preliminary work on this, in particular I renamed > the bin to "rust-toml2json" but maybe you've got a better idea? If the command-line tool does somewhat the same as the existing one, I suggest to rename it with the deviating part as the end instead, so that users TAB-completing would easier notice the alternative: toml2json-rust. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1064163: ITP: rust-futures-rustls -- asynchronous TLS/SSL streams for futures using Rustls
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-futures-rustls Version : 0.24.0 Upstream Contact: quininer kel * URL : https://github.com/quininer/futures-rustls * License : Apache-2.0 or Expat Programming Lang: Rust Description : asynchronous TLS/SSL streams for futures using Rustls futures-rustls provides asynchronous TLS/SSL streams for futures using Rustls. . Rustls is a modern TLS library written in Rust. It uses ring for cryptography and webpki for certificate verification. . Ring is a Rust library implementing safe, fast, small crypto using Rust with BoringSSL's cryptography primitives. . Webpki is a Rust library to validate Web PKI (TLS/SSL) certificates. . This package contains the source for the Rust futures-rustls crate, for use with cargo and dh-cargo. This package is needed by rust-libp2p (bug#1059908). It will be maintained in the collaborative Debian section of Salsa, at <https://salsa.debian.org/debian/rust-futures-rustls>. -BEGIN PGP SIGNATURE- iQIyBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmXRK7AACgkQLHwxRsGg ASEUtw/3eYe0loixgZd/xPwqYxUIYoDd/upVNDRNSuXk7mjx4trW+btOrABxhn7P /7odiwyI6ZC8/aLjvDa+YotECCl0E6/ZAEDF72Pz4ZzMQCousCdZTsNSB5l/1P/F 16G54lVRwU2IjPYEPhDXsTAT/8LFSPV2oY/0fRJiWSESNQLDstrJ3DENmFJvmjWZ 0MOUkFWCZouGjXwzqxso0Na8sK97wsjM6aMS7QZzEsUtuqplw0nkvFMnI5ZJm4VG 8EU1zz/JpwgxFyDI8Zw0EbVhjpzRWD0wb13VEzaROyWvysFAjjH6jNxJZfifYNlh 0Lb2f7Yay7h2IA8M+e3Xh3s+/FXiJLv/X9irqWclU3cSDc2knLQjekdYAQ8yEOWA EJYYdQyVWczwk1+BtaH7KDyWB573XgyhJrq5AjVt1zfFNglVCPbh9eOCyBtE/jvM dbhf9xjqN9Pp2P62xv+qKmGRVeHGpSERniIZFgpaLhNsrgng8dEbY9mAcG/k2r6B Tt5HOfRHUIzEzqq9MfJO8AGwZNrp+cryqTYReOocjb3jMQGg1DcgcBZaZYp28uQr OhM/BDLCpA4BJXdCByg2uTaKIXeevioDb82QxImFHTEyLbqf4P3SOdWKFyF/15Wo ytcmwUVaFIlchmqRhJGRSMVqXs15F6KSNfCsjzmcpao7QO0zGw== =6bYc -END PGP SIGNATURE-
Bug#1064155: ITP: rust-soketto -- websocket protocol implementation
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-soketto Version : 0.7.1 Upstream Contact: Jason Ozias * URL : https://github.com/paritytech/soketto * License : Apache-2,0 or Expat Programming Lang: Rust Description : websocket protocol implementation Soketto is an implementation of the RFC 6455 websocket protocol. . This package contains the source for the Rust soketto crate, for use with cargo and dh-cargo. This package is needed by rust-libp2p (bug#1059908). It will be maintained in the collaborative Debian section of Salsa, at <https://salsa.debian.org/debian/soketto>. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmXRDocACgkQLHwxRsGg ASGObg//UTYrtTt+t5iXeZWM6rXbZYpGhYPO5BYg0sGdykRwGWDq5RM0bC8s0acT oTKm7HqkZLa+uiDVEH4Kl6RPKQ/zglScu+rsZPtx/KiRVjI3pNJuh699uZgIEBUn /14lAMHStMEbiobb5q6REeAQIp0sL+Gi/hoU6+qg3+SvntkC4Asu2XzkHIiaMh37 CKye9bxmGJ/XFTgjxub91AAxCQJaxHyCHyF5wXfGZSpYVuzLKb17vqIuHmHCoyEv UqMfT/HITZph/nKiDMAMx8Zvogf7vCb2plyEiezmeZ79e3SfinCNacUoxr8dNRyV l7sGoKhfd633Q3PesO1Ux2i3Tb7b/ulI8AThzJh9Vs7JKHGrrbeIy+CRvKdhhWhJ GLanrJdSUbqAPey6VxEzu56rW1QcGTpVayd+QOTlGy7c4vRqQHP3kIpOeUPML7hY wyYnA9EVkEDhkIdI4pEMFvF05slBZXF5Ae9zQWdtvod7JwIqsDh0Strw3W0Q4VSh npZY9JD5qjujd2jwpuBjyFezlBOsuOm7zujSA6Urt5rnX0WVJLFcAmW5TFATRJyl Sr9pOssqcQBKtMUMyLBlH9oeS552mX7rOpqhdQRUixKDGauad9xt97UCL5hCg1v7 qv84WHefm94nUt+aRNOE105dfpO+qOvljmFdvfO2DFHS9mTsMHw= =RzfY -END PGP SIGNATURE-
Bug#1064145: ITP: sdml -- CLI tool for Simple Domain Modeling Language
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: sdml Version : 0.2.7 Upstream Contact: Simon Johnston * URL : https://github.com/sdm-lang/rust-sdml * License : Apache-2.0 Programming Lang: Rust Description : CLI tool for Simple Domain Modeling Language sdml is a command-line tool that provides functionality to process SDML files. The Simple Domain Modeling Language (SDML) is a small data-oriented language for constructing, documenting, and reasoning about a conceptual domain model. The SDML language comprises: * a semantic model whose structure and semantics are described in RDF by an OWL ontology * a surface syntax for editing and sharing model artifacts * a constraint language to capture model invariants not covered by the data descriptions in the surface syntax . Resource Description Framework (RDF) is a standard model for data interchange on the Web. . The Web Ontology Language (OWL) is a family of knowledge representation languages for authoring ontologies. This package will be maintained in the collaborative Debian section of Salsa, at <https://salsa.debian.org/debian/sdml>. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmXQ99cACgkQLHwxRsGg ASHdZw/+J+Ku4OKwRJ30CuDKM6wQc5mgoTSGa0tJWZtFkvlKMv8ncblEAcjHVclT 4q7V3+u3umCrO6DErJxgvB5vU2tZvNifoqABtLjluwyTTiKMR2ZxZBc0W/EomdiO O5pL6X5558HCC6mNRxrWhgRA3EqG97UIP156JSo7TCqEfH9sUklVuqF1+HmJjlEM okotoqkL+jNnjBnvajTBdNV2zebqlTrqUo56UBOqQHQzD25otMxNUWkRGTHpven0 fjIhV9UCTVbENH2lNWoat5E/UghsOAeobkCQm6/wWhlxP5vsItp7elzZ3dK7FaA3 s81f7Bue7PVfnAv0NXVK/0pcJTilLSWR3UO2uYWlB/EgRSWIf4cBSpv5H8OycifU /diOy2OA+qu6vPE44a3wnkU6qp3tMIdQc6xdigdsQdvyy6rKAV9gbp8aJqK53NzF ElYdQ+kaISZ6Idx/ha17oBuDghsEv1UGNcf6SS1Hk8Q0T+TAZdGoCDRS6qXOTNYE 251bdusyeJc8CPe5wMHvrisQ/nh5acOdYV49ZLpqGtFYnqQSmdPgok8p2La3qreT ihPHlK1/32C9Q/BfRn2suG09jXRSQ0pkPG7NVwYVx9jeZZxMb+MA/cbhssmE4msF Y743G/zSWLtuTCZxsalDEog1AcMUI6DD+/w5Ucd9XM4vJ+Wq3hc= =Zvbp -END PGP SIGNATURE-
Bug#1062222: ITP: gooseberry -- CLI tool to generate a wiki from Hypothesis annotations
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: gooseberry Version : 0.9.3 Upstream Contact: https://github.com/out-of-cheese-error/gooseberry/issues * URL : https://github.com/out-of-cheese-error/gooseberry * License : Apache-2.0 or Expat Programming Lang: Rust Description : CLI tool to generate a wiki from Hypothesis annotations Gooseberry provides a command-line interface for Hypothesis and lets you generate a knowledge-base wiki, without you having to actually type your knowledge out. . Hypothesis is a tool to annotate the web. This package will be group-maintained at the Debian section og salsa, at <https://salsa.debian.org/debian/gooseberry>. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmW6ou0ACgkQLHwxRsGg ASEmWA/+Lxiy5QS2wqjMyyWUVUSgiI8WVzxJLVgXBKI6XgZ+fKQgLP07LFiqtbLm 97xsA6apVPXJWY5ifngGNfvlka6voUwHa8KQ7M/J8H7QXOYahzY4hro06iwddlWg JlkFGtiWJ5Ad7jvnIL7mzKGOi+K0rC8VGV8zpqdbzpd5C9iIokBueMn4jwbZVvCj Zjty/nQz18TW8ZYBSFb5zbs9PntEOVNXhg4rIrjkftFK3is7AGm4/4bQzTm4BWVQ 89S38U14h1Ox1Ev28do04j/kL5LF7/iSz7VFTlfCXyjqROESDBXsSn/FxnyInciN aq4PrUjVtxUuHC9Jg6pHY5OJi6mi4CRU397VzdK1p4RXd+62XRE9ti0MlDUYlgg+ n0TGMAcTsLxXScYMMH253wNTXb4iQT8eYlaX6xVez78IS1LgmReQUmhDlcvYVWyk dJAd/LPqLkm10kvZKgHlro9BaqULpwUS9hxx2JAOh5qbAYDrblHuIc8vuqJIGXwU P3UNg54OVWfE7G7FSp1X6fHJRuvFRAwN+/BrDo/JLoJmHX7xN8LAiPt0G+Ie2+KW ArlIAr/5qzaVIdWscMLS6PkJ6KdIvRt6JyC8xCwv6SLjLSLBilMVU7lgtn/03rqP rWruNgXRjWFs7uVDDLKuLrumcRa2PGx9hlYyPFgadpW0KPuWKdM= =DwAH -END PGP SIGNATURE-
Re: Proper handling of Lintian warnings due to other packages
Quoting Scott Talbert (2024-01-31 16:49:59) > On Wed, 31 Jan 2024, Jonas Smedegaard wrote: > > > Unfortunately it is not likely that the package will be catch up soon, > > because the Haskell team upgrade most Haskell libraries only as a whole. > > > > That issue is not tracked in debbugs, because those vocal in the Haskell > > team actively discourages the use of debbugs: > > https://lists.debian.org/debian-haskell/2024/01/msg00012.html > > Note: I don't discourage usage of debbugs. It's just that I'm unlikely to > notice bugs immediately due to the way debbugs notifications work. The net effect of a) silence in response to filing bugreports, b) responses when reporting issues to Haskell mailinglist, and even c) you [dissing] my explicit attempts at steering conversation to the bugtracker is discouragement of using the bugtracker. - Jonas [dissing]: Sorry, I cannot find any other way to describe what you did when you replied to the list when I posted https://lists.debian.org/debian-haskell/2024/01/msg3.html and wrote "Meh" when I posted https://lists.debian.org/debian-haskell/2024/01/msg00010.html -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Proper handling of Lintian warnings due to other packages
Quoting G. Branden Robinson (2024-01-31 05:49:00) > At 2024-01-30T19:55:07-0800, Loren M. Lang wrote: > > While building a package preparing for a possible upload, I am getting > > a large number of warnings from groff-message due to invalid fonts for > > C and CB in the manpages that are generated from Markdown with pandoc. > > From what I understand, this is a known issue with how pandoc > > generates nroff man pages and more recent versions of groff have > > started complaining about the issue. Here is an example warning I am > > getting: > > > > groff-message troff::89: warning: cannot select font 'C' > > > > And it seems to match the issue documented here: > > > > https://github.com/jgm/pandoc/issues/9020 > > Yes. I work on groff upstream (and at rare intervals make minor > contributions to the Debian package), and you've accurately summarized > the situation. > > > My question is how to handle this. Should I just ignore it for now and > > upload anyways since it's only a warning or should I add an override > > to suppress it as it doesn't seem to be causing any breaking issues at > > the moment? Have other developers dealt with this warning before? > > Well, the version of pandoc that resolved the issue was 3.1.7, released > in August 2023.[1] But the version in Debian unstable is still 3.1.3, > and the package is team-maintained.[2] This particular bug is tracked in Debian as well: https://bugs.debian.org/1053777 > Unless it's release-critical to have these Lintian warnings, I would > disregard them in hope that the pandoc package in unstable will catch > up at some point soon. Unfortunately it is not likely that the package will be catch up soon, because the Haskell team upgrade most Haskell libraries only as a whole. That issue is not tracked in debbugs, because those vocal in the Haskell team actively discourages the use of debbugs: https://lists.debian.org/debian-haskell/2024/01/msg00012.html - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: icc-profiles_2.2_source.changes REJECTED
Quoting Jeremy Bícha (2024-01-25 22:05:27) > On Wed, Jan 24, 2024 at 9:48 PM Jonas Smedegaard wrote: > > For the record I have not heard from ftpmasters on this issues, and I > > know only what is in this public mailinglist thread. > > > > Obviously I would be happy to be able to maintain the package that I am > > listed as maintainer of. And if that for some reason is unreasonable of > > me to expect then I would appreciate an explanation why. > > I found https://bugs.debian.org/1021999 which suggests that DSA is > responsible for maintaining the version of lintian used for the upload > queue. Do you want to contact them about our request for an upgrade? I would prefer not to do it. Please go ahead if you are up for it. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: icc-profiles_2.2_source.changes REJECTED
Quoting Jeremy Bícha (2024-01-25 02:50:07) > On Fri, Mar 3, 2023 at 5:58 PM Bastien Roucariès wrote: > > Le vendredi 3 mars 2023, 22:35:24 UTC Jonas Smedegaard a écrit : > > > Quoting Bastien Roucariès (2023-03-03 22:21:49) > > > > Le lundi 27 février 2023, 12:11:27 UTC Jonas Smedegaard a écrit : > > > > Hi jonas, > > > > > > > > I have just checked the source code of lintian. Could you double check > > > > your package and create a simple test case ? > > > > > > > > According to: > > > > https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Files/NonFree.pm#L91 > > > > The test should not raise > > > > > > Sorry, I don't understand what you ask me to do. > > > > > > In case it was unclear from my previous posts: The rejection messages I > > > shared was not from a lintian check done locally by me, but a rejection > > > message I received from ftpmaster. > > > > > > Locally I did not experience the same messages. Are you asking me to > > > test again that I (again) do not experience the kind of messages that > > > ftpmasters for some reason unknown to me trigger? > > > > Yes could you double check ? > > > > If you do not experience the kind of messages with locally installed > > lintian, it means that lintian need to be backported and that ftpmaster > > should install a backport version. > > I am still getting the LIntian autoreject for thawab for > license-problem-md5sum-non-free. It is especially annoying that > current Lintian does not emit this error or even a warning because it > knows that thawab is in non-free. > > This is blocking me from being able to fix a RC bug in thawab unless I > repack the tarball which seems like a lot of work for a package that > is in non-free and a version that is **already in the archives**. > > I originally tried to fix this RC bug a year ago but my upload > was auto-rejected then and I forgot to mark this issue for followup. > It was an early enough upload that thawab could have landed in Debian > 12. > > https://alioth-lists.debian.net/pipermail/debian-islamic-maintainers/2023-January/004920.html For the record I have not heard from ftpmasters on this issues, and I know only what is in this public mailinglist thread. Obviously I would be happy to be able to maintain the package that I am listed as maintainer of. And if that for some reason is unreasonable of me to expect then I would appreciate an explanation why. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1061425: ITP: iamb -- Matrix chat client that uses Vim keybindings
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: iamb Version : 0.0.8 Upstream Contact: Ulyssa * URL : https://iamb.chat/ * License : Apache-2.0 Programming Lang: Rust Description : Matrix chat client that uses Vim keybindings iamb is a terminal-based client for Matrix for the Vim addict. You can edit messages, navigate windows and manage tabs in the same ways that your fingers are used to from your favorite text editor. This package will be maintained in the collaborative debian section of Salsa, at <https://salsa.debian.org/debian/iamb>. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWw7iUACgkQLHwxRsGg ASH50g/+NS9ZivOH2LjhBqR9wJYSBplB4WkacHYIiy6qNxz6mMD8exfAWtDSZP5V 96ABfcGuS2PIP6mTcfnA61DMep0mlbAQecZ3l2SxBEbqtpXcn8nsqRpKgg1vVWRd 3uIcd7PAnJB7+AdssOL664MoZMRAH+NchzeoGku/jOgjCI8gnaMNiR0BHA0k8McF NN437JVBTx/cJOtlkMgbJtRr8D36J9fzJIfiJo3pjU9IRlSE13/pwa7HZTpnQ+DE ckxU+Fi9xrnHFW0mc76n7nD8Wf5k4VGe/bzN6M1uodZpk0UFdCDR+F93AJTLz5y0 0VU7bkJX4cyGybOuMK6pP2x0p/05ErwtMxRcY7wYm+tqCL9T/SLuSZ3xnprwteTL kWwQrpuoD/8PXbdtte2aC7g9brK8lXeo2FUOcQ+76xvRlM0j4hq2bHMnlnI1rN1l u9fPI6HbOZ1UBmcM2BcBldOGOmzUJhjqAtCWY2Rdn2LAdcO7Ji+N7p13XKgwG6b3 cOpug96wPTUgXTFDLFn2ULrdL7sPJLcwzz0YA7BG3hubbMJv4KIuv0soC0Ih6iJ9 F5zg9OdsWkZFGYzYCXp7bEpQdRUZxj5MF69OmU7OgkU1a3KWcVQcNgBB8sgK8C77 P0RUoV3RaZaOk0thM8G3F0pi5JMwGzVV02oBRAuBfr8jUPiyq3A= =2DPA -END PGP SIGNATURE-
Re: Policy: versioning between releases
Quoting Matthias Urlichs (2024-01-21 13:35:05) > question: policy 3.5 states, rather unequivocally, > > Every package must specify the dependency information about other > packages that are required for the first to work correctly. > > Now … does that apply to crossing release boundaries? Specifically, if > foo/testing requires bar >=1.1 to work but just states "Depends: bar > >=1", and bar/stable is 1.0.42 … is that a bug? If so which severity? > > If not, shouldn't that be mentioned somewhere in Policy? Offhand I > didn't find anything that even mentions Debian suites / releases, but > admittedly I only skimmed the table of content and didn't re-read the > whole thing. It is not a bug to fail at predicting *future* breakage, which - if I understand you correctly - is what you are describing above. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Maintainers needed for debtags.debian.org
Hi Enrico (cc d-devel list), Quoting Enrico Zini (2022-10-19 15:20:43) > I would like to let go of the responsibility of maintaining > debtags.debian.org. > > Over the years I did my best to simplify the whole system, so picking up > maintenance shouldn't be too hard, if there is interest. > > I'm going to keep the service in life support until bookworm releases, > and if no other DD has picked up its maintenance by then, I'm going to > announce a plan for taking it offline. > > debtags.debian.org is a Django site. Its code is at > https://salsa.debian.org/debtags-team/debtagsd I can offer to maintain hosting and packaging of debtags code projects. Would that be helpful, or are/were you looking for new code maintainer? Sorry for not chiming in way way earlier. When you posted the above, I silently assumed that you were in need of a code maintainer, for which I consider myself a lousy fit. Only recently in another thread here on d-devel, Paul Wise made me realize that you might have interest in skills that I do feel confident in offering. I have also reached out to others who might potentially have interest and skills needed - again inspired by input from Paul Wise. If this action is too late and/or too little, then I understand, and apologize. Thanks for all your work on debtags over the years! Btw, is another communication channel perhaps more suitable than this? https://wiki.debian.org/Teams/DebTags lists a mailinglist, but that one doesn't exist, and indeed seems discontinued according to https://wiki.debian.org/Debtags Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Debtags: understanding the heuristics of "Checks and hints" in the online editor
Quoting Paul Wise (2024-01-21 06:51:08) > On Sat, 2024-01-20 at 09:40 +0100, Jonas Smedegaard wrote: > > > I am (very) willing to act as service maintainer. > > Please get in touch with the debtags team about this. > > https://wiki.debian.org/Teams/DebTags > https://salsa.debian.org/groups/debtags-team/-/group_members > > > I have interest myself in continued use of debtags, but don't have C++ > > coding skills needed to work intimately on the programming parts of the > > project. > > It does not seem to use C++, just Python/Shell/HTML/CSS/JavaScript: > > https://salsa.debian.org/debtags-team/debtagsd/-/graphs/master/charts > https://salsa.debian.org/debtags-team/debtags-vocabulary/-/graphs/master/charts > https://salsa.debian.org/debtags-team/debtags-tagdb/-/graphs/master/charts > https://salsa.debian.org/debtags-team/debtags-tools/-/graphs/master/charts Thanks - I am not comfortable with Python either, but that's certainly less scary to me. > You may be thinking of libept, which got adopted by the apt team. It was a mixture of thinking of goplay (see bug#930676) and reducing "languages I am not fluent in" to "C++". > In case you want collaborators, 5 people forked debtags git repos: > > https://salsa.debian.org/search?search=debtag > > Additionally apt-xapian-index needs a maintainer and the debtags > package needs to be updated from the debtags-tools git repository. > > Some of the debtags related wiki pages may need to be updated: > > https://wiki.debian.org/?action=fullsearch=180=debtag=Titles Thanks a lot! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Debtags: understanding the heuristics of "Checks and hints" in the online editor
Quoting Paul Wise (2024-01-20 07:32:14) > On Fri, 2024-01-19 at 18:24 +0100, André Maroneze wrote: > > > I want to use debtags metadata for a research project > > The debtags service is planned to be shutdown and the data no longer > published, as there is no-one in Debian who wants to maintain it. > > https://lists.debian.org/msgid-search/20231126160111.7nr56b7oje6uw...@enricozini.org > > > I started contributing, by adding and removing some tags using the > > online tag editor, but the "Checks and hints" part seems wrong to me > > in several cases. > > Sounds like there may be bugs that need fixing, but first there would > need to be a new maintainer who could take over the project. If you > were willing to be the primary code maintainer, perhaps you could find > some Debian member willing to be the service maintainers and review and > deploy all of the changes you could make, at least until you become a > Debian member on the basis of your debtags and other contributions. I am (very) willing to act as service maintainer. I have interest myself in continued use of debtags, but don't have C++ coding skills needed to work intimately on the programming parts of the project. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Policy: should libraries depend on services (daemons) that they can speak to?
Quoting Ansgar (2024-01-07 20:39:57) > I therefore think that libraries (be it classic C shared object > libraries or Python modules or others) should in general *not* have > Depends: or Recommends: relations on services (DBus services, DBus > itself, daemons, ...). I thought this was already in policy. If not then yes, certainly makes sense to add that! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1059914: ITP: rust-pandoc-ast -- markdown ast (de)serializer for writing Pandoc filters
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-pandoc-ast Version : 0.8.6 Upstream Contact: Oliver Scherer * URL : https://github.com/oli-obk/pandoc-ast * License : Expat Programming Lang: Rust Description : markdown ast (de)serializer for writing Pandoc filters pandoc-ast allows you to implement filters for pandoc. The easiest way is to them in conjunction with the `pandoc` crate. You can also create a binary that reads from stdin and writes to stdout, and pass that to a normal pandoc call using the --filter option. This package will be maintained in the collaborative debian section of Salsa, at <https://salsa.debian.org/debian/rust-pandoc-ast>. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWVZOkACgkQLHwxRsGg ASGrgg//Z/fjvXI78q6FYNLegruIWm5WBz4GDyEP8itiYnbK/R3bYRhT6Gp/oUQj AF2B34pEEq2PyA63w4rHLIIAfm4kWO0dJaOaiBZUTKgF8oZ9dt7RlNhM9+YjcFn2 w0TyG2zBuc0zuq1rra6zWdQcylXzarb+M2sbRuBDKVyoMzxBv7Ru1oUQ0ZKZ/Ax8 jIV/haLwzq4R44UEtTYLN/NikhMruaQjYsR/bPpNxeTUag8F6RSEYO+AAhh3eDx7 eUbRTJn8qBcjxRm4SaZxZIUlnLQcRo2pEvf8gr+J7iUnRqj4TQ47yJ7/dEmK0CZG 4iZdSKp2pDWBIOugM7ZjshEX/Irzd/alcqIFrdGoPm9ye2C/sIWoreWcsfSecwWS gLykQ8cAsbwjUSsgJekPij9ASpFHm+wGvuve98XNCZaxJ1CpsrqKym+oBKRe8Z5o CKCHQaq5Zm/n9Ceh6AY9go1dVVxQB54DXO+nFadtAHGcwtW5cEbnLE8yAv51OIAI 61H3Z0Mi7lTxePhHv6OylNbgoiEJBWKxm+E5RsEumMvm3yPk/99sK48VU4zGaq5Q i4IkXR+eLc4PYxSwktrq6BKPORtp0M8WQxyBBCuS9mUJLbh5bYrOfljjkqEZ+4dN qVixaQP79hnvRX17jyJZolI6N30/Tf5PoCBw4ww26qRnUQm8iOA= =fH2I -END PGP SIGNATURE-
Bug#1059908: ITP: rust-libp2p -- peer-to-peer networking library
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-libp2p Version : 0.53.2 Upstream Contact: Parity Technologies (UK) Ltd * URL : https://libp2p.io/ * License : Rust Programming Lang: Expat Description : peer-to-peer networking library libp2p is a modular system of protocols, specifications and libraries that enable the development of peer-to-peer network applications. There are many distributed peer-to-peer network models with different challenges and tradeoffs that try to improve on the way we network. Libp2p aims to be a modular, general-purpose toolkit for any peer-to-peer application. This package is needed transitively for safe-network (bug#1008016). It will be maintained in the collaborative debian section of Salsa, at <https://salsa.debian.org/debian/rust-libp2p>. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWVVl4ACgkQLHwxRsGg ASEI+Q//YULyfKdG7bRZG3PyVtnkJJ/LoqyJ7QacY302qjosjjEzYh3U0RfGhfOw PY3lU6q9/nlP3tPeILNXDTWriNGu7/cCo7Hbp7sWUF0XIh4cWQU7xXWDTYMVflhy hNMxj4xzwe+Rd+7FRPSbk2tS9R184jgeGpUSpRScWqSeMXGHEntZ6tdmwsO48Mvy f7HZ6t6Eilbh3oAT9jvzisxXMn/lQyq3TdX5EU61Kh0MmrGUJuCmnHZtB6JDkiO7 LvlgNYI6VxHJ/8oUCDGtvD/+NT7zrudRVwVNYUPwFc5U4obJ9EjuerLQQaK+UfnF TBSQLQTeVT4rWjnRnrN+JCa5+nowftMJsY7/uxldcu9sReZF2pI3AfyXCWCFqi0I XafWEzTs82WTUbCcuomnFgLJvBSg57c8qEvIMaS+uJ77eKTskJwvs81WSR24SHMw zy2E0X8TGafnFNCobc1NQn9yYvoCMX+DeOk0RYlRNg1kh1Odgqwz3qVe5kXj9UD2 ifTI7BZTFmOkeSXNdNlKAPtMZDbxkXVvI5SXwpFK9GrVSyGVocr7h5ka8v+tCnv+ M6Xd+VAeC0kzhuJLh+GGafhUebMuvzIFFrILKs/bhXOGKSSrOA4uCfTTjEp+DwsA O7PboXoaXR2OeiJXN5ZsZcoBR4ndvEBihcipguSKRo2MnIkRtYc= =m/WI -END PGP SIGNATURE-
Bug#1059905: ITP: rust-if-watch -- asynchronous network watcher
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-if-watch Version : 3.2.0 Upstream Contact: David Craven * URL : https://github.com/mxinden/if-watch * License : Apache-2.0 or Expat Programming Lang: Rust Description : asynchronous network watcher if-watch is a cross platform asynchronous network watcher. This package is needed transitively for safe-network (bug#1008016). It will be maintained in the collaborative debian section of Salsa, at <https://salsa.debian.org/debian/rust-if-watch>. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWVTMEACgkQLHwxRsGg ASHVZQ/+JzD0/SNMjSCkJ17DRxk4ZS9XTKZGKDEdtyq/u0MTqZBlsIcQP7XGH1ZV 3u3ErK4jYkuR6pybNnjlE0ycaaBAMuQquHMz2vYS1a9SU4p1xv5XPEWCgi0OsbZD AtPcKTdsVJa5zMYcYiR3wNM9qpWmAQSDnCdnonltqXJA16v0C+uP2+WzSTGtNPs3 EjepX8mTcvNj2iPMbkG8hu3CQP1bZuAZctZWaWLsprM/gvjzlzp9r5RzHkXw1hBy Fov8Cnxdcc5AgUhL8Br7p60xwMoF4gPfQzU/Nj1iRtmyenza20pdKL6AgT1dIlc6 okIffnJZJSMnnRPIVMP+F8WBpnKpl9K5DlpzFBExJMdsWPWDCi1NoNz2WoJOpv1N NZv4yfUj74weFbiUkHNq9ntHp9Ye5hf5+A4yoZ2qTk0+1qx6nbbQf9qSv2eZnjMM 8tfyPQjmOVcQIVEHV29+kDb/AkGGAuRk/h293XYpHQrUpZnfOXnGg+RSbGTwjZAZ UpScLJvOs2aY4wx9pZcEp9QzdYqbMSqNEhmTzA6Q7HyTr5blGka3oOVgGLrNuQP3 Ow/FMjHLQJR4jNtY88Z6mnT2IDrBAl6CbMhc49ACGUCMlYL1Hj2CjxibGvi792XM 42wgR718z+YtnepArVODb9XgntOvJzTkn1WvU/g0l4yeoDtNem0= =x07f -END PGP SIGNATURE-
Bug#1059665: ITP: pandoc-filter-diagram -- Pandoc filter to render diagrams in Markdown code sections as SVG
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: pandoc-filter-diagram Version : 0.2.1 Upstream Contact: Lars Wirzenius, Daniel Silverstone, pep.foundation * URL : https://gitlab.com/larswirzenius/pandoc-filter-diagram/ * License : MIT-0 Programming Lang: Rust Description : Pandoc filter to render diagrams in Markdown code sections as SVG pandoc-filter-diagram is a Pandoc filter to render as SVG diagrams in various markup languages, embedded in Markdown as fenced code blocks that are marked with the appropriate class. . Diagram languages supported: * pikchr * Graphviz dot * PlantUML * roadmap * raw SVG This package will be maintained in the collaborative debian section of salsa, at https://salsa.debian.org/debian/pandoc-filter-diagram -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWPNysACgkQLHwxRsGg ASEXsA//dXE3GTmjI6IfOEJWjGp9NvyGGCHLZdr4mXQW4TW+C+bB8tOcTmVmYd92 7CH31/TpYQY7PIFW4J90kTt+qpKLthkbU5BIB07ZkKYHcLYrrxvIbDEPXT3P/Qib 5WILCOtliDPFEJCoJbHK2etdKHyEUQu3hJ15AU3JrU07qCgZsuCZ5xNEuQdehzbi HKa96JWkKxKmxor1oBrZoci4Lc9RAqOSAZANkmJEZLUiUKtc+aDBRCANkrgDiSqL RFz9ORIBFGU/kLDDA28LUxcOpndkse+8+ts9bSRfkkQdBN/UlcXSfPstQiUyRFZs ZDCuUveqaMVg1WwfA5K0d1gq3yxrRFLg40n4dnEsWUgBu4NEXXy0+8QpL9BizeNh 6oXLl5qudV8O0krWGOnncscm4Lx3i2irMAoB0Dsbz5O8OqHLIX51LjhuankG2kEH /Rbk2l3nxBC480dUF3MM/hducbXfVJghIydRJRk7r+di4nO1P8Xo6icfgMGmS6B7 /s3H5w+JKkDFvaYNs1Kb5NbzltjI2YuqlAkAdBiz0h+YUTJbo4lb8Oy8UX81Q7mh /8U3JJWMtS6fJznd69iyJRnEYeI9L6IGcauGGmlKA7Z5Tlaz7ppoHPk0eKhONaGN FZGYJCmCNl+m9KtM8J4RpUYWrEhV8q6mt9FTz601hpsnT3Qi8Cc= =mwVh -END PGP SIGNATURE-
Bug#1059655: ITP: rust-roadmap -- model a project roadmap as a directed acyclic graph
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-roadmap Version : 0.5.0 Upstream Contact: Lars Wirzenius * URL : https://gitlab.com/larswirzenius/roadmap * License : MIT-0 Programming Lang: Rust Description : graph-based project roadmap modeling project generates directed acyclic graph representations of a project roadmap. The idea is to show the steps needed to reach a goal, and the order they need to be taken, but ignore due dates and other irrelevant details. This package will be maintained in the collaborative debian section of salsa, at https://salsa.debian.org/debian/rust-project -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWPLrAACgkQLHwxRsGg ASGKfg/+Jtgx6/Vl1kBctGxoeCa4b3wbX7JslUp30ADFAsv+dEyJsV3fsLZsebvW U8+IPxxKzOFr501D65JyF8o3CqeNA3H3MeEBc/ObfgYGgFBZLPOTtCT7lGrjMVwC d3g/bBH9eFO6++LMIekackImFeVnHM9xlbpWu3zxugQHUwEfg7u8r56qOXppjR// 7WrnC7W3Lsh+4sDthCQEuciY6T/yczPdIeDnwwLvNqajT4GhPRgEZ2wHGhopSwU3 9/2+jvKgDnPVeEgAw1fiTOQw33UyQToBU9KnsbR5m/H46pJ4FAafTdAotenrOjNN 3P5NiYssPMkqpDkr6ztPSJCwf6nTc1bSvSp3PaxPKYT/BwL4d96G0G2zS5EoNV51 87vrU2ob9ajaikqjtoMkJzhEnY0q0g8BacTf3UnLT10AwGBqYViGLBEBvlOrvQvF vOas/CL8zaf8G5Ud3YZZ0DO0H8kQZpC8+2MmTeZBsPFDqEmaCdZccQ0ll4iyv4Vx wTwu9n0PgWo6WUwm9GEcp9HRHV8yRRyyE2kJeuORbuspW5mt5KB2gJVkZT9NsmKC QHIwWEsbdHeOGeY4k99WcoEszkRTXtIsOqVT/arRuM6qp/NLvDNa/wGlMdDBzgL0 44xXzfvKQIljYEHutDidyUykafUTNVJS16T6d5T7Cgd6K9boTGY= =PpF5 -END PGP SIGNATURE-
Bug#1059521: ITP: rust-pikchr -- PIC-like diagramming language to SVG converter
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-pikchr Version : 0.1.3 Upstream Contact: Daniel Silverstone * URL : https://github.com/kinnison/pikchr * License : Apache-2.0 or Expat Programming Lang: Rust and C Description : PIC-like diagramming language to SVG converter Pikchr (pronounced "picture") is a PIC-like markup language for diagrams in technical documentation. Pikchr is designed to be embedded in fenced code blocks of Markdown or similar mechanisms of other documentation markup languages. This package will be maintained in the collaborative debian section of Salsa, at https://salsa.debian.org/debian/rust-pikchr -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWMK6cACgkQLHwxRsGg ASFeBA//bcFWS7kwUJXjVM6FgPmF6PCAFwFp+S03F2zH/b/GuynbvG1hyptVsV1e DokQYTG9jMPTrEy0UVw2popVegodkVHzPAXQZdy1TRR3r3wvpO0ezhikcTwbobpX lXMN0tAbfOTFdTQYi3aqYsmJA+9yCX6KmM2RSLdeR89javonW05T9SfzQSEUtKeX vDLtBA9JyICe/ox8Ymq/S7Zj6m8hoEK81ZsrBu2+x7O7lnI3g9X7/le7JxN2SyAr njunNioSq8bEHmGD8pMNbGadei+N2Eq8AyxinsZTbGF3Goc6eaz1ePfiNHeBST4v /hDfgc5n+xXegZfxfuR/q8e2jHd52RyVC0bsEOZ13W8eSMhCCyhF3AuTBI/3YUWW yoXyrBez3d+Wf/G3FU5kXCfPTF5pmoCKVq7dr90nWsyFp4zH5HlFHyOVAw31oef1 oxZu+81AS9ch6NtKJycxyQE3+ZiFiJ8dcALcZWAM1noMV5pYEeN1ciJFnAmMlCeB UfcFhdJYJI+/82+fWkBQMwPYkSPn1bhNX7aAabGs++CJkBcU9AeNQ/nv7AJ4xrCE nWiC1tWAmOmzTmEC5CJZzrkm3u5+4Syjp4Q5FwivEzRq6X9DpuXs4xOgCizfYz1o Zuy/0pKdDR5p4MhHFVtm3ahIIwQmdmhxXEFesMJUZQse+S3MjaM= =9MTY -END PGP SIGNATURE-
Bug#1057068: ITP: rust-bounded-static -- ToBoundedStatic and IntoBoundedStatic traits
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-bounded-static Version : 0.7.0 Upstream Contact: FujiApple * URL : https://github.com/fujiapple852/bounded-static * License : Apache-2.0 Programming Lang: Rust Description : ToBoundedStatic and IntoBoundedStatic traits The bounded-static crate defines the ToBoundedStatic and IntoBoundedStatic traits, the ToStatic macro and provides implementations for common types. This crate has zero-dependencies, is no_std friendly and forbids unsafe code. This package is needed for rust-imap-codec (bug#1057065). It will be maintained in the collaborative section of salsa, at https://salsa.debian.org/debian/rust-bounded-static -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVmu5MACgkQLHwxRsGg ASEa7g//SbnWe8bEjVMRt4b8IKNiU6bcgTrUVd9zeXajrOON3b5JKlZm1VOFfZXO TiNFFsMI/zxWxGE4dIkKf+96XqLlwOGaLtNWd0Z6CpQpJq0PSzGnOHrHFus9tE/A 52KxS7SU+0n7ZXACM/zp+dpjRC+ajxhvZwWNHb+IDlW4XXBHf/gsDVm7MZkxdulW GcRB7rqKntoS/Bbn3YY8VCsUjzpJXc95sq4au0xLy+tYHMaZqQfHPbP984kYdLZD iQ2OOmQ2FyQu/OOFobN3j6f2h3V8d2LYN9ncbr7eKTOD7T0MwOqHHEffEeXWC22A 8AnQRPJidS8x0qMnkkxQI6zA3yPWWFAimSWPuZzzveWrgWxZYVU4bfGni5mr1Jnm 7FQbjA1RWW9xR7xeZoG1tOUVdYi94HSyvpgGw7x+TOsVEwZdK3lEaa0jizf0LvXe qmeX2hLqXqo8EmAygqeMRJWd1XnkpgkKPNsNIrEjzKU4XzzbW899F1RbSqJiNT5y UCY3qTezs+9dOhia3Q1vxgNuKPsDJZJyLoWhNa2Mw/KpXy59n1cR2CYFcI3as102 TtDB0C7acYpbMIm2fjzrMk1KFHvSspD3mC6UGel7O9AK62nxuSN6hEpcwWJdn3d/ 4WjBpJlruTHRZkb13sni7HXWMfpmMOwj9OX9k9VfpCQ605Gv56k= =viSa -END PGP SIGNATURE-
Bug#1057066: ITP: rust-abnf-core -- nom-based parser for ABNF core rules
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-abnf-core Version : 0.6.0 Upstream Contact: Damian Poddebniak * URL : https://github.com/duesee/imap-codec * License : Apache-2.0 or Expat Programming Lang: Rust Description : nom-based parser for ABNF core rules The abnf-core crate is a parser for ABNF core rules based on nom 7. It is primarily a building block for the ABNF parsing crate, but should also be useful in itself. This package is needed for rust-imap-codec (bug#1057065). It will be maintained in the collaborative section of salsa, at https://salsa.debian.org/debian/rust-abnf-core -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVmtVwACgkQLHwxRsGg ASGS1A/8DG0E01SiEQDr74R2CR34gcFbMqZKoFdui76YC5XkfgF7/MtcLNbP8XqD AbOgtb+eOW1Uqgj12qzmmdadiU+bTYsp7+bm3jcNLOt2ziDf4J30iew5kaNhU+WM 23HAkpulF9RKyeVb42sdkyjkcdGKbMKax61sIOrQUK+C1fBb6dkPHyGYJx4UlQb5 d7Po+iS1875vwR5iuXaCwUG515KT1VigFrzk70TYD1Xz4jE0QX6J//F7Q7YqqoeM Q3fPKJ3vsmLqOy0aXqcqz/V3FSIyOxj6sUzSo8qMlMlBWBbU8InXy/gMKm9+FFMj rWSC3iwRfwuNyxQOFQLgwoDxE9TAgfZbFq37Xq7mGMt3evdvDBm+S0JJ+E7KOgik natMzCH2jpjkSVnx+lLNeOJVFbOYbSwg7Vy9en4lYu+bMYLNL0/0NpYSZc9SJBOy hxfRpYxRLbfWZ72Ua47Ilqf3XSypWaADTpZ03cm6GDX2Fn89UKeZaB4FdRS+IXtV yxxaOoage51dLQXT66tUrOszD0SH2mFDiq7naSiG+9XIkhLBmMiXDeGBe352MhIh pPGxdeMjfvCEcNqo/W7ovuR4WVuLTBTJQw8gZUUQAHbB21u9l2ytPhz+S1VWEarU VrhV7BOez2cN0+VweNUeFyoEFZzqlRKiWudUaaqLORmmg8NKJZg= =bBMd -END PGP SIGNATURE-
Bug#1057065: ITP: rust-imap-types -- misuse-resistant data structures for IMAP
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-imap-types Version : 1.0.0 Upstream Contact: Damian Poddebniak * URL : https://github.com/duesee/imap-codec * License : Apache-2.0 or Expat Programming Lang: Rust Description : misuse-resistant data structures for IMAP The imap-types crate provides a complete set of well-designed, misuse-resistant types for the IMAP4rev1 protocol and various extensions. Notably, it does *not* provide parsers, nor serializers, but tries to become the "standard library" for IMAP in Rust that is useful for a broad range of crates. This package is needed for meli (bug#1001084). It will be maintained in the collaborative Debian section of salsa, at https://salsa.debian.org/debian/rust-imap-codec -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVmr6IACgkQLHwxRsGg ASF97A//RItyoOZSJWXdVCjyzvEfyEzueEh3WhvwtOuT0D95h5ffKbl3apSJf1nx G3uKqiebn0k8cxkUeQQ33t1aTSGGr6jC7p3uXbpDHbUsN/sVzoEk5i6N2O0lv3dg 1TG5jUpW6DTudGKbrE0/UHkIkM9Zf9G70ge6a3Ov4i4Dch2lvitnpJ4Nz7wd3M9T df2ixE+RreMzJPBMYJKSHDkzl9GDaPcTor5RTHbPnU3WesUyZw/sscGoA2iVQpsI jCYuYJDXF8rDSoYYjjDn0nJBT+poq6Jw6wSiOjcbyTPqCNo+S4miHIazJzMzBiZ2 PpbzPyIZN2mMJOMXhgSCcyjoyrQZFWgDg2e9ag8kKOU5Y9I4OBj7gsakx/bzxeSw UeD1wnj6yI/9kzmBkc8opXrwLtYOGyntXW3En8UwQUiMPWIPfuSAQpZL+Y60AmTu h5TYh91ZMIDcRtmjqzwaigl6kyDZNL9J+5+lw4ZnEySUJvwPYoc6YsYole7Lexto zCWvBbXbKdqbtAyKVFsvj3d+hBU967EwYC0xAhmqyNpxNHVvn8gb/ffuFe9qwrWk hX7iAs8sU7YeLEQkP5lrQY55tNj3U/7yMJDd9ce/keueoR5kW/e30zPi9EhUWXHb 2e/1/NREk8wXejGsb7O3gS1H10gi5jAAGvjkpF6fLehAd2GS5f4= =a5C7 -END PGP SIGNATURE-
Bug#1057063: ITP: rust-strfmt -- rust library for formatting dynamic strings
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-strfmt Version : 0.2.4 Upstream Contact: Garrett Berg * URL : https://github.com/vitiral/strfmt * License : Expat Programming Lang: Rust Description : rust library for formatting dynamic strings strfmt is a rust library for formatting dynamic strings. It is a library is for rust developers who want to bring rust-like formatting to non-static strings. This package is needed for recent releases for btm. It will be maintained in the Debian section of salsa, at https://salsa.debian.org/debian/rust-strfmt -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVmnuQACgkQLHwxRsGg ASHvbw//cezjOWl7N/r18kJSC+zX+BwhpOOQZQFj6cUWDF12nbTK2trTlkgmnlRv tvdDO6yH0v+CQOIBsrqvIvM9oifYTl8eFHsuAC7KEIWHJ4ri+H5pduCosclIHO+4 m53/6QS40TLemWB3rissmL4QO2Bv5U5BzgcULk0TJ6CnMy50YaP5WOfhaL5/oPcC vLWHA9vfvgydQkTcXsUuqRXEzbLcowvLA6T+wg6knpudPn/D5In9xuvNmK1UCUN6 okpc5npyCbv89qpQywZQRNandB7U3+6ZJbHQH4bEEpAq8FD6QzUNK1vOun/jioqU 1zM/clDR6wbq2ikGkkRrRwxHjmzhAEviCWaOhnValta2f1IUh0zDNhtEUbDFd6B3 fNQAutAwMt24xSU8o/z9Nch3Yopp2skeq1JPhTFav1/ERZjdZavBRq7fXiHkrfDQ ECRdTVv4QGXmN5byyxUvuANdkc1RrOKU7GMFpyjWdwObkb5t6Ny0Pi+VVgFeMYRb C2fg9lf5xwuDWCwu3AYesb1bPBnIXlodWKRJrADSifVnNLoZh3fyDie1D4gbhmOD U/hGuSkx6dqh2gp2wWfm5IP/fVC9KoGLCVFY8NZ+iuAq+mZA2IFc/aN0DPRwgEjJ I2RzvE7yxwp5FKzPcCUUMIr92wcpeqBjllZ7GWfPw+HBqNIX6jY= =wN7u -END PGP SIGNATURE-
Re: Sunsetting Debtags
Quoting Enrico Zini (2023-11-26 17:01:11) > about a year ago I announced the intention of letting go of Debtags[1]. > > No successor has happened to carry over maintenance since then, so it's > time to follow my own advice[2] and properly let go. Thanks a lot for all the work poured into debtags, by you, Enrico and by everyone else contributing to that project. It remember the [DC5 talk] (and just now revisite the [video]), and I recall my excitement when later same year it aptitude 0.4.0 gained support for tag-based browsing and querying, and some years later playing with [goplay]. Amazing work! - Jonas [DC5 talk]: https://debconf5.debconf.org/comas/general/proposals/54.html [video]: https://meetings-archive.debian.net/pub/debian-meetings/2005/debconf5/mpeg/2005-07-10/06-Debtags-Enrico_Zini.mpeg [goplay]: https://tracker.debian.org/pkg/goplay -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1054312: ITP: btm -- customizable graphical process/system monitor for the terminal
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: btm Version : 0.9.6 Upstream Contact: Clement Tsang * URL : https://clementtsang.github.io/bottom * License : Expat Programming Lang: Rust Description : customizable graphical process/system monitor for the terminal bottom (executable name btm) is a customizable graphical process/system monitor for the terminal, inspired by gtop, gotop, and htop. . By default, bottom is somewhat like a dashboard - a bunch of different widgets, all showing different things, and they all cram together to fit into one terminal. This package will be maintained in the collaborative Debian section of salsa, at https://salsa.debian.org/debian/btm -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmUz404ACgkQLHwxRsGg ASGECA/+L3SdKQ0JgQZbhk4Z+NuDBcMasT4ssOcZIhpBjHi86dGZv6ZA8ky+bme/ sp6wd0YaKwWtCQVIiOto5nNdf4Gsg4CcLrzKvenHGfAlVPhzY3JYWa1ztJF6XLq+ DuEpPMuSJefc1h/A5lmA/N+cufZVkbaR8VpVKJzoIP9ACsGfHpz7FFuvMe1/NfHD DsExapPVSwFWxSv2y9t+RSmpeMZZLEx2bP3SH2AvpwDV1tm3zj+LtasIKtxIEllf 0590cxm+NPRLnjYyr2r3HOwqsfte9sfmPVo69r+aTDpJyiJp3zrx6F6KiTiW2RUg 9J4OsobfdI+udlXjjGUoA+3apDqbXdcG88kwHNvTXtslNvRweIvvKBPNYapc9R+E GfAF2XYBrqLLKz9jbuJJPyQu1j+EKAPwPxDZLUmMIYGJwNDE6i33VfhJe0tfCu04 Sb8aOQrfqRLPPmtVlyFTT2GpVEUXfufr3YoRhiyyIdYbtKii63XmR4+XE7vVmeqM QGH+kR3pZKat9UC4IKMeGzSk5kv6BbwQeD5gwxsFO/ozu7cfsDGQGmiWUnajWcle 8uBotzLjLjX4+mlGkrRbNwK/h7/gQgVkEmrF99J42RZt6c774mdwZl3SH8fwu5T9 mWRq68bZZX69uuWMDRxJPBDs5bgd0Cw0aZVkrW2ct5oSj5ogPNI= =B2Kv -END PGP SIGNATURE-
Bug#1054206: ITP: lsprotocol -- Python implementation of the Language Server Protocol types
Quoting Arto Jantunen (2023-10-19 07:48:40) > * Package name: lsprotocol Do the project really need to occupy the global namespace "lsprotocol" within Debian? If The project does not provide an executable /usr/bin/lsprotocol (which is generally usable, not just a narrow tool more appropriately provided in Debian as an example file), or in other ways make use the name "lsprotocol" in a system-wide namespace, then please rename the project as packaged in Debian - i.e. not only binary packages but also source package, to include a suitable prefix or suffix. Concretely, please consider renaming this packaging project as python-lsprotocol. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Pllllease use experimental for potentially breaking changes
You did it again, Rust team: Broke a pile of packages when bumping a library, most likely (again) due to some of its dependencies not yet being quite ready. This time it was rust-regex-syntax. Please, pretty please with a cherry on top, do *NOT* release potentially breaking changes directly to unstable, but use experimental. I have mentioned this several times in bugreports before, without you commenting on it. This time sharing with the wider Debian community, in case others than me can better help nudge you. Kind regards, and with all the best of intentions, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: allow missing description fields and empty long descriptions for Rust/etc packages?
Quoting Paul Wise (2023-09-20 04:10:58) > I have noticed that almost all Rust packages in Debian have boilerplate > long descriptions that aren't very useful to Debian users. The only > useful info is the crate name, but that is also in the package name. > > As far as I know they inherit this property from the upstream Rust > crates, which only have a synopsis or even no description at all. Not quite true: Upstream Rust crates have no long description as part of the crate manifest (i.e. in the Cargo.toml file), but such info is commonly found upstream embedded in the main library file (i.e. near the opp of src/lib.rs file) which is liftet out as part of upstream documentation generation. This is somewhat similar to how perl CPAN modules include POD documentation - with the difference that upstream perl packaging tools commonly lift out the embedded "long description" text and includes it in an autogenerated README file (whereas upstream rust distributes that documentation on a separate website. > Having the Rust team and other folks add non-upstream descriptions for > crates seems like not very useful work, since the Rust packages are > basically only used as build-deps and therefore have no human users. > > So I would like to suggest Debian relax our requirements around binary > package descriptions, especially for Rust binary packages. > > Does anyone object to this change? > > Are apt/dpkg or the repo creation tools likely to need fixing? > > Are there any other places that would need changes? (eg DDTP) > > Are there any other ecosystems that this could apply to? I find it useful to be able to read changelogs for Debian packages offline, not only for packages containing user-facing ABIs. Similarly I find it useful to search for relevant packages e.g. with axi-cache search or apt-cache search, again not only for packages containing user-facing ABIs. I would find it sad if Debian "optimized" away this ability. Personally I have not found it a too burdening work to grab documentation from upstream unstructured sources, and occationally update that information if it later changes. - Jonas > -- > bye, > pabs > > https://wiki.debian.org/PaulWise -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1052276: ITP: jbig2enc -- encoder for JBIG2
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: jbig2enc Version : 0.29 Upstream Contact: https://github.com/agl/jbig2enc/issues * URL : https://github.com/agl/jbig2enc * License : Apache-2.0 Programming Lang: C++ Description : encoder for JBIG2 jbig2enc is an encoder for JBIG2. . JBIG2 encodes bi-level (1 bpp) images using a number of clever tricks to get better compression than G4. This encoder can: * Generate JBIG2 files, or fragments for embedding in PDFs * Generic region encoding * Perform symbol extraction, classification and text region coding * Perform refinement coding and, * Compress multipage documents This package is optionally used by ocrmypdf. It will be maintained in the collaborative debian section of Salsa, at <https://salsa.debian.org/debian/jbig2enc>. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmUJ6jkACgkQLHwxRsGg ASGyLw/9GCokfYiMAMMLLRZLA+auOpPNSPOWOATunsucWm1S9Z3Bbai0ELzaTyUM E0lIf4KT+TjTMEk0aFgKMpQ6EbcGUPpjn3Rq/Zv/UuC+WZCPcWH7S9THuJ6K8HjJ JamsKksLQ9F0atN48d/9iI57cOt96DL3je0Gcy5gj9ZaV3FpNRR3SahcL3w9Vy+M W52R/JuWrHf8jRXwIXXltPvSQ5UmO22pVLvvN6RpB3n+k4SU4IhUHq8yj7DFlJ27 GIKBLJluWq0ZWJlBQVzwptQNMTSurdy4NuM3mzTOXjPNPw3LCMg5WzX3WDZCotTD en4+qYj3oTiKrDL8ZBKAQzTtVxQupXlr0d0JYMGkzFCAAvCtBZDWR5lXYRcUWYKh rlXtzReC7cecgeUh6YI/B0e+D4uW0mKzuwNMxu1E3Ol9vXYIQRS+4MEohRN602RF qf6ertUoweMBKVf/8dQjCU+wsFjS1YU2X3JtDqU6b2mFTwdSSvylABLJyIAyvtYT hUOEoXad1tfZtJM8LNasVYRHZpg675BKkdypS+asfj03xLT+HbJNCmxnzLTIkJZ+ avWqWHD8+nxwlv9pXKq9HEQx19/uD+FM+sEeyWuLX3oGDUO9RDIelVk6eQpxNSBm ZRdAHgHaMK3/obUplNXzt9ohw5T5slv5SKUKZir68O3a6yecX5M= =lc09 -END PGP SIGNATURE-
Bug#1052045: ITP: rust-ed25519-dalek -- fast and efficient ed25519 EdDSA key handling
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-ed25519-dalek Version : 2.0.0 Upstream Contact: isis agora lovecruft * URL : https://github.com/dalek-cryptography/curve25519-dalek * License : BSD-3-clause Programming Lang: Rust Description : fast and efficient ed25519 EdDSA key handling ed25519-dalek is a fast and efficient Rust implementation of ed25519 key generation, signing, and verification. . Edwards-curve Digital Signature Algorithm (EdDSA) is a digital signature scheme using the elliptic curve Curve25519. This package will be maintained in the collaborative debian section of Salsa, at <https://salsa.debian.org/debian/curve25519-dalek>. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmUFtw0ACgkQLHwxRsGg ASEMeA//V6RHC+y4TRyY4rUBxyRY0IXq7kj7FQhvOIt/jSrOx6Vc5yKFimb5Zd9n QpJ98CQxuIpx+EGA5bX54iiQBrDzU/1gwJ1NS3KsugwN2/xzh67s3kbNgxMGDewl JUntRsg1SI2en5P+ZqlQjtmlbqQuB7+9rVUsb6LSGxsnK842c3/0Y7tdNNomrNkH TIUrhW0PKRdGjX3QtELsQlySotdUNp5i36UhRPOOz06ltTPWu9f23w8f5hfILd0Q va2Rx76t7JpMafgL4MRoRr70HiiiPm5HGdLUk+pCrzUNLsv4kWKAOAFkC+dtda31 2wboqzReGhpu0eagZkxZtqRPpeGv4/0YWlwJwb1Xr5H/yMcIfa6OGTUDppCELk2a HCdCb06MljwC9NK6wnyMg3gPhgL8JcYjeRwP8gymevOg4X5joE9l5NXFRaxGOBo/ JT7V9PlzR5lHajVYvX/B9lbqAwxhtXTgD4ntBZWZWNOzjSWUHPnLvG8FNRQaZYAs cDsxQ8n8VYQlKbSEhNc8NXmbqhTX7DmvNNgitSM77su8dL5dIZ91r3kvxlTtquuy MENFshzg5PSYjul0WP1PjI0nYnsx2EJf7HzHINiSkIZ+Oayx16KcMu59OFemuJm4 Pb/11kljMaI9ELf5MfZOXIFhnbM/rS077bC7QpxfTXlzZgfToP8= =u5Ku -END PGP SIGNATURE-
Re: Default font: Transition from DejaVu to Noto
Quoting Gunnar Hjalmarsson (2023-09-13 21:28:00) > Hi Fabian, > > On 2023-09-12 08:24, Fabian Greffrath wrote: > > as has already been stated elsewhere, fontconfig upstream's move to > > Noto as the default font has most probably not been done for > > aesthetical reasons. That is, it is not the "most beautiful font" > > that people "like better" then DejaVu, but the single usable fallback > > font with the widest glyph coverage. > > That might be true. > > > However, I think that the acceptance - or rather lack thereof - of > > the Noto fonts in Debian has indeed to do with the way they are > > currently packaged. There is no pendant to the fonts-dejavu-core > > package which only installs the generic serif and sans-serif flavors. > > Instead, even the fonts-noto-core package installs a full pack of 268 > > (!) font files. This is discussed in detail in #983291 [1]. > > The way they are packaged is absolutely a restriction. How important > restriction it is depends on what you want to achieve. > > If I recall it correctly, the primary suggestion in that bug report is > to split fonts-noto-core into an LCG and an "other" package. Perhaps the primary suggestion, but not the expected future: I maintain the package fonts-noto, and what you refer to is the opinion of Fabian, who disagrees with my views on how to maintain that package. Also, the referenced bugreport is about pain of selecting fonts, and that issue is better addressed in font pickers than by avoiding to install fonts. Notably, the very purpose of the Noto font is to achieve "no tofu" so it is counter to the purpose of that font to omit installing some of its families. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Default font: Transition from DejaVu to Noto
Quoting Gunnar Hjalmarsson (2023-09-13 21:09:00) > Should fonts-noto-core be installed by default? > --- > Personally I think it should. The primary reason is that fonts-noto-core > offers a broad coverage of Unicode characters, and the quality is in > many cases superior to the free alternatives. Ask for instance an Arabic > or Sinhala speaking user. > > To really make use of a Noto font, the font configuration may need to be > tweaked. But having it installed is the basic prerequisite, and I think > it makes sense that Debian as an internationally spread OS provides > fonts of good quality for most languages. > > There is a problem with fonts-noto-core, though, as several people have > mentioned already: For non-LCG scripts it provides one font per script. > And there are quite a few of those. So for a user, who wants to actively > and often select font in a font picker, the list of font options gets > horribly long. > > Personally I see that as a shortcoming in the font pickers. They ought > to offer some "favorites" functionality, in the same manner as it works > with keyboard layouts. Unfortunately they don't, at least as far as I know. Perhaps it is then immature to switch to using fonts-noto by default, for the above reason alone (but see also further comments below). > So we have a conflict of goals here. The good news is that a user who > speaks some latin language, and who thinks it's important to be able to > easily select font directly in various applications, can do: > > apt purge fonts-noto-core Just as easily as those disliking a font can remove it, those appreciating a font can install it. Difference is if we want to bloat all systems by default or not. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Default font: Transition from DejaVu to Noto
Quoting Bobby de Vos (2023-09-13 18:47:22)
> On 2023-09-12 03:09, Jonas Smedegaard wrote:
> > Quoting Gioele Barabucci (2023-09-12 09:19:26)
> >> On 12/09/23 08:24, Fabian Greffrath wrote:
> >>> Instead, even
> >>> the fonts-noto-core package installs a full pack of 268 (!) font files.
> >>> This is discussed in detail in #983291 [1].
> >>
> >> The issues is not that there are too many files, but that these files
> >> become extra entries in font pickers (1 entry for every ~3 files).
> >>
> >> Why not collapse all these font files into a few new font files using
> >> fontforge or a variant of nototools's merge_fonts.py?
> >>
> >> For example Noto Serif {Ahom, Bengali, Devanagari, Malayalam, Tamil,
> >> Thai, …} could be merged into "Noto Serif Asia". Then, Noto * {Africa,
> >> America, Asia, Europe, Oceania, Symbols} could be shipped in the
> >> fonts-noto-aggregated package and their entries added to Debian's
> >> fontconfig as default fallbacks. This would greatly alleviate the
> >> problem of having too many entries in the font pickers, yet provide the
> >> same coverage of fonts-noto-core.
> >
> > Please discuss that proposal with the Noto project upstream, not here.
> >
> > My understanding (and I believe documented somewhere too, e.g. in the
> > Noto CJK subproject which is the most extreme in amount of glyphs) is
> > that it is technically impossible to join all glyphs due to limitations
> > of the font formats.
>
> Indeed, font have a 64K limit on the number of glyphs. There is a
> proposal[1] to increase this limit, and it is being discussed [2].
>
> Merging some (so not all, so the 64K limit is not reached) of the Noto
> fonts together might work. In addition to merging the sets of glyphs,
> you would also need to merge the OpenType layout data in the GSUB and
> GPOS tables.
>
> And the tool[3] from Google looks like it might handle the GSUB/GPOS
> merging.
>
> Different fonts (say for Devanagari and Arabic) might have different
> line spacing, a merged font would have to choose which line spacing to
> use. As a result, the line spacing in the font might be too loose, or it
> might be too tight, resulting in clipping and/or inter-line clashes
> depending on which script was being displayed. The source for the tool
> mentions this line spacing issue.
>
> And yes, Noto provides separate fonts for (in this example) Arabic and
> Devanaragi) even though the top of the Noto website[4] says "Noto: A
> typeface for the world" (sort of implying one font) but further down the
> page it says "Noto is a collection of high-quality fonts" (plural)
>
> I am curious about the comment above "1 entry for every ~3 files" In
> LibreOffice Writer (7.5.6) on my Ubuntu (22.04) system at least,
> installing a variable font results in fewer lines in a font picker that
> installing a bunch of static fonts.
Thanks for those details, Bobby.
Let me however reiterate my main point of previous post, which still
stands:
Please discuss that proposal with the Noto project upstream, not here.
Kind regards,
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Re: Bug#885698: What licenses should be included in /usr/share/common-licenses?
Quoting Russ Allbery (2023-09-12 18:15:27) > Jonas Smedegaard writes: > > > If you mean to say that ambiguous MIT declarations exist in > > debian/copyright files written using the machine-readable format, then > > please point to an example, as I cannot imagine how that would look. > > I can see it: people use License: Expat but then include some license that > is essentially, but not precisely, the same as Expat. If we then tell > people that they can omit the text of the license and we'll fill it in > automatically, they'll remove the actual text and we'll fill it in with > the wrong thing. > > This is just a bug in handling the debian/copyright file, though. If we > take this approach, we'll need to be very explicit that you can only use > whatever triggers the automatic inclusion of the license text if your > license text is word-for-word identical. Otherwise, you'll need to cut > and paste it into the file as always. Ah, right. I see it now. Strictly speaking it is not (as I was more narrowly focusing on) that the current debian/copyright spec leaves room for *ambiguity*, but instead that there is a real risk of making mistakes when replacing with centrally defined ones (e.g. redefining a local "Expat" from locally meaning "MIT-ish legalese as stated in this project" to falsely mean "the MIT-ish legalese that SPDX labels MIT"). If you disagree, then please shout, as then I am still missing your point here... - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Default font: Transition from DejaVu to Noto
Quoting Gioele Barabucci (2023-09-12 09:19:26)
> On 12/09/23 08:24, Fabian Greffrath wrote:
> > Instead, even
> > the fonts-noto-core package installs a full pack of 268 (!) font files.
> > This is discussed in detail in #983291 [1].
>
> The issues is not that there are too many files, but that these files
> become extra entries in font pickers (1 entry for every ~3 files).
>
> Why not collapse all these font files into a few new font files using
> fontforge or a variant of nototools's merge_fonts.py?
>
> For example Noto Serif {Ahom, Bengali, Devanagari, Malayalam, Tamil,
> Thai, …} could be merged into "Noto Serif Asia". Then, Noto * {Africa,
> America, Asia, Europe, Oceania, Symbols} could be shipped in the
> fonts-noto-aggregated package and their entries added to Debian's
> fontconfig as default fallbacks. This would greatly alleviate the
> problem of having too many entries in the font pickers, yet provide the
> same coverage of fonts-noto-core.
Please discuss that proposal with the Noto project upstream, not here.
My understanding (and I believe documented somewhere too, e.g. in the
Noto CJK subproject which is the most extreme in amount of glyphs) is
that it is technically impossible to join all glyphs due to limitations
of the font formats.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones
[x] quote me freely [ ] ask before reusing [ ] keep private
Re: Bug#885698: What licenses should be included in /usr/share/common-licenses?
Quoting Hideki Yamane (2023-09-12 09:27:12) > On Sun, 10 Sep 2023 18:29:36 +0200 > Bill Allombert wrote: > > Or we could generate DEBIAN/copyright from debian/copyright using data in > > license-common-list at build time. So maintainers would not need to manage > > the copying > > themselves. > > One problem is, that some software declares that they use some licenses > (e.g. MIT), but sometimes they modify the license term itself a bit. > So, there's a difference between words in the license list and some words > in the included license in such software. > > It'd be better to find such software and ask upstream to fix it to use > proper license terms, by tagging it at BTS. And, it's NOT Debian specific > issues, so it may be better to ask folks to join such a movement then, IMHO. I can only assume that the proposal for an automated DEBIAN/copyright file is limited to source files *possible* to automatically process, and consequently only relates to debian/copyright files written in the machine-readable format. The problem you describe about ambiguous MIT-derived licensing cannot, in by understanding, occur using the machine-readable format - only with less strictly structured debian/copyright files. If you mean to say that ambiguous MIT declarations exist in debian/copyright files written using the machine-readable format, then please point to an example, as I cannot imagine how that would look. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private
Re: Bug#885698: What licenses should be included in /usr/share/common-licenses?
Quoting Russ Allbery (2023-09-10 23:24:24) > Jonas Smedegaard writes: > > > I have so far worked the most on identifying and grouping source data, > > putting only little attention (yet - but do dream big...) towards > > parsing and processing debian/copyright files e.g. to compare and assess > > how well aligned the file is with the content it is supposed to cover. > > > So if I understand your question correctly and you are not looking for > > the output of `licensecheck --list-licenses`, then unfortunately I have > > nothing exciting to offer. > > I think that's mostly correct. I was wondering what would happen if one > ran licensecheck debian/copyright, but unfortunately it doesn't look like > it does anything useful. I tried it on one of my packages (remctl) that > has a bunch of different licenses, and it just said: > > debian/copyright: MIT License > > and apparently ignored all of the other licenses present (FSFAP, FSFFULLR, > ISC, X11, GPL-2.0-or-later with Autoconf-exception-generic, and > GPL-3.0-or-later with Autoconf-exception-generic). It also doesn't notice > that some of the MIT licenses are variations that contain people's names. > > (I still put all the Autoconf build machinery licenses in my > debian/copyright file because of the tooling I use to manage my copyright > file, which I also use upstream. I probably should change that, but I > need to either switch to licensecheck or rewrite my horrible script.) > > Also, presumably it doesn't know about copyright-format since it wouldn't > be expecting that in source files, so it wouldn't know to include licenses > referenced in License stanzas without the license text included. Right. Licensecheck so far mostly scans for human prose stating "this has been licensed as..." and "this is the license...", and rarely is able to recognize "the default license of this project is..." or "that folder over there is licensed as..." style prose. That said, there is interest in covering that as well, and also interest in improving on non-prose forms like "[this is YAML;] Copyright: ..." or binary forms most commonly embedded in fonts and ICC data in images. It is helpful if you (i.e. anyone reading this) have a good (as in particularly rich/tricky/peculiar) case that you file a bugreport pointing to its failure of being recognized by licensecheck. Also, I hadn't thought of there being interest in statistics - it should not be too hard to spit out numbers for variation in licenses or copyright holders once licensecheck has recognized the information. Again, if someone has suggestions for formats they'd particularly like such statistisc to be served from licensecheck then please file a bugreport. Sorry this isn't helping anything for the topic being discussed. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: What licenses should be included in /usr/share/common-licenses?
Quoting Russ Allbery (2023-09-10 21:41:59) > Jeremy Stanley writes: > > > I'm surprised, for example, by the absence of the ISC license given that > > not only ISC's software but much of that originating from the OpenBSD > > ecosystem uses it. My personal software projects also use the ISC > > license. Are you aggregating the "License:" field in copyright files > > too, or is it really simply a hard-coded list of matching patterns? > > It's only a hard-coded list of matching patterns, and it doesn't match any > of the short licenses because historically I wasn't considering them (with > the exception of common-licenses references to the BSD license, which I > kind of would like to make an RC bug and clean up so that we could remove > the BSD license from common-licenses on the grounds that it's specific to > only the University of California and confuses people). If we go with any > sort of threshold, the script will need serious improvements. > > That was something else I wanted to ask: I've invested all of a couple of > hours in this script, and would be happy to throw it away in favor of > something that tries to do a more proper job of classifying the licenses > referenced in debian/copyright. Has someone already done this (Jonas, > perhaps)? I have so far worked the most on identifying and grouping source data, putting only little attention (yet - but do dream big...) towards parsing and processing debian/copyright files e.g. to compare and assess how well aligned the file is with the content it is supposed to cover. So if I understand your question correctly and you are not looking for the output of `licensecheck --list-licenses`, then unfortunately I have nothing exciting to offer. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: What licenses should be included in /usr/share/common-licenses?
Quoting Russ Allbery (2023-09-10 18:16:07) > Russ Allbery writes: > > > In order to structure the discussion and prod people into thinking about > > the implications, I will make the following straw man proposal. This is > > what I would do if the decision was entirely up to me: > > > Licenses will be included in common-licenses if they meet all of the > > following criteria: > > > * The license is DFSG-free. > > * Exactly the same license wording is used by all works covered by it. > > * The license applies to at least 100 source packages in Debian. > > * The license text is longer than 25 lines. > > In the thread so far, there's been a bit of early convergence around my > threshold of 100 packages above. I want to make sure people realize that > this is a very conservative threshold that would mean saying no to most > new license inclusion requests. > > My guess is that with the threshold set at 100, we will probably add > around eight new licenses with the 25 line threshold (AGPL-2, > Artistic-2.0, CC-BY 3.0, CC-BY 4.0, CC-BY-SA 3.0, CC-BY-SA 4.0, and > OFL-1.1, and I'm not sure about some of those because the CC licenses have > variants that would each have to reach the threshold independently; my > current ad hoc script does not distinguish between the variants), and > maybe 10 to 12 total without that threshold (adding Expat, zlib, some of > the BSD licenses). This would essentially be continuing current practice > except with more transparent and consistent criteria. It would mean not > including a lot of long legal license texts that people have complained > about having to duplicate, such as the CDDL, CeCILL licenses, probably the > EPL, the Unicode license, etc. > > If that's what people want, that's what we'll do; as I said, that's what I > would do if the choice were left entirely up to me. But I want to make > sure I give the folks who want a much more relaxed standard a chance to > speak up. Good point. Another way of reading the responses is that there was some interest in including even more licenses. I would also prefer inclusion of more licenses, simply had the impression that a) we could do that step by step, and b) my habit of writing copyright files (and other teksts) using [semantic linebreaks] made me forget that Expat license is arguably only 3 lines long (whereas in my style of writing it is 24-25 lines long). If "include all SPDX licenses" is for some reason (space in minimal systems?) problematic, then let me propose a threshold of 1000 characters - as that just about covers Expat ;-) - Jonas [semantic linebreaks]: https://sembr.org/ -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: What licenses should be included in /usr/share/common-licenses?
Quoting Hideki Yamane (2023-09-10 11:00:07) > On Sat, 09 Sep 2023 22:41:48 -0700 > Russ Allbery wrote: > > > How about just pointing SPDX licenses URL for whole license text and > > > lists DFSG-free licenses from that? (but yes, we should adjust short > > > name of licenses for DEP-5 and SPDX for it). > > > > Can we do this legally? If we can, it certainly has substantial merits, > > but I'm not sure that this satisfies the requirement in a lot of licenses > > to distribute a copy of the license along with the work. Some licenses > > may allow that to be provided as a URL, but I don't think they all do > > (which makes sense since people may receive Debian on physical media and > > not have Internet access). > > Hmm, how about providing license-common package and that depends on > "license-common-list", and ISO image provides both, then? It would be > no regressions. > > > I expect license-common-list data as below > > license-short-name: URL > GPL-2: file:///usr/share/common-licenses/GPL-2 > Boost-1.0: https://spdx.org/licenses/BSL-1.0.html Ah, so what you propose is to use file URIs. I guess Russ' response above was a concern over using http(s) URIs towards a non-local resource. What I practice since some years is the following syntax: Files: foo/bar Copyright: 2022 Someone License: Apache-2.0 or Expat License: Apache-2.0 Reference: /usr/share/common-licenses/Apache-2.0 License: Expat [the full contents of the Expat license] That syntax introduces a new field "Reference" (our copyright file format permits new fields, despite lintian complaining about it). Related discussion is at https://bugs.debian.org/786450 - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1051588: ITP: rust-pkcs8 -- pure Rust implementation of PKCS#8
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-pkcs8 Version : 0.10.2 Upstream Contact: RustCrypto Developers * URL : https://github.com/rustcrypto/formats * License : Apache-2.0 or Expat Programming Lang: Rust Description : pure Rust implementation of PKCS#8 The pkcs8 crate is a pure Rust implementation of Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification (RFC 5208). . PKCS#8 is a format for cryptographic private keys, often containing pairs of private and public keys. This package will be maintained in the collaborative Debian section of salsa, at <https://salsa.debian.org/debian/rust-pkcs8>. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmT9apgACgkQLHwxRsGg ASF3EhAApqSs0osaDj0TKQHPOsojxNNsEfYy9JeKhlkg1oJCF12v607EMlZc2o0x VQNh7cQTJUIASLoh965ntMOkfpclAPmqGqW0/D0V+ECDsCN7iaMnggllgxXnG/Yi 6nZumKICsQQu6wJME2T3a3gOaOoRIW591P+x26EFO4fABiDLz29ARnc24zNQknEy XL/xeN7A+MemMKub2pzYp8tqssGB8L/ARw31zqP5tjKyPAeEMFbVr59HfWqJrdU5 PcWiAGrYEC+MBfeO16a3tV6bot0Yomh6NetvbiYiOC5nEtq9tTIaOudON+0zIbom FcvPAKW2H6C1xCVg9T87iwsFjntbUn+mnVsXyhDUZYa/6bKO16mswuD0ZEDBN++Z w/l/DoQtrbP7WgYHeJONYJJADwZy334/m5MqukryjPxr9mYuW5/5M70cK5naWLuV 7M2HYi3lbefHvd3zbxh7UeqYXUq0yARnh8USyC9g4cR57d9rnNKwJbMixlTLrzfj tNZMYQI3U+hSn8rGXEWAjPk3n9QOAMPhRVotP/lFLX5u5UU+1yGrIebBD6G7Wf27 vnX0t0el0ME1kBnPOdtvKD1f5qHH7Om0++0y9Vu6o2MbSJRnTRlJ4cBtT8+JCZ9Y rLeawJcuVdrle2lYFDMUixrh9N4o50Q+id0Qo0i3Qxecmb/GNO8= =KMXB -END PGP SIGNATURE-
Re: What licenses should be included in /usr/share/common-licenses?
Quoting Russ Allbery (2023-09-10 05:35:27) > In order to structure the discussion and prod people into thinking about > the implications, I will make the following straw man proposal. This is > what I would do if the decision was entirely up to me: > > Licenses will be included in common-licenses if they meet all of the > following criteria: > > * The license is DFSG-free. > * Exactly the same license wording is used by all works covered by it. > * The license applies to at least 100 source packages in Debian. > * The license text is longer than 25 lines. I fully support the above proposed criteria, and appreciate your initiative to have this conversation. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: debian/copyright format and SPDX
Quoting Paul Wise (2023-09-09 09:18:59) > On Fri, 2023-09-08 at 12:09 +0530, Hideki Yamane wrote: > > > Making appropriate debian/copyright file is hard and boring task, IMHO > > Using scancode-toolkit/etc can probably automate most of that work. > > https://wiki.debian.org/CopyrightReviewTools Yeah, although that page is aiming at debian/copyright format, not SPDX. As an example, it does not cover (and I think it would be confusing to add to it, at least as currently structured) how licensecheck also supports producing SPDX shortnames e.g. like this (which generates a slightly **broken** debian/copyright file sude to MIT/Expat difference, so beware): licensecheck --check '.*' --recursive --deb-machine --lines 0 --shortname-scheme spdx -- * - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: debian/copyright format and SPDX
Hi Hideki, Quoting Hideki Yamane (2023-09-08 08:39:09) ½> > tl;dr: How about considering updating debian/copyright format to have > more compatibility with SPDX format > > > SBOM is expected to be used widely and several tools support it as a trend > now, since US government asks to use it. There are two formats for it, > Software Package Data Exchange (SPDX) and CycloneDX. > > SPDX is led by the Linux foundation project, OpenChain for license > compliance. And CycloneDX is developed by the Open Web Application Security > Project (OWASP), so it is intended to use track vulnerabilities, IMO. > > > Well, as I said above, several tools support SPDX and CycloneDX now and > continue to be expanded, so I consider it'd be better if debian/copyright > has more compatibilities with them, especially SPDX. It would be easier > to handle debian/copyright data with tools that are outside of Debian. > > > Making appropriate debian/copyright file is hard and boring task, IMHO, > but if non-Debian people also can help it, it would be easier to fix it. Only issue I am aware of is that SPDX shortname "MIT" equals Debian shortname "Expat". It sounds like you are referring to more and larger incompatibilities than that. Do you mean e.g. support for checksums of files (which will blow up size and kill readability of the file)? Perhaps as a start compile a list of incompatibilities on a wiki page - or point to it if one already exists. Then we can add pros and cons at that page, as the discussion here progresses. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1051238: ITP: biome -- formatter and linter for web languages
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Javascript Maintainers -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: biome Version : 1.0.0 Upstream Contact: Rome Tools is Rome Tools, Inc. * URL : https://biomejs.dev/ * License : Expat Programming Lang: Rust, Node.js Description : formatter and linter for web languages Biome formats and lints your code in a fraction of a second. . Biome supports JavaScript, TypeScript, JSON, and CSS. It aims to support all main languages of modern web development. . Biome has sane defaults and requires minimal configuration. Biome helps you as much as possible by displaying detailed and contextualized diagnostics. . Biome unifies functionality that has previously been separate tools. Building upon a shared base allows us to provide a cohesive experience for processing code, displaying errors, parallelizing work, caching, and configuration. . Biome is designed to eventually replace Babel, ESLint, webpack, Prettier, Jest, and others. This package will be maintained in the collaborative debian section of salsa, at https://salsa.debian.org/debian/biome -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmT2P20ACgkQLHwxRsGg ASEZWg//TeQDd1oBh1KOyQvlEQkq6aducgElCNp/fas9oXJt+wIbw2E5o62c74Iw 4fqYiHJp7+hwA9Ld87G0llqdokhAPsq4+bwH21x4EDoNSaWBlcBjc1V6q8g22g/b xm0cI2cQKC15MhVls+WuDKpdHeGZHqxp4F3dWoCXbmJtFK82nMkWJkXZOh3UiJ+P /dPV5mI1Y/uexZZZmww+LKdt51ma100kZbAf+P4XgQOo43zKiiguE3RSVYd5CKgv 3i5i0V5OCFeoYr1vsXL2G1G0vrNZHDygJ6V88F2VpMe/AxHShLpnhL5PaQgAEFeq scKmLpV7blYU4qDXp3im3OP9mJsetovNLhvr0b9HuLn8U3QhmJoOZ4CoydmMAoNJ Kj8crKndk+ioZa3ct15SdUjOmQCrrQ5w47VjDvlyIpx7BrKeA7jquVLC367/LcZQ H0MyMu4Gy6YvHYKXB6OvWO8GJPJo/63vVz/AJYYuR7NT3Q0C3eBKr/VW1p555Yyd k/12Qv5p+QmlN0u0vniLX3i4Ftr3sGNhcjxCVAgYqsRZyTUR1rtdRgY9Bf9qTkFC jbdUrxrUfiyuunQimUlTDbsAIykZQac5f4cHViDWiGdCv6niAJaVQOatwFHslM4B SffnPOG3kdMjZpgIwlpGhVhxLEjETlPKcfE22EsOKmPiKtkzCaE= =fldg -END PGP SIGNATURE-
Re: Bug#1050891: sccache - update for new addr2line.
Quoting Peter Michael Green (2023-08-31 02:01:53) > Package: sccache > Version: 0.5.4-11 > Severity: serious > Tags: patch > > I just updated addr2line to version 0.20.0, sccache builds succesfully > with the new version after bumping the dependency. > > Debdiff attatched. Please, pretty please, DO NOT BREAK REVERSE DEPENDENCIES uncoordinated. Cc'ing debian-devel, to raise awareness of this ongoing pattern. It is stressful. You cannot expect to to always react quickly, and it is not acceptable to use NMUs to paper over too sloppy coordination. Possibly you did your homework and your assessment about the magnitude of the damage is correct, but it is a risky game, and it is unfair: Allow those responsible for maintaining packages to actually do that. All that said, thanks for your bugreport, and for your tests. Please in future coordinate *before* doing breaking changes (unless it happens accidentally, of course). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: DEP-5 copyright with different licenses for two parts of the same file
Quoting Marc Haber (2023-08-29 18:31:52) > in daemon(1), I have a file with has two contradicting licenses in the > same file. See > https://salsa.debian.org/debian/daemon/-/blob/master/libslack/getopt.c > > >From the wording of the second copyright notice, I think it is clear > that that notice applies to the POD documentation included in the file > while the actual code is LGPL. Upstream confirms that this is the > intention and agrees that this is somehow suboptimally worded. > > Now, how do I write this in a DEP-5 copyright file? Having two stanzas > for the same file gets flagged by Lintian as an Error, and the DEP-5 > syntax doesn't seem to allow to mention two Licenses in the License: > line. Yes, DEP-5 supports multiple licenses for one file: Files: getopt.c Copyright: 1987-1998 Free Software Foundation, Inc. License: GPL-2+ and LGPL-2+ Comment: Embedded POD documentation is licensed LGPL-2+ and other parts are licensed GPL-2+. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Potential MBF: packages failing to build twice in a row
Quoting Jonas Smedegaard (2023-08-15 17:26:13) > Quoting Boyuan Yang (2023-08-15 16:28:19) > > Hi, > > > > 在 2023-08-15星期二的 16:16 +0200，Jonas Smedegaard写道： > > > Quoting Boyuan Yang (2023-08-15 15:21:22) > > > > I am looking for advice in handling these MBF reports against packages > > > > that do > > > > irreversible changes to the source files during build every time (such > > > > as > > > > updating timestamp). A broad category would be packages using Gettext + > > > > PO > > > > combination with /usr/share/gettext/po/Makefile.in.in involved / > > > > embedded, > > > > where .po file that contains translation is updated every time, causing > > > > dpkg- > > > > source to complain the diff and quit when building twoce in a row. > > > > > > > > Take https://tracker.debian.org/pkg/ibus-array as an example. The > > > > upstream > > > > project does not include .pot template file in the source code. The > > > > logic > > > > of > > > > Makefile.in.in is to call msgmerge to update po translation file with > > > > generated .pot file when .pot file is not present. This causes at least > > > > the > > > > following diff after build: > > > > > > > > --- ibus-array-0.2.2.orig/po/zh_TW.po > > > > +++ ibus-array-0.2.2/po/zh_TW.po > > > > @@ -6,7 +6,7 @@ msgid "" > > > > msgstr "" > > > > "Project-Id-Version: ibus-array 0.2.2\n" > > > > "Report-Msgid-Bugs-To: https://github.com/lexical/ibus-array/issues\n; > > > > -"POT-Creation-Date: 2019-12-10 22:09+0800\n" > > > > +"POT-Creation-Date: 2023-08-15 09:07-0400\n" > > > > "PO-Revision-Date: 2019-12-10 22:12+0800\n" > > > > "Last-Translator: Anthony Fok \n" > > > > "Language-Team: Chinese (traditional)\n" > > > > > > > > > > > > ... which would raise error on building twice in a row: > > > > > > > > dpkg-source: info: local changes detected, the modified files are: > > > > ibus-array/po/zh_TW.po > > > > dpkg-source: info: Hint: make sure the version in debian/changelog > > > > matches > > > > the > > > > unpacked source tree > > > > dpkg-source: info: you can integrate the local changes with dpkg-source > > > > -- > > > > commit > > > > dpkg-source: error: aborting due to unexpected upstream changes, see > > > > /tmp/ibus-array_0.2.2-2.diff.TnL2Yp > > > > dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit > > > > status > > > > 2 > > > > > > > > > > > > I am looking for the advice to implement an elegant solution. What I can > > > > think > > > > of now is to persuade upstream to embed a copy of generated .pot > > > > template > > > > file > > > > in source code, which does not sound reasonable. Meanwhile since > > > > Makefile.in.in is somehow widely used, this issue likely already had > > > > impact on > > > > packages using gettext to handle translation. > > > > > > I see too options (aside from persuading upstream to not ship > > > autogenerated files in the first place, which is arguably the most > > > elegant but they might see it differently): > > > > > > a) repackage upstream source to exclude autogenerated *.pot files > > > > > > b) put aside autogenerated *.pot files during build > > > > > > For a) the common mechanism is to declare an Files-Excluded: field in > > > the header section of debian/copyright, and declare repacksuffix=+ds in > > > debian/watch (or repacksuffix=+dfsg if DFSG-conflicting files also need > > > to be excluded). More details on `man uscan`, e.g. in section > > > COPYRIGHT FILE EXAMPLES. > > > An example package using this method is node-expat. > > > > > > For b) I would suggest to move aside (but only if already done) in > > > debian/rules target execute_before_dh_auto_configure, and move it back > > > (forcefully - i.e. overwriting whatever might be there already - but > > > do nothing if no file was put aside) in debian/rules target > > > execute_after_dh_auto_clean. > > > An example package using this method is librdf-rdfa-parser-perl. > > &g
Re: Potential MBF: packages failing to build twice in a row
Quoting Boyuan Yang (2023-08-15 16:28:19) > Hi, > > 在 2023-08-15星期二的 16:16 +0200，Jonas Smedegaard写道： > > Quoting Boyuan Yang (2023-08-15 15:21:22) > > > I am looking for advice in handling these MBF reports against packages > > > that do > > > irreversible changes to the source files during build every time (such as > > > updating timestamp). A broad category would be packages using Gettext + PO > > > combination with /usr/share/gettext/po/Makefile.in.in involved / embedded, > > > where .po file that contains translation is updated every time, causing > > > dpkg- > > > source to complain the diff and quit when building twoce in a row. > > > > > > Take https://tracker.debian.org/pkg/ibus-array as an example. The upstream > > > project does not include .pot template file in the source code. The logic > > > of > > > Makefile.in.in is to call msgmerge to update po translation file with > > > generated .pot file when .pot file is not present. This causes at least > > > the > > > following diff after build: > > > > > > --- ibus-array-0.2.2.orig/po/zh_TW.po > > > +++ ibus-array-0.2.2/po/zh_TW.po > > > @@ -6,7 +6,7 @@ msgid "" > > > msgstr "" > > > "Project-Id-Version: ibus-array 0.2.2\n" > > > "Report-Msgid-Bugs-To: https://github.com/lexical/ibus-array/issues\n; > > > -"POT-Creation-Date: 2019-12-10 22:09+0800\n" > > > +"POT-Creation-Date: 2023-08-15 09:07-0400\n" > > > "PO-Revision-Date: 2019-12-10 22:12+0800\n" > > > "Last-Translator: Anthony Fok \n" > > > "Language-Team: Chinese (traditional)\n" > > > > > > > > > ... which would raise error on building twice in a row: > > > > > > dpkg-source: info: local changes detected, the modified files are: > > > ibus-array/po/zh_TW.po > > > dpkg-source: info: Hint: make sure the version in debian/changelog matches > > > the > > > unpacked source tree > > > dpkg-source: info: you can integrate the local changes with dpkg-source -- > > > commit > > > dpkg-source: error: aborting due to unexpected upstream changes, see > > > /tmp/ibus-array_0.2.2-2.diff.TnL2Yp > > > dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status > > > 2 > > > > > > > > > I am looking for the advice to implement an elegant solution. What I can > > > think > > > of now is to persuade upstream to embed a copy of generated .pot template > > > file > > > in source code, which does not sound reasonable. Meanwhile since > > > Makefile.in.in is somehow widely used, this issue likely already had > > > impact on > > > packages using gettext to handle translation. > > > > I see too options (aside from persuading upstream to not ship > > autogenerated files in the first place, which is arguably the most > > elegant but they might see it differently): > > > > a) repackage upstream source to exclude autogenerated *.pot files > > > > b) put aside autogenerated *.pot files during build > > > > For a) the common mechanism is to declare an Files-Excluded: field in > > the header section of debian/copyright, and declare repacksuffix=+ds in > > debian/watch (or repacksuffix=+dfsg if DFSG-conflicting files also need > > to be excluded). More details on `man uscan`, e.g. in section > > COPYRIGHT FILE EXAMPLES. > > An example package using this method is node-expat. > > > > For b) I would suggest to move aside (but only if already done) in > > debian/rules target execute_before_dh_auto_configure, and move it back > > (forcefully - i.e. overwriting whatever might be there already - but > > do nothing if no file was put aside) in debian/rules target > > execute_after_dh_auto_clean. > > An example package using this method is librdf-rdfa-parser-perl. > > I believe your take was in the reversed direction -- the issue is not about > upstream including auto-generated files, the issue is that upstream is **not** > including auto-generated POT files. > > * If auto-generated POT file is present, the PO file will not be updated using > msgmerge(1). The source code is not modified during build. > > * If auto-generated POT file is missing, it will be generated on-the-fly with > a new timestamp, and the PO file (in the source code) will be updated with a > new timestamp. The source code is thus modified, making dpkg-source(1) to > fail. Ah sorry, I indeed failed to read your scenario properly. If PO files are not updated when POT files exist (which sounds odd to me) then perhaps simply touch those files to bring them into existence during build, to fool msgmerge? Probably you will then need to touch them with a date earlier than the PO files for the trick to work. And make sure the fake POT file are removed in clean, and also excluded from getting installed if needed. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Potential MBF: packages failing to build twice in a row
Quoting Boyuan Yang (2023-08-15 15:21:22) > I am looking for advice in handling these MBF reports against packages that do > irreversible changes to the source files during build every time (such as > updating timestamp). A broad category would be packages using Gettext + PO > combination with /usr/share/gettext/po/Makefile.in.in involved / embedded, > where .po file that contains translation is updated every time, causing dpkg- > source to complain the diff and quit when building twoce in a row. > > Take https://tracker.debian.org/pkg/ibus-array as an example. The upstream > project does not include .pot template file in the source code. The logic of > Makefile.in.in is to call msgmerge to update po translation file with > generated .pot file when .pot file is not present. This causes at least the > following diff after build: > > --- ibus-array-0.2.2.orig/po/zh_TW.po > +++ ibus-array-0.2.2/po/zh_TW.po > @@ -6,7 +6,7 @@ msgid "" > msgstr "" > "Project-Id-Version: ibus-array 0.2.2\n" > "Report-Msgid-Bugs-To: https://github.com/lexical/ibus-array/issues\n; > -"POT-Creation-Date: 2019-12-10 22:09+0800\n" > +"POT-Creation-Date: 2023-08-15 09:07-0400\n" > "PO-Revision-Date: 2019-12-10 22:12+0800\n" > "Last-Translator: Anthony Fok \n" > "Language-Team: Chinese (traditional)\n" > > > ... which would raise error on building twice in a row: > > dpkg-source: info: local changes detected, the modified files are: > ibus-array/po/zh_TW.po > dpkg-source: info: Hint: make sure the version in debian/changelog matches the > unpacked source tree > dpkg-source: info: you can integrate the local changes with dpkg-source -- > commit > dpkg-source: error: aborting due to unexpected upstream changes, see > /tmp/ibus-array_0.2.2-2.diff.TnL2Yp > dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 2 > > > I am looking for the advice to implement an elegant solution. What I can think > of now is to persuade upstream to embed a copy of generated .pot template file > in source code, which does not sound reasonable. Meanwhile since > Makefile.in.in is somehow widely used, this issue likely already had impact on > packages using gettext to handle translation. I see too options (aside from persuading upstream to not ship autogenerated files in the first place, which is arguably the most elegant but they might see it differently): a) repackage upstream source to exclude autogenerated *.pot files b) put aside autogenerated *.pot files during build For a) the common mechanism is to declare an Files-Excluded: field in the header section of debian/copyright, and declare repacksuffix=+ds in debian/watch (or repacksuffix=+dfsg if DFSG-conflicting files also need to be excluded). More details on `man uscan`, e.g. in section COPYRIGHT FILE EXAMPLES. An example package using this method is node-expat. For b) I would suggest to move aside (but only if already done) in debian/rules target execute_before_dh_auto_configure, and move it back (forcefully - i.e. overwriting whatever might be there already - but do nothing if no file was put aside) in debian/rules target execute_after_dh_auto_clean. An example package using this method is librdf-rdfa-parser-perl. Hope that helps. -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1049395: ITP: rust-ed25519 -- generic Ed25519 signature algorithm
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-ed25519 Version : 2.2.1 Upstream Contact: RustCrypto Developers * URL : https://github.com/rustcrypto/signatures * License : Apache-2.0 or Expat Programming Lang: Rust Description : generic Ed25519 signature algorithm ed25519 is a library providing asynchronous, multiplexed tailing for (namely log) files. The `ed25519` crate allows you can write code which signs and verifies messages using the Ed25519 signature algorithm generically over any supported Ed25519 implementation. . This allows consumers of your code to plug in whatever implementation they want to use without having to add all potential Ed25519 libraries you'd like to support as optional dependencies. . Ed25519 is an EdDSA signature scheme using the secure hash function SHA-512 (SHA-2) and the elliptic curve Curve25519. This package is needed for safe-network (bug#1008016). It will be maintained in the collaborative debian section of salsa, at <https://salsa.debian.org/debian/rust-ed25519>. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmTbL9YACgkQLHwxRsGg ASFsMBAAj1zwdh8h4Lgh3bwUj++Kc6oY4mX0vbZiMlu49sxouiO9oodMuQS59n98 O0ssYElt4qci6QKLh9pgeElbl6kjT6ao3cO821IqOzy0BYpsiIl9/4MVGxNztmGh TrY8UNUEgjI0Yv7g2Q3CnrrCRs5KL5Htost9Ohj2/j+9crd57/0RerKmG5wKztul OjmWN2sRBpNDPqsGXW3R6JZWlDuhmea3hrkZ6JYZgzBtunZedYNtxvqCyy50IYqp Yh9IY0RLGkgHL3SLQfxkYvrin9e+HZFRD0Q3FfQ73Yh3+j4Rmk0mkIDvLyIJsPY/ hBvXJBLa/r5CkfE1/nLFzNASwMZ4RjSvRx/qKO5cDXD7IXZ27yd4MY8CT8Tvp1Gb t3WuCPwRsfUhgvIsFThXgsualYCBgMMxk3Scwd7eQvLhmayA46tMtTmqIHRUniMK T7akb6Z0+AAWa/9YnG9XkIiY6ihEBm+zlhVmQZAMVUcPMmo6MEDuusn6llRNlXjF AhMGWaPuXpgWlMrP9Kve93YodNH/hnIMaRMzhQ6jS4lw+YH0xTIyNkHK8rUM4ObD nO7ueCSMFlP1G3HuNp75T0HsrM49K0oelgiU9rZj4EKW/SXv5WJId9chVLdqCSlj IdMo0W4CI8tlgZYedD9veexGCpY/mSXSOF+VuIDZJol1SN6I6N0= =aSiD -END PGP SIGNATURE-
Re: Potential MBF: packages failing to build twice in a row
Quoting Timo Röhling (2023-08-10 11:56:42) > Hi, > > * Helmut Grohne [2023-08-10 06:43]: > >When repacking, the upstream signature becomes useless and external > >parties can no longer verify it at ease. Including that upstream > >signature increases trust in the source shipped by Debian being > >good. > I don't think that problem is very relevant in practise. > > On the one hand, the vast majority of upstreams I have encountered > so far do not ship any signatures at all. Some upstreams do not even > have an immutable release archive; Github (for example) generates > TARs and ZIPs on the fly and changes the exact format from time to > time. > > On the other hand, those upstream developers who care enough to go > the extra mile with a meaningful [1] cryptographic signature, > probably also pay more attention to the actual files they ship, > making it less likely to require repacks in the first place. > > > Cheers > Timo > > > [1] A signature is only meaningful if the signing key is kept > secure. If you upload a GPG private key to your favorite code > hoster and have it sign releases automatically, you have a very > convenient workflow that achieves nothing at all, because the > integrity of the release still depends on the integrity of the > hosting platform. I disagree that hoster-signed released are totally worthless. Even if we in Debian consider (other) hosters not worthy of our trust, downstreams of Debian may value some hosters differently and find value in our tracking their offered signatures. Example: An organisation has examines licensing of Chromium as installed ontheir Android and Linux systems, expressed as SPDX datasets with SHA1 checksums for upstream tarballs. They need to do a full analysis for each upstream release, but would prefer to only need a partial analysis for each Debian repackaging if possible. If Debian included a SHA1 which matched a SHA1 in their SPDX dataset then they benefit. If SHA1 for one reason or another don't match then it not a sign if insecurity, only a more expensive process for them because they then need to analyze that repackaged tarball as unique instead of as a derivation of something known to them. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1043206: ITP: rust-snow -- pure-rust Noise Protocol Framework implementation - Rust source code
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-snow Version : 0.9.2 Upstream Contact: Jake McGinty * URL : https://github.com/mcginty/snow * License : Apache-2.0 or Expat Programming Lang: Rust Description : pure-rust Noise Protocol Framework implementation - Rust source code The snow crate is a straightforward, Hard To Fuck Up™ Noise Protocol implementation. . The Noise Protocol Framework is a set of crypto protocols based on Diffie-Hellman key agreement, that each can consist of a single message as well as interactive protocols. This package is needed by safe-network (bug#1008016). It will be maintained in the collaborative debian section of salsa, at <https://salsa.debian.org/debian/rust-snow>. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmTQzK0ACgkQLHwxRsGg ASFu6RAAqV5579Kkcc8SQ4bffdnmgrRfkz+MoRrxeO8EkedUvS89+QpTEyQxJ9I+ 0MMsX63kOxVY7YduR8hNzXwINpn7J+T4vyp+To+r+AaE2wn80BhJw3k1HNRnTSpY /h/US3EUJ5fmBMzwqzwoFck7DLofN/IL+R9VOlpJMNwxQnkDQdbIdTbFdRdq/Arz kbtsg52Xz1Nu2x4UIz44NOOuN3FBTxrNbMoMuNMUYrlah2disrw5Li439lA7BLcE VXggUoX+QLq8JQl5vbt3lAitXSn0mxDIFfcclz6kiN90K99KcoDQG3NoaRtfA6eu KtPMdrdYk/LvXC5LHh7UvaxuHc3/wXH59m458XffcrzMtVk8Uuyep2S8VHXDX5r3 MYVnyVnH50q/6DCcGtaJ0gdDb7bCZt9swtNmaZGKlEtKThw0sts9ezLXYsuro1qr TvHJ+rGM2Jsi7OyDym3K4zEYLPuxLFYZb2vkXmi759Y93qb6Tn5GVqMs6in72G/O ko1/76G39db/DU7HpiXPiESeDZFxcb/fupQ7TlPBtJq62YweRnFTINJf6FKNyJTP pvSRN01CBTPmYTmkzbBi/SIDHgvKbA3uxR91sW5J07SzDXwod+R119cfa+306ZRU XM7sFr3Sa4FZJ9mdZRV9681iVe6J2+HUwS3r6P+hl1utpeQWSGk= =LTw/ -END PGP SIGNATURE-
Re: Can we distribute pre-built locales to speed up image generation?
Quoting Charles Plessy (2023-08-01 09:43:59) > Hello everybody, > > In the course of generating singularity/apptainer Debian images at work, > I wanted to make all locales available to the users. > > Running locale-gen on everything from /usr/share/i18n/SUPPORTED only > adds ~60 Mb to the image, which is small compared to the image total > size and the available storage in my use case. However, generating all > of them at image creation time is by far the most time-consuming and > earth-heating stage. > > The description of the locales package mentions that in the past they > were distributed pre-built. I was wondering if it was recently > considered to provide pre-built locales again, either in a separate > package or in one of the system images that we distribute, in the > interest of embracing language diversity. > > It has been a long time I have not posted here, and I am not subscribed > at the moment. Please CC me! Are you perhaps looking for the package locales-all? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: libgmp3c2 sources
Quoting Svetlana Karimova (2023-07-31 12:40:16) > Dear developers, > I work on a debian-like embedded system with quite an old kernel, so the > package libgmp3c2_2:4.3.2_armel.deb suited me perfectly. > The problem is that now I would really like to be able to build it from > sources as well, but I can't find them anywhere on the web. > Maybe you know someone who might still possess the source files? What you want is https://snapshot.debian.org/ Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1041919: ITP: rust-signature -- traits for cryptographic signature algorithms
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-signature Version : 2.1.0 Upstream Contact: RustCrypto Developers * URL : https://github.com/RustCrypto/traits * License : Apache-2.0 or Expat Programming Lang: Rust Description : traits for cryptographic signature algorithms signature contains traits which provide generic, object-safe APIs for generating and verifying digital signatures. This package is needed for safe-network (bug#1008016). It will be maintained in the collaborative debian section of salsa, at <https://salsa.debian.org/debian/rust-signature>. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS/lYIACgkQLHwxRsGg ASHXSA//VwukNfUOCHqUl5nNRM8j6wbTbJN0y3ajyQ5pVwGaC5lpX7Sbe7ALFFdF czwxXPhwa41ujgjJRW1sasJylaaRch3v+9chulSF2Of3wLJls9LFa9PdJun8Ifbd T95aBpYY4gTAyM/D4WDzU950kSEF863atxGSJzu5TG/qPc2PB1DhhXf+yqcB9evY 9kA1wjjTFZ8VT+eLjqthIvAgNvB+zvLC2MhRWUlb9zwW9D31P2wT9MBSqOnPDCer KisDADLrBAHDSGHSTrvf7NzvTtmLfgJPOu9o6S9f6oEXuuZFjAHlQD1zGL1Iqqrn pu6hyI6VJtvtUzZ1olufVQ05XyVY1OH/nEnrBdJxsMfWSvItZLl0gebR9LxJfXqI NOHHDH+Chelw79PM+RKtVFVMYeXX/zUnxpzyGQ0vEfV5HiQ8QOCAkdk5r2wa2BuX TeholvTSNS4GKXFzH17CZJUk5eZQp5EzUAL9jIXivB5DhiJJws0cIzT3pFiX4WNG flc/ir7PSCLcqO5T7VKPxCYSdUxyBGT1tyH+4sfs2yvEA7uaxIMWlBmenebqxrLV s9rN2Scj4GAqhZTWCTzt/KCRa3H3TczQ8s54hBunWQjaN5ych3Iy8IPHwOT4DlE9 NTTxEUxpHG1+LWKDSawR260ZFjOJfjG/vuqIsgDh1kWCCw3MhTY= =l+IW -END PGP SIGNATURE-
Bug#1041880: ITP: rust-multiaddr -- composable and future-proof network addresses
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-multiaddr Version : 0.18.0 Upstream Contact: Friedel Ziegelmayer * URL : https://github.com/multiformats/rust-multiaddr * License : Expat Programming Lang: Rust Description : composable and future-proof network addresses multiaddr is a library implementing the "multiaddr" format, aiming to make network addresses future-proof, composable, and efficient. This package is required by safe-network (bug#1008016). It will be maintained in the collaborative debian section of salsa, at <https://salsa.debian.org/debian/rust-multiaddr>. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS+0WoACgkQLHwxRsGg ASH6fw//dxQmpl4IPihgTOSW5bev3xjs/4ANsyh4jG+D9kf3uxlQE5xhDZgR5IZT VUFpZjZcY7mGiq8tvdOlOKAT0cL2fm9WqqmwWcfUVJIa1Z3wCoO4B61OVHr4Xipx kKMcKwbCrWlumJXJWy6r+/1bB+Q94NNZWWGc3/MYOPOg8XnJiArYd3n/lUfEsA75 p0hGRsgcgMk+EQRdZvL9n25UPK+daU42gj8nTl5s8fBTRyxwYmd+2hE36euGCWni wjF2zqzlWQGtVGqfvBU1suXM+MSqOuR12lVCNIPRiAw8UCAmnI8WIMDUe9NQpabc MjQMmtzZwGQ5cx4cP7U2TpbDVhbW8UqAw25PFbrony4UXAeGvZPGgdi3RcyFk1+C V8oj9NC2xIDa2OAde4/g0jkykWrMBIeUVh+yisare+o9AwrjBGqp/BDSPLD4qQEq uNJl7EXGBYxgFZw+tXrmKhJ+UDqUwwoZ2NrdleVYZLJT0zdBKtGQRik6CpcNNzyT u9zksOsaHciIPOBJ01RzVaROGWxDluWArYAArdNp8B295DmaP3L3C/nSR3aHxOx/ qIl21iy/g5PBSqtvC3Oull9eKfqskN2cjgVUg/RsRkuvIs+iN3KFXjkESjpfs9l/ EttnK4aiWMv9+mD+RiDI0mQRHI2VdLe45g8vLRE65lw+Oqi8ksg= =Kttr -END PGP SIGNATURE-
Bug#1041861: ITP: rust-libp2p-identity -- libp2p peer identifying structures and algorithms
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-libp2p-identity Version : 0.2.1 Upstream Contact: Parity Technologies (UK) Ltd. * URL : https://github.com/libp2p/rust-libp2p * License : Expat Programming Lang: Rust Description : libp2p peer identifying structures and algorithms libp2p-identity contains data structures and algorithms for identifying peers in libp2p. This package is needed by safe-network (bug#1008016). It will be maintained in the collaborative debian section of salsa, at <https://salsa.debian.org/debian/rust-libp2p-identity>. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS+nfoACgkQLHwxRsGg ASGO+A//YSVjy9TOFAnY4MICxcRZDx2DG80MyYDZP37ogZ7FC6Z5ygrgvJ9TOK4Z TAGVDoZ1zmYM+7IlQkzMwjIxw7u8EFGAP65cfDheIH8SRAO87QzwHvP3nSCxrPuR nBrucacutHWKSBMtQ5Gk/sPj7DI9+VK+1vOLh7rxy74EBdjTRVJE7LWak7vyC+uK 3HvRMqmsm+u1YBSzOPBXKPeDjCFgqlyN4bfap0uvDzQP0ZvN2dvjEqeMb3EbgF9h GN65QZJcLy/LZbCNO+uH09pR75dar22WA0Cqqb4+l7hLY6rIa+U6rDDR1TbDlHfB FKhLH9Q44i7UP2l4kI0SYpxVJWIKqBozGO4BE2/fdN9Sz1MAGFRhfpwERSMJSbsS 2IxZDlU3N4KNdvCa+DsxAjGF8Bbo7I6M/kVqpTETU91u1E3cCAoZsvXgRbzMCxyH LOlTYquXdUVSrJCgvDK+1PdXHLAgByVolZay2imBPSSsPQN1iyILD0K0yt5u0WC/ /qVZbTWtomNS9BtrJbdXXU5zcH4FKG6MQ0W3kYAykWTPNfPsEWpxXYsiYPc7doGU QcGHRGh44t7/W5a4yYYSRvDvhARUmIEVbQ644XSvcbekcB2piTRnoN0O6kwTP3XB VVNRsbiUxGPCd4SuOJLjWyUNudERHi+QsUU70sjRLaIPji5IKZE= =81qQ -END PGP SIGNATURE-
Bug#1041733: ITP: rust-linemux -- asynchronous, multiplexed file tailing
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-linemux Version : 0.3.0 Upstream Contact: Jon Magnuson * URL : https://github.com/jmagnuson/linemux * License : Apache-2.0 or Expat Programming Lang: Rust Description : asynchronous, multiplexed file tailing linemux is a library providing asynchronous, multiplexed tailing for (namely log) files. . Also available is the underlying file event-stream (driven by notify) that can register non-existent files. This package is needed for tailspin (bug#1041717) and safe-vdash (bug#1009781). It will be maintained in the collaborative debian section of salsa, at <https://salsa.debian.org/debian/rust-linemux>. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS8DncACgkQLHwxRsGg ASEnVg/9Evn2uuNe5P7JwBOAcrbBoWLsAlViW7cr8ZpbenTAEeqVRuEGskMsIrR1 7Q5bqtXCxJk8yNZggXnJmQZvCTPjJ8YG/05TT5M+LeNQszQgnJqeXtDYXos6KGbX YHGcCKHeN2HXAm9XftFPu+gtEZqxVFF/ghtH1wsOpCj7LXCzV6a9iVfEErevZPBU T3eM1KXCwqM3U2mV2X/FvRcgkTtRIQEiC98JeLRRK6sGS6uiuaItT+WDq2NomuJE siJO5pTELWuCZpMjAjVYfIE/emp7alp3NlepwPxENbgoxMza7GSbeecDqMrtsLR7 DzdmbzOfgVqzeYtfR50oiQ4hQG3O/l0uzAVEno7wilQCh+IphtMTBVcw3NFfu7Qk RE28ObdHQPELCfswUXmqcAc8k1nzqIivyr0mRTbYqaek4tpaPPhK2SGKWR+sY04q Far/c9wmo/AhgRq1u/NMN/1O/FOkJ8nx4fUaKSLFLO5Jcewmm0buNXA9Re1v1piS 3coRb2fi94WzwYTJ69Iwq4y0HvpZIRGUO5sLgkdjFyr4QXr02HIPUHmECr/jd61z FaMmie9jXQADkQkcRFyl6/EHP6rAVZiuAdsQidRzlnokQIybpxYLcEzv3lb+emN7 lkLJLwx1+l/J/iG4nLAF4+375Z/E69X+IReJcIr6EKoXxFyy1jg= =Tkfc -END PGP SIGNATURE-
Bug#1041717: ITP: tailspin -- log file highlighter and a drop-in replacement for tail -f
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: tailspin Version : 1.0.0 Upstream Contact: Ben Sadeh * URL : https://github.com/bensadeh/tailspin * License : Expat Programming Lang: Rust Description : log file highlighter and a drop-in replacement for tail -f tailspin is a command line tool for viewing (and `tail`-ing) log files. It highlights important keywords to make navigating log files easier. . tailspin is fast and easy to customize. It uses less under the hood to provide scrollback, search and filtering. This package will be maintained in the collaborative debian section of salsa, at <https://salsa.debian.org/debian/tailspin> - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS77PcACgkQLHwxRsGg ASHujg//aUX/vCS+1Y2spgtQ0YCGnYoboEUcT9oXvyVH9RfLErLn+bdCl9/YkETK 5CEJU4EkS6Sol6bbmO1niQt+VoEeBsOxee4PSmcpB1g5kFOJJyxi9yCui8PVrti1 +BsB1myBx8bkvFptDhgW3fnsrWsm8Yvslq8d16v4D1OgjM+a6M8jjsl8RZm0k2dT F60MEsvG3dIv+oKcFt2c98wN6MphDXOuq1p7JyMv775XUd0iWz3LLuFHFs9EOazx eRk1OcxM6dmptFpCAbCt8OHalYJ6YcFCU+/70XurDN90qs3JfhcVHCmACORuFTWE RV1h1vEfNds18YjDOLzo2DjYesvsHbnAVfBOu4Bdivg4QdhXZmI6hkFbWhMooN6z CB5lca9X8Wj0C/5vgczTw53bDPbpOLXLw4Vfgyrq/Q7wApL4+nCjLrmQj9e3dRDo w/ImpMhzJRJAMI1gVicduPS7Pko344GOQMvSesnqYUxiObjk5+89t3U/nY1iQLQx MWykSUqG7kM5TqaXeLA8dR9PUTg68vdNK6TBaZFjK7WrgeltIgchu6yI5hakFEFf cJZdHym0pv7Vi3GXH8FAlBdU7eaUGB2ox9XBUhakOIUC7bcIuOK5Kb/qaGkdzUXa ood9I+kkSHvTrOWu9mRw0Sb0pZJgx+GRq5jgdqn3ly3k1pAabYE= =28f1 -END PGP SIGNATURE-
Re: HFS/HFS+ are insecure
Quoting Matthew Garrett (2023-07-22 09:54:59) > On Sat, Jul 22, 2023 at 03:41:58PM +0800, Paul Wise wrote: > > Disabling auto-mounting and for manual GUI mounts, requesting users > > confirm they trust the filesystem they are mounting would avoid that > > as much as is reasonably possible without entirely deleting the code > > and without breaking the use-cases of people who need the filesystem > > code. > > When is a user going to plug in a USB stick and *not* click that > button? When the user had plugged in a coworker's phone they were asked to please charge. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1041463: ITP: rust-wasmtime -- cross-platform engine for running WebAssembly programs
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-wasmtime Version : 10.0.1 Upstream Contact: The Wasmtime Project Developers * URL : https://github.com/bytecodealliance/wasmtime * License : Apache-2.0 with LLVM exception Programming Lang: Rust Description : cross-platform engine for running WebAssembly programs rust-wasmtime is the Rust embedding API for the Wasmtime project: a cross-platform engine for running WebAssembly programs. This is a pseudo-ITP: The source package is already maintained for the subset covering core Cranelift crates, since they are part of same monorepo. The intent tracked here is extending that source package to provide binary packages librust-wasmtime* which involves additional dependencies unneeded for Cranelift. Please shout if there is need for wasmtime, and especially if there is interest in helping get the needed dependencies packaged. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS3pT0ACgkQLHwxRsGg ASHK0Q//T+JkDOAzi2aWZVLT0106beLktA52VWg0mivPwwM915X+mV3Ay1WcM022 3it2jJNtm3i/srEm1whOK/hB74kW2QvXuCRt9s9f4LQgchhvdp3RrjCdWFZwhgtI fy4ukekVJeDDa8gVY7BoTVMDRKBBNs7oLKnOhj08HPGi/mn+bB9tg1BCPL5DpZJt k/VpwFQFCG/Oe3ddlVRRyiZ/KnrprlEbOstMhgDyHMNPbaDgBuBl4Zjdv2TknHzH D2/aWPjdQncD53ub+MKOZIlhHs1CN6jZt0eEek3mFXtotG12jXDxwlvuhLuNTbVa HjudFhavVuHM1ugOYvfh9ucLUbBNx+P8pZjW2JDhNBQp2wOVCT6HYLo6uv0R1eGS fWu1LoY4mRx5X6wvTuZGB7LoOBds0dZo/96o7YPz/gnuhMR/5jfEUyQy1RZhYYe6 cEWSLQdjSVlHHfYgZ50uOdx99T+yd4jeimTCyb5CBYWtSIS3MBLLAaurapfxlIqC laFzGQ02qx+LOfsRahzsjLzf++fK5xMM16ombKEgyMHT5zu/2BwXiUCZunv5TURT A2bgXzyTaumrsvAHNrY4FWarXNywNd7srjaAsGwSN9iN75KAhS4Pkk0r9pPposBl v3TkcJv9mfc780lefjqyVJc1uzJ6VSNKS98G2JKCoaaqYN77W0A= =t/RV -END PGP SIGNATURE-
Bug#1041434: ITP: rust-cranelift -- low-level retargetable code generator
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-cranelift Version : 0.97.1 Upstream Contact: The Wasmtime Project Developers * URL : https://github.com/bytecodealliance/wasmtime * License : Apache-2.0 with LLVM exception Programming Lang: Rust Description : low-level retargetable code generator Cranelift is a low-level retargetable code generator. It translates a target-independent intermediate representation into executable machine code. This package is needed by swc (bug#991761). It will be maintained in the collaborative debian section of salsa at https://salsa.debian.org/debian/rust-wasmtime (wasmtime is a monorepo also containing Cranelift - if there is interest and the needed dependencies get packaged, the package may in future be extended to also provide wasmtime itself) - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS27GEACgkQLHwxRsGg ASHqog//QFxRjTnYEPBqPbJjOwnL+9kRs5IQgdOZdnO1O+Aw1A0mRamKiznbjWnI mBICExMTr4vvu29Z1NK63Ih28N1Yu4xo/bj2b5gDdNtnSs1uHsMeF3LWYhcS0AYd DhQ+DiMHX9sA0fLoXLouNd2RSBqNOhHDqSV4ry0/W5ugNw2v5likDEjASPCxV0jr 67NWeOV7lA3oxv0/8guyHGTHiyswh9oWC+qljHTGZ82oofAQa90PEq9jB/orrzpR Rr3y/haQLXz1NG2AwtIbKGtk8QGYkFKsWyoiA5bpg+anmJK+h67/h/mUu/0Lu2F/ y1+CF3Qx0BSmKP47EIOoghpwhi0l8SarXd1bzD1NWziONZCOV6pXSTHc6kWAIFBQ CWRoFD8LbXQ3dCGD0ZFWRl0os6xdCpC9pTH2UDkGSlIOFhUZQKLXK2KtlzuixOZJ j2GDXe2HfW4XFw6GyFJ+fIIuTHHkTD3XGy1oEKlylMnlokfmJLE2lI3IxElQANXS FzCARK5mujqH2eEbASSZy5Y/J0uROKOGL5oQCfbAV0h54iep96S2rMC8PvhZpawI 3eiAoTVdiQXj7bSJUEC2ghZqgjfH6SDsQkGEoC/TVl5y7E1xGpJnUMjo/3xVMoIz CYo+Dt3SmNDkWKqwrs87+WtsPGPjauc7pHXm1RKWFMbvqS+HdkY= =CTzG -END PGP SIGNATURE-
Bug#1041433: ITP: rust-id-arena -- simple id-based arena
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-id-arena Version : 2.2.1 Upstream Contact: Nick Fitzgerald * URL : https://github.com/fitzgen/id-arena * License : Apache-2.0 or Expat Programming Lang: Rust Description : simple id-based arena id-arena is a library to allocate objects and get an identifier for that object back, not a reference to the allocated object. Given an id, you can get a shared or exclusive reference to the allocated object from the arena. This id-based approach is useful for constructing mutable graph data structures. This package is needed by swc (bug#991761). It will be maintained in the collaborative debian section of salsa at https://salsa.debian.org/debian/rust-id-arena - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS25kQACgkQLHwxRsGg ASEEkhAAlbxqMawN2g8N0k39ooY+dMWMHpQqdkoqEmnYxbg1uYyRK6ioxyAXoiec Jj5/E4lzU9KXQOiiOIdpOgTvunhC+E5uPScOGs1rYnwUgHzI4tniN0SPRhcucpa8 QDdI9PFTSvPxSAeX+xVjFt1r06/lbXMMhNixVDYOu3M9GEX4Q2w0RzaKLwxBdOrW j6iviB6LtgB5pZaWrxsTy3XgB8gr43qgMnd/Mh+IY2ch8h+ge1N3/ti1/BPgxz3C ioc0ahisl+DruBFAZf4v3u+mcLitcv1g1nrfmE0bSV+JiudE2m7PJibpUXzPBWoK lCoEyBmA+jRzWynuiKqcZre1A6ckW/lQ2YkR+/IlHWHSLgQdCixUa4kiDE93hqcd +g+vEbqFtzWJwTr7g1XCs9oPejPe/b2XUz2qrxsSHaqxgPOJVE5Vrcp0ROt5umTz 7E6iQUhq6PeAvZz7uGp3r4uJqntdQT93zvv9085iexeBJR2PaJThspMCMBJyNNne gZrB8p1rlGXy/xft7VJPhF/7p+8uBEUXb6PYDFs4AcM3QeCBeRNqOlkX0J/fATis ODjEOyjR9sHwSO5XSAiazBh/BH+VnFUOl2dSW3jbeowrioYCFy+6GJbfIZ41NMkr YmFlGkjx+Eu9Cr1V/VsX7KOgBPACTXtODJ4HMU3sYPL2kj3/8lU= =AWM3 -END PGP SIGNATURE-
Bug#1041431: ITP: rust-souper-ir -- library for manipulating Souper IR
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-souper-ir Version : 2.1.0 Upstream Contact: Nick Fitzgerald * URL : https://github.com/fitzgen/souper-ir * License : Apache-2.0 or Expat Programming Lang: Rust Description : library for manipulating Souper IR souper-ir provides AST types for parsing or generating Souper IR. It is a suitable building block either for writing a custom LHS extractor, or for translating learned optimizations into your own peephole optimizations pass. This package is needed by swc (bug#991761). It will be maintained in the collaborative debian section of salsan at https://salsa.debian.org/debian/rust-souper-ir - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS24p4ACgkQLHwxRsGg ASFoNg//X+yn+nyVrFlZQIqTuazhXwczwIV4e/PEE4YqsCY3Ms21cDe1X//s4mUZ IRV5N4GUUkmcmqN4CUxpkYp3vTpin8izkpa1tmAh5gG3WKMkA/5QY5NcroOcHLcK IoL/IUAVjB2w1/nItUEkKiNJnc+DqpRZEz66xUE7JuwK1VR3xc00kwwoJSCpQXJ2 LSDwR7xpct/t7Atua5/rzQlXsaW0fGORFuGFTvkaR1JuqnmKN8KgxbJ5KfHYel5B AaGn7z23boQ69clJGXBKwBNeTP/sqE/q9byPJRqtNGuUtqZ9dxfwWuMhI82WZv9z 6G83lNDw9r2OeBviNGiWsmC/9OEoMXT26wm3F9zWPZgWRUi/Q+ZRcpVAX77xykyv R7gzJ5oBSFoQJGq3bfkFhgiU/1/g1g/D3HN8uBZR/ODl50yTHnScAR9quc06SK7u Lzesj6ON4F8ZDc6oYSVrakvwxcwsIRw+kko0BB6+euuMJutzAwX8BbDi17t50w0m 0WhaMc+i6nH//aHwQ1VgkhV3PMZ4VhC2cgux2Bcnr4NdPuG1XbhBLnJpSWtsUeVV kEJd00cV6ZNddNHtoqz8TDfi5ukJM+YfgbWWrwCRdaM4YnT3HB++cBgL3Qzgqe+A BRgok4h+4oi0opbS6xzyEDEbXGA2lIL2mxhSiixT4MkmlFzwwkw= =Ul/b -END PGP SIGNATURE-
Bug#1041418: ITP: rust-slice-group-by -- iterators over groups in slices and strs
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-slice-group-by Version : 0.3.1 Upstream Contact: Clément Renault (Kerollmops) * URL : https://github.com/kerollmops/slice-group-by * License : Expat Programming Lang: Rust Description : iterators over groups in slices and strs slice-group-by is an implementation of the groupBy Haskell function, providing tools for efficiently iterating over `slice` and `str` by groups defined by a function that specifies if two elements are in the same group. This package is needed by swc (bug#991761). It will be maintained in the collaborative debian section of salsan at https://salsa.debian.org/debian/rust-slice-by-group - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS20pYACgkQLHwxRsGg ASEZnw//c5aQ3rBSG7lO+TAqSI36Z9s0X6Qm0igXKDtQS8Z3I38kDuMGB6nIFXh3 omM52+RT1RmrftP+/ijmx9qjjK3e99/XkWezzyKOQ/w6VV2nRgpKbwjo7joohspP 548xlwKDt8mi83OhbvF5yhPVSOVA4Cnw874KHanvJ2b1WMNGyShjMlD3x3k7f9q1 kUnL+V998+IUxITCXKHD/kVbowDYk5IagcGfKKWrGM+ZdjRD1pfYqmIY3XuEHX6t kIbgCHsa3qxtJcXF5GIBz5+B/Pt/CwGYzrDqjrqwMZfiu+5ChiYLIG3sdN7a1+aQ 5t2R7xS1TKFSza4TDlNH3+HZVm4eQ1C8acN/ZafyuapkL9V4lbRbQGiRKO/73bEi Lj+nHvtDIVTopD350vypEdOyGslq//jq7rInwfTe+x6ZYsSP3xqaGS+iOGfiFpKP 3dCzxVmZm8YqR2OMlRNsx0uvqTTGrEVwT/haWJ8uNXp5ovg/VeT7rOrTo74YVcG9 7H+UCjXMDOLsbotTf2FqCKWL673HjNEUt9FbAQ1lqyqHFk6QTtktIRpz4hh7Zx3Q WSZ/hcfUORXyDSu4nBJ0HkKUPAKs3wy90crU3J+XrttE7laAxmXVXzG6bA8PIw4a cE/v1/4uCpH8w1fZgQw8e2qGhr7lRPJsxQS0SoAlJ0r6etUP9OU= =RiOT -END PGP SIGNATURE-
Bug#1041417: ITP: rust-regalloc2 -- backtracking register allocator
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-regalloc2 Version : 0.9.1 Upstream Contact: Chris Fallin * URL : https://github.com/bytecodealliance/regalloc2 * License : Apache-2.0 with LLVM exception Programming Lang: Rust Description : backtracking register allocator regalloc2 is a register allocator that started life as, and is about 50% still, a port of IonMonkey's backtracking register allocator to Rust. In many regards, it has been generalized, optimized, and improved since the initial port. . In addition, it contains substantial amounts of testing infrastructure (fuzzing harnesses and checkers) that does not exist in the original IonMonkey allocator. This package is needed by swc (bug#991761). It will be maintained in the collaborative debian section of salsan at https://salsa.debian.org/debian/rust-regalloc2 - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS2zHcACgkQLHwxRsGg ASFRAA/7B0A4+Zm3LFQoPFLfv/uaqfkELXs1Fuf2eKgK/IwzR99U+ne2dNB4S1aF V0ZhF33WbidD63Em/WwNwENGYmeqUa/WUnxFrvEq45E/VyYUd0a3V+jYaGAsxEOA dZ/N7oLrdFcWaG4eF+K2+Xm5nQe7S7vNafVR2+WT69So9dLlht6gkvDYdM2QWS1u QxQ08vGgPD9qYWW3IVcvG/mTzL7MnU2PkN4CD17Lowz3pVqxqioEZoHNjxjsJdXC dhGfTE4a7B9CY8sq/8mBkaJqtOSL6VFKa26rCheMYfwg85XZQ0xS9G5ZiumFU7w9 yM1FPMR9s9YRrGm350wnWzhnKbjGbiyPqMZL79In9vVXak0AXkmUe/07Eii9budI vzaq8oPMDOfFV3R809q7I8qh3Riy27LrjPxXzB30/r2L0fGs7l6csqGuPll5NZ6O N0087VphdJoGUJw9Sro+4Dvs+vqqsmNKQ26H+5d8BWeQsfmu1MTD/iyBu4w+3GG1 3nbrMFpBR16eQ6gV4rYxBjTcocqGBPJU+BwgGs5wcQtwplIN25T0pGwoIz2ZhPUQ pl+5EQw4dMCPMWJlmS9HWcbz5bD2s/t1cHDGpw87Nh66JjV1n6sAMkqNkFtxirCD WTBN6RMFscwLD/7wrgS0Q/bSwNWe9IzbuuJZDUu1+INW7w+fPrk= =nXER -END PGP SIGNATURE-
Bug#1041318: ITP: rust-json-event-parser -- JSON event parser and serializer
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-json-event-parser Version : 0.1.1 Upstream Contact: Tpt * URL : https://github.com/oxigraph/json-event-parser * License : Apache-2.0 or Expat Programming Lang: Rust Description : JSON event parser and serializer JSON event parser is a simple streaming JSON parser and serializer implementation in Rust. . It does not aim to be the fastest or the more versatile JSON parser possible but to be an as simple as possible implementation. This package is needed for oxigraph (bug#996504). It will be maintained in the collaborative debian section of salsa, at https://salsa.debian.org/debian/rust-json-event-parser - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS1LsgACgkQLHwxRsGg ASGuZxAAnGaRse4xNrc1A8yia/ZGZPbilR93QiVzblYfKtAvPp7sMUkpvjPhkdP6 EEXdvcHUP72p/yQj6wmRzptLtDxNd6/K4V0DQpZj1wA11i3BJHiiX4udVqqBQlvQ FpCgMw28c4VzYW84JGAYEb7Dqsd85U8rZLdpSmaZ+eAIzeRAjfoldLKn7wfoxZKk iB/veI19T/oAHyRYnG1ptukLBexUvjxQxZczhr1/6e5Njk0glY1/oNLQ7ewv7NGS 1Pcislx9jEsxPmtxGEzBifoV/H+2lYvir3HqNEx6pWF4BqiUEFDTfaRPUiQ/PsTQ azbJNcZzSiRLKFw6dZzXqnAZgQCgicO4a8GEoBNDaRWlbe7PL9BidfshcOnKXX/i 4x943xCCOhXSGCTrbIW2nwM8etz9QRXn7zmqHjCAH2arFPjRCv3E4dABhO1J/lP/ sNnMwKNtljuAG++ucBkXaN0JYV4JSQGRoCocegDbjYQBOsDG7ARgEJyJBdPbBoIH PF6HVgWCCvhJ9V8sEFy2/aY26ycfUzwKst7Qz80V35A3wyZMTrHQHs0A+dAVRhU1 foxNCFRhUdO/4HDB7opVfyZ7hOuagRiv0ccxa/jKzMtduh6JMYQf291NyN08valq yMTE83L5588OnZv/Z+AcRZQbtPOQZqyrqEEBtFTyo9qCUjtbUrk= =oDlV -END PGP SIGNATURE-
Bug#1041316: ITP: rust-fast-rgb8 -- conversions between linear float and 8-bit sRGB
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-fast-rgb8 Version : 1.0.0 Upstream Contact: Thom Chiovoloni * URL : https://github.com/thomcc/fast-srgb8 * License : Apache-2.0 or CC0-1.0 or Expat Programming Lang: Rust Description : conversions between linear float and 8-bit sRGB fast-srgb8 is a small crate implementing fast conversion between linear float and 8-bit sRGB. This package is needed by rust-palette (bug#1040661). It will be maintained in the collaborative debian section of salsa, at https://salsa.debian.org/debian/rust-fast-rgb8 - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS1IicACgkQLHwxRsGg ASF8wA//XqNCLrPd3g8ONx4zDru4XJR1auMUhMXMQCuNTBjigGjy31saOnWLfBZi 7SzMTHKDQZ04XBBGGqVFll2ei873oYWzz1I0A3cMdMUb8RnGrwaOuync4CbNUF/y /GkVajpfF3tHvDYJ5BgEIoNAmqTBm3nVQs8/m0OPP94w0EnqaVs7pNLhBL0caD1t s26cSbDnb6GGwrUOdVzUqsI2Yr+TGsK6MBJ3ZUCFcvrndFyaMk46rf+3DRYGXTqq SoLl3Z5EDnMN8Dkzf9WvHZrOBmHP36MJO/htA4+RL+Vdak8BIdo7/qYZsvGFubyc sEYL1pdL1IZcmBLq5rfxXaBjsL7Tm+wyZjOr1EqHh8yE6CMZFP0B95VeqTY6Z27M 5Cgzm9Npz9PE9pZO4nmTMh0E3jDb2nC5wJvZdq7MDFa+b/XS33pHotQyG82H8bqR IlFycw1UDVajxALZ1KLS4kJvX082BeHVBLLlIxGjztPdM7bVzVDtQzEqK3p9F4gb RjZu2u62nrr0PUNOUM1qS73ZIoeD6XvTUx7D3o+XtKHemBgA8dg1l+28FL9pkECy 9EwR3BFT5E0P9+ThdYUZllPHoAFTohpFe7OHqYKvqkQBYohUVy5+1LAZiTi3KnYE 3fVx9AgTWu4L0ETFeyUFH22ViWifgGkR+ULUrbMmOFeUvN5m+XM= =uQ4K -END PGP SIGNATURE-
Bug#1041314: ITP: rust-safe-arch -- safe exposure of core::arch
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-safe-arch Version : 0.6.0 Upstream Contact: Daniel "Lokathor" Gee * URL : https://github.com/lokathor/safe_arch * License : Apache-2.0 or Expat or Zlib Programming Lang: Rust Description : safe exposure of core::arch safe-arch exposes arch-specific intrinsics as safe function. This package will be maintained in the collaborative debian section of Salsa, at https://salsa.debian.org/debian/rust-safe-arch - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS1Fz8ACgkQLHwxRsGg ASFGQhAAoFDnieRSR2yQgqE0lI/b8RIRSJkG2OFyFAmjcOIcjauBY9JA3u/id7fx OhfxjgTeGc99ca2SeRqCmv68bk59+2YePnbryGFdCNyB7daKqHvR3V7hT8b6ru6H Dv5S5mHG/ak86mEzIQa4alMPB0tZhVKFda/4tOHAR8ihmi1mnP5/j3iKSbjWNUPp /VPYjlkdirlVh7nSWGGGMhZER3AgTnOPsXFcRZODexrZdcnAUiqJA7KNFODrDAw9 LooxSTKJ4DZYso/NpYmzQZ2mbYbzbDShvwJv9eCnHUn9mPFIWxxD0heRVd7XFswS QN6MI/6G6IfkWrBOC9ZIurLEFf1B0GlEP0XnWDpRJjKtIVCnciKD0gS18g7M+Fei QNNhDCBJwZGoQov6i9EYaxc9ewzLQ6LX/zsHv77K/RtuINnNGfN9yXI+2kj6pHQC Y57NtKb7DWCv6zHYR7QT/UYQqca+WhbK8ia1BTKoyi7DoqZAozoO0BsOZ0GXGOQW 4csCiYQWr8u22OG4qI+W73NqXe7eek8TAmN/8W2gpeOnecbO6sMWIzd4Ya2QLecT cUskiTsNO/oeOdYa/sqeBDdvhejOsYofvX9BJwG48kjCAncQYQoyHgauyf3B/891 k1Vo7jAqo9MI3uVBgmsDhyp6Pn2M54DxZnBRJvvOWCXXnlIDoV4= =KED9 -END PGP SIGNATURE-
Bug#1041309: ITP: rust-wide -- wide data types
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-wide Version : 0.7.11 Upstream Contact: Daniel "Lokathor" Gee * URL : https://github.com/lokathor/wide * License : Apache-2.0 or Expat or Zlib Programming Lang: Rust Description : wide data types wide provides portable "wide" data types that do their best to be SIMD when possible. This package is needed by rust-palette (bug#1040661). It will be maintained in the collaborative debian section of Salsa, at https://salsa.debian.org/debian/rust-wide - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS1DZQACgkQLHwxRsGg ASEveQ/+MmxDgN+d4h80E+OV6h1P9s8Fz0W/3aeyHUBABhldBI2UvaTz16UYsdWl x+MjPHAvJt7fFGdItcTksSoPElKZQLqj9mJUc8zMRD8faOxNfHt/HMz2XFNyjuhZ kQx09lNGI/58POZvXcP4G/cuSKnZwV3AM3HdS/VKJpiJrnB1buBr9jPKeKoNr88s x5A4AhWIWcpb0u5rvfHOk1sR3fHMIVL0+DIjFCnmmVV3RbWoUI8e7TqZNu5OnBDf IlbNNUxlqv0Nt+bo1fUUQVK6t6rR80tGG3mOxa7j6PSuW4wjbOT6VJJ8BWVv6plQ d/43MVpyEuCbRHC7eidI601G9s1vCuzQuUs3PK2elJKRPat2D0Uk7aKplcQHldz8 hMb5wEVZq62gXHvd2kE98ZCzY9bXGWygtXv6KelkC48cQdKFXF0HrYcvG8Ufvepx 2CYW5LEJj7zPbLjPEqY2MJ4hRwmdz8C2JhTm2+5xYN/+kRo+ymrzbxNIKQ5L8Ggh TclnbKFQEO0GDwOIOZuYo8ofucMAKUOekxFm53C15XLMeLmOda+3dq4oI9m6wk4F heCJu2p3szB2i+wBGIMxNFye6IW0dg3YZS8c7AEOzk/0I651vh3JdrAALnf5wMiX 1LmKZscwUDl1AZ6o+Ayt2ekiGq/RbemLD9GQf1bEWrComIEZs14= =3RiD -END PGP SIGNATURE-
Bug#1041273: ITP: rust-rustls-webpki -- web PKI X.509 certificate verification
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-rustls-webpki Version : 0.101.1 Upstream Contact: https://github.com/rustls/webpki/issues * URL : https://github.com/rustls/webpki * License : ISC Programming Lang: Rust Description : web PKI X.509 certificate verification rustls-webpki is a library that validates Web PKI (TLS/SSL) certificates. It's used by Rustls to handle certificate-related tasks required for implementing TLS clients and servers. . rustls-webpki is written in Rust and uses ring for cryptographic operations and low-level parsing. . This is a fork of the webpki project which adds a number of features required by the rustls project. . Rustls is a modern TLS library written in Rust. . This package contains the source for the Rust rustls-webpki crate, for use with cargo and dh-cargo. This package is needed for newer releases of package rust-rustls. It will be maintained in the collaborative debian section of salsa, at https://salsa.debian.org/debian/rust-rustls-webpki - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS0K0YACgkQLHwxRsGg ASGn3A/7BP9I756uFtYaFBjDncLCceCNvtgO9QY+J62IdWaXeg5hj55pKDLrMlFb GS192qei2/y+sEdntXpfv4lgelw2rS9K9F4U3mPMWaiPfsYZSmdER4YwLF4Qlo9H I5igYRC+vF2VvprNGqTfzErm4hC8OfMTrlPiBV9SM1Dpn7zUTx2XkSpbv22shJ70 b7S93XfOwrfxEeZXSlkm1Pft5uX9XiklmPAabptbec1gDI0ZFGtDMsBvoiMnVVe8 hOhj04YD0Oyv6ky97drRlpECbbdgp/OsLkgqgK1GW9ZWQDf0wi5x2taUIKF3y6fs f51MlKVMNUG8aendet+Y0lHFGVjzDnqFc39nb2SGloIlCHnkWCLvjjWlxNwhyGwN 0by/hh27Acta01nAJAa/5ArN0hjxFTu/AC3oZR1dRsadXxZZnEVRquz/JHTlrQlc KeWB8PM1GcdqasKFhH2QNp48x/voo7004Oiq5TfjlBuv1gD3CqDeSZr26+RrhPAI CuJPTtQTUiZzC7xjPb1jQuf5shEyHTt/e96aVK+RNUAHm66NUf2F79mep042wd+P c/mmikCPt0p14mkNPTagstB+Bjb2sUdY6bzqqViRZEDakMO7/FNOjK6KucpqAH0C kQx6PRgIA0YrgjdJDGqaXDApKL8i8uOvdBLUlzzNCphmfrbpZnw= =Bfnz -END PGP SIGNATURE-
Re: virtual packages for Ada libraries
Quoting Jonas Smedegaard (2023-07-15 10:05:24) > Quoting Nicolas Boulenguez (2023-07-12 15:55:09) > > The Ada maintainers are considering a new naming scheme for -dev packages, > > where > > libada-foo-dev Provides: libada-foo-dev-HASH. > > source packages Build-Depend: libada-foo-dev > > binary -dev packages Depend: libada-foo-dev-HASH > > The intent is similar to the one of shared object versions, but the > > name changes often (for example, with the architecture) and is > > computed, so virtual packages seem more appropriate. > > > > Policy 3.6 does not disapprove: > > ... should not use virtual package names (except privately, > > amongst a cooperating group of packages) unless they have been > > agreed upon and appear in the list of virtual package names. > > However politeness recommends to ask for objections before polluting > > the package namespace. > > > > Haskell and Ocaml apparently use a similar scheme. > > I have no objections to this - it sounds like a good approach. > > Just want to point out that experience from Rust packaging indicates > that general Debian tooling does a weaker job at dependency resolving > for vritual packages, which (for Rust libraries) causes breakages of > reverse dependencies, and may even (not quite sure) lead to breakage of > testing due to libraries with unsatisfied (dependencies) migrating. I now recall: The Rust library packages wreaking havoc by prematurely entering testing is (at least partly) due to the Rust team choosing to flag all(!) autopkgtests as flaky, so not really a concern for other teams (read: just don't take inspiration from that particular pattern). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
