Bug#905581: Mailing list for Salsa/Salsa-CI team

[Alexander Wirt]

On Mi, 17 Jul 2019, Otto Kekäläinen wrote:

> Hello!
> 
> There are now 10 people discussing "Licensing salsa-ci pipeline" in
> private thread that really should belong into a Debian mailing list.
> 
> Can you please create this list now?
> 
> If you think "debian-salsa-ci" is too small, then create a more
> generic "debian-salsa" list where also other Salsa usage and
> improvements can be discussed.
No, as I said I will create a debian-ci list as soon as I find time.

Alex

Bug#932073: closed by Niels Thykier (Bug#932073: fixed in debhelper 12.2.1)

[Helmut Grohne]

Control: reopen -1
Control: affects -1 + src:dropbear

On Tue, Jul 16, 2019 at 08:42:09PM +, Debian Bug Tracking System wrote:
>* dh_installinit: Fix regression where dh_installinit bailed
>  out on --name if only one of the acted on packages had an
>  init script file.  Thanks to Helmut Grohne for reporting
>  the issue.  (Closes: #932073)

The bug is partially fixed. A full build of openssh and dropbear now
works. At least the following situation (dropbar) is still broken:

The init script lives in an arch-all package, you pass the relevant
--name and you perform an arch-only build. Here is a cross build log,
but it fully reproduces natively:

http://crossqa.debian.net/build/dropbear_2019.78-1_mips_20190717050430.log

I'm also confused by the following message:

dh_link: No packages to build. Architecture mismatch: amd64, want: all any

It happens both during native and during cross builds of dropbear. I
would have assumed that "amd64" and "mips" match the "any" part of "all
any". I'd appreciate if someone could enlighten me about this aspect.

Helmut

Bug#905581: Mailing list for Salsa/Salsa-CI team

[Otto Kekäläinen]

Hello!

There are now 10 people discussing "Licensing salsa-ci pipeline" in
private thread that really should belong into a Debian mailing list.

Can you please create this list now?

If you think "debian-salsa-ci" is too small, then create a more
generic "debian-salsa" list where also other Salsa usage and
improvements can be discussed.

- Otto

Bug#932258: console-setup-freebsd: missing dependency

[Cyril Brulebois]

Hi Héctor,

Héctor Orón Martínez  (2019-07-17):
> Package: console-setup-freebsd
> Version: 1.191
> Severity: grave
> 
> 
> Dear Maintainer,
> 
>   console-setup-freebsd has a dependency on vidcontrol, which is not
> part of buster|bullseye|unstable, and causes the package to be
> uninstallable.

Adding debian-bsd@ to the loop for advise.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#931972: Bug#930637: unblock: monit/1:5.25.2-3+deb10u1

[Sebastiaan Couwenberg]

On 7/13/19 9:11 AM, Sebastiaan Couwenberg wrote:
> On 7/13/19 8:25 AM, Sergey B Kirpichev wrote:
>> On Sun, 7 Jul 2019 08:29:08 +0200 Sebastiaan Couwenberg  
>> wrote:
>>> Please upload a new revision to unstable with source-only changes...
>>
>> Backport for Buster:
>> https://mentors.debian.net/package/monit
>> Please sponsor this package.
> 
> I will sponsor the upload as soon a buster-backports accepts packages.
> 
> All the backports I uploaded today were rejected because source is not
> accepted yet.

buster-backports is now open, but the monit package cannot be uploaded
to it in its current shape.

The version is not correct: 5.26.0-1~bpo9+1

For buster-backports '~bpo10+1` should be used.

Beware that `dch --bpo` still defaults to stretch-backports on buster,
so you need to change the distribution and changelog entry to
buster-backports too.

The .orig.tar.gz is not available on mentors, and there is no
buster-backports branch in the repo on Salsa yet, so the package cannot
be built currently.

Please push the buster-backports branch to Salsa, I'll take it from there.

Kind Regards,

Bas

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

Bug#932258: console-setup-freebsd: missing dependency

[Héctor Orón Martínez]

Package: console-setup-freebsd
Version: 1.191
Severity: grave


Dear Maintainer,

  console-setup-freebsd has a dependency on vidcontrol, which is not part of 
buster|bullseye|unstable,
and causes the package to be uninstallable.

Regards

Bug#932257: libdbd-oracle-perl: unsatisfiable dependencies

[Héctor Orón Martínez]

Package: libdbd-oracle-perl
Version: 1.76-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

  libdbd-oracle-perl depends on oracle-instantclient12.1-basic | 
oracle-instantclient12.1-basiclite,
which are not found in buster|bullseye|unstable, causes the package to be 
unusable.

Regards

Bug#930904: closed by Salvatore Bonaccorso (Bug#930904: fixed in linux 4.9.184-1)

[Salvatore Bonaccorso]

Hi Julien,

On Wed, Jul 17, 2019 at 06:31:15AM +0200, Julien Aubin wrote:
> Hi,
> 
> Sadly the bug is still there for Buster. Could you re-open it please ?

That should actually not be done. The Debian BTS has the version
tracking in place, so for 4.19.37-5 it is still marked as unfixed even
if the bug status is done trigered by this acceptance into
stretch-proposed-updates by the 4.9.184-1 version. A bug can be closed
in multiple versions with the Debian BTS version tracking.

Then once the sid and buster upload is done, the bug will be marked as
fixed automatically as well for those versions.

Regards,
Salvatore

Bug#930904: closed by Salvatore Bonaccorso (Bug#930904: fixed in linux 4.9.184-1)

[Julien Aubin]

Hi,

Sadly the bug is still there for Buster. Could you re-open it please ?

Le mar. 16 juil. 2019 à 23:09, Debian Bug Tracking System
 a écrit :
>
> This is an automatic notification regarding your Bug report
> which was filed against the src:linux package:
>
> #930904: linux-image-4.19.0-5-amd64: Latest kernel upgrades on unstable break 
> Steam (link to fix included)
>
> It has been closed by Salvatore Bonaccorso .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Salvatore Bonaccorso 
>  by
> replying to this email.
>
>
> --
> 930904: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930904
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Salvatore Bonaccorso 
> To: 930904-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Tue, 16 Jul 2019 21:07:58 +
> Subject: Bug#930904: fixed in linux 4.9.184-1
> Source: linux
> Source-Version: 4.9.184-1
>
> We believe that the bug you reported is fixed in the latest version of
> linux, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 930...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Salvatore Bonaccorso  (supplier of updated linux package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Sat, 29 Jun 2019 09:29:10 +0200
> Binary: linux-doc-4.9 linux-headers-4.9.0-10-common 
> linux-headers-4.9.0-10-common-rt linux-manual-4.9 linux-source-4.9 
> linux-support-4.9.0-10
> Source: linux
> Architecture: all source
> Version: 4.9.184-1
> Distribution: stretch
> Urgency: medium
> Maintainer: Debian Kernel Team 
> Changed-By: Salvatore Bonaccorso 
> Closes: 866122 930904
> Description:
>  linux-doc-4.9 - Linux kernel specific documentation for version 4.9
>  linux-headers-4.9.0-10-common - Common header files for Linux 4.9.0-10
>  linux-headers-4.9.0-10-common-rt - Common header files for Linux 4.9.0-10-rt
>  linux-manual-4.9 - Linux kernel API manual pages for version 4.9
>  linux-source-4.9 - Linux kernel source for version 4.9 with Debian patches
>  linux-support-4.9.0-10 - Support files for Linux 4.9
> Changes:
>  linux (4.9.184-1) stretch; urgency=medium
>  .
>* New upstream stable update:
>  https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.9.169
>  - [x86] power: Fix some ordering bugs in __restore_processor_context()
>  - [amd64] power/64: Use struct desc_ptr for the IDT in struct 
> saved_context
>  - [i386] power/32: Move SYSENTER MSR restoration to 
> fix_processor_context()
>  - [x86] power: Make restore_processor_context() sane
>  - [ppc64el] powerpc/tm: Limit TM code inside PPC_TRANSACTIONAL_MEM
>  - [ppc64el] Fix invalid use of register expressions
>  - [ppc64el] powerpc/64s: Add barrier_nospec
>  - [ppc64el] powerpc/64s: Add support for ori barrier_nospec patching
>  - [ppc64el] Avoid code patching freed init sections
>  - [ppc64el] powerpc/64s: Patch barrier_nospec in modules
>  - [ppc64el] powerpc/64s: Enable barrier_nospec based on firmware settings
>  - [ppc64el] Use barrier_nospec in copy_from_user()
>  - [ppc64el] powerpc/64: Use barrier_nospec in syscall entry
>  - [ppc64el] powerpc/64s: Enhance the information in cpu_show_spectre_v1()
>  - [ppc64el] powerpc64s: Show ori31 availability in spectre_v1 sysfs file
>not v2
>  - [ppc64el] powerpc/64: Disable the speculation barrier from the command
>line
>  - [ppc64el] powerpc/64: Make stf barrier PPC_BOOK3S_64 specific.
>  - [ppc64el] powerpc/64: Add CONFIG_PPC_BARRIER_NOSPEC
>  - [ppc64el] powerpc/64: Call setup_barrier_nospec() from setup_arch()
>  - [ppc64el] powerpc/64: Make meltdown reporting Book3S 64 specific
>  - [ppc64el] asm: Add a patch_site macro & helpers for patching
>instructions
>  - [ppc64el] powerpc/64s: Add new security feature flags for count cache
>flush
>  - [ppc64el] powerpc/64s: Add support for software count cache flush
>  - [ppc64el] powerpc/pseries: Query hypervisor for count cache flush
>settings
>  - [ppc64el] powerpc/powernv: Query firmware for count cache flush
>settings
>  - [ppc64el] security: Fix spectre_v2 reporting
>  - [arm64] kaslr: Reserve size of ARM64_MEMSTART_ALIGN in linear region
>  - tty: ldisc: add sysctl to prevent autoloading of ldiscs
>  

Bug#857286: gst-plugins-good1.0: please recompile with --enable-v4l2-probe configure option

[Chen-Yu Tsai]

Dear Maintainers,

I second the proposal for enabling the V4L2 M2M Gstreamer plugins,

This is immediately usable on the Raspberry Pi's with their downstream
kernel that includes the bcm2835-codec V4L2 M2M stateful codec driver.
It would also be usable on Mediatek platforms, whose stateful codec
driver has been merged upstream as of kernel version 4.14. In addition,
a driver for Amlogic's VPU has been merged for Linux kernel 5.3,
initially supporting MPEG-1/2, but will be expanded to cover H.264,
MPEG-4 ASP, and MJPEG [1]. There are many more platforms already
supported upstream, though I'm not familiar with them.

It is more usable then FFmpeg's support for V4L2 M2M, which seems to
break under some corner cases.

The following patch (diff against buster source package version 1.14.4-1)
enables the feature for all Linux platforms. Please consider applying it.

Regards
ChenYu


[1] https://github.com/Elyotna/linux/commits/5.2/v4l2-m2m-pr


--- debian/rules.old2019-07-17 11:45:21.047971339 +0800
+++ debian/rules2019-07-17 11:22:50.010807527 +0800
@@ -86,6 +86,7 @@
 ifeq ($(DEB_HOST_ARCH_OS),linux)
 1394 = 
debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/gstreamer-$(gst_abi)/libgst1394.so
 video4linux2 = 
debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/gstreamer-$(gst_abi)/libgstvideo4linux2.so
+CONFIG_ARGS += --enable-v4l2-probe
 endif
 
 ifeq ($(DEB_HOST_ARCH_OS),hurd)


signature.asc
Description: PGP signature

Bug#932256: firefox: WM_CLASS changed in firefox 68 from 'Firefox' to 'firefox'

[terroreek]

Package: firefox
Version: 68.0-3
Severity: minor

Dear Maintainer,

Looks like in firefox 68 the WM_CLASS changed from Firefox to firefox.
However the /usr/share/applications/firefox.desktop file still has;
StartupWMClass=Firefox

this breaks docks like plank because the WM_CLASS is firefox.  Changing the
line to;
StartupWMClass=firefox

fixes the problem.  

-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox depends on:
ii  debianutils   4.8.6.2
ii  fontconfig2.13.1-2
ii  libasound21.1.8-1
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-10
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.16-1
ii  libdbus-glib-1-2  0.110-4
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-9
ii  libfontconfig12.13.1-2
ii  libfreetype6  2.9.1-3
ii  libgcc1   1:9.1.0-8
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.58.3-3
ii  libgtk-3-03.24.5-1
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.21-1
ii  libnss3   2:3.45-1
ii  libpango-1.0-01.42.4-6
ii  libsqlite3-0  3.29.0-1
ii  libstartup-notification0  0.12-6
ii  libstdc++69.1.0-8
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.7-1
ii  libx11-xcb1   2:1.6.7-1
ii  libxcb-shm0   1.13.1-2
ii  libxcb1   1.13.1-2
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.5-1
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1+b3
ii  procps2:3.3.15-2
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages firefox recommends:
ii  libavcodec57  7:3.4.3-1
ii  libavcodec58  7:4.1.3-1

Versions of packages firefox suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.17-4
ii  libgtk2.0-02.24.32-3
ii  pulseaudio 12.2-4

-- no debconf information

Bug#926131: why not apply it?

[Paul Wise]

On Wed, Jul 17, 2019 at 10:36 AM Thomas Lange wrote:

> I looked at the patch, and cannot see any problems it should
> produce. I would just apply it. Any objections?

There are some problems with it:

It needs testing to ensure that it builds fine and looks fine, no-one
has done that yet.

It changes the identi.ca link from an image to text, so that might not
fit with the current layout where we use an image for each of planet &
identica. Perhaps we should drop the planet image too for consistency
with the Debian blog link and other links in that section. Of course
with the new front page layout coming

It drops the alt text of the image, I think that should probably move
to a title tag.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#266914: cannot reproduce

[Thomas Lange]

I cannot produce this but with 1:8.11+urwcyr1.0.7~pre44-4.4 from
buster, so please close this bug.

-- 
regards Thomas

Bug#932255: valgrind.1: False indentation caused by lack of '.RE' macros

[Bjarni Ingi Gislason]

Package: valgrind
Version: 1:3.15.0-1
Severity: minor

Dear Maintainer,

   * What led up to the situation?

  Warnings from "man valgrind", with

MANOPT=-E latin1 --no-hyphenation --warnings=w --no-justification
MANWIDTH=80
MAN_KEEP_STDERR=yes

  and  file "~/.manpath" containing:

DEFINE  troff   test-groff -mandoc -rF=0
DEFINE  nroff   test-nroff -mandoc -rF=0

  [ "test-groff" is a script in the groff repository ]

  and with an own extra test "an-end-check":

troff: :1521: warning [p 21, 9.7i]: can't break line
troff: :1652: warning [p 22, 9.7i]: can't break line
troff: :2851: warning [p 37, 9.8i]: can't break line
troff: :2856: warning [p 37, 10.3i]: can't break line
troff: :2861: warning [p 37, 10.8i]: can't break line
troff: :2866: warning [p 38, 0.2i]: can't break line
troff: :2871: warning [p 38, 0.7i]: can't break line
an-end-check:: Warning: Different number of .RS and .RE calls, 
an-RS-open=16 at end of file

###

  Inspection of the original file, "valgrind/docs/xml/manual-core.xml"
shows for example (line 2647-):

Each line shows:
  
U: total user time
W: total wallclock time
CPU: overall average cpu use
EvC: number of event checks.  An event
 check is a backwards branch in the simulated program, so this is a
 measure of forward progress of the program
TIn: number of code blocks instrumented
  by the JIT
TOut: number of instrumented code
  blocks that have been thrown away
#thr: number of threads in the
program
  
  
  Other lines with "" show, that a " ... " block
is used inside the " ... " block to get a correct
output.

  So this "para"-block construct has to be added to the "listitem" blocks
that lack it.

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

Kernel: Linux 4.19.37-5 (SMP w/2 CPU cores)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE=is_IS.iso88591 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages valgrind depends on:
ii  libc6  2.28-10
ii  libc6-dbg  2.28-10

Versions of packages valgrind recommends:
ii  gdb   8.2.1-2
pn  valgrind-dbg  

Versions of packages valgrind suggests:
pn  alleyoop  
pn  kcachegrind   
pn  valgrind-mpi  
pn  valkyrie  

-- no debconf information

-- 
Bjarni I. Gislason

Bug#926131: why not apply it?

[Thomas Lange]

I looked at the patch, and cannot see any problems it should
produce. I would just apply it. Any objections?
-- 
regards Thomas

Bug#390190: texlive-base: Better dependency chains

[Norbert Preining]

On Mon, 15 Jul 2019, Hilmar Preuße wrote:
> - texlive-fonts-extra dep on texlive-fonts-recommended
> - texlive-generic-extra dep on texlive-generic-recommended

I can imagine people having only extra installed without recommended,
for very specific purposes. So leaving out, but also adding the deps,
both are fine with me.

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#932254: missing Xorg unix socket file after boot (appears after xserver restart)

[Jiri Novak]

Package: xserver-xorg
Version: 7.7+19
Hello,
i've got an issue with missing Xserver unix sockets after boot.
After boot, unix socket in /tmp/.X11-unix/X0 is missing, even if
specifically invoked with -listen unix (in my case, in slim.conf). Full
command in my case is then "/usr/lib/xorg/Xorg -listen unix vt07 -auth
/var/run/slim.auth"
ctrl-alt-backspace or simply killing the pid makes it restart and the
socket then appears properly.

i was suspecting there was issue with mounting of /tmp by systemd late,
but that seems not to be the case and i run out of ideas where to look
for the cause of the bug. Attaching log for reference, but i didn't see
there anything relevant either.
I'm not 100% sure which version started to cause it, as i noticed it
after dist-upgrading about a month ago somewhere within 9.x (it is still
present after dist-upgrading to 10), but i was using a tcp socket
workaround at that time.
Regards,
Gh.

[71.186] 
X.Org X Server 1.20.4
X Protocol Version 11, Revision 0
[71.186] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian
[71.186] Current Operating System: Linux LX-novak 4.19.0-5-amd64 #1 SMP 
Debian 4.19.37-5 (2019-06-19) x86_64
[71.186] Kernel command line: BOOT_IMAGE=/vmlinuz-4.19.0-5-amd64 
root=ZFS=D-ssd/V4242-gws/hypervisor/D0-LX_novak ro quiet apparmor=0
[71.186] Build Date: 05 March 2019  08:11:12PM
[71.186] xorg-server 2:1.20.4-1 (https://www.debian.org/support) 
[71.186] Current version of pixman: 0.36.0
[71.186]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[71.186] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[71.187] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Jul 17 02:46:04 
2019
[71.189] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[71.190] (==) No Layout section.  Using the first Screen section.
[71.190] (==) No screen section available. Using defaults.
[71.190] (**) |-->Screen "Default Screen Section" (0)
[71.190] (**) |   |-->Monitor ""
[71.190] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[71.190] (==) Automatically adding devices
[71.190] (==) Automatically enabling devices
[71.190] (==) Automatically adding GPU devices
[71.190] (==) Max clients allowed: 256, resource mask: 0x1f
[71.192] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[71.192]Entry deleted from font path.
[71.192] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist.
[71.192]Entry deleted from font path.
[71.192] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist.
[71.192]Entry deleted from font path.
[71.193] (WW) The directory "/usr/share/fonts/X11/100dpi" does not exist.
[71.193]Entry deleted from font path.
[71.193] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist.
[71.193]Entry deleted from font path.
[71.193] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/Type1,
built-ins
[71.193] (==) ModulePath set to "/usr/lib/xorg/modules"
[71.193] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[71.193] (II) Loader magic: 0x561978276e20
[71.193] (II) Module ABI versions:
[71.193]X.Org ANSI C Emulation: 0.4
[71.193]X.Org Video Driver: 24.0
[71.193]X.Org XInput driver : 24.1
[71.193]X.Org Server Extension : 10.0
[71.194] (++) using VT number 7

[71.194] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[71.194] (II) xfree86: Adding drm device (/dev/dri/card0)
[71.211] (--) PCI:*(0@0:2:0) 8086:5916:17aa:224b rev 2, Mem @ 
0xf100/16777216, 0xe000/268435456, I/O @ 0xe000/64, BIOS @ 
0x/131072
[71.211] (II) LoadModule: "glx"
[71.213] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[71.223] (II) Module glx: vendor="X.Org Foundation"
[71.223]compiled for 1.20.4, module version = 1.0.0
[71.223]ABI class: X.Org Server Extension, version 10.0
[71.223] (==) Matched modesetting as autoconfigured driver 0
[71.223] (==) Matched fbdev as autoconfigured driver 1
[71.223] (==) Matched vesa as autoconfigured driver 2
[71.223] (==) Assigned the driver to the xf86ConfigLayout
[71.223] (II) LoadModule: "modesetting"
[71.223] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[71.224] (II) Module modesetting: vendor="X.Org Foundation"
[71.224]compiled for 1.20.4, module version = 1.20.4
[71.224]Module class: X.Org Video 

Bug#932253: /usr/lib/dovecot/maildirlock does complains about no timeout given (although I did give it one)

[Jeronimo Pellegrini]

Package: dovecot-core
Version: 1:2.3.4.1-5
Severity: normal
Tags: upstream

Hello,

After upgrading a server to buster, dovecot was upgraded to
1:2.3.4.1-5, and /usr/lib/dovecot/maildirlock now complains
that it did not get a timeout parameter (although I did pass
the argument).

How to reproduce:

Create a maildir somewhere.

$ /usr/lib/dovecot/maildirlock PATH_TO_MAILDIR 100
Panic: BUG: No IOs or timeouts set. Not waiting for infinity.
6169Error: Raw backtrace: /usr/lib/dovecot/libdovecot.so.0(+0xdb13b) 
[0x7fe73d3e313b] -> /usr/lib/dovecot/libdovecot.so.0(+0xdb171) [0x7fe73d3e3171] 
-> /usr/lib/dovecot/libdovecot.so.0(+0x4a001) [0x7fe73d352001] -> 
/usr/lib/dovecot/libdovecot.so.0(+0xf070c) [0x7fe73d3f870c] -> 
/usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0x36) 
[0x7fe73d3faae6] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0x4c) 
[0x7fe73d3f968c] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_run+0x40) 
[0x7fe73d3f97f0] -> /usr/lib/dovecot/maildirlock(main+0x1bd) [0x55761fb7741d] 
-> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7fe73d0fc09b] -> 
/usr/lib/dovecot/maildirlock(_start+0x2a) [0x55761fb7752a]

