Re: Porterbox - impossible efficient debugging?
Le mardi 13 août 2024 à 15:54 +0500, Andrey Rakhmatullin a écrit : > On Tue, Aug 13, 2024 at 12:15:22PM +0200, > julien.pu...@gmail.com wrote: > > And of course, this is where I came to my wits' end: I can compile > > the > > new elpi successfully... but I have no way to install this new elpi > > binary packages in the schroot to test it against different coq- > > elpi! > > Yes, the usual recommendations are "unpack and try pointing to it via > stuff like LD_LIBRARY_PATH, hopefully such stuff exists for your > case". It doesn't: it's a mix of languages. C, OCaml, elpi and Coq I would say. > Consider using local qemu chroots instead. > I'd like a one-page easy-to-use tutorial on this. In fact, my question/proposition was to have scripts making it trivial to use. > > dd-cross-schroot-cmd -s $sessionid -a $targetarch apt-get install > > ./*foo*_3.14-159_$targetarch.deb > > This still runs random code as root. > I don't think running random code as root in a virtual environment I'm going to delete before the end of the day is a security issue. Cheers, J.Puydt
Porterbox - impossible efficient debugging?
Hi, there was a thread "Any way to install packages+run autopkgtests on porterbox machines?" in march already. Let me add another problematic use case. I'm trying to work on bug #1078549 about the coq-elpi package on ppc64el. With platti.debian.org I could confirm the failure with the package currently in Debian, and see that it would worsen with the next release of coq-elpi (!). So the next step to investigate the matter was to reproduce it with the latest upstream of its dependency elpi (which I suspect of being the culprit even though its successful compilation with its extensive compile-time testing says otherwise). And of course, this is where I came to my wits' end: I can compile the new elpi successfully... but I have no way to install this new elpi binary packages in the schroot to test it against different coq-elpi! I'm quite fond of the single-page just-follow-the-steps tutorial: https://dsa.debian.org/doc/schroot/ hence my dream is to be able to do something like the following to get not only a cross-compilation but also cross-running through whatever virtual system (say provided by a dd-cross-schroot package) : echo -n "Target arch: " && read targetarch && echo -n "Session ID: " && read sessionid && dd-cross-schroot-setup - s $sessionid -a $targetarch /* much, much work would be done here */ dd-cross-schroot-cmd -s $sessionid -a $targetarch apt-get build-dep foo dd-cross-schroot-run -s $sessionid -a $targetarch /* do what needs done for foo on the target architecture */ dd-cross-schroot-cmd -s $sessionid -a $targetarch apt-get install ./*foo*_3.14-159_$targetarch.deb dd-cross-schroot-cmd -s $sessionid -a $targetarch apt-get build-dep bar /* installation of its dep foo is hence covered by a local package */ dd-cross-schroot-run -s $sessionid -a $targetarch /* do what I needs done for bar on the target architecture */ dd-cross-schroot-clean -s $sessionid -a $targetarch Of course, that wouldn't be as good as an actual box of the right architecture, but it would definitely help getting many problems solved. As you may have noticed from the above I'm quite clueless on how schroot and cross-compilation work - and to be honest, I'd like to stay so as I have other itches to scratch and hopefully other areas of expertise - but I'm hopeful others have the competence and the will to provide solutions. Cheers, J.Puydt
Re: ifupdown maintenance
Hi,
Julien here, maintainer and main contributor of ifupdown2 since 2016.
> Since Cumulus has been bought by Nvidia, things have changed and
> development of ifupdown2 is now done behind closed doors.
NVIDIA acquisition of Cumulus didn't change anything for ifupdown2. The team
stayed the same and the development cycle stayed the same as well, we always
had a 'private' and 'public' repo.
Admittedly things have been way slower, since the acquisition we have been very
busy and over the past few months I have been dealing with a lot of personal
stuff. So, unfortunately the delays are compounding.
We are committed to upstreaming our changes and accepting community
contributions.
Like I said on github, some of the changes are made for Cumulus and are
breaking debian's default behavior, so extra work is sometimes required before
upstreaming changes.
Back in 2016, with Cumulus, we had the goal and ambition to become the default
debian network manager, but we realized that the python dependency would be a
blocker, so we don't have that goal anymore. And we are happy with the way
things are now, supporting our community users and customers.
Julien.
From: Santiago Ruano Rincón
Sent: Thursday, July 11, 2024 2:08 PM
To: Daniel Gröber
Cc: Martin-Éric Racine; debian-devel@lists.debian.org;
ifupd...@packages.debian.org; ifupdo...@packages.debian.org;
ifupdown...@packages.debian.org
Subject: Re: ifupdown maintenance
El 09/07/24 a las 11:25, Daniel Gröber escribió:
> Hi Santiago,
>
> On Mon, Jul 08, 2024 at 12:23:16PM -0300, Santiago Ruano Rincón wrote:
> > > > Santiago, how do you feel about ifupdown's future maintainability and
> > > > feature development? I honestly never looked into why people started
> > > > writing ifupdown replacements. I had my own gripes with it so I never
> > > > questioned it but I'm happy to hear why we should all rally around it.
> > >
> > > I've long wondered how we ended up with so many implementations. Team
> > > maintenance of just one implementation would make more sense.
> > >
> > > > For me the reason to work on ifupdown-ng is that it has a better core
> > > > design, clean&modern code, an active upstream community, a ***test
> > > > suite***
> >
> > I fully acknowledge this. After trying to fix some of the ifupdown bugs
> > but hitting some design issues,
>
> Can you elaborate on that point? What are the sort of issues you run into
> with the traditional ifupdown design and/or it's maintenance.
For example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804396.
Fixing it is not trivial.
> > I think it makes more sense to focus all
> > the efforts in just one of the implementations, and since ifupdown-ng
> > has all the above mentioned advantages, I'd would be in favor of
> > replacing ifupdown by ifupdown-ng...
>
> Good to hear.
>
> From the looks of the BTS page I feel like part of the burdon of
> maintaining ifupdown is that people just default to reporting any
> networking issues there, is that something you see a lot?
No, not really.
> Perhaps we should have a debian-networking mailing list as Maintainer to be
> able to load-share the user-support better?
I'd happy with that!
> > > > and the potential to fully replace ifupdown without breaking anyone's
> > > > system doing it. Full compatibility is not there yet. I'm working on it,
> > > > see [1] but I'm optimistic so far.
> > > >
> > > > [1]: https://github.com/ifupdown-ng/ifupdown-ng/issues/247
> > >
> > > Noted.
> >
> > ... but it would be *great* to make ifupdown-ng a drop-in replacement
> > first.
>
> Naturally.
>
> It is pretty close though. The remaining issues I know about are documented
> in the GH issue: the locking protocol is sligtly suboptimal (and more
> importantly for interop: different), ifstate file is separate and interface
> renaming ("rename" statanza) isn't supported. I didn't even know that last
> one existed, does anyone use those?
Yes, I am aware there are users of the rename stanza.
> If you're on-board with transitioning to -ng that should make the ifstate
> compat pretty easy since we can freeze the old format and behaviour.
>
> I haven't thrown -ng at a large legacy setup in anger yet (since I don't
> have any), but for regular desktop usage with some mildly custom stuff in
> /etc/network/interfaces I hardly notice which ifupdown* I have installed.
>
> Note: For testing you have to keep in mind to (tranditional) ifdown the
> ifaces you want to test first since the ifstate is still disjoint
> currently.
ACK.
[snip]
Cheers,
-- Santiago
Re: finally end single-person maintainership
Hi Le lun. 8 avr. 2024, 14:45, Simon Richter a écrit : > The web interface presented by salsa also does not have the necessary > data<->metadata filters to provide an actual insight into what is really > happening in the repository. > It's been several times already some people complain about salsa because of its web interface. I only use salsa's git. That begs two questions: - What do I miss by not using the web interface? - What does that web interface have that people don't like? Cheers, J.Puydt >
Re: 64-bit time_t transition in progress
Le samedi 03 février 2024 à 10:16 +0100, julien.pu...@gmail.com a écrit : > > About flint: if you need anything done, don't hesitate to ask me. > In fact multi-arch is broken for flint and I can probably fix it: would a new upload go in your way or on the contrary help you ? [I'll refrain any move until you confirm I won't break your effort.] Cheers, J.Puydt
Re: 64-bit time_t transition in progress
Hi, Le vendredi 02 février 2024 à 08:21 -0800, Steve Langasek a écrit : > The packages previously not reported are: > > flint > flint-arb About flint: if you need anything done, don't hesitate to ask me. About flint-arb: its code has been merged into flint, so it's abandoned upstream. The package is in FTBFS... only the sagemath package prevents its removal. Don't get blocked by this mess, you already have enough on your plate. Cheers, J.Puydt
Re: Potential MBF: packages failing to build twice in a row
Le dimanche 26 novembre 2023 à 16:34 +0100, Matthijs Kooijman a écrit : > Hi, > > I've also gotten a bunch of bug reports from this MBF. Some were easy > to > fix, but there is one subtype of this issue where I think the > commonly > given advice and policy currently contradict. > > This concerns files that: > - are shipped in the upstream tarball > - are regenerated (with slightly different contents) during the > build > > These are essentially build products prebuilt by upstream. > > > A commonly recommended approach to fix this, and also the only > approach > listed on the page linked by the bug report [1], is to add such files > to > the extend-diff-ignore dpkg-source option. > > [1]: https://wiki.debian.org/qa.debian.org/FTBFS/DoubleBuild > > AFAICS this causes dpkg-source to simply ignore changes in this file, > preventing dpkg-source from raising an error due to such > modifications. > > However, the policy 4.9 says: > > clean (required) > This must undo any effects that the build and binary targets > may > have had, except that it should leave alone any output files > created in the parent directory by a run of a binary target. > > So this does not say "dpkg-source must still work after the build > + clean", it says that *any* effects of the build must be undone, > which > is stronger. > > So AFAICS the extend-diff-ignore fix does not comply with the policy > in > its current form. Also, it means that two subsequent builds will not > start from an identical source tree, which *could* hurt > reproducibility > (though in practice these files will be regenerated, so the build > *should* be identical anyway). > The way I handled such cases in some of my packages was: - in the build target - but before actually building - detect if foo.orig exists, and if it doesn't, copy foo to foo.orig ; - in the clean target, detect if foo.orig exists, and if it does, move it to foo. That way even if foo gets modified during the build, the clean target puts it back like it was. Unelegant, annoying, but it does the trick... Cheers, JP
Re: allow missing description fields and empty long descriptions for Rust/etc packages?
Hi Le mer. 20 sept. 2023, 04:11, Paul Wise a écrit : > > 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? > Yes, definitely. I know it is a pain to write those texts, but they are the most user-bound part of packaging, and Debian is about user service. I would be very surprised if the required information weren't available somewhere in each and every rust package. Perhaps the ecosystem doesn't have it in a specific and easy to extract automatically place. Perhaps the packaging tools for rust crates don't know how to get it. But those are no good reasons to stop looking for it for our users' benefit. I would go as far as to say: open an upstream issue if someone just pushed a pile of code out the door without even the shortest description! Cheers, J.Puydt >
Re: versioned dependencies between -dev packages
Hi, Le sam. 15 juil. 2023, 17:36, Nicolas Boulenguez a écrit : > Julien Puydt > > - Indeed this is quite fragile; I have two scripts for Coq packages [1]: > > one to tell me about the deps (I give it which package I have to upgrade > > and it gives the list of affected packages by pass) and the other to > > generate the migration script (I give it the list of new packages and > their > > new version and it generates what I have to tell FTP masters), but it's > > still pretty painful. > > Perhaps if there are several such instances of such package > > dependency networks we should try to find a common and efficient > > solution Debian-wide ? > > Ada updates require the NEW queue and or manual Break/Replaces. > Ocaml updates require passes and migration scripts. > Rust updates encounter inconsistent states. > Let us steal as many ideas as possible from each other (but not > necessarily on -devel). > > https://wiki.debian.org/LanguageVersionedDevPackages Well -devel is also where we can expect people to make valuable observations and provide useful ideas. For the Coq packages: - good: packages become uninstallable but are not broken on users' systems; - bad: needs too much human planning (prepare ben script, open transition bug...); - bad: part of the deps aren't computed but handwritten (see dh-coq's tools/coq_packages.py); - etc J.Puydt
Re: virtual packages for Ada libraries
Hi Le sam. 15 juil. 2023, 10:05, Jonas Smedegaard a écrit : > 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. Two remarks: - Since OCaml used this approach, I also implemented something similar for Coq packages ; - Indeed this is quite fragile; I have two scripts for Coq packages [1]: one to tell me about the deps (I give it which package I have to upgrade and it gives the list of affected packages by pass) and the other to generate the migration script (I give it the list of new packages and their new version and it generates what I have to tell FTP masters), but it's still pretty painful. Perhaps if there are several such instances of such package dependency networks we should try to find a common and efficient solution Debian-wide ? Cheers, J.Puydt [1] https://tracker.debian.org/pkg/dh-coq
Bug#1038692: ITP: ppx-cold -- Provide the @cold annotation for OCaml
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-Cc: debian-devel@lists.debian.org, Debian OCaml Maintainers , jpu...@debian.org * Package name: ppx-cold Version : 0.16.0 Upstream Contact: opensource-conta...@janestreet.com * URL : https://github.com/janestreet/ppx_cold * License : expat Programming Lang: OCaml Description : Provide the @cold annotation for OCaml This package provides the @cold annotation to program in OCaml to disable a closure optimisation. It is a depend of a depend of a depend of a depend for a new version of an existing package in the OCaml team. I plan to maintain this package there along with the whole line of deps. Cheers, J.Puydt
Bug#1033940: ITP: sphinx-lint -- sphinx-lint is a reStructuredText linter for sphinx-doc
Package: wnpp Severity: wishlist Owner: Julien Palard X-Debbugs-Cc: debian-devel@lists.debian.org, jul...@palard.fr * Package name: sphinx-lint Version : 0.6.7 Upstream Contact: Julien Palard * URL : https://sphinx-contrib/sphinx-lint/ * License : Python Software Foundation Licence Version 2 Programming Lang: Python Description : sphinx-lint is a reStructuredText linter for sphinx-doc sphinx-lint search for errors in documentation written in reStructuredText for Sphinx. It's the child of cpython's rstlint.py used for years in the cpython repository. It's used by cpython on multiple repos (main doc, peps, devguide, documentation translations, ...), pandas, the sphinx-doc documentation, sympy and a few other projects. I'll gladly package it myself, or help to do so, but I'll definitely need guidance on the process (last time I packaged something for Debian was 10 years ago, I packaged a single package (logtop), so my memory won't help much here). I'm already a member of the Python team (IIRC), but the link in the page [1]: « For the full list, see https://salsa.debian.org/groups/python-team/modules/-/group_members » gives a 404 ☹. [1]: https://wiki.debian.org/Teams/PythonTeam
Re: Restart rsyslog only once after few packages are upgraded
Le mercredi 26 octobre 2022 à 11:49 +0200, Jędrzej Dudkiewicz a écrit : > > in its postinstall script. As this causes rsyslog to be restarted a > few times in a row it sometimes results in rsyslog not functioning. > High-severity issue right there: restarting should just work no matter what. Instead of trying to limit the number of restarts, I would try to make them just work! Cheers, J.Puydt
Re: Submitting Patches
Le vendredi 21 octobre 2022 à 16:47 +1100, Phillip Smith a écrit : > On Fri, 21 Oct 2022 at 16:30, Julien Puydt > wrote: > > In general they are ; just attach them to a bug report against the > > package. > > Thanks! Is there a (recommended) tool to do this? I presume the > recommended `bugreport` tool isn't appropriate for sending patches as > opposed to actual bugs? I don't seem to be able to get `git > send-email` to cooperate with the "Package" header that is required > for submitting via email. "reportbug" should do what you want as far as I know... Cheers, J.Puydt
Re: Submitting Patches
Hi Le ven. 21 oct. 2022 à 07:28, Phillip Smith a écrit : > Apologies if this is the wrong place to be asking this, but my > Google-fu isn't guiding me to any results... Where/How do I submit > patches for Debian packages? > > I have a small improvement for the iptables-persistent package; I > cloned the repo and made a patch (attached) on a branch, but it > appears the public aren't welcome to create accounts on > salsa.debian.org in order to create merge requests? > > Are patches even welcome? > In general they are ; just attach them to a bug report against the package. Thanks for your interest and contribution, J.Puydt >
Re: Firmware GR result - what happens next?
On Thu, Oct 13, 2022 at 05:17:59PM +0200, Tobias Frost wrote: > On Thu, Oct 13, 2022 at 05:08:57PM +0200, Julien Cristau wrote: > > On Thu, Oct 06, 2022 at 05:13:22PM +0200, Tobias Frost wrote: > > > Maybe and idea would to do something like isa-support does for e.g > > > sseX-support > > > on CPUs that does not have that feature: It fails on installation with an > > > debconf message, IIRC. > > > So that would allow something like "new package" | > > > "you-need-to-enable-nonfree-firmware-reminder-package" > > > > > Failing on installation is a terrible user experience, let's not, pretty > > please. > > I'd prefer failing loudly to failing silently. > I'd prefer if we could make things work vs making things fail, however loudly. Cheers, Julien
Re: Firmware GR result - what happens next?
On Thu, Oct 06, 2022 at 05:13:22PM +0200, Tobias Frost wrote: > Maybe and idea would to do something like isa-support does for e.g > sseX-support > on CPUs that does not have that feature: It fails on installation with an > debconf message, IIRC. > So that would allow something like "new package" | > "you-need-to-enable-nonfree-firmware-reminder-package" > Failing on installation is a terrible user experience, let's not, pretty please. Cheers, Julien
Re: Firmware GR result - what happens next?
On Thu, Oct 6, 2022 at 15:45:25 +0100, Steve McIntyre wrote: > On Wed, Oct 05, 2022 at 10:11:27PM +0200, Julien Cristau wrote: > >On Sun, Oct 02, 2022 at 08:21:31PM +0100, Steve McIntyre wrote: > >> On Sun, Oct 02, 2022 at 11:08:47AM -0400, Michael Stone wrote: > >> >On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote: > >> >> On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote: > >> >> > What's the plan for upgraded systems with an existing > >> >> > /etc/apt/sources.list. > >> >> > Will the new n-f-f section added on upgrades automatically(if > >> >> > non-free was > >> >> > enabled before)? > >> >> > >> >> So this is the one bit that I don't think we currently have a good > >> >> answer for. We've never had a specific script to run on upgrades (like > >> >> Ubuntu do), so this kind of potentially breaking change doesn't really > >> >> have an obvious place to be fixed. > >> > > >> >Is there a reason to not continue to make the packages available in > >> >non-free? > >> >I don't see a reason to force any change on existing systems. > >> > >> Two things: > >> > >> 1. I'm worried what bugs we might expose by having packages be in two > >> components at once. > >> 2. I really don't like the idea of leaving two different > >> configurations in the wild; it'll confuse people and is more > >> likely to cause issues in the future IMHO. > >> > >> Plus, as Shengjing Zhu points out: we already expect people to manage > >> the sources.list anyway on upgrades. > >> > >I think in the absence of a release upgrade script (which I very much > >doubt will happen, and be tested, and we can rely will be used, for > >bookworm), Michael's suggestion seems like a reasonable way forward. I > >imagine we'll need to patch dak to allow that, but it seems like it > >should be tractable? > > I'm also worried what effect this will have on other tools that have > to grok the archive (mirror tools, debian-cd, etc.). I'm not going to > try and veto having things in more than one component, but (ugh!) I > really think it's ugly. Actually, I think I'd much prefer Santiago's > idea: > > > Couldn't we handle this via transitional firware* non-free packages, > > that depend on bookworm non-free-firmware packages? > > We'd need to add some transitional binary packages for the small > number of n-f-f source packages. That way people would get errors from > apt if they don't read our warnings and update. Maybe this is a way > forward? > I don't think that will work well, the packages will likely just be held at the old version if the new ones are uninstallable because the new component isn't enabled. Cheers, Julien
Re: Firmware GR result - what happens next?
On Sun, Oct 02, 2022 at 08:21:31PM +0100, Steve McIntyre wrote: > On Sun, Oct 02, 2022 at 11:08:47AM -0400, Michael Stone wrote: > >On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote: > >> On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote: > >> > What's the plan for upgraded systems with an existing > >> > /etc/apt/sources.list. > >> > Will the new n-f-f section added on upgrades automatically(if non-free > >> > was > >> > enabled before)? > >> > >> So this is the one bit that I don't think we currently have a good > >> answer for. We've never had a specific script to run on upgrades (like > >> Ubuntu do), so this kind of potentially breaking change doesn't really > >> have an obvious place to be fixed. > > > >Is there a reason to not continue to make the packages available in non-free? > >I don't see a reason to force any change on existing systems. > > Two things: > > 1. I'm worried what bugs we might expose by having packages be in two > components at once. > 2. I really don't like the idea of leaving two different > configurations in the wild; it'll confuse people and is more > likely to cause issues in the future IMHO. > > Plus, as Shengjing Zhu points out: we already expect people to manage > the sources.list anyway on upgrades. > I think in the absence of a release upgrade script (which I very much doubt will happen, and be tested, and we can rely will be used, for bookworm), Michael's suggestion seems like a reasonable way forward. I imagine we'll need to patch dak to allow that, but it seems like it should be tractable? Cheers, Julien
Bug#1021300: ITP: ocaml-uucp -- access properties of Unicode characters
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-Cc: debian-devel@lists.debian.org, jpu...@debian.org, debian-ocaml-ma...@lists.debian.org * Package name: ocaml-uucp Version : 15.0.0 Upstream Author : Daniel Bünzli * URL : https://erratique.ch/software/uucp * License : ISC Programming Lang: OCaml Description : access properties of Unicode characters This low-deps library gives access to properties of Unicode characters of the Unicode character database. It is a dep of a new dep for ocaml-cohttp. I plan to maintain it within the Debian OCaml Maintainers team. Cheers, J.Puydt
Bug#1021294: ITP: ocaml-uunf -- Unicode text normalization form library
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-Cc: debian-devel@lists.debian.org, jpu...@debian.org, debian-ocaml-ma...@lists.debian.org * Package name: ocaml-uunf Version : 15.0.0 Upstream Author : Daniel Bünzli * URL : https://erratique.ch/software/uunf/ * License : ISC Programming Lang: OCaml Description : Unicode text normalization form library Library to normalize Unicode text, supporting all forms. It is independent of IO mechanism or Unicode text data structure, and can process text without a complete in-memory representation. It is a dep of a new dep for ocaml-cohttp. I plan to maintain it within the Debian OCaml Maintainers team. Cheers, J.Puydt
Bug#1021293: ITP: ocaml-uucd -- decode data on Unicode characters off XML
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-Cc: debian-devel@lists.debian.org, jpu...@debian.org, debian-ocaml-ma...@lists.debian.org * Package name: ocaml-uucd Version : 15.0.0 Upstream Author : Daniel Bünzli * URL : https://erratique.ch/software/uucd * License : ISC Programming Lang: OCaml Description : decode data on Unicode characters off XML This OCaml module decodes data from the Unicode character database from their XML representation, to provide high-level access so that efficient representations can be extracted. It's a dep for a new dep for ocaml-cohttp ; I plan to maintain it within the Debian OCaml Maintainers team. Cheers, J.Puydt
Bug#1021269: ITP: ocaml-afl-persistent -- use afl-fuzz in persistent mode
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-Cc: debian-devel@lists.debian.org, jpu...@debian.org, debian-ocaml-ma...@lists.debian.org * Package name: ocaml-afl-persistent Version : 1.3 Upstream Author : Stephen Dolan * URL : https://github.com/stedolan/ocaml-afl-persistent * License : MIT Programming Lang: OCaml Description : use afl-fuzz in persistent mode Makes it possible to run the afl-fuzz provided by the OCaml compiler in persistent mode. I plan to maintain it within the Debian OCaml Maintainers team ; it's a dep for a new dep of ocaml-cohttp. Cheers, J.Puydt
Bug#1021246: ITP: crowbar -- library to fuzz-test code
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-Cc: debian-devel@lists.debian.org, jpu...@debian.org, debian-ocaml-ma...@lists.debian.org * Package name: crowbar Version : 0.2.1 Upstream Author : Stephen Dolan * URL : https://github.com/stedolan/crowbar * License : Expat Programming Lang: OCaml Description : library to fuzz-test code It combines the QuickCheck-style property-based testing and the bug-finding efficiency of afl-fuzz. It's a new depend for ocaml-cohttp, and will probably comes with its own deps itself. I plan to maintain it within the Debian OCaml Maintainers team. Cheers, J.Puydt
Re: packages expected to fail on some archs
Hi Le lun. 26 sept. 2022 à 23:42, Adrian Bunk a écrit : > > If we limit the problem to avoiding build failures in cases that > upstream does not support, there would be the trivial solution of > having a package ship Provides like: > - architecture-is-64bit > - architecture-is-32bit > - architecture-is-little-endian > - architecture-is-big-endian > - architecture-has-64bit-timet > -... > > Build-Depends: architecture-is-64bit, architecture-is-little-endian,... > would be a package that only supports 64bit little endian architectures, > and that would never be attempted to build on 32bit or big endian > architectures. > > The buildd page would then show for i386: > mypackage build-depends on missing: > - architecture-is-64bit > > Not building a source package on one specific architecture could already > today be achieved with: > Build-Depends: package-is-broken-on-ppc64el [ppc64el],... > > This might not be the most elegant solution, but it should be sufficient > to solve the problem in this thread and it does not require any tool > changes. > I find it both simple and elegant -- and it's probably pretty efficient too. Perhaps there should be a conventional naming scheme for such virtual packages ; say deb-missing-feature, deb-unsupported-architecture or some such? J.Puydt >
Re: Q: uscan with GitHub
Hi, Le lundi 19 septembre 2022 à 20:50 +0900, Hideki Yamane a écrit : > > Recent changes in GitHub releases pages, I cannot check upstream > version with uscan. How do you deal with it? It's not that recent ; here is a working example: version=4 opts="\ dversionmangle=s/\+dfsg.*$//,\ filenamemangle=s/.+\/[vV]?(\d\S+)\.tar\.gz/coq-$1\.tar\.gz/,\ repack,repacksuffix=+dfsg,\ " \ https://github.com/coq/coq/tags .*/[vV]?(\d[^\s+]+)\.tar\.gz Cheers, J.Puydt
Re: Automatic trimming of changelogs in binary packages
Le vendredi 19 août 2022 à 09:04 +0200, Fabio Fantoni a écrit : > Il 19/08/2022 03:01, Paul Wise ha scritto: > > On Thu, 2022-08-18 at 21:18 +0200, Gioele Barabucci wrote: > > > > > Does anybody have objective objections against activating > > > automatic > > > changelog trimming in binary packages? > > Before we consider enabling this by default, first we need a way > > for > > `apt changelog` to download the full changelog rather than loading > > the > > changelog from /usr/share/doc in the currently installed package. > > > > Otherwise people who want to look at the full changelog for the > > currently installed version of the package will have no easy way to > > do > > so. They will have to manually find it instead, which isn't exactly > > an > > easy process if you do not know where the changelogs are stored > > online. > > > Hi, I also used the changelog many times both in the packages I > maintain > and in the one I only use, in some cases a very old changelog entries > was needed. As long as "apt-get source" gives the whole d/changelog as well as d/rules, d/control and everything, I think this objection is out. Why put rarely-used information in each and every installation of our _users_? Cheers, J.Puydt
Re: Coq packages in Debian : difficult transitions
Hi,
Le lundi 01 août 2022 à 14:20 +0200, Joachim Breitner a écrit :
>
> it looks like you re-created the setup that the Haskell and Ocaml
> packages use, with the provides/depends and hashes.
>
Yes, dh-ocaml was a great help. I learned Perl to write dh-coq...
> We have a tool that produces a file with the necessary commands to
> pass to wanna-build, see for example in
> https://people.debian.org/~iliastsi/binNMUs-haskell.txt
>
> I used to produce a file like this for Ocaml, but it’s gone since I
> disabled my account. It’s configured via a simple regex,
> libghc-(.*)-dev-([0-9.]+)-([0-9a-f]{5})
> in the case of Ocaml.
>
> The source code is at
> https://salsa.debian.org/haskell-team/tools/-/tree/master/binnmus
>
> It may be useful to you too
The source code is very complex, and it looks like it can get the
hashes of the new packages -- something I'm incapable of doing! Indeed
that would mean building the whole stack on all architectures so the
computations happen. Indeed the hashes I have are arch-dependent...
I tried to write a simpler version, which might still be valuable ;
here is the wanna-build script I would get if I wanted to upload coq-
elpi 1.15.5-1 to unstable:
./wanna-build.py coq-elpi 1.15.5-1
nmu coq-hierarchy-builder_1.3.0-1 . ANY . -m 'Rebuild due to new coq-
elpi 1.15.5-1'
dw coq-hierarchy-builder_1.3.0-1 . ANY . -m 'coq-elpi => 1.15.5-1'
nmu mathcomp-algebra-tactics_1.0.0-6+b1 . ANY . -m 'Rebuild due to new
coq-elpi 1.15.5-1'
dw mathcomp-algebra-tactics_1.0.0-6+b1 . ANY . -m 'coq-elpi => 1.15.5-
1'
nmu mathcomp-analysis_0.5.2-2 . ANY . -m 'Rebuild due to new coq-elpi
1.15.5-1'
dw mathcomp-analysis_0.5.2-2 . ANY . -m 'coq-elpi => 1.15.5-1'
dw mathcomp-analysis_0.5.2-2 . ANY . -m 'coq-hierarchy-builder =>
1.3.0-1+b1'
does that look correct?
How are automatic transitions generated? It would probably be much more
efficient if I could provide scripts to automatically provide
transition scripts such as above: they would only need to change when
the list of Coq-related packages changes.
Cheers,
J.Puydt
Re: Coq packages in Debian : difficult transitions
Hi,
Le lundi 01 août 2022 à 14:20 +0200, Joachim Breitner a écrit :
>
> Am Sonntag, dem 31.07.2022 um 12:33 +0200 schrieb
> julien.pu...@gmail.com:
> > I have a little script that tells me the following packages needs
> > to be
> > rebuilt when a transition has to be done ; for example:
> >
> > $ ./planif_transition.py mathcomp-finmap
> > mathcomp-finmap
> > mathcomp-analysis mathcomp-multinomials
> > coqeal
> >
> > (the lines are meaningful: same line means parallel build is
> > possible)
> >
> > So far, so good. But managing transitions is pretty annoying:
> >
> > (1) The checksums are arch-dependent, which is annoying to write
> > ben
> > transition scripts. I just need to trigger builds in the right
> > order.
> > How do I tackle it?
> >
> > (2) The other C-style lib* packages don't need maintainers to write
> > transitions: the automatic ones just work. How can I have libcoq-*
> > packages work like this?
> >
>
> it looks like you re-created the setup that the Haskell and Ocaml
> packages use, with the provides/depends and hashes.
>
Yes, dh-ocaml has been a great inspiration. I didn't know any Perl
before...
> We have a tool that produces a file with the necessary commands to
> pass to wanna-build, see for example in
> https://people.debian.org/~iliastsi/binNMUs-haskell.txt
>
> I used to produce a file like this for Ocaml, but it’s gone since I
> disabled my account. It’s configured via a simple regex,
> libghc-(.*)-dev-([0-9.]+)-([0-9a-f]{5})
> in the case of Ocaml.
>
> The source code is at
> https://salsa.debian.org/haskell-team/tools/-/tree/master/binnmus
>
> It may be useful to you too
Yes ; as I mentioned I have a tool that prints the steps to follow to
rebuild, so I might be able to make it evolve to produce wanna-build
scripts.
Cheers,
J.Puydt
Re: Coq packages in Debian : difficult transitions
Le dimanche 31 juillet 2022 à 12:43 +0200, Sebastian Ramacher a écrit : > On 2022-07-31 12:33:35 +0200, julien.pu...@gmail.com wrote: > > Hi, > > > > I tried to ask on debian-release because it seemed more sensible > > but didn't get feedback. [1] > > Please file a transition bug. The mailing list has a high volume and > non-bug mails may be overlooked. Bug 1016416, but that doesn't look that efficient. J.Puydt
Re: Coq packages in Debian : difficult transitions
Le dimanche 31 juillet 2022 à 12:43 +0200, Sebastian Ramacher a écrit : > On 2022-07-31 12:33:35 +0200, julien.pu...@gmail.com wrote: > > Hi, > > > > I tried to ask on debian-release because it seemed more sensible > > but > > didn't get feedback. [1] > > Please file a transition bug. The mailing list has a high volume and > non-bug mails may be overlooked. Well, I would file a bug for a specific transition, but first I would like to discuss how to handle transitions for Coq-related packages in general. Cheers, J.Puydt
Coq packages in Debian : difficult transitions
Hi, I tried to ask on debian-release because it seemed more sensible but didn't get feedback. [1] The Coq-related packages have a habit of breaking their ABI with almost each upload, and until recently that meant broken user configurations: installed packages stopped working because of an upgraded package down the dependency line. A few weeks ago, I wrote dh-coq. Basically, the idea is that the src:coq-foo package builds a binary libcoq-foo package, which declares it provides a libcoq-foo-1984az package, and when src:coq-bar builds libcoq-bar, dh-coq makes it depend on libcoq-foo-1984az. When the next upload provides libcoq-foo-d04ab7, apt won't install it because it would break libcoq-bar: that finer-grained Depends/Provides organisation means user systems don't get broken. I migrated all Coq- related packages to this. Now I took care of user comfort comes the time for mine: I need to handle transitions correctly. I have a little script that tells me the following packages needs to be rebuilt when a transition has to be done ; for example: $ ./planif_transition.py mathcomp-finmap mathcomp-finmap mathcomp-analysis mathcomp-multinomials coqeal (the lines are meaningful: same line means parallel build is possible) So far, so good. But managing transitions is pretty annoying: (1) The checksums are arch-dependent, which is annoying to write ben transition scripts. I just need to trigger builds in the right order. How do I tackle it? (2) The other C-style lib* packages don't need maintainers to write transitions: the automatic ones just work. How can I have libcoq-* packages work like this? Cheers, J.Puydt [1] https://lists.debian.org/debian-release/2022/07/msg00373.html
Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name
Hi, Le jeudi 14 juillet 2022 à 14:16 +0200, Marc Haber a écrit : > On Thu, 14 Jul 2022 12:54:52 +0100, Steve McIntyre > wrote: > > And I see you uploaded ~immediately - why even bother with an ITP? > > Is it proper procedure to upload without an ITP? > No ; I have to admit a large percentage of the new packages I upload get their ITP minutes before the package is ready. Basically: I wait for the bug number before pushing to salsa & NEW. Cheers, J.Puydt
Re: questionable massive auto-removal: buggy deps nvidia-graphics-drivers-tesla-470
Le mardi 28 juin 2022 à 16:17 -0400, Scott Talbert a écrit : > On Tue, 28 Jun 2022, julien.pu...@gmail.com wrote: > > > > Wild guess: were your new uploads _*source-only*_ ? > > I looked at a couple of them and they were (source all) so that does > appear to be the problem. All uploads need to be source-only (since > bullseye?). Except uploads to NEW... which isn't 100% logical in my opinion. Cheers, J.Puydt
Re: questionable massive auto-removal: buggy deps nvidia-graphics-drivers-tesla-470
Le mardi 28 juin 2022 à 22:08 +0200, Bastian Venthur a écrit : > Hi, > > sorry I didn't follow the conversation but it seems that all my > Python > packages are still not migrating to testing and I don't really > understand how to fix it. The error I see consistently in my Python > packages is: > > > Issues preventing migration: > > Not built on buildd: arch all binaries uploaded by venthur, a new > > source-only upload is needed to allow migration > > I've re-uploaded all packages a few days ago, but the error is still > the same. Wild guess: were your new uploads _*source-only*_ ? Cheers, J.Puydt
Re: guile-cairo
Le mercredi 15 juin 2022 à 11:11 +0300, Tommi Höynälänmaa a écrit : > ke, 2022-06-15 kello 09:55 +0200, julien.pu...@gmail.com kirjoitti: > > > > Let your new package migrate to testing, since it's that one which > > doesn't have the autoremoval issue? > > I'm not sure I understand what you mean. The Guile 2.2 dependency > issue is solved in the new package guile-cairo 1.11.2-5, which should > not be autoremoved. The new package should migrate to testing in a > few days. > The autoremoval from testing concerns the old package, which does depend on guile 2.2. Normally your new package should migrate to testing before the old one gets kicked out. Don't worry! J.Puydt
Re: guile-cairo
Le mercredi 15 juin 2022 à 10:29 +0300, Tommi Höynälänmaa a écrit : > > I recently received e-mail that package guile-cairo is to be > autoremoved 2022-07-09. The reason is that it depended on guile 2.2. > However, I made new version guile-cairo-1.11.2-5 that depends only on > guile 3.0. What shall I do in order to cancel the autoremoval? Let your new package migrate to testing, since it's that one which doesn't have the autoremoval issue? Cheers, J.Puydt
Re: Python installation paths
Le jeudi 02 juin 2022 à 14:31 -0500, Richard Laager a écrit : > > There are a couple different ways to do Python to C. I think the > terms are CFFI (or FFI or ctypes, maybe some of those are different > though?) vs CPython extension, but I'm not 100% certain of that. May I suggest debian-pyt...@lists.debian.org as a better venue to discuss packaging Python software for Debian ? Cheers, J.Puydt
Re: Re: questionable massive auto-removal: buggy deps nvidia-graphics-drivers-tesla-470
Hi Le ven. 27 mai 2022 à 09:27, Andreas Tille a écrit : > Am Thu, May 26, 2022 at 08:47:20AM +0200 schrieb Nilesh Patra: > > Would it be possible to manually remove this item from the list that > generates > > autoremovals? > > ... or generate a blacklist of packages that should not trigger those > removals. > > The autoremoval warnings are pretty helpful in general but if I'm forced > to mass > remove this subject from my mailbox I might loose other sensible > autoremoval > warnings. > Or the removal watcher could have a cap on the number of warnings it sends per sensible period of time. If it exceeds this number, it sends a special warning that something is amiss to debian-devel, so we still get to know something is going wrong. One message to say "I was supposed to send 31415 warnings today" is definitely better than 31415 false-positive warnings... Cheers, J.Puydt >
Re: questionable massive auto-removal: buggy deps nvidia-graphics-drivers-tesla-470
Le jeudi 26 mai 2022 à 09:32 +0300, Timo Lindfors a écrit : > > On 5/24/22 21:34, Paul Gevers wrote: > > https://bugs.debian.org/1011268 (but apparently my first assumption > > was wrong and it's another bug, most likely Simon was right. > > Thanks for the link. I was quite puzzled this morning when I saw > several removals messages. Several is an understatement... it's pouring in. Perhaps the autoremoval watch could *STOP* sending mails until the problem is fixed?! Cheers, J.Puydt
Re: popularity-contest: support for XB-Popcon-Reports: no
Le mercredi 04 mai 2022 à 10:12 -0700, Russ Allbery a écrit : > Bill Allombert writes: > > > I plan to add support for 'XB-Popcon-Reports: no' to popularity- > > contest. > > This allows to build packages with private names that will not be > > reported to popcon, by adding 'XB-Popcon-Reports: no' to > > debian/control. > > This must not used by packages in the debian archive, however that > > can > > be used by packages generators that create packages with randomly > > generated names (package names that include 128bit uuid for > > examples) or > > by organizations that generates packages for internal use whose > > name > > include the organization name. > > > The rationale is that the only info really leaked is the package > > name, > > so it only make sense to hide a package if every system that have > > it > > installed are also hiding it, so it is better to make it a property > > of > > the package than of the system. > > > Any comment ? > > This sounds like a good idea to me. > I do see the need. > Using an additional binary package control field felt weird to me, > and I wanted to believe there was some better place to put this > information rather than introducing yet another boolean control > field, but after thinking about it for a bit, I couldn't think of any > better place that made much sense. If there's a growing list of boolean control fields, isn't it the indication that some sort of tagging system might make more sense? Instead of three lines: XB-Popcon-Reports: no Rules-Requires-Root: yes Pants-Need-Washing: yes The same package could use a single line: Tags: no-popcon-reports, rules-needs-root, pants-need-washing (aside: by default rules doesn't need root... that would make one not- very-useful line less in so many packages!) Some of our tools might provide easy queries to the feature: $ apt-cache has-tag rules-needs-root my-beautiful-package $ apt-cache list-tags my-beautiful-package Cheers, J.Puydt
Re: proposed MBF: packages still using source format 1.0
On Sun, Mar 13, 2022 at 02:58:31PM -0700, Sean Whitton wrote: > Hello, > > On Wed 09 Mar 2022 at 05:15PM +01, Lucas Nussbaum wrote: > > > On 09/03/22 at 08:52 -0700, Sean Whitton wrote: > >> On Wed 09 Mar 2022 at 01:08pm +01, Lucas Nussbaum wrote: > >> > Also, how would that work with packages that combine direct changes to > >> > upstream, and quilt for Debian-created patches? > >> > >> Could you expand? I didn't think this category was one of the ones Russ > >> and I were talking about. > > > > My limited understanding of the landscape of git workflows is that a > > workflow that is quite popular among packages still using the 1.0 format > > is the one used by the Debian X strike force. Julien Cristau described > > it as follows when I asked about it on IRC: > > > > < jcristau> [...] basically, for upstream patches we cherry-pick > > commits directly, and we use quilt for changes that aren't upstream > > Ah right, thank you. I wasn't really thinking of this case as being > about git workflows. Are the repos patches-applied or > patches-unapplied? > The patches that we keep in quilt are not applied in the repo. (Obviously the cherry-picked patches are.) Cheers, Julien
Re: No mips64el porterbox?
Le mardi 01 mars 2022 à 10:34 +0100, Sebastiaan Couwenberg a écrit : > On 3/1/22 10:28, Julien Puydt wrote: > > Is there really no mips64el porterbox, or is it only a transitory > > situation? > > eller.debian.org has mips64el chroots. > How do I use one of those and not a mipsel one? I'm using https://dsa.debian.org/doc/schroot/ as usual, and it looks like I'm getting a mipsel and not mips64el... Thanks, J.Puydt
No mips64el porterbox?
Hi, one of my package has a failure on mips64el and upstream is ready to help me find the cause and debug the issue. Unfortunately, on https://db.debian.org/machines.cgi I only see five developer machines on this architecture -- all buildd! Is there really no mips64el porterbox, or is it only a transitory situation? Cheers, J.Puydt
Re: Legal advice regarding the NEW queue
Le samedi 05 février 2022 à 15:07 +, Andrew M.A. Cater a écrit : > There's a huge amount of software that's undistributable: Debian's > good faith attempt to review this is one of the crucial arguments I > have with $DAYJOB about the benefits of a curated distribution, > however fallible we may be. That is a strong point and a main difference in quality with other distributions. > I think we should use automated tools where available, query with > upstream where practicable, and continue doing what we're doing as > far as possible, in my humble opinion. I would see the screening like this: - only source uploads are allowed (NEW and all) ; - automatic building of binary packages ; - automatic tools try to find problems (licensing and all) ; - as a last step, human checks for license issues in NEW and randomly on existing packages. At least if they have seen updates since their NEW review -- I'm wondering how many packages are a one-time shot? > Reproducible builds and DEP-5 / SPDX are also crucial in improving > everyone's quality - I don't see commercial/enterprise distributions > doing this valuable public service but I very much value the fact > that Debian does it, for example. I would add our network of buildd/porterbox to the list of good things we can boast about. Cheers, J.Puydt
IPv6-only testing
Hi, I got an RC bug on python-anyio, because its testsuite fails when run on an IPv6-only host [1]. I pushed the issue upstream, and upstream has a patch proposal [2]. Now comes the question: how do I test this patch? Cheers, J.Puydt [1] https://bugs.debian.org/1004461 [2] https://github.com/agronholm/anyio/issues/417
Re: Cloud team plans for cloud-hosted mirrors
On Wed, Jan 26, 2022 at 09:43:16PM -0800, Ross Vandegrift wrote: > On Wed, Jan 26, 2022 at 07:58:23PM +0100, Julien Cristau wrote: > > I think we (DSA) have been reluctant to add new third-party-run services > > under debian.org, and it's not clear to me if that infrastructure would > > be run by the cloud team on behalf of debian, or if the cloud team would > > control the names but point them at mirrors run by the cloud providers > > themselves. > > It depends on the provider, and what you mean by "infrastructure". Many cases > fall into a grey area between your options: > > - AWS: the mirror will be a CloudFront distribution. SPI will own the > account, > the cloud team will create the CDN, but the infrastructure will be AWS. > - Azure, Infomaniak: they contract or employ folks to run mirrors for them. > Cloud team folks are responsible in both cases. > > Speaking for myself only, I'd be be open to providing a name for a provider > that doesn't work with us, and runs their own mirror. This would definitely > not meet your requirement. > Sorry for being unclear. For these purposes the first case would count as debian-run, the second probably not. Either way a couple of things to think about and maybe document is what are the criteria for providing a name for a vendor, and what happens when the criteria are no longer met. Cheers, Julien
Re: Cloud team plans for cloud-hosted mirrors
On Tue, Jan 25, 2022 at 09:47:49PM -0800, Ross Vandegrift wrote: > Hello, > > The cloud team wants to make folks aware of a possible change to the cloud > images. The team plans to register a new domain, debian.cloud, for mirrors > inside of cloud provider infrastructure. For such mirrors, sources.list will > look like: > deb http://.debian.cloud/debian/ bullseye main > > Hosting mirrors inside the cloud infrastructure provides users with faster, > cheaper access to the archive. And since it saves the providers money, > they're > often willing to provide the hosting infrastructure for free. Our image build > process allows customizing sources.list with these mirrors when possible. All > of this is great! > > But some of the hostnames are controlled by the cloud providers. Mostly, this > has happened when the name is assigned by a CDN. This isn't optimal: if that > name ever changes, users with the old hostname will be unable to install > packages. > > These names have been very stable. But in some providers, they're tied to > cloud accounts. This makes it impossible to move the mirror to another > account > without losing the name. And of course, for reasons [1], we need to move some > of these mirrors. > > Since a migration is required, we'd like to adopt debian-controlled hostnames > in sources.list. This way, we can never lose the hostnames that appear in > sources.list. > > Our first choice would be a subzone of debian.org. But we are not in DSA, and > haven't been able to get help with this request. So in the interest of making > progress, a new domain is the simplest alternative. > > I don't know when this work will be complete - hopefully, all of the new > infrastructure will be ready to go for the next stable release. > Hi, I think we (DSA) have been reluctant to add new third-party-run services under debian.org, and it's not clear to me if that infrastructure would be run by the cloud team on behalf of debian, or if the cloud team would control the names but point them at mirrors run by the cloud providers themselves. Either way as Stefano said if you go for a new domain name it should be possible to use the same setup as our other domains if you want. Cheers, Julien
Re: Deps of -dev packages with pkg-config .pc file: Policy Change?
This is all pretty straightforward. If foo.pc in libfoo-dev references bar.pc that lives in libbar-dev, then libfoo-dev needs a dependency on libbar-dev, and the missing dependency is a serious bug. That has been the case for as long as I remember, and doesn't require more long discussions or policy changes IMO. Libs.private is a bit different because static linking is not typically used for Debian packages, but Requires and Requires.private are quite clear cut. Cheers, Julien On Thu, Dec 09, 2021 at 03:24:27PM +0100, Alexander Traud wrote: > Linux distributions, which have separate packages for developers, like > Debian, are not really supported [1] by the developer tool pkg-config > [2]. The problems are C/C++ libraries which depend on other libraries at > runtime. Let us pick one, a security library for utilizing DNSSEC: > > $ sudo apt install libunbound-dev > $ pkg-config --print-errors --short-errors --cflags libunbound > $ pkg-config --print-errors --short-errors --exists libunbound > Package 'hogweed', required by 'libunbound', not found > > 1) The error message is misleading because pkg-config talks about the > *runtime* package 'hogweed', although (in Debian) a *-dev* package is > required to get the .pc file. Should I report that, where? > > 2) In this case, the package name is not simply an added '-dev' like > 'hogweed-dev'. Instead, the developer has to search the contents of all > packages [3] for the file 'hogweed.pc'. That is part of the package > 'nettle-dev'. > > 3) Are 'nettle-dev' (and 'libevent-dev', by the way) missing > dependencies of 'libunbound-dev'? > > The latter seems to be an ongoing question on debian-devel [4] if the > package includes a static library '.a' as libunbound-dev still does. At > least I found no conclusive answer. Position No: It is not a missing > dependency because I can use that package perfectly (as a shared > library) without pkg-config. Position Yes: pkg-config has to be > required, recommended, suggested - for each level of dependency, you > find an argument on debian-devel, see [5][6][7][8]. > > 16 years. This topic has come up for 16 years now, again and again on > the mailing list debian-devel, documenting the uncertainty of package > maintainers. Furthermore, bug reports come in, again and again for that > topic. Again, libunbound-dev as example for the Debian bug report [9]: > Upstream, in the pkg-config .pc file, the maintainer moved the libraries > from 'Requires' to 'Requires.private'. That was the correct approach. > However, the maintainer closed the Debian bug report because he falsely > believed to have fixed the issue that way. > > Requires -> -I/subfolder -lfuu, avoid if possible, see [10] > Requires.private -> -I/subfolder , a header includes that header > Libs -> -lfoo, lib itself > Libs.private -> -lfuu, exclusively for static linking > Cflags -> -I/subfolder , lib headers itself and/or > header includes that header > > Any idea how to approach this? > a) Leave as is. Do not depend on 'Require.private' automatically because > the package can be used without pkg-config. Only depend on other -devs > if one of those headers is included in a header. > b) Fix/convert. Upstream, move everything into 'Requires.private'. > Downstream, in the Debian package, remove 'Requires.private' and convert > to 'Libs.private'; again, except if one of those headers is included in > a header. > > These uncertainties create repeated frustration, even for core Debian > members. Proposal: Why not decide, or at least give a recommendation on > these questions: > > i) pkg-config tool itself: When is it a depend (which dep level?), and > when not? My suggestions: Because I can use a '-dev' package without any > tool, because of the FHS, just -lfoo should be needed [11]. > > ii) .pc file and its 'Require': Leave it or change it? My suggestion: > Report upstream that those libs have to be moved to 'Requires.private'. > > iii) .pc file and its 'Require[.private]': Depend on each lib? My > suggestion: Only if the headers include it. For Debian, convert all > others to 'Libs.private' because the built '.a' file (for static > linking) has a known dependency tree. This gets a Debian patch in that > source package. > > iv) Cflags: If I got it correctly, back in the year 2005, the cause of > this drama were -I flags [12]; if the header included
Re: uscan roadmap
Hi Le jeu. 2 déc. 2021 à 11:36, Yadd a écrit : > > Another idea to have a compromise: > * uscan is released with versioned schemes (GitHub.json, sf.json,...) > * when launched, it tries to download new version from a new Debian API > (static json files) > * if no response or no new version, uscan uses its own scheme or a > previously downloaded update (verifying signature) > * if a new version is available from new redirector: > * it verifies GPG signature of new scheme > * if not OK, it warns and uses cached scheme > * if OK, it stores it with signature in ~/.cache/uscan/schemes > What I don't like is that it will need time to check new profiles on a central site, which looks like an invitation for DoS situations. I propose a variation of this: an explicit "uscan --update" will update the profiles, and all other calls will use the known profiles. Cheers, J. Puydt
Re: Bug#995722: Not running tests because tests miss source code is not useful
Hi Le sam. 9 oct. 2021 à 18:52, Jonas Smedegaard a écrit : > Quoting Julien Puydt (2021-10-09 18:48:07) > > Hi > > > > Le sam. 9 oct. 2021 à 17:40, Jeremy Stanley a écrit > : > > > > > On 2021-10-09 08:53:57 +0200 (+0200), Yadd wrote: > > > [...] > > > > If you really consider minified files as binary, there's a room > > > > for creating a lot of RC bugs > > > > > > The more appropriate question is whether Debian considers minified > > > files to be source code, or a compiled form. To needlessly quote > > > DFSG §2: "The program must include source code, and must allow > > > distribution in source code as well as compiled form." > > > > > > > Minified code isn't code in a form meant/supposed to be modified by > > hand, so it's not source code. > > Right. But stating that is not helping much. > > It is not source code. > > It is not binary code. > It was helping: it's definitely binary code, since it's not source code! There was the case years ago of the smarteiffel compiler. It was supposed to be open source, but upstream only released C code. And that was bad, because it wasn't what *they* worked with: they had eiffel sources, and the C code was preprocessed and didn't allow/permit bootstrapping. It took some discussion to convince them to release the true sources. The situation is the same here: minified code isn't source. Trying to claim it's not really binary because it's JavaScript and not some bytecode (for a virtual or actual hardware) is disingenuous. If that's not what developer work with, that's not source, end of the discussion. Cheers, J. Puydt >
Re: Bug#995722: Not running tests because tests miss source code is not useful
Hi Le sam. 9 oct. 2021 à 17:40, Jeremy Stanley a écrit : > On 2021-10-09 08:53:57 +0200 (+0200), Yadd wrote: > [...] > > If you really consider minified files as binary, there's a room for > > creating a lot of RC bugs > > The more appropriate question is whether Debian considers minified > files to be source code, or a compiled form. To needlessly quote > DFSG §2: "The program must include source code, and must allow > distribution in source code as well as compiled form." > Minified code isn't code in a form meant/supposed to be modified by hand, so it's not source code. J. Puydt >
Re: uscan upstream version: padding zero to the left with elegance?
Le lundi 20 septembre 2021 à 11:11 +0200, Markus Frosch a écrit : > > I would keep using the versioning style of upstream. > > dpkg and uscan should be pretty much fine with this: > > $ dpkg --compare-versions 2021.8.23 eq 2021.08.23; echo $? > 0 Oh, you mean 2021.9.9 won't be seen as the last of the century? Cheers, J.Puydt
uscan upstream version: padding zero to the left with elegance?
Hi, I'm having an issue with an upstream where the latest git tag is v2021.8.23 ; I would have liked them to (also) tag v2021.08.23, but that won't happen. So I need some uversionmangle magic. I know how to get the parts $1=2021, $2=8 and $3=23, but I don't know how to say $2 ($3 will need a similar adjustment) should be padded with zeros to the left for a length of two -- it *should* be pretty straightforward. I tried looking: - in the manpage for uscan ; - in uscan's source code ; - on codesearch for examples ; - on internet for perl examples ; but didn't find anything conclusive for use in a d/watch file. The exceedingly inelegant but working (as far as I know!) trick I came up with is: uversionmangle=s/v?([\d]+)\.([\d]+)\.([\d]+).*/$1.0$2.0$3/;s/([\d]+)\.[ \d]*(\d\d)\.[\d]*(\d\d)/$1.$2.$3/ and I don't like it -- at all! Does someone have better? Cheers, J.Puydt
Re: Q: Use https for {deb,security}.debian.org by default
On Sat, Aug 21, 2021 at 10:28:04AM +0200, Wouter Verhelst wrote: > On Thu, Aug 19, 2021 at 10:11:33PM +, Jeremy Stanley wrote: > > On 2021-08-19 16:37:13 -0400 (-0400), Kyle Edwards wrote: > > > On 8/19/21 3:46 PM, Simon Richter wrote: > > > > For the most part, users would configure https if they are behind a > > > > corporate firewall that disallows http, or modifies data in-flight so > > > > signature verification fails, everyone else is better off using plain > > > > http. > > > > > > Or they might configure https on the sheer principle of not wanting to > > > have > > > their traffic hoovered up by their ISP or anyone else who might be > > > listening. > > > > While this does complicate it, a snooping party can still know the > > site they're connecting to via SNI happening unencrypted, > > SNI is not unencrypted if you do TLS1.3... > It is, though... ECH (née ESNI) https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ is still WIP. Cheers, Julien
Re: Proposed mass-bug filing: missing support for build-arch or build-indep
On Mon, Apr 19, 2021 at 03:11:21PM +0200, Lucas Nussbaum wrote: > Hi, > > I would like to propose a mass bug filing on source packages that miss > support for build-arch or build-indep targets in debian/rules. > > Those targets were made mandatory in Debian Policy 3.9.4 (released in > August 2012). From the changelog: > * build-arch and build-indep are now mandatory targets in debian/rules, > implementing the Technical Committee ruling in #629385. Wording > review by Jonathan Nieder, Jakub Wilk, and Roger Leigh. > (Closes: #374029) > > There are currently 411 packages in testing that do not include those > targets, according to lintian's debian-rules-missing-recommended-target > tag. (I will also file a bug against lintian to reflect that those > targets are now required). > I think you should start with a lower severity and consider bumping it to serious once you're down to a manageable number (and possibly a couple of NMU campaigns). Cheers, Julien
Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)
Le lundi 19 avril 2021 à 14:05 +0100, Jonathan Dowland a écrit : > On Mon, Apr 19, 2021 at 11:30:48AM +0800, Benda Xu wrote: > > The winning option "Debian will not issue a public statement on > > this > > issue" implies that the majority of DDs is not interested in such > > non-technical affairs. > > The vote in fact shows the opposite. That interpretation of the > result > would be true if the majority of people voted for that as their first > preference. They did not: it was the most-agreed upon preference > between > two ideologically opposite factions. The majority of voting DDs > expressed a strong preference one way or the other. All sides agreed Debian was not the right place to fight on such a matter. Let's move on. JP
Re: Missing samba DSA-4513 changelog in https://metadata.ftp-master.debian.org/changelogs/
On Wed, Apr 07, 2021 at 02:49:49PM +0200, Ben Hutchings wrote: > On Wed, 2021-04-07 at 20:07 +0900, Hideki Yamane wrote: > > Hi, > > > > I cannot find appropriate pseudo package in reportbug, so ask this > > in -devel. > > > > Fumiyasu (CCed) found a issue with samba package changelog in > > packages.d.o. > > https://packages.debian.org/buster/samba has "Debian Changelog" link > > but its > > https://metadata.ftp-master.debian.org/changelogs//main/s/samba/samba_4.9.5+dfsg-5+deb10u1_changelog > > link is 404. > > The latter site is part of the main archive and does not have > information about package versions that are only in the security > archive. > > Packages uploaded to the security archive are normally copied to the > (old)stable-proposed-update suite of the main archive, so long as that > is open, i.e. until the last point release. So it looks as if the copy > to the main archive failed for some reason. > The samba package is held in stable-new by bug#939419, see https://release.debian.org/proposed-updates/stable.html Cheers, Julien > > Something wrong with > > https://metadata.ftp-master.debian.org/changelogs/ , > > that doesn't have the changelog were introduced with DSA 4513-1 as > > > > https://tracker.debian.org/news/1061236/accepted-samba-2495dfsg-5deb10u1-source-into-stable-embargoed-stable/ > > > > Also, why DSA 4513-1 is not included in Debian10.2 ? > > See https://www.debian.org/News/2019/20191116 > > Because the package didn't get copied to the main archive. > > The common reason why this may fail is that a maintainer uploads a > different orig tarball to the security archive. However, the two > versions agree on the checksums of the orig tarball. I would take this > up with the FTP team. >
Re: Cancel "culture" is a threat to Debian
Hi Le mar. 30 mars 2021 à 12:49, Gard Spreemann a écrit : > > In order to calibrate what is considered merely "a foolish thing said" > from your perspective, I feel a need to ask: what is, from your > perspective, the least of the sufficiently bad things that a person can > do in order for Debian to officially call out said person's behavior? > What is (roughly) the smallest offense that *you* would consider too bad > for Debian to accept? You're asking the wrong question: should Debian do anything about people outside doing things outside? Now, if Debian does things with the FSF, then we can ask whether to go on or not, and that is a relevant issue. And let's be clear : the question is "go on or stop that specific common thing", not "ask the FSF to do whatever we want". JP
Re: Bug#984811: ITP: openbgpd -- Free, functional, and secure implementation of the BGP-4 protocol.
On Mon, Mar 08, 2021 at 05:13:35PM +0100, Job Snijders wrote: > Dear Julien, > > > > Description : Free, functional, and secure implementation of the > BGP-4 protocol. > > the above short description has 3 useless words in it, I suggest you drop > them. > > If it wasn't free it wouldn't be in Debian; if it wasn't functional why > would anyone release or package it; same with "secure", plus it's a > rather meaningless descriptor that'll be wrong the day somebody finds a > bug (especially combined with "implemented in C"...). > > > Thank you for your feedback. > > I'll change the short description to "OpenBSD BGP-4 daemon" > Sounds good, thanks! Cheers, Julien
Re: Bug#984811: ITP: openbgpd -- Free, functional, and secure implementation of the BGP-4 protocol.
On Mon, Mar 08, 2021 at 04:51:14PM +0100, Job Snijders wrote: > Package: wnpp > Severity: wishlist > Owner: Job Snijders > X-Debbugs-Cc: debian-devel@lists.debian.org > > * Package name: openbgpd > Version : 6.8p1 > Upstream Author : OpenBSD tech mailing list > * URL : http://www.openbgpd.org/ > * License : ISC > Programming Lang: C > Description : Free, functional, and secure implementation of the BGP-4 > protocol. > Hi, the above short description has 3 useless words in it, I suggest you drop them. If it wasn't free it wouldn't be in Debian; if it wasn't functional why would anyone release or package it; same with "secure", plus it's a rather meaningless descriptor that'll be wrong the day somebody finds a bug (especially combined with "implemented in C"...). Cheers, Julien
Bug#982562: general: Storing upstream signatures next to upstream tarballs is problematic
On Thu, Feb 11, 2021 at 09:59:42PM +0100, Raphaël Hertzog wrote: > Those files are not really meant to be immutable: > - signing keys can expire and be revoked, upstream might want to update > signatures of already released tarballs > - the set of "upstream release managers" might evolve over time and the > official signature to use might change... > As far as we're concerned they are immutable, they are the signature of the tarball at the time that tarball was uploaded to debian. There's no reason for that to change without the tarball itself changing, at which point both filenames change. Cheers, Julien
Re: Bug#981994: ITP: xserver-xorg-input-aiptek -- X.Org X server -- Aiptek input driver
On Fri, Feb 05, 2021 at 06:03:57PM +0200, Adrian Bunk wrote: > Package: wnpp > Severity: wishlist > Owner: Adrian Bunk > > Package name: xserver-xorg-input-aiptek > Description : X.Org X server -- Aiptek input driver > > Adopting X drivers that were removed in #955603 despite many objects. > These hardware drivers belong in the kernel. Do aiptek USB devices not show up as regular input devices that generic userspace drivers can handle? Cheers, Julien
Re: Bug#981113: ITP: root -- open-source data analysis framework
On Tue, Jan 26, 2021 at 04:34:14PM +0100, Stephan Lachnit wrote: > Package: wnpp > Severity: wishlist > Owner: Stephan Lachnit > X-Debbugs-Cc: debian-devel@lists.debian.org, stephanlach...@protonmail.com, > debian-scie...@lists.debian.org > > * Package name: root [...] > > I want to maintain ROOT in the science team. ROOT was already in Debian as > `root-system` [1], but hasn't been updated since 2015. > I will probably go with a more easy maintainable route like I did with Geant4 > for the start and do package splitting later. > > [1] https://tracker.debian.org/pkg/root-system > Please re-use the old name. "root" is a terrible choice of package name. Thanks, Julien
Re: RFC: raising ca-certificates package Priority to standard or important
Hi Antonio, On Thu, Jan 21, 2021 at 02:47:25PM -0300, Antonio Terceiro wrote: > On Thu, Jan 21, 2021 at 03:10:47PM +0100, Julien Cristau wrote: > > And which of standard or important made most sense (AIUI, standard > > means "installed by default in d-i" and important means "installed by > > default in debootstrap"). > > wget is already Priority: standard and recommends ca-certificates, so it > seems to me that making it standard would be a noop in practice for most > of the systems installed by d-i. > > On the other hand, all cases that I remember seeing a problem caused by > missing ca-certificates was in systems not installed by d-i, such as > containers, vm images, etc. Based on that, I would make it important. Here's my thinking on this: I would expect "standard" to get installed on "general purpose" VM images, and "important" *not* to get installed on "minimal" container or VM images. Looking at the docker debian image build script just now[1], it seems to pull in required packages + iproute2 and ping, so it has its own selection that doesn't include "important" priority. So changing the severity, by itself, won't change anything unless we go all the way to "required" which feels like it'd be going too far (but then I also don't think apt should be "required"). If there are specific examples where you think "important" would help I'd be interested; right now I'm sort of favouring "standard" as good enough. [1] https://github.com/debuerreotype/debuerreotype/blob/master/examples/debian.sh Cheers, Julien
RFC: raising ca-certificates package Priority to standard or important
[bcc: {openssl,ca-certificates}@packages.d.o]
Hi,
the ca-certificates package is currently "Priority: optional", like most
of the archive. It's Recommended by a bunch of packages, Depended on by
an equivalent number, but I'm not sure if this is optimal. I suspect
most packages can be configured to use a different trust store; and that
in many deployments you may want to use a private PKI, or limit trust to
a specific subset of the global public CAs, so in that sense `Depends'
on ca-certificates is not quite correct. On the other hand it's less
likely to run into "user disabled Recommends, and run into unexpected TLS
server auth failures" kind of situations.
So I'd like to raise the priority of ca-certificates from optional to
at least standard, as a signal that it should be installed on
non-minimal Debian systems. I'll note that ca-certificates depends on
the openssl binary package which would thus effectively also become
standard (or important, if we go that route), if it isn't already.
Before asking ftpmasters to make that change I wanted to ask this group
if there were downsides to it that I haven't considered. And which of
standard or important made most sense (AIUI, standard means "installed
by default in d-i" and important means "installed by default in
debootstrap").
Thanks,
Julien
Re: Architecture: all binNMUs (was: deduplicating jquery/)
On Tue, Dec 01, 2020 at 10:56:28AM +, Simon McVittie wrote:
> Possible solutions:
>
> - Change at least 622 packages so they have something more like
> Depends: foo-data (>= ${source:Version}), foo-data (<< ${source:Version}+c)
> (also hope that all of their maintainers can get those runes right, taking
> into account what the binNMU suffix is, and hope that it won't break
> derivatives like Ubuntu that use a source-upload suffix like ubuntu1 that
> compares less than +b1)
>
> - Change at least 622 packages so that when foo-data is binNMU'd, it
> automatically gets Provides: foo-data (= 1.2-3)
>
> - Change some more central component so that the dependencies are edited
> or the Provides is added globally
>
> - Something clever that I haven't thought of
>
Make no-change-other-than-version-bump source uploads easier?
Cheers,
Julien
Re: doubt with autopkgtest for javascript packages
Le lundi 09 novembre 2020 à 21:08 +, Sudip Mukherjee a écrit : > I have attached the list. > Do you want me to add them in my MBF list and raise bug reports for > them? If I remember well, I'm the main culprit behind those, and I'll refresh them -- probably at the end of the week: node-ast-types node-es5-shim node-esprima-fb node-mocha-lcov-reporter node-posix-getopt node-regenerate node-stringmap node-unicode-canonical-property-names-ecmascript node-unicode-property-aliases-ecmascript node-unicode-property-value-aliases Cheers, JP
Re: How does one package a multirepo project?
Le mardi 20 octobre 2020 à 18:00 +0200, Jonas Smedegaard a écrit : > > > - bad: the tarball contains the whole sources (no repack) ; > > > - bad: the bare checkout isn't cleared. > > > > Still current. > > Please file bugreports about concrete weaknesses of Debian tools. > > If you are still asking a question here, then I recommend to make > that more explicit. The lack of repack was because I had empty lines ; this problem is fixed, and was coming from me. The fact that the bare checkout stays after uscan has run is probably a bug. Is it supposed to stay around? JP
Re: How does one package a multirepo project?
Le lundi 19 octobre 2020 à 10:06 +0200, Jonas Smedegaard a écrit : > You might find some inspiration in the source package > jsbundle-web-interfaces which uses version type "group" and > mode=git, > and sets individual version numbers for each binary package. > > Another example is matrix-mirage where one component is fixed at a > specific release. I tried quite a few things today, and didn't get anywhere useful. If I use as d/watch: version=4 opts=component=algorithm,mode=git,\ uversionmangle=s/(.*)/algorithm-$1/ \ https://github.com/jupyterlab/lumino \ refs/tags/@lumino/algorithm@@ANY_VERSION@ group then I get a lumino_algorithm-1.3.3.orig-algorithm.tar.xz and its content looks good. But if my d/watch lists the first two components I'm interested in : version=4 opts=component=algorithm,mode=git,\ uversionmangle=s/(.*)/algorithm-$1/ \ https://github.com/jupyterlab/lumino \ refs/tags/@lumino/algorithm@@ANY_VERSION@ group opts=component=application,mode=git,\ uversionmangle=s/(.*)/application-$1/ \ https://github.com/jupyterlab/lumino \ refs/tags/@lumino/application@@ANY_VERSION@ group then I get the first tarball right, but then uscan dies : Successfully repacked ../lumino-algorithm-1.3.3.tar.xz as ../lumino_algorithm-1.3.3.orig-algorithm.tar.xz, deleting 443 files from it. fatal: not a valid object name: refs/tags/@lumino/application@1.11.0 uscan die: git archive failed at /usr/share/perl5/Devscripts/Uscan/Output.pm line 58. and if in the two-components d/watch I s/application/coreutils/g, I *do* get two tarballs! Notice that in any case the git bare repository has a name of the form lumino-temporary..git, where it looks like the number is increasing with time. That is probably (I'm not sure) bad : not all of the components need the same thing, and in the triple component- version-commit, for example, two components could have the same version and still need different commits! I'm still trying to know if the problem is sitting on the chair (I'm a bit tired these days) or if the tool is not up to the job. In any case : help! I need somebody. Help! Not just anybody... JP
Re: How does one package a multirepo project?
Le mardi 20 octobre 2020 à 10:02 +0200, Julien Puydt a écrit : > Hi, > > Le lundi 19 octobre 2020 à 20:03 +, PICCA Frederic-Emmanuel a > écrit : > > what about the git mode of uscan > > > > then you would have all the tags ? > > Ah, yes, I had forgotten that! > > I tried with a simpler version (one component), and my d/watch is : > > version=4 > > opts=\ > component=algorithm,\ > dversionmangle=auto,repacksuffix=+ds,mode=git,compression=gzip,\ > filenamemangle=s/lumino-(@ANY_VERSION@@ARCHIVE_EXT@)/lumino- > algorithm- > $1/ \ > https://github.com/jupyterlab/lumino \ > refs/tags/@lumino/algorithm@@ANY_VERSION@ group > > with d/copyright having (on a single line) : > > Files-Excluded-algorithm: api-extractor-base.json CONTRIBUTING.md > examples lerna.json notebooks package.json RELEASE.md review > yarn.lock > packages/application packages/collections packages/commands > packages/coreutils packages/datagrid packages/datastore > packages/default-theme packages/disposable packages/domutils > packages/dragdrop packages/keyboard packages/messaging > packages/polling > packages/properties packages/signaling packages/virtualdom > packages/widgets > > The result is : > - bad: the name lumino-1.3.3.tar.gz for the tarball is not correct ; uversionmangle=s/(.*)/algorithm-$1/,\ got me out of this! > - bad: the tarball contains the whole sources (no repack) ; > - bad: the bare checkout isn't cleared. Still current. JP
Re: How does one package a multirepo project?
Hi, Le lundi 19 octobre 2020 à 20:03 +, PICCA Frederic-Emmanuel a écrit : > what about the git mode of uscan > > then you would have all the tags ? Ah, yes, I had forgotten that! I tried with a simpler version (one component), and my d/watch is : version=4 opts=\ component=algorithm,\ dversionmangle=auto,repacksuffix=+ds,mode=git,compression=gzip,\ filenamemangle=s/lumino-(@ANY_VERSION@@ARCHIVE_EXT@)/lumino-algorithm- $1/ \ https://github.com/jupyterlab/lumino \ refs/tags/@lumino/algorithm@@ANY_VERSION@ group with d/copyright having (on a single line) : Files-Excluded-algorithm: api-extractor-base.json CONTRIBUTING.md examples lerna.json notebooks package.json RELEASE.md review yarn.lock packages/application packages/collections packages/commands packages/coreutils packages/datagrid packages/datastore packages/default-theme packages/disposable packages/domutils packages/dragdrop packages/keyboard packages/messaging packages/polling packages/properties packages/signaling packages/virtualdom packages/widgets The result is : - good: a bare checkout is made ; - good: a tarball gets generated ; - bad: the name lumino-1.3.3.tar.gz for the tarball is not correct ; - good: the symlink to lumino_1.3.3.orig-algorithm.tar.gz looks better - bad: the tarball contains the whole sources (no repack) ; - bad: the bare checkout isn't cleared. Here is the end of running "LANG=C uscan -v" : uscan info: Upstream URL(+tag) to download is identified as https://github.com/jupyterlab/lumino refs/tags/@lumino/algorithm@1.3.3 uscan info: Filename (filenamemangled) for downloaded file: lumino- 1.3.3.tar.gz uscan: Newest version of algorithm on remote site is 1.3.3, local version is 0~O uscan: => Newer package available from => https://github.com/jupyterlab/lumino refs/tags/@lumino/algorithm@1.3.3 uscan info: Downloading upstream package: lumino-1.3.3.tar.gz Cloning into bare repository '../lumino-temporary.277930.git'... remote: Enumerating objects: 442, done. remote: Counting objects: 100% (442/442), done. remote: Compressing objects: 100% (303/303), done. remote: Total 442 (delta 166), reused 258 (delta 112), pack-reused 0 Receiving objects: 100% (442/442), 614.72 KiB | 1.91 MiB/s, done. Resolving deltas: 100% (166/166), done. uscan info: Successfully downloaded package: lumino-1.3.3.tar.gz uscan info: Start checking for common possible upstream OpenPGP signature files uscan info: End checking for common possible upstream OpenPGP signature files uscan info: Missing OpenPGP signature. uscan info: New orig.tar.* tarball version (oversionmangled): 1.3.3 uscan info: Launch mk-origtargz with options: --package lumino --version 1.3.3 --repack-suffix +ds --component algorithm --compression gzip --directory .. --copyright-file debian/copyright ../lumino-1.3.3.tar.gz Successfully symlinked ../lumino-1.3.3.tar.gz to ../lumino_1.3.3.orig- algorithm.tar.gz. uscan info: New orig.tar.* tarball version (after mk-origtargz): 1.3.3 uscan warn: rename ../lumino_1.3.3.orig-algorithm.tar.gz to ../lumino_1.3.3.orig-algorithm.tar.gz Use of uninitialized value in string eq at /usr/share/perl5/Devscripts/Uscan/WatchFile.pm line 451. uscan info: Scan finished (I think that "Use of uninitialized value ..." is just a warning since the log doesn't end there) What do I still miss? JP
Re: How does one package a multirepo project?
Hi, Le lundi 19 octobre 2020 à 11:51 +0200, Julien Puydt a écrit : > Even in that case, will uscan see the tag subpackage42/3.14 on > github? > In my experience, it only sees a handful of last tags, so it will see > the releases of something like subpackage1/* to subpackage23/*, but > not the other ones. For example, it doesn't see the last ipywidgets > release 7.5.1's tag, so I had to download it by hand before calling > gbp import-orig. My experiments on uscan have given me the impression: (1) that if there are too many tags, some aren't seen (github only gives a list of ten by default) ; (2) that if one components appears tagless, nothing is done. Notice that it's possible to get more tags by (and that's what clicking "Next" does) : https://github.com/jupyterlab/lumino/tags?after=%40lumino%2Fapplication%401.11.0 so perhaps there's a trick to get more tags at once... Cheers, JP
Re: How does one package a multirepo project?
Hi, Le lundi 19 octobre 2020 à 20:33 +0200, Jonas Smedegaard a écrit : > Quoting Julien Puydt (2020-10-19 19:27:11) > > Am I getting somewhere with today's tools? Can someone propose a > > nicer way in the future? > > My apologies for mistaking the scope of your question. And my apologies for not being very clear in the first place. :-) Thanks, JP
Re: How does one package a multirepo project?
Hi,
Le lundi 19 octobre 2020 à 12:15 +0200, Jonas Smedegaard a écrit :
> Quoting Pirate Praveen (2020-10-19 12:01:47)
> > On 2020, ഒക്ടോബർ 19 12:45:28 PM IST, Julien Puydt
> > wrote:
> > > I was trying to update the ipywidgets package. It once had a
> > > quite
> > > normal upstream, but then things went wild, if not stellar :
> > > they
> > > went monorepo.
> > ...
> > > So basically my question is the one in the mail subject : how
> > > does
> > > one package a multirepo project?
> > >
> >
> > Look at node-rollup-plugin-* packages. The source packages will
> > have a
> > lot of duplication. I think uscan should provide an option to
> > include
> > only specific directories when repacking to make handling
> > monorepos
> > easier.
>
> To strip upstream content completely from Debian redistribution, use
> Files-Excluded-foo: in topmost section of debian/copyright - see
> jsbundle-web-interfaces for an example of that.
>
> To strip upstream content from entering the Debian git while still
> getting redistributed - notably to avoid upstream git hints from
> messing
> with a different use of git in Debian - use git-buildpackage and its
> --filter option. Again, jsbundle-web-interfaces is an example of
> that.
If I try to use the following script to update my d/copyright and
create a d/watch (I haven't any yet).
project = 'lumino'
github = f'https://github.com/jupyterlab/{project}'
packages = ['algorithm', 'application', 'collections', 'commands',
'coreutils', 'datagrid', 'datastore', 'default-theme',
'disposable', 'domutils', 'dragdrop', 'keyboard',
'messaging', 'polling', 'properties', 'signaling',
'virtualdom', 'widgets']
# In the real world, the following list of names is the result of:
#
# from os import listdir
# names = listdir('.')
#
# FIXME: since I don't have a main, where do I get CHANGELOG.md,
LICENSE.md and README.md from?
# WORKAROUND: edit by hand one of the components to let it get those
files!
#
names = ['api-extractor-base.json', 'CHANGELOG.md', 'CONTRIBUTING.md',
'examples',
'lerna.json', 'LICENSE', 'notebooks', 'package.json',
'packages',
'README.md', 'RELEASE.md', 'review' 'yarn.lock']
print('\n d/copyright\n==
==\n')
for package in packages:
chunks = []
for name in names:
if name != 'packages' and name != 'debian':
chunks.append(name)
for other in packages:
if other != package:
chunks.append(f'packages/{other}')
print(f'Files-Excluded-{package}: ' + ' '.join(chunks)+'\n')
print('\n d/watch\n
\n')
chunks = []
for package in packages:
chunk = 'opts=\\\n'
chunk = chunk + f'component={package},\\\n'
chunk = chunk +
'dversionmangle=auto,repacksuffix=+ds,compression=gzip,\\\n'
# FIXME: what if there are so many tags we don't see the relevant
one?
chunk = chunk +
f'filenamemangle=s/.*@(@ANY_VERSION@@ARCHIVE_EXT)/{project}-{package}-
$1/ \\\n'
chunk = chunk + f'{github}/tags \\\n'
chunk = chunk + f'.*/{package}@@ANY_VERSION@@ARCHIVE_EXT@ group\n'
chunks.append(chunk)
print('\n'.join(chunks))
It looks like uscan doesn't see the tag for the "algorithm" component,
as it isn't on the first page. And it looks like it doesn't try to look
for the other components. I tried to put "application" first, and now
it sees there's a newer package available, but I haven't found how to
get it to download. And of course after seeing there's a new
"application", it doesn't see "algorithm" and stops here.
Am I getting somewhere with today's tools? Can someone propose a nicer
way in the future?
Cheers,
JP
Re: How does one package a multirepo project?
Le lundi 19 octobre 2020 à 16:42 +0530, Pirate Praveen a écrit :
>
> On Mon, Oct 19, 2020 at 11:51, Julien Puydt
> wrote:
> > Here is what I have in d/control for my src:lumino experiments :
> >
> > Provides: node-lumino-algorithm (= 1.3.3),
> > node-lumino-application (= 1.11.0),
> > node-lumino-collections (= 1.3.3),
> > node-lumino-commands (= 1.11.3),
> > node-lumino-coreutils (= 1.5.3),
> > node-lumino-datagrid (= 1.14.0),
> > node-lumino-datastore (= 0.11.0),
> > node-lumino-default-theme (= 0.5.0),
> > node-lumino-disposable (= 1.4.3),
> > node-lumino-domutils (= 1.2.3),
> > node-lumino-dragdrop (= 1.6.4),
> > node-lumino-keyboard (= 1.2.3),
> > node-lumino-messaging (= 1.4.3),
> > node-lumino-polling (= 1.3.3),
> > node-lumino-properties (= 1.2.3),
> > node-lumino-signaling (= 1.4.3),
> > node-lumino-virtualdom (= 1.7.3),
> > node-lumino-widgets (= 1.14.0)
> >
> > can you imagine the size of the version string in d/changelog with
> > that
> > many parts?
> >
> > I'm pondering writing a small Python script to print a suitable
> > Provides: so I'll just have to paste its output and wrap-and-sort
> > to
> > update this...
>
> pkg-js-tools (dh-sequence-nodejs) can do this automatically. Use
> {nodejs:Provides}.
It assumes I use the uscan features for grouping ; and I'm not sure yet
it does the trick (needs a main source, if I followed correctly).
JP
Re: How does one package a multirepo project?
Hi, Le lundi 19 octobre 2020 à 10:06 +0200, Jonas Smedegaard a écrit : > Hi Julien, and others, > > Quoting Julien Puydt (2020-10-19 09:15:28) > > I was trying to update the ipywidgets package. It once had a quite > > normal upstream, but then things went wild, if not stellar : they > > went > > monorepo. > > > > For those lucky ones who never crossed the principle, the idea is > > to > > have a single repository, and make dozens of different packages > > live > > within. Basically, different directories now are different > > packages, > > with different release schedules. At the moment, > > https://github.com/jupyter-widgets/ipywidgets has 936 tags. > > > > There are several issues at hand : > > > > - uscan doesn't work correctly anymore, as the multiplication of > > tags > > makes them disappear in the list quite fast ; > > Please see uscan v4 and its version types "group" and "checksum". I find it gives unwieldly versions when there is a lot of packages (we're talking about a dozen packages here, with worse offenders probably around the corner) ; and we're left with : - an awfully long debian version string in debian/changelog ; - need to adapt by hand the versions of the Provides: in d/control for each sub-package. Here is what I have in d/control for my src:lumino experiments : Provides: node-lumino-algorithm (= 1.3.3), node-lumino-application (= 1.11.0), node-lumino-collections (= 1.3.3), node-lumino-commands (= 1.11.3), node-lumino-coreutils (= 1.5.3), node-lumino-datagrid (= 1.14.0), node-lumino-datastore (= 0.11.0), node-lumino-default-theme (= 0.5.0), node-lumino-disposable (= 1.4.3), node-lumino-domutils (= 1.2.3), node-lumino-dragdrop (= 1.6.4), node-lumino-keyboard (= 1.2.3), node-lumino-messaging (= 1.4.3), node-lumino-polling (= 1.3.3), node-lumino-properties (= 1.2.3), node-lumino-signaling (= 1.4.3), node-lumino-virtualdom (= 1.7.3), node-lumino-widgets (= 1.14.0) can you imagine the size of the version string in d/changelog with that many parts? I'm pondering writing a small Python script to print a suitable Provides: so I'll just have to paste its output and wrap-and-sort to update this... > If you are already aware of that, then perhaps by "doesn't work > correctly" you really mean "doesn't work same way as I am used to"? > > > - and what does one want to watch exactly anyway? > > Ideally we want to watch upstream releases of all upstream parts. > > If "upstream releases" are git commits, then watch that. Tagged commits, yes. Sounds good, but isn't ; see below. > If "upstream releases" are something more obscure like timestamps of > files (yes, some do that!) then somehow watch that - or try convince > upstream to also/instead use an easier watchable mechanism. The situation is worse than that : a same commit can be a release for a directory, and give something bad for another. Imagine a project named "monorepo", with only two packages/directories foo/ and bar/ and two tagged commits : - 0xdeadbeef is tagged foo/3.14, and bar is broken for it ; - 0x1337beef is tagged bar/2.72 and foo is broken for it. How can I get uscan version 4 to do anything sane about it? > > - even if uscan could keep up, how does one get the source? It > > should > > basically be a checkout of a different commit for each different > > directory! > > Please see uscan v4 and its mode=git. See above : the git mode is nice when there's a good global commit. I don't think that assumption is going to fly. > > - how does one even put a version number of this for a Debian > > package? > > (I guess something like "Provides: foo (= 3.14), bar (= 2.72)" can > > help a little, but what about the main package?) > > If main package is not versioned upstream, then I would say that's a > strong indication that you really want to track each underlying part > as a separate Debian package instead - i.e. that upstream "main > package" translates to a Debian metapackage. I don't understand what you mean here. A src:monorepo-something for each? With adapted d/copyright Files-Excluded: to get only the right directory? Even in that case, will uscan see the tag subpackage42/3.14 on github? In my experience, it only sees a handful of last tags, so it will see the releases of something like subpackage1/* to subpackage23/*, but not the other ones. For example, it doesn't see the last ipywidgets release 7.5.1's tag, so I had to downl
How does one package a multirepo project?
Hi, I was trying to update the ipywidgets package. It once had a quite normal upstream, but then things went wild, if not stellar : they went monorepo. For those lucky ones who never crossed the principle, the idea is to have a single repository, and make dozens of different packages live within. Basically, different directories now are different packages, with different release schedules. At the moment, https://github.com/jupyter-widgets/ipywidgets has 936 tags. There are several issues at hand : - uscan doesn't work correctly anymore, as the multiplication of tags makes them disappear in the list quite fast ; - and what does one want to watch exactly anyway? - even if uscan could keep up, how does one get the source? It should basically be a checkout of a different commit for each different directory! - how does one even put a version number of this for a Debian package? (I guess something like "Provides: foo (= 3.14), bar (= 2.72)" can help a little, but what about the main package?) So basically my question is the one in the mail subject : how does one package a multirepo project? Cheers, JP PS: and to package the next ipywidgets, I started to work on lumino ( https://github.com/jupyterlab/lumino) with the same problem. In my experiments I numbered the main package 0~20200824+git93880412-1... which is not ideal.
Re: Build-Depends-If-Available
Hi, Le dim. 9 août 2020 à 18:16, Simon McVittie a écrit : > Unfortunately, to the best of my knowledge, this is currently the least bad > thing to do. > if the current practices/software doesn't give enough leeway, perhaps we should seek to improve the situation. How would that fly if there were a B-dep list for the source package, and optional B-dep lists for binary packages? Cheers, JP >
Packaging minetest mods
Hi, I have packaged a few mods for the minetest game these last years. Recent minetest versions have a feature where you can download mods directly online. So the questions are : (1) should I go on updating the existing packages? or ask for their removal? orphan them? whatever? (2) should I go on packaging new things for minetest? Do we have a policy for such situations? Wesnoth has the same kind of feature, for example, and doesn't look like it comes with much in the way of in-Debian add-ons... Cheers, JP
Re: Lintian status reporting on packages overview broken?
Hi, Le jeudi 18 juin 2020 à 09:21 +0200, Gard Spreemann a écrit : > It seems to me that the "Lintian E+W" column on the QA packages > overview > page currently incorrectly shows a checkmark even when there are > Lintian > warnings for a package. Is this a known bug? I was about to ask around why on tracker.debian.org, we still get the number of lintian warnings, but the link to those warnings is broken. Perhaps the two issues are related? JP
Re: Pimp your shell - Debian developer tips?
Le mercredi 27 mai 2020 à 22:06 +0300, Otto Kekäläinen a écrit :
> Do we have Debian devs here who have pimped their shell heavily with
> custom prompts, colors, command line fonts, shell window title hacks,
> perhaps using zsh etc? Have you written blogs about you experiences,
> can you share some good reads (with screenshots) of what you have
> done?
I don't know where I got that one, but I have a "myautopkgtest" script
containing only:
autopkgtest $1 -- schroot unstable-amd64-sbuild
and in my .bashrc :
_myautopkgtest()
{
local cur=${COMP_WORDS[COMP_CWORD]}
COMPREPLY=( $( compgen -f -X '!*.dsc' -- $cur ) )
return 0
}
complete -F _myautopkgtest myautopkgtest
That's a pretty trivial hack, but it does save quite a few keystrokes,
when one checks a package before an upload.
Cheers,
JP
Re: Question for alioth-lists.debian.net status
On Sat, Apr 25, 2020 at 00:51:34 +0800, Shengjing Zhu wrote: > And another question for DSA is, whether the lists.alioth.debian.org > address is expected to work, as long as the alioth-lists.debian.net > exists? > I don't see a reason to break it. Cheers, Julien
Re: What to do when DD considers policy to be optional? [kubernetes]
Le mardi 24 mars 2020 à 14:03 +0100, Vincent Bernat a écrit : > > There are other reasons, notably that you speed up builds by having > all > the source code ready. Sorry, I don't know much about how go works, but : can't the developer just have the deps ready -- and just not commit them to the repo and not ship them? >From what I have read in this thread, go developers seem to be about as sloppy as javascript ones : put junk together and throw it to the world... J.Puydt
Re: RFC: Replacing vim-tiny with nano in essential packages
On Mon, Mar 16, 2020 at 11:06:11AM +0100, John Paul Adrian Glaubitz wrote: > Debian Ports is affected by this problem in particular because we don't have > the cruft feature in mini-DAK [3], so every time I build a debian-installer > image and forget checking whether vim build successfully on every > architecture, > the particular debian-installer image becomes unusable because debootstrap > cannot install vim-tiny as its version mismatches the version of vim-common. > The debian-ports archive maintainers could decide to change vim-tiny's priority on their side, without imposing that decision on the debian archive. Cheers, Julien
Re: trimming changelogs
Hi, Le vendredi 20 mars 2020 à 07:44 +0100, Ansgar a écrit : > > We should probably also not ship the same changelog in multiple > packages, especially when one depends on the other. > Switching to per src:package changelogs would cover that. But that will probably mean making dpkg smarter. J.Puydt
Re: Migration to testing blocked by broken piuparts?
On Thu, Jan 2, 2020 at 12:03:43 +0100, W. Martin Borgert wrote: > Hi, > > two packages[¹, ²] I uploaded are "Rejected due to piuparts > regression". I learned, that this is due to a bug in piuparts. > Any solution on its way? Would I need to re-upload later? > No, it'll eventually get retried and (assuming it passes) the migration block will lift. Cheers, Julien
Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?
On Tue, Sep 10, 2019 at 08:24:03 +0200, Ondřej Surý wrote: > > On 9 Sep 2019, at 15:31, Bjørn Mork wrote: > > > > I for one, do trust my ISPs a lot more than I trust Cloudflare or > > Google, simply based on the jurisdiction. > > While I still strongly agree with you on this one (even though I think all > major ISPs here are scumbags, especially the incumbent), I still strongly > think we should not have this debate here, and we should turn this around > the usual Debian policy - to not send data to 3rd party without explicit user > content and defaulting to not doing so. > How is this worse than what we're already doing by default, namely sending the same data to whoever happens to be on the network, in addition to whoever happened to be listed in an unauthenticated dhcp response? (Which, if you're lucky, is your ISP, aka a 3rd party.) Cheers, Julien
Re: buster backports question/status
On Wed, Jul 10, 2019 at 11:29:01 +0200, olivier sallou wrote: > Le mer. 10 juil. 2019 à 11:08, Andrey Rahmatullin a > écrit : > > > On Wed, Jul 10, 2019 at 10:54:21AM +0200, olivier sallou wrote: > > > So, am I doing something wrong? > > You tried to install a package (what package? they don't exist) from a > > repo that doesn't exist. > > > > I tried a package that is not in backports, it was just for test (for an > automation tool I use) > It should fail with a *package not found* , but should not fail about > buster-backports being non available. > > Is the problem linked to buster-backports not existing yet ? Is backports > repo not created automatically on new releases? > buster-backports exists. AIUI this is an apt bug when dealing with empty repos. (Although why are you setting default-release to buster-backports?) Cheers, Julien
Re: Bug#824495: Use of the Build-Conflicts field
On 2/16/19 7:08 AM, Scott Kitterman wrote: > On Friday, February 15, 2019 08:59:41 PM Sean Whitton wrote: >> Hello, >> >> Use of the Build-Conflicts field is currently mostly optional, but Ian >> Jackson and I have been working on text for Debian Policy that would >> require its use in certain cases. See #824495 for the discussion. >> >> There are two cases which we think that everyone would agree that there >> is a bug, but we are not sure that the bug would be considered to be RC. >> We are posting to -devel to see if, in fact, we do have a consensus that >> these bugs would be RC, or not. >> >> (1) a package FTBFSs when: another package that is part of a "reasonable >> standard development workstation install" is present, but the first >> package does not declare a Build-Conflicts against the second >> >> (2) a package FTBFSs when: a package that is NOT part of a "reasonable >> standard development workstation install" is present, but the first >> package does not declare a Build-Conflicts against the second >> >> Is (1) an RC-severity bug in the package that FTBFSs? Is (2)? >> >> It is worth noting that in both cases, the fix is highly non-disruptive >> to maintainer workflows: you just add the build-conflicts metadata. But >> how easy it is to fix the bug does not determine whether or not that bug >> is RC. >> >> For the purposes of this e-mail, let's assume that we have a good grasp >> on what a "reasonable standard development workstation install" means. > > I'll bite. > > I think "reasonable standard development workstation install" is the wrong > class of standard (whether I have a grasp on it or not). If it's not going > to > cause an FTBFS on a buildd, I think it's not RC. That would limit it to > packages that are build-depends (direct or indirect) of other packages, i.e. > no leaf packages. > > So my answer to both your questions is no. > +1 I'd say (1) and (2) range somewhere from minor to normal severity. Cheers, Julien
Re: Reusing source package name of long-removed, unrelated package
On 2/6/19 4:31 PM, Gard Spreemann wrote:
>
> Ian Jackson writes:
>
>> Gard Spreemann writes ("Reusing source package name of long-removed,
>> unrelated package"):
>>> I understand that 3.3.2 of the policy mandates that I at least bump the
>>> epoch, but I wanted to ask the list to make sure: is reusing the source
>>> package name of an unrelated, long-removed package like this OK, or
>>> should I consider using a different name?
>>
>> I would recommend using a different source package name.
>
> Thanks for your input. I'll wait a bit and see if there are other
> opinions before renaming the source.
>
> By the way, is it OK if the (renamed) source package produces a binary
> package with the same name as one of those produced by the old source?
>
I would say reusing binary package names is usually worse than reusing
source package names, in that it's a lot more likely to affect users.
Sometimes it happens anyway, but IMO it's best avoided.
Cheers,
Julien
Re: Bug#913976: ITP: python-hgapi -- module providing a pure-Python API to Mercurial
On 11/17/18 9:23 PM, Nick Morrott wrote: > Package: wnpp > Owner: Nick Morrott > Severity: wishlist > X-Debbugs-CC: debian-devel@lists.debian.org > > * Package name: python-hgapi > Version : 1.7.3 > Upstream Author : Fredrik Håård > * URL : https://github.com/haard/hgapi > * License : Expat > Programming Lang: Python > Description : module providing a pure-Python API to Mercurial > > hgapi is a pure-Python API to the Mercurial command-line, instead of the > internal Mercurial API. > > hgapi works for all versions of Mercurial, and will instantly reflect any > changes to the repository (including hgrc). > > hgapi is a dependency of yotta [1] > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908781 > Is there a particular reason yotta needs to use this instead of hglib, which: - is already in debian - is maintained by mercurial upstream - has pretty much the exact same package description as the above ? This seems like useless duplication. Thanks, Julien
Re: Perl 5.28 transition underway
On 12/7/18 4:34 PM, Cyrille Bollu wrote: > The URL https://release.debian.org/transitions/html/perl5.28.html is > 404 :-( > With Perl 5.28 in testing, the transition is over. Cheers, Julien
Re: Deployment of buildd machines [was: Re: usrmerge -- plan B?]
On 11/28/18 2:26 PM, Daniel Reichelt wrote: > On 11/22/18 1:56 PM, Ian Jackson wrote: >> (Bear in mind of course that happily our build machines >> *can* be reverted because they are frequently re-imaged.[…]) > > Using code from a debian package? Some script being hand-knitted using > hot needles? Anyways, I'm interested in how this is done…"this" meaning > the imaging/deployment part. Not the setup/configuration of a buildd itself. > The machines are not re-imaged. The build chroots are regenerated, with something more or less equivalent to sbuild-createchroot(8). https://salsa.debian.org/dsa-team/mirror/dsa-puppet/tree/master/modules/schroot/ Cheers, Julien
Re: Upcoming Qt switch to OpenGL ES on arm64
On 11/23/18 12:18 PM, Dmitry Shachnev wrote: > On Thu, Nov 22, 2018 at 11:05:27PM +0100, Julien Cristau wrote: >> At least mesa drivers can be used for desktop GL or GLESv2 just fine, >> AFAIK. Maybe the answer for Qt is to switch to GLESv2 for all >> architectures, to stop the special-casing madness, instead of making it >> spread? :) > > According to config_help.txt [1], Qt uses ES2 by default on Windows. > It probably means that it will work fine with most desktop video cards. > > But as Lisandro says, such a change in Debian will break many packages > (which are currently broken on ARM only), so we are definitely not > considering it at this point. > Why is it OK to break them on arm64 if it's not OK to break them on amd64? Do you have a list of those packages? Cheers, Julien
Re: Upcoming Qt switch to OpenGL ES on arm64
On 11/22/18 10:30 PM, Marcin Juszkiewicz wrote: > W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze: > >> The Qt framework can be built either with “desktop” OpenGL, or with OpenGL ES >> support. At the moment we are building it with OpenGL ES on armel and armhf, >> and with desktop OpenGL on all other architectures. >> >> However we have received a request [1] from two different persons to add >> arm64 >> to the list of architectures where OpenGL ES is used. >> >> We want your feedback! If you are using an arm64 device or board with Qt, >> please let us know your opinion about this change, by replying to this mail >> or to [1], and describe your use case. > > Does it mean that arm64 box with PCI Express graphics card will be not > able to use Qt based software? I can put Radeon or NVidia card into my > box and use it as a normal OpenGL accelerated desktop (did that already > few years ago). > At least mesa drivers can be used for desktop GL or GLESv2 just fine, AFAIK. Maybe the answer for Qt is to switch to GLESv2 for all architectures, to stop the special-casing madness, instead of making it spread? :) Cheers, Julien
Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]
On 09/09/2018 03:46 AM, Guillem Jover wrote: > Hi! > > On Sat, 2018-09-08 at 20:18:10 +0200, Sylvestre Ledru wrote: >> Le 08/09/2018 à 18:39, Sean Whitton a écrit : >>> On Fri 07 Sep 2018 at 10:10PM +0200, Ruben Undheim wrote: >>>> However, I think the policy gives us a lot of freedom to choose (it >>>> is not very strict in this case). >>> >>> I don't understand. This seems pretty strict: >>> >>> Two different packages must not install programs with different >>> functionality but with the same filenames. > >> I think the policy should be changed. > > I'd very very strongly oppose any such change. > Ditto. Cheers, Julien
Re: Browserified copy and DFSG
On 09/05/2018 04:38 PM, Bastien ROUCARIES wrote: >>> Browserify (or webpack) is a static compiler for javascript. I believe >>> that we must use built-using field in order to be policy compliant. >>> [...] > But I was thinking Built-Using may be used by security team in order > to trigger rebuild. > That should not be necessary. If we really needed that information (which seems unlikely to me), buildinfo files can provide it. Otherwise we'd set built-using to "everything in the build chroot" for every single package, and that doesn't seem like something we want or need to do. browserify doesn't seem to be that special, IMO. Cheers, Julien
Bug#907533: ITP: node-snapdragon-token -- Create a snapdragon token
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-snapdragon-token Version : 4.0.0 Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert) * URL : https://github.com/jonschlinkert/snapdragon-token * License : Expat Programming Lang: JavaScript Description : Create a snapdragon token This package provides a snapdragon token builder ; it is used by the snapdragon lexer, but also by snapdragon plugins. . Snapdragon is a framework to build parsers and compilers with built-in source-map support. . Node.js is an event-based server-side javascript engine. It is needed to update the node-split-string package. Snark on #debian-js
Bug#906272: ITP: minetest-mod-intllib -- Minetest module for internationalization of modules
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: minetest-mod-intllib Version : 20180811 Upstream Author : Diego Martinez * URL : https://github.com/minetest-mods/intllib * License : Unlicense Programming Lang: lua Description : Minetest module for internationalization of modules This Minetest module provides a framework to internationalize other minetest modules. It doesn't provide translations for other modules, but it makes it possible for them to use their own translations. I plan to maintain it with my other minetest-mod-* packages within the Debian Games Team. Cheers, jpuydt on irc.debian.org
