Re: tomcat9 using systemd specific stuff is now vendor lock-in [was: BITS from the DPL For September/October 2019]

On Nov 01, Thomas Goirand wrote: > Instead of using well understood parameters to adduser, which we've been > using for decades, and understand well the parameters, systemd provides Personally I never remember the exact semantics of many adduser/addgroup parameters and I have to double check

Re: Integration with systemd

On Oct 31, Svante Signell wrote: > When elogind enters testing there would be many more people running > Debian with sysvinit/elogind. elogind is needed for desktop usage when > not using systemd as PID 1. And as said numerous times Debian elogind is already in testing: I will be delighted to

Re: Integration with systemd

On Oct 31, Simon Richter wrote: > However, a lot of our software comes from the BSD world and will never > fully switch to systemd, and that software is often used in server contexts > by people who know exactly what they are doing. I don't see why we > shouldn't support these people anymore,

Re: Integration with systemd

On Oct 31, "Theodore Y. Ts'o" wrote: > handled on a case by case basis. Exactly how much of a win do we get > if we use a particular systemd feature in core Debian packaging? How > hard is it to emulate that for non-systemd systems? I don't think > that decision can be made in the abstract,

Bug#942321: ITP: fort-validator -- An RPKI Validator and RTR Server

Package: wnpp Severity: wishlist Owner: Marco d'Itri * Package name: fort-validator Version : 1.0.0 Upstream Author : NIC MX and LACNIC * URL : https://nicmx.github.io/FORT-validator/ * License : MIT Programming Lang: C Description : An RPKI Validator

Accepted whois 5.5.2 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 02 Oct 2019 23:44:49 +0200 Source: whois Architecture: source Version: 5.5.2 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Changes: whois (5.5.2) unstable; urgency=medium

Accepted rblcheck 20190930-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 30 Sep 2019 15:47:05 +0200 Source: rblcheck Architecture: source Version: 20190930-1 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Changes: rblcheck (20190930-1) unstable; urgency

Accepted inn2 2.6.3-3 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 18 Sep 2019 11:27:32 +0200 Source: inn2 Architecture: source Version: 2.6.3-3 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Changes: inn2 (2.6.3-3) unstable; urgency=medium

Accepted kmod 26-3 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 17 Sep 2019 21:40:12 +0200 Source: kmod Architecture: source Version: 26-3 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Closes: 931136 940221 Changes: kmod (26-3) unstable

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

On Sep 16, Sam Hartman wrote: > * Work to understand why people are using Github. From my past For the same reason why most people are using Twitter instead of Mastodon: the community and network effect. This is not a technical problem, so it cannot be solved by Debian. All my packages are on

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

On Sep 13, Ondřej Surý wrote: > > We are talking about preventing large scale censorship (I do not think > > that this is really about privacy) for *general users*: obviously *we* > > already know about countless workarounds. > That’s a false statement. Right now, we are talking about sending

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

On Sep 13, Jeremy Stanley wrote: > Note that by way of counterargument, Google and its services have > been blocked in mainland China by the Great Firewall for nearly a > decade now, so I question whether there is really such a thing as > "too big to block." This is a false dichotomy: not all

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

