Bug#907672: Rebasing cloud-init to the latest one

[Thomas Goirand]

On 09/07/2018 08:34 AM, Yanhui He wrote:
> Hi Thomas,
> 
> Thanks for your reply!
> 
> On Tue, 4 Sep 2018 09:28:55 +0200 Thomas Goirand  > wrote:
>> On 09/04/2018 05:29 AM, Yanhui He wrote:
>> > If you have any concern for v18.3 stability we could do some regression
>> > test together if needed.
>>
>> Not only us, but also the release team. If we sufficiently show it has
>> been tested, it may help.
>>
>> Cheers,
>>
>> Thomas Goirand (zigo)
>>
>> P.S: Is it really necessary to have 15 people CC-ed on each message?
>>
>>
> Based on Debian9.5.0-64 and cloud-init 18.3-35,  the following can be
> customized successfully.
> * static/DHCP IP address, Gateway, Netmask
> *  Hostname
> * Timezone
>  
> The following is not customized successfully, but most are known
> issue/limit for cloud-init
> * DNS. It was set in 50-cloud-init.cfg but not updated to resolv.conf
> file (Known cloud-init issue)
> * Domain name was not updated to /etc/hosts  (Known cloud-init issue)

While these may be cloud-init problems in Stretch, it's kind of easy to
do this in a user metadata script.

> * Hardware clock setting is not supported by cloud-init, default is UTC(
> Known cloud-init issue and it is not suggested to set hardware clock to
> local time on *NIX system)

Here, I don't see any issue at all. You'll get hardware clock as UTC,
and configure your VM with local timezone if you like. That's the normal
behavior, and I don't see any reason why you would like a different setup.

> From the results above, the 18.3 version of cloud-init can achieve most
> our customization goals, but with the version 0.7.9,  our customization
> can not work at all.

Why don't you do all of this in a user-data script?

Note that all of what I'm telling/asking here is probably what the
release team will ask if we request for a new version to get into
Stretch. If we don't have the answers, then probably we shouldn't even
attempt to ask the release team.

Cheers,

Thomas Goirand (zigo)

Bug#908183: mime-support: There are 2 entries for sh extension

[ArvoX]

Package: mime-support
Version: 3.60
Severity: normal

Dear Maintainer,

The sh extension has 2 entries:
application/x-shsh
text/x-sh   sh

I am not sure which one is the right one.


-- System Information:
Debian Release: 9.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

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

mime-support depends on no packages.

Versions of packages mime-support recommends:
ii  bzip2 1.0.6-8.1
ii  file  1:5.30-1+deb9u2
ii  xz-utils  5.2.2-1.2+b1

mime-support suggests no packages.

-- no debconf information

Bug#908184: RFS: gnome-pie/0.7.1-2 RC

