Re: ifupdown maintenance
Hello, I've gone ahead with the override switch. I think it is appropriate to use an override change to try to get some momentum behind this transition. And we are at a point in the release cycle where it is not a big deal to switch it back if it turns out there is unsolveable breakage. (by the way, after reading the package description, I lowered the priority of isc-dhcp-common too) -- Sean Whitton signature.asc Description: PGP signature
Re: ifupdown maintenance
Hello Santiago, What are your current intentions in this area? Do you want to make the change for trixie? If not, I'd like to close the override change bug for now. Thanks. -- Sean Whitton
Re: Representing Debian Metadata in Git
Hello, I think that more than you realise of this already exists :) On Tue 20 Aug 2024 at 04:10pm +09, Simon Richter wrote: > From a requirements perspective, I'd like to be able to > > - express patches as commits: >- allow cherry-picking upstream commits as Debian patches >- allow cherry-picking Debian patches for upstream submission git-debrebase and git-dpm already achieve this. > - express filter steps for generating the upstream archive(s) from a tree‑ish > and some metadata Excluded-Files in d/copyright is for this. I guess that you disprefer that because it's part of the tree, though. > - store upstream signatures inside Git Well, there's signatures on their tags. > - keep a history of patches, including patches applied to previously released > packages This is already there with git-debrebase and git-dpm, though it is a bit fiddly to dig it out. -- Sean Whitton signature.asc Description: PGP signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
[resending to your correct address] Hello, On Mon 05 Aug 2024 at 06:14am +05, Andrey Rakhmatullin wrote: > It's similar but different: I'm talking about workflows to build a package > from the repo (e.g. "gbp with gbp-pq and importing upstream tarballs"). > And yeah it could be a metadata field. Just to note that once people are using tag2upload, this information will start being recorded on salsa, as a side-effect. I've filed #1078016 about exposing this information in a machine-readable way. -- Sean Whitton
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Hello, On Mon 05 Aug 2024 at 06:14am +05, Andrey Rakhmatullin wrote: > It's similar but different: I'm talking about workflows to build a package > from the repo (e.g. "gbp with gbp-pq and importing upstream tarballs"). > And yeah it could be a metadata field. Just to note that once people are using tag2upload, this information will start being recorded on salsa, as a side-effect. I've filed #1078016 about exposing this information in a machine-readable way. -- Sean Whitton signature.asc Description: PGP signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Hello, On Sat 03 Aug 2024 at 11:29am -07, Soren Stoutner wrote: > 1. Debian workflows are too fractured. The project would be better if we > asked people > to standardize around a single (or a small number) of workflows. To do so, > the workflow > would need to be flexible enough to handle the wide range of technical needs > of all the > packages and upstream configurations. > > 2. Standardizing around a single (or small number of) workflows will make > some people > unhappy. But that is an acceptable price to pay because of the general > benefit to the > project as long as the correct solution is adopted. Unity is more important > than minority > opinions on this particular issue. > > 3. I do not yet have the wisdom to ascertain what the correct solution is. > Until I do, I > applaud those who attempt to push this discussion forward, and I follow it > closely, but I > haven’t commented. I think adopting an incorrect mandated (or maybe even > recommended) workflow is worse than the fractured status quo. We need to distinguish different workflows or workflow stages. There is the git hosting workflow -- gitlab vs. github vs. personal server. This seems solely about what people like to use. I agree with you that we should probably pick just one of these -- not even a small number. But there is also the git->dsc workflow -- gbp vs. dpm vs. debrebase vs. debcherry. The crucial difference is that in this area it's not just personal preferences, but that different packages have different needs. A small Python library is vastly different to, say, SBCL or Xen. My two favourite git->dsc workflows are documented in dgit-maint-merge(7) and dgit-maint-rebase(7). These manpages include some explanations as to what sort of packages are best suited to each of them. -- Sean Whitton signature.asc Description: PGP signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Hello, On Sat 03 Aug 2024 at 09:19am +02, PICCA Frederic-Emmanuel wrote: > Hello, I like the dgit idea, produce a git repository for people who want to > use git and let other use whatever they want. > > Maybe uploading a paquage to Debian could push automatically into dgit. (maybe > this is already the case) If the upload is done with dgit or tag2upload this is already the case. For other uploads, 'dgit clone' constructs the dgit view on-the-fly. We could consider having this done in advance. It would make 'dgit clone much faster' and it would enable importing into salsa as you also suggest. -- Sean Whitton signature.asc Description: PGP signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Hello, On Sat 03 Aug 2024 at 08:26am +02, Jonas Smedegaard wrote: > My problem with DEP-18 is that people who have zero problem with using > git and are also not fundamentally against using salsa, but have > reservations surrounding *which parts* of salsa to use and the > consequences for related already used tooling. This describes me. I use and am enthusiastic about git, and when the workflow is not obvious from team policy or whatever, I document it in README.source. I took time to write up the complex workflow emacs.git uses (not developed by me) precisely so that more people could become involved. I am happy to use salsa for git hosting and access management. I love that I can easily grant push access to my non-DD team members. But, I turn off salsa MRs for the repos of all packages I regularly upload. I would hope that this DEP can be written such as to account for these sorts of choices. -- Sean Whitton
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Yes, tag2upload. It’s almost ready :) Please wait a little longer. -- Sean Whitton Please excuse top-posting and brevity. I am writing to you from a mobile phone. > On 1 Aug 2024, at 20:43, Charles Plessy wrote: > > Le Thu, Aug 01, 2024 at 12:23:43PM +0100, Luca Boccassi a écrit : >> >> run a CI before uploading, even a very basic one is just fine, better >> than nothing. > > Thanks for the remider ! I will have a closer look at Salsa CI instead > of trying to understand how to run autopkgtests locally. > > Would there be a way to get Salsa upload and tag the package if the CI > tests pass and the changelog signals a release? Or does somebody has a > script which can screen a Salsa group for ready uploads, and run clone > && buildpackage && dput automatically ? > > Cheers, > > Charles > > -- > Charles Plessy Nagahama, Yomitan, Okinawa, Japan > Debian Med packaging team http://www.debian.org/devel/debian-med > Tooting from work, https://fediscience.org/@charles_plessy > Tooting from home, https://framapiaf.org/@charles_plessy >
Re: git tooling to handle files-excluded while preserving upstream history
Hello, On Tue 16 Jul 2024 at 03:28pm +02, Daniel Gröber wrote: > Right, thanks for the link. That certainly is one angle of attack and I > hope someone does tackle it given how popular gbp is, but it's not the only > game in town. > > Personally I'm moving away from gbp toward the dgit patches-applied > workflows so I'd be interested in something that can work there (too?). > > A quick chat with Ian on IRC illuminates the situation: git-deborig > (dgit/t2u's equivalent of gbp-export-orig) can't directly do this as it > would break dgit's "tarball equals git exactly" invariant. > > This needs do be done as a seperate tool that commits the removals into > git. I think the same tool could also work for the gbp case unless I'm > missing something. > > If nobody has a tool like that in the works yet I may have a stab at it. > > If anyone has any spare cycles I'd also like us think about how a > full-blown git-filter-branch/-repo invocation would fit into the picture so > perhaps the interface could handle those in the future. I do a manual 'git rm', commit, and make a upstrea/foo+dfsg tag. It's not great. Automation would be nice. -- Sean Whitton signature.asc Description: PGP signature
Re: DEP17 /usr-move: debootstrap set uploaded
Hello, On Thu 06 Jun 2024 at 11:25am -06, Gunnar Wolf wrote: > Let me chime in with all of the people that have been amazed at your > depth of analysis and your commitment to implementing the *properly > right* situation. It cannot be overstressed that, for this release > cycle, one of the main reasons Debian will probably keep its honor > badge of being easy and reliable to upgrade without breakage is the > work you have taken as yours. This is a great way to put it. Helmut's dedication to this was particularly clear from working with him on it from the TC side. We have benefitted repeatedly from his careful analysis. -- Sean Whitton
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
Hello, On Sun 19 May 2024 at 10:05am +02, Paul Gevers wrote: > > PS: I've always wondered if the dgit server shouldn't track history, even if > uploads don't happen via it. A dgit clone could (should?) already provide > available history, even if no upload happened via it yet. Well, 'dgit clone' adds a vcs-git remote pointing at the maintainer's history. So it sort of does this. We could make it do more. -- Sean Whitton signature.asc Description: PGP signature
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
Hello, On Sun 19 May 2024 at 12:32pm -07, Otto Kekäläinen wrote: > You could go to > https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 and > conduct a code review? > > You might discover that GitLab is useful and is not duplicating > Debbugs or anything else in Debian - it is currently the only platform > to conduct code reviews on in a way that has automatic testing and > comment-response-resolved -tracking. Doing code reviews patches > attached in email does not have that. > > If you try it out, and still think Salsa is bad for Debian, then I am > more willing to accept your stanze. I have tried it out, and am happy for those maintainers that like it to use it, but I do not want to maintain most of my packages that way. I want people to send me patches to the BTS / project ML. -- Sean Whitton signature.asc Description: PGP signature
Re: Silent hijacking and stripping records from changelog
Hello, On Thu 18 Apr 2024 at 09:44pm +02, Jonas Smedegaard wrote: > I am unaware if I am alone in maintaining Haskell packages outside of > the team giant-git-repo thingy. I wouldn't maintain libraries outside of the monorepo but typically programs are maintained outside of it. I maintain git-annex and git-repair outside of the monorepo. -- Sean Whitton signature.asc Description: PGP signature
Re: debian-policy: clarify requirement for use of Static-Built-Using
Hello Go and Rust packagers, On Thu 18 Apr 2024 at 11:29pm +03, Maytham Alsudany wrote: > With the increasing amount of programs in Debian that Build-Depend and > statically link with Golang and Rust libraries, it's important that > the Debian Policy clearly sets out the requirements for declaring > these statically-linked libraries. I think Maytham is right that updating Policy for this is a priority. It has been bothering me that misunderstandings of Built-Using have been proliferating somewhat among newer contributors. See also #999785. Could you take a look at his proposed changes to Policy in #1069256, please, and confirm they successfully reconcile Debian Policy with your team policies? I think that we should also include an explanation of why we have chosen to do this using a new field in d/control like Static-Built-Using. Policy is meant to be a record of our lessons learned in building a distribution, and the lessons learned in trying to handle these new hyper-statically linked language ecosystems seem important. My immediate question is why the Haskell and OCaml team's approaches, were not copied. They seem to work well and don't require a new field. That seems worth writing down. Thank you Maytham for your work so far. -- Sean Whitton signature.asc Description: PGP signature
Re: New supply-chain security tool: backseat-signed
Hello, On Sat 06 Apr 2024 at 02:24pm +02, Guillem Jover wrote: > Hi! > > On Sat, 2024-04-06 at 19:13:22 +0800, Sean Whitton wrote: >> On Fri 05 Apr 2024 at 01:31am +03, Adrian Bunk wrote: >> > Right now the preferred form of source in Debian is an upstream-signed >> > release tarball, NOT anything from git. >> >> The preferred form of modification is not simply up for proclamation. >> Our practices, which are focused around git, make it the case that >> salsa & dgit in some combination are the preferred form for modification >> for most packages. > > People keep bringing this up, and it keeps making no sense. I've > covered this over the years in: > > https://lists.debian.org/debian-devel/2014/03/msg00330.html > https://lists.debian.org/debian-project/2019/07/msg00180.html > > (There's in addition the part that Adrian covers in another reply.) I understand this point of view. The situation is not clear. But it is at least plausible that for some projects, the git history is part of the preferred form for modification. It is certainly not always true. I think that this point is largely academic, however. We are doing a disservice to our users if they have to go hunting beyond Debian services to find the upstream git history, because they'll likely want it if they indeed do want to modify packages installed on their system. Our own git histories of packaging changes aren't enough. So we should be hosting both, on some combination of salsa and dgit-repos. -- Sean Whitton signature.asc Description: PGP signature
Re: New supply-chain security tool: backseat-signed
Hello, On Sat 06 Apr 2024 at 02:42pm +03, Adrian Bunk wrote: > On Sat, Apr 06, 2024 at 07:13:22PM +0800, Sean Whitton wrote: >> Hello, >> >> On Fri 05 Apr 2024 at 01:31am +03, Adrian Bunk wrote: >> >> > >> > Right now the preferred form of source in Debian is an upstream-signed >> > release tarball, NOT anything from git. >> >> The preferred form of modification is not simply up for proclamation. >> Our practices, which are focused around git, make it the case that >> salsa & dgit in some combination are the preferred form for modification >> for most packages. > > You cannot simply proclaim that some git tree is the preferred form of > modification without shipping said git tree in our ftp archive. > > If your claim was true, then Debian and downstreams would be violating > licences like the GPL by not providing the preferred form of modification > in the archive. Well, maybe we are! Or maybe we're not when we publish those histories on salsa and/or dgit-repos. It also seems important to note that this is project-specific. Whether the git history is part of the preferred form of modification depends on the project's practices and content. I don't have a settled opinion on what we should be doing. But what I am sure about is that the preferred form for modification is determined by the content of the project, and we can't change what the preferred form for modification actually is just by choosing what exactly we publish. -- Sean Whitton signature.asc Description: PGP signature
Re: Validating tarballs against git repositories
Hello, On Fri 05 Apr 2024 at 03:19pm +01, Simon McVittie wrote: > There are basically three dgit-compatible workflows, with some minor > adjustments around handling of .gitignore files: > > - "patches applied" (git-debrebase, etc.): > This is the workflow that proponents of dgit sometimes recommend, > and dgit uses it as its canonicalized internal representation of > the package. > The git tree is the same as `dpkg-source -x`, with upstream source code > included, debian/ also included, and any Debian delta to the upstream > source pre-applied to those source files. > In the case of bubblewrap, if we used this workflow, after you clone > the project, bubblewrap.c would already have the Debian-specific error > message. > (dgit --split-view=never or dgit --quilt=dpm) > > - "patches unapplied" (gbp pq, quilt, etc.): > This is the workflow that many of the big teams use (at least Perl, > Python, GNOME and systemd), and is the one that bubblewrap really uses. > The git tree is the same as `dpkg-source -x --skip-patches`, with > upstream source code included, and debian/ also included. > Any Debian delta to the upstream source is represented in debian/patches > but is *not* pre-applied to the source files: for example, in the case > of bubblewrap, after you clone > https://salsa.debian.org/debian/bubblewrap.git and view bubblewrap.c, > it still has the upstream error message, not the Debian-specific one. > (dgit --quilt=gbp or dgit --quilt=unapplied; I use the latter) > > - debian/ only: > This is what you're advocating above. > The git tree contians only debian/. If there is Debian delta to the > upstream source, it is in debian/patches/ as usual. > (dgit --quilt=baredebian* family) People interested in these differences may also want to look at: <https://wiki.debian.org/GitPackagingSurvey>. > > Again, checking for that error is something that can be (and is) > automated: I use this workflow myself (e.g. in bubblewrap), so I know from > experience that dgit *does* check for that error, and will fail to build > the source package if the invariant does not hold. Again, dpkg-source > in 3.0 (quilt) format will also make your source package fail to build > if that error exists, except in the cases that it intentionally ignores. Right, both dgit and tag2upload's client-side wrapped of git-tag(1), git-debpush(1), do this check. -- Sean Whitton signature.asc Description: PGP signature
Re: New supply-chain security tool: backseat-signed
Hello, On Fri 05 Apr 2024 at 01:31am +03, Adrian Bunk wrote: > > Right now the preferred form of source in Debian is an upstream-signed > release tarball, NOT anything from git. The preferred form of modification is not simply up for proclamation. Our practices, which are focused around git, make it the case that salsa & dgit in some combination are the preferred form for modification for most packages. -- Sean Whitton signature.asc Description: PGP signature
Bug#1068094: RFH: sbcl -- Common Lisp compiler and development system
Package: wnpp Severity: normal X-Debbugs-Cc: s...@packages.debian.org, debian-devel@lists.debian.org, debian-emac...@lists.debian.org Control: affects -1 + src:sbcl I request assistance with maintaining SBCL in Debian. It is the most popular Free Software compiler for Common Lisp. So, most anyone who is interested in both Debian and Common Lisp is likely interested in SBCL, too. The upstream project is stable but seems relatively often to introduce changes that break our packaging scripts. Possibly there should be an attempt made to simplify how we do things. This would be good for a new contributor to Debian who is otherwise experienced with bootstrapping compilers / development environments. You definitely don't need to be a Debian Developer to help. The package description is: SBCL is a development environment for the ANSI Common Lisp language. It provides a native-code compiler and an integrated debugger, as well as all the features in the ANSI specification. . SBCL also contains other extensions to the ANSI specification, including a foreign-function interface, a pseudo-server API, user-extensible stream functionality, a Meta-Object Protocol, and an ability to run external processes. . To browse SBCL source definitions with development environments, install the sbcl-source package. For documentation on SBCL's usage and internals, the package sbcl-doc is provided. -- Sean Whitton signature.asc Description: PGP signature
Re: Validating tarballs against git repositories
Hello, On Sat 30 Mar 2024 at 12:19pm +01, Simon Josefsson wrote: > Relying on signed git tags is not reliable because git is primarily > SHA1-based which in 2019 cost $45K to do a collission attack for. We did some analysis on the SHA1 vulnerabilities and determined that they did not meaningfully affect dgit & tag2upload's design. -- Sean Whitton signature.asc Description: PGP signature
Re: Validating tarballs against git repositories
Hello, On Sat 30 Mar 2024 at 10:56am +01, Iustin Pop wrote: > On 2024-03-30 08:02:04, Gioele Barabucci wrote: >> Now it is time to take a step forward: >> >> 1. new upstream release; >> 2. the DD/DM merges the upstream release VCS into the Debian VCS; >> 3. the buildd is notified of the new release; >> 4. the buildd creates and uploads the non-reviewed-in-practice blobs "source >> deb" and "binary deb" to unstable. >> >> This change would have three advantages: > > I think everyone fully agrees this is a good thing, no need to list the > advantages. It is also already fully implemented as tag2upload, and is merely as yet undeployed, for social reasons. -- Sean Whitton
Re: Validating tarballs against git repositories
Hello, On Fri 29 Mar 2024 at 06:21pm -06, Antonio Russo wrote: > 1. Move towards allowing, and then favoring, git-tags over source tarballs Many of us already do this. dgit maintains an official store of the tags. -- Sean Whitton
Re: ITP: gtk-gnutella -- The Most Efficient Gnutella Client
Hello, On Fri 29 Mar 2024 at 01:44am GMT, Colin Watson wrote: > On Fri, Mar 29, 2024 at 09:28:44AM +0800, Sean Whitton wrote: >> On Thu 14 Mar 2024 at 01:29pm GMT, Jonathan Dowland wrote: >> > I took a peek, out of curiosity. I was surprised not to find a >> > orig.tar.gz / debian.tar.gz split; the package version scheme >> > properly reflects a normal (non-native) package (1.2.3-1), but >> > the source tarball has "./debian" in it; and indeed, it looks >> > like you're managing the debian packaging in the upstream repo. >> > It's advisable to keep the two separate. >> >> Not everyone agrees with this. I think that same repo, non-native >> versioning is often what's best for a package. > > While it's true that some people do hold that position, the problem with > it has always been that it gets extremely cumbersome the moment that > maintenance of the Debian packaging passes to somebody who doesn't have > upstream commit access. This event is traditionally followed by > cursing. I've been on both sides of this -- upstream maintainer doing Debian packaging, and adopting a package previously maintained by its upstream -- and I really appreciated the simplicity in the former role, and found it just one of the various small tasks involved in adopting the package in the latter role. I think it's easier now we treat source packages as an output format, thanks to git. -- Sean Whitton signature.asc Description: PGP signature
Re: ITP: gtk-gnutella -- The Most Efficient Gnutella Client
Hello, On Thu 14 Mar 2024 at 01:29pm GMT, Jonathan Dowland wrote: > On Wed Mar 13, 2024 at 6:52 PM GMT, Lucio Marinelli wrote: >> gtk-gnutella is a server/client for the Gnutella peer-to-peer network. >> It was previously included in Debian repository. >> The source code is hosted in Github: >> https://github.com/gtk-gnutella/gtk-gnutella >> I already prepared the .deb package here: >> https://sourceforge.net/projects/gtk-gnutella/files/gtk-gnutella/1.2.3/ > > I took a peek, out of curiosity. I was surprised not to find a > orig.tar.gz / debian.tar.gz split; the package version scheme > properly reflects a normal (non-native) package (1.2.3-1), but > the source tarball has "./debian" in it; and indeed, it looks > like you're managing the debian packaging in the upstream repo. > It's advisable to keep the two separate. Not everyone agrees with this. I think that same repo, non-native versioning is often what's best for a package. -- Sean Whitton signature.asc Description: PGP signature
Re: The Technical Committee needs you!
Hello Kunal, Thank you for your message. Unfortunately, only existing DDs can nominate themselves for this. -- Sean Whitton signature.asc Description: PGP signature
Re: What licenses should be included in /usr/share/common-licenses?
Hello Russ, Thank you for working on this. On Sat 09 Sep 2023 at 08:35pm -07, Russ Allbery wrote: > In order to structure the discussion and prod people into thinking about > the implications, I will make the following straw man proposal. This is > what I would do if the decision was entirely up to me: > > Licenses will be included in common-licenses if they meet all of the > following criteria: > > * The license is DFSG-free. > * Exactly the same license wording is used by all works covered by it. > * The license applies to at least 100 source packages in Debian. > * The license text is longer than 25 lines. Something that hasn't been brought up yet is the effects on NEW review. I would like to expand the idea of the same license wording being used by all works, to include the additional requirement that there aren't any very similar licenses that are easily confused with the license. For, if it's a license with small variations of any kind, including variations that are not project-specific things like the names of copyright holders, then NEW review is much easier if all the text is right there in d/copyright. I would be in favour of the 25 lines criterion. The main problem with manipulating d/copyright is only the really long licenses, IME. -- Sean Whitton signature.asc Description: PGP signature
Re: Developer Workload and Sustainability
Hello, On Fri 30 Jun 2023 at 12:31PM +02, Ansgar wrote: > We've had a decade of that about systemd, probably more if one looks at > Pulseaudio, GNOME and other things. Eventually we might reach a point > where we might want to stop that. Sadly I don't see you asking for that > to happen, rather the opposite. Let me just note that you're lumping together a number of distinct projects here, which is not fair to the sysvinit people in this thread. > Does that help? I tried to write in the helpful style the mail I > replied to uses. I don't think sarcasm is constructive in this sort of contentious discussion. -- Sean Whitton signature.asc Description: PGP signature
Re: Developer Workload and Sustainability
Hello, On Wed 28 Jun 2023 at 06:17PM +01, Luca Boccassi wrote: > Let's look at some community numbers for two init system projects in > question, we like to look at hard data after all, don't we. To spicy > it up, without mentioning which is which: > > $ git shortlog -s | cut -c8- | wc -l > 2318 > > $ git shortlog -s | cut -c8- | wc -l > 7 > > Just from this alone, it certainly seems true that one of those is a > project that "fails as a community project" and that is "not > hospitable to community building efforts". Anyone want to guess which > is which? It's understandable that you'd feel frustrated by what seems like a misrepresentation of your project's organisation and ethos, but please try to avoid this sort of rhetoric. You can just as well present the git statistics without hiding the author's names for rhetorical effect, or asking rhetorical questions, and it would keep the temperature of the discussion lower. -- Sean Whitton signature.asc Description: PGP signature
Re: Developer Workload and Sustainability
Hello, On Wed 28 Jun 2023 at 06:20PM +02, Ansgar wrote: > On Thu, 2023-06-29 at 00:32 +0900, Simon Richter wrote: >> According to Policy as currently published, systemd units are >> encouraged, and init scripts are mandatory. > > Please stop lying: Please assume good faith. There is no reason to think Simon would be lying about what he thinks is in Policy. It's a mistake, not a lie. > The real exhausting thing is people lying, FUD, spreading conspiracy > theories (ominous commercial sponsors (Rothschilds? Soros?)), endless > revisiting of decisions (should we prepare to revert usrmerge because > the attention of ominous commercial sponsors might shift elsewhere?), > claiming systemd is rot/cancer/an infection/the Windows registry and so > on. Perhaps people are spreading conspiracy theories like this about systemd outside of Debian. But people are not doing that on Debian lists, so the quoted text from your message seems entirely off-topic. -- Sean Whitton signature.asc Description: PGP signature
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
Hello, On Wed 10 May 2023 at 11:47PM +02, Ansgar wrote: > Cool, then let's ask tech-ctte. > > Dear ctte, please consider overruling the dpkg maintainer to include > the patch from #994388[1]. > > Thanks, > Ansgar > > [1]: https://bugs.debian.org/994388#397 This would require a new, maintainer-overruling vote. Our existing decisions do not apply, so far as I can tell. I have written a separate message to the bug and to debian-dpkg with a proposal to avoid having to have such a vote. -- Sean Whitton signature.asc Description: PGP signature
Re: DEP 17: Improve support for directory aliasing in dpkg
Hello, On Tue 09 May 2023 at 02:07AM +01, Luca Boccassi wrote: > But again, I do think we need to try and define what it is that we > want to support here. If we are serious about it, then we should > codify it, and hold any future changes to the same standards, wherever > they may come from. If we are not willing to do this, then I have to > ask why. If we can come to some specific conclusions about what we are and are not going to support that have consensus, as part of this work, we can and should write those down in Policy. There's probably too much complexity to achieve something more general than that, however. It is completely reasonable, as you wrote in another message, to want this transition to be held to the same standards as others. -- Sean Whitton signature.asc Description: PGP signature
Re: DEP 17: Improve support for directory aliasing in dpkg
Hello, On Sun 07 May 2023 at 11:14AM +02, Ansgar wrote: > Debian's dependency system requires to explicitly declare > Depends/Conflicts/Replaces/Breaks, but for obvious reasons we cannot do > that for packages outside Debian's ecosystem. > > The same is true for diversions/alternatives/* or anything else > requiring coordination among all users: the dpkg ecosystem has too many > practical limitations to support non-Debian packages on anything but a > "it might work" basis (which is usually "good enough"). (This is even > true for packages within the Debian ecosystem, especially when one > considers partially implemented features like multi-arch.) I don't think this is the consensus view. Our derivatives are among our users, for example, and we care about them being able to add packages in appropriate ways. Our policy documents and best practices contain various provisions with user's own packages in mind. -- Sean Whitton signature.asc Description: PGP signature
Re: DEP 17: Improve support for directory aliasing in dpkg
Hello, On Sun 07 May 2023 at 12:03PM +01, Luca Boccassi wrote: > Sure, this is in the context of the ongoing discussion in the TC about > revising their side of the advice. I think it's highly unlikely that we revise it rather than just reissue it, at the present time, because too many details are unsettled. > Also, we shouldn't lose sight of the reason why this was issued in the > first place: it is designed to stop a problem from happening, and that > problem can only happen when both conditions are true. I can't read > minds obviously, but I imagine that's the reason the RT advice was > worded as it was. It's designed to stop as-yet-unknown problems happening, too. -- Sean Whitton signature.asc Description: PGP signature
Re: DEP 17: Improve support for directory aliasing in dpkg
Hello, On Sat 06 May 2023 at 09:47PM +01, Luca Boccassi wrote: > On Sat, 6 May 2023 at 19:51, Helmut Grohne wrote: >> >> > - the moratorium on moving files from bin/ sbin/ lib/ _and_ to other >> > packages at the same time is maintained from bookworm till trixie, and >> > will lifted after trixie ships, and applies implicitly to all the >> > ~2000 binary pkgs that are affected by the above >> >> While the CTTE placed the moratorium until the release of bookworm, the >> release team extended it beyond, see >> https://lists.debian.org/e1ocdqk-0005ge...@respighi.debian.org. So you >> need explicit agreement from the release team on your plan. Failing >> that, any package that has been forcefully moved is immediately >> rc-buggy due to failing a release team requirement. > > Of course the release team needs to be on board, no questions about > that. But given the idea is to maintain their decision exactly as it > stands I wouldn't imagine it would be an issue? Once again, the > moratorium is explicitly about moving between locations _and_ > packages, in combination, not either/or. From that same email you > linked: > > "Files moving their canonical location between / and /usr (details in > [1]) *and* from one binary package to another binary package within > one release cycle remain an RC issue unless dpkg supports it." > > I'm proposing to keep this in place as a general rule, with the new > escape hatch that you devised as the only addition. Actually, the morotorium is not explicitly only about moving between both locations and packages. Firstly, the TC's morotorium does not have the qualification, restricting *any* movements in data.tar.*: The Technical Committee recommends that during the Debian 12 development cycle, the maintainers of individual packages should not proactively move files from the root filesystem to the corresponding locations in /usr in the data.tar.* of packages. Files that were in /usr in the Debian 11 release should remain in /usr, while files that were in /bin, /lib* or /sbin in the Debian 11 release should remain in those directories. If files were moved from /bin, /lib* or /sbin into /usr since the Debian 11 release, they should be moved back to their Debian 11 locations. Then secondly, the RT's message is ambiguous, because it says both that they want the /TC's/ morotorium to remain in place, and also that files moving between both locations and packages is an RC issue. Until the RT's position is clarified, I think we should treat the broader prohibition as what they require. The TC are going to discuss this issue at our meeting on Tuesday, and one possible outcome is that we reissue our version of the broader prohibition. Stepping back: I am far from being an expert on the details of merged-/usr. But one thing I've noticed is that among the people who have spent the most time looking into it, the majority think that simple fixes are not going to be sufficient. Only a few people who have spent a lot of time on it still think that the fixes that are required are relatively simple ones. If the former group are wrong then the transition takes longer than it needs to, but we don't lose any confidence in the state of our users' installations. If the latter group are wrong then we'll probably end up with a longer transition anyway, and a worse situation for both our maintainers and our users. And it's within one of the areas of Debian that we're most proud of -- completely smooth upgrades between stable releases. So, I think we should assume the people who are more worried are right, for the time being. We lose little in doing so. -- Sean Whitton signature.asc Description: PGP signature
Re: Reducing allowed Vcs for packaging?
Hello, On Mon 27 Mar 2023 at 12:02AM +01, Steve McIntyre wrote: > I think you're *reaching* here. I know of quite a few projects where > they consider their CI setup to be an intergral part of project > development. Should we therefore declare that "preferred form of > modification" could include all of the github or gitlab > infrastructure? Something that I have in mind in particular is longer commit messages. These can be as important as code comments, and sometimes having them attached to commits is more useful than just finding somewhere to put them in the code. Indeed, Emacs exports all these as CHANGELOG files in its release tarballs. -- Sean Whitton
Re: Reducing allowed Vcs for packaging?
Hello, On Sat 04 Mar 2023 at 10:58PM +01, Joerg Jaspert wrote: > On 16792 March 1977, Adrian Bunk wrote: > >> for the contents of packages in the archive the ftp team requires that >> everything is in the preferred form of modification. > > Yes. Of course. > > But git or svn or even sccs and rcs is NOT, in any way, preferred for of > modification. Only one way of storage and handling some metadata. This is Debian's official position, but it's debateable. There is the preferred form for modification for an individual *file*, and that probably doesn't include version control. But the preferred form for modifying a *project* arguably does. -- Sean Whitton
Re: Reducing allowed Vcs for packaging?
Hello, On Sat 04 Mar 2023 at 07:25PM +02, Adrian Bunk wrote: > for the contents of packages in the archive the ftp team requires that > everything is in the preferred form of modification. > > It is therefore surprising that you as member of the ftp team declare > that there is no requirement at all that the packages themselves that > get uploaded to the archive are in the preferred form of modification > as long as the preferred form of modification is in salsa. That is not what I meant. We certainly want some mechanism to enforce a correspondence between preferred forms for modification and binary packages, so that we know we have the former for every one of the latter. dgit-repos and dak's archive of source packages both serve this purpose. -- Sean Whitton
Re: src:developers-reference, call for patches, bug fixes & translations
Hello, On Mon 06 Mar 2023 at 07:46PM GMT, Holger Levsen wrote: > so I've uploaded src:developers-reference 12.17 today, marking the 17th > upload during the bookworm release cycle - and I'm not done with > src:developers-reference and bookworm yet, though further updates will > only change the documentation itself and it's translations. > > During the bullseye development cycle there were 22 uploads, during > the buster development cycle 7 uploads and for stretch there were 4. > I'm not going back further, since I hope you'll get my point already: > src:developers-reference is in active maintenance again! \o/ > > & many thanks to everyone who contributed to these uploads! Thank you for your leadership, Holger. > And then, the five existing translations could use some updates: > > Stats for de: 1276 translated messages, 45 fuzzy translations, 53 > untranslated messages. > Stats for fr: 1286 translated messages, 39 fuzzy translations, 49 > untranslated messages. > Stats for it: 869 translated messages, 46 fuzzy translations, 459 > untranslated messages. > Stats for ja: 891 translated messages, 26 fuzzy translations, 457 > untranslated messages. > Stats for ru: 870 translated messages, 44 fuzzy translations, 460 > untranslated messages. I hope you won't mind me noting here that we'd also like to see Policy translated. We've got all the infra, but not too much interest in working on it so far. -- Sean Whitton
Re: Reducing allowed Vcs for packaging?
Hello, On Sun 26 Feb 2023 at 11:38PM +02, Adrian Bunk wrote: > On Sun, Feb 26, 2023 at 09:57:34PM +0100, Diederik de Haas wrote: >> On Sunday, 26 February 2023 20:06:26 CET Adrian Bunk wrote: >>... >> > For anything in Debian, the package sources in Debian would not >> > disappear when a repository (or salsa) disappears. >> >> Question as I don't know: is that only the package change that gets uploaded >> to the Debian archive, or is there also a place where the (git) history of >> the >> changes leading up to a new upload gets stored? >> >> To use an analogy: I'd like that not only the 'destination' is preserved, but >> also the lead up to the destination. > > What goes into the Debian archive is based on tarballs and quilt patches. > Nothing is stored there except the files you upload. This is a matter of perspective. The fact that dak doesn't store git histories and send them out to mirrors is an implementation detail, to me. salsa and dgit-repos are both just as significant Debian archives, even if they're not what we refer to when we write "Debian archive". -- Sean Whitton signature.asc Description: PGP signature
Re: Reducing allowed Vcs for packaging?
Hello, On Mon 27 Feb 2023 at 12:17AM +01, Diederik de Haas wrote: > But AFAIK the Debian Xen Team does use dgit (not surprising given dgit's > maintainer (and author?)) ... and that drives me insane. > I'm very sure that is due to me not understanding the concepts/idea/etc, but I > can't wrap my head around it and it feels *to me* like it constantly rewrites > the (git) history and then does a `git push -f` ... every time. > I once referenced a patch by number (and a short description iirc) and on the > next push, that patch had a different number, thus messing up my commit msg. > > The most confusing thing for/to me is that it completely rearranges the commit > sequence, so I can't follow the changes that happened over time. > Right now in https://salsa.debian.org/xen-team/debian-xen/-/commits/master > HEAD~30 (and the 2 commits before that) are the most recent (and to me the > most relevant), but HEAD~9 was made 8 YEARS ago. > > I may learn dgit in time, but that'll probably be a (long) while. This is not dgit. This is git-debrebase, an experimental tool. Russ's comments about dgit are not at all connected with the (legitimate) issues with git-debrebase you describe. -- Sean Whitton signature.asc Description: PGP signature
Re: Reducing allowed Vcs for packaging?
Hello,
On Sun 26 Feb 2023 at 02:24PM +01, Bastian Germann wrote:
> Hi!
>
> During the last weeks I had a look at the Vcs situation in Debian. Currently,
> there are eight possible systems allowed and one might specify several of
> them for
> one package. No package makes use of several Vcs references and frankly I do
> not
> see why this was supported in the first place.
>
> For the allowed systems the situation in unstable is the following:
> arch is used by 2 packages pointing to bad URLs: #1025510, 1025511.
> bzr is used by ~50 packages, half of which point to bad URLs.
> cvs is used by 3 packages, 2 of which point to bad URLs: #1031312, #1031313.
> svn is used by ~130 packages, many of which point to bad URLs.
> darcs, mtn, and hg are not used.
>
> We can see: The Vcs wars are over; with git there is a clear winner and in my
> opinion, we should remove the possibility to use most of them for package
> maintenance. It is one additional barrier to get into package maintenance and
> we should remove the barriers that are not necessary.
>
> I would like to suggest removing the possibility to specify several systems
> and
> removing all systems except bzr, svn, and git, while deprecating bzr and
> possibly svn.
> This means solving the four listed bugs and convincing the cvsd maintainer to
> switch or drop the Vcs-Cvs reference. Then, the Debian Developer's Reference
> should specify the changes in §6.2.5 and whatever parses Vcs-* in
> debian/control
> should be adapted to do the specified thing.
>
> Finally, we can drop the orphaned packages {cvs,mercurial}-buildpackage
> (see #1026433) and add deprecation notices in brz-debian and svn-buildpackage.
Why don't we just fix all those packacges, instead of changing any
documents? Is there anyone who actually wants to introduce new packages
not using git? I'm not so sure.
--
Sean Whitton
signature.asc
Description: PGP signature
Re: SONAME bumps (transitions) always via experimental
Hello, On Thu 05 Jan 2023 at 01:13PM GMT, Simon McVittie wrote: > 3. If the ftp team prioritize NEW review of unstable packages higher than >experimental packages (do they?) then that would be >counter-productive under the proposed policy, and they'd have to >stop doing that (and perhaps prioritize binary-NEW higher than >source-NEW, instead). experimental packages appear in red on >https://ftp-master.debian.org/new.html, which makes me wonder whether >that reflects those packages being de-prioritized, but perhaps I'm >reading too much into that? The scripts prioritise binary-NEW over source-NEW by default, though I override this with a shell alias myself. We don't pay attention to unstable vs. experimental. -- Sean Whitton signature.asc Description: PGP signature
Re: Sunsetting sso.debian.org
Hello, On Sun 16 Oct 2022 at 07:22PM +02, Enrico Zini wrote: > Hello, > > I've just fixed sso.debian.org to work again after the upgrade of > diabelli to bullseye. > > I however have not used SSO certificates in years and don't intend to. > This means I'm unable to test if certificate authentication still works, > and to effectively maintain the site: I won't be able to do much more to > it than fix Django issues. > > Unless some other DD steps in to take over maintenance, I annouce my > intention to decommission sso.debian.org by the end of March 2023. > > I would welcome better single sign-on systems for Debian than Salsa, and > sso.debian.org is not it. > > I'm posting this to debian-devel as an early heads-up and a call for > other maintainers. If nobody steps in my the end of October, I'll post a > proper sunset announce to debian-devel-announce. Thank you for the notification. At the present time, I believe this will break DDs logging into tracker.debian.org. I recently had to mess around with client certificates in order to login there and subscribe to a new package. -- Sean Whitton
Re: Bug email is not getting to me
Hello, On Sun 25 Sep 2022 at 07:00PM -07, Russ Allbery wrote: > The right solution is probably for bugs.debian.org to rewrite all incoming > mail to change the From header to a debian.org address (probably the bug > address) and add a Reply-To header pointing to the original sender. This > is the fix that Mailman mostly uses, and it seems to work (I've had this > problem with multiple mailing lists I run and turning on this message > mangling has fixed it). But of course someone has to find time to > implement this. ARC is meant to be an alternative to this, eventually, right? -- Sean Whitton
Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation
Hello,
On Fri 02 Sep 2022 at 12:31PM +01, Ian Jackson wrote:
> Sean Whitton writes ("Re: Comments on proposing NEW queue improvement (Re:
> Current NEW review process saps developer motivation"):
>> On Sat 27 Aug 2022 at 04:22PM +02, Vincent Bernat wrote:
>> > It does not seem to work. Either people don't want to do that, either the
>> > FTP
>> > team is too picky on the candidates.
>>
>> Some combination of both, but I don't think I'm suffering from bias if I
>> say that it's at least 80% the former. Very few people who say they'd
>> like to be trained confirm they'd still like to once they've had a look
>> at the docs for trainees, and after that, hardly any do enough trainee
>> reviews for the other team members to feel confident they can let them
>> at it on their own.
>
> I am in this picture. Some years ago now I volunteered. I was
> introduced to the internal ftpmaster documentation and processes. At
> the time, these documents were not even published - including,
> astonishingly, some elements which read like a manifesto. (I don't
> know if these documents are published nowadays.)
They're all published, unedited
(one of the first things I worked on when I got involved).
<https://salsa.debian.org/ftp-team/manpages/-/tree/master/doc>
--
Sean Whitton
signature.asc
Description: PGP signature
Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation
Hello, On Sun 28 Aug 2022 at 07:45AM +02, Andreas Tille wrote: > > Am Sat, Aug 27, 2022 at 09:53:40AM -0400 schrieb M. Zhou: >> In my fuzzy memory, the last discussion on NEW queue improvement >> involves the disadvantages by allowing SOVERSION bump to directly >> pass the NEW queue. I'm not going to trace back, because I know >> this will not be implemented unless someone proposes a GR. > > I'm considering this once beeing back from vac. However, the problem in > such a GR is that even if there is an outcome for the voting that sais > SOVERSION bumps should pass new we need some code that implements this. > So we also need someone to volunteer for this. I think we still want the binary package namespace checking? I.e., a GR just saying "ftpteam should not do a full licensing/copyright check for packages in binNEW". Then no software changes are required. -- Sean Whitton signature.asc Description: PGP signature
Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation
Hello, On Sat 27 Aug 2022 at 04:22PM +02, Vincent Bernat wrote: > > On 2022-08-27 15:53, M. Zhou wrote: > >> That's why I still hope ftp team to recruit more people. This is >> a very direct and constructive way to speed up everything. >> More volunteers = higher bandwidth. >> Recruiting more people doesn't seem to have a serious disadvantage. > > It does not seem to work. Either people don't want to do that, either the FTP > team is too picky on the candidates. Some combination of both, but I don't think I'm suffering from bias if I say that it's at least 80% the former. Very few people who say they'd like to be trained confirm they'd still like to once they've had a look at the docs for trainees, and after that, hardly any do enough trainee reviews for the other team members to feel confident they can let them at it on their own. I am the only trainee who made it through in recent years and that's because I was highly systematic about doing lots of reviews each month. There are some technical improvements that would be possible. For example, feedback to trainees is entirely done via IRC; I would much prefer us to be doing that by e-mail. But other team members disagree with me, I think, and I do recognise I like e-mail more than most people do. There are ways the tools could be better. In general, however, existing team members, including myself, are pretty sceptical that technical improvements would be worth the time it would take to implement them effectively. dak as a whole is less well maintained than other core Debian software, but the NEW queue parts are pretty good! So, the bulk of the problem boils down to project members not being interested in doing the work. I certainly understand this. It feels just like grading student essays. Everyone finds that highly draining at first, until you develop a sort of detachment from the activity, where your mind is going through the motions of the activity sort of like how your hands can be going through the motions of something like food preparation for a familiar dish -- you have to learn that you won't make worse judgements if you become detached in this way, just like how you won't prepare a worse version of the dish if you do it in the detached way. Then I just applied what I'd learned from grading to the NEW queue, and then it's pretty fun and even relaxing when you're not in a frame of mind to do harder thinking. But like I said, most people don't want to do any of this, and of course being a trainee is *not* like that. And then recruitment is less efficient -- not enough feedback on trainee reviews -- because there aren't enough team members. The usual compounding effect. -- Sean Whitton signature.asc Description: PGP signature
Re: Current NEW review process saps developer motivation
Hello, On Fri 26 Aug 2022 at 11:58AM +01, Simon McVittie wrote: > More generally, I don't think it's always useful to talk about "the" > source or "the" preferred form for modification, as though there is only > one. I think it would be more appropriate to consider whether the form > in which some software is provided is suitable for exercising your Free > Software rights (as described in the FSF's "four essential freedoms", > for example) within the scope of whatever package we're talking about at > the time, or whether it's unsuitable for that use. If it's suitable, then > it's source, or close enough; if it's unsuitable, then that needs fixing. > > If we insist on a particularly puritanical view of what is source and > what is the preferred form for modification, then I think there is a > significant risk of producing a distribution which is unquestionably Free > Software, but either is missing useful Free software because it would be > too hard to get that software into a form that meets our self-imposed > policies, or can only contain that software as a result of individual > developers putting a heroic amount of effort into meeting those policies - > particularly if we always go back to the "true source" and generate from > there every time (which I will note that the ftp team specifically do not > insist on unless there is a technical reason to do so, they merely require > source to be *available*). Right. I think the ftpteam members agree, and hold far from the more extreme possible views about building everything all the way through. We just want to think through each case carefully enough to be satisfied that we're not failing the project in stewardship of the DFSG. Most times I send a "Comments regarding ..." mail from NEW saying "this seems a bit strange, can you explain" the result is an ACCEPT once an explanation has been provided. In the case of the Rust package that started the recent discussion, when I looked at it in NEW, I recall that I couldn't find a single non-generated file aside from metadata. That's the opposite extreme. In the discussion that followed I tried to respond to abstract cases in ways that were helpful, but with hindsight it would probably have been better just to say, "make some judgements about what's in its preferred form for modification, explain it in d/copyright, if you're doing so in the spirit of the DFSG then the ftpteam will probably agree." It's sort of like the "no detailed design work" for the TC. -- Sean Whitton signature.asc Description: PGP signature
Re: Need a buildd build after trip through NEW -- best practice?
Hello, On Wed 24 Aug 2022 at 12:09AM GMT, Holger Levsen wrote: > > On Tue, Aug 23, 2022 at 04:59:10PM -0500, Steven Robbins wrote: >> Commonly, I update a package that provides a shared library. Due to the >> package naming convention, a new SOVERSION necessitates a trip through NEW, >> which in turn means a binary upload. >> >> The binary upload cannot transition to testing -- a buildd binary build is >> required. So far as I know -- assuming [1] is still up-to-date, this means a >> nuisance upload just bumping the debian revision from -1 to -2. Is this >> still >> the recommended practice? > > yes. > > it's rather easy to do too, though maybe there should be something in > src:devscripts > implementing something along these lines: > > dch -i -m "Source only upload for testing migration." > dch -r > debuild -S > cd .. ; dput $changes_file > # git commit & git tag When the Emacs team needed to rebuild all our arch:all packages David did it with something like for foo in ...; do dgit clone foo dch "Rebuild for ..." dch -r git commit debian/changelog -m"..." dgit push-source done The advantage being that it's git workflow-agnostic, so perhaps more more useful to have that in devscripts. -- Sean Whitton signature.asc Description: PGP signature
Re: Epoch for node-markdown-it
Hello, On Sat 20 Aug 2022 at 03:53PM GMT, Holger Levsen wrote: > > On Sat, Aug 20, 2022 at 03:29:59PM +, Stefano Rivera wrote: >> > > Epochs cause problems, [...] >> > which are? (I agree they are ugly and should often be avoided, but I don't >> > see any unsolved problems with them, which is why I'm asking.) >> The standard one is that people use them to revert an upload. > > ok, I agree that's bad. (but not the case here.) > >> But, epochs aren't used in the upstream tarball filename, so you then >> easily get a conflict between the old and the new one. > > I'd replace 'easily' with 'theoretically in rare cases' but I can see how > this is a valid point, sometimes. > > Thanks for the feedback. Epochs make it easier to accidentally violate Policy 3.2.2. -- Sean Whitton signature.asc Description: PGP signature
Re: Automatic trimming of changelogs in binary packages
Hello, On Fri 19 Aug 2022 at 11:44AM GMT, Bastien Roucariès wrote: > > Le jeudi 18 août 2022, 19:18:35 UTC Gioele Barabucci a écrit : >> Hello, >> >> in 2020 there was a brief discussion on debian-devel@ about trimming >> changelogs [1,2]. >> >> Now there is a working implementation of said functionality in >> `dh_installchangelogs` [3]. > Could you stress on the mapage that some license ask to document the change > done by downstream in binary distribution and that in this case this tool > should be disable I think our separation of orig.tar and diff.gz/whatever has this covered? -- Sean Whitton signature.asc Description: PGP signature
Bug#1015729: ITP: org-make-toc -- automatic tables of contents for Org files
Package: wnpp Severity: wishlist Owner: Sean Whitton X-Debbugs-Cc: debian-devel@lists.debian.org, debian-emac...@lists.debian.org * Package name: org-make-toc Version : 0.5 Upstream Author : Adam Porter * URL : https://github.com/alphapapa/org-make-toc * License : GPL-3 Programming Lang: Emacs Lisp Description : automatic tables of contents for Org files I am packaging this as a dependency of ement-el, another ITP of mine. -- Sean Whitton
Bug#1015727: ITP: taxy-magit-section-el -- View Taxy structs in a Magit Section buffer
Package: wnpp Severity: wishlist Owner: Sean Whitton X-Debbugs-Cc: debian-devel@lists.debian.org, debian-emac...@lists.debian.org * Package name: taxy-magit-section-el Version : 0.9.1 Upstream Author : Adam Porter * URL : https://github.com/alphapapa/taxy.el branch package/taxy-magit-section * License : GPL-3+ Programming Lang: Emacs Lisp Description : View Taxy structs in a Magit Section buffer I am packaging this as a dependency of ement-el, another ITP of mine. -- Sean Whitton
Bug#1015726: ITP: emacs-svg-lib -- SVG tags, progress bars & icons for Emacs
Package: wnpp Severity: wishlist Owner: Sean Whitton X-Debbugs-Cc: debian-devel@lists.debian.org, debian-emac...@lists.debian.org * Package name: emacs-svg-lib Version : 0.2.5 Upstream Author : Nicolas P. Rougier * URL : https://github.com/rougier/svg-lib * License : GPL-3+ Programming Lang: Emacs Lisp Description : SVG tags, progress bars & icons for Emacs I am packaging this as a dependency of ement-el, another ITP of mine. -- Sean Whitton
Bug#1015725: ITP: taxy-el -- Programmable taxonomical grouping for arbitrary objects for Emacs
Package: wnpp Severity: wishlist Owner: Sean Whitton X-Debbugs-Cc: debian-devel@lists.debian.org, debian-emac...@lists.debian.org * Package name: taxy-el Version : 0.9 Upstream Author : Adam Porter * URL : https://github.com/alphapapa/taxy.el * License : GPL-3+ Programming Lang: Emacs Lisp Description : Programmable taxonomical grouping for arbitrary objects for Emacs I am packaging this as a dependency of ement-el, another ITP of mine. -- Sean Whitton
Bug#1015724: ITP: plz-el -- HTTP library for Emacs
Package: wnpp Severity: wishlist Owner: Sean Whitton X-Debbugs-Cc: debian-devel@lists.debian.org, debian-emac...@lists.debian.org * Package name: plz-el Version : 0.2 Upstream Author : Adam Porter * URL : https://github.com/alphapapa/plz.el * License : GPL-3+ Programming Lang: Emacs Lisp Description : HTTP library for Emacs I am packaging this as a dependency of ement-el, another ITP of mine. -- Sean Whitton
Bug#1015723: ITP: ement-el -- Matrix client for Emacs
Package: wnpp Severity: wishlist Owner: Sean Whitton X-Debbugs-Cc: debian-devel@lists.debian.org, debian-emac...@lists.debian.org * Package name: ement-el Version : 0~git... Upstream Author : Adam Porter * URL : https://github.com/alphapapa/ement.el * License : GPL-3+ Programming Lang: Emacs Lisp Description : Matrix client for Emacs I'll upload this to experimental for now, until upstream makes a stable release. But we can help them do some testing. -- Sean Whitton
Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name
Hello, On Thu 14 Jul 2022 at 01:52PM +01, Steve McIntyre wrote: > IMHO there are 2 points to an ITP: > > * to save effort in case two people might be working on the same >package > * to invite discussion on debian-devel / elsewhere > > If people post an ITP and upload iummediately, then I don't think that > helps on either count. Regarding the first point, in previous discussions others have said that they don't look at NEW but do look at ITPs, so they still want it posted for that reason. > If the only reason for the ITP is to make lintian quiet then I think > that's a total waste of time - it's following a guideline blindly > without understanding the reason for it. Definitely. -- Sean Whitton
Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name
Hello, On Thu 14 Jul 2022 at 02:23PM +02, Johannes Schauer Marin Rodrigues wrote: > Quoting Steve McIntyre (2022-07-14 13:54:52) >> And I see you uploaded ~immediately - why even bother with an ITP? > > I did that quite a few times in the past as well. Is there a rule of how long > I > have to wait with my upload to NEW after filing the ITP? No, in fact they're not even required. The Haskell team doesn't post them, for example. -- Sean Whitton
Re: feedback for NEW packages: switch to using the BTS?
Hello, On Sun 01 May 2022 at 07:52am +08, Paul Wise wrote: > On Sat, 2022-04-30 at 14:20 -0700, Sean Whitton wrote: > >> This would really slow things down; >> I don't think we could work that way. > > Using separate bug reports or not would of course be up to the person > filing them, but I expect the process could be automated well enough > that it wouldn't be much different to the current process (which I am > not familiar with). An automated multi-bug process might be something > like this; press the button for filing a bug, get a template with the > right version etc, type out the problem details, press send, repeat the > process. Is the current process any different other than the repeating? It's quicker to to edit a single text file, review the whole thing and then send it. -- Sean Whitton
Re: feedback for NEW packages: switch to using the BTS?
Hello, On Sat 30 Apr 2022 at 07:44AM +08, Paul Wise wrote: > It also means the ftpmasters can file separate bugs for each problem, > rather than combining them all into one mail. This would really slow things down; I don't think we could work that way. -- Sean Whitton signature.asc Description: PGP signature
Re: secnet_0.6.2_multi.changes REJECTED
Hello,
On Mon 11 Apr 2022 at 05:51PM +01, Ian Jackson wrote:
>> They also pointed out that there is some code from StackOverflow,
>> which is not GPL-3+.
>
> I think this is not right? I think you are referring to
> `argparseactionnoyes.py`. As I documented in the file header, it is
> part of StackOverflow's TOS that contributors grant a CC-BY-SA 4.0
> licence for the snippets they upload, which would make the
> contributions GPL3+-compatible. My file comment gives the relevant
> references. [1]
>
> It seems to me that StackOverflow have chosen this approach (making
> the upload licence part of the TOS) precisely to enable people to copy
> code fragments out of StackOverflow into their own projects. ISTM
> that in (unless it appears that the posting StackOverflow user did not
> write the code in question), we should be able to rely on that.
>
> Can you please confirm whether the opinion of the ftpmaster team, that
> is not sufficient? If it is not sufficent, I guess I will find
> someone to write a clean room implementation of this 22-line class.
In this case, I believe I was just passing on the other team member's
comment. What you say seems fine, though it should be documented in
d/copyright -- the code does not become GPL-3+ by being GPL-3-compatible.
>> I noticed that b91dec.{php,awk} have no license information at all.
>
> As you observe, these files as provided by upstream do not themselves
> contain licence information. But the file base91-c/README (which is
> provided by upstream) says, amongst other things:
>
> All source code in this package is released under the terms of the BSD
> license.
> See the file LICENSE for copying permission.
>
> And these files were (according to their copyright notice) written by
> the same author and clearly part of the base91-c project. I think
> this licence therefore applies also to the files b91dec.{php,awk}.
Sounds like I was just being confused by directory structure, then.
>> Shouldn't subdirmk be a separate package?
>
> Well. It is designed to be "git-subtree"'d into one's package. That
> is the way the upstream package uses it.
>
> It would be possible to make it a separate package and build-depend on
> it, at the cost of some additional work. The upside would be a very
> small amount of disk space saving, and largely theoretical saving of
> work in case of a need to do a security update for subdirmk (which
> seems unlikely to be critical since it's build system software which
> is designed to execute its input) - and that all only in the case
> where a second package in Debian uses subdirmk.
>
> It seemed me best to me to defer this work until subdirmk becomes more
> widely used.
Cool. Just wanted to raise the question.
--
Sean Whitton
signature.asc
Description: PGP signature
Epoch for cl-anaphora
Hello, I took over upstream maintenance of this package recently and started tagging releases again. The most recent release is 0.9.8. But the Debian package version is 20210111.gitab5f07e-1. So I would like to bump the epoch to go back to using upstream versions. Thanks! -- Sean Whitton signature.asc Description: PGP signature
Re: proposed MBF: packages still using source format 1.0
Hello, On Tue 29 Mar 2022 at 08:50AM +02, Lucas Nussbaum wrote: > On 28/03/22 at 16:03 -0700, Sean Whitton wrote: >> Hello, >> >> On Tue 15 Mar 2022 at 06:26PM +01, Lucas Nussbaum wrote: >> >> > On 15/03/22 at 15:36 +, Ian Jackson wrote: >> >> At least the following packages of which I am the maintainer or >> >> sponsor were includined in the MBF, despite the fact that they are 1.0 >> >> native packages with Debian revision: >> >> >> >>its-playback-time >> >>spigot >> >>vm >> >>vtwm >> >>chroma >> >> >> >> Clearly the it makes no sense to have filed bugs saying "please switch >> >> to this other source format" when the other source format cannot >> >> represent the package. >> > >> > Those five packages: >> > - are indeed native packages with Debian revisions >> > - are not maintained in a VCS (or the VCS is not advertized using >> > Vcs-*). >> > >> > So there's no easy way to understand how the package differs from >> > upstream (no patch serie, no VCS history). I don't think that it's >> > something desirable. >> > (if the packages had declared a VCS, they would have joined cachefilesd, >> > userv-utils, and vde2 in the "native package with a Debian revision >> > maintained in a VCS" category.) >> >> They have detailed history on dgit-repos. >> E.g. <https://browse.dgit.debian.org/its-playback-time.git/>. > > Yes, my point is that those packages don't have Vcs-* headers, so it's > impossible to discover the above URL. Right, sorry. They should have such Vcs-* headers added. -- Sean Whitton signature.asc Description: PGP signature
Re: proposed MBF: packages still using source format 1.0
Hello, On Tue 15 Mar 2022 at 06:26PM +01, Lucas Nussbaum wrote: > On 15/03/22 at 15:36 +, Ian Jackson wrote: >> At least the following packages of which I am the maintainer or >> sponsor were includined in the MBF, despite the fact that they are 1.0 >> native packages with Debian revision: >> >>its-playback-time >>spigot >>vm >>vtwm >>chroma >> >> Clearly the it makes no sense to have filed bugs saying "please switch >> to this other source format" when the other source format cannot >> represent the package. > > Those five packages: > - are indeed native packages with Debian revisions > - are not maintained in a VCS (or the VCS is not advertized using > Vcs-*). > > So there's no easy way to understand how the package differs from > upstream (no patch serie, no VCS history). I don't think that it's > something desirable. > (if the packages had declared a VCS, they would have joined cachefilesd, > userv-utils, and vde2 in the "native package with a Debian revision > maintained in a VCS" category.) They have detailed history on dgit-repos. E.g. <https://browse.dgit.debian.org/its-playback-time.git/>. -- Sean Whitton signature.asc Description: PGP signature
Re: proposed MBF: packages still using source format 1.0
Hello, On Tue 15 Mar 2022 at 11:46AM +01, Julien Cristau wrote: > 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.) Thanks. Is the rationale for this written down anywhere, may I ask? I'd like to read about the workflow. -- Sean Whitton signature.asc Description: PGP signature
Re: proposed MBF: packages still using source format 1.0
Hello, On Tue 15 Mar 2022 at 04:16pm +01, Lucas Nussbaum wrote: > On 15/03/22 at 10:36 +, Ian Jackson wrote: >> Answers were given, including by a former DPL (whom you may observe >> is not someone I am on speaking terms with). >> >> But I see now that the MBF has gone ahead anyway. >> >> I spent some time trying to help by setting out the factual >> background, but it seems that Debian is not interested in facts. I >> don't know why I bother. > > Hi Ian, > > As explained in https://lists.debian.org/debian-devel/2022/03/msg00165.html > I proceeded with the MBF for packages that match > not (debian_x or (vcs and vcs_status != 'ERROR' and direct_changes)) > or, maybe easier to read: > (not debian_x) and ((not vcs) or vcs_status == 'ERROR' or (not > direct_changes)) > > I did not file bugs for packages that are likely to use a VCS-based > workflow (category (2) in the mail pointed above, or in > https://udd.debian.org/cgi-bin/format10.cgi) > > What the are the packages for which you are surprised that bugs were > filed? I wonder which part of the criteria was too loose. It looks like the query didn't do quite what was intended, indeed: src:userv-utils is maintained in git but a bug was filed. Before I go ahead and close the bug, would you mind confirming this was an error rather than a disagreement about what counts as VCS-maintained? Thanks. -- Sean Whitton
Re: proposed MBF: packages still using source format 1.0
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? -- Sean Whitton signature.asc Description: PGP signature
Re: proposed MBF: packages still using source format 1.0
Hello Ian, Thank you for the summary, which helped refresh my memory. On Wed 09 Mar 2022 at 04:38PM GMT, Ian Jackson wrote: > 1. Why is 1.0-without-diff not always worse than 3.0 (native) ? > > 1.0 native is sometimes better than 3.0 (native) because dpkg-source > refuses to build a 3.0 native package with a Debian revision in its > version number. > > This prohibition exists solely because of a doctrinal objection to > native-format packages with Debian revisions. There is no technical > reason why this restriction could not be lifted. I sometimes upload > this way and I have never had anyone report problems[1] with it. > > IMO there is nothing wrong with native format packages with Debian > revisions. They work just fine. For a small paockage, this is often > a good choice, because it avoids dealing with patches at all. > > For anything but a small package, use of diffs is needed as a storage > and distribution optimisation. It it perhaps worth noting that this idea that native source package formats cannot have Debian revisions is an idea found in dpkg, not in Policy, which latter otherwise has quite a bit to say about native vs. non-native. > Changes not representable by diff is what Sean is talking about here: > >> Ian has some cases where something that is representable in git is not >> representable using 3.0 (quilt) but is representable using 1.0. I don't >> have those cases to hand; Ian, could you summarise, please? > > Currently, I think diff cannot represent changes to symlinks. > git can store symlinks and represent their targets, and changes to > their targets. So in this case 1.0-native is the only option. And it would be a downgrade to mess around with what git represents perfectly well just for the sake of an output format. -- Sean Whitton signature.asc Description: PGP signature
Re: proposed MBF: packages still using source format 1.0
Hello, On Wed 09 Mar 2022 at 01:08pm +01, Lucas Nussbaum wrote: > On 08/03/22 at 17:33 -0700, Sean Whitton wrote: >> Lucas, as I've had a lot to do with these git workflows and have >> probably done the most work documenting them, I can help with any >> specific follow-up questions you might have. > > Thanks! > > So the main question I think I have is: > > can we find a middleground where the git workflows don't require staying > with 1.0? Even if that means switching to 3.0 (quilt) using the > single-debian-patch approach? dgit-maint-merge(7) works with single-debian-patch and that's what I use. But it is not clear to me that there are any advantages at all to that over 3.0 (quilt) with single-debian-patch? Anyway, the main case where I myself use 1.0 is the following shell alias: alias ...="sbuild --dpkg-source-opts='-Zgzip -z1 --format=1.0 -sn'" This is from dgit-user(7). It's the only reasonable way to say "just sbuild HEAD, please". One reason to continue to use 1.0 in the archive is to ensure that a way to say "just sbuild HEAD, please" continues to be supported, as it's very important to have. Ian has some cases where something that is representable in git is not representable using 3.0 (quilt) but is representable using 1.0. I don't have those cases to hand; Ian, could you summarise, please? > 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. -- Sean Whitton
Re: proposed MBF: packages still using source format 1.0
Hello, On Tue 08 Mar 2022 at 04:45pm +01, Lucas Nussbaum wrote: > 1/ the arguments about using patches to track changes to upstream code. > Among the ~600 packages in that potential MBF, there are still many that > make changes to upstream code, which are not properly documented. I > believe that it is widely accepted that seperate patches in > debian/patches/ are the recommended way to manage changes to upstream code > (good way to help with those changes getting reviewed, getting merged > upstream, etc.) ... or a git workflow which has the changes represented as git commits, rather than files under d/patches. -- Sean Whitton
Re: proposed MBF: packages still using source format 1.0
Hello, On Sun 06 Mar 2022 at 01:28pm -08, Russ Allbery wrote: > If you're going to omit the ones in the last category, I think you should > also omit the ones in the none/no/yes category, since they may be packages > that intermittantly have changes and are similarly using a VCS-based > workflow that doesn't want to use the 3.0 format. Yes, indeed. Lucas, as I've had a lot to do with these git workflows and have probably done the most work documenting them, I can help with any specific follow-up questions you might have. > A mass bug filing for the first three categories seems like the change > with the biggest potential to benefit Debian, since it's a direct > simplification of the number of ways packages are maintained in the > archive. The packages without any patch system feel a bit less > interesting. Very much agreed. -- Sean Whitton
Re: NEW processing friction
Hello, On Thu 03 Mar 2022 at 08:44PM +01, Andreas Tille wrote: > Am Thu, Mar 03, 2022 at 09:57:26AM -0700 schrieb Sean Whitton: >> > PS: I'm currently considering writing up some summary of the bunch >> > of threads that was born out of my initial mail. >> > >> > [1] https://lists.debian.org/debian-devel/2022/01/msg00226.html >> >> Assuming I'm not misreading, the ftpteam currently thinks (B). > > What do you mean be "misreading"? My mail I linked above or some > ftpmaster statements I'm not aware about (or which I was misreading)? Your mail -- assuming I'm not misinterpreting anything about (B) in a way that means I misstate the team's view. -- Sean Whitton signature.asc Description: PGP signature
Re: NEW processing friction
Hello, On Thu 03 Mar 2022 at 07:36am +01, Andreas Tille wrote: > Hi Sean, > > Am Wed, Mar 02, 2022 at 08:33:35AM -0700 schrieb Sean Whitton: >> >> I'm sorry to be responding only a month later, but I think there are >> some reasons why binNEW is not the worst place to be doing these extra >> checks: packages with SONAME bumps are typically C or C++ projects and >> these are (i) large, such that d/copyright is more likely to drift >> simply because of the volume of files; and (ii) often contain embedded >> code copies with different copyright and licensing. My own NEW >> experience is that I've consistently found more problems in binNEW >> packages than anywhere else. > > Thanks a lot for your insight into this topic. I'd like to stress my > point (again) that besides I was naively thinking that the checks done > on packages that are passing new due to binary package changes (which > are not only due to changed SONAME) my main point is that I've found > a discrepancy in statements of ftpmaster teams. My question whether > we agree to status A or B[1] was not yet answered (or I missed some > explicit answer). > > Kind regards > > Andreas. > > PS: I'm currently considering writing up some summary of the bunch > of threads that was born out of my initial mail. > > [1] https://lists.debian.org/debian-devel/2022/01/msg00226.html Assuming I'm not misreading, the ftpteam currently thinks (B). -- Sean Whitton
Re: NEW processing friction
Hello Steve, On Wed 09 Feb 2022 at 01:26pm -08, Steve Langasek wrote: > The fact that the FTP team applies license/copyright review as part of their > review of source packages has grounding in a number of goals of Debian as a > project. The existence of a binary NEW queue is also sensible, as the FTP > team have to manage the namespace of the packages in the archive. But the > application of license/copyright review by the FTP team for existing > source packages as part of binary NEW processing /and at no other time/ is > arbitrary. It is, at best, a historical accident that has taken on the > authority of precedent. > > Guarding against debian/copyright drift is a useful goal. But it is harmful > to the velocity of the project to either block or reject new binary packages > in the archive because of this linkage to license review. > Actively-developed library packages with ABI changes are not fundamentally > more likely to have license drift than any other package in the archive, so > focusing FTP team time on reviewing the licenses of these packages in > particular is a misapplication of resources. > > The responses I've seen from the FTP team to this can, I believe, be roughly > paraphrased as "we would like all debian/copyright in the archive to be > clean, but we don't have capacity to do that, so we're doing this instead". > I assert that it is much, much worse to continue doing this than to do *no* > license/copyright review as part of binary NEW. It does not achieve the > goal of having clean debian/copyright across the archive; it slows down the > binary NEW queue due to (self-imposed) workload of the FTP team; and it > deters developers interested in this problem space from innovating better > (and more systematic) solutions outside the small FTP team. I'm sorry to be responding only a month later, but I think there are some reasons why binNEW is not the worst place to be doing these extra checks: packages with SONAME bumps are typically C or C++ projects and these are (i) large, such that d/copyright is more likely to drift simply because of the volume of files; and (ii) often contain embedded code copies with different copyright and licensing. My own NEW experience is that I've consistently found more problems in binNEW packages than anywhere else. -- Sean Whitton
Re: NEW processing friction
Hello, On Mon 07 Feb 2022 at 12:00PM -05, Theodore Ts'o wrote: > On Mon, Feb 07, 2022 at 12:06:24AM -0700, Sean Whitton wrote: >> >> When we treat any of the above just like other RC bugs, we are accepting >> a lower likelihood that the bugs will be found, and also that they will >> be fixed > > Another part of this discussion which shouldn't be lost is the > probabiltiy that these bugs will even *exist* (since if they don't > exist, they can't be found :-P) in the case where there is a NEW > binary package caused by a shared library version bump (and so we have > libflakey12 added and libflakey11 dropped as binary packages) and a > NEW source package. Which category of bugs do you mean? I distinguished three. -- Sean Whitton signature.asc Description: PGP signature
Re: NEW processing friction
Hello Russ, On Tue 25 Jan 2022 at 01:45pm -08, Russ Allbery wrote: > Jonas Smedegaard writes: > >> I just don't think the solution is to ignore copyright or licensing >> statements. > > That's not the goal. The question, which keeps being raised in part > because I don't think it's gotten a good answer, is what the basis is for > treating copyright and licensing bugs differently than any other bug in > Debian? > > The need for pre-screening was obvious when we had export control issues, > but my understanding is that those have gone away. Are we working from > legal advice telling us that this pre-screening is required for some legal > purpose? If so, is it effective for the legal purpose at which it is > aimed? Is this system left over from old advice? Have we checked our > assumptions recently? > > NEW processing is a lot of friction for the project as a whole and a lot > of work for the ftp team. If we were able to do less work at the cost of > a minimal increase in bugs, or at the cost of handling bugs a bit > differently, maybe that would be a good thing? > > In other words, it's unclear what requirements we're attempting to meet > and what the basis of those requirements is, which makes it hard to have a > conversation about whether the current design is the best design for the > problem we're trying to solve. I agree with you that we should consider treating license and copyright bugs just like other RC bugs, assuming a lawyer agrees. I think, though, that we should be more specific about what we want to treat differently. As an ftptrainee one learns various subtleties about licensing, copyright, the DFSG and the main/contrib/non-free distinction which most DDs would not disagree with, but of which they aren't explicitly aware, and don't incorporate into their packaging. Firstly, we can distinguish between copyright and licensing. The reason that ftpteam member ask for more copyright notices in d/copyright is because most licenses requires the preservation of all copyright notices in the binary distribution. When it comes to licensing, there are license compatibility issues, and the issue of d/copyright falsely claiming files are under one license when they're under another. I would guess that if the project wants to worry less about the former, we would also like to worry less about the latter, but the issues are distinct. Hardly anyone else in free software cares much about the copyright notices copying, but there is probably at least somewhat broader interest in being careful about license compatibility, for example. Secondly, there are the things which are self-imposed: the finer points of the DFSG, and the main/contrib/non-free distinction. Two issues which come up often are how we require that the preferred form for modification is included in main for every file in main, and the idea that main is self-contained. It is quite easy to violate these requirements, and it does seem to require training/practice to spot the issues. Typically new ftptrainees don't include them in their reviews. When we treat any of the above just like other RC bugs, we are accepting a lower likelihood that the bugs will be found, and also that they will be fixed. Severities can be changed and bugs can be ignored for purposes of testing migration. It would mean very different things for the identity of our project to accept a higher likelihood of strictly copyright/licensing bugs never being found or fixed, than it would to accept a higher likelihood of subtle DFSG bugs going unfound or unfixed. There are particular difficulties with trying to handle pure DFSG issues via the BTS rather than the simple accept/reject semantics of NEW. It is easy to disagree in particular cases, and sometimes judgement calls are required. The only people empowered to make those judgements calls are the ftpteam, and we can't be engaged with every bug in the BTS about DFSG issues, so it would seem particularly easy for bugs to languish. It means something, at present, that we treat these DFSG issues differently -- it's because we really care about shipping preferred forms for modification, and about how main is self-contained. It's not that we care about it /more/ than fixing programming bugs or whatever, but we care about it /differently/, because it's one of our founding ideas. We don't want to let that stuff in. We don't want to let technical bugs in either, but, well. I would like NEW to change so it can be faster, because I agree with you that the current focus on copyright and licensing does not line up with what we as a project really care about. I am not so sure that the character of the archive wouldn't change for the worse if we treated DFSG issues differently, however. -- Sean Whitton
Re: Legal advice regarding the NEW queue
Hello, On Fri 04 Feb 2022 at 11:50PM +01, Christian Kastner wrote: > On 2022-02-04 18:39, Russ Allbery wrote: >> In other words, this thread is once again drifting into a discussion of >> how to do copyright review *better*, when my original point is that we >> should seriously consider not doing the current type of incredibly tedious >> and nit-picky copyright review *at all*, and instead rely more on >> upstream's assertions, automated tools, and being reactive in solving the >> bugs that people actually care about (i.e., notice). > > If we're honest, that's basically how the rest of the open source world > already operates in general. Our level of scrutiny is a burden that I > don't see many others sharing. > > Of course "everybody's doing it" doesn't make something right. However, > when things go wrong, they don't seem to go wrong in the dramatic ways > we might anticipate them to. > > If GitHub (a Microsoft-owned entity and thus an attractive target for a > lawsuit) is OK with distributing files uploaded by third parties without > subjecting them to a manual review process, perhaps we have been > overthinking the risks here. Just to note that GitHub let *others* upload things without reviewing, such that they're a communications platform (or whatever the legal term is) not a publisher, but we're a publisher. -- Sean Whitton signature.asc Description: PGP signature
Bug#1002700: ITP: org-contrib -- additional Emacs Lisp libraries for Org-mode
Package: wnpp Severity: wishlist Owner: Sean Whitton X-Debbugs-Cc: debian-devel@lists.debian.org, debian-emac...@lists.debian.org, s...@debian.org * Package name: org-contrib Version : 0.3 Upstream Author : Bastien Guerry * URL : https://git.sr.ht/~bzg/org-contrib * License : GPL-3+ Programming Lang: Emacs Lisp Description : additional Emacs Lisp libraries for Org-mode These files used to be included in src:org-mode releases, but upstream has now made them a separate package. -- Sean Whitton signature.asc Description: PGP signature
New semi-formal ctte role: TC facilitators
Dear all, I would like to draw your attention to the following text which we recently committed to tech-ctte.git, in the context of our efforts to get the TC involved earlier, when disputes are cooler. [...] Facilitators Any developer or group of developers can request that the TC assign a *facilitator* to work with them in the early stages of a technical disagreement. Facilitators are regular members of the TC that can provide advice. Although this advice is not formally a statement of the TC, we can expect the TC to defer to some degree to the views of one of their members that has been deeply involved with the issue. Facilitators are also DDs, so can carry out all of the normal activities of a DD, including things like detailed design that are not possible for the TC. Obviously the facilitator must be clear about when they are acting as TC facilitator, and when they are acting as regular DDs. Some facilitators may prefer to avoid any activities that would not be permissible for the TC as a body. As with any TC related activity, assigned facilitators may find themselves in conflict of interest in a given disagreement. We trust members of the TC to recognize such problems and, if it becomes necessary, recuse themselves from their role as a facilitator, or even recuse themselves from a later TC vote on the disagreement. [...] Contacting us - - Formally, "requesting action from the TC" means "using reportbug to contact us" - We want to streamline the process and hopefully avoid things becoming TC bugs at all sometimes - Developers are welcome to contact the committee informally for feedback, or to ask for a facilitator. - We can talk about your issue, even informally, via IRC `#debian-ctte` in OFTC - If you prefer, mail a brief summary - To our mailing list (public, archived: `debian-c...@lists.debian.org`) - To our private alias (`debian-ctte-priv...@debian.org`) -- Sean Whitton signature.asc Description: PGP signature
Re: thank *you*, team@security.d.o! (was Re: [SECURITY] [DSA 5000-1] openjdk-11 security update)
Hello, On Tue 02 Nov 2021 at 12:07AM GMT, Holger Levsen wrote: > hey hey, hear hear! > > On Mon, Nov 01, 2021 at 07:44:34PM +, Moritz Muehlenhoff wrote: >> - >> Debian Security Advisory DSA-5000-1 secur...@debian.org > > WHHO! > > that's *something* to *celebrate*!!1 Very many thanks to the whole Debian > security team, past and present, and to everyone contributing! You rock! > A lot! 5 whooping thousand (counted) times so far! > > Thank you very much once more, and not enough, not even close. Oh, well noticed, and indeed -- thank you so much, security team, you are a huge part of making our distribution what it is. -- Sean Whitton signature.asc Description: PGP signature
tech-ctte: More specific advice regarding merged-/usr and implications of #978636
uently reverted in 13.5.2. We consider the revert that was done in 13.5.2 to have been an appropriate course of action. We issue this recommendation for several reasons: - The transition to merged-/usr will make the logical locations of these files irrelevant to their physical locations. - The transitional mechanisms necessary to prevent such moves from breaking other packages that hard-code specific paths are error-prone, and can themselves interfere with the transition to merged-/usr. - After the transition to merged-/usr has completed, during the Debian 13 development cycle, we expect that maintainers will be able to move these files without needing transitional mechanisms. - On merged-/usr systems, there is a possible failure mode involving files being moved between packages (with Replaces) during the same release cycle that their logical location is changed from the root filesystem to the corresponding aliased directory in /usr, which can result in the affected file disappearing. This can be avoided by not changing the file's logical location until the beginning of the Debian 13 development cycle, after the transition to merged-/usr is complete. - On non-merged-/usr systems, a failure mode has been observed in which older shared libraries in /lib/MULTIARCH are not always deleted as intended, and interfere with correct loading of the newer shared library in /usr/lib/MULTIARCH. This can be avoided by not changing the file's logical location until the beginning of the Debian 13 development cycle, after the transition to merged-/usr is complete, at which point ldconfig(8) will choose the newer library even if this occurs. This recommendation applies until Debian 12 is released, or until a subsequent Technical Committee resolution rescinds it, whichever is sooner. We intend to rescind this recommendation if mechanisms are developed to avoid the undesired side-effects of moving files from the root filesystem into /usr. For the Technical Committee: -- Sean Whitton signature.asc Description: PGP signature
Re: Q. What is the best practice about +dfsg and +ds extension?
Hello, On Sat 02 Oct 2021 at 03:03PM +02, Jonas Smedegaard wrote: > Quoting Kentaro Hayashi (2021-10-02 14:19:17) >> I want to know about the best practice of +dfsg and +ds extension. >> As far as I know, it is not well documented as a policy or devref. > > When upstream codebase in its pristine form would violate the Debian > Free Software Guidelines (DFSG), I would use the hint "dfsg"- > > When upstream codebase require repackaging for (only) other reasons than > DFSG compliance I instead use the hint "ds" (as in "derived source"). Or "Debian source" :) -- Sean Whitton signature.asc Description: PGP signature
Re: Debian choice of upstream tarballs for packaging
Hello, On Wed 25 Aug 2021 at 07:01PM +02, Thomas Goirand wrote: > If pushing the upstream git tags to Salsa, you're safe, and the way we > do in the OpenStack team, we still generate and upload tarballs to the > Debian archive matching each tags. Branches on salsa can be force-pushed, so it's not completely safe. When you 'dgit push-source' or 'dgit push', that history is immutable in that only the service admins can rewrite it. -- Sean Whitton signature.asc Description: PGP signature
Re: Debian choice of upstream tarballs for packaging
Hello, On Wed 25 Aug 2021 at 12:00PM +02, Simon Richter wrote: > Hi, > > On 8/25/21 1:21 AM, Sean Whitton wrote: > >> From my point of view, signing git tags is no less well established a >> best practice than signing tarballs -- in fact, to me, it seems *more* >> well established. > > That is ecosystem dependent. Yes, that was my point. We're going to have upstreams who release tarballs and upstreams who release tags for some time. -- Sean Whitton signature.asc Description: PGP signature
Re: Future of /usr/bin/which in Debian?
Hello Boyuan, On Fri 27 Aug 2021 at 04:48PM -04, Boyuan Yang wrote: > Hi, > > 在 2021-08-22星期日的 17:36 +0200，Andrej Shadura写道： >> Hi, >> >> On Thu, 19 Aug 2021, at 23:17, Boyuan Yang wrote: >> > 在 2021-08-18星期三的 22:59 +0200，Geert Stappers写道: >> > > > /usr/bin/which.debianutils 0 >> > > > >> > > > in postinst and so on so that FreeBSD which and GNU which and friends >> > > > could >> > > > take over. >> > > >> > > Please do. Make such take over possible. >> > > It is what >> > > https://salsa.debian.org/debian/debianutils/-/merge_requests/6#note_242172 >> > > is asking for. >> > >> > So we will have https://salsa.debian.org/debian/which-gnu providing a >> > binary >> > package with name "which". I will upload it to the NEW queue soon. >> >> I'd rather suggest the FreeBSD which, which I'm mirroring here: >> https://salsa.debian.org/andrewsh/freebsd-which/ >> >> I think it's much simpler than the GNU one. > > The GNU which package is now in NEW queue: > https://ftp-master.debian.org/new/gnu-which_2.21-1.html > > Having both freebsd which and gnu which in Debian archive is definitely ok. If > you would like, please also upload freebsd-which onto unstable. It's okay, indeed, but please do consider NEW queue workload with things like this -- upload it if you're sure it's going to get used, not just for completeness. -- Sean Whitton signature.asc Description: PGP signature
Re: Debian choice of upstream tarballs for packaging
Hello zigo, On Wed 25 Aug 2021 at 04:11PM +02, Thomas Goirand wrote: > I wrote this many times, but I don't see why we should use any "upstream > tarball" when the Git repository itself contains the tarball with: > > git archive --prefix=$(DEBPKGNAME)-$(VERSION)/ $(GIT_TAG) \ > | xz >../$(DEBPKGNAME)_$(VERSION).orig.tar.xz > > (which leads to a .xz, which is nicer) > > Not only then, only only has to merge the upstream tag in the Debian > branch to get the new release, but on top, no need to "gbp import" or > "pristine-tar commit", and a single packaging branch becomes enough. > > I very much wish this packaging workflow gained more traction, and the > pristine-tar abomination dies... I agree. I'd like to suggest using 'git deborig' which is much shorter to type :) -- Sean Whitton signature.asc Description: PGP signature
Re: Debian choice of upstream tarballs for packaging
Hello, On Fri 27 Aug 2021 at 07:58AM GMT, Paul Wise wrote: > On Wed, Aug 25, 2021 at 2:36 PM Simon Richter wrote: > >> "git archive" is reproducible > > I'm told by the Bootstrappable Builds folks that `git archive` isn't > deterministic in some cases to do with filtering, I lost the details > though. git-deborig in devscripts has code to handle the filtering problem, I believe. -- Sean Whitton signature.asc Description: PGP signature
Re: src:developers-reference - pt_BR translation initiative
Hello, On Wed 18 Aug 2021 at 05:52PM GMT, Thiago Pezzo (tico) wrote: > Hi, there, > > I have been thinking about opening a new translation front to our team, when > I saw Holger’s talk about the developer's reference handbook [1]. It would be > another great opportunity to our (small) team to contribute to the Debian > community. Please consider Debian Policy too! We've got po4a infra set up. -- Sean Whitton signature.asc Description: PGP signature
Re: Debian choice of upstream tarballs for packaging
Hello Simon, On Wed 18 Aug 2021 at 10:10AM +02, Simon Josefsson wrote: > 1) Trust paths. Some upstreams sign release tarballs with an OpenPGP > release key that Debian trust for making releases. Not all upstream > uses the same key to sign VCS tags/commits, and not all upstreams sign > VCS tags/commits at all. While Debian can encourage and promote new > policies for upstream here, I don't think we are in a position to > require any uniform set of rules. Signing tarballs is the current > established best practice -- moving to VCS builds needs a set of new > schemes to be established and deployed, and I don't see any single > universal solution today. From my point of view, signing git tags is no less well established a best practice than signing tarballs -- in fact, to me, it seems *more* well established. Of course, that's based on the kinds of upstreams I find myself interacting with, based on the package maintainance work I tend to be involved in. I don't mean to deny that it looks the other way around from other points of view. But I think either of us would be mistaken to take one of them to be more standard, at this point. -- Sean Whitton signature.asc Description: PGP signature
Bug#992601: Allow non-64-bit packages to install to /usr/lib64/ again
Package: debian-policy Version: 4.6.0.0 Tags: patch X-debbugs-cc: Aurelien Jarno , debian-devel@lists.debian.org On Wed 18 Aug 2021 at 02:10PM -07, Russ Allbery wrote: > Sean Whitton writes: >> On Wed 18 Aug 2021 at 11:10AM +02, Aurelien Jarno wrote: > >>> This path is used by the multilib 64-bit toolchain on 32-bit >>> architectures, for instance libc6-amd64:i386, or a few essential >>> libraries like ncurses. >>> >>> What kind of fix do you expect on the packages? Is it finally the time >>> to get rid of multilib and use pure multiarch instead? > >> We did not intend to make any packages buggy with this change. It was >> thought to be just a clarification. > >> Russ, perhaps we should revert this? > > Yes, that was a subtlety that I had completely failed to grasp and didn't > realize this was way the rule was worded the way it was. Sorry for that > mistake; we should revert it. Seeking seconds: diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst index 83b71b1..131b450 100644 --- a/policy/ch-opersys.rst +++ b/policy/ch-opersys.rst @@ -48,8 +48,8 @@ Debian Policy. The following exceptions to the FHS apply: libraries must not install these libraries to ``/usr/lib/i386-linux-gnu``. [#]_ -Packages must not install files in ``/usr/lib64`` or in a subdirectory -of it. +Packages for 64-bit architectures must not install files in ``/usr/lib64`` +or in a subdirectory of it. The requirement for C and C++ headers files to be accessible through the search path ``/usr/include/`` is amended, permitting files to be -- Sean Whitton signature.asc Description: PGP signature
Re: Debian Policy 4.6.0.0 released
Hello, On Wed 18 Aug 2021 at 11:10AM +02, Aurelien Jarno wrote: >> 9.1.1 >> No package is allowed to install files in ``/usr/lib64/``. Previously, >> this prohibition only applied to packages for 64-bit architectures. > > This path is used by the multilib 64-bit toolchain on 32-bit > architectures, for instance libc6-amd64:i386, or a few essential > libraries like ncurses. > > What kind of fix do you expect on the packages? Is it finally the time > to get rid of multilib and use pure multiarch instead? We did not intend to make any packages buggy with this change. It was thought to be just a clarification. Russ, perhaps we should revert this? -- Sean Whitton signature.asc Description: PGP signature
Re: Debian Policy 4.6.0.0 released
Hello, On Wed 18 Aug 2021 at 10:57AM -04, Scott Talbert wrote: > The upgrading checklist on [1] is for version 4.5.2. I could be wrong, > but doesn't this usually match first parts of the policy version > (4.6.0.0)? > > [1] > https://www.debian.org/doc/debian-policy/upgrading-checklist.html#version-4-5-2 Fixed, thanks. Will reach web mirrors later today. -- Sean Whitton signature.asc Description: PGP signature
Re: Debian choice of upstream tarballs for packaging
Hello, On Mon 16 Aug 2021 at 09:18AM +08, Paul Wise wrote: > I noticed that sometimes Debian's choice of upstream source for > packaging can be suboptimal. This is especially apparent for the > different per-language upstream packaging ecosystems[1], where the > upstream packaging differs from the upstream VCS in some significant > ways, including missing files, prebuilt files, embedded copies etc. > > While the upstream VCS also sometimes has these issues, it is often > much less problematic than the upstream packaging ecosystems. > > I'd like to suggest that we standardise on the upstream VCS for our > orig.tar.gz files and phase out use of upstream packaging ecosystems. I agree with this, and already do it for all or almost all of the packages I maintain. There will probably need to be lots of exceptions, however. Perhaps "recommended" in Policy? I wrote the git-deborig tool in devscripts to make it easy to generate the orig.tar files. For almost every upload I just type either 'git deborig', or for -2, 'origtargz'. -- Sean Whitton signature.asc Description: PGP signature
Re: git workflows (was: Steam Deck: good news for Linux gaming, bad news for Debian :()
Hello, On Sat 14 Aug 2021 at 07:55AM +01, Jonathan Dowland wrote: > On Thu, Aug 12, 2021 at 03:31:02PM -0700, Sean Whitton wrote: >> For example, there are those of us who think that the downsides of the >> combination of 3.0 (quilt) and patches stored unapplied in git are >> significant, and so we have made attempts to provide alternatives, such >> as git-debrebase. Contributing to Debian would be a lot less fun if we >> were asked to just set these reasons aside and use something which to us >> is clearly technically inferior. > > You can appreciate that the decision you took, in your interest, has the > direct cost that Romain mentioned, right? Even if I agree with you about > the technical merits of your approach, and I do, the consequence is an > increasingly complex and non-uniform surface area for other > contributors. Right. To be clear, I think that it's in the project's interests, not just my own. I made my remarks in terms of 'fun', but I don't mean fun for its own sake / for my own sake. > The task would be mammoth, and the likelyhood of success not > guaranteed, but I think in these circumstances implementing a > technical improvement to a project-wide process would be the way to > go. This pre-supposes that there *was* a project-wide process. There I > agree with other posters on this thread: this is where to start. I'm sceptical that we yet have enough knowledge about all this to work in any way other than bottom-up, as we are doing. I might not like patches-unapplied much, but I don't deny there are some advantages to that approach over the ones I prefer, in certain packaging situations. -- Sean Whitton signature.asc Description: PGP signature
git workflows (was: Steam Deck: good news for Linux gaming, bad news for Debian :()
Hello Romain, others, On Thu 12 Aug 2021 at 02:06PM +02, Romain Porte wrote: > I think this is a major point. I am a new Debian contributor after a > good time of ArchLinux PKGBUILD writing. I find Debian technically > superior on the packaging side, and would not trade it for PKGBUILD. But > there are so many ways to do things. After a lot of exploration, I have > found that the tooling that I was the most comfortable with was: > > * Salsa VCS > * GBP for git + patching (+ DEP-conformant branch names) > * dh > > However there are so many other ways to do things. Some packages are not > on Salsa. Some packages use manually generated diff files. Different > branch names everywhere (debian/latest vs. debian/master vs. > debian/unstable vs. master…). I think progressive enforcing of a > workflow would help new maintainers to not be lost in the packaging jungle. > >> I still trust Debian to be the most technically excellent distribution, >> but that's not all it makes to stay relevant. My point is that it would >> help to reduce the technical liberties we take in Debian. However, I >> don't think that's who we are. > > Maintainers like their freedoms, but enforcing some tools at some point > could make it easier for everyone to contribute and not relearn the > packaging process for every package, because currently every package is > different. We are getting there by looking at the number of "3.0 > (quilt)" packages and "dh" usage, but when a package does not conform to > this norm, it triggers a mental freeze on my side (and I want to migrate > it all to dh/3.0 quilt etc.). I understand your frustration and I appreciate you persevering with involvement in Debian -- thank you! I'd like to offer a brief counterpoint to some of what you say, however. In many cases, indeed, the reasons why things like dh are not in use is simply that no-one has taken the time to update the package yet, as you say. However, in other cases it is because the maintainer has thought through the options and decided against using those particular tools and workflows for principled reasons. For example, there are those of us who think that the downsides of the combination of 3.0 (quilt) and patches stored unapplied in git are significant, and so we have made attempts to provide alternatives, such as git-debrebase. Contributing to Debian would be a lot less fun if we were asked to just set these reasons aside and use something which to us is clearly technically inferior. -- Sean Whitton signature.asc Description: PGP signature
Re: Figuring how to work with team-maintained packages on salsa
Hello Helmut, On Sun 06 Jun 2021 at 09:58PM +02, Helmut Grohne wrote: > There is another issue affecting me, that may derail from the original > topic. When I work with packages I tend to fix bugs that are reported by > some CI system on unstable. When I dgit clone, I may get the unstable > version or I may get unreleased changes that may work or may be broken. > That's not what I want. Instead, I strongly prefer working with exactly > that version that produced the failure in CI. Even accidentally using > experimental often produces wildly differing results. Beyond that, I > don't want my trust root for software to reside in SSL certificates. I > haven't found a way to ask dgit to produce a git tree that exactly > produces the source package signed by unstable reliably. I think there is some confusion. 'dgit clone' should always get you what is in unstable, and thus exactly what the CI system was using. It would be a bug if it gave you unreleased changes, and I don't think we've ever seen a bug report like that. (The only exception I can think of is if mirror sync issues interact with your clone, but I think there is code to try to avoid that.) > Admittedly, not working with unreleased changes makes integrating them > harder for the maintainer. That's certainly a trade-off between my time > and their time. I've chosen that I'm unwilling to work with unreleased > changes of arbitrary packages. Their quality is too unpredictable to me. Yeah. 'dgit clone' is meant to be useful in exactly this situation. >> What dgit doesn't really help you with is integrating those patches >> directly into the maintainer's repo, if the maintainer invites you to >> push your changes directly, which is perhaps what Florian was looking >> for. > > Yes, that. debdiff kinda is the universal format here as it is > recommended in the developers reference and can be produced for > arbitrary packages. bugs.debian.org is a universal communication method > to package maintainers. It's a bit annoying, but universal (inside > Debian). > > Thinking more about this, there is one project of Jelmer that is getting > closer to reintegrating changes. It is silver-platter, which really > attempts to grok maintainers' idiosyncrasies and produce patches in the > way they desire. As far as I know, it actually works with a significant > portion of the archive already as it backs janitor.d.n. > > If everyone was using dgit, then yes it would be providing that > homogeneity much like dh does provide homogeneity on the packaging > helper level now. The way it currently is, dgit unfortunately is > https://xkcd.com/927/ (standards). We really cannot have both workflow > diversity and homogeneity. Either of them must be unhappy and dgit > chooses not to make the workflow diversity people unhappy. The price for > homogeneity is telling a significant number of people that they cannot > continue using their workflow and making them very unhappy that way. I think you might be mixing together debdiffs as the universal way to share changes, and the problem of integrating changes into maintainer git trees. The former dgit is useful for -- it can help you produce debdiffs to send to the BTS in a way that's more sane than working with raw source packages outside of VCS. The latter is the harder problem. -- Sean Whitton signature.asc Description: PGP signature
Re: Seeking feedback on a meta package builder
Hello, On Fri 04 Jun 2021 at 06:39PM +02, Helmut Grohne wrote: > Hi Sean, > > On Thu, Jun 03, 2021 at 04:47:44PM -0700, Sean Whitton wrote: >> dgit wraps some of the existing tools. While dgit is mainly for humans, >> one role it can have in automated toolchains is producing an ephemeral >> source package for the purpose of performing a build where the real >> input is a git tree. dgit knows how to convert various forms of git >> tree into source packages and there are TODOs for some others. > > While dgit does wrap build tools and thus could be a possible mdbp user, > dgit does so in a way that forwards the flexibility of those build tools > through dgit. As such, it has a subcommand for each implementation and > lets the user fiddle with the underlying implementation in the way they > want without providing any kind of abstraction. I'm vaguely convinced > that for dgit, this is best. An abstraction could be added as another > subcommand if desired, but does buy little in the end. After all, dgit > users tend to want tight control over the build and know their favourite > build tool well. > > The intended audience for the abstraction on the other hand would be > performing many builds in a mechanical way. Right. I was thinking that if you wanted to perform many builds from git trees, dgit could help obtain the .dscs. -- Sean Whitton signature.asc Description: PGP signature
Bug#991906: ITP: userv-utils -- privsep utilities collection
Package: wnpp Severity: wishlist Owner: Sean Whitton X-Debbugs-Cc: debian-devel@lists.debian.org, ijack...@chiark.greenend.org.uk * Package name: userv-utils Version : 0.6.1 Upstream Author : Ian Jackson * URL : https://www.chiark.greenend.org.uk/ucgi/~ian/git?p=userv-utils.git;a=summary * License : GPL-3+ & CC0-1.0 Programming Lang: C, Perl Description : privsep utilities collection Utilities to accompany bin:userv. I am packaging this primarily for the included ipif utility, which allows creating a network interface which speaks SLIP. -- Sean Whitton signature.asc Description: PGP signature
