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

[local10]

Package: kwrite 
Version: 4:18.04.0-1
Severity: important

Kwrite crashes while opening a file, kwrite was able to open this file in 
Wheezy consistently without any issues.

Thanks


Executable: kwrite PID: 9355 Signal: Segmentation fault (11) Time: 9/6/18 
01:31:20

Application: KWrite (kwrite), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f16e4810500 (LWP 9355))]

Thread 5 (Thread 0x7f16da747700 (LWP 9359)):
#0  0x7f16e9f7be6c in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#1  0x7f16db60a90b in ?? () from /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
#2  0x7f16db60a637 in ?? () from /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
#3  0x7f16e9f75f2a in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#4  0x7f16eb7e0edf in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 4 (Thread 0x7f16db089700 (LWP 9358)):
#0  0x7f16e9f7be6c in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#1  0x7f16db60a90b in ?? () from /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
#2  0x7f16db60a637 in ?? () from /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
#3  0x7f16e9f75f2a in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#4  0x7f16eb7e0edf in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 3 (Thread 0x7f16e21f6700 (LWP 9357)):
#0  0x7f16eb7d6739 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7f16e8c22439 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7f16e8c2254c in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f16ebce623b in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x7f16ebc9324b in 
QEventLoop::exec(QFlags) () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7f16ebae2176 in QThread::exec() () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x7f16ea4ed545 in ?? () from /lib/x86_64-linux-gnu/libQt5DBus.so.5
#7  0x7f16ebaebd47 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x7f16e9f75f2a in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#9  0x7f16eb7e0edf in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 2 (Thread 0x7f16e315e700 (LWP 9356)):
#0  0x7f16eb7d6739 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7f16e7a43cf7 in ?? () from /lib/x86_64-linux-gnu/libxcb.so.1
#2  0x7f16e7a4590a in xcb_wait_for_event () from 
/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x7f16e4528159 in ?? () from /lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#4  0x7f16ebaebd47 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7f16e9f75f2a in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#6  0x7f16eb7e0edf in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 1 (Thread 0x7f16e4810500 (LWP 9355)):
[KCrash Handler]
#6  0x7f16ec106376 in ?? () from /lib/x86_64-linux-gnu/libQt5Gui.so.5
#7  0x7f16ec10f05f in QTextEngine::itemize() const () from 
/lib/x86_64-linux-gnu/libQt5Gui.so.5
#8  0x7f16ec11799c in QTextLayout::beginLayout() () from 
/lib/x86_64-linux-gnu/libQt5Gui.so.5
#9  0x7f16ed14e3c6 in ?? () from /lib/x86_64-linux-gnu/libKF5TextEditor.so.5
#10 0x7f16ed153881 in ?? () from /lib/x86_64-linux-gnu/libKF5TextEditor.so.5
#11 0x7f16ed154b21 in ?? () from /lib/x86_64-linux-gnu/libKF5TextEditor.so.5
#12 0x7f16ed19af2a in ?? () from /lib/x86_64-linux-gnu/libKF5TextEditor.so.5
#13 0x7f16ed19b214 in ?? () from /lib/x86_64-linux-gnu/libKF5TextEditor.so.5
#14 0x7f16ed185196 in KTextEditor::ViewPrivate::updateView(bool) () from 
/lib/x86_64-linux-gnu/libKF5TextEditor.so.5
#15 0x7f16ed0f772c in KTextEditor::DocumentPrivate::updateConfig() () from 
/lib/x86_64-linux-gnu/libKF5TextEditor.so.5
#16 0x7f16ed1d9dbd in KateDocumentConfig::updateConfig() () from 
/lib/x86_64-linux-gnu/libKF5TextEditor.so.5
#17 0x7f16ed1d372b in KateDocumentConfig::setEncoding(QString const&) () 
from /lib/x86_64-linux-gnu/libKF5TextEditor.so.5
#18 0x7f16ed112afe in KateBuffer::openFile(QString const&, bool) () from 
/lib/x86_64-linux-gnu/libKF5TextEditor.so.5
#19 0x7f16ed109e2f in KTextEditor::DocumentPrivate::openFile() () from 
/lib/x86_64-linux-gnu/libKF5TextEditor.so.5
#20 0x7f16ecf5da21 in ?? () from /lib/x86_64-linux-gnu/libKF5Parts.so.5
#21 0x7f16ecf5e9b6 in KParts::ReadOnlyPart::openUrl(QUrl const&) () from 
/lib/x86_64-linux-gnu/libKF5Parts.so.5
#22 0x7f16ed0fe4d1 in KTextEditor::DocumentPrivate::openUrl(QUrl const&) () 
from /lib/x86_64-linux-gnu/libKF5TextEditor.so.5
#23 0x5590a44f0dea in ?? ()
#24 0x5590a44f3148 in ?? ()
#25 0x5590a44f32e2 in ?? ()
#26 0x7f16ebcbd7bb in QMetaObject::activate(QObject*, int, int, void**) () 
from /lib/x86_64-linux-gnu/libQt5Core.so.5
#27 0x7f16ec5e6ef2 in QAction::triggered(bool) () from 

Bug#908094: i3lock-fancy: new upstream version

[Brian May]

Package: i3lock-fancy
Version: 0.0~git20160228.0.0fcb933-2
Severity: wishlist


Version in Debian unstable is very old, please consider updating to at
least version 0.2, the latest release.

Actually I am somewhat confused, the Debian package seems to contain
functionality to support multiple monitors not in upstream. Maybe this
could be pushed upstream first?

Thanks

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

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

Versions of packages i3lock-fancy depends on:
ii  gawk 1:4.1.4+dfsg-1
ii  i3lock   2.8-1
ii  imagemagick  8:6.9.7.4+dfsg-11+deb9u5
ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-11+deb9u5
ii  mawk 1.3.3-17+b3
ii  scrot0.8-18

i3lock-fancy recommends no packages.

Versions of packages i3lock-fancy suggests:
ii  maim3.3.41-1+b1
pn  wmctrl  

-- no debconf information

Bug#907727: source-contains-empty-directory when a patch adds a file to that directory

[Niels Thykier]

Chris Lamb:
> Hi Russ,
> 
>> P: xfonts-jmk source: source-contains-empty-directory neep/ascii/
>>
>> but a patch in the quilt series adds a file to that directory. 
> 
> So, we currently loop over:
> 
> foreach my $file ($info->sorted_orig_index) {
> 
> … which with "3.0 (quilt)" has the patches applied. I'm not sure how we
> can get the unpatched output in this case. Any ideas?
> 
> (Parsing the diffs to catch this false-positive might be a little too
> much for this corner-case.)
> 
> 
> Regards,
> 

Hi Chris,

Have you checked if the src-orig-index collection
($info->{sorted_,}orig_index) has the data you want?

As I recall, it is based solely on the tarballs (i.e. no patches applied).

Thanks,
~Niels

Bug#908093: ITP: mle -- flexible terminal-based text editor

[Adam Saponara]

Package: wnpp
Severity: wishlist
Owner: Adam Saponara 

* Package name: mle
  Version : 1.2
  Upstream Author : Adam Saponara 
* URL : https://github.com/adsr/mle
* License : Apache
  Programming Lang: C
  Description : flexible terminal-based text editor

mle is a small, flexible, terminal-based text editor 
written in C. Runs on Linux, Windows (cygwin), FreeBSD, and 
MacOS.

Some demos:

https://imgur.com/a/ZBmmQ
https://i.imgur.com/atS11HX.gif
https://i.imgur.com/VGGMmGg.gif

Will seek sponsor in #debian-cli.

Bug#908092: dbus: skip autopkgtest ulimit test when in a container

[Steve Langasek]

Package: dbus
Version: 1.12.10-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu cosmic ubuntu-patch

Dear maintainers,

After merging dbus 1.12.10-1 from Debian into Ubuntu, the autopkgtests were
failing on armhf:

[...]
# our RLIMIT_NOFILE: rlim_cur: 1024, rlim_max: 1024
# dbus-daemon's RLIMIT_NOFILE: rlim_cur: 1024, rlim_max: 1024
Bail out! ERROR:../../../test/dbus-daemon.c:2085:test_fd_limit: assertion fa
iled (lim.rlim_cur >= DESIRED_RLIMIT): (1024 >= 65536)
/tmp/autopkgtest.GG6gs6/build.iea/src/debian/tests/root: line 28:   638 Aborted 
$timeout $t --tap
[...]
autopkgtest [20:05:11]: test root: ---]
autopkgtest [20:05:14]: test root:  - - - - - - - - - - results - - - - - - - - 
- -
root FAIL non-zero exit status 1

   
(https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/armhf/d/dbus/20180905_201152_67b80@/log.gz)

This is because armhf is the single architecture on which Ubuntu runs its
autopkgtests in containers rather than in VMs, and these are unprivileged
containers, which means "root" processes don't actually have the
capabilities necessary to re-raise limits after they've been lowered.

I've uploaded the attached patch to Ubuntu in order to have passing tests
again on armhf.  I'm not sure if you would consider it sufficiently correct
for Debian, since this means we're also skipping this test on privileged
containers, but I guess it should be a starting point for discussion.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru dbus-1.12.10/debian/tests/root dbus-1.12.10/debian/tests/root
--- dbus-1.12.10/debian/tests/root  2018-08-03 03:18:18.0 -0700
+++ dbus-1.12.10/debian/tests/root  2018-09-05 20:56:03.0 -0700
@@ -35,9 +35,14 @@
 echo "x" > "$AUTOPKGTEST_TMP/result"
 (
 set +e
-# One test needs us to have a small fd limit
-ulimit -S -n 1024
-ulimit -H -n 1024
+# Don't change limits in containers, as we're not guaranteed to be
+# able to re-raise them due to unprivileged containers.  This test
+# will be auto-skipped instead.
+if ! grep -q container= /proc/1/environ; then
+# One test needs us to have a small fd limit
+ulimit -S -n 1024
+ulimit -H -n 1024
+fi
 $timeout $t --tap
 echo "$?" > "$AUTOPKGTEST_TMP/result"
 ) | sed 's/^//'

Bug#908091: sweethome3d: Immediate crash upon starting 'sweethome3d'

[nikobit]

Package: sweethome3d
Version: 5.7+dfsg-2
Severity: normal
Tags: newcomer

Dear Maintainer,
Same as previous bug reporter I would like to say thank you for maintaining
such extraordinary job. Afraid I'm reporting bug 884057 once again but
hopefully my machine configuration will help to get the wright approach to the
issue.

Application crashes immediately after start. To avoid it I've tried to open
file *.sh3d which was created in other OS. That in turn led to unaccessible
system and required hard reset.

Me myself and the whole bunch of users will be greately appreciated if this
problem could be finally solved!



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

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

Versions of packages sweethome3d depends on:
ii  default-jre [java7-runtime] 2:1.10-68
ii  icedtea-netx-common 1.6.2-3.1
ii  java-wrappers   0.3
ii  libbatik-java   1.10-1
ii  libfreehep-graphicsio-svg-java  2.1.1-5
ii  libitext-java   2.1.7-12
ii  libjava3d-java  1.5.2+dfsg-15
ii  libsunflow-java 0.07.2.svn396+dfsg-17
ii  openjdk-10-jre [java7-runtime]  10.0.2+13-1

Versions of packages sweethome3d recommends:
ii  sweethome3d-furniture  1.6.3-1

sweethome3d suggests no packages.

-- no debconf information

Bug#907987: libextractor: CVE-2018-16430: Out of Bound Read

[Salvatore Bonaccorso]

Hi Chris,

On Wed, Sep 05, 2018 at 10:57:19PM +0100, Chris Lamb wrote:
> Hi,
> 
> > libextractor: CVE-2018-16430: Out of Bound Read
> 
> Happy to prepare a stable-security upload of this if team@security.d.o
> are interested?

Think this will not be needed this time, but thanks for the offer!
Maintainer prepared an update for the previous two CVEs, and is
pending, and we asked if he can include the fix for CVE-2018-16430 as
well already in the new debdiff.

Regards,
Salvatore

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

[Joseph Herlant]

Control: forwarded -1
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/4
Control: tags -1 + patch
Control: tags -1 + upstream

Hi,

The issue is due to a optiomizations impacting precision with GCC8.
There is an existing bug report on this issue upstream:
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/559
and an existing merge request there too:
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/4

I've created the MR on salsa to add the upstream patch with quilt in
the current version:
https://salsa.debian.org/pulseaudio-team/pulseaudio/merge_requests/1

Let me know if I can do anything more to help on this specific issue.

Thanks
Joseph

Bug#896970: RFS: odp/1.19.0.0-1 [ITP]

[Mo Zhou]

Hi Dmitry,

Thanks for the update!

On Fri, Aug 31, 2018 at 03:41:01PM +0300, Dmitry Eremin-Solenikov wrote:
> Hello,
> 
> I've uploaded new 1.19.0.2-1 version to mentors.d.o.
> I've added manpages, fixed copyright info, fixed alternatives
> and enabled auto-tests. Could you please review it?

Build-dependency libibverbs-dev is missing. It failed to build from
source because the linker cannot find -libverbs

After adding that dependency I tried to build again however it ended
up with a test failure. (also see the appendix part of this mail)

http://debomatic-amd64.debian.net/distribution#unstable/odp/1.19.0.2-1/buildlog

> сб, 2 июн. 2018 г. в 7:08, Lumin :
> >
> > On Sat, Jun 02, 2018 at 03:24:07AM +, Lumin wrote:
> > > Please fix the aforementioned problems. Hopefully we'll have the last
> > > round of check next time. Thank you for working on this.
> > >
> > > [1] 
> > > http://debomatic-amd64.debian.net/distribution#unstable/odp/1.19.0.1-1/buildlog
> >
> > Forgot to check the copyright ... The copyright looks incomplete. A
> > simple search on the source tree would reveal many non-Linaro copyright
> > holders:
> >
> >   grep -ri copyright | grep -vi linaro | grep -i copyright
> >
> > The package will be rejected by ftp-master if we don't fix the
> > copyright.
> 
> Should be fixed now.

Oops, you may have missed my second mail. The copyright file
could be simpler by merging similar paragraphs into one instead
one paragraph per file. A template can be generated with the
following command:

  licensecheck -r --deb-machine .

Which will automatically merge paragraphs. 
> >   grep -ri copyright | grep -vi linaro | grep -i copyright
^ And I use this command for double-checking the copyright.

Apart from that, these lintian complains should be fixed:

I: odp source: wildcard-matches-nothing-in-dep5-copyright 
platform/linux-generic/odp_hash.c (paragraph at line 101)
I: odp source: wildcard-matches-nothing-in-dep5-copyright 
m4/ax_check_compile_flag.m4 (paragraph at line 219)
I: odp source: wildcard-matches-nothing-in-dep5-copyright 
m4/ax_compiler_vendor.m4 (paragraph at line 224)
I: odp source: wildcard-matches-nothing-in-dep5-copyright 
m4/ax_compiler_version.m4 (paragraph at line 229)
I: odp source: wildcard-matches-nothing-in-dep5-copyright m4/ax_pthread.m4 
(paragraph at line 237)
I: odp source: unused-file-paragraph-in-dep5-copyright paragraph at line 101
I: odp source: unused-file-paragraph-in-dep5-copyright paragraph at line 109
I: odp source: unused-file-paragraph-in-dep5-copyright paragraph at line 219
I: odp source: unused-file-paragraph-in-dep5-copyright paragraph at line 224
I: odp source: unused-file-paragraph-in-dep5-copyright paragraph at line 229
I: odp source: unused-file-paragraph-in-dep5-copyright paragraph at line 237

> > When checking odp-dpdk, one more problem was found:
> >
> >   root@b69fed1c16e0 ~/odp-dpdk-1.19.0.0# update-alternatives --config 
> > libodp-linux.so-x86_64-linux-gnu
> >   There are 2 choices for the alternative libodp-linux.so-x86_64-linux-gnu 
> > (providing /usr/lib/x86_64-linux-gnu/libodp-linux.so).
> >
> > SelectionPath   
> > Priority   Status
> >   
> >   * 0/usr/lib/x86_64-linux-gnu/odp-generic/libodp-linux.so   40 
> >auto mode
> > 1/usr/lib/x86_64-linux-gnu/odp-dpdk/libodp-linux.so  40 
> >manual mode
> > 2/usr/lib/x86_64-linux-gnu/odp-generic/libodp-linux.so   40 
> >manual mode
> >
> >
> >   * 0/usr/lib/x86_64-linux-gnu/odp-dpdk/libodp-linux.so.119 
> >  60auto mode
> > 1/usr/lib/x86_64-linux-gnu/odp-dpdk/libodp-linux.so.119 
> >  60manual mode
> > 2/usr/lib/x86_64-linux-gnu/odp-generic/libodp-linux.so.119  
> >  40manual mode
> >
> > Taking BLAS as an example, the generic and slow libblas3 provides
> > libblas.so.3 symlink with a priority of 10. Faster implementations
> > provides the same symlink with higher priorities, e.g. 40 for openblas.
> >
> > Maybe you want to adjust the priority values in those postinst scripts?
> > The exact value is up to you, as long as it helps to tell the difference
> > among different implementations.
> 
> I'll fix odp-dpdk later.

It's good as long as all odp-generic packages are assigned with the
same priority, and odp-dpdk with a higher one.
 
> -- 
> With best wishes
> Dmitry
> 

Appendix

FAIL: scheduler/scheduler_main
==

odp_ishm.c:936:_odp_ishm_reserve():No huge pages, fall back to normal pages. 
check: /proc/sys/vm/nr_hugepages.
Queue config:
  queue_basic.max_queue_size: 8192
  queue_basic.default_queue_size: 4096

Using scheduler 'basic'
Scheduler config:
  sched_basic.prio_spread: 4

PKTIO: initialized loop interface.
PKTIO: initialized dpdk pktio, use export ODP_PKTIO_DISABLE_DPDK=1 to disable.
PKTIO: initialized pcap 

Bug#908090: VCS check reports bogus error

[Mattias Ellert]

package: qa.debian.org

The VCS check page for globus-gram-job-manager-sge has reported a
problem for months now without a problem existimg:

https://qa.debian.org/cgi-bin/vcswatch?package=globus-gram-job-manager-sge

Please fix the broken svn checkout on your test machine.

Consider implementing some autodetection of issues like this so that
problems on the test server are not reported as problems with a
package's VCS repository.

Mattias



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

Bug#905262: RFS: golang-github-tcnksm-go-gitconfig

[Jongmin Kim]

On Wed, Sep 05, 2018 at 09:57:40PM -0400, Alexandre Viau wrote:
> On 2018-09-01 02:10 AM, Jongmin Kim wrote:
> > Hi,
> >
> > Thanks a lot for your careful review.
> > A lot of apologise for my delay.
> 
> Don't worry, most of us work on Debian on our free time. If you want
> something done fast, the only way to be sure is to do it yourself or
> hire someone ;).

Thank you! X)

> > I made a change with your suggestions. Thank you!
> > I tried to make the repository to keep the upstream's commit history,
> > instead of using 'pristine-tar'. In result, I created again a new
> > repository in my namespace:
> > https://salsa.debian.org/jmkim-guest/golang-github-tcnksm-go-gitconfig
> >
> > Would you please consider to use this for packaging, instead of using
> > our team's repo? Thank you!
> 
> Again, I am not sure what to do.
> 
> You want me to overwrite our team's repository? Are you able to do it
> yourself?

Sorry. Could you please wipe the team's repository? I will upload there.
Thank you!

-- 
Jongmin Kim

OpenPGP key located at
https://jmkim-pgp.github.io/keys/pubkey.D39D8D29BAF36DF8.Jongmin_Kim.asc
OpenPGP fingerprint: 012E 4A06 79E1 4EFC DAAE  9472 D39D 8D29 BAF3 6DF8


signature.asc
Description: PGP signature

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

[Jongmin Kim]

