Bug#902834: goldendict: zim support doesn't seem to be working

[Elena ``of Valhalla'']

On 2018-07-01 at 22:42:21 +0200, Elena ``of Valhalla'' wrote:
> The files are pretty big (the smallest is 1.2G): could it be the reason?
> Tomorrow CEST I can try downloading some other smaller dumps from the
> site above (there are some that are ~100MB).

no difference even with a smaller file (122M, regular file in a
directory of its own).

-- 
Elena ``of Valhalla''

Bug#902796: /usr/lib/python2.7/dist-packages/magic.py: Aborts; too many arguments to str()

[Christoph Biedl]

tags 902796 moreinfo
fixed 902796 1:5.32-2
thanks

meba4815...@yahoo.com wrote...

> Traceback ended with:
> =
>   File "/usr/lib/python2.7/dist-packages/magic.py", line 155, in buffer
> return str(r, 'utf-8')
> TypeError: str() takes at most 1 argument (2 given)
> =

Can you please provide an example how you managed to trigger this? Also,
I'm a bit surprised nobody has managed to trigger this in years - still,
someone has to be first.

> The offending code seems gone from magic.py of the Testing package,
> but I did not test.

Confirmed, the python bindings have been removed recently.

> I classified this as important in part because I'm not a python
> programmer and this is my first bug report. For all I know, this could
> affect everyone (possibly depending on the data it's fed).

This is certainly stable point release material, so if I can provide a
fix within a very few days, this problem will go away quite soon.
However, I'd like to see this with my own eyes first.

Christoph


signature.asc
Description: PGP signature

Bug#902841: enigma FTCBFS: uses AC_RUN_IFELSE

[Helmut Grohne]

Source: enigma
Version: 1.20-dfsg.1-2.1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

enigma fails to cross build from source, because it uses AC_RUN_IFELSE.
The particular uses can be implemented using AC_COMPILE_IFELSE though.
The attached patch does that. I hope that it makes enigma cross build,
but that's difficult to test as enigma does not build from source.
Please consider applying it. Please close this bug when removing
AC_RUN_IFELSE from configure.ac by any means (e.g. new upstream
release).

Helmut
--- enigma-1.20-dfsg.1.orig/configure.ac
+++ enigma-1.20-dfsg.1/configure.ac
@@ -154,14 +154,16 @@
 dnl ---
 if test "$MINGW32" = no; then
   AC_MSG_CHECKING([for SDL_ttf >=2.0.6])
-  AC_RUN_IFELSE([AC_LANG_SOURCE(
+  AC_COMPILE_IFELSE([AC_LANG_SOURCE(
   [[#include 
-int main(int argc, char *argv[]) {
-if (TTF_MAJOR_VERSION < 2)
-  return 1;
-else if (TTF_MAJOR_VERSION == 2 && TTF_MINOR_VERSION == 0 && TTF_PATCHLEVEL < 6) 
-  return 1;
-return 0;}]])],
+#if TTF_MAJOR_VERSION < 2
+	#error too old
+	#else
+	#if TTF_MAJOR_VERSION == 2 && TTF_MINOR_VERSION == 0 && TTF_PATCHLEVEL < 6
+	#error too old
+	#endif
+	#endif
+]])],
 [AC_MSG_RESULT([found])],
 [AC_MSG_ERROR([SDL_ttf >= 2.0.6 not found.])])
 fi
@@ -206,12 +208,15 @@
   else
 AC_MSG_RESULT([not found])
 AC_MSG_CHECKING([for old Xerces release >=2.4])
-AC_RUN_IFELSE([AC_LANG_PROGRAM([[#include ]],
-  [[if (XERCES_VERSION_MAJOR < 2)
-  return 1;
-else if (XERCES_VERSION_MAJOR == 2 && XERCES_VERSION_MINOR < 4) 
-  return 1;
-return 0;]])],
+AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include ]],
+  [[#if XERCES_VERSION_MAJOR < 2
+#error too old
+#else
+	#if XERCES_VERSION_MAJOR == 2 && XERCES_VERSION_MINOR < 4
+	#error too old
+	#endif
+	#endif
+]])],
 [AC_MSG_RESULT([found])],
 [AC_MSG_ERROR([Xerces >= 2.4 not found.])])
 AC_CHECK_LIB(xerces-c, main,,[AC_MSG_ERROR([xerces is required to compile Enigma])])

Bug#898391:

[ciel]

This command effectively fixed my issue (I know this is really funny. lol)

sudo apt-get install
{nvidia-driver,xserver-xorg-video-nvidia,nvidia-driver-libs-nonglvnd,nvidia-driver-libs-nonglvnd-i386,nvidia-kernel-dkms}/buster

Bug#902840: clementine: .ogg stream disconnects/breaks/delays on track/song change

[goat]

Package: clementine
Version: 1.3.1+git276-g3485bbe43+dfsg-1
Severity: important

Dear Maintainer,

To reproduce in clementine go to internet>icecast.  Do a search for, "ogg" on 
the icecast directory, and play an available .ogg stream

I have tried several ogg streams.  You must wait for a track change for the bug 
to appear.  Roland Radio has an introductory audio clip that allows for the bug 
to be reproduced quickly as opposed to waiting for a random station's current 
playing song to end

Playback usually stops completely and the connection ends, at which point 
clementine may or may not cycle to the next item in the playlist.

Playback should be smooth and continuous when 
buffering/connectivity/hardware/etc... issues are not the problem.  The problem 
is not reproducible with gst-play-1.0 or ogg123

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

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

Versions of packages clementine depends on:
ii  gstreamer1.0-plugins-base   1.10.4-1
ii  gstreamer1.0-plugins-good   1.10.4-1
ii  gstreamer1.0-plugins-ugly   1.10.4-1
ii  libc6   2.24-11+deb9u3
ii  libcdio13   0.83-4.3+b1
ii  libchromaprint1 1.4.2-1
ii  libcrypto++65.6.4-7
ii  libfftw3-double33.3.5-3
ii  libgcc1 1:6.3.0-18+deb9u1
ii  libgdk-pixbuf2.0-0  2.36.5-2+deb9u2
ii  libglib2.0-02.50.3-2
ii  libgpod40.8.3-8.2
ii  libgstreamer-plugins-base1.0-0  1.10.4-1
ii  libgstreamer1.0-0   1.10.4-1
ii  libimobiledevice6   1.2.0+dfsg-3.1
ii  liblastfm1  1.0.9-1
ii  libmtp9 1.1.13-1
ii  libmygpo-qt11.0.9-2
ii  libplist3   1.12+git+1+e37ca00-0.3
ii  libprojectm2v5  2.1.0+dfsg-4+b3
ii  libprotobuf10   3.0.0-9
ii  libpulse0   10.0-1+deb9u1
ii  libqjson0   0.8.1-3
ii  libqt4-dbus 4:4.8.7+dfsg-11
ii  libqt4-network  4:4.8.7+dfsg-11
ii  libqt4-opengl   4:4.8.7+dfsg-11
ii  libqt4-sql  4:4.8.7+dfsg-11
ii  libqt4-sql-sqlite   4:4.8.7+dfsg-11
ii  libqt4-xml  4:4.8.7+dfsg-11
ii  libqtcore4  4:4.8.7+dfsg-11
ii  libqtgui4   4:4.8.7+dfsg-11
ii  libqxt-gui0 0.6.2-3
ii  libsqlite3-03.16.2-5+deb9u1
ii  libstdc++6  6.3.0-18+deb9u1
ii  libtag1v5   1.11.1+dfsg.1-0.1
ii  libx11-62:1.6.4-3
ii  projectm-data   2.1.0+dfsg-4
ii  zlib1g  1:1.2.8.dfsg-5

Versions of packages clementine recommends:
ii  gstreamer1.0-pulseaudio  1.10.4-1

Versions of packages clementine suggests:
pn  gstreamer1.0-plugins-bad  

-- no debconf information

Bug#902837: Bug#902839: ITP: elpa-bm -- visible bookmarks in Emacs buffers

[Nicholas D Steeves]

Request to tag a stable release newer than 201610 filed here:
  https://github.com/joodland/bm/issues/24

Obviously 20170815.1609 is the version we want.

https://melpa.org/#/bm
vs
https://stable.melpa.org/#/bm


signature.asc
Description: PGP signature

Bug#902797: lintian: check latest changelog entry for duplicate contributor information

[Paul Wise]

Control: close -1

On Sun, 2018-07-01 at 10:45 +0100, Chris Lamb wrote:

> Tagging as moreinfo for the time being...

The discussion has revealed that we do not have consensus on what
debian/changelog should look like in general so I close this bug.

I don't plan on starting any wider discussion on this topic but
I'll happily express my opinions if someone wants to work on this.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#532856: [Pkg-samba-maint] Bug#532856: Bug#532856: Bug#532856: closed by Mathieu Parent (Closing " umask settings overridden by Mac OS X 10.5 (Leopard) clients")

[Andrew Bartlett]

On Mon, 2018-07-02 at 01:14 +0200, Josip Rodin wrote:
> On Mon, Jul 02, 2018 at 09:41:39AM +1200, Andrew Bartlett wrote:
> > > How does that make sense? If the option is called "do X", and fails to
> > > do X in some opaque circumstances, how is that not a bug? At the very
> > > very least, it needs to be explained somewhere. Last I checked, there
> > > was nothing in the smb.conf manual to indicate that any of this would
> > > happen. The existence of a chmod extension isn't even mentioned. (As I
> > > said before.)
> > > 
> > > On a more general note, I would recommend triaging user bug reports when 
> > > you
> > > are available to actually try to understand what users are saying. 
> > > Ignoring
> > > information provided and repeating the same question all over again is
> > > unhelpful at best.
> > 
> > Honestly, this really isn't the place.
> > 
> > While this goes against general Debian practice, these bug reports are
> > really not a good place to discuss general issues with Samba.  
> 
> It's unreasonable to have a Debian package that doesn't respect the
> universally common practices of the Debian bug tracking system.

Would you like to help?  We simply don't have the resources to manage
the tasks you suggest as well as the other elements of maintaining the
package (it is marked help wanted and has been for years).  

> The Debian social contract doesn't go into that much detail, to explicitly
> require keeping bugs open because they exist in practice -- but common sense
> and decades of precedent do.

I'm very sorry, we just don't have the resources to tend to non-
packaging bugs.  I'll let others argue as to if validated but upstream
bugs should be left open, but debatable configuration discussions have
no useful place here. 

Upstream (non-packaging) bugs filed here at best have to be copied into
Samba's bugzilla before any progress can be made and the lossy nature
of that just makes work for everyone. 

> Or is this some new thing that we're now doing, am I that much out of
> the loop?

I don't know, I just try and bail out the very hard-working Debian
packagers from the overwhelming load from time to time.

Finally, debates, even meta debates, about unsupported and ancient
Samba and MacOS versions are simply not productive.  

Andrew Bartlett

-- 
Andrew Bartlett
https://samba.org/~abartlet/
Authentication Developer, Samba Team https://samba.org
Samba Development and Support, Catalyst IT   
https://catalyst.net.nz/services/samba

Bug#902837: Drop bm.el from goodies and recommend its elpafied variant

[Nicholas D Steeves]

clone 902837 -1 -2
retitle -2 ITP: elpa-bm -- visible bookmarks in Emacs buffers
reassign -2 wnpp
block -1 by -2

Bug#902837: Drop bm.el from goodies and recommend its elpafied variant

[Nicholas D Steeves]

Package: src:emacs-goodies-el
Version: 38
Severity: normal

Drop bm.el from goodies and recommend its elpafied variant.  It needs
to be elpafied.

Bug#883311: libatomic-ops: mips don't set mips3/set mips2 for mips r6

[Ian Wienand]

> This patch has been merged upstream, while not released with 7.6,
> Please cherry-pick from upstream.

7.6.4 in unstable/testing appears to have this patch.  Just to be
clear, are you saying it's something critical to pull into stable?

Thanks,

-i

