Bug#935223: kcollectd removal

[Scott Kitterman]

On Friday, August 30, 2019 12:53:35 AM EDT Antonio Russo wrote:
> Hello,
> 
> You recently requested the removal of kcollectd from unstable due to the use
> of qt4. I've ported this to qt5, taken over upstream, and offered to adopt
> the package [1].
> 
> Would it be possible for you to comment on the suitability of the packaging
> for inclusion in Debian? Since I've received no offers to sponsor a package
> upload, and no comments on the packaging beyond the (now corrected) lintian
> reports, I don't know how I can proceed.
> 
> Thank you for your time,
> Antonio Russo
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935485

The only reason it was removed was due to Qt4.  I know of no other reason why 
it wouldn't be suitable.  The usual process to look for a sponsor is to upload 
the package to mentors.debian.net or if you plan to maintain the package in a 
team you can ask DDs in the team usually done via IRC or the team mailing 
list.

Scott K

Bug#936095: sardana: Obsolete libs (Python 2) - Depends on to be removed packages

[Scott Kitterman]

Source: sardana
Version: 2.6.2+dfsg-1
Severity: serious
Justification: Policy 2.5

It appears that upstream supports python3 [1].  Please either upgrade
the package or have it removed.  This is, indirectly, one of the few
remaining packages blocking python-qt4 removal.  We are also removing
Qt4.  This is expected to be complete early in the buster release cycle,
so please upgrade soon if you intend to.

If you are no longer interested in the package, feel free to let me know
in the bug and I'll take care of filing the rm if you don't want to.

Scott K

[1] https://github.com/sardana-org/sardana

Bug#929786: origtargz does not download multiple tarballs

[Pirate Praveen]

On Mon, 15 Jul 2019 21:33:47 +0530 Pirate Praveen  
wrote:
> On Fri, 31 May 2019 16:25:17 +0500 Pirate Praveen
>  wrote:
> > 
> > 
> > On Fri, May 31, 2019 at 3:12 PM, Mattia Rizzolo  
> > wrote:
> > > user devscri...@packages.debian.org
> > > usertags 929786 origtargz
> > > tags 929786 moreinfo
> > > quit
> > > 
> > > On Thu, May 30, 2019 at 08:26:27PM +0500, Pirate Praveen wrote:
> > >>  pravi@nishumbha:~/forge/debian/git/js-team/node-vinyl-fs$ origtargz
> > >>  pristine-tar: successfully generated 
> > >> ../node-vinyl-fs_3.0.3.orig.tar.gz
> > >> 
> > >>  But it failed to download multiple tarballs from archive. You can 
> > >> use
> > >>  https://salsa.debian.org/js-team/node-vinyl-fs to reproduce this 
> > >> issue.
> > > 
> > > Honestly, I don't think there is any sane way for `origtargz` to 
> > > fiugre
> > > that it needs to download/produce/build more than one orig tarball, 
> > > from
> > > inside the unpacked source.
> > > 
> > > That's an information that is available *only* from the .dsc, which is
> > > not something `origtargz` has access to.  Anything else would truly be
> > > guesswork.
> > > 
> > > 
> > > Suggestions?
> > > 
> > If #577113 gets implemented, that will give a uniform way to get list 
> > of components. But even now this information is available in 
> > debian/gbp.conf for packages that use git-buildpackage. I think 
> > origtargz should look in gbp.conf for components if the file is present.
> > 
> > When pristine-tar branch is missing it does apt source, I think the 
> > same could be tried here also.
> 
> pristine-tar list will show all the tarballs when it is a git clone and
> has pristine-tar branch.
> 

If debian/watch has a component entry, it can be used to find all components. 
It also has a list of all components (at least for all node packages this 
works).

Bug#847621: mpi4py: FTBFS on !linux: tests fail in MPI_INIT

[Drew Parsons]

Source: mpi4py
Followup-For: Bug #847621
Control: block -1 by 929975

mpi4py is now building on hurd.

kfreebsd is held up by an endless loop between numpy and matplotlib,
Bug #929975.

Bug#931949: transition: proj

[Sebastiaan Couwenberg]

On 8/28/19 6:05 AM, Sebastiaan Couwenberg wrote:
> On 8/26/19 5:42 AM, Sebastiaan Couwenberg wrote:
>> On 8/25/19 4:31 PM, Sebastiaan Couwenberg wrote:
>>> On 8/25/19 3:22 PM, Jonathan Wiltshire wrote:
 On Fri, Jul 12, 2019 at 09:39:26PM +0200, Bas Couwenberg wrote:
> For the Debian GIS team I'd like to transition to PROJ 6.
>
> This is a major change that affects the wider GIS ecosystem, with proj
> being at the bottom of the dependency chain.

 Please go ahead.
>>>
>>> Thanks!
>>>
>>> proj (6.1.1-1), libgeotiff (1.5.1-1) & python-pyproj (2.3.0+ds-1) have
>>> been uploaded to unstable. And the severity of the remaining bugreports
>>> has been raised.
>>
>> The packages are now also installed on all release architectures.
> 
> Thanks for the binNMUs.
> 
> For some reason survex was not included in the list of packages to
> rebuild, but libgeotiff-dfsg was. Please also binnmu survex.

survex still needs to be rebuilt with the new proj.

> The FTBFS of libgeotiff-dfsg will likely result in someone filing an RC
> bug which will get and keep it out of testing until it can be removed
> from the archive.

libgeotiff-epsg, the last remaining libgeotiff-dfsg rdep, has been
removed from the archive via #936044.

Removal of libgeotiff-dfsg was just requested in #936093.

> It looks like the recent update of scons broke the mapnik build, I've
> reporting it upstream and am trying various things to make it work again
> but haven't succeeded so far.