On Wed, Sep 05, 2018 at 09:54:50PM -0400, Alexandre Viau wrote:
> On 2018-09-01 02:05 AM, Jongmin Kim wrote:
> > I tried to make the repository to keep the upstream's commit history,
> > instead of using 'pristine-tar'. In result, I created again a new
> > repository in my namespace:
> > https://salsa.debian.org/jmkim-guest/golang-github-rivo-tview
> >
> > Would you please consider to use this for packaging, instead of using
> > our team's repo? Thank you!
> >
> >
> > [1] https://github.com/rivo/tview/issues/149
> > [2] https://lists.debian.org/debian-mentors/2018/08/msg00217.html
> 
> Are you suggesting that we replace the team's repository? Or are you
> suggesting to keep it in your namespace?
> 
> Are you able to just update the team's repository to the latest and
> greatest and have me review that instead?
> 
> It may be that you are not able to overwrite existing commits. In that
> case, I am willing to wipe the repository for you.
> 
> Let me know what you need.

Ah, I suggest that we replace the team's repository.

I cannot overwrite the existing commits (because all the branches are
protected, and I don't have a right to overwrite them). Would you please
wipe the team's repository? Then I will upload there. Thank you!


-- 
Jongmin Kim

OpenPGP key located at
https://jmkim-pgp.github.io/keys/pubkey.D39D8D29BAF36DF8.Jongmin_Kim.asc
OpenPGP fingerprint: 012E 4A06 79E1 4EFC DAAE  9472 D39D 8D29 BAF3 6DF8


signature.asc
Description: PGP signature

Bug#908055: docker.io: CVE-2017-14992

[Shengjing Zhu]

On Thu, Sep 6, 2018 at 9:40 AM Arnaud Rebillout
 wrote:
>
>
> On 09/05/2018 10:22 PM, Shengjing Zhu wrote:
> > Dear docker.io maintainer,
> >
> > I'm not sure why the Built-Using field in docker.io doesn't contain
> > golang-github-vbatts-tar-split. Maybe dh-golang can't deal with the
> > docker.io repo. Not sure it's whose bug...
>
> Built-Using is supposed to reflect the build dependencies, isn't it?
>

Yes, not only packages listed in Build-Depends, but also the indirect depends.

Implementation details in dh-golang is: it runs `go list {{ .Dep }}` ,
to get all the dependencies.
https://sources.debian.org/src/dh-golang/1.35/script/dh_golang/#L73

I guess the manual manipulation of DH_GOPKG in d/rules comfuses dh-golang.


-- 
Regards,
Shengjing Zhu

Bug#905262: RFS: golang-github-tcnksm-go-gitconfig

[Alexandre Viau]

On 2018-09-01 02:10 AM, Jongmin Kim wrote:
> Hi,
>
> Thanks a lot for your careful review.
> A lot of apologise for my delay.

Don't worry, most of us work on Debian on our free time. If you want
something done fast, the only way to be sure is to do it yourself or
hire someone ;).

> I made a change with your suggestions. Thank you!
> I tried to make the repository to keep the upstream's commit history,
> instead of using 'pristine-tar'. In result, I created again a new
> repository in my namespace:
> https://salsa.debian.org/jmkim-guest/golang-github-tcnksm-go-gitconfig
>
> Would you please consider to use this for packaging, instead of using
> our team's repo? Thank you!

Again, I am not sure what to do.

You want me to overwrite our team's repository? Are you able to do it
yourself?

Cheers,

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




signature.asc
Description: OpenPGP digital signature

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

[Alexandre Viau]

On 2018-09-01 02:05 AM, Jongmin Kim wrote:
> At that time, I just used an username of upstream's author. With your
> suggestion, I opened an issue [1] and made a change. Some days ago I
> asked some questions related to copyright to debian-mentors [2], and got
> some suggestions from them. I will not do like this anymore. Thank you!
>
>
> I tried to make the repository to keep the upstream's commit history,
> instead of using 'pristine-tar'. In result, I created again a new
> repository in my namespace:
> https://salsa.debian.org/jmkim-guest/golang-github-rivo-tview
>
> Would you please consider to use this for packaging, instead of using
> our team's repo? Thank you!
>
>
> [1] https://github.com/rivo/tview/issues/149
> [2] https://lists.debian.org/debian-mentors/2018/08/msg00217.html

Are you suggesting that we replace the team's repository? Or are you
suggesting to keep it in your namespace?

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

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

Let me know what you need.

Cheers,

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




signature.asc
Description: OpenPGP digital signature

Bug#908086: rsyslog: FTBFS randomly (failing tests)

[Michael Biebl]

On 9/6/18 01:51, Santiago Vila wrote:

> The build was made in my autobuilder with "dpkg-buildpackage -B"
> but there are also build failures here:
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/rsyslog.html
> 
> I've put several of my build logs here:
> 
> https://people.debian.org/~sanvila/build-logs/rsyslog/

I'm not able to reproduce and the package builds pretty reliably on the
buildds as well.
So I can't really investigate this further myself, but I'd be happy if
someone wants to further debug this.


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



signature.asc
Description: OpenPGP digital signature

Bug#908089: nheko: Maintainer address needs to be pkg-matrix-maintain...@alioth-lists.debian.net

[shirish शिरीष]

Package: nheko
Version: 0.4.2-1
Severity: normal

Dear Maintainer,

Right now, the maintainer address given is wrong, please change it to
pkg-matrix-maintain...@alioth-lists.debian.net so people interested in
following the changes can look at the right place.

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

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

Versions of packages nheko depends on:
ii  libc6  2.27-5
ii  libgcc11:8.2.0-4
ii  liblmdb0   0.9.22-1
ii  libqt5concurrent5  5.11.1+dfsg-6
ii  libqt5core5a   5.11.1+dfsg-6
ii  libqt5gui5 5.11.1+dfsg-6
ii  libqt5multimedia5  5.11.1-2
ii  libqt5network5 5.11.1+dfsg-6
ii  libqt5svg5 5.11.1-2
ii  libqt5widgets5 5.11.1+dfsg-6
ii  libstdc++6 8.2.0-4

Versions of packages nheko recommends:
ii  ca-certificates  20170717

nheko suggests no packages.

-- no debconf information


-- 
  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#908055: docker.io: CVE-2017-14992

[Arnaud Rebillout]

On 09/05/2018 10:22 PM, Shengjing Zhu wrote:
> Dear docker.io maintainer,
>
> I'm not sure why the Built-Using field in docker.io doesn't contain
> golang-github-vbatts-tar-split. Maybe dh-golang can't deal with the
> docker.io repo. Not sure it's whose bug...

Built-Using is supposed to reflect the build dependencies, isn't it?

A quick look at the docker.io package in experiemental: there's around
130 build dependencies in debian/control, and only 33 packages in the
Built-Using field of the binary package... So there seem to be a
problem. A quick look at consul, another "big" package, also shows
surprising numbers, around 50 build dependencies, and only ... 33
packages again in Built-Using!

Bug#907769: chromium: tab consistently crashes when visiting arduino webpage

[Michael Gilbert]

control: reopen -1
control: tag -1 confirmed, upstream

On Mon, Sep 3, 2018 at 9:27 AM Marius Mikucionis wrote:
> I have replaced the packages (see the new list below) with the Debian ones 
> and the issue persists.

I tested as well now, it is reproducible with the latest upload.

> Is there a way to triangulate the offending library?

The --debug command line option is useful.  It appears to be a problem in v8.

Best wishes,
Mike

Bug#908088: network-manager-gnome: nm-applet icon corrupt after upgrade to GTK 3.24

[Ben Caradoc-Davies]

After a reboot, the icon looks less corrupt but still has the wrong 
background.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#907601: RFS: groonga/8.0.6-1

[Kentaro Hayashi]

Hi,

On Tue, 4 Sep 2018 15:00:54 + (UTC)
Gianfranco Costamagna  wrote:

> Hello Kentaro,
> Can you please explain why you did depend on runtime to libjemalloc directly, 
> without letting shlibs:Depends do the right thing?
> 
> I had to apply this patch to Ubuntu, where jemalloc is updated, and this will 
> become RC in Debian once jemalloc in experimental goesin unstable...what 
> about removing that line entirely?If jemalloc is not picked up, probably it 
> means it is not used by underlying libraries...
> 
snip
> diff -pruN 8.0.5-1/debian/control 8.0.5-1ubuntu1/debian/control
> --- 8.0.5-1/debian/control    2018-07-27 13:46:23.0 +
> +++ 8.0.5-1ubuntu1/debian/control    2018-07-30 14:26:21.0 +

As you pointed out, it should use shlibs:Depends.
It has been missed to fix it.
I'll fix it later.

P.S. For the record, Cc:907...@bugs.debian.org

Regards,


pgp4nL_YYf4bY.pgp
Description: PGP signature

Bug#907936: nuntius-linux FTBFS with vala 0.42.0-1

[Joseph Herlant]

Control: forwarded -1 https://github.com/holylobster/nuntius-linux/pull/79
Control: tags -1 + upstream

Hi,

FYI I pushed a patch upstream to fix that specific issue. See
https://github.com/holylobster/nuntius-linux/pull/79

Best,
Joseph

Bug#906127: Incorrect check of httplib2 version

[Ben Caradoc-Davies]

Aiden,

I can confirm that your patch fixes reportbug for me. Much appreciated.

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#906127: #906127: Incorrect check of httplib2 version

[Ben Caradoc-Davies]

Sandro,

this bug makes reportbug unusable.

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#908088: network-manager-gnome: nm-applet icon corrupt after upgrade to GTK 3.24

[Ben Caradoc-Davies]

Package: network-manager-gnome
Version: 1.8.16-1
Severity: minor

Dear Maintainer,

under Xfce with the Clearlooks-Phenix theme, the nm-applet icon is corrupt
since upgrade to GTK 3.24, displaying a black background and some red lines,
rather than the grey background of the theme.

Kind regards,
Ben.



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

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

Versions of packages network-manager-gnome depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.10-1
ii  dbus-x11 [dbus-session-bus]   1.12.10-1
ii  dconf-gsettings-backend [gsettings-backend]   0.30.0-1
ii  libatk1.0-0   2.28.1-1
ii  libayatana-appindicator3-10.5.3-4
ii  libc6 2.27-6
ii  libcairo2 1.15.12-1
ii  libgdk-pixbuf2.0-02.36.12-2
ii  libglib2.0-0  2.58.0-2
ii  libgtk-3-03.24.0-1
ii  libjansson4   2.11-1
ii  libmm-glib0   1.7.990-1
ii  libnm01.12.2-3
ii  libnma0   1.8.16-1
ii  libnotify40.7.7-3
ii  libpango-1.0-01.42.4-2
ii  libpangocairo-1.0-0   1.42.4-2
ii  libsecret-1-0 0.18.6-2
ii  libselinux1   2.8-1+b1
ii  network-manager   1.12.2-3
ii  policykit-1-gnome [polkit-1-auth-agent]   0.105-7

Versions of packages network-manager-gnome recommends:
ii  gnome-keyring3.28.2-1
ii  iso-codes4.1-1
pn  mobile-broadband-provider-info   
ii  notification-daemon  3.20.0-3
ii  xfce4-notifyd [notification-daemon]  0.4.2-1

Versions of packages network-manager-gnome suggests:
pn  network-manager-openconnect-gnome  
pn  network-manager-openvpn-gnome  
pn  network-manager-pptp-gnome 
pn  network-manager-vpnc-gnome 

-- no debconf information

Bug#908087: reportbug: Fails with: TypeError: fixer() missing 1 required positional argument: 'check_hostname'

[Ben Caradoc-Davies]

Package: reportbug
Version: 7.5.0
Severity: grave
Justification: renders package unusable

Dear Maintainer,

reportbug fails on fully upgraded sid because of #906127
"Incorrect check of httplib2 version":
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906127

#906127 has normal severity, but its impact on reportbug is grave. This report
is Google fodder to help fellow victims of this bug.


Workaround is to download the patch for pysimplesoap and apply it locally:
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=906127;filename=fix-
httplib2-version-check.patch;msg=5

cd /usr/lib/python3/dist-packages/pysimplesoap
patch -p2 < /path/to/fix-httplib2-version-check.patch

After applying this patch, I was able to use reportbug to submit this report.


This example with ui gtk2 in ~/.reportbugrc, failure after entering package
name):


$ reportbug
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line 1049, in
sync_pre_operation
http_proxy=http_proxy, archived=archived, source=source)
  File "/usr/lib/python3/dist-packages/reportbug/debbugs.py", line 1072, in
get_reports
bugs = debianbts.get_bugs(pkg_filter, package)
  File "/usr/lib/python3/dist-packages/debianbts/debianbts.py", line 410, in
get_bugs
reply = soap_client.call('get_bugs', method_el)
  File "/usr/lib/python3/dist-packages/pysimplesoap/client.py", line 260, in
call
self.xml_response = self.send(method, self.xml_request)
  File "/usr/lib/python3/dist-packages/pysimplesoap/client.py", line 313, in
send
location, http_method, body=xml, headers=headers)
  File "/usr/lib/python3/dist-packages/httplib2/__init__.py", line 1395, in
request
self.disable_ssl_certificate_validation)
  File "/usr/lib/python3/dist-packages/httplib2/__init__.py", line 978, in
__init__
timeout=timeout, context=context)
TypeError: fixer() missing 1 required positional argument: 'check_hostname'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/reportbug", line 2266, in 
main()
  File "/usr/bin/reportbug", line 1109, in main
return iface.user_interface()
  File "/usr/bin/reportbug", line 1722, in user_interface
latest_first=self.options.latest_first)
  File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line 1763, in
func
args, kwargs = op.sync_pre_operation(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line 1051, in
sync_pre_operation
error_dialog("Unable to connect to %s BTS." % sysinfo['name'])
  File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line 137, in
error_dialog
_assert_context(ui_context)
  File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line 92, in
_assert_context
(_describe_context(really), _describe_context(expected)))
AssertionError: Function should be called in 
but was called in 


Without ui option in ~/.reportbugrc:

$ reportbug
Please enter the name of the package in which you have found a problem, or type
'other' to report a more general problem. If you don't know what package the
bug is in, please contact
debian-u...@lists.debian.org for assistance.
> reportbug
Detected character set: UTF-8
Please change your locale if this is incorrect.

Using 'Ben Caradoc-Davies ' as your from address.
Getting status for reportbug...
Checking for newer versions at madison...
Will send report to Debian (per lsb_release).
Querying Debian BTS for reports on reportbug (source)...
Unable to connect to Debian BTS (error: "TypeError("fixer() missing 1 required
positional argument: 'check_hostname'",)"); continue [y|N|?]?


Kind regards,
Ben.



-- Package-specific info:
** Environment settings:
INTERFACE="gtk2"

** /home/ben/.reportbugrc:
mode standard
ui gtk2
email "b...@transient.nz"
realname "Ben Caradoc-Davies"
no-cc
header "X-Debbugs-CC: b...@transient.nz"
smtphost "skyhawk.mysecure.co.nz:587"
smtptls
smtpuser "b...@transient.nz"
smtppasswd 

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

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

Versions of packages reportbug depends on:
ii  apt1.6.4
ii  python33.6.6-1
ii  python3-reportbug  7.5.0
ii  sensible-utils 0.0.12

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
pn  debsums
pn  dlocate
pn  emacs24-bin-common | emacs25-bin-common
ii  exim4-daemon-light [mail-transport-agent]  4.91-7
ii  file   1:5.34-2
ii  gnupg  

Bug#898090:

[submitpvc]

Hi,

This also fixed my problem. 

 

Thanks all!

Hugh

 

From: Shawn Anderson  
Sent: Saturday, 18 August 2018 12:34 AM
To: 898...@bugs.debian.org
Subject: Bug#898090: 

 

I was able to find that if I run the following

 

cpanm --uninstall Storable

 

my issue was addressed.

 

Sent from Mail   for Windows 10

 

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

[Dirk Eddelbuettel]

Zack,

On 5 September 2018 at 06:22, Dirk Eddelbuettel wrote:
| 
| Hi Zack,
| 
| Thanks for the report. I am CCing David who was very helpful with the
| transition to elpa-ess.  I am wondering if we can address this here, or
| whether I need to talk to upstream about this.
| 
| David, any thought? Is this something that (package-initialize) may fix?
| Another trick to pass the "installed-in" directory to the package?  Or ask
| upstream? 
| 
| Dirk
| 
| On 3 September 2018 at 13:51, Zack Weinberg wrote:
| | Package: elpa-ess
| | Version: 17.11-5
| | Severity: normal
| | 
| | When you start an R process from inside ESS, it's supposed to load a
| | file ".load.R" that, among other things, sets it up so C-c C-v works.
| | R-initialize-on-start is looking for this file in the wrong place.
| | I get these error messages in *Messages*:
| | 
| | Type C-h m for help on ESS version 17.11
| | Cannot read history file /home/zack/.Rhistory
| | ess-tracebug mode enabled
| | load ESSR: + + + Error in file(filename, "r", encoding = encoding) : 
| |   cannot open the connection
| | In addition: Warning message:
| | In file(filename, "r", encoding = encoding) :
| |   cannot open file ’/usr/share/ess/etc/ESSR/R/.load.R’: No such file or 
directory

I _cannot_ reproduce that right now in a pristine testing/unstable session
running off Docker's r-base container (which I co-maintain):

  Loading /etc/emacs/site-start.d/00debian.el (source)...done
  For information about GNU Emacs and the GNU system, type C-h C-a.
  Type C-h m for help on ESS version 17.11
  Cannot read history file /.Rhistory
  ess-tracebug mode enabled

is all I have in *Message* after I do M-x R.

Exactly _how_ do you launch the R session leading to the error?

| | The directory /usr/share/ess does not exist.
| | The package has actually installed .load.R in
| | /usr/share/emacs/site-lisp/elpa-src/ess-17.11/etc/ESSR/R/.load.R
| | If I manually do
| | 
| | source("/usr/share/emacs/site-lisp/elpa-src/ess-17.11/etc/ESSR/R/.load.R")
| | load.ESSR("/usr/share/emacs/site-lisp/elpa-src/ess-17.11/etc/ESSR/R")
| | 
| | then C-c C-v starts working again.
| | 
| | The bad path is coming from the 'ess-etc-directory' variable.  C-h v says:
| | 
| | ess-etc-directory is a variable defined in ‘ess-site.el’.
| | Its value is "/usr/share/ess/etc/"

Not for me:

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

I have _no_ .emacs here or anything that could interfere.  So the package
looks clean to me.

Dirk

| | 
| | 
| | However, the string 'ess-etc-directory' does not appear anywhere in
| | ess-site.el.  It appears actually to be defined in ess-utils.el, but
| | if I try to re-execute the code in ess-utils.el that sets its value,
| | that doesn't work either:
| | 
| | ERROR:ess-site.el:ess-etc-directory
| | Relative to ess-lisp-directory, one of the following must exist:
| | ../etc/ess, ../etc, ../../etc/ess or ./etc
| | 
| | C-h v ess-lisp-directory says:
| | 
| | ess-lisp-directory is a variable defined in ‘ess-site.el’.
| | Its value is "/usr/share/emacs/site-lisp/ess"
| | 
| | That directory does exist, but it's not part of the package and I
| | don't know how to debug this any further. In case it helps:
| | 
| | $ ls -l /usr/share/emacs/site-lisp/ess
| | total 1224
| | -rw-r--r-- 1 root root   1670 Aug 18 11:30 ess-arc-d.elc
| | -rw-r--r-- 1 root root   6913 Aug 18 11:30 ess-bugs-d.elc
| | -rw-r--r-- 1 root root   7732 Aug 18 11:30 ess-bugs-l.elc
| | -rw-r--r-- 1 root root   1275 Aug 18 11:30 ess-compat.elc
| | -rw-r--r-- 1 root root   1022 Aug 18 11:30 ess-comp.elc
| | -rw-r--r-- 1 root root  92727 Aug 18 11:30 ess-custom.elc
| | -rw-r--r-- 1 root root   5008 Aug 18 11:30 ess-dde.elc
| | -rw-r--r-- 1 root root   1483 Aug 18 11:30 ess-debug.elc
| | -rw-r--r-- 1 root root   6471 Aug 18 11:30 essd-els.elc
| | -rw-r--r-- 1 root root   2658 Aug 18 11:30 ess.elc
| | -rw-r--r-- 1 root root551 Aug 18 11:30 ess-eldoc.elc
| | -rw-r--r-- 1 root root   4222 Aug 18 11:30 ess-font-lock.elc
| | -rw-r--r-- 1 root root   3457 Aug 18 11:30 ess-generics.elc
| | -rw-r--r-- 1 root root  17029 Aug 18 11:30 ess-gretl.elc
| | -rw-r--r-- 1 root root  30779 Aug 18 11:30 ess-help.elc
| | -rw-r--r-- 1 root root  95795 Aug 18 11:30 ess-inf.elc
| | -rw-r--r-- 1 root root   3242 Aug 18 11:30 ess-install.elc
| | -rw-r--r-- 1 root root   6140 Aug 18 11:30 ess-jags-d.elc
| | -rw-r--r-- 1 root root  15544 Aug 18 11:30 ess-julia.elc
| | -rw-r--r-- 1 root root   1282 Aug 18 11:30 ess-lsp-l.elc
| | -rw-r--r-- 1 root root  28374 Aug 18 11:30 ess-mode.elc
| | -rw-r--r-- 1 root root   6168 Aug 18 11:30 ess-mouse.elc
| | -rw-r--r-- 1 root root   2436 Aug 18 11:30 ess-noweb.elc
| | -rw-r--r-- 1 root root   7374 Aug 18 11:30 ess-noweb-font-lock-mode.elc
| | -rw-r--r-- 1 root root  46287 Aug 18 11:30 ess-noweb-mode.elc
| | -rw-r--r-- 1 root root   2527 Aug 18 11:30 ess-omg-d.elc
| | -rw-r--r-- 1 root root   2880 Aug 18 11:30 