The "6169" before the "Error" string is the PID of the program that
holds the lock.

I expected it to work as it did before the upgrade -- it would
only return the PID.

I also tried
$ /usr/lib/dovecot/maildirlock PATH_TO_MAILDIR 100

from two different terminals, at roughly the same time, and both
succeeded (I expected the second to have to wait before the first
one finished, after 100 seconds -- this was the behavior before
the upgrade).

Also triedon a sid box (same version), just to check if any different
libs would make a difference, but found the same bug.

maildirlock is documented in Dovecot's manual, in this page:
https://wiki2.dovecot.org/Plugins/Zlib

Thank you!
J.

-- Package-specific info:

dovecot configuration
-
# 2.3.4.1 (f79e8e7e4): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.4 ()
# OS: Linux 4.19.0-5-amd64 x86_64 Debian bullseye/sid 
# Hostname: socrates.lan
mail_location = mbox:~/mail:INBOX=/var/mail/%u
mail_privileged_group = mail
namespace inbox {
  inbox = yes
  location = 
  mailbox Drafts {
special_use = \Drafts
  }
  mailbox Junk {
special_use = \Junk
  }
  mailbox Sent {
special_use = \Sent
  }
  mailbox "Sent Messages" {
special_use = \Sent
  }
  mailbox Trash {
special_use = \Trash
  }
  prefix = 
}
passdb {
  driver = pam
}
ssl_cert = 
pn  dovecot-imapd 
pn  dovecot-ldap  
pn  dovecot-lmtpd 
pn  dovecot-lucene
pn  dovecot-managesieved  
pn  dovecot-mysql 
pn  dovecot-pgsql 
pn  dovecot-pop3d 
pn  dovecot-sieve 
pn  dovecot-solr  
pn  dovecot-sqlite
pn  dovecot-submissiond   
ii  ntp   1:4.2.8p13+dfsg-2

Versions of packages dovecot-core is related to:
ii  dovecot-core [dovecot-common]  1:2.3.4.1-5
pn  dovecot-dev
pn  dovecot-gssapi 
pn  dovecot-imapd  
pn  dovecot-ldap   
pn  dovecot-lmtpd  
pn  dovecot-managesieved   
pn  dovecot-mysql  
pn  dovecot-pgsql  
pn  dovecot-pop3d  
pn  dovecot-sieve  
pn  dovecot-sqlite 

Bug#863045: at: interactively please print parsed time at start

[Jose M Calhariz]

Hi,

I am working in a new release of at and I have a draft of this
feature.  If you are interested in beta testing it, I can prepare a
package for most releases of Debian on i386 ou amd64.

Kind regards
Jose M Calhariz

-- 
--
Se quer construir algo do nada, comece amando intensamente
seus pensamentos e sua imaginação. Um grande caminho começa
com o primeiro passo. O resto fica por conta das
circunstancias.


signature.asc
Description: PGP signature

Bug#932252: cleanup of /intro/organization

[Thomas Lange]

Package: www.debian.org


I like to clean up /intro/organization, esp. remove some content.
We have to much content on this page, much old and outdated
content. We could move some content to other pages.

My suggestion is:

- remove item Development Projects
- remove item  Individual Packages — @packages.debian.org ,
  since the page it links to will be removed
- remove the whole Ports — GNU/Linux section. These are only links to
  mailing list.
- maybe move the mailing list under User support to /support
- Debian women lists some members that left the Debian project years
  ago. ping someone to update the members list.
- remove item Consultants Page
- remove item CD Vendors Page
- remove item LDAP Developer Directory Administrator
- remove item Package Tracking System
- remove move section Debian Pure Blends. IMO blends are like
  ports. It's not a suborganization of Debian, and there's no need to
  list people involved in it.

-- 
regards Thomas

Bug#932251: buster-pu: package spl-linux/0.7.12-2+deb10u1

[Aron Xu]

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

Dear release team,

We would like to apply a single-line patch in addition to spl-linux/0.7.12-2
which fixes a deadlock[1], please see the changes in debdiff.

[1]https://github.com/zfsonlinux/spl/commit/cb4464f1549087794fdbe0f5ad2328618de2033e

Regards,
Aron


signature.asc
Description: PGP signature

Bug#932049: chromium: aw snap on linkedin.com

[Doug Bell]

I also get an "Aw, snap!" error (appears to be the same bug) when
visiting the  web page.

Downgrading to chromium 73.0.3683.75-1 solves the problem.

-Doug

Bug#912576: network-manager: doesn't show nor autoconnect to hidden wifi

[Jiri Novak]

can confirm, after dist-upgrading from debian 9 to 10, NM stopped
autoconnecting hidden wifis. nmcli con up name works.

adding hidden=yes under [wifi] in the network config file (as hinted on
nm irc) didn't help either.




signature.asc
Description: OpenPGP digital signature

Bug#902449: cryptsetup-initramfs: auto-detection of zfs pool(s)

[Jiri Novak]

Hi,


with current 2.1.0-5 in buster, dist-upgrade of encrypted zfs root
installations fails to boot. took me some while to find this hintwith
the initramfs in crypttab (my original solution was to bring cryptsetup
packages form stretch, noticed this randomly later)




signature.asc
Description: OpenPGP digital signature

Bug#913904: redsocks: Transparent proxy traffic no longer works on Debian Buster

[Apollon Oikonomopoulos]

Control: tags -1 unreproducible moreinfo

Hi,

On 14:06 Fri 16 Nov , Clauzio Cristiano Perpétuo wrote:
> Package: redsocks
> Version: 0.5-2
> Severity: normal
> 
> Dear Maintainer,
> 
> Transparent proxy traffic no longer works...
> 
> The same configuration, as recommended in the official documentation,
> worked on some previous updates. In the stable version (stretch) on the
> same network, the traffic is ok. The iptables rules are the same as the
> official documentation.
> 
> I do not know if the problem is in the redsocks package, the kernel version
> or the iptables version.

Apologies for the late response. Unfortunately, I cannot reproduce this 
bug, as forwarding seems to work in my case. If I had to guess, I would 
probably say your issue is due to the iptables/nftables migration and 
you ended up having loaded both, iptables-legacy and iptables-nft rules, 
which leads to unpredictable behavior. Please let me know if you are 
still seeing this issue.

Regards,
Apollon

Bug#134606: will remove /devel/people

[Thomas Lange]

we decided to remove /devel/people.

See also 657647 and 727738

-- 
regards Thomas

Bug#657647: removing this page

[Thomas Lange]

On the web sprint in 3/2019 we decided that the /devel/people page is
of no real use and that we will remove it. See also
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=251218#15

-- 
regards Thomas

Bug#932103: RFP: fuidshift -- remap a filesystem tree to shift one set of UID/GID ranges to another

[Vincent Tondellier]

On Tuesday 16 July 2019 23:11:24 Florian Weimer wrote:
> * Nicholas D. Steeves:
> > Package name: fuidshift
> > Version : 3.0
> > Upstream Author : Name 
> > URL : https://github.com/lxc/lxd/tree/master/fuidshift
> > License : Apache 2.0
> > Programming Lang: Go
> > Description : remap a filesystem tree to shift one set of UID/GID
> > ranges to another

...

> How does this compare to (or interact with) newuidmap and newgidmap
> from uidmap?

They do very different things.

Let me try a short description :
newuidmap - set the uid mapping of a user namespace (from manpage)
fuidshift - shift the uid/gid of files *on disk*

fuidshift is basically a recursive
chown $(( $(stat -c '%u' "$path") + $uidshift )) "$path"

It does not use or configure user namespaces or containers.

It's useful for the creation of containers images, for example when the 
container root filesystem is read-only (squashfs) and the container engine 
can't change the uids at runtime (see for example systemd-nspawn --private-
users=pick / --private-users-chown).

So fuidshift may be used to prepare a directory for later use by newuidmap, 
but that's about it.

> There's a push to force uidmap on everyone, with tight integration
> into NSS.  If there's a competing scheme, it would be helpful to know
> about it.

Bug#932250: linux-image-amd64: adding segfault data

[m . alfaeko]

Package: linux-image-amd64
Version: 4.19+105
Followup-For: Bug #932250

adding file with segfault data

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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)

Versions of packages linux-image-amd64 depends on:
ii  linux-image-4.19.0-5-amd64  4.19.37-5

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

-- no debconf information
xfdesktop[11344]: segfault at 16 ip 7ff9fd0f29ea sp 7b934f00 error 
4 in libglib-2.0.so.0.5800.3[7ff9fd0a2000+7e000]
2019-07-17T01:04:04.589422+02:00 debian kernel: [18604.040877] Code: 8d 48 ff 
48 89 c3 49 89 ce 49 c1 e6 04 4c 01 f5 48 8b 45 00 48 85 c0 0f 84 c3 00 00 00 
48 8b 58 08 48 85 db 0f 84 fe 01 00 00 <48> 8b 13 48 89 50 08 48 8b 45 08 48 85 
c0 74 08 48 83 e8 01 48 89
xfdesktop[16727]: segfault at 16 ip 7fe22e9aa9ea sp 7ffd313bc000 error 
4 in libglib-2.0.so.0.5800.3[7fe22e95a000+7e000]
2019-07-17T01:04:07.231175+02:00 debian kernel: [18606.685725] Code: 8d 48 ff 
48 89 c3 49 89 ce 49 c1 e6 04 4c 01 f5 48 8b 45 00 48 85 c0 0f 84 c3 00 00 00 
48 8b 58 08 48 85 db 0f 84 fe 01 00 00 <48> 8b 13 48 89 50 08 48 8b 45 08 48 85 
c0 74 08 48 83 e8 01 48 89
gmain[16752]: segfault at 17 ip 7fdada99a9ea sp 7fdad7f7c7c0 error 4 in 
libglib-2.0.so.0.5800.3[7fdada94a000+7e000]
2019-07-17T01:04:21.214468+02:00 debian kernel: [18620.669154] Code: 8d 48 ff 
48 89 c3 49 89 ce 49 c1 e6 04 4c 01 f5 48 8b 45 00 48 85 c0 0f 84 c3 00 00 00 
48 8b 58 08 48 85 db 0f 84 fe 01 00 00 <48> 8b 13 48 89 50 08 48 8b 45 08 48 85 
c0 74 08 48 83 e8 01 48 89
gmain[16974]: segfault at 1c ip 7f3b5dcc29ea sp 7f3b5b2a45f0 error 4 in 
libglib-2.0.so.0.5800.3[7f3b5dc72000+7e000]
2019-07-17T01:05:28.070894+02:00 debian kernel: [18687.524814] Code: 8d 48 ff 
48 89 c3 49 89 ce 49 c1 e6 04 4c 01 f5 48 8b 45 00 48 85 c0 0f 84 c3 00 00 00 
48 8b 58 08 48 85 db 0f 84 fe 01 00 00 <48> 8b 13 48 89 50 08 48 8b 45 08 48 85 
c0 74 08 48 83 e8 01 48 89

