Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On Mon May 6, 2024 at 5:01 PM BST, Luca Boccassi wrote: > On Mon, 6 May 2024 at 16:51, Barak A. Pearlmutter > wrote: > > For whatever reason, a lot of people who process large data use > > /var/tmp/FOO/ as a place to store information that should not be > > backed up, but also should not just disappear. > > Then such people, assuming they actually exist, can configure their > custom systems accordingly upon reading the release notes before > upgrading, as they would do anyway if installing on CentOS or any > other major OS. Hence, not an issue either. They actually exist. I'm been one of them, I've worked with many of them, it's an incredibly common pattern in academic computing at least, and changing it in Debian should be a very carefully explored decision. You've pointed out that changing the behaviour from the default, in either direction, is trivial. The issue is not one of individual preference but of what is default. The long-established status quo is not to clean /var/tmp. There is serious risk here: to users data and correspondingly to Debian's reputation for stability, which many of us have worked hard to maintain for a very long time. If you think we need hard data to quantify this practice, then let's work on a plan for how to gather that going forward, rather than dismiss this outright because we haven't collected it. Else-thread, Russ begs people to stop doing this. I agree people shouldn't! We should also work on education and promotion of the alternatives. I'd like to hear some arguments *in favour* of making this change. Alignment with systemd-upstream, reduced package maintenance burden are two that I can think of, but perhaps I've missed more. These two, IMHO, are significantly outweighed by the risks. Please hold off making this change now and let this discussion continue. -- Please do not CC me for listmail. Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: Binary conflict between Midnight Commander and MinIO Client
On Sun Apr 21, 2024 at 5:37 PM BST, Marco d'Itri wrote: > Go for it, I think that there is no good solution for this case. > Everybody who cares then will manually create a mc -> mcli symlink. Indeed, they will: so I would suggest that the chosen binary name for minio-client should *not* be mcli, which doesn't appear to clash with anything in Debian already, but almost certainly clashes with something outside Debian (which might be packaged in the future), and has no currency upstream. I'd go with "minio-client" as the binary name, which also aligns with the binary package name (which as an end-user I always appreciate), is more discoverable, and very unlikely to clash with anything else. Then set up a /usr/libexec/mc as suggested else-thread, and end-users will either use that or set up their own shell alias. -- Please do not CC me for listmail. Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: Silent hijacking and stripping records from changelog
On Wed Apr 17, 2024 at 7:26 PM BST, Jonas Smedegaard wrote: > To be fair, I _was_ upset (not with Jonathan, but) earlier in this > thread, which makes it harder to err on the side of a mistake when I > write something that can be read as being sarcastic. I would be upset too if my packages were repeatedly hijacked. > Sorry, Jonathan, for being difficult to read here. No problem: Sorry for lapsing in assuming good faith on my part. WRT Haskell and the monorepo, I've just done a bit of digging to try and remind myself why it was necessary, and I've not found a satisfactory answer. Perhaps there isn't one! [1] says it's "easier to update them in bulk" which, in isolation, I personally don't think is sufficient for the trade-off. I've just noticed that you upload Pandoc, and it (thankfully) is in an individual repo. You don't build a library package, perhaps that's relevant. I haven't traced the history that results in there being a separate haskell-pandoc source package yet. [1] https://lists.debian.org/debian-haskell/2024/02/msg1.html [2] https://tracker.debian.org/pkg/haskell-hakyll -- Please do not CC me for listmail. Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: Silent hijacking and stripping records from changelog
On Wed Apr 17, 2024 at 10:39 AM BST, Jonas Smedegaard wrote: > (or did I misunderstand your point?) You misunderstood my point: I was actually supporting your position. You've read it entirely backwards. > Interesting: Can you elaborate on those examplary contributions of yours > which highlighted a need for maintaining all Haskell packages in same > git repo? My Haskell contributions (which I did not enumerate) are tangential to the use of a monorepo. But it strikes me as an odd choice for you to describe them as examplary. Paired with you seeming to file me on "the opposing side", your mail reads to me as unnecessarily snarky. -- Please do not CC me for listmail. Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: Silent hijacking and stripping records from changelog
On Mon Apr 8, 2024 at 9:21 PM BST, Jonas Smedegaard wrote: > What I am not open to is abandon the one-git-repo-per-source-package > packaging style that is commonly practiced in Debian. As I understand > it, only Haskell and Rust teams use giant-git-for-all-team-packages > style I've never interacted with any Rust packaging. For Haskell, I believe there are sound technical reasons for the monorepo. I have found that trying to contribute fixes to Haskell packages is difficult because it is so different from Debian convention. I think that's important, so a decision to use a monorepo should not be taken lightly. -- Please do not CC me for listmail. Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: finally end single-person maintainership
On Tue Apr 9, 2024 at 7:37 PM BST, Holger Levsen wrote: > - I love git. > - I very much dislike git-buildpackage, too much magic. I try to avoid it > where I can. > - I like salsa. (though I think for many new contributors this is rather > a barrier "why not use github" directly. Also salsa is Debian only, > which also is a barrier for some.) > - I love autopkgtests. > - I hardly every look at the autopkgs logs on salsaci, cause I find > them incomprehensible and the javascript "UX" makes me wanna chop wood. > - I also think disallowing single-person maintainership would be very unwise, > though I agree team maintenance in general is probably better than > single-person maintainership. Still disallowing single-person maintainership > doesnt make a team and motivation lost is often motivation lost forever. I agree with everything you say here! Wrt git-buildpackage, I'd like to add that personally, I respect the gbp authors and maintainers and it's a very useful tool to bring together some complex workflows and in particular successfully move a lot of people over from svn-buildpackage. I do however agree that there's too much magic. Some of that is inherited from the Debian-specific tooling it sits on top of: I also think there's too much magic and/or complexity in debuild and dpkg-buildpackage. -- Please do not CC me for listmail. Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: Debian openssh option review: considering splitting out GSS-API key exchange
On Tue Apr 2, 2024 at 12:30 PM BST, Marc Haber wrote: > Please don't drop the mechanism that saved my¹ unstable installations > from being vulnerable to the current xz-based attack. Just having to > dump an ALL: ALL into /etc/hosts.deny is vastly easier than having to > maintain a packet filter. For you and fellow greybeards, perhaps: I'd be surprised if many people younger than us have even heard of tcp wrappers. I don't think the muscle memory of a diminishing set of users is a strong argument, especially given it's a preference rather than a requirement, and alternatives do exist. -- Please do not CC me for listmail. Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: ITP: gtk-gnutella -- The Most Efficient Gnutella Client
On Wed Mar 13, 2024 at 6:52 PM GMT, Lucio Marinelli wrote: > gtk-gnutella is a server/client for the Gnutella peer-to-peer network. > It was previously included in Debian repository. > The source code is hosted in Github: > https://github.com/gtk-gnutella/gtk-gnutella > I already prepared the .deb package here: > https://sourceforge.net/projects/gtk-gnutella/files/gtk-gnutella/1.2.3/ I took a peek, out of curiosity. I was surprised not to find a orig.tar.gz / debian.tar.gz split; the package version scheme properly reflects a normal (non-native) package (1.2.3-1), but the source tarball has "./debian" in it; and indeed, it looks like you're managing the debian packaging in the upstream repo. It's advisable to keep the two separate. The debian/copyright file doesn't conform to spec[1], and doesn't describe the copyright of the debian files in particular. I couldn't easily answer the question: is your packaging based on the previous iteration of the debian package? Do the previous packagers hold copyright? [1] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ -- Please do not CC me for listmail. Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: Bug#1010746: ITP: docker-squash -- Squashing helps with organizing docker images in logical layers
Hi, Are you still working on a Debian package of docker-squash[1]? I would like it packaged as a dependency of Cekit[2], so if you have stopped working on it I can take over this ITP. Note that Docker/Moby API version 1.25 has introduced a new, experimental, similar feature "--squash" argument for builds; I don't know how well it works, whether it will stay in Docker longer term (and become not experimental) and for the time being Cekit doesn't use it. [1] https://bugs.debian.org/1010746 [2] https://bugs.debian.org/1055584 Thanks, -- Please do not CC me for listmail. Jonathan Dowland ✎j...@debian.org https://jmtd.net
Bug#1055584: ITP: cekit -- Container image creation tool
Package: wnpp Severity: wishlist Owner: Jonathan Dowland X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: cekit Version : 4.9.1 Upstream Contact: Jonathan Dowland * URL : https://cekit.io/ * License : MIT Programming Lang: Python Description : Container image creation tool CEKit is a container-source pre-processor with a strong focus on modularity and code re-use. Features include . • Container images declaratively described in YAML documents and Jinja templates • Container description decomposed into separate modules which may live in external repositories, with inter-module dependency resolution • Multiple build back-ends including Docker, Podman, Buildah • Integration/unit testing of container images (Behave/Cucumber) CEKit has been organically built over a period of about ten years to enable the production of containers for much of Red Hat's Middleware product portfolio. CEKit is nowadays an independent community project with users and contributors beyond Red Hat. I intend to maintain CEKit (and necessary transitive dependencies) within Debian, in the Debian Salsa project (formerly collab-maint) and I am a supporter of low-threshold NMUs. Contributions welcome! -- Please do not CC me for listmail. Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: Bug#1050348: ITP: melonds -- nintendo DS emulator
On Wed, Aug 23, 2023 at 03:07:15PM +, Mae Miller wrote: I'm going to be packaging this as my first package partially because it's a program I use and care about and partially in order to learn how the system works and to make my first contribution to debian. Those are great reasons! Can melonDS be usefully used without a BIOS/firmware dump from a DS? -- Please do not CC me for listmail. Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: Issues in the Patch Tagging Guidelines
On Thu, Aug 10, 2023 at 03:42:03PM +0200, Lucas Nussbaum wrote: On 08/08/23 at 01:25 +0200, Guillem Jover wrote: - There is a requirement for the first field to appear on the first line, but git formatted patches start with «From ». That's OK, since From is an alternative to Author, so it's a valid DEP3 field. Is "From " an alternative to "Author:"? "From:" is, but Git patches are more mbox-like with "From " (space suffixed, not colon). DEP3 seems remarkably ambiguous on the syntax. (RFC 2822 seems fairly clear though, only colon delimits the header field name.) So I think that the next step would be for someone to start a draft to update DEP3. I might do it myself at some point, but would be very happy if someone else did it. +1 -- Please do not CC me for listmail. Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: Bug#1028467: ITP: borgbackup2 -- version 2.x of a deduplicating and compressing backup program
(setting CC according to X-Debbugs-CC, not sure if appropriate since posting via -devel, but well, I don't think we should have ITP's on -devel anyway.) On Wed, Jan 11, 2023 at 02:32:13PM +0100, Helmut Grohne wrote: The root of this ITP is #1019950. The crux of the matter is that borg 2.x is not very compatible with borg 1.x. I talked to upstream and as far as I understand things, the compatibility is quite limited: :( This is disappointing to learn, but given the situation, your plan seems to make sense to me! With one caveat * The idea is that borgbackup gains a "borg1" command and borgbackup2 is shipped as "borg2". The original name "borg" shall be managed using update-alternatives with "borg1" taking a preference in bookworm and changing that in trixie. I'm not sure that alternatives is appropriate, if the commands are not interchangeable. And they are not: if you have 1 & 2 installed on a host, and have used one to create some backups, trying to use the other could be disastrous, and mixing them up a very real possibility if either could concretely own "borg". IMHO, borg1 got that name and should keep it, and borg2 should exclusively use a different command name, even though that makes us significantly divergent from upstream. -- Please do not CC me for listmail. Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: Firmware - what are we going to do about it?
On Wed, Apr 20, 2022 at 09:07:47AM -0400, Polyna-Maude Racicot-Summerside wrote: When you talk or read a text out loud, you make pauses ? Why wouldn't they apply then you write a text ? Are we again in the world of "Everyone must adapt because I'm different" ? We ain't gonna go back to this WOKE thinking and "positive discrimination bullshit", please no ! Even IF it was your job to police other people's communication style on Debian lists, you are really throwing stones in glass houses. Please, refrain from complaining about someone's posting style ON LIST at least. -- Please do not CC me for listmail. Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: Firmware - what are we going to do about it?
Hi Steve, Thank you for raising this issue and writing about it so clearly. On Tue, Apr 19, 2022 at 01:27:46AM +0100, Steve McIntyre wrote: 5. We could split out the non-free firmware packages into a new non-free-firmware component in the archive, and allow a specific exception only to allow inclusion of those packages on our official media. We would then generate only one set of official media, including those non-free firmware packages. My preference is a variation on Option 5: Effectively, a two-phase version of it. I think we should produce installer media including the non-free firmware and for that to be the media that people are directed to, in the most part, via the normal routes (default path on website, etc.¹) However I think we should continue to produce install media without non-free components, at least for a period of time after making the switch (as another reply said, perhaps 1-2 releases and review). It feels like me too big a step to take to stop producing DFSG-compliant media. From simply a principle perspective, that's the "pure" aim of the project. If we continue to provide it but not on the default path then we might be able to gather some information on how popular or useful it is (how many downloads it attracts; or what kind of hardware configurations it can actually be used on; perhaps cross- referencing it with popcon or installation-report data) I'd also like to see us put a bit more effort into tools like vrms² so we can make it easier for folks to gauge how much non-free stuff they are relying upon and maybe even work towards offering tailored alternatives. (For example I've currently got an Nvidia GPU and the binary blob drivers installed, for the first time in over a decade, and I could do with some hand-holding to identify an alternative which would not require non-free drivers and/or firmware.) ¹ I agree with another person in this thread that the current behaviour of auto-downloading an ISO after visiting /download is wrong and should be changed, but, that is orthogonal to what you have raised and should be addressed separately. ² perhaps starting with renaming it… -- Please do not CC me for listmail. Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: Firmware - what are we going to do about it?
On Tue, Apr 19, 2022 at 01:43:39PM +0200, Christian Kastner wrote: In case my own wasn't clear, what I meant was: (a) all of the x86_64 hosts in our infrastructure use CPUs that utilize non-free microcode, and (b) unless we're crazy, those hosts also use the non-free intel-microcode or amd64-microcode packages to get security fixes. I hadn't even noticed that there was an amd64-microcode package. Although I see that it is older than my CPU (3945WX), so I'm not sure that it is (yet) a problem (for me). That said… Here's an even more radical thought: shipping any x86_64 installer CD without amd64-microcode and intel-microcode installed by default is a disservice to our users. There's no ideological "Win" when you're paying for it with the user's security, especially when they might be unaware of the problem. I can agree with that, but I think that's a bridge to cross *after* the change proposed by Steve. -- Please do not CC me for listmail. Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: warzone2100 video downloader
On Tue, Nov 23, 2021 at 08:36:04PM +1100, Russell Coker wrote: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862973 Regarding the above bug report, I don't think that cut-scene videos add much to the game play, and I'm certain it doesn't add enough to justify a gigabyte or more storage on the Debian mirrors. I think it would be OK to have a video downloader package or a downloader script in the main package but I don't plan to write it. A possible good home for something like this is "game-data-packager". -- Please do not CC me for listmail. Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: Future of /usr/bin/which in Debian?
Michael Stone wrote: I think it doesn't matter how many which implementations are in debian. If you want something with specific portable semantics, just use command -v. The remaining consumers of which are either programs that (ipso facto) don't care about semantic corner cases or are humans who want to use which just because, and probably have strong opinions on how it should behave (as, apparently, you do). *I* don't; in Clint's categorization¹ I fall into (d) "wants there to be exactly one version of `which` (except for all the shell builtins) so that alternatives won't confuse and complicate things". The point I've tried to make (too clumsily I guess) is the process of choosing one should not be shoot-from-the-hip: there should be some consideration as to which `which` would be the best fit for Debian. I hadn't seen any evidence of that, until, On Tue, Sep 21, 2021 at 05:41:49PM -0400, Nicholas D Steeves wrote: I also think it may be more reasonable to prefer (by default, using the alternatives mechanism) the more LSBish one (in this case GNU) rather than the potentially more simple, clean, and full-featured one (BSD). ^ this is an example of exactly what I would have hoped took place to decide upon which `which` we provided. Thankfully we have the /etc/alternatives and Provides mechanisms to affirm user choice in such cases, and I think most of us will agree this is a totally equitable and reasonable compromise :-) Unless there's a really compelling reason for there to be more than one `which`, we could avoid the burden of alternatives entirely. I should get off my soapbox now. ¹ Message-ID: -- Please do not CC me for listmail. Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: Future of /usr/bin/which in Debian?
On Mon, Sep 20, 2021 at 11:02:49AM -0400, Michael Stone wrote: It seems to install to /usr/bin/which.gnu, implying that you could upload /usr/bin/which.bsd if you so desire; what's the issue? I think we should have just one which implementation in the archive. We should (have) pick(ed) the best one for Debian. I believe (perhaps unfairly... I'd love to be proven wrong) that the GNU implementation was uploaded very quickly, without the BSD implementation being considered. Perhaps the GNU one is the best fit for our needs. It would have been nice to see that there was an evaluation. -- Please do not CC me for listmail. Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: Future of /usr/bin/which in Debian?
On Fri, Aug 20, 2021 at 11:03:50AM +0800, YunQiang Su wrote: For such a simple tool, do we really need such many versions? At least you've asked the question. I'd love to think that there was a proper evaluation of BSD which versus GNU which prior to the latter being uploaded to NEW, and there's a compelling reason that the GNU one was chosen; but if so there's no evidence of that on -devel. :( -- Please do not CC me for listmail. Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: git workflows (was: Steam Deck: good news for Linux gaming, bad news for Debian :()
On Thu, Aug 12, 2021 at 03:31:02PM -0700, Sean Whitton wrote: > For example, there are those of us who think that the downsides of the > combination of 3.0 (quilt) and patches stored unapplied in git are > significant, and so we have made attempts to provide alternatives, such > as git-debrebase. Contributing to Debian would be a lot less fun if we > were asked to just set these reasons aside and use something which to us > is clearly technically inferior. You can appreciate that the decision you took, in your interest, has the direct cost that Romain mentioned, right? Even if I agree with you about the technical merits of your approach, and I do, the consequence is an increasingly complex and non-uniform surface area for other contributors. The task would be mammoth, and the likelyhood of success not guaranteed, but I think in these circumstances implementing a technical improvement to a project-wide process would be the way to go. This pre-supposes that there *was* a project-wide process. There I agree with other posters on this thread: this is where to start. -- Please do not CC me for listmail. Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: Steam Deck: good news for Linux gaming, bad news for Debian :(
On Thu, Aug 12, 2021 at 04:42:51AM +, Paul Wise wrote: > On Thu, Aug 12, 2021 at 3:22 AM Timothy M Butterworth wrote: > > > Debian is missing KDE's Amarok music manager. > > Amarok was removed as it required the obsolete Qt 4 library. Now that > upstream has finally ported it to Qt5, it could be reintroduced to > Debian. That's an interesting way of presenting the situation. Amarok was removed because we aggressively removed Qt4, dropping packages that were still using it, rather than dropping it once it was no longer in use, which would be the more traditional approach. > > where people can create Repo's of newer software versions to > > use with stable Debian. > > We have backports for that, and there is the bikesheds idea. > > https://backports.debian.org/ Backports is not analogous to the concepts Timothy was presenting. It's *one* repository, not a system where people (not just Debian maintainers) can create repos. -- Please do not CC me for listmail. Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: filtering ITP in debian-devel (was: Reconsider sending ITP bugs to debian-devel: a new list?)
On Tue, Jun 15, 2021 at 01:05:57PM +0200, Thomas Goirand wrote: > I've read numerous people complaining about filtering. If I'm not > mistaking, the BTS adds this header: > > X-Debian-PR-Package: wnpp > > so filtering based on that seems to be a much nicer way than just using > the subject line. Is this correct? That will catch the initial ITP mail but none of the replies. -- Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: Reconsider sending ITP bugs to debian-devel: a new list?
On Tue, Jun 15, 2021 at 12:26:09AM -0400, Nicholas D Steeves wrote: > Honestly I thought that being able to cope with > large quantities of email--researching new solutions and implementing > them if necessary--was part of job description of doing Debian work, I don't like this kind of phrasing. It reads like "if you can't take the heat, stay out of the kitchen". Indeed working in Debian does mean coping with a lot of mail. I personally think this is a problem for attracting newer, perhaps younger contributors; I think it has been for a while and I think it will only get worse. Coping strategies for a lot of mail include using decent mail software (which I do); although I would like that not to be a barrier for entry; using mail filters (which I do; I've written elsewhere in this thread how that is not ideal for ITP mail to -devel); and targetting mailing lists: which is what I was proposing. As it happens the list I was proposing already exists; debian-wnpp. So my proposal becomes: we should send a digest mail from debian-wnpp to debian-devel instead of all initial ITP mails as we do today. > +1 It sends the wrong message if we have a bug in commonly used software > on the default desktop that is so severe that people discuss > accommodating this bug with infrastructure changes rather than fixing > the buggy software. For the avoidance of any doubt, I (thread originator) and not doing this: I don't use Evolution and haven't participated in the other thread. -- Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: Unique kernel with my own backup of all Debian repositories
On Mon, Jun 14, 2021 at 12:36:30PM -0400, Polyna-Maude Racicot-Summerside wrote: > I only repeated in a different way what was already explained (fair use > for servers not meant to be sucked up). My point was not about the technical content of your message, but the phrasing, that had started to assume an authoritative voice, which could be misleading. It's clear you want to get more involved in Debian, and that's great: have you read <https://www.debian.org/intro/help>? That lays out the best ways to get started. -- Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: Reconsider sending ITP bugs to debian-devel: a new list?
On Fri, Jun 11, 2021 at 11:05:02AM -0500, Gunnar Wolf wrote: > I concur with Steve. Often, I decide to ignore ITPs, or get annoyed or > overwhelmed when very prolific teams (hi nodejs!) announce and set to > package hundreds of packages I won't have any interest on. Yeah; I often ignore ITPs too. I did sometimes try to give time to them, and I might do again in the future. The rest of the time, I think they make the main purpose of the list harder; and that's the problem I'd like to fix. > But WNPP is problematic on its own: Right now, we have 1586 normal > priority open bugs, 4613 wishlist open bugs (what would the difference > be? It seems *most* normal are O and RFA, while ITPs, RFPs and such > are mostly wishlist... but it's not entirely consistent) between ITA, > ITP, O, RFA, RFH. Quite probably, many of them have just slipped of > anybody's sight and will never be acted upon. Yes, they document work > needed, but are barely visible for us if we don't explicitly go out > searching for them. > > We have 20 year old RFPs (#119911, even with nice bug numbers!), 17 > year old ITPs (#237925). And this is news to nobody. Those are serious problems yes, and the more general project of managing wnpp needs a lot more love. The majority of those problems get no regular exposure on -devel though, since they aren't brand new ITPs. You could make the argument that new ITPs get *too much* attention, relative to these other aspects of caring for wnpp. > I do, however, find value in getting notices when people file new > ITPs. It helps me know what people are up to, and makes me notice some > interesting new things to be on the outlook for. Me too! What I would like is to have better control over choosing when and how I do this, versus the current situation where it's entangled with any other use of -devel. In general I think I would prefer fewer mailing lists than more¹. But there are many other jobs/tasks/bits of Debian that could do with more exposure, and don't have the luxury of being auto-copied to -devel, ITP has a particularly privileged position here. I do agree with Steve's point though that practically it would likely result in few people interacting with ITPs than do now, and that would be unfortunate. It could possibly be ameliorated by a regular summary/digest email of to -devel. Quite literally nothing more sophisticated then a digest mail from a debian-itp list on a weekly frequency to -devel would, IMHO, greatly improve the readability of -devel. WDYT? I don't seem to have consensus amongst developers, so I won't persevere with the idea unless that changes. ¹ that was actually the driving force behind me trying to consume Debian lists via NNTP, so I could stop having to subscribe to so many lists; and also, have easier access to the archives prior to subscribing. -- Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: Reconsider sending ITP bugs to debian-devel: a new list?
On Fri, Jun 11, 2021 at 12:28:33PM +0200, Jonathan Carter wrote: > Wouldn't it just be far simpler for those who wish not to receive the > ITPs to filter them out to a subfolder of debian-devel or discard them? Others have covered the specifics of NNTP here; and at least one person has re-iterated my point that if many/most people are expected to, or choose to, filter ITPs, then the "sensible default" would be for them not to come to the list in the first place, but on the specific technical point of filtering: it's not simple to reliable filter all ITP traffic anyway. You can match on the subject, but you will miss any replies that change it. When I was doing this whatever I ended up with didn't reach 100% accuracy. -- Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: Unique kernel with my own backup of all Debian repositories
On Sat, Jun 12, 2021 at 04:47:26PM -0400, Polyna-Maude Racicot-Summerside wrote: > This is why your address is being blocked and will continue to do so. Writing something like this runs the risk of giving the impression that you are somehow involved in, or authoritative for, the official Debian mirrors. To avoid any doubt, it would be best in future to state clearly that you don't, and aren't; in fact it would be best to be clear that you aren't involved in developing Debian at all (unless that changes). -- Jonathan Dowland ✎j...@debian.org https://jmtd.net
Reconsider sending ITP bugs to debian-devel: a new list?
Hi, ITP bugs are copied to debian-devel@. The intention, I think, is to make sure that they have many eyes on them. ITP bugs often get feedback from readers of debian-devel. I think this is valuable. However, it's one job/task/role, and sometimes One wishes to focus on other jobs/tasks/roles instead. When I subscribed to debian-devel directly, I most often filtered ITP mail into a separate mailbox, to read at separate times. Nowadays, I read most Debian lists via NNTP gateways, and filtering ITPs is not quite so convenient (not least, because I don't easily have an analogue of the ITP-dedicated mailbox I used to.). But besides me, I think a better "default" for debian-devel would be not to have the ITPs. I think the ITP mails can make reading the rest of the list difficult without extra local filtering or steps. Some times they are the majority of the list traffic. I think it would be better if ITP mail went to a separate, dedicated list, e.g. "debian-itp" to which contributors are encouraged to subscribe and participate. Does anyone have any strong feelings about this, either for or against? Thanks -- Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: ARM architectures
On Sat, Jun 05, 2021 at 01:19:10PM -0400, Polyna-Maude Racicot-Summerside wrote: If you'd have took time to explain the real reason behind why choosing a RPi4 maybe a good idea versus simply saying they are better than other choices. Then I would have considered much more knowledgeable your opinions and fact based. He did: Marc wrote in his first reply to you that the issue with Siji Sunny's suggestions was their age. It wasn't an attack on Siji Sunny themself, although you seem to have interpreted it that way. This is a pattern I've seen in your interactions on debian-user@, too: a quickness to interpret messages as being hostile. Please, assume good faith from fellow participants in the Debian community. -- Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)
On Mon, Apr 19, 2021 at 11:30:48AM +0800, Benda Xu wrote: > The winning option "Debian will not issue a public statement on this > issue" implies that the majority of DDs is not interested in such > non-technical affairs. The vote in fact shows the opposite. That interpretation of the result would be true if the majority of people voted for that as their first preference. They did not: it was the most-agreed upon preference between two ideologically opposite factions. The majority of voting DDs expressed a strong preference one way or the other. -- Jonathan Dowland ✎ j...@dow.land https://jmtd.net
Re: a proper-unix meta package (Re: Proposal: plocate as standard for bookworm)
On Wed, Feb 10, 2021 at 12:21:36PM +, Holger Levsen wrote: > As it's 2021 and 99% of the Linux user base has no idea what UNIX (or Linux) > is, maybe it's time for a src:proper-unix-system package for those who care? I once considered packaging sed from v7 UNIX, which has all the coreutils bundled in one source repo, and so literally considered src:unix, although in both cases it was largely a joke and I didn't pursue it. Oh, that's still lying around somewhere: <https://github.com/jmtd/v7unix/tree/master/v7/debian> although not with src:unix. (And the credit getting sed to *build* as well as the initial packaging, goes to David Jones) -- ð±ð» Jonathan Dowland â j...@debian.org ðhttps://jmtd.net
Re: RFC: Final update of DEP-14 on naming of git packaging branches
Hi, Whilst I really welcome progress on this DEP, as I believe it's really important to codify best practice, and that's what you're trying to do :-), On Sat, Aug 29, 2020 at 01:01:09AM +0200, Raphael Hertzog wrote: > proposing the changes below to DEP-14. Basically it replaces debian/master > with debian/latest for all the reasons already discussed earlier. And > it says that debian/unstable is preferred over debian/sid. > > And it also marks the proposal as ACCEPTED given that it has gained > traction over the years and that we didn't feel the need to make > significant change to it. These two paragraphs seem to contradict each other. I would not object to the DEP moving to ACCEPTED if it was the case that it was effectively in-use, and no changes were necessary; but you are *are* changing the DEP, specifically, replacing debian/master with debian/latest. Clearly there's some debate as to whether debian/latest is appropriate. I don't think it's reasonable to consider that matter settled. So I would argue you should honour the DEP procedure and at most move it to CANDIDATE, but probably better stick with DRAFT — perhaps commit the debian/latest change and leave it in DRAFT status whilst we debate that point (since I believe there is consensus to move away from master, at least, so land that change now) Best wishes, -- Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: Mass bug filing: dependencies on GTK 2
On Wed, Apr 29, 2020 at 11:40:01AM +0200, Simon McVittie wrote: GTK 2 is used by some important productivity applications like GIMP, and has also historically been a popular UI toolkit for proprietary software that we can't change, so perhaps removing GTK 2 from Debian will never be feasible. However, it has definitely reached the point where a dependency on it is a bug - not a release-critical bug, and not a bug that can necessarily be fixed quickly, but a piece of technical debt that maintainers should be aware of. Thanks for expressing this so well! For folks interested in working with historical software, historical toolkits are vital. It was for this reason I am sad at the glee with which people removed Qt4 from the archive, and similar such things. But at the same time you are right that packaged F/OSS software really should migrate toolkits eventually. Or at least the vast majority of it should. -- Jonathan Dowland ✎ j...@dow.land https://jmtd.net
Re: RFC: Replacing vim-tiny with nano in essential packages
On Mon, Mar 16, 2020 at 12:50:01PM +0100, Tomas Pospisek wrote: I'd disagree. vi is very newbie unfriendly. OTOH I expect people that know how to navigate vi to be able to `apt install vi` without any problem. *t My initial feeling was similar, but we're talking about systems that only have minbase/priority Essential packages and nothing else. Newbies are not going to be using such systems. And if there's a choice between a not-small (~2MiB) friendly editor in the minimal images, OR a vi implementation, the latter is more important IMHO, and comes with the advantage of also being the smaller choice. One circumstance that non-newbies might be interacting with a minbase system includes odd environments where "apt install *" is not an option. -- Jonathan Dowland ✎ j...@dow.land https://jmtd.net
Re: New fast porterbox for powerpc and ppc64 available
On Mon, Jan 27, 2020 at 05:50:01PM +0100, John Paul Adrian Glaubitz wrote: Thanks to a very generous donation by IBM we have now a new porterbox for powerpc and ppc64 (big-endian) available [1]. Am I right in thinking you mean powerpc as in the 32 bit BE architecture dropped as an official port after jessie, re-activated as an unofficial one in 2018, suitable for use on "new world" Apple Macs e.g. some Mac Minis etc.? Great news if so, thanks! -- Jonathan Dowland
Re: Bug#949307: ITP: disk-filltest -- Simple Tool to Detect Bad Disks by Filling with Random Data
On Sun, Jan 19, 2020 at 06:30:01PM +0100, Sudip Mukherjee wrote: > The simple tool disk-filltest can help, together with S.M.A.R.T. monitoring, > to > check disks periodically and thus be forewarned about coming failures. The > function of disk-filltest is simple: > > * Write files random- to the current directory until the disk is full. How does this compare to f3read and f3write, from the "f3" package? -- Jonathan Dowland
Re: getting rid of "testing"
On Wed, Jun 26, 2019 at 09:15:49PM +0200, Alf Gaida wrote: Only a last thought: Didn't we have really important problems to solve? It might be only me, but i see the discussion as a minor variation of bike shedding. It may not be important to you, but it's evidently important to some people. I think bike shedding is a mischaracterisation of this discussion, because a) the problems that occur with the current arrangement have been clearly identified and are substantive, not trivial; b) the ratio of proposed alternatives to participants is not near 1:1. To sum it up: Some people like codenames, some not, same for numbers - the real question is: Does it really matters? This is a bad summary. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: getting rid of "testing"
On Wed, Jun 26, 2019 at 09:07:23PM +, Andrew M.A. Cater wrote: Think again about why we have release names at all: Debian 1.0 never happened because somebody packaged a pre-release semi-broken version as Debian 1.0 on their CDs. At that point, Debian chose to also use codenames to refer to releases in progress. Raspbian have released "Buster" before we have. Codenames have not prevented this happening. For me, I like the idea of being able to use the codename as soon as it is usable - that means that the distro tracks from unstable -> testing -> stable without a change. This would work with version numbers instead of code names. Pinning to stable is a silly idea in /etc/apt/sources.list - as soon as a release state changes - so if I have "stable" as my referent with 9.9, there'll be chaos as Buster is released and a forced upgrade This can be prevented by pinning to a version-number-name as well as code names. Having stable, testing, unstable as labels does mean I have to explain more to colleagues but it also means that I can confidently tell my colleagues: "Use the latest released stable Debian version if you want longer term support" They still have to resolve what that means, right? You don't want them putting "stable" in pinning etc. for the reason you list above. So, they still have to map stable → codename, and could just as easily map stable → version number. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: getting rid of "testing"
On Wed, Jun 26, 2019 at 04:50:39PM +0200, Andreas Tille wrote: Hi, On Wed, Jun 26, 2019 at 03:10:27PM +0200, Philip Hands wrote: I know +1 postings are not really welcome. I've been looking for an excuse to write slightly more than "+1" (to Simon or Phil's messages, in particular), but "+1" is substantively my main feeling However, in this case: I never really understood why we need these codenames. IMHO some marketing thingy which I tend to ignore. I fully agree with Phil that these can lead to confusion and the usage should be restricted to not so important use case. One thing that the code names give is colour. When I was (briefly) involved in debian-desktop stuff, the artists and suchlike enjoyed working on themes that riffed on the codename. I remember in particular being excited about what could be done with "Etch" and the swirl logo. So I would like to see the code names continue to exist, but I agree entirely that they should be reduced in importance and we should lead with the version number. We could consider bumping the version number up to match the current C.E. year, abbreviated (e.g. "19") in common with what Ubuntu do, if we wanted to increase the remember-or-computability of the current version. I do like how easy it is to look at an existing release number and be able to establish how old it is (aah, 18.04, was released in April 2018) -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Debian, so ugly and unwieldy!
On Fri, Jun 07, 2019 at 05:24:17PM +0200, Adam Borowski wrote: In general: could we please do something to appearance beyond choosing a wallpaper once a release? I fully support more effort on improving the usability, consistency etc. across the GUI stuff we provide. Timing-wise it's best done at a different point in the release cycle to now. In the past, this has been worked on via the debian-desktop@ list. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: @debian.org mail
On Mon, Jun 03, 2019 at 10:40:26AM +0200, Daniel Lange wrote: We (debian/DSA) do not provide email hosting. We provide email forwarding. DSA should re-evaluate that. I'm not sure I would want the existing DSA resource, spread as thin as it is, allocated to running a mail hosting service. At least there are other things I would prioritise above mail hosting. OTOH, I run my own email systems end-of-end, as I'm sure many DDs do; and I continue to do so partly out of inertia, I appreciate it's unrealistic to expect all DDs, and newer/younger members, to do the same. It may be worth, as a project, considering whether we would like something different to what we have now, and I guess that's exactly what this thread is. Best conducted at a project (requirements) level rather DSA (solutions) level. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Buster/XFCE unlock screen is blank
On Sat, Jun 01, 2019 at 09:20:48PM +0200, gregor herrmann wrote: I can't reproduce this in a quick test: Terminal 1: sleep 5 ; notify-send foo Terminal 2: xscreensaver-command -lock No "foo" notification pops up over the screensaver image. (This is with awesome, maybe the story is different for desktop environments.) I cannot reproduce it with gnome (1:3.30+1) running in an Xorg session (rather than Wayland). Perhaps it has been fixed. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: NMUs: Do we want to Require or Recommend DH
On Wed, May 15, 2019 at 03:22:16PM +0200, Andreas Tille wrote: On Wed, May 15, 2019 at 02:09:14PM +0200, Benjamin Drung wrote: Am Mittwoch, den 15.05.2019, 11:31 +0200 schrieb Enrico Zini: Or introduce a lintian check for not using dh. Then the maintainer could override lintian and document the reason for it in the override. ... but I think the documented lintian override is better since it is more connected to code than free text. I agree; also, the new lintian check/warning showing up in places like Tracker may help adoption of the documentation (as an override) to happen across the distribution more quickly. -- Jonathan Dowland
Re: Do we want to Require or Recommend DH
On Mon, May 13, 2019 at 05:58:47PM +0200, Thomas Goirand wrote: Why would one want to switch that one to something else? The package, basically, consists of a shell script and a man page only. The minimalism of this package doesn't require an over-engineered dh sequencer, does it? I maintain one of the simplest possible packages (in non-free), doom-wad-shareware, that is even simpler: it consists of three files total: /usr/share/doc/doom-wad-shareware/changelog.Debian.gz /usr/share/doc/doom-wad-shareware/copyright /usr/share/games/doom/doom1.wad For the source package, I thought "why do I need debhelper for such a simple package". And so I did things by hand instead¹, and I still screwed something up². This is clearly a stupid case of premature optimisation, yak shaving, etc.; I suspect many other instances of "why bother for such a simple package" in the archive have elements of these too. (An unrelated, but amusing mess-up in this trivial package: for the first 11 years, there was a version mismatch between what was actually in the .deb and what the version claimed) 1. https://sources.debian.org/src/doom-wad-shareware/1.9.fixed-2/debian/rules/ 2. https://tracker.debian.org/news/449441/accepted-doom-wad-shareware-19fixed-2-source-all/ -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Do we want to Require or Recommend DH
On Tue, May 14, 2019 at 02:27:30PM +0800, Paul Wise wrote: I think conversion to dh should only be done when doing hostile hijacking of packages, salvaging packages, adopting packages, orphaning packages or team/maintainer uploads and only if the person doing the conversion builds the package twice (with and without dh), inspects the resulting changes to the binary packages with diffoscope and is confident that each change is appropriate. Here you state your opinion but you haven't provided any rationale for it. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))
On Mon, Apr 08, 2019 at 11:18:14AM +, Mo Zhou wrote: The proposed idea is source-only-based, and is totally different from PPA (source+binary-based). I'm a PPA user and I don't have any reason to re-invent yet another PPA. Sorry I appreciate that *your* idea is different, and effectively my sub-thread is a hijack, but to be clear what I was referring to was the naming of the pre-existing "Bikeshed" proposal for Debian, which is equivalent to PPAs. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: is Wayland mature enough to be the default desktop choice in Buster?
Dear Simon On Sat, Apr 06, 2019 at 10:20:26PM +0100, Simon McVittie wrote: It's perhaps important to point out before this thread gets much further that Wayland is not like Xorg Apologies for not being clearer in my original message. Thank you for clearing that up. GNOME in buster has defaulted to Wayland mode since August 2017. The default could presumably be swapped back to X11, as we did for stretch, Apparently Ubuntu decided that it was not suitable (yet) as the default for 18.04, which was an LTS release, and still stuck with Xorg for 18.10. I don't know what criteria they used to make that decision, but I would imagine it should be very similar to ours. Especially for an LTS release. I also don't know what the status is for 19.04 which is presumably expected soon. but I'm not sure whether post-hard-freeze is necessarily an appropriate time to do that. The freeze is a tool we use to try and ensure a quality and orderly release. If we collectively agree that this change is necessary for the quality of our release, then I'd hope the release team would also agree that such a change was worthy of a freeze exception. But both of these hypotheticals are a few steps ahead of where we are now. If I understand correctly, the pattern that led to synaptic's removal is that it runs its full GUI as root, which isn't supported by the way many (all?) Wayland environments set up Xwayland. I think that's right. I appreciate that this is has been considered a bad approach to the problem for a long time, long before Wayland. I suspect, but have not confirmed, that it is not the only program that will fail to work properly in a Wayland environment. It's probably one of the more high profile programs to break in Debian, though. Another I'd like to verify is gparted. Would the GNOME team kindly share with this thread the criteria that you folks use to make your decision as to whether to default to Wayland in Debian? Best wishes -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: [Idea] Debian User Repository? (Not simply mimicing AUR)
On Sun, Apr 07, 2019 at 02:17:00PM +, Mo Zhou wrote: This single sentence is quite ambiguous to non-native english speakers. At the first glance I interpreted the sentence as "This will only lead to flamewars" due to the meaning of bikeshed[1]. However, I got a hint from a fellow developer and learned that "Bikeshed" has its own meaning under Debian's context, according to some old mailing list fragments[2][3] -- which refers to a dak feature (This is the first time I heard of such thing). This supports my (thus far) private feeling that naming this initiative "Bikeshed" is a bad idea. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
is Wayland/Weston mature enough to be the default desktop choice in Buster?
I was surprised to learn — by way of synaptic being autoremoved — that the default desktop in Buster will be GNOME/Wayland. I personally do not think that Wayland is a sensible choice for the default *yet*; and if the consequence is that bugs for software that do not work properly with Wayland have their severity inflated such that they are autoremoved (and thus potentially removed entirely from Buster), a decision that — in isolation — makes sense to me; although Synaptic is quite a high profile package within Debian for this to happen. I think the default should be reconsidered. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Bug#924270: O: keepassx -- Cross Platform Password Manager
On Sun, Mar 10, 2019 at 03:14:07PM -0400, Reinhard Tartler wrote: I am undecided whether or not this package should be included in Debian 10 (aka buster). It clearly is useful to many people, but its long-term maintenance is unclear. keepassxc is also going to be in Debian 10 (unless something happens to prevent it), so if the maintenance story is better there, I don't think there's a use-case for keepassx that is not fulfilled by keepassxc I'd lean towards dropping keepassx for Buster and possibly even using package metadata in keepassxc and compat symlinks for a smooth transition. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Bug#923300: ITP: golang-github-openshift-imagebuilder -- Builds Dockerfile using the Docker client
On Thu, Feb 28, 2019 at 05:53:37PM -0500, Reinhard Tartler wrote: Description : Builds Dockerfile using the Docker client The short-description could use some improvement. It doesn't build Dockerfiles presumably, but container images, using Dockerfiles as the input. This is a build dependency of the buildah tool. I would love to see that (and podman) packaged in Debian. Thanks for working towards this. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Salsa CI news
On Mon, Feb 25, 2019 at 11:19:35AM -0300, Inaki Malerba wrote: On behalf of the Salsa CI Team I'm pleased to announce some of the changes we've been working on this weekend. We don't have an official mailing list, so please excuse us if this is not the place for this kind of announcements. Thanks for sharing! Personally I think you could consider using debian-devel-annou...@lists.debian.org (but others may disagree)
Accepted wadc 3.0-1 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 18 Feb 2019 11:53:18 + Source: wadc Binary: wadc Architecture: source all Version: 3.0-1 Distribution: unstable Urgency: medium Maintainer: Jonathan Dowland Changed-By: Jonathan Dowland Description: wadc - programming environment for creating Doom maps Changes: wadc (3.0-1) unstable; urgency=medium . * New upstream release. * Recommend zdbsp instead of glbsp. * Update series file to apply 0002-docs-bsp.patch (oops) Checksums-Sha1: a03bacebd31595eb87c26431039862ce27f0db72 1849 wadc_3.0-1.dsc 95ebc0518a9cd8fb188c0dee4d27a38a52fad0dd 6271716 wadc_3.0.orig.tar.xz 5c18ead68d1b1082a0af4a169491d5e18201570f 4360 wadc_3.0-1.debian.tar.xz 958f911de9a5523917e45122c0c534e68393227c 572352 wadc_3.0-1_all.deb a78f08a0b57149d24e0a05eaac14db85838c 11421 wadc_3.0-1_amd64.buildinfo Checksums-Sha256: a19e1dcbea675883200960caf7106aad826e86745bf581da0c53579e13fd0ecb 1849 wadc_3.0-1.dsc 64eadaa0198f289ee9c6129ab72ff635434536723d2440191553f3a37801a2d9 6271716 wadc_3.0.orig.tar.xz d01af2a6bdfbabfddbb18518552ef345724f737f37317efd5df96e52f72fd7ad 4360 wadc_3.0-1.debian.tar.xz adf42231c768b15dca7d21b1a09ffe13cb8d05f080b7cd164e19a7a14af6ade6 572352 wadc_3.0-1_all.deb 1b4736951caf34701f50d5f9116c6ec1c794292a4eece0a7829e54f9e8ba1824 11421 wadc_3.0-1_amd64.buildinfo Files: 0a25965b75e1a837baca96133d6781f6 1849 utils optional wadc_3.0-1.dsc 09f6126368ced375e47de7ebe044ae5d 6271716 utils optional wadc_3.0.orig.tar.xz dc887810cabd96b615dcb8ffa89e6c79 4360 utils optional wadc_3.0-1.debian.tar.xz 168cf8654521cf7fd1a2b36ea0204f98 572352 utils optional wadc_3.0-1_all.deb 093bffec6dc7d4a9b14a31aebdc68060 11421 utils optional wadc_3.0-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJEBAEBCgAuFiEE4DfLKhoAYblDNjyLCQdAlgaqqqoFAlxubu8QHGptdGRAZGVi aWFuLm9yZwAKCRAJB0CWBiL4EACBIHNBeILtY4TpAp8sYvFfl+mLUUi04yNE L37gOBqol3vksZ6ooYNk5tSqa/+LZF08qZXk0cilC35aBlf21IgQbYvEW0erM+vE weS/9HuJyE2praTZ7u7JJOJjGy+HDyPNg19rNl9NGWgXVyGDxfybA0VFdVsUXkt+ VPxkXmd1OTLC8mVCOEtL4BQ8b49MKNrHPOo9Qa4xWA8t14by8jnp58QabVt/hXNk O5ER25Nz1sIyGkZ3xCtsTW26Pde6iuLUntNEMBRKLxb85+Rm9q5BeqXTJBf3y1x3 84ZGQYvV9U+CnyJ1BwH43ynmWo/6gR0CmyG2fNQWuqxe0Y1TBhaQsiv8ftYXLsT9 6Kh0Lcitrzd2GA9uO21Yq7zBxSF3zcuxz5fegw3Uz0iua31sdwpve31hMlgSZXFe VWwN0fOUm7oCnUwWG8ZU88X7ff3AepgppDih8SL0e1hW0ZBIDO3oVYviOueMnTmN rulqkcx/gDv2sjQhqYYhR6c/sHyzLRpatXExmhBk5Ut4k7vxdqNv1+VbF1BOagdI jwxTWvpFYumvg9M7Ef7qk8ImBOs7eO5EGWYyl/4PDvf3tedBkrOSdY8qXfOZhuUg 3NNUqRQpOvZsR+4scfwj5HIGK/qleXjsykWodIc6rBiIqPPasIV8ufRp5Qov7ClM UlzRB/6h6w== =VHEW -END PGP SIGNATURE-
Re: Recreating history of a package
On Wed, Feb 06, 2019 at 06:32:02PM +0100, Carsten Schoenert wrote: I know of at least git-buildpackage will do this with the option '--import-dscs' by importing all available versions from the Debian archives. I assume Ian's tool can do something similar. To be explicit, that's "dgit" https://packages.debian.org/sid/dgit -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: package management symlink
On Tue, Feb 05, 2019 at 07:20:23AM +0100, Sören Reinecke wrote: With your help I want to make package installing/removing equal on all linux systems without disturbing the diversity we have across linux distributions. In order to do that we need just a symlink, no replacement of existing software. You need to create a Debian package that contains your symlink (or bash script), and then either find someone to sponsor uploads of your package into Debian, or become a Debian Maintainer or Developer to do so yourself. You can start reading about this stuff here: https://www.debian.org/devel/join/newmaint You are probably out of time to do this in time for the next Debian release, because our freeze for that release begins at the end of this month. That's the *how*: a short sentence on whether you *should*: reading the page you provide, I don't think it's a good idea to actually do this. I'm not convinced that having to remember different package manager names is a significant problem for new people adopting a Linux distribution. The name is a very small part of the differences between the package managers (they have very different behaviour models, not just names), and the package managers are a small part of all the differences between distributions. That said, if you want to pursue this, the route above is how to do it. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: confused about virtual build-depends libcurl-dev
On Thu, Jan 17, 2019 at 09:29:58PM +0100, Thomas Koch wrote: Remarks: - https://www.debian.org/doc/debian-policy/ch-binary.html#virtual-packages links to virtual-package-names-list.yaml instead of .txt. That's not the bug, the bug is the yaml file not being present at the destination of the link[1]. Thanks for noticing; my email here is reporting it in the right place (MFT set accordingly) WWW team: the virtual-package-names-list file within the debian-policy source recently was converted from .txt to .yaml. There is a copy of the older .txt at [1], but no copy of the .yaml. Whatever process populates that path needs to please be updated. Thanks! Or alternatively: if linking to arbitrary files in [1] is to be deprecated we could change the link in the debian-policy document instead. [1] https://www.debian.org/doc/packaging-manuals/ -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: introduction of x-www-browser virtual package
On Fri, Jan 11, 2019 at 07:01:59PM +, Simon McVittie wrote: To facilitate that, I'd say the definition of that virtual package should include a desktop file with at least text/html, x-scheme-handler/http and x-scheme-handler/https in its MimeType list (I think that's what makes it eligible to be chosen as a per-user preferred web browser), and not just participation in the x-www-browser alternative. Yes that's a good idea. You may be interested in something else I'm (slowly) working on: I would like to encode such requirements of virtual packages. The first step was to rewrite the virtual package list in a structured format, which is now done. I hope to extend the schema to support things like "(should|must|etc) implement alternative /path". The next step would be to write things like lintian tests, UDD queries etc to use that information. And the step after that would be collecting other useful properties, such as these that you describe, that could be useful encoded. If the depending package is part of LXDE and is opening a URL, it could short-circuit the "what desktop are you?" logic and depend directly on something (anything) that implements freedesktop URL handling and has dependencies that would normally be installed by LXDE anyway. For example, if LXDE depends on GLib already, then libglib2.0-bin (for "Exec=gio open %u") would be uncontroversial. Yes. And that's a good specific suggestion for this case. I wasn't too concerned about dependency "bloat" (although the LXDE maintainers might be) so much as resolving the issue of ensuring a browser was installed. Unfortunately I don't think there's a way to express "open the preferred web browser to its default start page" as a URL to be opened. That's an interesting problem to look at. Yes, if you want to depend on "some arbitrary browser" then you need a virtual package. I wasn't making that decision myself, so much as following it through from the decision to put x-www-browser in the .desktop file. It's definitely a good idea to revisit that. However, I agree with Jeremy that "some arbitrary browser" is unlikely to be the UX anyone is actually looking for, and the browser that is preferred by the desktop environment's metapackage (which appears to be Firefox) would lead to more predictable behaviour. We're making an OS distribution here, not just a pile of packages, so it seems appropriate to make a choice, and back it up with some appropriate Recommends. If the LXDE maintainers simply specify firefox in the .desktop and Recommend on firefox-esr, it would be possible to install lxpanel without firefox (or, remove firefox later) and have a non-functioning icon on the toolbar, which is the situation I'm trying to fix now. The .desktop file currently specified Exec= but unfortunately, lxpanel displays an icon for the shortcut even if it is altered to TryExec= and the path is not satisfied. It reports "invalid desktop file lxde-x-www-browser.desktop", which could be improved. (Currently their browser dependency is in Suggests, I think bumping it to Recommends would be a small improvement) As an additional data-point, I'm not sure if lxpanel is maintained upstream any more. https://git.lxde.org/gitweb/ shows a repository for the Debian packaging (last modified nearly 2 years ago; and the version of lxpanel in sid is the same as in stretch) but no upstream repository, there is an lxqt-panel repository. I was under the impression the LXDE people were moving to LXQT, but I have no idea how far they've got on that transition (and whether Debian has caught up). The prospect of tweaking a package dependency to resolve this doesn't seem too bad; hacking on the program itself to alter it's behaviour around Exec=/TryExec= more awkward. For what it's worth, GNOME as packaged in Debian adjusts the default MIME type and URI scheme handler preference in /usr/share/applications/gnome-mimeapps.list to prefer firefox-esr or firefox over other browsers, and adds firefox-esr as a predefined "favourite app" in GNOME Shell using a GSettings override. In both cases, this can be overridden by user configuration. GNOME upstream would normally have used Epiphany (aka "Web", GNOME's own web browser), in both cases, but the Debian GNOME team has chosen to prefer Firefox because multi-year security support for WebKit-GTK+ and Epiphany is not feasible to do within the constraints of Debian stable release policies. That's a very sensible decision for GNOME-in-Debian. I think it would be wise of all the DEs in Debian (with possibly the notable exception of KDE) aligned accordingly. I'll take this to pkg-lxde-maintain...@alioth-lists.debian.net as the next step. Thanks, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: introduction of x-www-browser virtual package
On Wed, Jan 09, 2019 at 09:14:07AM +0900, Ansgar Burchardt wrote:
No, the alternatives system is not really useful for users (as only root
can choose an alternative). Having root choose a single
{editor,pager,browser,...} for all users is not a good solution.
Right now we have at least one package (one of the lxde* ones) shipping
a .desktop file that references x-www-browser but does not guarantee
that x-www-browser exists; this can be resolved via a virtual package.
I agree that it might be better if the .desktop file did not reference
x-www-browser (which is a system-wide preference) and instead used a
tool that respected a user-wide preference.
sensible-x-www-browser doesn't exist so we can't use that, and I'll
refrain from commenting on whether it's a good idea or not, for now.
If that package instead used xdg-open, it would need to depend upon
xdg-utils and whatever transitive dependencies that implied; and I'm
not sure the result would necessarily guarantee that a GUI web browser
was installed either, so the bug ultimately would not be fixed: we still
need a means to guarantee a GUI web browser is installed, and
x-www-browser is the only scheme I can think of right now.
Before I file the bugs to create the vpackage, I plan to perform one
further investigation: if the .desktop file used TryExec instead of
Exec, would the LXDE panel display the corresponding button/icon if
the TryExec is not satisfied?
(the x-www-browser vpackage dependency would not proclude also modifying
the .desktop file to use xdg-open)
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.
introduction of x-www-browser virtual package
Hello, We don't seem to have an x-www-browser virtual package name, corresponding to the x-www-browser alternative name. Introducing one would fix bugs like #833268 (package ships .desktop file which references x-www-browser but does not correctly depend upon package(s) that implement the x-www-browser alternative name) I plan to propose introducing one accordingly, but I was surprised enough at its absence (I could have sworn we did have one) I wondered if it was deliberately removed. I thought I'd post here to see if anyone had any information first. Best wishes -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Accepted zdbsp 1.19+20181027+dfsg.1-2 (source amd64) into unstable, unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 18 Nov 2018 19:03:48 + Source: zdbsp Binary: zdbsp Architecture: source amd64 Version: 1.19+20181027+dfsg.1-2 Distribution: unstable Urgency: medium Maintainer: Jonathan Dowland Changed-By: Jonathan Dowland Description: zdbsp - node builder library for OpenGL-based Doom-style games Changes: zdbsp (1.19+20181027+dfsg.1-2) unstable; urgency=medium . * Refinements and corrections to debian/copyright * Fix URI in manpage * Add alternative for /usr/bin/bsp and Provides: doom-node-builder, to substitute for (e.g.) glbsp in doom map editors (e.g. wadc) Checksums-Sha1: 9fe9be3c9f070cbd075629776993238cd87a0fa8 1926 zdbsp_1.19+20181027+dfsg.1-2.dsc 3114c600b1ce1136cdf2aaf44101b2117d1f8d55 95888 zdbsp_1.19+20181027+dfsg.1.orig.tar.xz fc5673cd97fd4032f272b09666c0d2e83301f8d9 3316 zdbsp_1.19+20181027+dfsg.1-2.debian.tar.xz f24e3c089a98f80dd2aab6d2a7913dd02e19ba4c 362748 zdbsp-dbgsym_1.19+20181027+dfsg.1-2_amd64.deb b7d9f226fe393652aca0e092a76ab89417509efd 6804 zdbsp_1.19+20181027+dfsg.1-2_amd64.buildinfo ee5163e55f6edbfd7d227baa2571b9dbc1d21086 54220 zdbsp_1.19+20181027+dfsg.1-2_amd64.deb Checksums-Sha256: 24756afb8bb7e5f8d2b9e3824e28ac5c0a99a0a28d5dbc4119a2cfc9899fc4a7 1926 zdbsp_1.19+20181027+dfsg.1-2.dsc 027261dbef41ddbb5b954dbd3b5aa7f7a66f9bc47c0af3106f8a3f890f9aa748 95888 zdbsp_1.19+20181027+dfsg.1.orig.tar.xz 307c4c2c087253ffe24822a71b3df3783e382988344424763f9fe9ac87647817 3316 zdbsp_1.19+20181027+dfsg.1-2.debian.tar.xz a97fbb49c642fadbda0c81e57da5af583024166f22dcd27de4773b2d01b7b0d1 362748 zdbsp-dbgsym_1.19+20181027+dfsg.1-2_amd64.deb 37d4d035bc27c4b85d47cf9e96c1b397ef068cacc2fdebf8a6b528e1796ac992 6804 zdbsp_1.19+20181027+dfsg.1-2_amd64.buildinfo e5c99eb9fdde8dd102dac621e3979ab0479190ec6bdb1c90ae51b0b76c9728ab 54220 zdbsp_1.19+20181027+dfsg.1-2_amd64.deb Files: 99c3cb5089fbda24857e9d410f0e88e4 1926 utils optional zdbsp_1.19+20181027+dfsg.1-2.dsc 71f254f68f29b1248e7b976aaacec526 95888 utils optional zdbsp_1.19+20181027+dfsg.1.orig.tar.xz ca6440a97c504a20983ac5c526f3408d 3316 utils optional zdbsp_1.19+20181027+dfsg.1-2.debian.tar.xz 3bb889dc0a276aa7aec0e7c4bed0dd12 362748 debug optional zdbsp-dbgsym_1.19+20181027+dfsg.1-2_amd64.deb 0e0087577aab8fc9104d361152c25181 6804 utils optional zdbsp_1.19+20181027+dfsg.1-2_amd64.buildinfo a05f646e6bf4f1cdec069e5f05894c0e 54220 utils optional zdbsp_1.19+20181027+dfsg.1-2_amd64.deb -BEGIN PGP SIGNATURE- iQJEBAEBCAAuFiEE4DfLKhoAYblDNjyLCQdAlgaqqqoFAlv9lLgQHGptdGRAZGVi aWFuLm9yZwAKCRAJB0CWBmxMD/0WUrBN5x6WADVO+rTNjOuEJBJ+kpZN6Cmc /tl6XvHrCC/PJ1Ox8+gvVvV1b7BW70ZqFMaY0dMi0c9f6E+orO+/GBWNvJQwiCMb p0mOEoCrnSW6yZlMMD6Uqsf1+4ZZ1ihHsImzCSmoIUYozu5nfaISrd450BDvQ3EY zMT8jIv9CIqZnv6ECSV1HhIqHAGh3oSVXQ/3seqLk1Fr+Estr4yFviZG8g7+TgX2 mGcjsySMcHE9UVG7AZO5Ou4y6iRcLTCR345wW3U9SyutqWBjYi//ZjM98OFecFmc lOHAbLbi/X8hwymV7s0I1Mqd8Q1pJDi/O28lRRn2xY3TNgBZADDpBW6JzSulWr25 v0SjzpoHZlk7OVcGTpm/EEM9fk1NCd1gThHFNHAtrAr3fAZw8/nncDIdx4WbHpA7 K7S2GaKKaTOJLFYvWACBnWhvd9GFdPe7lSOTXxcctJPIvbgdBRnFvrkVndAx2sSj 9U87Yf+3ZDpzkj0oujcFx1yKJ65OSCpASGRZC0WM410AXZSgjpVzZUOxLJs1AMfH PeHTWk9J46Iu82esCaiSHBMTylGPS6+iFXAufZZoez/jdyU7PkEJ8CoeorjpHVbG SSN0zLs+RyzPnaVWwBVorkvvbKnLnEIujgux4C8aew3jHM0DUZFw/2+a0lkGqrm8 nuM0rmzUtw== =Kf1l -END PGP SIGNATURE-
Accepted trash-cli 0.17.1.14-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 24 Nov 2018 19:43:18 + Source: trash-cli Binary: trash-cli Architecture: source Version: 0.17.1.14-2 Distribution: unstable Urgency: medium Maintainer: Stefano Karapetsas Changed-By: Jonathan Dowland Description: trash-cli - command line trashcan utility Changes: trash-cli (0.17.1.14-2) unstable; urgency=medium . * Fix autopkgtest, broken by rename of restore-trash Checksums-Sha1: 4ed0964ba34313a89d91612471bb35800c3c011b 2030 trash-cli_0.17.1.14-2.dsc a22d20a8f226208f35d6d2571abc671ef8b009d0 3956 trash-cli_0.17.1.14-2.debian.tar.xz 445cf83cd6dd4b94b4c399bfa0d224390f6b4562 6147 trash-cli_0.17.1.14-2_source.buildinfo Checksums-Sha256: d9ae7b2aba4b1faab3c8bd182bf1954a84a1a2885892bc3ce62a2141d69df915 2030 trash-cli_0.17.1.14-2.dsc 1ab9e106c228f107ffe743271b600e5a60e5a9fb01f9dae1932d39b082a3e0b1 3956 trash-cli_0.17.1.14-2.debian.tar.xz c87e2680920f9b40ed36059f16a82c0b7f6f78b90ef15bad9059f93761c62a40 6147 trash-cli_0.17.1.14-2_source.buildinfo Files: 6195400fe0dfb62b8048f60e305602e5 2030 utils optional trash-cli_0.17.1.14-2.dsc 1ab3f83051202ff5792ebf86f9c9a022 3956 utils optional trash-cli_0.17.1.14-2.debian.tar.xz 705ff2dff2c92760514cb54a86e97fd2 6147 utils optional trash-cli_0.17.1.14-2_source.buildinfo -BEGIN PGP SIGNATURE- iQJEBAEBCAAuFiEE4DfLKhoAYblDNjyLCQdAlgaqqqoFAlv5qmkQHGptdGRAZGVi aWFuLm9yZwAKCRAJB0CWBgolD/9x/DS8U4l7iPEAeszqmhvxXsL+qHRHgHDK eozzsWdq64L5PfQqzM/vcYxfxuuZufJ0emBJ6FOhLUXHOMneopf3Cn2LUXVr4LNJ KZ2qtB9aV/qXU0BmWe40b56KWNDLnetUfSYkxZ7YBldB/Nu9yJRFseiANjKW1MP4 vQg1rQoYOgXOXPC934wH5fGcvU/W+b8zRUtVouooroTUTyd4BQUxOZwceZN8YaBC 8IGWuRts1hn+KcBDJq4uNj/xlcOAbTrrKwlULF4qRde0mzchAmInpUjlG3NfynF7 PjyyeZvVbLiyr86a71IsjX3WfitgKrP20chNJsxfV9n9apCEb/YGF/1mEQpYg8t+ aCOkhJxuBVXfMKMKtfqG8GPjPRAB8VoPmbOp9xe9iabCRoflL+w+m5DxovtHwHM/ 5epVmfUZqsccbyctwh7PNCgkkW0VCRsiDoCe07jXICQok4HZ3DiO94MQXdoNsWKb 9rwZK9tX9ZjJp+GFV/4tS47axVVztNFMEMmjnHlnROdKnFQCTBMpsYt0ZKLwdW0Z BdvpY6cygk/AtUrUuMZZf+P7Tlu8RwE9wS3QUPIIMQw3uKBNLEUpwR43YAgaeASq Ogv/ygAoaD/QOQ5wydaS21KwCLAkAki1I03rmYn1+JpZ1uLKUEoFDX6ZFiBD+tSv pwag1z8Oww== =ax4c -END PGP SIGNATURE-
Re: usrmerge -- plan B?
On Thu, Nov 22, 2018 at 12:54:45AM +0100, Svante Signell wrote: Unfortunately Simon writes too long mails. Who can even thake the time to read all these verbalism. Things could be written more condensed. Please, can somebody summarize his verbosity! Maybe he is a politcian? I don't think this is a constructive comment. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: usrmerge -- plan B?
On Wed, Nov 21, 2018 at 04:21:42PM -0500, Michael Stone wrote: How many long-running production systems do you think people have run usrmerge on? I'd guess close to zero, since there is no advantage whatsoever to doing so. I'd also expect those to be the systems most likely to have issues. Long-running production systems would presumably be running Stable. We need testing or unstable systems to try usrmerge. I don't think even reporting on the success of usrmerge on current-Stable¹ would be necessarily useful. My gut feeling is we should do this transition; and we should not target our next release but the one after. ¹ I can't remember our own code names any more. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: usrmerge -- plan B?
On Wed, Nov 21, 2018 at 11:31:40AM +, Jonathan Dowland wrote: I'll upgrade to 7.6 and see what happens. I've upgraded and /bin -> /usr/bin However I didn't correctly check this before so it might have already happened. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: usrmerge -- plan B?
On Wed, Nov 21, 2018 at 11:02:44AM +0100, Marc Haber wrote: Did RHEL do that from 7.x to 7.x+1 (where updates are supported)? Or from x.y to z.0 where ther recommended migration way is a reinstall? I don't know the answer to when or how this happens, but my local RHEL VM is on 7.5 and doesn't have a merged /usr. It was, however, running a much earlier version of 7.x originally. I can't remember which. I'll upgrade to 7.6 and see what happens. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Accepted wadc 2.2-3 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 19 Nov 2018 16:42:52 + Source: wadc Binary: wadc Architecture: source Version: 2.2-3 Distribution: unstable Urgency: medium Maintainer: Jonathan Dowland Changed-By: Jonathan Dowland Description: wadc - programming environment for creating Doom maps Changes: wadc (2.2-3) unstable; urgency=medium . * Switch the default bsp tool from /usr/bin/glbsp to /usr/bin/bsp * Switch to recommending a virtual package (bsp) that could be satisfied by more than just glbsp (but recommend a glbsp version that provides bsp) Checksums-Sha1: de68eac316c27e16be36a0e4e0c7d16280228ad2 1849 wadc_2.2-3.dsc 9d5df24608a8e785026bdca3b03acd3264988921 4372 wadc_2.2-3.debian.tar.xz 338671f2cf92fb09cf817169040a2b795d725925 11675 wadc_2.2-3_source.buildinfo Checksums-Sha256: b89f296cb547a6427a3ed56807bf9d6d183e7b02dc633e8417b0a10e0d5df1d3 1849 wadc_2.2-3.dsc 291cbdeb3b253428379b6c0e474be6209f5df97816db8c2b3c130fc69a52 4372 wadc_2.2-3.debian.tar.xz 340d39ed0567fad7ccf4a57bc07706820992f6984313266fa8b482931a01741e 11675 wadc_2.2-3_source.buildinfo Files: 2d4f3160705c67e65ea6f1fb653c62c1 1849 utils optional wadc_2.2-3.dsc 5e918193c1e84eca6f42a78f9fd67364 4372 utils optional wadc_2.2-3.debian.tar.xz b241404092412b2cc8fdb6910d737906 11675 utils optional wadc_2.2-3_source.buildinfo -BEGIN PGP SIGNATURE- iQJEBAEBCAAuFiEE4DfLKhoAYblDNjyLCQdAlgaqqqoFAlv0OvcQHGptdGRAZGVi aWFuLm9yZwAKCRAJB0CWBhFuEACZKI+0G9WoP7sF7Qc4v0Ma8ilSvZe52kK3 nXHazwOBiaYmDXdXkgPTSR8tj9h9d50wdW1bWVPchEnm5VjpFYI/iYjC7UWpZcEf uVpbGTJ8cDnd1f/FQRl7oMK7bF2AwKwR/F1j21nUv3At2i7x4KeAV8AyZfoSYtYT bDY3VH2Fwb2VQ0bKONAlFlGdrgqb3URITmv+2yNoXMdSZH0IAyGiW2WvN1YNcFo7 gDwN7pE7IXT5qEK+YXws9/JF2nm9JtzZr2EKQiLpSv4bsUpH3Gce/iM31oQZ4x7a nvMfw+s35fKDE1Pyq1qu6gnTofLw9wePPQvVBdYg08EDh7fpMgT1cGfEfSmO8Cm/ dAVtUfaXilKlAF7nn6SaoYgugLAPPUHVwLD/PmZbq0hKXkj9/SNHrsZQdvm18hNV FDwVFvBJ1OcdaKE7URAm/laP1EVpMC5oCR04VsGli3Y4O04Boe0pptnqm/ITtv7m NU+FgS9gdUdYugb7bxJM4hMO2sWzWF9teMgsDD/+EZgYlyBP/Xz9582u1AAsI5R0 tUkl6DP6r/MweWI5jXBcal+V/JnLklFV9TnKQciqa03GzqtFnXnEMA4wnvLZr7T5 L+d0nZGdIU3OGeHmDSS3KHS2tMqtGawUCi8rqMkoy2vuB7DdDjw3kZ1gVMTik5Tn qbI0J+xAAg== =+zLG -END PGP SIGNATURE-
Accepted glbsp 2.24-4 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 20 Nov 2018 16:41:41 + Source: glbsp Binary: libglbsp-dev libglbsp3 glbsp Architecture: source Version: 2.24-4 Distribution: unstable Urgency: medium Maintainer: Jonathan Dowland Changed-By: Jonathan Dowland Description: glbsp - nodes builder for Doom-style games; has support for OpenGL libglbsp-dev - node builder library for OpenGL-based Doom-style games (headers) libglbsp3 - node builder library for OpenGL-based Doom-style games Changes: glbsp (2.24-4) unstable; urgency=medium . * Provide doom-node-builder and alternative for /usr/bin/bsp, so glbsp can be interchanged with (e.g.) zdbsp by doom map editors (e.g. wadc) * Add Vcs-* headers Checksums-Sha1: 0d8d2b4e324d1e81a2e727fd034fba7c33d8d495 1888 glbsp_2.24-4.dsc a1c765842aebcb86f3ffa0eb3bb040ff5cf48e2f 4234 glbsp_2.24-4.diff.gz 7a19a90de1fc6c62def0443227e70794cb2cf66a 5596 glbsp_2.24-4_source.buildinfo Checksums-Sha256: eec616827191b5342ac8abd4bab17c5c8a6eeb53317caf7f8f97923b85ead682 1888 glbsp_2.24-4.dsc b67d0514b1e05cee4dbc812152e608a1ff3e7f3a403946cb75c09aed1b8fc17d 4234 glbsp_2.24-4.diff.gz 1bdba35c011f0d2561dea0908b933552a884e765348f6e10563dfc953a777e11 5596 glbsp_2.24-4_source.buildinfo Files: a05d065b1a50cdd4e19da6cd9239f745 1888 utils optional glbsp_2.24-4.dsc 33377a7afe779d050891fd811b4523aa 4234 utils optional glbsp_2.24-4.diff.gz 9505f3faa2ea0fb3d09b65c1bd184aee 5596 utils optional glbsp_2.24-4_source.buildinfo -BEGIN PGP SIGNATURE- iQJEBAEBCAAuFiEE4DfLKhoAYblDNjyLCQdAlgaqqqoFAlv0Oo0QHGptdGRAZGVi aWFuLm9yZwAKCRAJB0CWBnuwEADZC4WE38v6XlQLXNwMc8tqk1q7/NirFgEw iNwv2FfABqCpLTVmFL/zeau22yMg1XHPNMw+aYiOVBG4YpMGywWlAjsxYbjAqhpv ouAiELoEsMhTGUjDJ6Rw4Va8c2Eow+dyONcovVUHouQh5hyF2REMCUjadExhbue5 gNTBNBY4bdhAdo+nVlpQBDKZ6b6gG90uDAOX8yy2cGYOci2vpzJW+/xGCuKTjP7X 5DIFs/Q08ufCOnvub1uUhgkSUFUxjaUb6zKE2q66cKbqQcQstcmfiShqioPk+CI5 Cj6g6VI+LqF1lxZpzxyJ1oYvVSlKBA8Z0eVQrS0gWAl2hrX+Aq/b+QEGHkmwjU8u GqNRLLIrLf6G7Wx4Jqyf+MWi+xXZIb1gVjNgVN1X/0FX0WS+cQvH0maEhRHOBaqc o0xyq3CAQ4f7fq/ZqRl5FnF679IT14qQRyLTNP2TkkpBSMV1TGLC5n+8OaRHYWiQ NE9ad4keI7DvhQ6DzJcIWEXI/PWCny3bNRvBGi223zpoqjYxtzymJdWDdoTRRNrW UF/s4R1wdjMqzhV+zW2lnYXL5XPUehcxTqGIanN1HJObVqWr9nAjTFGZpMnfV3A+ 6WDiKjWlfIChTPWOmzHDdwTivKTwUUrWWzzvA0eKhSsDHdItY5MZfzAFlt4IhbKF /HzbVyMjBg== =z2r3 -END PGP SIGNATURE-
Re: Iptables on Sid
On Mon, Nov 19, 2018 at 01:11:36PM -0500, Chris Lamb wrote: Ian Jackson wrote: Please see this page about how to report a bug: Actually, I believe this to be already filed as: https://bugs.debian.org/914074 You're right to point out that an important prerequisite step, before filing a bug, is to check whether it has already been filed. And that's what the page Ian linked to says. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: git vs dfsg tarballs
On Mon, Nov 19, 2018 at 08:17:03PM +0100, Andreas Metzler wrote: the main reason for having +dfsg versions is that non-distributable stuff is removed. Distributing these files in a Debian hosted GIT repository would not be workable, would it? It was widely done on alioth (by pulling in upstream branches to git repos) and I imagine is common on Salsa, too. In practise we are not applying the DFSG to the content of the VCS, the wiki, or really much except the archive. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Opt-in to continue as DD/DM? (was: I resigned in 2004)
On Mon, Nov 12, 2018 at 09:43:20PM +0200, Lars Wirzenius wrote: I support automatically retiring DDs and DMs that don't repond to a ping, or don't upload, or don't vote, or otherwise show activity. Me too. I think "otherwise show activity" would need to be formally captured. I suggest the exact algorithm(s) used by <https://contributors.debian.org/>; any shortcomings there should be fixed there. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: salsa.debian.org: merge requests and such
On Fri, Nov 09, 2018 at 04:57:51PM +, Matthew Vernon wrote: That's what Vcs-Git et al are for, isn't it? I'm sorry I don't understand what you're saying. Right now, the only way that someone can indicate that a package is collaboratively maintained via the control file is to have their Vcs-Git pointing at salsa.../debian/*. (contrast this to the alioth arrangement, where the Maintainer: field was also set to indicate this) Therefore, the salsa "Debian" project is carrying a lot more meaning than any other salsa project, or other potential VCS URI. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Installer: 32 vs. 64 bit
On Fri, Nov 09, 2018 at 01:40:59PM +0100, Adam Borowski wrote: If his students were doing code archaeology or deep embedded, such areas require enough base skills that getting spooked by 32 vs 64 bits would be beyond them. Everyone starts somewhere, even code archaeologists. At my former School a Lecturer taught Operating Systems by getting the students to write kernel modules for MINIX on a VM (networking iirc). I'm sure the majority of those students would get horribly tied up in 32 vs 64 issues like this if they experienced them; despite that, they broadly succeeded in writing the kernel modules and passing the course. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: salsa.debian.org: merge requests and such
(Please do not CC me, I am subscribed to the list and have set MFT accordingly, or at least think I have.) On Fri, Nov 09, 2018 at 11:54:50AM +, Matthew Vernon wrote: Putting it under a personal namespace doesn't make it much less visible, and folk can still open MRs... Oh I beg to differ, there's a huge difference of visibility between the "main" Debian project, to which we are all members, and personal namespaces. Not least the lack of any implied rules of behaviour. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Installer: 32 vs. 64 bit
On Fri, Oct 26, 2018 at 10:41:32PM +0200, Adam Borowski wrote: Or an user error. In either case, I don't get what a 32-bit _x86_ virtual machine would be good for. Are you teaching some code archeology? Do you want to prepare 32-bit images for something deeply embedded? Neither sounds an activity fit for your students. I'm not sure we are necessarily the experts in what is a fit activity for this teacher's students. For anything else, you want an amd64 kernel, possibly running i386 or x32 code. IMHO there are a remarkably small number of situations where x32 would be a sensible suggestion. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: salsa.debian.org: merge requests and such
On Tue, Nov 06, 2018 at 08:06:38PM +0100, Andreas Metzler wrote: Could we document this a little bit better in the wiki? This is completely different than on alioth, where collab-maint was suggested for basically everything that did not need a mailinglist. <https://wiki.debian.org/Alioth/PackagingProject>. The rules were basically the same for collab-maint as they are for Salsa's Debian group, it even says so on that very page you linked: "Thanks to ACL, all Debian developers have write access on those repositories." Instead of retreating in horror, please consider that the sky did not fall and perhaps there are many advantages to this arrangement. But of course, the wiki docs can be improved, including by you :-) -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: salsa.debian.org: merge requests and such
On Tue, Nov 06, 2018 at 03:42:01PM +, Matthew Vernon wrote: Hm, I had not quite appreciated that was the expected behaviour. Ah well, I can move it :) Please re-consider whether this trade-off (other people pushing to master) is a small price to pay for the advantages to you and/or the project of your package sources in the Debian project (more eyes, bus factor…) -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Uncoordinated upload of the rustified librsvg
On Tue, Nov 06, 2018 at 12:37:30PM +, Jonathan Dowland wrote: On Tue, Nov 06, 2018 at 11:58:57AM +0100, John Paul Adrian Glaubitz wrote: Well, if it wasn't for me, we'd probably be shipping the 2.40-version of librsrv in Debian Buster and Firefox would be missing on a couple of release architectures.. But I guess the phrase "Thank you" doesn't exist in Debian anymore. Debian's Dictionary is in a weird order; "Thank You" is right next to the definition of "Entitlement" Sorry this wasn't a helpful message. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Uncoordinated upload of the rustified librsvg
On Tue, Nov 06, 2018 at 11:58:57AM +0100, John Paul Adrian Glaubitz wrote: Well, if it wasn't for me, we'd probably be shipping the 2.40-version of librsrv in Debian Buster and Firefox would be missing on a couple of release architectures.. But I guess the phrase "Thank you" doesn't exist in Debian anymore. Debian's Dictionary is in a weird order; "Thank You" is right next to the definition of "Entitlement" -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Uncoordinated upload of the rustified librsvg
On Sat, Nov 03, 2018 at 10:53:12PM +0100, John Paul Adrian Glaubitz wrote: With this mail, I would like to protest the uncoordinated upload of the rustified version of libsrvg to unstable. The maintainer of the package There's no point dancing around the person's identity if you're going to bring -devel into this. All it does it cost the rest of us a small amount of effort to bother looking it up. Instead I think it would be both more polite and more effective to name them directly, AND ensure to CC them on the mail discussing them. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Confusing our users - who is supporting LTS?
On Fri, Nov 02, 2018 at 09:15:32AM -0300, Antonio Terceiro wrote: It was said in this same thread that Freexian is already not the only company paying people to do LTS work. See Thanks, that's a good point because it brings up something that's important to distinguish. Freexian as a business seeks money from customers/investors specifically to work on Debian LTS. The other LTS contributors that Ben mentioned may not work for a company that specifically seeks funding for that purpose, but who fund LTS work because it's considered valuable to their goals. In the context of Wouter's objection, I think the former category of company is what's important. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Bug#912745: ITP: libregexp-wildcards-perl -- converts wildcard expressions to Perl regular expressions
On Sat, Nov 03, 2018 at 04:25:15PM +0100, Christoph Biedl wrote: s/joker/wildcard/ ? Not sure here. Seems in English "joker" is unusual to describe a wildcard, unlike other languages. If some native English speaker could comment? In English, in the context of a deck of cards, Joker and Wildcard describe the same thing. Although the use of the term wildcard in globs etc. likely derives from the use in decks of cards, it's so far removed now that the original meaning doesn't come to mind, and Joker seems out of place.
Re: Confusing our users - who is supporting LTS?
On Sat, Oct 27, 2018 at 09:41:43AM +0200, Wouter Verhelst wrote: On Fri, Oct 26, 2018 at 01:02:57PM -0300, Thadeu Lima de Souza Cascardo wrote: I meant that we would say that stable is supported by the security team. And instead of saying that Jessie was supported by the LTS team, we would say supported by Freexian. I would object to that, on the grounds that even though Freexian is currently the only company paying people to do LTS support, we should not encourage the idea that they have a monopoly on doing that. In my view, that is a situation we could address at the time that we had more than one company doing LTS work. Until that time, I don't think it's a problem. It's consistent with our listing of consultants, and addresses the problems of the official-ness-or-not of LTS that are why this thread started. If some other company decides that they are not happy with Freexian, then they are currently able to just start their own competing project and do things differently. This is a good thing. They would still be able to do so even if we were listing Freexian as being the only entity supporting LTS (which is a statement of current fact after all): I don't think the hypothetical competing company would be too bashful to ask us to update the website. And we could pre-empt the situation by making a clear statement as to the project's position on listing Freexian (essentially codifying what I'm writing here, somewhere) -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: no{thing} build profiles
On Fri, Oct 26, 2018 at 11:15:36AM -0400, Marvin Renich wrote: Sure. But that requires the admin to build a package and deal with version number issues related to that package. E.g. A Depends: B, then later, A Depends: B and A Breaks: B < someversion. The admin simply wants to not install B and not have to worry about it. equivs used in this way is simply a much less convenient workaround to an incorrect dependency. Those are effectively UI/UX issues in the equivs package. The current two-step approach, involving authoring or editing a template file, is an unnecessary burden. I've had "rewrite equivs" on my TODO list for so long, with a command "equivs" which takes one mandatory argument, the package name you want an equivalent for, and does all the rest (optional argument to vary the version from matching what would be the installation candidate version as default). I should get on and do it. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: no{thing} build profiles
On Fri, Oct 26, 2018 at 08:38:01AM -0400, The Wanderer wrote: I suppose, on consideration, that this boils down to me being a grumpy pedant about language - which isn't necessarily helpful in a discussion that's more related to technical merits It's useful. You're pointing out bugs in our policy, and helping to explain the perspective of outsiders looking at our policies and coming to different conclusions to the old-timers. It's valid, we just need to follow through in the right place (-policy or in a bug) and fix policy wording. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Confusing our users - who is supporting LTS?
My brief 2p - I hope we can improve the interaction and experience of LTS for the whole project: although I don't use (yet) or contribute (yet) to the LTS effort, I think it's a *great* idea and a real benefit to Debian in the world. I'm glad some friends are able to support themselves by working on Debian. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Mass bugfiling potential: bundled implementation of md5
On Thu, Oct 25, 2018 at 09:32:57AM +, Holger Levsen wrote: I dont think delaying fixes is a the best solution. Especially since that's prioritising backports (support: maintainer best-effort, as-is basis, use with care) over our main release (full support) -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: no{thing} build profiles
On Wed, Oct 24, 2018 at 03:40:12PM +, Ivan Shmakov wrote: What are the values of the crypt_use_gpgme setting in each case? Could it be that mutt and neomutt actually have different defaults (one using gpg(1) directly and the other using GPGME) here? I suspect so; but I'm not motivated to spend more time investigating. Someone more troubled than I by this should both do that & file the relevant bugs. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Accepted trash-cli 0.17.1.14-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 24 Oct 2018 15:17:07 +0100 Source: trash-cli Binary: trash-cli Architecture: source Version: 0.17.1.14-1 Distribution: unstable Urgency: medium Maintainer: Stefano Karapetsas Changed-By: Jonathan Dowland Description: trash-cli - command line trashcan utility Closes: 813706 843612 856814 911762 Changes: trash-cli (0.17.1.14-1) unstable; urgency=medium . [ Javi Merino ] * Update debian/watch to what the Debian wiki suggests . [ Jonathan Dowland ] * Add myself to uploaders. * New Upstream version. Closes: #856814. * restore-trash now called trash-restore. Closes: #813706. * remove manpage symlink for old name * Remove debian/patches/0001-Fix-should_output_info_for_multiple_files.patch superseded upstream. * Segfault fixed. Closes: #843612, #911762. * Fix Vcs URLs (again!) * Bump standards version: * Update priority (extra→optional) * Remove X-Python-Version (value not necessary) Checksums-Sha1: d58bdf69d789df424547b4db0dfbc00eba655321 2030 trash-cli_0.17.1.14-1.dsc 48bf5b78d3fdf362dbc66ebd80f021b95bb1ae65 69141 trash-cli_0.17.1.14.orig.tar.gz 13847b5c8e1ba39b16f4c472ffb2bceca767cca3 3904 trash-cli_0.17.1.14-1.debian.tar.xz 521a2233be78122835acfc74fb74a7712b533234 6281 trash-cli_0.17.1.14-1_amd64.buildinfo Checksums-Sha256: c30e049757e25b6c6ebfa713cf26207f434061f531f7ef5824bc053813a31bb8 2030 trash-cli_0.17.1.14-1.dsc 8fdd20e5e9c55ea4e24677e602a06a94a93f1155f9970c55b25dede5e037b974 69141 trash-cli_0.17.1.14.orig.tar.gz c7f5f55bdda764de71d2843b8e7d61d52c1ee2e330951bb0e85d819d361f1385 3904 trash-cli_0.17.1.14-1.debian.tar.xz 670b489a223629e133c634c630ff1bba2a7bcc12608ac47ceb75eb109e51e80b 6281 trash-cli_0.17.1.14-1_amd64.buildinfo Files: af7ea7cbd0985c82b71a8b2ec8b60036 2030 utils optional trash-cli_0.17.1.14-1.dsc 75ccadb291fdef88cd7175d609fc6409 69141 utils optional trash-cli_0.17.1.14.orig.tar.gz 29b8088abc6abeb1303a3750c99a7625 3904 utils optional trash-cli_0.17.1.14-1.debian.tar.xz a688a01c4da4e800d83824851dff8dc3 6281 utils optional trash-cli_0.17.1.14-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJEBAEBCAAuFiEE4DfLKhoAYblDNjyLCQdAlgaqqqoFAlvQhk4QHGptdGRAZGVi aWFuLm9yZwAKCRAJB0CWBjk5EAC2VsTubsq5ryONyYvMLKzX8dUrWuDbdNUz A5PcXI+9IWzaGgxdxPQdCwYntUPI7YXGa6d/ZRWOf8fB5HcEvaAFiKDphuJ4smZy 5hZSiOpPR3xLkEbs5/OKmJbxZU9uxYHvmBn9GZL9B6cOfEaAoQOnHZemxWyxV03I 5Y7Ik9s05TjmnFJUbg78OxwBGxLirLXWvdZ0hceLk91CwZKpRM7E9Cli1CBuA0qu DlKb1ZurucSC8eO/voh25sR2zafCsmmSPbrvSyhxLmXVeEMxl496nVCjOFGLmO7H /LTbWuPebui/IkbrG0kiuGyXTU2z1JzvPB2nhYSVpxgBMLdEgFo5965YuYaL5NdQ KB29kV9N8H91uLpKZWjC6H26UE3LDJfxo3XYNePpxLoRlm299ZucyQzsjKgxyJGP np25oaS9GvJvU8u8SIe9N0n1ePBe1FQzqchn30cbE6zeh8OWWguQivktyHwiq1fA eianzArjZz8rNR+2roAdP5XIKR1upG9cFo3jN/f5JoLIDA8jvlDc4UMrHHFq3HgK uer0poxC2XQvhjIKcpkQHS99LVejIFqdJ1H8gNL6LEFod3VHdanBJfc3lkhWaDJD KDAfPJfLk4ki1RNCoUmOw9loGrTZYPl3SpkawVvHHeITnz9mLNRO8t74szTGK6cd Dn/SrZ42xQ== =QzGb -END PGP SIGNATURE-
Re: no{thing} build profiles
On Wed, Oct 24, 2018 at 01:11:47PM +0200, Marco d'Itri wrote: sh: 1: gpg: not found This looks like a very clear error message to me. It's certainly clearer than the other one, but it's not good enough IMHO, we should have something that unambigously means "you need to install exactly this package to get this feature to work" -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: no{thing} build profiles
On Tue, Oct 23, 2018 at 11:45:26PM +0200, Marco d'Itri wrote: On Oct 23, Tollef Fog Heen wrote: Wouldn't it make more sense for mutt to just go «oh, no GPG installed, let's note that there are signatures here, but they can't be verified, since there's no GPG installed on the system» and let the user know that? No need to actually disable PGP support. Yes. Because this way the default configuration will be useful both before and after gnupg will have been installed. That is sort-of what is happening for neomutt (20171215+dfsg.1-1) at least, it reports sh: 1: gpg: not found There's room for improvement there. mutt (1.9.2-1) is worse Error: verification failed: Unsupported protocol both with the default configurations. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: no{thing} build profiles
On Tue, Oct 23, 2018 at 02:11:48PM +0200, Marco d'Itri wrote: PGP-signed mail is an highly advanced feature, so I do not think that it is unreasonable to expect from users who want to use it to also install gnupg. … No: it is also TOTALLY POINTLESS to even just automatically verify received emails because any result is meaningless unless the local user has manually configured local sources of trust. Which requires installing AND configuring gnupg, so again the user has to know about it. I have sympathy with that position, but in which case PGP should be disabled by default in the /etc/Muttrc files too. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: no{thing} build profiles
On Mon, Oct 22, 2018 at 11:32:21AM -0400, Marvin Renich wrote: This keeps getting repeated in this thread in spite of the fact that multiple people have stated that having libgpgme installed without gnupg is useful in a very reasonable scenario. The scenario you describe, where the utility of the libgpgme package is soley as a way of satisfying a package dependency, and nothing to do with the bytes contained within the package, is an interesing case. It has taken me a few attempts to actually understand that this utility was what you (and Ivan iirc) were referring to. But it's not the traditional understanding of the utility of a package, and I don't think it's a purpose that was being considered when the relevant sections of policy were written. Why are some maintainers so adamant about using Depends when Recommends is the correct dependency? Because we don't agree that it is! I'm going to use the neomutt → libgpgme → gnupg as an example, but this applies as well to any other case where someone has a legitimate use for installing one package without a dependency that would normally be found with that package. If libgpgme Depends: gnupg, then anyone who wishes to install libgpgme (or, in cases like this, a package that has a Depends: libgpgme) without gnupg must either use equivs to build a fake gnupg package or build a modified libgpgme package that does not depend on gnupg. Both of Depends and Recommends in this case have drawbacks. It's a matter of weighing them up and considering their likelyhoods on a case by case basis. In this case, the maintainer must weigh the experience of users who may install mutt without gnupg and get a compromised experience, and how likely they are to hit that, versus the likelyhood that a user would be significantly troubled by installing gnupg even if they don't intend to use it; and in the latter case, factor in that we do have a system for addressing that, equivs, as you point out. In the case of mutt, both are configured to have PGP enabled by default. With the default configuration, as soon as you read a PGP-signed mail, you will hit the behaviour that requires gnupg installed to function properly. Due to this, I don't think this functionality can be considered niché. Adam Borowski makes a compelling argument that it should be niché in another mail to this thread; but this should be reflected in the default configuration, IMHO, before any dependency strengths are altered. However, if libgpgme Recommends: gnupg, then gnupg will be installed whenever libgpgme is installed, _unless_ the admin specifically prevents its installation. By "specifically prevents its installation" you may be referring to a much older decision that the admin made to disable installing Recommends by default, possibly when they installed the OS. When the user runs mutt and the PGP functionality does not work, they may not necessarily relate that failure to their early policy decision, which might have been a long time ago. And that's a situation we want to avoid, especially for beginner users. N.B. the policy definition of Recommends: This declares a strong, but not absolute, dependency. The Recommends field should list packages that would be found together with this one in all but unusual installations. That definition fits the relationship between libgpgme and gnupg perfectly. It's vague definition with plenty of room for interpretation, on purpose, precisely so that a decision can be made factoring in all of the considerations outlined above on a case-by-case basis. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: tinysshd dependency on systemd
On Sun, Oct 21, 2018 at 09:57:45PM +, Ivan Shmakov wrote: I disagree; to the best of my knowledge, anyone can do the testing and suggest any fixes he or she deems necessary. As such, having an issue recorded in the BTS is preferable to not having it recorded, and having a (semi-correct) You win the prize for the most Orwellian spelling of "untested and broken" that I've seen today. (so far.) Whilst you wasted your time (and ours) on this side-show, the actual maintainer has actually fixed the dependency problem (a one line change in the control file) -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: no{thing} build profiles
On Sun, Oct 21, 2018 at 10:00:43PM +, Ivan Shmakov wrote: It can be argued that libgpgme11 does not “provide a significant amount of functionality” (7.2) without gnupg. It won't function at all without gnupg. However, and it seems to be a common practice in Debian, for a shared library package that ‘functionality’ can be understood first and foremost as /allowing the packages dependent on said shared library package to run correctly./ (The ubiquity of said practice is evident from how libmariadbclient18 does /not/ depend on MariaDB That's because a MariaDB client can be installed on a different machine to a MarieDB server. , or how libxt6 does /not/ depend on an X server package, and so on, and so forth.) Same idea: separation of client and server. The same is not true for libgpgme11. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Debian Buster release to partially drop non-systemd support
On Thu, Oct 18, 2018 at 09:09:38AM +0100, Jonathan Dowland wrote: Thanks for passing that along: I'm using it with Exim and haven't noticed this particular problem, but it's useful to know it could happen. Ah, because I have User=nobody, and so the systemd sub-process can't reap the privileged exim4 sub-process. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Debian Buster release to partially drop non-systemd support
On Thu, Oct 18, 2018 at 08:46:10AM +0200, Kamil Jońca wrote: But this not play well with exim4. See: https://lists.freedesktop.org/archives/systemd-devel/2018-September/041417.html (and thread as a whole) Thanks for passing that along: I'm using it with Exim and haven't noticed this particular problem, but it's useful to know it could happen. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Debian Buster release to partially drop non-systemd support
On Wed, Oct 17, 2018 at 08:33:47PM -0700, Russ Allbery wrote: MAILTO was the main thing that I remember missing in terms of pure functionality. This is not a complete substitute for all uses of MAILTO, but I found the following useful so I share it in case you weren't aware of it. Define a service specifically designed for sending status emails: status-email-user@.service: [Service] Type=oneshot ExecStart=-/usr/local/bin/systemd-email %i User=nobody Group=systemd-journal (I also switch on a little status LED I have with another ExecStart line) /usr/local/bin/systemd-email: systemctl status --full "$1" | mail -s "unit $1 failed" root Put an OnFailure= line in systemd units that you want to mail you if they go wrong [Unit] OnFailure=status-email-user@%n.service I think I probably got this from the Arch wiki and it suffers many of the problems you outlined in your follow-on paragraph (needing a separate unit, to the timer, an external shell script, etc.) Since I switched to this, I've made the scripts I run on timers much more verbose in the non-failure case, because I know I am not going to generate mail. And this has turned out to be a good habit, because I have a lot of useful information in my journal. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: You are not seriously considering dropping the support of sysVinit?!
On Wed, Oct 17, 2018 at 10:19:31AM +0200, Ansgar Burchardt wrote: So dropping sysvinit support will make you go away? That sounds like a positive effect to me, but for some reason you seem to try and use it as a threat? Please don't feed the trolls. I enjoy mail from you, and it's a shame when stuff leaks through my killfile via quotes in your (or other people's) mails. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Debian Buster release to partially drop non-systemd support
On Mon, Oct 15, 2018 at 04:03:45PM +0200, Ansgar Burchardt wrote: Please no. I don't think it would help Debian to have toxic people maintain packages. At least some of the people who were at least once involved in Devuan (I haven't kept on top) were once valued Debian contributors - e.g. Roger Leigh. But I appreciate that some very troublesome individuals are associated with it, and we wouldn't want to deal with them. I see it as a sign of our project's healthiness that we are concerned about such things and have processes to deal with it when it happens. (As an example, Devuan's infobot has fun facts like this one: "<+infobot> 'sth is poettering' means it acts invasive, possessive, destructive, and generally in an egocentric exacerbating negative way. ``this cancer is extremely poettering'' [...]") I agree that's reprehensible, reflects badly on their project, and I don't condone it. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