Bug#908086: rsyslog: FTBFS randomly (failing tests)

[Santiago Vila]

Package: src:rsyslog
Version: 8.37.0-2
Severity: important
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules binary-arch
dh binary-arch
   dh_update_autotools_config -a
   dh_autoreconf -a
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
configure.ac:41: installing './compile'
configure.ac:33: installing './missing'

[... snipped ...]

DEB_HOST_ARCH_LIBC=gnu
DEB_TARGET_ARCH_ABI=base
TOP_BUILDDIR=..
SHELL=/bin/sh
DEB_BUILD_ARCH_OS=linux
MAKEOVERRIDES=${-*-command-variables-*-}
DEB_HOST_GNU_CPU=x86_64
GCJFLAGS=-g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong
DEB_TARGET_GNU_SYSTEM=linux-gnu
OBJCXXFLAGS=-g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security
DEB_TARGET_ARCH_CPU=amd64
MAKELEVEL=6
SHLVL=6
SCHROOT_SESSION_ID=sid-d3b57d3f-c1f1-4d9a-9b50-a61a1ada7400
DEB_TARGET_GNU_CPU=x86_64
SCHROOT_COMMAND=dpkg-buildpackage -us -uc -B -rfakeroot
ES_DOWNLOAD=elasticsearch-5.6.9.tar.gz
FFLAGS=-g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong
CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2 -DPATH_PIDFILE=\"/run/rsyslogd.pid\"
SOURCE_DATE_EPOCH=1534466677
DEB_HOST_ARCH_ENDIAN=little
DH_INTERNAL_OPTIONS=-a
LOGNAME=buildd
DEB_RULES_REQUIRES_ROOT=no
LDFLAGS=-Wl,-z,relro -Wl,-z,now
APT_CONFIG=/var/lib/sbuild/apt.conf
DEB_BUILD_ARCH_ENDIAN=little
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
DEB_TARGET_ARCH_OS=linux
SCHROOT_CHROOT_NAME=sid
DEB_BUILD_GNU_TYPE=x86_64-linux-gnu
MAKEFLAGS=w -j1 -- TEST_LOGS=empty-hostname.sh.log\ 
hostname-getaddrinfo-fail.sh.log\ prop-programname.sh.log\ 
prop-programname-with-slashes.sh.log\ hostname-with-slash-pmrfc5424.sh.log\ 
hostname-with-slash-pmrfc3164.sh.log\ hostname-with-slash-dflt-invld.sh.log\ 
hostname-with-slash-dflt-slash-valid.sh.log\ stop-localvar.sh.log\ 
stop-msgvar.sh.log\ glbl-umask.sh.log\ glbl-unloadmodules.sh.log\ 
glbl-invld-param.sh.log\ glbl_setenv_2_vars.sh.log\ glbl_setenv_err.sh.log\ 
glbl_setenv_err_too_long.sh.log\ glbl_setenv.sh.log\ 
nested-call-shutdown.sh.log\ invalid_nested_include.sh.log\ 
omfwd-keepalive.sh.log\ omfile-read-only-errmsg.sh.log\ 
omfile-null-filename.sh.log\ omfile-whitespace-filename.sh.log\ 
omfile-read-only.sh.log\ omfile_both_files_set.sh.log\ 
msgvar-concurrency.sh.log\ localvar-concurrency.sh.log\ 
exec_tpl-concurrency.sh.log\ privdropuser.sh.log\ privdropuserid.sh.log\ 
privdropgroup.sh.log\ privdropgroupid.sh.log\ template-json.sh.log\ 
template-pure-json.sh.log\ template-pos-
 from-to.sh.log\ template-pos-from-to-lowercase.sh.log\ 
template-pos-from-to-oversize.sh.log\ 
template-pos-from-to-oversize-lowercase.sh.log\ 
template-pos-from-to-missing-jsonvar.sh.log\ template-const-jsonf.sh.log\ 
fac_authpriv.sh.log\ fac_local0.sh.log\ fac_local7.sh.log\ fac_mail.sh.log\ 
fac_news.sh.log\ fac_ftp.sh.log\ fac_ntp.sh.log\ fac_uucp.sh.log\ 
fac_invld1.sh.log\ fac_invld2.sh.log\ fac_invld3.sh.log\ 
fac_invld4_rfc5424.sh.log\ compresssp.sh.log\ compresssp-stringtpl.sh.log\ 
rawmsg-after-pri.sh.log\ rfc5424parser.sh.log\ pmrfc3164-msgFirstSpace.sh.log\ 
pmrfc3164-AtSignsInHostname.sh.log\ pmrfc3164-AtSignsInHostname_off.sh.log\ 
pmrfc3164-tagEndingByColon.sh.log\ pmrfc3164-defaultTag.sh.log\ 
pmrfc3164-json.sh.log\ tcp_forwarding_tpl.sh.log\ 
tcp_forwarding_dflt_tpl.sh.log\ tcp_forwarding_retries.sh.log\ 
arrayqueue.sh.log\ global_vars.sh.log\ no-parser-errmsg.sh.log\ 
da-mainmsg-q.sh.log\ validation-run.sh.log\ msgdup.sh.log\ 
empty-ruleset.sh.log\ imtcp-discard-truncated-msg.sh.
 log\ imtcp-basic.sh.log\ imtcp-maxFrameSize.sh.log\ 
imtcp-msg-truncation-on-number.sh.log\ imtcp-msg-truncation-on-number2.sh.log\ 
imtcp-NUL.sh.log\ imtcp-NUL-rawmsg.sh.log\ imtcp-multiport.sh.log\ 
imtcp_incomplete_frame_at_end.sh.log\ daqueue-persist.sh.log\ 
daqueue-invld-qi.sh.log\ daqueue-dirty-shutdown.sh.log\ diskq-rfc5424.sh.log\ 
diskqueue.sh.log\ diskqueue-fsync.sh.log\ diskqueue-full.sh.log\ 
rulesetmultiqueue.sh.log\ rulesetmultiqueue-v6.sh.log\ manytcp.sh.log\ 
rsf_getenv.sh.log\ imtcp_conndrop.sh.log\ imtcp_addtlframedelim.sh.log\ 
imtcp_no_octet_counted.sh.log\ imtcp_spframingfix.sh.log\ sndrcv.sh.log\ 
sndrcv_failover.sh.log\ sndrcv_gzip.sh.log\ sndrcv_udp_nonstdpt.sh.log\ 
sndrcv_udp_nonstdpt_v6.sh.log\ imudp_thread_hang.sh.log\ 
sndrcv_udp_nonstdpt_v6.sh.log\ asynwr_simple.sh.log\ asynwr_simple_2.sh.log\ 
asynwr_timeout.sh.log\ asynwr_timeout_2.sh.log\ asynwr_small.sh.log\ 
asynwr_tinybuf.sh.log\ wr_large_async.sh.log\ wr_large_sync.sh.log\ 
asynwr_deadlock.sh.log\ asynwr_dead
 lock_2.sh.log\ asynwr_deadlock2.sh.log\ 

Bug#908085: leiningen-clojure: FTBFS randomly (clojure.lang.PersistentVector cannot be cast to java.base.etc.etc)

[Santiago Vila]

Package: src:leiningen-clojure
Version: 2.8.1-7
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
dh build-indep --with bash-completion --with javahelper --buildsystem=maven
   dh_update_autotools_config -i -O--buildsystem=maven
   dh_autoreconf -i -O--buildsystem=maven
[...]
Compiling classlojure.core
Compiling clojure.tools.nrepl
java.lang.ClassCastException: clojure.lang.PersistentVector cannot be cast to 
java.base/java.lang.CharSequence
at clojure.string$split.invokeStatic(string.clj:219)
at clojure.string$split.invoke(string.clj:219)
at clojure.data.xml$qualified_name.invokeStatic(xml.clj:30)
at clojure.data.xml$qualified_name.invoke(xml.clj:27)
at clojure.data.xml$emit_start_tag.invokeStatic(xml.clj:48)
at clojure.data.xml$emit_start_tag.invoke(xml.clj:47)
at clojure.data.xml$emit_event.invokeStatic(xml.clj:67)
at clojure.data.xml$emit_event.invoke(xml.clj:65)
at clojure.data.xml$emit.invokeStatic(xml.clj:379)
at clojure.data.xml$emit.doInvoke(xml.clj:366)
at clojure.lang.RestFn.invoke(RestFn.java:425)
at clojure.lang.AFn.applyToHelper(AFn.java:156)
at clojure.lang.RestFn.applyTo(RestFn.java:132)
at clojure.core$apply.invokeStatic(core.clj:650)
at clojure.core$apply.invoke(core.clj:641)
at clojure.data.xml$indent.invokeStatic(xml.clj:402)
at clojure.data.xml$indent.doInvoke(xml.clj:396)
at clojure.lang.RestFn.invoke(RestFn.java:425)
at clojure.data.xml$indent_str.invokeStatic(xml.clj:411)
at clojure.data.xml$indent_str.invoke(xml.clj:407)
at leiningen.pom$make_pom.invokeStatic(pom.clj:390)
at leiningen.pom$make_pom.invoke(pom.clj:381)
at leiningen.pom$make_pom.invokeStatic(pom.clj:382)
at leiningen.pom$make_pom.invoke(pom.clj:381)
at leiningen.jar$filespecs.invokeStatic(jar.clj:200)
at leiningen.jar$filespecs.invoke(jar.clj:191)
at leiningen.jar$build_jar.invokeStatic(jar.clj:284)
at leiningen.jar$build_jar.invoke(jar.clj:280)
at leiningen.jar$main_jar.invokeStatic(jar.clj:292)
at leiningen.jar$main_jar.invoke(jar.clj:288)
at leiningen.jar$jar.invokeStatic(jar.clj:343)
at leiningen.jar$jar.invoke(jar.clj:325)
at leiningen.uberjar$uberjar$fn__7843.invoke(uberjar.clj:167)
at leiningen.uberjar$uberjar.invokeStatic(uberjar.clj:167)
at leiningen.uberjar$uberjar.invoke(uberjar.clj:143)
at leiningen.uberjar$uberjar.invokeStatic(uberjar.clj:187)
at leiningen.uberjar$uberjar.invoke(uberjar.clj:143)
at clojure.lang.Var.invoke(Var.java:379)
at clojure.lang.AFn.applyToHelper(AFn.java:154)
at clojure.lang.Var.applyTo(Var.java:700)
at clojure.core$apply.invokeStatic(core.clj:648)
at clojure.core$apply.invoke(core.clj:641)
at leiningen.core.main$partial_task$fn__6272.doInvoke(main.clj:284)
at clojure.lang.RestFn.invoke(RestFn.java:410)
at clojure.lang.AFn.applyToHelper(AFn.java:154)
at clojure.lang.RestFn.applyTo(RestFn.java:132)
at clojure.lang.AFunction$1.doInvoke(AFunction.java:29)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invokeStatic(core.clj:648)
at clojure.core$apply.invoke(core.clj:641)
at leiningen.core.main$apply_task.invokeStatic(main.clj:334)
at leiningen.core.main$apply_task.invoke(main.clj:320)
at leiningen.core.main$resolve_and_apply.invokeStatic(main.clj:340)
at leiningen.core.main$resolve_and_apply.invoke(main.clj:336)
at leiningen.core.main$_main$fn__6339.invoke(main.clj:420)
at leiningen.core.main$_main.invokeStatic(main.clj:411)
at leiningen.core.main$_main.doInvoke(main.clj:408)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.lang.Var.invoke(Var.java:379)
at clojure.lang.AFn.applyToHelper(AFn.java:154)
at clojure.lang.Var.applyTo(Var.java:700)
at clojure.core$apply.invokeStatic(core.clj:646)
at clojure.core$apply.invoke(core.clj:641)
at clojure.main$main_opt.invokeStatic(main.clj:316)
at clojure.main$main_opt.invoke(main.clj:310)
at clojure.main$main.invokeStatic(main.clj:421)
at clojure.main$main.doInvoke(main.clj:384)
at clojure.lang.RestFn.invoke(RestFn.java:436)
at clojure.lang.Var.invoke(Var.java:388)
at clojure.lang.AFn.applyToHelper(AFn.java:160)
at clojure.lang.Var.applyTo(Var.java:700)
at clojure.main.main(main.java:37)
Uberjar aborting because jar failed: clojure.lang.PersistentVector cannot be 
cast to java.base/java.lang.CharSequence
make[1]: *** [debian/rules:70: override_dh_auto_build] Error 1
make[1]: Leaving directory '/<>'

Bug#884978: NMU built

[GCS]

Hi Hugh,

On Wed, Sep 5, 2018 at 2:33 PM Hugh McMaster  wrote:
> I've prepared an NMU for tiff and have uploaded it to Debian Mentors.
>
> The requisite diff is attached to this post.
 This NMU is unwelcomed. I don't see your point. Any of the bugs you
fix is RC and/or the maintainer is MIA or any other rush for this
upload?

Regards,
Laszlo/GCS

Bug#907554: maven-debian-helper: relocations do not work for packaging type pom

[Emmanuel Bourg]

I stumbled on this issue as well and I'm currently working on a fix for
maven-debian-helper. The same issue will have to be addressed in
maven-repo-helper.

Bug#908084: Please use different names for the Wayland and Xorg session

[Michael Biebl]

Package: plasma-workspace-wayland
Version: 4:5.13.4-1
Severity: normal

Hi,

/usr/share/wayland-sessions/plasmawayland.desktop
and
/usr/share/xsessions/plasma.desktop

both contain

Name=Plasma
Comment=Plasma by KDE

When using a display manager like gdm, which shows both X and Wayland
sessions, you are not able to distinguish the two Plasma sessions.

Please consider using a different name (like "Plasma on Wayland") for
the wayland session.





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

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

Versions of packages plasma-workspace-wayland depends on:
ii  kwayland-integration  5.13.4-1
ii  kwin-wayland  4:5.13.4-1
ii  plasma-workspace  4:5.13.4-1
ii  qtwayland55.11.1-2

plasma-workspace-wayland recommends no packages.

plasma-workspace-wayland suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/share/wayland-sessions/plasmawayland.desktop (from 
plasma-workspace-wayland package)

Bug#908082: golang-github-juju-testing: Autobuilder hangs when building with eatmydata

[Santiago Vila]

Package: src:golang-github-juju-testing
Version: 0.0~git20170608.2fe0e88-3
Severity: wishlist

Dear maintainer:

When I build this package using sbuild + eatmydata this is what happens:


[...]
 debian/rules build-indep
dh build-indep --buildsystem=golang --with=golang
   dh_update_autotools_config -i -O--buildsystem=golang
   dh_autoreconf -i -O--buildsystem=golang
   dh_auto_configure -i -O--buildsystem=golang
   dh_auto_build -i -O--buildsystem=golang
cd obj-x86_64-linux-gnu && go install 
-gcflags=\"-trimpath=/<>/golang-github-juju-testing-0.0\~git20170608.2fe0e88/obj-x86_64-linux-gnu/src\"
 
-asmflags=\"-trimpath=/<>/golang-github-juju-testing-0.0\~git20170608.2fe0e88/obj-x86_64-linux-gnu/src\"
 -v -p 1 github.com/juju/testing github.com/juju/testing/checkers 
github.com/juju/testing/filetesting github.com/juju/testing/httptesting
github.com/juju/errors
github.com/juju/loggo
github.com/juju/retry
gopkg.in/check.v1
gopkg.in/mgo.v2/internal/json
gopkg.in/mgo.v2/bson
gopkg.in/yaml.v2
github.com/juju/testing/checkers
github.com/juju/utils/clock
golang.org/x/crypto/pbkdf2
golang.org/x/net/context
github.com/juju/utils
github.com/juju/version
gopkg.in/mgo.v2/internal/scram
gopkg.in/mgo.v2
github.com/juju/testing
github.com/juju/testing/filetesting
github.com/juju/testing/httptesting
   dh_auto_test -i -O--buildsystem=golang
cd obj-x86_64-linux-gnu && go test -vet=off -v -p 1 
github.com/juju/testing github.com/juju/testing/checkers 
github.com/juju/testing/filetesting github.com/juju/testing/httptesting
=== RUN   Test
SIGQUIT: quit
PC=0x472298 m=0 sigcode=0

goroutine 6 [syscall]:
syscall.Syscall6(0xf7, 0x1, 0x7d43, 0xc420069600, 0x104, 0x0, 0x0, 0x0, 
0xbafe20, 0x0)
/usr/lib/go-1.10/src/syscall/asm_linux_amd64.s:44 +0x5 fp=0xc4200695a8 
sp=0xc4200695a0 pc=0x472275
os.(*Process).blockUntilWaitable(0xc420026780, 0x0, 0x0, 0x2)
/usr/lib/go-1.10/src/os/wait_waitid.go:31 +0x98 fp=0xc4200696a8 
sp=0xc4200695a8 pc=0x493668
os.(*Process).wait(0xc420026780, 0xc4200feb60, 0xc4200ce4f8, 0xc4200ce4f8)
/usr/lib/go-1.10/src/os/exec_unix.go:22 +0x3c fp=0xc420069720 
sp=0xc4200696a8 pc=0x48d5ac
os.(*Process).Wait(0xc420026780, 0x936048, 0x936050, 0x936040)
/usr/lib/go-1.10/src/os/exec.go:123 +0x2b fp=0xc420069750 
sp=0xc420069720 pc=0x48cb5b
os/exec.(*Cmd).Wait(0xc4200ce420, 0x0, 0x0)
/usr/lib/go-1.10/src/os/exec/exec.go:461 +0x5c fp=0xc4200697c8 
sp=0xc420069750 pc=0x53cc8c
os/exec.(*Cmd).Run(0xc4200ce420, 0xc420088910, 0x1)
/usr/lib/go-1.10/src/os/exec/exec.go:305 +0x5c fp=0xc4200697f0 
sp=0xc4200697c8 pc=0x53c16c
os/exec.(*Cmd).Output(0xc4200ce420, 0xf, 0xc4200578b8, 0x1, 0x1, 0xc4200ce420)
/usr/lib/go-1.10/src/os/exec/exec.go:500 +0xf5 fp=0xc420069840 
sp=0xc4200697f0 pc=0x53d085
github.com/juju/testing.detectMongoVersion(0xc420154b40, 0xf, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x0, 0xc420057cb0, 0xe0)

/<>/obj-x86_64-linux-gnu/src/github.com/juju/testing/mgo.go:396 
+0xb0 fp=0xc4200699b8 sp=0xc420069840 pc=0x7f0e90
github.com/juju/testing.(*mongodCache).Get(0xbaf180, 0x0, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x0, 0x0, ...)

