Bug#887743: ksh FTBFS: ast_stdio.h:82:15: error: conflicting types for '_sfio_FILE'

[Petter Reinholdtsen]

[ Juhani Numminen]
> From a comment at upstream issue tracker[1], I understand that FreeBSD has 
> patch[2] to fix this,
> but I didn't try it out myself.

I tested this patch from FreeBSD, and it did not solve the build problem:

Index: ksh-93u+20120801/src/lib/libast/features/wchar
===
--- ksh-93u+20120801.orig/src/lib/libast/features/wchar 2018-10-02 
06:36:06.485021481 +
+++ ksh-93u+20120801/src/lib/libast/features/wchar  2018-10-02 
06:36:06.481021424 +
@@ -51,6 +51,7 @@
 run{
 cat .  
I tested this
one too, and it did not fix the build failure either.  I did not look closely 
into the failure.

-- 
Happy hacking
Petter Reinholdtsen

Bug#909728: I found a workaround

[Matijs van Zuijlen]

Dear maintainer,

The folder /usr/local/share/fonts turned out to be empty. Removing it
stopped the messages appearing.

-- 
Kind regards,
Matijs van Zuijlen



signature.asc
Description: OpenPGP digital signature

Bug#910058: gitlab: please depend on bzip2

[Johannes 'josch' Schauer]

Package: gitlab
Severity: normal

Hi,

currently, when clicking on the "Download tar.bz2" link without having
the bzip2 package installed, gitlab returns a 500 error to the user.
After installing the bzip2 package, this doesn't happen anymore and a
bzipped tarball can be downloaded normally.

Hence, it would probably prudent to depend on the bzip2 package.

Thanks!

cheers, josch

Bug#910051: [pkg-uWSGI-devel] Bug#910051: uwgi: fails to build with shellcheck 0.5.0

[Jonas Smedegaard]

Quoting Jeremy Bicha (2018-10-02 02:58:00)
> uwsgi fails to build from source with shellcheck 0.5.0. That version
> hasn't built in Debian yet; I believe it's caught up in the ongoing
> haskell transition.
> 
> You can see the build failure at
> https://launchpad.net/ubuntu/+source/uwsgi/2.0.17.1-7/+build/15501460

Excellent. Thanks!


> A friend is working on a patch

Not needed, the failures look obvious to me.  Thanks anyway.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#909942: mmdebstrap: breaks system it runs on, power cycle needed.

[Andreas Henriksson]

Hi josch!

Thanks for the quick fixes. I'd say the latest version includes fixes for
both the major issues, so should be good to close this bug report!
See below for output from my testing.

Also wanted to mention two unrelated things I noticed white at it:
- was first confused that I did not find the commits in the repo pointed to
  by Vcs-Git/Browse.
- gitlab.mister-muffin.de is has a breakage if you click the 'download arrow'
  icon and select the 'tar.bz2' option. (Using 'tar.gz' works though.)


:/tmp/mmdebstrap-master-d25e939363c18824b58f545d7332c4e960184160$ ls -ld 
/dev/shm ; findmnt -R /sys ; sudo ./mmdebstrap sid /tmp/sid ; ls -ld /dev/shm ; 
findmnt -R /sys
drwxrwxrwt 2 root root 40 okt  2 08:30 /dev/shm
TARGET  SOURCE FSTYPE  OPTIONS
/syssysfs  sysfs   rw,nosuid,nodev,noexec,re
├─/sys/kernel/security  securityfs securit rw,nosuid,nodev,noexec,re
├─/sys/fs/cgrouptmpfs  tmpfs   ro,nosuid,nodev,noexec,mo
│ ├─/sys/fs/cgroup/unified  cgroup2cgroup2 rw,nosuid,nodev,noexec,re
│ ├─/sys/fs/cgroup/systemd  cgroup cgroup  rw,nosuid,nodev,noexec,re
│ ├─/sys/fs/cgroup/devices  cgroup cgroup  rw,nosuid,nodev,noexec,re
│ ├─/sys/fs/cgroup/net_cls,net_prio cgroup cgroup  rw,nosuid,nodev,noexec,re
│ ├─/sys/fs/cgroup/blkiocgroup cgroup  rw,nosuid,nodev,noexec,re
│ ├─/sys/fs/cgroup/cpu,cpuacct  cgroup cgroup  rw,nosuid,nodev,noexec,re
│ ├─/sys/fs/cgroup/cpuset   cgroup cgroup  rw,nosuid,nodev,noexec,re
│ ├─/sys/fs/cgroup/perf_event   cgroup cgroup  rw,nosuid,nodev,noexec,re
│ ├─/sys/fs/cgroup/pids cgroup cgroup  rw,nosuid,nodev,noexec,re
│ ├─/sys/fs/cgroup/freezer  cgroup cgroup  rw,nosuid,nodev,noexec,re
│ └─/sys/fs/cgroup/memory   cgroup cgroup  rw,nosuid,nodev,noexec,re
├─/sys/fs/pstorepstore pstore  rw,nosuid,nodev,noexec,re
├─/sys/fs/bpf   bpfbpf rw,nosuid,nodev,noexec,re
└─/sys/kernel/debug debugfsdebugfs rw,relatime
[sudo] password for ah: 
I: chroot architecture amd64 is equal to the host's architecture
I: automatically chosen mode: root
I: running apt-get update...
done
I: downloading packages with apt...
done
I: extracting archives...
done
I: installing packages...
done
I: downloading apt...
done
I: installing apt...
done
I: installing remaining packages inside the chroot...
done
I: cleaning package lists and apt cache...
done
done
drwxrwxrwt 2 root root 40 okt  2 08:32 /dev/shm
TARGET  SOURCE FSTYPE  OPTIONS
/syssysfs  sysfs   rw,nosuid,nodev,noexec,re
├─/sys/kernel/security  securityfs securit rw,nosuid,nodev,noexec,re
├─/sys/fs/cgrouptmpfs  tmpfs   ro,nosuid,nodev,noexec,mo
│ ├─/sys/fs/cgroup/unified  cgroup2cgroup2 rw,nosuid,nodev,noexec,re
│ ├─/sys/fs/cgroup/systemd  cgroup cgroup  rw,nosuid,nodev,noexec,re
│ ├─/sys/fs/cgroup/devices  cgroup cgroup  rw,nosuid,nodev,noexec,re
│ ├─/sys/fs/cgroup/net_cls,net_prio cgroup cgroup  rw,nosuid,nodev,noexec,re
│ ├─/sys/fs/cgroup/blkiocgroup cgroup  rw,nosuid,nodev,noexec,re
│ ├─/sys/fs/cgroup/cpu,cpuacct  cgroup cgroup  rw,nosuid,nodev,noexec,re
│ ├─/sys/fs/cgroup/cpuset   cgroup cgroup  rw,nosuid,nodev,noexec,re
│ ├─/sys/fs/cgroup/perf_event   cgroup cgroup  rw,nosuid,nodev,noexec,re
│ ├─/sys/fs/cgroup/pids cgroup cgroup  rw,nosuid,nodev,noexec,re
│ ├─/sys/fs/cgroup/freezer  cgroup cgroup  rw,nosuid,nodev,noexec,re
│ └─/sys/fs/cgroup/memory   cgroup cgroup  rw,nosuid,nodev,noexec,re
├─/sys/fs/pstorepstore pstore  rw,nosuid,nodev,noexec,re
├─/sys/fs/bpf   bpfbpf rw,nosuid,nodev,noexec,re
└─/sys/kernel/debug debugfsdebugfs rw,relatime
:/tmp/mmdebstrap-master-d25e939363c18824b58f545d7332c4e960184160$ 

Thanks for an awesome program.

Regards,
Andreas Henriksson

Bug#908681: fixed in sane-backends 1.0.27-2

[Julien Cristau]

Control: reopen -1

On Mon, Oct  1, 2018 at 23:48:42 +, Jörg Frings-Fürst wrote:

>  sane-backends (1.0.27-2) unstable; urgency=medium
>  .
>* debian/control:
>  - Remove obsolete section about sane-backends-extras.
>  - Revert change from Breaks to Conflicts for binary package libsane1
>(Closes: #908681).

This doesn't address this issue.

Cheers,
Julien

Bug#898969: dnssec-trigger: fails with OpenSSL 1.1.1 due to too-small key

[Paul Wise]

On Mon, 2018-10-01 at 22:42 -0700, Diane Trout wrote:

> Could you go into a bit more detail about how dnssec-triggerd-keygen
> isn't working for you?

As mentioned in the initial mail in the bug by brian m. carlson,
it creates the keys in /etc, not in /etc/dnssec-trigger and
the latter is where dnssec-triggerd looks for the keys.

> Because currently the easiest answer I can think of for this is to
> delete the keys and restart the daemons on upgrade.

That seems like the reasonable thing to do as long as the code for this
checks that the keys are long enough for the new openssl. It should
probably also add a trigger on the openssl files, so that merely
upgrading openssl to the new version does the delete and restart.

> Also I'm a bit surprised the panel is working. I guess this means
> you're using something that is not gnome.

I am using GNOME. The panel item was *not* working and thus generating
the errors in the dnssec-triggerd logs. This is because after the key
was replaced and the daemon restarted, it didn't reload the key from
disk and use the new one instead of the old one. So the panel needs to
handle a daemon restart (I assume it gets notification of that event)
by reloading the key before connecting to the newly restarted daemon.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#898969: dnssec-trigger: fails with OpenSSL 1.1.1 due to too-small key

[Paul Wise]

On Mon, 01 Oct 2018 22:42:52 -0700 Diane Trout wrote:

> Also I'm a bit surprised the panel is working. I guess this means
> you're using something that is not gnome.

Ah, maybe you're referring to GNOME getting rid of the system-tray
stuff, I'm using a GNOME shell extension to restore that functionality.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#871502: zotero-standalone-build: The newer Zotero is standalone only ; a reorganization is neded.

[Trout, Diane E.]

On Sat, 2018-09-29 at 13:01 +0200, Félix Sipma wrote:
> Package: src:zotero-standalone-build
> Followup-For: Bug #871502
> 
> So, zotero is starting to be severely broken... Maybe we should
> remove it
> completely from Debian?
> 
> Diane, you are the last one who tried to update zotero, do you still
> have
> interest in doing so?

I was at least going to try and commit the work I did and stick on
salsa, but I've been busy the past couple of days. I'll try to get it
done in by the weekend.

There's some javascript packages that are needed, that aren't packaged.

What I had so far can only build outside of a chroot when npm can
download packages.

Would anyone be willing to help package some javascript dependencies?

If my d/control file is right Debian is missing these:

#  node-babel-plugin-transform-es2015-modules-commonjs,
#   node-browserify,
#  node-chai,
#  node-chai-as-promised,
#  node-co-mocha,
#  node-eslint-plugin-react,
#  node-mocha,
#  node-node-sass,


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

Bug#898969: dnssec-trigger: fails with OpenSSL 1.1.1 due to too-small key

[Diane Trout]

On Mon, 2018-09-17 at 09:55 +0800, Paul Wise wrote:
> Package: dnssec-trigger
> Version: 0.15+repack-1
> Followup-For: Bug #898969
> Control: retitle -1 dnssec-trigger: fails with OpenSSL 1.1.1 due to
> too-small key and unknown ca
> Control: severity -1 serious 
> 
> If I delete the existing keys and recreate them with dnssec-trigger-
> control-setup (since dnssec-triggerd-keygen is broken) and restart
> dnssec-triggerd, I get an error repeating over and over again:

Could you go into a bit more detail about how dnssec-triggerd-keygen
isn't working for you?

Because currently the easiest answer I can think of for this is to
delete the keys and restart the daemons on upgrade.

Also I'm a bit surprised the panel is working. I guess this means
you're using something that is not gnome.


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

Bug#884635: transition: libupnp

[Niels Thykier]

Uwe Kleine-König:
> Hello,
> 
> adding Marcelo (upstream for libupnp) to recipents.
> 
> On 09/30/2018 10:09 AM, Sebastian Ramacher wrote:
>> On 2017-12-22 22:38:23, Uwe Kleine-König wrote:
>>> Hello,
>>>
>>> On Sun, Dec 17, 2017 at 10:07:16PM +0100, Uwe Kleine-König wrote:
 Currently there are two versions of libupnp in the archive:

  - src:libupnp providing the 1.6.x branch of libupnp which is considered
legacy by upstream
  - src:pupnp-1.8 providing the 1.8.x branch of libupnp

 I want to get rid of libupnp6 converting all rdeps to the newer libupnp
 package.
>>>
>>> ...
>>
>> The list of open issues is down to:
>>
>>>  - amule
>>>- FTBFS #884996 (patch)
>>>  - djmount
>>>- FTBFS #884243
>>>  - gmrender-resurrect
>>>- FTBFS #884246
>>>  - linphone
>>>- FTBFS #884247
>>
>> Those still fail to build.
>>
>>>  - gmediaserver
>>>- FTBFS #884245
>>
>> RM requested.
> (RM = Request to remove the package from testing)
> 
>> Considering that those packages had over 9 months to get fixed, I think we
>> should start the transition and RM the unfixed packages from testing.
> 
> The bug for gmrender-resurrect is tagged "help". I didn't look into that
> but I think it would be fair to check this one at least before starting
> to remove packages. I'll give it a bump in my todo list.
> 
> @Marcelo: Do you care to look into https://bugs.debian.org/884246 ?
> 
> Best regards
> Uwe
> 

Hi,

Before this transition can start, we will need a solution for amule,
djmount, gmrender-resurrect and linphone (which is either RM or upload
with a fix).

Removing all of them leads to the following collateral damage[1]:

"""
Checking reverse dependencies...
# Broken Depends:
kopete: kopete
libosmo-abis: libosmotrau2

# Broken Build-Depends:
kopete: libmediastreamer-dev (>= 3.6)
libortp-dev (>= 0.13)
libosmo-abis: libortp-dev
libosmo-netif: libortp-dev
osmo-bts: libortp-dev

Dependency problem found.
"""
(I have not researched exactly which package causes what to break; that
is an exercise left for the reader)

Accordingly, if we plan on removing these packages, their dependencies
are now also a part of the transition (having to move away from the
packages being removed or being removed themselves - the latter leading
to a rinse-and-repeat effect).

So:

 * Which of amule, djmount, gmrender-resurrect, linphone are going to
   be fixed/removed?

 * What is and how do we handle the collateral (if any) from any
  removals?

Thanks,
~Niels


[1]:
dak rm -nR -s testing amule djmount gmrender-resurrect \
  linphone gmediaserver

Can be run from respighi.debian.org, which is DD-accessible.

Bug#884246: gmrender-resurrect: FTBFS against upnp 1.8

[Niels Thykier]

On Sun, 26 Aug 2018 14:33:46 +0200 Tobias Frost  wrote:
> I tagged it help because maybe someone with more libupnp knowledge can
> help me... Or if there is some migration guide, please let me know...
> (I could not find anything...)
> 
> 

Hi,

We received some pointers in the following mail, which should probably
have been sent to this bug:

https://lists.debian.org/debian-release/2018/10/msg2.html

Thanks,
~Niels

Bug#908927: Issue seems fixed on Arch Linux machine by kernel 3.16.58-1-ARCH

[Andrew Roberts]

I've updated the kernel on the Arch Linux box which was experiencing the 
same issue to: 3.16.58-1-ARCH


This seems to fix the issue on that machine, so hopefully the fix is on 
the way here also.


Thanks

Andrew

Bug#910057: templates: should mention salsa.d.o instead of alioth.d.o as vcs host

[魏銘廷]

Package: nm.debian.org
Severity: normal

Hi,

I received welcome email but it seems it refers to the already died
alioth as VCS repo:

> The machine hosting most of our VCS repositories
> ({svn,bzr,git,arch,hg}.debian.org) is alioth.debian.org. It's handled
> by a separate team (ad...@alioth.debian.org) as it allows login by
> non-Debian developers. You probably already have a *-guest account
> there.  Please refer to https://wiki.debian.org/AliothFAQ to learn
> anything you need to know, including how to activate your account and
> how to request the removal of your old -guest account.

While Salsa account migration is mentioned in wiki [1], we should also
change the corresponding phrasing in the welcome email template as well.

Thanks,
Yao Wei

[1]: https://wiki.debian.org/MigrateToDDAccount


signature.asc
Description: PGP signature

Bug#908662: r-cran-etm: autopkgtest regression: saved results mismatch

[Andreas Tille]

Hi,

it is definitely architecture dependand.  I think the solution would be
to do a comparison tollerating this micro-diffs.

Kind regards

   Andreas.

On Mon, Oct 01, 2018 at 11:35:02PM +0200, Arthur Allignol wrote:
> Hi, 
> 
> sorry for not getting back to you earlier. Totally forgot about it...
> 
> If I read the diff well, there is differences in the 19th decimal (e.g., 
> 1.337e-19 vs 1.032e-19). Could these kind of rounding error be platform 
> specific? The saved results were obtained on a Mac. I could find some time to 
> fire up a VM and see but I would tend to ignore the problem. 
> 
> Should I take further actions?
> 
> Thanks for your work! and best,
> Arthur
> 
> 
> > On 12. Sep 2018, at 14:15, Andreas Tille  wrote:
> > 
> > Hi Arthur,
> > 
> > there was a bug report filed against the Debian packaged version of etm.
> > It seems the saved results are not matching the result of the test.
> > 
> > Could you please comment on this - may be we are doing something wrong?
> > 
> > Kind regards
> > 
> >   Andreas.
> > 
> > 
> > On Wed, Sep 12, 2018 at 12:26:13PM +0200, Graham Inggs wrote:
> >> Source: r-cran-etm
> >> Version: 1.0.4-2
> >> User: debian...@lists.debian.org
> >> Usertags: regression
> >> 
> >> Hi R Package Team
> >> 
> >> Now that #903672 has been resolved, we can see that r-cran-etm fails its
> >> autopkgtest [1] with the following errors:
> >> 
> >> --- tests.etm.Rout.save_   2018-09-10 10:04:21.100595425 +
> >> +++ tests.etm.Rout_2018-09-10 10:04:21.104595447 +
> >> @@ -246,7 +246,7 @@
> >> 116  0.9990 116.0 4.764e-07 0.99767 1.  1   0
> >> 124  0.9990 124.0 4.764e-07 0.99767 1.  2   0
> >> 164  0.9990 164.0 4.764e-07 0.99767 1.  0   0
> >> -183  1. 183.0 1.337e-19 1.0 1.  1   1
> >> +183  1. 183.0 1.032e-19 1.0 1.  1   1
> >>> 
> >>> ## gonna play a bit with the state names
> >>> dd <- sir.cont
> >> @@ -694,7 +694,7 @@
> >>  0.90344   35 1.193e-04 0.88204 0.92484 54   4
> >>  0.96816   54 4.374e-05 0.95520 0.98113 15   2
> >>  0.98894   77 1.668e-05 0.98094 0.99695  5   0
> >> - 1.0  460 1.016e-20 1.0 1.0  1   1
> >> + 1.0  460 2.253e-19 1.0 1.0  1   1
> >> 
> >> Transition 1 1
> >>   P time  var   lower   upper n.risk n.event
> >> autopkgtest [10:04:21]: test run-unit-test: ---]
> >> autopkgtest [10:04:21]: test run-unit-test:  - - - - - - - - - - results - 
> >> -
> >> - - - - - - - -
> >> run-unit-testFAIL non-zero exit status 1
> >> 
> >> Regards
> >> Graham
> >> 
> >> 
> >> [1] https://ci.debian.net/packages/r/r-cran-etm/unstable/amd64/
> > 
> > -- 
> > http://fam-tille.de
> 
> 

-- 
http://fam-tille.de

Bug#891098: NMU sugegstion

[Sergei Golovan]

Hi Onur,

I've prepared a NMU with the Stefano's patch. If you don't mind, I'd
like to upload it. The diff is attached.

Cheers!
-- 
Sergei Golovan


gumbo-parser_0.10.1+dfsg-2.3.debdiff
Description: Binary data

Bug#910056: twisted: Missing version constraint on python-attr dependencies

[Stuart Prescott]

Source: twisted
Version: 18.7.0-2
Severity: important

Dear Maintainer,

The python3-twisted package declares "Depends: python3-attr" however it is
not compatible with the version of python3-attr that is in stretch. This
means that partially upgraded systems could have a non-functional twisted
installation and also means that the upload of twisted to stretch-backports
is (partially?) broken.

To fix the partial-upgrade problem, a versioned dependency such as ">> 17.4.0"
is sufficient.

(Andrej, for stretch-backports, a backport of python-attrs fixes the problem.)

I also can't spot the twisted test suite being run in either the sid or the
stretch-backports build logs, is it possible to make the tests run on the
buildd? (Would that have caught this problem with the backport?)

cheers
Stuart



$ python3
Python 3.5.3 (default, Sep 27 2018, 17:25:39) 
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import twisted.web.http
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/twisted/web/http.py", line 100, in 

from twisted.internet import interfaces, protocol, address
  File "/usr/lib/python3/dist-packages/twisted/internet/address.py", line 23, 
in 
class IPv4Address(object):
  File "/usr/lib/python3/dist-packages/twisted/internet/address.py", line 37, 
in IPv4Address
type = attr.ib(validator=attr.validators.in_(["TCP", "UDP"]))
AttributeError: module 'attr.validators' has no attribute 'in_'

$ apt-cache policy python3-twisted python3-attr
python3-twisted:
  Installed: 18.7.0-2~bpo9+1
  Candidate: 18.7.0-2~bpo9+1
  Version table:
 *** 18.7.0-2~bpo9+1 200
200 http://deb.debian.org/debian stretch-backports/main amd64 Packages
200 http://deb.debian.org/debian stretch-backports/main i386 Packages
100 /var/lib/dpkg/status
 16.6.0-2 500
500 http://deb.debian.org/debian stretch/main amd64 Packages
500 http://deb.debian.org/debian stretch/main i386 Packages
python3-attr:
  Installed: 16.3.0-1
  Candidate: 16.3.0-1
  Version table:
 *** 16.3.0-1 500
500 http://deb.debian.org/debian stretch/main amd64 Packages
500 http://deb.debian.org/debian stretch/main i386 Packages
100 /var/lib/dpkg/status

Bug#910055: gsequencer hard codes location of errno.h

[Helmut Grohne]

Source: gsequencer
Version: 1.4.34-1
Tags: patch
Control: block 798955 by -1

gsequencer passes "-include /usr/include/errno.h". It thus hard codes
the location of errno.h. For non-glibc libcs, that file is located
in /usr/include/ instead and after fixing #798955 we'll use the
triplet location exclusively making gsequencer FTBFS. There is no
practical benefit from hard coding the location here as you can simply
pass "-include errno.h" here to achieve the same effect. Please consider
applying the attached patch.

Helmut
--- gsequencer-1.4.34.orig/Makefile.am
+++ gsequencer-1.4.34/Makefile.am
@@ -6,7 +6,7 @@
 SUBDIRS = po
 
 ACLOCAL_AMFLAGS = -I m4
-AM_CPPFLAGS = -std=gnu99 -include /usr/include/errno.h -I$(top_srcdir) -DSRCDIR=\"$(srcdir)\" -DDESTDIR=\"$(DESTDIR)$(datadir)\" -DPACKAGE_VERSION=\"$(PACKAGE_VERSION)\" -DAGS_LIBRARY_SUFFIX=\".so\" -DAGS_RT_PRIORITY=99 -D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security
+AM_CPPFLAGS = -std=gnu99 -include errno.h -I$(top_srcdir) -DSRCDIR=\"$(srcdir)\" -DDESTDIR=\"$(DESTDIR)$(datadir)\" -DPACKAGE_VERSION=\"$(PACKAGE_VERSION)\" -DAGS_LIBRARY_SUFFIX=\".so\" -DAGS_RT_PRIORITY=99 -D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security
 # -msse2 -O3 -ftree-vectorize -ftree-slp-vectorize -ffast-math -ftree-vectorizer-verbose=2
 
 # what flags you want to pass to the C compiler & linker

Bug#910054: kmail: Fatal startup error: Could not create collection inbox, resourceId: 3

[Nazar Zhuk]

Package: kmail
Version: 4:17.12.3-1
Severity: normal

Dear Maintainer,

On a fresh buster install when first opening KMail, I received this
message and after clicking a button in the dialog, KMail exited:

  Could not create collection inbox, resourceId: 3

On the second and subsequent attempts KMail opened without any issues.

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

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

Versions of packages kmail depends on:
ii  akonadi-server   4:17.12.3-3
ii  kdepim-runtime   4:17.12.3-2
ii  kio  5.49.0-1
ii  libc62.27-6
ii  libgcc1  1:8.2.0-7
ii  libgpgmepp6  1.11.1-1
ii  libkf5akonadiagentbase5  4:17.12.3-3
ii  libkf5akonadicontact54:17.12.3-2
ii  libkf5akonadicore5abi1   4:17.12.3-3
ii  libkf5akonadimime5   4:17.12.3-1
ii  libkf5akonadisearch-bin  4:17.12.3-1
ii  libkf5akonadisearch-plugins  4:17.12.3-1
ii  libkf5akonadisearchdebug54:17.12.3-1
ii  libkf5akonadisearchpim5  4:17.12.3-1
ii  libkf5akonadiwidgets5abi14:17.12.3-3
ii  libkf5bookmarks5 5.49.0-1
ii  libkf5calendarcore5abi1  4:17.12.3-1
ii  libkf5calendarutils5 4:17.12.3-1
ii  libkf5codecs55.49.0-1
ii  libkf5completion55.49.0-1
ii  libkf5configcore55.49.0-1
ii  libkf5configgui5 5.49.0-1
ii  libkf5configwidgets5 5.49.0-1
ii  libkf5contacts5  4:17.12.3-1
ii  libkf5coreaddons55.49.0-1
ii  libkf5crash5 5.49.0-1
ii  libkf5dbusaddons55.49.0-1
ii  libkf5followupreminder5  4:17.12.3-1
ii  libkf5grantleetheme-plugins  17.12.3-1
ii  libkf5gravatar5abi1  4:17.12.3-1
ii  libkf5guiaddons5 5.49.0-1
ii  libkf5i18n5  5.49.0-1
ii  libkf5iconthemes55.49.0-1
ii  libkf5identitymanagement517.12.3-1
ii  libkf5itemmodels55.49.0-1
ii  libkf5itemviews5 5.49.0-1
ii  libkf5jobwidgets55.49.0-1
ii  libkf5kcmutils5  5.49.0-1
ii  libkf5kiocore5   5.49.0-1
ii  libkf5kiofilewidgets55.49.0-1
ii  libkf5kiowidgets55.49.0-1
ii  libkf5kontactinterface5  17.12.3-1
ii  libkf5ksieveui5  4:17.12.3-1
ii  libkf5libkdepim-plugins  4:17.12.3-1
ii  libkf5libkdepim5 4:17.12.3-1
ii  libkf5libkdepimakonadi5  4:17.12.3-1
ii  libkf5libkleo5   4:17.12.3-2
ii  libkf5mailcommon5abi14:17.12.3-1
ii  libkf5mailtransport5 17.12.3-1
ii  libkf5mailtransportakonadi5  17.12.3-1
ii  libkf5messagecomposer5   4:17.12.3-3
ii  libkf5messagecore5   4:17.12.3-3
ii  libkf5messagelist5   4:17.12.3-3
ii  libkf5messageviewer5 4:17.12.3-3
ii  libkf5mime5abi1  17.12.3-2
ii  libkf5mimetreeparser54:17.12.3-3
ii  libkf5notifications5 5.49.0-1
ii  libkf5notifyconfig5  5.49.0-1
ii  libkf5parts5 5.49.0-1
ii  libkf5pimcommon5abi1 4:17.12.3-1
ii  libkf5pimcommonakonadi5  4:17.12.3-1
ii  libkf5pimtextedit5abi1   17.12.3-2
ii  libkf5sendlater5 4:17.12.3-1
ii  libkf5service-bin5.49.0-1
ii  libkf5service5   5.49.0-1
ii  libkf5sonnetui5  5.49.0-1
ii  libkf5templateparser54:17.12.3-3
ii  libkf5textwidgets5   5.49.0-1
ii  libkf5tnef5  4:17.12.3-1
ii  libkf5wallet-bin 5.49.0-1
ii  libkf5wallet55.49.0-1
ii  libkf5webengineviewer5   4:17.12.3-3
ii  libkf5widgetsaddons5 5.49.0-1
ii  libkf5windowsystem5  5.49.0-1
ii  libkf5xmlgui55.49.0-1
ii  libqgpgme7   1.11.1-1
ii  libqt5core5a 5.11.1+dfsg-9
ii  libqt5dbus5  5.11.1+dfsg-9
ii  libqt5gui5   5.11.1+dfsg-9
ii  libqt5network5   5.11.1+dfsg-9
ii  libqt5widgets5   5.11.1+dfsg-9
ii  libqt5xml5   5.11.1+dfsg-9
ii  libstdc++6   8.2.0-7

Versions of packages kmail recommends:
ii  accountwizard   4:17.12.3-1
ii  gnupg   2.2.10-1
ii  kdepim-addons   17.12.3-2
ii  kdepim-themeeditors 4:17.12.3-1
ii  mbox-importer   4:17.12.3-1
ii  pim-data-exporter   4:17.12.3-1
ii  pim-sieve-editor4:17.12.3-1
ii  pinentry-qt [pinentry-x11]  1.1.0-1+b1

Versions of packages kmail suggests:
pn  clamav 
ii  kaddressbook   4:17.12.3-1
pn  kleopatra   

Bug#908420: Buster: KVIrc forgets to use settings folder from previous installation

[local10]

The issue is still present for me. Anyone? Thanks

Bug#908575: Fwd: Buster: Firefox-esr: spell checker does not work?

[local10]

After the latest "aptitude safe-upgrade" the issue seems to have resolved 
itself so the bug can be closed.

Bug#898969: dnssec-trigger: fails with OpenSSL in experimental due to too-small key

[Diane Trout]

On Mon, 2018-10-01 at 20:23 +0200, Lee Garrett wrote:
> Hi,
> 
> Any update on this bug? dnssec-trigger will be autoremoved due to
> this bug
> tomorrow. I'd like to see it in buster, though.



Ooops I forgot, Also does this bug impact unbound? I tried checking the
unbound maintainer scripts and they're not doing anything to handle
this case

What's 
sudo -s openssl x509 \
  -in /etc/dnssec-trigger/dnssec_trigger_control.pem  -text | \
  grep 'Public-Key'

Look like on an effected system?

On mine is 3072, and I don't seem to be impacted.

I'm guessing I can use that to determine if I need to regenerate the
key

The other option is to just delete the key and regenerate it on the
specific version upgrade.

What do others think
Diane


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

Bug#909754: dpkg -l now always pipes to less and ignores $COLUMNS

[Guillem Jover]

Hi!

On Fri, 2018-09-28 at 02:42:19 +1000, Craig Sanders wrote:
> Package: dpkg
> Version: 1.19.1

> This is exactly the opposite of how unix programs should behave - stdout
> goes to a tty unless redirected.  If a user **wants** to view the output of
> a program in a pager, then they can pipe it to less or whatever themselves.
> That's standard usage of the unix shell.  Hard-coding a program to always use
> a pager is wrong.

I also don't think historic Unix commands (CLI, not TUI) traditionally
truncate (in contrast to perhaps just adapting their output to it) to fit
the screen, TBH? And I had to agree this seems rather perplexing and can
catch people off-guard with the "data-loss".

> It also prevents dpkg's output from appearing in the scrollback buffer of
> terminal emulators because less (by default) switches to the alternate screen.

> This makes the output ugly and difficult to read on standard 80 column
> terminals because the output will now typically be longer than 80 columns
> wide.  In fact, it's ugly and difficult to read on any terminal width
> less than the widest possible output line - it's no longer an easily read
> one-line-per-entry table, but a jumbled multiple-lines-per-entry mess.

Indeed, I realized about the new default not being more clear just a
bit before the upload, when I recalled I've got -S on my LESS
environment. :)