Bug#885890: at: permissions of /var/spool/cron/atjobs/ are to strict

[Jose M Calhariz]

Hi,

I been thinking on your solution but I am not certain that is secure.
So for now I think the best solution is to enhance the atq command.
If you are interested I accept patches for the at.c code.

Kind regards
Jose M Calhariz

-- 
--
Se quer construir algo do nada, comece amando intensamente
seus pensamentos e sua imaginação. Um grande caminho começa
com o primeiro passo. O resto fica por conta das
circunstancias.


signature.asc
Description: PGP signature

Bug#924888: current status

[Thomas Lange]

Currently /misc only links to two more subpages,
misc/awards and misc/merchandise

-- 
regards Thomas

Bug#931818: Info received (Bug#931818: cups: Jobs webpage /usr/lib/cups/cgi-bin/jobs.cgi segfault after package login removes /etc/securetty)

[Bernhard Übelacker]

Hello Jeffrey Hundstad,
your supplied backtrace would most likely look with debug symbols like this:

(gdb) bt
#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:79
#1  0x77dcbdae in __GI___strdup () at strdup.c:41
#2  0xb795 in cgiGetArray () at var.c:171
#3  0xa41c in cgi_copy () at template.c:299
#4  0xad3e in cgi_copy () at template.c:348
#5  0xa626 in cgi_copy () at template.c:602
#6  0xb0b7 in cgiCopyTemplateLang () at template.c:148
#7  0x868d in cgiShowJobs () at ipp-var.c:1506
#8  0x67c1 in main () at jobs.c:107
#9  0x77d6809b in __libc_start_main () at ../csu/libc-start.c:308
#10 0x687a in _start ()

But still, the backtrace from a gdb running at your system with
installed debug symbols would most probably show some more information,
and which name in cgiGetArray gets accessed.

Kind regards,
Bernhard

Bug#932250: linux-image-amd64: random segfaults without taking something down

[m . alfaeko]

Package: linux-image-amd64
Version: 4.19+105
Severity: important

Hi.

Im currently running debian buster kernel and i experienced some segfaults.
Segfaults are random, which prevents me from pinpointing the trigger.
First i tried disabling overcommit on memory, the behavior stoped.
Today it started during installing updates for libreoffice. Two first
segfaults were caused by xfdesktop, the two more with gmain.
Another odd thing is that the error is in libglib and the code is completly
identical. The RAM was tested with memtest86+, memtester. Previous release
with backport kernel was working perfectly even with overcommit. I
guess there is a small chance of defective hw.
My next suspect is apparmor. Im going to use the system with disabled
apparmor to see if this problem persist.

Thank you

I hope this helps make debian more stable and reliable.

Have a nice day

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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)

Versions of packages linux-image-amd64 depends on:
ii  linux-image-4.19.0-5-amd64  4.19.37-5

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

-- no debconf information

Bug#805602: at doesn't understand "at now + 1 second" etc.

[Jose M Calhariz]

Do you still interested in this bug?  I would well come a patch on how
to handle seconds in the input.  I am prepaeing a new release of at
and would like to add this feature.

Kind regards
Jose M Calhariz


-- 
--
Para que ocorra um tiro a queima roupa é necessário que a vítima esteja vestida?


signature.asc
Description: PGP signature

Bug#932249: yeroth-erp-3.0-standalone: Missing yeroth-erp-3.0-standalone -- POS + ERP software

[Xavier NOUMBISSI NOUNDOU]

Package: yeroth-erp-3.0-standalone
Version: 3.0
Severity: wishlist

Dear Maintainer,

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

   * What led up to the situation?
I develop this software myself for 3 years now

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
This is an free enterprise resource planing software (with a 
point-of-sale interface),
 and also an inventory stock management interface.

   * What was the outcome of this action?