/<>/obj-x86_64-linux-gnu/src/github.com/juju/testing/mgo.go:359 
+0x170 fp=0xc420069a58 sp=0xc4200699b8 pc=0x7f0830
github.com/juju/testing.(*MgoInstance).run(0xbaf300, 0xc, 0xc420057e78)

/<>/obj-x86_64-linux-gnu/src/github.com/juju/testing/mgo.go:260 
+0x1a8 fp=0xc420069da0 sp=0xc420069a58 pc=0x7ef848
github.com/juju/testing.(*MgoInstance).Start(0xbaf300, 0x0, 0x17f7a0e4, 
0x17f7a0e400a2d078)

/<>/obj-x86_64-linux-gnu/src/github.com/juju/testing/mgo.go:206 
+0x38f fp=0xc420069f48 sp=0xc420069da0 pc=0x7ef1bf
github.com/juju/testing.MgoTestPackage(0xc4201660f0, 0x0)

/<>/obj-x86_64-linux-gnu/src/github.com/juju/testing/mgo.go:455 
+0x3b fp=0xc420069f88 sp=0xc420069f48 pc=0x7f186b
github.com/juju/testing_test.Test(0xc4201660f0)

/<>/obj-x86_64-linux-gnu/src/github.com/juju/testing/package_test.go:13
 +0x34 fp=0xc420069fa8 sp=0xc420069f88 pc=0x805d34
testing.tRunner(0xc4201660f0, 0x935870)
/usr/lib/go-1.10/src/testing/testing.go:777 +0xd0 fp=0xc420069fd0 
sp=0xc420069fa8 pc=0x4ed330
runtime.goexit()
/usr/lib/go-1.10/src/runtime/asm_amd64.s:2361 +0x1 fp=0xc420069fd8 
sp=0xc420069fd0 pc=0x45b471
created by testing.(*T).Run
/usr/lib/go-1.10/src/testing/testing.go:824 +0x2e0

goroutine 1 [chan receive]:
testing.(*T).Run(0xc4201660f0, 0x917136, 0x4, 0x935870, 0x47e966)
/usr/lib/go-1.10/src/testing/testing.go:825 +0x301
testing.runTests.func1(0xc420166000)
/usr/lib/go-1.10/src/testing/testing.go:1063 +0x64
testing.tRunner(0xc420166000, 0xc42013fdf8)
/usr/lib/go-1.10/src/testing/testing.go:777 +0xd0
testing.runTests(0xc4200feb00, 0xba18a0, 0x1, 0x1, 0x411eb9)
/usr/lib/go-1.10/src/testing/testing.go:1061 +0x2c4
testing.(*M).Run(0xc420118800, 0x0)

Bug#908083: golang-gopkg-macaroon-bakery.v2: Autobuilder hangs when building with eatmydata

[Santiago Vila]

Package: src:golang-gopkg-macaroon-bakery.v2
Version: 0.0~git20171221.21d9e9a-5
Severity: wishlist

Dear maintainer:

When I build this package using sbuild + eatmydata this is what happens:


[...]
 debian/rules build-indep
dh build-indep --buildsystem=golang --with=golang
   dh_update_autotools_config -i -O--buildsystem=golang
   dh_autoreconf -i -O--buildsystem=golang
   dh_auto_configure -i -O--buildsystem=golang
   dh_auto_build -i -O--buildsystem=golang
cd obj-x86_64-linux-gnu && go install 
-gcflags=\"-trimpath=/<>/golang-gopkg-macaroon-bakery.v2-0.0\~git20171221.21d9e9a/obj-x86_64-linux-gnu/src\"
 
-asmflags=\"-trimpath=/<>/golang-gopkg-macaroon-bakery.v2-0.0\~git20171221.21d9e9a/obj-x86_64-linux-gnu/src\"
 -v -p 1 gopkg.in/macaroon-bakery.v2/bakery 
gopkg.in/macaroon-bakery.v2/bakery/checkers 
gopkg.in/macaroon-bakery.v2/bakery/identchecker 
gopkg.in/macaroon-bakery.v2/bakery/internal/macaroonpb 
gopkg.in/macaroon-bakery.v2/bakery/mgorootkeystore 
gopkg.in/macaroon-bakery.v2/bakerytest gopkg.in/macaroon-bakery.v2/httpbakery 
gopkg.in/macaroon-bakery.v2/httpbakery/agent 
gopkg.in/macaroon-bakery.v2/httpbakery/form 
gopkg.in/macaroon-bakery.v2/internal/httputil
github.com/juju/loggo
github.com/rogpeppe/fastuuid
golang.org/x/crypto/curve25519
golang.org/x/crypto/internal/subtle
golang.org/x/crypto/poly1305
golang.org/x/crypto/salsa20/salsa
golang.org/x/crypto/nacl/secretbox
golang.org/x/crypto/nacl/box
golang.org/x/net/context
gopkg.in/errgo.v1
gopkg.in/macaroon.v2
gopkg.in/macaroon-bakery.v2/bakery/checkers
github.com/golang/protobuf/proto
gopkg.in/macaroon-bakery.v2/bakery/internal/macaroonpb
gopkg.in/macaroon-bakery.v2/bakery
gopkg.in/macaroon-bakery.v2/bakery/identchecker
gopkg.in/mgo.v2/internal/json
gopkg.in/mgo.v2/bson
gopkg.in/mgo.v2/internal/scram
gopkg.in/mgo.v2
gopkg.in/macaroon-bakery.v2/bakery/mgorootkeystore
github.com/julienschmidt/httprouter
golang.org/x/net/html/atom
golang.org/x/net/html
gopkg.in/httprequest.v1
github.com/juju/webbrowser
golang.org/x/net/context/ctxhttp
golang.org/x/net/publicsuffix
gopkg.in/macaroon-bakery.v2/internal/httputil
gopkg.in/macaroon-bakery.v2/httpbakery
gopkg.in/macaroon-bakery.v2/bakerytest
gopkg.in/macaroon-bakery.v2/httpbakery/agent
github.com/juju/errors
github.com/juju/utils/clock
golang.org/x/crypto/pbkdf2
gopkg.in/yaml.v2
github.com/juju/utils
github.com/juju/schema
github.com/juju/utils/keyvalues
gopkg.in/juju/environschema.v1
golang.org/x/sys/unix
golang.org/x/crypto/ssh/terminal
gopkg.in/juju/environschema.v1/form
gopkg.in/macaroon-bakery.v2/httpbakery/form
   dh_auto_test -i -O--buildsystem=golang
cd obj-x86_64-linux-gnu && go test -vet=off -v -p 1 
gopkg.in/macaroon-bakery.v2/bakery gopkg.in/macaroon-bakery.v2/bakery/checkers 
gopkg.in/macaroon-bakery.v2/bakery/identchecker 
gopkg.in/macaroon-bakery.v2/bakery/internal/macaroonpb 
gopkg.in/macaroon-bakery.v2/bakery/mgorootkeystore 
gopkg.in/macaroon-bakery.v2/bakerytest gopkg.in/macaroon-bakery.v2/httpbakery 
gopkg.in/macaroon-bakery.v2/httpbakery/agent 
gopkg.in/macaroon-bakery.v2/httpbakery/form 
gopkg.in/macaroon-bakery.v2/internal/httputil
=== RUN   TestPackage
OK: 71 passed
--- PASS: TestPackage (0.05s)
PASS
ok  gopkg.in/macaroon-bakery.v2/bakery  0.050s
=== RUN   TestPackage
OK: 19 passed
--- PASS: TestPackage (0.00s)
PASS
ok  gopkg.in/macaroon-bakery.v2/bakery/checkers 0.003s
=== RUN   TestPackage
OK: 19 passed
--- PASS: TestPackage (0.01s)
PASS
ok  gopkg.in/macaroon-bakery.v2/bakery/identchecker 0.012s
?   gopkg.in/macaroon-bakery.v2/bakery/internal/macaroonpb  [no test files]
=== RUN   TestPackage
SIGQUIT: quit
PC=0x472258 m=0 sigcode=0

goroutine 5 [syscall]:
syscall.Syscall6(0xf7, 0x1, 0x3d5d, 0xc420069600, 0x104, 0x0, 0x0, 0x0, 
0xba1480, 0x0)
/usr/lib/go-1.10/src/syscall/asm_linux_amd64.s:44 +0x5 fp=0xc4200695a8 
sp=0xc4200695a0 pc=0x472235
os.(*Process).blockUntilWaitable(0xc4200267b0, 0x0, 0x0, 0x2)
/usr/lib/go-1.10/src/os/wait_waitid.go:31 +0x98 fp=0xc4200696a8 
sp=0xc4200695a8 pc=0x493358
os.(*Process).wait(0xc4200267b0, 0xc420106a80, 0xc4200cc918, 0xc4200cc918)
/usr/lib/go-1.10/src/os/exec_unix.go:22 +0x3c fp=0xc420069720 
sp=0xc4200696a8 pc=0x48d56c
os.(*Process).Wait(0xc4200267b0, 0x9308d8, 0x9308e0, 0x9308d0)
/usr/lib/go-1.10/src/os/exec.go:123 +0x2b fp=0xc420069750 
sp=0xc420069720 pc=0x48cb1b
os/exec.(*Cmd).Wait(0xc4200cc840, 0x0, 0x0)
/usr/lib/go-1.10/src/os/exec/exec.go:461 +0x5c fp=0xc4200697c8 
sp=0xc420069750 pc=0x675a3c
os/exec.(*Cmd).Run(0xc4200cc840, 0xc42008a9b0, 0x1)
/usr/lib/go-1.10/src/os/exec/exec.go:305 +0x5c fp=0xc4200697f0 
sp=0xc4200697c8 pc=0x674f1c
os/exec.(*Cmd).Output(0xc4200cc840, 0xf, 0xc4200578b8, 0x1, 0x1, 0xc4200cc840)
/usr/lib/go-1.10/src/os/exec/exec.go:500 +0xf5 fp=0xc420069840 
sp=0xc4200697f0 pc=0x675e35
github.com/juju/testing.detectMongoVersion(0xc42015eb30, 

Bug#908066: vim uses an incorrect URL parser

[KellerFuchs]

Control: tag -1 + buster sid
Control: found -1 2:8.1.0320-1

On Wed, Sep 05, 2018 at 06:53:01PM +, Keller Fuchs wrote:
> [...] I was not in a position to test whether I could reproduce it on buster.

PS: Ryan (in CC) reported she could reproduce the issue on Buster, and is 
planning to write a patch and submit it upstream.

Bug#907727: source-contains-empty-directory when a patch adds a file to that directory

[Russ Allbery]

Chris Lamb  writes:
> Hi Russ,

>> P: xfonts-jmk source: source-contains-empty-directory neep/ascii/
>> 
>> but a patch in the quilt series adds a file to that directory. 

> So, we currently loop over:

> foreach my $file ($info->sorted_orig_index) {

> … which with "3.0 (quilt)" has the patches applied. I'm not sure how we
> can get the unpatched output in this case. Any ideas?

The directory is not empty if you look when patches are applied, so I
think my assumption about what Lintian was doing is incorrect and there's
some other issue.

gwaihir:~/tmp$ apt-get source xfonts-jmk
Reading package lists... Done
Selected version '3.0-22' (unstable) for xfonts-jmk
NOTICE: 'xfonts-jmk' packaging is maintained in the 'Git' version control 
system at:
https://git.eyrie.org/git/debian/xfonts-jmk.git
Please use:
git clone https://git.eyrie.org/git/debian/xfonts-jmk.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 818 kB of source archives.
Get:1 http://ftp.us.debian.org/debian unstable/main xfonts-jmk 3.0-22 (dsc) 
[1,627 B]
Get:2 http://ftp.us.debian.org/debian unstable/main xfonts-jmk 3.0-22 (tar) 
[624 kB]
Get:3 http://ftp.us.debian.org/debian unstable/main xfonts-jmk 3.0-22 (diff) 
[192 kB]
Fetched 818 kB in 2s (435 kB/s) 
dpkg-source: info: extracting xfonts-jmk in xfonts-jmk-3.0
dpkg-source: info: unpacking xfonts-jmk_3.0.orig.tar.gz
dpkg-source: info: unpacking xfonts-jmk_3.0-22.debian.tar.xz
dpkg-source: info: applying debian-changes
gwaihir:~/tmp$ ls -al xfonts-jmk-3.0/neep/ascii
total 4
drwxr-xr-x 1 eagle eagle  24 Sep  5 15:46 ./
drwxr-xr-x 1 eagle eagle 292 Sep  5 15:46 ../
-rw-r--r-- 1 eagle eagle 341 Sep  5 15:46 .placeholder

-- 
Russ Allbery (r...@debian.org)   

Bug#907518: wpa: problems with openssl 1.1.1

[Josh Triplett]

On Wed, Sep 05, 2018 at 11:48:56PM +0200, Kurt Roeckx wrote:
> The problem here is that the CA you're connecting to has an
> insecure certificate. You should talk to your administrator
> to generate stronger keys.

I am aware of this, and I'm in the process of doing so.

> The "ca md too weak" is because the certificate is probably using
> SHA-1, while it should move to SHA256.

Is there a way I can easily get wpa_supplicant to log the full client
and server certificate chain, and flag which *specific* certificate in
that chain it has an issue with? I'm trying to present appropriate
information to get the wireless network infrastructure improved, and
unlike https I can't just use `openssl s_client` to get the details I
need.

> This can be worked around by using this in your wpa config:
> openssl_ciphers=DEFAULT@SECLEVEL=1

I don't suppose you happen to know how I could do that for a
NetworkManager network configuration?

> There is also an "ssl_choose_client_version:version too low" message.
> This is most likely caused by minimum TLS 1.2 version setting. I
> can't find a way in wpa to override the default. You will have to
> modify /etc/ssl/openssl.cnf and change:
> MinProtocol = TLSv1.2
> to:
> MinProtocol = TLSv1

Good to know, thank you.

> Note that you can also change the cipher string in that file, from
> CipherString = DEFAULT@SECLEVEL=2
> to
> CipherString = DEFAULT@SECLEVEL=1
> 
> But I recommend that you do it in the wpa config file if you can
> instead, so that only the security of that connection is lowered.

Ideally I'd like to do that for just the one network, yeah.

Bug#908068: torbrowser-launcher fails with torbrowser 8.0

[Nicolas Vigier]

On Wed, 05 Sep 2018, gregor herrmann wrote:

> 
> I suppose this needs "just" some AppArmor tweaks but I was not
> successful in the first few tries (it's a bit of a rabbit hole for a
> layperson like me, after dirname comes firefox.real, and then
> something about libstdc++.so.6 …).

It seems to be caused by this change:
https://gitweb.torproject.org/builders/tor-browser-build.git/commit/?id=5933f5916a68fdafd7103a4800e156a0100c3a6c

In this release the firefox binary has been renamed to firefox.real,
and firefox is now a wrapper script running firefox.real.

Nicolas



signature.asc
Description: Digital signature

Bug#904776: /usr/bin/dpkg-source: please parse d/t/control.autodep8 like d/t/control

[Guillem Jover]

Hi!

On Wed, 2018-08-01 at 15:58:29 +0200, Paul Gevers wrote:
> On 01-08-18 04:44, Guillem Jover wrote:
> > On Mon, 2018-07-30 at 20:03:07 +0200, Paul Gevers wrote:
> >> autopkgtest (the binary that is _an_
> >> implementation of the spec) only calls autodep8 when it doesn't find the
> >> control file as a fall back. autopkgtest doesn't know why it is called,
> >> it doesn't know about the Testsuite field, nor does anything in the CI
> >> framework except for the one that requests the test.
> > 
> > Right, but it seems autodep8 does check, and uses the Testsuite field
> > to decide whether some of the precooked checks should be used.
> 
> Yes, but it may be absent: autodep8 also works on packages that haven't
> set any Testsuite field in debian/control. It tries to figure out if the
> binary packages are of some type and cooks up the control stanza for
> those. E.g. if a source or binary package starts with python-, it gives
> us the python2.7 version, if you run autopkgtest (with auto_control
> enabled) on them. This has been very useful on the ci.d.n infrastructure
> to have large classes of packages tested. This isn't used for
> influencing migration though.

Sure.

> > Wouldn't simply changing the logic to something like the following
> > simplified stuff, do the trick?
> > 
> >   * change autopkgtest to always call autodep8 if auto_control is
> > enabled.
> >   * change autodep8 to always cat debian/tests/control if present.
> >   * then autodep8 would cat the autogenerated tests like now based on
> > the Testsuite field, and for backwards compat also the
> > control.autodep8 file if present.
> 
> What is currently missing is a way for the package maintainer to say:
> DON'T add autodep8 stanza to my package (as it fails). Currently that is
> implemented by having a file called debian/tests/control. So if we want
> to go this route, we either need time to have all packages that need
> autodep8 off to be able to migrate to a still to be defined way of
> saying so (e.g. by explicitly adding "Testsuite: autopkgtest" to
> d/control, which may break a lot of packages when autodep8 adds support
> for another class) or we can have autopgktest behave differently for
> different ways of calling the test, e.g. when run on .dsc files compared
> to when run from an unbuilt source-tree. I don't like to go the route of
> different results.

The problems I see are:

  * This feels like an internal implementation detail that would get
leaked upwards in the stack, so a layer violation.
  * The autodep8 stuff is optionally invoked so the information
generated might not always be relevant, but the control.autodep8
file looks like it's something that one would not want to make
dependant on autodep8 being run or not.
  * The auto generated stanzas are output into a temporary file so
these would not be taken into account either, which might be the
desired intention, but it feels weird.

I guess, the logic proposed above could be changed a bit to support
something closer to the current logic, and not introduce such a
global semantic change, so perhaps:

  * change autopkgtest to check the Testsuite field in debian/control:
- if it contains say an autopkgtest-autogen value then call autodep8,
  even if debian/tests/control exists.
- otherwise call autodep8 only if debian/tests/control does not
  exist.
  * change autodep8 to always cat debian/tests/control if present.
  * then autodep8 would cat the autogenerated tests like now based on
the Testsuite field, and for backwards compat also the
control.autodep8 file if present.


So this seems fully backwards compatible, and would make things more
clear IMO. It would also make those control.autodep8 files non-optional
based on autodep8 running or not. And the transition would be smooth. Any
current package shipping a control.autodep8 would just need to rename it
to control and add the “Testsuite: autopkgtest-autogen” field. Any
package that does not have such value in the field and contains a
debian/tests/control would not get autodep8 executed so would
automatically opt-out like now.

On Sun, 2018-08-19 at 21:38:26 +0200, Paul Gevers wrote:
> This bug is still marked as moreinfo, are you still waiting for more
> input from me?

I'm just still not convinced this should be handled in dpkg. :)

Thanks,
Guillem

Bug#908081: auctex: no longer autoloads with emacs >= 1:25.2+1-11

[Julian Gilbey]

Package: auctex
Version: 11.91-1
Severity: important
Tags: patch

With the recent upgrade of emacs to the non-numbered package names,
emacs25 is now just a transitional package.  As a result, the
debian-emacs-flavor is just "emacs", so the test on line 7 of
/etc/emacs/site-start.d/50auctex.el fails and the package is not
autoloaded.

Patch: add "emacs" to this list, so that it reads:

(if (member debian-emacs-flavor '(emacs24 emacs25 emacs-snapshot emacs))

Best wishes,

   Julian

Bug#890024: npapi-vlc: upcoming Firefox ESR dropping support for NPAPI

[Sebastian Ramacher]

Control: clone -1 -2
Control: severity -2 normal
Control: retitle -2 RM: npapi-vlc -- ROM; firefox-esr dropped support for NPAPI 
plugins
Control: reassign -2 ftp.debian.org

On 2018-08-30 08:15:16, Reinhard Tartler wrote:
> I agree that it's time to have the package npapi-vlc removed from unstable.
> 
> Let's proceed with the RM bug.

FTP masters, please remove npapi-vlc from unstable. With firefox dropping
support for NPAPI plugins, this plugin is no longer usable.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

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

[local10]

Package: kde-standard   
Version: 5:102

Am experiencing a weird issue in KDE after installing kde-standard package: all 
apps I tried (e.g. Konsole, Konqueror, Firefox) open and their windows do not 
have title bars. Thus, there is no (obvious) way to maximize, minimize, move, 
resize or even close the window.

Tried LXDE and LXQT, both work work as expected, with properly working widows, 
etc.

Any ideas? Thanks

Bug#907278: goobook fails to authenticate

[Kurt Roeckx]

Now that bug #907278 is fixed, I think this is fixed too.

Bug#907477: maven-debian-helper: does not substitute values of plugins with maven.rules

[Emmanuel Bourg]

Le 28/08/2018 à 15:25, Markus Koschany a écrit :

> I added a new rule to debian/maven.rules
> 
> org.apache.xbean maven-xbean-plugin * s/.*/4\.5/ * *
> 
> Expected behavior:
> 
> The version in src/pom.xml will be tranformed from 4.1 to 4.5.
> 
> Result:
> 
> Version is still 4.1

For plugins and poms the exact type and version have to be specified in
the substitution rule. For example:

  org.apache.xbean maven-xbean-plugin maven-plugin s/4.1/4.5/ * *

I have no idea if this was designed that way or if it's a bug.


> Ideally libxbean-java would provide a debian version of
> maven-xbean-plugin but that's another story.

Generic 'debian' versions don't work with plugins unfortunately.
We would have to hack the Maven plugin validation logic.

Bug#907987: libextractor: CVE-2018-16430: Out of Bound Read

[Chris Lamb]

Hi,

> libextractor: CVE-2018-16430: Out of Bound Read

Happy to prepare a stable-security upload of this if team@security.d.o
are interested?


Best wishes,

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

Bug#907884: vlc: Debian 9.5 hangs when opening the mkv file in vlc 3.0.4-1

[Sebastian Ramacher]

Control: severity -1 important

On 2018-09-03 17:14:07, Sebastian Ramacher wrote:
> Control: tags -1 + moreinfo
> 
> On 2018-09-03 17:59:43, Сергей Фёдоров wrote:
> > To: sub...@bugs.debian.org
> > Subject: vlc: Debian 9.5 hangs when opening the mkv file in vlc 3.0.4-1
> > Package: vlc
> > Version: 3.0.4-1
> > Severity: critical
> > Justification: breaks the whole system
> > Tags: a11y
> > 
> > Debian 9.5 hangs when opening the mkv file in vlc 3.0.4-1
> 
> The version infor below points to buster/unstable. What are you testing 
> exactly?
> 
> > In Debian 9.5 Sid opening a media file {avi,mkv and others} in vlc 3.0.4-1 
> > (and libvlc* 3.0.4-1)
> > opens a window with black content, the mouse cursor moves freely across the 
> > screen, but the keyboard
> > and mouse buttons are locked, i.e. Debian hangs.
> 
> Please provide the output of vlc -vvv when this happens. But in general, this
> seems like a driver issues to me. Please also try again with disabling 
> hardware
> accerlation and let us know if that fixes things.

Please provide this information. Without it, the bug is not actionable. I'm
downgrading the severity until we know more.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#907518: wpa: problems with openssl 1.1.1

[Kurt Roeckx]

The problem here is that the CA you're connecting to has an
insecure certificate. You should talk to your administrator
to generate stronger keys.

The "ca md too weak" is because the certificate is probably using
SHA-1, while it should move to SHA256.

This can be worked around by using this in your wpa config:
openssl_ciphers=DEFAULT@SECLEVEL=1

There is also an "ssl_choose_client_version:version too low" message.
This is most likely caused by minimum TLS 1.2 version setting. I
can't find a way in wpa to override the default. You will have to
modify /etc/ssl/openssl.cnf and change:
MinProtocol = TLSv1.2
to:
MinProtocol = TLSv1

Note that you can also change the cipher string in that file, from
CipherString = DEFAULT@SECLEVEL=2
to
CipherString = DEFAULT@SECLEVEL=1

But I recommend that you do it in the wpa config file if you can
instead, so that only the security of that connection is lowered.

Bug#908016: libqmi FTBFS with glib 2.58

[Juhani Numminen]

Control: tags -1 fixed-upstream

Dear maintainer,

On Wed, 05 Sep 2018 10:11:52 +0300 Adrian Bunk  wrote:
> Source: libqmi
> Version: 1.20.0-1
> Severity: serious
> Tags: ftbfs
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libqmi.html
> 
> ...
> In file included from /usr/include/glib-2.0/glib/glist.h:32,
>  from /usr/include/glib-2.0/glib/ghash.h:33,
>  from /usr/include/glib-2.0/glib.h:50,
>  from qmicli-dms.c:28:
> qmicli-dms.c: In function 'get_stored_image_result_free':
> qmicli-dms.c:2700:52: error: function called through a non-compatible type 
> [-Werror]
>  g_clear_pointer (>modem_unique_id, 
> (GDestroyNotify)g_array_unref);

Based on the commit message, I believe that this commit fixes the FTBFS:
https://cgit.freedesktop.org/libqmi/commit/?id=89bb9f6c18243b9e01386683566bd0bf2825566c

It is contained in the latest upstream release 1.20.2.

This is just speculation as I haven't attempted to build it :)


Cheers,
Juhani

Bug#907681: lintian: false positive source-only-upload-to-non-free-without-autobuild

[Chris Lamb]

tags 907681 + pending
thanks

Fixed in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/d31b05f82d276c35f475a952e0b240d14e5e1ed6

  checks/changes-file.desc   | 12 
  checks/changes-file.pm |  6 --
  checks/control-file.desc   | 12 
  checks/control-file.pm |  7 +++
  debian/changelog   |  4 
  t/changes/changes-file-source-only-non-free/desc   |  5 -
  t/changes/changes-file-source-only-non-free/log|  1 -
  t/changes/changes-file-source-only-non-free/tags   |  1 -
  .../changes-file-source-only-non-free/test.changes.in  | 18 --
  .../debian/debian/control.in   | 17 +
  .../desc   |  6 ++
  .../tags   |  1 +
  12 files changed, 47 insertions(+), 43 deletions(-)


Regards,

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

Bug#908078: should detect when 'nodoc' is active, then --with sphinxdoc should do nil

[Nicholas D Steeves]

Package: sphinx-common
Version: 1.7.8-1
Severity: normal

Part of the purpose of building with 'nodoc' is the omission of
build-deps.  dh_sphinxdoc should detect when 'nodoc' is active, then
--with sphinxdoc should not attempt to do anything, other than print
that it is doing nothing, because 'nodoc' is active.

Steps to reproduce:

--- a/debian/control
+++ b/debian/control
  , python3-mock 
  , python3-nose 
  , python3-pip 
- , python3-sphinx
- , texinfo
+ , python3-sphinx 
+ , texinfo 
 Standards-Version: 4.2.1
 Vcs-Browser: https://salsa.debian.org/emacsen-team/elpy
 Vcs-Git: https://salsa.debian.org/emacsen-team/elpy.git

--- a/debian/rules
+++ b/debian/rules
 # docs are not generated without this override
 override_dh_auto_build:
dh_auto_build
-   PYTHONPATH=. sphinx-build -N -bman docs/ build/man # Manpage generator
+# support the nodoc build profile
+ifneq ($(filter nodoc,$(DEB_BUILD_PROFILES)),)
+   echo -e "\nnodoc build profile enabled, therefor not building docs.\n"
+else
+   PYTHONPATH=. sphinx-build -N -bman docs/ build/man
PYTHONPATH=. sphinx-build -N -btexinfo docs/ build/info
makeinfo --no-split build/info/Elpy.texi -o build/info/elpy.info
cat NEWS.rst debian/local-var-snippet > build/NEWS
+endif


At this point dpkg-buildpackage will fail, because python3-sphinx is
not installed.  Python3-sphinx is only installed when  is
true, which is part of the purpose of building with 'nodoc'.  Of
course I was able to work around this issue by adding the following:

--- a/debian/rules
+++ b/debian/rules
 export LC_ALL
 
 %:
+ifneq ($(filter nodoc,$(DEB_BUILD_PROFILES)),)
+   echo -e "\nnodoc profile enabled, building without sphinxdoc..\n"
+   dh $@ --with elpa,python3 --buildsystem=pybuild
+else
dh $@ --with elpa,python3,sphinxdoc --buildsystem=pybuild
+endif


It would be best if dh_sphinxdoc had its own 'ifneq ($(filter
nodoc,$(DEB_BUILD_PROFILES)),)' logic.  I suspect this is a trivially
easy fix that could even be tagged 'newcomer'.


Cheers,
Nicholas

Bug#907888: [Pkg-openssl-devel] Bug#907888: Bug#907888: openssl: Breaks wpa_supplicant (and NetworkManager) which fail with error "ee key too small"

[Kurt Roeckx]

On Tue, Sep 04, 2018 at 11:41:48AM +0200, Gianpaolo Cugola wrote:
> 
> 1. Administrators of big organizations are usually reluctant to change
> their certificates

Can you at least try to contact them?

> 2. The suggested workaround works (thanks again) for wpa_supplicant but
> NetworkManager (which is used by most linux distros) cannot pass the
> "openssl_ciphers" flag to wpa_supplicant.
> 
> On the other hand, starting from your suggestion, I found a workaround that
> changes the cipher globally. I report it below for other users.
> 
> It is just a matter of editing file /etc/ssl/openssl.cnf changing last line
> from:
> CipherString = DEFAULT@SECLEVEL=2
> to
> CipherString = DEFAULT@SECLEVEL=1
> 
> I know, this impact the global security of your linux box, but it was the
> standard up to August, when OpenSSL 1.1.1 was released, so it should not be
> a big problem for most users :-)

It would be best that you could specify this as specific as
needed, so per connection. So having support for that in
NetworkManager could be nice.


Kurt

Bug#907015: [Pkg-openssl-devel] Bug#907015: openssl version 1.1.1 breaks multiple reverse dependencies; versioned Breaks needed

[Kurt Roeckx]

On Wed, Sep 05, 2018 at 10:58:27PM +0200, Sebastian Andrzej Siewior wrote:
> On 2018-08-23 09:07:31 [+0200], Paul Gevers wrote:
> > 2) enable the openssl package to collect information which packages it
> > breaks and which version of those package fix the issue. With that
> > information the openssl package can add versioned Breaks
> > 
> > We believe that the versioned Breaks are needed to enable a smooth
> > upgrade path for testing users as well as for users that upgrade from
> > stretch to buster. For users a Breaks is also required if the new
> > OpenSSL just exposed an existing bug in the reverse dependency.
> 
> how is a versioned break helping anything? The minimal key limit, hash
> and TLS version can be overriden via config file and this what is
> causing the problems from what I can tell. So either the remote side
> upgrades their things or the users enabled "lower security" mode.
> Is there anything that skipped my mind?

