Re: MBF: valgrind-if-available

[Ansgar Burchardt]

On Sun, 2022-02-27 at 03:40 +0100, Adam Borowski wrote:
> Among others, "command -v"
[...]
> * built-ins get reported as available.  And busybox has even "dpkg"
>   built-in, with a pretty bad implementation.

Like this?

+---
| % which which
| which: shell built-in command
+---

I suggest to implement a new utility named
`/usr/bin/posix-which2` utility if you do not want that ;-)
(Only after proper standardization of course.)

Ansgar

Re: git & Debian packaging sprint report

[Ansgar Burchardt]

Russ Allbery writes:
> Scott Kitterman  writes:
>> Except that we have different requirements than git.  Git isn't looking
>> for security properties from SHA-1, so it's highly likely it'll meet
>> their accident avoidance requirements long after it's no longer
>> appropriate for security related assertions.
>
>> I don't think adding more SHA-1 in a security sensitive context is a
>> good plan.
>
> I talked this over briefly in the security pod at work with some other
> security engineers who know more crypto than I do to sanity-check my
> initial opinion.
>
> The consensus among all of us was that if you have an opportunity to pick
> something other than SHA-1 when designing a new protocol, you should.

We have that opportunity here, so I guess we should then? :-)

There are also other useful properties the current implementation has:
for example the archive contains the artifact that was signed.  This can
be checked at a later time unlike a Git tag on salsa.d.o that may or may
not exist in the future.  It is always possible to go back to the key
that was used to introduce an artifact without having to trust any
system.

> But
> if it's not simple to pick a different hash, SHA-1 preimage resistance is
> reasonable and the other design properties of the system should dominate
> any concern about SHA-1 preimage attacks.

What about MD5's preimage resistance?  We don't really care about
collision attacks after all.

We have most infrastructure already using SHA-2 and there are
preparations to support newer hashes as well; it is a regression to
introduce a new system bound to SHA1 for the foreseeable future (and
given Git's use of SHA1 their need to require a strong hash is far
less).

Ansgar

Re: git & Debian packaging sprint report

[Ansgar Burchardt]

On Tue, 2019-07-16 at 08:29 +0100, Sean Whitton wrote:
> We also rely on git for security elsewhere.  For example, dak is
> deployed by ftpmasters pushing a signed git tag to salsa; a cronjob on
> ftpmaster then deploys that code.  That's relying on SHA-1 in pretty
> much the same way as tag2upload does, AFAICT.

That is true and I don't like it.  I should probably add a sha2 hash
somewhere.  (Note that we *can* just change it...)

> On Mon 15 Jul 2019 at 10:43PM +02, Ansgar Burchardt wrote:
> > It also has one downside: `git tag` alone won't be enough to generate
> > the required information, but then a special-purpose tool was proposed
> > here already.
> > 
> > The client tool could possibly also just create the .dsc and .changes,
> > except for hashes of the compressed files, and the web service just
> > recreate the tarball and compress them.  That would require near zero
> > trust in the web service, but still allow developers to no longer upload
> > source packages which might be large.  (A bit similar to not having to
> > trust buildds by making packages reproducible.)
> 
> This is certainly an interesting proposal and it would be better for
> users than using dput, as you say.
> 
> An important advantage of the tag2upload solution over such a thing,
> aside from just the fact that it already exists today, is that it allows
> us to move (slowly!) towards replacing source packages with git trees,
> like the rest of the world has.
> 
> git-debpush is such a simple wrapper around git-tag and git-push that
> its users really are uploading only by pushing a signed tag.  Your
> proposal would bake source packages back into the upload process in a
> way that will make it harder to ever get rid of them.

No, my proposal allows to stop generating the "source package" as a set
of real files at any given time.

A "source package" generally consists of:
 - a set of upstream artifacts (currently one or more tarballs,
   signatures); can be the empty set for native packages
 - Debian-specific artifacts
 - the .dsc artifact (generated from the Debian part); consists of:
   - strong cryptographic hashes of all other artifacts
 (Checksum-*, Files, ...)
   - convenience information extracted from Debian-specific artifacts
 (Build-Depends, ...)

Currently we represent all of these as real files that need to be
provided by the uploader.

If you no longer want "source packages" as we have currently, you just
define another representation as the canonical one.

So I would like to just change how developers can provide artifacts to
the archive: upstream artifacts can be specified as either a set of
URLs to retrieve them from or a Git tree; Debian-specific artifacts can
be a Git tree or (for source format 1.0) a diff between two Git trees.

All artifacts provided must be covered by a strong cryptographic hash
which is signed by a developer.  The hash must not only cover the Git
tree object itself, but also all content covered by it.

We currently have "tar" as the serialization format covered by the
strong cryptographic hash and, as I value having a representation of
upstream artifacts in the published archive, believe we should continue
to provide the "tar" files.  However this is not necessary; we could
instead provide only the Git tree.

Currently this proposal should also allow multi-package repositories,
packaging-only repositories, packages using multiple upstream
artifacts, and ensuring Debian uses the same artifact as upstream.  It
does not require any integrity from the VCS system.

I think the .dsc artifact should eventually be split into the two
parts: the list of artifacts (together with strong cryptographic hashes
and where to locate them) signed by the uploader, and the convenience
information extracted from these.  The second part should be generated
by the archive software.

Ansgar

Re: git & Debian packaging sprint report

[Ansgar Burchardt]

Russ Allbery writes:
> Ansgar Burchardt  writes:
>> The client tool could possibly also just create the .dsc and .changes,
>> except for hashes of the compressed files, and the web service just
>> recreate the tarball and compress them.
>
> I think experience with pristine-tar indicates that recreating tarballs is
> unfortunately not trivial.

pristine-tar tries to recreate an arbitrary tarball that was created by
a third-party; in this case both sides are controlled by the same party.
Using the uncompressed tarballs also avoids possible problems from the
compression algorithm.

This is a simpler problem than what pristine-tar tries to solve.

For upstream tarballs, one can fetch them from the upstream source if
matching the upstream release is desired.

Ansgar

Re: git & Debian packaging sprint report

[Ansgar Burchardt]