Have this free software as standard program within Debian stable
(https://github.com/xnoumbissinoundou/yeroth-erp-3.0)

   * What outcome did you expect instead?
Have a Debian mentor

Xavier NOUMBISSI NOUNDOU, Ph.D. (ABD), Waterloo, ON, 2011


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

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

Versions of packages yeroth-erp-3.0-standalone depends on:
ii  cups 2.2.1-8+deb9u3
ii  latex-cjk-all4.8.4+git20150701-2
ii  latex-cjk-common 4.8.4+git20150701-2
ii  latexdiff1.1.1-2
ii  latexmk  1:4.41-1
ii  libqt5core5a 5.7.1+dfsg-3+deb9u1
ii  libqt5dbus5  5.7.1+dfsg-3+deb9u1
ii  libqt5gui5   5.7.1+dfsg-3+deb9u1
ii  libqt5network5   5.7.1+dfsg-3+deb9u1
ii  libqt5sql5   5.7.1+dfsg-3+deb9u1
ii  libqt5sql5-mysql 5.7.1+dfsg-3+deb9u1
ii  libqt5test5  5.7.1+dfsg-3+deb9u1
ii  libqt5widgets5   5.7.1+dfsg-3+deb9u1
ii  libtexlua52  2016.20160513.41080.dfsg-2+deb9u1
ii  libtexluajit22016.20160513.41080.dfsg-2+deb9u1
ii  libusb-1.0-0 2:1.0.21-1
ii  mariadb-client   10.1.38-0+deb9u1
ii  mariadb-server   10.1.38-0+deb9u1
ii  qt5-doc  5.7.1-2
ii  qt5-style-plugins5.0.0+git16.g7aa4764-1
ii  texlive  2016.20170123-5
ii  texlive-base 2016.20170123-5
ii  texlive-bibtex-extra 2016.20170123-5
ii  texlive-binaries 2016.20160513.41080.dfsg-2+deb9u1
ii  texlive-extra-utils  2016.20170123-5
ii  texlive-font-utils   2016.20170123-5
ii  texlive-fonts-extra  2016.20170123-5
ii  texlive-fonts-recommended2016.20170123-5
ii  texlive-formats-extra2016.20170123-5
ii  texlive-full 2016.20170123-5
ii  texlive-games2016.20170123-5
ii  texlive-generic-extra2016.20170123-5
ii  texlive-generic-recommended  2016.20170123-5
ii  texlive-htmlxml  2016.20170123-5
ii  texlive-humanities   2016.20170123-5
ii  texlive-latex-base   2016.20170123-5
ii  texlive-latex-extra  2016.20170123-5
ii  texlive-latex-recommended2016.20170123-5
ii  texlive-luatex   2016.20170123-5
ii  texlive-metapost 2016.20170123-5
ii  texlive-music2016.20170123-5
ii  texlive-omega2016.20170123-5
ii  texlive-pictures 2016.20170123-5
ii  texlive-plain-extra  2016.20170123-5
ii  texlive-pstricks 2016.20170123-5
ii  texlive-publishers   2016.20170123-5
ii  texlive-science  2016.20170123-5
ii  texlive-xetex2016.20170123-5

yeroth-erp-3.0-standalone recommends no packages.

yeroth-erp-3.0-standalone suggests no packages.

-- no debconf information

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

[Brad Warren]

Package: python3-acme
Version: 0.28.0-1~deb9u1

The python*-acme packages will no longer work with Let’s Encrypt’s “ACMEv2” 
endpoint which is their RFC 8555 compliant endpoint starting November 1st. See 
https://community.letsencrypt.org/t/acme-v2-scheduled-deprecation-of-unauthenticated-resource-gets/74380
 for more details about this change.

This change will make the python*-acme packages unusable with this endpoint 
which will break any software using the library for this purpose. The impact of 
this which will affect the most users is probably the impact on Certbot where 
the client will no longer be able to obtain new certificates with the default 
ACME server (which almost everyone uses). This would mean that the TLS 
certificates currently being automatically renewed by Certbot on Debian Stretch 
will expire causing TLS failures.

As one of the upstream maintainers of this library, I would recommend 
backporting the python*-acme packages from Debian Buster to Stretch to fix this 
problem as these packages have been well tested and there are no breaking API 
changes between versions.

Bug#931895: [b...@transient.nz: Bug#931895: unzip: zip bomb false positives in Java ecosystem]

[Adler, Mark]

All,

Ok, I looked into it. Those jar files are seriously messed up. Any 
self-respecting unzipper would be well within its rights to reject them as 
invalid. As it turns out, my patch to unzip is doing exactly what it’s supposed 
to. Something that processed those jar files has a bug.

In each of those .jar files there are several entries that are duplicated in a 
screwy way. First, those entries each have an exactly duplicated central 
directory entry, with the same file name, pointing to the same local header 
offset in the jar file. You can see this even using an unpatched unzip, asking 
it to unzip the jar file. It will extract a bunch of files, and then ask you if 
you’d like to replace a file it just unzipped when it encounters the duplicated 
central directory entry.

The fact that two central directory entries are pointing to the same local 
header is what is, rightly, setting off the zip bomb detection in the patched 
unzip.

Second, the other screwy thing is that there are a bunch of vestigial blocks of 
data in those jar files that are not referred to by any central directory 
entry. I presume that those are the data for those same files that were 
intended to be pointed to by the duplicated central directory entries, but were 
orphaned when the offsets to the local headers were not changed for those 
entries. Of course, even if the offsets had been changed so that all the data 
in the jar file were actually used, it would still be invalid due to having the 
same names appear more than once.

The bug that resulted in these jar files might be even more serious if the 
duplicated entries are pointing to a previous version of those entries, and 
what was intended was to update those entries to what is now in the orphaned 
vestigial regions. Hopefully that’s not that the case.

In summary, those jar files are grossly invalid zip files for three reasons: 1. 
The same name appears twice, 2. Two central directory entries point to the same 
local header (setting off zip bomb detection), and 3. There is an orphaned 
chunk of the file that is not referred to by any central directory header.

As one example, all three of those things each occur 115 times in 
asm-5.0.3-sources.jar, out of 261 original central directory entries. Were it 
to be fixed, that jar file would have 146 unique entries, and would be quite a 
bit smaller. Which in addition to being invalid is also unfortunate and 
inefficient, since compression is kinda the point of the zip format.

Mark



> On Jul 12, 2019, at 8:23 PM, Adler, Mark  wrote:
> 
> Ben,
> 
> Ah, no, I did not test the jar files. I just did, and indeed I am seeing the 
> reported zip bomb detections.
> 
> Thanks. I’ll look into it.
> 
> Mark
> 
> 
>> On Jul 12, 2019, at 3:22 PM, Ben Caradoc-Davies  wrote:
>> 
>> On 13/07/2019 04:32, Adler, Mark wrote:
>>> I downloaded the four false-positive zip files from the bugreport page, and 
>>> none of them showed a zip bomb error (or any other error).
>> 
>> Mark,
>> 
>> the zip bomb error is seen when unzipping the 17 jar files contained within 
>> the four zip files. Did you test these inner jar files? I used (in bash):
>> 
>> $ for f in *.jar; do echo $f; unzip -tq $f; done
>> 
>> The outer zip files are there because many email filters block all email 
>> with jar attachments, and Debian BTS is email-based.
>> 
>> It would also be nice if unzip reported the filename when rejecting a 
>> suspected zip bomb, as it does when reporting "No errors detected".
>> 
>> Kind regards,
>> 
>> -- 
>> Ben Caradoc-Davies 
>> Director
>> Transient Software Limited 
>> New Zealand
> 

Bug#932135: [Pkg-puppet-devel] Bug#932135: puppetdb can't create/upgrade its DB schema past version 65 with postgres-11 11.4-1

[Apollon Oikonomopoulos]

Control: tags -1 confirmed upstream fixed-upstream
Control: severity -1 important
Control: clone -1 -2
Control: reassign -2 postgresql-11
Control: tags -2 upstream
Control: found -2 11.4-1
Control: affects -2 puppetdb
Control: severity -2 serious
Control: forwarded -2 
https://www.postgresql.org/message-id/15865-17940eacc8f8b081%40postgresql.org
Control: retitle -2 ALTER TABLE statements causing "relation already exists" 
errors when some indexes exist

Hi,

On 13:46 Mon 15 Jul , Gabriel Filion wrote:
> Hi there!
> 
> I've hit a bug with a new installation of puppetdb on buster (e.g. I've
> re-created my puppetmaster vagrant box) where puppetdb would fail to start,
> erroring out on an SQL upgrade of the database schema during the first service
> start.
> 
> I'll include the error log lower down since it's pretty long.
> 
> I've found a bug report on pupperware (puppet packaged up in docker 
> containers)
> that describes exactly the same problem, identifies a faulty postgresql 9.6.x
> version and seems to point to an upstream bug report that contains a fix.
> 
> https://github.com/puppetlabs/pupperware/issues/82
> 
> Since in buster we're using postgresql-11, we've had to identify which version
> had introduced the problem. I'm not sure about the exact minor version of
> postgres, but for certain when downgrading the debian package to postgres-11
> version 11.3-1, then puppetdb is able to start and complete its schema 
> upgrade.
> So the bug must have been introduced somewhere between 11.3 and 11.4
> 
> The upstream bug report says that there might be a fix for puppetdb available:
> 
> https://tickets.puppetlabs.com/browse/PDB-4422
> 
> It might be interesting to test applying the fix from the most appropriate
> branch (I'm not sure whether 6.0 or 6.3 makes more sense) and then test a new
> install with postgresql-11 version 11.4-1 to see if it goes through the schema
> upgrade successfully.

Thanks for the report and detailed information! According to 
https://ci.debian.net/packages/p/puppetdb/testing/amd64/, PuppetDB broke 
with postgresql-common/202, however it's really postgresql-11 11.4 that 
broke things while fixing CVE-2019-10164[1].

I'm inclined to say "this is a PostgreSQL bug", but there's no clear 
resolution from the Postgres side yet. PuppetDB upstream has already 
fixed this and the patch is trivial, so I'll prepare an upload to 
unstable to make it work again. However, I won't be filing for a stable 
update yet; instead, let's clone this bug as a PostgreSQL one and see 
what the Postgres maintainers say.

Cheers,
Apollon

[1] 
https://www.postgresql.org/message-id/15865-17940eacc8f8b081%40postgresql.org

Bug#912860: Don't ship libgtk2-perl in Bullseye

[intrigeri]

olly just nicely explained me on IRC a few things about the
autoremoval machinery and how it affects removing from testing
libgtk2-perl and its reverse-dependencies:

 - A set of RC buggy packages that have no reverse-deps outside of
   this set, should all be autoremoved together at some point, as long
   as they're not key packages, which are immune to autoremoval:
   https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

 - libgtk2-perl is on the list of key packages because it's installed
   on many machines ("popcon"). It's the last we can remove because
   all other packages that I've made RC-buggy today are
   reverse-dependencies of it.

 - Once everything else is gone, we'll need to ask for libgtk2-perl
   to lose its "key package" status and be removed from testing.

Bug#931774: RFS: paho.mqtt.c/1.3.0-1 [ITP] -- Eclipse Paho MQTT C client library

[Roman Ondráček]

Dear Mr Iwamatsu,

The problems have been fixed.

Yours sincerely,
Roman Ondráček

Dne 16. 07. 19 v 3:21 Nobuhiro Iwamatsu napsal(a):
> HI again,
> 
> Your package has some warning of dh_missing.
> 
> dh_missing: usr/CONTRIBUTING.md exists in debian/tmp but is not
> installed to anywhere
> dh_missing: usr/README.md exists in debian/tmp but is not installed to 
> anywhere
> dh_missing: usr/notice.html exists in debian/tmp but is not installed
> to anywhere
> dh_missing: usr/edl-v10 exists in debian/tmp but is not installed to anywhere
> dh_missing: usr/epl-v10 exists in debian/tmp but is not installed to anywhere
> 
>   I think that this file can ignore using debian/not-installed.
> 
> dh_missing: usr/samples/MQTTClient_publish_async.c exists in
> debian/tmp but is not installed to anywhere
> dh_missing: usr/samples/paho_cs_sub.c exists in debian/tmp but is not
> installed to anywhere
> dh_missing: usr/samples/MQTTAsync_publish.c exists in debian/tmp but
> is not installed to anywhere
> dh_missing: usr/samples/paho_c_pub.c exists in debian/tmp but is not
> installed to anywhere
> dh_missing: usr/samples/paho_cs_pub.c exists in debian/tmp but is not
> installed to anywhere
> dh_missing: usr/samples/pubsub_opts.c exists in debian/tmp but is not
> installed to anywhere
> dh_missing: usr/samples/MQTTAsync_subscribe.c exists in debian/tmp but
> is not installed to anywhere
> dh_missing: usr/samples/paho_c_sub.c exists in debian/tmp but is not
> installed to anywhere
> dh_missing: usr/samples/MQTTClient_publish.c exists in debian/tmp but
> is not installed to anywhere
> dh_missing: usr/samples/MQTTClient_subscribe.c exists in debian/tmp
> but is not installed to anywhere
> dh_missing: usr/bin/MQTTClient_publish_async exists in debian/tmp but
> is not installed to anywhere
> dh_missing: usr/bin/MQTTClient_publish exists in debian/tmp but is not
> installed to anywhere
> dh_missing: usr/bin/MQTTClient_subscribe exists in debian/tmp but is
> not installed to anywhere
> dh_missing: usr/bin/MQTTAsync_subscribe exists in debian/tmp but is
> not installed to anywhere
> dh_missing: usr/bin/MQTTVersion exists in debian/tmp but is not
> installed to anywhere
> dh_missing: usr/bin/MQTTAsync_publish exists in debian/tmp but is not
> installed to anywhere
> 
>   I think that this file should be included in paho.mqtt.c-examples
> package or other package.
> 
> Please fix this.
> And static libraries has '-static' suffix. please remove this.
> 
> 
> $ ls debian/tmp/usr/lib/x86_64-linux-gnu/libpaho-mqtt3*.a -1
> debian/tmp/usr/lib/x86_64-linux-gnu/libpaho-mqtt3a-static.a
> debian/tmp/usr/lib/x86_64-linux-gnu/libpaho-mqtt3as-static.a
> debian/tmp/usr/lib/x86_64-linux-gnu/libpaho-mqtt3c-static.a
> debian/tmp/usr/lib/x86_64-linux-gnu/libpaho-mqtt3cs-static.a
> 
> 
> Best regards,
>   Nobuhiro
> 
> 2019年7月16日(火) 7:23 Roman Ondráček :
>>
>> Dear Mr Iwamatsu,
>>
>> The problems was fixed.
>>
>> Yours sincerely,
>> Roman Ondráček
>>
>> Dne 15. 07. 19 v 2:05 Nobuhiro Iwamatsu napsal(a):
>>> Hi,
>>>
>>> 2019年7月15日(月) 7:30 Roman Ondráček :

 Dear Mr Iwamatsu,

 I am not sure if you received my answer on your comment on the site
 mentors.debian.net because I replied you via comment on the site
 mentors.debian.net.

 It should be fixed in the latest upload where I uploaded the forgotten
 source tarball.
>>>
>>> Thanks, I can download all files from mentors.debian.net.
>>> And I noticed two problem.
>>>
>>> debian/control:
>>>
>>>We does not need libc6-dev (>= 2.19.18) in Build-Depends.
>>>This is provided in the build-essential package.
>>>
>>> debian/changelog:
>>>
>>>   Please squash changelog from -1 and -3.
>>>   There are changelogs up to -3 now, but put them together. Packages 
>>> uploaded to
>>>   mentrors are not included in the package as Debian yet.
>>>
>>> Best regards,
>>>   Nobuhiro
>>>
>>
> --
> Nobuhiro Iwamatsu
>iwamatsu at {nigauri.org / debian.org}
>GPG ID: 40AD1FA6
> 

Bug#932246: printer-driver-hpcups: no more printing to a HP LaserJet 1320: stack smashing detected and hpcups crashed on signal 6

[Francesco Poli (wintermute)]

Package: printer-driver-hpcups
Version: 3.18.12+dfsg0-2
Severity: important

Dear Debian Printing Team,
I have a small i386 box (Soekris net5501) running testing (buster before
July the 6th, 2019, now bullseye) and connected to a HP LaserJet 1320
printer via USB cable.

The printer is configured via the following command lines:

  # lpadmin -p lj -E \
-v 'usb://HP/LaserJet%201320%20series?serial=00CNFW522KS9' \
-m drv:///hpijs.drv/hp-laserjet_1320-hpijs.ppd \
-o pdftops-renderer-default=pdftops \
-L local -D "HP LaserJet 1320"
  # lpoptions -p lj -o media=A4 -o sides=two-sided-long-edge
  # lpadmin -d lj

The setup has worked fine until July the 9th (that is to say, even
after the first bullseye package upgrades): during that day,
I printed a PDF file without issues.

After that, I went on upgrading the box for about a week:


[UPGRADE] tzdata:i386 2019a-1 -> 2019b-1

[UPGRADE] chrony:i386 3.4-4 -> 3.5-2
[UPGRADE] dirmngr:i386 2.2.12-1 -> 2.2.13-2
[UPGRADE] gnupg:i386 2.2.12-1 -> 2.2.13-2
[UPGRADE] gnupg-l10n:i386 2.2.12-1 -> 2.2.13-2
[UPGRADE] gnupg-utils:i386 2.2.12-1 -> 2.2.13-2
[UPGRADE] gnupg2:i386 2.2.12-1 -> 2.2.13-2
[UPGRADE] gpg:i386 2.2.12-1 -> 2.2.13-2
[UPGRADE] gpg-agent:i386 2.2.12-1 -> 2.2.13-2
[UPGRADE] gpg-wks-client:i386 2.2.12-1 -> 2.2.13-2
[UPGRADE] gpg-wks-server:i386 2.2.12-1 -> 2.2.13-2
[UPGRADE] gpgconf:i386 2.2.12-1 -> 2.2.13-2
[UPGRADE] gpgsm:i386 2.2.12-1 -> 2.2.13-2
[UPGRADE] gpgv:i386 2.2.12-1 -> 2.2.13-2
[UPGRADE] libnewt0.52:i386 0.52.20-8 -> 0.52.21-1
[UPGRADE] libsystemd0:i386 241-5 -> 241-6
[UPGRADE] libudev1:i386 241-5 -> 241-6
[UPGRADE] nano:i386 3.2-3 -> 4.3-1
[UPGRADE] openssh-client:i386 1:7.9p1-10 -> 1:8.0p1-3
[UPGRADE] openssh-server:i386 1:7.9p1-10 -> 1:8.0p1-3
[UPGRADE] openssh-sftp-server:i386 1:7.9p1-10 -> 1:8.0p1-3
[UPGRADE] udev:i386 241-5 -> 241-6
[UPGRADE] whiptail:i386 0.52.20-8 -> 0.52.21-1

[UPGRADE] libassuan0:i386 2.5.2-1 -> 2.5.3-2
[UPGRADE] libedit2:i386 3.1-20181209-1 -> 3.1-20190324-1
[UPGRADE] libgpg-error0:i386 1.35-1 -> 1.36-2
[UPGRADE] libpci3:i386 1:3.5.2-1 -> 1:3.6.2-2
[UPGRADE] pciutils:i386 1:3.5.2-1 -> 1:3.6.2-2
[UPGRADE] usbutils:i386 1:010-3 -> 1:012-1

[REMOVE, NOT USED] libip4tc0:i386 1.8.2-4
[REMOVE, NOT USED] libip6tc0:i386 1.8.2-4
[INSTALL, DEPENDENCIES] libip4tc2:i386 1.8.3-2
[INSTALL, DEPENDENCIES] libip6tc2:i386 1.8.3-2
[UPGRADE] base-files:i386 10.3 -> 11
[UPGRADE] iptables:i386 1.8.2-4 -> 1.8.3-2
[UPGRADE] libiptc0:i386 1.8.2-4 -> 1.8.3-2
[UPGRADE] libnftnl11:i386 1.1.2-2 -> 1.1.3-2
[UPGRADE] libsystemd0:i386 241-6 -> 241-6+b1
[UPGRADE] libudev1:i386 241-6 -> 241-6+b1
[UPGRADE] libxtables12:i386 1.8.2-4 -> 1.8.3-2
[UPGRADE] login:i386 1:4.5-1.1 -> 1:4.7-1
[UPGRADE] passwd:i386 1:4.5-1.1 -> 1:4.7-1
[UPGRADE] startpar:i386 0.61-1 -> 0.63-1
[UPGRADE] udev:i386 241-6 -> 241-6+b1

[UPGRADE] bzip2:i386 1.0.6-9.1 -> 1.0.6-9.2
[UPGRADE] exim4:i386 4.92-8 -> 4.92-9
[UPGRADE] exim4-base:i386 4.92-8 -> 4.92-9
[UPGRADE] exim4-config:i386 4.92-8 -> 4.92-9
[UPGRADE] exim4-daemon-light:i386 4.92-8 -> 4.92-9
[UPGRADE] info:i386 6.5.0.dfsg.1-4+b1 -> 6.6.0.dfsg.1-2
[UPGRADE] install-info:i386 6.5.0.dfsg.1-4+b1 -> 6.6.0.dfsg.1-2
[UPGRADE] iproute2:i386 4.20.0-2 -> 5.2.0-1
[UPGRADE] libbz2-1.0:i386 1.0.6-9.1 -> 1.0.6-9.2
[UPGRADE] libgnutls-dane0:i386 3.6.7-4 -> 3.6.8-2
[UPGRADE] libgnutls30:i386 3.6.7-4 -> 3.6.8-2
[UPGRADE] manpages:i386 4.16-2 -> 5.01-1
[UPGRADE] rsyslog:i386 8.1901.0-1 -> 8.1907.0-1
[UPGRADE] runit-helper:i386 2.8.6 -> 2.8.13.2


Yesterday, I tried to print a PDF file and I found out that
the hpcups crashed and printing was no longer possible.

Even a simple 

  $ echo hello | lpr

generates a print job that never vanishes:

  $ lpq
  lj is ready
  RankOwner   Job File(s) Total Size
  1st unknown 348 unknown 1024 bytes

but the data seem to never reach the printer and
/var/log/cups/error_log shows the following error messages:


E [16/Jul/2019:23:08:14 +0200] [Job 348] Job stopped due to filter errors; 
please consult the /var/log/cups/error_log file for details.
D [16/Jul/2019:23:08:14 +0200] [Job 348] The following messages were recorded 
from 11:08:01 PM to 11:08:14 PM
D [16/Jul/2019:23:08:14 +0200] [Job 348] Applying default options...
D [16/Jul/2019:23:08:14 +0200] [Job 348] Adding start banner page "none".
D [16/Jul/2019:23:08:14 +0200] [Job 348] Queued on "lj" by "USER".
D [16/Jul/2019:23:08:14 +0200] [Job 348] Auto-typing file...
D [16/Jul/2019:23:08:14 +0200] [Job 348] Request file type is text/plain.
D [16/Jul/2019:23:08:14 +0200] [Job 348] File of type text/plain queued by 
"USER".
D [16/Jul/2019:23:08:14 +0200] [Job 348] Adding end banner page "none".
D [16/Jul/2019:23:08:14 +0200] [Job 348] 

Bug#676129: texlive: pdflatex generates an invalid pdf if a particular combination of images are inluded

[Thomas Caswell]

I no longer have access to that system and can not reproduce this issue on
a up-to-date version of latex, I think this issue can be closed.

As a maintainer of a largish OS project, I am professionally impresed with
your dilligance in following up on this!

Tom

On Mon, Jul 15, 2019 at 3:59 AM Hilmar Preuße  wrote:

> On 05.06.12 00:48, Thomas A Caswell wrote:
>
> Hi Thomas,
>
> > These are test cases for a very strange interaction I found with
> > texlive 2012, garphix, pdflatex, a png, and a pdf.  All files needed
> > to reproduce the bug are at
> >
> > https://github.com/tacaswell/pdflatex_bug
> >
> I've compiled your non-working document using pdflatex from oldstable
> and Debian unstable. In both cases the document can be displayed fine
> using gv, evince and current Adobe Reader on Windows.
>
> Are you still able to reproduce or can we close the issue?
>
> Hilmar
> --
> sigfault
> #206401 http://counter.li.org
>
>

-- 
Thomas Caswell
tcasw...@gmail.com

Bug#932245: RFS: ffmpegfs/1.8-1 [ ITP] -- read-only FUSE filesystem which transcodes between audio and video formats on the fly

[Norbert Schlia]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "ffmpegfs", hoping to find someone 
who's interested:

Package name: ffmpegfs
Version : 1,8-1
Upstream Author : Norbert schliansch...@oblivion-software.de
URL :https://github.com/nschlia/ffmpegfs
License : GPL
Section : mutimedia

  It builds those binary packages:

ffmpegfs - read-only FUSE filesystem which transcodes between audio and video 
formats on the fly

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

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


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

  dget 
-xhttps://mentors.debian.net/debian/pool/main/f/ffmpegfs/ffmpegfs_1.8-1.dsc

  More information about ffmpegfs can be obtained 
fromhttps://nschlia.github.io/ffmpegfs/html/index.html.

  Changes since the last upload:

  * First time upload, still missing out on some fixes for packaging.

--
*Oblivion Software Development and Internet Services*
Norbert Schlia
Hans-Thoma-Str. 24
76327 Pfinztal
Germany

Telefon:0721 47 05 1112
Fax:0721 47 05 1113
Mobile: 0178 5365230
Steuernr.:  3411/44460


/www: http://www.oblivion-software.eu//

/Pour le Respect de l'Environnement : merci d'éviter d'imprimer ce 
message./
/Rispetto per l'ambiente: Si prega di evitare di stampare questo 
messaggio./
/Пожалуйста, не печатайте это письмо - защита окружающей среды в наших 
руках./
/Por favor, ten en cuenta el medio ambiente antes de imprimir este 
mensaje./

/With regard to the environment: Please avoid printing this message./
/Aus Rücksicht auf die Umwelt drucken Sie bitte diese Nachricht nicht aus./

Bug#932210: Fwd: Bug#932210: libimage-exiftool-perl: Exiftool does not start

[Salvatore Bonaccorso]

hi,

On Tue, Jul 16, 2019 at 11:09:50PM +0200, Pierre AUSSAGUEL wrote:
> Le 16/07/2019 à 21:16, Salvatore Bonaccorso a écrit :
> > This is actually not needed that you create a symlink.
> > /usr/bin/exiftool is provided by the package. But you previously
> > invoked in the sheell having probably a preference of /usr/local/bin
> > before /usr/bin. I guess after removing the file you did not invoked
> > hash -r in bash to forget the remembered locations of a command? (see
> > hash under SHELL BUILTIN COMMANDS in bash(1)).
> 
> I removed the symlink and ran the command hash -r
> It works just as expected
> 
> Thank you for your help.

You are welcome!

> I wonder what lead to this problem, since I stay with a stable debian and
> dont remember having installed exiftool by other means than apt or aptitude
> 
> At a certain moment the location of exiftool binary has changed. In this
> case the package libimage-exiftool-perl or the package manager itself should
> have removed the old binary and invoqued the hash command.

Are you sure you haven't installed it once locally directly from
source, via CPAN or other mechanism?

Debian package managment will never install it into /usr/local/bin so
this soulds like  have been a local installation (or in worst case a
bug in the package violating Debian policy).

Regards,
Salvatore

Bug#932244: ITP: libphp-easyrdf -- A PHP library for RDF

[Marco Villegas]

Package: wnpp
Version: 0.9.0
Severity: wishlist

* Package name: libphp-easyrdf
Version: 0.9.0
Upstream Author: Nicholas J Humfrey 
* URL : http://www.easyrdf.org/
* License: BSD-3-Clause
Description: EasyRdf is a PHP library designed to make it easy to
consume and produce RDF.
See https://github.com/njh/easyrdf

-Marco

Bug#931896: grub-efi-amd64: symbol `grub_file_filters` not found

[Colin Watson]

On Tue, Jul 16, 2019 at 11:08:25PM +0200, MiloMak wrote:
>Updated from 2.02+dfsg1-20 to 2.04-1 like the op and get similar to the op
> 
>[1]https://i.imgur.com/jKYXOHs.png
> 
>when i downgrade back to 2.02 grub boots without issue. I have debian
>installed as:
>/dev/sdc1    /boot/efi
>/dev/sdc2    /                (/boot is here)
> 
>it has been working with:
># grep 'set root' /boot/grub/grub.cfg
>set root='hd2,msdos2'

To save time, I'd just like to point out that whatever "set root" says
in /boot/grub/grub.cfg is basically irrelevant here.  That describes the
expected location of GRUB's modules, but it says nothing about where
grub-install is installing GRUB's core image nor about where the
firmware is loading GRUB from, and what matters here is that those last
two things need to match.

(It's also not interesting whether "set root" in your grub.cfg matches
the value of the "root" variable that you see at run-time.  The "set
root" command is just a fallback, and what usually takes effect instead
is the following "search" command which causes GRUB to try to find a
file system by UUID or similar.  On systems with multiple disks, it's
unsurprising for this to result in something different from the guessed
value.)

>i see you say that the problem is most probably caused by a
>misconfiguration.
> 
>what should i be checking and how do i fix it?

I think the only thing I can say to you is to repeat the advice I gave
in the message that you were replying to just now (that is,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931896#10).  You
should at least start by going through each one of those questions and
answering them.  Since you appear to have multiple disks, it seems quite
likely that the firmware might be booting from an EFI System Partition
that isn't the same as the one you have mounted on /boot/efi, and if so
then that's something you need to correct.

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

Bug#912870: Removing libgtk2-perl from testing

[intrigeri]

Control: severity -1 serious

Hi,

as announced on this bug report and on debian-devel@ in November 2018,
GTK 2 is going away in Bullseye, so I'm hereby bumping severity of
these bugs, on every reverse-dependency of libgtk2-perl, to RC.

I hope that upstream will port the code to GTK 3 in time for the
Bullseye freeze :)

References:

  https://bugs.debian.org/912860
  https://lists.debian.org/debian-devel/2018/11/msg00570.html
  
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=gtk2-removal;users=debian-p...@lists.debian.org

Cheers,
-- 
intrigeri

Bug#883571: [pkg-gnupg-maint] Bug#883571: Bug#883571: Unescaped left brace in regex is illegal here in regex; marked by <-- HERE in m/\${ <-- HERE ([^ \t=:+{}]+)}/ at /usr/bin/automake line 3930

[Daniel Kahn Gillmor]

On Thu 2017-12-07 16:24:46 -0500, Daniel Kahn Gillmor wrote:
> Can you suggest a patch that would have helped you to avoid the problem?

it's been a year and a half with no followup and debian bug #883571 is
still in a moreinfo,unreproducible state.  so i'm closing this bug
report.  If anyone has any suggestions for how to reproduce (or fix) it,
please don't hesitate to re-open it.

Regards,

--dkg


signature.asc
Description: PGP signature

Bug#932240: debhelper: no longer detects setgid binaries in dh_shlibdeps

[Niels Thykier]

Control: tags -1 serious

James Cowgill:
> Package: debhelper
> Version: 12.2
> Severity: important
> Control: affects -1 src:nethack
> 
> Hi,
> 
> I noticed when upgrading nethack, dh_shlibdeps no longer finds the main
> nethack ELF binaries. debhelper 12.1.1 works correctly.
> 
> [...] 
> 
> I think this is caused by the fix for #931996. Nethack installs these
> files with the setgid bit by default, which changes the output of file
> in a way that's no longer detected properly:
> 
> $ file --brief debian/nethack-x11/usr/lib/games/nethack/nethack-x11
> setgid ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV),
> dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
> BuildID[sha1]=1485534d83c00eb43ac9e8ddf15cab6c5b062ad7, for GNU/Linux
> 3.2.0, stripped
> 
> It's pretty easy to fix this in nethack if I need to, but I don't think
> something like this should break in debhelper without a compat bump.
> 
> James
> 