There are also bugs in packages that actually break because of the
TLS 1.3 changes, for instance not sending the SNI and trying to
connect to google. Having a Breaks might be useful for those.


Kurt

Bug#908077: ITP: google-compute-image-packages -- Google Compute Engine guest environment for cloud images

[Lucas Kanashiro]

Package: wnpp
Severity: wishlist
Owner: Lucas Kanashiro 

* Package name  : google-compute-image-packages
  Version  : 20180611
  Upstream Author   : Google Cloud Team 
* URL   :
https://github.com/GoogleCloudPlatform/compute-image-packages
* License : Apache-2.0
  Programming Lang: Python, C, C++
  Description    : Google Compute Engine guest environment for
cloud images

This package contains a set of scripts, configuration, and systemd init
files for features
specific to the Google Compute Engine cloud environment. They are used
on Google
Compute Engine cloud images.

-- 
Lucas Kanashiro
Collabora Ltd.

Bug#907015: openssl version 1.1.1 breaks multiple reverse dependencies; versioned Breaks needed

[Sebastian Andrzej Siewior]

On 2018-08-23 09:07:31 [+0200], Paul Gevers wrote:
> 2) enable the openssl package to collect information which packages it
> breaks and which version of those package fix the issue. With that
> information the openssl package can add versioned Breaks
> 
> We believe that the versioned Breaks are needed to enable a smooth
> upgrade path for testing users as well as for users that upgrade from
> stretch to buster. For users a Breaks is also required if the new
> OpenSSL just exposed an existing bug in the reverse dependency.

how is a versioned break helping anything? The minimal key limit, hash
and TLS version can be overriden via config file and this what is
causing the problems from what I can tell. So either the remote side
upgrades their things or the users enabled "lower security" mode.
Is there anything that skipped my mind?

Sebastian

Bug#907727: source-contains-empty-directory when a patch adds a file to that directory

[Chris Lamb]

Hi Russ,

> P: xfonts-jmk source: source-contains-empty-directory neep/ascii/
> 
> but a patch in the quilt series adds a file to that directory. 

So, we currently loop over:

foreach my $file ($info->sorted_orig_index) {

… which with "3.0 (quilt)" has the patches applied. I'm not sure how we
can get the unpatched output in this case. Any ideas?

(Parsing the diffs to catch this false-positive might be a little too
much for this corner-case.)


Regards,

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

Bug#908076: diffoscope: FTBFS: Files debian/tests/control and debian/tests/control.tmp differ

[Mattia Rizzolo]

Source: diffoscope
Version: 100
Severity: serious
Tags: pending


Log:

|dh clean --with python3 --with bash-completion --buildsystem=pybuild
|   debian/rules override_dh_auto_clean
|make[1]: Entering directory '/build/1st/diffoscope-100'
|Generating the debian/tests/control file...
|Files debian/tests/control and debian/tests/control.tmp differ
|
|The generated control file differs from the actual one.
|A sourceful upload of this package is needed.
|
|Differences:
|--- debian/tests/control   2018-08-31 20:09:48.0 -1200
|+++ debian/tests/control.tmp   2019-10-06 08:45:13.401730614 -1200
|@@ -2,7 +2,7 @@
| # EDIT debian/tests/control.in INSTEAD!
| #
| Tests: pytest-with-recommends
|-Depends: diffoscope, python3-pytest, file, abootimg, acl, apktool [!ppc64el 
!s390x], binutils-multiarch, bzip2, caca-utils, colord, db-util, 
default-jdk-headless | default-jdk | java-sdk, device-tree-compiler, docx2txt, 
e2fsprogs, enjarify, fontforge-extras, fp-utils [!ppc64el !s390x], genisoimage, 
gettext, ghc, ghostscript, giflib-tools, gnumeric, imagemagick, jsbeautifier, 
libarchive-tools, llvm, lz4, mono-utils, odt2txt, oggvideotools [!s390x], 
openssh-client, pgpdump, poppler-utils, procyon-decompiler, r-base-core, sng, 
sqlite3, squashfs-tools, tcpdump, unzip, xmlbeans, xxd | vim-common, xz-utils
|+Depends: diffoscope, python3-pytest, file, abootimg, acl, apktool [!ppc64el 
!s390x], binutils-multiarch, bzip2, caca-utils, colord, db-util, 
default-jdk-headless | default-jdk | java-sdk, device-tree-compiler, docx2txt, 
e2fsprogs, enjarify, fontforge-extras, fp-utils [!ppc64el !s390x], genisoimage, 
gettext, ghc, ghostscript, giflib-tools, gnumeric, gnupg, imagemagick, 
jsbeautifier, libarchive-tools, llvm, lz4, mono-utils, odt2txt, oggvideotools 
[!s390x], openssh-client, pgpdump, poppler-utils, procyon-decompiler, 
r-base-core, rpm2cpio, sng, sqlite3, squashfs-tools, tcpdump, unzip, xmlbeans, 
xxd | vim-common, xz-utils
| 
| Tests: pytest
| Depends: diffoscope, python3-pytest, file
|make[1]: *** [debian/rules:85: override_dh_auto_clean] Error 1
|make[1]: Leaving directory '/build/1st/diffoscope-100'
|make: *** [debian/rules:35: clean] Error 2
|dpkg-buildpackage: error: debian/rules clean subprocess returned exit status 2


This was originally caused by #908072 - and incidentally fixing this
FTBFS by just applying that diff would case diffoscope to FTBFS with
nocheck… (as v99 did, but nobody noticed).

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#908075: transition: fplll

[Tobias Hansen]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

I would like to request a transition of fplll to version 5.2.1 (currently in
experimental), on behalf of the package uploader Julien Puydt and the Debian
Science Team. The new version of the package is needed for sagemath 8.3.

The package has 3 reverse dependencies: fpylll, sollya and gap-float. I checked
that sollya and gap-float build with the new version of fplll. fpylll has to be
updated along with fplll. The new version is ready in experimental and will be
uploaded by me together with fplll.

Ben file:

title = "fplll";
is_affected = .depends ~ "libfplll4" | .depends ~ "libfplll5";
is_good = .depends ~ "libfplll5";
is_bad = .depends ~ "libfplll4";

Bug#908072: diffoscope: `bin/diffoscope --list-debian-substvars` output depends on installed packages

[Mattia Rizzolo]

Package: diffoscope
Version: 99
Severity: important

`bin/diffoscope --list-debian-substvars` depends on installed packages.

In particular, it seems "gnupg" and "rpm2cpio" are not printed if they
are not installed.
This makes d/rules generate differing d/tests/control whether the
package is built with nocheck or not.

This accidentally caused the FTBFS of version 100 (about to be
reported).

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#908073: difference between manual and program behavior

[-=}\*/{=-]

Package: tsocks
Version: 1.8beta5+ds1-1

in tsocks manual says...

   
  create a new shell with LD_PRELOAD including tsocks(8).

but when running tsocks without arguments says...

  /usr/bin/tsocks: insufficient arguments

Using: Linux 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21)
x86_64 GNU/Linux

Bug#908074: diffoscope: test failures with LLVM 7

[Mattia Rizzolo]

Source: diffoscope
Version: 99
Severity: important

Ubuntu bumped their LLVM defaults to 7 (from 6), and diffoscope is now
failing its tests:

|=== FAILURES 
===
|___ test_item3_deflate_llvm_bitcode 

|
|differences = [, , ]>]>]
|rlib_dis_expected_diff = '@@ -41,32 +41,32 @@\n entry-block:\n   %out.i.i = 
alloca i8*, align 8\n   %4 = icmp ult i64 %3, 17\n   br i1 %4, labe...able\n 
define i64 @__rust_reallocate_inplace(i8* nocapture readnone, i64, i64, i64) 
unnamed_addr #1 {\n entry-block:\n'
|
|@skip_unless_tools_exist('llvm-dis')
|@skip_unless_tool_is_at_least('llvm-config', llvm_version, '3.8')
|def test_item3_deflate_llvm_bitcode(differences, rlib_dis_expected_diff):
|assert differences[3].source1 == 
'alloc_system-d16b8f0e.0.bytecode.deflate'
|assert differences[3].source2 == 
'alloc_system-d16b8f0e.0.bytecode.deflate'
|expected_diff = rlib_dis_expected_diff
|actual_diff = differences[3].details[0].details[1].unified_diff
|>   assert diff_ignore_line_numbers(
|actual_diff) == diff_ignore_line_numbers(expected_diff)
|E   AssertionError: assert '@@ -XX,XX +X...ntry-block:\n' == '@@ -XX,XX 
+XX...ntry-block:\n'
|E   @@ -XX,XX +XX,XX @@
|Eentry-block:
|E  %out.i.i = alloca i8*, align 8
|E  %4 = icmp ult i64 %3, 17
|E  br i1 %4, label %then-block-195-.i, label 
%_ZN12alloc_system3imp8allocate17h8ba7625cc4a820e8E.exit.i
|E
|Ethen-block-195-.i:; preds = 
%entry-block
|E  %5 = tail call i8* @realloc(i8* %0, i64 %2) #2
|E   -  br label 
%_ZN12alloc_system3imp10reallocate17h4a0811c9ec086854E.exit
|E   +  br label 
%_ZN12alloc_system3imp10reallocate1l44a0811c9ec086854E.exit
|E
|E_ZN12alloc_system3imp8allocate17h8ba7625cc4a820e8E.exit.i: ; 
preds = %entry-block
|E  %6 = bitcast i8** %out.i.i to i8*
|E  call void @llvm.lifetime.start.p0i8(i64 8, i8* %6) #2
|E  store i8* null, i8** %out.i.i, align 8
|E  %7 = call i32 @posix_memalign(i8** nonnull %out.i.i, i64 %3, 
i64 %2) #2
|E  %8 = icmp eq i32 %7, 0
|E  %9 = load i8*, i8** %out.i.i, align 8
|E  %sret_slot.0.i.i = select i1 %8, i8* %9, i8* null
|E  call void @llvm.lifetime.end.p0i8(i64 8, i8* %6) #2
|E  %10 = icmp ule i64 %2, %1
|E  %11 = select i1 %10, i64 %2, i64 %1
|E -call void @llvm.memmove.p0i8.p0i8.i64(i8* align 1 
%sret_slot.0.i.i, i8* align 1 %0, i64 %11, i1 false)
|E ?    

