Re: Package uploads silently discarded: how to investigate?
Andrey Rahmatullin writes: > On Mon, Jun 27, 2022 at 09:02:30AM +1000, Ben Finney wrote: > > In this thread I want to discover: How can I find out what's > > happening and why the Debian archive is no longer sending me any > > email messages about my package uploads? > You should check usper.debian.org:/srv/upload.debian.org/queued/run/log Thank you, that has the information I need, and now I successfully diagnosed what was wrong with a couple of uploads. As to how someone can know this in future: "IOhannes m zmölnig (Debian/GNU)" writes: > as i've wondered myself about this in the past (not for some time > though, since i no longer update my keys just-in-time): would it be > possible to list reasons for (silent) discards on a prominent page? > (e.g. somewhere on https://ftp-master.d.o¹). Yes, please. I think your suggestions are a good starting point. -- \ “Airports are ugly. Some are very ugly. Some attain a degree of | `\ugliness that can only be the result of a special effort.” | _o__) —Douglas Adams, _The Long Dark Tea-Time of the Soul_, 1988 | Ben Finney
Re: Package uploads silently discarded: how to investigate?
Russ Allbery writes: > Ben Finney writes: > > > The trouble is, I can only guess, because there are no messages from > > anything in the Debian archive telling me what went wrong. > > My recollection is that if the signature on the upload is invalid, we > intentionally delete the upload with no notice (because we have no > confirmed knowledge of who to notify). So, the question remains: How can I, the person responsible for uploading this to the queue, find out (not guess based on absence of any message) what the error was that caused the submission to fail? -- \ “Our urge to trust our senses overpowers what our measuring | `\ devices tell us about the actual nature of reality.” —Ann | _o__) Druyan, _Cosmos_, 2014 | Ben Finney
Package uploads silently discarded: how to investigate?
Howdy all, For many weeks, my package uploads have been silently discarded. I have some guesses as to why but I can't find any concrete report saying so. Typically I'll receive an email message to my maintainer email address saying the package is being processed, and later a message saying it's succeeded or failed. By “silently discarded”, I mean that an upload of a package – whether source package or binary package, and whether using ‘dput’ or FTP commands directly – succeeds, then soon afterward the files no longer appear in the ‘/pub/UploadQueue/’ directory; then there is no further communication from the Debian archive infrastructure. My guess is that this is something to do with an update to the signing GnuPG key expiry date. I can get into that in a different thread if needed. The trouble is, I can only guess, because there are no messages from anything in the Debian archive telling me what went wrong. In this thread I want to discover: How can I find out what's happening and why the Debian archive is no longer sending me any email messages about my package uploads? -- \ “The enjoyment of one's tools is an essential ingredient of | `\ successful work.” —Donald Knuth, _The Art of Computer | _o__) Programming_ | Ben Finney
Re: Project to improve Debian support model
Howdy Katy, Katy Tolsen <2ndlifek...@gmail.com> writes: > I've started a project with the aim to improve Debian's support > model > […] I see that in the intervening time, the project repository has moved away from GitHub (thank you!) and to this URL: https://git.fosscommunity.in/kathryntolsen/diss/> > For consideration of our developers, I ask for your input on this > matter […] The wiki content there has an overview of the intended architecture. Core Components of the Debian Integrated Software System * DISS Bot * DISS Chat Client * DISS Client * DISS Diagnostic Trees * DISS Tracker https://git.fosscommunity.in/kathryntolsen/diss/-/wikis/home> As you state on the wiki, many of those pages are without content. To help get an informal idea, can you describe briefly each of those components? -- \“Consider the daffodil. And while you're doing that, I'll be | `\ over here, looking through your stuff.” —Jack Handey | _o__) | Ben Finney signature.asc Description: PGP signature
Re: Project to improve Debian support model
Howdy Katy, Katy Tolsen <2ndlifek...@gmail.com> writes: > I've started a project with the aim to improve Debian's support model > […] I see that in the intervening time, the project repository has moved away from GitHub (thank you!) and to this URL: https://git.fosscommunity.in/kathryntolsen/diss/> > For consideration of our developers, I ask for your input on this > matter […] The wiki content there has an overview of the intended architecture. Core Components of the Debian Integrated Software System * DISS Bot * DISS Chat Client * DISS Client * DISS Diagnostic Trees * DISS Tracker https://git.fosscommunity.in/kathryntolsen/diss/-/wikis/home> As you state on the wiki, many of those pages are without content. To help get an informal idea, can you describe briefly each of those components? -- \ “Teach a man to make fire, and he will be warm for a day. Set a | `\ man on fire, and he will be warm for the rest of his life.” | _o__) —John A. Hrastar | Ben Finney
Re: Survey results: git packaging practices / repository format
Sean Whitton writes: > I don't think the comment about quilt is unreasonable, because it seems > like you've just been lucky in not having to use quilt, or similar, yet. > "Never having a Debian delta" would seem to be a property of packages, > not workflows. There's some conflation here between “never had a need for additional tools like Quilt” with “never needing a Debian packaging delta”. I've never needed the former, and always needed the latter. I don't think the latter at all implies the former. -- \ “People demand freedom of speech to make up for the freedom of | `\ thought which they avoid.” —Soren Aabye Kierkegaard (1813–1855) | _o__) | Ben Finney
Re: Survey results: git packaging practices / repository format
Ian Jackson writes: > What should another Debian contributor do, who wants to make a change > to the upstream source, but wants to do so in your own git workflow > and collaborate via your git branch, rather than by uploading a .dsc ? I'm increasingly baffled here. Why does anyone need anything but the existing VCS tools (to work with upstream's VCS) and the DEP-3 patch format (to represent the changes in Debian packaging) for this? > I think they would need to use quilt[1]. Are we talking here about the “3.0 (quilt)” package source format? I don't consider that “using Quilt” because no maintainer of the package needs to even know what Quilt is, let alone use it, for that format to work. If someone finds Quilt makes the job easier, more power to them; but I don't see it as any kind of requirement in the workflow. Not even noteworthy in discussing the packaging workflow. > So that explains why your branch format is listed in that table as > requiring quilt. Unless there's something I'm missing here, I think that's just a false statement. -- \ “I have a large seashell collection, which I keep scattered on | `\the beaches all over the world. Maybe you've seen it.” —Steven | _o__) Wright | Ben Finney
Re: Survey results: git packaging practices / repository format
Russ Allbery writes: > Ben Finney writes: > > > It may be “bare debian” is meant to cover this; but I don't > > recognise the comment “requires use of quilt and similar tools” > > because I've never needed to use Quilt for this. > > How do you handle needed changes to the upstream source? * Use whatever VCS is published by upstream, to implement the change. * Preferably do this in a local fork, because: * Rebase the branch as necessary while the change is not yet merged upstream. * Export that change as a series of patches. * Those patches become DEP-3 files in ‘debian/patches/’ of the Debian package. So the VCS tools themselves, and the DEP-3 format, completely (?) obviate the need for any human to touch Quilt. > Or do you just never make any changes to the upstream source? We are rarely that lucky! Changes to upstream are very often needed. That's a good reason to maintain a local clone of the upstream VCS repository. And with a good Distributed VCS (like Git) resolving divergent upstream development while you wait for them to (if ever) accept the changes upstream, patches are relatively easy to keep clean. -- \ “Oh, I realize it's a penny here and a penny there, but look at | `\ me: I've worked myself up from nothing to a state of extreme | _o__) poverty.” —Groucho Marx | Ben Finney
Re: dgit advocacy again (Re: Survey results: git packaging practices / repository format)
Ian Jackson writes: > I have said before that I think using "dgit push" (where possible) is > an ethical imperative. (I should clarify that I *don't* mean that > people who aren't using "dgit push" yet are bad people. Life is so > full of ethical imperatives that no real human could meet them all, > and of course Debian's right to call on volunteer effort is limited.) Perhaps “ethical imperative” isn't what you mean, then? I understand an ethical imperative to be instruction demanded ethically (e.g. “don't trade people as property”). If one fails to dobey an ethical imperative, one *is* necessarily a bad person. Certainly I hope you don't consider that anyone who chooses not to use ‘dgit’ is thereby an ethical villain; and so I hope you'll avoid the term “ethical imperative” for your instruction there. Your meaning seems better expressed by an “ethical virtue”; some instruction (e.g. “donate time at a homeless shelter”) which when a person follows it makes that person praiseworthy, but which we do not condemn every person who fails to follow it. -- \ “I have never made but one prayer to God, a very short one: ‘O | `\ Lord, make my enemies ridiculous!’ And God granted it.” | _o__) —Voltaire | Ben Finney
Re: Survey results: git packaging practices / repository format
Ian Jackson writes: > Please let us know if we have missed one. It is probably better if > you ask us rather than just adding it, unless you're sure that what > you are adding isn't the same as one of the existing ones. In > particular it seems that "unapplied" is used by a large number of > people with disjoint tooling and disjoint terminology. I don't recognise the repository structure that was raised by myself and some others: A VCS repository that contains only the Debian packaging files, which at build time is then exported to a non-VCS working tree and moerged with the upstream source. It may be “bare debian” is meant to cover this; but I don't recognise the comment “requires use of quilt and similar tools” because I've never needed to use Quilt for this. > I hope you all won't mind too much that Sean and I have privileged our > own point of view, in the columns which contain value judgements, and > that we hope to retain that property of the page. The page admonishes that we not edit ithe “value judgement” fields; but the same page offers no clear alternative forum to achieve changes there. -- \“If you ever drop your keys into a river of molten lava, let | `\ 'em go, because, man, they're gone.” —Jack Handey | _o__) | Ben Finney
Re: Survey: git packaging practices / repository format
Ian Jackson writes: > Can you please look through the table below and see if I have covered > everything you do ? You have covered the workflows I set up where I have the choice. Thanks. -- \ “I am amazed, O Wall, that you have not collapsed and fallen, | `\since you must bear the tedious stupidities of so many | _o__) scrawlers.” —anonymous graffiti, Pompeii, 79 CE | Ben Finney
Re: Difficult Packaging Practices
Sam Hartman writes: > If you just want to get upstream's idea of their package onto a system > with their release schedule and their recommended dependency versions, > there are better ways than getting a package into Debian. In the Debian mentors forum (that is, the chat channel, the mailing list, etc.) we make a point of saying: that's fine! Not every package needs to be in Debian, for its users to install that package. Someone who wants what you describe above can learn how to make a Debian package that will only be side-loaded from that community's own repository, or whatever. Perhaps that needs to be stated louder or more consistently? -- \ “Truth is stranger than fiction, but it is because fiction is | `\ obliged to stick to possibilities, truth isn't.” —Mark Twain, | _o__) _Following the Equator_ | Ben Finney
Re: dgit FAQ
Sean Whitton writes: > This now exists: https://wiki.debian.org/DgitFAQ Thank you. One issue I noticed: git-buildpackage and git-dpm users are fully supported […] That seems to contradict earlier statements that “separate Debian-packaging-only repository” workflow (which is supported by Git-BuildPackage) is currently not supported by DGit. Is the DGit FAQ wrong on that point? -- \ “Pinky, are you pondering what I'm pondering?” “I think so, | `\ Brain, but if they called them ‘Sad Meals’, kids wouldn't buy | _o__)them!” —_Pinky and The Brain_ | Ben Finney
Re: Preferred git branch structure when upstream moves from tarballs to git
Ian Jackson writes: > So far I have gained the impression that the kind of people who are > using packaging-only git trees tend to be very conservative, and very > comfortable with .dsc/tarball/patch/quilt based tools, and not really > convinced of the usefulness of git. Let me counter that impression, then: I am well convinced of the usefulness of Git, both generally and for Debian packaging in particular. I use it every day for all manner of development work. What I remain unconvinced of is the worth of abandoning the clean separation between an upstream source repository (whether Git repository or not) and a VCS repository for Debian packaging (typically in Git). The worth of such a clean separation is that it does not run afoul of the often wide differences between upstream developer team workflow and Debian package maintainer team workflow. So it's not conservatism or unwillingness to learn, in my case at least. I don't see that there's sufficient benefit to be had trying to weld their work together into one Git repository, when we have existing tools and workflows that don't demand that conflation. I believe I've made an informed assessment of the benefits and costs of a combined-upstream-with-Debian-packaging single VCS repository, and tentatively rejected it. That choice is not irrevocable and I could be convinced by sufficient benefit, but AFAICT the costs remain what they are. > I have even experienced what feels to me like significant hostility. Yes, I've seen that at times. I'm sure you get more that I haven't seen. It's sad to see when it happens. > If I am wrong and there are more users to be had by implementing this > feature then I will definitely consider giving it a higher priority. I'll try to find time to respond on the bug report you cited. > BTW, dgit is capitalised thus. Can't promise I'll remember that; as with DPut, it's easier to see the portmanteau term with distinct capitalisation, in my opinion. -- \ “Advertising is the price companies pay for being unoriginal.” | `\—Yves Béhar, _New York Times_ interview 2010-12-30 | _o__) | Ben Finney
Re: Preferred git branch structure when upstream moves from tarballs to git
Ian Jackson writes: > […] I have not taught dgit how to convert [separate Debian > packaging-only repository and upstream source repository] into a git > tree that contains the [combined] source code. One interpretation of “convert [separate repositories] into [one Git tree]” is that it's a flag-day, point of no return conversion that precludes the separate-Debian-packaging-repository workflow from that point forward. If so, that wouldn't be enough to convince me to use DGit, because I consider the separate-Debian-packaging-repository workflow superior for many cases. Contrariwise, on the assumption we are instead talking about a “conversion to a Git tree” that would seamlessly let DGit support the ongoing workflow of Debian packaging in a repository separate from any upstream code: > That feature would be the wishlist bug > #903392 "want support for packaging-only maintainer views" > which I've already mentioned once in this thread, where I explained > why implementing it is a low priority. While acknowledging you are under no obligation to implement features demanded by others, I'll point out that for as long as DGit lacks support for that workflow, you won't get much user feedback from people whose Debian packages need that workflow and therefore are not knowledgeable DGit users. So for as long as that persists, it will take special consious effort to remember that there's a class of Debian package maintainers who would like to become knowledgeable about DGit but can't yet; that the current DGit user base is not representative of that class of potential user. I trust you already know this, but it bears explicit expression from time to time :-) -- \ “Our task must be to free ourselves from our prison by widening | `\our circle of compassion to embrace all humanity and the whole | _o__) of nature in its beauty.” —Albert Einstein | Ben Finney
Re: Preferred git branch structure when upstream moves from tarballs to git
Sean Whitton writes: > Hello, > > On Tue 30 Apr 2019 at 08:05AM +02, Ansgar wrote: > > > As an example: to update to a new upstream release, I ideally just > > have to drop the new upstream tarball, update d/changelog and am > > done. > > As a package maintainer, if you don't keep the whole source package in > git, you're giving up on a lot of the power of git. I can't speak for Ansgar, but “you don't keep the whole source package in Git” is not implied by keeping Debian packaging separate. It's not accurate to the workflow, at least as I described (I don't know Ansgar's case, but nothing he described implies that either). Rather, I keep the Debian packaging source separate from the upstream source. That doesn't preclude Git access to the upstream source, and I frequently use a Git repository cloned from upstream for that. So, the Debian-packaging-in-a-separate-repository does not give up any of the power of Git. > The most significant thing is that you cannot manipulate quilt patches > as commits on a branch. It is also much more involved to cherry pick > commits from upstream branches, and quickly obtain diffs between > Debian's version of the code and arbitrary other branches, to mention > a few other things. The full power of Git is available when I manipulate upstream source to refresh my Debian patches. Indeed, it's even neater to refresh those patches by going straight from the only-upstream-source repository. > I also think that you're doing a disservice to downstream users. If > you're trying to fix a bug in the packaged version of some software on > your computer, you don't care about the distinction between Debian's > packaging scripts and the upstream code. It's all going to be turned > into a .deb once you've fixed your problem. You want the history of > the whole thing. Thus, a git history that contains both the upstream > git history and the Debian maintainer's changes to the packaging > scripts is going to be very useful. A git history of only the Debian > packaging scripts is much less useful. Conversely, I think it does a disservice to downstream users to mix in Debian packaging changes with upstream changes. The separation is useful and much easier to maintain when the repositories are separate. -- \ “Time is the great legalizer, even in the field of morals.” | `\ —Henry L. Mencken | _o__) | Ben Finney
Re: Preferred git branch structure when upstream moves from tarballs to git
Gard Spreemann writes: > Recently, upstream has finally started using git. What is the > recommended way for me to maintain a sane branch structure for the > packaging repository while starting to use upstream's git master as > the upstream branch to follow? My opinionated recommendation: Track the Debian packaging in a separate repository (which contains only the ‘debian/’ directory tree). When it's time to build the Debian source package for testing, export the upstream source to a temporary build directory and export the Debian packaging onto that. Build the Debian source package from the result. (Of course, Git-BuildPackage supports this workflow, with the ‘--export’ and related options.) Insulation from the kind of changes in upstream publishing that you describe, is a significant advantage of this Debian packaging workflow. -- \ “My girlfriend has a queen sized bed; I have a court jester | `\ sized bed. It's red and green and has bells on it, and the ends | _o__) curl up.” —Steven Wright | Ben Finney
Bug#927454: ITP: towncrier -- compiler for project news file
Package: wnpp Owner: Ben Finney Severity: wishlist * Package name: towncrier Version : 19.2.0 Upstream Author : Amber Brown and Contributors * URL or Web page : https://pypi.org/project/towncrier/ * License : Expat Description : compiler for project news file Towncrier is a utility to produce useful, summarised news files for your project. Rather than reading the VCS history as some newer tools do, or having one single file which developers all write to, towncrier reads “news fragments” which contain information *useful to end users*. . towncrier delivers the news which is convenient to those that hear it, not those that write it. . That is, a “news fragment” (a small file containing just enough information to be useful to end users) can be written that summarises what has changed from the “developer log” (which may contain complex information about the original issue, how it was fixed, who authored the fix, and who reviewed the fix). By compiling a collection of these fragments, towncrier can produce a digest of the changes which is valuable to those who may wish to use the software. -- \ “Often, the surest way to convey misinformation is to tell the | `\ strict truth.” —Mark Twain, _Following the Equator_ | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#927453: ITP: towncrier -- compiler for project news file
Package: wnpp Owner: Ben Finney Severity: wishlist * Package name: towncrier Version : 19.2.0 Upstream Author : Amber Brown and Contributors * URL or Web page : https://pypi.org/project/towncrier/ * License : Expat Description : compiler for project news file Towncrier is a utility to produce useful, summarised news files for your project. Rather than reading the VCS history as some newer tools do, or having one single file which developers all write to, towncrier reads “news fragments” which contain information *useful to end users*. . towncrier delivers the news which is convenient to those that hear it, not those that write it. . That is, a “news fragment” (a small file containing just enough information to be useful to end users) can be written that summarises what has changed from the “developer log” (which may contain complex information about the original issue, how it was fixed, who authored the fix, and who reviewed the fix). By compiling a collection of these fragments, towncrier can produce a digest of the changes which is valuable to those who may wish to use the software. -- \ “Often, the surest way to convey misinformation is to tell the | `\ strict truth.” —Mark Twain, _Following the Equator_ | _o__) | Ben Finney
Re: [Idea] Debian User Repository? (Not simply mimicing AUR)
Vincent Bernat writes: > ❦ 8 avril 2019 14:46 +10, Ben Finney : > > >> yes, it can be done, but it is a lot more work for individual > >> packagers. > > > > Sure. And, on the other hand, providing an APT repository for arbitrary > > packages of unknown copyright status is also a lot of work to expect > > disinterested volunteers to do without motivation. > > Disinterested volunteers are never forced to work for Debian. Yes, that's why I said “expect” and not “force”. > What is the point of being so negative? Not sure who you're addressing here, and I'm sorry if the discussion appears negative to you. -- \ “When I get real bored, I like to drive downtown and get a | `\ great parking spot, then sit in my car and count how many | _o__) people ask me if I'm leaving.” —Steven Wright | Ben Finney
Re: [Idea] Debian User Repository? (Not simply mimicing AUR)
Ben Finney writes: > Peter Silva writes: > > > With debian, it's kind of all or nothing. Etiher you're in Debian, > > and it gets built on every platform using the build farm, or it's > > not, so you get no help at all. > > That doesn't seem accurate. Have people tried setting up an APT > repository and got “no help at all”? Does the maintenance of the > packages to run an APT repository, and instructions on how to do it, not > count as help in doing that? As for the build farm: the parties who donate those to Debian did so on the understanding that they took on the load of building only the official Debian archive. Opening the gates to even unofficial Debian packages would be a significant increase in that burden on many of those donated machines. I think it's good to keep the distinction between official Debian archive (which is built on the official Debian build farm) versus unofficial packages (which need someone else with their own reasons to donate resources to build them). -- \ “The generation of random numbers is too important to be left | `\to chance.” —Robert R. Coveyou | _o__) | Ben Finney
Re: [Idea] Debian User Repository? (Not simply mimicing AUR)
Peter Silva writes: > On Sun, Apr 7, 2019 at 11:10 PM Ben Finney wrote: > > > If one needs to keep a close eye on changes to make sure they can > > still be installed even on a years-old OS, the resulting packages > > can be placed in a custom repository set up with the instructions at > > https://wiki.debian.org/DebianRepository/Setup>. What am I > > missing? > yes, it can be done, but it is a lot more work for individual > packagers. Sure. And, on the other hand, providing an APT repository for arbitrary packages of unknown copyright status is also a lot of work to expect disinterested volunteers to do without motivation. So it sounds like you know of at least enough individual developers that you have a group motivated to maintain an unofficial APT repository. That seems like an appropriate model: groups who want to make unofficial packages available can put in the sys-admin effort to run an unofficial APT repository with the existing tools. The Debian project does not (and, I believe, should not) need to be the home of third-party unofficial repositories; the tools to provide those are already in the hands of anyone who wants to provide them. > With debian, it's kind of all or nothing. Etiher you're in Debian, and > it gets built on every platform using the build farm, or it's not, so > you get no help at all. That doesn't seem accurate. Have people tried setting up an APT repository and got “no help at all”? Does the maintenance of the packages to run an APT repository, and instructions on how to do it, not count as help in doing that? > Launchpad gives a nice middle road that suits us right now, > and if something similar were available for debian, it would provide a > stepping stone to being in Debian proper. Conversely, I would argue that providing an APT repository for the unofficial packages they want available is a way for grroups to, on their own steam, provide that stepping stone. -- \“Beware of bugs in the above code; I have only proved it | `\ correct, not tried it.” —Donald Knuth, 1977-03-29 | _o__) | Ben Finney
Re: [Idea] Debian User Repository? (Not simply mimicing AUR)
Peter Silva writes: > […] the launchpad.net model, which supports backporting seamlesslly > and allows to support the same version on all distro versions, works > better for us. This is something a debian version of launchpad would > get us. How does it handle “seamlessly” changes that make a package incompatible with the already-released Debian stable? If it doesn't handle that, is it right to call that seamless? If one needs to keep a close eye on changes to make sure they can still be installed even on a years-old OS, the resulting packages can be placed in a custom repository set up with the instructions at https://wiki.debian.org/DebianRepository/Setup>. What am I missing? -- \ “I think Western civilization is more enlightened precisely | `\ because we have learned how to ignore our religious leaders.” | _o__)—Bill Maher, 2003 | Ben Finney
Re: [Idea] Debian User Repository? (Not simply mimicing AUR)
Peter Silva writes: > One thing that dampens our enthusiasm for that at the moment is that > our packages are still very unstable […], but if it gets baked into > debian, then we need to support some random old version for many > years. By that description it is not a good candidate for putting into Debian the operating system. If the upstream project is not going to support specific releases for years, that puts the onus on Debian package maintainers to choose a version for support during the lifetime of a Debian release. So would you agree, then, that the barrier to entry to the Debian system is appropriate in this case? -- \ “I don't want to live peacefully with difficult realities, and | `\ I see no virtue in savoring excuses for avoiding a search for | _o__)real answers.” —Paul Z. Myers, 2009-09-12 | Ben Finney
Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]
Ian Jackson writes: > Adrian Bunk writes: > > I thought this would would have been less offensive than the normal > > "This is a lie." > > You should never accuse someone of lying unless you are sure that they > know that what they are saying is wrong. For Adrian (since you acknowledged non-native English language status): Ian is pointing out the distinction between “That is a lie” (asserting the person knowingly intended to communicate a falsehood), versus alternatives like “That is false” or “That is not true” (which carries no implication of the person's intention or state of mind). > If you can prove that someone is deliberately saying untrue things on > Debian lists, that is abuse which should be reported and stopped. If you don't want to support a claim that someone is lying, you can avoid that implication: Just point out that the statement is not true (and then do as you (Adrian) did to show how you know it's not true). I hope that helps! -- \“Considering the current sad state of our computer programs, | `\ software development is clearly still a black art, and cannot | _o__) yet be called an engineering discipline.” —Bill Clinton | Ben Finney
Corresponding source for a machine-learning data set (was: Concerns to software freedom when packaging deep-learning based appications.)
Ian Jackson writes: > […] In the case of a pretrained neural network, the source code is the > training data. > > In fact, they are probably not redistributable unless all the training > data is supplied, since the GPL's definition of "source code" is the > "preferred form for modification". For a pretrained neural network > that is the training data. One hopeful sign is that people are addressing the need for the source form of a machine-learning product. In this case, it's by offering a version control system customised to machine-learning data. https://blog.dataversioncontrol.com/data-version-control-tutorial-9146715eda46> Is that an approach we can recommend to upstream developers who publish machine-learning data sets? -- \ “A child of five could understand this. Fetch me a child of | `\ five.” —Groucho Marx | _o__) | Ben Finney
Re: Concerns to software freedom when packaging deep-learning based appications.
Ian Jackson writes: > Things in Debian main shoudl be buildable *from source* using Debian > main. In the case of a pretrained neural network, the source code is > the training data. > > In fact, they are probably not redistributable unless all the training > data is supplied, since the GPL's definition of "source code" is the > "preferred form for modification". For a pretrained neural network > that is the training data. The above (with which I agree completely) puts me in mind of this article from O'Reilly Media: Compilers automated the process of writing machine code. Scripting languages automate many mundane tasks by gluing together larger, more complex programs. Software testing tools, automated deployment tools, containers, and container orchestration systems are all tools for automating the process of developing, deploying, and managing software systems. None of these take advantage of machine learning, but that is certainly the next step. […] We’ve seen research suggesting that neural networks can create new programs by combining existing modules. The system is trained using execution traces from other programs. […] Thinking more systematically, Peter Norvig has argued that machine learning can be used to generate short programs (but not long ones) from training data; to optimize small parts of larger programs, but not the entire program; and possibly to (with the help of humans) be better tutors to beginning programmers. https://www.oreilly.com/ideas/what-machine-learning-means-for-software-development> This thread will be just one of many we will need to have, to determine how best to preserve software freedom as the practice of developing software changes fundamentally. -- \“I always had a repulsive need to be something more than | `\ human.” —David Bowie | _o__) | Ben Finney
Re: get-orig-source and standardized source repacking
Simon McVittie writes: > The only times repacking the orig tarball is required are: > > […] > - it isn't available in a format supported by dpkg (with the extreme case > of this being that there is no orig tarball at all, only a VCS repository) A case more extreme: the work is not distributed upstream as tarball nor as VCS. It is available upstream only as disparate files, not from any single URL. (For a simple example of that, see the ‘lojban-common’ package.) -- \“I don't accept the currently fashionable assertion that any | `\ view is automatically as worthy of respect as any equal and | _o__) opposite view.” —Douglas Adams | Ben Finney
Re: Debian Policy 4.1.4.0 released
Sean Whitton writes: > I just pushed Debian Policy 4.1.4.0 to sid. Thank you to the ~20 > people who contributed to this release, which includes several first > time contributors of patches. > […] > > 4.9 > The ``get-orig-source`` rules target has been removed. Packages > should use ``debian/watch`` and uscan instead. Especially for this, my ‘debian/rules’ files thank you. -- \“Institutions will try to preserve the problem to which they | `\ are the solution.” —Clay Shirky, 2012 | _o__) | Ben Finney
Re: New lintian warning: vcs-deprecated-in-debian-infrastructure
Adam Borowski writes: > but pray tell, what will you do with that URL? Visit it later, when I *do* have internet access. Many people have internet connections that are unreliable, slow, expensive, arbitrarily blocked, or some combination of all those. We should not assume that “has internet access” is a binary, all-or-nothing property; and we should not dismiss the use cases of people who are between those extremes. -- \“Pinky, are you pondering what I'm pondering?” “Wuh, I think | `\ so, Brain, but wouldn't anything lose its flavor on the bedpost | _o__) overnight?” —_Pinky and The Brain_ | Ben Finney
Re: New lintian warning: vcs-deprecated-in-debian-infrastructure
Markus Koschany writes: > Am 22.03.2018 um 15:40 schrieb Guillem Jover: > > I'd very strongly object to completely moving those fields out of > > the source packages [&.3] I'll happily take outdated data than no > > data any day, because usually you can use that outdated data to > > trace your way to the current one, not so if it's missing. > > You need online access to make use of the above information in any > way. That's not true; you are incorrect in thinking that exhausts the common uses of that information. For example: > If you want to contact the maintainer you need internet access With the maintainer email address, I do not need internet access to compose an email message. Without that information I can't. > if you want to visit the upstream homepage you need internet access With the upstream home page URL, I do not need internet access to bookmark a URL. Without that URL I can't. > etc. So, there are plenty of uses for information that do not require internet access *at the time of using* the information. Yes, some uses do require internet access; that doesn't eliminate all usefulness of the information. So, I concur with Guillem: This information is closely tied to the source package, and the source package becomes less useful (lack of imagination notwithstanding :-) by taking that information away from the source package. There may be good arguments for removing that information from the source package. But let's dispose now of the “it's no use” claim; that's simply false, so some other justification will be needed. -- \ “If consumers even know there's a DRM, what it is, and how it | `\ works, we've already failed.” —Peter Lee, Disney corporation, | _o__) 2005 | Ben Finney
Re: Bug#880014: Technical committee appointment
Gunnar Wolf writes: > I have to pick a nit here - I know this mail probably comes from a > template and you are repeating what used to be true here. But, > according to GR 003 in 2016¹, Didier is the "Chair" of the Technical > Committee, not the "Chairman". Thank you, this was a well worded correction that avoided any accusation or shame. These corrections are always worthwhile, for improving the welcoming culture of the Debian community. -- \“If you continue running Windows, your system may become | `\unstable.” —Microsoft, Windows 95 bluescreen error message | _o__) | Ben Finney
Re: Updated proposal for improving the FTP NEW process
Gert Wollny writes: > […] simply asking the peers doesn't make the process very public. That is, IIUC, by design and for good reason. Before a review of the copyright status of the work is done, we don't have confidence the Debian Project has permission to redistribute it publicly. If it turns out the work is not redistributable by the Debian Project, it is then too late; and the case could be made that we should not allow that situation to arise (i.e. we should not redistribute before we have confidence the work can legally be permitted by us). So, putting it up on some public Debian infrastructure before it passes review is, IIUC, problematic for that reason at least. -- \ “Please leave your values at the front desk.” —hotel, Paris | `\ | _o__) | Ben Finney
Salsa issue tracker disabled for Debian group (was: A proposal for improving transparency of the FTP NEW process)
Thomas Goirand writes: > Also, I would really have preferred if Salsa's issue tracker feature > was simply removed/desactivated, because every other day, there's > someone proposing to replace debbug with it. Thanks but no thanks. As best I can tell, any project created in the Debian group https://salsa.debian.org/debian/> already has the Issues permission off, without anything else needing to be done. That seems entirely appropriate, for a Debian packaging project, for the reason you state (any Debian package should have bugs reported to the Debian BTS). Does that meet the preference you expressed above? -- \ “I distrust those people who know so well what God wants them | `\to do to their fellows, because it always coincides with their | _o__) own desires.” —Susan Brownell Anthony, 1896 | Ben Finney
Re: A proposal for improving transparency of the FTP NEW process
Paul Gevers writes: > Hi, > > On 03-03-18 11:57, Ben Finney wrote: > > A large code base with complex interacting works of copyright can be > > broken into smaller packages, that are each individually easier to > > review and pass through NEW; either built as separate source > > packages, or combined at build time. > > Except if there is one upstream tar ball. Do you really suggest we > should repack one upstream tar ball into multiple smaller tar balls > just for the review process? To say “should” is rather too strong. I'm presenting it as one option to try, for those who are frustrated at the slow review process for a large, complex source package with complex copyright interactions: Break it into more easily-reviewed pieces. The review process is an acknowledged bottleneck for NEW queue processing, and we've seen stated that large, complex source packages are especially difficult to get through. I'm proposing that the same code base as a set of smaller source packages will get through that bottleneck easier; I don't say that as a recommendation nor a “should”, but as an option to try, for those of us who not FTPmaster and are looking for ways to work better with the process. -- \ “Whenever you read a good book, it's like the author is right | `\ there, in the room talking to you, which is why I don't like to | _o__) read good books.” —Jack Handey | Ben Finney
Re: A proposal for improving transparency of the FTP NEW process
Lars Wirzenius writes: > Admittedly, it is quite a small package, but that's kind-of my point. > Making it easy for others to do the thing you need them to do is what > you can do to make things easier for you. Asking them to do more work, > or to change how they do their thing, is less likely to go well. > > The Linux kernel maintainers flat-out reject large patches that dump > big changes without prior discussion. This is because it's easier for > them to digest changes in smaller chunks, and they put the > responsibility for presenting the changes that way on the people > producing the patches. > > For Debian, I think we should have the same approach. […] Your recounted experience suggests another way (compatible with the ways you discussed) to reduce the work of reviewing a code base with complex copyright interactions: A large code base with complex interacting works of copyright can be broken into smaller packages, that are each individually easier to review and pass through NEW; either built as separate source packages, or combined at build time. Will that work for every large package? Maybe that's too much to hope for. But in those cases where the maintainers are frustrated that the NEW queue processing takes a long time to pass their new package: isn't it worth the effort to try making it easier to review by breaking the package into smaller more easily-reviewed chunks? A maintainer (or a team) who tries that might find it's not so hard; and having done that, it becomes that much easier to understand not only the copyright status of each smaller package, but for a newcomer to understand how to maintain it. This is a benefit not only in getting the package reviewed through the NEW queue, but also for attracting additional co-maintainers. Breaking large complex tangles into smaller manageable pieces is thus, I'd suggest, an investment in reducing the overall work of Debian package maintenance. > There may be other reasons why some packages stay in NEW for a long > time. Getting information from ftp masters about the reasons why, and > a discussion of how we can make easier for them to make NEW review > easier would, I feel, take us forward better than another than us > complaining that things are taking too long. Thanks for keeping the options open. -- \ Contentsofsignaturemaysettleduringshipping. | `\ | _o__) | Ben Finney
Bug#889696: ITP: editorconfig-gedit -- EditorConfig support for GEdit
Package: wnpp Severity: wishlist Owner: Ben Finney * Package name: editorconfig-gedit Version : 0.5.3 Upstream Author : EditorConfig Team * URL : https://github.com/editorconfig/editorconfig-gedit/ * License : BSD-2-clause Programming Lang: Python Description : EditorConfig support for GEdit EditorConfig makes it easy to maintain the correct coding style when switching between different text editors and between different projects. . This package installs the plug-in for GEdit to support EditorConfig settings. -- \ “I'm a born-again atheist.” —Gore Vidal | `\ | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#889694: ITP: editorconfig-core-py -- Python library for working with EditorConfig
Package: wnpp Severity: wishlist Owner: Ben Finney * Package name: editorconfig-core-py Version : 0.12.1 Upstream Author : EditorConfig Team * URL : https://pypi.org/project/EditorConfig/ * License : PSF-2 Programming Lang: Python Description : Python library for working with EditorConfig EditorConfig makes it easy to maintain the correct coding style when switching between different text editors and between different projects. . When developing an editor plugin for reading EditorConfig files, the EditorConfig core code can be used to locate and parse these files. . This package is the Python library of EditorConfig Core. This is a dependency for the ‘editorconfig-gedit’ package. -- \ 德不孤、必有鄰。 (The virtuous are not abandoned, | `\ they shall surely have neighbours.) | _o__)—孔夫子 Confucius (551 BCE – 479 BCE) | Ben Finney signature.asc Description: PGP signature
Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)
Adam Borowski writes: > One issue: on a small screen, crap font and no glasses, "ITR" looks similar > to "ITP", an alternate acronym could be better. RFI (Request for Interest) RFU (Request for Users) POLL (Participate Or Let's Lose this) -- \“Politics is not the art of the possible. It consists in | `\ choosing between the disastrous and the unpalatable.” —John | _o__)Kenneth Galbraith, 1962-03-02 | Ben Finney
GitLab repository logo customisation
Howdy all, Jeremy Bicha has a short post describing how a repository on Debian's GitLab can customise its avatar or logo. There’s a useful under-documented feature I found. If you place a logo.png in the root of your repository, it will be automatically used as the default “avatar” for your project (in other words, the logo that shows up on the web page next to your project). https://jeremy.bicha.net/2018/01/30/default-avatar-for-gitlab-repos/> -- \ “The great thing about science is we can test our ideas.… But | `\ until we do, until we have data, it is just one more proposal.” | _o__) —Darren Saunders, 2015-12-02 | Ben Finney
Serving repos from salsa, via ‘anonscm.debian.org’ URLs (was: salsa.debian.org (git.debian.org replacement) going into beta)
Guillem Jover writes: > But this still leaves all checkouts that will also need to be updated, > which is way way worse than the changes required in debian/control, > documentation, wiki, etc. :( I also mentioned this when we moved from > git.d.o to anonscm.d.o. This is an issue I haven't seen addressed with a solution, so far. We're being asked to migrate repositories, published at ‘anonscm.debian.org’ URLs, to a host that won't serve those same URLs. People who have ‘anonscm.debian.org’ as a remote URL should not, IMO, be expected to know about this move; nor event to check a website prior to the move (because there's no indication, from accessing that repository with Git, that anything is expwected to move anywhere). As Guillen points out, having the existing URL serve a moribund repository, while the repository continues development somewhere else, can be avoided – the domains are both in Debian Project control – and should be avoided if feasible, IMO. So it's important to keep ‘anonscm.debian.org’ working to access the same repository at the same URL, after it moves to ‘salsa’. What is the prospect, having migrated a repository to the salsa.debian.org host, to continuing to serve the repository at the published ‘anonscm.debian.org’ URL? -- \“A right is not what someone gives you; it's what no one can | `\ take from you.” —Ramsey Clark | _o__) | Ben Finney
Re: Why do we list individual copyright holders?
Marc Haber writes: > On Mon, 18 Dec 2017 20:01:12 -0500, Jeremy Bicha > wrote: > >I was forced to spend a few hours doing a thorough copyright file > >earlier this year for mozjs52 which is simply the JavaScript engine > >from Firefox 52 ESR. I first tried copying the Firefox 52 ESR's > >copyright file (removing the extra lines that didn't apply to this > >more minimal source) but it wasn't complete enough. (mozjs52 is > >essential for GNOME Shell 3.26.) > > In the long run, this is going to keep big software packages from > being packaged for Debian. We (the Debian Project) don't have to accept being the *only* ones shouldering this burden. Large upstream organisations have large shoulders. Surely a team responsible for a large code base also must – to avoid self-delusion – confront the need to know, with confidence that comes from standard, verifiable documentation, the provenance of works from which their code base is derived. This is quite apart from any requirements the Debian Project has; it is part of distributing any work that derives from many copyright holders over a log history of changes. Our conversations about this with upstream maintainers can, I think, more often be collaborative in nature. Instead of appealing to only one party's policy, appeal rather to the common need for this knowledge to be gathered, and maintained, and recorded somewhere, in a standard format for reference by anyone when needed. -- \ “The process by which banks create money is so simple that the | `\ mind is repelled.” —John Kenneth Galbraith, _Money: Whence It | _o__) Came, Where It Went_, 1975 | Ben Finney
Re: Has Copyright summarizing outlived its usefulness?
Simon McVittie writes: > On Wed, 13 Dec 2017 at 23:10:51 +1100, Ben Finney wrote: > > expecting to find “complete copyright holder information” such > > that we can be confident it *is* complete, solely in the upstream source > > is a folly, in my experience. > > Given that, on what basis can a user of the package gain value from > our claim that the complete list of copyright holders is present in > debian/copyright? Because that file is typically a record of a specific effort to *acquire* that information, and to document it for people who are careful about the provenance and grant of license in the work. The upstream source typically does not have that property, which is why I'm saying ‘debian/copyright’ is valuable for that in a way that can't be had from a typical upstream source work. > For non-trivial packages it almost certainly isn't, because if the > upstream maintainers (who gate all contributions) don't know the > complete list In my experience the information can be had from the upstream people, in many cases where it simply isn't recorded reliably or coherently in the source work. The distinction I'm drawing is in response to proposals in this thread, to declare the record in ‘debian/copyright’ to be obsolete. Some proposals have advocated that we rely on finding that information solely in the upstream work. I'm pointing out that's comparatively unreliable, by comparison to the current – admittedly under-resourced – concerted effort to find and gather and standardise and maintain that information for the benefit of people who want to quickly find the freedoms granted and who specifically grants those freedoms. > > This effort is rarely undertaken to completion in the general > > free-software community. > > Yes, and rather than seeing that as a source of disappointment with > the general free software community and demanding that our volunteers > spend heroic amounts of effort on doing it ourselves, perhaps we > should consider why it's rarely done, and spend our volunteers' time > more wisely? I agree that the burden falls unfairly on Debian Project volunteers. I prefer to have our volunteers push that responsibility upstream more often, making it a norm beyond our project and into the broader community, to expect that the information can be found. And gently, diplomatically, promoting the importance to any potential free software recipient of knowing the provenance of a work's copyright status and provenance. > Linux distributions exist, they don't attempt to list every copyright > holder on the Linux kernel, and in practice this is fine, which > suggests that this is an ocean we're trying to boil as a weird Debian > thing rather than because we actually need to. It's fine to have weird > Debian things that we do because we're Debian rather than because we > absolutely need to do them - but when we do, we should be clear about > why, so that we can stop enforcing them if the cost (mostly in > maintainer time and motivation, our most valuable commodities) exceeds > the benefit. I agree with the need to be clear about why. I hope this and other expressions in this thread have helped make it clearer. As you describe, the Debian Project has a long history in the free software community of leading by persistent example, on a basis of well-reasoned principle and informed by fact. I think this can continue. -- \ “If consumers even know there's a DRM, what it is, and how it | `\ works, we've already failed.” —Peter Lee, Disney corporation, | _o__) 2005 | Ben Finney
Re: Has Copyright summarizing outlived its usefulness?
Steve Robbins writes: > On Sunday, December 10, 2017 11:11:20 PM CST gregor herrmann wrote: > > My understanding is that a license without any information who puts > > the software under this license (i.e. who is the copyright holder > > who can grant these rights) is incomplete. > > OK, but surely it is up to Debian to choose the form of such > information. For instance: each binary package is unambiguously linked > to a source package; said source package is easy to locate and > contains the complete copyright holder information. That last point – whether it is easy or even feasible to locate the complete copyright holder information merely by inspecting the upstream source work alone – seems to be a particular issue in this discussion. While the upstream source work is easy to locate for a Debian package, the difficult task is locating *within* that upstream source work the complete set of license grants that apply for the recipient. If you're claiming that the *complete* copyright holder information is to be found there: that is rarely the case, in my experience. Perhaps for some simple, young, small, one-person works, written entirely without deriving from any other work, by someone diligent about recording their specific copyright information. With works more complex than that, or those that have some history, or some combination of existing works, or even those developed in the “throw it online and copyright be damned” world we increasingly seem to inhabit, expecting to find “complete copyright holder information” such that we can be confident it *is* complete, solely in the upstream source is a folly, in my experience. The frustrations expressed by many in this thread are keenly felt by those who interact with copyright, and not just by Debian package maintainers. It is a lot of effort for a software project, open to collaboration from the public at large, to record tracks carefully enough to show the specific copyright holders and license grants, and therefore to show provenance of the claimed grant of license in the work, to some later recipient who needs to be sure of their status under the law in most jurisdictions, and who may not have easy access to contact the copyright holders even if they could know who those are. This effort is rarely undertaken to completion in the general free-software community. The effort of figuring out who holds copyright in a typical published software work by the time it gets to the Intent To Package for Debian, is therefore difficult. It remains a significant effort after that, to keep the information updated as the upstream maintainers continue to make changes that potentially affect the copyright status of the work. I assume we're agreed that it is necessary, in order that the Debian Project can be confident we know the provenance of that work; which itself is necessary to justify our claim to have received from the specific copyright holders of the work some specific grant of license (which we then grant, in turn, to Debian users). To my mind, that effort – a precondition of confidently asserting the copyright information and license we intend to grant to Debian users of that software work – results in valuable and hard-won information typically found in no single organised place. As such, that information should not go unrecorded, it should be in a standard location for the purpose of viewing the asserted copyright status and enabling future verification of those claims. That IMO is a principal value of recording the license grants, and the collated information about the copyright holders, in the file ‘debian/copyright’ in a package. > In the medical device industry, regulators allow vendors to use the > "least burdensome" means of complying with a given regulation. At the > risk of sounding naive, why can't apply this principle to copyright? A naive answer might be: Because upstream copyright holders frequently do not provide, in the work itself, sufficient nor complete nor standardised documentation for us to use in complying with those requirements. So we present in a more standard (“least burdensome”, for the community members who want assurance of compliance) format, our best understanding of what evidence we have of our claim to the copyright information. -- \ “I knew things were changing when my Fraternity Brothers threw | `\ a guy out of the house for mocking me because I'm gay.” | _o__) —postsecret.com, 2010-01-19 | Ben Finney
Which files should go in ‘/usr/share/common-licenses/’? (was: Has Copyright summarizing outlived its usefulness?)
Wookey writes: > On 2017-12-08 01:42 +0100, Markus Koschany wrote: > > Why don't we add all DFSG-free licenses to > > /usr/share/common-licenses or /usr/share/free-licenses instead? > > I would second this. It seems odd that we only have a small subset in > common-licences so I often end up finding/copying in a copy to the > copyright file by hand. This seems like makework. I am sympathetic to this. There is significant value in being able to put a “License: GPL-3” paragraph that doesn't repeat the entire GPL v3, and instead refers the reader to ‘/usr/share/common-licenses/GPL-3’. The files in ‘/usr/share/common-licenses/’ get installed on every Debian system, by the ‘base-files’ package. This is needed because that allows ‘/usr/share/doc/…/copyright’ to refer to a file there, knowing it will be available. If I understand correctly, the justification of putting a file there must include that it is overwhelmingly more likely to save *storage space* overall (by reducing the space in a corresponding number of ‘/usr/share/doc/…/copyright’ files), especially on machines that have low disk space in ‘/usr/share/’. So I think we should specifically ask the position of people who have expertise maintaining machines with very small disk space: How to judge which files should be unilaterally installed in that directory, in the hope of saving not only the efforts of package maintainers, but also the storage requirements on storage-constrained systems. -- \ “It seems intuitively obvious to me, which means that it might | `\ be wrong.” —Chris Torek | _o__) | Ben Finney
Re: Has Copyright summarizing outlived its usefulness?
Ian Jackson writes: > From what I've seen of the ftp review process, the file-by-file > information is invaluable to ftpmaster review. As in, the ftpmaster > review would probably be impractical without it. ftpmaster review > necessarily focuses on the contents of the source package. It is also invaluable, from what I can tell, as a common reference point between what the *actual* copyright information of the work is – something that can only be inferred, and that can change as the work changes – versus what the maintainer *has inferred* as the copyright information of the work. Without that, it's very hard to talk about differences between what the maintainer thinks is the case, versus what information is actually in the upstream work. > That the information for ftpmaster review has ended up being shipped > as the user-facing copyright notice in the binary is arguably not > ideal for some of the reasons we have explored here. Agreed. Though I don't know of a better way, today, to serve the purposes described above. > So we go with what we have, and what we already have a mechanism for > auditing. Thanks for expressing this succinctly, Ian. -- \ “It’s a great idea to come in unencumbered by dogma but you | `\can’t also be unencumbered by evidence.” —Darren Saunders, | _o__) 2015-12-02 | Ben Finney
Re: Debian Stretch new user report (vs Linux Mint)
Jonathan Dowland writes: > On Sun, Dec 03, 2017 at 09:17:59PM +0100, Thomas Goirand wrote: > >I at least, and probably a lot of Debian contributors, would start > >hating Debian for promoting hardware that needs non-free drivers if > >the non-free ISO was the default one. > > Are we promoting hardware that *doesn't* require non-free firmware > (not drivers, there is an important distinction) at the moment? I don't know what is meant (in either message) by “promoting hardware”. What does an assertion of “yes, we promote such-and-so hardware” imply? The implication that seems most sensible – we promote hardware to the extent that we produce the Debian operating system supporting it – would mean, AFAICT, that the Debian Project does not promote hardware that needs non-free drivers (because the Debian system does not provide such non-free drivers); and the Debian Project promotes hardware that doesn't require non-free firmware (because the Debian system by default needs no extra drivers for that hardware). > I don't think so. Where are we prominently explaining the problem? > Where are the links to the unencumbered hardware that people > could/should be using instead? This rhetorical question suggests that it's not the place of the Debian Project to promote specific hardware. I agree with that. On the other hand, we recognise, and can certainly draw attention to, hardware that works with entirely free software; and we can refuse to lend our effort to any reduction of software freedom for our users. > Are *you* using non-free firmware? The machines sold by, for example, ThinkPenguin, work with the latest Debian release, without non-free software. There's one example, which responds to the rhetoric of that question. That distinction – there is hardware which works with entirely free software, and we work to keep it so – is one of the most valuable things the Debian Project does, and is why I work for the Debian Project. There are, of course, hardware vendors that expend a lot of effort in opposition to that goal. That does not justify the Debian Project retreating from that goal. > I can understand the discomfort of grasping this nettle. Likewise, the nettle of pressing for increased software freedom is difficult to grasp, but IMO core to the Debian Project. > But are you completely closed to the idea of revisiting our core value > documents at all? The Social Contract and DFSG were written a long > time ago. Should the project not be open to looking at what our > collective values are today, or are we beholden to the terms layed > down by braver people, all those years ago? Any idea is open to examination, I'd say. But this thread has not presented any salient reason to retreat from the core values of the project. Indeed, the facts presented in this thread cast into sharp relief the urgency of recognising and pressing for software freedom. -- \ “I have a large seashell collection, which I keep scattered on | `\the beaches all over the world. Maybe you've seen it.” —Steven | _o__) Wright | Ben Finney
Easy discovery of ‘debian/rules’ build problems (was: Unsustainable debian/rules as official build entry point?)
Ian Jackson writes: > After there is only one consumer [of the package-provided > ‘debian/rules’ build interface], it will be somewhat easier to change > [the policy so that interface is not the standard]. >From the rest of your message I infer that the mention of “one consumer” there refers to (current or future) ‘dpkg-buildpackage’, is that correct? > Important consequences of my views include: > > * The package-provided rules interface needs to remain managed as part > of policy (and to continue to have a controlled approach to updates, > etc.). > > * The interface is not *defined by* dpkg-buildpackage: ie it is still > possible for dpkg-buildpackage to have a bug where it does not > implement the de-jure interface. > > * Packages may still need to work around bugs in old versions of > dpkg-buildpackage; conversely, new versions of dpkg-buildpackage may > need to work around bugs in old packages. > > * For a long time, packages should try to be compatible with old > builders which invoke rules directly, even old builders other than > dpkg-buildpackage. I had been under the impression the build tools (SBuild, PBuilder, etc.) invoke ‘debian/rules’ directly, and so are a good way to test that compatibility. Evidently that impression is wrong, and the use of those build tools is not helping to find such bugs. What tools exist to allow package maintainers – as many as possible – to get easy (automatic?) notification when the package they maintain is not presenting a compatible ‘debian/rules’ build interface? -- \ “Very few things happen at the right time, and the rest do not | `\ happen at all. The conscientious historian will correct these | _o__) defects.” —Mark Twain, _A Horse's Tale_ | Ben Finney
Re: Whether remotely running software is considered "software" for Debian.
Andrey Rahmatullin writes: > On Wed, Aug 30, 2017 at 01:51:16AM -0400, Anthony DeRobertis wrote: > > Policy is not the Social Contract, Policy is not the Constitution. > > Policy can be relatively easily changed and is supposed to largely > > document actual practices. So really, Policy needs to be amended. > > And attempting to language-lawyer Policy like this is pointless. > I don't it *needs* to be amended as there is no data that the current > policy language cause problems. Yes, I'm in agreement that the Policy wording has not been demonstrated to cause the alleged problems. I'm also in agreement with Anthony that, *if* the Policy wording is in conflict with agreed consensus practice, in that hypothetical scenario that would mean it is Policy that need to change. -- \ “A thing moderately good is not so good as it ought to be. | `\Moderation in temper is always a virtue; but moderation in | _o__) principle is always a vice.” —Thomas Paine | Ben Finney
Re: Whether remotely running software is considered "software" for Debian.
Anthony DeRobertis writes: > Policy is not the Social Contract, Policy is not the Constitution. > Policy can be relatively easily changed and is supposed to largely > document actual practices. So really, Policy needs to be amended. And > attempting to language-lawyer Policy like this is pointless. Thank you, that's all well put. -- \ “I love and treasure individuals as I meet them, I loathe and | `\ despise the groups they identify with and belong to.” —George | _o__) Carlin, 2007 | Ben Finney
Re: Whether remotely running software is considered "software" for Debian.
Carsten Leonhardt writes: > Actually, I haven't seen anyone citing the following part of policy > 2.2.1: "None of the packages in the main archive area require software > outside of that area to function." Yes, that's been raised. I've responded to that at https://lists.debian.org/msgid-search/851sodkbsc@benfinney.id.au>. -- \ “Software patents provide one more means of controlling access | `\ to information. They are the tool of choice for the internet | _o__) highwayman.” —Anthony Taylor | Ben Finney
Re: Project and User creation is now disabled on alioth.d.o
Alexander Wirt writes: > as alioth is deprecated and will (more or less) get replaced with > other services soon I disabled user creation and project creation on > alioth. > > Please stay tuned for the results of our sprint at the weekend, an > announcement should come that week. How exciting! Thank you to all for working on Alioths successor, and for working to make a graceful transition. -- \ “We spend the first twelve months of our children's lives | `\ teaching them to walk and talk and the next twelve years | _o__) telling them to sit down and shut up.” —Phyllis Diller | Ben Finney
Package Managers All the Way Down
Howdy all, I am catching up with the Linux.conf.au 2017 presentations, and have just watched “Package Managers All the Way Down” by Kristoffer Grönlund https://archive.org/details/lca2017-Package_Managers_all_the_way_down>, also discussed at LWN https://lwn.net/Articles/712318/>. The problems Kristoffer covered are ones that affect the Debian Project a lot, and his call for solutions is interesting. Are there any DebConf 2017 presentations or working groups that are tackling this? -- \“I'd take the awe of understanding over the awe of ignorance | `\ any day.” —Douglas Adams | _o__) | Ben Finney
Re: Whether remotely running software is considered "software" for Debian.
"Dr. Bas Wijnen" writes: > I'm referring to policy 2.2, which lists what software belongs in main > and what belongs in contrib. While this is not voted on and it does > not follow directly from the SC, I thought there was agreement that > what's in Policy 2.2 is a good way to determine where software should > go. In particular, if it is free, but requires software outside of > main to do its job, then it should go in contrib. The parts of Policy §2.2 relevant to this appear to be: §2.2.1 “The main archive area” […] In addition, the packages in _main_ * must not require or recommend a package outside of _main_ for compilation or execution (thus, the package must not declare a [dependency relationship] on a non-_main_ package) […] §2.2.2 “The contrib archive area” The _contrib_ archive area contains supplemental packages intended to work with the Debian distribution, but which require software outside of the distribution to either build or function. […] Examples of packages which would be included in _contrib_ are: * free packages which require _contrib_, _non-free_ packages or packages which are not in our archive at all for compilation or execution […] The language is clear that it is talking about dependency in the sense of requiring the program installed on the system in order for the program to build or execute. > People are arguing here that "It requires a network server that is not > in main" is fundamentally different from "it requires local software > that is not in main". I don't know of any program even proposed for Debian that would require a network server in order to build or execute that program. So yes, that is a distinction that is salient in the above Policy language. > I think they are equivalent; server software is still software and I > don't see why it running remotely suddenly makes it acceptable to > depend on it. You appear to be using “depend” here to mean “without this the program *is not useful*”. That is not a distinction relevant to the above Policy sections. They speak only to whether the program will build or execute. Whether the program does something useful is not relevant for the categorisation into different archive areas, as laid out in the above Policy sections. > Policy 2.2. So again, I'm not saying the rules apply to the external > software, I'm just saying that the external software is indeed > software and therefore depending on it requires a package to be moved > to contrib if the external software is not packaged in Debian (main). The text of the above Policy sections uses “depend” and “require” in the sense only for the cases they explicitly state: that of building the program or executing it. > Similarly, if a client program's purpose is to connect to a server > that is not in main, the server operator doesn't need to do anything, > but the fact that it is not in main means (IMO, but apparently that is > disputed) that the client must be in contrib. The language in Policy §2.2 does not relate to any program's purpose at all. Policy experts may correct me, but I find that your interpretation does not fit what is written there. -- \ “When I was born I was so surprised I couldn't talk for a year | `\ and a half.” —Gracie Allen | _o__) | Ben Finney
Re: Whether remotely running software is considered "software" for Debian.
"Dr. Bas Wijnen" writes: > What seems to be the dispute is whether software that runs on a remote > system is still "software" for the purpose of our rules. That is not in dispute, it seems to me. The rules of the Debian Project can only bind what the Debian Project does. The Debian Project could moot rules about what the project will do with regard to software that runs on a remote system. While there are trends, I don't think such rules exist yet, or if they do you haven't shown us what rules you're referring to. The Debian Project does have rules about software *in Debian*, as described in, for example, our Social Contract. I hope we can agree that the Social Contract's rules about software in Debian do not have any power to restrict software running on remote systems (unless they also get their software from Debian). > I think [software that runs on a remote system] is [software for the > purpose of the Debian Project's rules], especially considering the > trend that almost everything is being moved into the cloud. Which of the Debian Project's rules are you referring to there? Can you show from where in those rules you draw this interpretation? > I believe Debian's philosophy should be that software running remotely > on behalf of the user should be considered part of the system By that philosophy, if person Foo connects to a system I am operating on the internet, the rules person Foo has chosen to accept are also binding on me? Even if I do not accept those rules? If not, please explain where that interpretation of your statement is inaccurate. > It seems clear to me that a program which is intended to interact with > server software does indeed require that server software to function. > So if there is no free implementation of the server, then the client > cannot be in main. Maybe so, but that appears to be a different position: that the Debian Project's rules apply to software in Debian which interacts with remote systems. That's very different from stating that the remote system's software is also part of Debian and therefore subject to the Debian Project's rules. Please help by clarifying which of those positions you hold. -- \ “One time I went to a drive-in in a cab. The movie cost me | `\ ninety-five dollars.” —Steven Wright | _o__) | Ben Finney
Re: Call for testers: DPut version 1.0.0
Jonathan Carter writes: > I get the following: > […] > > I looked for tofu but there only seems to be a python-tofu package and > not a python3-tofu package, something I'm missing? Thanks. Please report it as a bug in the Debian BTS. -- \ “We can't depend for the long run on distinguishing one | `\ bitstream from another in order to figure out which rules | _o__) apply.” —Eben Moglen, _Anarchism Triumphant_, 1999 | Ben Finney
Re: Embedded library copies - mergerfs
Ritesh Raj Sarraf writes: > To quote upstream: > It embeds libfuse because: > > I support many old platforms which use old and buggy versions of > libfuse. Embedding it keeps many of my users who don't know and don't > care to know how to update their systems from having to learn to build > libfuse themselves. This is a choice that developer can make, to take extra burden of maintaining a bundled third-party library. We can disagree whether it's overall a good thing (it makes security updates more difficult than they need to be, etc.) but the developer is clearly meeting a need expressed by the users of the software. You can try to persuade them otherwise, but such persuasion should bear in mind the developer is knowingly accepting the *work* of maintaining that bundled ‘libfuse’ library. > So far, in Debian, I've pushed version 2.21.0. The last version > without the embedded library. > > Any advise on what should be our take further ? You have correctly identified that the embedded library should not be used in Debian, and instead the Debian ‘mergerfs’ package should use only the first-class Debian ‘libfuse’ package. By your description, the upstream code doesn't do that. One obvious workaround is to remove the embedded library in the Debian ‘mergerfs’ package ‘clean’ target, patch the software to instead use Debian's packaged ‘libfuse’ library, and maintain that patch in the Debian ‘mergerfs’ package, indefinitely. There may be some upstream changes that you could suggest which would make that easier. Could a bit of refactoring in ‘mergerfs’ allow for an easily configurable ‘libfuse’ location? Could those changes be made acceptable by the upstream developer? -- \ “The cost of a thing is the amount of what I call life which is | `\ required to be exchanged for it, immediately or in the long | _o__) run.” —Henry David Thoreau | Ben Finney
Call for testers: DPut version 1.0.0
Howdy all, I have released version 1.0.0 to Debian Experimental, and it now needs plenty of testing to find regressions from earlier behaviour. This release represents a culmination of carefully preserving the existing behavior while porting the code base to Python 3, ahead of the deprecation of Python 2 in Debian. While there are a number of feature requests outstanding, this release is focussed primarily on making sure all existing use cases are supported without breakage from the significant upheval in the code base. Please try your strange uploads, and anything else you use ‘dput(1)’ and ‘dcut(1)’ for, with varying configurations. If there are any regressions I want you to report them in the Debian BTS, so they can be investigated before a wider release. If anyone has unusual use cases that are feasible for automation, I am also interested in setting up an automated feature test suite. Please contact me at . Thanks in advance for your help to improve DPut! -- \ “Too many pieces of music finish too long after the end.” —Igor | `\ Stravinskey | _o__) | Ben Finney
Re: Call for Signatures: stretch dedication
"Adam D. Barratt" writes: > On 2017-06-14 9:48, Ben Finney wrote: > > For those who (like me) had difficulty with some of these steps, here's > > how I eventually got it done: > > Out of curiosity, which step(s)? They all seem fairly > self-explanatory, but I may well be missing something. Not everyone knows how to do them, or may think they know but still get it wrong, so I thought an explicit series of commands might help. > [...] > > $ gpg --detach-sign \ > > --local-user "$DEBSIGN_KEYID" \ > > --output "$sigfile" --armor \ > > ./dedication-9.0.txt > > fwiw, with the exception of the --local-user switch, which is only > required if your Debian key isn't also your default key My default key is my Debian signing key, nevertheless the earlier command grabbed a completely unrelated key. So yes, this is the step that tripped me up, so I found it easy to believe not everyone would find every command obvious. -- \ “I was trying to daydream, but my mind kept wandering.” —Steven | `\ Wright | _o__) | Ben Finney
Re: Call for Signatures: stretch dedication
Jonathan Wiltshire writes: > We welcome every Debian developer, maintainer, translator, or > contributor in any other field to join us in signing this dedication. Thanks for calling on us to make this dedication. > If you wish to do so, please: For those who (like me) had difficulty with some of these steps, here's how I eventually got it done: = $ curl --location --remote-name-all \ https://people.debian.org/~jmw/dedication-9.0.txt […] $ sha1sum ./dedication-9.0.txt fb37a995eebad8ced194709a9a2eb7a68ad8979c ./dedication-9.0.txt $ sigfile="Your_Name" $ gpg --detach-sign \ --local-user "$DEBSIGN_KEYID" \ --output "$sigfile" --armor \ ./dedication-9.0.txt $ gpg --verify "$sigfile" ./dedication-9.0.txt gpg: Signature made Wed 14 Jun 2017 18:37:12 AEST gpg:using RSA key A1A10BC6C2451DAC42D3B28B0EA5AC6F65D1F1F7 gpg: Good signature from "Ben Finney " [ultimate] […] gpg: aka "Ben Finney (Debian Project) " [ultimate] […] = Then attach the resulting "$sigfile" to a message to Jonathan. -- \ “What is needed is not the will to believe but the will to find | `\ out, which is the exact opposite.” —Bertrand Russell, _Free | _o__) Thought and Official Propaganda_, 1928 | Ben Finney
Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)
Ian Jackson writes: > Use [dgit] to publish your git history, by doing your uploads with > dgit push. > > The root goal is this: Debian should publish the source for all our > packages, as git branches, in a format that is directly useable by > ordinary people. Thanks. That is what I think anyone reading the package description needs to know; it's context that simply isn't there. > I would be very happy to hear suggestions for improving the > descriptions. Ideally without making them longer. Making it longer is unavoidable, I think, since the issue as I see it is the context is missing. So I hope you'll be convinced to add that context to the package description. Adding a paragraph like the above one about “the root goal” would be an excellent start. -- \ “Why doesn't Python warn that it's not 100% perfect? Are people | `\ just supposed to “know” this, magically?” —Mitya Sirenef, | _o__) comp.lang.python, 2012-12-27 | Ben Finney
Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)
Ian Jackson writes: > I want every maintainer who is using git to be able to use dgit. Use it to do what, though? The package description is currently: git interoperability with the Debian archive dgit (with the associated infrastructure) makes it possible to treat the Debian archive as a git repository. . dgit push constructs uploads from git commits . dgit clone and dgit fetch construct git commits from uploads. That sounds to me like it isn't a tool for maintainers, but rather a tool for “interoperability with the Debian archive” which AFAICT is already provided by the tools I am using. If the package does something that should be of interest to package maintainers in general, I'd expect the description to be a lot clearer what that is and why it's of interest. My apologies for publicly pointing to a package description for criticism, but it seems relevant to the claim that the package is for “every maintainer who uses git” that the description should explain why that is. -- \ “Pinky, are you pondering what I'm pondering?” “I think so, but | `\ where will we find an open tattoo parlor at this time of | _o__) night?” —_Pinky and The Brain_ | Ben Finney
Bug#860027: ITP: elpa-page-break-lines -- Emacs mode to display ugly ^L page breaks as tidy horizontal lines
Package: wnpp Severity: wishlist Owner: Ben Finney * Package name: elpa-page-break-lines Version : 0.11 Upstream Author : Steve Purcell * URL : https://github.com/purcell/page-break-lines * License : GPL-3+ Programming Lang: Emacs Lisp Description : Emacs mode to display ugly ^L page breaks as tidy horizontal lines This library provides an Emacs mode which displays form feed characters as horizontal rules. . The U+000C FORM FEED character is a normal white-space character, and in a text file is often used to mark virtual “page” separation. . Though it is rendered invisibly as white space, Emacs will (like many text editors) represent it with a glyph such as “^L”. This Emacs mode allows the same character to instead display as a custom horizontal line. I have found this package useful and would like to make it available in Debian. If the Debian Emacs addons team are willing, this could be maintained there, otherwise I will maintain it myself. -- \ “Those are my principles. If you don't like them I have | `\others.” —Groucho Marx | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#858160: ITP: wikiextractor -- tool to extract plain text from a Wikipedia dump
Package: wnpp Severity: wishlist Owner: Ben Finney * Package name: wikiextractor Version : 2.75 Upstream Author : Giuseppe Attardi * URL : http://medialab.di.unipi.it/wiki/Wikipedia_Extractor * License : GPL-3 Programming Lang: Python Description : tool to extract plain text from a Wikipedia dump The Wikipedia maintainers provide, each month, an XML dump of all documents in the database: a single XML file containing the whole encyclopedia, that can be used for various kinds of analysis, such as statistics, service lists, etc. This Wikipedia extractor tool generates plain text from a Wikipedia database dump. It discards any other information or annotation present in Wikipedia pages, such as images, tables, references and lists. Some works use Wikipedia data as part of their complete source. This package will be useful for build chains that require processing that data as source. -- \ “I put instant coffee in a microwave oven and almost went back | `\ in time.” —Steven Wright | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#858093: ITP: genealogy-data.us.1990 -- genealogy data from US Census 1990
Package: wnpp Severity: wishlist Owner: Ben Finney * Package name: genealogy-data.us.1990 Version : 1995.10 Upstream Author : US Census Bureau * URL : http://www2.census.gov/topics/genealogy/1990surnames/ * License : public-domain Programming Lang: none Description : genealogy data from US Census 1990 The United States Census Bureau receives numerous demands for summary data on the frequency of surnames for genealogical reasons. Similar interest has arisen for the frequency of first names by sex. This data set attempts to satisfy these demands while still providing utmost confidentiality of individual results. This package provides source needed to build some password-strength checking software. It is general enough that it can be useful for many other purposes also. -- \“The problem with television is that the people must sit and | `\keep their eyes glued on a screen: the average American family | _o__) hasn't time for it.” —_The New York Times_, 1939 | Ben Finney signature.asc Description: PGP signature
Re: SPAM
Christopher Clements writes: > On Sat, Mar 04, 2017 at 03:36:58PM +1100, Ben Finney wrote: > >I think the best explanation is that the entire message ??? complaint and > >quoted part ??? were composed and sent by the spammer themselves. > > Oh, the "original" message is seperate, I just replied to a reply. That doesn't contradict my explanation; I think both messages are composed by the spammer. That explanation could be wrong, but I'm convinced of it (tentatively) so far. -- \ “All television is educational television. The question is: | `\ what is it teaching?” —Nicholas Johnson | _o__) | Ben Finney
Re: Non-free RFCs in stretch
Sebastiaan Couwenberg writes: > On 03/04/2017 10:13 AM, Simon Josefsson wrote: > > I have searched for non-free licensed IETF RFCs in the archive and > > found the files below in the stretch suite. Compare earlier work > > here [1]. > > Instead of trying to get standards documents out of Debian There is AFAIK no motive to “get standards documents out of Debian”. Your characterisation, “trying to get standards documents out of Debian”, describes whose motives? Not Simon's, as best I can see. That seems needlessly antagonistic. Instead, the stated motive is to ensure all works in Debian are free. > I'd rather see effort invested in working on solutions to get Debian > able to include them. That is a laudable goal, but you present it misleadingly as though it were in opposition to Simon's. It is not: the documents can be in Debian if licensed under free-software terms to all recipients. So, to the extent that would allow such documents in Debian, yes I agree that is a solution in which it is worth investing effort. > I'd like to see a compromise in the DFSG like #4 for standards to > allow their inclusion in Debian when their license at least allows > modification when changing the name or namespace for schemas and the > like. Since that does not describe the license granted in these documents, I don't see why you raise it. On the contrary, I would like to see the license granted in these documents changed to conform to the DFSG, and then they can be included without violating or changing our social contract. -- \ “I still have my Christmas Tree. I looked at it today. Sure | `\ enough, I couldn't see any forests.” —Steven Wright | _o__) | Ben Finney
Re: SPAM
The Wanderer writes: > In this case, either it's faked up to look as if it's coming from the > person listed in the From: address but that person has actually never > seen the message before it reaches us, or it was faked up when being > sent _to_ that person (to appear as if it had come from the mailing > list) and we don't even have the headers of the actual original spam. That's my tentative conclusion also. There is a commonality to all these “don't send me this spam” messages, that essentially combine a plausible complaint top-posted on a quoted spam message. I think the best explanation is that the entire message – complaint and quoted part – were composed and sent by the spammer themselves. -- \ “The internet's completely over.… Anyway, all these computers | `\and digital gadgets are no good. They just fill your head with | _o__) numbers and that can't be good for you.” —Prince, 2010-07-05 | Ben Finney
Re: Personal Git repositories on Alioth
Ben Finney writes: > Wouter Verhelst writes: > > > […] for future reference, this is ridiculously easy for anyone who's > > a Debian Developer or otherwise has an account on alioth […] > Thank you. I completely overlooked the section about personal Git repositories on the https://wiki.debian.org/Alioth/Git> page. I have now made it a little easier to find on that page. -- \ “Begin with false premises and you risk reaching false | `\ conclusions. Begin with falsified premises and you forfeit your | _o__) authority.” —Kathryn Schulz, 2015-10-19 | Ben Finney
Personal Git repositories on Alioth (was: manpages.debian.org has been modernized!)
Wouter Verhelst writes: > […] for future reference, this is ridiculously easy for anyone who's a > Debian Developer or otherwise has an account on alioth: > > ssh to git.debian.org, and run: > > mkdir -p public_git/repo.git > cd public_git/repo.git > git init --bare > > log out again; then, in your local repository, run: > > git remote add --mirror debian git.debian.org:public_git/repo.git > git push debian > > you're done. Thank you. Does the resulting repository automatically get published on Alioth, managed by ‘cgit’ at a ‘anonscm.debian.org’ URL? I'd like to be able to use the resulting URL in the “VCS-Git” field of the package. -- \ “The entertainment industry calls DRM "security" software, | `\ because it makes them secure from their customers.” —Cory | _o__) Doctorow, 2014-02-05 | Ben Finney
Re: The end of OpenStack packages in Debian?
Thomas Goirand writes: > All this to say that, unless someone wants to hire me for it (which > would be the best outcome, but I fear this wont happen), or if someone > steps in (this seems unlikely at this point), both the packaging-deb > and the faith of OpenStack packages in Debian are currently > compromised. Thanks for your work, Thomas, and yes I hope someone hires you and other skilled maintainers to continue OpenStack in Debian. Nadia Eghbal's work documenting the state of critical infrastructure https://medium.com/@nayafia/how-i-stumbled-upon-the-internet-s-biggest-blind-spot-b9aa23618c58#.str97fkhj> has led her to create a guide for seeking funding for crucial free-software infrastructure https://github.com/nayafia/lemonade-stand>. For those parties who are profiting from OpenStack, or any other free-software project, you need to read “Roads and Bridges” http://www.fordfoundation.org/library/reports-and-studies/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure> and *fund* the maintenance of this infrastructure. Stories like Thomas's should gavlanise you to put sustained funding in for the projects that provide your own lifeblood. Step up, join with others, and make this right. -- \ “Pray, v. To ask that the laws of the universe be annulled in | `\ behalf of a single petitioner confessedly unworthy.” —Ambrose | _o__) Bierce, _The Devil's Dictionary_, 1906 | Ben Finney
Re: changelog practice, unfinalised vs UNRELEASED vs ~version
Simon McVittie writes: > On Mon, 13 Feb 2017 at 09:42:32 +1100, Ben Finney wrote: > > I'm in agreement with Ian that the “write the documentation > > (including the changelog) along with the change it describes” > > workflow should have full support from our tools. > > Are you making the stronger assertion, as Ian seems to be, that this > workflow should be the *only* thing that has full support from our > tools? On that, I'm currently undecided. Thanks for distinguishing those two positions. -- \ “Writing a book is like washing an elephant: there no good | `\place to begin or end, and it's hard to keep track of what | _o__) you've already covered.” —anonymous | Ben Finney
Re: changelog practice, unfinalised vs UNRELEASED vs ~version
Russ Allbery writes: > I really want something that will pass Lintian completely but that > dput will refuse to upload, which is what UNRELEASED currently > accomplishes. Wookey writes: > 1. I really dislike dch's enthusiasm for putting in 'UNRELEASED'. It > gives me nothing I wanted, and just provides the opportunity to really > do a final, clean, tested, build, only to find on upload that it's > still marked 'UNRELASED', and I have to do the build, test, upload > step again - for big packages that is a huge pain and happens way too > often. Those two positions seem incompatible as described. Can the two of you discuss further what it would take to reconcile what each of you wants from the changelog-adjacent tools? -- \ “Often, the surest way to convey misinformation is to tell the | `\ strict truth.” —Mark Twain, _Following the Equator_ | _o__) | Ben Finney
Re: changelog practice, unfinalised vs UNRELEASED vs ~version
Simon McVittie writes: > I think you're the only person I've ever seen using unfinalized > changelog entries for Debian packages. I think the fact you don't know we're using this workflow isn't very informative :-) > Broadly, the two extremes of workflows for Debian packages' changelogs > maintained in git seem to be: > > * Write the changelog as you go along: each commit includes its own > Debian changelog entry. Yes. The Debian changelog is documentation, and describes a particular state of the package. When that state changes, it's a fine practice to immediately update the documentation describing the package. > This works fine if every commit is final and immutable and is sent > directly to the master VCS immediately, but works very poorly if you > are proposing commits for someone else to merge at a later date - I don't see how this complaint is any different from the need to merge, for example, changes to API documentation and test cases that accompany a functional change. > * Write the changelog later: each commit just has a commit message > in a normal git way, and its debian/changelog is out of date. For the record, I don't have anything against that workflow either. I disagree that it should be preferred. > I'm concerned that the first model is optimized for people who know > Debian as well as you do, and do not need pre-commit review because > they get everything right first time. That concern is, I'd think, addressed by realising changes are not immutable; a new change is merely an additional commit away. Resolving a conflict in documentation isn't especially onerous compared with the general resolution of conflicts in a collaborative code base. I'm in agreement with Ian that the “write the documentation (including the changelog) along with the change it describes” workflow should have full support from our tools. -- \ “We tend to scoff at the beliefs of the ancients. But we can't | `\scoff at them personally, to their faces, and this is what | _o__) annoys me.” —Jack Handey | Ben Finney
Re: ITP: golang-github-choueric-cmdmux -- Package cmdmux implements a command parser and router for terminal programme.
Konstantin Khomoutov writes: > On Tue, 7 Feb 2017 13:23:24 +0800 > Haishan Zhou wrote: > > > * Package name: golang-github-choueric-cmdmux > [...] > > * URL : https://github.com/choueric/cmdmux > > * License : GPL-3.0 > > Are you aware of the fact that usage of GPL is questionable *library* > Go code because a) most of Go programs are statically linked, and b) > this makes any Go code using a GPL-ed library required to use GPL as > well? That is an explicit intention of a copyleft license like the GNU GPL: to encourage programs to also be licensed under the same copyleft terms. I don't see why you say it is “questionable” to use the GNU GPL for the purpose for which it is designed. Please don't cast FUD on copyleft licenses, they are an important part of free software and therefore of Debian. > So, in the end, you're about to package a library which is currently > used by no packages external to it, and vasty more feature-complete > alternatives exist. Hence do we need it in the archive? This is a reasonable criticism. Haishan Zhou, is there a specific reason you want this particular library in Debian when there are apparently equivalent packages already? -- \“He who laughs last, thinks slowest.” —anonymous | `\ | _o__) | Ben Finney
Re: If you can't describe what the package is, you probably should not Intend To Package it.
Ben Finney writes: > Howdy all, My apologies for sending this to ‘debian-devel’. The problem is real and is worth discussing, but that message's tone was rather more angry than I wanted. > When I ask about some of these[0], […] That reference was to a footnote I forgot to include: I greatly appreciate that people are volunteering to package important works as dependencies for useful applications. I am not naming specific packages because don't want to draw attention to the volunteers, probably Debian Project newcomers, who should not feel they are the focus of this complaint; that's not the case. -- \ “The manager has personally passed all the water served here.” | `\ —hotel, Acapulco | _o__) | Ben Finney
If you can't describe what the package is, you probably should not Intend To Package it.
Howdy all, If your Intention To Package a work for Debian is not accompanied by an appropriate description of the package, I argue you do not yet know what the package is well enough to file that ITP. A lot of the recent Intent To Package reports for Node.js pacakge have come with *terrible* package descriptions. They are usually far too short, and they seem to be copied from the NPM metadata without explaining it for a Debian audience. When I ask about some of these[0], the responses in some cases reveal that the author of the ITP expected that no-one should be reading it, and certainly that the description was not important. Is someone teaching newcomers to just automatically file ITP bug reports, without writing a proper package description? If so, *please* stop doing that, it teaches unfriendly habits from the start and it makes the ITP almost useless. -- \ “In the Soviet Union, capitalism triumphed over communism. In | `\ [the USA], capitalism triumphed over democracy.” —Fran Lebowitz | _o__) | Ben Finney
Git hosting for code that provides Debian services (was: manpages.debian.org has been modernized!)
Ian Jackson writes: > For a debian.org service, I would like to be able to check out the > running version without interacting with a proprietary online service. I have been looking at the GitLab instance hosted at FOSS Community India's servers, https://git.fosscommunity.in/>. It's been working fine for a few months. Do the FOSS Community India people want us to make larger use of that GitLab instance for general Debian code bases? > Using github as well is up to you. I won't try to talk you out of it. > But I think for a service in the .debian.org namespace, bugs should be > reportable without interacting with a proprietary web service. I believe the GitLab running at the above URL is entirely free software. > So thank you for agreeing to work with a system you don't find > comfortable. You'll see that I have filed a bug against b.d.o > requesting the manpages.debian.org pseudopackage. I would agree that the Debian BTS is important to maintain as the primary bug reporting system for the Debian Project, in general. Even if other platforms offer their own separate BTS, we strongly direct people to the Debian BTS and it is important to have that as a first-class venue for discussing bug reports. -- \ “In the long run, the utility of all non-Free software | `\ approaches zero. All non-Free software is a dead end.” —Mark | _o__) Pilgrim, 2006 | Ben Finney
Bug#850782: ITP: python-curio -- library for concurrent I/O with coroutines
Package: wnpp Severity: wishlist Owner: Ben Finney * Package name: python-curio Version : 0.4 Upstream Author : David Beazley * URL : https://github.com/dabeaz/curio * License : BSD 3-clause Programming Lang: Python Description : library for concurrent I/O with coroutines Curio is a library for performing concurrent I/O and common system programming tasks such as launching subprocesses and farming work out to thread and process pools. It uses Python coroutines and the explicit async/await syntax introduced in Python 3.5. Its programming model is based on cooperative multitasking and existing programming abstractions such as threads, sockets, files, subprocesses, locks, and queues. You'll find it to be small and fast. -- \ “We tend to scoff at the beliefs of the ancients. But we can't | `\scoff at them personally, to their faces, and this is what | _o__) annoys me.” —Jack Handey | Ben Finney signature.asc Description: PGP signature
Re: Python 3.6 in stretch
Adam Borowski writes: > On Tue, Jan 10, 2017 at 05:35:34AM +1100, Ben Finney wrote: > > Andrey Rahmatullin writes: > > > > > On Sun, Jan 08, 2017 at 06:55:45PM +0100, Galbo Branbert wrote: > > > > Thanks for the info, didn't know that the transition freeze was > > > > actually the version freeze for minor versions of Python. > > > A minor version upgrade would be 3.5.3 -> 3.5.4. 3.5 -> 3.6 is a > > > lot of changes. > > > > Galbo is referring correctly to the minor version, as specified in > > https://www.python.org/dev/peps/pep-0440/> and Semantic Versioning > > http://semver.org/>. > > […] > > Not every project uses semver. We're not talking about “every project”. We are talking specifically about Python, where “minor version” has the meaning Gablo used. $ python3 Python 3.5.2+ (default, Dec 13 2016, 14:16:35) [GCC 6.2.1 20161124] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.version_info.major 3 >>> sys.version_info.minor 5 >>> sys.version_info.micro 2 So, the changes Andrey describes are not changes in the minor version. > In some, like Perl, Python, GNOME, when the first number changes you have > a different language/DE. Which Python calls the “major” version component. -- \“Telling pious lies to trusting children is a form of abuse, | `\plain and simple.” —Daniel Dennett, 2010-01-12 | _o__) | Ben Finney
Re: dput: Call for feedback: What should change? What should stay the same?
Barry Warsaw writes: > Unfortunately, the documentation you find on extending upload > permissions to DMs doesn't tell you that only dput-ng supports the dm > subcommand. Likewise, I'm having no luch finding comprehensive reference documentation for commands accepted by ‘dak’. Is there a bug report I've missed which addresses this? -- \ “I still have my Christmas Tree. I looked at it today. Sure | `\ enough, I couldn't see any forests.” —Steven Wright | _o__) | Ben Finney
Re: Python 3.6 in stretch
Andrey Rahmatullin writes: > On Sun, Jan 08, 2017 at 06:55:45PM +0100, Galbo Branbert wrote: > > Thanks for the info, didn't know that the transition freeze was actually > > the version freeze for minor versions of Python. > A minor version upgrade would be 3.5.3 -> 3.5.4. 3.5 -> 3.6 is a lot of > changes. Galbo is referring correctly to the minor version, as specified in https://www.python.org/dev/peps/pep-0440/> and Semantic Versioning http://semver.org/>. So, “3.5.3” → “3.5.4” is a change of patch version. “3.5” → “3.6” is a change of minor version. And “2” → “3” is a change of major version. -- \ “[I]t is impossible for anyone to begin to learn that which he | `\thinks he already knows.” —Epictetus, _Discourses_ | _o__) | Ben Finney
Re: wording: "reverse dependence" vs "depender"
Ben Finney writes: > The adjective “dependent” is IMO fine, so perhaps the noun phrase > “dependent package” is a good candidate. It's not the single word > you're looking for, but maybe it is unambiguous for the purpose? https://english.stackexchange.com/questions/366158/noun-for-thing-which-depends-on-foo> -- \ “The Initial Mystery that attends any journey is: how did the | `\ traveller reach his starting point in the first place?” —Louise | _o__) Bogan, _Journey Around My Room_ | Ben Finney
Re: Specification of FTP upload queue management commands
Emilio Pozuelo Monfort writes: > On 29/12/16 20:49, Ben Finney wrote: > > Where is the canonical specification of the commands accepted by > > ‘dak’? > > See gregor's link, or read the source: > > https://anonscm.debian.org/cgit/mirror/dak.git/tree/daklib/command.py This surprises me. To be clear: There is no published documentation for the remote command interface to ‘dak’? Not even on the level of ftp://ftp.upload.debian.org/pub/UploadQueue/README>? Is there an open bug report for ‘dak’ requesting a reference to what commands it accepts? > Whether it's dput's job to support dak commands or that belongs to a > different tool is up to you. But maybe you should support it just to > stop losing users to dput-ng :P What tool to ‘dak’ maintainers expect maintainers to use for communicating commands to ‘dak’? -- \ “I find the whole business of religion profoundly interesting. | `\ But it does mystify me that otherwise intelligent people take | _o__) it seriously.” —Douglas Adams | Ben Finney
Re: Bug#791828: dput-ng: Please make coinstallable with dput
On 08-Jul-2015, Tobias Frost wrote: > I'd love to use both dput and dput-ng without the need of installing > the version I'd use next.. As discussed briefly in the thread from 2016-12, my counter-proposal is that the two packages should ideally: * Be alternative implementations of the same set of features, so that any features that people actually use should be implemented in each. * Eventually converge so closely that they merge, and there is just one ‘dput’ that is the single obvious package to install. > Thanks for consdering! I look forward to working (gradually and carefully) with the ‘dput-ng’ maintainers to make this request redundant :-) -- \“You don't change the world by placidly finding your bliss — | `\you do it by focusing your discontent in productive ways.” | _o__) —Paul Z. Myers, 2011-08-31 | Ben Finney signature.asc Description: PGP signature
Re: wording: "reverse dependence" vs "depender"
Adam Borowski writes: > Oi you lot! Wassp!? > I wonder, would it be better if we switched to using the word > "depender" in place of "reverse dependency"? I don't know a simple term in English that carries that meaning. To me, “depender” feel like a neologism and does not make me confident the reader would know what is meant. I vote −1 to that term. The adjective “dependent” is IMO fine, so perhaps the noun phrase “dependent package” is a good candidate. It's not the single word you're looking for, but maybe it is unambiguous for the purpose? -- \ “I still have my Christmas Tree. I looked at it today. Sure | `\ enough, I couldn't see any forests.” —Steven Wright | _o__) | Ben Finney
Specification of FTP upload queue management commands
Afif Elghraoui writes: > Hi, Ben, Thanks for the feedback. One specific suggestion appears to already have a bug report; I'm redirecting this sub-thread there. > على الثلاثاء 27 كانون الأول 2016 20:31، كتب Ben Finney: > > The ‘dput-ng’ package is one alternative that is sometimes suggested > > when people hit the limits in ‘dput’. I am not a user of ‘dput-ng’ > > or other alternatives, so am also seeking feedback from people who > > have informed positions on choosing one over the other. > > I always have to use dput-ng in order to be able to use the dcut dm > […] command and grant DMs upload permissions. There is not ‘dm’ command is not mentioned at the upload queue Read Me document ftp://ftp.upload.debian.org/pub/UploadQueue/README>. As best I can tell, that document is the specification for queue manipulation commands. What am I missing? > So as far as I'm concerned, if the dput package had a dcut that supports > the dm subcommand, I'd be very happy. Where is the canonical specification of the commands accepted by ‘dak’? Should ‘dcut’ support only one of those specifications, or should it be attempting to support the ‘…/UploadQueue/README’ commands as well? -- \ “For myself, I am an optimist — it does not seem to be much use | `\ being anything else.” —Winston Churchill, 1954-11-09 | _o__) | Ben Finney
Re: dput: Call for feedback: What should change? What should stay the same? [and 1 more messages]
"Paul R. Tagliamonte" writes: > FWIW, I don't think any of the dput-ng hackers particularly mind if it > changes, changing API could just happen for both together, at the same > time. Or maybe just consolidate :) Much appreciated. Yes, one aspiration I eventually hope to achieve have is to resolve the fork by merging the desirable features of both back into ‘dput’, and discarding behaviour that we decide is no longer helpful. -- \ “Corporation, n. An ingenious device for obtaining individual | `\ profit without individual responsibility.” —Ambrose Bierce, | _o__) _The Devil's Dictionary_, 1906 | Ben Finney
Re: dput: Call for feedback: What should change? What should stay the same?
Russ Allbery writes: > I have never managed to work out how to use dcut […] in fewer than > five tries each time I've needed to use it. I'm not sure what it is > with that command, but I find it completely baffling to use correctly. This should be addressed by, at least, improving the ‘dcut(1)’ manual page so that it properly describes how to use the existing interface. I have reported bug#849687 for this. A broader discussion can be had on changing the ‘dcut’ interface; I leave that as an exercise for the future. Suggestions are welcome though. -- \ “In case of fire, do your utmost to alarm the porter.” —hotel, | `\Vienna | _o__) | Ben Finney
dput: Call for feedback: What should change? What should stay the same?
Howdy all, I recently donned the mantle of maintaining ‘dput’ and am carefully making improvements. I am conscious of the special need for backward compatibility so I am taking care to understand how the Debian developer community uses it today. So I'm now familiar enough, but still fresh enough, that feedback from people with different experiences is particularly valuable. What does ‘dput’ do that you think really should not be changed? What does ‘dput’ do that you wish it would stop doing? What do other tools do better than ‘dput’? Do you think that ‘dput’ should change to do those tasks the same way? The same questions can be asked of the ‘dcut’ program from the same package. The ‘dput-ng’ package is one alternative that is sometimes suggested when people hit the limits in ‘dput’. I am not a user of ‘dput-ng’ or other alternatives, so am also seeking feedback from people who have informed positions on choosing one over the other. Both newcomers and old hands are welcome to give responses on these questions. -- \“Good judgement comes from experience. Experience comes from | `\ bad judgement.” —Frederick P. Brooks | _o__) | Ben Finney
Re: Bug#820780: clarify syntax of ‘cancel’ command for queue control
On 27-Dec-2016, James Cowgill wrote: > On 26/12/16 21:36, Ben Finney wrote: > >> .commands file has invalid Commands line: cancel > >> ../pytest-django_2.9.1-2.1_amd64.changes > >> debsign: .commands file appears to be invalid. see: > >> ftp://ftp.upload.debian.org/pub/UploadQueue/README > >> for valid format > > > > is not very helpful, because the referenced document does not make > > that constraint plain. In fact, the “README” document does say: […] Except for the DELAYED queue (see below) filenames may not contain slashes (so that they're restricted to the queue directory). […] embedded in the paragraph explaining the syntax of commands. > On the archive side, arguments to 'cancel' must match this regex: […] > Forward slash is not in the regex, so paths are disallowed. Thanks. -- \ “Why, I'd horse-whip you if I had a horse.” —Groucho Marx | `\ | _o__) | Ben Finney signature.asc Description: PGP signature
Re: Bug#820780: clarify syntax of ‘cancel’ command for queue control
Control: retitle -1 clarify syntax of ‘cancel’ command for queue control Control: tags -1 + help On 12-Apr-2016, Neil Williams wrote: > >From the manpage: > >If you've uploaded packages with the --delayed option (uploaded to >DEFERRED queue), then use the cancel command with a .changes file. > >$ dcut cancel dput_0.9.4_i386.changes I notice that this example, and the description of the ‘cancel’ command at ftp://ftp.upload.debian.org/pub/UploadQueue/README>, only ever show a base filename (with no directory). > $ dcut cancel ../pytest-django_2.9.1-2.1_amd64.changes Whereas this command has a directory in the path (‘../’). That might be a salient difference. Is this constraint – the argument to ‘cancel’ *must* be a base filename only – imposed by the upload queue processor? If so, the response: > .commands file has invalid Commands line: cancel > ../pytest-django_2.9.1-2.1_amd64.changes > debsign: .commands file appears to be invalid. see: > ftp://ftp.upload.debian.org/pub/UploadQueue/README > for valid format is not very helpful, because the referenced document does not make that constraint plain. I'm casting this to ‘debian-devel’ for confirmation whether this is actually the problem. Can someone with knowledge of the upload queue processing clarify this? -- \ “Whatever a man prays for, he prays for a miracle. Every prayer | `\ reduces itself to this: “Great God, grant that twice two be not | _o__) four.”” —Ivan Turgenev | Ben Finney signature.asc Description: PGP signature
Re: which JavaScript dependencies really need a separate package?
Daniel Pocock writes: > - While looking through the list, I noticed that some of them (or at > least files with similar names) are also included within other web > packages. Those packages would be similarly buggy in Debian, if so. > What is the latest opinion on when JavaScript libs can be included in > a web application package? In addition to the FTP Master position statement discussed elsewhere in this thread, there is also the principle that separate works with their own separate release schedules should not be in a single Debian source package. -- \ “Are you pondering what I'm pondering?” “I think so, Brain, but | `\why would anyone want a depressed tongue?” —_Pinky and The | _o__) Brain_ | Ben Finney
Bug#842523: RFP: doconce -- lightweight documentation markup language
Package: wnpp Severity: wishlist Owner: Ben Finney * Package name: doconce Version : 1.3 Upstream Author : Hans Petter Langtangen * URL : https://hplgit.github.io/doconce/doc/web/index.html * License : BSD-3-clause Programming Lang: Python Description : lightweight documentation markup language DocOnce is a modestly tagged (Markdown-like) markup language targeting scientific reports, software documentation, books, blog posts, and slides involving much math and code in the text. . From DocOnce source you can generate LaTeX, Sphinx, HTML, IPython notebooks, Markdown, MediaWiki, and other formats. This means that you get the most up-to-date publishing technologies for paper, tablets, and phones. -- \ 己所不欲、勿施于人。 (What is undesirable to you, | `\ do not do to others.) | _o__)—孔夫子 Confucius (551 BCE – 479 BCE) | Ben Finney signature.asc Description: PGP signature
dput 0.11.0~3: Call for testers: replacing ‘/usr/bin/gpg’ with GPGME
Howdy all, I have uploaded to ‘experimental’ a pre-release of the GnuPG changes in Dput. The version is dput “0.11.0~3”. If your packaging workflow has unusual signing practices, or an unusual GnuPG configuration, your help will be especially valuable to test this change. In particular I am seeking workflows and tests that: * Use signatures from keys that are now expired, or from keys that your GnuPG doesn't trust, or from keys that your GnuPG doesn't know. * Use signatures that are well-formed but fail to verify, or that are good but very old, or that are from the future. * Use non-default hash algorithms, or non-default options that would otherwise affect the generated signature. * Use GnuPG version 1 on a system with GnuPG 2, or vice versa. * Use outdated versions of GPGME. * etc. I'm also hoping some people interested in back-porting ‘dput’ to older Debian releases can help test these changes on those systems. Please feel free to file bugs against ‘dput/0.11.0~3’ for regressions in GnuPG signature verification in unusual workflows. -- \ “It is difficult to get a man to understand something when his | `\ salary depends upon his not understanding it.” —Upton Sinclair, | _o__) 1935 | Ben Finney
Resilience of ‘debbugs’ against spam (was: "Dear Customer" spam in the BTS)
Don Armstrong writes: > Any developer who is interested in volunteering and/or helping can > e-mail ow...@bugs.debian.org, and I promise to try to train people and > get them set up. Shall do. > [And/or write additional tools to make things easier.] To what extent does ‘debbugs’, the instrallable package, have tools for dealing with spam? How much is even feasible to include in the package for the benefit of other ‘debbugs’ installations? -- \“A thing is not necessarily true because a man dies for it.” | `\—Oscar Wilde, _The Portrait of Mr. W. H._, 1889-07 | _o__) | Ben Finney
Re: jquery 3.x uploaded to unstable
Antonio Terceiro writes: > To those who care about jquery: I have just uploaded jquery 3.1.1-1 to > unstable. Thank you to everyone who worked to bring this important update to Debian! -- \ “Guaranteed to work throughout its useful life.” —packaging for | `\ clockwork toy, Hong Kong | _o__) | Ben Finney
Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)
Ondřej Surý writes: > Gentlemen (arguing over and over) and ladies (watching this thread), Can we not characterise entire genders inaccurately, please? Preferably, not at all, since it seems entirely irrelevant to the discussion. -- \ “To punish me for my contempt of authority, Fate has made me an | `\ authority myself.” —Albert Einstein, 1930-09-18 | _o__) | Ben Finney
Re: dput: Call for testers: replacing ‘/usr/bin/gpg’ with GPGME
Ben Finney writes: > I am preparing a new version of ‘dput’ that stops using ‘/usr/bin/gpg’, > and instead uses the GPGME library for GnuPG operations. > […] > If your packaging workflow has unusual signing practices, or an unusual > GnuPG configuration, your help will be especially valuable to test this > change. In particular I am seeking workflows and tests that: * Use signatures from keys that are now expired, or from keys that your GnuPG doesn't trust, or from keys that your GnuPG doesn't know. * Use signatures that are well-formed but fail to verify, or that are good but very old, or that are from the future. * Use non-default hash algorithms, or non-default options that would otherwise affect the generated signature. * Use GnuPG version 1 on a system with GnuPG 2, or vice versa. * Use outdated versions of GPGME. * etc. I'm also hoping some people interested in back-porting ‘dput’ to older Debian releases can help test these changes on those systems. Please contact me at to offer your packaging system to test this new release. -- \“Good judgement comes from experience. Experience comes from | `\ bad judgement.” —Frederick P. Brooks | _o__) | Ben Finney
dput: Call for testers: replacing ‘/usr/bin/gpg’ with GPGME
Howdy all, I am preparing a new version of ‘dput’ that stops using ‘/usr/bin/gpg’, and instead uses the GPGME library for GnuPG operations. Currently, as of ‘dput’ version 0.10, GnuPG operations are done by invoking the ‘/usr/bin/gpg’ command in a subprocess. This is fragile in several ways, not least that it depends on stream output from the command to determine the result of operations. I expect GPGME https://gnupg.org/related_software/gpgme/> will make it easier for ‘dput’ to support more systems. So I am preparing a version of ‘dput’ > 0.10 that will stop using a specific command path in a subprocess, and instead use the library API. Before the release I would like to have some testers try the program for regressions. If your packaging workflow has unusual signing practices, or an unusual GnuPG configuration, your help will be especially valuable to test this change. Please contact me at to offer your packaging system to test this new release. -- \“Sane people have an appropriate perspective on the relative | `\ importance of foodstuffs and human beings. Crazy people can't | _o__) tell the difference.” —Paul Z. Myers, 2010-04-18 | Ben Finney