Hi Christoph,

Can you help me come up with a more reliable regex / handling of file(1)
output that satisfy your request from #931996 and also avoiding
regressions like this bug?

Because this generates wrong dependency info, I will "revert" the change
(i.e. remove the anchor) now to limit the breakage as it can slip into
testing.  This will in turn reduce the pressure for us to find a better
solution.

Thanks,
~Niels

Bug#932127: Reply

[Steve McIntyre]

On Tue, Jul 16, 2019 at 08:47:20AM +0200, Thomas Schneider wrote:
>Hi,
>the question was why I think this is a problem in the Grub packages.
>My answer to this is:
>1. Grub is already considering existing Btrfs snapshots, because it includes
>this string in the Linux line: rootflags=subvol=@
>2. Grub is already adapting the Linux line after a snapshot is booted and
>Grub is reinstalled
>3. Snapper is not the program responsible for booting a system

But Grub knows nothing at all about what you've done with snapshots,
unless you've done something to inform it. If you run snapper and then
run update-grub, that will likely do what you need.

>4. Snapper + Grub works well in Arch Linux

That would suggest that the Arch developers have done some work to add
integration here.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.

Bug#932103: RFP: fuidshift -- remap a filesystem tree to shift one set of UID/GID ranges to another

[Florian Weimer]

* Nicholas D. Steeves:

> Package name: fuidshift
> Version : 3.0
> Upstream Author : Name 
> URL : https://github.com/lxc/lxd/tree/master/fuidshift
> License : Apache 2.0
> Programming Lang: Go
> Description : remap a filesystem tree to shift one set of UID/GID
> ranges to another
>
> Fuidshift is useful for converting privileged containers to
> unprivileged ones, and also to adapt a container master to multiple
> users' authorised subuid and subguid ranges.  It also sounds like it
> might be useful for fixing up cases where --numeric-owner should have
> been used, but where it would be too labour-intensive to manually chown.
>
> I learned about this tool via the following document:
>   https://github.com/BenSartor/unprivileged-lxc-containers
>
> Here is the upstream description:
>
>   This tool lets you remap a filesystem tree, switching it from one
>   set of UID/GID ranges to another.
>   This is mostly useful when retrieving a wrongly shifted filesystem tree
>   from a backup or broken system and having to remap everything either to
>   the host UID/GID range (uid/gid 0 is root) or to an existing container's
>   range.
>   A range is represented as 
> :::.
>   Where "u" means shift uid, "g" means shift gid and "b" means shift
> uid and gid.
>
> https://github.com/lxc/lxd/blob/81b81b9ace3064c8065319f4e984378244587d80/fuidshift/main_shift.go#L26-L36
>
> It's part of the LXD project, but I'm not sure if it's as difficult to
> package as LXD itself, which is one reason why I've CCed the Go team.
> I also wonder if the best way to get this into Debian would be a
> src:lxd that produces bin:fuidshift.

How does this compare to (or interact with) newuidmap and newgidmap
from uidmap?

There's a push to force uidmap on everyone, with tight integration
into NSS.  If there's a competing scheme, it would be helpful to know
about it.

Bug#932152: debhelper: Make commands use pkgname.name.fragment automatically?

[Niels Thykier]

Guillem Jover:
> Source: debhelper
> Source-Version: 12.2
> Severity: wishlist
> 
> Hi!
> 
> I've noticed when using the dh sequencer, one of the common reasons
> to override targets is to pass --name arguments to debhelper commands.
> It would be nice if the name arguments would be inferred from the
> presence of the filenames instead, so that if we have say:
> 
>   debian/pkgname-a.name-a.service
>   debian/pkgname-a.name-b.service
>   debian/pkgname-a.name-c.init
>   debian/pkgname-b.name-d.logrotate
> 
> Then the commands would automatically use these w/o needing overrides.
> 
> Thanks,
> Guillem
> 

Hi,

Thanks for the suggestion.  I think it would be great if we could
realize a change like this to reduce the number of overrides and to make
more packaging "just work(tm)".

For the concrete proposal, I note the following things:

 * Correctness: Both pkgname-X and name-X can contain periods.  In the
   average case, it is unlikely to be ambiguous.  However, will it be an
   issue?

   - E.g. firebird3.0-server has an init file called firebird3.0
 installed via dh_installinit --name firebird$(FB_VER)

 * Efficiency: Globbing debian/ is quite expensive for some packages
   because they put a lot of files in debian/.  So preferably, this
   should be a solution without globbing - or at least, without globbing
   for the cases without --name.

   - The existing logic for avoiding to call dpkg_architecture in
 pkgfile might be useful or even sufficient (haven't checked).
 This is particular relevant for dh(1), which uses pkgfile often
 to determine if a helper can be skipped.

   - This could be an argument for supporting "directories".  Related
 bug #455246 which asked for directories for arch-qualified
 "pkgfile"s.

 * The example implies that these tools must now work with 0..N
   "pkgfile"s rather than 0..1, which implies adding another loop to
   pretty much every helper.  The most sane option here is probably
   to replace the "pkgfile" sub with a different routine to avoid
   breaking existing helpers that do not transition at the same time
   as debhelper.

 * In case you have two "pkgfile"s - one with and one without "--name"
   respectively - AND need different options for the two files, then
   you effectively need to rename the file without to ensure that you
   only act on one file at the time.  Alternative being a special case
   for refering to an "unnamed" "pkgfile" - not sure what is better.

   - Note this case cannot be done without overrides in the first place
 and is not a prime candidate for optimization.

 * This will need a compat bump as some people currently call the same
   helper twice with and without --name.

Feedback / Concrete solutions and suggestions etc. are welcome.

Thanks,
~Niels

Bug#931896: grub-efi-amd64: symbol `grub_file_filters` not found

[MiloMak]

  
  
Updated from 2.02+dfsg1-20 to 2.04-1 like the op and get similar to
the op

https://i.imgur.com/jKYXOHs.png

when i downgrade back to 2.02 grub boots without issue. I have
debian installed as:
/dev/sdc1    /boot/efi
/dev/sdc2    /                (/boot is here)

it has been working with:
# grep 'set root' /boot/grub/grub.cfg
set root='hd2,msdos2'

i see you say that the problem is most probably caused by a
misconfiguration. 

what should i be checking and how do i fix it?


On Fri, 12 Jul 2019 10:16:57 +0100 Colin Watson
 wrote:
> On Fri, Jul 12, 2019 at 02:57:42AM +0200, Sebastian Ramacher
wrote:
> > since the last update the grub no longer works. It fails
very early with
> > 
> > symbol `grub_file_filters` not found
> > 
> > and enters the rescue shell. After downgrading it back to
2.02+dfsg1-20
> > everything works again as expected.
> 
> This means that your GRUB installation is misconfigured: in
particular,
> it means that the GRUB core image that your firmware is
configured to
> boot from is not the one that grub-install is writing to on
upgrade,
> which means that the core image and the loadable modules in
/boot/grub/
> are incompatible and you get this failure mode.
> 
> This is not a bug in the new version of GRUB; any upgrade at
all that
> changed the interface between the core image and modules (which
is not a
> stable interface) would have exposed this. Rather, it's a bug
in the
> way your system was installed or possibly in the way it has
been
> maintained since then, and unfortunately it's prohibitively
difficult
> for the GRUB packaging to detect this sort of problem; while we
can do
> our best to predict what the firmware is going to boot from
(and it's
> usually easier with UEFI), we can't do a perfect job of that.
> 
> Since you're using grub-efi-amd64, here are a few tips for
things to
> investigate:
> 
> * Is your firmware actually set up to boot your system using
UEFI? If
> you had grub-efi-amd64 installed (declaring that your system's
boot
> process is owned by a UEFI boot loader), but your firmware is
> actually booting from an old BIOS core image that was once
installed
> using grub-pc, then that would cause this problem.
> 
> * Do you have multiple EFI System Partitions on different
disks? If
> so, it's possible that /boot/efi isn't the one your firmware is
> actually using.
> 
> * Perhaps your firmware is one of those that requires the boot
loader
> image to be in the so-called "removable media path"
> (/EFI/Boot/bootx64.efi on the EFI System Partition) despite
being on
> a fixed disk, and in that case perhaps you used grub-install's
> --force-extra-removable option or otherwise manually put it
there.
> If you don't remember, you can try to check for this, although
> imprecisely, by seeing whether "strings
> /boot/efi/EFI/Boot/bootx64.efi" (or case variations of that)
mentions
> "GRUB" or "shim". In that case, use "dpkg-reconfigure -plow
> grub-efi-amd64" and answer yes to the "Force extra installation
to
> the EFI removable media path?" question.
> 
> -- 
> Colin Watson [cjwat...@debian.org]
> 
> 

  

Bug#932243: RFS: streamlink/1.1.1+dfsg-1

[Alexis Murzeau]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "streamlink" for a new
upstream version 1.1.1.

 * Package name: streamlink
   Version : 1.1.1+dfsg-1
   Upstream Author : Streamlink Team
 * URL : https://streamlink.github.io/
 * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
   Section : python

It builds those binary packages:

  python3-streamlink - Python module for extracting video streams from
various websites
  python3-streamlink-doc - CLI for extracting video streams from various
websites (documentation)
  streamlink - CLI for extracting video streams from various websites to
a video player

To access further information about this package, please visit the
following URL:
  https://mentors.debian.net/package/streamlink


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

  dget -x
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_1.1.1+dfsg-1.dsc

More information about streamlink can be obtained at
https://streamlink.github.io/

Changes since the last upload in unstable:
streamlink (1.1.1+dfsg-1) unstable; urgency=medium

  * Use ignore-branch instead of having different gbp.conf over branches
  * Bump standard version to 4.4.0, no change required
  * Bump debhelper compat to 12
  * Remove livestreamer transitional package
  * Merge changes in experimental to unstable

 -- Alexis Murzeau   Tue, 16 Jul 2019 22:39:58 +0200

streamlink (1.1.1+dfsg-1~exp1) experimental; urgency=low

  * New upstream version 1.1.1+dfsg
  * Update patch remove_new_version_check

 -- Alexis Murzeau   Wed, 19 Jun 2019 21:58:59 +0200


I've removed the livesteamer transitional package as testing is now
Bullseye.

Regards,
-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F



signature.asc
Description: OpenPGP digital signature

Bug#932242: gpac: CVE-2019-13618

[Salvatore Bonaccorso]

Source: gpac
Version: 0.5.2-426-gc5ad4e4+dfsg5-5
Severity: important
Tags: security upstream
Forwarded: https://github.com/gpac/gpac/issues/1250
Control: found -1 0.5.2-426-gc5ad4e4+dfsg5-3+deb9u1
Control: found -1 0.5.2-426-gc5ad4e4+dfsg5-3

Hi,

The following vulnerability was published for gpac.

CVE-2019-13618[0]:
| In GPAC before 0.8.0, isomedia/isom_read.c in libgpac.a has a heap-
| based buffer over-read, as demonstrated by a crash in gf_m2ts_sync in
| media_tools/mpegts.c.


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-13618
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13618
[1] https://github.com/gpac/gpac/issues/1250

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#932241: vlc: CVE-2019-13615

[Salvatore Bonaccorso]

Source: vlc
Version: 3.0.7.1-2
Severity: important
Tags: security upstream
Forwarded: https://trac.videolan.org/vlc/ticket/22474
Control: found -1 3.0.7.1-1
Control: found -1 3.0.7-1
Control: found -1 3.0.7-0+deb9u1

Hi,

The following vulnerability was published for vlc, sorry another one.
For buster, stretch I think we can follow the usual strategy and
release a new upstream stable version once available.

CVE-2019-13615[0]:
| VideoLAN VLC media player 3.0.7.1 has a heap-based buffer over-read in
| mkv::demux_sys_t::FreeUnused() in modules/demux/mkv/demux.cpp when
| called from mkv::Open in modules/demux/mkv/mkv.cpp.


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-13615
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13615
[1] https://trac.videolan.org/vlc/ticket/22474

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#916220: saidar: segfault after couple of minutes

[Tim Bishop]

libstatgrab 0.92 has been release and we believe will fix this bug. Can
the package be updated?

https://github.com/libstatgrab/libstatgrab/releases/tag/LIBSTATGRAB_0_92

Tim.

-- 
Tim Bishop
http://www.bishnet.net/tim/
PGP Key: 0x6C226B37FDF38D55

Bug#932235: Possibly related bug

[vi0oss]

May be related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833640

Bug#932239: libcloud: new upstream version available: 2.5.0

[Leo Antunes]

Source: libcloud
Severity: wishlist

Dear Maintainers,

A new upstream has been released: 2.5.0
It would be great if someone would find the time to upload it! :)