|E +call void @llvm.memmove.p0i8.p0i8.i64(i8* %sret_slot.0.i.i, i8* 
%0, i64 %11, i32 1, i1 false) #2
|E ?
 +++ +++
|E  call void @free(i8* %0) #2
|E   -  br label 
%_ZN12alloc_system3imp10reallocate17h4a0811c9ec086854E.exit
|E   +  br label 
%_ZN12alloc_system3imp10reallocate1l44a0811c9ec086854E.exit
|E
|E   -_ZN12alloc_system3imp10reallocate17h4a0811c9ec086854E.exit: ; 
preds = %_ZN12alloc_system3imp8allocate17h8ba7625cc4a820e8E.exit.i, 
%then-block-195-.i
|E   +_ZN12alloc_system3imp10reallocate1l44a0811c9ec086854E.exit: ; 
preds = %_ZN12alloc_system3imp8allocate17h8ba7625cc4a820e8E.exit.i, 
%then-block-195-.i
|E  %sret_slot.0.i = phi i8* [ %5, %then-block-195-.i ], [ 
%sret_slot.0.i.i, %_ZN12alloc_system3imp8allocate17h8ba7625cc4a820e8E.exit.i ]
|E  ret i8* %sret_slot.0.i
|E}
|E
|E; Function Attrs: nounwind readnone uwtable
|Edefine i64 @__rust_reallocate_inplace(i8* nocapture readnone, 
i64, i64, i64) unnamed_addr #1 {
|Eentry-block:
|
|actual_diff = '@@ -42,32 +42,32 @@\n entry-block:\n   %out.i.i = alloca i8*, 
align 8\n   %4 = icmp ult i64 %3, 17\n   br i1 %4, labe...able\n define i64 
@__rust_reallocate_inplace(i8* nocapture readnone, i64, i64, i64) unnamed_addr 
#1 {\n entry-block:\n'
|differences = [, , ]>]>]
|expected_diff = '@@ -41,32 +41,32 @@\n entry-block:\n   %out.i.i = alloca i8*, 
align 8\n   %4 = icmp ult i64 %3, 17\n   br i1 %4, labe...able\n define i64 
@__rust_reallocate_inplace(i8* nocapture readnone, i64, i64, i64) unnamed_addr 
#1 {\n entry-block:\n'
|rlib_dis_expected_diff = '@@ -41,32 +41,32 @@\n entry-block:\n   %out.i.i = 
alloca i8*, align 8\n   %4 = icmp ult i64 %3, 17\n   br i1 %4, labe...able\n 
define i64 @__rust_reallocate_inplace(i8* nocapture readnone, i64, i64, i64) 
unnamed_addr #1 {\n entry-block:\n'
|
|tests/comparators/test_rlib.py:105: AssertionError


This is with:
ii  llvm (1:7.0-43ubuntu1)
ii  llvm-7 (1:7~+rc2-1~exp3)
ii  

Bug#908071: RM: sheepdog -- ROM; Not maintained, orphaned for 1.5 months

[Thomas Goirand]

Package: ftp.debian.org
Severity: normal


Hi,

Since nobody is picking-up this bug:
https://bugs.debian.org/903990

and that Sheepdog hasn't been updated for years, I think it's more
reasonable to remove the package from Debian.

Cheers,

Thomas Goirand (zigo)

Bug#906019: wireguard-dkms: DKMS module version string not correct

[Daniel Kahn Gillmor]

Control: tags 906019 + moreinfo

On Mon 2018-08-13 12:04:42 +0200, Sedat Dilek wrote:
> the version string for installed wireguard-dkms does not look correct to me.
> This should be "0.0.20180802" not "0.0.20180802-1".

I'm not convinced that this is correct.  In the event that a
debian-specific revision of the package modifies the source, we'd want
that reflected in the kernel module identification.  so including the -1
in the kernel module version number indicates this.

It also allows the local user to identify that the module used is from
the debian packaging, as opposed to some other installation method.

can you explain in more detail *why* you think the value should not
contain the debian packaging revision number?  otherwise, i'm inclined
to leave it as it is.

--dkg

Bug#907587: CONTENT_LENGTH can no longer be empty

[Jelmer Vernooij]

Git's http-backend has become slightly stricter about the content
of the CONTENT_LENGTH variable. Previously, Dulwich would leave this
variable empty but git now expects it to be set to 0 for GET requests
without a body.

I'm uploading a fixed version of dulwich.

-- 
Jelmer Vernooij 
PGP Key: https://www.jelmer.uk/D729A457.asc


signature.asc
Description: PGP signature

Bug#908070: libdazzle FTBFS: test failure

[Adrian Bunk]

Source: libdazzle
Version: 3.30.0-1
Severity: serious
Tags: ftbfs

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

...
OK:26
FAIL:   1
SKIP:   0
TIMEOUT:0


The output from the failed tests:

 1/27 test-applicationFAIL 0.09 s (killed by signal 
5 SIGTRAP)

--- command ---
G_TEST_BUILDDIR='/<>/obj-x86_64-linux-gnu/tests' MALLOC_CHECK_='2' 
GSETTINGS_BACKEND='memory' PYTHONDONTWRITEBYTECODE='yes' 
G_TEST_SRCDIR='/<>/tests' G_DEBUG='gc-friendly' 
/<>/obj-x86_64-linux-gnu/tests/test-application
--- stdout ---
/Dazzle/Application/basic: 
--- stderr ---

(/<>/obj-x86_64-linux-gnu/tests/test-application:23435): 
GLib-GIO-CRITICAL **: 12:30:40.566: g_dbus_connection_call_internal: assertion 
'object_path != NULL && g_variant_is_object_path (object_path)' failed
---

Full log written to /<>/obj-x86_64-linux-gnu/meson-logs/testlog.txt
FAILED: meson-test 
/usr/bin/python3 -u /usr/bin/meson test --no-rebuild --print-errorlogs
ninja: build stopped: subcommand failed.
dh_auto_test: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 
ninja test returned exit code 1
make[1]: *** [debian/rules:21: override_dh_auto_test] Error 1

Bug#898216: unattended-upgrades: flaky autopkgtest

[Paul Gevers]

On Fri, 6 Jul 2018 14:06:32 +0200 =?UTF-8?B?QsOhbGludCBSw6ljemV5?=
 wrote:
> I monitored the runs for some time and the test does not seem to be
> flaky in unstable. Since I added a new test with debootstrap I keep
> monitoring it and it shows to be flaky I may add retries somewhere.

September 2, 2018:
https://ci.debian.net/data/autopkgtest/testing/amd64/u/unattended-upgrades/926140/log.gz

In unstable August 23, 2018:
https://ci.debian.net/data/autopkgtest/unstable/amd64/u/unattended-upgrades/871383/log.gz

Paul



signature.asc
Description: OpenPGP digital signature

Bug#903314: kwayland: flaky autopkgtest: kwayland-testPlasmaWindowModel Exception: SIGPIPE

[Paul Gevers]

Control: reassign -1 src:kwayland 4:5.47.0-1

On Sun, 8 Jul 2018 20:13:14 +0200 Paul Gevers  wrote:
> Source: plasma-framework

This was obviously wrong. Reassigning to the right package.

Paul



signature.asc
Description: OpenPGP digital signature

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

[Adrian Bunk]

On Wed, Sep 05, 2018 at 06:58:04PM +0200, Hilmar Preuße wrote:
> On 04.09.2018 22:49, Adrian Bunk wrote:
> 
> Hi Adrian,

Hi Hilmar,

> thanks for the report!
> 
> > cd doc; rubber --warn all --pdf manual.tex
> > Traceback (most recent call last):
> >   File "/usr/bin/rubber", line 17, in 
> > sys.exit (cmdline (args))
> 
> > return codecs.ascii_decode(input, self.errors)[0]
> > UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 10: 
> > ordinal not in range(128)
> > make[2]: *** [Makefile:1917: doc/manual.pdf] Error 1
> > 
> > This is a common problem when running Python3 in C locale.
> > 
> I.e. is this a problem, which needs to be fixed in python or do /we/
> need to fix it? If the first: is there a bug report in Debian?

what defines the encoding of input files for rubber?
Currently the encoding of the locale is used,
on the buildds this is C which means ASCII.

For why3 the relevant difference is between the nonworking
  LANG=C rubber --warn all --pdf manual.tex
and the working
  LANG=C.UTF-8 rubber --warn all --pdf manual.tex

How is the input encoding of the files opened by rubber defined/set?

Similar to LaTeX, Python has become less tolerant in handling/discarding
illegal characters and treats such cases as error.

If input files are supposed to be in some fixed encoding (usually UTF-8),
then this has to be passed as parameter when opening the file.

> Hilmar

cu
Adrian

-- 

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

Bug#908069: ITP: cct -- visually comparing bacterial, plasmid, chloroplast, or mitochondrial sequences

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: cct
  Version : 20170919
  Upstream Author : Paul Stothard ,
* URL : http://stothard.afns.ualberta.ca/downloads/CCT/
* License : GPL-2+
  Programming Lang: Perl, Python, sh
  Description : visually comparing bacterial, plasmid, chloroplast, or 
mitochondrial sequences
 The CGView Comparison Tool (CCT) is a package for visually comparing
 bacterial, plasmid, chloroplast, or mitochondrial sequences of interest
 to existing genomes or sequence collections. The comparisons are
 conducted using BLAST, and the BLAST results are presented in the form
 of graphical maps that can also show sequence features, gene and protein
 names, COG category assignments, and sequence composition
 characteristics. CCT can generate maps in a variety of sizes, including
 400 Megapixel maps suitable for posters. Comparisons can be conducted
 within a particular species or genus, or all available genomes can be
 used. The entire map creation process, from downloading sequences to
 redrawing zoomed maps, can be completed easily using scripts included
 with the CCT. User-defined features or analysis results can be included
 on maps, and maps can be extensively customized. To simplify program
 setup, a CCT virtual machine that includes all dependencies preinstalled
 is available. Detailed tutorials illustrating the use of CCT are
 included with the CCT documentation.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/cct

Bug#908068: torbrowser-launcher fails with torbrowser 8.0

[gregor herrmann]

Package: torbrowser-launcher
Version: 0.2.9-3
Severity: grave
Tags: upstream
Justification: renders package unusable
User: pkg-apparmor-t...@lists.alioth.debian.org 
Usertags: buggy-profile

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Today torbrowser 8.0 was released, and after updating it (from
torbrowser 7.x, started with torbrowser-launcher), the new version
doesn't start:

% torbrowser-launcher   
Tor Browser Launcher
By Micah Lee, licensed under MIT
version 0.2.9
https://github.com/micahflee/torbrowser-launcher
Refreshing local keyring...
Keyring refreshed successfully...
  No key updates for key: EF6E286DDA85EA2A4BA7DE684E2C6E8793298290
Launching './Browser/start-tor-browser --detach'...
%


At that point AppArmor says:

Sep  5 21:21:28 jadzia kernel: [1647972.387747] audit: type=1400 
audit(1536175288.429:218): apparmor="DENIED" operation="open" 
profile="torbrowser_firefox" name="/dev/tty" pid=27409 comm="firefox" 
requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=0
Sep  5 21:21:28 jadzia kernel: [1647972.389168] audit: type=1400 
audit(1536175288.429:219): apparmor="DENIED" operation="exec" 
profile="torbrowser_firefox" name="/usr/bin/dirname" pid=27410 comm="firefox" 
requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
Sep  5 21:21:28 jadzia kernel: [1647972.389200] audit: type=1400 
audit(1536175288.429:220): apparmor="DENIED" operation="open" 
profile="torbrowser_firefox" name="/usr/bin/dirname" pid=27410 comm="firefox" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0


Trying to start the browser manually is not better:

% 
~/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/start-tor-browser
 --verbose
./firefox: line 3: /usr/bin/dirname: Permission denied
./firefox: line 14: /firefox.real: No such file or directory


And AppArmor details:

Sep  5 21:22:36 jadzia kernel: [1648040.572592] audit: type=1400 
audit(1536175356.609:221): apparmor="DENIED" operation="open" 
profile="torbrowser_firefox" name="/dev/tty" pid=28449 comm="firefox" 
requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=0
Sep  5 21:22:36 jadzia kernel: [1648040.573203] audit: type=1400 
audit(1536175356.609:222): apparmor="DENIED" operation="exec" 
profile="torbrowser_firefox" name="/usr/bin/dirname" pid=28450 comm="firefox" 
requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
Sep  5 21:22:36 jadzia kernel: [1648040.573224] audit: type=1400 
audit(1536175356.609:223): apparmor="DENIED" operation="open" 
profile="torbrowser_firefox" name="/usr/bin/dirname" pid=28450 comm="firefox" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0


Same for the version in experimental (0.3.0~dev-1~exp3).


I suppose this needs "just" some AppArmor tweaks but I was not
successful in the first few tries (it's a bit of a rabbit hole for a
layperson like me, after dirname comes firefox.real, and then
something about libstdc++.so.6 …).


Cheers,
gregor


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

Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_AT.utf8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages torbrowser-launcher depends on:
ii  ca-certificates   20180409
ii  gnupg 2.2.10-1
ii  libdbus-glib-1-2  0.110-3
ii  python2.7.15-3
ii  python-gtk2   2.24.0-5.1+b1
ii  python-lzma   0.5.3-3.1
pn  python-parsley
pn  python-psutil 
ii  python-twisted18.7.0-2
pn  python-txsocksx   

Versions of packages torbrowser-launcher recommends:
ii  tor  0.3.3.9-1

Versions of packages torbrowser-launcher suggests:
ii  apparmor   2.13-8
ii  python-pygame  1.9.3+dfsg2-2

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAluQMU5fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgaWZRAAnSKawPgJyZ6ncZ9V76ANmlWF0i7i4lJH5MBUu83ZvcRppBEXjZHM/RD6
Xqtn8G7qhZKcvswm5nMVbGwep9Afk2+SugWHXBpy2RU365a68zj437uxtaHkfVrl
NP7BWf7o2wSbWeU/vNmCAB7i++BJCM6CZnWY4/gEeJ7/badyr2xVnNzjAKc1wMxh
jWoXnZTf/K/4jgOS55GUDOJrqDTRBugYVoDWT6mlByoiBHmmvj5pdUm9hsMH40BC
+9SETYSV16sNUCmdT1RCjgnq8c2xv08CkcXjV+sv6IrgvP4AcXQ66+mcNbx9a/Ii
mSIWxne4n03BymfPLIOcSptFGafZH55jliTxvkqcZ5KreDLmN76gR+U/3gqmnyFo
gDGyPl64RVyJxgbE1HVAQvgCat+f9JotQ/5PYw/ddzJyrB+u6MN0KvM7nIkToKOi
WNXfCzWZ9gYjESw1fh1LXUm2PVewrMlrPxP/DqRFYeh6kk16w6Q4Y9smD2N+YLzg
Qb3jbFxsTuCVKEsZmxkYhUZFakyPXFVj4EAhCbZ9FEF59QuNQv7fHYtTTxYkX0DC
5QDZs265KueZGHAQbTNEHe1/bOxsoHHyBDvNgOaTDjGtGWFNB/FhYm0ZiFGtFgdE
UMQmVFUf/Q9pn6FVsn4MYT6RxbhX46xyfeqO2o/s0uaS+RlleYI=
=hTCu
-END PGP SIGNATURE-

Bug#908034: thunderbird: should set intl.locale.requested to the empty string by default

[Carsten Schoenert]

Control: severity -1 serious

Hello Sven,

On Wed, Sep 05, 2018 at 11:18:56AM +0200, Sven Joachim wrote:
... 
> Today I upgraded from 1:52.9.1-1 and found thunderbird's UI in English,
> which could be rectified by setting intl.locale.requested to "de" in
> about:config, as mentioned in README.Debian.  However, there seems to be
> a better way: by setting intl.locale.requested to the empty string,
> thunderbird actually obeys the locale setting again, i.e. with LANG=C it
> starts in English, with LANG=de_DE.UTF-8 in German.  This is mentioned
> in https://bugzilla.mozilla.org/show_bug.cgi?id=1413866#c21.
> 
> Therefore I think that /etc/thunderbird/pref/thunderbird.js should
> contain the following line:
> 
> pref("intl.locale.requested", "");
> 
> Maybe this helps for lightning too - I don't use lightning, so I have
> not tested it.

thanks for this useful hint!
I tested this and yes, it works, also for Lighting and other AddOns!
Sadly the upstream maintainers probably didn't know this behaviour of
this new setting and didn't had any useful information for me and the
packaging of Thunderbird.

I've tagged the severity of your report to serious to prevent the
transition of the current Thunderbird to testing so people don't need or
do start to modify their settings.

I will upload a new modified version of Thunderbird in the next
hours/day.

Regards
Carsten

Bug#908067: lsmount: does not build on hurd-i386

[Andreas Schwarz]

Package: lsmount
Version: 0.2.2-1
Severity: serious
Tags: upstream
Justification: fails to build from source

Dear myself,

lsmount does not build on hurd-i386 because it uses the PATH_MAX macro

POSIX describes the constant PATH_MAX and similar, 
which _may_ be defined by the system to indicate certain limits. 

Hurd doesn't define the macros.

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

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

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

lsmount recommends no packages.

lsmount suggests no packages.

-- no debconf information

Bug#904776: /usr/bin/dpkg-source: please parse d/t/control.autodep8 like d/t/control

[Paul Gevers]

Please consider this a polite ping.

On 19-08-18 21:38, Paul Gevers wrote:
> Hi Guillem,
> 
> This bug is still marked as moreinfo, are you still waiting for more
> input from me?
> 
> Paul

Paul



signature.asc
Description: OpenPGP digital signature

Bug#907655: xserver-xorg-core: X don't start with the latest package version

[Davide Prina]

On 05/09/2018 20:13, Davide Prina wrote:


If I install xserver-xorg-core 2:1.20.1-1 X don't start
If I install xserver-xorg-core 2:1.19.6-1 X start


I have installed xserver-xorg-core version (taken from snapshot.debian.org):
* 2:1.20.0-3 X don't start
* 2:1.20.0-2 X don't start
* 2:1.20.0-1 X don't start
* 2:1.19.99.901-1 X don't start

Ciao
Davide

--
Dizionari: http://linguistico.sourceforge.net/wiki
Database: http://www.postgresql.org
GNU/Linux User: 302090: http://counter.li.org
Non autorizzo la memorizzazione del mio indirizzo su outlook

Bug#908066: vim uses an incorrect URL parser

[Keller Fuchs]

Source: vim
Version: 2:8.0.0197-4+deb9u1
Severity: normal
Tags: upstream stretch

Hello,

I just noticed that vim allows one to open a URL directly (for instance,
`vim 'https://hashbang.sh/'`), but its URL parser fails when the URL has
an empty path component (i.e. `vim 'https://hashbang.sh'` fails).

I thought it was a bug worth reporting, though I was not in a position to
test whether I could reproduce it on buster.


Best,

  Keller Fuchs  :3


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

Kernel: Linux 4.9.0-6-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF8, LC_CTYPE=en_US.UTF8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF8 (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)

Bug#908065: r-cran-adegraphics: autopkgtest regression: dependency versions not properly specified

[Paul Gevers]

Source: r-cran-adegraphics
Version: 1.0-12-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With the upload of 1.0-12-1 the autopkgtest of your package started to
fail when run in testing (it runs fine in unstable). I copied the output
below.

Currently this regression is contributing to the delay of the migration
to testing [1]. Could you please investigate the situation and fix it?
If needed, please change the bug's severity as appropriate.

