Bug#998307: RM: sosi2osm -- ROM; RC buggy, practically dead upstream

[Bas Couwenberg]

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

Please remove sosi2osm from the archive, it's RC buggy and practically dead 
upstream making it highly unlikely to ever get fixed.

Kind Regards,

Bas

Bug#862338: libsmbclient is not multi-arch co-installable due to samba-libs->python-talloc

[Andrew Bartlett]

On Tue, 2021-11-02 at 06:14 +0100, Helmut Grohne wrote:
> Control: tags -1 - patch
> 
> On Mon, Nov 01, 2021 at 10:53:13PM +, Vasyl Gello wrote:
> > I encountered the same issue trying to cross-build Kodi. Johannes
> > advised me to try
> > splitting Python libraries from samba-libs in [1] and I quickly
> > crafted the first
> > draft of the change (see attached debdiff). It solved my issue and
> > the issue
> > reported in this bug:
> 
> Thank you for working on this. Unfortunately, it's not quite ready
> yet.
> Please keep in mind that the reason for this bug being open for so
> long
> most likely is that it is a difficult problem. At least I have stayed
> away from it for that reason.
> 
> Your patch moves files between packages. At the very least that
> requires
> Breaks and Replaces relations. Without them, it will fail piuparts
> and
> receive an rc bug from Andreas Beckmann at best or get angry users at
> worst.
> 
> Then Andrew Bartlett pointed out that other packages may depend on
> that
> functionality via samba-libs. Of course those need to have their
> Depends
> updated and we need another pile of Breaks here. Figuring out what is
> broken is a difficult aspect. An incomplete approach would be running
> every single autopkgtest of every single transitive reverse
> dependency.
> Unfortunately, there is lots of them and it only gives you a lower
> bound
> of what is broken, but you'd really want an upper bound.

My recommendation is that someone works with us upstream to kill samba-
libs, which would reduce the set.  It should be a SUBSYSTEM used by the
python module in the same directory only.