Russ Allbery writes:
> Ansgar Burchardt writes:
>> Russ Allbery writes:
>>> If so, I think that security model is roughly equivalent to the
>>> automatic signing of binary packages by buildds, so probably doesn't
>>> introduce a new vulnerability,
>
>> It doesn't rely on strong cryptographic hashes to guarantee integrity.
>> To quote Wikipedia:
>
>> +---
>> | Revision control systems such as Git, Mercurial, and Monotone use
>> | SHA-1 not for security but to identify revisions and to ensure that
>> | the data has not changed due to accidental corruption.
>> +---[ https://en.wikipedia.org/wiki/SHA-1#Data_integrity ]
>
>> But developers could instead just sign artifacts using a strong
>> cryptographic hash that will be included in the source package; for
>> example the .orig.tar and .debian.tar which can be made reproducible
>> (git-archive is supposed to be reproducible; compression might not be so
>> just sign the uncompressed version).
>
>> We shouldn't go back to trusting SHA-1.
>
> I'm dubious that we really care that much about a preimage attack on
> SHA-1, but sure, if there's some easy way to use something different, that
> would be more future-proof.

SHA-1 isn't going to get stronger in the future.  The TLS world has
already moved on, OpenPGP is still in the slow process to move on,
Release/Packages stopped using it[1], there is no reason to continue
using it.

There is another advantage to developers signing the artifacts: one
would need much less trust in the service building the source files as
it could only manipulate the .dsc, .changes and compression used.

It also has one downside: `git tag` alone won't be enough to generate
the required information, but then a special-purpose tool was proposed
here already.

The client tool could possibly also just create the .dsc and .changes,
except for hashes of the compressed files, and the web service just
recreate the tarball and compress them.  That would require near zero
trust in the web service, but still allow developers to no longer upload
source packages which might be large.  (A bit similar to not having to
trust buildds by making packages reproducible.)

Ansgar

  [1] Though we still have MD5sum for some suites for jigdo...

Re: git & Debian packaging sprint report

[Ansgar Burchardt]

Russ Allbery writes:
> If so, I think that security model is roughly equivalent to the automatic
> signing of binary packages by buildds, so probably doesn't introduce a new
> vulnerability,

It doesn't rely on strong cryptographic hashes to guarantee integrity.
To quote Wikipedia:

+---
| Revision control systems such as Git, Mercurial, and Monotone use
| SHA-1 not for security but to identify revisions and to ensure that
| the data has not changed due to accidental corruption.
+---[ https://en.wikipedia.org/wiki/SHA-1#Data_integrity ]

But developers could instead just sign artifacts using a strong
cryptographic hash that will be included in the source package; for
example the .orig.tar and .debian.tar which can be made reproducible
(git-archive is supposed to be reproducible; compression might not be so
just sign the uncompressed version).

We shouldn't go back to trusting SHA-1.

> There are also some interesting nuances here around handling DM packages,
> where not everyone with a key in the keyring can upload every package,
> although the obvious way to address that is probably for this service to
> do the same DM checks that ftpmaster would normally do.

We have other permissions checks as well; they shouldn't be
reimplemented in different places.  Instead the archive (dak) should
know who signed the package.

Ansgar

Re: Is it the job of Lintian to push an agenda?

[Ansgar Burchardt]

Russ Allbery writes:
> Matthias Klumpp writes:
>> With two Debian stable releases defaulting to systemd now, I think a
>> solid case could be made to at least relax the "must" requirement to a
>> "should" in policy (but that should better go to the respective bug
>> report).
>
> The Policy process is not equipped to deal with this because that process
> requires fairly consensus, and I don't believe that's possible to reach on
> this topic.

If we have no consensus that doing something is the right thing, then
lintian should probably not start raising a warning about it and one
should keep in mind that Policy might not reflect consensus when
referring to it.

Ansgar

Re: git & Debian packaging sprint report

[Ansgar Burchardt]

On Thu, 2019-07-11 at 17:58 -0300, Antonio Terceiro wrote:
> > We designed and implemented a system to make it possible for DDs to
> > upload new versions of packages by simply pushing a specially
> > formatted git tag to salsa.
[...]
> If the uploads will be done by a service, this means that all of them
> will be signed by a single key and not by the DD key. Is ftp-master
> ok with that?

Depends on a lot of things.  As far as I understand this work is in a
very early stage and a first brainstorming session on what problem this
is intended to solve, why one should consider doing it, and possible
requirements is planned for DebConf[1].

Without having any of these, it is hard to comment on anything.

Ansgar

  [1] 
https://debconf19.debconf.org/talks/68-one-git-to-package-them-all-and-on-the-salsa-find-them/

Re: The Difference between debcheckout and dgit and what they try to accomplish

[Ansgar Burchardt]

On Thu, 2019-06-20 at 10:52 +0200, Enrico Zini wrote:
> This reminds me of something that popped up in a dinner discussion a few
> days ago: mandate documenting workflow in debian/README.source no matter
> what, and allow to symlink that file to a repository in
> /usr/share/doc/somewhere/ as we do for common licenses.

My workflow also includes getting changes merged upstream, so any such
documentation would need to include the upstream workflow. Information
how to contribute also includes code style (spaces vs tabs), naming
conventions and so on.

I'm not willing to write such things down for Debian for the rare case
someone might read it; there are enough other things that need to be
done.

Ansgar

Re: The Difference between debcheckout and dgit and what they try to accomplish

[Ansgar Burchardt]

Russ Allbery writes:
> Colin Watson writes:
>> Is it at all likely that the ftpmaster api service might migrate away
>> from Let's Encrypt at this point?  I would assume probably not.  In that
>> case, you could at least make the situation substantially better with no
>> further DSA work required by pinning the appropriate LE root certificate
>> in dgit.
>
> debian.org already publishes a CAA record, which conveys that information
> (although has its own verification concerns, but I think debian.org is
> using DNSSEC so you can verify the record that way).  It says that all
> debian.org hosts will only use certificates from either LE or Amazon:

The CAA record does not indicate a future commitment and could change at
any time.  If you want to rely on debian.org to use some specific CAs,
you would have to ask DSA.

(Nor does the CAA record indicate that all currently valid certificates
must come from the listed CAs; the CAA record could have been different
when those were issued.)

Ansgar

Re: .deb format: let's use 0.939, zstd, drop bzip2

[Ansgar Burchardt]

Ian Jackson writes:
> Ansgar writes ("Re: .deb format: let's use 0.939, zstd, drop bzip2"):
>> `ar` needs to be replaced for the file size limitation mentioned in the
>> initial mail: ar represents file size as a 10 digit decimal number[1]
>> which limits the members (control.tar.*, data.tar.*) to ~10G.
> ...
>> Replacing `ar` is an incompatible format change.  So if we already do
>> an incompatible change, it is an appropriate time to bundle any other
>> incompatible changes (if there are any).  That is why I suggested that
>> it might be useful to also replace the `tar` archives with another
>> format.
>
> As has been pointed out, we have done many incompatible format
> changes.  Every new compression algorithm is one.  It isn't really a
> big problem, when managed properly.
>
> So I strongly disagree.  The archive size limit is getting more and
> more annoying.  We should not let fixing that be entangled with some
> random other nice-to-haves.

Changing container formats is a more invasive change than just
compression algorithms (of which there are already several anyway);
I believe it is a bad idea to create too many new formats that
would require long-term support in dpkg.

Ansgar

Re: Preferred git branch structure when upstream moves from tarballs to git

[Ansgar Burchardt]

Sam Hartman  writes:
>> "Ansgar" == Ansgar   writes:
>
> Ansgar> Sam Hartman  writes:
> >> I'm having a bit of trouble here and am hoping you can help us
> >> out.  Ian asked what git workflow it is that you're talking about
> >> where people can deal with commit push and pull and don't need to
> >> know more.
> >> 
> >> I didn't see a clear answer to that.  Which debian packaging
> >> workflow do you believe has that property?
>
> Ansgar> There is no need for a vendor branch if only the packaging
> Ansgar> information is kept in the repository, i.e. only debian/.
> Ansgar> In particular there is no need for branches or merges for
> Ansgar> regular updates (i.e. not based on an older release).
>
> OK, I didn't hear that as an answer but think I'm coming to the same
> conclusion that Ian did after reading your mail.
> It sounds like you are talking about having the Debian packaging in a
> separate repository from upstream.
> Do I correctly understand the model you are talking about?

Sure.

I'll point to [1] for what complexity this avoids.  Try explaining that
to someone without advanced Git knowledge...

  [1] https://manpages.debian.org/unstable/git-debrebase/git-debrebase.5.en.html

Note that CVS already had a mechanism for tracking upstream releases
(vendor branches); I'm not sure how widely they were used, but as far as
I understand they were usually seen as advanced use of CVS.  Git makes
maintaining such vendor branches easier (better merging), and some
workflows for Debian packaging result in trivial merges, but it is very
confusing when something unexpected happens.

Ansgar

Re: Preferred git branch structure when upstream moves from tarballs to git

[Ansgar Burchardt]

On Tue, 2019-04-30 at 16:00 -0700, Sean Whitton wrote:
> 
> On Tue 30 Apr 2019 at 08:05AM +02, Ansgar wrote:
> 
> > As an example: to update to a new upstream release, I ideally just have
> > to drop the new upstream tarball, update d/changelog and am done.
> > Compare with [1] which is much more complicated, even ignoring the extra
> > complexity using dgit adds compared to just using git.
> > 
> >   [1] 
> > https://manpages.debian.org/stretch-backports/dgit/dgit-maint-merge.7.en.html#NEW_UPSTREAM_RELEASES
> 
> As a package maintainer, if you don't keep the whole source package in
> git, you're giving up on a lot of the power of git.

I think keeping entry barriers low is more important than being able to
use all the power of Git.  That's sadly one of the main problems with
Dgit: it raises entry barriers by making packaging more complicated. 
Packaging shouldn't be complicated: it's just a build recipe plus some
metadata.

> The most
> significant thing is that you cannot manipulate quilt patches as commits
> on a branch.  It is also much more involved to cherry pick commits from
> upstream branches, and quickly obtain diffs between Debian's version of
> the code and arbitrary other branches, to mention a few other things.

Most packages don't need that either: for me most changes are either
fairly static (no merge conflict) or are just backports of upstream
commits (in which case they can just be removed when using a new
upstream version).

It does get easier when most fixes are applied upstream instead of
staying only in Debian :-)

> I also think that you're doing a disservice to downstream users.  If
> you're trying to fix a bug in the packaged version of some software on
> your computer, you don't care about the distinction between Debian's
> packaging scripts and the upstream code.

Either the bug is in upstream code, then you just need the upstream
source (and the patch should be pushed upstream anyway).  Or it is in
the (ideally smalll) Debian-specific parts which hopefully don't need a
long history to understand.

If you have large, invasive changes from upstream, you effectively fork
the package.  Maybe one should release it as a "fork" then so non-
Debian distributions can benefit from the changes in the fork.  That is
arguable a disservice to users...

Ansgar

Re: introduction of x-www-browser virtual package

[Ansgar Burchardt]

Paul Wise writes:
> On Tue, 2019-01-08 at 13:20 +0100, Bastien ROUCARIES wrote:
>> I could add a sensible-x-www-browser to be more nice to our user to
>> sensible-utils
>
> We already have a x-www-browser alternative, so sensible-x-www-browser
> would just duplicate that and is thus not needed.

No, the alternatives system is not really useful for users (as only root
can choose an alternative).  Having root choose a single
{editor,pager,browser,...} for all users is not a good solution.

Ansgar

Re: [Pkg-julia-devel] julia_1.0.0-1_amd64.changes REJECTED

[Ansgar Burchardt]

Hi,

Mo Zhou writes:
> Another fortnight has passed. Any update?

Sorry for taking so long; I wanted to put this on our meeting agenda,
but currently don't find much time...

Anyway, the package is now marked to be accepted.

There were some misunderstandings on our side why debug symbols weren't
stripped and from discussion I'm not sure it is clear why, but we agree
that this shouldn't block the current version and should better be
discussed in a bug report.

Ansgar

Re: Extension of Built-Using:

[Ansgar Burchardt]

On Wed, 2018-12-12 at 15:12 +, Alastair McKinstry wrote:
> I've been looking at using the "Built-Using" tag for dh-fortran-mod.

Why not a

  Fortran-Mod: gfortran-7, gfortran-8, flang-42

field or so?

As another example Python has `Python-Version: 3.6, 3.7` (for packages
where this matters; don't ask me about details, I don't know much).

Ansgar

Re: wicd-daemon-run_1.0_amd64.changes REJECTED

[Ansgar Burchardt]

Lorenz writes:
> Ansgar Burchardt:
>>As a possible alternative: ship the runscript and some metadata (which
>>systemd service(s) and/or sysvinit script(s) this corresponds with;
>>which system users would be needed; ...) either in the service package
>>(preferred long-term) or a "runscripts" package (maybe easier for
>>initial experiments).
>
>>Then have runit provide a command that creates the system users, sets up
>>the runit service and disables the systemd service (which I think was
>>still missing from the *-run packages).
>
> That will work for runit-init, but what about runit-sysv and runit-systemd?
> Let's say I have systemd (as init), runit-systemd and a foo daemon installed;
> and 'runscripts' package ship a run script for foo. How can I detect
> if the user wants to manage foo with runit or with systemd?

You let the user configure it.

Ansgar

Re: wicd-daemon-run_1.0_amd64.changes REJECTED

[Ansgar Burchardt]

Dmitry Bogatov writes:
> I believed (and still believe, despite of REJECT), that best way is
>
> 0. One source package, providing single binary package per runscript.
>
>src:{foo}-run -> bin:{foo}-run -> /etc/sv/{foo}

We generally try to avoid tiny packages in the archive; having 1000+
automatically generated source and binary packages in the archive seems
like a suboptimal solution.

Neither systemd, sysvinit or upstart required extra binary packages.

> 2. Add bin:{foo}-run into {foo}.
>
>It is infeasible due same social consideration.

That would still result in many tiny binary packages.
>
> 3. Make single src:runscripts, providing many bin:{foo}-run

Same.

As a possible alternative: ship the runscript and some metadata (which
systemd service(s) and/or sysvinit script(s) this corresponds with;
which system users would be needed; ...) either in the service package
(preferred long-term) or a "runscripts" package (maybe easier for
initial experiments).

Then have runit provide a command that creates the system users, sets up
the runit service and disables the systemd service (which I think was
still missing from the *-run packages).

Ansgar

Re: Re: usrmerge -- plan B?

[Ansgar Burchardt]

On Wed, 2018-11-28 at 09:45 +, Holger Levsen wrote:
> On Wed, Nov 28, 2018 at 07:52:08AM +0500, Alexander E. Patrakov
> wrote:
>  As long as there is one Debian Developer (or any other person who has the
> > right to upload binary packages) who has a merged /usr on his system used
> > for building packages, there is a risk of reintroducing the bug through his
> > package. Maybe we should somehow, in the short term, modify dpkg to add
> > something like "Tainted-By: usr-merge" control field to all binary packages
> > produced, if a package is built on a system with merged /usr (detected via
> > /bin being a symlink). 

There are far more annoying problems that are caused by, for example,
building in a really outdated chroot or a chroot for the wrong
distribution and so on.

(Also the test is wrong, /bin can be a symlink without the system
having merged-/usr when the local admin just moved some files around to
a more preferred location...)

> we have .buildinfo files now which document the packages installed
> during build time. If usrmerge is installed it will be there.

usrmerge being installed doesn't tell you if a system has merged-/usr
or not.  Newly installed systems will have merged-/usr, but no usrmerge
(as debootstrap creates the symlinks), or usrmerge could be removed
after the system has been converted (I did that for my systems).

Ansgar

Re: usrmerge -- plan B?

[Ansgar Burchardt]

On Fri, 2018-11-23 at 12:45 +, Ian Jackson wrote:
> Russ Allbery writes ("Re: usrmerge -- plan B?"):
> > This is a much better summary of the thread, and I wish that you would
> > have said this instead of claiming incorrectly that those same people are
> > the ones advocating for a full merge of all systems.
> 
> Marco d'Itri writes ("Re: usrmerge -- plan B?"):
> > 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 
> > benefit in doing that other than pleasing the few people who are scared 
> > by changes.

What is this quote supposed to tell us?

Ansgar

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

[Ansgar Burchardt]

Russ Allbery writes:
> Ansgar Burchardt  writes:
>> Moving files around in such a matter that they are still available in
>> the old location (via a symlink) is not a very invasive change, so there
>> is only a small risk of problems.
>
> I think it's fair to note that our past experience in Debian doesn't
> really support this.  I've run into multiple problems in unstable with
> uninstallable packages due to various bugs in this sort of change, most
> recently with iptables.  We repeatedly get the details of this change
> wrong in various subtle ways that create issues in some upgrade paths and
> not others.

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.

If we want to support packages such as iptables moving binaries from
/{s,}bin to /usr/{s,}bin while setting up compat symlinks on
non-merged-/usr systems, it might be useful to have a dh-usrmerge
package creating the maintainer scripts.  (Also for some files below
/lib, but most libraries could just be moved without compat symlinks.)

This should be similar to what OpenSUSE has done; see the section around
`#UsrMerge` on https://en.opensuse.org/openSUSE:Usr_merge

This could also be seen as a slower path to merged-/usr: programs such
as `sed` would be in both /bin and /usr/bin and hard-coding either would
be fine (as with merged-/usr, but not without).  Less static files would
be on a read-write root file system (if /usr is a separate read-only
fs).

In case a later Debian release would merged-/usr mandatory, the
conversion process would be less problematic as no files would be left
to move (just replace individual symlinks with a directory symlink).

Ansgar

Re: usrmerge -- plan B?

[Ansgar Burchardt]

On Thu, 2018-11-22 at 13:56 +, Ian Jackson wrote:
> Marco d'Itri writes ("Re: usrmerge -- plan B?"):
> > On Nov 22, Ian Jackson  wrote:
> > > Marco d'Itri writes ("Re: usrmerge -- plan B?"):
> > > > So far nobody reported anything significant.
> > > 
> > > 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.
> 
> I think this allows us to calibrate what you consider `anything
> significant'.

Causing problems with a few packages is not a significant problem.  We
should stop upgrading GCC to newer versions otherwise as doing so
generates tons of RC bugs every time.

> There is tradeoff here between risk of breakage, and reduction of
> future work (as most clearly explained by Russ).  The argument that
> is
> being made is that the risk is low because of a lack of reports of
> breakage.

Moving files around in such a matter that they are still available in
the old location (via a symlink) is not a very invasive change, so
there is only a small risk of problems.  That matches what was reported
so far.

Very few changes come with zero problems.

> Others have observed that systems most likely to experience trouble
> will not have been upgraded.  For example, chiark was first installed
> with Debian 0.93R5 in 1993.  Obviously I haven't usrmerged it.  No-
> one sensible in my position would do so.

Why should "originally installed in 1993" make moving files from one
location to another more difficult?  It's not different than having to
add LSB init headers to local init scripts (or just replace them with
systemd units these days), having to purge leftover conffiles from
removed packages or similar changes on upgrades.

If the system is prone to breakage on upgrades in general, I would
expect anyone sensible to fix that.

Ansgar

Re: Q: secure boot

[Ansgar Burchardt]

On Tue, 2018-11-06 at 09:14 +0800, Paul Wise wrote:
> AFAICT the Debian Secure Boot packages are not designed for the
> scenario where only Debian keys or per-user keys are trusted by the
> firmware, if they were then shim-signed would be named
> shim-signed-microsoft and there would be a shim-signed-debian package
> too.

This was discussed: you can attach multiple signatures to a UEFI binary
such as shim, so all this would need is to add an additional signature.
Maybe also a legacy version with only the MS signature in case some
implementations don't like multiple signatures (it was added in a later
UEFI version as far as I understand).

> In addition, the revocation situation is just ridiculous. There is no
> way to revoke known-insecure (but still validly signed) software from
> every vendor that supports secure boot.

I agree.  You can probably always get something with a valid signature
and a code execution bug running...

Ansgar

Re: Q: secure boot

[Ansgar Burchardt]

On Tue, 2018-11-06 at 10:42 +, Holger Levsen wrote:
> On Tue, Nov 06, 2018 at 10:08:10AM +0100, Bastian Blank wrote:
> > On Tue, Nov 06, 2018 at 01:09:50AM +0100, Adam Borowski wrote:
> > > But only the stock kernel, which turns it non-free software.
> > What is non-free?  Signing stuff does not change the freeness of
> > the
> > software.
> 
> it does introduce https://en.wikipedia.org/wiki/Tivoisation however.

I don't think it does as `shim` allows to either register your own
signing keys or disable secure boot verification (as long as you have
physical access to the machine).

Ansgar

Re: Debian Buster release to partially drop non-systemd support

[Ansgar Burchardt]

Paul Wise writes:
> On Fri, Oct 19, 2018 at 7:30 PM Martin Steigerwald wrote:
>> As long as people choose to strip of dependencies to libsystemd from
>> packages like util-linux, avoiding a fork would not work with how Debian
>> and Debian based distributions are built.
>
> It might be feasible to introduce nosystemd build profiles to Debian
> source packages and then create a shed/bikeshed/PPA (once that
> infrastructure exists) that contains rebuilds using that build
> profile.

Why should Debian spend resources on implementing and maintaining the
changes needed for the "systemd is cancer" trip of the Devuan lead
developers?

Should Debian also support "noalsa", "noavahi", "nocups",
"nopulseaudio", "nosysvinit", "nodbus", "nopam", "nowayland",
... profiles because there are people who do not like these projects and
would like to not see them used?

Or an "ubuntu" build profile so Ubuntu can merge all their changes
(branding, Ubuntu-specific choices, integration, ...) and would no
longer have to rebase them?

If one really cares about which shared libraries one wants to use, this
is *much* easier in source-based distributions such as Gentoo which
already have implemented this (USE flags).

See https://www.gentoo.org/support/use-flags/ for more build profiles ;-)

(The nosystemd build profile was already suggested in the past.)

> That would allow Devuan's libsystemd stripping to be
> completely merged into Debian source packages and infrastructure. I
> guess Devuan have other changes that might be easier or harder to
> merge too though.

And if we also build packages for them, they wouldn't even have to fix
their package-building infrastructure which seems to no longer work for
some time already now ;-) (A datapoint for how much interest in working
on stuff there is?)

But why spend work on implementing and, more importantly, maintaining
all of this for a derivative distribution which already had 498 active
developers(!) back in 2015 according to a presentation by Devuan
developer Alberto Zuin and Devuan founder Jaromil, and which represents
an exodus for half of the active Debian user base (according to a Devuan
lead developer in a publication in 2018)?  They certainly should have
enough resources.

Ansgar

Re: Debian Buster release to partially drop non-systemd support

[Ansgar Burchardt]

On Fri, 2018-10-19 at 11:35 +0200, Martin Steigerwald wrote:
> Martin Steigerwald - 19.10.18, 10:57:
> > That written, I estimate or guess that the people preferring to use
> > another initialization system than the initialization system in
> > Systemd are in the minority. Yet, this minority might be larger
> > than
> > you think. Especially as popularity contest does not count the ones
> > who switched over to Devuan:
> […]
> 
> Okay, let's add some numbers:
> 
> Debian and all the other Debian derived distributions:
> - 3109 (=1,55%) installations of sysvinit-core
> - 2031 (=1,01%) installations of runit -68 runit-systemd -6 of runit-
> sysv (counted above already)
> - 110 (=0,05) installations of openrc, but it works on top of
> sysvinit
> - https://qa.debian.org/popcon.php?package=sysvinit (and so on)

I think you forgot Ubuntu as a Debian-derived distribution...  If you
already include extra data, one shouldn't neglect that one.

> Devuan:
> - 2578 installations of sysvinit-core (and I just added two more by 
> installing popularity-contest on my Devuan based server VMs)
> - 27 installations of runit
> - 141 installations of openrc, installations of openrc, but it works
> on 
> top of sysvinit
> - http://popcon.devuan.org/tmp-www/by_inst.html
> 
> So Devuan almost doubles the percentage of sysvinit-
> core  installations.

And Ubuntu probably reduces it again by more than that.

Statistics are fun :-)

Ansgar

Re: "debian.pool.ntp.org" for Debian derivatives?

[Ansgar Burchardt]

On Thu, 2018-10-18 at 13:57 +0200, Philipp Hahn wrote:
> So my question is more like "is it okay to not change Debians default
> NTP server selection", so the initial setup and those lazy enough to
> not change the default get a sane time?

I don't think Debian can answer that question and suggest to ask the
pool operators.  This seems to be the correct list:
  https://lists.ntp.org/listinfo/pool

A related question is the use of API keys that are included in some
packages (e.g. chromium).  These are also vendor-specific, but cannot
be really secret (as they are included in the binaries and could be
extracted even for proprietary software).

Ansgar

Re: You are not seriously considering dropping the support of sysVinit?!

[Ansgar Burchardt]

free...@tango.lu writes:
> If Debian drops sysVinit support I will drop Debian
[...]
> This is your last chance to do the right thing and announce the
> removal of this fucking piece of shit malware(D) from Debian and go
> back to sysVinit or openrc!

So dropping sysvinit support will make you go away?  That sounds like a
positive effect to me, but for some reason you seem to try and use it as
a threat?

Ansgar
  (SCNR)

Re: Debian Buster release to partially drop non-systemd support

[Ansgar Burchardt]

On Tue, 2018-10-16 at 14:48 +0200, Philipp Kern wrote:
> The question is: Is 
> the package buggy if it does not contain an init script but a systemd 
> unit and it seems to be the case. Note that there are a *lot* of useful 
> options in a systemd unit that would need emulation to make properly 
> work with sysvinit.

Shipping a systemd unit without a corresponding init script with the
same name is forbidden by policy:

| However, any package integrating with other init systems must also
| be backwards-compatible with sysvinit by providing a SysV-style init
| script with the same name as and equivalent functionality to any
| init-specific job
+---[ Debian Policy, section 9.11 ]

In practice this is ignored.

Note that this also forbids, for example, ssh.socket/ssh@.service or
tor@.service which all don't have a corresponding init script of the
same name.  Also cases where the init script starts multiple services,
but there are individual units for each service in systemd is
forbidden.

I think this requirement isn't a good idea these days for various
reasons and will file a bug asking to drop it.

Ansgar

Re: Debian Buster release to partially drop non-systemd support

[Ansgar Burchardt]

On Tue, 2018-10-16 at 09:57 +0200, Martin Steigerwald wrote:
> Ansgar Burchardt - 16.10.18, 08:53:
> > If some people consistently call others a "cancer", accuse them of
> > "vandalizing" open source, spread obvious FUD and so on, then I don't
> > think they would fit in well in Debian's culture where they would have
> > to accept that packages such as systemd exist.
> 
> I disagree. So far I saw none of the Devuan developers (!) I had contact 
> with doing any of the stuff you accuse them of. I think it is important 
> to see the difference between the comments on random people in some 
> mailing list or IRC channel and *actual* Devuan *developers*.

Let me see how some actual Devuan developers think about systemd:

+---
| I personally find hilarious that most of the people out there are
| still convinced that the systemd-nonsense is just a replacement for
| sysv-init, while it should be clear by now that it is already
| becoming a pervasive cancer...
+---[ Enzo Nicosia aka KatolaZ in 20150330170221.gm22...@katolaz.homeunix.net ]

+---
| that's exactly what I referred to when I talked of the
| systemd-nonsense as a "cancer". The damage is not merely technical and
| localised to the relatively minor issue of replacing PID 1, as you
| correctly pointed out, but "systemic" and "social". And that's exactly
| why we should be more concerned about it.
+---[ Enzo Nicosia aka KatolaZ in 20150331093754.go22...@katolaz.homeunix.net ]

+---
| What we really need is to build sufficient maintainer capacity and
| capability to fork more packages and excise this systemd cancer once and
| for all. [...] If we don't slay the beast, it will continue to
| grow and infect more components ever more invasively,
+---[ Daniel Reurich in 
https://lists.dyne.org/lurker/message/20180619.232314.a3229d06.html ]

As a lazy person I was just grepping for "cancer" in the mail archive
and picked a few examples.  Too lazy to search for other insults.

I'm not alone in seeing this as a problem in the Devuan community.  A
certain Martin Steigerwald pointed out:

+---
| As a honest feedback:
|
| Currently I do not read much of the threads here.
|
| Cause again and again I see language like systemd being like a cancer or 
| infecting people´s systems.
+---[ Martin Steigerwald in 24625919.fzpRARYAEh@merkaba ]

Tolerating this *does* reflect back on project leaders, more so if some
of them also engage in the behavior.

Debian already had a systemd maintainer step back because of abuse from
a certain group of people[1].  As I would like to see systemd still
maintained in the future, I don't think it's worth to try to integrate
the abusers in Debian as package maintainers.

Given that the systemd maintainers also have to deal with sysvinit,
maintainership of sysvinit is probably especially problematic.

  [1] 
https://err.no/personal/blog/tech/debian/2014-11-16-23-55_resigning_from_pkg-systemd/

> > And no, it's not just that infobot factoid or just random people that
> > are totally unrelated to Devuan.
> 
> A claim without facts. So FUD in itself. I let go on spending energy to 
> prove otherwise.

See above for a few examples.

> In addition to that the infobot factiod may easily have not been from a 
> Devuan developer or someone else related to Devuan:
> 
> goli...@dyne.org - 16.10.18, 03:32:
> > infobot is a bot with a database that references 119770 factoids that
> > can be queried. Each one has it's own individual author and literally
> > anybody can add new factoids to the bot. It has been around for about
> > 20 years. It *allows* Devuan to use the bot services and would allow
> > Debian to do exactly same.�
> 
> https://lists.dyne.org/lurker/message/20181016.013255.cada93dc.en.html
>
> I put the emphasis on *anybody* here.

Dunno, I saw it used by IRC channel operators.  I would assume that IRC
channel ops are not totally unrelated people...
 
> So I close with a snippet from the post of KatolaZ mentioned above:
> 
> KatolaZ - 16.10.18, 06:23:
> > Let's try to reduce the useless chit-chat and drama to a minimum,
> > please (and the minimum is zero, in this case), since that's not
> > helpful at all, and does not build packages. I subscribed to
> > debian-devel as well, and will reach out later.
> 
> https://lists.dyne.org/lurker/message/20181016.042148.1688fecb.en.html
> 
> Drama is not helpful to get anything done. KatolaZ already reached out.

Ah, one of the people calling systemd a cancer. Great.

Ansgar

Re: Debian Buster release to partially drop non-systemd support

[Ansgar Burchardt]

Martin Steigerwald writes:
> Ansgar Burchardt - 15.10.18, 16:03:
>> Please no.  I don't think it would help Debian to have toxic people
>> maintain packages.
>> 
>> (As an example, Devuan's infobot has fun facts like this one:
>> "<+infobot> 'sth is poettering' means it acts invasive, possessive,
>> destructive, and generally in an egocentric exacerbating negative way.
>> ``this cancer is extremely poettering'' [...]")
>
> Calling people "toxic" IMHO is quite similar to what Devuan's infobot 
> displays: Both are attacks on persons. And both are not helpful.

I'm also guilty of calling MikeeUSA a toxic person, also a horrible
personal attack.  For me enough Devuan-related people have managed to
end up in the same category by hard work.  I don't think it's
coincidence that the "VUA" liked MikeeUSA's writings about why systemd
is so evil.

If some people consistently call others a "cancer", accuse them of
"vandalizing" open source, spread obvious FUD and so on, then I don't
think they would fit in well in Debian's culture where they would have
to accept that packages such as systemd exist.

And no, it's not just that infobot factoid or just random people that are
totally unrelated to Devuan.

(Yes, I know Devuan eventually banned MikeeUSA for his writings.)

Ansgar

Re: Debian Buster release to partially drop non-systemd support

[Ansgar Burchardt]

On Mon, 2018-10-15 at 14:20 +0100, Jonathan Dowland wrote:
> On Mon, Oct 15, 2018 at 06:56:50AM +0200, Petter Reinholdtsen wrote:
> > I believe Andreas Henriksson is right, the packages are going to be
> > removed unless someone with time and interest show up to take care of
> > them.  A good start would be to split initscripts off from the sysvinit
> > binary packages, to let them live separate lives.  It will be sad, but
> > the proper way for Debian to handle unmaintained packages in a sad
> > state.
> 
> Is it worth interested parties reaching out to the Devuan project
> regarding person-power for sysvinit maintenance?

Please no.  I don't think it would help Debian to have toxic people
maintain packages.

(As an example, Devuan's infobot has fun facts like this one:
"<+infobot> 'sth is poettering' means it acts invasive, possessive,
destructive, and generally in an egocentric exacerbating negative way.
``this cancer is extremely poettering'' [...]")

Ansgar

Re: Package not compatible with old systemd

[Ansgar Burchardt]

On Wed, 2018-09-19 at 10:07 +0200, Wouter Verhelst wrote:
> On Tue, Sep 18, 2018 at 10:45:45AM +0200, Ondrej Novy wrote:
> > for example when files are overwritten. This is not case and Breaks
> > "is enough".
> 
> "Breaks" means "will cause the other package to fail". That isn't the
> case here. Additionally, Breaks isn't supported very well by some
> tools, so it's better to be avoided.

It is usally recommended to avoid Conflicts in favor of Breaks: Policy
says "Normally, Breaks should be used instead of Conflicts"[1].

  [1] 


> "Conflicts" *can* mean "shares pathnames with other package", but it
> doesn't have to; it can also mean "doesn't work well with other
> package".

Policy specifically says to use Breaks in this case: "Breaks should be
used [...] when the breaking package exposes a bug in or interacts
badly with particular versions of the broken package." (same section as
above)

> You're claiming that the systemd support of your package won't work
> correctly unless you have a particular version of systemd on your
> system. If that's the case, then you should Depend on the correct
> version of systemd. If you also support other init systems, you can
> add
> an alternate dependency on those other systems; or you can use
> Recommends: rather than Depends: if you don't want it to be absolute.

Depending on an init system is definitely wrong as it is perfectly fine
to use some service without any init, such as in Docker containers, or
under other supervisors such as runit.

Ansgar

Re: Should the weboob package stay in Debian?

[Ansgar Burchardt]

Hi Jonathan,

On Fri, 2018-07-20 at 07:47 +0100, Jonathan Dowland wrote:
> On Fri, Jul 20, 2018 at 01:34:19PM +1000, Dmitry Smirnov wrote:
> > On Friday, 20 July 2018 12:50:12 AM AEST Jonathan Dowland wrote:
> > > Have you read Matthew Vernon's reply to OP in this thread? Does
> > > that not
> > > explain it?
> > 
> > Matthew did not convince me. IMHO his explanation is weak as it
> > boils down to
> > "there are many problems like this and we should fix this problem
> > because
> > there are other similar ones"...
> 
> This suggests that you did understand Matthew's reply, but the rest of
> your message implies that you didn't. Honestly I'm not sure I've got the
> skill to explain it to you, I'm not sure I could do a better job than
> Matthew at summarizing the issue. I'm afraid I must bow out, focus on
> fixing the problem, and leave it to others or to self-study for you to
> understand it, if you wish to.

I can't help but understand your message as "if you don't agree, you
haven't understood" which I don't find very helpful.

Is that what you wanted to say?

Ansgar

Re: Should the weboob package stay in Debian?

[Ansgar Burchardt]

Matthew Vernon writes:
> We shouldn't need to have numbers of people having to justify why a
> particular thing is offensive before we (as a project) try and fix
> it.

That works if Debian was a non-diverse groups where everyone had similar
views on what is offensive.  In that case the maintainer could just have
done whatever or would not have uploaded the package at all.

Sadly(?) Debian is too diverse and "we (as a project)" won't agree on
what is offensive or where what level of offensive content is okay.

In this case I feel like we might as well try to reach a consensus on
whether pride parades are a display of sexual depravity, sexual
liberation or self-objectification; or skipping that part any trying to
agree if and how pride parades should be fixed.

The current policy[1] leaves it up to the maintainers to make this
judgement and I don't think a discussion on -devel@ will reach a
consensus that would take away the responsibility here.

Ansgar

  [1] 
https://www.debian.org/doc/debian-policy/#packages-with-potentially-offensive-content

Re: Which checks should we mandate for source operations in shell scripts

[Ansgar Burchardt]

Marc Haber writes:
> back in the sysvinit days, we used to have the following construct as
> a common idiom in init scripts:
>
> |if [ -f /etc/default/foo ]; then
> |  . /etc/default/foo
> |fi
>
> This is an immediate privilege escalation vulnerability in the case
> that /etc/default/foo or /etc/default itself is/are writeable for
> non-root users.

That seems to be the same class of issue as init scripts, systemd units
(in /etc/systemd/system) or /bin/bash writable by non-root.  I don't
think Debian should try to "fix" this.

(Now, let me mention my favorite
  chown -R non-root /var/lib/service
in maintainer scripts...)

Ansgar

Re: rkt

[Ansgar Burchardt]

Dmitry Smirnov writes:
> On Tuesday, 5 June 2018 5:11:31 PM AEST Ansgar Burchardt wrote:
>> rkt is neither in testing nor stable...
>
> Unfortunately... However it is a static Golang binary with minimum external 
> run-time dependencies which makes it possible to reasonably safely install 
> rkt on Stretch straight from "unstable"...

Yay, build systems that will be a nightmare to maintain later...

Though I admit golang is a crappy language to support given one has to
rebuild everything all the time there is a security update.  Just
imagine libc (or worse: linux) was written in Go and there was a
security update: just rebuild the distribution ;-) (And for third-party
providers wait for the vendored libc (or linux) to get updated, if that
will happen at all.)  So I'm not surprised many Golang things don't make
it to testing.

Ansgar

Re: concerns about Salsa

[Ansgar Burchardt]

Dmitry Smirnov writes:
> Do you think there will be a potential to move services to containers, 
> probably on "rkt" runtime[*] ?

rkt is neither in testing nor stable...

> [*]: Because Docker sucks...

Does rkt then suck more because it depends on docker stuff (at least in
Debian)? *scnr*

Ansgar

Re: Bug#900286: ITP: spm -- simple password manager

[Ansgar Burchardt]

On Tue, 2018-05-29 at 13:11 -0400, Nicholas D Steeves wrote:
> On Mon, May 28, 2018 at 07:46:59PM +0200, Jakub Wilk wrote:
> > * Paride Legovini , 2018-05-28, 17:33:
> > > spm is a single fully POSIX shell compliant script
> 
> [...]
> > > In Debian the script will be installed as 'spm.sh'
> > 
> > That would be against Policy §10.4.
> > Please talk to upstream about choosing a different name.
> 
> Are there any reasons why a debian/spm.install like this one wouldn't
> be an appropriate solution to §10.4?
> 
> #!/usr/bin/dh-exec
> spm.sh => /usr/bin/spm

/usr/bin/spm is already shipped by another package as noted in the
initial report.

Renaming the binary to simple-password-manager or so would probably
work.

Ansgar

Re: Want to make salsa advertise contact and source code details [and 1 more messages]

[Ansgar Burchardt]

On Fri, 2018-05-25 at 18:57 +0100, Ian Jackson wrote:
> Another way to achieve the effect I want would be to do it post-hoc in
> a reverse proxy.  I see that salsa is using Apache as a reverse proxy.
> So perhaps the right answer is to do this in Apache.  It seems quite
> hacky, but if it's thought easier to maintain then fine...

That seems like an horrible maintenance nightmare just to avoid even
talking to upstream...

Ansgar

Re: Want to make salsa advertise contact and source code details

[Ansgar Burchardt]

On Fri, 2018-05-25 at 17:16 +0200, Geert Stappers wrote:
> Not knowing who is "we", but the thing I want to says is
> 
>   Do not ask for a lighter load,
>   but ask for more shoulders to carry the load.

Asking for a lighter load has given us the wheel, washing machines,
dishwashers, computers, and so on though. :-)

Sorry, could not resist.

Ansgar

Re: Salsa Questions

[Ansgar Burchardt]

On Wed, 2018-05-02 at 14:11 +0200, Jörg Frings-Fürst wrote:
> - Becomes salsa the permissions as an open system like Alioth or does
> it stay so steady?

Sorry, I can't parse this question.

> The background to the question is that at the moment I can not even
> draw attention to the one project that has already moved to Salsa
> because of "Permission denied (publickey)".

Did you register your ssh public key on salsa?

Did you specify the `git` user when cloning the project?  All Git
accesses via ssh have to use that user.  It's also possible to use
https:// for accessing Git repository; that also works without an
account (for public projects).

Ansgar

Re: problems in gjots2 and Debian

[Ansgar Burchardt]

On Wed, 2018-04-18 at 10:45 -0400, The Wanderer wrote:
> On 2018-04-18 at 05:55, Andrey Rahmatullin wrote:
> 
> > On Wed, Apr 18, 2018 at 11:23:23AM +0200, Martin Steigerwald wrote:
> > 
> > > As just someone who mostly maintains one package (fio - flexible
> > > I/O tester) I can certainly understand how you feel about that
> > > Lucas removed you as a maintainer.
> > 
> > But that didn't happen, unless you put different meaning into
> > Maintainer and Uploaders.
> 
> If you don't assign different meanings to "Maintainer:" and
> "Uploaders:", what's the point in both fields existing?

The Maintainer field is only allowed to list one person for historic
reasons.  So a new field was added to list additional maintainers.

Ansgar

Re: Lucas Kanashiro and Athos Ribeiro salvaged my package

[Ansgar Burchardt]

Scott Kitterman writes:
> Personally, I think people should be more annoyed at the people doing
> the hijacking than the one they did it to.

I thought this is called "salvage" now?

There might have been some miscommunications, but given an acceptable
alternative is just requesting the removal of a package with open RC
bugs that hasn't been uploaded for a time, isn't just salvaging the
package by adding oneself as a maintainer better?

And if this is the preferred outcome, shouldn't the salvaging be
"easier" than just requesting removal (which is just one bug report
away)?

Ansgar

nmap license is incompatible with GPL

[Ansgar Burchardt]

Hi,

[ BCC'ed maintainers of packages mentioned below ]

Chris Lamb pointed out that nmap uses a special version of the GPL-2
which is incompatible with the standard GPL license:

+---
| Because this license imposes special exceptions to the GPL, Covered
| work may not be combined (even as part of a larger work) with plain
| GPL software."
+---

The license in particular also forbids front-ends parsing nmap's output
that are released under a license not compatible with nmap's:

+---
| For example, we consider an application to constitute a
| derivative work for the purpose of this license if it does any of the
| following with any software or content covered by this license
| ("Covered Software"):
| [...]
| - Is designed specifically to execute Covered Software and parse the
|   results (as opposed to typical shell or execution-menu apps, which
|   will execute anything you tell them to).
+---

This means packages such as `nmapsi4`, `python-nmap`, `lsat`, `nikto`,
`zabbix`, `oscinventory-agent`, `fusioninventory-agent-task-network` and
possibly others which are licensed under the GPL-2 (some with or-later)
do not conform to nmap's license requirements...

I plan to file RC bugs against these packages soon; this thread can
serve as a central place for discussions.

Ansgar

Re: Removing packages perhaps too aggressively?

[Ansgar Burchardt]

peter green writes:
>> If you do reintroduce it, please note the extra steps (reopening bugs
>> in particular)
> On that note one thing that doesn't seem to be easy/well documented is
> how to go about finding the bugs that affected a package at the time
> of it's removal. If I go to the bugs page for the package and select
> "archived and unarchived" I see a bunch of resolved bugs but other
> than opening them up individually I don't see a good way to tell the
> difference between ones that were actually fixed and ones that were
> open at the time of the removal.

dak logs which bug reports is closed when a source package was removed:
see the "Also-Bugs" field in https://ftp-master.debian.org/removals.822
(for the current year; removals-.822 or removals-full.822 are also
available).

Note that sometimes[1] the bugs are not closed by dak and end up getting
closed in a different way.

Ansgar

  [1] IIRC when removing >1 source package at the same time

Re: Removing packages perhaps too aggressively?

[Ansgar Burchardt]

Andrej Shadura writes:
> On 01/02/18 09:40, Ansgar Burchardt wrote:
>> Andrej Shadura writes:
>>> On 31/01/18 21:01, Jeremy Bicha wrote:
>>>>> Here you go, there's #871004 for you. Missed jessie, stretch,
>>>>> not in testing, no uploads since the beginning of 2017.
>>>>
>>>> I don't think you'll get much sympathy for a package being removed
>>>> from unstable when it hasn't shipped with a Debian release since
>>>> Wheezy, and has continuously been out of Testing for 3.5 years.
>>>
>>> True, it hasn't. But if you look a little bit closer, you'll see both RC
>>> bugs it had were quite trivial to fix: two sourceless files (would be
>>> fixed by linking them to the packaged versions instead), and an failed
>>> attempt to download a build-dep (actually, fixed by an NMU while fixing
>>> another bug, just never marked as done).
>> 
>> So there was plenty of time to fix them.
>> 
>> Why would filing a third RC bug (the "proposed-RM") and waiting one
>> month more change anything?  Why would someone turn up to fix them now?
>
> Why not? I *was* already doing just that, but with an RM bug filed
> elsewhere, I was unable to know it's about to be removed. I would have
> reacted and closed it before the package's got removed.

Packages that have open RC bugs are always at risk to get removed
eventually.  That is why the bug is release critical.

Especially when there is no activity at all on the bugs for an extended
period of time (or no activity ever as was the case here).  And when
they already missed getting included in a stable release or two.

Ansgar

Re: Removing packages perhaps too aggressively?

[Ansgar Burchardt]

Andrej Shadura writes:
> On 31/01/18 21:01, Jeremy Bicha wrote:
>>> Here you go, there's #871004 for you. Missed jessie, stretch,
>>> not in testing, no uploads since the beginning of 2017.
>> 
>> I don't think you'll get much sympathy for a package being removed
>> from unstable when it hasn't shipped with a Debian release since
>> Wheezy, and has continuously been out of Testing for 3.5 years.
>
> True, it hasn't. But if you look a little bit closer, you'll see both RC
> bugs it had were quite trivial to fix: two sourceless files (would be
> fixed by linking them to the packaged versions instead), and an failed
> attempt to download a build-dep (actually, fixed by an NMU while fixing
> another bug, just never marked as done).

So there was plenty of time to fix them.

Why would filing a third RC bug (the "proposed-RM") and waiting one
month more change anything?  Why would someone turn up to fix them now?

Ansgar

Re: Bug#886238: Please introduce official nosystemd build profile

[Ansgar Burchardt]

Simon McVittie writes:
> On Sun, 07 Jan 2018 at 00:27:15 +0100, Ansgar Burchardt wrote:
>> sysvinit probably only stays in testing because systemd
>> depends on sysv-rc for compatability with LSB init scripts...
>
> I think it did during the default init system transition, but it doesn't
> any more.
>
> sysvinit-utils is still Essential: yes, because it contains binaries that
> were historically part of the Essential set; *that* keeps src:sysvinit
> in testing. There are plans to make sysvinit-utils non-Essential by
> moving pidof to a new Essential package built from src:procps (lots
> of packages blindly assume that pidof exists, so adding dependencies
> doesn't seem feasible) and adding dependencies for the few uses of the
> other sysvinit-utils binaries, which have been OK'd in principle by the
> maintainer of src:sysvinit, but haven't happened yet.

Oh, right, I somehow ended up thinking the LSB init script bits from
lsb-base were part of sysvinit, but they aren't.

> sysv-rc and initscripts are both present on about 72% of installations
> that report to popcon, even though systemd-sysv is present on about 78%
> of those installations and sysvinit-core is present on less than 2%.
> I don't know what's going on in the other 20% - surely they can't all
> be wheezy or older? Perhaps some of them are chroots or containers with
> no init system at all?

If you look at the version graph at https://popcon.debian.org (leaving
out intermediate versions):

1.28 (sarge)  : 16
1.41 (etch)   : 740
1.46 (lenny)  : 2442
1.49 (squeeze): 7912
1.56 (wheezy) : 27436

total submissions : 195697

This makes about 20% running wheezy or older releases.

Ansgar

Re: Bug#886238: Please introduce official nosystemd build profile

[Ansgar Burchardt]

Adam Borowski writes:
> On Sat, Jan 06, 2018 at 07:17:14PM +0100, Marco d'Itri wrote:
>> On Jan 06, Simon Richter  wrote:
>>
>> > As it is now, we have a lot of people who are maintaining their own
>> > packages outside of Debian. Can we get enough support to reintegrate
>> > both the people and the code?
>> I will ignore for the time being the reasons why these packages are 
>> outside of Debian, and focus on the obvious prerequisite.
>> As it is now, and as Simon is patiently trying to explain, sysvinit in 
>> Debian is basically unmaintained because no Debian developer cares 
>> enough about it.
>
> Ian Jackson and Benda Xu are nobodies?
> (Somehow Ian mistakenly versioned an upload as NMU.)

I think Marco wants to suggest that they don't seem to actively maintain
sysvinit and therefore the package is in practice unmaintained.

> I can't think of any pressing issue (#872039 has bogus severity), the
> package is mature, and any recent breakage happened due to systemd
> changes.

No maintainer has replied for almost half a year (when the bug was
filed)...  sysvinit probably only stays in testing because systemd
depends on sysv-rc for compatability with LSB init scripts...

> This is not to say all is fine -- the package really could take some extra
> work, but it is functional.

And the remaining packages of the sysvinit ecosystem are unmaintained
too, for example insserv (#834284) and startpar (#834283).  Or
systemd-shim if you want to consider desktop systems too.

Ansgar

Bug#886238: Please introduce official nosystemd build profile

[Ansgar Burchardt]

On Wed, 2018-01-03 at 14:26 +0100, Samuel Thibault wrote:
> > Do we really need systemd-less builds? I'm not convinced this is
> > something relevant to Debian.
> 
> Well, if Debian wants to remain relevant to downstreams, it'd be
> better to accomodate their needs.

I think there is only one distribution which wants builds without
libsystemd: the one that formed around MikeeUSA's call to action.

What does Debian gain from supporting a distribution whose developers
are unfriendly to Debian developers (accusing Debian to "vandalize"
open source by supporting systemd) and other people (calling a systemd
developer a cancer)?

Let me quote Devuan's IRC's infobot fact:

| 'sth is poettering' means it acts invasive, possessive, destructive,
| and generally in an egocentric exacerbating negative way. ``this
| cancer is extremely poettering'', [...]

I don't think we should waste time to accomodate the needs of such
people.

Ansgar

Re: allowed uses of non-baseline CPU extensions

[Ansgar Burchardt]

On Mon, 2017-10-23 at 16:47 +0200, Adam Borowski wrote:
> On Mon, Oct 23, 2017 at 04:36:11PM +0200, Julian Andres Klode wrote:
> > sse2-support and other packages that fail to install can massively
> > screw up systems, potentially leaving dpkg in a state that people
> > cannot easily recover from - that is, apt-get install -f might not
> > be working at that point. We should not have such packages.
> 
> It cleanly aborts installation in preinst.
> 
> If there are any problems with that, they'd also apply to every other
> package with preinst that can possibly fail.

Anything with failing maintainer scripts is very much not nice,
especially for unexperienced users.

(One the reasons I don't like packages trying to be smart and configure
things, then break in the maintainer script. Dumb packages are more
friendly.)

Ansgar

Re: Mandates explicit -std=c++XY for c++ projects

[Ansgar Burchardt]

Mathieu Malaterre writes:
> With this mind I'd like to make mandatory the -std=c++XY flags when
> compiling either a c++ library or a stand-alone c++ program:
>
> 1. Either upstream define the explicit -std=c++XY flags by mean of its
> build system,
> 2. Or the package maintainers needs to explicit change the CXXFLAGS to
> pass the appropriate version of the c++ standard. In which case this
> should be documented in the README.Debian file.
> 3. As a fallback, dh should initialize the CXXFLAGS with -std=gnu++98

So if the upstream build system adds '-std=c++14' and CXXFLAGS is set to
'-std=gnu++98', one gets '-std=c++14 -std=gnu++98' and building the
package no longer works?  That doesn't sound good to me.

Why should CXXFLAGS be documented in README.Debian?  (Or in fact
anywhere outside of d/rules?)  They aren't interesting for users of the
package.

I also don't think we should default to an ancient C++ standard.  All
maintained software should hopefully work with C++11 or later by now...

Ansgar

Re: allowed uses of non-baseline CPU extensions

[Ansgar Burchardt]

On Thu, 2017-10-05 at 03:23 +0100, Ben Hutchings wrote:
> This should be unnecessary since gcc 6, as you can easily tell the
> compiler to generate and select between multiple versions of the
> functions.  See .

Having to identify interesting functions and add compiler-specific
definitions to them isn't that easy.  The real easy and lazy option
would be to have a compiler flag to enable it for entire translation
units (probably at the expense of binary size).

Ansgar

Re: Removal of upstart integration

[Ansgar Burchardt]

Ian Jackson writes:
> Alexandre Detiste writes ("Re: Removal of upstart integration"):
>> Please also sprinkle these maintainers scripts with some
>> 
>>   rmdir /etc/init  --ignore-fail-on-non-empty
>
> That should be
>
>   rmdir --ignore-fail-on-non-empty /etc/init
>
> in case an environment variable is set requesting traditional
> (non-GNU) positional option parsing.

While it doesn't hurt here, I think people are on their own if they set
POSIX_CORRECTLY or so (or include another incompatible `rmdir` in
$PATH).

Arguably `dpkg` could also run maintainer scripts in a more controlled
environment so less random variables affect the maintainer scripts.

Ansgar

Re: ftp master uploads disappearing?

[Ansgar Burchardt]

Hi,

Norbert Preining writes:
>> I now use dupload which does not have that kind of issues.
>
> Indeed, dupload worked right ahead. Thanks.

dput should also allow uploads via rsync-over-ssh (or scp or sftp) which
also allows resuming uploads.  The default dput.cf doesn't include it,
but I have

+---
| [rsync]
| method = rsync
| fqdn   = ssh.upload.debian.org
| incoming   = /srv/upload.debian.org/UploadQueue/
| allow_dcut = 1
+---

in my ~/.dput.cf.

There is also ssh.security.upload.debian.org for security uploads via
SSH, but dput doesn't handle that quite correct yet (it explicitly makes
uploads world-readable which shouldn't happen for security uploads).

Ansgar

Re: Whether remotely running software is considered "software" for Debian.

[Ansgar Burchardt]

"Dr. Bas Wijnen"  writes:
> Actually, that isn't so clear at all.  At least when it comes to current
> practice, I have yet to find any client for which nobody wrote a free server.
> People keep implying that we have many such clients currently in main, but I
> don't think we do.  So there is no clear current practice that can be used as
> an argument.

hplip ("server" runs on printers / multi function devices),
python-digitalocean, ruby-azure*, waagent, twittering-mode, smart cards
("server" runs on card), probably HBCI clients, python3-googleapi,
usbmuxd, python3-pyicloud, python-yowsup, youtube-dl,
libgfbgraph-0.2-dev, other proprietary web APIs, drivers for SATA disks
("server" runs on SDD/HDD), ...

Ansgar

Maintainer information in source packages (was: Re: Returning to the requirement that Uploaders: contain humans)

[Ansgar Burchardt]

Hi,

as a more radical change one could also ask the question where to
maintain the maintainer information.  Currently we handle this in the
source package via the Maintainer and Uploaders field, and via team
memberships.

This has several limitations: for teams, Uploaders will often be
useless (you don't want to list all team members in every team-
maintained package).  The Maintainer field only really applies to
Debian, in derivatives someone else should be contacted.  In stable
releases, the field can often be outdated (it records who maintained
the package some time ago, not who currently maintains it).

So I have been wondering several times whether we should move the
maintainer information elsewhere.  For example, tracker.d.o could be
extended to record maintainer information.  It could also understand
the concept of "teams" listing team members and whom to send mails
about individual packages.

For legacy purposes, the Maintainer field would then list ${source}@tra
cker.d.o and the Uploaders field could be removed.

This would also address the fact that various bits of our
infrastructure don't know about Uploaders (like bugs.d.o only
contacting the Maintainer).

Ansgar

Re: Bad interaction between pbuilder/debhelper/dpkg-buildinfo/dpkg-genchanges and dak on security-master

[Ansgar Burchardt]

On Sun, 2017-07-09 at 15:41 +0100, James Clarke wrote:
> Now, the issue here is not its presence, but its
> name; however, I'd argue this is the correct name for it; it *is* a buildinfo
> file for an amd64 build.

And that has little to do with what ends up in the archive, unlike
other files dak processes: those usually are what ends up in the
archive, but here it's just random data that might lie about what ends
up in thhe archive.

>  Uploading a source-only changes file called
> _amd64.changes has been done many times in the past (and used to be what you
> would get with pbuilder pre-stretch) and never posed an issue, I guess because
> the .changes files were thrown away(?), though I seem to recall in some cases
> there were issues?

There are issues with files named _amd64.changes in the same cases
where there are issues with files named _amd64.buildinfo, just that is
much worse with _amd64.buildinfo as one cannot rename them (see the
.changes why that is so).

(Uploads to unstable usually don't trigger that problem.)

> Anyway, I don't especially care whether the _amd64.buildinfo
> gets renamed (copied) by dpkg-genchanges -S, or whether dak is fixed to allow
> multiple buildinfo files for the same arch (maybe renaming the file itself);

Or fixed to just silently discard .buildinfo files that might not work.
Or reject them always (though that also causes issues because arch:all
uploads also seem to get a _amd64.buildinfo, except when they come from
the buildds).

Ansgar

Re: DEP 15: Reserved namespace for DD-approved non-maintainer changes

[Ansgar Burchardt]

Sean Whitton writes:
> I am hereby reserving DEP number 15 for my draft DEP, "Reserved
> namespaces for DD-approved non-maintainer changes".
>
> I'd like to suggest discussing this DEP on d-devel (which is the
> Reply-to for this e-mail).  The canonical DEP text is at
> .

What about contributions to non-packaged parts of Debian?

I also don't like having more systems only a subset of contributors can
use.  Having a place where every contributor can publish merge requests
is nicer (one can still have a tool to make it easier to check commit
signatures using the Debian keyrings if one so desires).

Ansgar

Too many Recommends (in particular on mail-transport-agent)

[Ansgar Burchardt]

Hi,

my impression is that too many packages use Recommends that should
really be Suggests.  As a random example: installing dracut as a
initramfs provider will pull in exim4... (dracut-core Recommends: mdadm
which Recommends: default-mta | mail-transport-agent).  This seems
really not ideal.

As a result many people seem to disable installing recommended packages
by default.  I believe we should be much more agressive in downgrading
dependencies to Suggests.

For example, very few packages should Depend/Recommend a MTA: if you
just send notifications (like mdadm), you would need a properly
configured MTA anyway or they just end up in a file nobody will ever
look at (I don't see local mail to root as very useful).

I suggest that only very few packages should Recommend a MTA: packages
that mainly deal with mail on servers in some way or another (for
user-facing applications, speaking SMTP to a remote SMTP server is
common enough that these shouldn't Recommend a MTA usually either).

Ansgar

Re: substvars in *.install + friends

[Ansgar Burchardt]

Hi,

On Thu, 2017-05-04 at 17:14 +0200, Enrico Weigelt wrote:
> is it possible to use the substvars mechanism for the *.install and
> similar files, just like w/ control file ?
> 
> For multi-version installations, I'm keeping the whole package in a
> prefix w/ the version number (see my other mail - nodejs). I don't
> like to change lots of files which each version number.

Please ask packaging questions on debian-ment...@lists.debian.org

The *.install file can be executable (see "Debhelper config files" in
man:debhelper(7)).  There is also dh-exec, but I had no need for it
myself so far and therefore don't know much about it.

Ansgar

Re: Bug#761348: ftp.debian.org: need machine-readable metadata about suites & repositories

[Ansgar Burchardt]

Hi,

On Fri, 2017-04-21 at 09:28 +0200, Michael Stapelberg wrote:
> pabs, what’s the current status on this? AFAICT, you mentioned you
> wanted to come up with a spec on the RepositoryFormat wiki page. I
> don’t
> see that on the RepositoryFormat wiki page yet.
> 
> Is there any way to help?
> 
> I’m also interested in this issue due to hardcoding in manpages.d.o,
> which I’ve now described on
> https://wiki.debian.org/SuitesAndReposExtension#manpages.debian.org

While a file in the archive itself will also be useful, some
information is also available via api.ftp-master.d.o.  For example some
information about suites:

  curl https://api.ftp-master.debian.org/suites

If people need more information avialable, we can add more bits.  

Some documentation is available on
https://ftp-master.debian.org/epydoc/dakweb.queries-module.html

Ansgar

Re: Release impact of introducing a new archive section?

[Ansgar Burchardt]

Josh Triplett writes:
> Given that, can you please go ahead and add the two new sections for
> rust (https://bugs.debian.org/845576) and javascript
> (https://bugs.debian.org/753480), and update the override file for
> existing packages?  These packages should move to the "rust" section:
> rustc, cargo, libstd-rust*, and rust-*.  And all packages named
> node-*, libjs-*, and javascript-* should move to the "javascript"
> section.

I've done this now.

Ansgar

Re: no-strong-digests-in-dsc MBF

[Ansgar Burchardt]

Adrian Bunk writes:
> I want to do a MBF for all packages without a SHA256 checksum field
> in the .dsc [1] - only SHA1 as hash would not be good in stretch.

Why?  The Sources index should have a stronger hash either way.

If you care about stronger hashes in the .dsc itself, wouldn't the .dsc
itself be need to be signed by a stronger hash?  I would expect there
are still a lot more .dsc with "Hash: SHA1" in the archive.

Ansgar

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Ansgar Burchardt]

On Fri, 2017-01-06 at 07:48 +0100, Adam Borowski wrote:
> On Thu, Jan 05, 2017 at 12:19:08PM +0100, Ansgar Burchardt wrote:
> > With elogind do you mean https://github.com/wingo/elogind?  That
> > project doesn't look very active.
> > 
> > Is there any active project trying to reimplement the logind API? 
> 
> Consolekit2 for example; it suffers from being a fork of consolekit
> codebase though.

That one looks indeed still active.

> > Including access to devices (which X wants these days)?
> 
> That's just for ancient graphics cards (ie, with no KMS/DRM support)
> without xserver-xorg-legacy, right?

logind is required for drivers using KMS and *not* the legacy suid
wrapper, see /usr/share/doc/xserver-xorg-core/NEWS.Debian.gz.

I think wayland does the same (I haven't used it though).

So eventually alternatives should probably provide an alternative for
this part of logind too.

Ansgar

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Ansgar Burchardt]

On Thu, 2017-01-05 at 11:22 +0100, Adam Borowski wrote:
> Neither systemd-shim nor consolekit are solutions that are viable in
> the long term, the sooner we get rid of both, the better.  I don't
> know what's a good alternative, though.  Loginkit is
> vapourware.  Elogind maybe?

With elogind do you mean https://github.com/wingo/elogind?  That
project doesn't look very active.

Is there any active project trying to reimplement the logind API? 
Including access to devices (which X wants these days)?

Ansgar

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Ansgar Burchardt]

Ian Jackson writes:
> Michael Biebl writes ("Re: "not authorised" doing various desktoppy things"):
> I'm not sure I need "logind integration" in my X server but perhaps I
> do ?

Only if you want to start X as non-root.

> Simon McVittie writes ("Re: "not authorised" doing various desktoppy things"):
>> None of this works unless you have libpam-systemd installed and enabled.
>> That PAM module is somewhat mis-named: it's really for systemd-logind,
>> the user/login manager, and not the systemd init/service manager.
>
> In fact I didn't have libpam-systemd installed for some strange
> reason, but installing it hasn't helped.  (All the symptoms I report
> above are with it installed.)

How did you not have libpam-systemd installed?  network-manager has
Depends: policykit-1 and policykit-1 has Depends: libpam-systemd.

Ansgar

Re: Can we kill net-tools, please?

[Ansgar Burchardt]

Josh Triplett writes:
> Geert Stappers wrote:
>> On Mon, Dec 26, 2016 at 02:50:50PM +0100, Marco d'Itri wrote:
>> > ifconfig, route, etc...
>>
>>  From https://packages.debian.org/stretch/arm64/net-tools/filelist
>>
>>   * /bin/netstat
>
> The rest of net-tools aside (which have sensible replacements), what
> replaces netstat in the absence of net-tools?

Which parts of netstat?

`ss` displays socket information.  And is more informative then netstat,
for example it shows correctly which programs(!) use a listening socket.
Compare:

+---
| # netstat -xlp | grep gpg-agent.ssh
| unix  2  [ ACC ] STREAM LISTENING 258881911/systemd   
  /run/user/1000/gnupg/S.gpg-agent.ssh
| # ss -lp | grep gpg-agent.ssh
| u_str  LISTEN 0  128/run/user/1000/gnupg/S.gpg-agent.ssh 25888
 * 0 
users:(("gpg-agent",pid=20584,fd=5),("systemd",pid=1911,fd=22))
+---

(which reminds me of `ip` vs. `ifconfig` on interfaces with multiple
 IPv4 addresses.  `ifconfig` will show only one of them...)

Ansgar

Re: dpkg no longer installs conffiles??

[Ansgar Burchardt]

Hi Svante,

On Tue, 2016-11-29 at 17:58 +0100, Svante Signell wrote:
> After upgrading to sid the conffiles don't seem to be installed any
> longer?

I think it would be nice to make restoring the original configuration
easier.  The various --force-conf* options by dpkg are not easily
discovered and require the binary package (*.deb) to still be
available.

Having the original configuration available also would allow to easier
generate a "diff" of local changes.  This makes it easier to support
systems usually maintained by different people, or even systems not
using a configuration management system in general.

Maybe we should look at [1] for some ideas here.

Ansgar

  [1] http://0pointer.net/blog/projects/stateless.html

Re: misleading timestamps in binnmus

[Ansgar Burchardt]

On Thu, 2016-11-10 at 11:33 +, Ian Jackson wrote:
> Cyril Brulebois writes ("Re: misleading timestamps in binnmus"):
> > Ian Jackson  (2016-11-09):
> > > What version of sbuild do buildds run ?  Ie, supposing that this
> > > is
> > > fixed in sbuild in stretch, will this be fixed on the buildds
> > > ?  Or do
> > > we need to update jessie, or what ?
> > 
> > sbuild on buildds uses a specific version of sbuild, for reasons
> > I'm not
> > going to summarize. The base version is close to what's in jessie
> > (see the
> > first lines of any build log which has “sbuild (Debian sbuild)
> > 0.65.2”).
> 
> ...
> > Repository seems to live under:
> >   https://apt.buildd.debian.org/
> 
> Thanks.  When Johannes has decided exactly what the sbuild patch
> looks
> like in sid, I will take a look at the repo there and backport the
> change.  In what form should I supply mhy update ?  As an source+all
> upload of sbuild, as if I were being sponsored ?  As a
> git-format-patch against a git import of what I find there (or a
> dgitish git branch) ?

The source for the sbuild variant used on the buildds lives in a branch
of the sbuild repository (`buildd-0.65` for the current version I
think).

Ansgar

Re: misleading timestamps in binnmus

[Ansgar Burchardt]

On Wed, 2016-11-09 at 10:04 +0100, Sven Joachim wrote:
> On 2016-11-08 22:30 -0200, Johannes Schauer wrote:
> > It seems that sbuild indeed re-uses the timestamp from the last
> > debian/changelog entry in the binNMU changelog entry.
> 
> This has been done in an early attempt to make binNMUs co-installable 
> in a multiarch world:
> 
> ,
> > sbuild (0.62.2-1) unstable; urgency=low
> > [...]
> > - Improve binNMU handling to permit binNMUs for multiarch
> > packages
> >   (Closes: #620112).  Currently, binary NMUs use the current
> > date
> >   in the new changelog entry, but co-installable packages
> > require
> >   an identical changelog.  To avoid this, take the date from
> > the
> >   previous changelog entry to ensure the same date for all
> > binNMUs.
> > [...]
> >  -- Roger Leigh   Tue, 05 Apr 2011 10:46:49
> > +0100
> 
> `
> 
> Which did not help, because the changelog is not actually identical
> anyway.

The date from the last sourceful upload should probably still be used
for any date/time information included in generated files to ensure
they are identical on all architectures (or at least to try to do so).

If you change the date in the binNMU entry, SOURCE_DATE_EPOCH should
probably be set to the date of the last sourceful upload (instead of
just using the most recent changelog entry).

Ansgar

Re: awesome, it's done! (Re: When should we https our mirrors?)

[Ansgar Burchardt]

On Mon, 2016-10-24 at 16:30 +, Holger Levsen wrote:
> On Mon, Oct 24, 2016 at 11:51:00AM -0400, Paul Tagliamonte wrote:
> > https://deb.debian.org/ is now set up (thanks, folks!)
> 
> whoohooo, & it works on stable too! apt install apt-transport-https
> was
> all it took. (and changing the entries in sources.list to that…)
> 
> Just security.d.o (or rather, it's suites) are not available via
> https yet…
> 
> but still, very nice! thanks to everyone involved making this happen!

deb.debian.org has a debian-security area, so security updates should
also be available via https:// now.

Ansgar

Re: Package name conflict question

[Ansgar Burchardt]

"SZ Lin (林上智)"  writes:
> Although these packages are not API-compatible, they are using the
> same installation path and file name; therefore, I think "Conflict:"
> section is needed.

Note that Policy explicitly forbids using "Conflicts" in this case, see
the first paragraph in [1].

  [1] 

Ansgar

Re: Support for merged-/usr now in debootstrap; default for stretch?

[Ansgar Burchardt]

On Tue, 2016-09-27 at 15:42 +0500, Andrey Rahmatullin wrote:
> On Tue, Sep 13, 2016 at 10:36:58PM +0200, Ansgar Burchardt wrote:
> > 
> > debootstrap in unstable can now install with merged-/usr, that is
> > with
> > /bin, /sbin, /lib* being symlinks to their counterpart in
> > /usr.  Run
> > 
> >   debootstrap --merged-usr testing .../testing http://deb.debian.or
> > g/debian
> > 
> > to give it a try.
> usrmerge Conflicts: zsh << experimental, does this apply to
> debootstrap
> solution too?

The `Conflicts:` in usrmerge is too strict, see [1].

Ansgar

  [1] https://bugs.debian.org/824205

Re: Support for merged-/usr now in debootstrap; default for stretch?

[Ansgar Burchardt]

Ansgar Burchardt wrote:
> debootstrap in unstable can now install with merged-/usr, that is
> with
> /bin, /sbin, /lib* being symlinks to their counterpart in /usr.  Run
> 
>   debootstrap --merged-usr testing .../testing http://deb.debian.org/
> debian
> 
> to give it a try.

As I was just asked on IRC:

One can also test installations using d-i.  The images from [1] already
include the new debootstrap (at least on amd64), then just switch to a
shell early, run `nano /usr/sbin/debootstrap` and change

  MERGED_USR="no"

to

  MERGED_USR="yes"

and continue with the installation.

There might be a smarter way to do this, but for a quick test this
should work good enough. If we switch the default to merged-/usr, an
explicit opt-out preseeding option might be helpful to smoothen the
transition, given users one more cycle to adapt to the changes.

Ansgar

  [1] http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/
amd64/iso-cd

Support for merged-/usr now in debootstrap; default for stretch?

[Ansgar Burchardt]

Hi,

debootstrap in unstable can now install with merged-/usr, that is with
/bin, /sbin, /lib* being symlinks to their counterpart in /usr.  Run

  debootstrap --merged-usr testing .../testing http://deb.debian.org/debian

to give it a try.

It has been previously suggested to make this the default for (at least)
new installations.  I think Russ' earlier mail[1] explains quite well
why the "split" between / and /usr doesn't really work out for Debian
these days and that trying to maintain it for some configurations (which
are not documented) is mostly busy-work.  There is also a nice article
on LWN[2] summarizing earlier discussions.

I found these arguments convincing enough and would like to see the
default switched to merged-/usr for Stretch and later.  Possibly also
switching systems on upgrade to the new scheme (not necessarily already
in the Stretch release cycle).

Please remember that this still allows / and /usr to reside on different
filesystems: in this case the initramfs has to make sure /usr is mounted
as well.  This is already required for various reasons (again, see [1]).

Ansgar

  [1] https://lists.debian.org/debian-devel/2016/01/msg00081.html
  [2] https://lwn.net/Articles/670071/

Re: Is missing SysV-init support a bug?

[Ansgar Burchardt]

On Fri, 2016-08-26 at 00:11 +0200, Sven Hartge wrote:
> I just saw the new conntrack-tools (1:1.4.4-2) package in Sid, which
> has as a change
> 
>   * [917beed] conntrackd: get rid of the sysvinit support
> 
> and I wondered, if this is a bug (and at what severity) or not.

FWIW, there is now a request for the technical committee related to
this thread, see https://bugs.debian.org/835507

Ansgar

Re: Is missing SysV-init support a bug?

[Ansgar Burchardt]

On Thu, 2016-08-25 at 18:43 -0400, Robert Edmonds wrote:
> I looked up the answer to this recently (because I wanted to do
> exactly
> what the conntrackd maintainer had done).
> 
> The relevant text from the policy manual, §9.11:
> 
> Packages may integrate with these replacement init systems [i.e.,
> init systems which are not sysvinit] by providing
> implementation-specific configuration information about how and
> when
> to start a service or in what order to run certain tasks at boot
> time. However, any package integrating with other init systems
> must
> also be backwards-compatible with sysvinit by providing a SysV-
> style
> init script with the same name as and equivalent functionality to
> any init-specific job, as this is the only start-up configuration
> method guaranteed to be supported by all init implementations.

Was that changed since the default init system was changed?  It pretty
much still reads like Policy still assumes that sysvinit is the default
init system.  It also still mentions upstart in 9.11.1; will file a bug
for that.

If it wasn't changed, just s/sysvinit/systemd/ mentally ;)  It's not
the only place where Policy lags behind what is actual practice.

> The relevant TC decision was two years ago in #746715:
> 
> For the record, the TC expects maintainers to continue to support
> the multiple available init systems in Debian.  That includes
> merging reasonable contributions, and not reverting existing
> support without a compelling reason.
> 
> (https://lists.debian.org/debian-devel-announce/2014/08/msg1.html
> )
> 
> However, that was two years ago. How long should we be expected to
> continue maintaining sysvinit scripts?

Well, the quoted decision doesn't suggest active maintenance.  Just
ignore it, but don't remove it (random additional configuration(!)
files shouldn't be too bad).  So keep them, ignore them and in 10 years
we will eventually remove them ;)

Ansgar

Re: Proposed mass bug filing: use and misuse of dbus-launch (dbus-x11)

[Ansgar Burchardt]

On Thu, 2016-07-28 at 15:25 +0100, Simon McVittie wrote:
> On Thu, 28 Jul 2016 at 08:33:21 -0400, Marvin Renich wrote:
> > Do you mean metapackage or virtual package?  Wouldn't a virtual
> > package
> > be exactly the right thing for this?  Then dbus-user-session and
> > dbus-x11 would each "Provides: dbus-session" and no additional real
> > package is required.  Maybe I do not understand what is being
> > suggested.
> 
> If we want to avoid mass package changes when the preferred way to
> get
> a session bus changes, then either it has to be a real package, or we
> have to have a real dbus-default-session-bus package instead.
> 
> When there are two or more providers for a virtual package,
> dependening
> packages need to depend on a real package, with a virtual package as
> an alternative. If we just had

It is sufficient to ensure there is only one provider of the "default"
package. This is currently done for the default MTA: packages needing a
MTA depend on "default-mta | mail-transport-agent". The only provider
(in Debian) of default-mta is exim4-daemon-light, so exim4 is selected
by default if no other MTA is installed.

Ansgar

Re: Per-user package configuration

[Ansgar Burchardt]

Dmitry Bogatov writes:
> I am working on runit process supervision suite, and I want to provide
> user-local supervision support out-of-binary-package. User-local supervision 
> for
> requires one file pre user in /etc.  (Well, true is a
> bit more complex, but nevermind). One extra will be spawned per user).
>
> Question is: how to properly configure all this?

