Bug#966524: lvm2: lvconvert --merge does not remove the snapshot after restarting and completing job

[Antonio]

Package: lvm2
Version: 2.03.09-1
Severity: important

Dear Maintainer,

* What led up to the situation?

I created a snapshot to safely test my application and then run lvconvert
--merge to undo the changes made to the system

* What exactly did you do (or not do) that was effective (or
 ineffective)?

lvcreate --size 10G -s -n revert system/debian
... test my application ...
lvconvert --merge system/revert
reboot

* What was the outcome of this action?

After the restart, the restore was successful but the snapshot was not
removed after the job was completed:

debian   system Owi-aos--- 100,00g 0,00

[revert] system Swi-aos---   1,00g  debian 0,00

* What outcome did you expect instead?

remove the snapshot at the end of the lvconvert process

debian   system -wi-ao 100,00g


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

Kernel: Linux 5.7.11-custom (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=ISO-8859-1)
(ignored: LC_ALL set to it_IT), LANGUAGE=it
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lvm2 depends on:
ii  dmeventd  2:1.02.171-1
ii  dmsetup   2:1.02.171-1
ii  libaio1   0.3.112-8
ii  libblkid1 2.36-1
ii  libc6 2.31-2
ii  libdevmapper-event1.02.1  2:1.02.171-1
ii  libreadline5  5.2+dfsg-3+b13
ii  libselinux1   3.1-2
ii  libsystemd0   245.7-1
ii  libudev1  245.7-1
ii  lsb-base  11.1.0

Versions of packages lvm2 recommends:
ii  thin-provisioning-tools  0.8.5-4

lvm2 suggests no packages.

-- debconf information excluded

Bug#966523: r-bioc-rsubread FTBFS on 32bit: error: conflicting types for ‘uintptr_t’

[Adrian Bunk]

Source: r-bioc-rsubread
Version: 2.2.5-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=r-bioc-rsubread=sid

...
In file included from /usr/lib/gcc/i686-linux-gnu/10/include/stdint.h:9,
 from HelperFunctions.h:139,
 from R_wrapper.c:35:
/usr/include/stdint.h:96:23: error: conflicting types for ‘uintptr_t’
   96 | typedef unsigned int  uintptr_t;
  |   ^
In file included from R_wrapper.c:30:
/usr/share/R/include/Rinterface.h:110:24: note: previous declaration of 
‘uintptr_t’ was here
  110 |  typedef unsigned long uintptr_t;
  |^
make[1]: *** [/usr/lib/R/etc/Makeconf:167: R_wrapper.o] Error 1

Bug#966522: libgetdata: binary-all FTBFS

[Adrian Bunk]

Source: libgetdata
Version: 0.10.0-8
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=libgetdata=all=0.10.0-8=1596045626=0

...
   dh_missing -i
dh_missing: warning: usr/include/getdata.mod exists in debian/tmp but is not 
installed to anywhere 
dh_missing: error: missing files, aborting
The following debhelper tools have reported what they installed (with 
files per package)
 * dh_install: libf95getdata7 (2), libfgetdata6 (2), libgetdata++7 (2), 
libgetdata-dev (27), libgetdata-doc (190), libgetdata-perl (1), 
libgetdata-tools (4), libgetdata8 (2), python3-pygetdata (1)
 * dh_installdocs: libf95getdata7 (0), libfgetdata6 (0), libgetdata++7 
(0), libgetdata-dev (0), libgetdata-doc (3), libgetdata-perl (0), 
libgetdata-tools (0), libgetdata8 (0), python3-pygetdata (0)
 * dh_installman: libf95getdata7 (0), libfgetdata6 (0), libgetdata++7 
(0), libgetdata-dev (0), libgetdata-doc (0), libgetdata-perl (0), 
libgetdata-tools (0), libgetdata8 (0), python3-pygetdata (0)
If the missing files are installed by another tool, please file a bug 
against it.
When filing the report, if the tool is not part of debhelper itself, 
please reference the
"Logging helpers and dh_missing" section from the "PROGRAMMING" guide 
for debhelper (10.6.3+).
  (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz)
Be sure to test with dpkg-buildpackage -A/-B as the results may vary 
when only a subset is built
If the omission is intentional or no other helper can take care of this 
consider adding the
paths to debian/not-installed.
make: *** [debian/rules:28: binary-indep] Error 25

Bug#966315: (Requesting sponsorship) Re: Bug#966315: ITP: age -- simple, modern and secure encryption tool

[Johan Fleury]

Hello.

So, apart from the issue I reported in my previous message, I believe the 
package is ready to be included in Debian.

If a kind member could help me get this “finalized” I’d be very happy :)

--
Johan Fleury

signature.asc
Description: OpenPGP digital signature

Bug#966520: Please enable AMD AMF

[Louis-Philippe Véronneau]

Package: src:ffmpeg
Version: 7:4.3-3
Severity: wishlist

Dear maintainers,

It seems ffmpeg version 4.3 now supports AMD AMF on Linux via Vulkan
[1]. Would it be possible to enable it?

From what I understand, this needs the AMF framework header files, that
can be found here:

https://github.com/GPUOpen-LibrariesAndSDKs/AMF/tree/master/amf/public/include

These files are under the MIT, so I think it should be ok to package
them in Debian.

I'm not 100% sure if AMF works on mesa though (without the amdgpu-pro
non-free drivers), as the documentation isn't super clear on this [2].

Cheers,

[1]: https://www.phoronix.com/scan.php?page=news_item=FFmpeg-4.3-Released
[2]: http://www.ffmpeg.org/general.html#toc-AMD-AMF_002fVCE

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature

Bug#948712: raspi-firmware: Please add support for Raspebrry Pi4

[Christian Marillat]

On 29 juil. 2020 15:40, Lucas Nussbaum  wrote:

