Re: New supply-chain security tool: backseat-signed
On Thu, Apr 11, 2024 at 01:27:54PM -0500, G. Branden Robinson wrote: > At 2024-04-11T15:37:46+0100, Colin Watson wrote: > > On Thu, Apr 11, 2024 at 10:26:55AM -0400, Theodore Ts'o wrote: > > > Or, because some upstream maintainers have learned through, long, > > > bitter experience that newer versions of autoconf tools may result > > > in the generated configure script to be busted (sometimmes subtly), > > > and so distrust relying on blind autoreconf always working. > > > > When was the last time this actually happened to you? I certainly > > remember it being a problem in the early 2.5x days, but it's been well > > over a decade since this actually bit me. ^ > > A darkly amusing story of this frustration can be found under "Why > patch?" at <https://invisible-island.net/autoconf/autoconf.html>. I mean, sure - as I said, I recall there being problems in the early 2.5x days - but I will note that the newest release mentioned there was over two decades ago. I'm not really interested in relitigating things from that long ago at this point. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: New supply-chain security tool: backseat-signed
On Thu, Apr 11, 2024 at 10:26:55AM -0400, Theodore Ts'o wrote: > On Sat, Apr 06, 2024 at 04:30:44PM +0100, Simon McVittie wrote: > > But, it is conventional for Autotools projects to ship the generated > > ./configure script *as well* (for example this is what `make dist` > > outputs), to allow the project to be compiled on systems that do not > > have the complete Autotools system installed. > > Or, because some upstream maintainers have learned through, long, > bitter experience that newer versions of autoconf tools may result in > the generated configure script to be busted (sometimmes subtly), and > so distrust relying on blind autoreconf always working. When was the last time this actually happened to you? I certainly remember it being a problem in the early 2.5x days, but it's been well over a decade since this actually bit me. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: About Package Maintenance (was: Question to all candidates: What are your technical goals)
[I'm skipping most of this email because I haven't generally been keeping up with the thread, but thought it might be worth pointing out one thing.] On Mon, Apr 08, 2024 at 06:48:13PM +0200, Marc Haber wrote: > On Thu, Apr 04, 2024 at 12:38:34PM +0200, Andreas Tille wrote: > > Before uploading I usually > > run `routine-update -f` which is just upgrading to latest standards by > > calling Janitor tools and does some other changes to keep up with latest > > packaging standards semi-automatically. > > I wasn't aware of that tool. We need to publish more about such things. > > I am not particularly fond of Janitor's suggestions though. For my > taste, it removes support for older versions of Debian too quickly, and > I have frequently chosen to not accept janitor MRs because this would > affect ability and ease to backport to oldstable or even to > oldoldstable. But that also is a matter of style. I'm not sure how widely known it is, but the Janitor does have a mechanism for overriding the versions of Debian it retains compatibility with based on various considerations, and I've found it useful to land changes there in the past so that its other facilities can still be useful without getting in my way. Search for "compat_release" in https://salsa.debian.org/janitor-team/janitor.debian.net/-/blob/master/k8s/policy.conf. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: finally end single-person maintainership (Was: becoming a debian member under a not-real name)
On Sat, Apr 06, 2024 at 06:32:47PM +0200, Bastian Germann wrote: > Am 06.04.24 um 18:29 schrieb Colin Watson: > > There might be some small errors in this, but I couldn't see any when > > eyeballing the resulting uniquified list of Maintainer fields. It looks > > like 78% of source packages in unstable are team-maintained, which can't > > reasonably be called an "exception". > > https://trends.debian.net/#co-maintenance is the best ressource that I know > for this sort of stuff. Thanks to Lucas Nussbaum by the way for creating > this service! Thanks. Unfortunately this undercounts team maintenance very significantly (by at least 4000) as a result of https://wiki.debian.org/Alioth/MailingListContinuation. Given the timing of that change compared to the sudden increase in co-maintained packages on that graph, I suspect they're mostly being misfiled as co-maintained. I've filed https://salsa.debian.org/lintian/lintian/-/merge_requests/497 to fix this, but even after that's accepted and uploaded, I'm not sure how long it would take to trickle through to UDD; I presume old figures would never be corrected. There's still a discrepancy of several thousand compared to the numbers I found, so I've probably missed something else similar. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Validating tarballs against git repositories
On Fri, Apr 05, 2024 at 03:19:23PM +0100, Simon McVittie wrote: > I find that having the upstream source code in git (in the same form that > we use for the .orig.tar.*, so including Autotools noise, etc. if present, > but excluding any files that we exclude by repacking) is an extremely > useful tool, because it lets me trace the history of all of the files > that we are treating as source - whether hand-written or autogenerated - > if I want to do that. If we are concerned about defending against actively > malicious upstreams like the recent xz releases, then that's already a > difficult task and one where it's probably unrealistic to expect a high > success rate, but I think we are certainly not going to be able to achieve > it if we reject tools like git that could make it easier. Strongly agree. For many many things I rely heavily on having the upstream source code available in the same working tree when doing any kind of archaeology across Debian package versions, which is something I do a lot. I would hate to see an attacker who relied on an overloaded maintainer push us into significantly less convenient development setups, thereby increasing the likelihood of overload. > In the "debian/ only" workflow, the Debian delta is exactly the contents > of debian/. There is no redundancy, so every tree is in some sense a > valid one (although of course sometimes patches will fail to apply, or > whatever). I'd argue that this, and the similar error case in patches-unapplied, is symmetric with the error case in the patches-applied workflow (although it's true that there is redundancy in _commits_ in the latter case). -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Debian openssh option review: considering splitting out GSS-API key exchange
On Thu, Apr 04, 2024 at 06:42:08PM -0300, Henrique de Moraes Holschuh wrote: > If libwrap is bringing in complex libs, maybe we could reduce the > attack surface on libwrap itself? It would be nice to have a variant > that only links to the libc and that's it... Yeah, that's https://bugs.debian.org/1068311 which I linked to elsewhere in this thread. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Debian openssh option review: considering splitting out GSS-API key exchange
On Wed, Apr 03, 2024 at 04:01:34PM -0400, Michael Stone wrote: > To speed things up for those who really want it, perhaps make > openssh-client/server dependency-only packages on > openssh-client/server-nogss? People can choose the less-compatible version > for this release if they want to, and the default can change next release. > Pushing back the ability to install the unpatched version for a few more > years seems suboptimal. I worry about churn, and about inviting more bugs to do with moving an awkward combination of conffiles and non-conffile configuration files between packages. But maybe. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Debian openssh option review: considering splitting out GSS-API key exchange
On Wed, Apr 03, 2024 at 04:38:19PM +0200, Marc Haber wrote: > On Wed, 03 Apr 2024 14:10:37 +0100, "Jonathan Dowland" > wrote: > >For you and fellow greybeards, perhaps: I'd be surprised if many people > >younger than us have even heard of tcp wrappers. I don't think the > >muscle memory of a diminishing set of users is a strong argument, > >especially given it's a preference rather than a requirement, and > >alternatives do exist. > > It is possible to have that alternative not present without being > noticed (for example, a firewall build script failing, but sshd start > nof failing), whilea security measure built into the very daemon is > way harder to be accidentally disabled while keeping the daemon > running. While I'm still not totally convinced, one possible alternative here is https://bugs.debian.org/1068311. That would still mean one more library than strictly needed (once the GSS-API stuff is split out), but at least it would be one small library rather than a big linkage chain over 30 times the size. I could probably justify keeping it in that case. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: xz backdoor
On Fri, Mar 29, 2024 at 09:09:45PM +0100, Sirius wrote: > This is quite actively discussed on Fedora lists. > https://www.openwall.com/lists/oss-security/2024/ > https://www.openwall.com/lists/oss-security/2024/03/29/4 > > Worth taking a look if action need to be taken on Debian. FWIW, just uploaded: openssh (1:9.7p1-4) unstable; urgency=medium * Rework systemd readiness notification and socket activation patches to not link against libsystemd (the former via an upstream patch). * Force -fzero-call-used-regs=used not to be used on ppc64el (it's unsupported, but configure fails to detect this). -- Colin Watson Wed, 03 Apr 2024 12:06:08 +0100 -- Colin Watson (he/him) [cjwat...@debian.org]
Re: autoreconf --force not forcing (was Re: Validating tarballs against git repositories)
On Tue, Apr 02, 2024 at 08:20:31PM +0300, Adrian Bunk wrote: > On Tue, Apr 02, 2024 at 06:05:22PM +0100, Colin Watson wrote: > > On Tue, Apr 02, 2024 at 06:57:20PM +0300, Adrian Bunk wrote: > > > Does gnulib upstream support upgrading/downgrading the gnulib m4 files > > > (like the one used in the xz backdoor) without upgrading/downgrading > > > the corresponding gnulib C files? > > > > Yes, although it takes a bit of effort. You can use the --local-dir > > option of gnulib-tool, which allows overriding individual Gnulib files > > or modules or applying patches to Gnulib files; or you can define a > > bootstrap_post_import_hook function in bootstrap.conf and do whatever > > you want there. > > I had the impression that what Guillem has in mind is more towards > adding dependencies on packages like gnulib and autoconf-archive > to dh-autoreconf, which would then blindly overwrite all m4 files > where a copy (same or older or newer) exists on the build system. Oh, I see what you mean now. IMO it would be a mistake to attempt to do this in such a way that it upgraded only the m4 files and not the C files. Changes made to gnulib modules (which typically consist of some m4, some C, and some metadata) often touch both m4 and C at once; it seems unwise to try to arbitrarily split those up. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: autoreconf --force not forcing (was Re: Validating tarballs against git repositories)
On Tue, Apr 02, 2024 at 06:57:20PM +0300, Adrian Bunk wrote: > On Mon, Apr 01, 2024 at 08:07:27PM +0200, Guillem Jover wrote: > > On Sat, 2024-03-30 at 14:16:21 +0100, Guillem Jover wrote: > > > This seems like a serious bug in autoreconf, but I've not checked if > > > this has been brought up upstream, and whether they consider it's > > > working as intended. I expect the serial to be used only when not > > > in --force mode though. :/ > >... > > We might have to perform a mass rebuild to check if there could be > > fallout out of a true --force behavior change I guess. > > Does gnulib upstream support upgrading/downgrading the gnulib m4 files > (like the one used in the xz backdoor) without upgrading/downgrading > the corresponding gnulib C files? Yes, although it takes a bit of effort. You can use the --local-dir option of gnulib-tool, which allows overriding individual Gnulib files or modules or applying patches to Gnulib files; or you can define a bootstrap_post_import_hook function in bootstrap.conf and do whatever you want there. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Debian openssh option review: considering splitting out GSS-API key exchange
On Tue, Apr 02, 2024 at 12:04:26PM +0200, Marco d'Itri wrote: > Yes, people. I object to removing TCP wrappers support since the patch > is tiny and it supports use cases like DNS-based ACLs which cannot be > supported by L3 firewalls. I suspect OpenSSH upstream would also want me to point out that DNS-based ACLs are supported by Match blocks without needing a separate library. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Debian openssh option review: considering splitting out GSS-API key exchange
On Tue, Apr 02, 2024 at 12:04:26PM +0200, Marco d'Itri wrote: > On Apr 02, Colin Watson wrote: > > At the time, denyhosts was popular, but it was removed from Debian > > several years ago. I remember that, when I dealt with that on my own > > systems, fail2ban seemed like the obvious replacement, and my impression > > is that it's pretty widely used nowadays; it's very pluggable but it > > normally works by adding firewall rules. Are there any similar popular > > systems left that rely on editing /etc/hosts.deny? > > Yes, people. I object to removing TCP wrappers support since the patch > is tiny and it supports use cases like DNS-based ACLs which cannot be > supported by L3 firewalls. It's not about the size of the patch. You could use a drop-in unit to wrap sshd in tcpd, as suggested by the Fedora wiki page? This would avoid exposing sshd's process space to libwrap and all the stuff it links to by default. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Debian openssh option review: considering splitting out GSS-API key exchange
On Tue, Apr 02, 2024 at 03:27:30AM +0200, Christoph Anton Mitterer wrote: > Do you think it will be possible to have still only one `ssh`, `scp`, > etc. command and that will just use extra GSSAPI stuff if installed and > needed by a certain connection? It would be technically possible to retain the client parts of the GSS-API key exchange patch in the default variant. It would require the build to be separated into multiple passes, since that patch touches a number of files shared by the client and the server. Rather than trying to construct this, though, it would be much simpler and I think safer to just have a separate openssh-client-gsskeyex package. Like today's openssh-client, it would be usable both with and without GSS-API key exchange. -- Colin Watson (he/him) [cjwat...@debian.org]
Debian openssh option review: considering splitting out GSS-API key exchange
==
We carry a patch to restore support for TCP wrappers, which was dropped
in OpenSSH 6.7 (October 2014); see
https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-April/032497.html
and thread. That wasn't long before the Debian 8 (jessie) freeze, and
so I patched it back in "temporarily", but then I dropped the ball on
organizing a proper transition. libwrap links to libgssapi_krb5 (via
libnsl and libtirpc), so if we want to do a proper job of removing that
linkage then we'll have to finish this transition too. This probably
means a similar timeline, with the addition that people will have to
make sure that they aren't relying on /etc/hosts.deny being effective
for sshd.
At the time, denyhosts was popular, but it was removed from Debian
several years ago. I remember that, when I dealt with that on my own
systems, fail2ban seemed like the obvious replacement, and my impression
is that it's pretty widely used nowadays; it's very pluggable but it
normally works by adding firewall rules. Are there any similar popular
systems left that rely on editing /etc/hosts.deny?
Fedora dropped libwrap from sshd in 2018
(https://bugzilla.redhat.com/show_bug.cgi?id=1530163), and
https://fedoraproject.org/wiki/Changes/Deprecate_TCP_wrappers has some
other options here (which would need to be adapted for Debian, but
broadly similar approaches would work).
SELinux
===
The fact that we build using --with-selinux has come up
(https://cybervillains.com/@djm/112192735215160932). I haven't formed a
complete opinion on this, but I'm less worried about this linkage than
about GSS-API: it doesn't need much in the way of complex OpenSSH
patches, and the idea that it links indirectly to liblzma seems to have
been a mistaken one that turned up early in the discussions around the
xz-utils backdoor.
My feeling on this is that it's probably of about as much concern as
PAM, which we're definitely stuck with enabling, and I'm not
enthusiastic about adding a matrix of variant packages. We could go for
something like openssh-{client,server}-full, but I'm not clear that
there's much in the way of correlation between people who need GSS-API
key exchange and people who need SELinux support, and I don't want to
force more people than necessary onto the variant that includes an extra
4000-odd-line patch.
For the time being my inclination is to leave this be, but I've seen the
suggestion that pam_selinux is basically all you need
(https://infosec.exchange/@alwayscurious/112192949171400643), so maybe
it would be an option to drop --with-selinux in favour of that? I've
never used SELinux, so I'd need an expert to weigh on here.
Comments welcome,
--
Colin Watson (he/him) [cjwat...@debian.org]
Re: Validating tarballs against git repositories
On Mon, Apr 01, 2024 at 05:24:45PM +0200, Simon Josefsson wrote: > Colin Watson writes: > > On Mon, Apr 01, 2024 at 11:33:06AM +0200, Simon Josefsson wrote: > >> Running ./bootstrap in a tarball may lead to different results than the > >> maintainer running ./bootstrap in pristine git. It is the same problem > >> as running 'autoreconf -fvi' in a tarball does not necessarily lead to > >> the same result as the maintainer running 'autoreconf -fvi' from > >> pristine git. The different is what is pulled in from the system > >> environment. Neither tool was designed to be run from within a tarball, > >> so this is just bad practice that never worked reliable and without a > >> lot of complexity it will likely not become reliable either. > > > > The practice of running "autoreconf -fi" or similar via dh-autoreconf > > has worked extremely well at scale in Debian. I'm sure there are > > complex edge cases where it's caused problems, but it's far from being a > > disaster area. > > Agreed. I'm saying it doesn't fix the problem that I perceive that some > people appear to believe, i.e., that running 'autoreconf -fi' solves the > re-bootrapping problem. Indeed - I've been pointing this out to people pretty much since the xz-utils backdoor was discovered. > >> I have suggested before that upstream's (myself included) should publish > >> PGP-signed *-src.tar.gz tarballs that contain the entire pristine git > >> checkout including submodules, > > > > A while back I contributed support to Gnulib's bootstrap script to allow > > pinning particular commits without using submodules. I would recommend > > this mode; submodules have very strange UI. > > I never liked git submodules generally, so I would be happy to work on > getting that to be supported -- do you have pointers for earlier works > here? https://lists.gnu.org/archive/html/bug-gnulib/2018-04/msg00029.html and thread - it's been in gnulib for some years. (I think you may have misread me as saying that I'd tried to contribute this and that it never made it, or something like that?) > What is necessary, I think, is having something like this in > bootstrap.conf: > > gnulib_commit_id = 123abc567... This is what I implemented, except I spelled it GNULIB_REVISION. Then see e.g. https://gitlab.com/libpipeline/libpipeline/-/blob/main/bootstrap.conf. > > As I noted in a comment on your blog, I think there is a case to be made > > for .po files being committed to upstream git, and I'm not fond of the > > practice of pulling them in only at bootstrap time (although I can > > understand why that's come to be popular as a result of limited > > maintainer time). I have several reasons to believe this: > > Those are all good arguments, but it still feels backwards to put these > files into git. It felt so good to externalize all the translation > churn outside of my git (or then, CVS...) repositories many years ago. > > I would prefer to maintain a po/SHA256SUMS in git and continue to > download translations but have some mechanism to refuse to continue if > the hashes differ. I wonder if a middle ground would be automated commits of translations. I don't think that's as robust, but a number of projects do it (e.g. d-i) and at least it's amenable to having translations go through CI rather than just being YOLOed straight into release tarballs. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: xz backdoor
On Mon, Apr 01, 2024 at 08:13:58AM -0700, Russ Allbery wrote: > Bastian Blank writes: > > I don't understand what you are trying to say. If we add a hard check > > to lintian for m4/*, set it to auto-reject, then it is fully irrelevant > > if the upload is a tarball or git. > > Er, well, there goes every C package for which I'm upstream, all of which > have M4 macros in m4/* that do not come from an external source. Ditto. And a bunch of the packages where I'm not upstream too, such as that famously enthusiastic adopter of all things GNU, OpenSSH. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Validating tarballs against git repositories
On Mon, Apr 01, 2024 at 11:33:06AM +0200, Simon Josefsson wrote: > Running ./bootstrap in a tarball may lead to different results than the > maintainer running ./bootstrap in pristine git. It is the same problem > as running 'autoreconf -fvi' in a tarball does not necessarily lead to > the same result as the maintainer running 'autoreconf -fvi' from > pristine git. The different is what is pulled in from the system > environment. Neither tool was designed to be run from within a tarball, > so this is just bad practice that never worked reliable and without a > lot of complexity it will likely not become reliable either. The practice of running "autoreconf -fi" or similar via dh-autoreconf has worked extremely well at scale in Debian. I'm sure there are complex edge cases where it's caused problems, but it's far from being a disaster area. I don't think running ./bootstrap can be generalized as easily as running autoreconf can, and it's definitely going to be tough to apply to all packages that use gnulib; but I think the blanket statement that it's bad practice is painting with too broad a brush. For the packages where I've applied it so far (most of which I'm upstream for, admittedly), it's fine. > I have suggested before that upstream's (myself included) should publish > PGP-signed *-src.tar.gz tarballs that contain the entire pristine git > checkout including submodules, A while back I contributed support to Gnulib's bootstrap script to allow pinning particular commits without using submodules. I would recommend this mode; submodules have very strange UI. > *.po translations, As I noted in a comment on your blog, I think there is a case to be made for .po files being committed to upstream git, and I'm not fond of the practice of pulling them in only at bootstrap time (although I can understand why that's come to be popular as a result of limited maintainer time). I have several reasons to believe this: * There at least used to be some edge cases where format string mismatches aren't caught by the gettext toolchain. I've forgotten the details, but I remember running into one case where this turned into at least a translation-induced crash if not a security vulnerability. * Like just about everyone, translators make mistakes. Since they're often working with technical text across a wide variety of domains, my experience is that they're more likely to make mistakes when dealing with package-specific terms, and these are often left untranslated, which means that the maintainer is in a much better position to catch those mistakes than you might think. I don't want to cast shade on anyone in particular, but I find that I catch mistakes in a significant fraction of man-db translation updates just by looking at the diff without having to understand the target language; for example, if I add an item to a list and also make some other nearby textual changes, it's quite common for translators to miss adding the item to the list, and I can spot that sort of thing almost regardless of the language. * Actively malicious translations are rare, but they do happen. https://discourse.ubuntu.com/t/announcement-ubuntu-desktop-23-10-release-image-translation-incident-now-resolved/39365 was a recent case of this. I seem to remember that when I tracked down the original files it was fairly obvious that the "translations" had nothing to do with the source strings even without understanding Ukrainian. * If you're faced with a user report containing translated messages, then it's much easier to figure out what's going on if you can just look for them in git. I've found this to be a source of frustration on several occasions when dealing with packages where ./bootstrap pulls in translations. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: xz backdoor
On Sun, Mar 31, 2024 at 10:10:42AM +0200, Sirius wrote: > Not worth boiling the ocean over, but is there an estimate of how many > packaged projects have customisations to their autoconf that is not found > in the upstream autoconf project? If that number is low single digit > percent, it may motivate those projects to upstream their modifications. > If it is double digits percent, it might not be possible to disallow > vendoring the files. This is difficult to answer because it's comparing apples and oranges to some extent: not all autoconf customizations are vendored or would make any kind of sense to upstream. For example, https://gitlab.com/man-db/man-db/-/blob/main/m4/man-arg-config-file.m4 is obviously specific to that project; it's just in a separate file for the same reasons that projects past a certain size don't typically put all their code in a single file. I suspect the question you're aiming for is something like "how many packaged projects have copied autoconf macros from elsewhere and modified them but kept the same file names, so that a naïve attempt to update them would drop those modifications". My guess is that the number here is very low - IME it's much more common in such cases to either rename the macro file to be obviously project-specific or to find some workaround that doesn't require changing the upstream macro - but I've never seen anything resembling a robust analysis of this and I may well have a skewed view. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: xz backdoor
On Sun, Mar 31, 2024 at 09:35:09AM +0200, Bastian Blank wrote: > On Sat, Mar 30, 2024 at 08:15:10PM +0000, Colin Watson wrote: > > On Sat, Mar 30, 2024 at 05:12:17PM +0100, Sirius wrote: > > > I have seen discussion about shifting away from the whole auto(re)conf > > > tooling to CMake or Meson with there being a reasonable drawback to CMake. > > > Is that something being discussed within Debian as well? > > It's not in general something that Debian can unilaterally change. And > > in a number of cases switching build system would be pretty non-trivial. > > What we can do unilaterally is to disallow vendoring those files. > > Does it help? At least in the case of autoconf it removes one common > source of hard to read files. That's doable unilaterally to some extent, using the dh-autoreconf style of approach: the files may be vendored in the upstream tarball, but we'll throw them away and rebuild them. I did that recently for the packages that use gnulib where I'm upstream (e.g. https://salsa.debian.org/debian/libpipeline/-/commit/b596eefb342e93136cf1f479415981fc7f48). Frankly, I suspect that it will introduce slightly more FTBFS bugs over time due to differences between the packaged version of gnulib and the version in use upstream (although things have got better in that regard over the last year or so with the introduction of stable branches), but it does seem to be worth it for transparency. It's going to take some extra work in some cases though. For example, when I looked at groff, I quickly ran into needing https://lists.gnu.org/archive/html/groff/2024-03/msg00211.html. And in cases where upstreams have just copied some individual files from gnulib rather than adopting the bootstrap script, there may be a bigger hill to climb. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: xz backdoor
On Sun, Mar 31, 2024 at 04:14:13AM +0300, Adrian Bunk wrote: > The timing of the 5.6.0 release might have been to make it into the > upcoming Ubuntu LTS, it didn't miss it by much. It didn't miss it at all, even. Ubuntu has rolled it back and is rebuilding everything that was built using it, but it did make it into noble-proposed (the current unstable analogue) for some time and noble (the current testing analogue) briefly. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: xz backdoor
On Sat, Mar 30, 2024 at 05:12:17PM +0100, Sirius wrote: > I have seen discussion about shifting away from the whole auto(re)conf > tooling to CMake or Meson with there being a reasonable drawback to CMake. > Is that something being discussed within Debian as well? It's not in general something that Debian can unilaterally change. And in a number of cases switching build system would be pretty non-trivial. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: ITP: gtk-gnutella -- The Most Efficient Gnutella Client
On Fri, Mar 29, 2024 at 09:28:44AM +0800, Sean Whitton wrote: > On Thu 14 Mar 2024 at 01:29pm GMT, Jonathan Dowland wrote: > > I took a peek, out of curiosity. I was surprised not to find a > > orig.tar.gz / debian.tar.gz split; the package version scheme > > properly reflects a normal (non-native) package (1.2.3-1), but > > the source tarball has "./debian" in it; and indeed, it looks > > like you're managing the debian packaging in the upstream repo. > > It's advisable to keep the two separate. > > Not everyone agrees with this. I think that same repo, non-native > versioning is often what's best for a package. While it's true that some people do hold that position, the problem with it has always been that it gets extremely cumbersome the moment that maintenance of the Debian packaging passes to somebody who doesn't have upstream commit access. This event is traditionally followed by cursing. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Run Debian packaging tasks remotely with debusine.debian.net
On Mon, Mar 11, 2024 at 09:28:06PM +0530, Praveen Arimbrathodiyil wrote: > cat > work-request-ruby-semver-dialects.debusine << END > build_components: > - any > - all > host_architecture: amd64 > input: > source_artifact_id: 788 > environment_id: 154 > END > > debusine create-work-request sbuild < > work-request-ruby-semver-dialects.debusine > result: success > message: Work request registered on https://debusine.debian.net/api with id > 155. > work_request_id: 155 > > log > https://debusine.debian.net/artifact/789/configure_for_execution.log Your environment_id apparently refers to a debian:binary-packages artifact, not a debian:system-tarball artifact. I think this is because you gave it the work request ID of your mmdebstrap job rather than the ID of the artifact it produced. Looking at https://debusine.debian.net/work-request/154/, you should try "environment_id: 786" instead. This sort of mistake is pretty easy to make right now with the low-level interface that we currently have. It'll be easier once we've done a bit more work on collections, at which point debusine will have its own idea of reasonable base tarballs to use for (e.g.) unstable amd64 builds and won't need to be told manually. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: clustalw lost in debian/dists/sid/main/binary-i386/Packages.{gx}z ?
On Mon, Mar 11, 2024 at 01:06:49PM +0100, Andreas Tille wrote: > Yes, I've filed this and this was perfectly intended (even if I forgot > that the bug is done meanwhile which I should have checked before asking > here - sorry about this). It was just that all signs that this package > exists are remaining and its just missing in the Packages file. So > removing a package just means droping it from Packages file and all > other things are cleaned up later on? "rmadison clustalw" shows: clustalw | 2.1+lgpl-6| oldoldstable | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x clustalw | 2.1+lgpl-7| oldstable | source, amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x clustalw | 2.1+lgpl-7| stable | source, amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x clustalw | 2.1+lgpl-7| testing| source, amd64, arm64, mips64el, ppc64el, s390x clustalw | 2.1+lgpl-7| unstable | source, amd64, arm64, mips64el, ppc64el, s390x clustalw | 2.1+lgpl-7| unstable-debug | source clustalw | 2.1+lgpl-7+b1 | unstable | riscv64 So since clustalw/2.1+lgpl-7/i386 is still in oldstable and stable, it has to be kept in the pool; files are only expired from the pool once they're no longer referenced anywhere. (And yes, I think there's a delay between removing references from index files and removing the actual pool files, to avoid mirroring race conditions.) -- Colin Watson (he/him) [cjwat...@debian.org]
Re: clustalw lost in debian/dists/sid/main/binary-i386/Packages.{gx}z ?
On Mon, Mar 11, 2024 at 12:06:58PM +0100, Andreas Tille wrote: > Debci seems to be fine in testing clustalw on all architectures[3] and > according to build logs[4] all should be fine. Unfortunately > >wget -q -O - > http://ftp.debian.org/debian/dists/sid/main/binary-i386/Packages.xz | xzgrep > "Package: *clustalw" Packages.xz > > is empty and I wonder why. Is the Packages file for i386 just broken > or is it me? Search for "clustalw" in https://ftp-master.debian.org/removals.txt: [Date: Mon, 26 Feb 2024 18:19:39 -] [ftpmaster: Thorsten Alteholz] Removed the following packages from unstable: clustalw | 2.1+lgpl-7 | armel, armhf, i386 Closed bugs: 1063063 --- Reason --- ROM; emboss-lib does not support of 32 bit architectures any more -- ... and in fact https://bugs.debian.org/1063063 seems to have been filed by you? -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Run Debian packaging tasks remotely with debusine.debian.net
On Sat, Mar 09, 2024 at 01:43:18PM +, Stefano Rivera wrote: > Hi Martin (2024.03.09_11:43:54_+) > > thank you for this project, it looks very interesting. Would you also > > support running ratt there? For some packages ratt often fails on my local > > machines due to RAM constraints. > > We are building out the pieces that will lead to being able to > reimplement ratt within Debusine. > > Running ratt as a single debusine job wouldn't make as much sense as > running a single build for each changed reverse dependency. Indeed. The high-level goal for our second STF milestone is to add generic support for this sort of automatic orchestration of QA tasks across many packages, and we're currently working on the essential building blocks for this. https://salsa.debian.org/freexian-team/debusine/-/milestones/9 has details, especially anything to do with "collections" or "workflows". ratt as such isn't explicitly one of the funded developers' goals, and we'll probably probably start with automating runs of lintian and autopkgtest. However, I expect in a couple of months we'll have enough pieces to make it possible for Debian developers to build something like ratt using debusine - probably in a "some assembly required" kind of way at first. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Run Debian packaging tasks remotely with debusine.debian.net
On Fri, Mar 08, 2024 at 10:21:30AM +0100, Andreas Tille wrote: > Am Thu, Mar 07, 2024 at 05:06:48PM + schrieb Colin Watson: > > While for the moment Debusine may seem like a less polished version of > > Salsa CI, it has very different goals, > > Speaking about Salsa CI: I would like to do what Enrico mentioned to > somehow re-run building some Salsa commit using sbuild and (optionally) > the autopkgtest on the result. We don't have direct support for building from git yet. Ian asked about that in Cambridge, and it's certainly a good idea though not currently in the funded plan - Raphaël gave a more detailed response starting from around 30:27 in the mini-DebConf video. However, you can always build a source package from the commit in question, upload it to debusine, then start creating work requests from there. (This will become more interesting once we have collections and workflows properly in place; that will allow doing things like running autopkgtests of all the reverse-dependencies of a change you're experimenting with.) > > > > https://freexian-team.pages.debian.net/debusine/tutorials/getting-started-with-debusine.html > > This doc brought me just to creating the chroot. It goes on to describe "debusine import-debian-artifact", which you can use to upload packages to debusine, and "debusine create-work-request sbuild" based on a chroot you've created. We're definitely still at the stage where you have to poke around quite a bit to figure out exactly how to submit jobs, though. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Another take on package relationship substvars
On Thu, Feb 22, 2024 at 09:40:22PM +0100, Matthias Klose wrote:
> Package: libgcc-13-dev
> Recommends: ${dep:libcdev}
> Depends: gcc-13-base (= ${gcc:Version}), ${dep:libgcc}, ${dep:libssp},
> ${dep:libgomp}, ${dep:libitm},
> ${dep:libatomic}, ${dep:libbtrace}, ${dep:libasan}, ${dep:liblsan},
> ${dep:libtsan}, ${dep:libubsan}, ${dep:libhwasan}, ${dep:libvtv},
> ${dep:libqmath}, ${dep:libunwinddev}, ${shlibs:Depends}, ${misc:Depends}
>
> Some of those are undefined depending on the architecture. And most of
> these are unused in other packages, however passing every macro into a
> package, independent if it's used or not.
>
> Not seeing any benefit in this feature (hard failure).
Your examples aren't what Niels refers to as "relationship substvars",
so aren't affected either way by this proposal.
--
Colin Watson (he/him) [cjwat...@debian.org]
Re: Another take on package relationship substvars
On Thu, Feb 22, 2024 at 08:52:36PM +0100, IOhannes m zmölnig wrote:
> Am 22. Februar 2024 20:25:32 MEZ schrieb Boyuan Yang :
> >在 2024-02-22星期四的 19:32 +0100，Niels Thykier写道：
> >> I am omitting Breaks, Conflicts, and Replaces because I am not aware of
> >> any users of these at the moment. I am open to adding them, if there is
> >> a strong use-case.
Once upon a time, dh_suidmanager recommended that people add "Conflicts:
suidmanager (<< 0.50)" when migrating away from it to normal
statoverrides. With your proposal, I can imagine it having made sense
to do that (or at least something similar) using substvars. And while
dbgsym control files aren't actually generated using substvars,
dh_gencontrol does use -DReplaces and -DBreaks when generating them, and
it's not too hard to imagine something similar being needed for some
kind of automatic transition.
I'd include these three fields, if you're going to do this. I think I'm
in favour, as long as testing indicates that it doesn't cause much
breakage.
> While I like the idea in general, I wonder how I could override these
> automatic additions.
> I think there are some packages that even demote `${shlibs:Depends}` to
> Recommends.
That rings a bell, but I can't think where it was.
One thing I've done occasionally when I had no better option is to
postprocess the output of dpkg-shlibdeps. For example:
https://salsa.debian.org/ssh-team/openssh/-/blob/b9671cc7/debian/adjust-openssl-dependencies
https://salsa.debian.org/ssh-team/openssh/-/blob/b9671cc7/debian/rules#L217-219
(Possibly obsolete now - I should check. But anyway.)
If you really had to, then postprocessing debian/*.substvars to remove a
particular field would be simpler than that - probably just two lines in
debian/rules. I think that would be tolerable if the need is as rare as
I think it is, though of course it'd be worth documenting.
--
Colin Watson (he/him) [cjwat...@debian.org]
Re: X-Windows on PPC in Debian SID
On Sun, Jan 21, 2024 at 10:41:05AM -0700, Stan Johnson wrote: > I have a PowerMac G4 MDD (two 1.25 GHz CPUs, 2 GiB memory) that has been > running Debian SID for years. It was last updated on 15 Oct 2023, with > no problems. Yesterday, the update failed. Specifically, "apt-get > update" worked, "apt-get upgrade" worked, and "apt-get dist-upgrade" > worked but deleted ~500 MB of X Windows packages, including Xorg, wdm, > etc. So the system currently is text-only in Debian SID. This sort of thing sometimes happens in unstable due to various dependency issues that are typically filtered out of testing; you're expected to keep a reasonably close eye on what upgrades are going to do and say no if the result is unsuitable. The proximate cause may or may not be sysvinit/systemd. The best thing would be if you still have a record of the terminal log, but it's possible you don't. > This system is using sysvinit instead of systemd, and perhaps that's the > problem? I noticed when I tried to reinstall wdm, apt wanted to remove > sysvinit and presumably use systemd as the init program. What happens if you try "apt install wdm sysvinit" to nudge it into not doing that? -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Mon, Jan 08, 2024 at 03:01:11PM -0800, Steve Langasek wrote: > On Fri, Jan 05, 2024 at 09:17:52PM +0100, Paul Gevers wrote: > > On 05-01-2024 17:36, Rene Engelhard wrote: > > > Also a problem is that experimental also might already contain totally > > > unrelated updates like new upstream versions... > > > I share this worry. Have you thought about how to handle the cases where you > > don't have experimental to upload to? How big is this problem? > > > Another worry, how will you provide the required changes to the maintainers > > of the packages? Via BTS? For those working on salsa: MR? Both? Something > > else? Obviously we should not end in the situation that a new upload goes > > back to the old name (or are the ftp-masters so keen on this transition that > > that won't happen? But what about newer versions with the old name already > > in experimental, conform the former worry?). I've seen NMU's being ignored > > by subsequent uploads by the maintainer, even when they fixed RC issues > > which were then reintroduced. > > I would intend to provide diffs via the BTS. This remains the standard > policy for NMUs in Debian per the Developer's Reference, and as far as I > know has worked effectively for all such previous ABI transitions. In the current situation, though, not having experimental available means that there's no opportunity for dumat to weigh in regarding usrmerge interactions, which seems problematic given Helmut's preliminary analysis. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Bug#1059618: ITP: ssh3 -- faster and rich secure shell using HTTP/3
On Sat, Dec 30, 2023 at 12:13:28AM +0100, Philipp Kern wrote: > On 29.12.23 11:30, Simon Josefsson wrote: > > SSH3 is a complete revisit of the SSH protocol, mapping its semantics on > > top of the HTTP mechanisms. In a nutshell, SSH3 uses QUIC+TLS1.3 for > > secure channel establishment and the HTTP Authorization mechanisms for > > user authentication. Among others, SSH3 allows the following > > improvements: > > I feel like SSH3 is an unfortunate name. The program claims "SSH3 stands for > the concatenation of SSH and H3." - well sure, but you're also reusing the > name of an existing protocol and bump its version. ssh-h3? I agree - as the Debian OpenSSH maintainer, I'm concerned that this will cause a new source of user confusion because people will think "ah, ssh3, that must be better than ssh" (which indeed seems to have been a deliberate marketing choice by this project) and not realize that it's a largely incompatible thing. Not to mention the way that it parses OpenSSH configuration files, which may work today but I doubt OpenSSH offers any guarantees that it won't make changes that will break this independent parser in future. I also feel that something security-critical like this that's labelled by upstream as "still experimental" probably shouldn't be in a Debian release. Maybe it should be kept in Debian experimental for the time being? -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Bug#1041731: Hyphens in man pages
My plan, as indicated in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041731#62, had been to leave things much as they are for most of the period while trixie is in development, and then put the ".char - \-" etc. workarounds back in place for nroff output for trixie's release; this would have meant a higher chance of more manual page authoring tools being updated to handle the groff input language more strictly (although this isn't always easy, as Russ has indicated, since sometimes the input languages of those tools are less rich than groff). However, after wading through an enormous amount of inordinately verbose stuff in my inbox about this, I'm afraid I've now lost patience with the whole thing and am definitely not willing to put up with it for another year or more, so I'm putting the workaround back in place now. Sorry to anyone who will end up dissatisfied by non-terminal printed output as a result. https://salsa.debian.org/debian/groff/-/commit/d5394c68d7 It is still true that being strict about the use of the "\-", "\[aq]", "\[ga]", "\[ha]", and "\[ti]" escape sequences (as opposed to "-", "'", "`", "^", and "~" respectively) will produce better printed output. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: groff warning: TE macro called with TW register undefined
On Wed, Aug 16, 2023 at 07:08:18PM -0500, G. Branden Robinson wrote: > [6] https://man.cx/grog > > I was going to link to > https://manpages.debian.org/unstable/groff/grof.1.en.html here, but > the man page is missing! groff definitely ships it. Any advice? Aside from the typo in the last URL segment, the penultimate segment identifies the binary package, and grog(1) is in the groff-base package rather than groff. https://manpages.debian.org/unstable/groff-base/grog.1.en.html -- Colin Watson (he/him) [cjwat...@debian.org]
Re: groff warning: TE macro called with TW register undefined
On Thu, Aug 17, 2023 at 07:54:03AM +1000, Hugh McMaster wrote: > The man page in question -- ftlint.1 -- is in the freetype2-demos > package [1], or you can get an online copy from [2]. > > [1] /usr/share/man/man1/ftlint.1.gz > [2] > https://sources.debian.org/src/freetype/2.13.0%2Bdfsg-1/ft2demos/man/ftlint.1/ Your problem is that you need this line as the very first line of the page to instruct man(1) to run the tbl preprocessor: '\" t See https://manpages.debian.org/bookworm/man-db/man.1.en.html#DEFAULTS. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: groff warning: TE macro called with TW register undefined
On Wed, Aug 16, 2023 at 09:29:45PM +1000, Hugh McMaster wrote: > This all seems promising. Unfortunately, the man page is hand-crafted, > not generated from another source, so groff is never invoked, and no > other documents are referenced in the file. groff must be run somewhere, because you're seeing a warning from groff. What exact check is failing here (is it lintian, or something else)? Could you please give us a pointer to the man page in question? -- Colin Watson (he/him) [cjwat...@debian.org]
Re: groff warning: TE macro called with TW register undefined
On Tue, Aug 15, 2023 at 10:46:30PM +1000, Hugh McMaster wrote: > Lintian has recently started emitting this groff warning for ftlint.1 > in freetype-demos as part of its man pages check: > > groff-message an.tmac::66: warning: tbl preprocessor > failed, or it or soelim was not run; table(s) likely not rendered (TE > macro called with TW register undefined) I haven't looked at your code in detail, but this sounds similar to https://bugs.debian.org/1042358. groff is most likely observing that you're using the tbl macros but haven't invoked groff with -t, which means any warnings it issues are going to be inaccurate representations of how pages are actually rendered in practice. Your starting point should be to add -t to the groff command line in this check, and then see what else shows up after that. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Bug#1043360: ITP: python-poetry-dynamic-versioning -- dynamic versioning plugin for Poetry
On Wed, Aug 09, 2023 at 04:16:29PM +0200, Jakub Ružička wrote: > * Package name: python-poetry-dynamic-versioning > Version : 0.25.0 > Upstream Contact: Matthew T. Kennerly > * URL : https://github.com/mtkennerly/poetry-dynamic-versioning > * License : Expat > Programming Lang: Python > Description : dynamic versioning plugin for Poetry > > This is a Python plugin for Poetry and Poetry Core to enable dynamic > versioning based on tags in your version control system, powered by Dunamai. > Many different version control systems are supported, including Git and > Mercurial. > > > Poetry is very popular in the Python world and this plugin makes it easy to > use dynamic versioning in Poetry-managed projects. > > Having this in Debian is a prerequisite for packaging of any projects using > poetry-dynamic-versioning. Some of existing packages require this in order to > update to latest upstream version which started using the plugin. How will this sort of thing work when a git tree isn't necessarily available at binary package build time, since buildds build binary packages from a source package rather than directly from git and the source package doesn't usually include a git tree? Is it just a matter of causing the plugin to exist so that pybuild doesn't fail, but in practice the version is still going to be set by something that's actually in the source package? -- Colin Watson (he/him) [cjwat...@debian.org]
Re: systmd-analyze security as a release goal
On Fri, Jul 14, 2023 at 08:08:39AM +0100, Matthew Garrett wrote: > On Thu, Jul 13, 2023 at 08:03:39PM +0200, Timo Röhling wrote: > > qemu is basically an interpreter for foreign machine code. If your > > threat model allows access to qemu-user-static for an attacker, they > > can run pretty much any binary is if it were native, and the whole > > SystemCallArchitectures hardening becomes meaningless. > > My understanding of the threat is that compatibility syscalls (eg, x32 > on amd64) are less well-tested than the local architecture syscalls, and > so allowing apps to call them increases the risk - a compromised app > that can make compatibility syscalls stands a higher probability of > being able to elevate privileges, either in userland or to the kernel > itself. Allowing qemu to translate syscalls from other architectures to > the local syscall ABI doesn't increase that risk, so isn't a concern. > The goal isn't to prevent code form other architectures from running, > it's to reduce the attack surface by preventing calls to the > compatbility syscalls. Not just that, but also using compatibility syscalls allows circumventing other systemd hardening that filters syscalls (RestrictAddressFamilies=, MemoryDenyWriteExecute=, SystemCallFilter=). Allowing qemu also doesn't make much difference either way to that though - if your process can't make a syscall directly, it can't make it via qemu either. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)
On Fri, May 19, 2023 at 09:19:35AM -0500, G. Branden Robinson wrote: > Well, maybe not a strong view, but a sense of vague unease--possibly an > ill-informed one. As someone who has used SIMH for "real" work[1], I > have to ask how someone would conduct an install to a 32-bit x86 machine > running under emulation, assuming no OS on the simulated machine. I occasionally use 32-bit x86 even today (mostly for not very good historical reasons, but nevertheless), and I do it by using a 32-bit container on a 64-bit x86 machine instead. It's much faster to run, and it doesn't depend on installer support. There are doubtless edge cases where you need a completely separate kernel, but they aren't really ones I run into. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Bug#1011666: need help with groff 1.23.0 (1.23.0~rc3-1 package prepared)
On Mon, Feb 27, 2023 at 03:26:52PM +0100, Alejandro Colomar wrote:
> On 2/27/23 13:56, G. Branden Robinson wrote:
> > At 2023-02-26T13:30:58+0000, Colin Watson wrote:
> >> First, move your current branch somewhere for reference, then make a new
> >> one. Then, my routine for pulling in new upstreams looks roughly like
> >> this:
> >>
> >> git-dpm import-new-upstream -p $UPSTREAMTAG^{} --rebase-patched
> >> ../foo.orig.tar.gz
> >> # this imports the unpacked upstream tarball onto an upstream branch
> >> # based on $UPSTREAMTAG, then drops you into a rebase session
> >>
> >> ... continue with rebase as needed, then once you're finished ...
> >>
> >> git-dpm update-patches --amend
> >> # the --amend is just because the import-new-upstream step will
> >> # already have recorded the new upstream on the branch you started
> >> # from, but the history looks clearer if you bundle the rebase with
> >> # that in a single merge commit, which this does
>
> May I ask something from you, Colin? Could you please embed that
> info in the commit messages in salsa? That would help those who
> want to learn Debian packaging from actual practice rather than
> tutorials (I've read and watched many of those, and my confusion
> only grows; I mean, just look at
> <https://www.youtube.com/watch?v=O83rIRRJysA> :p).
>
> In the Linux man pages I write the scripts or commands run to produce
> a scripted or semi-scripted patch, or when some important information
> needed to write a patch was gotten from some script. See for example:
This isn't really analogous to your situation, though. git-dpm is more
like a workflow tool (such as stgit) than it is like a program you use
to generate one-off scripted patches. I don't think it would be
appropriate or reasonable to try to embed this sort of thing in every
commit generated by git-dpm, which is quite a lot of the commits that
end up in my packaging branches.
I'd be happy to write a debian/README.source file, which would be a
better place for this sort of thing. I'm not sure exactly when I'll get
round to it, but I've added it to my to-do list.
> > Please find attached my much more modest proposal. Let's make sure the
> > groff in Debian bookworm will not throw confusing undefined register
> > warnings or drop text from man pages that begin to embrace groff 1.23's
> > new features.
I'm fine with this, modulo sorting out minor commit formatting details.
--
Colin Watson (he/him) [cjwat...@debian.org]
Re: DEB_BUILD_OPTIONS=nowerror
On Tue, Feb 28, 2023 at 11:10:24PM +0100, Philipp Kern wrote: > On 28.02.23 20:34, Steve Langasek wrote: > > But it's not practical to do CI -Werror builds; when we do > > out-of-archive rebuilds for all architectures, it's a significant > > committment of resources and each rebuild takes about a month to > > complete (on the slowest archs). And to be able to effectively > > analyze build results to identify Werror-related failures with high > > signal would require two parallel builds, one with and without the > > flag, built against the same baseline. > > That you are so resource constrained here surprises me a little. I can see > that for Debian, but I'm surprised that Ubuntu is affected as well. > Especially as you'd think that this could also be done within virtualization > - the evaluation here is mostly around running the compiler and checking its > errors, not so much about running tests accurately on real hardware. All Ubuntu builds are virtualized. For most architectures that's OpenStack VMs on real hardware of the appropriate architecture; riscv64 builds currently run in emulated VMs on x86 hardware. I have graphs handy, so I can say that most Ubuntu architectures complete a full rebuild much more quickly than Steve indicated. The last time we did this, we started four parallel full rebuilds on most architectures, and two on riscv64. After these were started, the build queues cleared on amd64 in about three days, ppc64el in five, arm64+armhf (which share builders) in about seven, and s390x in about nine. That's including other normal activity on the same builders at the same time. Some of these (especially s390x) would be much faster except that there are some unreliabilities in the inter-build VM reset mechanism which caused failures and meant we weren't using anything like our full build farm capacity; usually not so much of a problem in practice, but full rebuilds tend to involve dispatching lots of small builds and stressing that mechanism more than usual, and also we were running this over the end-of-year holidays when not many people were around to babysit things. There are definitely various ways we can improve this further, which aren't especially on-topic for debian-devel, but nevertheless this means that on everything except riscv64 Ubuntu can do a single full rebuild in a couple of days (with a bit of fuzz for the small number of multi-day builds in the archive - this is just considering how long the build queues take to drain). The very long pole in the tent, though, is those emulated builds on riscv64, which did indeed take rather more than a month to clear its build queues last time, even though it was only running two full rebuilds rather than four. I don't think we're going to be able to get real hardware with the hypervisor extension particularly soon, but we may be able to throw some more x86 hardware at it soonish to mitigate the problem. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Bug#1011666: need help with groff 1.23.0 (1.23.0~rc3-1 package prepared)
On Sat, Feb 25, 2023 at 11:13:29PM -0600, G. Branden Robinson wrote:
> I've sent you a couple of mails over the past few months, but I don't
> recall seeing a reply.
Sorry about that! Feel free to grab me on IRC if I'm not replying to
email.
> I am not a proficient gbp user, but I think I have done what is
> necessary.
groff doesn't use gbp - it uses git-dpm. If you try to use gbp for it
then you will probably get quite confused and so will I, so please
don't.
First, move your current branch somewhere for reference, then make a new
one. Then, my routine for pulling in new upstreams looks roughly like
this:
git-dpm import-new-upstream -p $UPSTREAMTAG^{} --rebase-patched
../foo.orig.tar.gz
# this imports the unpacked upstream tarball onto an upstream branch
# based on $UPSTREAMTAG, then drops you into a rebase session
... continue with rebase as needed, then once you're finished ...
git-dpm update-patches --amend
# the --amend is just because the import-new-upstream step will
# already have recorded the new upstream on the branch you started
# from, but the history looks clearer if you bundle the rebase with
# that in a single merge commit, which this does
Then you can cherry-pick your packaging changes on top of this, as well
as telling pristine-tar about the new upstream tarball based on the
appropriate imported branch.
If you push the results to a temporary branch on salsa then I can look
over them, which is probably a good idea since you're unfamiliar with
git-dpm.
> How do we move forward with this? I am anxious about the closing of the
> soft freeze window.
There is no way that this giant new upstream release will be suitable at
this stage in the freeze; it's too late. This should be targeted at
experimental.
--
Colin Watson (he/him) [cjwat...@debian.org]
Re: Q: How about versions/features in bookworm?
On Sun, Nov 06, 2022 at 01:58:21PM +0900, Hideki Yamane wrote: > Q3: Does OpenSSH9.1p go into bookworm? I just uploaded this to unstable, so barring any major unforeseen issues I expect this to be in bookworm, yes. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: libpaper and gnulib
execute_java_class, etc.) I think it's nevertheless better than people rolling their own slightly different versions. * The functions that Gnulib tends to provide are basically those that are in libc or little things that lots of upstreams tend to implement themselves (badly). In pretty much every case, equivalent code would be in the package anyway; if you forbid the use of Gnulib then they'll just write it themselves! gnulib-tool only copies the files that are actually used. * One effect that I have noticed in using Gnulib as an upstream is that, because it provides implementations of GNU-specific functions for systems that lack them, I am much more likely to be willing to use those functions. Despite the fact that some code ends up being copied around as a fallback measure (much of it not used when built on Debian, as above), this comes out as a net win as far as security is concerned. I'd much rather live in a world where people use Gnulib and so are willing to use non-portable functions like asprintf, canonicalize_file_name, openat, and so on than our current world which is still full of stupid vulnerabilities due to people getting sprintf or realpath buffer sizes wrong or race conditions while traversing directory trees. ======== -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Firmware GR result - what happens next?
On Sun, Oct 02, 2022 at 03:27:36PM +0100, Steve McIntyre wrote: > * Check/add support for the non-free-firmware section in various > places: > + debmirror (?) Done in debmirror 1:2.37. I guess we need to cherry-pick this to bullseye too? I know bullseye doesn't have non-free-firmware (which is fine, the new debmirror doesn't object), but most people running mirrors probably run stable rather than testing. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: adduser default for sgid home directories
On Sun, Jul 24, 2022 at 12:34:31PM -0400, Matt Barry wrote: > Anyway, its been released at this point, so the issue is moot :) Regardless of the rest of the discussion, this isn't entirely true. Yes, people following unstable will have already seen the NEWS entry and apt-listchanges won't show it again for that version, but it's still possible to edit it retroactively so that (for example) people upgrading between stable releases see improved text. That can sometimes be worthwhile. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Q: systemd-timer vs cron
On Mon, Mar 14, 2022 at 09:29:56AM +0800, Paul Wise wrote: > On Sun, 2022-03-13 at 18:02 +0100, Christian Kastner wrote: > > I don't think that's a very constructive line of argument. As a former > > maintainer, it was evident that user crontabs (crontab -e) are still > > very popular, as are some other perhaps niche features, and I've never > > had the impression that anti-systemd has anything to do with it. > > As a systemd user who has a large user crontab I have to agree. > > I'd like to migrate to systemd timers, but there are a few blockers: Also systemd timers require a session to be running, so as I understand it you have to configure lingering (loginctl enable-linger) for users who want to use per-user timers that aren't tied to having an interactive session (surely the common case). This is frankly obscure - there's no mention of it in systemd.timer(5), and I only found out about it from the Arch wiki. I'm not particularly anti-systemd - there are lots of things about it that I like and use. However, I'm not sure the ergonomics of it weighed up against user crontabs are particularly favourable. Unlike init scripts, for instance, it usually requires noticeably more typing to write a systemd timer than a cron job. The trade-off is that you get better observability and fancier controls over when and how things run. That trade-off usually seems to be worth it for packaged cron jobs, but I have a fair few ad-hoc user cron jobs where I don't feel particularly enthusiastic about it. I'd hate to have to write the release notes entry telling people that they had to use timers rather than user crontabs! systemd-cron provides a generator so that the traditional domain-specific language for crontabs remains available, which seems like a decent approach. I haven't used it, but in general I think the crontab syntax is much stickier than the particular cron implementation. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: DKIM and Exim (was Re: Gmail bounce unauthenticated @debian.org addresses)
On Fri, Mar 04, 2022 at 03:59:09PM +0100, Guillem Jover wrote: > On Fri, 2022-03-04 at 14:36:01 +0000, Colin Watson wrote: > > I reproduced a similar problem, then set up DKIM for myself and > > everything then worked, so I think you're correct. > > > > The links in the original d-d-a email were mostly stale, but I found > > https://bynicolas.com/server/exim-multi-domain-dkim-custom-selector/ > > helpful in getting this going with my local Exim setup. > > You might want to also fix the DKIM_SIGN_HEADERS macro in the Exim > config, as its default is currently broken (see #939808). The patch > attached there is not helpful for local usage, so you might want > something like what I've got in my config: [...] Useful to know - thanks! -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Gmail bounce unauthenticated @debian.org addresses
On Fri, Mar 04, 2022 at 03:15:59PM +0100, Baptiste Beauplat wrote: > On 3/4/22 14:40, Bastian Blank wrote: > > On Fri, Mar 04, 2022 at 12:38:02PM +0100, Baptiste Beauplat wrote: > >> We recently discovered that Gmail started to bounce email from > >> mentors.debian.net with the following message: > > > > Can you please share the complete headers of the bounced message? Aka > > the thing in the message/rfc822 part of the DSN message. Right now we > > don't know what they see from your explanation. > > I'm attached the bounce. > > Am I mistaken in thinking that's only a case of simply rejecting > unsigned DKIM email? I reproduced a similar problem, then set up DKIM for myself and everything then worked, so I think you're correct. The links in the original d-d-a email were mostly stale, but I found https://bynicolas.com/server/exim-multi-domain-dkim-custom-selector/ helpful in getting this going with my local Exim setup. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: where can I find the binNUM informations ?
On Fri, Dec 24, 2021 at 07:40:44PM +0100, PICCA Frederic-emmanuel wrote: > Hello, I am trying to understand a problem in matplotlib on the mips64el arch > > https://buildd.debian.org/status/logs.php?pkg=matplotlib=3.3.4-2%2Bb1=sid > > between 3.3.4-2 and 3.3.4-2+b1 the tests started to failed. > > So I would like to know why this package was binNMU and the difference > between both enviropnment during the build. Since the build were successful, you can find the reason in the build log: matplotlib (3.3.4-2+b1) sid; urgency=low, binary-only=yes . * Binary-only non-maintainer upload for mips64el; no source changes. * Add Python 3.10 as supported version As for environmental differences, I normally find it easiest to start by diffing the build logs and working from there. Something like this: diff -u <(curl -s 'https://buildd.debian.org/status/fetch.php?pkg=matplotlib=mips64el=3.3.4-2=1633211581=1') <(curl -s 'https://buildd.debian.org/status/fetch.php?pkg=matplotlib=mips64el=3.3.4-2%2Bb1=1637459674=1') -- Colin Watson (he/him) [cjwat...@debian.org]
Re: deb822 sources by default for bookworm
On Wed, Nov 03, 2021 at 05:32:53PM +0100, Julian Andres Klode wrote: > On Wed, Nov 03, 2021 at 04:23:52PM +, Holger Levsen wrote: > > You didn't say so explicitly, but do you plan to support old style > > /etc/apt/sources.list until forever? ;) Or do you envision automatic > > migration of that file? Or? > > I don't know, to be honest, have not thought about it yet. > > With APT's 5 year interface stability and major version bump, > The first time we could remove support for old releases would be > trixie/apt 3.0 in 2025 (that schedule just happens because I don't > want to release .10 versions, but keep the 2nd component single > digit :D) > > I think an automatic migration might be to painful what with all the > juju and ansible and saltstack (I feel like it'd be nice to have > those tools migrate config to new formats). > > Of course, once everyone and their dog has migrated, I might feel > different and complain about legacy sources.list and deprecate > them. I think it would be a mistake to ever drop support for the older format. Instructions for using it are scattered all over the place, and there'll be an enormous long tail of things to update, not to mention things like old forum posts that can never really be updated. I agree we might feel different in ten years' time! -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Bug#969631: can base-passwd provide the user _apt?
On Mon, Aug 30, 2021 at 12:30:49PM +0200, David Kalnischkies wrote: > On Sun, Aug 29, 2021 at 11:30:41PM +0100, Colin Watson wrote: > > case) it seems mostly like the sort of user that could be anonymous > > outside of the lifetime of an apt process, analogous to systemd's > > DynamicUser. > > The _apt user started as 'nobody', but quickly people complained that > they didn't want to punch holes in their firewalls for nobody. > > As Julian notes most cases in which _apt creates/owns files are things > to fix eventually, some of which were indeed already, but that is gonna > be hard work and probably not achievable in the short term. Especially > if other lower hanging fruits are still in reach. We are labouring on > _apt for more than seven years now after all. Yeah, I suppose so. > So, while for some/most usecases something akin to DynamicUser would be > enough, for others a more stable user would be preferred and then there > are also cases were it would be beneficial if the user had the same > UID across all systems. And that's exactly the bit that seems tricky to achieve here. If we only had deal with the bits that are internal to apt (as opposed to set up manually by sysadmins) then it wouldn't be so bad. > > But I guess there's no way to do something like that > > outside of systemd, much less on systems that don't run systemd at all. > > The problem with systemd in this context is that apt kinda needs to be > its own systemd --user instance as apt is not a system service, but > a service manager of its own. I doubt the systemd ecosystem offers that > functionality, especially considering that these parts would need to be > platform agnostic and reasonably light given they would be involved in > (cross)bootstrap and all the other situations apt operates in. To be clear, I wasn't literally proposing that apt should use systemd; I don't think that would make sense. It was just an analogy. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Bug#969631: can base-passwd provide the user _apt?
On Sun, Aug 29, 2021 at 11:31:05AM -0700, Russ Allbery wrote: > Colin Watson writes: > > I think it's an interesting idea and worth pursuing, but on the face of > > it it seems that this would end up violating policy 9.2.2: > > > "Globally allocated by the Debian project, the same on every Debian > > system." > > > ... because the UID of the _apt user in fact wouldn't be the same on > > every Debian system, and I can imagine that this might cause trouble > > somewhere. > > My first reaction is that from a strictly Policy perspective you may be > reading that requirement too strictly. Certainly possible, and also it's extremely rare for issues about the global static range to come up at all so we've never really litigated the exact boundaries of this text. > I would read that as a statement of intention, not a requirement: the > intent is for this UID to be the same on every Debian system, but this > may not be the case in practice due to upgrades. (Which seems > obviously true or we could never add a new user.) It's only an issue for users that were already created by some other package (unless you count the small number of non-system users that might conflict with any addition, in the absence of "_" prefixes and the like). This is also literally the first reasonably compelling case there's been for adding a new entry to passwd.master in my time as base-passwd maintainer (since 2002). > That said, it does feel weird to switch to this sort of static allocation > and not have a migration strategy for existing systems and leave them on > an old UID. I know that it's not an explicit design goal of the project, > but I like the idea that continuously upgraded systems will converge on > the state that they would get if they were newly-installed, and that seems > valuable for long-term upgrade support. > > My intuition is also that the case where a UID change will cause problems, > namely: > > > I'm mostly just worried about users using file:/ or copy:/ methods > > and having given _apt access to them, they'd break. > > is relatively rare (but maybe I'm wrong about this?), so I'm not sure that > it outweighs the simplicity advantages of converging on the same UID in > the long run. It does feel likely to be rare, but maybe Julian or somebody else on deity@ can elaborate on whether this is something they've seen much in the wild. A UID migration would also require changing the ownership of (at least) /var/cache/apt/archives/partial, /var/lib/apt/lists/auxfiles, and /var/lib/apt/lists/partial. Maybe something like "find /etc/apt /var/cache/apt /var/lib/apt -user _apt" would make this less fragile, but it still seems like an awkward thing to be doing in base-passwd's postinst. Helmut said in the original bug report that "libapt always chowns it to _apt"; I don't know how reliable this is or whether libapt does it for all the relevant directories. If it's absolutely reliable then maaaybe we could skip that step, though it feels a bit risky. > > I think it'd be best if we don't change existing _apt users, but only > > dealt with new systems for now. I mean we could prompt users about > > changing the uid > > This is certainly a gentler migration, but I think the prompt or providing > some simple migration path would be valuable so that, in the long run, > people can converge their systems to the new configuration. Maybe a > compromise would be to make the prompt have a fairly low urgency level? > We could then tell people in the release notes that if they're not using > _apt in some special way, they can dpkg-reconfigure base-passwd and let it > migrate the UID. Conceivable. I'm not sure how much that would actually help converge the mass of systems, numerically. > > Of course, another approach to the overall problem might be > > declarative user creation in dpkg, e.g. #685734 and > > https://wiki.debian.org/Teams/Dpkg/Spec/SysUser. But that's clearly > > a lot of work, and this change wouldn't preclude it. > > This does seem like clearly the right solution in the long run for all > problems of this sort, though. I wouldn't want to add many statically > allocated UIDs. (But if anything qualifies for one, _apt is a > reasonable candidate.) It's a slightly weird one too, because (aside from the file:/ or copy:/ case) it seems mostly like the sort of user that could be anonymous outside of the lifetime of an apt process, analogous to systemd's DynamicUser. But I guess there's no way to do something like that outside of systemd, much less on systems that don't run systemd at all. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Bug#969631: can base-passwd provide the user _apt?
[For debian-devel readers; the original stated motivation for this bug was being able to trim down the de-facto-essential set by removing adduser from it.] On Wed, Aug 25, 2021 at 09:54:35AM +0200, Johannes Schauer Marin Rodrigues wrote: > Quoting Helmut Grohne (2020-09-06 09:48:26) > > Another benefit of this change (if a static uid is allocated) is that we > > improve reproducible installations where currently uids may depend on > > configuration order. > > I'm very interested in having this bug fixed because of the reason above. > > And there is yet another use-case that would be solved by the _apt user being > shipped by base-passwd: since apt would no longer require adduser, we would > automatically get DPKG_ROOT support for Essential:yes packages plus apt. > > What do we need to implement this change? I observed that when I apply this > patch to base-passwd: > > diff -Nru base-passwd-3.5.51/passwd.master > base-passwd-3.5.51+nmu1/passwd.master > --- base-passwd-3.5.51/passwd.master 2021-07-10 13:57:43.0 +0200 > +++ base-passwd-3.5.51+nmu1/passwd.master 2021-08-24 20:08:52.0 > +0200 > @@ -15,4 +15,5 @@ > list:*:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin > irc:*:39:39:ircd:/run/ircd:/usr/sbin/nologin > gnats:*:41:41:Gnats Bug-Reporting System > (admin):/var/lib/gnats:/usr/sbin/nologin > +_apt:*42:42::/nonexistent:/usr/sbin/nologin > nobody:*:65534:65534:nobody:/nonexistent:/usr/sbin/nologin > > Then not only will the _apt user be created as expected, but I also observed > that when upgrading base-passwd on a system with an existing _apt user with > uid > 100 from basepasswd 3.5.51 to my patched 3.5.51+nmu1, the uid of the _apt user > remained the same as it should. I think it's an interesting idea and worth pursuing, but on the face of it it seems that this would end up violating policy 9.2.2: "Globally allocated by the Debian project, the same on every Debian system." ... because the UID of the _apt user in fact wouldn't be the same on every Debian system, and I can imagine that this might cause trouble somewhere. Is this a serious enough problem to be worth fixing? I'm not sure, so CCing debian-devel for wider discussion. Julian's point earlier in the bug thread was: I'm mostly just worried about users using file:/ or copy:/ methods and having given _apt access to them, they'd break. I think it'd be best if we don't change existing _apt users, but only dealt with new systems for now. I mean we could prompt users about changing the uid I can see the issue there. Adding another prompt that every Debian user will need to consider on upgrade to the next release is pretty undesirable, though - I actively try to avoid that in base-passwd changes. So maybe the policy violation, i.e. ending up with an inconsistent _apt UID on upgraded systems, is in fact the better option? Of course, another approach to the overall problem might be declarative user creation in dpkg, e.g. #685734 and https://wiki.debian.org/Teams/Dpkg/Spec/SysUser. But that's clearly a lot of work, and this change wouldn't preclude it. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: merged /usr vs. symlink farms
On Sat, Aug 21, 2021 at 06:47:50PM +0100, Luca Boccassi wrote: > My recollection (which might be wrong, but a quick look at release > notes seems to support it with 11.04 having multiarch 2 years before > Wheezy) is that Canonical led the way with the multiarch effort in > Ubuntu, and Debian followed with lots of huffing, puffing and > grumbling. As a Canonical employee who was involved in the multiarch design work at the time, this is a pretty unfair-to-Debian version of history. Yes, some things took a bit longer to get organized on the Debian side for various reasons, but the design and implementation work was done in collaboration with key people in Debian and was definitely better for it; Guillem and Raphaël in particular did a lot of hard work on dpkg and dpkg-dev respectively. (Also, several of us on the Canonical side regarded ourselves as having one foot firmly in each camp; I certainly didn't see it as a confrontational sort of thing where we were having to drag Debian along with us - rather the contrary, there was a lot of enthusiasm in Debian for it.) -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Future of /usr/bin/which in Debian?
On Wed, Aug 18, 2021 at 08:50:04PM +0200, Ben Hutchings wrote: > Debian's implementation started out in 1995 or 1996 as a shell script > calling 'type', and remains a shell script. Not very important historical note: it's true that Debian had a "which" command from 1995/1996 or so, but the current implementation doesn't descend from that at all. I wrote the earliest version of the current implementation from scratch, as part of a job I held from 2000 to 2003; in that job, I worked on lots of different Unix flavours, and we had NFS-mounted home directories so I wanted a reasonably cross-platform ~/.bashrc. The spectacular lack of consistent behaviour of "which" across those platforms got in my way, so I wrote a shell script that I could put in my ~/bin and use everywhere. I don't remember exactly when I wrote it, but it can't have been before 2000 and I think it was probably around 2002. I contributed that script to Debian in 2002 in response to https://bugs.debian.org/94507, where it became clear that the previous implementation wasn't really salvageable; Clint merged that in debianutils 1.16.5. It's been extended since then, but still has the same basic approach. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: base-passwd marked as Essential: yes but other packages depend on it being configured.
On Sun, Feb 21, 2021 at 05:22:19PM +, Tim Woodall wrote: > base-passwd is marked as Essential: yes > > However, it actually creates the initial passwd and group files in the preinst > script. > > At least two other packages depend on this initial passwd file but do > not explicitly state a dependency on this package (because it's marked > essential) I think the analysis you're working on here is a subset of that in https://bugs.debian.org/924401, so I'd suggest reading over that carefully before going any further. It has a good deal of interesting discussion. > debootstrap appears to work around this missing dependency by having an > explicit ordering of the configuration of the first few packages, in > particular it configures base-passwd first of all and then base-files, > even though base-files has a Pre-Depends on awk (and debootstrap has to > manually install the symlink for awk) To date it has always been the case that bootstrapping a system requires careful ordering, yes. Any given possible improvement to that process may or may not turn out to be worth it; adding more declarative metadata is often good, it's true, but to some extent the system of essential packages exists because it tends not to be either practical or useful to carefully annotate everything that depends on the absolute core of a working system existing. > I think that passwd and base-files at least should have an explicit > dependency on base-password and, once that is in place any any other > places identified, the Essential: yes flag on base-password should be > removed. What specific problem would be fixed by removing base-passwd's Essential flag? I can't see how it would make anything better to do that; as the base-passwd maintainer I would oppose such a change without a very strong practical justification. That is: let's have a solution-neutral problem statement here. > (I cannot see a way to make base-passwd really Essential: yes other than > bizarre ideas like making /etc/passwd a conffile - which would then > trigger annoying warnings on upgrade and "installing the package > maintainers version" would break systems!) Policy's description of how essential packages work has never really fully extended to the bootstrapping case; in practice, essential packages must currently have been configured at least once before the guarantees in Policy about functioning even while unconfigured truly hold for them. (Section 6.5 almost says this, although the wording is not completely clear. This is still a very useful guarantee for upgrades.) There are a couple of possibilities, both suggested in the bug report I mentioned above): clarify Policy to weaken its guarantees to document what's currently true in practice, or extend dpkg's unpack phase to support something like specifying a file's initial contents in the event that it doesn't exist without making it a full conffile. My own view is: we should clarify Policy now to match current reality, and it can always be strengthened later if people manage to get a more declarative approach working well. I think this is in line with the last few substantive messages in the bug report above. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Debconf - adding "treeselect" type(s)?
On Mon, Nov 30, 2020 at 10:18:05AM +, Steve McIntyre wrote: > Colin Watson wrote: > >On Sun, Nov 29, 2020 at 07:21:54PM +, Steve McIntyre wrote: > >> AFAICS I'd need to add at least basic support for the new type(s) into > >> all the frontends that *can* support it. So, I have a couple of > >> questions: > >> > >> 1. How flexible is Debconf at coping with a frontend not including > >> support for a type?? > > > >Not hugely. The INPUT command would return an internal error with the > >text "unable to make an input element". I think we'll need at least > >minimal support across all the frontends, which may need to inform the > >design of the element. > > Bah, I was afraid you were going to say that. :-( > > For frontends that can't meaningfully deal with a tree (like > showing/hiding sub-trees), I think the best way is to maybe just > display the entire tree and treat it as the equivalent > select/multiselect. It's not great, but at least it should work. Agreed. That shouldn't be too much work. > >How were you imagining Choices working here? > > I'm envisaging treating the Choices *mostly* like in an existing > select/multiselect, but with extra decoration to indicate the position > in the tree for display. It would then be up to the frontend to decode > that and work out a sensible way to display things as best it can. Not > sure on the best way to do the decoration, hoping there'll be an > available special character or similar that we could use in strings to > avoid too big an upheaval here. Since the question type is new, you'd have room to define this. I worry a bit about how in-band decoration would interact with localisation, though - it would be easy for translators to accidentally break the tree structure, and potentially difficult to spot. An alternative might be to have the contents of each subtree listed in a different field somehow. But I'm not sure - it may be worth prototyping a couple of different approaches. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Debconf - adding "treeselect" type(s)?
On Mon, Nov 30, 2020 at 10:24:56AM +, Steve McIntyre wrote: > Timo wrote: > >What are the proposed semantics of this multitreeselect? > > > >If we imagine something like: > > > >[ ] a > > [ ] a/b > > [ ] a/c > >[ ] b > > [ ] b/a > > > >Would checking "a" automatically also check "a/*"? > >Is it only about UI, meaning "a/*" would be collapsed under "a"? > >Shall it be possible to check "a", but uncheck "a/b"? > > Yes, I'm thinking just about UI here: my plan would be to not have > anything *selectable* at "a" - it would just toggle the display of the > "a/*" subtree in those frontends that can display such a thing. If we took that approach then it wouldn't work so well for the grub2 case, where "a" would be a whole disk and "a/b" and "a/c" would be individual partitions. (Unless we rephrased the choices to include an explicit "Whole disk" option or something.) -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Debconf - adding "treeselect" type(s)?
On Sun, Nov 29, 2020 at 07:21:54PM +, Steve McIntyre wrote: > On and off, I've been hacking on tasksel for quite a while to improve > the UI there and add better support for things like Blends. I've made > some progress in my hacking, but I think I've hit a brick wall and I > need to change tack. :-/ > > What I've ended up doing so far is hacking tasksel to give a poor > *approximation* of a tree-style layout: classifying some existing > tasks under headers and building a tree, then displaying each of the > nodes of the tree one level at a time via the existing debconf > setup. It just about works, but it's ugly as all hell and I'm not > happy with where I've got to. I've sunk a lot of development time into > this, but I don't think it's ready to fly this way. :-( > > What I *actually* need here is proper support in debconf for > tree-style selection. I'm thinking of adding that, adding new types > "treeselect" as a tree-equivalent of "select" and "multitreeselect" as > an extension of "multitselect". The first one may not even be needed, > but would be a trivial simplification of the second, so *meh*. grub2's maintainer scripts attempt to emulate something a bit like a tree-style multiselect by putting "- " at the start of the partition descriptions to indicate that they're under the disks. It's certainly not ideal; I'd be open to considering something better, although it might take some time to be usable by packages in general. (tasksel has an easier time of it than some, since it's a full debconf-based application rather than needing to work at the preconfiguration stage.) > AFAICS I'd need to add at least basic support for the new type(s) into > all the frontends that *can* support it. So, I have a couple of > questions: > > 1. How flexible is Debconf at coping with a frontend not including > support for a type?? Not hugely. The INPUT command would return an internal error with the text "unable to make an input element". I think we'll need at least minimal support across all the frontends, which may need to inform the design of the element. How were you imagining Choices working here? > 2. Is anybody actually ever using the more obscure (to me!) frontends > (e.g. kde, editor)? Is it worth spending time there? Although these require manual selection, I think they do have at least some use, and I'd rather keep them going. It shouldn't be too hard to get full coverage, pulling in help from specialists if necessary. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: BinUtils /usr/bin/ld: cannot find -lGL
On Wed, Nov 11, 2020 at 12:59:49PM -0500, Timothy M Butterworth wrote: > I added a symbolic link "libGL.so -> > /usr/lib/x86_64-linux-gnu/libGL.so.1" and that fixed the issue. You should install the libgl-dev package instead of doing this manually. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: CITL Releasing 7000 defects/vulnerabilities
On Sun, Nov 01, 2020 at 03:13:24PM +0100, Xavier wrote: > Ubuntu is based on testing and does not import our fixes after its > release (except a few list), then it's normal to find a lot of > vulnerabilities. It's not really relevant to this CITL list; but just on a point of information, Ubuntu imports packages from unstable (and runs its own equivalent of a testing migration process), not from testing. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: lintian groff-message warning "can't set the locale"
On Mon, Oct 26, 2020 at 08:16:43PM +, Simon McVittie wrote: > On Mon, 26 Oct 2020 at 18:35:53 +0000, Colin Watson wrote: > > LC_ALL should imply LANG > > One thing that it does not imply is LANGUAGE, used for LC_MESSAGES as a > GNU extension (at a higher precedence than even LC_ALL). Indeed, though I don't believe it's possible for it to cause the warning message in question here (which results from setlocale (LC_ALL, "") returning NULL). If all else fails then setting MAN_NO_LOCALE_WARNING=1 may be a viable workaround. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: lintian groff-message warning "can't set the locale"
On Mon, Oct 26, 2020 at 07:57:58AM -0700, Felix Lechner wrote: > On Mon, Oct 26, 2020 at 5:11 AM Nick Black wrote: > > C.UTF-8 sounds like the right way to go. > > As noted in the issue tracker [1], Lintian already sets LC_ALL to > C.UTF-8 [2] in a sanitized environment, but we do not currently set > LANG. LC_ALL should imply LANG, and as far as I know that works fine in man (which is the program producing the warning message in this case), so this should make no difference. If somebody can come up with a reduced test environment in which man does not seem to interpret LC_ALL as implying LANG, I'd consider that a bug. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: DEP-14: renaming master to main?
On Tue, Jun 23, 2020 at 08:14:37AM +0200, Christian Kastner wrote: > On 2020-06-23 02:12, Colin Watson wrote: > > On Tue, Jun 23, 2020 at 01:10:31AM +0200, Ansgar wrote: > >> On Mon, 2020-06-22 at 22:13 +0100, Colin Watson wrote: > >>> [1] > >>> https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html > >> > >> You might be interested in [2] as well. Speculation is often wrong. > >> > >> [2]: > >> https://mail.gnome.org/archives/desktop-devel-list/2020-June/msg00023.html > > > > Good to know, but I think it doesn't really change my conclusions. > > Could you expand on that? I interpreted your conclusions to be > necessitated by what was written in the first mail. Not really. The master/slave metaphor prompted me to think about this sort of thing more and give it a higher priority, that's all. I still think we'd be better off using a different name. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: DEP-14: renaming master to main?
On Tue, Jun 23, 2020 at 01:10:31AM +0200, Ansgar wrote: > On Mon, 2020-06-22 at 22:13 +0100, Colin Watson wrote: > > For a while I'd thought that it was relatively harmless in comparison > > to > > full-blown uses of master/slave metaphors, but I saw some analysis of > > the history recently that pointed out that git got it from BitKeeper > > which did in fact use a master/slave metaphor [1]. > > > [1] > > https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html > > You might be interested in [2] as well. Speculation is often wrong. > > [2]: > https://mail.gnome.org/archives/desktop-devel-list/2020-June/msg00023.html Good to know, but I think it doesn't really change my conclusions. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: DEP-14: renaming master to main?
On Mon, Jun 22, 2020 at 05:50:02PM +0200, Michael Biebl wrote: > there has been a lot of talk recently about how master is a loaded term > that should be avoided. > If I read the news correctly, github and others are going to change the > default master branch to main. > I don't really have any strong opinion on that matter myself. For a while I'd thought that it was relatively harmless in comparison to full-blown uses of master/slave metaphors, but I saw some analysis of the history recently that pointed out that git got it from BitKeeper which did in fact use a master/slave metaphor [1]. > That said, what I care about is consistency and predictability across > the archive. > If we deem that "main" is a better term, should we change the defaults > in salsa/gitlab and maybe update DEP-14? I think my ranked preferences are: 1. devel (for the sorts of reasons smcv@ gave; also, debian/devel is a nice allusion to this list) 2. trunk (historical familiarity from other VCSes) 3. main or maybe mainline (some tab-completion similarity to master, though the confusion with components in a Debian context is unfortunate) 4. further discussion / something else / etc. 5. stick with master I'm not that fussed about the relative ranking of 1-3, though, and I agree it would be good to end up with something consistent if we can. [1] https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html -- Colin Watson (he/him) [cjwat...@debian.org]
Re: bootstrap.min.js in pydoctor
On Tue, Feb 25, 2020 at 05:40:47PM +, Ian Jackson wrote: > (The d/copyright problem with epydoc should be easy if tedious to fix; > I don't understand why it wants epydoc which I thought was obsolete > but this is far from my field of expertise.) epydoc has been unmaintained for a long time, but the API documentation of various projects (notably Twisted) still relies on its docstring format for automatically-generated HTML documentation in a way that would be extremely tedious to replace with something else. As a result, the approach that the Twisted developers ended up taking for pydoctor was to take a copy of the bits of epydoc that they needed and port those bits to Python 3 themselves. (This is second-hand; I'm not on the Twisted team, but I contribute a fair bit there and generally keep an eye on what they're doing since we rely on Twisted at work.) -- Colin Watson [cjwat...@debian.org]
Bug#951184: RFP: libfido2 -- communicate with a FIDO device over USB
Package: wnpp Severity: wishlist * Package name: libfido2 Version : 1.3.0 Upstream Author : Yubico AB * URL : https://github.com/Yubico/libfido2 * License : BSD-2-clause Programming Lang: C Description : communicate with a FIDO device over USB libfido2 provides library functionality and command-line tools to communicate with a FIDO device over USB, and to verify attestation and assertion signatures. libfido2 supports the FIDO U2F (CTAP 1) and FIDO 2.0 (CTAP 2) protocols. This is going to be an optional dependency of OpenSSH 8.2 (optional at build time, I think, though it seems sufficiently useful that I'd be inclined to link against it by default if it doesn't impose an unreasonable run-time footprint), needed for U2F/FIDO support which is the principal new feature in that release. As such I'd like to be able to enable it. I do have a Yubikey 5 NFC which would be suitable for testing this with, and in principle I'd probably be able to maintain this package reasonably well, but I also have a lot to do and would rather give somebody else the chance to take it on first. I expect I'll start work on it in a week or two if nobody else picks this up. -- Colin Watson [cjwat...@debian.org]
Re: Y2038 - best way forward in Debian?
On Tue, Feb 04, 2020 at 06:13:12PM +0100, Marco d'Itri wrote: > On Feb 04, Guillem Jover wrote: > > Well, I guess such a new (conditinally selectable) name could be > > coordinated with glibc upstream? Say bump 32-bit ports to use libc6.1? > > (We already have precedent in some ports that do not use the same > > prevalent SONAME, such as libc6.1, libc0.1 and libc0.1.) But it would > > indeed involve lots of work, with massive amounts of package renames. :/ > > This may be a good time to mention that SONAMEs like libc6.1 are not > supported by libtool, so in libxcrypt I had to conditionally patch the > generated libtool executable for the architectures that did this. What exactly went wrong? libpipeline uses libtool and I've never had to patch it for libc6.1. -- Colin Watson [cjwat...@debian.org]
Accepted six 1.14.0-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 21 Jan 2020 09:44:26 + Source: six Architecture: source Version: 1.14.0-2 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team Changed-By: Colin Watson Changes: six (1.14.0-2) unstable; urgency=medium . * Build-depend on python2 rather than python. Checksums-Sha1: 9a849e566af04da2d0757182a5f3a75dbe40eba6 2426 six_1.14.0-2.dsc 388debc785bff1c7de2e5940247f985381addf9f 4368 six_1.14.0-2.debian.tar.xz Checksums-Sha256: 1655e1f7246bd08332615eb3f6bb7769435724cd60e2ed0c0ce717e1ffd89416 2426 six_1.14.0-2.dsc 02a80f76758dde7a8b2f42cd05a20db56d956f4678a882f0aba905ee49847050 4368 six_1.14.0-2.debian.tar.xz Files: 6b6e7d05543d02b8c54415819d94908a 2426 python optional six_1.14.0-2.dsc 3fd93605111ebbbc2a2456ffe1f0fc58 4368 python optional six_1.14.0-2.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAl4myBwACgkQOTWH2X2G UAsKig//dWgzfZkqdpGcL6Usp6QyZHdxLzKf0LvMQ/EFqcU4EM6+WfvZUDW6agfp PZs58WIOEjZWgWWOSZLDxZ77zq2Q67MNB678S5GtF33GgU3TsLz2/QrvZO2GJxfO zx6Y5O8kN0Kii7qgowePVBJmQ7lEWe81eyn/1JDWOc5PhImkwIj1xoq78WdVcUPb Y97zHtvtQ3yuMDUBq78YOJazCpEFwXfdz9YxvUF4pG2b0/lYor3ae3o8WxqcfU2q 6U1XAerk4X+Dof+7l5MbME+mPVvznzl4gHKAmHuhcG751HT8PVkWlF0EqSgxN3TU gxF0V8muGXU2IAC9sj02Ze2LuJoNocwTjYdNKmWSJxD1T9JblrhKsbJdeGrbHLHz V/5VXlOBaK29rTXYeEFBwFCj2lo61o5cS7haQfGMorIzgAsNB3rUrl9fYW/R3HFA 54yQ2z0AR0vgRXPH08hER+MScGYDv+SMJzc/bw8nokWeOP/IpGDxRKmJREqu3sfb /oFB7pxAK32J8ESWHyByFDQnGYsrxNeDzF4+q+04A+9J3c1kkGKJQLwrYeb+t94b kOwa7CenPcazJ+wlQ3pik2f27HVDDRoIoxdTyPq2OxeqLG5JM/ur7Ct7iWVKWh7h yo2Q9p8Lwk9h7CJ0QD8WEPkUQ9DcZsRV2uf/9zt6Daf0AmAUfJ8= =EEC8 -END PGP SIGNATURE-
Accepted six 1.14.0-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 20 Jan 2020 21:39:42 + Source: six Architecture: source Version: 1.14.0-1 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team Changed-By: Colin Watson Changes: six (1.14.0-1) unstable; urgency=medium . [ Debian Janitor ] * Remove unnecessary team-upload line in changelog. * Set upstream metadata fields: Bug-Database, Repository. * Set upstream metadata fields: Bug-Submit, Repository-Browse. . [ Colin Watson ] * New upstream release. Checksums-Sha1: 11014510e029da1fad89204231d7213fe27a56e2 2425 six_1.14.0-1.dsc 05568b5c867b19e52f5ae1b4989ef21516c58911 33857 six_1.14.0.orig.tar.gz 20ce3f83e8f9b3b64bf1bb4dd0e7a10c9cf610cb 4364 six_1.14.0-1.debian.tar.xz Checksums-Sha256: 88e130ddbf53c72e42650fbfa124fb280c46e90fa61a1ba9da46246ed536e9a6 2425 six_1.14.0-1.dsc 236bdbdce46e6e6a3d61a337c0f8b763ca1e8717c03b369e87a7ec7ce1319c0a 33857 six_1.14.0.orig.tar.gz 95b618ff3241c979b02cf03af2e6001978bea8914e77e1b96635088a1d435917 4364 six_1.14.0-1.debian.tar.xz Files: 84148b32eaed45d78446b357451515fe 2425 python optional six_1.14.0-1.dsc 21674588a57e649d1a6d977ec3122140 33857 python optional six_1.14.0.orig.tar.gz 4e2fbc61e6cfad497780c3a22d2cc338 4364 python optional six_1.14.0-1.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAl4mIS0ACgkQOTWH2X2G UAtnxhAAlp7jeDQDNeshzi9GRlcyqLzBen9D9qXT/+CiLCSZ460Bp1BPorPYbjWd GeAU4mStYqdlWTiXt+3skiEtNlg1RoWMpqHn7tZL/26Jhkj+5MmRHRKks7JQ/AYI UmonVccgCGWPVr6sfLWKvNoF5BdloUF5xstqlEuQLD4xoV/lBSf6XN4QuMUQ+Nhb WNFV1ICtyoXOHfStzRyB1K0xKXh8eTvq7dF/5XKr0Og7gWd38X6MEkXPGxN+c4c7 kyYDdi6H/8boHEAwH/MyrxtaFY309wle0x1XCucU8DB6cg/0LsY9lJ+yM8T6RI7Y X4o0EUWUNxKFuwenWCsSy13WSM6ZR7SWTI5VFxmkzHBCld4E8SmkiLmRAMSJzrL8 BjOI+rab3YjMQ9emq1sWOESDRrPE+SQj4WAyMXTPYtdahuJxX7WNxEyANyx1g+Aq EnJQcX6dXzPV2CwP3cKQ/TFqWb9JzKjd4gQdKlM/gALYtD6cRcjvVV5in/TQ2ufX LzHFot+KAmwHQAjYpy/Q8cO5L3/3gbz4NvwmdavpJdG2Bdi7XgjE5l937Fy7rYu9 LjZ3Q2PX/cnRjhYRs9L2HHZpIzQvHrr1J6yj7wgXS8f02TlW2925GalVw5/JIdXn KNtByBlaZK4PuVzL39Ug8b4jiAZFuLkLsD7PG3OeilgzDRPNVgY= =gtws -END PGP SIGNATURE-
Accepted parted 3.3-3 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 19 Jan 2020 22:35:35 + Source: parted Architecture: source Version: 3.3-3 Distribution: unstable Urgency: medium Maintainer: Parted Maintainer Team Changed-By: Colin Watson Changes: parted (3.3-3) unstable; urgency=medium . * Fix chromeos-kernel-flag.patch to patch include/parted/disk.h too. Checksums-Sha1: a9b70df9362d7e3a71235ff4edcaabdd414a5a68 3145 parted_3.3-3.dsc fbb1a9495998ad724db0757f59c1ccf989a18ec5 58100 parted_3.3-3.debian.tar.xz Checksums-Sha256: 6c8d03751ffcd718c62f174055860e49e9d2786f76fa4f5ad83e00d54f5e27bd 3145 parted_3.3-3.dsc 65ad4b810d0f562c2f9c7393e20be645f78d278b85a40c458e43be6f766e5270 58100 parted_3.3-3.debian.tar.xz Files: 4b1814263dfdd3a00d861c5ebbce4971 3145 admin optional parted_3.3-3.dsc 53402834e1b14da2ac22e86d704bf163 58100 admin optional parted_3.3-3.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAl4k2kAACgkQOTWH2X2G UAt0ShAAmTlvo4sr8yDAeuVVEAEQqKlK0nnaVEudAbZuCj82cd39Nwv8oHO27Wwp or3aFmxCdyJLSM2if4pFsT4iaXNOxoTL197juJsTtLGbn1scTDVMZ4kp6RiHPMlz t8CwP+7Uz3nLIp86R2ER3TY5C6S10P1jSuHwwzRKNCHUch7xsowrD4/wiRg/hv14 dxWlmwe+m5e3Ae2JUMX2b+wtJkeDYKdj7fKSYn0t5l33knnwwviwhir253+g6kUR 0BgpcdWBA+UCFxjM1AkNr7Mjwflr53YNZcPyvZo4kmnT6Afx9+qZHkh5EqdeKYTY qkr4ps6PaCGfg/mroDXMDUuBnvDnO39Hx2qFiHsSay5zTe+4gq4dObYz6c2BaQPi 85Qa9+dN6IYI7u1ohR3dhPXMnOIFKbguy0mFOzMnmsDChMPm3ETfiC1J+/VPLyO+ X8CNilJh/iaprCtGL7Ind3EsuRG2HUNNMbwVbt0mpCCZbv1wqIrEc66b9+w9++wR hpI5lwGqKe0pl3UtW2u6wQGWA7c6ary4ET4zEK1hEjGtuwVqGAoQP8Kgg7zWtWtf 1p6Mnlox1qWVhz1gX3k7SekYEqZCPAAkEwGVrVVSA8nMFbvnh0BrQ9yKIslLW3sW 34d1lBKpFxxPI8kFfXKNcHO/5S0v9ZAX4aj5atHz9DU0FX4UabY= =ktvz -END PGP SIGNATURE-
Accepted parted 3.3-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 19 Jan 2020 21:37:10 + Source: parted Architecture: source Version: 3.3-2 Distribution: unstable Urgency: medium Maintainer: Parted Maintainer Team Changed-By: Colin Watson Closes: 949316 Changes: parted (3.3-2) unstable; urgency=medium . * Cherry-pick upstream patch to add a GPT-only chromeos_kernel partition type flag (closes: #949316). Checksums-Sha1: 0dce5671f9cfbbd1fe4fd9f3198bf79582a1d4dd 3145 parted_3.3-2.dsc c2226fe77712925a61d91b44ca5f8a829273b7c4 57980 parted_3.3-2.debian.tar.xz Checksums-Sha256: d19da96cbb27f280421e28759a9c5dae381e88f38dcde918aff25a3f051f9eee 3145 parted_3.3-2.dsc 0a4abfa9b71ff06b56254bad5541ab692e289818fdb35dec8437d417db307b98 57980 parted_3.3-2.debian.tar.xz Files: af42cff08ad2a98598248a42ffbf8b4a 3145 admin optional parted_3.3-2.dsc fbc2d7c985ad8ed86ce21b30547953ba 57980 admin optional parted_3.3-2.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAl4kzDAACgkQOTWH2X2G UAudChAAjaKgf9mqDRoSbjR8mGJDSsOJHNf+5Y6AU0Otxx/3X/aWG4MjaOZFrLkh HAvRvWdnG6cBmUjBj7a+COufTyIbTvoS/QTQKCQ66gzldjh9rmXlcFteQqtAZMNb iQ/FT6veztOBIh/i9o0KGgG0xnDkJ4oIBbBubEm/UdIFgMhpqwwQAgCNECzzlX9i zDxCv4HUuNSAB9DdcFNZQNVBnndVkKWQ2Ga5V6jfWus+TdPBEHMkeTLXWNuXoHUM in9pD1EOzaYi11QdozgDxR8Z519k9/hAUQlJVAGKFvvTBp6SmTYidnTBkzo7HDqw wlNbIWatfcOcYLNoRNQTybtnE2UUZiwWJuhLZDwDVlwmWj2eDtQCe5dXyi7vLXu6 /pSxH9h1RvkZ74CJkmNoIZDav0alwnMWv4VfcCrMkZDJDLozDq+cESWvtdsyR/Ei XS7bKwAXhtNpJJJhkQqbN46+u8ap0YCpP+fFgCHQTajEXbyAVQ5eOaBp9Ctvwhpr O355g7xrjTK6RmoZ7Bqs1WyRPR+7Fr9XDtstcQwFDM67QwoxGf/0F4AdjD+qXRx8 aESr5e1HexFuGuwvCqlCBQSiVEFwj9xhBWkUla1vjP036h6dJEg3nIJoHMySm0+9 hylEz9dd3KcHqWxt4V+tSVR0//jlHtT6yZHmKsdF/eG9b+E1dL8= =eYT8 -END PGP SIGNATURE-
Accepted madison-lite 0.26 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 12 Jan 2020 18:41:44 + Source: madison-lite Architecture: source Version: 0.26 Distribution: unstable Urgency: medium Maintainer: Colin Watson Changed-By: Colin Watson Changes: madison-lite (0.26) unstable; urgency=medium . * Use debhelper-compat instead of debian/compat. * Mark madison-lite as Multi-Arch: foreign. * Policy version 4.4.1: no changes required. Checksums-Sha1: a64ac1a9c06afa206cb73d83dd73f299914d255d 1651 madison-lite_0.26.dsc ca2ef57ec96e8ceee92b68fe4c9142f4d6774ebc 13584 madison-lite_0.26.tar.xz Checksums-Sha256: edcee05d705172b473f7f85d873470cba18e3a54d3252a23009072a113ff17c7 1651 madison-lite_0.26.dsc 147d07e689ccffd325f5b44fa4a280eb548a9c62d3661be4f7ac9aec103e571f 13584 madison-lite_0.26.tar.xz Files: bd4dd20382da9cf8d0bbe63824357f19 1651 admin optional madison-lite_0.26.dsc 40b05acf88fb5e46e695c0076e549cf7 13584 admin optional madison-lite_0.26.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAl4baIYACgkQOTWH2X2G UAuWYw//X0D5fUDUaiJZ0TJ3eEROUk5Au9wDYHkV80XXgb53p7oo5eCMMH3TIn/i nonRXpRWRNfBVmUyCeGbSIKmo24d9YBzBdSVMnb3+52couD4ebV7Mok+Oa5cfvIz 43a0ghD+YHGmTcfP7/IwAYJbbMEcOVfDyNrq97ql6fXGKFRDs9+awk/dRci+6NlK 9qg7Lt1kC6WHlKj7nIl/sBFGKLnkKy1Weus5hF9k5x2lsWFeaR1xEkSlz67sWTtf CPtaJDFLNchsOhVkvgI0it9YDuwjgOVxdqaeVTfDldQvIme0bIT4uaxPPejos6JC lwqzL7yDK5YDavcI5Wk8pjUlduGUIu3lrsJKBu0+1qLKbPLuL9GM/tcMJPMn7ZYv ya53aOGHGnIsaGwJZTql36VwRzzme1IeBA7innfwWYuezIw9jY6R7Jev+OABYvH7 r2rAxpS1FuFi+i6x3KO5N6Tj8NLl2DPi0d7qed5gud21vtJvWes0xnVn6hWuFzcH UvTJ0RGsNudDYyatFA2NfKpkWUu8IfzTEhvEtsOtA5R25Rq92bcDEpNLOyPV/t3a QfEIhlfuBKMMQqxp38Sh2EhPY1Udxbgrt8KC/91r0UYN5LMyzn2caqeIyXOi/axT XWuvF0SYkru1OGv2EIM3bmOQ/E8D2GRX0CHUyckHRkM/1PJRhkA= =E70V -END PGP SIGNATURE-
Accepted openssh 1:8.1p1-5 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 11 Jan 2020 23:55:03 + Source: openssh Architecture: source Version: 1:8.1p1-5 Distribution: unstable Urgency: medium Maintainer: Debian OpenSSH Maintainers Changed-By: Colin Watson Closes: 946242 Changes: openssh (1:8.1p1-5) unstable; urgency=medium . * Apply upstream patches to allow clock_nanosleep() and variants in the seccomp sandbox, fixing failures with glibc 2.31. * Apply upstream patch to deny (non-fatally) ipc in the seccomp sandbox, fixing failures with OpenSSL 1.1.1d and Linux < 3.19 on some architectures (closes: #946242). Checksums-Sha1: 416b9a792df5167dfcfc7aee930af6fd9c5a3ba6 3316 openssh_8.1p1-5.dsc a0d2e4f5014b0c7420a6e32ae44adcb1373f4aae 173076 openssh_8.1p1-5.debian.tar.xz Checksums-Sha256: 9e3faf5dae122bc3ea7a5cff4a55e6af2bcdd6d77ab21f65b9e45e4872b56d13 3316 openssh_8.1p1-5.dsc a4a3b7580e5ddb22c07d64e8d72faf67cf65541207dd473717d4175d55590004 173076 openssh_8.1p1-5.debian.tar.xz Files: 50f206cf5b04641d4c33bf9badbc7140 3316 net standard openssh_8.1p1-5.dsc 3815394fd58bed3b885b4c822b2b33ec 173076 net standard openssh_8.1p1-5.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAl4aYIcACgkQOTWH2X2G UAsl+w//XJCpdXy/doBDA2OO18HfFRoi8aDtIbjFyYc14L8xCbfzwjGUTg8z0YU8 BtpZrZUZlpZHRubE7A91UN/WI5yyy5Z4tBrM+nls38twvK3F51keqzDWSeXdEO39 WiTC5C51NYCkz8WYkwf3r+6CKfPdEd7uvTCqHnSofFei/siZK2vblnB1x6w3555j dsrW13Gjsp+Kqy1pj3ZFl4+ep5j/yOhl9lXhEDRT5ZiADSaugiq40cBPWZblTkm8 cauXDvcShfIM7evrjzuskoYFr2leXhJc16vqCJsKYGmrf+JJnQdk0gSmxEvkf5g6 KWZFutkeB41e0V/LGZgOZzd5rO0WxQT9ROV9RI0aMF0L7qcDhk/zNjVzrcSdEfRi m0l3TWZG/SHRgg5vCFAwAeotjzxD+pRxS0KVDwwR2eGSkynv3M5uwlaN8bwj4igJ ks2or2xWqOy0BoiBppyviL0+2fnT2LWiFL/fIlPdSpJ8VNpGuEuANpJuwh2K7oNB amcb63T0nTV8pVlgLXCbreyrlc50cXy0EKlOFpjI3rKL7VUfE1BsfvI1CWbDafd2 4OyNfgJpj/ntwjMEPmCybkSf1NqyHlj+zLeoAjVLo2XK4go81rdJyQ6bKtZawKjQ ivPTr+0kTW7fFG2hP37iGRZGN8H0nqD27CmF7PK8SPDEhiClPJ0= =Olg7 -END PGP SIGNATURE-
Accepted python-libnacl 1.7.1-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 10 Jan 2020 00:00:35 + Source: python-libnacl Architecture: source Version: 1.7.1-1 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team Changed-By: Colin Watson Closes: 922259 Changes: python-libnacl (1.7.1-1) unstable; urgency=medium . * New upstream release. - Fix unreliability in verify tests (closes: #922259). Checksums-Sha1: 7e246594e5c64b38d0c99cfb21f913c62265e3ea 2235 python-libnacl_1.7.1-1.dsc d725b9ada21d8e48c054c74df9524d10d2e4e503 41186 python-libnacl_1.7.1.orig.tar.gz 271a0b0838cedb1aded6f034495ad8a997d86576 2464 python-libnacl_1.7.1-1.debian.tar.xz Checksums-Sha256: f4dd8160fb1b0825fcf6d83a264a0b75acad3db01a414189d327243aa4abf3c7 2235 python-libnacl_1.7.1-1.dsc 33f31c4686541aee24876706b46a846f93c60e62d6b4211bc16bd08ba71d8fb8 41186 python-libnacl_1.7.1.orig.tar.gz 2f3e002019c599ff08794e8fbfcc8a2a65449227e49729a9830741f201262ca2 2464 python-libnacl_1.7.1-1.debian.tar.xz Files: 47e20918a7deab04d370936db3521430 2235 python optional python-libnacl_1.7.1-1.dsc 2bfba5658837a330fe962f0b9464998b 41186 python optional python-libnacl_1.7.1.orig.tar.gz 93ca591f319704f1c0bed243fc866fa7 2464 python optional python-libnacl_1.7.1-1.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAl4XwIYACgkQOTWH2X2G UAtK1w/+OaNBrJziOrH+2x7RzeznuXmFrbKgOR7gdnvYkgLqb+G68isyjp7kCAnB nojepANOeJN/96kWaIboHLz8PWdGhmoJMQpvvxXAQHyedx01WZkLIE9+1CJDWG3N JOPJykQoMDK8/YJKKPwOsta85SAsmp9qSm2Dn7PDV6/DcLYbLc92S+BPL590bGYp 0pbhJKnyTvZJfqrxfiGqAxTlOtQucuA8WpoeFpj9mvm0zDXT55drPp1L/rbGZHxY 91G+xaIWkZo/Oufhgf9gyYlCxGDPDDLA2KvdtW5K7S1oak8hNH+7aGs2sHkTJC3W MkrNTXdgKgxA3NocoMfUKPRP+BZU6X5mt02Wb1/5gm6JTive1kdzHU3xN3EkxunK gtyLq3jcIDbrYc5arl8TTFccbvJQVwL1D0NudzDu2G3SQF0r0wFxaf97xgswe0GG bym2u8w6hb89agMjt0nESMLdj5sFYG7WPkfQVoMSZiZU+3rDoENylAwK1U2OJf0I xOFxa7Iq2/nFlTNYWyyhUdMb662+QRKBVOuPgEqQWA5uyMBm98v2ACZdzFVlDGwi 8Z0LzCn7kvHuU25HflWVcn3zlz6fV7TeCgkuXKhVXRPV1VU+xvosnQ6YjwxvaQK5 YFlncZMxSP8BnQjQVXpdtt72BqM0bTwahm0Jn/d4omHQD+zEg2Q= =4kyT -END PGP SIGNATURE-
Accepted libpipeline 1.5.2-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 09 Jan 2020 17:14:23 + Source: libpipeline Architecture: source Version: 1.5.2-2 Distribution: unstable Urgency: medium Maintainer: Colin Watson Changed-By: Colin Watson Closes: 948515 Changes: libpipeline (1.5.2-2) unstable; urgency=medium . [ Colin Watson ] * debian/copyright: Refer to gl/* rather than gnulib/*. * Add a debian/upstream/metadata file. * debian/copyright: Update copyright dates. . [ Steve Langasek ] * Make autopkgtests cross-test-friendly (closes: #948515). Checksums-Sha1: c921b762a973e3990df982b6ac364f6ab2f20242 2438 libpipeline_1.5.2-2.dsc f354add7604a1ab3c1eb3a8dbdf4d88a215cc607 9556 libpipeline_1.5.2-2.debian.tar.xz Checksums-Sha256: 4a6afb6118076a43d51c104e0de4343141aed77550e372d53c350612d0569106 2438 libpipeline_1.5.2-2.dsc 68a5ff619dc067783a14e9215f9a3197dfd8737bca077f6984ab0c48bc7d04ba 9556 libpipeline_1.5.2-2.debian.tar.xz Files: 6e53d23b068efa7e0b9e3ab6d39c7c3c 2438 libs optional libpipeline_1.5.2-2.dsc 9b0623070226ac87535263b98eabbf16 9556 libs optional libpipeline_1.5.2-2.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAl4XX5IACgkQOTWH2X2G UAso5g//VqdHcOGKTYorv7NFyipx5t0I2K4bl3HM4rDYH/nAGloMDgPnQfJQUEXT OuJyLuLVET7+SWJS3RtbLiCdy+L905FfEVa6TKUYR3OlMC3BuAnhNecJRmVpwWYJ u+Dw+jD/gV6xReg38R3WnmKSLpJXRyNnTqO4riQLxF+LbhewowIL2Z3FKJFpN28S olzrNSmav3eaICQ4UnxNVaKjHbpgjDVCk6VTyC4WvK0wVQAROH9hVPx61P//VcpS m2hyMGq7H+SZve1GnksS2BBjWs5rxOQhVyfwcXI8FCSjWOnEd2rfC6S07+RBgtPA FDJorSZnxA4sLi9X1cG28EAXgZGoYKXnt/Kz8vzmismZMuwLn3XSF2uRvajcDIB4 rBOg8J5QEU4LVdZnEqNvFHK7pMKSWT6e1ZUuFqk8foIH5nV7FbhkaZ0kX/U708TS KsMu/k6AH5/Mj96eaZnHdVTdr5CSb+p4bbYVksNwM0kJmh+Jxu3A4Hzw9CDxPeUM PUyBG+OI8pzmqnrVQ5ZXMXhRuEay+YieZG74RVUEiiQhq4K+Xy4aYLLfPpiaHKdn Ehy7VYAKELTfx/YHt7EYRtd9KBYF1FfUhYyXB07NKD7jeogq7KTangSH1BGun0ge raM1ILrPLrybbHa/st0dSBuq18qRj4CefoDXryS3aw2ecSmbU0I= =gOhk -END PGP SIGNATURE-
Accepted openssh 1:8.1p1-4 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 09 Jan 2020 11:42:10 + Source: openssh Architecture: source Version: 1:8.1p1-4 Distribution: unstable Urgency: medium Maintainer: Debian OpenSSH Maintainers Changed-By: Colin Watson Changes: openssh (1:8.1p1-4) unstable; urgency=medium . * Apply upstream patch to stop using 2020 as a future date in regress tests. Checksums-Sha1: bc9ac4f5f8bdf6fb649b5d9f8d6e7d8ab1db36ee 3316 openssh_8.1p1-4.dsc 802ce80d863601ed4bb48d44480f6289cd3cc459 171920 openssh_8.1p1-4.debian.tar.xz Checksums-Sha256: c5d5a33db79e4d8516dbac2efa0ad46ebe73483cf8f31becef311b4713465ddc 3316 openssh_8.1p1-4.dsc 60b8f04df14eb2b45e2e3a26314abfc977e69822928d18188cae722063f07af6 171920 openssh_8.1p1-4.debian.tar.xz Files: 2eb340e69f914ee044d1b8335a4ae431 3316 net standard openssh_8.1p1-4.dsc 30059157cf595af975bd4f29bd8e19b1 171920 net standard openssh_8.1p1-4.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAl4XEb0ACgkQOTWH2X2G UAt4qRAApDXil57pXcJKQJGY0qzCRlhYznhZbPNNtJ1UHB7GieX+e+I1medrb1cj sSJHW2FfE74FQPggLnd2rSSQGFr8jpP7IhyiPWiF4LmHMUurjCMLXWexQ/9dbGll k+cdcAiNPqCA6HoXLuZXQsyQnnPiXLue+CMthv/tc+RXZyBlofKzUg8nPheJOHcy ldvk1WpUJSj4hwXnXSB/cJCGq4bAZNq1M9+eSl7CHwW/wH6F3DQWOmSdZH4Jwf3E eSTXVI9slkK6hUrkhYjp/re6R5YSWkxyRs8z0OHoT6suzoGn0Q9lvnM9lvpsmznh V0qNzWx+CChEKwg4pdzg7a1R6MAYgiK/Q/bYaA17EpyPfVTGNkOj+pbaok+Xxyzx UgE/62NpJ3jZpavgaV2yqSCEBVstAU+et7J+4GW5ukfbDyd93MO8/tTxG/SSvgxA 8bM19BeIwbSIN/wa88SfrWJxhXJuex+BfOZmUaGnFRCCZxI17iElLDtDzcVebtf1 G6Xl6F09C583MEM35VGk1uS2dXRzsja78+n5UAalrnHyLOE1QPRvu+pevAvMetLp C50/7hoHpnPDXywLrnhPIPbHY8LWzP3C71rRE9dy4y0N6dDAKLPWGCliOawHGWyU iPQEewT+/uMEqno3DBvf7QBlEr49HLNsa0ayqTyHhW8yx4nT+/I= =cliy -END PGP SIGNATURE-
Accepted openssh 1:8.1p1-3 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 09 Jan 2020 00:29:58 + Source: openssh Architecture: source Version: 1:8.1p1-3 Distribution: unstable Urgency: medium Maintainer: Debian OpenSSH Maintainers Changed-By: Colin Watson Closes: 948466 Changes: openssh (1:8.1p1-3) unstable; urgency=medium . [ Colin Watson ] * Drop suggestion of rssh, since it's been removed (see https://bugs.debian.org/923691). . [ Steve Langasek ] * Don't build openssh-tests on Ubuntu i386 (closes: #948466). Checksums-Sha1: 359c2006171fdf2c5b5f5f21af6a4ab1391d5f42 3316 openssh_8.1p1-3.dsc 946883cce0f368240002860bff51ad8fb653163c 171388 openssh_8.1p1-3.debian.tar.xz Checksums-Sha256: 14a9bc0e3ccb4d64f55c1eb87e34d211332ac7504007126d36c4406f6c590231 3316 openssh_8.1p1-3.dsc 86c7d40e4c3027b07d04782316cc010f8141bb12738a56494897787de30796ed 171388 openssh_8.1p1-3.debian.tar.xz Files: 4a4f29bef9bf31f1d5853c0c9119ac69 3316 net standard openssh_8.1p1-3.dsc b23b64d9223d062693d67c1682ab7c7f 171388 net standard openssh_8.1p1-3.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAl4WdEYACgkQOTWH2X2G UAtusBAAg/5AMkPWJU4+73f2Ugot+a/2lVdqAZG3bUhLddu3T6oRUX/0hHW4dQYy Tn7U6oM0fXec0zZdZfLBQpSbwfHoGg4mB9BIbRWtydI3RlKNHU7unpAa27xHtj+n xXvI87VnBroEJQET76qE8cBoL9Jqk42X3DIf+AHe7yplSJ7VaVZKXMnfvMHHb2k4 x8Z0pi2A5CMcLSZ1aZoHKIkDFPliEIdjFqEyKeoMNfVyb+Tf1s7AVWZ/6nDsMDqZ qVcRzZW7b/1hKJYzSXQ19tAqSXxzHi2fsxGXRrESkOs7AQog7koM/4Da07Wx+3tg tJs9r8kW67w0AGzGAAqGN3cEX0o4o5DXD98UBAe6fBiVjfZkM8uUXze8tLnpHORT KZnNg+QcdE8qVwPEA67bBhHacNUdR8QT944CNFL/j4yIQmu//FkTW9JUpHqiXhYR h7X1TyfIWK8Wuzehruh4YsRUrY5lDCv77671ytCh8dM+41DJzvsLCQN9g46jKicx VbLrCdhQOGyF5RUYazC1w+bZniYipuRlhTqtBUZRrZ8wEa5x65dUAcJ6timOTI/w 5kPPiS5+Y3ypJAPMGH+KjeRfIif6L3UbUsP43OsCyCY1JRoFZy4SeP0rFp5xQaJF OQ7gLNk8sxmSo9yJt1RPoc8Fhw+l5eDci3TGTemY/462YFe//B8= =OfNr -END PGP SIGNATURE-
Accepted libpipeline 1.5.2-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 01 Jan 2020 16:29:38 + Source: libpipeline Architecture: source Version: 1.5.2-1 Distribution: unstable Urgency: medium Maintainer: Colin Watson Changed-By: Colin Watson Changes: libpipeline (1.5.2-1) unstable; urgency=medium . * New upstream release: - pipecmd_exec now calls _exit rather than exit, to avoid bugs such as functions registered using atexit being called multiple times (LP: #1276257). - Document that standard FDs must be open before calling pipeline_start (LP: #992271). Checksums-Sha1: b04b3e2c784510bea582e3a8bd7c46f46e0fe91f 2438 libpipeline_1.5.2-1.dsc fa296e37495d1874c736b7182770baaf390ad9de 994071 libpipeline_1.5.2.orig.tar.gz 6491d8585548d5e6409f38c698bb593b9e6fae83 833 libpipeline_1.5.2.orig.tar.gz.asc 2e087d4af45b8921a72650b38d0ce5efe721a794 9272 libpipeline_1.5.2-1.debian.tar.xz Checksums-Sha256: bfdb77b314a7f7ca9cf5fe1202c098b50f9f0a13b19b8108e5607557114d92cd 2438 libpipeline_1.5.2-1.dsc fd59c649c1ae9d67604d1644f116ad4d297eaa66f838e3dfab96b41e85b059fb 994071 libpipeline_1.5.2.orig.tar.gz 73d0d65c55bee5687c6a4fdb3138be4a1c3c7923fe6b1af8daa278c682d20e13 833 libpipeline_1.5.2.orig.tar.gz.asc 4aee76d35a44afb50d5aa06cf87da8c2376a01d1f98a0ff13721e086cc3eadb7 9272 libpipeline_1.5.2-1.debian.tar.xz Files: 6983928bb539fa73c8e27c1e4e714b0a 2438 libs optional libpipeline_1.5.2-1.dsc 169de4cc1f6f7f7d430a5bed858b2fd3 994071 libs optional libpipeline_1.5.2.orig.tar.gz a8f9e3595c2678ed40e7a9e6e688150a 833 libs optional libpipeline_1.5.2.orig.tar.gz.asc 81dc0bd57667a8e77df42265245f3b77 9272 libs optional libpipeline_1.5.2-1.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAl4MymEACgkQOTWH2X2G UAv/rg//ad1MpERR561QTClsaRfmXxPqls+XRX9CgV/vqDikz6CkiKIU1NSKYkK/ 8oyCUfia0ivRrJ0nbxPwNkd3YHanjnRXyHHekMmKbx+OyujUyKybT46XTItuGZo7 hUJ2BTKI6fTjnNw0hgkiDcpx1M2uRqoGMNpB9WssRaBC9VCam1ur7cQMbn6xFyZB 89zGfgqrj05M2TLM648Cr8EGqdiAyz2T0s2dNmW+xfDJDwEFgkZBme9C8f7/Gwo6 xQojFCmVcinfkxNssUxyOiTX0hjSN/ZxRD1PPst134pEAf580xbZBXs4B8qVCpiF qcbgaRqJfCHLVECMGLshFHQ7xcq8zs0nWKMl+lXi+BZmLs0vuWjMs4gU2WmqsZU0 jMivo5zj0J1BKOWbL2aC5QmSVfPWQFXK5tTB+MbK1Pte9zf8hdMExyBNQE0z4Yfw qjPdojp2Aw4AQ3mM9vHW39S8Src9JwMxQppaQJ5AM//LnLHlgDi3GLgXLhDazxI1 fuRSH4p6ZLYOepRiH8xATqOmtVQ595B6t+W4QMZanwFHfMAowpuycp/B4b+Po9R6 +8tLoA39X1rau6+lnedau/CBcSgtedNk7H5mO5reAHN9ADkuaAOIuYhs5fYXWaVF vCj6Fx6M9pzpThDQZhH+vVTndCix+PAwmfhw70Y9LYoecDfh/e4= =w5Vi -END PGP SIGNATURE-
Accepted py-macaroon-bakery 1.2.3-3 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 26 Dec 2019 22:46:22 + Source: py-macaroon-bakery Architecture: source Version: 1.2.3-3 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team Changed-By: Colin Watson Changes: py-macaroon-bakery (1.2.3-3) unstable; urgency=medium . * Cherry-pick from upstream: - Avoid using deprecated platform.dist() in setup.py. Checksums-Sha1: cfcec5a4d71cb3e0f97bab98403141b5a719cac2 2451 py-macaroon-bakery_1.2.3-3.dsc 6fa805277ca74be9efe9d1cf090c3ad8254f5718 4256 py-macaroon-bakery_1.2.3-3.debian.tar.xz Checksums-Sha256: 193cf9decca14253c3d2666008c212e04a798a2f850dc06a242af7753fa4f0eb 2451 py-macaroon-bakery_1.2.3-3.dsc ddd21c5ffb263a8544f1cd1057ae33aba01d80106812d00f778aa6b99646b9f2 4256 py-macaroon-bakery_1.2.3-3.debian.tar.xz Files: 2a45b6fad5d5e56d3f88fc1fc28946f1 2451 python optional py-macaroon-bakery_1.2.3-3.dsc 739b62b35a84e48580398cb950ba89bb 4256 python optional py-macaroon-bakery_1.2.3-3.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAl4FOGIACgkQOTWH2X2G UAvCsA//YPXUlFbi/JG49aCBfXBFSy+RhuKNYjJBqWcMdESNaBdgIEiGf/N7WCsI bfutqGxWILgLPNpm0d0GkMY/J/xCD/f9hlhRN04L5EDlFZthGGrMGZRxZx6Dha/8 m08XloQTTGhY8BLS1bK1iVTwXFkfJn1gtxMuORHmt0LRLkLsEOvAnD1NRPNlv9DE /Pb55bxHNFBIjViQ8hdh8QvBM73JCiVOFhOYTQ44BIMCzdf4BQiH4Rr1MBY7U7Bj WId08RRlnLpLram2fERuVlEjtc5MAeFL3k1ib2fuiGU7bykCCnsuXt6hmMlfzmDv twhD4vcXCiHkW/5lZjp/ep6jqkdjQ5UO2PT2sBXxBrqIQf1qLCMjF3vf5IHaXJSm jxDUW0BBGx92RhEhydZsx5JW5IKxVX1Tz+YuZnMAE/e5Q84uWdQCixDs51xdGxYS EQzHFiwgOiXzZWUnvXAzvzn4a7hYXaZSNPIbko/1R+qOes2/mImGN1uRO/IFMkT8 m8dpEg7I3r9JlLC7uYoDI3IpNHn5Np29HI2jIJnu0sEtmGdOODpZrBMcARbyldD5 0q1ALvjUVmeTdhBMWTdlsXJr99e4hAJJQEW5+NBD9onVmPmUxClFyxVtp5YO8QDl j2bsAOQmYHzPtjFyd/ziLmLzAicloBn1CEaE3m5y/KLn095dtPk= =XizW -END PGP SIGNATURE-
Accepted py-macaroon-bakery 1.2.3-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 26 Dec 2019 02:13:31 + Source: py-macaroon-bakery Architecture: source Version: 1.2.3-2 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team Changed-By: Colin Watson Changes: py-macaroon-bakery (1.2.3-2) unstable; urgency=medium . [ Ondřej Nový ] * Use debhelper-compat instead of debian/compat. * d/control: Remove ancient X-Python3-Version field. Checksums-Sha1: 2ce29a206e768fdc77c5ca886d61a36da716bd13 2451 py-macaroon-bakery_1.2.3-2.dsc 6adafef958c0a3953c446ae30f09c6ad02551f33 3692 py-macaroon-bakery_1.2.3-2.debian.tar.xz Checksums-Sha256: d33d22250fdd838f918fca73cbf4aba7d12fdde9a8cfd32d4217bf0e7af46064 2451 py-macaroon-bakery_1.2.3-2.dsc 0a0bae851501289ee1bbb08dcb201b6a3c36ec662f96bc4141c7a5c167393eb9 3692 py-macaroon-bakery_1.2.3-2.debian.tar.xz Files: ba7a552b5694641ae1b5df032cedce27 2451 python optional py-macaroon-bakery_1.2.3-2.dsc 1b47ab088cbd6b5e5a9f7c401e045241 3692 python optional py-macaroon-bakery_1.2.3-2.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAl4EF4kACgkQOTWH2X2G UAvRdA//SrCFQq8eqgq/d6zyeCYg0AeRLCghYxgGVV8qG8v/eb7OgZ/vJB8gGwGu dcET3GJea21FicR+Z+cMmDOZSeFfyPFBueSnJunTy/GPZh8gzNrNYvZinjEd39Ei 48dbHr5LAJUiIJDz8u2AaWD/TS2xnaHvqUUXsmkaMBKh3+pJwv/PDxzTPXVMWu7I hgoKAd7vOwexkQuQ5idejBCoG0mBmTJO16KEFV7m3uG69BAVtt5RpDa0qrVa/YCm x1ri5I1N3sfzGVcvtkWAHodvWj1+16KLHFnJ12xSTeYtVfMwWMODT4zKsbkv40hj Mxq7QEojtvfzDuHCWcoIAYa2yzVlt9Xr4uHjMDxxQWDxX2I3MYYMFFZ9S1YmtcOV X0A8T6YFHUGqljuds/rJ91QpWSPkswEKTe7/7Eu/28dBVxC0XKsz7fi7Nr3O2h0F ZPVwebJqk+rLpMP0Z+4r5nMh92HlD98lBvJWY342RDAHVHdv/6TQz2FQnju1poA3 C88KdN5nRdJOIWopFkEFtM7OMl5altEHSvZ8+aldtBEJdXSUrQNhc2Cqx3f0ggA+ inb5/NTMrsglK10bBF/iqAry9i/2KSkT65OS1Fd2EpXTUuS+r1qtEVIm6xDjghm7 Npxu1sYFaWYmW4xjQOUrQSXGtWRfgK9gb0aVYfFuXsWOl/p1w30= =ilSb -END PGP SIGNATURE-
Accepted storm 0.22-3 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 26 Dec 2019 01:36:24 + Source: storm Architecture: source Version: 0.22-3 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team Changed-By: Colin Watson Changes: storm (0.22-3) unstable; urgency=medium . * debian/copyright: Update copyright dates to 2019. * Remove redundant versioning on python3-all-* build-dependencies. Checksums-Sha1: bd8023f31bf598c5638a185bc8c8cbfb9366436d 2646 storm_0.22-3.dsc 8b3527fd0223b9347dce3d42af93d68a516ed90c 13004 storm_0.22-3.debian.tar.xz Checksums-Sha256: 33d5735d59c81ccceead7e8959c3a276b412a2e5b7464e3f6c37e09f4be41e82 2646 storm_0.22-3.dsc 9820957b9bd32bb962589ebcab05fc09bd9ca8813a6aa6c1314abe82f3637b09 13004 storm_0.22-3.debian.tar.xz Files: 62644e09082282498771b545cd24e2b4 2646 python optional storm_0.22-3.dsc 927d5666274cac518b6edf3f00cd5329 13004 python optional storm_0.22-3.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAl4EDvUACgkQOTWH2X2G UAu1GxAAj1B1/YDPhhkrkoERDI+FTHwN2+uDZHvPg70NiJ/o3+NXrbX5H0VAYo31 /M9FQZWP0pBdEBFwHdNHemmYSZzYXtID+ii2AZbYKtYP2FqdczOoXalbYaehE8qE DsdXm3PGVHlpI+pp0cLuZzjtM2GFctpUKVoA4o5HCk9Wh81236JGMK0iK41/Uc4d FkiCPVA69FD2qhG16vgu0UXnxtiGSYL7gQY1o0ueQ93+1Kbn4MhANhrKr4QkOfB7 UKCg6PXM2eIFSIhGvh/pVz0FQlIh7ilTd3ypaljRppo7DYbY/dW1qpM2bfVmVlSF aNWTN8MIaeOrh4OZXXvTj++AsCbkZf2zDomfuyEMyZkyn2BJlIi4eF6NtudwqsAs NFssfQ0K/xaQ2UFHH7kmp3JJA4r0qPXSGTzrrS0UxzUM7i/FpIjn9/uLrFMEEXqh JUo4/IGmvrixgyf5u/xQU6BV9HDOCh7+DuJ6mMchhrrpyy5YsDAeYmpXK9/LJ+FS /khkwauqbrNww2Q8D0LZwZGT2ffZ9tNJ0ecxOuazpANYeNCrtT2R2EZyVinzm+OT jwVDJZz3DVvyuCUMOIQecwNY46l2dgJk8wMQH9IMGfsxxi4EVERoqjQN3IfikG3w FUeDpJNqc3qhyldDpJfh4xk4hYbpXIjhVDRm78BQtjiv3w513H4= =E/r/ -END PGP SIGNATURE-
Accepted keymapper 0.6.2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 26 Dec 2019 01:33:31 + Source: keymapper Architecture: source Version: 0.6.2 Distribution: unstable Urgency: medium Maintainer: Colin Watson Changed-By: Colin Watson Changes: keymapper (0.6.2) unstable; urgency=medium . * Remove "from __future__ import print_function" from keymapper/parse/*.g; this isn't needed when running on Python 3, and breaks now that #911730 is fixed. Checksums-Sha1: 37cc715e404020e6396ae1b3c20396f48a085e42 1667 keymapper_0.6.2.dsc 8f3b73c3304a1efaf16f00d7faebf184f0f342f4 48976 keymapper_0.6.2.tar.xz Checksums-Sha256: 62441b34135095e31ed96d6be305457943e74cd3a153d2cb42561ca48032c804 1667 keymapper_0.6.2.dsc f142164b7fd9c0e2b3149a2c4352269622d2e3ab1f94bc6db4efdf87953d4927 48976 keymapper_0.6.2.tar.xz Files: a7c2841c9ccb91ba8128d2e0a1f451f1 1667 utils optional keymapper_0.6.2.dsc 2c681f899e2d930600b38e2678ed79b0 48976 utils optional keymapper_0.6.2.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAl4EDg4ACgkQOTWH2X2G UAvTyw//TWyALNhRaW4CYEfLZ9hpejFSsBhtxTfQepbuYbtGlbcEmEl7TcreSLUJ WbVCY2JwZ8hllpE42ZAOMJBblhJ7nu2YNnXjE2ki2rIcxX4VLpXqVdR0VFuLfXFv grZKuuC+qpKyalAaxXbFpeSMMsK2uBAuvbdPzCZFfttHCFgOu7R8zm6hmrjkZliO PXUZTJhbjbql61pXG5IXvaZPc8PW45h81B4TvMmVU2FsMjZlRo9hUPVSw8TLjCjU HahA6mDWNtiZtARgukQQm/E+wtmBq5Oib6dEksk2MAMT+cD4rUNfVCoIV87H3rcz MN04UQh01OS+0y+/ZKWsBoZnoA48lwMg2dpyrS4t0ky946ag1SvjKrYwoWjpyr1g fLZQNaeejpCRf3WyvNubhlY32EU9ilxwfgTSocOvV9i3Hg3K+/5CyLFt2gCJCt4d skpBx+3Zlck9g3CkwB34jI2YQvzKbnCiw36puILSlZJQWFuAs1hCJX3tFa0R1fTE iG27ukqdHxPlrBJehrp+TAyNpwEa+iYL4EbW83DGOJcifgD3gsPzaWPBw/ZIb8A5 fnxsHVDdmcJtFGNIKn7fYDsmMMMd1WV+Lpjc3mvsuaxAC2qQr+u/SrWnCAU0R0Bz Vn2pjWRJx3qq8Idh7Zl6rmkqwHb6x00exPkeW7Fnce3isS3q/bs= =jiEI -END PGP SIGNATURE-
Accepted storm 0.22-2 (amd64 source) into unstable, unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 21 Nov 2019 16:05:09 + Source: storm Binary: python3-storm python3-storm-dbg Architecture: amd64 source Version: 0.22-2 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team Changed-By: Colin Watson Closes: 725462 940876 Description: python3-storm - object-relational mapper (ORM) for Python 3 python3-storm-dbg - object-relational mapper (ORM) for Python 3 - debugging files Changes: storm (0.22-2) unstable; urgency=medium . * No-change reupload due to dgit signing confusion. . storm (0.22-1) unstable; urgency=medium . * Convert git repository from git-dpm to gbp layout. * Fix typos in package descriptions. * Update watch file to download GPG signatures. * Restore DPMT as Maintainer and set myself as Uploader (closes: #940876). * New upstream release (closes: #725462). * Adjust packaging for port to Python 3. * Switch to pybuild. * Set Rules-Requires-Root: no. * Policy version 4.4.1. * Restore DPMT Vcs-* fields. * Update Homepage to use HTTPS. Checksums-Sha1: 63833dcd5778b1bef17e1b7f7c174571d772e4d3 2674 storm_0.22-2.dsc 85989e51a0c9bfccd73ddd9f4e62c9ab1097a929 12972 storm_0.22-2.debian.tar.xz 569329ba6b496d326de5c3b3f9606b8df70965bd 241028 python3-storm-dbg_0.22-2_amd64.deb c920899c552bf80054e3ec48baa917557480e1b4 228488 python3-storm_0.22-2_amd64.deb 96775360194d8c31c25ebae98197a2ce775b95ba 9388 storm_0.22-2_amd64.buildinfo d74631f6d6408419ac7cbcf19fb4128bda768d76 213386 storm_0.22.orig.tar.bz2 a99647cd214414eea9020f542b8287c164467fe5 833 storm_0.22.orig.tar.bz2.asc Checksums-Sha256: 71c07c81b6b85dd0e3b1f150e3c98ba2c4e44828da050f69bc7323b66858e3c1 2674 storm_0.22-2.dsc 3fb6e3928390771027504ec2ed42a6bf4c7935f15426fd38f976b3714dabdfa8 12972 storm_0.22-2.debian.tar.xz 02f30f8797ef60e99fe415873331dea55baeccc28ba40148dd7bc31f370198cc 241028 python3-storm-dbg_0.22-2_amd64.deb 9d9f13f669420ad7a0d5e67ae254b7547fe1011e2b6f18f96b86520635efef08 228488 python3-storm_0.22-2_amd64.deb 3d46357f01e54045b18f6871de89e81a51333467f49afcbc68f7088f937c2b2c 9388 storm_0.22-2_amd64.buildinfo 73aceb4c3ab9fb4967b109af7a3f5fe3cde5be379776475a96113b0ee6187de6 213386 storm_0.22.orig.tar.bz2 f16139f7930cae5ddc31cd85c214900443e876502bb7597e6ec4b6949df42124 833 storm_0.22.orig.tar.bz2.asc Files: c93a0fad6e434d918b67f3566a4b716a 2674 python optional storm_0.22-2.dsc a1afa88f7799d857e478e35d86485177 12972 python optional storm_0.22-2.debian.tar.xz 588c9278c14637c05bc9e0ca624e15e9 241028 debug optional python3-storm-dbg_0.22-2_amd64.deb 55d88b59c05ba67fd38e90ade218 228488 python optional python3-storm_0.22-2_amd64.deb b8696958326d9f7046451c33d11f59c9 9388 python optional storm_0.22-2_amd64.buildinfo 3dd0070e72b75829fbc8d89f11cf85fd 213386 python optional storm_0.22.orig.tar.bz2 886ad2008d876ce0d8b08332141aec5c 833 python optional storm_0.22.orig.tar.bz2.asc -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAl3XL1gACgkQOTWH2X2G UAv2wg/+OxFHezIbvLkEhAPr8JiN/b+TOWJN6eiejrfi9pVxbRMrAXCpHPJIrSbf +Q3uL0R5MMw0zR6G8BQGuBBIoRHOa8iSekITKsGJw8HFoU6mi8kqlKi3dXnrYX9r 56bx5e+ER1BRALyYjsMVjilcSS+eZ4kvqnDhrQ1pN3YeMOSOprx3j0JXFiDmCbFP aan89NBIVrvAoaYa+UAyJ2vfWXIU/caam6k/rGejt8AUcNudBfvEBfSAvuy1ij+b JUUdI0g/4rDWovd6t5N6sRato+dy7aYGE8G4pOo/nvZHFMbmamkyHHTvurTzhOvk SDW5ldZTzgDPAoWkjEPCCviypnPZNtT+P3exxn5/jZGqFQAYYbPs7MCjPpeC1c4Z cnPevCFiKyL9l/Z0crKlQyjT/rJapAI/vgrJFd0E4JaBiyOG4aRYBKDaFDSIyzHb UfzRq4fIqqdlGihXQxhQ4m+kcqH5XI1sinbCwURblihw57um4of1VoO3cms/GKzR UdgS8pJltjcB+2XqcpZUhe1Ovmsbf6n+9u3L7vkScQ+r7eiugwzfbaBcoVqtoHgK f4I+dPFk/kgW/Z6qoXuzAAJ/L+DtL1A6FbBdSh05K73Ga8s2PvENEZKjMpXy10Ss uN1D+/Yite6k+l+r3A9x7KGp+qc6kV/LVt7C4Pz5oH15kmz7ayo= =0MP+ -END PGP SIGNATURE-
Accepted yapps2 2.2.1-3.1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 23 Dec 2019 22:05:40 + Source: yapps2 Architecture: source Version: 2.2.1-3.1 Distribution: unstable Urgency: medium Maintainer: Matthias Urlichs Changed-By: Colin Watson Closes: 911730 911752 911753 938864 Changes: yapps2 (2.2.1-3.1) unstable; urgency=medium . * Non-maintainer upload. * Drop Python 2 support (closes: #938864). * Write __future__ import before preparser (closes: #911730). * Convert Scanner.print_line_with_pointer to Python 3 print syntax (closes: #911753). * Port documentation and examples to Python 3 (closes: #911752). Checksums-Sha1: 77406f76605477f548eea44d73a9e940de9df3c6 1874 yapps2_2.2.1-3.1.dsc 313e50cde0130e208ac23ece88bc1ce7907efea5 28477 yapps2_2.2.1-3.1.diff.gz Checksums-Sha256: c8cac3ea6c16d3854b221ea637a7ed47e3af9d75315963f07196db374f31 1874 yapps2_2.2.1-3.1.dsc b41f6ec42dadb3ce55d45bc9e068f5713e69b453e9098313c4fac73d626fea68 28477 yapps2_2.2.1-3.1.diff.gz Files: 4edea926922e2d5776e8b469d1f32cd2 1874 python optional yapps2_2.2.1-3.1.dsc ece1dc2d8252c4e4d4b37dfccd8e49d8 28477 python optional yapps2_2.2.1-3.1.diff.gz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAl4BOxEACgkQOTWH2X2G UAsksRAAnhmTIy8hEF3hSqsNOKsSOO0BS+aUoG8ep6SeGvY14sA7aLCsVRIQ9Ti2 NKOesIYW+V6GCbjNyrGkPOnjaHY25oEroQlxQ8s+vcUZ0U4KJrph1d6Sm3iJQHQt /q9Dmx0p7Xo6vytQd5OK3gvNyAmGCYdv2gMVRp+NCrTODfKhl8b9FgwgqNPscv4J YEmrNhAh8Hb2BBcebwwQx0c1LzKnwGulVKJJiSgNGzBRC8YjR3GWfUDYN3OEE5jO zuc9yEFBQJ3CopO3d2TLGdW84B/B7PlSd9ZXm2Obt9QzNrwgL1MVUMrnqsFFqCkN Gbxx1rKPU8pAxcSwj99kslOTFNFPrf9wc3XtW7EW9O3TzVZWiUPoY03fb7vXWPLe 7oVFXWKRlZKHAe4KXhoFNSPUcK2Wx4pHQgLuVLBYLwDUJ18TcB5tWcTC/WVOD3pJ ssvGzBJoKsiOGoGMxfugKAo/ch1xnhFMtpoAo9I1JWqE6Gm4Vskd7oFTU7JBlMEP ABAZyIsHAQLWXqGAPPYzZa+0SaVWsZc3gbD20z/hRrhJUfUWHvOzd/oMY5QDdHBi oYD1oBFZkwywd8P2Y7jB86kF/PTK9YcRjDz14GZghMRjO0YN5UJAJzpOpqLRhncS M86dpgjE/JfmWLOy9l0HXUJC1u2lYfPTdAAWT1VNhQVbNDs9Cf8= =uTrA -END PGP SIGNATURE-
Accepted groff 1.22.4-4 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 23 Dec 2019 22:38:19 + Source: groff Architecture: source Version: 1.22.4-4 Distribution: unstable Urgency: medium Maintainer: Colin Watson Changed-By: Colin Watson Closes: 867123 946868 Changes: groff (1.22.4-4) unstable; urgency=medium . [ Colin Watson ] * Use debhelper-compat instead of debian/compat. * Cherry-pick from upstream: - Correctly handle groff_mdoc(7) .Lk arguments starting with a dot (closes: #946868). - Update NetBSD, OpenBSD, FreeBSD, Darwin, and DragonFly version strings (closes: #867123). . [ Debian Janitor ] * Trim trailing whitespace. * Bump debhelper from old 9 to 12. * Set upstream metadata fields: Bug-Submit (from ./configure), Name (from ./configure), Repository. * Drop unnecessary dependency on dh-autoreconf. * Drop unnecessary dh arguments: --parallel * Rely on pre-initialized dpkg-architecture variables. Checksums-Sha1: 1e667872c565f9b44fc1eec9aca739e7e025d67c 2432 groff_1.22.4-4.dsc 3478a2aac763c355dd09c6bd1497977282223c8a 49872 groff_1.22.4-4.debian.tar.xz Checksums-Sha256: eb05cafe35e3e3cef8cb2af4e488d7d1d6b1876a63dd405635c3f7fa4546b825 2432 groff_1.22.4-4.dsc 69332e36cf90946036cf813f479a734dd1c4bd9692d380fc0b837874db2d63a3 49872 groff_1.22.4-4.debian.tar.xz Files: 629489dccc3007fe66ceaba7e9a03c48 2432 text important groff_1.22.4-4.dsc 137310cbaf936714928fed228ded91b7 49872 text important groff_1.22.4-4.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAl4BRIUACgkQOTWH2X2G UAt8GA/+KWgX0OitvRZdboZzSFFHBiUvNFgoHKwy79o2OKdMz0CrIMbs4GNyFMaw Lc1OqCPpJhNr9r0oVkBFtErqkh/LGDr84hTsLJFuTXWrRTU0w1q8vrr8HvsmvEi7 MhyBumHmHBr2eryPdJ2AfCHYVs2UTryrO5GDjkP5A7P4v7WEQDBmMJQVIy0rB0DZ 7+CD6k9X+2c5Ysb4lJM0/qlpYHxwAq6DaF76uZOIaDr7SIo2So0+RB62RrI2QFE/ gx7rq5Di87YvOv+WUf2UCMxdXAOKJHE7ERLWgDW6dnkyAV+iw3fTI3Rta4bj4FHd MncRLUGsFWpb8vs+PijTaxPoyZCsSkxQy7N3+UPcSBgXpWBDkaNf4ZI2j6QI0aH0 hKpwVO8bqCE0CTYxysMBvozRsKkh27yY9TxUaA/KReXrE3IistpzmkiydvreYP87 lvmWKohR/XNicgz2ptrr7ceeCqhdQD59F71TsonO2xtDCRhHKUv/KxQTPbGWQjs7 h1GYK7FY0DwFQeyfnesSoFOHa1nvM9RqT2f0KPkd/fiLY7ClOYGvKDt5oFnCqht4 +C2KQmdNW39OelMz8WdCLtYbaiCKn7jigpYE83WBh/rJwn+tDjoiqyPRkCJV2N5E Vb+s2gioiIn8WDJkD0CU6tSswKHht9NTIHCvOmjXgwSrm3vVKd0= =olTK -END PGP SIGNATURE-
Accepted base-passwd 3.5.47 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 16 Dec 2019 23:51:51 + Source: base-passwd Architecture: source Version: 3.5.47 Distribution: unstable Urgency: medium Maintainer: Colin Watson Changed-By: Colin Watson Changes: base-passwd (3.5.47) unstable; urgency=medium . [ Colin Watson ] * Use debhelper-compat instead of debian/compat. * Adjust wildcards in debian/copyright so that all files are matched by at least one paragraph. . [ Debian Janitor ] * debian/copyright: Replace commas with whitespace to separate items in Files paragraph. * Update copyright file header to use current field names (Name => Upstream-Name, Maintainer => Upstream-Contact) * Bump debhelper from old 9 to 12. * Drop unnecessary dependency on dh-autoreconf. . [ Dimitri John Ledkov ] * Switch from sgmltools-lite to docbook-utils. Checksums-Sha1: 54711ab5719c1f51f1dcc5e281e5f3a5a99a9488 1757 base-passwd_3.5.47.dsc c8ad18613f77b9dce413e3c1031d64e1b1850bcf 53024 base-passwd_3.5.47.tar.xz Checksums-Sha256: 5a77a4cce51d1eb72e9d96d4083c641435c05888922c7bd3fa6b4395bf9afad3 1757 base-passwd_3.5.47.dsc 9810ae0216e96bf9fc7ca6163d47ef8ec7d1677f533451af5911d8202a490a23 53024 base-passwd_3.5.47.tar.xz Files: 0f36f3825da03e99c3fd54a2b17d3343 1757 admin required base-passwd_3.5.47.dsc 1c822f6bf218415062467c497137b505 53024 admin required base-passwd_3.5.47.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAl34GXYACgkQOTWH2X2G UAuNCA//V3mFjmkG9R46lTKDlo1pHB5fG4GANXLLClXAk30ltfMn4z+UZkPcPKNi NlMC+Q+UyKwWtJjhvZLmjHKbXd8XqV1yhcQnLY7cenoQDYeA7X4A3pNOKq2tsYW4 i9NrU9xTOv8qDTefEJ0Ts0WWASn5cgfW8L9big6Gm9MWpU74r/LYNyq5yQqA2eBx r04W18soYgMhuG3yp3sXK5/GeDKx68JbdLghGjB/jESK82b9DEftW6d4a8FXsf2F 3aSoNAUPWv4V4TEclsKTg5Rtpr8YobkH9s+xs6i1keRP3dqg9O09hdD2R8YSak8y o31G4uCFydBnCiIfdHpNTrDjyZEPb4wfgQdNHQT9D3gv/ark1+Bg28X5ZEfpVF5x CFooFexQR8IvJ11+TsGSfWo8cfIyQSjg1TOaD9SVnmshT4r3jpFDiT2kLwUAHLW5 3dlaiUBdIUliVvtLT5VTvaxoQ3zEA0nktHGTSeVwifdX1c+f9Cvimm69sUm7Jc5U sPlYrMg4kJT6OSZKb7h1IAKe5A5B6r8jMjUBMCBGxINqwuWbcWjX/p5FxFl2n0kB wVhIOraZ4/Zz+5hx+Fq87X9f50ois+LFLFkydwCL6D+2DuaU1uZi1QjPK4gQdVyf ++MHZY4/DvC4Yh/9J+/MChxRw/+SA4ZVgru1kBIKM1HP1cFUaDw= =i6Z+ -END PGP SIGNATURE-
Accepted keymapper 0.6.1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 16 Dec 2019 15:52:46 + Source: keymapper Architecture: source Version: 0.6.1 Distribution: unstable Urgency: medium Maintainer: Colin Watson Changed-By: Colin Watson Changes: keymapper (0.6.1) unstable; urgency=medium . * Remove alternate dependency on long-obsolete xkeyboard-config binary package. Checksums-Sha1: f350782c1da2cdd699c907aaa7033147b9f7e0f3 1667 keymapper_0.6.1.dsc e5221f29c05349e541542d82967248df2a5222ab 48940 keymapper_0.6.1.tar.xz Checksums-Sha256: 216141748628e9c9bc0f786990b3f01e7bf425b5a758d9d75a3f2c0525c16c27 1667 keymapper_0.6.1.dsc 1c9c4a159be0159bf2118cfb1f79ba242f61d755e28988ad5890b29bca344915 48940 keymapper_0.6.1.tar.xz Files: 305ca9ff7288d013345945b3b7ed59e2 1667 utils optional keymapper_0.6.1.dsc 8aeb66169b7542f3a17f12f528dedbc2 48940 utils optional keymapper_0.6.1.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAl33qHgACgkQOTWH2X2G UAuUBQ//bWlB4YbJNogSepLR0hG8tCwomkLirpRXAMZGDUlwRq9a+pGVZmDA3Zbo /RZlQZqhJpPSRNMsrcjU9acnR1HXdaGGYcROq5C5C3u81JQ8jZDVkAhY24rWD6Mw xPaqru1VON0eMkyRZJ4tWT3K28VVxdl6R6zmNNB8cU7MCh07RHLTSD8bvtYubeeU TIkFpVoXE7U2JW5Lo7+zD7YpI8qmQyzufR+NmYPDjb1eWhkPLYIfVe+xepw5boGl cwEYBLC72GWFdZBg2gZB09BKtwB/norDjJABjxgetoMjY9c1OXJe1N3V+SaDaKmd fE6jdfsvuQdNLEU0otq2uE9dTcnm6WKfCOEvyht6Z+Z1ROi3MBdXGS3FB+FOBceM RctviahOsbKO18P2GnzgaZ6C5NrWqodPbQHRC4mtF7HItHVVR0Hg4+vAudYWNHu2 cYIlx1WF3jbOLYSTPL3as6ZETAOtXXopPRfHzQI81/+LgNBEKo59gV4cvp98mlhQ Ayce+tytEvIag/UJGpWqrUJNE3CvjRCuPwE+ymF9x0FQe3ihMx/O+eE74JGGoGH8 pIPMnlSkyN79A4E3aOx3JyOJIzo02Ej3JBclvvhVwbiONATtWIQon+DFmHtLXMRW JP1q+U4JlQJGbTUm8ID7NxVABJAxASveZgnwHayfcnNBtm6C1Qo= =9FJF -END PGP SIGNATURE-
Accepted grub2 2.04-5 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 16 Dec 2019 15:48:45 + Source: grub2 Architecture: source Version: 2.04-5 Distribution: unstable Urgency: medium Maintainer: GRUB Maintainers Changed-By: Colin Watson Changes: grub2 (2.04-5) unstable; urgency=medium . * Cherry-pick from upstream: - verifiers: Blocklist fallout cleanup (this was one cause of a build failure on hurd-i386, though may not be the only one). * Only recommend grub-efi-*-signed on the architectures where they exist. Checksums-Sha1: bee0879e91350d60a28d8ae0db6ab9089c816cc6 7178 grub2_2.04-5.dsc 789ff7b8b9271d1190b2f6d8bf4d62fbec71ec32 1050012 grub2_2.04-5.debian.tar.xz Checksums-Sha256: 1d03c7afac3ff8a006c313087c9790f51679277cd419339f836734cd37b3c28c 7178 grub2_2.04-5.dsc cbd8215ffdb56d3605d03c5c93c972941dbb5031d18a295314ad3510c55f0302 1050012 grub2_2.04-5.debian.tar.xz Files: d51accfaa82779672a4c44394426fdc3 7178 admin optional grub2_2.04-5.dsc a92efa96d6962b42e7d40635e5cd0a67 1050012 admin optional grub2_2.04-5.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAl33p5QACgkQOTWH2X2G UAs1PxAAlXNakoFwwEImvw6bSWAbG5aJc16RMQn95cdnl9gUlC0t3iaKmhvsypH8 bqbFTRA7mmkbeYUxPoq2/ypR823Oa+3wzQUgDV9wOjqLMVXDk1IhT6hr6LkRziCJ yXIwkLtmKUmEv02gXluiOCEhfluhgk9uzFX3x5/GQ27OTt0glOuanoOB6q2GAqAU hTJCCw8QXRZydzbOE7gTpPjYWM8azfAlz9NxaqRaI4TqR0dKvqo2uYZV9RGQGtyV AcBYqeXFkdAQJlSwiCu2drEV/EHZVPsihv5jQslAb3qvVew/XVzwticKWIlD3Qjh BU2HuaNg06G+Vg4X2N6FYk0UxLLLgZz+bBHxAyxdNdzEX+2lGKkgzKQo/fgqBhWB wSUylnjlP/zyvrizEOI0ko2b1X9BU7MxBDUsfvo92HrUs5hQ2DXlX3xURXIPwW6f bBnwUd6dybVEN9G3k58K2aGBJwNouVjQtzeoCBbp1VkaiBzzY5m0qalS5xrKYbU+ w54iDDRp2Y3WN/lPU3IKGQ0yPkM/htNfvxiVesdTGeZmoKkJnqBCEwDa40bwWmWS SEPftqWSsdyDD5SSLIPG/myyAiBdXzWBP+zZZhEF36iOH9Cf3o2ES+/FbTE9A/bk X0MWst5YUI7z97hZhWclGy8QzNKC7SfUBKeCWyuBNXrGq0vX0CE= =iPFR -END PGP SIGNATURE-
Accepted libpipeline 1.5.1-3 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 14 Dec 2019 03:21:09 + Source: libpipeline Architecture: source Version: 1.5.1-3 Distribution: unstable Urgency: medium Maintainer: Colin Watson Changed-By: Colin Watson Changes: libpipeline (1.5.1-3) unstable; urgency=medium . * Use debhelper-compat instead of debian/compat. * Re-export debian/upstream/signing-key.asc without extra signatures. * Install NEWS in /usr/share/doc/libpipeline1/. * Adjust package descriptions to clarify what kind of pipelines this library creates. * Policy version 4.4.1. Checksums-Sha1: 167a40f3e02c82c943a21bbc37d41499e61cacb8 2438 libpipeline_1.5.1-3.dsc 6845599c1e8f9694354492ce9ef67867ec8919ae 9072 libpipeline_1.5.1-3.debian.tar.xz Checksums-Sha256: 0f374a574f6aa531540d98fde91b2a153b9f15566d94e1ce947b351f21022e0a 2438 libpipeline_1.5.1-3.dsc 510ba05c65d0005a45621424190a2cb0d31e7dfff52d31f468b60c40d9ceaf5c 9072 libpipeline_1.5.1-3.debian.tar.xz Files: 87b7b0766d57c21bb47ae379ea6fe6f2 2438 libs optional libpipeline_1.5.1-3.dsc ce9d37568f729edfc5c0011f42c09822 9072 libs optional libpipeline_1.5.1-3.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAl30VbkACgkQOTWH2X2G UAtHjw/9FY+c209WMwmELqT0FZhiguu4EhcjeO2RfUYk4bAcUKn7WlOp9q1tk4Rj xzui6XcocBXpj4KaRFGIrzRxW9dykTK6HGOb+yafiOHdYeKUeqavH0CbNRyEVWjG UsTa/gtrJx2VitCjVlim7oAR4kuNk+18hlUVA+YNWlaeyCTCdUYT1wSi4wzzRVOA IT6uwRy4fu4dm9v99dh+osrfn/cbHRcwmjWgnLEToknargHiMM1ep2YWSUiiULWf rblwv00k7UJaz4eQ+3xGwk5+1XnrkeRc5jRhhpq+MK1QEAnkViYndPchAAZj86i/ Rv6COwYeckAQ4t+n3Cu6ccGTbHZAuoOq+oIDov24dbWRechJKmsorqie0UrQ06i5 +J8xESZ6zwgUFQvRYqpmNcGptJUdG5OIy/OzWm94Va7Pc+yWirWFypOJNckxhJhr seDZdGinp7hhmGAWtVChUXblAdZi+87VKYJCCoDzVlSyS/uAjsL6C/TgxNI1fd3Q hXDDzD9MN7Cmvb93zXPC5rxuJmlhZKL/vtEmI3CJ/g0NgPKmXfIkvvd+6qIBRmD/ mC3DwBa6rjUrFzNQ3UptNOM4Vumcm5OAZNNTz+23vSBQigDzmlr8LoiuE3io2jKn Tr3QXVwW3CBEzCpreeX+A2XJEkSiRMFxemiRDiipb62dTwTDM9A= =GDkh -END PGP SIGNATURE-
Accepted python-pgbouncer 0.0.9-3 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 14 Dec 2019 03:06:46 + Source: python-pgbouncer Architecture: source Version: 0.0.9-3 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team Changed-By: Colin Watson Changes: python-pgbouncer (0.0.9-3) unstable; urgency=medium . [ Ondřej Nový ] * Bump Standards-Version to 4.4.1. . [ Colin Watson ] * Fix PyPI package name in debian/watch. Checksums-Sha1: 312e1e4da6b4ffb60924b9d9b044bd31e3985ccb 2603 python-pgbouncer_0.0.9-3.dsc 3b99bd0f43468f4d2e56d24a09c13466261c2b48 12428 python-pgbouncer_0.0.9-3.debian.tar.xz Checksums-Sha256: 7a89621f7bea684494521d2fd86341555c04227ac157a6853f4bc6a1d458971b 2603 python-pgbouncer_0.0.9-3.dsc 48508a2fa1e01b6f2fd2bd13b8d4570f673209daa54c32f09fa8052f0cb417df 12428 python-pgbouncer_0.0.9-3.debian.tar.xz Files: ac2f3d2399fa605e86e099b193ddce22 2603 python optional python-pgbouncer_0.0.9-3.dsc 5092554da5b6f310235c830fe3f8ce8d 12428 python optional python-pgbouncer_0.0.9-3.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAl30UegACgkQOTWH2X2G UAsU3A//cfL19Lho5OmBkZaTFC4qzqO8FRt8yr7oVPGM8arMg49HNq7Kg6q9m+jb mgCzPKMVmjdM6teLATcdm4ITOQ8mgbSiVwnVvjxFiKKrsk9qHmGjgxgkvnH7rPsa ERH84wAFyP9YeLVl4p658r/3Gq7GK6Cf6jrRy/S6tYbcj1mjKYxE4D/G4uyHz5PC sELSjs/7xNVpe6bhlW/Nmsgxk07osK1tmqYIhZeCqjfvinatmMAkQT6slNZHCM5W hAgLK9cL9EcndPMlv3E9DnnCwR3JY8kboFRACEgIuJOfcQLnRuwKCE3KQfhGKgwY bzis871daoLlyXsPRgWvKrk5oFB+m0vpgZUtvbWvEqrvGQyT/H18Z+egDg9twEa6 KA3YOU2IESOiZlVw1tLNHEWH7ZeeqoplSfVjCnZmj2qRGnLkqj7dQGhV4ld5VkDG 69cx/91k8hhfvwVs224f2KIvrv9YoL6zu5FCDdnIdgb3RfkTq4yhCi4NXgLMoCYH v+ahEuscWQ2z3cNrqq9lja/z3EWapkIRUMU0zcKiSKRVWYRe3+bh7mzZm57Afane MVjsUGbU+S8QtVmqj4Qvis+hppILDcDX/gl+eVQhUNgtgl1t06H70/ptSsq29/v9 lod0Py172XTlzDQAolBBh6q9pObFclEyE39ZTCuPjk5hdJ9NA3k= =Oed2 -END PGP SIGNATURE-
Accepted python-timeline 0.0.7-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 14 Dec 2019 03:05:28 + Source: python-timeline Architecture: source Version: 0.0.7-2 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team Changed-By: Colin Watson Changes: python-timeline (0.0.7-2) unstable; urgency=medium . [ Ondřej Nový ] * Bump Standards-Version to 4.4.1. . [ Colin Watson ] * Fix PyPI package name in debian/watch. Checksums-Sha1: 4e44f4f3cb99b15edbb3bcf81f3b51bf8353a115 2526 python-timeline_0.0.7-2.dsc 583f5f9faaef30613623feaf903ae468416c3870 1924 python-timeline_0.0.7-2.debian.tar.xz Checksums-Sha256: cf64ead7b767733d31f59938e1216f1fa4c17fc141b820aa095a66de61fb6743 2526 python-timeline_0.0.7-2.dsc fc6fabfb979d0239e2c5dca47bca42e8ceabaf7dd3e6fecd495c2da5546290ad 1924 python-timeline_0.0.7-2.debian.tar.xz Files: 29b93a3bad10977c6f19c2c35efb4e04 2526 python optional python-timeline_0.0.7-2.dsc f75aa94356ba498cbe80053f82f1dc33 1924 python optional python-timeline_0.0.7-2.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAl30UaYACgkQOTWH2X2G UAtxuA//bnPz+CdxBhObIaqZVmGW35ZB6XUVcrk9/ls5UQqI2EoADWjJylDIP3N3 2q8AcVnChpIfa27bmObJtUchoPN0zWMq0FHPVy+wZPQpSTgWNVBzE42H6zoNU3Kb Hf1JT2IZc9Eo6Ok44pC5R2PV+FUvCXqHT6g19LwBBBpPc375ULobWDkT2l0SbGPi 33RqudkLKZ21ovh9NElA7WQRr9dKwBfUxHFGVJL39vY3/bZ16TdGxu39VoxJwxyp 4V/1+533TLTaeOhpot9+pAD2O7mvUfycyb8Ql5TecqdSk8G5NwwhHNBdezEV51fk 82parGQBzQ/XKVAXQ1mFXsrzkA+Xwnrc59lWLdohji2eXc+JITNSMWOinL0bsEcA sZUu7F0q4+9WTiuv7SU/ADXd7Kfu7W8CtiTZnP56j4A3FxgxOe2OjYL3Ml0Ke0FU fwbtMAtrEQrbFmPIDaKGa8myEo38Y57/WxGToNyj7uu6SWEYyn6vBnUM/QWZs9Z8 +V6NZvPJCfr8jmjTZcTFwJpPb6ll4a/ZUnG9pR+PwR7d8pIjXTdNJXP7b8LYwFmK 3/VBfCalDo+5b5I+k6FTxcJxygddEYrszaKLrCRARRjEuabmjTdQWSezAOp9qvh4 mi2JhNA7Oq3FZ4JSLv+8PSVAkmiE3TJ/kDaUQTJ+d0N+W1uy7qQ= =nbj5 -END PGP SIGNATURE-
Accepted debmirror 1:2.33 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 12 Dec 2019 00:24:23 + Source: debmirror Architecture: source Version: 1:2.33 Distribution: unstable Urgency: medium Maintainer: Colin Watson Changed-By: Colin Watson Closes: 943970 Changes: debmirror (1:2.33) unstable; urgency=medium . * Use debhelper-compat instead of debian/compat. * Strip trailing spaces and tabs from the content of clearsigned files before verifying the signature, in accordance with RFC 4880 section 7.1 (closes: #943970). Checksums-Sha1: 6355e6e1e51755bb7a1fd51075daca94ea96e4b2 1784 debmirror_2.33.dsc 06b9b0cc1199c2d14888532b2d399b06e658fa70 54976 debmirror_2.33.tar.xz Checksums-Sha256: 7ce999e50424e6a4b252410ee8990d0bf86a20aba9e4ed20921a847c101ddaf5 1784 debmirror_2.33.dsc 2f4e197c975d6cd7d8d406191f9d6eeedfd7ba64faf3057c3ee61006cbc92023 54976 debmirror_2.33.tar.xz Files: 2f3ea3bba96ddf728cb32fe9a5d6c821 1784 net optional debmirror_2.33.dsc e02ca3aaefd43f2e4b0f9cde4d227d49 54976 net optional debmirror_2.33.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAl3xiSsACgkQOTWH2X2G UAvJGBAAtldIUZf17wNH8P1O+4L+kty2hxwpgEUhIMJWxsY7Z9zFvi45+BeirKSO oYOtRVcEfW/4q+uwgCuGJfJWX7hGlczNmP6x79CV1sfejxQX39jABtat6FlnRXpe sEm5dKMz8WlaQ8UKi4BOVuz95XIbUGluAX/drycGedGVcPmAETe4+zu+rS/rbzQQ 3L0AX0th9E8qnel2V7hDqev4NmF+b+2H0kzJsE1He8K1vK+pX995ifGbefRm6Kq3 3ieBmvL2si8aWsmId/Z3qsT/LM4ydMs7MAav0mPvxD42fneyYdHZxv7grzWpGYkG ZmdK/bQGBMO5FYj4IPlliWwfm02WjucIUlYDQ1vIotIoPlP0f0f0Q4/Wj6B8fLC8 Tca2n0LEmlVbK7Zi/um3NeQI334MOoMB+ZF98YU85Uvp/NhYermYj+r+K4Mvs3N7 HHzNdnxgD5L0x2L1lNkhaSl+evoVxE9lcovzUubGufyBkH7c1WmapAnP0pBc92xl PEkV/FrqGXhKtyiElfHzOBmTrnR0S028Ju+FR7A6zj28S++BQwlXnbaeXEIPYe1Y 9uy++NmLdPczifYvZT0qYhdqgzGwrcbXz/GLlPwXdQxn6vimrbxn5LsGpqULqbnr +WhAADBaoZSnDgKQu7rtx40B4NshZvw2cmqtjWhsDpWASnWAq8w= =JZyv -END PGP SIGNATURE-
Accepted man-db 2.9.0-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 12 Dec 2019 00:22:16 + Source: man-db Architecture: source Version: 2.9.0-2 Distribution: unstable Urgency: medium Maintainer: Colin Watson Changed-By: Colin Watson Closes: 945909 Changes: man-db (2.9.0-2) unstable; urgency=medium . * AppArmor: Allow groff to read /etc/papersize (thanks, Bruce Momjian; closes: #945909). Checksums-Sha1: 8ac8daecd8bbe449745d0be76004adf16e304e05 2436 man-db_2.9.0-2.dsc 219b0f5823f9e6c32387f6a4f5c4b452085e8477 72420 man-db_2.9.0-2.debian.tar.xz Checksums-Sha256: 3e36a44af2bb694410fb6e67273163b6aa05eab3a77c1dbc4d20612f06c7ec42 2436 man-db_2.9.0-2.dsc 877aec1cd5edbf22828ecab2a597eeb1e2ddd8dde95f0dbf0a6d283924c2a6b7 72420 man-db_2.9.0-2.debian.tar.xz Files: 658a003fb607aec5fea5c8dc773e17eb 2436 doc important man-db_2.9.0-2.dsc 7c11851ab83c04098776b4934fe6e409 72420 doc important man-db_2.9.0-2.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAl3xiFsACgkQOTWH2X2G UAvtrRAAmUdO0Aoibgdg6eqfZH/oezvq8Xn2OKGcvPQKEioRGLhaQpJRQ6+/GJnW Pn+1G++C/JRGdvxmS0XY3Yexdqo50zH90k+RI0f82eM1c9DkC2TtMoWZo9h1p8Qn by3i0imG8wdHWvUde9GPYJuZV4hu25OX7K1GYi9WRgiJrJkhfa5+j2w5wGwmXOBw mNBDufwjH02ULookzUABsFUuq8XIatj0SqHe/AwfEwxrAyeaGt9w8DRAq0v9GP4g OY16/I/bDYHhgZmt6BthAQQItWWQLgu+OOPPRySPuQ95ujlEH1Y1ATiYtDD9nDy5 xqx1WoA/6yP76d/ul/g064OA7xG4DHVNFKY3avk8osvV+UxtGAVx+HAwRuT6o73E 1n8c+Kr7zDXnjfSCTDFJqHlrNAq+lXLVKVW+4RnDzfUc2kVqGmJmCO06qYXOVtrN SNa+Ovg6g+KRwDNNegWWF5Nsp5P+piZA2BCUfo0rVLVFsp1yIWi/7uSPhT0bSAWF NFIfqXrCA30Cer/azcQeQJH7A1SdAx1LMrLewf2fyJOHKYynRa4diqsZtTsjevl9 d8Vdf8e3L27zzLEXvBNW0nX1DfxORPJ9SGWsdf+/ssrSb/sNJKZxXowe5tHRtvcq ExcXsT8C+LiVugRQrPRLDiZMvbhlVajHilMeKwATR95o1xozgPY= =geqg -END PGP SIGNATURE-
Accepted openssh 1:8.1p1-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 11 Dec 2019 23:53:49 + Source: openssh Architecture: source Version: 1:8.1p1-2 Distribution: unstable Urgency: medium Maintainer: Debian OpenSSH Maintainers Changed-By: Colin Watson Changes: openssh (1:8.1p1-2) unstable; urgency=medium . * Drop "Allow flock and ipc syscall for s390 architecture" patch for now; upstream has security concerns with it and it doesn't currently seem to be needed. * Mark openssh-sftp-server, openssh-tests, ssh, and ssh-askpass-gnome as Multi-Arch: foreign; none of them provide any architecture-dependent interfaces. Checksums-Sha1: f21206a394c401d829cf9d99ec54a81cda8498eb 3316 openssh_8.1p1-2.dsc c1c81e566fda1fc7c15116ca2c6c3da0abfd9058 171280 openssh_8.1p1-2.debian.tar.xz Checksums-Sha256: 152f1eb5e1af12b2a92fcf53786ce879d39ad05b58bf18bce20e6fbeb5ea6903 3316 openssh_8.1p1-2.dsc 2b08ea2c5c33d71816a2d6bd47f752b25f2117ae920ba4bcb9f98b718f63ccda 171280 openssh_8.1p1-2.debian.tar.xz Files: 379627b879fe509dba88fe5504ac0dfe 3316 net standard openssh_8.1p1-2.dsc 9384f32c73637a49fd5469326acedc2f 171280 net standard openssh_8.1p1-2.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAl3xgbkACgkQOTWH2X2G UAtNuA/+MW69kc5QP8lJFdLjII4s998J+ajql/zl3B1iRKgPFas8vko3WdVJQeg7 QUobcyqbedYMM8Z45i1O4lA92WW6XuvU5xwYEkCPN8Q/VyJgyGBqCkeowN6gRsx1 9Oowoz2Pc4bXka4YPLCeKpl47NS7JnZwTPpEg1HFaq9tAEY9/4UkQeDKWUbb1lNK YpV6libeQlAiQnukKZmGv5FkA7oPoE0S/d0faP91B1QaM/7Htan8werlsTYSigsX j8N46lfAKNqJ76Zwci3Fn7S1eaKq338ISgN1mkF89rvCHSlOqr7Q8FHhp/r2Zqc/ BhluubokrP3WCJUvg323QZYbjCw+CDeqAGhy8xe7N1HtrbO/a+Oo/bTdPlwSVKtg rObReRYjG5MIIQPt2c8kvYnkLI4q915bq39zJ/otS1S6Sc1t51CE9Uy1NGJXY+CB Af9LZOikBP/j/Pj3bCoXbvzsgIQLzL0Z7Q6onEZJlo8bM8F9gO4cbe8tFXSyvWfO z0IacFMERfCUL2LAszxk58OpEoeaRf94wgHBScmbWRfhdVM04HOCQLhqghl8iFFF U3DUxOPbEsnz3CCuWJZvFLZJDqUpRdXdsHadS0l9Y5j4wdAng/0y9Qh5G69IINAo Tmx4PCO16ujQnIXQNOCjWsZKREyMKc2VKa2gMyDZXTejl0VUMI4= =GvfD -END PGP SIGNATURE-
Accepted python-tblib 1.6.0-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 09 Dec 2019 10:09:57 + Source: python-tblib Architecture: source Version: 1.6.0-1 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team Changed-By: Colin Watson Changes: python-tblib (1.6.0-1) unstable; urgency=medium . * New upstream release. Checksums-Sha1: fbf45f2c789fc1448d55c5167d3112f2761d9415 2212 python-tblib_1.6.0-1.dsc 4efe676e4ae54e04d5d7f4ce17f19436b43b21c1 31450 python-tblib_1.6.0.orig.tar.gz 4fd15321a75fc8a8e96c8206bdb53d1b6a82453c 2936 python-tblib_1.6.0-1.debian.tar.xz Checksums-Sha256: 84299d2a863d02075b90c19f73931e4988c80d8bd417fb9db64b68e2b6e9e9de 2212 python-tblib_1.6.0-1.dsc 229bee3754cb5d98b4837dd5c4405e80cfab57cb9f93220410ad367f8b352344 31450 python-tblib_1.6.0.orig.tar.gz 4a396e2c986bfd5b1eb89d38fd904d7d923ad16f2bcc76dccf4a6b1d3f3fb783 2936 python-tblib_1.6.0-1.debian.tar.xz Files: 0ab5126ff5949b7f7e0d90bcbde8b4e9 2212 python optional python-tblib_1.6.0-1.dsc 7dd37394a2174b522ab046fbfc386dc9 31450 python optional python-tblib_1.6.0.orig.tar.gz a0da1a7899fe9cacf5557c0dcb099670 2936 python optional python-tblib_1.6.0-1.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAl3uHfsACgkQOTWH2X2G UAtiQQ//ccMEXEc/RwffK6Xxc3Y4s2d+JWz6n3KKowfHANCLFii3KAljap8BwLKq 93Na2TGLJ3EIwsPZ8jy/HtSUrLdotE+n130SSdp+OZN62K67ykWJ9/U3LcVsyO+7 gr/neBOGkJQ3nlhuqTpag14I1uLdmSiLpxTQWX94abazI+51CAu/CmgVBAVk3b+j LaPxQrxuUHAwZbAoXnTDdoGwh65BYeE0VGc8J2p6C6jAFc5em7ZgkkCaY52B6c4Q 02vrPHzGNsSQwSHtaLdjjeWxS5KnyGOotg3H0sbUlfjeLA8RKIb+JmskJ2VsrYr4 lNhnD37DyzooaJhDpCrETaUVLeiTklKv32SlXgrVwwiFBpMTTp16Yt9CxINTvZlA kjmFFt+rk6ryjbKIWAfWbF+oShGd9oNcRfNJ67NGDeIMjA62aoFD2p1MtBCOG78O 5fCtbZvx0jOVDiaaIVmleWCxVgoMFcDGmoRJ4UGqvTlY/RGNVd+QJm+dNyzVxEvC Mv9+X8SJQij6wII0zmOuUjJDxnz0cZ2/mk+eSBkT4E/ChzTk1zsyE93gg/vcG7I7 mB5QMwP5BSjvEQZYjzJ9CZ1Lj2w+01BTK/zUjKjPGBNGdpG4g2158g1nXGV6Fj1Y 3Jn7DWWxw0o+B7aQBWxcjk9j22TeNDN8+SgIsN60bhlHZqSzo84= =XzXj -END PGP SIGNATURE-
