Bug#1068479: cynically closed by Rene Engelhard (Re: Bug#1068479: libreoffice-writer: space between paragraphs missing in spacing and indentation)

[Marvin Renich]

* José Luis González  [240407 15:00]:
> reopen 1068479
> thanks
> 
> Hi all,
> 
> Rene Engelhard seems to be a worse case even than Ricardo Mones. Take a
> look at my recent bug reports to libreoffice-writer and his replies.
> 
> In this one:
> 
> > Am 06.04.24 um 11:03 schrieb Rene Engelhard:
> > > Am 06.04.24 um 00:34 schrieb José Luis González:
> > >> The setting for spacing between paragraphs is missing in the spacing
> > >> and indentation tab of the paragraph dialog.
> > >
> > > ?
> > >
> > >  It's definitely there. Format -> Paragraph has spacing "after/before".
> 
> I meant spacing between paragraphs, not spacing after and before
> paragraphs. The report was crystal clear.
> 
> The difference, for those who didn't realize is space after paragraph
> happens always, and between only between them, being the regular
> separation between paragraphs (the other is formatting, and isn't
> useful as a substitute because it adds something undesirable at the end
> of the document or between paragraphs and other kinds of block
> elements).
> 

First, please carefully consider the reply from Pierre-Elliott Bécue.
The tone of your email is way out of line.  If this is the way you
regularly communicate, I would not be surprised that Rene closes your
bug reports.

It is clear to me from your quote of Rene's response that Rene honestly
believed he was answering your question and the bug should be closed.
Politely expressing the difference between the current behavior and what
you were asking for, and at the same time reopening the bug (at a proper
severity), would have been appropriate.  It should have been done in the
bug tracker and _not_ on this list.  I've set Reply-To to the bug report
only.

I don't use libreoffice daily, but I do use it.  If this is a case that
lowriter already has a way to obtain "between" spacing, but it is just
not in the proper dialog box, then this is a "normal" bug at most,
possibly "minor".  However, I don't believe lowriter ever had such a
feature.  If this is the case, the severity is "wishlist", and not
higher.  (If it does have this feature, I would personally be interested
in how to do it!)

In no way would I consider this an "important" bug, and absolutely not
"serious" or RC.

All missing or not-yet-implemented features might be considered to have
a "major effect on usability" by someone, but in almost all cases, such
a feature request is still only a "wishlist" bug.  Please don't confuse
the difference between how you would like the software to behave and how
it is currently designed to behave as being anything more than a feature
request, regardless of how important you believe the feature is.

...Marvin

Bug#1054883: recognize .m3u8 as playlist (use mp3 icon like .m3u)

[Marvin Renich]

Package: xfe
Version: 1.43.2-3
Severity: wishlist

[also seen in 1.45-2]

Files with extension .m3u8 are UTF-8 encoded .m3u files.  It would be
nice if these files used the same icon as .m3u files.

...Marvin

Bug#1052562: ITP: eza -- Modern replacement for ls

[Marvin Renich]

* Sylvestre Ledru  [230924 15:57]:
> Package: wnpp
> Severity: wishlist
> Owner: Sylvestre Ledru 
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name: eza
> * URL : https://github.com/eza-community/eza
> * License : MIT
> 
> it is a replacement of exa (dead upstream).
> it will break/replace it.

Why?  If they are not co-installable, this is the correct dependency.

Also, if you are the maintainer of the old package, and you are planning
to remove the old package after the next release, and are doing this to
automatically upgrade users from the old package to the new package,
then this, as well as the rest of the advice at
https://wiki.debian.org/RenamingPackages, is appropriate.

However, just because eza is the _logical_ replacement for a
dead-upstream package is not a reason for it to have a Debian package
dependency forcing the removal of the old package when installing the
new.

If they are co-installable, and the removal of the old package is not
imminent, I would simply coordinate with the maintainer of the old
package (if he/she is amenable), and when yours is uploaded, add a
sentence to the bottom of the old package description stating that the
package is obsolete and naming your package as the preferred, actively
maintained replacement.  Also add a NEWS entry with that info in the old
package.

...Marvin

Bug#1051250: ITP: hyfetch -- A system info script...

[Marvin Renich]

Your short description is way too long and only three words in it are
useful:  "system info script".  Those three words by themselves do not
really give a good idea what the package does.

The neofetch package description (short and long) is much better; you
should model yours from it, adding the bits about being a fork of
Neofetch and integration with other tools in the long description.
Describe _what_ your package does first, then if room allows, add where
it came from.

It is definitely useful, in the long description, to describe how it
differs from the project that it forked.  I wouldn't take that out, just
reorder things a bit, possibly rewording it as necessary.  Write your
description as if the reader may not know what Neofetch does.  Something
like:

  HyFetch is a command line script to display information about your
  Linux system, such as  It is a fork of Neofetch, and adds pride
  flag coloration.

  It can also integrate

It is also not clear (and possibly not relevant?) what the difference is
between "started as a fork" and "now also maintains".  Did upstream for
hyfetch take over the neofetch github repo?  You might want to just
leave out the second part, or at least reword it to be more clear.
Normally, a fork of a now-defunct project is just called a fork, unless
there was some official transfer of the old project's assets to the new
project upstream.

...Marvin

* Bailey Kasin  [230905 02:09]:
> Package: wnpp
> Severity: wishlist
> Owner: Bailey Kasin 
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name: hyfetch
>   Version : 1.4.10
>   Upstream Contact: Azalea Gui 
> * URL : https://github.com/hykilpikonna/hyfetch
> * License : MIT
>   Programming Lang: Python
>   Description : A system info script built off of Neofetch, continuing 
> development of the original project and adding new functionality
> 
> HyFetch started as a fork of Neofetch to add pride flag
> colorations, and now also maintains Neofetch as that
> project seems to be abandoned. The standard, updated
> Neofetch script gets installed as Neowofetch to avoid
> name collisions.
> 
> It can also integrate with tools such as Fastfetch and
> qwqfetch, to act as a frontend for them adding the same
> features it adds for Neofetch.
> 
>  - This package is relevant because it is useful on it's
>own, and also replaces an abandoned project.
> 
>  - I contribute to the project and can handling packaging
>on my own, though I believe this package falls under
>the Debian Python Team umbrella and I have applied to
>that team to maintain it there. (I am rather unfamiliar
>with this process as this is the first package I have
>tried to submit). I believe that also means that I do
>need a sponsor.
> 

Bug#1050005: ITP: pdftopng -- Convert PDF to PNG

[Marvin Renich]

* Elena Grandi  [230818 05:27]:
> Package: wnpp
> Severity: wishlist
> Owner: Elena Grandi 
> 
> * Package name: pdftopng
>   Description : Convert PDF to PNG
> 
> A command line tool and python library to convert PDFs to PNGs, based on
> pdftoppm from poppler.
> 
> This is a dependency of camelot-py (#1049944) and I intend to maintain
> it in the Python Team.

Does pdftocairo from the poppler-utils package do what you need?  If
not, would it make sense to submit patches to add pdftopng to the
poppler-utils package instead of creating a separate package for it?

Just a suggestion.

...Marvin

Bug#801065: Documenting how to not fail postinst on service fails to start

[Marvin Renich]

* Steve Langasek  [230214 13:09]:
> On Mon, Feb 13, 2023 at 09:03:34AM -0500, Marvin Renich wrote:
> > * Steve Langasek  [230212 00:03]:
> > > FWIW I think that it's the wrong thing to do if the "circumstances" 
> > > include
> > > reverse-dependencies on the package which expect to interact with the
> > > service the package provides, as these packages may themselves do such
> > > interaction in the maintainer script, resulting in cascading damage.
> 
> > > And the decision for whether there are reverse-dependencies on your 
> > > package
> > > is non-local and asynchronous.
> 
> > > Therefore I think it's always wrong for a package's postinst to exit 0 if:
> 
> > >  - it ships a service,
> > >  - it is a new install or an upgrade on a system where the service was
> > >previously started successfully, and
> > >  - the service fails to start in the postinst.
> 
> > I have to strongly disagree with this.  Suppose package A ships a
> > service, and package B depends on A and requires A's service to be
> > running in order for package B to be useful.  If I install A and disable
> > its service, and then install B, I would be very disappointed if B's
> > postinst script failed and left B in what dpkg considers an unconfigured
> > state.
> 
> > Succeeding the install and requiring the user to manually run some
> > documented configuration steps is _so_ much more user friendly than
> > leaving a broken package (from dpkg's POV).  I intentionally disabled A,
> > so when I want to use B, I will take the necessary steps.  I would
> > expect that attempting to use B without completing the configuration
> > would produce a useful error message.
> 
> Up until now the conversation has been about the semantics of exit codes for
> package A's maintainer script.
> 
> You are now arguing that a package *B* is not allowed to fail on install if
> the conditions for its full configuration have not been met.
> 
> And I absolutely disagree!  Your rationale that it's user-unfriendly to
> leave a package in an unconfigured state, if followed to its logical
> conclusion, applies to *any* package.  We might as well not care about
> postinst exit codes at all!

You are right, I went off on a tangent.  I agree that if a package
installation script is unable to leave the package's own configuration
in a "usable" state (barring explicit misconfiguration prior to upgrade
by the sysadmin), that it should fail.

The condition in the original bug report was that the problem that
prevented the service from starting or restarting was orthogonal to
anything the installation script was doing.  In that case, the
installation script will leave the filesystem in an identical state
regardless of whether starting the service succeeds or fails.  The
package is installed and perfectly usable if and when the outside
condition, unrelated to the package installation, is fixed.

In these cases, there is nothing more that the installation scripts can
or should do, so there is no need to leave the package in a dpkg
half-configured state.

I think the real problem is that the ideas of "configured" and "running"
have been conflated specifically for services.  The same type of issue
with a user program would not cause a failure of installation.

The part of your message that I disagree with is

> > >  - the service fails to start in the postinst.

This implies that "the service is running" is part of "the service is
configured", which is where I disagree.

...Marvin

Bug#801065: Documenting how to not fail postinst on service fails to start

[Marvin Renich]

* Steve Langasek  [230212 00:03]:
> FWIW I think that it's the wrong thing to do if the "circumstances" include
> reverse-dependencies on the package which expect to interact with the
> service the package provides, as these packages may themselves do such
> interaction in the maintainer script, resulting in cascading damage.
> 
> And the decision for whether there are reverse-dependencies on your package
> is non-local and asynchronous.
> 
> Therefore I think it's always wrong for a package's postinst to exit 0 if:
> 
>  - it ships a service,
>  - it is a new install or an upgrade on a system where the service was
>previously started successfully, and
>  - the service fails to start in the postinst.

I have to strongly disagree with this.  Suppose package A ships a
service, and package B depends on A and requires A's service to be
running in order for package B to be useful.  If I install A and disable
its service, and then install B, I would be very disappointed if B's
postinst script failed and left B in what dpkg considers an unconfigured
state.

Succeeding the install and requiring the user to manually run some
documented configuration steps is _so_ much more user friendly than
leaving a broken package (from dpkg's POV).  I intentionally disabled A,
so when I want to use B, I will take the necessary steps.  I would
expect that attempting to use B without completing the configuration
would produce a useful error message.

Package relationships and the idea of "properly configured" have gotten
much more complex (in a relatively small set of packages) since early
Debian days.  Packages whose configuration has complex requirements
should be installable without complete configuration and should be
resilient and provide good user feedback when run before being properly
set up.

I also think that such packages are the exception, rather than the rule,
and they are usually being administered by people capable of dealing
with postponing the configuration step.

...Marvin

Bug#801065: consent unclear

[Marvin Renich]

* Holger Levsen  [230208 08:15]:
> control: tags -1 +moreinfo
> thanks
> 
> hi,
> 
> I don't think there has been consent on the issue, thus I'm tagging it
> moreinfo.
> 
> I'm also wondering whether to mark this bug as wontfix (until there is
> consent) or to reassign to debian-policy or simply to close it.

I disagree.  Re-reading the messages to the bug report, We have
"strongly support" from Sam Hartman, and "also in favor" from Russ
Allbery and Bill Allombert.

The only objection was from Henrique de Moraes Holschuh based on lack of
risk assessment from the mistaken impression that what was being
proposed was a change to dh that would _automatically_ change existing
behavior of all dh-using packages.

What is being proposed in this bug is simply a change to the Developers
Reference to encourage package maintainers to allow dpkg installation to
succeed even if the service fails to start, unless the package
maintainer has a specific reason to do otherwise.

The bug report appears to me to have reached an overwhelming consensus
in favor.

...Marvin

Bug#1023460: in debian/nslcd.config, guess_ldap_uri returns the IP address instead of the name of the server

[Marvin Renich]

* Arthur de Jong  [221204 09:42]:
> On Fri, 2022-11-04 at 11:00 -0400, Marvin Renich wrote:
> > When nslcd is installed [...] guess_ldap_uri tries to find an
> > appropriate ldap server using some heuristics.  If it finds a host
> > [...] it returns the IP address of the host rather than the name.
> 
> The original reason for this was that if you use LDAP for host name
> lookups having a host name in nslcd.conf causes problems.
> 
> I think that is reasonably uncommon and agree that the host name would
> make more sense to provide as a suggestion. This behaviour will be
> changed in the next upload (uploads are not very frequent).
> 
> Thanks,

Thank you!

...Marvin

Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]

[Marvin Renich]

* Marvin Renich  [221115 12:57]:
> TEMPDIR, on the other hand, is for _specific_ cases, and can have
  ^ et al

Of course, that should be TMPDIR, not TEMPDIR.  Apologies.

...Marvin

Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]

[Marvin Renich]

* Robie Basak  [221113 14:15]:
> On Sun, Nov 13, 2022 at 05:46:00PM +0100, Marco d'Itri wrote:
> > On Nov 13, Robie Basak  wrote:
> > 
> > > This seems inconsistent to me. Where is the expectation that TMPDIR must
> > > be unset if dropping privileges coming from? Obviously for users of
> > Where is the expectation that $TMPDIR is writable by any user but the 
> > current one?
> > I do not believe that it is expected that if a user creates a directory 
> > and points $TMPDIR to it then they also have to make it sticky, so this 
> > has nothing to do with libpam-tmpdir.
> 
> I understand the traditional semantics of TMPDIR to be exactly the same
> as /tmp. So that includes the sticky bit, or at least behaviour that is
> equivalent under all circumstances. Or, alternatively, that someone who
> sets TMPDIR without setting the sticky bit is certain that it will be
> used in a way that does not rely on that.

This is an incorrect assumption and may be what is driving your
resistance to others' guidance on how to resolve these bugs.  /tmp has
world-writable, sticky-bit semantics specifically because it was
necessary in order for the system to give a single _common_ place where
all users could write temporary files, not because a temporary directory
for a given process needs those semantics.

TEMPDIR, on the other hand, is for _specific_ cases, and can have
whatever semantics are appropriate for the environment in which it is
set.  TEMPDIR is specifically for use when /tmp has properties that are
not appropriate for a process for any reason.  The inappropriate
property may be available disk space, inappropriate permissions
(privacy), or anything else.  When TEMPDIR is set, you specifically
cannot assume that it is world-writable or has a specific amount of disk
space.  Also, you cannot count on automatic cleaning of the TEMPDIR
directory, while you can with /tmp (at some indeterminate point in the
future).

I think Simon's analysis is the most thorough, well-thought-out, and
technically correct that I have seen in this thread.  His reasoning
should be used to determine how these bugs are resolved.

...Marvin

Bug#1023460: in debian/nslcd.config, guess_ldap_uri returns the IP address instead of the name of the server

[Marvin Renich]

Package: nslcd
Version: 0.9.12-3
Severity: normal

When nslcd is installed with noninteractive debconf frontend (perhaps
also interactively, I didn't check), guess_ldap_uri tries to find an
appropriate ldap server using some heuristics.  If it finds a host named
ldap, ldap.$domain, dirhost, or dirhost.$domain using getent hosts, it
returns the IP address of the host rather than the name.  This seems
wrong to me for at least two reasons.

First, a host can have multiple IP addresses.  If it does, you
definitely want to use the name rather than the IP address.

Second, even if the host has only one IP address, it seems much more
likely for the host's IP address to change (for whatever administrative
reason) than for the host to be renamed.

...Marvin

Bug#1023454: debconf-show: add --selections option to format output for debconf-set-selections

[Marvin Renich]

Package: debconf
Version: 1.5.79
Severity: wishlist

Please add an option --selections that will output "seen" questions in
the format used as input to debconf-set-selection, and an option --all
that, when used with --selections, will output all questions in that
format.  I.e.

debconf-show [--selections [--all]] packagename

Although debconf-show --selections --all packagename can be implemented
by

debconf-get-selections | grep '^packagename\t' # \t replaced by real tab

debconf is priority required and debconf-utils is optional, and
implementing the behavior without --all requires first displaying the
output from debconf-show packagename and then filtering the output of
debconf-get-selections manually.

...Marvin

Bug#1012525: gensquashfs: double free detected in tcache 2

[Marvin Renich]

Package: squashfs-tools-ng
Version: 1.1.4-1
Severity: minor

In mknode.c:fstree_mknode, if the parent directory link count is too
large, the tree_node_t that was just calloc'ed is free'd before
returning.  However, it has already been linked to the parent's children
list.  This causes a double free of that pointer when the parent is
subsequently free'd.  Also, all of the other children may not be free'd
and/or free may be called with invalid pointers, depending on whether
the just-freed memory gets reallocated and used before exit.

This is only a minor bug, because gensquashfs is about to exit with an
error, but it clutters stderr with irrelevant messages.

I didn't follow the error return path to be sure, but I think if the
call to free(n) just before errno = EMLINK is removed, everything will
get properly freed farther up the call stack.

