Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable

[Zack Weinberg]

On 2022-09-28 5:30 PM, Ansgar wrote:

On Wed, 2022-09-28 at 16:40 -0400, Zack Weinberg wrote:

"Available and usable at all times" is orthogonal to "maintainer scripts
do not render the system unbootable".  As I read things, *all* packages
bear the responsibility of not rendering the system unbootable.


No, it's a significantly weaker requirement than what you want to
impose. If it is not available and usable at all time, it can clearly
render the system unbootable (by not being available or usable at
boot).


The vast majority of Debian packages provide programs, libraries, etc. 
that are not used at all during the boot process.  Therefore, *even if* 
those packages are currently unusable, due to a crash in the middle of 
an upgrade that left them unpacked-but-not-configured, or whatever, they 
can't prevent the system from coming up at least as far as the point 
where it's possible to get a root shell and run `dpkg -a --configure`.


The small subset of packages that *are* used at boot time, do need to 
take extra care to keep working even if they are unpacked but not 
configured, and that subset and that extra requirement is codified as 
the rules for (transitively) Essential packages.


But *all* packages must take particular care *in their maintainer 
scripts* to not render the system unbootable, because maintainer scripts 
are all run with full root privileges, at a time when the system is in a 
partially ill-defined state (since it is in the process of being 
upgraded -- this is why we have the "postinst scripts can't assume any 
non-Essential functionality works" rule), and yet it could still be in 
active use (there has never been a requirement to take the system to 
single-user mode before running 'apt-get upgrade').


But most packages don't *do* anything in their maintainer scripts that 
has any serious *risk* of rendering the system unbootable, and therefore 
we don't have to worry about them.  The subset of packages that do 
dangerous things in their maintainer scripts *overlaps* the set of 
Essential packages, but there are members of each set that are not 
members of the other.


There is also a set of packages where it's the *installed software* that 
might have bugs that render the system unbootable, such as 
implementations of fsck for particular filesystems.


Do you understand the distinctions I am making?  If you don't, please 
explain what doesn't make sense about what I just said, because I don't 
think we're going to get any further with this discussion until you do.



One of the several documented
justifications for that severity is "potentially renders the system
unbootable".  I see nothing anywhere that limits the scope of that
justification to essential packages, or to any other subset of the archive.


I tried searching for that justification and a major internet search
provider just says 'Your search - "potentially renders the system
unbootable" - did not match any documents.'


https://www.debian.org/Bugs/Developer#severities

The official wording appears to be "makes unrelated software on the 
system (or the entire system) break".  I hope you will agree that a 
system that doesn't boot is entirely broken.


https://salsa.debian.org/reportbug-team/reportbug/-/blob/master/reportbug/debbugs.py#L79 
is where I got the "unbootable" phrasing.


zw

Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable

[Zack Weinberg]

On 2022-09-28 3:06 PM, Ansgar wrote:

On Wed, 2022-09-28 at 14:54 -0400, Zack Weinberg wrote:

On 2022-09-28 2:40 PM, Ansgar wrote:

If I thought there was a bug in some other package that posed a
significant risk of rendering Debian systems unbootable on upgrade, I
would have filed a report against THAT PACKAGE.


Okay, so I understand this is an arbitrary requirement for *just*
usrmerge. Any other package may still break the system (as there are
enough critical packages).


I don't understand how you got from what I said to "this is an arbitrary
requirement just for usrmerge".

It is, in fact, a *non*-arbitrary requirement, spelled out in Policy as
such, that applies to *all* packages.  "Potentially breaks the entire
system (e.g. by rendering it unbootable)" = critical-severity bug.


During upgrades, package dependencies might not be satisfied, there is
no guarantee that non-essential (as in the Policy meaning of essential)
packages work at all, partly-unpacked essential packages are likely
also interesting.

The system can crash while any of this is the case, not even involving
more complex parts like maintainer scripts.

This obviously also includes boot loaders and similar.

Your requirement is that a system must *never* become unbootable in
*all* of these states. 


Yes, and furthermore I think Debian has required this for many, many years.


So again: please show that other packages don't have such issues in
general.


I do not think it is reasonable for you to ask that I investigate the 
possibility of bugs existing in other packages before I file a bug on 
your package.


zw

Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable

[Zack Weinberg]

On 2022-09-28 2:16 PM, Marco d'Itri wrote:

it appears to be possible
for the next boot to find the root filesystem in a state where /lib or
/bin doesn’t exist at all.  Recovery from this state will require
booting from installation media.

This is technically correct.
But after 8 years of development in Debian, and after Ubuntu converting
all their user base on upgrades, no such event has been reported.


I don't think you can draw conclusions from Ubuntu in this context since 
their upgrade process is radically different.  If I remember correctly, 
they invoke convert-usrmerge at a point when the system is effectively 
in single-user mode, and thus other processes are much less likely to 
interfere.


I also don't think you can draw conclusions from 8 years of past 
development within Debian because the vast majority of Debian 
installations that were originally installed unmerged (pre-bullseye or 
opt out) *have not yet been converted*.  Most people who maintain Debian 
installations, after all, aren't paying any attention to this process. 
They'll get the conversion *only* when they upgrade to bookworm.


As such I think we haven't yet seen *most* of the truly weird conditions 
under which convert-usrmerge will be invoked, and I think you should 
reconsider.


zw

Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable

[Zack Weinberg]

On 2022-09-28 2:04 PM, Ansgar wrote:

On Wed, 2022-09-28 at 13:53 -0400, Zack Weinberg wrote:

On Wed, Sep 28, 2022, at 1:47 PM, Ansgar wrote:

No, you would need to atomically replace the *entire* system, not
just
individual directories.


??? Atomic replacement of each affected directory is, as far as I can
see, both necessary and sufficient to prevent the system being
rendered unbootable.


No. It is not sufficient. Upgrading packages can affect multiple
directories and half-upgraded packages can easily render systems
unbootable.


Do I really have to spell this out for you?

Atomic replacement of each directory replaced with a symlink by 
convert-usrmerge should be sufficient [unless I missed something while 
reading through convert-usrmerge's code] to prevent the system being 
unbootable AS A CONSEQUENCE OF ACTIONS PERFORMED BY convert-usrmerge.


If I thought there was a bug in some other package that posed a 
significant risk of rendering Debian systems unbootable on upgrade, I 
would have filed a report against THAT PACKAGE.


zw

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

[Zack Weinberg]

On 2022-09-28 2:16 PM, Russ Allbery wrote:

"Zack Weinberg"  writes:


1. Is there already a rule (or multiple rules) somewhere that forbids
the existence of pairs of packages where one ships /X/Y and the
other ships /usr/X/Y, where X is a directory on non-merged-/usr
systems and a symlink on merged-/usr systems, and Y is any name?


Policy 10.1:

 To support merged-/usr systems, packages must not install files in
 both /path and /usr/path. For example, a package must not install both
 /bin/example and /usr/bin/example.


That does not clearly say that a *pair* of packages, where one installs 
files in /path and the other one installs files in /usr/path, is not 
allowed.  I'm guessing it was the *intent*, but the example, at least, 
makes it sound like it's only talking about within a single package. 
Suggest maybe the editorial addition of


For another example, if one package installs /bin/example, then
no package which is coinstallable with that package may install
/usr/bin/example.

(the "coinstallable with" clause means to clarify that the existing pair 
discussed upthread is fine because there's a package-level Conflicts)


zw

Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable

[Zack Weinberg]

On Wed, Sep 28, 2022, at 1:47 PM, Ansgar wrote:
> No, you would need to atomically replace the *entire* system, not just
> individual directories.

??? Atomic replacement of each affected directory is, as far as I can see, both 
necessary and sufficient to prevent the system being rendered unbootable.

> But please explain how this is specifc to usrmerge and not many other
> packages.

As I already said, this code needs to be extra robust because it is being run 
from a postinst script, at some unpredictable moment in the middle of an 
upgrade to bookworm (in most cases).

zw

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

[Zack Weinberg]

On Wed, Sep 28, 2022, at 1:40 PM, Helmut Grohne wrote:
> Hi Zack,
>
> On Wed, Sep 28, 2022 at 12:29:19PM -0400, Zack Weinberg wrote:
>> I thought about this a bunch yesterday evening and I believe I see a
>> concrete scenario that can cause problems but is not covered by the
>> moratorium: Suppose there exist two packages, one of which ships
>> /bin/foo, and the other ships /usr/bin/foo.  On a non-merged system,
>> these packages can coexist.  On a merged system, they have a file
>> conflict that dpkg will not detect.
>
> $ ssh delfin.debian.org sqlite3 
> /srv/dedup.debian.org/database/dedup.sqlite3 '"'"SELECT * FROM content 
> AS ca JOIN content AS cb ON ca.filename = './usr' || 
> substr(cb.filename, 2) WHERE cb.filename NOT LIKE './usr/%';"'"'
> 166447797|96615|./usr/bin/systemctl|201531|221889683|4004|./bin/systemctl|1173136
> 210029518|32365|./usr/sbin/update-service|2917|223295080|31077|./sbin/update-service|4573
> $
>
> So we have systemctl vs systemd and daemontools-run vs runit, both of
> which declare Conflicts.

*nod* I don't think we need to worry about this when there's a declared 
package-level conflict.

> Depends on whether you consider that one-liner above tooling I guess.

Good enough for now, probably -- it would be nice to have some automation 
searching for such overlaps in packages that *don't* declare Conflicts, and 
filing bugs, but I won't call that a blocker.

> Do you see any other issues?

Not at present, but I'm not the person you should be asking!  The only person 
who could possibly say "yeah, the rules in place are sufficient to prevent 
problems post-bookworm until the bugs are actually fixed", with the level of 
confidence we need before proceeding with this transition, is ... the dpkg 
maintainer.

zw

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

[Zack Weinberg]

On Wed, Sep 28, 2022, at 5:08 AM, Svante Signell wrote:
>
> You can easily revert any system having usrmerge installed with dpkg-
> fsys-usrunmess. This should be known by all Debian users, by some
> suitable channel.

Having used it myself a couple of times, I would question "easily".  If all 
goes well, yes, you run it and you reboot and you're done, but if all *doesn't* 
go well you're left having to manually repair a system with important files not 
existing in *either* their unmerged or their merged location, which may require 
booting from recovery media.

I'd say that if Debian were going to widely advertise the availability of 
dpkg-fsys-usrunmess, first it ought to be revamped to ensure that it's fully 
restartable, idempotent, and never, not even transiently, places the system in 
a state where it cannot boot at least as far as single user mode (in systemd 
terms, rescue.target, *not* just emergency.target).

Of course the exact same criticism applies to convert-usrmerge -- skimming its 
code just now, it appears to be idempotent and restartable in principle, but if 
"the system crashes at a really bad time" (to quote its own comments) I think 
it _could_ leave the system in a state where it cannot boot as far as 
rescue.target.  In fact, see #1020920.

zw

Bug#1020922: usrmerge: please split convert-* scripts into separate package from the postinst that actually performs the conversion

[Zack Weinberg]

Source: usrmerge
Version: 31
Severity: wishlist
X-Debbugs-Cc: z...@owlfolio.org

It would be significantly easier to experiment with convert-usrmerge
under exotic conditions if the scripts were installable without also
pulling the postinst that performs the conversion.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-1-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable

[Zack Weinberg]

Package: usrmerge
Version: 31
Severity: critical
Justification: breaks the whole system
X-Debbugs-Cc: z...@owlfolio.org

convert-usrmerge is nominally idempotent and restartable, but (as it
says in the script’s own documentation) if “the system crashes at a
really bad time” during the conversion process it might not be
possible to recover without manual intervention.  Unfortunately, it’s
worse than that: if the system crashes at _just_ the wrong time
(specifically, in the middle of a convert_directory operation, in
between the rename() and symlink() calls) it appears to be possible
for the next boot to find the root filesystem in a state where /lib or
/bin doesn’t exist at all.  Recovery from this state will require
booting from installation media.

Since the current plan for the usrmerge transition is to run
convert-usrmerge from usrmerge’s postinst, during (for most
installations where a conversion is required) a bullseye->bookworm
upgrade, which system administrators may choose to do *without*
dropping to single user mode, a crash at exactly that point is
plausible due to interactions with other concurrent processes.
Imagine that a watchdog process picks exactly the moment where /bin is
being replaced to check whether it can exec /bin/true, or (perhaps
more plausible) a server picks exactly the moment where /lib is being
replaced to try to load an NSS module, fails, crashes, and then a
watchdog notices the server crash and triggers a reboot.

To fix this, I think some technique for replacing directories with
symlinks _atomically_ needs to be found.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-1-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages usrmerge depends on:
ii  libfile-find-rule-perl  0.34-2
ii  perl5.34.0-5

usrmerge recommends no packages.

usrmerge suggests no packages.

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

[Zack Weinberg]

On Tue, Sep 27, 2022, at 4:12 PM, Sebastian Ramacher wrote:
> On 2022-09-27 10:26:36 -0400, Zack Weinberg wrote:
>> On Tue, Sep 27, 2022, at 5:15 AM, Sebastian Ramacher wrote:
>> >> I'd like to make sure that the bug submitter has not identified
>> >> something new here.
>> >
>> > I've not seen any new issues appearing since the last round I file bugs.
>>
>> I wasn’t aware that you have been filing bugs related to the
>> transition.  What criteria are you using to find and file those bugs?
>
> I only checked for packages violating the moratorium. Thankfully a check
> for that was implemented by Luca in piuparts. If we have additional
> patterns that could cause issues for upgrades, the check would ideally
> be extended with that information.

I thought about this a bunch yesterday evening and I believe I see a
concrete scenario that can cause problems but is not covered by the
moratorium: Suppose there exist two packages, one of which ships
/bin/foo, and the other ships /usr/bin/foo.  On a non-merged system,
these packages can coexist.  On a merged system, they have a file
conflict that dpkg will not detect.

For practical reasons I doubt that two such packages actually exist --
nobody wants the concrete implementation of "foo" to be selected by
what order the user happened to list /usr/bin and /bin in their PATH,
this is what alternatives are for -- but, I don't see anything in
Policy that *forbids* it outright.  (I could have missed something.)
Also, the undetected file conflict can happen in *any* directory that
is converted to a symlink on a merged system, and  it's at least
vaguely plausible to me that there might be packages shipping
small variations on the same library as /lib/foo.so and /usr/lib/foo.so
(perhaps one has fewer dependencies, to be used during early boot).

So questions for you and everyone else reading this:

1. Is there already a rule (or multiple rules) somewhere that forbids
   the existence of pairs of packages where one ships /X/Y and the
   other ships /usr/X/Y, where X is a directory on non-merged-/usr
   systems and a symlink on merged-/usr systems, and Y is any name?

2. Does Debian already have tooling that can *find* pairs of such
   packages?  (This is a fully independent question from 1.  If
   there's a rule but no automation to enforce it then we don't *know*
   nobody's breaking the rule.  If there is no rule then, before we
   consider adding such a rule, we need to know whether any packages
   exist that break it.)

zw

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

[Zack Weinberg]

On Tue, Sep 27, 2022, at 12:25 PM, Andreas Metzler wrote:
> On 2022-09-27 Zack Weinberg  wrote:
> [...]
>> What I am asking for is a schedule change: specifically, that the
>> merged /usr transition not be allowed to proceed past the status quo
>> as of two weeks ago (i.e. *before* init-system-helpers added a
>> dependency on usrmerge|usr-is-merged) until after the dpkg bugs are
>> fixed to the satisfaction of the dpkg maintainers.
> [...]
>
> Hello Zack,
>
> Afaiui the only thing the change two weeks caused is an increased
> percentage of usrmerged Debian installations.

It is *conceivable* that a system that has been *converted* to
merged-/usr, in the way usrmerge does it, is different from a system
that was originally installed with merged /usr, in a way that matters
to whether the dpkg bugs can be triggered on that system.  I thought I
had come up with just such a scenario yesterday, in fact.  On further
consideration I was wrong -- but that doesn't mean there are no such
scenarios.

However:

> Afaict the problem is unchanged: There is a very large number of
> usrmerged systems (every system installed with bullseye installer or
> newer unless some very specific steps were taken to avoid this) which
> are prone to bugs due to dpkg not having been changed *first*. This
> number is of usrmerged systems is so large that we cannot mark them as
> unsupported ("Please reinstall"). Whether this percentage is 25% or 90%
> does not matter.

I basically agree with this assertion.  For instance, I think it's not
realistic to roll back every such system to an un-merged state, and
then restart the entire transition, this time following the procedure
that was used when /usr/man was moved to /usr/share/man, which is, it
appears to me, what Guillem would ideally like to have happen.

(I will point out, though, that if we had done it that way starting in
2015 or even 2017, *we would be done by now*, since that process takes
exactly three releases to complete.)

If I had had the authority to make the relevant decision at the time,
I probably would have insisted on getting the dpkg bugs fixed before
the installer's default could be changed.  But that ship has sailed.

However, I think there's still value from a process-management
perspective in declaring that non-merged systems may not be converted,
and are to remain supported, until all critical components of the
distribution -- in particular dpkg -- fully support the merged state.
For instance, it means that the proponents of the transition have a
concrete incentive to get *all* of the remaining work done, and not
just the piece that matters to them.

zw

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

[Zack Weinberg]

On Tue, Sep 27, 2022, at 5:15 AM, Sebastian Ramacher wrote:
>> I'd like to make sure that the bug submitter has not identified
>> something new here.
>
> I've not seen any new issues appearing since the last round I file bugs.

I wasn’t aware that you have been filing bugs related to the
transition.  What criteria are you using to find and file those bugs?

If you have time to put into actively *looking* for bugs *other than*
the one identified by Simon, that would be hugely helpful and I think
a good way to go about it would be to write a fuzzer for package
upgrades — try to generate the weirdest possible scenarios of packages
splitting, recombining, replacing each other, conflicting with each
other, transferring files among each other, diverting each other’s
files, etc. etc.  Using that, see if you can come up with concrete
reproducers for all the data loss scenarios listed by Guillem at
, or for *other* data
loss scenarios, hitherto unsuspected by anyone.

zw

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

[Zack Weinberg]

On Tue, Sep 27, 2022, at 4:23 AM, Matthew Vernon wrote:
> Thanks for bringing this to the committee; even if Sean is correct that
> we won't act on this report, you've described the issues clearly and I
> think it was worth bringing to our attention.

Thank you for saying so.

> As Sean says, though, questions of what are and aren't RC bugs are
> typically the domain of the release team, not the TC.
>
> I don't think you're asking us to revisit our decision on the approach
> taken to merged-/usr

No, I am not.  To be excruciatingly specific, I do not want to
re-litigate the decision on “merged /usr via aliased dirs” vs
“merged /usr via moves and symlink farms”.

What I am asking for is a schedule change: specifically, that the
merged /usr transition not be allowed to proceed past the status quo
as of two weeks ago (i.e. *before* init-system-helpers added a
dependency on usrmerge|usr-is-merged) until after the dpkg bugs are
fixed to the satisfaction of the dpkg maintainers.

I do not think that this is “returning to a decision once made” and I
*do* think that this is within the ambit of the TC’s responsibilities.
(Concretely, the TC would be overruling Luca Bonassi on the subject of
whether init-system-helpers may depend on usrmerge|usr-is-merged, and
issuing more project-wide advice on the timing and the blockers for
the transition.)

> I think the best way to proceed would be to open a bug describing the
> problem that Simon outlines with RC severity; the relevant maintainers
> and release team can then discuss how to resolve the issues and if they
> warrant delaying the release or adjusting when we complete the
> transition. Obviously those people might want to ask the TC for advice,
> but I think that would be up to them at least in the first instance.

This gets into interpersonal issues.  Supposing I filed a critical-
severity bug on any or all of dpkg, usrmerge, or init-system-helpers,
I fully expect that the respective maintainer would immediately close
it as either not their problem or not actually a problem at all.
I would then have to come back here and request that you override
their determination of the severity and/or appropriate package to
carry the bug.  Having the TC act first would save everyone involved
some steps, wouldn’t it?

zw

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

[Zack Weinberg]

[Procedural note: I’m very busy with my day job this week, so I will
be responding to messages related to this report in batch mode, once a
day.]

On Mon, Sep 26, 2022, at 4:49 PM, Sam Hartman wrote:
>> "Sean" == Sean Whitton  writes:
>
> Sean> - you might be lacking the full context of TC-involving
> Sean> discussions over the past few months, but so far as I can see,
> Sean> you are asking for us to undo a decision that we only just
> Sean> made, which doesn't make sense.
>
> Sean, as someone who has tried to follow this for a while, I'm confused
> by a third thing.
> Doesn't the TC recommendation given additional weight by the RT that we
> not migrate file paths until the dpkg bug has been fixed  make it
> impossible for the pre-conditions for disappearing files to happen?

I may have misunderstood the TC recommendation here.  I was under the
impression that the “no migration of file paths” rule was *only* in
effect until the release of bookworm, and that it was motivated by the
need to continue supporting non-merged systems up till that point, not
by the dpkg bugs.

If the rule is in effect until the specific dpkg bug identified by
Simon is fixed, then that does make the situation *somewhat* less
dire, but I still stand on the request I made, because of:

>>Several other equally dire scenarios
>>are listed in https://wiki.debian.org/Teams/Dpkg/MergedUsr under the
>>“merged-/usr-via-aliased-dirs” subheading, albeit only tersely.)
>
> I think that if you are going to ask for drastic action like you are
> doing, a turse mention on a wiki page is not sufficient documentation.
> Simon's mail got significant attention because he actually worked
> through and documented the situation.
> I and I believe several people who have looked at this situation believe
> that the RT guidance will prevent the issue Simon raised from happening.

I think this may get at the heart of the disconnect between my
perspective and yours.  You are apparently content to think that the
issue Simon identified is the only issue that actually needs a remedy.
I, on the other hand, am assuming that this is only one of potentially
dozens of similar data-loss scenarios (not necessarily dozens of
*bugs*; perhaps just several other scenarios that tickle the same bug)
and that most of them are *not* addressed by the “no migration of file
paths” rule.

I believe this, fundamentally, because I believe Guillem Jover.
You say that “if you are going to ask for drastic action like
you are doing, a terse mention on a wiki page is not sufficient
documentation”, and that would be fair if it was me who wrote
the wiki page, but it was Guillem who wrote it, and *he’s the
dpkg maintainer*.  If he says there’s a situation where, quote,
“dpkg and dpkg-divert are currently broken by this approach, will
fail to notice file conflicts and will overwrite files” then I
take that seriously, and what I want here is fundamentally for
the project as a whole to take Guillem’s concerns seriously.
This is why I said “to the satisfaction of the dpkg maintainers”
in my original request.

In particular, it should not be on me, or Guillem, to demonstrate
how each of the problems listed on the wiki page can be triggered.
It should be *the proponents of usrmerge* who are held responsible
for fully investigating just how many data loss scenarios there are,
and for proposing solutions.  Given that they have spent the last five
years, possibly more, *refusing* to do so, I think it is entirely
reasonable for the project to demand a halt to their proposed change
until they have done all of the due diligence that they *should* have
done five years ago.

I know that usrmerge has been planned for rather *longer* than five
years now, but here’s the thing: No properly-written Unix program
has any reason to *care* whether /bin is a symlink to /usr/bin.
Therefore there is no justification for pursuing usrmerge with any
kind of urgency.  I can see the value from a theoretical system
integration design perspective, and I don’t mind it happening
*eventually*, but I do very much care that it not render my personal
workstation (which has tracked unstable for 25 years now with no
serious issues) unbootable.

(Postscript: Let me be clear that I’m just a user of the distribution.
I’ve never even considered becoming a DD.  But as a longtime contributor
to several key upstream projects for *all* Linux distributions, and as
someone who *has* been running Debian unstable on his personal workstation
for 25 years, I’d like to think that I know what I’m talking about when
I say things like “no properly-written Unix program has any reason to care
whether /bin is a symlink to /usr/bin”.)

zw

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

[Zack Weinberg]

On Mon, Sep 26, 2022, at 4:30 PM, Sean Whitton wrote:
> I believe that this request is invalid, for two reasons:
>
> - the specific things you ask for are all or mostly things that we think
>   are currently up to the Release Team, and the TC cannot override
>   delegates

I'm surprised to hear you say that, given that, in the past, the TC
has required bugs of various severities to be filed, and has required
maintainers not to alter bug severities.  Almost all of what I'm
asking for would follow "by operation of Policy", as it were, from the
requested s:critical bugs on usrmerge and usr-is-merged; I only
spelled them out for explicitness's sake.  And I didn't file the bugs
myself because they would certainly be rejected by the maintainers,
and then I'd have to escalate _that_ to you, so I'm trying to save time
by skipping that step.

> - you might be lacking the full context of TC-involving discussions over
>   the past few months, but so far as I can see, you are asking for us to
>   undo a decision that we only just made, which doesn't make sense.

As far as _I_ am aware, I'm acting on this bit of the "more specific
advice re #978636", issued last year:

# If a suitable transition mechanism is not available by the time the
# Debian 12 freeze is reached, the Technical Committee will rescind our
# advice in #978636 and modify our advice in this resolution to reflect
# the situation that has been reached. We hope that this will not be
# necessary.

In my opinion, a "suitable transition mechanism" _must_ include a fix
for the dpkg bugs, and it is almost certain at this point that the
dpkg bugs will _not_ be fixed in time for the freeze, hence it is
appropriate at this point for the TC to "rescind our advice in #978636
and modify our advice in this resolution", along the lines I requested.

If there has been substantive discussion or progress on the dpkg bugs
"over the past few months" I have not seen it either on -ctte or on
-devel.  I would appreciate a concrete summary of what has happened so
far and what is planned to happen.

zw

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

[Zack Weinberg]

Package: tech-ctte
Severity: normal
X-Debbugs-Cc: z...@owlfolio.org

I formally request that the Technical Committee call a halt to the
merged-/usr transition until such time as all of the bugs in dpkg that
can, on a merged-/usr system, cause damage to the contents of the
filesystem (e.g. packaged files being silently deleted on upgrade)
have been fixed to the satisfaction of the dpkg maintainers.

## Background

It has been known for some time that dpkg has bugs which prevent it
from correctly handling merged-/usr systems.  #858331/#848622 is the
only such bug (that I can find) that has actually been recorded in the
BTS, and it *appears* to be a relatively harmless problem, affecting
only dpkg-query output.

However, Simon Richter  showed in
https://lists.debian.org/debian-devel/2021/08/msg00326.html that the
bad dpkg-query output is only the most obvious symptom of a much more
serious problem, and that, under conditions that will plausibly occur
in the archive after the release of bookworm (assuming all continues
as presently planned) upgrading packages on a merged-/usr system can
cause packaged files to disappear from the filesystem.  The files most
likely to be affected are the files that are currently packaged in
/bin, /sbin, and /lib, including, just to mention a few, /bin/bash,
/bin/systemd, and /lib/$ARCH/libc.so.6.  Thus, the dpkg bugs can
render systems unbootable on upgrade, and should be considered
critical severity.

(N.B. Simon’s message is the only thing I can find that gives
step-by-step instructions to reproduce a problem that could plausibly
cause catastrophic filesystem damage during package upgrades, but the
scenario it describes should _not_ be considered the only problem that
needs to be fixed urgently.  Several other equally dire scenarios
are listed in https://wiki.debian.org/Teams/Dpkg/MergedUsr under the
“merged-/usr-via-aliased-dirs” subheading, albeit only tersely.)

Despite the severity of the dpkg bugs having been known since
_at least_ August of 2021, the people working on the merged-/usr
transition have made almost no effort to fix them.  A patch exists
(https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=858331;filename=file_move_moratorium.patch;msg=46)
that at least partially addresses the problem, but only one desultory
attempt was made to get it merged.

The people working on the merged-/usr transition have repeatedly
claimed that the several years of experience Debian now has with
systems that were _originally installed_ with merged /usr, and the
somewhat longer baseline for Ubuntu doing the same thing, indicates
the dpkg bugs are not a problem in practice.  That claim is incorrect.
The dpkg bugs are *latent* right now because, until the actual release
of bookworm, packages have to continue supporting non-merged systems.
Therefore they cannot move files from /{bin,sbin,lib} to
/usr/{bin,sbin,lib}, which is one of the conditions required to
trigger the most serious known issue (disappearance of packaged files).

I anticipate that if the merged-/usr transition proceeds as planned,
*all systems* that track either testing or unstable will be rendered
unbootable at least once in the bookworm+1 development cycle.  This
level of fallout is not acceptable, even in potentiality.  Since it
seems clear that the people working on the merged-/usr transition have
no intention of getting the bugs fixed, project-level action is
required.

## Specific actions requested

I ask the Committee to require all of the following, partially
reversing the decision taken in #978636, and overriding maintainers
as necessary:

 - The usrmerge and usr-is-merged packages are to be removed from
   testing immediately, and severity:critical (justification: “makes
   unrelated software break” and/or “breaks the entire system”) bugs
   are to be filed to prevent them from re-entering testing.

 - Those bugs may not be closed, nor may their severity be lowered,
   until *the dpkg maintainers agree* that dpkg can now fully support
   merged-/usr systems.

 - No package may declare a dependency on either usrmerge or
   usr-is-merged until the respective bug is closed.  Any packages in
   the archive that currently declare such a dependency must drop it
   immediately (or else be removed from testing as well).

 - No *other* mechanism which converts existing non-merged-/usr
   installations to merged-/usr, as a side-effect of package upgrade
   or installation, may enter testing, until at least the usr-is-merged
   bug is closed.  [I can imagine at least one possible resolution
   which would make it safe to use dpkg on a system where /usr has
   been merged ever since installation, but *not* on a system that was
   converted the way the usrmerge package does it.]

 - If merged-/usr conversion fails to reach testing before the release
   freeze for bookworm, then bookworm shall continue to support
   non-merged /usr for its lifetime, and similarly for future
   (post-bookworm) releases.

 - Optionally: 

Bug#1009277: gnome-weather: background service ImportError on login

[Zack Weinberg]

Package: gnome-weather
Version: 42.0-1
Severity: normal
X-Debbugs-Cc: za...@panix.com

Upon logging in I get these error messages in the user journal:

Apr 10 16:51:27 moxana org.gnome.Weath[5211]:
ImportError: Unable to load file from:
resource:///org/gnome/Weather/js/service/main.js
(The resource at “/org/gnome/Weather/js/service/main.js” does not exist)
Apr 10 16:51:27 moxana org.gnome.Weath[5211]:
Unhandled promise rejection. To suppress this warning, add an
error handler to your promise chain with .catch() or a try-catch
block around your await expression. Stack trace of the failed promise:
@/usr/share/org.gnome.Weather/org.gnome.Weather.BackgroundService:9:4

These errors repeat periodically for as long as I am logged in —
I presume something is trying to start the background service at
intervals.

A file named “main.js” appears to be packed inside
/usr/share/org.gnome.Weather/org.gnome.Weather.BackgroundService.src.gresource;
I do not know enough about gjs to understand why it’s not being found
there.

The primary “gnome-weather” application seems to work fine.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.16.0-6-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-weather depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  geoclue-2.0  2.6.0-1
ii  gir1.2-adw-1 1.1.0-1
ii  gir1.2-geoclue-2.0   2.6.0-1
ii  gir1.2-glib-2.0  1.72.0-1+b1
ii  gir1.2-gtk-4.0   4.6.2+ds-1
ii  gir1.2-gweather-4.0  4.0.0-2
ii  gjs  1.72.0-2
ii  libglib2.0-bin   2.72.0-1+b1

gnome-weather recommends no packages.

gnome-weather suggests no packages.

-- no debconf information

Bug#1005128: nmu: hugin_2021.0~beta1+dfsg-1

[Zack Weinberg]

On Mon, Feb 7, 2022, at 12:13 PM, Sebastian Ramacher wrote:
> This is currently not possible. See #1003547

Ah, thank you. I didn't find that bug because I was only looking at 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=hugin, not at 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=libvigraimpex, which is a 
library I have never heard of before. Sorry for the noise.

zw

Bug#1005128: nmu: hugin_2021.0~beta1+dfsg-1

[Zack Weinberg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: za...@panix.com

nmu hugin_2021.0~beta1+dfsg-1 . ANY . unstable . -m "Rebuild against libgsl27"

hugin is currently built against libgsl25 and therefore is
uninstallable in unstable.

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Zack Weinberg]

As an end user I wish to register an objection to any solution to this bug that 
makes it impossible for me to install a Debian system where, out of the box, 
"rename" in the default PATH is the Perl rename.  This is what my fingers 
expect, and what dozens of non-packaged scripts rely on.

(I say "the default PATH" and "out of the box" because I _can_ always put a 
symlink in $HOME/.local/bin or /usr/local/bin, regardless of what packages do, 
but that's an extra step that may not be tracked by configuration management 
and may not apply to all processes.)

I recognize that there are people coming to Debian from environments where 
there is precisely the opposite expectation, but I think backward compatibility 
with the environment Debian has provided for many years is, in this case, more 
important.

zw

Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

[Zack Weinberg]

As a Debian user I'm pleased to see the ctte taking proactive steps to
ensure that the merged-/usr transition will still allow smooth
upgrades from Debian 11 to 12 and 12 to 13.

As an upstream contributor to several pieces of software included in
Debian, and as someone with an interest in ensuring that software
developed on Linux is not *accidentally* unportable to other OSes
under the 'Unix' umbrella, I'd like to stick an oar in regarding:

On Wed, 15 Sep 2021 at 12:39:53 +0100, Simon McVittie wrote:
> On Wed, 15 Sep 2021 at 12:35:38 +0100, Simon McVittie wrote:
> > - §(Building packages): I almost wrote an extra paragraph about
> >   how this class of bugs becomes a non-issue when merged-/usr is
> >   the only supported layout - but actually it doesn't! If we
> >   consider building packages while having /usr/local/bin/sed to be
> >   a supported thing you can do, then we need to ensure that
> >   /usr/local/bin/sed doesn't get hard-coded into the resulting
> >   package, and the steps you take to make that happen are the same
> >   as the steps you take to fix this class of bugs.
>
> I think that class of bugs probably does become non-RC when the
> merged-/usr transition is complete, though.

After the transition is complete, /usr/local is not the only possible
source of problems.  For the various files with a "canonical" location
either in /usr or in /, either specified by some standard or by
convention, and regularly referred to by absolute pathname, all
software should continue to refer to those files by their "canonical"
name, so that it remains portable to Unixes that have not and may
never undergo a /usr merge.  The most common class of such files is
those used in #! directives: /bin/sh not /usr/bin/sh, /usr/bin/perl
not /bin/perl, etc.  I would ideally like this to be spelled out in
Policy, as an explicit list of files that MUST be referred to without
/usr, all others to be referred to with /usr.

[I agree that from Debian's perspective it makes sense for these bugs
to be RC until the transition is complete, and non-RC afterward.]

zw

Bug#991185: systemd: 'systemctl start anacron.service' from emergency mode kills emergency shell

[Zack Weinberg]

On Wed, Jul 21, 2021 at 9:46 AM Michael Biebl  wrote:
> When emergency mode is triggered (either by a boot failure or adding
> emergency to the kernel command line), emergency.target is started and
> emergency.service as a result of it.
>
> sysinit.target has "Conflicts=emergency.service emergency.target"
...

Thanks for the explanation.

> Would you be willing to file an upstream bug report?
> Maybe there is a way, to find a solution for this without causing a
> regression.

I see that you reopened https://github.com/systemd/systemd/issues/6509
so I commented there instead of filing a brand new report.

> For the time being, you might consider using single/rescue mode. It
> doesn't seem to have such a conflicts with sysinit.target.

I'll keep that in mind, thanks.  I suppose I can always *stop* the
handful of services started by rescue.target if they're interfering
with repairs, instead of avoiding starting them in the first place.

zw

Bug#991185: systemd: 'systemctl start anacron.service' from emergency mode kills emergency shell

[Zack Weinberg]

On Tue, Jul 20, 2021 at 8:00 AM Michael Biebl  wrote:
> Am 16.07.21 um 21:09 schrieb Zack Weinberg:
> > Package: systemd
> > Version: 247.3-5
> > Severity: important
> > X-Debbugs-Cc: za...@panix.com
> >
> > Running ‘systemctl start anacron.service’ from the emergency shell
> > causes the emergency shell and all processes running inside it to be
> > killed; you get the “You are in emergency mode” banner again and are
> > re-prompted for the root password.
> >
> > I don’t know if this is a general problem with starting services from
> > emergency mode, or if it’s somehow specific to anacron.
>
> Can you provide a full journal -alb log after this has happened?

I don't use persistent journals so I will need to reproduce the
problem again, please stay tuned.

> Would be good to know, why you ended up in emergency mode.

I booted directly into emergency mode for low-level maintenance.

zw

Bug#991190: dpkg-fsys-usrunmess: block service activation with policy-rc.d?

[Zack Weinberg]

On Sat, Jul 17, 2021 at 12:51 PM Guillem Jover  wrote:
> On Fri, 2021-07-16 at 15:23:01 -0400, Zack Weinberg wrote:
> > As a stopgap safety measure, I suggest that dpkg-fsys-usrunmess should
> > use policy-rc.d to block all service activation while it’s running.
>
> Hmm, right, that's not nice, sorry for the trouble. Hmm on one hand I
> guess installing a policy-rc.d would make this safer, on the other, it
> might end up not restarting services that will end up possibly using
> old inodes or pathname references, which might affect service monitoring
> for example, so I'm not sure what's worse.

You would know better than me -- I mostly use Debian as a workstation
environment, I have very little experience with weird server issues.

> But then I think the better option is to move the package
> configuration at the end once everything has been unmessed and the
> filesystem has been fully cleaned up.

That seems like a good change regardless.  If there are any packages
whose postinsts somehow depend on the presence or absence of files
that move between / and /usr in this process, they're more likely to
do the Right Thing after the moves are completely done.

Thanks for the quick reply.

zw

Bug#991192: dpkg-fsys-usrunmess: should be restartable

[Zack Weinberg]

Package: dpkg
Version: 1.20.9
Severity: wishlist
File: /usr/sbin/dpkg-fsys-usrunmess
X-Debbugs-Cc: za...@panix.com

I tried to run dpkg-fsys-usrunmess from systemd’s emergency mode,
thinking that this would be safer, since nothing else would be
running.  This tickled a bug in systemd (see #991185) and got
dpkg-fsys-usrunmess killed in the middle of its run—specifically,
during the ‘dpkg --pending --configure’ operation.  As you can
probably imagine, this is a really bad time for the process to be
interrupted.  I have a *lot* of experience cleaning up after breakage
in unstable and it still took me five hours this time.

In another bug, I suggested a stopgap measure for the specific thing
that went wrong with dpkg-fsys-usrunmess this time, but a more
thorough fix would be to make dpkg-fsys-usrunmess restartable.  Each
phase of the operation could be made idempotent on a file-by-file
basis simply by ignoring failures due to the rename or whatever
already having happened, and in between phases it could checkpoint
itself in a file in the shadow directory.

If I get time this weekend I’ll try to come up with a patch.


-- Package-specific info:

-- System Information:
Debian Release: 11.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/32 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-13
ii  liblzma5 5.2.5-2
ii  libselinux1  3.1-3
ii  tar  1.34+dfsg-1
ii  zlib1g   1:1.2.11.dfsg-2

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.2.4
pn  debsig-verify  

-- no debconf information

Bug#991190: dpkg-fsys-usrunmess: block service activation with policy-rc.d?

[Zack Weinberg]

Package: dpkg
Version: 1.20.9
Severity: normal
File: /usr/sbin/dpkg-fsys-usrunmess
X-Debbugs-Cc: za...@panix.com

I tried to run dpkg-fsys-usrunmess from systemd’s emergency mode,
thinking that this would be safer, since nothing else would be
running.  This tickled a bug in systemd (see #991185) and got
dpkg-fsys-usrunmess killed in the middle of its run—specifically,
during the ‘dpkg --pending --configure’ operation.  As you can
probably imagine, this is a really bad time for the process to be
interrupted.

As a stopgap safety measure, I suggest that dpkg-fsys-usrunmess should
use policy-rc.d to block all service activation while it’s running.

-- Package-specific info:

-- System Information:
Debian Release: 11.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/32 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-13
ii  liblzma5 5.2.5-2
ii  libselinux1  3.1-3
ii  tar  1.34+dfsg-1
ii  zlib1g   1:1.2.11.dfsg-2

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.2.4
pn  debsig-verify  

-- no debconf information

Bug#989808: fonts-linuxlibertine: Newer Libertine fonts available from CTAN

[Zack Weinberg]

Package: fonts-linuxlibertine
Version: 5.3.0-6
Severity: important
X-Debbugs-Cc: za...@panix.com, debian-tex-ma...@lists.debian.org

The Libertine font project ceased to make new releases circa 2012
(you will probably already have noticed that the debian/watch file is
pinging a location that no longer exists).  The TeX Live people have
taken over maintenance; the version of these fonts on CTAN
(https://www.ctan.org/pkg/libertine/) is still labeled “5.3.0” but has
received significant changes relative to what’s in Debian right now.
These changes are particularly important for use in LuaLaTeX
documents; without them, every document that uses these fonts,
rendered with LuaLaTex, will spew warnings (listed below).  I _think_
these warnings are harmless unless you want to use certain fancy
typographic features, but I’m not sure, and the problems are
apparently significant enough that libertine.sty contains special code
to force use of TeX Live’s version of the fonts.  That special code
is, however, ineffective on Debian because the font files in
/usr/share/texlive/texmf-dist/fonts/opentype/public/libertine are just
symlinks to the files provided by the fonts-linuxlibertine package.
(This is why I’ve marked the bug as severity important.  I’m also
cc:ing the TeX maintainers.)

Please update the fonts in this package to the versions found on CTAN.
It would be reasonable to consider https://www.ctan.org/pkg/libertine
the new upstream, IMHO.

-- Reproduce warnings by running lualatex on this file:
\documentclass{article}
\usepackage{libertine}
\begin{document}
x
\end{document}

-- Warnings:
Package fontspec Warning: OpenType feature 'Numbers=Uppercase' (lnum) not
(fontspec)available for font 'LinBiolinum_RB' with script
(fontspec)'CustomDefault' and language 'Default'.
Package fontspec Warning: OpenType feature 'Numbers=Uppercase' (lnum) not
(fontspec)available for font 'LinBiolinum_RB' with script
(fontspec)'CustomDefault' and language 'Default'.
Package fontspec Warning: OpenType feature 'Numbers= Monospaced, Lining'
(fontspec)(tnum) not available for font 'LinLibertine_RZI'
(fontspec)with script 'CustomDefault' and language 'Default'.
Package fontspec Warning: OpenType feature 'Numbers= Monospaced, Lining'
(fontspec)(tnum) not available for font 'LinLibertine_RZI'
(fontspec)with script 'CustomDefault' and language 'Default'.
Package fontspec Warning: OpenType feature 'Numbers=Uppercase' (lnum) not
(fontspec)available for font 'LinBiolinum_RB' with script
(fontspec)'CustomDefault' and language 'Default'.
Package fontspec Warning: OpenType feature 'Numbers=Uppercase' (lnum) not
(fontspec)available for font 'LinBiolinum_RB' with script
(fontspec)'CustomDefault' and language 'Default'.

-- Package-specific info:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version   Architecture Description
+++-==-=--=
ii  fontconfig 2.13.1-4.2amd64generic font configuration 
library - support binaries
ii  libfreetype6:amd64 2.10.4+dfsg-1 amd64FreeType 2 font engine, 
shared library files
ii  libxft2:amd64  2.3.2-2   amd64FreeType-based font drawing 
library for X

-- System Information:
Debian Release: 11.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-7-amd64 (SMP w/32 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#985372: [hel...@subdivi.de: Bug#985372: libxcrypt FTCBFS: glibc version detection inspects build architecture libc]

[Zack Weinberg]

Merged as 86d1e4e3815fa6c47613bda86820ee50e41ebd11, thank you for the
patch.  It's good to know someone is testing cross compilation.

zw

Bug#982924: what-is-python: The python-is-python3 and python-dev-is-python3 packages should not exist

[Zack Weinberg]

On Tue, Mar 2, 2021 at 4:30 AM Matthias Klose  wrote:
> On 2/16/21 5:34 PM, Zack Weinberg wrote:
> > Unpackaged Python-2-only software
> > will continue to exist indefinitely—I am *certain* that I will still
> > need a Python 2 interpreter ten years from now, and I fully expect my
> > grandchildren will occasionally trip over Python-2-only software even
> > a hundred years from now.
>
> Please also consider the burden on other grandparents having to explain their
> grandchildren that they have to type "python3" on Debian, when anybody else
> running Python on a different platform or running Python on other Linux
> distributions is used to type "python" ;)

I sincerely hope that the organizations shipping Python 3 as "python"
will come to their senses in the near future and stop doing so, so
everyone will in fact be used to typing "python3".

> I don't think there's a good solution for everybody.  I still think it's 
> better
> to provide an explicit choice in a package, instead of following instructions
> from the web to manage the "python" symlink using update-alternatives.

That's all well and good, but I do not think the choice represented by
"python-is-python3" should be offered as an option.

The change I am asking for is the removal of this package from Debian,
and I think it is _especially_ important that this package not be
included in bullseye (as this will be the first release without Python
2, AIUI).

> I'm going to propose an addition to the Debian Python Policy on the
> debian-python ML:
[...]

I like this except for the part that implies "python-is-python3" will
be an option.

zw

Bug#982924: what-is-python: The python-is-python3 and python-dev-is-python3 packages should not exist

[Zack Weinberg]

On Wed, Feb 17, 2021 at 3:17 PM Dimitri John Ledkov
 wrote:
> In Bullseye release file:/usr/bin/python is not reserved, but
> intentionally unused.

That is not good enough.  It needs to be reserved.

> In Bullseye release neither deb:python2 nor deb:python3 packages own
> /usr/bin/python.

Yes, I know.  That's fine as long as there is not, **and never will
be**, any package within Debian that creates /usr/bin/python as
anything other than a link to python2.  The existence of the
python-is-python3 package breaks this constraint.

> No packages in Bullseye may depend, or build-depend on neither
> deb:python, nor deb:python-is-python* packages.

That is not good enough.  The existence of the python-is-python3
package means that there can exist Debian installations in which
/usr/bin/python executes python3, breaking **unpackaged** software.
Hence the bug report.

(A sysadmin could of course `ln -s python3 /usr/bin/python`
themselves, but then that would be their error, not a bug in Debian.)

> Thus it is a leaf package without any dependencies. By definition not
> impacting any unrelated software.

I am concerned with this package's effect on **unpackaged** software
written by end-users and present on existing Debian systems.  I hope
you will understand that "unrelated software" does not just mean
software within Debian.

zw

Bug#982925: libgtk: print dialog lists autodetected printer twice

[Zack Weinberg]

Package: libgtk-3-0
Version: 3.24.24-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: za...@panix.com

I have only one printer, a network-attached Brother HL model.  CUPS
autodetects it somehow and creates a queue for it:

$ lpstat -e
Brother_HL_L2350DW_series

This queue shows up twice in the GTK print dialog box, with two
slightly different names (see attached screenshot).

This is not merely a cosmetic problem: only one of the two queues
actually works.  If I select the wrong one, the print job disappears
into the aether.

According to https://github.com/apple/cups/issues/5017 it is probably
the print dialog box’s responsibility to determine that a single
queue has been reported twice (e.g. by cupsEnumDests()) and merge the
information from both reports.


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-3-amd64 (SMP w/32 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libgtk-3-0:amd64 depends on:
ii  adwaita-icon-theme   3.38.0-1
ii  hicolor-icon-theme   0.17-2
ii  libatk-bridge2.0-0   2.38.0-1
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-9
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libcolord2   1.4.5-3
ii  libcups2 2.3.3op2-3
ii  libepoxy01.5.5-1
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libfribidi0  1.0.8-2
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.7-1
ii  libgtk-3-common  3.24.24-1
ii  libharfbuzz0b2.7.4-1
ii  libjson-glib-1.0-0   1.6.0-3
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpangoft2-1.0-01.46.2-3
ii  librest-0.7-00.8.1-1.1
ii  libwayland-client0   1.18.0-2~exp1.1
ii  libwayland-cursor0   1.18.0-2~exp1.1
ii  libwayland-egl1  1.18.0-2~exp1.1
ii  libx11-6 2:1.7.0-2
ii  libxcomposite1   1:0.4.5-1
ii  libxcursor1  1:1.2.0-2
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxi6   2:1.7.10-1
ii  libxinerama1 2:1.1.4-2
ii  libxkbcommon01.0.3-2
ii  libxrandr2   2:1.5.1-1
ii  shared-mime-info 2.0-1

Versions of packages libgtk-3-0:amd64 recommends:
ii  libgtk-3-bin  3.24.24-1

Versions of packages libgtk-3-0:amd64 suggests:
ii  gvfs 1.46.2-1
ii  librsvg2-common  2.50.3+dfsg-1

-- no debconf information

Bug#982924: what-is-python: The python-is-python3 and python-dev-is-python3 packages should not exist

[Zack Weinberg]

Source: what-is-python
Version: 3.8.6-3
Severity: critical
Justification: breaks unrelated software
X-Debbugs-Cc: za...@panix.com

Any system where the unqualified command names ‘python’ and/or
‘python-config’, or the well-known pathname /usr/bin/python, refer to
Python 3, is misconfigured.  These names need to be **permanently**
reserved for the legacy Python 2 interpreter, even after Debian ceases
to ship Python 2, or you risk breaking unpackaged software that has
not yet been ported to Python 3.  Unpackaged Python-2-only software
will continue to exist indefinitely—I am *certain* that I will still
need a Python 2 interpreter ten years from now, and I fully expect my
grandchildren will occasionally trip over Python-2-only software even
a hundred years from now.

(I am aware that PEP 394 explicitly licenses ‘python’ to run the
Python 3 interpreter.  PEP 394 is wrong.  It is my understanding that
the authors of PEP 394 felt they could not declare various
distributions (e.g. arch), that had already made ‘python’ run the v3
interpreter, to be buggy—but they should have.)

Please remove the python-is-python3 and python-dev-is-python3 packages
from Debian, and document in Debian’s Python policy that the
unqualified command names ‘python’ and ‘python-config’ and the
pathname /usr/bin/python are **permanently** reserved for the Python 2
interpreter.

I cannot overstate how much I mean **permanently**.  Forever.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-3-amd64 (SMP w/32 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#973432: additional

[Zack Weinberg]

All of the missing environment variables are present in the output of
`systemctl --user show-environment` run from a gnome-terminal window,
so the problem *might* just be that emacs.service is getting started
too early, in which case it could probably be fixed with some After=
directives, but I don't know what those should be.

zw

Bug#973432: emacs: When run as a systemd user service, emacs does not pick up environment settings from the desktop

[Zack Weinberg]

Package: emacs
Version: 1:27.1+1-2
Severity: normal
Tags: a11y upstream
X-Debbugs-Cc: za...@panix.com

I’ve been experimenting with running emacs as a systemd “user
service”, which is an upstream-supported configuration (see
/usr/lib/systemd/user/emacs.service).  I use GNOME for my desktop.

At about the same time that emacs 27.1 landed in unstable, I noticed
emacs start prompting me to unlock my ssh key via the mini-buffer
instead of via the desktop-wide password prompt.  It turns out that
this is because emacs is no longer aware of the desktop-wide ssh
agent, because it’s not picking up all the environment variable
settings that it ought to.  Specifically, these environment variables
are set for a random GUI application invoked from the GNOME launcher,
but not for emacs running as a user service:

DESKTOP_SESSION=gnome
GDMSESSION=gnome
GDM_LANG=en_US.UTF-8
GNOME_DESKTOP_SESSION_ID=this-is-deprecated
GNOME_SETUP_DISPLAY=:1
IM_CONFIG_PHASE=1
QT_IM_MODULE=ibus
SESSION_MANAGER=local/moxana:@/tmp/.ICE-unix/2195,unix/moxana:/tmp/.ICE-unix/2195
SSH_AGENT_LAUNCHER=openssh
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
WAYLAND_DISPLAY=wayland-0
XAUTHORITY=/run/user/1000/.mutter-Xwaylandauth.UOX3S0
XDG_CURRENT_DESKTOP=GNOME
XDG_MENU_PREFIX=gnome-
XDG_SESSION_CLASS=user
XDG_SESSION_DESKTOP=gnome
XDG_SESSION_TYPE=wayland
XMODIFIERS=@im=ibus

SSH_AUTH_SOCK is the one causing my immediate problem, but several
others look like they could also be trouble for Emacs users, such
as everything to do with input methods.

zw

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-1-amd64 (SMP w/32 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages emacs depends on:
ii  emacs-gtk  1:27.1+1-2

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information

Bug#972951: Fwd: Bug#972951: lintian should accept arbitrary files in /usr/share/gocode/**/testdata

[Zack Weinberg]

On Mon, Oct 26, 2020 at 11:33 AM Felix Lechner
 wrote:
> On Mon, Oct 26, 2020 at 7:48 AM Zack Weinberg  wrote:
> >
> > Go library packages bundle their own test suites, which may include
> > arbitrary data files;
>
> Which package are you working on, please? We cannot investigate your
> issue properly without a reference.

I was working on a local package for my job.  I'm not a DD or even a
DM nor have I had any contact with the Go team.

Any golang-*-dev package where the source package contains a
'testdata' directory somewhere should show this effect -- in
particular, if it contains .txt files that should trip
package-contains-documentation-outside-usr-share-doc. I did nothing
special to the result of running dh-make-golang on the upstream git
repo.

> By "Go library package" you probably mean Golang source modules. I
> just checked mine; they ship testing sources but no test data. Does it
> really make sense to ship either as part of the installation packages?

I could be wrong, but I am under the impression that the *_test.go
files and the testdata/** files are used by autopkgtest to run the
test suite against the installed version of the library.  If these
files *aren't* used for anything, probably this bug should be
reassigned to dh-golang and turned into a request to have it weed them
out during the binary phase.

zw

Bug#970393: RFP: shfmt -- Shell script formatter

[Zack Weinberg]

I would like to endorse this RFP; I was about to file one for it myself.

shfmt can be used as a more powerful alternative to `sh -n`, able to
detect use of bashisms in scripts that are supposed to be POSIX-only.
And it has an option to dump out its parse tree as JSON, which could
make life easier for programs that want to analyze shell scripts.

zw

Bug#972951: lintian should accept arbitrary files in /usr/share/gocode/**/testdata

[Zack Weinberg]

Package: lintian
Version: 2.99.0
Severity: wishlist

Go library packages bundle their own test suites, which may include
arbitrary data files; these files are always in a nested subdirectory
of /usr/share/gocode named “testdata”.  Lintian should ignore such
files.  I tripped over this as a false positive for
package-contains-documentation-outside-usr-share-doc, but it could
easily cause false positives in many other tags.

AIUI, these files can’t be moved somewhere else or it won’t be
possible to run the test suite against the installed library.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-1-amd64 (SMP w/32 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils2.35.1-2
ii  bzip2   1.0.8-4
ii  diffstat1.63-1
ii  dpkg1.20.5
ii  dpkg-dev1.20.5
ii  file1:5.38-5
ii  gettext 0.21-0.1
ii  gpg 2.2.20-1
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.36+b3
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b5
ii  libclone-perl   0.45-1
ii  libconfig-tiny-perl 2.24-1
ii  libcpanel-json-xs-perl  4.24-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1
ii  libdevel-size-perl  0.83-1+b1
ii  libdpkg-perl1.20.5
ii  libemail-address-xs-perl1.04-1+b2
ii  libfile-basedir-perl0.08-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1
ii  libhtml-html5-entities-perl 0.004-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004002-1
ii  liblist-compare-perl0.55-1
ii  liblist-moreutils-perl  0.416-1+b5
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.004000-1
ii  libmoox-aliases-perl0.001006-1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.114-1
ii  libperlio-gzip-perl 0.19-1+b6
ii  libproc-processtable-perl   0.59-2
ii  libsereal-decoder-perl  4.018+ds-1
ii  libsereal-encoder-perl  4.018+ds-1
ii  libtext-glob-perl   0.11-1
ii  libtext-levenshteinxs-perl  0.03-4+b7
ii  libtext-markdown-discount-perl  0.12-1
ii  libtext-xslate-perl 3.5.8-1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b2
ii  libtimedate-perl2.3300-1
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.010006-1
ii  libunicode-utf8-perl0.62-1+b1
ii  liburi-perl 5.05-1
ii  libxml-libxml-perl  2.0134+dfsg-2
ii  libyaml-libyaml-perl0.82+repack-1
ii  lzip1.21-8
ii  lzop1.04-1
ii  man-db  2.9.3-2
ii  patchutils  0.4.2-1
ii  perl [libdigest-sha-perl]   5.30.3-4
ii  t1utils 1.41-4
ii  unzip   6.0-25
ii  xz-utils5.2.4-1+b1

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.59-1

-- no debconf information

Bug#972871: git-el: .el files not installed / byte-compiled

[Zack Weinberg]

Package: git-el
Version: 1:2.28.0-1
Severity: grave
Justification: renders package unusable

While updating my emacs configuration for 27.1 (now in unstable)
I noticed that /etc/emacs/site-start.d/50git-core.el prints

git removed but not purged, skipping setup

and does not autoload either git.el or git-blame.el.  This appears to
be because /usr/lib/emacsen-common/packages/install/git does nothing
when $FLAVOR is “emacs”:

| # The emacs startup file looks for these files in
| # /usr/share/${debian-emacs-flavor}/site-lisp/git.
| # Installing to the generic /usr/share/emacs/site-list/git would be
| # pointless.
| [ "$FLAVOR" != emacs ] || exit 0

This has been incorrect for quite some time - I’m not sure how long
ago it was that (symbol-name debian-emacs-flavor) was changed to
evaluate to “emacs” for the ordinary packages of GNU Emacs, but
probably more than one release by now.

I think a sufficient fix is to remove the above quoted lines from
/usr/lib/emacsen-common/packages/install/git.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-1-amd64 (SMP w/32 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages git-el depends on:
ii  emacs1:27.1+1-2
ii  emacs-gtk [emacsen]  1:27.1+1-2
ii  git  1:2.28.0-1

Versions of packages git-el recommends:
ii  elpa-magit  2.99.0.git0957.ge8c7bd03-1

git-el suggests no packages.

-- no debconf information

Bug#934738: Experimental gettext 0.21 packages available

[Zack Weinberg]

Work I'm doing on Autoconf is now also blocked by the out-of-date
gettext in Debian, for reasons too tedious to get into, so I've
prepared experimental packages of gettext 0.21.  Get them from
https://research.owlfolio.org/scratchpad/debian -- this URL should
work as an apt source line, but beware that experimental packages of
the recent upstream beta of autoconf are also present.

I addressed a number of outstanding bugs and lintian complaints while
I was at it (the full changelog is at the bottom of this message, for
your interest); most importantly, I removed the dependency on libcroco
(bug #967028).  I did *not* change the set of binary packages at all,
because it wasn't clear to me what changes should be made.  Nor did I
revise the copyright file beyond updating the copyright years.  (I did
run scan-copyrights, the result of which is in
debian/copyright.dep5.raw, but it would clearly need a great deal of
manual revision and I don't have time for that any more than Santiago
does.  I've already spent two full days on this.)

I hope this is useful to at least some of you.  I don't plan to do any
further work on gettext myself, but please feel free to take what I
have done and build on it.

zw

gettext (0.21-0.1) experimental; urgency=medium

  * Non-maintainer upload to experimental.
  * New upstream version 0.21 released July 2020.
- xgettext can detect ‘(eval_)gettext -e’ in shell scripts. Closes: #507091.
-  compiles cleanly as C++. Closes: #547798.
- The unpacked usr/share/gettext/intl is no longer installed.
  If you were using these files, find them in
  /usr/share/gettext/archive.dir.tar.xz, which is part of the
  autopoint package.
- New upstream signing key added to signing-key.asc:
  "Bruno Haible (Open Source Development) "
  9001 B85A F9E1 B83D F1BD  A942 F5BE 8B26 7C6A 406D

  * Patches that are no longer necessary:
- 01-do-not-use-java-in-urlget.patch: Replaced with logic in debian/rules.
- 02-msgfmt-remove-pot-creation-date.patch: Merged upstream.
- 03-avoid-extraneous-nul-bytes.patch: Merged upstream.
- 04-fix-msgunfmt-heap-corruption.patch: Merged upstream.
- 05-fix-crash-xgettext-with-its.patch: Merged upstream.
- 06-java9-support.patch: Merged upstream.
- 07-java11-support.patch: Merged upstream.
- 08-java-future-support.patch: Merged upstream.
- 09-fix-crash-with-po-file-input.patch: Merged upstream.

  * New patches:
- NF-use-system-help2man.patch: Use system help2man instead of
  embedded help2man. Closes: #949338.
- NF-library-dependencies.patch: Link all libraries and
  executables against all of their dependencies, correctly.
  (Latent upstream bug, exposed by hardening.)
- NF-disable-libtextstyle.patch: Do not build libtextstyle.
  We never packaged it, and it depends on libcroco, which is
  unmaintained and has known security bugs.  Use the Gnulib
  libtextstyle-dummy module (already included in the upstream
  sources) to satisfy various programs’ use of libtextstyle.
  Note that this means those programs’ --color options
  silently do nothing. Closes: #967028.

  * Debhelper compat level 13 (current recommended).
- Switch to dh sequencing.
- Switch to Build-Depends: debhelper-compat.
- Switch to declarative package contents, using dh_install etc.
  dh-exec is needed for build profile filtering in a few places.
  (The old scripting is preserved in debian/rules.old.)
- Manual ldconfig triggers are no longer necessary.
- The HTML documentation and examples are now installed in
  /usr/share/doc/gettext instead of .../gettext-doc.

  * gettext-el is now created using dh_elpa, eliminating the need for
custom package scripts.

  * Standards-Version: 4.5.0.
- All lintian E-level diagnostics have been addressed, and
  many but not all of the W- and I-level diagnostics.
- I don’t *think* any specific changes were required besides the
  above, but I could have missed something.

Bug#969973: lintian: Please emit dh-exec-useless-usage only when none of the lines needs dh-exec

[Zack Weinberg]

Package: lintian
Version: 2.96.0
Followup-For: Bug #969973

I just tripped over this as well.  In my case I am specifically using
dh-exec only for filter-build-profiles, but lintian complains anyway:

#! /usr/bin/dh-exec --with-scripts=filter-build-profiles

usr/lib/${DEB_HOST_MULTIARCH}/libthingy.so.1
 usr/share/java/thingy.jar



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.8.0-2-amd64 (SMP w/32 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils2.35.1-1
ii  bzip2   1.0.8-4
ii  diffstat1.63-1
ii  dpkg1.20.5
ii  dpkg-dev1.20.5
ii  file1:5.38-5
ii  gettext 0.19.8.1-10
ii  gpg 2.2.20-1
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.36+b3
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b5
ii  libclone-perl   0.45-1
ii  libconfig-tiny-perl 2.24-1
ii  libcpanel-json-xs-perl  4.23-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1
ii  libdevel-size-perl  0.83-1+b1
ii  libdpkg-perl1.20.5
ii  libemail-address-xs-perl1.04-1+b2
ii  libfile-basedir-perl0.08-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1
ii  libhtml-html5-entities-perl 0.004-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004002-1
ii  liblist-compare-perl0.55-1
ii  liblist-moreutils-perl  0.416-1+b5
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.004000-1
ii  libmoox-aliases-perl0.001006-1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.114-1
ii  libperlio-gzip-perl 0.19-1+b6
ii  libproc-processtable-perl   0.59-2
ii  libsereal-decoder-perl  4.018+ds-1
ii  libsereal-encoder-perl  4.018+ds-1
ii  libtext-glob-perl   0.11-1
ii  libtext-levenshteinxs-perl  0.03-4+b7
ii  libtext-markdown-discount-perl  0.12-1
ii  libtext-xslate-perl 3.5.8-1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b2
ii  libtimedate-perl2.3300-1
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.010006-1
ii  libunicode-utf8-perl0.62-1+b1
ii  liburi-perl 1.76-2
ii  libxml-libxml-perl  2.0134+dfsg-2
ii  libyaml-libyaml-perl0.82+repack-1
ii  lzip1.21-8
ii  lzop1.04-1
ii  man-db  2.9.3-2
ii  patchutils  0.4.2-1
ii  perl [libdigest-sha-perl]   5.30.3-4
ii  t1utils 1.41-4
ii  unzip   6.0-25
ii  xz-utils5.2.4-1+b1

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.59-1

-- no debconf information

Bug#970920: lintian: spurious no-dh-sequencer with build profile conditionals

[Zack Weinberg]

Package: lintian
Version: 2.95.0
Severity: normal

lintian fails to recognize this debian/rules construct as use of the
dh sequencer:

%:
ifeq ($(DEB_BUILD_PROFILE),stage1)
dh $@ -Npackage-doc
else
dh $@
endif

This functionally equivalent construct *is* recognized:

DH_OPTIONS =
ifeq ($(DEB_BUILD_PROFILE),stage1)
DH_OPTIONS += -Npackage-doc
endif
%:
dh $@ $(DH_OPTIONS)

It would be nice if lintian would recognize both.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.8.0-2-amd64 (SMP w/32 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils2.35.1-1
ii  bzip2   1.0.8-4
ii  diffstat1.63-1
ii  dpkg1.20.5
ii  dpkg-dev1.20.5
ii  file1:5.38-5
ii  gettext 0.19.8.1-10
ii  gpg 2.2.20-1
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.36+b3
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b5
ii  libclone-perl   0.45-1
ii  libconfig-tiny-perl 2.24-1
ii  libcpanel-json-xs-perl  4.23-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1
ii  libdevel-size-perl  0.83-1+b1
ii  libdpkg-perl1.20.5
ii  libemail-address-xs-perl1.04-1+b2
ii  libfile-basedir-perl0.08-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1
ii  libhtml-html5-entities-perl 0.004-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004002-1
ii  liblist-compare-perl0.55-1
ii  liblist-moreutils-perl  0.416-1+b5
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.004000-1
ii  libmoox-aliases-perl0.001006-1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.114-1
ii  libperlio-gzip-perl 0.19-1+b6
ii  libproc-processtable-perl   0.59-2
ii  libsereal-decoder-perl  4.018+ds-1
ii  libsereal-encoder-perl  4.018+ds-1
ii  libtext-glob-perl   0.11-1
ii  libtext-levenshteinxs-perl  0.03-4+b7
ii  libtext-markdown-discount-perl  0.12-1
ii  libtext-xslate-perl 3.5.8-1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b2
ii  libtimedate-perl2.3300-1
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.010006-1
ii  libunicode-utf8-perl0.62-1+b1
ii  liburi-perl 1.76-2
ii  libxml-libxml-perl  2.0134+dfsg-2
ii  libyaml-libyaml-perl0.82+repack-1
ii  lzip1.21-8
ii  lzop1.04-1
ii  man-db  2.9.3-2
ii  patchutils  0.4.2-1
ii  perl [libdigest-sha-perl]   5.30.3-4
ii  t1utils 1.41-4
ii  unzip   6.0-25
ii  xz-utils5.2.4-1+b1

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.59-1

-- no debconf information

Bug#961875: r-cran-dplyr: please package version 1.0.0

[Zack Weinberg]

Package: r-cran-dplyr
Version: 0.8.5-1+b1
Severity: normal

Per https://cran.r-project.org/web/packages/dplyr/index.html the current
version of dplyr is 1.0.0; the most recent packaged version is 0.8.5.
Version 1.0.0 adds some valuable new features such as the ability to
create multiple new columns at once in mutate() and summarise().
Please package this version.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-1-amd64 (SMP w/32 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages r-cran-dplyr depends on:
ii  libc62.30-8
ii  libgcc-s110.1.0-2
ii  libstdc++6   10.1.0-2
ii  r-base-core [r-api-4.0]  4.0.0-3
ii  r-cran-assertthat0.2.1-2
ii  r-cran-bh1.66.0-1
ii  r-cran-ellipsis  0.3.1-1
ii  r-cran-glue  1.4.1-1
ii  r-cran-magrittr  1.5-6
ii  r-cran-pkgconfig 2.0.3-2
ii  r-cran-plogr 0.2.0-3
ii  r-cran-r62.4.1-2
ii  r-cran-rcpp  1.0.4.6-1+b1
ii  r-cran-rlang 0.4.6-1+b1
ii  r-cran-tibble3.0.1-1+b1
ii  r-cran-tidyselect1.1.0+dfsg-1

Versions of packages r-cran-dplyr recommends:
ii  r-cran-bit64   0.9-7-3+b1
ii  r-cran-data.table  1.12.8+dfsg-1+b1
ii  r-cran-hms 0.5.3-2
ii  r-cran-mass7.3-51.6-1+b1
ii  r-cran-rsqlite 2.2.0-1+b1
ii  r-cran-testthat2.3.2-2+b1
ii  r-cran-withr   2.2.0-2

Versions of packages r-cran-dplyr suggests:
ii  r-cran-broom0.5.6+dfsg-2
ii  r-cran-callr3.4.3-2
ii  r-cran-covr 3.5.0+dfsg-1+b1
ii  r-cran-crayon   1.3.4-5
ii  r-cran-dbi  1.1.0-3
ii  r-cran-dbplyr   1.4.3-2
ii  r-cran-ggplot2  3.3.0+dfsg-2
ii  r-cran-knitr1.28+dfsg-2
ii  r-cran-lubridate1.7.8-1+b1
ii  r-cran-mgcv 1.8-31-1+b1
ii  r-cran-purrr0.3.4-1+b1
ii  r-cran-readr1.3.1-1+b2
ii  r-cran-rmarkdown2.1+dfsg-4
ii  r-cran-rmysql   0.10.20-1+b1
ii  r-cran-rpostgresql  0.6-2+dfsg-2+b1

-- no debconf information

Bug#941991: gnome-shell: crashes on startup (Wayland only) with "JS ERROR: TypeError: actor.get_meta_window(...) is null"

[Zack Weinberg]

On Sun, Apr 12, 2020 at 7:57 AM Simon McVittie  wrote:
> On Tue, 08 Oct 2019 at 13:59:12 -0400, Zack Weinberg wrote:
> > On my computer, after upgrading to gnome-shell 3.34, I consistently get a
> > gnome-shell catastrophic failure about 10 seconds after logging in, but only
> > when running under Wayland.
>
> Do you mean that you literally log in, wait for 10 seconds without doing
> anything, and the shell crashes; or is there something else you do that
> is or might be the trigger?

I literally log in, wait 10 seconds without doing anything, and the
shell crashes.

> What GPU(s) do you have? If you have an NVIDIA device, are you using the
> proprietary nvidia-graphics-drivers or the open source Mesa/Nouveau drivers?

01:00.0 VGA compatible controller: NVIDIA Corporation GK107 [GeForce GT 740]

Using the open source drivers.

> Does this still happen in newer versions?
> Do you have any GNOME Shell extensions enabled?

Unfortunately, the affected computer is my office workstation and the
building is closed to all personnel for the duration of the COVID-19
crisis.  If it is possible to determine the answers to these questions
somehow via ssh-ing into the box and typing commands, please tell me
what to do; otherwise I will not be able to answer them anytime soon.
Sorry.

zw

Bug#949980: libgl1-mesa-dri: SIGSEGV in rockchip_dri.so when running Gnome/GTK

[Zack Weinberg]

Package: libgl1-mesa-dri
Followup-For: Bug #949980

This bug is still present with the libgl1-mesa-dri in unstable
(currently 19.3.3-1), but upgrading the following set of packages
to the version in experimental (currently 20.0.0-1) fixes it for me:

libegl-mesa0
libgbm1
libgl1-mesa-dri
libglapi-mesa
libglx-mesa0
mesa-va-drivers
mesa-vdpau-drivers
mesa-vulkan-drivers


-- Package-specific info:
glxinfo:

glxinfo is not available (missing mesa-utils package).

/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

The lspci command was not found; not including PCI data.

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 0

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 5.5.0-1-pinebookpro-arm64 (abuild@obs-arm-9) (gcc version 9.2.1 
20200224 (Debian 9.2.1-30)) #1 SMP PREEMPT Sun Mar 1 05:19:55 UTC 2020

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 36000 Mar  4 15:44 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[12.158] 
X.Org X Server 1.20.7
X Protocol Version 11, Revision 0
[12.158] Build Operating System: Linux 4.19.0-6-arm64 aarch64 Debian
[12.158] Current Operating System: Linux torrey 5.5.0-1-pinebookpro-arm64 
#1 SMP PREEMPT Sun Mar 1 05:19:55 UTC 2020 aarch64
[12.158] Kernel command line: root=PARTLABEL=mmcblk0-RootFS 
console=ttyS2,150n8 console=tty0 ro quiet splash 
plymouth.ignore-serial-consoles maxcpus=4 coherent_pool=1M 
earlycon=uart8250,mmio32,0xff1a mem_sleep_default=s2idle
[12.158] Build Date: 05 February 2020  04:27:36PM
[12.158] xorg-server 2:1.20.7-3 (https://www.debian.org/support) 
[12.158] Current version of pixman: 0.36.0
[12.158]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[12.158] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[12.159] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Mar  4 14:02:25 
2020
[12.171] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[12.174] (==) No Layout section.  Using the first Screen section.
[12.175] (==) No screen section available. Using defaults.
[12.175] (**) |-->Screen "Default Screen Section" (0)
[12.175] (**) |   |-->Monitor ""
[12.176] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[12.176] (==) Automatically adding devices
[12.177] (==) Automatically enabling devices
[12.177] (==) Automatically adding GPU devices
[12.177] (==) Max clients allowed: 256, resource mask: 0x1f
[12.182] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[12.183]Entry deleted from font path.
[12.189] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[12.189] (==) ModulePath set to "/usr/lib/xorg/modules"
[12.189] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[12.189] (II) Loader magic: 0xbb81ce10
[12.189] (II) Module ABI versions:
[12.189]X.Org ANSI C Emulation: 0.4
[12.189]X.Org Video Driver: 24.1
[12.189]X.Org XInput driver : 24.1
[12.189]X.Org Server Extension : 10.0
[12.194] (++) using VT number 7

[12.194] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[12.199] (II) xfree86: Adding drm device (/dev/dri/card0)
[12.207] (II) xfree86: Adding drm device (/dev/dri/card1)
[12.207] (II) no primary bus or device found
[12.207]falling back to 
/sys/devices/platform/display-subsystem/drm/card0
[12.207] (II) LoadModule: "glx"
[12.211] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[12.257] (II) Module glx: vendor="X.Org Foundation"
[12.257]compiled for 1.20.7, module version = 1.0.0
[12.257]ABI class: X.Org Server Extension, version 10.0
[12.258] (==) Matched modesetting as autoconfigured driver 0
[12.258] (==) Matched fbdev as autoconfigured driver 1
[12.258] (==) Assigned the driver to the xf86ConfigLayout
[12.258] (II) LoadModule: "modesetting"
[12.259] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[12.264] (II) Module modesetting: vendor="X.Org 

Bug#941991: gnome-shell: crashes on startup (Wayland only) with "JS ERROR: TypeError: actor.get_meta_window(...) is null"

[Zack Weinberg]

Package: gnome-shell
Version: 3.34.0-2
Severity: grave
Justification: renders package unusable

On my computer, after upgrading to gnome-shell 3.34, I consistently get a
gnome-shell catastrophic failure about 10 seconds after logging in, but only
when running under Wayland.  This error appears in the logs:

gnome-shell[2608]: JS ERROR: TypeError: actor.get_meta_window(...) is null
  destroyWindowDone@resource:///org/gnome/shell/ui/windowManager.js:1773:26
  onStopped@resource:///org/gnome/shell/ui/windowManager.js:1742:34
  makeEaseCallback/<@resource:///org/gnome/shell/ui/environment.js:73:13
  easeActor/<@resource:///org/gnome/shell/ui/environment.js:126:60
gnome-shell[2608]: JS ERROR: TypeError: actor.get_meta_window(...) is null
  destroyWindowDone@resource:///org/gnome/shell/ui/windowManager.js:1773:26
  onStopped@resource:///org/gnome/shell/ui/windowManager.js:1742:34
  makeEaseCallback/<@resource:///org/gnome/shell/ui/environment.js:73:13
  easeActor/<@resource:///org/gnome/shell/ui/environment.js:126:60
gdm-wayland-session[2571]: Received signal:15->'Terminated'

I don't see anything else that is obviously related, but I could have
missed something.  Please let me know if you need more information.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.34.0-1
ii  evolution-data-server3.34.1-1
ii  gir1.2-accountsservice-1.0   0.6.45-2
ii  gir1.2-atspi-2.0 2.34.0-3
ii  gir1.2-freedesktop   1.62.0-2
ii  gir1.2-gcr-3 3.33.4-3
ii  gir1.2-gdesktopenums-3.0 3.34.0-2
ii  gir1.2-gdm-1.0   3.34.1-1
ii  gir1.2-geoclue-2.0   2.5.5-1
ii  gir1.2-glib-2.0  1.62.0-2
ii  gir1.2-gnomebluetooth-1.03.34.0-1
ii  gir1.2-gnomedesktop-3.0  3.34.0-3
ii  gir1.2-gtk-3.0   3.24.12-1
ii  gir1.2-gweather-3.0  3.28.3-2
ii  gir1.2-ibus-1.0  1.5.21-1
ii  gir1.2-mutter-5  3.34.0-4
ii  gir1.2-nm-1.01.20.4-2
ii  gir1.2-nma-1.0   1.8.22-2
ii  gir1.2-pango-1.0 1.42.4-7
ii  gir1.2-polkit-1.00.105-26
ii  gir1.2-rsvg-2.0  2.44.15-1
ii  gir1.2-soup-2.4  2.68.1-2
ii  gir1.2-upowerglib-1.00.99.11-1
ii  gjs  1.58.0-2
ii  gnome-backgrounds3.34.0-1
ii  gnome-settings-daemon3.34.0-3
ii  gnome-shell-common   3.34.0-2
ii  gsettings-desktop-schemas3.34.0-2
ii  libatk-bridge2.0-0   2.34.0-3
ii  libatk1.0-0  2.34.0-1
ii  libc62.29-2
ii  libcairo21.16.0-4
ii  libcroco30.6.13-1
ii  libecal-2.0-13.34.1-1
ii  libedataserver-1.2-243.34.1-1
ii  libgcr-base-3-1  3.33.4-3
ii  libgdk-pixbuf2.0-0   2.38.2+dfsg-1
ii  libgirepository-1.0-11.62.0-2
ii  libgjs0g 1.58.0-2
ii  libgles2 1.1.0-1+b1
ii  libglib2.0-0 2.62.1-1
ii  libglib2.0-bin   2.62.1-1
ii  libgnome-autoar-0-0  0.2.3-2
ii  libgstreamer1.0-01.16.1-1
ii  libgtk-3-0   3.24.12-1
ii  libical3 3.0.5-2
ii  libjson-glib-1.0-0   1.4.4-2
ii  libmutter-5-03.34.0-4
ii  libnm0   1.20.4-2
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libpolkit-agent-1-0  0.105-26
ii  libpolkit-gobject-1-00.105-26
ii  libpulse-mainloop-glib0  13.0-2
ii  libpulse013.0-2
ii  libsecret-1-00.19.1-1
ii  libsystemd0  

Bug#941990: displaycal-apply-profiles needs python-dbus

[Zack Weinberg]

Package: displaycal
Version: 3.8.7.1-1
Severity: normal

The displaycal package has no dependency on (python-)dbus, but
its script /usr/bin/displaycal-apply-profiles crashes on startup
if the dbus module is not available:

Traceback (most recent call last):
  File "/usr/bin/displaycal-apply-profiles", line 17, in 
main()
  File "/usr/lib/python2.7/dist-packages/DisplayCAL/profile_loader.py", line 
3375, in main
ProfileLoader()
  File "/usr/lib/python2.7/dist-packages/DisplayCAL/profile_loader.py", line 
1112, in __init__
self.apply_profiles_and_warn_on_error()
  File "/usr/lib/python2.7/dist-packages/DisplayCAL/profile_loader.py", line 
1834, in apply_profiles_and_warn_on_error
errors = self.apply_profiles(event, index)
  File "/usr/lib/python2.7/dist-packages/DisplayCAL/profile_loader.py", line 
1683, in apply_profiles
from worker import Worker, get_argyll_util
  File "/usr/lib/python2.7/dist-packages/DisplayCAL/worker.py", line 127, in 

import colord
  File "/usr/lib/python2.7/dist-packages/DisplayCAL/colord.py", line 27, in 

from util_dbus import DBusObject, DBusException, BUSTYPE_SYSTEM
  File "/usr/lib/python2.7/dist-packages/DisplayCAL/util_dbus.py", line 16, in 

import dbus
ImportError: No module named dbus

The package should add at least a Recommends for python-dbus and possibly
also python-gi.  After conversion to Python 3 as requested in #936404,
these dependencies should be changed to python3-{dbus,gi} respectively.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages displaycal depends on:
ii  argyll   2.0.1+repack-1
ii  libc62.29-2
ii  libjs-jquery 3.3.1~dfsg-3
ii  libx11-6 2:1.6.8-1
ii  libxinerama1 2:1.1.4-2
ii  libxrandr2   2:1.5.1-1
ii  libxxf86vm1  1:1.1.4-1+b2
ii  python   2.7.16-1
ii  python-numpy 1:1.16.5-1
ii  python-wxgtk3.0  3.0.2.0+dfsg-8

Versions of packages displaycal recommends:
ii  colord1.4.4-1
ii  gir1.2-colordgtk-1.0  0.1.26-2

displaycal suggests no packages.

-- no debconf information

Bug#930380: calligraflow: crash on startup (when run under gnome?)

[Zack Weinberg]

Package: calligraflow
Version: 1:2.9.11+dfsg-4+b1
Severity: important

calligraflow crashes on startup - possibly only when run under a GNOME 
desktop session and/or with KDE persistent state not properly initialized,
since a stack trace fingers the KDE most-recently-used-files implementation.

Stack trace collected with gdb:

QObject::connect: Cannot connect KoDocumentInfo::infoUpdated(const QString &, 
const QString &) to (null)::documentInformationUpdated(const QString &, const 
QString &)

Program received signal SIGSEGV, Segmentation fault.
0x7689f73c in QString::operator=(QString const&) ()
   from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
(gdb) bt
#0  0x7689f73c in QString::operator=(QString const&) ()
at /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#1  0x74c78f88 in  () at /usr/lib/libkdeui.so.5
#2  0x74c68d84 in KXMLGUIClient::findMostRecentXMLFile(QStringList 
const&, QString&) () at /usr/lib/libkdeui.so.5
#3  0x779548ad in KoMainWindow::KoMainWindow(QByteArray const&, 
KComponentData const&) () at /usr/lib/libkomain.so.14
#4  0x7fffec52a535 in FlowPart::createMainWindow() ()
at /usr/lib/libflowprivate.so.14
#5  0x7792b39f in KoApplication::start() () at /usr/lib/libkomain.so.14
#6  0x77dcc88f in kdemain ()
at /usr/lib/kde4/libkdeinit/libkdeinit4_calligraflow.so
#7  0x77c0309b in __libc_start_main (main=
0x4780, argc=1, argv=0x7fffddc8, init=, 
fini=, rtld_fini=, stack_end=0x7fffddb8)
at ../csu/libc-start.c:308
#8  0x47ba in _start ()



-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages calligraflow depends on:
ii  calligra-libs  1:2.9.11+dfsg-4+b1
ii  calligraflow-data  1:2.9.11+dfsg-4
ii  kde-runtime4:17.08.3-2.1
ii  libc6  2.28-10
ii  libgcc11:8.3.0-7
ii  libkdecore54:4.14.38-3
ii  libkdeui5  4:4.14.38-3
ii  libodfgen-0.1-10.1.7-1
ii  libqtcore4 4:4.8.7+dfsg-18
ii  libqtgui4  4:4.8.7+dfsg-18
ii  librevenge-0.0-0   0.0.4-6
ii  libstdc++6 8.3.0-7
ii  libvisio-0.1-1 0.1.6-1+b2
ii  libwpg-0.3-3   0.3.3-1

calligraflow recommends no packages.

calligraflow suggests no packages.

-- no debconf information

Bug#925149: emacs-gtk: next-error painfully slow on glibc build logs

[Zack Weinberg]

Package: emacs-gtk
Version: 1:26.1+1-3.2
Severity: normal
File: /usr/bin/emacs-gtk

In Emacs 26, compilation-mode has become painfully slow to scan for
the next error, when applied to the build logs typically produced by
GNU libc.  As I am one of GNU libc's upstream maintainers, this is a
pretty inconvenient regression for me.

I'm attaching a build log that will demonstrate the problem.  It is
1.1MB when uncompressed.  On my computer, when I load the file into
a buffer and then type C-x `, Emacs 26 becomes unresponsive and consumes
100% CPU for two and a half minutes before moving point to a line near the
end of the file.  (C-g works, but then the buffer's idea of which lines
are errors is corrupted.)  In Emacs 25 this operation was instantaneous.

Besides next-error, several other operations cause the same effect, such
as end-of-buffer or an isearch that has to scan a lot of the buffer.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages emacs-gtk depends on:
ii  emacs-bin-common   1:26.1+1-3.2
ii  emacs-common   1:26.1+1-3.2
ii  libacl12.2.53-4
ii  libasound2 1.1.8-1
ii  libatk1.0-02.30.0-2
ii  libc6  2.28-8
ii  libcairo-gobject2  1.16.0-4
ii  libcairo2  1.16.0-4
ii  libdbus-1-31.12.12-1
ii  libfontconfig1 2.13.1-2
ii  libfreetype6   2.9.1-3
ii  libgdk-pixbuf2.0-0 2.38.1+dfsg-1
ii  libgif75.1.4-3
ii  libglib2.0-0   2.58.3-1
ii  libgnutls303.6.6-3
ii  libgomp1   8.3.0-3
ii  libgpm21.20.7-5
ii  libgtk-3-0 3.24.5-1
ii  libice62:1.0.9-2
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  liblcms2-2 2.9-3
ii  libm17n-0  1.8.0-2
ii  libmagickcore-6.q16-6  8:6.9.10.23+dfsg-2
ii  libmagickwand-6.q16-6  8:6.9.10.23+dfsg-2
ii  libotf00.9.13-4
ii  libpango-1.0-0 1.42.4-6
ii  libpangocairo-1.0-01.42.4-6
ii  libpng16-161.6.36-5
ii  librsvg2-2 2.44.10-1
ii  libselinux12.8-1+b1
ii  libsm6 2:1.2.3-1
ii  libsystemd0241-2
ii  libtiff5   4.0.10-4
ii  libtinfo6  6.1+20181013-2
ii  libx11-6   2:1.6.7-1
ii  libx11-xcb12:1.6.7-1
ii  libxcb11.13.1-2
ii  libxext6   2:1.3.3-1+b2
ii  libxfixes3 1:5.0.3-1
ii  libxft22.3.2-2
ii  libxinerama1   2:1.1.4-2
ii  libxml22.9.4+dfsg1-7+b3
ii  libxpm41:3.5.12-1
ii  libxrandr2 2:1.5.1-1
ii  libxrender11:0.9.10-1
ii  zlib1g 1:1.2.11.dfsg-1

emacs-gtk recommends no packages.

Versions of packages emacs-gtk suggests:
pn  emacs-common-non-dfsg  

-- no debconf information


emacs-slow-compilation-mode.txt.xz
Description: application/xz

Bug#922106: /usr/bin/vim.tiny: flood of E319 errors on startup

[Zack Weinberg]

Package: vim-tiny
Version: 2:8.1.0875-1
Severity: normal
File: /usr/bin/vim.tiny

When /usr/bin/vim.tiny is invoked with no special options
(in particular, without -u NONE or -u NORC) it immediately spews
a flood of E319 error messages:

Error detected while processing /usr/share/vim/vim81/filetype.vim:
line   10:
E319: Sorry, the command is not available in this version: let 
did_load_filetypes = 1
line   13:
E319: Sorry, the command is not available in this version: let s:cpo_save = 
line   45:
E319: Sorry, the command is not available in this version: func! s:StarSetf(ft)
line   49:
E319: Sorry, the command is not available in this version: endfunc
line 2163:
E319: Sorry, the command is not available in this version: func! 
TestFiletypeFuncs(testlist)
line 2164:
E319: Sorry, the command is not available in this version:   let output = ''
line 2165:
E319: Sorry, the command is not available in this version:   for f in a:testlist
line 2166:
E319: Sorry, the command is not available in this version: try
line 2167:
E319: Sorry, the command is not available in this version:   exe f
line 2168:
E319: Sorry, the command is not available in this version: catch
line 2169:
E319: Sorry, the command is not available in this version:   let output = 
output . "\n" . f . ": " . v:exception
line 2170:
E319: Sorry, the command is not available in this version: endtry
line 2171:
E319: Sorry, the command is not available in this version:   endfor
line 2172:
E319: Sorry, the command is not available in this version:   return output
line 2173:
E319: Sorry, the command is not available in this version: endfunc
line 2176:
E319: Sorry, the command is not available in this version: let  = s:cpo_save
line 2177:
E319: Sorry, the command is not available in this version: unlet s:cpo_save
Error detected while processing /usr/share/vim/vim81/ftplugin.vim:
line9:
E319: Sorry, the command is not available in this version: let 
did_load_ftplugin = 1
line   14:
E319: Sorry, the command is not available in this version:   func! 
s:LoadFTPlugin()
line   20:
E319: Sorry, the command is not available in this version: let s = 
expand("")
line   34:
E319: Sorry, the command is not available in this version:   endfunc
Error detected while processing /usr/share/vim/vim81/indent.vim:
line9:
E319: Sorry, the command is not available in this version: let did_indent_on = 1
line   13:
E319: Sorry, the command is not available in this version:   func! 
s:LoadIndent()
line   18:
E319: Sorry, the command is not available in this version: let s = 
expand("")
line   30:
E319: Sorry, the command is not available in this version:   endfunc

I presume that the .tiny build of vim should not be loading these rc
files in the first place.

I have no personal .vimrc and the vim configuration files in /etc are
untouched from how the packages install them.

dpkg -l 'vim*' prints

ii  vim   2:8.1.0875-1 amd64Vi IMproved - enhanced vi editor
un  vim-addon-manager   (no description available)
un  vim-athena  (no description available)
ii  vim-common2:8.1.0875-1 all  Vi IMproved - Common files
un  vim-doc (no description available)
un  vim-gnome   (no description available)
un  vim-gtk (no description available)
un  vim-gtk3(no description available)
un  vim-nox (no description available)
ii  vim-runtime   2:8.1.0875-1 all  Vi IMproved - Runtime files
un  vim-scripts (no description available)
ii  vim-tiny  2:8.1.0875-1 amd64Vi IMproved - enhanced vi 
editor - compact version


-- Package-specific info:

--- real paths of main Vim binaries ---
/usr/bin/vi is /usr/bin/vim.basic
/usr/bin/vim is /usr/bin/vim.basic

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages vim-tiny depends on:
ii  libacl1  2.2.52-3+b1
ii  libc62.28-7
ii  libselinux1  2.8-1+b1
ii  libtinfo66.1+20181013-1
ii  vim-common   2:8.1.0875-1

vim-tiny recommends no packages.

Versions of packages vim-tiny suggests:
ii  indent  2.2.12-1

-- no debconf information

Bug#920376: lintian: Add a check for binaries using obsolete DES encryption

[Zack Weinberg]

Package: lintian
Version: 2.5.123
Severity: wishlist
Tags: patch

The attached patch adds a Lintian check for binaries using the obsolete
DES encryption functions that were made inaccessible to newly linked
binaries in glibc 2.28.  See the patch's commit message for more detail.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils   2.31.1-11
ii  bzip2  1.0.6-9
ii  diffstat   1.62-1
ii  dpkg   1.19.4
ii  dpkg-dev   1.19.4
ii  file   1:5.35-2
ii  gettext0.19.8.1-9
ii  gpg2.2.12-1
ii  intltool-debian0.35.0+20060710.5
ii  libapt-pkg-perl0.1.34+b1
ii  libarchive-zip-perl1.64-1
ii  libcgi-pm-perl 4.40-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.41-1+b1
pn  libdigest-sha-perl 
ii  libdpkg-perl   1.19.4
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libio-async-perl   0.72-1
ii  libipc-run-perl20180523.0-1
ii  liblist-moreutils-perl 0.416-1+b4
ii  libparse-debianchangelog-perl  1.2.0-13
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.76-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.76+repack-1
ii  man-db 2.8.5-1
ii  patchutils 0.3.4-2
ii  perl   5.28.1-3
ii  t1utils1.41-3
ii  xz-utils   5.2.2-1.3

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libhtml-parser-perl3.72-3+b3
ii  libtext-template-perl  1.54-1

-- no debconf information
>From d79acb92725ef2ddbc2b33eba62a4e7b7f361a3d Mon Sep 17 00:00:00 2001
From: Zack Weinberg 
Date: Thu, 24 Jan 2019 15:40:26 -0500
Subject: [PATCH] Add a check for binaries using obsolete DES encryption.

libcrypt.so.1 (part of glibc) used to provide a set of functions that
allowed raw use of the DES block cipher.  Encryption with DES is now
inherently insecure (any use of single DES can be broken by brute
force) and therefore these functions were made inaccessible to newly
linked programs in glibc 2.28.

Any program in the archive that unconditionally uses one of these
functions will FTBFS with glibc 2.28.  Any program that conditionally
uses one of these functions may be falling back to an internal
implementation of DES and therefore have a security bug.

Therefore, I propose this new lintian check, which detects use of the
functions that were removed from libcrypt.so.1.  In sid it is arguably
redundant (since any program that would fail this check will FTBFS
anyway) but applying this check to the stable archive would detect
programs that were conditionally using these functions and need to be
audited for security bugs.
---
 checks/binaries.desc  | 45 
 checks/binaries.pm| 10 +++-
 data/binaries/obsolete-crypt-functions| 13 +
 t/tests/binaries-obsolete-des/desc|  7 +++
 t/tests/binaries-obsolete-des/orig/Makefile   | 51 +++
 t/tests/binaries-obsolete-des/orig/dummy.pod  | 12 +
 .../binaries-obsolete-des/orig/uses-encrypt.c | 30 +++
 .../orig/uses-encrypt_r.c | 33 
 .../binaries-obsolete-des/orig/uses-fcrypt.c  | 21 
 .../binaries-obsolete-des/orig/uses-setkey.c  | 45 
 .../orig/uses-setkey_r.c  | 48 +
 t/tests/binaries-obsolete-des/tags|  5 ++
 12 files changed, 319 insertions(+), 1 deletion(-)
 create mode 100644 data/binaries/obsolete-crypt-functions
 create mode 100644 t/tests/binaries-obsolete-des/desc
 create mode 100644 t/tests/binaries-obsolete-des/orig/Makefile
 create mode 100644 t/tests/binaries-obsolete-des/orig/dummy.pod
 create mode 100644 t/tests/binaries-obsolete-des/orig/uses-encrypt.c
 create mode 100644 t/tests/binaries-obsolete-des/orig/uses-encrypt_r.c
 create mode 100644 t/tests/binaries-obsolete-des/orig/uses-fcrypt.c
 create mode 100644 t/tests/binaries-obsolete-des/orig/uses-setkey.c
 create mode 100644 t/tests/binaries-obsolete-des/orig/uses-setkey_r.c
 create mode 100644 t/tests/binaries-obsolete-des/tags

diff --git a/che

Bug#920361: cairo-dock-core: uses DES encryption for password storage

[Zack Weinberg]

Package: cairo-dock-core
Version: 3.4.1-3
Severity: important
Tags: security upstream

While looking into something else I noticed that cairo-dock is using
single DES encryption (via the C library functions setkey() and encrypt())
to store passwords: see 
https://sources.debian.org/src/cairo-dock/3.4.1-3/src/gldit/cairo-dock-config.c/?hl=526#L487

This is insecure for several reasons, most importantly because DES itself can
be broken by brute force on modern hardware, and because it doesn't support
passwords longer than eight characters.  cairo_dock_{encrypt,decrypt}_string
need to be changed to use a modern cipher and operation mode designed for
storage of secrets on disk, and to support arbitrary-length passwords.

(Note, I do not use cairo-dock myself and do not have it installed.  I found
this problem by searching through the source code.)

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cairo-dock-core depends on:
ii  libatk1.0-0 2.30.0-2
ii  libc6   2.28-5
ii  libcairo-gobject2   1.16.0-2
ii  libcairo2   1.16.0-2
ii  libcurl3-gnutls 7.62.0-1
ii  libdbus-1-3 1.12.12-1
ii  libdbus-glib-1-20.110-3
ii  libfribidi0 1.0.5-3.1
ii  libgdk-pixbuf2.0-0  2.38.0+dfsg-7
ii  libgl1  1.1.0-1
ii  libgl1-mesa-glx 18.2.8-2
ii  libglib2.0-02.58.2-3
ii  libglu1-mesa [libglu1]  9.0.0-2.1
ii  libgtk-3-0  3.24.3-1
ii  libpango-1.0-0  1.42.4-6
ii  libpangocairo-1.0-0 1.42.4-6
ii  librsvg2-2  2.44.10-1
ii  libwayland-client0  1.16.0-1
ii  libx11-62:1.6.7-1
ii  libxcomposite1  1:0.4.4-2
ii  libxinerama12:1.1.4-1
ii  libxml2 2.9.4+dfsg1-7+b3
ii  libxrandr2  2:1.5.1-1
ii  libxrender1 1:0.9.10-1
ii  libxtst62:1.2.3-1

Versions of packages cairo-dock-core recommends:
pn  cairo-dock-plugins  
ii  curl7.62.0-1

Versions of packages cairo-dock-core suggests:
pn  empathy   
pn  f-spot
ii  gimp  2.10.8-2
ii  gnome-calculator  3.30.1-2
ii  inkscape  0.92.3-7+b1
pn  xcompmgr  

Bug#912909: dh-python: crashes when run under reprotest

[Zack Weinberg]

Package: dh-python
Version: 3.20180927
Severity: normal
Tags: patch

I tried to use reprotest on a Python module that is built using pybuild,
and it blew up deep inside the guts of dh_python2:

   dh_python2 -O--buildsystem=pybuild
I: dh_python2 fs:329: renaming _MeCab.so to _MeCab.x86_64-linux-gnu.so
Traceback (most recent call last):
  File "/usr/share/dh-python/dh_python2", line 545, in 
main()
  File "/usr/share/dh-python/dh_python2", line 430, in main
stats = Scanner(interpreter, package, private_dir, options).result
  File "/usr/share/dh-python/dhpython/fs.py", line 216, in __init__
ver = self.handle_ext(fpath)
  File "/usr/share/dh-python/dh_python2", line 57, in handle_ext
so_version = so2pyver(fpath)
  File "/usr/share/dh-python/dhpython/tools.py", line 137, in so2pyver
match = SHAREDLIB_RE.search(str(process.stdout.read(), encoding='utf-8'))
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa0 in position 60: 
invalid start byte
make: *** [debian/rules:7: binary] Error 1
dpkg-buildpackage: erreur: debian/rules binary subprocess returned exit status 2

Note the French 'erreur'.  reprotest appears to have selected a random but
non-UTF-8 locale before invoking dpkg-buildpackage.  This makes readelf -Wd
produce output that so2pyver cannot decode.

An appropriate fix would be for so2pyver to override the locale to C.UTF-8
when invoking readelf.  I will attach a patch that does this.  This seems
to be the only problem with using reprotest on dh-python packages.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (501, 'unstable'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'testing'), (101, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dh-python depends on:
ii  python33.6.7-1
ii  python3-distutils  3.7.1-1

dh-python recommends no packages.

Versions of packages dh-python suggests:
ii  dpkg-dev  1.19.2
ii  libdpkg-perl  1.19.2

-- no debconf information
--- dhpython/tools.py   2018-09-27 16:40:56.0 -0400
+++ dhpython/tools.py   2018-11-04 15:22:42.979069501 -0500
@@ -27,7 +27,7 @@
 from pickle import dumps
 from shutil import rmtree
 from os.path import exists, getsize, isdir, islink, join, split
-from subprocess import Popen, PIPE
+from subprocess import Popen, PIPE, check_output
 
 log = logging.getLogger('dhpython')
 EGGnPTH_RE = re.compile(r'(.*?)(-py\d\.\d(?:-[^.]*)?)?(\.egg-info|\.pth)$')
@@ -131,10 +131,13 @@ def so2pyver(fpath):
 :rtype: tuple
 :returns: Python version
 """
-
-cmd = "readelf -Wd '%s'" % fpath
-process = Popen(cmd, stdout=PIPE, shell=True)
-match = SHAREDLIB_RE.search(str(process.stdout.read(), encoding='utf-8'))
+env = {}
+for k, v in os.environ.items():
+if not k.startswith("LANG") and not k.startswith("LC_"):
+env[k] = v
+env["LC_ALL"] = "C.UTF-8"
+report = check_output(["readelf", "-Wd", fpath], stdout=PIPE, env=env)
+match = SHAREDLIB_RE.search(str(report, encoding='utf-8'))
 if match:
 return Version(match.groups()[0])
 

Bug#909699: emacs-gtk: crash on rendering Kannada script

[Zack Weinberg]

Package: emacs-gtk
Version: 1:25.2+1-11
Severity: important
File: /usr/bin/emacs-gtk

If Emacs is displaying its own window (as opposed to running inside a
terminal), visiting the attached text file will cause emacs to segfault.
The file is a cut-down version of /usr/share/themes/Adwaita/index.theme
(from gnome-themes-extra-data); if you visit *that* file, emacs will
not crash until you scroll down far enough to see the line beginning
Comment[kn].  Removing either of the two lines of the test file
suppresses the crash.

A Lisp backtrace (collected with 'xbacktrace' from the Emacs source
tree's .gdbinit) is quite short:

(gdb) xbacktrace
"font-shape-gstring" (0x5900)
"auto-compose-chars" (0x5b58)
"redisplay_internal (C function)" (0x0)

The presence of auto-compose-chars in this trace points a finger at
composite.el, and indeed if you do C-u -1 M-x global-auto-composition-mode
before visiting the test file, Emacs doesn't crash.  However, it looks like
all the heavy lifting is happening in C, inside font-shape-gstring.

A C stack trace (below) points at the guts of libotf / libm17n, but I am
filing this bug against emacs anyway, because gedit, which presumably
uses the same libraries, does not crash on the test file.

Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
0x7453fa95 in lookup_gpos (lookup_list=lookup_list@entry=0xd2ff28, 
lookup_list_index=lookup_list_index@entry=1, 
gstring=gstring@entry=0x9a7da0 , gidx=, 
gidx@entry=0, accumulate=accumulate@entry=1) at otfdrive.c:975
975 otfdrive.c: No such file or directory.
(gdb) bt
#0  0x7453fa95 in lookup_gpos (lookup_list=lookup_list@entry=0xd2ff28, 
lookup_list_index=lookup_list_index@entry=1, gstring=gstring@entry=0x9a7da0 
, gidx=, gidx@entry=0, 
accumulate=accumulate@entry=1)
at otfdrive.c:975
#1  0x74540e64 in OTF_drive_gpos_internal (otf=otf@entry=0xcb7500, 
gstring=gstring@entry=0x9a7da0 , script=, 
language=, features=, 
accumulate=accumulate@entry=1, with_log=1)
at otfdrive.c:1886
#2  0x74542a2a in OTF_drive_gpos_with_log (otf=otf@entry=0xcb7500, 
gstring=gstring@entry=0x9a7da0 , 
script=script@entry=0x7fff499e "knda", language=language@entry=0x0, 
features=features@entry=0x7fff48e0 "abvm,blwm,dist") at otfdrive.c:1935
#3  0x005c3d3a in ftfont_drive_otf (font=, 
spec=, in=, from=, to=, out=0x7fff5610, adjustment=) at 
./debian/build-src/src/ftfont.c:2035
#4  0x740f94f2 in run_otf (depth=, otf_spec=0x18281a8, 
from=from@entry=1, to=to@entry=3, ctx=0x7fff5630) at m17n-flt.c:1945
#5  0x740fcba8 in run_command (depth=depth@entry=8, id=, 
from=from@entry=1, to=to@entry=3, ctx=ctx@entry=0x7fff5630)
at m17n-flt.c:2169
#6  0x740fcf67 in run_rule (depth=8, rule=0x1828140, from=1, 
from@entry=0, to=, to@entry=4, ctx=0x7fff5630)
at m17n-flt.c:1836
#7  0x740fc75c in run_command (depth=depth@entry=7, id=, 
from=from@entry=0, to=to@entry=4, ctx=ctx@entry=0x7fff5630)
at m17n-flt.c:2165
#8  0x740fcf67 in run_rule (depth=7, rule=
0x18280d8, from=from@entry=0, to=, 
to@entry=4, ctx=0x7fff5630) at m17n-flt.c:1836
#9  0x740fc75c in run_command (depth=depth@entry=6, id=, 
from=from@entry=0, to=to@entry=4, ctx=ctx@entry=0x7fff5630)
at m17n-flt.c:2165
#10 0x740fcb53 in run_cond (cond=0x1828070, cond=0x1828070, 
ctx=0x7fff5630, to=4, from=0, depth=) at m17n-flt.c:1863
#11 0x740fcb53 in run_command (depth=depth@entry=5, id=, 
from=from@entry=0, to=to@entry=4, ctx=ctx@entry=0x7fff5630)
at m17n-flt.c:2167
#12 0x740fcf67 in run_rule (depth=5, rule=
0x1828008, from=from@entry=0, to=, ctx=0x7fff5630)
at m17n-flt.c:1836
#13 0x740fc75c in run_command (depth=depth@entry=4, 
id=id@entry=-16777232, from=from@entry=0, to=, 
ctx=ctx@entry=0x7fff5630)
at m17n-flt.c:2165
#14 0x740fdb98 in run_stages (gstring=gstring@entry=0x9a7d80 , 
from=from@entry=0, to=, 
to@entry=2, ctx=ctx@entry=0x7fff5630, flt=)
at m17n-flt.c:2359
#15 0x740fee51 in mflt_run (gstring=gstring@entry=0x9a7d80 , 
from=from@entry=0, to=, 
to@entry=2, font=font@entry=0x7fff5760, flt=, 
flt@entry=0x0) at m17n-flt.c:3050
#16 0x005c4d70 in ftfont_shape_by_flt (matrix=, 
otf=, ft_face=, font=, 
lgstring=10802589)
at ./debian/build-src/src/ftfont.c:2644
#17 0x005c4d70 in ftfont_shape (lgstring=10802589)
---Type  to continue, or q  to quit---
at ./debian/build-src/src/ftfont.c:2697
#18 0x005c875e in xftfont_shape (lgstring=10802589)
at ./debian/build-src/src/xftfont.c:672
#19 0x00573e98 in Ffont_shape_gstring (gstring=10802589)
at ./debian/build-src/src/font.c:4410
#20 0x005648d8 in Ffuncall (nargs=2, args=args@entry=0x7fff58f8)
at ./debian/build-src/src/lisp.h:1061
#21 0x00599a6b in exec_byte_code (bytestr=, 
vector=, maxdepth=, 

Bug#907893: elpa-ess: R-initialize-on-start looks for .load.R in the wrong place

[Zack Weinberg]

Yes, that is correct:

ii  emacs 1:25.2+1-11
ii  emacs-bin-common  1:25.2+1-11
ii  emacs-common  1:25.2+1-11
ii  emacs-gtk 1:25.2+1-11
ii  emacsen-common3.0.2

See my other message: this appears to be a problem with upgrades from
the pre-ELPA versions of the ESS packages.  Suggest installing ess
17.11-2 or -3 in your container, upgrading to the current version, and
then see if you can reproduce?  Might also be worth testing an upgrade
from whatever version shipped in stretch.

zw

Bug#907893: elpa-ess: R-initialize-on-start looks for .load.R in the wrong place

[Zack Weinberg]

Additionally, if I start Emacs with --no-site-file --no-init-file, M-x
R is initially not a valid command, but if I do M-x
package-initialize, M-x R becomes available ... and still throws the
same error.  In that case, *Messages* contains

For information about GNU Emacs and the GNU system, type C-h C-a.
You can run the command ‘package-initialize’ with M-x p-ini RET
Type C-h m for help on ESS version 17.11
ess-tracebug mode enabled
load ESSR: + + + Error in file(filename, "r", encoding = encoding) :
  cannot open the connection
In addition: Warning message:
In file(filename, "r", encoding = encoding) :
  cannot open file ’/usr/share/ess/etc/ESSR/R/.load.R’: No such file
or directory

Bug#907893: elpa-ess: R-initialize-on-start looks for .load.R in the wrong place

[Zack Weinberg]

Thinking about this some more, C-h v keeps telling me that the bad
value for ess-etc-directory is coming from ess-site.el even though the
string 'ess-etc-directory' does not appear in ess-site.el.  So I got
suspicious.

$ find / -name 'ess-site.el*' -ls 2> /dev/null
33614087  4 -rw-r--r--   1 root root 3821 Aug 22 12:49
/usr/share/emacs/site-lisp/ess/ess-site.elc
 16804888 12 -rw-r--r--   1 root root 8345 Aug 24
07:57 /usr/share/emacs/site-lisp/elpa-src/ess-17.11/ess-site.el
 33736809  0 lrwxrwxrwx   1 root root   58 Aug 28
11:47 /usr/share/emacs/site-lisp/elpa/ess-17.11/ess-site.el ->
/usr/share/emacs/site-lisp/elpa-src/ess-17.11//ess-site.el
 33746754  4 -rw-r--r--   1 root root 3646 Aug 28
11:47 /usr/share/emacs/site-lisp/elpa/ess-17.11/ess-site.elc
 17260428  4 -rw-r--r--   1 root root 3821 Aug 17
16:12 /usr/share/emacs/25.2/site-lisp/ess/ess-site.elc

After 'dpkg --purge elpa-ess', the oldest two of those are still present:
 33614087  4 -rw-r--r--   1 root root 3821 Aug 22
12:49 /usr/share/emacs/site-lisp/ess/ess-site.elc
 17260428  4 -rw-r--r--   1 root root 3821 Aug 17
16:12 /usr/share/emacs/25.2/site-lisp/ess/ess-site.elc

These files are identical, and they contain a setting for ess-etc-directory:

$ grep -a etc /usr/share/emacs/site-lisp/ess/ess-site.elc
#@130 Location of the ESS etc/ directory.
The ESS etc directory stores various auxillary files that are useful
(defvar ess-etc-directory "/usr/share/ess/etc/" (#$ . 695))

(A copy of the whole file is attached.)  In fact, both
/usr/share/emacs/25.2/site-lisp/ess and /usr/share/emacs/site-lisp/ess
appear to be detritus from older versions of the ESS packages,
containing a full set of .elc files for the ESS code.  After deleting
both directories and their contents and re-installing the elpa-ess
package (but not the transitional 'ess' package), M-x R no longer
throws errors, and C-c v works correctly in buffers containing R code.

So, if there is a bug here, it involves upgrading from the pre-ELPA
versions of the ESS packages, to the ELPA-ified versions.

zw


ess-site.elc.gz
Description: application/gzip

Bug#907893: elpa-ess: R-initialize-on-start looks for .load.R in the wrong place

[Zack Weinberg]

> I _cannot_ reproduce that right now in a pristine testing/unstable session
> running off Docker's r-base container (which I co-maintain):
...
> Exactly _how_ do you launch the R session leading to the error?

I get the error just by doing M-x R in a freshly started emacs
session, on two different computers, even if I rename my .emacs.d so
that neither my init file or my customize settings are found.  This is
the complete contents of *Messages* after doing M-x R.  Nothing in

Loading /etc/emacs/site-start.d/00debian.el (source)...done
Loading /etc/emacs/site-start.d/00debian-vars.el (source)...done
Loading /etc/emacs/site-start.d/50autoconf.el (source)...done
Loading /etc/emacs/site-start.d/50cmake-data.el (source)...done
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...
Loading debian-ispell...
Loading /var/cache/dictionaries-common/emacsen-ispell-default.el (source)...done
Loading debian-ispell...done
Loading /var/cache/dictionaries-common/emacsen-ispell-dicts.el (source)...done
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...done
Loading /etc/emacs/site-start.d/50gtk-doc-tools.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.
Type C-h m for help on ESS version 17.11
ess-tracebug mode enabled
load ESSR: + + + Error in file(filename, "r", encoding = encoding) :
  cannot open the connection
In addition: Warning message:
In file(filename, "r", encoding = encoding) :
  cannot open file ’/usr/share/ess/etc/ESSR/R/.load.R’: No such file
or directory

And this is the complete contents of *ESS*:

[ess-site.el]: ess-customize-alist=nil
[ess-site.el _2_]: ess-customize-alist=nil
`ess-icon-directory' does not exist; using `ess-etc-directory'.
Creating global Emacs toolbar(S): ess-s-versions-create making M-x defuns for

(R): ess-r-versions-create making M-x defuns for


(R): ess-dialect=nil, buf=*GNU Emacs*, start-arg=nil
 current-prefix-arg=nil
(inf-ess 1): lang=nil, dialect=nil, tmp-dialect=R, buf=*GNU Emacs*
(inf-ess 1.1): procname=R temp-dialect=R, buf-name=*R*
(inf-ess 2.0) Method #3 start=/home/zack/ buf=*R*
(ess-setq-vars-LOCAL): language=S, dialect=R, buf=nil,
comint..echoes=t, comint..sender=comint-simple-send
(inf-ess 2.1): ess-language=S, ess-dialect=R buf=*R*
(ess-setq-vars-LOCAL): language=S, dialect=R, buf=nil,
comint..echoes=t, comint..sender=inferior-ess-input-sender
(i-ess 1): buf=*R*, lang=S, comint..echo=t,
comint..sender=inferior-ess-input-sender,
(i-ess end): buf=*R*, lang=S, comint..echo=t,
comint..sender=inferior-ess-input-sender,
(inf-ess 3.0): prog=R, start-args=--no-readline  , echoes=t
Making Process...Buf *R*, :Proc R, :Prog R
 :Args= --no-readline
Start File=nil
(inferior-ess: waiting for process to start (before hook)
(inferior-ess 3): waiting for process after hookload-ESSR cmd:
local({
  source('/usr/share/ess/etc/ESSR/R/.load.R',
local=TRUE) #define load.ESSR
  load.ESSR('/usr/share/ess/etc/ESSR/R')
  })

(R): inferior-ess-language-start=options(STERM='iESS',
str.dendrogram.last="'", editor='emacsclient',
show.error.locations=TRUE)

Bug#907977: python-minimal: please consider adding argparse to minimal modules

[Zack Weinberg]

Package: python-minimal
Version: 2.7.15-3
Severity: wishlist

I am one of the upstream maintainers of GNU libc.  We are considering
starting to use Python for scripts run during the build.  This obviously
adds some version of Python to the set of packages that need to be built
early in the process of bringing up a new architecture, and we want to
minimize the hassle for people doing that work.  We think it would help
if we made sure sure that all Python scripts run during the build work
with only Debian's python-minimal installed; thus, most of the external
libraries pulled in by the full Python stdlib would not be required.
We've looked over the set of modules included in python-minimal, and the
only one that's missing that we're sure we want to use is argparse.

Would you please consider adding argparse to the set of modules included
in python-minimal?  This would also require adding copy and copy_reg, but
in Python 2 all of those appear to be pure-Python modules (no C component)
so I should think it wouldn't be a huge extra maintenance burden.

The discussion about using Python scripts during the build of glibc starts at
https://sourceware.org/ml/libc-alpha/2018-08/msg00190.html and continues at
https://sourceware.org/ml/libc-alpha/2018-09/msg00025.html .  We currently
plan to keep our scripts compatible with both Python 2 and 3 at least through
upstream EOL for Python 2, so I'm going to file a copy of this bug against
python3-minimal.

Thanks,
zw

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.17.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python-minimal depends on:
ii  dpkg   1.19.0.5+b1
ii  python2-minimal2.7.15-3
ii  python2.7-minimal  2.7.15-4

Versions of packages python-minimal recommends:
ii  python  2.7.15-3

python-minimal suggests no packages.

-- no debconf information

Bug#907976: python3-minimal: please consider adding argparse to minimal modules

[Zack Weinberg]

Package: python3-minimal
Version: 3.6.6-1
Severity: wishlist

I am one of the upstream maintainers of GNU libc.  We are considering
starting to use Python for scripts run during the build.  This obviously
adds some version of Python to the set of packages that need to be built
early in the process of bringing up a new architecture, and we want to
minimize the hassle for people doing that work.  We think it would help
if we made sure sure that all Python scripts run during the build work
with only Debian's python3-minimal installed; thus, most of the external
libraries pulled in by the full Python stdlib would not be required.
We've looked over the set of modules included in python3-minimal, and the
only one that's missing that we're sure we want to use is argparse.

Would you please consider adding argparse to the set of modules included
in python3-minimal?  This would also require adding copy and copyreg,
but all of those appear to be pure-Python modules (no C component)
so I should think it wouldn't be a huge extra maintenance burden.

The discussion about using Python scripts during the build of glibc starts at
https://sourceware.org/ml/libc-alpha/2018-08/msg00190.html and continues at
https://sourceware.org/ml/libc-alpha/2018-09/msg00025.html .  We currently
plan to keep our scripts compatible with both Python 2 and 3 at least through
upstream EOL for Python 2, so I'm going to file a copy of this bug against
python-minimal.

Thanks,
zw

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.17.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-minimal depends on:
ii  dpkg   1.19.0.5+b1
ii  python3.6-minimal  3.6.6-3

python3-minimal recommends no packages.

python3-minimal suggests no packages.

-- no debconf information

Bug#907893: elpa-ess: R-initialize-on-start looks for .load.R in the wrong place

[Zack Weinberg]

Package: elpa-ess
Version: 17.11-5
Severity: normal

When you start an R process from inside ESS, it's supposed to load a
file ".load.R" that, among other things, sets it up so C-c C-v works.
R-initialize-on-start is looking for this file in the wrong place.
I get these error messages in *Messages*:

Type C-h m for help on ESS version 17.11
Cannot read history file /home/zack/.Rhistory
ess-tracebug mode enabled
load ESSR: + + + Error in file(filename, "r", encoding = encoding) : 
  cannot open the connection
In addition: Warning message:
In file(filename, "r", encoding = encoding) :
  cannot open file ’/usr/share/ess/etc/ESSR/R/.load.R’: No such file or 
directory

The directory /usr/share/ess does not exist.
The package has actually installed .load.R in
/usr/share/emacs/site-lisp/elpa-src/ess-17.11/etc/ESSR/R/.load.R
If I manually do

source("/usr/share/emacs/site-lisp/elpa-src/ess-17.11/etc/ESSR/R/.load.R")
load.ESSR("/usr/share/emacs/site-lisp/elpa-src/ess-17.11/etc/ESSR/R")

then C-c C-v starts working again.

The bad path is coming from the 'ess-etc-directory' variable.  C-h v says:

ess-etc-directory is a variable defined in ‘ess-site.el’.
Its value is "/usr/share/ess/etc/"

However, the string 'ess-etc-directory' does not appear anywhere in
ess-site.el.  It appears actually to be defined in ess-utils.el, but
if I try to re-execute the code in ess-utils.el that sets its value,
that doesn't work either:

ERROR:ess-site.el:ess-etc-directory
Relative to ess-lisp-directory, one of the following must exist:
../etc/ess, ../etc, ../../etc/ess or ./etc

C-h v ess-lisp-directory says:

ess-lisp-directory is a variable defined in ‘ess-site.el’.
Its value is "/usr/share/emacs/site-lisp/ess"

That directory does exist, but it's not part of the package and I
don't know how to debug this any further. In case it helps:

$ ls -l /usr/share/emacs/site-lisp/ess
total 1224
-rw-r--r-- 1 root root   1670 Aug 18 11:30 ess-arc-d.elc
-rw-r--r-- 1 root root   6913 Aug 18 11:30 ess-bugs-d.elc
-rw-r--r-- 1 root root   7732 Aug 18 11:30 ess-bugs-l.elc
-rw-r--r-- 1 root root   1275 Aug 18 11:30 ess-compat.elc
-rw-r--r-- 1 root root   1022 Aug 18 11:30 ess-comp.elc
-rw-r--r-- 1 root root  92727 Aug 18 11:30 ess-custom.elc
-rw-r--r-- 1 root root   5008 Aug 18 11:30 ess-dde.elc
-rw-r--r-- 1 root root   1483 Aug 18 11:30 ess-debug.elc
-rw-r--r-- 1 root root   6471 Aug 18 11:30 essd-els.elc
-rw-r--r-- 1 root root   2658 Aug 18 11:30 ess.elc
-rw-r--r-- 1 root root551 Aug 18 11:30 ess-eldoc.elc
-rw-r--r-- 1 root root   4222 Aug 18 11:30 ess-font-lock.elc
-rw-r--r-- 1 root root   3457 Aug 18 11:30 ess-generics.elc
-rw-r--r-- 1 root root  17029 Aug 18 11:30 ess-gretl.elc
-rw-r--r-- 1 root root  30779 Aug 18 11:30 ess-help.elc
-rw-r--r-- 1 root root  95795 Aug 18 11:30 ess-inf.elc
-rw-r--r-- 1 root root   3242 Aug 18 11:30 ess-install.elc
-rw-r--r-- 1 root root   6140 Aug 18 11:30 ess-jags-d.elc
-rw-r--r-- 1 root root  15544 Aug 18 11:30 ess-julia.elc
-rw-r--r-- 1 root root   1282 Aug 18 11:30 ess-lsp-l.elc
-rw-r--r-- 1 root root  28374 Aug 18 11:30 ess-mode.elc
-rw-r--r-- 1 root root   6168 Aug 18 11:30 ess-mouse.elc
-rw-r--r-- 1 root root   2436 Aug 18 11:30 ess-noweb.elc
-rw-r--r-- 1 root root   7374 Aug 18 11:30 ess-noweb-font-lock-mode.elc
-rw-r--r-- 1 root root  46287 Aug 18 11:30 ess-noweb-mode.elc
-rw-r--r-- 1 root root   2527 Aug 18 11:30 ess-omg-d.elc
-rw-r--r-- 1 root root   2880 Aug 18 11:30 ess-omg-l.elc
-rw-r--r-- 1 root root526 Aug 18 11:30 ess-pkg.elc
-rw-r--r-- 1 root root   2792 Aug 18 11:30 ess-r-a.elc
-rw-r--r-- 1 root root   2901 Aug 18 11:30 ess-r-args.elc
-rw-r--r-- 1 root root  15170 Aug 18 11:30 ess-r-completion.elc
-rw-r--r-- 1 root root  14133 Aug 18 11:30 ess-rd.elc
-rw-r--r-- 1 root root  10279 Aug 18 11:30 ess-rdired.elc
-rw-r--r-- 1 root root   6136 Aug 18 11:30 ess-r-gui.elc
-rw-r--r-- 1 root root  63776 Aug 18 11:30 ess-r-mode.elc
-rw-r--r-- 1 root root  30334 Aug 18 11:30 ess-roxy.elc
-rw-r--r-- 1 root root  16162 Aug 18 11:30 ess-r-package.elc
-rw-r--r-- 1 root root  40232 Aug 18 11:30 ess-r-syntax.elc
-rw-r--r-- 1 root root  11715 Aug 18 11:30 ess-rutils.elc
-rw-r--r-- 1 root root   1785 Aug 18 11:30 ess-s3-d.elc
-rw-r--r-- 1 root root   1914 Aug 18 11:30 ess-s4-d.elc
-rw-r--r-- 1 root root  38396 Aug 18 11:30 ess-sas-a.elc
-rw-r--r-- 1 root root   6830 Aug 18 11:30 ess-sas-d.elc
-rw-r--r-- 1 root root  41313 Aug 18 11:30 ess-sas-l.elc
-rw-r--r-- 1 root root   1283 Aug 18 11:30 ess-send2.elc
-rw-r--r-- 1 root root   1121 Aug 18 11:30 ess-send.elc
-rw-r--r-- 1 root root   3821 Aug 18 11:30 ess-site.elc
-rw-r--r-- 1 root root  19292 Aug 18 11:30 ess-s-lang.elc
-rw-r--r-- 1 root root   2001 Aug 18 11:30 ess-sp3-d.elc
-rw-r--r-- 1 root root  11131 Aug 18 11:30 ess-sp4-d.elc
-rw-r--r-- 1 root root   2024 Aug 18 11:30 ess-sp5-d.elc
-rw-r--r-- 1 root root   7989 Aug 18 11:30 ess-sp6-d.elc
-rw-r--r-- 1 root root  17563 Aug 18 11:30 ess-sp6w-d.elc
-rw-r--r-- 1 root root  22380 Aug 18 11:30 

Bug#906517: ess: doesn't load, "Package ess not fully installed. Skipping setup" in *Messages*

[Zack Weinberg]

I installed that package over 17.11-2 and ESS is now loading correctly
with no manual intervention required.  Thanks for the quick fix!

Bug#906517: ess: doesn't load, "Package ess not fully installed. Skipping setup" in *Messages*

[Zack Weinberg]

On Fri, Aug 17, 2018 at 4:35 PM, Dirk Eddelbuettel  wrote:
> Ack. Can you check if invoking emacsen-install differently, or updating it,
> would help?
>
> The postinst should still have
>
> if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = 
> "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
> if [ -e 
> /var/lib/emacsen-common/state/package/installed/emacsen-common -a -x 
> /usr/lib/emacsen-common/emacs-package-install ] ; then
> /usr/lib/emacsen-common/emacs-package-install --postinst ess
> fi
> fi

This is the complete contents of ess.postinst:

#!/bin/sh
set -e
# Automatically added by dh_installemacsen/10.10.8
if [ "$1" = "configure" ] && [ -e
/var/lib/emacsen-common/state/package/installed/emacsen-common -a -x
/usr/lib/emacsen-common/emacs-package-install ]
then
/usr/lib/emacsen-common/emacs-package-install --postinst ess
fi
# End automatically added section

> What happens when you run this, ie 'emacs-package-install --postinst ess' ?

I tried that.  It does some other unrelated stuff and then it runs
/usr/lib/emacsen-common/packages/install/ess with sole argument
"emacs", and that's where we came in.

zw

Bug#906517: ess: doesn't load, "Package ess not fully installed. Skipping setup" in *Messages*

[Zack Weinberg]

Package: ess
Version: 17.11-2
Severity: normal

With the current packaging of Emacs 25.2.2 in unstable, ess doesn't get
loaded as it ought to.  I believe this is fallout from the Emacs maintainers
dropping the version number from the packages (as of 'emacs' package version
1:25.2+1-7).  On startup, the *Messages* buffer has

Loading /etc/emacs/site-start.d/50ess.el (source)...
Package ess not fully installed.  Skipping setup.
Loading /etc/emacs/site-start.d/50ess.el (source)...done

and 'r-mode is not defined.  I traced through the execution of
50ess.el by hand and found that it's bailing out because
debian-emacs-flavor is "emacs" and 
/usr/share/emacs/site-lisp/ess/ess-site.elc 
does not exist.  That file does not exist because
/usr/lib/emacsen-common/packages/install/ess
silently exits when its FLAVOR argument is "emacs".

I'm not sure what the _proper_ fix is, but if I byte-compile all the
.el files in /usr/share/emacs/site-lisp/ess and then replace 50ess.el
with just

(require 'ess-site)

then ess is loaded again.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.17.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ess depends on:
ii  dpkg1.19.0.5+b1
ii  emacsen-common  3.0.2
ii  install-info6.5.0.dfsg.1-4

Versions of packages ess recommends:
ii  r-base-core  3.5.1-1+b1

Versions of packages ess suggests:
pn  jags   
pn  julia  
pn  pspp   
pn  xlispstat  

-- no debconf information

Bug#878943: with mutter 2.26.2, this only affects gnome-terminal anymore

[Zack Weinberg]

reassign 878943 gnome-terminal
quit

mutter version 3.26.2 seems to have corrected the problem for *most*
graphical programs -- but not for gnome-terminal.  I am therefore
reassigning this bug to gnome-terminal.

Bug#878943: mutter: 2.26 regression: one-dimensional window maximize no longer possible

[Zack Weinberg]

Package: mutter
Version: 3.26.1-5
Severity: normal

With the GNOME 2.26 mutter, one-dimensional window maximize no longer
works correctly.  Specifically, if you set one of the "titlebar actions"
in gnome-tweak-tool's "windows" tab to either "toggle maximize vertically"
or "toggle maximize horizontally", then triggering the action will
cause the window to be fully maximized instead of maximized in only the
desired direction.

I waited to file this bug until both the 2.26 gnome-shell and the
2.26 gnome-tweak-tool appeared in unstable, but the behavior has been
consistently wrong since 2.26 mutter appeared in unstable, so I'm
pretty sure it's mutter's fault.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mutter depends on:
ii  gnome-settings-daemon  3.26.1-2
ii  gsettings-desktop-schemas  3.24.1-1
ii  libc6  2.24-17
ii  libglib2.0-0   2.54.1-1
ii  libmutter-1-0  3.26.1-5
ii  libx11-6   2:1.6.4-3
ii  libxcomposite1 1:0.4.4-2
ii  mutter-common  3.26.1-5
ii  zenity 3.24.0-1

mutter recommends no packages.

Versions of packages mutter suggests:
ii  gnome-control-center  1:3.26.1-2
pn  xdg-user-dirs 

-- no debconf information

Bug#877667: firmware-realtek: please add RTL8812 firmware (rtl8812aefw.bin & rtl8812aefw_wowlan.bin)

[Zack Weinberg]

Package: firmware-realtek
Version: 20170823-1
Severity: normal
Tags: upstream

This PCI WiFi card...

05:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8812AE 
802.11ac PCIe Wireless Network Adapter [10ec:8812] (rev 01)
Subsystem: TRENDnet RTL8812AE 802.11ac PCIe Wireless Network Adapter 
[20f4:807e]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: rtl8821ae
Kernel modules: rtl8821ae

... requires firmware to work reliably, and the firmware that it
requires (rtl8812aefw.bin and rtl8812aefw_wowlan.bin) is missing from
firmware-realtek.  The driver tries loading rtl8821aefw{,_wowlan}.bin
instead, but this does not make the hardware happy: it cannot maintain
download speeds above about 100kB/s, and it keeps losing its association
with the access point - I suspect these are both visible manifestations
of a severe packet loss problem.

Unfortunately, the necessary firmware binaries do not
appear to be in linux-firmware.git either.  I found them at
https://github.com/lwfinger/rtlwifi_new/tree/master/firmware/rtlwifi
and those do seem to be working reliably.

(This card is sold as "TRENDnet TEW-807ECH AC1200 High Power Wireless
Dual Band PCIe Adapter".)

Relevant excerpts from the kernel log when the firmware is missing:

 [   10.502081] rtl8821ae :05:00.0: enabling device ( -> 0003)
 [   10.519792] rtl8821ae: Using firmware rtlwifi/rtl8812aefw.bin
 [   10.519794] rtl8821ae: Using firmware rtlwifi/rtl8812aefw_wowlan.bin
 [   10.574617] rtl8821ae :05:00.0: firmware: failed to load 
rtlwifi/rtl8812aefw_wowlan.bin (-2)
 [   10.574655] rtl8821ae :05:00.0: Direct firmware load for 
rtlwifi/rtl8812aefw_wowlan.bin failed with error -2
 [   10.574697] rtl8821ae :05:00.0: firmware: failed to load 
rtlwifi/rtl8812aefw.bin (-2)
 [   10.574727] rtl8821ae :05:00.0: Direct firmware load for 
rtlwifi/rtl8812aefw.bin failed with error -2
 [   10.622946] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
 [   10.623072] rtlwifi: rtlwifi: wireless switch is on
 [   11.213655] rtl8821ae :05:00.0: firmware: direct-loading firmware 
rtlwifi/rtl8821aefw.bin
 [   11.213662] rtlwifi: Loading alternative firmware rtlwifi/rtl8821aefw.bin
 [   11.213672] rtlwifi: Loading alternative firmware rtlwifi/rtl8821aefw.bin
 [   11.477030] rtl8821ae :05:00.0 wlp5s0: renamed from wlan0
 [   19.572265] rtl8821ae: Polling FW ready fail!! REG_MCUFWDL:0x00070706 .
 [   19.912098] rtl8821ae: Polling FW ready fail!! REG_MCUFWDL:0x00070706 .
 [   21.384057] rtl8821ae: Polling FW ready fail!! REG_MCUFWDL:0x00070706 .
 [   48.144496] rtl8821ae: Polling FW ready fail!! REG_MCUFWDL:0x00070706 .
 [   81.163287] rtl8821ae: Polling FW ready fail!! REG_MCUFWDL:0x00070706 .
 [  124.173712] rtl8821ae: Polling FW ready fail!! REG_MCUFWDL:0x00070706 .
 [  174.166256] rtl8821ae: Polling FW ready fail!! REG_MCUFWDL:0x00070706 .
 [  178.011057] rtl8821ae: Polling FW ready fail!! REG_MCUFWDL:0x00070706 .
 [  178.360943] rtl8821ae: Polling FW ready fail!! REG_MCUFWDL:0x00070706 .
 [  186.498418] rtl8821ae: Polling FW ready fail!! REG_MCUFWDL:0x00070706 .
 [  189.787011] wlp5s0: authenticate with 88:ad:43:bf:6e:a8
 [  189.787883] wlp5s0: send auth to 88:ad:43:bf:6e:a8 (try 1/3)
 [  189.789226] wlp5s0: authenticated
 [  189.797492] wlp5s0: associate with 88:ad:43:bf:6e:a8 (try 1/3)
 [  189.807617] wlp5s0: RX AssocResp from 88:ad:43:bf:6e:a8 (capab=0x411 
status=0 aid=1)
 [  189.813597] wlp5s0: associated
 [  189.870937] wlp5s0: Limiting TX power to 27 (30 - 3) dBm as advertised by 
88:ad:43:bf:6e:a8
 [  849.964133] rtlwifi: AP off, try to reconnect now
 [  849.964202] wlp5s0: Connection to AP 88:ad:43:bf:6e:a8 lost
 [  855.344960] rtl8821ae: Polling FW ready fail!! REG_MCUFWDL:0x00070706 .
 [  858.654983] wlp5s0: authenticate with 88:ad:43:bf:6e:a0
 [  858.655871] wlp5s0: send auth to 88:ad:43:bf:6e:a0 (try 1/3)
 [  858.658445] wlp5s0: authenticated
 [  858.665893] wlp5s0: associate with 88:ad:43:bf:6e:a0 (try 1/3)
 [  858.670647] wlp5s0: RX AssocResp from 88:ad:43:bf:6e:a0 (capab=0x431 
status=0 aid=2)
 [  858.676544] wlp5s0: associated
 [  881.995258] rtlwifi: AP off, try to reconnect now
 [  881.995316] wlp5s0: Connection to AP 88:ad:43:bf:6e:a0 lost
 [  885.266245] wlp5s0: authenticate with 88:ad:43:bf:6e:a8
 [  885.267089] wlp5s0: send auth to 88:ad:43:bf:6e:a8 (try 1/3)
 [  885.369150] wlp5s0: send auth to 88:ad:43:bf:6e:a8 (try 2/3)
 [  885.473136] wlp5s0: send auth to 88:ad:43:bf:6e:a8 (try 3/3)
 [  885.577130] wlp5s0: authentication with 88:ad:43:bf:6e:a8 timed out
 [  897.187365] rtl8821ae: Polling FW ready fail!! REG_MCUFWDL:0x00070706 .
 [  900.709948] rtl8821ae: Polling FW ready fail!! REG_MCUFWDL:0x00070706 .
 [  900.965784] wlp5s0: authenticate with 88:ad:43:bf:6e:a8
 [  900.966542] wlp5s0: send auth to 

Bug#865442: correction: errno is special, python is not the problem

[Zack Weinberg]

Control: retitle -1 gdb: x86-64: "cannot find thread-local variables
on this target"

Further experimentation indicates that this is a problem with
thread-local variables in general and there's something special about
'errno' that makes it appear to work; the Python interface is not the
problem.  For instance:

$ cat test.c
#include 
#include 
static _Thread_local int foo;
int main(void)
{
  printf("%d %d\n", errno, foo);
}
$ gcc -g test.c
$ gdb ./a.out
...
(gdb) b main
Breakpoint 1 at 0x749: file test.c, line 6.
(gdb) r
Starting program: /home/zack/a.out

Breakpoint 1, main () at test.c:6
6  printf("%d %d\n", errno, foo);
(gdb) p errno
$1 = 0
(gdb) p foo
Cannot find thread-local storage for process 13090, executable file
/home/zack/a.out:
Cannot find thread-local variables on this target

Bug#865442: gdb: "cannot find thread-local storage" from Python, not from CLI

[Zack Weinberg]

Package: gdb
Version: 7.12-6
Severity: normal
Tags: upstream

Attempting to read thread-local variables (e.g. errno) from the
Python interface fails with "Cannot find thread-local storage", but
reading the same variable from the (gdb) prompt works.  Transcript:

$ cat test.c
#include 
#include 
int main(void)
{
  printf("%d\n", errno);
}
$ gcc -g test.c
$ gdb ./a.out
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./a.out...done.
(gdb) b main
Breakpoint 1 at 0x704: file test.c, line 6.
(gdb) r
Starting program: /home/zack/a.out 

Breakpoint 1, main () at test.c:6
6 printf("%d\n", errno);
(gdb) p errno
$1 = 0
(gdb) pi
>>> gdb.parse_and_eval('errno')
Traceback (most recent call last):
  File "", line 1, in 
gdb.error: Cannot find thread-local storage for process 8486, shared library 
/lib/x86_64-linux-gnu/libc.so.6:
Cannot find thread-local variables on this target

I observe the same behavior with 7.12-6 (unstable) and 8.0-1 (experimental).

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (501, 'unstable'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'testing'), (101, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gdb depends on:
ii  libbabeltrace-ctf1  1.5.2-1
ii  libbabeltrace1  1.5.2-1
ii  libc6   2.24-12
ii  libexpat1   2.2.1-1
ii  liblzma55.2.2-1.2+b1
ii  libncurses5 6.0+20161126-1
ii  libpython3.53.5.3-3
ii  libreadline77.0-3
ii  libtinfo5   6.0+20161126-1
ii  zlib1g  1:1.2.8.dfsg-5

Versions of packages gdb recommends:
ii  libc6-dbg [libc-dbg]  2.24-12

Versions of packages gdb suggests:
pn  gdb-doc
ii  gdbserver  7.12-6

-- no debconf information

Bug#863914: linux-libc-dev: Install separate from /usr/include

[Zack Weinberg]

On Sat, Jun 3, 2017 at 5:05 PM, Ben Hutchings  wrote:
>> It would be much easier to arrange
>> this if the kernel's headers were installed in a location separate from
>> /usr/include and then symlinked into /usr/include.  (It would be fine to
>> symlink just the directories.)
>
> I don't understand how this would help.

Suppose there exists a directory (let's call it
/usr/src/linux/include, just for concreteness) that contains all the
kernel headers and no other headers. Then my Makefiles can pass
-nostdinc -isystem $(gcc -print-file-name=include) -isystem
/usr/src/linux/include in CFLAGS to see only the kernel's headers and
the compiler's headers. Without such a directory, the only way to get
the same effect that I can think of is to manually create that
directory somehow. It'd be much easier to do this in linux-libc-dev,
which already knows what all the files are.

zw

Bug#863914:

[Zack Weinberg]

Upstream patch submission:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1411004.html

Bug#863914: linux-libc-dev: Install separate from /usr/include

[Zack Weinberg]

Package: linux-libc-dev
Version: 4.11-1~exp2
Severity: wishlist

Certain low-level programs and libraries, notably glibc, would like to
be able to make sure that they do *not* use any system headers during
their build, other than the kernel's headers and the ones provided by
the compiler (stddef.h, stdarg.h etc)  It would be much easier to arrange
this if the kernel's headers were installed in a location separate from
/usr/include and then symlinked into /usr/include.  (It would be fine to
symlink just the directories.)


-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (501, 'unstable'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'testing'), (101, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#863909: linux/a.out.h: should use #ifdef __linux__ not #ifdef linux, etc

[Zack Weinberg]

Package: linux-libc-dev
Version: 4.11-1~exp2
Severity: normal
File: /usr/include/linux/a.out.h
Tags: upstream, patch

linux/a.out.h contains a number of uses of "deprecated
system-specific predefined macros" that will not be defined
when the compiler is used in a strict conformance mode, see
https://gcc.gnu.org/onlinedocs/gcc-6.3.0/cpp/System-specific-Predefined-Macros.html
for details.

This would only be a minor problem, except that it causes the GCC build
process to copy the header, "fix" it, and install the "fixed" copy in a
private directory that is searched before /usr/include.  It is desirable
for GCC not to do this to any headers, because it means updates to the
original are silently ignored until the GCC package is itself updated.

Please apply the attached patch.  It would be best if it were installed
to all actively maintained Debian kernels.  I will submit it upstream.

zw

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (501, 'unstable'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'testing'), (101, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information
--- a/linux/a.out.h 2017-06-01 16:33:49.558497923 -0400
+++ b/linux/a.out.h 2017-06-01 16:35:42.559478580 -0400
@@ -115,21 +115,21 @@
 /* Address of data segment in memory after it is loaded.
Note that it is up to you to define SEGMENT_SIZE
on machines not listed here.  */
-#if defined(vax) || defined(hp300) || defined(pyr)
+#if defined(__vax__) || defined(__hp300__) || defined(__pyr__)
 #define SEGMENT_SIZE page_size
 #endif
-#ifdef sony
+#ifdef __sony__
 #defineSEGMENT_SIZE0x2000
 #endif /* Sony.  */
-#ifdef is68k
+#ifdef __is68k__
 #define SEGMENT_SIZE 0x2
 #endif
-#if defined(m68k) && defined(PORTAR)
+#if defined(__m68k__) && defined(__PORTAR__)
 #define PAGE_SIZE 0x400
 #define SEGMENT_SIZE PAGE_SIZE
 #endif
 
-#ifdef linux
+#ifdef __linux__
 #include 
 #if defined(__i386__) || defined(__mc68000__)
 #define SEGMENT_SIZE   1024
@@ -256,7 +256,7 @@
   unsigned int r_extern:1;
   /* Four bits that aren't used, but when writing an object file
  it is desirable to clear them.  */
-#ifdef NS32K
+#ifdef __NS32K__
   unsigned r_bsr:1;
   unsigned r_disp:1;
   unsigned r_pad:2;

Bug#844453: upstream report

[Zack Weinberg]

Filed https://github.com/systemd/systemd/issues/5659

Bug#844453: apt-daily.service delays startup by more than five minutes

[Zack Weinberg]

On Mon, Mar 27, 2017 at 6:14 PM, Julian Andres Klode <j...@debian.org> wrote:
> On Mon, Mar 27, 2017 at 12:15:38PM -0400, Zack Weinberg wrote:
>>
>> Well, it _is_ run at boot, and in fact _blocks_ boot, so I don't see
>> specifying that it should run within an hour of boot and not block
>> anything as a step in the _wrong_ direction...
>
> Why should it block boot? It has no dependencies, nor reverse
> dependencies. systemd is dependency based. It might not consider
> the boot complete, but it certainly does not affect any other
> service.

I don't actually know that it blocks in the sense of systemd waiting
for it to be done before declaring multiuser.target (or something) to
be available.  What I know is that the time from power-on to being
able to interact with the (gdm) login screen, as measured by an
external stopwatch, is consistently two to five seconds shorter when
apt-daily.service is not run during boot.  It _could_ be entirely due
to disk contention -- but I would still consider that sufficient
reason to not run this during boot.

>> I think systemd is probably
>> noticing that the calendar deadline expired while the computer was
>> off, and interpreting that to mean that the task needs to run as soon
>> as possible.
>
> Sure. And that's exactly what we want (well, actually we'd like to
> ensure we have networking, but I don't think we have a usable solution
> for that [which also works at resume]).

I don't understand why you would ever want this run "as soon as
possible".  Can you explain why you consider it a _priority_ task
under some circumstances?

>> I think you're saying this because what you _really_ don't want is for
>> the task to be run _more_ than once daily.  If the computer is
>> rebooted several times within a day, it shouldn't get run each time.
>> Is that right?
>
> I think so, yes. I have days I reboot a lot, I would not want to
> have my service run every time I boot.

This makes sense.

> I want to run the service as soon as possible if the timer elapsed
> and there is connectivity. The reason is simple: By the time I login,
> I want the service to be done.

... This doesn't.  Why do you care about that?

> IMO: It's kind of ridiculous to care about boot speed and use a hard disk
> at the same time, so I always fail to see the point in that. SSDs are priced
> acceptable now, and the boot performance increase is 6 times or more, so
> I don't really care if you take 1 minute or 2 minute to boot if you could
> boot in 10 seconds just by switching to appropriate hardware.

... Huh, I had thought SSDs were still US$1/GB, but they're less than
half that now.

They are still a nontrivial expense and, since we're talking about
replacing the boot drive, a nontrivial upgrade job, I don't think it's
fair to say that software changes to improve boot performance are
unnecessary because "you can just switch to appropriate hardware."

> So, let's say you have a laptop you use every day for 4 hours, and then
> suspend. With OnActiveSec, the service would run after about a week
> (-/- 3 days). With OnCalendar, it will run daily (maybe every second
> day, let's say it schedules Mon 18, Tue 14 and you boot on Mon 16-20
> and Tue 08-12. It would not run on Tuesday then, but it would immediately
> catch up on Wednesday and schedule the next run within the next
> 24 hours +/- 12).

OK, this is a really good point.  I had missed the paragraph of the
systemd.timer manpage where it says that OnActiveSec doesn't count
time in suspension.

I will talk to systemd upstream about adding timer features that would
let one express "once each _calendar_ day, at an arbitrarily chosen
point, but not immediately upon boot", and we can let this bug lie at
least till they make a decision about that.

zw

Bug#844453: apt-daily.service delays startup by more than five minutes

[Zack Weinberg]

On Mon, Mar 27, 2017 at 10:49 AM, Julian Andres Klode <j...@debian.org> wrote:
> On Mon, Mar 27, 2017 at 10:12:59AM -0400, Zack Weinberg wrote:
>>
>> I believe an appropriate fix for this bug would be to change
>> apt-daily.timer so that systemd does not attempt to run APT
>> daily background processing during boot-up, but only some time
>> afterward.
>
> The problem is that we do not really want to run it at boot.

Well, it _is_ run at boot, and in fact _blocks_ boot, so I don't see
specifying that it should run within an hour of boot and not block
anything as a step in the _wrong_ direction...

There probably are some circumstances where the current spec doesn't
cause it to be run at boot, but it does consistently run at boot when
I turn my desktop on in the mornings: I think systemd is probably
noticing that the calendar deadline expired while the computer was
off, and interpreting that to mean that the task needs to run as soon
as possible.

Maybe that's a systemd bug or at least a feature request, but it's too
late to get a feature request through for jessie...

(And see 
https://unix.stackexchange.com/questions/315502/how-to-disable-apt-daily-service-on-ubuntu-cloud-vm-image
for a case where this is not just a performance issue.)

> We might want to delay startup if systemd would start it otherwise,
> but adding a rule to always start it at a boot is a step in the
> wrong direction.

I think you're saying this because what you _really_ don't want is for
the task to be run _more_ than once daily.  If the computer is
rebooted several times within a day, it shouldn't get run each time.
Is that right?

> That said, I'm not convinced that apt's daily service significantly
> slows down a boot process, at least not on a solid state drive. Using
> a spinning disk generally conflicts with systemd's model of starting
> as much as possible in parallel

SSDs are still not the common case, and should not be optimized for at
the expense of spinning disks.  Is there a way to tell systemd to cool
it a little?

> And OnUnitActiveSec is wrong. We want to run daily (in real
> time), not after your machine was on for 24 hours

I don't understand. Once the computer has been on for 24 hours these
become the same thing.  Conversely, if the computer is not left on for
more than 24 hours at a time (the common desktop case) then it's a
matter of luck (and the user's schedule) whether the timer ever gets
to fire "naturally" while the computer is on.

Bug#844453: apt-daily.service delays startup by more than five minutes

[Zack Weinberg]

Package: apt
Version: 1.4~rc2
Followup-For: Bug #844453

I believe an appropriate fix for this bug would be to change
apt-daily.timer so that systemd does not attempt to run APT
daily background processing during boot-up, but only some time
afterward.  An appropriate configuration would be similar to the
systemd-tmpfiles-clean.timer, which runs 15 minutes after boot
and once a day thereafter.

For instance

--- apt-daily.timer.orig2017-03-27 10:07:32.697972326 -0400
+++ apt-daily.timer 2017-03-27 10:08:37.022378906 -0400
@@ -2,8 +2,9 @@
 Description=Daily apt activities
 
 [Timer]
-OnCalendar=*-*-* 6,18:00
-RandomizedDelaySec=12h
+OnBootSec=15min
+OnUnitActiveSec=1d
+RandomizedDelaySec=30min
 AccuracySec=1h
 Persistent=true
 
I have made this change in my local configuration via override file
and it appears to work well; at least, apt-daily.service is no longer
the long pole in 'systemd-analyze blame' output.

zw

Bug#158969: autoconf: AC_SYS_LARGEFILE documentation misleading

[Zack Weinberg]

On Wed, Jan 25, 2017 at 2:06 PM, Eric Blake  wrote:
>
> I also think we can try harder to point out the need for config.h to
> appear first.  How about the following counter-proposal:
...

If we're going to warn people about this in the context of specific
macros we should do the same for AC_USE_SYSTEM_EXTENSIONS as well.  I
don't *think* there are any other stock macros that put
feature-selection #defines into config.h but I could have missed
something.

zw

Bug#852617: autoconf: AC_SYS_LARGEFILE should output to CPPFLAGS

[Zack Weinberg]

On Wed, Jan 25, 2017 at 1:02 PM, Thorsten Glaser <t.gla...@tarent.de> wrote:
> On Wed, 25 Jan 2017, Zack Weinberg wrote:
>
>> As far as I can tell from the Git history, AC_SYS_LARGEFILE has
>> *always* used AC_DEFINE_UNQUOTED to define the various preprocessor
>> macros that it can define (_FILE_OFFSET_BITS, _LARGE_FILES, and
>> _DARWIN_USE_64_BIT_INODE).
>
> Interesting, as I recall seeing -D_FILE_OFFSET_BITS=64 on various
> compiler command lines when working under GNU. (I normally work
> under BSD at home, so I don’t know where exactly.)

Is it possible that those programs were not using a config.h?

>> That part of the code has been unchanged
>> since AC_SYS_LARGEFILE was added to specific.m4.
>
> Interesting, when was that? (That is, before 2.13? Anything before
> that, even I consider ancient ☻)

2000-06-08.  According to NEWS, it was not in 2.13 (which was released
1999-05-01), but it was in the very next release, 2.50 (2001-05-21).
The ChangeLog entry for the addition says "Import AC_SYS_LARGEFILE
from largefile.m4 serial 12", so that sounds like there was an add-on
.m4 file with the same functionality floating around prior to that - I
don't know where to find copies of that file.

zw

Bug#852617: autoconf: AC_SYS_LARGEFILE should output to CPPFLAGS

[Zack Weinberg]

On Wed, Jan 25, 2017 at 12:21 PM, Thorsten Glaser  wrote:
>
> Would you at least *consider* moving the definition back to some
> command line argument? (Changing severity to wishlist now; if not,
> we can likely close the bug, but I’d still like you to please at
> least consider doing the change.)

As far as I can tell from the Git history, AC_SYS_LARGEFILE has
*always* used AC_DEFINE_UNQUOTED to define the various preprocessor
macros that it can define (_FILE_OFFSET_BITS, _LARGE_FILES, and
_DARWIN_USE_64_BIT_INODE).  That part of the code has been unchanged
since AC_SYS_LARGEFILE was added to specific.m4.

I can see how you got the impression from the documentation that these
are added to CC instead, but that's actually talking about a different
thing that AC_SYS_LARGEFILE can do -- on *one* system, namely IRIX 6,
it may try adding "-n32" to CC.  As a general rule, whenever the
Autoconf manual says that something defines preprocessor macros, you
can assume that it does that with AC_DEFINE(_UNQUOTED).

You're talking about this like it's a regression.  Can you please
verify that it really was an Autoconf upgrade that broke the build of
whatever program you're having trouble with, and if so, report what
the older version was?

zw

Bug#850074: systemd: "Freezing execution" mode breaks batch upgrades

[Zack Weinberg]

On Tue, Jan 3, 2017 at 4:29 PM, Michael Biebl  wrote:
> Aha, thanks a lot for the reproducer. This helps a lot!
>
> Will forward this issue upstream. daemon-reexec should handle the case
> of a full /run more gracefully.

Thanks.  When you do that, please also mention that journald doesn't
handle full partitions gracefully either (it goes into an infinite
loop spamming log messages about how it can't save log messages) and
that when Storage=auto and /var/log/journal doesn't exist, journals
are saved to /run and never rotated!  This means that in a default
installation of unstable, if the system is left up 24x7 and there's a
user cron job that runs every five minutes, /run will be full in less
than two weeks.  (Relatedly, user cron jobs produce an awful lot of
log chatter:

Jan  3 08:45:01 kenaz CRON[27272]: () CMD ()
Jan  3 08:45:02 kenaz systemd[1]: Created slice User Slice of .
Jan  3 08:45:02 kenaz systemd[1]: systemd-timesyncd.service: Cannot
add dependency job, ignoring: Unit systemd-timesyncd.service is
masked.
Jan  3 08:45:02 kenaz systemd[1]: Starting User Manager for UID 1006...
Jan  3 08:45:02 kenaz systemd[1]: Started Session 17888 of user .
Jan  3 08:45:02 kenaz systemd[27284]: Reached target Timers.
Jan  3 08:45:02 kenaz systemd[27284]: Reached target Sockets.
Jan  3 08:45:02 kenaz systemd[27284]: Reached target Paths.
Jan  3 08:45:02 kenaz systemd[27284]: Reached target Basic System.
Jan  3 08:45:02 kenaz systemd[27284]: Reached target Default.
Jan  3 08:45:02 kenaz systemd[27284]: Startup finished in 7ms.
Jan  3 08:45:02 kenaz systemd[1]: Started User Manager for UID 1006.
Jan  3 08:45:02 kenaz systemd[1]: Stopping User Manager for UID 1006...
Jan  3 08:45:02 kenaz systemd[27284]: Reached target Shutdown.
Jan  3 08:45:02 kenaz systemd[27284]: Starting Exit the Session...
Jan  3 08:45:02 kenaz systemd[27284]: Stopped target Default.
Jan  3 08:45:02 kenaz systemd[27284]: Stopped target Basic System.
Jan  3 08:45:02 kenaz systemd[27284]: Stopped target Timers.
Jan  3 08:45:02 kenaz systemd[27284]: Stopped target Sockets.
Jan  3 08:45:02 kenaz systemd[27284]: Stopped target Paths.
Jan  3 08:45:02 kenaz systemd[27284]: Received SIGRTMIN+24 from PID
27309 (kill).
Jan  3 08:45:02 kenaz systemd[1]: Stopped User Manager for UID 1006.
Jan  3 08:45:02 kenaz systemd[1]: Removed slice User Slice of .

If you know off the top of your head how to squelch these I would love
to hear about it.)

zw

Bug#850074: systemd: "Freezing execution" mode breaks batch upgrades

[Zack Weinberg]

On Tue, Jan 3, 2017 at 3:55 PM, Michael Biebl <bi...@debian.org> wrote:
> Am 03.01.2017 um 21:41 schrieb Zack Weinberg:
>>
>> I don't expect I will be able to reproduce the situation until the
>> next time the systemd package is updated.  However, I recall this
>> happening the past several times the systemd package was updated.
>
> A "apt-get install --reinstall systemd" does not trigger the issue?

Oh, I didn't think of that.

> Hm, yes. It looks like the system (or systemd specifically) was already
> in a bad state before the daemon-reexec and the crash/freeze was a
> result of that.

Indeed.  The problem was /run being full.  Here is a reproduction recipe:

# cat /dev/zero > /run/eatspace
cat: write error: No space left on device
# df -h | grep /run
tmpfs   128M  128M 0 100% /run
# apt-get install --reinstall systemd
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 3 not upgraded.
Need to get 0 B/2,453 kB of archives.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 269661 files and directories currently installed.)
Preparing to unpack .../systemd_232-8_amd64.deb ...
Unpacking systemd (232-8) over (232-8) ...
Setting up systemd (232-8) ...
addgroup: The group `systemd-journal' already exists as a system group. Exiting.

Broadcast message from systemd-journald@kenaz (Tue 2017-01-03 16:16:42 EST):

systemd[1]: Freezing execution.


Message from syslogd@kenaz at Jan  3 16:16:42 ...
 systemd[1]: Freezing execution.
Failed to try-restart systemd-networkd.service: Connection timed out
See system logs and 'systemctl status systemd-networkd.service' for details.
Failed to try-restart systemd-resolved.service: Connection timed out
See system logs and 'systemctl status systemd-resolved.service' for details.
Failed to try-restart systemd-timesyncd.service: Connection timed out
See system logs and 'systemctl status systemd-timesyncd.service' for details.
Processing triggers for man-db (2.7.6.1-2) ...
Processing triggers for dbus (1.10.14-1) ...
Error: Timeout was reached

And I get the same "Failed to serialize state: Input/output error" in
the logs.  There is no /core file produced, though.

I don't know *why* /run was full originally, since it gets cleared on
reboot, but at a minimum I suggest that systemd.preinst should abort
the upgrade if /run is full.

zw

Bug#850074: systemd: "Freezing execution" mode breaks batch upgrades

[Zack Weinberg]

On Tue, Jan 3, 2017 at 3:19 PM, Michael Biebl  wrote:
>> An ideal fix would be for systemd to support seamless upgrades of itself,
>> i.e. pid 1 would re-exec itself using the new binary, without losing
>> any state.
>
> Well, that's actually what's already happening. In postinst we run
> systemctl daemon-reexec which will start the new binary and transfer the
> state from the old process.
>
> For some reason systemd crashed on your system before that happened.
>
> Can you reproduce the crash or do you at least have a core file from the
> crash? Do you have a complete journal log?

I don't expect I will be able to reproduce the situation until the
next time the systemd package is updated.  However, I recall this
happening the past several times the systemd package was updated.

I do not have any journal-format logs, having set Storage=none after
the incident some months ago when it filled up /run with journal
fragments.  The only things in traditional logfiles that appear to be
relevant are:

/var/log/dpkg.log ...
2017-01-03 13:58:59 upgrade systemd:amd64 232-7 232-8
2017-01-03 13:58:59 status half-configured systemd:amd64 232-7
2017-01-03 13:58:59 status unpacked systemd:amd64 232-7
2017-01-03 13:58:59 status half-installed systemd:amd64 232-7
2017-01-03 13:58:59 status triggers-pending dbus:amd64 1.10.14-1
2017-01-03 13:58:59 status triggers-pending dbus:amd64 1.10.14-1
2017-01-03 13:58:59 status half-installed systemd:amd64 232-7
2017-01-03 13:59:00 status unpacked systemd:amd64 232-8
2017-01-03 13:59:00 status unpacked systemd:amd64 232-8
2017-01-03 13:59:00 startup packages configure
2017-01-03 13:59:00 configure systemd:amd64 232-8 
2017-01-03 13:59:00 status unpacked systemd:amd64 232-8
2017-01-03 13:59:00 status unpacked systemd:amd64 232-8
2017-01-03 13:59:00 status unpacked systemd:amd64 232-8
2017-01-03 13:59:00 status unpacked systemd:amd64 232-8
2017-01-03 13:59:00 status unpacked systemd:amd64 232-8
2017-01-03 13:59:00 status unpacked systemd:amd64 232-8
2017-01-03 13:59:00 status unpacked systemd:amd64 232-8
2017-01-03 13:59:00 status unpacked systemd:amd64 232-8
2017-01-03 13:59:00 status unpacked systemd:amd64 232-8
2017-01-03 13:59:00 status unpacked systemd:amd64 232-8
2017-01-03 13:59:00 status unpacked systemd:amd64 232-8
2017-01-03 13:59:00 status unpacked systemd:amd64 232-8
2017-01-03 13:59:00 status unpacked systemd:amd64 232-8
2017-01-03 13:59:00 status unpacked systemd:amd64 232-8
2017-01-03 13:59:01 status unpacked systemd:amd64 232-8
2017-01-03 13:59:01 status unpacked systemd:amd64 232-8
2017-01-03 13:59:01 status half-configured systemd:amd64 232-8
2017-01-03 14:00:16 status installed systemd:amd64 232-8

/var/log/messages ...
Jan  3 13:57:57 kenaz systemd[1]: Reloading.
Jan  3 13:57:57 kenaz systemd[1]: Failed to reload: Input/output error
Jan  3 13:58:59 kenaz dbus[512]: [system] Reloaded configuration
Jan  3 13:58:59 kenaz dbus[512]: [system] Reloaded configuration
Jan  3 13:58:59 kenaz dbus[512]: [system] Reloaded configuration
Jan  3 13:58:59 kenaz dbus[512]: [system] Reloaded configuration
Jan  3 13:58:59 kenaz dbus[512]: [system] Reloaded configuration
Jan  3 13:58:59 kenaz dbus[512]: [system] Reloaded configuration
Jan  3 13:58:59 kenaz dbus[512]: [system] Reloaded configuration
Jan  3 13:58:59 kenaz dbus[512]: [system] Reloaded configuration
Jan  3 13:58:59 kenaz dbus[512]: [system] Reloaded configuration
Jan  3 13:59:00 kenaz dbus[512]: [system] Reloaded configuration
Jan  3 13:59:00 kenaz dbus[512]: [system] Reloaded configuration
Jan  3 13:59:00 kenaz dbus[512]: [system] Reloaded configuration
Jan  3 13:59:00 kenaz dbus[512]: [system] Reloaded configuration
Jan  3 13:59:00 kenaz dbus[512]: [system] Reloaded configuration
Jan  3 13:59:00 kenaz dbus[512]: [system] Reloaded configuration
Jan  3 13:59:00 kenaz dbus[512]: [system] Reloaded configuration
Jan  3 13:59:00 kenaz dbus[512]: [system] Reloaded configuration
Jan  3 13:59:00 kenaz dbus[512]: [system] Reloaded configuration
Jan  3 13:59:00 kenaz dbus[512]: [system] Reloaded configuration
Jan  3 13:59:01 kenaz systemd[1]: Reloading.
Jan  3 13:59:01 kenaz systemd[1]: Failed to reload: Input/output error
Jan  3 13:59:01 kenaz systemd[1]: Reloading.
Jan  3 13:59:01 kenaz systemd[1]: Failed to reload: Input/output error
Jan  3 13:59:01 kenaz systemd[1]: Reloading.
Jan  3 13:59:01 kenaz systemd[1]: Failed to reload: Input/output error
Jan  3 13:59:01 kenaz systemd[1]: Reloading.
Jan  3 13:59:01 kenaz systemd[1]: Failed to reload: Input/output error
Jan  3 13:59:01 kenaz systemd[1]: Reloading.
Jan  3 13:59:01 kenaz systemd[1]: Failed to reload: Input/output error
Jan  3 13:59:01 kenaz systemd[1]: Failed to serialize state: Input/output error
Jan  3 13:59:01 kenaz systemd[1]: Freezing execution.

So you can see that the freeze was directly triggered by the upgrade,
but there seems to have been some pre-existing problem where unit
reloads were failing.  If you can think of reasons why that would
happen 

Bug#850074: systemd: "Freezing execution" mode breaks batch upgrades

[Zack Weinberg]

Package: systemd
Version: 232-8
Severity: normal

When the systemd package is upgraded, the running instance of systemd is
likely to go into 'freezing execution' mode, in which it is unresponsive
to D-Bus requests until the computer is rebooted.  If a daemon package is
being upgraded at the same time, its postinst is therefore liable to fail,
as it will be unable to ask systemd to restart the daemon.  Here's what
this syndrome looks like in the upgrade crawl:

Extracting templates from packages: 100%
Preconfiguring packages ...
(Reading database ... 271106 files and directories currently installed.)

...
Preparing to unpack .../4-systemd_232-8_amd64.deb ...
Unpacking systemd (232-8) over (232-7) ...
Setting up systemd (232-8) ...
addgroup: The group `systemd-journal' already exists as a system group. Exiting.

Broadcast message from systemd-journald@kenaz (Tue 2017-01-03 13:59:01 EST):

systemd[1]: Freezing execution.
Failed to try-restart systemd-networkd.service: Failed to activate service 
'org.freedesktop.systemd1': timed out
See system logs and 'systemctl status systemd-networkd.service' for details.
Failed to try-restart systemd-resolved.service: Connection timed out
See system logs and 'systemctl status systemd-resolved.service' for details.
Failed to try-restart systemd-timesyncd.service: Failed to activate service 
'org.freedesktop.systemd1': timed out
See system logs and 'systemctl status systemd-timesyncd.service' for details.
(Reading database ... 271105 files and directories currently installed.)
Preparing to unpack .../0-udev_232-8_amd64.deb ...
Unpacking udev (232-8) over (232-7) ...
Failed to reload daemon: Failed to activate service 'org.freedesktop.systemd1': 
timed out

...
Preparing to unpack .../00-cups-daemon_2.2.1-4_amd64.deb ...
Failed to reload daemon: Failed to activate service 'org.freedesktop.systemd1': 
timed out
Failed to retrieve unit: Connection timed out
Failed to stop cups.service: Connection timed out
See system logs and 'systemctl status cups.service' for details.
Failed to get load state of cups.service: Failed to activate service 
'org.freedesktop.systemd1': timed out
invoke-rc.d: initscript cups, action "stop" failed.
dpkg: warning: subprocess old pre-removal script returned error exit status 1
dpkg: trying script from the new package instead ...
Failed to reload daemon: Failed to activate service 'org.freedesktop.systemd1': 
timed out
Failed to retrieve unit: Failed to activate service 'org.freedesktop.systemd1': 
timed out
Failed to stop cups.service: Connection timed out
See system logs and 'systemctl status cups.service' for details.
Failed to get load state of cups.service: Failed to activate service 
'org.freedesktop.systemd1': timed out
invoke-rc.d: initscript cups, action "stop" failed.
dpkg: error processing archive 
/tmp/apt-dpkg-install-RbqGAG/00-cups-daemon_2.2.1-4_amd64.deb (--unpack):
 subprocess new pre-removal script returned error exit status 1
Failed to reload daemon: Failed to activate service 'org.freedesktop.systemd1': 
timed out
Failed to reload daemon: Failed to activate service 'org.freedesktop.systemd1': 
timed out
Failed to retrieve unit: Connection timed out
Failed to start cups.service: Connection timed out
See system logs and 'systemctl status cups.service' for details.
invoke-rc.d: initscript cups, action "start" failed.
Failed to get properties: Connection timed out
dpkg: error while cleaning up:
 subprocess installed post-installation script returned error exit status 1

...
Errors were encountered while processing:
 /tmp/apt-dpkg-install-RbqGAG/00-cups-daemon_2.2.1-4_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

(There will usually then be a flood of additional error messages from packages
whose dependencies are broken.)

I have been able to work around this by temporarily creating an
/usr/sbin/policy-rc.d that always exits with code 101, but I shouldn't
have to do that.

An ideal fix would be for systemd to support seamless upgrades of itself,
i.e. pid 1 would re-exec itself using the new binary, without losing
any state.  I realize that if this were easy it would already have been
done.  An acceptable kludge would be for systemd, in "freezing execution"
mode, to continue _accepting_ D-Bus requests, and responding to them as
if they had been successful -- it just wouldn't actually _do_ anything.
Since the computer has to be rebooted anyway, this would not cause any
long-term problems.  (Bonus points for making sure that 'unattended-upgrades'
notices that the computer needs to be rebooted.)


-- Package-specific info:


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (501, 'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of 

Bug#740208: systemd: encountered with /dev/disk/by-uuid as well

[Zack Weinberg]

On Mon, Dec 19, 2016 at 12:33 AM Michael Biebl <bi...@debian.org> wrote:

> On Thu, 18 Sep 2014 11:46:49 -0400 Zack Weinberg <za...@panix.com> wrote:
>
> > I've just tripped over the same bug with the latest systemd.
>
> Is that still an issue on an up-to-date sid/stretch system?


I don't know, the computer no longer has that partition arrangement. I can
try to reproduce it in a VM but not till January.

zw

Bug#843532:

[Zack Weinberg]

I can now confirm that the problem I was having is solved.  I don't
use all the functionality of dnssec-trigger, though.

I would have appreciated your waiting at least another 48 hours before
assuming I had no further complaints.

zw

Bug#843532: dnssec-trigger: broken by OpenSSL 1.1.0

[Zack Weinberg]

Package: dnssec-trigger
Version: 0.13~svn685-6
Severity: critical
Justification: renders package unusable

On upgrading dnssec-trigger within unstable, the postinst fails with
errors from systemd:

Setting up dnssec-trigger (0.13~svn685-6) ...
Job for dnssec-triggerd.service failed because the control process exited with 
error code.
See "systemctl status dnssec-triggerd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript dnssec-triggerd, action "start" failed.
● dnssec-triggerd.service - Reconfigure local DNSSEC resolver on connectivity 
changes
   Loaded: loaded (/lib/systemd/system/dnssec-triggerd.service; enabled; vendor 
preset: enabled)
   Active: activating (auto-restart) (Result: exit-code) since Mon 2016-11-07 
08:25:41 EST; 3ms ago
  Process: 8425 ExecStopPost=/usr/lib/dnssec-trigger/dnssec-trigger-script 
--cleanup (code=exited, status=1/FAILURE)
  Process: 8423 ExecStartPost=/usr/lib/dnssec-trigger/dnssec-trigger-script 
--update (code=exited, status=1/FAILURE)
  Process: 8422 ExecStart=/usr/sbin/dnssec-triggerd -d (code=exited, 
status=1/FAILURE)
  Process: 8421 ExecStartPre=/usr/lib/dnssec-trigger/dnssec-trigger-script 
--prepare (code=exited, status=0/SUCCESS)
 Main PID: 8422 (code=exited, status=1/FAILURE)

Nov 07 08:25:41 moxana systemd[1]: dnssec-triggerd.service: Unit entered fa…ate.
Nov 07 08:25:41 moxana systemd[1]: dnssec-triggerd.service: Failed with res…de'.
Hint: Some lines were ellipsized, use -l to show in full.
dpkg: error processing package dnssec-trigger (--configure):
 subprocess installed post-installation script returned error exit status 1

The real error message is hiding in "journalctl -xe":

-- Unit dnssec-triggerd.service has begun starting up.
Nov 07 08:34:17 moxana dnssec-triggerd[20281]: Nov 07 08:34:17 
dnssec-triggerd[20281] error: could not set SSL_OP_NO_SSLv2 crypto 
error:
Nov 07 08:34:17 moxana dnssec-triggerd[20281]: Nov 07 08:34:17 
dnssec-triggerd[20281] error: cannot setup SSL context
Nov 07 08:34:17 moxana dnssec-triggerd[20281]: Nov 07 08:34:17 
dnssec-triggerd[20281] fatal error: could not init server
Nov 07 08:34:17 moxana systemd[1]: dnssec-triggerd.service: Main process 
exited, code=exited, status=1/FAILURE
Nov 07 08:34:17 moxana dnssec-trigger-script[20282]: Cannot connect to 
dnssec-trigger.
Nov 07 08:34:18 moxana dnssec-trigger-script[20284]: chattr: Operation not 
supported while reading flags on /etc/resolv.conf
Nov 07 08:34:18 moxana dnssec-trigger-script[20284]: Traceback (most recent 
call last):
Nov 07 08:34:18 moxana dnssec-trigger-script[20284]:   File 
"/usr/lib/dnssec-trigger/dnssec-trigger-script", line 465, in 
Nov 07 08:34:18 moxana dnssec-trigger-script[20284]: 
Application(sys.argv).run()
Nov 07 08:34:18 moxana dnssec-trigger-script[20284]:   File 
"/usr/lib/dnssec-trigger/dnssec-trigger-script", line 364, in run
Nov 07 08:34:18 moxana dnssec-trigger-script[20284]: self.method()
Nov 07 08:34:18 moxana dnssec-trigger-script[20284]:   File 
"/usr/lib/dnssec-trigger/dnssec-trigger-script", line 398, in run_cleanup
Nov 07 08:34:18 moxana dnssec-trigger-script[20284]: 
subprocess.check_call(["chattr", "-i", "/etc/resolv.conf"])
Nov 07 08:34:18 moxana dnssec-trigger-script[20284]:   File 
"/usr/lib/python2.7/subprocess.py", line 186, in check_call
Nov 07 08:34:18 moxana dnssec-trigger-script[20284]: raise 
CalledProcessError(retcode, cmd)
Nov 07 08:34:18 moxana dnssec-trigger-script[20284]: 
subprocess.CalledProcessError: Command '['chattr', '-i', '/etc/resolv.conf']' 
returned non-
Nov 07 08:34:18 moxana systemd[1]: Failed to start Reconfigure local DNSSEC 
resolver on connectivity changes.
-- Subject: Unit dnssec-triggerd.service has failed

I get the same SSL-related errors upon attempting to start dnssec-triggerd 
manually:

# dnssec-triggerd -d -v
Nov 07 08:37:21 dnssec-triggerd[20314] debug: event mini-event-0.13 uses 
not_obtainable method.
Nov 07 08:37:21 dnssec-triggerd[20314] error: could not set SSL_OP_NO_SSLv2 
crypto error::lib(0):func(0):reason(0)
Nov 07 08:37:21 dnssec-triggerd[20314] error: cannot setup SSL context
Nov 07 08:37:21 dnssec-triggerd[20314] fatal error: could not init server

The patch for bug #828283 appears to have been either incomplete or broken, and 
not to have been tested. >:-(

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (501, 'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dnssec-trigger depends on:
ii  gir1.2-networkmanager-1.0  1.4.2-2
ii  init-system-helpers1.46
ii  libc6  2.24-5
ii  libgdk-pixbuf2.0-0 2.36.0-1
ii  libglib2.0-0   2.50.1-1
ii  libgtk2.0-02.24.31-1
ii  libldns1  

Bug#740563: Fwd: [DSE-Dev] Bug#740563: policycoreutils: semodule -d/-e is ridiculously slow

[Zack Weinberg]

I regret to say I am no longer able to test this.

Bug#838688: update-grub: backup kernels should be sorted after new kernels

[Zack Weinberg]

Package: grub2-common
Version: 2.02~beta2-36
Severity: normal
File: /usr/sbin/update-grub

When you upgrade a packaged Debian kernel, the old kernel and initrd are
preserved under names ending with `.bak`.  update-grub should sort these
after the new kernel when generating the menu (so the default is to boot
into the new kernel).  It used to do this, but quite recently it has
started sorting the backup kernels *first*, which is wrong.  Observe:

(Reading database ... 257654 files and directories currently installed.)
Preparing to unpack .../linux-image-4.7.0-1-amd64_4.7.4-2_amd64.deb ...
Unpacking linux-image-4.7.0-1-amd64 (4.7.4-2) over (4.7.2-1+s1) ...
Setting up linux-image-4.7.0-1-amd64 (4.7.4-2) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.7.0-1-amd64
/etc/kernel/postinst.d/zz-update-grub:
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-4.7.0-1-amd64.bak
Found initrd image: /boot/initrd.img-4.7.0-1-amd64.bak
Found linux image: /boot/vmlinuz-4.7.0-1-amd64
Found initrd image: /boot/initrd.img-4.7.0-1-amd64
Adding boot menu entry for EFI firmware configuration
done

And you will see in the grub.cfg below that the default kernel is
/boot/vmlinuz-4.7.0-1-amd64.bak instead of vmlinuz-4.7.0-1-amd64.

(Note: My configuration is slightly weird in that the EFI partition
is mounted at /boot, not /boot/EFI.)

zw

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/sda2 / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
/dev/sda1 /boot vfat 
rw,relatime,fmask=0033,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,tz=UTC,errors=remount-ro
 0 0
/dev/bcache0 /home xfs 
rw,nosuid,nodev,relatime,attr2,inode64,sunit=1024,swidth=3072,noquota 0 0
/dev/bcache0 /var xfs 
rw,nosuid,nodev,relatime,attr2,inode64,sunit=1024,swidth=3072,noquota 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/disk/by-id/ata-CT120BX100SSD1_1511F00440EA
(hd1)   /dev/disk/by-id/ata-TOSHIBA_DT01ACA300_256D4LUGS
(hd2)   /dev/disk/by-id/ata-TOSHIBA_DT01ACA300_256D4NPGS
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 --hint='hd0,gpt2'  
33486f1a-7abf-4d96-8a1f-8194594f6a92
else
  search --no-floppy --fs-uuid --set=root 33486f1a-7abf-4d96-8a1f-8194594f6a92
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 --hint='hd0,gpt2'  
33486f1a-7abf-4d96-8a1f-8194594f6a92
else
  search --no-floppy --fs-uuid --set=root 33486f1a-7abf-4d96-8a1f-8194594f6a92
fi
insmod png
if background_image /usr/share/images/desktop-base/lines-grub-1920x1080.png; 
then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN 

Bug#826246: deja-dup: progress details pane does not stretch vertically when window is resized

[Zack Weinberg]

Package: deja-dup
Version: 34.2-1
Severity: minor

The "details" pane of the deja-dup progress monitor window doesn't stretch
vertically when the window is resized vertically.  Please see the attached
screenshot.  I think this broke with gtk 3.20.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (501, 'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.5.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages deja-dup depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-1
ii  duplicity0.7.07.1-1
ii  libatk1.0-0  2.20.0-1
ii  libc62.22-9
ii  libcairo-gobject21.14.6-1+b1
ii  libcairo21.14.6-1+b1
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libgirepository-1.0-11.48.0-2
ii  libglib2.0-0 2.48.1-1
ii  libgtk-3-0   3.20.5-4
ii  libnautilus-extension1a  3.20.1-2
ii  libnotify4   0.7.6-2
ii  libpackagekit-glib2-18   1.1.1-1
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1
ii  libpeas-1.0-01.18.0-2
ii  libsecret-1-00.18.5-1
ii  libsqlite3-0 3.13.0-1

Versions of packages deja-dup recommends:
ii  gvfs-backends1.28.2-1
ii  openssh-client [ssh-client]  1:7.2p2-5
ii  python-boto  2.40.0-1
ii  python-cloudfiles1.7.11-3

Versions of packages deja-dup suggests:
pn  python-swiftclient  

-- no debconf information

Bug#819731: r-cran-hdf5: crash on loading hdf objects with empty TITLE attribute

[Zack Weinberg]

On Fri, Apr 1, 2016 at 2:12 PM, Dirk Eddelbuettel  wrote:
> Only thing to add is that IIRC the BioConductor folks also have a package for
> R + hdf5:
>
>http://bioconductor.org/packages/release/bioc/html/rhdf5.html
>
> I am not a user of HDF5 so not sure if this is preferable over h5.

I am the wrong person to ask; I don't need to do anything
_complicated_ with HDF5, nor am I much of an R programmer.

zw

Bug#819731: r-cran-hdf5: crash on loading hdf objects with empty TITLE attribute

[Zack Weinberg]

On Fri, Apr 1, 2016 at 11:30 AM, Dirk Eddelbuettel  wrote:
>
> Sadly this package is not longer maintained upstream:
>
>   https://cloud.r-project.org/web/packages/hdf5/index.html
>
> Somehow R never had real good support for HDF5 files--maybe the newer h5
> package could be an alternative?
>
>   https://cloud.r-project.org/web/packages/h5/index.html

Yeah, I noticed that too.  But a crasher seemed worth putting on the
record even for something that's dead upstream.

I also filed RFP bug #819735 for h5.  It looks like the only rdepends
for r-cran-hdf5 is the science-statistics metapackage; probably they
would be willing to switch over to h5?

zw

Bug#819735: RFP: r-cran-h5 -- S4-based interface to the HDF5 library for binary data storage

[Zack Weinberg]

Package: wnpp
Severity: wishlist

Debian has a package 'r-cran-hdf5' which provides a basic interface to
libhdf5, but it appears to have been abandoned upstream, and is no longer
available on CRAN.  This would make a suitable replacement.

The long description below has been copied verbatim from the upstream
website.

* Package name: r-cran-h5
  Version : 0.9.5
  Upstream Author : Mario Annau 
* URL : http://h5.predictingdaemon.com/
* License : BSD (2-clause)
  Programming Lang: R, C++
  Description : S4-based interface to the HDF5 library for binary data 
storage

h5 is an R interface to the HDF5 library under active development. It is
available on Github and already released on CRAN for all major platforms
(Windows, OS X, Linux). Online documentation for the package is available
at http://h5.predictingdaemon.com.

HDF5 is an excellent library and data model to store huge amounts of data
in a binary file format. Supporting most major platforms and programming
languages it can be used to exchange data files in a language independent
format. Compared to R's integrated save() and load() functions it also
supports access to only parts of the binary data files and can therefore
be used to process data not fitting into memory.

h5 utilizes the HDF5 C++ API through Rcpp and S4 classes. 

Bug#819731: r-cran-hdf5: crash on loading hdf objects with empty TITLE attribute

[Zack Weinberg]

Package: r-cran-hdf5
Version: 1.6.10-3+b2
Severity: normal

Attached to this bugreport are two HDF5 files named 'title.hdf' and
'no-title.hdf', and the Python script that generated them (using pytables).
According to h5dump, the only difference between the two is

--- title.hdf
+++ no-title.hdf
...
   ATTRIBUTE "TITLE" {
  DATATYPE  H5T_STRING {
 STRSIZE 1;
 STRPAD H5T_STR_NULLTERM;
 CSET H5T_CSET_UTF8;
 CTYPE H5T_C_S1;
  }
- DATASPACE  SCALAR
+ DATASPACE  NULL
  DATA {
- (0): "M"
  }
   }

Calling hdf5load() on 'title.hdf' works fine, but calling it on
'no-title.hdf' crashes the R interpreter.

(gdb) r
Starting program: /usr/lib/R/bin/exec/R 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

R version 3.2.4 Revised (2016-03-16 r70336) -- "Very Secure Dishes"
Copyright (C) 2016 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> library(hdf5)
> hdf5load('no-title.hdf', verbosity=99)
hdf5_global_verbosity=99 load=1
Processing object: M .. its a dataset...Dataset has ID83886080
Dataset has tid 50331742
Dataset has space id 67108866
Dataset has rank 1
Dataset has dims/maxdims: 1 / 1 
Allocating vector with rank=1 dim=1
calling vector_io. Hangs here with big datsets
in vector_io: rank=1
in vector_io:size 0 = 1 into n_elements..=1
 Setting buffer size in plist
About to read with bufsize = 8
 Done read
in vector_io: permuting
in vector_io: tidying
Phew. Done it. calling iinfo->add
Rank > 1 or not VECSXP
Calling  hdf5_load_attributes 
Processing attribute 1 called CLASS
attribute CLASS has rank 0 
Rank 0 attribute treated as rank 1 size 1
Attribute is a string
in string_ref: count=1, size=5 srcbf=5
leaving string_ref
string length of new name =6
Done processing attribute CLASS
Processing attribute 2 called VERSION
attribute VERSION has rank 0 
Rank 0 attribute treated as rank 1 size 1
Attribute is a string
in string_ref: count=1, size=3 srcbf=3
leaving string_ref
string length of new name =8
Done processing attribute VERSION
Processing attribute 3 called TITLE
attribute TITLE has rank 0 
Rank 0 attribute treated as rank 1 size 1
Attribute is a string

Program received signal SIGSEGV, Segmentation fault.
0x770b606a in strlen () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x770b606a in strlen () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x77915af9 in Rf_mkChar () from /usr/lib/R/lib/libR.so
#2  0x7453148a in hdf5_process_attribute ()
   from /usr/lib/R/site-library/hdf5/libs/hdf5.so
#3  0x73130c3b in H5A_attr_iterate_table ()
   from /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.10
#4  0x732000bc in H5O_attr_iterate_real ()
   from /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.10
#5  0x732007c7 in H5O_attr_iterate ()
   from /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.10
#6  0x7312e661 in H5Aiterate1 ()
   from /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.10
#7  0x7452e466 in ?? () from /usr/lib/R/site-library/hdf5/libs/hdf5.so
#8  0x7452ff9b in ?? () from /usr/lib/R/site-library/hdf5/libs/hdf5.so
#9  0x731b07ed in ?? ()
   from /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.10
#10 0x731b6449 in H5G__node_iterate ()
   from /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.10
#11 0x73135763 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.10
#12 0x73136c26 in H5B_iterate ()
   from /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.10
#13 0x731bbc4f in H5G__stab_iterate ()
   from /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.10
#14 0x731b8d90 in H5G__obj_iterate ()
   from /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.10
#15 0x731b17e8 in H5G_iterate ()
   from /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.10
#16 0x731ae4fa in H5Giterate ()
   from /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.10
#17 0x74531cdf in do_hdf5load ()
   from /usr/lib/R/site-library/hdf5/libs/hdf5.so
#18 0x778f7331 in ?? () from /usr/lib/R/lib/libR.so
#19 0x7792f7af in Rf_eval () from /usr/lib/R/lib/libR.so
#20 0x77931ca8 in ?? () from /usr/lib/R/lib/libR.so
#21 0x7792f5a1 in Rf_eval () from /usr/lib/R/lib/libR.so
#22 0x77930c65 in Rf_applyClosure () from /usr/lib/R/lib/libR.so
#23 0x7792f37d in Rf_eval 

Bug#814240: systemd triggers break upgrades within unstable

[Zack Weinberg]

On Mon, Feb 29, 2016 at 12:18 PM, Manuel A. Fernandez Montecelo wrote:
>
>> DPkg::NoTriggers "true";
>> DPkg::ConfigurePending "true";
>> DPkg::TriggersPending "true";
>
>
> After talking about this bug a few days ago with APT Deities (David
> Kalnischkies, in this case), he told me that apt doesn't use "dpkg
> --triggers-only" by default.
>
> He believes that apt /could/ issue that command when
> "DPkg::TriggersPending" or "DPkg::ConfigurePending" are enabled, and
> possibly other similar ones (he didn't mention the specifics).
>
> Such options as marked as experimental and dangerous (man apt.conf) so
> maybe they are better left disabled unless there's a specific need to
> use them.

On the system with the problem, that setting comes from a file named
/etc/apt/apt.conf.d/triggers, whose entire contents are

# cat /etc/apt/apt.conf.d/triggers
DPkg::NoTriggers "true";
PackageManager::Configure "smart";
DPkg::ConfigurePending "true";
DPkg::TriggersPending "true";

It was last modified in 2011.  I have no memory of having created this
file, but it doesn't belong to any package either.  Searching the 'net
for that combination of options brings me to
https://raphaelhertzog.com/2011/05/30/trying-to-make-dpkg-triggers-more-useful-and-less-painful/
and bug #626599.  It is probable that I saw Raphael's blog post go by
and decided to try it out.

I have another computer that runs unstable, and which had not yet
received the systemd 229-2 update; I verified that it does *not* have
any of these settings and then ran the update.  It went through with
no problems.

So that's a pretty strong indicator that this non-default mode is the
cause of the problem.  And it's corroborated by the dpkg/apt logs on
the computer that didn't have these settings, which show no sign of
the problem in the past, as far as I can tell.  But just to make sure,
I would like to leave this bug open until another systemd update comes
along and I can confirm that disabling these settings addresses the
problem on the computer that definitely did have it.

zw

Bug#814240: systemd triggers break upgrades within unstable

[Zack Weinberg]

Control: found -1 aptitude/0.7.5-3

On Mon, Feb 15, 2016 at 8:41 AM, Michael Biebl  wrote:
>
> Zack, I guess the aptitude maintainers will want to know which aptitude
> version you are using.

I know I've seen this with the version currently in unstable, which is
0.7.5-3. It seems likely to affect older versions as well, though.
Complete output of /usr/share/bug/aptitude is appended.

zw


$ sh /usr/share/bug/aptitude 3>&1
Terminal: xterm-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.7.5
Compiler: g++ 5.3.1 20151207
Compiled against:
  apt version 5.0.0
  NCurses version 6.0
  libsigc++ version: 2.6.2
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.0.20151024
  cwidget version: 0.5.17
  Apt version: 5.0.0

aptitude linkage:
linux-vdso.so.1 (0x7fff7e677000)
libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
(0x7f0e19941000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5
(0x7f0e19711000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7f0e194e6000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0
(0x7f0e192e)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3
(0x7f0e18fe3000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
(0x7f0e18d0c000)
libboost_iostreams.so.1.58.0 =>
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.58.0
(0x7f0e18af2000)
libboost_filesystem.so.1.58.0 =>
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.58.0
(0x7f0e188d9000)
libboost_system.so.1.58.0 =>
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.58.0
(0x7f0e186d4000)
libxapian.so.22 => /usr/lib/x86_64-linux-gnu/libxapian.so.22
(0x7f0e182d)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f0e180b3000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x7f0e17d37000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f0e17a32000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f0e1781c000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f0e17477000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f0e17274000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f0e1707)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7f0e16e58000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f0e16c3d000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7f0e16a2d000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f0e16809000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x7f0e165f7000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f0e163ee000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f0e161e9000)
/lib64/ld-linux-x86-64.so.2 (0x55ae6e5e4000)

Bug#814240: systemd triggers break upgrades within unstable

[Zack Weinberg]

Package: systemd
Version: 228-6
Severity: normal

libpam-systemd, systemd, and libsystemd0 have = dependencies on each
other.  This invariant can be temporarily violated in the middle of a
large upgrade, and AIUI that is normal and to be expected.  However,
systemd has several dpkg triggers that can fire while the = dependencies
are violated, and when this happens, the entire upgrade bombs out.
Worse, one of those triggers seems to be armed and immediately fired *by
upgrading libsystemd0*, before dpkg has had a chance to upgrade systemd
proper, so this is guaranteed to happen any time the systemd packages
are upgraded.

It's possible to recover by manually installing the new versions of
libpam-systemd, systemd, and libsystemd0, but there's got to be some
way to make apt do the Right Thing, right?  (I don't really understand
triggers.  I thought they were supposed to postpone work until the *end*
of a large upgrade, but they seem to go off all the time in the middle.)

Example upgrade transcript:

# aptitude safe-upgrade
[...]
Extracting templates from packages: 100%
Preconfiguring packages ...
[...snip...]
(Reading database ... 289818 files and directories currently installed.)
Preparing to unpack .../linux-image-4.3.0-1-amd64_4.3.5-1_amd64.deb ...
Unpacking linux-image-4.3.0-1-amd64 (4.3.5-1) over (4.3.3-7) ...
Preparing to unpack .../archives/udev_228-6_amd64.deb ...
Unpacking udev (228-6) over (228-5) ...
Preparing to unpack .../libpam-systemd_228-6_amd64.deb ...
Unpacking libpam-systemd:amd64 (228-6) over (228-5) ...
Preparing to unpack .../libsystemd0_228-6_amd64.deb ...
Unpacking libsystemd0:amd64 (228-6) over (228-5) ...
Setting up libsystemd0:amd64 (228-6) ...
Processing triggers for libc-bin (2.21-7) ...
dpkg: dependency problems prevent processing triggers for systemd:
 systemd depends on libsystemd0 (= 228-5); however:
  Version of libsystemd0:amd64 on system is 228-6.

dpkg: error processing package systemd (--triggers-only):
 dependency problems - leaving triggers unprocessed
Processing triggers for man-db (2.7.5-1) ...
Errors were encountered while processing:
 systemd
E: Sub-process /usr/bin/dpkg returned an error code (1)
Failed to perform requested operation on package.  Trying to recover:
Setting up libquadmath0:amd64 (5.3.1-8) ...
Setting up linux-image-4.3.0-1-amd64 (4.3.5-1) ...
[...snip...]
Setting up libobjc4:amd64 (5.3.1-8) ...
dpkg: dependency problems prevent configuration of libpam-systemd:amd64:
 libpam-systemd:amd64 depends on systemd (= 228-6); however:
  Version of systemd on system is 228-5.

dpkg: error processing package libpam-systemd:amd64 (--configure):
 dependency problems - leaving unconfigured
Setting up libx32gcc1 (1:5.3.1-8) ...
[...snip...]
Setting up udev (228-6) ...
addgroup: The group `input' already exists as a system group. Exiting.
update-initramfs: deferring update (trigger activated)
dpkg: dependency problems prevent processing triggers for systemd:
 systemd depends on libsystemd0 (= 228-5); however:
  Version of libsystemd0:amd64 on system is 228-6.

dpkg: error processing package systemd (--configure):
 dependency problems - leaving triggers unprocessed
Setting up libx32asan2 (5.3.1-8) ...
[..snip...]
Processing triggers for libc-bin (2.21-7) ...
Processing triggers for initramfs-tools (0.122) ...
update-initramfs: Generating /boot/initrd.img-4.3.0-1-amd64
Errors were encountered while processing:
 libpam-systemd:amd64
 systemd
Press Return to continue.

# aptitude safe-upgrade
Performing actions...
Reading changelogs... Done
Extracting templates from packages: 100%
Preconfiguring packages ...
(Reading database ... 289818 files and directories currently installed.)
Preparing to unpack .../acl_2.2.52-3_amd64.deb ...
Unpacking acl (2.2.52-3) over (2.2.52-2) ...
Preparing to unpack .../libacl1_2.2.52-3_amd64.deb ...
Unpacking libacl1:amd64 (2.2.52-3) over (2.2.52-2) ...
Setting up libacl1:amd64 (2.2.52-3) ...
Processing triggers for libc-bin (2.21-7) ...
dpkg: dependency problems prevent processing triggers for systemd:
 systemd depends on libsystemd0 (= 228-5); however:
  Version of libsystemd0:amd64 on system is 228-6.

dpkg: error processing package systemd (--triggers-only):
 dependency problems - leaving triggers unprocessed
Processing triggers for man-db (2.7.5-1) ...
Errors were encountered while processing:
 systemd
E: Sub-process /usr/bin/dpkg returned an error code (1)
Failed to perform requested operation on package.  Trying to recover:
dpkg: dependency problems prevent configuration of libpam-systemd:amd64:
 libpam-systemd:amd64 depends on systemd (= 228-6); however:
  Version of systemd on system is 228-5.

dpkg: error processing package libpam-systemd:amd64 (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent processing triggers for systemd:
 systemd depends on libsystemd0 (= 228-5); however:
  Version of libsystemd0:amd64 on system is 228-6.

dpkg: error processing package systemd (--configure):
 

Bug#814240: systemd triggers break upgrades within unstable

[Zack Weinberg]

On Tue, Feb 9, 2016 at 9:46 AM, Michael Biebl  wrote:
>>
>> It's possible to recover by manually installing the new versions of
>> libpam-systemd, systemd, and libsystemd0, but there's got to be some
>> way to make apt do the Right Thing, right?  (I don't really understand
>> triggers.  I thought they were supposed to postpone work until the *end*
>> of a large upgrade, but they seem to go off all the time in the middle.)
>>
>
> This looks like something which needs to be fixed in either dpkg or
> aptitude.
>
> Fwiw, I've never seen such a problem using apt.

I do not have either the time or the skills to dig into this any
further, but I suggest you reassign the bug to dpkg and maybe they can
do something with it?

zw

Bug#808789: phantomjs: FTBFS in several architectures (patch)

[Zack Weinberg]

On Tue, Dec 22, 2015 at 6:43 PM, Mattia Rizzolo  wrote:
> oh, dear upstream maintainer, I just submitted a debian bug to
> phantomjs, and I'd welcome a quick word from you in
> https://bugs.debian.org/808789 :)

As I said in #795719, Debian should not attempt to package PhantomJS at all.

zw

Bug#807858: quodlibet: "Saving the songs you changed" window immobile & obscures other programs

[Zack Weinberg]

Package: quodlibet
Version: 3.5.1-2
Severity: normal

Writing tags back to music files can be very slow, particularly to a
network filesystem, and blocks the UI; quodlibet sensibly puts up a
progress bar.  However, the progress bar is implemented as a dialog box
that isn't attached to the application window, can't be moved, doesn't
go away when quodlibet is minimized, and insists on being on top of all
other windows.  This means it's difficult to do something else with the
computer while waiting for it to finish.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (501, 'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages quodlibet depends on:
ii  exfalso 3.5.1-2
ii  gir1.2-gst-plugins-base-1.0 1.6.1-1
ii  gir1.2-gstreamer-1.01.6.1-1
ii  gstreamer1.0-plugins-bad [gstreamer1.0-audiosink]   1.6.1-1+b1
ii  gstreamer1.0-plugins-base   1.6.1-1
ii  gstreamer1.0-plugins-good [gstreamer1.0-audiosink]  1.6.1-1
ii  gstreamer1.0-plugins-ugly   1.6.1-1+b1
ii  gstreamer1.0-pulseaudio [gstreamer1.0-audiosink]1.6.1-1
ii  python  2.7.11-1

Versions of packages quodlibet recommends:
ii  gir1.2-gtksource-3.0   3.18.1-1
ii  gir1.2-keybinder-3.0   0.3.1-1
ii  gnome-shell [notification-daemon]  3.18.3-2
ii  libgpod4   0.8.3-1.1+b3
ii  media-player-info  22-2
ii  notification-daemon3.18.1-1
ii  python-dbus1.2.0-2+b4
ii  python-feedparser  5.1.3-3
ii  python-pyinotify   0.9.5-1
ii  udisks22.1.6-2

Versions of packages quodlibet suggests:
ii  gstreamer1.0-plugins-bad  1.6.1-1+b1

-- no debconf information