Cheers
Leo

Bug#932240: debhelper: no longer detects setgid binaries in dh_shlibdeps

[James Cowgill]

Package: debhelper
Version: 12.2
Severity: important
Control: affects -1 src:nethack

Hi,

I noticed when upgrading nethack, dh_shlibdeps no longer finds the main
nethack ELF binaries. debhelper 12.1.1 works correctly.

With 12.1.1:
$ dh_shlibdeps -v
dh_shlibdeps -v
dpkg-shlibdeps -Tdebian/nethack-common.substvars
debian/nethack-common/usr/lib/games/nethack/dlb
debian/nethack-common/usr/lib/games/nethack/lev_comp
debian/nethack-common/usr/lib/games/nethack/dgn_comp
debian/nethack-common/usr/lib/games/nethack/recover
dpkg-shlibdeps -Tdebian/nethack-console.substvars
debian/nethack-console/usr/lib/games/nethack/nethack-console
dpkg-shlibdeps -Tdebian/nethack-lisp.substvars
debian/nethack-lisp/usr/lib/games/nethack/nethack-lisp
dpkg-shlibdeps -Tdebian/nethack-x11.substvars
debian/nethack-x11/usr/lib/games/nethack/nethack-x11

With 12.2:
$ dh_shlibdeps -v
dpkg-shlibdeps -Tdebian/nethack-common.substvars
debian/nethack-common/usr/lib/games/nethack/dlb
debian/nethack-common/usr/lib/games/nethack/lev_comp
debian/nethack-common/usr/lib/games/nethack/dgn_comp
debian/nethack-common/usr/lib/games/nethack/recover


I think this is caused by the fix for #931996. Nethack installs these
files with the setgid bit by default, which changes the output of file
in a way that's no longer detected properly:

$ file --brief debian/nethack-x11/usr/lib/games/nethack/nethack-x11
setgid ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
BuildID[sha1]=1485534d83c00eb43ac9e8ddf15cab6c5b062ad7, for GNU/Linux
3.2.0, stripped

It's pretty easy to fix this in nethack if I need to, but I don't think
something like this should break in debhelper without a compat bump.

James



signature.asc
Description: OpenPGP digital signature

Bug#932238: RM: gtkorphan -- RoQA: RC-buggy due to obsolete dependencies, orphaned & effectively unmaintained in Debian, inactive upstream

[intrigeri]

Package: ftp.debian.org
Severity: normal

Hi,

as part of the broader effort to remove GTK 2 from the archive¹,
we (pkg-perl team) would like to remove this package.

It has been effectively unmaintained in Debian since 3+ years
and orphaned in March 2018.

Upstream is the same person who was previously maintaining this
package in Debian and the upstream home page [2] suggests no recent
activity; the "SVN" and "Download" links lead nowhere useful.

So I have extremely little hope that this piece of software is ever
ported away from GTK 2.

References:

 - requests to port to GTK 3, with no reply:
   https://bugs.debian.org/904562
   https://bugs.debian.org/912876

 - l10n patch submitted 4.5 years ago, with no reply:
   https://bugs.debian.org/773337

[1] https://lists.debian.org/debian-devel/2018/11/msg00570.html
[2] http://www.marzocca.net/linux/gtkorphan.html

Cheers,
-- 
intrigeri

Bug#932237: ITP: py-libzfs -- Python libzfs bindings

[William Grzybowski]

Package: wnpp
Severity: wishlist
Owner: William Grzybowski 

* Package name: py-libzfs
  Version : 0.1
  Upstream Author : FreeNAS
* URL : https://github.com/freenas/py-libzfs
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Python libzfs bindings

py-libzfs is a fairly straight-forward set of Python bindings for libzfs for
ZFS on Linux and FreeBSD.

Its a very useful module to deal with ZFS programatically, without relying on
zfs CLI tools.
I plan to maintain it myself.

Bug#910857: libvirt-daemon: race condition on reboot with spice monitor

[Dirk Steingäßer]

Hi,

have the same issue here.

Linux Wingert-APU 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u3
(2019-06-16) x86_64 GNU/Linux


Jul 16 21:05:57 Wingert-APU systemd[1]: Starting Suspend/Resume Running
libvirt Guests...
Jul 16 21:05:57 Wingert-APU libvirt-guests.sh[1138]: libvirt-guests is
configured not to start any guests on boot
Jul 16 21:05:57 Wingert-APU systemd[1]: Started Suspend/Resume Running
libvirt Guests.
Jul 16 21:05:59 Wingert-APU libvirtd[1088]: 2019-07-16
19:05:59.787+: 1088: info : libvirt version: 3.0.0, package:
4+deb9u4 (Guido Günther  Wed, 12 Jun 2019 10:13:38 +0200)
Jul 16 21:05:59 Wingert-APU libvirtd[1088]: 2019-07-16
19:05:59.787+: 1088: info : hostname: Wingert-APU
Jul 16 21:05:59 Wingert-APU libvirtd[1088]: 2019-07-16
19:05:59.787+: 1088: error : qemuMonitorIORead:601 : Unable to read
from monitor: Connection reset by peer
Jul 16 21:05:59 Wingert-APU libvirtd[1088]: 2019-07-16
19:05:59.789+: 1088: error : qemuProcessReportLogError:1792 :
internal error: qemu unexpectedly closed the monitor: ((null):1423):
Spice-Warning **: reds.c:2489:reds_init_socket:
getaddrinfo(127.0.0.1,5900): Address family for hostname not supported
Jul 16 21:05:59 Wingert-APU libvirtd[1088]: 2019-07-16T19:05:59.563803Z
qemu-system-x86_64: failed to initialize spice server
Jul 16 21:05:59 Wingert-APU libvirtd[1088]: 2019-07-16
19:05:59.790+: 1137: error : qemuProcessReportLogError:1792 :
internal error: process exited while connecting to monitor:
((null):1423): Spice-Warning **: reds.c:2489:reds_init_socket:
getaddrinfo(127.0.0.1,5900): Address family for hostname not supported
Jul 16 21:05:59 Wingert-APU libvirtd[1088]: 2019-07-16T19:05:59.563803Z
qemu-system-x86_64: failed to initialize spice server
Jul 16 21:05:59 Wingert-APU virtlogd[1250]: 2019-07-16
19:05:59.791+: 1250: info : libvirt version: 3.0.0, package:
4+deb9u4 (Guido Günther  Wed, 12 Jun 2019 10:13:38 +0200)
Jul 16 21:05:59 Wingert-APU libvirtd[1088]: 2019-07-16
19:05:59.796+: 1137: error : qemuAutostartDomain:297 : internal
error: Failed to autostart VM 'offloader': internal error: process
exited while connecting to monitor: ((null):1423): Spice-Warning **:
reds.c:2489:reds_init_socket: getaddrinfo(127.0.0.1,5900): Address
family for hostname not supported
Jul 16 21:05:59 Wingert-APU libvirtd[1088]: 2019-07-16T19:05:59.563803Z
qemu-system-x86_64: failed to initialize spice server
Jul 16 21:06:00 Wingert-APU libvirtd[1088]: 2019-07-16
19:06:00.392+: 1088: error : qemuMonitorIORead:601 : Unable to read
from monitor: Connection reset by peer
Jul 16 21:06:00 Wingert-APU libvirtd[1088]: 2019-07-16
19:06:00.394+: 1088: error : qemuProcessReportLogError:1792 :
internal error: qemu unexpectedly closed the monitor: -boot strict=on
-device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device
ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6
-device
ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1
-device
ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 -drive
file=/kvmimages/openwrt-x86-64-combined-ext4.img,format=raw,if=none,id=drive-ide0-0-0
-device
ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1
-netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=26 -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:69:79:76,bus=pci.0,addr=0x3
-netdev tap,fd=27,id=hostnet1,vhost=on,vhostfd=28 -device
virtio-net-pci,netdev=hostnet1,id=net1,mac=52:54:00:96:13:58,bus=pci.0,addr=0x4
-chardev pty,id=charserial0 -device
isa-serial,chardev=charserial0,id=serial0 -chardev
spicevmc,id=charchannel0,name=vdagent -device
virtserialport,bus=virtio-serial0.0,nr
Jul 16 21:06:00 Wingert-APU libvirtd[1088]: 2019-07-16
19:06:00.395+: 1137: error : qemuProcessReportLogError:1792 :
internal error: process exited while connecting to monitor: -boot
strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device
ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6
-device
ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1
-device
ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 -drive
file=/kvmimages/openwrt-x86-64-combined-ext4.img,format=raw,if=none,id=drive-ide0-0-0
-device
ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1
-netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=26 -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:69:79:76,bus=pci.0,addr=0x3
-netdev tap,fd=27,id=hostnet1,vhost=on,vhostfd=28 -device
virtio-net-pci,netdev=hostnet1,id=net1,mac=52:54:00:96:13:58,bus=pci.0,addr=0x4
-chardev pty,id=charserial0 -device
isa-serial,chardev=charserial0,id=serial0 -chardev
spicevmc,id=charchannel0,name=vdagent -device
virtserialport,bus=virtio-serial
Jul 16 21:06:00 Wingert-APU libvirtd[1088]: 2019-07-16
19:06:00.402+: 1137: error : 

Bug#932149: Early segfault in steal-ctty on Xen DomU install

[Bernhard Übelacker]

Dear Maintainer,
just tried to have a look at the part where steal-ctty is crashing.

It looks like it may get called from [1].

81  # Run the startup scripts once, using the preferred console
82  cons=$(cat /var/run/console-preferred)
83  # Some other session may have that console as ctty. Steal it from them
84  /sbin/steal-ctty $cons "$@"

Due to the low memory situation there is no /var directory at all
and therefore the cons variable might have no content.

Therefore steal-ctty is called with just one parameter while
it unconditionally tries to execute the second command line parameter [2].

35  if (-1 == execvp(argv[2], [2])) {

As a "side effect" the now saved script to be executed in argv[1] gets
not executed, but that might fail anyway later in this case.

Maybe that situation could be detected when the initramfs was not
unpacked successfully, but has enough unpacked to attempt starting
the installer.

[0.564101] Unpacking initramfs...
[0.634972] Initramfs unpacking failed: write error

Also this might not be limited to xen install images.
I could reproduce this with debian-10.0.0-amd64-netinst.iso
inside a VM with just 300MB memory assigned.

Kind regards,
Bernhard


[1] 
https://salsa.debian.org/installer-team/rootskel/blob/master/src/sbin/reopen-console-linux#L82
[2] 
https://salsa.debian.org/installer-team/rootskel/blob/master/src/sbin/steal-ctty.c#L35

Bug#904561: libgtk2-gladexml-perl: Don't ship libgtk2-gladexml-perl in Buster

[intrigeri]

Hi,

next step here is to remove this package from sid,
as it blocks the removal of libgtk2-perl (#912860).

intrig...@debian.org:
> This package has only 4 reverse-dependencies

Thankfully, no new reverse-dependency has appeared since then :)

>  - libgtk2-gladexml-simple-perl: filed #904551 to avoid shipping it in Buster

I've requested its removal: #932228

>  - gresolver: not in testing (depends on obsolete libgnome)

Removed from sid already:
https://tracker.debian.org/news/1008752/removed-005-6-from-unstable/

>  - gtkorphan: filed a bug to request removing the dependency

That's #904562. The package was orphaned more than a year ago,
no reply to my bugs on the BTS ⇒ will request removal right away.

>  - macchanger-gtk: not in testing, filed a bug to request removing the
>dependency anyway

I've made that bug (#904559) RC and have sent one last ping to the
maintainer; if I still get no reply, I'll go through whatever process
is needed in order to request the removal.

Cheers,
-- 
intrigeri

Bug#931561: fix bug 931561

[esm5]

git clone 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git


cd linux-firmware

mkdir /lib/firmware/mediatek/

cp mediatek/mt7610u.bin /lib/firmware/mediatek/

rmmod mt76x0

modprobe mt76x0

Adapter is working.

Bug#904559: macchanger-gtk won't be part of Bullseye unless it's ported away from GTK 2

[intrigeri]

Hi Alejandro,

macchanger-gtk is one of the few remaining reverse-dependency of
libgtk2-perl, which will be removed from testing, and possibly from
the archive, during the Bullseye cycle:

  https://bugs.debian.org/912860
  https://lists.debian.org/debian-devel/2018/11/msg00570.html

Since a year, when I started alerting you about this problem,
are there any news wrt. porting this package to GTK+ 3?
Is it worth waiting? It looks like upstream is gone.

Note that NetworkManager now has various functionality to spoof the
MAC address, so perhaps macchanger-gtk is less needed than it used
to be?

Cheers,
-- 
intrigeri

Bug#930952: RFS: libagentcrypt/1.0.5-2 [ITP] -- symmetric encryption with SSH Agent

[Nicola Di Lieto]

On Mon, Jul 15, 2019 at 09:15:15PM +0200, Adam Borowski wrote:

How do I use this program?  According to my reading of the man page,
the following should work:

[/tmp]$ echo meow >foo
[/tmp]$ agentcrypt foo
agentcrypt: failed to encrypt foo: Invalid argument
[/tmp]$ agentcrypt -v foo
agentcrypt: encrypting foo to foo.acb in binary mode
agentcrypt: failed to encrypt foo: Invalid argument

The ssh agent is running, and I can ssh normally.



Have you got a supported ssh key loaded in the ssh agent? Only rsa and
ed25519 will work. Check with ssh-add -l please



You can run lintian to automate the bulk of reviewers' work.
Here, it says:
W: libagentcrypt-dev: manpage-has-bad-whatis-entry 
usr/share/man/man3/libagentcrypt.h.3.gz
W: libagentcrypt-dev: pkg-config-references-unknown-shared-library 
usr/lib/x86_64-linux-gnu/pkgconfig/libagentcrypt.pc -lsodium (line 26)
E: libagentcrypt0: repeated-trigger-name activate-noawait ldconfig (line 3) vs 
activate-noawait ldconfig (line 1)

repeated-trigger-name is because both you and dh add the same trigger; you
can remove it.

There's no reason for user programs to link with libsodium:
[~]$ ldd /usr/lib/x86_64-linux-gnu/libagentcrypt.so.0
linux-vdso.so.1 (0x7fff1b6ab000)
libgtk3-nocsd.so.0 => /usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 
(0x7f5d7789e000)
libsodium.so.23 => /usr/lib/x86_64-linux-gnu/libsodium.so.23 
(0x7f5d77847000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f5d77686000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f5d77681000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f5d7766)
/lib64/ld-linux-x86-64.so.2 (0x7f5d77ad)
any program that uses your library will recursively pull in libsodium
via the loader; if you recompile against a different backend or even
a different soversion of libsodium that won't affect the programs.



Thanks for all the suggestions, I'll implement them when I have a 
minute.

Bug#912367: stretch-pu: package gthumb/3:3.4.4.1-5

[Adam D. Barratt]

On Sat, 2019-03-09 at 16:41 +, Adam D. Barratt wrote:
> On Mon, 2018-12-03 at 08:17 +0100, Julien Cristau wrote:
> > Control: tag -1 confirmed
[...]
> > Go ahead, thanks.
> 
> Ping?

Ping? If nothing happens by August 15th then I plan to close this bug.

Regards,

Adam

Bug#912068: stretch-pu: package apache-directory-server/2.0.0~M15-4

[Adam D. Barratt]

On Mon, 2019-02-04 at 21:36 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sat, 2018-10-27 at 22:35 +0200, Dominik George wrote:
> > I would like to upload fixes for two RC bugs that affect stretch
> > and
> > make the package uninstallable and, after manually fixing that,
> > unusable:
> > 
> >  #909063 - apacheds: package installation fails due to incorrect
> > apacheds.service unit
> >  #911557 - apacheds: broken symlinks:
> > /usr/share/apacheds/lib/{log4j-
> > 1.2,commons-io,antlr}.jar
> 
> I assume there's no way of avoiding the hard-coding of the new
> dependencies there?
> 
> Please go ahead; sorry for the delay.

Ping? If nothing happens by August 15th then I plan to close this bug.

Regards,

Adam

Bug#902683: stretch-pu: package python-proliantutils/2.1.11-2

[Adam D. Barratt]

On Sat, 2019-03-09 at 16:40 +, Adam D. Barratt wrote:
> On Thu, 2018-11-01 at 20:32 +, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > On Fri, 2018-06-29 at 16:50 +0200, Thomas Goirand wrote:
> > > I've prepared an update to python-proliantutils which fixes FTBFS
> > > when there is internet connectivity in the build host. Please
> > > find
> > > the diff attached to this bug report. Trivially, it replaces
> > > 1.1.1.1
> > > by a never reachable IP address in the test suite.
> > 
> > This wasn't fixed in unstable last time I looked, but apparently
> > has
> > been in the meantime, so please go ahead.
> 
> Ping?

Ping? If nothing happens by August 15th then I plan to close this bug.

Regards,

Adam

Bug#932235: gnupg: Stucks in CPU busy loop when started from torbrowser-launcher

[vi0oss]

Package: gnupg
Version: 2.2.12-1
Severity: normal

-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (900, 'stable'), (10, 'stable-debug'), (10, 
'oldstable-debug'), (10, 'oldoldstable'), (10, 'oldstable')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.18-64+ (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_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 /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gnupg depends on:
ii  dirmngr 2.2.12-1
ii  gnupg-l10n  2.2.12-1
ii  gnupg-utils 2.2.12-1
ii  gpg 2.2.12-1
ii  gpg-agent   2.2.12-1
ii  gpg-wks-client  2.2.12-1
ii  gpg-wks-server  2.2.12-1
ii  gpgsm   2.2.12-1
ii  gpgv    2.2.12-1

gnupg recommends no packages.

Versions of packages gnupg suggests:
pn  parcimonie  
ii  xloadimage  4.1-25

-- no debconf information

-- Description

I noticed torbrowser-launcher gets stuck on startup. Actually it was 
stuck in /usr/bin/gpg.


The problem is consistently reproducible.

Command line:

/usr/bin/gpg --status-fd 2 --homedir 
/home/torbrowser/.local/share/torbrowser/gnupg_homedir --keyserver 
hkps://hkps.pool.sks-keyservers.net --keyserver-options ca-cert-
file /usr/share/torbrowser-launcher/sks-keyservers.netCA.pem 
include-revoked no-honor-keyserver-url no-honor-pka-record --refresh-keys


Backtrace

#0  0x562cd88cfc2e in add_kbnode (root=root@entry=0x562cdcdc1ce0, 
node=node@entry=0x562ce050bce0) at ../../g10/kbnode.c:147

    n1 = 0x562cdfe75360
#1  0x562cd88cd27c in keyring_get_keyblock (hd=0x562cdcd90e10, 
ret_kb=ret_kb@entry=0x7fff4d17cb40) at ../../g10/keyring.c:480

    pkt = 0x562ce050bb20
    parsectx = {inp = 0x562cdcd90bf0, last_pkt = {pkttype = 
PKT_SIGNATURE, pkt = {generic = 0x562ce050bb40, symkey_enc = 
0x562ce050bb40, pubkey_enc = 0x562ce050bb40, onepass_sig = 
0x562ce050bb40, signature = 0x562ce050bb40, public_key = 0x562ce050bb40, 
secret_key = 0x562ce050bb40, comment = 0x562ce050bb40, user_id = 
0x562ce050bb40, compressed = 0x562ce050bb40, encrypted = 0x562ce050bb40, 
mdc = 0x562ce050bb40, plaintext = 0x562ce050bb40, gpg_control = 
0x562ce050bb40}}, free_last_pkt = 0, skip_meta = 0, n_parsed_packets = 
223025}

    rc = 
    keyblock = 0x562cdcdc1ce0
    node = 0x562ce050bce0
    lastnode = 0x562ce050bce0
    a = 0x562cdcd90bf0
    in_cert = 1
    pk_no = 1
    uid_no = 1
    save_mode = 0