I would just let the administrator configure this, without debconf.

You might also look at what systemd does: start the supervisor for users
on login (and stop on logout), and allow users to request the supervisor
to be started at boot (and kept after logout) and give administrators
options to allow/deny such requests.

> My best idea so far is provide at installation time list of users with
> uid >= 1000, and ask for which of them user-local supervision should
> be enabled. But seems that debconf templates are static, and I can't
> dynamically generate list of choices (users). But I need to, since
> users can be added and removed, and I want 'dpkg-reconfigure' handle
> it.

That seems unhelpful on any installation that doesn't just have up to
five local users, but use an LDAP directory with thousands of users.

> Another, more crude, alternative is just enable user-local supervision
> for every user availiable in postinst. But it is not so nice to
> require sysadmin to run 'dpkg-reconfigure' every time user is removed
> or added.

This is probably also a bad idea if many users exist.

Ansgar

unstable-debug and experimental-debug gone for a day

[Ansgar Burchardt]

Hi,

we moved /debian-debug/dists/unstable-debug to sid-debug and added a
symlink unstable-debug -> sid-debug to have the debug suite for unstable
also available via its codename. The same for experimental-debug ->
rc-buggy-debug.

Sadly this directory-to-symlink conversion confuses our mirror scripts
(rsync): they are unable to convert a real directory to a symlink in a
single run. So we have to remove the symlink for a short while; we plan
to restore it in the next 24 hours.

