Bug#888545: lists.debian.org: Request for new mailing list: debian-sagemath

[Alexander Wirt]

On Fri, 26 Jan 2018, Tobias Hansen wrote:

> Package: lists.debian.org
> Severity: wishlist
> 
> Dear listmasters,
> 
> With the upcoming shutdown of alioth, the Debian SageMath Team [1] needs a
> new mailing list for discussions about the packaging effort.
there will be a lists.alioth replacement. Since we don't want maintainer only 
lists, it is probably a good idea to wait for it.

Alex

Bug#888444: cryptmount: Got errno=95 when run as not-root

[R.Penney]

Hello Andrey,
Thanks for finding this issue with cryptmount, and for your helpful
stack traces and configuration information.

I am still investigating this issue, and have created a new test
specifically for LUKS partitions within ordinary files to help
narrow-down the source of the problem.

Could you confirm that in your case, the LUKS container is in an
ordinary file on a local filesystem (e.g. there are no NFS/SSHFS/NTFS
filesystems involved)?

I've confirmed that cryptmount does handle these files as intended on
debian-jessie, debian-stretch, ubuntu-artful, but there do seem to be
issues with debian-buster and fedora-27. All functionality relating to
handling LUKS containers within ordinary block devices (e.g. hard-disk
partitions), or filesystems in ordinary files managed by other
cryptmount keymanagers (e.g. "builtin", "libgcrypt") seems to be
working as it should.

I hope to be able to provide a fix soon.

RW Penney

Bug#885763: invada-studio-plugins-lv2: Depends on libgnome

[Adrian Bunk]

On Fri, Dec 29, 2017 at 08:20:11PM +0100, Jaromír Mikeš wrote:
>...
> as you see there is ongoing process of removing of old libs in debian.
> ​invada-studio-plugins-lv2 package depends on one of them unfortunately.
>...

Is there actually any reason why the package does depend on libgnome?

No plugin is linked with libgnome (there is also no build dependency),
and all these manual library dependencies look wrong to me 
(${shlibs:Depends} already does the right thing).

In other words, I'd suggest to:

--- invada-studio-plugins-lv2-1.2.0+repack0/debian/control  2016-12-19 
20:44:37.0 +0200
+++ invada-studio-plugins-lv2-1.2.0+repack0/debian/control  2018-01-27 
09:40:48.0 +0200
@@ -18,12 +18,6 @@
 Package: invada-studio-plugins-lv2
 Architecture: any
 Depends:
- libcairo2,
- libglade2-0,
- libglib2.0-0,
- libgnome2-0,
- libgtk2.0-0,
- libxml2,
  ${misc:Depends},
  ${shlibs:Depends}
 Provides:


> best regards
> 
> mira

cu
Adrian

-- 

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

Bug#888567: gnome-tweaks: Incomplete debian/copyright?

[Chris Lamb]

Source: gnome-tweaks
Version: 3.27.4-1
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Jeremy Bicha 

Hi!

I just ACCEPTed gnome-tweaks from NEW but noticed it was missing 
attribution in debian/copyright for at least, Cosimo Cecchi,
Canonical, Red Hat, etc. etc. :)

(This is not exhaustive so please check over the entire package 
carefully and address these on your next upload.)


Regards,

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

Bug#888564: www.debian.org: Release-critical bugs status page has wrong designation for stable and testing

[Boyuan Yang]

Thanks for your work!

Just out of curiosity, why is the source code of bugs.debian.org component not
hosted on Debian infrastructure? There's also nowhere under bugs.debian.org/*
documenting / pointing to that cgit instance.

Perhaps it would be great if we add appropriate information onto the webpage
about their source code repository.

Regards,
Boyuan Yang

> Thanks for the report and reassignment.
>
> I've fixed this in @5ccf6f4
> https://git.donarmstrong.com/bugscan.git/c/5ccf6f4; it'll be updated the
> next time that page is rebuilt (in a few hours.)
>
>
> --
> Don Armstrong  https://www.donarmstrong.com
>
> The game of science is, in principle, without end. He who decides one
> day that scientific statements do not call for any further test, and
> that they can be regarded as finally verified, retires from the game.
>  -- Sir Karl Popper _The Logic of Scientific Discovery_ §11

Bug#888566: vim FTBFS on alpha: vim segfaults in the build

[Michael Cree]

Source: vim
Version: 2:8.0.1401-2
Severity: important
Justification: fails to build from source (but built in the past)
User: debian-al...@lists.debian.org
Usertags: ftbfs

vim FTBFS on Alpha with the following [1]:

make[2]: Entering directory '/<>/src/vim-gtk/po'
../vim -u NONE -e -X -S check.vim -c "if error == 0 | q | endif" -c cq af.po
Segmentation fault
Makefile:153: recipe for target 'af.ck' failed

And, indeed, the built vim in src/vim-gtk3 segfaults when manually
run.  Debugging shows the segfault at:

#0  0x020001173014 in parse_cino (buf=0x200036a83a0) at misc1.c:7047

7047for (p = buf->b_p_cino; *p; )

which sets p to buf->b_p_cino and dereferences it but it is NULL.
Interesting the offset to field b_p_cino in the struct is 5144
bytes.

Going one step up the stack to:

#1  0x0200011b734c in check_buf_options (buf=0x200036a83a0) at
option.c:5672

5671check_string_option(&buf->b_p_cino);
5672parse_cino(buf);

So buf->b_p_cino should be set to an empty string (i.e. "") by
check_string_option() BUT the field b_p_cino in the struct is
5136 bytes from the start of the struct (cf. 5144 bytes for the
same struct in module misc1.o)!

Four of those bytes difference are due to the field b_ino in the
struct (of type ino_t).  And indeed examining the build log [1]
one sees option.c is compiled with -DFILE_OFFSET_BITS=64 but
misc1.c is NOT compiled with that option, hence the difference
in offsets to fields in the buf_T struct.

I am not sure why only some modules are compiled with
-DFILE_OFFSET_BITS=64. Whatever the reason, it leads to a broken
vim on Alpha.

Cheers
Michael.

[1]
https://buildd.debian.org/status/fetch.php?pkg=vim&arch=alpha&ver=2%3A8.0.1401-2&stamp=1514134076&raw=0

Bug#888564: www.debian.org: Release-critical bugs status page has wrong designation for stable and testing

[Boyuan Yang]

Control: reassign -1 bugs.debian.org
X-Debbugs-CC: ow...@bugs.debian.org fjfj...@protonmail.com

Hi annadane,

Bugs.debian.org (Debian Bug Tracking System) is not handled by debian-www team.
Please directly contact BTS Administrators via their mail address
ow...@bugs.debian.org .

Reassigning this bug to them here.

Regards,
Boyuan Yang


2018-01-27 12:45 GMT+08:00 annadane :
> Package: www.debian.org
> Severity: minor
>
> Dear Maintainer,
>
> The page https://bugs.debian.org/release-critical/debian/main.html still 
> lists Jessie as current stable which means all the other designations are 
> thrown off as well (Stretch is still listed as testing, Wheezy as oldstable).
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_CA:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>

Bug#888565: kexec-tools: update package information

[Heinrich Schuchardt]

Package: kexec-tools
Version: 1:2.0.15-1
Severity: minor

Dear Maintainer,

the home page link on the debian package description points to a file list:
https://www.kernel.org/pub/linux/utils/kernel/kexec/
This link does not help to get into contact with the kexec-tools project.

Please, update the home page information for kexec-tools to:
https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/
This will save the time of searching kernel.org.

Best regards

Heinrich Schuchardt

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

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

Versions of packages kexec-tools depends on:
ii  debconf [debconf-2.0]  1.5.65
ii  libc6  2.26-4
ii  lsb-base   9.20170808
ii  zlib1g 1:1.2.8.dfsg-5

kexec-tools recommends no packages.

kexec-tools suggests no packages.

-- debconf information excluded

Bug#888564: www.debian.org: Release-critical bugs status page has wrong designation for stable and testing

[annadane]

Package: www.debian.org
Severity: minor

Dear Maintainer,

The page https://bugs.debian.org/release-critical/debian/main.html still lists 
Jessie as current stable which means all the other designations are thrown off 
as well (Stretch is still listed as testing, Wheezy as oldstable). 

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

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

Bug#888563: transition: fcitx

[Boyuan Yang]

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

Dear Release Team,

I'm working to push fcitx 4.2.9.5 into unstable.
Fcitx upstream bumped the SONAME of one of its libraries,
libfcitx-gclient. This is a really tiny transition that only
affects one package outside fcitx world (mlterm):

% LC_ALL=C.UTF-8 apt rdepends libfcitx-gclient0
libfcitx-gclient0
Reverse Depends:
  Depends: fcitx-frontend-gtk2 (>= 4.2.9)
  Depends: libfcitx-gclient0-dbgsym (= 1:4.2.9.4-3)
  Depends: mlterm-im-fcitx (>= 4.2.7)
  Depends: fcitx-imlist (>= 4.2.7)
  Depends: fcitx-frontend-fbterm (>= 4.2.7)
  Depends: fcitx-config-gtk (>= 4.2.7)
  Depends: gir1.2-fcitx-1.0 (>= 4.2.9)
  Depends: fcitx-libs-dev (= 1:4.2.9.4-3)
  Depends: fcitx-libs (>= 1:4.2.9.4-3)
  Depends: fcitx-frontend-gtk3 (>= 4.2.9)

I will handle every reverse-dependency named after fcitx
(requesting binNMU or uploading the updated package).

As for package mlterm, I rebuilt it against the new fcitx. The build
is okay but the program won't start. I've filed bug #887711 for it.
If the bug cannot be fixed soon, I'm planning to disable mlterm's fcitx
support in an NMU later.

https://bugs.debian.org/887711

Automatic transition tracker:

https://release.debian.org/transitions/html/auto-fcitx.html

NB. the missing fcitx-module-quickphrase-editor there has no reverse-dependency
thus
does not affect the transition.

Thanks,
Boyuan Yang



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

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

Bug#888562: tor: Accounting settings are not applied

[gustavo panizzo]

Package: tor
Version: 0.3.1.9-1~bpo9+1
Severity: normal

Hello

As you can see on my edited torrc I've setup 3550GB of quota transfer
per month but as I can see using arm I only transfer 1T per month

I used tor from stable, but before reporting the bug I upgraded to
backports' tor and the problem is still there

arm's screenshot


Accounting (hard)  Time to reset: 4:20:06:30
  1 TB / 1 TB1 TB / 1 TB


thanks!

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

Kernel: Linux 4.14.12-x86_64-linode92 (SMP w/1 CPU core)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages tor depends on:
ii  adduser  3.115
ii  init-system-helpers  1.48
ii  libc62.24-11+deb9u1
ii  libcap2  1:2.25-1
ii  libevent-2.0-5   2.0.21-stable-3
ii  liblzma5 5.2.2-1.2+b1
ii  libseccomp2  2.3.1-2.1
ii  libssl1.11.1.0f-3+deb9u1
ii  libsystemd0  232-25+deb9u1
ii  libzstd1 1.1.2-1
ii  lsb-base 9.20161125
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages tor recommends:
ii  logrotate3.11.0-0.1
ii  tor-geoipdb  0.2.9.14-1
ii  torsocks 2.2.0-1+deb9u1

Versions of packages tor suggests:
pn  apparmor-utils   
pn  mixmaster
pn  obfs4proxy   
pn  obfsproxy
ii  socat1.7.3.1-2+deb9u1
ii  tor-arm  1.4.5.0-1.1
pn  torbrowser-launcher  

-- Configuration Files:
/etc/tor/torrc changed:

AccountingStart month 01 00:00
AccountingRule sum
AccountingMax 3500GB


-- no debconf information

Bug#888561: jessie-pu: package nvidia-graphics-modules/340.106+3.16.0+1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
Control: block -1 with 887559

