Bug#943855: RM: rust-crossbeam-utils-0.5/0.5.2-2

[Juhani Numminen]

Juhani Numminen kirjoitti 19.1.2020 klo 22.24:
> On Wed, 30 Oct 2019 21:16:10 +0100 Wolfgang Silbermayr 
>  wrote:
>> The rust-crossbeam-utils-0.5 package is no longer in use. All reverse
>> dependencies either migrated to a non-semver-suffixed version of rust-
>> crossbeam-utils or don't depend on it anymore at all.
>> The only remaining dependency as of now is rust-crossbeam-epoch-0.5 for 
>> which I
>> asked the maintainer to file a RM request as well.
> 

> Apparently rust-crossbeam-epoch-0.5 is still in unstable, though it was
> removed from testing (#948606). Perhaps you should ask the maintainer again?

The RM for the remaining reverse depend was filed:
#949548 "RM: rust-crossbeam-epoch-0.5 -- ROM; no longer in use"

Bug#949274: pyresample autopkg tests regressed in unstable

[Bas Couwenberg]

On 2020-01-22 08:12, Antonio Valentino wrote:
On Sun, 19 Jan 2020 08:44:48 +0100 Matthias Klose  
wrote:

- WGS_1984_Web_Mercator_Auxiliary_Sphere
+ WGS 84 / Pseudo-Mercator


I gave a very quick look to the issue and it seems that the problem has
be triggered bu the update to gdal 3.0.3.

-gdal-data 3.0.2+dfsg-1
+gdal-data 3.0.3+dfsg-1
-libgdal26 3.0.2+dfsg-1
+libgdal26 3.0.3+dfsg-1

rasterio could be also involved since the specific test uses rasterio 
to

retrieve the information about the geographic projection

I don't see any change in gdal data at a first look so probably the
problem is related behavior change in gdal that is not correctly 
handled

by pyresample or rasterio.

I need to make some additional investigation.


GDAL 3 is the first to fully support PROJ 6, it now relies on PROJ and 
its database for CRS data instead the data files included in gdal-data.


The test should either expect the new name or expect both.

Kind Regards,

Bas

Bug#949468: satpy: autopkgtest regression due to new pygac

[Antonio Valentino]

Dear Gianfranco,

On Tue, 21 Jan 2020 18:03:01 +0100 Gianfranco Costamagna
 wrote:
> control: severity -1 important
> 
> On Tue, 21 Jan 2020 09:28:40 +0100 Gianfranco Costamagna 
>  wrote:
> > Source: satpy
> > Version: 0.19.1-1
> > Severity: serious
> > 
> > Hello, looks like pygac update regressed the testsuite.
> > I requested a new run in Debian, but in the meanwhile you can see a run 
> > here:
> > https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/s/satpy/20200120_195040_eac9b@/log.gz
> > 
> > or here:
> > http://debomatic-amd64.debian.net/distribution#unstable/satpy/0.19.1-1/autopkgtest
> > 
> > (and even inside the build process itself the error is thrown out, but for 
> > some reasons the testsuite errors are somewhat ignored at least in that 
> > part)
> > 
> 
> looks like the debian autopkgtest is green, and the "killed" is an 
> ubuntu-only thing.
> 
> However, my patch has been merged upstream, so the gac issue is fixed.
> 
> G.


Sorry Gianfranco but the problem is not clear to me.

Apart for the killed test run, satpy is failing in testing due to a
missing dependency (behave) which has been removed form testing.

I don't see any issue related to pygac, am I missing something?

Also can you please give me a pointer to the patch that has been merged
upstream?


kind regards

-- 
Antonio Valentino

Bug#949274: pyresample autopkg tests regressed in unstable

[Antonio Valentino]

Dear Matthias,
thank you for reporting.

On Sun, 19 Jan 2020 08:44:48 +0100 Matthias Klose  wrote:
> Package: src:pyresample
> Version: 1.14.0-2
> Severity: serious
> Tags: sid bullseye
> 
> https://ci.debian.net/data/autopkgtest/unstable/amd64/p/pyresample/4019144/log.gz
> 
> [...]
> ==
> FAIL: test_get_area_def_from_raster_extracts_proj_id
> (pyresample.test.test_utils.TestMisc)
> --
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/pyresample/test/test_utils.py", line 
> 477,
> in test_get_area_def_from_raster_extracts_proj_id
> self.assertEqual(area_def.proj_id, 'WGS 84 / Pseudo-Mercator')
> AssertionError: 'WGS_1984_Web_Mercator_Auxiliary_Sphere' != 'WGS 84 /
> Pseudo-Mercator'
> - WGS_1984_Web_Mercator_Auxiliary_Sphere
> + WGS 84 / Pseudo-Mercator
> 
> 
> --
> Ran 271 tests in 193.325s
> 
> FAILED (failures=1, skipped=2)

I gave a very quick look to the issue and it seems that the problem has
be triggered bu the update to gdal 3.0.3.

-gdal-data 3.0.2+dfsg-1
+gdal-data 3.0.3+dfsg-1
-libgdal26 3.0.2+dfsg-1
+libgdal26 3.0.3+dfsg-1

rasterio could be also involved since the specific test uses rasterio to
retrieve the information about the geographic projection

I don't see any change in gdal data at a first look so probably the
problem is related behavior change in gdal that is not correctly handled
by pyresample or rasterio.

I need to make some additional investigation.


kind regards

-- 
Antonio Valentino

Bug#689528: please add virtio support for cdrom at install time

[Witold Baryluk]

Package: debian-installer
Followup-For: Bug #689528

Dear Maintainer,

any progress on this, I still have this issue.

I think the culprit might be in the `list-devices cd`, but the git /
salsa organization of debian-installer is very convoluted, and I can't
track it down where it is.


Regards,
Witold

Bug#949574: RFS: tl-expected/1.0.0~dfsg-1 [ITP] -- std::expected with functional-style extensions

[Nicholas Guriev]

Package: sponsorship-requests
Severity: wishlist
Control: blocks -1 949401

Dear mentors,

I am looking for a sponsor for my package "tl-expected"

 * Package name: tl-expected
   Version : 1.0.0~dfsg-1
   Upstream Author : Simon Brand 
 * URL : https://tl.tartanllama.xyz/
 * License : CC0 (Public Domain)
 * Vcs : https://salsa.debian.org/mymedia-guest/tl-expected
   Section : libdevel

It builds those binary packages:

  libexpected-dev - C++11/14/17 std::expected with functional-style extensions

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

  https://mentors.debian.net/package/tl-expected

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

  dget -x 
https://mentors.debian.net/debian/pool/main/t/tl-expected/tl-expected_1.0.0~dfsg-1.dsc

Changes since the last upload:

   * Initial upload. (Closes: #949401)

Regards,

--
  Nicholas Guriev

Bug#949570: dropwatch should not use the private binutils shared libraries

[Dmitry Smirnov]

On Wednesday, 22 January 2020 3:59:01 PM AEDT Matthias Klose wrote:
> dropwatch should not use the private binutils shared libraries.  If it
> cannot be dropped, then please link those statically and document it with
> the Built-Using tag in the binary package.

I don't understand. Where do you see private binutils libraries?

-- 
Best wishes,
 Dmitry Smirnov.

---

When reasons are weak, attitudes stiffen.
-- Stanisław Jerzy Lec


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

Bug#949572: debian-installer: Do not install Python2 by default.

[Witold Baryluk]

Package: debian-installer
Followup-For: Bug #949572

One more thing, reportbug, apt-listchanges, and few other packages
that look to be using Python, all work fine, and use Python3.

I rebooted the system, and things are working fine.

Bug#869897: [debian-installer] Please add support for the TRIM command for SSDs

[Witold Baryluk]

Package: debian-installer
Followup-For: Bug #869897


The dmcrypt / LUKS doesn't enable discard by default on purpose, as it might
potentially be a security issue. I don't think personally it is actual
security problem, but it is just my personal opinion. You would need to
convince dmcrypt / luks maintainer to change the default probably.


BTW. As of the moment kernel and ext4 and LVM doesn't detect automatically
if the device is discard (TRIM) capable, and doesn't use it by default,
which is rather missfortunate.

So, yeah, I think it does belong to installer, especially when doing
automated partitioning for the user.

However, I think it is worth doing some stress tests and benchmarks
on real hardware before actually implementing it. Anecdotal evidence
and "recommendations", just in case are very weak argument.

Also, there is a Debian Wiki article on this: 
https://wiki.debian.org/SSDOptimization

Another way to quickly see TRIm supporting devices is `lsblk --discard`
take a look at 3rd column (discard granularity), if it is more than 0,
it supports discard / TRIM.

Cheers,
Witold



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

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

Bug#861115: Please consider increasing net.ipv6.route.max_size default value

[Vincent Bernat]

 ❦ 21 janvier 2020 23:51 +00, Tim Bray :

>> This setting is for the size of the route cache. You can have far more
>> routes. In the past, there were bugs where each lookup will be put in
>> cache, but since 4.2, only the PMTU exceptions are stored in cache. See
>> 
>>
>> Do you have a lot of entries in `ip -6 route show cache`?
>
>
> No entries at all in
> `ip -6 route show cache`
>
> and none in `ip -6 route show table cache`
>
> It is a quiet time of day, so I'll check again.
>
> What prompted me to look at net.ipv6.route.max_size was because I built my 
> own newer kernel (in desperation).
>
> Linux version 5.4.11 (from kernel.org, .config from debian buster, make 
> olddefconfig) gives out in dmesg:
>
> Route cache is full: consider increasing sysctl net.ipv[4|6].route.max_size.
>
>
> I've never seen this message on 4.19 Debian buster, but increasing
> net.ipv6.route.max_size made all the network hangs go away, both on
> 5.4.11 and 4.19

The message was addeed in 5.1. I'll test later today to check if "ip -6
route show cache" still works.
-- 
Parenthesise to avoid ambiguity.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#949573: rsync systemd unit ignore default file

[Pavel Rauš]

Package: rsync

Version: 3.1.3-6



The rsync daemon starting via systemd unit including in the package ignore
variables in file /etc/default/rsync.



Could you fix this issue by adding EnvironmentFile into Service part of
systemd unit?

EnvironmentFile=-/etc/default/rsync



Thx



Pavel Raus

Bug#787583: CIM-4

[Margaret Yiu]

How's it going?

Thanks for your time.

I am Margaret Yiu, I got your contact via Qoo10. Would it be convenient for
you to be available for a business discussion?

I look forward to hearing from you at your convenience.

-- 


Dr. Margaret Yiu
Head Operations,
Standard Chartered Bank,
Hong Kong
***
The information contained in this communication is intended solely for the
use of the individual or entity to whom it is addressed and others
authorized to receive it. It may contain confidential or legally privileged
information.
If you are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution or taking any action in reliance on the
contents of this information is strictly prohibited and may be unlawful.
If you have received this communication in error please notify the sender
immediately by responding to this email and then delete it from your system.

Bug#787583: SDT-5

[Margaret Yiu]

Nice to meet you,

Thanks for your time.

I am Margaret Yiu, I got your contact via Qoo10. Would it be convenient for
you to be available for a business discussion?

I look forward to hearing from you at your convenience.

-- 


Dr. Margaret Yiu
Head Operations,
Standard Chartered Bank,
Hong Kong
***
The information contained in this communication is intended solely for the
use of the individual or entity to whom it is addressed and others
authorized to receive it. It may contain confidential or legally privileged
information.
If you are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution or taking any action in reliance on the
contents of this information is strictly prohibited and may be unlawful.
If you have received this communication in error please notify the sender
immediately by responding to this email and then delete it from your system.

Bug#949572: debian-installer: Do not install Python2 by default.

[Witold Baryluk]

Package: debian-installer
Severity: normal


Hi,

I just installed Debian using daily amd64 netinst iso (2020-01-21 iso),
and after I selected mostly minimal amount of stuff (plus popcon,
unatannteded-upgrades, and ssh server and standard utilities),
I rebooted, and checked the python2 packages.

I did spot that python2.7 and python (2) packages were installed.

I just done apt-get purge {,lib}{python,python2.7}{,-minimal,-stdlib}
and nothing else was removed. Just python2.

There is nothing in the minimal system that depends on it.

Removal was successfull.

$ python
bash: python: command not found
$

Good!

python3 works fine.

System looks to be working perfectly fine.

So the debian-installer, or debootstrap, or whatever is installing python (2),
should stop doing it. If some later package requires is as a dependency,
sure apt will install it, but by default it is unecassary dependency.

If there is some package or script that implicitly depends on Python2,
well so bad. It is better to simply remove this implicit dependency,
and by removing default installation of python2, it would be way easier
to actually find any such scripts, if any.


Best regards,
Witold




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

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

Bug#949570: dropwatch should not use the private binutils shared libraries

[Matthias Klose]

Package: src:dropwatch
Version: 1.5.1-2
Severity: serious
Tags: sid bullseye

dropwatch should not use the private binutils shared libraries.  If it cannot be
dropped, then please link those statically and document it with the Built-Using
tag in the binary package.

Bug#949571: naev should not use the private binutils shared libraries

[Matthias Klose]

Package: src:naev
Version: 0.7.0-2
Severity: serious
Tags: sid bullseye

naev should not use the private binutils shared libraries.  If it cannot be
dropped, then please link those statically and document it with the Built-Using
tag in the binary package.

Bug#949484: navit FTBFS on ppc64el, rsvg crashes.

[Joseph Herlant]

Hi Peter,

Thank for your report.

On Tue, Jan 21, 2020 at 6:09 AM peter green  wrote:
> Unfortunately the new version failed to build on ppc64el,
> it seems rsvg is crashing.

I noticed this issue but it seems to me like it's really an issue with
librsvg2 more than an issue with Navit itself.

> Potential solutions include.
>
> 1. Fix the build system to only build arch all data during
>the arch all build (the result of the rsvg run in question
>seems to be packaged in an arch all package).
> 2. Find and fix the underlying rsvg issue.

I'll just switch the svg2png processor to another tool, that should do
the trick for now.
Feel free to send a MR if you have a better patch! ;)

Thanks,
Joseph

Bug#949569: ITP: vtkplotter-examples -- Examples set for vtkplotter

[Drew Parsons]

Package: wnpp
Severity: wishlist
Owner: Drew Parsons 

* Package name: vtkplotter-examples
  Version : 2020.0.2
  Upstream Author : Marco Musy 
* URL : https://github.com/marcomusy/vtkplotter-examples
* License : MIT
  Programming Lang: Python
  Description : Examples set for vtkplotter

Repository for the set of more than 300 examples for vtkplotter.
Documentation can be found at https://vtkplotter.embl.es/

Search and run any of the examples with:
  vtkplotter --list
  vtkplotter -i -r gyroscope2

These examples were originally packaged with the vtkplotter package
and have recently been split out into a separate repository.

To be maintained alongside vtkplotter by the Debian Science team.

Bug#949567: fai-server: fai dirinstall option -N works not properly

[Stefan]

Package: fai-server
Version: 5.9
Severity: normal

Dear Thomas,
an execution of the following command works not as expected:
/usr/sbin/fai -N -v -u ${SERVERNAME} dirinstall
/srv/fai/container/${SERVERNAME}
after finishing the action, it appears just a small (maybe a basic install)
system, no classes are used.

After executing the same command (without deleting the the content from the
install just run like before!),
the fai will use the proper classes and make an install as expected
(configured) <- So that's my
workaround

If I use the -c option and put all classes manually there, I got other failures
(obviously there
are not (all) variables in the env - this is not happend during the second
install from above). So I
cannot use that option too.

Best regards
Stefan

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

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

Versions of packages fai-server depends on:
ii  debootstrap  1.0.114
ii  e2fsprogs1.44.5-1+deb10u2
ii  fai-client   5.9
ii  xz-utils 5.2.4-1

Versions of packages fai-server recommends:
ii  dosfstools4.1-2
ii  isc-dhcp-server   4.4.1-2
ii  libproc-daemon-perl   0.23-1
ii  mtools4.0.23-1
ii  nfs-kernel-server 1:1.3.4-2.5
ii  openbsd-inetd [inet-superserver]  0.20160825-4
ii  openssh-client1:7.9p1-10+deb10u1
ii  openssh-server1:7.9p1-10+deb10u1
ii  tftpd-hpa 5.2+20150808-1+b1

Versions of packages fai-server suggests:
ii  binutils   2.31.1-16
pn  debmirror  
ii  fai-setup-storage  5.9
pn  grub2  
ii  perl-tk1:804.033-2+b3
ii  qemu-utils 1:3.1+dfsg-8+deb10u2
pn  reprepro   
ii  squashfs-tools 1:4.3-12
ii  xorriso1.5.0-1

-- Configuration Files:
/etc/fai/NFSROOT changed [not included]
/etc/fai/apt/sources.list changed [not included]
/etc/fai/nfsroot.conf changed [not included]

-- no debconf information



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

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

Versions of packages fai-server depends on:
ii  debootstrap  1.0.116ubuntu1.1
pn  fai-client   
ii  xz-utils 5.2.4-1

Versions of packages fai-server recommends:
pn  isc-dhcp-server   
pn  libproc-daemon-perl   
pn  nfs-kernel-server 
pn  openbsd-inetd | inet-superserver  
ii  openssh-client1:8.0p1-6build1
ii  openssh-server1:8.0p1-6build1
pn  tftpd-hpa | atftpd

Versions of packages fai-server suggests:
ii  aptitude   0.8.11-3ubuntu3
ii  binutils   2.33-2ubuntu1.2
pn  debmirror  
pn  fai-setup-storage  
pn  grub2  
pn  perl-tk
ii  qemu-utils 1:4.0+dfsg-0ubuntu9.2
pn  reprepro   
ii  squashfs-tools 1:4.4-1
pn  xorriso

Bug#949568: libomxil-bellagio: Please mark libomxil-bellagio-doc Multi-Arch: foreign

[Steve Langasek]

Package: libomxil-bellagio
Version: 0.9.3-4.1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Hi Paul,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The only thing that currently prevents libomxil-bellagio from being
cross-testable is that autopkgtest wants to install the i386 versions of all
the binaries built from this source, but libomxil-bellagio-doc is an Arch:
all package which is not marked Multi-Arch: foreign, so apt will treat it as
a package of the host architecture (amd64) and the test dependencies are
unsatisfiable.

I've verified that the attached patch is sufficient to make
libomxil-bellagio cross-testable in Ubuntu for i386 tests on an amd64 host.

And marking libomxil-bellagio-doc Multi-Arch: foreign is correct in Debian
as well, since it's a documentation package and is therefore fine to satisfy
foreign-arch dependencies (or test dependencies).

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru libomxil-bellagio-0.9.3/debian/control 
libomxil-bellagio-0.9.3/debian/control
--- libomxil-bellagio-0.9.3/debian/control  2016-11-12 12:44:17.0 
-0800
+++ libomxil-bellagio-0.9.3/debian/control  2020-01-21 16:46:24.0 
-0800
@@ -108,6 +108,7 @@
 
 Package: libomxil-bellagio-doc
 Architecture: all
+Multi-Arch: foreign
 Section: doc
 Depends: lynx | www-browser, libjs-jquery, ${misc:Depends}
 Description: Documentation of the Bellagio OpenMAX IL

Bug#949566: iproute2: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: iproute2
Version: 5.4.0-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The iproute2 tests currently fail in this environment, because they include
a build test that does not invoke the toolchain in a cross-aware manner and
because they try to install cross versions of base packages when they should
use the available host versions.  I've verified that the attached patch lets
the tests successfully build (and run) i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru iproute2-5.4.0/debian/tests/control 
iproute2-5.4.0/debian/tests/control
--- iproute2-5.4.0/debian/tests/control 2019-11-28 02:47:08.0 -0800
+++ iproute2-5.4.0/debian/tests/control 2020-01-21 16:35:46.0 -0800
@@ -2,4 +2,5 @@
 # therefore do not run as build time tests
 Tests: testsuite.sh
 Restrictions: allow-stderr, isolation-machine, needs-root, rw-build-tree
-Depends: build-essential, locales-all, dpkg-dev, sudo, kmod, @builddeps@
+Depends: build-essential, locales-all, dpkg-dev, sudo:native, kmod, @builddeps@
+
diff -Nru iproute2-5.4.0/debian/tests/testsuite.sh 
iproute2-5.4.0/debian/tests/testsuite.sh
--- iproute2-5.4.0/debian/tests/testsuite.sh2019-11-28 02:47:08.0 
-0800
+++ iproute2-5.4.0/debian/tests/testsuite.sh2020-01-21 16:35:46.0 
-0800
@@ -1,10 +1,16 @@
 #!/bin/sh
 set -uxe
 
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+vars="CC=$DEB_HOST_GNU_TYPE-gcc LD=$DEB_HOST_GNU_TYPE-ld"
+else
+vars=""
+fi
+
 # copy built-tree to tmp test dir to gurantee no files are left behind
 dir=$(mktemp -d)
 cp -a . "${dir}"
 cd "${dir}"
 
 # build and run tests
-make check
+make $vars check

Bug#947452: RFS: kworkflow/20191112-1 [ITP] -- Inglorious kernel developer workflow scripts

[Rodrigo Carvalho]

A new version was uploaded. Thanks Adam!

Bug#949565: IPv6 Router Advertisement: skip interfaces by no-dhcp-interface

[NIIBE Yutaka]

Package: dnsmasq
Version: 2.80-1
Severity: normal
Tags: ipv6 patch upstream

Hello,

Situation: My ISP doesn't offer IPv6 prefix delegation and just gives
/64 IPv6 address.  I configure my router with ndppd (NDP Proxy
Daemon), running dnsmasq for internal network.

It mostly works, but I observed no periodical IPv6 Router
Advertisement (only reply to Router Solicitation) to internal network.

With a line in dnsmasq.conf:

no-dhcp-interface=
interface=

I expected dnsmasq does IPv6 Router Advertisement, even though these
interfaces share same IPv6 network address.  It does for Router
Solicitation request, but no periodical ones.

I think I found a problem in src/radv.c.  When an interface is
searched, it doesn't skip interfaces with no-dhcp-interface, so,
invalid interface may be identified.  (Note that in the periodic_ra
function, there is code to skip the interface _after_ interface is
identified.)


When I applied following patch, I started to observe IPv6 Router
Advertisement in internal network.

I'm not sure if this patch is correct, or good one.  This is for
sharing the problem.

diff --git a/src/radv.c b/src/radv.c
index cad0530..82f9603 100644
--- a/src/radv.c
+++ b/src/radv.c
@@ -917,6 +917,17 @@ static int iface_search(struct in6_addr *local,  int 
prefix,
param->iface = 0;
return 0;
  }
+
+{
+ struct iname *tmp;
+ for (tmp = daemon->dhcp_except; tmp; tmp = tmp->next)
+   if (tmp->name && wildcard_match(tmp->name, param->name))
+ break;
+
+  /* Skip this interface.  */
+  if (tmp)
+return 1;
+}

new_timeout(context, param->name, param->now);



-- System Information:
Debian Release: 10.2
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-debug'), (500, 'unstable'), (500, 
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages dnsmasq depends on:
ii  dnsmasq-base [dnsmasq-base]  2.80-1
ii  init-system-helpers  1.56+nmu1
ii  lsb-base 10.2019051400
ii  netbase  5.6

dnsmasq recommends no packages.

Versions of packages dnsmasq suggests:
pn  resolvconf  

-- Configuration Files:
/etc/default/dnsmasq changed [not included]

-- no debconf information

Bug#949564: cache parsed files in between fixers to improve performance

[Jelmer Vernooij]

Package: lintian-brush
Version: 0.56
Severity: normal

Rather than parsing certain files again and again for each fixer, lintian-brush
should cache them in between fixers if it can.

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

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

Versions of packages lintian-brush depends on:
ii  devscripts   2.19.7
ii  python3  3.7.5-3
ii  python3-breezy   3.0.2-1
ii  python3-debian   0.1.36
ii  python3-distro-info  0.23
ii  python3-dulwich  0.19.14-4
ii  python3-iniparse 0.4-3
ii  python3-levenshtein  0.12.0-5
ii  python3-pkginfo  1.4.2-2
ii  python3-ruamel.yaml  0.15.89-3+b1

Versions of packages lintian-brush recommends:
ii  dos2unix   7.4.0-2
ii  gpg2.2.19-1
ii  libdebhelper-perl  12.8
ii  lintian2.46.0
ii  python3-asyncpg0.20.0-1
ii  python3-pyinotify  0.9.6-1.2

Versions of packages lintian-brush suggests:
pn  gnome-pkg-tools
ii  postgresql-common  210

-- no debconf information

Bug#946996: wireguard-tools: 'wg-quick down' segfaults

[Celejar]

On Tue, 21 Jan 2020 10:36:25 -0500
Daniel Kahn Gillmor  wrote:

> Control: reassign 946996 iptables
> Control: affects 946996 + wireguard-tools
> 
> Hi Celejar--
> 
> On Thu 2019-12-19 00:00:39 -0500, Celejar wrote:
> > Package: wireguard-tools
> > Version: 0.0.20191212-1
> > Severity: normal
> >
> > I use wireguard to establish a very simple point-to-point VPN. 'wg-quick
> > up wgo' works fine; 'wg-quick down wg0' also seems to work correctly,
> > but it segfaults after doing (AFAICT) everything that it's supposed to
> > do. Everything seems to be working fine, though, both before and afterward.

...

> Thanks for this report.  It looks to me like this is a segfault in
> iptables-restore, not in wg-quick, so i'm reassigning the bug report to
> the iptables package, which shouldn't segfault, no matter what input it
> receives.  (maybe this is due to sending it empty lines?
> 
> In the meantime, i believe that more recent versions of wireguard-tools
> do not send empty lines to iptables-restore.  Can you verify that this
> doesn't happen for you with a more recent version?

Sorry, I'm still getting it:

~# apt-cache policy wireguard-tools 
wireguard-tools:
  Installed: 1.0.20200102-1
  Candidate: 1.0.20200102-1
  Version table:
 *** 1.0.20200102-1 500
500 http://deb.debian.org/debian sid/main amd64 Packages
100 /var/lib/dpkg/status

~# ifdown wg0
[#] ip -4 rule delete table 51820
[#] ip -4 rule delete table main suppress_prefixlength 0
[#] ip link delete dev wg0
[#] resolvconf -d tun.wg0 -f
[#] iptables-restore -n
/usr/bin/wg-quick: line 29: 186243 Segmentation fault  "$@"

...

> Thanks for reporting this,

Thank you for all your Debian, technology, and privacy work!

Celejar

Bug#936740: Fixed in rev -3

[Steve Robbins]

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#941336: nvidia-legacy-340xx-kernel-dkms: Kernel module nvidia-legacy-340xx can't be loaded

[Paul Vojta]

I noticed similarities with Bug #941427 (relating to non-legacy nvidia drivers),
and I found that the procedure in Message 10 in that bug report worked for me.

I suspect it's a problem with some package's "Depends" or "Pre-depends"
declarations.

(This solves the problem reported in this bug report, but the machine still
has problems with suspend/resume.  That's a problem for another bug report.)

Paul Vojta

Bug#949563: ruby-defaults: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: ruby-defaults
Version: 1:2.5.2
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Hi Antonio,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The ruby-defaults tests currently fail in this environment, because one of
them invokes pkg-config to check for correct registration of the .pc file. 
However, it does not invoke pkg-config in a cross-aware manner.  I've
verified that the attached patch lets the tests successfully build (and run)
i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru ruby-defaults-2.5.2/debian/tests/control 
ruby-defaults-2.5.2ubuntu1/debian/tests/control
--- ruby-defaults-2.5.2/debian/tests/control2019-10-16 15:30:22.0 
-0700
+++ ruby-defaults-2.5.2ubuntu1/debian/tests/control 2020-01-21 
16:12:51.0 -0800
@@ -6,5 +6,5 @@
 Depends: ruby, ruby-all-dev
 Restrictions: allow-stderr
 
-Test-Command: pkg-config --cflags --libs ruby
+Test-Command: ${DEB_HOST_GNU_TYPE:+$DEB_HOST_GNU_TYPE-}pkg-config --cflags 
--libs ruby
 Depends: ruby-dev, pkg-config

Bug#949562: #949562: espeak-ng need to Build-Depend on kramdown soon

[Chris Hofstaedtler]

Hi,

I'm going to upload a ruby-kramdown with the changes described by
Helmut. Once this enters the archive, espeak-ng will FTBFS as
/usr/bin/kramdown will have moved to the new "kramdown" package.

Chris

Bug#861115: Please consider increasing net.ipv6.route.max_size default value

[Tim Bray]

On 21/01/2020 19:37, Vincent Bernat wrote:

This setting is for the size of the route cache. You can have far more
routes. In the past, there were bugs where each lookup will be put in
cache, but since 4.2, only the PMTU exceptions are stored in cache. See


Do you have a lot of entries in `ip -6 route show cache`?



No entries at all in
`ip -6 route show cache`

and none in `ip -6 route show table cache`

It is a quiet time of day, so I'll check again.

What prompted me to look at net.ipv6.route.max_size was because I built my own 
newer kernel (in desperation).

Linux version 5.4.11 (from kernel.org, .config from debian buster, make 
olddefconfig) gives out in dmesg:

Route cache is full: consider increasing sysctl net.ipv[4|6].route.max_size.


I've never seen this message on 4.19 Debian buster,  but increasing 
net.ipv6.route.max_size made all the network hangs go away, both on 5.4.11 and 
4.19

Tim Bray

Bug#948550: buster-pu: package e2fsprogs/1.44.5-1+deb10u2

[Theodore Y. Ts'o]

On Tue, Jan 21, 2020 at 07:57:54PM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed d-i
> 
> On Thu, 2020-01-09 at 22:34 -0500, Theodore Y. Ts'o wrote:
> > +e2fsprogs (1.44.5-1+deb10u3) buster; urgency=medium
> > +
> > +  * Fix CVE-2019-5188: potential stack underflow in e2fsck (Closes:
> > #948508)
> > +  * Fix use after free in e2fsck (Closes: #948517)
> 
> This looks OK to me, but will also need a d-i ACK as e2fsprogs produces
> a udeb; CCing and tagging to reflect that.

Thanks!  Should I go ahead and upload, or should we wait for the d-i
ACK first?  It'll just stay in the proposed-stable-updates queue until
final approval as I understand things, correct?

Cheers,

- Ted

Bug#949432: FYI, new hang

[Karl O. Pinc]

Hello,

FYI.  Just had chromium hang in debug mode.  This is not
reproducible.

I was left with the "unresponsive white screen" of
my original bug report.

$ chromium --debug
# Env:
# LD_LIBRARY_PATH=
#PATH=/usr/local/bin:/usr/bin:/bin:/usr/games
#GTK_PATH=
#  CHROMIUM_FLAGS= --show-component-extension-options 
--enable-gpu-rasterization --no-default-browser-check --disable-pings 
--media-router=0 --enable-remote-extensions --load-extension=
/usr/bin/gdb /usr/lib/chromium/chromium -x /tmp/chromiumargs.Hxg3FA
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/chromium/chromium...(no debugging symbols 
found)...done.
(gdb) run
Starting program: /usr/lib/chromium/chromium --show-component-extension-options 
--enable-gpu-rasterization --no-default-browser-check --disable-pings 
--media-router=0 --enable-remote-extensions --load-extension= --single-process 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffea9e1700 (LWP 1397)]
[Detaching after fork from child process 1398]
[New Thread 0x7fffea1e0700 (LWP 1402)]
[New Thread 0x7fffe3fff700 (LWP 1403)]
[New Thread 0x7fffe37fe700 (LWP 1404)]
[New Thread 0x7fffe2ffd700 (LWP 1405)]
[New Thread 0x7fffe27fc700 (LWP 1406)]
[New Thread 0x7fffe1ffb700 (LWP 1407)]
[New Thread 0x7fffe17fa700 (LWP 1408)]
[New Thread 0x7fffe0ff9700 (LWP 1409)]
[New Thread 0x7fffc700 (LWP 1418)]
[New Thread 0x7fffe847b700 (LWP 1419)]
[New Thread 0x7fffcf7fe700 (LWP 1420)]
[New Thread 0x7fffceffd700 (LWP 1421)]
[New Thread 0x7fffce7fc700 (LWP 1422)]
[New Thread 0x7fffcdffb700 (LWP 1423)]
[New Thread 0x7fffcd7fa700 (LWP 1424)]
[New Thread 0x7fffccff9700 (LWP 1428)]
[New Thread 0x7fff9bfff700 (LWP 1429)]
[New Thread 0x7fff9b7fe700 (LWP 1433)]
[New Thread 0x7fff9affd700 (LWP 1434)]
[New Thread 0x7fff9a7fc700 (LWP 1437)]
[1392:1392:0121/165948.721531:ERROR:system_network_context_manager.cc(726)] 
Cannot use V8 Proxy resolver in single process mode.
[New Thread 0x7fff99ffb700 (LWP 1438)]
[New Thread 0x7fff997fa700 (LWP 1439)]
libGL error: failed to authenticate magic 1
libGL error: failed to load driver: radeonsi
[1392:1392:0121/165948.915339:ERROR:system_network_context_manager.cc(726)] 
Cannot use V8 Proxy resolver in single process mode.
[New Thread 0x7fff7bfff700 (LWP 1440)]
[Thread 0x7fff7bfff700 (LWP 1440) exited]
[New Thread 0x7fff7affd700 (LWP 1441)]
[New Thread 0x7fff7b7fe700 (LWP 1442)]
[New Thread 0x7fff7a7fc700 (LWP 1443)]
[New Thread 0x7fff79ffb700 (LWP 1444)]
[New Thread 0x7fff797fa700 (LWP 1445)]
[New Thread 0x7fff78ff9700 (LWP 1446)]
[New Thread 0x7fff63fff700 (LWP 1450)]
[New Thread 0x7fff637fe700 (LWP 1451)]
[New Thread 0x7fff62ffd700 (LWP 1452)]
[New Thread 0x7fff627fc700 (LWP 1453)]
[New Thread 0x7fff61ffb700 (LWP 1457)]
[New Thread 0x7fff617fa700 (LWP 1458)]
[New Thread 0x7fff57fff700 (LWP 1460)]
[New Thread 0x7fff60ff9700 (LWP 1459)]

Thread 17 "CompositorTileW" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffcd7fa700 (LWP 1424)]
0x595dafe8 in ?? ()


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Bug#943370: Me too

[Daniel Leidert]

Is there any progress on this issue? My ELAN touchpad (Acer Aspire 7) is not
working either with linux-image-5.4.0-1-amd64 and linux-image-5.4.0-2-amd64
(have not tested linux-image-5.4.0-3-amd64 yet). It works with linux-image-
5.3.0-1-amd64.

Regards, Daniel


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

Bug#855389: calibre: exception when adding custom open-with program

[Eli Schwartz]

Should be fixed a very long time ago (4 months after it was reported
here) via
https://github.com/kovidgoyal/calibre/commit/768bdc2d8eaee4728a6dfe29e917b048f7aeea0a

In the future, please consider trying to install the official prebuilt
binaries at https://calibre-ebook.com/download_linux and seeing if the
error can be duplicated; if you still get the error, then it's an
upstream bug and can be reported to the calibre developer at
https://calibre-ebook.com/bugs

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Bug#949163: Please provide a repo for packages not intent for users

[Ximin Luo]

Paul Wise:
> On Mon, 2020-01-20 at 22:51 +0800, Shengjing Zhu wrote:
>> On Mon, Jan 20, 2020 at 10:37 PM Ximin Luo wrote:
>>> This doesn't work for Rust unfortunately, due to features. Based on
>>> which feature-set is activated, when you depend on a source-package 
>>> you would want to pull in different sets of transitive
>>> dependencies.
>>>
>>> However, a combination of:
>>>
>>> 1. implicitly being able to install source packages into /usr/src
>>> 2. metadata-only binary Packages that can depend on these implicit
>>> source packages
>>
>> This applies to Go too. Currently a source-package's build-depends
>> usually include those for testing purposes, which are not needed when
>> building the rdepends. Or we don't test it, or we have a separate
>> control-filed in source-package..
> 
> IIRC the proposals about build-depending on source packages included
> being able to build-depend on their build-depends. If you could also
> filter those build-depends by build profiles then that might work.
> 

Filtering by build-profile doesn't work as we have no mechanism to say that 
build profile A should automatically imply build profile B on a dependency.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#949561: alsa-lib: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: alsa-lib
Version: 1.2.1.2-2
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The alsa-lib tests currently fail in this environment, because they are a
build test that does not invoke the toolchain in a cross-aware manner.  I've
verified that the attached patch lets the tests successfully build (and run)
i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru alsa-lib-1.2.1.2/debian/tests/build-seq 
alsa-lib-1.2.1.2/debian/tests/build-seq
--- alsa-lib-1.2.1.2/debian/tests/build-seq 2019-10-11 04:02:05.0 
-0700
+++ alsa-lib-1.2.1.2/debian/tests/build-seq 2020-01-21 14:22:23.0 
-0800
@@ -5,6 +5,13 @@
 
 set -e
 
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
+
 WORKDIR=$(mktemp -d)
 trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
 cd $WORKDIR
@@ -19,7 +26,7 @@
 }
 EOF
 
-gcc -o asound_build_test asound_build_test.c -lasound
+${CROSS_COMPILE}gcc -o asound_build_test asound_build_test.c -lasound
 echo "build: OK"
 [ -x asound_build_test ]
 ./asound_build_test 2>&1

Bug#949560: CVE-2020-6623

[Moritz Muehlenhoff]

Source: libstb
Severity: normal
Tags: security

This was assigned CVE-2020-6623:
https://github.com/nothings/stb/issues/865

Cheers,
Moritz

Bug#949559: CVE-2020-6622

[Moritz Muehlenhoff]

Source: libstb
Severity: normal
Tags: security

This was assigned CVE-2020-6622:
https://github.com/nothings/stb/issues/869

Cheers,
Moritz

Bug#949558: CVE-2020-6621

[Moritz Muehlenhoff]

Source: libstb
Severity: normal
Tags: security

This was assigned CVE-2020-6621:
https://github.com/nothings/stb/issues/867

Cheers,
Moritz

Bug#949557: CVE-2020-6620

[Moritz Muehlenhoff]

Source: libstb
Severity: normal
Tags: security

This was assigned CVE-2020-6620:
https://github.com/nothings/stb/issues/868

Cheers,
Moritz

Bug#949554: CVE-2019-6617

[Moritz Muehlenhoff]

Source: libstb
Severity: normal
Tags: security

This was assigned CVE-2019-6617:
https://github.com/nothings/stb/issues/867

Cheers,
Moritz

Bug#949555: CVE-2020-6618

[Moritz Muehlenhoff]

Source: libstb
Severity: normal
Tags: security

This was assigned CVE-2020-6618:
https://github.com/nothings/stb/issues/866

Cheers,
Moritz

Bug#949556: CVE-2020-6619

[Moritz Muehlenhoff]

Source: libstb
Severity: normal
Tags: security

This was assigned CVE-2020-6619:
https://github.com/nothings/stb/issues/863

Cheers,
Moritz

Bug#939260: websploit: Python2 removal in sid/bullseye

[Marcos Fouces]

Hello Fardin
I am the uploader of websploit in Debian distro. I am trying to package
your new release but AFAIK one of the dependencies (python-wifi) is
only for python2. Currently we cannot package new python2 modules in
Debian.
Please, let me know  if i am wrong because i am all for packaging this
release for Debian, Kali...
Greetings, Marcos.



El lun, 20-01-2020 a las 08:07 -0500, Optimous Prime escribió:
> Hi RaphaelI just finished updating websploit. latest version now
> available on github 
> https://github.com/websploit/websploit
> Cheers
> On Wed, Jan 15, 2020 at 5:00 AM 0X0Ptim0Us <0x0ptim...@gmail.com>
> wrote:
> > Hi Raphael
> > I’m working on it and i will release new version before 24th.
> > Thanks
> > 
> > 
> > 
> > > On Jan 15, 2020 at 12:27 PM,  wrote:
> > > 
> > > Hello Fardin,
> > > 
> > > 
> > > any update?
> > > 
> > > 
> > > Due to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939260,
> > > https://tracker.debian.org/pkg/websploit indicates that websploit
> > > will
> > > be auto-removed from Debian testing on January 24th.
> > > 
> > > 
> > > It would be nice to have a Python 3 version until then.
> > > 
> > > 
> > > Cheers,
> > > 
> > > 
> > > On Sat, 21 Dec 2019, Optimous Prime wrote:
> > > > Hi, i'm working on it, maybe 20 day .
> > > >  
> > > > On Mon, Dec 16, 2019 at 8:28 AM Raphael Hertzog <
> > > hert...@debian.org> wrote:
> > > >  
> > > > > Hello,
> > > > >
> > > > > On Tue, 10 Dec 2019, 0X0Ptim0Us wrote:
> > > > > > Got it, thank you. I will work on it
> > > > >
> > > > > Great. Looking forward to it. Do you have any idea how much
> > > time you need
> > > > > to complete this Python 3 port of websploit?
> > > > >
> > > > > Regards,
> > > > > --
> > > > >   ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
> > > > >   ⣾⠁⢠⠒⠀⣿⡁
> > > > >   ⢿⡄⠘⠷⠚⠋The Debian Handbook: 
> > > https://debian-handbook.info/get/
> > > 
> > > > >   ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS
> > > 
> > > > >
> > > 
> > > 
> > > --  
> > >   ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
> > >   ⣾⠁⢠⠒⠀⣿⡁
> > >   ⢿⡄⠘⠷⠚⠋The Debian Handbook: 
> > > https://debian-handbook.info/get/
> > > 
> > >   ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS
> > > 

Bug#949553: wireless-regdb: Package is terribly outdated

[Miguel A. Vallejo]

Package: wireless-regdb
Version: 2016.06.10-1
Severity: normal

Dear Maintainer,

Please consider upgrading this package to an up-to-date version. It is
more than 3 years old and significant changes have occurred since then
worldwide, especially on the 5 GHz band.

For example, using wireless-regdb version 2016.06.10-1, the one
currently used in all active Debian versions, my regulatory domain is:

~# iw reg get
global
country ES: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 20), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
(57000 - 66000 @ 2160), (N/A, 40), (N/A)

If I update manually /lib/crda/regulatory.bin with the latest one at
https://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git,
my regulatory domain changes to this:

~# iw reg get
global
country ES: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 20), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
(5725 - 5875 @ 80), (N/A, 13), (N/A)
(57000 - 66000 @ 2160), (N/A, 40), (N/A)

In my case the updated database enables the scanning and use of APs
running in the 5725 - 5875 MHz band and probably prevents WiFi
dropouts when the AP, because of DFS, moves to a channel on that
range.

Thanks in advance.

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

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

wireless-regdb depends on no packages.

wireless-regdb recommends no packages.

Versions of packages wireless-regdb suggests:
ii  crda  3.18-1

-- no debconf information

Bug#949552: Consider linking against archive version of libstb

[Moritz Muehlenhoff]

Package: goxel
Severity: important

ext_src/stb contains stb_image.h, stb_image_write.h, stb_rect_pack.h, 
stb_textedit.h, stb_truetype.h

These are also available in src:libstb, so please consider linking against the 
in-archive copy.

Cheers,
Moritz

Bug#949551: RM: libexosip2 -- RoQA; unmaintained, open security issues

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove libexosip2. It's unmaintained (last maintainer upload
six years ago), there are open security issues and there are no
reverse deps.

Cheers,
Moritz

Bug#949545: cacti: cli/add_device.php reports success but device-id is 0 and never appears in the host list

[Jim McNamara]

On Tue, Jan 21, 2020 at 4:43 PM Paul Gevers  wrote:

> Control: forwarded -1 https://github.com/Cacti/cacti/issues/3111
> Control: tags -1 - moreinfo
>
>
> []

> No problem. Do you agree that this doesn't warrant an update in buster?
> With the update it would generate an error (instead of "fixing" the
> situation), but that's nicer than nothing happening.
>
> I agree that it doesn't merit an update exclusively to fix this issue, but
I do think it would be a practical to include the error generation whenever
the next update happens.

Paul
>
> Jim

Bug#949545: cacti: cli/add_device.php reports success but device-id is 0 and never appears in the host list

[Paul Gevers]

Control: forwarded -1 https://github.com/Cacti/cacti/issues/3111
Control: tags -1 - moreinfo

Hi Jim,

On 21-01-2020 22:18, Jim McNamara wrote:
> You're most welcome, thank you for maintaining software I've found
> tremendously useful over the last 15 years.

YW.

> I found this upstream report: https://github.com/Cacti/cacti/issues/3111
> Can you check your cacti.log for errors and see if the issue matches?
> 
>  
> That is precisely my issue, thank you. The error when trying to add my
> host shows that net-snmp was being provided as the snmp_version -

[...]

> Thanks again, sorry I missed the upstream bug.

No problem. Do you agree that this doesn't warrant an update in buster?
With the update it would generate an error (instead of "fixing" the
situation), but that's nicer than nothing happening.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#949550: RFP: chiaki -- Free and Open Source PS4 Remote Play Client

[Pierre Rudloff]

Package: wnpp
Severity: wishlist

* Package name: chiaki
  Version : 1.1.2
  Upstream Author : Florian Märkl 
* URL : https://github.com/thestr4ng3r/chiaki
* License : GPL
  Programming Lang: C
  Description : Free and Open Source PS4 Remote Play Client

Chiaki is a Free and Open Source Software Client for PlayStation 4 
Remote Play

for Linux, Android, macOS, Windows and potentially even more platforms.

The official PS4 remote play client from Sony has no Linux version so AFAIK
Chiaki is the only way to use remote play natively on Linux.

Bug#949545: cacti: cli/add_device.php reports success but device-id is 0 and never appears in the host list

[Jim McNamara]

On Tue, Jan 21, 2020 at 3:48 PM Paul Gevers  wrote:

> Control: tags -1 moreinfo
>
> Hi Jim,
>
> Thanks for reporting issues you encounter.
>

You're most welcome, thank you for maintaining software I've found
tremendously useful over the last 15 years.


>
> On 21-01-2020 21:15, Jim McNamara wrote:
> >* What led up to the situation?
> >   Upgraded machine from Stretch to Buster, cacti was upgraded in
> process from 0.8.8 to 1.2.2.
> >
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> >   Any host added through the use of
> /usr/share/cacti/cli/add_device.php reports success, but the device-id is
> always 0 and the host never appears either in the web interface or via
> /usr/share/cacti/cli/add_tree.php --list-hosts
> >
> >* What was the outcome of this action?
> >   ++ /usr/share/cacti/cli/add_device.php --template=1
> --description=192.168.112.200 --ip=192.168.112.200 --community=public
> >   + ADDHOST='Adding 192.168.112.200 (192.168.112.200) as "Generic
> SNMP-enabled Host" using SNMP vnet-snmp with community "public"
> >   Success - new device-id: (0)'
> >
> >   The host is not added, and 0 seems like an odd device-id as they
> seem to start from 1
> >
> >* What outcome did you expect instead?
> >
> >   Host would be added with the next available device-id, that new
> device-id should be reported by the add-device.php script
>
> I found this upstream report: https://github.com/Cacti/cacti/issues/3111
> Can you check your cacti.log for errors and see if the issue matches?
>

That is precisely my issue, thank you. The error when trying to add my host
shows that net-snmp was being provided as the snmp_version -

01/21/2020 14:44:50 - DBCALL ERROR: SQL Save Failed for Table 'host'.
SQL:'INSERT INTO host (`id`, `host_template_id`, `poller_id`, `site_id`,
`external_id`, `description`, `hostname`, `notes`, `location`,
`snmp_version`, `snmp_community`, `snmp_username`, `snmp_password`,
`snmp_auth_protocol`, `snmp_priv_passphrase`, `snmp_priv_protocol`,
`snmp_context`, `snmp_engine_id`, `snmp_port`, `snmp_timeout`, `disabled`,
`availability_method`, `ping_method`, `ping_port`, `ping_timeout`,
`ping_retries`, `max_oids`, `device_threads`) VALUES (267, 1, 1, 1, '',
'192.168.112.200', '192.168.112.200', '', '', net-snmp, 'public', '', '',
'', '', '', '', '', 161, 500, '', 1, 1, 23, 400, 1, 10, 1) ON DUPLICATE KEY
UPDATE `host_template_id`=VALUES(`host_template_id`),
`poller_id`=VALUES(`poller_id`), `site_id`=VALUES(`site_id`),
`external_id`=VALUES(`external_id`), `description`=VALUES(`description`),
`hostname`=VALUES(`hostname`), `notes`=VALUES(`notes`),
`location`=VALUES(`location`), `snmp_version`=VALUES(`snmp_version`),
`snmp_community`=VALUES(`snmp_community`),
`snmp_username`=VALUES(`snmp_username`),
`snmp_password`=VALUES(`snmp_password`),
`snmp_auth_protocol`=VALUES(`snmp_auth_protocol`),
`snmp_priv_passphrase`=VALUES(`snmp_priv_passphrase`),
`snmp_priv_protocol`=VALUES(`snmp_priv_protocol`),
`snmp_context`=VALUES(`snmp_context`),
`snmp_engine_id`=VALUES(`snmp_engine_id`), `snmp_port`=VALUES(`snmp_port`),
`snmp_timeout`=VALUES(`snmp_timeout`), `disabled`=VALUES(`disabled`),
`availability_method`=VALUES(`availability_method`),
`ping_method`=VALUES(`ping_method`), `ping_port`=VALUES(`ping_port`),
`ping_timeout`=VALUES(`ping_timeout`),
`ping_retries`=VALUES(`ping_retries`), `max_oids`=VALUES(`max_oids`),
`device_threads`=VALUES(`device_threads`)'

Redoing the call to add and including --version=1 solves things in the
short term:

./add_device.php --template=1 --description=192.168.112.200
--ip=192.168.112.200 --community=public --version=1
Adding 192.168.112.200 (192.168.112.200) as "Generic SNMP-enabled Host"
using SNMP v1 with community "public"
Success - new device-id: (267)


Thanks again, sorry I missed the upstream bug.

Jim

Bug#944982: open-infrastructure-compute-tools: Script accesses internal dpkg database

[Daniel Baumann]

reopen 944982
thanks

Hi Guillem,

On 1/21/20 10:00 PM, Guillem Jover wrote:
> Not sure whether the above is a typo or a misunderstanding.

misunderstanding, sorry.. my fault.

> The
> problem is with the dpkg db accesses. The script does:
> 
>   if [ -e "${DIRECTORY}/var/lib/dpkg/info/locales.list" ] && \

I misread that you ment the debconf db files
$tmp/foo.xxx/{config,passwords,templates}.dat, rather than ones from
dpkg. Sorry about that.

Reopening.. and I'll fix that by the next upload in a couple of days, at
latest next weekend.

Regards,
Daniel

Bug#949549: tango-accesscontrol: Does not use hardening flags for compilation

[Thomas Braun]

Package: tango-accesscontrol
Version: 9.3.4~rc2+dfsg2-1~exp3
Severity: normal

Dear Maintainer,

according to the lintian output and my own testing the hardening flags
are not set correctly for TangoAccessControl.

/usr/lib/tango/TangoAccessControl:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: no, only unprotected functions found!
 Read-only relocations: yes
 Immediate binding: yes
 Stack clash protection: unknown, no -fstack-clash-protection
instructions found
 Control flow integrity: unknown, no -fcf-protection instructions
found!

They seems to be set correctly for DatabaseDS and Starter.

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

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

Versions of packages tango-accesscontrol depends on:
ii  init-system-helpers  1.57
ii  libc62.29-9
ii  libgcc1  1:9.2.1-23
ii  libmariadb3  1:10.3.21-2
ii  libomniorb4-24.2.2-0.9+b1
ii  libomnithread4   4.2.2-0.9+b1
ii  libstdc++6   9.2.1-23
ii  libtango-tools   9.3.4~rc2+dfsg2-1~exp3
ii  libtango99.3.4~rc2+dfsg2-1~exp3
ii  lsb-base 11.1.0
ii  tango-db 9.2.5a+dfsg1-2+b2
ii  tango-starter9.2.5a+dfsg1-2+b2

tango-accesscontrol recommends no packages.

tango-accesscontrol suggests no packages.

-- no debconf information

Bug#949548: RM: rust-crossbeam-epoch-0.5 -- ROM; no longer in use

[Paul Gevers]

Control: reassign -1 ftp.debian.org

Hi kpcyrd,

On 21-01-2020 21:40, kpcyrd wrote:
> The rust-crossbeam-epoch-0.5 package is no longer in use. There are no
> reverse dependencies.
> 
> Thank you very much!

This package isn't in testing, so the request doesn't make sense for the
release team. I assume you want the package to be removed from unstable,
hence I reassign the package to ftp masters (ftp.debian.org pseudo
package) as they are in charge there.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#944982: open-infrastructure-compute-tools: Script accesses internal dpkg database

[Guillem Jover]

Hi!

On Tue, 2020-01-21 at 21:24:11 +0100, Daniel Baumann wrote:
> thank you for reporting this bug. However, it's a false-positive: while
> the debconf scripts uses debconf (with its own instance of a debconf
> db), it doesn't touch the systems debconf db. I'll therefore close the bug.

Not sure whether the above is a typo or a misunderstanding. The
problem is with the dpkg db accesses. The script does:

  if [ -e "${DIRECTORY}/var/lib/dpkg/info/locales.list" ] && \

and

  if [ -e "${DIRECTORY}/var/lib/dpkg/info/openssh-server.postinst" ] && \

which do access the dpkg db. The db layout will change and at least
one of these will disappear inminently, the other might disappear in
the future, so that code will break. If this is fine, then the code
might not be needed anymore, which would be nice to cleanup. Otherwise
I'd appreciate if you could replace it to use one of the public
interfaces. (I think in both cases the bug would be better kept
open? :)

Thanks,
Guillem

Bug#949548: RM: rust-crossbeam-epoch-0.5 -- ROM; no longer in use

[kpcyrd]

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

The rust-crossbeam-epoch-0.5 package is no longer in use. There are no
reverse dependencies.

Thank you very much!

Bug#949545: cacti: cli/add_device.php reports success but device-id is 0 and never appears in the host list

[Paul Gevers]

Control: tags -1 moreinfo

Hi Jim,

Thanks for reporting issues you encounter.

On 21-01-2020 21:15, Jim McNamara wrote:
>* What led up to the situation?
>   Upgraded machine from Stretch to Buster, cacti was upgraded in process 
> from 0.8.8 to 1.2.2.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>   Any host added through the use of /usr/share/cacti/cli/add_device.php 
> reports success, but the device-id is always 0 and the host never appears 
> either in the web interface or via /usr/share/cacti/cli/add_tree.php 
> --list-hosts
> 
>* What was the outcome of this action?
>   ++ /usr/share/cacti/cli/add_device.php --template=1 
> --description=192.168.112.200 --ip=192.168.112.200 --community=public
>   + ADDHOST='Adding 192.168.112.200 (192.168.112.200) as "Generic 
> SNMP-enabled Host" using SNMP vnet-snmp with community "public"
>   Success - new device-id: (0)'
> 
>   The host is not added, and 0 seems like an odd device-id as they seem 
> to start from 1
> 
>* What outcome did you expect instead?
>   
>   Host would be added with the next available device-id, that new 
> device-id should be reported by the add-device.php script

I found this upstream report: https://github.com/Cacti/cacti/issues/3111
Can you check your cacti.log for errors and see if the issue matches?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#949377: dh_python --buildsystem=cmake doesn't pass recently added Python_EXECUTABLE variable

[Piotr Ożarowski]

Hi Lisandro,

> I'm writing this because at first I understood that dh-python should *set* 
> this
> variable, but that's FindPython's job.

I'm afraid that's the case here. We need to invoke cmake twice: once
for Python 3.7 and once for 3.8 (to build extensions for both of them)

Bug#949547: find a nicer way than `tail -c +0 -f` to autoscroll build logs

[Mattia Rizzolo]

Package: jenkins.debian.org

/cgi-bin/nph-logwatch basically just runs `tail -c +0 -f` to pass a log
in real time to apache.
That keeps an apache worker busy as long as the user has it connected,
and has tail take a while CPU for it for the whole duration of the
thing.

I.e., it's highly inefficient and causes us to be subject to DoS if
anybody wanted it.
For example, right now there are 6 such proceses running.  It really
means 6 busy vCPUs that can't do anything else.

We should find a better way to do it…

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#949546: python-cascacore build-depends on removed libcasa-python3-3

[Steve Langasek]

Source: python-casacore
Version: 3.2.0-1
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal

Dear maintainers,

python-casacore build-depends on libcasa-python3-3, but the 3.2.1 version of
casacore currently in testing and unstable ships libcasa-python3-4 instead.

Installing the build-dependencies of python-casacore also already pulls in
libcasa-python3-4 as a dependency of casacore-dev, so I suspect this
hard-coded build-dependency should just be dropped.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#949545: cacti: cli/add_device.php reports success but device-id is 0 and never appears in the host list

[Jim McNamara]

Package: cacti
Version: 1.2.2+ds1-2+deb10u2
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
Upgraded machine from Stretch to Buster, cacti was upgraded in process 
from 0.8.8 to 1.2.2.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Any host added through the use of /usr/share/cacti/cli/add_device.php 
reports success, but the device-id is always 0 and the host never appears 
either in the web interface or via /usr/share/cacti/cli/add_tree.php 
--list-hosts

   * What was the outcome of this action?
++ /usr/share/cacti/cli/add_device.php --template=1 
--description=192.168.112.200 --ip=192.168.112.200 --community=public
+ ADDHOST='Adding 192.168.112.200 (192.168.112.200) as "Generic 
SNMP-enabled Host" using SNMP vnet-snmp with community "public"
Success - new device-id: (0)'

The host is not added, and 0 seems like an odd device-id as they seem 
to start from 1

   * What outcome did you expect instead?

Host would be added with the next available device-id, that new 
device-id should be reported by the add-device.php script


*** End of the template - remove these template lines ***


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

Kernel: Linux 4.19.0-6-amd64 (SMP w/16 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 cacti depends on:
ii  dbconfig-common   2.0.11+deb10u1
ii  dbconfig-mysql2.0.11+deb10u1
ii  debconf [debconf-2.0] 1.5.71
ii  fonts-dejavu-core 2.37-1
ii  fonts-dejavu-extra2.37-1
ii  fonts-fork-awesome1.1.5+ds1-2
ii  javascript-common 11
ii  libapache2-mod-php2:7.3+69
ii  libapache2-mod-php7.0 [libapache2-mod-ph  7.0.33-0+deb9u5
ii  libapache2-mod-php7.3 [libapache2-mod-ph  7.3.11-1~deb10u1
ii  libjs-c3  0.4.11+dfsg-2
ii  libjs-chart.js2.7.3+dfsg-5
ii  libjs-d3  3.5.17-2
ii  libjs-jquery  3.3.1~dfsg-3
ii  libjs-jquery-colorpicker  1.2.17-1
ii  libjs-jquery-cookie   12-1.1
ii  libjs-jquery-hotkeys  0~20130707+git2d51e3a9+dfsg-2
ii  libjs-jquery-jstree   3.3.7+dfsg1-1
ii  libjs-jquery-metadata 12-1.1
ii  libjs-jquery-tablesorter  1:2.31.1+dfsg1-1
ii  libjs-jquery-timepicker   1.2-1
ii  libjs-jquery-ui   1.12.1+dfsg-5
ii  libjs-jquery-ui-theme-smoothness  1.12.1+dfsg-1
ii  libjs-jquery-ui-theme-south-street1.12.1+dfsg-1
ii  libjs-jquery-ui-theme-ui-darkness 1.12.1+dfsg-1
ii  libjs-jquery-ui-touch-punch   0.0~git20141218.2.4bc0091+dfsg1-2
ii  libphp-phpmailer  6.0.6-0.1
ii  perl  5.28.1-6
ii  php-gd2:7.3+69
ii  php-gmp   2:7.3+69
ii  php-ldap  2:7.3+69
ii  php-mbstring  2:7.3+69
ii  php-mysql 2:7.3+69
ii  php-php-gettext   1.0.12-0.1
ii  php-phpseclib 2.0.14-1
ii  php-snmp  2:7.3+69
ii  php-twig  2.6.2-2
ii  php-xml   2:7.3+69
ii  php7.0-cli [php-cli]  7.0.33-0+deb9u5
ii  php7.0-json [php-json]7.0.33-0+deb9u5
ii  php7.0-mbstring [php-mbstring]7.0.33-0+deb9u5
ii  php7.0-snmp [php-snmp]7.0.33-0+deb9u5
ii  php7.0-xml [php-xml]  7.0.33-0+deb9u5
ii  php7.3-cli [php-cli]  7.3.11-1~deb10u1
ii  php7.3-gd [php-gd]7.3.11-1~deb10u1
ii  php7.3-gmp [php-gmp]  7.3.11-1~deb10u1
ii  php7.3-json [php-json]7.3.11-1~deb10u1
ii  php7.3-ldap [php-ldap]7.3.11-1~deb10u1
ii  php7.3-mbstring [php-mbstring]7.3.11-1~deb10u1
ii  php7.3-snmp [php-snmp]7.3.11-1~deb10u1
ii  php7.3-xml [php-xml]  7.3.11-1~deb10u1
ii  rrdtool   1.7.1-2
ii  snmp  5.7.3+dfsg-5
ii  ucf   3.0038+nmu1

Versions of packages cacti recommends:
ii  apache2 [httpd] 

Bug#949377: dh_python --buildsystem=cmake doesn't pass recently added Python_EXECUTABLE variable

[Lisandro Damián Nicanor Pérez Meyer]

Hi! tl;dr: I was wrong.

On Tue, 21 Jan 2020 at 17:31, Lisandro Damián Nicanor Pérez Meyer
 wrote:
>
> Hi!
[snip]
> > -- Found Python3: /usr/bin/python3.8 (found suitable version "3.8.1", 
> > minimum required is "3.4") found components:  Interpreter Development
> >
> > It looks like dh-python should include Python_EXECUTABLE:
> >
> > https://gitlab.kitware.com/cmake/cmake/commit/06d9e67fbd2b2dfc9cba12327866b2f73eab8a18
>
> I might be wrong, but: if by the above you mean that dh-python should get the
> value returned into Python_EXECUTABLE and pass it over: yes, it's possible.
>
> I'm writing this because at first I understood that dh-python should *set* 
> this
> variable, but that's FindPython's job.
>
> Except I am missing something.

And I am. It's actually the other way around. Sorry for the noise!


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#944982: open-infrastructure-compute-tools: Script accesses internal dpkg database

[Daniel Baumann]

close 944982
thanks

Hi Guillem,

thank you for reporting this bug. However, it's a false-positive: while
the debconf scripts uses debconf (with its own instance of a debconf
db), it doesn't touch the systems debconf db. I'll therefore close the bug.

Regards,
Daniel

Bug#940144: developers-reference: document self-service givebacks in wanna-build section

[Mattia Rizzolo]

On Tue, Jan 21, 2020 at 09:20:54PM +0100, Philipp Kern wrote:
> That being said, tracker, nm and contributors already moved to request
> client certificates on the main host.

In their case it didn't really change anything, since they had the
client certificate bit in their  section.

> And yes, the correct approach would be something like OAuth2. Or use
> client certificates with some sort of CLI. :/

Then get the sso.d.o team to do that, in a sane way.  We are still
waiting for an interface to register guest accounts, that has been ready
for more than a year now but apparently has trouble being deployed.



-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#949377: dh_python --buildsystem=cmake doesn't pass recently added Python_EXECUTABLE variable

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On 20/01/20 12:58, Christoph Berg wrote:
> Package: dh-python
> Version: 4.20191017
> Severity: normal
> 
> libarcus and libsavitar from the 3dprinting team have the problem
> that the cmake jobs called from dh_auto_install use the wrong python
> version, note that 3.8 is used in the 3.7 install pass:
> 
> https://salsa.debian.org/3dprinting-team/libsavitar/-/jobs/515849#L935
> 
> olasd tracked the problem down to find_package(Python3) not working:
> 
> I: pybuild base:217: dh_auto_configure --buildsystem=cmake 
> --builddirectory="/builds/3dprinting-team/libsavitar/debian/output/libsavitar-4.4.1/.pybuild/cpython3_3.7/build"
>  -- -DPYTHON_EXECUTABLE:FILEPATH=/usr/bin/python3.7 
> -DPYTHON_LIBRARY:FILEPATH=/usr/lib/python3.7/config-3.7m-x86_64-linux-gnu/libpython3.7m.so
>  -DPYTHON_INCLUDE_DIR:PATH=/usr/include/python3.7m
> ...
> -- Found Python3: /usr/bin/python3.8 (found suitable version "3.8.1", minimum 
> required is "3.4") found components:  Interpreter Development
> 
> It looks like dh-python should include Python_EXECUTABLE:
> 
> https://gitlab.kitware.com/cmake/cmake/commit/06d9e67fbd2b2dfc9cba12327866b2f73eab8a18

I might be wrong, but: if by the above you mean that dh-python should get the
value returned into Python_EXECUTABLE and pass it over: yes, it's possible.

I'm writing this because at first I understood that dh-python should *set* this
variable, but that's FindPython's job.

Except I am missing something.

Cheers, Lisandro.

Bug#949544: src:deal.ii: FTBFS with tbb 2020.0-2

[Gilles Filippini]

Package: src:deal.ii
Version: 9.1.1-8
Severity: serious
Justification: FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

deal.II FTBFS when built against tbb 2020.0-2:
- -- Found TBB_LIBRARY
- -- TBB_DEBUG_LIBRARY not found! Call:
- -- FIND_LIBRARY(TBB_DEBUG_LIBRARY NAMES tbb_debug HINTS PATH_SUFFIXES lib 
lib64 lib)
- -- Found TBB_INCLUDE_DIR
- --   TBB_VERSION: 0.0
- --   TBB_LIBRARIES: /usr/lib/x86_64-linux-gnu/libtbb.so
- --   TBB_INCLUDE_DIRS: /usr/include
- --   TBB_USER_INCLUDE_DIRS: /usr/include
- -- Found TBB
- -- The externally provided TBB library is older than version 4.2.0, which 
cannot be used with deal.II.
- -- DEAL_II_WITH_THREADS has unmet external dependencies.
CMake Error at cmake/macros/macro_configure_feature.cmake:112 (MESSAGE):
  

  Could not find the threads library!

  The externally provided TBB library is older than version

  4.2.0, which is the oldest version compatible with deal.II and its

  supported compilers.Please ensure that a suitable threads library is
  installed on your computer.

  If the library is not at a default location, either provide some hints for
  autodetection, or set the relevant variables by hand in ccmake.

Thanks,

_g.

- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAl4nXocACgkQ7+hsbH/+
z4MlNQf+IQYXIr0lT+XBnaRT8nBTeVRggaU6v+Eo6h/3LkG2ykrkDvG4BFUxMHWj
lMIrpBKXo98cUVCXjb+7woIt0xtnMLhQqk+zpKQVrGOafSrJJ0ebaRDr2+lXRVtQ
OPQ6zXPyItDwA4gbpdG+tVJWGbpo6jgCVdFYKy6NPO6Nh1HCVmOJ1Rqx+K99F5pV
la7Kr9Oz6QzSwBav1lO41fFLrZoTNJ7eFRizaL9YvXvfIE2jiU2PSNEQuOHoUTXQ
ocuRqP2cIxKOb96o8/vYooqAFrePigtpgl07JtP0dESAhXpYeHrrBLdglwus23wn
W+J8EM/O2v1yUF0rZqFC1cRIxLZpTw==
=ljqV
-END PGP SIGNATURE-

Bug#940144: developers-reference: document self-service givebacks in wanna-build section

[Philipp Kern]

On 1/21/2020 4:50 PM, Sam Hartman wrote:
>> "Philipp" == Philipp Kern  writes:
> 
> Philipp> I'm told it was broken by the upgrade of Apache - apparently it 
> can no
> Philipp> longer do per path client certificate authentication. There is a
> Philipp> pending RT ticket from DSA to fix that but I don't think there is
> Philipp> anything I can do at the moment - except turn on SSO for the 
> whole
> Philipp> vhost. Maybe that could even be a workaround for now and we could
> Philipp> check if someone is annoyed by that. :)
> 
> TLS dropped the facilities necessary to do that.
> Ultimately you'll need a vhost for stuff that requires client certs and
> other vhosts that do not.
> The user experience of having a site request client certs when you don't
> have one to give is really bad in some browsers.
> 
> Client certs really kind of are the unloved step child of web
> authentication.

Yeah, so Julien helpfully just created auth.buildd.debian.org (thanks
for that!). I'm going to spend some time on that tomorrow.

That being said, tracker, nm and contributors already moved to request
client certificates on the main host. I find the UI problematic when you
actually have a cert, as it will show a problem. In enterprise
environments you can push a policy to not ask about which certificate to
use but for privacy reasons it is still explicit in the normal case.

And yes, the correct approach would be something like OAuth2. Or use
client certificates with some sort of CLI. :/

Kind regards
Philipp Kern

Bug#935881: Additional information on pgadmin3 usability

[bug . reporter]

Dear Maintainer, 

re: pgadmin3

I am running Debian Testing and 
postgresql ver 12.1 on an amd machine

I forward this as an update to bug  #935881
because there is no real fix for this bug. 

The pgadmin site says that pgadmin3 is no longer 
supported. It would appear that migration to 
pgAdmin4 is their preferred solution. 

The situation is now somewhat critial for 
Debian|Testing because of the current upgrade 
of postgresql to version 12.1

This causes an error message : 
column ad.adsrc does not exist

Much of the functionality of pgadmin3 is lost. 
It is no longer possible to access tables in 
pgadmin3 because of this bug. 

Presently two solutions are available, to either
build the package (pgadmin4) from source code, 
or revert to version 11 pf postgresql. 

May I suggest that this bug be elevated to 
grave. 

HTH
Richard A Lough

apt list --installed | grep postgresql

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

libreoffice-sdbc-postgresql/testing,now 1:6.3.4-2 amd64 [installed,automatic]
postgresql-11/testing,now 11.6-2~sid1 amd64 [installed]
postgresql-12/testing,now 12.1-2 amd64 [installed,automatic]
postgresql-client-11/testing,now 11.6-2~sid1 amd64 [installed]
postgresql-client-12/testing,now 12.1-2 amd64 [installed,automatic]
postgresql-client-common/testing,now 210 all [installed,automatic]
postgresql-common/testing,now 210 all [installed,automatic]
postgresql/testing,now 12+210 all [installed]

Bug#949543: src:blasr: FTBFS with pbseqlib 5.3.3+dfsg-1

[Gilles Filippini]

Package: src:blasr
Version: 5.3.3+dfsg-3
Severity: serious
Justification: FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Blasr 5.3.3+dfsg-3 FTBFS when built against pbseqlib 5.3.3+dfsg-1:

 meson.build:64:0: ERROR: C++ library 'pbdata' not found


It seems related to this changelog entry from pbseqlib:
>  * Remove binary packages libpbdata and libpbihdf since these are
>header only libraries now

Thanks,

_g.

- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAl4nWbAACgkQ7+hsbH/+
z4PbbAf7BGMs1D2tr7QRAMot8aIsMNO1lEwuYU75y/mHbt+TuwzvQL+1SbDkFM8B
R/pyC3kycX9wOl2vRDcc9b1+n7M5z3uWe52IO0H2y3ZKiZFfFRxNAZbSm3JhDVd0
hh1dp01ehAPb0YLpYiQapSUF8N9BPhcZXZJfIDXOCKgCa/TAUeFuXuzBM7dNOwYi
3Qn3leIjtsO2gFWH1dcVfFhFFgzRswN2qi9rH3zZ4AMgWyfYYwrNGGNYA2vJTUSD
S/0iJqGzWbi8evrHajA5g/9oC+tNY3/08e5kU/UMKi+PMosawB3vA91hynxqdYVb
mdbYtoNSiS3F0DX2nQ+s35yoSJANdg==
=CcMs
-END PGP SIGNATURE-

Bug#949542: src:pbdagcon: FTBFS with pbseqlib 5.3.3+dfsg-1

[Gilles Filippini]

Package: src:pbdagcon
Version: 0.3+git20161121.000+ds-1.1
Severity: serious
Justification: FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Pbdagcon FTBFS when built against pbseqlib 5.3.3+dfsg-1:
g++ -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -O3 -std=c++11 -Wall -Wuninitialized -pedantic 
-Wdate-time -D_FORTIFY_SOURCE=2 -MMD -MP -I/<>/DAZZ_DB 
-I/<>/DALIGNER -I/usr/include/pbseq/alignment 
-I/usr/include/pbseq/pbdata -I/usr/include/pbseq/hdf -I/usr/include/pbseq 
-isystem.//third-party  -c -o main.o main.cpp
In file included from SimpleAligner.hpp:5,
 from main.cpp:24:
/usr/include/pbseq/pbdata/DNASequence.hpp:4:10: fatal error: LibBlasrConfig.h: 
No such file or directory
4 | #include 
  |  ^~
compilation terminated.

The missing header LibBlasrConfig.h used to be part of libpbdata-dev.

Thanks,

_g.

- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAl4nW00ACgkQ7+hsbH/+
z4OfGQf+PL2qtI618amy3p+f7voJyYMt8nK9zEDtG6XyDfTmalC3xh7tlL8jnPZ+
qNOJea0QwpDiP1Vsec20HsJ5xMBmtLDwY+w+RDQhh3jd2ODlHfVoFCElDWKWPWs2
7mUGPfTPxOMwLvgxI+XyPvLqxYfw0HH6mDNQxcp8zzeNYFkqulUsgBYKIGjghmAr
m570ZnFMK8LrPUGaSjLKTCDs/n367NFiwqfWtXC0HMlt/pfYWGoqBh2zmqS2lD15
xX1ecd0eyRt6OoPlqk2eHubE9prc+f9cG3leHxl0+WvIVuZt92qUdT9sFK9FTDw5
XgjOSe4Sm5gYVn+EDTS7XOHyj5Cgng==
=ZCPV
-END PGP SIGNATURE-

Bug#949541: buster-pu: package mesa/18.3.6-2+deb10u1

[Moritz Muehlenhoff]

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

Attached debdiff fixes a minor security issue in mesa. I've been running
the updated packaged on a Buster workstation over the last days.

Cheers,
Moritz

diff -u mesa-18.3.6/debian/changelog mesa-18.3.6/debian/changelog
--- mesa-18.3.6/debian/changelog
+++ mesa-18.3.6/debian/changelog
@@ -1,3 +1,10 @@
+mesa (18.3.6-2+deb10u1) buster; urgency=medium
+
+  * Call shmget() with permission 0600 instead of 0777 (CVE-2019-5068)
+(Closes: #944298)
+
+ -- Moritz Mühlenhoff   Wed, 15 Jan 2020 20:28:42 +0100
+
 mesa (18.3.6-2) unstable; urgency=medium
 
   * Cherry-pick c77acc3ceba (meson: remove meson-created megadrivers
diff -u mesa-18.3.6/debian/patches/series mesa-18.3.6/debian/patches/series
--- mesa-18.3.6/debian/patches/series
+++ mesa-18.3.6/debian/patches/series
@@ -5,0 +6 @@
+CVE-2019-5068.patch
only in patch2:
unchanged:
--- mesa-18.3.6.orig/debian/patches/CVE-2019-5068.patch
+++ mesa-18.3.6/debian/patches/CVE-2019-5068.patch
@@ -0,0 +1,68 @@
+From 02c3dad0f3b4d26e0faa5cc51d06bc50d693dcdc Mon Sep 17 00:00:00 2001
+From: Brian Paul 
+Date: Wed, 9 Oct 2019 12:05:16 -0600
+Subject: Call shmget() with permission 0600 instead of 0777
+
+A security advisory (TALOS-2019-0857/CVE-2019-5068) found that
+creating shared memory regions with permission mode 0777 could allow
+any user to access that memory.  Several Mesa drivers use shared-
+memory XImages to implement back buffers for improved performance.
+
+This path changes the shmget() calls to use 0600 (user r/w).
+
+Tested with legacy Xlib driver and llvmpipe.
+
+Cc: mesa-sta...@lists.freedesktop.org
+Reviewed-by: Kristian H. Kristensen 
+---
+ src/gallium/winsys/sw/dri/dri_sw_winsys.c   | 3 ++-
+ src/gallium/winsys/sw/xlib/xlib_sw_winsys.c | 3 ++-
+ src/mesa/drivers/x11/xm_buffer.c| 3 ++-
+ 3 files changed, 6 insertions(+), 3 deletions(-)
+
+diff --git a/src/gallium/winsys/sw/dri/dri_sw_winsys.c 
b/src/gallium/winsys/sw/dri/dri_sw_winsys.c
+index cbccf4d01df..6173147a1ff 100644
+--- a/src/gallium/winsys/sw/dri/dri_sw_winsys.c
 b/src/gallium/winsys/sw/dri/dri_sw_winsys.c
+@@ -92,7 +92,8 @@ alloc_shm(struct dri_sw_displaytarget *dri_sw_dt, unsigned 
size)
+ {
+char *addr;
+ 
+-   dri_sw_dt->shmid = shmget(IPC_PRIVATE, size, IPC_CREAT|0777);
++   /* 0600 = user read+write */
++   dri_sw_dt->shmid = shmget(IPC_PRIVATE, size, IPC_CREAT | 0600);
+if (dri_sw_dt->shmid < 0)
+   return NULL;
+ 
+diff --git a/src/gallium/winsys/sw/xlib/xlib_sw_winsys.c 
b/src/gallium/winsys/sw/xlib/xlib_sw_winsys.c
+index be28fae3df2..8e97f0a24af 100644
+--- a/src/gallium/winsys/sw/xlib/xlib_sw_winsys.c
 b/src/gallium/winsys/sw/xlib/xlib_sw_winsys.c
+@@ -126,7 +126,8 @@ alloc_shm(struct xlib_displaytarget *buf, unsigned size)
+shminfo->shmid = -1;
+shminfo->shmaddr = (char *) -1;
+ 
+-   shminfo->shmid = shmget(IPC_PRIVATE, size, IPC_CREAT|0777);
++   /* 0600 = user read+write */
++   shminfo->shmid = shmget(IPC_PRIVATE, size, IPC_CREAT | 0600);
+if (shminfo->shmid < 0) {
+   return NULL;
+}
+diff --git a/src/mesa/drivers/x11/xm_buffer.c 
b/src/mesa/drivers/x11/xm_buffer.c
+index d945d8af556..0da08a6e64d 100644
+--- a/src/mesa/drivers/x11/xm_buffer.c
 b/src/mesa/drivers/x11/xm_buffer.c
+@@ -89,8 +89,9 @@ alloc_back_shm_ximage(XMesaBuffer b, GLuint width, GLuint 
height)
+   return GL_FALSE;
+}
+ 
++   /* 0600 = user read+write */
+b->shminfo.shmid = shmget(IPC_PRIVATE, b->backxrb->ximage->bytes_per_line
+-   * b->backxrb->ximage->height, IPC_CREAT|0777);
++ * b->backxrb->ximage->height, IPC_CREAT | 0600);
+if (b->shminfo.shmid < 0) {
+   _mesa_warning(NULL, "shmget failed while allocating back buffer.\n");
+   XDestroyImage(b->backxrb->ximage);
+-- 
+cgit v1.2.1
+


Cheers,
Moritz

Bug#949540: libtango-tools: Move tango_admin into a directory in $PATH

[Thomas Braun]

Package: libtango-tools
Version: 9.3.4~rc2+dfsg2-1~exp3
Severity: normal

Dear Maintainer,

please move tango_admin into a directory which is in $PATH so that the
user can call it without having to figure out where it is.

Thanks,
Thomas

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

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

Versions of packages libtango-tools depends on:
ii  libc6 2.24-11+deb9u4
ii  libcos4-1 4.1.6-2.1+b1
ii  libgcc1   1:6.3.0-18+deb9u1
pn  liblog4tango5v5   
ii  libomniorb4-1 4.1.6-2.1+b1
ii  libomnithread3c2  4.1.6-2.1+b1
ii  libstdc++66.3.0-18+deb9u1
pn  libtango9 
ii  libzmq5   4.2.1-4+deb9u2

libtango-tools recommends no packages.

libtango-tools suggests no packages.

Bug#949538: debhelper: Possibly guard the file program invocation by inserting "--"

[Niels Thykier]

Christoph Biedl:
> Package: debhelper
> Version: 12.8
> Severity: wishlist
> 
> Heya,
> 
> some debhelper programs call the file program, and I noticed the
> invocation does not guard against file names that file(1) could
> misinterpret as a command line option. In other words, file names
> starting with a dash will create undesired results.
> 
> You might argue Debian should not ship such strange file names, and I
> concur. But this already happens a few times, openfoam-examples for
> example. It seems these files are just not tested by any of the
> debhelper programs. Perhaps just not yet.
> 
> So as a safeguard I suggest to place "--" as usual between the options
> and the argument. Before ugly things happen.
> 
> This affects at least /usr/bin/dh_shlibdeps and /usr/bin/dh_strip.
> 
> Cheers,
> 
> Christoph
> 
> [...]
> 

Thanks for the suggestion.

At the moment, there is no problem at all as debhelper passes the full
path to file at the relevant call sites.  That said, it is a fine
"defense-in-depth" strategy for avoiding "funny breakage" in the future.

Thanks,
~Niels

Bug#949539: linux-image-4.19.0-6-cloud-amd64: virtio-rng.ko moduel is not present

[Ben Hutchings]

Control: forcemerge 914511 -1

On Tue, 2020-01-21 at 19:28 +, David Magda wrote:
> Package: src:linux
> Version: 4.19.67-2+deb10u2
> Severity: normal
> 
> Dear Maintainer,
> 
> The virtio-rng.ko is not present cloud image kernel package:
[...]
> If it is preset in the non-cloud package, and the backported cloud package,
> shouldn't it also be present in the 'default' cloud package as well?
[...]

That doesn't necessarily follow: backported kernel packages have the
same configuration as the next release, with minimal changes to avoid
incompatibility.

However, this probably should be enabled.

Ben.

-- 
Ben Hutchings
If God had intended Man to program,
we'd have been born with serial I/O ports.



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

Bug#948550: buster-pu: package e2fsprogs/1.44.5-1+deb10u2

[Adam D. Barratt]

Control: tags -1 + confirmed d-i

On Thu, 2020-01-09 at 22:34 -0500, Theodore Y. Ts'o wrote:
> +e2fsprogs (1.44.5-1+deb10u3) buster; urgency=medium
> +
> +  * Fix CVE-2019-5188: potential stack underflow in e2fsck (Closes:
> #948508)
> +  * Fix use after free in e2fsck (Closes: #948517)
> 

This looks OK to me, but will also need a d-i ACK as e2fsprogs produces
a udeb; CCing and tagging to reflect that.

Regards,

Adam

Bug#949539: linux-image-4.19.0-6-cloud-amd64: virtio-rng.ko moduel is not present

[David Magda]

Package: src:linux
Version: 4.19.67-2+deb10u2
Severity: normal

Dear Maintainer,

The virtio-rng.ko is not present cloud image kernel package:

debian@dm-test1:~$ locate virtio
/usr/lib/modules/4.19.0-6-cloud-amd64/kernel/drivers/virtio
/usr/lib/modules/4.19.0-6-cloud-amd64/kernel/drivers/block/virtio_blk.ko
/usr/lib/modules/4.19.0-6-cloud-amd64/kernel/drivers/char/virtio_console.ko
/usr/lib/modules/4.19.0-6-cloud-amd64/kernel/drivers/net/virtio_net.ko
/usr/lib/modules/4.19.0-6-cloud-amd64/kernel/drivers/scsi/virtio_scsi.ko
/usr/lib/modules/4.19.0-6-cloud-amd64/kernel/drivers/virtio/virtio.ko
/usr/lib/modules/4.19.0-6-cloud-amd64/kernel/drivers/virtio/virtio_balloon.ko
/usr/lib/modules/4.19.0-6-cloud-amd64/kernel/drivers/virtio/virtio_input.ko
/usr/lib/modules/4.19.0-6-cloud-amd64/kernel/drivers/virtio/virtio_mmio.ko
/usr/lib/modules/4.19.0-6-cloud-amd64/kernel/drivers/virtio/virtio_pci.ko
/usr/lib/modules/4.19.0-6-cloud-amd64/kernel/drivers/virtio/virtio_ring.ko
/usr/lib/modules/4.19.0-6-cloud-amd64/kernel/net/vmw_vsock/vmw_vsock_virtio_transport.ko
/usr/lib/modules/4.19.0-6-cloud-amd64/kernel/net/vmw_vsock/vmw_vsock_virtio_transport_common.ko

This can further be confirmed via the package file list

https://packages.debian.org/buster/amd64/linux-image-4.19.0-6-cloud-amd64/filelist

However, the module is present in the non-cloud package:

https://packages.debian.org/buster/amd64/linux-image-4.19.0-6-amd64/filelist

It is also present in the cloud package of the buster-packports package:

https://packages.debian.org/buster-backports/amd64/linux-image-5.4.0-0.bpo.2-cloud-amd64/filelist


If it is preset in the non-cloud package, and the backported cloud package,
shouldn't it also be present in the 'default' cloud package as well?


-- Package-specific info:
** Version:
Linux version 4.19.0-6-cloud-amd64 (debian-ker...@lists.debian.org) (gcc 
version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-6-cloud-amd64 
root=UUID=d187d85e-8a80-4664-8b5a-dce4d7ceca9e ro biosdevname=0 net.ifnames=0 
console=tty0 console=ttyS0,115200 earlyprintk=ttyS0,115200 consoleblank=0 
systemd.show_status=true

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: OpenStack Foundation
product_name: OpenStack Nova
product_version: 18.2.1
chassis_vendor: QEMU
chassis_version: pc-i440fx-bionic
bios_vendor: SeaBIOS
bios_version: 1.10.2-1ubuntu1

** Loaded modules:
kvm_intel
kvm
irqbypass
crct10dif_pclmul
crc32_pclmul
ghash_clmulni_intel
evdev
virtio_console
virtio_balloon
serio_raw
qemu_fw_cfg
button
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
fscrypto
ecb
ata_generic
virtio_net
net_failover
virtio_blk
failover
crc32c_intel
ata_piix
libata
aesni_intel
scsi_mod
aes_x86_64
crypto_simd
cryptd
glue_helper
virtio_pci
virtio_ring
virtio

** PCI devices:
not available

** USB devices:
not available


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

Kernel: Linux 4.19.0-6-cloud-amd64 (SMP w/2 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-4.19.0-6-cloud-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.133+deb10u1
ii  kmod26-1
ii  linux-base  4.6

Versions of packages linux-image-4.19.0-6-cloud-amd64 recommends:
ii  apparmor 2.13.2-10
ii  firmware-linux-free  3.4

Versions of packages linux-image-4.19.0-6-cloud-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.02+dfsg1-20
pn  linux-doc-4.19  

Versions of packages linux-image-4.19.0-6-cloud-amd64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#949538: debhelper: Possibly guard the file program invocation by inserting "--"

[Christoph Biedl]

Package: debhelper
Version: 12.8
Severity: wishlist

Heya,

some debhelper programs call the file program, and I noticed the
invocation does not guard against file names that file(1) could
misinterpret as a command line option. In other words, file names
starting with a dash will create undesired results.

You might argue Debian should not ship such strange file names, and I
concur. But this already happens a few times, openfoam-examples for
example. It seems these files are just not tested by any of the
debhelper programs. Perhaps just not yet.

So as a safeguard I suggest to place "--" as usual between the options
and the argument. Before ugly things happen.

This affects at least /usr/bin/dh_shlibdeps and /usr/bin/dh_strip.

Cheers,

Christoph

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

Kernel: Linux 5.4.13 (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: unable to detect

Versions of packages debhelper depends on:
ii  autotools-dev20180224.1
ii  dh-autoreconf19
ii  dh-strip-nondeterminism  1.6.3-2
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  dwz  0.13-5
ii  file 1:5.38-4
ii  libdebhelper-perl12.8
ii  libdpkg-perl 1.19.7
ii  man-db   2.9.0-2
ii  perl 5.30.0-9
ii  po-debconf   1.0.21

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.201903

-- no debconf information



signature.asc
Description: PGP signature

Bug#948546:

[Mario.Limonciello]

If you adopt this release, please also backport this commit:
https://github.com/hughsie/libgusb/commit/17f9cda073459fc673a99bd281e929a999643374

To avoid causing significantly higher power consumption in software that uses 
libgusb.

Bug#949289: Workaround: No wifi and no sound after suspend

[Wolf-Dieter Groll]

Installing a network restart service as suggested on

https://askubuntu.com/questions/761180/wifi-doesnt-work-after-suspend-after-16-04-upgrade

has fixed the problem.

Even so this only restarts the network-manager.service, the other
problems are solved as well: Sound ok, shutdown is working.


-- 

 Wolf-Dieter



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#861115: Please consider increasing net.ipv6.route.max_size default value

[Vincent Bernat]

 ❦ 21 janvier 2020 18:58 +00, Tim Bray :

> I also agree.
>
> I've just spent a month tracking down an issue where IPv6 networking
> connections hang.  Using Debian buster, 4.19.0-6-amd64.
>
> Machine carries a full IPv6 table, received via BGP. About 80k routes.
>
> Symptoms were BFD dropping out.  Connectivity hangs.
>
> setting net.ipv6.route.max_size to 2147483647 fixed all issues.   
> (aware this might be too big)
>
> Later kernels  (5.4.11) cause a dmesg when full.

This setting is for the size of the route cache. You can have far more
routes. In the past, there were bugs where each lookup will be put in
cache, but since 4.2, only the PMTU exceptions are stored in cache. See


Do you have a lot of entries in `ip -6 route show cache`?
-- 
Avoid multiple exits from loops.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#949537: elpa-elfeed-web: depends on CSS and JavaScript not in Debian

[Benjamin Barenblat]

Package: elpa-elfeed-web
Version: 3.1.0-1
Severity: serious
Control: block -1 by 902083
Control: found -1 3.3.0-1

elfeed-web uses Foundation [1], AngularJS [2], and URI.js [3], loading
them from various CDN sites in index.html:





AngularJS is included in main, but Foundation and URI.js are not. This
is probably a violation of Policy 2.2.1, which states that “None of the
packages in the main archive area requires software outside of that
area to function.”

Ideally, Debian’s elfeed-web should Depend on packages containing
Foundation, AngularJS, and URI.js, and it should be patched to load
those resources from the same origin as index.html. There’s already an
ITP for URI.js, which I’ve marked as a blocker for this bug.

[1] https://foundation.zurb.com/
[2] https://angularjs.org/
[3] https://medialize.github.io/URI.js/

Bug#949536: New upstream version 2.44 - please package

[Marc Meledandri]

Package: keepass2
Version: 2.43+dfsg-1

Dear Maintainer,

Please package KeePass 2.44. List of fixes and improvements:
https://keepass.info/news/n200120_2.44.html

Thanks!

Bug#949535: RM: rumor -- ROM; blocks guile transition; dead upstream; low popcon

[Ryan Kavanagh]

Package: ftp.debian.org
Severity: normal

Please remove rumor from the archives. It does not build with guile-2.2
and the guile maintainers would like to remove guile-2.0 from the
archives. It has not been updated upstream since 2010. I packaged it for
the archives because frescobaldi used it way back when, but frescobaldi
no longer uses it.

Thanks,
Ryan

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#861115: Please consider increasing net.ipv6.route.max_size default value

[Tim Bray]

I also agree.

I've just spent a month tracking down an issue where IPv6 networking 
connections hang.  Using Debian buster, 4.19.0-6-amd64.


Machine carries a full IPv6 table, received via BGP. About 80k routes.

Symptoms were BFD dropping out.  Connectivity hangs.

setting net.ipv6.route.max_size to 2147483647 fixed all issues.    
(aware this might be too big)


Later kernels  (5.4.11) cause a dmesg when full.

Tim

Bug#949533: gmotionlive FTCBFS: uses the build architecture pkg-config

[Helmut Grohne]

Source: gmotionlive
Version: 1.0-3
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

gmotionlive fails to cross build from source, because the upstream
Makefile hard codes the build architecture pkg-config. After making it
substitutable, gmotionlive cross builds successfully. Please consider
applying the attached patch.

Helmut
--- gmotionlive-1.0.orig/Makefile
+++ gmotionlive-1.0/Makefile
@@ -1,11 +1,12 @@
 CC = gcc
 CFLAGS = -DG_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGDK_PIXBUF_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED
 CFLAGS += -Wall
+PKG_CONFIG ?= pkg-config
 
 all:	gmotionlive
 
 gmotionlive: gmotionlive.c
-	$(CC) gmotionlive.c -o gmotionlive $(CFLAGS) `pkg-config gtk+-2.0 --cflags --libs`
+	$(CC) gmotionlive.c -o gmotionlive $(CFLAGS) `$(PKG_CONFIG) gtk+-2.0 --cflags --libs`
 
 clean:
 	rm -f *.o gmotionlive

Bug#949502: tablix2: FTBFS with libxml2 not shipping xml2-config

[Helmut Grohne]

Control: clone -1 -2
Control: reassign -2 libxml2-dev
Control: tags -2 - ftbfs
Control: retitle -2 stop using xml2-config in AM_PATH_XML2
Control: block -1 by -2

On Tue, Jan 21, 2020 at 03:55:42PM +0100, Mattia Rizzolo wrote:
> your package is using `xml2-config` to detect and use libxml2.  I'm
> removing that script, so please update your build system to use
> pkg-config instead.

tablix2 uses AM_PATH_XML2, which comes from libxml2-dev. So I'm cloning
a bug for libxml2-dev to stop using xml2-config in the AM_PATH_XML2
macro. Once that is fixed, progress should be relatively easy here.

Helmut

Bug#949532: medialibrary: keep out of testing until vlc uses it

[Sebastian Ramacher]

Source: medialibrary
Version: 0.6.0-1
Severity: serious

This has currently no use beside vlc 4.0. Once that's released, I'll
close this bug.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#949531: ITP: qiskit-aer -- Quantum Information Science Kit (Qiskit): Aer

[Diego M. Rodriguez]

Package: wnpp
Severity: wishlist
Owner: "Diego M. Rodriguez" 
User: debian-scie...@lists.debian.org
Usertags: field..science

* Package name: qiskit-aer
  Version : 0.3.4
  Upstream Author : Qiskit Development Team 
* URL : https://github.com/Qiskit/qiskit-aer
* License : Apache-2.0
  Programming Lang: Python, C++
  Description : Quantum Information Science Kit (Qiskit): Aer

 Qiskit (Quantum Information Science Kit) is a collection of software developed
 by IBM Research for working with short depth quantum circuits and building
 near term applications and experiments on quantum computers.
 .
 This package contains Aer, the element that contains high-performance quantum
 computing simulators with realistic noise models.

I intend to package this software under the umbrella of the Debian
Science team. In the same spirit as a recent ITP for
qiskit-ibmq-provider [0], this module was previously included in the
upstream Qiskit terra package, and is now available as a standalone
module (more details about the splitting of the currently packaged
version into smaller packages can be found at #933060 [1], along with
recent updates to the qiskit-terra debian repository [2]).

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949383
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933060
[2] https://salsa.debian.org/science-team/qiskit-terra

-- 
Diego M. Rodriguez



signature.asc
Description: OpenPGP digital signature

Bug#941866: gtrayicon: Intent to remove from Debian

[Boyuan Yang]

X-Debbugs-CC: ripps...@gmail.com

On Sun, 6 Oct 2019 16:29:28 -0400 Jeremy Bicha  wrote:
> Source: gtrayicon
> Version: 1.1-1
> Severity: serious
> 
> As part of a major effort to reduce the amount of GTK2 software in
> Debian, I or someone else will be requesting the removal of gtrayicon
> from Debian.
> 
> It has very low popcorn and hasn't been updated upstream or in Debian
> in more than a decade.
> 
> If you object, please comment here before the package is removed from
> Debian. Or better yet, convert it to gtk3 if you can. See
> https://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html

Dear developer,

since there has been no response since October, I will consider starting the
removal soon. The removal bug will be filed after one week (after Jan. 28,
2020). If you have any objections, please let me know ASAP.

Thanks,
Boyuan Yang


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

Bug#949528: ceph: mipsel missing from architecture lists for most binary packages.

[Bernd Zeimetz]

Hi, 

Oh well, guess the change was hiding in experimental and was merged...  willne 
fixed with the next upload.

Bernd 

Am 21. Jänner 2020 17:39:12 MEZ schrieb peter green :
>Package: src:ceph
>Version: 14.2.6-4
>Severity: serious
>
>The good news is that the ceph source package now builds on mipsel. YAY
>
>However when checking to see if things were fixed in testing I
>discovered that the only binary package that emerged from the ceph
>14.2.6-4 build on mipsel, was python3-ceph-argparse. It looks like
>mipsel needs to be added back to the architecture lists for the other
>binary packages.

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#949530: network-manager 1.22.4 still failing dhcp on some wifi networks

[Benjamin Redelings]

Package: network-manager
Version: 1.22.4-1
Severity: important

Dear Maintainer,

For some wifi networks, network-manager fails to join the network.  1.22.4 was 
a big improvement over 1.22.2, but there are still some problems.
It logs lines like these:

NetworkManager[854]:   [1578839858.0531] device (p2p-dev-wlp4s0): 
supplicant management interface state: associated -> complet>
NetworkManager[854]:   [1578839858.0534] device (wlp4s0): state change: 
config -> ip-config (reason 'none', sys-iface-state: '>
NetworkManager[854]:   [1578839858.0551] dhcp4 (wlp4s0): activation: 
beginning transaction (timeout in 45 seconds)
NetworkManager[854]:   [1578839861.0781] dhcp4 (wlp4s0): selecting lease 
failed: 12
NetworkManager[854]:   [1578839864.7164] dhcp4 (wlp4s0): selecting lease 
failed: 12
NetworkManager[854]:   [1578839873.5769] dhcp4 (wlp4s0): selecting lease 
failed: 12
NetworkManager[854]:   [1578839892.0217] dhcp4 (wlp4s0): selecting lease 
failed: 12
NetworkManager[854]:   [1578839901.4961] manager: sleep: sleep requested 
(sleeping: no  enabled: yes)
NetworkManager[854]:   [1578839901.4965] device (enp0s31f6): state 
change: unavailable -> unmanaged (reason 'sleeping', sys-if>

I used to be able to join this network with previous versions of 
network-manager.

The gitlab issue links a commit after 1.22.4.

Issue: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/324
Commit: 
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/c19eefc6ec9d0a52f4d3ce75e70cfd6dab60aa2f

I've seen the log message "Activation: Stage 5 of 5 (IPv4 Commit) error 
accepting lease: failed to accept lease: Cannot allocate memory"
but I don't get this every time.

If you roll an update that includes commit c19eefc6, I will check whether this 
fixes the problem.

-BenRI



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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


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

Kernel: Linux 5.4.0-trunk-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
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 network-manager depends on:
ii  adduser3.118
ii  dbus   1.12.16-2
ii  init-system-helpers1.57
ii  libaudit1  1:2.8.5-2+b1
ii  libbluetooth3  5.50-1+b1
ii  libc6  2.29-9
ii  libcurl3-gnutls7.67.0-2
ii  libglib2.0-0   2.62.4-1
ii  libgnutls303.6.11.1-2
ii  libjansson42.12-1
ii  libmm-glib01.10.4-0.1
ii  libndp01.6-1+b1
ii  libnewt0.520.52.21-4
ii  libnm0 1.22.4-1
ii  libpam-systemd 244-3
ii  libpolkit-agent-1-00.105-26
ii  libpolkit-gobject-1-0  0.105-26
ii  libpsl50.20.2-2
ii  libreadline8   8.0-3
ii  libselinux13.0-1
ii  libsystemd0244-3
ii  libteamdctl0   1.30-1
ii  libudev1   244-3
ii  libuuid1   2.34-0.1
ii  policykit-10.105-26
ii  udev   244-3
ii  wpasupplicant  2:2.9-6

Versions of packages network-manager recommends:
ii  crda 3.18-1
ii  dnsmasq-base [dnsmasq-base]  2.80-1.1
ii  iptables 1.8.4-1
ii  modemmanager 1.10.4-0.1
ii  ppp  2.4.7-2+4.1+b1

Versions of packages network-manager suggests:
ii  isc-dhcp-client  4.4.1-2
pn  libteam-utils

-- no debconf information

Bug#949529: keepalived: Please make another source-only upload to allow testing migration

[Boyuan Yang]

Source: keepalived
Version: 1:2.0.19-1
Severity: important

Hi formorer,

The latest upload of your package keepalived will not migrate to Debian
Testing due to being a non-source-only upload. Please make another source-only 
upload to allow the new version with fixes to RC bugs to migrate to Testing.

-- 
Best,
Boyuan Yang


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

Bug#949459: [Pkg-xmpp-devel] Bug#949459: sms4you: homepage link does not exist

[Martin]

Control: tag -1 pending

On 2020-01-21 11:25, Paul Wise wrote:
> I noticed that the Homepage for this package redirects to the salsa
> login page and when you login it says 404 Page Not Found.

Thanks! Fixed in git (6fb52a6e07e9a93b7be0f6ac9cdf19258a20bdc9).

Bug#949468: satpy: autopkgtest regression due to new pygac

[Gianfranco Costamagna]

control: severity -1 important

On Tue, 21 Jan 2020 09:28:40 +0100 Gianfranco Costamagna 
 wrote:
> Source: satpy
> Version: 0.19.1-1
> Severity: serious
> 
> Hello, looks like pygac update regressed the testsuite.
> I requested a new run in Debian, but in the meanwhile you can see a run here:
> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/s/satpy/20200120_195040_eac9b@/log.gz
> 
> or here:
> http://debomatic-amd64.debian.net/distribution#unstable/satpy/0.19.1-1/autopkgtest
> 
> (and even inside the build process itself the error is thrown out, but for 
> some reasons the testsuite errors are somewhat ignored at least in that part)
> 

looks like the debian autopkgtest is green, and the "killed" is an ubuntu-only 
thing.

However, my patch has been merged upstream, so the gac issue is fixed.

G.

Bug#863217: libgmp10:amd64: gmp_snprintf tries to allocate 18 EB on long strings

[Vincent Lefevre]

Control: tags -1 fixed-upstream

On 2017-05-23 21:43:06 +0200, Vincent Lefevre wrote:
> Consider the following program:
> 
> #include 
> #include 
> 
> int main(void)
> {
>   int r;
>   long n = -1;
> 
>   r = gmp_snprintf (NULL, 0, "%2147483600s%100s%ln", "", "", &n);
>   printf ("%d %ld\n", r, n);
>   return 0;
> }
> 
> On my Debian/unstable x86_64 machine (GMP 6.1.2 provided by the Debian
> package), I get after 273 seconds:
> 
> GNU MP: Cannot allocate memory (size=18446744071562067968)

With upstream's GMP 6.2.0, I get:

-1 -1

So the bug is fixed upstream.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#867822: /usr/bin/pdebuild: Re: pbuilder: pdebuild cannot build source-only packages

[Thorsten Glaser]

>> We do. But using a chroot to just build a source package is, in my
>opinion,
>> pointless

Actually not: source packages can differ depending on what
release they are built on.

>when I run dpkg-buildpackage -S, the build fails since I don't have the
>correct build dependencies installed:

This is another good point. While there’s -d, the clean stage
often fails with it, and sometimes, there are build dependencies
on debhelper things (needed for clean) that require a certain
init system to be installed, thus doing this in a chroot is sane.


That being said, I personally just do…

DIST=something cowbuilder --login

… and run the dpkg-buildpackage -S (after installing the needed
B-D) in it, then copy out the stuff from /v/c/pb/build/*/.

bye,
//mirabilos
-- 
[00:02]  gecko: benutzt du emacs ?
[00:03]  nö  [00:03]  nur n normalen mac
[00:04]  argl   [00:04]  ne den editor
-- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)

Bug#949102: eclipse-titan: FTBFS: fails to resolve the local hostname

[Pilisi Gergely]

Got it, thanks! Then the change will come with the next release.

Mattia Rizzolo  ezt írta (időpont: 2020. jan. 21., K
17:50):

> On Tue, Jan 21, 2020 at 05:48:42PM +0100, Pilisi Gergely wrote:
> > Upstream has modified the script, so if the nslookup fails, then it will
> > try to communicate on 127.0.0.1. The nightly tests are running right now,
> > if everything is green, then I'll patch the package.
>
> ACK, in the meantime I also patched pbuilder so it addds the local
> hostname to /etc/hosts; though as I said I don't think that's something
> good to rely on.
>
> So, it can also wait on whenever the next release will happen naturally.
>
> --
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> More about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
>

Bug#949102: eclipse-titan: FTBFS: fails to resolve the local hostname

[Mattia Rizzolo]

On Tue, Jan 21, 2020 at 05:48:42PM +0100, Pilisi Gergely wrote:
> Upstream has modified the script, so if the nslookup fails, then it will
> try to communicate on 127.0.0.1. The nightly tests are running right now,
> if everything is green, then I'll patch the package.

ACK, in the meantime I also patched pbuilder so it addds the local
hostname to /etc/hosts; though as I said I don't think that's something
good to rely on.

So, it can also wait on whenever the next release will happen naturally.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#949102: eclipse-titan: FTBFS: fails to resolve the local hostname

[Pilisi Gergely]

Hi,

Upstream has modified the script, so if the nslookup fails, then it will
try to communicate on 127.0.0.1. The nightly tests are running right now,
if everything is green, then I'll patch the package.

BR,
Gergely Pilisi

Mattia Rizzolo  ezt írta (időpont: 2020. jan. 17., P
12:12):

> On Fri, Jan 17, 2020 at 11:33:23AM +0100, Pilisi Gergely wrote:
> > I'll contact upstream first, they should know about this. Will be back
> soon
> > with the solution.
>
> Thanks.  Just a note on the urgency: it isn't at all.
> The official buildds seems able to resolve their hostname, but I'm
> saying it not agreed upon because just a few days ago there was a
> conversation in #debian-mentors exactly about this.
>
> Also, I'm probably going to patch my builders so it puts the hostname in
> /etc/hosts, so it will at least work, regardless of what is the project
> consensus.
>
> --
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> More about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
>

Bug#949519: sudo-ldap: Fails to connect to LDAP : "ldap_sasl_bind_s(): Can't contact LDAP server"

[Jean-Christophe]

Sorry, it looks like I forget to paste the presentation of my issue on 
reportbug.

I used to use sudo-ldap on Stretch to grant some rights to some users on my 
servers.
I recently upgrade one of these servers to Buster, and now sudo doesn't work 
anymore.
It's always the same error : "ldap_sasl_bind_s(): Can't contact LDAP server".

Which is interesting is that ldapsearch works when I try something like this :
ldapsearch -x -H ldaps://server2.mydomain.com:636 -b 
"ou=SUDOers,dc=mydomain,dc=com"

Also ldap.conf and sudo-ldap.conf are identical.