#2  0x562cd88cb004 in keydb_get_keyblock (hd=0x562cdcde0640, 
ret_kb=ret_kb@entry=0x7fff4d17cb40) at ../../g10/keydb.c:1403

    err = 0
#3  0x562cd88c5a5c in lookup (ctrl=ctrl@entry=0x562cd9074e50, 
ctx=ctx@entry=0x7fff4d17cba0, want_secret=want_secret@entry=0, 
ret_keyblock=ret_keyblock@entry=0x7fff4d17cb90, 
ret_found_key=ret_found_key@entry=0x7fff4d17cb98) at ../../g10/getkey.c:3678

    rc = 0
    no_suitable_key = 0
    keyblock = 0x0
    found_key = 0x0
    infoflags = 1897227711
    __FUNCTION__ = "lookup"
#4  0x562cd88c840d in get_pubkey_byfprint 
(ctrl=ctrl@entry=0x562cd9074e50, pk=pk@entry=0x0, 
r_keyblock=r_keyblock@entry=0x0, fprint=fprint@entry=0x7fff4d17cd90 
"\357n(mڅ\352*K\247\336hN,n\207\223)\202\220,V", 
fprint_len=fprint_len@entry=20) at ../../g10/getkey.c:1678
    ctx = {exact = 1, want_secret = 0, req_usage = 0, kr_handle = 
0x562cdcde0640, not_allocated = 1, extra_list = 0x0, found_via_akl = 0, 
nitems = 1, items = {{mode = KEYDB_SEARCH_MODE_FPR20, skipfnc = 0x0, 
skipfncvalue = 0x0, sn = 0x0, snlen = 0, u = {name = 0x2aea85da6d286eef 
, fpr = 
"\357n(mڅ\352*K\247\336hN,n\207\223)\202\220\000\000\000", kid = 
{1831366383, 720012762}, grip = 
"\357n(mڅ\352*K\247\336hN,n\207\223)\202\220"}, exact = 0}}}

    kb = 0x0
    found_key = 0x0
    rc = 
#5  0x562cd88c8d47 in get_pubkey_byfprint (fprint_len=20, 
fprint=0x7fff4d17cd90 "\357n(mڅ\352*K\247\336hN,n\207\223)\202\220,V", 
r_keyblock=0x0, pk=0x0, ctrl=0x562cd9074e50) at ../../g10/getkey.c:1657

    rc = 
    rc = 
    ctx = 
    kb = 
    found_key = 
#6  get_user_id_byfpr (ctrl=ctrl@entry=0x562cd9074e50, 
fpr=fpr@entry=0x7fff4d17cd90 
"\357n(mڅ\352*K\247\336hN,n\207\223)\202\220,V", 
rn=rn@entry=0x7fff4d17cc90) at ../../g10/getkey.c:4124

    r = 0x0
    p = 
    pass = 
#7  0x562cd88c8d8e in get_user_id_byfpr_native 
(ctrl=ctrl@entry=0x562cd9074e50, fpr=fpr@entry=0x7fff4d17cd90 
"\357n(mڅ\352*K\247\336hN,n\207\223)\202\220,V") at ../../g10/getkey.c:4137

    rn = 0
    p = 
    p2 = 
#8  0x562cd890332c in import_one (ctrl=ctrl@entry=0x562cd9074e50, 
keyblock=, stats=stats@entry=0x562cd90c4970, 
fpr=fpr@entry=0x0, fpr_len=fpr_len@entry=0x0, options=, 
options@entry=2198, from_sk=0, silent=, 
screener=0x562cd89148f0 , 
screener_arg=0x7fff4d17d170, origin=1, url=0x562cd9082fe0 

Bug#932174: xfce4-settings: Should depend on GTK3 variant of garcon

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 2019-07-16 at 21:01 +0200, Simon Frei wrote:
> On 16/07/2019 20:28, Yves-Alexis Perez wrote:
> > xfce4-settings depends on libgarcon-1-0 because it's not yet ported to >
> > libgarcon-2: > >
> https://git.xfce.org/xfce/xfce4-settings/tree/configure.ac.in#n95 I
> believe everything is ported to gtk3 in 4.13 (actually 4.14-pre now).
> Looking at e.g.
> https://git.xfce.org/xfce/garcon/tree/configure.ac.in#n167
> the -1 suffix didn't change when moving to gtk3. It also depends on gtk3
> and libxfce4util-1.0, so the same is true there. As far as I understand
> it gtk2 build options are just there for legacy, they aren't used anymore.

Sorry I was a bit confused. xfce4-settings uses garcon-1 library, not garcon-
gtk3-1. The libgarcon-1-0 package includes both libgarcon-1-0 and libgarcon-
gtk2-1 and that's the reason why it depends on both libxfce4ui-1 and gtk2.

When libgarcon-gtk3 was introduced, we split it to a new package because it's
indeed more reasonable, but we didn't move the libgarcon-1-gtk2 in a new
package. In due time, we'll just stop building libgarcon-1-gtk2 (and thus
remove the extra dependency), but there's no urgency.

In any case, there's no bug in xfce4-settings. We can reassign to garcon to
remember stopping building the gtk2 variant at one point, or just close it, up
to you.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl0uJr8ACgkQ3rYcyPpX
RFvn1Af/ZrEoT/9mJVGvn2ZdVvTkIb4Dkj4idtF2JKyuurjh6RxIzg/HApnXaSlM
9I2jzDC5YzHJU413tUCU+T6NfOGxwtMKkOU49hDAASo7PByhIiI9XX2Wcdc5ly/J
/3SnFwPCNdOW3WeTLT/NPiqX346Twh01QeanuhtUQYBCAy4oiPCbY+K60YRSDfKW
fEHUpLt+ool3NoxEa0GrxVe30d83qr4Z62L0uDU8MfxGpRCWQFXC+PfLMwjGWQSx
RdU6VgmBjDXb3jfQxV6cbRX5ntxF4k3b6UOC+LW39A193nSL6AuyXEWARARaOIor
C+o2P4YJpsAxTYaTjMcP9CeF9BZ6Jw==
=lmGn
-END PGP SIGNATURE-

Bug#932234: RM: libgtk2-trayicon-perl -- ROM: RC-buggy due to obsolete dependencies

[intrigeri]

Package: ftp.debian.org
Severity: normal

Hi,

as part of the broader effort to remove GTK 2 from the archive¹,
we (pkg-perl team) would like to remove this package.

Its only reverse dependency is checkgmail (inactive upstream for
years, orphaned in Debian, no reply since a year to my bug reports on
the BTS) for which I've filed a RM bug as well.

Reference: https://bugs.debian.org/904556

[1] https://lists.debian.org/debian-devel/2018/11/msg00570.html

Cheers,
-- 
intrigeri

Bug#931572: Vagrant box missing stable buster release

[Filippo Giunchedi]

On Sun, Jul 07, 2019 at 02:22:41PM -0500, Andrew Pennebaker wrote:
> Package: cloud.debian.org
> Version: *
> 
> The semi-official virtual machine images on Vagrant Cloud do not yet
> feature a stable, v10.0.0 release for Debian Buster.

Can confirm, additionally 'vagrant up' with debian/buster64 is failing for me
on amd64 with

Tuesday 16 July 2019  21:18:43 +0200 (0:00:00.041)   0:00:01.150 ** 
prober | FAILED! => {
"changed": false, 
"cmd": "apt-get update", 
"msg": "E: Repository 'http://deb.debian.org/debian buster InRelease' 
changed its 'Suite' value from 'testing' to 'stable'\nE: Repository 
'http://security.debian.org/debian-security buster/updates InRelease' changed 
its 'Suite' value from 'testing' to 'stable'", 
"rc": 100, 
"stderr": "E: Repository 'http://deb.debian.org/debian buster InRelease' 
changed its 'Suite' value from 'testing' to 'stable'\nE: Repository 
'http://security.debian.org/debian-security buster/updates InRelease' changed 
its 'Suite' value from 'testing' to 'stable'\n", 
"stderr_lines": [
"E: Repository 'http://deb.debian.org/debian buster InRelease' changed 
its 'Suite' value from 'testing' to 'stable'", 
"E: Repository 'http://security.debian.org/debian-security 
buster/updates InRelease' changed its 'Suite' value from 'testing' to 'stable'"
], 
"stdout": "Get:1 http://deb.debian.org/debian buster InRelease [118 
kB]\nGet:2 http://security.debian.org/debian-security buster/updates InRelease 
[39.1 kB]\nReading package lists...\n", 
"stdout_lines": [
"Get:1 http://deb.debian.org/debian buster InRelease [118 kB]", 
"Get:2 http://security.debian.org/debian-security buster/updates 
InRelease [39.1 kB]", 
"Reading package lists..."
]
}

Bug#887427: stretch-pu: package buildbot/0.8.12-3.2

[Adam D. Barratt]

On Sun, 2018-12-02 at 16:53 +0100, Julien Cristau wrote:
> Control: tag -1 - moreinfo
> Control: tag -1 + confirmed
> 
> On Tue, Jan 16, 2018 at 02:54:14PM +0300, Alexander GQ Gerasiov
> wrote:
[...]
> > Waiting for approve to do NMU to stretch-proposed-updates.
> > 
> 
> Sounds ok.  Please use version 0.8.12-3.2+deb9u1.

Ping? If nothing happens by August 15th then I plan to close this bug.

Regards,

Adam

Bug#932233: RM: checkgmail -- RoQA; obsolete dependencies and inactive upstream

[intrigeri]

Package: ftp.debian.org
Severity: normal

Hi,

as part of the broader effort to remove GTK 2 from the archive¹,
we (pkg-perl team) would like to remove this orphaned package:

  https://bugs.debian.org/904557
  https://bugs.debian.org/912871

It's the only reverse-dependency of libgtk2-trayicon-perl,
for which I'll file another RM bug.

[1] https://lists.debian.org/debian-devel/2018/11/msg00570.html

Cheers,

Bug#874740: stretch-pu: breeze-gtk/5.8.7-1+deb9u1

[Adam D. Barratt]

On Sat, 2017-09-09 at 16:15 +0200, Julien Cristau wrote:
> Control: tag -1 confirmed
> 
> Next up, breeze-gtk.
[...]
> Looks fine, feel free to upload this one.

That never happened, possibly because of lack of decisions on some of
the other components, and the discussion seems to have fallen between
the cracks all around; apologies for our part in that.

Is updating plasma in stretch still of any interest at this point?

Regards,

Adam

Bug#932182: Acknowledgement (vlc: Floating point exception crash playing certain DVDs)

[Sergio Gelato]

control: found -1 3.0.7-1
control: tags -1 + fixed-upstream 

I confirm that the upstream commit I referred to earlier solves my problem and 
allows the DVD to be played.

Inspection of the 3.0.7.1-2 source code suggests that the bug is still there 
(i.e. the commit didn't make it into that upstream release and isn't in 
debian/patches either) but I haven't verified it experimentally.

Bug#932232: RM: libgtk2-traymanager-perl -- ROM: RC-buggy due to obsolete dependencies

[intrigeri]

Package: ftp.debian.org
Severity: normal

Hi,

as part of the broader effort to remove GTK 2 from the archive¹,
we (pkg-perl team) would like to remove this leaf package.

Reference: https://bugs.debian.org/904555

[1] https://lists.debian.org/debian-devel/2018/11/msg00570.html

Cheers,
-- 
intrigeri

Bug#932210: Fwd: Bug#932210: libimage-exiftool-perl: Exiftool does not start

[Salvatore Bonaccorso]

Hi Pierre,