Looking at the error, you seem to be missing a versioned (test)
dependency on r-cran-ade4. A similar issue can be seen when
r-cran-treescape [2] or r-cran-treespace [3] is tested in testing, with
r-cran-adegraphics from unstable. Seems like r-cran-adegraphics breaks
the versions of r-cran-treescape and r-cran-treespace in testing.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=r-cran-adegraphics
[2]
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treescape/941304/log.gz
[3]
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treespace/941302/log.gz

https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-adegraphics/941314/log.gz

autopkgtest [16:01:12]: test run-unit-test: [---

R version 3.5.1 (2018-07-02) -- "Feather Spray"
Copyright (C) 2018 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

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

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

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

> library(adegraphics)
Error: package or namespace load failed for 'adegraphics' in
loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()), versionCheck =
vI[[j]]):
 namespace 'ade4' 1.7-11 is being loaded, but >= 1.7.13 is required
Execution halted
autopkgtest [16:01:13]: test run-unit-test: ---]



signature.asc
Description: OpenPGP digital signature

Bug#908064: diaspora-installer: please update to 0.7.6.0

[Gianfranco Costamagna]

Source: diaspora-installer
Version: 0.7.4.0+nmu1
Severity: important
Tags: patch

This new release drops sigar, that is unmaintained and FTBFS with glibc
2.28

I might NMU later this month or next one, because this will become RC once 
glibc 2.28 goes in unstable.

Thanks for caring, I'm attaching a diff right now (note: I can't test on 
pbuilder, so I presume
the fix works by the fact that the testsuite is now completely green)

thanks

Gianfranco
diff -Nru diaspora-installer-0.7.4.0+nmu1/debian/changelog 
diaspora-installer-0.7.6.0~build1/debian/changelog
--- diaspora-installer-0.7.4.0+nmu1/debian/changelog2018-08-30 
10:59:22.0 +0200
+++ diaspora-installer-0.7.6.0~build1/debian/changelog  2018-09-03 
10:03:38.0 +0200
@@ -1,3 +1,9 @@
+diaspora-installer (0.7.6.0) unstable; urgency=medium
+
+  * Update to 0.7.6.0, drop sigar dependency
+
+ -- Gianfranco Costamagna   Mon, 03 Sep 2018 
10:03:38 +0200
+
 diaspora-installer (0.7.4.0+nmu1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru diaspora-installer-0.7.4.0+nmu1/debian/postinst 
diaspora-installer-0.7.6.0~build1/debian/postinst
--- diaspora-installer-0.7.4.0+nmu1/debian/postinst 2018-03-27 
08:41:03.0 +0200
+++ diaspora-installer-0.7.6.0~build1/debian/postinst   2018-09-03 
10:03:36.0 +0200
@@ -40,10 +40,6 @@
 echo "Installing latest version of bundler..."
gem install bundler
 
-   echo "Setting build flags for Sigar as workaround for \
-   https://github.com/hyperic/sigar/issues/60 ..."
-su diaspora -s /bin/sh -c "bundle config --local build.sigar 
'--with-cppflags=\"-fgnu89-inline\"'"
-
echo "Installing gems with rubygems ..."
su ${diaspora_user} -s /bin/sh -c "mkdir -p ~/vendor/bundle"
su ${diaspora_user} -s /bin/sh -c "touch ~/Gemfile.lock && truncate -s 
0 ~/Gemfile.lock"
diff -Nru diaspora-installer-0.7.4.0+nmu1/diaspora-common.conf 
diaspora-installer-0.7.6.0~build1/diaspora-common.conf
--- diaspora-installer-0.7.4.0+nmu1/diaspora-common.conf2018-03-27 
08:41:03.0 +0200
+++ diaspora-installer-0.7.6.0~build1/diaspora-common.conf  2018-09-03 
10:03:38.0 +0200
@@ -1,5 +1,5 @@
 # If diaspora_version is changed, update sha256sums as well
-export diaspora_version=0.7.4.0
+export diaspora_version=0.7.6.0
 # possible values branch, tag
 export diaspora_release_type=tag
 export github_archive_url=https://github.com/diaspora/diaspora/archive
diff -Nru diaspora-installer-0.7.4.0+nmu1/sha256sums 
diaspora-installer-0.7.6.0~build1/sha256sums
--- diaspora-installer-0.7.4.0+nmu1/sha256sums  2018-03-27 08:41:03.0 
+0200
+++ diaspora-installer-0.7.6.0~build1/sha256sums2018-09-03 
10:03:38.0 +0200
@@ -1 +1 @@
-a1e62b83d1aa81acf5ccc0f8a30472d7528b3acc46c6041ee334825257d609f6 
/var/cache/diaspora-installer/diaspora-0.7.4.0.tar.gz
+a2b7b2e432a8a914f38aa692187b56171be7377011016d7f94c79cd74531efd0 
/var/cache/diaspora-installer/diaspora-0.7.6.0.tar.gz

Bug#907655: xserver-xorg-video-mga: X don't start with the latest package version

[Davide Prina]

On 08/30/2018 09:10 PM, Davide Prina wrote:

Package: xserver-xorg-video-mga
Version: 1:1.6.5-1
Severity: grave
Justification: renders package unusable


I see now that I make a mistake :-(
My video is gma and not mga

$ lsmod | grep gma | cut -d ' ' -f 1
gma500_gfx
drm_kms_helper
drm
i2c_algo_bit
video

so the package that don't let me to have a X starting is not
xserver-xorg-video-mga, but it is xserver-xorg-core.

If I install xserver-xorg-core 2:1.20.1-1 X don't start
If I install xserver-xorg-core 2:1.19.6-1 X start

Please change the Subject to xserver-xorg-core and move the bug to this 
package.


Let me know if I can do some test and give you more info.

thanks
Davide

Bug#908001: Removal of currently running kernel is prevented by "Failed to substitute package name in title: ..."

[Ben Hutchings]

Control: retitle -1 debconf: Fails to populate template cache during package 
removal
Control: reassign -1 src:debconf
Control: affects -1 linux-base

On Wed, 2018-09-05 at 03:00 +0200, Lars Kruse wrote:
> Package: linux-base
> Version: 4.5
> Severity: normal
> 
> Dear Maintainer,
> 
> I recently encountered the following situation while trying to remove the
> package of a currently running kernel:
> 
> root@router-foo:~# apt purge linux-image-4.9.0-6-amd64
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following packages will be REMOVED:
>   linux-image-4.9.0-6-amd64*
> 0 upgraded, 0 newly installed, 1 to remove and 24 not upgraded.
> After this operation, 193 MB disk space will be freed.
> Do you want to continue? [Y/n]
> (Reading database ... 50646 files and directories currently installed.)
> Removing linux-image-4.9.0-6-amd64 (4.9.88-1+deb9u1) ...
> Failed to substitute package name in title: 10 at /usr/bin/linux-check-removal
> line 102,  line 1. dpkg: error processing package
> linux-image-4.9.0-6-amd64 (--remove): subprocess installed pre-removal script
> returned error exit status 255 Errors were encountered while processing:
>  linux-image-4.9.0-6-amd64
> E: Sub-process /usr/bin/dpkg returned an error code (1)
[...]
> The only specific detail of the problematic environment is probably the
> fact, that /var/cache is stored on a tmpfs and thus is regularly
> discarded on every reboot.
[...]

This is an unusual configuration, but apparently valid (according to
the FHS).

Currently debconf only populates the cache during package installation
and in dpkg-reconfigure.  This means that asking any questions during
package removal has the same problem.  I verified that the same failure
occurs when attempting to remove an old kernel package that has a
similar prompt using its own template.

I think debconf should populate the cache from package template files
on-demand, using the first part of the template name as the package
name.

Ben.

-- 
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett




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

Bug#740891: listadmin: insecure use of /tmp

[Gunnar Wolf]

tags 740891 + pending
thanks

The package has been uploaded to DELAYED (5 days).

Bug#873287: listadmin: insecure use of /tmp

[Gunnar Wolf]

tags 873287 + pending
thanks

The package has been uploaded to DELAYED (5 days).

Bug#904652: pulseaudio: looses device and replace it with dummy package so no sound possible

[Meinolf Gödde]

Am 29.08.2018 00:46 schrieb Felipe Sateler:
On Sat, Aug 11, 2018 at 9:54 AM Meinolf Gödde  
wrote:



The problem is back again. So i hope it helps.



The log file is empty :(.

here it is


Anyway, are you using MATE? Another bug with the same symptoms seems to 
be

caused by the mate volume manager (see bug #906622).

SaludosI: [pulseaudio] main.c: setrlimit(RLIMIT_NICE, (31, 31)) failed: Die Operation 
ist nicht erlaubt
I: [pulseaudio] main.c: setrlimit(RLIMIT_RTPRIO, (9, 9)) failed: Die Operation 
ist nicht erlaubt
D: [pulseaudio] core-rtclock.c: Timer slack is set to 50 us.
D: [pulseaudio] core-util.c: RealtimeKit worked.
I: [pulseaudio] core-util.c: Successfully gained nice level -11.
I: [pulseaudio] main.c: This is PulseAudio 12.0
D: [pulseaudio] main.c: Compilation host: x86_64-pc-linux-gnu
D: [pulseaudio] main.c: Compilation CFLAGS: -g -O2 
-fdebug-prefix-map=/build/pulseaudio-ZS3GKw/pulseaudio-12.0=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -W -Wextra 
-pipe -Wno-long-long -Wno-overlength-strings -Wunsafe-loop-optimizations 
-Wundef -Wformat=2 -Wlogical-op -Wsign-compare -Wformat-security 
-Wmissing-include-dirs -Wformat-nonliteral -Wpointer-arith -Winit-self 
-Wdeclaration-after-statement -Wfloat-equal -Wmissing-prototypes 
-Wredundant-decls -Wmissing-declarations -Wmissing-noreturn -Wshadow 
-Wendif-labels -Wcast-align -Wstrict-aliasing -Wwrite-strings 
-Wno-unused-parameter -ffast-math -fno-common -fdiagnostics-show-option 
-fdiagnostics-color=auto
D: [pulseaudio] main.c: Running on host: Linux x86_64 4.17.0-3-amd64 #1 SMP 
Debian 4.17.17-1 (2018-08-18)
D: [pulseaudio] main.c: Found 4 CPUs.
I: [pulseaudio] main.c: Page size is 4096 bytes
D: [pulseaudio] main.c: Compiled with Valgrind support: no
D: [pulseaudio] main.c: Running in valgrind mode: no
D: [pulseaudio] main.c: Running in VM: no
D: [pulseaudio] main.c: Optimized build: yes
D: [pulseaudio] main.c: FASTPATH defined, only fast path asserts disabled.
I: [pulseaudio] main.c: Machine ID is 2e89375b18d542bdaf4ac210ad79f30b.
I: [pulseaudio] main.c: Session ID is 2.
I: [pulseaudio] main.c: Using runtime directory /run/user/1000/pulse.
I: [pulseaudio] main.c: Using state directory /home/meinolf/.config/pulse.
I: [pulseaudio] main.c: Using modules directory /usr/lib/pulse-12.0/modules.
I: [pulseaudio] main.c: Running in system mode: no
E: [pulseaudio] pid.c: Daemon already running.
E: [pulseaudio] main.c: pa_pid_file_create() fehlgeschlagen.

Bug#867140: cqrlog: Please migrate to openssl1.1 in Buster

[Petr Hlozek]

Recent version (2.3.0) of CQRLOG already supports openssl1.1. New
version will be released soon.

73 Petr
út 4. 9. 2018 v 23:27 odesílatel Moritz Mühlenhoff  napsal:
>
> On Fri, Oct 13, 2017 at 08:49:21AM +0100, Colin Tuckley wrote:
> > > this is a remainder about the openssl transition [0]. We really want to
> > > remove libssl1.0-dev from unstable for Buster. I will raise the severity
> > > of this bug to serious in a month. Please react before that happens.
> >
> > I've talked to upstream about this. Apparently it will be a *lot* of
> > work due to the API changes without a soname bump. As a result upstream
> > are giving the required changes a very low priority.
>
> What's the current status? openssl 1.0.2 will be EOLed next year, so this
> is also something that affects cqrlog users outside of Debian.
>
> Cheers,
> Moritz
>


-- 
ex OK2CQR
https://hamqth.com/ok7an
https://ok7an.com
https://www.cqrlog.com/

Bug#908063: sylpheed: TLS connection to imap.gmail.com returns self-signed certificate with openssl 1.1.0

[Antonio Ospite]

Package: sylpheed
Version: 3.7.0-3+b1
Severity: important
Tags: upstream patch

Dear Maintainer,

when using openssl 1.1.0 (now in Unstable) the gmail servers require
clients to set the Server Name Indication, responding with an invalid
self-signed certificate if this is not the case.

Sylpheed does not set the SNI.

Here is a link to the upstream bug report in which I provide a patch and
a link to a better explanation:
https://sylpheed.sraoss.jp/redmine/issues/306

Thanks,
   Antonio

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

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

Versions of packages sylpheed depends on:
ii  libassuan0   2.5.1-2
ii  libatk1.0-0  2.28.1-1
ii  libc62.27-6
ii  libcairo21.15.12-1
ii  libcompfaceg11:1.5.2-5+b2
ii  libenchant1c2a   1.6.0-11.1
ii  libfontconfig1   2.13.0-5
ii  libfreetype6 2.8.1-2
ii  libfribidi0  1.0.5-3
ii  libgdk-pixbuf2.0-0   2.36.12-2
ii  libglib2.0-0 2.58.0-2
ii  libgpg-error01.32-1
ii  libgpgme11   1.11.1-1
ii  libgtk2.0-0  2.24.32-3
ii  libgtkspell0 2.0.16-1.2
ii  libldap-2.4-22.4.46+dfsg-5
ii  libonig5 6.8.2-1
ii  libpango-1.0-0   1.42.4-2
ii  libpangocairo-1.0-0  1.42.4-2
ii  libpangoft2-1.0-01.42.4-2
ii  libssl1.11.1.1~~pre9-1
ii  pinentry-gtk21.1.0-1+b1

Versions of packages sylpheed recommends:
ii  aspell-it [aspell-dictionary]  2.4-20070901-0-3
ii  bogofilter 1.2.4+dfsg1-13
ii  bsfilter   1:1.0.19-2
ii  ca-certificates20180409
ii  sylpheed-i18n  3.7.0-3

Versions of packages sylpheed suggests:
pn  claws-mail-tools  
ii  curl  7.61.0-1
pn  sylpheed-doc  
ii  sylpheed-plugins  3.7.0-3+b1

-- no debconf information
-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

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

[Ben Hutchings]

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

Indeed.  The use of Javascript makes WPAD implementation quite risky. 
There are other dangers in implementating WPAD; for example see
.

It could be useful, and maybe even worth enabling by default, if it was
supported in all (or at least most) of the different HTTP libraries we
ship.  But I don't think we're anywhere near there, so supporting it at
installation time only doesn't seem worth the trouble.

Ben.

-- 
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett



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

Bug#740891: listadmin: insecure use of /tmp

[Gunnar Wolf]

tags 740891 + patch
thanks

I am proposing the following patch for this package:

Index: listadmin-2.42/listadmin.pl
===
--- listadmin-2.42.orig/listadmin.pl
+++ listadmin-2.42/listadmin.pl
@@ -29,6 +29,7 @@ use strict;
 use English;
 use IO::Socket::SSL;
 use Net::INET6Glue::INET_is_INET6;
+use File::Temp qw(:mktemp);
 
 my $rc = $ENV{"HOME"}."/.listadmin.ini";
 
@@ -727,12 +728,12 @@ sub get_list {
 
 if ($page !~ get_trans_re("pending_req")) {
my $msg = "unexpected contents";
-   # Use rand() to protect a little against tmpfile races
-   $dumpfile ||= "/tmp/dump-" . rand() . "-$list.html";
-   if (open(DUMP, ">$dumpfile")) {
+   if (! defined($dumpfile) or $dumpfile eq '') {
+   my $dumpfh;
+   ($dumpfh, $dumpfile) = mkstemps('/tmp/dump-', 
"-$list.html");
chmod(0600, $dumpfile);
-   print DUMP $page;
-   close(DUMP);
+   print $dumpfh $page;
+   close($dumpfh);
$msg .= ", please send $dumpfile to $maintainer";
}
return {servererror => $msg, url => $url};


I will be preparing an NMU fixing this bug and #873287 and uploading
to DELAYED-5.

Greetings!


signature.asc
Description: PGP signature

Bug#908061: RFS: rapid-photo-downloader/0.9.11-1

[Antoine Beaupré]

Control: owner -1 anar...@debian.org

On 2018-09-05 18:39:07, Jörg Frings-Fürst wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
>   I am looking for a sponsor for my package "rapid-photo-downloader"

Hi!

As the uploader for the package, I'll be happy to sponsor this.

I've reviewed your changes and they seem mostly good. However, they seem
to omit some changes I've uploaded to the git repository 4 weeks ago:

https://salsa.debian.org/debian/rapid-photo-downloader

... namely:

https://salsa.debian.org/debian/rapid-photo-downloader/commit/ff0358a5e0783fb2464391cd06d02021a881ccae
https://salsa.debian.org/debian/rapid-photo-downloader/commit/c0027837223b83325d653a59146e16d2206fcccf

Those are necessary (I think?) to completely fix #900709.

With those changes, I'll be happy to do the upload.

I would also encourage you to register on salsa.debian.org and upload
your changes there, as it will make future collaboration easier: it
would have avoided such confusion, for example.

Thanks!

A.

-- 
The value of a college education is not the learning of many facts but
the training of the mind to think.
   - Albert Einstein

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

[Hilmar Preuße]

On 04.09.2018 22:49, Adrian Bunk wrote:

Hi Adrian,

thanks for the report!

> cd doc; rubber --warn all --pdf manual.tex
> Traceback (most recent call last):
>   File "/usr/bin/rubber", line 17, in 
> sys.exit (cmdline (args))

> return codecs.ascii_decode(input, self.errors)[0]
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 10: 
> ordinal not in range(128)
> make[2]: *** [Makefile:1917: doc/manual.pdf] Error 1
> 
> This is a common problem when running Python3 in C locale.
> 
I.e. is this a problem, which needs to be fixed in python or do /we/
need to fix it? If the first: is there a bug report in Debian?

Hilmar
-- 
sigfault
#206401 http://counter.li.org

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

[Antoine Beaupré]

On 2018-09-05 12:50:07, Antoine Beaupre wrote:
> dch --lts currently creates a changelog entry for wheezy and a +deb7uX
> version number. wheezy is now ELTS and it's jessie that's LTS.
>
> The attached patch should fix this.

The patch was also pushed to the git repository.
-- 
What this country needs is more unemployed politicians.
- Angela Davis

Bug#907313: Lack of guidelines on purging conffiles in stateless packages

[Ian Jackson]

Gioele Barabucci writes ("Bug#907313: Lack of guidelines on purging conffiles 
in stateless packages"):
> Most of the current base programs still work in this way, but I suppose 
> that it is only a matter of time before everything will switch to the 
> stateless paradigm (that is in need of a better name). It is just too 
> convenient. At that point the state "configured" would have little 
> sense, same thing for the "apt --purge remove" command.

I think we are lookng at this slightly from the wrong perspective.

Why might a user (sysadmin) purge a package ?

I can think of the following reasons:

(i) The package was removed but some of its leftover config content
(eg hook files provided in other packages' .d directories - init
scripts are an example) have bugs which are now causing lossage.

(ii) The user intents to reinstall it but wants a completely fresh,
vanilla, default install.

(iii) The package, even when removed, uses an inconvenient amount of
disk space.

(iv) The package's content in /etc is clutter (getting in the way of
listings, tab completion, etckeeper diffs, etc. etc.)

The idea that config supplied by the user by creating files should be
kept, but the config supplied by the user by editing files should be
removed, doesn't seem to fit into the above.

I think it only makes sense in a world where the latter don't exist.
Debian is not such a world, even though some packages are.

(Of course a package foobar must not delete its /etc/foobar.d
directory completely, even on purge, because another package may have
put a dropping into it.)

Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#907518: workaround

[Raphaël Rigo]

Hello,
I have been bitten by the same problem, which stems from the following
Debian change:

openssl (1.1.1~~pre6-1) experimental; urgency=medium
  * Increase default security level from 1 to 2. This moves from the 80
bit security level to the 112 bit securit level and will require 2048
bit RSA and DHE keys.

You can change the default security level in /etc/ssl/openssl.cnf by
setting

CipherString=DEFAULT@SECLEVEL=1

Hope this helps,
Raphaël

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

[Antoine Beaupre]

Package: devscripts
Version: 2.18.3
Severity: normal
File: /usr/bin/debchange
Tags: patch

dch --lts currently creates a changelog entry for wheezy and a +deb7uX
version number. wheezy is now ELTS and it's jessie that's LTS.

The attached patch should fix this.

-- Package-specific info:

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

--- ~/.devscripts ---
DEBEMAIL=anar...@debian.org
RMADISON_DEFAULT_URL=debian,ubuntu
DEBSIGN_KEYID=8DC901CE64146C048AD50FBB792152527B75921E
DEB_SIGN_KEYID=8DC901CE64146C048AD50FBB792152527B75921E

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.0.5
ii  libc6 2.27-5
ii  libfile-homedir-perl  1.004-1
ii  perl  5.26.2-7
ii  python3   3.6.5-3
ii  sensible-utils0.0.12

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

Versions of packages devscripts suggests:
pn  adequate  
ii  autopkgtest   5.5
pn  bls-standalone
ii  bsd-mailx [mailx] 8.1.2-0.20180807cvs-1
ii  build-essential   12.5
pn  check-all-the-things  
pn  cvs-buildpackage  
pn  devscripts-el 
ii  diffoscope99
ii  disorderfs0.5.3-2
pn  dose-extra
pn  duck  
ii  faketime  0.9.7-2
ii  gnuplot   5.2.2+dfsg1-2
ii  gnuplot-x11 [gnuplot] 5.2.2+dfsg1-2
ii  gpgv  2.2.10-1
ii  how-can-i-help16
ii  libauthen-sasl-perl   2.1600-1
ii  libfile-desktopentry-perl 0.22-1
pn  libnet-smtps-perl 
pn  libterm-size-perl 
ii  libtimedate-perl  2.3000-2
pn  libyaml-syck-perl 
pn  mozilla-devscripts
ii  mutt  1.10.1-2
ii  openssh-client [ssh-client]   1:7.8p1-1
pn  piuparts  
ii  postgresql-client 10+193
ii  postgresql-client-10 [postgresql-client]  10.5-1
ii  quilt 0.65-2
pn  ratt  
ii  reprotest 0.7.8
pn  svn-buildpackage  
ii  w3m   0.5.3-36+b1

-- no debconf information
>From 863ba24427b083d4e74ce67dcd09307caff1e69d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
Date: Wed, 5 Sep 2018 12:44:13 -0400
Subject: [PATCH] bump LTS version number (Closes: #-1)

Wheezy is now ELTS and jessie is the new LTS.
---
 scripts/debchange.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/debchange.pl b/scripts/debchange.pl
index b9eed2a9..374e84b8 100755
--- 

Bug#908061: RFS: rapid-photo-downloader/0.9.11-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 "rapid-photo-downloader"

   Package name: rapid-photo-downloader
   Version : 0.9.11-1
   Upstream Author : Damon Lynch 
   URL : https://damonlynch.net/rapid
   License : GPL-2+
   Section : graphics

  It builds those binary packages:

rapid-photo-downloader - Photo downloader (importer) from cameras,
memory cards, other dev

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

  https://mentors.debian.net/package/rapid-photo-downloader


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

dget -x 
https://mentors.debian.net/debian/pool/main/r/rapid-photo-downloader/rapid-photo-downloader_0.9.11-1.dsc

git: 
https://jff.email/cgit/rapid-photo-downloader.git/?h=release%2Fdebian%2F0.9.11-1


  Changes since the last upload:

  * New upstream release.
- Refresh patches.
  * debian/control:
- Change VCS-* to point to the new repository.
  * debian/copyright:
- Use secure copyright format URI.
- Change source to new homepage.
- Add year 2018 to Antoine Beaupré.
  * debian/watch:
- Use secure URI.
  * 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+AHX8jUOrs1qzDuCfifPIyh0l0FAluQBqsACgkQCfifPIyh
0l3GDhAAxQysiYBzoyexRwibfHJuRpiPayKA0d9kUmhxKcRov71gVWfpnFdxA6fp
oIvsYdMNs6C6yaWc0Im4jnkuZw/2lU9hRfgKjXgo2XXlMdd0tf0vBj6KG3AA+1+2
6TWJ62XnfC2WcSqqqvOG22JlmHO+4ppzasdCeTI8AXytGrI54h/TGArsCjkmN+mQ
rOU3Vktbl5d/1H2FNCH1ydfPRPthdFjSGTFyWwkC69r1VvBwaZROa65v+3IsoRdx
oF9FMoCKzWT+utvu4HK9AFNETAKo+uZMch7rPI1jy+TzaOG+Bggu2iPuVJcCbh6V
y+BItMc8WOdeXMuqfs+1bFkR/I+Zia6XdNAl+f1hrChv+Cc0LPRxhKeAcarwu5F+
TEV0InpbcA3QNC4lS1oyvIdpiYJpeODHbhivc29011hp7k5N8yYkysuQWvzqplRZ
7KgoDD9HH9sVrfUkACpDPEy0QKm7P6atfjmrnJipfnV1Z/OQVs6SqqmlWq1Zrz1W
9cGXTOGESHzrSlnN9z6O6Tg57RrB/3446+jKJwjAalPYMJtV5sPAZG5ar46I+4V9
c5lJKozcXhLdoS5LK64fTLvKOp8pVF4QyWZxZWOWjcB6dMY8A+GJyaShejSvcILE
vVKym+Wj4jvloZxZQFycq3LIIALWga025rb/16+DuWw948BF4rc=
=B8bg
-END PGP SIGNATURE-

Bug#908060: fakeroot: Extracting files with set file capabilites using tar results invalid mode

[Balint Reczey]

Package: fakeroot
Version: 1.23-1

Dear Maintainer,

The following operation fails with fakeroot but works with sudo:

$ fakeroot  bash -c "touch asd && chmod 0775 asd && setcap
cap_net_raw+ep asd && tar --xattrs -czf asd.tar.gz asd && rm asd"
$ fakeroot bash -c "tar --xattrs-include='*' -xf asd.tar.gz && file
asd ; getcap asd"
asd: ERROR: invalid mode 0775
$ sudo bash -c "tar --xattrs-include='*' -xf asd.tar.gz && file asd ;
getcap asd"
asd: empty
asd = cap_net_raw+ep

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#908059: Additional information

[Hank Barta]

GDB examination of core file
hbarta@rocinante:~$ ls -l core
-rw--- 1 hbarta hbarta 104566784 Sep  5 11:18 core
hbarta@rocinante:~$ file core
core: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), SVR4-style, from
'/usr/bin/Xwayland :0 -rootless -terminate -accessx -core -listen 4 -listen
5 -d', real uid: 1000, effective uid: 1000, real gid: 1000, effective gid:
1000, execfn: '/usr/bin/Xwayland', platform: 'x86_64'
hbarta@rocinante:~$ gdb /usr/bin/Xwayland  core
GNU gdb (Debian 8.1-4) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/Xwayland...Reading symbols from
/usr/lib/debug/.build-id/b0/5eff2ea3c555f3a53cada3613925b052be1363.debug...done.
done.
[New LWP 5433]
[New LWP 5440]
[New LWP 5437]
[New LWP 5442]
[New LWP 5443]
[New LWP 5439]
[New LWP 5438]
[New LWP 5434]
[New LWP 5444]
[New LWP 5441]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/Xwayland :0 -rootless -terminate -accessx
-core -listen 4 -listen 5 -d'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x7f7ac5b4f640 (LWP 5433))]
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x7f7ac72622f1 in __GI_abort () at abort.c:79
#2  0x55680fc7a30a in OsAbort () at ../../../../os/utils.c:1350
#3  0x55680fc7fe13 in AbortServer () at ../../../../os/log.c:877
#4  0x55680fc80c79 in FatalError (f=f@entry=0x55680fca3fb0 "Caught
signal %d (%s). Server aborting\n") at ../../../../os/log.c:1015
#5  0x55680fc77721 in OsSigHandler (signo=11, sip=,
unused=) at ../../../../os/osinit.c:156
#6  
#7  0x7f7abf517fe0 in st_renderbuffer_delete (ctx=0x55681106d610,
rb=0x5568114f55f0) at ../../../src/mesa/state_tracker/st_cb_fbo.c:239
#8  0x7f7abf47eb11 in _mesa_reference_renderbuffer_
(ptr=ptr@entry=0x556811563748,
rb=rb@entry=0x0) at ../../../src/mesa/main/renderbuffer.c:212
#9  0x7f7abf40dc5a in _mesa_reference_renderbuffer (rb=0x0,
ptr=0x556811563748) at ../../../src/mesa/main/renderbuffer.h:72
#10 _mesa_free_framebuffer_data (fb=fb@entry=0x556811563600) at
../../../src/mesa/main/framebuffer.c:223
#11 0x7f7abf40dc8e in _mesa_destroy_framebuffer (fb=0x556811563600) at
../../../src/mesa/main/framebuffer.c:199
#12 0x7f7abf40dd39 in _mesa_reference_framebuffer_
(ptr=ptr@entry=0x556811b94bd0,
fb=fb@entry=0x0) at ../../../src/mesa/main/framebuffer.c:256
#13 0x7f7abf37a752 in _mesa_reference_framebuffer (fb=0x0,
ptr=0x556811b94bd0) at ../../../src/mesa/main/framebuffer.h:63
#14 _mesa_free_context_data (ctx=ctx@entry=0x556811b94ac0) at
../../../src/mesa/main/context.c:1320
#15 0x7f7abf524d8d in st_destroy_context (st=0x556811ba9c40) at
../../../src/mesa/state_tracker/st_context.c:659
#16 0x7f7abf6ec999 in dri_destroy_context () at
../../../../../src/gallium/state_trackers/dri/dri_context.c:239
#17 0x7f7abf6eb923 in driDestroyContext (pcp=0x5568116282a0) at
../../../../../../src/mesa/drivers/dri/common/dri_util.c:532
#18 0x55680fb9d229 in __glXDRIcontextDestroy
(baseContext=0x5568115ba790) at ../../../../glx/glxdriswrast.c:132
#19 0x55680fb9bf7b in __glXFreeContext (cx=0x5568115ba790) at
../../../../glx/glxext.c:190
#20 ContextGone (cx=0x5568115ba790, id=) at
../../../../glx/glxext.c:82
#21 0x55680fc662ad in doFreeResource (res=0x556811ce5ba0,
skip=skip@entry=0) at ../../../../dix/resource.c:880
#22 0x55680fc66f66 in FreeResourceByType (id=,
type=, skipFree=skipFree@entry=0) at
../../../../dix/resource.c:941
#23 0x55680fba1229 in __glXDisp_DestroyContext (cl=,
pc=0x55681150f520 "\227\004\002") at ../../../../glx/glxcmds.c:437
#24 0x55680fc85d45 in dispatch_DestroyContext (client=0x556811532000)
at ../../../../glx/vnd_dispatch_stubs.c:82
#25 0x55680fc4199e in Dispatch () at ../../../../dix/dispatch.c:478
#26 0x55680fc45946 in dix_main (argc=12, argv=0x7ffccb324498,
envp=) at ../../../../dix/main.c:276
#27 0x7f7ac724db17 in __libc_start_main (main=0x55680fb17150 ,
argc=12, argv=0x7ffccb324498, init=, fini=,
rtld_fini=,
stack_end=0x7ffccb324488) at ../csu/libc-start.c:310
#28 0x55680fb1718a in _start () at 