The suitename in projectb was also changed temporarily (as it is used
when creating files). So rmadison will mention sid-debug instead of
unstable-debug for a short while.

Ansgar

Re: Neomutt packages available

[Ansgar Burchardt]

Ian Jackson writes:
> I don't think there is anything wrong with having a competing package.

There is. I'm fairly sure the security team will not be happy...
Packaging the *same* project twice seems even more useless busy work for
them than packaging lots of forks of the same project (which some people
might argue are not useless).

Ansgar

Re: Package tool with systemd dependency

[Ansgar Burchardt]

On Tue, 2016-06-21 at 10:55 +0100, Simon McVittie wrote:
> On Tue, 21 Jun 2016 at 11:11:09 +0200, Jan Luca Naumann wrote:
> > I want to package a tool* which highly uses systemd and particulary
> > its
> > per-user service feature.
> 
> By "per-user service" are you referring to systemd user services,
> which are
> children of the per-user service manager, "systemd --user"
> (aka the system service user@.service, started by systemd-logind)?

The upstream repository looks like it provides .service units for a
"systemd --user" instance.

> You should probably use Depends: libpam-systemd (which means you
> get a working systemd-logind somehow, either via systemd-sysv or
> sysvinit + systemd-shim) together with a Depends or Recommends on
> systemd-sysv. That's what I did for dbus-user-session.