On Tue, Jul 16, 2019 at 12:31:41PM -0400, Phil Harvey wrote:
> > From: Pierre AUSSAGUEL 
> > Subject: Re: Bug#932210: libimage-exiftool-perl: Exiftool does not start
> > Date: July 16, 2019 at 12:26:43 PM EDT
> > To: Phil Harvey 
> > 
> > Le 16/07/2019 à 18:14, Phil Harvey a écrit :
> >> Somehow you've got a very old version (9.76) in /usr/local/bin
> >> This explains the problem.  Delete this old version and replace it with 
> >> the most current one (if it doesn't already exist somewhere else in the 
> >> path).
> > 
> > # rm /usr/local/bin/exiftool
> > # apt reinstall libimage-exiftool-perl
> > # exiftool -v
> > bash: /usr/local/bin/exiftool: Aucun fichier ou dossier de ce type
> > 
> > I dont understand ... isn't libimage-exiftool-perl supposed to provide the 
> > file ?
> > 
> > I solved the problem by placing a symlink in /usr/local/bin from 
> > /usr/bin/exiftool
> > 
> > Thank for your help
> > 
> > I think the package should be modified to remove the old file and make the 
> > symlink or any other better solution.

This is actually not needed that you create a symlink.
/usr/bin/exiftool is provided by the package. But you previously
invoked in the sheell having probably a preference of /usr/local/bin
before /usr/bin. I guess after removing the file you did not invoked
hash -r in bash to forget the remembered locations of a command? (see
hash under SHELL BUILTIN COMMANDS in bash(1)).

Regards,
Salvatore

Bug#932231: flash-kernel might fail silently

[Uwe Kleine-König]

Package: flash-kernel
Version: 3.37
Severity: normal

Hello,

flash-kernel 3.37 introduced the following in flash-kernel:

+   # installation-report #781742 included:
+   # Can't find /boot/vmlinuz-[...] or /boot/initrd.img-[...]
+   #
+   # It's unclear how this can have happened or what state the
+   # system was in, so log some additional information in the
+   # hopes of catching it in the act next time.
+   (
+   set -x
+   ls -l $kfile*
+   ls -l $ifile*
+   ) >> /tmp/flash-kernel-no-kernel-error.log
+   error "Can't find $kfile or $ifile (see 
/tmp/flash-kernel-no-kernel-error.log)"

A problem here is that if the last command in the subshell fails this
makes flash-kernel exit (as it uses "set -e") without reaching the error
message.

Best regards
Uwe

Bug#932230: RM: libgtk2-spell-perl -- ROM: RC-buggy due to obsolete dependencies

[intrigeri]

Package: ftp.debian.org
Severity: normal

Hi,

as part of the broader effort to remove GTK 2 from the archive¹,
we (pkg-perl team) would like to remove this leaf package.

Reference: https://bugs.debian.org/904554

[1] https://lists.debian.org/debian-devel/2018/11/msg00570.html

Cheers,
-- 
intrigeri

Bug#932228: ftp.debian.org: RM: libgtk2-gladexml-simple-perl -- ROM: RC-buggy due to obsolete dependencies

[intrigeri]

Package: ftp.debian.org
Severity: normal

Hi,

as part of the broader effort to remove GTK 2 from the archive¹, we
(pkg-perl team) would like to remove this leaf package.

Reference: https://bugs.debian.org/904551

[1] https://lists.debian.org/debian-devel/2018/11/msg00570.html

Cheers,
-- 
intrigeri

Bug#932229: RM: libgtk2-notify-perl -- ROM: RC-buggy due to obsolete dependencies

[intrigeri]

Package: ftp.debian.org
Severity: normal

Hi,

as part of the broader effort to remove GTK 2 from the archive¹,
we (pkg-perl team) would like to remove this leaf package.

Reference: https://bugs.debian.org/904552

[1] https://lists.debian.org/debian-devel/2018/11/msg00570.html

Cheers,
-- 
intrigeri

Bug#932227: RM: libgtk2-ex-volumebutton-perl -- ROM: RC-buggy due to obsolete dependencies and inactive upstream

[intrigeri]

Package: ftp.debian.org
Severity: normal

Hi,

as part of the broader effort to remove GTK 2 from the archive¹,
we (pkg-perl team) would like to remove this RC-buggy package from
the archive. It has no reverse-dependency.

Reference: https://bugs.debian.org/904550

[1] https://lists.debian.org/debian-devel/2018/11/msg00570.html

Cheers,
-- 
intrigeri

Bug#287766: your mail

[Moritz Mühlenhoff]

On Sat, Oct 17, 2009 at 12:28:26AM +0100, Martin Meredith wrote:
> tags 287766 +wontfix
> thanks
> 
> Have contacted upstream maintainer, who no longer wishes to maintain this
> package.  It is now unmaintained upstream.
> 
> I do not have the time to take over upstream maintenance for this, therefore
> marking bug as wontfix. 
> 
> Dependant on further investigation, I may ask for bld-postfix to be removed 
> from
> the archives

Almost a decade later, let's proceed with the removal? :-)

Cheers,
Moritz

Bug#932226: RM: libgtk2-ex-simple-list-perl -- ROM: RC-buggy due to obsolete dependencies and inactive upstream

[intrigeri]

Package: ftp.debian.org
Severity: normal

Hi,

as part of the broader effort to remove GTK 2 from the archive¹, we
(pkg-perl team) would like to remove this RC-buggy package from the
archive. It has only one reverse-dependency in the archive
(libgtk2-ex-podviewer-perl) for which I've filed a RM bug already.

Reference: https://bugs.debian.org/904549

[1] https://lists.debian.org/debian-devel/2018/11/msg00570.html

Cheers,
-- 
intrigeri

Bug#932225: RM: libgtk2-ex-printdialog-perl -- ROM: RC-buggy due to obsolete dependencies and inactive upstream

[intrigeri]

Package: ftp.debian.org
Severity: normal

Hi,

as part of the broader effort to remove GTK 2 from the archive¹, we
(pkg-perl team) would like to remove this package from the archive.
It has no reverse-dependency.

Reference: https://bugs.debian.org/904548

[1] https://lists.debian.org/debian-devel/2018/11/msg00570.html

Cheers,
-- 
intrigeri

Bug#932174: xfce4-settings: Should depend on GTK3 variant of garcon

[Simon Frei]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 16/07/2019 20:28, Yves-Alexis Perez wrote:
> xfce4-settings depends on libgarcon-1-0 because it's not yet ported to > 
> libgarcon-2: > >
https://git.xfce.org/xfce/xfce4-settings/tree/configure.ac.in#n95 I
believe everything is ported to gtk3 in 4.13 (actually 4.14-pre now).
Looking at e.g.
https://git.xfce.org/xfce/garcon/tree/configure.ac.in#n167
the -1 suffix didn't change when moving to gtk3. It also depends on gtk3
and libxfce4util-1.0, so the same is true there. As far as I understand
it gtk2 build options are just there for legacy, they aren't used anymore.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEMW9redpUgdeyrfEzfDHSPssQBvMFAl0uHvkACgkQfDHSPssQ
BvMiqQ/+N9g435M4dVXTRAftVmJoAuhR+6GAio3rc/4MDzRoMNpNsYHiv6cyUSeO
jSdl6xp7tUkc4HmoPp7i7K1iZ17ggDGm92Qc+V+l2+9Rkq1xblLCCbvRghRFB9GD
pq4KsfdMYaSRRxFovBlQni9m0q/n+pv2S0nlkl9Bxix2zcM4Otl6l6TKOL3ldIKK
eGzdW2Tu02meqr5nkUjHo2G1kREfsrdSY8lIn0RyUAjn0KwRCs9jbkkAvOkvT/WK
4JLKVT3cV5XRZ/nt+u92rGASqSXLszrrQuyUTHX9Q3hlEd/W7c9BTpODp80yo1a/
3r0kig4WGCfB/Ze7cdexA1NMH+TlI8UGVw/Z82wAmr5nGyjVxUG6QedYUbCxSGx2
kDfb1PbBm8pYUBRoFI/DKIrJED2qhMj7Z74TbzPutcyrgLxBa08osQzmn1MF+CrQ
Rxlq6WxgCqguU7bzEqKQh39+3RjxodT5SaRu7i2Ub0yFTbC1Aa7tHKyW3rSHigEh
tUS9yrOBlr7MsrzwVFQkxL0u4syOLcTjsMSKoxKVNNoEp/LA+5CmsKUXp3brpbye
5FtZHgasWhRLX0qZcCVHzGYmLherznivKLXP9Zja3xcihuevtVARqj5IBCmNViRT
GRr0SVRTvMAtPbP1SXkjuYrauv2tRTA6lKcWHmQIC2EUXfeKbCI=
=W/+F
-END PGP SIGNATURE-

Bug#928002: firefox-esr: DnD from firefox to nautilus under Wayland locks up all X applications

[Samuel Wolf]

Same here with Firefox 68 and Gnome/Wayland, no way to use Buster in
this combination to work.

Bug#932224: RM: libgtk2-ex-podviewer-perl -- ROM: RC-buggy due to obsolete dependencies and inactive upstream

[intrigeri]

Package: ftp.debian.org
Severity: normal

Hi,

as part of the broader effort to remove GTK 2 from the archive¹, we
(pkg-perl team) would like to remove this package from the archive.
This package has no reverse-dependency in the archive.

Reference: https://bugs.debian.org/904547

[1] https://lists.debian.org/debian-devel/2018/11/msg00570.html

Cheers,
-- 
intrigeri

Bug#932223: RM: libgtk2-ex-entry-pango-perl -- ROM: RC-buggy due to obsolete dependencies

[intrigeri]

Package: ftp.debian.org
Severity: normal

Hi,

as part of the broader effort to remove GTK 2 from the archive¹,
we (pkg-perl team) would like to remove this RC-buggy package from
the archive. Its only reverse-dependency is xacobeo, for which I've
just filed a RM bug as announced on #885675 a year ago.

Reference: https://bugs.debian.org/904546

[1] https://lists.debian.org/debian-devel/2018/11/msg00570.html

Cheers,
-- 
intrigeri

Bug#932221: RM: xacobeo -- ROM: RC-buggy due to obsolete dependencies and inactive upstream

[intrigeri]

Package: ftp.debian.org
Severity: normal

Hi,

we (pkg-perl team) would like to remove this RC-buggy package from
the archive.

Reference: https://bugs.debian.org/885675

Cheers,
-- 
intrigeri

Bug#932222: ftp.debian.org: RM: libgtk2-sourceview2-perl -- ROM: RC-buggy due to obsolete dependencies

[intrigeri]

Package: ftp.debian.org
Severity: normal

Hi,

we (pkg-perl team) would like to remove this RC-buggy package from
the archive.

I've just filed a RM bug for its only reverse-dependency (xacobeo),
as announced on #885675 during DebCamp 2018.

Reference: https://bugs.debian.org/885676

Cheers,
-- 
intrigeri

Bug#912860: Don't ship libgtk2-perl in Bullseye

[intrigeri]

Hi,

intrigeri:
> I've filed bug reports against all reverse dependencies (normal
> severity for now), tracked using the gtk2-removal usertag

Since then, one new reverse dependency appeared in the archive
(libcircle-fe-gtk-perl), against which I've also filed a bug.

I intend to make all these bugs RC during DebCamp. Maintainers and
upstreams will have 18 more months to port packages to current GTK, in
addition to the 8 months they already had since the announcement
on -devel@¹ and the bugs I've filed.

[1] https://lists.debian.org/debian-devel/2018/11/msg00570.html

Cheers,
-- 
intrigeri

Bug#792040: [PATCH] Allow seconds in -t option

[Jose M Calhariz]

Hi,

Still interested in this bug report?  Adding support for seconds to at
daemon?


I am considering to release a new version of at with your patch and
others to support seconds and I am looking for beta testers.

Kind regards
Jose M Calhariz

-- 
--
Para que ocorra um tiro a queima roupa é necessário que a vítima esteja vestida?


signature.asc
Description: PGP signature

Bug#932174: xfce4-settings: Should depend on GTK3 variant of garcon

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

control: severity -1 wishlist

On Tue, 2019-07-16 at 11:17 +0200, Simon Frei wrote:
> I noticed that both libxfce4ui-1-0 and -2-0 are installed on my system and
> checking showed it's due to xfce4-settings depending on libgarcon-1-0. I
> assume it should depend on libgarcon-gtk3-1-0 (like e.g. xfce4-panel does).

xfce4-settings depends on libgarcon-1-0 because it's not yet ported to
libgarcon-2:

https://git.xfce.org/xfce/xfce4-settings/tree/configure.ac.in#n95

When the porting will be done upstream, the build-dependency will be updated
in Debian and the binary dependency will be automatically updated.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl0uF0gACgkQ3rYcyPpX
RFtV7QgArF1RC5+fbDD4KG+oLhJEhg0gdUy/zCSS3ZkF+LVF4wW+YTN9ikMIbhRy
QbXpTKRK6ZntambNKLQ5G8rQrxk62mZO2fLV1y/RLZOAmOQIDilkGRPvxNQs0afJ
I7GMzWSsUJe0KSrzqJm/eVMOq47uXroYs3TtLCpTq/K6uLFu8JWhpAI0b4amDmo1
swH5Y1iuLrLVAvUKPFarpod4HeHicjgm/BooTRaMqCwxiE9/w7DtIG68kQHUjfM6
NcajjzcBUI6jdwlwgjQor+eMKYjegZu38aVvfj6PYf0sgKgQysOdua1oQDxaYhHB
AxJ8hyRlJhA0hBnO41KmiEh8oG6n3w==
=pzuY
-END PGP SIGNATURE-

Bug#899377: xfce4-notifyd doesn't autostart with xfce session

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

control: retitle -1 xfce4-notifyd fails to start with DBus activation (Unable 
to init server)

On Sat, 2019-07-13 at 13:31 -0700, Bob Hauck wrote:
> Jul 13 13:29:28 robin xfce4-notifyd[2624]: Unable to init server: Could not
> connect: Connection refused
> Jul 13 13:29:28 robin systemd[1253]: xfce4-notifyd.service: Main process
> exited, code=exited, status=1/FAILURE
> Jul 13 13:29:28 robin systemd[1253]: xfce4-notifyd.service: Failed with
> result 'exit-code'.

So it's not that the service is not started, it's that it fails to start for
some reason. We'll have to investigate that.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl0uF7sACgkQ3rYcyPpX
RFuZuwgA7HqqLgzlzeyzqxOSAWsnirw0Kv8fS0VtCDsWkKk+4SMOLy94KARbfsKR
8/FVxwk3Bw1ONGL5anV0/NlyZv3Q0/T1lSvl9fAI0U+ED7I6EVtrs+C2sxXLBlPh
Mq8wPg0wdJd0riPksA7daaezbatBjT8r5aX3/blKbFQUH4sI/9ym46WB/2eaaE9e
yxENoJA+dLCLNqTc0y3HfqUy+K3GATrLXgmLUm26cEW/V90CrS3I1mt19auf/Vh8
ZfDZIQiTlvaW/l1JCzyACD4fhvI1fC8DCS1y5cj+dBImAgiYsgjRZJJ8yHx44rGL
Syri6k7qOz0q9EFZm65M7B1UiqDYTg==
=ZjmU
-END PGP SIGNATURE-

Bug#932220: libcircle-fe-gtk-perl: Depends on libgtk2-perl, that won't be part of Bullseye

[intrigeri]

Source: libcircle-fe-gtk-perl
Version: 0.173170-1
Severity: normal

Hi Andrej!

This package depends on libgtk2-perl, that I intend to remove from
testing soon (now that Buster was released), and then from sid at some
later point during the Bullseye development cycle:

   https://bugs.debian.org/912860
   
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=gtk2-removal;users=debian-p...@lists.debian.org

This is part of a broader effort to remove GTK 2 from Debian,
as announced last November:

   https://lists.debian.org/debian-devel/2018/11/msg00570.html

Please get in touch with the upstream project and suggest they port
this application to libgtk3-perl. I've personally ported a couple Perl
GTK+ apps from 2.x to 3.x and it's rather straightforward.
Upstream for the GTK+ 3 and GObject Introspection Perl bindings is
responsive and happy to add missing bits to the bindings.

Cheers!
-- 
intrigeri