Bug#908059: xwayland: Desktop crashes when trying to run Visual Studio Code.

[Hank Barta]

Package: xwayland
Version: 2:1.20.1-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?

Trying to open Visual Studio Code. The application never appears and I 
am returned to the login screen.

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

I tried reverting to an earlier version of the application but it is 
installed as a snap package. I did
manage to revert but it updated automatically and resulted in the 
desktop crash. I could find no way to
pin to an older version.

   * What was the outcome of this action?
   * What outcome did you expect instead?



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

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

Versions of packages xwayland depends on:
ii  libaudit1   1:2.8.4-2
ii  libbsd0 0.9.1-1
ii  libc6   2.27-5
ii  libdrm2 2.4.94-1
ii  libegl1 1.1.0-1
ii  libepoxy0   1.4.3-1
ii  libgbm1 18.1.7-1
ii  libgcrypt20 1.8.3-1
ii  libgl1  1.1.0-1
ii  libpixman-1-0   0.34.0-2
ii  libselinux1 2.8-1+b1
ii  libsystemd0 239-7
ii  libwayland-client0  1.15.0-2
ii  libxau6 1:1.0.8-1+b2
ii  libxdmcp6   1:1.1.2-3
ii  libxfont2   1:2.0.3-1
ii  libxshmfence1   1.3-1
ii  xserver-common  2:1.20.1-1

xwayland recommends no packages.

xwayland suggests no packages.

-- no debconf information

Bug#907603: Problem has resolved

[Charlie Hagedorn]

The problem appears to have resolved itself. The computer was restarted at
least once, and has been updated at least once. A check of the dependencies
with reportbug suggests that no change in taskwarrior's dependencies
occurred.

Please close this bug at this time -- I will reply back if it recurs.

Thank you!

Bug#472477: ssh-add -D does not remove SSH key from gnome-keyring-daemon memory

[Jérôme]

I think I just got caught by this.

I'm using Debian Stretch/Mate and I had SSH Gnome keyring launched at 
startup (install default, I guess).


Indeed I do see gnome-keyring in ps ax:

1255 ?Sl 0:03 /usr/bin/gnome-keyring-daemon --daemonize 
--login


While testing ssh keys, I created a key and added a .ssh/config file 
with this content:


Host github.com
IdentityFile ~/.ssh/github-test.key

I checked I could connect.

Then I removed the file and even the key itself. And I could still 
connect (!).


I figured keys must be cached somehow and found out about ssh-agent.

I tried to delete the key cache using

ssh-add -D

And althouth it says

All identities removed.

all the keys in the cache still appear when running

ssh-add -l

echo $SSH_AGENT_PID
1336

ps ax:

1336 ?Ss 0:04 /usr/bin/ssh-agent x-session-manager

gnome-keyring 3.20.0-3
openssh-client 1:7.4p1-10+deb9u4

I have no idea what more I could provide to turn this message into 
something helpful...


--
Jérôme

Bug#908043: plasma-desktop: Plasma-desktop loads with black screen

[Martin Steigerwald]

severity 908043 important
tags 908043 upstream
thanks

Dear MH.

This looks like an upstream bug. I recommend you report this to  
upstream bugtracker¹ in case not already done so. Please report back the 
link to the upstream bug report. By doing so you help the small Debian 
Qt/KDE team.


Severity of this bug is in no way grave as what you reported only 
happens in a special use case, while the package just works fine for the 
majority of users. It may be grave to you, but that is not what is meant 
with "grave" severity in Debian. Instead this is what bug severity 
"important" is for².

[1] https://bugs.kde.org

[2] see https://www.debian.org/Bugs/Developer#severities
(especially description for "important")

Thanks,
Martin

MH - 05.09.18, 14:58:
> Package: plasma-desktop
> Version: 4:5.8.6-1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> When PC is connected to AVR via HDMI, plasma-desktop loads with a
> black screen. Apparently, it queries the EDID of the connected TV,
> which is 4k. Previously, SDDM did the same thing. The AVR is limited
> to 1920x1080 input. Creating an xorg.conf file using NVidia Settings
> solve the issue for SDDM, but that file seems to be ignored by
> plasma-desktop. The desktop still responds to keyboard input, but is
> otherwise unusable. This situation also exists under Buster.
> 
> IMO the problem is not with the AVR, which needs to passthrough EDID
> so monitors with lesser resolutions are correctly detected.
> Plasma-desktop should not requery for EDID but should accept the same
> settings as SDDM. Or maybe this is an issue with Xserver?
> 
> -- 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=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages plasma-desktop depends on:
> ii  breeze   4:5.8.5-2
> ii  kactivitymanagerd5.8.4-1
> ii  kde-cli-tools4:5.8.4-2
> ii  kded55.28.0-1
> ii  kio  5.28.0-2
> ii  libc62.24-11+deb9u3
> ii  libcanberra0 0.30-3
> ii  libfontconfig1   2.11.0-6.7+b1
> ii  libgcc1  1:6.3.0-18+deb9u1
> ii  libkf5activities55.28.0-1
> ii  libkf5activitiesstats1   5.28.0-1
> ii  libkf5archive5   5.28.0-2
> ii  libkf5auth5  5.28.0-2
> ii  libkf5baloo5 5.28.0-2
> ii  libkf5bookmarks5 5.28.0-1
> ii  libkf5codecs55.28.0-1+b2
> ii  libkf5completion55.28.0-1
> ii  libkf5configcore55.28.0-2
> ii  libkf5configgui5 5.28.0-2
> ii  libkf5configwidgets5 5.28.0-2
> ii  libkf5coreaddons55.28.0-2
> ii  libkf5dbusaddons55.28.0-1
> ii  libkf5emoticons-bin  5.28.0-1
> ii  libkf5emoticons5 5.28.0-1
> ii  libkf5globalaccel5   5.28.0-1
> ii  libkf5guiaddons5 5.28.0-1
> ii  libkf5i18n5  5.28.0-2
> ii  libkf5iconthemes55.28.0-2
> ii  libkf5itemmodels55.28.0-2
> ii  libkf5itemviews5 5.28.0-1
> ii  libkf5jobwidgets55.28.0-2
> ii  libkf5kcmutils5  5.28.0-2
> ii  libkf5kdelibs4support5   5.28.0-1
> ii  libkf5kiocore5   5.28.0-2
> ii  libkf5kiofilewidgets55.28.0-2
> ii  libkf5kiowidgets55.28.0-2
> ii  libkf5newstuff5  5.28.0-1
> ii  libkf5notifications5 5.28.0-1
> ii  libkf5notifyconfig5  5.28.0-1
> ii  libkf5parts5 5.28.0-1
> ii  libkf5people55.28.0-1
> ii  libkf5peoplewidgets5 5.28.0-1
> ii  libkf5plasma55.28.0-2
> ii  libkf5plasmaquick5   5.28.0-2
> ii  libkf5quickaddons5   5.28.0-1
> ii  libkf5runner55.28.0-1
> ii  libkf5service-bin5.28.0-1
> ii  libkf5service5   5.28.0-1
> ii  libkf5solid5 5.28.0-3
> ii  libkf5sonnetui5  5.28.0-2
> ii  libkf5wallet-bin 5.28.0-3
> ii  libkf5wallet5  

Bug#894262: closed by Adrian Bunk (gconf has been adopted)

[Jeremy Bicha]

On Wed, Sep 5, 2018 at 11:21 AM Adrian Bunk  wrote:
> We have (sometimes quite popular) packages that are unmaintained
> upstream for over 20 years - this is not a problem, actually far
> less of a problem than active upstreams breaking various stuff.
>
> And the package is not unmaintained in Debian, it is maintained by the
> Debian QA Group. This is pretty well maintained by Debian standards,
> it doesn't happen here that a trivial one-line FTBFS fix does not get
> applied for over half a year.

Hmm, so I guess we'll wait 9 months or so and then remove regexxer
from Debian? If so, we could still reopen this bug and just mark it
buster-ignore or something.

Anyway, there are
https://salsa.debian.org/gnome-team/gconf
https://salsa.debian.org/gnome-team/gconf-editor

Let me know where you want those repos to be moved to.

Because of issues with the svn-to-gconf conversion, tagged releases
might not exactly match what was actually uploaded for that version
number.

I don't think it really makes sense to keep gconf-editor in Debian.
Until you pushed stuff back into Testing, there was only one package
in Testing that used gconf (eclipse). Even now, there's really not
enough in Testing to justify needing to use gconf-editor to change
settings.

Thanks,
Jeremy Bicha