On Mon, May 28, 2018 at 8:34 PM, YunQiang Su  wrote:
> On Sat, 2 Dec 2017 15:29:56 +0800 YunQiang Su  wrote:
>> Package: src:libatomic-ops
>> Version: 7.4.8-1
>>
>> MIPS r6 uses different encode for ll/sc pair with r5 and previous.
>> So if `.set mips3' in asm, it will generate previous encode for ll/sc.
>
> This patch has been merged upstream, while not released with 7.6,
> Please cherry-pick from upstream.
>
> https://github.com/ivmai/libatomic_ops/pull/33
>
>>
>> --
>> YunQiang Su

Bug#902751: drop highlight-current-line.el

[David Bremner]

Nicholas D Steeves  writes:

> On Sat, Jun 30, 2018 at 08:29:45AM -0300, David Bremner wrote:
>> 
>> This seems to be unmaintained, and at least at first glance, the
>> functionality is now built into GNU emacs as hl-line-mode.
>
> Agreed.  The finer points to potential differences are lost to me.
>
> One caveat: debian/patches/50_highlight-beyond-fill-column.diff
> uses highlight-current-line's configuration group, thus I suspect
> removing highlight-current-line's emacs-goodies custom configuration
> will break highlight-beyond-fill-column.  Is beyond-fill-column also a
> target for removal?

Yes, as Eli Barzilay points out in the stack overflow discussion you
found, the functionality of highlight-beyond-fill-colummn is provided
by whitespace-line-column (I just tested, and the only difference seems
to be the default choice of face to use to highlight.

d

Bug#532856: [Pkg-samba-maint] Bug#532856: Bug#532856: closed by Mathieu Parent (Closing " umask settings overridden by Mac OS X 10.5 (Leopard) clients")

[Josip Rodin]

On Mon, Jul 02, 2018 at 09:41:39AM +1200, Andrew Bartlett wrote:
> > How does that make sense? If the option is called "do X", and fails to
> > do X in some opaque circumstances, how is that not a bug? At the very
> > very least, it needs to be explained somewhere. Last I checked, there
> > was nothing in the smb.conf manual to indicate that any of this would
> > happen. The existence of a chmod extension isn't even mentioned. (As I
> > said before.)
> > 
> > On a more general note, I would recommend triaging user bug reports when you
> > are available to actually try to understand what users are saying. Ignoring
> > information provided and repeating the same question all over again is
> > unhelpful at best.
> 
> Honestly, this really isn't the place.
> 
> While this goes against general Debian practice, these bug reports are
> really not a good place to discuss general issues with Samba.  

It's unreasonable to have a Debian package that doesn't respect the
universally common practices of the Debian bug tracking system.

The Debian social contract doesn't go into that much detail, to explicitly
require keeping bugs open because they exist in practice -- but common sense
and decades of precedent do.

Or is this some new thing that we're now doing, am I that much out of
the loop?

-- 
 2. That which causes joy or happiness.

Bug#902835: python3.7: segfault on pip install

[Mike Dupont]

Package: python3.7
Version: 3.7.0-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
running pip install segfaults
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Using this requirements.txt
python3.7 -m pip install -r requirements.txt
-e git+ssh://g...@github.com/h4ck3rm1k3/django.git#egg=django
-e git://
github.com/38elements/django-simple-jsonschema.git#egg=django-simple-jsonschema
-e git://
github.com/Aristotle-Metadata-Enterprises/django-jsonforms#egg=django-jsonforms
-e git://github.com/Yupeek/django-rest-models.git#egg=django-rest-models
-e git://github.com/bcwaldon/warlock.git#egg=warlock
-e git://
github.com/cwacek/python-jsonschema-objects.git#egg=python-jsonschema-objects
-e git://
github.com/django-parler/django-parler-rest.git#egg=django-parler-rest
-e git://github.com/dsc/bunch#egg=bunch
-e git://github.com/frx08/jsonschema2popo.git#egg=jsonschema2popo
-e git://
github.com/h4ck3rm1k3/django-rest-framework.git#egg=djangorestframework
-e git://github.com/jazzband/django-model-utils.git#egg=django-model-utils
-e git://
github.com/marcgibbons/django-rest-swagger.git#egg=django-rest-swagger
-e git://github.com/paulcwatts/drf-json-schema.git#egg=drf-json-schema
-e git://
github.com/petrounias/json-schema-toolkit.git#egg=json-schema-toolkit
-e git://github.com/podio/valideer#egg=valideer
e git://github.com/h4ck3rm1k3/jsonschema#egg=jsonschema

### python wrappers around specs
-e git+ssh://
g...@github.com/h4ck3rm1k3/OpenAPI-Specification.git#egg=openapi-specification-python
-e git+ssh://
g...@github.com/h4ck3rm1k3/json-schema-spec.git#egg=json-schema-spec-python

-e git+ssh://
g...@github.com/h4ck3rm1k3/django-category.git#egg=django-category


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.8.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored:
LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3.7 depends on:
ii  libpython3.7-stdlib  3.7.0-1
ii  mime-support 3.60
ii  python3.7-minimal3.7.0-1
python3.7 recommends no packages.

Versions of packages python3.7 suggests:
ii  binutils2.30-19
pn  python3.7-doc   
pn  python3.7-venv  

-- no debconf information


-- 
James Michael DuPont

Bug#902836: RFS: slick-greeter/1.2.2-1

[David Mohammed]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "slick-greeter"

 * Package name: slick-greeter
   Version : 1.2.2-1
  Upstream Author :  Clement Lefebvre 
 * URL : https://github.com/linuxmint/slick-greeter/
 * License : GPL-3+
  Section : x11

  It builds those binary packages:

slick-greeter - Slick-looking LightDM greeter

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

  https://mentors.debian.net/package/slick-greeter


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

dget -x 
https://mentors.debian.net/debian/pool/main/s/slick-greeter/slick-greeter_1.2.2-1.dsc

Notes:
Tested by building on an up-to-date buster and installing the built .deb

check-all-the-things has been run on the source
lintian -i -I --pedantic run on the built changes files. It is lintian free
with the exception of the
following information/pedantic issues;

testsuite-autopkgtest-missing - I don't believe a autopkgtest is
required for a greeter

no-upstream-changelog - upstream does not supply a changelog so I have
summarised the changes in the debian/changelog

debian-watch-does-not-check-gpg-signature - upstream do not sign their
release tarballs

pbuilder-dist unstable build has been run successfully

May I request that this package be added to my debian maintainers
list of packages I'm allowed to look after (dak
fossfree...@ubuntu.com) ?

  Changes since the last upload:

   * New upstream release
- Latest translations
- Fix HiDPI detection
- Add option to display to specific monitor (only-on-monitor)
  * Packaging Changes:
- Drop patch mint-master-unstable-19.patch since it is now
  included in the new release
- debian/control bump StandardsVersion - no changes required


  Regards,
   David Mohammed

Bug#902772: texinfo: missing debug symbols and DEB_BUILD_OPTIONS support for Perl XS code

[Norbert Preining]

Hi Niko,

> I noticed that the Perl XS code in this package gets built without
> debugging symbols, so they are not in the -dbgsym package. Furthermore,
> the XS build doesn't honor DEB_BUILD_OPTIONS=noopt. These glitches make
> debugging unnecessarily hard.

I tried to fix this and also included the patch for the other issue in
the upload I did just now (-4). Hope that helps. if it is not fixed,
please reopen/resubmit.

Thanks a lot for your work and patches

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#532856: [Pkg-samba-maint] Bug#532856: Bug#532856: closed by Mathieu Parent (Closing " umask settings overridden by Mac OS X 10.5 (Leopard) clients")

[Andrew Bartlett]

On Sun, 2018-07-01 at 23:25 +0200, Josip Rodin wrote:
> On Fri, Jun 29, 2018 at 11:04:27AM +0200, Mathieu Parent wrote:
> > The "create mask" doesn't impact the chmod UNIX extension.
> 
> Exactly, and likewise for "force create mode". How does that make sense? If
> the option is called "do X", and fails to do X in some opaque circumstances,
> how is that not a bug? At the very very least, it needs to be explained
> somewhere. Last I checked, there was nothing in the smb.conf manual to
> indicate that any of this would happen. The existence of a chmod extension
> isn't even mentioned. (As I said before.)
> 
> On a more general note, I would recommend triaging user bug reports when you
> are available to actually try to understand what users are saying. Ignoring
> information provided and repeating the same question all over again is
> unhelpful at best.

Honestly, this really isn't the place.

While this goes against general Debian practice, these bug reports are
really not a good place to discuss general issues with Samba.  

There are good, upstream e-mail lists with a much larger peer user base
and monitored by full-time Samba developers.  Likewise the upstream
bugzilla tracks issues for the project as a whole, and is actively
reponded to (mostly) by Samba Team members.

Finally, the Debian Samba project has a fairly strict policy of not
carrying local patches, so any change has to go via the above in any
case. 

Sorry,

Andrew Bartlett

-- 
Andrew Bartlett
https://samba.org/~abartlet/
Authentication Developer, Samba Team https://samba.org
Samba Development and Support, Catalyst IT   
https://catalyst.net.nz/services/samba

Bug#881205: NMU for backintime 1.1.24

[Fabian Wolff]

Hi Jonathan,

On Fri, 29 Jun 2018 22:21:54 +0100, Jonathan Wiltshire wrote:
> Would you like to co-maintain? If so, please add yourself to uploaders and
> prepare a maintainer upload (rather than NMU). I added you to the
> repository members in anticipation.

Thanks. In principle, I'd be interested in co-maintaining the package,
but unfortunately, I don't think that I have the time for it right
now. I might reconsider co-maintaining this package in the future,
though.

For the time being, I'd like to leave it at a NMU. Can I proceed with
the NMU? If so, would you like to sponsor it, or should I look for a
sponsor elsewhere?

Best regards,
Fabian

Bug#532856: [Pkg-samba-maint] Bug#532856: closed by Mathieu Parent (Closing " umask settings overridden by Mac OS X 10.5 (Leopard) clients")

[Josip Rodin]

On Fri, Jun 29, 2018 at 11:04:27AM +0200, Mathieu Parent wrote:
> The "create mask" doesn't impact the chmod UNIX extension.

Exactly, and likewise for "force create mode". How does that make sense? If
the option is called "do X", and fails to do X in some opaque circumstances,
how is that not a bug? At the very very least, it needs to be explained
somewhere. Last I checked, there was nothing in the smb.conf manual to
indicate that any of this would happen. The existence of a chmod extension
isn't even mentioned. (As I said before.)

On a more general note, I would recommend triaging user bug reports when you
are available to actually try to understand what users are saying. Ignoring
information provided and repeating the same question all over again is
unhelpful at best.

-- 
 2. That which causes joy or happiness.

Bug#563252: still exists in 2.14.0-8

[Johannes Zarl-Zierl]

Hi,

I still experience the bug in timidity 2.14.0-8.
After a reboot I get no sound on my primary soundcard using pulseaudio. After
issuing "systemctl restart timidity.service" as root, sound starts working
again.

dpkg -l pulseaudio timidity*:
ii  pulseaudio12.0-1  
amd64   PulseAudio sound server
ii  timidity  2.14.0-8
amd64   Software sound renderer (MIDI sequencer, MOD player)
rc  timidity-daemon   2.14.0-8
all runs TiMidity++ as a system-wide MIDI sequencer

  Johannes



On Tue, 26 Jun 2018 15:19:42 + =?utf-8?q?Bastien_Roucari=C3=A8s?= 
 wrote:
> Source: timidity
> Source-Version: 2.14.0-5
> 
> We believe that the bug you reported is fixed in the latest version of
> timidity, which is due to be installed in the Debian FTP archive.
> 
> A summary of the changes between this version and the previous one is
> attached.
> 
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 563...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
> 
> Debian distribution maintenance software
> pp.
> Bastien Roucariès  (supplier of updated timidity package)
> 
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Format: 1.8
> Date: Tue, 26 Jun 2018 15:23:28 +0200
> Source: timidity
> Binary: timidity timidity-interfaces-extra timidity-el timidity-daemon
> Architecture: source
> Version: 2.14.0-5
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian QA Group 
> Changed-By: Bastien Roucariès 
> Description:
>  timidity   - Software sound renderer (MIDI sequencer, MOD player)
>  timidity-daemon - runs TiMidity++ as a system-wide MIDI sequencer
>  timidity-el - Emacs front end to Timidity++
>  timidity-interfaces-extra - TiMidity++ extra user interfaces
> Closes: 563252
> Changes:
>  timidity (2.14.0-5) unstable; urgency=medium
>  .
>* Use libao, allows a better integration with desktop
>  (Closes: 

Bug#902834: goldendict: zim support doesn't seem to be working

[Elena ``of Valhalla'']

Package: goldendict
Version: 1.5.0~rc2+git20180412+ds-1
Severity: normal

Dear Maintainer,

I've seen in the changelog that you are enabling zim support in
goldendict, which is strongly appreciated.
This is also mentioned in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763321#48

However, I can't seem to be able to make it actually work: I have a
directory with a few zim files (downloaded from http://www.kiwix.org/ ),
add it to goldendict under Edit - Dictionaries and hit Rescan now, but
nothing new appears in Dictionaries.

I have installed libzim2 manually, as it wasn't listed among the
dependencies, but that didn't help.

I have run goldendict from the command line, but stdout doesn't seem to
be mentioning anything relevant.

The files are pretty big (the smallest is 1.2G): could it be the reason?
Tomorrow CEST I can try downloading some other smaller dumps from the
site above (there are some that are ~100MB).

The files are also symbolic links, but I've tried to copy one of them
elsewhere as a regular file, and that didn't help.

I may be doing something wrong, but I can't understand what.

Please let me know if you need me to check anything else.

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

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

Versions of packages goldendict depends on:
ii  libao4 1.2.2+20180113-1
ii  libavcodec57   7:3.4.2-2+b2
ii  libavformat57  7:3.4.2-2+b2
ii  libavutil557:3.4.2-2+b2
ii  libbz2-1.0 1.0.6-8.1
ii  libc6  2.27-3
ii  libeb164.4.3-12
ii  libgcc11:8.1.0-8
ii  libhunspell-1.6-0  1.6.2-1+b1
ii  liblzo2-2  2.10-0.1
ii  libopencc2 1.0.5-1
ii  libqt5core5a   5.10.1+dfsg-7
ii  libqt5gui5 5.10.1+dfsg-7
ii  libqt5help55.10.1-2
ii  libqt5multimedia5  5.10.1-2
ii  libqt5multimedia5-plugins  5.10.1-2
ii  libqt5network5 5.10.1+dfsg-7
ii  libqt5printsupport55.10.1+dfsg-7
ii  libqt5svg5 5.10.1-2
ii  libqt5webkit5  5.212.0~alpha2-9+b1
ii  libqt5widgets5 5.10.1+dfsg-7
ii  libqt5x11extras5   5.10.1-2
ii  libqt5xml5 5.10.1+dfsg-7
ii  libstdc++6 8.1.0-8
ii  libtiff5   4.0.9-5
ii  libvorbisfile3 1.3.6-1
ii  libx11-6   2:1.6.5-1
ii  libxtst6   2:1.2.3-1
ii  zlib1g 1:1.2.11.dfsg-1

goldendict recommends no packages.

Versions of packages goldendict suggests:
pn  goldendict-wordnet  

-- no debconf information

Bug#902833: doc-base: typos in manual

[Paul Hardy]

Source: doc-base
Version: 0.10.8
Tags: patch

There are some typos in the doc-base HTML manual.  I have made changes
to the XML source file, doc-base-0.10.8/doc/doc-base.xml.  A patch
file is attached.

Some notes:

- "ham radio" -- "ham" is not capitalized (I am a radio ham and vouch
for this one).

- "Texinfo" -- GNU documentation capitalizes this when describing the
system, not the program itself or the package name.

- Usually punctuation is set in the same type style as the text it
follows, but I did not change punctuation that immediately followed
"emphasis" tags.  If you want to change those instances, I can send a
patch for them also.

- Usually in English when two complete sentences are combined into
one, they are separated by a semicolon, not a comma.  See for example
https://en.wikipedia.org/wiki/Comma_splice.  I use them myself
sometimes, but generally a semicolon is better.

Also, you might or might not want to mention in the introduction for
section 2.3 that control files are ordinarily stored in the debian
directory under package-name.doc-base.

Thanks,


Paul Hardy


doc-base.xml.patch
Description: Binary data

Bug#902774: jetty/jetty8/jetty9 not affected by CVE-2018-12538

[Hugo Lefeuvre]

Hi,

FYI, none of the jetty releases present in Debian are affected by
CVE-2018-12538.

CVE-2018-12538 affects FileSessionDataStore and more specifically its
function getFile(). This class was introduced in 9.4, this
vulnerability thus affects 9.4.x releases only (and jetty package has
version < 9.0, jetty9 has <= 9.2.24).

FTR FileSessionDataStore was introduced in
fa8232d3c81608c25d9e8c66cdfe8ab7a66c892b and the vulnerable code in
54a56314627f0a2c33ca67d813e3396f6bc03274.

regards,
 Hugo

-- 
 Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA

Bug#902832: stretch-pu: package rustc/1.24.1+dfsg1-1~deb9u1

[Moritz Muehlenhoff]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi,
the second update to allow us to keep up with Firefox ESR60;
rustc 1.24. See attached debdiff against 1.24.1 from unstable.

This uses a bootstrap build which I've tested successfully
on amd64.

Cheers,
Moritz
diff -aur rustc-1.24.1+dfsg1.orig/debian/changelog 
rustc-1.24.1+dfsg1/debian/changelog
--- rustc-1.24.1+dfsg1.orig/debian/changelog2018-03-07 20:07:27.0 
+0100
+++ rustc-1.24.1+dfsg1/debian/changelog 2018-07-01 13:42:46.197752265 +0200
@@ -1,3 +1,12 @@
+rustc (1.24.1+dfsg1-1~deb9u1) stretch; urgency=medium
+
+  * Build for stretch to be used by Firefox ESR60
+  * Enable stage0 build
+  * Disable -doc package, requires packages not found in stretch and
+docs are available online anyway
+
+ -- Moritz Mühlenhoff   Sun, 01 Jul 2018 13:42:52 +0200
+
 rustc (1.24.1+dfsg1-1) unstable; urgency=medium
 
   * Upload to unstable.
Nur in rustc-1.24.1+dfsg1/debian: changelog~.
diff -aur rustc-1.24.1+dfsg1.orig/debian/control 
rustc-1.24.1+dfsg1/debian/control
--- rustc-1.24.1+dfsg1.orig/debian/control  2018-03-05 15:57:40.0 
+0100
+++ rustc-1.24.1+dfsg1/debian/control   2018-07-01 13:43:09.981484174 +0200
@@ -11,9 +11,6 @@
 Build-Depends: debhelper (>= 9),
dpkg-dev (>= 1.17.14),
python:native,
-   cargo:native (>= 0.19.0)  ,
-   rustc:native (>= 1.23.0+dfsg) ,
-   rustc:native (<= 1.24.1++),
llvm-4.0-dev:native   (>= 1:4.0.1-8),
llvm-4.0-tools:native (>= 1:4.0.1-8),
libllvm4.0(>= 1:4.0.1-8),
@@ -50,7 +47,7 @@
 Depends: ${shlibs:Depends}, ${misc:Depends}, libstd-rust-dev (= 
${binary:Version}),
  gcc, libc-dev, binutils (>= 2.26)
 Recommends: rust-gdb | rust-lldb
-Suggests: rust-doc, rust-src
+Suggests: rust-src
 Description: Rust systems programming language
  Rust is a curly-brace, block-structured expression language.  It
  visually resembles the C language family, but differs significantly
@@ -148,29 +145,6 @@
  This package contains pretty printers and a wrapper script for
  invoking lldb on rust binaries.
 
-Package: rust-doc
-Section: doc
-Architecture: all
-Build-Profiles: 
-Depends: ${misc:Depends},
- libjs-jquery, libjs-highlight.js, libjs-mathjax,
- fonts-open-sans, fonts-font-awesome
-Description: Rust systems programming language - Documentation
- Rust is a curly-brace, block-structured expression language.  It
- visually resembles the C language family, but differs significantly
- in syntactic and semantic details.  Its design is oriented toward
- concerns of "programming in the large", that is, of creating and
- maintaining boundaries - both abstract and operational - that
- preserve large-system integrity, availability and concurrency.
- .
- It supports a mixture of imperative procedural, concurrent actor,
- object-oriented and pure functional styles.  Rust also supports
- generic programming and meta-programming, in both static and dynamic
- styles.
- .
- This package contains the Rust tutorial, language reference and
- standard library documentation.
-
 Package: rust-src
 Architecture: all
 Depends: ${misc:Depends}
Nur in rustc-1.24.1+dfsg1/debian: control~.
diff -aur rustc-1.24.1+dfsg1.orig/debian/make_orig-stage0_tarball.sh 
rustc-1.24.1+dfsg1/debian/make_orig-stage0_tarball.sh
--- rustc-1.24.1+dfsg1.orig/debian/make_orig-stage0_tarball.sh  2018-03-03 
10:26:05.0 +0100
+++ rustc-1.24.1+dfsg1/debian/make_orig-stage0_tarball.sh   2018-07-01 
13:41:33.170575430 +0200
@@ -11,6 +11,7 @@
 
 rm -f stage0/*/*.sha256
 mkdir -p stage0 build && ln -sf ../stage0 build/cache
+touch stage0/hack
 for deb_host_arch in $upstream_bootstrap_arch; do
make -s --no-print-directory -f debian/architecture-test.mk 
"rust-for-deb_${deb_host_arch}" | {
read deb_host_arch rust_triplet
diff -aur rustc-1.24.1+dfsg1.orig/debian/rules rustc-1.24.1+dfsg1/debian/rules
--- rustc-1.24.1+dfsg1.orig/debian/rules2018-03-07 20:06:58.0 
+0100
+++ rustc-1.24.1+dfsg1/debian/rules 2018-06-30 23:39:14.0 +0200
@@ -161,7 +161,8 @@
-DLLVM_VERSION="$(LLVM_VERSION)" \
-DRUST_DESTDIR="$(RUST_DESTDIR)" \
"$<" > "$@"
-   ! $(DOWNLOAD_BOOTSTRAP) || sed -i -e '/^rustc = /d' -e '/^cargo = /d' 
"$@"
+   if $(DOWNLOAD_BOOTSTRAP) || [ $(HAVE_BINARY_TARBALL) != 0 ]; \
+ then sed -i -e '/^rustc = /d' -e '/^cargo = /d' "$@"; fi
# Work around armhf issue: 
https://github.com/rust-lang/rust/issues/45854
[ $(DEB_BUILD_ARCH) != armhf -a \
  $(DEB_BUILD_ARCH) != armel ] || sed -i -e '/^debuginfo-only-std = /d' 
"$@"
diff -aur rustc-1.24.1+dfsg1.orig/debian/source/options 
rustc-1.24.1+dfsg1/debian/source/options
--- rustc-1.24.1+dfsg1.orig/debian/source/options   2017-08-24 
16:57:59.0 +0200
+++ 

Bug#847786: solid-pop3d: Does not work with systemd. Is inetd mandatory?

[Robert Luberda]

Ludovic Rousseau writes:

Hi,
> 
> I just installed solid-pop3d in my Debian stable (jessie 8.6) system.
> 
> It looks like the pop3 server is NOT started when systemd is used.
> I use the default package configuration so "inetd". I have not tried
> with the "daemon" configuration.

The "deamon" configuration should suit you. It causes solid-pop3d to run
as a standalone daemon, without using inetd. It should work with systemd
as well, so I am closing this bug report.
> 
> It is possible to use this package on a systemd system (default init
> system on Debian now)?
> If yes can you provide the systemd configuration files?

The files are autogenerated, based on /etc/init.d/solid-pop3d.

Regards,
robert

Bug#902751: drop highlight-current-line.el

[Nicholas D Steeves]

On Sat, Jun 30, 2018 at 08:29:45AM -0300, David Bremner wrote:
> 
> This seems to be unmaintained, and at least at first glance, the
> functionality is now built into GNU emacs as hl-line-mode.

Agreed.  The finer points to potential differences are lost to me.

One caveat: debian/patches/50_highlight-beyond-fill-column.diff
uses highlight-current-line's configuration group, thus I suspect
removing highlight-current-line's emacs-goodies custom configuration
will break highlight-beyond-fill-column.  Is beyond-fill-column also a
target for removal?

The following thread also has various reference to
whitespace-line-column (part of GNU Emacs), which sounds like it
provides the functionality of highlight-beyond-fill-column.  "The
author of highlight-80+.el [sounds like an alternate
highlight-beyond-fill-column] says its discontinued and recommends,
since Emacs 23, to use whitespace-mode's whitespace-line-column".

  
https://stackoverflow.com/questions/6344474/how-can-i-make-emacs-highlight-lines-that-go-over-80-chars

Cheers,
Nicholas.


signature.asc
Description: PGP signature

Bug#902831: wireguard-tools: /etc/wireguard permissions are open to the world, leaking private keys

[Mike Swanson]

Package: wireguard-tools
Version: 0.0.20180625-1
Severity: normal

When installing wireguard-tools, the /etc/wireguard directory is created
that can contain configuration files for the wg-quick service to use.

These configuration files will contain the private key of the local
machine for the VPN configuration, and as such, the default mode (755)
for the directory is unsuitable for production use, since it creates an
opportunity for any user to be able to print out the contents of the
configuration files (if they were not changed to mode 600 themselves),
and potentially break the security model of the Wireguard VPN altogether.

I propose changing the default mode of the /etc/wireguard directory to 600.
I do this on my own machines and there is no functionality impact for the
software, only that the private keys become completely inaccessible for
anyone but root.

Bug#902830: openstack-pkg-tools is presently unsuitable using in Build-Depends for cross building

[Helmut Grohne]

Package: openstack-pkg-tools
Version: 81
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 src:ntpstat src:openvswitch src:python-posix-ipc 
src:python-rjsmin src:python-wrapt src:subunit src:websockify

The affected packages cannot satisfy their cross Build-Depends, because
their (transitive) dependency on openstack-pkg-tools is not satisfiable.
In general, Architecture: all packages can never satisfy cross
Build-Depends unless marked Multi-Arch: foreign. In this case, it is
very unclear whether such a marking is correct, because
openstack-pkg-tools composes so much functionality into a single
package. It may never be safe to mark it Multi-Arch: foreign, so making
packages cross buildable presently involves removing it from
Build-Depends, which runs counter to its goal. We should seek a way to
avoid that route.

One aspect is that openstack-pkg-tools kinda is a metapackage as it
exposes its dependencies to consumers. Thus each dependency needs to be
looked at individually (but that's not enough):
 * autopkgtest is not Multi-Arch: foreign. I kinda doubt that packages
   use autopkgtest to run tests during build, so this dependency is more
   of a convenience dependency. Would it be possible to either demote it
   to Recommends (effectively removing it from package builds) or adding
   a openstack-pkg-dev-tools to be installed for development, which is
   not supposed to be used in Build-Depends?
 * gettext is Multi-Arch: foreign.
 * libxml-xpath-perl is not Multi-Arch: foreign and cannot become
   Multi-Arch: foreign due to the multiarch interpreter problem. I don't
   understand why openstack-pkg-tools needs it.
 * madison-lite is not Multi-Arch: foreign, but the tool primarily
   exists for checking archive package metadata, i.e. it requires a
   network connection. That's not something one can rely on during
   package builds. Can it be demoted to Recommends or split out?
 * po-debconf is Multi-Arch: foreign.
 * pristine-tar is not Multi-Arch: foreign, but maybe could be.

Given the above, I ask you to reduce the scope of openstack-pkg-tools.
Please split it into two packages:
 * One for use in Build-Depends.
 * Another for developer tools that are not required for building
   packages.

After such a split has been performed, we can reevaluate the possibility
of marking openstack-pkg-tools Multi-Arch: foreign. Please close this
bug once openstack-pkg-tools is split or its dependencies have been
reduced (e.g. using Recommends).

Helmut

Bug#901089: stretch-pu: package dosbox/0.74-4.2+deb9u1

[Moritz Mühlenhoff]

On Sun, Jul 01, 2018 at 06:44:08PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Fri, 2018-06-08 at 22:41 +0200, Moritz Muehlenhoff wrote:
> > dosbox is broken in the default setting on a number of systems/DOS
> > binaries
> > (see #857341). This got fixed in unstable back in September, but the
> > patch
> > is also needed in stretch. Apart from debian/changelog, the debdiff
> > the
> > only change applied to the package in unstable since the stretch
> > release.
> > 
> 
> Please go ahead.

Thanks, uploaded.

Cheers,
Moritz

Bug#902829: vlc: VLC too bigger windows with xorg and gnome-shell

[Lombardo Davide]

Package: src:vlc
Version: 3.0.2-0+deb9u1
Severity: important

When I start vlc the windows of the program it's very bigger and the program
very unresponsive, the only thing I can do it's quit the program. I can't see
anythings. This don't happen if I start GNOME with Wayland from GDM3. That
happen only if I use Xorg.

output $vlc -vvv:

VLC media player 3.0.2 Vetinari (revision 3.0.2-0-gd7b653cf14)
[55698d6921a0] main libvlc debug: VLC media player - 3.0.2 Vetinari
[55698d6921a0] main libvlc debug: Copyright © 1996-2018 the VideoLAN team
[55698d6921a0] main libvlc debug: revision 3.0.2-0-gd7b653cf14
[55698d6921a0] main libvlc debug: configured with ./configure  '--
build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--
mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--
sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--
libdir=${prefix}/lib/x86_64-linux-gnu' '--
libexecdir=${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--
disable-dependency-tracking' '--config-cache' '--disable-update-check' '--
enable-fast-install' '--docdir=/usr/share/doc/vlc' '--with-binary-
version=3.0.2-0+deb9u1' '--enable-a52' '--enable-aa' '--enable-bluray' '--
enable-avahi' '--enable-caca' '--enable-chromaprint' '--enable-chromecast' '--
enable-dbus' '--enable-dca' '--enable-dvbpsi' '--enable-dvdnav' '--enable-faad'
'--enable-flac' '--enable-fluidsynth' '--enable-freerdp' '--enable-freetype' '
--enable-fribidi' '--enable-gles2' '--enable-gnutls' '--enable-harfbuzz' '--
enable-jack' '--enable-kate' '--enable-libass' '--enable-libmpeg2' '--enable-
libxml2' '--enable-lirc' '--enable-live555' '--enable-mad' '--enable-matroska'
'--enable-mod' '--enable-mpc' '--enable-mpg123' '--enable-mtp' '--enable-
ncurses' '--enable-notify' '--enable-ogg' '--enable-opus' '--enable-pulse' '--
enable-qt' '--enable-realrtsp' '--enable-samplerate' '--enable-sdl-image' '--
enable-sftp' '--enable-shine' '--enable-shout' '--enable-skins2' '--enable-
sndio' '--enable-soxr' '--enable-speex' '--enable-svg' '--enable-svgdec' '--
enable-taglib' '--enable-theora' '--enable-twolame' '--enable-upnp' '--enable-
vdpau' '--enable-vnc' '--enable-vorbis' '--enable-x264' '--enable-x265' '--
enable-zvbi' '--with-kde-solid=/usr/share/solid/actions/' '--disable-aribsub' '
--disable-d3d11va' '--disable-decklink' '--disable-directx' '--disable-dsm' '--
disable-dxva2' '--disable-fdkaac' '--disable-fluidlite' '--disable-goom' '--
disable-gst-decode' '--disable-libplacebo' '--disable-libtar' '--disable-
macosx' '--disable-macosx-avfoundation' '--disable-macosx-qtkit' '--disable-
mfx' '--disable-opencv' '--disable-projectm' '--disable-schroedinger' '--
disable-sparkle' '--disable-srt' '--disable-telx' '--disable-vpx' '--disable-
vsxu' '--disable-wasapi' '--enable-alsa' '--enable-dc1394' '--enable-dv1394' '
--enable-linsys' '--enable-nfs' '--enable-omxil' '--enable-udev' '--
enable-v4l2' '--enable-wayland' '--enable-libva' '--enable-vcd' '--enable-
smbclient' '--disable-oss' '--enable-crystalhd' '--enable-mmx' '--enable-sse' '
--disable-neon' '--disable-altivec' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g
-O2 -fdebug-prefix-map=/build/vlc-XFxItV/vlc-3.0.2=. -fstack-protector-strong
-Wformat -Werror=format-security ' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now -Wl,--as-
needed' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2 -fdebug-
prefix-map=/build/vlc-XFxItV/vlc-3.0.2=. -fstack-protector-strong -Wformat
-Werror=format-security ' 'OBJCFLAGS=-g -O2 -fdebug-prefix-map=/build/vlc-
XFxItV/vlc-3.0.2=. -fstack-protector-strong -Wformat -Werror=format-security'
[55698d6921a0] main libvlc debug: searching plug-in modules
[55698d6921a0] main libvlc debug: loading plugins cache file
/usr/lib/x86_64-linux-gnu/vlc/plugins/plugins.dat
[55698d6921a0] main libvlc debug: recursively browsing
`/usr/lib/x86_64-linux-gnu/vlc/plugins'
[55698d6921a0] main libvlc debug: plug-ins loaded: 515 modules
[55698d6921a0] main libvlc debug: opening config file
(/home/ldvd85/.config/vlc/vlcrc)
[55698d692510] main logger debug: looking for logger module matching "any":
4 candidates
[55698d692510] main logger debug: using logger module "console"
[55698d6921a0] main libvlc debug: translation test: code is "en_GB"
[55698d693970] main keystore debug: looking for keystore module matching
"memory": 4 candidates
[55698d693970] main keystore debug: using keystore module "memory"
[55698d6921a0] main libvlc debug: CPU has capabilities MMX MMXEXT SSE SSE2
SSE3 SSSE3 SSE4.1 SSE4.2 SSE4A AVX XOP FMA4 FPU
[55698d71d250] main input debug: Creating an input for 'Media Library'
[55698d71d250] main input debug: Input is a meta file: disabling unneeded
options
[55698d71d250] main input debug: using timeshift granularity of 50 MiB
[55698d71d250] main input debug: using default timeshift path
[55698d71d250] main input debug:
`file/directory:///home/ldvd85/.local/share/vlc/ml.xspf' gives 

Bug#898579: please transition from emacs-goodies-el to elpa-htmlize

[Nicholas D Steeves]

Control: tag -1 + pending

On Sun, May 13, 2018 at 05:24:25PM -0400, Nicholas D Steeves wrote:
> Package: yasnippet
> Version: 0.12.2-2
> Severity: normal
> 
> Yasnippet should transition from emacs-goodies-el to elpa-htmlize,
> because the latter is more up to date, and also because we are trying
> to reduce dependencies on emacs-goodies-el in preparation for it's
> removal.  At this point in time there's definitely no rush :-)

Fixed in git@commit: 089d7cf.  When emacs-goodies-el is uploaded to
unstable yasnippet will also need an upload to fix this broken
dependency.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#702225: Iòi

[April Clark]

Ne


✨✨TheFitnessFairy
Sent from my iPhone

Bug#600963: switching to RFP

[David Bremner]

user debian-emac...@lists.debian.org
usertag 600963 elpafy
reassign 600963 wnpp
retitle 600963 RFP: elpa-nagios-mode
quit

We're not adding any more code to emacs-goodies-el, so I'm turning this
bug into an RFP

I'm not really sure how active upstream is, but there was a whitespace
fix in 2016, so I guess it's worth checking out if someone is still
interested.

Bug#902828: pgpdump: autopkgtest regression: sh: 0: Can't open debian/test

[Paul Gevers]

Source: pgpdump
Version: 0.33-1
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

Since the upload of 0.33-1, your package fails its autopkgtest in
both unstable and testing, with the error copied below. It seems you
dropped the file you wanted to test somewhere during packaging.

This regression is causing your package to have to wait 13 extra days to
migrate to testing.

Thanks for consideration.

Paul

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pgpdump/533316/log.gz

autopkgtest [19:13:36]: test command1: [---
sh: 0: Can't open debian/test
autopkgtest [19:13:36]: test command1: ---]



signature.asc
Description: OpenPGP digital signature

Bug#901331: stretch-pu: package ganeti/2.15.2-7+deb9u2

[Apollon Oikonomopoulos]

On 18:41 Sun 01 Jul , Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Mon, 2018-06-11 at 18:02 +0300, Apollon Oikonomopoulos wrote:
> > I would like to update ganeti in Stretch to resolve #895599, whereby 
> > ganeti fails to "export" (aka dump) VMs because of an SSL
> > verification 
> > error. The bug is fixed by cherry-picking an upstream commit,
> > already 
> > included in 2.16 which is in unstable.
> 
> Please go ahead.
> 

Uploaded!

Thanks,
Apollon

Bug#902819: system freeze (hang task) when launching Xorg(1) after a new version of linux-image installed

[Luca Boccassi]

Control: forcemerge 901919 -1

On Sun, 2018-07-01 at 23:31 +0800, M0xkLurk3r wrote:
> Package: nvidia-driver
> Version: 390.48
> Severity: serious
> 
> Dear Maintainer:
>   I had upgrade my linux-image to a new version (4.16.0-2,
> exactly 4.16.16), then i found the Xorg were failed to start up, the
> screen shows blank and the keyboard stops answer, then i try to grab
> out what's kernel happening in the meantime, and i found kernel gives
> looping oop with "CPU stuck" and "hang task" messages.
>   Probably the issue were still exists in upstream, i try to
> remove this package and install the offical nVIDIA linux driver
> (version 390.67), and the bug were still exists and perfectly
> reproduce. Then i remove the nvidia driver and turn to uses nouveau,
> this issue disappear(but as well known, the nouveau takes a huge
> performance penalty on graphics that i can't accept)

Please check existing bug reports before opening new ones. This is the
7th duplicate...

Add the following to the kernel command line:

slab_common.usercopy_fallback=y

-- 
Kind regards,
Luca Boccassi

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

Bug#902795: systemd fills kmsg and console with rubbish

[Michael Biebl]

Am 01.07.2018 um 01:49 schrieb Peter De Schrijver:
> Package: systemd
> Version: 239-3
> Severity: important
> 
> 
> systemd fills kmsg and console with:
> 
> [  102.676667] systemd-journald[360]: Sent WATCHDOG=1 notification.
> [  102.683373] systemd-journald[360]: Journal effective settings seal=no 
> compress=yes compress_threshold_bytes=512B

This is a debug log message [1]. Please check if you have debug logging
enabled.
Most likely you have added "debug" to the kernel command line.

If you turn off debug logging, those log messages should go away.

Michael


[1]
https://github.com/systemd/systemd/blob/master/src/journal/journal-file.c#L3261
-- 
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#882097: sbuild: --bd-uninstallable-explainer should default to apt

[Johannes Schauer]

Control: tag -1 + wontfix

Hi Mike,

On Sun, 19 Nov 2017 07:43:38 +0900 Mike Hommey  
wrote:
> sbuild's default resolver is apt, and its default
> bd-uninstallable-explainer is dose3.
> 
> As of writing, the apt resolver fails to install the build dependencies
> for firefox... and dose3 does find a solution. Which means, I'm in a
> situation where the default configuration gives me useless information
> about why the resolver failed to install the build dependencies because
> what it uses to explain is different, and doesn't fail to find a
> solution.
> Even if it did fail to find a solution, that would not necessarily be
> the reason apt failed in the first place.
> So I think the default explainer should be apt, at least when the
> resolver is apt.

I disagree and here is why.

That the apt resolver failed and the dose3 explainer succeeded is *not* useless
information. It tells you, that a solution exists but apt is able to find one.
This in turn tells you, that you might want to choose a different resolver. If
the apt explainer were the default, then you would not be able to figure out
that the problem is not a dependency problem but instead a problem with the apt
resolver.

To your second argument: indeed the reason why dose3 fails might be a different
one because of which apt fails. But that should not matter. Because (in theory)
as long as the dose3 explainer fails, you simply cannot get a solution from
apt. So even if the reason is different, you have to fix the reason given by
the dose3 explainer anyways, even if it's a different reason from the one that
apt had. So why is it then a problem that the reason given by the dose3
explainer might be a different one?

Thus, I'm tagging this wontfix. But if you think that my arguments are
unfounded, please tell me why. :)

Another reason why the dose3 explainer is the default is, that its output is
much more human readable than the output of the apt explainer. Do you disagree?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#897092: stretch-pu: package mapbox-vector-tile/0.5.0+ds-4+deb9u1

[Sebastiaan Couwenberg]

Control: tags -1 - moreinfo
Control: close -1

On 07/01/2018 08:04 PM, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo
> 
> On Sat, 2018-04-28 at 11:37 +0200, Bas Couwenberg wrote:
>> To fix #896350 I'd like to update mapbox-vector-tile in stretch too.
> 
> +  * Add python3-lib2to3 to dependencies.
> 
> There's no such package in stretch:
> 
> $ dak ls python3-lib2to3
> python3-lib2to3 | 3.6.6~rc1-3   | testing| all
> python3-lib2to3 | 3.6.6~rc1-3   | unstable   | all
> python3-lib2to3 | 3.6.6-1   | unstable   | all

Right, it's still part of libpython3.5-stdlib on stretch, so the issue
shouldn't affect stable. I've tagged the bug with buster & sid.

Kind Regards,

Bas

Bug#902827: FTBFS: GHC OOM on armel/armhf

[Clint Adams]

Source: agda
Version: 2.5.2-2
Severity: serious

ghc: out of memory (requested 2097152 bytes)

Bug#902819:

[Giacomo Graziosi]

May be related to
https://devtalk.nvidia.com/default/topic/1031067/linux/-linux416-nvidia-390-48-nvidia_stack_cache-rip-0010-usercopy_warn-0x7e-0xa0/

Bug#897092: stretch-pu: package mapbox-vector-tile/0.5.0+ds-4+deb9u1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Sat, 2018-04-28 at 11:37 +0200, Bas Couwenberg wrote:
> To fix #896350 I'd like to update mapbox-vector-tile in stretch too.

+  * Add python3-lib2to3 to dependencies.

There's no such package in stretch:

$ dak ls python3-lib2to3
python3-lib2to3 | 3.6.6~rc1-3   | testing| all
python3-lib2to3 | 3.6.6~rc1-3   | unstable   | all
python3-lib2to3 | 3.6.6-1   | unstable   | all

Regards,

Adam

Bug#890602: sbuild fails to install Build-Depends of pam: unsatisfied dependency libfl-dev:native

[Helmut Grohne]

Control: tag -1 - moreinfo
Control: reassign -1 src:pam
Control: retitle -1 pam: rebuild with a recent dpkg-source

On Sun, Jul 01, 2018 at 03:11:33PM +0200, Johannes Schauer wrote:
> Are you sure? Since libfl-dev:native is not part of the build dependencies of
> src:pam anymore, I build pam_1.1.8-3.5.dsc and I'm getting:

That's only partially true. pam's debian/control still has
libfl-dev:native, but pam's .dsc doesn't. I tried to build it with
"sbuild -d unstable pam", so sbuild was using the .dsc here. You built a
fixed .dsc and thus you cannot reproduce it. In other words, the fault
is with pam, not sbuild.

Please rebuild the pam source package with a version of dpkg-source >=
stretch and close this bug when doing so.

Helmut

Bug#896170: stretch-pu: package salt/2016.11.2+ds-1+deb9u1

[Adam D. Barratt]

On Fri, 2018-04-20 at 15:04 +0200, Ondrej Novy wrote:
> Build and tested on stretch. Uploaded to stretch-pu. Debdiff
> attached.
> 

I'm not sure what happened to your upload, but there's no sign of it in
the logs on either the upload host or ftp-master.

++.. note:: keep does not work with salt-ssh.
++
++As a consequence of how the files are transfered to the minion, 
and
++the inability to connect back to the master with salt-ssh, salt is
++unable to stat the file as it exists on the fileserver and thus
++cannot mirror the mode on the salt-ssh minion

Is that a regression?

Regards,

Adam

Bug#895766: stretch-pu: package tlslite-ng/0.6.0-1+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2018-04-15 at 21:02 +0200, Daniel Stender wrote:
> I hereby propose an update for stable/stretch of tlslite-ng. It
> contains
> a patch fixing CVE-2018-1000159 [1]. The security issue was marked as
> being
> no-dsa [2]. Please see the attached debdiff for details.
> 

+tlslite-ng (0.6.0-1+deb9u1) stable; urgency=medium

We generally prefer the distribution to be specified by codename - i.e.
"stretch", rather than "stable".

Please feel free to upload.

Regards,

Adam

Bug#895596: stretch-pu: package xrdp/0.9.1-9+deb9u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2018-04-13 at 10:48 +0200, Dominik George wrote:
> The last upload to stretch, fixing a minor security issue, had an
> incomplete
> patch provided by upstream which can lead to memory corruption and
> crashes
> in some cases.
> 

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#902826: scilab: FTBFS on i386 - seg. fault during build

[Niels Thykier]

Source: scilab
Version: 6.0.1-1
Severity: serious

Build log from the buildd:

"""
Building index for all classes...
Generating ./modules/javasci/javadoc/allclasses-frame.html...
Generating ./modules/javasci/javadoc/allclasses-noframe.html...
Generating ./modules/javasci/javadoc/index.html...
Generating ./modules/javasci/javadoc/overview-summary.html...
-- Building documentation (en_US) --
LANG=en_US.UTF-8 LC_ALL=C SCI_DISABLE_TK=1 SCI_JAVA_ENABLE_HEADLESS=1 
_JAVA_OPTIONS='-Djava.awt.headless=true' HOME=/tmp ./bin/scilab-adv-cli 
-noatomsautoload -nb -l en_US -nouserstartup -e "try 
xmltojar([],[],'en_US');catch disp(lasterror()); exit(-1);end;exit(0);"
Picked up _JAVA_OPTIONS: -Djava.awt.headless=true
Caught handled GLException: EGLGLXDrawableFactory - Could not initialize shared 
resources for EGLGraphicsDevice[type .egl, v0.0.0, connection nil, unitID 0, 
handle 0x0, owner true, ResourceToolkitLock[obj 0x804ce6, isOwner true, 
<182de92, 6d1923>[count 1, qsz 0, owner ]]] on 
thread main-SharedResourceRunner
[0]: 
jogamp.opengl.egl.EGLDrawableFactory$SharedResourceImplementation.createSharedResource(EGLDrawableFactory.java:518)
[1]: jogamp.opengl.SharedResourceRunner.run(SharedResourceRunner.java:353)
[2]: java.lang.Thread.run(Thread.java:748)
Caused[0] by GLException: Failed to created/initialize EGL display incl. 
fallback default: native 0x0, error 0x3001/0x3001 on thread 
main-SharedResourceRunner
[0]: 
jogamp.opengl.egl.EGLDisplayUtil.eglGetDisplayAndInitialize(EGLDisplayUtil.java:297)
[1]: jogamp.opengl.egl.EGLDisplayUtil.access$300(EGLDisplayUtil.java:58)
[2]: 
jogamp.opengl.egl.EGLDisplayUtil$1.eglGetAndInitDisplay(EGLDisplayUtil.java:320)
[3]: 
com.jogamp.nativewindow.egl.EGLGraphicsDevice.open(EGLGraphicsDevice.java:125)
[4]: 
jogamp.opengl.egl.EGLDrawableFactory$SharedResourceImplementation.createEGLSharedResourceImpl(EGLDrawableFactory.java:532)
[5]: 
jogamp.opengl.egl.EGLDrawableFactory$SharedResourceImplementation.createSharedResource(EGLDrawableFactory.java:516)
[6]: jogamp.opengl.SharedResourceRunner.run(SharedResourceRunner.java:353)
[7]: java.lang.Thread.run(Thread.java:748)
Segmentation fault
Makefile:2204: recipe for target 'doc' failed
make[1]: *** [doc] Error 1
make[1]: Leaving directory '/<>'
/usr/share/cdbs/1/class/makefile.mk:77: recipe for target 
'debian/stamp-makefile-build' failed
make: *** [debian/stamp-makefile-build] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

Build finished at 2018-07-01T17:48:33Z
"""

It is possible that the following patch in Ubuntu solves/works around the 
problem:

"""
diff -pruN 6.0.1-1/debian/changelog 6.0.1-1ubuntu1/debian/changelog
--- 6.0.1-1/debian/changelog2018-02-26 12:32:37.0 +
+++ 6.0.1-1ubuntu1/debian/changelog 2018-03-06 16:07:25.0 +
@@ -1,3 +1,9 @@
+scilab (6.0.1-1ubuntu1) bionic; urgency=medium
+
+  * Disable building help docs on i386, java fails.
+
+ -- Dimitri John Ledkov   Tue, 06 Mar 2018 17:07:25 +0100
+
 scilab (6.0.1-1) unstable; urgency=medium
 
   * Formally adopting the package (Closes: #744140).
diff -pruN 6.0.1-1/debian/control 6.0.1-1ubuntu1/debian/control
--- 6.0.1-1/debian/control  2018-02-26 12:32:37.0 +
+++ 6.0.1-1ubuntu1/debian/control   2018-03-06 16:07:25.0 +
@@ -1,7 +1,8 @@
 Source: scilab
 Section: math
 Priority: optional
-Maintainer: Debian Science Team 

+Maintainer: Ubuntu Developers 
+XSBC-Original-Maintainer: Debian Science Team 

 Uploaders: Julien Puydt 
 Build-Depends: cdbs, debhelper (>= 10), gfortran,
  default-jdk, chrpath, ocaml-nox (>= 3.11.2-3), fakeroot,
diff -pruN 6.0.1-1/debian/rules 6.0.1-1ubuntu1/debian/rules
--- 6.0.1-1/debian/rules2018-01-09 11:11:21.0 +
+++ 6.0.1-1ubuntu1/debian/rules 2018-03-06 16:07:21.0 +
@@ -35,7 +35,7 @@ endif
 
 DEB_CONFIGURE_SCRIPT_ENV += LDFLAGS="-Wl,--no-as-needed"
 
-ENABLE_BUILD_HELP_ARCHS := amd64 i386
+ENABLE_BUILD_HELP_ARCHS := amd64
 ifneq (,$(findstring $(DEB_HOST_ARCH),$(ENABLE_BUILD_HELP_ARCHS)))
 # Enable the build on these arch. it timeouts for the other archs
 DEB_MAKE_BUILD_TARGET := all doc
"""

This bug is preventing several important bugs fixes from reaching
testing, so a timely fix would be appreciated.

Thanks,
~Niels

Bug#902825: python-nacl: in stretch-backports FTBFS on non-amd64 architectures

[Phil Morrell]

Source: python-nacl
Version: 1.2.1-3~bpo9+1
Severity: important

This is a necessary dependency for matrix-synapse on arm. I'm not sure
why amd64 succeeds, but from the buildd logs, I think it's just missing
a versioned dependency on libsodium-dev, which is only .11 in stable.

https://buildd.debian.org/status/package.php?p=python-nacl=stretch-backports

It builds fine in sid with .16, which is in -backports, so that might be
sufficient, but for reference I include the minimum version these
symbols appear to have been added according to git blame hash:

crypto_pwhash_argon2id_opslimit_moderate:   2cb8415 (.13)
crypto_pwhash_scryptsalsa208sha256_bytes_min:   08c0e03 (.12)


signature.asc
Description: PGP signature

Bug#897923: stretch-pu: package tclreadline/2.1.0-15+deb9u1 pre-approval

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2018-05-04 at 23:22 +0300, Sergei Golovan wrote:
> I would like to upload the tclreadline package to stretch. The
> package
> currently in stable misses a shared library for the ppc64el
> architecture,
> as indicated in [1]. I'm attaching the package diff for review. It's
> tested using he ppc64el QEMU installation, and it builds fine now.
> 

Please go ahead.

Regards,

Adam

Bug#901089: stretch-pu: package dosbox/0.74-4.2+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2018-06-08 at 22:41 +0200, Moritz Muehlenhoff wrote:
> dosbox is broken in the default setting on a number of systems/DOS
> binaries
> (see #857341). This got fixed in unstable back in September, but the
> patch
> is also needed in stretch. Apart from debian/changelog, the debdiff
> the
> only change applied to the package in unstable since the stretch
> release.
> 

Please go ahead.

Regards,

Adam

Bug#901331: stretch-pu: package ganeti/2.15.2-7+deb9u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2018-06-11 at 18:02 +0300, Apollon Oikonomopoulos wrote:
> I would like to update ganeti in Stretch to resolve #895599, whereby 
> ganeti fails to "export" (aka dump) VMs because of an SSL
> verification 
> error. The bug is fixed by cherry-picking an upstream commit,
> already 
> included in 2.16 which is in unstable.

Please go ahead.

Regards,

Adam

Bug#902387: sbuild: consider use of dpkg-buildpackage -F flag

[Johannes Schauer]

Control: tag -1 + moreinfo

Hi,

On Mon, 25 Jun 2018 14:29:57 -0500 Matt Zagrabelny  wrote:
> Since dpkg 1.15.8, the options -F does suffice for build any/all/source. From
> dpkg-buildpackage's man page:
> 
> -F Equivalent to --build=full, --build=source,binary or
> --build=source,any,all (since dpkg 1.15.8).
> 
> Perhaps consider using -F in sbuild or updating documentation.

why?

The table is a documentation of what sbuild is doing. The table is not a
documentation of what dpkg-buildpackage is doing. With all three options set to
"true", sbuild passes no special flags to dpkg-buildpackage.

So what is the bug?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#900272: stretch-pu: devscripts/2.17.6+deb9u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2018-06-09 at 22:18 +0200, Mattia Rizzolo wrote:
> On Mon, May 28, 2018 at 12:06:38PM +0200, Mattia Rizzolo wrote:
> > I'd like to fix a bunch of sillyness in stretch to make it work
> > smoother
> > for those who prefer not to run the backports version.
> 
> Another bug came in, updated debdiff attached.
> This time it modified the pos needed a refresh due to a change in
> line number.

I'd be happy with this update, but please could we look at getting the
"ftbfs" tag addition (trivial as it is) landed in unstable before the
point release?

Regards,

Adam

Bug#902824: caja-actions FTCBFS: lintian tag autotools-pkg-config-macro-not-cross-compilation-safe

[Helmut Grohne]

Source: caja-actions
Version: 1.8.3-3
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

caja-actions fails to cross build from source, because lintian tag
autotools-pkg-config-macro-not-cross-compilation-safe. See tag
description for details. The attached patch fixes that and makes
caja-actions cross buildable. Please consider applying the patch.

Helmut
--- caja-actions-1.8.3.orig/configure.ac
+++ caja-actions-1.8.3/configure.ac
@@ -63,8 +63,8 @@
 AM_PROG_LIBTOOL
 
 # we are using pkgconfig for all development libraries we need
-AC_PATH_PROG(PKG_CONFIG, pkg-config, no)
-if test "${PKG_CONFIG}" = "no"; then
+PKG_PROG_PKG_CONFIG
+if test "x$PKG_CONFIG" = x; then
 	AC_MSG_ERROR([You need to install pkg-config])
 fi
 

Bug#902758: subversion 1.9.5-1+deb9u2 flagged for acceptance

[Adam D Barratt]

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: subversion
Version: 1.9.5-1+deb9u2

Explanation: reject commits which would introduce hash collisions with existing 
data, thus addressing the SHA1/shattered issue

Bug#901355: llvm-toolchain-4.0 4.0.1-10~deb9u1 flagged for acceptance

[Adam D Barratt]

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: llvm-toolchain-4.0
Version: 4.0.1-10~deb9u1

Explanation: new package for rust backports

Bug#902626: Stretch kvm accelerated qemu-system-i386 on i386 archirecture enters infinite loop at startup

[Michael Tokarev]

BTW, I've installed stretch i386 chroot and installed qemu-system-x86 on it.
qemu-system-i386 works just fine here.
Become curious, installed 32bit kernel too - the same, qemu-system-i386 works
just fine.

So I *guess* your issue has something to do with your host CPU too, --
Core2duo is quite old and lacks several kvm-related features found on
modern CPUs (eg, nested page tables), - without these, some old and
quite complex code paths in qemu and kernel are being executed.
Probably bit-rotted too, but here, I definitely can't help you,
since I just don't have that hardware and there's no where I can
get it.

Thanks,

/mjt

Bug#902823: [binutils-dev] Missing file diagnostics.h

[Giovanni Mascellani]

Package: binutils-dev
Version: 2.30.90.20180627-1
Severity: normal

Hi,

package binutils-dev is not distributing the header diagnostics.h, which
is included by bfd.h. As a result, any program including bfd.h fails
compilation. For example:

> giovanni@amalgama:/tmp$ cat test.c 
> #include 
> 
> int main(int argc, char* argv[]) {
>   return 0;
> }
> giovanni@amalgama:/tmp$ LANG=C gcc -o test test.c 
> In file included from test.c:1:0:
> /usr/include/bfd.h:41:10: fatal error: diagnostics.h: No such file or 
> directory
>  #include "diagnostics.h"
>   ^~~
> compilation terminated.
> giovanni@amalgama:/tmp$ 

Please add missing headers.

Thanks, Gio.


Debian Release: buster/sid
  500 unstable-debug  debug.mirrors.debian.org   500 unstable
ftp.be.debian.org   500 testing ftp.be.debian.org   500 stable
   repository.spotify.com   500 stable  repo.skype.com   500
stable  dl.google.com 1 experimentalftp.be.debian.org
--- Package information. ---
Depends  (Version) | Installed
==-+-===
binutils(= 2.30.90.20180627-1) | 2.30.90.20180627-1
libbinutils (= 2.30.90.20180627-1) | 2.30.90.20180627-1


Package's Recommends field is empty.

Package's Suggests field is empty.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature

Bug#902819: system freeze (hang task) when launching Xorg(1) after a new version of linux-image installed

[Markus Steinko]

Same here,

I could get the screen running with using lightdm instead of gdm3 and I 
changed to mesa-diverted using sudo update-glx --config glx. But I am 
missing some performance.


I needed to change the grub kernel line to 'nomodeset text single' to be 
able to do same terminal workaround.

Bug#902680: reportbug: Unable to connect to Debian BTS, certificate verify error

[Sandro Tosi]

control: tags -1 unreproducible

On Fri, Jun 29, 2018 at 10:09 AM Brian Minton  wrote:
> Querying Debian BTS for reports on reportbug (source)...
> Unable to connect to Debian BTS (error: "SSLError(1, '[SSL:
> CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:841)')");
> continue [y|N|?]? y

can you still reproduce this on your end? i cant on a cliean unstable chroot.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#901727: sbuild: add hashes of source package to build log

[Paul Wise]

On Sun, 2018-07-01 at 17:41 +0200, Johannes Schauer wrote:

> I'm unsure whether the sbuild build log is the right place for this. Look at 
> it
> this way: .changes and .buildinfo are part of the log because they are the
> *output* of running sbuild. The .dsc is the *input* for sbuild. Thus, whoever
> runs sbuild already has a .dsc and does not need the build log to contain a
> copy of it.

The build log is the one place that input and output are connected.
Thus I think that is one place both input and output should be logged.

> In your case, the buildd has the dsc and thus the actual problem seems to be,
> that it is currently hard to retrieve the .dsc that was used from
> buildd.debian.org.

In my case the buildd has the dsc but buildd.debian.org does not,
because the buildd admin created it on the buildd instead of using the
dsc that buildd.debian.org sent to the buildd.

> Thus, I suggest that you rather convince the maintainers of buildd.debian.org
> to make it easier to find out what they were feeding sbuild with.

buildd.debian.org never had the dsc that the buildd used to build the
package so it cannot provide this feature in this case.

I agree that it would be useful to have the log of the build requests
that were sent to buildds include more information about the source.

> Do you agree?

Given the above, I do not agree.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#902797: lintian: check latest changelog entry for duplicate contributor information

[Jonas Smedegaard]

Quoting Florian Schlichting (2018-07-01 17:23:04)
> Hi,
> 
> On Sun, Jul 01, 2018 at 11:37:21AM +0200, Mattia Rizzolo wrote:
> > On Sun, Jul 01, 2018 at 12:39:47PM +0800, Paul Wise wrote:
> > > I recently saw a changelog entry (quoted below) for a Perl team 
> > > package where several contributors to that version had their names 
> > > mentioned multiple times with one or more changes below each 
> > > instance of their name. This made the changelog harder to read. I 
> > > think it would be useful for lintian to emit a pedantic or 
> > > info-level warning for duplicate contributor information in the 
> > > latest changelog entry.
> > 
> > I personally agree with you here, but apparently not everybody does. 
> > ISTR to remember in the past suggesting to change the default of dch 
> > --multimaint-merge but somebody complained that that way it would 
> > lose the chronological order of the changes or something like that 
> > (I don't really buy it).
> 
> I'm probably guilty of uploading a fair number of packages with such 
> changelogs over the last few days, as I'm working through a list of 
> perl team packages that haven't had an upload in over six years and 
> thus still point to SVN with their version in the archive.
> 
> Most of those changelog entries stem from (semi-)automatic mass 
> commits made over the years to our several thousand packages; and some 
> of them change the very same thing a previous entry modified. In the 
> example that Paul cited, Ansgar first changed the Vcs-* lines from 
> svn.d.o to git.d.o in 2011, then Salvatore changed git.d.o to 
> anonscm.d.o in 2013, git:// to https:// in 2016, and anonscm.d.o to 
> salsa.d.o in 2018, each time adding a commit with the change and one 
> that modified d/changelog using dch. If that last commit was made by 
> Ansgar again, wouldn't --multimaint-merge result in a confusing 
> changelog that lists final modifications before intermediate ones?
> 
> Having said that, I don't have a strong feeling about how changelogs 
> should look like, other than that the default behaviour of our tools 
> should agree with what lintian wants to see. In my use of d/changelog, 
> both as a packager and occasionally as a user looking at an installed 
> package, it's a mirror of the packaging repository's git history, very 
> likely auto-generated, and a bit redundant as a source of 
> information...

Lintian not complaining is not the same as lintian wanting us to tune 
tools for (in our opinion) improved readability.

I find it more readable to list each contributor only once.

Also (not exactly same but strongly related):

I find it irrelevant¹ to list changes reverted or shadowed later within 
same release: Please cleanup auto-generated changelog, stripping parts 
not ending in the final package release.


 - Jonas

¹ I thought Debian Policy had a passage that changelog should cover 
user-facing changes, but cannot find it now so maybe I imagined that.

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

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


signature.asc
Description: signature

Bug#899539: Getting hunspell-ar and myspell-fa back into testing

[Lior Kaplan]

Hi,

NMUs are always welcome.

Otherwise I hope to fixs this in Debconf.

On Sat, Jun 30, 2018 at 1:11 PM, intrigeri  wrote:

> Hi,
>
> do you plan to fix #899539 and #899616 soon? I could not find updates
> nor any repo on Salsa.
>
> These bugs caused these two packages to be removed from testing, which
> makes it harder e.g. for derivatives (such as Tails) that try to start
> working on their migration to Debian Buster, which is why these
> problems appeared on my radar.
>
> If you lack time to take care of it yourself soon, I can offer to NMU
> these packages in order to set the maintainer address to person listed
> in the Uploaders field who did most of the recent uploads. This would
> be a temporary stop-gap allowing the packages to migrate back into
> testing, until your team has had time to find out how you want to fix
> this. Just let me know :)
>
> Cheers,
> --
> intrigeri
>

Bug#902822: fribidi: please consider reinstating static library

[Simon McVittie]

Package: libfribidi-dev
Version: 0.19.4-1
Severity: normal
Tags: patch

In fribidi 0.19.4-1, ﺄﺤﻣﺩ ﺎﻠﻤﺤﻣﻭﺪﻳ (Ahmed El-Mahmoudy) removed the static
library from the -dev package:

>  * debian/libfribidi-dev.install: drop static library (upstream doesn't
>provide it anymore).

This came to my attention while investigating bugs involving pango1.0's
dependency on fribidi and how it is represented in pkg-config: the correct
solution to those bugs changes depending on whether fribidi supports static
linking or not.

I asked fribidi upstream on https://github.com/fribidi/fribidi/issues/83
and they clarified that they had not intended to force shared-only
linking, but only to make development builds quicker by skipping the
static library by default. The static library can be requested by
passing the standard Libtool-provided option "--enable-static" to the
configure script.

Please consider bringing back the static library, unless you
specifically intend to forbid/de-support static linking to libfribidi
as a Debian-specific policy. I attach a patch that seems to work.

Thanks,
smcv

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

Kernel: Linux 4.16.0-2-amd64 (SMP w/4 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)
LSM: AppArmor: enabled
>From 9c949f79e7f6076ce0e4b23e79231179f334d47f Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sun, 1 Jul 2018 17:10:03 +0100
Subject: [PATCH] Reinstate the static library

---
 debian/libfribidi-dev.install | 1 +
 debian/rules  | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/libfribidi-dev.install b/debian/libfribidi-dev.install
index 904c133..6a25082 100644
--- a/debian/libfribidi-dev.install
+++ b/debian/libfribidi-dev.install
@@ -1,3 +1,4 @@
 usr/include/fribidi/
+usr/lib/*/libfribidi.a
 usr/lib/*/libfribidi.so
 usr/lib/*/pkgconfig/fribidi.pc
diff --git a/debian/rules b/debian/rules
index 0073fb5..4aee951 100755
--- a/debian/rules
+++ b/debian/rules
@@ -15,7 +15,7 @@ endif
 	dh $@
 
 override_dh_auto_configure:
-	dh_auto_configure -- --enable-malloc CFLAGS="${DEB_CFLAGS}"
+	dh_auto_configure -- --enable-malloc --enable-static CFLAGS="${DEB_CFLAGS}"
 
 override_dh_auto_install:
 	dh_auto_install
-- 
2.18.0

Bug#866122: slapd-mtread crash on ppc64{,el} in stretch/sid

[Ryan Tandy]

On Sun, Jul 01, 2018 at 03:42:12AM +0100, Ben Hutchings wrote:

Is this bug still present?


Thanks for the ping. The Unicamp Minicloud, where I was granted access 
to a VM for testing, is currently down for maintenance until July 7. I 
will check this again after it comes back.

Bug#899958: Getting ibus-anthy and ibus-pinyin back into testing

[Osamu Aoki]

On Sat, Jun 30, 2018 at 12:06:18PM +0200, intrigeri wrote:
> Hi,
> 
> do you plan to fix #899958 and #899538 soon? I could not find updates
> nor any Git repo on Salsa.

Yah, I am behind.  I just uploaded few packages with salsa.
 getmail
 maildrop
 maint-guide
...
 
> These bugs caused ibus-anthy and ibus-pinyin to be removed from
> testing, which makes it harder e.g. for derivatives (such as Tails)
> that try to start working on their migration to Debian Buster, which
> is why these problems appeared on my radar.
> 
> If you lack time to take care of it yourself soon, I can offer to NMU
> these packages in order to set the maintainer address to person listed
> in the Uploaders field who did most of the recent uploads. Just let me
> know :)

You are welcomed to do so.  Just move old alioth data from
alioth-archive.

Osamu

Bug#902821: qa.debian.org: Asian (JP, CH) input impossible, when locale is not Asian (LANG=en_US, etc)

[Andrey]

Package: qa.debian.org
Severity: important
Tags: l10n

Dear Maintainer,

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

   * What led up to the situation?
Installing Debian9/Gnome with US English locales/UI, or changing locales/UI
from Japanese to US English
   * What exactly did you do (or not do) that was effective (or ineffective)?
Installed Debian9/Gnome with US lang/UI - Japanese input impossible.
Installed Debian with Japanese lang/UI - Japanese input works well,
multilingual input switching works (tried ja_JP+en_US+ka_GE+ru_RU)
Switched Debian installation to en_US lang/UI by adding necessary locales, and
using Gnome Region settings - Japanese input became impossible.
Tried im-config - no effect.

   * What was the outcome of this action?
With non-Japanese (English) UI in Debian9/Gnome, Japanese input is impossible.
Japanese can be switched on, but only English characters appear. Japanese
keyboard special buttons do not work.
   * What outcome did you expect instead?
Expected Japanese kanji input possible along with English(using the same
Japanese layout), and Georgian, Russuan (using ka_GE, and ru_RU layouts); like
it works with Japanese locales, and Japanese Gnome UI.



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

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

Bug#902820: gmap: FTBFS on stretch/amd64 if CPU has SSE2 and nothing more

[Santiago Vila]

Package: src:gmap
Version: 2017-01-14-1
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-arch
dh  build-arch --parallel --with autotools_dev
   dh_testdir -a -O--parallel
   dh_update_autotools_config -a -O--parallel
   dh_autotools-dev_updateconfig -a -O--parallel
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dh_auto_configure -- --enable-shared --with-gmapdb=/var/cache/gmap \
--bindir=/usr/lib/gmap 
./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu 
--libexecdir=\${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode 
--disable-dependency-tracking --enable-shared --with-gmapdb=/var/cache/gmap 
--bindir=/usr/lib/gmap
checking package version... 2017-01-14
loading default site script ./config.site
checking CFLAGS... -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security
checking MPI_CFLAGS... 

[... snipped ...]

gcc -DHAVE_CONFIG_H -I.   -Wdate-time -D_FORTIFY_SOURCE=2  -pthread 
-DTARGET=\"x86_64-pc-linux-gnu\" -DGMAPDB=\"/var/cache/gmap\" -mpopcnt 
-DHAVE_SSE2=1 -msse2 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -c -o 
gmap_sse2-inbuffer.o `test -f 'inbuffer.c' || echo './'`inbuffer.c
gcc -DHAVE_CONFIG_H -I.   -Wdate-time -D_FORTIFY_SOURCE=2  -pthread 
-DTARGET=\"x86_64-pc-linux-gnu\" -DGMAPDB=\"/var/cache/gmap\" -mpopcnt 
-DHAVE_SSE2=1 -msse2 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -c -o 
gmap_sse2-samheader.o `test -f 'samheader.c' || echo './'`samheader.c
samheader.c: In function 'SAM_header_change_HD_tosorted':
samheader.c:201:5: warning: ignoring return value of 'fread', declared with 
attribute warn_unused_result [-Wunused-result]
 fread(buffer,sizeof(char),CHUNK,input);
 ^~
samheader.c:206:5: warning: ignoring return value of 'fread', declared with 
attribute warn_unused_result [-Wunused-result]
 fread(buffer,sizeof(char),headerlen,input);
 ^~
gcc -DHAVE_CONFIG_H -I.   -Wdate-time -D_FORTIFY_SOURCE=2  -pthread 
-DTARGET=\"x86_64-pc-linux-gnu\" -DGMAPDB=\"/var/cache/gmap\" -mpopcnt 
-DHAVE_SSE2=1 -msse2 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -c -o 
gmap_sse2-outbuffer.o `test -f 'outbuffer.c' || echo './'`outbuffer.c
gcc -DHAVE_CONFIG_H -I.   -Wdate-time -D_FORTIFY_SOURCE=2  -pthread 
-DTARGET=\"x86_64-pc-linux-gnu\" -DGMAPDB=\"/var/cache/gmap\" -mpopcnt 
-DHAVE_SSE2=1 -msse2 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -c -o 
gmap_sse2-chimera.o `test -f 'chimera.c' || echo './'`chimera.c
gcc -DHAVE_CONFIG_H -I.   -Wdate-time -D_FORTIFY_SOURCE=2  -pthread 
-DTARGET=\"x86_64-pc-linux-gnu\" -DGMAPDB=\"/var/cache/gmap\" -mpopcnt 
-DHAVE_SSE2=1 -msse2 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -c -o 
gmap_sse2-datadir.o `test -f 'datadir.c' || echo './'`datadir.c
gcc -DHAVE_CONFIG_H -I.   -Wdate-time -D_FORTIFY_SOURCE=2  -pthread 
-DTARGET=\"x86_64-pc-linux-gnu\" -DGMAPDB=\"/var/cache/gmap\" -mpopcnt 
-DHAVE_SSE2=1 -msse2 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -c -o 
gmap_sse2-parserange.o `test -f 'parserange.c' || echo './'`parserange.c
gcc -DHAVE_CONFIG_H -I.   -Wdate-time -D_FORTIFY_SOURCE=2  -pthread 
-DTARGET=\"x86_64-pc-linux-gnu\" -DGMAPDB=\"/var/cache/gmap\" -mpopcnt 
-DHAVE_SSE2=1 -msse2 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -c -o 
gmap_sse2-getopt.o `test -f 'getopt.c' || echo './'`getopt.c
gcc -DHAVE_CONFIG_H -I.   -Wdate-time -D_FORTIFY_SOURCE=2  -pthread 
-DTARGET=\"x86_64-pc-linux-gnu\" -DGMAPDB=\"/var/cache/gmap\" -mpopcnt 
-DHAVE_SSE2=1 -msse2 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -c -o 
gmap_sse2-getopt1.o `test -f 'getopt1.c' || echo './'`getopt1.c
gcc -DHAVE_CONFIG_H -I.   -Wdate-time -D_FORTIFY_SOURCE=2  -pthread 
-DTARGET=\"x86_64-pc-linux-gnu\" -DGMAPDB=\"/var/cache/gmap\" -mpopcnt 
-DHAVE_SSE2=1 -msse2 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -c -o 
gmap_sse2-gmap.o `test -f 'gmap.c' || echo './'`gmap.c
/bin/bash ../libtool  --tag=CC   --mode=link gcc  -pthread 
-DTARGET=\"x86_64-pc-linux-gnu\" -DGMAPDB=\"/var/cache/gmap\" -mpopcnt 
-DHAVE_SSE2=1 -msse2 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security   -Wl,-z,relro 
-Wl,-z,now -o gmap.sse2 gmap_sse2-except.o 

Bug#901727: sbuild: add hashes of source package to build log

[Johannes Schauer]

Hi,

On Sun, 17 Jun 2018 22:13:54 +0800 Paul Wise  wrote:
> It would be nice to have the full contents of the .dsc included in the
> build log, similarly to how the .changes and .buildinfo files are
> included in the build log.
> 
> This would enhance the traceability of buildd admin actions.
> 
> For example the admin of the hppa buildd mx3210 has modified the source
> package to enable it to build on hppa, without publishing the source
> package anywhere (but filed a bug to update debian/rules):
> 
> https://buildd.debian.org/status/fetch.php?pkg=normaliz=hppa=3.6.0%2Bds-1=1528456221=0
> https://buildd.debian.org/status/fetch.php?pkg=normaliz=hppa=3.6.0%2Bds-1=1528654212=0
> https://bugs.debian.org/901700

I'm unsure whether the sbuild build log is the right place for this. Look at it
this way: .changes and .buildinfo are part of the log because they are the
*output* of running sbuild. The .dsc is the *input* for sbuild. Thus, whoever
runs sbuild already has a .dsc and does not need the build log to contain a
copy of it.

In your case, the buildd has the dsc and thus the actual problem seems to be,
that it is currently hard to retrieve the .dsc that was used from
buildd.debian.org.

Thus, I suggest that you rather convince the maintainers of buildd.debian.org
to make it easier to find out what they were feeding sbuild with.

Do you agree?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#902819: system freeze (hang task) when launching Xorg(1) after a new version of linux-image installed

[M0xkLurk3r]

Package: nvidia-driver
Version: 390.48
Severity: serious

Dear Maintainer:
I had upgrade my linux-image to a new version (4.16.0-2, exactly 
4.16.16), then i found the Xorg were failed to start up, the screen shows blank 
and the keyboard stops answer, then i try to grab out what's kernel happening 
in the meantime, and i found kernel gives looping oop with "CPU stuck" and 
"hang task" messages.
Probably the issue were still exists in upstream, i try to remove this 
package and install the offical nVIDIA linux driver (version 390.67), and the 
bug were still exists and perfectly reproduce. Then i remove the nvidia driver 
and turn to uses nouveau, this issue disappear(but as well known, the nouveau 
takes a huge performance penalty on graphics that i can't accept)


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

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

Versions of packages nvidia-driver depends on:
pn  nvidia-alternative
pn  nvidia-driver-bin 
pn  nvidia-driver-libs | nvidia-driver-libs-nonglvnd  
pn  nvidia-installer-cleanup  
pn  nvidia-kernel-dkms | nvidia-kernel-390.48 
pn  nvidia-legacy-check   
pn  nvidia-support
pn  nvidia-vdpau-driver   
pn  xserver-xorg-video-nvidia 

Versions of packages nvidia-driver recommends:
pn  nvidia-persistenced  
pn  nvidia-settings  

Versions of packages nvidia-driver suggests:
pn  nvidia-kernel-dkms | nvidia-kernel-source  

Bug#902797: lintian: check latest changelog entry for duplicate contributor information

[Florian Schlichting]

Hi,

On Sun, Jul 01, 2018 at 11:37:21AM +0200, Mattia Rizzolo wrote:
> On Sun, Jul 01, 2018 at 12:39:47PM +0800, Paul Wise wrote:
> > I recently saw a changelog entry (quoted below) for a Perl team package
> > where several contributors to that version had their names mentioned
> > multiple times with one or more changes below each instance of their
> > name. This made the changelog harder to read. I think it would be
> > useful for lintian to emit a pedantic or info-level warning for
> > duplicate contributor information in the latest changelog entry.
> 
> I personally agree with you here, but apparently not everybody does.
> ISTR to remember in the past suggesting to change the default of dch
> --multimaint-merge but somebody complained that that way it would lose
> the chronological order of the changes or something like that (I don't
> really buy it).

I'm probably guilty of uploading a fair number of packages with such
changelogs over the last few days, as I'm working through a list of perl
team packages that haven't had an upload in over six years and thus still
point to SVN with their version in the archive.

Most of those changelog entries stem from (semi-)automatic mass commits
made over the years to our several thousand packages; and some of them
change the very same thing a previous entry modified. In the example
that Paul cited, Ansgar first changed the Vcs-* lines from svn.d.o to
git.d.o in 2011, then Salvatore changed git.d.o to anonscm.d.o in 2013,
git:// to https:// in 2016, and anonscm.d.o to salsa.d.o in 2018, each
time adding a commit with the change and one that modified d/changelog
using dch. If that last commit was made by Ansgar again, wouldn't
--multimaint-merge result in a confusing changelog that lists final
modifications before intermediate ones?

Having said that, I don't have a strong feeling about how changelogs
should look like, other than that the default behaviour of our tools
should agree with what lintian wants to see. In my use of d/changelog,
both as a packager and occasionally as a user looking at an installed
package, it's a mirror of the packaging repository's git history, very
likely auto-generated, and a bit redundant as a source of information...

Florian

Bug#902620: certbot.service should not use root privileges

[Harlan Lieberman-Berg]

forcemerge 819107 902620 810216
severity 902620 normal
thanks

Hello Roland,

We definitely want to move to using a more "Debian standard" approach
to the certbot user -- especially for the keys it writes out --, but
it's a complicated problem. For example, many of the certbot plugins
add or alter webserver configuration, which means that the certbot
user would need permission to access those directories, or some method
of gaining higher privileges for certain operations.

This is something we've talked about with upstream in the past, but we
don't currently have a plan to implement.  I'd personally like to see
us switch to use a more Debian approach for the key storage before we
do anything else -- something I'd like to see go into buster.

Thanks for reporting this!

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#902817: fail2ban: SyntaxError when run with python3.7

[James Valleroy]

Package: fail2ban
Version: 0.10.2-2
Severity: important

fail2ban uses 'async' as a parameter/variable name. But it's a
reserved keyword in python3.7.

I found the problem in this CI build:
https://salsa.debian.org/freedombox-team/plinth/-/jobs/28625

Setting up fail2ban (0.10.2-2) ...
  File "/usr/lib/python3/dist-packages/fail2ban/client/fail2banclient.py", line 
231
def configureServer(self, async=True, phase=None):
  ^
SyntaxError: invalid syntax

  File "/usr/lib/python3/dist-packages/fail2ban/client/fail2banserver.py", line 
173
async = self._conf.get("async", False)
  ^
SyntaxError: invalid syntax

dpkg: error processing package fail2ban (--configure):
 installed fail2ban package post-installation script subprocess returned error 
exit status 1

Bug#902816: mini-httpd: mini-httpd fails to stop upon "systemctl top"

[Łukasz Stelmach]

Package: mini-httpd
Version: 1.23-1.2
Severity: important

Dear Maintainer,

1. I started mini-httpd with "systemctl start mini-httpd"


2. I tried to stop it with "systemctl stop mini-httpd"

3. The process was still running. Among other log messages ther was this
   one 

start-stop-daemon: warning: this system is not able to track process names 
longer than 15 characters, please use --exec instead of --name.

4. I expected mini-httpd to stop after "systemctl stop" command.

To fix the problem, the following patch for /etc/init.d/mini-httpd is
required.

--8<---cut here---start->8---
--- a/etc/init.d/mini-httpd 2018-07-01 17:10:15.354864914 +0200
+++ b/etc/init.d/mini-httpd 2018-07-01 17:10:31.079301238 +0200
@@ -60,7 +60,7 @@
fi
fi
else 
-   start-stop-daemon --stop --quiet --oknodo --name $DAEMON
+   start-stop-daemon --stop --quiet --oknodo --exec $DAEMON
fi
echo "$NAME."
 }
--8<---cut here---end--->8---


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

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

Versions of packages mini-httpd depends on:
ii  libc6  2.24-11+deb9u3
ii  libssl1.1  1.1.0f-3+deb9u2

Versions of packages mini-httpd recommends:
pn  apache2-utils  

mini-httpd suggests no packages.

-- Configuration Files:
/etc/default/mini-httpd changed:
START=1
DAEMON_OPTS="-C /etc/mini-httpd.conf"

/etc/init.d/mini-httpd changed:
set -x
. /lib/lsb/init-functions
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/sbin/mini_httpd
NAME=mini_httpd
DESC="web server"
PIDFILE=/var/run/mini_httpd.pid
test -x $DAEMON || exit 0
if [ -f /etc/default/mini-httpd ]
then
. /etc/default/mini-httpd
fi
set -e
start() {
if [ "$START" = "1" ]
then
echo -n "Starting $DESC: "
start-stop-daemon --start --quiet --pidfile /var/run/$NAME.pid \
--exec $DAEMON -- $DAEMON_OPTS
echo "$NAME."
else
printf "You have to edit /etc/mini-httpd.conf 
and\n/etc/default/mini-httpd before running mini-httpd!\n"
printf " "
exit 0
fi
}
stop() {
echo -n "Stopping $DESC: "
# Get pid number
if [ -e /var/run/$NAME.pid ]
then
PID=`cat /var/run/$NAME.pid`
if [ -d /proc/$PID ]
then
start-stop-daemon -v --stop --quiet --oknodo --pidfile 
/var/run/$NAME.pid
else
# we need to remove the pidfile manually
if [ -e /var/run/$NAME.pid ]
then
rm -f /var/run/$NAME.pid
fi
fi
else 
start-stop-daemon --stop --quiet --oknodo --exec $DAEMON
fi
echo "$NAME."
}
case "$1" in
  start)
start
;;
  stop)
stop
;;
  status)
status_of_proc -p $PIDFILE $DAEMON $NAME && exit 0 || exit $?
;;
  restart|force-reload)
stop
start
;;
  *)
N=/etc/init.d/$NAME
echo "Usage: $N {start|stop|status|restart|force-reload}" >&2
exit 1
;;
esac
exit 0

/etc/mini-httpd.conf changed:
ssl
host=zniczek.stlmch.eu
port=80
user=nobody
nochroot # no
data_dir=/var/www/html
cgipat=cgi-bin/*
certfile=/etc/ssl/private/mini-httpd.cert
logfile=/var/log/mini-httpd.log
pidfile=/var/run/mini-httpd.pid
charset=iso-8859-1


-- no debconf information

-- 
Było mi bardzo miło.  --- Rurku. --- ...
>Łukasz<--- To dobrze, że mnie słuchasz.


signature.asc
Description: PGP signature

Bug#901590: duplicity: Backblaze B2 backups error with "Bucket cannot be created"

[Ashlyn Black]

Using 0.7.17 and still having this issue.

Authtoken expired, will reauthenticate with next attempt
FatalBackendException: Bucket cannot be created

Bug#892993: sphinx-rtd-theme CSS is not properly rebuilt from source

[Dmitry Shachnev]

Control: block -1 by 899124

On Thu, Mar 15, 2018 at 01:12:03PM +0300, Dmitry Shachnev wrote:
> This theme is currently not properly rebuilt from its SASS source.
> What is in debian/missing-sources/theme.css is only a de-uglified
> version of the built CSS file provided by upstream.

I almost have a working solution for this, but it needs font-awesome v4
SCSS files, so adding a blocker bug for getting v4 (re-)packaged.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#902654: larry6: Add support for SVGA version

[Simon McVittie]

On Sat, 30 Jun 2018 at 21:48:07 +0700, Рома Тенцер wrote:
> Still doesn't work.

Try with current git? Please try the VGA version too - I don't think
I've broken it, but it's best to be sure.

The description that g-d-p uses to package this game is in
data/larry6.yaml. Run "make" after making any changes.

smcv

Bug#896933: sbuild: bd-uninstallable-explainer is run on sbuild-build-depends-*-dummy even if installation of sbuild-build-depends-core-dummy failed

[Johannes Schauer]

Control: merge -1 871968

On Thu, 26 Apr 2018 07:15:32 +0200 Johannes Schauer  wrote:
> sbuild runs the bd-uninstallable-explainer on the build-depends-*-dummy
> package even in cases where installation of build-depends-core-dummy failed.
> At that point, build-depends-*-dummy is not yet generated, so sbuild fails
> with:
> 
>  Cannot find any package corresponding to the selector 
> sbuild-build-depends-hello-dummy:ppc64el
> 
> A build log is attached.
> 
> Instead, when failing to install build-depends-core-dummy, the
> bd-uninstallable-explainer should check for that package and not the
> build-depends-*-dummy package.

This problem is fixed by the solution to #871968, thus merging.


signature.asc
Description: signature

Bug#902814: input-pad: Please package new version and switch upstream project

[Boyuan Yang]

Source: input-pad
Version: 1.0.3-1
Severity: important

Dear input-pad maintainers and debian-input-method members,

Package input-pad in Debian needs to be updated. Its homepage has moved to
https://github.com/fujiwarat/input-pad and some new releases were made there.

--
Regards,
Boyuan Yang



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

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

Bug#871968: sbuild does not ensure presence of build-essential

[Johannes Schauer]

Control: severity -1 important

Hi,

On Sun, 13 Aug 2017 06:44:49 +0200 Helmut Grohne  wrote:
> sbuild splits the implicit (build-essential) and explicit Build-Depends into
> two dummy packages and installs them separately. In theory, that can cause
> the latter to remove the former, but I haven't observed this.  When
> installing the latter fails, sbuild launches dose by default to explain the
> problem. While doing so, it tends to produce installation sets that lack
> build-essential as the former package is not passed to dose. This issue can
> currently be triggered by cross building lp-solve.
> 
> I argue that the dose3 explainer should ensure that build-essential is kept.

this is not only a problem of the explainer. This is a conceptual issue with
the way sbuild install packages. Instead of installing them step by step, it
should create a single big meta dummy package that contains everything and
install that. This would also solve the issue of the explainer.

I'm gonna postpone fixing this a bit but increase the severity because this is
an issue that I want to see fixed.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#901043: vkd3d-demos: /usr/bin/triangle is already shipped by the triangle-bin package

[Michael Gilbert]

control: tag -1 pending

On Fri, Jun 8, 2018 at 7:28 AM, Andreas Beckmann wrote:
> I don't think a -demos package should ship binaries with generic
> names in /usr/bin - and maybe not in /usr/bin at all.

I uploaded a new version fixing this last week, it is currently
awaiting review in NEW.

Best wishes,
Mike

Bug#868657: sbuild tries to create /build even when told otherwise

[Johannes Schauer]

Hi Ian,

sorry, I forgot to CC you in my reply to bug #868657 (see below) and when I
found the thread in my inbox, I found that we had already talked outside of the
bug report and that also answered my question about what you want to do. :)

If you find more issues, please report them. Thanks!

cheers, josch

Quoting Johannes Schauer (2018-07-01 16:20:56)
> Control: tag -1 + pending
> 
> Hi Ian,
> 
> On Mon, 17 Jul 2017 10:59:35 +0100 Ian Jackson 
>  wrote:
> > I am trying to do a strange thing: use sbuild with adt-virt-null, without
> > being root.
> 
> I'm curious, what strange thing is that?
> 
> > I have discovered that sbuild insists on trying to create /build even if an
> > alternative --build-path is specified:
> > 
> > + 
> > BUILD_PATH=/home/ian/things/Dgit/dgit/tests/tmp/sbuild-adt-null/sbuild-build-path
> > + sbuild --chroot-mode=autopkgtest 
> > --autopkgtest-virt-server=/usr/bin/fakeroot 
> > --autopkgtest-virt-server-opt=adt-virt-null -D 
> > --build-path=/home/ian/things/Dgit/dgit/tests/tmp/sbuild-adt-null/sbuild-build-path
> >  '--dpkg-source-opts=-Zgzip -z1 --format=1.0 -sn'
> > ...
> > I: env sh -c cd / && exec "$@" exec /bin/sh -c set -e; if [ ! -d /build ] ; 
> > then mkdir -m 0775 /build; fi
> > D: Setting Log Stream Error=1
> > D: Running command: env sh -c cd / && exec "$@" exec /bin/sh -c set -e; if 
> > [ ! -d /build ] ; then mkdir -m 0775 /build; fi
> > mkdir: cannot create directory '/build': Permission denied
> > E: Failed to create build directory /build
> > Failed to set up chroot
> > 
> > (I expect that when I get past this I will have to prevent it from
> > running apt.)
> > 
> > Full repro:
> >  $ git clone git://git.chiark.greenend.org.uk/~ianmdlvl/dgit.git
> >  $ cd dgit
> >  $ git checkout 904c4128a89555d5caecb100943da23fffd7ee98
> >  $ tests/using-intree tests/tests/sbuild-adt-null 2>&1 |tee ../log
> > 
> > You will find that this hangs.  That is due to a bug in adt-virt-null,
> > #868576.  However, you can look at the logfile;
> >  ^Z
> >  $ less tests/tmp/sbuild-adt-null/example_1.1-1_amd64.build
> > 
> > Observe in that log the error messages I quote above.
> > The file ../log (from tee) will contain the output from the dgit test
> > machinery, which includes much noise, but I don't think is relevant.
> 
> I now fixed this particular bug in commit
> 435d85f89ea091946e281fd2724ea576f3a87003 but I suspect there are many more
> problems ahead for you. What is it that you want to do?
> 
> Thanks!
> 
> cheers, josch


signature.asc
Description: signature

Bug#868657: sbuild tries to create /build even when told otherwise

[Johannes Schauer]

Control: tag -1 + pending

Hi Ian,

On Mon, 17 Jul 2017 10:59:35 +0100 Ian Jackson 
 wrote:
> I am trying to do a strange thing: use sbuild with adt-virt-null, without
> being root.

I'm curious, what strange thing is that?

> I have discovered that sbuild insists on trying to create /build even if an
> alternative --build-path is specified:
> 
> + 
> BUILD_PATH=/home/ian/things/Dgit/dgit/tests/tmp/sbuild-adt-null/sbuild-build-path
> + sbuild --chroot-mode=autopkgtest 
> --autopkgtest-virt-server=/usr/bin/fakeroot 
> --autopkgtest-virt-server-opt=adt-virt-null -D 
> --build-path=/home/ian/things/Dgit/dgit/tests/tmp/sbuild-adt-null/sbuild-build-path
>  '--dpkg-source-opts=-Zgzip -z1 --format=1.0 -sn'
> ...
> I: env sh -c cd / && exec "$@" exec /bin/sh -c set -e; if [ ! -d /build ] ; 
> then mkdir -m 0775 /build; fi
> D: Setting Log Stream Error=1
> D: Running command: env sh -c cd / && exec "$@" exec /bin/sh -c set -e; if [ 
> ! -d /build ] ; then mkdir -m 0775 /build; fi
> mkdir: cannot create directory '/build': Permission denied
> E: Failed to create build directory /build
> Failed to set up chroot
> 
> (I expect that when I get past this I will have to prevent it from
> running apt.)
> 
> Full repro:
>  $ git clone git://git.chiark.greenend.org.uk/~ianmdlvl/dgit.git
>  $ cd dgit
>  $ git checkout 904c4128a89555d5caecb100943da23fffd7ee98
>  $ tests/using-intree tests/tests/sbuild-adt-null 2>&1 |tee ../log
> 
> You will find that this hangs.  That is due to a bug in adt-virt-null,
> #868576.  However, you can look at the logfile;
>  ^Z
>  $ less tests/tmp/sbuild-adt-null/example_1.1-1_amd64.build
> 
> Observe in that log the error messages I quote above.
> The file ../log (from tee) will contain the output from the dgit test
> machinery, which includes much noise, but I don't think is relevant.

I now fixed this particular bug in commit
435d85f89ea091946e281fd2724ea576f3a87003 but I suspect there are many more
problems ahead for you. What is it that you want to do?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#901471: Thunderbird should not be able to render the xserver unusable

[Erich Schubert]

I am unsure where to clone the issue.

For obvious reasons, a client application like thunderbird should not be 
able to break the xserver in a way that thunderbird does.


While extending the apparmor permissions makes thunderbird work again 
(and thus solves this bug), there is an underlying issue with the 
xserver most likely.


When I try to use thunderbird with apparmor enabled, the xserver stops 
drawing except for the mouse cursor; and even killing the thunderbird 
process does not fix the xserver. That should be prevented on the 
xserver side.


Regards,
Erich

Bug#867180: sbuild: autopkgtest/lxc: cannot create /autopkgtest-virt-dummy-location/etc/group: Directory nonexistent

[Johannes Schauer]

Control: tag -1 + pending

Hi Ian & Julian,

On Tue, 15 May 2018 20:25:46 +0100 Ian Jackson 
 wrote:
> In summary: I think the root cause is that the lxc container is not
> set up the way sbuild expects.

I would say the root cause is, that sbuild is buggy but indeed, the code that
tries to modify /etc/group is only run if the container does not have an sbuild
group.

> The named directory becomes $self->get('Location') within sbuild; it's
> a dummy value used when (as in this case) the chroot provider does not
> have a way to access the within-chroot filesystem from outside it.
> 
> It is used in relatively few places.  Searching for more of the error
> message found a use in basesetup (in ChrootSetup.pm).  It seems to try
> to use it only if the `sbuild' group is not found in the chroot.

