Re: speeding up installs
Adam Borowski writes: > There are two massive recent improvements: > * eatmydata helps a lot, and eating a power-lossed install is not a loss We did an experiment at work about four years ago with using eatmydata inside a D-I run, and had to revert because we ran into no end of problems with zero-length files after the first system reboot, even though we did an explicit sync before reboot. This is potentially obsolete data (this was with Ubuntu 12.04, IIRC), but it's made me fairly cautious of eatmydata ever since. Also, I think your proposal is not to use LD_PRELOAD and other hacks but to instead have a native package installation mode that understands when to sync, and perhaps that wouldn't have the same behavior. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Bug#929834: Buster/XFCE unlock screen is blank
Yves-Alexis Perez writes: > Actually it seems to me that the bug is a bad interaction with light- > locker/lightdm locking system (which relies on vt switch) and the Intel > driver. It only seems to happens on this driver, and I think it's also > been reproduced just by doing vt-switches (but can't remember where it > was reported). Ah, good call. I was also seeing other problems with the Intel driver in combination with light-locker where the monitor resolution would be set to some incorrect value after restore from lock. This would come with kernel errors like: [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo underrun on pipe B [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun and then lots and lots of: [drm:intel_dp_start_link_train [i915]] *ERROR* Timed out waiting for DP idle patterns -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: @debian.org mail
Marco d'Itri writes: > On Jun 03, Russ Allbery wrote: >> A possibly useful compromise is to do what Marco suggested: publish SPF >> records for domains like lists.debian.org, where all the mail is coming >> from Debian infrastructure. That can easily be -all. And then at >> least we have the option of moving some of the most important official >> mail messages (password reset links and so forth) to a subdomain with >> -all SPF records, without affecting the flow of @debian.org mail. > I have never suggested using -all because we are discussing improving > deliverability issues and -all cannot do this. -all would stop some > forged emails, but we do not have forged email issues. Right, sorry, I should have been clearer that DKIM should be the top priority rather than worrying about SPF, since that will do the most to directly improve our sender reputation. The point that you raised was using subdomains, which I think is by far the easiest way to proceed. debian.org itself is a complicated problem, but we can do a lot for, say, lists.debian.org or bugs.debian.org by adding DKIM signing without tackling that problem. That said, it has been my anecdotal experience that adding restrictive DMARC or SPF policies does help with sender reputation somewhat, but I haven't tested this in any scientific way and it may be that I was confusing correlation with causation. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: @debian.org mail
Sam Hartman writes: >>>>>> "Daniel" == Daniel Lange writes: > Daniel> To do better, we should really offer SMTP submission/IMAP > Daniel> services for @debian.org as soon as possible and - after a > Daniel> grace period - publish a mx -all SPF record. > Actually publishing the SPF record seems fairly problematic. A possibly useful compromise is to do what Marco suggested: publish SPF records for domains like lists.debian.org, where all the mail is coming from Debian infrastructure. That can easily be -all. And then at least we have the option of moving some of the most important official mail messages (password reset links and so forth) to a subdomain with -all SPF records, without affecting the flow of @debian.org mail. (The same all applies to DKIM, of course, and DKIM is probably more generally useful these days. SPF is slowly dying in favor of DKIM most places.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Buster/XFCE unlock screen is blank
Jonathan Dowland writes: > 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. Ah, excellent. Thank you both! -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Realizing Good Ideas with Debian Money
"G. Branden Robinson" writes: > My two cents[4] is that DSA should make its purchasing and hardware > solicitation decisions with the architectural security issue fairly far > down the priority list. It saddens me to say that, but this new class > of exploits, what van Schaik et al. call "microarchitectural data > sampling" (MDS), is a playground for security researchers right now; a > big rock has been turned over and bugs are erupting from the soil in a > squamous frenzy. It will take months or years for the situation to > settle down. > To acquire hardware based on what is known today is to risk buyer's > remorse. Plan on inescapable remorse later; every chip vendor will let > us down until corporate managers learn to treat confidentiality and > integrity as feature rather than cost centers. (And count on them to > forget what they've learned after a few quarters pass without > embarassing headlines.) +1 to this. So far as I can tell, about the only thing that seems to correlate with being less likely to have side-channel attacks is less sophisticated scheduling pipelines and processor architecture (read: simpler, slower processors). And this area of security research is changing very rapidly. I would expect several more novel attacks to surface. Processors that don't have a bunch of non-free, unauditable bullshit as a proprietary control plane would obviously be better, but you'd be paying a prohibitive performance price (not to mention other issues). There just aren't any good options right now. Buy (or accept donations of) whatever makes sense for other reasons, and expect there to be mandatory microcode updates, kernel and virtualization workarounds, and security bugs. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Buster/XFCE unlock screen is blank
Georg Faerber writes: > On 19-06-01 11:04:28, Russ Allbery wrote: >> I did some research on that a while back and ended up not filing a bug >> about it because it looked relatively pointless. It appeared to be a >> deep design choice on both sides, and not something anyone was likely >> to solve, so I just switched to a desktop-aware locker. > If I may ask, which one? light-locker, hence why I know about the bug that started this thread. :) (I never filed it as a bug since I didn't mind the workaround. In retrospect, I should have.) Obviously given the discussion here I'm not sure I'd recommend that one. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Buster/XFCE unlock screen is blank
gregor herrmann writes: > 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.) Yeah, I think it may be DE-related. I ran into it with Xfce and, IIRC, GNOME (although it would have been older GNOME). -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Buster/XFCE unlock screen is blank
Adam Borowski writes: > But, the culprit is light-locker. In general, it's in such a buggy > state that I believe it shouldn't be in the distribution at all, much > less a default of any kind. After it replaced xscreensaver[1] as the > xfce's dependency, I went into some pretty heated arguments, but then > stormed off and ignored the issue. It's worth noting here that xscreensaver has an IMO serious security vulnerability (unless maybe this has been fixed?): because it doesn't integrate properly with the desktop, it doesn't hide desktop notifications. Desktop notifications will appear above the lock screen. If you therefore leave a locked computer in some relatively public place (such as an open plan office at work), you may be exposing things on your screen that you didn't expect, such as direct messages from some messaging system that's plugged into desktop notifications. I did some research on that a while back and ended up not filing a bug about it because it looked relatively pointless. It appeared to be a deep design choice on both sides, and not something anyone was likely to solve, so I just switched to a desktop-aware locker. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Buster/XFCE unlock screen is blank
(This probably belonged on debian-user, but since I have background on this specific problem and already did the research.) Raj Kiran Grandhi writes: > In a fresh install of Buster with XFCE desktop, locking the screen > blanks the monitor and the monitor enters a power save state. After > that, neither moving the mouse nor typing on the keyboard would turn > the monitor back on. Ctrl-Alt-F7 will also restore the desktop (which I think is just another version of your solution 2 of switching VTs). This appears to be a bug in light-locker specifically, which is the default screen lock program with XFCE with lightdm. See, for instance: https://github.com/the-cavalry/light-locker/issues/114 Switching to another greeter from the default gtk-greeter appears to help according to that bug, which may mean that the bug is actually in lightdm-gtk-greeter. There doesn't appear to be a Debian bug for this; it might be a good idea to open one against light-locker (or, if you confirm switching to slick-greeter per that bug, lightdm-gtk-greeter). -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Consensus Call: Do We Want to Require or Recommend DH; comments by 2019-06-16
Jonas Meurer writes: > Depending on the software you packages, doing the initial packaging > already requires a lot of knowledge about library handling, doc build > systems, makefiles, the filesystem hierarchy standard, language-specific > toolchains, etc. > To properly build the package you have to learn either sbuild or > pbuilder. Which involves understanding and creating chroots/VMs/... > For proper version controlling, things like git-buildpackage (and/or > dgit) and the "3.0 (quilt)" format need to be understood. > And for testing, you need to learn about piuparts, autopkgtest, as well > as again chroots and/or containers for local testing. > That's a very high bar for entering the world of Debian packaging. I completely agree. How can we fix this? I've written some documentation of my personal approaches, but I think documentation, even with step-by-step instructions, may not be the best way to cut through all that complexity. When I look at other ecosystems, there often is less diversity than we have in Debian (newer languages like Rust or Go, for instance, have converged strongly on a single choice of build system), but perhaps even more helpfully they've automated a lot of that flow or at least wrapped it into single tools. Debian rightfully values its diversity, and while I think pushing us to think about whether that diversity is still serving a purpose is valuable, I am sure we don't want to give it up entirely. But I think there's a missing gap here for a very opinionated combination of a tool and a document that says "here is one coherent way to package things for Debian; you don't have to do things this way at all, but if you don't have opinions about all this stuff, use this." I don't think we have that right now. By this, I mean way more than just the packaging. Imagine a world where you apt-get install decisive (name made up) and then run decisive setup and it sets up an sbuild environment for you, and then run decisive init on an upstream directory and it builds a packaging template using dh and 3.0 (quilt) and autogenerates your copyright file using licensecheck. Running decisive format runs cme fix, running decisive lint runs lintian and cme check, running decisive check runs puiparts for you, and autopkgtest, and whatever else we can come up with. Running decisive upload runs dgit push for you. And so forth. We have some of those pieces already, of course, and writing this sort of tool is a little fraught for all the tools upstream of them since they'll get an influx of user bugs from people who don't really understand how the tool works because they're not using it directly. So this isn't without cost. But I don't think we've ever assembled the *entire* packaging workflow into a tool like this that has strong opinions and a mandate to *not* allow every possible variation and instead just focus on being a very simple and easy-to-understand workflow for the 80% case. (Obviously we'd want to try to design it so that it's relatively easy to use selectively as someone gets better at packaging and makes some alternate choices.) To be clear, I personally don't have time to work on this. But I think it would fill a valuable niche in our ecosystem, particularly if accompanied by a supporting document that lays out *why* those tools were chosen and provides a few pointers to alternatives for someone who starts getting curious about other ways to do things. I've seen this kind of approach be successful elsewhere; the idea is to make common things easy while getting out of your way if you need to do something uncommon and complicated. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Difficult Packaging Practices
Sam Hartman writes: > I think it's a combination of a lot of things. We have high standards, > a lot of complexity, and you have to get most or all of that right to > contribute. You have to have a package that meets our standards. You > have to have a copyright file that meets our standards. You have to be > able to figure out our processes. You have to be willing to follow our > processes. And you eventually have to deal with the PGP mess. > If you don't find value in the things where we have high standards, > Debian doesn't make a lot of sense. If you just want to get upstream's > idea of their package onto a system with their release schedule and > their recommended dependency versions, there are better ways than > getting a package into Debian. This is my experience as well. I've occasionally tried to get people at work (at various jobs) interested in packaging software for Debian, without all that much success. The problem seems less any one specific thing and more that they're perfectly content with a Debian package created by running fpm on some install tree, and don't see the point in doing any more work than that. This is usually in the context where there's some other config management system in use, so to them all the packaging format is good for is as a container of files with a version number attached. It's not that they don't understand the merits of having what they think of as the base operating system properly maintained and integrated; it's more that they don't see any value in doing that work for the incremental thing that they're adding. They cobble together some combination of local config management and a deployment method until it works and then move on to some (from their perspective) more interesting problem. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Preferred git branch structure when upstream moves from tarballs to git
Ansgar writes:
> On Thu, 2019-05-02 at 09:15 -0700, Russ Allbery wrote:
>> I'm confused. I'm a happy user of dgit and don't have to think about
>> any of those things as part of using dgit. I choose to use branches,
>> but I certainly wouldn't have to, and merging, multiple remotes, and so
>> forth don't seem related to using dgit at all.
> How do you update the package to a new upstream release?
I think I understand what I was missing. Are you using a separate
repository for only the debian directory and merging that with an unpacked
upstream tarball without using a version control system to do so? I don't
know how that works with dgit if that's the case.
For whatever it's worth, I'm in the camp that believes the combination of
the Debian packaging and the imported upstream releases should be merged
into a single coherent Git history, because the packaging changes are
heavily dependent on the upstream changes and have an important sequencing
between upstream imports that is a key component of the total history of
the package. Having to manually stitch together two separate histories is
exactly the kind of tedious chore that I think computers are good at and
humans are bad at, so I'd rather let Git do it. YMMV, of course.
> The "dgit" repository is also separate from the "real" repository; if
> you just use "dgit clone ${something}" you won't get the current
> "master" branch (unless it happens to be identical to the last release),
> or totally different if the maintainer doesn't use dgit.
Yes, that's true, and somewhat inherent in the model. I don't know that
that's avoidable without standardizing the actual Git tree used by every
maintainer for in-progress work, which is a much harder lift. dgit stays
out of the business of investigating how the maintainer does work, at the
cost of only having visibility to the commits that have been pushed to the
archive.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Preferred git branch structure when upstream moves from tarballs to git
Ansgar writes: > Having to know about branches, merging, dealing with multiple remotes, > ... *is* an entry barrier compared to not having to know about it. Now > you have to teach people that before you even get to how to write a > build recipe. I'm confused. I'm a happy user of dgit and don't have to think about any of those things as part of using dgit. I choose to use branches, but I certainly wouldn't have to, and merging, multiple remotes, and so forth don't seem related to using dgit at all. Maybe you're using dgit in a way that's suboptimal for your workflow? -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Preferred git branch structure when upstream moves from tarballs to git
Gard Spreemann writes: > For one of my packages, I maintain two public git branches: one is > upstream/latest, where I've been importing upstream's released tarballs, > and the other is debian/sid that contains the packaging. > Recently, upstream has finally started using git. What is the > recommended way for me to maintain a sane branch structure for the > packaging repository while starting to use upstream's git master as the > upstream branch to follow? A lot of people have told you that you have a lot of options, which is of course true. But in case you're looking for an opinionated answer rather than a range of options: in cases like this, I track the upstream master branch in my repository as master, just as if I had a regular clone of upstream, and use debian/master (or debian/sid if you want) for the packaging. I experimented with a few other approaches, and this one seemed to cause the least amount of pain. It means I'm not renaming the upstream branches when I pull them into my repository (which is possible to do in Git but tedious and irritating if you get the .git/config runes incorrect or some tool doesn't pay attention and merges the wrong branch). -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: [Idea] Debian User Repository? (Not simply mimicing AUR)
Mo Zhou writes: > Plus, it's super important to write every packaging bit into a single > file. That would enable simple copy from github or any other > resources. If you provide a directory, things will become more > complicated. More impotantly, the proposed single file specification > virtually adds NO overhead. This is one of those vi vs. Emacs things: I don't think you're going to convince anyone who prefers it the other way. Possibly my least favorite thing about RPMs is the spec files, because by smashing everything together into the same file, the syntax of that file is absurd. This bit is a shell script! This bit is a configuration file! This bit is human-readable text! This bit is a patch list! This bit is a file manifest! This bit is a structured changelog! This bit is a bunch of preprocessor definitions! Aie. One syntax per file, please. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Accepted libnet-duo-perl 1.02-1 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 09 Mar 2019 14:36:00 -0800 Source: libnet-duo-perl Binary: libnet-duo-perl Architecture: source all Version: 1.02-1 Distribution: unstable Urgency: medium Maintainer: Debian Perl Group Changed-By: Russ Allbery Description: libnet-duo-perl - Perl API for Duo multifactor authentication service Closes: 924127 Changes: libnet-duo-perl (1.02-1) unstable; urgency=medium . * New upstream release. - Use pagination to retrieve users and integrations via the admin API. (Closes: #924127) * Update to debhelper compatibility level V12. - Depend on debhelper-compat instead of using debian/compat. * Update to standards version 4.3.0 (no changes required). * Stop explicitly setting xz compression in debian/source/options. * Refresh upstream signing key. Checksums-Sha1: 384fb35e19b3e9c70df9929299a672f1b4c9945b 2156 libnet-duo-perl_1.02-1.dsc 9cfd1ca35f6e0fe0f7bd4345247ab3b7384ece6d 55196 libnet-duo-perl_1.02.orig.tar.xz 13a53de4c5c20678bcc0c86587a0ee9346ea63a2 488 libnet-duo-perl_1.02.orig.tar.xz.asc d8ba9dcaaadd93e33cf981af0b4fc123a3d96d54 9500 libnet-duo-perl_1.02-1.debian.tar.xz 52e9c22107a2eb0af0c3b97233668ee2d0912c13 93316 libnet-duo-perl_1.02-1_all.deb 1501abee60ec1a100af4c8462f1c19973494d9f8 7582 libnet-duo-perl_1.02-1_amd64.buildinfo Checksums-Sha256: 67ec46801b879b6430977f3a4ad4989bc6529248d5ac98c03f0240a3ab4bdf24 2156 libnet-duo-perl_1.02-1.dsc ec743438e33368731586f4e6040c64be873df24d7951aebcef16b9a6f5081a27 55196 libnet-duo-perl_1.02.orig.tar.xz ba120e573d91213d777b78cd10b3adf8f378783de2ad478b0aafec6c3ab71fe4 488 libnet-duo-perl_1.02.orig.tar.xz.asc 386c94412467eb0bfb3ca57b883c7b37f2b0aa0a784f3dd9b90c97323320105c 9500 libnet-duo-perl_1.02-1.debian.tar.xz 318971077c0aca17f3a7b3019e2d7c7bc1e83afee3364fadda9f38c0e63963c7 93316 libnet-duo-perl_1.02-1_all.deb aea5b0125f13987ae39b119ff36891418f4524310315323c24473ca30f39a31f 7582 libnet-duo-perl_1.02-1_amd64.buildinfo Files: 4987cf9db60f2015f75bd501d76a8e7f 2156 perl optional libnet-duo-perl_1.02-1.dsc 2a06a8a7191525fd7fc03a555ed29bae 55196 perl optional libnet-duo-perl_1.02.orig.tar.xz 527aee12f5a23a82c951798962605b53 488 perl optional libnet-duo-perl_1.02.orig.tar.xz.asc 557eb51b499758cd09f8e7cbfa7def55 9500 perl optional libnet-duo-perl_1.02-1.debian.tar.xz 73af182e0018d8ec253d270c96717cde 93316 perl optional libnet-duo-perl_1.02-1_all.deb b6dd34d7e1223030d252a8f4d3bee0b1 7582 perl optional libnet-duo-perl_1.02-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE1zk0tJZ0z1zNmsJ4fYAxXFc23nUFAlyEQCYACgkQfYAxXFc2 3nV65wf9HCZpDoIcNKVU3Hdfv10JUoKcMavqB3apcJlxsjL5w9v2cJ51hUE2FnvS WIwymeonYr8vUf5WiwiFS7HCt9EH4Ci9BXAw/RdjRncgOVD6l8bAw1UZAHaUbyXX pB/arFIcRTUKRN5W1astf0PMYBLVC7MBbka7PPbIRMrW+Ce8Kq0ryFa2pp+ampUH O1QRwnK2M8jBQj9EXMslQyfQulLIMuIV4AeT+QfBgH3MZ37EQaZHV5PMPFZiSM/F mBKXwYrr3/j+jj578CL2P7uQK7UqU8Im6FmjnVK3HGgIeYfd9yZH2M1KF2Dg5JKq YwOVKeGGBjUg7uboboqohNWB21MgjA== =ZQXA -END PGP SIGNATURE-
Re: Please drop anacron from task-desktop
Simon McVittie writes: > anacron/cron don't have a built-in way to skip particular cron jobs > other than open-coding it in the cron job itself. Maybe we should just fix this? cron is effectively maintained by the distributions anyway; there hasn't been an official upstream release in more than twenty years. This seems like a reasonable feature to add. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: merged-/usr-via-symlinks damage control (was Re: usrmerge -- plan B?)
Julian Andres Klode writes:
> Having symlinks in /bin and so on would be unclean: We'd have to maintain
> one symlink per binary in /usr. This is a lot of symlinks.
Does the quantity of symlinks matter?
> We also cannot ever get rid of them - it would break the property.
Well, on any given system, once every file in /bin was a symlink to the
same-named file in /usr/bin and we had some guarantee that no new packages
would break this property, we could in theory replace the entire directory
with a symlink. Doing that feels like it would require new primitives in
the package management software, though, and it might be hard to do
safely. (It would also create a break point where packages from before
that flag day could no longer be installed on the system.)
> It also fails to handle subdirectories in lib{exec}. We do want
> /usr/lib/systemd and /lib/systemd to be the same.
You can use the same approach recursively and symlink every file. This is
an old package manager trick that I think Nix is still using to this day,
and which was used to some success by such things as GNU stow (albeit for
different reasons).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Unifying logging by default
Josh Triplett writes: > Both syslog and journald support multi-line log messages syslog does not support multi-line log messages in any reasonable way. It just escapes the newline (if you're lucky) and jams all the lines together, and is rather likely to break whatever log parser you have on the other end. > Again, I'm aiming for the common case here, and I expect this to be a > years-long effort, not an overnight one. I think what's missing for me is what you're trying to accomplish with this thread. Are you just trying to make people aware of this as something we *could* do and get people thinking about it in the background? Are you forming a team of people who is going to tackle this problem in Debian and are looking for volunteers? Are you asking packagers to do work today? Are you asking for the project as a whole to reach some consensus that this is something we should do? If you're asking whether that sort of work seems like a good idea to other people, I personally think it probably does for line-structured logs with no performance issues (and that are actually logs, not execution traces or data dumps or some other thing -- see below), but the devil is going to be in the details, and blindly dumping existing log messages into syslog without thinking a little about how they're structured is not a good idea. In other words, I think this requires some per-package thought and analysis. But I previously made this change (relative to upstream behavior) for the logging from shibboleth2-sp, and that seems to have been a good idea, or at least not a bad idea. If you want to get things to change, you're probably going to have to start doing the required work (or recruiting people to do so), which means something closer to "I have identified the following 14 Debian packages that are currently logging to files, have investigated why this is the case, believe that they would be equally happy logging to syslog for the following reasons, and here are diffs to make that change." I suspect you're not going to get a meaningful consensus in advance that this is something we should do with just an abstract write-up, but may get traction with an inventory of packages in Debian that currently log to files and a plan for how to deal with them. Down that path is (potentially, if successful) a Lintian check to discourage introduction of new cases, possibly with some carefully crafted exceptions, but I think a more comprehensive analysis would be needed first. Not everything in /var/log is a log in the syslog sense, though. I see some logs that I as a system administrator do not want in syslog and would be quite unhappy if they were just dumped into syslog because they're pure noise and I'd then have to filter them out again in my log analysis pipeline. /var/log/fontconfig.log is an excellent example. That appears to be a local debugging trace log for fontconfig that I suspect has only one user (reportbug when filing bugs against fontconfig, if it even knows to grab that log) and is otherwise pretty useless. So I don't think that should go into syslog, and it would cause me work if it did. Another example is /var/log/popularity-contest. I don't think that's actually a log; it looks like data that popularity-contest gathered. I definitely do not want that dumped into my syslog. Maybe you could start with Xorg.0.log. :) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Unifying logging by default
Josh Triplett writes: > While there are *absolutely* configurations in which system > administrators want to log to arbitrary locations and files, I would > like to propose that for consistency we should configure software to > unify logging into syslog and/or journald by default. In particular, I'd > propose that daemons and applications should default to logging to > syslog (working with any installed syslog implementation providing > /dev/log), and that daemons run via systemd units may detect or be > configured to log to stdout/stderr which will be wired to the sysadmin's > preferred log target. I've seen three main reasons why packages do not use syslog: * The log data is not line-structured. Example: /var/log/apt/history.log Dumping that as-is into syslog sounds like an awful idea. This would therefore block on an upstream feature request to change log formats first, with all that entails. * Performance. Good examples here are Apache and INN, both of which have per-request logs that are intentionally not line-buffered and are logged directly to files, since losing some log messages is not as much of a concern as performance and disk I/O. I've tried to reroute things like that through syslog in the past, only to find syslog now taking a substantial portion of all available system resources trying to keep up. * The package does its own log analysis. INN again is an excellent example: it has a bespoke but very comprehensive and incredibly useful log analysis package that ships with the software and requires access to the raw logs. Anything that moves those logs out of their expected locations will break that tool, which is a significant regression for our users. I think you're going to need a much more concrete and specific proposal with worked examples of how to deal with cases like this. As is, I think this proposal is much too vague to really discuss, let alone implement. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Accepted rssh 2.3.4-12 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 18 Feb 2019 18:58:27 -0800 Source: rssh Architecture: source Version: 2.3.4-12 Distribution: unstable Urgency: high Maintainer: Russ Allbery Changed-By: Russ Allbery Changes: rssh (2.3.4-12) unstable; urgency=high . * The fix for the scp security vulnerability in 2.3.4-9 combined with the regression fix in 2.3.4-10 rejected the -pf and -pt options, which are sent by libssh2's scp support. Add support for those variants. (LP #1815935) Checksums-Sha1: a6155903c2d3f1d91a7892cef46017ad547912ef 1553 rssh_2.3.4-12.dsc 998db96d54c658c59760cbb37b431b5e45f00ad2 30448 rssh_2.3.4-12.debian.tar.xz Checksums-Sha256: 5cbe2303853f9137c26b8e290e90e8efc9d67ba0744bf3fa2e405c2a6dc40328 1553 rssh_2.3.4-12.dsc 29890c92481e04a07179ccdb42a5eac57029591f3f17278dee2846b7b9c28fa1 30448 rssh_2.3.4-12.debian.tar.xz Files: 41b018c6beba829d2bccd3fd03cbbe88 1553 net optional rssh_2.3.4-12.dsc 36bff8ad0ea6635a9635fd3a45143ab7 30448 net optional rssh_2.3.4-12.debian.tar.xz -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE1zk0tJZ0z1zNmsJ4fYAxXFc23nUFAlxreaEACgkQfYAxXFc2 3nULoAf/XLOo2fuk+2cMiHZ9ScUDJW094ucgsu+BduhpBNnNMTD0+PL1Vgkk8RhQ qZcQsMxYRhKy5VGSVSixnYdxvJ86lw/lesebs+k7DQXpAgmuN4KECIPaePcuczLx Qhkmp7AT91hHrq+/Nb4BN+wmej17W0FEJczo8KceaQ3SC1G9n0muNGW0rw9+1GuJ r/0LCg7RYnCJ+LkTbr9gQemQieVb6oKbgnC7cQAHKXRdKeOZHw4pbz4WOfCX3cNh ShGvZLhi00tj4iQq0hfahRLuf3bZPGz8bhpJd1j3srFprsKwh6AsK508XlxoXX2p uKHzTBgnulBcouWPkKkyz6GSGWuGGQ== =AH+4 -END PGP SIGNATURE-
Re: Tainted builds (was Re: usrmerge -- plan B?)
Guillem Jover writes: > So I think I'll go ahead with the current name for now, it's going to be > an optional field anyway, so if there's a better name proposed that > conveys a satisfactory meaning, I'll be happy to consider it and do a > rename, and handle any users of the current name. Why not some variation of "build environment properties"? I feel like the general feature here is to capture possibly relevant information about the build environment, and that's the most general form. For instance, I could imagine it being interesting in the future to capture whether the build was done via sbuild, pbuilder, or cowbuilder, none of which would arguably qualify as "tainted" but which may have different behavior and may therefore be useful in tracking down a bug. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Use of the Build-Conflicts field
Tollef Fog Heen writes: > I think we should (over time) aim towards non-reproducible builds being > release critical bugs, and I think «builds differently in an unclean > chroot» is a class of non-reproducibleness we need to tackle («fails to > build» is really just a subset of «builds differently»). This feels like a very hard problem if we try to express it through Build-Conflicts or through careful tuning of upstream build systems. It's working at cross-purposes with the goal of a lot of upstream build systems, which try to dynamically discover available optional features and packages and compile in optional features. It's so much easier to solve this problem with containers, and the places where I'm aware of it being solved at scale, it's done with containers, or with namespacing and related features. One hides from the build system everything that isn't supposed to be part of the build, and then this problem becomes much easier to solve. To be clear, sometimes there are good reasons for Debian to do the hard thing and try to solve a problem more deeply than others do. But I'm not sure this is a good example of that, or a good place to invest significant resources, particularly since it's in the class of problems that would require work from every individual package maintainer to carefully configure their build system to not behave differently in the presence of unexpected packages. Making it seamless and simple to build inside an isolated namespace feels like a more productive investment and would benefit every package. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Accepted rssh 2.3.4-11 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 10 Feb 2019 11:17:28 -0800 Source: rssh Architecture: source Version: 2.3.4-11 Distribution: unstable Urgency: high Maintainer: Russ Allbery Changed-By: Russ Allbery Closes: 921655 Changes: rssh (2.3.4-11) unstable; urgency=high . * The fix for the scp security vulneraability in 2.3.4-9 introduced a regression that blocked scp of multiple files from a server using rssh. Based on further analysis of scp's command-line parsing, relax the check to require the server command contain -f or -t, which should deactivate scp's support for remote files. (Closes: #921655) Checksums-Sha1: dceb7da45abf1c64e300c426f879bd38d23f46a2 1553 rssh_2.3.4-11.dsc 73edbba658c448753fcf9343d1d273f470bdd992 30332 rssh_2.3.4-11.debian.tar.xz Checksums-Sha256: a601be045c621b4cadca033ac836e6da753b2ce25df09442ce22d2bd2d2e17a8 1553 rssh_2.3.4-11.dsc 464eac3ff45d55591ab23a22de2d205bc09e8bf8258655cc0291c41b25438404 30332 rssh_2.3.4-11.debian.tar.xz Files: db5723bf5557ea2f342e8fe20f3795b7 1553 net optional rssh_2.3.4-11.dsc b6c0efbbde4855832db40aa5b1ce5a12 30332 net optional rssh_2.3.4-11.debian.tar.xz -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE1zk0tJZ0z1zNmsJ4fYAxXFc23nUFAlxgeXoACgkQfYAxXFc2 3nVNfgf+PrYrypfGfbRhu53GIzxqm6rUjHhLFAMfHWp3YQvMgifPCrXVmLoCmAQk EijqTWbsePG4NEv19FyvWKWNu1IYe9MZFIOhy46C/evzF/wNytVOLuT9QcXNza8j Hq+XHLQN4LnR8L8Ggx684vG7MGWq/N9RdEBSSKSOYbBx1DWVj2WHE4Dc1HiCtsDo WOISpSv8oDLhw6/QWPDbvmZWZZwKeMQu8qwL23dbsK36143E82Q5gMlfQCtEZ3Le 4GWE2O2R/1D8usZrFm0xvL/Rq5Xn8A25505blDOdNqi+48St/6nVkfEI/olQN0qi 87JUKiRwdvZyurwdIW6obM8G5tVsyg== =NJI8 -END PGP SIGNATURE-
Re: Namespace for system users
Sam Hartman writes: > I'd like to support the _user convention as well. > It works well as packages move around between distributions and things > get upstreamed. Agreed. I think we should just write this up as the recommended approach for all new system users in Policy. (Changing the existing ones is sadly a much more complicated problem.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Accepted rssh 2.3.4-10 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 02 Feb 2019 10:59:47 -0800 Source: rssh Architecture: source Version: 2.3.4-10 Distribution: unstable Urgency: high Maintainer: Russ Allbery Changed-By: Russ Allbery Changes: rssh (2.3.4-10) unstable; urgency=high . * Also reject rsync --daemon and --config command-line options, which can be used to run arbitrary commands. Thanks, Nick Cleaton. (CVE-2019-3463) * Unset the HOME environment variable when running rsync to prevent popt (against which rsync is linked) from loading a ~/.popt configuration file, which can run arbitrary commands on the server or redefine command-line options to bypass argument checking. Thanks, Nick Cleaton. (CVE-2019-3463) * Do not stop checking the rsync command line at --, since this can be an argument to some other option and later arguments may still be interpreted as options. In the few cases where one needs to rsync to files named things like --rsh, the client can use ./--rsh instead. Thanks, Nick Cleaton. * Remove now-unused variables from the rsync validation patch. Checksums-Sha1: 653927e9f563caa618bc79ceed492b020f741db2 1553 rssh_2.3.4-10.dsc a5e4f8cab40c8c7f9f454e2154ee4e7b38f8235a 30280 rssh_2.3.4-10.debian.tar.xz Checksums-Sha256: 100519617bc5ebe7e9873af0f9fa360801ee0d75dcc8ec25a9583aec5d06d9f5 1553 rssh_2.3.4-10.dsc 2c41e3c3905ae87249b0ad028b20e88a86d1bf4445e3be216ff87733221e1b5d 30280 rssh_2.3.4-10.debian.tar.xz Files: bfaf5c2799545bf54f8d7b0b68fb81a2 1553 net optional rssh_2.3.4-10.dsc 3acfc99e2106da0343f47f9a71e3f2e1 30280 net optional rssh_2.3.4-10.debian.tar.xz -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE1zk0tJZ0z1zNmsJ4fYAxXFc23nUFAlxV6SEACgkQfYAxXFc2 3nXCxwf/Qgn/v0ufU2/0n1QxOzjnZE5tju9a4ADrhSQzHyW0waSb/VXGHDtJMpgQ vuO9QjnlfcDKwI3uQvq6v0KXDvReP/B54WBh6wDyS7SfL2+hzQvFZkc1GbmxpqNx VhYw+8rNnhCHm3RlBATO4tssrk30KSWvy82F1hbC8GUxxA0UDrrYhmeKBQW2zh+r XGmVGFcNU7obuXR6Uu97HXcDQGDRYBD5rZA3O3U4Vl/vzns385UJOcxNLrp8TgEW tKSLfdzifqolLx/chFy1CcqWXpVdBt83WeYEDMEh8N6QBYW80Y1jvkKMA9FA7Jig oCpbXrqZeGRiXBEQowdNuDv6xWH65Q== =78u6 -END PGP SIGNATURE-
Accepted rssh 2.3.4-9 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 28 Jan 2019 21:03:59 -0800 Source: rssh Architecture: source Version: 2.3.4-9 Distribution: unstable Urgency: high Maintainer: Russ Allbery Changed-By: Russ Allbery Closes: 919623 Changes: rssh (2.3.4-9) unstable; urgency=high . [ Russ Allbery ] * Validate the allowed scp command line and only permit the flags used in server mode and only a single argument, to attempt to prevent use of ssh options to run arbitrary code on the server. This will break scp -3 to a system running rssh, which seems like an acceptable loss. (Closes: #919623, CVE-2019-118) * Tighten validation of the rsync command line to require --server be the first argument, which should prevent initiation of an outbound rsync command from the server, which in turn might allow execution of arbitrary code via ssh configuration similar to scp. * Add validation of the server command line after chroot when chroot is enabled. Prior to this change, dangerous argument filtering was not done when chroot was configured, allowing remote code execution inside the chroot in some configurations via the previous two bugs and via the mechanisms in CVE-2012-2251 and CVE-2012-2252. * Document that the cvs server-side dangerous option filtering is probably insufficient and should not be considered secure. * Remove ancient upgrade support in debian/postinst. * Remove debian/source/options, which was forcing compression to xz (now the default). * Update to debhelper compatibility level V12. * Update standards version to 4.3.0 (no changes required). . [ Ondřej Nový ] * d/watch: Use https protocol Checksums-Sha1: 42eccc8a40da4bccb24eb1cae17e5f60b95cae52 1548 rssh_2.3.4-9.dsc ef0b4a667e16c3f09209dd6c049e5bed6e4f119a 29704 rssh_2.3.4-9.debian.tar.xz Checksums-Sha256: 59a60a8c4c703752afd349e56a5acf848f4e6a8ba9a7de14b25b8522a716711e 1548 rssh_2.3.4-9.dsc aae025b0d9b2d335ad140ecb872b97ec162cd26aae81aaf979d97478db9a4a24 29704 rssh_2.3.4-9.debian.tar.xz Files: c7e597dcb58a210e377ce83771cce0d9 1548 net optional rssh_2.3.4-9.dsc 11e4877e55f793e5b2efeb24ed9c5d49 29704 net optional rssh_2.3.4-9.debian.tar.xz -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE1zk0tJZ0z1zNmsJ4fYAxXFc23nUFAlxP39EACgkQfYAxXFc2 3nV7vAf6ApcxS1NqfqqxzZklCcNbvmhAzZ0+8tMNvTQ5zRMUqoFg8wbpumrzy5ji iET3HqYZk9WSq0UDiM90sMDFivW1GsPVms8B4G/bRlXuXJTACiWPrJIdesadb8w5 6czJp/LjSLP0iROa+9NzTngujaZwZE8NL8sNE7T+YhZnVI+C0/U7KLHJ11Ir/Mel s8a4GQoD/8Rl9/bpHTxevtgKiQFkPttEI8CRYsIWLfGppPG7Y1hz3WcNN2Np5Fo/ 8ofAvtapGTD0GtoYX8COYogLpkEwWcI8L25SC0Q/NZmeiCIx1w1EOFXjr1CxUCN9 Bm0bO3P3iI+w4TnOHlYKG4rKjWQ1UQ== =GBQT -END PGP SIGNATURE-
Re: Potentially insecure Perl scripts
Ben Hutchings writes: > People have said this about ASLR, protected symlinks, and many other > kinds of security hardening changes. We made them anyway and took the > temporary pain for a long-term security gain. Well, Perl has a deprecation mechanism with warnings and so forth, although I don't think Perl has ever actively broken a feature outside of "use " with a later version, except for features marked as experimental. But I suppose it's possible. Good luck with that -- there was a long discussion about this when <<>> was introduced, and as one can tell, that viewpoint did not prevail. Maybe it's used less now and it might be easier to get rid of it? -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Potentially insecure Perl scripts
Colin Watson writes: > Ah, I see. I think it would have been clearer what you meant with a bit > more context, so here it is for others: >If one can be sure that a particular program is a Perl script >expecting filenames in @ARGV, the clever programmer can write >something like this: >% program f1 "cmd1|" - f2 "cmd2|" f3 < tmpfile >and no matter which sort of shell it's called from, the Perl >program will read from the file f1, the process cmd1, standard >input (tmpfile in this case), the f2 file, the cmd2 command, >and finally the f3 file. Pretty nifty, eh? Note also that you can modify @ARGV in the program and then use <>, and I know of Perl programs (I have even written Perl programs, back in the day) that do this to introduce pipes and other constructs and then use <> to loop through the results. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Potentially insecure Perl scripts
Ian Jackson writes:
> Apparently this has been klnown about for EIGHTEEN YEARS
> https://rt.perl.org/Public/Bug/Display.html?id=2783
> and no-one has fixed it or even documented it.
It's been documented for pretty close to eighteen years too. See
perlop(1):
The null filehandle "<>" is special: it can be used to emulate the
behavior of sed and awk, and any other Unix filter program that
takes a list of filenames, doing the same to each line of input
from all of them. Input from "<>" comes either from standard
input, or from each file listed on the command line. Here's how it
works: the first time "<>" is evaluated, the @ARGV array is
checked, and if it is empty, $ARGV[0] is set to "-", which when
opened gives you standard input. The @ARGV array is then processed
as a list of filenames. The loop
while (<>) {
... # code for each line
}
is equivalent to the following Perl-like pseudo code:
unshift(@ARGV, '-') unless @ARGV;
while ($ARGV = shift) {
open(ARGV, $ARGV);
while () {
... # code for each line
}
}
except that it isn't so cumbersome to say, and will actually work.
It really does shift the @ARGV array and put the current filename
into the $ARGV variable. It also uses filehandle ARGV internally.
"<>" is just a synonym for "", which is magical. (The pseudo
code above doesn't work because it treats "" as non-magical.)
Since the null filehandle uses the two argument form of "open" in
perlfunc it interprets special characters, so if you have a script
like this:
while (<>) {
print;
}
and call it with "perl dangerous.pl 'rm -rfv *|'", it actually
opens a pipe, executes the "rm" command and reads "rm"'s output
from that pipe. If you want all items in @ARGV to be interpreted
as file names, you can use the module "ARGV::readonly" from CPAN,
or use the double bracket:
while (<<>>) {
print;
}
> I think this is a serious bug in Perl which should be fixed in a
> security update.
There is absolutely no way. So much stuff in Perl depends on this. You
will break all kinds of scripts. It's been a feature of the language for
basically forever.
There have been extensive discussions of this on perl5-porters, and
there's some general consensus that it was a bad idea originally, but
changing this destroys backwards compatibility. You just can't; it's like
removing strcpy from libc. The best you could do would be to add a
pragmata to turn it off, and *maybe*, *someday*, enable that pragmata by
default with a sufficiently new version in "use".
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Nix and non-standard-toplevel-dir
Kai Harries writes: > I have filled an ITP for the Nix package-manager [1]. During packaging > lintian pointed out [2] that Nix relies on a non-standard-toplevel-dir. > The Nix package-manager keeps by default all packages in the path > `/nix/store`. In principal this path can be changed, but it would make > it impossible to use pre-build binaries from the standard Nixpkgs > channels [3]. > The problem are retained dependencies. A package keeps references to > a package it depends on. And this references contain the absolute > path (including `/nix/store`). > Section 5.5.3 and 6.1 of the PHD thesis "The Purely Functional > Software Deployment Model" [4] on which Nix is based gives some more > insight. > I would like your advise on how to proceed. I think this is a case where we should waive FHS for this package, due to the unique nature of this package. The top-level purpose of FHS is consistency on the system, partly for other packages but primarily for the local systems administrator. All namespaces that aren't covered in FHS are implicitly reserved for the local administrator, and they know that the distribution will use the FHS directories for specific purposes and can set disk allocations, remote mounts, and so forth accordingly. Nix is effectively a completely different model and concept for how to lay out software packages. It's therefore not surprising that it doesn't comply with the FHS, since it's not even trying to be the same sort of system that the FHS anticipates. It's an experiment with something new. I think including the package manager in Debian, if possible, is a great way to let Debian users experiment with some interesting concepts, and is very much in line with our goals to be a universal operating system and to provide a common basis for people to experiment and do interesting things. Thank you for working on this! I also don't think that anyone who installs and then uses the Nix package manager is going to be surprised that it doesn't follow the FHS. This is pretty experimental stuff, and I doubt anyone is going to use it without expecting it to be a bit weird. If anything, they probably already know how Nix works and are expecting it to use those paths. There doesn't seem to be much drawback in this carefully-chosen lack of compliance with the FHS. I don't think it's worth writing an explicit Policy exception for this, since it's a single edge case. Instead, I think it's a good use of a Lintian override documenting what's going on. Obviously, if Nix becomes really popular in the long run, we can then go back and write this into Policy. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: including complete corresponding licence information should stay a requirement (was Re: Debian Policy 4.3.0.0 released)
Thorsten Glaser writes: > Sean Whitton dixit: >>2.3 & 4.5 >>In cases where a package's distribution license explicitly permits >>its copyright information to be excluded from distributions of >>binaries built from the source, a verbatim copy of the package's >>copyright information should normally still be included in the >>copyright file, but it need not be if creating and maintaining a >>copy of that information involves significant time and effort. > I quite disagree. Downstreams will require the licence information, > and if it’s included in the source package, it’s easy enough to add > it to the binary package, and if not, the above does not apply either. Hi Thorsten, Just a procedural note here: ftp-master is the responsible team for the minimum standards in debian/copyright files, and there has been a very long-standing desire to align Policy with the actual practices of the ftp-master team to avoid confusion. This change was made in large part towards that end, and was based on guidance from ftp-master, specifically: | 4. The FTP team believes that documenting copyright holders in | debian/copyright is a good idea. If policy were modified to make it | along the lines of SHALL if the license does not explicitly allow it to | be left out of binary distributions and SHOULD in all other cases, the | FTP team believes this would be a good change make maintainer's efforts | easier when a package license allows for it. (Quoted in the start of https://bugs.debian.org/912581.) I'm not sure if you're objecting to how that guidance was worded in Policy (in which case we can certainly fix it if we can come up with clearer language), or the substance of that advice. If the latter, this of course doesn't mean that you shouldn't object if you feel it's wrong. It does mean, though, that you're probably going to need to convince ftp-master that their practices are wrong here for it to make sense to revert this change on the Policy side. Otherwise, we would be going back to having Policy say one thing but having the standards for the archive be something else entirely, something that we all have been collectively unhappy about for probably at least a decade. I think there's a pretty strong consensus for keeping the wording of Policy in tighter alignment with what ftp-master actually requires. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Sending using my @debian.org in gmail
Jeremy Stanley writes: > On 2018-12-05 14:58:08 +0100 (+0100), Thomas Goirand wrote: >> Absoultely not. Adding some DMARC records in our DNS doesn't break any >> server not checking DMARC records. > Migrating _client_ configurations/workflows to all submit via > Debian-controlled relays on the other hand would be necessary, to > avoid servers who check DMARC records rejecting messages from people > using their debian.org addresses in other ways (for example, yours > seems to have been sent through an MTA in GPLHost for relaying to > the lists.d.o MX). Right, the whole point of DMARC is to say that messages from a given domain only originate from a small and well-defined set of servers, or from servers with access to specific private key material. Right now, people can use their debian.org address and send mail from anywhere. For example, this message is being sent from my personal servers and, were it not addressed to a Debian mailing list, would not go anywhere near Debian infrastructure. If we're not going to require that anyone sending mail from a debian.org address do so through project infrastructure (which is a large change), there's basically no point in doing anything with DMARC. It would only increase the chances that mail not sent through Debian infrastructure would be rejected by over-aggressive implementations that treat unknown as failure. Whether we want to continue to support that use case is certainly something we can ask, and balance against the benefits of setting up proper DMARC, SPF, DKIM, and so forth. The advantage would be that project mail might be more reliably deliverable, and we would allow receiving systems to discard more forged spam. The disadvantage is that setting up infrastructure, documentation, and client configuration to send all mail from debian.org addresses through project infrastructure would be a lot of work, particularly since I'm sure that, in the grand Debian tradition, there are at least as many ways we all send mail as there are Debian developers. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: usrmerge -- plan B?
Guillem Jover writes: > The current merged-/usr deployment (via usrmerge or the bootstrapping > symlink generation before unpack) is a major hack, and bypasses the dpkg > understanding of the filesystem, it breaks dpkg-query, and while we > could workaround the breakage there, it's still the wrong way to go > around this. Does this imply that you're considering adding support for merging /usr *properly* directly inside dpkg, with all the correct updates to dpkg's metadata? Because that would be an awesome way to fully support this. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Tainted builds (was Re: usrmerge -- plan B?)
Guillem Jover writes: > … and then I'm not entirely sure a non-minimal environment should be > qualified as tainted? For example contrast using a minimal but outdated > installation to a non-minimal, but clean and up-to-date one. > I think I'm still of the opinion that a user should be able to build on > a normal (clean and up-to-date) system and get a proper result. I guess > the problem might be how to define "clean". :) Tainted is a loaded term that may make this more confusing. I think it may be better to instead think of it as additional metadata to figure out why a package is buggy, if a bug shows up. Some build states we know are more likely to cause problems than others, but if a bug exists only in the versions of the package built in a minimal chroot and not in the versions built on a regular system, that's a useful clue to what may be causing problems. But perhaps the reproducible build testing infrastructure is the better solution to this problem. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Tainted builds (was Re: usrmerge -- plan B?)
Guillem Jover writes: > Whether a package is being built within a chroot or not, has nothing > to do with how that installation is being managed IMO. It feels a bit > like recording what's the form factor of the machine being run on? :) I think what people are trying to get at here is "was the package built on a system with packages other than build dependencies plus build-essential plus essential/required packages installed." I do think this would be very useful to track, but it's a bit complicated to work out, and there are probably a few other exceptions that would need to be in place. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: wicd-daemon-run_1.0_amd64.changes REJECTED
Lorenz writes: > That will work for runit-init, but what about runit-sysv and > runit-systemd? Let's say I have systemd (as init), runit-systemd and a > foo daemon installed; and 'runscripts' package ship a run script for > foo. How can I detect if the user wants to manage foo with runit or with > systemd? I think a command would work for that case as well. What I'm imagining would look something like this: - If runit-init is installed, it installs a trigger that runs the command for any change to the runit metadata directory. That command sets up the users, runit configuration, and does whatever other actions are needed to maintain a consistent system. - If runit-init is not installed, by default all services are run through the regular init system. However, the local system administrator can run the command manually, specifying a specific service, and it then sets up that service to run via runit in a similar way and also disables the systemd unit or init script. - runit-sysv and runit-systemd install a different trigger that runs the script with a flag that says to update all configuration that was previously manually enabled by the system administrator (so that you can update service definitions or delete ones when packages are removed), and ignore all the other configurations. Note that a lot of the runit metadata can probably be derived from systemd units for services that have unit files. For example, if the systemd unit runs the daemon as a different user, runit can probably use the same user, and the systemd unit may well also run the daemon in the foreground since systemd prefers that for the same reasons runit does. So it's conceivable that you could get out of shipping explicit runit data for a lot of packages, or ship something that just notes that the unit file can be autoconverted. This would cut down on the maintenance burden of the primary package maintainer a lot. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: usrmerge -- plan B?
Michael Stone writes: > On Tue, Nov 27, 2018 at 08:54:43AM +, Simon McVittie wrote: >> If I was wrong in assuming good faith and you were being argumentative >> for the sake of being argumentative, please stop: that is not >> constructive. >> >> Either way, please don't call me stupid. That is not *at all* >> constructive - especially if you want things you say in future to >> change my opinion on anything! - and contributes to an atmosphere of >> hostility that drives away Debian contributors. > I agree. I wish you were just as busy policing memes like "people who > have issues with mandatory usrmerge are just scared of change". There is not enough energy in the world to police all of the unnecessarily confrontational and counter-productive things people have said in this thread. :( I wholeheartedly agree: the argument here is not about fear of change. It's primarily about a cost/benefit tradeoff and an orderly transition that is well-understand and won't surprise anyone, and secondarily about Debian's ongoing severe social problems around having a constructive technical discussion. Thank you so much, Simon, for your incredibly useful and productive messages in this thread. I am certain there are technical approaches and good compromises here that will make everyone happy, but we're not going to be able to reach them if everyone falls into the trap of loudly repeating their position, getting defensive, and lashing out at each other. We had some things break because of a change to buildd configuration that caught some people by surprise. It's entirely reasonable that the first reaction to that was "woah, wait, hold on, slow down, what's going on here?" A wonderfully productive next step would be for someone with the time to do so (which sadly I do not right now) to write up a summary of what the desired end state should be for Debian (maybe with a few options) and then a more detailed transition plan about how to get from where we are now to where we want to be. That will give us something concrete to debate and to test against the risks that people perceive, and hopefully will reduce the hardening of positions on all sides. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Our build system may be broken: /bin vs /usr/bin
Wouter Verhelst writes: > How can it do so, though, if the build system hardcodes paths to > binaries[1]? Isn't it better (and easier) to have non-usr-merged buildd > chroots as long as we still support such systems? > [1] Yes, I know policy says you shouldn't do that, but if there's a > 3000-line upstream configure.ac file that does so all over the place, > fixing that might be involved, for questionable benefit (exaggerating > here, but you get the point). This was mentioned elsewhere in the thread, but just for the sake of clarity, Policy doesn't say that. Policy says only that maintainer scripts should not hard-code paths. Whether other binaries should or should not is a somewhat complicated question that is a little case-dependent. For instance, we decided in an earlier debian-devel thread that Perl and Python scripts should hard-code paths rather than using the env trick. This therefore makes your point even stronger. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: individual packages moving binaries from /bin to /usr/bin
Ansgar Burchardt writes:
> If we want to support packages such as iptables moving binaries from
> /{s,}bin to /usr/{s,}bin while setting up compat symlinks on
> non-merged-/usr systems, it might be useful to have a dh-usrmerge
> package creating the maintainer scripts. (Also for some files below
> /lib, but most libraries could just be moved without compat symlinks.)
> This should be similar to what OpenSUSE has done; see the section around
> `#UsrMerge` on https://en.opensuse.org/openSUSE:Usr_merge
> This could also be seen as a slower path to merged-/usr: programs such
> as `sed` would be in both /bin and /usr/bin and hard-coding either would
> be fine (as with merged-/usr, but not without). Less static files would
> be on a read-write root file system (if /usr is a separate read-only
> fs).
Yes, this exactly, thank you. This is a much better description of what I
was seeing as an alternative to the current usrmerge approach, assuming a
(not yet decided) project consensus that we want to do something like
usrmerge in the long run.
This approach will obviously take forever, and be another one of those
Debian transitions that someone five years from now has to do a bunch of
work to finally finish, assuming that happens at all. But it would be
backward-compatible the entire way.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: usrmerge -- plan B?
into a set of possible strategies to move forward, but I don't feel like we've even separated the strands of things we're arguing about yet, let alone clearly explored the options. > We can then have this discussion again early in the bullseye release > cycle. If we must. That idea makes me wince. This will just result in the same thing happening again. Let's have the discussion *now*, when the problems are fresh in our mind, and then defer *action* to early in the bullseye release cycle (which I suspect is likely to happen anyway given how long it usually takes us to sort through questions of large migrations like this). -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: usrmerge -- plan B?
Ansgar Burchardt writes: > Moving files around in such a matter that they are still available in > the old location (via a symlink) is not a very invasive change, so there > is only a small risk of problems. I think it's fair to note that our past experience in Debian doesn't really support this. I've run into multiple problems in unstable with uninstallable packages due to various bugs in this sort of change, most recently with iptables. We repeatedly get the details of this change wrong in various subtle ways that create issues in some upgrade paths and not others. This may be acceptable temporary breakage, and I don't think any of it made it into stable (and it usually doesn't even make it into testing), but if we're going to do a lot of this, I think we need better tools, such as declarative support in packaging metadata that tells dpkg to do the right thing, so that we can lean on a single, well-tested, robust implementation. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: usrmerge -- plan B?
Ian Jackson writes:
> Michael Stone writes ("Re: usrmerge -- plan B?"):
>> Let's restate this so it can stand clearly on its own:
>> "We ran into some unanticipated issues when we usrmerged our build
>> systems, and we think the way to fix that is to force merge every one
>> of our users' systems."
> That does seem to be the position that is being advanced.
I think this is an unfair characterization of the thread, and adds
considerably more heat than light.
We ran into unanticipated problems *with supporting full portability of
packages between usrmerged systems and non-usrmerged systems*. (And I'm
not sure the problems were really that unanticipated -- that problem is
hard.) We're now evaluating what that means for the overall goal of
supporting systems with merged /usr. One possibility is to not attempt to
support that use case, which can be done in two ways: never merging /usr,
or merging all systems.
In this sort of discussion, it's very important to keep distinct the point
we're discussing and our positions on that point, and try to maintain our
agreement on what is even under discussion while we disagree.
To support my side of that, I promise to not mischaracterize consensus on
*what we're debating* as consensus on *what the outcome should be*, and
keep those two things entirely separate.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: usrmerge -- plan B?
Michael Stone writes: > On Wed, Nov 21, 2018 at 02:19:56PM -0800, Russ Allbery wrote: >> Doing this check in reproducible-builds definitely helps allievate my >> concerns as a backstop, but this is still fragile and we don't have a >> tight test/fix cycle. And, in general, I'm dubious of a path where we >> support building a package on both merged and unmerged systems and then >> allow running it on both merged and unmerged systems. There are so >> many places that binary paths creep into software build processes, and >> so many different upstream software build processes to analyze. > I'm likewise generally dubious of a process where we try to merge two > directories into one directory during a system upgrade as a side effect > of installing a package. I've just seen too many strange things on real > systems. If not supporting legacy installs isn't an option, we never > should have started this. I don't believe supporting legacy installs *without doing the migration* is an option, or at least an option that we should take. We could theoretically make it work, but the ongoing burden to packagers and to our testing infrastructure would be high. It would be yet another obscure and irritating thing that you'd have to mess with when packaging and that was very hard to test, and we already have way too many of those. So yes, this is exactly the decision before us. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: usrmerge -- plan B?
Matthias Klumpp writes: > (At the moment I don't actually see the upcoming doom - a few packages > broke, bugs were fixed, life goes on. If it turns out that we are not > able to cope with new bugs in time, we can always change decisions > later). The reason why I personally jumped into this thread is that I don't think the initial fix proposed for R was good engineering. We should not be doing that sort of fragile machinations in Autoconf configuration. It will end in tears. We will miss some other binary later, or Autoconf will change flags or how it probes, and we won't catch the breakage. Doing this check in reproducible-builds definitely helps allievate my concerns as a backstop, but this is still fragile and we don't have a tight test/fix cycle. And, in general, I'm dubious of a path where we support building a package on both merged and unmerged systems and then allow running it on both merged and unmerged systems. There are so many places that binary paths creep into software build processes, and so many different upstream software build processes to analyze. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: usrmerge -- plan B?
Holger Levsen writes: > On Wed, Nov 21, 2018 at 12:38:53PM -0800, Russ Allbery wrote: >> But it's not just my opinion that matters. I think we need to decide >> this somehow as a project, whether via the TC or via GR or something, >> because there's a real disagreement here over whether we can or should >> force-upgrade all Debian systems and I don't believe doing something >> short of that is going to be supportable. > why do you think we need to decide it via TC or GR, without letting > whoever is responsible for the affected packages decide? Because we have no idea what packages are affected (possibly a lot). It's not just packages that ship files in /lib, /bin, and /sbin (although that's already lots); it's every package that uses something in those directories. Personally, I think the chances of breakage are reasonably small and I think Marco has already done a ton of work to try to find that breakage, but it's a very sweeping, global change, which is what makes it challenging. > (Or are you just forseeing that someone will want to go to the TC?) > As a user, I couldnt care less if usrmerge is enabled or not. 0 visible > differences. /bin is a link to /usr/bin, the sun still rises in the > morning. If we can decide via consensus that no one objects to the goal and it's just a matter of getting enough testing to make usrmerge essential (and working out the timing for when we have enough testing), great. Given the general trend of the threads, I'm dubious we'll get there, but consider me +1 for that position if it helps. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: usrmerge -- plan B?
Michael Stone writes: > 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. Yup, lack of testing is definitely a valid point. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: usrmerge -- plan B?
Jeremy Bicha writes: > On Wed, Nov 21, 2018 at 3:39 PM Russ Allbery wrote: >> But it's not just my opinion that matters. I think we need to decide >> this somehow as a project, whether via the TC or via GR or something, >> because there's a real disagreement here over whether we can or should >> force-upgrade all Debian systems and I don't believe doing something >> short of that is going to be supportable. > If we are going to have a vote, we don't have a lot of time. I think > that if Debian were to choose to convert all systems to usrmerge for > the Buster release, it ought to be complete in Buster before the > Transition Freeze which is scheduled for January 12. [1] > [1] https://release.debian.org/ We could also skip buster, hold usrmerge out of the buster release as a not-yet-supported configuration (or ship it with a bunch of disclaimers; I have no strong opinion either way), and then aim for the next release, and in the meantime double down on trying to get as much testing of usrmerge systems as possible. That's going to be a disappointing delay for a lot of people, I'm sure, but it's still better for them than never doing this at all. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: usrmerge -- plan B?
Michael Stone writes: > On Wed, Nov 21, 2018 at 09:59:24AM -0800, Russ Allbery wrote: >> If we just force-merge every system on upgrade, none of those >> inconsistencies matter, and I do believe we could successfully complete >> that process (with some bumps, of course). > I think that's likely to be the most painful upgrade since a.out. We'd > need one heck of a lot of testing that needs to have already started > unless we want to push back buster. This seems like too high of a level of pessimism given that the usrmerge package already implements this sort of force-merge and some people have it installed and don't seem to be running into a bunch of bugs. The last round of problems was on systems without it installed, because packages generated that way weren't backward-compatible, not with the forward direction of forcing the merge. That said, if we do want to go down this path, getting as many people as possible to install usrmerge now and make sure it doesn't break anything (or report bugs if it does) seems like a good idea. (Just don't build Debian packages for upload on the resulting system; use a build chroot instead.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: usrmerge -- plan B?
Marco d'Itri writes: > On Nov 21, Russ Allbery wrote: >> I think there are some arguments to be made for just force-merging and >> moving on, but they're mostly "tidiness" arguments (letting everyone > No, they are not that at all. I have never argued about "tidiness", nor > did anybody else that is working to support merged-/usr. A merged-/usr > is an enabler for new features, like stateless systems, clones, > appliances and better containers. Simon McVittie today was patient > enough to explain some of them. I read all of Simon's message, which was excellent and which I greatly appreciate. The arguments he listed there are, however, the arguments I was classifying as "tidiness" arguments. We shouldn't get caught up on terminology, since whether or not my adjective is correct isn't really the point. The point is that every use case he describes is possible without usrmerge. It's just more complicated because it requires manipulating multiple paths instead of one, which requires a bit more ingenuity and fragility (via symlink redirections and the like) to make atomic. I completely understand why merged /usr makes it easier, and removes a lot of avoidable bugs. But it is not a *requirement* for doing any of the things that he spells out in that message. There is still a tradeoff here. >> strategy of (for example) moving each binary out of /bin manually, but > As I explained, this cannot really work. Of course it can work. It will just take forever and produce a bunch of minor bugs along the way and won't be something you'll be able to wait for before tackling other goals. In reality, it might well mean just giving up on merging entirely because people won't be willing to sustain the effort over that length of time. Personally, I consider separate /bin and /usr/bin to be a historic artifact whose remaining useful properties have become obsolete or been replaced with other, better techniques (such as mounting /usr in initramfs), and we'd all be better off following Red Hat and Arch, dealing with the pain of merging every system, and then saving ourselves the time and energy we spend on this separation. It definitely makes some system design patterns simpler. I also agree that this isn't a diversity question; so far as I know, there aren't any remaining viable use cases for split /bin and /usr/bin that work in Debian today or have any hope of working in a Debian of the future. /bin is already useless without /usr mounted, and is basically certain to remain so. The remaining argument is just that the transition is difficult and may not be worth the effort. But it's not just my opinion that matters. I think we need to decide this somehow as a project, whether via the TC or via GR or something, because there's a real disagreement here over whether we can or should force-upgrade all Debian systems and I don't believe doing something short of that is going to be supportable. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: usrmerge -- plan B?
Adam Borowski writes: > Thus, either usrmerge Essential or not included in Buster -- no middle > way. I think I agree with this. My impression is that most of the problems with usrmerge are because we're trying to support a halfway position that Red Hat did not try to support, where some systems are merged and some aren't. This creates a ton of complicated edge cases and inconsistencies, and now we're looking at making invasive changes to package build systems to try to fix those edge cases. This feels like a vast waste of developer time and resources that could be put to better purposes. If we just force-merge every system on upgrade, none of those inconsistencies matter, and I do believe we could successfully complete that process (with some bumps, of course). But this halfway slow migration is death by a thousand cuts. I think there are some arguments to be made for just force-merging and moving on, but they're mostly "tidiness" arguments (letting everyone recycle the brain cells they're currently using to keep track of whether something is in /bin or /usr/bin and try to make decisions about this, getting rid of all the compatibility symlinks, permanently eliminating all minor bugs from omitting /bin or /sbin from PATH, and so forth). Those are real benefits that I don't think we should underestimate, but I'm not sure they're strong enough benefits to create a bunch of hard feelings and frustration and anger inside the project. They're also mostly benefits for packagers; there aren't a ton of benefits for users here. If we're *not* going to commit to force-merging all systems, I think we should just stop, or at least slow way down, because there are a *lot* of edge cases and it's going to require a lot of work to go through them. I'm very dubious of the viability of any strategy that requires people override the paths to binaries in their debian/rules file to undo Autoconf auto-probing, for example. It feels to me like we should decide as a project whether we're going to do the same thing Red Hat did and just do the merge and be done with it, or whether we're going to do a much slower migration by some more robust strategy of (for example) moving each binary out of /bin manually, but either way, the current strategy does not seem viable to me. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Our build system may be broken: /bin vs /usr/bin
Ian Jackson writes:
> Russ Allbery writes ("Re: Our build system may be broken: /bin vs /usr/bin"):
>> Marco d'Itri writes:
>>> Actually this is the root problem: policy says that packages should
>>> use the $PATH to search for commands, but your package (like many
>>> others) hardcodes their full path.
>> Policy only says that for maintainer scripts. I agree that it's not a
>> good idea in any location, but I don't believe we've explicitly
>> forbidden it anywhere.
> We don't even have consensus that it is a bug! We have, for example,
> at least one important component which *requires* hardcoded paths in
> their critical configuration files.
Sorry, my "not a good idea" phrase needs more nuance.
I think the general argument against hard-coding paths in maintainer
scripts generally applies here as well. However, there are going to be
exceptions that need to hard-code specific paths for other reasons, so
it's going to have to be a case-by-case determination. A good
counter-example where we do want to hard-code paths is to interpreters
(see previous debian-devel discussion).
I would be pretty dubious of Policy language here stronger than "should."
I would also consider anything other than /bin/sh, /bin/bash, etc. in
shell scripts to be a bug, and I'm worried that some upstream build
systems will generate /usr/bin/sh or /usr/bin/bash if they decide to use
Autoconf to find shells.
Tactically, I'm in favor of not using usrmerge on buildds. I feel like
this is the *last* place we should enable usrmerge, since it's likely to
require all systems consuming the built packages to also have usrmerge
enabled.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Our build system may be broken: /bin vs /usr/bin
Marco d'Itri writes: > On Nov 19, Dirk Eddelbuettel wrote: >> GNU R has long been relying on sed, tar, bzip2, ... and many more base >> tools. No issues there. Generally looked for in /bin and found there. > Actually this is the root problem: policy says that packages should use > the $PATH to search for commands, but your package (like many others) > hardcodes their full path. Policy only says that for maintainer scripts. I agree that it's not a good idea in any location, but I don't believe we've explicitly forbidden it anywhere. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: I resigned in 2004
Carsten Leonhardt writes: > Russ Allbery writes: >> The general principle that I would advocate for here, though, is that >> if someone says clearly and explicitly "never contact me again," we >> should do what we can to never contact them again. > If the message would be signed I'd agree, but for a non-signed message > that would open abuse potential. I wouldn't like to find out I've been > retired from Debian because someone faked a message like that in my > name... This theoretically could happen, but in practice using some basic intuition while reading the message will, I think, reduce the chances to nearly zero. For instance, the original reply did not feel like the kind of thing someone would forge (it's too specific, too emotional, and too full of easily falsifiable details), not to mention that it's hard to figure out a motive for someone to forge such a message from someone who had been inactive in Debian for a long time. Also, if that does happen, it's remediable later, as Wouter points out. We're not going to do anything completely irreversible. "Never contact me again" is what one is supposed to tell someone if they feel like they're being harassed. It's the sort of thing that I do think we want to try to honor unless we have some reasonable reason to believe that something weird is going on. I think it's highly unlikely that anything good for anyone will ever come out of sending another message to someone who says that. To be very clear, I'm not saying this to defend the rudeness of the reply, or to say that anyone did anything wrong by following our normal MIA process. Just advocating for a change in procedure in the future if someone sends that type of reply. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: I resigned in 2004
Mattia Rizzolo writes: > Indeed, I was very bothered. > On the other hand, most of my reply to willy's mail was not addressed to > him, but to debian-devel@ at large, to have everybody else understand > how silly what he did was. Replying to my email in d-private@ saying > "aye aye, I really want to go away" wold have been *far* more effecting > (even if process-wise I'd have preferred him click the damn buttons we > sent him) and his case would most likely already been closed. > Instead, he decided to throw such a bothersome mail in debian-devel. The general principle that I would advocate for here, though, is that if someone says clearly and explicitly "never contact me again," we should do what we can to never contact them again. (We're probably not organized enough to guarantee we'll succeed in this, but we can make the attempt.) Pretty much however obnoxiously they make that statement, to me that's sort of a "magic phrase," and unless there's some legal or emergency reason why we *absolutely* have to contact them, I'd just stop talking to them completely and take whatever default actions we would take if we had never been able to contact them again. To be clear, I think his reply was unnecessarily nasty, and I greatly appreciate the work that you're doing. This is not intended as any sort of dissatisfaction with your work, just a suggestion for if this comes up again. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Q: secure boot
Holger Levsen writes: > On Tue, Nov 06, 2018 at 10:08:10AM +0100, Bastian Blank wrote: >> On Tue, Nov 06, 2018 at 01:09:50AM +0100, Adam Borowski wrote: >>> But only the stock kernel, which turns it non-free software. >> What is non-free? Signing stuff does not change the freeness of the >> software. > it does introduce https://en.wikipedia.org/wiki/Tivoisation however. I'm not sure how us signing our stuff does that. The computer's firmware may do this if it enforces secure boot and doesn't provide a way to turn it off. But only running signed software is a valid and sometimes desirable security configuration, which our users may want to choose. By default, apt will only install software signed by Debian's archive keys and will refuse to install anything else. We rightfully don't consider that to be Tivoisation. I feel like supporting secure boot is similar. By this, I am not trying to defend hardware vendors who lock the owners of the hardware out of installing software of their choice, only contending that Debian signing its software doesn't create that problem. One could argue that we should refuse to ever sign anything on the grounds that it makes it possible to use Debian with hardware that requires signatures, and we should be boycotting such hardware. And indeed I wouldn't be surprised to see an FSF distribution take such a stance. But I think that would be incompatible with our project choice to allow our users to run Debian on non-free hardware and leave that choice up to the user. (I also don't think this would be useful from a tactical standpoint; vendors making such locked-down hardware don't care whether Debian runs on it.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Should libpam-elogind Provide libpam-systemd ?
Adam Borowski writes: > Conflicts would greatly simplify packaging, but I'm afraid we need > coinstallability at least for upgrades. With d-i installing systemd, > the user needs to be able to switch to sysvinit -- and, horrors, some > might want to go the other way. > It'd be damage to allow two loginds running at the same time, thus what > about: > * the "systemd" package starts its logind only if systemd is pid 1 > * elogind starts its logind only if pid 1 is not systemd I may be missing some complexity here, but it feels as if there should be a PAM module that determines which logind is running and then dispatches the PAM calls to the appropriate module for the running logind. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: no{thing} build profiles
The Wanderer writes: > On 2018-10-25 at 20:00, Russ Allbery wrote: >> The Depends field should be used if the depended-on package is >> required for the depending package to provide a significant amount of >> functionality. > This does not actually seem to conflict with the "would be found > together in all but unusual installations" definition for Recommends; in > a case where the depending package can still provide meaningful > functionality without the depended-on package, but will miss "a > significant amount of functionality" if the latter package is not > present, both definitions would seem equally applicable. I don't know why you would expect otherwise? That seems entirely natural and expected given that Depends is a stronger relationship than Recommends, and therefore is naturally a subset of the things that would qualify as Recommends. You choose the strongest relationship that is applicable. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: no{thing} build profiles
Marvin Renich writes: > I certainly agree with you that 99.9% is clearly a wrong number for > this. However I disagree that even 0.1% justifies using a different > definition for Recommends than policy gives. libgpgme11 is not doing that. The library is literally unusable for its actual technical purpose without gnupg installed, which clearly meets the definition of Depends in Debian Policy: The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality. There is absolutely no question that gnupg is required for libgpgme11 to provide a significant amount of functionality, given that the library can do essentially nothing other than generate error messages if gnupg is not installed. Now, there is *also* an interesting argument in this thread that we should consider the usability of programs linked against a shared library for optional features sufficiently strongly to warrant demoting dependencies of shared libraries to Recommends. There is some support for this given the special nature of shared libraries and the interaction between their dependencies and the Debian practice of linking with shared libraries for all optional features. We can have (and are having) a debate over whether we should *amend* the rule about dependencies to single out shared libraries for special treatment due to that property. But I think it's simply incorrect to say that libgpgme11 is in any way doing something wrong given what Policy says right now. This *clearly* meets the definition of Depends as currently stated in Policy. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: no{thing} build profiles
Ian Jackson writes:
> Russ Allbery writes ("Re: no{thing} build profiles"):
>> Minimal installation size is *not* the only goal here. Ease of use and
>> lack of surprise is important to. Personally, I'd much rather have
>> numerous unused packages installed than to have something break in an
>> opaque way when I try to use it, even if I'm unlikely to need to use
>> it.
> I would note that none of this is an argument against demoting this
> dependency to a Recommends.
It is *an* argument, but definitely not as strong of an argument.
I'm pretty strongly opposed to Suggests here. I think that's simply
wrong. Recommends is a trickier question, and I can see the case for
asking shared libraries to use Recommends instead of Depends for cases
like this, even if it makes the library essentially non-functional. I'm
not sure I'm convinced, but there's definitely a strong case, particularly
in cases like gnupg where the package is of non-trivial size.
The primary thing that gives me pause is the error handling. It needs to
be *really obvious* to the user what to do to make the optional
functionality work if the required package was removed for some reason
(and remember that can be for reasons other than disabling Recommends,
which I agree is an advanced configuration; Recommends aren't enforced
across all conflicting package scenarios), and I'm concerned that shared
libraries throwing some API error is not going to bubble up to the user in
any useful way.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: no{thing} build profiles
Adam Borowski writes: > Thus, I'd re-propose a Policy change that was mentioned in multiple > threads in the past: > "A runtime library should not Depend: or Recommend: on any packages than > other libraries or dormant data, unless the library or its programming > language provides a convenient scheme for it being loaded only > optionally. Any such dependencies should be declared by programs linked > against such a library." I think the prerequisite for making a change like this would be for the library to be able to surface this transitive requirement in metadata so that debhelper could support automatically adding it to the dependencies of all linked programs (and I'm not sure that sort of collapse of our dependency structure is a good idea). Otherwise, if a user does want to use the functionality that GnuPG provides but doesn't have gnupg installed since it's been relegated to a Suggests, do they have much hope of figuring out what's wrong and how to fix it? Or will the package just look broken? Minimal installation size is *not* the only goal here. Ease of use and lack of surprise is important to. Personally, I'd much rather have numerous unused packages installed than to have something break in an opaque way when I try to use it, even if I'm unlikely to need to use it. This is particularly the case when the additional packages don't do things like run services or (much) increase the attack surface. Personally, I think people in this thread are too worried about trying to remove as many packages from their system as possible and not worried enough about a straightforward user experience. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Debian Buster release to partially drop non-systemd support
Paul Wise writes: > On Thu, Oct 18, 2018 at 5:24 AM Russ Allbery wrote: >> Timer units are also a more complicated problem since they're not a >> superset of cron behavior. They do some things better than cron jobs; >> they do other things much *worse* than cron jobs. I have cron jobs >> that I wanted to convert to timer units and discovered I couldn't >> because timers simply wouldn't work for what I was trying to do. > Could you give some examples of the issues you discovered with systemd > timers? > BTW, we have in systemd-cron a tool for generating systemd units from > crontab/etc. MAILTO was the main thing that I remember missing in terms of pure functionality. The other problem I can recall wasn't functionality, but was ease of use: a timer unit can only trigger a service unit, and service units aren't suitable for doing arbitrary shell scripting. Here, this wasn't for packaging but was instead as a local system administrator. I have a lot of cases where I drop a simple 20-line shell script into /etc/cron.daily that has some logic intermixed with variables that list things like, say, directories to back up to another host. I looked at replacing that with a timer unit, just as an experiment, but I would have had to write the timer unit to control the timing, a separate exec unit that specifies what command to run, and then put the shell script into yet a third file (with no particularly obvious location for the local system administrator). Since I don't like using /usr/local/bin for such things, I'd probably end up extracting configuration from the script, sticking the script in a local Debian package, and installing the configuration separately. I now have four different files just to replace a single file dropped into a directory. Admittedly, this was to replace something run from cron.daily, and maybe the solution there (if one is considering a system that doesn't need a separate cron daemon, which in theory should be possible if one wanted to do it although not necessary of course) would be to have a single timer unit that uses run-parts the way that cron runs cron.daily. Timer units were a closer match for cron.d, although I'm still missing MAILTO. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Debian Buster release to partially drop non-systemd support
Philipp Kern writes:
> On 17.10.2018 06:52, Russ Allbery wrote:
>> I think a package of a daemon that does not inherently require any
>> systemd-specific features and would work straightforwardly with
>> sysvinit, but has only a systemd unit file and no init script, is not
>> only buggy but RC-buggy. That's what Policy currently says.
> And it would not be buggy if it does not ship any init integration or
> relies on a non-init service supervision system like runit. (The crux
> being that systemd is not modular to be run that way and not portable.)
No, I think that's also buggy. If it's a daemon that should be started at
boot and it doesn't include init integration, I think that's an obvious
bug. It's very hard to write a Policy rule that says this, since it's
more of a common sense sort of bug.
> You say "more than adequate". I don't particularly see it as providing a
> solid system as you don't get restart on failure. Now I can see how
> people say that this is not a problem as daemons should not crash in the
> first place. Maybe I just value reliability of service more highly than
> being woken up at night being told that my service is unreliable.
My point is that sysvinit is a non-default configuration and it's
reasonable to expect that it may be missing some features or robustness.
If you have the time and resources to put into equaling the robustness
that you would get under systemd, that's great, but sysvinit is much more
of a fire-and-forget system and is known to in general not have that
robustness property. sysvinit users who care will run something like
monit that watches health externally and takes appropriate action.
I think every packager owes it to the social fabric of the project to make
the effort to provide a basic init script, in the same way that we do
basic porting to other architectures and investigate build failures.
There is some point, which is subjective, beyond which I think it's
reasonable to ask someone who cares about sysvinit to do more complicated
work, but I think a basic init script tested under systemd's init support
is a reasonable request.
My personal concern is more about the social community of the project than
about the technical details. I consider providing an init script even if
I don't personally use sysvinit to be extending the hand of community and
solidarity to other Debian community members who use it. To say to them
that their concerns have been heard and supported, even if I don't agree
with their concerns. Personally, I find that extremely important, a
principle that's as important as the technical quality bar we try to reach
in our packages.
> Is a possible answer here to ship an init script and then provide
> additional supervision options using override files - to enhance
> whatever is provided by the sysv generator?
I personally would tend to maintain separate init and systemd unit files
and only lightly test the init script unless I knew there was something
tricky going on, but this answer varies based on the complexity of the
daemon.
> This statement also does not address a daemon that only runs through
> socket activation - passing an fd to the daemon. But I don't have any
> example handy and this might be a strawman argument. Except that I could
> see that for simplicity newer daemons might be written in this way as it
> does cut a significant amount of socket handling code.
Yes, at the point where we have an upstream daemon that was written
explicitly for use with systemd in that fashion, I think that turns into a
different sort of question. This is now more akin to porting, and that's
a different bar. I don't think we can place hard requirements on what a
maintainer chooses to do here, other than asking for them to take patches
from porters if those are offered.
> To some degree I regret that we cannot provide a fully integrated
> distribution by mandating that the core layers (be it kernels or init
> systems) can be switched out. systemd still supports init scripts but on
> the other side there's pretty much complete stagnation with the onus on
> the systemd maintainers to keep things working. There could as well have
> been an effort to support a subset of the unit language for sysvinit.
I do completely agree with the general thrust of this thread: sysvinit
needs an active maintenance team, and without that work, it will
eventually die. There's a limit to how much people who don't use it
should feel obligated to keep it working. Hopefully those who do use it
will be able to find the resources to support and improve it (and indeed
being able to support the unit *syntax* would be a huge step towards
making sysvinit support in Debian more robust).
> I suppose one answer would be a cron generator. Given that policy
> specifies naming schemes for /etc/cron.{hourly,daily,weekly,monthly,d},
> there could proba
Re: Debian Buster release to partially drop non-systemd support
Philipp Kern writes: > I don't understand. If I submit a merge request to the maintainer, it's > on me to test what I submit actually works. So if I add stuff for a > completely different init system I have to test it. The question is: Is > the package buggy if it does not contain an init script but a systemd > unit and it seems to be the case. Note that there are a *lot* of useful > options in a systemd unit that would need emulation to make properly > work with sysvinit. I think a package of a daemon that does not inherently require any systemd-specific features and would work straightforwardly with sysvinit, but has only a systemd unit file and no init script, is not only buggy but RC-buggy. That's what Policy currently says. It is quite easy to write a sysvinit init script for most daemons that will basically work. I don't think the maintainer is obligated to do much more than that (for instance, I don't think you need to try to duplicate systemd hardening configuration or other features that are quite challenging to do under sysvinit without more tool support, although some of that may be coming in start-stop-daemon). I don't think it's reasonable to expect every Debian maintainer to have a system booted into sysvinit to test the init script, since that can be quite an undertaking if one isn't using sysvinit normally, but thankfully you don't need to do that to test the init script. Just delete the unit file and then test the init script with systemd. For nearly all daemons that don't involve tight system integration, this will be more than adequate. If you want to do more than the minimum and try to replicate more unit file features in the init script, that's great, but I think it's also reasonable to not do so and wait for sysvinit users to file bugs. But I do think it's a key and important part of our general project-wide compromise that maintainers of packages that include daemons continue to do the reasonable minimum to keep those daemons basically working with other init systems, until such time as the project as a whole decides that sysvinit support should not be maintained. > It'd need to run much more often (every 15 minutes). So cron.daily > wouldn't fit. For the sake of the argument it'd need to be a shell > script that checks multiple conditions (see [1]). And we currently don't > have timer/cron deduplication, unfortunately. That means it'd also need > to disable itself on systemd systems (but of course cron would still > invoke the script periodically). Similarly - as a more general remark - > having it as a cronjob doesn't let you monitor it in quite the same way. I think we should solve the problem of timer/cron de-duplication before opening the door to timer units. I agree that timer units would be a very valuable addition to a lot of packages, but timer/cron de-duplication feels like an entirely tractable problem that's useful to resolve in its own right. Maybe we can just do that? -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Bug#906183: Dependency change and upgrade
"Devarajulu, Mohanasundaram" writes: > There are few reasons why I believe upgrade does not bring in entirely > new packages by default when dependencies are changed. IIRC there's a difference here between "apt-get upgrade" and "apt upgrade". The latter is equivalent to "apt-get --with-new-pkgs upgrade", I believe. apt(8) says: upgrade (apt-get(8)) upgrade is used to install available upgrades of all packages currently installed on the system from the sources configured via sources.list(5). New packages will be installed if required to satisfy dependencies, but existing packages will never be removed. If an upgrade for a package requires the remove of an installed package the upgrade for this package isn't performed. In general, I recommend to any new Debian user that they use apt instead of apt-get as their normal interaction mechanism with the package system. Sometimes the other tools are useful for getting more specific behavior, but the defaults of apt seem well-tuned for the typical user and typical use cases. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Bumping epoch and reusing package name "elisa"
Marc Haber writes: > Why do we have them then, and why do we keep tightening up Policy in a > way that we'd better write "don't use epochs, they're evil"? The original Policy documentation of why we have epochs (which I think has been essentially unchanged forever) is: Note that the purpose of epochs is to allow us to leave behind mistakes in version numbering, and to cope with situations where the version numbering scheme changes. It is *not* intended to cope with version numbers containing strings of letters which the package management system cannot interpret (such as ``ALPHA`` or ``pre-``), or with silly orderings. I think the canonical example is a package that was using version numbers like 20180925 and then switches to semver 1.0 versions. (Policy recommends always using 0.0.20180925 as the version for packages versioned by date for exactly this reason, but if someone didn't notice that and uploads the package using date versions for a while, epochs are our only way to convert to upstream's versioning system shy of renaming all the packages.) That said, it feels like the general sentiment in the project has turned quite strongly against epochs. When I first got involved in Debian, it was common to use epochs whenever we had to package an older version of upstream for some reason, but my impression is that this has fallen out of favor. That reduces the use of epochs considerably. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Bumping epoch and reusing package name "elisa"
Christoph Biedl writes: > For me this concern is about asking upstream for a change that is caused > by something more or less Debian-internal - although other distributions > might have that issue as well. So it should rather be handled inside > Debian. > And I subscribe to that position. Upstreams are going to vary a lot here. For example, I as upstream would be happy to bump a version number for a similar problem in Red Hat, since meh, I don't attach a ton of significance to version numbers anyway as long as they go up and vaguely follow semver. (The only thing that would give me pause is going from a 0.x to a 1.x version number, since that carries some more semantic weight.) But I could see some people being irritated by the request. I think there's no substitute for knowing upstream and having a feel for how they'd react. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Bumping epoch and reusing package name "elisa"
Andrey Rahmatullin writes: > On Mon, Sep 24, 2018 at 09:21:14AM -0700, Russ Allbery wrote: >> apt is going to have no idea what to do for a system that already has >> the previous package installed. > This is not a problem as upgrading to an unrelated software is not > something that we should care about. I agree it's probably not going to cause problems in practice in this case (ironically, it's probably worse for the new software to have a higher version in terms of unexpected apt behavior), but it's still breaking apt's version model, and I'm not sure I can think through all the implications. Ideally, we would never reuse the name of a binary package for some unrelated piece of software, although I know that's not realistic in the real world. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Bumping epoch and reusing package name "elisa"
Andrey Rahmatullin writes: > On Sun, Sep 23, 2018 at 10:53:04PM +0200, Aurélien COUDERC wrote: >> FTP masters rejected the upload of the new elisa 0.2.1-1 as the package >> has a lower version than the former Elisa project and they proposed >> bumping the epoch and reusing the name. > I don't find this reasonable to be honest. > Unless it has some other reasons than just "lower version". This causes a ton of headaches for the archive software. IIRC, I believe dak is rather unhappy about version numbers going backwards, and of course apt is going to have no idea what to do for a system that already has the previous package installed. Consider also systems like snapshot.debian.org and what they have to do to deal with this. It's basically a whole bunch of pain that can be relatively easily avoided and probably isn't worth chasing in every piece of software. Version numbers should be monotonically increasing, and I think it's reasonable for a lot of software to bake in the assumption that's the case. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Limiting the size of installed changelogs
Ben Hutchings writes: > - A large part of the changelog is listing the changes in upstream > stable updates. These are mostly important changes, and we already try > to leave out those that are clearly irrelevant to Debian. Should we > continue to include these, or limit to those that address CVEs or Debian > bug reports? For the record, I've found these curated summaries of the upstream changes *incredibly* helpful more times than I can count. So I'd love to see these continue to be available somewhere. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]
Adrian Bunk writes: > I thought this would would have been less offensive than the normal > "This is a lie." when a statement is the exact opposite of the > truth (compare [1] with the claim "no upstream release since 2013"), > but as non-native speaker I accept your explanation that I was wrong > on that. "I don't think this is correct" is a less confrontational way of phrasing this that assumes the other person is writing in good faith and just made a mistake, as opposed to maliciously attempted to deceive people, which is what both your original phrasing and "this is a lie" (unintentionally, I assume) implied. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]
Paride Legovini writes: > It would certainly work, but as you say it is still irritating. I like > the idea of putting the binaries in a different directory *and* > providing a "name compatibility package", as it has been already > suggested. This package would provide the symlinks in /usr/bin and set > the needed Conflicts. In this way we allow both packages to be installed > at the same time while leaving the users enough freedom to chose what to > have in their PATH. Oh, hm, yes, I rather like this idea too, particularly combined with putting those symlink packages in their own namespace (and maybe their own section). Maybe this is overkill for the relatively small number of these packages we run into, but it provides some basis for writing more interesting tools. For example, if we could standardize an alternatives-style way of selecting between various packages providing the same binary names, we could provide user tools that would let individual users select which one to prefer by updating their own PATH. I agree that we're likely to see more of this problem as the overall universe of software available and has been packaged continues to expand, and not all of the problems have relatively easy solutions. (Node, which came up elsewhere in this thread, was a particularly challenging problem because it was an interpreter and had to be referenced in #! lines. Hopefully we won't have that specific problem frequently.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]
Paride Legovini writes: > However, there are clearly cases where renaming binaries makes several > people unhappy (most likely: the package maintainers, upstream, people > writing scripts, users of different distributions), while not making a > single user happier. This is especially true with low popcon packages > with a small use case intersection. If the packages conflict, though, this is extremely unfriendly to the users who do want to use both packages. They cannot use both packages on the same OS installation, and have to resort to chroots or VMs or containers, which is a lot of extra complexity. I'm therefore in favor of keeping Policy's prohibition on using Conflicts for this case; maybe a combination of two packages will get lucky and there will be literally no users who want to use both at the same time, but it's very hard to tell when that's the case and the failure mode is ugly. I kind of like the solution of putting the binaries in a different directory. This is also a little irritating, since users have to add an additional directory to their PATH, but they only have to do that once and it works consistently going forward, and they can still use the other program. It's not totally unheard of to have to modify PATH to use a package, particularly one that wants to use a bunch of very generic command names. That was always the official way to use MH, for example. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Accepted krb5-strength 3.1-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 31 Aug 2018 17:07:43 -0700 Source: krb5-strength Binary: krb5-strength Architecture: source Version: 3.1-2 Distribution: unstable Urgency: medium Maintainer: Russ Allbery Changed-By: Russ Allbery Description: krb5-strength - Password strength checking for Kerberos KDCs Changes: krb5-strength (3.1-2) unstable; urgency=medium . * Update standards version to 4.2.1. - Enable verbose test output. - Install the upstream release notes as NEWS.gz, not changelog.gz. - Add Rules-Requires-Root: no. - Use https for URLs in debian/copyright. - Change priority to optional. * Update to debhelper compatibility levl V11. * Bump debian/watch version to 4 and use https. * Add upstream-vcs-tag configuration to debian/gbp.conf. * Remove obsolete debian/source/options that was forcing the compression format to xz (now the default). * Refresh upstream signing key. Checksums-Sha1: 4b2a90dbbe10fb7b40ef93d054912987f8cbefbf 2049 krb5-strength_3.1-2.dsc af88124e6038acc3b5ba09019c248d07744956ce 15500 krb5-strength_3.1-2.debian.tar.xz Checksums-Sha256: 6e38492ce5877c7a428ee7baa3afb02bdb520ef1296ae351d777eef1d907f0ad 2049 krb5-strength_3.1-2.dsc 6d5aa5a461ce711a671a8fb8a9b9ba8e9be214bec0d66e3d488be89f393ae205 15500 krb5-strength_3.1-2.debian.tar.xz Files: 5dffe29a8b0c82a3912fa86094d6d378 2049 net optional krb5-strength_3.1-2.dsc 6363dc0a973abbcdf327563f8ae3d274 15500 net optional krb5-strength_3.1-2.debian.tar.xz -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE1zk0tJZ0z1zNmsJ4fYAxXFc23nUFAluJ2X4ACgkQfYAxXFc2 3nWhrggAvVZs/Ub4yOq/EXvqOc4W6pXlWcmtaNLGunedgDrTsiFxbPcPNHlFnbl7 dCQf1FaRwiPhC3mQt/he3DB4eOQD881x09EQhz4ttFYFjLbgWGlcTRYcnUcGAR07 237ngUz8rdvEAxbSRAcYEQFw7sg34HCO9GgBwVeMYp+0MLKAxe0tYrxZYrw0IFgh t9430Uy45vaVxIOxteGbk0WCGfXdoS+jD3+ks+vyz8QncBtyVNkGbyF/AbVhqO4O LAlXNyg1Spk+6CfD3W8oRISDki1s7xng+19JwvmXX16l5jmsWe1zxpTt+YVlOa9D nsIXoHDkmGXbp7/DXMo4Eb3kJuwoQQ== =FBwa -END PGP SIGNATURE-
Accepted xfonts-jmk 3.0-22 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 31 Aug 2018 15:52:25 -0700 Source: xfonts-jmk Binary: xfonts-jmk Architecture: source Version: 3.0-22 Distribution: unstable Urgency: medium Maintainer: Russ Allbery Changed-By: Russ Allbery Description: xfonts-jmk - Jim Knoble's character-cell fonts for X Closes: 802389 901123 Changes: xfonts-jmk (3.0-22) unstable; urgency=medium . * Add eight missing runic letters to neep (10x20 and 6x13), thanks to Ben Wong. (Closes: #901123) * Convert to the dgit-maint-merge(7) package workflow. - Remove all build output files from the source package. I previously avoided this since it will create a large Debian patch, but better to optimize simplicity of workflow than the size of still-tiny archive artifacts. - Add include-removal to debian/source/options. - Remove debian/source/local-options and local-patch-header. - Create debian/gbp.conf from dgit-maint-merge(7) but enable pristine-tar, since the package was already using it. - Add single-debian-patch and auto-commit to debian/source/options. - Add a slightly modified version of the default patch header. * Use a placeholder file to ensure neep/ascii exists consistently in all representations of the source package even though its contents are otherwise removed by debian/rules clean, since it contains only generated files. * Use /bin/echo in modd/Makefile.modd to support -n and -ne regardless of shell, allowing the modd fonts to be rebuilt during package build. * Remove modd fonts and makefile machinery on debian/rules clean. * Remove neep/fragments/neep-post-ampersand-05x11-bold.bdf.orig from the source package, dropping a dh_clean override that preserved it. This file was previously preserved since it's in the upstream tarball release, but since I'm cleaning up the source package by removing generated files anyway, remove this additional special case at the cost of slightly bloating the Debian diff. * Change Homepage, debian/watch, and, in debian/copyright, Source to the mirror of the now-defunct original upstream web site maintained by Nik Nyby. (Closes: #802389) * Add Multi-Arch: foreign. * Override INSTDATFLAGS during install to avoid making installed font files read-only and then breaking dh_strip_nondeterminism. * Change package short description to use "Jim Knoble" rather than "James M. Knoble," matching upstream's LSM entry and spec file (and also removing a Lintian false positive). * Update standards version to 4.2.1. - Add Rules-Requires-Root: no. Checksums-Sha1: 4e0d48778dcaea316057f249d5e31b1eefe61d25 1627 xfonts-jmk_3.0-22.dsc f3715140a664a917be08290f97259a75bc34ef77 192080 xfonts-jmk_3.0-22.debian.tar.xz Checksums-Sha256: 947e4478749149f51f7fa56411580f70b9256f375ac87907e66bc14940459944 1627 xfonts-jmk_3.0-22.dsc dff9baa6cbc986270506aee40b4972422062e8dbcb1ba274f88189a6da551fd9 192080 xfonts-jmk_3.0-22.debian.tar.xz Files: 6d88575cf533748d06280522856795af 1627 fonts optional xfonts-jmk_3.0-22.dsc f49823e8d8a065b0552e31257083bdfc 192080 fonts optional xfonts-jmk_3.0-22.debian.tar.xz -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE1zk0tJZ0z1zNmsJ4fYAxXFc23nUFAluJx+UACgkQfYAxXFc2 3nUx/Qf+LrqblvjfUUeKFpqGFbRPFVisLQ6zld6WUd5s22h6s/6BuFUFXgaWVl6v jhryaHZ2DXoCAxEXKDAzOZcxfWSPwUdeOlC1XQjt0F1MZjyQjmg9ZkjA3Gee4rsd JhUXXPo0CogyOu+NUjYoIAmkedCdxF4NHyjUVbgZKDWth4OEi01N2ML+sZCYUrPX h4Ttx514umsBS18xj2ym68UNv/2tTesRCEn91FFOrnkmD6PYdaEVOXGytwr8WYOv Ob2gGJk0FqA3A+7uXT6i9Y4KxAkvBiZR44G7kKgZjJ5rfq4Pa+W0A6Xw/i3pvkio /Qwivn9N2eoh2tkM1MKmIs+njSFiDQ== =hKsC -END PGP SIGNATURE-
Accepted libpam-krb5 4.8-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 31 Aug 2018 10:57:00 -0700 Source: libpam-krb5 Binary: libpam-krb5 libpam-heimdal Architecture: source Version: 4.8-2 Distribution: unstable Urgency: medium Maintainer: Russ Allbery Changed-By: Russ Allbery Description: libpam-heimdal - PAM module for Heimdal Kerberos libpam-krb5 - PAM module for MIT Kerberos Changes: libpam-krb5 (4.8-2) unstable; urgency=medium . * Move canonical packaging repository to salsa.debian.org. * Update standards version to 4.2.1. - Enable verbose test output. - Install the upstream release notes as NEWS.gz, not changelog.gz. - Add Rules-Requires-Root: no. * Add upstream release tag pattern to debian/gbp.conf. * Bump watch file version to 4. * Refresh upstream signing key. Checksums-Sha1: a62f08ede6c0ba06beea70903188496f1537b3c2 2050 libpam-krb5_4.8-2.dsc ca146dc25c972124ac353037055eaf350b173295 25388 libpam-krb5_4.8-2.debian.tar.xz Checksums-Sha256: f0a29e20858a926f77f41ae3557966fa458708d54a675a6bef12a048a0ddf792 2050 libpam-krb5_4.8-2.dsc cfec8f962d3b979ab80f026d87ee261507e36ef14a0114e27b182d1e288f3cf5 25388 libpam-krb5_4.8-2.debian.tar.xz Files: 9fdf7f5ba492dcb4ef0a78d66aea2035 2050 admin optional libpam-krb5_4.8-2.dsc 9af3df195f01f40a53e8c0cb47f0e48d 25388 admin optional libpam-krb5_4.8-2.debian.tar.xz -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE1zk0tJZ0z1zNmsJ4fYAxXFc23nUFAluJggcACgkQfYAxXFc2 3nXqOQf+NsFmMN2J4yjYvxb8HPC53B7BLPVhUFwiccJDZ3lIdBSEMh5PBNlrWlNY QoyQtIz41GaJIWvYQavTS+oeuA7TuGX9a9ceO2sRZCZl1z1V2hrZfMcEHYAtkHd7 NCkaBQ4lJ5QTe45kQpXln5qLRTzGkQ8QpXLNL9zn+8Flbezw1auxAVEXjkKvog9E wy9IWteajIsyleAwyPzHxpu42CodqfFBaQWB2hb5vwGcsOmKbpW7uvj6KokzfoGG TH9oflAMMXu5pxLo/rSJ76sC7M0x0JTNEBz2HScOKxEuuW8xhRC2ZJIoJbOkAA2B jN0uRm7YNdBzDFGeTt58Urx9OvATYQ== =5vIj -END PGP SIGNATURE-
Accepted krb5-sync 3.1-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 26 Aug 2018 18:17:15 -0700 Source: krb5-sync Binary: krb5-sync-plugin krb5-sync-tools Architecture: source Version: 3.1-2 Distribution: unstable Urgency: medium Maintainer: Debian QA Group Changed-By: Russ Allbery Description: krb5-sync-plugin - MIT Kerberos Active Directory synchronization plugin krb5-sync-tools - Kerberos Active Directory synchronization tools Changes: krb5-sync (3.1-2) unstable; urgency=medium . * Orphan the package (see #907366). * Move packaging repository to salsa.debian.org. * Update to debhelper compatibility level V11. - Remove --parallel flags, no longer needed. - Remove dh-autoreconf dependency and sequence, no longer needed. * Update to standards version 4.2.1. - Enable verbose test output. - Install the upstream release notes as NEWS.gz, not changelog.gz. - Add Rules-Requires-Root: no. - Use https for URLs in debian/control and debian/copyright. - Change priority to optional. * Remove old Breaks and Replaces against krb5-sync. * Remove versioned dependency constraints satisfied by oldstable. * Bump watch file version to 4 and use https for URL. * Switch to the DEP-14 branch layout and update debian/gbp.conf and Vcs-Git accordingly. * Remove debian/source/local-options and local-patch-header and switch to normal patch management. * Remove debian/source/options configuration to force xz compression, which is now the default. * Remove debian/rules override to force xz compression of the binary package, since this is now the default. * Refresh upstream signing key. * Run wrap-and-sort -ast. Checksums-Sha1: d56ea878af1c77b929cfeda1151277f995f178e8 1856 krb5-sync_3.1-2.dsc 59d87b9a1c26ca952d4b99c62b22ea228be42122 17256 krb5-sync_3.1-2.debian.tar.xz Checksums-Sha256: 8e9a5840c1c1162378d0cf3d341bd99e08d3836e3d3b95c202374406b5b4cd97 1856 krb5-sync_3.1-2.dsc 5b51eb854c335138beaca281a3ffa2d44a6a649f23ffa9beecd25ab8f3c86689 17256 krb5-sync_3.1-2.debian.tar.xz Files: 28df1c1b2e5a018707f0e8e4f54c518c 1856 net optional krb5-sync_3.1-2.dsc 900252c9be0e5a6968a917b7cc1fbbcd 17256 net optional krb5-sync_3.1-2.debian.tar.xz -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE1zk0tJZ0z1zNmsJ4fYAxXFc23nUFAluDUdkACgkQfYAxXFc2 3nX+aAf9Fioga/U3WMwQNQW97G4oaCBLePRhXG932nbWKhE3Gk7uv2BUIfbWRIzK xHvL800zsnp/8ajoetNSnDrrHGLR4HtvmMWBbVjJElijM7fYW+psJ0e4pV36Wxvs GZVz0ZMKsiDS1eO3aPjUDtRyH3iwc3wOawfmO8vS6OwEW+7jGtqQYPmGLE1QniVU 5AnrnkZL+E5KOc73mU5Vwrlx0qskjKkCy8jGu7H/7riOXYTyDKhWEr+bjVv42hJa sYn78idQxMr8MIStdWC4l7EYrTEFnB0QcgaYvotwgq5Qj2mgZ+rPaUXMz5w/p9oT hTrVSaUbLyMLtD2TS+KHTXet117ZQg== =Jf9V -END PGP SIGNATURE-
Accepted libpam-afs-session 2.6-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 26 Aug 2018 16:11:10 -0700 Source: libpam-afs-session Binary: libpam-afs-session Architecture: source Version: 2.6-2 Distribution: unstable Urgency: medium Maintainer: Debian QA Group Changed-By: Russ Allbery Description: libpam-afs-session - PAM module to set up a PAG and obtain AFS tokens Changes: libpam-afs-session (2.6-2) unstable; urgency=medium . * Orphan the package (see #907361). * Move the packaging repository to Salsa from Alioth and update Vcs-*. * Update to debhelper compatibility level V11. - Remove --parallel flags, no longer needed. - Remove dh-autoreconf dependency and sequence, no longer needed. * Update standards version to 4.2.1. - Enable verbose test output. - Install the upstream release notes as NEWS.gz, not changelog.gz. - Add Rules-Requires-Root: no. - Use https for URLs in debian/control and debian/copyright. * Delete debian/source/local-options and local-patch-header and use standard patch handling. * Remove debian/source/options forcing xz compression, since this is now the default. * Bump watch file version to 4 and use https for URL. * Remove version qualifications on libpam-runtime and libpam0g dependencies, which were older than oldoldstable. * Switch to the DEP-14 branch layout and update debian/gbp.conf accordingly. * Refresh upstream signing key. * Run wrap-and-sort -ast. Checksums-Sha1: aa7fd5a47bbdba6bafe32de9fe3adb18890d3b90 1805 libpam-afs-session_2.6-2.dsc bb0fd10a102f07405bab3c65cc353d4e728e4adf 16212 libpam-afs-session_2.6-2.debian.tar.xz Checksums-Sha256: 8f7a3fc3fd0e2473638d8de67aeb08b521baae6e0d3beb062b767d1433aba713 1805 libpam-afs-session_2.6-2.dsc 54113dcbf9b81968f987ed51bcc5ba3c2f5db137be8384a52ad3263a07756894 16212 libpam-afs-session_2.6-2.debian.tar.xz Files: 8f11256f47f9ffbd51377230f5d9d38b 1805 admin optional libpam-afs-session_2.6-2.dsc 27d564929d16500d2d519a4625372166 16212 admin optional libpam-afs-session_2.6-2.debian.tar.xz -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE1zk0tJZ0z1zNmsJ4fYAxXFc23nUFAluDNAAACgkQfYAxXFc2 3nXNHwf/bDLkUZBZ/iQ89RHxktLSz4TG+JQFy1uVZ0LEs6Lj//pCg5Fuiza912CK EkG6P6MgUmOQB11lo+rIohbcHf52i6Hn0jthZBF4w0+LIK9Uk+XD/9UXNcjcLtuj 9D3qYQd/9la5lvhoLJIaGesukStTEh63qmzX+tB8JfYjosoHlco04biXesVIv4Fn 7tc21O3waYWyR7M5ZTlH+ZozS4XGLIc/f/fpz6/En8FJeJlCcUXdApvYHeVWfX9R PSDKrpp47R0bhtu9oLI+6MxXsRCxdQrUHte5oeMnCaNUY1bca9GXJPJKGaHjYl83 m5E46CyunsT4gZLwkqf7IIqReffWfw== =QMu3 -END PGP SIGNATURE-
Accepted gnubg 1.06.002-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 26 Aug 2018 15:02:10 -0700 Source: gnubg Binary: gnubg gnubg-data Architecture: source Version: 1.06.002-1 Distribution: unstable Urgency: medium Maintainer: Russ Allbery Changed-By: Russ Allbery Description: gnubg - graphical or console backgammon program with analysis gnubg-data - data files for GNU Backgammon Changes: gnubg (1.06.002-1) unstable; urgency=medium . * New upstream release. - Fix cube value when clicking on a chequers tray in edit mode. * Add Suggests on sensible-utils, since sensible-browser is used to launch an external browser to report an upstream bug if wanted. * Remove Suggests of kbackgammon, which is no longer in Debian. * Determine override of __DATE__ macro from SOURCE_EPOCH_DATE via /usr/share/dpkg/pkg-info.mk and post-processing with the date command rather than parsing the output of dpkg-parsechangelog. * Update to standards version to 4.2.1 (no changes required). Checksums-Sha1: 4550aac7b81cdf27ed3d3e21964ea453c0278aa1 1968 gnubg_1.06.002-1.dsc 1f415ab7eb4e308833fe4fd9b9556998261af423 13163681 gnubg_1.06.002.orig.tar.gz 9a15305cd28d55019ef47427a5ee19e27739d0f9 24576 gnubg_1.06.002-1.debian.tar.xz Checksums-Sha256: 2332549bb7dba970504eb7079b34fd51391cde4a541cbffceade8e6b4e73a29d 1968 gnubg_1.06.002-1.dsc ce1b0b0c1900717cc598032a14cf8c0ee60faf24d84368b39922c0102983bc87 13163681 gnubg_1.06.002.orig.tar.gz d0785e74161d2f4fd2d1ce522d23d720a15a19bddd976b490cb3bd22a653540c 24576 gnubg_1.06.002-1.debian.tar.xz Files: dd297e4136d3ed6e5db7f721423bcf46 1968 games optional gnubg_1.06.002-1.dsc d3823526d5c503a961024d761adefd5e 13163681 games optional gnubg_1.06.002.orig.tar.gz 04d13595ec2845216aa7e7341a9acd9d 24576 games optional gnubg_1.06.002-1.debian.tar.xz -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE1zk0tJZ0z1zNmsJ4fYAxXFc23nUFAluDJdYACgkQfYAxXFc2 3nURkQf/X4sBvZGoUVuhCnLfy6x+Wj0rSbXQwFD1k4Eyz0c9m/6bNFmS295fPJPo 9Kdiol8F++dYvDemCHYpuD+XvTPzQK7YJUg2QjOrPyUFP0FRyQzVMN8dTHF/J9sA PBUMIU4D26bKdIQzHZ+KTkH1ioUQHkf9EROVT/jzRUednPSrCSJTRGHzDSwOBy0f EvMNPHtbSerwdRp20ri/B+h/GEP4RsYxa8BPVc+OvIezLmoL8WS65zL8+3CIJYu9 WkQJnEGQKzXlLgQpPPc1owLDI+aN6NgLjaOv5dob9aVdhKyaJW6HBS8hfOokIbxg XXUY0ZLZz+FvVQ6bRgsqJTWDAbWqwg== =/UNl -END PGP SIGNATURE-
Accepted kstart 4.2-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 26 Aug 2018 13:34:55 -0700 Source: kstart Binary: kstart Architecture: source Version: 4.2-2 Distribution: unstable Urgency: medium Maintainer: Russ Allbery Changed-By: Russ Allbery Description: kstart - Kerberos kinit supporting AFS and ticket refreshing Changes: kstart (4.2-2) unstable; urgency=medium . * Update to debhelper compatibility level V11. - Remove --parallel flags, no longer needed. - Remove dh-autoreconf dependency and sequence, no longer needed. * Update standards version to 4.2.1. - Enable verbose test output. - Install the upstream release notes as NEWS.gz, not changelog.gz. - Add Rules-Requires-Root: no. - Use https for URLs in debian/control and debian/copyright. * Bump watch file version to 4 and use https for URL. * Switch to the DEP-14 branch layout and update debian/gbp.conf and Vcs-Git accordingly. * Refresh upstream signing key. * Run wrap-and-sort -ast. Checksums-Sha1: 83e36dafb59590b02763b59aa464c7680c522901 1616 kstart_4.2-2.dsc dc6669b30f0fb0b476045f4f60a8e44e34ddaae9 15196 kstart_4.2-2.debian.tar.xz Checksums-Sha256: f438e616f075ba1b8303700f05a0505c9467e56f0c6f6023bb6b97889be29dae 1616 kstart_4.2-2.dsc 8668a52e82b340304c1db5c0c34a3567c36b5ea53c7a1fe9de398f1f5e07d657 15196 kstart_4.2-2.debian.tar.xz Files: cb599a01d30523e994cd4b9a91d1ceaa 1616 net optional kstart_4.2-2.dsc 1773c383b733ad0bd37d525b57be7360 15196 net optional kstart_4.2-2.debian.tar.xz -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE1zk0tJZ0z1zNmsJ4fYAxXFc23nUFAluDD3UACgkQfYAxXFc2 3nXMdAgAgpObKAjVXUpV9pV16Y+EyFc9zUfuq4fW2CgQ5FF+EhvnItaI/gCCmLin B7fwn/PMm9y4i7+pGHYibT0ilYVwcYFPkvduomg+FRj0L5tPlFOku2Pxf/Weqi1w Xds2glNQ5gGg+i8q6Sx0kkTCWN2ixYq4uCV0NvXNl24FREZzLBfuHeqp7wAn5hyi u35bZw/05xnAb+fY24MQWEwL4XmK0ux6W3NIUWpnPRYmox5EaC7tmDCmzUqGCf58 kxI4+N7/lNl9FNBjAsf3bE7fCgXOa82djsTtAyvPDTPd3NS/m2cGyGYveXB/Ta93 JoMkUUmyzatzsbIo13E19r2zLuoBKg== =k3DE -END PGP SIGNATURE-
Re: Debian 9.5 Installer
Carl-Valentin Schmitt writes: > Apparently the installer compels each time before Installation to delete > hard disk too slowly. > It should be optional to delete (slowly) the harddisk or to format > harddisk quickly. > In 9.5 installer there is no option for formatting without deleting. You can just cancel that step and move on. (But I am also dubious of its utility in most situations, and wish it weren't the default or that at least one was given a prompt first.) I think a better place to file this issue is as a bug report against debian-installer (and I suspect there may already be one). -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Should the weboob package stay in Debian?
Dmitry Smirnov writes: > With all due respect, you did not research the matter enough and neither > am I... Just as I was checking online dictionaries to see if I've missed > something as terrible as you say, I've found that "boob" is a reference > to "embarrassing mistake" or "foolish or stupid person". Evidence > suggests that "weboob" may be semantically interpreted as word play > around something entirely non sexual. > https://www.collinsdictionary.com/dictionary/english/boob > https://www.thefreedictionary.com/boob > https://www.merriam-webster.com/dictionary/boobs > https://www.google.com/search?hl=en=dictionary%3A%20boobs This attempt to manufacture excuses for upstream is absurd. There is a ton of context here, both from the imagery on the upstream web site and the other program names in the package. It's completely obvious that the word "boob" is referring to female anatomy, and the rest of the package is an extended riff on that joke. You can certainly disagree about how important that is or what impact it might have, but let's at least be honest about the obvious intent. Not the slightest hint of mind reading is required. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Bug#903815: ITP: pw -- A simple command-line password manager
Tollef Fog Heen writes: > Assuming it's small enough, using a pipe (or possibly a FIFO) could > work. That's kernel memory and iirc it won't be swapped out. (I'm > happy to be corrected on this, I'm basing it on what I've heard before > and my recollection of it.) There's a Kerberos ticket cache implementation (still a non-standard one, though) that uses this mechanism since it even works across processes if one is careful. It's a really interesting trick, although it has a few drawbacks. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Concerns to software freedom when packaging deep-learning based appications.
Russell Stuart writes: > Apart from the "non-human" intelligence bit none of this is different to > what we _already_ accept into Debian. It's very unlikely I could have > sensible contributions to the game engines of the best chess, backgammon > or Go programs Debian has now. For what it's worth, the backgammon engine in Debian now (GNU Backgammon, which I package as gnubg) uses a trained neural network that was constructed in much the way that you describe (training the network by playing it against itself for substantial amounts of time). It's been in Debian for many years, long before I packaged it. I think it's the preferred form of modification in this case because upstream does not have, so far as I know, any special data set or additional information or resources beyond what's included in the source package. They would make any changes exactly the same way any user of the package would: instantiating the net and further training it, or starting over and training a new network. That may have been a better example to ask about than my scientific data example. (For those who are curious, this is the file gnubg.weights in the gnubg source package.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Concerns to software freedom when packaging deep-learning based appications.
Ian Jackson writes: > Taking a step back: the point of this exercise is to preserve user > freedom. That is, a user should be able to make their computer serve > their interests, and should not be subordinated to upstreams (nor to > Debian or to one of our derivatives0. > A user who uses NASA's tables for astronomical data is not subordinated > to NASA. If for any reason they don't agree with NASA's views on the > orbits of planets or whatever, then they can put in their own figures. [...] > Compare neural networks: a user who uses a pre-trained neural network is > subordinated to the people who prepared its training data and set up the > training runs. > If the user does not like the results given by the neural network, it is > not sensibly possible to diagnose and remedy the problem by modifying > the weighting tables directly. The user is rendered helpless. This is a great argument. I'm convinced. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Concerns to software freedom when packaging deep-learning based appications.
Ian Jackson writes: > Lumin writes: >> 1. Is GPL-licended pretrained neural network REALLY FREE? Is it really >> DFSG-compatible? > No. No. > Things in Debian main shoudl be buildable *from source* using Debian > main. In the case of a pretrained neural network, the source code is > the training data. > In fact, they are probably not redistributable unless all the training > data is supplied, since the GPL's definition of "source code" is the > "preferred form for modification". For a pretrained neural network > that is the training data. I'm not sure I disagree, but I think it's worth poking at this a bit and seeing if it holds up in extension by analogy to other precomputed data. Suppose that NASA releases a database of features of astronomical objects, described as a bunch numeric parameters. Suppose that database is released in the public domain or some other obviously free license allowing use, derivative works, and everything else we expect. However, suppose that data is derived (using significant computational resources and analysis code) from huge databases of observational data. Suppose that observational data is *largely* released, but it's not at all clear what pieces were used to build the database of features, and the code to do so wasn't released alongside the database. Is that database DFSG-compatible and something we could package? (I could see a possible argument that it is but a neural network still isn't if we think about the NASA database as facts about the physical world, however derived, and the neural network as a program. But I think that's an interestingly murky distinction.) Similar analogies may come up with databases about genome sequences. For a lot of scientific data, reproducing a result data set is not trivial and the concept of "source" is pretty murky. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: get-orig-source and standardized source repacking (was: Debian Policy 4.1.4.0 released)
Andreas Tille writes: > My main point is that README.source is just text and no code that I can > run and test. That's different from my proposal. I can definitely see the merits of clear automation the process of transforming an upstream release into a tarball usable for Debian packaging (with the caveat that like all packaging it may require modification for a new upstream release). get-orig-source was not that, partly because it was originally underspecified and partly because people used it inconsistently to solve two subtlely but significantly different problems (as Bill pointed out). As a result, the get-orig-source targets in the archive are a mixed bag and are not reliably (or, and I think this is important, testably) usable for that purpose. Reintroducing the same target with the same name but with a stricter definition would almost certainly make a bunch of those packages buggy. I'm dubious that it's worth disrupting whatever local workflow that they already have around get-orig-source by asking them to rename that target if it doesn't match with new semantics. That doesn't mean it's a bad idea to have what you're asking for with clear semantics. However, I think the best way forward is to have that be something new that has clear semantics from the start. For example, I think one promising way to look at this problem is to define a way to transform a given upstream tarball into its corresponding Debian source tarball, and then one can test that downloading the upstream release corresponding to the current Debian source tarball and running that process on it produces an equivalent tarball to the one used in current Debian packaging. This is *not* what at least the get-orig-source targets I am familiar with did. I think the way to move forward with that is to write a specification that clearly defines its scope and addresses the ambiguities discussed in the original get-orig-source bug report, probably under some new name so that we don't have the problem of making existing packages buggy and so that it's clear whether packages are complying with the new specification as opposed to inheriting some pre-specification get-orig-source target. We can certainly then look at that for inclusion in Policy, although I think it would be worth field-testing with a variety of packages first to make sure a clearer specification is useful. There are a bunch of nasty edge cases in this general problem, and while the specification doesn't need to deal with all of them, it should be much clearer than get-orig-source was about where it's declining to try to handle the problem and where documentation for humans about the process should go (presumably README.source). Personally (although this certainly isn't a requirement), I think this should build on the work that uscan is already doing and should probably come in the form of uscan configuration or supporting scripts that uscan would run automatically, to try to reduce tool proliferation and build on the tool that's already solving 95% of this problem. (Or, alternatively, a lower-level tool that uscan itself, as well as other tools like dgit, can use, and that borrows from the work uscan has already done.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Debian Policy 4.1.4.0 released
Jonathan Nieder writes: > Context: I have run into a few packages that used the +dfsg convention > without documenting what they removed from the tarball and I was not > able to locally update them. :( This is one of the cases that now has a better solution and more standard tools than the get-orig-source target, specifically Files-Excluded in debian/copyright. See the documentation of Files-Excluded in uscan(1). -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: concerns about Salsa
Colin Watson writes: > My experience has been that if I'm working on a complex service then I > want as little friction as possible for the fast-moving stuff that I'm > working on directly and so often end up deploying that straight from git > or whatever, but that I prefer to use packages for everything else below > that layer. My personal experience is that there is an interesting cycle of scale here. If you have a pretty small environment where you're not doing significant local development, tracking the Git version of something, or trying to be on the cutting edge, using packages for everything is best, since it minimizes your risk and most of your attention is going to be on configuration and content. (In other words, the software is just a tool for something else you're doing.) If you then start doing substantial amounts of local development, or are aggressively tracking some upstream package, then it starts making sense to run that one thing out of Git, since that is the thing you want to spend time on and do really well, and possibly uniquely well. It makes sense to use Debian packages for all the other things that form the scaffolding on which it's built, since those things you want to be stable and you don't want to have to think about them. But the thing that you're actively working on you want to be as low-friction as possible. (At this point, the software *is* your product.) However, once you get beyond the scale of a few machines, this starts to break down again because you need a deployment process with stage, canary, and production, some rollback process, synchronization across lots of nodes, and so forth. At this point, you end up having to reintroduce packaging of everything to get those properties. However, it's more common to use containers instead of OS packages once you reach this set of problems, largely because it's often desirable to allow different applications to use different underlying library stacks and not have to upgrade everything in lockstep with dependencies. Once you hit this scale, you often have a lot of stuff, and the tighter of coupling you have between all your stuff, the more you get a combinatorial explosion of problems during upgrades. So mechanisms like containers that can loosen the coupling between your services are immensely valuable. I think people's varying reactions on this thread may have a lot to do with where they are in this hierarchy of scale, and what problems they therefore anticipate. But the Debian Project infrastructure itself seems to me to be firmly in that middle tier where it makes sense to run the core thing out of Git and the supporting scaffolding from packages. We have a lot of things that we're working on directly and intensely as the core mission of that part of the project, but generally they're deployed on one or two machines and don't need management at scale, canarying, and rollback properties. More broadly, one useful way to think about the mission of a Linux distribution is to make all the things our users *don't* care about effortless and simple, so that they can invest all of their energy and attention into the one or two things they *do* care about. Trying to get them to package those few things that they care about deeply is more dubious and often doesn't add much value for them. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: dep.debian.net unavailable now (force HTTPS with wrong cert?)
Boyuan Yang <073p...@gmail.com> writes: > I want to read the DEPs [1] on dep.debian.net and find that > this site has forced HTTPS access with wrong certificate that > is only valid for *.pages.debian.net and pages.debian.net. > Could this issue be fixed recently? It looks like you now want https://dep-team.pages.debian.net/ (probably because the repository migrated to Salsa). -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Accepted tf5 5.0beta8-7 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 26 May 2018 19:03:58 -0700 Source: tf5 Binary: tf5 Architecture: source Version: 5.0beta8-7 Distribution: unstable Urgency: medium Maintainer: Russ Allbery <r...@debian.org> Changed-By: Russ Allbery <r...@debian.org> Description: tf5- text-based MU* and chatserver client Changes: tf5 (5.0beta8-7) unstable; urgency=medium . * Update debhelper compatibility level to V11. - Use dh_autoreconf but disable running autoheader. * Update standards version to 4.1.4. - Use https for Format URL in debian/copyright. * Update debian/watch to version 4 and use https. Checksums-Sha1: c33af121d91fd345671946eb779ce81b27baf03c 1671 tf5_5.0beta8-7.dsc 44a817dec229d2e1b70396217dfe19be66b8142a 12184 tf5_5.0beta8-7.debian.tar.xz Checksums-Sha256: f8e321845c28e1c8f80ad293895a56e92159f20453f56ebaadf944452e7d7416 1671 tf5_5.0beta8-7.dsc 7ac37e9546694c84c70e916d5f1670053d15f92c0656c0691d3d1dfbd7b56f19 12184 tf5_5.0beta8-7.debian.tar.xz Files: 03ba95836cff9e92ae78ca22e1393708 1671 net optional tf5_5.0beta8-7.dsc 086cc223160fde166afdc4ad153b917b 12184 net optional tf5_5.0beta8-7.debian.tar.xz -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE1zk0tJZ0z1zNmsJ4fYAxXFc23nUFAlsKEuoACgkQfYAxXFc2 3nWezAf/fuXoNGyPWzsT+7kNXDdbNl3rhA/zkiSr3sfRLkkSZt+7NDsegFmeSYVo oERoNm6yFvHp24w0hgDbSgngNftvIvIfHUn7wZsL1dkmbH+Vss8jhoqzsl6mIqUo owFH5T0g3S+yoL+CUNhsEleIEWdo9zHAC/5VqIIspgd2t1DAAGaTbl1y2U16pULw rjVDpiQiXCRa8wA1+Zf6nEmxxsLVoZeCAmALJwU7Ljy/rIUokTE8Ymph4WUKtwQi 0HBE9/wWiCne+M/4cpk/ywkRX2QdK6h+3j5zJ6r/V6+6BU6BreEROQmIZYditPAH t1dAZaGBvvZBwbrSXYmWZiS2ybX29g== =TToZ -END PGP SIGNATURE-
Re: make compilation not so gray
Guus Sliepen <g...@debian.org> writes: > Even more helpful would be to NOT display anything irrelevant. When a > package fails to build, I am generally only interested in the error > message, not everything that led up to it, because up until the error > message everything went fine, and the likelyhood that there was any > valuable information up to that point is very small. And, since builds > should be reproducible, once I know there is an error I can probably > start a rebuild myself with all debugging output enabled if I'd think > that would help. For Debian buildds, I really want the full log, because for failures on some architecture I don't personally have, it's so, so much easier to see the full compilation command line with all of its flags and so forth. Often I can fix the problem without needing access to the architecture, which saves a lot of time messing about with porter boxes and setting up a proper build environment there. It would be great to be able to automatically distinguish between important stuff and noise and provide both views, although given the wide variety of different tools we use, it's probably not possible in general. But things like this may be a nice solution for the 80% case. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Accepted libnet-duo-perl 1.01-2 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 07 May 2018 16:59:34 -0700 Source: libnet-duo-perl Binary: libnet-duo-perl Architecture: source all Version: 1.01-2 Distribution: unstable Urgency: medium Maintainer: Debian Perl Group <pkg-perl-maintain...@lists.alioth.debian.org> Changed-By: Russ Allbery <r...@debian.org> Description: libnet-duo-perl - Perl API for Duo multifactor authentication service Changes: libnet-duo-perl (1.01-2) unstable; urgency=medium . [ Russ Allbery ] * Contribute the package to the Debian Perl Group. - Change Maintainer to the group. - Add myself to Uploaders. - Change Vcs-Git and Vcs-Browser to point to the pkg-perl repository. * Update to debhelper compatibility level V11. * Update to standards version 4.1.4. - Use https for debian/copyright URLs. * Use https for Homepage and debian/watch URL. * Add Rules-Requires-Root: no. * Run wrap-and-sort -ast. * Remove debian/gbp.conf and use the standard pkg-perl branch layout. * Refresh upstream signing key. . [ Salvatore Bonaccorso ] * Update Vcs-* headers for switch to salsa.debian.org Checksums-Sha1: 00a32697dcff8bc33b3447b641c9099c2edfe615 1885 libnet-duo-perl_1.01-2.dsc 307c25ebe93498ff236540836bd202f35950a0a6 9192 libnet-duo-perl_1.01-2.debian.tar.xz d10078b934ab9356e645471bb162a623caea6139 91004 libnet-duo-perl_1.01-2_all.deb 6d72de379fd26aa258aac40c4d32ace7a061b56b 7507 libnet-duo-perl_1.01-2_amd64.buildinfo Checksums-Sha256: 8b367b623bb13fa6b3f6c2c0c990ef0a2e89c6ebede608cd20938672dfa9d427 1885 libnet-duo-perl_1.01-2.dsc af3d7c4c1aac8bf21b0f3b6dd1229c6a0cb496d9734b15174ed0c16d58010146 9192 libnet-duo-perl_1.01-2.debian.tar.xz 50d0ae0dffda603985b142d30893fcb3226d91b6aca7ad5699d80f9b08ccadb5 91004 libnet-duo-perl_1.01-2_all.deb d9471157bfd58336a7cb99a39a62795e6bd9ccd9c401187b7a31de8719cc0326 7507 libnet-duo-perl_1.01-2_amd64.buildinfo Files: dfa6b4f8d6e229014ec96d690712acbe 1885 perl optional libnet-duo-perl_1.01-2.dsc aa5b6e3473c3f331dfd1eadb4e50da9e 9192 perl optional libnet-duo-perl_1.01-2.debian.tar.xz 70d95e4816a1df399453e8563329aa8a 91004 perl optional libnet-duo-perl_1.01-2_all.deb 5d29fb04d5107c43f447e674c4ded93b 7507 perl optional libnet-duo-perl_1.01-2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE1zk0tJZ0z1zNmsJ4fYAxXFc23nUFAlrw6VwACgkQfYAxXFc2 3nVKPggAiTZGMrduN/+MQG2/E74KKfToBWwqXoCf96HSsHCNHuiJ0f8wlbZlDY8l 2cgrKhZPl+OAV5S+1hxut0dMXoKkKJNFIXcWOQcD2i4MK/EArGcU3biozg0DNfNs gB6Lsgor/yx/ZPP3npQIAz3434wb5v00m3hnxQvboieqXCt9gssIjThowkDi2U80 RoxuRlw1sxC7FmM44iCjnLeb79sGkn03vgEbHe77fOTuObzEin7UYcvrrBYe7V2d 47Rc/2e54ekcL3IpP079OwJ0ZKX88+QGEcMI6ww7AwkAX9unncHlhHhIUe+WlsbK vyksY4X6EI1nsgH01wZxSsh2hErMmA== =1HtT -END PGP SIGNATURE-
Accepted remctl 3.15-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 05 May 2018 15:30:47 -0700 Source: remctl Binary: libremctl1 libremctl-dev remctl-client remctl-server libnet-remctl-perl php-remctl python-remctl ruby-remctl Architecture: source Version: 3.15-1 Distribution: unstable Urgency: medium Maintainer: Russ Allbery <r...@debian.org> Changed-By: Russ Allbery <r...@debian.org> Description: libnet-remctl-perl - Perl client for Kerberos-authenticated command execution libremctl-dev - Development files for Kerberos-authenticated command execution libremctl1 - Library for Kerberos-authenticated command execution php-remctl - PECL module for Kerberos-authenticated command execution python-remctl - Python extension for Kerberos-authenticated command execution remctl-client - Client for Kerberos-authenticated command execution remctl-server - Server for Kerberos-authenticated command execution ruby-remctl - Ruby extension for Kerberos-authenticated command execution Closes: 835677 Changes: remctl (3.15-1) unstable; urgency=medium . * New upstream release. - Fix possible output truncation for commands receiving data from standard input that exit before reading all input data. - Do more paranoid validation of more protocol elements. - Make a test robust against the first resolved value of 127.0.0.1 not being localhost. (Closes: #835677) * Add Multi-Arch: same for libnet-remctl-perl and ruby-remctl. * Enable basic pkg-perl-autopkgtests tests with a custom control file, since autodep8 doesn't find the Perl package built from this more-complex source package. Don't include the smoke test for now since it requires a more complex setup and execution of the test from the perl subdirectory. * Add the Python import test generated by autodep8 to the package. (Unfortunately, autopkgtest-pkg-python in the Testsuite control field appears to do nothing if debian/tests/control exists in the package.) * Add dh-python to Build-Depends as requested by dh_python2. * Add debian/upstream/metadata file. * Set Rules-Requires-Root: no. * Bump watch file version to 4. * Update standards version to 4.1.4 (no changes required). Checksums-Sha1: 02091ae24b6f1160fc1edcc5729669dd3a385b7d 2711 remctl_3.15-1.dsc 035b4def8872f3c4b11a6c48e120d1821e09ef45 588780 remctl_3.15.orig.tar.xz 4b33386bb2965be320d4bdff184727989c55245f 488 remctl_3.15.orig.tar.xz.asc f85affc1959035afa8dff15327267346f49a443e 26532 remctl_3.15-1.debian.tar.xz Checksums-Sha256: 88d9cfdd4c89e423189b6c165276610eb8e9799181ded19fbf8f6e9f95399474 2711 remctl_3.15-1.dsc 873c9fbba51ff721acb666e927f58f4407f08eb79f53b5a058801f5f404f4db2 588780 remctl_3.15.orig.tar.xz 81cfdcb32fdb73327641363ba19b25f5f586f040c07a9cb0b7867fca37565e1d 488 remctl_3.15.orig.tar.xz.asc ab70996d6b93894eabf199fb14a095700a9f2e73636566f49dcb0b18321396c1 26532 remctl_3.15-1.debian.tar.xz Files: f937ac32ec9e00850f9d73f2c3252944 2711 net optional remctl_3.15-1.dsc 26782e07c81f33d63e17b463fe956194 588780 net optional remctl_3.15.orig.tar.xz c7ae99a4b26f482f4c4e2c3ddd95a830 488 net optional remctl_3.15.orig.tar.xz.asc 04f37f048c0aa3878a45a42034ecfe1d 26532 net optional remctl_3.15-1.debian.tar.xz -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE1zk0tJZ0z1zNmsJ4fYAxXFc23nUFAlruPgkACgkQfYAxXFc2 3nVsCQf+LvU1jPVZriUJttUiNhSxBAmuiDNANIDMNaFrm9jwa1Cu7IZnEw8zymgb TEO57IgiHXFlPKBKJmtXsIuvh8fAL7+ZN+C2oIMbpLtA3KG0csowJw4AVYe6bxj+ GvMV0sCn4bhPOvtGJG+KyEBFgrpY5ehrGtMA4LzSMxoYg1rHhThUL6wXET4esejG qj6+vkh8EtQTn5ITDJJAPgzJiaUWwwYd/QR65wiSFJhkC6Pg/YyOZAXmQ7qIFGye 056fQOcsFuuv3mcLxy6o1F101dGEbmLjrFKa7g0HWu86J7lJ+Vk5Ew2TcNz5saCT ABNqAVS0cy9dGhTfcPYiDZpR45cURg== =uw95 -END PGP SIGNATURE-
Accepted rssh 2.3.4-8 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 22 Apr 2018 10:58:03 -0700 Source: rssh Binary: rssh Architecture: source Version: 2.3.4-8 Distribution: unstable Urgency: medium Maintainer: Russ Allbery <r...@debian.org> Changed-By: Russ Allbery <r...@debian.org> Description: rssh - Restricted shell allowing scp, sftp, cvs, svn, rsync or rdist Changes: rssh (2.3.4-8) unstable; urgency=medium . * Update Vcs-Git and Vcs-Browser for the move to salsa.debian.org. * Use https URL for copyright-format 1.0. * Update standards version to 4.1.4 (no changes required). Checksums-Sha1: 5fc75dab1f10986fdbaf1393f58348213e548e12 1548 rssh_2.3.4-8.dsc 3400780a6d77daf80a4796048d8b1cf20e5e51d9 28092 rssh_2.3.4-8.debian.tar.xz Checksums-Sha256: 72b4f9ba9f11d9e1a01dc818dad6980da33f86bcab98f652566bdac0a209ee91 1548 rssh_2.3.4-8.dsc 5d820eebef3bb5bff4641c6c98d07e20772fc7f4fa72148dd1ea47c737ab8ee8 28092 rssh_2.3.4-8.debian.tar.xz Files: b68c9c00dddfe3f47d8ed56575a838ec 1548 net optional rssh_2.3.4-8.dsc 7da1a032c3bb1dc558f5d4fefa56968f 28092 net optional rssh_2.3.4-8.debian.tar.xz -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE1zk0tJZ0z1zNmsJ4fYAxXFc23nUFAlrczw8ACgkQfYAxXFc2 3nVaaAf9H12n0inWqwOJWaSLYYnWRuPNUgGhCMCmY2VC2Gap8dIlZbtA4XiyFX3H K/2L+uN3tMbcPnzZuA0tAwUVH2W545U3Up+f0XYtTK7VjrCaTlFUVqviqisAq6SH f+6SefNl3JLiALxGXA2vAbkfXlEMGLBPwnxiPqwYoeEaNc2M8lPdvU8lVeUgoB/F OAMaKGQMlH4myVr5NpmCHvOmJ9vMmB8YbZa+3JeSDWeEvUcn3k4AaNL7q8WDlk4v kTQAM9ICjgh7P4JkoVCH/jIVX0+c4voQ75vgOapOHYuM0ec5Cy6mVMExmGlaWeXK MDlOHs0vMolp+Jzwry99yFFcuJOGsw== =mS6u -END PGP SIGNATURE-
Re: Comma in Maintainer field
Michael Stone <mst...@debian.org> writes: > Yes, it would probably be best to specify a restricted subset of > RFC822. Luckily most of the work for that was done in RFC2822, and it > would probably be sufficient to specify RFC2822 "mailbox" syntax with no > "obsolete" elements. Multiple mailboxes can be listed with comma > delimiters. Then if someone wants to get really creative with their > comments and routing syntax, just file a bug. I'd be more comfortable with this (well, RFC 5322 at this point), since this removes a lot of the insanity. However, note that this is incompatible with existing Maintainer fields: RFC 5322 requires that . be quoted. So any Maintainer field containing an unquoted period would have to change. RFC 5322 also prohibits non-ASCII characters, which would have to be encoded in RFC 2047 encoding. I have some experience with RFC 2822 and its various related and successor standards as part of a lot of Usenet standardization work, and I think people underestimate just how complicated those standards are and how different this is from our current practice. This is me waving red flags and saying "here there be dragons, you may not want to go down this path." -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Bits from the release team: full steam ahead towards buster
Russ Allbery <r...@debian.org> writes: > Adam Borowski <kilob...@angband.pl> writes: >> Thus, there are locales where a purely ASCII word sorts differently >> when capitalized and when not. > Yes, including en_US. Just to head off the noise of the corrections for this error, this last should have said "yes, including C." -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Comma in Maintainer field
Andreas Tille <andr...@an3as.eu> writes: > From my understanding the names in quotes should be parsed correctly, > right? Definitely not. They will absolutely break with some tools. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Comma in Maintainer field
Ian Jackson <ijack...@chiark.greenend.org.uk> writes: > I think nowadays we should specify that this field, and Uploaders, are > in RF822 recipient field syntax. I am opposed to this on the grounds that there are two types of RFC822 parsers in the world: correct ones that will drive you insane if you attempt to understand them, and incorrect ones. Nearly all of them are in the latter bucket. Full RFC822 is incredibly complicated and way, way beyond any tool that we currently use for Debian packages. I'm opposed to introducing significance for double quotes in the maintainer field for the same reason, unless it's part of standardizing some rather simple syntax. (I'd much rather just ban commas in Maintainer except as a separator and ask people with commas in their names to omit them, which isn't great but which is very common.) If we're going to change the syntax, I think we need something much, much simpler to parse than RFC822. > We can expect any program which wants to split it into separate > recipients to have a full-on email header parser. I don't think this assumption is at all justified given the number of tools in Debian that need to parse the Maintainer field for various purposes (tracker.debian.org, dd-list, etc.). -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