> Looking through the changelog, this seems to be an attempt to "solve" #898603
> which was a non-problem that didn't need fixing.

I don't agree with this, I think the previous behavior was not a
really good default. I was expecting such change would make some
people unhappy, and had already some of the changes you propose in
mind to help with that (but not all!), but wanted to get 1.19.1 out
of the way and not block on these.

> There were already several methods available to that user to get the output
> they preferred.  They could have piped to cat (or 'less -S', or whatever)
> as they already knew how to do. or they could have set the COLUMNS variable
> before running dpkg, e.g.
> 
> $ COLUMNS=132 dpkg -l pkg1 pkg2 pkg3 ...

> or, at least, modify it to use a DPKG_PAGER environment variable (and maybe
> DPKG_PAGER_OPTIONS for overriding the pager's default options).
> 
> Better yet, make it configureable in /etc/dpkg/dpkg.cfg (I don't care what the
> default is as long as I can unset it or comment it out - without having to set
> it to cat)
> 
> or add a -w or --wide option to dpkg.  That would have been
> backwards-compatible with existing behaviour and expectations.

> or all of the above.

So, first, thanks for the constructive proposals! But I'd rather not
revert this change. I'm happy to implement anything sane people might
find useful to cope with such change. This includes the following
changes which I've started coding:

  * DPKG_PAGER (equivalent to PAGER, so it will accept arguments).
  * Set LESS (if unset) to something along the lines of -FRSXMQ, which
sould fix the clear-screen-problem, the ugly-output, and
blocking-on-pager-when-unnecessary.
  * New --no-pager option (that can be set in the config file, for
dpkg, although dpkq-query does not currently honor any config,
but I might need to implement something for the path mapping
options anyway in the future).
  * I could see perhaps a mode where the Description is omitted?
  * If you still want the truncating behavior, I could introduce it
back under a new option such as --width=fit-to-screen vs =auto vs
= or similar.

On Fri, 2018-09-28 at 11:40:38 +, Holger Levsen wrote:
> also, running eg 'dpkg -l dpkg' and then ending up in less is confusing
> and breaking >20y old habbits, and then I press 'q' and get exit code 1.

Ah! That's actually a bug, the process dies from a SIGPIPE, I'll fix
that.

On the backwards incompatible change, well, this part is human
interaction only, and while that might perhaps be one of the trickest
to get used to, I considered the pros and cons, and that several other
tools that produce lots of output (such as git) do that by default,
which seems rather convenient.

Thanks,
Guillem

Bug#906609: gnucash: FTBFS on mips/sid: Segmentation fault

[Dmitry Smirnov]

On Tuesday, 2 October 2018 12:22:18 AM AEST Chris Lamb wrote:
> Gentle ping on this? gnucash is not currently in testing (!).

Thanks for reminder. It's the lack of time, not lack of attention is the 
problem...

I've taken care of that problem and I'm planing to upload the updated package 
in about an hour or so...

-- 
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#906609: gnucash: FTBFS on mips/sid: Segmentation fault

[Dmitry Smirnov]

On Tuesday, 4 September 2018 3:08:03 AM AEST Bernhard Übelacker wrote:
> This macro WORDS_BIGENDIAN was maybe set by autotools in the past.
> But after the switch to cmake it looks like it has to
> to given to cmake at "configure" time.
> 
> Attached patch tries to append based on DEB_TARGET_ARCH_ENDIAN
> a cmake parameter to have that macro defined.

Thank you very much for your help and excellent analysis. 


> Unfortunately my mips VM is terrible slow and a mips qemu-user chroot
> is not reliable enough. Therefore I could not finish (yet) any build with
> this patch included.

Despite trying for many hours I could not make a bootable mips qemu image at 
all...

-- 
Best wishes,
 Dmitry Smirnov.

---

Criticism may not be agreeable, but it is necessary. It fulfils the same
function as pain in the human body. It calls attention to an unhealthy
state of things.
-- Winston Churchill


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

Bug#910053: RFS: btrfsmaintenance/0.4.2-1

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: normal

Hello Sven and dear mentors,

I am looking for a sponsor for my package "btrfsmaintenance"

Package name: btrfsmaintenance
Version : 0.4.2-1
URL : https://github.com/kdave/btrfsmaintenance
License : GPL-2

It builds this binary package:

  btrfsmaintenance - automate btrfs maintenance tasks on mountpoints or 
directories

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

  https://mentors.debian.net/package/btrfsmaintenance

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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/btrfsmaintenance/btrfsmaintenance_0.4.2-1.dsc

Alternatively, use this git repository:

  git clone https://salsa.debian.org/sten-guest/btrfsmaintenance.git
  # gbp will use the upstream tag to generate upstream tarball
  # alternatively generate it with -> git deborig

Changes since the last upload:

btrfsmaintenance (0.4.2-1) unstable; urgency=medium
   
  * New upstream version.  
  * README.Debian: Make various grammar and clarity fixes, add the 
reasoning behind the default policy, and also some essential tips that 
are not yet general knowledge. 
  * Drop patches which were merged upstream:   
- 0002-Import-patch-provided-by-SUSE-to-fix-CVE-2018-14722.patch   
- 0003-btrfs-defrag.sh-add-functions-library-to-fix-missing.patch  
   
 -- Nicholas D Steeves   Mon, 01 Oct 2018 21:38:04 -0400   
   
btrfsmaintenance (0.4.1-3) unstable; urgency=medium


Cheers,
Nicholas

Bug#909723: missing priority for source package

[Johannes Schauer]

Hi Daniel,

On Thu, 27 Sep 2018 13:39:14 +0200 Daniel Baumann 
 wrote:
> On 09/27/2018 01:28 PM, Johannes Schauer wrote:
> > I wonder though why Lintian didn't warn about it. Do you know?
> I don't, but imho it should: Eventhough only the more strict tool warn
> about it or fail to operate on source packages without a priority, it
> should not harm anyone else to add it.
> 
> I'll open a lintian bug about it.

Could you point me to the bug number?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#910044: mmdebstrap: problem with sources.list-style mirror parameter handling

[Johannes Schauer]

Hi Karsten,

Quoting Karsten Merker (2018-10-01 22:43:31)
> many thanks for creating mmdebstrap!  I'm using it for creating
> chroots for Debian-Ports architectures, where we need to pull the
> packages from two suites: unstable and unreleased.  While using
> mmdebstrap, I've stumbled over two issues.  Everything works fine
> when creating a sources.list, feeding it to mmdebstrap on stdin
> and having mmdebstrap automatically generate a tarball, i.e. 
> with something like
> 
>   echo -e "deb http://deb.debian.org/debian-ports/ sid main\ndeb 
> http://deb.debian.org/debian-ports/ unreleased main" | mmdebstrap 
> --architectures=riscv64 > /tmp/rv64-chroot.tar
> 
> The process fails when one tries to pass the mirrors on the
> commandline, though.  Due to the fact that there is more than one
> suite to use, the mirrors need to be passed in sources.list
> style, i.e. as "deb http:///debian-ports  main".
> 
> Running mmdebstrap with
> 
>   mmdebstrap --architectures=riscv64 sid /tmp/rv64-chroot "deb 
> http://deb.debian.org/debian-ports/ sid main" "deb 
> http://deb.debian.org/debian-ports/ unreleased main"
> 
> results in
> 
>   E: Malformed entry 1 in list file /tmp/rv64-chroot/etc/apt/sources.list 
> (URI parse)
>   E: The list of sources could not be read.
>   apt-get update failed at /usr/bin/mmdebstrap line 548.
>   # cat /tmp/rv64-chroot/etc/apt/sources.list
>   deb deb http://deb.debian.org/debian-ports/ sid main sid main
>   deb deb http://deb.debian.org/debian-ports/ unreleased main sid main
> 
> The manpage states:
> 
>   If a MIRROR option starts with "deb " or "deb-src " then it is
>   used as a one-line-style format entry for apt's sources.list
>   inside the chroot.  If a MIRROR option contains a "://" then it
>   is interpreted as a mirror URI and the apt line inside the chroot
>   is assembled as "deb [arch=A] B C D" where A is the host's native
>   architecture, B is the MIRROR, C is the given SUITE and D is the
>   components given via --components (defaults to "main").
> 
> It looks like the second part is applied unconditionally on
> all mirror parameters that contain a "://", although that should
> not happen if the mirror parameter starts with a "deb " or
> "deb-src " and thereby already constitutes a complete sources.list
> entry.

yes, that is a bug. The code was indeed wrongly first checking for :// even
though it should first check if the parameter starts with "deb " or "deb-src ".
Fixed here:

https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/bb2aa6e9fdbbf4723eacdaf5937a8855ff41509d

> Another thing that I have stumbled upon is that providing a sources.list on
> stdin only works when no target directory is provided on the commandline,
> i.e. when automatically creating a tarball. While
> 
>   echo -e "deb http://deb.debian.org/debian-ports/ sid main\ndeb 
> http://deb.debian.org/debian-ports/ unreleased main" | mmdebstrap 
> --architectures=riscv64 > /tmp/rv64-chroot.tar
> 
> works, the following doesn't:
> 
>   echo -e "deb http://deb.debian.org/debian-ports/ sid main\ndeb 
> http://deb.debian.org/debian-ports/ unreleased main" | mmdebstrap 
> --architectures=riscv64 sid /tmp/rv64-chroot
> 
> It results in
> 
>   I: riscv64 cannot be executed, falling back to qemu-user
>   I: automatically chosen mode: root
>   I: running apt-get update...
>   done
>   apt-get update didn't download anything at /usr/bin/mmdebstrap line 721.

This is actually a feature. In your second invocation, you didn't specify the
"MIRROR" argument. The docs say:

> If no MIRROR option is provided, http://deb.debian.org/debian is used.

In your first invocation, you also didn't specify the "SUITE" argument. The
docs say:

> If no SUITE was specified, then a single MIRROR "-" is added and thus the
> information of the desired suite has to come from standard input as part of a
> valid apt sources.list file.

So the implicit '-' as the mirror argument only works if there was no SUITE. If
you pass a SUITE, you need to explicitly tell it that you want to read the
mirror from stdin. This is to have compatibility with how debootstrap also just
uses deb.debian.org/debian as the mirror if the mirror argument is missing.

To make the cause of the problem more obvious, I'm now printing the content of
/etc/apt/sources.list in the chroot in case apt-get didn't download anything:

https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/1f13d0157bc8364ac491203a6a9156a78f6228a9

But we could turn this bug into a feature request of the following form:

If no MIRROR was provided *and* something was specified on standard input, then
don't use deb.debian.org/debian but use whatever was given on standard input
instead.

Or even more liberal:

If anything is provided on standard input and there is no '-' MIRROR argument,
then just append whatever is given on standard input to the apt sources.list
inside the chroot.

What do you think?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#910009: exim4-config: upgrade fails when trying to execute conffile difference visualizer

[Guillem Jover]

Control: severity -1 serious

Hi!

On Mon, 2018-10-01 at 14:47:09 +0200, Vincent Lefevre wrote:
> Control: reassign -1 dpkg 1.19.1
> Control: retitle -1 dpkg execs $PAGER with execvp instead of sh -c, yielding 
> upgrade failure

> As a summary, when a pager needs to be invoked (e.g. for the
> conffile difference visualizer), one gets an upgrade failure
> if $PAGER contains the program name + options, as specified
> by POSIX.

Nice catch! Thanks for the analysis.

> On 2018-10-01 14:12:20 +0200, Vincent Lefevre wrote:
> > On 2018-10-01 14:08:17 +0200, Vincent Lefevre wrote:
> > > A possible bug might be that $PAGER is run as a program name,
> > > instead of something like system(), which allows options.
> > 
> > Hmm... I can see in /usr/share/doc/dpkg/changelog.Debian.gz that
> > there have been pager-related changes in dpkg 1.19.1 (26 Sep 2018).
> > The bug might actually be there.
> 
> Indeed, after a quick look at the code (pager_spawn in lib/dpkg/pager.c
> and lib/dpkg/command.c code), this seems to be the case.

I've queued a patch fixing this, which I'll be uploding around
Wednesday with dpkg 1.19.2. Although this will temporarily get in
the way of making the pager presence detection harder, but I'll
improve that later on.

Thanks,
Guillem

Bug#881333: qtbase5-dev: Rebuild qtbase with OpenGL ES support for arm64

[Re4son]

Hi everyone,


On 26/09/18 01:05, Lisandro Damián Nicanor Pérez Meyer wrote:
> Hi everybody!
>
>
> Sure thing. I even wrote to you on IRC on #debian-devel but you might have 
> missed it.
>
> I want to stress a point here: in my reply below I might sound too negative, 
> but I have been struggling with this subject for at very least a couple of 
> years now. The big issue behind this is lack of proper data and industry 
> definitions in terms of what is the real trend behind all this.
I really appreciate your hard work on this topic Lisandro and I'm very
thankful for you agreeing to revisit this issue. I think there would be
a huge benefit implementing this change.

> That being said every data that can help us make a better decision will be 
> highly appreciated. 
I have compiled some data for us to work with:

https://github.com/Re4son/kali-gemini-multistrap-config/raw/files/Arm64List.xls

I'm currently working through this list to gauge the level of qt related
activities with these boards (column g).
So far I can't see much activity at all but I'm still going through the
forums of the more popular platforms. Could we start discussions with
the ones documented?
> I would disagree with that, specially with the use of QML, but the arm64 
> server scenario is definitely not a fully deployed one yet so there is lot of 
> room for changes.
>
> But I would *love* to have one more data point: how many of those boards 
> require the proprietary video card vendor's headers to be present at Qt build 
> time? Yes, some of them need to be present at qtbase's build time in order to 
> fully work (or even work at all).
>
> Take a look at [experimental's] qtbase build. Look for "QPA backends" → 
> "EGLFS 
> details". As you can see there is EGL support, but some vendors require 
> specific proprietary code to be present at build time. Even if it where not 
> proprietary they are self-excluding, ie, you can only pick one at a time.
>
> [experimental's] 
> 
>
> So the question is: if we do the switch, how many boards we will really 
> support? And actually, did the switch to EGL really served the other arm* 
> archs? That really depends on the number of bards that do not require 
> proprietary stuff around at build time.
Good point. Let's take a conservative approach and assume all. That
would still leave us with all arm64 boards being able to run KDE or LXQT.
People wanting to write their own window applications outside the actual
windowing system would still need to build qt for their own needs as
they had to in the past.
I haven't seen much evidence of people doing that. The few exceptions I
have found are building their own qtbase with EGLF support for their
platform.
Gauging the interest for a lightweight desktop environment on
https://www.armbian.com/ and having experienced LXQT on the gemini, I am
positive that this is going to be very well received and the combination
of choice in the future.
> Side note: I have just created #909579 to see if we can add Vulkan support 
> without breaking anything else.
>
>>> More objectively, Ubuntu did that switch two years ago and there have
>>> been no issues reported in launchpad as a result of it.
> This is not actually true. There's what I wrote above *and* the fact that 
> this 
> breaks API/ABI. How so? Well, EGL is not compatible with GLU/GLUT, on which 
> many Qt-based applications rely upon, see [glut].
>
> [glut] 
>
> Note that at the moment I was convinced to switch arm64 and we did know of 
> few 
> packages that had issues. That changed.

Also a good point, and a scary one, too.
I have done a scan of the activities in some of the board's forums and
couldn't find any indication that anyone is, or has been, developing or
running GLU applications on arm64.
I might be looking in the wrong corners of the Internet but it looks
currently very quiet in the arm64 space when it comes to qt.
I would need a few more days to check out the forums and IRC channels of
the popular boards to see what they are up to but we might have an
opportunity to get this over the line before people start putting some
serious effort into this space.


I understand that there is a considerable likelihood of something going
wrong, you have plenty of experience from the Ubuntu switch, but the
impact might be lower than last time.
I'm going out on a limb here, but:

- assuming that the uptake of qt on arm64 is currently very low
- GLU has been broken on armhf a few years ago already so people have
probably been driven away from it
- ?? Doesn't FreeGLUT offer support for GLES ?? I have to dig into that
a bit more

the impact on users may even be negligible compared to the benefit of
having a proper desktop environment on all arm64 boards and, if the
Gemini is a success, future arm64 handhelds.
Experiencing LXQT on thos

Bug#910052: RFH: mysql-workbench -- visual database modeling, administration and queuing tool

[Dmitry Smirnov]

Package: wnpp
Severity: normal
Control: affects -1 mysql-workbench

mysql-workbench is in crisis as I can not build the new upstream release from 
source any more. I'm lacking capacity and expertise required to address all 
the problems.

M-W 8.0.12 requires new package "libanrlr4c-dev" which is not provided by 
src:antlr4. Either ANTLR4 package should be updated to provide Cpp support or 
it might be introduced as a standalone package similar to "libantlr3c".

ANTLR4 might need update to version 4.7.1 as well.

I've dumped my draft packaging to 

  https://salsa.debian.org/debian/mysql-workbench/tree/experimental

in hope that someone might be able to take care of it.

-- 
Regards,
 Dmitry Smirnov.


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

Bug#910051: uwgi: fails to build with shellcheck 0.5.0

[Jeremy Bicha]

Source: uwsgi
Version: 2.0.17.1-7
Severity: serious
Tags: ftbfs

uwsgi fails to build from source with shellcheck 0.5.0. That version
hasn't built in Debian yet; I believe it's caught up in the ongoing
haskell transition.

You can see the build failure at
https://launchpad.net/ubuntu/+source/uwsgi/2.0.17.1-7/+build/15501460

A friend is working on a patch

Thanks,
Jeremy Bicha

Bug#910021: GNU wishes Debian not split out .els anymore

[積丹尼 Dan Jacobson]

reopen 910021
retitle 910021 GNU wishes Debian not split out .els anymore
thanks

> "GM" == Glenn Morris  writes:

GM> Emacs does not support installing without its .el files and makes no
GM> provision for it. It's something downstream distributions added back
GM> when disk space was an issue (I guess?). They get to keep all the pieces
GM> from the resulting breakage. :)
GM> Personally I think it should this separation should just go away.

GM> PS Red Hat got rid of this split years ago, and I would encourage Debian
GM> to follow suit; ref https://bugzilla.redhat.com/show_bug.cgi?id=1151652

Bug#701599: lightdm: bug is fixed in squeeze, please close

[Sergey Spiridonov]

Package: lightdm
Followup-For: Bug #701599

This bug is fixed, in stretch one can use systemd-oriented approach using udev 
and loginctl and multiseat works. Please close.

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

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

Versions of packages lightdm depends on:
ii  adduser3.115
ii  consolekit 0.4.6-6
ii  dbus   1.10.26-0+deb9u1
ii  debconf [debconf-2.0]  1.5.61
ii  libaudit1  1:2.6.7-2
ii  libc6  2.24-11+deb9u3
ii  libgcrypt201.7.6-2+deb9u3
ii  libglib2.0-0   2.50.3-2
ii  libpam-systemd 237-3~bpo9+1
ii  libpam0g   1.1.8-3.6
ii  libxcb11.12-1
ii  libxdmcp6  1:1.1.2-3
ii  lightdm-gtk-greeter [lightdm-greeter]  2.0.2-1
ii  lsb-base   9.20161125

Versions of packages lightdm recommends:
ii  xserver-xorg  1:7.7+19

Versions of packages lightdm suggests:
ii  accountsservice  0.6.43-1
ii  upower   0.99.4-4+b1
pn  xserver-xephyr   

-- Configuration Files:
/etc/lightdm/lightdm.conf changed [not included]

-- debconf information:
  lightdm/daemon_name: /usr/sbin/lightdm
* shared/default-x-display-manager: lightdm

Bug#910050: lightdm: high CPU usage (up to 100%) on partially configured multiseat

[Sergey Spiridonov]

Package: lightdm
Version: 1.18.3-5
Severity: normal
Tags: patch upstream

If one seat of multiseat setup is not configured properly, lightdm restarts
it in a endless loop, consuming up to 100% CPU and polluting logs.

Including a patch that adds half a second delay before a greeter restart.


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

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

Versions of packages lightdm depends on:
ii  adduser3.115
ii  consolekit 0.4.6-6
ii  dbus   1.10.26-0+deb9u1
ii  debconf [debconf-2.0]  1.5.61
ii  libaudit1  1:2.6.7-2
ii  libc6  2.24-11+deb9u3
ii  libgcrypt201.7.6-2+deb9u3
ii  libglib2.0-0   2.50.3-2
ii  libpam-systemd 237-3~bpo9+1
ii  libpam0g   1.1.8-3.6
ii  libxcb11.12-1
ii  libxdmcp6  1:1.1.2-3
ii  lightdm-gtk-greeter [lightdm-greeter]  2.0.2-1
ii  lsb-base   9.20161125

Versions of packages lightdm recommends:
ii  xserver-xorg  1:7.7+19

Versions of packages lightdm suggests:
ii  accountsservice  0.6.43-1
ii  upower   0.99.4-4+b1
pn  xserver-xephyr   

-- Configuration Files:
/etc/lightdm/lightdm.conf changed:
[LightDM]
logind-load-seats=true
[Seat:*]
[Seat:seat-1]
xserver-config=/etc/X11/xorg.conf.seat-1
[Seat:seat-2]
xserver-config=/etc/X11/xorg.conf.seat-2
xserver-command=/usr/local/bin/Xintel
[XDMCPServer]
[VNCServer]


-- debconf information:
* shared/default-x-display-manager: lightdm
  lightdm/daemon_name: /usr/sbin/lightdm
Description: fix high CPU usage on partially configured multiseat
 If one seat of multiseat setup is not configured properly, lightdm restarts
 it in a endless loop, consuming up to 100% CPU and polluting logs. This fix
 adds a half second delay before a greeter restart.
 .
 lightdm (1.18.3-5) experimental; urgency=medium
 .
   * debian/control:
 - add liblightdm-qt5-3-0 and liblightdm-qt5-3-dev (packaging bits imported
 from Ubuntu)closes: #871840
 - add build-dep on qtbase5-dev
 - move libraries to section libs
 - update standards version to 4.1.0
 - replace dh-systemd build-dep by a newer version of debhelper
   * debian/liblightdm-qt5-3-0.install and debian/liblightdm-qt5-3-dev.install
 added to ship relevant files to Qt5 library and development packages
   * debian/liblightdm-qt-dev.install:
 - narrow installation path to only cover Qt4 library.
   * debian/rules:
 - explicitly enable qt5 library
Author: Yves-Alexis Perez 
Bug-Debian: https://bugs.debian.org/871840

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: , 
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: 
Reviewed-By: 
Last-Update: 2018-10-01

--- lightdm-1.18.3.orig/src/seat.c
+++ lightdm-1.18.3/src/seat.c
@@ -1,3 +1,4 @@
+
 /*
  * Copyright (C) 2010-2011 Robert Ancell.
  * Author: Robert Ancell 
@@ -434,6 +435,20 @@ check_stopped (Seat *seat)
 }
 }
 
+
+static gboolean
+call_seat_switch_to_greater(gpointer data)
+{
+   Seat *seat = (Seat *)data;
+   if(!seat_switch_to_greeter(seat))
+   {
+   l_debug (seat, "Stopping; failed to start a greeter");
+   seat_stop (seat);
+   }
+   return FALSE;
+}
+
+
 static void
 display_server_stopped_cb (DisplayServer *display_server, Seat *seat)
 {
@@ -489,12 +504,9 @@ display_server_stopped_cb (DisplayServer
 active_session = seat_get_active_session (seat);
 if (!active_session || session_get_display_server (active_session) == 
display_server)
 {
-l_debug (seat, "Active display server stopped, starting greeter");
-if (!seat_switch_to_greeter (seat))
-{
-l_debug (seat, "Stopping; failed to start a greeter");
-seat_stop (seat);
-}
+   l_debug (seat, "Active display server 
stopped, starting greeter again after delay");
+  g_timeout_add(500, call_seat_switch_to_greater, (gpointer)seat); 

+
 }
 }
 

Bug#910015: message wrong

[積丹尼 Dan Jacobson]

It turns out this message is totally wrong.

It should just say "check your device for a permissions confirmation
screen."

(And no the user is not always online to be able to access web explanations.)

Bug#910049: linux-image-4.18.0-1-cloud-amd64: Please enable Amazon ENA NIC support

[Noah Meyerhans]

Package: linux-image-4.18.0-1-cloud-amd64
Version: 4.18.8-1
Severity: wishlist
Tags: patch
Control: affects -1 cloud.debian.org

The cloud variant of the kernel packages does not currently enable
CONFIG_ENA_ETHERNET, meaning it is not able to drive the network hardware
on modern AWS instances.

A patch for enabling this is attached. I have tested it with the linux
sources from stretch-backports on an AWS m5d instance and confirmed that
the ENA driver is properly enabled and functional.
--- /mnt/config.amd64_none_cloud-amd64  2018-10-01 20:47:28.803906526 +
+++ .config 2018-10-01 20:58:42.155319362 +
@@ -4,7 +4,7 @@
 #
 
 #
-# Compiler: gcc-6 (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
+# Compiler: gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
 #
 CONFIG_64BIT=y
 CONFIG_X86_64=y
@@ -57,6 +57,7 @@
 # CONFIG_COMPILE_TEST is not set
 CONFIG_LOCALVERSION=""
 # CONFIG_LOCALVERSION_AUTO is not set
+CONFIG_BUILD_SALT=""
 CONFIG_HAVE_KERNEL_GZIP=y
 CONFIG_HAVE_KERNEL_BZIP2=y
 CONFIG_HAVE_KERNEL_LZMA=y
@@ -1935,7 +1936,8 @@
 # CONFIG_NET_VENDOR_ALACRITECH is not set
 # CONFIG_NET_VENDOR_ALTEON is not set
 # CONFIG_ALTERA_TSE is not set
-# CONFIG_NET_VENDOR_AMAZON is not set
+CONFIG_NET_VENDOR_AMAZON=y
+CONFIG_ENA_ETHERNET=m
 # CONFIG_NET_VENDOR_AMD is not set
 # CONFIG_NET_VENDOR_AQUANTIA is not set
 # CONFIG_NET_VENDOR_ARC is not set

Bug#909905: gradle FTBFS when building with openjdk-11 (needs update to 4.7.0 or upstream patch)

[shirish शिरीष]

at bottom :-

On 02/10/2018, Emmanuel Bourg  wrote:
> Le 01/10/2018 à 19:37, shirish शिरीष a écrit :
>
>> So are we going to have gradle 4.8 in either experimental or unstable
>> soonish.
>
> Unfortunately no. Starting with version 4.5 Gradle requires Kotlin, and
> we are nowhere near having Kotlin in Debian. It's more likely we'll
> instead patch Gradle 4.4 and fix the Java 11 incompatibilities.
>
>
>> I'm sure you may have read the freeze time-table which was shared few days
>> ago.
>>
>> It would be nice to have all the components in debian tested etc. well
>> before freeze.
>
> Sure but this won't happen magically, we need more contributors.
>
> Emmanuel Bourg
>

I can help with testing but that's all I can help with :(

I did see in the tracker though that the newer gradle isn't migrating towards
testing due to jgit which I didn't know was a package till I saw it -

tracker.debian.org/gradle

I also saw https://bugs.debian.org/905547 which is a wishlist bug for
getting a new version of jgit also which is one of the blockages of
transitioning to testing.

I am open to testing that as well  . I did see that the recent commits
to jgit-cli and brethen were on 5th august last ,

~/games/eclipse-jgit$ git log
commit 609ea8c723cba1584f75cef8dc8378e9206cd4bd (HEAD -> master,
origin/master, origin/HEAD)
Author: Emmanuel Bourg 
Date:   Thu Aug 16 01:04:37 2018 +0200

Upload to unstable


and that's -

$ apt-cache policy jgit-cli
jgit-cli:
  Installed: (none)
  Candidate: 3.7.1-5
  Version table:
 3.7.1-5 100
100 http://deb.debian.org/debian unstable/main amd64 Packages

Looking forward to testing a new version of jgit assuming of course it
doesn't have
any complexities or additional package requirements as the newer
gradle seems to have.

-- 
  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#909851: meson fails: AttributeError: 'list' object has no attribute 'absolute_path'

[Jussi Pakkanen]

On Sat, Sep 29, 2018 at 6:36 PM Adrian Bunk  wrote:

> Package: meson
> Version: 0.48.0-1
> Severity: serious
> Control: affects -1 src:gnome-initial-setup src:file-roller

The fix for this is pending review upstream and will be in the next
point release:

https://github.com/mesonbuild/meson/pull/4308

Bug#910048: RFS: mwc/2.0.4-3

[Jörg Frings-Fürst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: sponsorship-requests
Severity: normal 

  Dear mentors,

  I am looking for a sponsor for my package "mwc"

   Package name: mwc
   Version : 2.0.4-3
   Upstream Author : Michael Till Beck 
   URL : https://github.com/Debianguru/MailWebsiteChanges
   License : GPL-2+, GPL-3+
   Section : utils

  It builds those binary packages:

mwc   - Powerful website-tracking tool

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

  https://mentors.debian.net/package/mwc


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

  dget -x https://mentors.debian.net/debian/pool/main/m/mwc/mwc_2.0.4-3.dsc

or 

  git https://jff.email/cgit/mwc.git/?h=release%2Fdebian%2F2.0.4-3



  Changes since the last upload:

  * Declare compliance with Debian Policy 4.2.1 (No changes needed).
  * Migrate to debhelper 11:
- Change debian/compat to 11.
- Bump minimum debhelper version in debian/control to >= 11.
  * debian/control:
- Switch Vcs-* to new loacation.
  * debian/copyright:
- Use secure URI.


  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+AHX8jUOrs1qzDuCfifPIyh0l0FAluymioACgkQCfifPIyh
0l0tvw/8DuMwPF9oWIapgWfYmzpcHSV03BojUtEv3pukjNqhmKSWXN6YbwbfZwH6
NG2i6i9UP4oKCVM0QyyxNp58+WU32LXazV3WQaUc+CIvikwUzhE65YxaFA3Txxc3
TpWa5j7jWbR8ihgs9WbhTpnd4pn/rO59yebUZWcguRGzGSIRlX4a6PtgeE3jTKmI
nxPqp2SleG6Mr4kl/vU4fvjz1WOc1aIEOsPdcl2m1cCm59nHV699v8AAd/M6b+WH
qf5R2HssvuoMUPGlqs5Z3ZK+7GFHpJQ479nRR0Y9ZdH4UnQ6BGhmL+bXgpm3FcfT
ycZqguPU9JwPOoRgrQ5+NIOw/kfCZJxld+UxoT2QF+7qK9tqCrJtEJqGqER1XUR/
XmSWy73wxtjjvmc8s3DUkEwuRV5MwrXY13VlO3C8h3ZY7w5Tr/dX/Gh1MhUBDrO3
tqgnJ7Q3Pxi62Z6Z+IzePrgLUB6TKjNz8JWZccgL0L5SMOb1slK+A6ScjwJ/Fkoa
aInvg3uA2ydeab7ZpP+LapX0ugPDIubobv++cX10ASyF1cB1ffYsIQCmGn4VKC9h
PkRxAFDtFlDi6moc8R35CK9pzcDdnIpOZ0Lmdl8EBNTj3h3f69xx31NK9ZzeAyG5
Iw6AgK8cPGigDE2qswL778ralyL+kEOxf5TGaX1GTT6od09IvM8=
=De2R
-END PGP SIGNATURE-

Bug#910017: Apparmor profile whitelist /etc/torrc.d/ and /usr/local/etc/torrc.d/

[Patrick Schleizer]

Any chance to get any entry by default pointing to something in
/usr/local such as

/usr/local/etc/tor/** r,

or so?

That would be very useful for Qubes, and Qubes-Whonix (since /usr/local
is persistent by default in TemplateBased AppVMs while /etc is not).

Even if Debian wouldn't parse any Tor config in /usr/local by default (I
wouldn't suggest it), having '/usr/local/etc/torrc.d/** r,' or so by
default would help a lot.

Wouldn't be any disadvantage for Debian (except for a single unused
apparmor line) and simpler for Qubes since extending an apparmor profile
as a distribution is unclean. (config-package-dev displace
/etc/apparmor.d/local/system_tor but not pretty.)

Bug#892453: therion: Please use 'pkg-config' to find FreeType 2

[Olly Betts]

Control: tags -1 + fixed-upstream

On Thu, Mar 08, 2018 at 10:52:30PM +1100, hugh.mcmas...@outlook.com wrote:
> If this bug is not resolved prior to the release of FreeType 2.9.1,
> your package may FTBFS.

Therion upstream recently fixed this in git master:

https://github.com/therion/therion/issues/110

What's the likely timescale on FreeType 2.9.1 in unstable?  Wondering
if we can just pick up the change next time there's an upstream therion
release.

Cheers,
Olly

Bug#884635: transition: libupnp

[Marcelo Roberto Jimenez]

Hi,

Unfortunately, there is no porting guide. But the good news is that the new
API is pretty much straight forward and I can summarize it here. It is much
easier to use than it is to explain, but here it goes:

You no longer have pointers to data structures. All the pointers have been
substituted by handlers. This also means that you no longer de-reference
pointers, you use functions with meaningful names to access the fields.
That was done a long time ago to shield the applications using libupnp from
changes in the internal data structures, as well as allowing developers to
make changes to these structures without the need to release incompatible
libraries.

In the processes, several repetitive bug prone boiler plate code has been
replaced by those functions, which being defined as macro templates are no
longer subject to this type of mistakes. Just call the function and get
what you want.

All the magic is done in the files upnp/inc/TemplateSource.h and
upnp/inc/TemplateInclude.h. The technique is called x-macros (
https://en.wikipedia.org/wiki/X_Macro), and is as old as the first assembly
pre-processor. Together with some of the C preprocessor features, it works
like a C++ object. You have classes defined in source files like
ActionComplete.h, and the class definition is boiler plate. There are a
limited number of types that an object can have, like integer, string,
DOMString, buffer, list and object. The last is a handle to another object.
There are get and set methods for each member. Every class has a new(),
delete(), dup() and assign() methods.

Example. The class ActionComplete is defined like this:

#define CLASS UpnpActionComplete


#define EXPAND_CLASS_MEMBERS(CLASS) \

EXPAND_CLASS_MEMBER_INT(CLASS, ErrCode, int) \

EXPAND_CLASS_MEMBER_STRING(CLASS, CtrlUrl) \

EXPAND_CLASS_MEMBER_INT(CLASS, ActionRequest, IXML_Document *) \

EXPAND_CLASS_MEMBER_INT(CLASS, ActionResult, IXML_Document *) \


This creates the following methods:

UpnpActionComplete *UpnpActionComplete_new();
void UpnpActionComplete_delete(UpnpActionComplete *p);
UpnpActionComplete *UpnpActionComplete_dup(UpnpActionComplete *p);
UpnpActionComplete *UpnpActionComplete_assign(UpnpActionComplete *p, const
UpnpActionComplete *q);

For each INT member field:

int UpnpActionComplete_get_ErrCode(const UpnpActionComplete *p);
int UpnpActionComplete_set_ErrCode(const UpnpActionComplete *p, int n);

For STRING member fields:

const UpnpString *UpnpActionComplete_get_CtrlUrl(const UpnpActionComplete *p);

int UpnpActionComplete_set_CtrlUrl(CLASS *p, const UpnpString *s);

size_t UpnpActionComplete_get_CtrlUrl##_Length(const UpnpActionComplete *p);

const char *UpnpActionComplete_get_CtrlUrl##_cstr(const UpnpActionComplete *p);

int UpnpActionComplete_strcpy_CtrlUrl(UpnpActionComplete *p, const char *s);

int UpnpActionComplete_strncpy_CtrlUrl(UpnpActionComplete *p, const
char *s, size_t n);

void UpnpActionComplete_clear_CtrlUrl(UpnpActionComplete *p);


And so on.

There is only one class that is coded in C, and that is UpnpString, which
can be found in upnp/src/api/UpnpString.c and upnp/inc/UpnpString.h. There
you can see how the template generate code would look like.

If I can help further, please do contact me.

Best regards,
Marcelo.


On Sun, Sep 30, 2018 at 7:40 AM Uwe Kleine-König 
wrote:

> Hello,
>
> adding Marcelo (upstream for libupnp) to recipents.
>
>

Bug#909267: library-not-linked-against-libc: downgrade from error

[Jeremy Bicha]

Chris, see https://bugs.debian.org/896012

Thanks,
Jeremy Bicha

Bug#910047: RFS: ipmiutil/3.1.3-1

[Jörg Frings-Fürst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: sponsorship-requests
Severity: normal

Dear mentors,

  I am looking for a sponsor for my package "ipmiutil"

   Package name: ipmiutil
   Version : 3.1.3-1
   Upstream Author : Andy Cress 
   URL : https://sourceforge.net/projects/ipmiutil/
   License : BSD-2-clause, BSD-3-clause, GPL-2+,
 GPL-2+ with OpenSSL exception, Zlib, Artistic-2.0
   Section : utils

It builds those binary packages:

ipmiutil   - IPMI management utilities

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

  https://mentors.debian.net/package/ipmiutil


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

  dget -x 
https://mentors.debian.net/debian/pool/main/i/ipmiutil/ipmiutil_3.1.3-1.dsc

or

  git https://jff.email/cgit/ipmiutil.git/?h=release%2Fdebian%2F3.1.3-1



  Changes since the last upload:

  * New upstream release.
  * Declare compliance with Debian Policy 4.2.1 (No changes needed).


  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+AHX8jUOrs1qzDuCfifPIyh0l0FAluyjqkACgkQCfifPIyh
0l0Oyg/9EH3FSn+DGJTsN1t9xOsoSiOJB8jNUgk/s0JAGrPwT9zg3R2KKJlj4UMI
NOfR5oyhb8izxdU2fvlzXQoRV6804p00aGU7wl+eFOePF2VQXqUnb0ENyfPvbPIl
faFfBTVjEcF2+vYxb0O5AErXsFRU6u2TIj3WLJOpLFKGaqL1E/WNLL3dTuUyCv6Y
Vjauv+JzqpaB+5j2gJRQZ4lPxJdeFfaYZkqYpmDFXuQ+X9Eh/KSD55yCa2LR+Toh
1co/4iS+2WXivVWRIGIpA9KinamdV5VhdEsytrHNBwiCmo15mIdXm8qh5AURgLi4
aLhF9xOvrRPLg8k1tFT8Ky69XxuNewyu0yLjPoXvx8FTBeohkf3gcc0wvZ5/2udQ
VTUGuFOA2I2M/YqbfquGiYIH/iJmPKPoMJVWwnFOEixT3CMErCNqJfhBqIHfUaOd
t9AmfL97XdnZ3ACc7yw5LmF0MI+ggZk2xfcQ18A42wCWSmzxzjz6CF0FE3rYO6Z5
V7kEy0v9W3SxizC25UKrFz2hPa1H9JJ6aI1+O+yDJEq50YgXxVZ62vnKpdwuKYhp
2r/BUD5a+EIeP1z5QcnA/DJd00eGyxhUHml9viran+uOgZNLMCqDXqcT1Mze+u/W
ET8VgWaUHjReegbDcU2Hp8ArfPJbaXGCq2BaLcNdZJYeXhmkbqI=
=QVKM
-END PGP SIGNATURE-

Bug#909905: gradle FTBFS when building with openjdk-11 (needs update to 4.7.0 or upstream patch)

[Tiago Daitx]

Updated patch to include the missing DEP-3 headers and to remove the test files.
On Mon, Oct 1, 2018 at 9:52 PM Tiago Daitx  wrote:
>
> I have updated the patch to include 3 additional commits from
> upstream, this fixes the build with openjdk-11 and stops gradle from
> FTBFS.
>
> The last applied patch [1], which actually gets rid of the
> "NoSuchMethodError: sun.misc.Unsafe.defineClass" error, required me to
> remove the kotlin classes and then put the new classes under
> subprojets/base-services/ instead of subprojects/base-services-java9/
> in order to get them to compile - the logic of handling the
> subprojects has been moved to kotlin and I didn't check if there was a
> way to get it working with separated directories under gradle's 4.4
> build structure.
>
> For now I kept the openjdk-11 version check patch as it was
> originally, having the full JEP-223 might actually be a good thing - I
> will let the decision to someone who understands gradle better than I
> do.
>
> Of course, always bootstrap with openjdk-10 first, after that the
> generated binaries are good enough to get it to build with openjdk-11.
>
> [1] 
> debian/patches/use-lookup-instead-of-reflection-on-java-9-3db6e25698705317.patch
>
> On Mon, Oct 1, 2018 at 8:39 PM Emmanuel Bourg  wrote:
> >
> > Le 01/10/2018 à 19:37, shirish शिरीष a écrit :
> >
> > > So are we going to have gradle 4.8 in either experimental or unstable 
> > > soonish.
> >
> > Unfortunately no. Starting with version 4.5 Gradle requires Kotlin, and
> > we are nowhere near having Kotlin in Debian. It's more likely we'll
> > instead patch Gradle 4.4 and fix the Java 11 incompatibilities.
> >
> >
> > > I'm sure you may have read the freeze time-table which was shared few 
> > > days ago.
> > >
> > > It would be nice to have all the components in debian tested etc. well
> > > before freeze.
> >
> > Sure but this won't happen magically, we need more contributors.
> >
> > Emmanuel Bourg
> >
>
>
> --
> Tiago Stürmer Daitx
> Software Engineer
> tiago.da...@canonical.com
>
> PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
> Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE



-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE
diff -Nru gradle-4.4/debian/changelog gradle-4.4/debian/changelog
--- gradle-4.4/debian/changelog	2018-10-01 14:12:33.0 +0100
+++ gradle-4.4/debian/changelog	2018-10-01 20:05:23.0 +0100
@@ -1,3 +1,17 @@
+gradle (4.4-4) UNRELEASED; urgency=medium
+
+  * Enable support for openjdk-11 (Closes: #909905)
+- debian/patches/enable-jdk-11-support-ac15612d41b43c39c.patch:
+  enable support for openjdk-11.
+- d/p/use-lookup-to-invoke-defineclass-java-9-028548460bd929fd.patch:
+  Use Lookup to invoke defineClass on Java 9+.
+- d/p/do-not-use-classLoader-getdefinedpackages-on-java-9-50eababaa25230ab.patch:
+  Don't use ClassLoader.getDefinedPackages() on Java 9.
+- d/p/use-lookup-instead-of-reflection-on-java-9-3db6e25698705317.path:
+  Use Lookup instead of reflection on Java 9+.
+
+ -- Tiago Stürmer Daitx   Mon, 01 Oct 2018 21:12:00 +
+
 gradle (4.4-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru gradle-4.4/debian/patches/do-not-use-classLoader-getdefinedpackages-on-java-9-50eababaa25230ab.patch gradle-4.4/debian/patches/do-not-use-classLoader-getdefinedpackages-on-java-9-50eababaa25230ab.patch
--- gradle-4.4/debian/patches/do-not-use-classLoader-getdefinedpackages-on-java-9-50eababaa25230ab.patch	1970-01-01 01:00:00.0 +0100
+++ gradle-4.4/debian/patches/do-not-use-classLoader-getdefinedpackages-on-java-9-50eababaa25230ab.patch	2018-10-01 20:05:23.0 +0100
@@ -0,0 +1,149 @@
+Description: Don't use ClassLoader.getDefinedPackages() on Java 9
+ Prior to this change, FilteringClassLoader invokes
+ ClassLoader.getSystemClassLoader().getParent().getDefinedPackages()
+ to get all system packages on Java 9, which is not correct.
+ ClassLoader.getDefinedPackages() only fetches packages defined by
+ the ClassLoader itself, not including its parent's. The consequence is,
+ on Java 9, most Java SE and JDK packages (e.g. java.lang) are not included in
+ FilteringClassLoader.SYSTEM_PACKAGES.
+ 
+ This PR fixes this problem by using ClassLoader.getPackages() all the time.
+Origin: upstream, https://github.com/gradle/gradle/commit/50eababaa25230abc73899eda768dd0646ddcdb4
+Bug: https://github.com/gradle/gradle/pull/5477
+Bug-Debian: https://bugs.debian.org/909905
+Forwarded: not-needed
+Applied-Upstream: 50eababaa25230abc73899eda768dd0646ddcdb4
+Last-Update: 2018-10-01
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+
+From 50eababaa25230abc73899eda768dd0646ddcdb4 Mon Sep 17 00:00:00 2001
+From: Bo Zhang 
+Date: Wed, 23 May 2018 16:24:05 +0800
+Subject: [PATCH] Don't use ClassLoader.getDefinedPackages() on Java 9 (#5477)
+
+Prior

Bug#909942: mmdebstrap: breaks system it runs on, power cycle needed.

[Johannes Schauer]

Hi again,

On Mon, 01 Oct 2018 17:20:17 +0200 Johannes Schauer  wrote:
> I now added a commit that mounts a completely new sysfs when not running in
> unshare mode and doesn't use the --recursive when unmounting:
> 
> https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/640d854c2e0f139fdfbd60ddaffc5dfe72063fc0
> 
> If you are okay with that, I'd be happy if you could verify that after adding
> this patch, the problem indeed disappears.

and this commit should fix the unintended renaming of the source of the bind
mounts:

https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/6da8791c118b132feff51503182b7e8ce5dda48d


signature.asc
Description: signature

Bug#799626: RFP: beancount -- command line double-entry bookkeeping system

[Stefano Zacchiroli]

I've updated the package at
https://salsa.debian.org/python-team/applications/beancount to match
latest release (2.1.2) + mercurial snapshot and fixed one failing test.

Two tests still fail.

The corresponding functionalities work in the package after installed.

Also, they fail in very weird ways, only under python3.7, which are not
reproducible outside the package build environment.

I'm tempted to just push the attached patch to ignore the two tests and
upload. That will give us some user testing time before buster is frozen
and, when 3.7 become the default, reassess whether the tests still fail
or not.

Thoughts?
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »
From: Stefano Zacchiroli 
Date: Mon, 1 Oct 2018 22:58:39 +0200
Subject: ignore tests that fail with pytest 3.7 in a 3.6 environment

the tests runs fine outside the build process and the corresponding
functionalities work when the package is installed
---
 beancount/ingest/identify_test.py  | 2 ++
 beancount/scripts/tutorial_test.py | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/beancount/ingest/identify_test.py b/beancount/ingest/identify_test.py
index f6689da..2d37cb6 100644
--- a/beancount/ingest/identify_test.py
+++ b/beancount/ingest/identify_test.py
@@ -4,6 +4,7 @@ __license__ = "GNU GPLv2"
 from os import path
 from unittest import mock
 import os
+import pytest
 import re
 import subprocess
 import sys
@@ -72,6 +73,7 @@ class TestScriptIdentifyFunctions(test_utils.TestTempdirMixin, unittest.TestCase
 
 class TestScriptIdentify(scripts_utils.TestScriptsBase):
 
+@pytest.mark.skip
 def test_identify(self):
 regexp = textwrap.dedent("""\
 \*\*\*\* .*/Downloads/ofxdownload.ofx
diff --git a/beancount/scripts/tutorial_test.py b/beancount/scripts/tutorial_test.py
index e2b3e32..6dcb5c2 100644
--- a/beancount/scripts/tutorial_test.py
+++ b/beancount/scripts/tutorial_test.py
@@ -2,6 +2,7 @@ __copyright__ = "Copyright (C) 2014, 2016  Martin Blais"
 __license__ = "GNU GPLv2"
 
 import os
+import pytest
 import shutil
 import tempfile
 from os import path
@@ -12,6 +13,7 @@ from beancount.scripts import tutorial
 
 class TestTutorial(test_utils.TestCase):
 
+@pytest.mark.skip
 def test_generate_tutorial(self):
 rootdir = test_utils.find_repository_root(__file__)
 example_beancount = path.join(rootdir, 'examples', 'example.beancount')

Bug#909843: libfiu: frequent parallel FTBFS

[Chris Lamb]

tags 909843 + pending
thanks

Hi Alberto,


> >> https://blitiri.com.ar/git/r/libfiu/c/b4c21a6b2a714c1ad9cdfe96358f843688c3a77e/
> >
> >Still no way of getting a patch from the web interface, out of
> >interest?
> 
> Just implemented it :)

Applied & uploaded... Many thanks.


Best wishes,

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

Bug#909218: nvidia-xconfig: Files section missing ModulePath entries break GLX upon installing libgl1-nvidia-glx (required by Steam)

[Miguel Angel Vilela]

Please find logs attached.

It appears only an empty or missing xorg.conf will cause the issue with
xflock4.
I tried before a file with only the Files section, and today I tried also
with both sections (with-files) as well as without Files, and again and
empty xorg.conf

Thanks to you!
Miguel


On Sun, Sep 30, 2018 at 3:14 PM Andreas Beckmann  wrote:

> PS: can you repeat the xflock4 test with the working minimal xorg.conf,
> too? Including the sleep+stop trick, to produce a well matching logfile?
>
> Thanks,
>
> Andreas
>


-- 
There are 10 types of geeks: 1s and 0s.

X.Org X Server 1.20.1
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.9.0-7-amd64 x86_64 Debian
Current Operating System: Linux rapture 4.18.0-1-amd64 #1 SMP Debian 4.18.6-1 
(2018-09-06) x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.18.0-1-amd64 
root=UUID=7e47da94-60c7-43de-aa1b-8f2e4bf73be8 ro nomodeset net.ifnames=0 
biosdevname=0
Build Date: 17 August 2018  08:05:00PM
xorg-server 2:1.20.1-1 (https://www.debian.org/support) 
Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Mon Oct  1 22:54:18 2018
(==) Using config file: "/etc/X11/xorg.conf"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(==) No Layout section.  Using the first Screen section.
(==) No screen section available. Using defaults.
(**) |-->Screen "Default Screen Section" (0)
(**) |   |-->Monitor ""
(==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
(==) Automatically adding devices
(==) Automatically enabling devices
(==) Automatically adding GPU devices
(==) Max clients allowed: 256, resource mask: 0x1f
(WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
Entry deleted from font path.
(==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
(**) ModulePath set to "/usr/lib/xorg/modules/linux,/usr/lib/xorg/modules"
(II) The server relies on udev to provide the list of input devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
(II) Loader magic: 0x557345da3de0
(II) Module ABI versions:
X.Org ANSI C Emulation: 0.4
X.Org Video Driver: 24.0
X.Org XInput driver : 24.1
X.Org Server Extension : 10.0
(++) using VT number 7

(II) systemd-logind: logind integration requires -keeptty and -keeptty was not 
provided, disabling logind integration
(II) xfree86: Adding drm device (/dev/dri/card0)
(--) PCI:*(9@0:0:0) 10de:1b81:1043:8598 rev 161, Mem @ 0xf600/16777216, 
0xe000/268435456, 0xf000/33554432, I/O @ 0xd000/128, BIOS @ 
0x/131072
(II) LoadModule: "glx"
(II) Loading /usr/lib/xorg/modules/linux/libglx.so
(II) Module glx: vendor="NVIDIA Corporation"
compiled for 4.0.2, module version = 1.0.0
Module class: X.Org Server Extension
(II) NVIDIA GLX Module  390.87  Tue Aug 21 16:10:56 PDT 2018
(II) Applying OutputClass "nvidia" to /dev/dri/card0
loading driver: nvidia
(==) Matched nvidia as autoconfigured driver 0
(==) Matched nouveau as autoconfigured driver 1
(==) Matched nv as autoconfigured driver 2
(==) Matched modesetting as autoconfigured driver 3
(==) Matched fbdev as autoconfigured driver 4
(==) Matched vesa as autoconfigured driver 5
(==) Assigned the driver to the xf86ConfigLayout
(II) LoadModule: "nvidia"
(II) Loading /usr/lib/xorg/modules/drivers/nvidia_drv.so
(II) Module nvidia: vendor="NVIDIA Corporation"
compiled for 4.0.2, module version = 1.0.0
Module class: X.Org Video Driver
(II) LoadModule: "nouveau"
(II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so
(II) Module nouveau: vendor="X.Org Foundation"
compiled for 1.20.0, module version = 1.0.15
Module class: X.Org Video Driver
ABI class: X.Org Video Driver, version 24.0
(II) LoadModule: "nv"
(WW) Warning, couldn't open module nv
(EE) Failed to load module "nv" (module does not exist, 0)
(II) LoadModule: "modesetting"
(II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
(II) Module modesetting: vendor="X.Org Foundation"
compiled for 1.20.1, module version = 1.20.1
Module class: X.Org Video Driver
ABI class: X.Org Video Driver, version 24.0
(II) LoadModule: "fbdev"
(II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
(II) Module fbdev: vendor="X.Org Foundation"
compiled for 1.20.0, module version = 0.5.0
Module class: X.Org Video D

Bug#909905: gradle FTBFS when building with openjdk-11 (needs update to 4.7.0 or upstream patch)

[Tiago Daitx]

I have updated the patch to include 3 additional commits from
upstream, this fixes the build with openjdk-11 and stops gradle from
FTBFS.

The last applied patch [1], which actually gets rid of the
"NoSuchMethodError: sun.misc.Unsafe.defineClass" error, required me to
remove the kotlin classes and then put the new classes under
subprojets/base-services/ instead of subprojects/base-services-java9/
in order to get them to compile - the logic of handling the
subprojects has been moved to kotlin and I didn't check if there was a
way to get it working with separated directories under gradle's 4.4
build structure.

For now I kept the openjdk-11 version check patch as it was
originally, having the full JEP-223 might actually be a good thing - I
will let the decision to someone who understands gradle better than I
do.

Of course, always bootstrap with openjdk-10 first, after that the
generated binaries are good enough to get it to build with openjdk-11.

[1] 
debian/patches/use-lookup-instead-of-reflection-on-java-9-3db6e25698705317.patch

On Mon, Oct 1, 2018 at 8:39 PM Emmanuel Bourg  wrote:
>
> Le 01/10/2018 à 19:37, shirish शिरीष a écrit :
>
> > So are we going to have gradle 4.8 in either experimental or unstable 
> > soonish.
>
> Unfortunately no. Starting with version 4.5 Gradle requires Kotlin, and
> we are nowhere near having Kotlin in Debian. It's more likely we'll
> instead patch Gradle 4.4 and fix the Java 11 incompatibilities.
>
>
> > I'm sure you may have read the freeze time-table which was shared few days 
> > ago.
> >
> > It would be nice to have all the components in debian tested etc. well
> > before freeze.
>
> Sure but this won't happen magically, we need more contributors.
>
> Emmanuel Bourg
>


-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE
diff -Nru gradle-4.4/debian/changelog gradle-4.4/debian/changelog
--- gradle-4.4/debian/changelog	2018-10-01 14:12:33.0 +0100
+++ gradle-4.4/debian/changelog	2018-10-01 20:05:23.0 +0100
@@ -1,3 +1,17 @@
+gradle (4.4-4) UNRELEASED; urgency=medium
+
+  * Enable support for openjdk-11 (Closes: #909905)
+- debian/patches/enable-jdk-11-support-ac15612d41b43c39c.patch:
+  enable support for openjdk-11.
+- d/p/use-lookup-to-invoke-defineclass-java-9-028548460bd929fd.patch:
+  Use Lookup to invoke defineClass on Java 9+.
+- d/p/do-not-use-classLoader-getdefinedpackages-on-java-9-50eababaa25230ab.patch:
+  Don't use ClassLoader.getDefinedPackages() on Java 9.
+- d/p/use-lookup-instead-of-reflection-on-java-9-3db6e25698705317.path:
+  Use Lookup instead of reflection on Java 9+.
+
+ -- Tiago Stürmer Daitx   Mon, 01 Oct 2018 19:05:23 +
+
 gradle (4.4-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru gradle-4.4/debian/patches/do-not-use-classLoader-getdefinedpackages-on-java-9-50eababaa25230ab.patch gradle-4.4/debian/patches/do-not-use-classLoader-getdefinedpackages-on-java-9-50eababaa25230ab.patch
--- gradle-4.4/debian/patches/do-not-use-classLoader-getdefinedpackages-on-java-9-50eababaa25230ab.patch	1970-01-01 01:00:00.0 +0100
+++ gradle-4.4/debian/patches/do-not-use-classLoader-getdefinedpackages-on-java-9-50eababaa25230ab.patch	2018-09-29 21:25:43.0 +0100
@@ -0,0 +1,130 @@
+From 50eababaa25230abc73899eda768dd0646ddcdb4 Mon Sep 17 00:00:00 2001
+From: Bo Zhang 
+Date: Wed, 23 May 2018 16:24:05 +0800
+Subject: [PATCH] Don't use ClassLoader.getDefinedPackages() on Java 9 (#5477)
+
+Prior to this change, FilteringClassLoader invokes
+ClassLoader.getSystemClassLoader().getParent().getDefinedPackages()
+to get all system packages on Java 9, which is not correct.
+ClassLoader.getDefinedPackages() only fetches packages defined by
+the ClassLoader itself, not including its parent's. The consequence is,
+on Java 9, most Java SE and JDK packages (e.g. java.lang) are not included in
+FilteringClassLoader.SYSTEM_PACKAGES.
+
+This PR fixes this problem by using ClassLoader.getPackages() all the time.
+---
+ .../classloader/ClassLoaderUtils.java |  4 ++--
+ .../classloader/FilteringClassLoader.java | 22 +--
+ .../FilteringClassLoaderTest.groovy   |  6 +
+ .../fixtures/executer/LogContent.java |  2 +-
+ ...ConsoleJvmTestLoggingFunctionalTest.groovy |  3 ++-
+ 5 files changed, 17 insertions(+), 20 deletions(-)
+
+diff --git a/subprojects/base-services/src/main/java/org/gradle/internal/classloader/ClassLoaderUtils.java b/subprojects/base-services/src/main/java/org/gradle/internal/classloader/ClassLoaderUtils.java
+index 3995ad38be55..cdd68af5f905 100644
+--- a/subprojects/base-services/src/main/java/org/gradle/internal/classloader/ClassLoaderUtils.java
 b/subprojects/base-services/src/main/java/org/gradle/internal/classloader/ClassLoaderUtils.java
+@@ -39,7 +39,8 @@
+ 
+ static {
+ CLASS_DEFINER = JavaVersi

Bug#910046: python3-grpcio: consider building the Python bindings using the "grpc" source package

[Banpei-kun RX]

Package: python3-grpcio
Version: 1.15.0-1
Severity: normal

The GRPC github project managed by Google
(https://github.com/grpc/grpc) includes support for many languages
including Python. Tarballs generated from that project include support
for all those languages and are linked from the official page at
https://packages.grpc.io/ . This tarball is packaged as the "grpc"
Debian source package, though it hasn't seen a new upload to unstable
in over a year.

The grpcio tarball available from https://pypi.org/project/grpcio/ is
created from the same source, but has the non-Python bits removed (and
includes a few extras, like a copy of zlib/c-ares/openssl).

Two bugs (https://bugs.debian.org/871442 and
https://bugs.debian.org/908873 ) ask for Python support to be enabled
on the grpc source package. I'd guess they were asking for Python 2
bindings, but they might also be interested in the Python 3 bindings
provided by this package.

I'm not aware of any actual problems caused by the current situation,
but packaging the same source twice is unusual.

Bug#909584: ITA rapid-photo-downloader

[Antoine Beaupré]

On 2018-09-26 10:03:16, Antoine Beaupré wrote:
> On 2018-09-26 13:50:09, Dr. Tobias Quathamer wrote:
>> If you'd like to have the package, I'll retract my ITA, of course.
>
> No - the reason I got involved is because I use the package and just
> wanted to get it back into shape into Debian. I'd be more than happy to
> delegate the maintainership to someone who can take care of it.

Any update here? Still planning on maintaining this package?

A.

-- 
The world is a dangerous place, not because of those who do evil,
but because of those who look on and do nothing.
- Albert Einstein

Bug#910045: apertium-hbs-mkd parallel FTBFS

[Helmut Grohne]

Source: apertium-hbs-mkd
Version: 0.1.0~r76450-2
Severity: serious
Tags: ftbfs

apertium-hbs-mkd fails to build from source with sbuild on
unstable/amd64 when DEB_BUILD_OPTIONS is sufficiently parallel. A build
log ends with:

|dh_auto_build -O--fail-missing
| make -j8
| make[1]: Entering directory '/<>'
| make  all-am
| make[2]: Entering directory '/<>'
| xsltproc --stringparam alt hbs --stringparam var ijek alt.xsl 
apertium-hbs-mkd.hbs.metadix >apertium-hbs-mkd.hbs.dix 
| apertium-validate-dictionary apertium-hbs-mkd.mkd.dix
| xsltproc --stringparam alt hbs_BS --stringparam var ijek alt.xsl 
apertium-hbs-mkd.hbs.metadix >apertium-hbs-mkd.hbs_BS.dix
| xsltproc --stringparam alt hbs_HR --stringparam var ijek alt.xsl 
apertium-hbs-mkd.hbs.metadix >apertium-hbs-mkd.hbs_HR.dix
| xsltproc --stringparam alt hbs_SR --stringparam var ek alt.xsl 
apertium-hbs-mkd.hbs.metadix >apertium-hbs-mkd.hbs_SR.dix
| if [ ! -d .deps ]; then mkdir .deps; fi
| if [ ! -d .deps ]; then mkdir .deps; fi
| apertium-validate-dictionary apertium-hbs-mkd.mkd.dix
| mkdir: apertium-validate-dictionary apertium-hbs-mkd.hbs-mkd.dix
| cannot create directory ‘.deps’: File exists
| make[2]: *** [Makefile:829: mkd-hbs.autobil.bin] Error 1
| make[2]: *** Waiting for unfinished jobs
| apertium-hbs-mkd.mkd.dix:2484: element pardef: Schemas validity error : 
Element 'pardef': Duplicate key-sequence ['зн/ае__vblex'] in unique 
identity-constraint 'pardef-unique'.
| lt-comp lr apertium-hbs-mkd.mkd.dix mkd-hbs.automorf.bin
| apertium-hbs-mkd.mkd.dix:2484: element pardef: Schemas validity error : 
Element 'pardef': Duplicate key-sequence ['зн/ае__vblex'] in unique 
identity-constraint 'pardef-unique'.
| lt-comp lr apertium-hbs-mkd.hbs-mkd.dix hbs-mkd.autobil.bin
| lt-comp rl apertium-hbs-mkd.mkd.dix hbs-mkd.autogen.bin
| main@standard 14580 22636
| final@inconditional 161 815
| main@standard 12693 26012
| final@inconditional 161 792
| main@standard 12630 25786
| prefixes@standard 9 9
| make[2]: Leaving directory '/<>'
| make[1]: *** [Makefile:333: all] Error 2
| make[1]: Leaving directory '/<>'
| dh_auto_build: make -j8 returned exit code 2
| make: *** [debian/rules:9: build] Error 2
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

This is a race condition between the "if [ ! -d .deps ]; then mkdir
.deps; fi" commands. When both are executed simultaneously, both see
.deps as absent and try to create it.

Helmut

Bug#909843: libfiu: frequent parallel FTBFS

[Alberto Bertogli]

On Mon, Oct 01, 2018 at 10:34:51AM +0100, Chris Lamb wrote:

Hi Alberto,


I think this newly written patch fixes the problem:
https://blitiri.com.ar/git/r/libfiu/c/b4c21a6b2a714c1ad9cdfe96358f843688c3a77e/


Still no way of getting a patch from the web interface, out of
interest?


Just implemented it :)

Append ".patch" to the commit base path, like this:
https://blitiri.com.ar/git/r/libfiu/c/0d4f662733045f0e3f6e2936e94518cd4186129e.patch

Let me know if something doesn't work, I did this 5s ago so there could 
be bugs or issues.




I'm having a problem even getting this from the git
repository itself:

 $ git clone https://blitiri.com.ar/repos/libfiu
 $ cd libfiu
 $ git show b4c21a6b2a714c1ad9cdfe96358f843688c3a77e
 fatal: bad object b4c21a6b2a714c1ad9cdfe96358f843688c3a77e


Sorry, my bad. I rebased the branch afterwards (for unrelated reasons).

Try commit: 0d4f662733045f0e3f6e2936e94518cd4186129e

https://blitiri.com.ar/git/r/libfiu/c/0d4f662733045f0e3f6e2936e94518cd4186129e/
https://blitiri.com.ar/git/r/libfiu/c/0d4f662733045f0e3f6e2936e94518cd4186129e.patch

Thanks,
Alberto

Bug#910044: mmdebstrap: problem with sources.list-style mirror parameter handling

[Karsten Merker]

Package: mmdebstrap
Version: 0.1.0-2

Hello,

many thanks for creating mmdebstrap!  I'm using it for creating
chroots for Debian-Ports architectures, where we need to pull the
packages from two suites: unstable and unreleased.  While using
mmdebstrap, I've stumbled over two issues.  Everything works fine
when creating a sources.list, feeding it to mmdebstrap on stdin
and having mmdebstrap automatically generate a tarball, i.e. 
with something like

  echo -e "deb http://deb.debian.org/debian-ports/ sid main\ndeb 
http://deb.debian.org/debian-ports/ unreleased main" | mmdebstrap 
--architectures=riscv64 > /tmp/rv64-chroot.tar

The process fails when one tries to pass the mirrors on the
commandline, though.  Due to the fact that there is more than one
suite to use, the mirrors need to be passed in sources.list
style, i.e. as "deb http:///debian-ports  main".

Running mmdebstrap with

  mmdebstrap --architectures=riscv64 sid /tmp/rv64-chroot "deb 
http://deb.debian.org/debian-ports/ sid main" "deb 
http://deb.debian.org/debian-ports/ unreleased main"

results in

  E: Malformed entry 1 in list file /tmp/rv64-chroot/etc/apt/sources.list (URI 
parse)
  E: The list of sources could not be read.
  apt-get update failed at /usr/bin/mmdebstrap line 548.
  # cat /tmp/rv64-chroot/etc/apt/sources.list
  deb deb http://deb.debian.org/debian-ports/ sid main sid main
  deb deb http://deb.debian.org/debian-ports/ unreleased main sid main

The manpage states:

  If a MIRROR option starts with "deb " or "deb-src " then it is
  used as a one-line-style format entry for apt's sources.list
  inside the chroot.  If a MIRROR option contains a "://" then it
  is interpreted as a mirror URI and the apt line inside the chroot
  is assembled as "deb [arch=A] B C D" where A is the host's native
  architecture, B is the MIRROR, C is the given SUITE and D is the
  components given via --components (defaults to "main").

It looks like the second part is applied unconditionally on
all mirror parameters that contain a "://", although that should
not happen if the mirror parameter starts with a "deb " or
"deb-src " and thereby already constitutes a complete sources.list
entry.

Another thing that I have stumbled upon is that providing a
sources.list on stdin only works when no target directory is
provided on the commandline, i.e. when automatically creating a
tarball. While

  echo -e "deb http://deb.debian.org/debian-ports/ sid main\ndeb 
http://deb.debian.org/debian-ports/ unreleased main" | mmdebstrap 
--architectures=riscv64 > /tmp/rv64-chroot.tar

works, the following doesn't:

  echo -e "deb http://deb.debian.org/debian-ports/ sid main\ndeb 
http://deb.debian.org/debian-ports/ unreleased main" | mmdebstrap 
--architectures=riscv64 sid /tmp/rv64-chroot

It results in

  I: riscv64 cannot be executed, falling back to qemu-user
  I: automatically chosen mode: root
  I: running apt-get update...
  done
  apt-get update didn't download anything at /usr/bin/mmdebstrap line 721.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#908796: udev (with sysvinit) fails to find devices at boot

[Bill Brelsford]

On Mon Oct 01 2018 at 06:45 AM +0200, Trek wrote:
> to Bill Brelsford: please, can you try again if this new patch fixes the
> problem? thank you!

No -- $CTRLFILE must already be there as it doesn't sleep ($timeout
stays at 150).

(Even so, it worked consistently for a number of boots, then began
to fail consistently.  Strange.  Apparently it doesn't need much of
a pause, on my hardware anyway..)

Bug#866306: patch for haveged

[Vagrant Cascadian]

On 2018-09-19, Natanael Copa wrote:
> On Mon, 03 Sep 2018 13:57:17 -0700
> Vagrant Cascadian  wrote:
>> On 2018-09-03, Nicolas Braud-Santoni wrote:
>> > Could you confirm whether the patch solves the bug on your hardware?  
>> 
>> I'd be happy to try it out! Unfortunately, the patch sent to the debian
>> BTS is some xml representation of a patch; I'm not sure how to apply
>> it. Would it be possible to resend the patch in a more conventional
>> patch format?
>
> You can fetch[1] it from upstream pull request[2]. It would also be
> nice if you can give a comment there if it works or not.
>
> Thanks!
>
> [1]: https://patch-diff.githubusercontent.com/raw/jirka-h/haveged/pull/7.patch
> [2]: https://github.com/jirka-h/haveged/pull/7

Unfortunately, it didn't fix the issue for me. The workaround of passing
the --data=16 argument still does.

Maybe this is an entirely different issue you were experiencing? I'll
follow up on the pull request, too.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#910043: links2: misspelled options in help and man page

[Oliver Schode]

Package: links2
Version: 2.17-1
Severity: minor
Tags: upstream

Hi,

the following options as per man page and links2 -h

 -html-t-text-color <0>-<15>
  Text color in text mode.

 -html-t-link-color <0>-<15>
  Link color in text mode.

 -html-t-background-color <0>-<7>
  Background color in text mode.

 -html-t-ignore-document-color <0>/<1>
  Ignore colors specified in html document in text mode.

do not actually expect the -t- signifier, they once did probably. I
haven't looked into the sources, just found out by trial and luck,
apparently because I don't like the new default with yellow links too
much. ;) Never used these before, it's an older omission though, at least
2.14 has it, which is the version now packaged in Cygwin. Either way,
thanks a lot for keeping this current in Debian!

Oliver


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

Kernel: Linux 4.15.0-1-amd64 (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)
LSM: AppArmor: enabled

Versions of packages links2 depends on:
ii  libbrotli1  1.0.3-1
ii  libbz2-1.0  1.0.6-9
ii  libc6   2.27-5
ii  libcairo2   1.15.10-3
ii  libdirectfb-1.7-7   1.7.7-8
ii  libevent-2.1-6  2.1.8-stable-4
ii  libfontconfig1  2.13.1-1
ii  libgdk-pixbuf2.0-0  2.36.12-2
ii  libglib2.0-02.58.1-1
ii  libgomp18.2.0-4
ii  libgpm2 1.20.7-5
ii  libjpeg62-turbo 1:1.5.2-2+b1
ii  liblz1  1.10-1
ii  liblzma55.2.2-1.3
ii  libpng16-16 1.6.34-1
ii  librsvg2-2  2.40.20-2
ii  libssl1.1   1.1.1-1
ii  libtiff54.0.9-5
ii  libx11-62:1.6.6-1
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages links2 recommends:
ii  ca-certificates  20180409
ii  konsole [x-terminal-emulator]4:18.04.0-1
ii  qterminal [x-terminal-emulator]  0.9.0-3
ii  xterm [x-terminal-emulator]  337-1

links2 suggests no packages.

-- no debconf information

Bug#910037:

[Ken Dreyer]

Note that modern versions of "patch" already do symlink protection.

I think this means you could drop this "-l" check in Patch.pm.

>From http://git.savannah.gnu.org/cgit/patch.git/tree/NEWS ...

Changes in version 2.7.5:

* There are users which expect patch to follow symbolic links in the working
  directory, so patch now again follows symbolic links as long as they do not
  leave the working directory.

Changes until version 2.7.4:
...
* Patch no longer follows symbolic links to input and output files.  This
  ensures that symbolic links created by git-style patches cannot cause
  patch to write outside the working directory (CVE-2015-1196).

Bug#910042: afterburnr.fx FTBFS: compilation error

[Helmut Grohne]

Source: afterburner.fx
Version: 1.7.0-1
Severity: serious
Tags: ftbfs

afterburner.fx fails to build in sbuild for unstable/amd64. A build log
ends with:

|dh_auto_build
|   /usr/lib/jvm/default-java/bin/java -noverify -cp 
/usr/share/maven/boot/plexus-classworlds-2.x.jar -Dmaven.home=/usr/share/maven 
-Dmaven.multiModuleProjectDirectory=/<> 
-Dclassworlds.conf=/etc/maven/m2-debian.conf 
-Dproperties.file.manual=/<>/debian/maven.properties 
org.codehaus.plexus.classworlds.launcher.Launcher 
-s/etc/maven/settings-debian.xml -Ddebian.dir=/<>/debian 
-Dmaven.repo.local=/<>/debian/maven-repo package javadoc:jar 
javadoc:aggregate -DskipTests -Dnotimestamp=true -Dlocale=en_US
| WARNING: An illegal reflective access operation has occurred
| WARNING: Illegal reflective access by 
com.google.inject.internal.cglib.core.$ReflectUtils$1 
(file:/usr/share/maven/lib/guice.jar) to method 
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
| WARNING: Please consider reporting this to the maintainers of 
com.google.inject.internal.cglib.core.$ReflectUtils$1
| WARNING: Use --illegal-access=warn to enable warnings of further illegal 
reflective access operations
| WARNING: All illegal access operations will be denied in a future release
| [INFO] Scanning for projects...
| [WARNING] The POM for 
org.apache.maven.plugins:maven-install-plugin:jar:2.4 is missing, no dependency 
information available
| [WARNING] Failed to retrieve plugin descriptor for 
org.apache.maven.plugins:maven-install-plugin:2.4: Plugin 
org.apache.maven.plugins:maven-install-plugin:2.4 or one of its dependencies 
could not be resolved: Cannot access central 
(https://repo.maven.apache.org/maven2) in offline mode and the artifact 
org.apache.maven.plugins:maven-install-plugin:jar:2.4 has not been downloaded 
from it before.
| [WARNING] The POM for 
org.apache.maven.plugins:maven-deploy-plugin:jar:2.7 is missing, no dependency 
information available
| [WARNING] Failed to retrieve plugin descriptor for 
org.apache.maven.plugins:maven-deploy-plugin:2.7: Plugin 
org.apache.maven.plugins:maven-deploy-plugin:2.7 or one of its dependencies 
could not be resolved: Cannot access central 
(https://repo.maven.apache.org/maven2) in offline mode and the artifact 
org.apache.maven.plugins:maven-deploy-plugin:jar:2.7 has not been downloaded 
from it before.
| [WARNING] The POM for 
org.apache.maven.plugins:maven-site-plugin:jar:3.3 is missing, no dependency 
information available
| [WARNING] Failed to retrieve plugin descriptor for 
org.apache.maven.plugins:maven-site-plugin:3.3: Plugin 
org.apache.maven.plugins:maven-site-plugin:3.3 or one of its dependencies could 
not be resolved: Cannot access central (https://repo.maven.apache.org/maven2) 
in offline mode and the artifact 
org.apache.maven.plugins:maven-site-plugin:jar:3.3 has not been downloaded from 
it before.
| [WARNING] The POM for 
org.apache.maven.plugins:maven-antrun-plugin:jar:1.3 is missing, no dependency 
information available
| [WARNING] Failed to retrieve plugin descriptor for 
org.apache.maven.plugins:maven-antrun-plugin:1.3: Plugin 
org.apache.maven.plugins:maven-antrun-plugin:1.3 or one of its dependencies 
could not be resolved: Cannot access central 
(https://repo.maven.apache.org/maven2) in offline mode and the artifact 
org.apache.maven.plugins:maven-antrun-plugin:jar:1.3 has not been downloaded 
from it before.
| [WARNING] The POM for 
org.apache.maven.plugins:maven-assembly-plugin:jar:2.2-beta-5 is missing, no 
dependency information available
| [WARNING] Failed to retrieve plugin descriptor for 
org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5: Plugin 
org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5 or one of its 
dependencies could not be resolved: Cannot access central 
(https://repo.maven.apache.org/maven2) in offline mode and the artifact 
org.apache.maven.plugins:maven-assembly-plugin:jar:2.2-beta-5 has not been 
downloaded from it before.
| [WARNING] The POM for 
org.apache.maven.plugins:maven-dependency-plugin:jar:2.8 is missing, no 
dependency information available
| [WARNING] Failed to retrieve plugin descriptor for 
org.apache.maven.plugins:maven-dependency-plugin:2.8: Plugin 
org.apache.maven.plugins:maven-dependency-plugin:2.8 or one of its dependencies 
could not be resolved: Cannot access central 
(https://repo.maven.apache.org/maven2) in offline mode and the artifact 
org.apache.maven.plugins:maven-dependency-plugin:jar:2.8 has not been 
downloaded from it before.
| [WARNING] The POM for 
org.apache.maven.plugins:maven-release-plugin:jar:2.5.3 is missing, no 
dependency information available
| [WARNING] Failed to retrieve plugin descriptor for 
org.apache.maven.plugins:maven-release-plugin:2.5.3: Plugin 
org.apache.maven.plugins:maven-release-plugin:2.5.3 or

Bug#895765: How to announce commons.io in gradle build

[Andreas Tille]

Hi,

igv upstream has switched the build system to gradle and provides
specific java9 gradle input file.  I probably did not found the most
elegant way to choose this[1] but it should at least work.  I wonder
how I should announce common classes that are not found in

...
Compiling with JDK Java compiler API.
/build/igv-2.4.14+dfsg/src/main/java9/module-info.java:96: error: module not 
found: com.google.common
requires com.google.common;
   ^
/build/igv-2.4.14+dfsg/src/main/java9/module-info.java:97: error: module not 
found: commons.io
requires commons.io;
^
/build/igv-2.4.14+dfsg/src/main/java9/module-info.java:98: error: module not 
found: commons.math
requires commons.math;
^
/build/igv-2.4.14+dfsg/src/main/java9/module-info.java:100: error: module not 
found: gson
requires gson;
 ^
/build/igv-2.4.14+dfsg/src/main/java9/module-info.java:110: error: module not 
found: javafx.base
requires javafx.base;
   ^
/build/igv-2.4.14+dfsg/src/main/java9/module-info.java:111: error: module not 
found: javafx.controls
requires javafx.controls;
   ^
...

since I can not find these in the said *.gradle files and thus have no
idea how to replace the upstream delivered jar file by the Debian
packaged file.  The according Build-Depends are (hopefully) properly
set.

Kind regards

Andreas.

[1] 
https://salsa.debian.org/med-team/igv/commit/1fd85b5d63a43613ee39f7915278e35787438aa2

-- 
http://fam-tille.de

Bug#910041: aether-ant-tasks FTBFS: error: Can't rename /usr/share/java/commons-lang3.jar as /usr/share/java/commons-lang3.zbk Permission denied

[Helmut Grohne]

Source: aether-ant-tasks
Version: 1.0.1-2
Severity: serious
Tags: ftbfs

A native build of aether-ant-tasks with sbuild in unstable on amd64 ends
with:

|jh_classpath -O--buildsystem=maven
| error: Can't rename /usr/share/java/commons-lang3.jar as 
/usr/share/java/commons-lang3.zbk Permission denied 
|  at /usr/share/perl5/Archive/Zip/Archive.pm line 471.
| 
Archive::Zip::Archive::overwriteAs(Archive::Zip::Archive=HASH(0x55ba51fd0bf8), 
"/usr/share/java/commons-lang3.jar") called at 
/usr/share/perl5/Archive/Zip/Archive.pm line 439
| 
Archive::Zip::Archive::overwrite(Archive::Zip::Archive=HASH(0x55ba51fd0bf8)) 
called at /usr/bin/jh_manifest line 342
| main::update_jar("/usr/share/java/commons-lang3.jar", undef) called 
at /usr/bin/jh_manifest line 147
| jh_manifest: Writing modified jar (/usr/share/java/commons-lang3.jar) failed: 
Permission denied
| jh_classpath: jh_manifest -plibaether-ant-tasks-java --classpath=\\ 
/usr/share/java/commons-lang3.jar returned exit code 13
| make: *** [debian/rules:4: binary] Error 2
| dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned 
exit status 2

Helmut

Bug#907675: transition: x264

[Sebastian Ramacher]

On 2018-09-30 16:37:00, Niels Thykier wrote:
> Sebastian Ramacher:
> > On 2018-09-30 08:30:00, Niels Thykier wrote:
> >> Control: tags -1 confirmed pending
> >>
> >> Sebastian Ramacher:
> >>> On 2018-08-31 11:01:21, Sebastian Ramacher wrote:
>  Package: release.debian.org
>  Severity: normal
>  User: release.debian@packages.debian.org
>  Usertags: transition
>  Control: forwarded -1 
>  https://release.debian.org/transitions/html/auto-x264.html
>  Control: block -1 by 907659
> 
>  x264 bumped its SONAME and needs a transition. Besides opal (not in 
>  testing due
>  to another build failure, #896893), nageru is the only blocker 
>  (#907659). nageru
>  has a patch and the maintainer is looking at it.
> >>>
> >>> I've uploaded it to sid and it built everywhere. Please schedule the 
> >>> binNMUs. If
> >>> you need help, I'd be happy to them on my own.
> >>>
> >>> Cheers
> >>>
> >>
> >> I have scheduled binNMUs for this transition.  Please check up on them
> >> tomorrow and see if there are unexpected issues.
> > 
> > Thank you. Please give back ffmpeg with dep wait on libsdl2-dev >=
> > 2.0.8+dfsg1-3.1 (failed due to ##909778) and also schedule the binNMUs for
> > nageru.
> > 
> > Cheers
> > 
> 
> Done.

Thanks, everything was built successfully.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#833268: closed by Holger Wansing (task-lxde-desktop: LXDE desktop does not include a web browser)

[Jonathan Dowland]

On Mon, Oct 01, 2018 at 09:06:39PM +0200, Holger Wansing wrote:

Sorry, but you mix-up several problems into one bugreport, which are all
completely unrelated to the tasksel package. There is nothing that can
be done against all this in tasksel.
So there need to be other packages to be found, to file this against.


I agree, src:tasksel is not where this should be filed or fixed.
Whichever LXDE package ships the actual shortcut icon to launch
x-www-browser would be the culprit package. I'm no more an LXDE
packaging expert now than I was when I filed this, two years ago,
but I will make another effort to find a more appropriate package
and reassign.


--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#909905: gradle FTBFS when building with openjdk-11 (needs update to 4.7.0 or upstream patch)

[Emmanuel Bourg]

Le 01/10/2018 à 19:37, shirish शिरीष a écrit :

> So are we going to have gradle 4.8 in either experimental or unstable soonish.

Unfortunately no. Starting with version 4.5 Gradle requires Kotlin, and
we are nowhere near having Kotlin in Debian. It's more likely we'll
instead patch Gradle 4.4 and fix the Java 11 incompatibilities.


> I'm sure you may have read the freeze time-table which was shared few days 
> ago.
> 
> It would be nice to have all the components in debian tested etc. well
> before freeze.

Sure but this won't happen magically, we need more contributors.

Emmanuel Bourg

Bug#909480: HTTP::Tiny tries to reuse closed connections

[Xavier]

Control: forwarded -1 https://github.com/chansen/p5-http-tiny/pull/117

Le 01/10/2018 à 21:21, Niko Tyni a écrit :
> ...
> On Sun, Sep 30, 2018 at 09:12:07AM +0200, Xavier wrote:
>> Sometimes, a closed connection isn't detected by HTTP::Tiny. To
>> reproduce the bug, use feersum sources:
>>
>> $ perl Makefile.PL && make
>> $ taskset -c 0 perl -I blib/lib -I blib/arch t/63*
>>
>> HTTP::Tiny tries to reuse a closed connection.
>>
>> This little patch fixes the problem:
>>
>> --- HTTP/Tiny.pm.orig2018-09-30 09:02:16.674730242 +0200
>> +++ HTTP/Tiny.pm 2018-09-30 09:02:43.274353687 +0200
>> @@ -647,6 +647,7 @@
>>  if ( $self->{keep_alive}
>>  && $known_message_length
>>  && $response->{protocol} eq 'HTTP/1.1'
>> +&& $self->connected
>>  && ($response->{headers}{connection} || '') ne 'close'
>>  ) {
>>  $self->{handle} = $handle;
> 
> Hi, thanks for digging into this. HTTP::Tiny is also separately
> packaged in libhttp-tiny-perl, and this needs to be fixed there
> first. Otherwise installing an unfixed libhttp-tiny-perl package
> could override a fixed version in perl-modules-5.26.
> 
> So cloning and blocking. Could you please take this upstream 
> (at https://github.com/chansen/p5-http-tiny/issues) yourself,
> assuming it's not been fixed between 0.70 and 0.76 ?

Hello,

done, thanks

Bug#833268: closed by Holger Wansing (task-lxde-desktop: LXDE desktop does not include a web browser)

[Holger Wansing]

Hi,

Holger Wansing  wrote:
> Hi,
> 
> Jonathan Dowland  wrote:
> > reopen 833268
> > found 833268 3.39
> > thanks
> > 
> > Hi Holger,
> > 
> > On Sun, Sep 30, 2018 at 07:03:09PM +, Debian Bug Tracking System wrote:
> > >Jonathan Dowland  wrote:
> > >> The resulting desktop does not have a graphical web browser installed.
> > >> www-browser is being provided by w3m. Clicking on the web browser in
> > >> LXDE results in a pop-up
> > >>
> > >>  "invalid desktop entry file: 
> > >> '/usr/share/applications/lxde-x-www-browser.desktop'
> > >
> > >This has been fixed in the meantime, lxde now recommends
> > >firefox-esr | firefox | www-browser, and recommends are installed by 
> > >default.
> > >
> > >So closing this bug.
> > 
> > Thanks for taking a look at this but you have misunderstood the bug
> > report. 
> 
> Maybe I tried to understand it as a bug against tasksel?

Ah wait, the bug title says it all:
"LXDE desktop does not include a web browser."

So I understood it all correctly? The problem in the title is indeed fixed.


Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#910040: Please consider packaging a new version >= 20180922, with support for gnome 3.30

[Víctor Cuadrado Juan]

Package: materia-gtk-theme
Version: 20180519-1
Severity: wishlist
Tags: upstream

Hello,

As one of your users, many thanks for maintaining materia-gtk-theme, it is nice
to use it every day.

Now that Gnome 3.30 is in Testing, it would be nice if materia-gtk-theme was
bumped to a version supporting it (particularly, supporting the pop-up for
volume).

Kind regards,
Víctor Cuadrado


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

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

Versions of packages materia-gtk-theme depends on:
ii  gnome-themes-extra3.28-1
ii  gtk2-engines-murrine  0.98.2-2
ii  libgtk-3-common   3.24.0-3
ii  libgtk2.0-common  2.24.32-3

materia-gtk-theme recommends no packages.

materia-gtk-theme suggests no packages.

-- no debconf information

Bug#884600: firefox-esr: Please package "feature" addons separately

[Jonas Smedegaard]

Control: tag -1 patch

Quoting Dmitry Mikhirev (2017-12-17 13:57:37)
> the firefox-esr package contains several addons installed under
> /usr/lib/firefox-esr/browser/features/:
> 
> /usr/lib/firefox-esr/browser/features/aushel...@mozilla.org.xpi
> /usr/lib/firefox-esr/browser/features/e10sroll...@mozilla.org.xpi
> /usr/lib/firefox-esr/browser/features/fire...@getpocket.com.xpi
> /usr/lib/firefox-esr/browser/features/webcom...@mozilla.org.xpi
> 
> Those addons are not required for normal browser operation and slow it down.
> Please make it possible to remove them by splitting them into separate
> packages. The main firefox-esr package may still recommend them to keep them
> installed by default, but it shouldn't have a strong dependency on them.

PureOS, a downstream distribution derived from Debian, ships with these 
feature addons removed.

Here's the patch: 
https://source.puri.sm/pureos/packages/firefox-esr/commit/c7c70af

That should be easily adapted to instead install as separate packages, 
either recommended or suggested by firefox.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#909984: ITP: vaapi-media-driver -- VA-API driver for Intel Gen8+ graphic cards

[Sebastian Ramacher]

On 2018-10-01 08:27:14, Bastian Blank wrote:
> On Mon, Oct 01, 2018 at 12:16:49AM +0200, Sebastian Ramacher wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Sebastian Ramacher 
> > Control: block -1 by 909983
> > 
> > * Package name: vaapi-media-driver
> >   Version : 18.2.0
> >   Upstream Author : Intel Corporation
> > * URL : https://github.com/intel/media-driver
> > * License : (GPL, LGPL, BSD, MIT/X, etc.)
> >   Programming Lang: (C, C++, C#, Perl, Python, etc.)
> 
> Please actually fill out these values.

I thought I did, but seem's only filled them for gmmlib. So here they are:

* License : Expat and BSD-3-clause
  Programming Lang: C++

> 
> >   Description : VA-API driver for Intel Gen8+ graphic cards
> > 
> > VA-API driver for BDW, SKL, BXT, APL, KBL, CF, CNL, ICL chips. This driver 
> > will
> > replace i965-va-driver for those chips.
> 
> Can you please not use (internal?) abbreviations of code names?  From
> this description I could not tell if I want it, even if I own Intel
> chips of multiple generations.

Sure, those are:

* Broadwell
* Skylake
* Broxton
* Apollo Lake
* Kaby Lake
* Coffee Lake
* Cannonlake
* Ice Lake

I'll use the full code names in the description.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#909480: HTTP::Tiny tries to reuse closed connections

[Niko Tyni]

Control: clone -1 -2
Control: reassign -1 libhttp-tiny-perl 0.070-1
Control: block -1 with -2

On Sun, Sep 30, 2018 at 09:12:07AM +0200, Xavier wrote:
> Control: severity -1 normal
> Control: tags -1 + patch
> Control: reassign -1 perl-modules-5.26
> 
> Sometimes, a closed connection isn't detected by HTTP::Tiny. To
> reproduce the bug, use feersum sources:
> 
> $ perl Makefile.PL && make
> $ taskset -c 0 perl -I blib/lib -I blib/arch t/63*
> 
> HTTP::Tiny tries to reuse a closed connection.
> 
> This little patch fixes the problem:
> 
> --- HTTP/Tiny.pm.orig2018-09-30 09:02:16.674730242 +0200
> +++ HTTP/Tiny.pm 2018-09-30 09:02:43.274353687 +0200
> @@ -647,6 +647,7 @@
>  if ( $self->{keep_alive}
>  && $known_message_length
>  && $response->{protocol} eq 'HTTP/1.1'
> +&& $self->connected
>  && ($response->{headers}{connection} || '') ne 'close'
>  ) {
>  $self->{handle} = $handle;

Hi, thanks for digging into this. HTTP::Tiny is also separately
packaged in libhttp-tiny-perl, and this needs to be fixed there
first. Otherwise installing an unfixed libhttp-tiny-perl package
could override a fixed version in perl-modules-5.26.

So cloning and blocking. Could you please take this upstream 
(at https://github.com/chansen/p5-http-tiny/issues) yourself,
assuming it's not been fixed between 0.70 and 0.76 ?
-- 
Niko

Bug#908398: firefox-esr: Browsing history leak after 60.2 upgrade

[Jonas Smedegaard]

Quoting Tuxicoman (2018-10-01 19:40:23)
> Do you have any more info ?
> This looks related to Firefox rather than Debian. So it should be
> reproducible elsewhere. Is there any study on this behavior so that we
> can know which part of the code is responsible of this behavior ?

This is likely (at least in part) the redesigned start page, driven by 
feature addon "Activity Stream".

Upstream consider Activity Streams a feature, not a bug - see e.g. 
https://github.com/mozilla/activity-stream/issues/2306

Feature addons are addons shipped with Firefox - again considered a 
feature upstream, separable, see https://bugs.debian.org/884600


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#909935: Now the developer says it looks like a bug

[Kingsley G. Morse Jr.]

Gnumeric's developer dug a little deeper, and wrote

"For some reason Gnumeric thinks your symbols
differ only in case. That looks like a bug."

So,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#833268: closed by Holger Wansing (task-lxde-desktop: LXDE desktop does not include a web browser)

[Holger Wansing]

Hi,

Jonathan Dowland  wrote:
> reopen 833268
> found 833268 3.39
> thanks
> 
> Hi Holger,
> 
> On Sun, Sep 30, 2018 at 07:03:09PM +, Debian Bug Tracking System wrote:
> >Jonathan Dowland  wrote:
> >> The resulting desktop does not have a graphical web browser installed.
> >> www-browser is being provided by w3m. Clicking on the web browser in
> >> LXDE results in a pop-up
> >>
> >>"invalid desktop entry file: 
> >> '/usr/share/applications/lxde-x-www-browser.desktop'
> >
> >This has been fixed in the meantime, lxde now recommends
> >firefox-esr | firefox | www-browser, and recommends are installed by default.
> >
> >So closing this bug.
> 
> Thanks for taking a look at this but you have misunderstood the bug
> report. 

Maybe I tried to understand it as a bug against tasksel?

> www-browser was satisfied at the time, by w3m, which does not
> provide x-www-browser (and there's no assertion anywhere that Provides:
> www-browser means ships an alternative for x-www-browser)
> 
> The problem is there doesn't seem to be something like "x-www-browser"
> virtual package name corresponding to the alternatives name. Chromium,
> firefox, firefox-esr and epiphany provide "gnome-www-browser" which is
> close, but obviously excludes (e.g.) konqueror, which merely provides
> "info-browser, man-browser, www-browser".
> 
> The proper fix here, distribution wide, is to rationalise the virtual
> package names for GUI browser packages. (A starting point might be to
> post about the issue to -desktop, and I might do that.)
> 
> But for LXDE, the issue would also not occur if taskbar icons
> configured to point at not-existent .desktop URIs were not drawn or
> de-configured on session start-up.

Sorry, but you mix-up several problems into one bugreport, which are all
completely unrelated to the tasksel package. There is nothing that can
be done against all this in tasksel.
So there need to be other packages to be found, to file this against.


Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#910038: python3-rpyc: did not build

[Matthias Urlichs]

Package: python3-rpyc
Version: 4.0.2-2
Severity: important

rpyc 4.0.2-2 has been uploaded on September 6th. It is now October 1st,
there still are no binary packages in the archive => FTBFS? => please fix.

-- System Information:
Debian Release: buster/sid
  APT prefers stable
  APT policy: (800, 'stable'), (750, 'testing'), (700, 'unstable'), (650, 
'oldstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.17.0-1-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)

Versions of packages python3-rpyc depends on:
ii  python3  3.6.5-3

Versions of packages python3-rpyc recommends:
pn  python3-paramiko  

Versions of packages python3-rpyc suggests:
pn  python-rpyc-doc  

-- no debconf information

Bug#910037: dpkg-source does not permit patches to change destinations of symlinks

[Ken Dreyer]

Package: dpkg
Version: 1.18.4ubuntu1.4
Severity: normal

scripts/Dpkg/Source/Patch.pm has the following code:

while (1) {
if (-l $path) {
error(g_('diff %s modifies file %s through a symlink: %s'),
  $diff, $fn{$key}, $path);
}

$diff is a patch file in debian/patches/*.patch.
$path is the path within package's source tree.

The idea here is to prevent dpkg from ever overwriting files from outside the
source tree (CVE-2010-1679).

This protection is overly-broad, because I cannot modify any files that happen
to be symlinks at all. In particular I want to create a debian .patch file that
updates the destination of a symlink in my package's tree.

If I use git-buildpackage to manage my changes in a patch-queue branch,
"git-buildpackage pq export" will generate debian .patches that update symlink
destinations, but then dpkg-source cannot process these .patch files.


-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.8-200.fc28.x86_64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.6-8
ii  libc62.23-0ubuntu10
ii  liblzma5 5.1.1alpha+20120614-2ubuntu2
ii  libselinux1  2.4-3build2
ii  tar  1.28-2.1ubuntu0.1
ii  zlib1g   1:1.2.8.dfsg-2ubuntu4.1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt  1.2.27

-- no debconf information

Bug#909983: ITP: gmmlib -- graphics memory management library

[Sebastian Ramacher]

Hi Timo

On 2018-10-01 09:01:30, Timo Aaltonen wrote:
> On 01.10.2018 01:12, Sebastian Ramacher wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Sebastian Ramacher 
> > 
> > * Package name: gmmlib
> >   Version : 18.3.0
> >   Upstream Author : Intel Corporation, Gabi Melman
> > * URL : https://github.com/intel/gmmlib
> > * License : Expat
> >   Programming Lang: C++
> >   Description : graphics memory management library
> > 
> > The Intel Graphics Memory Management Library provides device specific and
> > buffer management for the Intel Graphics Compute Runtime for OpenCL and
> > the Media Driver for VAAPI.
> > 
> > Upcoming dependency of VAAPI driver implementation for Gen8+ graphic cards.
> 
> FYI, I've packaged this (without an ITP I know..), but didn't know
> whether to put it under xorg-team/lib or elsewhere. So I pushed it here
> for now, use it or leave it:
> 
> https://salsa.debian.org/tjaalton/intel-gmmlib

I don't have any strong feeling regarding maintainership of gmmlib. If you want
to take it over -- as you already have packaged it -- please go ahead. We can
also co-maintain it under the multimeida team umbrella.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#898969: dnssec-trigger: fails with OpenSSL in experimental due to too-small key

[Lee Garrett]

Hi,

Any update on this bug? dnssec-trigger will be autoremoved due to this bug
tomorrow. I'd like to see it in buster, though.

Regards,
Lee

Bug#907491: closed by Paul Gevers (Re: goobook fails to authenticate)

[Sergio Mendoza]

Hi Ilias,

  Today I performed a dist-upgrade and things are back to normal.  goobook
runs fine as it should.  Hope it doesn't go wrong again.

Cheers,

Sergio.

-- 
Sergio Mendoza  
Instituto de Astronomia, UNAM
http://www.mendozza.org/sergio
On Mon, Sep 24, 2018 at 09:19:49AM -0500, Sergio Mendoza wrote:
> Hi Ilias,
> 
>   Nope.  It's not python-httplib2.  Can't find what can it be:
> 
> 
> root@izta:~# pip uninstall python-httplib2
> Cannot uninstall requirement python-httplib2, not installed
> root@izta:~# dpkg -l python-httplib2
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name   Version  Architecture Description
> +++-==---==
> ii  python-httplib 0.11.3-1 all  comprehensive HTTP client library
> root@izta:~# ls -l /usr/lib/python2.7/dist-packages/httplib2/
> total 180
> -rw-r--r-- 1 root root 73431 Sep  5 01:45 __init__.py
> -rw-r--r-- 1 root root 59427 Sep  9 13:05 __init__.pyc
> -rw-r--r-- 1 root root  3828 Mar 29 20:28 iri2uri.py
> -rw-r--r-- 1 root root  3786 Sep  9 13:05 iri2uri.pyc
> -rw-r--r-- 1 root root 18999 Mar 29 20:28 socks.py
> -rw-r--r-- 1 root root 17500 Sep  9 13:05 socks.pyc
> 
> 
> Cheers,
> 
> Sergio.
> 
> --
> Sergio Mendoza  
> Instituto de Astronomia, UNAM
> http://www.mendozza.org/sergio
> 
> 
> 
> 
> On Sat, Sep 22, 2018 at 02:36:45PM +0300, Ilias Tsitsimpis wrote:
> > Hi again,
> > 
> > On Fri, Sep 21, 2018 at 01:46PM, Sergio Mendoza wrote:
> > >   Unfortunately, no matter how hard I look for to spot the problem, I have
> > > not find the culprit package.  I tried and tried, but couldn't.  This is
> > > the reason I reported the bug to goobook.  Sorry for not being more
> > > helpful.
> > > 
> > > > > sergio@izta:~$ goobook query sergio
> > > > > Traceback (most recent call last):
> > > > >   File "/usr/bin/goobook", line 11, in 
> > > > > load_entry_point('goobook==1.9', 'console_scripts', 'goobook')()
> > > > >   File "/usr/share/goobook/goobook/application.py", line 94, in main
> > > > > args.func(config, args)
> > > > >   File "/usr/share/goobook/goobook/application.py", line 125, in 
> > > > > do_query
> > > > > goobk = GooBook(config)
> > > > >   File "/usr/share/goobook/goobook/goobook.py", line 59, in __init__
> > > > > self.cache.load()
> > > > >   File "/usr/share/goobook/goobook/goobook.py", line 257, in load
> > > > > self.update()
> > > > >   File "/usr/share/goobook/goobook/goobook.py", line 264, in update
> > > > > self.contacts = list(self._parse_contacts(gc.fetch_contacts()))
> > > > >   File "/usr/share/goobook/goobook/goobook.py", line 395, in 
> > > > > fetch_contacts
> > > > > res = self._get(query)
> > > > >   File "/usr/share/goobook/goobook/goobook.py", line 371, in _get
> > > > > connection_type=httplib2.HTTPSConnectionWithTimeout)
> > > > >   File 
> > > > > "/usr/local/lib/python2.7/dist-packages/oauth2client/client.py", line 
> > > > > 562, in new_request
> > > > > redirections, connection_type)
> > > > >   File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", 
> > > > > line 1608, in request
> > > > > (response, content) = self._request(conn, authority, uri, 
> > > > > request_uri, method, body, headers, redirections, cachekey)
> > > > >   File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", 
> > > > > line 1350, in _request
> > > > > (response, content) = self._conn_request(conn, request_uri, 
> > > > > method, body, headers)
> > > > >   File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", 
> > > > > line 1272, in _conn_request
> > > > > conn.connect()
> > > > >   File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", 
> > > > > line 1059, in connect
> > > > > raise SSLHandshakeError(e)
> > > > > httplib2.SSLHandshakeError: [SSL: CERTIFICATE_VERIFY_FAILED] 
> > > > > certificate verify failed (_ssl.c:726)
> > > > 
> > > > The above traceback mentions 
> > > > "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py".
> > > > This is not the canonical location where Debian Python packages get
> > > > installed. I believe you have installed a different version of the
> > > > httplib2 module using pip. Could you please test using the Python module
> > > > provided by the python-httplib2 package?
> > 
> > Please take a look at the comment above. It looks like you are not using
> > the official Debian package for python-httplib2, which is installed
> > under /usr/lib/python2.7/dist-packages/httplib2/ [1]. My guess is that
> > you have `pip install`-ed that package, so I would start by uninstalling
> > it and revert back to the Debian one.
> > 
> > [1] https://packages.debian.org/sid/all/python-httplib2/filelist
> > 
> > Cheers,
> > 
> > -- 
> > Ilias

Bug#909033: FIXED quickroute-gps: Map flicking makes software unusuable on X11

[Gautier Pelloux-Prayer]

I've fixed the problem by removing all mono packages and reinstall. I 
had a mix of mono 4 and mono 5 packages:



sudo aptitude purge '~imono'

sudo aptitude install quickroute-gps


Properly working with:


ii  libmono-accessibility4.0-cil 4.6.2.7+dfsg-2 all Accessibility 
library (for CLI 4.0)

ii  libmono-corlib4.5-cil 4.6.2.7+dfsg-2 all  core library (for CLI 4.5)
ii  libmono-csharp4.0c-cil 4.6.2.7+dfsg-2 all .CSharp library (for CLI 4.0)
ii  libmono-data-tds4.0-cil 4.6.2.7+dfsg-2 all  Data Library (for CLI 4.0)
ii  libmono-i18n-west4.0-cil 4.6.2.7+dfsg-2 all  I18N.West library (for 
CLI 4.0)

ii  libmono-i18n4.0-cil .6.2.7+dfsg-2 all  I18N base library (for CLI 4.0)
ii  libmono-ldap4.0-cil .6.2.7+dfsg-2 all  LDAP library (for CLI 4.0)
ii  libmono-microsoft-csharp4.0-cil 4.6.2.7+dfsg-2 all Microsoft.CSharp 
library (for CLI 4.0)

ii  libmono-posix4.0-cil .6.2.7+dfsg-2 all .Posix library (for CLI 4.0)
ii  libmono-security4.0-cil 4.6.2.7+dfsg-2 all  Security library (for 
CLI 4.0)

ii  libmono-sqlite4.0-cil 4.6.2.7+dfsg-2 all  Sqlite library (for CLI 4.0)
ii  libmono-system-componentmodel-dataannotations4.0-cil 4.6.2.7+dfsg-2 
all  System.ComponentModel.DataAnnotations library (for CLI 4.0)
ii  libmono-system-configuration4.0-cil 4.6.2.7+dfsg-2 all 
System.Configuration library (for CLI 4.0)
ii  libmono-system-core4.0-cil 4.6.2.7+dfsg-2 all  System.Core library 
(for CLI 4.0)
ii  libmono-system-data4.0-cil 4.6.2.7+dfsg-2 all  System.Data library 
(for CLI 4.0)
ii  libmono-system-design4.0-cil 4.6.2.7+dfsg-2 all  System.Design 
Library (for CLI 4.0)
ii  libmono-system-drawing4.0-cil .6.2.7+dfsg-2 all System.Drawing 
library (for CLI 4.0)
ii  libmono-system-enterpriseservices4.0-cil .6.2.7+dfsg-2 all 
System.EnterpriseServices library (for CLI 4.0)
ii  libmono-system-ldap4.0-cil 4.6.2.7+dfsg-2 all 
System.DirectoryServices library (for CLI 4.0)
ii  libmono-system-numerics4.0-cil .6.2.7+dfsg-2 all System.Numerics 
library (for CLI 4.0)
ii  libmono-system-runtime-serialization-formatters-soap4.0-cil 
4.6.2.7+dfsg-2 all  System.Runtime.Serialization.Formatters.Soap Library 
(for CLI 4.0)
ii  libmono-system-security4.0-cil .6.2.7+dfsg-2 all System.Security 
library (for CLI 4.0)
ii  libmono-system-transactions4.0-cil 4.6.2.7+dfsg-2 all 
System.Transactions library (for CLI 4.0)
ii  libmono-system-web-applicationservices4.0-cil 4.6.2.7+dfsg-2 all  
System.Web.ApplicationServices library (for CLI 4.0)
ii  libmono-system-web-services4.0-cil 4.6.2.7+dfsg-2 all 
System.Web.Services (for CLI 4.0)
ii  libmono-system-web4.0-cil 4.6.2.7+dfsg-2 all  System.Web library 
(for CLI 4.0)
ii  libmono-system-windows-forms4.0-cil 4.6.2.7+dfsg-2 all 
System.Windows.Forms Library (for CLI 4.0)
ii  libmono-system-xml4.0-cil 4.6.2.7+dfsg-2 all  System.Xml library 
(for CLI 4.0)

ii  libmono-system4.0-cil 4.6.2.7+dfsg-2 all  System libraries (for CLI 4.0)
ii  libmono-webbrowser4.0-cil 4.6.2.7+dfsg-2 all  Web Browser library 
(for CLI 4.0)

ii  mono-4.0-gac 4.6.2.7+dfsg-2 all  GAC tool (for CLI 4.0)
ii  mono-gac 4.6.2.7+dfsg-2 all  GAC tool
ii  mono-mcs 4.6.2.7+dfsg-2 all  C# 2.0 / 3.0 / 4.0 / 5.0 compiler for 
CLI 2.0 / 4.0 / 4.5

ii  mono-runtime 4.6.2.7+dfsg-2 amd64    Mono runtime - default version
ii  mono-runtime-common .6.2.7+dfsg-2 amd64    Mono runtime - common 
files

ii  mono-runtime-sgen 4.6.2.7+dfsg-2 amd64    Mono runtime - SGen
rc  mono-xsp4 .2-2.1 all  web server to run ASP.NET 4.0 applications
rc  monodoc-http 4.2-2.2 all  http based viewer

Bug#909033: quickroute-gps: Map flicking makes software unusuable on X11

[Gautier Pelloux-Prayer]

The bug actually also occurs on Wayland, with the same stacktrace.

Bug#908398: firefox-esr: Browsing history leak after 60.2 upgrade

[Tuxicoman]

Hi,

Do you have any more info ?
This looks related to Firefox rather than Debian. So it should be
reproducible elsewhere. Is there any study on this behavior so that we
can know which part of the code is responsible of this behavior ?

Bug#909986: cloudpickle: FTBFS (TypeError: can't pickle _abc_data objects)

[Diane Trout]

On Sun, 2018-09-30 at 23:03 +, Santiago Vila wrote:
> Package: src:cloudpickle
> Version: 0.5.2-2
> Severity: serious
> Tags: ftbfs
> 
> Dear maintainer:
> 
> I tried to build this package in buster but it failed:

Looks like a python 3.7 incompatibility

I updated to cloudpickle 0.5.6 and it seems to work.

(The internal unittests pass, though though autopkgtests are having
trouble because of a debian mirror consistency problem)

I pushed a new source release and will see how the autobuilders handle
it.

Diane


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

Bug#906567: firefox-esr: Won't view html5 with h264

[Tuxicoman]

Hi,

On testing, libavcodec58 arrived and libavcodec57 has been removed.

Unfortunately Firefox 52 is not compatible with libavcodec58 and needs
libavcodec57 to decode H264. Thus, you cannot play h264 anymore.

The solution is to manually install libavcodec57 from Debian stable or
to upgrade to Firefox 60 which can use libavcodec58. 

Unfortunately Firefox 60 is not yet on testing. Maybe Mike Hommey can
give further info on why the migration is blocked.

Best regards,

Bugs #909722 #909398 and #906567 are duplicates of this same issue.

Bug#909380: libvidstab: enable Multi-Arch: same

[James Cowgill]

Hi,

On 01/10/2018 11:55, Keng-Yu Lin wrote:
> Hi James:
>   While I worked on the package, salsa was kind of messy for non-DD
> contributors. I just checked, it looks much better now. I think I will
> use salsa as the vcs repository.
> 
>   Can you help grant me the DM permission so that I am able to upload?
> 
>   `dcut dm` as described in https://wiki.debian.org/DebianMaintainer

I don't give DM permissions to people I haven't worked with before.
However, I will happily sponsor the upload for you if you give me a git
repository or a dsc.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#910036: [openjdk-10-jdk] Broken symlink "/usr/lib/jvm/java-10-openjdk-amd64/src.zip"

[Alexander Kernozhitsky]

Package: openjdk-10-jdk
Version: 10.0.2+13-1
Severity: normal

Symlink /usr/lib/jvm/java-10-openjdk-amd64/src.zip, redirects to ../
openjdk-10/src.zip, which doesn't exist (and I can't find this file in other 
packages)

--- System information. ---
Architecture: 
Kernel:   Linux 4.18.0-1-amd64

Debian Release: buster/sid
  990 testing ftp.by.debian.org 
  500 unstableftp.by.debian.org 

--- Package information. ---
Depends   (Version) | Installed
===-+-
openjdk-10-jre  (= 10.0.2+13-1) | 10.0.2+13-1
openjdk-10-jdk-headless (= 10.0.2+13-1) | 10.0.2+13-1
libc6(>= 2.2.5) | 
zlib1g (>= 1:1.1.4) | 


Recommends  (Version) | Installed
=-+-===
libxt-dev | 1:1.1.5-1


Suggests   (Version) | Installed
-+-===
openjdk-10-demo  | 
openjdk-10-source| 
visualvm | 
-- 
Alexander Kernozhitsky

Bug#909905: gradle FTBFS when building with openjdk-11 (needs update to 4.7.0 or upstream patch)

[shirish शिरीष]

at bottom :-

On 01/10/2018, Emmanuel Bourg  wrote:
> Le 01/10/2018 à 11:48, Emmanuel Bourg a écrit :
>
>> Thanks a lot for investigating this issue Tiago. I'll apply the patch.
>
> The fix for the Java version parsing issue can be reduced to:
>
> ---
> a/subprojects/base-services/src/main/java/org/gradle/api/JavaVersion.java
> +++
> b/subprojects/base-services/src/main/java/org/gradle/api/JavaVersion.java
> @@ -26,7 +26,7 @@
>  public enum JavaVersion {
>  VERSION_1_1(false), VERSION_1_2(false), VERSION_1_3(false),
> VERSION_1_4(false),
>  // starting from here versions are 1_ but their official name is "Java
> 6", "Java 7", ...
> -VERSION_1_5(true), VERSION_1_6(true), VERSION_1_7(true),
> VERSION_1_8(true), VERSION_1_9(true), VERSION_1_10(true);
> +VERSION_1_5(true), VERSION_1_6(true), VERSION_1_7(true),
> VERSION_1_8(true), VERSION_1_9(true), VERSION_1_10(true),
> VERSION_1_11(true);
>  private static JavaVersion currentJavaVersion;
>  private final boolean hasMajorVersion;
>  private final String versionName;
>
>
> But that's not enough, the build fails later due to the removal of
> sun.misc.Unsafe.defineClass in Java 11. It seems this was fixed in
> Gradle 4.8.
>

So are we going to have gradle 4.8 in either experimental or unstable soonish.

I'm sure you may have read the freeze time-table which was shared few days ago.

It would be nice to have all the components in debian tested etc. well
before freeze.

Hope to see the new releases of gradle, openjfx and rest of openjdk 11
dependencies so we have a java 11 transition if need be before hard
freeze comes up.

-- 
  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#909722: firefox-esr: Cannot Playback H264 content with firefox-esr 52

[Tuxicoman]

Hi,

On testing, libavcodec58 arrived and libavcodec57 has been removed.

Unfortunately Firefox 52 is not compatible with libavcodec58 and needs
libavcodec57 to decode H264. Thus, you cannot play h264 anymore.

The solution is to manually install libavcodec57 from Debian stable or
to upgrade to Firefox 60 which can use libavcodec58. 

Unfortunately Firefox 60 is not yet on testing. Maybe Mike Hommey can
give further info on why the migration is blocked.

Best regards,

Bugs #909722 #909398 and #906567 are duplicates of this same issue.

Bug#910024: thunderbird: Thunderbird useless after unkonwn automatic upgrades

[Miguel Hermanns]

Dear Carsten,

thanks for the fast response. Although you are right that the update could
have taken place earlier than this weekend, I usually keep my programs open
for long times, so that if an update happens, I do not necessarily
see/notice it. I have checked the history files you point out and the
update took place on September 17th, and indeed Thunderbird was not closed
since then until last Friday.

I also see that on that same day also the package lightning was updated,
but no mention of lightning-l10n. In fact, as you mention, the package
lightning-l10n is not installed in my PC. I will check that tomorrow and
let you know if it changes things.

I will also try the other things you mention. As said, tomorrow I report
any new findings.

Thanks again for your help and best regards,

Miguel



On Mon, Oct 1, 2018 at 7:01 PM Carsten Schoenert 
wrote:

> Hello,
>
> Am 01.10.18 um 16:51 schrieb Miguel Hermanns:
> > Package: thunderbird
> > Version: 1:60.0-3~deb9u1
> > Severity: important
> >
> > Dear Maintainer,
> >
> > When I started Thunderbird this morning, after the weekend, several
> > issues have appeared:
> >
> > - Icons for forwarding/responding/etc are no longer there.
> >
> > - Choosing from the right mouse botton menu to answer an email opens a
> >   new window to answer the email, but no text from the original email is
> >   copied for referencing.
> >
> > - Also the list of emails from the email to respond are not shown, nor
> >   the subject with the usual Re: in front.
> >
> > - Attached files are not shown at the bottom of the messages in the
> >   inbox, or anywhere in the window opened for the writing of a new
> >   email.
> >
> > I have updated the packages and restarted the computer to exclude any
> > version issues, but the problems persist. Since the visual aspect of
> > Thunderbird has changed, I assume it has been upgraded automatically
> > during the last week. Or a component/library on which it depends on
> > has been upgraded. At the moment, due to the abovementioned issues,
> > Thunderbird cannot be used on my computer.
> the update of Thunderbird 1:60.0-3~deb9u1 was introduced on 16 Sep 2018,
> this is almost 14 days from now.
>
> https://www.debian.org/security/2018/dsa-4295
>
> If your issue was introduced by Thunderbird itself and you do automatic
> updated this would mean you haven't done automatic update for over 14
> days. This is unlikely.
>
> You can check the time of the thunderbird update by have look into the
> logs of apt
>
>   /var/log/apt/history*
>
> I expect Thunderbird was updated earlier than in the last days.
>
> There are reports from a lot of users with a similar behavior which have
> installed a needed thunbird-l10n and lightning package but not the
> respective lightning-l10n package. Did you have checked the other reports?
>
> Did you have checked the other possibilities as described in the Debian
> wiki?
>
> https://wiki.debian.org/Thunderbird#Bug_Reporting_.2F_Issues
>
> --
> Mit freundlichen Grüßen
> Carsten Schönert
>

Bug#909785: python-pcl: Incomplete debian/copyright and/or "freeware" source code?

[Jochen Sprickerhof]

Hi Chris,

* Chris Lamb  [2018-09-30 20:27]:

Great stuff; thanks! The only thing I would add would be something that
explicitly addresses the the "freeware" term - it is a bit of a
"trigger word" for people looking for DFSG violations.


Now I get why you where asking for this, thanks for the explanation :). 
I updated the comment here:


https://salsa.debian.org/science-team/pcl/commit/a99ca3f9916a6a5e9d66cc2e7e4eb4adc7d3ade9

Cheers Jochen


signature.asc
Description: PGP signature

Bug#910035: O: cowsay -- configurable talking cow

[tony]

Package: wnpp

Severity:Normal

Bug#910033: bless-0.6.0-5 - Unexpected exit of the program when exporting to a file

[zkubinski]

Package: bless
Version: 0.6.0-5
Severity: important

Dear Maintainer,

   * What led up to the situation?
When I export to a text file using the File-> Export option, the
program quits unexpectedly. In the "export pattern" field, I entered
-> % E "4" p "0x" x ","%,% E "4" p "0x" s ","% \ n

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I did not take corrective actions

   * What was the outcome of this action?

the program ended unexpectedly and returned the following error in the console

Starting export
*** Error in `mono': free(): invalid pointer: 0x010a05c8 ***
=== Backtrace: =
/lib/i386-linux-gnu/libc.so.6(+0x6738a)[0xb758838a]
/lib/i386-linux-gnu/libc.so.6(+0x6dfc7)[0xb758efc7]
/lib/i386-linux-gnu/libc.so.6(+0x6e806)[0xb758f806]
/lib/i386-linux-gnu/libglib-2.0.so.0(g_free+0x20)[0xb3f7b9e0]
[0xb0e85fc4]
[0xb1116625]
[0xb11164fc]
[0xb0e85f69]
[0xb0e8585c]
mono(+0x1d8b6c)[0x62cb6c]
=== Memory map: 
00454000-0085c000 r-xp  08:05 523586 /usr/bin/mono-sgen
0085d000-0086 r--p 00408000 08:05 523586 /usr/bin/mono-sgen
0086-00865000 rw-p 0040b000 08:05 523586 /usr/bin/mono-sgen
00865000-0088 rw-p  00:00 0
00a43000-0124d000 rw-p  00:00 0  [heap]
ad50c000-ad58c000 rw-p  00:00 0
ad59-ad61 rw-p  00:00 0
ad611000-ad619000 rw-p  00:00 0
ad619000-ad61b000 rw-p  00:00 0
ad61b000-ad624000 ---p  00:00 0
ad624000-ad71c000 rw-p  00:00 0
ad71c000-ad725000 ---p  00:00 0
ad725000-ad81d000 rw-p  00:00 0
ad81d000-ad826000 ---p  00:00 0
ad826000-ad83e000 rw-p  00:00 0
ad83e000-ad847000 ---p  00:00 0
ad847000-ad93f000 rw-p  00:00 0
ad93f000-ad948000 ---p  00:00 0
ad948000-ada4 rw-p  00:00 0
ada4-ada41000 ---p  00:00 0
ada41000-ae241000 rw-p  00:00 0
ae241000-ae242000 ---p  00:00 0
ae242000-aea42000 rw-p  00:00 0
aea42000-aeade000 r--p  08:05 1441233
/usr/share/fonts/truetype/dejavu/DejaVuSans-Oblique.ttf
aeade000-aeb32000 r--p  08:05 1439700
/usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf
aeb32000-aeb3b000 ---p  00:00 0
aeb3b000-aec33000 rw-p  00:00 0
aec33000-aece r--p  08:05 1439697
/usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf
aece-aece1000 ---p  00:00 0
aece1000-af4e1000 rw-p  00:00 0
af4e1000-af4e2000 ---p  00:00 0
af4e2000-afce2000 rw-p  00:00 0
afce2000-afcfd000 r-xp  08:05 924364
/usr/lib/i386-linux-gnu/gio/modules/libgioremote-volume-monitor.so
afcfd000-afcff000 r--p 0001a000 08:05 924364
/usr/lib/i386-linux-gnu/gio/modules/libgioremote-volume-monitor.so
afcff000-afd0 rw-p 0001c000 08:05 924364
/usr/lib/i386-linux-gnu/gio/modules/libgioremote-volume-monitor.so
afd0-afd26000 rw-p  00:00 0
afd26000-afe0 ---p  00:00 0
afe0-afe15000 rw-p  00:00 0
afe15000-afe75000 rw-s  00:05 11370521   /SYSV (deleted)
afe75000-afe76000 ---p  00:00 0
afe76000-b0676000 rw-p  00:00 0
b0676000-b0677000 ---p  00:00 0
b0677000-b0e77000 rw-p  00:00 0
b0e77000-b0e79000 r-xp  08:02 392934
/lib/i386-linux-gnu/libutil-2.24.so
b0e79000-b0e7a000 r--p 1000 08:02 392934
/lib/i386-linux-gnu/libutil-2.24.so
b0e7a000-b0e7b000 rw-p 2000 08:02 392934
/lib/i386-linux-gnu/libutil-2.24.so
b0e7b000-b0e7e000 rw-p  00:00 0
b0e7e000-b0e8e000 rwxp  00:00 0
b0e8e000-b0e92000 rw-p  00:00 0
b0e92000-b0ec9000 r-xp  08:05 924359
/usr/lib/i386-linux-gnu/gvfs/libgvfscommon.so
b0ec9000-b0ecc000 r--p 00036000 08:05 924359
/usr/lib/i386-linux-gnu/gvfs/libgvfscommon.so
b0ecc000-b0ecd000 rw-p 00039000 08:05 924359
/usr/lib/i386-linux-gnu/gvfs/libgvfscommon.so
b0ecd000-b0f03000 r-xp  08:05 924365
/usr/lib/i386-linux-gnu/gio/modules/libgvfsdbus.so
b0f03000-b0f04000 ---p 00036000 08:05 924365
/usr/lib/i386-linux-gnu/gio/modules/libgvfsdbus.so
b0f04000-b0f05000 r--p 00036000 08:05 924365
/usr/lib/i386-linux-gnu/gio/modules/libgvfsdbus.so
b0f05000-b0f06000 rw-p 00037000 08:05 924365
/usr/lib/i386-linux-gnu/gio/modules/libgvfsdbus.so
b0f06000-b0f0a000 r--p  08:05 1438667
/usr/share/icons/hicolor/icon-theme.cache
b0f0a000-b0f0e000 r--p  08:05 1438667
/usr/share/icons/hicolor/icon-theme.cache
b0f0e000-b0f25000 r--p  08:05 12198
/usr/share/icons/gnome/icon-theme.cache
b0f25000-b0f3c000 r--p  08:05 12198
/usr/share/icons/gnome/icon-theme.cache
b0f3c000-b0f5a000 r--p  08:05 1321029
/usr/share/locale/pl/LC_MESSAGES/glib20.mo
b0f5a000-b0f6a000 rwxp  00:00 0
b0f6a000-b0f7a000 r--p  08:05 409256
/usr/share/texlive/texmf-dist/fonts/type1/adobe/courier/pcrr8a.pfb
b0f7a000-b0f8 r-xp  08:05 1045049
/usr/lib/cli/gdk-sharp-2.0/libgdksharpglue-2.so
b0f8-b0f81000 r--p 5000 08:05 1045049
/usr/lib/cli/gdk-sharp-2.0/l

Bug#910034: courier-pop-ssl: Doesn't start after reboot

[Thomas Bliesener]

Package: courier-pop-ssl
Version: 0.76.3-5
Severity: normal

Dear Maintainer,

courier-pop-ssl doesn't start after reboot, but can be started manually.

-- 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/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages courier-pop-ssl depends on:
ii  courier-pop  0.76.3-5

courier-pop-ssl recommends no packages.

courier-pop-ssl suggests no packages.

-- no debconf information

Bug#910024: thunderbird: Thunderbird useless after unkonwn automatic upgrades

[Carsten Schoenert]

Hello,

Am 01.10.18 um 16:51 schrieb Miguel Hermanns:
> Package: thunderbird
> Version: 1:60.0-3~deb9u1
> Severity: important
> 
> Dear Maintainer,
> 
> When I started Thunderbird this morning, after the weekend, several
> issues have appeared:
> 
> - Icons for forwarding/responding/etc are no longer there.
> 
> - Choosing from the right mouse botton menu to answer an email opens a
>   new window to answer the email, but no text from the original email is
>   copied for referencing.
> 
> - Also the list of emails from the email to respond are not shown, nor
>   the subject with the usual Re: in front.
> 
> - Attached files are not shown at the bottom of the messages in the
>   inbox, or anywhere in the window opened for the writing of a new
>   email.
> 
> I have updated the packages and restarted the computer to exclude any
> version issues, but the problems persist. Since the visual aspect of
> Thunderbird has changed, I assume it has been upgraded automatically
> during the last week. Or a component/library on which it depends on
> has been upgraded. At the moment, due to the abovementioned issues,
> Thunderbird cannot be used on my computer.
the update of Thunderbird 1:60.0-3~deb9u1 was introduced on 16 Sep 2018,
this is almost 14 days from now.

https://www.debian.org/security/2018/dsa-4295

If your issue was introduced by Thunderbird itself and you do automatic
updated this would mean you haven't done automatic update for over 14
days. This is unlikely.

You can check the time of the thunderbird update by have look into the
logs of apt

  /var/log/apt/history*

I expect Thunderbird was updated earlier than in the last days.

There are reports from a lot of users with a similar behavior which have
installed a needed thunbird-l10n and lightning package but not the
respective lightning-l10n package. Did you have checked the other reports?

Did you have checked the other possibilities as described in the Debian
wiki?

https://wiki.debian.org/Thunderbird#Bug_Reporting_.2F_Issues

-- 
Mit freundlichen Grüßen
Carsten Schönert

Bug#771998: plasma-nm: Plasma-NM gets partially dysfunctional after systemd upgrade

[Mikaela Suomalainen]

Hi,

I think I can reproduce this issue anytime by running "systemctl
restart NetworkManager". When I run it, plasma-nm loses all
connections and seems to be desynced with NetworkManager as some
applications (like HexChat) will keep receiving messages and appear
connected for a moment while plasma-nm complains about "no secrets
received" or similar strange error.

The only way to restore connectivity surely after that seems to be
rebooting as "killall plasmashell" and "plasmashell&" didn't change
the situation.

-- 
Mikaela Suomalainen
https://mikaela.info/

Bug#890299:

[J. Smith]

The crash is (probably) a libotf bug, see https://debbugs.gnu.org/30193, and 
debian bug#909699.

Bug#798955: How to deal with gcc's with multiarch glibc headers?

[Helmut Grohne]

Hi,

I was offered some CPU cycles to research the impact of #798955 (moving
glibc's headers to /usr/include/). I'll post another mail with
a summary, but there is already one quite obvious issue affecting
multiple packages. The implications are not quite clear to me, so maybe
someone else can chime in?

/usr/include/c++/8/cstdlib contains the following code:

| // Need to ensure this finds the C library's  not a libstdc++
| // wrapper that might already be installed later in the include search path.
| #define _GLIBCXX_INCLUDE_NEXT_C_HEADERS
| #include_next 
| #undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS

After fixing #798955, glibc's stdlib.h will live in
/usr/include/. One can figure out the default include search
path with "gcc -E -Wp,-v - 
comes before /usr/include. Adding -x c++ gives the search path for C++.
Notably /usr/include/c++/8 comes before both others.

Now most of the time, that works, but some packages (such as
chromium-browser, fcitx-qt5, fw4spl, or gemma) insist on adding some
-isystem /usr/include/.  That changes order and one can get:

| /usr/include/c++/8/cstdlib:75:15: fatal error: stdlib.h: No such file or 
directory
|  #include_next 
|^~
| compilation terminated.

You can trigger the very same error on a standard sid system using
-isystem /usr/include:

| echo '#include ' | g++ -isystem /usr/include -x c++ -E - >/dev/null

After messing with system include order, that's a little expected, but I
wonder whether it should work anyway.

Now gcc also ships /usr/include/c++/8/stdlib.h which starts with:

| #if !defined __cplusplus || defined _GLIBCXX_INCLUDE_NEXT_C_HEADERS
| # include_next 
| #else

So it seems that if we replaced the #include_next in cstdlib with a
plain #include, it should always work, regardless of the search order:
If glibc's header comes first, all is fine. Otherwise, the
_GLIBCXX_INCLUDE_NEXT_C_HEADERS macro will instruct gcc's stdlib.h to
#include_next glibc's stdlib.h, so it should also be fine. What I don't
understand is: why does cstdlib use #include_next at all? What problem
is solved by not using plain #include?

Then the question arises whether adding /usr/include/ via
-isystem is something that should work. Should we fix chromium-browser
et al here?

Thanks in advance

Helmut

Bug#910032: [kde-plasma-desktop] Circular dependency on kde-standard

[Alexander Kernozhitsky]

Package: kde-plasma-desktop
Version: 5:102
Severity: normal

kde-plasma-desktop and kde-standard seem to be circular dependencies (the 
packages depend on each other)

--- System information. ---
Architecture: 
Kernel:   Linux 4.18.0-1-amd64

Debian Release: buster/sid
  990 testing ftp.by.debian.org 
  500 unstableftp.by.debian.org 

--- Package information. ---
Depends   (Version) | Installed
===-+-===
kde-baseapps (>= 4:17.08.3) | 4:17.08.3+5.102
plasma-desktop  (>= 4:5.10) | 4:5.13.5-1
plasma-workspace(>= 4:5.10) | 4:5.13.5-1
udisks2 | 2.7.6-3
upower  | 0.99.8-2


Recommends (Version) | Installed
-+-
kwin-x11 (>= 4:5.10) | 4:5.13.5-1
sddm   (>= 0.11) | 0.18.0-1
xserver-xorg | 1:7.7+19


Suggests(Version) | Installed
=-+-===
kdeconnect| 1.3.1-1
-- 
Alexander Kernozhitsky

Bug#910030: fuse3: Please drop unnecessary debhelper overrides

[Chris Lamb]

Source: fuse3
Version: 3.2.4-1
Severity: wishlist
X-Debbugs-CC: Laszlo Boszormenyi (GCS) , 
ftpmas...@debian.org

Hi,

I just ACCEPTed fuse3 from NEW but was wondering if you could drop the
unneccessary debhelper overrides.

It is likely that is this was intended to optimise package builds by
introducing "no-op" overrides that avoid specific debhelper commands.

However, whilst using overrides are not a problem per-se, such a list
is usually a premature optimisation, subject to constant revision,
prevents future debhelper versions fixing archive-wide problems, adds
unnecessary noise/distraction for anyone reviewing the package,
increases the package's "bus factor" and is typically a premature
optimisation. It is, in addition, aesthetically displeasing.


Regards,

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