Yes, your analysis is entirely correct.

> Looking at the code, sbuild expects various other preparatory things
> to have been done to the chroot.  It expects a /build directory, and
> /var/lib/sbuild, and so on.  I can't find any of this documented
> anywhere.

It could be documented but I don't think it's a high priority to document these
internals. I think sbuild should be able to cope with any plain Debian chroot
and it should be the task of sbuild itself to do the setup that it requires.
This is why sbuild calls the basesetup() function every time it starts a new
chroot session (independent of the backend).

> Hopefully the following, observed in an schroot of mine, is helpful:
> 
> $ id sbuild
> uid=120(sbuild) gid=124(sbuild) groups=124(sbuild)
> $ find /build/ /var/lib/sbuild/ -ls
>606209  4 drwxrws---   2 sbuild   sbuild   4096 Jun  3  2016 
> /build/
>344285  4 drwxrws---   3 sbuild   sbuild   4096 Jun  3  2016 
> /var/lib/sbuild/
>344838  4 -rw-rw-r--   1 root sbuild   1417 Jun  3  2016 
> /var/lib/sbuild/package-checklist
>344355  4 drwxrws---   2 sbuild   sbuild   4096 Jun  3  2016 
> /var/lib/sbuild/srcdep-lock
>344721  4 -rw---   1 root sbuild117 Jun  3  2016 
> /var/lib/sbuild/apt.conf
> $ 
> 
> Is there a script that someone could run in an existing
> vm/container/whatever, to prepare it appropriately, before
> snapshotting ?