AFAIK this is not enough to get a "systemd --user" instance. You would
need to depend on both libpam-systemd *and* systemd-sysv.

That said I think packages should avoid depending on systemd-sysv if
possible. It should be fine to only provide a unit for "systemd --user" 
and people who don't use systemd or libpam-systemd then have to
configure the service start and stop themselves.

Ansgar

Re: experimental syslog-ng

[Ansgar Burchardt]

Hi,

Matt Zagrabelny  writes:
> It appears that the version of syslog-ng for mirrors of
> ftp.us.debian.org's experimental repository is still at version
> 3.6.1+git20141206-g4d90138-4+b1, while tracker.d.o is reporting that
> the experimental version is at 3.7.1-3, and has been since Thu, 08 Oct
> 2015 21:51:09 +0200.
>
> At least the following mirrors' Packages.xz file shows the older
> 3.6.1+git version:

The package failed to build, see [1].

Ansgar

  [1] 

Re: Bug#824884: netbase: should not recommend ifupdown

[Ansgar Burchardt]

Henrique de Moraes Holschuh  writes:
> On Tue, May 24, 2016, at 13:03, Ansgar Burchardt wrote:
>> On Tue, 2016-05-24 at 11:43 -0300, Henrique de Moraes Holschuh wrote:
>> > On Tue, May 24, 2016, at 10:01, Simon McVittie wrote:
>> > > On Tue, 24 May 2016 at 09:08:11 -0300, Henrique de Moraes Holschuh
>> > > wrote:
>> > > > Whatever we do, we absolutely must bring up a fully configured
>> > > > loopback
>> > > > interface by default.
>> > > Happily, our default init system already does that.
>> > We need to ensure any non-default ones also do that before we drop
>> > ifupdown from "recommends", because ifupdown + default
>> > /etc/network/interfaces is the fallback that ensures the loopback
>> > will be up.
>>
>> We are not talking about removing "ifupdown" from the default
>> installation which includes all "Priority: important" packages (which
>> happens to include both netbase and ifupdown).
>>
>> The only installations affected are debootstrap's "minbase" and
>> "buildd" variants: these only install "Priority: required" packages and
>> select extra packages (apt and, for buildd, build-essential).  These
>> would no longer pull in "ifupdown" if "netbase" is installed.
>
> As far as I am concerned, ensuring the "master namespace" loopback is
> configured and up is actually required behavior and it should be
> enforced by something stronger than "priority important" packages being
> installed.  Systemd got this right.