For the new kernel ABI (5) and the updated nvidia-graphics-drivers
(jessie-pu request #887559) we need to regenerate the prebuilt kernel
modules. Due to the kernel ABI change, some packages will get renamed.


Andreas
diff --git a/debian/changelog b/debian/changelog
index 4dca75f..65d68e9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+nvidia-graphics-modules (340.106+3.16.0+1) jessie; urgency=medium
+
+  * Build for Linux 3.16.0 (ABI 5).
+  * Use nvidia-kernel-source 340.106.
+  * Switch Vcs-* URLs to salsa.debian.org.
+  * Upload to jessie.
+
+ -- Andreas Beckmann   Sat, 27 Jan 2018 04:23:41 +0100
+
 nvidia-graphics-modules (340.102+3.16.0+1) jessie; urgency=medium
 
   * Use nvidia-kernel-source 340.102.
diff --git a/debian/control b/debian/control
index a86e969..28837b4 100644
--- a/debian/control
+++ b/debian/control
@@ -7,18 +7,18 @@ Uploaders:
  Andreas Beckmann ,
  Vincent Cheng 
 Build-Depends: debhelper (>= 9),
- linux-headers-3.16.0-4-amd64 [i386 amd64], linux-headers-3.16.0-4-586 [i386], 
linux-headers-3.16.0-4-686-pae [i386],
- nvidia-kernel-source (>= 340.102), nvidia-kernel-source (<< 340.102.~),
+ linux-headers-3.16.0-5-amd64 [i386 amd64], linux-headers-3.16.0-5-586 [i386], 
linux-headers-3.16.0-5-686-pae [i386],
+ nvidia-kernel-source (>= 340.106), nvidia-kernel-source (<< 340.106.~),
 Standards-Version: 3.9.6
 Homepage: http://www.nvidia.com/
-Vcs-Git: git://anonscm.debian.org/pkg-nvidia/nvidia-graphics-modules.git -b 
jessie
-Vcs-Browser: 
https://anonscm.debian.org/cgit/pkg-nvidia/nvidia-graphics-modules.git
+Vcs-Browser: https://salsa.debian.org/nvidia-team/nvidia-graphics-modules
+Vcs-Git: https://salsa.debian.org/nvidia-team/nvidia-graphics-modules.git -b 
jessie
 XS-Autobuild: yes
 
 Package: nvidia-kernel-dummy
 Architecture: amd64
 Priority: extra
-Depends: nvidia-kernel-source (>= 340.102), ${misc:Depends}
+Depends: nvidia-kernel-source (>= 340.106), ${misc:Depends}
 Description: NVIDIA kernel module for Linux (dummy package)
  This dummy package exists solely to ensure that the prebuilt modules do not
  migrate to testing before the corresponding driver is available. Nothing is
@@ -39,7 +39,7 @@ Description: NVIDIA kernel module for Linux (dummy package)
 
 Package: nvidia-kernel-amd64
 Architecture: i386 amd64
-Depends: ${misc:Depends}, nvidia-kernel-3.16.0-4-amd64 (>= 340.102)
+Depends: ${misc:Depends}, nvidia-kernel-3.16.0-5-amd64 (>= 340.106)
 Conflicts: nvidia-kernel-2.6-amd64
 Replaces: nvidia-kernel-2.6-amd64
 Description: NVIDIA kernel module for Linux (amd64 flavor)
@@ -48,7 +48,7 @@ Description: NVIDIA kernel module for Linux (amd64 flavor)
  Install this package to automatically install the latest NVIDIA module
  when new versions of the kernel are released.
 
-Package: nvidia-kernel-3.16.0-4-amd64
+Package: nvidia-kernel-3.16.0-5-amd64
 Architecture: i386 amd64
 Depends: ${misc:Depends}
 Description: NVIDIA binary kernel module (amd64 flavor)
@@ -57,7 +57,7 @@ Description: NVIDIA binary kernel module (amd64 flavor)
 
 Package: nvidia-kernel-586
 Architecture: i386
-Depends: ${misc:Depends}, nvidia-kernel-3.16.0-4-586 (>= 340.102)
+Depends: ${misc:Depends}, nvidia-kernel-3.16.0-5-586 (>= 340.106)
 Conflicts: nvidia-kernel-2.6-586
 Replaces: nvidia-kernel-2.6-586
 Description: NVIDIA kernel module for Linux (586 flavor)
@@ -66,7 +66,7 @@ Description: NVIDIA kernel module for Linux (586 flavor)
  Install this package to automatically install the latest NVIDIA module
  when new versions of the kernel are released.
 
-Package: nvidia-kernel-3.16.0-4-586
+Package: nvidia-kernel-3.16.0-5-586
 Architecture: i386
 Depends: ${misc:Depends}
 Description: NVIDIA binary kernel module (586 flavor)
@@ -75,7 +75,7 @@ Description: NVIDIA binary kernel module (586 flavor)
 
 Package: nvidia-kernel-686-pae
 Architecture: i386
-Depends: ${misc:Depends}, nvidia-kernel-3.16.0-4-686-pae (>= 340.102)
+Depends: ${misc:Depends}, nvidia-kernel-3.16.0-5-686-pae (>= 340.106)
 Conflicts: nvidia-kernel-2.6-686-pae
 Replaces: nvidia-kernel-2.6-686-pae
 Description: NVIDIA kernel module for Linux (686-pae flavor)
@@ -84,7 +84,7 @@ Description: NVIDIA kernel module for Linux (686-pae flavor)
  Install this package to automatically install the latest NVIDIA module
  when new versions of the kernel are released.
 
-Package: nvidia-kernel-3.16.0-4-686-pae
+Package: nvidia-kernel-3.16.0-5-686-pae
 Architecture: i386
 Depends: ${misc:Depends}
 Description: NVIDIA binary kernel module (686-pae flavor)
diff --git a/debian/control.md5sum b/debian/control.md5sum
index 0961922..4c5e190 100644
--- a/debian/control.md5sum
+++ b/debian/control.md5sum
@@ -1,7 +1,7 @@
-cd5a1006e343e3ae2ae05a7e0f9603ca  debian/control
-cebaad312eecf5eb135ccc2acc8525aa  debian/control.source
+37790ec17bedbf710c7dc2f61759da9a  debian/control
+6b6e7c6757d8dbfb1b687170d

Bug#733750: release?

[gustavo panizzo]

Hi

any idea when this will be released? I'd like add it to Recommends on uhexen2 


thanks!

--
IRC: gfa
GPG: 0X44BB1BA79F6C6333

Bug#888073: glibc: Support amd64 systems without /lib64

[Javier Serrano Polo]

X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net

El ds 27 de 01 de 2018 a les 03:17 +0100, Samuel Thibault va escriure:
> So you are hiding some things.

I do not understand. What do you think I am hiding? There are no hidden
symlinks. The file /lib64/ld-linux-x86-64.so.2 does not exist, unless
you create it.

> > The way I see the ABIs, /lib64/ld-linux-x86-64.so.2, /lib/ld.so.1,
> > /libexec/ld-elf.so.1, etc. are magic strings, not requirements for the
> > filesystem.
> 
> That's hiding the actual ABI meaning.

I do not think so. The ABI is just an interface, it says: "My executable
will ask for this interpreter". I say: "Okay, let me handle the
implementation details".

I will not hide this fact. Tools like gdb and valgrind fail with /lib64
programs, which is not a problem since I usually recompile to fix a bug
or a leak. In the unusual case that I must audit /lib64 programs, I grab
a read-write environment and add a symlink. If there were complaints, I
would adapt those tools.


smime.p7s
Description: S/MIME cryptographic signature

Bug#888559: lintian: another too generic python module file: /usr/lib/python2.7/dist-packages/backports/__init__.py

[Chris Lamb]

tags 888559 + pending
thanks

Thanks for the report! Fixed in Git:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=18a2ee48027d883f3f4c36f7da00f24825b1ec78


Regards,

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

Bug#888560: mpfi dependencies inconsistency

[Vincent Lefevre]

Package: src:mpfi
Version: 1.5.3+ds-1
Severity: serious
Justification: Policy 7.2

The current libmpfi-dev version is 1.5.3+ds-1+b1, which has:

Depends: libmpfi0 (= 1.5.3+ds-1+b1), libmpfi-dev-common (= 1.5.3+ds-1), 
libmpfr-dev, libgmp-dev

but libmpfi-dev-common 1.5.3+ds-1 has:

Recommends: libmpfi-dev (= 1.5.3+ds-1)

This is inconsistent.

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

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

libmpfi-dev-common depends on no packages.

Versions of packages libmpfi-dev-common recommends:
ii  libmpfi-dev  1.5.3+ds-1

libmpfi-dev-common suggests no packages.

-- no debconf information

Bug#888559: lintian: another too generic python module file: /usr/lib/python2.7/dist-packages/backports/__init__.py

[Andreas Beckmann]

Package: lintian
Version: 2.5.50.4
Severity: normal

Another candidate for the backlist of too generic filenames:
/usr/lib/python2.7/dist-packages/backports/__init__.py

Seen in python-backports-shutil-get-terminal-size 1.0.0-3 (stretch) and
python-backports.tempfile 1.0-1 (sid) (#888558)


Andreas

Bug#888558: python-backports.tempfile: ships file with generic name: /usr/lib/python2.7/dist-packages/backports/__init__.py

[Andreas Beckmann]

Package: python-backports.tempfile
Version: 1.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stable'.
It installed fine in 'stable', then the upgrade to 'sid' fails
because it tries to overwrite other packages files.

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package python-backports.tempfile.
  Preparing to unpack .../python-backports.tempfile_1.0-1_all.deb ...
  Unpacking python-backports.tempfile (1.0-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python-backports.tempfile_1.0-1_all.deb (--unpack):
   trying to overwrite 
'/usr/lib/python2.7/dist-packages/backports/__init__.py', which is also in 
package python-backports-shutil-get-terminal-size 1.0.0-3
  Errors were encountered while processing:
   /var/cache/apt/archives/python-backports.tempfile_1.0-1_all.deb

I don't think Breaks+Replaces is the correct approach to handle this very
generic file name.


cheers,

Andreas


python-backports-shutil-get-terminal-size=1.0.0-3_python-backports.tempfile=1.0-1.log.gz
Description: application/gzip

Bug#888073: glibc: Support amd64 systems without /lib64

[Samuel Thibault]

Javier Serrano Polo, on ven. 26 janv. 2018 21:55:52 +0100, wrote:
> In the case of amd64, there is a module which handles the
> well-known /lib64/ld-linux-x86-64.so.2. If I want to support those
> programs, I load the module with the
> alternative /lib/ld-linux-x86-64.so.2. It is like a symlink, but without
> touching the base filesystem and just for the purpose of finding an
> interpreter.

So you are hiding some things. Not the best thing to do, in my opinion.

> The way I see the ABIs, /lib64/ld-linux-x86-64.so.2, /lib/ld.so.1,
> /libexec/ld-elf.so.1, etc. are magic strings, not requirements for the
> filesystem.

That's hiding the actual ABI meaning.

Samuel

Bug#888557: eom-dev,gir1.2-eom-1.0: fails to upgrade from 'testing' - trying to overwrite /usr/lib/x86_64-linux-gnu/girepository-1.0/Eom-1.0.typelib, /usr/share/gir-1.0/Eom-1.0.gir

[Andreas Beckmann]

Package: eom-dev,gir1.2-eom-1.0
Version: 1.18.3-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package gir1.2-eom-1.0.
  Preparing to unpack .../42-gir1.2-eom-1.0_1.18.3-2_amd64.deb ...
  Unpacking gir1.2-eom-1.0 (1.18.3-2) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-CQq0kj/42-gir1.2-eom-1.0_1.18.3-2_amd64.deb (--unpack):
   trying to overwrite 
'/usr/lib/x86_64-linux-gnu/girepository-1.0/Eom-1.0.typelib', which is also in 
package gir1.2-eom 1.18.3-1
  Selecting previously unselected package eom-dev.
  Preparing to unpack .../43-eom-dev_1.18.3-2_amd64.deb ...
  Unpacking eom-dev (1.18.3-2) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-CQq0kj/43-eom-dev_1.18.3-2_amd64.deb (--unpack):
   trying to overwrite '/usr/share/gir-1.0/Eom-1.0.gir', which is also in 
package gir1.2-eom 1.18.3-1


cheers,

Andreas


gir1.2-eom=1.18.3-1_eom-dev=1.18.3-2.log.gz
Description: application/gzip

Bug#888556: libetsf-io-doc: fails to upgrade from 'testing' - trying to overwrite /usr/share/doc/libetsf-io-dev/AUTHORS

[Andreas Beckmann]

Package: libetsf-io-doc
Version: 1.0.4-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package libetsf-io-doc.
  Preparing to unpack .../libetsf-io-doc_1.0.4-2_all.deb ...
  Unpacking libetsf-io-doc (1.0.4-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libetsf-io-doc_1.0.4-2_all.deb (--unpack):
   trying to overwrite '/usr/share/doc/libetsf-io-dev/AUTHORS', which is also 
in package libetsf-io-dev 1.0.4-1.1+b3
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/libetsf-io-doc_1.0.4-2_all.deb

This is probably caused by a dh_installdocs behavior change in
debhelper compat level 11.


cheers,

Andreas


libetsf-io-dev=1.0.4-1.1+b3_libetsf-io-doc=1.0.4-2.log.gz
Description: application/gzip

Bug#878221: linux-image-4.9.0-4-amd64: Screen flickers randomly with Radeon R9 270X since upgrade from 4.9.0-3 to 4.9.0-4

[besy]

I realized that the kernel I suggested as workaround
(linux-image-4.9.0-3-amd64) didn't completely solve the flickering
problem. However, it made the flickering occur very rarely.

I can confirm that the kernel "4.14.0-3-amd64 #1 SMP Debian 4.14.13-1
(2018-01-14)" from stretch-backports causes no
flickering at all with my Dell U2415.

Bug#888484: clamav: Security release 0.99.3 available

[Bernhard Schmidt]

Control: unfixed 888484 0.99.3~beta2+dfsg-1
Control: fixed 888511 0.99.3~beta2+dfsg-1

Hi 

>> 
>> We've have started seeing unexpected clamd crashes on a high-traffic mail
>> system today, though I've been unable to isolate a test case. It's seems like
>> too much of a coincidence that these crashes start happening the day after a
>> security release was announced. We've implemented mitigations but an updated
>> package would be even better.
> 
> I *think* the crashes you obsereved might be due to FD desc issue. This
> was fixed in Stretch by chance but not in Jessie. However the remaining
> CVEs were not addressed yet and I'm looking into it…
> 
> [0] 
> http://blog.clamav.net/2018/01/update-on-recent-file-descriptors-issue.html

Indeed. There is a separate Bug#888511 for that, I have migrated the fixed 
Version above to avoid confusion.

Are you sure about the Stretch thing? Stretch contains 0.99.2 which should be 
affected by this bug. But I’m not 100% sure, as all my high traffic mail 
gateways are still running Jessie.

According to reports 0.99.3~beta2 was indeed not affected by the signature bug, 
so Buster/Sid where fine. What makes things even more confusing is that 0.99.3 
does not contain this fix, because 0.99.3 is 0.99.2+security fixes, while 
0.99.3~beta was a development tree that is now called 0.100 :-(

http://blog.clamav.net/2018/01/clamav-version-number-adjustment.html

Upstream announcement suggests you cannot do a clean switch from 0.99.3~beta to 
0.99.3

As previously mentioned, if you downloaded the beta version of ClamAV 0.99.3, 
you will need to completely uninstall it and do a fresh install with the 
production version of 0.99.3 as there are significant code differences


Bernhard

Bug#888555: clang-tools: fails to upgrade from 'sid' - trying to overwrite /usr/share/man/man1/clang-apply-replacements.1.gz

[Andreas Beckmann]

Package: clang-tools
Version: 1:5.0-41~exp2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package clang-tools.
  Preparing to unpack .../clang-tools_1%3a5.0-41~exp2_amd64.deb ...
  Unpacking clang-tools (1:5.0-41~exp2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/clang-tools_1%3a5.0-41~exp2_amd64.deb (--unpack):
   trying to overwrite '/usr/share/man/man1/clang-apply-replacements.1.gz', 
which is also in package clang 1:4.0-40
  Errors were encountered while processing:
   /var/cache/apt/archives/clang-tools_1%3a5.0-41~exp2_amd64.deb

Full list of conflicting files:

usr/share/man/man1/clang-apply-replacements.1.gz
usr/share/man/man1/clang-check.1.gz
usr/share/man/man1/clang-query.1.gz
usr/share/man/man1/sancov.1.gz
usr/share/man/man1/scan-build.1.gz
usr/share/man/man1/scan-view.1.gz


cheers,

Andreas


clang=1%4.0-40_clang-tools=1%5.0-41~exp2.log.gz
Description: application/gzip

Bug#888554: ITP: wxpython4.0 -- Python interface to the wxWidgets Cross-platform C++ GUI toolkit, Phoenix version

[Scott Talbert]

Package: wnpp
Severity: wishlist
Owner: Scott Talbert 

* Package name: wxpython4.0
  Version : 4.0.0
  Upstream Author : Robin Dunn 
* URL : https://www.wxpython.org/
* License : wxWindows Library License
  Programming Lang: Python
  Description : Python interface to the wxWidgets Cross-platform C++ GUI 
toolkit, Phoenix version

wxWidgets (formerly known as wxWindows) is a class library for C++ providing
GUI components and other facilities on several popular platforms (and some
unpopular ones as well).
.
This package provides a Python interface to the wxGTK library and the 
wxPython runtime support libraries.  This is the "Phoenix" 
implementation which now supports Python 3.

Bug#888243: Lack of /opt in base-files causes piuparts issues for in-house packages

[Santiago Vila]

On Fri, Jan 26, 2018 at 08:01:59PM -0500, Jeremy Bicha wrote:
> On Fri, Jan 26, 2018 at 7:46 PM, Santiago Vila  wrote:
> > If you still think this is wrong you should suggest an alternative way
> > to give users the freefom to remove those directories.
> 
> There was a proposal in the original #888243 bug for that,

Yes, the report suggested an extra package, but that's overkill.

> although I
> don't see much benefit in giving the people the freedom to remove
> these directories.

But I do. The FHS only requires those directories to exist in a newly
installed system. base-files ensures that those directories exist in a
newly installed system.

There are also other directories like /mnt or /media which are also
required by FHS and are also handled in exactly the same way
(i.e. created by postinst in the very first install), but they
have never made piuparts to complain because nobody was brave enough
to violate the FHS to the point of having files in /mnt or /media.

If you want those directories to exist at *all* times, not just in a
newly installed system, that would be only a personal preference, but
it would not be a FHS requirement anymore.

> > Otherwise, I will also respectfully disagree and will close this bug
> > again.
> 
> Could you not be so quick to close this bug?

Sure. Could you not be so quick to reopen it in the first place?

> Because of the piuparts
> regression, chrome-gnome-shell and all its recursive dependencies
> (like debian-edu) won't migrate to testing.

A simple "mkdir -p /etc/opt" in postrm would restore the directory and
make piuparts happy again. That would be simple and effective, and it's
what I would do.

Another option would be to support Firefox and Chromium only and
create a different package in contrib for Chrome.

Thanks.

Bug#888484: clamav: Security release 0.99.3 available

[Rob N ★]

On Sat, Jan 27, 2018, at 11:08 AM, Sebastian Andrzej Siewior wrote:
> I **think** the crashes you obsereved might be due to FD desc
> issue. This> was fixed in Stretch by chance but not in Jessie. However the
> remaining> CVEs were not addressed yet and I'm looking into it…

Yes, I found this too after reviewing discussion on clamav-users. I've
been running the latest daily.cvd on a test server this morning without
issue, which is a good enough solution for me at the moment.
I will of course be watching for updated packages, but it's definitiely
no long urgent.
Thanks you all for the pointers; I appreciate the assist :)

Rob N.

Bug#888552: stretch-pu: package clamav/0.99.2+dfsg-6+b1

[Sebastian Andrzej Siewior]

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

Clamav released 0.99.3. Recently upstream decided to release 0.99.2.1 as
a security hostfix release only. However they then decided not to use a
four digit version but three as usually and so the security hotfix is
now 0.99.3. 
In unstable we have 0.99.3~beta2 which was a pre-release of the upcomming
0.99.3 before they decided to release a security fix. So in unstable we
have a "beta2" which contains all the security fixes which are part of
their final 0.99.3 release.
Instead reverting all that stuff I prepared for the 0.99.3 I backported
the delta from 0.99.2..0.99.3 and prepared an incremental 0.99.2 release
for Stretch [0]. Clamav itself identifies as 0.99.3 because otherwise it
will complain about being too old.

Please find attached a debdiff. The official announcement is at [1].
If you prefer another way of dealing with this please let me know.

[0] A second pair of eyes wouldn't hurt, after all it is 2am here.
[1] http://blog.clamav.net/2018/01/clamav-0993-has-been-released.html

Sebastian
diff -Nru clamav-0.99.2+dfsg/debian/changelog clamav-0.99.2+dfsg/debian/changelog
--- clamav-0.99.2+dfsg/debian/changelog	2017-02-04 21:54:51.0 +0100
+++ clamav-0.99.2+dfsg/debian/changelog	2018-01-27 00:33:28.0 +0100
@@ -1,3 +1,13 @@
+clamav (0.99.2+dfsg-6+deb9u1) stretch; urgency=medium
+
+  * Apply security patches from 0.99.3 (Closes: #888484):
+- fixes for the following CVE's: CVE-2017-6418, CVE-2017-6420,
+  CVE-2017-12374, CVE-2017-12375, CVE-2017-12376, CVE-2017-12377,
+  CVE-2017-12378, CVE-2017-12379, CVE-2017-12380.
+   * Bump symbol version of cl_retflevel because CL_FLEVEL changed.
+
+ -- Sebastian Andrzej Siewior   Sat, 27 Jan 2018 00:33:28 +0100
+
 clamav (0.99.2+dfsg-6) unstable; urgency=medium
 
   * Fix detection of curl. Patch by Reiner Herrmann 
diff -Nru clamav-0.99.2+dfsg/debian/.git-dpm clamav-0.99.2+dfsg/debian/.git-dpm
--- clamav-0.99.2+dfsg/debian/.git-dpm	2017-01-30 21:27:33.0 +0100
+++ clamav-0.99.2+dfsg/debian/.git-dpm	2018-01-27 00:30:29.0 +0100
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-4a07f7933aad6b3f3e533fa69e5401d82415b319
-4a07f7933aad6b3f3e533fa69e5401d82415b319
+6d775ed287a80b1a7e26cff79a2519982267c66f
+6d775ed287a80b1a7e26cff79a2519982267c66f
 48a96d2a3f0f4aca12f39f62a53fe1671a6e15a2
 48a96d2a3f0f4aca12f39f62a53fe1671a6e15a2
 clamav_0.99.2+dfsg.orig.tar.xz
diff -Nru clamav-0.99.2+dfsg/debian/libclamav7.symbols clamav-0.99.2+dfsg/debian/libclamav7.symbols
--- clamav-0.99.2+dfsg/debian/libclamav7.symbols	2017-01-30 21:27:31.0 +0100
+++ clamav-0.99.2+dfsg/debian/libclamav7.symbols	2018-01-27 00:33:28.0 +0100
@@ -63,7 +63,7 @@
  cl_load_cert@CLAMAV_PRIVATE 0.99.2
  cl_load_crl@CLAMAV_PRIVATE 0.99.2
  cl_retdbdir@CLAMAV_PUBLIC 0.99~rc1
- cl_retflevel@CLAMAV_PUBLIC 0.99.1
+ cl_retflevel@CLAMAV_PUBLIC 0.99.2+dfsg-6+deb9u1
  cl_retver@CLAMAV_PUBLIC 0.99~rc1
  cl_scandesc@CLAMAV_PUBLIC 0.99~rc1
  cl_scandesc_callback@CLAMAV_PUBLIC 0.99~rc1
diff -Nru clamav-0.99.2+dfsg/debian/patches/b11939-adding-fix-as-recommended-by-bug-reporter-alo.patch clamav-0.99.2+dfsg/debian/patches/b11939-adding-fix-as-recommended-by-bug-reporter-alo.patch
--- clamav-0.99.2+dfsg/debian/patches/b11939-adding-fix-as-recommended-by-bug-reporter-alo.patch	1970-01-01 01:00:00.0 +0100
+++ clamav-0.99.2+dfsg/debian/patches/b11939-adding-fix-as-recommended-by-bug-reporter-alo.patch	2018-01-27 00:30:30.0 +0100
@@ -0,0 +1,75 @@
+From c9bcbeb72bd8966bec18e5c3ad8efd0409e712c5 Mon Sep 17 00:00:00 2001
+From: Micah Snyder 
+Date: Sun, 29 Oct 2017 17:35:00 -0400
+Subject: b11939: adding fix as recommended by bug reporter along with a couple
+ extra lines to ensure freed pointers are set to NULL.
+
+Patch-Name: b11939-adding-fix-as-recommended-by-bug-reporter-alo.patch
+---
+ libclamav/mbox.c|  2 +-
+ libclamav/message.c |  4 +++-
+ libclamav/text.c| 10 +++---
+ 3 files changed, 11 insertions(+), 5 deletions(-)
+
+diff --git a/libclamav/mbox.c b/libclamav/mbox.c
+index 96bdbd2..8e48bb7 100644
+--- a/libclamav/mbox.c
 b/libclamav/mbox.c
+@@ -2067,7 +2067,7 @@ parseEmailBody(message *messageIn, text *textIn, mbox_ctx *mctx, unsigned int re
+  * bother saving to scan, it's safe
+  */
+ saveIt = (bool)(encodingLine(mainMessage) != NULL);
+-			else if((t_line = encodingLine(mainMessage)) != NULL) {
++			else if(mainMessage->body_last != NULL && (t_line = encodingLine(mainMessage)) != NULL) {
+ /*
+  * Some bounces include the message
+  * body without the headers.
+diff --git a/libclamav/message.c b/libclamav/message.c
+index 3856bfe..8afe800 100644
+--- a/libclamav/message.c
 b/libclamav/message.c
+@@ -1068,8 +1068,10 @@ messageMoveText(message *m, text *t, message *old_message)
+ 			for(u = old_message->body_first; u != t;) {
+ text *next;
+ 
+-if(u->t_line)
++if(u->t_l

Bug#888553: jessie-pu: package clamav/0.99.2+dfsg-0+deb8u2

[Sebastian Andrzej Siewior]

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

Clamav released 0.99.3. Recently upstream decided to release 0.99.2.1 as
a security hostfix release only. However they then decided not to use a
four digit version but three as usually and so the security hotfix is
now 0.99.3.
In unstable we have 0.99.3~beta2 which was a pre-release of the upcomming
0.99.3 before they decided to release a security fix. So in unstable we
have a "beta2" which contains all the security fixes which are part of
their final 0.99.3 release.
Instead reverting all that stuff I prepared for the 0.99.3 I backported
the delta from 0.99.2..0.99.3 and prepared an incremental 0.99.2 release
for Jessie [0]. Clamav itself identifies as 0.99.3 because otherwise it
will complain about being too old.
I synced the queue with Stretch. One patch (which is new) the one
addressing upstream bug#11549 [1] which triggered today. Upstream forgot
to include it in their 0.99.3 release and I had it already in
0.99.2+dfsg-5 (as of Stretch). While upstream claims that this won't
happen again with *their* signatures, it might happen with
others/community and it *did* trigger earlier [2].

Please find attached a debdiff. The official announcement is at [3].
If you prefer another way of dealing with this please let me know.

[0] A second pair of eyes wouldn't hurt, after all it is 2am here.
[1] http://blog.clamav.net/2018/01/update-on-recent-file-descriptors-issue.html
[2] https://bugs.debian.org/824196
[3] http://blog.clamav.net/2018/01/clamav-0993-has-been-released.html

Sebastian
diff -Nru clamav-0.99.2+dfsg/debian/changelog clamav-0.99.2+dfsg/debian/changelog
--- clamav-0.99.2+dfsg/debian/changelog	2016-06-06 23:23:31.0 +0200
+++ clamav-0.99.2+dfsg/debian/changelog	2018-01-27 01:29:24.0 +0100
@@ -1,3 +1,15 @@
+clamav (0.99.2+dfsg-0+deb8u3) jessie; urgency=medium
+
+  * Apply security patches from 0.99.3 (Closes: #888484):
+- fixes for the following CVE's: CVE-2017-6418, CVE-2017-6420,
+  CVE-2017-12374, CVE-2017-12375, CVE-2017-12376, CVE-2017-12377,
+  CVE-2017-12378, CVE-2017-12379, CVE-2017-12380.
+  * Bump symbol version of cl_retflevel because CL_FLEVEL changed.
+  * Cherry-pick patch from bb11549 to fix a temp file cleanup issue
+(Closes: #824196).
+
+ -- Sebastian Andrzej Siewior   Sat, 27 Jan 2018 01:29:24 +0100
+
 clamav (0.99.2+dfsg-0+deb8u2) stable; urgency=medium
 
   * Don't fail if AllowSupplementaryGroups is still set in the config file but
diff -Nru clamav-0.99.2+dfsg/debian/.git-dpm clamav-0.99.2+dfsg/debian/.git-dpm
--- clamav-0.99.2+dfsg/debian/.git-dpm	2016-06-06 22:10:43.0 +0200
+++ clamav-0.99.2+dfsg/debian/.git-dpm	2018-01-27 01:27:48.0 +0100
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-279c06a817c13eb22dc3ade949ea8b4a8aea9825
-279c06a817c13eb22dc3ade949ea8b4a8aea9825
+f77af4292400e7652f3cc358933d3b79adf9432e
+f77af4292400e7652f3cc358933d3b79adf9432e
 48a96d2a3f0f4aca12f39f62a53fe1671a6e15a2
 48a96d2a3f0f4aca12f39f62a53fe1671a6e15a2
 clamav_0.99.2+dfsg.orig.tar.xz
diff -Nru clamav-0.99.2+dfsg/debian/libclamav7.symbols clamav-0.99.2+dfsg/debian/libclamav7.symbols
--- clamav-0.99.2+dfsg/debian/libclamav7.symbols	2016-05-19 18:40:20.0 +0200
+++ clamav-0.99.2+dfsg/debian/libclamav7.symbols	2018-01-27 01:28:11.0 +0100
@@ -63,7 +63,7 @@
  cl_load_cert@CLAMAV_PRIVATE 0.99.2
  cl_load_crl@CLAMAV_PRIVATE 0.99.2
  cl_retdbdir@CLAMAV_PUBLIC 0.99~rc1
- cl_retflevel@CLAMAV_PUBLIC 0.99.1
+ cl_retflevel@CLAMAV_PUBLIC 0.99.2+dfsg-6+deb9u1
  cl_retver@CLAMAV_PUBLIC 0.99~rc1
  cl_scandesc@CLAMAV_PUBLIC 0.99~rc1
  cl_scandesc_callback@CLAMAV_PUBLIC 0.99~rc1
diff -Nru clamav-0.99.2+dfsg/debian/patches/b11939-adding-fix-as-recommended-by-bug-reporter-alo.patch clamav-0.99.2+dfsg/debian/patches/b11939-adding-fix-as-recommended-by-bug-reporter-alo.patch
--- clamav-0.99.2+dfsg/debian/patches/b11939-adding-fix-as-recommended-by-bug-reporter-alo.patch	1970-01-01 01:00:00.0 +0100
+++ clamav-0.99.2+dfsg/debian/patches/b11939-adding-fix-as-recommended-by-bug-reporter-alo.patch	2018-01-27 01:27:48.0 +0100
@@ -0,0 +1,75 @@
+From a0b8b7e0408029869fbb85353d9f53d3347e20e7 Mon Sep 17 00:00:00 2001
+From: Micah Snyder 
+Date: Sun, 29 Oct 2017 17:35:00 -0400
+Subject: b11939: adding fix as recommended by bug reporter along with a couple
+ extra lines to ensure freed pointers are set to NULL.
+
+Patch-Name: b11939-adding-fix-as-recommended-by-bug-reporter-alo.patch
+---
+ libclamav/mbox.c|  2 +-
+ libclamav/message.c |  4 +++-
+ libclamav/text.c| 10 +++---
+ 3 files changed, 11 insertions(+), 5 deletions(-)
+
+diff --git a/libclamav/mbox.c b/libclamav/mbox.c
+index 96bdbd2..8e48bb7 100644
+--- a/libclamav/mbox.c
 b/libclamav/mbox.c
+@@ -2067,7 +2067,7 @@ parseEmailBody(message *messageIn, text *textIn, mbox_ctx *mctx, unsigned int re
+  * bother saving to scan, it's safe
+  */
+ saveIt = 

Bug#888243: Lack of /opt in base-files causes piuparts issues for in-house packages

[Jeremy Bicha]

On Fri, Jan 26, 2018 at 7:46 PM, Santiago Vila  wrote:
> If you still think this is wrong you should suggest an alternative way
> to give users the freefom to remove those directories.

There was a proposal in the original #888243 bug for that, although I
don't see much benefit in giving the people the freedom to remove
these directories.

> Otherwise, I will also respectfully disagree and will close this bug
> again.

Could you not be so quick to close this bug? Because of the piuparts
regression, chrome-gnome-shell and all its recursive dependencies
(like debian-edu) won't migrate to testing.

Thanks,
Jeremy Bicha

Bug#888551: salt FTBFS: UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 828: ordinal not in range(128)

[Adrian Bunk]

Source: salt
Version: 2017.7.2+dfsg1-1
Severity: serious

https://buildd.debian.org/status/fetch.php?pkg=salt&arch=all&ver=2017.7.2%2Bdfsg1-1&stamp=1516915304&raw=0

...
==
ERROR: test_list_products (unit.modules.test_zypper.ZypperTestCase)
[CPU:0.0%|MEM:23.2%] 
--
Traceback (most recent call last):
  File "/<>/salt-2017.7.2+dfsg1/tests/unit/modules/test_zypper.py", 
line 236, in test_list_products
'stdout': get_test_data(filename)
  File "/<>/salt-2017.7.2+dfsg1/tests/unit/modules/test_zypper.py", 
line 53, in get_test_data
return rfh.read()
  File "/usr/lib/python3.6/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 828: 
ordinal not in range(128)

==
ERROR: test_non_ascii (unit.templates.test_jinja.TestGetTemplate)
[CPU:0.0%|MEM:23.2%] 
--
Traceback (most recent call last):
  File "/<>/salt-2017.7.2+dfsg1/tests/unit/templates/test_jinja.py", 
line 341, in test_non_ascii
result = fp.read()
  File "/usr/lib/python3.6/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 5: ordinal 
not in range(128)

==
ERROR: test_non_ascii_encoding (unit.templates.test_jinja.TestGetTemplate)
[CPU:0.0%|MEM:23.2%] 
--
Traceback (most recent call last):
  File "/<>/salt-2017.7.2+dfsg1/tests/unit/templates/test_jinja.py", 
line 303, in test_non_ascii_encoding
fp_.read(),
  File "/usr/lib/python3.6/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 5: ordinal 
not in range(128)

--
Ran 5870 tests in 702.684s

FAILED (errors=3, skipped=1503, expected failures=2)
debian/rules:18: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1

Bug#888302: recollgui,recollcmd: missing Breaks+Replaces: recoll (<< 1.23.7-2)

[Andreas Beckmann]

On 2018-01-27 00:33, Kartik Mistry wrote:
> hmm. Wondering why this is happening. Both package mentions Breaks +
> Replaces in debian/control.
> 
> Package: recollcmd
> Breaks: recoll (<< 1.23.7-1)
> Replaces: recoll (<< 1.23.7-1)

Which is the wrong version, since the split happened in -2, see Subject.


Andreas

Bug#888243: Lack of /opt in base-files causes piuparts issues for in-house packages

[Santiago Vila]

On Fri, Jan 26, 2018 at 07:28:34PM -0500, Jeremy Bicha wrote:
> If /etc/opt/ is required by FHS, then shouldn't base-files own /etc/opt/ ?

No, not necessarily. The directories are only required to exist in a
newly installed system.

I want users to have the freedom to remove them without those
directories being created on base-files upgrades over and over again.

(This is explained in /usr/share/doc/base-files/FAQ).

BTW: Those directories are not the only ones which are not owned by
base-files in the "dpkg -S" sense. See postinst for details.

If you still think this is wrong you should suggest an alternative way
to give users the freefom to remove those directories.

Otherwise, I will also respectfully disagree and will close this bug
again.

Thanks.

Bug#888546: gnome-chrom-shell: After purging files have disappeared: /etc/opt/ owned by: chrome-gnome-shell

[Guillem Jover]

Hi!

On Sat, 2018-01-27 at 00:14:21 +0100, Holger Levsen wrote:
> Package: base,chrome-gnome-shell
> Severity: important

> from #debian-edu and #-release just now:
> 
>  
> https://piuparts.debian.org/sid/fail/education-desktop-gnome_2.10.14.log 
> fails with
>  17m25.6s ERROR: FAIL: After purging files have disappeared:
>/etc/opt/ owned by: chrome-gnome-shell
>  hmm. thats not coming from src:debian-edu 
>  yeah, 
> https://piuparts.debian.org/sid/fail/chrome-gnome-shell_9-2.log is to blame
>  h01ger: I don't think it's chrome-gnome-shell's fault
>  FAIL: After purging files have disappeared: /etc/opt/ owned by: 
> chrome-gnome-shell
>  that directory is created by base-files but chrome-gnome-shell is 
> the first Debian package to include something there
>  I don't know enough about this situation to know how to fix the issue
>  we should probably file a bug against base,chrome-gnome-shell
>  chrome-gnome-shell uses that directory because that's where the 
> official Google Chrome looks for overrides
>  maybe dpkg? I don't know
>  I'm fine with you filing a chrome-gnome-shell bug. I'm guessing that 
> the ultimate fix will be somewhere else
> 
> Filing this with severity important as this introduces a piuparts
> regression which becomes a britney migration blocker.

The problem is that base-files does not own those pathnames (in
the dpkg sense), it just creates them from its postinst, so when
chrome-gnome-shell gets installed, from dpkg's PoV, it's the only
one owning them, and on purge they get removed on last reference.

Thanks,
Guillem

Bug#888549: chrome-gnome-shell: Please don't use /etc/opt, it's not FHS-compliant

[Santiago Vila]

On Sat, Jan 27, 2018 at 12:15:38AM +, Simon McVittie wrote:
> On Sat, 27 Jan 2018 at 00:46:27 +0100, Santiago Vila wrote:
> > It has come to my attention (via Bug #888243) than this package uses 
> > /etc/opt.
> > 
> > The opt directories exist for "add-on" packages, i.e. those who are
> > not provided by Debian.
> 
> chrome-gnome-shell uses /etc/opt to get itself loaded by Chrome, and for
> no other reason. It's the inverse of how Chrome (which correctly uses
> /{,etc/,var/}opt for its main content) has to put its .desktop file in
> /usr/{local/,}share/applications, because FHS-compliant desktop
> environments don't look for .desktop files in /opt.
> 
> Is there a way it can be loaded by Chrome without dropping integration
> files into the directory Chrome is going to look in?

I have no idea. Maybe we should ask Google to build Chrome without the
opt thing (while opt is for add-on packages, using opt is not
mandatory for add-on packages).

> (chrome-gnome-shell is simultaneously an extension for Chrome, Chromium
> and Firefox, so it installs appropriate integration files for all three
> into /etc/opt/chrome, /etc/chromium and /usr/lib/mozilla respectively.)

Ok, I was going to suggest "contrib" but since the package is also for
Chromium and Firefox, it would not make a lot of sense.

Anyway: Would "mkdir -p /etc/opt" in postrm solve the problem with piuparts?

Thanks.

Bug#888243: Lack of /opt in base-files causes piuparts issues for in-house packages

[Jeremy Bicha]

If /etc/opt/ is required by FHS, then shouldn't base-files own /etc/opt/ ?

I'm beginning to suspect that the problem here isn't
chrome-gnome-shell (see #888549) or Google Chrome or piuparts or these
in-house apps, but base-files for creating a directory in its postinst
instead of creating it in the usual way and owning the directory so
that dpkg won't remove the directory when uninstalling the last file
in the directory.

For archaeological reference, /etc/opt/ was added to base-files as a
result of #118505.

Thanks,
Jeremy Bicha

Bug#864809: Pending fixes for bugs in the gocryptfs package

[pkg-go-maintainers]

tag 864809 + pending
tag 868070 + pending
thanks

Some bugs in the gocryptfs package are closed in revision
af0f436694f9a17bcfddb9a1ad60c8a8372f12a8 in branch 'debian' by Felix
Lechner

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/gocryptfs.git/commit/?id=af0f436

Commit message:

Created new changelog entry for Debian revision 2
Imported upstream commits fixing FTBS on i386 (dirent size)
Built with new version of go-fuse (Closes: #864809)
Passed upstream version, go-fuse version and timestamp to build process 
(Closes: #868070)
Built with tag 'without_openssl'
Marked changelog for release

Bug#888549: chrome-gnome-shell: Please don't use /etc/opt, it's not FHS-compliant

[Simon McVittie]

On Sat, 27 Jan 2018 at 00:46:27 +0100, Santiago Vila wrote:
> It has come to my attention (via Bug #888243) than this package uses /etc/opt.
> 
> The opt directories exist for "add-on" packages, i.e. those who are
> not provided by Debian.

chrome-gnome-shell uses /etc/opt to get itself loaded by Chrome, and for
no other reason. It's the inverse of how Chrome (which correctly uses
/{,etc/,var/}opt for its main content) has to put its .desktop file in
/usr/{local/,}share/applications, because FHS-compliant desktop
environments don't look for .desktop files in /opt.

Is there a way it can be loaded by Chrome without dropping integration
files into the directory Chrome is going to look in?

(chrome-gnome-shell is simultaneously an extension for Chrome, Chromium
and Firefox, so it installs appropriate integration files for all three
into /etc/opt/chrome, /etc/chromium and /usr/lib/mozilla respectively.)

smcv

Bug#888484: clamav: Security release 0.99.3 available

[Sebastian Andrzej Siewior]

control: fixed -1  0.99.3~beta2+dfsg-1

On 2018-01-26 09:35:25 [+], Rob N wrote:
> Package: clamav
> Version: 0.99.2+dfsg-0+deb8u2
> Severity: important
> 
> 0.99.3 has been released, see 
> http://blog.clamav.net/2018/01/clamav-0993-has-been-released.html.
> 
> This fixed a number of overflow bugs, each of which has assigned CVE numbers
> due to the potential for denial of service.
> 
> We've have started seeing unexpected clamd crashes on a high-traffic mail
> system today, though I've been unable to isolate a test case. It's seems like
> too much of a coincidence that these crashes start happening the day after a
> security release was announced. We've implemented mitigations but an updated
> package would be even better.

I *think* the crashes you obsereved might be due to FD desc issue. This
was fixed in Stretch by chance but not in Jessie. However the remaining
CVEs were not addressed yet and I'm looking into it…

[0] http://blog.clamav.net/2018/01/update-on-recent-file-descriptors-issue.html

> Cheers!
> Rob N.

Sebastian

Bug#888549: chrome-gnome-shell: Please don't use /etc/opt, it's not FHS-compliant

[Jeremy Bicha]

On Fri, Jan 26, 2018 at 6:46 PM, Santiago Vila  wrote:
> It has come to my attention (via Bug #888243) than this package uses /etc/opt.
>
> The opt directories exist for "add-on" packages, i.e. those who are
> not provided by Debian.
>
> Well-behaved FHS-compliant packages should not use any of the opt
> directories (/opt, /etc/opt or /var/opt).

I respectfully disagree. chrome-gnome-shell ships a file in /etc/opt/
because that is where Google Chrome looks for overrides.

Please read https://bugs.debian.org/840235 and
https://bugs.debian.org/840804

Thanks,
Jeremy Bicha

Bug#753471: konqueror: Black picture when trying to play youtube videos using html5

[Pali Rohár]

Hi!

I fixed same problem on Debian Stretch by installing gstreamer1.0-libav and 
phonon-backend-gstreamer packages followed by system reboot.


It looks like there is a problem in KDE4/Qt4 version of Phonon to play mp4 
video contrainer and only gstreamer with libav plugin (libgstlibav.so) is 
able to do that for Phonon.


--
Pali Rohár
pali.ro...@gmail.com

Bug#888550: glm has some silly GCC version checks, removed upstream

[Matthias Klose]

Package: src:glm
Version: 0.9.8.4-1.1
Severity: serious
Tags: sid buster patch

glm has some silly GCC version checks, removed upstream

see https://launchpad.net/bugs/1745685

patch at
http://launchpadlibrarian.net/354819354/glm_0.9.8.4-1.1_0.9.8.4-1.1ubuntu1.diff.gz

Bug#888549: chrome-gnome-shell: Please don't use /etc/opt, it's not FHS-compliant

[Santiago Vila]

Package: chrome-gnome-shell
Version: 9-2

Dear maintainers:

It has come to my attention (via Bug #888243) than this package uses /etc/opt.

The opt directories exist for "add-on" packages, i.e. those who are
not provided by Debian.

Well-behaved FHS-compliant packages should not use any of the opt
directories (/opt, /etc/opt or /var/opt).

Thanks.

Bug#888243: Lack of /opt in base-files causes piuparts issues for in-house packages

[Santiago Vila]

On Wed, 24 Jan 2018, chrysn wrote:

> Package: base-files
> Version: 10.1
> Severity: normal
> 
> When a package gets installed and later uninstalled that places files in
> /opt (or /etc/opt), that directory gets removed because it was only used
> by that package and not owned by any. As a consequence, in-house
> packages (which can reasonably install to /opt/) can not pass piuparts
> as that complains about /opt and /etc/opt going away.
> 
> Now this could be fixed at several places (eg. dpkg could keep them
> around, or piupats could mask them), but keeping such directories around
> is typically done by base-files. The reason given in the FAQ for /opt
> just being added in postinst is that it should be possible for an admin
> to rmdir those -- a valid point, but causing inconvenience to packages
> going there.
> 
> The fix I'd suggest is to have a base-files-fhs package recommended by
> base-files but not required, which can be uninstalled if an admin wants
> those files gone.

That would be too much complexity for very very little gain.

A well behaved FHS-compliant Debian package should never use opt.

Therefore, this would only be a problem for non FHS-compliant packages.

I agree that passing the piuparts test is a good thing, but we should
follow FHS as well, not just pass the piuparts tests.

For Debian packages, if any, I strongly suggest that they are fixed to
comply with FHS. For in-house packages, a simple "mkdir -p /opt"
in postrm would make piuparts not to warn about /opt.

Thanks.

Bug#888531: transition: ruby2.5

[Emilio Pozuelo Monfort]

Control: forwarded -1 https://release.debian.org/transitions/html/ruby2.5.html

On 26/01/18 20:36, Antonio Terceiro wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi,
> 
> I would like to start the transition to ruby2.5 in unstable. General
> information about Ruby transitions can be found in:
> https://wiki.debian.org/Teams/Ruby/InterpreterTransitions
> 
> ruby2.5 has been in testing for a while.
> 
> Building against ruby2.5 has been enabled in experimental, and we
> already did a test rebuild against it, with pretty good results:
> https://hackmd.io/EYBghgHA7AjFDMBaCZgE5EBYYCYAmiaEAxhjgKzFQCmAZtGHtTkA
> 
> So I would like to enable building against ruby2.5 in unstable, and to
> effectively start the transition. Soon after we have a transition page,
> I will have a first round of binNMUs to request.

You mention 315 build failures in your report, but I only see 46 bugs in [1] and
[2] looks empty. Where are the rest of the bugs? Also, there are on ~150
packages affected in [3]. How many of those fail to build?

Cheers,
Emilio

[1] 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ruby2.5;users=debian-r...@lists.debian.org
[2] https://quickdeb.goeswhere.com/show-non-trivial.html
[3] https://release.debian.org/transitions/html/ruby2.5.html

Bug#888302: recollgui,recollcmd: missing Breaks+Replaces: recoll (<< 1.23.7-2)

[Kartik Mistry]

On Wed, Jan 24, 2018 at 11:45 AM, Andreas Beckmann  wrote:
> during a test with piuparts I noticed your package fails to upgrade from
> 'sid' to 'experimental'.
> It installed fine in 'sid', then the upgrade to 'experimental' fails
> because it tries to overwrite other packages files without declaring a
> Breaks+Replaces relation.
>
> See policy 7.6 at
> https://www.debian.org/doc/debian-policy/#overwriting-files-and-replacing-packages-replaces

hmm. Wondering why this is happening. Both package mentions Breaks +
Replaces in debian/control.

Package: recollcmd
Breaks: recoll (<< 1.23.7-1)
Replaces: recoll (<< 1.23.7-1)

and,

Package: recollgui
Breaks: recoll (<< 1.23.7-1)
Replaces: recoll (<< 1.23.7-1)

-- 
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com

Bug#888485: fixed in gjs 1.50.3-2

[Simon McVittie]

On Fri, 26 Jan 2018 at 21:38:20 +0100, Raphael Hertzog wrote:
> On Fri, 26 Jan 2018 17:37:32 + Simon McVittie  wrote:
> >* Revert some of the upstream changes from 1.50.3, which appear to
> >  cause crashes (Closes: #888485; possibly also #888052, #888199)
> 
> With this version, I no longer have the crash and I see errors logged

OK, that's a good start. Hopefully upstream can work out how to avoid
the crash while not reverting those three commits.

> Jan 26 21:28:01 kali-rolling org.gnome.Shell.desktop[885]: #0 0x56294fcf2b98 
> i   
> /usr/share/gnome-shell/extensions/places-m...@gnome-shell-extensions.gcampax.github.com/placeDisplay.js:146
>  (0x7f0c31806d58 @ 67)

This is the sort of logging you should have been getting as a result of
the remaining (non-reverted) changes in 1.50.3. It probably indicates
a bug in the Places extension's JS code.

#888485 is really two bugs:

* the Places extension continues to use objects after they've been
  destroyed (this is the Places extension's fault);
* when that happens, gjs treats it as an uncatchable exception instead
  of coping gracefully, for reasons I don't fully understand yet
  (this is gjs' fault)

I believe the first part is a known upstream bug in the Places extension,
which is already fixed upstream. I deliberately haven't applied that
change because this is the only way I was able to reproduce the second
part, which is believed to be related to #888052 and #888199 (which I
don't know how to reproduce or test).

Reverting the three commits that I reverted in 1.50.3-2 seems to avoid
the second part.

There are also bugs similar to the first part in gnome-shell itself,
although they don't cause crashes (that I've seen). Some or perhaps all
of them are fixed in experimental, including #887082 (I didn't fix those
in unstable yet, because that involves several unreviewed patches).

smcv

Bug#888548: kismet: Update to a more recent version

[Thomas Andrejak]

Source: kismet
Version: 2016.07.R1-1
Severity: wishlist

The actual version is 2016 and start to be old. Please update to a
more recent version.

Regards

Thanks

Thomas

Bug#872998: transition: php7.2

[Emilio Pozuelo Monfort]

On 25/01/18 12:55, Emilio Pozuelo Monfort wrote:
> Control: reopen -1
> Control: retitle -1 transition: php7.2
> Control: forwarded -1 https://release.debian.org/transitions/html/php7.2.html
> 
> On 25/01/18 12:27, Debian Bug Tracking System wrote:
>>  php-defaults (60) unstable; urgency=medium
>>  .
>>* Start the soft-transition to PHP 7.2 by adding 7.2 to a list of
>>  supported versions and making PHP 7.2 the default Debian version
>>  (Closes: #872998)
> 
> This is not fixed yet. Let's keep it open until the transition is finished.

Now that php7.2 is built and php-defaults has been updated, can I schedule the
binNMUs?

Cheers,
Emilio

Bug#888547: CVE-2017-1000190

[Moritz Muehlenhoff]

Source: simple-xml
Severity: important
Tags: security

CVE-2017-1000190 has been assigned to this bug in simple-xml:
https://github.com/ngallagher/simplexml/issues/18

Cheers,
Moritz

Bug#888546: gnome-chrom-shell: After purging files have disappeared: /etc/opt/ owned by: chrome-gnome-shell

[Holger Levsen]

Package: base,chrome-gnome-shell
Severity: important

hi,

from #debian-edu and #-release just now:

 
https://piuparts.debian.org/sid/fail/education-desktop-gnome_2.10.14.log fails 
with
 17m25.6s ERROR: FAIL: After purging files have disappeared:
   /etc/opt/ owned by: chrome-gnome-shell
 hmm. thats not coming from src:debian-edu 
 yeah, https://piuparts.debian.org/sid/fail/chrome-gnome-shell_9-2.log 
is to blame
 h01ger: I don't think it's chrome-gnome-shell's fault
 FAIL: After purging files have disappeared: /etc/opt/ owned by: 
chrome-gnome-shell
 that directory is created by base-files but chrome-gnome-shell is the 
first Debian package to include something there
 I don't know enough about this situation to know how to fix the issue
 we should probably file a bug against base,chrome-gnome-shell
 chrome-gnome-shell uses that directory because that's where the 
official Google Chrome looks for overrides
 maybe dpkg? I don't know
 I'm fine with you filing a chrome-gnome-shell bug. I'm guessing that 
the ultimate fix will be somewhere else

Filing this with severity important as this introduces a piuparts
regression which becomes a britney migration blocker.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#761404: minor Incompatibility between apparmor profile & tor configuration file

[Diane Trout]

Hi,

My system copy of tor wasn't starting in the background.

It was because I'd put some customizations into /etc/torrc.custom, (as
suggested by the comments at the bottom of /etc/tor/torrc. However the
apparmor profile in (abstractions/system_tor) limit tor to be able to
only read /etc/tor/.

Could either the config file suggest using /etc/tor/torrc.custom, or
modifying the apparmor profile to allow reading /etc/torrc.custom.

I wasn't sure if this should go to this open bug, or get its own new
wishlist bug.

Diane

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

Bug#888515: debian-installer: UEFI boot menu (grub) misses the help screen

[Steve McIntyre]

On Fri, Jan 26, 2018 at 02:13:30PM -0500, Lennart Sorensen wrote:
>On Fri, Jan 26, 2018 at 05:16:38PM +0100, Samuel Thibault wrote:
>> Hello Grub maintainers, any idea about this?
>
>Is this too much of a hack:
>
>



This is what I suggested to Samuel in irc earlier today, in fact. It's
a bit gross, but could work...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< liw> everything I know about UK hotels I learned from "Fawlty Towers"

Bug#888545: lists.debian.org: Request for new mailing list: debian-sagemath

[Tobias Hansen]

Package: lists.debian.org
Severity: wishlist

Dear listmasters,

With the upcoming shutdown of alioth, the Debian SageMath Team [1] needs a
new mailing list for discussions about the packaging effort.

The team maintains SageMath and many of its more than 100 dependencies [2].

The list would be for human traffic.

Also, we would like to import the archives and subscribers from our old list
debian-science-sagem...@lists.alioth.debian.org

I attached the list of subscribers, however it was not possible to obtain the 
archive
following the instructions on [3]. Could you help out with this?

Name: debian-sagemath
Short description: Maintaining SageMath and related software
Long description: Discussion and coordination of the maintenance of SageMath 
and its dependencies in Debian
Category: Developers
Subscription policy: open
Post policy: open
Web archive: yes

Thanks,
Tobias

[1] https://wiki.debian.org/DebianScience/Sage
[2] https://people.debian.org/~thansen/debian-sage-status.html 

[3] https://wiki.debian.org/Alioth#Moving_lists_to_lists.debian.org

bou...@debian.org
calcu...@rezozer.net
cl...@jhcloos.com
david.dou...@logilab.fr
dtorra...@piedmont.edu
frp.bis...@gmail.com
g...@debian.org
gor...@chronitis.net
halting.compl...@gmail.com
infini...@debian.org
jan.groenew...@gmail.com
jdeme...@cage.ugent.be
julien.pu...@laposte.net
khai...@mit.edu
m...@mezzarobba.net
paulo.cesar.pereira.de.andr...@gmail.com
samuel.lelie...@gmail.com
than...@debian.org
vincent.delecr...@u-bordeaux.fr
laurent.ba...@ut-capitole.fr
nmc...@chebucto.ns.ca

Bug#876592: gconf FTBFS with gtk-doc-tools 1.26: gtkdoc-mktmpl is no longer available

[John Paul Adrian Glaubitz]

Package: src:gconf
Followup-For: Bug #876592

Hi!

Since gconf is dead upstream, I don't think that someone will convert
the documentation format away from gtk-doc. I therefore just suggest
to turn off gtk-doc support for the time being until gconf can be
removed from the archives.

Attaching a suggested patch.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -Nru old/gconf-3.2.6/debian/control.in new/gconf-3.2.6/debian/control.in
--- old/gconf-3.2.6/debian/control.in   2016-10-11 16:56:10.0 +0200
+++ new/gconf-3.2.6/debian/control.in   2018-01-26 23:37:45.854551064 +0100
@@ -7,7 +7,6 @@
cdbs (>= 0.4.93),
dh-autoreconf,
gnome-pkg-tools (>= 0.14),
-   gtk-doc-tools (>= 1.0),
libglib2.0-dev (>= 2.31.0),
libdbus-1-dev (>= 1.0.0),
libdbus-glib-1-dev (>= 0.74),
diff -Nru old/gconf-3.2.6/debian/rules new/gconf-3.2.6/debian/rules
--- old/gconf-3.2.6/debian/rules2016-10-11 16:56:08.0 +0200
+++ new/gconf-3.2.6/debian/rules2018-01-26 23:38:03.939217937 +0100
@@ -21,7 +21,7 @@
 
 DEB_INSTALL_DOCS_gconf2 += doc/FAQ.txt NEWS README TODO
 
-DEB_CONFIGURE_EXTRA_FLAGS += --enable-gtk-doc \
+DEB_CONFIGURE_EXTRA_FLAGS += --disable-gtk-doc \
  --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) \
  --libexecdir=\$${libdir}/gconf \
  --with-gtk=3.0 \

Bug#880505: New upstream release and upload to unstable

[Michael Biebl]

Hi everyone

Am 26.01.2018 um 04:12 schrieb Sandro Tosi:
>> Is sponsored the upload of network-manager-fortisslvpn just the other day.
> 
> that's great, but does it work? all i can do is to import a PAC
> (what's a PAC?) script and i can never press save, hmmm

Tbh, I only looked at the packaging side of things for nm-fortisslvpn.
I don't have a setup where I could actually test it but I assume Lubo
did successfully test the package.

>> I completely missed that openfortivpn has not been uploaded to unstable
>> yet, so we now have network-manager-fortisslvpn in unstable which can't
>> migrate to testing as openfortivpn is not available in testing.
>>
>> Thus please consider making the upload.
> 
> done, 1.6.0 is in unstable

Thanks a lot


Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#888073: glibc: Support amd64 systems without /lib64

[Javier Serrano Polo]

X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net

El dv 26 de 01 de 2018 a les 22:27 +0100, Aurelien Jarno va escriure:
> It's an ugly solution and clearly not
> something we want to support, even as a build profile.

We have different views about what is ugly. Anyway, it is a maintainer's
choice, no problem. A wontfix tag would be appreciated.


smime.p7s
Description: S/MIME cryptographic signature

Bug#888543: webkit2gtk: Please reduce optimization level to -O1 on sh3 and sh4

[John Paul Adrian Glaubitz]

Source: webkit2gtk
Version: 2.18.6-1
Severity: normal
Tags: patch
User: debian-sup...@lists.debian.org
Usertags: sh3 sh4

Hi!

webkit2gtk currently FTBFS on sh3/sh4 due to an upstream gcc bug [1]:

/<>/Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.cpp:273:1: 
error: unable to find a register to spill in class 'R0_REGS'
 }
 ^
/<>/Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.cpp:273:1: 
error: this is the insn:
(insn 664 663 669 66 (parallel [
(set (subreg:SI (reg:QI 605) 0)
(unspec_volatile:SI [
(mem/v:QI (reg/f:SI 6 r6 [orig:706 _169 ] [706]) [-1  
S1 A8])
(reg:QI 5 r5 [598])
(subreg:QI (reg:SI 604) 0)
] UNSPECV_CMPXCHG_1))
(set (mem/v:QI (reg/f:SI 6 r6 [orig:706 _169 ] [706]) [-1  S1 A8])
(unspec_volatile:QI [
(const_int 0 [0])
] UNSPECV_CMPXCHG_2))
(set (reg:SI 147 t)
(unspec_volatile:SI [
(const_int 0 [0])
] UNSPECV_CMPXCHG_3))
(clobber (scratch:SI))
(clobber (reg:SI 0 r0))
(clobber (reg:SI 1 r1))
]) "/usr/include/c++/7/bits/atomic_base.h":434 403 
{atomic_compare_and_swapqi_soft_gusa}
 (expr_list:REG_DEAD (reg:SI 604)
(expr_list:REG_DEAD (reg:QI 5 r5 [598])
(expr_list:REG_UNUSED (reg:QI 605)
(expr_list:REG_UNUSED (reg:SI 1 r1)
(expr_list:REG_UNUSED (reg:SI 0 r0)
(nil)))
/<>/Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.cpp:273: 
confused by earlier errors, bailing out
Preprocessed source stored into /tmp/ccoGxdST.out file, please attach this to 
your bugreport.

While the upstream bug has not been fixed yet, it can be worked around by 
reducing
the optimization level on sh3/sh4 to -O1 which is what the attached patch does.

Would be nice if it could be applied for the next upload of webkit2gtk.

Thanks,
Adrian

> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81426
> [2] 
> https://buildd.debian.org/status/fetch.php?pkg=webkit2gtk&arch=sh4&ver=2.18.6-1&stamp=1516855725&raw=0

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -Nru old/webkit2gtk-2.18.6/debian/rules new/webkit2gtk-2.18.6/debian/rules
--- old/webkit2gtk-2.18.6/debian/rules  2018-01-24 12:30:06.0 +0100
+++ new/webkit2gtk-2.18.6/debian/rules  2018-01-26 22:57:39.257606655 +0100
@@ -25,6 +25,12 @@
CFLAGS := $(CFLAGS:-g=-g1)
 endif
 
+# See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81426
+ifneq (,$(filter $(DEB_HOST_ARCH),sh3 sh4))
+CFLAGS := $(CFLAGS:-O2=-O1)
+CXXFLAGS := $(CXXFLAGS:-O2=-O1)
+endif
+
 ifeq (,$(filter $(DEB_HOST_ARCH),i386 amd64 hurd-i386 kfreebsd-i386 
kfreebsd-amd64 armhf arm64))
EXTRA_CMAKE_ARGUMENTS += -DENABLE_JIT=OFF
 endif

Bug#888423: firefox: FF 58.0 segfaults each 1-2 minute

[Dmitry E. Oboukhov]

>> Package: firefox
>> Version: 58.0-1
>> Severity: grave
>> 
>> I used FF58b4, it works fine.
>> Then I upgraded it to FF58b14, it crashed from time to time.
>> 
>> Today I upgraded FF to 58.0, it crashes each 1 minute (see backtrace)
>> (see below).
>> 
>> I can't find `firefox-dbg` package, so the backtrace doesn't contain symbols.

> You can add
> deb http://deb.debian.org/debian-debug unstable-debug main
> to your sources.list and install the firefox-dbgsym package.


Thanks!

The full backtrace here:

(gdb) bt
#0  mozilla::ipc::MessageChannel::OnChannelErrorFromLink (this=0x7f2f2aee6128)
at /build/firefox-WvkEP5/firefox-58.0/ipc/glue/MessageChannel.cpp:2543
#1  0x7f2f1cd7954f in mozilla::ipc::ProcessLink::OnChannelError 
(this=0x7f2f15369df0)
at /build/firefox-WvkEP5/firefox-58.0/ipc/glue/MessageLink.cpp:397
#2  0x7f2f1a4e99ba in ?? () from /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6
#3  0x7f2f1a4ea537 in event_base_loop () from 
/usr/lib/x86_64-linux-gnu/libevent-2.1.so.6
#4  0x7f2f1cd5074e in base::MessagePumpLibevent::Run (this=0x7f2f2ae53e00, 
delegate=0x7f2f191c0d20)
at 
/build/firefox-WvkEP5/firefox-58.0/ipc/chromium/src/base/message_pump_libevent.cc:381
#5  0x7f2f1cd53000 in MessageLoop::RunInternal (this=0x7f2f191c0d20)
at 
/build/firefox-WvkEP5/firefox-58.0/ipc/chromium/src/base/message_loop.cc:326
#6  MessageLoop::RunHandler (this=0x7f2f191c0d20)
at 
/build/firefox-WvkEP5/firefox-58.0/ipc/chromium/src/base/message_loop.cc:319
#7  MessageLoop::Run (this=this@entry=0x7f2f191c0d20)
at 
/build/firefox-WvkEP5/firefox-58.0/ipc/chromium/src/base/message_loop.cc:299
#8  0x7f2f1cd5fa19 in base::Thread::ThreadMain (this=0x7f2f2ae2b528)
at /build/firefox-WvkEP5/firefox-58.0/ipc/chromium/src/base/thread.cc:181
#9  0x7f2f1cd5029a in ThreadFunc (closure=)
at 
/build/firefox-WvkEP5/firefox-58.0/ipc/chromium/src/base/platform_thread_posix.cc:38
#10 0x7f2f2c0bc494 in start_thread (arg=0x7f2f191c1700) at 
pthread_create.c:333
#11 0x7f2f2b661aff in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97


-- 

. ''`.Dmitry E. Oboukhov 
: :’  :
`. `~’   GPG key: 4096R/08EEA756 2014-08-30
  `- 71ED ACFC 6801 0DD9 1AD1  9B86 8D1F 969A 08EE A756


signature.asc
Description: PGP signature

Bug#812721: gbp could filter out Files-Excluded: entries when committing to the pristine-tar branch

[Michael Stapelberg]

I looked into implementing the discussed gbp import-git subcommand. Find
attached preliminary patches. In my tests, the new subcommand tags the
upstream branch and imports it correctly, but perhaps I missed something.
Filtering is not yet considered at all. Feedback/review welcome (or, feel
free to just run with them if that’s easier. I’m not fast with Python.)

One thing came up during the implementation to which I’d like your
feedback: if the upstream branch isn’t by chance already tagged with a
proper version number (e.g. v1.2), how do we get a suitable version number
for the git snapshot we’re about to package? We have such logic in
dh-make-golang:
https://github.com/Debian/dh-make-golang/blob/5a5180dce36c9c878b7551640ff018a6dfabf0dd/version.go#L19
— as you can see it’s rather complicated. I couldn’t find anything
comparable in git-buildpackage yet. Did I miss it? If no, could such logic
be added?

Thanks,

On Thu, Jan 25, 2018 at 1:04 PM, Michael Stapelberg 
wrote:

>
>
> On Thu, Jan 25, 2018 at 12:46 PM, Guido Günther  wrote:
>
>> Hi,
>> On Thu, Jan 25, 2018 at 10:25:09AM +0100, Raphael Hertzog wrote:
>> > > • branch “upstream/latest” tracks an upstream branch, e.g. remote
>> > > “upstream”, branch “master”.
>> > >
>> > > • branch “upstream/latest-filtered” contains a filtered version of
>> that
>> > > branch, whose commits would be tagged e.g. upstream/1.0+dfsg1 so that
>> > > gbp-buildpackage picks the correct commit.
>> > >
>> > > I think that complies with DEP14 as good as possible, and is still
>> > > reasonably clear for casual users. Thoughts?
>> >
>> > I would use "upstream-filtered/latest" for the latter. You have clean
>> > namespace separation. But this still changes the assumption about
>> > upstream/latest (non-filtered now) so it needs a broader discussion IMO.
>>
>> To add to the bikeshed: I like path like separation in git:
>>
>> upstream/filtered/latest
>>
>> or (since upstream is somewhat redundant):
>>
>
> I don’t feel that “upstream” is redundant. I think the contents of a
> branch should be obvious from the name.
>
>
>>
>> filtered/latest
>> pristine/latest
>>
>
> The “pristine” namespace could easily be confused with “pristine-tar”, so
> I’d prefer avoiding that name altogether if possible.
>
>
>>
>> this would also allow to retain upstream/ with the original meaning for
>>
>
> Wait, now I’m confused. Isn’t “upstream” the same as “upstream/latest”?
> What “original meaning” are you referring to? :)
>
>
>> existing projects and would make the switch of defaults easier since
>> gbp's current default upstream does not conflict with upstream/latest.
>>
>> Cheers,
>>  -- Guido
>>
>
>
>
> --
> Best regards,
> Michael
>



-- 
Best regards,
Michael
From 6c59a6b196382f846b48f1a4d650fa6937d360dc Mon Sep 17 00:00:00 2001
From: Michael Stapelberg 
Date: Fri, 26 Jan 2018 22:36:17 +0100
Subject: [PATCH 1/2] Copy import_orig.py to import_git.py

---
 gbp/scripts/import_git.py | 669 ++
 1 file changed, 669 insertions(+)
 create mode 100644 gbp/scripts/import_git.py

diff --git a/gbp/scripts/import_git.py b/gbp/scripts/import_git.py
new file mode 100644
index 000..97b6d54
--- /dev/null
+++ b/gbp/scripts/import_git.py
@@ -0,0 +1,669 @@
+# vim: set fileencoding=utf-8 :
+#
+# (C) 2006, 2007, 2009, 2011, 2015, 2016 Guido Guenther 
+#This program is free software; you can redistribute it and/or modify
+#it under the terms of the GNU General Public License as published by
+#the Free Software Foundation; either version 2 of the License, or
+#(at your option) any later version.
+#
+#This program is distributed in the hope that it will be useful,
+#but WITHOUT ANY WARRANTY; without even the implied warranty of
+#MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+#GNU General Public License for more details.
+#
+#You should have received a copy of the GNU General Public License
+#along with this program; if not, please see
+#
+#
+"""Import a new upstream version into a Git repository"""
+
+import os
+import shutil
+import sys
+import tempfile
+import time
+import gbp.command_wrappers as gbpc
+from gbp.deb import (DebianPkgPolicy, parse_changelog_repo)
+from gbp.deb.format import DebianSourceFormat
+from gbp.deb.upstreamsource import DebianUpstreamSource, unpack_component_tarball
+from gbp.deb.uscan import (Uscan, UscanError)
+from gbp.deb.changelog import ChangeLog, NoChangeLogError
+from gbp.deb.git import (GitRepositoryError, DebianGitRepository)
+from gbp.config import GbpOptionParserDebian, GbpOptionGroup, no_upstream_branch_msg
+from gbp.errors import GbpError
+from gbp.format import format_str
+from gbp.git.vfs import GitVfs
+import gbp.log
+from gbp.scripts.common import ExitCodes, is_download, get_component_tarballs
+from gbp.scripts.common.import_orig import (orig_needs_repack, cleanup_tmp_tree,
+ask_package_

Bug#888542: xcal: Missing patches due to 00List != 00list?

[Chris Lamb]

Package: xcal
Version: 4.1-19+b2
Severity: important

Hi,

You have a debian/patches/00List file - shouldn't this be
debian/patches/00list? :)


Regards,

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

Bug#888540: mclibs: Missing patches due to incomplete quilt conversion?

[Chris Lamb]

Package: mclibs
Version: 20061220+dfsg3-3.1
Severity: important

Hi,

You are using source format "3.0 (quilt)" but have a bunch of
dpatch patches in debian/patches along with a 00list instead
of a "series" file. 

Are the patches being applied? :)


Regards,

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

Bug#888541: paw: Missing patches due to incomplete quilt conversion?

[Chris Lamb]

Package: paw
Version: 1:2.14.04.dfsg.2-9.1+b1
Severity: important

Hi,

You are using source format "3.0 (quilt)" but have a bunch of
dpatch patches in debian/patches along with a 00list instead
of a "series" file. 

Are the patches being applied? :)


Regards,

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

Bug#888539: geant321: Missing patches due to incomplete quilt conversion?

[Chris Lamb]

Package: geant321
Version: 1:3.21.14.dfsg-11
Severity: important

You are using source format "3.0 (quilt)" but have a bunch of
dpatch patches in debian/patches along with a 00list instead
of a "series" file. 

Are the patches being applied? :)


Regards,

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

Bug#888538: cernlib: Missing patches due to incomplete quilt conversion?

[Chris Lamb]

Package: cernlib
Version: 20061220+dfsg3-4.3
Severity: important

Hi,

You are using source format "3.0 (quilt)" but have a bunch of
dpatch patches in debian/patches along with a 00list instead
of a "series" file. 

Are the patches being applied? :)


Regards,

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

Bug#888297: p7zip: CVE-2017-17969: ZIP Shrink: Heap Buffer Overflow

[Antoine Beaupre]

Control: tags -1 +patch

Since a fix was published in upstream 18.00-beta, I looked at the source
there and was able to produce a simple patch for wheezy, which should be
trivial to port to jessie and easy to port to stretch:

https://sourceforge.net/p/p7zip/bugs/_discuss/thread/0920f369/c296/attachment/CVE-2017-17969.patch

Attached as well.

Looks good?

A.
Subject: backport of the CVE-2017-17969 fix from 7zip 18.00-beta
Forwarded: https://sourceforge.net/p/p7zip/bugs/204/
Bug-Debian: http://bugs.debian.org/888297
Author: Antoine Beaupré 
Applied-Upstream: 18.00-beta
Last-Update: 2018-01-26

--- p7zip-9.20.1~dfsg.1/CPP/7zip/Compress/ShrinkDecoder.cpp.orig	2011-04-01 15:14:01.0 -0400
+++ p7zip-9.20.1~dfsg.1/CPP/7zip/Compress/ShrinkDecoder.cpp	2018-01-26 16:00:19.944166092 -0500
@@ -99,7 +99,13 @@
 corectionIndex = i;
   _stack[i++] = _suffixes[cur];
   cur = _parents[cur];
+  if (cur == kEmpty || i >= kNumItems)
+break;
 }
+
+if (cur == kEmpty || i >= kNumItems)
+  break;
+
 _stack[i++] = (Byte)cur;
 if (needPrev)
 {


signature.asc
Description: PGP signature

Bug#885670: kino: diff for NMU version 1.3.4-2.4

[Adrian Bunk]

Control: tags 885670 + pending

Dear maintainer,

I've prepared an NMU for kino (versioned as 1.3.4-2.4) and uploaded it 
to DELAYED/5. Please feel free to tell me if I should cancel it.

cu
Adrian

-- 

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

diff -u kino-1.3.4/debian/changelog kino-1.3.4/debian/changelog
--- kino-1.3.4/debian/changelog
+++ kino-1.3.4/debian/changelog
@@ -1,3 +1,11 @@
+kino (1.3.4-2.4) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Remove the unused libgnome2-dev and libgnomeui-dev
+build dependencies. (Closes: #885670)
+
+ -- Adrian Bunk   Fri, 26 Jan 2018 22:58:22 +0200
+
 kino (1.3.4-2.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u kino-1.3.4/debian/control kino-1.3.4/debian/control
--- kino-1.3.4/debian/control
+++ kino-1.3.4/debian/control
@@ -15,9 +15,7 @@
libdv4-dev,
libv4l-dev,
libavc1394-dev (>= 0.4.1),
-   libgnome2-dev,
libglade2-dev,
-   libgnomeui-dev,
libx11-dev,
libxt-dev,
libxv-dev,

Bug#888507: live-build: option to build against a distribution which is not the one enabled in the final image

[Raphael Hertzog]

Control: tag -1 + patch

On Fri, 26 Jan 2018, Raphaël Hertzog wrote:
> Much like we have --mirror-chroot and --mirror-binary, it would be nice to
> have --distribution-chroot and --distribution-binary so that we can build
> against a specific repository but have the final sources.list point to
> another repository.

I have implemented this for Kali and the attached patch works for me.
It still lacks some documentation update though.

It's not 100% transparent either, the LB_DISTRIBUTION_CHROOT is used
in the "dists" directory structure holding packages but in my tests
this codename is not used in the resulting installed systemd (and also not
in the live image). It might be possible to further improve this.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/
>From 05f3bd4b5ddea9bec36c78db7e0844f17fb41347 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= 
Date: Fri, 26 Jan 2018 17:15:08 +0100
Subject: [PATCH] Implement use of different distributions for build and
 runtime usage

---
 functions/defaults.sh| 20 
 functions/echo.sh|  2 +-
 scripts/build/binary_disk| 10 +++---
 scripts/build/binary_package-lists   |  6 ++--
 scripts/build/binary_syslinux|  4 +--
 scripts/build/bootstrap_archives | 26 +++
 scripts/build/bootstrap_debootstrap  |  6 ++--
 scripts/build/build  |  2 +-
 scripts/build/chroot_apt |  4 +--
 scripts/build/chroot_archives| 52 +++---
 scripts/build/chroot_firmware| 16 +-
 scripts/build/config | 55 +---
 scripts/build/installer_debian-installer | 36 -
 scripts/build/source_debian  |  6 ++--
 scripts/build/source_disk|  4 +--
 15 files changed, 146 insertions(+), 103 deletions(-)

diff --git a/functions/defaults.sh b/functions/defaults.sh
index 78ca358d1..a631d9703 100755
--- a/functions/defaults.sh
+++ b/functions/defaults.sh
@@ -128,18 +128,19 @@ Set_defaults ()
 			LB_DERIVATIVE="false"
 			;;
 	esac
+	LB_DISTRIBUTION_CHROOT="${LB_DISTRIBUTION_CHROOT:-${LB_DISTRIBUTION}}"
+	LB_DISTRIBUTION_BINARY="${LB_DISTRIBUTION_BINARY:-${LB_DISTRIBUTION_CHROOT}}"
+
 
 	case "${LB_MODE}" in
 		progress-linux)
 			case "${LB_DISTRIBUTION}" in
 baureo|baureo-backports)
 	LB_PARENT_DISTRIBUTION="${LB_PARENT_DISTRIBUTION:-wheezy}"
-	LB_PARENT_DEBIAN_INSTALLER_DISTRIBUTION="${LB_PARENT_DEBIAN_INSTALLER_DISTRIBUTION:-${LB_PARENT_DISTRIBUTION}}"
 	;;
 
 cairon|cairon-backports)
 	LB_PARENT_DISTRIBUTION="${LB_PARENT_DISTRIBUTION:-sid}"
-	LB_PARENT_DEBIAN_INSTALLER_DISTRIBUTION="${LB_PARENT_DEBIAN_INSTALLER_DISTRIBUTION:-${LB_PARENT_DISTRIBUTION}}"
 	;;
 			esac
 
@@ -147,12 +148,17 @@ Set_defaults ()
 			;;
 
 		*)
-			LB_PARENT_DISTRIBUTION="${LB_PARENT_DISTRIBUTION:-${LB_DISTRIBUTION}}"
-			LB_PARENT_DEBIAN_INSTALLER_DISTRIBUTION="${LB_PARENT_DEBIAN_INSTALLER_DISTRIBUTION:-${LB_PARENT_DISTRIBUTION}}"
-
 			LB_BACKPORTS="${LB_BACKPORTS:-false}"
 			;;
 	esac
+	if [ -n "$LB_PARENT_DISTRIBUTION" ]; then
+		LB_PARENT_DISTRIBUTION_CHROOT="${LB_PARENT_DISTRIBUTION_CHROOT:-${LB_PARENT_DISTRIBUTION}}"
+		LB_PARENT_DISTRIBUTION_BINARY="${LB_PARENT_DISTRIBUTION_BINARY:-${LB_PARENT_DISTRIBUTION}}"
+	else
+		LB_PARENT_DISTRIBUTION_CHROOT="${LB_PARENT_DISTRIBUTION_CHROOT:-${LB_DISTRIBUTION_CHROOT}}"
+		LB_PARENT_DISTRIBUTION_BINARY="${LB_PARENT_DISTRIBUTION_BINARY:-${LB_DISTRIBUTION_BINARY}}"
+	fi
+	LB_PARENT_DEBIAN_INSTALLER_DISTRIBUTION="${LB_PARENT_DEBIAN_INSTALLER_DISTRIBUTION:-${LB_PARENT_DISTRIBUTION_CHROOT}}"
 
 	# Setting package manager
 	LB_APT="${LB_APT:-apt}"
@@ -479,7 +485,7 @@ Set_defaults ()
 	LB_LINUX_PACKAGES="${LB_LINUX_PACKAGES:-linux-image}"
 
 	# Setting security updates option
-	case "${LB_PARENT_DISTRIBUTION}" in
+	case "${LB_PARENT_DISTRIBUTION_BINARY}" in
 		sid)
 			LB_SECURITY="${LB_SECURITY:-false}"
 			;;
@@ -490,7 +496,7 @@ Set_defaults ()
 	esac
 
 	# Setting updates updates option
-	case "${LB_PARENT_DISTRIBUTION}" in
+	case "${LB_PARENT_DISTRIBUTION_BINARY}" in
 		sid)
 			LB_UPDATES="${LB_UPDATES:-false}"
 			;;
diff --git a/functions/echo.sh b/functions/echo.sh
index 96b742cef..40e76ea6e 100755
--- a/functions/echo.sh
+++ b/functions/echo.sh
@@ -193,7 +193,7 @@ Echo_file ()
 
 Echo_breakage ()
 {
-	case "${LB_PARENT_DISTRIBUTION}" in
+	case "${LB_PARENT_DISTRIBUTION_BINARY}" in
 		sid)
 			Echo_message "If the following stage fails, the most likely cause of the problem is with your mirror configuration, a caching proxy or the sid distribution."
 			;;
diff --git a/scripts/build/binary_disk b/scripts/build/binary_disk
index 7175a543a..d9fefa4b0 100755
--- a/scripts/build/binary_disk
+++ b/scripts/build/binary_disk
@@ -49,8 

Bug#888073: glibc: Support amd64 systems without /lib64

[Javier Serrano Polo]

X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net, m...@suse.de, j...@suse.cz, 
a...@suse.de

El dv 26 de 01 de 2018 a les 20:10 +0100, Aurelien Jarno va escriure:
> It's probably not clear, let me try again. Your package provides a
> /lib/ld-linux-x86-64.so.2 -> /lib64/ld-linux-x86-64.so.2 symlink. As 2
> packages or more can't provide the same file, I conclude that to be able
> to install your package your program interpreter should be installed in
> /lib64 (and not in /lib), which is exactly what you want to avoid.

You are forgetting the claim that the example is countering. No matter
how, can a /lib/ld-linux-x86-64.so.2 program run on your system? Does
the provided package work on your system or not?

El dv 26 de 01 de 2018 a les 20:42 +0100, Samuel Thibault va escriure:
> How did it find an interpreter?

Now the workings; you may not like how it works, but it does. My kernel
acknowledges the fact that third-party programs may require interpreters
that do not exist, which is a problem if the base filesystem cannot be
modified. If the interpreter does not exist, the kernel asks for
alternatives.

In the case of amd64, there is a module which handles the
well-known /lib64/ld-linux-x86-64.so.2. If I want to support those
programs, I load the module with the
alternative /lib/ld-linux-x86-64.so.2. It is like a symlink, but without
touching the base filesystem and just for the purpose of finding an
interpreter.

The way I see the ABIs,
/lib64/ld-linux-x86-64.so.2, /lib/ld.so.1, /libexec/ld-elf.so.1, etc.
are magic strings, not requirements for the filesystem. It is a kind of
binfmt-support solution.


smime.p7s
Description: S/MIME cryptographic signature

Bug#878614: linux-image-4.13.0-1-amd64: unexpected IRQ trap at vector e8 on Intel NUC H26998-401

[Daniel Kahn Gillmor]

On Sat 2017-10-14 22:17:29 -0400, Daniel Kahn Gillmor wrote:
> Trying to boot this machine into 4.13.0-1-amd64 results in several kernel 
> messages like:
>
> unexpected IRQ trap at vector e8
>
> per second, and basic system services take ages to start (including
> journald, which means i don't have a clear log of the error messages
> at the moment).
>
> rebooting into 4.11.0-2-amd64 produces no such error.  The machine is
> already running irqbalance 1.1.0-2.3, fwiw.

fwiw, this bug went away once i upgraded the BIOS of the machine.

the old bios was:

TYBYT10H.86A.0019.2014.0327.1516

The new bios is:

TYBYT10H.86A.0061.2017.1011.1904

After this upgrade, new kernels boot just fine.

The bios file i installed was TY10H0061.bio, with sha256
2b841a072ce65b1b73cb494b7d291e11c245b7373c601559f5547981a10c9543

This apparently also improved the onboard DRAM controller so that it's
now operating at 1600MHz (0.6 ns) instead of 1066MHz (0.9 ns).

So, i think this was a hardware problem, and not a problem with the
kernel, so i'm closing this bug report.  I don't know why the newer
kernels had the problem with this hardware but older ones didn't.  ah well.

hope this info helps,

 --dkg



signature.asc
Description: PGP signature

Bug#884217: thunderbird: Latest VCS-Git AppArmor profile (will) break aa-enfroce usage on Jessie

[Carsten Schoenert]

Hello Vincas,

On Fri, Jan 26, 2018 at 08:43:52PM +0200, Vincas Dargis wrote:
> May I provide `patches/fixes/fix-jessie-apparmor-parser-error.patch` for a 
> `jessie` branch, or something like that?

if you have something prepared and ready why not, I need to prepare
jessie and stretch updates for 52.6.0 anyway this weekend.
It would be good if one of the reporter could test your changes if
needed. I guess we are save OTOH as the AA profile is now disabled as
default.

Regards
Carsten

Bug#888485: fixed in gjs 1.50.3-2

[Raphael Hertzog]

Hi,

On Fri, 26 Jan 2018 17:37:32 + Simon McVittie  wrote:
>  gjs (1.50.3-2) unstable; urgency=medium
>  .
>* Team upload
>* Add patch from upstream merge request 38 to prevent crashes in
>  certain error situations (possibly resolves #888052, #888199)
>* Add patches to improve uncatchable exception reporting
>* Revert some of the upstream changes from 1.50.3, which appear to
>  cause crashes (Closes: #888485; possibly also #888052, #888199)

With this version, I no longer have the crash and I see errors logged:

Jan 26 21:28:01 kali-rolling kernel: sd 2:0:0:0: [sda] Attached SCSI disk
Jan 26 21:28:01 kali-rolling dbus-daemon[370]: [system] Activating via systemd: 
service name='org.freedesktop.hostname1' 
unit='dbus-org.freedesktop.hostname1.service' requested by ':1.65' (uid=0 
pid=885 comm="/usr/bin/gnome-shell ")
Jan 26 21:28:01 kali-rolling systemd[1]: Starting Hostname Service...
Jan 26 21:28:01 kali-rolling dbus-daemon[370]: [system] Successfully activated 
service 'org.freedesktop.hostname1'
Jan 26 21:28:01 kali-rolling systemd[1]: Started Hostname Service.
Jan 26 21:28:01 kali-rolling gnome-shell[885]: Object Gio.DBusProxy 
(0x562950b78ea0), has been already deallocated - impossible to access to it. 
This might be caused by the fact that the object has been destroyed from C code 
using something such as destroy(), dispose(), or remove() vfuncs
Jan 26 21:28:01 kali-rolling org.gnome.Shell.desktop[885]: == Stack trace for 
context 0x56294f839170 ==
Jan 26 21:28:01 kali-rolling org.gnome.Shell.desktop[885]: #0 0x56294fcf2b00 i  
 resource:///org/gnome/gjs/modules/overrides/Gio.js:197 (0x7f0c5c803d58 @ 26)
Jan 26 21:28:01 kali-rolling gnome-shell[885]: Object Gio.DBusProxy 
(0x562950b78ea0), has been already deallocated - impossible to connect to 
signal. This might be caused by the fact that the object has been destroyed 
from C code using something such as destroy(), dispose(), or remove() vfuncs
Jan 26 21:28:01 kali-rolling org.gnome.Shell.desktop[885]: == Stack trace for 
context 0x56294f839170 ==
Jan 26 21:28:01 kali-rolling org.gnome.Shell.desktop[885]: #0 0x56294fcf2b98 i  
 
/usr/share/gnome-shell/extensions/places-m...@gnome-shell-extensions.gcampax.github.com/placeDisplay.js:146
 (0x7f0c31806d58 @ 67)
Jan 26 21:28:01 kali-rolling org.gnome.Shell.desktop[885]: #1 0x7ffcf0b27000 b  
 self-hosted:917 (0x7f0c5c9ee5e8 @ 394)
Jan 26 21:28:01 kali-rolling org.gnome.Shell.desktop[885]: #2 0x56294fcf2b00 i  
 resource:///org/gnome/gjs/modules/overrides/Gio.js:203 (0x7f0c5c803d58 @ 89)
Jan 26 21:28:01 kali-rolling gnome-shell[885]: Object Gio.DBusProxy 
(0x562950b78ea0), has been already finalized. Impossible to get any property 
from it.
Jan 26 21:28:01 kali-rolling org.gnome.Shell.desktop[885]: == Stack trace for 
context 0x56294f839170 ==
Jan 26 21:28:01 kali-rolling org.gnome.Shell.desktop[885]: #0 0x56294fcf2c40 i  
 
/usr/share/gnome-shell/extensions/places-m...@gnome-shell-extensions.gcampax.github.com/placeDisplay.js:159
 (0x7f0c31806e68 @ 9)
Jan 26 21:28:01 kali-rolling org.gnome.Shell.desktop[885]: #1 0x7ffcf0b26300 I  
 resource:///org/gnome/gjs/modules/_legacy.js:82 (0x7f0c5c9c2bc0 @ 71)
Jan 26 21:28:01 kali-rolling org.gnome.Shell.desktop[885]: #2 0x56294fcf2b98 i  
 
/usr/share/gnome-shell/extensions/places-m...@gnome-shell-extensions.gcampax.github.com/placeDisplay.js:148
 (0x7f0c31806d58 @ 85)
Jan 26 21:28:01 kali-rolling org.gnome.Shell.desktop[885]: #3 0x7ffcf0b27000 b  
 self-hosted:917 (0x7f0c5c9ee5e8 @ 394)
Jan 26 21:28:01 kali-rolling org.gnome.Shell.desktop[885]: #4 0x56294fcf2b00 i  
 resource:///org/gnome/gjs/modules/overrides/Gio.js:203 (0x7f0c5c803d58 @ 89)
Jan 26 21:28:01 kali-rolling systemd[1]: Created slice 
system-clean\x2dmount\x2dpoint.slice.
Jan 26 21:28:01 kali-rolling systemd[1]: Started Clean the /media/root/Debian 
Inst mount point.
Jan 26 21:28:01 kali-rolling udisksd[954]: Mounted /dev/sda at 
/media/root/Debian Inst on behalf of uid 0
Jan 26 21:28:01 kali-rolling dbus-daemon[797]: [session uid=0 pid=797] 
Activating service name='org.gnome.Shell.HotplugSniffer' requested by ':1.13' 
(uid=0 pid=885 comm="/usr/bin/gnome-shell ")
Jan 26 21:28:01 kali-rolling dbus-daemon[797]: [session uid=0 pid=797] 
Successfully activated service 'org.gnome.Shell.HotplugSniffer'
Jan 26 21:28:01 kali-rolling gnome-shell[885]: Object Gio.DBusProxy 
(0x5629568191a0), has been already deallocated - impossible to access to it. 
This might be caused by the fact that the object has been destroyed from C code 
using something such as destroy(), dispose(), or remove() vfuncs
Jan 26 21:28:01 kali-rolling org.gnome.Shell.desktop[885]: == Stack trace for 
context 0x56294f839170 ==
Jan 26 21:28:01 kali-rolling org.gnome.Shell.desktop[885]: #0 0x56294fcf2b00 i  
 resource:///org/gnome/gjs/modules/overrides/Gio.js:197 (0x7f0c5c803d58 @ 26)
Jan 26 21:28:01 kali-rolling gnome-shell[885]: Object Gio.DBusProxy 
(0x5629568191a0), has been already deallocated - impossible

Bug#888537: linux-image-4.14.0-3-arm64: BUG: Bad page state in process cc1 pfn:75cbd

[Heinrich Schuchardt]

Package: src:linux
Version: 4.14.13-1
Severity: normal

Dear Maintainer,

I am running an Odroid C2 on iSCSI.

Under heavy load I see bad page errors like the ones below. This is not gcc
specific. Same happens when git is handling large repositories.

The reserved memory matches my firmware.

reserved-memory/secmon@1000/reg
00 00 00 00  10 00 00 00  00 00 00 00  00 20 00 00

reserved-memory/hwrom@0/reg
00 00 00 00  00 00 00 00  00 00 00 00  01 00 00 00

Please, give advice for further analysis.

Best regards

Heinrich Schuchardt

-- Package-specific info:
** Version:
Linux version 4.14.0-3-arm64 (debian-ker...@lists.debian.org) (gcc version 
7.2.0 (Debian 7.2.0-19)) #1 SMP Debian 4.14.13-1 (2018-01-14)

** Command line:
BOOT_IMAGE=/vmlinuz-4.14.0-3-arm64 
root=UUID=afa724eb-deb7-4779-ba7d-b6553f4e34d3 ro quiet

** Tainted: B (32)
 * System has hit bad_page.

** Kernel log:
[   11.936949] systemd[1]: File /lib/systemd/system/systemd-journald.service:35 
configures an IP firewall (IPAddressDeny=any), but the local system does not 
support BPF/cgroup based firewalling.
[   11.936958] systemd[1]: Proceeding WITHOUT firewalling in effect! (This 
warning is only shown for the first loaded unit using IP firewalling.)
[   12.105689] systemd[1]: 
dev-disk-by\x2duuid-84185ebb\x2d74ba\x2d4879\x2d93ba\x2d56adcdfbe8c7.device: 
Dependency Before=network-online.target ignored (.device units cannot be 
delayed)
[   12.105705] systemd[1]: 
dev-disk-by\x2duuid-84185ebb\x2d74ba\x2d4879\x2d93ba\x2d56adcdfbe8c7.device: 
Dependency Before=network.target ignored (.device units cannot be delayed)
[   12.109332] systemd[1]: dev-disk-by\x2duuid-1F97\x2dB63B.device: Dependency 
Before=network-online.target ignored (.device units cannot be delayed)
[   12.109347] systemd[1]: dev-disk-by\x2duuid-1F97\x2dB63B.device: Dependency 
Before=network.target ignored (.device units cannot be delayed)
[   12.115281] systemd[1]: Created slice System Slice.
[   12.270402] EXT4-fs (sda3): re-mounted. Opts: errors=remount-ro
[   12.326234] systemd-journald[225]: Received request to flush runtime journal 
from PID 1
[   12.365796] iscsi: registered transport (iser)
[   12.609622] EFI Variables Facility v0.08 2004-May-17
[   12.609640] efivars: get_next_variable: status=8007
[   12.611877] pstore: using zlib compression
[   12.611894] pstore: Registered efi as persistent store backend
[   12.719455] scsi 0:0:0:0: Attached scsi generic sg0 type 12
[   12.719557] sd 0:0:0:1: Attached scsi generic sg1 type 0
[   13.215460] audit: type=1400 audit(1513289398.720:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=332 
comm="apparmor_parser"
[   13.215471] audit: type=1400 audit(1513289398.720:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man//filter" 
pid=332 comm="apparmor_parser"
[   13.215477] audit: type=1400 audit(1513289398.720:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man//groff" 
pid=332 comm="apparmor_parser"
[   13.252407] audit: type=1400 audit(1513289398.756:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/ntpd" pid=333 
comm="apparmor_parser"
[   13.971676] random: crng init done
[   16.601127] audit: type=1400 audit(1513289402.104:6): apparmor="DENIED" 
operation="open" profile="/usr/sbin/ntpd" name="/usr/local/sbin/" pid=382 
comm="ntpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[   16.601139] audit: type=1400 audit(1513289402.104:7): apparmor="DENIED" 
operation="open" profile="/usr/sbin/ntpd" name="/usr/local/bin/" pid=382 
comm="ntpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[   16.803865] EXT4-fs (sda2): mounting ext2 file system using the ext4 
subsystem
[   16.811713] EXT4-fs (sda2): mounted filesystem without journal. Opts: (null)
[   16.920231] FAT-fs (sda1): Volume was not properly unmounted. Some data may 
be corrupt. Please run fsck.
[ 1609.725807] BUG: Bad page state in process cc1  pfn:75cbd
[ 1609.725859] page:7e0001d72f40 count:0 mapcount:0 mapping:  
(null) index:0x4
[ 1609.733512] flags: 
0x0460320(lru|slab|owner_priv_1|reclaim|swapbacked)
[ 1609.740671] raw: 00460320  0004 

[ 1609.748345] raw: dead0100 dead0200  

[ 1609.756018] page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set
[ 1609.762137] bad because of flags: 
0x60320(lru|slab|owner_priv_1|reclaim|swapbacked)
[ 1609.769727] Modules linked in: nls_ascii nls_cp437 vfat fat meson_drm 
meson_saradc drm_kms_helper industrialio meson_rng rng_core sg meson_gxbb_wdt 
drm leds_gpio efi_pstore efivars ib_iser rdma_cm iw_cm ib_cm ib_core configfs 
efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 fscrypto ecb 
aes_arm64 sd_mod crc32c_generic iscsi_tcp libiscsi_tcp libiscsi 
scsi_transport_iscsi scsi_mod dwmac_generic realtek dwc2 meson_gx_mmc udc_core 
dwmac_m

Bug#888536: binutils: TLS breakage in PIC/PIE mode on SPARC (PR ld/22727)

[John Paul Adrian Glaubitz]

Source: binutils
Version: 2.29.90.20180122-1
Severity: important
Tags: upstream
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hi!

binutils on sparc64 is currently pretty much broken. Lots of stuff
compiled with it just segfaults:

root@stadler:~# update-menus 
Segmentation fault
root@stadler:~# dpkg -i gcc-7-base_7.1.0-9_sparc64.deb 
libstdc++6_7.1.0-9_sparc64.deb 
dpkg: warning: downgrading gcc-7-base:sparc64 from 7.3.0-1 to 7.1.0-9
(Reading database ... 193251 files and directories currently installed.)
Preparing to unpack gcc-7-base_7.1.0-9_sparc64.deb ...
Unpacking gcc-7-base:sparc64 (7.1.0-9) over (7.3.0-1) ...
dpkg: warning: downgrading libstdc++6:sparc64 from 7.3.0-1 to 7.1.0-9
Preparing to unpack libstdc++6_7.1.0-9_sparc64.deb ...
Unpacking libstdc++6:sparc64 (7.1.0-9) over (7.3.0-1) ...
Setting up gcc-7-base:sparc64 (7.1.0-9) ...
Setting up libstdc++6:sparc64 (7.1.0-9) ...
Processing triggers for libc-bin (2.26-4) ...
root@stadler:~# update-menus 
root@stadler:~#

This is most likely a result of PR ld/22727 [1] which was fixed in [2].

Thanks,
Adrian

> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=22727
> [2] 
> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=bb363086e7743506d78bc6b1e56face0fb1fc93f

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#888535: Global configuration location stated incorrectly in man page

[Daniel Mulholland]

Package: snapper
Version: 0.4.1-3


In the man page for snapper it refers to the default global configuration
file as   /etc/sysconfig/snapper. I believe this should be
/etc/default/snapper instead.

FILES
>/etc/sysconfig/snapper
>Global configuration file.
>


# cat /etc/sysconfig/snapper
cat: /etc/sysconfig/snapper: No such file or directory
# cat /etc/default/snapper
## Path: System/Snapper

## Type:string
## Default: ""
# List of snapper configurations.
SNAPPER_CONFIGS=""

Bug#888534: pychess: Pychess cannot open PGN files

[Leo]

Package: pychess
Version: 0.12.2-1
Severity: normal

Dear Maintainer,

* What led up to the situation?
1. Open Pychess
2. From "Game" choose "Load Game", or drag and drop a PGN file to Pychess

* What exactly did you do (or not do) that was effective (or
  ineffective)?
I tried to run Pychess from Terminal, it gave error:
```
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/pychess/Main.py", line 448, in 
recent_item_activated
newGameDialog.LoadFileExtension.run(self.get_current_uri())
  File "/usr/lib/python2.7/dist-packages/pychess/widgets/newGameDialog.py", 
line 476, in run
cls.loadSidePanel.set_filename(uri)
AttributeError: BoardPreview instance has no attribute 'set_filename'
```

* What was the outcome of this action?
PGN files not opened.

* What outcome did you expect instead?
PGN files are loaded.


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

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

Versions of packages pychess depends on:
ii  gaviotatb0.4-2
ii  gir1.2-gdkpixbuf-2.0 2.36.5-2+deb9u2
ii  gir1.2-glib-2.0  1.50.0-1+b1
ii  gir1.2-gst-plugins-base-1.0  1.10.4-1
ii  gir1.2-gstreamer-1.0 1.10.4-1
ii  gir1.2-gtk-3.0   3.22.11-1
ii  gir1.2-gtksource-3.0 3.22.2-1
ii  gir1.2-pango-1.0 1.40.5-1
ii  gir1.2-rsvg-2.0  2.40.16-1+b1
ii  gnome-icon-theme 3.12.0-2
ii  gobject-introspection1.50.0-1+b1
ii  libgaviotatb10.4-2
ii  python   2.7.13-2
ii  python-cairo 1.8.8-2.2
ii  python-gi3.22.0-2
ii  python-gi-cairo  3.22.0-2

pychess recommends no packages.

pychess suggests no packages.

-- no debconf information

Bug#804272: fails to synchronize caldav to OpenXChange without notice

[Martin Steigerwald]

Control: tags -1 upstream
Control: severity -1 important
kthxbye

Hello Thomas, hello Enrico, hello Petter.

I am sorry that you received no response to this bug report earlier.

I am downgrading the bug to important as its not a policy violation and also 
the package is not unsuitable for everyone.

Of course some time has passed and current Debian Stable aka Stretch has the 
updated Akonadi version 16.04.3. Could you reproduce this issue with this 
version or a newer one?

If so, I kindly ask you to report the bug upstream if not already done. We 
greatly appreciate your help.

Please report it via Help -> Report bug... menu item of the respective 
application or by visiting https://bugs.kde.org/ and following instructions
to report a new bug.

Debian Qt/KDE maintainers do not have resources to deal with
non Debian-specific bugs and therefore it is unlikely that
your bug will be solved if you do not report it to KDE developers
directly (unless it is/has been reported by somebody else).

Whenever you open a bug report or find an existing one on the KDE
bug tracking system, you can couple both this Debian bug and the
KDE bug together by sending a mail with the text below to
cont...@bugs.debian.org (replace KDE-BUG-URL with the address of
the bug report on https://bugs.kde.org/)

[ copy this ]
forwarded {debbug} KDE-BUG-URL
thanks
[ copy this ]

Thanks,
-- 
Martin

Bug#888533: openjpeg2: CVE-2018-5785: integer overflow in opj_j2k_setup_encoder function in openjp2/j2k.c

[Salvatore Bonaccorso]

Source: openjpeg2
Version: 2.3.0-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/uclouvain/openjpeg/issues/1057

Hi,

the following vulnerability was published for openjpeg2.

CVE-2018-5785[0]:
| In OpenJPEG 2.3.0, there is an integer overflow caused by an
| out-of-bounds left shift in the opj_j2k_setup_encoder function
| (openjp2/j2k.c). Remote attackers could leverage this vulnerability to
| cause a denial of service via a crafted bmp file.

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-2018-5785
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5785
[1] https://github.com/uclouvain/openjpeg/issues/1057
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1537758#c2

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#888532: openjpeg2: CVE-2018-5727: nteger overflow in opj_t1_encode_cblks in src/lib/openjp2/t1.c

[Salvatore Bonaccorso]

Source: openjpeg2
Version: 2.3.0-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/uclouvain/openjpeg/issues/1053

Hi,

the following vulnerability was published for openjpeg2.

CVE-2018-5727[0]:
| In OpenJPEG 2.3.0, there is an integer overflow vulnerability in the
| opj_t1_encode_cblks function (openjp2/t1.c). Remote attackers could
| leverage this vulnerability to cause a denial of service via a crafted
| bmp file.

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-2018-5727
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5727
[1] https://github.com/uclouvain/openjpeg/issues/1053
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1536552#c2

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#888531: transition: ruby2.5

[Antonio Terceiro]

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

Hi,

I would like to start the transition to ruby2.5 in unstable. General
information about Ruby transitions can be found in:
https://wiki.debian.org/Teams/Ruby/InterpreterTransitions

ruby2.5 has been in testing for a while.

Building against ruby2.5 has been enabled in experimental, and we
already did a test rebuild against it, with pretty good results:
https://hackmd.io/EYBghgHA7AjFDMBaCZgE5EBYYCYAmiaEAxhjgKzFQCmAZtGHtTkA

So I would like to enable building against ruby2.5 in unstable, and to
effectively start the transition. Soon after we have a transition page,
I will have a first round of binNMUs to request.

Ben file:

title = "ruby2.5";
is_affected: .depends ~ /ruby2.3 | .depends ~ /ruby2.5/
is_good: .depends ~ /ruby2.5/
is_bad: .depends ~ /ruby2.3/ & !.depends ~ /ruby2.5/

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

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


signature.asc
Description: PGP signature

Bug#888461: nvidia-persistenced: Daemon will not start

[Andreas Beckmann]

Control: reassign -1 glx-alternative-nvidia 0.7.4

On 2018-01-26 02:33, Marc Bonnor wrote:
> I would like to use the graphics card on my laptop when I need it.
> 
> ii  bumblebee-nvidia  3.2.1-
> 17amd64NVIDIA Optimus support using

So your usecase is nvidia-persistenced with bumblebee-nvidia.
I see why the library alternative is missing. Fix is coming.


Andreas

Bug#885891: mitigation via systemd atd.service

[H.-Dirk Schmitt]

A simple mitigation is to add the following statement to the atd.service 
definition:

  [Service]
  ExecStartPre=-find /var/spool/cron/atjobs/ -type f -name "=*" -not -newercc 
/run/systemd -delete

Justification:
--
The job command specification are files below  /var/spool/cron/atjobs/.
The naming convention is: 

On the start of a batch job the job file is renamed to 
=.
This change the inode and „ctime“ of the file.

Assuming that '/run/systemd' :
1. is created on startup of the machine
2.  before atd is started

So we have a barrier that allows the distinction stale job files.

Bug#888513: huge graphical bug

[melissa M.]

thank you for help

unfortunately no parameter fixes the bug...

vga=normal fb=false
has no effect also

My case is desperate, I think..

sorry for the version and severity..
I didn't know the exact version.
sorry :/

Bug#888073: glibc: Support amd64 systems without /lib64

[Samuel Thibault]

Javier Serrano Polo, on ven. 26 janv. 2018 20:38:07 +0100, wrote:
> > But what about the converse? Can you run the attached program?
> 
> Not yet:
> 
> ./true: /lib/libc.so.6: version `GLIBC_2.14' not found (required by ./true)

How did it find an interpreter?

If I drop /lib64 on my system, I can't execute it.

samuel

Bug#888530: openjfx: CVE-2018-2581

[Salvatore Bonaccorso]

Source: openjfx
Version: 8u151-b12-1
Severity: important
Tags: security upstream

Hi,

the following vulnerability was published for openjfx, apart the CVE
description not much is available:

CVE-2018-2581[0]:
| Vulnerability in the Java SE component of Oracle Java SE
| (subcomponent: JavaFX). Supported versions that are affected are Java
| SE: 7u161, 8u152 and 9.0.1. Easily exploitable vulnerability allows
| unauthenticated attacker with network access via multiple protocols to
| compromise Java SE. Successful attacks require human interaction from
| a person other than the attacker and while the vulnerability is in
| Java SE, attacks may significantly impact additional products.
| Successful attacks of this vulnerability can result in unauthorized
| read access to a subset of Java SE accessible data. Note: This
| vulnerability applies to Java deployments, typically in clients
| running sandboxed Java Web Start applications or sandboxed Java
| applets, that load and run untrusted code (e.g., code that comes from
| the internet) and rely on the Java sandbox for security. This
| vulnerability does not apply to Java deployments, typically in
| servers, that load and run only trusted code (e.g., code installed by
| an administrator). CVSS 3.0 Base Score 4.7 (Confidentiality impacts).
| CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N).

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-2018-2581
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2581

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#888073: glibc: Support amd64 systems without /lib64

[Javier Serrano Polo]

X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net, m...@suse.de, j...@suse.cz, 
a...@suse.de

El dv 26 de 01 de 2018 a les 19:18 +0100, Samuel Thibault va escriure:
> Count a sixth person :)

You are welcome.

> But what about the converse? Can you run the attached program?

Not yet:

./true: /lib/libc.so.6: version `GLIBC_2.14' not found (required by ./true)

But this has nothing to do with the interpreter. Of course, I could run
a sid chroot, but this is not the point. When I finish my upgrade
process (which may take months), I will try again your test.


smime.p7s
Description: S/MIME cryptographic signature

Bug#888515: debian-installer: UEFI boot menu (grub) misses the help screen

[Lennart Sorensen]

On Fri, Jan 26, 2018 at 05:16:38PM +0100, Samuel Thibault wrote:
> Hello Grub maintainers, any idea about this?

Is this too much of a hack:



menuentry ' ' {true}
menuentry 'Help:' {true}
submenu '  Prerequesites for installing Debian.' {
menuentry 'PREREQUISITES FOR INSTALLING DEBIAN' {true}
menuentry ' ' {true}
menuentry 'You must have at least 105 megabytes of RAM to use this 
Debian' {true}
menuentry 'installer.' {true}
menuentry ' ' {true}
menuentry 'You should have space on your hard disk to create a new disk 
partition' {true}
menuentry "of at least 680 megabytes to install the base system.  
You'll need more" {true}
menuentry 'disk space to install additional packages, depending on what 
you wish' {true}
menuentry 'to do with your new Debian system.' {true}
menuentry ' ' {true}
menuentry 'See the Installation Guide or the FAQ for more information; 
both' {true}
menuentry 'documents are available at the Debian web site, 
http://www.debian.org/' {true}
menuentry ' ' {true}
menuentry 'Thank you for choosing Debian!' {true}
}
submenu '  Boot methods for special ways of using this CD-ROM' {
menuentry 'BOOT METHODS' {true}
menuentry ' ' {true}
menuentry 'Available boot methods:' {true}
menuentry ' ' {true}
menuentry 'installgui' {true}
menuentry '  Start the installation using the graphical installer -- 
this is the' {true}
menuentry 'install' {true}
menuentry '  Start the installation using the text mode installer' 
{true}
menuentry 'expertgui' {true}
menuentry '  Start the installation in expert mode, for maximum 
control, using' {true}
menuentry '  the graphical installer' {true}
menuentry 'expert' {true}
menuentry '  Start the installation in expert mode using the text mode 
installer' {true}
}

Obviously the text has to be corrected I just copied from isolinux pages
as an example.

-- 
Len Sorensen

Bug#888073: glibc: Support amd64 systems without /lib64

[Aurelien Jarno]

On 2018-01-26 19:54, Aurelien Jarno wrote:
> On 2018-01-26 19:05, Javier Serrano Polo wrote:
> > My systems obviously exist. To the claim that I cannot run a /lib64
> > program without rebuilding, the answer is easy to say: try my system.
> > To the claim that applications from my system will not run anywhere
> > else, I can provide a counterexample: you can install the attached
> > package.
> 
> Your package provides a /lib64 library, which is exactly what you want
> to avoid. The binary alone doesn't work, which is exactly my point.

It's probably not clear, let me try again. Your package provides a
/lib/ld-linux-x86-64.so.2 -> /lib64/ld-linux-x86-64.so.2 symlink. As 2
packages or more can't provide the same file, I conclude that to be able
to install your package your program interpreter should be installed in
/lib64 (and not in /lib), which is exactly what you want to avoid.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#888529: memcached: Systemd private tmp breaks unix socket access to memcached

[Dennis Boone]

Package: memcached
Version: 1.5.4-1
Severity: important

After applying this version the other night, our application was no
longer able to connect to memcached via its unix socket.  (Since the
systemd private tmp functionality is a damned rootkit, it too a while to
diagnose this problem.)  The distributed configuration file appears to
place the unix socket in /tmp.

If systemd private tmp is to be enabled for memcached, the distributed
configuration should place the unix socket elsewhere.  Alternately,
private tmp could be disabled for memached.


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

Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to es_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to es_US.UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages memcached depends on:
ii  adduser 3.116
ii  libc6   2.26-5
ii  libevent-2.1-6  2.1.8-stable-4
ii  libsasl2-2  2.1.27~101-g0780600+dfsg-3
ii  lsb-base9.20170808
ii  perl5.26.1-4

memcached recommends no packages.

Versions of packages memcached suggests:
pn  libanyevent-perl 
pn  libcache-memcached-perl  
pn  libmemcached 
ii  libterm-readkey-perl 2.37-1+b2
pn  libyaml-perl 

-- no debconf information

Bug#888073: glibc: Support amd64 systems without /lib64

[Aurelien Jarno]

On 2018-01-26 19:05, Javier Serrano Polo wrote:
> X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net, m...@suse.de, j...@suse.cz, 
> a...@suse.de
> 
> El dv 26 de 01 de 2018 a les 08:39 +0100, Andreas Jaeger va escriure:
> > No, this is not possible - it would break binary compatibility. The path
> > is hardcoded into each binary and if you change it, your application
> > will not run anywhere else,
> 
> It would be nice if you answered the question about appendix A.1.
> 
> So, we have five people who state or imply that either my amd64 systems
> do not exist or they are unavoidably incompatible with systems depending
> on a /lib64 directory.

We never said that your system doesn't exist. We said you have to
rebuild all binaries to get of /lib64. It's what your package shows:

$ readelf -e hello-nolib64 | grep interpret
  [Requesting program interpreter: /lib/ld-linux-x86-64.so.2]

> My systems obviously exist. To the claim that I cannot run a /lib64
> program without rebuilding, the answer is easy to say: try my system.
> To the claim that applications from my system will not run anywhere
> else, I can provide a counterexample: you can install the attached
> package.

Your package provides a /lib64 library, which is exactly what you want
to avoid. The binary alone doesn't work, which is exactly my point.

> Would you accept the evidence? Is /lib64 still a mistake or rather a
> maintainer's choice?

/lib64 is being compatible with everybody in both directions, you like
it or not. Your system is not compatible with others. We do not want
that.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#888528: libnot-yet-commons-ssl-java - missing on buster

[Yadickson Soto]

Package: libnot-yet-commons-ssl-java
Version: 0.3.17
Branch: buster (testing)

Hi,

On debian buster is missing the libnot-yet-commons-ssl-java library.
Please, is posible add the libnot-yet-commons-ssl-java to repository.

The original url is dead

http://juliusdavies.ca/commons-ssl/

The last release version of libnot-yet-commons-ssl-java is 0.3.17 from

https://github.com/nivertius/not-yet-commons-ssl/tree/0.3.17


Maybe, is possible update the libnot-yet-commons-ssl-java library?

Thanks a lot
Best regards

Ing. Yadickson Soto
+56 9 9668 8798
Usuario Linux #497718

Bug#888513: huge graphical bug

[Cyril Brulebois]

Control: found -1 20170615+deb9u2
Control: severity -1 important

Hi melissa,

and thanks for your report.

melissa M.  (2018-01-26):
> Package: debian-installer
> Version: stable
> Severity: grave

I'm adjusting version and severity with the commands above. While this
is a grave issue for you, that only affects one particular equipment and
doesn't make d-i unusable for everyone else.


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


signature.asc
Description: PGP signature

Bug#884217: thunderbird: Latest VCS-Git AppArmor profile (will) break aa-enfroce usage on Jessie

[Vincas Dargis]

May I provide `patches/fixes/fix-jessie-apparmor-parser-error.patch` for a 
`jessie` branch, or something like that?

Bug#888513: huge graphical bug

[Samuel Thibault]

melissa M., on ven. 26 janv. 2018 19:12:32 +0100, wrote:
> despite the different options, there is no change, the bug persists...

If there is no change, there must be an error in passing the kernel arg,
how do you pass them?

vga=normal fb=false 

should get you to a pure textmode, there's no way you can get the split
image you sent to the bug, or your graphic card is *seriously* broken if
it can't even properly display pure text.

Samuel

Bug#888073: glibc: Support amd64 systems without /lib64

[Samuel Thibault]

Javier Serrano Polo, on ven. 26 janv. 2018 19:05:38 +0100, wrote:
> X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net, m...@suse.de, j...@suse.cz, 
> a...@suse.de
> 
> El dv 26 de 01 de 2018 a les 08:39 +0100, Andreas Jaeger va escriure:
> > No, this is not possible - it would break binary compatibility. The path
> > is hardcoded into each binary and if you change it, your application
> > will not run anywhere else,
> 
> It would be nice if you answered the question about appendix A.1.
> 
> So, we have five people who state or imply that either my amd64 systems
> do not exist or they are unavoidably incompatible with systems depending
> on a /lib64 directory.

Count a sixth person :)

> My systems obviously exist. To the claim that I cannot run a /lib64
> program without rebuilding, the answer is easy to say: try my system.
> To the claim that applications from my system will not run anywhere
> else, I can provide a counterexample: you can install the attached
> package.

Yes. But what about the converse? Can you run the attached program?

Samuel


true
Description: Binary data

Bug#888527: RFS: hollywood/1.12-1 [ITP]

[Yangfl]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: hollywood
   Version : 1.12-1
   Upstream Author : Dustin Kirkland
 * URL : http://launchpad.net/hollywood
 * License : Apache-2
   Section : games

It builds those binary packages:

  hollywood  - fill your console with Hollywood melodrama technobabble
 wallstreet - fill your console with Wall Street-like news and stats

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

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


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

  dget -x https://mentors.debian.net/debian/pool/main/h/hollywood/
hollywood_1.12-1.dsc

More information about hello can be obtained from https://www.example.com.

Changes since the last upload:

[your most recent changelog entry]


Regards,
 Yangfl

Bug#888525: monodevelop - missing on buster

[Yadickson Soto]

Package: monodevelop
Version: 5.10.0.871-2
Branch: buster (testing)

Hi,

On debian buster is missing the monodevelop application.
Please, is posible add the monodevelop to repository.

The last release version of monodevelop is 7.3.2.12 from

https://github.com/mono/monodevelop/tree/monodevelop-7.3.2.12

Maybe, is possible update the monodevelop application?

Thanks a lot
Best regards

Ing. Yadickson Soto
+56 9 9668 8798
Usuario Linux #497718

Bug#888512: clamav-daemon: Clamd suddenly eat up all file descriptors, 'Too many open files' error

[Bernhard Schmidt]

Am 26.01.2018 um 17:26 schrieb Marco Gaiarin:

Hi Marco,
> 
>> This is an issue in daily.cld 24256+ (released around this morning).
> 
> I've searched extensively with google, but found nothing apart some old
> similar trouble dated 2015 or later... sorry...

It took me a lot of time to find reliable information about this as
well. The ClamAV bugtracker is an absolute mess and totally useless, and
most of the times when you see issues there is nothing on the ML either.

That said, since about half an hour they are shipping daily.cvd 24258
from the mirrors which is supposed to fix this. So a remedy should be
just one freshclam run away.

Bernhard

Bug#888526: RFS: dxf2gcode/20170925-5 [ITP] -- converts 2D drawings to G-code for CNC machines

[Sebastian Kuzminsky]

Package: sponsorship-requests
Severity: wishlist

Dear Mentors/Sponsors,

I am looking for a Sponsor for my package "dxf2gcode":

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

It builds a single binary-all package also named dxf2gcode.

More info is available at upstream's wiki here: 

https://sourceforge.net/p/dxf2gcode/wiki/Home/

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

Kernel: Linux 4.9.0-5-rt-amd64 (SMP w/8 CPU cores; PREEMPT)
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)

Bug#888524: jmeter - missing on buster

[Yadickson Soto]

Package: jmeter
Version: 2.13
Branch: buster (testing)

Hi,

On debian buster is missing the jmeter application.
Please, is posible add the jmeter to repository.

The last version of jmeter is 3.3 from

http://jmeter.apache.org/download_jmeter.cgi

Maybe, is possible update the jmeter application?

Thanks a lot
Best regards

Ing. Yadickson Soto
+56 9 9668 8798
Usuario Linux #497718