I don't know of any but the basesetup() function is not doing much so I wonder
if it would be worth the added complexity.

> Also, the error message seems poor.

Agreed.

> I suggest the following approach:
> 
>  * Break out the relevant bits of sbuild-createchroot into an
>advertised script that can be run as root within the master
>image (what schroot calls the source chroot).

I don't think that should be necessary. Sbuild should do the setup that it
requires itself.

If you find "relevant bits of sbuild-createchroot" which are *required* and not
carried out by sbuild itself, please file a bug!

It should be possible for sbuild to work with a plain debootstrap-ed chroot.

>  * Replace calls to ->get('Location') with ->get_location($reason)
>and make the latter fail if the access is not supported.
>$reason will be an explanation of what schroot was trying to do.
>So it will say something like
>  E: filesystem access to chroot not supported (wanted because: trying to 
> add sbuild group)

There is a better way: avoid the use of 'Location' altogether. Since the
failing piece of code is only attempting to add the sbuild group, sbuild now
instead calls $(groupadd --system sbuild) from within the chroot environment.
There is really no need for direct filesystem access here.

Autopkgtest was the first backend for sbuild where the host potentially didn't
have direct filesystem access to the chroot directory. Back then I tried to
eradicate lots of places where 'Location' was used in a similar way as it is
done here. This one must've slipped.