[Jörg Frings-Fürst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: sponsorship-requests
Severity: important


Dear mentors,

  I am looking for a sponsor for my package "gnome-pie"

   Package name: gnome-pie
   Version : 0.7.1-2
   Upstream Author : Simon Schneegans 
   URL : https://github.com/Simmesimme/Gnome-Pie
   License : BSD-2-Clause
   Section : gnome

  It builds those binary packages:

gnome-pie  - visual application launcher for GNOME

  To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/gnome-pie


  Alternatively, one can download the package with dget using this
command:

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gnome-pie/gnome-pie_0.7.1-2.dsc

or

  git: https://jff.email/cgit/gnome-pie.git/?h=release%2Fdebian%2F0.7.1-2


  Changes since the last upload:

  * New debian/patches/0100-fix-ftbfs_vala_0_42.patch to fix FTBFS
with vala 0.42 (Closes: #907943).
  * Switch to Ayatana AppIndicator (Closes: #907551):
- New debian/patches/0700-ayatana-appindicator.patch.
- debian/control:
  + Switch build depends from libappindicator3-dev to 
libayatana-appindicator3-dev.
Thanks to Mike Gabriel .
  * Change to my new email address.
  * Migrate to debhelper 11:
- Change debian/compat to 11.
- debian/control:
  + Bump minimum debhelper version to >= 11.
  * Declare compliance with Debian Policy 4.2.1 (No changes needed).
  * New debian/patches/0105-spelling_errors.patch to fix spelling errors.
  * debian/control:
- Change Vcs-* to point to the new repository.
- Remove trailing whitespace.
  * debian/copyright:
- Use secure URI for copyright format.
- Refresh years for debian/*.


  Regards,
   Jörg Frings-Fürst

- -- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAluSJZEACgkQCfifPIyh
0l19oQ/9F1atkryA6TWEoGkupfcEApDHesUJI/byIyT+wfE3l65zEhDqX2lhdQfF
ArLHGrSevSkSDFICrKJg6lZdC8q7Twd619dB/Y6D5wIui5/BmBcgETnej+MLnBu5
59gphO4MO3yg3Wocq6V0dRGA/2uRvOCW7fbTlacqpfHh7S3KE79wqXQ3x9CaeUMC
u9hROXwA9C6yn4/j6vaLlATQD3WxsiSU7a7Y6u6dfBL6uTsq1DRfrJfSRwzneIrN
GMQGHnrWfeEu+LVpXgbIjWBNT3XaNe11cCicEb23+47YX/O1yrFJTOIrz3msoLNY
U7OFHVYfZGLjpQE7tahQU34sc2QG13qia3B4YecA9L+c0bT3FDNKdaYcSEx9betO
p8BLCm4G9GXN8X0TmX2e/DvtcA9ax8KCOZsgMXcwFj8wlTzxuZnBBgJFzrdlCno6
o1PuMMmM2JeA5ZYprQ6Y4ZEqIA4cyvlce94L76YxMFgEtN83Znj5B4q1QsLb7Nwb
1b7BI+eL6Uht0o4nT2+1J+EUZZTbep9DVHu4cQ6jiUu4PScBo/7Acmke1NzIyVRy
MwpVAdms+CL+8P/QTf/a/X8REkxC72L4SCR3uRCC+sFJkRVv6KuAaoZ/k3K0Zhfs
N08v/Df8kVDosVJ5iCwssjuHiLaVU6oe25ddkPyTBQcRUxetX1U=
=YuKd
-END PGP SIGNATURE-

Bug#888423: Are you getting the segfault on the new release as well i.e. 62.0-1

[shirish शिरीष]

Dear Dmitry E. Oboukhov,

Are you still getting crashes with the new release as well ?

$ apt-cache policy firefox
firefox:
  Installed: (none)
  Candidate: 62.0-1
  Version table:
 62.0-1 100
100 http://deb.debian.org/debian unstable/main amd64 Packages

$ apt-cache policy firefox-dbgsym
firefox-dbgsym:
  Installed: (none)
  Candidate: 62.0-1
  Version table:
 62.0-1 100
100 http://debug.mirrors.debian.org/debian-debug
unstable-debug/main amd64 Packages


If possible please install the new version, use firefox
--ProfileManager , make a new profile, make sure that no addons are
installed and see if you still are having the same issues.

Looking forward to see if you are having the same issue and getting
the same traceback (or not). If it's still an issue then you could CC
Mike Hommey  so maybe it could be reported
upstream if it's an upstream issue.

Looking forward to see this resolved.

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#908177: evince: Rename of desktop file from evince.desktop to org.gnome.Evince.desktop breaks MIME/mailcap ordering (PDFs open with gimp)

[Josh Triplett]

On Fri, Sep 07, 2018 at 06:22:06AM +0200, Michael Biebl wrote:
> Am 07.09.18 um 05:49 schrieb Josh Triplett:
> > Package: evince
> > Version: 3.30.0-1
> > Severity: important
> > 
> > evince 3.30 renamed the desktop file from evince.desktop to
> > org.gnome.Evince.desktop. update-mime, the tool to generate
> > /etc/mailcap, processes desktop files in order by name. Because of this
> > rename, GIMP now has a higher priority for PDF and PostScript files than
> > Evince does, causing mutt and similar to open PDF and PostScript files
> > with GIMP by default.
> 
> What would you suggest should be done about this?
> Renaming the desktop file back to evince.desktop is not really an option.

I'm not proposing that (though I'm curious what makes that particularly
painful). We need *some* solution though. That this happened to work
out of the box before was effectively a coincidence based on "evince"
sorting before "gimp".

I don't know what the *ideal* solution looks like.

One short-term approach would be to introduce some kind of simplistic priority
scheme in desktop files via an X- header that update-mime reads, and
have evince and/or GIMP use that (and perhaps declare a Breaks for older
mime-support).  Effectively, this would introduce a concept of "this
application supports this MIME type but should never end up as the
primary tool a user wants to use to open it", versus "it's plausible
that this could be the primary tool a user uses to open this MIME type".
That would solve the problem of ending up with something like GIMP as
the primary PDF opener, though it doesn't solve the long-term issue of
ending up with the wrong tool for your preferred environment (e.g.
evince vs okular).

Bug#906504: pulseaudio: FTBFS in buster/sid (failing tests) => patch available

[Sven Joachim]

Control: found -1 12.2-1

On 2018-09-05 21:20 -0700, Joseph Herlant wrote:

> Control: forwarded -1
> https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/4
> Control: tags -1 + patch
> Control: tags -1 + upstream
>
> Hi,
>
> The issue is due to a optiomizations impacting precision with GCC8.
> There is an existing bug report on this issue upstream:
> https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/559
> and an existing merge request there too:
> https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/4
>
> I've created the MR on salsa to add the upstream patch with quilt in
> the current version:
> https://salsa.debian.org/pulseaudio-team/pulseaudio/merge_requests/1

Unfortunately pulseaudio 12.2-1 did still FTBFS on various
architectures, e.g. on arm64[1]:

,
| max deviation: 1 n=307
| 0%: Checks: 1, Failures: 1, Errors: 0
| tests/volume-test.c:148:F:volume:volume_test:0: Assertion 'mdn <= 300' failed
`

Similar on armhf, i386, s390x and sparc64.

Cheers,
   Sven

1. 
https://buildd.debian.org/status/fetch.php?pkg=pulseaudio&arch=arm64&ver=12.2-1&stamp=1536269336&raw=0

Bug#906189: linux-image-4.17.0-1-amd64: Laptop does not suspend in 4.17 - worked up to 4.16

[Christoph Haas]

Does it suffice to know that the problem does not occur any more with
kernel 4.19.0-rc2+?

I could continue with the "git bisect" but it would take days. :(




signature.asc
Description: OpenPGP digital signature

Bug#908185: False positive init.d-script-possible-missing-stop for rcS init scripts

[Michael Biebl]

Package: lintian
Version: 2.5.100
Severity: normal

I just updated the udev init script (which starts in runlevel S) to be
stopped on shutdown and reboot. Now I get this lintian warning:

W: udev: init.d-script-possible-missing-stop etc/init.d/udev 1
N:
N:The given /etc/init.d script indicates it should be stopped at one of
N:the runlevels 0, 1, or 6 but not at all of them. This is usually a
N:mistake. Normally, facilities that need to be stopped at any of those
N:runlevels need to be stopped at all of them.

I think this information is incorrect for services which start during
early boot, i.e. have Default-Start: S. I'd argue it makes no sense to
stop them in single user mode.

What I currently have is

# Default-Start: S
# Default-Stop:  0 6

which looks correct to me.


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

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

Versions of packages lintian depends on:
ii  binutils   2.31.1-5
ii  bzip2  1.0.6-9
ii  diffstat   1.61-1+b1
ii  dpkg   1.19.0.5+b1
ii  file   1:5.34-2
ii  gettext0.19.8.1-7
ii  intltool-debian0.35.0+20060710.4
ii  libapt-pkg-perl0.1.34
ii  libarchive-zip-perl1.63-1
ii  libcgi-pm-perl 4.40-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.39-1
ii  libdigest-sha-perl 6.02-1
ii  libdpkg-perl   1.19.0.5
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libipc-run-perl20180523.0-1
ii  liblist-moreutils-perl 0.416-1+b3
ii  libparse-debianchangelog-perl  1.2.0-12
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.74-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.72+repack-1
ii  man-db 2.8.4-2
ii  patchutils 0.3.4-2
ii  perl [libdigest-sha-perl]  5.26.2-7
ii  t1utils1.41-2
ii  xz-utils   5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b4

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.19.0.5
ii  libhtml-parser-perl3.72-3+b2
ii  libtext-template-perl  1.53-1

-- no debconf information

Bug#908186: libvirt-clients: UNable to limit swap by editing guest xml configuration, but virsh memtune swap_hard_limit works

[reusser]

Package: libvirt-clients
Version: 3.0.0-4+deb9u3
Severity: normal

Dear Maintainer,

I'm trying to limit swap usage of guest systems. Libvirt offers the
memory tuning option 'swap_hard_limit' [1]. To enable setting of the swap
hard limit, we need to enable swap control in the kernel by adding
swapaccounting to the grub commandline [2]. 

Now, I'm able to set a swap limit with virsh memtune:

> virsh --connect qemu:///system memtune demo --hard-limit 614400 
> virsh --connect qemu:///system memtune demo --swap-hard-limit 714400 

However, if I edit the guest xml configuration by adding

  
  614402
  

The guest does not start. Instead, I get an error:
virsh --connect qemu:///system start demo
error: Failed to start domain demo error: Invalid value '629146624' for 
'memory.memsw.limit_in_bytes': Das Argument ist ungültig 

I expect the guest to start with a limitation on swap usage.

[1] https://libvirt.org/formatdomain.html#elementsMemoryTuning
[2] https://askubuntu.com/questions/417215/how-does-kernel-support-swap-limit


-- System Information:
Debian Release: 9.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages libvirt-clients depends on:
ii  libapparmor12.11.0-3+deb9u2
ii  libaudit1   1:2.6.7-2
ii  libavahi-client30.6.32-2
ii  libavahi-common30.6.32-2
ii  libc6   2.24-11+deb9u3
ii  libcap-ng0  0.7.7-3+b1
ii  libdbus-1-3 1.10.26-0+deb9u1
ii  libdevmapper1.02.1  2:1.02.137-2
ii  libgnutls30 3.5.8-5+deb9u3
ii  libnl-3-200 3.2.27-2
ii  libnl-route-3-200   3.2.27-2
ii  libnuma12.0.11-2.1
ii  libreadline77.0-3
ii  libsasl2-2  2.1.27~101-g0780600+dfsg-3
ii  libselinux1 2.6-3+b3
ii  libssh2-1   1.7.0-1
ii  libvirt03.0.0-4+deb9u3
ii  libxen-4.8  4.8.4+xsa273+shim4.10.1+xsa273-1+deb9u10
ii  libxml2 2.9.4+dfsg1-2.2+deb9u2
ii  libyajl22.1.0-2+b3

libvirt-clients recommends no packages.

Versions of packages libvirt-clients suggests:
ii  libvirt-daemon  3.0.0-4+deb9u3

-- no debconf information

Bug#823755: pinpoint segfault with gdb details

[Andrew Donnellan]

Hi there,

I'm also seeing this segfault.

The following gdb output is with pinpoint 1:0.1.8-2+b1 on Debian stretch 
- it doesn't look overly helpful, so let me know if there's anything 
more I can provide.



ajd@intelligence:~/tmp/banana$ gdb pinpoint
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from pinpoint...Reading symbols from 
/usr/lib/debug/.build-id/cd/942bd29ed800140f945368f652f03bf623f4af.debug...done.

done.
(gdb) run /usr/share/doc/pinpoint/examples/introduction.pin
Starting program: /usr/bin/pinpoint 
/usr/share/doc/pinpoint/examples/introduction.pin

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe77d7700 (LWP 19024)]
[New Thread 0x7fffe6fd6700 (LWP 19025)]

Thread 1 "pinpoint" received signal SIGSEGV, Segmentation fault.
__GI___pthread_mutex_lock (mutex=0x0) at ../nptl/pthread_mutex_lock.c:67
67  ../nptl/pthread_mutex_lock.c: No such file or directory.
(gdb)

--
Andrew Donnellan  OzLabs, ADL Canberra
andrew.donnel...@au1.ibm.com  IBM Australia Limited

Bug#907829: p4est: FTBFS on single CPU machines (?)

[Adrian Bunk]

On Thu, Sep 06, 2018 at 10:46:07PM +0200, Santiago Vila wrote:
> On Thu, Sep 06, 2018 at 09:01:02PM +0300, Adrian Bunk wrote:
>...
> Ok, I started saying "FTBFS = serious" but the above does not really
> count as a counter-example. We agree that a FTBFS bug in an unreleased
> arch is not RC, that's completely out of the discussion.
>...
> You will have noticed that we usually report FTBFS bugs when a package
> fails to build in any "correctly" configured autobuilder, we don't wait
> for the build failure to happen on buildd.debian.org.
>...

No release architectures has a single-core autobuilder at buildd.debian.org.

And it is completely out of the discussion that any would in the future.

> That's simply not true. Here is the math:
> 
> In the best case scenario, a machine with 2 CPU will usually cost
> double than a single-CPU. It will build the package in half of the
> time, but since it cost double per minute, the total cost is
> approximately the same, not cheaper at all.
> 
> But that's only the best case scenario. The worst case scenario is
> that you build all packages using 2 CPU but only a proportion of them
> support (and benefit from) parallel build. For those who don't we are
> wasting completely the extra CPU.
> 
> So no, it's not cheaper in general, and it may be even more expensive.

Which cloud provider are you using?

Your math assumes that expensive resources like RAM or storage would be 
free, and not cost you more when you have to provision them longer due 
to the longer build time.

If you want to do do the math properly, you have to take into account
that faster build times mean fewer seconds you also have to pay for 
everything else.

> > Debian packages should build on single-core machines and it is a bug 
> > when they don't, but it is mostly irrelevant in practice.
> 
> Hmm, "mostly irrelevant" and "in practice".
> 
> The problem with that is that it's highly subjective. We don't
> "optimize for Internet Explorer". We follow standards, and being
> multi-core is not an intrinsic property of the amd64 architeture.
> 
> You seem to think that because desktop computers are almost always
> multi-core these days,

"these days" was 10 years ago.

Today even cheap embedded devices like a Raspberry Pi are quadcore.

>...
> In practice, there is only a *handful* of packages that do not build
> on single-core. The actual figure is closer to 5 than 10, 20 or
> whatever is the number that you might be guessing.
> 
> Would it be the same for you if this number was 5 than if it was 200
> or 300? (BTW: What was the approximate number you had in mind?)

Yes.

These are bugs, but in reality "FTBFS on hppa" is the most relevant
consequence.

>...
> You keep talking about "not RC" for "practical" reasons, but for me it
> is *really* practical that I can build 99.98% of all Debian packages
> on single-cpu machines. It is not also a practical thing for Debian
> that people can make QA in a cheap way, without wasting CPUs?
>...

When you buy hardware today you usually get more cores than you can 
use, but RAM costs a fortune.

Like it is a real problem that plenty complete ARM quadcore systems
like the Raspberry Pi are available in the $30-40 range, but anything
with >= 8 GB RAM is ridiculously expensive.

This is the core reason why you are facing so much resistance when you 
are trying to use release critical bugs to force people to spend their
spare time on something that has no actual practical relevance.

It also obscures the many useful bug reports you submit when you are
insisting that whatever fails to build in your weird setup should be
considered release critical.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#908065: BTS seems to send bugs to old maintainer of a package but displays new one correctly (Was: Bug#908065: r-cran-adegraphics: autopkgtest regression: dependency versions not properly specifie

[Andreas Tille]

Hi,

On Thu, Sep 06, 2018 at 10:31:34PM +0200, Paul Gevers wrote:
> 
> > BTW, do you have any idea why that bug is filed against Debian Med
> > packaging list[1] while the maintainer of the package is
> > r-pkg-t...@alioth-lists.debian.net?
> 
> tracker.d.o?

Hmmm, why should tracker.d.o keep a record where a package was
maintained *before* instead of just taking the Maintainer field of the
current package?  At least the *rendered* information of tracker.d.o[1]
mentions Debian R Packages Maintainers.

The result of this wrong choice of team somehow hides the todo item for
dh-r from the people who should care (I'll forward a summary, but would
like to understand this issue first).  The BTS says on the bug page:

   Maintainer for src:r-cran-adegraphics is Debian R Packages Maintainers 


but it sends the e-mail in contrast to this to debian-med-packaging[3].

Any idea why BTS sends the e-mail to the maintainer that is mentioned
for instance in the package in stable rather than the one in unstable
(which is correctly parsed obviously)?

Kind regards

   Andreas.

[1] https://tracker.debian.org/pkg/r-cran-adegraphics
[2] https://bugs.debian.org/908065
[3] 
https://alioth-lists.debian.net/pipermail/debian-med-packaging/2018-September/065335.html

-- 
http://fam-tille.de

Bug#908186: Acknowledgement (libvirt-clients: UNable to limit swap by editing guest xml configuration, but virsh memtune swap_hard_limit works)

[Dominik Reusser]

The problem can be solved by setting the hard_limit in the guest xml
file as well.

Ideally, the hard_limit would be set automatically and a warning about
the missing entry in the configuration generated.

At least the error message should be more specific.

Bug#907997: emacs-lucid: trying to overwrite '/usr/share/emacs/25.2/etc/DOC', which is also in package emacs25 25.2+1-6+b2

[Sven Joachim]

Control: tags -1 + patch

On 2018-09-05 01:18 +0200, Axel Beckert wrote:

> Hi again,
>
> Axel Beckert wrote:
>> I'm sorry, but the Breaks/Replaces headers still seem incomplete. I just
>> experienced the following upgrade failure when I wanted to switch from
>> emacs25 to emacs-lucid on a Raspberry Pi running Buster/Testing arm64:
> […]
>> dpkg: error processing archive 
>> /var/cache/apt/archives/emacs-lucid_1%3a25.2+1-11_arm64.deb (--unpack):
>>  trying to overwrite '/usr/share/emacs/25.2/etc/DOC', which is also in 
>> package emacs25 25.2+1-6+b2
>
> This is more or less the same issue as https://bugs.debian.org/904957
> which either hasn't been fixed correctly or the fix has been removed
> already again.

The former.  The attached patch should fix that, but I have not tested
it at all.

Cheers,
   Sven

>From c17bb8a334d3fded3f9e88fa37ada55f9cb80efb Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Fri, 7 Sep 2018 09:52:49 +0200
Subject: [PATCH] Correct the Replaces in emacs-{gtk,lucid,nox}

The predecessors of emacs-gtk, emacs-lucid and emacs-nox in
src:emacs25 were called emacs25, emacs25-lucid and emacs25-nox
respectively, so replace those rather than the new variants.

Closes: 907997
---
 debian/control | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index 6d4a533ea20..1dcd6a2a00a 100644
--- a/debian/control
+++ b/debian/control
@@ -42,7 +42,7 @@ Provides: emacs, emacsen, editor, info-browser, mail-reader, news-reader
 Suggests: emacs-common-non-dfsg
 Conflicts: emacs-gtk, emacs-nox
 Replaces: emacs-gtk, emacs-nox,
-  emacs-gtk (<< 1:25), emacs-lucid (<< 1:25), emacs-nox (<< 1:25)
+  emacs25 (<< 1:25), emacs25-lucid (<< 1:25), emacs25-nox (<< 1:25)
 Description: GNU Emacs editor (with Lucid GUI support)
  GNU Emacs is the extensible self-documenting text editor.  This
  package contains a version of Emacs with support for a graphical user
@@ -74,7 +74,7 @@ Provides: emacs, emacsen, editor, info-browser, mail-reader, news-reader
 Suggests: emacs-common-non-dfsg
 Conflicts: emacs-gtk, emacs-lucid
 Replaces: emacs-gtk, emacs-lucid,
-  emacs-gtk (<< 1:25), emacs-lucid (<< 1:25), emacs-nox (<< 1:25)
+  emacs25 (<< 1:25), emacs25-lucid (<< 1:25), emacs25-nox (<< 1:25)
 Description: GNU Emacs editor (without GUI support)
  GNU Emacs is the extensible self-documenting text editor.  This
  package contains a version of Emacs compiled without support for X,
@@ -100,7 +100,7 @@ Provides: emacs, emacsen, editor, info-browser, mail-reader, news-reader
 Suggests: emacs-common-non-dfsg
 Conflicts: emacs-lucid, emacs-nox
 Replaces: emacs-lucid, emacs-nox,
-  emacs-gtk (<< 1:25), emacs-lucid (<< 1:25), emacs-nox (<< 1:25)
+  emacs25 (<< 1:25), emacs25-lucid (<< 1:25), emacs25-nox (<< 1:25)
 Description: GNU Emacs editor (with GTK+ GUI support)
  GNU Emacs is the extensible self-documenting text editor.  This
  package contains a version of Emacs with a graphical user interface
-- 
2.19.0.rc2

Bug#908191: bind9: db.root VS root.hints

[Alexandre Anriot]

Package: bind9
Version: 1:9.11.4+dfsg-4~bpo9+1
Severity: normal

Dear Maintainer,

The file `/etc/bind/db.root` appears to be present in the stretch package as
well as in the buster package. Though, it's not part of the stretch-backports
package.

I did modify the `named.conf.default-zones` file in order to use
`/usr/share/dns/root.hints` (provided by the `dns-root-data` package) but would
like to know if `db.root` will be kept or not in the buster package in order to
update external tools (i.e. a SaltStack formula) accordingly.

Thanks a lot.

Cheers,

-- System Information:
Debian Release: 9.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages bind9 depends on:
ii  adduser3.115
ii  bind9utils 1:9.11.4+dfsg-4~bpo9+1
ii  debconf [debconf-2.0]  1.5.61
ii  dns-root-data  2017072601~deb9u1
ii  init-system-helpers1.48
ii  libbind9-160   1:9.11.4+dfsg-4~bpo9+1
ii  libc6  2.24-11+deb9u3
ii  libcap21:2.25-1
ii  libcomerr2 1.43.4-2
ii  libdns1102 1:9.11.4+dfsg-4~bpo9+1
ii  libfstrm0  0.3.0-1
ii  libgeoip1  1.6.9-4
ii  libgssapi-krb5-2   1.15-1+deb9u1
ii  libisc169  1:9.11.4+dfsg-4~bpo9+1
ii  libisccc1601:9.11.4+dfsg-4~bpo9+1
ii  libisccfg160   1:9.11.4+dfsg-4~bpo9+1
ii  libjson-c3 0.12.1-1.1
ii  libk5crypto3   1.15-1+deb9u1
ii  libkrb5-3  1.15-1+deb9u1
ii  liblmdb0   0.9.18-5
ii  liblwres1601:9.11.4+dfsg-4~bpo9+1
ii  libprotobuf-c1 1.2.1-2
ii  libssl1.1  1.1.0f-3+deb9u2
ii  libxml22.9.4+dfsg1-2.2+deb9u2
ii  lsb-base   9.20161125
ii  net-tools  1.60+git20161116.90da8a0-1
ii  netbase5.4

bind9 recommends no packages.

Versions of packages bind9 suggests:
pn  bind9-doc   
ii  dnsutils1:9.10.3.dfsg.P4-12.3+deb9u4
pn  resolvconf  
ii  ufw 0.35-4

-- Configuration Files:
/etc/bind/named.conf changed [not included]
/etc/bind/named.conf.default-zones changed [not included]
/etc/bind/named.conf.local changed [not included]
/etc/bind/named.conf.options changed [not included]

-- debconf information excluded

Bug#907913: Message: 'geckodriver' executable needs to be in PATH

[Sascha Girrulat]

Package: python-selenium
Version: 3.8.0+dfsg1-3
Severity: normal
Justification: limited usage because of firefox dependency

Hi Mykola,

there is already a bug[1] for firefox. Geckodriver has to be shippet
with firefox not with python-selenium. Until that you have to use a
other one e.g. chromium-driver as described in
NEWS.debain/README.debian. Alternative yo have to install the
Geckodriver manually[2].

Regards
Sascha

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874207
[2]
https://askubuntu.com/questions/851401/where-to-find-geckodriver-needed-by-selenium-python-package


On 9/4/18 2:11 AM, Mykola Nikishov wrote:
> Package: python-selenium
> Version: 3.8.0+dfsg1-3
> Severity: grave
> Justification: renders package unusable
> 
> --8<---cut here---start->8---
> Traceback (most recent call last):
>   File "", line 70, in 
>   File "", line 57, in main
>   File 
> "/usr/lib/python2.7/dist-packages/selenium/webdriver/firefox/webdriver.py", 
> line 148, in __init__
> self.service.start()
>   File 
> "/usr/lib/python2.7/dist-packages/selenium/webdriver/common/service.py", line 
> 81, in start
> os.path.basename(self.path), self.start_error_message)
> selenium.common.exceptions.WebDriverException: Message: 'geckodriver' 
> executable needs to be in PATH. 
> --8<---cut here---end--->8---
> 
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers stable
>   APT policy: (900, 'stable'), (190, 'testing'), (180, 'unstable'), (170, 
> 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages python-selenium depends on:
> ii  python  2.7.13-2
> 
> Versions of packages python-selenium recommends:
> ii  phantomjs  2.1.1+dfsg-2
> 
> Versions of packages python-selenium suggests:
> ii  firefoxdriver  3.8.0-1
> 
> -- no debconf information
> 



signature.asc
Description: OpenPGP digital signature

Bug#908192: linux-image-4.18.0-1-amd64: After upgrade kernel to linux-image-4.18.0-1-amd64, LXC can not start

[John Wong]

Package: src:linux
Version: 4.18.6-1
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

As title, after upgrade to linux-image-4.18.0-1-amd64, lxc can not 
start,
If boot to old kernel (4.17-3..), lxc can start again.

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- Package-specific info:
** Version:
Linux version 4.18.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-29)) #1 SMP Debian 4.18.6-1 (2018-09-06)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.18.0-1-amd64 
root=UUID=5cb16262-d214-4feb-9369-81a291a2388b ro apparmor=1 security=apparmor 
quiet

** Not tainted

** Kernel log:

** Model information
[   50.617580] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   50.617598] lxcbr0: port 2(veth471YAX) entered blocking state
[   50.617599] lxcbr0: port 2(veth471YAX) entered forwarding state
[   50.633435] lxcbr0: port 2(veth471YAX) entered disabled state
[   50.633527] device veth471YAX left promiscuous mode
[   50.633528] lxcbr0: port 2(veth471YAX) entered disabled state
[  111.648345] lxcbr0: port 2(vethMT2FWQ) entered blocking state
[  111.648347] lxcbr0: port 2(vethMT2FWQ) entered disabled state
[  111.648372] device vethMT2FWQ entered promiscuous mode
[  111.651743] lxcbr0: port 2(vethMT2FWQ) entered disabled state
[  111.651866] device vethMT2FWQ left promiscuous mode
[  111.651867] lxcbr0: port 2(vethMT2FWQ) entered disabled state
[  221.679794] lxcbr0: port 2(vethYPTVY4) entered blocking state
[  221.679795] lxcbr0: port 2(vethYPTVY4) entered disabled state
[  221.679821] device vethYPTVY4 entered promiscuous mode
[  221.701044] eth0: renamed from vethHEA5JH
[  221.724082] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[  221.725177] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[  221.725196] lxcbr0: port 2(vethYPTVY4) entered blocking state
[  221.725197] lxcbr0: port 2(vethYPTVY4) entered forwarding state
[  221.740431] lxcbr0: port 2(vethYPTVY4) entered disabled state
[  221.740526] device vethYPTVY4 left promiscuous mode
[  221.740527] lxcbr0: port 2(vethYPTVY4) entered disabled state
[  229.743698] lxcbr0: port 2(vethG6VBDH) entered blocking state
[  229.743699] lxcbr0: port 2(vethG6VBDH) entered disabled state
[  229.743727] device vethG6VBDH entered promiscuous mode
[  229.769070] eth0: renamed from vethESL89I
[  229.791893] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[  229.792987] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[  229.793003] lxcbr0: port 2(vethG6VBDH) entered blocking state
[  229.793004] lxcbr0: port 2(vethG6VBDH) entered forwarding state
[  229.804473] lxcbr0: port 2(vethG6VBDH) entered disabled state
[  229.804572] device vethG6VBDH left promiscuous mode
[  229.804573] lxcbr0: port 2(vethG6VBDH) entered disabled state
[  252.543415] lxcbr0: port 2(vethQTK7VL) entered blocking state
[  252.543416] lxcbr0: port 2(vethQTK7VL) entered disabled state
[  252.543442] device vethQTK7VL entered promiscuous mode
[  252.573029] eth0: renamed from veth8J8RJX
[  252.587882] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[  252.589098] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[  252.589115] lxcbr0: port 2(vethQTK7VL) entered blocking state
[  252.589116] lxcbr0: port 2(vethQTK7VL) entered forwarding state
[  252.600700] lxcbr0: port 2(vethQTK7VL) entered disabled state
[  252.600801] device vethQTK7VL left promiscuous mode
[  252.600802] lxcbr0: port 2(vethQTK7VL) entered disabled state
[ 1270.152712] lxcbr0: port 2(veth83ORBG) entered blocking state
[ 1270.152713] lxcbr0: port 2(veth83ORBG) entered disabled state
[ 1270.152741] device veth83ORBG entered promiscuous mode
[ 1270.175792] eth0: renamed from vethXLKI4X
[ 1270.199037] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 1270.200115] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 1270.200133] lxcbr0: port 2(veth83ORBG) entered blocking state
[ 1270.200134] lxcbr0: port 2(veth83ORBG) entered forwarding state
[ 1270.215342] lxcbr0: port 2(veth83ORBG) entered disabled state
[ 1270.215431] device veth83ORBG left promiscuous mode
[ 1270.215432] lxcbr0: port 2(veth83ORBG) entered disabled state
[ 1281.911374] lxcbr0: port 2(vethWLL3H7) entered blocking state
[ 1281.911375] lxcbr0: port 2(vethWLL3H7) entered disabled state
[ 1281.911402] device vethWLL3H7 entered promiscuous mode
[ 1281.935451] eth0: renamed from vethDVX7T8
[ 1281.946282] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 1281.947522] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 1281.947540] lxcbr0: port 2(vethWLL3H7) entered blocking state
[ 1281.947541] lxcbr0: port 2(vethWLL3H7) entered forwarding state
[ 1281.968923] lxcbr0: port 2(vethWLL3H7) entered d

Bug#908177: evince: Rename of desktop file from evince.desktop to org.gnome.Evince.desktop breaks MIME/mailcap ordering (PDFs open with gimp)

[Michael Biebl]

Am 07.09.18 um 09:07 schrieb Josh Triplett:
> On Fri, Sep 07, 2018 at 06:22:06AM +0200, Michael Biebl wrote:
>> Am 07.09.18 um 05:49 schrieb Josh Triplett:
>>> Package: evince
>>> Version: 3.30.0-1
>>> Severity: important
>>>
>>> evince 3.30 renamed the desktop file from evince.desktop to
>>> org.gnome.Evince.desktop. update-mime, the tool to generate
>>> /etc/mailcap, processes desktop files in order by name. Because of this
>>> rename, GIMP now has a higher priority for PDF and PostScript files than
>>> Evince does, causing mutt and similar to open PDF and PostScript files
>>> with GIMP by default.
>>
>> What would you suggest should be done about this?
>> Renaming the desktop file back to evince.desktop is not really an option.
> 
> I'm not proposing that (though I'm curious what makes that particularly
> painful). We need *some* solution though. That this happened to work
> out of the box before was effectively a coincidence based on "evince"
> sorting before "gimp".
> 
> I don't know what the *ideal* solution looks like.
> 
> One short-term approach would be to introduce some kind of simplistic priority
> scheme in desktop files via an X- header that update-mime reads, and
> have evince and/or GIMP use that (and perhaps declare a Breaks for older
> mime-support).  Effectively, this would introduce a concept of "this
> application supports this MIME type but should never end up as the
> primary tool a user wants to use to open it", versus "it's plausible
> that this could be the primary tool a user uses to open this MIME type".
> That would solve the problem of ending up with something like GIMP as
> the primary PDF opener, though it doesn't solve the long-term issue of
> ending up with the wrong tool for your preferred environment (e.g.
> evince vs okular).

/etc/mailcap is very unflexible in that regard and I'm not sure it's
fixable.
Maybe a better solution would be if tools moved away from using
/etc/mailcap. Could mutt be taught to use xdg-open?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#908156: xpra cannot create directories in /run

[Dmitry Smirnov]

On Friday, 7 September 2018 5:07:22 AM AEST Alex wrote:
> xpra in debian buster does not work anymore. The error messages when
> trying to start it from another host with xpra start are:
> 
> $ xpra start ssh:remotehost:10 --encoding=vp9 --min-quality=50
> --start=konsole

Does it work with "--systemd-run=no"?

-- 
Regards,
 Dmitry Smirnov.

---

No person, no idea, and no religion deserves to be illegal to insult,
not even the Church of Emacs.
-- Richard Stallman


signature.asc
Description: This is a digitally signed message part.

Bug#908192: Acknowledgement (linux-image-4.18.0-1-amd64: After upgrade kernel to linux-image-4.18.0-1-amd64, LXC can not start)

[johnw]

Attached config and log file for lxc-start -n name -l debug


--
Key fingerprint: CDB3 6C62 254B C088 1E5D DD32 182C 97DB CF2C 80AC
lxc.start.auto = 1
lxc.start.delay = 0

# Distribution configuration
lxc.include = /usr/share/lxc/config/debian.common.conf
lxc.include = /usr/share/lxc/config/debian.userns.conf
lxc.arch = x86_64

# Container specific configuration
lxc.kmsg = 0
lxc.id_map = u 0 1210 65536
lxc.id_map = g 0 1210 65536
#lxc.cap.drop = sys_module mac_admin mac_override sys_time mknod net_raw 
sys_rawio sys_nice sys_pacct setfcap setpcap sys_ptrace syslog sys_resource 
sys_tty_config wake_alarm sys_admin
#lxc.aa_profile = lxc-container-default-local
#lxc.aa_allow_incomplete = 0
lxc.aa_profile = unconfined
lxc.rootfs = /var/lib/lxc/lxc121/rootfs
lxc.rootfs.backend = dir
lxc.utsname = lxc121

# Network configuration
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = lxcbr0
lxc.network.hwaddr = AA:BB:CC:DD:01:21
lxc.network.ipv4 = 192.168.168.121/32
lxc.network.ipv4.gateway = 192.168.168.1


# manual mount for drop sys_admin
lxc.mount.entry = tmpfs run tmpfs 
rw,nosuid,noexec,relatime,mode=0755,create=dir 0 0
lxc.mount.entry = tmpfs run/lock tmpfs 
rw,nosuid,nodev,noexec,relatime,mode=1777,size=5M,create=dir 0 0
lxc.mount.entry = tmpfs run/shm tmpfs 
rw,nosuid,nodev,noexec,relatime,mode=1777,create=dir 0 0

lxc.mount.entry = tmpfs root tmpfs nosuid,nodev,noatime,mode=0700,uid=0,gid=0 0 0
lxc.mount.entry = tmpfs home/lxc121 tmpfs 
nosuid,nodev,noatime,mode=0700,uid=1121,gid=1121 0 0

# mount tmp first then GUI
lxc.mount.entry = tmpfs tmp tmpfs nosuid,nodev,noatime,mode=1777,create=dir 0 0

lxc.mount.entry = /ramdisk ramdisk none bind,optional,create=dir,nodev,nosuid 0 0
lxc.mount.entry = tmpfs var/cache/apt/archives tmpfs 
nosuid,nodev,noatime,mode=0755,create=dir 0 0

  lxc-start 20180907081437.752 INFO lxc_start_ui - 
tools/lxc_start.c:main:277 - using rcfile /var/lib/lxc/lxc121/config
  lxc-start 20180907081437.752 WARN lxc_confile - 
confile.c:set_config_pivotdir:2262 - lxc.pivotdir is ignored.  It will soon 
become an error.
  lxc-start 20180907081437.752 INFO lxc_confile - 
confile.c:set_config_idmaps:1861 - read uid map: type u nsid 0 hostid 1210 
range 65536
  lxc-start 20180907081437.752 INFO lxc_confile - 
confile.c:set_config_idmaps:1861 - read uid map: type g nsid 0 hostid 1210 
range 65536
  lxc-start 20180907081437.752 INFO lxc_container - 
lxccontainer.c:do_lxcapi_start:877 - Attempting to set proc title to [lxc 
monitor] /var/lib/lxc lxc121
  lxc-start 20180907081437.752 INFO lxc_lsm - lsm/lsm.c:lsm_init:48 - 
LSM security driver AppArmor
  lxc-start 20180907081437.753 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:435 - processing: .reject_force_umount  # comment 
this to allow umount -f;  not recommended.
  lxc-start 20180907081437.753 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:610 - Adding native rule for reject_force_umount 
action 0(kill).
  lxc-start 20180907081437.753 INFO lxc_seccomp - 
seccomp.c:do_resolve_add_rule:276 - Setting Seccomp rule to reject force 
umounts.
  lxc-start 20180907081437.753 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:614 - Adding compat rule for reject_force_umount 
action 0(kill).
  lxc-start 20180907081437.753 INFO lxc_seccomp - 
seccomp.c:do_resolve_add_rule:276 - Setting Seccomp rule to reject force 
umounts.
  lxc-start 20180907081437.753 INFO lxc_seccomp - 
seccomp.c:do_resolve_add_rule:276 - Setting Seccomp rule to reject force 
umounts.
  lxc-start 20180907081437.753 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:435 - processing: .[all].
  lxc-start 20180907081437.753 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:435 - processing: .kexec_load errno 1.
  lxc-start 20180907081437.753 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:610 - Adding native rule for kexec_load action 
327681(errno).
  lxc-start 20180907081437.753 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:614 - Adding compat rule for kexec_load action 
327681(errno).
  lxc-start 20180907081437.753 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:435 - processing: .open_by_handle_at errno 1.
  lxc-start 20180907081437.753 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:610 - Adding native rule for open_by_handle_at action 
327681(errno).
  lxc-start 20180907081437.753 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:614 - Adding compat rule for open_by_handle_at action 
327681(errno).
  lxc-start 20180907081437.753 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:435 - processing: .init_module errno 1.
  lxc-start 20180907081437.753 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:610 - Adding native rule for init_module action 
327681(errno).
  lxc-start 20180907081437.753 INFO lxc_seccomp - 
seccomp.c:parse_config_v2:614 - Adding compat rule for init_module action 
327681(errno).
  lxc-s

Bug#906013: have you started working on l3afpad ?

[shirish शिरीष]

Dear Paulo,

Have you started packaging l3afpad . If you need a tester please let me know.

I installed and have uninstalled l3afpad in the hopes I get a correct
debian package so that my package manager i.e. apt can do the
necessary work without me doing

make install
and make uninstall

Looking forward to see the package in Debian sid/experimental :)

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#908193: Can sometimes fail to timeout

[Iain Lane]

Package: autopkgtest
Version: 5.5
Severity: normal

Hey,

We don't have much information to help with debugging of this problem. I
just wanted to make sure it is recorded.

We've got an autopkgtest process that is currently (Sep 7) still
running, when it was started:

  Aug 25 07:44:36 juju-prod-ues-proposed-migration-machine-11 sh[31372]: 
2018-08-25 07:44:36,816 [31372] INFO: Received request for package 
r-cran-fastmatch on cosmic/ppc64el; params: {'triggers': 
['glibc/2.28-0ubuntu1']}
  Aug 25 07:44:36 juju-prod-ues-proposed-migration-machine-11 sh[31372]: 
2018-08-25 07:44:36,817 [31372] INFO: Running 
/home/ubuntu/autopkgtest/runner/autopkgtest --output-dir 
/tmp/autopkgtest-work.fdcdgul6/out --timeout-copy=6000 --setup-commands 
/home/ubuntu/autopkgtest-cloud/worker-config-production/setup-canonical.sh 
--setup-commands /home/ubuntu/autopkgtest/setup-commands/setup-testbed 
--apt-pocket=proposed=src:glibc --apt-upgrade r-cran-fastmatch 
--env=ADT_TEST_TRIGGERS=glibc/2.28-0ubuntu1 -- ssh -s 
/home/ubuntu/autopkgtest/ssh-setup/nova -- --nova-reboot --flavor autopkgtest 
--security-groups autopkgtest@bos02-ppc64el-20.secgroup --name 
adt-cosmic-ppc64el-r-cran-fastmatch-20180825-074436 --image 
adt/ubuntu-cosmic-ppc64el-server --keyname 
testbed-juju-prod-ues-proposed-migration-machine-11 
--net-id=net_ues_proposed_migration -e 'http_proxy=http://squid.internal:3128' 
-e 'https_proxy=http://squid.internal:3128' -e 
'no_proxy=127.0.0.1,127.0.1.1,localhost,localdomain,novalocal,internal,archive.ubuntu.com,security.ubuntu.com,changelogs.ubuntu.com,ddebs.ubuntu.com,ppa.launchpad.net'
 --mirror=http://ftpmaster.internal/ubuntu

a long time ago.

I was away at the time, but apparently this affected several instances
around the same time, so it is likely that some event disrupted the
tests and they should have failed / been retried. Unfortunately the logs
have been deleted since then, so I can't see if there is any evidence in
them. If that's true then there might be an additional bug that they
didn't fail harder. This one says that the timeout should be there as an
ultimate fallback.

We're running 5243905d9dbee07d2b712d747fea0decd6e0c78c, so it's a bit
old - but scanning the changes doesn't show anything that's likely to
have changed this. Do let me know if that's wrong though. I'll try to
update us soon in any event.

Cheers!

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]

Bug#908079: Buster: No window title bars in KDE?

[local10]

Sep 6, 2018, 4:33 PM by mar...@lichtvoll.de:

> So I´d use "apt update" and if the package then still is not available,
> check your /etc/apt/sources.list. Maybe your mirror is outdated.
>
I installed kwin-x11 and it did resolve the titlebar problem.  Thanks

Here's a question though: Since KDE cannot function properly without a window 
manager, why isn't a window manager in the KDE package dependency chain? I 
understand some users may prefer a different window system and/or window 
manager but shouldn't KDE package, by default, include everything that KDE 
actually needs to run properly? 


> But again, this is no user support forum. Please use debian-kde mailing

I asked this question on deb-user but did not receive an answer that would 
allow me to solve the issue, so I filed this bug. As for the debian-kde list, I 
didn't even know it existed until you brought it up.

Thanks

Bug#907993: lyx: FTBFS with Qt 5.11

[Dr. Tobias Quathamer]

Am 06.09.2018 um 09:26 schrieb Juhani Numminen:
> This patch fixes the FTBFS, and is in use by LyX upstream, Gentoo and Fedora.

Hi Juhani,

thanks for the pointer, I'm preparing a new upload.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#908194: ITP: ukui-greeter -- lightdm greeter for UKUI

[handsome_feng]

Package: wnpp
Severity: wishlist
Owner: handsome_feng 

* Package name: ukui-greeter
  Version : 1.1.4
  Upstream Author : yanghao 
* URL : https://salsa.debian.org/kylin-team/ukui-greeter
* License : GPL-2+
  Programming Lang: C++
  Description : lightdm greeter for UKUI

A greeter for UKUI desktop environment written by Qt5.
The greeter supports biometric authentication which is
provided by biometric-authentication service.

This package will be maintained by the Kylin Team.

Bug#907925: jhead: Interger overflow while running jhead

[Salvatore Bonaccorso]

Control: retitle -1 jhead: CVE-2018-16554: Interger overflow while running jhead

Hi Hanfang,

On Fri, Sep 07, 2018 at 12:53:38PM +0800, Hanfang Zhang wrote:
> Hi Salvatore,
> 
> I have done that and the CVE ID is CVE-2018-16554. But the status of it is
> preserved. Thanks.

Perfect, thank you!

Regards,
Salvatore

Bug#887361: ccnet: Coordinated Packaging for ccnet and ccnet-server

[Moritz Schlarb]

Hi Nicholas,

On 30.08.18 22:19, Nicholas D Steeves wrote:
> P.S. my apologies, I failed to notice that seafile-client was still at
> 6.2.4 :-(  ( https://github.com/haiwen/seafile )
> 
> I guess we still need to wait...

The changes to really remove ccnet came shortly after they tagged 6.2.4
- I hope I will come around to testing the patches shortly.
But it looks like there's not much time to wait for.

Regards,
-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF
<>

signature.asc
Description: OpenPGP digital signature

Bug#908189: dict-freedict-all: postinst script has a wrong redirection

[Ralf Treinen]

Hello,

On Fri, Sep 07, 2018 at 10:16:52AM +0200, Sebastian Humenda wrote:

> Thanks for the report. This has been fixed in the VCS and will go online in 
> the
> next upload.

thanks for the prompt reaction :-) in fact I intended to send a 
supplement to the bug report in case of freedict: this concerns
in reality a large list of binary packages generated by the
same source package (list attached), but we sent only one bug report 
in order not to clutter the BTS.

Cheers -Ralf
-- 
Ralf Treinen
Institut de Recherche en Informatique Fondamentale
Équipe Preuves, Programmes et Systèmes
Université Paris Diderot, Paris, France.
http://www.irif.fr/~treinen/
dict-freedict-afr-deu_2016.12.12-1
dict-freedict-afr-eng_2016.12.12-1
dict-freedict-ara-eng_2016.12.12-1
dict-freedict-bre-fra_2016.12.12-1
dict-freedict-ces-eng_2016.12.12-1
dict-freedict-ckb-kmr_2016.12.12-1
dict-freedict-cym-eng_2016.12.12-1
dict-freedict-dan-eng_2016.12.12-1
dict-freedict-deu-eng_2016.12.12-1
dict-freedict-deu-fra_2016.12.12-1
dict-freedict-deu-ita_2016.12.12-1
dict-freedict-deu-kur_2016.12.12-1
dict-freedict-deu-nld_2016.12.12-1
dict-freedict-deu-por_2016.12.12-1
dict-freedict-deu-swe_2016.12.12-1
dict-freedict-deu-tur_2016.12.12-1
dict-freedict-eng-afr_2016.12.12-1
dict-freedict-eng-ara_2016.12.12-1
dict-freedict-eng-ces_2016.12.12-1
dict-freedict-eng-cym_2016.12.12-1
dict-freedict-eng-deu_2016.12.12-1
dict-freedict-eng-ell_2016.12.12-1
dict-freedict-eng-fra_2016.12.12-1
dict-freedict-eng-gle_2016.12.12-1
dict-freedict-eng-hin_2016.12.12-1
dict-freedict-eng-hrv_2016.12.12-1
dict-freedict-eng-hun_2016.12.12-1
dict-freedict-eng-ita_2016.12.12-1
dict-freedict-eng-lat_2016.12.12-1
dict-freedict-eng-lit_2016.12.12-1
dict-freedict-eng-nld_2016.12.12-1
dict-freedict-eng-pol_2016.12.12-1
dict-freedict-eng-por_2016.12.12-1
dict-freedict-eng-rom_2016.12.12-1
dict-freedict-eng-rus_2016.12.12-1
dict-freedict-eng-spa_2016.12.12-1
dict-freedict-eng-srp_2016.12.12-1
dict-freedict-eng-swe_2016.12.12-1
dict-freedict-eng-swh_2016.12.12-1
dict-freedict-eng-tur_2016.12.12-1
dict-freedict-fra-bre_2016.12.12-1
dict-freedict-fra-deu_2016.12.12-1
dict-freedict-fra-eng_2016.12.12-1
dict-freedict-fra-nld_2016.12.12-1
dict-freedict-gla-deu_2016.12.12-1
dict-freedict-gle-eng_2016.12.12-1
dict-freedict-gle-pol_2016.12.12-1
dict-freedict-hrv-eng_2016.12.12-1
dict-freedict-hun-eng_2016.12.12-1
dict-freedict-isl-eng_2016.12.12-1
dict-freedict-ita-deu_2016.12.12-1
dict-freedict-ita-eng_2016.12.12-1
dict-freedict-jpn-deu_2016.12.12-1
dict-freedict-jpn-eng_2016.12.12-1
dict-freedict-jpn-fra_2016.12.12-1
dict-freedict-jpn-rus_2016.12.12-1
dict-freedict-kha-deu_2016.12.12-1
dict-freedict-kha-eng_2016.12.12-1
dict-freedict-kur-deu_2016.12.12-1
dict-freedict-kur-eng_2016.12.12-1
dict-freedict-kur-tur_2016.12.12-1
dict-freedict-lat-deu_2016.12.12-1
dict-freedict-lat-eng_2016.12.12-1
dict-freedict-lit-eng_2016.12.12-1
dict-freedict-mkd-bul_2016.12.12-1
dict-freedict-nld-deu_2016.12.12-1
dict-freedict-nld-eng_2016.12.12-1
dict-freedict-nld-fra_2016.12.12-1
dict-freedict-nno-nob_2016.12.12-1
dict-freedict-oci-cat_2016.12.12-1
dict-freedict-pol-gle_2016.12.12-1
dict-freedict-por-deu_2016.12.12-1
dict-freedict-por-eng_2016.12.12-1
dict-freedict-san-deu_2016.12.12-1
dict-freedict-slk-eng_2016.12.12-1
dict-freedict-spa-ast_2016.12.12-1
dict-freedict-spa-eng_2016.12.12-1
dict-freedict-spa-por_2016.12.12-1
dict-freedict-srp-eng_2016.12.12-1
dict-freedict-swe-deu_2016.12.12-1
dict-freedict-swe-eng_2016.12.12-1
dict-freedict-swh-eng_2016.12.12-1
dict-freedict-swh-pol_2016.12.12-1
dict-freedict-tur-deu_2016.12.12-1
dict-freedict-tur-eng_2016.12.12-1

Bug#908195: openssh-server: agent forwarding broken in incoming ssh connections

[Giacomo Mulas]

Package: openssh-server
Version: 1:7.8p1-1
Severity: normal

Dear Maintainer,

with the recent updates of openssh, agent forwarding is broken in incoming
connections.  It still works properly in outgoing connections, which I
tested by logging in on several computers running e.g.  debian stable or
other distros or even another os altogether.  However, when I try to connect
from other machines to my computer, or even upon using locah ssh to
localhost, no credentials are forwarded.
E.g., on the session from which I use ssh:

gmulas@spitzer:~$ ssh-add -l
2048 SHA256:1EiqSAb6gUEpa27SrPhpx2lbj0I2yjz6TWO6HgUuFO4 
/homes/spitzer/gmulas/.ssh/id_rsa (RSA)
1024 SHA256:bcMLBbvPfsCMMYUkXJYLljsNsBhpkC3N//38mnObjIw 
/homes/spitzer/gmulas/.ssh/id_dsa (DSA)
256 SHA256:GdCSZj0SYfo3XgnGAEfaFVJSjqzGuHAq01oYpG5HNEA 
/homes/spitzer/gmulas/.ssh/id_ecdsa (ECDSA)

then I successfully login to my laptop using one of those keys, with

ssh -A capitanata

but if I then ask which credentials are available I get:

gmulas@capitanata:~$ ssh-add -l
The agent has no identities.

The same happens if I do "ssh -A localhost" on my computer.  Nothing changes
if I add "-4" or "-6" options (i.e. it does not depend on using IPv4 vs IPv6).
Nothing changes if I use gnome's keyring daemon vs openssh's agent.
If I turn up debugging level, e.g. "ssh -Avv", I get (among other unrelated 
stuff) on a _broken_ agent connection:

debug1: Entering interactive session.
debug1: pledge: exec
debug1: client_input_global_request: rtype hostkeys...@openssh.com want_reply 0
debug1: Remote: /home/gmulas/.ssh/authorized_keys:3: key options: 
agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /home/gmulas/.ssh/authorized_keys:3: key options: 
agent-forwarding port-forwarding pty user-rc x11-forwarding
debug2: callback start
debug1: X11 forwarding requested but DISPLAY not set
debug1: Requesting authentication agent forwarding.
debug2: channel 0: request auth-agent-...@openssh.com confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1

while on a _working_ connection I get:

debug1: Entering interactive session.
debug1: pledge: exec
debug1: client_input_global_request: rtype hostkeys...@openssh.com want_reply 0
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: x11_get_proto: /usr/bin/xauth  list :0 2>/dev/null
Warning: No xauth data; using fake authentication data for X11 forwarding.
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 1
debug1: Requesting authentication agent forwarding.
debug2: channel 0: request auth-agent-...@openssh.com confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1

Aside from X-related stuff, which should be irrelevant, the only difference
I see is 

debug1: Remote: /home/gmulas/.ssh/authorized_keys:3: key options: 
agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /home/gmulas/.ssh/authorized_keys:3: key options: 
agent-forwarding port-forwarding pty user-rc x11-forwarding

I did not change anything in the ssh configuration upon the latest package.
upgrades.

While I did not tag this as an "important" or "grave" bug, the broken
functionality is a fairly important one for the sshd server, its origin
should definitely be tracked down and either fixed or at least documented.

Please let me know if I can run any useful tests to help.

Thanks in advance, bye
Giacomo Mulas

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

Kernel: Linux 4.17.17-jak (SMP w/4 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to it_IT.UTF-8), LANGUAGE=it_IT,en_EN (charmap=UTF-8) (ignored: LC_ALL set 
to it_IT.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openssh-server depends on:
ii  adduser3.117
ii  debconf [debconf-2.0]  1.5.69
ii  dpkg   1.19.0.5+b1
ii  libaudit1  1:2.8.4-2
ii  libc6  2.27-6
ii  libcom-err21.44.4-2
ii  libgssapi-krb5-2   1.16-2
ii  libkrb5-3  1.16-2
ii  libpam-modules 1.1.8-3.8
ii  libpam-runtime 1.1.8-3.8
ii  libpam0g   1.1.8-3.8
ii  libselinux12.8-1+b1
ii  libssl1.0.21.0.2o-1
ii  libsystemd0239-7
ii  libwrap0   7.6.q-27
ii  lsb-base   9.20170808
ii  openssh-client 1:7.8p1-1
ii  openssh-sftp-server1:7.8p1-1
ii  procps 2:3.3.15-2
ii  ucf3.0038
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages openssh-server recommends:
ii  libpam-systemd  239-7
ii  ncurses-term6.1+20180714-1
ii  xauth 

Bug#908197: ITP: biometric-authentication -- Biometric Authentication Service

[handsome_feng]

Package: wnpp
Severity: wishlist
Owner: handsome_feng 

* Package name: biometric-authentication
  Version : 0.9.55
  Upstream Author : jianglin...@kylinos.cn
* URL : https://salsa.debian.org/kylin-team/biometric-
authentication
* License : LGPL-3+
  Programming Lang: C
  Description : Biometric Authentication Service

A biometric identification framework. Provide unified DBus interface for
application layer, used for various biometric identification and
authentication.

The framework is divided into three layers: service layer, core layer and
drive layer.

And this package will be maintained by the Kylin team.

Bug#908196: linux-image-4.9.0-8-armmp: Please set CONFIG_LEDS_PCA963X=m

[Reco]

Package: src:linux
Version: 4.9.110-3+deb9u4
Severity: wishlist

Dear Maintainer,

I happen to have a piece of hardware (Linksys WRT1200 AC) which runs
stock Debian kernel flawlessly.
There's one small detail that mars that experience - the absence of I2C
LED driver for PCA9634.

Sincerely yours, Reco

-- Package-specific info:
** Version:
Linux version 4.9.0-8-armmp (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21)

** Command line:
console=ttyS0,115200 root=/dev/mapper/xx-root ro quiet apparmor=1 
security=apparmor

** Tainted: WO (4608)
 * Taint on warning.
 * Out-of-tree module has been loaded.

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
Hardware: Marvell Armada 380/385 (Device Tree)
Revision: 
Device Tree model: Linksys WRT1200AC

** Loaded modules:
tcp_diag
inet_diag
ctr
ccm
ip6t_MASQUERADE
nf_nat_masquerade_ipv6
ip6table_nat
nf_nat_ipv6
xt_TCPMSS
xfrm4_tunnel
ipcomp
ebt_ip
ebt_arp
ebtable_filter
ebtables
8021q
garp
mrp
ip6t_REJECT
nf_reject_ipv6
nf_conntrack_ipv6
nf_defrag_ipv6
ip6table_filter
ip6_tables
ipt_REJECT
nf_reject_ipv4
xt_mac
xt_limit
xt_owner
xt_multiport
xt_hashlimit
xt_comment
xt_mark
xt_conntrack
iptable_filter
cls_fw
ipt_MASQUERADE
nf_nat_masquerade_ipv4
em_meta
xt_nat
cls_basic
xt_tcpudp
sch_htb
iptable_nat
nf_conntrack_ipv4
nf_defrag_ipv4
nf_nat_ipv4
nf_nat
nf_conntrack
bridge
stp
llc
sit
af_key
ah4
esp4
iptable_raw
iptable_mangle
ip_vti
ip_tunnel
echainiv
authenc
ansi_cprng
drbg
xfrm_ipcomp
xfrm_user
xfrm_algo
tunnel4
xfrm4_mode_tunnel
xfrm6_mode_tunnel
arc4
sg
ofpart
pxa3xx_nand
marvell_cesa
tmp421
leds_gpio
evdev
orion_wdt
des_generic
mwlwifi(O)
mac80211
cfg80211
auth_rpcgss
oid_registry
rfkill
sunrpc
ip_tables
x_tables
autofs4
crc32c_generic
ext4
crc16
jbd2
fscrypto
mbcache
dm_mod
sd_mod
uas
usb_storage
ahci_mvebu
libahci_platform
libahci
libata
xhci_plat_hcd
ehci_orion
ehci_hcd
phy_generic
xhci_hcd
usbcore
scsi_mod
mvmdio
usb_common
mvneta
i2c_mv64xxx
dsa_core

** PCI devices:
00:01.0 PCI bridge [0604]: Marvell Technology Group Ltd. Device [11ab:6820] 
(rev 04) (prog-if 00 [Normal decode])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 

00:02.0 PCI bridge [0604]: Marvell Technology Group Ltd. Device [11ab:6820] 
(rev 04) (prog-if 00 [Normal decode])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 

01:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88W8864 
[Avastar] 802.11ac Wireless [11ab:2a55]
Subsystem: Marvell Technology Group Ltd. 88W8864 [Avastar] 802.11ac 
Wireless [11ab:]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: mwlwifi
Kernel modules: mwlwifi

02:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88W8864 
[Avastar] 802.11ac Wireless [11ab:2a55]
Subsystem: Marvell Technology Group Ltd. 88W8864 [Avastar] 802.11ac 
Wireless [11ab:]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: mwlwifi
Kernel modules: mwlwifi


** USB devices:
Bus 003 Device 002: ID 1058:25a2 Western Digital Technologies, Inc. 
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


-- System Information:
Debian Release: 9.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armhf (armv7l)

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

Versions of packages linux-image-4.9.0-8-armmp depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.130
ii  kmod23-2
ii  linux-base  4.5

Versions of packages linux-image-4.9.0-8-armmp recommends:
pn  firmware-linux-free  
ii  irqbalance   1.1.0-2.3

Versions of packages linux-image-4.9.0-8-armmp suggests:
pn  debian-kernel-handbook  
pn  linux-doc-4.9   

Versi

Bug#823755: pinpoint segfault with gdb details

[Andrew Donnellan]

On 07/09/18 19:00, Andrew Donnellan wrote:

On 07/09/18 17:23, Andrew Donnellan wrote:

Hi there,

I'm also seeing this segfault.


I should add that I'm observing this when I'm using the mouse to click 
through slides - if I don't click and only use the keyboard things seem 
to work. This is different from what the original reporter saw.




After installing all the debug symbols required, I see the following gdb 
backtrace and valgrind output:


(gdb) run /usr/share/doc/pinpoint/examples/introduction.pin
Starting program: /usr/bin/pinpoint 
/usr/share/doc/pinpoint/examples/introduction.pin

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe77d7700 (LWP 32504)]
[New Thread 0x7fffe6fd6700 (LWP 32505)]

Thread 1 "pinpoint" received signal SIGSEGV, Segmentation fault.
__GI___pthread_mutex_lock (mutex=0x20) at ../nptl/pthread_mutex_lock.c:67
67  ../nptl/pthread_mutex_lock.c: No such file or directory.
(gdb) bt
#0  __GI___pthread_mutex_lock (mutex=0x20) at 
../nptl/pthread_mutex_lock.c:67
#1  0x741f325a in XrmQGetResource () from 
/usr/lib/x86_64-linux-gnu/libX11.so.6
#2  0x741cf6e6 in XGetDefault () from 
/usr/lib/x86_64-linux-gnu/libX11.so.6
#3  0x7fffede27682 in _XcursorGetDisplayInfo () from 
/usr/lib/x86_64-linux-gnu/libXcursor.so.1
#4  0x7fffede276d9 in XcursorSupportsARGB () from 
/usr/lib/x86_64-linux-gnu/libXcursor.so.1
#5  0x7fffede2a171 in XcursorNoticeCreateBitmap () from 
/usr/lib/x86_64-linux-gnu/libXcursor.so.1
#6  0x741c9c71 in XCreatePixmap () from 
/usr/lib/x86_64-linux-gnu/libX11.so.6
#7  0x74a6a1c4 in _gdk_x11_window_create_bitmap_surface 
(window=0x5579a020, width=width@entry=1, height=height@entry=1) at 
././gdk/x11/gdkwindow-x11.c:586
#8  0x74a471f2 in get_blank_cursor (display=0x55790110) at 
././gdk/x11/gdkcursor-x11.c:219
#9  _gdk_x11_display_get_cursor_for_type (display=0x55790110, 
cursor_type=GDK_BLANK_CURSOR) at ././gdk/x11/gdkcursor-x11.c:270
#10 0x76d75966 in clutter_stage_gdk_set_cursor_visible 
(stage_window=0x557902b0, cursor_visible=) at 
gdk/clutter-stage-gdk.c:552
#11 0x76dde1b4 in clutter_stage_hide_cursor 
(stage=0x55bff200) at clutter-stage.c:2724
#12 0xc863 in hide_cursor_cb (stage=) at 
pp-clutter.c:327

#13 0x757bb123 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x757ba6aa in g_main_context_dispatch () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0

#15 0x757baa60 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#16 0x757bab0c in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x76a3972d in g_application_run () from 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#18 0x9672 in main (argc=, argv=out>) at pinpoint.c:271


--

==31771== Use of uninitialised value of size 8
==31771==at 0x74AAB20: pthread_mutex_lock (pthread_mutex_lock.c:67)
==31771==by 0x8774259: XrmQGetResource (in 
/usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==31771==by 0x87506E5: XGetDefault (in 
/usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==31771==by 0xEBE7681: _XcursorGetDisplayInfo (in 
/usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2)
==31771==by 0xEBE76D8: XcursorSupportsARGB (in 
/usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2)
==31771==by 0xEBEA170: XcursorNoticeCreateBitmap (in 
/usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2)
==31771==by 0x874AC70: XCreatePixmap (in 
/usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==31771==by 0x7FA41C3: _gdk_x11_window_create_bitmap_surface 
(gdkwindow-x11.c:586)

==31771==by 0x7F811F1: get_blank_cursor (gdkcursor-x11.c:219)
==31771==by 0x7F811F1: _gdk_x11_display_get_cursor_for_type 
(gdkcursor-x11.c:270)
==31771==by 0x5BC7965: clutter_stage_gdk_set_cursor_visible 
(clutter-stage-gdk.c:552)

==31771==by 0x5C301B3: clutter_stage_hide_cursor (clutter-stage.c:2724)
==31771==by 0x110862: hide_cursor_cb (pp-clutter.c:327)
==31771==
==31771== Invalid read of size 4
==31771==at 0x74AAB20: pthread_mutex_lock (pthread_mutex_lock.c:67)
==31771==by 0x8774259: XrmQGetResource (in 
/usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==31771==by 0x87506E5: XGetDefault (in 
/usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==31771==by 0xEBE7681: _XcursorGetDisplayInfo (in 
/usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2)
==31771==by 0xEBE76D8: XcursorSupportsARGB (in 
/usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2)
==31771==by 0xEBEA170: XcursorNoticeCreateBitmap (in 
/usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2)
==31771==by 0x874AC70: XCreatePixmap (in 
/usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==31771==by 0x7FA41C3: _gdk_x11_window_create_bitmap_surface 
(gdkwindow-x11.c:586)

==31771==by 0x7F811F1: get_blank_cursor (gdkcursor-x11.c:219)
==31771==by 0x7F811F1: _gdk_x11_display

Bug#803907: systemd: Unable to shutdown/restart because of 'nobody' session

[Michael Biebl]

On Mon, 02 Nov 2015 19:45:14 -0800 Nikolaus Rath  wrote:
> Package: systemd
> Version: 215-17+deb8u2
> Severity: normal
> 
> Dear Maintainer,
> 
> I would like to restart my system, but:
> 
> $ systemctl poweroff
> User nobody is logged in on ???.
> Please retry operation after closing inhibitors and logging out other
> users.
> Alternatively, ignore inhibitors and users with 'systemctl poweroff -i'.
> 
> Upon closer investigation:
> 
> $ grep nobody /etc/passwd
> nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
> $ ps -U 65534
>   PID TTY  TIME CMD
>  7701 ?00:00:00 systemd
>  7702 ?00:00:00 (sd-pam)
> 
> 
> I don't know what exactly this systemd process is doing, but I
> did not start it, and I can't imagine that it does anything useful.

Is this still a problem?

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#823755: pinpoint segfault with gdb details

[Andrew Donnellan]

On 07/09/18 19:17, Andrew Donnellan wrote:
After installing all the debug symbols required, I see the following gdb 
backtrace and valgrind output:


(gdb) run /usr/share/doc/pinpoint/examples/introduction.pin
Starting program: /usr/bin/pinpoint 
/usr/share/doc/pinpoint/examples/introduction.pin

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe77d7700 (LWP 32504)]
[New Thread 0x7fffe6fd6700 (LWP 32505)]

Thread 1 "pinpoint" received signal SIGSEGV, Segmentation fault.
__GI___pthread_mutex_lock (mutex=0x20) at ../nptl/pthread_mutex_lock.c:67
67  ../nptl/pthread_mutex_lock.c: No such file or directory.
(gdb) bt
#0  __GI___pthread_mutex_lock (mutex=0x20) at 
../nptl/pthread_mutex_lock.c:67
#1  0x741f325a in XrmQGetResource () from 
/usr/lib/x86_64-linux-gnu/libX11.so.6


Googling for this led me to a few other Debian bug reports that appear 
to show segfaults in the XrmQGetResource() path, e.g. 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700015


#700015 suggests that there's a missing call to XInitThreads() which 
results in uninitialised mutexes.


To verify this, I did the same thing suggested at 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700015#10 and invoked 
XInitThreads() manually in gdb:


(gdb) break main
Breakpoint 1 at 0x5490: file pinpoint.c, line 191.
(gdb) run /usr/share/doc/pinpoint/examples/introduction.pin
Starting program: /usr/bin/pinpoint 
/usr/share/doc/pinpoint/examples/introduction.pin

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, main (argc=2, argv=0x7fffddd8) at pinpoint.c:191
191 pinpoint.c: No such file or directory.
(gdb) call XInitThreads()
$1 = 1
(gdb) continue

It appears that this fixes the problem.

I haven't looked as far as figuring out where the right place to put 
this XInitThreads() call would be - maybe pinpoint itself, maybe one of 
its graphics libraries, or maybe the libraries aren't being invoked 
properly...


--
Andrew Donnellan  OzLabs, ADL Canberra
andrew.donnel...@au1.ibm.com  IBM Australia Limited

Bug#908146: libreoffice-dictionaries: Dealing with Breaks/Replaces against ancient dicts in other myspell/hunspell packages.

[Agustin Martin]

On Thu, Sep 06, 2018 at 08:58:37PM +0200, Mattia Rizzolo wrote:
> Hi Agustin!

Hi Mattia, thanks for the quick reply,
 
> On Thu, Sep 06, 2018 at 07:00:16PM +0200, Agustin Martin wrote:
> > I have recently received some bug reports about making transitional myspell
> > packages to hunspell packages contained in lo-dicts. Some of them refer to
> > myspell packages containing old versions of the same dict shipped with
> > lo-dicts, so version in lo-dicts should really be used.
> 
> I saw and acted upon similar bugs already in the past, nothing
> particularly new to be explained :)
> 
> > I think this should be dealt previously from inside lo-dicts adding
> > appropriate Breaks/Replaces, and old packages made transitional afterwards.
> 
> Note that if you also look for a home to keep those transitional
> packages, we can also build them within lo-dicts (we would drop them
> after buster, which also means after ubuntu 18.04, so everything's
> great).
> But from what I can see the source packages you mentions in this bug
> report are building something else anyway, so I guess they can also keep
> building those transitional packages.

Thanks for the info, I did not find the relevant part in helper.py.

There is one package (hunspell-sv) where that is desirable, since it will
only contain transitional packages hunspell-sv-se and myspell-sv-se, so
I think it is better if hunspell-sv-se transitional package is created
from lo-dicts itself.

Regarding myspell-sv-se transitional package, it was created back in 2011,
so I think is safe not to worry anymore about it.

I will ask for old hunspell-sv removal afterwards,
 
> > A proposed patch is added.
> 
> Please just confirm you won't need anything else, and I'll upload your
> patch quickly so you can turn the rest into transitional packages :)

Apart from the above, I think nothing else is needed.

Thanks for everything,

Regards,

-- 
Agustin

Bug#908198: tilestache does not render mapnik tiles

[Daniel Schreiber]

Package: tilestache
Version: 1.51.5-3
Severity: wishlist

Dear Maintainer,

tilestache in testing does not work due to API changes in the python 
mapnik bindings. There is an upstream bugfix in tilestache which fixes 
that issue:


https://github.com/TileStache/TileStache/pull/337/commits/2c0a957d353af87d9057d3ba03c6f3033e0f80d5

Please consider applying this patch until a fixed upstream release 
becomes available.


I used a configuration like this:

{
  "cache":
  {
"name": "Disk",
"path": "/var/cache/stache",
"umask": ""
  },
  "layers":
  {
"osm":
{
"provider": {
"name": "mapnik",
"mapfile": "/opt/osm/openstreetmap-carto/project.xml"
},
"projection": "spherical mercator"
}
  }
}
I use the openstreetmap-carto style.

Without the patch it throws the following exception:

tilestache-server -c tilestache.cfg -i 0.0.0.0
Error loading Tilestache config:
Traceback (most recent call last):
  File "/usr/bin/tilestache-server", line 55, in 
app = TileStache.WSGITileServer(config=options.file, autoreload=True)
  File "/usr/lib/python2.7/dist-packages/TileStache/__init__.py", line 
374, in __init__

self.config = parseConfig(config)
  File "/usr/lib/python2.7/dist-packages/TileStache/__init__.py", line 
136, in parseConfig

return Config.buildConfiguration(config_dict, dirpath)
  File "/usr/lib/python2.7/dist-packages/TileStache/Config.py", line 
226, in buildConfiguration

config.layers[name] = _parseConfigLayer(layer_dict, config, dirpath)
  File "/usr/lib/python2.7/dist-packages/TileStache/Config.py", line 
472, in _parseConfigLayer

layer.provider = _class(layer, **provider_kwargs)
  File "/usr/lib/python2.7/dist-packages/TileStache/Mapnik.py", line 
94, in __init__

engine = mapnik.FontEngine.instance()
AttributeError: type object 'FontEngine' has no attribute 'instance'


Thank you,

Daniel

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

Kernel: Linux 4.17.0-3-amd64 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tilestache depends on:
ii  fonts-dejavu-core  2.37-1
ii  python 2.7.15-3
ii  python-modestmaps  1.4.7-3
ii  python-pil 5.2.0-2
ii  python-simplejson  3.15.0-1+b1
ii  python-werkzeug0.14.1+dfsg1-1

Versions of packages tilestache recommends:
ii  libjs-modestmaps  3.3.6+ds2-1
pn  python-blit   
ii  python-gdal   2.3.1+dfsg-3
ii  python-mapnik 1:0.0~20180411-fe47aa15e-3
ii  python-psycopg2   2.7.5-2
ii  python-pyproj 1.9.5.1-4
ii  python-pysolr 3.6.0-1
ii  python-shapely1.6.4-2

Versions of packages tilestache suggests:
pn  python-boto  
pn  python-memcache  
pn  python-redis 

-- no debconf information

--
Daniel Schreiber
Facharbeitsgruppe Systemsoftware
Universitaetsrechenzentrum

Technische Universität Chemnitz
Straße der Nationen 62 (Raum B303)
09111 Chemnitz
Germany

Tel: +49 371 531 35444
Fax: +49 371 531 835444



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#908200: grub-efi-*-signed: mismatch between /EFI/vendor (used) and /EFI/debian (expected) when derivative uses unmodified Debian binary packages

[Raphaël Hertzog]

Source: grub2
Version: 2.02+dfsg1-6
Severity: important
User: de...@kali.org
Usertags: origin-kali

In Kali, UEFI users are no longer able to boot their system:
https://bugs.kali.org/view.php?id=4956

The problem seems to come down to the fact that during initial installation,
(at least) when the install picks the new *-signed packages, they get
installed to /EFI/kali but the binary installed inside is actually
expecting the configuration file in /EFI/debian/grub.cfg.

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

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

Bug#742126: "dd if=" completion broken

[Marcel]

I have the same problem and could get rid of it by removing the file 
/usr/share/bash-completion/completions/dd . I do not have anything in 
/usr/share/bash_completion.d/ nor do I have problems with other commands.


Cheers,

Marcel




smime.p7s
Description: S/MIME Cryptographic Signature

Bug#908198: tilestache does not render mapnik tiles

[Sebastiaan Couwenberg]

Control: tags -1 pending

Hi Daniel,

Thanks for reporting this issue with a link to the patch.

On 9/7/18 11:21 AM, Daniel Schreiber wrote:
> tilestache in testing does not work due to API changes in the python
> mapnik bindings. There is an upstream bugfix in tilestache which fixes
> that issue:
> 
> https://github.com/TileStache/TileStache/pull/337/commits/2c0a957d353af87d9057d3ba03c6f3033e0f80d5
> 
> 
> Please consider applying this patch until a fixed upstream release
> becomes available.

The patch from https://github.com/TileStache/TileStache/pull/327 was
used instead.

A new upload to unstable will following shortly, which should migrated
to testing in 5 days.

Kind Regards,

Bas

Bug#854388: systemd: lid switch not detected on acer chromebook

[Milan P. Stanic]

Dear Michael,

I gave that acer chromebook to another person before more than one and a
half year, so I can't check how it works now regarding that systemd
problem. I have another chromebook (samsung one plus) but it works under
Alpine Linux and openrc so I cannot test Debian systemd on it.

Best regards

On Fri, 2018-09-07 at 03:14, Michael Biebl wrote:
> Control: tags -1 + moreinfo
> 
> On Mon, 6 Feb 2017 15:45:20 +0100 "Milan P. Stanic"  wrote:
> > Package: systemd
> > Version: 232-15
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> >* What led up to the situation?
> >  Installed Debian on the acer chromebook R13 (mediatek MT8173 SOC,
> >  board called elm (oak)) armv8 with the kernel source from chromeos
> >  site and built myself for that device.
> > 
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> >  By closing screen logind does not detect lid switch
> > 
> >* What was the outcome of this action?
> >  Device does not suspend
> > 
> >* What outcome did you expect instead?
> >  Suspend
> > 
> > During boot kernel recognizes that the device have lid switch, here is
> > the log from journalctl:
> > Feb 05 17:20:01 zarya kernel: of_get_named_gpiod_flags: parsed 'gpios' 
> > property of node '/gpio-keys/lid[0]' - status (0)
> > Feb 05 17:20:01 zarya kernel: of_get_named_gpiod_flags: parsed 'gpios' 
> > property of node '/gpio-keys/power[0]' - status (0)
> > Feb 05 17:20:01 zarya kernel: of_get_named_gpiod_flags: parsed 'gpios' 
> > property of node '/gpio-keys/tablet_mode[0]' - status (0)
> > Feb 05 17:20:01 zarya kernel: of_get_named_gpiod_flags: parsed 'gpios' 
> > property of node '/gpio-keys/volume_down[0]' - status (0)
> > Feb 05 17:20:01 zarya kernel: of_get_named_gpiod_flags: parsed 'gpios' 
> > property of node '/gpio-keys/volume_up[0]' - status (0)
> > Feb 05 17:20:01 zarya kernel: input: gpio-keys as 
> > /devices/gpio-keys/input/input5
> > 
> > but systemd-logind does not report that it is watching any of these
> > keys, as it does on another armv7 or amd64 where I tested lid switch.
> 
> what's the output of evtest on those devices?
> 
> > evtest detect all these when I run it to test does kernel works, here it
> > is output of invoking it:
> > 
> > No device specified, trying to scan all of /dev/input/event*
> > Available devices:
> > /dev/input/event0:  cros_ec
> > /dev/input/event1:  Elan Touchscreen
> > /dev/input/event2:  Elan Touchpad
> > /dev/input/event3:  mtk-rt5650 Headset Jack
> > /dev/input/event4:  mtk-rt5650 HDMI Jack
> > /dev/input/event5:  gpio-keys
> > Select the device event number [0-5]: 5
> > Input driver version is 1.0.1
> > Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100
> > Input device name: "gpio-keys"
> > Supported events:
> > Event type 0 (EV_SYN)
> > Event type 1 (EV_KEY)
> > Event code 114 (KEY_VOLUMEDOWN)
> > Event code 115 (KEY_VOLUMEUP)
> > Event code 116 (KEY_POWER)
> > Event type 5 (EV_SW)
> > Event code 0 (SW_LID) state 0
> > Event code 1 (SW_TABLET_MODE) state 0
> > Properties:
> > Testing ... (interrupt to exit)
> > Event: time 1486391966.918428, type 5 (EV_SW), code 0 (SW_LID), value 1
> 
> 
> This looks quite a bit different here:
> 
> # evtest
> No device specified, trying to scan all of /dev/input/event*
> Available devices:
> /dev/input/event0:AT Translated Set 2 keyboard
> /dev/input/event1:Lid Switch
> /dev/input/event2:Sleep Button
> /dev/input/event3:Power Button
> ...
> Select the device event number [0-20]: 1
> Input driver version is 1.0.1
> Input device ID: bus 0x19 vendor 0x0 product 0x5 version 0x0
> Input device name: "Lid Switch"
> Supported events:
>   Event type 0 (EV_SYN)
>   Event type 5 (EV_SW)
> Event code 0 (SW_LID) state 0
> 
> 
> I wonder if logind does not detect the lid switch device as it
> apparently also does all sort of other events.
> 
> Can you post the output of running
> SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-logind
> 
> You need to stop the already running logind via
> systemctl stop systemd-logind (make sure to run those commands from a
> tty and not from within X)
> 
> 
> 
> 
> -- 
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> 

Bug#908158: webext-ublock-origin: xul-ext-ublock-origin and webext-ublock-origin should co-exist

[Mykola Nikishov]

Carsten Schoenert  writes:

> If users install a separate additional FF package they are on
> their own, but the system is flexible enough to get this handled.

... and I'm trying to make use of such flexibility. For smooth migration
I'd like to use current firefox-esr/stable and
xul-ext-ublock-origin/stable while moving to firefox/unstable with
webext-ublock-origin/unstable (whatever unstable might be at the
moment).

As I understand, there are no technical problems having both
xul-ext-ublock-origin and webext-ublock-origin installed. And even for
the same Firefox profile, both FF ESR and FF would just ignore
unsupported one.

Having said that, I think Breaks: constraint could be relaxed.

-- 
Mykola
https://manandbytes.git{lab,hub}.io/

Bug#908095: Buster: Kwrite crashes while opening a file

[local10]

Was able to open the problematic file by reconfiguring Kwrite and changing the 
default encoding to UTF-8 and the fallback encoding to UTF-16 (Kwrite keeps 
changing UTF-16 to ucs2 but whatever).

That's a good news for me, of course, but still I feel Kwrite shouldn't crash 
like that even if the default and fallback encoding do not match the file's 
encoding. In Wheezy I sometimes would open a binary file with Kwrite and I 
don't even remember when Kwrite crashed like that, if it ever did.

Regards,

Bug#908201: RM: debian-games -- NBS; games-finest-light no longer built from source

[Markus Koschany]

Package: ftp.debian.org
Severity: normal

Dear ftp team,

please remove the games-finest-light binary package. It is no longer
built from source but is blocking the migration to testing.

Regards,

Markus

Bug#908005: nvidia-driver: When initializing vulkan, driver opens default XDisplay

[Luca Boccassi]

Control: reassign -1 bumblebee
Control: forcemerge 892646 -1

On Wed, 2018-09-05 at 06:52 +0200, Felix Dörre wrote:
> Package: nvidia-driver
> Version: 390.77-1
> Severity: important
> 
> Dear Maintainer,
> 
> I have an Nvidia-Optimus setup and use bumblebee to activate the
> Nvidia GPU on demand.
> 
> When I use libvulkan.so.1 to run a Vulkan application the ICD from
> Nvidia (installed in /usr/share/vulkan/icd.d/nvidia_icd.json,
> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1) opens a connection to
> the
> default X Display (as specified by the DISPLAY environment variable).
> When using bumblebee to activate the Nvidia GPU, the driver must
> connect to Display :8, where bumblebee runs the secondary
> X Server. However I want to run my application with the DISPLAY
> environment variable set to :0 (as I want it displayed on :0).
> 
> I generally would expect the Vulkan-Nvidia driver not to require an
> X-connection when doing headless rendering and for 'normal' rendering
> use the X-connection/display that is indicated by the surface-
> creation functions, and not choose one by itself on startup.
> If that is hard to achieve, I would at least expext the Nvidia-Driver 
> to have some override environment variable (like e.g. NV_DISPLAY)
> that, when set, is passed by the Nvidia-Driver to XOpenDisplay, that
> "normal" applications would ignore.

Hi, Vulkan is not supported on Optimus, see #892646.

-- 
Kind regards,
Luca Boccassi

signature.asc
Description: This is a digitally signed message part

Bug#908202: tryton-server: Install fails during configuration

[Alexander Senger]

Package: tryton-server
Version: 4.6.7-1+dto~9stretch+1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I attempt to install a newer version of tryton-server from debian.tryton.org 
which seems to be maintained by Debian maintainer yangoon.

After adding the appropriate sources.list, issuing a

$ apt-get install tryton-server

works smoothly until tryton-server is about to be configured. The configuration 
fails with:

> tryton-server (4.6.7-1+dto~9stretch+1) wird eingerichtet ...
> update-rc.d: error: no runlevel symlinks to modify, aborting!
> dpkg: Fehler beim Bearbeiten des Paketes tryton-server (--configure):
> Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 
> zurück
> Fehler traten auf beim Bearbeiten von:
> tryton-server
> E: Sub-process /usr/bin/dpkg returned an error code (1)

Subsequent attempts to install necessary modules (tryton-modules) fails due to 
the unfinished configuration of tryton-server,
rendering tryton unusable.


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

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

Versions of packages tryton-server depends on:
ii  adduser3.115
ii  lsb-base   9.20161125
ii  python33.5.3-1
ii  python3-dateutil   2.5.3-2
ii  python3-genshi 0.7-5
ii  python3-lxml   3.7.1-1
ii  python3-pkg-resources  33.1.1-1
ii  python3-polib  1.0.8-1
ii  python3-relatorio  0.7.1-1~9stretch+1
ii  python3-sql0.8-3
ii  python3-werkzeug   0.11.15+dfsg1-1
ii  python3-wrapt  1.9.0-2

Versions of packages tryton-server recommends:
ii  postgresql   9.6+181+deb9u2
ii  python3-bcrypt   3.1.2-1
ii  python3-levenshtein  0.12.0-2+b2
ii  python3-psycopg2 2.6.2-1
ii  python3-pydot1.0.28-2
ii  ssl-cert 1.0.39
ii  unoconv  0.7-1.1

Versions of packages tryton-server suggests:
ii  postgresql-client-9.6 [postgresql-client]  9.6.10-0+deb9u1
pn  python3-sphinx 
pn  tryton-client  
pn  tryton-modules-all 
pn  tryton-server-doc  

-- no debconf information

Bug#907988: rubber must specify the encoding when opening files

[Emmanuel Fleury]

Hi all,

I just reported this bug to the rubber dev-team. Waiting for the next
bug-fix, I suggested the following fix:

In file /usr/lib/python3/dist-packages/rubber/converters/latex.py, at
line 183:

  self.lines = None
  try:
-   with open (name, encoding='utf-8') as fp:
+   with open (name, encoding='utf-8', errors='replace') as fp:
line = fp.readline ()
if not line or not re_loghead.match (line):


This patch fixed it on my system.

-- 
Emmanuel Fleury

I do not fear computers. I fear the lack of them.
  -- Isaac Asimov



signature.asc
Description: OpenPGP digital signature

Bug#908203: opam: Should not depend on aspcud any more

[Ralf Jung]

Package: opam
Version: 2.0.0-2
Severity: normal

Dear Maintainer,

Quoting from https://opam.ocaml.org/doc/2.0/External_solvers.html:

> As of 2.0.0, opam comes with a CUDF solver built-in by default, so unless you
> have specifically compiled without it, you shouldn't have to be worried about
> installing an external solver.

So, aspcud should at best be a recommendation, not a dependency.  Likely, it
should just be a suggestions; the internal solver is used by default even when
aspcud is installed.

Kind regards,
Ralf

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

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

Bug#908204: git-buildpackage: cannot use gbp push without tagging a release

[Norbert Preining]

Package: git-buildpackage
Version: 0.9.10
Severity: important

$ gbp push --verbose
gbp:debug: ['git', 'rev-parse', '--show-cdup']
gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
gbp:debug: ['git', 'rev-parse', '--git-dir']
gbp:debug: ['git', 'symbolic-ref', 'HEAD']
gbp:debug: ['git', 'show-ref', 'refs/heads/master']
gbp:debug: ['git', 'config', 'branch.master.remote']
gbp:debug: ['git', 'config', 'branch.master.merge']
gbp:debug: ['git', 'tag', '-l', 'debian/3.31.0+dfsg-1']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 
'debian/3.31.0+dfsg-1^{commit}']
gbp:error: revision 'debian/3.31.0+dfsg-1^{commit}' not found
$

And ... so what? 

I don't care whether I have already a debian release tag, I
want to push the stuff so that I can continue working on a different
computer.

Thanks

Norbert


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

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

Versions of packages git-buildpackage depends on:
ii  devscripts 2.18.4
ii  git1:2.19.0~rc2-1
ii  man-db 2.8.4-2
ii  python33.6.6-1
ii  python3-dateutil   2.7.3-1
ii  python3-pkg-resources  40.2.0-1
ii  sensible-utils 0.0.12

Versions of packages git-buildpackage recommends:
ii  cowbuilder0.87+b1
ii  pbuilder  0.229.3
ii  pristine-tar  1.44
ii  python3-requests  2.18.4-2

Versions of packages git-buildpackage suggests:
pn  python3-notify2  
ii  sudo 1.8.23-2
ii  unzip6.0-21

-- no debconf information

Bug#908205: cups: Cannot print on my hp wireless printer

[Eric Valette]

Package: cups
Version: 2.3~b5-2
Severity: important


May be related to this https://github.com/apple/cups/issues/5394 as I was using 
ghostscript 9.24~~rc2~dfsg-1
When trying to print the default test page I get : 

 | ./base/gsicc_manage.c:1863: gsicc_verify_device_profiles(): Mismatch of ICC 
profiles and device color model
D [07/Sep/2018:12:58:41 +0200] [Job 347] | ./base/gsicc_manage.c:1990: 
gsicc_set_device_profile(): Error in device profiles
D [07/Sep/2018:12:58:41 +0200] [Job 347] Unrecoverable error: rangecheck in 
.putdeviceprops
D [07/Sep/2018:12:58:41 +0200] [Job 347] Operand stack:
D [07/Sep/2018:12:58:41 +0200] [Job 347] true
D [07/Sep/2018:12:58:41 +0200] [Job 347] PID 5578 
(/usr/lib/cups/filter/gstoraster) stopped with status 1.
D [07/Sep/2018:12:58:41 +0200] [Job 347] Hint: Try setting the LogLevel to 
"debug" to find out more.
D [07/Sep/2018:12:58:41 +0200] [Job 347] prnt/hpcups/HPCupsFilter.cpp 568: 
cupsRasterOpen failed, fd = 0
D [07/Sep/2018:12:58:41 +0200] [Job 347] prnt/backend/hp.c 919: ERROR: null 
print job total=0
D [07/Sep/2018:12:58:41 +0200] [Job 347] PID 5579 (/usr/lib/cups/filter/hpcups) 
stopped with status 1.
D [07/Sep/2018:12:58:41 +0200] [Job 347] Hint: Try setting the LogLevel to 
"debug" to find out more.
D [07/Sep/2018:12:58:41 +0200] [Job 347] PID 5580 (/usr/lib/cups/backend/hp) 
exited with no errors.
D [07/Sep/2018:12:58:41 +0200] [Job 347] End of messages
D [07/Sep/2018:12:58:41 +0200] [Job 347] printer-state=3(idle)
D [07/Sep/2018:12:58:41 +0200] [Job 347] printer-state-message="Filter failed"
D [07/Sep/2018:12:58:41 +0200] [Job 347] printer-state-reasons=none
tri-yann4:~# dpkg -S /usr/lib/cups/filter/gstoraster
cups-filters: /usr/lib/cups/filter/gstoraster
tri-yann4:~# file /usr/lib/cups/filter/gstoraster
/usr/lib/cups/filter/gstoraster: ELF 64-bit LSB shared object, x86-64, version 
1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for 
GNU/Linux 3.2.0, BuildID[sha1]=b90e688cf14c80643315ca0ffa6c00e6d5abe49f, 
stripped


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

Kernel: Linux 4.14.68 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cups depends on:
ii  cups-client2.3~b5-2
ii  cups-common2.3~b5-2
ii  cups-core-drivers  2.3~b5-2
ii  cups-daemon2.3~b5-2
ii  cups-filters   1.21.2-1
ii  cups-ppdc  2.3~b5-2
ii  cups-server-common 2.3~b5-2
ii  debconf [debconf-2.0]  1.5.69
ii  ghostscript9.24~~rc2~dfsg-1
ii  libavahi-client3   0.7-4
ii  libavahi-common3   0.7-4
ii  libc6  2.27-6
ii  libcups2   2.3~b5-2
ii  libcupscgi12.3~b5-2
ii  libcupsimage2  2.3~b5-2
ii  libcupsmime1   2.3~b5-2
ii  libcupsppdc1   2.3~b5-2
ii  libgcc11:8.2.0-5
ii  libstdc++6 8.2.0-5
ii  libusb-1.0-0   2:1.0.22-2
ii  poppler-utils  0.66.0-1
ii  procps 2:3.3.15-2

Versions of packages cups recommends:
ii  avahi-daemon 0.7-4
ii  colord   1.3.3-2
ii  cups-filters [ghostscript-cups]  1.21.2-1
ii  printer-driver-gutenprint5.3.0~pre1-3

Versions of packages cups suggests:
ii  cups-bsd   2.3~b5-2
ii  foomatic-db-compressed-ppds [foomatic-db]  20180604-1
ii  hplip  3.18.7+dfsg1-1
ii  printer-driver-cups-pdf [cups-pdf] 3.0.1-5
ii  printer-driver-hpcups  3.18.7+dfsg1-1
ii  smbclient  2:4.8.5+dfsg-1
ii  udev   239-7

-- debconf information:
  cupsys/backend: lpd, socket, usb, snmp, dnssd
  cupsys/raw-print: true

Bug#823755: pinpoint segfault with gdb details

[Andrew Donnellan]

On 07/09/18 17:23, Andrew Donnellan wrote:

Hi there,

I'm also seeing this segfault.


I should add that I'm observing this when I'm using the mouse to click 
through slides - if I don't click and only use the keyboard things seem 
to work. This is different from what the original reporter saw.


--
Andrew Donnellan  OzLabs, ADL Canberra
andrew.donnel...@au1.ibm.com  IBM Australia Limited

Bug#908205: Downgrading ghostscript indeed fixes the problem

[Eric Valette]

Fixed after:

apt-get install ghostscript=9.22~dfsg-3 libgs9=9.22~dfsg-3 
libgs9-common=9.22~dfsg-3


So indeed a ghostscript bug

-- eric

Bug#855539: logwatch: Excessive unmatched entries in SSHD section of logwatch

[Paul Cochrane]

Hello,

it seems that these issues have been fixed in the upstream repository:

  - Disconnected from: 
https://sourceforge.net/p/logwatch/git/ci/f8aae45768d5ddf01e55b86afa9af90757530089/
  - Close session: 
https://sourceforge.net/p/logwatch/git/ci/6e8d4316275897f70dcfac824a789e480d1f65d4/

I've asked on the project discussion list if a release is forthcoming, so
perhaps a new release with these fixes will appear sometime.  However, in
the meantime, would it be an idea to integrate the above mentioned patches
into the current debian package?  That way users could profit from the
reduced noise in the logwatch output.

Kind regards,

Paul

Bug#908206: thunderbird: Can not open links due to AppArmour profile

[George B.]

Package: thunderbird
Version: 1:60.0-3
Severity: important

Hello,

I am unable to open any links in emails due to AppArmour profile.

```
Sep  7 11:39:38 glossy kernel: [   36.549148] audit: type=1400 
audit(1536316778.195:25): apparmor="DENIED" operation="file_mmap" 
profile="thunderbird" name="/tmp/.glJnadZk" pid=1862 comm="thunderbird" 
requested_mask="m" denied_mask="m" fsuid=1000 ouid=1000
Sep  7 11:39:38 glossy kernel: [   36.549150] audit: type=1400 
audit(1536316778.195:26): apparmor="DENIED" operation="file_mmap" 
profile="thunderbird" name="/tmp/.glJnadZk" pid=1862 comm="thunderbird" 
requested_mask="m" denied_mask="m" fsuid=1000 ouid=1000
Sep  7 11:39:38 glossy kernel: [   36.549152] audit: type=1400 
audit(1536316778.195:27): apparmor="DENIED" operation="mknod" 
profile="thunderbird" name="/home/borisov/.nv/.glAmX1Zf" pid=1862 
comm="thunderbird" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
Sep  7 11:39:39 glossy kernel: [   37.487371] audit: type=1400 
audit(1536316779.131:28): apparmor="DENIED" operation="open" 
profile="thunderbird" 
name="/home/borisov/.config/fcitx/dbus/92386e08ae0d45f3b92e68bdd67d6b91-0" 
pid=1845 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=1000
Sep  7 11:40:02 glossy kernel: [   60.931903] audit: type=1400 
audit(1536316802.115:29): apparmor="DENIED" operation="exec" 
profile="thunderbird" 
name="/usr/lib/x86_64-linux-gnu/glib-2.0/gio-launch-desktop" pid=2343 
comm="thunderbird" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
```

I think the last error is the one related to links, but I include the
others since they will probably have some other impact that I am not
aware of yet.


Thanks,

George

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

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

Versions of packages thunderbird depends on:
ii  debianutils   4.8.6
ii  fontconfig2.13.0-5
ii  libatk1.0-0   2.28.1-1
ii  libc6 2.27-6
ii  libcairo-gobject2 1.15.12-1
ii  libcairo2 1.15.12-1
ii  libdbus-1-3   1.12.10-1
ii  libdbus-glib-1-2  0.110-3
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-8
ii  libfontconfig12.13.0-5
ii  libfreetype6  2.8.1-2
ii  libgcc1   1:8.2.0-5
ii  libgdk-pixbuf2.0-02.36.12-2
ii  libglib2.0-0  2.58.0-2
ii  libgtk-3-03.24.0-1
ii  libgtk2.0-0   2.24.32-3
ii  libhunspell-1.6-0 1.6.2-1+b1
ii  libicu60  60.2-6
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.19-3
ii  libnss3   2:3.38-1
ii  libpango-1.0-01.42.4-3
ii  libpangocairo-1.0-0   1.42.4-3
ii  libpangoft2-1.0-0 1.42.4-3
ii  libsqlite3-0  3.24.0-1
ii  libstartup-notification0  0.12-5
ii  libstdc++68.2.0-5
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.6-1
ii  libx11-xcb1   2:1.6.6-1
ii  libxcb-shm0   1.13-3
ii  libxcb1   1.13-3
ii  libxext6  2:1.3.3-1+b2
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  psmisc23.1-1+b1
ii  x11-utils 7.7+4
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages thunderbird recommends:
ii  hunspell-en-gb [hunspell-dictionary]  1:6.1.0~rc2-2
ii  lightning 1:60.0-3

Versions of packages thunderbird suggests:
ii  apparmor  2.13-8
ii  fonts-lyx 2.3.0-2
ii  libgssapi-krb5-2  1.16-2

-- debconf-show failed

Bug#892989: closed by Michael Biebl (Re: Bug#892989: weird chars found in dpkg output)

[Harald Dunkel]

I think you misunderstood the problem. This is not about
using UTF-8, but about producing binary log files, refused
by tools like less and others.

Writing the log file you don't know the locale used when it
is read, so the

"if locale == xxx"

is bad code. I am forced to *avoid* UTF-8 as a default to
make sure that there are no weird side effects later.

Just to replace "->"?


Harri

Bug#908207: [jack-mixer] New URL

[Michael Jarosch]

Package: jack-mixer
Version: 10-1+b1
Severity: normal

--- Please enter the report below this line. ---
Dear maintainers,

I saw that the old gno.org-URL of jack-mixer has been abandoned. I
found a github project that should be the new home for this project:

https://github.com/relascope/jack_mixer

Hope that helps!
Greets!
Mitsch
--- System information. ---
Architecture: 
Kernel:   Linux 4.17.0-1-amd64

Debian Release: buster/sid
  500 testing httpredir.debian.org 

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.




signature.asc
Description: This is a digitally signed message part

Bug#908208: ITP: node-topo -- Topological sorting with grouping support

[Bastien ROUCARIES]

Package: wnpp
Severity: wishlist
Owner: ro...@debian.org
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-topo
  Version : 3.0.0
  Upstream Author : [Devin Ivy](https://github.com/devinivy)
* URL : https://github.com/hapijs/topo#readme
* License : BSD-3-Clause
  Programming Lang: JavaScript
  Description : Topological sorting with grouping support
 This package allows one to create containers for topologically
sorting a list of nodes withnon-circular interdependencies.
.
In the field of computer science, a topological sort or topological
ordering of a directed graph is a linear ordering of its vertices such
that for every directed edge uv from vertex u to vertex v, u comes
before v in the ordering.
 .
 Node.js is an event-based server-side JavaScript engine.

Bug#901302: Crash on monitor rotation

[Luc Deschenaux]

Same problem I guess on my Thinkpad X220 upgraded from stretch to buster
(testing):

When I try to rotate a monitor in "Displays" (tried several ones), the
mouse is freezing, the fan is racing (infinite loop ? :-) ) and I must
reboot.

Maybe related to https://gitlab.gnome.org/GNOME/mutter/issues/216

Kind regards,

Luc

PS:

Sep  7 16:59:26 x220 org.gnome.SettingsDaemon.MediaKeys.desktop[13972]: 
[2019:2019:0907/165926.201824:ERROR:gl_surface_presentation_helper.cc(115)] 
GetVSyncParametersIfAvailable() failed!
Sep  7 16:59:26 x220 org.gnome.SettingsDaemon.MediaKeys.desktop[13972]: 
[2019:2019:0907/165926.203076:ERROR:gl_surface_presentation_helper.cc(115)] 
GetVSyncParametersIfAvailable() failed!
Sep  7 16:59:26 x220 org.gnome.SettingsDaemon.MediaKeys.desktop[13972]: 
[2019:2019:0907/165926.207092:ERROR:gl_surface_presentation_helper.cc(115)] 
GetVSyncParametersIfAvailable() failed!
Sep  7 16:59:26 x220 org.gnome.SettingsDaemon.MediaKeys.desktop[13972]: 
[2019:2019:0907/165926.220308:ERROR:gl_surface_presentation_helper.cc(115)] 
GetVSyncParametersIfAvailable() failed!
Sep  7 16:59:26 x220 org.gnome.SettingsDaemon.MediaKeys.desktop[13972]: 
[2019:2019:0907/165926.224835:ERROR:gl_surface_presentation_helper.cc(115)] 
GetVSyncParametersIfAvailable() failed!
Sep  7 16:59:26 x220 org.gnome.SettingsDaemon.MediaKeys.desktop[13972]: 
[2019:2019:0907/165926.226449:ERROR:gl_surface_presentation_helper.cc(115)] 
GetVSyncParametersIfAvailable() failed!
Sep  7 16:59:26 x220 org.gnome.SettingsDaemon.MediaKeys.desktop[13972]: 
[2019:2019:0907/165926.228240:ERROR:gl_surface_presentation_helper.cc(115)] 
GetVSyncParametersIfAvailable() failed!
Sep  7 16:59:26 x220 org.gnome.SettingsDaemon.MediaKeys.desktop[13972]: 
[2019:2019:0907/165926.230209:ERROR:gl_surface_presentation_helper.cc(115)] 
GetVSyncParametersIfAvailable() failed!
Sep  7 16:59:26 x220 gnome-shell[13822]: Object St.Icon (0x55b531070d10), has 
been already finalized. Impossible to set any property to it.
Sep  7 16:59:26 x220 gnome-shell[13822]: Object St.BoxLayout (0x55b53106fc50), 
has been already finalized. Impossible to set any property to it.
Sep  7 16:59:26 x220 org.gnome.Shell.desktop[13822]: == Stack trace for context 
0x55b530b3b320 ==
Sep  7 16:59:26 x220 org.gnome.Shell.desktop[13822]: #0 0x55b530ee3848 i   
resource:///org/gnome/shell/ui/osdWindow.js:206 (0x7f562bbc7450 @ 231)
Sep  7 16:59:26 x220 org.gnome.Shell.desktop[13822]: #1 0x7ffc7592f200 b   
resource:///org/gnome/gjs/modules/_legacy.js:82 (0x7f562beb5de0 @ 71)
Sep  7 16:59:26 x220 org.gnome.Shell.desktop[13822]: #2 0x7ffc7592f2c0 b   
self-hosted:916 (0x7f562bef1230 @ 367)
Sep  7 16:59:26 x220 org.gnome.Shell.desktop[13822]: #3 0x7ffc7592f3b0 b   
resource:///org/gnome/gjs/modules/signals.js:128 (0x7f562bed2230 @ 386)
Sep  7 16:59:26 x220 org.gnome.Shell.desktop[13822]: #4 0x55b530ee37c0 i   
resource:///org/gnome/shell/ui/layout.js:523 (0x7f562bb04230 @ 127)
Sep  7 16:59:26 x220 org.gnome.Shell.desktop[13822]: #5 0x7ffc759306f0 b   
resource:///org/gnome/gjs/modules/_legacy.js:82 (0x7f562beb5de0 @ 71)
Sep  7 16:59:26 x220 org.gnome.Shell.desktop[13822]: #6 0x7ffc75930ee0 b   
self-hosted:916 (0x7f562bef1230 @ 367)
Sep  7 16:59:26 x220 org.gnome.Shell.desktop[13822]: == Stack trace for context 
0x55b530b3b320 ==
Sep  7 16:59:26 x220 org.gnome.Shell.desktop[13822]: #0 0x55b530ee3848 i   
resource:///org/gnome/shell/ui/osdWindow.js:207 (0x7f562bbc7450 @ 273)
Sep  7 16:59:26 x220 org.gnome.Shell.desktop[13822]: #1 0x7ffc7592f200 b   
resource:///org/gnome/gjs/modules/_legacy.js:82 (0x7f562beb5de0 @ 71)
Sep  7 16:59:26 x220 org.gnome.Shell.desktop[13822]: #2 0x7ffc7592f2c0 b   
self-hosted:916 (0x7f562bef1230 @ 367)
Sep  7 16:59:26 x220 org.gnome.Shell.desktop[13822]: #3 0x7ffc7592f3b0 b   
resource:///org/gnome/gjs/modules/signals.js:128 (0x7f562bed2230 @ 386)
Sep  7 16:59:26 x220 org.gnome.Shell.desktop[13822]: #4 0x55b530ee37c0 i   
resource:///org/gnome/shell/ui/layout.js:523 (0x7f562bb04230 @ 127)
Sep  7 16:59:26 x220 org.gnome.Shell.desktop[13822]: #5 0x7ffc759306f0 b   
resource:///org/gnome/gjs/modules/_legacy.js:82 (0x7f562beb5de0 @ 71)
Sep  7 16:59:26 x220 org.gnome.Shell.desktop[13822]: #6 0x7ffc75930ee0 b   
self-hosted:916 (0x7f562bef1230 @ 367)
Sep  7 16:59:26 x220 gnome-shell[13822]: Object St.Icon (0x55b53404c090), has 
been already finalized. Impossible to set any property to it.
Sep  7 16:59:26 x220 gnome-shell[13822]: Object St.BoxLayout (0x55b5343a8310), 
has been already finalized. Impossible to set any property to it.
Sep  7 16:59:26 x220 org.gnome.Shell.desktop[13822]: == Stack trace for context 
0x55b530b3b320 ==
Sep  7 16:59:26 x220 org.gnome.Shell.desktop[13822]: #0 0x55b530ee3848 i   
resource:///org/gnome/shell/ui/osdWindow.js:206 (0x7f562bbc7450 @ 231)
Sep  7 16:59:26 x220 org.gnome.Shell.desktop[13822]: #1 0x7ffc7592f200 b   
resource:///org/gnome/gjs/modules/_legacy.js:82 (0x7f562beb5de0 @ 71)
Sep  7 16:59:26 x220 org.gnome.Shell.desktop[13822]: #2 0x7ffc759

Bug#907704: choose-mirror: default to deb.debian.org

[Wouter Verhelst]

On Wed, Sep 05, 2018 at 02:58:17PM +0200, Philipp Kern wrote:
> On 2018-09-05 12:35, Wouter Verhelst wrote:
[...]
> > I disagree with that, but I do also agree that it would be preferable if
> > local proxies or mirrors were used preferably.
> > 
> > However, this shouldn't be done by way of manual configuration; instead,
> > I think it should be done by way of autodetection performed by apt,
> > something not unlike the proxy-PAC scheme, where a browser looks for
> > pac., with the  part being what was passed to it by
> > DHCP, incrementally dropping off the leaf-most part of that until it
> > resolves.
> > 
> > I think such a scheme could work for apt too.
> 
> Arguably the correct way would be to fetch the PAC and execute it to
> determine the proxy for the host. Of course that'd require interpreting
> Javascript.

Not what I meant (but I certainly could've been clearer).

Autodetecting a proxy using the WPAD scheme is complicated, and I agree
that adding a Javascript interpreter to apt just so we can figure out
where a proxy can be found is probably way overkill. It might be nice,
but I don't think we should do it.

However, it would be nice if a network administrator could somehow
suggest a closeby *mirror*. That's why I said "something not unlike" in
the above quote. Since this'd be something we'd be creating ourselves,
we can decide that no scripting language would be necessary, but instead
just a simple configuration file that says "if you're looking for a
mirror for something of which the Release file has fields matching
, please go to ".

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#908209: colord FTBFS: cannot touch 'debian/stamps/generate_meson_build_system': No such file or directory

[Adrian Bunk]

Source: colord
Version: 1.4.3-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=colord

...
   debian/rules override_dh_auto_configure-indep
make[1]: Entering directory '/<>'
touch debian/stamps/generate_meson_build_system
touch: cannot touch 'debian/stamps/generate_meson_build_system': No such file 
or directory
make[1]: *** [debian/rules:44: debian/stamps/generate_meson_build_system] Error 
1

Bug#908210: arc-theme FTBFS with gtk+3.0 3.24

[Adrian Bunk]

Source: arc-theme
Version: 20180114-1
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/arc-theme.html

...
checking pkg-config is at least version 0.9.0... yes
configure: error: Invalid GNOME version: 3.24


In a related note, when the package is that dependeny
on the specific GTK+ version used it might also require
stricter runtime dependencies.

Bug#908211: pvpgn: PvPGN refuse to start

[Shildark]

Package: pvpgn
Version: 1.8.5-2.1
Severity: important

Dear Maintainer, hello,

I’m trying to install pvpgn 1.8.5 on Debian.

After “apt-get install pvpgn”, I’m stuck with :

# service pvpgn start
You are missing the pvpgn support files and daemon will not start
without them.
Run 'sudo pvpgn-support-installer' or read /usr/share/doc/pvpgn/README.Debian

Except that download.berlios.de doesn’t exist anymore.

I find a way to get some of these files on:
https://github.com/pvpgn/pvpgn-server/issues/363

After “git clone https://github.com/pvpgn/pvpgn-server”, I move the
files missing in /var/lib/pvpgn/files and try to start pvpgn: still the
same issue.

I try with the files/ repertory in:
wget https://github.com/pvpgn/pvpgn-server/archive/master.tar.gz

Inspecting /usr/share/doc/pvpgn/README.Debian, I notice the script
pvpgn-support-installer mentions 3 files which are not in
https://github.com/pvpgn/pvpgn-server/tree/master/files :
matchmaking-war3-default.dat, matchmaking-war3-enUS.dat and WAR3IX86.mpq

I have no ideas where I can find those files.

Or maybe pvpgn refuse to start for another reason. Is there something else
I missed?

Thanks.

-- System Information:
Debian Release: 9.5
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'oldstable')
Architecture: i386 (i686)

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

Versions of packages pvpgn depends on:
ii  libc6   2.24-11+deb9u3
ii  libcdb1 0.78+b1
ii  libmariadbclient18  10.1.26-0+deb9u1
ii  libpq5  9.6.10-0+deb9u1
ii  libsqlite3-03.16.2-5+deb9u1
ii  zlib1g  1:1.2.8.dfsg-5

Versions of packages pvpgn recommends:
pn  tinycdb  

Versions of packages pvpgn suggests:
pn  default-mysql-server | virtual-mysql-server  
pn  fortune  

-- no debconf information

Bug#908212: node-unicode-11.0.0: Package description mentions Unicode 10

[Jeremy Bicha]

Package: node-unicode-11.0.0
Version: 0~20180730+gitca26ee35-1

The short package description for node-unicode-11.0.0 claims to be for
Unicode 10.

https://salsa.debian.org/js-team/node-unicode-data/blob/master/debian/control#L27

Thanks,
Jeremy Bicha

Bug#908155: Coordination with upstream developers not universally applied

[Wouter Verhelst]

On Thu, Sep 06, 2018 at 09:05:04PM +0200, Moritz Muehlenhoff wrote:
> Source: developers-reference
> Severity: normal
> 
> "3.1.4. Coordination with upstream developers" says
> 
> "You have to forward these bug reports to the upstream developers so that they
> can be fixed in a future upstream release."
> 
> That's not the current/best practice for a number of packages, either because
> of the sheer volume of bug reports/size of the package or because some of the
> bugs are very specific to the reporters setup and having the Debian maintainer
> as a middle person forwarding information back and forth would be useless
> (e.g. for the Linux kernel where a lot of bug reports are hardware-specific).
> 
> The current formulation will cause false expections for end users.
> 
> Maybe alternatively make this
> 
> "You can either forward these bug reports to the upstream developers yourself
> or ask the reporter to report them upstream, so that they can be fixed in a
> future upstream release."

I would like something stronger.

To me, the core message of the current text is that you should ensure
that bug reports which are not Debian-specific end up with upstream,
*somehow*, whether by the maintainers forwarding it to upstream
themselves or by them asking the reporter to do so. Your proposed new
text weakens that, and I think that's not a good idea.

I agree that it's perfectly fine for a maintainer to say "this is an
upstream bug, please report it upstream", which the current text doesn't
allow for. Having said that, I *don't* think it's fine for a maintainer
to say "never ever report upstream bugs for this package to Debian"; for
someone not familiar with the software in question, determining whether
something is a Debian-specific bug or an upstream one is not always
possible.

While we're at it, I think we should also point out that if upstream
uses an issue tracker that is supported by bts-link, it might be nice to
keep upstream bug reports that were filed in the Debian bts open, but
mark them as forwarded to the correct URL so that bts-link will tag them
"fixed-upstream" when relevant. That should probably not be a
requirement though.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab


signature.asc
Description: PGP signature

Bug#908213: node-regjsparser: Build against node-unicode-11.0.0

[Jeremy Bicha]

Source: node-regjsparser
Version: 0.4.0+ds-1
Severity: serious
Tags: ftbfs

node-regjsparaser build-depend on node-unicode-10.0.0 but that package
is no longer built from source. Please build against
node-unicode-11.0.0 instead.

Thanks,
Jeremy Bicha

Bug#901474: Forwarded

[Bastien ROUCARIES]

control: forwarded -1 https://github.com/nodejs/node/issues/22745

Bug#908214: debdiff: please color wdiff of binary comparison

[Adam Borowski]

Package: devscripts
Version: 2.18.4
Severity: wishlist

Hi!
Binary debdiff supports -wt which makes wdiff output slightly more
readable, but it's not enough: during a bright day when you're distracted
undercaffeinated and have a headache, it's possible to stare at the
output for minutes without noticing something obvious.

Any other modern program uses color for diffs, thus why not do this here?
The wdiff program doesn't provide a baked-in setting to do this with one
switch, but its documentation suggests the following:

wdiff -n \
  -w $'\033[30;41m' -x $'\033[0m' \
  -y $'\033[30;42m' -z $'\033[0m' \

You could wrap this in a new option such as "--wc".


Note that this is for binary debdiff; for source there's #809854 which
I wholeheartly support.


Meow!
-- Package-specific info:

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

--- ~/.devscripts ---
DEBCHANGE_RELEASE_HEURISTIC=log
DEBSIGN_KEYID=FD9CE2D8D7754B78AB279BBD2C3B436FEAC68101
DSCVERIFY_KEYRINGS="~/.gnupg/pubring.gpg"

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

Kernel: Linux 4.18.5+ (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.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.5
ii  libc6 2.27-6
ii  libfile-homedir-perl  1.004-1
ii  perl  5.26.2-7
ii  python3   3.6.6-1
ii  sensible-utils0.0.12

Versions of packages devscripts recommends:
ii  apt 1.6.4
pn  at  
ii  curl7.61.0-1
ii  dctrl-tools 2.24-2+b1
ii  debian-keyring  2018.07.24
ii  dput-ng [dput]  1.21
ii  dupload 2.9.2
ii  equivs  2.1.0
ii  fakeroot1.23-1
ii  file1:5.34-2
ii  gnupg   2.2.10-1
ii  libdistro-info-perl 0.18
ii  libdpkg-perl1.19.0.5
ii  libencode-locale-perl   1.05-1
pn  libgit-wrapper-perl 
pn  liblist-compare-perl
ii  liblwp-protocol-https-perl  6.07-2
pn  libsoap-lite-perl   
pn  libstring-shellquote-perl   
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.74-1
ii  libwww-perl 6.35-2
ii  licensecheck3.0.31-2
ii  lintian 2.5.100
ii  man-db  2.8.4-2
ii  patch   2.7.6-3
ii  patchutils  0.3.4-2
ii  python3-apt 1.6.2
ii  python3-debian  0.1.33
ii  python3-magic   2:0.4.15-2
ii  python3-requests2.18.4-2
ii  python3-unidiff 0.5.4-1
ii  python3-xdg 0.25-4
ii  strace  4.21-1
ii  unzip   6.0-21
ii  wdiff   1.2.2-2+b1
ii  wget1.19.5-1
ii  xz-utils5.2.2-1.3

Versions of packages devscripts suggests:
ii  adequate  0.15.1
ii  autopkgtest   5.5
pn  bls-standalone
ii  bsd-mailx [mailx] 8.1.2-0.20180807cvs-1
ii  build-essential   12.5
pn  check-all-the-things  
pn  cvs-buildpackage  
pn  devscripts-el 
pn  diffoscope
pn  disorderfs
ii  dose-extra5.0.1-11+b1
pn  duck  
pn  faketime  
pn  gnuplot   
ii  gpgv  2.2.10-1
pn  how-can-i-help
ii  libauthen-sasl-perl   2.1600-1
ii  libdbd-pg-perl3.7.4-1
ii  libfile-desktopentry-perl 0.22-1
pn  libnet-smtps-perl 
ii  libterm-size-perl 0.209-1
ii  libtimedate-perl  2.3000-2
pn  libyaml-syck-perl 
pn  mozilla-devscripts
pn  mutt  
ii  openssh-client [ssh-client]   1:7.8p1-1
ii  piuparts  0.90
ii  postgresql-client 10+193
ii  postgresql-client-10 [postgresql-client]  10.5-1
ii  quilt 0.65-2
pn  ratt  
pn  reprotest 
pn  svn-buildpackage  
pn  w3m   

-- no debconf information

Bug#908215: ITP: lagan -- highly parametrizable pairwise global genome sequence aligner

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: lagan
* URL : http://lagan.stanford.edu/lagan_web/index.shtml
* License : GPL
  Programming Lang: C++
  Description : highly parametrizable pairwise global genome sequence 
aligner

The package is team maintained on salsa.d.o/med-team/lagan.

Bug#908095: Buster: Kwrite crashes while opening a file

[Martin Steigerwald]

tag 908095 upstream
thanks

local10 - 07.09.18, 12:15:
> Was able to open the problematic file by reconfiguring Kwrite and
> changing the default encoding to UTF-8 and the fallback encoding to
> UTF-16 (Kwrite keeps changing UTF-16 to ucs2 but whatever).
> 
> That's a good news for me, of course, but still I feel Kwrite
> shouldn't crash like that even if the default and fallback encoding
> do not match the file's encoding. In Wheezy I sometimes would open a
> binary file with Kwrite and I don't even remember when Kwrite crashed
> like that, if it ever did.

This is an upstream issue.

Please report with https://bugs.kde.org if not already done so and 
report the link to this bug report. By doing so you help our small 
Debian Qt/KDE team a lot. Bugs to Debian are not automatically forwarded 
to the upstream bug tracker.

Before doing so please retest with Kate 18.08 which is available in 
Buster meanwhile.

Actually, for smaller upstream issues I think its better to just report 
upstream. If there is an upstream patch depending on the severity of the 
issue and on planned release date of next Debian stable release, it can 
make sense to open a Debian bug report asking to include it.

Thanks,
-- 
Martin

Bug#876772: RFA: dosbox -- x86 emulator with Tandy/Herc/CGA/EGA/VGA/SVGA graphics, sound and DOS

[Stephen Kitt]

Control: retitle -1 ITA: dosbox -- x86 emulator with 
Tandy/Herc/CGA/EGA/VGA/SVGA graphics, sound and DOS
Control: owner -1 !

Hi Jan,

On Mon, Sep 25, 2017 at 07:38:18PM +0200, Jan Dittberner wrote:
> I request an adopter for the dosbox package.

I’ll adopt it, I use it regularly. I’ll upload a package of 0.74-2
soon.

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#908120: gnome-terminal: Cursor disappears when changing or moving window

[Ron Lovell]

Yeah, me too. Issue appeared evening of 05 Sep 2018 in Sid after a number
of possibly relevant updates:
GLib 2.58.0-2
GTK 3.24.0
GNOME Shell 3.30
Wayland libs 1.16.0
Mutter 3.30

-- 
James Ronald Lovell 
Huntsville, AL, USA

Bug#904699: W: parser_rfc822: Iek! Don't find end of value!

[Marc Kleine-Budde]

Hello,

using buster I just ran into the same problem. Will the READSIZE be
increased or can't we cdebootstrap until the rust problem is sorted out?

regards,
Marc



signature.asc
Description: OpenPGP digital signature

Bug#907704: choose-mirror: default to deb.debian.org

[Julien Cristau]

Control: retitle -1 choose-mirror: hide mirror selection by default

On 09/04/2018 11:07 AM, Julien Cristau wrote:
> If switching the mirror question from high to medium priority proves
> controversial I guess I could separate that to its own bug too, to at
> least get the default changed.
> 
Since there still seems to be some discussion around that, I'm going to
use bug#797340 to make deb.debian.org the default, and repurpose this
bug to stop asking the mirror country + hostname questions by default.

Cheers,
Julien

Bug#907829: p4est: FTBFS on single CPU machines (?)

[Santiago Vila]

On Fri, Sep 07, 2018 at 10:46:36AM +0300, Adrian Bunk wrote:
> On Thu, Sep 06, 2018 at 10:46:07PM +0200, Santiago Vila wrote:
>
> > You will have noticed that we usually report FTBFS bugs when a package
> > fails to build in any "correctly" configured autobuilder, we don't wait
> > for the build failure to happen on buildd.debian.org.
> >...
> 
> No release architectures has a single-core autobuilder at buildd.debian.org.
> 
> And it is completely out of the discussion that any would in the future.

I was trying to argue that the official autobuilders are not, and
should not be, the only measure by which we consider a bug to be
serious or not.

And I put a very simple example: Imagine that all our amd64
autobuilders are Intel and there is a package which FTBFS on AMD.

Are you really trying to tell me that the FTBFS bug would not be
serious "because it does not happen on buildd.debian.org"?

I would like to believe that you would say "baseline violation",
since that's what you said (and I fully agree) here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906697

Now you could maybe argue that using a package and building it are
"different" things.

And they are in fact different things: Being able to build a package
is actually *more* important than being able to use it, because
building is a *precondition* for use. If I try to build a package and
it fails, there is no package to use. This is the very reason why we
consider a FTBFS to be serious. The package is completely unsuitable
for release. It prevents the package from working at all because there
is no package to use at all.

Now the question: Do you want to deprecate using Debian on
single-core, or only building Debian on single-core?

> > But that's only the best case scenario. The worst case scenario is
> > that you build all packages using 2 CPU but only a proportion of them
> > support (and benefit from) parallel build. For those who don't we are
> > wasting completely the extra CPU.
> > 
> > So no, it's not cheaper in general, and it may be even more expensive.
> 
> Which cloud provider are you using?

I have actually used many of them. The most popular ones like vultr,
digital ocean or linode offer all-in-one packages in which more CPUs
means more RAM and of course more money, usually in powers of two.

For example, if we compare the most expensive single-CPU with the
cheapest multi-CPU on Vultr, that means going from $10/month to
$20/month:

https://www.vultr.com/pricing/

This is double the price for something which may or may not take
half the time (depending on the package).

So yes, I already did the math and definitely building on several CPUs
is not cheaper.

On GCE you can pay for CPUs and RAM independently, but CPUs are
generally more expensive than RAM:

https://cloud.google.com/compute/pricing

(The disk here is very cheap: $0.04 by GB-month).

Why are we discussing about the price, anyway?

Are you trying to discriminate against people who build on single-cpu
because they are rich, because they are poor, because in your opinion
they don't use their resources efficiently, because of what?

Thanks.

Bug#907900: hplip: Printing is not possible b/c of missing foomatic-rip-hplip filter

[Brian Potkin]

On Tue 04 Sep 2018 at 21:39:28 +0200, Till Kamppeter wrote:

> On 04/09/18 21:20, Dimitri Chausson wrote:
> > Hello Brian,
> > 
> > thanks for your quick reply, following are the results:
> > 
> > $>   grep -i cupsfilter /etc/cups/ppd/HP_DeskJet_3630_series.ppd
> > *cupsFilter: "application/vnd.cups-postscript 100 foomatic-rip-hplip"
> > *cupsFilter: "application/vnd.cups-pdf 0 foomatic-rip-hplip"
> > 
> 
> AFAIK there is no package providing a foomatic-rip-hplip in Debian or
> Ubuntu. Probably your PPD comes from an older version of HPLIP installed
> from the original source (not as Debian package).
> 
> So removing and re-creating your print queue probably gives you an
> up-to-date PPD file which does not use foomatic-rip-hplip, but, instead, the
> hpcups filter of HPLIP.

On a sid machine with only printer-driver-hpijs and hplip-data:

 brian@desktop3:~$ /usr/lib/cups/driver/hplip-data cat 
hplip-data:0/ppd/hplip/HP/hp-psc_1300_series-hpijs.ppd | grep cupsFilter
 *cupsFilter: "application/vnd.cups-postscript 100 foomatic-rip-hplip"
 *cupsFilter: "application/vnd.cups-pdf 0 foomatic-rip-hplip"/

jessie gives foomatic-rip in the lines.

Regards,

Brian.

Bug#908146: libreoffice-dictionaries: Dealing with Breaks/Replaces against ancient dicts in other myspell/hunspell packages.

[Mattia Rizzolo]

On Fri, Sep 07, 2018 at 11:15:34AM +0200, Agustin Martin wrote:
> > Note that if you also look for a home to keep those transitional
> > packages, we can also build them within lo-dicts (we would drop them
> > after buster, which also means after ubuntu 18.04, so everything's
> > great).

Well, of couse yesterday I was drunk and messed up the timing.  Of
course for ubuntu we would be looking at 20.04 at this point, well after
the buster release.  But I trust future me to not mess that up :)

> > But from what I can see the source packages you mentions in this bug
> > report are building something else anyway, so I guess they can also keep
> > building those transitional packages.
> 
> Thanks for the info, I did not find the relevant part in helper.py.

Maybe because those are handled more "manually" in control.in :)

> There is one package (hunspell-sv) where that is desirable, since it will
> only contain transitional packages hunspell-sv-se and myspell-sv-se, so
> I think it is better if hunspell-sv-se transitional package is created
> from lo-dicts itself.
> 
> Regarding myspell-sv-se transitional package, it was created back in 2011,
> so I think is safe not to worry anymore about it.

I took over both, as myspell-sv-se seems to have several reverse
dependencies still around, maybe you could look at that and file bugs?

> I will ask for old hunspell-sv removal afterwards,

so no need anymore, it will be marked as obsolete source and be removed
as cruft.

> Apart from the above, I think nothing else is needed.

Alright, I added transitional packages for myspell-sv-se and
hunspell-sv-se, tweaked the versioning of Breaks/Conflicts and uploaded
:)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#908155: Coordination with upstream developers not universally applied

[Thorsten Glaser]

Hello Moritz,

> On Thu, Sep 06, 2018 at 11:29:52PM +0200, Thorsten Glaser wrote:
> > I’m trying to be constructive here, but in the end, I still
> > think that this was something package maintainers (at least
> > DDs) have read beforehand and signed up for, so there’s no
> > room to complain now,
> 
> Good. Please subscribe to the PTS, I take that as an offer
> by you to take care of forwarding Debian kernel bugs to upstream.

you seem to be deliberately misunderstanding me.

I’m not a maintainer of the Debian Linux kernel. I exhibit
a few of the things I mentioned, such as, not being know‐
ledgeable enough about the stuff. In this instance, I’m the
user / bug reporter.

Not “all DDs must forward bugs about *all* packages to *all*
upstreams”, but “package maintainers must forward bugs about
*their* packages (and perhaps others, if interested and capable)
to those upstreams”.

I try to do so for my packages and a couple others (I’d even
be more involved in klibc if upstream and maks weren’t such
a wall of silence).

bye,
//mirabilos
-- 
>> Why don't you use JavaScript? I also don't like enabling JavaScript in
> Because I use lynx as browser.
+1
-- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel

Bug#908065: BTS seems to send bugs to old maintainer of a package but displays new one correctly (Was: Bug#908065: r-cran-adegraphics: autopkgtest regression: dependency versions not properly specifie

[Mattia Rizzolo]

On Fri, Sep 07, 2018 at 09:50:28AM +0200, Andreas Tille wrote:
> On Thu, Sep 06, 2018 at 10:31:34PM +0200, Paul Gevers wrote:
> > 
> > > BTW, do you have any idea why that bug is filed against Debian Med
> > > packaging list[1] while the maintainer of the package is
> > > r-pkg-t...@alioth-lists.debian.net?
> > 
> > tracker.d.o?
> 
> Hmmm, why should tracker.d.o keep a record where a package was
> maintained *before* instead of just taking the Maintainer field of the
> current package?  At least the *rendered* information of tracker.d.o[1]
> mentions Debian R Packages Maintainers.

Well, this has nothing at all (really) with tracker.d.o, nor with the QA
team alas.

> Any idea why BTS sends the e-mail to the maintainer that is mentioned
> for instance in the package in stable rather than the one in unstable
> (which is correctly parsed obviously)?

FTR, looking at #908065 I can read:

|Report forwarded to debian-bugs-dist@lists.debian.org, 
debian...@lists.debian.org, Debian Med Packaging Team 
:
|Bug#908065; Package src:r-cran-adegraphics. (Wed, 05 Sep 2018 18:42:04 GMT)

no idea why, given that the page header mentions the r-pkg-team@ alioth
address.

I suggest you ask ow...@bugs.debian.org and/or file a bug against the
bugs.debian.org pseudo-package, as that's where the bugs.d.o maintainer
answer.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#908217: git-buildpackage: fails to identify compression method when pristine-tar branch is only in the remote repository

[Raphaël Hertzog]

Package: git-buildpackage
Version: 0.9.10
Severity: normal
User: de...@kali.org
Usertags: origin-kali

I'm often sponsoring packages and I usually use "git clone" (and not "gbp
clone") so that I only have the "master" or "debian/master" branch in my
local repository, however the "upstream" and "pristine-tar" branches are
in the remote repository ("origin").

pristine-tar copes just fine with this and fallsback to use the data from
origin/pristine-tar but if the compression method is not the usual gzip, gbp
buildpackage will fail. I have to tell it "--git-compresionn=xz" to make
the call succeed. It would be nice if the code that looks up the compression
method in the pristine-tar branch was smart enough to also fall back
to looking into origin/pristine-tar.

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

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

Versions of packages git-buildpackage depends on:
ii  devscripts 2.18.4
ii  git1:2.19.0~rc2-1
ii  man-db 2.8.4-2
ii  python33.6.6-1
ii  python3-dateutil   2.7.3-1
ii  python3-pkg-resources  40.2.0-1
ii  sensible-utils 0.0.12

Versions of packages git-buildpackage recommends:
ii  pristine-tar  1.44
ii  python3-requests  2.18.4-2
ii  sbuild0.77.0-4

Versions of packages git-buildpackage suggests:
ii  python3-notify2  0.3-3
ii  sudo 1.8.23-2
ii  unzip6.0-21

-- no debconf information

Bug#908155: Coordination with upstream developers not universally applied

[Thorsten Glaser]

Hi Wouter,

> I agree that it's perfectly fine for a maintainer to say "this is an
> upstream bug, please report it upstream", which the current text
> doesn't allow for.

In theory, I could agree to that, were it not for a number of
points I outlined earlier:

• the variety of upstream bug trackers and having to register
  an account with each of them

• the problems dealing with upstream reactions (questions,
  patches, etc.) especially for less technical users (or
  merely these not knowledgeable about that particular
  package’s internals)

• the lack of familiarity between upstream and distro end user

Now that I write it again, there’s another point:

• the package maintainers not being involved in the discussion
  (dangerous if e.g. upstream suggests a fix that won’t work
  in the distro for some reason, and the end user not knowing
  about that, and them agreeing to that fix)

I’m still convinced that package maintainers should at least
forward patches from end users and keep an eye on them, and
that, if/when it’s okay to ask the end user to report upstream
themselves, they help whenever needed and perhaps also keep an
eye on the upstream bugs.

bye,
//mirabilos
-- 
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...

Bug#908155: Coordination with upstream developers not universally applied

[Ian Jackson]

Thorsten Glaser writes ("Bug#908155: Coordination with upstream developers not 
universally applied"):
> On Thu, 6 Sep 2018, Moritz Muehlenhoff wrote:
> > That's not the current/best practice for a number of packages,
> > either because of the sheer volume of bug reports/size of the
> > package or because some of the bugs are very specific to the
> > reporters setup and having the Debian maintainer as a middle
> > person forwarding information back and forth would be useless
> > (e.g. for the Linux kernel where a lot of bug reports are
> > hardware-specific).
> 
> I respectfully disagree.

I think it is usually better if the Debian maintainer can do this.
I would like to encourage maintainers do do it.  But I really don't
think we can make this mandatory.

Ian.

Bug#908155: Coordination with upstream developers not universally applied

[Ian Jackson]

Wouter Verhelst writes ("Bug#908155: Coordination with upstream developers not 
universally applied"):
> To me, the core message of the current text is that you should ensure
> that bug reports which are not Debian-specific end up with upstream,
> *somehow*, whether by the maintainers forwarding it to upstream
> themselves or by them asking the reporter to do so. Your proposed new
> text weakens that, and I think that's not a good idea.

How about this

   These bug reports should be forwarded to the upstream developers so
   that they can be fixed in a future upstream release.  Usually it is
   best if you can do this, but alternatively, you may ask the bug
   submitter to do it.

?

Ian.

Bug#908155: Coordination with upstream developers not universally applied

[Ian Jackson]

Thorsten Glaser writes ("Re: Bug#908155: Coordination with upstream developers 
not universally applied"):
> Now that I write it again, there\u2019s another point:
> 
> \u2022 the package maintainers not being involved in the discussion
>   (dangerous if e.g. upstream suggests a fix that won\u2019t work
>   in the distro for some reason, and the end user not knowing
>   about that, and them agreeing to that fix)
> 
> I\u2019m still convinced that package maintainers should at least
> forward patches from end users and keep an eye on them, and
> that, if/when it\u2019s okay to ask the end user to report upstream
> themselves, they help whenever needed and perhaps also keep an
> eye on the upstream bugs.

It's all very well to say that package maintainers "should" do
something.  Package maintainers "should" fix all bugs in their
packages.

But we have limited effort.  It is better to have a package in Debian,
but where users have to do some more of the work, than no package.

Or to put it another way: if you see something that "should" be done,
but which is not being done, why are you not volunteering to do it ?
Or are you saying that maintainers should step down and orphan the
package instead ?

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#907192: need help on the very last blocker (Re: RFS: tensorflow/1.10.0+dfsg-A1 [ITP]

[Mo Zhou]

Hi mentors,

Does anyone have idea about the following very last blocker for libtensorflow?
We are really ready to upload TF once the C API unit tests passed without fatal 
error.

procedure to reproduce::

  1. download libtensorflow-cc1.10 and libtensorflow-dev from
 debomatic-amd64 and install. (with version >= ...-A1u35). -A1u38 is 
preferred
 but it just started to build at time of writing.

 
http://debomatic-amd64.debian.net/distribution#experimental/tensorflow/1.10.1+dfsg-A1u35/buildlog
 
http://debomatic-amd64.debian.net/distribution#experimental/tensorflow/1.10.1+dfsg-A1u38/buildlog

 Or just build it from the git repo if you like. (demomatic-amd64's
 CPU is E5-2699v3 and TF takes ~30 mins for dom-amd64 to build.)

  2. clone the git repo and checkout to master (the very latest commit).

 https://salsa.debian.org/science-team/tensorflow

  3. install B-D from experimental and prepare the environment 

 # apt build-dep .
 $ ./debian/devh pre

  4. run the unit test for C API

 $ sh debian/tests/tf_c_api_test.sh

 And you will see the attached failure log.
 I asked for help here https://github.com/tensorflow/tensorflow/issues/22116
 but still not reply.
 
::

~/p/t/tensorflow ❯❯❯ ./tf_c_api_test
Running main() from test_main.cc
[==] Running 66 tests from 5 test cases.
[--] Global test environment set-up.
[--] 28 tests from CAPI
[ RUN  ] CAPI.Version
[   OK ] CAPI.Version (0 ms)
[ RUN  ] CAPI.Status
[   OK ] CAPI.Status (0 ms)
[ RUN  ] CAPI.Tensor
[   OK ] CAPI.Tensor (0 ms)
[ RUN  ] CAPI.MalformedTensor
[   OK ] CAPI.MalformedTensor (0 ms)
[ RUN  ] CAPI.AllocateTensor
[   OK ] CAPI.AllocateTensor (0 ms)
[ RUN  ] CAPI.MaybeMove
[   OK ] CAPI.MaybeMove (0 ms)
[ RUN  ] CAPI.LibraryLoadFunctions
2018-09-07 12:37:26.801818: I 
tensorflow/core/platform/cpu_feature_guard.cc:141] Your CPU supports 
instructions that this TensorFlow binary was not compiled to use: SSE3 SSE4.1 
SSE4.2 AVX AVX2 FMA
2018-09-07 12:37:26.803857: I tensorflow/c/c_api_test.cc:73] There are 
2 devices.
2018-09-07 12:37:26.803871: I tensorflow/c/c_api_test.cc:79] Device 0 
has name /job:localhost/replica:0/task:0/device:CPU:0, type CPU
2018-09-07 12:37:26.803895: I tensorflow/c/c_api_test.cc:79] Device 1 
has name /job:localhost/replica:0/task:0/device:XLA_CPU:0, type XLA_CPU
[   OK ] CAPI.LibraryLoadFunctions (8 ms)
[ RUN  ] CAPI.TensorEncodeDecodeStrings
[   OK ] CAPI.TensorEncodeDecodeStrings (0 ms)
[ RUN  ] CAPI.SessionOptions
[   OK ] CAPI.SessionOptions (0 ms)
[ RUN  ] CAPI.DeprecatedSession
[   OK ] CAPI.DeprecatedSession (0 ms)
[ RUN  ] CAPI.DataTypeEnum
[   OK ] CAPI.DataTypeEnum (0 ms)
[ RUN  ] CAPI.StatusEnum
[   OK ] CAPI.StatusEnum (0 ms)
[ RUN  ] CAPI.GetAllOpList
[   OK ] CAPI.GetAllOpList (9 ms)
[ RUN  ] CAPI.SetShape
[   OK ] CAPI.SetShape (0 ms)
[ RUN  ] CAPI.Graph
[   OK ] CAPI.Graph (0 ms)
[ RUN  ] CAPI.ImportGraphDef
[   OK ] CAPI.ImportGraphDef (2 ms)
[ RUN  ] CAPI.ImportGraphDef_WithReturnOutputs
[   OK ] CAPI.ImportGraphDef_WithReturnOutputs (0 ms)
[ RUN  ] CAPI.ImportGraphDef_MissingUnusedInputMappings
[   OK ] CAPI.ImportGraphDef_MissingUnusedInputMappings (1 ms)
[ RUN  ] CAPI.Session
2018-09-07 12:37:26.818053: F 
tensorflow/core/grappler/costs/op_level_cost_estimator.cc:404] Check failed: 0 
< gflops (0 vs. 0)type: "CPU"
vendor: "GenuineIntel"
model: "110"
num_cores: 4
environment {
  key: "cpu_instruction_set"
  value: "SSE, SSE2"
}
environment {
  key: "eigen"
  value: "3.3.90"
}
l1_cache_size: 32768
l2_cache_size: 262144
l3_cache_size: 6291456
memory_size: 11281461248

*** Received signal 6 ***

Bug#908155: Coordination with upstream developers not universally applied

[Moritz Muehlenhoff]

On Fri, Sep 07, 2018 at 02:14:15PM +0100, Ian Jackson wrote:
> Wouter Verhelst writes ("Bug#908155: Coordination with upstream developers 
> not universally applied"):
> > To me, the core message of the current text is that you should ensure
> > that bug reports which are not Debian-specific end up with upstream,
> > *somehow*, whether by the maintainers forwarding it to upstream
> > themselves or by them asking the reporter to do so. Your proposed new
> > text weakens that, and I think that's not a good idea.
> 
> How about this
> 
>These bug reports should be forwarded to the upstream developers so
>that they can be fixed in a future upstream release.  Usually it is
>best if you can do this, but alternatively, you may ask the bug
>submitter to do it.

LGTM.

Cheers,
Moritz

Bug#908219: libhinawa: please make the build reproducible

[Chris Lamb]

Source: libhinawa
Version: 1.0.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that libhinawa could not be built reproducibly.

This is because it uses the absolute @filename@ template variable to
generate a comment in a header files. Patch attached that uses
@basename@ instead.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/01-reproducible-build.patch1970-01-01 
01:00:00.0 +0100
--- b/debian/patches/01-reproducible-build.patch2018-09-07 
14:28:06.424844056 +0100
@@ -0,0 +1,26 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2018-09-07
+
+--- libhinawa-1.0.0.orig/src/hinawa_enums.c.template
 libhinawa-1.0.0/src/hinawa_enums.c.template
+@@ -4,7 +4,7 @@
+ 
+ /*** BEGIN file-production ***/
+ 
+-/* enumerations from "@filename@" */
++/* enumerations from "@basename@" */
+ /*** END file-production ***/
+ 
+ /*** BEGIN value-header ***/
+--- libhinawa-1.0.0.orig/src/hinawa_enums.h.template
 libhinawa-1.0.0/src/hinawa_enums.h.template
+@@ -9,7 +9,7 @@ G_BEGIN_DECLS
+ 
+ /*** BEGIN file-production ***/
+ 
+-/* enumerations from "@filename@" */
++/* enumerations from "@basename@" */
+ /*** END file-production ***/
+ 
+ /*** BEGIN value-header ***/
--- a/debian/patches/series 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/series 2018-09-07 14:28:05.332837328 +0100
@@ -0,0 +1 @@
+01-reproducible-build.patch

Bug#908220: cryptsetup-initramfs: Need a clean way to force cryptsetup in initramfs

[Raphaël Hertzog]

Package: cryptsetup-initramfs
Version: 2:2.0.4-2
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Hello,

In Kali we build a live image and we include cryptsetup by default so that
users can easily enable encrypted persistence following our instructions:
https://docs.kali.org/downloading/kali-linux-live-usb-persistence

However that no longer works... when the live image is created, there's
no encrypted device detected and you see that in the build log:

update-initramfs: Generating /boot/initrd.img-4.17.0-kali3-amd64
cryptsetup: WARNING: Couldn't determine root device
cryptsetup: ERROR: Couldn't resolve device /dev/sdb4
cryptsetup: WARNING: The initramfs image may not contain cryptsetup 
binaries 
nor crypto modules. If that's on purpose, you may want to uninstall the 
'cryptsetup-initramfs' package in order to disable the cryptsetup 
initramfs 
integration and avoid this warning.

The only way that I found to force the inclusion of cryptsetup is by
setting CRYPTSETUP=y in /etc/cryptsetup-initramfs/conf-hook. But when you do 
that
you get another worrying warning:

cryptsetup: WARNING: Honoring CRYPTSETUP=[y|n] will deprecated in the 
future. 
Please uninstall the 'cryptsetup-initramfs' package if you don't want 
the 
cryptsetup initramfs integration.

So what's the proper way to tell cryptsetup to put its files in the initramfs, 
no matter
what it detects, without generating a warning? Ideally I would like to
be able to do it by adding a supplementary file, not by modifying an existing
configuration file (as Debian policy forbids this).

Users very much dislike all those warnings and they report them to us in 
Kali... so
there must be a way to not get a warning. I would be more than happy if 
installing
cryptsetup-initramfs was sufficient. If the user doesn't want it in the 
initramfs, he
just removes the package.

Thank you for considering our request.

Related Kali tickets for reference:
https://bugs.kali.org/view.php?id=4945
https://bugs.kali.org/view.php?id=4719

-- Package-specific info:

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

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

Versions of packages cryptsetup-initramfs depends on:
ii  busybox 1:1.27.2-3
ii  cryptsetup-run  2:2.0.4-2
ii  initramfs-tools [linux-initramfs-tool]  0.132

Versions of packages cryptsetup-initramfs recommends:
ii  console-setup  1.185
ii  kbd2.0.4-4

cryptsetup-initramfs suggests no packages.

-- no debconf information

Bug#908221: postfix packages' upgrade problem at the postinst script, empty alias_database in main.cf causes problems

[Gábor Lénárt]

Package: postfix

This bug report is done because of the ask of an ubuntu/launchpad report
from me. I was given with the request to report this to the upstream. The
report itself:

https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1791139

I'm sorry, but I don't know what package version is affected in the Debian
distribution because of right now, I don't have any Debian system
accessible to check that out. The report itself from above:

I wanted to upgrade my bionic system. Some postfix related packages has
been upgraded:

# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  base-files postfix postfix-ldap postfix-mysql postfix-pcre
  python3-problem-report qemu-guest-agent
7 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

# ls /var/cache/apt/archives/postfix*deb
/var/cache/apt/archives/postfix_3.3.0-1ubuntu0.1_amd64.deb
/var/cache/apt/archives/postfix-ldap_3.3.0-1ubuntu0.1_amd64.deb
/var/cache/apt/archives/postfix-pcre_3.3.0-1ubuntu0.1_amd64.deb
/var/cache/apt/archives/postfix-cdb_3.3.0-1ubuntu0.1_amd64.deb
/var/cache/apt/archives/postfix-mysql_3.3.0-1ubuntu0.1_amd64.deb

After the installation, I saw this error message:

Setting up postfix-mysql (3.3.0-1ubuntu0.1) ...
Adding mysql map entry to /etc/postfix/dynamicmaps.cf
/var/lib/dpkg/info/postfix-mysql.postinst: 33: [: =: unexpected operator

But anyway, installation seemed to be succeeded. However, I noticed, that
according to my mail logs, all mysql based postfix tables does not work at
all with "unsupported map type". Just noticed, that even with ldap tables,
not only mysql tables ...

restarting postfix seems to cured the problem, but I think, it shouldn't
work this way ...

What I found: in /var/lib/dpkg/info/postfix-mysql.postinst the
corresponding context, where the problem is (line 33):

configure)
addmap mysql
   if [ $(postconf |grep alias_database | awk '{print $3}'|awk -F \: \
   '{print $1}') = 'mysql' ]; then
   runnewaliases
   fi
;;

I guess, the problem is the following: I have the main.cf with empty
alias_database directive, since I don't use aliases at all, so in main.cf,
I have:

# grep ^alias /etc/postfix/main.cf
alias_maps =
alias_database =
# postconf |grep alias_database
alias_database =
# postconf |grep alias_database | awk '{print $3}'|awk -F \: '{print $1}'
#

So you see, because of my config, I get empty string ... And it seems the
postinst script is not prepared to have this, as the empty string is
represented in the script this way then:

if [ = 'mysql' ]; then

So it is understandable now, that I get this error:

/var/lib/dpkg/info/postfix-mysql.postinst: 33: [: =: unexpected operator

Because of the postinst script runs with "set -e", this error is "fatal".
Surely, I guess the same issue happens with postfix-ldap package as well, I
guess, maybe with others, I am not sure (postfix-pcre, etc?).

I think, this should be fixed, since it can break things for everyone using
empty value for alias_database directive in main.cf

Though I am still not sure, why postfix thought these are unsupported map
types after the upgrade, and postfix restart cured the problem, shouldn't
the upgrade restart postfix anyway?

As a workaround, I put an empty hash map file into main.cf for with option,
now there is no error message in postinst script, but still, it's a strange
situation ...

Also, the logic in the script to "extract" table type is a bit complicated
I guess, I would use something like this:

if [ "$(postconf -h alias_database | cut -f1 -d:)" = "mysql" ]; then


Maybe there are better solutions than mine above, still, it's just a quick
idea (rather than multiple awk's and a grep) 
Btw, maybe an even better solution for that "if":

if postconf -h alias_database | grep -q '^mysql:' ; then

Bug#908146: libreoffice-dictionaries: Dealing with Breaks/Replaces against ancient dicts in other myspell/hunspell packages.

[Agustin Martin]

On Fri, Sep 07, 2018 at 02:52:13PM +0200, Mattia Rizzolo wrote:
> > 
> > Thanks for the info, I did not find the relevant part in helper.py.
> 
> Maybe because those are handled more "manually" in control.in :)
> 
> > There is one package (hunspell-sv) where that is desirable, since it will
> > only contain transitional packages hunspell-sv-se and myspell-sv-se, so
> > I think it is better if hunspell-sv-se transitional package is created
> > from lo-dicts itself.
> > 
> > Regarding myspell-sv-se transitional package, it was created back in 2011,
> > so I think is safe not to worry anymore about it.
> 
> I took over both, as myspell-sv-se seems to have several reverse
> dependencies still around, maybe you could look at that and file bugs?

Hi,

I have to look more carefully, but I think that the only real
reverse-dependency are debian-parl-{eu,world} packages, the others are
alternative or negative dependencies (Breaks, ...), but better to
clean up all this ancient stuff. I will file some bug reports for it.

> > Apart from the above, I think nothing else is needed.
> 
> Alright, I added transitional packages for myspell-sv-se and
> hunspell-sv-se, tweaked the versioning of Breaks/Conflicts and uploaded

Fine, thanks a lot.

Regards,

-- 
Agustin

Bug#908192: Acknowledgement (linux-image-4.18.0-1-amd64: After upgrade kernel to linux-image-4.18.0-1-amd64, LXC can not start)

[johnw]

I can start privileged LXC containers with 4.18 kernel,
Only can not start unprivileged LXC containers with 4.18 kernel.

Maybe the problem is lxc, not the kernel,

https://lists.linuxfoundation.org/pipermail/containers/2018-June/039174.html

--
Key fingerprint: CDB3 6C62 254B C088 1E5D DD32 182C 97DB CF2C 80AC

Bug#908222: octavia: please make the build reproducible

[Chris Lamb]

Source: octavia
Version: 3.0.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: hostname
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that octavia could not be built reproducibly.

This is because it embeds the hostname in the config file (which
also gets picked up in the documentation and the documentation
index files.)

Patch attached that uses sample_default.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.patch   1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/reproducible-build.patch   2018-09-07 14:37:54.488579794 
+0100
@@ -0,0 +1,14 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2018-09-07
+
+--- octavia-3.0.0.orig/octavia/common/config.py
 octavia-3.0.0/octavia/common/config.py
+@@ -38,6 +38,7 @@ API_SETTINGS_DEPRECATION_MESSAGE = _(
+ 
+ core_opts = [
+ cfg.HostnameOpt('host', default=utils.get_hostname(),
++sample_default='',
+ help=_("The hostname Octavia is running on")),
+ cfg.StrOpt('octavia_plugins', default='hot_plug_plugin',
+help=_("Name of the controller plugin to use")),
--- a/debian/patches/series 2018-09-07 14:26:28.148228533 +0100
--- b/debian/patches/series 2018-09-07 14:37:53.404572475 +0100
@@ -1 +1,2 @@
 fix-py36-compatibility.patch
+reproducible-build.patch

Bug#908200: grub-efi-*-signed: mismatch between /EFI/vendor (used) and /EFI/debian (expected) when derivative uses unmodified Debian binary packages

[Raphael Hertzog]

Control: tags -1 + patch

On Fri, 07 Sep 2018, Raphaël Hertzog wrote:
> The problem seems to come down to the fact that during initial installation,
> (at least) when the install picks the new *-signed packages, they get
> installed to /EFI/kali but the binary installed inside is actually
> expecting the configuration file in /EFI/debian/grub.cfg.

I'm attaching a possible patch. I checked that the package builds, but I
did not test the resulting package.

Since the EFI image hardcodes the patch in the EFI partition, I modified
/etc/default/grub to contain GRUB_BOOTLOADER_ID initialized with the
value of SB_EFI_VENDOR coming from debian/rules. grub-install has been
patched to initialize the default value of its --bootloader-id parameter
with this variable.

I opted to not modify GRUB_DISTRIBUTOR since this contains the
user-visible name of the derivative and we want to keep that obviously.

Cheers,

PS: I pushed my branch here too: https://salsa.debian.org/hertzog/grub
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/
>From 496d4265535bddbd1e55f8f883ff2742e7c05ef1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= 
Date: Fri, 7 Sep 2018 14:01:01 +0200
Subject: [PATCH 1/3] Store the EFI vendor in GRUB_BOOTLOADER_ID in
 /etc/default/grub

And use it when running grub-install in postinst.
---
 debian/default/grub | 1 +
 debian/postinst.in  | 9 +++--
 debian/rules| 1 +
 3 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/debian/default/grub b/debian/default/grub
index 7617f0131..f2be31cc5 100644
--- a/debian/default/grub
+++ b/debian/default/grub
@@ -5,6 +5,7 @@
 
 GRUB_DEFAULT=0
 GRUB_TIMEOUT=@DEFAULT_TIMEOUT@
+GRUB_BOOTLOADER_ID="@DEFAULT_BOOTLOADER_ID@"
 GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
 GRUB_CMDLINE_LINUX_DEFAULT="@DEFAULT_CMDLINE@"
 GRUB_CMDLINE_LINUX=""
diff --git a/debian/postinst.in b/debian/postinst.in
index 16cd64023..f12197c61 100644
--- a/debian/postinst.in
+++ b/debian/postinst.in
@@ -371,6 +371,7 @@ case "$1" in
 trap "rm -f ${tmp_default_grub}" EXIT
 cp -p /usr/share/grub/default/grub ${tmp_default_grub}
 
+sed -i -e 's|@DEFAULT_BOOTLOADER_ID@|@EFI_VENDOR@|' ${tmp_default_grub}
 merge_debconf_into_conf "$tmp_default_grub" GRUB_CMDLINE_LINUX grub2/linux_cmdline
 merge_debconf_into_conf "$tmp_default_grub" GRUB_CMDLINE_LINUX_DEFAULT grub2/linux_cmdline_default
 
@@ -690,11 +691,7 @@ case "$1" in
   ;;
 
   grub-efi-ia32|grub-efi-amd64|grub-efi-ia64|grub-efi-arm|grub-efi-arm64)
-bootloader_id="$(config_item GRUB_DISTRIBUTOR | tr A-Z a-z | \
- cut -d' ' -f1)"
-case $bootloader_id in
-  kubuntu) bootloader_id=ubuntu ;;
-esac
+bootloader_id="@EFI_VENDOR@"
 if [ "$bootloader_id" ] && [ -d "/boot/efi/EFI/$bootloader_id" ]; then
   case @PACKAGE@ in
 grub-efi-ia32)  target=i386-efi ;;
@@ -708,7 +705,7 @@ case "$1" in
 FORCE_EXTRA_REMOVABLE="--force-extra-removable"
   fi
   NO_NVRAM="$(no_nvram_arg)"
-  run_grub_install --target="$target" "$FORCE_EXTRA_REMOVABLE" "$NO_NVRAM"
+  run_grub_install --target="$target" --bootloader-id="$bootloader_id" "$FORCE_EXTRA_REMOVABLE" "$NO_NVRAM"
 fi
 
 # /boot/grub/ has more chances of being accessible by GRUB
diff --git a/debian/rules b/debian/rules
index 5c0bee13b..125d94cb2 100755
--- a/debian/rules
+++ b/debian/rules
@@ -300,6 +300,7 @@ platform_subst = \
 	if [ -e debian/$(1) ]; then \
 		debian/platform-subst \
 			PACKAGE="$(2)" \
+			EFI_VENDOR="$(SB_EFI_VENDOR)" \
 			DEFAULT_CMDLINE="$(DEFAULT_CMDLINE)" \
 			DEFAULT_TIMEOUT="$(DEFAULT_TIMEOUT)" \
 			DEFAULT_HIDDEN_TIMEOUT_BOOL="$(DEFAULT_HIDDEN_TIMEOUT_BOOL)" \
-- 
2.19.0.rc2

>From d23248b11c2d42013474355994dba62e02538675 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= 
Date: Fri, 7 Sep 2018 14:56:51 +0200
Subject: [PATCH 2/3] Update changelog

---
 debian/changelog | 8 
 1 file changed, 8 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 137d2db7f..2202e674a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+grub2 (2.02+dfsg1-7) UNRELEASED; urgency=medium
+
+  * Ensure grub-install install files in the directory where the EFI images
+built with grub are expecting them, even if we are running unmodified
+binary packages in a derivative distribution. Closes: #908200
+
+ -- Raphaël Hertzog   Fri, 07 Sep 2018 14:54:34 +0200
+
 grub2 (2.02+dfsg1-6) unstable; urgency=medium
 
   * Only build *-signed packages on their native architecture for now, since
-- 
2.19.0.rc2

>From d9e6c876294a3c1478eaca91f3df974440aa8c39 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= 
Date: Fri, 7 Sep 2018 14:30:49 +0200
Subject: [PATCH 3/3] Initialize bootloader_id from config wit

Bug#907829: p4est: FTBFS on single CPU machines (?)

[Adrian Bunk]

On Fri, Sep 07, 2018 at 02:45:31PM +0200, Santiago Vila wrote:
>...
> And I put a very simple example: Imagine that all our amd64
> autobuilders are Intel and there is a package which FTBFS on AMD.
> 
> Are you really trying to tell me that the FTBFS bug would not be
> serious "because it does not happen on buildd.debian.org"?

That's pretty exactly how things are handled.

An even better example than yours:

Some of the current mips buildds do have an FPU, and some don't.
Some packages do not build on the buildds without FPU.

The solution is to blacklist these packages for the buildds without FPU.

And after the blacklisting the RC FTBFS bugs are closed
since they are no longer happening on buildd.debian.org.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#905240: RFS: golang-github-rivo-tview

[Alexandre Viau]

On 2018-09-06 10:26 PM, Jongmin Kim wrote:
> On Thu, Sep 06, 2018 at 01:37:48PM -0400, Alexandre Viau wrote:
>> On 2018-09-05 10:36 PM, Jongmin Kim wrote:
>>> On Wed, Sep 05, 2018 at 09:54:50PM -0400, Alexandre Viau wrote:
 On 2018-09-01 02:05 AM, Jongmin Kim wrote:
> I tried to make the repository to keep the upstream's commit history,
> instead of using 'pristine-tar'. In result, I created again a new
> repository in my namespace:
> https://salsa.debian.org/jmkim-guest/golang-github-rivo-tview
>
> Would you please consider to use this for packaging, instead of using
> our team's repo? Thank you!
 Are you suggesting that we replace the team's repository? Or are you
 suggesting to keep it in your namespace?

 Are you able to just update the team's repository to the latest and
 greatest and have me review that instead?

 It may be that you are not able to overwrite existing commits. In that
 case, I am willing to wipe the repository for you.

 Let me know what you need.
>>> Ah, I suggest that we replace the team's repository.
>>>
>>> I cannot overwrite the existing commits (because all the branches are
>>> protected, and I don't have a right to overwrite them). Would you please
>>> wipe the team's repository? Then I will upload there. Thank you!
>> I have deleted the repository.
>>
>> Feel free to re-create it and ask me to review your new packaging.
> Thanks a lot. I created our team's repository and pushed:
> https://salsa.debian.org/go-team/packages/golang-github-rivo-tview
>
> Now it's ready for packaging. Could you please review again and upload?

What did you use to choose the branch names?

I don't see a "master" branch, so this is probably the new workflow?

However, the new workflow does not use the "debian" branch:
 - https://go-team.pages.debian.net/workflow-changes.html

Please either use a repository as created by dh-make-golang or use the
new workflow according to the spec on the team's website.

Cheesr,

-- 
Alexandre Viau
av...@debian.org




signature.asc
Description: OpenPGP digital signature

Bug#905240: RFS: golang-github-rivo-tview

[Alexandre Viau]

On 2018-09-06 10:26 PM, Jongmin Kim wrote:
> On Thu, Sep 06, 2018 at 01:37:48PM -0400, Alexandre Viau wrote:
>> On 2018-09-05 10:36 PM, Jongmin Kim wrote:
>>> On Wed, Sep 05, 2018 at 09:54:50PM -0400, Alexandre Viau wrote:
 On 2018-09-01 02:05 AM, Jongmin Kim wrote:
> I tried to make the repository to keep the upstream's commit history,
> instead of using 'pristine-tar'. In result, I created again a new
> repository in my namespace:
> https://salsa.debian.org/jmkim-guest/golang-github-rivo-tview
>
> Would you please consider to use this for packaging, instead of using
> our team's repo? Thank you!
 Are you suggesting that we replace the team's repository? Or are you
 suggesting to keep it in your namespace?

 Are you able to just update the team's repository to the latest and
 greatest and have me review that instead?

 It may be that you are not able to overwrite existing commits. In that
 case, I am willing to wipe the repository for you.

 Let me know what you need.
>>> Ah, I suggest that we replace the team's repository.
>>>
>>> I cannot overwrite the existing commits (because all the branches are
>>> protected, and I don't have a right to overwrite them). Would you please
>>> wipe the team's repository? Then I will upload there. Thank you!
>> I have deleted the repository.
>>
>> Feel free to re-create it and ask me to review your new packaging.
> Thanks a lot. I created our team's repository and pushed:
> https://salsa.debian.org/go-team/packages/golang-github-rivo-tview

Again, I notice that you have created a "debian" branch, none of our
workflows use this.

I'd like to avoid repeating the same comments twice, maybe you should
focus on one ITP and then proceed to the next?

Cheers,

-- 
Alexandre Viau
av...@debian.org




signature.asc
Description: OpenPGP digital signature

Bug#908155: Coordination with upstream developers not universally applied

[Thorsten Glaser]

On Fri, 7 Sep 2018, Ian Jackson wrote:

> I think it is usually better if the Debian maintainer can do this.
> I would like to encourage maintainers do do it.  But I really don't
> think we can make this mandatory.

Uhm… it’s been mandatory the last couple of years.

> It's all very well to say that package maintainers "should" do
> something.  Package maintainers "should" fix all bugs in their
> packages.
>
> But we have limited effort.  It is better to have a package in Debian,
> but where users have to do some more of the work, than no package.

Good point.

As I wrote in 
I don’t think it’s sensible to _forbid_ maintainers to ask users to
report upstream. My concerns is more about cases in which that is
a big burden on the users. Tons of bug trackers come to mind, or being
unskilled in the interna of a particular package.

As long as it’s a “should” in the same sense as “should fix bugs in
their packages”, and package maintainers keep an eye on users’ bug
reports and, when necessary, help them (providing infos to upstream,
packages to test to users who can’t (easily) build themselves, and,
yes, definitely *also* forward bugs upstream, occasionally.

Does this sound like an option?

bye,
//mirabilos
-- 
[17:15:07] Lukas Degener: Kleines Asterix-Latinum für Softwaretechniker:
   veni, vidi, fixi(t) ;-)

Bug#895640: Closing this one

[Santiago Vila]

reopen 895640
thanks

On Thu, 6 Sep 2018, Thomas Goirand wrote:

> This bug was fixed by latest upload to Sid.

Hmm. Are you sure? In this case, latest version in sid is 1:9.0.0-1,
which is also the version in the bug report, which entered testing
today and failed to build in my autobuilder too.

If I'm mistaken, sorry for the reopening, and please use close with a
version.

Thanks.

Bug#908223: lxc: Can not start unprivileged LXC containers with 4.18 kernel

[John Wong]

Package: lxc
Version: 1:2.0.9-6.1
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

After upgrade kernel to linux-image-4.18.0-1-amd64, I can not start 
unprivileged LXC containers,
Maybe related to this one 
"https://lists.linuxfoundation.org/pipermail/containers/2018-June/039174.html";,
and "https://github.com/lxc/lxc/pull/2438";.

Please help and thank you.

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


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

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

Versions of packages lxc depends on:
ii  libapparmor1  2.13-8
ii  libc6 2.27-6
ii  libcap2   1:2.25-1.2
ii  libgnutls30   3.5.19-1
ii  liblxc1   1:2.0.9-6.1
ii  libseccomp2   2.3.3-3
ii  libselinux1   2.8-1+b1
ii  lsb-base  9.20170808
ii  python3   3.6.6-1
ii  python3-lxc   1:2.0.9-6.1

Versions of packages lxc recommends:
ii  bridge-utils  1.5-16
pn  debootstrap   
ii  dirmngr   2.2.10-1
pn  dnsmasq-base  
ii  gnupg 2.2.10-1
ii  iptables  1.6.2-1.1
pn  libpam-cgfs   
pn  lxcfs 
ii  openssl   1.1.1~~pre9-1
ii  rsync 3.1.2-2.2
pn  uidmap

Versions of packages lxc suggests:
ii  apparmor 2.13-8
ii  btrfs-progs  4.17-1
pn  lvm2 

-- no debconf information

Bug#908062: dch --lts has wrong version number

[Antoine Beaupré]

On 2018-09-06 21:26:43, Mattia Rizzolo wrote:
> Control: tag -1 pending
>
> On Wed, Sep 05, 2018 at 12:53:14PM -0400, Antoine Beaupré wrote:
>> On 2018-09-05 12:50:07, Antoine Beaupre wrote:
>> > dch --lts currently creates a changelog entry for wheezy and a +deb7uX
>> > version number. wheezy is now ELTS and it's jessie that's LTS.
>> >
>> > The attached patch should fix this.
>> 
>> The patch was also pushed to the git repository.
>
> Not sure about what git repository you are talking about, as I haven't
> seen anything on salsa.d.o/debian/devscripts, but I've now applied your
> patch (after tweaking the message and adding a changelog entry) :)

Ah yes, forgot to push of course. Thanks for the declutter! :)

a.
-- 
We reject kings, presidents and voting.
We believe in rough consensus and running code.
- David Clark

Bug#896861: More notes on Open MPI / sometimes "-l" issues

[Jeff Squyres (jsquyres)]

On Sep 7, 2018, at 1:29 AM, Alastair McKinstry  
wrote:
> 
>> I am using:
>> 
>> Autoconf 2.69
>> Automake 1.15 (*** you are using 1.15.1 -- do we think that makes a 
>> difference?)
>> Libtool 2.4.6
> 
> Something about Debian's libtool still implicated, then.

Ouch -- that could get tricky to track down.  :-(

Just for giggles: what version of (g)m4 do you have?  I'm using 1.4.17.

It would likely be difficult for me to try Debian's Libtool, but if you're 
using a different m4, that might impact Libtool's search-and-replace...?  I'd 
be happy to give it a whirl on my side (i.e., on RHEL and/or MacOS) with the 
full complement of exactly the (stock) Autotools versions you're using to see 
if that triggers the issue.

-- 
Jeff Squyres
jsquy...@cisco.com

Bug#908185: False positive init.d-script-possible-missing-stop for rcS init scripts

[Chris Lamb]

tags 908185 + pending
thanks

Fixed in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/683335046187b832a10bb6a59413ccc12b21898d

  checks/init.d.pm|  4 +++-
  debian/changelog|  4 
  t/tests/init.d-lsb-headers/debian/debian/control.in |  9 +
  .../debian/init.d-lsb-headers-early-boot.init   | 21 +
  t/tests/init.d-lsb-headers/tags |  1 +
  5 files changed, 38 insertions(+), 1 deletion(-)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-