Then work to disable the C->python bindings except in a selftest build
(we don't go C->python in production, only Python -> C).  That will
remove the problem once and for all.

But do this upstream.

Andrew Bartlett
-- 
Andrew Bartlett (he/him)   https://samba.org/~abartlet/
Samba Team Member (since 2001) https://samba.org
Samba Team Lead, Catalyst IT   https://catalyst.net.nz/services/samba

Samba Development and Support, Catalyst IT - Expert Open Source
Solutions

Bug#998306: dwarf2sources FTBFS with rust-object 0.20

[peter green]

Package: dwarf2sources
Version: 0.2.0
Severity: important

I have prepared updates of rust-backtrace and friends, specifically.

rust-backtrace -> 0.3.51
rust-addr2line -> 0.13.0
rust-gimli -> 0.22.0
rust-cpp-demangle -> 0.3.3
rust-object -> 0.20.0

I did not update to the latest versions because debcaro refused to
package the latest version of gimli, complaining about a lack of
authors metadata. So I decided to instead update to the minimum
version that would satisfy the dependencies of librust-anyhow+backtrace-dev

Unfortunately I found that when I tried to build dwarf2sources with the
new packages I got the following error.


error[E0599]: no method named `section_data_by_name` found for reference `&'file 
object::File<'input>` in the current scope
  --> src/main.rs:29:14
   |
29 | .section_data_by_name(S::section_name())
   |   method not found in `&'file 
object::File<'input>`

For more information about this error, try `rustc --explain E0599`.
error: could not compile `dwarf2sources` due to previous error


Digging in the upstream commit log lead me to 
https://github.com/gimli-rs/object/commit/85abdca55d62c3fa77bfb85a6d4089d57b139759
reading though that commit suggested that I would replace section_data_by_name 
with section_by_name, however when I tried that
I got the following error.


error[E0308]: mismatched types
  --> src/main.rs:30:24
   |
30 | .unwrap_or(Cow::Borrowed(&[]));
   |^^ expected struct 
`object::Section`, found enum `Cow`
   |
   = note: expected struct `object::Section<'_, '_>`
found enum `Cow<'_, [_; 0]>`

error[E0308]: mismatched types
  --> src/main.rs:31:38
   |
31 | let data_ref = (*arena.alloc(data)).borrow();
   |   expected enum `Cow`, found 
struct `object::Section`
   |
   = note: expected enum `Cow<'file, [u8]>`
found struct `object::Section<'_, '_>`

For more information about this error, try `rustc --explain E0308`.
error: could not compile `dwarf2sources` due to 2 previous errors


Which I have no clue how to fix.

I have uploaded rust-backtrace and related packages to experimental for now.

Bug#862338: libsmbclient is not multi-arch co-installable due to samba-libs->python-talloc

[Helmut Grohne]

Control: tags -1 - patch

On Mon, Nov 01, 2021 at 10:53:13PM +, Vasyl Gello wrote:
> I encountered the same issue trying to cross-build Kodi. Johannes advised me 
> to try
> splitting Python libraries from samba-libs in [1] and I quickly crafted the 
> first
> draft of the change (see attached debdiff). It solved my issue and the issue
> reported in this bug:

Thank you for working on this. Unfortunately, it's not quite ready yet.
Please keep in mind that the reason for this bug being open for so long
most likely is that it is a difficult problem. At least I have stayed
away from it for that reason.

Your patch moves files between packages. At the very least that requires
Breaks and Replaces relations. Without them, it will fail piuparts and
receive an rc bug from Andreas Beckmann at best or get angry users at
worst.

Then Andrew Bartlett pointed out that other packages may depend on that
functionality via samba-libs. Of course those need to have their Depends
updated and we need another pile of Breaks here. Figuring out what is
broken is a difficult aspect. An incomplete approach would be running
every single autopkgtest of every single transitive reverse dependency.
Unfortunately, there is lots of them and it only gives you a lower bound
of what is broken, but you'd really want an upper bound.

And finally, there is a process issue. For moving things around, the
usual process is:

1. Prepare
  * Move files from package A to package B.
  * Let B declare Breaks + Replaces on A.
  * Have A depend on B.
2. Transition
  * Update all packages that require the moved functionality to depend
on B instead of or in addition to A.
3. Cleanup
  * Drop dependency of A on B.
  * Add Breaks to all pre-updated packages to A.

Usually, you miss something in step 2, so you proceed to step 3 after
having found the big chunk and later redo step three a few times after
finding the remainders.

So really, this problem is worth solving. It affects a lot of packages.
But if it was simple to solve, we'd already have done it. Expect to
spend at least a week on this and a bigger chunk of CPU days.

Helmut

Bug#996814: Missing import and export in Kaddressbook

[Norbert Preining]

Hi all,

> I think, package kdepim-addons needs libkpimaddressbookimportexport-dev as 

Confirmed. Uploading a new package in a minute. Thanks a lot!

Norbert

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

Bug#997476: python-uvicorn: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 returned exit code 13

[Sandro Tosi]

> > === FAILURES 
> > ===
> > _ test_supported_upgrade_request[H11Protocol] 
> > __
> >
> > protocol_cls = 
> >
> > @pytest.mark.parametrize("protocol_cls", HTTP_PROTOCOLS)
> > def test_supported_upgrade_request(protocol_cls):
> > app = Response("Hello, world", media_type="text/plain")
> >
> > protocol = get_connected_protocol(app, protocol_cls, ws="wsproto")
> > protocol.data_received(UPGRADE_REQUEST)
> >
> > >   assert b"HTTP/1.1 426 " in protocol.transport.buffer
> > E   AssertionError: assert b'HTTP/1.1 426 ' in b'HTTP/1.1 400 
> > \r\nSec-WebSocket-Version: 13\r\ncontent-length: 0\r\n\r\n'
> > E+  where b'HTTP/1.1 400 \r\nSec-WebSocket-Version: 
> > 13\r\ncontent-length: 0\r\n\r\n' =  > 0x7f5dfc10cf10>.buffer
> > E+where  = 
> >  > 0x7f5dfc104fd0>.transport
> >
> > tests/protocols/test_http.py:685: AssertionError
> > __ test_supported_upgrade_request[HttpToolsProtocol] 
> > ___
> >
> > protocol_cls =  > 'uvicorn.protocols.http.httptools_impl.HttpToolsProtocol'>
> >
> > @pytest.mark.parametrize("protocol_cls", HTTP_PROTOCOLS)
> > def test_supported_upgrade_request(protocol_cls):
> > app = Response("Hello, world", media_type="text/plain")
> >
> > protocol = get_connected_protocol(app, protocol_cls, ws="wsproto")
> > protocol.data_received(UPGRADE_REQUEST)
> >
> > >   assert b"HTTP/1.1 426 " in protocol.transport.buffer
> > E   AssertionError: assert b'HTTP/1.1 426 ' in b'HTTP/1.1 400 
> > \r\nSec-WebSocket-Version: 13\r\ncontent-length: 0\r\n\r\n'
> > E+  where b'HTTP/1.1 400 \r\nSec-WebSocket-Version: 
> > 13\r\ncontent-length: 0\r\n\r\n' =  > 0x7f5dfb815af0>.buffer
> > E+where  = 
> >  > 0x7f5dfb815670>.transport

This is due to the version of uvicorn in the archive is not compatible
with wsproto 1.0.0, https://github.com/encode/uvicorn/issues/868;
that's fixed in https://github.com/encode/uvicorn/pull/892 which was
released in 0.14.0 and 0.15.0.

I've started upgrading the package in git to 0.15.0, but that requires
a newer version of httpx than the one in the archive and that requires
python-charset-normalizer, which is currently in NEW.

uvicorn unittests are also failing, apparently because a test HTTP
daemon on port 8000 is not running, i've opened
https://github.com/encode/uvicorn/discussions/1231 asking for help

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

Bug#998305: ITP: flowchar -- a tiny tool for conversion from pseudo-code to flowchart

[YaNing Lu]

Package: wnpp
Severity: wishlist
Owner: Lu YaNing 

* Package name: flowchar
  Version : 1.1-1
  Upstream Author : Gusabary 
* URL : https://github.com/Gusabary/FlowChar
* License : MIT
  Programming Lang: C++
  Description : a tiny tool for conversion from pseudo-code to flowchart.

flowchar is a tiny tool for conversion from pseudo-code to flowchart
in character format.

This is a very interesting and useful tool.

-- 
Thanks,
Lu YaNing

Bug#994920: RFS: simple-image-filter [ITP] -- Image processing software

[YaNing Lu]

Hi Hi Bastian,
The following post 1.1.0 submission was deleted due to licensing issues and
has been communicated to upstream authors.
https://github.com/dependon/simple-image-filter/commit/c753ac8fdac4ad07c374751eb84f970829a04a76

Regards,
--
  Lu YaNing

Bastian Germann  于2021年11月1日周一 上午8:26写道：

> Control: tags -1 - moreinfo
>
> I cannot find those license issues after 1.1.0. I can see that in
> c753ac8fdac4ad07c374751eb84f970829a04a76 some files were deleted.
> But they are all GPL-3+, so they should not be the problem.
>

Bug#998304: ITP: qalculate-qt -- Powerful and easy to use desktop calculator - Qt version

[Norbert Preining]

Package: wnpp
Severity: wishlist
Owner: Norbert Preining 
X-Debbugs-Cc: debian-de...@lists.debian.org, team+qalcul...@tracker.debian.org

* Package name: qalculate-qt
  Version : 3.21.0
  Upstream Author : Hanna Knutsson 
* URL : https://github.com/Qalculate/qalculate-qt
* License : GPL-2.0-or-later
  Programming Lang: C++
  Description : Powerful and easy to use desktop calculator - Qt version

Qalculate! is small and simple to use but with much power and versatility
underneath.  Features include customizable functions, units, arbitrary
precision, plotting, and a graphical interface that uses a one-line
fault-tolerant expression entry (although it supports optional traditional
buttons).

This package contains the Qt user interface of qalculate.

Bug#998303: pulseaudio: Loud thumps in speakers at hibernation and resume with analog audio output.

[patrick]

Package: pulseaudio
Version: 15.0+dfsg1-2
Severity: important
X-Debbugs-Cc: blackwhite...@gmail.com




-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

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

Versions of packages pulseaudio depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  libasound2   1.2.4-1.1
ii  libasound2-plugins   1.2.2-2
ii  libc62.31-13+deb11u2
ii  libcap2  1:2.44-1
ii  libdbus-1-3  1.12.20-2
ii  libfftw3-single3 3.3.8-2
ii  libgcc-s110.2.1-6
ii  libglib2.0-0 2.66.8-1
ii  libice6  2:1.0.10-1
ii  libltdl7 2.4.6-15
ii  liborc-0.4-0 1:0.4.32-1
ii  libpulse015.0+dfsg1-2
ii  libsm6   2:1.2.3-1
ii  libsndfile1  1.0.31-2
ii  libsoxr0 0.1.3-4
ii  libspeexdsp1 1.2~rc1.2-1.1
ii  libstdc++6   10.2.1-6
ii  libsystemd0  247.3-6
ii  libtdb1  1.4.3-1+b1
ii  libudev1 247.3-6
ii  libwebrtc-audio-processing1  0.3-1+b1
ii  libx11-6 2:1.7.2-1
ii  libx11-xcb1  2:1.7.2-1
ii  libxcb1  1.14-3
ii  libxtst6 2:1.2.3-1
ii  lsb-base 11.1.0
ii  pulseaudio-utils 15.0+dfsg1-2

Versions of packages pulseaudio recommends:
ii  dbus-user-session1.12.20-2
ii  libpam-systemd [logind]  247.3-6
ii  rtkit0.13-4

Versions of packages pulseaudio suggests:
pn  paprefs  
pn  pavucontrol  
pn  pavumeter
ii  udev 247.3-6

-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; enable-memfd = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB
; lock-memory = no
; cpu-limit = no

; high-priority = yes
; nice-level = -11

; realtime-scheduling = yes
; realtime-priority = 5

; exit-idle-time = 20
; scache-idle-time = 20

; dl-search-path = (depends on architecture)

; load-default-script-file = yes
; default-script-file = /etc/pulse/default.pa

; log-target = auto
; log-level = notice
; log-meta = no
; log-time = no
; log-backtrace = 0

; resample-method = speex-float-1
; avoid-resampling = false
; enable-remixing = yes
; 

Bug#993824: transition: libqalculate

[Norbert Preining]

Hi Sebastian, hi Phil,

> > Any news regarding libqalculate20-data?

Since it has been ages without a response, I took the liberty to upload
the current status to unstable.

I am now preparing also 3.21.0

Best

Norbert

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

Bug#973313: lintian: Salsa CI jobs fail for many sources hosted there

[Colin Watson]

I have a reproduction recipe that doesn't involve Salsa CI:

 * Start a clean buster virtual machine.  (I used LXD, with "lxc launch
   --vm images:debian/buster", but any VM software will probably do.)
 * In the VM:
   - apt update && apt install -y docker.io man-db
   - docker pull debian:unstable
   - docker run --rm --privileged debian:unstable /bin/sh -c 'apt-get update && 
apt-get install -y man-db && LC_ALL=C.UTF-8 man --version'

Installing man-db in the VM alongside Docker is vital, as is using
--privileged.  The following message appears in dmesg in the VM:

  [  665.609594] audit: type=1400 audit(1635817161.488:11): apparmor="DENIED" 
operation="open" info="Failed name lookup - disconnected path" error=-13 
profile="/usr/bin/man" 
name="var/lib/docker/overlay2/3fd16b80cd6bf5eaac5175310673d6d76c288b560b0dd1994908f957825eb8fa/diff/usr/lib/locale/C.UTF-8/LC_MESSAGES"
 pid=6221 comm="man" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

Interestingly, a bullseye VM does *not* exhibit the same issue, which
suggests that it may be possible to track down a change to the kernel,
AppArmor userspace, or Docker that fixed this (I'm guessing as to
plausible packages).  I haven't tried that yet since it's 2am here, but
maybe somebody else can run with this.

This seems related to https://github.com/moby/moby/issues/38420, but I'm
not sure it's exactly the same thing as that upstream bug so perhaps
that's a red herring.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#993905: lxc-create fails GPG checkserver due to keyserver depreciation

[Kyle Spam marketing]

> Normally I'd send a message to 993905-d...@bugs.debian.org to close the
bug
> with the mentioned version, but I have a feeling that this issue is
primarily
> about a backported fix to stable and oldstable?
> Can you confirm that?

Yes, that is correct. So manually specifying a working key server would not
be required in order to use lxc-create for normal use.

>The sks-keyservers.net https certificate expired on 2021-04-23 and last
time I
> checked, it's completely defunct, so it's even worse then 'deprecated'.

Correct. Unfortunately the entire project was forced to shut down due to
issues complying with GDPR requirements.

On Thu, Oct 28, 2021 at 7:00 PM Diederik de Haas 
wrote:

> Control: fixed -1 1:4.0.10-1
>
> On Tue, 07 Sep 2021 20:21:12 -0400 Kyle  wrote:
> > Package: lxc
> > Version: 1:4.0.6-2
> >
> > lxc-create fails with the following error message caused by
> > sks-keyservers.net going offline, The lxc package currently in testing
> > includes a patch that fixes the issue by changing the keyserver from
> > pool.sks-keyservers.net to keyserver.ubuntu.com.
>
> Yes and the fix is part of version 4.0.10-1, so marking it accordingly.
>
> > This impacts both oldstable and stable as of writing this.
> >
> > -- System Information:
> > Debian Release: 11.0
> >   APT prefers stable-security
> >   APT policy: (500, 'stable-security'), (500, 'stable')
>
> Normally I'd send a message to 993905-d...@bugs.debian.org to close the
> bug
> with the mentioned version, but I have a feeling that this issue is
> primarily
> about a backported fix to stable and oldstable?
> Can you confirm that?
>
> The sks-keyservers.net https certificate expired on 2021-04-23 and last
> time I
> checked, it's completely defunct, so it's even worse then 'deprecated'.
>
> Cheers,
>   Diederik

Bug#983229: proj transition has started

[Olly Betts]

On Tue, Oct 26, 2021 at 05:35:48AM +0200, Sebastiaan Couwenberg wrote:
> PROJ 8.2.0 is scheduled for release next week, just wait for that.

Oh, I see this has been uploaded.  I'll try to sort out updating the
survex package to use it.

Cheers,
Olly

Bug#966382: RFS: photoprint/0.4.2~pre2-3 -- Image printing utility

[François Mazen]

Hi Bastian,

the package is fixed and I've uploaded new version at mentors:
https://mentors.debian.net/package/photoprint/


Best,
François


Le jeudi 28 octobre 2021 à 22:37 +0200, Bastian Germann a écrit :
> Control: tags -1 moreinfo
> 
> The package fails to build from scratch:
> https://salsa.debian.org/debian/photoprint/-/jobs/2124003
> 
> Please fix it and then remove the moreinfo tag.
> 



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

Bug#997386: libnss3: cannot co-install libnss3-dbgsym:amd64 and libnss3-dbgsym:i386

[Mike Hommey]

On Sat, Oct 23, 2021 at 07:54:05PM +, Witold Baryluk wrote:
> Package: libnss3
> Version: 2:3.70-1
> Severity: important
> X-Debbugs-Cc: witold.bary...@gmail.com
> 
> As in title.
> 
> apt install libnss3-dbgsym:amd64 libnss3-dbgsym:i386
> 
> causes a conflict and failure:
> 
> 
> The following packages have unmet dependencies:
>  libnss3-dbgsym : Conflicts: libnss3-dbgsym:i386 but 2:3.70-1 is to be 
> installed
>  libnss3-dbgsym:i386 : Conflicts: libnss3-dbgsym but 2:3.70-1 is to be 
> installed

I don't know where these conflicts would come from. Not from the
package, at least:

$ wget 
http://snapshot.debian.org/archive/debian-debug/20210908T025327Z/pool/main/n/nss/libnss3-dbgsym_3.70-1_amd64.deb
$ dpkg -I libnss3-dbgsym_3.70-1_amd64.deb
 new Debian package, version 2.0.
 size 5326012 bytes: control archive=984 bytes.
 774 バイト、   14 行  control
 954 バイト、9 行  md5sums
 Package: libnss3-dbgsym
 Source: nss
 Version: 2:3.70-1
 Auto-Built-Package: debug-symbols
 Architecture: amd64
 Maintainer: Maintainers of Mozilla-related packages 

 Installed-Size: 5939
 Depends: libnss3 (= 2:3.70-1)
 Breaks: libnss3-dbg (<< 2:3.37-1~)
 Replaces: libnss3-dbg (<< 2:3.37-1~)
 Section: debug
 Priority: optional
 Description: debug symbols for libnss3
 Build-Ids: 2210ba11fe9481c172ba1969fd3d998c9b6c46fa 
288034785b5563a15acaca0d6e1a3a73785aa1fd 
48cf1be391fed01c9e46683309742ba05f9eb478 
7466955093731977b0d600a4491e848360750f5b 
8017c0d0d462eac86bab2d075e95cb377e0a969d 
80977bd1219b7cbdc44b3b5f0b5c4809a9b6f915 
b2f50ce30032950fcb7ae2b5b6ea849e7e4555d4 
beea65445f297154fddce58abc7b2742542cfefb 
f326dea22c916a7a8f6775264b0ea0536ed42d8a

Mike

Bug#994275: Reverting breaking changes in debianutils

[Sean Whitton]

Hello,

On Fri 29 Oct 2021 at 09:57AM +02, Raphael Hertzog wrote:

> I have sympathy with your reasoning and I can certainly relate to things
> that we did 20 years ago, where we happily broke unstable after a release
> but we have changed.
>
> Yes, on some aspects we have become more conservative. I certainly wish
> to change that, but not by going backwards, but by providing new avenues
> to experiment and make large-scale changes without breaking unstable/testing.

I'd like to express disagreement with the characterisation that breaking
unstable/testing more often for the sake of making major changes would
always count as going backwards.

Of course we should be exploring the new avenues that you mention.  But
becoming more willing to break unstable/testing than we are at present
might also be good for our project.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#998165: debian-policy: document and allow Description in the source paragraph

[Sean Whitton]

Hello,

On Sun 31 Oct 2021 at 11:18AM +01, Mattia Rizzolo wrote:

> Package: debian-policy
> Version 4.6.0.0
>
> Hi!
>
> dpkg 1.19.0 introduced, following the request in #555743, a bunch of new
> substvars.  Notably, it now handles ${source:Synopsis} and
> ${source:Extended-Description} that are described as follow:
>
>source:Synopsis
>The source package synopsis, extracted from the source stanza
>Description field, if it exists
>
>source:Extended-Description
>The source package extended description, extracted from the
>source stanza Description field, if it exists
>
>
> Currently Policy §5.2 lists the allowed known fields, and Description is
> accepted only in the "binary package paragraphs", not in the one for the
> source package.
>
>
> As documented in the bug report mentioned above, these are the main
> benefits of having a Description in the source paragraph:
>  * helps de-duplicate the description in the binary paragraphs (mostly
>relevant for libraries and other packages that build many binaries
>and share a common description).  Note that this would only
>de-duplicate d/control, the binary DEBIAN/control of each binary
>package would still keep the generated long description.
>  * ship a generic source-level descrption of the package, which just
>make sense if one thinks about it
>  * as a consequence of the above, a bunch of tools (DDPO, PTS, etc)
>would be able to drop the weird and unnatural logic that they use to
>pick a description for the source package
> The main "bad" consequence would be that Description would be exported
> in the .dsc and as such end up in the Sources index.  This is probably
> what we want anyway, but with all the people complaining about how big
> the index is getting it's something to consider.  However it's also true
> that realistically very few packages are going to make use of this
> facility in the near future so it shouldn't really matter IMHO.

Hrm.  Could dak be modified to filter this out of the Sources file?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#998302: debian-history: Please set "Rules-Requires-Root: no" in debian/control

[Vagrant Cascadian]

Package: debian-history
Severity: minor
Tags: patch

The debian-history package appears to build fine with
Rules-Requires-Root set to "no", allowing the package to be built
without fakeroot or any form of (emulated) root access.

See debian-policy:

  5.6.31. "Rules-Requires-Root"


Thanks for maintaining debian-history!


live well,
  vagrant


diff --git a/debian/control b/debian/control
index 3b489e5..bd6ee95 100644
--- a/debian/control
+++ b/debian/control
@@ -20,6 +20,7 @@ Build-Depends-Indep: dblatex,
  xsltproc,
  zip
 Standards-Version: 4.6.0
+Rules-Requires-Root: no
 Homepage: https://www.debian.org/doc/misc-manuals#history
 Vcs-Git: https://salsa.debian.org/ddp-team/project-history.git
 Vcs-Browser: https://salsa.debian.org/ddp-team/project-history


signature.asc
Description: PGP signature

Bug#996923: apt-listbugs: page long buglists

[Moshe Piekarski]

> Please let me know, in case I am missing the point.
This works, although I find it strange that setpriv is called without
--reset-env

Sincerely,

Moshe Piekarski

--

There's no such thing as a stupid question,

But there are plenty of inquisitive idiots.

Bug#732683: ITP: golang-github-juju-gnuflag -- GNU-compatible flag handling with a stdlib-like API for Go

[Mathias Gibbens]

retitle 732683 ITP: golang-github-juju-gnuflag -- GNU-compatible flag handling 
with a stdlib-like API for Go
owner !
thanks

* Package name: golang-github-juju-gnuflag
  Version : 0.0~git20171113.2ce1bb7-1
  Upstream Author : The Go Authors
* URL : https://github.com/juju/gnuflag
* License : BSD-3-clause
  Programming Lang: Go
  Description : GNU-compatible flag handling with a stdlib-like API for Go

 The gnuflag package is a fork of the Go standard library package that
supports GNU-compatible flag syntax.
 .
 In particular, it supports --longflag and -l single-character flag
syntax.

Since the initial ITP was filed, the project has moved from
https://launchpad.net/gnuflag to https://github.com/juju/gnuflag. This
package is a common dependency for several different Go libraries that
are dependencies for packaging LXD (ITP #768073).

This package will be team-maintained within the Debian Go Packaging
Team.


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

Bug#998216: plasma-workspace: xembedsniproxy, Xorg and kwin_x11 use 100% CPU when I run two electron apps

[Norbert Preining]

tags 998216 + unreproducible moreinfo
thanks

Hi Patrick,

> When I run two electron apps in the current plasma-workspace the UI is very 
> laggy

I am running three or more (Element, Ferdi, Signal, Telegram) and don't
see anything similar.

> - the bug was introduced by the 5.23 update of plasma-workspace (or kwin)
> - killing one of the apps resolves the problem at any time
> - it happens only using X.org, not on Wayland
> - the apps are reporting no errors and work in general, only very laggy

Very strange, nothing I see on my computer, though. CPU is eaten by
which process? Maybe IO bound?

Best

Norbert

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

Bug#862338: libsmbclient is not multi-arch co-installable due to samba-libs->python-talloc

[Andrew Bartlett]

Does samba-libs depend on samba-python3?

If not, then you will break some operations (not a massive lot, but not
nothing). 

It is also a configuration not at all tested upstream, and prone to
further breakage. 

I think libsamba-policy is probably better in samba-python3, or
removed.  It is unclear why this library is shipped, but that should be
an upstream discussion.

Andrew Bartlett

On Mon, 2021-11-01 at 22:53 +, Vasyl Gello wrote:
> Source: samba
> Version: 2:4.13.5+dfsg-2
> Followup-For: Bug #862338
> X-Debbugs-Cc: sath...@debian.org, jo...@debian.org, 
> debian-cr...@lists.debian.org
> 
> Control: found -1 2:4.13.13+dfsg-1
> Control: tag -1 patch
> 
> Dear colleagues,
> 
> I encountered the same issue trying to cross-build Kodi. Johannes
> advised me to try
> splitting Python libraries from samba-libs in [1] and I quickly
> crafted the first
> draft of the change (see attached debdiff). It solved my issue and
> the issue
> reported in this bug:
> 
> 
> root@debian-development:/# apt-get install -s --no-install-recommends 
> libsmbclient-dev:native libsmbclient-dev:armhf
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> The following additional packages will be installed:
>   gcc-11-base:armhf libacl1:armhf libaudit1:armhf libavahi-
> client3:armhf libavahi-client3 libavahi-common-data libavahi-common-
> data:armhf
>   libavahi-common3:armhf libavahi-common3 libbsd0 libbsd0:armhf
> libc6:armhf libcap-ng0:armhf libcap2:armhf libcom-err2:armhf libcups2
> libcups2:armhf
>   libdb5.3:armhf libdbus-1-3:armhf libdbus-1-3 libffi8:armhf libgcc-
> s1:armhf libgcrypt20:armhf libgmp10:armhf libgnutls30:armhf libgpg-
> error0:armhf
>   libgssapi-krb5-2:armhf libhogweed6:armhf libicu67 libicu67:armhf
> libidn2-0:armhf libjansson4 libjansson4:armhf libk5crypto3:armhf
> libkeyutils1:armhf
>   libkrb5-3:armhf libkrb5support0:armhf libldap-2.4-2 libldap-2.4-
> 2:armhf libldb2 libldb2:armhf liblmdb0 liblz4-1:armhf liblzma5:armhf
> libmd0 libmd0:armhf
>   libnettle8:armhf libnsl2:armhf libp11-kit0:armhf libpam0g:armhf
> libpopt0 libpopt0:armhf libsasl2-2 libsasl2-2:armhf libsasl2-modules-
> db
>   libsasl2-modules-db:armhf libsmbclient:armhf libsmbclient
> libssl1.1:armhf libstdc++6:armhf libsystemd0:armhf libtalloc2
> libtalloc2:armhf libtasn1-6:armhf
>   libtdb1 libtdb1:armhf libtevent0 libtevent0:armhf libtirpc3:armhf
> libunistring2:armhf libwbclient0 libwbclient0:armhf libzstd1:armhf
> samba-libs
>   samba-libs:armhf zlib1g:armhf
> Suggested packages:
>   glibc-doc:armhf libc-l10n:armhf locales:armhf libnss-nis:armhf
> libnss-nisplus:armhf cups-common cups-common:armhf rng-tools:armhf
> gnutls-bin:armhf
>   krb5-doc:armhf krb5-user:armhf libpam-doc:armhf
> Recommended packages:
>   dbus:armhf dbus libgpg-error-l10n:armhf krb5-locales:armhf libldap-
> common libldap-common:armhf libsasl2-modules libsasl2-modules:armhf
> The following NEW packages will be installed:
>   gcc-11-base:armhf libacl1:armhf libaudit1:armhf libavahi-
> client3:armhf libavahi-client3 libavahi-common-data libavahi-common-
> data:armhf
>   libavahi-common3:armhf libavahi-common3 libbsd0 libbsd0:armhf
> libc6:armhf libcap-ng0:armhf libcap2:armhf libcom-err2:armhf libcups2
> libcups2:armhf
>   libdb5.3:armhf libdbus-1-3:armhf libdbus-1-3 libffi8:armhf libgcc-
> s1:armhf libgcrypt20:armhf libgmp10:armhf libgnutls30:armhf libgpg-
> error0:armhf
>   libgssapi-krb5-2:armhf libhogweed6:armhf libicu67 libicu67:armhf
> libidn2-0:armhf libjansson4 libjansson4:armhf libk5crypto3:armhf
> libkeyutils1:armhf
>   libkrb5-3:armhf libkrb5support0:armhf libldap-2.4-2 libldap-2.4-
> 2:armhf libldb2 libldb2:armhf liblmdb0 liblz4-1:armhf liblzma5:armhf
> libmd0 libmd0:armhf
>   libnettle8:armhf libnsl2:armhf libp11-kit0:armhf libpam0g:armhf
> libpopt0 libpopt0:armhf libsasl2-2 libsasl2-2:armhf libsasl2-modules-
> db
>   libsasl2-modules-db:armhf libsmbclient:armhf libsmbclient
> libsmbclient-dev libsmbclient-dev:armhf libssl1.1:armhf
> libstdc++6:armhf libsystemd0:armhf
>   libtalloc2 libtalloc2:armhf libtasn1-6:armhf libtdb1 libtdb1:armhf
> libtevent0 libtevent0:armhf libtirpc3:armhf libunistring2:armhf
> libwbclient0
>   libwbclient0:armhf libzstd1:armhf samba-libs samba-libs:armhf
> zlib1g:armhf
> 0 upgraded, 78 newly installed, 0 to remove and 0 not upgraded.
> Inst gcc-11-base:armhf (11.2.0-10 Debian:unstable [armhf])
> Inst libgcc-s1:armhf (11.2.0-10 Debian:unstable [armhf]) []
> Inst libc6:armhf (2.32-4 Debian:unstable [armhf])
> Inst libacl1:armhf (2.3.1-1 Debian:unstable [armhf])
> Inst libavahi-common-data:armhf (0.8-5 Debian:unstable [armhf])
> Inst libavahi-common3:armhf (0.8-5 Debian:unstable [armhf])
> Inst libcap2:armhf (1:2.44-1 Debian:unstable [armhf])
> Inst libgpg-error0:armhf (1.42-3 Debian:unstable [armhf])
> Inst libgcrypt20:armhf (1.9.4-3+b1 Debian:unstable [armhf])
> Inst liblz4-1:armhf (1.9.3-2 Debian:unstable [armhf])
> Inst liblzma5:armhf (5.2.5-2 Debian:unstable [armhf])

Bug#998301: ITP: golang-github-juju-cmd -- A command line implementation framework

[Mathias Gibbens]

Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-juju-cmd
  Version : 0.0~git20210809.65029dab-1
  Upstream Author : Canonical Ltd
* URL : https://github.com/juju/cmd
* License : LGPL-3.0-with-exception
  Programming Lang: Go
  Description : A command line implementation framework

This package is a common dependency for several different Go libraries
that are dependencies for packaging LXD (ITP #768073).

This package will be team-maintained within the Debian Go Packaging
Team.


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

Bug#998212: easytag: overwrites tags containing UTF8 data with random rubbish

[Norbert Preining]

Hi

> What kind of files / tags did you process with easytag? If these files

that were mp3, not sure about what version of tags since they were gone
afterwards. At least they displayed fine in all music players I used.
But yes, I guess it is common here in Japan that id3v1 tags are coded in
UTF8 (or even ShiftJIS).

I still consider overwriting tags when there was an error during
preparation, irrespective of the correctness of the original tags,
a serious problem. easytag should *not* write broken tags.

Best

Norbert

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

Bug#998300: ITP: golang-github-juju-mutex -- Provides a named machine level mutex shareable between processes

[Mathias Gibbens]

Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-juju-mutex
  Version : 0.0~git20180619.d21b13a-1
  Upstream Author : Canonical Ltd
* URL : https://github.com/juju/mutex
* License : LGPL-3.0-with-exception
  Programming Lang: Go
  Description : Provides a named machine level mutex shareable between 
processes

 The mutex package provides a named machine level mutex shareable
between processes.

This ITP reintroduces the golang-github-juju-mutex package to the
archive. It was previously RM'ed in #913968 as no packages depended on
it.

This package is a dependency for updating golang-github-juju-utils as
part of the process of packaging LXD (ITP #768073).

This package will be team-maintained within the Debian Go Packaging
Team.


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

Bug#998299: ITP: golang-github-juju-clock -- Clock definition and testing clock

[Mathias Gibbens]

Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-juju-clock
  Version : 0.0~git20190205.9c5c971-1
  Upstream Author : Canonical Ltd
* URL : https://github.com/juju/clock
* License : LGPL-3.0-with-exception
  Programming Lang: Go
  Description : Clock definition and testing clock

 An interface definition for a fully defined clock. A WallClock
 implementation of that interface using the time package. A
 testing clock.

This ITP reintroduces the golang-github-juju-clock package to the
archive. It was previously RM'ed in #911006 as no packages depended on
it.

This package is a common dependency for several different Go libraries
that are dependencies for packaging LXD (ITP #768073).

This package will be team-maintained within the Debian Go Packaging
Team.


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

Bug#989284: insserv: toggles rc0.d/{K02avahi-daemon => K01avahi-daemon} with every upgrade

[Jesse Smith]

On 2021-11-01 4:23 p.m., Mark Hindley wrote:
> -- System Information:
>> Debian Release: 11.0
>>   APT prefers unreleased
>>   APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 
>> 'unstable'), (100, 'experimental')
>> Architecture: x32 (x86_64)
>> Foreign Architectures: i386, amd64
> I realise this may be clutching at straws, but is there any chance the x32 
> arch
> is the trigger for this?
>
> I don't see any other discrepancies.
That's an interesting idea. Given everything else we've tried I'm open
to the possibility. I didn't realize until you mentioned it that Debian
even supported x32 builds these days.

Bug#798013: #798013: doc-debian: useless "Suggests: postscript-viewer, www-browser"

[Joost van Baal-Ilić]

tags #798013 +pending
thanks

Fixed in git at [master 8419b97].  Thanks Jakub Wilk!

Bug#862338: libsmbclient is not multi-arch co-installable due to samba-libs->python-talloc

[Vasyl Gello]

Control: found -1 2:4.13.13+dfsg-1
Control: tag -1 patch

And again the control directive not there :(((
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#862338: libsmbclient is not multi-arch co-installable due to samba-libs->python-talloc

[Vasyl Gello]

Source: samba
Version: 2:4.13.5+dfsg-2
Followup-For: Bug #862338
X-Debbugs-Cc: sath...@debian.org, jo...@debian.org, 
debian-cr...@lists.debian.org

Control: found -1 2:4.13.13+dfsg-1
Control: tag -1 patch

Dear colleagues,

I encountered the same issue trying to cross-build Kodi. Johannes advised me to 
try
splitting Python libraries from samba-libs in [1] and I quickly crafted the 
first
draft of the change (see attached debdiff). It solved my issue and the issue
reported in this bug:


root@debian-development:/# apt-get install -s --no-install-recommends 
libsmbclient-dev:native libsmbclient-dev:armhf
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  gcc-11-base:armhf libacl1:armhf libaudit1:armhf libavahi-client3:armhf 
libavahi-client3 libavahi-common-data libavahi-common-data:armhf
  libavahi-common3:armhf libavahi-common3 libbsd0 libbsd0:armhf libc6:armhf 
libcap-ng0:armhf libcap2:armhf libcom-err2:armhf libcups2 libcups2:armhf
  libdb5.3:armhf libdbus-1-3:armhf libdbus-1-3 libffi8:armhf libgcc-s1:armhf 
libgcrypt20:armhf libgmp10:armhf libgnutls30:armhf libgpg-error0:armhf
  libgssapi-krb5-2:armhf libhogweed6:armhf libicu67 libicu67:armhf 
libidn2-0:armhf libjansson4 libjansson4:armhf libk5crypto3:armhf 
libkeyutils1:armhf
  libkrb5-3:armhf libkrb5support0:armhf libldap-2.4-2 libldap-2.4-2:armhf 
libldb2 libldb2:armhf liblmdb0 liblz4-1:armhf liblzma5:armhf libmd0 libmd0:armhf
  libnettle8:armhf libnsl2:armhf libp11-kit0:armhf libpam0g:armhf libpopt0 
libpopt0:armhf libsasl2-2 libsasl2-2:armhf libsasl2-modules-db
  libsasl2-modules-db:armhf libsmbclient:armhf libsmbclient libssl1.1:armhf 
libstdc++6:armhf libsystemd0:armhf libtalloc2 libtalloc2:armhf libtasn1-6:armhf
  libtdb1 libtdb1:armhf libtevent0 libtevent0:armhf libtirpc3:armhf 
libunistring2:armhf libwbclient0 libwbclient0:armhf libzstd1:armhf samba-libs
  samba-libs:armhf zlib1g:armhf
Suggested packages:
  glibc-doc:armhf libc-l10n:armhf locales:armhf libnss-nis:armhf 
libnss-nisplus:armhf cups-common cups-common:armhf rng-tools:armhf 
gnutls-bin:armhf
  krb5-doc:armhf krb5-user:armhf libpam-doc:armhf
Recommended packages:
  dbus:armhf dbus libgpg-error-l10n:armhf krb5-locales:armhf libldap-common 
libldap-common:armhf libsasl2-modules libsasl2-modules:armhf
The following NEW packages will be installed:
  gcc-11-base:armhf libacl1:armhf libaudit1:armhf libavahi-client3:armhf 
libavahi-client3 libavahi-common-data libavahi-common-data:armhf
  libavahi-common3:armhf libavahi-common3 libbsd0 libbsd0:armhf libc6:armhf 
libcap-ng0:armhf libcap2:armhf libcom-err2:armhf libcups2 libcups2:armhf
  libdb5.3:armhf libdbus-1-3:armhf libdbus-1-3 libffi8:armhf libgcc-s1:armhf 
libgcrypt20:armhf libgmp10:armhf libgnutls30:armhf libgpg-error0:armhf
  libgssapi-krb5-2:armhf libhogweed6:armhf libicu67 libicu67:armhf 
libidn2-0:armhf libjansson4 libjansson4:armhf libk5crypto3:armhf 
libkeyutils1:armhf
  libkrb5-3:armhf libkrb5support0:armhf libldap-2.4-2 libldap-2.4-2:armhf 
libldb2 libldb2:armhf liblmdb0 liblz4-1:armhf liblzma5:armhf libmd0 libmd0:armhf
  libnettle8:armhf libnsl2:armhf libp11-kit0:armhf libpam0g:armhf libpopt0 
libpopt0:armhf libsasl2-2 libsasl2-2:armhf libsasl2-modules-db
  libsasl2-modules-db:armhf libsmbclient:armhf libsmbclient libsmbclient-dev 
libsmbclient-dev:armhf libssl1.1:armhf libstdc++6:armhf libsystemd0:armhf
  libtalloc2 libtalloc2:armhf libtasn1-6:armhf libtdb1 libtdb1:armhf libtevent0 
libtevent0:armhf libtirpc3:armhf libunistring2:armhf libwbclient0
  libwbclient0:armhf libzstd1:armhf samba-libs samba-libs:armhf zlib1g:armhf
0 upgraded, 78 newly installed, 0 to remove and 0 not upgraded.
Inst gcc-11-base:armhf (11.2.0-10 Debian:unstable [armhf])
Inst libgcc-s1:armhf (11.2.0-10 Debian:unstable [armhf]) []
Inst libc6:armhf (2.32-4 Debian:unstable [armhf])
Inst libacl1:armhf (2.3.1-1 Debian:unstable [armhf])
Inst libavahi-common-data:armhf (0.8-5 Debian:unstable [armhf])
Inst libavahi-common3:armhf (0.8-5 Debian:unstable [armhf])
Inst libcap2:armhf (1:2.44-1 Debian:unstable [armhf])
Inst libgpg-error0:armhf (1.42-3 Debian:unstable [armhf])
Inst libgcrypt20:armhf (1.9.4-3+b1 Debian:unstable [armhf])
Inst liblz4-1:armhf (1.9.3-2 Debian:unstable [armhf])
Inst liblzma5:armhf (5.2.5-2 Debian:unstable [armhf])
Inst libzstd1:armhf (1.4.8+dfsg-3 Debian:unstable [armhf])
Conf gcc-11-base:armhf (11.2.0-10 Debian:unstable [armhf])
Conf libgcc-s1:armhf (11.2.0-10 Debian:unstable [armhf])
Conf libc6:armhf (2.32-4 Debian:unstable [armhf])
Conf libcap2:armhf (1:2.44-1 Debian:unstable [armhf])
Conf libgpg-error0:armhf (1.42-3 Debian:unstable [armhf])
Conf libgcrypt20:armhf (1.9.4-3+b1 Debian:unstable [armhf])
Conf liblz4-1:armhf (1.9.3-2 Debian:unstable [armhf])
Conf liblzma5:armhf (5.2.5-2 Debian:unstable [armhf])
Conf libzstd1:armhf (1.4.8+dfsg-3 Debian:unstable [armhf])
Inst libsystemd0:armhf (249.5-1 Debian:unstable [armhf])
Inst 

Bug#843449: #843449: doc-debian: Mistake in doc-base control file for debian-social-contract

[Joost van Baal-Ilić]

tags #843449 +pending
thanks

Fixed in git at [master 1a4d1e3].  Thanks Legimet!

Bug#273323: doc-debian: please ship typesettable version of social contract and dfsg documents

[Joost van Baal-Ilić]

Hi,

Thanks for participating in this discussion.  I guess the way forward is to
ship a /usr/share/doc/doc-debian/README file with instructions on the various
ways as posted here on how to get typesettable versions.  (Or anybody has
better ideas?)

Anyway, I'll try to get to that.  (As always: patches welcome :)

Bye,

Joost

PS: and on my todo list is shipping the Debian flyers as a Debian package, in
order to improve discoverability of
https://debian.pages.debian.net/debian-flyers/ and
https://salsa.debian.org/debian/debian-flyers .

Bug#998297: mu-editor: FTBFS: AssertionError: Expected 'SendScintilla' to be called once. Called 0 times.

[Andreas Beckmann]

Source: mu-editor
Version: 1.1.0~alpha2+dfsg1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi,

mu-editor/experimental recently started to FTBFS:

=== FAILURES ===
_ test_tidy_code_valid_python __

@pytest.mark.skipif(sys.version_info < (3, 6), reason="Requires Python3.6")
def test_tidy_code_valid_python():
"""
Ensure the "good case" works as expected (the code is reformatted and Mu
shows a status message to confirm so).
"""
mock_view = mock.MagicMock()
mock_view.current_tab.text.return_value = "print('hello')"
ed = mu.logic.Editor(mock_view)
ed.show_status_message = mock.MagicMock()
ed.tidy_code()
tab = mock_view.current_tab
>   tab.SendScintilla.assert_called_once_with(tab.SCI_SETTEXT,
  b'print("hello")\n')

tests/test_logic.py:3474: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = 
args = (, 
b'print("hello")\n')
kwargs = {}, msg = "Expected 'SendScintilla' to be called once. Called 0 times."

def assert_called_once_with(self, /, *args, **kwargs):
"""assert that the mock was called exactly once and that that call was
with the specified arguments."""
if not self.call_count == 1:
msg = ("Expected '%s' to be called once. Called %s times.%s"
   % (self._mock_name or 'mock',
  self.call_count,
  self._calls_repr()))
>   raise AssertionError(msg)
E   AssertionError: Expected 'SendScintilla' to be called once. Called 
0 times.

/usr/lib/python3.9/unittest/mock.py:918: AssertionError
-- Captured log call ---
ERRORmu.logic:logic.py:1508 cannot import name 'PY36_VERSIONS' from 'black' 
(/usr/lib/python3/dist-packages/black/__init__.py)
=== warnings summary ===
.pybuild/cpython3_3.9_mu-editor/build/tests/modes/test_microbit.py::test_flash_with_attached_known_device_and_forced
.pybuild/cpython3_3.9_mu-editor/build/tests/modes/test_microbit.py::test_flash_forced_with_attached_device_as_not_windows
.pybuild/cpython3_3.9_mu-editor/build/tests/modes/test_microbit.py::test_force_flash_user_specified_device_path
.pybuild/cpython3_3.9_mu-editor/build/tests/modes/test_microbit.py::test_force_flash_empty_script
.pybuild/cpython3_3.9_mu-editor/build/tests/modes/test_microbit.py::test_flash_force_with_attached_device_as_windows
.pybuild/cpython3_3.9_mu-editor/build/tests/modes/test_microbit.py::test_flash_device_has_latest_firmware_encounters_serial_problem_windows
.pybuild/cpython3_3.9_mu-editor/build/tests/modes/test_microbit.py::test_flash_with_attached_device_has_latest_firmware_encounters_problem
.pybuild/cpython3_3.9_mu-editor/build/tests/modes/test_microbit.py::test_flash_device_has_latest_firmware_encounters_serial_problem_unix
.pybuild/cpython3_3.9_mu-editor/build/tests/modes/test_microbit.py::test_flash_with_attached_device_has_latest_firmware
  
/build/mu-editor-1.1.0~alpha2+dfsg1/.pybuild/cpython3_3.9_mu-editor/build/mu/modes/microbit.py:256:
 DeprecationWarning: Function 'semver.parse' is deprecated. Deprecated since 
version 2.10.0.  This function will be removed in semver 3. Use the respective 
'semver.VersionInfo.parse' instead.
semver.parse(version_info['release'])

.pybuild/cpython3_3.9_mu-editor/build/tests/modes/test_microbit.py: 10 warnings
  
/build/mu-editor-1.1.0~alpha2+dfsg1/.pybuild/cpython3_3.9_mu-editor/build/mu/modes/microbit.py:272:
 DeprecationWarning: Function 'semver.compare' is deprecated. Deprecated since 
version 2.10.0.  This function will be removed in semver 3. Use the respective 
'semver.VersionInfo.compare' instead.
if semver.compare(board_version,

-- Docs: https://docs.pytest.org/en/stable/warnings.html
=== short test summary info 
FAILED tests/test_logic.py::test_tidy_code_valid_python - AssertionError: Exp...
== 1 failed, 820 passed, 19 warnings in 6.51s ==
E: pybuild pybuild:354: test: plugin distutils failed with: exit code=1: cd 
'/build/mu-editor-1.1.0~alpha2+dfsg1/.pybuild/cpython3_3.9_mu-editor/build'; 
python3.9 -m pytest --random-order
Traceback (most recent call last):
  File "/usr/bin/pybuild", line 352, in main
run(func, i, version, c)
  File "/usr/bin/pybuild", line 302, in run
result = func(context, args)
  File "/usr/share/dh-python/dhpython/build/base.py", line 282, in wrapped_func
raise Exception(msg)
Exception: exit code=1: cd 
'/build/mu-editor-1.1.0~alpha2+dfsg1/.pybuild/cpython3_3.9_mu-editor/build'; 
python3.9 -m pytest --random-order
rm -fr -- /tmp/dh-xdg-rundir-Uw9IX9A5
dh_auto_test: error: pybuild --test 

Bug#995198: wsjtx: No transmit audio

[Christoph Berg]

Re: Hilary Snaden
> The CAT on my rig stopped working after a voltage surge fried my USB-serial
> interfaces. A new (USB controllable) rig is on my medium-term wishlist.

Ouch :(

> However, if I try to change the audio device (settings...) this appears:
> 
> Cannot connect to server socket err = No such file or directory
> 
> Cannot connect to server request channel
> 
> jack server is not running or cannot be started

That looks like Qt multimeda has trouble talking to pulseaudio.

Are you using pulseaudio? Is fldigi working properly through
pulseaudio, or talking to the sound devices differently?
(To inspect, start pavucontrol and check if the play/record channel
meters move on transmitting.)

I have no idea if wsjtx on Debian is supposed to work with Jack or
plain Alsa.

Christoph

Bug#998296: adios: autopktest failure

[Sebastian Ramacher]

Source: adios
Version: 1.13.1-29
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

autopkgtests fail with:
| Broken autopkgtest-satdep:amd64 Depends on libadios-mpi-dev:amd64 < none @un 
H >
|   Removing autopkgtest-satdep:amd64 because I can't find 
libadios-mpi-dev:amd64

See https://ci.debian.net/data/autopkgtest/testing/amd64/a/adios/16336328/log.gz

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#997917: transition: aom

[Sebastian Ramacher]

Control: tags -1 confirmed
Control: forwarded -1 https://release.debian.org/transitions/html/auto-aom.html

On 2021-10-27 01:54:28 -0400, Boyuan Yang wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-CC: by...@debian.org debian-multime...@lists.debian.org
> Severity: normal
> 
> Dear Debian Release Team,
> 
> I plan to start libaom transition as shown on the following transition
> tracker:
> 
> 
> https://release.debian.org/transitions/html/auto-aom.html
> 
> The new version of libaom library has bumped SONAME (libaom0 -> libaom3) and
> needs a transition.
> 
> There are 3 reverse build-dependencies, and I have verified that
> the build would still pass with the new libaom currently in experimental:
> 
> * ffmpeg (ok)
> * libheif (ok)
> * gst-plugins-bad1.0 (ok)
> 
> Example Ben file (the one currently on auto-aom page should be ok):
> 
> title = "aom";
> is_affected = .depends ~ "libaom3" | .depends ~ "libaom0";
> is_good = .depends ~ "libaom3";
> is_bad = .depends ~ "libaom0";
> 
> I expect it to be a smooth transition that only involves binNMUs. Please let
> me know if there are any concerns.

Please go ahead

Cheers

> 
> Thanks,
> Boyuan Yang



-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#998295: puma: 401 runs, 1086 assertions, 1 failures, 0 errors, 6 skips

[Sebastian Ramacher]

Source: puma
Version: 5.3.2-3
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

puma fails to build on amd64 and mips*el:
| Errors & Failures:
|
|   1) Failure:
| TestIntegrationSingle#test_hot_restart_does_not_drop_connections_threads 
[/<>/test/helpers/integration.rb:308]:
|   0 unexpected_response
|   3 refused
|   0 read timeout
|   0 reset
| 997 success
| 565 success after restart
|   1 restart count
| Expected no refused connections.
| Expected: 0
|   Actual: 3
|
| 401 runs, 1086 assertions, 1 failures, 0 errors, 6 skips

https://buildd.debian.org/status/fetch.php?pkg=puma=amd64=5.3.2-3%2Bb1=1635692756=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#998124: meson: gnome module missing install_dir fix for c_template

[Jussi Pakkanen]

On Mon, 1 Nov 2021 at 23:33, Joshua Peisach  wrote:

> Nemo (Cinnamon's file manager) is failing to build with this same "KeyError: 
> 'install_dir'" issue, and I feel like it is a 0.60 regression as previous 
> versions didn't fail.
>
> Hope this gets fixed soon.

This is already fixed upstream and will be in 0.60.1 which will be out soonish;

https://github.com/mesonbuild/meson/pull/9484

Bug#989155: dh_installinit: when upgrading to a version that adds --no-restart-after-upgrade, the service is not restarted

[Michael Biebl]

On 29.10.21 19:39, Ryan Tandy wrote:

Hi Michael,

On Fri, Oct 29, 2021 at 09:51:46AM +0200, Michael Biebl wrote:
If you use "--no-restart-after-upgrade", why do you expect the service 
to be

restarted?


The man page describes --no-restart-after-upgrade:

  Undo a previous --restart-after-upgrade (or the default of compat 10). 
  If no other options are given, this will cause the service to be 
  stopped in the prerm script and started again in the postinst script.


I have to admit that I'm very confused by the name of this command line 
flag and the action it actually does.
So --no-restart-after-upgrade actually means the service is restarted 
during the upgrade.
I think it should have been named something like 
--stop-and-start(-on-upgrade) to actually describe what it does.


In the same way, I find that replacing --no-restart-on-upgrade with 
--no-stop-on-upgrade not a good idea either (or the -r shortcut)







OpenPGP_signature
Description: OpenPGP digital signature

Bug#996670: libkdecorations2-5v5 migrated to testing too early breaking Plasma

[stefaca]

I can confirm this. Upgrade of KDE on testing is totally broken at the moment. 

On Sat, 23 Oct 2021 15:57:47 +0200 Chris Nospam  wrote:
> KDE/Plasma (package dependencies) are currently completely broken under 
testing. Is there currently a chance to (somehow simply) block the partial 
transition of plasma 5.23 to testing (so that not related package updates are 
easy)? Selectively upgrading single packages with dependencies one after the 
other from the mass provided in testing is rather cumbersome.
> 
> Currently I get the following (sorry for the german locale):
> 
> root@xxx:~# apt-get dist-upgrade
> Paketlisten werden gelesen… Fertig
> Abhängigkeitsbaum wird aufgebaut… Fertig
> Statusinformationen werden eingelesen… Fertig
> Paketaktualisierung (Upgrade) wird berechnet… Fertig
> Die folgenden NEUEN Pakete werden installiert:
>   libkdecorations2private9
> Die folgenden Pakete werden aktualisiert (Upgrade):
>   bluedevil breeze breeze-cursor-theme breeze-gtk-theme drkonqi
>   kactivitymanagerd kde-config-gtk-style kde-config-sddm kde-config-updates
>   kde-style-breeze kgamma5 kinfocenter kmenuedit kscreen ksshaskpass
>   kwayland-integration kwin-style-breeze kwrited libkdecorations2-5v5
>   libkf5screen-bin libkf5screen7 libpam-kwallet-common libpam-kwallet5 milou
>   oxygen-sounds plasma-discover plasma-discover-common plasma-disks
>   plasma-integration plasma-pa polkit-kde-agent-1
> 31 aktualisiert, 1 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
> Es müssen 96,2 MB an Archiven heruntergeladen werden.
> Nach dieser Operation werden 47,1 MB Plattenplatz zusätzlich benutzt.
> Möchten Sie fortfahren? [J/n] n
> Abbruch.
> 
> All packages shown above are from version 4:5.23.0 whereas the others would 
stay on 4:5.21.x. Unfortunately, it is not sufficient to set 
libkdecorations2-5v5 on hold, as it would remove plasma-desktop:
> 
> root@xxx:~# apt-mark hold libkdecorations2-5v5
> libkdecorations2-5v5 auf Halten gesetzt.
> root@xxx:~# apt-get dist-upgrade
> Paketlisten werden gelesen… Fertig
> Abhängigkeitsbaum wird aufgebaut… Fertig
> Statusinformationen werden eingelesen… Fertig
> Paketaktualisierung (Upgrade) wird berechnet… Fertig
> Die folgenden Pakete wurden automatisch installiert und werden nicht mehr 
benötigt:
>   accountsservice apt-config-icons-hidpi apt-config-icons-large
>   apt-config-icons-large-hidpi bluedevil bluez bluez-obexd breeze-gtk-theme
>   bup bup-doc gtk2-engines-pixbuf ibus-data ieee-data kde-config-gtk-style
>   kde-config-sddm kde-config-updates kgamma5 khotkeys khotkeys-data
>   kinfocenter kmenuedit kscreen kup-backup kwrited libaccountsservice0
>   libibus-1.0-5 libkpmcore11 libqt5designer5 libqt5help5 libscim8v5
>   libxcb-record0 oxygen-sounds par2 partitionmanager plasma-desktop-data
>   plasma-discover plasma-discover-common plasma-disks python3-fuse
>   python3-pylibacl python3-pyqt5 python3-pyqt5.sip python3-pyxattr
>   python3-software-properties python3-tornado qml-module-org-kde-activities
>   qml-module-org-kde-kcm qml-module-org-kde-kitemmodels smartmontools
>   software-properties-common software-properties-kde systemsettings
>   xsettings-kde
> Verwenden Sie »apt autoremove«, um sie zu entfernen.
> Die folgenden Pakete werden ENTFERNT:
>   kde-plasma-desktop plasma-desktop
> Die folgenden Pakete sind zurückgehalten worden:
>   breeze breeze-cursor-theme kde-config-gtk-style kde-style-breeze
>   kwin-style-breeze libkdecorations2-5v5 plasma-integration
> Die folgenden Pakete werden aktualisiert (Upgrade):
>   bluedevil breeze-gtk-theme drkonqi kactivitymanagerd kde-config-sddm
>   kde-config-updates kgamma5 kinfocenter kmenuedit kscreen ksshaskpass
>   kwayland-integration kwrited libkf5screen-bin libkf5screen7
>   libpam-kwallet-common libpam-kwallet5 milou oxygen-sounds plasma-discover
>   plasma-discover-common plasma-disks plasma-pa polkit-kde-agent-1

Bug#996695: buster-pu: package plib/plib_1.8.5-8+deb10u1

[Salvatore Bonaccorso]

Hi Anton,

On Mon, Nov 01, 2021 at 10:19:03PM +0100, Salvatore Bonaccorso wrote:
> Hi Anton,
> 
> On Sun, Oct 17, 2021 at 03:20:41PM +0200, Anton Gladky wrote:
> > Package: release.debian.org
> > Severity: normal
> > Tags: buster
> > User: release.debian@packages.debian.org
> > Usertags: pu
> > 
> > Anton Gladky 
> >   
> > Anhänge15:17 (vor 1 Minute)
> >   
> > an Debian; Bcc: gladk
> > Package: release.debian.org
> > Severity: normal
> > Tags: bullseye
> > User: release.debian@packages.debian.org
> > Usertags: pu
> > 
> > Dear release team,
> > 
> > the plib versioned 1.8.5-8+deb10u1 is prepared for the bullseye next
> > stable release.
> 
> Did you meant to fill this for bullseye-pu? (with a +deb11u1) suffix?
> I see that both versions are uploaded:
> 
> plib   | 1.8.5-8+deb10u1 | oldstable-new   | source
> plib   | 1.8.5-8+deb11u1 | stable-new  | source
> 
> Both buster and bullseye have the same version, but two separate bugs
> for the update in buster-pu and bullseye-pu would be needed.

Scratch that last part, while searching I missed #996694 and got
confused by the text in the report :).

Regards,
Salvatore

Bug#996695: buster-pu: package plib/plib_1.8.5-8+deb10u1

[Salvatore Bonaccorso]

Hi Anton,

On Sun, Oct 17, 2021 at 03:20:41PM +0200, Anton Gladky wrote:
> Package: release.debian.org
> Severity: normal
> Tags: buster
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Anton Gladky 
>   
> Anhänge15:17 (vor 1 Minute)
>   
> an Debian; Bcc: gladk
> Package: release.debian.org
> Severity: normal
> Tags: bullseye
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Dear release team,
> 
> the plib versioned 1.8.5-8+deb10u1 is prepared for the bullseye next
> stable release.

Did you meant to fill this for bullseye-pu? (with a +deb11u1) suffix?
I see that both versions are uploaded:

plib   | 1.8.5-8+deb10u1 | oldstable-new   | source
plib   | 1.8.5-8+deb11u1 | stable-new  | source

Both buster and bullseye have the same version, but two separate bugs
for the update in buster-pu and bullseye-pu would be needed.

Regards,
Salvatore

Bug#998294: src:vulkan-validationlayers: fails to migrate to testing for too long: FTBFS on mips*el

[Paul Gevers]

Source: vulkan-validationlayers
Version: 1.2.162.0-1
Severity: serious
X-Debbugs-CC: d...@duckcorp.org
Tags: sid bookworm ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing
and unstable for more than 60 days as having a Release Critical bug in
testing [1]. Your package src:vulkan-validationlayers has been trying to
migrate for 61 days [2]. Hence, I am filing this bug. It turns out that
the package FTBFS on mips*el since the upload of 1.2.182.0-1.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have tagged this bug to only affect sid and bookworm, so it doesn't
affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=vulkan-validationlayers




OpenPGP_signature
Description: OpenPGP digital signature

Bug#998293: src:phosh: fails to migrate to testing for too long

[Paul Gevers]

Source: phosh
Version: 0.8.0-1
Severity: serious
Control: close -1 0.13.1-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing
and unstable for more than 60 days as having a Release Critical bug in
testing [1]. Your package src:phosh has been trying to migrate for 61
days [2]. Hence, I am filing this bug.

I checked the output of britney [3], it says this:
trying: phosh
skipped: phosh (0, 1, 128)
got: 26+0: a-1:a-23:a-0:a-0:i-0:m-0:m-1:p-0:s-1
* mipsel: phosh-phone

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bookworm, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=phosh
[3] https://release.debian.org/britney/update_output.txt



OpenPGP_signature
Description: OpenPGP digital signature

Bug#998285: libgig: fails to clean after build

[Sebastian Ramacher]

Control: tags -1 important

On 2021-11-01 20:58:14 +0100, Andreas Beckmann wrote:
> Source: libgig
> Version: 4.3.0~ds1-1
> Severity: serious
> 
> Hi,
> 
> libgig fails to build twice in a row since it cannot clean up after a
> successful build:
> 
>dh_clean
> rm: cannot remove './doc/html': Is a directory
> dh_clean: error: rm -f -- debian/libgig-dev.substvars 
> debian/libgig10.substvars debian/libakai0.substvars debian/gigtools.substvars 
> debian/libgig-doc.substvars ./doc/html debian/files returned exit code 1
> make: *** [debian/rules:6: clean] Error 25
> 
> 
> This looks like you want to have 'doc/html/' (note the trailing slash)
> in debian/clean instead.

Such bugs have always been important at most.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#998292: docker.io: CVE-2021-41092: Docker CLI leaks private registry credentials to registry-1.docker.io

[Salvatore Bonaccorso]

Source: docker.io
Version: 20.10.8+dfsg1-2
Severity: normal
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for docker.io.

CVE-2021-41092[0]:
| Docker CLI is the command line interface for the docker container
| runtime. A bug was found in the Docker CLI where running `docker login
| my-private-registry.example.com` with a misconfigured configuration
| file (typically `~/.docker/config.json`) listing a `credsStore` or
| `credHelpers` that could not be executed would result in any provided
| credentials being sent to `registry-1.docker.io` rather than the
| intended private registry. This bug has been fixed in Docker CLI
| 20.10.9. Users should update to this version as soon as possible. For
| users unable to update ensure that any configured credsStore or
| credHelpers entries in the configuration file reference an installed
| credential helper that is executable and on the PATH.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-41092
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41092
[1] https://github.com/docker/cli/security/advisories/GHSA-99pg-grm5-qq3v
[2] 
https://github.com/docker/cli/commit/893e52cf4ba4b048d72e99748e0f86b2767c6c6b

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#995021: osmnx: autopkgtest regression on armhf: iteration over a 0-d array

[Jerome BENOIT]

On Mon, 1 Nov 2021 20:49:58 +0100 Paul Gevers  wrote:
Hello Paul,


Is this run on all cores? Our armhf worker has 160 cores, so you may be
running into limits you didn't expect.


This would be a surprising bug, indeed.
I will have a closer look. But I think I have ultimately
to contact the upstream author.

Otherwise, is there a way to limit the number of cores to use
through an environment variable (or something along this way) ?


Cheers,
Jerom




--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B



OpenPGP_signature
Description: OpenPGP digital signature

Bug#989284: insserv: toggles rc0.d/{K02avahi-daemon => K01avahi-daemon} with every upgrade

[Thorsten Glaser]

Mark Hindley dixit:

>I realise this may be clutching at straws, but is there any chance the
>x32 arch is the trigger for this?

As already stated… at least twice, I think, no: the system got
converted to amd64 in the meanwhile, and the same problem occurs
on my amd64 laptop that was never a different architecture, when
copying these files over, as well as in a clean chroot.

bye,
//mirabilos
-- 
Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit
gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so
reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~
(as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)

Bug#998291: ITP: ocaml-ansi-terminal -- colors and cursor movements for OCaml applications

[Julien Puydt]

Package: wnpp
Owner: Julien Puydt 
X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org
Severity: wishlist

* Package name: ocaml-ansi-terminal
  Version : 0.8.2
  Upstream Author : Christophe Troestler & Vincent Hugot
* URL : https://github.com/Chris00/ANSITerminal
* License : LGPL 3.0 with OCaml linking exception
  Programming Lang: OCaml
  Description : colors and cursor movements for OCaml applications

 This package provides a library for use of colors and cursor movements
 on ANSI terminals for OCaml programs.

I plan to maintain it within the Debian OCaml Maintainers team, since
it's in written in OCaml and will allow running the upstream testsuite
for my recent elpi package in the same team.

Cheers,

J.Puydt

Bug#998290: gnunet: fails to install: gnunet.postinst: 91: tempfile: not found

[Andreas Beckmann]

Package: gnunet
Version: 0.14.0-6
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

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

  Setting up gnunet (0.14.0-6) ...
  Creating new GNUnet group gnunet: done.
  Creating new GNUnet user gnunet: done.
  Creating new secured GNUnet group gnunetdns: done.
  Updating files and directories permissions: done.
  Writing new configuration file:/var/lib/dpkg/info/gnunet.postinst: 91: 
tempfile: not found
  dpkg: error processing package gnunet (--configure):
   installed gnunet package post-installation script subprocess returned error 
exit status 127
  Processing triggers for libc-bin (2.32-4) ...
  Errors were encountered while processing:
   gnunet


cheers,

Andreas


gnunet_0.14.0-6.log.gz
Description: application/gzip

Bug#998289: r-cran-gert: autopkgtest regression since mid October 2021 master renamed to main?

[Paul Gevers]

Source: r-cran-gert
Version:
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
X-Debbugs-CC: debian...@lists.debian.org

Dear maintainer(s),

Your package has an autopkgtest, great! However, since somewhere between
21 October and 1 November 2021 it started to fail [1] in testing. Can
you fix the situation?

Paul

[1] https://ci.debian.net/packages/r/r-cran-gert/

https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-gert/16361108/log.gz

> test_check("gert")
Error in (function (url, username, retries)  :
  To use a hardcoded password, include your username in the URL like
'https://je...@github.com
══ Failed tests

── Failure (test-clone.R:7:3): cloning repositories works
──
info$head not equal to "refs/heads/master".
1/1 mismatches
x[1]: "refs/heads/main"
y[1]: "refs/heads/master"
── Failure (test-clone.R:8:3): cloning repositories works
──
info$shorthand not equal to "master".
1/1 mismatches
x[1]: "main"
y[1]: "master"
── Failure (test-clone.R:16:3): cloning repositories works
─
git_remote_info(repo = repo)$head not equal to "refs/remotes/origin/master".
1/1 mismatches
x[1]: "refs/remotes/origin/main"
y[1]: "refs/remotes/origin/master"
── Error (test-rebase.R:13:3): rebasing things
─
Error in `git_commit_id("origin/master", repo = repo)`: Failed to find
git reference 'origin/master'
Backtrace:
█
 1. ├─testthat::expect_equal(...) test-rebase.R:13:2
 2. │ └─testthat::quasi_label(enquo(expected), expected.label, arg =
"expected")
 3. │   └─rlang::eval_bare(expr, quo_get_env(quo))
 4. └─gert::git_commit_id("origin/master", repo = repo)

[ FAIL 4 | WARN 0 | SKIP 0 | PASS 99 ]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#998288: node-clipanion: FTBFS: Cannot find type definition file for 'yup'.

[Andreas Beckmann]

Package: node-clipanion
Version: 2.6.2-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi,

node-clipanion FTBFS in a minimal chroot:

   dh_auto_build --buildsystem=nodejs
Found debian/nodejs/./build
cd ./. && sh -ex debian/nodejs/./build
+ rollup -c

./sources/advanced/index.ts → lib, lib...
(!) Plugin typescript: @rollup/plugin-typescript TS2688: Cannot find type 
definition file for 'yup'.
  The file is in the program because:
Entry point of type library 'yup' specified in compilerOptions
created lib, lib in 1.6s
   dh_auto_test --buildsystem=nodejs
ln -s ../. node_modules/clipanion
/bin/sh -ex debian/tests/pkg-js/test
+ export FORCE_COLOR=1
+ mocha --require ts-node/register --extension ts tests

TSError: ⨯ Unable to compile TypeScript:
sources/advanced/Command.ts(440,21): error TS2571: Object is of type 'unknown'.
sources/advanced/Command.ts(441,21): error TS2571: Object is of type 'unknown'.

at createTSError (/usr/share/nodejs/ts-node/src/index.ts:513:12)
at reportTSError (/usr/share/nodejs/ts-node/src/index.ts:517:19)
at getOutput (/usr/share/nodejs/ts-node/src/index.ts:752:36)
at Object.compile (/usr/share/nodejs/ts-node/src/index.ts:968:32)
at Module.m._compile (/usr/share/nodejs/ts-node/src/index.ts:1056:42)
at Module._extensions..js (internal/modules/cjs/loader.js:1027:10)
at Object.require.extensions. [as .ts] 
(/usr/share/nodejs/ts-node/src/index.ts:1059:12)
at Module.load (internal/modules/cjs/loader.js:863:32)
at Function.Module._load (internal/modules/cjs/loader.js:708:14)
at Module.require (internal/modules/cjs/loader.js:887:19)
at require (internal/modules/cjs/helpers.js:74:18)
at Object. 
(/build/node-clipanion-2.6.2/sources/advanced/index.ts:1:1)
at Module._compile (internal/modules/cjs/loader.js:999:30)
at Module.m._compile (/usr/share/nodejs/ts-node/src/index.ts:1056:23)
at Module._extensions..js (internal/modules/cjs/loader.js:1027:10)
at Object.require.extensions. [as .ts] 
(/usr/share/nodejs/ts-node/src/index.ts:1059:12)
at Module.load (internal/modules/cjs/loader.js:863:32)
at Function.Module._load (internal/modules/cjs/loader.js:708:14)
at Module.require (internal/modules/cjs/loader.js:887:19)
at require (internal/modules/cjs/helpers.js:74:18)
at Object. 
(/build/node-clipanion-2.6.2/tests/advanced.test.ts:6:1)
at Module._compile (internal/modules/cjs/loader.js:999:30)
at Module.m._compile (/usr/share/nodejs/ts-node/src/index.ts:1056:23)
at Module._extensions..js (internal/modules/cjs/loader.js:1027:10)
at Object.require.extensions. [as .ts] 
(/usr/share/nodejs/ts-node/src/index.ts:1059:12)
at Module.load (internal/modules/cjs/loader.js:863:32)
at Function.Module._load (internal/modules/cjs/loader.js:708:14)
at Module.require (internal/modules/cjs/loader.js:887:19)
at require (internal/modules/cjs/helpers.js:74:18)
at Object.exports.requireOrImport 
(/usr/share/nodejs/mocha/lib/nodejs/esm-utils.js:56:20)
dh_auto_test: error: /bin/sh -ex debian/tests/pkg-js/test returned exit code 1
make: *** [debian/rules:8: binary] Error 25


Andreas


node-clipanion_2.6.2-1.log.gz
Description: application/gzip

Bug#998287: r-cran-pdftools: autopkgtest failure: nrow(fonts) not equal to 3

[Paul Gevers]

Source: r-cran-pdftools
Version: 3.0.1-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

Your package r-cran-pdftools has an autopkgtest, great. However, it
fails. Can you please investigate the situation and fix it? I copied
some of the output at the bottom of this report.

The release team has announced [1] that failing autopkgtest are now
considered RC in testing.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-pdftools/16361110/log.gz

autopkgtest [17:58:47]: test run-unit-test: [---
BEGIN TEST poppler.R

R version 4.1.1 (2021-08-10) -- "Kick Things"
Copyright (C) 2021 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> library(pdftools)
Using poppler version 20.09.0
>
BEGIN TEST testthat.R

R version 4.1.1 (2021-08-10) -- "Kick Things"
Copyright (C) 2021 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> library(testthat)
> library(pdftools)
Using poppler version 20.09.0
>
> test_check("pdftools")
══ Skipped tests
═══
• On CRAN (1)

══ Failed tests

── Failure (test-chinese.R:7:3): reading Chinese text
──
`text` does not match "風險因素".
Actual value: "
T\+2\\n\\n\\n\\n17,300,000\\n\\n\\n\\n299,900\\n\\n\\n\\n\\n

36\.8%\\n34\.9%\\n4,300,000
  6,900,000 7,100,000\\n300,000\\n\\n\\n
  3\.7%   1\.5%   3\.4%0\.1%\\n\\n\\n\\n\\n
   80%\\n  10%
80%\\n\\n\\n\\n\\n   – 31 –\\n"
Backtrace:
█
 1. └─testthat::expect_match(text, "風險因素") test-chinese.R:7:2
 2.   └─testthat:::expect_match_(...)
── Failure (test-chinese.R:11:3): reading Chinese text
─
nrow(fonts) not equal to 3.
1/1 mismatches
[1] 1 - 3 == -2
── Failure (test-chinese.R:13:3): reading Chinese text
─
fonts\$name\[2\] does not match "MSung".
Actual value: ""
Backtrace:
█
 1. └─testthat::expect_match(fonts$name[2], "MSung") test-chinese.R:13:2
 2.   └─testthat:::expect_match_(...)
── Failure (test-chinese.R:14:3): reading Chinese text
─
fonts\$name\[3\] does not match "MHei".
Actual value: ""
Backtrace:
█
 1. └─testthat::expect_match(fonts$name[3], "MHei") test-chinese.R:14:2
 2.   └─testthat:::expect_match_(...)

[ FAIL 4 | WARN 0 | SKIP 1 | PASS 20 ]
Error: Test failures
Execution halted
autopkgtest [17:58:49]: test run-unit-test: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#998286: r-cran-psych: autopkgtest regression since mid October 2021

[Paul Gevers]

Source: r-cran-psych
Version: 2.1.9-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
X-Debbugs-CC: debian...@lists.debian.org

Dear maintainer(s),

Your package has an autopkgtest, great! However, since somewhere between
20 October and 1 November 2021 it started to fail [1] in testing. Can
you fix the situation?

Paul

[1] https://ci.debian.net/packages/r/r-cran-psych/

autopkgtest [01:28:04]: test vignette: [---
BEGIN VIGNETTE vignettes/intro.Rnw
Warning in log((1 - cc2)) : NaNs produced
Output file:  intro.tex
BEGIN VIGNETTE vignettes/scoring.Rnw
Error in loadNamespace(key[1]) : there is no package called 'knitr'
Calls:  ... loadNamespace -> withRestarts -> withOneRestart
-> doWithOneRestart
Execution halted
autopkgtest [01:28:08]: test vignette: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#967939: dvb-apps: Update dvb-apps:amd64 1.1.1+rev1500-1.2 => 1.1.1+rev1500-1.4 breaks gnutv

[Sylvain L. Sauvage]

Hi,

Bug confirmed on Bullseye (1.1.1+rev1500-1.4).
gnutv only writes meta-data, no audio, no video, no subtitles….
So no errors but an empty stream.

At least, 1.1.1+rev1500-1.2 from Buster can be installed on Bullseye without 
too much hassle and still works.

Sincerely,
-- 
  Sylvain L. Sauvage

Bug#961386: Please drop the bitstream vera font

[Amr Ibrahim]

Hello,

Please cherry-pick the upstream fix to drop the bitstream vera font.

The bitstream vera font is very obsolete, looks worse than dejavu and
sometimes as a negative side-effect it takes over as a default font
when installed.

Best,
Amr

Bug#998285: libgig: fails to clean after build

[Andreas Beckmann]

Source: libgig
Version: 4.3.0~ds1-1
Severity: serious

Hi,

libgig fails to build twice in a row since it cannot clean up after a
successful build:

   dh_clean
rm: cannot remove './doc/html': Is a directory
dh_clean: error: rm -f -- debian/libgig-dev.substvars debian/libgig10.substvars 
debian/libakai0.substvars debian/gigtools.substvars debian/libgig-doc.substvars 
./doc/html debian/files returned exit code 1
make: *** [debian/rules:6: clean] Error 25


This looks like you want to have 'doc/html/' (note the trailing slash)
in debian/clean instead.


Andreas


libgig_4.3.0~ds1-1_twice.log.gz
Description: application/gzip

Bug#998156: contains non-DFSG-free files

[Henry Cejtin]

Your right, but I think (not on the basis of real knowledge) that
ml-nlffigen isn't used in either the compilation
of the MLton compiler, nor by the MLton compiler in compiling user
code.  I thought that it was
for a MLton compiler user to use, and had been tweaked so that the
output was usable by MLton.

I certainly could be wrong about this.

Bug#998284: Please drop the dependency on ttf-bitstream-vera

[Amr Ibrahim]

Package: fontconfig-config

Hello,

Please drop the dependency on ttf-bitstream-vera. The package already
depends on fonts-dejavu-core, which extends the bitstream vera font,
and is already installed by default on Debian GNOME. Besides, the
bitstream vera font is very obsolete, looks worse than dejavu and
sometimes as a negative side-effect it takes over as a default font
when installed.

Best,
Amr

Bug#995021: osmnx: autopkgtest regression on armhf: iteration over a 0-d array

[Paul Gevers]

Hi Jerome,

On 24-09-2021 22:23, Paul Gevers wrote:
> The above exception was the direct cause of the following exception:
> 
> def test_elevation():
> 
> G = ox.graph_from_address(address=address, dist=500,
> dist_type="bbox", network_type="bike")
> rasters = list(Path("tests/input_data").glob("elevation*.tif"))
> 
> # add node elevations from a single raster file (some nodes will
> be null)
> G = ox.elevation.add_node_elevations_raster(G, rasters[0], cpus=1)

 ^^^
Suddenly strikes me, compared to the next failing line...

> # add node elevations from multiple raster files
>>   G = ox.elevation.add_node_elevations_raster(G, rasters)

Is this run on all cores? Our armhf worker has 160 cores, so you may be
running into limits you didn't expect.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#937945: Removal of python-neuroshare (Was: python-neuroshare: Python2 removal in sid/bullseye)

[Andreas Tille]

Am Mon, Nov 01, 2021 at 08:28:50PM +0100 schrieb Moritz Mühlenhoff:
> Am Sun, Feb 09, 2020 at 01:18:27PM +0100 schrieb Andreas Tille:
> > Hi,
> > 
> > I've taken over this package into Debian Med team to
> > 
> >https://salsa.debian.org/med-team/python-neuroshare
> > 
> > It needs some remaining work to port for Python3 which I
> > can not do right now.  Any help is welcome.
> 
> What's the status? https://github.com/G-Node/python-neuroshare
> hasn't seen any commits since five years, should it be removed?

The people listed as Uploaders should have the last say.

Kind regards

  Andreas. 

-- 
http://fam-tille.de

Bug#998282: Please make Section a required field for the source paragraph in d/control

[Felix Lechner]

Package: debian-policy

Hi,

The installable stanzas in d/control (called "binary package
paragraphs" in policy) inherit the Section field from the source
paragraph. There is no reason to provide inheritance the other way
around.

Also, sources may not build successfully on all architectures. People
do not often use Debian's sources directly, but we distribute them
just like installation packages.

The Section field in the source paragraph (called "general paragraph"
in policy) reveals important clues about the DFSG-classification of
the sources. It should be required. Policy section 5.2 presently shows
the field as merely recommended. Thanks!

Kind regards
Felix Lechner

Bug#998281: uhd: FTBFS during binary-indep only build

[Andreas Beckmann]

Source: uhd
Version: 4.1.0.4-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

uhd/experimental FTBFS when building only the arch-all packages as done
on the buildd:
https://buildd.debian.org/status/fetch.php?pkg=uhd=all=4.1.0.4-1=1634959755=0

 fakeroot debian/rules binary-indep
dh binary-indep --sourcedirectory=host --with python3 --with numpy3 
--buildsystem=cmake+ninja
   dh_testroot -i -O--sourcedirectory=host -O--buildsystem=cmake\+ninja
   dh_prep -i -O--sourcedirectory=host -O--buildsystem=cmake\+ninja
   debian/rules override_dh_auto_install
make[1]: Entering directory '/<>'
cp debian/uhd-host.limits debian/uhd-host/etc/security/limits.d/uhd.conf
cp: cannot create regular file 
'debian/uhd-host/etc/security/limits.d/uhd.conf': No such file or directory
make[1]: *** [debian/rules:33: override_dh_auto_install] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:17: binary-indep] Error 2

You probably need to split the override_dh_auto_install target into
separate override_dh_auto_install-arch and
override_dh_auto_install-indep targets.


Andreas

Bug#998280: Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-core

[Amr Ibrahim]

Package: efl-doc

Hello,

Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-
core. The dejavu font extends the bitstream vera font, the bitstream
vera font is very obsolete, looks worse than dejavu and sometimes as a
negative side-effect it takes over as a default font when installed.

Best,
Amr

Bug#937945: python-neuroshare: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

Am Sun, Feb 09, 2020 at 01:18:27PM +0100 schrieb Andreas Tille:
> Hi,
> 
> I've taken over this package into Debian Med team to
> 
>https://salsa.debian.org/med-team/python-neuroshare
> 
> It needs some remaining work to port for Python3 which I
> can not do right now.  Any help is welcome.

What's the status? https://github.com/G-Node/python-neuroshare
hasn't seen any commits since five years, should it be removed?

Cheers,
 Moritz

Bug#989284: insserv: toggles rc0.d/{K02avahi-daemon => K01avahi-daemon} with every upgrade

[Mark Hindley]

Hi,

Since nobody has been able to reproduce this issue, I have just been re-reading
Thorsten's original report to look for any possible differences.

On Mon, May 31, 2021 at 04:40:17AM +0200, Thorsten Glaser wrote:
> -- System Information:
> Debian Release: 11.0
>   APT prefers unreleased
>   APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 
> 'unstable'), (100, 'experimental')
> Architecture: x32 (x86_64)
> Foreign Architectures: i386, amd64

I realise this may be clutching at straws, but is there any chance the x32 arch
is the trigger for this?

I don't see any other discrepancies.

Mark

Bug#998279: Please switch the recommends from ttf-bitstream-vera to fonts-dejavu-core

[Amr Ibrahim]

Package: python3-freetype

Hello,

Please switch the recommends from ttf-bitstream-vera to fonts-dejavu-
core. The dejavu font extends the bitstream vera font and is already
installed by default on Debian GNOME. Besides, the bitstream vera font
is very obsolete, looks worse than dejavu and sometimes as a negative
side-effect it takes over as a default font when installed.

Best,
Amr

Bug#937194: opencaster: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

Am Fri, Jan 29, 2021 at 09:56:46PM + schrieb Thorsten Alteholz:
> Hi Moritz,
> 
> On Fri, 29 Jan 2021, Moritz Mühlenhoff wrote:
> > opencaster seems dead upstream, should it be removed or are
> > you planning to port it to Python 3 yourself?
> 
> I don't plan to do the porting myself, so I think at the moment it should be
> better removed.

Ack, now filed an RM bug.

Cheers,
Moritz

Bug#998278: Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-core

[Amr Ibrahim]

Package: freewheeling

Hello,

Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-
core. The dejavu font extends the bitstream vera font and is already
installed by default on Debian GNOME. Besides, the bitstream vera font
is very obsolete, looks worse than dejavu and sometimes as a negative
side-effect it takes over as a default font when installed.

Best,
Amr

Bug#998277: RM: opencaster -- RoQA; Depends on Python 2, dead upstream

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove opencaster. It depends on Python 2 and is dead upstream.
Removal was acked by Thorsten in #937194.

Cheers,
 Moritz

Bug#998276: RM: libvirt-sandbox -- RoQA; Depends on Python 2, dead upstream

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: a...@sigxcpu.org

Please remove libvirt-sandbox. It depends on Python 2 and is dead upstream.
Removal was acked by Guido.

Cheers,
Moritz

Bug#998274: Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-core

[Amr Ibrahim]

Package: gearhead2-data

Hello,

Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-
core. The dejavu font extends the bitstream vera font and is already
installed by default on Debian GNOME. Besides, the bitstream vera font
is very obsolete, looks worse than dejavu and sometimes as a negative
side-effect it takes over as a default font when installed.

Best,
Amr

Bug#998275: Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-core

[Amr Ibrahim]

Package: gearhead-data

Hello,

Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-
core. The dejavu font extends the bitstream vera font and is already
installed by default on Debian GNOME. Besides, the bitstream vera font
is very obsolete, looks worse than dejavu and sometimes as a negative
side-effect it takes over as a default font when installed.

Best,
Amr

Bug#998273: Please drop the recommends on ttf-bitstream-vera

[Amr Ibrahim]

Package: gem-doc

Hello,

Please drop the recommends on ttf-bitstream-vera. The package already
recommends fonts-dejavu-core, which extends the bitstream vera font,
and is already installed by default on Debian GNOME. Besides, the
bitstream vera font is very obsolete, looks worse than dejavu and
sometimes as a negative side-effect it takes over as a default font
when installed.

Best,
Amr

Bug#998271: Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-core

[Amr Ibrahim]

Package: libmupen64plus2

Hello,

Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-
core. The dejavu font extends the bitstream vera font and is already
installed by default on Debian GNOME. Besides, the bitstream vera font
is very obsolete, looks worse than dejavu and sometimes as a negative
side-effect it takes over as a default font when installed.

Best,
Amr

Bug#998272: Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-core

[Amr Ibrahim]

Package: gravit-data

Hello,

Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-
core. The dejavu font extends the bitstream vera font and is already
installed by default on Debian GNOME. Besides, the bitstream vera font
is very obsolete, looks worse than dejavu and sometimes as a negative
side-effect it takes over as a default font when installed.

Best,
Amr

Bug#998270: Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-core

[Amr Ibrahim]

Package: libncarg0

Hello,

Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-
core. The dejavu font extends the bitstream vera font and is already
installed by default on Debian GNOME. Besides, the bitstream vera font
is very obsolete, looks worse than dejavu and sometimes as a negative
side-effect it takes over as a default font when installed.

Best,
Amr

Bug#998269: Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-core

[Amr Ibrahim]

Package: openmsx-data

Hello,

Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-
core. The dejavu font extends the bitstream vera font and is already
installed by default on Debian GNOME. Besides, the bitstream vera font
is very obsolete, looks worse than dejavu and sometimes as a negative
side-effect it takes over as a default font when installed.

Best,
Amr

Bug#993009: RFP: cimfomfa -- tingea library for mcl

[Joost van Baal-Ilić]

Hi,

Some updates.

On Mon, Sep 06, 2021 at 02:05:33PM +0200, Joost van Baal-Ilić wrote:
> On Thu, Aug 26, 2021 at 11:26:55AM +0200, Joost van Baal-Ilić wrote:
> > Package: wnpp
> > Severity: wishlist
> > 
> > * Package name: cimfomfa
> >   Upstream Author : Stijn van Dongen 

URL : https://github.com/micans/cimfomfa

> > * License : GPL-3+
> >   Programming Lang: C

Description : C utility library libtingea for MCL and zoem

Long description:

cimfomfa is used by both MCL, a cluster algorithm for graphs, and zoem,
a macro/DSL language. It supplies abstractions for memory management, I/O,
associative arrays, strings, heaps, and a few other things.
The tingea library comes with some testing programs.

> > Upstream published a git snapshot prerelease of cimfomfa, at
> > http://micans.org/phloobaz/cimfomfa-21-101.tar.gz .  The upcoming mcl 
> > tarball
> > will need cimfomfa to build, a git snapshot prerelease of upcoming mcl is
> > available from http://micans.org/phloobaz/mcl-21-100.tar.gz .  (We ship the
> > mcl package.)

BTW, the mcl code is maintained at public repository
https://github.com/micans/mcl .

> > It would be cool if the Debian Med Packaging Team at
> > https://salsa.debian.org/med-team could take up maintainership of this
> > library.


Or maybe zoem (debian-science), mcl (debian-med) and cimfomfa could all be
maintained by https://salsa.debian.org/math-team .  Since these packages will
now share dependencies, maybe that would work best.  Or would it be better to
move zoem from debian-science to debian-med?  Andreas Tille, Shayan Doust: any
opinions?

Bye,

Joost

Bug#998263: Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-core

[Sebastiaan Couwenberg]

Control: tags -1 - moreinfo
Control: tags -1 pending

On 11/1/21 19:49, Amr Ibrahim wrote:

On Mon, 2021-11-01 at 19:41 +0100, Sebastiaan Couwenberg wrote:

If you want to remove the ttf-bitstream-vera package, we can drop the
use of the package and not diverge from upstream.


Yes, please drop it.


Done in git, the changes will be included in the next upload.

Kind Regards,

Bas

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

Bug#998268: Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-core

[Amr Ibrahim]

Package: libprojectm3

Hello,

Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-
core. The dejavu font extends the bitstream vera font and is already
installed by default on Debian GNOME. Besides, the bitstream vera font
is very obsolete, looks worse than dejavu and sometimes as a negative
side-effect it takes over as a default font when installed.

Best,
Amr

Bug#998267: Please switch the suggests from ttf-bitstream-vera to fonts-dejavu-core

[Amr Ibrahim]

Package: python3-pygments

Hello,

Please switch the suggests from ttf-bitstream-vera to fonts-dejavu-
core. The dejavu font extends the bitstream vera font and is already
installed by default on Debian GNOME. Besides, the bitstream vera font
is very obsolete, looks worse than dejavu and sometimes as a negative
side-effect it takes over as a default font when installed.

Best,
Amr

Bug#998263: Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-core

[Amr Ibrahim]

On Mon, 2021-11-01 at 19:41 +0100, Sebastiaan Couwenberg wrote:
> If you want to remove the ttf-bitstream-vera package, we can drop the
> use of the package and not diverge from upstream.

Yes, please drop it.

Best,
Amr

Bug#998263: Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-core

[Sebastiaan Couwenberg]

Control: tags -1 moreinfo

On 11/1/21 19:32, Amr Ibrahim wrote:

Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-
core. The dejavu font extends the bitstream vera font and is already
installed by default on Debian GNOME. Besides, the bitstream vera font
is very obsolete, looks worse than dejavu and sometimes as a negative
side-effect it takes over as a default font when installed.


The vera ttf files are included in the upstream source tree, the package 
is used to avoid those embedded copies.


If you want to remove the ttf-bitstream-vera package, we can drop the 
use of the package and not diverge from upstream.


Kind Regards,

Bas

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

Bug#998244: lists.debian.org: request for debian-math mailing list (was: Re: Debian Math Team)

[Joost van Baal-Ilić]

Hi,

I am interested in the creation of this list.  The Debian Math Team is being
created now; https://salsa.debian.org/math-team was created last week, it
currently has 11 members.  The need for this group (and list) has been
discussed in the thread starting at
https://lists.debian.org/msgid-search/87wnlvn3fg@piedmont.edu ; people
expressed interest there.

Thanks, Bye,

Joost

Bug#998266: Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-core

[Amr Ibrahim]

Package: setbfree

Hello,

Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-
core. The dejavu font extends the bitstream vera font and is already
installed by default on Debian GNOME. Besides, the bitstream vera font
is very obsolete, looks worse than dejavu and sometimes as a negative
side-effect it takes over as a default font when installed.

Best,
Amr

Bug#998264: Please switch the recommends from ttf-bitstream-vera to fonts-dejavu-core

[Amr Ibrahim]

Package: vdr

Hello,

Please switch the recommends from ttf-bitstream-vera to fonts-dejavu-
core. The dejavu font extends the bitstream vera font and is already
installed by default on Debian GNOME. Besides, the bitstream vera font
is very obsolete, looks worse than dejavu and sometimes as a negative
side-effect it takes over as a default font when installed.

Best,
Amr

Bug#998265: epigrass: autopkgtest regression: The 'panel' distribution was not found

[Paul Gevers]

Source: epigrass
Version: 3.0.3+dfsg-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of epigrass the autopkgtest of epigrass fails in
testing when that autopkgtest is run with the binary packages of
epigrass from unstable. It passes when run with only packages from
testing. In tabular form:

   passfail
epigrass   from testing3.0.3+dfsg-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=epigrass

https://ci.debian.net/data/autopkgtest/testing/amd64/e/epigrass/16032967/log.gz

Traceback (most recent call last):
  File "/usr/bin/epirunner", line 33, in 
sys.exit(load_entry_point('epigrass==3.0.3', 'console_scripts',
'epirunner')())
  File "/usr/bin/epirunner", line 25, in importlib_load_entry_point
return next(matches).load()
  File "/usr/lib/python3.9/importlib/metadata.py", line 77, in load
module = import_module(match.group('module'))
  File "/usr/lib/python3.9/importlib/__init__.py", line 127, in
import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1030, in _gcd_import
  File "", line 1007, in _find_and_load
  File "", line 986, in _find_and_load_unlocked
  File "", line 680, in _load_unlocked
  File "", line 850, in exec_module
  File "", line 228, in
_call_with_frames_removed
  File "/usr/lib/python3/dist-packages/Epigrass/manager.py", line 20, in

from Epigrass.simobj import graph, edge, siteobj
  File "/usr/lib/python3/dist-packages/Epigrass/simobj.py", line 19, in

from Epigrass import models
  File "/usr/lib/python3/dist-packages/Epigrass/models.py", line 14, in

from epimodels.continuous.models import SIR, SEIR
  File "/usr/lib/python3/dist-packages/epimodels/continuous/models.py",
line 12, in 
import numba
  File "/usr/lib/python3/dist-packages/numba/__init__.py", line 19, in

from numba.core import config
  File "/usr/lib/python3/dist-packages/numba/core/config.py", line 16,
in 
import llvmlite.binding as ll
  File "/usr/lib/python3/dist-packages/llvmlite/binding/__init__.py",
line 4, in 
from .dylib import *
  File "/usr/lib/python3/dist-packages/llvmlite/binding/dylib.py", line
3, in 
from llvmlite.binding import ffi
  File "/usr/lib/python3/dist-packages/llvmlite/binding/ffi.py", line
137, in 
from pkg_resources import resource_filename
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
3243, in 
def _initialize_master_working_set():
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
3226, in _call_aside
f(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
3255, in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
568, in _build_master
ws.require(__requires__)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
886, in require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
772, in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'panel' distribution was not
found and is required by epigrass
autopkgtest [12:13:19]: test run-unit-test




OpenPGP_signature
Description: OpenPGP digital signature

Bug#974778: llvmlite: Please upgrade to llvm-toolchain-11

[Drew Parsons]

Source: llvmlite
Version: 0.35.0-3
Followup-For: Bug #974778
Control: affects -1 src:numba

Now that bullseye is released, please proceed fixing this bug now,
i.e. please package llvmlite 0.37.

It's required in order to package numba 0.54, which is needed to fix
problems on armel.

Bug#998263: Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-core

[Amr Ibrahim]

Package: python3-mapscript

Hello,

Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-
core. The dejavu font extends the bitstream vera font and is already
installed by default on Debian GNOME. Besides, the bitstream vera font
is very obsolete, looks worse than dejavu and sometimes as a negative
side-effect it takes over as a default font when installed.

Best,
Amr

Bug#998261: jsbundle-web-interfaces: autopkgtest regression: node: command not found

[Paul Gevers]

Source: jsbundle-web-interfaces
Version: 1.1.0+~2.0.1~ds+~7.0.0+~0~20180821-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of jsbundle-web-interfaces the autopkgtest of
jsbundle-web-interfaces fails in testing when that autopkgtest is run
with the binary packages of jsbundle-web-interfaces from unstable. It
passes when run with only packages from testing. In tabular form:

passfail
jsbundle-web-interfaces from testing
1.1.0+~2.0.1~ds+~7.0.0+~0~20180821-1
all others  from testingfrom testing

I copied some of the output at the bottom of this report. It seems that
when you dropped the (Build-)Depends, you forgot it was needed for the test.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=jsbundle-web-interfaces

https://ci.debian.net/data/autopkgtest/testing/amd64/j/jsbundle-web-interfaces/16336344/log.gz

bash: line 1: node: command not found
autopkgtest [15:09:56]: test command1




OpenPGP_signature
Description: OpenPGP digital signature

Bug#998262: Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-core

[Amr Ibrahim]

Package: python3-django-captcha

Hello,

Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-
core. The dejavu font extends the bitstream vera font and is already
installed by default on Debian GNOME. Besides, the bitstream vera font
is very obsolete, looks worse than dejavu and sometimes as a negative
side-effect it takes over as a default font when installed.

Best,
Amr

Bug#994750: RFS: mazeofgalious/0.63-1 [ITA] -- The Maze of Galious

[Parodper]

Thank you for reviewing the package, and sorry for any inconveniences.

O 01/11/21 ás 12:51, Bastian Germann escribiu:

There is a hint in #341497 why the repackage was done.


Sorry, but I do not see it. I only see a bug report about the game not
starting, which also happened to me when I removed the non-default sets.


I do not see this changed (the links) in your current package.


The current mazeofgalious-data.links for all the graphics/sound sets to
the default ones. I don't see what needs to be changed.


Also, some sounds are repacked to silence.


To silence? I did change the sounds missing in the jorito set, but for
other adjacent ones. It should not be silence.

Please fix #998229 and use the current download as a base for your 
package. This also gets rid of build/osx and build/windows.


It seems that the Download version has a debian folder. Would this make
it a «native» package?

In any case, the source seems to be the same for both (SVN and Download)
versions, and this game is not going to have any more development, so I
don't think this will be a problem.


The #341501 change must be done as a repack (+dfsg), not as a patch.


A few questions on that:

* Should I create the links inside the folders, or leave the 
mazeofgalious-data.links file?

* What is the syntax for dfsg versions? I can't find it anywhere.

Bug#998260: ITP: golang-github-beevik-ntp -- a simple ntp client package for go

[Benjamin Drung]

X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: Benjamin Drung 

* Package name    : golang-github-beevik-ntp
  Version : 0.3.0-1
  Upstream Author : Brett Vickers
* URL : https://github.com/beevik/ntp
* License : BSD-2-clause
  Programming Lang: Go
  Description : a simple ntp client package for go

This package contains an implementation of a Simple NTP (SNTP) client
based on RFC 5905 (https://tools.ietf.org/html/rfc5905). It allows you
to connect to a remote NTP server and request information about the
current time.

This library was vendored in prometheus-node-exporter and is now
packaged separately.

-- 
Benjamin Drung

Senior DevOps Engineer and Debian & Ubuntu Developer
Compute Platform Operations

1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Deutschland
E-Mail: benjamin.dr...@ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498

Vorstand: Hüseyin Dogan, Dr. Martin Endreß, Claudia Frese, Henning
Kettler, Arthur Mai, Matthias Steinberg, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke


Member of United Internet

Bug#998259: src:osslsigncode: fails to migrate to testing for too long: unresolved RC bugs

[Paul Gevers]

Source: osslsigncode
Version: 2.1-1
Severity: serious
Control: close -1 2.2-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 993451 993452
Control: tags 993451 ftbfs
Control: severity 993451 serious
Control: tags 993452 ftbfs
Control: severity 993452 serious

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing
and unstable for more than 60 days as having a Release Critical bug in
testing [1]. Your package src:osslsigncode has been trying to migrate
for 61 days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bookworm, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=osslsigncode




OpenPGP_signature
Description: OpenPGP digital signature

Bug#998258: node-liftoff: FTBFS: TypeError: isPlainObject is not a function

[Andreas Beckmann]

Source: node-liftoff
Version: 3.1.0-5
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi,

node-liftoff/experimental recently started to FTBFS with

  dh_auto_build --buildsystem=nodejs
No build command found, searching known files
No build command found, searching known files
No build command found, searching known files
   dh_auto_test --buildsystem=nodejs
ln -s ../. node_modules/liftoff
/bin/sh -ex debian/tests/pkg-js/test
+ mocha -t 2 -b -R spec test/index


  Liftoff
buildEnvironment
  undefined should locate local module using cwd if no config is found
  undefined should locate global module using NODE_PATH if defined
  undefined if cwd is explicitly provided, don't use search_paths
  undefined should find case sensitive configPath
  - should find module in the directory next to config
  - should require the package sibling to the module
  undefined should set cwd to match the directory of the config file as 
long as cwd wasn't explicitly provided
  for developing against yourself
- should find and load package.json
- should clear modulePackage if package.json is of different project
- should use `index.js` if `main` property in package.json does not 
exist
prepare
  undefined should set the process.title to the moduleName
  undefined should return early if completions are available and requested
  undefined should call prepare with liftoff instance as context
  undefined should pass environment to first argument of prepare callback
  undefined should throw if 2nd arg is not a function
execute
  undefined should pass environment to first argument of execute callback
  undefined should throw if 2nd arg is not a function
  - should skip respawning if process.argv has no values from v8flags in it
  - should respawn if process.argv has values from v8flags in it
  - should throw if v8flags is a function and it causes an error
  - should respawn if v8flag is set by forcedFlags
  - should respawn if v8flag is set by both cli flag and forcedFlags
  - should emit a respawn event if a respawn is required
  - should respawn if process.argv has v8flags with values in it
  - should respawn if v8flags is empty but forcedFlags are specified
requireLocal
  - should attempt pre-loading local modules if they are requested
  - should attempt pre-loading a local module if it is requested
  - should attempt pre-loading local modules but fail
  - should pre-load a local module only once even if be respawned
  - should emit `require` with the name of the module and the required 
module
  undefined should emit `requireFail` with an error if a module can't be 
found.
configFiles
  undefined should be empty if not specified
  1) should find multiple files if specified


  14 passing (49ms)
  18 pending
  1 failing

  1) Liftoff
   configFiles
 should find multiple files if specified:
 TypeError: isPlainObject is not a function
  at expandPath (/usr/share/nodejs/fined/index.js:19:8)
  at fined (/usr/share/nodejs/fined/index.js:14:22)
  at /build/node-liftoff-3.1.0/index.js:122:21
  at /build/node-liftoff-3.1.0/object-map/index.js:18:19
  at /usr/lib/nodejs/for-own/index.js:16:17
  at forIn (/usr/lib/nodejs/for-in/index.js:12:12)
  at forOwn (/usr/lib/nodejs/for-own/index.js:14:3)
  at module.exports (object-map/index.js:17:3)
  at /build/node-liftoff-3.1.0/index.js:121:14
  at /build/node-liftoff-3.1.0/object-map/index.js:18:19
  at /usr/lib/nodejs/for-own/index.js:16:17
  at forIn (/usr/lib/nodejs/for-in/index.js:12:12)
  at forOwn (/usr/lib/nodejs/for-own/index.js:14:3)
  at module.exports (object-map/index.js:17:3)
  at Liftoff.buildEnvironment (index.js:119:19)
  at Liftoff.prepare (index.js:171:18)
  at Context. (test/index.js:410:11)
  at callFnAsync (/usr/share/nodejs/mocha/lib/runnable.js:394:21)
  at Test.Runnable.run (/usr/share/nodejs/mocha/lib/runnable.js:338:7)
  at Runner.runTest (/usr/share/nodejs/mocha/lib/runner.js:681:10)
  at /usr/share/nodejs/mocha/lib/runner.js:804:12
  at next (/usr/share/nodejs/mocha/lib/runner.js:596:14)
  at /usr/share/nodejs/mocha/lib/runner.js:606:7
  at next (/usr/share/nodejs/mocha/lib/runner.js:489:14)
  at Immediate._onImmediate (/usr/share/nodejs/mocha/lib/runner.js:574:5)
  at processImmediate (internal/timers.js:461:21)



dh_auto_test: error: /bin/sh -ex debian/tests/pkg-js/test returned exit code 1
make: *** [debian/rules:5: binary] Error 25


Andreas


node-liftoff_3.1.0-5.log.gz
Description: application/gzip

Bug#998257: ITP: golang-github-josharian-native -- Easy to use native encoding/binary.ByteOrder

[Benjamin Drung]

X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: Benjamin Drung 

* Package name    : golang-github-josharian-native
  Version : 0.0~git20200817.b6b71de-1
  Upstream Author : Josh Bleecher Snyder
* URL : https://github.com/josharian/native
* License : Expat
  Programming Lang: Go
  Description : Easy to use native encoding/binary.ByteOrder

 Package native provides easy access to native byte order.
 .
 go get github.com/josharian/native
 .
 Usage: Use native.Endian where you need the native binary.ByteOrder.
 .
 Please think twice before using this package.  It can break program
 portability.  Native byte order is usually not the right answer.

This library was vendored in prometheus-node-exporter and is now
packaged separately.

-- 
Benjamin Drung

Senior DevOps Engineer and Debian & Ubuntu Developer
Compute Platform Operations

1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Deutschland
E-Mail: benjamin.dr...@ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498

Vorstand: Hüseyin Dogan, Dr. Martin Endreß, Claudia Frese, Henning
Kettler, Arthur Mai, Matthias Steinberg, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke


Member of United Internet

Bug#998256: graphviz: helping upgrade to 2.49.3

[Patrice Duroux]

Source: graphviz
Version: 2.42.2-5
Severity: wishlist

Dear Maintainer,

Using sbuild and a set of changes (attached file) I was able to generate new
packages.

Here are some points addressed with remarks:

  * Update watch file.
  * Remove patches applied upstream:
- fix_out-of-bounds_write_on_invalid_label.patch
- update_documentation_link.patch
  * Refresh patches:
- gvmap.sh_bashism.patch
see my report: https://gitlab.com/graphviz/graphviz/-/issues/2151
- build_with_libann.patch
- 50_remove_changelog_in
  * Inactivated patch:
- fix-kfreebsd-chroots
Remark: still needed?
  * Remove all manpages and related files, provided by upstream.
  * Replace graphviz-doc.install by graphviz-doc.docs and graphviz-
doc.examples.
  * Remove orphan mksvgfonts.pl.
Remark: it is no more hidden in the upstream and was not included in
any packages of the previous release.
  * Add gvpr(3) manpage to libgvpr2.
  * Add xdot(3) manpage to libxdot4.
  * Add pack(3) manpage to libgraphviz-dev.
  * Add upstream/metadata.
  * Add not-installed.
Remark: its content may be adjusted.
  * Simplify and update control to build and add:
- gvedit, gvpr and smyrna
Remark: new bins in graphviz.
- lasi, poppler, devil and gs plugins
Remark: new libs in libgvc6.

README.Debian-packaging and README.source are mostly similar.
And I haven't check the content to verify its relevance.

Bindings to Java, R, Go, and C# are also available in the upstream.
But they are not considered yet even if I was able to build them all
using the commented depends in d/control.

Don't know yet if the new binaries and plugins have to be added.
It may be useful in future to split headless binaries to the other, no?

Fill free to take what you want.

Regards,
Patrice


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

Kernel: Linux 5.14.0-3-amd64 (SMP w/12 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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
diff -Nur graphviz.old/debian/control graphviz/debian/control
--- graphviz.old/debian/control 2020-04-26 07:25:24.0 +0200
+++ graphviz/debian/control 2021-11-01 11:34:30.114084895 +0100
@@ -2,51 +2,55 @@
 Section: graphics
 Priority: optional
 Maintainer: Laszlo Boszormenyi (GCS) 
-Standards-Version: 4.5.0
-Build-Depends: tk-dev,
- tcl-dev,
- debhelper-compat (= 11),
+Standards-Version: 4.6.0
+Build-Depends: debhelper-compat (= 13),
  dh-python,
- libfreetype6-dev,
- zlib1g-dev,
- libjpeg-dev,
- libpng-dev,
- libxaw7-dev,
+ libltdl-dev,
+ pkg-config,
+ tcl-dev,
  bison,
  flex,
  libexpat1-dev,
- libfontconfig1-dev,
  swig,
  libperl-dev,
- libgd-dev (>= 2.0.33),
+ libgd-dev,
  guile-3.0-dev,
- groff-base,
  ghostscript,
- lua5.2,
- liblua5.2-dev,
- ruby,
- ruby-dev (>= 1:2.2),
+ libgs-dev,
+ libpoppler-glib-dev,
+ lua5.4,
+ liblua5.4-dev,
+ ruby-dev,
  libargon2-dev,
  libsodium-dev,
- libxml2-dev,
  php-dev,
  python3-dev,
  libcairo2-dev,
- libpango1.0-dev,
- d-shlibs,
- chrpath,
- libgtk2.0-dev,
+ libgtkgl2.0-dev,
+ libgtkglext1-dev,
+ libglade2-dev,
  libgts-dev,
  libann-dev,
  librsvg2-dev,
- libwebp-dev
-Build-Conflicts: tcl8.3, tcl8.4, tcl8.5
+ freeglut3-dev,
+ libwebp-dev,
+ libdevil-dev,
+ liblasi-dev,
+ qt5-qmake,
+ qtbase5-dev,
+# mono-devel,
+# golang,
+# default-jdk-headless,
+# r-base-dev,
+# ocaml-nox,
+ libcriterion-dev 
 Homepage: https://www.graphviz.org/
+Rules-Requires-Root: no
 
 Package: graphviz
 Architecture: any
 Multi-Arch: foreign
-Depends: ${shlibs:Depends}, libgvc6 (>= 2.42.1), ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}
 Recommends: fonts-liberation
 Suggests: gsfonts, graphviz-doc
 Description: rich set of graph drawing tools
@@ -109,7 +113,7 @@
 Architecture: any
 Multi-Arch: same
 Section: php
-Depends: ${shlibs:Depends}, ${php:Depends}, ${misc:Depends}
+Depends: ${php7:Depends}, ${shlibs:Depends}, ${misc:Depends}
 Description: PHP7 bindings for graphviz
  Graphviz is a set of graph drawing tools. See the description of the graphviz
  package for a full description.
@@ -119,7 +123,8 @@
 Package: python3-gv
 Architecture: any
 Section: python
-Depends: ${shlibs:Depends}, ${python3:Depends}, ${misc:Depends}
+Multi-Arch: same
+Depends: ${python3:Depends}, ${shlibs:Depends}, ${misc:Depends}
 Breaks: libgv-python (<< 2.40.1-0~)
 Replaces: libgv-python (<< 2.40.1-0~)
 Description: Python3 bindings for graphviz
@@ -139,7 +144,6 @@
  .
  This package contains the Ruby bindings.
 
-
 Package: libgv-tcl
 Architecture: any
 Multi-Arch: same
diff -Nur graphviz.old/debian/diffimg.1 graphviz/debian/diffimg.1
--- graphviz.old/debian/diffimg.1   2014-12-10 16:25:41.0 +0100
+++ 

Bug#998255: fbzx: FTBFS with GCC 11: error: reference to 'byte' is ambiguous

[Andreas Beckmann]

Source: fbzx
Version: 3.1.0-1
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)

Hi,

fbzx FTBFS with GCC 11 which defaults to -std=c++17:

g++ -c -O2 -Wdate-time -D_FORTIFY_SOURCE=2 `pkg-config --cflags sdl 
libpulse-simple alsa` -D D_SOUND_PULSE -D D_SOUND_ALSA -D D_SOUND_OSS -o 
cargador.o cargador.cpp
In file included from emulator.hh:22,
 from tape.hh:35,
 from computer.hh:26,
 from cargador.hh:20,
 from cargador.cpp:20:
z80free/Z80free.h:56:17: error: reference to 'byte' is ambiguous
   56 | byte F,A, C,B, E,D, L,H, IXl,IXh, IYl,IYh, P,S;
  | ^~~~
In file included from /usr/include/c++/11/bits/stl_algobase.h:61,
 from /usr/include/c++/11/bits/char_traits.h:39,
 from /usr/include/c++/11/string:40,
 from tape.hh:30,
 from computer.hh:26,
 from cargador.hh:20,
 from cargador.cpp:20:
/usr/include/c++/11/bits/cpp_type_traits.h:404:30: note: candidates are: 'enum 
class std::byte'
  404 |   enum class byte : unsigned char;
  |  ^~~~
In file included from emulator.hh:22,
 from tape.hh:35,
 from computer.hh:26,
 from cargador.hh:20,
 from cargador.cpp:20:
z80free/Z80free.h:28:23: note: 'typedef unsigned char byte'
   28 | typedef unsigned char byte;
  |   ^~~~
z80free/Z80free.h:75:9: error: reference to 'byte' is ambiguous
   75 | byteR;  /* Refresh */
  | ^~~~
In file included from /usr/include/c++/11/bits/stl_algobase.h:61,
 from /usr/include/c++/11/bits/char_traits.h:39,
 from /usr/include/c++/11/string:40,
 from tape.hh:30,
 from computer.hh:26,
 from cargador.hh:20,
 from cargador.cpp:20:
/usr/include/c++/11/bits/cpp_type_traits.h:404:30: note: candidates are: 'enum 
class std::byte'
  404 |   enum class byte : unsigned char;
  |  ^~~~
In file included from emulator.hh:22,
 from tape.hh:35,
 from computer.hh:26,
 from cargador.hh:20,
 from cargador.cpp:20:
z80free/Z80free.h:28:23: note: 'typedef unsigned char byte'
   28 | typedef unsigned char byte;
  |   ^~~~
[...]

Andreas


fbzx_3.1.0-1.log.gz
Description: application/gzip