Thanks for the report!

>  * In the longer term, the virt servers should have a way to edit
>the master image.  Then you could say sbuild --setup-the-thing
>--autopkgtest-etc.

It seems that this is not going to happen:

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

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#860064: #860064 dnsmasq will not start after dns-root-data upgrade

[Adam D. Barratt]

On Sun, 2018-07-01 at 11:38 +, Martin, Christoph wrote:
> dns-root-data had an update a week before. the file with the dns root
> keys was updated. at least the format has changed.

To re-iterate, no such change has happened recently in stretch.

I understand that the update in jessie may have introduced such a
change, but at this stage there's unfortunately nothing that either the
security or release teams can do about that, as jessie is EOL and has
moved to the LTS team.

Regards,

Adam

Bug#902797: lintian: check latest changelog entry for duplicate contributor information

[Adam D. Barratt]

On Sun, 2018-07-01 at 11:37 +0200, Mattia Rizzolo wrote:
> On Sun, Jul 01, 2018 at 12:39:47PM +0800, Paul Wise wrote:
> > I recently saw a changelog entry (quoted below) for a Perl team
> > package
> > where several contributors to that version had their names
> > mentioned
> > multiple times with one or more changes below each instance of
> > their
> > name. This made the changelog harder to read. I think it would be
> > useful for lintian to emit a pedantic or info-level warning for
> > duplicate contributor information in the latest changelog entry.
> 
> I personally agree with you here, but apparently not everybody does.
> ISTR to remember in the past suggesting to change the default of dch
> --multimaint-merge but somebody complained that that way it would
> lose the chronological order of the changes or something like that (I
> don't really buy it).
> 

When I initially added the merging functionality, I made it the
default. Joey Hess objected, and said that he'd intentionally
implemented the "strictly chronological" ordering, so it was made a
non-default option.

Regards,

Adam

Bug#866023: "gpg: signing failed: A locale function failed" when GnuPG User ID is non-ASCII

[Johannes Schauer]

Control: tag -1 + moreinfo

Hi dkg,

On Mon, 26 Jun 2017 14:31:04 -0400 Daniel Kahn Gillmor  
wrote:
> I got a report on IRC that sbuild was failing during its signing phase with
> the error message:
> 
> gpg: signing failed: A locale function failed
> 
> but normal gpg signing was working fine.
> 
> I tracked this down to what appears to be an upstream bug with
> pinentry when trying to sign in LC_ALL=C when the User ID for the
> signing key has a non-ASCII character in it:
> 
> https://dev.gnupg.org/T3222
> 
> However, sbuild shouldn't be enforcing a C (or any other non-UTF-8)
> locale during the signing phase, so there's something wrong with
> sbuild too.
> 
> Looking in the source for sbuild, i think it looks like it's setting
> C.UTF-8 which shouldn't have this problem.  But the problem happens
> anyway, and i haven't been able to track it down further.
> 
> My attempt at building that let me replicate this error was:
> 
> sbuild -d sid-amd64-sbuild -k $KEYID $DSCNAME
> 
> (where $KEYID refered to a secret key i have access to with only one
> User ID.  That User ID was 'Test Usér ')

thanks a lot for your report and your investigation!

Unfortunately, I'm not able to reproduce your findings. :(

Build needed 00:00:22, no disk space
Signature with key '96758709F780776A746BB14CCC1BF96161B0F46B' requested:
 signfile buildinfo 
/home/josch/git/dpkg-tests/t-source-minimal/pkg-minimal_1.0_amd64.buildinfo 
96758709F780776A746BB14CCC1BF96161B0F46B

 fixup_changes buildinfo 
/home/josch/git/dpkg-tests/t-source-minimal/pkg-minimal_1.0_amd64.buildinfo 
/home/josch/git/dpkg-tests/t-source-minimal/pkg-minimal_1.0_amd64.changes
 signfile changes 
/home/josch/git/dpkg-tests/t-source-minimal/pkg-minimal_1.0_amd64.changes 
96758709F780776A746BB14CCC1BF96161B0F46B

Successfully signed buildinfo, changes files

This is a key I just created for testing purposes. As you can see, there are
definitely non-ASCII characters in its user id:

gpg: checking the trustdb
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   4  signed:   1  trust: 0-, 0q, 0n, 0m, 0f, 4u
gpg: depth: 1  valid:   1  signed:   0  trust: 1-, 0q, 0n, 0m, 0f, 0u
pub   rsa1024/CC1BF96161B0F46B 2018-07-01 [SC]
  96758709F780776A746BB14CCC1BF96161B0F46B
uid [ultimate] Pokémon ポケモン 

Any idea what I could do to see the issue you are having?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#884105: gdb: bump libunwind version dependency for ia64

[James Clarke]

Control: tags -1 patch

On Fri, Jan 19, 2018 at 01:12:03PM -0500, Jason Duerstock wrote:
> After some discussion on #debian-ports, I believe this should be
> changed from libunwind7-dev to libunwind-dev.
>
> Jason

I have created a merge request on Salsa for this[1].

Regards,
James

[1] https://salsa.debian.org/gdb-team/gdb/merge_requests/2

Bug#893189: transition: llvm-defaults to llvm 6.0

[Sylvestre Ledru]

Le 23/06/2018 à 11:15, Emilio Pozuelo Monfort a écrit :
> On 23/04/18 20:39, Sylvestre Ledru wrote:
>> Le 23/04/2018 à 19:58, Emilio Pozuelo Monfort a écrit :
>>> Hi Sylvestre,
>>>
>>> On 28/03/18 00:10, Emilio Pozuelo Monfort wrote:
 On 17/03/18 09:43, Sylvestre Ledru wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
>
> Hello,
>
> This is again the time to transition to a more recent version of LLVM.
> This time to 6.0. Just like in bug 832098 & 869752, I propose that we 
> skip one version (5.0 here)
>
> All supported archs are green:
> https://buildd.debian.org/status/package.php?p=llvm-toolchain-6.0=sid
>  
> 
> I am rebuilding the packages with v6.0.
 How did the rebuild go?
>>> Any news here?
>> Not yet, sorry. been busy with other things!
> Hi Sylvestre, any progress with this? Would be nice to bump llvm-defaults so
> that we can start removing the old versions.

I reported a few bugs and made them block this one.

I think we are good to go. :)