I note that systemd is one of those "priority important" packages ;) I
have to admit though that "init" is still[1] at "Priority: required" and
depends on the lower-priority "systemd" package (a policy violation that
makes life much easier and sane).

  [1] <https://bugs.debian.org/824991>

> So, yes, I do think it would be best were it done by something in the
> initscripts package, since systemd is already doing it by itself as
> well.

That might be useful in either case to make sure "lo" gets setup
early. That would remove one subtle difference between systemd and
sysvinit.

> Also, it is "probably not ok" (as in I fully expect we will end up with
> people filling severity critical bugs should we do otherwise) to allow
> ifupdown (and likely netbase) to get uninstalled anywhere it was
> automatically installed, unless we ensure something else will take up
> their job.   This is not even related to configuring the loopback, but
> rather to /etc/network/interfaces processing, as well as /etc/services.

I'm not sure why "netbase" should be uninstalled anywhere if we remove
the "Recommends: ifupdown" from "netbase"?

Also all "Priority: important" packages installed by the default
installation should be marked as manually installed as far as I
remember.

I guess if you use the "minbase" or "buildd" variants, install "netbase"
and "ifupdown" only as a recommended package, then apt might suggest to
remove the no-longer recommended package.  I guess you mean this by
"automatically removed" even though it only happens by admin request as
far as I remember?  If you include other reasons for "automatically
removed", like for example running dist-upgrade and not checking what
will be removed, there are many other packages that could be removed and
break networking/firewall hooks.  (And "Recommends: ifupdown" will
likely not prevent that sort of removal for "ifupdown" anyway.)