On Sep 13, Thomas Goirand wrote: > You shouldn't insist on always writing "their ISP", as if it was the > only choice. It isn't. One can setup his own recursive DNS locally, for > example. I've done this for years, as I didn't trust my ISP (first, in Sure, me too: but it does not matter, because

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

On Sep 12, Wouter Verhelst wrote: > Except all they need to do is return NXDOMAIN on the > "use-application-dns.net" domain, and Presto! they can spy on their > users again. They need to have a government to compel then to do it, which is not obvious. And then Mozilla will disable that (you can

Re: should Debian add itself to https://python3statement.org ?

On Sep 12, Alf Gaida wrote: > It doesn't really matter. In fact python2 is dead for years, if we > start now to make a plan we are years to late. The timeframe is _now:. Dead for who? As long as somebody will be interested in maintaining python2 it will not be dead. I maintain some packages

Accepted kmod 26-2 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 11 Sep 2019 09:29:57 +0200 Source: kmod Architecture: source Version: 26-2 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Closes: 939779 Changes: kmod (26-2) unstable; urgency

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

On Sep 09, Adam Borowski wrote: > With DoH: > * the target server knows about you (duh!) > * the ISP can read the destination of every connection > [reading the IP header, reading SNI header] > * the ISP can block such connections > [blocking actual connection] Well, no. They cannot without

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

On Sep 08, Ondřej Surý wrote: > I would rather see an explicit statement. I would be very surprised > with Debian’s usual stance regarding the users’ privacy that we would > not consider this as a privacy violation, but again I am not Firefox > maintainer in Debian and I would rather hear

Accepted usrmerge 23 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 03 Sep 2019 02:20:46 +0200 Source: usrmerge Architecture: source Version: 23 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Changes: usrmerge (23) unstable; urgency=medium

Re: Git Packaging: Native source formats

On Aug 30, Scott Kitterman wrote: > It's not particularly rare for me to poke through other distros package > patches when I'm trying to figure out how to solve a problem. I suspect I'm I would even say that maintainers who do not periodically review what other distributions do with their

Accepted rbldnsd 0.999~20180516-3 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 29 Aug 2019 16:01:06 +0200 Source: rbldnsd Architecture: source Version: 0.999~20180516-3 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Changes: rbldnsd (0.999~20180516-3) unstable

Accepted rbldnsd 0.999~20180516-2 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 29 Aug 2019 14:27:27 +0200 Source: rbldnsd Architecture: source Version: 0.999~20180516-2 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Changes: rbldnsd (0.999~20180516-2) unstable

Accepted rbldnsd 0.999~20180516-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 29 Aug 2019 12:47:49 +0200 Source: rbldnsd Architecture: source Version: 0.999~20180516-1 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Changes: rbldnsd (0.999~20180516-1) unstable

Accepted ifmail 2.14tx8.10-26 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 26 Aug 2019 18:58:25 +0200 Source: ifmail Architecture: source Version: 2.14tx8.10-26 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Changes: ifmail (2.14tx8.10-26) unstable

Accepted ifmail 2.14tx8.10-25 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 26 Aug 2019 01:08:43 +0200 Source: ifmail Architecture: source Version: 2.14tx8.10-25 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Closes: 872507 929239 933938 Changes: ifmail

Accepted inn2 2.6.3-2 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 19 Aug 2019 05:16:59 +0200 Source: inn2 Architecture: source Version: 2.6.3-2 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Closes: 931256 Changes: inn2 (2.6.3-2) unstable; urgency

Accepted whois 5.5.1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 18 Aug 2019 19:47:55 +0200 Source: whois Architecture: source Version: 5.5.1 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Changes: whois (5.5.1) unstable; urgency=medium

Re: duplicate popularity-contest ID

On Aug 05, Bill Allombert wrote: > Each Debian popularity-contest submitter is supposed to have > a different random 128bit popcon ID. > However, the popularity-constest server > receives a lot of submissions with identical popcon ID, which cause them > to be treated

Re: tag2upload (git-debpush) service architecture - draft

On Aug 02, Sam Hartman wrote: > In effect, ftpmaster is saying they are uncomfortable trusting > tag2upload very much. A simple solution to this concern would be for ftpmaster to take over the operations of tag2upload once it will be ready. -- ciao, Marco signature.asc Description: PGP

Re: default firewall utility changes for Debian 11 bullseye

On Aug 01, Aron Xu wrote: > If there is no pre-installed firewall application in a standard/full > installation (which does not exist for us theoretically), Debian could > be easily marked as missing feature in some enterprise IT evalutation, [citation needed] Even if this were true I do no

Re: default firewall utility changes for Debian 11 bullseye

On Jul 31, Aron Xu wrote: > utility (for instance, firewalld) for certain use cases, i.e. it could > be useful for a "standard" server installation with graphic desktop, > for which we could expect most users choosing this method would like > to have advanced firewalling as an enterprise feature

Re: default firewall utility changes for Debian 11 bullseye

On Jul 31, Scott Kitterman wrote: > Please don't install one by default. I suspect it will cause more > trouble for end users than it's worth. Making sure our default > install is severely limited in what ports it listens to is likely more > broadly useful and less risky. Agreed.

Re: tag2upload (git-debpush) service architecture - draft

On Jul 28, Bernd Zeimetz wrote: > So I think the best thing to do is to get sha256 working in git and > force the usage of sha256 if you want to sign a tag for upload. This cannot be a goal for this project since git upstream will need apparently a few more years for the transition to sha-256

Re: Challenge from Julia's non-standard vendored openblas"64_"

On Jul 28, Mo Zhou wrote: > 2. Specifically compile a libopenblas64_.so >from src:openblas for julia's use. >This looks very bad for src:openblas's >package layout. Why would this look bad? We have plenty of source packages which generate multiple variations of binary packages.

Accepted tin 1:2.4.4~20190307-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 22 Jul 2019 01:56:42 +0200 Source: tin Architecture: source Version: 1:2.4.4~20190307-1 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Changes: tin (1:2.4.4~20190307-1) unstable

Accepted libberkeleydb-perl 0.62-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 21 Jul 2019 13:06:21 +0200 Source: libberkeleydb-perl Architecture: source Version: 0.62-1 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Changes: libberkeleydb-perl (0.62-1

Re: seccomp woes (was: file(1) now with seccomp support enabled)

On Jul 20, Christoph Biedl wrote: > * Centralize the list of supported archs in the seccomp packages. By > either creating an empty libseccomp-dev for the archs where seccomp > is not supported, or by creating a "libseccomp-dev-dummy" for these. > In the latter case package maintainers

Accepted whois 5.5.0 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 19 Jul 2019 11:31:42 +0200 Source: whois Architecture: source Version: 5.5.0 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Closes: 774603 931244 931336 Changes: whois (5.5.0

Re: default firewall utility changes for Debian 11 bullseye

On Jul 17, Paul Wise wrote: > To me, something like opensnitch seems like a better option for a > desktop firewall once it becomes more mature and enters Debian. This project is a "personal firewall", which is a quite different thing from what is being discussed here. -- ciao, Marco

Re: Bits from the Release Team: ride like the wind, Bullseye!

On Jul 07, Jonathan Wiltshire wrote: > Q: I already did a binary upload, do I need to do a new (source-only) > upload? > A: Yes (preferably with other changes, not just a version bump). Is there any good reason why we still do not have an interface to allow developers to self-service

Accepted whois 5.4.3 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 12 Jun 2019 15:03:56 +0200 Source: whois Binary: whois whois-dbgsym Architecture: source amd64 Version: 5.4.3 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Description: whois

Accepted usrmerge 22 (source all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 09 Jun 2019 14:54:21 +0200 Source: usrmerge Binary: usrmerge Architecture: source all Version: 22 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Description: usrmerge - Convert

Re: @debian.org mail

On Jun 03, Daniel Lange wrote: > It is a data point to prove your "we do not have forged email issues" wrong. By "forged email issues" I mean phishing attacks, not garden variety malware which can be blocked in other ways. -- ciao, Marco signature.asc Description: PGP signature

Re: @debian.org mail

On Jun 03, Daniel Lange wrote: > > -all would stop some forged emails, but we do not have forged email > > issues. > We do. 4% of this year's spam in my spam traps have originated as fake > @debian.org. Unfortunately we even nicely relay them as we can't tell This is not a meaningful figure

Re: @debian.org mail

On Jun 03, Russ Allbery wrote: > A possibly useful compromise is to do what Marco suggested: publish SPF > records for domains like lists.debian.org, where all the mail is coming > from Debian infrastructure. That can easily be -all. And then at least > we have the option of moving some of the

Re: @debian.org mail

On Jun 03, Sam Hartman wrote: > But more than that, you don't need the SPF record. (Here comes a short lesson on email authentication...) The most useful way to think about SPF and DKIM is that they allow to move reputation considerations for a message from the sender IP address to the sender

Re: Stalls due to insufficient randomness in cloud images

On Jun 03, Bastian Blank wrote: > Does anyone know what RHEL8 (which should have this problem as well) > does to "fix" this problem? RHEL8 enables by default rngd from rng-tools, which looks much better to me than haveged. -- ciao, Marco signature.asc Description: PGP signature

Re: @debian.org mail

On Jun 03, Daniel Lange wrote: > The default reply for missing wafer confirmation emails (the software > running debconf19.debconf.org) and missing salsa password reset emails is > "check your Spam folder". Debian.org doesn't have a SPF record so mail > submitted from such Debian machines is a

Re: Cdbs Features

On May 22, Wouter Verhelst wrote: > I think at this point we can recommend dh, and require debhelper (i.e., > the individual dh_* tools could be required to be part of the build > system, but how they are called can be left to a maintainer's > discretion, with the assumption that "you use dh or

Bug#929024: ITP: routinator -- An RPKI Validator

Package: wnpp Severity: wishlist Owner: Marco d'Itri * Package name: routinator Version : 0.3.3 Upstream Author : NLnet Labs * URL : https://nlnetlabs.nl/rpki * License : BSD Programming Lang: Rust Description : An RPKI Validator The Routinator 3000

Re: Do we want to Require or Recommend DH

On May 13, Sam Hartman wrote: > As promised, I'd like to start a discussion on whether we want to > recommend using the dh command from debhelper as our preferred build > system. I have already asked this last time, but nobody answered. I use debhelper in all of my packages but I have never

Re: fixing debian-security-support upgrades from stretch (for good)

On May 13, Holger Levsen wrote: > So I think this can only be fixed properly (=without asking people to > upgrade to the latest stretch pointrelease but instead allowing upgrades > to buster from *any* stretch pointrelease) by adding a "pre-depends: > debian-security-support (>= 2019.04.25)" to

Re: native packages? (Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells")

On Apr 15, Sam Hartman wrote: > However if my sources are in git, git is the definitive format for > thinking about things, and the dsc I'm producing is only for the > convenience of the archive, I don't want to deal with an upstream > tarball. Generating an upstream tarball in this case is

Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"

On Apr 13, Lucas Nussbaum wrote: > TL;DR: see https://trends.debian.net and Nice. I suggest to add a graph detailing: - packages with at least one init script - packages with at least one systemd unit - packages with at least one init script and one systemd unit Also, did I miss the memo about

Accepted whois 5.4.2 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 28 Mar 2019 00:48:28 +0100 Source: whois Architecture: source Version: 5.4.2 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Changes: whois (5.4.2) unstable; urgency=medium

Re: Debian vs Linux namespaces

On Mar 23, Harald Dunkel wrote: > AFAICS there are several packages that appear to be unaware of / > do not care about containers, e.g. opensmtpd, bind9, apt-cacher-ng, > probably everything using pidof or pidofproc from /lib/lsb/init-\ > functions). I routinely use containers and namespaces

Accepted tcp-wrappers 7.6.q-28 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 18 Feb 2019 01:54:18 +0100 Source: tcp-wrappers Architecture: source Version: 7.6.q-28 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Changes: tcp-wrappers (7.6.q-28) unstable

Accepted openbsd-inetd 0.20160825-4 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 18 Feb 2019 01:31:18 +0100 Source: openbsd-inetd Architecture: source Version: 0.20160825-4 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Changes: openbsd-inetd (0.20160825-4

Accepted tin 1:2.4.3-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 17 Feb 2019 23:41:06 +0100 Source: tin Architecture: source Version: 1:2.4.3-1 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Closes: 232924 Changes: tin (1:2.4.3-1) unstable

Accepted inn 1:1.7.2q-46 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 17 Feb 2019 20:18:43 +0100 Source: inn Architecture: source Version: 1:1.7.2q-46 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Changes: inn (1:1.7.2q-46) unstable; urgency=medium

Accepted binkd 1.1a-99-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 17 Feb 2019 19:37:52 +0100 Source: binkd Architecture: source Version: 1.1a-99-1 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Changes: binkd (1.1a-99-1) unstable; urgency=medium

Accepted ifmail 2.14tx8.10-24 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 17 Feb 2019 19:16:41 +0100 Source: ifmail Architecture: source Version: 2.14tx8.10-24 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Changes: ifmail (2.14tx8.10-24) unstable

Accepted inn2 2.6.3-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 17 Feb 2019 17:52:36 +0100 Source: inn2 Architecture: source Version: 2.6.3-1 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Closes: 886255 Changes: inn2 (2.6.3-1) unstable; urgency

Accepted usrmerge 21 (source all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 17 Feb 2019 17:44:25 +0100 Source: usrmerge Binary: usrmerge Architecture: source all Version: 21 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Description: usrmerge - Convert

Accepted netbase 5.6 (source all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 10 Feb 2019 03:05:36 +0100 Source: netbase Binary: netbase Architecture: source all Version: 5.6 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Description: netbase- Basic TCP

Accepted libberkeleydb-perl 0.55-2 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 10 Feb 2019 01:22:03 +0100 Source: libberkeleydb-perl Architecture: source Version: 0.55-2 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Changes: libberkeleydb-perl (0.55-2

Accepted kmod 26-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 10 Feb 2019 00:00:31 +0100 Source: kmod Architecture: source Version: 26-1 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Changes: kmod (26-1) unstable; urgency=medium . * New

Re: Namespace for system users

On Feb 09, Sean Whitton wrote: > ISTM to me we have a consensus, at least, that new packages with system > users should use the underscore prefix convention. There isn't a > consensus on what to do about old packages, but Policy can be written in > such a way to refer only to new packages with

Accepted whois 5.4.1 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 27 Jan 2019 04:48:53 +0100 Source: whois Binary: whois whois-dbgsym Architecture: source amd64 Version: 5.4.1 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Description: whois

Re: Handling of entropy during boot

On Jan 16, Guido Günther wrote: > There's also jitterentropy-rngd which does the trick but I haven't > looked at the security implications. Nowadays rngd collects jitter entropy, so I would not use something else. -- ciao, Marco signature.asc Description: PGP signature

Re: Json-c library installed into /lib/ instead of /usr/lib/ ... is that relevant anymore?

On Jan 15, Boyuan Yang wrote: > I digged a little bit into it and found out that it was originally due to > upstart that needed it during bootup [2] so the lib should be placed into /lib > according to FHS. However, with upstart disappeared from Debian archive (since > 2016), other init systems

Re: Handling of entropy during boot

On Jan 13, Sam Hartman wrote: > I recently discovered that Vmware appears to have no virtual RNG > available to the guest at all. AFAIK you are right. > A buster vmware guest will boot but will be unable to start sshd because > of lack of entropy for typically five minutes or so. > A lot of

Re: Handling of entropy during boot

On Jan 09, "Theodore Y. Ts'o" wrote: > x86 systems have a high resolution timer; Rasberry PI's don't. > Furthermore, if libvirt is miconfigured, it should just be fixed (and > better yet, it should be configured to enable virtio-rng, which is > *not* hard). Can you clarify what is the best

Re: usrmerge -- plan B?

On Dec 23, Martin Steigerwald wrote: > I think I have seen this with either SLES or RHEL that they created > symlinks for every binary in /bin and /sbin, pointing to the binary in > /usr/bin and /usr/sbin. I did not understand why at the time I have seen > this. Definitely not RHEL, maybe you

Re: usrmerge -- plan B?

On Dec 23, Guillem Jover wrote: > To me it's always been very clear the only *proper* way to deploy > merged-/usr, is to do the changes to the canonical pathnames on > each relevant package. Even adding compat symlinks, means that dpkg > would know about them, and they'd be temporary anyway for

Re: usrmerge debian implementation

On Dec 10, d.dob...@tuta.io wrote: > > I have read that debian was struggling with their implementation of > > usrmerge. This is not true. > > How does the symbolic link method bejng employed differ from that of > > gobolinux's "gobohide"? This "gobohide" thing does not actually move the

Accepted usrmerge 20 (source all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 08 Dec 2018 23:37:38 +0100 Source: usrmerge Binary: usrmerge Architecture: source all Version: 20 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Description: usrmerge - Convert

Re: usrmerge -- plan B?

On Dec 04, Russ Allbery wrote: > Does this imply that you're considering adding support for merging /usr > *properly* directly inside dpkg, with all the correct updates to dpkg's > metadata? > > Because that would be an awesome way to fully support this. It would make using dpkg -S a bit easier

Re: Sending using my @debian.org in gmail

On Nov 30, Alexandre Viau wrote: > - https://en.wikipedia.org/wiki/DMARC Among other issues, the BTS is still not compatible with DMARC. -- ciao, Marco signature.asc Description: PGP signature

Re: usrmerge -- plan B?

On Nov 28, "Alexander E. Patrakov" wrote: > Well, the buildd configuration change has been reverted. What worries me now > is that there is a risk not yet mitigated, coming from personal systems of > Debian developers, and we should also check porter boxes. This is not a new problem at all: in

Re: usrmerge -- plan B?

On Nov 26, Marc Haber wrote: > I would be willing to do this on production systems that can easily be > snapshotted and reverted in no time during an upgrade change, such as > VMs. Unless forced to, I'd rather not touch systems running on bare > metal and would need a restore-from-backup should

Re: usrmerge -- plan B?

On Nov 26, Ian Jackson wrote: > I could do it. But, frankly, this is quite a lot of work. I think > the work (throughout the Debian ecosystem) to test this properly far > outweighs the minor benefits. I disagree both that simple testing (that you could do with a KVM snapshot as well) would be

Re: usrmerge -- plan B?

On Nov 26, Bjørn Mork wrote: > "Migration is not (easily) reversible" was reported as important in > 2016: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848626 This is not a bug: nothing is misbehaving, so classifying this as wishlist is correct. I even doubt that it would be technically

Re: usrmerge -- plan B?

On Nov 26, Didier 'OdyX' Raboud wrote: > Sorry to be blunt about this, but have you reported these? Sniping at (any) No, they have not. There is a lot of handwaving in this thread but very few results of actual tests. After creating again unmerged chroots for the buildds the only bugs left,

Re: usrmerge -- plan B?

On Nov 24, "Gabriel F. T. Gomes" wrote: > Has this option been given enough attention? It sounds appealing in Yes. I would love to implement a --dry-run mode, but I still need to figure out how much complex it would be and if it could actually cover all cases. -- ciao, Marco signature.asc

Re: individual packages moving binaries from /bin to /usr/bin (was: Re: usrmerge -- plan B?)

On Nov 22, Ansgar Burchardt wrote: > Well, the iptables case is different: those are compat symlinks created > by the package's maintainer scripts, not the /bin -> /usr/bin symlinks > that merged-/usr sets up. Actually iptables is different because it mixes (incorrectly) compatibility symlinks

Re: usrmerge -- plan B?

On Nov 22, Michael Stone wrote: > Three years ago we were told this was to enable people to optionally do > something, not that all users would be forced to migrate. That's a pretty > substantial change. At this point there is no plan to force anybody to migrate. It has just been argued that it

Re: usrmerge -- plan B?

On Nov 22, Russ Allbery wrote: > I'm stating the advantages of fully converting Debian to merged /usr for > engineering reasons: I don't think the existing optional migration is > going to work very well or be supportable. On this point, I'm > *disagreeing* with the usrmerge maintainer, who

Re: usrmerge -- plan B?

On Nov 22, Matthew Vernon wrote: > > In the worst case it will fail explaining that some local change (in > > a directory which should not have been modified by the local admin, BTW) > > needs to be addressed by the local admin and then it can be restarted > > and continue its work. > Could you

Re: usrmerge -- plan B?

On Nov 22, Michael Stone wrote: > That's not actually what happens: the files are still available in the old > location *if and only if the process is fully successful*. If there are any > issues you have a partially migrated system in which the files are *not* > still available in the old

Re: usrmerge -- plan B?

On Nov 22, Ian Jackson wrote: > I would also like to point out that change planning is the job of > someone who wants to change something. That includes not only: I planned for everything that I could foresee. I did not think about the buildds issue, but this is hardly the first time that some

Re: usrmerge -- plan B?

On Nov 22, Ian Jackson wrote: > I hear there was a major free software project who accidentally > usrmerged their build systems and discovered that they then built > broken packgaes. And it was quickly fixed, so no big deal. -- ciao, Marco signature.asc Description: PGP signature

Re: usrmerge -- plan B?

On Nov 22, Michael Stone wrote: > Again, how many weren't systems you're responsible for? I have no doubt that > you took care of the problems that you encountered personally when you wrote > the tool. I've seen a lot of problems on systems in the wild that don't No: what I meant is that I did

Re: usrmerge -- plan B?

On Nov 22, Jonathan Dowland wrote: > Long-running production systems would presumably be running Stable. We > need testing or unstable systems to try usrmerge. I don't think even > reporting on the success of usrmerge on current-Stable¹ would be > necessarily useful. I use merged-/usr without

Re: usrmerge -- plan B?

On Nov 21, Michael Stone wrote: > How many long-running production systems do you think people have run > usrmerge on? I'd guess close to zero, since there is no advantage whatsoever Actually I have quite a lot personally, with exactly zero problems. On some of them I also enjoy advantages of

Re: usrmerge -- plan B?

On Nov 21, Russ Allbery wrote: > I think there are some arguments to be made for just force-merging and > moving on, but they're mostly "tidiness" arguments (letting everyone No, they are not that at all. I have never argued about "tidiness", nor did anybody else that is working to support

Re: usrmerge -- plan B?

On Nov 20, Adam Borowski wrote: If you are seriously concerned with the small issuses caused by the transition to merged-/usr then I have a better proposal. Plan C: just stop supporting non-merged-/usr systems since these problems are caused by having to support both, and there is no real

Re: Our build system may be broken: /bin vs /usr/bin

On Nov 19, Matthias Klumpp wrote: > I wonder how this was handled on other distributions when they made > the change - even if the change was applied on all systems, there must > have been at least one release where both modes were supported. No, Fedora and RHEL just switched overnight. On Nov

Re: Our build system may be broken: /bin vs /usr/bin

On Nov 19, Dirk Eddelbuettel wrote: > GNU R has long been relying on sed, tar, bzip2, ... and many more base > tools. No issues there. Generally looked for in /bin and found there. Actually this is the root problem: policy says that packages should use the $PATH to search for commands, but your

Accepted netbase 5.5 (source all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 17 Nov 2018 02:50:53 +0100 Source: netbase Binary: netbase Architecture: source all Version: 5.5 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri Changed-By: Marco d'Itri Description: netbase- Basic TCP

<    1   2   3   4   5   6   7   8   9   10   >