S

Bug#902813: httping: Please depends on an unversionned of clang-tools

[Sylvestre Ledru]

Package: httping
Severity: important

Dear Maintainer,

As part of the llvm-toolchain 6.0, please depends on clang-tools
instead of clang-tools-4.0. 
Even without the transition, you should depend on the same version of clang.

the diff should be:
--- control.orig2018-07-01 15:25:17.574603016 +0200
+++ control 2018-07-01 15:25:21.010641653 +0200
@@ -5,7 +5,7 @@
 Build-Depends: debhelper (>= 11),
libssl-dev,
clang,
-   clang-tools-4.0,
+   clang-tools,
libncursesw5-dev,
libncurses5-dev,
libfftw3-dev,

Sylvestre


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

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

Versions of packages httping depends on:
ii  libc6 2.26-6
ii  libfftw3-double3  3.3.7-1
ii  libncursesw5  6.1-1
ii  libssl1.1 1.1.0g-2
ii  libtinfo5 6.1-1
ii  openssl   1.1.0g-2

httping recommends no packages.

httping suggests no packages.

Bug#902812: wcc FTBFS

[Sylvestre Ledru]

Package: wcc
Severity: important

Dear Maintainer,

Looks like wcc fails to build from source:

cc -Wdate-time -D_FORTIFY_SOURCE=2 -W -Wall -Wno-discarded-qualifiers 
-Wno-int-conversion -Wno-unused-parameter -Wno-unused-function 
-Wno-unused-result -fpie -pie -fPIC -g3 -ggdb -I../../include  
-I./include/sflib/ -I./include -I../../include/  
-Wno-incompatible-pointer-types  -fstack-protector-all -Wl,-z,relro,-z,now 
-DPACKAGE -DPACKAGE_VERSION -masm=intel -rdynamic -D_fORTIFY_SOURCE=2 -O2 wcc.c 
-o wcc -lbfd -lelf -lcapstone
In file included from wcc.c:33:
/usr/include/bfd.h:41:10: fatal error: diagnostics.h: No such file or directory
 #include "diagnostics.h"
  ^~~