Ansgar

Re: Bug#824884: netbase: should not recommend ifupdown

[Ansgar Burchardt]

On Tue, 2016-05-24 at 11:43 -0300, Henrique de Moraes Holschuh wrote:
> On Tue, May 24, 2016, at 10:01, Simon McVittie wrote:
> > 
> > On Tue, 24 May 2016 at 09:08:11 -0300, Henrique de Moraes Holschuh
> > wrote:
> > > 
> > > Whatever we do, we absolutely must bring up a fully configured
> > > loopback
> > > interface by default.
> > Happily, our default init system already does that.
> We need to ensure any non-default ones also do that before we drop
> ifupdown from "recommends", because ifupdown + default
> /etc/network/interfaces is the fallback that ensures the loopback
> will be up.

We are not talking about removing "ifupdown" from the default
installation which includes all "Priority: important" packages (which
happens to include both netbase and ifupdown).

The only installations affected are debootstrap's "minbase" and
"buildd" variants: these only install "Priority: required" packages and
select extra packages (apt and, for buildd, build-essential).  These
would no longer pull in "ifupdown" if "netbase" is installed.

Ansgar

Re: Debian i386 architecture now requires a 686-class processor

[Ansgar Burchardt]

Ian Jackson writes:
> IMO the way to read "is a bug RC" is "if the bug is not fixed, would
> Debian be better without the package, than with the buggy package".
> This calls for weighing the harm caused by the bug to the people
> affected, against the benefit of the package to other users.
>
> In this case I think the class of affected users is big enough - and
> there are generally enough alternatives - that the bug ought to be RC.
> If the packages are removed from Debian, then those users will be
> guided by our installation and package selection tools to other,
> working, software.

If we treated architectures in the same way, I wonder if we would have
any architecture other than amd64...  After all that will guide our
users to other, working, architectures.

(No, I don't find "let's just drop Qt/GNOME/X11/ncurses" a very useful
approach and I don't think it is very productive to suggest to do
so. More the opposite.)

Ansgar

Re: Overall bitrot, package reviews and fast(er) unmaintained package removals

[Ansgar Burchardt]

On Thu, 2016-04-07 at 15:29 +0200, Enrico Zini wrote:
> On Thu, Apr 07, 2016 at 02:23:42PM +0100, Steve McIntyre wrote:
> Definitely. But we still seem to have a few overly-territorial
> > people
> > failing to maintain their packages. Not 100% sure what to do about
> > that, as that same subset of developers are also not likely to read
> > threads on d-devel.
> I'd say:
> 
>  1. get DAM to say that we wouldn't close your account if you did it
> following a given set of steps (like, at least a successful NMU 
> with
> no reaction, and the salvaging NMU uploaded in the maximum
> delayed
> queue and notified [how?])
>  2. document it (a d-d-a post, a bit in developers-reference)
>  3. do it

For the notification in (1), I would guess filing a "intend to adopt"
bug against the package (not against wnpp) should be enough? The
maintainer would get that mail.  The mail should state that one wants
to adopt the package in case there are no objections in ${N} days.

How the adoption happens (upload to DELAYED/${N}-day or manual upload
after ${N} days) is an implementation detail and shouldn't matter.

In case of disagreements on the question whether the package needs a
new maintainer or not, the bug could be referred to the tech-ctte.

Ansgar

Re: arch all package's missing dependency on i386 prevents testing migration

[Ansgar Burchardt]

Neil Williams  writes:
> On Tue, 29 Mar 2016 21:25:26 -0700
> Afif Elghraoui  wrote:
>> The package in question, circlator, depends on two
>> architecture-dependent packages that can only build on amd64 and
>> kfreebsd-amd64 currently. The package cannot migrate to testing
>> because those dependencies are not available for i386 [1].
>>
>> I am hoping there is a better solution to this problem than to work
>> around this by changing this package's build architecture from "all"
>> to "any-amd64"
>
> That's not a workaround, it is the correct fix for the error in the
> original upload. The package cannot work on all architectures - the
> fact that this is because of dependencies rather than the code within
> the package is irrelevant. Unless the code in the package can
> *transparently* omit the need for the dependency on architectures where
> that dependency does not exist, then the package is not arch:all.
> Installation alone is insufficient, the package needs to be usable on
> all the architectures in the Architecture list.

No.  It is arch:all if it contains no arch-specific binaries and doesn't
require arch-specific dependencies (i.e. dependencies which should only
appear on specific architectures like "foo [amd64]").

It should be fine if an arch:all package depends on binary packages that
are not installable on all architectures.  Otherwise a lot of arch:all
packages that depend on, say, linux-specific binary packages would
become arch:any which is not very useful.