There is no solution for scons not using the environment variables any
more yet (#936017), so I had to revert to using the embedded copy of
scons 3.0.1 included in the mapnik upstream tarballs. The upload to
unstable will follow shortly.

That leaves:

 * openorienteering-mapper (#931935)

 * vtk6 (#931943)
   Fixed version only available in experimental,
   maintainer said he'll move it to unstable soon.

 * vtk7 (#931944)

 * lammps
   Once the fixed vtk6 is in unstable it should build successfully.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#936060: rocksndiamonds lintian override for maintainer-script-should-not-use-recursive-chown-or-chmod reasoning is incorrect

[Daniel Kahn Gillmor]

Hi Stephen--

On Thu 2019-08-29 23:18:53 +0200, Stephen Kitt wrote:

> Thanks for taking an interest in this, I’ve often wondered if I’d got my
> analysis right...

thanks for taking another look at this with me.

> But all this happens inside $tempdir, which is root:root 700. If anyone can
> race there, or read files, we’ve lost already, haven’t we? And if they can’t,
> then we’re safe, at least until we copy the files elsewhere — and I think at
> this point we’re sure the files can only match the contents of the archives we
> unpack.

ok, that's certainly an improved argument for why it doesn't matter as
much, compared to the lintian-override :)

But from a defense in depth scenario, it'd still be much nicer to not
worry about this stuff happening at all :/  For example, what if there
is a bug in the network fetching or archive extraction tools?

> The scenario I was thinking of when I wrote my comment was the issue of
> suid/sgid binaries, since those could be stored in the archives we extract.
> But even then, I don’t think there would be a way of exploiting them even if
> the chown happened before the chmods, and in any case the archives are
> extracted without preserving permissions...

Is there a reason that the archives need to be fetched and extracted as
the superuser in the first place?  if all that work was done by a
non-privileged user, then there'd be no chance of the files being
suid/sgid even if there was a heinous bug in the extractor, because the
kernel wouldn't let that happen.

Then you could ignore the chown, and just ensure that the files are
world-readable in the normal way.

 --dkg


signature.asc
Description: PGP signature

Bug#936094: python3: Installing vdirsyncer or pygobject in a virtual environment results in a linker error

[Nicolas Évrard]

Package: python3
Version: 3.7.3-1
Severity: important

Dear Maintainer,

I noticed the same error while installing in a pristine virtual
environment the python packages 'vdirsyncer' or 'pygobject' (I made a
bug report to gnome for the later in case it matters:
https://gitlab.gnome.org/GNOME/pygobject/issues/358)

Here's the final line of the vdirsyncer installation:

ImportError: 
/tmp/easy_install-e4zaxt6y/vdirsyncer-0.17.0a3/.eggs/cffi-1.12.3-py3.7-linux-x86_64.egg/_cffi_backend.cpython-37m-x86_64-linux-gnu.so:
 failed to map segment from shared object

as you can see from gnome's bug report it's the same issue with
pygobject. It made me realize that the issue might not be with the
packages but with the python shipped with sid. Thus I tried on a
buster box I have and vdirsyncer installs successfully.

I wonder if this bug is related to #919134 (although I am not sure as
this bug was found before the buster release).

Regards (and thanks for all the work you've done this far ;) as I
never had the opportunity to thank you since I never had an issue
before),

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

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

Versions of packages python3 depends on:
ii  libpython3-stdlib  3.7.3-1
ii  python3-minimal3.7.3-1
ii  python3.7  3.7.4-3

python3 recommends no packages.

Versions of packages python3 suggests:
pn  python3-doc   
ii  python3-tk3.7.4-3
ii  python3-venv  3.7.3-1

-- no debconf information

Bug#936093: RM: libgeotiff-dfsg -- ROM; Obsolete, replaced by libgeotiff

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal

Please remove libgeotiff-dfsg from the archive, it's obsolete with the
transition to PROJ 6 and replaced by libgeotiff.

Kind Regards,

Bas

Bug#935223: kcollectd removal

[Antonio Russo]

Hello,

You recently requested the removal of kcollectd from unstable due to the use of
qt4. I've ported this to qt5, taken over upstream, and offered to adopt the 
package [1].

Would it be possible for you to comment on the suitability of the packaging for
inclusion in Debian? Since I've received no offers to sponsor a package upload,
and no comments on the packaging beyond the (now corrected) lintian reports,
I don't know how I can proceed.

Thank you for your time,
Antonio Russo

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935485

Bug#936092: gcc-9 patches apply even less

[Helmut Grohne]

Source: cross-gcc
Version: 231
Severity: serious
Tags: patch
Control: block -1 by 928035

On top of #928035, there is another change in gcc-9 that makes the gcc-9
patches no longer apply. The attached patch resolves the relevant hunk.
Please consider uploading a new version that works with the current
gcc-9.

Helmut
--- a/gcc-9/0004-added-multi-arch-specific-install-location-patch.patch
+++ b/gcc-9/0004-added-multi-arch-specific-install-location-patch.patch
@@ -368,9 +388,9 @@
 +  else
 +debian_patches += cross-install-location
 +  endif
- endif
- 
- ifeq ($(DEB_TARGET_ARCH_OS),hurd)
+   ifeq ($(with_m2),yes)
+ debian_patches += cross-install-location-gm2
+   endif
 -- 
 2.17.1

Bug#927135: src:rekall: Please update to python3 version

[Sandro Tosi]

control: block -1 by 936091

On Mon, 26 Aug 2019 11:02:23 +0200 Raphael Hertzog  wrote:
> Hi,
>
> On Sun, 25 Aug 2019, Scott Kitterman wrote:
> > If you have lost interest in the package, please let me know so I can ask to
> > have it removed.
>
> Don't remove rekall please. There's a new upstream release with Python 3
> support. We will get to it eventually.

I started having a look at packaging the new upstream release of
rekall, to support python 3 (mostly because rekall is a r-dep of some
of the packages i maintain). For now it looks like the most immediate
need is to get aff4 ported to python3, as it's a strong dependency of
rekall, so i filed #936091

Regards,
Sandro

Bug#936091: aff4: please package new upstream release (needed by rekall), port to python3

[Sandro Tosi]

Source: aff4
Severity: serious

Hello,
please package the new upstream release for aff4; according to
https://github.com/google/aff4 the project has been split in the Python and C
parts separately.

aff4 (specificly `'pyaff4 >= 0.26, < 0.30'`) is required by the new upstream
release of rekall.  Additionally, since we're trying to port rekall to python 3,
aff4 will need to provide python 3 bindings too.  Since rekall is the only
reverse-dependency of pyhton-aff4, you can as well drop the python2 bindings at
the same time, since we're trying to remove python 2 from bullseye,
https://wiki.debian.org/Python/2Removal .

The severity is set to serious because rekall requires this package to be
packaged, and it's already RC-buggy.

Regards,
Sandro

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

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

Bug#811180: etckeeper: Please port it to python 3

[Daniel Kahn Gillmor]

On Mon 2016-01-25 18:20:11 +, Jelmer Vernooij wrote:

> The bzr bits have to be python2 because bzr is python 2 only at the moment.
>
> Bzr is optional though.

fwiw, i'd much rather see etckeeper shipping with python3 with bzr
disabled at this point.  or maybe whatever folks need it to work with
bzr can fix that part?

 --dkg


signature.asc
Description: PGP signature

Bug#913639: unclutter: change upstream to unclutter-xfixes

[Sean Whitton]

Hello,

On Tue 13 Nov 2018 at 12:04PM +01, nfb wrote:

> since unclutter seems very old (so old that it doesn't even have an
> Homepage, but it must be referred to by a web.archive snapshot among
> the other things), would you mind switching upstream location to
> unclutter-xfixes[0] for an hopefully actively maintained alternative
> which also seems to solve many known bugs with modern WMs?
>
> By the way, this is a rewrite of the program, so maybe a new package
> with a different name is more appropriate?

I'm currently trying out unclutter-xfixes as I'm hitting the various
unclutter bugs.  Although unclutter-xfixes is a drop-in replacement, it
does have some behavioural differences which might make people prefer
the old unclutter.  For example, xtrlock's padlock cursor gets hidden by
unclutter-xfixes but not by old unclutter.

So, I think that maybe unclutter and unclutter-xfixes should be separate
source packages that register with the alternatives system?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#932777: scotch: segfault in test_scotch_graph_order bump_b1.grf

[Drew Parsons]

Source: scotch
Followup-For: Bug #932777
Control: retitle -1 scotch: 6.0.8 FTBFS: segfault in test_scotch_graph_order 
bump_b1.grf
Control: forwarded -1 
https://gforge.inria.fr/tracker/?func=detail_id=248=1079=21771

Scotch 6.0.8 fixed test_libmetis (upstream bug #21768).

But bump_b1.grf causes problems elsewhere

$ LD_LIBRARY_PATH=../../lib/ ./test_scotch_graph_order data/bump_b1.grf
Segmentation fault

New bug reported upstream #21771.


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#936090: xfce4-settings: scrollbar disappears, doesn't want to come back

[Mike Kupfer]

Package: xfce4-settings
Version: 4.14.1-1
Severity: normal

Dear Maintainer,

Suppose I go to the Appearance section, which has a nice long list of
styles.

If I drag the scrollbar thumb and then pause while holding the (left)
mouse button down, the scrollbar disappears after about 3 seconds.
That's fine.  But if I release the mouse button and start moving the
mouse around in the list of styles, I'd like for the scrollbar to
reappear.  It doesn't.  Moving the input focus somewhere else and then
back to Appearance doesn't help.  I have to click in the window (not
necessarily in the style list) for the scrollbar to come back.

I've tried several different widget styles, and the problem seems
independent of the style.

I can't reproduce the problem with xfce4-terminal: the scrollbar stays
visible as long as I hold the mouse button.  I can reproduce the
problem with xfce4-settings-editor, but only when run from the
settings manager.  If I start xfce4-settings-editor directly from a
terminal emulator, the scrollbar stays visible as long as I hold the
mouse button.

I do have some GTK settings related to scrollbars.  I don't know if
they're relevant.

In settings.ini:

  gtk-primary-button-warps-slider=0

In gtk-3.0/gtk.css:

  .scrollbar {
  -GtkScrollbar-has-backward-stepper: 1;
  -GtkScrollbar-has-forward-stepper: 1;
  }
  
  scrollbar {
-GtkScrollbar-has-backward-stepper: true;
-GtkScrollbar-has-forward-stepper: true;
  }



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

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

Versions of packages xfce4-settings depends on:
ii  libatk1.0-0  2.33.3+really2.32.0-4
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libcolord2   1.4.3-4
ii  libexo-2-0   0.12.8-1
ii  libfontconfig1   2.13.1-2+b1
ii  libgarcon-1-00.6.4-1
ii  libgarcon-common 0.6.4-1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.60.6-2
ii  libgtk-3-0   3.24.10-1
ii  libnotify4   0.7.8-1
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libupower-glib3  0.99.10-1
ii  libx11-6 2:1.6.7-1
ii  libxcursor1  1:1.2.0-2
ii  libxfce4ui-2-0   4.14.1-1+b1
ii  libxfce4util74.14.0-1
ii  libxfconf-0-34.14.1-1
ii  libxi6   2:1.7.9-1
ii  libxklavier165.4-4
ii  libxrandr2   2:1.5.1-1
ii  xfconf   4.14.1-1

Versions of packages xfce4-settings recommends:
pn  colord 
ii  x11-utils  7.7+4
pn  xiccd  

xfce4-settings suggests no packages.

-- no debconf information

Bug#931311: libsixel: Multiple security issues (CVE-2018-19756 CVE-2018-19757 CVE-2018-19759 CVE-2018-19761 CVE-2018-19762 CVE-2018-19763)

[Takatsugu Nokubi]

On Wed, 7 Aug 2019 10:05:36 +0900 Takatsugu Nokubi  wrote:
> Finaly, I made these fix patches, but not uploaded yet.
> https://salsa.debian.org/debian/libsixel/tree/master/debian/patches

At least, all bugs reported as important are fixed now.

I'm working to fix patches for stretch:
https://salsa.debian.org/debian/libsixel/tree/debian-stretch/debian/patches

Bug#936088: Acknowledgement (libmurmurhash autopkg tests fail)

[Matthias Klose]

Control: tags -1 + patch

patch at
http://launchpadlibrarian.net/439524642/libmurmurhash_1.5-1_1.5-1ubuntu1.diff.gz

Bug#936080: iputils-arping: arping -D : false positives

[Noah Meyerhans]

On Fri, Aug 30, 2019 at 12:01:32AM +0200, Pierre Donis wrote:
> I'm using dracut to build the initramfs to boot on an ISCSI root disk.
> Line 125 of /usr/lib/dracut/modules.d/40network/ifup.sh :
> 
>  if ! arping -f -q -D -c 2 -I $netif $ip ; then
>   warn "Duplicate address detected for $ip for interface $netif."
>   return 1
>  fi
> 
> Inirtd created with iputils-arping_20190709-1_amd64.deb, booting fails:
> # arping -f -q -D -c 2 -I br0 172.16.1.100 ; echo $?
> 1
> 
> Inirtd created with iputils-arping_20180629-2_amd64.deb, booting succeeds:
> # arping -f -q -D -c 2 -I br0 172.16.1.100 ; echo $?
> 0

This sounds a lot like https://github.com/iputils/iputils/issues/209

Are you able to build an arping binary locally that includes the fix,
for testing and confirmation? If not, I should be able to provide you
with a package to test.

Bug#936089: nemo: Missing gir1.2-nemo-3.0 dependency

[Norbert Preining]

reassign 936089 cinnamon
tags 936089 + pending
thanks

Hi Jethro,

On Fri, 30 Aug 2019, Jethro Nederhof wrote:
> ValueError: Namespace Nemo not available
> 
> Manually installing the gir1.2-nemo-3.0 as per 
> https://github.com/linuxmint/cinnamon/issues/8203#issuecomment-449746265
> package fixes the error and launches all Settings applications correctly.

Thanks for the report. I reassigned the bug to 
cinnamon
which provides the cinnamon-settings program, and added the respective
dependency in our git repository.

Thanks again

Norbert

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

Bug#936089: nemo: Missing gir1.2-nemo-3.0 dependency

[Jethro Nederhof]

Package: nemo
Version: 4.0.6-1
Severity: normal

Dear Maintainer,

On upgrade to Cinnamon 4, settings no longer launch properly.
Trying to run cinnamon-settings from a terminal results in the Python error:

ValueError: Namespace Nemo not available

Manually installing the gir1.2-nemo-3.0 as per 
https://github.com/linuxmint/cinnamon/issues/8203#issuecomment-449746265
package fixes the error and launches all Settings applications correctly.
Nemo should probably depend on this package so it is automatically installed 
and Cinnamon works correctly.

Not sure if this is a bug for Cinnamon or Nemo, but since the dependency 
contains 'nemo' I am reporting it here.

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

Kernel: Linux 5.2.11-towo.1-siduction-amd64 (SMP w/8 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nemo depends on:
ii  cinnamon-desktop-data  4.0.1-1
ii  desktop-file-utils 0.24-1
ii  gsettings-desktop-schemas  3.28.1-1
ii  gvfs   1.38.1-5
ii  libatk1.0-02.33.3+really2.32.0-4
ii  libc6  2.28-10
ii  libcairo-gobject2  1.16.0-4
ii  libcairo2  1.16.0-4
ii  libcinnamon-desktop4   4.0.1-1
ii  libexempi8 2.5.1-1
ii  libexif12  0.6.21-5.1
ii  libgail-3-03.24.10-1
ii  libgdk-pixbuf2.0-0 2.38.1+dfsg-1
ii  libglib2.0-0   2.60.6-2
ii  libglib2.0-data2.60.6-2
ii  libgtk-3-0 3.24.10-1
ii  libnemo-extension1 4.0.6-1
ii  libnotify4 0.7.8-1
ii  libpango-1.0-0 1.42.4-7
ii  libpangocairo-1.0-01.42.4-7
ii  libselinux12.9-2+b2
ii  libx11-6   2:1.6.7-1
ii  libxapp1   1.4.9-1
ii  libxml22.9.4+dfsg1-7+b3
ii  nemo-data  4.0.6-1
ii  shared-mime-info   1.10-1

Versions of packages nemo recommends:
ii  cinnamon-l10n4.0.2-1
ii  gvfs-backends1.38.1-5
ii  gvfs-fuse1.38.1-5
ii  librsvg2-common  2.44.14-1
ii  nemo-fileroller  4.0.0-1

Versions of packages nemo suggests:
ii  eog   3.28.4-2+b1
ii  evince [pdf-viewer]   3.30.2-3
ii  mpg321 [mp3-decoder]  0.3.2-3
ii  totem 3.32.0-2
ii  xdg-user-dirs 0.17-2

-- no debconf information

Bug#925129: ffcall failed to build mips64 R6 version due to Illegal instruction

[Bruno Haible]

Hi,

In  you reported
a problem with the use of the 'jr $25' instruction on MIPS32R6. Thanks for
this report.

I've changed the code to use the new opcode (previously written as
'jal $0,$25') always, since this opcode is supported since the earliest
MIPS ISAs.

https://git.savannah.gnu.org/gitweb/?p=libffcall.git;a=commitdiff;h=5f801d3d01a079c49c1e84b02ab5a153efd5c428

Bruno

Bug#936088: libmurmurhash autopkg tests fail

[Matthias Klose]

Package: src:libmurmurhash
Version: 1.5-1
Severity: serious
Tags: sid bullseye

Apparently the package needs a rebuild at least, some tests don't work anymore.

autopkgtest [22:47:58]: test run-unit-test: [---
/usr/bin/ld: /tmp/ccNY3NFj.o: in function `main':
mmh.c:(.text.startup+0xe2): undefined reference to `lmmh_x86_32'
/usr/bin/ld: mmh.c:(.text.startup+0x11a): undefined reference to `lmmh_x86_128'
/usr/bin/ld: mmh.c:(.text.startup+0x159): undefined reference to `lmmh_x64_128'
collect2: error: ld returned 1 exit status

CFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2 -O2 -fstack-protector-strong -Wformat 
-Werror=format-security"

gcc ${CFLAGS} -o mmh -lmurmurhash mmh.c
gcc ${CFLAGS} -o mmh_old -lmurmurhash mmh_old.c

- libraries have to appear last on the command line

- it's questionable to hard code the hardening flags.
  you should ask dpkg-buildflags about that, and add
  dpkg-dev to the test dependencies.

Bug#935958: runit: Tools to help generating runscripts

[Lorenzo Puliti]

Package: runit
Version: 2.1.2-33rescan1
Followup-For: Bug #935958

>  * please make scripts return != 0 in case of failure. `./fetch foo'
>exiting with 0 is very confusing.

I have updated the code[1], all script now return nonzero in case of failure.
Also there is some improvement on the hackit script.


> May I suggest using git? `debcheckout`, if maintainer uses Salsa, or
> `gbp import-dsc apt:foo` otherwise. Extra points for making Salsa merge
> request in addition to BTS bug.

Thanks for the suggestion, I will add this in version 0.3, WIP code will
be in [2]. Also I will focus on improving the converter.


> * you seem to invent yet-another templating engine with those #dep1#
>   tokens. I suggest you to re-use something already established, like
>   mustache or jinja2. bin:ionit may be interested.

Didn't know about mustache, jinja2 and ionit. It's a lot of new things to learn,
and I don't have the time now, maybe in the future..

> But before patch can be submitted to maintainer, automatic testing is
> must. I suggest salsa.debian.org/kaction/daemons.

Is there any instruction on how to use it?


>> Do I need to 'set -e' in run script, or it's inherited from invoke-run?

> No, it is not. Do you think invoke-run should?

Mmm, I don't have an strong opinion on that, I think it's fine as it is now.


> * please do not print "Starting $NAME". It goes to log, quite
>   pointless and may confuse scripts/tools that want to analyze log.

I know it goes to log, that was exactly my idea but i didn't thought about
scripts that want to analyze logs.
Runit is absolutely mute and in some case it's hard for me to understand
what is wrong with a service. For example, if in the log there is no
`Starting NAME` message i know something is wrong with the run file;
if i see a stream of `starting NAME Stopping NAME` i know there is 
some permanent failure condition. I'm not sure I will be able to help in
solving bug that users will send about runit services without those
markers. Maybe I can change the message into something less confusing
like `runsv: starting NAME` and `runsv: NAME stopped` ?


> PS. You know that I already got runscript into src:tor and src:acpid?

yes I've noticed that :) 
I've send a couple of patches too and have few others
ready (but those need the fix for #934173).
Maybe you can help with Anacron? It's QA maintained.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934231

[1] https://salsa.debian.org/Lorenzo.ru.g-guest/runit-tools/tree/nopackage
[2] https://salsa.debian.org/Lorenzo.ru.g-guest/runit-tools/tree/next-0.3

Thanks,
Lorenzo

Bug#936073: please have libffi6-dbgsym debug package

[Matthias Klose]

On 29.08.19 20:46, shirish शिरीष wrote:

It would be nice to have libffi6-dbgsym instead of libffi6-dbg as lot
of archive has moved to use -dbgsym as they give more info. while
debugging.


please could you quantify "as they give more info. while debugging"?

Bug#752604: xbmc: better logging with timestamps

[Olly Betts]

Control: tags -1 + fixed-upstream
Control: forwarded https://github.com/xbmc/xbmc/pull/15457

On Thu, Jun 26, 2014 at 10:42:01PM +0200, Bálint Réczey wrote:
> OK, reopening it. I'm not sure if adding the date would be accepted by
> upstream since there may plenty of scripts expecting only the time of
> day timestamp.

This was fixed upstream in version 18.1:

https://github.com/xbmc/xbmc/commit/dc013552b0710b60146bf5693938dbb22bbff3dd

Cheers,
Olly

Bug#936043: ITP: gitbatch -- Manage git repositories in one place

[Ben Hutchings]

On Thu, 2019-08-29 at 13:28 +0200, Dawid Dziurla wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Dawid Dziurla 
> 
> * Package name: gitbatch
>   Version : 0.5.0-1
>   Upstream Author : Ibrahim Serdar Acikgoz
> * URL : https://github.com/isacikgoz/gitbatch
> * License : Expat
>   Programming Lang: Go
>   Description : Manage git repositories in one place
> 
>  Managing multiple git repositories is easier than ever. Often one would end
>  up working on many directories and manually pulling updates etc. To make
>  this routine faster, gitbatch was created, a simple tool to handle this job.
>  Although the focus is batch jobs, one can still do de facto micro management 
> of
>  git repositories (e.g add/reset, stash, commit etc.)
> 
> Useful tool for managing multiple git repositiories at once.
> Does not need additional dependencies, only those already in archive.

We already have "mr", which can do this for git and several other
version control systems.  Does gitbatch offer anything new?

Ben.

-- 
Ben Hutchings
Experience is what causes a person to make new mistakes
instead of old ones.



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

Bug#936086: RFS: vtun/3.0.4-1 [ITA] -- virtual tunnel over TCP/IP networks

[Rodrigo Carvalho]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: vtun
   Version : 3.0.4-1
   Upstream Author : Maxim Krasnyansky 
 * URL : http://vtun.sourceforge.net/
 * License : GPL-2+
 * Vcs : None
   Section : net

It builds those binary packages:

  vtun - virtual tunnel over TCP/IP networks

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/v/vtun/vtun_3.0.4-1.dsc

Changes since the last upload:

   * New upstream release.
   * New maintainer (Closes: #812758).
   * debian/rules: use of dpkg-buildflags instead of obsolete finding for
 noopt in DEB_BUILD_OPTIONS.
   * No stripping on building package. Patch by Helmut Grohne.
 (Closes: #883530).

Regards,

--
  Rodrigo Carvalho

Bug#911821: Add development packages

[Bastian Germann]

Please find a packaged development package in
https://salsa.debian.org/debian/mtd-utils/merge_requests/1

Bug#936085: mpd: Can not disable mpd.service and mpd.socket as a user.

[Michel]

Package: mpd
Version: 0.21.13-1
Severity: normal

Dear Maintainer,

Tried to disable mpd.service and mpd.socket, but can not disable them.


mpd.service and mpd.socket, are currently enabled:

$ systemctl --user is-enabled mpd.service
enabled


$ systemctl --user is-enabled mpd.socket
enabled


Tried disabling mpd.service and mpd.socket with:

$ systemctl --user disable mpd.service


$ systemctl --user disable mpd.socket
Removed /home/michel/.config/systemd/user/sockets.target.wants/mpd.socket.


As we an see, mpd.service and mpd.socket do not get disabled:

$ systemctl --user is-enabled mpd.service
enabled

$ systemctl --user is-enabled mpd.socket
enabled


Also checked after a reboot, mpd.service and mpd.socket are still
started at login. Even though we tried disabling them earlier:

$ systemctl --user status mpd.service
● mpd.service - Music Player Daemon
   Loaded: loaded (/usr/lib/systemd/user/mpd.service; enabled; vendor preset: 
enabled)
   Active: active (running) since Mon 2019-08-26 18:51:19 EDT; 4min 52s ago
 Docs: man:mpd(1)
   man:mpd.conf(5)
   file:///usr/share/doc/mpd/html/user.html
 Main PID: 1975 (mpd)
   CGroup: /user.slice/user-1000.slice/user@1000.service/mpd.service
   └─1975 /usr/bin/mpd --no-daemon


$ systemctl --user status mpd.socket
● mpd.socket
   Loaded: loaded (/usr/lib/systemd/user/mpd.socket; enabled; vendor preset: 
enabled)
   Active: active (running) since Mon 2019-08-26 18:51:09 EDT; 5min ago
   Listen: /run/user/1000/mpd/socket (Stream)
   [::]:6600 (Stream)
   CGroup: /user.slice/user-1000.slice/user@1000.service/mpd.socket


Thank You


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

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

Versions of packages mpd depends on:
ii  adduser   3.118
ii  init-system-helpers   1.57
ii  libadplug-2.2.1-0v5   2.2.1+dfsg3-1+b1
ii  libao41.2.2+20180113-1+b1
ii  libasound21.1.8-1
ii  libaudiofile1 0.3.6-5
ii  libavahi-client3  0.7-4+b1
ii  libavahi-common3  0.7-4+b1
ii  libavcodec58  7:4.1.4-1+b2
ii  libavformat58 7:4.1.4-1+b2
ii  libavutil56   7:4.1.4-1+b2
ii  libbz2-1.01.0.6-9.2
ii  libc6 2.28-10
ii  libcdio-cdda2 10.2+2.0.0-1+b1
ii  libcdio-paranoia2 10.2+2.0.0-1+b1
ii  libcdio18 2.0.0-2
ii  libcurl3-gnutls   7.65.3-1
ii  libdbus-1-3   1.12.16-1
ii  libexpat1 2.2.7-1
ii  libfaad2  2.8.8-3
ii  libflac8  1.3.3-1
ii  libfluidsynth11.1.11-4
ii  libgcc1   1:9.2.1-4
ii  libgcrypt20   1.8.4-5
ii  libgme0   0.6.2-1+b1
ii  libicu63  63.2-2
ii  libid3tag00.15.1b-14
ii  libiso9660-11 2.0.0-2
ii  libixml10 1:1.8.4-2
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2+b1
ii  libjs-sphinxdoc   1.8.5-3
ii  libmad0   0.15.1b-10
ii  libmikmod33.3.11.1-4
ii  libmms0   0.6.4-3
ii  libmodplug1   1:0.8.9.0-2
ii  libmp3lame0   3.100-2+b1
ii  libmpcdec62:0.1~r495-1+b2
ii  libmpdclient2 2.16-1+b1
ii  libmpg123-0   1.25.11-1
ii  libnfs12  3.0.0-2
ii  libogg0   1.3.2-1+b1
ii  libopenal11:1.19.1-1+b1
ii  libopus0  1.3-1+b1
ii  libpcre3  2:8.39-12+b1
ii  libpulse0 12.99.2-1
ii  libsamplerate00.1.9-2
ii  libshout3 2.4.1-2
ii  libsidplayfp4 1.8.8-1+b1
ii  libsmbclient  2:4.9.11+dfsg-1
ii  libsndfile1   1.0.28-6
ii  libsoxr0  0.1.2-3
ii  libsqlite3-0  3.29.0-2
ii  libstdc++69.2.1-4
ii  libsystemd0   242-4
ii  libupnp13 1:1.8.4-2
ii  libvorbis0a   1.3.6-2
ii  libvorbisenc2 1.3.6-2
ii  libwavpack1   5.1.0-7
ii  libwildmidi2   

Bug#936084: mpd: An mpd client can not connect to mpd on port 6600, when mpd.socket is active as a user.

[Michel]

Package: mpd
Version: 0.21.13-1
Severity: normal

Dear Maintainer,

After upgrading mpd from 0.21.5-3 to 0.21.13-1. An mpd client could not
connect to mpd on port 6600. Checked to make sure that mpd was still
disabled system wide:

# systemctl is-enabled mpd.service
disabled

# systemctl is-enabled mpd.socket
disabled

As mpd is started at loggin in time with:

[ ! -s ~/.mpd/pid ] && mpd --verbose


Here are the errors shown, by mpd:

Aug 24 16:02 : exception: Failed to bind to '127.0.0.1:6600'
Aug 24 16:02 : exception: nested: Failed to bind socket: Address already in use


Then ran:

# netstat -anptuv | grep :6600
tcp6   0  0 :::6600 :::*LISTEN  
1924/systemd


# lsof | grep 6600
systemd1924  michel   29u IPv6  42105   
0t0TCP *:6600 (LISTEN)


Changed the port in ~/.mpd/mpd.conf from 6600 to 6601 to test if could
connect to mpd. Afterwords an mpd client could connect to mpd on port
6601.

With some help from #mpd, Rasi suggested grepping for 6600 in the
.service files:

$ grep -R 6600 /usr/lib/systemd
/usr/lib/systemd/user/mpd.socket:ListenStream=6600


$ grep -R 6600 /etc/systemd
/etc/systemd/user/sockets.target.wants/mpd.socket:ListenStream=6600


With the information above, then trying:

$ systemctl --user disable --now mpd.socket

That tried to disable[Will file another bug report for this.] mpd.socket
and did stop mpd.socket.


Then killed the mpd process and started mpd.service:

$ mpd --kill

$ systemctl --user start mpd.service

A restart of mpd.service also works:

$ systemctl --user restart mpd.service

After either of the above was able to connect to mpd with an
mpd client on port 6600.


Below are the things that where tried to try to figure out what was
going on. 


*NOTE: The following where done without rebooting.

Showing that an mpd client can not connect to mpd on port 6600, when
mpd.socket is active:  


$ systemctl --user status mpd.service
● mpd.service - Music Player Daemon
   Loaded: loaded (/usr/lib/systemd/user/mpd.service; enabled; vendor preset: 
enabled)
   Active: inactive (dead) since Mon 2019-08-26 13:02:40 EDT; 23s ago
 Docs: man:mpd(1)
   man:mpd.conf(5)
   file:///usr/share/doc/mpd/html/user.html
  Process: 3995 ExecStart=/usr/bin/mpd --no-daemon (code=exited, 
status=0/SUCCESS)
 Main PID: 3995 (code=exited, status=0/SUCCESS)


$ systemctl --user status mpd.socket
● mpd.socket
   Loaded: loaded (/usr/lib/systemd/user/mpd.socket; enabled; vendor preset: 
enabled)
   Active: inactive (dead) since Mon 2019-08-26 13:02:47 EDT; 20s ago
   Listen: /run/user/1000/mpd/socket (Stream)
   [::]:6600 (Stream)


We can see that mpd.service and mpd.socket are inactive above. Let's only start
mpd.socket:

$ systemctl --user start mpd.socket


$ systemctl --user status mpd.socket
● mpd.socket
   Loaded: loaded (/usr/lib/systemd/user/mpd.socket; enabled; vendor preset: 
enabled)
   Active: active (listening) since Mon 2019-08-26 13:04:56 EDT; 6s ago
   Listen: /run/user/1000/mpd/socket (Stream)
   [::]:6600 (Stream)
   CGroup: /user.slice/user-1000.slice/user@1000.service/mpd.socket


$ systemctl --user status mpd.service
● mpd.service - Music Player Daemon
   Loaded: loaded (/usr/lib/systemd/user/mpd.service; enabled; vendor preset: 
enabled)
   Active: inactive (dead) since Mon 2019-08-26 13:02:40 EDT; 2min 41s ago
 Docs: man:mpd(1)
   man:mpd.conf(5)
   file:///usr/share/doc/mpd/html/user.html
  Process: 3995 ExecStart=/usr/bin/mpd --no-daemon (code=exited, 
status=0/SUCCESS)
 Main PID: 3995 (code=exited, status=0/SUCCESS)


$ netstat -anptuv | grep :6600
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp6   0  0 :::6600 :::*LISTEN  
1991/systemd


$ ncmpcpp
ncmpcpp: Connection refused


Let's now start mpd.service:

$ systemctl --user start mpd.service


$ systemctl --user status mpd.service
● mpd.service - Music Player Daemon
   Loaded: loaded (/usr/lib/systemd/user/mpd.service; enabled; vendor preset: 
enabled)
   Active: active (running) since Mon 2019-08-26 13:06:45 EDT; 6s ago
 Docs: man:mpd(1)
   man:mpd.conf(5)
   file:///usr/share/doc/mpd/html/user.html
 Main PID: 22901 (mpd)
   CGroup: /user.slice/user-1000.slice/user@1000.service/mpd.service
   └─22901 /usr/bin/mpd --no-daemon


$ systemctl --user status mpd.socket
● mpd.socket
   Loaded: loaded (/usr/lib/systemd/user/mpd.socket; enabled; vendor preset: 
enabled)
   Active: active (running) since Mon 2019-08-26 13:04:56 EDT; 2min 0s ago
   Listen: /run/user/1000/mpd/socket (Stream)
   [::]:6600 (Stream)
   CGroup: /user.slice/user-1000.slice/user@1000.service/mpd.socket


$ netstat -anptuv | grep :6600
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root 

Bug#933576: debhelper: dh_installman is terribly slow

[Colin Watson]

On Wed, Aug 21, 2019 at 05:51:00PM +, Niels Thykier wrote:
> Colin Watson:
> > Does this make sense to you?  If so, do you have any opinions on the
> > interface?  (I'm open to it being a new program rather than having to
> > stuff even more complexity into man's command-line interface, which
> > would also make it easy to detect whether the new interface is
> > available.)
> 
> So basically, I envision something like any of the 4 following usage
> patterns (as a starting point):
[...]

Thanks for the input.  Something along these lines should be doable.  I
would be inclined to just take multiple file names and rely on xargs
rather than bothering with "--null --files-from -".

--suffix would, I think, want to strip off any compression extension
before appending the suffix.

> In all cases, I assume that compression is retained (e.g. if the file
> was gzip compressed, then the output file should be as well.  This is an
> assumption in the current dh_installman as well)

This is a bit fiddly: man-db currently knows how to decompress files but
never needs to compress them.  Are you sure this is necessary?  Firstly,
dh_compress is normally run after dh_installman; secondly, as far as I
can see this is *not* in fact an assumption in the current
dh_installman, and indeed it takes care to remove compressed pages
before renaming the (uncompressed) output files over the input files.

> The tool could be man itself with a special flag.  Though I can
> appreciate your comment about man's command-line interface being
> complex, so it might indeed be better to do it as a separate tool for
> that reason alone.

I think I might actually extend manconv instead; it already does a
certain amount of what you need here and just needs autodetection of
input encoding and the multiple-files interface.

manconv is currently installed in man-db's libexecdir, but I could
easily move it onto $PATH.  Since it isn't currently on $PATH, that
would provide you with an easy way to test whether this new interface is
supported (I could also add "manconv --has-bulk" or something, but I
don't think it's necessary in this case).

-- 
Colin Watson   [cjwat...@debian.org]

Bug#936083: RM: gdm3 [s390x] -- NBS; uninstallable

[Simon McVittie]

Package: ftp.debian.org
Severity: normal

Please remove the s390x *binary* package gdm3 (only that one, not the
rest of src:gdm3) from unstable and experimental. It is uninstallable
on s390x due to gnome-shell not working (it fails build-time tests),
and in any case a desktop environment that requires a GPU is not really
useful or appropriate for a CPU architecture that only exists in a
mainframe form-factor.

I've modified the gdm3 source package in unstable to skip building
gdm3.deb on s390x. Note that the rest of the binaries from src:gdm3,
notably libgdm1, should remain available on s390x to keep gnome-panel
installable without s390x-specific hacks in gnome-panel, so that
task-gnome-desktop:s390x can depend on gnome-session-flashback, so that
uninstallable task packages won't break testing migration.

The corresponding change in experimental is not in the archive yet, but
is queued in gnome-team git for the next upload.

I tried

dak rm  --rdep-check --no-action --suite=unstable --architecture=s390x 
--partial --binary gdm3
dak rm  --rdep-check --no-action --suite=experimental --architecture=s390x 
--partial --binary gdm3

which says there are no reverse-dependencies.

Thanks,
smcv

Bug#936082: grub-efi-amd64-signed: Add probe module to available modules

[adrian15 adrian15]

Package: grub-efi-amd64-bin
Version: 1+2.02+dfsg1+20
Severity: wishlist

Dear Maintainer,

  I'm trying to use Debian-signed secure boot grub binaries
with Super Grub2 Disk scripts.
  Many of the Super Grub2 Disk scripts make use of the probe
command. It makes possible to identify partition uuid given
the grub partition device so that you can fed the kernel
UUID boot parametre.

  Is it possible to add the probe module and command to the
secure boot based grub (both grub-efi-amd64-signed and
grub-efi-ia32-signed packages) ?

Similar bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928628 and
its associated commit:
https://salsa.debian.org/grub-team/grub/commit/ed4a71ed6d2617e6916e7a663f9da28ee3699127
.

  Thank you very much!


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages grub-efi-amd64-signed depends on:
ii  grub-common  2.02+dfsg1-20

Versions of packages grub-efi-amd64-signed recommends:
ii  shim-signed  1.33+15+1533136590.3beb971-7

grub-efi-amd64-signed suggests no packages.

Versions of packages grub-efi-amd64-bin depends on:
ii  grub-common  2.02+dfsg1-20

Versions of packages grub-efi-amd64-bin recommends:
ii  efibootmgr  15-1

-- no debconf information

Bug#935753: FATAL:memory_linux.cc Out of memory

[Michael Gilbert]

control: tag -1 moreinfo

On Sun, Aug 25, 2019 at 4:36 PM Dan Jacobson wrote:
> Versions of packages chromium depends on:
[...]
> ii  libatk1.0-0  2.33.3+really2.33.3-1
[...]
> ii  libc62.29-0experimental1
[...]
> ii  libjpeg62-turbo  1:2.0.2-1~exp2

Could you try this again without packages from experimental?  I assume
its caused by the update to libc6 2.29?

Best wishes,
Mike

Bug#935988: buster-pu: package reportbug/7.5.3~deb10u1

[Andreas Beckmann]

Followup-For: Bug #935988
Control: retitle -1 buster-pu: package reportbug/7.5.3~deb10u1

new debdiff for rebuilding the 7.5.3 maintainer upload for buster.

Andreas
diff -Nru reportbug-7.5.2/bin/reportbug reportbug-7.5.3~deb10u1/bin/reportbug
--- reportbug-7.5.2/bin/reportbug   2019-02-01 02:57:49.0 +0100
+++ reportbug-7.5.3~deb10u1/bin/reportbug   2019-08-29 01:54:08.0 
+0200
@@ -1936,7 +1936,6 @@
 detected_addr = self.options.email or utils.get_email()[1]
 if not detected_addr:
 efail("list-cc-me option specified but email address not 
detected")
-ewrite("list-cc-me DEBUG: {}".format(detected_addr))
 listcc += [detected_addr]
 
 if not listcc and mode > MODE_STANDARD and rtype == 'debbugs' and not 
self.options.testmode and not self.options.template and self.options.ccmenu:
diff -Nru reportbug-7.5.2/debian/changelog 
reportbug-7.5.3~deb10u1/debian/changelog
--- reportbug-7.5.2/debian/changelog2019-02-01 02:57:49.0 +0100
+++ reportbug-7.5.3~deb10u1/debian/changelog2019-08-29 22:47:26.0 
+0200
@@ -1,3 +1,33 @@
+reportbug (7.5.3~deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * Re-enable submitting stretch-pu requests.
+  * Rebuild for buster.
+
+ -- Andreas Beckmann   Thu, 29 Aug 2019 22:47:26 +0200
+
+reportbug (7.5.3) unstable; urgency=medium
+
+  * debian/control
+- replace emacs* Suggests with emacs-bin-common; Closes: #925422
+- bump Standards-Version to 4.4.0 (no changes needed)
+- add sensible-utils dep, patch by Nis Martensen
+  * reportbug/debbugs.py
+- when handling ftp.d.o, dont look up package information if the package
+  doesnt exist, fixing a crash; Closes: #923631
+- fix a crash with stable version lookup, patch by Nis Martensen;
+  Closes: #935602
+  * bin/reportbug
+- remove debug code when handling list-cc-me, patch by Josh Triplett
+  * reportbug/utils.py
+- update release names, following Buster releases, patch by Nicolas
+  Braud-Santoni; Closes: #932524, #931609
+- recognize versioned Provides; patch by Nis Martensen; Closes: #934472
+  * man/reportbug.1
+- add default for --draftpath; patch by laokz
+
+ -- Sandro Tosi   Wed, 28 Aug 2019 19:54:08 -0400
+
 reportbug (7.5.2) unstable; urgency=medium
 
   * bin/reportbug
diff -Nru reportbug-7.5.2/debian/control reportbug-7.5.3~deb10u1/debian/control
--- reportbug-7.5.2/debian/control  2019-02-01 02:57:49.0 +0100
+++ reportbug-7.5.3~deb10u1/debian/control  2019-08-29 01:54:08.0 
+0200
@@ -3,7 +3,7 @@
 Priority: standard
 Maintainer: Reportbug Maintainers 
 Uploaders: Sandro Tosi 
-Standards-Version: 4.1.2
+Standards-Version: 4.4.0
 Build-Depends: debhelper (>= 10), python3, dh-python
 Build-Depends-Indep: python3-nose, python3-setuptools, python3-mock
 Vcs-Git: https://salsa.debian.org/reportbug-team/reportbug.git
@@ -12,7 +12,7 @@
 Package: reportbug
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}, apt, python3-reportbug (= 
${source:Version}), sensible-utils
-Suggests: postfix | exim4 | mail-transport-agent, gnupg | pgp, debconf-utils 
(>> 1.1.0), debsums (>= 2.0.47), file (>> 1.30), dlocate, python3-urwid, 
reportbug-gtk (= ${source:Version}), xdg-utils, emacs24-bin-common | 
emacs25-bin-common, claws-mail (>= 3.8.0)
+Suggests: postfix | exim4 | mail-transport-agent, gnupg | pgp, debconf-utils 
(>> 1.1.0), debsums (>= 2.0.47), file (>> 1.30), dlocate, python3-urwid, 
reportbug-gtk (= ${source:Version}), xdg-utils, emacs-bin-common, claws-mail 
(>= 3.8.0)
 Description: reports bugs in the Debian distribution
  reportbug is a tool designed to make the reporting of bugs in Debian
  and derived distributions relatively painless.  Its features include:
@@ -35,7 +35,7 @@
 Package: python3-reportbug
 Section: python
 Architecture: all
-Depends: ${misc:Depends}, ${python3:Depends}, apt, python3-debian, 
python3-debianbts (>= 1.13), file, python3-requests, python3-apt
+Depends: ${misc:Depends}, ${python3:Depends}, apt, python3-debian, 
python3-debianbts (>= 1.13), file, python3-requests, python3-apt, sensible-utils
 Suggests: reportbug
 Description: Python modules for interacting with bug tracking systems
  reportbug is a tool designed to make the reporting of bugs in Debian
diff -Nru reportbug-7.5.2/man/reportbug.1 
reportbug-7.5.3~deb10u1/man/reportbug.1
--- reportbug-7.5.2/man/reportbug.1 2019-02-01 02:57:49.0 +0100
+++ reportbug-7.5.3~deb10u1/man/reportbug.1 2019-08-29 01:54:08.0 
+0200
@@ -122,7 +122,7 @@
 .TP
 .B \-\-draftpath=DRAFTPATH
 Save the draft (for example, when exiting and saving the report
-without reporting it) into \fIDRAFTPATH\fP directory.
+without reporting it) into \fIDRAFTPATH\fP directory(default /tmp).
 .TP
 .B \-e EDITOR, \-\-editor=EDITOR
 Specify the editor to use, overriding any \fBEDITOR\fP or \fBVISUAL\fP
diff -Nru reportbug-7.5.2/reportbug/__init__.py 

Bug#933723: Bug#936003: libsbuild-perl: always cleans apt cache even if "$apt_clean = 0;" is in .sbuildrc

[Alexis Murzeau]

Hi,

Le 29/08/2019 à 00:12, Johannes Schauer a écrit :
>
> Ah indeed -- please go ahead!
>

Thanks ! :)

I've made a git patch (see attached file) to be applied on master of
sbuild (tell me if I should make a Debian package patch (in
debian/patches) instead :) ).

It adds a new option "$apt_keep_downloaded_packages" to be used in
sbuild.conf, defaulting to the existing behavior.

I've tested these cases:
- $apt_keep_downloaded_packages is not set
- $apt_keep_downloaded_packages is set to 1
- $apt_keep_downloaded_packages is set to 0

And the result is as I expect it, downloaded packages are kept in the
apt cache only when $apt_keep_downloaded_packages is set to 1, else they
are removed from the cache after installation as in the existing behavior.

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F
From 8dd69fe5fb045d15a88b8822ed23d4a36b13662f Mon Sep 17 00:00:00 2001
From: Alexis Murzeau 
Date: Thu, 29 Aug 2019 23:43:13 +0200
Subject: [PATCH] Add configuration option to keep downloaded packages by APT
 (Closes: #933723)

sbuild was always setting APT::Keep-Downloaded-Packages to false which
caused downloaded packages to be always deleted from the APT cache after
installation.
This prevented to take advantage of using a persistent package cache to
avoid downloading packages on every sbuild invocation.

The added option "apt_keep_downloaded_packages" is 0 by default, which
cause sbuild to have the same behavior as before, that is setting
APT::Keep-Downloaded-Packages to false.
---
 lib/Sbuild/Conf.pm | 7 +++
 lib/Sbuild/ResolverBase.pm | 9 +++--
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/lib/Sbuild/Conf.pm b/lib/Sbuild/Conf.pm
index 17680aca..df9207ec 100644
--- a/lib/Sbuild/Conf.pm
+++ b/lib/Sbuild/Conf.pm
@@ -871,6 +871,13 @@ $environment_filter = [map /^FOOBAR$/ ? () : $_, 
Dpkg::Build::Info::get_build_en
HELP => 'APT clean.  1 to enable running "apt-get clean" at the 
start of each build, or 0 to disable.',
CLI_OPTIONS => ['--apt-clean', '--no-apt-clean']
},
+   'APT_KEEP_DOWNLOADED_PACKAGES'  => {
+   TYPE => 'BOOL',
+   VARNAME => 'apt_keep_downloaded_packages',
+   GROUP => 'Chroot options',
+   DEFAULT => 0,
+   HELP => 'Keep downloaded packages in cache by APT. Controls 
APT::Keep-Downloaded-Packages option used when downloading dependencies. 1 to 
keep downloaded packages in cache, or 0 to delete them after installation.'
+   },
'APT_UPDATE'=> {
TYPE => 'BOOL',
VARNAME => 'apt_update',
diff --git a/lib/Sbuild/ResolverBase.pm b/lib/Sbuild/ResolverBase.pm
index 4c154fe9..9be92e10 100644
--- a/lib/Sbuild/ResolverBase.pm
+++ b/lib/Sbuild/ResolverBase.pm
@@ -115,8 +115,13 @@ sub setup {
 print $F qq(APT::AutoRemove::SuggestsImportant "false";\n);
 print $F qq(APT::AutoRemove::RecommendsImportant "false";\n);
 print $F qq(Acquire::Languages "none";\n); # do not download translations
-# remove packages from /var/cache/apt/archive/*.deb after installation
-print $F qq(APT::Keep-Downloaded-Packages "false";\n);
+
+if ($self->get_conf('APT_KEEP_DOWNLOADED_PACKAGES')) {
+   print $F qq(APT::Keep-Downloaded-Packages "true";\n);
+} else {
+   # remove packages from /var/cache/apt/archive/*.deb after installation
+   print $F qq(APT::Keep-Downloaded-Packages "false";\n);
+}
 
 if ($self->get('Split')) {
print $F "Dir \"$chroot_dir\";\n";
-- 
2.23.0



signature.asc
Description: OpenPGP digital signature

Bug#935308: messed up regex

[Adam D. Barratt]

On Thu, 2019-08-29 at 22:45 +0100, Adam D. Barratt wrote:
> On Thu, 2019-08-29 at 23:20 +0200, Hans-Christoph Steiner wrote:
> > Ok, this is embarrasing: after discussing that Debian version regex
> > and
> > the version scheme for proposed-updates, I failed to see that the
> > regex
> > was wrong (see https://bugs.debian.org/935938).  Its fixed now in
> > 25.0.0+11+deb10u1.  And hopefully I got the version right.
> 
> No, that version is higher than unstable.
> 
> I'm a little confused by what you've uploaded now:
> 
> android-sdk-meta | 25.0.0+10 | stable   | source
> android-sdk-meta | 25.0.0+11~deb10u1 | proposed-updates | source
> android-sdk-meta | 25.0.0+11~deb10u2 | stable-new   | source
> android-sdk-meta | 25.0.0+11 | testing  | source
> android-sdk-meta | 25.0.0+11 | unstable | source
> android-sdk-meta | 25.0.0+11+deb10u1 | stable-new   | source
> 
> ~deb10u1 is the source I originally accepted, which generated the
> duplicate binary package versions. What's ~deb10u2?

OK, I've now seen the diffs, and the -12 upload to unstable. That
answers some of my questions, but...

+android-sdk-meta (25.0.0+11+deb10u1) buster; urgency=medium
+
+  * fix version: this adds on top of package from sid
+
+ -- Hans-Christoph Steiner   Thu, 29 Aug 2019 23:05:54
+0200
+
+android-sdk-meta (25.0.0+11~deb10u2) buster; urgency=medium

That version would be correct iff the remainder of the changelog was
from sid.

Will 25.0.0+11~deb10u2 build correctly-versioned binary packages if I
accept that one?

I noticed that +12 that just hit sid has

   * Revert "remove broken screenshot2 symlink (Closes: #924175)

although I can't see why from looking at the bug report. That change
was also included in the p-u uploads - should it be reverted there?

Regards,

Adam

Bug#934591: Anki fails to start: ModuleNotFoundError: No module named 'PyQt5.sip'

[Julian Gilbey]

severity 931798 normal
thanks

On Wed, Aug 21, 2019 at 09:39:52PM +0100, Julian Gilbey wrote:
> On Wed, Aug 21, 2019 at 04:22:23PM +0200, Arnaldo Pirrone wrote:
> > Hi, i do have python3-sip.
> > Now the error is this:
> > $ anki
> > Traceback (most recent call last):
> >   File "/usr/bin/anki", line 6, in 
> >     import aqt
> >   File "/usr/share/anki/aqt/__init__.py", line 32, in 
> >     import aqt.forms
> >   File "/usr/share/anki/aqt/forms/__init__.py", line 44, in 
> >     from . import about
> >   File "/usr/share/anki/aqt/forms/about.py", line 42, in 
> >     from aqt.webview import AnkiWebView
> >   File "/usr/share/anki/aqt/webview.py", line 90, in 
> >     class AnkiWebView(QWebEngineView):
> > NameError: name 'QWebEngineView' is not defined
> 
> OK, something is very very wrong with your installation of something,
> or some other problem, but I'm quite stumped.  Anki imports the whole
> of PyQt5.Qt, and that includes QWebEngineView.
> 
> Are you getting the same error message every time you try starting
> Anki, or is it different each time?

Dear Arnaldo,

Since I can't reproduce this problem, and it seems to be related to
something else wrong on your system (as it gives different errors on
different occasions), I'm reducing the severity of this bug to
"normal".  If you are able to answer my question, we could try to get
to the bottom of this, otherwise we'll just have to leave it,
unfortunately.

Best wishes,

   Julian

Bug#936081: New upstream 0.7.0 available

[Martin Michlmayr]

Package: wlroots
Severity: wishlist

Any plans to upload 0.7.0?

I'd like to see sway 1.2 in Debian. :)

-- 
Martin Michlmayr
https://www.cyrius.com/

Bug#874901: [GLE-devel] Probable fix for qgle seg faults with latest ghostscript versions

[Christian T. Steigies]

On Thu, Aug 29, 2019 at 10:55:28PM +0200, Francesco Poli wrote:
> On Thu, 29 Aug 2019 22:14:04 +0200 Christian T. Steigies wrote:
> 
> > Hi,
> > On Fri, Aug 16, 2019 at 04:32:08PM +0100, Laurence Abbott via Glx-devel 
> > wrote:
> > > I _think_ I have the fix for seg faults that occur when QGLE is used with
> > > ghostscript 9.27 (the latest release).
> > 
> > I applied Laurence's patches and applied them to the Debian package, plus
> > some Debian related changes. It looks as if we have QGLE ported to Qt5!
> 
> Hey, I am glad to hear this!   :-)
> I am adding the Qt4-removal bug address to the list of recipient, since
> this is good news for Qt4-removal issue.
> 
> > 
> > I need to do some before this can go into Debian, but here are amd64 and
> > source packages for you to test:
> > 
> > https://people.debian.org/~cts/deb/
> > 
> > Please don't upload them, but test and send feedback back to the list.
> 
> Any specific reason to use a version number (4.2.5-7~exp1) which is
> actually considered lower than the one currently in Debian unstable
> (4.2.5-7+b1)?

Oh, I forgot about the binNMU. This is not the version that will be uploaded
to Debian, that will be -8. I just wanted to give you something to test,
before I upload, and it should have had a version between 7 and 8. Well, I
guess you can still test it, since you need to install the deb manually
anyway.

Christian

Bug#929493: totem crashes on startup due to protocol error bug report #929493

[william l-k]

Package: totem
Version: 3.32.0-2
Followup-For: Bug #929493

This bug still exists in 3.33.90-2.

as noted witht he x11 token, this problem affects the ability to run totem when
using wayland.

I was puzzled as to why this bug was affecting our Debian based home
entertainment system, but not any of our laptops. When I ran totem from the
terminal, it threw the aforementioned error 71. I immediately checked to see
whether the unaffected systems were using Wayland: they were not.  Upgrading to
3.33.90-2 did not solve the problem. Switching from Gnome Wayland "system x11
default" - as expected - corrected the problem, enabling videos to play
normally in totem and launch from nautilus.







-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (800, 'testing'), (700, 'unstable'), (600, 'experimental'), (500, 
'stable')
Architecture: amd64 (x86_64)

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

Versions of packages totem depends on:
ii  grilo-plugins-0.3   0.3.9-1
ii  gsettings-desktop-schemas   3.28.1-1
ii  gstreamer1.0-clutter-3.03.0.27-1
ii  gstreamer1.0-plugins-base   1.16.0-2
ii  gstreamer1.0-plugins-good   1.16.0-2+b1
ii  gstreamer1.0-x  1.16.0-2
ii  libc6   2.28-10
ii  libcairo2   1.16.0-4
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libglib2.0-02.60.6-2
ii  libgstreamer-plugins-base1.0-0  1.16.0-2
ii  libgstreamer1.0-0   1.16.0-2.1
ii  libgtk-3-0  3.24.10-1
ii  libpango-1.0-0  1.42.4-7
ii  libpangocairo-1.0-0 1.42.4-7
ii  libtotem-plparser18 3.26.3-1
ii  libtotem0   3.32.0-2
ii  libx11-62:1.6.7-1
ii  totem-common3.32.0-2

Versions of packages totem recommends:
ii  gstreamer1.0-libav 1.16.0-2+b1
ii  gstreamer1.0-plugins-bad   1.16.0-2+b1
ii  gstreamer1.0-plugins-ugly  1.16.0-2
ii  gstreamer1.0-pulseaudio1.16.0-2+b1
ii  totem-plugins  3.32.0-2

Versions of packages totem suggests:
pn  gnome-codec-install  

-- debconf-show failed

Bug#936080: iputils-arping: arping -D : false positives

[Pierre Donis]

Package: iputils-arping
Version: 3:20190709-1
Severity: normal

Dear Maintainer,

I'm using dracut to build the initramfs to boot on an ISCSI root disk.
Line 125 of /usr/lib/dracut/modules.d/40network/ifup.sh :

 if ! arping -f -q -D -c 2 -I $netif $ip ; then
  warn "Duplicate address detected for $ip for interface $netif."
  return 1
 fi

Inirtd created with iputils-arping_20190709-1_amd64.deb, booting fails:
# arping -f -q -D -c 2 -I br0 172.16.1.100 ; echo $?
1

Inirtd created with iputils-arping_20180629-2_amd64.deb, booting succeeds:
# arping -f -q -D -c 2 -I br0 172.16.1.100 ; echo $?
0




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

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

Versions of packages iputils-arping depends on:
ii  libc62.28-10
ii  libcap2  1:2.25-2
ii  libcap2-bin  1:2.25-2

iputils-arping recommends no packages.

iputils-arping suggests no packages.

-- no debconf information

Bug#936016: meteo-qt crashes immediately

[Alf Gaida]

my bad, my first answer was wrong - should talk with the author


cheers Alf

Bug#936030: ***UNCHECKED*** Bug#936030: /usr/bin/cloud-init: cloud-init 18.3 failed to detect network link type: cascading (datasource: OpenStack)

[Thomas Goirand]

On 8/29/19 11:25 AM, sabrina-muel...@t-systems.com wrote:
> [...]
> # w3m -dump http://169.254.169.254/openstack/latest/network_data.json |
> jq ''
> 
> {
> [...]
>   "links": [
>     {
>   "type": "cascading",

Hi Sabrina,

Could you explain a little bit more what is "cascading" network type?
What I run is OpenStack with OVS, so therefore, on the above, I get:

  "links": [
{
  "type": "ovs"

and then it works perfectly for me. So, what exactly is your network setup?

Cheers,

Thomas Goirand (zigo)

Bug#875234: [writetype] Future Qt4 removal from Buster

[Miriam Ruiz]

Thanks!!!

Miry

El jue., 29 ago. 2019 a las 23:05, Moritz Mühlenhoff
() escribió:
>
> On Thu, Aug 29, 2019 at 10:58:03PM +0200, Miriam Ruiz wrote:
> > It's okay for me to remove it from the archive. I think it would be
> > the best. As you say, it seems to be dead upstream.
>
> Ack, I've just filed a removal bug.
>
> Cheers,
> Moritz

Bug#935308: messed up regex

[Adam D. Barratt]

On Thu, 2019-08-29 at 23:20 +0200, Hans-Christoph Steiner wrote:
> Ok, this is embarrasing: after discussing that Debian version regex
> and
> the version scheme for proposed-updates, I failed to see that the
> regex
> was wrong (see https://bugs.debian.org/935938).  Its fixed now in
> 25.0.0+11+deb10u1.  And hopefully I got the version right.

No, that version is higher than unstable.

I'm a little confused by what you've uploaded now:

android-sdk-meta | 25.0.0+10 | stable   | source
android-sdk-meta | 25.0.0+11~deb10u1 | proposed-updates | source
android-sdk-meta | 25.0.0+11~deb10u2 | stable-new   | source
android-sdk-meta | 25.0.0+11 | testing  | source
android-sdk-meta | 25.0.0+11 | unstable | source
android-sdk-meta | 25.0.0+11+deb10u1 | stable-new   | source

~deb10u1 is the source I originally accepted, which generated the
duplicate binary package versions. What's ~deb10u2?

25.0.0+11+deb10u1 is higher than the version in unstable, which doesn't
make a lot of sense.

> Is this bug report enough, or should I open a new one?

This one's sufficient, but as above I'm not sure what's going on with
the uploads.

Regards,

Adam

Bug#936007: stretch-pu: package libu2f-host/1.1.2-2+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2019-08-29 at 00:04 +0200, Nicolas Braud-Santoni wrote:
> I would like to backport the fix for CVE-2019-9578 in the next point
> release
> for stretch.  Please find enclosed the proposed debdiff.

++  /* the response has to be atleast 17 bytes, if it's more we discard 
that */
++  if (resplen < 17)

"at least" - it's two words. Also the first half of the comment and the
code itself imply that "more" should be "less".

Please go ahead.

Regards,

Adam

Bug#936016: meteo-qt crashes immediately

[Alf Gaida]

Nice finding, unfortunately you are right:


>From bfe9ae4d25b914d5c2622042303ba09fa8060e80 Mon Sep 17 00:00:00 2001
From: Dimitrios Glentadakis 
Date: Mon, 6 May 2019 19:34:58 +0200
Subject: [PATCH] Fix crash when 6 days forceast is not available

---
 meteo_qt/meteo_qt.py | 4 
 1 file changed, 4 insertions(+)

diff --git a/meteo_qt/meteo_qt.py b/meteo_qt/meteo_qt.py
index f6fca87..9774616 100644
--- a/meteo_qt/meteo_qt.py
+++ b/meteo_qt/meteo_qt.py
@@ -1861,6 +1861,10 @@ def run(self):
 'Fetching url for 6 days :' + self.forecast6_url
 + self.id_ + self.suffix + '=7'
 )
+reqforecast6 = (
+self.forecast6_url + self.id_
++ self.suffix + '=7'
+)
 try:
 reqforecast6 = urllib.request.urlopen(
 self.forecast6_url + self.id_


Applying this patch to 1.0.0 fixes the problem for me - next question is:

How to get this to stable, testing and sid have already 1.3.

Bug#933822: closed by Jan Dittberner (Bug#933822: fixed in virtualenvwrapper 4.8.4-1)

[Peter Green]

On 28/08/2019 09:12, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the virtualenvwrapper package:

#933822: virtualenvwrapper depends on cruft package python-stevedore

Is there a reason that the fix was only uploaded to experimental? and/or an ETA 
for getting the fix in unstable?

Bug#935976: stretch-pu: package node-ws/1.1.0+ds1.e6ddaae4-3+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2019-08-28 at 17:29 +0200, Xavier Guimard wrote:
> During buster release, we fixed CVE-2016-10542 for node-ws. The same
> patch can be applied in Stretch.
> 

Please go ahead.

Regards,

Adam

Bug#936079: python-ceilometerclient (build-)depends on cruft packages.

[peter green]

Package: python-ceilometerclient
Version: 2.9.0-2
Severity: serious
Tags: bullseye, sid

The python-ceilometerclient binary package depends on and the 
python-ceilometerclient binary package build-depends on a number of python 2 
binary packages that are no longer built by their corresponding source packages.

There don't seem to be any reverse-dependencies left, so presumablly it is time 
to drop python 2 support from this package.

Bug#912498: freealchemist: Please migrate to python3-pygame

[Reiner Herrmann]

Control: tags -1 + patch

Dear maintainer,

I submitted a merge request for Python 3 support on salsa:
 
https://salsa.debian.org/python-team/applications/freealchemist/merge_requests/1

Kind regards,
  Reiner


signature.asc
Description: PGP signature

Bug#935915: Same problem reported on ubuntu

[sixerjman]

https://bugs.launchpad.net/ubuntu/+source/apt-cacher-ng/+bug/1034392

The original bug was reported in 2012 but recent comments are from 2018 and
2019:

Steve Dodd (anarchetic)  wrote on
2018-07-07: #17


I am seeing this on a box running 14.04 (acng 0.7.26-1ubuntu0.1) - nothing
leapt out when I strace'd, I will try again and save to file. I am also not
sure that strace-ing didn't "unstick" the acng process, which would be very
odd ..

I will also try backporting a more recent acng and see if problem still
exists,
Andres Jalinton (andresj551)  wrote on
2019-01-24: #18


   - logfile2
   

Edit
   

(234.2
   KiB, text/plain)

I'm running an Ubuntu 14.04 and Ubuntu 16.04.5 serving the DEB cache with
apt-cacher-ng.

The download of files to the older (and tested in other distros debian
based) is very slow (10 to 50 kbps)

Attached are the strace files.

Bug#935015: datalad: please drop python-datalad (python 2 removal effort)

[peter green]

Found 935015 0.11.2-2
Thanks

This bug also affects the version in testing.

Bug#935999: buster-pu: package libu2f-host/1.1.9-1+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2019-08-28 at 22:52 +0200, Nicolas Braud-Santoni wrote:
> On Wed, Aug 28, 2019 at 10:29:02PM +0200, Nicolas Braud-Santoni
> wrote:
> > I would like to backport the following patches for libu2f-host to
> > stretch:
> > 
> >   + Fix for CVE-2019-9578 (Closes: #923874)
> 
> I was confused, this is a minor security issue for which no CVE was
> assigned.
> (CVE-2019-9578 / #923874 impacts stretch, and should be addressed in
> stretch-pu)
> 

Please go ahead.

Regards,

Adam

Bug#936022: buster-pu: package osmpbf/1.3.3-11

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2019-08-29 at 10:15 +0200, Bas Couwenberg wrote:
> To fix the PBF support in the osmpbf rdeps it needs to be rebuilt
> with protobuf 3.6.1 as reported in #935990.
> 

Please go ahead.

Regards,

Adam

Bug#935308: messed up regex

[Hans-Christoph Steiner]

Ok, this is embarrasing: after discussing that Debian version regex and
the version scheme for proposed-updates, I failed to see that the regex
was wrong (see https://bugs.debian.org/935938).  Its fixed now in
25.0.0+11+deb10u1.  And hopefully I got the version right.

Is this bug report enough, or should I open a new one?

Bug#936056: buster-pu: package sdl-image1.2/1.2.12-10+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2019-08-29 at 09:45 -0400, Hugo Lefeuvre wrote:
> sdl-image1.2 is affected by a number of security issues in buster.
> Impact is
> quite minor, but it would still be nice to get them fixed.
> 

Please go ahead.

Regards,

Adam

Bug#936051: stretch-pu: package sdl-image1.2/1.2.12-5+deb9u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2019-08-29 at 09:51 -0400, Hugo Lefeuvre wrote:
> Small update: I forgot to close the bug report (#932755) and did not
> mention
> CVE-2019-5058 in debian/changelog. You can find an updated debdiff in
> attachment.
> 

Please go ahead.

Regards,

Adam

Bug#936060: rocksndiamonds lintian override for maintainer-script-should-not-use-recursive-chown-or-chmod reasoning is incorrect

[Stephen Kitt]

Hi Daniel,

Thanks for taking an interest in this, I’ve often wondered if I’d got my
analysis right...

On Thu, 29 Aug 2019 10:45:08 -0400, Daniel Kahn Gillmor
 wrote:
> the lintian override says:
> 
> # We recursively chown files to root:root after neutering their
> # permissions, so the attacks mentioned by Lintian aren’t applicable
> rocksndiamonds: maintainer-script-should-not-use-recursive-chown-or-chmod
> postinst:340 rocksndiamonds:
> maintainer-script-should-not-use-recursive-chown-or-chmod postinst:341
> rocksndiamonds: maintainer-script-should-not-use-recursive-chown-or-chmod
> postinst:342
> 
> But this reasoning doesn't follow.

I agree, and it seems I forgot the first rule of security, documenting the
scenarios.

> The script is:
> 
> cmd_execute "find $tempdir -type d -exec chmod 0755 '{}' '+'";
> cmd_execute "find $tempdir -type f -exec chmod 0644 '{}' '+'";
> cmd_execute "chown -R root:root $tempdir";
> 
> even if we set aside race condition concerns (can some unprivileged user
> get away with something between the find and the chown?), the
> "neutering" of permissions makes all the files in that directory
> world-readable.
> 
> so if an attacker can manage to link /etc/shadow or
> /etc/ssh/ssh_host_*_key or whatever into that directory before the chown
> happens, they can reveal system secrets that should only be visible to
> the superuser.

But all this happens inside $tempdir, which is root:root 700. If anyone can
race there, or read files, we’ve lost already, haven’t we? And if they can’t,
then we’re safe, at least until we copy the files elsewhere — and I think at
this point we’re sure the files can only match the contents of the archives we
unpack.

The scenario I was thinking of when I wrote my comment was the issue of
suid/sgid binaries, since those could be stored in the archives we extract.
But even then, I don’t think there would be a way of exploiting them even if
the chown happened before the chmods, and in any case the archives are
extracted without preserving permissions...

It’s quite likely I’ve missed something, so if you can identify a scenario in
which the extraction is unsafe, I’d love to know about it.

Regards,

Stephen


pgpnnoDjEZZUY.pgp
Description: OpenPGP digital signature

Bug#936078: RM: writetype -- RoQA; dead upstream, depends on qt4

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove writetype. It's dead upstream and depends on Qt4, the maintainer
(CCed) has acked the removal in #875234).

Cheers,
Moritz

Bug#875234: [writetype] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Thu, Aug 29, 2019 at 10:58:03PM +0200, Miriam Ruiz wrote:
> It's okay for me to remove it from the archive. I think it would be
> the best. As you say, it seems to be dead upstream.

Ack, I've just filed a removal bug.

Cheers,
Moritz

Bug#701903: Issue incorrectly tagged fixed-upstream

[segfault]

Simon McVittie:
> You mentioned Bugzilla #679622, but that looks like an unrelated bug
> (which was also migrated to Gitlab, this time as GNOME/gimp#412).

Right, copied the wrong link, sorry about that.

Bug#936077: RM: gns3 -- RoQA; unmaintained, depends on qt4

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove gns3. It's unmaintained (last upload in 2014), is removed from
testing since 15 months due to the old version being unusable (#784871) and
depends on qt4, which is going away.

Cheers,
Moritz

Bug#935915: CPU load, kernel IP filters not a factor

[sixerjman]

CPU load - Not a factor, utilization is almost always less than 30% when
tests are run. Nothing is running in the GUI,
of the acng server, not even a browser.  The out of tree module is the
'netatop' module which works inside atop
and it hardly uses any cycles. The module is loaded and the netatop daemon
is running all the time, and CPU utilization
hasn't budged past 5% all day.

Kernel IP filters - None are running as far as I can tell, i.e. no firewall
is running.

Things were going well until a few weeks ago IIRC, but since it slowed to a
crawl I had to revert the few clients I have
to direct downloads. Using the same mirror as the acng server, the 'apt
update / upgrade' cycle elapsed time
immediated reverted back to the order of seconds from order of minutes.
the order of seconds from the order of minutes immediately.

The apt-cacher-err.log shows the debug trace of an 'apt-get update' from a
client. Note the
elapsed time is a tad over 3 minutes. From the same client an 'apt-get
update' took about 9 seconds:

time sudo apt-get update

<* 27 gets *>

real 0m9.601s
user 0m10.649s
sys 0m1.819s

Bug#936076: python3-numba: numba segfaults when run with python 3.7.4 at numba/_dynfunc.c:52

[Diane Trout]

Package: python3-numba
Version: 0.42.0-1
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainer,

Attempting to run any numba code immediately segfaults when running with python
3.7.4.

I found this upstream bug report.
https://github.com/numba/numba/pull/4328

"CPython 3.7.3->3.7.4 changed the size of PyGC_Head, the macro
_PyObject_GC_UNTRACK relied on calling sizeof() on that struct, as it is a
macro it got baked in at compile time and then segfaults happen across the
point version change as the struct size changed."

The simplist solution is to rebuild with python 3.7.4... though then it'll
crash with earlier versions.

Diane



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

Kernel: Linux 5.2.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:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-numba depends on:
ii  libc6   2.28-10
ii  libgcc1 1:9.2.1-4
ii  libgomp19.2.1-4
ii  libstdc++6  9.2.1-4
ii  libtbb2 2019~U8-1
ii  python3 3.7.3-1
ii  python3-llvmlite0.27.0-2
ii  python3-numpy [python3-numpy-abi9]  1:1.16.2-1+b1

Versions of packages python3-numba recommends:
ii  numba-doc  0.42.0-1

Versions of packages python3-numba suggests:
pn  nvidia-cuda-toolkit  

-- no debconf information

Bug#875234: [writetype] Future Qt4 removal from Buster

[Miriam Ruiz]

It's okay for me to remove it from the archive. I think it would be
the best. As you say, it seems to be dead upstream.

Greetings,
Miry

El jue., 29 ago. 2019 a las 22:42, Moritz Mühlenhoff
() escribió:
>
> On Sat, Sep 09, 2017 at 11:12:40PM +0200, Lisandro Damián Nicanor Pérez Meyer 
> wrote:
> > Source: writetype
> > Version: 1.3.163-1
> > Severity: wishlist
> > User: debian-qt-...@lists.debian.org
> > Usertags: qt4-removal
> >
> >
> > Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> > as [announced] in:
> >
> > Therefore, please take the time and:
> > - contact your upstream (if existing) and ask about the state of a Qt5
> > port of your application
> > - if there are no activities regarding porting, investigate whether there 
> > are
> > suitable alternatives for your users
> > - if there is a Qt5 port that is not yet packaged, consider packaging it
> > - if both the Qt4 and the Qt5 versions already coexist in the Debian
> > archives, consider removing the Qt4 version
>
> Hi,
> writetype is dead upstream (the website vanished completely), are you
> planning to port it yourself or should we remove it from the archive?
>
> Cheers,
> Moritz

Bug#874901: [GLE-devel] Probable fix for qgle seg faults with latest ghostscript versions

[Francesco Poli]

On Thu, 29 Aug 2019 22:14:04 +0200 Christian T. Steigies wrote:

> Hi,
> On Fri, Aug 16, 2019 at 04:32:08PM +0100, Laurence Abbott via Glx-devel wrote:
> > I _think_ I have the fix for seg faults that occur when QGLE is used with
> > ghostscript 9.27 (the latest release).
> 
> I applied Laurence's patches and applied them to the Debian package, plus
> some Debian related changes. It looks as if we have QGLE ported to Qt5!

Hey, I am glad to hear this!   :-)
I am adding the Qt4-removal bug address to the list of recipient, since
this is good news for Qt4-removal issue.

> 
> I need to do some before this can go into Debian, but here are amd64 and
> source packages for you to test:
> 
> https://people.debian.org/~cts/deb/
> 
> Please don't upload them, but test and send feedback back to the list.

Any specific reason to use a version number (4.2.5-7~exp1) which is
actually considered lower than the one currently in Debian unstable
(4.2.5-7+b1)?

  $ if dpkg --compare-versions 4.2.5-7+b1 lt 4.2.5-7~exp1 ; then echo yes ; 
else echo no ; fi
  no

Should it be 4.2.5-8~exp1, perhaps?


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpYS3xJP4nMT.pgp
Description: PGP signature

Bug#932248: python*-acme and Certbot will break on November 1st

[Brad Warren]

Any updates on this?

Looking at server logs, I expect ~145K+ unique installations to be affected by 
this problem if it doesn’t get fixed.

Bug#875234: [writetype] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Sat, Sep 09, 2017 at 11:12:40PM +0200, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Source: writetype
> Version: 1.3.163-1
> Severity: wishlist
> User: debian-qt-...@lists.debian.org
> Usertags: qt4-removal
> 
> 
> Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> as [announced] in:
> 
> Therefore, please take the time and:
> - contact your upstream (if existing) and ask about the state of a Qt5
> port of your application
> - if there are no activities regarding porting, investigate whether there are
> suitable alternatives for your users
> - if there is a Qt5 port that is not yet packaged, consider packaging it
> - if both the Qt4 and the Qt5 versions already coexist in the Debian
> archives, consider removing the Qt4 version

Hi,
writetype is dead upstream (the website vanished completely), are you
planning to port it yourself or should we remove it from the archive?

Cheers,
Moritz

Bug#936006: [Pkg-fonts-devel] Bug#936006: fonts-dejavu-core: Invalid rendering of 'ż' at serveral different sizes

[Fabian Greffrath]

Am Donnerstag, den 29.08.2019, 21:58 +0200 schrieb Łukasz Stelmach:
> Done, however, I am not 100% sure github is the right place to do it.

Thanks for that! Well, at least now it is at the attention of the
upstream developers. Though, last commit from 2+ years ago doesn't
really look promising...

 - Fabian



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

Bug#925862: xbindkeys-config: ftbfs with GCC-9

[Reiner Herrmann]

Control: tags -1 + patch

Dear maintainer,

the attached patch fixes the FTBFS by moving the linked
libraries to the end of the command line.

Regards,
  Reiner
--- xbindkeys-config-0.1.3.orig/debian/patches/gcc9.patch
+++ xbindkeys-config-0.1.3/debian/patches/gcc9.patch
@@ -0,0 +1,15 @@
+Author: Reiner Herrmann 
+Description: Fix FTBFS with gcc9 by moving libs to the end of the command line
+Bug-Debian: https://bugs.debian.org/925862
+
+--- a/Makefile
 b/Makefile
+@@ -15,7 +15,7 @@
+ all: main
+ 
+ main: $(OBJS)
+-	$(CC) $(GTK) $(OBJS) -o $(NOM)
++	$(CC) $(OBJS) -o $(NOM) $(GTK)
+ 
+ clean:
+ 	rm -f *.o */*.o */*~ core $(NOM) *~
only in patch2:
unchanged:
--- xbindkeys-config-0.1.3.orig/debian/patches/series
+++ xbindkeys-config-0.1.3/debian/patches/series
@@ -0,0 +1 @@
+gcc9.patch


signature.asc
Description: PGP signature

Bug#875250: [scim] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Sat, Sep 09, 2017 at 11:09:36PM +0200, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Source: scim
> 
> Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> as [announced] in:
> 
> [announced] 
> 
> 
> Currently Qt4 has been dead upstream and we are starting to have problems
> maintaining it, like for example in the [OpenSSL 1.1 support] case.
> 
> [OpenSSL 1.1 support] 
> 
> 
> In order to make this move, all packages directly or indirectly depending on
> the Qt4 libraries have to either get ported to Qt5 or eventually get
> removed from the Debian repositories.
> 
> Therefore, please take the time and:
> - contact your upstream (if existing) and ask about the state of a Qt5
> port of your application
> - if there are no activities regarding porting, investigate whether there are
> suitable alternatives for your users
> - if there is a Qt5 port that is not yet packaged, consider packaging it
> - if both the Qt4 and the Qt5 versions already coexist in the Debian
> archives, consider removing the Qt4 version

Given upstream's comments on https://github.com/scim-im/scim/issues/21, let's
move forward by dropping the scim-qt-immodule binary package? It can still
be re-added if a Qt5 port appears at a later time.

Cheers,
Moritz

Bug#930446: popularity-contest: unable to submit report, impossible to debug

[Ludovic Rousseau]

On Wed, 12 Jun 2019 22:52:59 +0200 Bill Allombert  wrote:

On Wed, Jun 12, 2019 at 09:46:58PM +0200, Stefan Fritsch wrote:
> Package: popularity-contest
> Version: 1.67
> Severity: normal
> 
> Dear Maintainer,
> 
> on several of my hosts, popularity-contest logs
> 
>   unable to submit report to http://popcon.debian.org/cgi-bin/popcon.cgi.

>   unable to submit report.
> 
> But it does not log why and there is no way that I could find to trigger

> the sending from the command line with debug output enabled.
> 
> http://popcon.debian.org/cgi-bin/pop is reachable from the host via curl. Also,

> according to the documentation it should fall back to email, which it does not
> do. It does not log why it does not do that.

Hello Stefan!

This comes from /etc/cron.daily/popularity-contest:
# try to post the report through http POST
if [ "$SUBMITURLS" ] && [ "yes" = "$USEHTTP" ]; then
for URL in $SUBMITURLS ; do
if setsid /usr/share/popularity-contest/popcon-upload \
-u $URL -f $POPCON 2>/dev/null ; then
SUBMITTED=yes
else
logger -t popularity-contest "unable to submit report to
$URL."
fi
done
fi

/usr/share/popularity-contest/popcon-upload has an option -d for
debugging that you could try.


I added the -d to get some more debug.

But what I got is not really helpfull. I got an email from cron:

From: r...@pihole.xxx.fr (Cron Daemon)
To: r...@pihole.xxx.fr
Subject: Cron  test -x /usr/sbin/anacron || ( cd / && run-parts 
--report /etc/cron.daily )
Date: Thu, 29 Aug 2019 06:25:15 +0200

/etc/cron.daily/popularity-contest:
Failed to upload, answer ''



And in /var/log/messages I have the classic:
Aug 29 06:25:15 PiHole popularity-contest: unable to submit report to 
http://popcon.debian.org/cgi-bin/popcon.cgi.
Aug 29 06:25:15 PiHole popularity-contest: unable to submit report


I am using Debian stable (buster) with popularity-contest 1.67

Bye

--
 Dr. Ludovic Rousseau

Bug#930363: faad2: fix build with gcc-9 [patch]

[Fabian Greffrath]

Am Donnerstag, den 29.08.2019, 09:54 -0400 schrieb Hugo Lefeuvre:
> Ack, I'll NMU then. Good luck with the baby :)

Thank you! \o/

 - Fabian



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

Bug#875219: [unixodbc-gui-qt] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Sat, Sep 09, 2017 at 11:11:54PM +0200, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Source: unixodbc-gui-qt
> Version: 2.3.0-4
> Severity: wishlist
> User: debian-qt-...@lists.debian.org
> Usertags: qt4-removal
> 
> 
> Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> as [announced] in:
> 
> Therefore, please take the time and:
> - contact your upstream (if existing) and ask about the state of a Qt5
> port of your application
> - if there are no activities regarding porting, investigate whether there are
> suitable alternatives for your users
> - if there is a Qt5 port that is not yet packaged, consider packaging it
> - if both the Qt4 and the Qt5 versions already coexist in the Debian
> archives, consider removing the Qt4 version

The current SVN trunk on the SourceForge page supports Qt5.

Cheers,
Moritz

Bug#936006: [Pkg-fonts-devel] Bug#936006: fonts-dejavu-core: Invalid rendering of 'ż' at serveral different sizes

[Łukasz Stelmach]

Control: forwarded -1 https://github.com/dejavu-fonts/dejavu-fonts/issues/338

Fabian Greffrath  writes:
> Would you mind reporting this issue upstream, please?

Done, however, I am not 100% sure github is the right place to do it.

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


signature.asc
Description: PGP signature

Bug#933578: Possible fix scanning with HP MFP that requires a plugin

[Nathan Wallach]

I had quite some difficulty getting "hp-setup" to configure a HP Color
LaserJet Pro MFP M277dw to allow scanning + "hp-toolbox" to allow scanning,
status check, etc. on Debian 10.

See:
https://bugs.launchpad.net/ubuntu/+source/hplip/+bug/1430561/comments/39

I found several things which together got scanning and hp-toolbox
working for me with my HP Color LaserJet Pro MFP M277dw. I hope the
proceedure below is of help to someone else.

1. Fix the source for the gpg key to avoid the problem with the pgp.mit.edu
server:

   sudo cp -a /usr/share/hplip/base/validation.py
/usr/share/hplip/base/validation.py.ORIG

   vim /usr/share/hplip/base/validation.py

   # replace pgp.mit.edu with pool.sks-keyservers.net on line 44

2. After getting the plugin to install using "hp-plugin" as a regular user
and the root password when requested, the software still complained...

3. It seems that hplip expects the libraries in a different location than
where they are getting installed:

   find /usr/lib -name "*sane*" | grep hp2000S

   sudo ln -s /usr/lib /usr/lib/i386-linux-gnu
   sudo ln -s /usr/lib64 /usr/lib64/x86_64-linux-gnu

(Based on https://bugs.launchpad.net/hplip/+bug/1818629)

Bug#935133: [Pkg-openssl-devel] Bug#935133: Bug#935133: slow TLS handshake renders browsers and email client unusable

[nbi]

While I may be the first to report this to Debian bugs casual googling 
turns up other reports of this to the Internet at large.


The good news is that the MTU workaround seems to be working as there 
has not been any TLS handshake issues since the workaround was applied. 
While I'm completely baffled as to why this should be the case (MTU size 
should be totally transparent at the TLS level) I'll take the victory. I 
guess this ticket can be closed and revisited if need be.


On Wed, 21 Aug 2019 19:08:12 +0200 Kurt Roeckx  wrote:
> On Wed, Aug 21, 2019 at 09:47:09AM -0700, nbi wrote:
> > Some progress. I found a reference to a MTU size issue possibly 
impacting
> > this. I'm using channel bonding provided by the ifenslave package. 
It turns
> > out ifenslave has a bug that causes it to not set the MTU size 
correctly on
> > the active slave. I applied the workaround and verified the MTU is 
correct.
> > I have not seen the handshake problem since, but it is much too 
early to
> > tell. I'm perplexed as to how MTU fragmentation/reassembly could 
possibly
> > impact this issue, but if that turns out to be the fix I'm more 
than happy

> > to go with it.
> >
> > If the problem resurfaces I will use the utility dumpssl to debug the
> > handshakes.
>
> I did suspect something between your PC and the internet, but a
> reboot fixing it didn't then make sense. I guess it's on the PC
> itself, and something specific to your setup.
>
> That it slows down does not make sense to me, so I suspect there
> is an other bug than the MTU problem. My expierence with MTU
> problems is that some sites don't work at all, or only sometimes,
> rather than slow down.
>
> > > > Neither Firefox nor Chrome makes use of openssl. Firefox makes use
> > > > of NSS (libnss3). Chrome makes use of boringssl, but neither
> > > > Chrome nor boringssl is part of Debian. Chromium has an embeded
> > > > copy of boringssl.
> > >
> > > I don't understand how all these apps can experience the same problem
> > > without using a shared component for the TLS handshakes. That 
would just

> > > be too coincidental, no?
> > > boringssl is a fork of Openssl. So is it possible that some of the
> > > problems that existed in Openssl were carried forward to boringssl
> > > without correction?
>
> The TLS implementations have very little in common. boringssl
> isn't really a fork of OpenSSL, it just picked random parts of the
> OpenSSL code, and has rewritten other parts. Even if the TLS
> implementations was very simular, both boringssl and openssl
> have rewritten it since the "fork". As far as I know, NSS doesn't
> share any code with the others.
>
> > > > Did you try to look at network traffic with something like
> > > > wireshark?
> > >
> > > And what am I looking for? You're suggesting that I'm the first 
person

> > > to report this problem? I've already spent far too much time on this
> > > issue and now you're asking me an end user to spend even more time on
> > > this issue? I don't mind helping, but it needs to be within 
reason. In

> > > this case having specific things to look for would be most helpful.
>
> So yes, you're the first person to report anything like that.
>
> With the switch to buster, lots of things changed including the
> kernel. I guess most of your traffic is TLS based, so I'm not even
> sure it's only TLS connections that are affected. The problem can
> be in any of the components.
>
> If you have the problem again, I suggest to use a tool like
> wireshark or tcpdump to monitor the network traffic. You can at
> least look at which side seems to be slow to respond. I don't

Bug#936075: ITP: fortran-language-server -- Fortran Language Server for the Language Server Protocol

[Denis Danilov]

Package: wnpp
Severity: wishlist
Owner: Denis Danilov 

* Package name: fortran-language-server
  Version : 1.10.2
  Upstream Author : Chris Hansen
* URL : https://github.com/hansec/fortran-language-server
* License : MIT
  Programming Lang: Python
  Description : Fortran Language Server for the Language Server Protocol

Fortran Language Server (fortls) is an implementation of the Language Server
Protocol.  It can be used with editors that supports the protocol to offer
support for code completion and documentation.

Supported LSP features include:
* Document symbols (textDocument/documentSymbol)
* Auto-complete (textDocument/completion)
* Signature help (textDocument/signatureHelp)
* GoTo/Peek definition (textDocument/definition)
* Hover (textDocument/hover)
* GoTo implementation (textDocument/implementation)
* Find/Peek references (textDocument/references)
* Project-wide symbol search (workspace/symbol)
* Symbol renaming (textDocument/rename)
* Documentation parsing (Doxygen and FORD styles)
* Diagnostics

Bug#925625: abr2gbr: ftbfs with GCC-9

[Reiner Herrmann]

Control: tags -1 + patch

Dear maintainer,

the attached patch fixes the FTBFS by moving the libs
to the end of the command line.

Regards,
  Reiner
diff -Nru abr2gbr-1.0.2/debian/patches/gcc9.patch abr2gbr-1.0.2/debian/patches/gcc9.patch
--- abr2gbr-1.0.2/debian/patches/gcc9.patch	1970-01-01 01:00:00.0 +0100
+++ abr2gbr-1.0.2/debian/patches/gcc9.patch	2010-08-24 10:01:53.0 +0200
@@ -0,0 +1,15 @@
+Author: Reiner Herrmann 
+Description: Fix FTBTS with gcc9 by moving libs to the end of the command line
+Bug-Debian: https://bugs.debian.org/925625
+
+--- a/Makefile
 b/Makefile
+@@ -44,7 +44,7 @@
+ 	$(CC) -o $@ $(CFLAGS) -c $<
+ 
+ $(OBJDIR)/$(BIN): $(DESTS)
+-	$(CC) -o $@ $(CFLAGS) $(LIBS) $(DESTS)
++	$(CC) -o $@ $(CFLAGS) $(DESTS) $(LIBS)
+ 	if [ ! -L $(BIN) ]; then \
+ 		ln -s $(OBJDIR)/$(BIN) .; \
+ 		ln -s $(OBJDIR)/$(BIN) jbr2gbr; \
diff -Nru abr2gbr-1.0.2/debian/patches/series abr2gbr-1.0.2/debian/patches/series
--- abr2gbr-1.0.2/debian/patches/series	2010-08-27 21:37:09.0 +0200
+++ abr2gbr-1.0.2/debian/patches/series	2010-08-24 10:01:53.0 +0200
@@ -1 +1,2 @@
 fix_compile_flags-1:1.0.2-2
+gcc9.patch


signature.asc
Description: PGP signature

Bug#936074: irssi: CVE-2019-15717

[Salvatore Bonaccorso]

Source: irssi
Version: 1.2.1-1
Severity: important
Tags: security upstream
Control: found -1 1.2.0-2

Hi,

The following vulnerability was published for irssi.

CVE-2019-15717[0]:
| Irssi 1.2.x before 1.2.2 has a use-after-free if the IRC server sends
| a double CAP.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-15717
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15717
[1] https://irssi.org/security/irssi_sa_2019_08.txt
[2] 
https://github.com/irssi/irssi/commit/5a4e7ab659aba2855895c9f43e9a7a131f4e89b3

Regards,
Salvatore

Bug#936073: please have libffi6-dbgsym debug package

[shirish शिरीष]

Package: libffi6
Version: 3.2.1-9
Severity: normal

Dear Maintainer,
It would be nice to have libffi6-dbgsym instead of libffi6-dbg as lot
of archive has moved to use -dbgsym as they give more info. while
debugging.

See https://wiki.debian.org/AutomaticDebugPackages for more info.

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

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

Versions of packages libffi6 depends on:
ii  libc6  2.28-10

libffi6 recommends no packages.

libffi6 suggests no packages.

-- no debconf information

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#935988: buster-pu: package reportbug/7.5.2+nmu1~deb10u1

[Andreas Beckmann]

On 29/08/2019 20.26, Adam D. Barratt wrote:
> Will you be updating and/or reversioning the pu to reflect the
> maintainer upload?

Yes, updated pu is coming... The maintainer upload contained a few more
bugfixes, but I think they all should go to buster as well.
Unfortunately it's lacking a one-line change to re-enable oldstable_pu
(i.e. stretch-pu) requests ... I'll include that in the updated pu
unless 7.5.4 shows up til tomorrow.

I tried to dcut the delayed upload, but got errors that the files were
not found. So in case 7.5.2+nmu1~deb10u1 still shows up, please reject it.


Andreas

Bug#875029: [lightdm] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Thu, Sep 21, 2017 at 03:36:38PM +0200, Yves-Alexis Perez wrote:
> On Thu, 2017-09-21 at 00:09 +0800, Boyuan Yang wrote:
> > I noticed that you are planning to remove Qt components of lightdm from 
> > Debian's lightdm. In fact, pkg-deepin team has a planned package that needs 
> > Qt5-based liblightdm-qt as (build-)dependency. See bug #871840 [1]. In case 
> > you might be curious, we have a dependency graph too. [3]
> 
> Hi,
> 
> I'm a not at all interested in Qt (4 or 5) components, so honestly I'm all
> inclined to just disable Qt4 and stay like this.

Attached is a patch which drops Qt4 support. It's only used by src:razorqt,
which is already RC-buggy anyway and which will be removed soon along with
Qt4.

Cheers,
Moritz
diff -Naur lightdm-1.26.0.orig/debian/control lightdm-1.26.0/debian/control
--- lightdm-1.26.0.orig/debian/control	2019-07-10 22:34:59.0 +0200
+++ lightdm-1.26.0/debian/control	2019-08-29 20:25:12.718749257 +0200
@@ -16,7 +16,6 @@
libglib2.0-dev,
libgtk-3-dev,
libpam-dev,
-   libqt4-dev,
libxcb1-dev,
libxdmcp-dev,
libxklavier-dev,
@@ -72,15 +71,6 @@
  This package contains the GObject library for lightdm, used by the GTK+
  greeter.
 
-Package: liblightdm-qt-3-0
-Section: libs
-Architecture: any
-Multi-Arch: same
-Pre-depends: ${misc:Pre-Depends}
-Depends: ${misc:Depends}, ${shlibs:Depends}
-Description: simple display manager (Qt library)
- This package contains the Qt library for lightdm.
-
 Package: liblightdm-qt5-3-0
 Section: libs
 Architecture: any
@@ -107,17 +97,6 @@
  This package contains the development files for lightdm.
  They can be used to build new greeters applications GTK+ based.
 
-Package: liblightdm-qt-dev
-Section: libdevel
-Architecture: any
-Multi-Arch: same
-Depends: liblightdm-qt-3-0 (= ${binary:Version}),
- ${misc:Depends},
- ${shlibs:Depends}
-Description: simple display manager (Qt development files)
- This package contains the development files for lightdm.
- They can be used to build new greeters applications Qt based.
-
 Package: liblightdm-qt5-3-dev
 Section: libdevel
 Architecture: any
diff -Naur lightdm-1.26.0.orig/debian/liblightdm-qt-3-0.install lightdm-1.26.0/debian/liblightdm-qt-3-0.install
--- lightdm-1.26.0.orig/debian/liblightdm-qt-3-0.install	2019-07-10 22:34:59.0 +0200
+++ lightdm-1.26.0/debian/liblightdm-qt-3-0.install	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-usr/lib/*/liblightdm-qt-*.so.*
diff -Naur lightdm-1.26.0.orig/debian/liblightdm-qt-3-0.lintian-overrides lightdm-1.26.0/debian/liblightdm-qt-3-0.lintian-overrides
--- lightdm-1.26.0.orig/debian/liblightdm-qt-3-0.lintian-overrides	2019-07-10 22:34:59.0 +0200
+++ lightdm-1.26.0/debian/liblightdm-qt-3-0.lintian-overrides	1970-01-01 01:00:00.0 +0100
@@ -1,2 +0,0 @@
-# we do use -fstack-protector
-liblightdm-qt-3-0: hardening-no-stackprotector usr/lib/x86_64-linux-gnu/liblightdm-qt-3.so.0.0.0
diff -Naur lightdm-1.26.0.orig/debian/liblightdm-qt-3-0.symbols lightdm-1.26.0/debian/liblightdm-qt-3-0.symbols
--- lightdm-1.26.0.orig/debian/liblightdm-qt-3-0.symbols	2019-07-10 22:34:59.0 +0200
+++ lightdm-1.26.0/debian/liblightdm-qt-3-0.symbols	1970-01-01 01:00:00.0 +0100
@@ -1,72 +0,0 @@
-liblightdm-qt-3.so.0 liblightdm-qt-3-0 #MINVER#
- (c++|regex)"^.*::qt_metacall\(QMetaObject::Call, int, void[*][*]\)@Base$" 1.8.7
- (c++|regex)"^.*::qt_metacast\(char const[*]\)@Base$" 1.8.7
- (c++|regex)"^.*::staticMetaObject@Base$" 1.8.7
- (c++|regex)"^.*::metaObject\(\) const@Base$" 1.8.7
- (c++|regex)"^typeinfo for .*@Base$" 1.8.7
- (c++|regex)"^typeinfo name for .*@Base$" 1.8.7
- (c++|regex)"^vtable for .*@Base$" 1.8.7
- (c++)"QLightDM::UsersModel::UsersModel(QObject*)@Base" 1.8.7
- (c++)"QLightDM::UsersModel::~UsersModel()@Base" 1.8.7
- (c++)"QLightDM::SessionsModel::SessionsModel(QLightDM::SessionsModel::SessionType, QObject*)@Base" 1.8.7
- (c++)"QLightDM::SessionsModel::SessionsModel(QObject*)@Base" 1.8.7
- (c++)"QLightDM::SessionsModel::~SessionsModel()@Base" 1.8.7
- (c++)"QLightDM::PowerInterface::canRestart()@Base" 1.8.7
- (c++)"QLightDM::PowerInterface::canSuspend()@Base" 1.8.7
- (c++)"QLightDM::PowerInterface::canShutdown()@Base" 1.8.7
- (c++)"QLightDM::PowerInterface::canHibernate()@Base" 1.8.7
- (c++)"QLightDM::PowerInterface::PowerInterfacePrivate::PowerInterfacePrivate()@Base" 1.8.7
- (c++)"QLightDM::PowerInterface::restart()@Base" 1.8.7
- (c++)"QLightDM::PowerInterface::suspend()@Base" 1.8.7
- (c++)"QLightDM::PowerInterface::shutdown()@Base" 1.8.7
- (c++)"QLightDM::PowerInterface::hibernate()@Base" 1.8.7
- (c++)"QLightDM::PowerInterface::PowerInterface(QObject*)@Base" 1.8.7
- (c++)"QLightDM::PowerInterface::~PowerInterface()@Base" 1.8.7
- (c++)"QLightDM::Greeter::showPrompt(QString, QLightDM::Greeter::PromptType)@Base" 1.8.7
- (c++)"QLightDM::Greeter::connectSync()@Base" 1.8.7
- 

Bug#935988: buster-pu: package reportbug/7.5.2+nmu1~deb10u1

[Adam D. Barratt]

On Wed, 2019-08-28 at 19:52 +0200, Andreas Beckmann wrote:
> reportbug/buster does not know about buster being stable ...
> 
> I've just uploaded a fix to unstable via DELAYED/2, so it should be
> in
> unstable before the weekend, still hoping for a maintainer upload.

That happened.

[...]
> I'll upload this to DELAYED/2, too.

Will you be updating and/or reversioning the pu to reflect the
maintainer upload?

Regards,

Adam

Bug#875087: [phonon-backend-gstreamer] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Sat, Sep 09, 2017 at 10:18:38PM +0200, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Source: phonon-backend-gstreamer
> Version: 4:4.9.0-1
> Severity: wishlist
> User: debian-qt-...@lists.debian.org
> Usertags: qt4-removal
> 
> 
> Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> as [announced] in:

With the removal of src:kde4libs, there are no reverse deps of the Qt4
packages of phonon-backend-gstreamer, patch attached to drop them.

Cheers,
Moritz
diff -Naur phonon-backend-gstreamer-4.9.1.orig/debian/control phonon-backend-gstreamer-4.9.1/debian/control
--- phonon-backend-gstreamer-4.9.1.orig/debian/control	2019-07-30 07:26:24.0 +0200
+++ phonon-backend-gstreamer-4.9.1/debian/control	2019-08-29 20:18:01.483076445 +0200
@@ -13,12 +13,8 @@
libglib2.0-dev,
libgstreamer-plugins-base1.0-dev,
libgstreamer1.0-dev,
-   libphonon-dev (>= 4:4.7.1~),
libphonon4qt5-dev (>= 4:4.7.1~),
libphonon4qt5experimental-dev (>= 4:4.7.1~),
-   libphononexperimental-dev (>= 4:4.7.1~),
-   libqt4-dev (>= 4:4.8.1),
-   libqt4-opengl-dev (>= 4:4.8.1),
libqt5opengl5-dev,
libqt5x11extras5-dev (>= 5.2.0~),
libxml2-dev,
@@ -47,29 +43,6 @@
  .
  This package contains icons used by Phonon and Phonon4Qt5 backends.
 
-Package: phonon-backend-gstreamer
-Architecture: any
-Multi-Arch: same
-Provides: phonon-backend
-Pre-Depends: ${misc:Pre-Depends}
-Depends: gstreamer1.0-alsa [linux-any] | gstreamer1.0-audiosink,
- gstreamer1.0-plugins-base,
- gstreamer1.0-pulseaudio,
- phonon-backend-gstreamer-common (= ${binary:Version}),
- ${misc:Depends},
- ${shlibs:Depends}
-Recommends: gstreamer1.0-plugins-good
-Suggests: gstreamer1.0-plugins-ugly
-Description: Phonon GStreamer 1.0 backend
- This package contains GStreamer 1.0 backend for Phonon multimedia
- framework. It transparently adapts and reroutes all requests from Phonon
- applications to the GStreamer framework which in turn performs requested
- audio/video decoding/capture tasks.
- .
- You should install gstreamer1.0-plugins-good to get support for playing
- popular free multimedia formats and gstreamer1.0-plugins-ugly to get support
- for popular MPEG audio formats like MP3.
-
 Package: phonon4qt5-backend-gstreamer
 Architecture: any
 Multi-Arch: same
diff -Naur phonon-backend-gstreamer-4.9.1.orig/debian/phonon-backend-gstreamer.install phonon-backend-gstreamer-4.9.1/debian/phonon-backend-gstreamer.install
--- phonon-backend-gstreamer-4.9.1.orig/debian/phonon-backend-gstreamer.install	2016-06-06 21:29:58.0 +0200
+++ phonon-backend-gstreamer-4.9.1/debian/phonon-backend-gstreamer.install	1970-01-01 01:00:00.0 +0100
@@ -1,2 +0,0 @@
-usr/lib/*/qt4/plugins/phonon_backend/phonon_gstreamer.so
-usr/share/kde4/services/phononbackends/gstreamer.desktop
diff -Naur phonon-backend-gstreamer-4.9.1.orig/debian/rules phonon-backend-gstreamer-4.9.1/debian/rules
--- phonon-backend-gstreamer-4.9.1.orig/debian/rules	2016-06-06 21:29:58.0 +0200
+++ phonon-backend-gstreamer-4.9.1/debian/rules	2019-08-29 20:14:51.963932199 +0200
@@ -5,33 +5,27 @@
 include /usr/share/pkg-kde-tools/qt-kde-team/2/debian-qt-kde.mk
 
 override_dh_auto_configure:
-	$(overridden_command) -B obj-qt4 -- -DPLUGIN_INSTALL_DIR=/usr/lib/$(DEB_HOST_MULTIARCH)/qt4/
 	$(overridden_command) -B obj-qt5 -- \
 	  -DPLUGIN_INSTALL_DIR=/usr/lib/$(DEB_HOST_MULTIARCH)/qt5/ \
 	  -DPHONON_BUILD_PHONON4QT5=ON
 
 override_dh_auto_build:
-	$(overridden_command) -B obj-qt4
 	$(overridden_command) -B obj-qt5
 
 override_dh_auto_install:
-	$(overridden_command) -B obj-qt4
 	$(overridden_command) -B obj-qt5
 
 override_dh_install:
 	$(overridden_command) --fail-missing
 
 override_dh_auto_clean:
-	$(overridden_command) -B obj-qt4
 	$(overridden_command) -B obj-qt5
 
 override_dh_shlibdeps:
 	$(overridden_command) -- -xphonon
 
 override_dh_auto_test:
-	$(overridden_command) -B obj-qt4
 	$(overridden_command) -B obj-qt5
 
 override_dh_strip:
-	$(overridden_command) -pphonon-backend-gstreamer --dbgsym-migration='phonon-backend-gstreamer-dbg (<= 4:4.9.0-1~~)'
 	$(overridden_command) -pphonon4qt5-backend-gstreamer --dbgsym-migration='phonon4qt5-backend-gstreamer-dbg (<= 4:4.9.0-1~~)'

Bug#935588: ceph 12.2.11+dfsg1-2.1+b1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 935588 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: ceph
Version: 12.2.11+dfsg1-2.1+b1

Explanation: rebuild against new libbabeltrace

Bug#935588: gdb 8.2.1-2+b1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 935588 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: gdb
Version: 8.2.1-2+b1

Explanation: rebuild against new libbabeltrace

Bug#935588: gdb-mingw-w64 10.8+b2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 935588 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: gdb-mingw-w64
Version: 10.8+b2

Explanation: rebuild against new libbabeltrace

Bug#920900: pkgdata in icu-devtools(63.2-2) pkg on deb10 stable still use icu-config

[Gregory Auzanneau]

Dear Maintainer,

As you confirm icu-config is now deprecated.

But pkgdata in icu-devtools(63.2-2) on deb10 stable is still referring 
to icu-config :

$ pkgdata -p bin_mkltfs -m static packagelist.txt
sh: 1: icu-config: not found
sh: 1: icu-config: not found
pkgdata: icu-config: No icu-config found. (fix PATH or use -O option)
 required parameter is missing: -O is required for static and shared 
builds.

Run 'pkgdata --help' for help.

icu-63.2/source/tools/pkgdata/pkgdata.cpp :
line 2137 -> 2172 :
/* Try calling icu-config directly to get the option file. */
 static int32_t pkg_getOptionsFromICUConfig(UBool verbose, UOption 
*option) {

#if U_HAVE_POPEN
LocalPipeFilePointer p;
size_t n;
static char buf[512] = "";
icu::CharString cmdBuf;
UErrorCode status = U_ZERO_ERROR;
const char cmd[] = "icu-config --incpkgdatafile";
char dirBuf[1024] = "";
/* #1 try the same path where pkgdata was called from. */
findDirname(progname, dirBuf, UPRV_LENGTHOF(dirBuf), );
if(U_SUCCESS(status)) {
  cmdBuf.append(dirBuf, status);
  if (cmdBuf[0] != 0) {
cmdBuf.append( U_FILE_SEP_STRING, status );
  }
  cmdBuf.append( cmd, status );

  if(verbose) {
fprintf(stdout, "# Calling icu-config: %s\n", cmdBuf.data());
  }
  p.adoptInstead(popen(cmdBuf.data(), "r"));
[...]

On http://userguide.icu-project.org/howtouseicu, there is an 
recommendation about that :
pkgdata uses the icu-config script in order to locate pkgdata.inc. If 
you are not building ICU using the supplied tools, you may need to 
modify this file directly to allow static and dll modes to function.


Thanks for the good job, keep up with it !
Grégory

Bug#932361: [gnome flashback] gnome-desktop-flashback does not start

[Dmitry Shachnev]

Control: reassign -1 linux-image-4.19.0-6-amd64-unsigned 4.19.67-1

Hi Joachim,

On Thu, Aug 29, 2019 at 07:17:19PM +0200, Joachim Schmidt wrote:
> Hi Dmitry,
>
> ~/.local/share/applications is empty
> sometime I can start gnome-flashback but today there was a crash again (only
> press of RESET button continues). time at 18:53

Thanks for the log that you sent me in private.

It looks like you have problems with the kernel, not with GNOME Flashback.

I am attaching the relevant part of your log and reassigning the bug to linux.

--
Dmitry Shachnev
Aug 29 18:53:14 merkur kernel: [   28.084991] [ cut here 
]
Aug 29 18:53:14 merkur kernel: [   28.084999] NETDEV WATCHDOG: enp0s7 
(forcedeth): transmit queue 0 timed out
Aug 29 18:53:14 merkur kernel: [   28.085040] WARNING: CPU: 1 PID: 0 at 
net/sched/sch_generic.c:461 dev_watchdog+0x20d/0x220
Aug 29 18:53:14 merkur kernel: [   28.085042] Modules linked in: fuse devlink 
nf_tables tun nfnetlink pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) 
vboxdrv(OE) snd_hda_codec_via snd_hda_codec_generic snd_hda_intel snd_hda_codec 
edac_mce_amd snd_hda_core kvm_amd snd_hwdep ccp rng_core snd_pcm kvm irqbypass 
snd_timer snd pcspkr serio_raw soundcore k10temp sg asus_atk0110 evdev 
pcc_cpufreq acpi_cpufreq parport_pc ppdev lp parport ip_tables x_tables autofs4 
ext4 crc16 mbcache jbd2 fscrypto ecb crypto_simd cryptd glue_helper aes_x86_64 
sr_mod cdrom btrfs hid_generic usbhid hid xor zstd_decompress zstd_compress 
xxhash sd_mod raid6_pq libcrc32c crc32c_generic nouveau mxm_wmi wmi ata_generic 
video pata_amd i2c_algo_bit sata_nv ttm libata drm_kms_helper ohci_pci drm 
psmouse forcedeth ehci_pci ohci_hcd ehci_hcd usbcore scsi_mod usb_common
Aug 29 18:53:14 merkur kernel: [   28.085142]  i2c_nforce2 button
Aug 29 18:53:14 merkur kernel: [   28.085151] CPU: 1 PID: 0 Comm: swapper/1 
Tainted: G   OE 4.19.0-6-amd64 #1 Debian 4.19.67-1
Aug 29 18:53:14 merkur kernel: [   28.085153] Hardware name: System 
manufacturer System Product Name/M4N68T-M-V2, BIOS 100112/21/2011
Aug 29 18:53:14 merkur kernel: [   28.085160] RIP: 0010:dev_watchdog+0x20d/0x220
Aug 29 18:53:14 merkur kernel: [   28.085164] Code: 00 49 63 4e e0 eb 92 4c 89 
e7 c6 05 71 ea ad 00 01 e8 57 ba fc ff 89 d9 4c 89 e6 48 c7 c7 48 ea 2d 8b 48 
89 c2 e8 9d 0e a6 ff <0f> 0b eb c0 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 
0f 1f 44
Aug 29 18:53:14 merkur kernel: [   28.085167] RSP: 0018:9a41fbe43e90 
EFLAGS: 00010286
Aug 29 18:53:14 merkur kernel: [   28.085171] RAX:  RBX: 
 RCX: 0006
Aug 29 18:53:14 merkur kernel: [   28.085173] RDX: 0007 RSI: 
0092 RDI: 9a41fbe566b0
Aug 29 18:53:14 merkur kernel: [   28.085175] RBP: 9a41fafa845c R08: 
02ed R09: 0004
Aug 29 18:53:14 merkur kernel: [   28.085178] R10:  R11: 
0001 R12: 9a41fafa8000
Aug 29 18:53:14 merkur kernel: [   28.085180] R13: 0001 R14: 
9a41fafa8480 R15: 0001
Aug 29 18:53:14 merkur kernel: [   28.085183] FS:  () 
GS:9a41fbe4() knlGS:
Aug 29 18:53:14 merkur kernel: [   28.085186] CS:  0010 DS:  ES:  CR0: 
80050033
Aug 29 18:53:14 merkur kernel: [   28.085188] CR2: 7f393800b340 CR3: 
000134b64000 CR4: 06e0
Aug 29 18:53:14 merkur kernel: [   28.085190] Call Trace:
Aug 29 18:53:14 merkur kernel: [   28.085196]  
Aug 29 18:53:14 merkur kernel: [   28.085204]  ? pfifo_fast_enqueue+0x110/0x110
Aug 29 18:53:14 merkur kernel: [   28.085209]  call_timer_fn+0x2b/0x130
Aug 29 18:53:14 merkur kernel: [   28.085215]  run_timer_softirq+0x3d1/0x410
Aug 29 18:53:14 merkur kernel: [   28.085221]  ? 
__hrtimer_run_queues+0x130/0x280
Aug 29 18:53:14 merkur kernel: [   28.085226]  ? ktime_get+0x3a/0xa0
Aug 29 18:53:14 merkur kernel: [   28.085232]  __do_softirq+0xde/0x2d8
Aug 29 18:53:14 merkur kernel: [   28.085239]  irq_exit+0xba/0xc0
Aug 29 18:53:14 merkur kernel: [   28.085244]  
smp_apic_timer_interrupt+0x74/0x140
Aug 29 18:53:14 merkur kernel: [   28.085249]  apic_timer_interrupt+0xf/0x20
Aug 29 18:53:14 merkur kernel: [   28.085251]  
Aug 29 18:53:14 merkur kernel: [   28.085257] RIP: 
0010:native_safe_halt+0xe/0x10
Aug 29 18:53:14 merkur kernel: [   28.085261] Code: ff ff 7f c3 65 48 8b 04 25 
40 5c 01 00 f0 80 48 02 20 48 8b 00 a8 08 75 c4 eb 80 90 e9 07 00 00 00 0f 00 
2d 76 c0 4d 00 fb f4  90 e9 07 00 00 00 0f 00 2d 66 c0 4d 00 f4 c3 90 90 0f 
1f 44 00
Aug 29 18:53:14 merkur kernel: [   28.085263] RSP: 0018:ae29c06abea8 
EFLAGS: 0246 ORIG_RAX: ff13
Aug 29 18:53:14 merkur kernel: [   28.085267] RAX: 8ab2b880 RBX: 
0001 RCX: 8b44f350
Aug 29 18:53:14 merkur kernel: [   28.085269] RDX: 00016f36 RSI: 
8b44afb8 RDI: 0006895f45fc
Aug 29 18:53:14 merkur kernel: [   28.085271] RBP: 0001 R08: 
0002 R09: 

Bug#936072: RM: xflr5 -- RoQA; orphaned, depends on Qt4

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove xflr5. The version in the archive is very old (released
in 2013) and depends on Qt4. Recent releases do support Qt5, but noone
stepped up to maintain it during the last 2.5 years, so let's remove it.

Cheers,
Moritz

Bug#892102: Need a core dump

[sixerjman]

The inetd daemon runs as a systemd service, but lately I've been getting
the following message when it crashes with SIGABRT:

systemd-coredump[15585]: Resource limits disable core dumping for process
13098 (inetd).

How can the system be configured to allow a core dump to be taken? I have
core dumps
configured to 'unlimited' in '/etc/security/limits.conf', so I don't
understand why systemd-coredump
refuses to actually do it's job and take a core dump which can be analyzed
later.

Another question is how to the debugging symbols for libevent. There used
to be a package
'libevent-dbg' which provided the debug symbols but it is not available in
the testing ('bullseye')
or unstable distributions.

Bug#935977: RM: gnuplot [mipsel] -- ROM; FTBFS on deprecated platform (mipsel)

[Anton Gladky]

Hello Scott,

thanks for explanation and sorry for misunderstanding.
Yes I will try to fix thenFTBFSt, if it is possible.

Regard

Anton

Am Mi., 28. Aug. 2019 um 23:48 Uhr schrieb Scott Kitterman
:
>
> Mipsel is still a release architecture.  It's mips that was dropped.  Does 
> that change your mind about the rm?
>
> Scott K
>
> On August 28, 2019 3:42:15 PM UTC, Anton Gladky  wrote:
> >Package: ftp.debian.org
> >Severity: normal
> >
> >Dear FTP team,
> >
> >gnuplot fails to compile on mipsel. As this architecture
> >considered to be removed from official archs, I do not
> >see a motivation to fix it there.
> >
> >Thanks
> >
> >Anton

Bug#933330: Bug#903161: Same issue here; solution found

[Josh Triplett]

On Thu, Aug 29, 2019 at 01:08:32PM +0300, Timo Sirainen wrote:
> On 29 Aug 2019, at 3.57, Josh Triplett  wrote:
> > 
> > On Wed, Aug 28, 2019 at 05:43:27PM -0700, Josh Triplett wrote:
> >> So if the stats sockets don't exist at *all*, deliver won't complain.
> >> 
> >> To disable those stats sockets, add the following configuration to a
> >> file in /etc/dovecot/conf.d/ :
> > 
> > Update: sadly this doesn't fully work, as it produces the following
> > spurious errors in the logs:
> > 
> > Aug 28 17:54:27 cloud dovecot[3168]: imap-login: Error: 
> > net_connect_unix(/var/run/dovecot/stats-writer) failed: No such file or 
> > directory
> > Aug 28 17:54:27 cloud dovecot[3168]: auth: Error: 
> > net_connect_unix(/var/run/dovecot/stats-writer) failed: No such file or 
> > directory
> > Aug 28 17:54:27 cloud dovecot[3168]: auth: Error: stats: 
> > open(old-stats-user) failed: No such file or directory
> > Aug 28 17:54:28 cloud dovecot[3168]: auth: Error: 
> > net_connect_unix(/var/run/dovecot/stats-writer) failed: No such file or 
> > directory
> > Aug 28 17:54:28 cloud dovecot[3168]: auth-worker(3182): Error: stats: 
> > open(old-stats-user) failed: No such file or directory
> > Aug 28 17:54:28 cloud dovecot[3168]: imap: Error: 
> > net_connect_unix(/var/run/dovecot/stats-writer) failed: No such file or 
> > directory
> > 
> > So while deliver has no problem ignoring such errors, the rest of
> > dovecot unfortunately doesn't like that configuration.
> > 
> > I'd like to have a "disable all stats" configuration, rather than having
> > to make a stats socket available to the user running deliver.
> 
> Add to dovecot.conf: stats_writer_socket_path=

Interesting! I'll try that and see how it goes.

Bug#701903: Issue incorrectly tagged fixed-upstream

[Simon McVittie]

Control: tags -1 - fixed-upstream
Control: forwarded -1 https://gitlab.gnome.org/GNOME/gimp/issues/535

On Thu, 29 Aug 2019 at 17:15:00 +, segfault wrote:
> This bug was tagged as fixed-upstream, but the upstream issue wasn't
> actually fixed, it was merely moved to GitLab.
> 
> The old upstream issue: http://bugzilla.gnome.org/show_bug.cgi?id=679622
> The new upstream issue (still open):
> https://gitlab.gnome.org/GNOME/gimp/issues/535

GNOME/gimp#535 looks like the right bug for Bugzilla #724130 and Debian
#701903; fixing the metadata accordingly.

You mentioned Bugzilla #679622, but that looks like an unrelated bug
(which was also migrated to Gitlab, this time as GNOME/gimp#412).

smcv

Bug#934457: installation in chroot failing with Unknown device "/dev/fuse": No such device

[Tyler Weldon]

Hello,

The issue is in the command:

udevadm test --action -p  $(udevadm info -q path -n /dev/fuse)

the -p flag is being seen as a parameter to the --action flag, which is not
a valid action.

Per the udevadm man page:

*-c*, *--action=**ACTION*
Type of event to be triggered. Possible actions are "add", "remove",
"change", "move", "online", "offline", "bind", and "unbind". The default
value is "change".

Hope this helps.

Tyler Weldon
tylerweldo...@gmail.com
(609)-661-9396

Bug#701903: Issue incorrectly tagged fixed-upstream

[segfault]

This bug was tagged as fixed-upstream, but the upstream issue wasn't
actually fixed, it was merely moved to GitLab.

The old upstream issue: http://bugzilla.gnome.org/show_bug.cgi?id=679622
The new upstream issue (still open):
https://gitlab.gnome.org/GNOME/gimp/issues/535