compilation terminated.

Cheers,
Sylvestre



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

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

Bug#902811: castxml will fail after the llvm 6.0 migration

[Sylvestre Ledru]

Package: castxml
Severity: important

Dear Maintainer,

We are planning to migrate to llvm 6.0 pretty soon.

castxml fails to build with the following error:
  
cd /build/castxml-0.1+git20170823/obj-x86_64-linux-gnu/src && /usr/bin/c++   
-DCASTXML_INSTALL_DATA_DIR=\"share/castxml\" -I/usr/lib/llvm-6.0/include 
-I/build/castxml-0.1+git20170823/obj-x86_64-linu\
x-gnu/src  -g -O2 -fdebug-prefix-map=/build/castxml-0.1+git20170823=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fno-exceptions -fno-rtti -std=c++11  \
 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
-D__STDC_LIMIT_MACROS -o CMakeFiles/castxml.dir/Utils.cxx.o -c 
/build/castxml-0.1+git20170823/src/Utils.cxx 
/build/castxml-0.1+git20170823/src/Utils.cxx: In function 'bool runCommand(int, 
const char* const*, int&, std::__cxx11::string&, std::__cxx11::string&, 
std::__cxx11::string&)':   
/build/castxml-0.1+git20170823/src/Utils.cxx:146:65: error: could not convert 
'(const llvm::StringRef**)(& redirects)' from 'const llvm::StringRef**' to 
'llvm::ArrayRef >'   

   
   ret = llvm::sys::ExecuteAndWait(prog, &*cmd.begin(), nullptr, redirects, 0,  

   
 ^  

   
make[3]: *** [src/CMakeFiles/castxml.dir/build.make:118: 
src/CMakeFiles/castxml.dir/Utils.cxx.o] Error 1 


Could you please fix that?
Thanks
S

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

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

Versions of packages castxml depends on:
ii  libc6   2.27-3
ii  libgcc1 1:8-20180402-1
ii  libstdc++6  8-20180402-1
ii  libtinfo5   6.1-1
ii  libtinfo6   6.1+20180210-4
ii  zlib1g  1:1.2.8.dfsg-5

castxml recommends no packages.

castxml suggests no packages.

Bug#890602: sbuild fails to install Build-Depends of pam: unsatisfied dependency libfl-dev:native

[Johannes Schauer]

Control: tag -1 + moreinfo

On Fri, 16 Feb 2018 16:49:54 +0100 Helmut Grohne  wrote:
> sbuild fails to install Build-Depends of pam. With build arch amd64 and host
> arch arm64, sbuild merges the dependencies "libfl-dev" and "libfl-dev:native"
> into a single dependency "libfl-dev". After installing the Build-Depends,
> libfl-dev:amd64 is not installed and dpkg-buildpackage complains about
> libfl-dev:native being unsatisfied.

Are you sure? Since libfl-dev:native is not part of the build dependencies of
src:pam anymore, I build pam_1.1.8-3.5.dsc and I'm getting:

Merged Build-Depends: libcrack2-dev (>= 2.8), bzip2, debhelper (>= 9), quilt
(>= 0.48-1), flex, libdb-dev, libselinux1-dev, po-debconf, dh-autoreconf,
autopoint, libaudit-dev, pkg-config, libfl-dev, libfl-dev:amd64, docbook-xsl,
docbook-xml, xsltproc, libxml2-utils, w3m

According to that output, libfl-dev:native gets correctly translated to
libfl-dev:amd64

Could you provide more details?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#902810: user-mode-linux: FTBFS in stretch (Hunk #1 FAILED in 07-remove-rpath.patch)

[Santiago Vila]

Package: src:user-mode-linux
Version: 4.9-1um-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in stretch + security + stretch-proposed-updates 
but it failed:


[...]
 debian/rules build-arch
tar -x -f /usr/src/linux-source-4.9.tar.xz
touch unpack-stamp
(cd linux-source-4.9 && QUILT_PATCHES=/<>/debian/patches quilt 
push -a)
Applying patch /<>/debian/patches/02_x-terminal-emulator.patch
patching file arch/um/drivers/xterm.c

Applying patch /<>/debian/patches/03_uml_switch.patch
patching file arch/um/drivers/daemon_kern.c

Applying patch /<>/debian/patches/05_fix_static_build.patch
patching file arch/um/Makefile
Hunk #1 succeeded at 91 (offset 15 lines).

Applying patch /<>/debian/patches/06-fix-linkage-on-386-arch.patch
patching file arch/x86/um/Makefile
Hunk #1 succeeded at 19 with fuzz 2.

Applying patch /<>/debian/patches/07-remove-rpath.patch
patching file arch/um/Makefile
Hunk #1 FAILED at 107.
1 out of 1 hunk FAILED -- rejects in file arch/um/Makefile
patching file arch/x86/Makefile.um
Patch /<>/debian/patches/07-remove-rpath.patch does not apply 
(enforce with -f)
debian/rules:54: recipe for target 'patch-stamp' failed
make: *** [patch-stamp] Error 1
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2


The build was made with "dpkg-buildpackage -B" in my autobuilder but
it also fails with plain "dpkg-buildpackage" in reproducible builds:

https://tests.reproducible-builds.org/debian/rb-pkg/stretch/amd64/user-mode-linux.html

Thanks.

Bug#860064: #860064 dnsmasq will not start after dns-root-data upgrade

[Martin, Christoph]

Hi,

sorry for the late reply. I don‘t have everyday internet connection at the 
moment.

dns-root-data had an update a week before. the file with the dns root keys was 
updated. at least the format has changed. now there a dns time to live values 
in front of the keys. dnsmasq tries to parse these lines an puts the ttl value 
into the command line of dnsmasq which then fails to start.

and yes I consider a failing dnsmasq which is often used as a dns forwarder for 
whole networks as a critical problem.

> Am 27.06.2018 um 23:29 schrieb Adam D. Barratt :
> 
>> On Mon, 2018-06-25 at 10:44 +0200, Christoph Martin wrote:
>> severity 860064 critical
>> 
> 
> On which grounds are you claiming this qualifies for critical severity?
> 
> 
> It doesn't introduce a security hole, cause severe data loss or break
> your whole system. I have difficulty with dnsmasq and dns-root-data
> being "unrelated software", particularly given that dnsmasq-base has
> "Recommends: dns-root-data".
> 
> Regards,
> 
> Adam

Bug#902799: ([kwin-x11] Regression: Does not start (crashes repeatedly))

[Antonio Russo]

Control: severity -1 wishlist
Control: retitle -1 Please add correct versioned dependencies

The bug originally presented on a machine that was running testing (and not 
unstable).

I had used aptitude to pull a (presumably minimal) set of dependencies allowing 
kwin-x11
from unstable to be installed. That configuration---which naturally satisfied 
all stated
dependencies---generated the bug.

Using purely unstable does not cause this bug.

I am reducing the severity to wishlist because, while it would be nice to have 
accurate
dependency information, most users probably aren't going to experience this.

Bug#883294:

[ael]

On Thu, Apr 26, 2018 at 08:54:26AM +0200, Romain Perier wrote:
> Hello,
> 
> Could you :
> 
> - Retry with linux-image 4.15, that is the current kernel in buster/sid
> - Instead of not using IO-APIC completly, could you try to boot with
> kernel parameter "no_timer_check" ?

I reaaly do apologise for no reply in all this time! I have been away
without access to the machine.

Hope to do tests again in the next week.

ael

Bug#883294: linux-image-4.13.0-1-amd64: Kernel panic prevents boot: regression (apic)

[ael]

On Sun, Jul 01, 2018 at 02:57:02AM +0100, Ben Hutchings wrote:
> I'm sending these questions to you since Romain mistakenly sent them
> only to the bug:
> 
> On Thu, 26 Apr 2018 08:54:26 +0200 Romain Perier  
> wrote:
> > Hello,
> > 
> > Could you :
> > 
> > - Retry with linux-image 4.15, that is the current kernel in buster/sid
> 
> (but now 4.16 is current)
> 
> > - Instead of not using IO-APIC completly, could you try to boot with
> > kernel parameter "no_timer_check" ?
> > 
> > Does it help ?

No, Romain did send a copy to me. Absurd delay is because I have been
away without access to the machine. Will try to test this week.

Apologises again: I know how frustrating it is to look at a bug and not
get a prompt reply to follow up.

ael

Bug#902363: fix build with ld --as-needed

[Alberto Bertogli]

On Sat, Jun 30, 2018 at 08:58:08PM +0100, Chris Lamb wrote:

tags 902363 + pending
thanks

Dear Alberto,


https://blitiri.com.ar/git/r/libfiu/c/633bd2ae5d89850fecf71161bc74f21c04904c5b/

Would you mind giving it a try?


Sure thing - uploaded!


Thanks!



FYI I needed to clone the repo to get the "real" patch; does git-arr
support getting the .diff directly?


Not yet. If you'd find this feature useful, it would be quite easy to 
implement, so please let me know.




Oh, and git://blitiri.com.ar/libfiu
failed for me… ;)


This is intentional, I disabled git:// a few months ago as it was almost 
never used and significantly less secure than the https transport.
I think I've updated all references in the documentation but please let 
me know if something slipped.


Thanks again,
Alberto