As far as I remember, the testing migration script checks installability
of arch:all packages on amd64 and i386, and there are manual workarounds
for arch:all packages that are not installable on these architectures.
Cc'ed the release team to take a look too.

Ansgar

Re: dh_gencontrol debug symbol wrapper: no debian/-dbgsym, skipping package

[Ansgar Burchardt]

Hi,

Nico Schlömer writes:
> I'd like to play around with the (new) auto dbgsym packages, and for
> starters build Mixxx [1] on launchpad's Xenial environment (featuring
> debhelper 9.20160115ubuntu2). Instead of an auto dbg package, however, I'm
> getting
> ```
> dh_gencontrol debug symbol wrapper: no debian/mixxx-dbgsym, skipping
> package mixxx
> ```
> Is this a server misconfig, or am I actually missing something from the
> package?

As far as I know Ubuntu implements automatic debug symbols in a
different way and only for the main archive. I don't think you will get
any automatic debug symbols for local builds or PPA uploads.

An Ubuntu development list probably is a better place to ask how
automatic debug symbols work there.

Ansgar

Re: default softphone in Debian stretch

[Ansgar Burchardt]

Daniel Pocock  writes:
> On 15/01/16 14:20, Bas Wijnen wrote:
>> On Fri, Jan 15, 2016 at 11:08:35AM +0100, Daniel Pocock wrote:
>>> If there are meta-packages (e.g. sip-client, xmpp-client), should
>>> any softphone be able to assert that it provides sip-client?  Or
>>> should there be some quality threshold?
>>
>> I think there should be a threshold.  Failing to meet that should
>> be ground for an RC bug.  In other words, the package can be in
>> unstable, but not in testing (or stable).
>
> Is this approach used in a formal manner with any other sets of
> packages, meta-packages or tags in Debian?

No, I don't think we have some sort of "quality" level for providing a
virtual package.  Just take a look at www-browser which is provided by
packages not getting any security updates at all or implementing SSL in
very broken ways (I remember reading about browsers that would just
accept any certificate silently).

Ansgar

Re: Going ahead with non-free-firmware

[Ansgar Burchardt]

Paul Wise  writes:
> On Mon, Jan 11, 2016 at 5:23 PM, Ansgar Burchardt wrote:
>> So you don't want another component, but something that looks like a
>> component in some places only?  I.e. it behaves like a component in that
>> it gets its own Packages (and Sources?) indices, but it has neither its
>> own area in pool/ nor is it used in packages' Section field.
>
> Right. This would be nice for some other use-cases too, like cut-down
> Packages/Sources files for special-purpose systems.

I'm pretty sure we don't want to do so in the main archive though as we
don't want to ship even more (large) indices.  Special-purpose
applications seem much better served with a solution based on tags in
the Packages index.

Also it would need someone to write code for the general solution first
if one would want to use it instead of using what we already have.

Ansgar

Re: Going ahead with non-free-firmware

[Ansgar Burchardt]

Stefano Zacchiroli  writes:
> On Mon, Jan 11, 2016 at 09:52:08AM +0100, Ansgar Burchardt wrote:
>> dak doesn't really like having a package in multiple components: the
>> layout of pool/ requires that the files would have to be duplicated.
>> Then dak only knows that a "binary package" belongs to a suite, not to
>> a given (suite, component) tuple, i.e. it will just appear in the
>> component where the files are located.
>
> I don't understand why we're talking about duplicating the actual .deb-s
> here. What I'd have imagined---but I don't know the internals of dak, so
> there is only that much I can contribute to the design discussion---is
> that the .deb-s would have been in a single place; under non-free
> exactly where they are now. Then, in addition to the usual Packages
> files for non-free, we would generate *another* one, that APT can find
> under non-free/firmware, which only contains a given subset of the
> .deb-s.
>
> Now of course the question is how to tell the Packages generation part
> of dak which packages should be in that subset Packages file. I would've
> expected to use some metadata for that. "Section: non-free/firmware",
> suggested by pabs, seems reasonable enough.

So you don't want another component, but something that looks like a
component in some places only?  I.e. it behaves like a component in that
it gets its own Packages (and Sources?) indices, but it has neither its
own area in pool/ nor is it used in packages' Section field.

I really don't want to add new special cases to dak, but get rid of
them.  They often don't work that well and get even less testing than
other parts of dak: as an example the fact that components are not named
{main,contrib,non-free}, but updates/{main,contrib,non-free} on the
security archive causes breakage quite often when related code is
changed...  (This is one of my motivations behind changing the security
archive besides the confusion about */updates vs *-updates.)

So I really don't want to implement support for this and have to
maintain it if it can be avoided.

>> I also think that it is nicer for packages to be just in one canonical
>> location.
>
> Absolutely agreed.
>
>> Finally note that users will most likely have to update their
>> sources.list for the stretch upgrade anyway as I also plan to rename
>> the security suite[1].  (It has been suggested to use symlinks to
>> allow continued use of the old names, but I think apt checks the
>> Suite: and Codename: fields of Release these days so that might not be
>> enough.  We also might want to eventually drop the old name.)
>
> I don't think that the fact users have to update their sources.list
> anyhow for an unrelated change is a very solid argument for imposing
> another one onto them.

I don't think it's particular bad to have to update sources.list either:
we often required so already (*-volatile, *-updates come to mind).  Its
nice to not have to think of this when updating machines, but I don't
think it warrants avoiding at all costs either.

Ansgar

Re: Going ahead with non-free-firmware

[Ansgar Burchardt]

Stefano Zacchiroli  writes:
> On Sat, Jan 09, 2016 at 08:48:25PM +, Steve McIntyre wrote:
>> Are we sure on the name? Previous commenters have suggested that
>> "non-free/firmware" might be better. I understand that may be more
>> awkward to implement in terms of directories... :-)
>
> If my recalling is correct, at the BoF there was indeed a mild
> preference for non-free/firmware, because that names better captures the
> fact that /firmware is indeed a sub-part of "non-free" rather than
> something new.

And gives problems: the "Section" field has either just the ${section}
or ${component}/${section}.  If component now also has a "/" in it,
there will likely be bugs.  I don't think aesthetic reasons call for
this breakage if we can avoid it.

> There was also concerns that introducing something
> *separate* wouldn't fly with the social contract, which explicitly
> mentions main/contrib/non-free whereas it does *not* mention
> non-free-firmware. In that sense "just" allowing to select a sub part of
> non-free wouldn't be a problem, whereas introducing something new might
> be.

If the social contract would forbid creating a new section
"non-free-firmware", I don't think that changing a letter in the name
would change much.

> But an important part of the above reasoning in favor of
> non-free/firmware was that user enabling explicitly non-free in the
> sources.list and *not* enabling non-free/firmware would get the non-free
> firmware anyhow. I.e., no regressions or changes needed w.r.t. the
> status quo. From other messages in this thread I understand this is
> actually not going to be the case. Which would be problematic and also a
> little bit disturbing. Is really no technical way to easily allow to
> have packages in multiple (sub-)parts of the archive?

dak doesn't really like having a package in multiple components: the
layout of pool/ requires that the files would have to be duplicated.
Then dak only knows that a "binary package" belongs to a suite, not to a
given (suite, component) tuple, i.e. it will just appear in the
component where the files are located.

Now one could hack dak into duplicating files intentionally for some
uploads, but I don't really like that: it allows disparities between the
packages in "non-free" and "non-free-firmware" as some settings are
applied per-suite (e.g. copying packages to testing) and others
per-component (e.g. overrides) and some are implicit on where files are
located.  The latter because originally files could only be located in
one component, but this caused issues when packages moved between
components and reused the same upstream tarball.

I also think that it is nicer for packages to be just in one canonical
location.

Finally note that users will most likely have to update their
sources.list for the stretch upgrade anyway as I also plan to rename the
security suite[1].  (It has been suggested to use symlinks to allow
continued use of the old names, but I think apt checks the Suite: and
Codename: fields of Release these days so that might not be enough.  We
also might want to eventually drop the old name.)

Ansgar

  [1] 

Re: Going ahead with non-free-firmware

[Ansgar Burchardt]

Paul Wise  writes:
> On Sat, Jan 9, 2016 at 6:51 PM, Ansgar Burchardt wrote:
>> I think there was consensus to introduce the non-free-firmware section
>> and move the non-free firmware blobs there.  I'm wondering what we need
>> to do next?
>
> I have a question about the implementation; will non-free firmware be
> in non-free and non-free-firmware or just non-free-firmware?

Just in non-free-firmware.  This means users will have to update their
sources.list, but they will have to do so anyway[1].

There are at least two reasons for this: having a package in two
locations means one has to keep track of them so every action like
removing or adding it to a suite has to be done in sync.  Also dak
splits the pool/ directory by component[2]: having the same package in
two components means file duplications (though firmware probably is
quite small).

Ansgar

  [1] <https://lists.debian.org/debian-security/2015/12/msg00015.html>
  [2] If I were to implement this again, I wouldn't support multiple
  components per suite: just have separate suites sid, sid-contrib,
  sid-non-free. The files could still be split across different
  areas of pool/ per suite, but no source packages is main that
  also build binaries in the contrib section or other such
  complications.

Going ahead with non-free-firmware

[Ansgar Burchardt]

Hi,

I think there was consensus to introduce the non-free-firmware section
and move the non-free firmware blobs there.  I'm wondering what we need
to do next?

Besides the ftp team setting the new section up, I expect the installer
would need changes to enable it instead of non-free when non-free
firmware is required; maybe it still needs to ask for non-free as well
for other reasons?  Other teams might also need to add the new section,
e.g. the release team, packages.d.o, ...  I expect the list to be
hard-coded in quite a few places.

Then the release notes need to document that "non-free-firmware" might
have to be added to sources.list.

Finally we need to identify the packages that should move there.  I
guess all non-free packages named "firmware-*" would be a good match.

Ansgar

Bug#810378: lintian: suggest to use https:// over git:// (was: Re: Death to git://! Long live git://!)

[Ansgar Burchardt]

Package: lintian
Severity: wishlist

Paul Tagliamonte  writes:
> We still have `git://` all over the place, for instance, on Vcs-Git on
> control files. That makes me sad. Boo insecure transports.
>
> `git://` is plaintext, and plaintext transports are bad.
>
> I'd like to suggest we move all Vcs-Git entries to either `https` or
> `ssh`.

I think moving to https:// over git:// is a good idea.  lintian could
probably suggest this change, just like it did with canonical VCS URLs
before.

Ansgar

Re: support for merged /usr in Debian

[Ansgar Burchardt]

Craig Small  writes:
> On Tue, Jan 05, 2016 at 03:55:51PM +, Ian Jackson wrote:
>> What is causing all the heat is the suggestion that support might be
>> withdrawn for currently working configurations which _do_ have a /usr
>> vs / distinction, or which do mount /usr using / rather than
>> initramfs, or some such.
> Which actually was never proposed. There were some "what if" type
> posts, but noone was mandating a merged /usr anywhere.

What is the advantage of having a optional-merged-/usr?

>From what I understand the main argument for having merged-/usr was to
reduce maintenance overhead of having to decide between /bin and
/usr/bin or more importantly /lib and /usr/lib and moving things between
both locations.  With an optional-merged-/usr, one still has the
overhead, i.e. no advantages over state quo I can see?

As a step towards merged-/usr (only) it might sense to have such an
optional-merged-/usr to start identifying issues, but what is the point
if we keep it optional?  It just makes it less likely that people will
find issues with split-/usr (i.e. applications using /usr/bin/foo
instead of /bin/foo in some places).

Ansgar

Bug#809705: general: let people use non-free software but opt-out of non-open software

[Ansgar Burchardt]

Philippe Cerfon  writes:
> On Mon, Jan 4, 2016 at 8:45 AM, Niels Thykier  wrote:
>> Philippe Cerfon:
>> Your second item has been brought up before with different
>> focus/rationale/purpose.  At least I remember there being an interest in
>> splitting "non-free" into "non-free/firmware" vs. various other non-free
>> sub components.
>
> Well, I think splitting of just the firmware sounds far less appealing.
> Actually in some cases having a non open firmware may not be *that*
> big security issues, e.g. when it's used to be loaded in some external
> device (something like ColorHug) and for many other firmwares there is
> simply no alternative (or e.g. one won't have networking).
> So while it would make of course to split of the non-open firmware
> packages as well, the whole effort seems to rather only make sense if
> really everything non-open is split off.

Then why should one have "non-open" at all?  The argument was that this
somehow brings some sort of "security" by being able to audit things
(though the license may probably still forbid you from doing so or
publishing your results, its non-free after all), but then there are
"non-open" packages where this doesn't matter anyway...

The reason for the "non-free-firmware" component is the admission that
in many cases non-free firmware is required to correctly use the
hardware.  While this is not ideal, we want people to be able to use
Debian on their hardware with the minimum amount of non-free things[1].

I don't think Debian should bother with differentiating between levels
of non-freeness on the level of components besides this: after all
Debian is about free software, not the various levels of non-free
things.  Having them on the level of debtags or similar is way more
flexible and more likely to suit different uses.

Otherwise we end up with "non-free", "non-open", "non-free-data",
"non-free-documentation", "non-free-firmware", "non-open-firmware",
"non-open-data" and so on.  Just imaging a sources.list with 10
different non-free component and only one free component ("main") ;)

Ansgar

  [1] Personally I don't see much of a difference between having such
  non-free blobs supplied by the operating system or having them
  stored in some sort of ROM, though the FSF sees that different.
  This should be unrelated to the decision whether to provide
  non-free-firmware as an extra suite or not.