> Version: 1.20200212-1
>
> Hi,
>
> raspi-firmware now supports RPI4. (I could not find the exact version
> where this was fixed, but at least it's fixed in the version above)

I'm not talking about files itself but how firmware are installed under
Debian.

With a rpi4 we don't need a /boot/firmware partition in vfat format as
rpi4 are able to boot from ext4.

Here is the original bug report :

,
| >> Setting up raspi-firmware (1.20190925-1) ...
| >> Error: missing /boot/firmware, did you forget to mount it?
| >> dpkg: error processing package raspi-firmware (--configure):
| >>  installed raspi-firmware package post-installation script subprocess 
returned error exit status 1
| >> Errors were encountered while processing:
| >>  raspi-firmware
| >> E: Sub-process /usr/bin/dpkg returned an error code (1)
| >> 
| >> Also note that Pi4 is able to boot from an ext4 partition and don't need 
/boo/firmware.
`

Christian

Bug#966519: RM: pysal -- ROM; Unmaintained

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org

Please remove pysal from the archive,
it is unmaintained and has a low popcon score.

Kind Regards,

Bas

Bug#941326: More detail

[Gary]

This looks like a bug in readline 8.0

Program received signal SIGSEGV, Segmentation fault.
0x776637da in _rl_update_final () at ../display.c:2972
2972  botline_length = VIS_LLEN(_rl_vis_botlin) - woff;


Once the macros are expanded this is attempting to deference the NULL
pointer line_state_visible->lbreaks. This pointer is initialized in
rl_display, but in the password entry case the standard rl_display is
overridden and it is never initialized.

This was ok in version 7.0 as full_lines is set to zero and VIS_LLEN was
not called.
Relevant diff below.

_rl_update_final ()

2968
full_lines = 1;
}
_rl_move_vert (_rl_vis_botlin);
• woff = W_OFFSET(_rl_vis_botlin, wrap_offset);
• botline_length = VIS_LLEN(_rl_vis_botlin) - woff;
/* If we've wrapped lines, remove the final xterm line-wrap flag. */
• if (full_lines && _rl_term_autowrap && (VIS_LLEN(_rl_vis_botlin) ==
_rl_screenwidth))
• if (full_lines && _rl_term_autowrap && botline_length == _rl_screenwidth)



signature.asc
Description: OpenPGP digital signature

Bug#966517: qemu-system-x86: Qemu called with curses arg exits with qemu-system-x86_64: Display 'curses' is not available.

[Eldon]

Package: qemu-system-x86
Version: 1:5.0-13
Severity: normal
X-Debbugs-Cc: debianb...@eldondev.com

Dear Maintainer,

I frequently use the -curses argument with a variety of qemu
invocations. After performing some straces, it appears that only these
latest builds expect a ui-curses.so file. I attempted to install
qemu-system-gui, but that package contains no such file on my system.

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

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

Versions of packages qemu-system-x86 depends on:
ii  ipxe-qemu 1.0.0+git-20190125.36a4c85-5
ii  libaio1   0.3.112-8
ii  libbrlapi0.7  6.0+dfsg-6
ii  libc6 2.31-2
ii  libcacard01:2.7.0-1
ii  libcapstone3  4.0.1+really+3.0.5-2
ii  libepoxy0 1.5.4-1
ii  libfdt1   1.6.0-1
ii  libgbm1   20.1.2-1
ii  libgcc-s1 10.1.0-6
ii  libglib2.0-0  2.64.4-1
ii  libgnutls30   3.6.14-2+b1
ii  libibverbs1   29.0-1
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  libnettle83.6-2
ii  libnuma1  2.0.12-1+b1
ii  libpixman-1-0 0.36.0-1
ii  libpmem1  1.8-1
ii  libpng16-16   1.6.37-2
ii  librdmacm129.0-1
ii  libsasl2-22.1.27+dfsg-2
ii  libseccomp2   2.4.3-1+b1
ii  libslirp0 4.3.1-1
ii  libspice-server1  0.14.3-1
ii  liburing1 0.6-3
ii  libusb-1.0-0  2:1.0.23-2
ii  libusbredirparser10.8.0-1+b1
ii  libvdeplug2   2.3.2+r586-2.2+b1
ii  libvirglrenderer1 0.8.2-3
ii  libxendevicemodel14.11.4+24-gddaaccbbab-1
ii  libxenevtchn1 4.11.4+24-gddaaccbbab-1
ii  libxenforeignmemory1  4.11.4+24-gddaaccbbab-1
ii  libxengnttab1 4.11.4+24-gddaaccbbab-1
ii  libxenmisc4.114.11.4+24-gddaaccbbab-1
ii  libxenstore3.04.11.4+24-gddaaccbbab-1
ii  libxentoolcore1   4.11.4+24-gddaaccbbab-1
ii  qemu-system-common1:5.0-13
ii  qemu-system-data  1:5.0-13
ii  seabios   1.13.0-1
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages qemu-system-x86 recommends:
ii  ovmf 2020.05-2
ii  qemu-system-gui  1:5.0-13
ii  qemu-utils   1:5.0-13

Versions of packages qemu-system-x86 suggests:
pn  qemu-block-extra
ii  qemu-system-data [sgabios]  1:5.0-13
pn  samba   
pn  vde2

-- no debconf information

Bug#965064: pkg-haskell-tools: FTBFS in unstable

[Clint Adams]

On Wed, Jul 15, 2020 at 03:09:24PM +0100, Iain Lane wrote:
> Upgrading shake will fix this, or it can be worked around in the 

In theory we can upgrade shake once js-dgtable clears NEW.  It's
been sitting there for 3 months.

Bug#966393: pandas: FTBFS: TypeError: use() got an unexpected keyword argument 'warn'

[Rebecca N. Palmer]

Control: found -1 0.25.3+dfsg2-3
Control: tags -1 fixed-upstream patch
(untested)

Probably matplotlib 3.3:
https://github.com/pandas-dev/pandas/pull/35323

Bug#966392: [pkg-php-pear] Bug#966392: php-codecoverage: FTBFS 4 tests failed

[Robin Gustafsson]

> -Setting up php-token-stream (4.0.1-1) ...
> +Setting up php-token-stream (4.0.3-1) ...
> [...]
>-Setting up php-phpdocumentor-reflection-docblock (4.3.3-1) ...
>+Setting up php-phpdocumentor-reflection-docblock (5.1.0-1) ...

One or both of these seem to be the cause.

The tests pass if I specifically depend on php-token-stream (4.0.1-1).
Doing so also brings in php-phpdocumentor-reflection-docblock
(4.3.3-1).

Diff in installed packages for my successful build:
-Setting up php-token-stream (4.0.3-1) ...
+Setting up php-token-stream (4.0.1-1) ...
-Setting up php-phpdocumentor-reflection-docblock (5.1.0-1) ...
+Setting up php-phpdocumentor-reflection-docblock (4.3.3-1) ...

Upstream dropped the dependency on php-token-stream recently. There's
no new upstream release (tag) since then yet.

Regards,
Robin

Bug#965001: strange version 2.1.0 beta4 fails tests with mpfr4 4.1.0

[Martin Kelly]

On Wed, Jul 15, 2020, 4:27 PM Martin Kelly  wrote:

> On Tue, Jul 14, 2020, 3:15 AM Vincent Lefevre  wrote:
>
>> On 2020-07-14 09:48:18 +0200, Matthias Klose wrote:
>> > There is no 2.1.0 beta4, just a beta1, so I don't know what was
>> packaged in
>> > February 2020.  However the tests now fail with mpfr 4.1.0, seems to be
>> > consistent across all architectures:
>> >
>> > **
>> > File "test/test_gmpy2_format.txt", line 157, in test_gmpy2_format.txt
>> > Failed example:
>> > c.__format__('e')
>> > Differences (ndiff with -expected +actual):
>> > - '3.3331e-01+5e+00j'
>> > + '3.3331e-01+5.e+00j'
>> > ?  +
>>
>> FYI, the old MPFR behavior was regarded as a bug:
>>
>>
>> https://gforge.inria.fr/tracker/index.php?func=detail=21816_id=136=619
>>
>> There were 2 reasonable interpretations of the description in the
>> MPFR manual that did not leave the output partly unspecified, and
>> for each of them, some outputs were incorrect. The one that has
>> been chosen is the one that is closer to ISO C's %e and it does
>> not change the numerical output value (the only difference is
>> trailing zeros).
>>
>> --
>> Vincent Lefèvre  - Web: 
>> 100% accessible validated (X)HTML - Blog: 
>> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
>>
>
> Hi all,
>
> Thanks for the bug report. Unfortunately I'm on a long hiking vacation
> with no computer access until October and won't be able to look at this
> until then. I welcome a non-maintainer upload if this needs a fix sooner.
>
> I'm also CCing the upstream maintainer, who may have an opinion on that to
> do here.
>

The beta4 version is this one:
https://github.com/aleaxit/gmpy/releases/tag/gmpy2-2.1.0b4

It looks like it may be a tag but not a release? In any case, I assume
that's what I packaged (I can't check as I don't have computer access right
now, just phone).

Apparently this bug is going to cause autoremoval from testing soon. Is the
severity really high enough for that?

Again, I'd like to take a closer look at this but am away from a computer
until October on an extended trip

>

Bug#936288: cfv

[Sandro Tosi]

On Mon, 27 Jul 2020 01:19:52 +0200 Stefan Alfredsson  wrote:
>
> Closing since cfv is being removed due to python2 dependency.
>
> (removal request - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966332 )

please dont close bugs for packages that are still in the archive. the
RM process takes care of closing them when the package is actually
removed

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#936628: gnucap-python: diff for NMU version 0.0.2-1.2

[Sandro Tosi]

Control: tags 936628 + patch


Dear maintainer,

I've prepared an NMU for gnucap-python (versioned as 0.0.2-1.2). The diff
is attached to this message.

Regards.

diff -Nru gnucap-python-0.0.2/debian/changelog gnucap-python-0.0.2/debian/changelog
--- gnucap-python-0.0.2/debian/changelog	2019-01-20 07:38:13.0 -0500
+++ gnucap-python-0.0.2/debian/changelog	2020-07-29 21:27:14.0 -0400
@@ -1,3 +1,10 @@
+gnucap-python (0.0.2-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #936628
+
+ -- Sandro Tosi   Wed, 29 Jul 2020 21:27:14 -0400
+
 gnucap-python (0.0.2-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru gnucap-python-0.0.2/debian/control gnucap-python-0.0.2/debian/control
--- gnucap-python-0.0.2/debian/control	2019-01-20 07:38:13.0 -0500
+++ gnucap-python-0.0.2/debian/control	2020-07-29 21:20:12.0 -0400
@@ -11,10 +11,6 @@
gnucap,
gnucap-default-plugins0,
libgnucap-dev,
-   python,
-   python-numpy,
-   python-scipy,
-   python2.7-dev,
python3-all-dev,
python3-numpy,
python3-scipy,
@@ -27,30 +23,13 @@
 Package: gnucap-python
 Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends}
-Suggests: gnucap, python
+Suggests: gnucap, python3
 Description: GNU Circuit Analysis package, Python command plugin
  This package contains a plugin with a command to load extensions written in
  the Python language.
  .
  Gnucap is a general purpose circuit simulator. It performs nonlinear
  dc and transient analyses, Fourier analysis, and ac analysis
- linearized at an operating point. It is fully interactive and
- command driven. It can also be run in batch mode or as a server.
-
-Package: python-gnucap
-Section: python
-Architecture: any
-Depends: ${dlopen:Depends},
- ${misc:Depends},
- ${python:Depends},
- ${shlibs:Depends}
-Recommends: gnucap-default-plugins0
-Suggests: gnucap-devel
-Description: Python 2 bindings for the GNU Circuit Analysis Package
- This package contains Python2 bindings for the GNU Circuit Analysis Package.
- .
- Gnucap is a general purpose circuit simulator. It performs nonlinear
- dc and transient analyses, Fourier analysis, and ac analysis
  linearized at an operating point. It is fully interactive and
  command driven. It can also be run in batch mode or as a server.
 
diff -Nru gnucap-python-0.0.2/debian/python-gnucap.install gnucap-python-0.0.2/debian/python-gnucap.install
--- gnucap-python-0.0.2/debian/python-gnucap.install	2018-12-20 06:25:09.0 -0500
+++ gnucap-python-0.0.2/debian/python-gnucap.install	1969-12-31 19:00:00.0 -0500
@@ -1,2 +0,0 @@
-/usr/lib/python2*/*/gnucap/*.so*
-/usr/lib/python2*/*/gnucap/*py
diff -Nru gnucap-python-0.0.2/debian/rules gnucap-python-0.0.2/debian/rules
--- gnucap-python-0.0.2/debian/rules	2019-01-20 07:38:13.0 -0500
+++ gnucap-python-0.0.2/debian/rules	2020-07-29 21:21:24.0 -0400
@@ -1,7 +1,6 @@
 #!/usr/bin/make -f
 
-PYVERS:= $(shell pyversions -v -r debian/control) \
-  $(shell py3versions -v -r debian/control)
+PYVERS:= $(shell py3versions -v -r debian/control)
 
 PYDEF:= $(shell py3versions -d -v)
 
@@ -19,7 +18,7 @@
 
 
 %:
-	dh $@ --with python2,python3
+	dh $@ --with python3
 
 build: build-arch build-indep
 
@@ -65,11 +64,9 @@
 
 override_dh_shlibdeps: debian/tmp.lib
 	dh_shlibdeps
-	dh_numpy
 	dh_numpy3
 
 	# inject extra library dependency
-	cat $< >> debian/python-gnucap.substvars
 	cat $< >> debian/python3-gnucap.substvars
 
 # dpkg-shlibdeps misses the dlopen in gnucap/__init__.py

Bug#947384: fixed in ipmitool 1.8.18-9

[Paul Wise]

Control: reopen -1

On Wed, 2020-07-29 at 16:48 +, Jörg Frings-Fürst wrote:

>* debian/ipmitool.maintscript:
>  - Fix syntax (Closes: #947384).

Unfortunately this change has not fixed the bug, reopening.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#963475: Could not parse device path: Invalid argument

[Michel Le Bihan]

Hello,

I tested `efibootmgr -v` from Debian testing in QEMU and had the `Could
not parse device path: Invalid argument` error. Then I downloaded
Fedora 32 live, run `efibootmgr -v` and got a nice output:
```
[liveuser@localhost-live ~]$ sudo efibootmgr -v
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,,0005
Boot* UiApp FvVol(7cb8bdc9-f8eb-4f34-aaea-
3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0001* UEFI QEMU DVD-ROM QM1 PciRoot(0x0)/Pci(0x1f,0x2)/Sata
(0,65535,0)N.YMR,Y.
Boot0005* EFI Internal ShellFvVol(7cb8bdc9-f8eb-4f34-aaea-
3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
```

I think that the Debian package should have this patch applied.

Michel Le Bihan

Bug#965282: wpasupplicant: fails to create /var/run/wpa_supplicant control interface in Debian 10

[APT Gatuno MX]

Finally found the issue.

Looks like the ctrl unix sockets are not created if network-manager is 
not installed. Not sure about the complete work-flow, but goes like 
this:


* wpa_supplicant inits. It doesn't create any unix socket on normal 
startup

* network-manager ask for something in the dbus interface.
* wpa_supplicant runs wpa_supplicant_add_iface function which in turns 
creates the unix socket control for the interface.


The only remaining question is, there is a chance for a simple program 
to control wpa_supplicant daemon without network-manager or dbus?


I think that as long as this bug is not Debian related, it should be 
closed.


--
Atte. Félix Arreola
«Sin firma GPG»

Bug#966366: json-c: Please package new release (0.15)

[Chris Hofstaedtler]

* Boyuan Yang  [200729 23:30]:
> Source: json-c
> Version: 0.14+dfsg-1
> Tags: sid
> Severity: normal
> X-Debbugs-CC: babelou...@debian.org
> 
> Dear new Debian json-c maintainer,
> 
> It seems that the json-c upstream has just released v0.15:
> 
> https://github.com/json-c/json-c/releases

0.15 also contains the fix for #963932, so that'd be appreciated
too.

Chris

Bug#966515: scons: Some upstream sources are missing

[Bill Deegan]

So what is this issue?
Which tarball debian packages are using as their source?

On Wed, Jul 29, 2020 at 4:23 PM Ben Hutchings 
wrote:

> On Wed, 2020-07-29 at 16:11 -0700, Bill Deegan wrote:
> > Note there's a bug for this on SCons tracker.
> > https://github.com/SCons/scons/issues/3759
> >
> > Please add any comments there.
>
> No, that's an entirely different issue.
>
> Ben.
>
> --
> Ben Hutchings, Software Developer Codethink Ltd
> https://www.codethink.co.uk/ Dale House, 35 Dale Street
>  Manchester, M1 2HF, United Kingdom
>
>

Bug#966515: scons: Some upstream sources are missing

[Ben Hutchings]

On Wed, 2020-07-29 at 16:11 -0700, Bill Deegan wrote:
> Note there's a bug for this on SCons tracker.
> https://github.com/SCons/scons/issues/3759
> 
> Please add any comments there.

No, that's an entirely different issue.

Ben.

-- 
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
 Manchester, M1 2HF, United Kingdom

Bug#963932: Unversioned symbol json_object_iter_next is in all of json-c, jansson, json-glib

[Chris Hofstaedtler]

Control: severity -1 important

* Simon McVittie  [200728 00:21]:
> On Sun, 28 Jun 2020 at 22:06:13 +0200, Chris Hofstaedtler wrote:
> > your libraries BOTH export a symbol named json_object_iter_next,
> > causing crashes for binaries that end up loading both (possibly
> > transitively).

[..]

> Because util-linux (libmount) has taken steps to avoid pulling json-c
> into unsuspecting processes' namespaces, I don't think this should be
> treated as RC any more - I think important would now be a more reasonable
> severity. Chris, do you agree?

>From libmount PoV, I agree. Have lowered severity for #963932 now,
but this should not be seen as overriding jansson,json-c Maintainers
preference.

Chris

Bug#966515: scons: Some upstream sources are missing

[Bill Deegan]

Note there's a bug for this on SCons tracker.
https://github.com/SCons/scons/issues/3759

Please add any comments there.

On Wed, Jul 29, 2020 at 4:06 PM Ben Hutchings 
wrote:

> Source: scons
> Version: 3.1.2-2
> Severity: serious
>
> Dear Maintainer,
>
> The current source package uses the 'production' tarballs
> (scons-.tar.gz) as the orig tarball, whereas the upstream
> source tarballs are released as scons-src-.tar.gz.
>
> The 'production' tarballs contain many generated or preprocessed files.
> In particular, the manual pages there are generated from the doc/man/
> subdirectory of the upstream source, which is *not* included in the
> production tarballs.
>
> Ben.
>
> -- System Information:
> Debian Release: 10.4
>   APT prefers stable
>   APT policy: (990, 'stable'), (500, 'stable-updates')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386, armhf, arm64
>
> Kernel: Linux 4.19.0-9-amd64 (SMP w/2 CPU cores)
> 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
>
> --
> Ben Hutchings, Software Developer Codethink Ltd
> https://www.codethink.co.uk/ Dale House, 35 Dale Street
>  Manchester, M1 2HF, United Kingdom
>
>

Bug#966516: mako-notifier: Runtime failure when the config file is a symlink

[Kate]

Package: mako-notifier
Version: 1.4.1-1

When creating a config file for mako using a symlink, the program fails to run 
successfully:

$ mkdir ~/.config/mako
$ touch ~/test-config
$ ln -s ~/.confiq/mako/config ~/test-config
$ mako
Unable to open /home/kit_ty_kate/.config/mako/config for readingFailed to parse 
config

However, I tried to compile mako from source 
https://github.com/emersion/mako.git (https://github.com/emersion/mako) using 
the same tag (v1.4.1):

$ git checkout v1.4.1
$ meson build
$ ninja -C build
$ ./build/mako

and the resulting binary ./build/mako works fine. I'm not sure what's going on.

I'm using Debian Sid, Linux kernel 5.7.10-1, x86_64, libc6 2.31-2

Warm regards,
Kate

Bug#966515: scons: Some upstream sources are missing

[Ben Hutchings]

Source: scons
Version: 3.1.2-2
Severity: serious

Dear Maintainer,

The current source package uses the 'production' tarballs
(scons-.tar.gz) as the orig tarball, whereas the upstream
source tarballs are released as scons-src-.tar.gz.

The 'production' tarballs contain many generated or preprocessed files.
In particular, the manual pages there are generated from the doc/man/
subdirectory of the upstream source, which is *not* included in the
production tarballs.

Ben.

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

Kernel: Linux 4.19.0-9-amd64 (SMP w/2 CPU cores)
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

-- 
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
 Manchester, M1 2HF, United Kingdom

Bug#966514: elpa-org-roam: Invalid read syntax: "#" when building db

[Rod Tye]

Package: elpa-org-roam
Version: 1.2.1-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
   I started emacs without the init file using the command
   /usr/bin/emacs -q
   Then I ran
   (require 'org-roam)
   from scratch window and
   M-x org-roam-db-build-cache

   I get the error message:
   Invalid read syntax: "#"


If I run M-x toggle-debug-on-error 
and repeat the process it gives me a debug stack:
Debugger entered--Lisp error: (invalid-read-syntax "#")
  read(#)
  #f(compiled-function (conn) #)(#)
  apply(#f(compiled-function (conn) #) 
# nil)
  emacsql-parse(#)
  #f(compiled-function (connection sql  args) "Send SQL s-expression to 
CONNECTION and return the results." #)(# [:pragma 
(= busy-timeout $s1)] 15000)
  apply(#f(compiled-function (connection sql  args) "Send SQL s-expression 
to CONNECTION and return the results." #) 
# ([:pragma (= 
busy-timeout $s1)] 15000))
  emacsql(# [:pragma (= 
busy-timeout $s1)] 15000)
  #f(compiled-function (conn slots) #)(# (:file 
"/home/rod/org-roam/org-roam.db"))
  apply(#f(compiled-function (conn slots) #) 
(# (:file 
"/home/rod/org-roam/org-roam.db")))
  #f(compiled-function ( args) #)(# (:file 
"/home/rod/org-roam/org-roam.db"))
  apply(#f(compiled-function ( args) #) 
# (:file 
"/home/rod/org-roam/org-roam.db"))
  initialize-instance(# 
(:file "/home/rod/org-roam/org-roam.db"))
  #f(compiled-function (class  slots) "Default constructor for CLASS 
`eieio-default-superclass'.\nSLOTS are the initialization slots used by 
`initialize-instance'.\nThis static method is called when an object is 
constructed.\nIt allocates the vector used to represent an EIEIO object, and 
then\ncalls `initialize-instance' on that object." #)(emacsql-sqlite3-connection :file "/home/rod/org-roam/org-roam.db")
  apply(#f(compiled-function (class  slots) "Default constructor for CLASS 
`eieio-default-superclass'.\nSLOTS are the initialization slots used by 
`initialize-instance'.\nThis static method is called when an object is 
constructed.\nIt allocates the vector used to represent an EIEIO object, and 
then\ncalls `initialize-instance' on that object." #) 
emacsql-sqlite3-connection (:file "/home/rod/org-roam/org-roam.db"))
  make-instance(emacsql-sqlite3-connection :file 
"/home/rod/org-roam/org-roam.db")
  emacsql-sqlite3("/home/rod/org-roam/org-roam.db")
  org-roam-db()
  org-roam-db-build-cache(nil)
  funcall-interactively(org-roam-db-build-cache nil)
  call-interactively(org-roam-db-build-cache record nil)
  command-execute(org-roam-db-build-cache record)
  execute-extended-command(nil "org-roam-db-build-cache" "org-roam-db-bu")
  funcall-interactively(execute-extended-command nil "org-roam-db-build-cache" 
"org-roam-db-bu")
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)



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

Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=UTF-8) (ignored: LC_ALL set to 
en_GB.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages elpa-org-roam depends on:
ii  dh-elpa-helper2.0.4
ii  elpa-dash 2.17.0+dfsg-1
ii  elpa-emacsql  3.0.0+ds-2
ii  elpa-emacsql-sqlite3  1.0.1-1
ii  elpa-f0.20.0-2
ii  elpa-s1.12.0-3
ii  emacsen-common3.0.4

Versions of packages elpa-org-roam recommends:
ii  emacs  1:26.3+1-2
ii  emacs-gtk [emacs]  1:26.3+1-2

Versions of packages elpa-org-roam suggests:
pn  org-roam-doc  

-- no debconf information

Bug#966451: cloud.debian.org: systemd-growfs@-.service fails on arm64 instance types

[kula]

On 2020-07-29 08:01:19, Bastian Blank wrote:
> On Tue, Jul 28, 2020 at 03:40:14PM -0700, Noah Meyerhans wrote:
> > Actually, the problem seems to have been caused by
> > https://salsa.debian.org/cloud-team/debian-cloud-images/-/merge_requests/192/
> > Prior to that MR, we weren't using systemd-growfs at all.
> 
> Prior to that we did not have any grow capability at all in several
> setup, so reverting is not really an option.

I'd say reverting is always an option and in some cases when behaviour becomes
erratic I'd prefer to revert to expected lack of something that having
inconsistency across whole fleet of instances.

> > I've confirmed impact on amd64 instances as well as the arm64 instances
> > on which originally observed it.  It also seems like this could impact
> > our images on other cloud services besides Amazon EC2, but I haven't
> > tested there.
> 
> I'll take a look later.  None of the instances I tested showed this
> behaviour.

Thank Waldi.
-- 

|_|0|_|  |
|_|_|0|  "Panta rei" |
|0|0|0|  kuLa    |

gpg --keyserver pgp.mit.edu --recv-keys 0x686930DD58C338B3
3DF1  A4DF  C732  4688  38BC  F121  6869  30DD  58C3  38B3


signature.asc
Description: PGP signature

Bug#960617: popularity-contest: popcon fails to send data if USETOR=maybe and tor is not running

[Bill Allombert]

On Wed, Jul 29, 2020 at 12:35:14PM +0200, Ben Wiederhake wrote:
> Package: popularity-contest
> Version: 1.70
> Followup-For: Bug #960617
> 
> Dear Maintainer,
> 
> I also ran into this issue.

> For some reason, setting USETOR="no" in /etc/popularity-contest.conf does not
> do the trick for me. (It still fails.)

Could you try run
sh -x /etc/cron.daily/popularity-contest
to see why it fails ?

(set DAY in /etc/popularity-contest.conf to the current day of the
week).

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#966199: nastran: FTBFS with GCC 10: Error: BOZ constant at (1) uses nonstandard postfix syntax

[Andreas Beckmann]

Hi Sylvestre,

you sponsored the nastran upload some years ago, could you take a look
again?

Thanks

Andreas

On 7/25/20 11:50 AM, Luca Dall'Olio wrote:
> Hi,
> 
> Thank you for reporting: I just fixed the issue by adding a check in
> configure.ac and defining -fallow-invalid-boz if present. I checked with
> both gfortran-10 and gfortran-7 and tests are passing.
> 
> I had to add autoconf-archive in Buld-Depends to have
> the AX_CHECK_COMPILE_FLAG macro
> 
> My tests are passing
>  with
> this revision
> 
> .
> 
> Honestly, I do not remember well the procedure to push these changes into
> the Debian build system, could you please point me in the right direction?
> 
> Thank you very much in advance, all the best
> 
> Luca
> 
> Il giorno ven 24 lug 2020 alle ore 18:09 Andreas Beckmann 
> ha scritto:
> 
>> Source: nastran
>> Version: 0.1.95-1
>> Severity: serious
>> Tags: ftbfs sid bullseye
>> Justification: fails to build from source
>> User: debian-...@lists.debian.org
>> Usertags: ftbfs-gcc-10
>>
>> Hi,
>>
>> nastran started to FTBFS when GCC 10 was made the default compiler:
>>
>> f77  -g -w -fno-range-check -fno-automatic -fcray-pointer -std=legacy -c
>> -o bufchk.o bufchk.f
>> bufchk.f:16:28:
>>
>>16 |  1 '1'X,  '2'X , '3'X, '4'X  ,
>> '8'X   /
>>   |1
>> Error: BOZ constant at (1) uses nonstandard postfix syntax [see
>> '-fno-allow-invalid-boz']
>> bufchk.f:18:32:
>>
>>18 |  1 'F'X,  'F'X , 'F'X, 'F'X /
>>   |1
>> Error: BOZ constant at (1) uses nonstandard postfix syntax [see
>> '-fno-allow-invalid-boz']
>> bufchk.f:20:32:
>>
>>20 |  1 'F'X,  'F'X , 'F'X, 'F'X /
>>   |1
>> Error: BOZ constant at (1) uses nonstandard postfix syntax [see
>> '-fno-allow-invalid-boz']
>> make[2]: *** [Makefile:390: bufchk.o] Error 1
>>
>> More information about the corresponding GCC changes can be found here:
>> https://gcc.gnu.org/gcc-10/porting_to.html
>>
>>
>> Andreas
>>
> 

Bug#966500: python3-notcurses: missing Breaks+Replaces: notcurses-bin (<< 1.6)

[Andreas Beckmann]

Control: tag -1 pending

On 7/29/20 2:32 PM, Nick Black wrote:
> Thank you for filing my first Debian bug! How exciting, and at
> the same time embarrassing. I should have caught this before
> uploading. A fix is obvious, and I ought be able to accomplish
> it within the Debian packaging proper, rather than requiring a
> new release (I'm the upstream author).

Yes, the fix is only in the Debian packaging part (perhaps unless you
decide to move around stuff again).
Don't feel too embarrassed, I forgot Breaks+Replaces when I renamed a
package yesterday, too. And noticed it two minutes after the upload.

On 7/29/20 6:44 PM, Nick Black wrote:
> pending
> thanks

See above for the correct syntax to tag the bug as pending by simply
sending a mail to the bug ;-)

> Andreas, if a fix tomorrow or the next day isn't fast enough,
> let me know and I can push on the 1.6.9+dfsg.1-3. thanks!

I don't mind when this gets fixed, it's fine to bundle it with more
fixes/new upstream releases ;-)
This RC (release critical) bug will prevent the buggy version from
migrating to testing.
(Only if the package gets out-of-sync between testing and unstable for
more than two months you are risking removal from testing.)

Andreas

Bug#925992: upgrade-reports: Suspend no longer working on Thinkpad X1 Carbon after "dist-upgrade" yesterday

[Julian G. Rutten]

This is the Debian list, and I can confirm I have a similar issue on my
T495 Thinkpad with Ubuntu 20.04. When I suspend it goes to the login
screen, when I enter my password it goes into hibernation. When I try to
wake it I am logged in. Used to work fine before recent updates as stated.

On Wed, Jul 29, 2020 at 9:09 PM Abdullah  wrote:

>
> I'm running Arch Linux right now and have no problems with X1 Carbon on
> suspension.
>
>
> On 29/07, Walter Montes wrote:
> >Hi there,
> >
> >I have excatly the same issue after installing Ubuntu 20.04 in my Thinkpad
> >Helix. With Ubuntu 18.04 I had no problems ...
> >Could you fix that?
> >This could help:
> >https://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg5512720.html
> >
> >But if you have a better solution, please let me know
> >
> >On Fri, 29 Mar 2019 14:46:59 -0700 Ali Sayed  wrote:
> >> Package: upgrade-reports
> >> Severity: normal
> >>
> >> Dear Maintainer,
> >>
> >>
> >> After running "apt get dist-upgrade" and upgrading to
> >vmlinuz-4.19.0-4-amd64 I noticed that I can no longer suspend my laptop
> >either by closing the lid or manually. This used to work before the
> >upgrade. I also noticed that the touchpad was no longer working with my
> >XFCE desktop.
> >>
> >> Upon further investigation I noticed the synaptics touchpad driver was
> >missing so I installed the package xserver-xorg-input-synaptics and
> >rebooted my system. I was able to Suspend once right after the reboot but
> >then it no longer works. also the tocuhpad worked right after the reboot
> >but not after my repeated attempts to suspend.
> >>
> >> Here is out from "dmesg"
> >>
> >> [27361.594572] PM: suspend entry (s2idle)
> >> [27361.594573] PM: Syncing filesystems ... done.
> >> [27361.613865] Freezing user space processes ... (elapsed 0.001 seconds)
> >done.
> >> [27361.615612] OOM killer disabled.
> >> [27361.615613] Freezing remaining freezable tasks ... (elapsed 0.001
> >seconds) done.
> >> [27361.616806] Suspending console(s) (use no_console_suspend to debug)
> >> [27361.620724] rmi4_f01 rmi4-00.fn01: Failed to write sleep mode: -6.
> >> [27361.620727] rmi4_f01 rmi4-00.fn01: Suspend failed with code -6.
> >> [27361.620729] rmi4_physical rmi4-00: Failed to suspend functions: -6
> >> [27361.620733] rmi4_smbus 1-002c: Failed to suspend device: -6
> >> [27361.620740] dpm_run_callback(): rmi_smb_suspend+0x0/0x50 [rmi_smbus]
> >returns -6
> >> [27361.620743] PM: Device 1-002c failed to suspend: error -6
> >> [27361.657382] PM: Some devices failed to suspend, or early wake event
> >detected
> >> [27361.915062] OOM killer enabled.
> >> [27361.915064] Restarting tasks ...
> >> [27361.916391] rmi4_physical rmi4-00: rmi_driver_set_irq_bits: Failed to
> >change enabled interrupts!
> >> [27361.916401] psmouse: probe of serio2 failed with error -1
> >> [27361.916411] done.
> >> [27361.927609] PM: suspend exit
> >> [27362.156899] e1000e: enp0s25 NIC Link is Down
> >> [27362.235054] IPv6: ADDRCONF(NETDEV_UP): enp0s25: link is not ready
> >> [27362.449650] IPv6: ADDRCONF(NETDEV_UP): enp0s25: link is not ready
> >> [27362.514062] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
> >> [27362.765765] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
> >> [27363.033796] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
> >> [27363.094240] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
> >> [27366.354289] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
> >> [27369.330559] wlp3s0: authenticate with 84:61:a0:66:b3:30
> >>
> >>
> >> I no longer have the older vmlinuz-4.19.0-2-amd64 kernel on this system
> >to test if this is a bug due to the new kernel or something else. I will
> >continue to investigate on my end. I do have acpitool, tp-smapi-dkms and
> >tpb installed. Additionally XFCE power manager is set to suspend when the
> >lid is closed and that is no longer working.
> >>
> >> thanks
> >> -ali
> >>
> >>
> >>
> >>
> >> -- System Information:
> >> Debian Release: buster/sid
> >> APT prefers testing
> >> APT policy: (500, 'testing')
> >> Architecture: amd64 (x86_64)
> >>
> >> Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
> >> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> >> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
> >LANGUAGE=en_US.utf8 (charmap=UTF-8)
> >> Shell: /bin/sh linked to /bin/dash
> >
> >Walter Montes
>
>
> Abdullah
>
> https://abdullah.today
>
> C20F 2707 3025 2569 BAC5
> 534B 7820 6670 C19D 1580
>


-- 
Met vriendelijke groeten,



Julian Rutten

Bug#966513: unp: Please make another source-only upload

[Boyuan Yang]

Source: unp
Version: 2.0~pre8
Tags: sid
X-Debbugs-CC: bl...@debian.org

Dear Debian unp maintainer,

The latest upload of package unp was not a source-only upload. As a result,
this package will not migrate to Debian Testing.

Please consider making another source-only upload to fix this problem and have
the package migrated to testing. For details about source-only upload, please
read https://wiki.debian.org/SourceOnlyUpload .

-- 
Thanks,
Boyuan Yang


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

Bug#966451: cloud.debian.org: systemd-growfs@-.service fails on arm64 instance types

[Noah Meyerhans]

On Wed, Jul 29, 2020 at 08:04:54AM +0200, Bastian Blank wrote:
> | # /run/systemd/generator/systemd-growfs@-.service
> | # Automatically generated by systemd-fstab-generator
> | 
> | [Unit]
> | BindsTo=%i.mount
> | After=%i.mount
> | Before=shutdown.target local-fs.target
> 
> So it is an artefact of Debian being the only distro still starting the
> real system with a read-only / (and with that making using first-boot
> mode impossible).

This is a systemd upstream issue, fixed in 244.1.  See
https://github.com/systemd/systemd/issues/14603 and the corresponding
fix in
https://github.com/systemd/systemd/commit/18e6e8635f06ac8d935ed5494ea65c6dac6af90f

The easiest solution for us would be to ship a drop-in configuration
fragment to supply the missing dependency.  I've opened a merge request
to do this at
https://salsa.debian.org/cloud-team/debian-cloud-images/-/merge_requests/213

A more complete solution would be to ask the systemd maintainers to
backport the above commit to buster, but it's too late to get that
change into the upcoming point release (10.5).  With that in mind, I
propose that we ship the drop-in now, and pursue the systemd fix for
buster 10.6.  If we get the systemd fix, we can stop shipping the
drop-in.

noah

Bug#903643: ITP: baconqrcode / Re: Bug#903643: (no subject)

[Joost van Baal-Ilić]

Hi William,

On Wed, Jul 29, 2020 at 06:40:30PM +0200, William Desportes wrote:
> 
> I intend to take this one since it is still waiting, 

Great!

> let me know if you still want to work on it.

Not really, actually.

The maintainer of the eduvpn suite decided to drop the baconqrcode dependency,
mainly because of https://github.com/Bacon/BaconQrCode/issues/70 .  Some old
packaging effort for BaconQrCode 1.0.3 is still available from
https://github.com/eduvpn/eduvpn-debian/tree/buster/BaconQrCode/debian , it
might be useful for packaging 2.x.

Happy Hacking, Bye,

Joost

Bug#966314: bepasty: Please provide an example uwsgi config

[valhalla]

On 2020-07-26 at 12:18:43 -0400, James Valleroy wrote:
> I would like to add bepasty as an app in FreedomBox. For this purpose,
> it would be nice to have an example ini configuration file for
> uwsgi. In FreedomBox, we are already running uwsgi behind apache2
> reverse proxy for searx and radicale apps.

I've added an example configuration to the repository:

https://salsa.debian.org/python-team/applications/bepasty/-/blob/debian/master/debian/examples/bepasty-uwsgi.conf.example

I'm using it with nginx and lighttpd, not apache; I don't expect that to
be an issue, but I can't exclude it; please let me know if it's working
for you.

How urgently to you need this in an uploaded package? I don't have plans
for an upload soon (unless upstream releases a new version, of course),
so if you need this example in the package for it to be useful I can do
one with just this change.

-- 
Elena ``of Valhalla''


signature.asc
Description: PGP signature

Bug#925992: upgrade-reports: Suspend no longer working on Thinkpad X1 Carbon after "dist-upgrade" yesterday

[Abdullah]

I'm running Arch Linux right now and have no problems with X1 Carbon on 
suspension.


On 29/07, Walter Montes wrote:

Hi there,

I have excatly the same issue after installing Ubuntu 20.04 in my Thinkpad
Helix. With Ubuntu 18.04 I had no problems ...
Could you fix that?
This could help:
https://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg5512720.html

But if you have a better solution, please let me know

On Fri, 29 Mar 2019 14:46:59 -0700 Ali Sayed  wrote:

Package: upgrade-reports
Severity: normal

Dear Maintainer,


After running "apt get dist-upgrade" and upgrading to

vmlinuz-4.19.0-4-amd64 I noticed that I can no longer suspend my laptop
either by closing the lid or manually. This used to work before the
upgrade. I also noticed that the touchpad was no longer working with my
XFCE desktop.


Upon further investigation I noticed the synaptics touchpad driver was

missing so I installed the package xserver-xorg-input-synaptics and
rebooted my system. I was able to Suspend once right after the reboot but
then it no longer works. also the tocuhpad worked right after the reboot
but not after my repeated attempts to suspend.


Here is out from "dmesg"

[27361.594572] PM: suspend entry (s2idle)
[27361.594573] PM: Syncing filesystems ... done.
[27361.613865] Freezing user space processes ... (elapsed 0.001 seconds)

done.

[27361.615612] OOM killer disabled.
[27361.615613] Freezing remaining freezable tasks ... (elapsed 0.001

seconds) done.

[27361.616806] Suspending console(s) (use no_console_suspend to debug)
[27361.620724] rmi4_f01 rmi4-00.fn01: Failed to write sleep mode: -6.
[27361.620727] rmi4_f01 rmi4-00.fn01: Suspend failed with code -6.
[27361.620729] rmi4_physical rmi4-00: Failed to suspend functions: -6
[27361.620733] rmi4_smbus 1-002c: Failed to suspend device: -6
[27361.620740] dpm_run_callback(): rmi_smb_suspend+0x0/0x50 [rmi_smbus]

returns -6

[27361.620743] PM: Device 1-002c failed to suspend: error -6
[27361.657382] PM: Some devices failed to suspend, or early wake event

detected

[27361.915062] OOM killer enabled.
[27361.915064] Restarting tasks ...
[27361.916391] rmi4_physical rmi4-00: rmi_driver_set_irq_bits: Failed to

change enabled interrupts!

[27361.916401] psmouse: probe of serio2 failed with error -1
[27361.916411] done.
[27361.927609] PM: suspend exit
[27362.156899] e1000e: enp0s25 NIC Link is Down
[27362.235054] IPv6: ADDRCONF(NETDEV_UP): enp0s25: link is not ready
[27362.449650] IPv6: ADDRCONF(NETDEV_UP): enp0s25: link is not ready
[27362.514062] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[27362.765765] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[27363.033796] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[27363.094240] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[27366.354289] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[27369.330559] wlp3s0: authenticate with 84:61:a0:66:b3:30


I no longer have the older vmlinuz-4.19.0-2-amd64 kernel on this system

to test if this is a bug due to the new kernel or something else. I will
continue to investigate on my end. I do have acpitool, tp-smapi-dkms and
tpb installed. Additionally XFCE power manager is set to suspend when the
lid is closed and that is no longer working.


thanks
-ali




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

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),

LANGUAGE=en_US.utf8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash


Walter Montes



Abdullah

https://abdullah.today

C20F 2707 3025 2569 BAC5
534B 7820 6670 C19D 1580


signature.asc
Description: PGP signature

Bug#966512: Please update python-cups to 2.0.1

[Didier 'OdyX' Raboud]

Source: python-cups
Version: 1.9.73-3
Severity: normal
X-Debbugs-CC: Till Kamppeter , 
debian-print...@lists.debian.org

Submitting this as a proper bug to keep track.

Jérôme: anything I could do from the Printing Team to help?

Le mercredi, 13 mai 2020, 11.41:40 h CEST Till Kamppeter a écrit :
> please update python-cups to 2.0.1 as it contains a fix for a crasher
> with system0-config-printer.
> 
> original Ubuntu bug report:
> 
> https://bugs.launchpad.net/system-config-printer/+bug/1867480
> 
> Forwarded upstream:
> 
> https://github.com/OpenPrinting/system-config-printer/issues/176
> 
> Upstream author's comment on python-cups:
> 
> https://github.com/OpenPrinting/system-config-printer/issues/176#issuecommen
> t-627738281
> 
> Could you update the Debian package so that it syncs into Ubuntu? Thanks.
> 
> Till


-- 
OdyX

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

Bug#966511: fig2dev: "fig2dev -L mmp" reports that mmp-language (multi-meta-post) would be unknown

[Daniel Jung]

Package: fig2dev
Version: 1:3.2.7a-5+deb10u3
Severity: normal

Dear Maintainer,

I need fig2dev for mmp-files. The bug is described in the subject.

yours,
Daniel


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

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

Versions of packages fig2dev depends on:
ii  gawk 1:4.2.1+dfsg-1
ii  ghostscript  9.27~dfsg-2+deb10u3
ii  libc62.28-10
ii  libpng16-16  1.6.36-6
ii  libxpm4  1:3.5.12-1
ii  netpbm   2:10.0-15.3+b2
ii  x11-common   1:7.7+19

fig2dev recommends no packages.

Versions of packages fig2dev suggests:
pn  xfig  

-- no debconf information

Bug#965144: ipp-usb replaces ippusbxd; remove?

[Didier 'OdyX' Raboud]

Le vendredi, 17 juillet 2020, 13.40:26 h CEST Till Kamppeter a écrit :
> On 17/07/2020 12:54, Brian Potkin wrote:
> > I am very much attracted by the idea of a USB connected printer becoming
> > immediately available when it is plugged in, so a Recommends: ipp-usb
> > would be ok with me.
> 
> Yes, I would very much like this, too, for Ubuntu into which both CUPS
> and ipp-usb get synced.

You might have seen that I uploaded CUPS with a Recommends: ipp-usb in cups-
daemon.

Le jeudi, 23 juillet 2020, 20.52:47 h CEST Brian Potkin a écrit :
> On Fri 17 Jul 2020 at 18:21:21 +0100, Brian Potkin wrote:
> > I have started on planning a revision of the IPP-over-USB content on the
> > wiki. Much of what you wrote (and I have snipped) is part of the plan's
> > outline. However, it has helped to focus my mind. Thank you very much for
> > the input. I hope to have something in place during this coming week.
> 
> The IPP-over-USB content at
> 
>   https://wiki.debian.org/CUPSDriverlessPrinting
> 
> has been revised. There will be changes to it as developments occur. I also
> intend altering SaneOverNetwork (to be linked to from DriverlessPrinting)
> to take account of recent driverless scanning initiatives. This will happen
> when the integration of libsane1 into unstable takes place.
 
Great; thanks a lot for your continued, consistent and persistent 
documentation work!

-- 
OdyX

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

Bug#962307: RFS: anymeal/1.5-1 [ITA] -- Cookbook database for storing recipes

[Boyuan Yang]

Hi,

On Sun, 26 Jul 2020 22:58:16 +0100 (BST) Jan Wedekind  wrote:
> Hi,
> I have now released version 1.5. It is available here:
> 
>  https://mentors.debian.net/package/anymeal
> 
> Also it can be downloaded as follows:
> 
>  dget -x 
https://mentors.debian.net/debian/pool/main/a/anymeal/anymeal_1.5-1.dsc

Please fix the following issues before we proceed:

1. It looks like your package has nothing to do with KDE. As a result, please
do not use "Section: kde" in debian/control file. Maybe we can use "Section:
utils".

2. Please also document the copyright holder information and different license
information for files under m4/ directory, epecially ax_have_qt.m4 and
ax_lib_sqlite3.m4.

3. Please clean up debian/changelog file and drop all past changelog entries
that never existed in Debian. (They never existed in the past and they won't
exist in the future so they should not appear anyway.) See 
https://tracker.debian.org/pkg/anymeal for the history of package anymeal in
Debian.

4. Can you explain the reason of overriding dh_auto_install in debian/rules
directory? If you are using Autotools buildsystem correctly, you should not do
override at all and the package will build successfully without human
intervention.

The problem 1), 2) and 3) should be fixed and you can feel free to investigate
into 4) if you are willing to. Let me know after those issues are solved.

--
Regards,
Boyuan Yang


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

Bug#966510: gnome-boxes: guest gets no Internet if host connects through VLAN

[Roman Riabenko]

Package: gnome-boxes
Version: 3.36.5-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
Create a virtual machine with gnome-boxes on a laptop.
Gnome-boxes configures Internet connection for the guest automatically.
Move laptop to a network which is configured with VLAN tagging.
The guest OS gets no Internet connection.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
If the host has connection from VLAN-tagged network and a different
network at the same time, the guest OS gets Intrenet connection.

I tried connecting to different networks (Ethernet, WiFi, Buletooth).
The guest OS gets Internet all the time, except for this one network,
which the administrator told me is VLAN-configured to separate
the guest WiFi network from the office internal network.

I tried Windows 10 and Debian guests with the same result.

It was suggested to me that VLAN may drop frames from the VM
because VM has different MAC address. I wanted to look into
ebtables whether i can use ebtables to change the MAC, but gave up
for now.

   * What was the outcome of this action?
The guest OS gets no Internet on one network, 
which the adminstrator said me is VLAN-tagging traffic.
I perceive it as gnome-boxes suddenly not working because
I rely on gnome-boxes to configure the guest OS connection.

   * What outcome did you expect instead?
I expected gnome-boxes to "just work" and make the VM traffic appear
coming from the host, so it is treated the same as the host traffic.
I belive it comes within the scope of gnome-boxes to make configuration
easy for the end user.

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


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

Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND
Locale: LANG=uk_UA.UTF-8, LC_CTYPE=uk_UA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-boxes depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
ii  genisoimage  9:1.1.11-3.1
ii  libarchive13 3.4.3-1+b1
ii  libc62.31-2
ii  libcairo21.16.0-4
ii  libfreerdp2-22.1.2+dfsg1-2
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-5
ii  libglib2.0-0 2.64.4-1
ii  libgtk-3-0   3.24.20-1
ii  libgtk-vnc-2.0-0 1.0.0-1
ii  libgudev-1.0-0   233-1
ii  libosinfo-1.0-0  1.7.1-1
ii  libosinfo-bin1.7.1-1
ii  libpango-1.0-0   1.44.7-4
ii  libsecret-1-00.20.3-1
ii  libsoup2.4-1 2.70.0-1
ii  libspice-client-glib-2.0-8   0.38-2
ii  libspice-client-gtk-3.0-50.38-2
ii  libtracker-sparql-2.0-0  2.3.4-1+b1
ii  libusb-1.0-0 2:1.0.23-2
ii  libvirt-daemon   6.4.0-2
ii  libvirt-glib-1.0-0   3.0.0-1
ii  libvte-2.91-00.60.3-1
ii  libwebkit2gtk-4.0-37 2.28.3-2
ii  libwinpr2-2  2.1.2+dfsg1-2
ii  libxml2  2.9.10+dfsg-5+b1
ii  tracker  2.3.4-1+b1

Versions of packages gnome-boxes recommends:
ii  qemu-system-x86  1:5.0-13

gnome-boxes suggests no packages.

-- no debconf information

Bug#966415: RFS: pixz/1.0.7-1 -- parallel, indexing XZ compressor/decompressor

[Leon Marz]

I've updated the package on mentors.debian.net with the new vcs fields. 
Thank you very much for helping me.

- Leon

Bug#963225: ITP: prince-of-persia -- SDL port of the classic Prince of Persia game

[Kees Cook]

Hi Ben,

On Mon, Jun 22, 2020 at 01:53:09PM +0100, Ben Hutchings wrote:
> On Sat, 2020-06-20 at 16:38 -0700, Kees Cook wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Kees Cook 
> > 
> > * Package name: prince-of-persia
> >   Version : 1.20
> >   Upstream Author : Dávid Nagy
> > * URL : https://github.com/NagyD/SDLPoP
> > * License : GPL-3+
> 
> I don't see how this is possible.

Why not? There have been all kinds of ports (JS, Roku, etc), and this
one was done explicitly GPL from the start.

> 
> >   Programming Lang: C
> >   Description : SDL port of the classic Prince of Persia game
> [...]
> 
> So this is a derivative work of Prince of Persia (the DOS version
> apparently), isn't it?

It is a reimplementation based on reverse engineering of the DOS binaries.

-- 
Kees Cook@debian.org

Bug#776951: (no subject)

[Helge Deller]

Thanks, this patch has been applied to the new upstream version:
https://git.kernel.org/pub/scm/linux/kernel/git/deller/rbootd.git/

Bug#966509: geeqie: can not start due to clutter-gtk init failure

[Eugene Berdnikov]

Package: geeqie
Version: 1:1.5.1+git20200723-2
Severity: important

Dear Maintainers,


% geeqie

(geeqie:28868): Clutter-CRITICAL **: 19:45:09.437: Unable to initialize 
Clutter: Unable to initialize the Clutter backend: no available drivers found.
Can't initialize clutter-gtk.


Problem was found after upgrade from 1.5.1-11:

2020-07-29 17:13:18 upgrade geeqie:amd64 1:1.5.1-11 1:1.5.1+git20200723-2
2020-07-29 17:13:19 upgrade geeqie-common:all 1:1.5.1-11 1:1.5.1+git20200723-2

In ~/.config/geeqie/geeqierc.xml clutter is turned OFF:
image.use_clutter_renderer = "false" 


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

Kernel: Linux 4.17.0-1-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages geeqie depends on:
ii  geeqie-common1:1.5.1+git20200723-2
ii  libc62.30-4
ii  libcairo21.16.0-4
ii  libchamplain-0.12-0  0.12.20-1
ii  libchamplain-gtk-0.12-0  0.12.20-1
ii  libclutter-1.0-0 1.26.4+dfsg-1
ii  libclutter-gtk-1.0-0 1.8.4-4
ii  libcogl201.22.8-1
ii  libdjvulibre21   3.5.27.1-15
ii  libexiv2-27  0.27.2-8
ii  libffmpegthumbnailer4v5  1:2.2.2-dmo1
ii  libgcc-s110.1.0-1
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-5
ii  libglib2.0-0 2.64.4-1
ii  libgtk-3-0   3.24.20-1
ii  libheif1 1.6.1-1+b1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-4+b1
ii  liblirc-client0  0.10.1-6.2
ii  liblua5.1-0  5.1.5-8.1+b3
ii  libopenjp2-7 2.3.1-1
ii  libpango-1.0-0   1.44.7-4
ii  libpangocairo-1.0-0  1.44.7-4
ii  libpoppler-glib8 0.71.0-6
ii  libstdc++6   10.1.0-1
ii  libtiff5 4.1.0+git191117-2
ii  libwebp6 0.6.1-2+b1
ii  libx11-6 2:1.6.9-2+b1
ii  sensible-utils   0.0.12+nmu1

Versions of packages geeqie recommends:
pn  cups-bsd | lpr   
pn  exiftran 
pn  exiv2
ii  imagemagick  8:6.9.10.23+dfsg-2.1+b2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1+b2
ii  librsvg2-common  2.48.7-1
pn  ufraw-batch  
pn  zenity   

Versions of packages geeqie suggests:
pn  geeqie-dbg 
pn  gimp   
pn  libjpeg-progs  
pn  ufraw  
ii  xpaint 2.9.1.4-3.2+b1

-- no debconf information

-- 
 Eugene Berdnikov

Bug#903643: (no subject)

[William Desportes]

Hi,

I intend to take this one since it is still waiting, let me know if you
still want to work on it.


Regards,

William Desportes





signature.asc
Description: OpenPGP digital signature

Bug#966500: python3-notcurses: missing Breaks+Replaces: notcurses-bin (<< 1.6)

[Nick Black]

pending
thanks

ok, I believe i have solved this. the problem arose when i moved
notcurses-pydemo from notcurses-bin to python3-notcurses
sometime since 1.5.1. so:

 * i've added the necessary Breaks+Replace to debian/control,
   and have built this as 1.6.9+dfsg.1-3. it ought remedy the
   reported problem. i have made them available at:

   https://www.dsscaw.com/repos/apt/debian/pool/main/n/notcurses/

i'll almost certainly be cutting 1.6.10 today or tomorrow, so
i'm inclined to wait until then, and get this all into one
release (especially since I can't yet upload my own packages,
and must harass my Sponsor to do so). if a DD would like to
upload the 1.6.9+dfsg.1-3 packages i've prepared before then,
email me, and we can do that.

Andreas, if a fix tomorrow or the next day isn't fast enough,
let me know and I can push on the 1.6.9+dfsg.1-3. thanks!

Bug#957532: mes: ftbfs with GCC-10

[Vagrant Cascadian]

On 2020-07-27, Vagrant Cascadian wrote:
> Debian has switched to gcc 10 by default for the development releases,
> and that currently breaks building mes.

Apparently, Adding -fcommon to CFLAGS does allow the build to complete.

from https://gcc.gnu.org/gcc-10/porting_to.html:

  C language issues
  Default to -fno-common

  A common mistake in C is omitting extern when declaring a global
  variable in a header file. If the header is included by several files
  it results in multiple definitions of the same variable. In previous
  GCC versions this error is ignored. GCC 10 defaults to -fno-common,
  which means a linker error will now be reported. To fix this, use
  extern in header files when declaring global variables, and ensure
  each global is defined in exactly one C file. If tentative definitions
  of particular variables need to be placed in a common block,
  __attribute__((__common__)) can be used to force that behavior even in
  code compiled without -fcommon. As a workaround, legacy C code where
  all tentative definitions should be placed into a common block can be
  compiled with -fcommon.


I'm thinking it's appropriate for mes to use -fcommon in this case,
since it uses it's own headers and libc.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#966313: lxterminal: Setting "Select by word characters" has no effect

[Ian Zimmerman]

I looked at the code, and the only thing lxterminal does with this
setting is to pass it down through a vte_* function. Therefore this
bug should probably be reassigned to the libvte package.

Ian

Bug#618413: URGENT RESPONSE

[jan king]

Sir / Madam,

Hi Friend I am the accountant and auditing manager of the
International Finance Bank Plc bf I want to transfer an abandoned sum
of 10.5 millions USD  to your account.50% will be for you. No risk
involved. Contact me for more details.

Kindly reply me back to my alternative email address (kingjan...@gmail.com)

Thanks
Prince King Jan.

Bug#966499: unicode-cldr-core: Please generate JSON data file also

[James Valleroy]

Package: unicode-cldr-core
Severity: wishlist
X-Debbugs-Cc: jvalle...@mailbox.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

Please consider generating JSON data files from the XML files in this
package. The JSON files could be part of the same binary package, or a
separate package like unicode-cldr-core-json.

This was suggested in ITP #965209 as a way to avoid embedding the JSON
data in php-gettext-languages package.

-BEGIN PGP SIGNATURE-

iQJKBAEBCgA0FiEEfWrbdQ+RCFWJSEvmd8DHXntlCAgFAl8haHwWHGp2YWxsZXJv
eUBtYWlsYm94Lm9yZwAKCRB3wMdee2UICE/zD/9KAqLCeXBsJyueA41nxTbHFvxQ
b9+oWYlbp1dPccdfBBdjdzmDw2Wn9m8jb+DFNv5vYK0KsOPNp1mdnV1tixHHJEwr
Q/GtM6fZmmkr/8+O/KSffmo8i2PCwLqWEDMGIbis1K+ZrdQKnEV71qzfWhAJaYyR
tkR3tAadQuE5h5CNLk1bEEVvTRCcZ7PTabTfAFg1kdUa6hoevFx1ANml2PMCqy7n
lwlQjcy56sIMsreEdiZdYYyoyVYi2zGUjHJ365GuiZT4IS8JACPlLFIpMInXBxJx
oaP4V1tt2r9e8pmtDfA5UfzJsEJcPuhXGilC5oJJT1a3x8lIl0Yw/I+uXof2P3Mv
sINV/JUod0k2441GgLznP65czDhySXaKRomAOLyULYAzmQxpATWzQlEbbDLv50iI
kgiJVt4tRDHtkATi5/T0gVgtl+1ahgHqhW5jV2neIK3WvCybOfrDarNwX/pR+Adq
pzQ7z2+S5y8VQx1FDVxFBIdET5IUS2Ef39MAV6T/Fbqbbf11Mb856IeqDihTXUgq
kKqbWsWu11WlKixVU9wKP42MVjw+wOHVrKQvEdsqOnRpV+IlgenMj65K0rr18M8x
iz3vXDyCm7jAo8Ynf4RDF+rxtOk2lBiwHEAUPuDlw07znweJ8NaYMLqgXSFZnKxJ
VxDr3BaezsE+Ignymg==
=9y+8
-END PGP SIGNATURE-

Bug#966093: Error: default OCI runtime "runc" not found: invalid argument -Workaround for wrong regular-user defaults

[Lorenzo M. Catucci]

Package: podman
Version: 2.0.3+dfsg1-1
Followup-For: Bug #966093

Dear Robby and Maintainer,

to avoid the described failure in running podman *as a regular user*, it's
enough to execute the command:

$ echo 'runtime = "crun"' > ~/.config/containers/libpod.conf

afterwards, both

$ podman info

and

$ podman run -it debian:sid

work correctly.

As a side note, I think a note about the need for sysctl
kernel.unprivileged_userns_clone=1 should be present also in podman's
README.Debian, and not only in buildah's



-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (777, 'testing'), (666, 'stable'), (333, 'oldstable'), (222, 
'unstable'), (1, 'experimental')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.7.0-1-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages podman depends on:
ii conmon 2.0.9-1
ii containernetworking-plugins 0.8.6-2
ii crun 0.14.1+dfsg-1
ii init-system-helpers 1.58
ii libc6 2.31-2
ii libdevmapper1.02.1 2:1.02.167-1+b1
ii libgpgme11 1.13.1-9
ii libseccomp2 2.4.3-1+b1

Versions of packages podman recommends:
ii buildah 1.15.0-4
ii fuse-overlayfs 1.0.0-1
ii slirp4netns 1.0.1-1
ii tini 0.18.0-1+b1
ii uidmap 1:4.8.1-1

Versions of packages podman suggests:
ii containers-storage 1.21.2+dfsg1-1

Bug#966093: Error: default OCI runtime "runc" not found: invalid argument - Workaround

[Lorenzo M. Catucci]

Package: podman
Version: 2.0.3+dfsg1-1
Followup-For: Bug #966093

Dear Robby and Maintainer,

while I can confirm `podman` doesn't correctly execute the `crun` runtime when
started from a regular user, after executing the following command from the
user's shell:

  $ echo 'runtime = "crun"' >  ~/.config/containers/libpod.conf

both

  $ podman info

and the suggested

  $ podman run -it debian:sid

run correctly for a regular user, only if the administrator correctly enabled
the  kernel.unprivileged_userns_clone sysctl via manually running

  $ sudo sysctl -w kernel.unprivileged_userns_clone=1

or setting it in /etc/sysctl.conf or in a /etc/sysctl.d/ snippet (I think this
should be documented also in podman's README.Debian as well as in buildah's)

Thank you all.



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (777, 'testing'), (666, 'stable'), (333, 'oldstable'), (222, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages podman depends on:
ii  conmon   2.0.9-1
ii  containernetworking-plugins  0.8.6-2
ii  crun 0.14.1+dfsg-1
ii  init-system-helpers  1.58
ii  libc62.31-2
ii  libdevmapper1.02.1   2:1.02.167-1+b1
ii  libgpgme11   1.13.1-9
ii  libseccomp2  2.4.3-1+b1
ii  runc 1.0.0~rc10+dfsg2-1

Versions of packages podman recommends:
ii  buildah 1.15.0-4
ii  fuse-overlayfs  1.0.0-1
ii  slirp4netns 1.0.1-1
ii  tini0.18.0-1+b1
ii  uidmap  1:4.8.1-1

Versions of packages podman suggests:
ii  containers-storage  1.21.2+dfsg1-1

-- debconf-show failed

Bug#966506: ITP: raku-getopt-long -- A powerful getopt implementation for Raku

[Dominique Dumont]

Package: wnpp
Owner: Dominique Dumont 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-rakudo-de...@lists.alioth.debian.org

* Package name: raku-getopt-long
  Version : 0.1.6-1~1.gbp99eaf4
  Upstream Author : Leon Timmermans 
* URL : https://github.com/perl6/getopt-long6
* License : Artistic-2.0
  Programming Lang: Raku
  Description : A powerful getopt implementation for Raku

The Getopt::Long module implements extended getopt functions called get-
options() and get-options-from, as well as automatic argument parsing
for a MAIN sub.

This function adheres to the POSIX syntax for command line options, with
GNU extensions. In general, this means that options have long names
instead of single letters, and are introduced with a double dash "--".
Support for bundling of command line options, as was the case with the
more traditional single-letter approach, is also provided.

Bug#966415: RFS: pixz/1.0.7-1 -- parallel, indexing XZ compressor/decompressor

[Roger Shimizu]

Dear Leon,

Git repo created on salsa, with your account as maintainer:
- https://salsa.debian.org/debian/pixz

I also find one with some old gits, maybe you can create from that:
- https://salsa.debian.org/bremner/pixz
Usually I do such task by:
  gbp import-dscs --debsnap --author-is-committer
--author-date-is-committer-date --create-missing-branches

Good luck!

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#966507: ITP: prove6 -- test runner based on TAP harness

[Dominique Dumont]

Package: wnpp
Owner: Dominique Dumont 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-rakudo-de...@lists.alioth.debian.org

* Package name: prove6
  Version : 0.0.12-1~1.gbp4f786b
  Upstream Author : Leon Timmermans 
* URL : https://github.com/Leont/app-prove6
* License : Artistic-2.0
  Programming Lang: Raku
  Description : test runner based on TAP harness

prove6 is an implementation in Raku language of Perl's prove command.

This command runs a set of test through a TAP harness

Bug#966422: bind9utils: dnssec-signzone -N unixtime behaves like increment

[Sven Strickroth]

> Please report this upstream at
> https://gitlab.isc.org/isc-projects/bind9/-/issues . When you have a
> bugid feel free to report back to we can tag this bug accordingly.

Reported upstream: 

Best,
 Sven

Bug#965018: RFS: freetype-py/2.2.0-1 -- Freetype Python bindings for Python 3

[mattia]

On Wed, Jul 29, 2020 at 11:09:37AM +0200, Bastian Germann wrote:
> The python3-setuptools-scm build dependency could not be installed in
> your environment which causes setuptools to try download this package.
> That obviously fails.
> 
> Shouldn't pdebuild make sure that all the build dependencies are installed?

You are both confusing pdebuild with pbuilder here.

That's the `clean` step that is failing, which is done outside of the
chroot.  That's responsability of whoever is calling `pdebuild` to
satisfy.

If you are sure your source is clean you may as well just skip cleaning
and not use pdebuild:
dpkg-source -b .
dpkg-source --after-build .
pbuilder b ../freetype-py_2.2.0-1.dsc
the above sequence should prove that nothing is at fault here.

-- 
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#914840: umockdev FTBFS on hppa architecture

[Martin Pitt]

Version: 0.13-1

Helge Deller [2018-11-27 21:40 +0100]:
> umockdev fails to build quite often on the hppa architecture, as can be seen 
> here:
> https://buildd.debian.org/status/logs.php?pkg=umockdev=hppa
> 
> I did some testing, and I think it fails because of timing issues.
> Attached trivial patch (which increases the delay time) seems to fix it.
> 
> So, can you please include the attached patch (or another one which increases 
> the timeout)
> in the next upload?
> 
> Thanks,
> Helge

> diff -up ./tests/test-umockdev.c.org ./tests/test-umockdev.c
> --- ./tests/test-umockdev.c.org   2018-11-27 21:20:00.375030350 +0100
> +++ ./tests/test-umockdev.c   2018-11-27 21:20:06.079035516 +0100
> @@ -1691,7 +1691,7 @@ r 10 ^@response\n";
>  
>/* should get initial greeting after 200 ms */
>ASSERT_EOF;
> -  usleep(22);
> +  usleep(22*2);
>g_assert_cmpint(read(fd, buf, 5), ==, 5);
>g_assert(strncmp(buf, "ready", 5) == 0);
>g_assert_cmpint(errno, ==, 0);

This patch landed in upstream release 0.13 two years ago.

The recent failures are something else (#767908) and will be fixed in 0.14.2.

Martin

Bug#966505: dnsmasq: machine-readable copyright file

[Andrej Shadura]

Package: src:dnsmasq
Severity: wishlist

Dear Maintainer,

While performing license review of Apertis, a Debian derivative, we
prepared a machine-readable version of the copyright file. The copyright
years may not be exact, please edit according to your knowledge if you
find it necessary.

-- 
Cheers,
  Andrej
Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Source: http://www.thekelleys.org.uk/dnsmasq/

Files: *
Copyright: 2000-2020 Simon Kelley
License: GPL-2 or GPL-3
Comment:
 This program is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
 the Free Software Foundation; version 2 dated June, 1991, or
 (at your option) version 3 dated 29 June, 2007.
 .
 This program is distributed in the hope that it will be useful,
 but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 GNU General Public License for more details.

Files: bld/bloat-o-meter
Copyright: 2004 Matt Mackall 
License: GPL-2 or GPL-3

Files: contrib/dnslist/dnslist.pl
Copyright: 2004 Thomas Tuttle
License: GPL-2+

Files: contrib/dynamic-dnsmasq/*
Copyright: 2004 Peter Willis
License: GPL-2+

Files:
 contrib/lease-tools/dhcp_lease_time.c
 contrib/lease-tools/dhcp_release.c
Copyright: 2006, 2007 Simon Kelley
License: GPL-2

Files: contrib/webmin/dnsmasq.wbm
Copyright: 2006 Neil Fisher 
License: GPL-2+

Files: contrib/wrt/lease_update.sh
Copyright: 2000-2018 Simon Kelley
License: GPL-2

Files: debian/*
Copyright:
 1994, 1995 Ian Jackson
 2001-2020 Simon Kelley
License: GPL-2 or GPL-3
Comment:
 The Debian package of dnsmasq was created by Simon Kelley
 with assistance from Lars Bahner.

Files:
 logo/favicon.ico
 logo/icon.png
 logo/icon.svg
Copyright: 2010 Justin Clift
License: GPL-2 or GPL-3

Files: src/dnssec.c
Copyright:
 2012-2018 Simon Kelley
 2012 Giovanni Bajo 
License: GPL-2 or GPL-3

Files: src/ipset.c
Copyright: 2013 Jason A. Donenfeld 
License: GPL-2 or GPL-3

Files: src/tables.c
Copyright: 2014 Sven Falempin
License: GPL-2 or GPL-3

License: GPL-2
 On Debian systems, the text of the GNU General Public license
 version 2 is available in the file /usr/share/common-licenses/GPL-2

License: GPL-3
 On Debian systems, the text of the GNU General Public license
 version 3 is available in the file /usr/share/common-licenses/GPL-3

Bug#966504: emacs-ivy: should suggest not recommend elpa-smex

[Sean Whitton]

Package: emacs-ivy
Version: 0.13.0-1

Hello,

On Fri 24 Jul 2020 at 11:49PM GMT, Debian FTP Masters wrote:

> Changes:
>  emacs-ivy (0.13.0-1) unstable; urgency=medium
>  .
>[...]
>* Add elpa-smex to elpa-counsel's Recommends.  The way it presents one's
>  recently and most frequently used commands at the top of the
>  candidates list is a wonderful productivity-enhancing feature.  See
>  the docs to learn how to use Counsel to enable this for the M-x
>  interface.

Based on your description here, should probably be Suggests: not
Recommends:, given that Recommends: is for packages where it would be
highly unusual not to use ivy with them.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#966408: RFH: libidn

[John Scott]

I'm not a DD and can only send merge requests, and don't know much about 
symbols files, but will try my hand at some of the lower-hanging Debianization 
and Lintian issues.

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

Bug#925992: upgrade-reports: Suspend no longer working on Thinkpad X1 Carbon after "dist-upgrade" yesterday

[Walter Montes]

Hi there,

I have excatly the same issue after installing Ubuntu 20.04 in my Thinkpad
Helix. With Ubuntu 18.04 I had no problems ...
Could you fix that?
This could help:
https://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg5512720.html

But if you have a better solution, please let me know

On Fri, 29 Mar 2019 14:46:59 -0700 Ali Sayed  wrote:
> Package: upgrade-reports
> Severity: normal
>
> Dear Maintainer,
>
>
> After running "apt get dist-upgrade" and upgrading to
vmlinuz-4.19.0-4-amd64 I noticed that I can no longer suspend my laptop
either by closing the lid or manually. This used to work before the
upgrade. I also noticed that the touchpad was no longer working with my
XFCE desktop.
>
> Upon further investigation I noticed the synaptics touchpad driver was
missing so I installed the package xserver-xorg-input-synaptics and
rebooted my system. I was able to Suspend once right after the reboot but
then it no longer works. also the tocuhpad worked right after the reboot
but not after my repeated attempts to suspend.
>
> Here is out from "dmesg"
>
> [27361.594572] PM: suspend entry (s2idle)
> [27361.594573] PM: Syncing filesystems ... done.
> [27361.613865] Freezing user space processes ... (elapsed 0.001 seconds)
done.
> [27361.615612] OOM killer disabled.
> [27361.615613] Freezing remaining freezable tasks ... (elapsed 0.001
seconds) done.
> [27361.616806] Suspending console(s) (use no_console_suspend to debug)
> [27361.620724] rmi4_f01 rmi4-00.fn01: Failed to write sleep mode: -6.
> [27361.620727] rmi4_f01 rmi4-00.fn01: Suspend failed with code -6.
> [27361.620729] rmi4_physical rmi4-00: Failed to suspend functions: -6
> [27361.620733] rmi4_smbus 1-002c: Failed to suspend device: -6
> [27361.620740] dpm_run_callback(): rmi_smb_suspend+0x0/0x50 [rmi_smbus]
returns -6
> [27361.620743] PM: Device 1-002c failed to suspend: error -6
> [27361.657382] PM: Some devices failed to suspend, or early wake event
detected
> [27361.915062] OOM killer enabled.
> [27361.915064] Restarting tasks ...
> [27361.916391] rmi4_physical rmi4-00: rmi_driver_set_irq_bits: Failed to
change enabled interrupts!
> [27361.916401] psmouse: probe of serio2 failed with error -1
> [27361.916411] done.
> [27361.927609] PM: suspend exit
> [27362.156899] e1000e: enp0s25 NIC Link is Down
> [27362.235054] IPv6: ADDRCONF(NETDEV_UP): enp0s25: link is not ready
> [27362.449650] IPv6: ADDRCONF(NETDEV_UP): enp0s25: link is not ready
> [27362.514062] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
> [27362.765765] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
> [27363.033796] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
> [27363.094240] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
> [27366.354289] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
> [27369.330559] wlp3s0: authenticate with 84:61:a0:66:b3:30
>
>
> I no longer have the older vmlinuz-4.19.0-2-amd64 kernel on this system
to test if this is a bug due to the new kernel or something else. I will
continue to investigate on my end. I do have acpitool, tp-smapi-dkms and
tpb installed. Additionally XFCE power manager is set to suspend when the
lid is closed and that is no longer working.
>
> thanks
> -ali
>
>
>
>
> -- System Information:
> Debian Release: buster/sid
> APT prefers testing
> APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
LANGUAGE=en_US.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash

Walter Montes

Bug#966425: include Meson cross files

[John Scott]

On Wednesday, July 29, 2020 6:45:25 AM EDT Jussi Pakkanen wrote:
> Currently debcrossgen is optimized for Debian package building and it works 
> quite well with it.
I'm going on a tangent, but I'd like to understand how debcrossgen is used in 
practice. At the moment it appears one needs to explicitly look for it, with 
it not being in $PATH or documented in README.Debian or README.cross.

Is the intent of debcrossgen, as opposed to just installing ready cross files 
in the system path, so that they can be customized if needed?

I haven't yet had any success finding a package using Meson with satisfiable 
cross-build dependencies to try with, but is Debhelper or dpkg supposed to be 
debcrossgen-aware so something like
sbuild --host=armhf fwupd
just works? Or is debcrossgen more for building in custom build environments 
for now?

> I don't have personal experience with that work flow, so I don't know how
> well these two would tie together (most likely quite well, but you can never 
> tell about these things).
debcrossgen looks like it leverages dpkg which would be no good. I've attached 
the x86_64 MinGW cross file I've personally been using, with some probably 
unnecessary entries (project suggestions to try on are welcome!).

It's more of an upstream Meson issue, but one potential problem is that on 
non-amd64, wine64 won't work, and Meson seems to take exe_wrapper as an 
implicit promise that it is a suitable wrapper. A simple workaround for this 
is to suggest people using the cross file to install wine-binfmt, and omit the 
entry altogether. Being able to test the target binaries is relatively 
unimportant anyway.# Requires Meson 0.55
[constants]
tri = 'x86_64-w64-mingw32'

[binaries]
exe_wrapper = 'wine64'
addr2line =  tri + '-addr2line'
c =  tri + '-gcc'
c++ =tri + '-c++'
cpp =tri + '-cpp'
ar = tri + '-ar'
dlltool =tri + '-dlltool'
gcov =   tri + '-gcov'
gcov-dump = gcov + '-dump'
gcov-tool = gcov + '-tool'
ld = tri + '-ld'
nm = tri + '-nm'
objcopy =tri + '-objcopy'
ranlib = tri + '-ranlib'
readelf =tri + '-readelf'
strip =  tri + '-strip'
pkgconfig =  tri + '-pkg-config'

[properties]
sys_root = '/usr/x86_64-w64-mingw32/'

[host_machine]
system = 'windows'
cpu_family = 'x86'
cpu = 'x86_64'
endian = 'little'


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

Bug#966436: files

[Cédric Boutillier]

Here are the promised files
Image: spec/fixtures/clipping_path.jpg
  Format: JPEG (Joint Photographic Experts Group JFIF format)
  Mime type: image/jpeg
  Class: DirectClass
  Geometry: 200x120+0+0
  Resolution: 72x72
  Print size: 2.8x1.7
  Units: PixelsPerInch
  Colorspace: sRGB
  Type: Palette
  Base type: Undefined
  Endianess: Undefined
  Depth: 8-bit
  Channel depth:
red: 8-bit
green: 8-bit
blue: 8-bit
  Channel statistics:
Pixels: 24000
Red:
  min: 208  (0.815686)
  max: 208 (0.815686)
  mean: 208 (0.815686)
  standard deviation: 0 (0)
  kurtosis: 4.19021e+54
  skewness: 0
  entropy: 0
Green:
  min: 176  (0.690196)
  max: 176 (0.690196)
  mean: 176 (0.690196)
  standard deviation: 0 (0)
  kurtosis: -1.73261e+54
  skewness: 0
  entropy: 0
Blue:
  min: 177  (0.694118)
  max: 177 (0.694118)
  mean: 177 (0.694118)
  standard deviation: 0 (0)
  kurtosis: 1.47046e+54
  skewness: -1.39375e+37
  entropy: 0
  Image statistics:
Overall:
  min: 176  (0.690196)
  max: 208 (0.815686)
  mean: 187 (0.73)
  standard deviation: 0 (0)
  kurtosis: -1.50004
  skewness: 0.70469
  entropy: 0
  Colors: 1
  Histogram:
 24000: (208,176,177) #D0B0B1 srgb(208,176,177)
  Rendering intent: Perceptual
  Gamma: 0.454545
  Chromaticity:
red primary: (0.64,0.33)
green primary: (0.3,0.6)
blue primary: (0.15,0.06)
white point: (0.3127,0.329)
  Background color: white
  Border color: srgb(223,223,223)
  Matte color: grey74
  Transparent color: black
  Interlace: None
  Intensity: Undefined
  Compose: Over
  Page geometry: 200x120+0+0
  Dispose: Undefined
  Iterations: 0
  Compression: JPEG
  Quality: 99
  Orientation: TopLeft
  Properties:
date:create: 2018-03-18T06:54:04+01:00
date:modify: 2018-03-18T06:54:04+01:00
exif:ColorSpace: 1
exif:DateTime: 2016:01:20 19:28:30
exif:ExifOffset: 172
exif:Orientation: 1
exif:PixelXDimension: 200
exif:PixelYDimension: 120
exif:ResolutionUnit: 2
exif:Software: Adobe Photoshop CC 2014 (Macintosh)
exif:thumbnail:Compression: 6
exif:thumbnail:JPEGInterchangeFormat: 310
exif:thumbnail:JPEGInterchangeFormatLength: 814
exif:thumbnail:ResolutionUnit: 2
exif:thumbnail:XResolution: 72/1
exif:thumbnail:YResolution: 72/1
exif:XResolution: 72/1
exif:YResolution: 72/1
icc:copyright: Copyright (c) 1998 Hewlett-Packard Company
icc:description: sRGB IEC61966-2.1
icc:manufacturer: IEC http://www.iec.ch
icc:model: IEC 61966-2.1 Default RGB colour space - sRGB
jpeg:colorspace: 2
jpeg:sampling-factor: 1x1,1x1,1x1
signature: 44f62c0b59893193d132f211e53e1d4fc8d92b27d5699d1ccdb340c97f9e6d12
  Clipping path: 

http://www.w3.org/2000/svg; width="200" height="120">





  Profiles:
Profile-8bim: 3720 bytes
Profile-exif: 1130 bytes
Profile-icc: 3144 bytes
Profile-xmp: 4273 bytes
  Artifacts:
filename: spec/fixtures/clipping_path.jpg
verbose: true
  Tainted: False
  Filesize: 14616B
  Number pixels: 24000
  Pixels per second: 2.4MB
  User time: 0.010u
  Elapsed time: 0:01.009
  Version: ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
Image:
  Filename: spec/fixtures/clipping_path.jpg
  Format: JPEG (Joint Photographic Experts Group JFIF format)
  Mime type: image/jpeg
  Class: DirectClass
  Geometry: 200x120+0+0
  Resolution: 72x72
  Print size: 2.8x1.7
  Units: PixelsPerInch
  Colorspace: sRGB
  Type: Palette
  Base type: Undefined
  Endianness: Undefined
  Depth: 8-bit
  Channel depth:
red: 8-bit
green: 8-bit
blue: 8-bit
  Channel statistics:
Pixels: 24000
Red:
  min: 208  (0.815686)
  max: 208 (0.815686)
  mean: 208 (0.815686)
  standard deviation: 0 (0)
  kurtosis: 4.19021e+54
  skewness: 0
  entropy: 0
Green:
  min: 176  (0.690196)
  max: 176 (0.690196)
  mean: 176 (0.690196)
  standard deviation: 0 (0)
  kurtosis: -1.73261e+54
  skewness: 0
  entropy: 0
Blue:
  min: 177  (0.694118)
  max: 177 (0.694118)
  mean: 177 (0.694118)
  standard deviation: 0 (0)
  kurtosis: 1.47046e+54
  skewness: -1.39375e+37
  entropy: 0
  Image statistics:
Overall:
  min: 176  (0.690196)
  max: 208 (0.815686)
  mean: 187 (0.73)
  standard deviation: 0 (0)
  kurtosis: -1.50004
  skewness: 0.70469
  entropy: 0
  Colors: 1
  Histogram:
24000: (208,176,177) #D0B0B1 srgb(208,176,177)
  Rendering intent: Perceptual
  Gamma: 0.454545
  Chromaticity:
red primary: (0.64,0.33)
green primary: (0.3,0.6)
blue primary: (0.15,0.06)
white point: (0.3127,0.329)
  Background color: white
  Border color: srgb(223,223,223)
  Matte color: grey74
  Transparent color: black
  Interlace: None
  Intensity: Undefined
  Compose: Over
  Page geometry: 200x120+0+0
  

Bug#966436: reassign to imagemagick 8:6.9.11.24+dfsg-1

[Cédric Boutillier]

reassign 966436 src:imagemagick
found 966436 8:6.9.11.24+dfsg-1n
retitle scrambled property in identify -verbose output
affects 966436 ruby-mini-magick
thanks


ruby-mini-magick relies (too) heavily on a parsing of output of
imagemagick tools like identify.
The issue discussed here is caused by a change in the output of the
`identify -verbose` command from the version in testing
(8:6.9.10.23+dfsg-2.1+b2) and unstable (8:6.9.11.24+dfsg-1).

Attached are the corresponding outputs of the above command on the file
from ruby-mini-magick specs (spec/fixtures/clipping_path.jpg).

In the "unstable" version, the field Properties: has first subfield (on
line 96) with a strange name, which makes regexp filtering from
ruby-mini-magick choke. The content seems to be the same as the
"Clipping path:" field.

This subfield does not appear in the version of testing.

It is mentionned as a warning on newer versions of ruby-mini-magick that
the `details` method reading the output of `identify -verbose` in a
specific way, has become unreliable for newer versions of ImageMagick.
I am therefore disabling the corresping test in that code.

However, I believe that the output of identify -verbose should not
contain such cryptic field names, therefore, I am reassigning the but to
imagemagick package.

Thanks,

Cédric





signature.asc
Description: PGP signature

Bug#966498: libgd-perl: Dropped libgd-gd2-perl breaks a Recommends in lcov and prevents a clean upgrade

[gregor herrmann]

Control: forcemerge -1 966365
Control: severity -1 serious
Control: found -1 libgd-perl 2.72-1
Control: tag -1 + sid bullseye confirmed
Control: affects -1 + circos gbrowse ircmarkers libbio-graphics-perl 
libcatalyst-view-gd-perl libchado-perl libchart-strip-perl libgd-svg-perl 
libtemplate-plugin-gd-perl libtest-image-gd-perl lightsquid otrs2 shanty


On Wed, 29 Jul 2020 14:05:43 +0200, Vincent Lefevre wrote:

> libgd-perl (2.72-1) unstable; urgency=medium
> [...]
>   * Drop ancient Breakes/Replaces/Provides on libgd-gd2-{,noxpm-}perl.
> [...]
>  -- gregor herrmann   Wed, 22 Jul 2020 19:58:57 +0200
> 
> libgd-gd2-perl is not ancient. It is still used by lcov at least:

Well, depends on the definition of "ancient".

The breaks/replaces/provides were added to libgd-perl in 2013
https://tracker.debian.org/media/packages/libg/libgd-perl/changelog-2.72-1 ;
libgd-gd2-perl and libgd-gd2-noxpm-perl were removed from testing at that time, 
and from the archive in 2014:
https://tracker.debian.org/pkg/libgd-gd2-perl
https://tracker.debian.org/pkg/libgd-gd2-noxpm-perl

But yes, there are at least 13 package still depending in the removed
real or virtual packages, according to
https://qa.debian.org/excuses.php?package=libgd-perl

And I'm sorry for missing these reverse dependencies. Obviously my
methodology was not good enough:

% reverse-depends libgd-gd2-noxpm-perl
b'Package not published in specified release'

% apt-cache rdepends libgd-gd2-noxpm-perl



Anyway, I'll add the Breaks/Replaces/Provides back and file bugs
against the reverse dependencies.
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Beatles: While My Guitar Gently Weeps


signature.asc
Description: Digital Signature

Bug#966503: raspi-firmware: /etc/kernel/postinst.d/z50-raspi-firmware should deal with compressed kernels

[Lucas Nussbaum]

Package: raspi-firmware
Version: 1.20200212-1

Hi,

the RPI4 cannot boot compressed kernels. So kernels in /boot/firmware/
must be uncompressed.

There are several ways how raspi-firmware could help with that:
- when coping kernels to /boot/firmware, it could check that the kernel
  is not compressed, and issue an error if it is.
- better, it could uncompress kernels when copying them.

This is not a problem with the Debian kernel because they are shipped
uncompressed (apparently?). But it is a problem with kernels built with
'make bindeb-pkg' from upstream sources, that are compressed.

Lucas

Bug#966502: octavia: |INTL: fr] french debconf templates translation

[bubu]

Package: octavia

Severity: wishlist

tags: patch l10n

Please find attached the french translation update proofered by the
debian-l10n-french contributors mailing list

This file should be put as debian/po/fr.po in your package build-tree



fr.po.tar.gz
Description: application/gzip

Bug#966430: salmon should be Architecture: amd64

[Michael R. Crusoe]

On Tue, 28 Jul 2020 16:55:31 +0300 Adrian Bunk  wrote:
> Source: salmon
> Version: 1.3.0+ds1-2
> Severity: important
> Tags: ftbfs
>
> https://buildd.debian.org/status/package.php?p=salmon=sid
>
> Loooking at the code, I ended up at
>
https://sources.debian.org/src/salmon/1.3.0+ds1-1/debian/external/pufferfish/src/ksw2pp/KSW2Aligner.cpp/#L381


This is similar to code that has already been ported to arm64 and other
non-x86 systems. I will fix this as well.

-- 
Michael R. Crusoe




signature.asc
Description: OpenPGP digital signature

Bug#964810: gimp: Unable to start gimp in debian unstable

[felipe]

On 7/29/20 5:07 AM, Simon McVittie wrote:
> Control: reassign -1 libllvm10,libllvm9,libllvm7
> Control: forcemerge 852746 -1
> Control: affects 852746 + gimp
> 
> On Thu, 16 Jul 2020 at 12:26:26 -0300, zeden wrote:
>> $ gimp
>> : CommandLine Error: Option 'polly' registered more than once!
>> LLVM ERROR: inconsistency in registered CommandLine options
> 
> On Wed, 29 Jul 2020 at 00:55:02 -0300, felipe wrote:
>> After investigating further, I found the problematic package to be 
>> mesa-opencl-icd.
>>
>> After removing the package above, gimp works again.
> 
> This looks like the same issue as #852746. The workaround appears to be
> to avoid installing more than one OpenCL implementation at the same time:
> 
> - If you have an AMD GPU, install mesa-opencl-icd
> - If you have an NVIDIA GPU and are using the proprietary driver,
>   install nvidia-opencl-icd or one of the nvidia-*-opencl-icd packages
> - If you have an Intel integrated GPU, install beignet-opencl-icd or
>   intel-opencl-icd

I use and AMD polaris card with amdgpu and mesa drivers.

Previously I only had mesa-opencl-icd and ocl-icd-libopencl1 which is pulled by 
mesa-opencl-icd.

Trying to remove ocl-icd-libopencl1 prompts me to install nvidia-opencl 
packages.

It seems bug #954849 has a pretty similar bug, but found the problem while 
using libreoffice's opencl implementation.

Bug#959715: fixed in 7.2.20

[David Bremner]

Control: tag 959715 fixed-upstream

David Bremner  writes:

> Hash: SHA256
>
> I have some figures created in late 2019, apparently with ipe
> 7.2.9. If I load them in ipe or try to run ipetoipe -pdf then ipetoipe 
> complains
> "There was an error trying to run Pdflatex".
>
> Ipe says there is no latex executable on my command path, which is not
> true.  Enabling cloud latex compilation does work, so I guess it is
> related to execing pdflatex. I'll (try to) attach an example of a
> non-working figure, incase that helps.
>

It seems that this bug (whatever it is) is fixed upstream in 7.2.20

I did a quick and dirty update to 7.2.20 at

  https://salsa.debian.org/bremner/ipe

It's probably not suitable for upload since I just dropped the cross
building patch, lacking the patience for rebasing it at the moment.

Of course feel free to use my version as a starting point, or not.

Bug#957289: gnss-sdr: ftbfs with GCC-10

[Carles Fernandez]

Dear all,


this should be fixed in

   https://mentors.debian.net/package/gnss-sdr/ 


The respective dsc file can be found at:

   https://mentors.debian.net/debian/pool/main/g/gnss-sdr/gnss-sdr_0.0.13-1.dsc 



I’ve asked Christoph Berg to kindly sponsor the upload.

Best regards,
Carles


> El 29 jul 2020, a las 12:26, Gianfranco Costamagna  
> escribió:
> 
> control: tags -1 fixed-upstream
> 
> The new release is out, and might be fixing also this issue...
> 
> I tried a build and resulted in
> https://github.com/gnss-sdr/gnss-sdr/issues/414
> 
> but this looks like more a gnuradio issue, not sure who is to blame...
> (even boost might be faulty)
> 
> 
> G.
> 
> On Fri, 17 Apr 2020 11:01:35 + Matthias Klose  wrote:
>> Package: src:gnss-sdr
>> Version: 0.0.11-2
>> Severity: normal
>> Tags: sid bullseye
>> User: debian-...@lists.debian.org
>> Usertags: ftbfs-gcc-10
>> 
>> Please keep this issue open in the bug tracker for the package it
>> was filed for.  If a fix in another package is required, please
>> file a bug for the other package (or clone), and add a block in this
>> package. Please keep the issue open until the package can be built in
>> a follow-up test rebuild.
>> 
>> The package fails to build in a test rebuild on at least amd64 with
>> gcc-10/g++-10, but succeeds to build with gcc-9/g++-9. The
>> severity of this report will be raised before the bullseye release,
>> so nothing has to be done for the buster release.
>> 
>> The full build log can be found at:
>> http://people.debian.org/~doko/logs/gcc10-20200225/gnss-sdr_0.0.11-2_unstable_gcc10.log
>> The last lines of the build log are at the end of this report.
>> 
>> To build with GCC 10, either set CC=gcc-10 CXX=g++-10 explicitly,
>> or install the gcc, g++, gfortran, ... packages from experimental.
>> 
>>  apt-get -t=experimental install g++ 
>> 
>> Common build failures are new warnings resulting in build failures with
>> -Werror turned on, or new/dropped symbols in Debian symbols files.
>> For other C/C++ related build failures see the porting guide at
>> http://gcc.gnu.org/gcc-10/porting_to.html
>> 
>> [...]
>> from 
>> /<>/src/algorithms/signal_source/adapters/osmosdr_signal_source.cc:32:
>> /usr/include/boost/format/alt_sstream_impl.hpp: In instantiation of 
>> ‘boost::io::basic_altstringbuf::int_type 
>> boost::io::basic_altstringbuf> Alloc>::overflow(boost::io::basic_altstringbuf::int_type) 
>> [with Ch = char; Tr = std::char_traits; Alloc = std::allocator; 
>> boost::io::basic_altstringbuf::int_type = int]’:
>> /usr/include/boost/format/alt_sstream_impl.hpp:227:9:   required from here
>> /usr/include/boost/format/alt_sstream_impl.hpp:261:45: error: no matching 
>> function for call to ‘std::allocator::allocate(std::size_t&, char*)’
>>  261 | newptr = alloc_.allocate(new_size, is_allocated_? 
>> oldptr : 0);
>>  |  
>> ~~~^
>> In file included from /usr/include/c++/10/string:41,
>> from /usr/include/c++/10/stdexcept:39,
>> from /usr/include/c++/10/system_error:41,
>> from /usr/include/c++/10/bits/std_mutex.h:39,
>> from /usr/include/c++/10/condition_variable:40,
>> from 
>> /<>/src/core/receiver/concurrent_queue.h:35,
>> from 
>> /<>/src/algorithms/signal_source/adapters/osmosdr_signal_source.h:36,
>> from 
>> /<>/src/algorithms/signal_source/adapters/osmosdr_signal_source.cc:32:
>> /usr/include/c++/10/bits/allocator.h:171:7: note: candidate: ‘constexpr _Tp* 
>> std::allocator<  >::allocate(std::size_t) [with _Tp 
>> = char; std::size_t = long unsigned int]’
>>  171 |   allocate(size_t __n)
>>  |   ^~~~
>> /usr/include/c++/10/bits/allocator.h:171:7: note:   candidate expects 1 
>> argument, 2 provided
>> make[3]: *** 
>> [src/algorithms/signal_source/adapters/CMakeFiles/signal_source_adapters.dir/build.make:170:
>>  
>> src/algorithms/signal_source/adapters/CMakeFiles/signal_source_adapters.dir/osmosdr_signal_source.cc.o]
>>  Error 1
>> make[3]: *** Waiting for unfinished jobs
>> [ 95%] Building CXX object 
>> src/algorithms/acquisition/adapters/CMakeFiles/acquisition_adapters.dir/beidou_b3i_pcps_acquisition.cc.o
>> cd /<>/obj-x86_64-linux-gnu/src/algorithms/acquisition/adapters 
>> && /usr/bin/c++  -DGNSSSDR_INSTALL_DIR=\"/usr\" -D_FILE_OFFSET_BITS=64 
>> -D_LARGEFILE_SOURCE -D_LARGE_FILES -I/<>/src/core/interfaces 
>> -I/<>/src/algorithms/libs/gsl/include 
>> -I/<>/src/algorithms/libs 
>> -I/<>/src/algorithms/acquisition/gnuradio_blocks 
>> -I/<>/src/algorithms/libs/opencl 
>> -I/<>/src/algorithms/acquisition/libs 
>> -I/<>/src/core/receiver 
>> -I/<>/src/algorithms/channel/libs 
>> -I/<>/src/core/system_parameters -isystem /usr/include/glog 
>> -isystem 
>> 

Bug#966501: 2.0.3 REST API regression: Failed to parse parameters for /v1.12/libpod/events: unexpected end of JSON input

[Martin Pitt]

Package: podman
Version: 2.0.3+dfsg1-1
Severity: serious
Tags: upsteam fixed-upstream

Version 2.0.3 breaks the REST API really hard, which breaks cockpit-podman and
any other API user. This is tracked here:

  https://github.com/containers/podman/issues/7078

This has been fixed upstream and will be in 2.0.4. I'd like to block this
version from testing to avoid the regression.

If you disagree and would rather get this in ASAP (given how young the package
is still), I'm fine with that as well, and disable the cockpit-podman test on
debian-testing for a while.

Thanks,

Martin

Bug#966500: python3-notcurses: missing Breaks+Replaces: notcurses-bin (<< 1.6)

[Nick Black]

#thanks

Thank you for filing my first Debian bug! How exciting, and at
the same time embarrassing. I should have caught this before
uploading. A fix is obvious, and I ought be able to accomplish
it within the Debian packaging proper, rather than requiring a
new release (I'm the upstream author).

Expect a +dfsg.1-3 built very soon. I'm not yet even a DM, so
I'll have to wait on a DD to upload the new build to the
archive. I'll provide a link here, and poke one of my sponsors.

Bug#966456: mutt: suddenly started ignoring $realname

[Andreas Kurth]

On Tue, 28 Jul 2020 14:55:23 -0300 Antonio Terceiro  wrote:
> With this setup, I open mutt, hit "m" to compose, fill in "To:" and
> "Subject:", write something in $EDITOR, save, quit. Then I get:
> 
> From: f...@example.com
> 
> instead of
> 
> From: Foo Bar 

A similar observation might have the same root cause:

I'm used to fill the recipient addresses with the help of lbdb, which
in turn uses LDAP to retrieve the data and set
"Real Name ".

Behaviour has changed to only set "recipi...@example.com" and omit
"Real Name" some time ago. I suspect it is somehow related to the
changed exact-addresses handling.

Bug#966498: libgd-perl: Dropped libgd-gd2-perl breaks a Recommends in lcov and prevents a clean upgrade

[Vincent Lefevre]

On 2020-07-29 14:05:43 +0200, Vincent Lefevre wrote:
> Package: libgd-perl
> Version: 2.72-1
> Severity: important
> 
> libgd-perl (2.72-1) unstable; urgency=medium
> [...]
>   * Drop ancient Breakes/Replaces/Provides on libgd-gd2-{,noxpm-}perl.
> [...]
>  -- gregor herrmann   Wed, 22 Jul 2020 19:58:57 +0200
> 
> libgd-gd2-perl is not ancient. It is still used by lcov at least:
> 
> Package: lcov
> Status: install ok installed
> Priority: optional
> Section: devel
> Installed-Size: 456
> Maintainer: Alastair McKinstry 
> Architecture: all
> Version: 1.14-2
> Depends: perl:any, gcc, libjson-perl, libperlio-gzip-perl
> Recommends: libgd-gd2-perl
> 
> signing-party 2.11-1 also has:
> Recommends: default-mta | mail-transport-agent, dialog | whiptail, 
> libgd-gd2-noxpm-perl | libgd-gd2-perl, libpaper-utils
> 
> This prevents a clean upgrade with aptitude, which checks Recommends.

Worse than that, if libgd-gd2-perl features were silently dropped,
this may break lcov. And if they are still present in libgd-perl,
installing lcov on a machine will not install libgd-perl automatically
(in case it is not already installed), so that lcov will not behave as
normally expected.

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

Bug#966500: python3-notcurses: missing Breaks+Replaces: notcurses-bin (<< 1.6)

[Andreas Beckmann]

Package: python3-notcurses
Version: 1.6.9+dfsg.1-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

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

  Preparing to unpack .../python3-notcurses_1.6.9+dfsg.1-2_amd64.deb ...
  Unpacking python3-notcurses (1.6.9+dfsg.1-2) over (1.5.1+dfsg.1-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-notcurses_1.6.9+dfsg.1-2_amd64.deb (--unpack):
   trying to overwrite '/usr/bin/notcurses-pydemo', which is also in package 
notcurses-bin 1.5.1+dfsg.1-1
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-notcurses_1.6.9+dfsg.1-2_amd64.deb


cheers,

Andreas


notcurses-bin=1.5.1+dfsg.1-1_python3-notcurses=1.6.9+dfsg.1-2.log.gz
Description: application/gzip

Bug#966498: libgd-perl: Dropped libgd-gd2-perl breaks a Recommends in lcov and prevents a clean upgrade

[Vincent Lefevre]

Package: libgd-perl
Version: 2.72-1
Severity: important

libgd-perl (2.72-1) unstable; urgency=medium
[...]
  * Drop ancient Breakes/Replaces/Provides on libgd-gd2-{,noxpm-}perl.
[...]
 -- gregor herrmann   Wed, 22 Jul 2020 19:58:57 +0200

libgd-gd2-perl is not ancient. It is still used by lcov at least:

Package: lcov
Status: install ok installed
Priority: optional
Section: devel
Installed-Size: 456
Maintainer: Alastair McKinstry 
Architecture: all
Version: 1.14-2
Depends: perl:any, gcc, libjson-perl, libperlio-gzip-perl
Recommends: libgd-gd2-perl

signing-party 2.11-1 also has:
Recommends: default-mta | mail-transport-agent, dialog | whiptail, 
libgd-gd2-noxpm-perl | libgd-gd2-perl, libpaper-utils

This prevents a clean upgrade with aptitude, which checks Recommends.

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

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

Versions of packages libgd-perl depends on:
ii  libc6   2.31-2
ii  libgd3  2.3.0-2
ii  perl5.30.3-4
ii  perl-base [perlapi-5.30.3]  5.30.3-4

libgd-perl recommends no packages.

libgd-perl suggests no packages.

-- no debconf information

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

Bug#966497: Buster: update-policy { grant dev.DOMAIN.TLD subdomain dev.DOMAIN.TLD a aaaa txt; } is not handled correctly

[Joop Boonen]

Package: bind9
Version: 1:9.11.5.P4+dfsg-5.1+deb10u1

Problem:
update-policy { grant dev.DOMAIN.TLD subdomain dev.DOMAIN.TLD a  txt; } is 
not handled correctly

Debian Stretch (9.10.3) doesn't have this issue. 

It is also possible to change entries in DOMAIN.TLD

Configuration part:

include "/etc/bind/dev.key";

zone DOMAIN.TLD {
type master;
file "/var/lib/bind/zones/DOMAIN.TLD";
key-directory "/var/lib/bind/keys";
masterfile-format raw;
update-policy {
grant dhcp zonesub a dhcid;
grant local-ddns zonesub any;
grant dev.DOMAIN.TLD subdomain dev.DOMAIN.TLD a  txt;
};

allow-transfer {
local;
};
};

nsupdate key:

cat /etc/bind/dev.key 
key "dev.DOMAIN.TLD" {
algorithm hmac-sha512;
secret "**";
};


What is seen on Debian Buster:

nsupdate -k dev.key
> server 192.168.122.129
> ttl 3600
> update add test3.dev.DOMAIN.TLD a 192.0.2.3
> send
> update add test.DOMAIN.TLD a 192.0.2.1
> send

Logging: 
Jul 28 16:48:59 debian10-bind named[5894]: client @0x7f5718000c80 
192.168.122.1#40886/key dev.DOMAIN.TLD: updating zone 'DOMAIN.de/IN': adding 
an RR at 'test3.dev.DOMAIN.de' A 192.0.2.3
Jul 28 16:48:59 debain10-bind named[5894]: zone DOMAIN.de/IN: sending notifies 
(serial 2020050521)
Jul 28 16:49:07 debian10-bind named[5894]: client @0x7f5718000c80 
192.168.122.1#40886/key dev.DOMAIN.TLD: updating zone 'DOMAIN.de/IN': adding 
an RR at 'test.DOMAIN.de' A 192.0.2.1
Jul 28 16:49:07 debian10-bind named[5894]: zone DOMAIN.de/IN: sending notifies 
(serial 2020050522)


How it should look like, Debian Stretch:

nsupdate -k dev.key
> server 192.168.122.40
> ttl 3600
> update add test5.dev.credativ.de a 192.0.2.5   
> send
> update add test5.credativ.de a 192.0.2.5
> send
update failed: REFUSED

Logging:
Jul 29 11:37:00 debian9-bind named[515]: client 192.168.122.1#49684/key 
dev.credativ.de: updating zone 'credativ.de/IN': adding an RR at 
'test5.dev.credativ.de' A 192.0.2.5
Jul 29 11:37:00 debian9-bind named[515]: zone credativ.de/IN: sending notifies 
(serial 2020050522)
Jul 29 11:37:16 debian9-bind named[515]: client 192.168.122.1#49684/key 
dev.credativ.de: updating zone 'credativ.de/IN': update failed: rejected by 
secure update (REFUSED)


A isc issue (bug report) has been created: 
https://gitlab.isc.org/isc-projects/bind9/-/issues/2055

Regards,
 
Joop Boonen

Tel.: +49 2166 9901-0
Fax: +49 2166 9901-100
E-Mail: joop.boo...@credativ.de
pgp fingerprint: 9130 2E95 0D0E 1721 EB23 7270 C2C6 B28E 7EA7 F0A4
https://www.credativ.de
credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
Unser Umgang mit personenbezogenen Daten unterliegt
folgenden Bestimmungen: https://www.credativ.de/datenschutz
**
Jetzt neu: 
Elephant Shed - PostgreSQL Appliance
PostgreSQL und alles was dazugehört
Von Backup über Monitoring bis Reporting: 
https://elephant-shed.io/index.de.html
**

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

Bug#966490: libpam-geoip does not work with /usr/share/GeoIP/GeoIPCity.dat

[Joerg Dorchain]

On Wed, Jul 29, 2020 at 12:40:15PM +0200, Patrick Matthäi wrote:
> You have to get the files from maxmind.com, since there is no package
> for the databases, yet.

Yep, that works almost painless.

- Install the geoipupdate package
- Sign up with a maxming.com free account
- enter the the credentials you get in /etc/Geoip.conf
- run geoipupdate
- point libpam-geoip to /var/lib/GeoIP/GeoLite2-City.mmdb

I am now fine again with my manually patched version of
libpam-geoip (cfr. #966486)

Bye,

Joerg



signature.asc
Description: PGP signature

Bug#933031: pristine-tar: unable to unpack some deltas of version 2

[Steve McIntyre]

Control: tags -1 +patch

On Tue, Jul 28, 2020 at 04:17:08PM +0100, Steve McIntyre wrote:
>Control: severity -1 grave

...

>IMHO this has to be a grave bug - without reimporting this repo we
>can't get our older revisions back. Then I'm worried that this will
>break things if we need to go back and rebuild older versions (using
>older tooling). pristine-tar needs to be safe for data here. :-(
>
>I've done a git bisect of the pristine-tar repo to see where things
>broke, and that clearly tells me:
>
>...
>f287f10b48c3ca5a30db13dbf3ba918c47a943bb is the first bad commit
>commit f287f10b48c3ca5a30db13dbf3ba918c47a943bb
>Author: Tomasz Buchert 
>Date:   Fri Jan 13 23:28:04 2017 +0100
>
>fix #851286
>
>:100755 100755 1a34e953ba363ae1e284b97f83f63f6ef80ea544 
>3ba76f79d376d011451b8c572b20e185b715bed1 M  pristine-tar
>:04 04 84bc809be6b4dcf81cfce71f0550858957a3e92f 
>f8eb72beb458cbd9770f88f0f4efc00f0c75a299 M  test
>bisect run success
>...
>
>I hope that helps the maintainers - shout if you'd like more help debugging.

I've carried on and looked at the code. The attached patch makes
things work for me, at the expense of YA thing added to the @try
loop. But I'll take that over failure!

Having looked at this code a little, I'm now also a little concerned
about the way the fallbacks work, i.e. applied one at a time
independently. I'm thinking that there could well be cases where a
stored tarball might need more than one of the workaround/retry
options. Maybe I'm over-thinking it.

Also submitted this as an MR:

  https://salsa.debian.org/debian/pristine-tar/-/merge_requests/7

in case you'd prefer that.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< sladen> I actually stayed in a hotel and arrived to find a post-it
  note stuck to the mini-bar saying "Paul: This fridge and
  fittings are the correct way around and do not need altering"
diff --git a/pristine-tar b/pristine-tar
index 0fe132e..081dca1 100755
--- a/pristine-tar
+++ b/pristine-tar
@@ -560,6 +560,33 @@ sub recreatetarball_broken_numeric_owner {
   return recreatetarball_helper();
 }
 
+sub recreatetarball_broken_verbatim {
+  # To fix #851286, the option --verbatim-files-from was added by
+  # default. But now some older older stored tarballs won't reproduce
+  # (#933031). Try again *without* that option to tar.
+  my %options = @_;
+  my $tempdir = $recreatetarball_tempdir;
+
+  my $ret = "$tempdir/recreatetarball";
+  my @cmd = (
+$tar_program, "cf",
+$ret, "--owner",
+0,"--group",
+0,"--numeric-owner",
+"-C", "$tempdir/workdir",
+"--no-recursion", "--mode",
+"0644",
+"--files-from",   "$tempdir/manifest"
+  );
+  if (exists $options{tar_format}) {
+push @cmd, ("-H", $options{tar_format});
+  }
+
+  doit(@cmd);
+
+  return $ret;
+}
+
 sub gentar {
   my $deltafile = shift;
   my $tarball   = shift;
@@ -614,6 +641,7 @@ sub gentar {
   %opts
 );
   };
+  push @try, \_broken_verbatim;
   push @try, \_broken_numeric_owner;
 
   my $ok;

Bug#966496: ITP: node-unbzip2-stream -- streaming unbzip2 implementation in pure javascript for node and browsers

[merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist
Control: block 959412 by -1

* Package name: node-unbzip2-stream
  Version : 1.4.2
  Upstream Author : Jan Bölsche 
* URL : https://github.com/regular/unbzip2-stream#readme
* License : Expat
  Programming Lang: JavaScript
  Description : streaming unbzip2 implementation in pure javascript
for node and browsers
 Streaming bzip2 decompressor in pure JS for Node and browserify. When
 browserified, the stream emits instances of feross/buffer instead of raw
 Uint8Arrays to have a consistent API across browsers and Node.

This package is required by node-puppeteer.

Remark: This package is to be maintained with Debian Javascript
Maintainers at
   https://salsa.debian.org/js-team/node-unbzip2-stream

Bug#966490: libpam-geoip does not work with /usr/share/GeoIP/GeoIPCity.dat

[Joerg Dorchain]

On Wed, Jul 29, 2020 at 12:40:15PM +0200, Patrick Matthäi wrote:
> Am 29.07.2020 um 11:32 schrieb Joerg Dorchain:
> > Package: libpam-geoip
> > Version: 2.1.1-1
> >
> > Hello,
> >
> > I used to have a working setup with libpam-geoip as 
> >
> > account required pam_geoip.so debug system_file=/etc/security/geoip.conf 
> > geoip_db=/usr/share/GeoIP/GeoIPCity.dat
> >
> > After upgrading to this version, I find in authlog
> > PASSV: pam_geoip(dovecot:account): failed to open geoip db 
> > (/usr/share/GeoIP/GeoIPCity.dat - The MaxMind DB file contains invalid 
> > metadata)
> >
> > This renders the geoip line rather useless.
> >
> > Besides, there is no hint of any potentials incompatibilities
> > during upgrade, neither an upgrade path mentioned.
> >
> > FYI, the /usr/share/GeoIP/GeoIPCity.dat on my system is provided
> > by the package geoip-database-extra version 20181108-1
> 
> see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953577
> 
> The old package is not maintained anymore, upstream is "dead" so I have
> decided to switch to this fork, using the new maxmind geoip2 databases.
> You have to get the files from maxmind.com, since there is no package
> for the databases, yet.
> Maybe packaging them is also not possible, because of license issues
> (same with the v1 database now).

I am still on the learning curve for the new version, so please
bear with me.

Maybe adding a conflicts: or breaks: -line for the package for the
old geoip-database* packages would be a decent hint that things are
quite different now on the technical level.

Thanks for the quick reply!

Bye,

Joerg



signature.asc
Description: PGP signature

Bug#966495: python-pyxs: please make the build reproducible

[Chris Lamb]

Source: python-pyxs
Version: 0.4.2~git20190115.97f14313-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] I noticed that
python-pyxs could not be built reproducibly.

This is because the linkcode Sphinx extension and linkcode_resolve get
confused and try to link to the documentation to the @contextlib.contextmanager
decorator, and then uses relpath... All this results in links differing
depending on the number of directory components in the absolute build path:

  
href="https://github.com/selectel/pyxs/tree/0.4.2-dev/pyxs/../../../../usr/lib/python3.8/contextlib.py#L25-L33

vs.

  
href="https://github.com/selectel/pyxs/tree/0.4.2-dev/pyxs/../../../../../usr/lib/python3.8/contextlib.py#L25-L33;

As these links are broken anyway, I've attached a patch that will simply
hide them if we know they will be wrong. I think the right fix would be
to resolve the location of the exact function "underneath" the decorator.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/docs/conf.py  2020-07-29 11:09:24.036630132 +0100
--- b/docs/conf.py  2020-07-29 11:45:54.186574021 +0100
@@ -119,6 +119,8 @@
 import pyxs
 fn = inspect.getsourcefile(obj)
 fn = os.path.relpath(fn, os.path.dirname(pyxs.__file__))
+if fn.startswith(".."):
+return None
 source, lineno = inspect.getsourcelines(obj)
 return fn, lineno, lineno + len(source) - 1
 

Bug#966490: libpam-geoip does not work with /usr/share/GeoIP/GeoIPCity.dat

[Patrick Matthäi]

Hi

Am 29.07.2020 um 11:32 schrieb Joerg Dorchain:
> Package: libpam-geoip
> Version: 2.1.1-1
>
> Hello,
>
> I used to have a working setup with libpam-geoip as 
>
> account required pam_geoip.so debug system_file=/etc/security/geoip.conf 
> geoip_db=/usr/share/GeoIP/GeoIPCity.dat
>
> After upgrading to this version, I find in authlog
> PASSV: pam_geoip(dovecot:account): failed to open geoip db 
> (/usr/share/GeoIP/GeoIPCity.dat - The MaxMind DB file contains invalid 
> metadata)
>
> This renders the geoip line rather useless.
>
> Besides, there is no hint of any potentials incompatibilities
> during upgrade, neither an upgrade path mentioned.
>
> FYI, the /usr/share/GeoIP/GeoIPCity.dat on my system is provided
> by the package geoip-database-extra version 20181108-1

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

The old package is not maintained anymore, upstream is "dead" so I have
decided to switch to this fork, using the new maxmind geoip2 databases.
You have to get the files from maxmind.com, since there is no package
for the databases, yet.
Maybe packaging them is also not possible, because of license issues
(same with the v1 database now).

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: https://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/




signature.asc
Description: OpenPGP digital signature

Bug#915008: I've seen a similar problem and managed to work around it.

[John Hughes]

(Disclaimer, don't know if it's exactly the same problem).

On one of our DELL Lattitude 5400 laptops the wifi stopped working, giving:

Jul 27 22:00:04 oceanic kernel: [  141.298350] iwlwifi :00:14.3: enabling 
device ( -> 0002)
Jul 27 22:00:04 oceanic kernel: [  141.323938] iwlwifi :00:14.3: firmware: 
direct-loading firmware iwlwifi-9000-pu-b0-jf-b0-38.ucode
Jul 27 22:00:04 oceanic kernel: [  141.324553] iwlwifi :00:14.3: loaded 
firmware version 38.755cfdd8.0 op_mode iwlmvm
Jul 27 22:00:04 oceanic kernel: [  141.403707] iwlwifi :00:14.3: Detected 
Intel(R) Dual Band Wireless AC 9560, REV=0x318
Jul 27 22:00:04 oceanic kernel: [  141.646515] iwlwifi :00:14.3: Microcode 
SW error detected. Restarting 0x0.
Jul 27 22:00:04 oceanic kernel: [  141.646524] iwlwifi :00:14.3: Not valid 
error log pointer 0x for Init uCode
Jul 27 22:00:04 oceanic kernel: [  141.646566] iwlwifi :00:14.3: SecBoot 
CPU1 Status: 0x3, CPU2 Status: 0x2475
Jul 27 22:00:04 oceanic kernel: [  141.646569] iwlwifi :00:14.3: Failed to 
start INIT ucode: -5
Jul 27 22:00:04 oceanic kernel: [  141.658825] iwlwifi :00:14.3: Failed to 
run INIT ucode: -5

I tried updating firmware-iwlwifi to 20190717-2~bpo10+1, no change

I upgraded to kernel 5.6.14-2~bpo10+1, and hence 
9000-pu-b0-jf-b0-46.ucode which gave more output but still didn't work:


Jul 29 11:52:21 oceanic kernel: [   12.133630] iwlwifi :00:14.3: enabling 
device ( -> 0002)
Jul 29 11:52:21 oceanic kernel: [   12.150217] iwlwifi :00:14.3: firmware: 
direct-loading firmware iwlwifi-9000-pu-b0-jf-b0-46.ucode
Jul 29 11:52:21 oceanic kernel: [   12.150233] iwlwifi :00:14.3: Found 
debug destination: EXTERNAL_DRAM
Jul 29 11:52:21 oceanic kernel: [   12.150234] iwlwifi :00:14.3: Found 
debug configuration: 0
Jul 29 11:52:21 oceanic kernel: [   12.150622] iwlwifi :00:14.3: loaded 
firmware version 46.a41adfe7.0 9000-pu-b0-jf-b0-46.ucode op_mode iwlmvm
Jul 29 11:52:21 oceanic kernel: [   12.233985] iwlwifi :00:14.3: Detected 
Intel(R) Wireless-AC 9560 160MHz, REV=0x318
Jul 29 11:52:21 oceanic kernel: [   12.241362] iwlwifi :00:14.3: Applying 
debug destination EXTERNAL_DRAM
Jul 29 11:52:21 oceanic kernel: [   12.241616] iwlwifi :00:14.3: Allocated 
0x0040 bytes for firmware monitor.
Jul 29 11:52:21 oceanic kernel: [   12.274019] iwlwifi :00:14.3: Microcode 
SW error detected. Restarting 0x0.
Jul 29 11:52:21 oceanic kernel: [   12.274025] iwlwifi :00:14.3: Not valid 
error log pointer 0x for Init uCode
Jul 29 11:52:21 oceanic kernel: [   12.274042] iwlwifi :00:14.3: Fseq 
Registers:
Jul 29 11:52:21 oceanic kernel: [   12.274050] iwlwifi :00:14.3: 0xE8680755 
| FSEQ_ERROR_CODE
Jul 29 11:52:21 oceanic kernel: [   12.274059] iwlwifi :00:14.3: 0x 
| FSEQ_TOP_INIT_VERSION
Jul 29 11:52:21 oceanic kernel: [   12.274067] iwlwifi :00:14.3: 0x304500C4 
| FSEQ_CNVIO_INIT_VERSION
Jul 29 11:52:21 oceanic kernel: [   12.274075] iwlwifi :00:14.3: 0xA384 
| FSEQ_OTP_VERSION
Jul 29 11:52:21 oceanic kernel: [   12.274084] iwlwifi :00:14.3: 0x8F6E77E5 
| FSEQ_TOP_CONTENT_VERSION
Jul 29 11:52:21 oceanic kernel: [   12.274092] iwlwifi :00:14.3: 0xC5F6D9EF 
| FSEQ_ALIVE_TOKEN
Jul 29 11:52:21 oceanic kernel: [   12.274100] iwlwifi :00:14.3: 0x08234C18 
| FSEQ_CNVI_ID
Jul 29 11:52:21 oceanic kernel: [   12.274109] iwlwifi :00:14.3: 0xBCDE7DBF 
| FSEQ_CNVR_ID
Jul 29 11:52:21 oceanic kernel: [   12.274117] iwlwifi :00:14.3: 0x01000100 
| CNVI_AUX_MISC_CHIP
Jul 29 11:52:21 oceanic kernel: [   12.274128] iwlwifi :00:14.3: 0x01300202 
| CNVR_AUX_MISC_CHIP
Jul 29 11:52:21 oceanic kernel: [   12.274138] iwlwifi :00:14.3: 0x485B 
| CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM
Jul 29 11:52:21 oceanic kernel: [   12.274179] iwlwifi :00:14.3: 0xA5A5A5A2 
| CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR
Jul 29 11:52:21 oceanic kernel: [   12.274224] iwlwifi :00:14.3: SecBoot 
CPU1 Status: 0x3, CPU2 Status: 0x2386
Jul 29 11:52:21 oceanic kernel: [   12.274227] iwlwifi :00:14.3: Failed to 
start INIT ucode: -5
Jul 29 11:52:21 oceanic kernel: [   12.274229] iwlwifi :00:14.3: Collecting 
data: trigger 16 fired.
Jul 29 11:52:21 oceanic kernel: [   12.522663] iwlwifi :00:14.3: Firmware 
not running - cannot dump error
Jul 29 11:52:21 oceanic kernel: [   12.534415] iwlwifi :00:14.3: Failed to 
run INIT ucode: -5

In desperation I booted into windows to see if the wifi worked there, 
and it did.


Then I rebooted Debian and the wifi now works.

Jul 29 12:13:09 oceanic kernel: [   15.067344] iwlwifi :00:14.3: enabling 
device ( -> 0002)
Jul 29 12:13:09 oceanic kernel: [   15.072020] iwlwifi :00:14.3: firmware: 
direct-loading firmware iwlwifi-9000-pu-b0-jf-b0-46.ucode
Jul 29 12:13:09 oceanic kernel: [   15.072039] iwlwifi :00:14.3: Found 
debug destination: EXTERNAL_DRAM
Jul 29 12:13:09 oceanic kernel: [   15.072039] iwlwifi :00:14.3: 

Bug#966494: RFE: add 'carddav' to package 'roundcube-plugins-extra'

[Marco Emilio Poleggi]

Package: roundcube-plugins-extra
Version: 1.4.7+1-1 (bullseye)

Hi there,

I'm testing the 'carddav' plugin to synchronize address books between
Nectcloud and Roundcube. It works pretty well (with minor glitches, so far)
with Roundcube v1.4.7+dfsg.1-1 and Nextcloud v19.0.1-1~deb10
(https://apt.jurisic.org/debian). Here's the code:

  

It would be great to have it distributed with roundcube-plugins-extra :-)

Cheers,

  Marco

Bug#966425: include Meson cross files

[Jussi Pakkanen]

On Tue, 28 Jul 2020 at 15:36, John Scott  wrote:

> I'm not close to being finished yet, but I'm working on writing Meson
> cross files that would be suitable for inclusion. Meson recommends that
> distros including cross-toolchains ship these somehow, be it with the
> toolchain or in a separate package.
>
> No cross files seem to be packaged yet. I've cc'd the Meson maintainer
> if he has any thoughts, but I think mingw-w64-common seems a fine place.
>
> I wonder if you would prefer one of two scenarios:
>
> * Include two cross files: one for i686, another for x86_64.
>   Let the alternatives system handle the -posix and -win32 choice.
> or
> * Include four cross files: one for each arch and threads combination.
>
> Thanks for packaging MinGW-w64! It's a treasure I'd like to make more
> useful out-of-the-box.

The way things are done in Debian is that Meson ships a script called
debcrossgen that automatically generates cross files for a given
setup. The best solution would probably be to extend that script to
also generate cross files for mingw. There is a bit of a policy
question, though. Currently debcrossgen is optimized for Debian
package building and it works quite well with it. Presumably these
cross files would be used for other things, such as building Windows
packages/installers. I don't have personal experience with that work
flow, so I don't know how well these two would tie together (most
likely quite well, but you can never tell about these things). Thus if
someone with more hands on experience could comment on the
feasibility, it would be useful.

Thanks,

Bug#960617: popularity-contest: popcon fails to send data if USETOR=maybe and tor is not running

[Ben Wiederhake]

Package: popularity-contest
Version: 1.70
Followup-For: Bug #960617

Dear Maintainer,

I also ran into this issue.

For some reason, setting USETOR="no" in /etc/popularity-contest.conf does not
do the trick for me. (It still fails.)

My "temporary workaround" is now to uninstall tor. (Let's hope I don't need it
for a while.)

Cheers,
Ben



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

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

Versions of packages popularity-contest depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  dpkg   1.19.7

Versions of packages popularity-contest recommends:
ii  cron [cron-daemon] 3.0pl1-136
ii  exim4-daemon-light [mail-transport-agent]  4.94-6
ii  gnupg  2.2.20-1

Versions of packages popularity-contest suggests:
ii  anacron   2.3-29
pn  tor   
pn  torsocks  

-- debconf information:
  popularity-contest/submiturls:
* popularity-contest/participate: true

Bug#965323: postinst script deletes custom locales

[Aurelien Jarno]

On 2020-07-27 08:26, Harald Dunkel wrote:
> Can't be worse than not having the locale at all. Not to mention that there is
> an option --posix to assure compatibility to POSIX.1-2008, AFAICT.

This option doesn't change the output format which is glibc specific. It
only control the source format, which is defined by POSIX.

> If there are
> incompatible changes, then its my job to worry about recreating the custom 
> locales.

This is how *you* consider that. Most users that encounter broken
locales just report a bug.

> Since the postinst builds just a subset of all locales and since it even 
> maintains
> a list about it, I would suggest to erase and rebuild only these locales.

This is not so easy as the list evolve from version to version.

Regards
Aurelien

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

Bug#966493: RFS: source-highlight/3.1.9-1.3 -- convert source code to syntax highlighted document

[Kartik Kulkarni]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "source-highlight":

 * Package name: source-highlight
   Version : 3.1.9-1.3
   Upstream Author : http://www.gnu.org/software/src-highlite/
 * URL : http://www.gnu.org/software/src-highlite/
 * License : GPL-3+
 * Vcs : None
   Section : devel

It builds those binary packages:

  libsource-highlight-common - architecture-independent files for
source highlighting library
  libsource-highlight4v5 - source highlighting library
  libsource-highlight-dev - development files for source highlighting library
  source-highlight - convert source code to syntax highlighted document

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

  https://mentors.debian.net/package/source-highlight/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/source-highlight/source-highlight_3.1.9-1.3.dsc

Changes since the last upload:

 source-highlight (3.1.9-1.3) unstable; urgency=medium
 .
   * Fix reproducible build with patch from
 Vagrant (Closes: #963518)
   * Fix fail to cross build from source with patch
 Helmut  (Closes: #912715)
   * Updated standards version

Regards,
--
  Kartik Kulkarni

Bug#957289: gnss-sdr: ftbfs with GCC-10

[Gianfranco Costamagna]

control: tags -1 fixed-upstream

The new release is out, and might be fixing also this issue...

I tried a build and resulted in
https://github.com/gnss-sdr/gnss-sdr/issues/414

but this looks like more a gnuradio issue, not sure who is to blame...
(even boost might be faulty)


G.

On Fri, 17 Apr 2020 11:01:35 + Matthias Klose  wrote:
> Package: src:gnss-sdr
> Version: 0.0.11-2
> Severity: normal
> Tags: sid bullseye
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-10
> 
> Please keep this issue open in the bug tracker for the package it
> was filed for.  If a fix in another package is required, please
> file a bug for the other package (or clone), and add a block in this
> package. Please keep the issue open until the package can be built in
> a follow-up test rebuild.
> 
> The package fails to build in a test rebuild on at least amd64 with
> gcc-10/g++-10, but succeeds to build with gcc-9/g++-9. The
> severity of this report will be raised before the bullseye release,
> so nothing has to be done for the buster release.
> 
> The full build log can be found at:
> http://people.debian.org/~doko/logs/gcc10-20200225/gnss-sdr_0.0.11-2_unstable_gcc10.log
> The last lines of the build log are at the end of this report.
> 
> To build with GCC 10, either set CC=gcc-10 CXX=g++-10 explicitly,
> or install the gcc, g++, gfortran, ... packages from experimental.
> 
>   apt-get -t=experimental install g++ 
> 
> Common build failures are new warnings resulting in build failures with
> -Werror turned on, or new/dropped symbols in Debian symbols files.
> For other C/C++ related build failures see the porting guide at
> http://gcc.gnu.org/gcc-10/porting_to.html
> 
> [...]
>  from 
> /<>/src/algorithms/signal_source/adapters/osmosdr_signal_source.cc:32:
> /usr/include/boost/format/alt_sstream_impl.hpp: In instantiation of 
> ‘boost::io::basic_altstringbuf::int_type 
> boost::io::basic_altstringbuf Alloc>::overflow(boost::io::basic_altstringbuf::int_type) 
> [with Ch = char; Tr = std::char_traits; Alloc = std::allocator; 
> boost::io::basic_altstringbuf::int_type = int]’:
> /usr/include/boost/format/alt_sstream_impl.hpp:227:9:   required from here
> /usr/include/boost/format/alt_sstream_impl.hpp:261:45: error: no matching 
> function for call to ‘std::allocator::allocate(std::size_t&, char*)’
>   261 | newptr = alloc_.allocate(new_size, is_allocated_? 
> oldptr : 0);
>   |  
> ~~~^
> In file included from /usr/include/c++/10/string:41,
>  from /usr/include/c++/10/stdexcept:39,
>  from /usr/include/c++/10/system_error:41,
>  from /usr/include/c++/10/bits/std_mutex.h:39,
>  from /usr/include/c++/10/condition_variable:40,
>  from 
> /<>/src/core/receiver/concurrent_queue.h:35,
>  from 
> /<>/src/algorithms/signal_source/adapters/osmosdr_signal_source.h:36,
>  from 
> /<>/src/algorithms/signal_source/adapters/osmosdr_signal_source.cc:32:
> /usr/include/c++/10/bits/allocator.h:171:7: note: candidate: ‘constexpr _Tp* 
> std::allocator<  >::allocate(std::size_t) [with _Tp = 
> char; std::size_t = long unsigned int]’
>   171 |   allocate(size_t __n)
>   |   ^~~~
> /usr/include/c++/10/bits/allocator.h:171:7: note:   candidate expects 1 
> argument, 2 provided
> make[3]: *** 
> [src/algorithms/signal_source/adapters/CMakeFiles/signal_source_adapters.dir/build.make:170:
>  
> src/algorithms/signal_source/adapters/CMakeFiles/signal_source_adapters.dir/osmosdr_signal_source.cc.o]
>  Error 1
> make[3]: *** Waiting for unfinished jobs
> [ 95%] Building CXX object 
> src/algorithms/acquisition/adapters/CMakeFiles/acquisition_adapters.dir/beidou_b3i_pcps_acquisition.cc.o
> cd /<>/obj-x86_64-linux-gnu/src/algorithms/acquisition/adapters 
> && /usr/bin/c++  -DGNSSSDR_INSTALL_DIR=\"/usr\" -D_FILE_OFFSET_BITS=64 
> -D_LARGEFILE_SOURCE -D_LARGE_FILES -I/<>/src/core/interfaces 
> -I/<>/src/algorithms/libs/gsl/include 
> -I/<>/src/algorithms/libs 
> -I/<>/src/algorithms/acquisition/gnuradio_blocks 
> -I/<>/src/algorithms/libs/opencl 
> -I/<>/src/algorithms/acquisition/libs 
> -I/<>/src/core/receiver 
> -I/<>/src/algorithms/channel/libs 
> -I/<>/src/core/system_parameters -isystem /usr/include/glog 
> -isystem 
> /<>/obj-x86_64-linux-gnu/volk_gnsssdr_module/build/include 
> -isystem 
> /<>/src/algorithms/libs/volk_gnsssdr_module/volk_gnsssdr/include 
>  -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
> -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 
> -fvisibility=hidden -fvisibility-inlines-hidden   -Wall -Wextra -std=c++2a -o 
> CMakeFiles/acquisition_adapters.dir/beidou_b3i_pcps_acquisition.cc.o -c 
> /<>/src/algorithms/acquisition/adapters/beidou_b3i_pcps_acquisition.cc
> [ 95%] Building CXX object 
> 

Bug#966488: [Aptitude-devel] Bug#966488: aptitude corrupts package install selection after dpkg error

[Axel Beckert]

Control: severity -1 important

Dear Vincent,

Vincent Lefevre wrote:
> Severity: grave
> Justification: causes non-serious data loss

while I agree that this is "data loss" and that it's anything but
"serious" (and serious is less than grave btw. ;-), I disagree that
this validates the "grave" severity. IMHO it's at most "minor
data-loss". Hence downgrading the severity to important. (My gut
feeling would even say this is "normal" at most.)

Besides that, aptitude for quite a long time, like decades, has the
issue that it saves not all details of actions, e.g. it does only save
that you want to upgrade, but not to which version. Not sure what
happens if that version has a lower preference, it might even ignore
it as it can't find a version to upgrade to with higher preference.

Also not sure if there's even a bug report for that.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#966492: modemmanager: Quectel EC25 wrong supported modes with modemmanager 1.12.12

[jason]

Package: modemmanager
Version: 1.10.0-1
Severity: normal

Dear Maintainer,

I use EC25 with modemmanager 1.12.12(same issue in 1.12.8), I found some
mistakes in supported modes. EC-25 only supports AUTO, GSM only, WCDMA only,
LTE only, TD-SCDMA only, UMTS only, CDMA only, HDR only, CDMA and HDR only. But
mmcli shows as follows:
allowed: 2g; preferred: none
allowed: 3g; preferred: none
allowed: 4g; preferred: none
allowed: 2g, 3g; preferred: 2g
allowed: 2g, 3g; preferred: 3g
allowed: 2g, 4g; preferred: 2g
allowed: 2g, 4g; preferred: 4g
allowed: 3g, 4g; preferred: 3g
allowed: 3g, 4g; preferred: 4g
allowed: 2g, 3g, 4g; preferred: 2g
allowed: 2g, 3g, 4g; preferred: 3g
allowed: 2g, 3g, 4g; preferred: 4g

seems like all of the combinations of 2g, 3g, 4g.



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

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

Versions of packages modemmanager depends on:
ii  libc6  2.28-10
ii  libglib2.0-0   2.58.3-2+deb10u2
ii  libgudev-1.0-0 232-2
ii  libmbim-glib4  1.18.0-1
ii  libmbim-proxy  1.18.0-1
ii  libmm-glib01.10.0-1
ii  libpolkit-gobject-1-0  0.105-25
ii  libqmi-glib5   1.22.0-1.2
ii  libqmi-proxy   1.22.0-1.2
ii  libsystemd0241-7~deb10u3

Versions of packages modemmanager recommends:
ii  usb-modeswitch  2.5.2+repack0-2

modemmanager suggests no packages.

-- no debconf information

Bug#966491: ITP: raku-tap-harness -- TAP test harness for Raku

[Dominique Dumont]

Package: wnpp
Owner: Daniel Dehennin ,
  Dominique Dumont 
Severity: wishlist
X-Debbugs-CC: 
debian-de...@lists.debian.org,pkg-rakudo-de...@lists.alioth.debian.org

* Package name: raku-tap-harness
  Version : 0.1.0-1
  Upstream Author : Leon Timmermans
* URL : https://github.com/perl6/tap-harness6
* License : Artistic-2.0
  Programming Lang: Raku (Perl6)
  Description : TAP test harness for Raku

Provides a TAP based test suite and report printing, in and for Raku
(formerly known as Perl 6)

TAP is the Test Anything Protocol used to Perl and other languages to
communicate results between unit tests and the test harness.

This package and prove6 package (soon to be uploaded) replace perl6-tap-harness

Bug#966490: libpam-geoip does not work with /usr/share/GeoIP/GeoIPCity.dat

[Joerg Dorchain]

Package: libpam-geoip
Version: 2.1.1-1

Hello,

I used to have a working setup with libpam-geoip as 

account required pam_geoip.so debug system_file=/etc/security/geoip.conf 
geoip_db=/usr/share/GeoIP/GeoIPCity.dat

After upgrading to this version, I find in authlog
PASSV: pam_geoip(dovecot:account): failed to open geoip db 
(/usr/share/GeoIP/GeoIPCity.dat - The MaxMind DB file contains invalid metadata)

This renders the geoip line rather useless.

Besides, there is no hint of any potentials incompatibilities
during upgrade, neither an upgrade path mentioned.

FYI, the /usr/share/GeoIP/GeoIPCity.dat on my system is provided
by the package geoip-database-extra version 20181108-1
`
Bye,

Joerg


signature.asc
Description: PGP signature

Bug#965323: postinst script deletes custom locales

[Harald Dunkel]

Can't be worse than not having the locale at all. Not to mention that there is
an option --posix to assure compatibility to POSIX.1-2008, AFAICT. If there are
incompatible changes, then its my job to worry about recreating the custom 
locales.

Since the postinst builds just a subset of all locales and since it even 
maintains
a list about it, I would suggest to erase and rebuild only these locales.

Thanx very much
Harri

Bug#966488: aptitude corrupts package install selection after dpkg error

[Vincent Lefevre]

On 2020-07-29 11:06:16 +0200, Vincent Lefevre wrote:
> An upgrade with aptitude failed due to a dpkg lock error (bug 95).
> Then I noticed that not all packages were upgraded, so that I started
> aptitude again to complete the upgrade. I typed 'g', but got:
> 
> [1(1)/...] Actions: no changes
> e: Examine  !: Apply  .: Next  ,: Previous
> 
> and 'e' gives:
> 
>   --\ Leave the following recommendations unresolved: 
>   
> lcov recommends libgd-gd2-perl
> 
> Since lcov recommends libgd-gd2-perl, this means that it was in
> the package install selection before the initial upgrade (note
> that I didn't have such a warning in the initial upgrade). But
> now libgd-gd2-perl is no longer proposed for installation!

Actually I don't even understand this message as libgd-perl is
already installed and provides libgd-gd2-perl:

cventin:~> dpkg -s libgd-perl
Package: libgd-perl
Status: purge ok installed
Priority: optional
Section: perl
Installed-Size: 392
Maintainer: Debian Perl Group 
Architecture: amd64
Source: libgd-perl (2.71-2)
Version: 2.71-2+b1
Replaces: libgd-gd2-noxpm-perl (<= 1:2.46-2.1), libgd-gd2-perl (<= 1:2.46-3.1)
Provides: libgd-gd2-noxpm-perl, libgd-gd2-perl
[...]

But in the aptitude log (see below), I see that aptitude wanted to
remove libgd-perl (this package is still installed as the upgrade
did not complete due to the dpkg error).

Now, the real issue may be that in its initial dependency resolution,
aptitude missed the Recommends satisfied by the "Provides:", and chose
to remove libgd-perl, breaking the "Recommends:" by doing that.

Aptitude 0.8.13: log report
Wed, Jul 29 2020 10:44:18 +0200

  IMPORTANT: this log only lists intended actions; actions which fail
  due to dpkg problems may not be completed.

Will install 340 packages, and remove 10 packages.
583 MB of disk space will be freed

[REMOVE, NOT USED] g++-9:amd64 9.3.0-15
[REMOVE, NOT USED] gfortran-9:amd64 9.3.0-15
[REMOVE, NOT USED] libflint-2.6.0:amd64 2.6.0-3
[REMOVE, NOT USED] libgc1c2:amd64 1:7.6.4-0.4
[REMOVE, NOT USED] libgd-perl:amd64 2.71-2+b1
[REMOVE, NOT USED] libgfortran-9-dev:amd64 9.3.0-15
[REMOVE, NOT USED] libre2-7:amd64 20200601+dfsg-1
[REMOVE, NOT USED] libssl1.0.2:amd64 1.0.2s-1~deb9u1
[REMOVE, NOT USED] libx264-159:amd64 2:0.159.2999+git296494a-2
[REMOVE, NOT USED] libx264-159:i386 2:0.159.2999+git296494a-2
[HOLD, DEPENDENCIES] linux-compiler-gcc-9-x86:amd64 5.7.6-1
[HOLD, DEPENDENCIES] linux-doc-5.7:amd64 5.7.6-1
[HOLD, DEPENDENCIES] linux-kbuild-5.7:amd64 5.7.6-1
[HOLD, DEPENDENCIES] linux-libc-dev:amd64 5.7.6-1
[INSTALL, DEPENDENCIES] fonts-unifont:amd64 1:13.0.03-1
[INSTALL, DEPENDENCIES] g++-10:amd64 10.2.0-3
[INSTALL, DEPENDENCIES] gfortran-10:amd64 10.2.0-3
[INSTALL, DEPENDENCIES] libaliased-perl:amd64 0.34-1
[INSTALL, DEPENDENCIES] libcompress-raw-bzip2-perl:amd64 2.095-1
[INSTALL, DEPENDENCIES] libcompress-raw-lzma-perl:amd64 2.095-1
[INSTALL, DEPENDENCIES] libcompress-raw-zlib-perl:amd64 2.095-1
[INSTALL, DEPENDENCIES] libdata-dpath-perl:amd64 0.58-1
[INSTALL, DEPENDENCIES] libflint-2.6.1:amd64 2.6.1-1
[INSTALL, DEPENDENCIES] libgc1:amd64 1:8.0.4-1
[INSTALL, DEPENDENCIES] libgfortran-10-dev:amd64 10.2.0-3
[INSTALL, DEPENDENCIES] libio-compress-lzma-perl:amd64 2.095-1
[INSTALL, DEPENDENCIES] libio-compress-perl:amd64 2.095-1
[INSTALL, DEPENDENCIES] libiterator-perl:amd64 0.03+ds1-1
[INSTALL, DEPENDENCIES] libiterator-util-perl:amd64 0.02+ds1-1
[INSTALL, DEPENDENCIES] libre2-8:amd64 20200706+dfsg-2
[INSTALL, DEPENDENCIES] libstdc++-10-dev:amd64 10.2.0-3
[INSTALL, DEPENDENCIES] libtirpc-common:amd64 1.2.6-1
[INSTALL, DEPENDENCIES] libtirpc3:amd64 1.2.6-1
[INSTALL, DEPENDENCIES] libx264-160:amd64 2:0.160.3011+gitcde9a93-2
[INSTALL, DEPENDENCIES] libx264-160:i386 2:0.160.3011+gitcde9a93-2
[HOLD] firefox-esr:amd64 52.9.0esr-1~deb9u1
[HOLD] linux-doc:amd64 5.7.6-1
[HOLD] linux-headers-amd64:amd64 5.7.6-1
[HOLD] linux-image-amd64:amd64 5.7.6-1
[HOLD] linux-libc-dev:i386 5.7.6-1
[HOLD] unison:amd64 2.48.4-1+b1
[HOLD] xterm:amd64 351-1+local1
[UPGRADE] asymptote:amd64 2.66-1 -> 2.66-1+b1
[UPGRADE] binutils:amd64 2.34.90.20200706-1 -> 2.35-1
[UPGRADE] binutils-common:amd64 2.34.90.20200706-1 -> 2.35-1
[UPGRADE] binutils-doc:amd64 2.34.90.20200706-1 -> 2.35-1
[UPGRADE] binutils-i686-linux-gnu:amd64 2.34.90.20200706-1 -> 2.35-1
[UPGRADE] binutils-x86-64-linux-gnu:amd64 2.34.90.20200706-1 -> 2.35-1
[UPGRADE] bison:amd64 2:3.6.3+dfsg-1 -> 2:3.7+dfsg-1
[UPGRADE] bsdextrautils:amd64 2.35.2-7 -> 2.36-1
[UPGRADE] bsdutils:amd64 1:2.35.2-7 -> 1:2.36-1
[UPGRADE] bzip2:amd64 1.0.8-3 -> 1.0.8-4
[UPGRADE] bzip2-doc:amd64 1.0.8-3 -> 1.0.8-4
[UPGRADE] calendar:amd64 12.1.5 -> 12.1.6
[UPGRADE] coreutils:amd64 8.32-2 -> 8.32-3
[UPGRADE] cpp:amd64 4:9.2.1-3.1 -> 4:10.1.0-1
[UPGRADE] cpp-10:amd64 10.1.0-6 -> 10.2.0-3
[UPGRADE] cpp-9:amd64 9.3.0-15 -> 9.3.0-16
[UPGRADE] dictionaries-common:amd64 1.28.1 -> 1.28.2
[UPGRADE] dkms:amd64 2.8.2-2 -> 2.8.3-1
[UPGRADE] 

Bug#897688: RFP: tomboy-ng -- simple note-taking application

[Philipp Huebner]

Hi David,

coworkers of mine are interested in getting tomboy-ng into Debian since
tomboy has been removed.

I am therefore interested in sponsoring uploads and helping out with
mentoring/advice.

The first thing to do would be to turn this RFP into an ITP if you
intend to maintain tomboy-ng in Debian.

Best wishes
-- 
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-



signature.asc
Description: OpenPGP digital signature