...Marvin


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'oldstable-updates'), (500, 'stable'), (500, 
'oldstable'), (200, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.17.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
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 not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages squashfs-tools-ng depends on:
ii  libc6 2.33-7
ii  liblzma5  5.2.5-2.1
ii  liblzo2-2 2.10-2
ii  libselinux1   3.3-1+b2
ii  libsquashfs1  1.1.4-1
ii  libzstd1  1.5.2+dfsg-1
ii  zlib1g1:1.2.11.dfsg-4

squashfs-tools-ng recommends no packages.

squashfs-tools-ng suggests no packages.

-- no debconf information

Bug#1012522: gensquashfs: "creating tree node: Too many links" error message is confusing and uninformative

[Marvin Renich]

Package: squashfs-tools-ng
Version: 1.1.4-1
Severity: minor

The error text "Too many links" from EMLINK is intended to refer to the
number of hard links to an inode, but is misused in fstree_mknode
(mknode.c) to mean "directory has too many entries" (perhaps a squashfs
limit?).  This is confusing and doesn't help the user find the offending
part of the directory structure.  Reading the source code was required
to determine the real problem.

Also, the name of the offending directory is not printed, so once the
real problem is identified, finding the directory requires a little
shell scripting to be used with find -exec to get the information that
could have been printed by gensquashfs with the error message.

In fstree_from_dir.c:populate_dir where fstree_mknode is called, you
could check errno for EMLINK and print a more informative message
instead of calling perror.  I did not look at calls to fstree_mknode in
other files, but there are only a few to check; perhaps they would also
benefit from a similar fix.

Thanks...Marvin


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'oldstable-updates'), (500, 'stable'), (500, 
'oldstable'), (200, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.17.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
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 not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages squashfs-tools-ng depends on:
ii  libc6 2.33-7
ii  liblzma5  5.2.5-2.1
ii  liblzo2-2 2.10-2
ii  libselinux1   3.3-1+b2
ii  libsquashfs1  1.1.4-1
ii  libzstd1  1.5.2+dfsg-1
ii  zlib1g1:1.2.11.dfsg-4

squashfs-tools-ng recommends no packages.

squashfs-tools-ng suggests no packages.

-- no debconf information

Bug#943903: samba 2:4.11.1+dfsg-1 server breaks mount.cifs from cifs-utils 2:6.9-1

[Marvin Renich]

* Michael Tokarev  [220510 15:54]:
> Control: tag -1 + moreinfo
> 
> On Thu, 31 Oct 2019 11:53:52 -0400 Marvin Renich  wrote:
> > Package: samba
> > Version: 2:4.11.1+dfsg-1
> > Severity: normal
> > 
> > I plan to clone this bug to cifs-utils, as it is unclear which package has 
> > the bug.
> > 
> > After upgrading from samba 2:4.9.13+dfsg-1 to 2:4.11.0+dfsg-10 on a server 
> > machine, mount.cifs from cifs-utils 2:6.9-1
> > on a different machine fails to connect with "mount error(13): Permission 
> > denied".  Subsequently upgrading samba to
> > 2:4.11.1+dfsg-1 did not help.
> > 
> > Downgrading samba to stable 2:4.9.5+dfsg-5+deb10u1 on the server fixes the 
> > problem.  Adding a snapshot version to figure
> > out what needed to be downgraded to get version 2:4.9.13+dfsg-1 was deemed 
> > not worth the effort, as my daily backup on
> > the client machine (which mounts the remote cifs share) was running fine 
> > when the server had 2:4.9.13+dfsg-1.
> 
> Hi!
> 
> Is this still a problem in current bullseye version of samba (4.13) and 
> cifs-utils?
> If yes, can you please try samba version 4.16 (available in 
> bullseye-backports)?
> 
> Thank you!

I no longer have the same setup; both hardware and software configuration are
different.  For example, at the time I reported the bug, I was using 
smbldap-tools
for authentication from an LDAP server.

I tried recreating the original bug in a buster VM with the same versions of 
samba
and cifs-utils (but without all the extra stuff, like LDAP and samba acting as 
WINS
server), but could not replicate the problem.  It also does not occur in my 
current
setup with either bullseye or bookworm.

You can probably close this bug.  If it rears its ugly head again, I'll reopen 
or
file a new bug.

Thanks...Marvin

Bug#1006464: Please use "mdadm monitoring " as default MAILFROM

[Marvin Renich]

Package: mdadm
Version: 4.2-1
Severity: wishlist

Currently, the default for MAILFROM is "mdadm monitoring ".  If
/etc/mailname exists and is not empty, please use it to create a default
>From address that is useful when root's mail is being forwarded off the
current system (e.g. to a sysadmin responsible for many machines).

Thanks...Marvin

Bug#1002527: postinst ignores USER from /etc/default/milter-greylist when invoking chown ... /var/lib/milter-greylist

[Marvin Renich]

retitle 1002527 milter-greylist -u user does not correctly ensure user can 
update greylist.db
quit

* Adrian Bunk  [220120 21:43]:
> On Thu, Dec 23, 2021 at 02:12:04PM -0500, Marvin Renich wrote:
> >...
> > With an existing installation of milter-greylist set up to work with
> > chrooted postfix (i.e. USER="postfix" in /etc/default/milter-greylist),
> > every upgrade sets the owner of the directory /var/lib/milter-greylist
> > to "greylist" regardless of the setting of USER.  This effectively
> > breaks postfix, as it will no longer deliver mail until the problem is
> > resolved.
> > 
> > Note that the particular system hosting my mail server is still running
> > sysvinit, not systemd.  I do not know how milter-greylist configures the
> > user under systemd, but the postinst has "greylist" hardcoded, so I
> > suspect that if the sysadmin has configured a different user, this will
> > break under systemd, as well.
> >...
> 
> With systemd the problem likely doesn't exist since the user is 
> hardcoded also in the service file:
> 
> /lib/systemd/system/milter-greylist.service:
>   ExecStart=/usr/sbin/milter-greylist -u greylist

I'm not sure how that fixes anything.

When I first migrated from exim to postfix (many years ago), the
recommendation to get milter-greylist to work with Debian's chroot'ed
postfix was to run milter-greylist as user postfix (I believe to get the
permissions correct on the socket created by greylist, or perhaps to
allow it to create the socket in the postfix chroot, or both).

milter-greylist had a documented way to run it as a different user by
setting USER="postfix" in the above file.

I don't have milter-greylist running with postfix on a systemd system,
so I can't test this, but I suspect that if I copied
/lib/systemd/system/milter-greylist.service to /etc/systemd/system/ and
edited it to use -u postfix, and corrected the ownership and permissions
on /var/lib/milter-greylist, the next upgrade would still clobber the
ownership, thus breaking postfix.

Doing some research (just now), I think I can get this working reliably
across milter-greylist upgrades by adding user postfix to the group
greylist, and running milter-greylist with its default user (greylist).
I will try this when I have a chance.  But this is only a workaround for
the bug.  As long as the package supports running as a different user,
an upgrade should not change ownership of /var/lib/milter-greylist.

More research has narrowed down the problem.  This is not an
installation problem, but a failure of the "-u" option to perform its
documented behavior:

  Make sure this user (and group) has write access to greylist.db.

Because every write to greylist.db is (at least seems to be) done by
writing a temporary file in the same directory and then atomically
renaming it, the above promise is equivalent to ensuring that the user
and group has write access to the containing directory.  This is not
done at all.  I am retitling this bug appropriately.

...Marvin

Bug#1002529: removing /etc/init.d/rsyslog on upgrade breaks systems still using sysvinit

[Marvin Renich]

Package: rsyslog
Version: 8.2110.0-4
Severity: critical

On systems still running sysvinit, the removal of /etc/init.d/rsyslog
during upgrade of rsyslog causes complete data loss of critical system
information that was intended to be logged after the next reboot.

I understand that many maintainers do not want to continue to maintain
init scripts, but this case is different, as on sysvinit systems with
rsyslog installed, this is _the_ system logging mechanism.

At the very least, during postinst check if the system is running
sysvinit and do something to prevent removal of the file, even if it
stays around as a non-package-owned sysadmin file.

...Marvin


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'oldstable-updates'), (500, 'stable'), (500, 
'oldstable'), (200, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
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 not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages rsyslog depends on:
ii  init-system-helpers  1.61
ii  libc62.33-1
ii  libestr0 0.1.10-2.1+b1
ii  libfastjson4 0.99.9-1
ii  liblognorm5  2.0.5-1.1
hi  libsystemd0  238-5
ii  libuuid1 2.37.2-4
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages rsyslog recommends:
ii  logrotate  3.18.1-2

Versions of packages rsyslog suggests:
pn  rsyslog-doc   
pn  rsyslog-gssapi
pn  rsyslog-mongodb   
pn  rsyslog-mysql | rsyslog-pgsql 
pn  rsyslog-openssl | rsyslog-gnutls  
pn  rsyslog-relp  

-- no debconf information

Bug#1002527: postinst ignores USER from /etc/default/milter-greylist when invoking chown ... /var/lib/milter-greylist

[Marvin Renich]

Package: milter-greylist
Version: 4.6.4-1
Severity: critical

With an existing installation of milter-greylist set up to work with
chrooted postfix (i.e. USER="postfix" in /etc/default/milter-greylist),
every upgrade sets the owner of the directory /var/lib/milter-greylist
to "greylist" regardless of the setting of USER.  This effectively
breaks postfix, as it will no longer deliver mail until the problem is
resolved.

Note that the particular system hosting my mail server is still running
sysvinit, not systemd.  I do not know how milter-greylist configures the
user under systemd, but the postinst has "greylist" hardcoded, so I
suspect that if the sysadmin has configured a different user, this will
break under systemd, as well.

I chose severity critical because it breaks other software, and said
software is possibly the primary reason for the host on which it is
running, and this breakage can affect many users.

...Marvin


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'oldstable-updates'), (500, 'stable'), (500, 
'oldstable'), (200, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
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 not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages milter-greylist depends on:
ii  adduser  3.118
ii  init-system-helpers  1.61
ii  libbind9-161 1:9.11.19+dfsg-2.1
ii  libc62.33-1
ii  libcurl4 7.79.1-2
ii  libgeoip11.6.12-8
ii  libmilter1.0.1   8.16.1-2
ii  libopendkim112.11.0~beta2-6
ii  libspf2-21.2.10-7.1
ii  libssl1.11.1.1l-1
ii  lsb-base 11.1.0

Versions of packages milter-greylist recommends:
ii  postfix  3.6.3-1

milter-greylist suggests no packages.

Bug#766194: debhelper: dh_installinit should gain option to ignore start failures

[Marvin Renich]

* Niels Thykier  [180521 05:29]:
> As I understood your original mail, it sounded like we expect the
> service to fail because the user has not configured it yet.  I think I
> am missing the point of having it start automatically if it will not
> work out of the box.
>   Can you elaborate on what makes you want it to start automatically?

I'm not sure, so this may not be Sam's issue, but perhaps it should be
attempted to start the service, but it might fail, and such failure
should be ignored.  I'm not sure if dh_installinit can do different
things on initial install and upgrade, and it almost certainly cannot
determine if a proper configuration has been put in place by the
sysadmin before the initial install that would allow the service to
start correctly.  I don't use krb5-kdc, and don't know what the real
issue is.

> Note that debhelper's tooling for init scripts vs. systemd has the
> asymmetry that the systemd tooling ignores all failures basically.  As I
> understood the systemd maintainers who wrote the original systemd
> tooling, they were of the mind that failing installation because a
> service fails to start was not desirable.
>   But unlike sysvinit, systemd makes it easy for the administrator to
> tell which services have issues - so I am a bit hesitant to make these
> symmetric in general.

My bug is very closely related; tell me if I should file it separately.
I am approaching this from a different perspective:  that of a sysadmin
who has deliberately ensured that a service (docker in this case) will
not start automatically, by setting all the rc*.d links to "K01docker".
On every upgrade, this causes the installation to be stuck in a
half-configured state (from dpkg's pov).  I must manually edit the
postinst script to complete the upgrade, and my edit is lost during the
next upgrade.

This is, in my opinion, a normal, not wishlist, bug.  And, it is
probably a bug in both dh_installinit and invoke-rc.d.  In the man page
for invoke-rc.d, it says status codes 1-99 are reserved for the init.d
script, and:

  101Action not allowed.  The requested action will not be performed
 because of runlevel or local policy constraints.

The actual return code from invoke-rc.d for my case is 1, but should be
101 according to the man page (runlevel does not allow start or
restart).

But whether or not invoke-rc.d is fixed, dh_installinit will emit code
that ignores the sysadmin's explicit configuration and causes a failure
at upgrade (or initial installation).

I suspect that 99.9% of all Debian packages that have services should
not treat failure of the service to start during installation or upgrade
as a dpkg failure.  At worst, it is a bug in the package.  Since a bug
in a non-service executable that causes the executable to crash
immediately when invoked from the command line (e.g. if ls were to cause
a segfault) is not treated as an installation failure, why should a bug
in the package that causes the service to fail to start be treated
differently?

I think you should change dh_installinit so that if invoke-rc.d returns
101, you should treat it as success for the postinst's purposes, and any
other return code (other than 0) should produce a warning, but not fail
the postinst.

...Marvin

Bug#995772: please use alternatives instead of conflicting with exfat-utils

[Marvin Renich]

* Sven Hoexter  [211005 11:02]:
> I already coordinated with myself that exfat-utils and exfat-fuse will be
> removed.

Thanks!  I didn't look at the exfat-utils maintainer.

And thanks for maintaining these packages.

...Marvin

Bug#995772: please use alternatives instead of conflicting with exfat-utils

[Marvin Renich]

Package: exfatprogs
Version: 1.1.2-2
Severity: normal

Please coordinate with exfat-utils maintainer and use the alternative
system to allow both packages to be installed at the same time, with
both of them Providing a virtual package so that reverse dependencies
like exfat-fuse and udisks2 can depend on the virtual package if they
only use compatible command-line options or only Recommend for human
use.

This is the preferred method for dealing with multiple packages that
provide different implementations of the same command (see Policy 3.9
Maintainer Scripts).  This method has the advantage that if one or both
of the would-be conflicting packages have additional functionality not
in the other package (e.g. tune.exfat which is in exfatprogs but not in
exfat-utils), both can be installed, making the combined functionality
available.

...Marvin

Bug#989568: Please allow kgames and xmille to be co-installable

[Marvin Renich]

Package: kgames
Version: 1.0-2.1
Severity: normal

kgames Breaks, Replaces, and Provides xmille, but the user interface is
different enough between the two that it is reasonable to want the
xmille package and the other games in kgames at the same time.

I see three obvious solutions, listed in order of my own personal
preference:

1.  Rename the binary in kgames to kmille, and use the alternatives
system to provide links from xmille to either package's binary.
This requires cooperation and coordination with the xmille
maintainer, but provides the best end user experience.

2.  Rename the binary in kgames and don't bother with alternatives.
This is a very close second option.

3.  Move the kgames version of xmille to a separate binary package,
which Conflicts, Replaces, Provides xmille.  I'm not too keen on
this solution, but it allows you to keep the original executable
name without interaction with the xmille maintainer.

Debian Policy section 10.1 says that two packages must not install
programs with different functionality but with the same filenames.  It
goes on to say that the same functionality but different implementations
is handled by "alternatives" or "Conflicts".

I think this best fits the second criterion, but because there is
sufficient reason to want both packages installed at the same time, the
"alternatives" solution seems substantially better than "Conflicts" to
me.

For future reference, Conflicts should be used rather than Breaks when
two packages provide the same file and will continue to do so.  See
Debian Policy section 7.4.  Policy does encourage using Breaks over
Conflicts when possible, but this is a case where Conflicts is
necessary.

Thanks for packaging these games.

...Marvin

-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-security'), (500, 
'stable-updates'), (500, 'stable'), (500, 'oldstable'), (200, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
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 not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages kgames depends on:
ii  libc6 2.31-12
ii  libx11-6  2:1.7.1-1
ii  libxaw7   2:1.0.13-1.1
ii  libxmu6   2:1.1.2-2+b3
ii  libxpm4   1:3.5.12-1
ii  libxt61:1.2.0-1

kgames recommends no packages.

kgames suggests no packages.

-- no debconf information

Bug#975557: Please improve package descriptions

[Marvin Renich]

Source: xrootd
Version: 5.0.3-1

All binary packages built from xrootd except xrootd-server have
descriptions that rely on the reader already having knowledge of what
xrootd is.  Each package's description should include a brief
description of the overall xrootd project.

An example for xrootd-client might be:

Description: Xrootd command line client tools
 This package contains the command line tools used to communicate with
 xrootd servers.
 .
 The xrootd-server package contains a root file system server and a
 cluster management server that provide a clustered file system.

This description not only says that xrootd is a clustered file system,
but it specifically identifies the package containing the more verbose
description.

Note, I am not an xrootd user, I just happened to see it under "New
Packages" and wanted to know what it was.  Finding the xrootd-related
package that gave that information took more effort than it should have,
as there were almost 200 new packages, and xrootd-doc was near the top,
but xrootd-server was much farther down.

It might also help to include the more verbose description in xrootd-doc
as well as xrootd-server.

...Marvin

Bug#946900: latest neomutt no longer uses account-hook for initial login [regression]

[Marvin Renich]

* Antonio Radici  [200624 08:00]:
> Control: tag -1 +moreinfo
> 
> Can you provide an example configuration that allow us to reproduce this bug
> against the version that is currently on sid?

The only things necessary are "set spoolfile=...", "mailboxes ...", and
an account-hook that sets imap_user and imap_pass for the account used
in the common imap spoolfile/mailbox.

This simple file demonstrates the bug for me in a relatively clean
buster VM with neomutt from unstable:

set realname="Your Name"
set from="y...@example.com"
set use_from
set spoolfile="imap://mail.example.com/inbox"
set folder="imap://mail.example.com"
mailboxes imap://mail.example.com/inbox
account-hook imap://mail.example.com/ 'set imap_user=you imap_pass=secret'

(Obviously, use a real imap server and account.)

If you comment out the mailboxes line, you are not prompted.  In my
real setup, mailboxes contains a list of folders, and I have "set
sidebar_visible=yes".

...Marvin

Bug#958120: apt-secure man page does not give promised information

[Marvin Renich]

Package: apt
Version: 2.0.2
Severity: normal

When an InRelease file changes, apt-get update gives the following error:

E: Repository 'http://approx.local:/debian buster InRelease' changed its 
'Suite' value from 'testing' to 'stable'
N: This must be accepted explicitly before updates for this repository can be 
applied. See apt-secure(8) manpage for details.

The apt-secure man page describes _why_ this happens, but gives
absolutely no clue about how to fix it.  While different front ends may
have different ways to do this, the apt-secure man page should at the
very least point explicitly to the --allow-releaseinfo-change option of
the apt-get man page, so the user can follow the error message to a
solution, without resorting to guessing or googling.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 
'oldstable-updates'), (500, 'stable'), (500, 'oldstable'), (200, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.5.0-1-amd64 (SMP w/8 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: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages apt depends on:
ii  adduser 3.118
ii  debian-archive-keyring  2019.1
ii  gpgv2.2.20-1
ii  libapt-pkg6.0   2.0.2
ii  libc6   2.30-4
ii  libgcc-s1   10-20200411-1
ii  libgnutls30 3.6.13-2
ii  libseccomp2 2.4.3-1+b1
ii  libstdc++6  10-20200411-1
ii  libsystemd0 238-5

Versions of packages apt recommends:
ii  ca-certificates  20190110

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.8.12-3
ii  dpkg-dev1.19.7
ii  gnupg   2.2.20-1
ii  powermgmt-base  1.36
ii  synaptic0.90+nmu1

-- no debconf information

Bug#956049: clone for second bug

[Marvin Renich]

Control: clone -1 -2
Control: retitle -2 Unable to read top-level mounted directory with idmap=file

Bug#956049: No error message from failed mount with idmap=file and incomplete gidfile

[Marvin Renich]

Package: sshfs
Version: 3.7.0+repack-1
Severity: normal

(I will clone this for two related bugs with the same setup.)

On remote host:

$ id
uid=1000(user1) gid=1000(user1) groups=1000(user1),…,50(staff),…
$ cd /srv/www/site1
$ ls -lAd
drwxrwsr-x 8 user1 staff 4096 Oct 30 16:44 .
$ ls -lA
total 20
drwxrwsr-x 2 user1 staff 4096 Mar 17  2019 config
drwxrwsr-x 3 user1 staff 4096 Mar 16 21:19 data
drwxrwsr-x 4 user1 staff 4096 Apr  5 12:36 .hg
-rw-rw-r-- 1 user1 staff  223 Mar 10  2019 .hgignore
drwxrwsr-x 7 user1 staff 4096 Apr  5 18:19 home
$ ls -lA config
total 32
-rwxrwxr-x 1 user1 staff 1213 Mar 10  2019 checkuser
-rw-rw-r-- 1 user1 staff  873 Mar 10  2019 permissions
-rwxrwxr-x 1 user1 staff 1862 Mar 10  2019 register
-rw-rw-r-- 1 user1 staff 5274 Mar 17  2019 rws.conf
-rwxrwxr-x 1 user1 staff  105 Mar 10  2019 sync-reg
-rwxrwxr-x 1 user1 staff  178 Mar 10  2019 sync-srv
-rwxrwxr-x 1 user1 staff 3202 Mar 10  2019 updateprofile

On local host:

$ id
uid=1001(mrvn) gid=1001(mrvn) groups=1001(mrvn),…,50(staff),…
$ ls -lA
total 12
drwxrwxr-x 2 mrvn mrvn 4096 Apr  5 11:33 remote
-rw-r--r-- 1 mrvn mrvn   19 Apr  6 11:24 .remote-gidmap
-rw-r--r-- 1 mrvn mrvn   10 Apr  5 14:27 .remote-uidmap
$ ls -lA remote
total 0
$ cat .remote-uidmap
mrvn:1000
$ cat .remote-gidmap
mrvn:1000

Bug #1:  No error message from failed mount with idmap=file and incomplete 
gidfile

On local host:

$ sshfs user1@remote:/srv/www/site1 remote -o 
idmap=file,uidfile=.remote-uidmap,gidfile=.remote-gidmap
$ echo $?
1

And the remote file system is not mounted.

Bug #2:  Unable to read top-level mounted directory with idmap=file

On local host:

$ echo staff:50 >> .remote-gidmap
$ cat .remote-gidmap
mrvn:1000
staff:50
$ sshfs user1@remote:/srv/www/site1 remote -o 
idmap=file,uidfile=.remote-uidmap,gidfile=.remote-gidmap
$ echo $?
0
$ ls -lA
total 12
drwxrwsr-x 1 mrvn staff 4096 Oct 30 16:44 remote
-rw-r--r-- 1 mrvn mrvn19 Apr  6 12:24 .remote-gidmap
-rw-r--r-- 1 mrvn mrvn10 Apr  5 14:27 .remote-uidmap
$ ls -lA remote
ls: reading directory 'remote': Operation not permitted
total 0
$ ls -lA remote/config
total 32
-rwxrwxr-x 1 mrvn staff 1213 Mar 10  2019 checkuser
-rw-rw-r-- 1 mrvn staff  873 Mar 10  2019 permissions
-rwxrwxr-x 1 mrvn staff 1862 Mar 10  2019 register
-rw-rw-r-- 1 mrvn staff 5274 Mar 17  2019 rws.conf
-rwxrwxr-x 1 mrvn staff  105 Mar 10  2019 sync-reg
-rwxrwxr-x 1 mrvn staff  178 Mar 10  2019 sync-srv
-rwxrwxr-x 1 mrvn staff 3202 Mar 10  2019 updateprofile
$ fusermount -u remote

Adding nomap=ignore fixes the problem (why?):

$ sshfs user1@remote:/srv/www/site1 remote -o 
idmap=file,uidfile=.remote-uidmap,gidfile=.remote-gidmap,nomap=ignore
$ echo $?
0
$ ls -lA
total 12
drwxrwsr-x 1 mrvn staff 4096 Oct 30 16:44 remote
-rw-r--r-- 1 mrvn mrvn19 Apr  6 12:24 .remote-gidmap
-rw-r--r-- 1 mrvn mrvn10 Apr  5 14:27 .remote-uidmap
$ ls -lA remote
total 20
drwxrwsr-x 1 mrvn staff 4096 Mar 17  2019 config
drwxrwsr-x 1 mrvn staff 4096 Mar 16 21:19 data
drwxrwsr-x 1 mrvn staff 4096 Apr  5 12:36 .hg
-rw-rw-r-- 1 mrvn staff  223 Mar 10  2019 .hgignore
drwxrwsr-x 1 mrvn staff 4096 Apr  5 18:19 home
$ ls -lA remote/config
total 32
-rwxrwxr-x 1 mrvn staff 1213 Mar 10  2019 checkuser
-rw-rw-r-- 1 mrvn staff  873 Mar 10  2019 permissions
-rwxrwxr-x 1 mrvn staff 1862 Mar 10  2019 register
-rw-rw-r-- 1 mrvn staff 5274 Mar 17  2019 rws.conf
-rwxrwxr-x 1 mrvn staff  105 Mar 10  2019 sync-reg
-rwxrwxr-x 1 mrvn staff  178 Mar 10  2019 sync-srv
-rwxrwxr-x 1 mrvn staff 3202 Mar 10  2019 updateprofile
$ fusermount -u remote


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 
'oldstable-updates'), (500, 'stable'), (500, 'oldstable'), (200, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-4-amd64 (SMP w/8 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: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages sshfs depends on:
ii  fuse3   3.9.0-2
ii  libc6   2.30-4
ii  libfuse3-3  3.9.0-2
ii  libglib2.0-02.64.1-1
ii  openssh-client  1:8.2p1-4

sshfs recommends no packages.

sshfs suggests no packages.

-- no debconf information

Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace

[Marvin Renich]

* Joerg Dorchain  [200303 05:15]:
> On Tue, Mar 03, 2020 at 10:57:41AM +0100, Andras Korn wrote:
> > I filed https://github.com/neomutt/neomutt/issues/2161.
> 
> Thanks for the effort, but:
> 
> Duplicate #2002 and there's already pull request for it #2160.
> @gahr gahr closed this 6 minutes ago 
> 
> Looks like cherry-pikcing that patch and thinking about the default setting.

No, #2002 is _not_ the same.  See my previous message.

Neomutt bug #2002 is about editing headers.  This Debian bug and Neomutt
#2161 are about commands in the message index.  The behaviors are
different in the two situations.

There are three behaviors being discussed:

1. old behavior:  backspace stays on the command line
2. new behavior:  backspace aborts the command
3. wrong behavior:  backspace invokes command with default argument

In #2002, while editing headers, you currently get "new behavior".  The
bug reporter wants "old behavior" (what the previous version of Neomutt
did in this situation).  The patch adds a config option to select which
you want.

In #2161, while in the message index, the previous version of Neomutt
gave "old behavior".  The current Neomutt gives "wrong behavior", _not_
"new behavior".

For example, type s and (assuming a save-hook matches for the message)
the command line shows:

Save to mailbox ('?' for list): +some_folder

Now keep backspacing until +some_folder is gone and backspace one more
time.  Instead of aborting the save, the message is actually saved to
+some_folder!  This is really, _really_ wrong!

First, #2161 must be fixed so it doesn't give "wrong behavior".  Then,
the patch needs to be tested to see if it affects both editing message
headers (#2002) and commands in the message index (#2161).  If it does,
great!  If it doesn't, the patch should be updated so that it does.

Then, the default needs to be decided.

Holding the backspace key down is common practice for some people as a
way of erasing the default prompt in preparation for typing a different
value.

Both for this reason and to reduce surprise and change, I feel that the
default should be "old behavior", but I can live with setting the option
myself if other people would rather have "new behavior" as the default.

There is one more reason that having backspace remain on the command
line instead of aborting is a better default.  If someone has bound the
backspace key to some action in the message index (or in the message
editing screen), holding down the backspace key could invoke the bound
action on one (or several) messages in the index, depending on how
quickly the user releases the key.

...Marvin

Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace

[Marvin Renich]

[P.S. I'm subscribed to the bug; you may drop me from explicit To or CC.]

* Joerg Dorchain  [200302 12:18]:
> Then please include
> https://github.com/neomutt/neomutt/commit/f197ab93c8436a39fc511f396acde24f90389f20?diff=unified
> 
> in a new package, maybe with a Debian-specific change of the abort_backspace
> default to false.

I'm not a DD or DM and have no upload rights, and don't have the time at
the moment to prepare and test an upload properly (which is more than
just applying the patch and building a package).  I do appreciate the
people who have in the past and are currently working on the Debian
packaging of neomutt.

Looking at the github issue, it looks like backspace is supposed to
cancel the command, and the behavior that the bug reporter wants is to
remain on the empty command line and ignore the backspace.  But neither
is the behavior I am seeing.

First, the behavior in the github issue is specific to editing email
headers while composing a message.  For me, that specific case seems to
abort the edit, and it seems to be an intentional change.  I don't have
a strong opinion about the github issue, but it is definitely not the
issue in this Debian bug, although the code that implemented the
intentional change may be the cause of this Debian bug.

The situation that I feel is a grave bug is when in the message index,
using certain commands that require more information (save-message is
one such command), pressing backspace when the prompt is empty (only the
":" showing) causes the _default action_ to occur (e.g. save to the
folder specified by the save-hook for that message) rather than aborting
the command.

As long as backspace does not have a binding after the prompt is
aborted (e.g. in the index), I can probably live with either the abort
or ignore behavior, but activating the default action is highly broken.

I cannot tell whether the patch referenced in the previous message will
fix this Debian bug.  If the cause of the Debian bug has to do with
mutt_enter_string_full being called for both completing a command in the
index and for editing message headers, but the result of the function is
being handled differently in the two cases, then perhaps the patch will
allow the bug to be masked by unsetting the option, but with the option
set the bug will still be present.  I can't tell without looking at the
rest of the code.

I don't have a github account, and do not wish to get one for this.
Will someone (Debian maintainer for neomutt, or someone else interested
in this bug) please file this with upstream as a separate bug, pointing
out that the other github issue is not the same as this bug, even though
some of the same code may be involved.

Thanks...Marvin

Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace

[Marvin Renich]

* Andreas Henriksson  [200302 08:27]:
> On Fri, Feb 14, 2020 at 11:31:53AM -0500, Marvin Renich wrote:
> > Control: -1 severity grave
> > 
> > I'm increasing the severity of this bug, as it can cause unintended
> [...]
> 
> I just NMUed a new upstream version of neomutt, 20191207+dfsg.1-1,
> which fixes the two other outstanding RC bugs.
> It seems I can still reproduce this issue however (with the first prompt
> I get which is the imap password prompt for me).

Thanks for this!

> This seems somewhat like a possible UX design fail.

Possibly, but I suspect not.  This is a regression from previous
versions, and it would not make sense at all as an intentional design
change.

> This is done
> upstream and not in debian. Do you know if there's already been any
> discussion regarding this upstream? If not could you please file an
> upstream bug report about this?

Unfortunately, I don't have time to do this at the moment.  I have no
clue where upstream's bug system (or mailing list) is, and can't spend
the time to do this right away.  If you (or the maintainer; I assume you
are not the maintainer since you did an NMU) would be so kind as to
point upstream to this bug, I would appreciate it.

> The behaviour hasn't really bothered me and I probably wouldn't even
> have noticed it if it wasn't for this bug showing up on the RC bug radar
> while doing my NMU, so I'm quite tempted to downgrade severity again.
> Please work this out with upstream if this issue is important to you.
> Please give feedback on this bug report about upstream discussions or
> relevant commits and I'm happy to look into cherry-picking and NMUing
> those as needed.

Please don't downgrade this bug.  Here is a very plausible expanded
example based on my original scenario:

The user is unaware of this bug, so is not being careful to watch out
when backspacing (I am now aware of this bug, and still find myself
accidentally backspacing too far).

The user has tagged a large number of messages, intending to save them
all to a different folder.  The user types «;s=soon-but-not-immediate»
out of habit, without watching the command line, and doesn't notice what
folder was originally placed on the command line based on the save-hook
for the first tagged message.  The first message happens to match the
save-hook for "=spam" (it received a marginally-positive spam score from
spamassassin, but was a false positive).

Before hitting enter on the ;s=soon-but-not-immediate command, the user
changes his mind and decides to save them to the =handle-now folder, so
he presses and holds the backspace key.

Oops!  Now all those messages are moved to the spam folder, which
triggers a daemon on the IMAP server to tell spamassassin to learn all
those messages as spam and moves the messages into a quarantine folder
(inaccessible to the user).

Meanwhile, the poor user, who has never seen this neomutt bug before,
has no clue where his messages went, and all those messages have been
learned as spam without the user's knowledge.

Here is my rationale for severity grave:

* This is a regression from a previous version.

* The behavior makes no sense as an intentional UI change.

* The bug can cause behaviour of which the user is unaware.

* The unintended behavior caused by this bug can have significantly
  detrimental effects that are difficult discover and difficult to undo.

Users of neomutt (and mutt) are typically a different kind of user than
those who stick with Thunderbird or the Gmail web interface.  They are
likely to take full advantage of save-hooks and other advanced neomutt
features.  They are also more likely to type sequences of commands
quickly and by habit, only looking at the command line at certain
pauses.

The above scenario is not based on a hypothetical setup.  I run the
renich.org mail server, which uses spamassassin to score incoming
messages.  Messages with scores above a certain threshold are rejected
during the SMTP dialog, but messages with low-positive scores are
accepted.  I have a save-hook that uses =spam as the default folder for
messages that spamassassin marks with a low-but-positive spam score.  I
do have a spam folder, with behavior similar to what is stated above,
except that the auto-learning happens from a cron job overnight.

While I have not had the above happen to me where the messages were
saved to the spam folder and learned as spam before I caught it, it
could have happened.  The way I discovered this bug was, however, very
similar.  The actual (but unintended) save target was a different
folder.  It took several hours of investigation to determine what the
bug was, where the messages actually went (which was not at all obvious
even after I understood the bug), and to restore the messages to the
intended destination.

Debian Policy does not mention "severity" or "grave" anywhere.  The
Developers Reference lists th

Bug#945442: Re Bug#945442: Possible to backspace past beginning of string...

[Marvin Renich]

Control: -1 severity grave

I'm increasing the severity of this bug, as it can cause unintended
behavior of which the user is unaware, in a manner that is close enough
to data loss that it should be considered grave.

One example is when saving a bunch of tagged messages, and backspacing
too far when attempting to change the destination folder, the messages
will be saved to the default (save-hook) folder for the first tagged
message.  If the user is unaware of this bug, the user may not know what
has happened or where the messages have gone.

...Marvin

Bug#951263: please do not change "=" to "+" on command line (regression)

[Marvin Renich]

Package: neomutt
Version: 2019+dfsg.1-1
Severity: minor

When typing a folder on the command line, certain keys cause the folder
name to be canonicalized, and if the user is accustomed to using "=", it
now changes that to "+".  This is new behavior; it used to leave "="
alone.  I don't know if it used to change "+" to "=", but I am guessing
that it didn't.

This change is disconcerting at best, and is completely unnecessary.  On
a US keyboard, both characters are on the same key, but "=" is unshifted
and easier to type.  The "+" may be easier to type on other keyboards.
Please respect the user's choice of "=" or "+".

Please don't try to canonicalize the command line when it loses
information or is contrary to the user's expectation.

-- Package-specific info:
NeoMutt 2019
Copyright (C) 1996-2016 Michael R. Elkins and others.
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type 'neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type 'neomutt -vv' for details.

System: Linux 5.4.0-3-amd64 (x86_64)
ncurses: ncurses 6.1.20191019 (compiled with 6.1.20191019)
libidn: 1.33 (compiled with 1.33)
GPGme: 1.13.1-unknown
hcache backends: tokyocabinet

Compiler:
Using built-in specs.
COLLECT_GCC=cc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 9.2.1-19' 
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-9 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib 
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch 
--disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none,hsa --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 9.2.1 20191109 (Debian 9.2.1-19) 

Configure options: --build=x86_64-linux-gnu --prefix=/usr 
{--includedir=${prefix}/include} {--mandir=${prefix}/share/man} 
{--infodir=${prefix}/share/info} --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules {--libdir=${prefix}/lib/x86_64-linux-gnu} 
{--libexecdir=${prefix}/lib/x86_64-linux-gnu} --disable-maintainer-mode 
--disable-dependency-tracking --mandir=/usr/share/man --libexecdir=/usr/libexec 
--with-mailpath=/var/mail --gpgme --lua --notmuch --with-ui --gnutls --gss 
--idn --mixmaster --sasl --tokyocabinet

Compilation CFLAGS: -g -O2 
-fdebug-prefix-map=/build/neomutt-jdVSn8/neomutt-2019+dfsg.1=. 
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -I/usr/include 
-I/usr/include/lua5.3 -DNCURSES_WIDECHAR -isystem /usr/include/mit-krb5

Default options:
  +attach_headers_color +compose_to_sender +compress +cond_date +debug 
  +encrypt_to_self +forgotten_attachments +forwref +ifdef +imap +index_color 
  +initials +limit_current_thread +multiple_fcc +nested_if +new_mail +nntp +pop 
  +progress +quasi_delete +regcomp +reply_with_xorig +sensible_browser +sidebar 
  +skip_quoted +smtp +status_color +timeout +tls_sni +trash 

Compile options:
  -autocrypt +bkgdset +color +curs_set +fcntl -flock -fmemopen +futimens 
  +getaddrinfo +gnutls +gpgme +gss +hcache -homespool +idn +inotify 
  -locales_hack +lua +meta +mixmaster +nls +notmuch -openssl +pgp +sasl +smime 
  -sqlite +start_color +sun_attachment +typeahead 
MAILPATH="/var/mail"
MIXMASTER="mixmaster"
PKGDATADIR="/usr/share/neomutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/etc"

To learn more about NeoMutt, visit: https://neomutt.org
If you find a bug in NeoMutt, please raise an issue at:
https://github.com/neomutt/neomutt/issues
or send an email to: 

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 
'oldstable-updates'), (500, 'stable'), (500, 'oldstable'), (200, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-3-amd64 (SMP w/8 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: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages neomutt depends on:

Bug#951261: indication that command is operating on tagged messages disappears (regression)

[Marvin Renich]

Package: neomutt
Version: 2019+dfsg.1-1
Severity: normal

If you only have one message tagged, and type ;s to save tagged
messages, the command line used to say "Save tagged to...", but now the
word "tagged" is no longer there.  This is truely bad, as the message
that is highlighted is usually not the tagged message, so the message
that looks like it will be saved is neither the message that was
intended nor the message that actually will be saved.

Even if the tagged message is the one that is highlighted, please still
use the "Save tagged..." message; it tells the user not only what will
happen, but confirms what the user actually typed.

Please don't try to "canonicalize" the command line when it loses
information or is contrary to the user expectation.

...Marvin

-- Package-specific info:
NeoMutt 2019
Copyright (C) 1996-2016 Michael R. Elkins and others.
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type 'neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type 'neomutt -vv' for details.

System: Linux 5.4.0-3-amd64 (x86_64)
ncurses: ncurses 6.1.20191019 (compiled with 6.1.20191019)
libidn: 1.33 (compiled with 1.33)
GPGme: 1.13.1-unknown
hcache backends: tokyocabinet

Compiler:
Using built-in specs.
COLLECT_GCC=cc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 9.2.1-19' 
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-9 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib 
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch 
--disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none,hsa --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 9.2.1 20191109 (Debian 9.2.1-19) 

Configure options: --build=x86_64-linux-gnu --prefix=/usr 
{--includedir=${prefix}/include} {--mandir=${prefix}/share/man} 
{--infodir=${prefix}/share/info} --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules {--libdir=${prefix}/lib/x86_64-linux-gnu} 
{--libexecdir=${prefix}/lib/x86_64-linux-gnu} --disable-maintainer-mode 
--disable-dependency-tracking --mandir=/usr/share/man --libexecdir=/usr/libexec 
--with-mailpath=/var/mail --gpgme --lua --notmuch --with-ui --gnutls --gss 
--idn --mixmaster --sasl --tokyocabinet

Compilation CFLAGS: -g -O2 
-fdebug-prefix-map=/build/neomutt-jdVSn8/neomutt-2019+dfsg.1=. 
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -I/usr/include 
-I/usr/include/lua5.3 -DNCURSES_WIDECHAR -isystem /usr/include/mit-krb5

Default options:
  +attach_headers_color +compose_to_sender +compress +cond_date +debug 
  +encrypt_to_self +forgotten_attachments +forwref +ifdef +imap +index_color 
  +initials +limit_current_thread +multiple_fcc +nested_if +new_mail +nntp +pop 
  +progress +quasi_delete +regcomp +reply_with_xorig +sensible_browser +sidebar 
  +skip_quoted +smtp +status_color +timeout +tls_sni +trash 

Compile options:
  -autocrypt +bkgdset +color +curs_set +fcntl -flock -fmemopen +futimens 
  +getaddrinfo +gnutls +gpgme +gss +hcache -homespool +idn +inotify 
  -locales_hack +lua +meta +mixmaster +nls +notmuch -openssl +pgp +sasl +smime 
  -sqlite +start_color +sun_attachment +typeahead 
MAILPATH="/var/mail"
MIXMASTER="mixmaster"
PKGDATADIR="/usr/share/neomutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/etc"

To learn more about NeoMutt, visit: https://neomutt.org
If you find a bug in NeoMutt, please raise an issue at:
https://github.com/neomutt/neomutt/issues
or send an email to: 

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 
'oldstable-updates'), (500, 'stable'), (500, 'oldstable'), (200, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-3-amd64 (SMP w/8 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: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Bug#946900: latest neomutt no longer uses account-hood for initial login [regression]

[Marvin Renich]

Package: neomutt
Version: 2019+dfsg.1-1
Severity: normal

When starting neomutt version 20180716+dfsg.1-1, my login credentials
from an account-hook setting sourced by ~/.mutt/muttrc are used for the
initial connection to my imap server.  With verion 2019+dfsg.1-1, I
am prompted for my user name and password for the initial connection.

With both versions, changing to another server (with different
credentials) correctly uses an account hook specified in the same config
file, and changing back to the initial account either uses the cached
user name and password or a cached tcp connection or correctly uses the
account hook (I cannot tell which).

-- Package-specific info:
NeoMutt 2019
Copyright (C) 1996-2016 Michael R. Elkins and others.
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type 'neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type 'neomutt -vv' for details.

System: Linux 5.3.0-2-amd64 (x86_64)
ncurses: ncurses 6.1.20191019 (compiled with 6.1.20191019)
libidn: 1.33 (compiled with 1.33)
GPGme: 1.13.1-unknown
hcache backends: tokyocabinet

Compiler:
Using built-in specs.
COLLECT_GCC=cc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 9.2.1-19' 
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-9 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib 
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch 
--disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none,hsa --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 9.2.1 20191109 (Debian 9.2.1-19) 

Configure options: --build=x86_64-linux-gnu --prefix=/usr 
{--includedir=${prefix}/include} {--mandir=${prefix}/share/man} 
{--infodir=${prefix}/share/info} --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules {--libdir=${prefix}/lib/x86_64-linux-gnu} 
{--libexecdir=${prefix}/lib/x86_64-linux-gnu} --disable-maintainer-mode 
--disable-dependency-tracking --mandir=/usr/share/man --libexecdir=/usr/libexec 
--with-mailpath=/var/mail --gpgme --lua --notmuch --with-ui --gnutls --gss 
--idn --mixmaster --sasl --tokyocabinet

Compilation CFLAGS: -g -O2 
-fdebug-prefix-map=/build/neomutt-jdVSn8/neomutt-2019+dfsg.1=. 
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -I/usr/include 
-I/usr/include/lua5.3 -DNCURSES_WIDECHAR -isystem /usr/include/mit-krb5

Default options:
  +attach_headers_color +compose_to_sender +compress +cond_date +debug 
  +encrypt_to_self +forgotten_attachments +forwref +ifdef +imap +index_color 
  +initials +limit_current_thread +multiple_fcc +nested_if +new_mail +nntp +pop 
  +progress +quasi_delete +regcomp +reply_with_xorig +sensible_browser +sidebar 
  +skip_quoted +smtp +status_color +timeout +tls_sni +trash 

Compile options:
  -autocrypt +bkgdset +color +curs_set +fcntl -flock -fmemopen +futimens 
  +getaddrinfo +gnutls +gpgme +gss +hcache -homespool +idn +inotify 
  -locales_hack +lua +meta +mixmaster +nls +notmuch -openssl +pgp +sasl +smime 
  -sqlite +start_color +sun_attachment +typeahead 
MAILPATH="/var/mail"
MIXMASTER="mixmaster"
PKGDATADIR="/usr/share/neomutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/etc"

To learn more about NeoMutt, visit: https://neomutt.org
If you find a bug in NeoMutt, please raise an issue at:
https://github.com/neomutt/neomutt/issues
or send an email to: 

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 
'oldstable-updates'), (500, 'stable'), (500, 'oldstable'), (200, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.0-2-amd64 (SMP w/8 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: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages neomutt depends on:
ii  libc6 2.29-3
ii  libgnutls30   3.6.10-5
ii  libgpg-error0 

Bug#943903: [Pkg-samba-maint] Bug#943903: samba 2:4.11.1+dfsg-1 server breaks mount.cifs from cifs-utils 2:6.9-1

[Marvin Renich]

Thanks for looking into this.

* Mathieu Parent  [191116 16:12]:
> Le jeu. 31 oct. 2019 à 17:03, Marvin Renich  a écrit :
> >
> > Package: samba
> > Version: 2:4.11.1+dfsg-1
> > Severity: normal
> >
> > After upgrading from samba 2:4.9.13+dfsg-1 to 2:4.11.0+dfsg-10 on a server 
> > machine, mount.cifs from cifs-utils 2:6.9-1
> > on a different machine fails to connect with "mount error(13): Permission 
> > denied".  Subsequently upgrading samba to
> > 2:4.11.1+dfsg-1 did not help.
> 
> What is the kernel version on the client side?

$ uname -a
Linux basil 5.2.0-3-amd64 #1 SMP Debian 5.2.17-1 (2019-09-26) x86_64 GNU/Linux

> 
> Try to force the CIFS version with vers= in the mount options.

At the time, I tried 1.0, 2.0, 2.1, 3.0, and 3.

If I remember correctly, 1.0 gave me a different error message, but
still failed to mount.  3.0 (I think) and 3 gave the error above.  I
don't remember which error I got for 2.[01], but it was one of the two.

If it would be useful, early next week I can try temporarily upgrading
samba on the server and running mount on the client with the --verbose
option.  If there is anything else I should try at that time, let me
know.

If it makes any difference (I don't think so), the version of samba on
my client is 2:4.11.1+dfsg-2, and  mount.cifs works correctly with the
older version of samba on the server.

...Marvin

Bug#943903: samba 2:4.11.1+dfsg-1 server breaks mount.cifs from cifs-utils 2:6.9-1

[Marvin Renich]

Package: samba
Version: 2:4.11.1+dfsg-1
Severity: normal

I plan to clone this bug to cifs-utils, as it is unclear which package has the 
bug.

After upgrading from samba 2:4.9.13+dfsg-1 to 2:4.11.0+dfsg-10 on a server 
machine, mount.cifs from cifs-utils 2:6.9-1
on a different machine fails to connect with "mount error(13): Permission 
denied".  Subsequently upgrading samba to
2:4.11.1+dfsg-1 did not help.

Downgrading samba to stable 2:4.9.5+dfsg-5+deb10u1 on the server fixes the 
problem.  Adding a snapshot version to figure
out what needed to be downgraded to get version 2:4.9.13+dfsg-1 was deemed not 
worth the effort, as my daily backup on
the client machine (which mounts the remote cifs share) was running fine when 
the server had 2:4.9.13+dfsg-1.

-- Package-specific info:
* /etc/samba/smb.conf present, but not attached
* /var/lib/samba/dhcp.conf present, but not attached

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 
'oldstable-updates'), (500, 'stable'), (500, 'oldstable'), (200, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-3-amd64 (SMP w/8 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: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages samba depends on:
ii  adduser  3.118
ii  dpkg 1.19.7
ii  init-system-helpers  1.57
ii  libbsd0  0.10.0-1
ii  libc62.29-2
ii  libgnutls30  3.6.9-5+b1
ii  libldb2  2:2.0.7-3
ii  libpam-modules   1.3.1-5
ii  libpam-runtime   1.3.1-5
ii  libpopt0 1.16-14
ii  libpython3.7 3.7.5~rc1-2
ii  libtalloc2   2.3.0-2
ii  libtasn1-6   4.14-3
ii  libtdb1  1.4.2-2
ii  libtevent0   0.10.1-3
ii  libwbclient0 2:4.11.1+dfsg-1
ii  lsb-base 11.1.0
ii  procps   2:3.3.15-2+b1
ii  python3  3.7.5-1
ii  python3-dnspython1.16.0-1
ii  python3-samba2:4.11.1+dfsg-1
ii  samba-common 2:4.11.1+dfsg-1
ii  samba-common-bin 2:4.11.1+dfsg-1
ii  samba-libs   2:4.11.1+dfsg-1
ii  tdb-tools1.4.2-2

Versions of packages samba recommends:
ii  attr1:2.4.48-5
ii  logrotate   3.15.1-1
ii  samba-dsdb-modules  2:4.11.1+dfsg-1
ii  samba-vfs-modules   2:4.11.1+dfsg-1

Versions of packages samba suggests:
pn  bind9  
pn  bind9utils 
pn  ctdb   
pn  ldb-tools  
ii  ntp1:4.2.8p13+dfsg-2
pn  smbldap-tools  
ii  ufw0.36-1
ii  winbind2:4.11.1+dfsg-1

-- debconf information:
  samba/run_mode: daemons
  samba-common/title:

Bug#929270: description uses "Golang" instead of "Go"

[Marvin Renich]

Package: termshark
Version: 1.0.0-1
Severity: normal

The package description says "Written in Golang".  The correct name of
that computer language is "Go".  golang.org is the domain name where the
official website is hosted, but that is not the name of the language.

...Marvin

Bug#865975: #865975 docker.io breaks (bridged) network for VMs

[Marvin Renich]

[I'm subscribed to this bug, you don't need to include me in TO or CC.]

* Dmitry Smirnov  [181126 20:45]:
> This bug is basically a duplicate of #903635.

Not really.  Bug #903635 is about not obeying a documented command line
option.  This bug is about incorrectly modifying iptables when it is
enabled.  I.e. when --iptables=true, the modification is done is wrong
(in a way that breaks networking configuration for non-docker software).

> On Tuesday, 27 November 2018 9:00:20 AM AEDT Marvin Renich wrote:
> > The current behavior appears to break other software 100% of the time
> > if that software relies on ip_forward being 1 and the FORWARD chain
> > being in its default state.
> 
> Situation is unfortunate and upstream does not care enough. They probably 
> want Docker users to use Docker exclusively without any other software on the 
> host. I very much dislike this approach but that's Docker for you... :(

I appreciate your candor regarding upstream's attitude.

Would you mind forwarding this upstream anyway, to give them the
opportunity to do the right thing?  Here is my suggestion to them to fix
this bug:

1.  Only change the FORWARD chain policy if ip_forward was 0 before
adding rules to this chain (obviously docker sets ip_forward to 1 if
it wasn't already).

2.  Only add two rules to FORWARD:

-A FORWARD -o docker0 -j DOCKER-IN
-A FORWARD -i docker0 -j DOCKER-OUT

Add all other rules to docker-specific chains (DOCKER-IN and -OUT can
jump to DOCKER-USER and -ISOLATION-* as desired).  This ensures that
only docker-related packets make it to the docker chains, so the docker
chains cannot modify non-docker packets.

This has the advantage that you don't need to keep testing -i docker0 or
-o docker0 on multiple rules, making the filtering more efficient.

> About 6 months ago I've moved all my application containers from Docker to 
> "rkt" and I couldn't be happier. Although still immature, in the future 
> libpod/podman will likely become a worthy Docker successor.

Thanks for this tip; I'll investigate.

> > I'm raising this back to critical (makes unrelated software on the
> > system break),
> 
> I'm lowering severity back to "important". You are not wrong that Docker is 
> hostile to other applications but I think many users would agree that we need 
> Docker in "testing" and upcoming Debian release despite of this problem.

Okay.  I understand and agree that the current situation is better than
not having docker in the archive.  Since this has the potential to break
other software on initial installation or upgrade from an older version,
can you put an item in NEWS.Debian pointing to this bug and mentioning
the /etc/docker/daemon.json workaround?

Thanks for your work packaging docker!

...Marvin

Bug#865975: #865975 docker.io breaks (bridged) network for VMs

[Marvin Renich]

Control: severity -1 critical

* Alban Browaeys  [171022 00:01]:
> The FORWARD chain policy is set to DROP by docker since 1.13.

HUH???  Since when is it okay for software that is not advertised as
firewall software to modify the sysadmin's implicit or explicit iptables
setup for IP packets completely unrelated to said software?

I understand that this is a non-trivial problem because of the history
behind /proc/sys/net/ipv4/ip_forward and the FORWARD chain, but docker
can and needs to do better.  My first approximation would be to only
change the policy for FORWARD if ip_forward was 0 before docker added
its own iptables rules.  This will probably work 99.9% of the time.

The current behavior appears to break other software 100% of the time
if that software relies on ip_forward being 1 and the FORWARD chain
being in its default state.

* Dmitry Smirnov  [180607 09:31]:
> I'm lowering severity of this bug since it is not clear how to reproduce the 
> problem and because networking is not broken for everyone...

I'm raising this back to critical (makes unrelated software on the
system break), as I cannot fathom how this could not be broken for
anyone using KVM with a bridging network interface unless they have
found one of the workarounds given in this thread (i.e. the
/etc/docker/daemon.json modification, or manually modifying the FORWARD
chain).

The following should reliably reproduce the problem (disclaimer: I
haven't gone back to a clean system and tried this from the start, but I
have been using virt-manager for a while, and installing docker.io
immediately broke networking on my VMs):

* Ensure dockerd is not running and iptables is empty and in its default
  state (FORWARD chain policy is ACCEPT).
* Install virt-manager.
* Create a virtual machine with a bridging virtual network interface
  (e.g. for network source choose "Bridge br0: Host device ens3" where
  ens3 is the host's wired interface to the LAN).
* Ensure networking on the VM works correctly (to the LAN or beyond),
  and that FORWARD chain still has POLICY ACCEPT.
* Start dockerd.

The VM's networking to the LAN or beyond (but not to the host machine)
will now be broken.

Another scenario that I expect to reliably fail is machine A with two
wired NIC's, one connected to the LAN and the other connected directly
to isolated machine B (e.g. a Raspberry Pi).  The connection between A
and B could be USB networking.

Ensure:

* The LAN gateway has a route to B via A.  (Using a different /24
  between A and B is recommended here.)
* Machine A has ip_forward set to 1, and empty, default FORWARD chain.
* Machine A has a route to B.
* Machine B can reach outside the LAN.

I would be extremely surprised if installing docker.io did not break
this scenario for machine B.

...Marvin

Bug#911539: tinysshd: Use Recommends: systemd rather than Depends

[Marvin Renich]

* Jan Mojzis  [181021 13:45]:
> fixed here: 
> https://salsa.debian.org/debian/tinyssh/commit/64ab1d6729ecf5e0a7115bffa634beb8dbb5b3e6
>  
> 

Wow!  Thanks very much for the extremely rapid fix.

...Marvin

Bug#911539: tinysshd: Use Recommends: systemd rather than Depends

[Marvin Renich]

Package: tinysshd
Version: 20180201-1

[Jan Mojžíš: this is a reply to a thread on debian-devel; some of the
statements below are directed toward that thread, not to you
personally.]

* Vincent Bernat  [181021 11:29]:
>  ❦ 21 octobre 2018 13:15 GMT, Ivan Shmakov :
> 
> >  >>> tinysshd only ships a systemd unit file; neomutt links against
> >  >>> libgpgme11 which again Depends on gnupg.  It’s the kind of
> >  >>> dependencies that individually make sense,
> >
> > I beg to differ; I suppose (though haven’t actually tried) I
> > can start tinysshd straight from rc.local just as well, or even
> > write my own init.d script, right?  Having the dependency in
> > place just makes it harder to me to contribute an init.d script
> > for the package.
> 
> tinysshd requires some kind of socket server to run. It could run from
> inetd, so if you were an actual user, I would propose you file a bug
> report against the package to let the maintainer knows the dependency is
> too strong for your use (and maybe propose a patch to integrate with
> inetd).
> 
> As you are not, please, do not. Our resources are scarce and we already
> cater for the need of many non-existent users.

Recommends, rather than Depends is correct, based on your description,
even without a patch to enable use with inetd.  Anyone who is not using
systemd, either out of dislike of systemd or because they have real
requirements for no or a stripped-down init system, is able to add a
single line to inetd (or one of its successors).

However, adding Depends just because the package ships with a systemd
unit file, and no other init integration, is simply wrong.

Don't let the fact that systemd antagonists keep annoying you prevent
you from doing the right thing.  openssh-server has an uncompressed size
of 922k with a long list of Depends.  tinysshd has an uncompressed
size of 606k with only two Depends, libc6 and systemd.  Changing systemd
to a Recommends would make tinysshd significantly more useful in some
of the use cases where its stated description "minimalistic SSH server"
already makes it the preferred ssh server.

As a general rule, please use Recommends over Depends whenever it will
not truly break the package.  This is exactly what Recommends is for.

...Marvin

Bug#909324: geeqie: please document locations of config and state files in the man page

[Marvin Renich]

* Andreas Ronnquist  [180924 11:54]:
> As you might have seen, I have forwarded this upstream, and my
> suggested patch has been accepted in the upstream Git repository, so
> this will be in the next upstream release. My patch is simply based on
> the info on
> 
> http://www.geeqie.org/help/GuideReferenceConfig.html
> 
> - I hope this covers your needs.

Thanks.  The man page is always my first choice for reference docs.

...Marvin

Bug#909324: geeqie: please document locations of config and state files in the man page

[Marvin Renich]

Package: geeqie
Version: 1:1.4+git20180820-1
Severity: minor

Please document in the man page the locations of the config files (e.g.
/etc/geeqie/geeqierc.xml and ~/.config/geeqie/geeqierc.xml) and state
files (e.g. ~/.local/share/geeqie/*) in a FILES section (man ssh is a
good example).

This is an offshoot of old bug 762231 where a deprecation warning did
not give any indication of how to resolve the warning.  But knowing
where state files are stored and how they are used will help users to be
able to clean up cruft on their system.

Thanks...Marvin

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

Kernel: Linux 4.18.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: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages geeqie depends on:
ii  geeqie-common1:1.4+git20180820-1
ii  libatk1.0-0  2.30.0-1
ii  libc62.27-6
ii  libcairo21.15.12-1
ii  libexiv2-14  0.25-4
ii  libfontconfig1   2.13.0-5
ii  libfreetype6 2.8.1-2
ii  libgcc1  1:8.2.0-6
ii  libgdk-pixbuf2.0-0   2.36.12-2
ii  libglib2.0-0 2.58.0-4
ii  libgtk2.0-0  2.24.32-3
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-3
ii  liblirc-client0  0.10.0-2+b1
ii  liblua5.1-0  5.1.5-8.1+b2
ii  libpango-1.0-0   1.42.4-3
ii  libpangocairo-1.0-0  1.42.4-3
ii  libpangoft2-1.0-01.42.4-3
ii  libstdc++6   8.2.0-6
ii  libtiff5 4.0.9-6
ii  sensible-utils   0.0.12

Versions of packages geeqie recommends:
ii  cups-bsd [lpr]   2.2.8-5
ii  exiftran 2.10-2+b3
ii  exiv20.25-4
ii  imagemagick  8:6.9.10.8+dfsg-1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.8+dfsg-1
ii  librsvg2-common  2.40.20-3
ii  ufraw-batch  0.22-3
ii  zenity   3.28.1-1

Versions of packages geeqie suggests:
pn  geeqie-dbg   
ii  gimp 2.10.6-3
ii  libjpeg-turbo-progs [libjpeg-progs]  1:1.5.2-2+b1
pn  ufraw
pn  xpaint   

-- no debconf information

Bug#762231: warning on startup: Option image.dither_quality ignored

[Marvin Renich]

* Andreas Ronnquist  [180916 10:41]:
> Hi - replying to a really old bug here -
> 
> Do you have a /etc/geeqie folder and a /etc/geeqie/geeqierc.xml file?
> 
> If not, check in $HOME/.config/geeqie/geeqierc.xml - 
> 
> If you have a line containing your mentioned option
> (image.dither_quality) in either of these files, simply remove it from either
> file.
> 
> (If I add it on an up to date geeqie 1.4+git20180820, I do get the
> warning you are mentioning, but it then removes the option, and I don't
> get the warning on subsequent startups of geeqie).
> 
> So, it should be safe to simply remove the option. - I intend to close
> this bug.

SGTM.  I don't know how long it has been since I last saw the warning,
but it has been quite a while (and I do not now have that option in
either config file).

I'm going to open a new bug asking for the locations of the config files
to be documented in the man page.  If it had been documented when I
first encountered this, I would not have considered the warning a bug
(or if the warning msg pointed to the offending config file).

...Marvin

Bug#908046: add option to hide pseudo filesystems

[Marvin Renich]

* Andreas Schwarz  [180918 13:00]:
> This possibility already exists.
> 
> The -s switch is basically for skipping certain devices, but since
> pseudo file systems use their identifiers as devices, you can also use
> this.
> 
> See lsmount.rc.example
> 
> skip = 
> "sysfs,proc,udev,sunrpc,devpts,tmpfs,cgroup,pstore,systemd-1,mqueue,securityfs,debugfs,configfs,hugetlbfs,fusectl";

Okay, thanks.  I was hoping for something where I didn't have to
enumerate all possible pseudo file systems, but I guess somebody has to
maintain that list.  It would be nice if the list were in a single
place, rather than each user having to maintain the same list on all
systems where lsmount was installed.

BTW, I would not include tmpfs in that list; those file systems are
modifiable by normal users.  Also, replace securityfs with none, as that
is the device name used by that file system type.

If you are not willing to maintain the list inside lsmount (perhaps as
an alias device name 'pseudo' recognized by skip), then you can go ahead
and close this bug.

Thanks...Marvin

Bug#908046: add option to hide pseudo filesystems

[Marvin Renich]

Package: lsmount
Version: 0.2.2-1
Severity: wishlist

Please add an option to skip display of pseudo filesystems, such as
sysfs, proc, udev, cgroup, etc.  I would like a way to show only
disk-backed filesystems and tmpfs (i.e. those on which a normal program
might be able to write).

Thanks...Marvin

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

Kernel: Linux 4.17.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: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages lsmount depends on:
ii  libc6   2.27-5
ii  libconfig9  1.5-0.4
ii  libtinfo6   6.1+20180714-1

lsmount recommends no packages.

lsmount suggests no packages.

-- no debconf information

Bug#908045: add option to select and specify order of columns

[Marvin Renich]

Package: lsmount
Version: 0.2.2-1
Severity: wishlist

I would love to have the mount point column first by default, but I'm
sure others have different tastes.  This leads me to suggest an option
to select which columns, in which order, are displayed.  To be really
useful, it would be nice to have an environment variable similar to
LS_OPTIONS for the ls command, so that I can set my defaults in my
.bashrc.

Thanks again for the useful utility!

...Marvin

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

Kernel: Linux 4.17.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: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages lsmount depends on:
ii  libc6   2.27-5
ii  libconfig9  1.5-0.4
ii  libtinfo6   6.1+20180714-1

lsmount recommends no packages.

lsmount suggests no packages.

-- no debconf information

Bug#902672: If you win but do not make the high score list, you cannot see your time

[Marvin Renich]

Package: gnome-mines
Version: 1:3.28.0-1
Severity: normal

If you win but do not make the high score list, the game goes
immediately back to the new game selection window without letting you
see what your time was.

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

Kernel: Linux 4.16.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: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages gnome-mines depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.28.0-2
ii  libc62.27-3
ii  libglib2.0-0 2.56.1-2
ii  libgnome-games-support-1-3   1.4.1-1
ii  libgtk-3-0   3.22.29-3

Versions of packages gnome-mines recommends:
ii  yelp  3.28.1-1

gnome-mines suggests no packages.

-- no debconf information

Bug#900511: libcurl4 Conflicts: libcurl3

[Marvin Renich]

Package: libcurl4
Version: 7.60.0-2
Severity: serious

libcurl4 conflicts with libcurl3, which violates the stated purpose of
the "must" clause at Policy 8.1 (to allow multiple versions of a shared
library to be co-installable), even though it doesn't violate the letter
of the must (binary package name must change when SONAME changes).
Without the second sentence at Policy 8.1, the MUST requirement serves
no purpose, so I have given this severity serious.

This means that, regardless of what Debian does with packages depending
on libcurl, libcurl4 cannot be installed if the user has third party or
home brew software that requires libcurl3.

I found this because I have netsurf-gtk installed, which Depends:
libcurl3.  netsurf-gtk is currently the same version in stable and
unstable, but has been removed from testing.

...Marvin

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

Kernel: Linux 4.15.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: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Bug#896183: Please add debian_releases to base-files (was Re: Bits from the release team: full steam ahead towards buster)

[Marvin Renich]

Package: base-files
Version: 10.1
Severity: wishlist

* Stephan Seitz  [180420 07:38]:
> On Do, Apr 19, 2018 at 11:00:37 +0200, Christoph Biedl wrote:
> > But being human I prefer names over numbers, even if it's just for
> > aesthetic reason - "buster" is just more comfortable than "debian10".
> 
> No, it’s not. I know that my systems are running Debian 8 or 9, but I always
> have to think if stretch is 9 or was it jessie.
> 
> I have to look up the name not the number.

I have often wanted to have on my system a text file containing the
correspondence between code name and release number.  I know this is one
more thing for the base-files maintainer to do during an already busy
period just before release, but if he is willing, it would be nice to
have a file, suggested to be /usr/share/doc/base-files/debian_releases,
that contains each code name with its Debian release number, as well as
the code name for the current testing release.

I know this info is in the Debian wiki, but having it in a local text
file is more convenient.  I would also be okay if this were a text file
in debian-history, but I find that solution less satisfactory than being
in base-files which is essential/required.

I would also like /etc/debian_version to contain both number and name,
but I suspect there is some resistance to this on the grounds that
scripts may be using $(cat /etc/debian_version) for comparisons.
Perhaps /etc/debian_codename?  Since debian_version contains
codename/sid for testing and unstable, debian_codename could just
contain the codename.

Santiago, if you are willing to do either or both of these, I would
appreciate it, but I certainly understand if it is just one too many
things to remember during release prep.  If you don't want
debian_releases in base-files, I'll reassign this bug to debian-history.

...Marvin

Bug#752467: python-virtualenv: no command "virtualenv"

[Marvin Renich]

* Simon McVittie <s...@debian.org> [180322 13:21]:
> [Please try to use a Subject line that will remind other developers which
> bug you're talking about when mails from it are seen out of context. I've
> retrieved the title from the original bug report.]

Oops, sorry!  I did see this and intended to fix it, but forgot.

> On Thu, 22 Mar 2018 at 12:41:33 -0400, Marvin Renich wrote:
> > I just ran into this issue.  I am installing OctoPrint from source on a
> > BeagleBone Black, and OctoPrint uses python2, and I would rather not
> > install python3 if I can avoid it.
> 
> Python 2 is no longer security-supported after 2020 (and that's about
> halfway through the expected support lifetime of buster), so in the
> buster timescale, Python 3 should really be preferred.

I agree.

> In a space-constrained environment, you can install python-virtualenv
> and run "python -m virtualenv ARGS" as a substitute for "virtualenv ARGS".
> Does that help?

Well, yes, except for lack of documentation.  Being an experienced
programmer, but relatively new to Python, I did not think of (and would
not have thought of) this until after downloading the virtualenv_*.deb
file and dissecting it.  Once I had done that, several one-time
solutions were evident.

In fact, I believe that even if I were an experienced Python programmer,
I would need to look at /usr/bin/virtualenv to know that is it simply a
cover for invoking the module with arguments.

> > My (strong) opinion is that the correct solution should involve a single
> > /usr/bin/virtualenv command that works correctly with both python2 and
> > python3.
> 
> For commands where the user neither knows nor cares how the command
> is implemented because it doesn't matter, like the tappy command from
> src:tap.py, having a single command is absolutely fine.
> 
> For commands where the version of Python used for the implementation
> matters, like python[3]-coverage and pyflakes[3], I'm not so sure about
> this reasoning.

Sure.

> virtualenv is somewhere between those extremes, because
> it has a -p/--python option, but the default if that option is not given
> is to use the same Python version used for virtualenv itself.
> 
> If I understand correctly, the script that you assert should exist
> has these semantics when run without the -p/--python option:
> 
> * Please set up a virtual environment to run Python code
> * After running this command, the virtual environment will be suitable
>   for running either Python 2 code or Python 3 code but probably not
>   both, and I can't know which
> 
> which don't seem amazingly useful? It would seem better for there to be
> a predictable default, so that at least within Debian, virtualenv does
> something consistent; and Python 2 is going to reach the end of its
> security support before buster does, so for buster, that default should
> probably be Python 3.

Okay, I see your point.  However this only makes a difference if you
have both versions of Python installed.  It is more like:

* Please set up a virtual environment to run Python code
* If only one version of Python is installed, use that.
* If more than one version is installed, in the absence of a
  command-line option to indicate otherwise (-p in this case),
  always use the preferred version (python3).

This seems perfectly useful and useable to me.

In fact, the current situation, where virtualenv depends on, and only
uses, the python3 module, is broken.  If my apt configuration installed
recommeds by default, installing python-virtualenv would have installed
python3 and python3-virtualenv.  virtualenv would have then set up a
python3 environment for OctoPrint (without me realizing it), and
OctoPrint would be broken and I would have had a much harder time
figuring out what was wrong.

The current Python naming convention, IIUC, is to use python for the
python2 interpreter, python3 for the python3 interpreter, and use
python-* and python3-* for package names for modules for the respective
versions.  I see that the python[3]-coverage and pyflakes[3] packages
(according to the pkg description) include version-specific commands.
It seems to me that maybe the correct solution for virtualenv is to have
separate virtualenv and virtualenv3 packages for the respective
versions, or simply remove virtualenv as a separate package and have the
py[3]-virtenv packages provide differently-named virtualenv commands.

The more I think about it, the more I like the latter solution.  What
was the reasoning for splitting the command into its own package?  With
the pyflakes and py-coverage precedents, it doesn't seem like users
should expect virtualenv to create a python3 environment by default, but
might reasonably expect there to be a virtualenv3 command that does.

Is it planned to include pytho

Bug#752467: (no subject)

[Marvin Renich]

Control: tags -1 patch

[I'm now subscribed to this bug; no need to CC me.]

On Tue, 18 Nov 2014 01:59:18 +0200 Stefano Rivera  wrote:
> Hi Barry (2014.11.17_22:53:01_+0200)
> > The question still remains: how best to upgrade people who have
> > /usr/bin/virtualenv provided by python-virtualenv in Wheezy, so that they 
> > now
> > get /usr/bin/virtualenv provided by virtualenv in Jessie?  Using Recommends
> > was an attempt at that, but clearly it's not good enough.
> 
> Taking a step back, I think the only way to reliably do this is to have
> virtualenv be Python2 for jessie, and change it to Python 3 in stretch.
> 
> so:
> python-virtualenv Depends virtualenv
> virtualenv Depends python-virtualenv (ick a loop. Avoidable?)
> 
> and in stretch:
> virtualenv Depends python3-virtualenv
> 
> By then, anybody using virtualenv has had the virtualenv package
> installed.

I just ran into this issue.  I am installing OctoPrint from source on a
BeagleBone Black, and OctoPrint uses python2, and I would rather not
install python3 if I can avoid it.

My (strong) opinion is that the correct solution should involve a single
/usr/bin/virtualenv command that works correctly with both python2 and
python3.  I have attached such a script (only tested with python2) based
on Brian May's suggestion to use the trick from django-admin.

Once this is done, the dependencies sort themselves out very nicely:

python-virtualenv Recommends: virtualenv
python3-virtualenv Recommends: virtualenv
virtualenv Depends: python3-virtualenv (>= someversion) | python-virtualenv (>= 
someversion)

virtualenv should not depend on python or python3; this will happen
transitively from the python{,3}-virtualenv dependencies.

A Depends is the correct dependency in virtualenv, because it is useless
and doesn't function unless one of the modules is installed.

A Recommends is the correct dependency in python*-virtualenv because
either can by used as a python module without the virtualenv command,
but a user would normally have the command installed as well.

Anyone with a default apt configuration (i.e. installs Recommends by
default) will upgrade correctly.  Those (like me) who don't install
Recommends by default should be looking for new Recommends when
upgrading and should be able to handle the situation.

I believe that replacing the current /usr/bin/virtualenv with the
attached script and adjusting the dependencies as described above will
allow closing this bug, and I see no downsides.

...Marvin

#!/bin/sh
# EASY-INSTALL-ENTRY-SCRIPT: 'virtualenv==15.1.0','console_scripts','virtualenv'
shell_code=''' '
# shell code
if command -v python3 > /dev/null && test -e 
/usr/lib/python3/dist-packages/virtualenv.py
then
exec python3 "$0" "$@"
elif command -v python2.7 > /dev/null && test -e 
/usr/lib/python2.7/dist-packages/virtualenv.py
then
exec python2.7 "$0" "$@"
else
echo "Cannot find installed version of python-virtualenv or 
python3-virtualenv." >&2
exit 1
fi

python_code='''
# python code
# ONLY use DOUBLE quotes <"> after this line
__requires__ = "virtualenv==15.1.0"
import re
import sys
from pkg_resources import load_entry_point

if __name__ == "__main__":
sys.argv[0] = re.sub(r"(-script\.pyw?|\.exe)?$", "", sys.argv[0])
sys.exit(
load_entry_point("virtualenv==15.1.0", "console_scripts", 
"virtualenv")()
)

# End of Python code. Do not modify this line. #'

Bug#885436: /var/log/aptitude shows wrong architecture for architecture:all packages

[Marvin Renich]

clone 885436 -1
reassign -1 apt 1.6~alpha5
retitle -1 /var/log/apt shows wrong architecture for arch:all packages
thanks

* David Kalnischkies <da...@kalnischkies.de> [180102 06:03]:
> On Mon, Jan 01, 2018 at 05:09:21PM -0500, Marvin Renich wrote:
> > IOW, using pkg-name:amd64 in the log loses information that is harder to
> > recover, while using pkg-name:all hides an internal detail of aptitude's
> > processing that is trivial to obtain.
> 
> I can't argue about aptitudes log, but it sounds like it would be
> similar to /var/log/apt/history.log in what it contains. In that log it
> is also always pkg:native instead of pkg:all.

That seems wrong as well to me.

> I don't think "sometimes" saying pkg:all will help you much as there are
> still the "rare" situations in which that info will be wrong as the
> 'all' applies to the old/new version only, so you have to work with this
> either way and it is "just" a matter of how often a certain codepath is
> called.

Actually, it helps a great deal, even when a binary package changes
between native and all (either way), as long as the log gives the old
package's stated arch.  Whether changing architecture is rare or common,
the current log entry is unhelpful, and giving the old pkg arch is
significantly more helpful.

Determining both the new pkg arch and the native arch are trivial
without it being stated in the log; finding the old pkg arch is
non-trivial unless it is in the log.

> Perhaps it is a matter of what you are doing that you need this
> architecture – I can only imagine it being needed to guess download URIs
> which I consider a problem enough (mirror selection, filenames,
> security, …) that native/all is trivial to solve (e.g. try all after
> native failed) or is solved as by-product (for security you need indexes
> and in those indexes the filenames are given).

You are actually proving my point.  Knowing whether to look in
http://snapshot.debian.org/archive/debian/20171201/dists/buster/main/binary-all/
or
http://snapshot.debian.org/archive/debian/20171201/dists/buster/main/binary-amd64/
to begin with is a big jump forward.  By having the package
architecture, the URIs for both the Packages file and the .deb file are
deterministic.  If you only have the native architecture, you have to go
searching to figure out which package architecture is the right one.

The native architecture is a detail of the internal operation of
aptitude (and apt), and does not represent how packages are stored in
the archive or how packages are identified by users.

These log files are primarily meant for sysadmins, to record changes (or
intended changes) to the system, not as debugging aids for internal
apt/aptitude problems (though they are probably useful for that, as
well).

> But as said, I am not here to decide what aptitude should (not) do. I am
> just saying what apt does (not) and why in a similar case.

I hadn't looked at apt's logs.  I also think this is a bug there, as
well.  I'm cloning this bug to apt.

...Marvin

Bug#885436: /var/log/aptitude shows wrong architecture for architecture:all packages

[Marvin Renich]

* David Kalnischkies  [180101 15:48]:
> On Thu, Dec 28, 2017 at 12:45:14AM +0100, Manuel A. Fernandez Montecelo wrote:
> > > In the extremely rare (I think) case where an upgrade (or downgrade)
> > > replaces a specific architecture package with an architecture all
> > > package, or vice versa, I would be okay with my script breaking because
> > > it does not have enough information from /var/log/aptitude to get it
> > > right.  E.g. I think it is okay to arbitrarily choose one architecture
> > > or the other, but I think it is more useful to know the architecture of
> > > the package being replaced than that of the one being installed.
> > 
> > I wonder if it's because apt treats internally :all packages as the
> > native arch, but it doesn't make much sense, I think that the string
> > printed should still be :all.
> 
> The architecture for a package in apt is never 'all' as this isn't
> a property of the package for preciously the reason Marvin outlines as
> "extremely rare" case – it just isn't that rare.

[good explanation snipped]

Thanks for the explanation.  However, I believe that the log file should
still identify the architecture as specified in the control file, rather
than the architecture that apt is using for dependency and upgrade
resolution.  The log file is used by the human (or a script) after the
fact to identify what happened; it is irrelevant in that context that
aptitude internally substitutes the default dpkg architecture for
arch:all packages in aptitude's internal processing.

Even if you think it is not irrelevant, it is much easier for a human or
script to take pkg-name:all from the log and deduce that aptitude used
pkg-name:amd64 in its processing than it is for a human or script to see
pkg-name:amd64 in the log and then try to determine if it is really
pkg-name:amd64 or was originally pkg-name:all.

IOW, using pkg-name:amd64 in the log loses information that is harder to
recover, while using pkg-name:all hides an internal detail of aptitude's
processing that is trivial to obtain.

...Marvin

Bug#885443: debsnap: should allow writing output to existing directory without -f

[Marvin Renich]

Package: devscripts
Version: 2.17.11
Severity: wishlist
File: /usr/bin/debsnap

It is clear that it was a conscious decision to give an error when
downloading a source or binary package to an existing directory (without
-f), but I don't understand what real problem this solves.  On the other
hand, I would expect an error if the output file already exists, and
would expect -f to override this and replace the output file.

The documentation does not specify what happens, with or without -f,
when the destination file exists.  Does -f allow overwriting an existing
.deb file, or just writing the .deb to an existing directory if the .deb
file doesn't exist?

I am writing a script to back out of an upgrade that had unintended
consequences.  The script generates a list of (package, version,
architecture) tuples (a multiarch system with amd64 and i386 packages)
that are not necessarily sorted, and uses debsnap to download the .deb
files.  This script fails because I want both amd64 and i386 versions of
some packages, but because they are requested via separate invocations
of debsnap, the destination dir (but not destination file) already
exists when the second architecture is requested.  The script would
require significant extra logic to sort the tuples and combine different
architectures for the same package into a single debsnap invocation.

I would like to see the behavior changed so that the existence of the
destination directory is irrelevant, and the presence of -f determines
whether to give an error if the output file exists (no -f) or overwrite
a pre-existing output file (-f).

Perhaps if I understood the real use case for the current behavior, I
would be less eager to ask for a change, but it sounds like the current
behavior was designed to guard against unrealistic circumstances, but
fails at doing so.  How do you guarantee that no other process writes to
the destination directory after debsnap creates it?  Under what
circumstances would some other process be trying to write to the
destination directory, and why?

The best you can do is ensure that debsnap does not overwrite an
existing file, and creating a new output directory is neither necessary
nor sufficient to accomplish that.

...Marvin

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
Not present

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

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: sysvinit (via /sbin/init)

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.0.4
ii  libc6 2.25-3
ii  libfile-homedir-perl  1.002-1
ii  perl  5.26.1-3
ii  python3   3.6.4~rc1-2
ii  sensible-utils0.0.11

Versions of packages devscripts recommends:
ii  apt 1.6~alpha5
ii  at  3.1.20-3.1
ii  curl7.57.0-1
ii  dctrl-tools 2.24-2+b1
ii  debian-keyring  2017.11.24
ii  dput-ng [dput]  1.15
pn  equivs  
ii  fakeroot1.22-2
ii  file1:5.32-1
ii  gnupg   2.2.3-1
ii  libdistro-info-perl 0.17
ii  libdpkg-perl1.19.0.4
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.047-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
ii  libsoap-lite-perl   1.23-1
ii  liburi-perl 1.72-2
ii  libwww-perl 6.29-1
ii  licensecheck3.0.31-2
ii  lintian 2.5.65
ii  man-db  2.7.6.1-4
ii  patch   2.7.5-1+b2
ii  patchutils  0.3.4-2
ii  python3-apt 1.4.0~beta3+b1
ii  python3-debian  0.1.31
ii  python3-magic   1:5.32-1
ii  python3-requests2.18.1-1
pn  python3-unidiff 
ii  python3-xdg 0.25-4
ii  strace  4.19-1
ii  unzip   6.0-21
ii  wdiff   1.2.2-2
ii  wget1.19.2-1
ii  xz-utils5.2.2-1.3

Versions of packages devscripts suggests:
pn  adequate 
pn  autopkgtest  
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20160123cvs-4
ii  build-essential  12.4
pn  check-all-the-things 
pn  cvs-buildpackage 
pn  devscripts-el
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  faketime 
ii  gnuplot   

Bug#885437: debsnap: fails when an old version uses a now-invalid version number

[Marvin Renich]

Package: devscripts
Version: 2.17.11
Severity: normal

If a package has in the past used a version number that is no longer
valid, debsnap cannot download any version of that package.

$ debsnap --binary -d . -a amd64 libnspr4 2:4.16-1
debsnap: error: M18-3 is not a valid version

According to snapshot.debian.org, in 2009 libnspr4 was built from source
package mozilla version M18-3.  This is no longer a valid Debian version
number, but was then(?).  debsnap cannot download a recent version of
this package because the available-version information from snapshot.d.o
contains a version number that debsnap doesn't know how to handle.

...Marvin

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
Not present

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

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: sysvinit (via /sbin/init)

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.0.4
ii  libc6 2.25-3
ii  libfile-homedir-perl  1.002-1
ii  perl  5.26.1-3
ii  python3   3.6.4~rc1-2
ii  sensible-utils0.0.11

Versions of packages devscripts recommends:
ii  apt 1.6~alpha5
ii  at  3.1.20-3.1
ii  curl7.57.0-1
ii  dctrl-tools 2.24-2+b1
ii  debian-keyring  2017.11.24
ii  dput-ng [dput]  1.15
pn  equivs  
ii  fakeroot1.22-2
ii  file1:5.32-1
ii  gnupg   2.2.3-1
ii  libdistro-info-perl 0.17
ii  libdpkg-perl1.19.0.4
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.047-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
ii  libsoap-lite-perl   1.23-1
ii  liburi-perl 1.72-2
ii  libwww-perl 6.29-1
ii  licensecheck3.0.31-2
ii  lintian 2.5.65
ii  man-db  2.7.6.1-4
ii  patch   2.7.5-1+b2
ii  patchutils  0.3.4-2
ii  python3-apt 1.4.0~beta3+b1
ii  python3-debian  0.1.31
ii  python3-magic   1:5.32-1
ii  python3-requests2.18.1-1
pn  python3-unidiff 
ii  python3-xdg 0.25-4
ii  strace  4.19-1
ii  unzip   6.0-21
ii  wdiff   1.2.2-2
ii  wget1.19.2-1
ii  xz-utils5.2.2-1.3

Versions of packages devscripts suggests:
pn  adequate 
pn  autopkgtest  
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20160123cvs-4
ii  build-essential  12.4
pn  check-all-the-things 
pn  cvs-buildpackage 
pn  devscripts-el
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  faketime 
ii  gnuplot  5.2.2+dfsg1-2
ii  gnuplot-qt [gnuplot] 5.2.2+dfsg1-2
ii  gpgv 2.2.3-1
pn  how-can-i-help   
ii  libauthen-sasl-perl  2.1600-1
ii  libfile-desktopentry-perl0.22-1
pn  libnet-smtps-perl
pn  libterm-size-perl
ii  libtimedate-perl 2.3000-2
pn  libyaml-syck-perl
ii  mailutils [mailx]1:3.4-1
pn  mozilla-devscripts   
ii  mutt 1.9.2-1
ii  openssh-client [ssh-client]  1:7.6p1-2
pn  piuparts 
ii  quilt0.63-8.1
pn  ratt 
pn  reprotest
pn  svn-buildpackage 
ii  w3m  0.5.3-34.1

-- no debconf information

Bug#885436: /var/log/aptitude shows wrong architecture for architecture:all packages

[Marvin Renich]

Package: aptitude
Version: 0.8.10-1
Severity: normal

/var/log/aptitude shows the default architecture (e.g. amd64) when
logging actions pertaining to an architecture:all package, e.g.

[UPGRADE] console-setup:amd64 1.171 -> 1.172

should be

[UPGRADE] console-setup:all 1.171 -> 1.172

This is making it more difficult to write a script to back out of last N
updates using debsnap, because debsnap can download debs for a specific
architecture or all available architectures, but does not automatically
select an architecture:all deb when a specific architecture is requested
(reasonable behavior for debsnap).

In the extremely rare (I think) case where an upgrade (or downgrade)
replaces a specific architecture package with an architecture all
package, or vice versa, I would be okay with my script breaking because
it does not have enough information from /var/log/aptitude to get it
right.  E.g. I think it is okay to arbitrarily choose one architecture
or the other, but I think it is more useful to know the architecture of
the package being replaced than that of the one being installed.

...Marvin

-- Package-specific info:
Terminal: screen
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.10
Compiler: g++ 7.2.0
Compiled against:
  apt version 5.0.2
  NCurses version 6.0
  libsigc++ version: 2.10.0
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.0.20171125
  cwidget version: 0.5.17
  Apt version: 5.0.2

aptitude linkage:
linux-vdso.so.1 (0x7ffc98f75000)
libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 
(0x7f8c1698d000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 
(0x7f8c1675d000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7f8c16533000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7f8c1632c000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7f8c16031000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f8c15d29000)
libboost_iostreams.so.1.62.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.62.0 (0x7f8c15b11000)
libboost_filesystem.so.1.62.0 => 
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.62.0 (0x7f8c158f8000)
libboost_system.so.1.62.0 => 
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.62.0 (0x7f8c156f4000)
libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 
(0x7f8c152e9000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f8c150cb000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f8c14d4c000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f8c14a39000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f8c14822000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f8c1447f000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7f8c14269000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f8c1404f000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f8c13e3f000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f8c13c19000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7f8c13a07000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f8c137e9000)
/lib64/ld-linux-x86-64.so.2 (0x7f8c1734b000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f8c135e5000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f8c133dd000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f8c131d8000)

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

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: sysvinit (via /sbin/init)

Versions of packages aptitude depends on:
ii  aptitude-common0.8.10-1
ii  libapt-pkg5.0  1.6~alpha5
ii  libboost-filesystem1.62.0  1.62.0+dfsg-4+b2
ii  libboost-iostreams1.62.0   1.62.0+dfsg-4+b2
ii  libboost-system1.62.0  1.62.0+dfsg-4+b2
ii  libc6  2.25-3
ii  libcwidget3v5  0.5.17-6
ii  libgcc11:7.2.0-18
ii  libncursesw5   6.0+20171125-1
ii  libsigc++-2.0-0v5  2.10.0-1
ii  libsqlite3-0   3.21.0-1
ii  libstdc++6 7.2.0-18
ii  libtinfo5  6.0+20171125-1
ii  libxapian301.4.5-1

Versions of packages aptitude recommends:
ii  libparse-debianchangelog-perl  1.2.0-12
ii  sensible-utils 0.0.11

Versions of packages aptitude suggests:

Bug#883713: packages.debian.org: search contents of packages will not find full path

[Marvin Renich]

Package: www.debian.org
Severity: normal

Go to https://packages.debian.org/index and enter
/etc/bluetooth/main.conf under "Search the contents of packages".
Ensure default "packages that contain files named like this" is
selected, distribution stretch, architecture any, and press search.  The
result is "Sorry, your search gave no results".

If you remove "/etc", so the keyword is "/bluetooth/main.conf", you get
the expected result, file "/etc/bluetooth/main.conf" found in package
"bluez".  (Just removing the leading /, as in "etc/bluetooth/main.conf"
does not work either.)

...Marvin

Bug#880051: less: please bump priority to important

[Marvin Renich]

I strongly agree.  Whenever I build a chroot with debootstrap or
cdebootstrap, I am surprised to find less missing.

...Marvin

Bug#755434: pmount: please support exfat filesystem (via fuse)

[Marvin Renich]

* Vincent Fourmond  [170908 16:18]:
>   Oops, looks like I completely missed the patch.
> 
>   I'll review/apply ASAP, but I need to wait until my updated key is
> back in the keyring.
> 
>   Thanks for your patience,

No problem.

I had prepared an almost identical patch before looking to see if there
was already a bug.  My patch included a change to src/pmount.c at line
365:

-else if(! strcmp(fsname, "vfat") && fs->iocharset_format) {
+else if((!strcmp(fsname, "vfat") || !strcmp(fsname, "exfat")) && 
fs->iocharset_format) {

It seems to be a workaround for a bug in mount specific to vfat, so it
is probably unnecessary.  But I thought I would mention it, in case it
jogs your memory about why that test was added.

...Marvin

Bug#755434: pmount: please support exfat filesystem (via fuse)

[Marvin Renich]

tags 755434 patch
thanks

Vincent Danjean added a patch in his msg on 25 Dec 2016.  I'm setting
the appropriate tag, and adding my "please apply this patch" to the bug
report.

Many thanks for maintaining this package, as well as (hopefully) adding
this patch!

...Marvin

Bug#835377: godoc requires explicit GOROOT

[Marvin Renich]

Package: golang-golang-x-tools
Version: 1:0.0~git20160315.0.f42ec61-2
Severity: normal

The general recommendation is to not set GOROOT, because the go tools
know what it should be with a default install (see [1] and [2] and
numerous discussions on golang-nuts mailing list).

However, godoc does not use the implicit GOROOT (the one shown by go
env) and requires setting it explicitly to get expected behavior (e.g.
providing documentation for standard library packages).

...Marvin

[1] https://golang.org/doc/install
[2] http://dave.cheney.net/2013/06/14/you-dont-need-to-set-goroot-really

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

Kernel: Linux 4.6.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages golang-golang-x-tools depends on:
ii  golang-golang-x-tools-dev  1:0.0~git20160315.0.f42ec61-2
ii  libc6  2.23-4

golang-golang-x-tools recommends no packages.

golang-golang-x-tools suggests no packages.

-- no debconf information

Bug#834941: closed by Roland Rosenfeld (Bug#834941: fixed in privoxy 3.0.25-2)

[Marvin Renich]

* Debian Bug Tracking System  [160823 06:39]:
> This is an automatic notification regarding your Bug report
> which was filed against the privoxy package:
> 
> #834941: privoxy segfaults with listen-address :8118
> 
> It has been closed by Roland Rosenfeld .
> 
> From: Roland Rosenfeld 
> Date: Tue, 23 Aug 2016 10:34:50 +
> Subject: Bug#834941: fixed in privoxy 3.0.25-2
> To: 834941-cl...@bugs.debian.org
> 
> Source: privoxy
> Source-Version: 3.0.25-2
> 
> We believe that the bug you reported is fixed in the latest version of
> privoxy, which is due to be installed in the Debian FTP archive.
> 
> Source: privoxy
> Version: 3.0.25-2
> Closes: 827327 834941
> Changes:
>  privoxy (3.0.25-2) unstable; urgency=medium
>* 36_listen-nohost: Fix crashes with "listen-addr :8118" (Closes: #834941).

Thanks, Roland, for the extremely quick fix for this!

...Marvin

Bug#834941: privoxy segfaults with listen-address :8118

[Marvin Renich]

Package: privoxy
Version: 3.0.25-1
Severity: normal

Dear Maintainer,

If the config file contains

listen-address :8118

privoxy starts, correctly listens on all interfaces (as shown by lsof -i -n),
but terminates with a segfault when a connection is attempted from other than
localhost.  Changing the listen-address to *:8118 resolves the problem, but
privoxy should not segfault with :8118.  Either it should refuse to start,
giving an appropriate error message, or, preferably, it should treat :port and
*:port as synonyms.

Thanks...Marvin


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.6.0-1-amd64 (SMP w/1 CPU core)
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 privoxy depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.59
ii  init-system-helpers1.42
ii  libc6  2.23-4
ii  libpcre3   2:8.39-1
ii  logrotate  3.8.7-2
ii  lsb-base   9.20160629
ii  ucf3.0036
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages privoxy recommends:
pn  doc-base  

privoxy suggests no packages.

-- debconf information:
  privoxy/listen-address: 127.0.0.1:8118 [::1]:8118

Bug#832109: add postfix config and command line option

[Marvin Renich]

Package: milter-greylist
Version: 4.5.11-1
Severity: wishlist
Tags: patch

Please add a runtime option to select behavior appropriate for Postfix.
I believe this should replace the USE_POSTFIX macro, but the attached
patches do not remove this macro (or associated configure option).

My rational is that, while a compile-time option might be appropriate
for software that is compiled by the end user, who is likely to only be
using one MTA, or for a distribution like Gentoo that compiles software
at install-time, the binary package distributed by Debian is likely to
be used with both Postfix and Exim, and perhaps other MTAs.

The included patches add a "-x" command-line option and corresponding
config file option "postfix" to enable Postfix-specific behavior.  This
option currently only suppresses one warning.

The suppressed warning (which the --enable-postfix configure option and
corresponding USE_POSTFIX macro currently remove at compile time), is
completely useless in a Postfix environment, but is emitted once for
each message processed by milter-greylist.  This just clutters the log
files.

I envision this option being used to enable other Postfix-specific
behavior in the future, if such behavior is identified.

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

Kernel: Linux 4.6.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Index: milter-greylist-4.5.11/milter-greylist.c
===
--- milter-greylist-4.5.11.orig/milter-greylist.c
+++ milter-greylist-4.5.11/milter-greylist.c
@@ -515,7 +515,9 @@ real_envfrom(ctx, envfrom)
 		 * until after it accepts the first valid RCPT TO 
 		 * command, so don't log the failure 
 		 */
-		mg_log(LOG_DEBUG, "smfi_getsymval failed for {i}");
+		if (conf.c_postfix == 0) {
+			mg_log(LOG_DEBUG, "smfi_getsymval failed for {i}");
+		}
 #endif
 		priv->priv_queueid = "(unknown id)";
 	}
@@ -1605,7 +1607,7 @@ main(argc, argv)
 	/* 
 	 * Process command line options 
 	 */
-	while ((ch = getopt(argc, argv, "Aa:cvDd:qw:f:hp:P:Tu:rSL:M:l")) != -1) {
+	while ((ch = getopt(argc, argv, "Aa:cvDd:qw:f:hp:P:Tu:rSL:M:lx")) != -1) {
 		switch (ch) {
 		case 'A':
 			defconf.c_noauth = 1;
@@ -1799,6 +1801,11 @@ main(argc, argv)
 			defconf.c_forced |= C_ACLDEBUG;
 			break;
 
+		case 'x':
+			defconf.c_postfix = 1;
+			defconf.c_forced |= C_POSTFIX;
+			break;
+
 		case 'h':
 		default:
 			usage(argv[0]);
@@ -3251,7 +3258,7 @@ fstring_expand(priv, rcpt, fstring, cv)
 fqdn = host;
 			}
 
-			snprintf(output, HDRLEN, 
+			snprintf(output, HDRLEN,
  "milter-greylist-%s (%s [%s]); %s %s (%s)",
 			 PACKAGE_VERSION, fqdn, local_ipstr(priv),
  timestr, tzstr, tznamestr);
Index: milter-greylist-4.5.11/conf.c
===
--- milter-greylist-4.5.11.orig/conf.c
+++ milter-greylist-4.5.11/conf.c
@@ -493,5 +493,6 @@ conf_defaults(c)
 	c->c_syncmaxqlen = SYNC_MAXQLEN;
 	(void)memset(>c_localaddr, 0, sizeof(c->c_localaddr));
 	(void)memset(>c_localaddr_string, 0, sizeof(c->c_localaddr_string));
+	c->c_postfix = 0;
 	return;
 }
Index: milter-greylist-4.5.11/conf.h
===
--- milter-greylist-4.5.11.orig/conf.h
+++ milter-greylist-4.5.11/conf.h
@@ -123,6 +123,7 @@ struct conf_rec {
 	struct sockaddr_storage c_localaddr;
 	char c_localaddr_string[IPADDRSTRLEN];
 	int c_fixldapcheck;
+	int c_postfix;
 };
 
 /* c_forced flags */
@@ -146,6 +147,7 @@ struct conf_rec {
 #define C_DOMAINEXACT	0x1
 #define C_TARPIT	0x2
 #define C_TARPIT_SCOPE	0x4
+#define C_POSTFIX	0x8
 #define C_NOTFORCED(x) 	((conf.c_forced & (x)) == 0) 
 
 /* c_report */
Index: milter-greylist-4.5.11/conf_lex.l
===
--- milter-greylist-4.5.11.orig/conf_lex.l
+++ milter-greylist-4.5.11/conf_lex.l
@@ -143,6 +143,7 @@ log_local6	[Ll][Oo][Cc][Aa][Ll]6
 log_local7	[Ll][Oo][Cc][Aa][Ll]7
 p0fsock		[Pp]0[Ff][Ss][Oo][Cc][Kk]
 p0f		[Pp]0[Ff]
+postfix		[Pp][Oo][Ss][Tt][Ff][Ii][Xx]
 spamdsock	[Ss][Pp][Aa][Mm][Dd][Ss][Oo][Cc][Kk]
 spamdsockt	[Ii][Nn][Ee][Tt]|[Uu][Nn][Ii][Xx]
 spamd		[Ss][Pp][Aa][Mm][Dd]
@@ -314,6 +315,7 @@ type		[Tt][Yy][Pp][Ee]
 {domatch}	{ return DOMATCH; }
 {p0fsock}	{ return P0FSOCK; }
 {p0f}		{ BEGIN(S_REGEX); return P0F; }
+{postfix}	{ return POSTFIX; }
 {spamdsock}	{ return SPAMDSOCK; }
 {spamdsockt}	{ 
 			strncpy(yylval.spamdsockt, yytext, QSTRLEN);
Index: milter-greylist-4.5.11/conf_yacc.y
===
--- milter-greylist-4.5.11.orig/conf_yacc.y
+++ milter-greylist-4.5.11/conf_yacc.y
@@ -13,7 +13,7 @@
 %token LOGFAC_MAIL LOGFAC_DAEMON LOGFAC_AUTH 

Bug#825793: Installing the lilo bootloader on a qemu/kvm VM fails

[Marvin Renich]

Package: installation-reports
Severity: important
Tags: d-i

Installing lilo bootloader on qemu/kvm virtual machine fails.

-- Package-specific info:

Boot method: CD
Image version: 
http://cdimage.debian.org/cdimage/stretch_di_alpha6/amd64/iso-cd/debian-stretch-DI-alpha6-amd64-netinst.iso
Date: 

Machine: qemu/kvm using virt-manager
Partitions: 
(I cannot cut-and-paste from the virt-viewer, but here is an abridged
summary, typed by hand)

/dev/vda1 is mounted on both /target and /dev/.static/dev.
/dev/sr0 is mounted on both /target/media/cdrom0 and /cdrom.

sfdisk -l /dev/vda gives

DeviceBoot Start  End  Sectors Size Id Type
/dev/vda1  2048 14678015 14675968   7G 83 Linux


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[E]
Overall install:[ ]

Comments/Problems:

I created a virtual machine using virt-manager and used the stretch DI
alpha 6 netinst to install Debian.  I selected expert (non-graphical)
install.  I used manual partitioning to create a single partition
without a swap partition.  The other options were defaults, except for
things like hostname and initial user (no root login).  When I skipped
"Install GRUB boot loader" and selected "Install LILO boot loader", then
selected "/dev/vda: Master Boot Record", I get the "Installation step
failed" dialog.

As a side note, the actual command that failed and the output from that
command would help immensely.  The idea that "technical output" scares
users is flawed; when something goes wrong, even if the user is unable
to understand the lower level diagnostics, providing it allows the user
to find help more easily and/or provide more useful bug reports.

I am going to guess (and this is just a guess) that what I would have
seen, had the output to the command been visible, was either

/bin/sh: liloconfig: not found

or 

/bin/sh: lilo: not found

as switching to another console shows that neither command is installed.


-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

I have snipped the installer-hardware summary, as I believe the host
environment is completely irrelevant to this bug, other than it is an
amd64 architecture.  If there is a specific piece of information that
would help in the diagnosis, I will be more than happy to provide it.

I am using libvirt-clients, libvirt-daemon, and libvirt-daemon-system
version 1.3.3-2; virt-manager 1:1.3.2-4; qemu 1:2.5+dfsg-5+b1.

Thanks...Marvin

Bug#741654: Please provide tcl-tls for non-default tcl8.6

[Marvin Renich]

Control: severity -1 normal

This bug just bit me in testing (stretch).  I'm raising the severity to
normal based on the following rationale:

  The different versions of tcl are intended to be co-installable, and
  in fact at least the last two stable releases (I didn't look back
  farther) have had at least two versions of tcl.

  The current tcl-tls package breaks software that uses it if any of the
  following are true:

The user has only installed a version of tcl that does not work with
the installed version (in stable there is only one version) of
tcl-tls.

The dependent software explicitly uses a version of tcl that does
not work with the installed version of tcl-tls (this appears to be
the case for coccinella).

The user chooses (by way of the symlink /usr/bin/tclsh) a version of
tcl that does not work with the installed version of tcl-tls.

  Any of these conditions can reasonably happen in either stable or
  testing.

I would like to thank Petter Reinholdtsen and Mike Gabriel for the
excellent bug report (#698485) and subsequent investigation that made it
easy for me to diagnose my problem and find a work-around (downgrade
tcl-tls to the one in stable).

Thanks...Marvin

Bug#804544: please document the --no-dereference option in the man page

[Marvin Renich]

Package: diffutils
Version: 1:3.3-2
Severity: minor

The --no-dereference option is documented in the info docn and in the
--help output, but not in the man page.  Perhaps help2man was not run
recently enough?

Thanks...Marvin


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

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

Versions of packages diffutils depends on:
ii  libc6  2.19-22

diffutils recommends no packages.

Versions of packages diffutils suggests:
pn  diffutils-doc  
ii  wdiff  1.2.2-1

-- no debconf information

Bug#801065: Section 6.4 - discourage failing install or upgrade when service fails to start

[Marvin Renich]

* Henrique de Moraes Holschuh <h...@debian.org> [151007 09:42]:
> On Mon, Oct 5, 2015, at 22:13, Marvin Renich wrote:
> > The discussion started on d-devel; should it be moved back there?  The
> > overwhelming majority of opinion seems to be in favor of the change.
> 
> We have supported per-package behavior on this for a very long time,
> maybe since forever (this is no joke).  We have had packages that
> restart after the upgrade instead of stopping before, or that ignore
> service start failures during upgrades for *years*.

Agreed.

> All it takes is that the package maintainer actually stop to think about
> it, consider which behavior is more appropriate to that specific
> package, and adjust things appropriately.

I enthusiastically agree!

> There is a damn good reason
> why policy does not use "must" to mandate service start/stop/restart
> behavior across package updates.

Again, agreed.  I was not proposing to use "must", and would not support
such a proposal.

> The reason for this thread, an "undesired" behavior of stopping a
> package upgrade if the service fails to start, which is the current
> default, is both employed by the (likely few) packages that absolutely
> depend on it to avoid worse damage down the service/package dependency
> chain, as well as by packages that the maintainer did not even think
> about the issue (and therefore might or might not need this behavior).

Right.  And the second case, which is at least perceived by me (and
apparently others) to be the vast majority of services, is what this
proposal is about.

> IMO, we should not just "change this default" in the *implementation*
> (debhelper, etc), at least not without actually acessing the real risk
> of the change.  It does not look like this kind of risk accessment was
> done by anyone yet in the d-devel thread.  Just because we expect it to
> be low, doesn't mean it doesn't exist or that it won't have a high
> impact on the user if it happens.

Actually, I was not aware that dh had a helper for this that defaulted
to "fail upgrade if service fails", and so was not intending to propose
an automatic change in behavior based on a change to dh.  This part of
it certainly requires more thought and a thorough risk assessment.

My proposal, and what I still think we should do regardless of any
change or lack of change to dh, is to document, in a place that package
maintainers will see, that the "best practice" is to not fail the
install just because the service fails to start.

> If the need for this kind of provision in a possible policy text update
> (possibly as a foot-note) is contentious, IMHO the matter needs to go
> back to d-devel for further discussion.

I don't see this as a contentious change; at least the part about
changing what is considered "best practice".  Changing dh hasn't, as far
as I can see, been discussed enough to know whether it is contentious or
not.  But, as you point out, a risk assessment followed by some
discussion on d-devel would be the first two steps.

I don't think a documentation change to "best practices" should be held
up by the dh issue.  Perhaps someone wants to clone this bug to the
debhelper package so the documentation change to developers-reference
and the potential implementation change to debhelper are tracked
independently.  If you would like me to do so, let me know.

...Marvin

Bug#801065: Section 6.4 - discourage failing install or upgrade when service fails to start

[Marvin Renich]

Package: developers-reference
Version: 3.4.16
Severity: wishlist

As discussed on debian-devel starting at [1], I would like a comment
added to Section 6.4 "Best practices for maintainer scripts" that
recommends preventing the postinst script from returning failure when a
service fails to start.

A general rule of thumb is that if the corrective action would not
otherwise require re-running dpkg, then the postinst should behave as if
the installation succeeded.

An example of a case where postinst should succeed is if the admin,
prior to an upgrade, modified a configuration file which resulted in the
service being unable to restart during the upgrade.

Another example is if the service requires another resource to be
available that might be on another machine (e.g. a database).

The rational is that the failure has nothing to do with the installation
process or the contents of the .deb.  The service might just as well
have failed on reboot even though it was correctly installed.

I will send a follow-up message that contains a condensed digest of the
thread beginning at [1].

...Marvin

[1] https://lists.debian.org/debian-devel/2015/09/msg00496.html

Bug#801065: Section 6.4 - discourage failing install or upgrade when service fails to start

[Marvin Renich]

* Russ Allbery  [151005 18:24]:
> I'm also in favor.  However, this is a very substantial change to Debian
> practice, and I'm not sure what process should be used for making this
> kind of decision.  This wasn't a gap in our specification; rather, the
> previous standard was explicitly chosen (by at least some folks).  Failure
> to install was intentional and believed better since it didn't hide
> service failures.

I understand that this was intentional, but it is not the only way to
make sure the user (admin) is informed of the failure.

It was suggested in the discussion on d-devel that some other
notification mechanism could be implemented instead of installation
failure.

I was thinking about a special dpkg trigger that would be handled
internally by dpkg.  Packages would, in their postinst, place a file
containing non-fatal but important failure information in a directory
owned by dpkg.  This info would be printed out by dpkg at the end of the
run, and would also be passed to front ends that asked.

Front ends such as aptitude could ask dpkg for these notifications.  If
a large installation needed to be split into multiple calls to dpkg, the
front end can aggregate the notifications and present them all at the
very end, in whatever way is native to the front end.

One of the other notifications that I, personally, would like to see
this used for is when a configuration file has changes that cannot be
handled automatically.  Currently you are asked in the middle of the
installation; this would not change at all.  But it would be nice to
have a summary at the end of all the config files that had incompatible
changes, regardless of how I answered the dpkg or ucf prompt.

> I feel like this would benefit from a broader discussion than just the
> Policy list, but I'm not sure how to go about that, or what teams in
> particular should weigh in.

The discussion started on d-devel; should it be moved back there?  The
overwhelming majority of opinion seems to be in favor of the change.

...Marvin

Bug#801065: digest of debian-devel discussion leading to this bug

[Marvin Renich]

Here is a condensation of the discussion prior to filing this bug.  I
have removed all quotes of previous messages (e.g. msg [2] contained
quotes from msg [1] that have been removed).  I have tried to identify
when a message is a reply to parts of several messages or to a message
that is not the previous message in this digest.  When in doubt, refer
to the original message.

[1] https://lists.debian.org/debian-devel/2015/09/msg00496.html
* Marvin Renich <m...@renich.org> [150923 13:53]:
> 
> 
> From the first time I had dpkg mark a package as half-configured when
> everything was correct except that the service would not start for some
> reason that had nothing to do with package installation (exactly the
> situation here for virtualbox), I have felt that dpkg had no business
> failing just because the service would not start.  I think that is a
> wrong design decision.
> 
> In fact, one specific case that often hurts me is when I have xen
> installed on a machine where I only run the hypervisor occasionally.
> Upgrading the xen packages causes (or has caused in the past) the
> upgrade to fail.  This is ridiculous!
> 
> I think it should be documented in the developers reference that if you
> attempt to start or restart a service in postinst, you should guard it
> so that a failure in the service does not propagate to a failure of the
> postinst.
> 
> 

[2] https://lists.debian.org/debian-devel/2015/09/msg00508.html
* Jeroen Dekkers <jer...@dekkers.ch> [150924 07:23]:
> But then when something goes wrong when upgrading and the service
> doesn't (re)start apt/dpkg will report success but the service isn't
> running anymore. That also sounds wrong to me. Letting postinst fail
> might not be the best way to signal this, but to change that we need
> something else to let the user know that something went wrong. Just
> printing an error message isn't enough, because the user might not see
> that (for example when multiple packages are installed/upgraded and a
> later package asks some questions using dialog or when using
> unattended-upgrades).

[3] https://lists.debian.org/debian-devel/2015/09/msg00511.html
* Marvin Renich <m...@renich.org> [150924 08:12]:
> How does failing the upgrade solve anything?  The upgrade should only
> fail if the failure of the service to start was because something in the
> upgrade itself was broken; this is rarely the case.
> 
> There are two prominent reasons why a service fails to start after an
> upgrade:  the relationship between the application and its configuration
> has changed (e.g. different, incompatible defaults or incompatible file
> format) or some external influence that has nothing to do with the
> upgrade (e.g.  unavailable resource).
> 
> The first case requires the admin to sort out the changes and fix the
> configuration.  Being required to re-run the dpkg installation just to
> flip the 'half-configured' state to 'installed' when the result would
> have been the same if dpkg had not failed the first time is wrong.
> 
> In the second case, how is it a dpkg installation failure if the
> hypervisor is not running so xen won't start?  Everything is installed
> perfectly.  Or if a daemon fails to start because the ldap server on a
> different host is down?  Failing the installation is _really_, _really_
> _wrong_!
> 
> What makes this even worse is that when installing or upgrading a large
> number of packages, this kind of incorrect failure sometimes affects
> many completely unrelated packages.  For an unattended upgrade, this is
> so much worse than having one service that (for a correct reason)
> refused to restart after the upgrade.
> 
> What you are looking for is a more prominent notification that a service
> did not restart.  But the current situation is like the "check engine"
> light flashing when you are low on fuel; yes, it gets your attention,
> but it is telling you the wrong thing.

[4] https://lists.debian.org/debian-devel/2015/09/msg00518.html
* Henrique de Moraes Holschuh <h...@debian.org> [150924 12:21]:
> What we really want is a "do not fail upgrade, BUT report that some services
> *that were previously running* failed to restart after the upgrade run".
> 
> ESPECIALLY if you are going to take "unattended upgrades" seriously.
> 
> Still, that would need some proper design work, and a reasonable amount of
> code to be written and tested.  Some of it will hook into the package
> system, some of it needs to interface to the services subsystem (systemd,
> sysvinit, others).

[5] https://lists.debian.org/debian-devel/2015/09/msg00519.html
* Paul Gevers <elb...@debian.org> [150924 14:12]:
> I would like to add there is more than just services. As the current
> maintain

Bug#800969: hangs during upgrade

[Marvin Renich]

Package: ntopng
Version: 2.0+dfsg1-1
Severity: normal

When upgrading from version 1.2.1+dfsg1-2 to 2.0+dfsg1-1, the postinst
script hung.  Note that this machine is still using sysvinit, not
systemd.  The relevant pstree output:

root@basil:~# pstree -ap 7441
aptitude,7441 -u
  ├─dpkg,19994 --status-fd 107 --configure libndpi2:amd64 libjs-bootstrap:all 
ntopng-data:all ntopng:amd64...
  │   └─frontend,20002 -w /usr/share/debconf/frontend 
/var/lib/dpkg/info/ntopng.postinst configure 1.2.1+dfsg1-2
  │   └─(ntopng.postinst,20008)
  └─{aptitude},12945

Sorry, I did not notice if ntopng was running at this point or not, but
I believe it was for two reasons.  The output from aptitude at this
point was

Setting up ntopng-data (2.0+dfsg1-1) ...
Setting up ntopng (2.0+dfsg1-1) ...
[ ok ] Starting network top daemon: ntopng.

At which point I killed frontend (20002) and aptitude continued with

dpkg: error processing package ntopng (--configure):
 subprocess installed post-installation script was killed by signal (Terminated)

and then later:

Errors were encountered while processing:
 ntopng
E: Sub-process /usr/bin/dpkg returned an error code (1)
W: Operation was interrupted before it could finish
Failed to perform requested operation on package.  Trying to recover:
Setting up ntopng (2.0+dfsg1-1) ...
[ ok ] Starting network top daemon: ntopng already running.
Press Return to continue.


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

Kernel: Linux 4.1.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages ntopng depends on:
ii  init-system-helpers  1.23
ii  libc62.19-22
ii  libcurl3-gnutls  7.44.0-2
ii  libgcc1  1:5.2.1-17
ii  libgeoip11.6.6-1+b1
ii  libhiredis0.13   0.13.1-2
ii  libjson-c2   0.11-4
ii  libluajit-5.1-2  2.0.4+dfsg-1
ii  libndpi2 1.6-1
ii  libpcap0.8   1.7.4-1
ii  librrd4  1.5.4-5
ii  libsqlite3-0 3.8.11.1-1
ii  libstdc++6   5.2.1-17
ii  libzmq3  4.0.5+dfsg-3
ii  ntopng-data  2.0+dfsg1-1
ii  redis-server 2:3.0.4-6

ntopng recommends no packages.

Versions of packages ntopng suggests:
ii  geoip-database-contrib  1.17+nmu1

-- no debconf information

Bug#775318: Bug#796529: ITP: local-apt-repository -- Ready to use local apt repository

[Marvin Renich]

* Joachim Breitner nome...@debian.org [150823 07:24]:
 With pow-priority, you mean one that does not get shown by default? But
 is that much better than allowing the interested admin to change the
 configuration afterwards?

Actually, I was thinking it should be similar to postfix, which looks
like it is using medium priority for most questions (sorry, that was my
mistake).

 Note that my package does _not_ touch or put files in /srv. It merely
 uses files that are put in a certain directory that, that the admin has
 to create first. Does that mitigate your concerns?

Somewhat.  Still, it mandates that a specific directory in /srv be used.

Current practice in Debian, based on a very small sample, is to use a
subdirectory of /var, such as /var/www or /var/lib/pkgname.  You would
certainly be following precedent if you did something like this.

However, after reading bug #775318 (CC'ed, as the rest of this message
pertains to this specific package as well as the debian-policy bug), I
am forming some new opinions.

First, it now appears to me that the FHS authors:

1.  intended for /srv to be used for things like this.

2.  intended for the structure of /srv to be primarily under control of
the local admin.

3.  recognized that this directory was relatively new and best practices
had not been established.  They intentionally left the details
unspecified to allow distributions to arrive at a consensus.

In order for both distributions and local admins to safely share /srv,
there must be some rules about how the namespace is divided.  For /usr
and /var, distributions were alloted all except one subdirectory of
each:  /usr/local and /var/local.  This gives distributions primary
control over these two top-level directories.

To give local admins primary control of /srv, we should do the converse,
and reserve one top-level subdirectory for distributions (perhaps
/srv/pkg; other suggestions welcome), and leave the remainder of the
/srv namespace available for the local admin.  So you might use
/srv/pkg/local-apt-repository.

There currently does not appear to be any precedent in Debian for a
package to use /srv as a default, so it would be nice for the first
package to do so to get it right.  Once packages start usurping
top-level subdirectories of /srv, it will be difficult to ebb the tide.

I do think that for packages where it makes sense to use a subdirectory
of /srv, it also makes sense to ask the admin what directory to use,
giving a sensible suggestion as a default.

...Marvin

Bug#764132: fails to compile with linux-image-3.16-2-amd64

[Marvin Renich]

Package: blktap-dkms
Version: 2.0.91-1
Severity: normal

With both linux-image-3.2.0-4-amd64 and linux-image-3.16-2-amd64 installed,
blktap fails to compile for the 3.16-2 kernel, but succeeds for the 3.2.0-4
kernel.  (Contrary to the dependency listing below, I do have the headers for
3.16-2 installed.)

I am attaching the build log.


-- System Information:
Debian Release: 7.6
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'testing'), (200, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages blktap-dkms depends on:
ii  dkms 2.2.0.3-1.2
ii  libc6-dev2.19-11
ii  linux-headers-3.2.0-2-amd64 [linux-headers]  3.2.19-1
ii  linux-headers-3.2.0-4-amd64 [linux-headers]  3.2.60-1+deb7u3
ii  linux-headers-amd64 [linux-headers]  3.2+46
ii  linux-libc-dev   3.2.60-1+deb7u3

blktap-dkms recommends no packages.

blktap-dkms suggests no packages.

-- no debconf information
DKMS make.log for blktap-2.0.91 for kernel 3.16-2-amd64 (x86_64)
Sun Oct  5 12:54:39 EDT 2014
make: Entering directory `/usr/src/linux-headers-3.16-2-amd64'
make[1]: Entering directory `/usr/src/linux-headers-3.16-2-amd64'
  CC [M]  /var/lib/dkms/blktap/2.0.91/build/control.o
In file included from /var/lib/dkms/blktap/2.0.91/build/linux-blktap.h:66:0,
 from /var/lib/dkms/blktap/2.0.91/build/blktap.h:32,
 from /var/lib/dkms/blktap/2.0.91/build/control.c:30:
/var/lib/dkms/blktap/2.0.91/build/linux-blktap.h:119:24: warning: variably 
modified ‘pending’ at file scope [enabled by default]
sizeof(((struct blktap_sring *)0)-ring[0])))
^
/usr/src/linux-headers-3.16-2-common/include/xen/interface/io/ring.h:15:59: 
note: in definition of macro ‘__RD2’
 #define __RD2(_x)  (((_x)  0x0002) ? 0x2 : ((_x)  0x1))
   ^
/usr/src/linux-headers-3.16-2-common/include/xen/interface/io/ring.h:17:66: 
note: in expansion of macro ‘__RD4’
 #define __RD8(_x)  (((_x)  0x00f0) ? __RD4((_x)4)4: __RD4(_x))
  ^
/usr/src/linux-headers-3.16-2-common/include/xen/interface/io/ring.h:18:66: 
note: in expansion of macro ‘__RD8’
 #define __RD16(_x) (((_x)  0xff00) ? __RD8((_x)8)8: __RD8(_x))
  ^
/usr/src/linux-headers-3.16-2-common/include/xen/interface/io/ring.h:19:66: 
note: in expansion of macro ‘__RD16’
 #define __RD32(_x) (((_x)  0x) ? __RD16((_x)16)16 : __RD16(_x))
  ^
/var/lib/dkms/blktap/2.0.91/build/linux-blktap.h:117:8: note: in expansion of 
macro ‘__RD32’
  ((int)__RD32((BLKTAP_PAGE_SIZE -\
^
/var/lib/dkms/blktap/2.0.91/build/blktap.h:75:41: note: in expansion of macro 
‘BLKTAP_RING_SIZE’
  struct blktap_request *pending[BLKTAP_RING_SIZE];
 ^
  CC [M]  /var/lib/dkms/blktap/2.0.91/build/ring.o
In file included from /var/lib/dkms/blktap/2.0.91/build/linux-blktap.h:66:0,
 from /var/lib/dkms/blktap/2.0.91/build/blktap.h:32,
 from /var/lib/dkms/blktap/2.0.91/build/ring.c:30:
/var/lib/dkms/blktap/2.0.91/build/linux-blktap.h:119:24: warning: variably 
modified ‘pending’ at file scope [enabled by default]
sizeof(((struct blktap_sring *)0)-ring[0])))
^
/usr/src/linux-headers-3.16-2-common/include/xen/interface/io/ring.h:15:59: 
note: in definition of macro ‘__RD2’
 #define __RD2(_x)  (((_x)  0x0002) ? 0x2 : ((_x)  0x1))
   ^
/usr/src/linux-headers-3.16-2-common/include/xen/interface/io/ring.h:17:66: 
note: in expansion of macro ‘__RD4’
 #define __RD8(_x)  (((_x)  0x00f0) ? __RD4((_x)4)4: __RD4(_x))
  ^
/usr/src/linux-headers-3.16-2-common/include/xen/interface/io/ring.h:18:66: 
note: in expansion of macro ‘__RD8’
 #define __RD16(_x) (((_x)  0xff00) ? __RD8((_x)8)8: __RD8(_x))
  ^
/usr/src/linux-headers-3.16-2-common/include/xen/interface/io/ring.h:19:66: 
note: in expansion of macro ‘__RD16’
 #define __RD32(_x) (((_x)  0x) ? __RD16((_x)16)16 : __RD16(_x))
  ^
/var/lib/dkms/blktap/2.0.91/build/linux-blktap.h:117:8: note: in expansion of 
macro ‘__RD32’
  ((int)__RD32((BLKTAP_PAGE_SIZE -\
^
/var/lib/dkms/blktap/2.0.91/build/blktap.h:75:41: note: in expansion of macro 
‘BLKTAP_RING_SIZE’
  struct blktap_request *pending[BLKTAP_RING_SIZE];
  

Bug#764135: fails to compile with linux-image-3.2.0-4-amd64

[Marvin Renich]

Package: blktap-dkms
Version: 2.0.93-0.3
Severity: normal

With both linux-image-3.2.0-4-amd64 and linux-image-3.16-2-amd64 installed,
blktap fails to compile for the 3.2.0-4 kernel, but succeeds for the 3.16-2
kernel.  (Headers for both kernel versions are installed.)

I am attaching the build log.

Note that bug 764132 is for blktap-dkms version 2.0.91-1 and fails for the
opposite kernel version.  The combination of these two bugs means that I cannot
choose which kernel version to boot from without first upgrading or downgrading
blktap-dkms to match the kernel version I wish to boot (i.e. I cannot have a
single blktap-dkms package that works with both kernel versions).

Additionally, with both kernels installed, when dkms fails to build the module
for the first kernel, it does not attempt to build it for the second, so that
the build must be done by hand after aptitude finishes the upgrade.


-- System Information:
Debian Release: 7.6
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'testing'), (200, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages blktap-dkms depends on:
ii  dkms2.2.0.3-1.2
ii  libc6-dev   2.19-11
ii  linux-libc-dev  3.2.60-1+deb7u3

Versions of packages blktap-dkms recommends:
ii  linux-headers-amd64  3.2+46

blktap-dkms suggests no packages.

-- no debconf information
DKMS make.log for blktap-2.0.93 for kernel 3.2.0-4-amd64 (x86_64)
Sun Oct  5 13:27:21 EDT 2014
make: Entering directory `/usr/src/linux-headers-3.2.0-4-amd64'
  CC [M]  /var/lib/dkms/blktap/2.0.93/build/control.o
In file included from /var/lib/dkms/blktap/2.0.93/build/control.c:30:0:
/var/lib/dkms/blktap/2.0.93/build/blktap.h:77:41: warning: variably modified 
‘pending’ at file scope [enabled by default]
  CC [M]  /var/lib/dkms/blktap/2.0.93/build/ring.o
In file included from /var/lib/dkms/blktap/2.0.93/build/ring.c:38:0:
/var/lib/dkms/blktap/2.0.93/build/blktap.h:77:41: warning: variably modified 
‘pending’ at file scope [enabled by default]
/var/lib/dkms/blktap/2.0.93/build/ring.c: In function ‘blktap_ring_map_request’:
/var/lib/dkms/blktap/2.0.93/build/ring.c:214:2: error: implicit declaration of 
function ‘vm_mmap’ [-Werror=implicit-function-declaration]
/var/lib/dkms/blktap/2.0.93/build/ring.c: In function 
‘blktap_ring_unmap_request’:
/var/lib/dkms/blktap/2.0.93/build/ring.c:234:2: error: implicit declaration of 
function ‘vm_munmap’ [-Werror=implicit-function-declaration]
/var/lib/dkms/blktap/2.0.93/build/ring.c: In function 
‘blktap_ring_make_tr_request’:
/var/lib/dkms/blktap/2.0.93/build/ring.c:314:32: error: ‘struct bio’ has no 
member named ‘bi_iter’
cc1: some warnings being treated as errors
make[3]: *** [/var/lib/dkms/blktap/2.0.93/build/ring.o] Error 1
make[2]: *** [_module_/var/lib/dkms/blktap/2.0.93/build] Error 2
make[1]: *** [sub-make] Error 2
make: *** [all] Error 2
make: Leaving directory `/usr/src/linux-headers-3.2.0-4-amd64'

Bug#761062: Upgrading from 304.117-1 to 340.32-1 with older graphics card leaves system without X Windows

[Marvin Renich]

* Andreas Beckmann a...@debian.org [140923 03:46]:
 We already have a NEWS entry about the legacy stuff - but nobody reads
 that or uses apt-listchanges.

Having a NEWS entry is important, but not sufficient.  I filed this bug
because the problem happened on my father's machine (which does have
apt-listchanges installed).  However, even if he were to have read the
changes carefully, he would not have known which specific GPU model he
has, nor would he have realized that it was important to find out before
continuing.

 We could probably reuse the approach I used for fglrx-driver in wheezy
 where AMD removed support for some legacy hardware ... and created a
 legacy driver that has not been maintained for newer Xorg versions ...
 
 Raw outline: While installing or upgrading to the current (not a legacy)
 nvidia-driver (not sure which package this should go to) we have a
 debconf prompt in preinst that reports *unsupported* hardware (having
 *no* supported hardware in a system is not an error) and asks whether to
 proceed or abort. The answer will be remembered for future upgrades.
 This check can be disabled via preseeding to allow unattended
 installations in such setups - the admin probably knows what he does in
 this case.
 We probably need two cases here: totally unsupported and
 legacy-supported, giving hints about the legacy package to install instead.
 
 nvidia-detect is probably *not* the tool for this task.

I still believe that a debconf prompt is the wrong solution.  If the
currently installed version of nvidia-kernel-dkms and/or nvidia-driver
supports the hardware, but the new version does not, and the appropriate
legacy packages are not installed, the upgrade should fail.  Period.
There is no reason to prompt the user, and the debconf priority should
not have any bearing on the outcome.

Looking closer at nvidia-detect, it doesn't provide enough information
by itself, because it doesn't have the nvidia.ids file for both the
currently installed package and the new version of the package.

I think what is needed is for nvidia-kernel-{legacy-.*}?dkms
and nvidia-{legacy-.*}?driver to each have their own copy of the
nvidia.ids file (4K).  Then, during preinst, check if the unpacked (new)
version of that file contains the pci id for the GPU.  If it does,
continue with the installation (the hardware is still supported).

Otherwise, check the nvidia.ids file from the currently installed
(older) package.  If that file does not have the pci id, then the older
package didn't support this hardware either, so we can safely continue
the installation; we aren't going to break something that was working
before the upgrade.

Now we have the case that the GPU was supported by the currently
installed package, but is not supported by the new package.  Has the
user installed an appropriate legacy package?  Look for the pci id in
the nvidia.ids files in all the installed legacy packages.  If you don't
find it, abort the installation.

If you found it, does the nvidia alternative point to that legacy
package?  If yes, continue the installation, otherwise, abort.

One thing I am not sure about is whether the unpacked files are moved
into their proper place in the file system before or after running the
preinst script.  If the are moved before, then we need a different
method to obtain the nvidia.ids file of the old package.

...Marvin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762231: warning on startup: Option image.dither_quality ignored

[Marvin Renich]

Package: geeqie
Version: 1:1.2-1
Severity: minor

Geeqie prints the following warning message on startup:

Option image.dither_quality ignored: deprecated since 2012-08-13

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable'), (200, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages geeqie depends on:
ii  geeqie-common1:1.2-1
ii  libatk1.0-0  2.12.0-1
ii  libc62.19-11
ii  libcairo21.12.16-5
ii  libexiv2-13  0.24-4
ii  libfontconfig1   2.11.0-6.1
ii  libfreetype6 2.5.2-1.1
ii  libgcc1  1:4.9.1-14
ii  libgdk-pixbuf2.0-0   2.30.8-1
ii  libglib2.0-0 2.40.0-5
ii  libgtk2.0-0  2.24.24-1
ii  libjpeg8 8d1-1
ii  liblcms2-2   2.6-3
ii  liblircclient0   0.9.0~pre1-1
ii  libpango-1.0-0   1.36.7-1
ii  libpangocairo-1.0-0  1.36.7-1
ii  libpangoft2-1.0-01.36.7-1
ii  libstdc++6   4.9.1-14
ii  libtiff5 4.0.3-10

Versions of packages geeqie recommends:
ii  cups-bsd [lpr]   1.7.5-1
ii  exiftran 2.07-14
ii  exiv20.24-4
ii  imagemagick  8:6.8.9.6-4
ii  librsvg2-common  2.40.3-2
ii  ufraw-batch  0.19.2-3+b1
pn  zenity   none

Versions of packages geeqie suggests:
pn  geeqie-dbg none
ii  gimp   2.8.10-2
ii  libjpeg-progs  8d1-1
pn  ufraw  none
pn  xpaint none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#761062: Upgrading from 304.117-1 to 340.32-1 with older graphics card leaves system without X Windows

[Marvin Renich]

* Vincent Cheng vch...@debian.org [140912 04:37]:
 I'd like to point out that the various nvidia packages are (supposed
 to be) co-installable, letting you pick what driver series to use at
 runtime rather than during package installation (and the kernel
 modules are patched so that they're versioned as well), so I don't
 think we should forcefully fail package installation attempts of
 nvidia drivers that aren't compatible with the user's hardware. Again,
 probably a debconf prompt invoking nvidia-detect at some point would
 be appropriate.

The non-legacy and legacy packages being co-installable isn't sufficient
to solve this problem.  When the non-legacy packages were installed,
they had the correct drivers (kernel and X) for the given hardware, and
there were no legacy packages that had drivers for that hardware.
When nVidia deprecated drivers for a selection of older hardware, they
created a new legacy package, and removed support for those video cards
from the non-legacy package.  Now the user performs a normal upgrade,
getting the new version of the non-legacy package which no longer
supports the user's hardware.  The package has essentially been renamed
from nvidia-kernel-dkms to nvidia-legacy-304xx-kernel-dkms for _some_
users of nvidia-kernel-dkms but not all.

If this were a simple rename, the normal Replaces and Conflicts dance
would get the new package installed correctly, but Debian's package
management system does not have a way to describe that one package
conditionally supersedes another.

Because this bug leaves the system in a severely broken state, I believe
a failed upgrade is the only viable solution.  The upgrade should fail
iff

the version of the non-legacy package on the system before the
upgrade supported the hardware and the new version does not,

and either of the following is true:

the legacy packages that support the hardware are not installed
(both kernel and X),

the nvidia alternative does not point to the version that supports
the hardware.

I don't believe a debconf prompt is helpful here.  If the above
conditions are met, you want the upgrade to fail (the user presumably
had a working system prior to the upgrade and will definitely have a
broken system if the upgrade continues).  If the above conditions are
not met, you do not want to fail the upgrade, as the nvidia upgrade will
not affect the system (either the system was working prior to the
upgrade and will continue to work afterward, or the system wasn't
working prior to the upgrade so the upgrade won't break anything that
wasn't already broken).

Note that using nvidia-detect in the preinst, which is what I think is
needed to fix this, will require a PreDepends on nvidia-detect.  I think
having the non-legacy packages bring this in as at least a Recommends
would have been a good thing all along, so I don't think that is a big
deal.

...Marvin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#761063: changes to /etc/inittab are not respected on upgrade from sysvinit

[Marvin Renich]

Package: systemd-sysv
Version: 208-8
Severity: normal

On a system with dbndns, daemontools, and daemontools-run installed,
when upgrading from sysvinit to systemd, the changes to /etc/inittab are
not respected, so dnscache and tinydns did not start.  In my case, this
left an entire local network without dns service.


-- System Information:
Debian Release: 7.6
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'testing-updates'), (500, 
'stable-updates'), (500, 'testing'), (200, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages systemd-sysv depends on:
ii  systemd  208-8

systemd-sysv recommends no packages.

systemd-sysv suggests no packages.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#761062: Upgrading from 304.117-1 to 340.32-1 with older graphics card leaves system without X Windows

[Marvin Renich]

Source: nvidia-graphics-drivers
Version: 340.32-1
Severity: important

On a machine with a graphics card supported by version 304, but
relegated to the legacy packages for version 340, upgrading the
nvidia-kernel-dkms and nvidia-driver packages leaves the system with an
unusable X Windows system.

The preinst script should determine if the hardware was supported by the
old version of the package but not the new version, and give the
sysadmin an opportunity to fail the upgrade, with an appropriate
explanation.


-- System Information:
Debian Release: 7.6
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'testing-updates'), (500, 
'stable-updates'), (500, 'testing'), (200, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#743895: transaction report crashes

[Marvin Renich]

Package: gnucash
Version: 1:2.6.2-1
Severity: normal

When configuring a transaction report, gnucash crashes with the python
traceback below.  When starting gnucash, the lines in the traceback up
to and including Found Finance::Quote version 1.18 occur immediately,
but gnucash seems to start normally, with my previously open register
windows opened.

I select Transaction Report which brings up an empty report (No accounts
selected).  I select Options. On the General tab I change start and end
dates to start and end of previous year.  On the Sorting tab I change
secondary subtotal for date key to none.  I click Apply and there is no
change in the report (expected, because I haven't selected any
accounts), and there is no additional console output.  Now, on the
Accounts tab I select Expenses and then Select Children.  When I select
Apply, the remainder of the traceback is printed and the gnucash window
disappears.

Prior to upgrading from 1:2.6.1-2 to 1:2.6.2-1, the lines beginning
Traceback... through ImportError... did not occur; on startup, the
first line of console output was Found Finance::Quote version 1.18.
However, the crash did occur in version 1:2.6.1-2 (current testing).
The only reason I upgraded gnucash from testing to unstable was to
determine if this bug existed in the newest version.

...Marvin

$ gnucash
Traceback (most recent call last):
  File /usr/share/gnucash/python/init.py, line 3, in module
from gnucash import *
ImportError: No module named gnucash
Found Finance::Quote version 1.18
In report.scm:
 770: 19 [gnc:report-run 0]
In unknown file:
   ?: 18 [gnc-set-busy-cursor () #t]
In ice-9/boot-9.scm:
 157: 17 [catch #t #catch-closure 36beb20 #catch-closure 36beb00 #f]
In unknown file:
   ?: 16 [apply-smob/1 #catch-closure 36beb20]
In ice-9/boot-9.scm:
 171: 15 [with-throw-handler #t #catch-closure 36be8c0 #catch-closure 
36be7e0]
In unknown file:
   ?: 14 [apply-smob/1 #catch-closure 36be8c0]
   ?: 13 [call-with-input-string (gnc:report-run 0) ...]
In ice-9/boot-9.scm:
2320: 12 [save-module-excursion #procedure 3667e40 at 
ice-9/eval-string.scm:65:9 ()]
In ice-9/eval-string.scm:
  44: 11 [read-and-eval #input: string 312a410 #:lang ...]
  37: 10 [lp (gnc:report-run 0)]
In report.scm:
 771: 9 [gnc:report-run 0]
In ice-9/boot-9.scm:
 157: 8 [catch ignore #procedure 3667c30 at gnucash/main.scm:112:4 () ...]
In unknown file:
   ?: 7 [lazy-catch #t #procedure 3667bd0 at gnucash/main.scm:114:18 () ...]
In ice-9/boot-9.scm:
 171: 6 [with-throw-handler #t #catch-closure 36be2c0 #catch-closure 
36be2a0]
In unknown file:
   ?: 5 [apply-smob/1 #catch-closure 36be2c0]
In report.scm:
 775: 4 [#procedure 3667c60 at report.scm:772:5 ()]
 754: 3 [gnc:report-render-html # #t]
In html-document.scm:
 196: 2 [gnc:html-document-render # #t]
In ice-9/boot-9.scm:
 102: 1 [#procedure 347cc00 at ice-9/boot-9.scm:97:6 (thrown-k . args) 
vm-error ...]
In unknown file:
   ?: 0 [apply-smob/1 #catch-closure 36be2a0 vm-error ...]
Aborted


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable'), (200, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.12-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gnucash depends on:
ii  gnucash-common 1:2.6.2-1
ii  guile-2.0  2.0.9+1-1
ii  guile-2.0-libs 2.0.9+1-1
ii  libaqbanking34 5.4.1beta-1
ii  libc6  2.18-4
ii  libcairo2  1.12.16-2
ii  libcrypt-ssleay-perl   0.58-1+b1
ii  libdate-manip-perl 6.43-1
ii  libdbi10.9.0-1
ii  libfinance-quote-perl  1.18-2
ii  libgdk-pixbuf2.0-0 2.30.6-1
ii  libglib2.0-0   2.38.2-5
ii  libgnome-keyring0  3.4.1-1
ii  libgnomecanvas2-0  2.30.3-2
ii  libgoffice-0.8-8   0.8.17-3
ii  libgtk2.0-02.24.22-1
ii  libgwengui-gtk2-0  4.11.0beta-1
ii  libgwenhywfar604.11.0beta-1
ii  libhtml-tableextract-perl  2.11-1
ii  libhtml-tree-perl  5.03-1
ii  libktoblzcheck1c2a 1.45-1
ii  libofx41:0.9.4-2.1
ii  libpango-1.0-0 1.36.3-1
ii  libpangocairo-1.0-01.36.3-1
ii  libpython2.7   2.7.6-8
ii  libwebkitgtk-1.0-0 2.2.6-1
ii  libwww-perl6.05-2
ii  libx11-6   2:1.6.2-1
ii  libxml22.9.1+dfsg1-3
ii  libxslt1.1 1.1.28-2
ii  perl   5.18.2-2+b1
ii  zlib1g 1:1.2.8.dfsg-1

Versions of packages gnucash recommends:
ii  gnucash-docs  2.6.2-1
ii  yelp  3.10.1-1

Versions of packages gnucash suggests:
pn  libdbd-mysqlnone
pn  libdbd-pgsqlnone
pn  libdbd-sqlite3  none

-- no debconf information


-- 
To UNSUBSCRIBE, email to 

Bug#697407: xen-utils-4.1: pygrub doesn't find extlinux.conf in default Debian location

[Marvin Renich]

Package: xen-utils-4.1
Version: 4.1.3-7
Severity: normal

pygrub looks for extlinux config files /boot/isolinux/isolinux.cfg and
/boot/extlinux.conf, but the default Debian installation uses the
config file /boot/extlinux/extlinux.conf.  (See
/usr/lib/xen-4.1/bin/pygrub lines 405-407.)

...Marvin

-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), 
(500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages xen-utils-4.1 depends on:
ii  e2fslibs  1.42.5-1
ii  libc6 2.13-37
ii  libgnutls26   2.12.20-2
ii  libncurses5   5.9-10
ii  libpci3   1:3.1.9-6
ii  libtinfo5 5.9-10
ii  libuuid1  2.20.1-5.3
ii  libxen-4.14.1.3-7
ii  libxenstore3.04.1.3-7
ii  python2.7.3~rc2-1
ii  python2.7 2.7.3~rc2-2.1
ii  xen-utils-common  4.1.3-7
ii  zlib1g1:1.2.7.dfsg-13

Versions of packages xen-utils-4.1 recommends:
ii  bridge-utils   1.5-6
ii  qemu-keymaps   1.1.2+dfsg-3
ii  qemu-utils 1.1.2+dfsg-3
ii  xen-hypervisor-4.1-amd64 [xen-hypervisor-4.1]  4.1.3-7

Versions of packages xen-utils-4.1 suggests:
ii  xen-docs-4.1  4.1.3-7

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#697409: xen-utils-4.1: pygrub does not correctly distinguish between disk with partitions and partition

[Marvin Renich]

Package: xen-utils-4.1
Version: 4.1.3-7
Severity: normal

The function is_disk_image in /usr/lib/xen-4.1/bin/pygrub at line 45
distinguishes a partitioned disk from a partition by looking for 0xaa55
at offset 0x1fe in the image, but this is the bootsector signature, not
the partition table signature.  extlinux and other bootloaders put this
signature there on bootable partitions (which don't have partition
tables).

A better heuristic, though still very fallible, would be to check if all
four pairs of [start-sector, sector-count] entries were either [0,0] or
reasonable for the size of the file (if the file size can be
determined), and that at least one pair is not [0,0].

...Marvin


-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), 
(500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages xen-utils-4.1 depends on:
ii  e2fslibs  1.42.5-1
ii  libc6 2.13-37
ii  libgnutls26   2.12.20-2
ii  libncurses5   5.9-10
ii  libpci3   1:3.1.9-6
ii  libtinfo5 5.9-10
ii  libuuid1  2.20.1-5.3
ii  libxen-4.14.1.3-7
ii  libxenstore3.04.1.3-7
ii  python2.7.3~rc2-1
ii  python2.7 2.7.3~rc2-2.1
ii  xen-utils-common  4.1.3-7
ii  zlib1g1:1.2.7.dfsg-13

Versions of packages xen-utils-4.1 recommends:
ii  bridge-utils   1.5-6
ii  qemu-keymaps   1.1.2+dfsg-3
ii  qemu-utils 1.1.2+dfsg-3
ii  xen-hypervisor-4.1-amd64 [xen-hypervisor-4.1]  4.1.3-7

Versions of packages xen-utils-4.1 suggests:
ii  xen-docs-4.1  4.1.3-7

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#697412: xen-utils-4.1: pygrub does not recognize the include statement in extlinux.conf

[Marvin Renich]

Package: xen-utils-4.1
Version: 4.1.3-7
Severity: normal

pygrub does not recognize the include statement in extlinux.conf.  The
default Debian installation of extlinux creates a stub extlinux.conf
which includes linux.cfg, where all the linux image entries are.  This
means that even if bugs 697407 and 697409 are fixed, pygrub still can't
find the right kernel on a default Debian installation where extlinux
has been installed as the bootloader.

A workaround for bug 697407 and this bug is to

$ ln -s /boot/extlinux/linux.cfg /boot/extlinux.conf

...Marvin


-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), 
(500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages xen-utils-4.1 depends on:
ii  e2fslibs  1.42.5-1
ii  libc6 2.13-37
ii  libgnutls26   2.12.20-2
ii  libncurses5   5.9-10
ii  libpci3   1:3.1.9-6
ii  libtinfo5 5.9-10
ii  libuuid1  2.20.1-5.3
ii  libxen-4.14.1.3-7
ii  libxenstore3.04.1.3-7
ii  python2.7.3~rc2-1
ii  python2.7 2.7.3~rc2-2.1
ii  xen-utils-common  4.1.3-7
ii  zlib1g1:1.2.7.dfsg-13

Versions of packages xen-utils-4.1 recommends:
ii  bridge-utils   1.5-6
ii  qemu-keymaps   1.1.2+dfsg-3
ii  qemu-utils 1.1.2+dfsg-3
ii  xen-hypervisor-4.1-amd64 [xen-hypervisor-4.1]  4.1.3-7

Versions of packages xen-utils-4.1 suggests:
ii  xen-docs-4.1  4.1.3-7

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#697417: xen-utils-4.1: pygrub is unable to parse default Debian grub.cfg

[Marvin Renich]

Package: xen-utils-4.1
Version: 4.1.3-7
Severity: normal

The grub.cfg created by a default Debian installation uses many
configuration statements that pygrub does not recognize, and pygrub is
unable to find any kernel to load.

...Marvin


-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), 
(500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages xen-utils-4.1 depends on:
ii  e2fslibs  1.42.5-1
ii  libc6 2.13-37
ii  libgnutls26   2.12.20-2
ii  libncurses5   5.9-10
ii  libpci3   1:3.1.9-6
ii  libtinfo5 5.9-10
ii  libuuid1  2.20.1-5.3
ii  libxen-4.14.1.3-7
ii  libxenstore3.04.1.3-7
ii  python2.7.3~rc2-1
ii  python2.7 2.7.3~rc2-2.1
ii  xen-utils-common  4.1.3-7
ii  zlib1g1:1.2.7.dfsg-13

Versions of packages xen-utils-4.1 recommends:
ii  bridge-utils   1.5-6
ii  qemu-keymaps   1.1.2+dfsg-3
ii  qemu-utils 1.1.2+dfsg-3
ii  xen-hypervisor-4.1-amd64 [xen-hypervisor-4.1]  4.1.3-7

Versions of packages xen-utils-4.1 suggests:
ii  xen-docs-4.1  4.1.3-7

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#403777: icedove: Trust junk mail headers set by: SpamAssassin gives wrong results

[Marvin Renich]

* Carsten Schoenert c.schoen...@t-online.de [12 04:07]:
 Hello Marvin,
 
 some years ago you opend this bug and the bug ist still active.
 Is this behavior allready vissible on current versions of icedove?
 
 Regards
 Carsten

I will try to check some time this week.

...Marvin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#668870: RFH: golang

[Marvin Renich]

* Ondřej Surý ond...@debian.org [120415 04:34]:
 Package: wnpp
 Severity: normal
 
 Hi,
 
 I am looking for co-maintainers (DMs are welcome).  I don't use Go
 myself, so the prospective co-maintaner should be a person who is
 involved in Go more than I am.
 
 Ondrej

I am willing to help.  I am currently only playing with go, but it is an
interesting language, and I believe I will keep using it at some level
for quite a while.  I am neither DM nor DD though.

...Marvin




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#658421: golang-weekly: go build and go install fail

[Marvin Renich]

* Justus Winter 4win...@informatik.uni-hamburg.de [120311 14:19]:
 Hm, the issue is back:
 
 % make
 go install vgo/logic
 open /usr/lib/go/pkg/linux_amd64/runtime.a: permission denied
 make: *** [vgo] Error 1
 % find /usr/lib/go/src/pkg/runtime -newer 
 /usr/lib/go/pkg/linux_amd64/runtime.a
 /usr/lib/go/src/pkg/runtime
 /usr/lib/go/src/pkg/runtime/pprof
 /usr/lib/go/src/pkg/runtime/cgo
 /usr/lib/go/src/pkg/runtime/debug
 
 But this time my workaround isn't working anymore, don't know what
 triggers the rebuild this time...

Sorry it took so long to get back to you.  I didn't have a chance to try
2012.02.22, but I'm still having problems with 2012.03.04.  I get:

$ go install ./
load cmd/cgo: package cmd/cgo: no Go source files in /usr/lib/go/src/cmd/cgo

And indeed, the only source for anything under .../src/cmd/ is the
doc.go file for each command.  The source for .../src/pkg/ seems to be
intact.

...Marvin




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#660899: freerdp-x11: CPU usage goes to 165% (dual core), no window is displayed

[Marvin Renich]

Package: freerdp-x11
Version: 1.0.1-1
Severity: important

When starting freerdp-x11, its CPU usage goes to 75% and gdm's usage
goes to 90% on a dual-core system, and they remain there until freerdp
is killed.  gdm's usage returns to 0 after killing freerdp.  The window
for the remote desktop never appears.

Downgrading to freerdp-x11 0.8.2-2+b1 resolves the problem.

...Marvin


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), 
(500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.1.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages freerdp-x11 depends on:
ii  libc6 2.13-26
ii  libfreerdp1   1.0.1-1
ii  libssl1.0.0   1.0.0g-1
ii  libx11-6  2:1.4.4-4
ii  libxcursor1   1:1.1.12-1
ii  libxext6  2:1.3.0-3
ii  libxinerama1  2:1.1.1-3
ii  libxkbfile1   1:1.0.7-1
ii  libxv12:1.0.6-2
ii  zlib1g1:1.2.6.dfsg-1

Versions of packages freerdp-x11 recommends:
ii  libfreerdp-plugins-standard  1.0.1-1

freerdp-x11 suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#658421: golang-weekly: go build and go install fail

[Marvin Renich]

Package: golang-weekly
Version: 2012.01.27-2
Severity: important

$ echo $GOPATH
/home/mrvn/golang
$ cd $GOPATH
$ go build tempus
# tempus
morestack trampoline not defined - runtime.morestack00
morestack trampoline not defined - runtime.morestack10
morestack trampoline not defined - runtime.morestack01
morestack trampoline not defined - runtime.morestack11
morestack trampoline not defined - runtime.morestack8
morestack trampoline not defined - runtime.morestack16
morestack trampoline not defined - runtime.morestack24
morestack trampoline not defined - runtime.morestack32
morestack trampoline not defined - runtime.morestack40
morestack trampoline not defined - runtime.morestack48
$ go install tempus
open /usr/lib/go/pkg/linux_amd64/runtime.a: permission denied

It appears that the go std libraries are not completely built.  If I
download and build go from upstream, and set GOROOT and GOPATH
appropriately, I do not have these problems.

I also wanted to thank you for packaging both golang and golang-weekly.
I appreciate being able to install, upgrade, and remove them as Debian
packages and having them follow the Debian directory structure.

...Marvin


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), 
(500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.39-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages golang-weekly depends on:
ii  golang-weekly-doc2012.01.27-2
ii  golang-weekly-go 2012.01.27-2
ii  golang-weekly-src2012.01.27-2
ii  golang-weekly-tools  2012.01.27-2

golang-weekly recommends no packages.

golang-weekly suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#656412: golang-weekly: please package the most recent weekly

[Marvin Renich]

Package: golang-weekly
Version: 2011.09.21-1
Severity: wishlist

Please package the most recent weekly build, weekly.2012.01.15;
significant changes have been made since 2011.09.21.  I tried to create
a package for the weekly.2011.12.22.  The package seems to build, but
after installing and trying to use go build or go install, I get errors
like open /usr/lib/go/pkg/linux_amd64/runtime.a: permission denied and
morestack trampoline not defined - runtime.morestack00.  I've
obviously not made all the necessary changes to the packaging.
Installing go locally and setting GOPATH to the local version works
fine.

Thanks...Marvin


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), 
(500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.39-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages golang-weekly depends on:
ii  golang-weekly-doc2011.12.22~mrvn-2
ii  golang-weekly-go 2011.12.22~mrvn-2
ii  golang-weekly-src2011.12.22~mrvn-2
ii  golang-weekly-tools  2011.12.22~mrvn-2

golang-weekly recommends no packages.

golang-weekly suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#655117: golang-weekly-tools: debconf question refers to popularity-contest rather than golang-weekly-tools

[Marvin Renich]

Package: golang-weekly-tools
Version: 2011.09.21-1
Severity: normal

The debconf question about reporting installation of public packages to
Go dashboard says the choice can be modified later by running
dpkg-reconfigure popularity-contest, but it should be
golang-weekly-tools.

...Marvin


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), 
(500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.39-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages golang-weekly-tools depends on:
ii  debconf [debconf-2.0]  1.5.41
ii  golang-weekly-go   2011.09.21-1
ii  libc6  2.13-24

Versions of packages golang-weekly-tools recommends:
ii  golang-weekly-doc  2011.09.21-1
ii  golang-weekly-src  2011.09.21-1

golang-weekly-tools suggests no packages.

-- debconf information:
* golang-weekly-tools/dashboard: true



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#612918: Writing to /etc/ from a privileged UI

[Marvin Renich]

* David Paleino da...@debian.org [110509 04:19]:
 On Mon, 9 May 2011 11:12:53 +0200, Adam Borowski wrote:
 
  /etc may include only _static_ configuration.  What you have is variable
  state which belongs in /var.  It's no different from a database, or dpkg's
  status data.
 
 Static IPs, DNS servers and WEP/WPA keys for a given wireless network are
 variable state? Sorry, I disagree.
 
 I already said that I have a patch not to save networks for which no
 configuration is made -- which is the variable state thing at the moment. 
 The
 question was different :)

This isn't about whether the data saved in the config file is variable,
it is about whether the config file is variable.  Files in /etc should
only be modified when the sysadmin is doing what (s)he considers to be
configuration, not when a user is running a program.

The specific data shown in the bug report is clearly variable state
information and not static configuration info, but even adding and
removing more permanent wireless access point info should not be done in
/etc during the normal, continuous operation of a daemon.

If I were designing the config structure, since each AP is a distinct
entity that doesn't depend on any other AP (maybe that should be essid,
not AP), I would have a .d directory where each essid had its own config
file.  There could be corresponding /etc/wicd/something.d and
/var/lib/wicd/something.d directories.  The admin could place files in
/etc that he didn't want users messing with.  Non-conflicting files in
/etc, /var/lib, and ~user/.wicd (or better, ~user/.config/wicd), would
be treated equally by wicd, with preference to ~user/.config/wicd then
/var/lib/wicd, then /etc/wicd for any conflicting entries.

Actually, one normal user should not be able to override the admin
defaults for another user, so if there is already an entry in /etc, wicd
should place any user change to that entry in ~user, but new,
non-conflicting entries should go in /var/lib.  Then, the order of
preference should be ~user, /etc, /var/lib.

Transient state information, like signal strength and quality should
_not_ go in these files, but rather in /var/run/wicd/ (soon to be
/run/wicd/).

...Marvin




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#616462: debian-policy: clarify wording of parenthetical in section 2.2.1

[Marvin Renich]

Package: debian-policy
Version: 3.9.1.0
Severity: wishlist

As suggested in thread on debian-devel (starting at
http://lists.debian.org/debian-devel/2011/03/msg00202.html), change the
wording of the parenthetical in the first bullet of section 2.2.1 from

...the packages in main

   • must not require a package outside of main for compilation or
 execution (thus, the package must not declare a Depends,
 Recommends, or Build-Depends relationship on a non-main
 package)

to

...the packages in main

   • must not require a package outside of main for compilation or
 execution (thus, all declared Depends, Recommends, and
 Build-Depends relationships must be satisfiable with only
 packages in main)

...Marvin

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'squeeze-updates'), (500, 'unstable'), 
(500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.37-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

debian-policy depends on no packages.

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
ii  doc-base  0.9.5  utilities to manage online documen

-- no debconf information



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#616462: debian-policy: clarify wording of parenthetical in section 2.2.1

[Marvin Renich]

* Steve Langasek vor...@debian.org [110304 11:36]:
 Although I agree with you that this parenthetical has been mistaken for
 normative language and it should be clarified with regards to intent, the
 clarification you've suggested is OTOH weaker than what I understand the
 common rule to be.  If the goal is to make sure installing a package in main
 doesn't automatically pull in a package from non-free, then the main
 alternative must be listed first.
 
 Maybe must be satisfied by default with only packages in main expresses
 this?
 
 Or maybe this is splitting hairs and I shouldn't worry too much about a
 non-normative parenthetical :)

Not being a DD, much less a policy maintainer, I didn't want to overstep
my bounds.  :-)  There was at least one person in that thread who
thought non-main dependencies could be listed first.  However, I agree
with you, and would prefer to mandate that the first alternative
explicitly be the default and that this be required to be in main.

...Marvin




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#616471: www.debian.org: Merge /intro/ and /intro/about pages

[Marvin Renich]

Package: www.debian.org
Severity: wishlist

The new web site is terrific!  However, I was looking for the
organization chart and had to resort to Google to find it.  After that,
I found the /intro/ page (from which the organization chart is an
obvious link) and was going to suggest adding a link to the intro page
on the common footer.  But, thinking about it more, and looking at the
content of the intro and about pages, I decided it would be easy and
make more sense to simply incorporate the contents of the intro page
into to about page, and perhaps make /intro/index.html and intro/about
synonyms.

...Marvin



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#616472: www.debian.org: the Report it! button doesn't give an opportunity to describe the problem

[Marvin Renich]

Package: www.debian.org
Severity: wishlist

When you click on the Report it! button in the common footer, there is
no opportunity for the user to give any description of the problem.

...Marvin



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org