Bug#994858: libglib2.0-0: After upgrade to 2.70.0-1, broken nextcloud-desktop

[John Wong]

On 9/22/21 3:36 PM, Simon McVittie wrote:

Control: tags -1 + moreinfo
Control: notfound -1 2.68.4-1
Control: found -1 2.70.0-1

On Wed, 22 Sep 2021 at 11:52:21 +0800, John Wong wrote:

After upgrade from 2.68.4-1 to 2.70.0-1, nextcloud-desktop
cannot work anymore, rollback to 2.68.4-1 fixed problem.


What exactly does "cannot work" mean?

What version of nextcloud-desktop are you using?

If you run nextcloud-desktop from a terminal such as gnome-terminal or
xterm while using libglib2.0-0 2.70.0-1, are there any error messages?

What would a developer who does not normally use nextcloud-desktop need to
do to reproduce this problem?

I tried installing nextcloud-desktop version 3.3.3-1 and connecting it to
an account created by  on the demo instance
. It was able to download files and did not
produce any obvious errors or warnings.

 smcv


Hi Simon,

When I run nextcloud-desktop on terminal, there is no error but just hang on there and cannot 
login. (sorry cannot provide useful information)

https://ibb.co/mzn9ykH

I rollback (with btrfs snapshot) , and hold the package.

john@redcat:~$ dpkg --get-selections |grep hold
libglib2.0-0:amd64  hold
john@redcat:~$ sudo apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  gir1.2-freedesktop gir1.2-glib-2.0 glib-networking glib-networking-services 
libgirepository-1.0-1 libglib2.0-0

0 upgraded, 0 newly installed, 0 to remove and 6 not upgraded.
john@redcat:~$

Regards & Thanks,
John.

Bug#994916: Jessie: Bad archive mirror

[Thorsten]

Package: mirrors
Severity: important

Dear Maintainer,

I'm having some trouble to install the latest Jessie Version (8.11). I
need this for some legacy systems... At the installation process I'm
getting a "Bad archive mirror" error, which is a result of this error:
"broken mirror: invalid Suite in Release file for Jessie"

Your README [1] says:
"Debian 8.11, or jessie. Access this release through dists/oldoldoldstable"

But in the release file [2] the Suite name is: oldoldstable and not
oldoldoldstable and for my understanding, this causes the "Bad archive
mirror" error.

Furthermore I tried to install Jessie (8.0?) from the archive mirrors, which
will work to a certain point of the base installation process, but it
fails somewhere at the end. The error this time:
"Unable to install busybox" which is a result of the error "Warning: The
following packages cannot be authenticated"


I believe, fixing the suite name in the release file would solve the
"bad archive mirror" installation problem.

Thank you.

Best regards
Thorsten


1: https://ftp.debian.org/debian/README
2: https://ftp.debian.org/debian/dists/oldoldoldstable/Release

Bug#994915: thunderbird: When I changed email address of an account, Thunderbird goes in a infinite loop

[rpnpif]

Package: thunderbird
Version: 1:78.14.0-1~deb10u1
Severity: important

Dear Maintainer,

When I changed the email address of an account in settings dialog of the 
account, Thunderbird 78 goes in a infinite loop.
It did not respond to click, its window cannot be displayed after a moment.
I must killed Thunderbird and restart, then all work fine but the change had 
been well saved.

Expected : When I change the email address of an account, Thunderbird should 
give back the hand to the user after some seconds and should not go in an 
infinite loop.

Regards

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

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

Versions of packages thunderbird depends on:
ii  debianutils 4.8.6.1
ii  fontconfig  2.13.1-2
ii  libatk1.0-0 2.36.0-2~bpo10+1
ii  libbotan-2-92.9.0-2
ii  libbz2-1.0  1.0.6-9.2~deb10u1
ii  libc6   2.28-10
ii  libcairo-gobject2   1.16.0-4+deb10u1
ii  libcairo2   1.16.0-4+deb10u1
ii  libdbus-1-3 1.12.20-0+deb10u1
ii  libdbus-glib-1-20.110-4
ii  libevent-2.1-6  2.1.8-stable-4
ii  libffi6 3.2.1-9
ii  libfontconfig1  2.13.1-2
ii  libfreetype62.9.1-3+deb10u2
ii  libgcc1 1:8.3.0-6
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libglib2.0-02.58.3-2+deb10u3
ii  libgtk-3-0  3.24.5-1
ii  libjson-c3  0.12.1+ds-2+deb10u1
ii  libpango-1.0-0  1.42.4-8~deb10u1
ii  libstdc++6  8.3.0-6
ii  libx11-62:1.6.7-1+deb10u2
ii  libx11-xcb1 2:1.6.7-1+deb10u2
ii  libxcb-shm0 1.13.1-2
ii  libxcb1 1.13.1-2
ii  libxext62:1.3.3-1+b2
ii  libxrender1 1:0.9.10-1
ii  psmisc  23.2-1
ii  x11-utils   7.7+4
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages thunderbird recommends:
ii  hunspell-en-gb [hunspell-dictionary] 1:6.2.0-1
ii  hunspell-en-us [hunspell-dictionary] 1:2018.04.16-1
ii  hunspell-fr-classical [hunspell-dictionary]  1:6.3-2

Versions of packages thunderbird suggests:
ii  apparmor  2.13.2-10
ii  fonts-lyx 2.3.2-1
ii  libgssapi-krb5-2  1.17-3+deb10u2
ii  libgtk2.0-0   2.24.32-3

-- no debconf information

Bug#994903: remove-on-upgrade breaks packages replacing conffiles by non-conffile

[Sven Joachim]

On 2021-09-23 00:20 +0200, Christoph Berg wrote:

> Package: dpkg
> Version: 1.20.9
> Severity: normal
> X-Debbugs-Cc: Niels Thykier 
>
> Hi,
>
> the new remove-on-upgrade logic from #822462 breaks the use-case of
> replacing a conffile by a non-conffile version.

Not only that, it also breaks if the conffile has been moved to another
package.  Today's systemd upgrade surprised me by deleting two conffiles
of systemd-timesyncd:

,
| systemd (247.9-2) wird eingerichtet ...
| Entfernen des veralteten Conffiles /etc/dhcp/dhclient-exit-hooks.d/timesyncd 
...
| Entfernen des veralteten Conffiles /etc/systemd/timesyncd.conf ...
`

,
| $ dpkg --verify systemd-timesyncd
| ??5?? c /etc/dhcp/dhclient-exit-hooks.d/timesyncd
| ??5?? c /etc/systemd/timesyncd.conf
`

Cheers,
   Sven

Bug#988696: connman does not respect /etc/network/interfaces when upgrading from buster to bullseye and more general considerations

[Andreas Tille]

On Wed, Sep 22, 2021 at 10:21:10PM +0200, Ervin Dine wrote:
> I have not had any problems with conman in my LXDE Debian 11 install
> but if I may give my suggestion, gnome-network-manager works fine with
> LXDE and it has more features. Why not bundle that instead of conman?
> Conman does not even have an icon in the status bar where you can
> toggle wifi on and off or choose another connection. 

The missing icon in the status bar triggered bug #988696.  I personally
consider this very unfriendly to new users.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#994914: python-autobahn: Please package new upstream release of autobahn

[Vasudev Kamath]

Source: python-autobahn
Severity: wishlist

Dear Maintainer,

We are working on to reintroduce tahoe-lafs to Debian since a new version
with python3 support has been release. New version need autobahn >= 19.5.2. 

Can you please consider updating the package to latest upstream release so we 
will be
unblocked on introducing tahoe again to Debian.

Thanks and Regards,
Vasudev

-- 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)

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

Bug#994913: python-eliot: Please package eliot version 1.13.0

[Vasudev Kamath]

Source: python-eliot
Severity: wishlist

Dear Maintainer,

We are working on reintroducing the tahoe-lafs back to Debian now that it 
supports python3.
But newer version of tahoe-lafs needs eliot to be updated to 1.13.0. Here is 
the comment from
the upstream requirements file

# On Python 3, we want a new enough version to support custom JSON encoders.
"eliot >= 1.13.0 ; python_version > '3.0'",

Could you please consider updating eliot to latest upstream release so we can 
be unblocked
to upload tahoe to Debian.

Thanks and Regards,
Vasudev

-- 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)

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

Bug#992917: grok: FTBFS due to RPC removal from glibc

[Stig Sandbeck Mathisen]

Adrian Bunk  writes:

> On Wed, Sep 22, 2021 at 08:22:04PM +0200, Stig Sandbeck Mathisen wrote:
>> Adrian Bunk  writes:
>> 
>> > On Sat, Aug 28, 2021 at 09:43:36PM +0200, Stig Sandbeck Mathisen wrote:
>> >> 
>> >> Hello,
>> >> 
>> >> Thank you for the bug report and patch. I did a slight adjustment,
>> >> adding the parameters in debian/rules, and targeting the "gnu"
>> >> libc, see
>> >> https://salsa.debian.org/debian/grok/-/commit/fe4c4b549ae2595007271df7502feb54115f4dda
>> >
>> > Could you make an upload with this bug fixed?
>> 
>> That fixed the bug, but the package unfortunately still won't build,
>> and why or why not this happens is not clear to me. Any hints would
>> be welcome. (build log for that commit at
>> https://salsa.debian.org/debian/grok/-/jobs/1870864)
>
> That was fixed in one of the missing NMUs.

Thanks, I'll import those and get the package in shape again.

-- 
Stig Sandbeck Mathisen
Debian Developer

Bug#993864: [pkg-tasktools] Bug#993864: ITP: taskserver -- taskwarrior synchronisation server

[Sergio Cipriano]

On Wednesday, September 22nd, 2021 at 05:46, Mattia Rizzolo  
wrote:

> On Wed, Sep 22, 2021 at 01:43:06AM +, Sergio Cipriano wrote:
>
> > > AFAIK that's: https://tracker.debian.org/pkg/taskd which became quite a
> > >
> > > bit abandonend over time. however I'd be interested in reviving it.
> >
> > After talking to Gordon, I started making some changes to the package so it 
> > could get back to testing.
> >
> > I haven't uploaded these changes to the main repository yet, but I plan to.
>
> Feel free to push whenever you wish (if in doubt, a different branch is
>
> always fine).

I'm currently working on a fork [1], when it's done I'll open an MR.

> > > I drifted away from the project, but it wouldn't be bad to start on it
> > >
> > > again.
> >
> > Your help would be very welcome.
> >
> > Could you review and sponsor the package when the changes are ready?
>
> Sure! Just mail me (or try to hit me on IRC, I'm "mapreri" there).

Ok, thanks!

> Having said this, I think this ITP could be closed, right?

It was closed a little while ago [2].

[1]: https://salsa.debian.org/sergiosacj/taskd
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993864;msg=7

--
Regards,
Sérgio Cipriano.

Bug#970013: pulseaudio-utils: cannot switch to headset_head_unit

[Chad]

Package: pulseaudio
Version: 14.2-2
Followup-For: Bug #970013

Dear Maintainer,

As with the original reporter of this bug, I too cannot change the
profile of my associated bluetooth headsets to
headset_head_unit. Below is a clip of the output from "pactl list"
after associating a headset. I recall this working at some point in
the past, but I don't have a good fixture on when that changed, as it
has been quite some time since I've used any bluetooth headset to
record.

This could also potentially be related to pulseaudio-module-bluetooth bug 
#993011?

-- Output from "pactl list":
Card #2
Name: bluez_card.F4_4E_FC_22_A0_0A
Driver: module-bluez5-device.c
Owner Module: 21
Properties:
device.description = "S17"
device.string = "F4:4E:FC:22:A0:0A"
device.api = "bluez"
device.class = "sound"
device.bus = "bluetooth"
device.form_factor = "headset"
bluez.path = "/org/bluez/hci0/dev_F4_4E_FC_22_A0_0A"
bluez.class = "0x240404"
bluez.alias = "S17"
device.icon_name = "audio-headset-bluetooth"
device.intended_roles = "phone"
Profiles:
a2dp_sink: High Fidelity Playback (A2DP Sink) (sinks: 1, 
sources: 0, priority: 40, available: yes)
headset_head_unit: Headset Head Unit (HSP/HFP) (sinks: 1, 
sources: 1, priority: 30, available: no)
off: Off (sinks: 0, sources: 0, priority: 0, available: yes)
Active Profile: a2dp_sink
Ports:
headset-output: Headset (type: Headset, priority: 0, latency 
offset: 0 usec, availability unknown)
Part of profile(s): a2dp_sink, headset_head_unit
headset-input: Headset (type: Headset, priority: 0, latency 
offset: 0 usec, not available)
Part of profile(s): headset_head_unit


Trying to switch to the headset_head_unit profile on this card fails:

-- Setting card profile with pactl:
$ pactl set-card-profile 2 off
$ pactl set-card-profile 2 a2dp_sink
$ pactl set-card-profile 2 headset_head_unit
Failure: Input/Output error

-- journalctl output
Sep 22 22:13:59 strigo pulseaudio[6071]: Refused to switch profile to 
headset_head_unit: Not connected


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


-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (10, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages 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
ii  libcap2  1:2.44-1
ii  libdbus-1-3  1.12.20-2
ii  libgcc-s110.2.1-6
ii  libice6  2:1.0.10-1
ii  libltdl7 2.4.6-15
ii  liborc-0.4-0 1:0.4.32-1
ii  libpulse014.2-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 14.2-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  
ii  pavucontrol  4.0-2
pn  pavumeter
ii  udev 247.3-6

-- Configuration Files:
/etc/pulse/default.pa changed:
.fail
load-module module-device-restore
load-module module-stream-restore
load-module module-card-restore
load-module module-augment-properties
load-module module-switch-on-port-available
.ifexists module-udev-detect.so
load-module module-udev-detect
.else
load-module module-detect
.endif
.ifexists module-jackdbus-detect.so
.nofail
load-module module-jackdbus-detect channels=2
.fail
.endif
.ifexists module-bluetooth-policy.so
load-module module-bluetooth-policy enable_native_hfp_hf=false
.endif
.ifexists module-bluetooth-discover.so
load-module module-bluetooth-discover
.endif

Bug#994912: RFS: pyupgrade/2.24.0-1 [RFP] -- Tool to automatically upgrade Python 3 syntax for newer versions

[Joshua Peisach]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "pyupgrade":

 * Package name: pyupgrade
   Version : 2.24.0-1
   Upstream Author : Anthony Sottile 
 * URL : https://github.com/asottile/pyupgrade
 * License : MIT
 * Vcs : https://salsa.debian.org/python-team/packages/pyupgrade
   Section : devel

It builds those binary packages:

  pyupgrade - Tool to automatically upgrade Python 3 syntax for newer versions

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/pyupgrade/pyupgrade_2.24.0-1.dsc

Changes for the initial release:

 pyupgrade (2.24.0-1) unstable; urgency=medium
 .
   * Initial packaging
   * Fix lintian issues, cleanup and add a few extra essentials
 .
   * Initial release (Closes: #988658)

Regards,
--
  Joshua Peisach

Bug#790943: Root and local certificate location clash

[David Mandelberg]

I just came across this while configuring the CA certs for some 
software. It would be really nice if this security issue were fixed at 
some point. In the meantime, it looks like 
/etc/ssl/certs/ca-certificates.crt doesn't have the snake oil 
certificate (at least on my systems) even though /etc/ssl/cert does have 
symlinks to it. So I think it might be a reasonable workaround to point 
software at the single file instead of the directory?

Bug#994911: error modifying deb822 object while iterating

[Jelmer Vernooij]

Package: python3-debian
Version: 0.1.41
Severity: normal

Modifying a deb822 file while iterating over it results in a RuntimeError:

...
  File 
"/home/jelmer/src/debian-janitor/python-debian/lib/debian/_deb822_repro/parsing.py",
 line 2208, in iter_keys
yield from self._kvpair_elements
RuntimeError: dictionary keys changed during iteration

(This doesn't happen with the default deb822 implementation)

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

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

Versions of packages python3-debian depends on:
ii  python3  3.9.2-3
ii  python3-chardet  4.0.0-1
ii  python3-six  1.16.0-2

Versions of packages python3-debian recommends:
ii  python3-apt  2.2.1

Versions of packages python3-debian suggests:
ii  gpgv  2.2.27-2

-- no debconf information

Bug#994910: tripwire segfaults while reading files in /etc

[Ron Murray]

Package: tripwire
Version: 2.4.3.7-3+b3
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

I've been using tripwire for several years now, and never had troubles
with it until this morning (perhaps [not] coincidentally with the
updated glibc6).

Now it segfaults a short time after starting. An strace of it comes
out something like this at the end:

openat(AT_FDCWD, "/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=545, ...}) = 0
read(3, "# /etc/nsswitch.conf\n#\n# Example"..., 4096) = 545
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xe0} ---
write(2, "Software interrupt forced exit: "..., 51Software interrupt 
forced exit: Segmentation Fault
) = 51
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x421} ---
+++ killed by SIGSEGV (core dumped) +++

I did this several times, and other files in /etc failed instead of
nsswitch.conf (passwd was one).

Since there's no dbgsym package for this version of tripwire, I
rebuilt from source (using gcc 10), and, after installing, it worked
fine with no segfault. However, this was version 2.4.3.7-3, not
2.4.3.7-3+b3: there doesn't seem to be a source for the "+b3" version.

I have coredumps and full strace if anyone needs it.

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

Kernel: Linux 5.14.7.khufu (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tripwire depends on:
ii  debconf [debconf-2.0]1.5.77
ii  sendmail-bin [mail-transport-agent]  8.15.2-23

tripwire recommends no packages.

tripwire suggests no packages.

- -- Configuration Files:
/etc/tripwire/twpol.txt changed:
@@section GLOBAL
TWBIN = /usr/sbin;
TWETC = /etc/tripwire;
TWVAR = /var/lib/tripwire;
@@section FS
SEC_CRIT  = $(IgnoreNone)-SHa ; # Critical files that cannot change
SEC_BIN   = $(ReadOnly) ;# Binaries that should not change
SEC_CONFIG= $(Dynamic) ; # Config files that are changed
# infrequently but accessed
# often
SEC_LOG   = $(Growing) ; # Files that grow, but that
 # should never change ownership
SEC_INVARIANT = +tpug ;  # Directories that should never
# change permission or ownership
SIG_LOW   = 33 ; # Non-critical files that are of
 # minimal security impact
SIG_MED   = 66 ; # Non-critical files that are of
 # significant security impact
SIG_HI= 100 ;# Critical files that are
 # significant points of
 # vulnerability
(
  rulename = "Tripwire Binaries",
  severity = $(SIG_HI)
)
{
$(TWBIN)/siggen -> $(SEC_BIN) ;
$(TWBIN)/tripwire   -> $(SEC_BIN) ;
$(TWBIN)/twadmin-> $(SEC_BIN) ;
$(TWBIN)/twprint-> $(SEC_BIN) ;
}
(
  rulename = "Tripwire Data Files",
  severity = $(SIG_HI)
)
{
$(TWVAR)/$(HOSTNAME).twd-> $(SEC_CONFIG) -i ;
$(TWETC)/tw.pol -> $(SEC_BIN) -i ;
$(TWETC)/tw.cfg -> $(SEC_BIN) -i ;
$(TWETC)/$(HOSTNAME)-local.key  -> $(SEC_BIN) ;
$(TWETC)/site.key   -> $(SEC_BIN) ;
#don't scan the individual reports
$(TWVAR)/report -> $(SEC_CONFIG) (recurse=0) ;
}
(
  rulename = "Critical system boot files",
  severity = $(SIG_HI)
)
{
/boot   -> $(SEC_CRIT) ;
/lib/modules-> $(SEC_CRIT) ;
}
(
  rulename = "Boot Scripts",
  severity = $(SIG_HI)
)
{
/etc/init.d -> $(SEC_BIN) ;
/etc/rcS.d  -> $(SEC_BIN) ;
/etc/rc0.d  -> $(SEC_BIN) ;
/etc/rc1.d  -> $(SEC_BIN) ;
/etc/rc2.d  -> $(SEC_BIN) ;
/etc/rc3.d  -> $(SEC_BIN) ;
/etc/rc4.d  -> $(SEC_BIN) ;
/etc/rc5.d  -> $(SEC_BIN) ;
/etc/rc6.d  -> $(SEC_BIN) ;
/etc/systemd-> $(SEC_BIN) ;
}
(
  rulename = "Root file-system executables",
  severity = $(SIG_HI)
)
{
/bin-> $(SEC_BIN) ;
/sbin   -> $(SEC_BIN) ;
}
(
  rulename = "Root file-system libraries",
  severity = $(SIG_HI)
)
{
/lib-> $(SEC_BIN) ;
}
(
  rulename = "Security 

Bug#994899: xen-hypervisor-4.14-amd64 breaks system poweroff on bullseye

[Chuck Zmudzinski]

Package: xen-hypervisor-4.14-amd64
Version: 4.14.3-1~deb11u1
Severity: important
Tags: patch newcomer upstream

Dear Maintainer,

This bug is related to #991976, reported by Elliott Mitchell,
who happens to be the person who requested the patches
that are causing this bug. I understand he is a Debian Xen
developer.

Since I am not a developer, I only tagged this bug
important, but if I were a developer, I would tag it
serious and implement a fix that does what I will
propose below.

I hereby humbly request that you elevate this bug to
serious, since it is entirely wrong to release software
that causes a modern workstation/server to not power down
properly and renders it unable to be managed remotely,
which is what this bug does. A bug like this is
normal on an unstable or testing distribution, but
unacceptable/serious on the current stable release.

I refer you here for my first description of the problem
to the Debian Bug System:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991967#34

I also point out that another Debian user confirmed the
bug on bullseye:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991967#54

Elliott is of the opinion that what I am seeing is a
bug distinct from #991976. I am inclined to agree, as I
have not been able to reproduce it the way he describes
it, although the symptoms he sees are very similar.
That is why I am submitting a new report.

I can drill down the cause of this bug in the stable
version of debian to the Debian Xen Team's decision to
include a series of nine commits from upstream in order
to improve Raspberry Pi 4 support in version
4.14.0+88-g1d1d1f5391-1. So the bug was introduced in
the Debian Xen unstable/testing package on 15 Dec 2020
according to the changelog.

I understand the original reporter of #991976 wants to
keep these patches in the stable version of Xen to
better support the Raspberry Pi 4, and that he is
a Debian Xen developer. But I will strenuously and
respectfully disagree with any decision by the Debian
Xen Team to not apply a very reasonable compromise
solution.

Over on #991967, I argued passionately for removing
the nine Raspberry Pi 4 patches from the stable Xen
version because, and it is still my opinion that
experiments with patches from unstable upstream
branches is not appropriate for a package in a
stable version. That is why I would expect the
release team to tag this bug as serious even if
the Debian Xen Team refuses to tag it as serious.

Nevertheless, I propose the following compromise:

Simply ship a package for the stable version that
omits the nine Raspberry Pi 4 patches from unstable
upstream while building for the amd64|i386
architectures. I was able to implement such a fix
even though I am not an official developer in
just a few hours. It is really a trivial fix,
all I did was add a rule in debian/rules to use
quilt to disable the nine patches on amd64|i386.
I made it easy by moving the nine RP4 patches
from debian/patches to debian/patches/rpi4
and so could I use sed s/rpi4/#rpi4/ debian/series
to disable the patches for the amd64|i386 case.

I am sure there are other ways to implement the
fix, and it really is trivial, it would fix
this bug and still allow for the Raspberry Pi 4
patches to be included where they are needed
which I believe is in the arm64 architecture.

I also tested the current unstable branch from
Xen upstream, which is xen-c76cfad, which
unstable calls Xen-4.16-unstable. I tested
the current bullseye kernel as a dom0 on that
upstream Xen-4.16 hypervisor and did not
see the bug, so this most definetely is
NOT an upstream bug. It is a Debian Xen
packaging bug. I expect that perhaps some
commits on the Xen-4.16 upstream branch
that are missing on the Xen-4.14 branch might
also fix this bug, but until such a solution
is found, I suggest the aforementioned solution
as a workaround. The reason I tagged this bug
as upstream is that I think it would be
adviseable to make upstream aware that our
current xen-4.14 package is not really a
true Xen-4.14 but one with some patches from
Xen-unstable that are causing this bug, and
perhaps they can help eventually find the best
solution for their Xen-4.14 stable branch.

Finally, I tag the bug newcomer simply because
there is a known solution but the Debian Xen
package maintainer seems to want the Debian
Kernel Team to find a way to fix the bug
in the Linux kernel, as evidenced by the
recent discussion over at #991976, instead
of implementing the fix in the Xen hypervisor
as proposed here.

Regards,

Chuck Zmudzinski


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


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

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


-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (500, 

Bug#994846: Toot cuts off last char of last line

[SDA]

It works fine if one remembers to put a blank line after the last line. Not 
sure one should be expected to do that.

Bug#994877: Bug 994877 Network-Manager install status

[Hal Meyers]

Hello Andreas,

Thank you for replying to the bug and the work you do. Since you asked
a larger question to debian-desktop list, I wasn't exactly sure how to
repsond

For your information I did a quick check and found that network-manager
was installed before dokuwiki. I can state this because dokuwiki is
that last software I've tried to install. This is a fresh install of
Debian on a workstation laptop. The desktop is KDE Plasma was installed
through the  Debian task. 

$ aptitude show network-manager
Package: network-manager 
Version: 1.30.6-1
State: installed
Automatically installed: yes
Priority: optional
Section: net

Bug#994883: iptables-netflow-dkms: Kernel module fails to build for linux-image-5.14.0-1-amd64

[Axel Beckert]

Control: tag -1 + pending

Hi Salvatore,

Salvatore Bonaccorso wrote:
> > Might be an upstream issue. Will dig deeper later.
> 
> Upstream commit
> https://github.com/aabc/ipt-netflow/commit/66e4304101010108892376866334ec9317b427d8
> should address this issue. Linux upstream 5.14-rc1 had e3ae2365efc1
> ("net: sock: introduce sk_error_report").

Nice, thanks!

And indeed, cherry-picking that commit fixes the issue.

An upload with the fix is imminent.

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

Bug#994908: ITP: golang-github-containerd-stargz-snapshotter -- Fast container image distribution plugin with lazy pulling

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-containerd-stargz-snapshotter
  Version : 0.8.0-1
  Upstream Author : containerd
* URL : https://github.com/containerd/stargz-snapshotter
* License : Apache-2.0
  Programming Lang: Go
  Description : Fast container image distribution plugin with lazy pulling

 Pulling image is one of the time-consuming steps in the
 container lifecycle. Stargz Snapshotter is an
 implementation of snapshotter which aims to solve this problem by lazy
 pulling.  Lazy pulling here means a container can run without waiting
 for the pull completion of the image and necessary chunks of the image
 are fetched on-demand.
 .
 eStargz is a lazily-pullable image format proposed by this project.  This is
 compatible to OCI images so this can be pushed to standard container
 registries (e.g. ghcr.io) as well as this is still runnable even on
 eStargz-agnostic runtimes including Docker.  eStargz format is based on stargz
 image format by CRFS but comes with additional features like runtime
 optimization and content verification.

This package is a new dependency of podman (via the containers/storage_v1.36.0)

I plan to maintain this under the pkg-golang unmbrella.

Bug#994907: bullseye-pu: package proftpd-dfsg/1.3.7a+dfsg-12+deb11u2

[Hilmar Preusse]

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

[ Reason ]
During development of proftp 1.3.7 a few regressions were introduced, which
were not present in v1.3.6. This upload tries to address at least a few of
them.

[ Impact ]
For #993173 we have tag "security", hence it has to be solved. All other
should be fixed too, to eliminate regression introduced in 1.3.7.

[ Tests ]
For #993173 I got the response that the patch solves the issue.

[ Risks ]
All patches were provided (and tested) by upstream author.

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable

Debdiff is here [1]

Sorry for the deb11u1-deb11u2 confusion. When uploading deb11u1 I simply
missed a patched, which was already present on the salsa repository. Hence I
decided to do another upload to get all patches.

  [X] the issue is verified as fixed in unstable

All patches are contained in unstable in version 1.3.7c (or earlier)
although [2] reports they are not.

[1] 
https://release.debian.org/proposed-updates/bullseye_diffs/proftpd-dfsg_1.3.7a+dfsg-12+deb11u2.debdiff
[2] https://release.debian.org/proposed-updates/stable.html


signature.asc
Description: PGP signature

Bug#994906: FTBFS: missing plugins due to bug in libdrm-dev

[Lisandro Damián Nicanor Pérez Meyer]

Source: qtbase-opensource-src
Version: 5.15.2+dfsg-10
Severity: serious
Justification: Fails to build from source
X-Debbugs-Cc: lisan...@debian.org

This package is currently failing to build from source due to two
things:

- A change in libglvnd (or a compiler change that triggers this
  failure). This is already fixed on the repo.
- A bug in libdrm-dev https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994873
  which prevents some plugins from being built.

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

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

Bug#994905: override: systemd-timesyncd:admin/standard

[Michael Biebl]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: override
X-Debbugs-Cc: debian-b...@lists.debian.org, 
pkg-systemd-maintain...@lists.alioth.debian.org, debian-rele...@lists.debian.org

Hi FTP team,

I just uploaded systemd 247.9-2 to fix #986651 [0] and #993947 [1]
In this upload, I demoted systemd-timesyncd from a Depends to
Recommends. As discussed in the above bug report, to ensure that
systemd-timesycnd is still installed in a default d-i based
installation (including the standard task), I'd like to see the priority
of systemd-timesyncd bumped accordingly.

This is similar to what's has been done to libpam-systemd in [2]

I'd like to make this change for both unstable/testing and stable. I've
CCed the debian-release mailing list accordingly for their input.


Regards,
Michael

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986651
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993947
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803184

Bug#994903: remove-on-upgrade breaks packages replacing conffiles by non-conffile

[Christoph Berg]

Package: dpkg
Version: 1.20.9
Severity: normal
X-Debbugs-Cc: Niels Thykier 

Hi,

the new remove-on-upgrade logic from #822462 breaks the use-case of
replacing a conffile by a non-conffile version.

In postgresql-common, I'm trying to remove
/etc/apt/apt.conf.d/01autoremove-postgresql as a conffile, while still
generating that file from the package postinst. That worked[*] since
debian/postgresql-common.maintscript knows in which previous package
versions to trigger the logic, and the logic fires only once.

The same workflow happens for everyone moving from conffile to ucf.

The new logic does not know on which previous package versions to
trigger, and triggers always instead, and worse, it even triggers if
the file is no longer a conffile, but has been properly regenerated.
That means, on each package installation, I'm seeing this:

Setting up postgresql-common (229) ...
Obsolete conffile '/etc/apt/apt.conf.d/01autoremove-postgresql' has been 
modified by you.
Saving as /etc/apt/apt.conf.d/01autoremove-postgresql.dpkg-old ...

Is the answer here that I should keep the conffile flag around even if
the package isn't shipping the file anymore? Users tend to complain if
a file is in that state.

Christoph

[*] The full truth is there was a typo in
debian/postgresql-common.maintscript which made it remove apt's
/etc/apt/apt.conf.d/01autoremove instead. Oops.

Bug#994904: general: Wayland-Gnome-freeze in VMware when automatic ungrab while scrolling

[Volker Jung]

Package: general
Severity: normal
X-Debbugs-Cc: volker.j...@flexible-solutions.de

Dear Maintainer,

I installed Debian 11 in VMware Player 16.1.2 build-17966106 running on Windows 
10. Most things are fine, tools are automatically
installed. While working I discovered random freezes of the gnome session. 
After a while I noticed three cases when this happens.
Whenever gnome seems to be interested in mouse movement like when interacting 
with scrollbars or menus or when double clicking a
file in nautilus which leads to creation of new window the session will freeze 
if the mouse leaves the VM. With scrollbars this can
easily be reproduced especially while using Firefox.

My temporary solution is prohibiting the automatic ungrab operation which leads 
to a stable non freezing system. But of course that's
not a good solution for all time.

Please find out how this occurs and how it can be fixed. I guess it has 
something to do with a collapsing mouse communication which
seems to affect communication with other parts of gnome. Sometimes the freeze 
starts with the mouse action and then runs over more
steps. You can click other parts of the UI, activate other Windows but this 
gets worse fast and some seconds later you have a full
freeze.

Thanks in advance and kind regards.

Volker Jung

Bug#884575: ITP: syncthingtray -- a tray applet, plasmoid, and Dolphin integration for Syncthing

[Hannah Rittich]

Hey Nicholas,

nice to hear that you are still interested.

I have read this BTS entry, as well as the related GitHub issue [1].
Indeed, libc++utilities and libqtutilities are quite generic names. I
think, there are three ways to deal with this.

1.  Rename the libraries. Build a package for each one.
2.  Build a syncthingtray package that includes the libraries and
installs them to `/usr/lib/$ARCH/syncthingtray`. This would make use
of the multiple tarball support.
3.  Acceptance. Keep the names as they are. Build a package for each
one.

The three approaches have pros and cons.

1.  + More specific package name.
- More work: requires changing the build process and changes to
  upstream might be necessary.
- Increases long term maintenance cost, since higher complexity
  increases the chance of errors.
- Can break on updates, if upstream does not want to include the
  changes.

2.  + A hypothetical name collision is avoided.
o Probably less work than 1.
- Additional work: requires a more complicated build process.
- Increases long term maintenance cost, since higher complexity
  increases the chance of errors.
- Libraries cannot be used by other packages. (The author has other
  applications that might be of interest. They use the same
  libraries.)

3.  + Much simpler than 1. and 2.
+ Debian package is very close to the upstream package.
+ Low maintenance cost and more stable build process.
- A hypothetical name collision can occur.

I, would suggest option 3. A name collision, at this point, is just
hypothetical, while the drawbacks of the other options are real.

I have checked the package database and there is currently no name
collision with these package names, and the Debian Policy
Manual just requires a name to be unique in Debian [2], which they are.

Furthermore, the chance of a name collision is rather small. Yes,
libc++utilities is a rather generic name. However, for the same reason
you are concerned about the name, most people will not consider to use
such a generic name for a project; it is actually a bold move to choose
such a name. In case a more important package needs this name, however,
the packages can still be renamed. Hence, I do not see a reason to
significantly increase the effort of packaging when there is no concrete
reason to do so at the moment. There is the saying "done is better than
perfect."

If you insist, one could add a section to the README.Debian file that
the package will be renamed in case the name is needed by a more
important package.

In any case, I have taken the liberty to create an MVP (minimum viable
packaging) for Syncthing Tray and the required libraries [3], which can
be improved upon.

What are your thoughts?

Regards,

Hannah

[1]: https://github.com/Martchus/cpp-utilities/issues/16

[2]:
https://www.debian.org/doc/debian-policy/ch-binary.html#the-package-name

[3]: https://salsa.debian.org/rittich/packaging-syncthingtray

Bug#941199: Upstream has valid debian packaging

[Ian Donnelly]

What happened to this? What exactly is the bottleneck and is there any room to 
help get this over the line?

Considering Windows 11 VMs pretty much require TPM and this is necessary for 
that through libvirt I think it's something that should we should try to get in 
the repo before the Windows 11 launch.

For the record I was able to install Nick's packages and functionality is 
working as expected on sid.

Thanks,
Ian

Bug#994902: "missing-dep-for-interpreter make" should not trigger on "make:any"

[Christoph Berg]

Package: lintian
Version: 2.106.1
Severity: normal

Hi,

 Package: postgresql-server-dev-all
 Source: postgresql-common
 Version: 229
 Architecture: amd64
 Depends: make:any, postgresql-common (= 229), postgresql-server-dev-13

Yet lintian is complaining:

E: postgresql-server-dev-all: missing-dep-for-interpreter make => make | 
build-essential | dpkg-dev 
(usr/share/postgresql-common/dh_make_pgxs/debian/rules) /usr/bin/make

Christoph

Bug#994702: ipfm: Missing working homepage link

[Robert Chéramy]

Hi,

as the main author of ipfm, i can give following information:
- there is no homepage for ipfm anymore
- ipfm has not been developed for about 20 years and I do not plan to 
change something at this


I can't retain to share my memories...
We developed ipfm in order to get statistics about the Internet Usage of 
our student campus which was attached to Renater and The Internet 
through the Ecole Centrale Paris. This was a 45 Mbit/s link and every 
student had is own, public IP-Address on his PC in his room. We managed 
the whole Campus Network and IT within the student assiociation VIA 
Centale Reseaux an played with LAN Emulation (ATM), 3com and of course 
developed VideoLAN. This was a really great time!


Today, one would use netflow and a netflow collector in order to produce 
these stats and much more.


The time may have come to remove ipfm from debian. The decision is by 
sam, he is the maintainer of the package. Or is someone still using ipfm 
out there? Popcon says 13 votes.


Cheers,

tibob



On 19.09.21 18:27, Petter Reinholdtsen wrote:

Package: ipfm
Version: 0.11.4-4.2

The package lack homepage information in d/control, and the homepage
link in d/copyright do no longer work.

Where is its current upstream?

Note, the package could use a maintainer upload to refresh its packaging
and acknoledge the last two NMUs.

Bug#988593: foot: A new version of foot is available

[Jonas Smedegaard]

Package: foot
Version: 1.6.4-1
Followup-For: Bug #988593

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Changing the watch file to the following makes uscan work again,
and should work for fcft package too (which seems to suffer similarly):

version=4
opts=\
searchmode=plain,\
filenamemangle=s/.+\/(@ANY_VERSION@@ARCHIVE_EXT@)/@PACKAGE@-types-$1 \
https://codeberg.org/dnkl/foot/releases 
/dnkl/@PACKAGE@/archive/@ANY_VERSION@@ARCHIVE_EXT@


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmFLm8QACgkQLHwxRsGg
ASHzLw/+J3/Hhasvog+pQjG8t8YDYDCjCyFdTBj1vJNZ7eThW1uYi5WOSZs4I4mV
vUCEc7oXd7P65se0oq/1eBqGNsNW6lutLIe+0R9KVqAn9V9Lxw2mYSTzuV1AdD+T
jzFCBepZn6kPh/IwckXZQxUP0sLPvglHhhXhD6wh2C7nbIrMYWjt/pQiKyPe87rz
Mt486DK37s9Anw4X4NGTZDgXIWrPL0MeepyyGWodPpO47CncuyH2muoRuuSeHPiA
nbC5XsIYhK/JzhpB36HCwv+PHP5+qMG3SmAEJDBCd2AVcZIWij3wBwMZWWSmf0X5
yKAmZCh/xYVzKV+gRVIzayWEk3r7kCaugfkpC3QG7UGyHU5+3lAdE3RK6lnHdiyu
1rNbkWD/RrATwIgrtspp1O+dxPtlcbiNAb42fT1OB09gT3SrvIkWC1rW9AN/uPvu
LS0ZsUal8Wi2SF1LCDIx+dMQewBpQy2jCcX//7qPOlYysZlui24owqq2oFDEv1Qn
H8Ltv9zivaX87s61fJU/q+YiYkaDJ7JXTMWEg25mnSg1ieo7eNmnRzfjcJx5yJmE
bxhGn3R+xnz9DjIC0uL+sV8b7pZDFhzRq2YuA3LBSdR2nj7QSSmBUoQwdxPiNqyE
PHa3XaxpiRTc+SfAuRDDn2bQ/cFYlXig4Wux1Rt/jZzgnkc2IpA=
=6ZL1
-END PGP SIGNATURE-

Bug#762353: libaqbanking-data: Missing sentence to translate #762353

[Martin Preuss]

Hi Micha,

Am 22.09.21 um 21:52 schrieb Micha Lenk:
[...]
> On Fri, 26 Feb 2016 12:15:28 +0100 mechtilde  wrote:
>> As I can see the package libchipcard didn't contain any translated oder
>> translatable strings.
>>
>> I guess I strumble over one of the following lines.
>>
>> src/ct/ddvcard/ddvcard.c    161  I18N("Abort"),
[...]
> Now, most of the I18N symbols seem to be #define'd to GWEN_I18N_Translate(). 
> I have to admit that I am lost at this point. Would you mind to help us to 
> understand how the translations for these lines of code are supposed to work?
[...]

Actually, it isn't supposed to work at all, because until a few minutes ago 
there was no translation setup code.
I just added something in that regard to Libchipcard's GIT repository, but we 
still need to add I18N stuff to the toplevel Makefile.am to generate message 
catalogs etc.

Until then the I18N environment in Libchipcard is incomplete and thus not 
available ATM.


Regards
Martin

-- 
"Things are only impossible until they're not."

Bug#994121: debian-cd: Default CODENAME should be changed to bookworm (testing)

[Steve McIntyre]

Hi Daniel!

On Sun, Sep 12, 2021 at 04:40:00AM -0500, Daniel Lewart wrote:
>Source: debian-cd
>Version: 3.1.35
>Severity: normal
>Tags: patch
>X-Debbugs-Cc: szilard.an...@gmail.com
>
>Debian CD Group,
>
>The default CODENAME should be changed to bookworm (testing).
>
>Below is a patch, which I successfully tested with:
>$ ./easy-build.sh NETINST
>
>Thank you!
>Daniel Lewart
>Urbana, Illinois

Thanks for the patches. (Mostly) applied, but please don't make
unrelated changes when you send patches. In this case, I've *not*
changed the CONTRIB setting.

>---
>diff -ru a/CONF.sh b/CONF.sh
>--- a/CONF.sh  2021-09-06 05:22:44.0 -0500
>+++ b/CONF.sh  2021-09-12 00:00:00.0 -0500
>@@ -70,7 +70,7 @@
>   export DI_CODENAME=$CODENAME
> fi
> # If you want backported d-i (e.g. by setting
>-# DI_CODENAME=jessie-backports, then you'll almost definitely also
>+# DI_CODENAME=bookworm-backports, then you'll almost definitely also
> # want to enable BACKPORTS below as well
> 
> # Should we include some packages from backports? If so, point at a
>@@ -86,8 +86,8 @@
> # the Debian mirror.
> #export DI_WWW_HOME=default
> 
>-# Version number, "2.2 r0", "2.2 r1" etc.
>-export DEBVERSION="11.0.0"
>+# Version number, "10.11.0", "11.1.0", "testing", etc
>+export DEBVERSION="testing"
> 
> # Official or non-official set.
> # NOTE: THE "OFFICIAL" DESIGNATION IS ONLY ALLOWED FOR IMAGES AVAILABLE
>@@ -136,7 +136,7 @@
> # export NONFREE=1
> 
> # Do I want to have CONTRIB merged in the CD set
>-export CONTRIB=1
>+# export CONTRIB=1
> 
> # Do I want to have NONFREE on a separate CD (the last CD of the CD set)
> # WARNING: Don't use NONFREE and EXTRANONFREE at the same time !
>@@ -208,8 +208,8 @@
> 
> # Extra keys that you might want apt to trust. List their fingerprints
> # here and debian-cd will grab them from the user's keyring as needed
>-# (The example here is the buster release key)
>-#export ARCHIVE_EXTRA_KEYS="80D15823B7FD1561F9F7BCDDDC30D7C23CBBABEE"
>+# (The example here is the bullseye release key)
>+#export ARCHIVE_EXTRA_KEYS="1F89983E0081FDE018F3CC9673A4F27B8DD47936"
> 
> # By default we use debootstrap --no-check-gpg to find out the minimal set
> # of packages because there's no reason to not trust the local mirror. But
>diff -ru a/easy-build.sh b/easy-build.sh
>--- a/easy-build.sh2021-09-06 05:22:44.0 -0500
>+++ b/easy-build.sh2021-09-12 00:00:00.0 -0500
>@@ -72,10 +72,10 @@
> ## For what release to build images
> 
> # The suite the installed system will be based on
>-export CODENAME=buster
>+export CODENAME=bookworm
> # The suite from which the udebs for the installer will be taken (normally
> # the same as CODENAME)
>-export DI_CODENAME=buster
>+export DI_CODENAME=bookworm
> 
> 
> ## The debian-installer images to use. This must match the suite (DI_CODENAME)
>###
>
>

On Sun, Sep 12, 2021 at 04:51:05AM -0500, Daniel Lewart wrote:
>Makefile patch is attached.  Dan

>--- a/Makefile 2021-09-06 05:22:44.0 -0500
>+++ b/Makefile 2021-09-12 00:00:00.0 -0500
>@@ -191,14 +191,14 @@
>   fi
> endif
> 
>-# Make sure unstable/sid points to testing/buster, as there is no build
>+# Make sure unstable/sid points to testing/bookworm, as there is no build
> # rule for unstable/sid.
> unstable-map:
>   $(Q)if [ ! -d $(BASEDIR)/data/sid ] ; then \
>-  ln -s buster $(BASEDIR)/data/sid ; \
>+  ln -s bookworm $(BASEDIR)/data/sid ; \
>   fi
>   $(Q)if [ ! -d $(BASEDIR)/tools/boot/sid ] ; then \
>-  ln -s buster $(BASEDIR)/tools/boot/sid ; \
>+  ln -s bookworm $(BASEDIR)/tools/boot/sid ; \
>   fi
> 
> #


-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...

Bug#984858: python-numpy-doc: numpy doc search results broken by appending "undefined"

[Cédric Hannotier]

On Tue, 09 Mar 2021 10:15:52 +0100 Drew Parsons  wrote:
> The local numpy docs at /usr/share/doc/python-numpy-doc/html/index.html
> provide a search window.  Search does work, but the result links are
> borken.
> 
> For instance, search for norm, finds 76 pages of results, the first
> being "numpy.linalg.norm (Python function, in numpy.linalg.norm)"
> The url link for this result is 
> file:///usr/share/doc/python-numpy-doc/html/reference/generated/numpy.linalg.normundefined?highlight=norm#numpy.linalg.norm
> 
> The "undefined" suffix at the end of the filepath of course means the
> link does not work. The actual file is
> file:///usr/share/doc/python-numpy-doc/html/reference/generated/numpy.linalg.norm.html
> 
> The tags on the search url do work if applied to the correct filepath, as in
> file:///usr/share/doc/python-numpy-doc/html/reference/generated/numpy.linalg.norm.html?highlight=norm
> 
> Something in the search engine is replacing '.html' with 'undefined'.

It is because the sphinx builder seems to do something wrong
when building the search.html file...

DIR=/usr/share/doc/python-numpy-doc/html

in $DIR/_static/searchtools.js line 268,
the script generates links using this:
```
linkUrl = item[0] + DOCUMENTATION_OPTIONS.LINK_SUFFIX;
```

The issue is that, somehow,
the `DOCUMENTATION_OPTIONS` is defined in $DIR/search.html,
and does not contain a `LINK_SUFFIX` parameter (-> undefined).

>From numpy doc website, they use this instead:
```

```

Dirty workaround is to comment the definition of
`DOCUMENTATION_OPTIONS` in search.html and add this line,
or add `LINK_SUFFIX: '.html'` to its definition.

Sadly, I do not have any knowledge on Sphinx build to properly fix it.

Regards
-- 

Cédric Hannotier

Bug#903374: tracker : flaky autopkgtest: ERROR: tracker-monitor-test - Bail out!

[Paul Gevers]

Control: retitle -1 tracker: autopkgtest regressed in September 2021
Control: severity -1 serious

Hi
On Mon, 9 Jul 2018 10:18:24 +0200 Paul Gevers  wrote:
> While inspecting regressions in autopkgtest results¹, I noticed that
> your package failed multiple times² without apparent changes and passed
> later again. Most (recent) cases had the error that I copied below, but
> there were others as well. The last regression was involved in delaying
> the migration of glibc.
> 
> Could you please investigate and make your autopkgtest more robust?
> Please contact me if you need help and you think I can provide that (I
> am not subscribed to this bug). Note that we recently added the "flaky"
> restriction to autopkgtest. If you can't really fix the test, but still
> want it run, you can mark it as not suitable for gating.
> 
> Recent discussion of gating migration by autopkgtests on debian-devel³
> noted that if this is going to work, and in particular if we are going
> to *block* migration when it causes autopkgtest regressions rather than
> merely delaying it, intermittent autopkgtest failures are likely to have
> to be considered RC due to their impact on the tested package's
> dependencies; for now I've filed it as important.

Since the beginning of September 2021, the autopkgtest of tracker
started to fail consistently.

Can you please look into this?

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#994901: postfwd: Systemd .service file missing for postfwd

[Jakub Filo]

Package: postfwd
Version: 1.35-6
Severity: important
X-Debbugs-Cc: plantr...@plantroon.com

Dear Maintainer,

   * What led up to the situation?
   Upgrading to Bullseye, the /lib/systemd/system/postfwd.service file
   is no longer available and therefore the service does not start - the
   upgrade effectively broke a working package
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   I use the .service file from Buster in the meantime, copied it to my
   /etc/systemd/system directory.
   * What was the outcome of this action?
   It works now.
   * What outcome did you expect instead?
   The package should provide the .service file that it once did.

   As a note, listing files on packages.debian.org leads to an error,
   see:
   https://packages.debian.org/bullseye/all/postfwd/filelist

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

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

Versions of packages postfwd depends on:
ii  adduser 3.118
ii  libnet-dns-perl 1.29-1
ii  libnet-server-perl  2.009-2
ii  lsb-base11.1.0
ii  perl5.32.1-4+deb11u1

postfwd recommends no packages.

postfwd suggests no packages.

-- no debconf information

Bug#994889: RM: python-dipy -- NBS; dipy does not produce python2 packages anymore

[Étienne Mollier]

Package: ftp.debian.org
Severity: normal

Hello Ftp,

the source package dipy does not produce the python-dipy binary
package anymore, since this is python2 specific.  The current
replacement is python3-dipy 1.4.1-1, but the old python-dipy
0.14.0-1 seems still around in sid.

This also affects various versions of the binary package
python-dipy-lib, depending on whether we are on s390x (version
0.13.0-2), or any other architecture (0.14.0-1).

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/3, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#994900: git-filter-repo: git Build-Depends missing version epoch

[David (Plasma) Paul]

Source: git-filter-repo
Version: 2.33.0-1
Severity: important
Tags: patch

Dear Maintainer,

In the list of Build-Depends for git-filter-repo, the version
requirement for git is listed as ">= 2.22". Because the git package's
version number contains an epoch[1], the version requirement in the
control file should be rewritten as ">= 1:2.22". Otherwise, as written,
the current version requirement is satisfiable by literally every
version of the git package that has ever been in Debian.

[1] 
https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_What_are_version_epochs_and_why_and_when_are_they_needed.3F

-- 
Plasma
diff --git a/debian/control b/debian/control
index fecdb1e..2c0ba21 100644
--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,7 @@ Build-Depends:
  dh-python,
  docbook-xsl,
  dos2unix,
- git (>= 2.22),
+ git (>= 1:2.22),
  python3,
  python3-setuptools,
  python3-setuptools-scm,

Bug#994848: xterm: "xterm -e command" should return the exit code of "command"

[Axel Beckert]

Hi Sven,

Sven Joachim wrote:
> > for test suites of tools which manipulate terminals, it would be nice if
> > "xterm -e command" would return the exit code of "command", e.g.
> >
> >   $ xterm -e false
> >
> > should exit with return code 1, but actually does exit with return code 0.
> 
> That would certainly be useful for automatic tests, but seems to clash
> with xterm's current use of error return codes when it itself encounters
> a fatal problem.

Indeed. Maybe a new option is then the better way to go here. My
suggestion would be "-E" similar how Perl' -e and -E work. They do the
same, but -E does more.

> All the terminal emulators on my system behave the same way as xterm and
> happily exit 0, even when the command specified in the -e option cannot
> be found.

For my current use case I used the following workaround to transport
output and exit code:

  override_dh_auto_test:
xvfb-run xterm -e '( dh_auto_test ; echo $$? ) | tee 
debian/xterm_dh_auto_test.log'
cat debian/xterm_dh_auto_test.log
sh -c 'exit $$(tail -1 debian/xterm_dh_auto_test.log)'

Quite hackish, but seems to work so far. (Double dollar sign due to
being Makefile syntax.)

Only downside so far: I can't capture STDERR because as soon as I add
"2>&1", xtermcontrol argues it can't find the controlling terminal
anymore. But that might be an xtermcontrol issue.

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

Bug#762353: libaqbanking-data: Missing sentence to translate #762353

[Micha Lenk]

Hi Martin,

the Debian Bug #762353[0] is sitting in the bug tracker for way too long 
time already, so I poked a while whether I can find a resolution.


[0.] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762353

On Fri, 26 Feb 2016 12:15:28 +0100 mechtilde  wrote:

As I can see the package libchipcard didn't contain any translated oder
translatable strings.

I guess I strumble over one of the following lines.

src/ct/ddvcard/ddvcard.c161  I18N("Abort"),
src/ct/starcoscard/starcoscard.c161  I18N("Abort"),
src/ct/zkacard/zkacard.c161  I18N("Abort"),

I'm not familiar with C-Code to prefer the files for translation.
I can do the translation itself to German.


If I looked correctly, these lines are in current libchipcard's 'master' 
branch on lines 164 or 165, so most likely almost unchanged.


Now, most of the I18N symbols seem to be #define'd to 
GWEN_I18N_Translate(). I have to admit that I am lost at this point. 
Would you mind to help us to understand how the translations for these 
lines of code are supposed to work?


Thanks in advance,
Micha

Bug#994882: ITS: vitables

[Anton Gladky]

Hi Benda!

Thanks for your contribution. I have approved and merged your MR. Also I
have added you
to the Debian Science group on salsa.

@PICCA Frederic-Emmanuel ,
would you want also to check those changes?

Best regards

Anton


Am Mi., 22. Sept. 2021 um 16:18 Uhr schrieb Benda Xu :

> Package: vitables
> Version: 3.0.2-1
> Severity: normal
> X-Debbugs-Cc: Debian Science Maintainers <
> debian-science-maintain...@lists.alioth.debian.org>, Dmitrijs Ledkovs <
> dmitrij.led...@gmail.com>, Picca Frédéric-Emmanuel 
>
> Dear Maintainer,
>
> I am interested in co-maintaining vitables by joining the science team
> and appending myself as an uploader.
>
> The newest version (3.0.0-1.1) was NMU-ed and has not been included in
> the package Vcs for more than a year. Bug 966056 (a year old) prevents
> the version in bullseye to function if python3-sip is not installed. I
> think the current uploads need help.
>
> I have contributed to the present 3.0.0-1 release in 2019 and I would
> like to support packaging vitables in the long run, as I am an active
> user of it and giving my lectures with it.
>
> The diff is in the merge request:
>
>   https://salsa.debian.org/science-team/vitables/-/merge_requests/4
>
> Thanks for your consideration!
> Benda
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers stable
>   APT policy: (990, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-5-amd64 (SMP w/8 CPU threads)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
> set to en_US.UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /bin/dash
> Init: OpenRC (via /run/openrc), PID 1: init
>
> Versions of packages vitables depends on:
> ii  python3  3.9.2-2
> ii  python3-numexpr  2.7.2-2
> ii  python3-numpy1:1.19.5-1
> ii  python3-qtpy 1.9.0-3
> ii  python3-tables   3.6.1-3
>
> vitables recommends no packages.
>
> vitables suggests no packages.
>
> -- no debconf information
> --
> debian-science-maintainers mailing list
> debian-science-maintain...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
>

Bug#994848: xterm: "xterm -e command" should return the exit code of "command"

[Sven Joachim]

On 2021-09-21 22:52 +0200, Axel Beckert wrote:

> Package: xterm
> Version: 368-2
> Severity: wishlist
> Tags: upstream
>
> Hi,
>
> for test suites of tools which manipulate terminals, it would be nice if
> "xterm -e command" would return the exit code of "command", e.g.
>
>   $ xterm -e false
>
> should exit with return code 1, but actually does exit with return code 0.

That would certainly be useful for automatic tests, but seems to clash
with xterm's current use of error return codes when it itself encounters
a fatal problem.  See the "ERROR MESSAGES" section in the manpage.

All the terminal emulators on my system behave the same way as xterm and
happily exit 0, even when the command specified in the -e option cannot
be found.

Cheers,
   Sven

Bug#994898: package gcc-7-doc incorrectly displayed on tracker.debian.org

[Dmitry Baryshkov]

Package: tracker.debian.org
Severity: normal


The package gcc-7-doc is displayed on tracker.d.o as present in testing
distribution. Package news (correctly) show that the package was removed
from unstable, but miss the note that the package was removed from
testing. Correpondingly package is still displayed as present in testing
distribution. Could you please correct that?

-- 
With best wishes
Dmitry

Bug#994894: gpm FTBFS with texinfo >= 6.8

[Sven Joachim]

Control: reassign -1 texinfo 6.8-2
Control: forwarded -1 
https://lists.gnu.org/archive/html/bug-texinfo/2021-09/msg00011.html

Am 22.09.2021 um 20:25 schrieb Helmut Grohne:

> Source: gpm
> Version: 1.20.7-9
> Severity: serious
> Tags: ftbfs
> X-Debbugs-Cc: debian-tex-ma...@lists.debian.org
>
> gpm fails to build from source in unstable on amd64. A build ends as
> follows:
>
> | if [ "/usr/bin/makeinfo" != "no" ]; then /usr/bin/makeinfo
> | --no-split /<>/doc/gpm.texinfo -o
> | /<>/doc/gpm.info; fi
> | touch gpm.man
> | gpm.texinfo:32: warning: undefined flag: version
> | gpm.texinfo:84: warning: multiple @setchapternewpage
> | gpm.texinfo:89: warning: @subtitle missing argument
> | gpm.texinfo:94: warning: multiple @setchapternewpage
> | gpm.texinfo:95: bad argument to @headings: single
> | make[3]: *** [Makefile:53: /<>/doc/gpm.info] Error 1
> | rm /<>/doc/gpm.texinfo
> | make[3]: Leaving directory '/<>/doc'
> | make[2]: *** [Makefile:77: do-all] Error 1
> | make[2]: Leaving directory '/<>'
> | dh_auto_build: error: make -j8 returned exit code 2
> | make[1]: *** [debian/rules:20: override_dh_auto_build] Error 25
> | make[1]: Leaving directory '/<>'
> | make: *** [debian/rules:8: binary] Error 2
> | dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
> status 2
>
> Since it built a day earlier, the cause very likely is the texinfo
> upload. That totally leaves open the question where this needs fixing.

Seems it should be fixed in texinfo, an upstream patch can be found at
https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=13a8894fe2faa45b04033d7122a8fe7939ce6aa2.
I have not tested it, though.

Cheers,
   Sven

Bug#994897: security-tracker: turning text URL to link includes extraneous character

[Roberto C. Sanchez]

Package: security-tracker
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

It appears that when parsing data/CVE/list and a URL is encountered,
that extraneous characters can end up included in the link, which
can result in the actual link not reflecting the intended link.  For
example, https://security-tracker.debian.org/tracker/CVE-2020-13230
links to https://people.debian.org/~abhijith/upload/CVE-2020-13230.patch
but incorrectly includes the closing parenthsis that denotes the end of
the note text as part of the link.

Regards,

- -Roberto

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEz9ERzDttUsU/BH8iLNd4Xt2nsg8FAmFLhUgACgkQLNd4Xt2n
sg9qphAAi244W6/VseDDs09HA/s65C+ZkGoiTpg6h+BBaQcCU4qlaaxfwtl3IXBK
Ocj7YEAuOnsdSxl+R0WTyz0pbyaADxX2exI0BXZLqJ9Z5AnQ+BionvAl2HpU1Jho
eNJzID1ejWLJAsWGNr7+CWp8NZYSKRN7SxJlnII2nHDVm7g/F1WPyxZtHtXPdwJ5
0Qve7hbk4zQZ+L6sNJGRElmee9N3wxN7ajdQbEXMWw1V8MVg0yJjWKgkFH+kTeaZ
vU8uM3owPzCv9CNGp84Qf7X9MilGOgw5ZQpFAMi8ULZrvN0OyYl1N2P9ajk5bx4J
Mh7o22KchcBXIUgCzEAnPWhVN6cY5a1/qA/1xWDQii4rWUtw0kGvJjSP12WRWCef
/gFr9ba8NMsVKaiPuoaeZY4cPpcU9oLBHBxnqBP2cXSy1xJa2aHPgaQD+q9Gb5Zh
EWW2NXS6cRQcYBJJVBX+TZXoQBaBCA88kDesFVN21VZpYaJkudYxoP46GqRYNODw
Jc3ruP1WmjaEGOGfuBavd9qbKa67Ihn6DR3o/PCNMCps9sLnhvhEmtzQEuZHo8H+
zZxjcMI76vs+KWE2rR7/GJmOqtul0PW17lRHBzAFoiaIN+vK+OmH6Pv/u9Lbr8bn
7R8h07DFVZhSsG/Rhe2oPDbYhf2oT0UrcwQQCcjMUeXT+sR0gvk=
=BQe6
-END PGP SIGNATURE-

Bug#994870: [Pkg-xen-devel] Bug#994870: Memory allocation problem for VM after xen security update

[Hans van Kranenburg]

Hi Ruediger,

On 9/22/21 11:37 AM, H.-R. Oberhage wrote:
> Package: xen-system-amd64
> Version: 4.14.3-1~deb11u1
> 
> After applying the buster security update to xen, my VM won't start
> any longer, complaining about a memory allocation error.

Can you confirm that this is a virtual machine that tries to boot a
32-bit kernel as PV type?

The error message you are seeing is not particularly helpful, but it is
most likely related to this.

The fact that with this package update 32-bit PV guests fail to start is
indeed a regression problem, which is quite inconvenient for you, right now.

At this point I would really recommend to not wait for a fix to arrive
which makes it start again, but change your VM to use a 64-bit kernel.

Let me know if you need help or run into problems while making this change.

Running 32-bit PV at all is already 'on life support' upstream for quite
a while now, and it also not under security support any more.

In the long run, I'd suggest working towards having 64-bit guests in PVH
mode, since that's one of the best options we have these days.

If there's a reason you really cannot switch to a 64-bit kernel or move
the functionality of this virtual machine to a new fully 64 bit system,
switching the virtualization type from PV to HVM would also be an option.

> Switching back to the previous version 4.14.2+25-gb6a8c4f72d-2 lets
> the VM start (again,) normally.
> 
> /var/log/libvirt/libxl/libxl-driver.log:
> 2021-09-21 14:01:44.645+: xc: panic: xc_dom_boot.c:120: 
> xc_dom_boot_mem_init: can't allocate low memory for domain: Out of 
> memory
> 2021-09-21 14:01:44.653+: libxl: libxl_dom.c:593:libxl__build_dom: 
> xc_dom_boot_mem_init failed: Die Operation wird nicht unterstützt 
> [means: the operation is not supported]
> 2021-09-21 14:01:44.662+: libxl: 
> libxl_create.c:1576:domcreate_rebuild_done: Domain 1:cannot (re-)build 
> domain: -3
> 
> The error is triggered, regardless if there was a boot-parameter
> "dom0_mem=1024M:max=2048M" set or not.
> /etc/xen/xl.conf was unaltered, i.e. 'autoballoon' was implicitely set
> to "auto".
> 
> I am "on" Buster, kernel 5.10.0-8-amd64 (5.10.46-4), all relevant fixes
> included.

Apologies for the inconvenience,

Hans

Bug#994896: pyhst2: FTBFS due to missing B-D: python3-six

[Andreas Beckmann]

Source: pyhst2
Version: 2020c-1
Severity: serious
Tags: sid bookworm

Hi,

pyhst2 FTBFS in current sid when running the tests:

   dh_auto_test -O--buildsystem=pybuild
I: pybuild base:232: cd /build/pyhst2-2020c/.pybuild/cpython3_3.9_pyhst2/build; 
python3.9 -m unittest discover -v 
PyHST2_2020c.test (unittest.loader._FailedTest) ... ERROR

==
ERROR: PyHST2_2020c.test (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: PyHST2_2020c.test
Traceback (most recent call last):
  File 
"/build/pyhst2-2020c/.pybuild/cpython3_3.9_pyhst2/build/PyHST2_2020c/third_party/six.py",
 line 46, in 
from ._local.six import *  # noqa
ModuleNotFoundError: No module named 'PyHST2_2020c.third_party._local'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.9/unittest/loader.py", line 470, in _find_test_path
package = self._get_module_from_name(name)
  File "/usr/lib/python3.9/unittest/loader.py", line 377, in 
_get_module_from_name
__import__(name)
  File 
"/build/pyhst2-2020c/.pybuild/cpython3_3.9_pyhst2/build/PyHST2_2020c/test/__init__.py",
 line 44, in 
from . import utilstest
  File 
"/build/pyhst2-2020c/.pybuild/cpython3_3.9_pyhst2/build/PyHST2_2020c/test/utilstest.py",
 line 50, in 
from ..third_party import six
  File 
"/build/pyhst2-2020c/.pybuild/cpython3_3.9_pyhst2/build/PyHST2_2020c/third_party/six.py",
 line 49, in 
from six import *  # noqa
ModuleNotFoundError: No module named 'six'


--
Ran 1 test in 0.001s

FAILED (errors=1)
E: pybuild pybuild:353: test: plugin distutils failed with: exit code=1: cd 
/build/pyhst2-2020c/.pybuild/cpython3_3.9_pyhst2/build; python3.9 -m unittest 
discover -v 
dh_auto_test: error: pybuild --test -i python{version} -p 3.9 returned exit 
code 13
make: *** [debian/rules:11: build] Error 25


This looks like the package is missing an explicit
  Build-Depends: python3-six
as that package is no longer pulled in transitively.


Andreas

Bug#994770: RFS: binutils-m68hc1x/1:3 -- GNU binary utilities for Motorola's 68HC11/12 targets

[Vincent Smeets]

Thank you Adam for testing my package.

Can you send me the build log, so I can analyse the problem?

I have been building my package on my Debian/Testing machine without
problems. Are you using a different build environment? What is the minimum
required build environment (except for the build dependencies)?

Regards,
Vincent

Op wo 22 sep. 2021 om 14:57 schreef Adam Borowski :

> On Mon, Sep 20, 2021 at 07:16:30PM +0200, Vincent Smeets wrote:
> >  * Package name: binutils-m68hc1x
>
> > Changes since the last upload:
> >
> >  binutils-m68hc1x (1:3) unstable; urgency=medium
> >  .
> >* Repackaged as a native package based on binutils-source (Closes:
> #982848)
>
> Fails to build with:
>
> cd obj-x86_64-linux-gnu && ../src/configure
> --build=x86_64-linux-gnu --prefix=/usr --includedir=\${prefix}/include
> --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info
> --sysconfdir=/etc --localstatedir=/var --disable-option-checking
> --disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu
> --runstatedir=/run --disable-maintainer-mode --disable-dependency-tracking
> --target=m68hc11 --libdir=\${prefix}/lib/m68hc11 --with-bugurl=
> https://www.debian.org/Bugs/ --with-system-zlib
> --with-pkgversion=1:2.37\+3 --enable-deterministic-archives
> --enable-targets=m68hc11,m68hc12
> configure: error: unrecognized option: `--runstatedir=/run'
>
>
> Meow!
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ If you ponder doing what Jesus did, remember than flipping tables
> ⢿⡄⠘⠷⠚⠋⠀ and chasing people with a whip is a prime choice.
> ⠈⠳⣄
>

Bug#994895: atftpd: buffer overflow, CVE-2021-41054

[Andreas B. Mundt]

Package: atftpd
Version: 0.7.git20120829-3.2~deb10u1 0.7.git20120829-3.3
Severity: important
Tags: patch upstream
X-Debbugs-Cc: a...@debian.org

Hi,

this bug report tracks the fixes for CVE-2021-41054 in buster and bullseye.
Related links can be found in the security tracker:

https://security-tracker.debian.org/tracker/CVE-2021-41054

The upstream patch is here:
   

https://sourceforge.net/p/atftp/code/ci/d255bf90834fb45be52decf9bc0b4fb46c90f205/

Regards,

  Andi
   
 

Bug#775827: RFA: grok -- powerful pattern-matching and reacting tool

[Stig Sandbeck Mathisen]

This package is still up for adoption.  To take over, just do an upload with a
new Maintainer: field in debian/control and close this bug.

The packaging repository is at https://salsa.debian.org/debian/grok/

>>> Stig

Bug#994894: gpm FTBFS with texinfo >= 6.8

[Helmut Grohne]

Source: gpm
Version: 1.20.7-9
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: debian-tex-ma...@lists.debian.org

gpm fails to build from source in unstable on amd64. A build ends as
follows:

| if [ "/usr/bin/makeinfo" != "no" ]; then /usr/bin/makeinfo --no-split 
/<>/doc/gpm.texinfo -o /<>/doc/gpm.info; fi
| touch gpm.man
| gpm.texinfo:32: warning: undefined flag: version
| gpm.texinfo:84: warning: multiple @setchapternewpage
| gpm.texinfo:89: warning: @subtitle missing argument
| gpm.texinfo:94: warning: multiple @setchapternewpage
| gpm.texinfo:95: bad argument to @headings: single
| make[3]: *** [Makefile:53: /<>/doc/gpm.info] Error 1
| rm /<>/doc/gpm.texinfo
| make[3]: Leaving directory '/<>/doc'
| make[2]: *** [Makefile:77: do-all] Error 1
| make[2]: Leaving directory '/<>'
| dh_auto_build: error: make -j8 returned exit code 2
| make[1]: *** [debian/rules:20: override_dh_auto_build] Error 25
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:8: binary] Error 2
| dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2

Since it built a day earlier, the cause very likely is the texinfo
upload. That totally leaves open the question where this needs fixing.

Helmut

Bug#994893: ITP: ogre-next -- Ogre is a 3D graphics rendering engine (next generation)

[Jose Luis Rivero]

Package: wnpp
Severity: wishlist
Owner: Jose Luis Rivero 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: ogre-next
  Version : 2.2.5
  Upstream Author : https://github.com/OGRECave/ogre-next/blob/master/AUTHORS
* URL : https://github.com/OGRECave/ogre-next
* License : MIT
  Programming Lang: C++
  Description : Ogre is a 3D graphics rendering engine (next generation)

In Debian we already have Ogre-1.x in the form of ogre-1.9 and
ogre-1.10. The Ogre project was divided into Ogre and Ogre-next,
this last one hosts the old 2.x branches. Both are maintained and
developed and incompatible with each other.

For more details see:
https://www.ogre3d.org/about/what-version-to-choose

The idea is to have both projects in Debian since nowadays they are
totally independent from each other.

To maintain it in Debian, together with Manuel A. Fernandez Montecelo,
we created the ogre-team inside salsa some years ago.
https://salsa.debian.org/ogre-team

Bug#992917: grok: FTBFS due to RPC removal from glibc

[Adrian Bunk]

On Wed, Sep 22, 2021 at 08:22:04PM +0200, Stig Sandbeck Mathisen wrote:
> Adrian Bunk  writes:
> 
> > On Sat, Aug 28, 2021 at 09:43:36PM +0200, Stig Sandbeck Mathisen wrote:
> >> 
> >> Hello,
> >> 
> >> Thank you for the bug report and patch. I did a slight adjustment,
> >> adding the parameters in debian/rules, and targeting the "gnu" libc,
> >> see
> >> https://salsa.debian.org/debian/grok/-/commit/fe4c4b549ae2595007271df7502feb54115f4dda
> >
> > Could you make an upload with this bug fixed?
> 
> That fixed the bug, but the package unfortunately still won't build, and
> why or why not this happens is not clear to me. Any hints would be
> welcome. (build log for that commit at
> https://salsa.debian.org/debian/grok/-/jobs/1870864)

That was fixed in one of the missing NMUs.

> Also, the "grok" package is up for adoption if anyone would like to take
> care of it. (https://bugs.debian.org/775827)

Sorry, that won't be me.

> Stig Sandbeck Mathisen

cu
Adrian

Bug#992917: grok: FTBFS due to RPC removal from glibc

[Stig Sandbeck Mathisen]

Adrian Bunk  writes:

> On Sat, Aug 28, 2021 at 09:43:36PM +0200, Stig Sandbeck Mathisen wrote:
>> 
>> Hello,
>> 
>> Thank you for the bug report and patch. I did a slight adjustment,
>> adding the parameters in debian/rules, and targeting the "gnu" libc,
>> see
>> https://salsa.debian.org/debian/grok/-/commit/fe4c4b549ae2595007271df7502feb54115f4dda
>
> Could you make an upload with this bug fixed?

That fixed the bug, but the package unfortunately still won't build, and
why or why not this happens is not clear to me. Any hints would be
welcome. (build log for that commit at
https://salsa.debian.org/debian/grok/-/jobs/1870864)

Also, the "grok" package is up for adoption if anyone would like to take
care of it. (https://bugs.debian.org/775827)

-- 
Stig Sandbeck Mathisen
Debian Developer

Bug#994892: evdi-dkms: fails to build for kernel 5.14.0-1

[Rémi Letot]

Package: evdi-dkms
Version: 1.9.0+dfsg-1
Severity: important

Dear Maintainer,

I upgraded to linux-image 5.14.0-1-amd64, and evdi-dkms does not build 
anymore. 

sudo dpkg-reconfigure evdi-dkms 

--
Deleting module version: 1.9.0+dfsg
completely from the DKMS tree.
--
Done.
Loading new evdi-1.9.0+dfsg DKMS files...
Building for 5.14.0-1-amd64
Building initial module for 5.14.0-1-amd64
Error! Bad return status for module build on kernel: 5.14.0-1-amd64 (x86_64)
Consult /var/lib/dkms/evdi/1.9.0+dfsg/build/make.log for more information.

I attach the needed make.log file. Don't hesitate to ask for more info. 

Thanks a lot, 
-- 
Rémi

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

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

Versions of packages evdi-dkms depends on:
ii  dkms  2.8.4-4

Versions of packages evdi-dkms recommends:
ii  libevdi0  1.9.0+dfsg-1

evdi-dkms suggests no packages.

-- no debconf information
DKMS make.log for evdi-1.9.0+dfsg for kernel 5.14.0-1-amd64 (x86_64)
mer 22 sep 2021 20:19:06 CEST
make : on entre dans le répertoire « /usr/src/linux-headers-5.14.0-1-amd64 »
  CC [M]  /var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_platform_drv.o
  CC [M]  /var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_platform_dev.o
  CC [M]  /var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_sysfs.o
  CC [M]  /var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_modeset.o
  CC [M]  /var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_connector.o
  CC [M]  /var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_encoder.o
  CC [M]  /var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_drm_drv.o
  CC [M]  /var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_fb.o
  CC [M]  /var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_gem.o
  CC [M]  /var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_painter.o
/var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_drm_drv.c:81:3: error: ‘struct 
drm_driver’ has no member named ‘preclose’; did you mean ‘postclose’?
   81 |  .preclose = evdi_driver_preclose,
  |   ^~~~
  |   postclose
/var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_drm_drv.c:81:14: error: initialization 
of ‘void (*)(struct drm_device *)’ from incompatible pointer type ‘void 
(*)(struct drm_device *, struct drm_file *)’ 
[-Werror=incompatible-pointer-types]
   81 |  .preclose = evdi_driver_preclose,
  |  ^~~~
/var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_drm_drv.c:81:14: note: (near 
initialization for ‘driver.release’)
/var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_drm_drv.c:87:3: error: ‘struct 
drm_driver’ has no member named ‘gem_free_object_unlocked’
   87 |  .gem_free_object_unlocked = evdi_gem_free_object,
  |   ^~~~
/var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_drm_drv.c:87:30: error: initialization 
of ‘void (*)(struct drm_device *)’ from incompatible pointer type ‘void 
(*)(struct drm_gem_object *)’ [-Werror=incompatible-pointer-types]
   87 |  .gem_free_object_unlocked = evdi_gem_free_object,
  |  ^~~~
/var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_drm_drv.c:87:30: note: (near 
initialization for ‘driver.lastclose’)
/var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_drm_drv.c:91:3: error: ‘struct 
drm_driver’ has no member named ‘gem_vm_ops’
   91 |  .gem_vm_ops = _gem_vm_ops,
  |   ^~
/var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_drm_drv.c:91:16: error: initialization 
of ‘void (*)(struct drm_device *)’ from incompatible pointer type ‘const struct 
vm_operations_struct *’ [-Werror=incompatible-pointer-types]
   91 |  .gem_vm_ops = _gem_vm_ops,
  |^
/var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_drm_drv.c:91:16: note: (near 
initialization for ‘driver.unload’)
/var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_modeset.c:163:20: error: 
initialization of ‘void (*)(struct drm_crtc *, struct drm_atomic_state *)’ from 
incompatible pointer type ‘void (*)(struct drm_crtc *, struct drm_crtc_state 
*)’ [-Werror=incompatible-pointer-types]
  163 |  .atomic_flush   = evdi_crtc_atomic_flush,
  |^~
/var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_modeset.c:163:20: note: (near 
initialization for ‘evdi_helper_funcs.atomic_flush’)
/var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_modeset.c:308:19: error: 
initialization of ‘void (*)(struct drm_plane *, struct drm_atomic_state *)’ 
from incompatible pointer type ‘void (*)(struct drm_plane *, struct 
drm_plane_state *)’ [-Werror=incompatible-pointer-types]
  308 |  .atomic_update = evdi_plane_atomic_update,
  |   ^~~~
/var/lib/dkms/evdi/1.9.0+dfsg/build/evdi_modeset.c:308:19: note: (near 
initialization for 

Bug#993578: 90gpg-agent generator: `gpgconf --check-programs` can hang

[Kévin Seroux]

Hello,

This bug happened to my server, it prevented SSH connections.

One workaround is to initiate another SSH connection before the session 
drop timeout (systemd seems to not trigger several times 90gpg-agent).

Since I removed the gpg-agent package, SSH now works.

Regards,

Kevin

Bug#994891: ITP: system-monitoring-center -- Provides information about system performance and usage

[Hakan Dündar]

Package: system-monitoring-center
Version: N/A; reported 2021-09-22
Severity: wishlist

* Package name : system-monitoring-center
Version : v0.1.9-beta
Upstream Author : Hakan Dündar 
* URL : https://kod.pardus.org.tr/Hakan/system-monitoring-center
* License : GNU GPL v3
Description : Provides information about CPU/RAM/Disk/Network/GPU
performance, sensors, processes, users, storage, startup programs,
services, environment variables and system.

Bug#536815: obeisance dear beloved

[Sophia Brown]

Meu caro amigo, elogios a você e toda sua família.

Meu nome é Sra. Sophia Brown dos EUA, uma viúva que sofre de doença de
câncer, estou escrevendo este e-mail com lágrimas graves nos olhos e
muita dor no coração. Decidi entrar em contato com você por causa da
urgência da minha situação.

Minha querida, quero doar US$ 6,5 milhões para caridade. projetos em
seu país, também parte desse dinheiro será doado aos pobres e menos
privilegiados em seu país. Por favor, responda por mais detalhes.

Sophia J. Brown

Bug#994890: New upstream version (5.7.4)

[Vincent Bernat]

Package: maim
Version: 5.6.3-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

Could you please upload a new version? 5.6.3 is getting a bit old and
I am running into an annoying bug that may be fixed in a more recent
version.

Thanks!


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

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

Versions of packages maim depends on:
ii  libc62.32-4
ii  libgcc-s111.2.0-7
ii  libjpeg62-turbo  1:2.0.6-4
ii  libpng16-16  1.6.37-3
ii  libstdc++6   11.2.0-7
ii  libx11-6 2:1.7.2-2+b1
ii  libxcomposite1   1:0.4.5-1
ii  libxext6 2:1.3.4-1
ii  libxfixes3   1:5.0.3-2
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  slop 7.5-1+b1

maim recommends no packages.

maim suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmFLYPgSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5gvgP/R2B3vthPg67Ch5dUEcF6i7CNEZhfHSu
Nmxb8LyaAPHM682dTvBbb0lK6Dh2PjUIBZLnKs1rc8kD1RgnVlf5BYpyvO0E/hin
PlmG/XK3vRzAkXNagO6KDHm9n+B1p9gTmfCzyXbzJP7lgthZgwP5pd+qdtg3nS4n
NWIY+kqUGFV6eAbWO2CIrUrA/VYCufP2spNR7aUgVFNRciklYxtxJD6/0zNVXu1n
fpC+1JBQnER7rg8gCZTChEuIMeNa1BYPTvS9WBVPEcXMKyOEoQzCDN1OcuqoaaLX
g4XxlCU+KwKd3AA2JRKivb0Qb+S55uqqeCoiVkxm8N4TU4KqvdUQe2fSKHwVQrtI
gb4GDZK+jEYXOEzf7FqHfhvfV5Gt3Kpw3KmJcQXqh6Kszq2j4zsox7jvV+dJ28Kv
Qc+jPMZE5ltkqEhSCM8HM/mH5v1bNAB8haKAPQJ2j9DKst2eZq2EfNKctRgjMxIX
pwjrnumOrArBnSGaccNX4mmhboxiNnSqD3JgvLLFlsYWCYzqh18YfXDc6sAZL8zN
dV3aQMNsXCcdmgsVi3m/vbYnATIR2OQ224rJan8n7QAPEdiaNOrssn5Ei5u9e+C/
yEgBIOGODObiJFPuAwzADoo64q9nEXZsI4kwpl3ce70Ytr4HyY8d+sQ+5xyk5GRU
33xCAxiNWhgA
=16HM
-END PGP SIGNATURE-

Bug#994757: libgraphite2-dev: no archive files for static compilation are included in the -dev package

[Rene Engelhard]

tag 994757 + wontfix

thanks

Hi,

Am 22.09.21 um 17:56 schrieb Alfonso Sanchez-Beato:

> and that in general having the option to compile statically cannot be
harmful.

I disagree. It's probably usedul for essential stuff but not for GUI
stuff. (and graphite is about fonts, so GUI).


There actually is effort in Debian to get rid of .as and MANY packages
don't ship .as anymore. I am not convinced adding a new .a now is a way
forward.


Regards,


Rene

Bug#994757: libgraphite2-dev: no archive files for static compilation are included in the -dev package

[Rene Engelhard]

Hi again,

Am 22.09.21 um 18:08 schrieb Rene Engelhard:
> Hi,
>> Do you want me to create a new bug? I was about to do it, but thought
>> that would create more noise by now.
> 
> obviously not. if you read the bug you'd have seen that I fixed the
> metadata. 

I am sorry, actually I didn't remove the wrong found (cut'n'paste error
in the command), nevermind..

Regards,

Rene

Bug#992917: grok: FTBFS due to RPC removal from glibc

[Adrian Bunk]

On Sat, Aug 28, 2021 at 09:43:36PM +0200, Stig Sandbeck Mathisen wrote:
> 
> Hello,
> 
> Thank you for the bug report and patch.  I did a slight adjustment, adding the
> parameters in debian/rules, and targeting the "gnu" libc, see
> https://salsa.debian.org/debian/grok/-/commit/fe4c4b549ae2595007271df7502feb54115f4dda

Could you make an upload with this bug fixed?

> Stig Sandbeck Mathisen

Thanks in advance
Adrian

BTW: Two NMUs might be missing in git.

Bug#993949: dnscrypt-proxy fails to use address from DoH servers on start-up, resorts to system resolver

[Danny van Heumen]

Hi Eric,

It has been quiet for a while. I'd like to hear what your thoughts are on this.

Kind regards,
Danny

‐‐‐ Original Message ‐‐‐

On Friday, September 10th, 2021 at 5:54 PM, Danny van Heumen 
 wrote:

> Hi Eric,
>
> Indeed, a fix was implemented.
>
> Yes. I think that the address from the public-resolvers document should take 
> precedence over the address from an arbitrary resolver.
>
> Kind regards,
>
> Danny
>
> ‐‐‐ Original Message ‐‐‐
>
> On Friday, September 10th, 2021 at 7:40 AM, Eric Dorland e...@debian.org 
> wrote:
>
> > Control: forwarded -1 https://github.com/DNSCrypt/dnscrypt-proxy/issues/1861
> >
> > Thanks for the report. I've marked it forwarded upstream, and the fix
> >
> > appears to be in
> >
> > https://github.com/DNSCrypt/dnscrypt-proxy/commit/0f00cd27f92cee434336c6d6cde9df26286d8dbe.
> >  Do
> >
> > you think this is serious enough to warrant cherrypicking into the
> >
> > package or should we just wait for the next upstream release?
> >
> > -   Danny van Heumen (da...@dannyvanheumen.nl) wrote:
> >
> > > Package: dnscrypt-proxy
> > >
> > > Version: 2.0.45+ds1-1+b5
> > >
> > > Severity: normal
> > >
> > > X-Debbugs-Cc: da...@dannyvanheumen.nl
> > >
> > > Dear Maintainer,
> > >
> > > A bug was recently found where DNS stamp information is used
> > >
> > > incorrectly to fill the resolver cache on initialization.
> > >
> > > In short, DNS stamps of the various DNSCrypt/DoH/etc. resolvers include
> > >
> > > hostname and port information for finding the server. Additionally, it
> > >
> > > (optionally) includes an IPv4/IPv6 address to find the server without
> > >
> > > nameserver resolution for bootstrapping/initialization purposes, in such
> > >
> > > cases where it is unreliable or unavailable.
> > >
> > > dnscrypt-proxy intends to use this address in all cases - caching the
> > >
> > > address with unlimited lifetime, but accidentally stored it with incorrect
> > >
> > > key "hostname with optional port number". Subsequently loading from a key
> > >
> > > "hostname" will fail to load the address from the cache.
> > >
> > > Consequently, in all cases of DoH servers that include a port number,
> > >
> > > the bootstrapping address could not be loaded and dnscrypt-proxy needs to
> > >
> > > rely on the system resolver to look up the address anyways.
> > >
> > > The details can be found in
> > >
> > > https://github.com/DNSCrypt/dnscrypt-proxy/issues/1861
> > >
> > > and a side-effect was under discussion at
> > >
> > > https://github.com/DNSCrypt/dnscrypt-proxy/discussions/1828
> > >
> > > It is beneficial to use the DNS stamp information both for speed and
> > >
> > > reliability of resolution.
> > >
> > > Kind regards,
> > >
> > > Danny
> > >
> > > PS: I am not familiar with bug reporting or bug handling in Debian. Please
> > >
> > > let me know if I should do things differently. I may be able to help if
> > >
> > > you want to cherry-pick the bugfix from upstream. (Although I am not
> > >
> > > affiliated with the project in any way.)
> > >
> > > -- System Information:
> > >
> > > Debian Release: 11.0
> > >
> > > APT prefers stable-security
> > >
> > > APT policy: (500, 'stable-security'), (500, 'stable')
> > >
> > > Architecture: amd64 (x86_64)
> > >
> > > Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
> > >
> > > Kernel taint flags: TAINT_USER
> > >
> > > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> > > LANGUAGE=en_US:en
> > >
> > > Shell: /bin/sh linked to /usr/bin/dash
> > >
> > > Init: systemd (via /run/systemd/system)
> > >
> > > LSM: AppArmor: enabled
> > >
> > > Versions of packages dnscrypt-proxy depends on:
> > >
> > > ii adduser 3.118
> > >
> > > ii libc6 2.31-13
> > >
> > > ii lsb-base 11.1.0
> > >
> > > dnscrypt-proxy recommends no packages.
> > >
> > > Versions of packages dnscrypt-proxy suggests:
> > >
> > > pn resolvconf 
> > >
> > > -- Configuration Files:
> > >
> > > /etc/dnscrypt-proxy/dnscrypt-proxy.toml changed [not included]
> > >
> > > -- no debconf information
> >
> > Eric Dorland e...@kuroneko.ca
> >
> > 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93

Bug#956121: Issue persists in 40.4

[Damián Cinich]

Hi everyone,

I'm facing exactly the same issue in GNOME 40. Same symptoms: The screen in
the second display is entirely blank, except for the mouse pointer which I
can move. I'm not using proprietary nvidia drivers, just Wayland, Nouveau,
Mutter, on GNOME 40.

Here's some environmental information:

Versions:

===
$ dpkg -l xserver-xorg-video-nouveau mutter xwayland
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---===
ii  mutter 40.4-2+b1amd64Example window
manager using GNOME's window manager library
ii  xserver-xorg-video-nouveau 1:1.0.17-1   amd64X.Org X server --
Nouveau display driver
ii  xwayland   2:1.20.11-1  amd64Xwayland X server
===

Devices:

===
$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 630 (rev
04)
01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro
M1200 Mobile] (rev a2)
===

Info from reportbug:

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

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

Versions of packages mutter depends on:
ii  adwaita-icon-theme41.0-1
ii  gnome-settings-daemon-common  40.0.1-2
ii  gsettings-desktop-schemas 41.0-1
ii  libc6 2.32-4
ii  libgles2  1.3.4-2+b1
ii  libglib2.0-0  2.70.0-1
ii  libmutter-8-0 40.4-2+b1
ii  libwayland-client01.19.0-2
ii  libx11-6  2:1.7.2-2+b1
ii  libxcomposite11:0.4.5-1
ii  mutter-common 40.4-2
ii  zenity3.41.0-2

mutter recommends no packages.

Versions of packages mutter suggests:
ii  gnome-control-center  1:40.1-1
ii  xdg-user-dirs 0.17-2

-- no debconf information
===

Bug#994757: libgraphite2-dev: no archive files for static compilation are included in the -dev package

[Rene Engelhard]

Hi,
> Do you want me to create a new bug? I was about to do it, but thought
> that would create more noise by now.

obviously not. if you read the bug you'd have seen that I fixed the
metadata. Yes,a new bug would be  useless noise.


Regards,


Rene

Bug#994757: libgraphite2-dev: no archive files for static compilation are included in the -dev package

[Alfonso Sanchez-Beato]

On Mon, Sep 20, 2021 at 5:39 PM Rene Engelhard  wrote:
>
> notfound 994757 1.3.13-11
>
> severity 994757 wishlist
>
> thanks
>
> Hi,
>
> Am 20.09.21 um 16:43 schrieb Alfonso Sanchez-Beato:
> > Package: libgraphite2-dev
> > Version: 1.3.13-11build1
>
> There is no such version. You are reporting against Debian, please use
> proper versions existing there.
>
>
> Also you are reporting against a obsolete version which doesn't exist
> anymore (and in stable stuff like this won't be changed):
>
> $ rmadison libgraphite2-dev
>
> libgraphite2-dev | 1.3.13-7| oldstable   | amd64, arm64,
> armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
> libgraphite2-dev | 1.3.14-1| stable  | amd64, arm64,
> armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
> libgraphite2-dev | 1.3.14-1| testing | amd64, arm64,
> armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
> libgraphite2-dev | 1.3.14-1| unstable| amd64, arm64,
> armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
>
> > There is no libgraphite2.a file, so it is not possible to compile statically
> > against this library.
> Because upstream doesn't build one in their standard build and I didn't
> bother to manually build it as in your patch ...
> > See attached patch to solve this.
> .. as I am not sure. Why would people want to statically build against
>
> libgraphite2.a anyways?

My use case is to compile an embedded application with all
dependencies bundled in,
including libpango, libgraphite, and others, to minimize the final
size of the image (no other
apps would use the shared libs anyway). But I think it can be useful
in other cases too,
and that in general having the option to compile statically cannot be harmful.

>
> > -- System Information:
> > Debian Release: bullseye/sid
> >   APT prefers focal-updates
> >   APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 
> > 'focal'), (100, 'focal-backports')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
>
> Ah, this explains it. If you use Ubuntu please do some care to make a correct 
> Debian bug report.

Do you want me to create a new bug? I was about to do it, but thought
that would create more noise by now.

>
>
> Regards,
>
>
> Rene
>
>

Thanks,
Alfonso

Bug#918137: marked as pending in lintian

[Felix Lechner]

Hi Feri,

On Wed, Sep 22, 2021 at 8:09 AM  wrote:
>
> Does this mean that Debhelper is too strict ...?

Probably, but I am not sure it matters. The version in oldstable
(1.48) falls short of either condition, and the next-higher
alternative (1.56) meets both of them.

Thanks again for your patience!

Kind regards
Felix Lechner

Bug#868861: Mitigation

[Michiel Hazelhof]

The complete and better walkthrough (systemd users only!), some parts
might be redundant if you allready migrated to the proper systemd
invocations:

This completely fixed the "There are processes named 'apache2' running
which do not match your pid file which are left untouched in the name of
safety, Please review the situation by hand. ..." warning (and the
application kill that follows).

0: systemctl disable apache2-instancename && systemctl stop
apache2-instancename
1: delete /etc/init.d/apache2 and /etc/init.d/apache2-instancename
3: ln -s /usr/sbin/apache2 /usr/sbin/apache2-instancename
4: edit /usr/sbin/apache2ctl:
- Find: HTTPD=${APACHE_HTTPD:-/usr/sbin/apache2}
- Replace with: HTTPD=${APACHE_HTTPD:-/usr/sbin/apache2$SUFFIX}
5: systemctl enable apache2@instancename && systemctl start
apache2@instancename

Important notices:
0: that your envvars in the apache config should change the suffix from
@instancename to -instancename as is debians default (if not simply do
the ln -s with @ instead of -)!
1: After every apache upgrade the /usr/sbin/apache2ctl mod needs to be
performed again!

On Tue, 6 Jul 2021 09:47:09 +0200 Michiel Hazelhof 
wrote:

> Made two small tweaks to hopefully mitigate this behaviour:
... Do not follow this post anymore!


OpenPGP_signature
Description: OpenPGP digital signature

Bug#994807: [Pkg-sssd-devel] Bug#994807: sssd-common: capabilities restrictions break the service

[Timo Aaltonen]

On 22.9.2021 17.43, Marc Dequènes (duck) wrote:

Quack,

On 2021-09-22 18:28, Timo Aaltonen wrote:


But since the 'run sssd as a non-privileged user' -feature is still
not used in Fedora either, best to make it run as root and change the
file permissions to match.


I guess it's not ready yet and following Fedora seems the best thing to do.


Yeah, I try to follow them when possible, but some changes do go 
unnoticed still.



I've pushed a new version to salsa, could you build and test that in
your environment? The autopkgtest at least passes so the daemon should
work (and didn't on the current version, which I didn't notice, boo).


I built it and restarted, no problem. I removed sbus-monitor, restarted, 
and it was able to recreate it.

Thanks for the quick fix :-).


Excellent, I'll add some other fixes too and upload.


--
t

Bug#994883: iptables-netflow-dkms: Kernel module fails to build for linux-image-5.14.0-1-amd64

[Salvatore Bonaccorso]

Hi Axel,

On Wed, Sep 22, 2021 at 04:45:45PM +0200, Axel Beckert wrote:
> Package: iptables-netflow-dkms
> Version: 2.6-1
> Severity: serious
> 
> DKMS make.log for ipt-netflow-2.6 for kernel 5.14.0-1-amd64 (x86_64)
> Wed Sep 22 16:33:59 CEST 2021
> ./gen_compat_def > compat_def.h
> Test symbol xt_family linux/netfilter_ipv4/ip_tables.h  declared
> Test struct timeval linux/ktime.h  undeclared
> Test struct proc_ops linux/proc_fs.h  declared
> Test symbol synchronize_sched linux/rcupdate.h  undeclared
> Test symbol nf_bridge_info_get linux/netfilter_bridge.h  declared
> Test struct vlan_dev_priv linux/if_vlan.h  declared
> Compiling 2.6 for kernel 5.14.6
> make -C /lib/modules/5.14.0-1-amd64/build 
> M=/var/lib/dkms/ipt-netflow/2.6/build modules
> make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
> rule.
> make[1]: Entering directory '/usr/src/linux-headers-5.14.0-1-amd64'
>   CC [M]  /var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.o
> /var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:96:4: warning: #warning 
> "Requested physdev is not compiled." [-Wcpp]
>96 | #  warning "Requested physdev is not compiled."
>   |^~~
> /var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c: In function ‘nf_seq_show’:
> /var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:762:39: warning: format 
> ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type 
> ‘s64’ {aka ‘long long int’} [-Wformat=]
>   762 |seq_printf(seq, " Flows selected %lu, discarded %lu.",
>   | ~~^
>   |   |
>   |   long unsigned int
>   | %llu
>   763 |atomic64_read(_selected),
>   |~~  
>   ||
>   |s64 {aka long long int}
> /var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:762:54: warning: format 
> ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type 
> ‘s64’ {aka ‘long long int’} [-Wformat=]
>   762 |seq_printf(seq, " Flows selected %lu, discarded %lu.",
>   |~~^
>   |  |
>   |  long unsigned int
>   |%llu
>   763 |atomic64_read(_selected),
>   764 |atomic64_read(_observed) - 
> atomic64_read(_selected));
>   |~~~
>   |   |
>   |   s64 {aka long long int}
> /var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:766:39: warning: format 
> ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type 
> ‘s64’ {aka ‘long long int’} [-Wformat=]
>   766 |seq_printf(seq, " Flows selected %lu.", 
> atomic64_read(_selected));
>   | ~~^
> ~~
>   |   ||
>   |   |s64 {aka long long int}
>   |   long unsigned int
>   | %llu
> /var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c: At top level:
> /var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:1946:13: error: static 
> declaration of ‘sk_error_report’ follows non-static declaration
>  1946 | static void sk_error_report(struct sock *sk)
>   | ^~~
> In file included from 
> /usr/src/linux-headers-5.14.0-1-common/include/net/inet_sock.h:22,
>  from 
> /usr/src/linux-headers-5.14.0-1-common/include/linux/udp.h:16,
>  from /var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:33:
> /usr/src/linux-headers-5.14.0-1-common/include/net/sock.h:2287:6: note: 
> previous declaration of ‘sk_error_report’ was here
>  2287 | void sk_error_report(struct sock *sk);
>   |  ^~~
> In file included from /var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:79:
> /var/lib/dkms/ipt-netflow/2.6/build/murmur3.h: In function ‘murmur3’:
> /var/lib/dkms/ipt-netflow/2.6/build/murmur3.h:35:14: warning: this statement 
> may fall through [-Wimplicit-fallthrough=]
>35 |   case 3: k1 ^= tail[2] << 16; /* FALLTHROUGH */
>   |   ~~~^~~~
> /var/lib/dkms/ipt-netflow/2.6/build/murmur3.h:36:3: note: here
>36 |   case 2: k1 ^= tail[1] << 8;  /* FALLTHROUGH */
>   |   ^~~~
> /var/lib/dkms/ipt-netflow/2.6/build/murmur3.h:36:14: warning: this statement 
> may fall through [-Wimplicit-fallthrough=]
>36 |   case 2: k1 ^= tail[1] << 8;  /* FALLTHROUGH */
>   |   ~~~^~~
> /var/lib/dkms/ipt-netflow/2.6/build/murmur3.h:37:3: note: here
>37 |   case 1: k1 ^= tail[0];
>   |   

Bug#994888: chromium: chrome://extensions/ broken

[Stefano Callegari]

Package: chromium
Version: 93.0.4577.82-1
Severity: normal

Dear Maintainer,

after last upgrade I've noted some problems with few web pages (for example
Amazon Music asks me to upgrade the browser because it's obsolete, or
embedded Youtube video not loaded).

So after some tests I've also opened chrome://extensions/ but show me only
the header: no extensions appears, a blank pages!

Although I see the header, no Menu or Search or "Developer mode" check
works.

The extensions buttons in the url bar, some works and some no.

I've tried to clean cache (all time), reload pages, reinstall without solve.

With a downgrade, the chrome://extensions/ page works again.

Thanks

Stefano


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (903, 'unstable'), (500, 'testing'), (400, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages chromium depends on:
ii  chromium-common 93.0.4577.82-1
ii  libasound2  1.2.5.1-1
ii  libatk-bridge2.0-0  2.38.0-2
ii  libatk1.0-0 2.36.0-2
ii  libatomic1  11.2.0-7
ii  libatspi2.0-0   2.42.0-1
ii  libavcodec587:4.4-6+b1
ii  libavformat58   7:4.4-6+b1
ii  libavutil56 7:4.4-6+b1
ii  libc6   2.32-4
ii  libcairo2   1.16.0-5
ii  libcups22.3.3op2-7
ii  libdbus-1-3 1.12.20-2
ii  libdrm2 2.4.107-3
ii  libevent-2.1-7  2.1.12-stable-1
ii  libexpat1   2.4.1-2+b1
ii  libflac81.3.3-2
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.10.4+dfsg-1
ii  libgbm1 21.2.1-2
ii  libgcc-s1   11.2.0-7
ii  libglib2.0-02.70.0-1
ii  libharfbuzz0b   2.7.4-1
ii  libicu6767.1-7
ii  libjpeg62-turbo 1:2.0.6-4
ii  libjsoncpp241.9.4-4
ii  liblcms2-2  2.12~rc1-2
ii  libminizip1 1.1-8+b1
ii  libnspr42:4.32-1
ii  libnss3 2:3.70-1
ii  libopenjp2-72.4.0-3
ii  libopus01.3.1-0.1
ii  libpango-1.0-0  1.48.10+ds1-1
ii  libpng16-16 1.6.37-3
ii  libpulse0   15.0+dfsg1-2
ii  libre2-920210901+dfsg-1
ii  libsnappy1v51.1.8-1
ii  libstdc++6  11.2.0-7
ii  libwebp60.6.1-2.1
ii  libwebpdemux2   0.6.1-2.1
ii  libwebpmux3 0.6.1-2.1
ii  libx11-62:1.7.2-2+b1
ii  libxcb1 1.14-3
ii  libxcomposite1  1:0.4.5-1
ii  libxdamage1 1:1.1.5-2
ii  libxext62:1.3.4-1
ii  libxfixes3  1:5.0.3-2
ii  libxml2 2.9.12+dfsg-5
ii  libxrandr2  2:1.5.1-1
ii  libxshmfence1   1.3-1
ii  libxslt1.1  1.1.34-4
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages chromium recommends:
ii  chromium-sandbox  93.0.4577.82-1

Versions of packages chromium suggests:
ii  chromium-driver  93.0.4577.82-1
pn  chromium-l10n
ii  chromium-shell   93.0.4577.82-1

Versions of packages chromium-common depends on:
ii  libc6   2.32-4
ii  libstdc++6  11.2.0-7
ii  libx11-62:1.7.2-2+b1
ii  libxext62:1.3.4-1
ii  x11-utils   7.7+5
ii  xdg-utils   1.1.3-4.1
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages chromium-common recommends:
ii  chromium-sandbox93.0.4577.82-1
ii  fonts-liberation1:1.07.4-11
ii  libgl1-mesa-dri 21.2.1-2
ii  libu2f-udev 1.1.10-3
ii  notification-daemon 3.20.0-4+b1
ii  plasma-workspace [notification-daemon]  4:5.21.5-3+b1
ii  system-config-printer   1.5.14-1
ii  upower  0.99.13-1

Versions of packages chromium-driver depends on:
ii  libatomic1  11.2.0-7
ii  libc6   2.32-4
ii  libevent-2.1-7  2.1.12-stable-1
ii  libgcc-s1   11.2.0-7
ii  libglib2.0-02.70.0-1
ii  libicu6767.1-7
ii  libminizip1 1.1-8+b1
ii  libnspr42:4.32-1
ii  libnss3 2:3.70-1
ii  libre2-920210901+dfsg-1
ii  libstdc++6  11.2.0-7
ii  libxcb1 1.14-3
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages chromium-sandbox depends on:
ii  libc6  2.32-4

-- no debconf information

Bug#994887: buster-pu: package ulfius/2.5.2-4

[Nicolas Mora]

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

[ Reason ]
Ulfius package contains the bug that is rewferred by CVE-2021-40540

[ Impact ]
Application segfault when a malformed http request is received

[ Risks ]
the patch is trivial, the risk is low

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
add 'memset(con_info, 0, sizeof(struct connection_info_struct));' after
con_info is malloced to initialize the structure and avoid testing an undefined
value.
diff -Nru ulfius-2.5.2/debian/changelog ulfius-2.5.2/debian/changelog
--- ulfius-2.5.2/debian/changelog   2019-01-12 12:41:47.0 -0500
+++ ulfius-2.5.2/debian/changelog   2021-09-20 08:15:27.0 -0400
@@ -1,3 +1,9 @@
+ulfius (2.5.2-4+deb10u1) buster; urgency=medium
+
+  * d/patches: Fix CVE-2021-40540
+
+ -- Nicolas Mora   Mon, 20 Sep 2021 08:15:27 -0400
+
 ulfius (2.5.2-4) unstable; urgency=medium
 
   * debian/rules: remove override_dh_auto_test since now it's executed
diff -Nru ulfius-2.5.2/debian/patches/CVE-2021-40540.patch 
ulfius-2.5.2/debian/patches/CVE-2021-40540.patch
--- ulfius-2.5.2/debian/patches/CVE-2021-40540.patch1969-12-31 
19:00:00.0 -0500
+++ ulfius-2.5.2/debian/patches/CVE-2021-40540.patch2021-09-20 
08:15:27.0 -0400
@@ -0,0 +1,13 @@
+Description: Fix CVE-2021-40540
+Author: Nicolas Mora 
+Forwarded: not-needed
+--- a/src/ulfius.c
 b/src/ulfius.c
+@@ -190,6 +190,7 @@
+   UNUSED(cls);
+   
+   if (con_info != NULL) {
++memset(con_info, 0, sizeof(struct connection_info_struct));
+ con_info->callback_first_iteration = 1;
+ con_info->u_instance = NULL;
+ u_map_init(_info->map_url_initial);
diff -Nru ulfius-2.5.2/debian/patches/series ulfius-2.5.2/debian/patches/series
--- ulfius-2.5.2/debian/patches/series  2019-01-12 12:41:47.0 -0500
+++ ulfius-2.5.2/debian/patches/series  2021-09-20 08:15:27.0 -0400
@@ -1,3 +1,4 @@
 examples.patch
 test.patch
 cmake.patch
+CVE-2021-40540.patch

Bug#994886: xsane not showing up in gimp

[Jörg Frings-Fürst]

merge 994886 994429
thanks

Hello,

thanks for the bug report. Since there are already several reports on
the error, I have merged them.


Am Mittwoch, dem 22.09.2021 um 17:00 +0200 schrieb Philipp Klaus
Krause:
> Package: xsane
> Version: 0.999-12
> Severity: normal
> X-Debbugs-Cc: p...@spth.de
> 
> Dear Maintainer,
> 
> since a few weeks or months, I no longer see the entry for using
> xsane to
> create a new image in gimp.
> I can still scan invoking xsane manually, saving the result, and
> opening it in
> gimp. But apparently the xsane gimp plugin no longer works.
> 
> Whe I delete .config/GIMP, on the next start of "LANG=C gimp" for
> multiple
> seconds the line I see "Querying new plugins" and "xsane" in the gimp
> startup
> window, but there menu entry for gimp still doesn't show up later.
> When doing
> that with gimp --verbose, I see "Querying plug-in:
> '/usr/lib/gimp/2.0/plug-
> ins/xsane/xsane'" in teh output, but no other references to sane, and
> no
> indication of anything going wrong.
> 
[...]

CU 
Jörg
-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema: SYR8SJXB
Wire: @joergfringsfuerst
Skype: joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#994057: libegl-mesa0: 21.2.1-2 with intel graphic card produces artifact on firefox-esr

[Salvatore Bonaccorso]

Related: https://bugzilla.mozilla.org/show_bug.cgi?id=1678804

Bug#994808: upgrade issue

[Sophie Brun]

On Wed, 22 Sep 2021 16:27:46 +0200 "Andreas B. Mundt"  wrote:

[...]
 
Great, many thanks.  I slightly modified the patch to make the fix 
a bit more targeted:  Only the faulty syntax is fixed now, not the 
whole file removed [1].


You'll find the code already pushed to salsa.


I quickly tested and everything works fine for me.
Thanks for your quick answer!


Concerning the autopkgtests: Can you point me to a package that
implements a test to detect these kind of errors early?


I don't know specific packages that implement that. Maybe Raphaël does.
The syntax error can probably be easily detected if you start the service
and check the status of the service in the autopkgtest.

Sophie

Bug#918137: marked as pending in lintian

[wferi]

Felix Lechner  writes:

> According to my research, the functionality was added in this commit [1] and
> released in this one [2] as part of init-system-helpers 1.52.

Hi Felix,

Thanks for the thorough research and the fix.  Does this mean that
Debhelper is too strict generating the init-system-helpers (>= 1.54~)
pre-dependency and it should use >= 1.52~ instead?
-- 
Thanks,
Feri

Bug#994886: xsane not showing up in gimp

[Philipp Klaus Krause]

Package: xsane
Version: 0.999-12
Severity: normal
X-Debbugs-Cc: p...@spth.de

Dear Maintainer,

since a few weeks or months, I no longer see the entry for using xsane to
create a new image in gimp.
I can still scan invoking xsane manually, saving the result, and opening it in
gimp. But apparently the xsane gimp plugin no longer works.

Whe I delete .config/GIMP, on the next start of "LANG=C gimp" for multiple
seconds the line I see "Querying new plugins" and "xsane" in the gimp startup
window, but there menu entry for gimp still doesn't show up later. When doing
that with gimp --verbose, I see "Querying plug-in: '/usr/lib/gimp/2.0/plug-
ins/xsane/xsane'" in teh output, but no other references to sane, and no
indication of anything going wrong.

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

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

Versions of packages xsane depends on:
ii  libc62.32-4
ii  libgimp2.0   2.10.22-4
ii  libglib2.0-0 2.68.4-1
ii  libgtk2.0-0  2.24.33-2
ii  libjpeg62-turbo  1:2.0.6-4
ii  liblcms2-2   2.12~rc1-2
ii  libpng16-16  1.6.37-3
ii  libsane1 1.0.32-4
ii  libtiff5 4.2.0-1
ii  sensible-utils   0.0.17
ii  xsane-common 0.999-12
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages xsane recommends:
ii  chromium [www-browser] 90.0.4430.212-1
ii  cups-client2.3.3op2-7
ii  firefox [www-browser]  88.0.1-1
ii  firefox-esr [www-browser]  78.13.0esr-1
ii  hv3 [www-browser]  3.0~fossil20110109-8
ii  lynx [www-browser] 2.9.0dev.9-2

Versions of packages xsane suggests:
ii  gimp 2.10.22-4
pn  gv   
pn  hylafax-client | mgetty-fax  
ii  tesseract-ocr4.1.1-2.1

Bug#994885: bullseye-pu: package glewlwyd/2.5.2-2

[Nicolas Mora]

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

Fix CVE-2021-40818 in bullseye

[ Reason ]
CVE-2021-40818 allows a malicious user to perform a buffer overflow during a
webauthn registration with FIDO2 protocol.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
The patch changes a 'unsigned char data_signed[200]' to a 'unsigned char *
data_signed = NULL' and allocates the variable with the proper length. The
previous code didn't take credential_id_len in account.
diff -Nru glewlwyd-2.5.2/debian/changelog glewlwyd-2.5.2/debian/changelog
--- glewlwyd-2.5.2/debian/changelog 2021-03-14 19:32:40.0 -0400
+++ glewlwyd-2.5.2/debian/changelog 2021-09-22 08:42:59.0 -0400
@@ -1,3 +1,11 @@
+glewlwyd (2.5.2-2+deb11u1) bullseye; urgency=medium
+
+  * d/patches: Fix CVE-2021-40818
+  possible buffer overflow during FIDO2 signature validation
+  in webauthn registration
+
+ -- Nicolas Mora   Wed, 22 Sep 2021 08:42:59 -0400
+
 glewlwyd (2.5.2-2) unstable; urgency=medium
 
   * Fix postgre database initialization (Closes: #985238)
diff -Nru glewlwyd-2.5.2/debian/patches/series 
glewlwyd-2.5.2/debian/patches/series
--- glewlwyd-2.5.2/debian/patches/series2021-03-14 19:32:40.0 
-0400
+++ glewlwyd-2.5.2/debian/patches/series2021-09-22 08:42:59.0 
-0400
@@ -1 +1,2 @@
 #webpack.patch
+webauthn.patch
diff -Nru glewlwyd-2.5.2/debian/patches/webauthn.patch 
glewlwyd-2.5.2/debian/patches/webauthn.patch
--- glewlwyd-2.5.2/debian/patches/webauthn.patch1969-12-31 
19:00:00.0 -0500
+++ glewlwyd-2.5.2/debian/patches/webauthn.patch2021-09-22 
08:42:59.0 -0400
@@ -0,0 +1,35 @@
+Description: Fix buffer overflow
+Author: Nicolas Mora 
+Forwarded: not-needed
+--- a/src/scheme/webauthn.c
 b/src/scheme/webauthn.c
+@@ -1530,7 +1530,7 @@
+   gnutls_pubkey_t pubkey = NULL;
+   gnutls_x509_crt_t cert = NULL;
+   gnutls_datum_t cert_dat, data, signature, cert_issued_by;
+-  unsigned char data_signed[200], client_data_hash[32], cert_export[32], 
cert_export_b64[64];
++  unsigned char * data_signed = NULL, client_data_hash[32], cert_export[32], 
cert_export_b64[64];
+   size_t data_signed_offset = 0, client_data_hash_len = 32, cert_export_len = 
32, cert_export_b64_len = 0;
+   
+   if (j_error != NULL) {
+@@ -1619,6 +1619,12 @@
+ break;
+   }
+   
++  if ((data_signed = 
o_malloc(rpid_hash_len+client_data_hash_len+credential_id_len+cert_x_len+cert_y_len+2))
 == NULL) {
++y_log_message(Y_LOG_LEVEL_DEBUG, "check_attestation_fido_u2f - Error 
allocating data_signed");
++json_array_append_new(j_error, json_string("Internal error"));
++break;
++  }
++
+   // Build bytestring to verify signature
+   data_signed[0] = 0x0;
+   data_signed_offset = 1;
+@@ -1653,6 +1659,7 @@
+   }
+   
+ } while (0);
++o_free(data_signed);
+ 
+ if (json_array_size(j_error)) {
+   j_return = json_pack("{sisO}", "result", G_ERROR_PARAM, "error", 
j_error);

Bug#994752: Bug#994751: pango1.0: the development package does not include static libraries

[Alfonso Sanchez-Beato]

On Mon, Sep 20, 2021 at 6:05 PM Simon McVittie  wrote:
>
> Control: tags -1 = moreinfo
>
> On Mon, 20 Sep 2021 at 17:29:34 +0200, Alfonso Sanchez-Beato wrote:
> > On Mon, Sep 20, 2021 at 5:05 PM Simon McVittie  wrote:
> > > libpango-1.0.so.0 depends on libgio-2.0.so.0, which depends on
> > > libmount.so.1, which is only available as a shared library
> >
> > I do not see a dependency on libgio when I run ldd on
> > libpango-1.0.so.0, although it does depend on libglib-2.0.so.0 and
> > libgobject-2.0.so.0.
>
> Maybe the dependency was only introduced in a recent version? It's
> certainly there in Debian unstable, which is the only suite where adding
> static libraries would be in-scope for Debian (other than experimental,
> but there's currently no version of pango1.0 in experimental), for at
> least amd64 and i386.

Right, I double checked and indeed the latest in unstable has that dependency.

>
> > Besides, it is possible to compile statically against libpango and
> > still compile dynamically against some of its dependencies.
> ...
> > > More generally, configurations that aren't actively tested typically
> > > don't work, so if I enable static linking in a particular package,
> > > I would want to have at least superficial autopkgtest coverage for it
> > > (see debian/tests/build-static and debian/tests/build in src:glib2.0 for
> > > an example)
> >
> > I will be happy to provide such a test if that is the blocker for landing 
> > this.
>
> If this is something that works in unstable, then please do.

Please see the new attached patch.

>
> smcv

Thanks,
Alfonso
diff -Nru pango1.0-1.48.10+ds1/debian/changelog pango1.0-1.48.10+ds1/debian/changelog
--- pango1.0-1.48.10+ds1/debian/changelog	2021-09-17 09:54:40.0 +
+++ pango1.0-1.48.10+ds1/debian/changelog	2021-09-22 14:10:13.0 +
@@ -1,3 +1,15 @@
+pango1.0 (1.48.10+ds1-2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Include archive files to allow static compilation of the libraries
+- d/rules: Build also archive files for static compilation
+- d/libpango1.0-dev.install: Include archive files
+- d/tests/build: Add --static option
+- d/tests/build-static: Exercise static linking
+- d/tests/control: Add build-static test
+
+ -- Alfonso Sanchez-Beato (email Canonical)   Wed, 22 Sep 2021 14:10:13 +
+
 pango1.0 (1.48.10+ds1-1) unstable; urgency=medium
 
   * Team upload
diff -Nru pango1.0-1.48.10+ds1/debian/libpango1.0-dev.install pango1.0-1.48.10+ds1/debian/libpango1.0-dev.install
--- pango1.0-1.48.10+ds1/debian/libpango1.0-dev.install	2021-09-17 09:54:40.0 +
+++ pango1.0-1.48.10+ds1/debian/libpango1.0-dev.install	2021-09-22 14:06:45.0 +
@@ -1,4 +1,5 @@
 usr/include
+usr/lib/*/*.a
 usr/lib/*/*.so
 usr/lib/*/pkgconfig/*.pc
 usr/share/gir-1.0
diff -Nru pango1.0-1.48.10+ds1/debian/rules pango1.0-1.48.10+ds1/debian/rules
--- pango1.0-1.48.10+ds1/debian/rules	2021-09-17 09:54:40.0 +
+++ pango1.0-1.48.10+ds1/debian/rules	2021-09-22 14:06:45.0 +
@@ -21,6 +21,7 @@
 		-Dauto_features=enabled \
 		-Dgtk_doc=$(with_docs) \
 		-Dinstall-tests=true \
+		-Ddefault_library=both \
 		$(NULL)
 
 override_dh_auto_test-arch:
diff -Nru pango1.0-1.48.10+ds1/debian/tests/build pango1.0-1.48.10+ds1/debian/tests/build
--- pango1.0-1.48.10+ds1/debian/tests/build	2021-09-17 09:54:40.0 +
+++ pango1.0-1.48.10+ds1/debian/tests/build	2021-09-22 14:10:13.0 +
@@ -1,11 +1,36 @@
 #!/bin/sh
 # autopkgtest check: Builds a small application against libcairo2-dev, checking
 # if it compiles, links and runs successfully.
-# Author: Rafał Cieślak  
+# Authors: Rafał Cieślak ,
+#  Alfonso Sánchez-Beato 
 
 set -e
 set -u
 
+mode=dynamic
+
+getopt_temp="$(getopt -o '' --long 'static' -n debian/tests/build -- "$@")"
+eval set -- "$getopt_temp"
+
+while true; do
+case "$1" in
+(--static)
+mode=static
+shift
+continue
+;;
+
+(--)
+shift
+break
+;;
+
+(*)
+echo "getopt: Internal error" >&2
+exit 2
+esac
+done
+
 WORKDIR=$(mktemp -d)
 cleanup () {
 rm -fr "$WORKDIR"
@@ -31,9 +56,26 @@
 }
 EOF
 
-# Deliberately word-splitting, that's how pkg-config works:
-# shellcheck disable=SC2046
-"${CROSS_COMPILE}gcc" -o build_test build_test.c $("${CROSS_COMPILE}pkg-config" --cflags --libs pango)
+
+case "$mode" in
+(static)
+# Compile all statically but libgraphite and libmount, that do not have
+# static version yet.
+flags=$("${CROSS_COMPILE}pkg-config" --cflags --static --libs pango)
+flags=$(echo "$flags" | sed 's/-lgraphite2//')
+flags=$(echo "$flags" | sed 's/-lmount//')
+# Deliberately word-splitting, that's how pkg-config works:
+# shellcheck disable=SC2086
+"${CROSS_COMPILE}gcc" -o build_test build_test.c -Wl,-Bstatic $flags -Wl,-Bdynamic -lgcc_s 

Bug#994884: libcairomm-1.0-doc doesn't work in devhelp: dangling refs and bad escaping

[Stefano Marsili]

Package: libcairomm-1.0-doc
Version: 1.12.2-4.1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
 After installing libcairomm-1.0-doc, devhelp search stopped working
 for the std namespace (cppreference package).
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 I removed dangling references to non existing html files in
 cairomm-1.0.devhelp2 (see patch at the end of this text)
   * What was the outcome of this action?
 I could search cppreference classes but still couldn't search
 libcairomm classes. devhelp couldn't load html pages because
 of doxygen not escaping RefPtr<> to RefPtr correctly
 (I guess)
   * What outcome did you expect instead?
 To browse the libcairomm documentation.

I escaped the relevant RefPtr<> to RefPtr\<\> in the offending refptr.h file
but I'm not familiar with autotools and couldn't regenerate the documentation,
which isn't rebuilt when running "debuild -us -uc" anyway

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

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

libcairomm-1.0-doc depends on no packages.

libcairomm-1.0-doc recommends no packages.

Versions of packages libcairomm-1.0-doc suggests:
ii  firefox-esr [www-browser]  78.14.0esr-1
ii  w3m [www-browser]  0.5.3+git20210102-6


Index: cairomm-1.12.2/docs/reference/cairomm-1.0.devhelp2
===
--- cairomm-1.12.2.orig/docs/reference/cairomm-1.0.devhelp2
+++ cairomm-1.12.2/docs/reference/cairomm-1.0.devhelp2
@@ -104,24 +104,6 @@
   
   
   
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
 
 
   
@@ -180,24 +162,6 @@
   
   
   
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
 
   
   

Bug#994807: [Pkg-sssd-devel] Bug#994807: sssd-common: capabilities restrictions break the service

[duck]

Quack,

On 2021-09-22 18:28, Timo Aaltonen wrote:


But since the 'run sssd as a non-privileged user' -feature is still
not used in Fedora either, best to make it run as root and change the
file permissions to match.


I guess it's not ready yet and following Fedora seems the best thing to 
do.



I've pushed a new version to salsa, could you build and test that in
your environment? The autopkgtest at least passes so the daemon should
work (and didn't on the current version, which I didn't notice, boo).


I built it and restarted, no problem. I removed sbus-monitor, restarted, 
and it was able to recreate it.

Thanks for the quick fix :-).

Regards.
\_o<

--
Marc Dequènes

Bug#994883: iptables-netflow-dkms: Kernel module fails to build for linux-image-5.14.0-1-amd64

[Axel Beckert]

Package: iptables-netflow-dkms
Version: 2.6-1
Severity: serious

DKMS make.log for ipt-netflow-2.6 for kernel 5.14.0-1-amd64 (x86_64)
Wed Sep 22 16:33:59 CEST 2021
./gen_compat_def > compat_def.h
Test symbol xt_family linux/netfilter_ipv4/ip_tables.h  declared
Test struct timeval linux/ktime.h  undeclared
Test struct proc_ops linux/proc_fs.h  declared
Test symbol synchronize_sched linux/rcupdate.h  undeclared
Test symbol nf_bridge_info_get linux/netfilter_bridge.h  declared
Test struct vlan_dev_priv linux/if_vlan.h  declared
Compiling 2.6 for kernel 5.14.6
make -C /lib/modules/5.14.0-1-amd64/build M=/var/lib/dkms/ipt-netflow/2.6/build 
modules
make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
rule.
make[1]: Entering directory '/usr/src/linux-headers-5.14.0-1-amd64'
  CC [M]  /var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.o
/var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:96:4: warning: #warning 
"Requested physdev is not compiled." [-Wcpp]
   96 | #  warning "Requested physdev is not compiled."
  |^~~
/var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c: In function ‘nf_seq_show’:
/var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:762:39: warning: format ‘%lu’ 
expects argument of type ‘long unsigned int’, but argument 3 has type ‘s64’ 
{aka ‘long long int’} [-Wformat=]
  762 |seq_printf(seq, " Flows selected %lu, discarded %lu.",
  | ~~^
  |   |
  |   long unsigned int
  | %llu
  763 |atomic64_read(_selected),
  |~~  
  ||
  |s64 {aka long long int}
/var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:762:54: warning: format ‘%lu’ 
expects argument of type ‘long unsigned int’, but argument 4 has type ‘s64’ 
{aka ‘long long int’} [-Wformat=]
  762 |seq_printf(seq, " Flows selected %lu, discarded %lu.",
  |~~^
  |  |
  |  long unsigned int
  |%llu
  763 |atomic64_read(_selected),
  764 |atomic64_read(_observed) - atomic64_read(_selected));
  |~~~
  |   |
  |   s64 {aka long long int}
/var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:766:39: warning: format ‘%lu’ 
expects argument of type ‘long unsigned int’, but argument 3 has type ‘s64’ 
{aka ‘long long int’} [-Wformat=]
  766 |seq_printf(seq, " Flows selected %lu.", 
atomic64_read(_selected));
  | ~~^
~~
  |   ||
  |   |s64 {aka long long int}
  |   long unsigned int
  | %llu
/var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c: At top level:
/var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:1946:13: error: static 
declaration of ‘sk_error_report’ follows non-static declaration
 1946 | static void sk_error_report(struct sock *sk)
  | ^~~
In file included from 
/usr/src/linux-headers-5.14.0-1-common/include/net/inet_sock.h:22,
 from 
/usr/src/linux-headers-5.14.0-1-common/include/linux/udp.h:16,
 from /var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:33:
/usr/src/linux-headers-5.14.0-1-common/include/net/sock.h:2287:6: note: 
previous declaration of ‘sk_error_report’ was here
 2287 | void sk_error_report(struct sock *sk);
  |  ^~~
In file included from /var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:79:
/var/lib/dkms/ipt-netflow/2.6/build/murmur3.h: In function ‘murmur3’:
/var/lib/dkms/ipt-netflow/2.6/build/murmur3.h:35:14: warning: this statement 
may fall through [-Wimplicit-fallthrough=]
   35 |   case 3: k1 ^= tail[2] << 16; /* FALLTHROUGH */
  |   ~~~^~~~
/var/lib/dkms/ipt-netflow/2.6/build/murmur3.h:36:3: note: here
   36 |   case 2: k1 ^= tail[1] << 8;  /* FALLTHROUGH */
  |   ^~~~
/var/lib/dkms/ipt-netflow/2.6/build/murmur3.h:36:14: warning: this statement 
may fall through [-Wimplicit-fallthrough=]
   36 |   case 2: k1 ^= tail[1] << 8;  /* FALLTHROUGH */
  |   ~~~^~~
/var/lib/dkms/ipt-netflow/2.6/build/murmur3.h:37:3: note: here
   37 |   case 1: k1 ^= tail[0];
  |   ^~~~
/var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c: In function ‘parse_sampler’:
/var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:2228:7: warning: this 
statement may fall through [-Wimplicit-fallthrough=]
 2228 |   ret = -EINVAL;

Bug#994808: upgrade issue

[Andreas B. Mundt]

Control: tags -1 + pending

Hi Sophie, hi Raphael,

On Wed, Sep 22, 2021 at 09:37:46AM +0200, Raphael Hertzog wrote:
> 
> We will come up with an additional MR later today.
 
Great, many thanks.  I slightly modified the patch to make the fix 
a bit more targeted:  Only the faulty syntax is fixed now, not the 
whole file removed [1].

You'll find the code already pushed to salsa.

If I don't hear back from you, I'll upload the package with the fix 
later today in the early evening.

Concerning the autopkgtests: Can you point me to a package that
implements a test to detect these kind of errors early?

Best regards,

  Andi


[1] This covers also the case I had here:  After the faulty line, I had
a correct line, which made the test: 

 $ if ! . /etc/default/atftpd_save ; then echo "Remove broken 
/etc/default/atftpd"; fi
 bash: 69: command not found
 $ 

slightly confusing …

Bug#994882: ITS: vitables

[Benda Xu]

Package: vitables
Version: 3.0.2-1
Severity: normal
X-Debbugs-Cc: Debian Science Maintainers 
, Dmitrijs Ledkovs 
, Picca Frédéric-Emmanuel 

Dear Maintainer,

I am interested in co-maintaining vitables by joining the science team
and appending myself as an uploader.

The newest version (3.0.0-1.1) was NMU-ed and has not been included in
the package Vcs for more than a year. Bug 966056 (a year old) prevents
the version in bullseye to function if python3-sip is not installed. I
think the current uploads need help.

I have contributed to the present 3.0.0-1 release in 2019 and I would
like to support packaging vitables in the long run, as I am an active
user of it and giving my lectures with it.

The diff is in the merge request:

  https://salsa.debian.org/science-team/vitables/-/merge_requests/4

Thanks for your consideration!
Benda

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

Kernel: Linux 5.10.0-5-amd64 (SMP w/8 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: OpenRC (via /run/openrc), PID 1: init

Versions of packages vitables depends on:
ii  python3  3.9.2-2
ii  python3-numexpr  2.7.2-2
ii  python3-numpy1:1.19.5-1
ii  python3-qtpy 1.9.0-3
ii  python3-tables   3.6.1-3

vitables recommends no packages.

vitables suggests no packages.

-- no debconf information

Bug#994872: python3-spf-engine: Replace link to www.openspf.net

[Richard van den Berg]

Package: python3-spf-engine
Version: 2.9.2-2
Severity: normal

python3-spf-engine 2.9.2-2 still builds an url to www.openspf.net in
/usr/lib/python3/dist-packages/spf_engine/__init__.py on line 370:

def _rejectmessage(result, type, info, ip, recipient, configData):
if result[3] == 'reject':
rejectdefer = "rejected"
elif result[3] == 'defer':
rejectdefer = "deferred"
url = ("http://www.openspf.net/Why?s={0};id={1};ip={2};r={3};
  .format(type, info, ip, recipient))
msg = configData.get('Reason_Message')
return msg.format(
rejectdefer=rejectdefer,
spf=result[1],
url=url,
)

The openspf.net website has been offline now for two years. It is time to
use a different default url. Personally I use https://mxtoolbox.com/spf.aspx
but there might be a better website to link to by default.

I know the Reason_Message can be set in 
/etc/postfix-policyd-spf-python/policyd-spf.conf
but it cannot be parameterized in detail like the default url is. At the 
very least please make the variables type, info, ip and recipient available to
Reason_Message as well.

-- System Information:
Debian Release: 10.10
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'testing'), (500, 'oldstable')
Architecture: amd64 (x86_64)

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

Versions of packages python3-spf-engine depends on:
ii  python3  3.7.3-1
ii  python3-authres  1.1.1-1
ii  python3-spf  2.0.12t-3

python3-spf-engine recommends no packages.

python3-spf-engine suggests no packages.

-- no debconf information

Bug#994881: bullseye-pu: package rhonabwy/0.9.13-3

[Nicolas Mora]

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

The attached debdiff file fixes 2 bugs:
  jwe cbc tag computation error
  jws alg:none signature verification issue

[ Tests ]
The tests are updated by the debdiff file

[ Risks ]
The jws alg:none signature verification issue might lead to incorrect token
verification, while the jwe cbc tag computation error leads to incorrect token
decryption

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable
diff -Nru rhonabwy-0.9.13/debian/changelog rhonabwy-0.9.13/debian/changelog
--- rhonabwy-0.9.13/debian/changelog2021-02-09 07:33:21.0 -0500
+++ rhonabwy-0.9.13/debian/changelog2021-09-22 07:29:46.0 -0400
@@ -1,3 +1,11 @@
+rhonabwy (0.9.13-3+deb11u1) bullseye; urgency=medium
+
+  * d/patches/bugfixes: apply upstream bugfixes
+  jwe cbc tag computation error
+  jws alg:none signature verification issue
+
+ -- Nicolas Mora   Wed, 22 Sep 2021 07:29:46 -0400
+
 rhonabwy (0.9.13-3) unstable; urgency=medium
 
   * Fix r_library_info_json_t output
diff -Nru rhonabwy-0.9.13/debian/patches/bugfixes.patch 
rhonabwy-0.9.13/debian/patches/bugfixes.patch
--- rhonabwy-0.9.13/debian/patches/bugfixes.patch   1969-12-31 
19:00:00.0 -0500
+++ rhonabwy-0.9.13/debian/patches/bugfixes.patch   2021-09-22 
07:29:46.0 -0400
@@ -0,0 +1,37 @@
+Description: Fix jwe cbc tag computation and jws alg:none signature 
verification
+Author: Nicolas Mora 
+Forwarded: not-needed
+--- a/src/jwe.c
 b/src/jwe.c
+@@ -450,7 +450,7 @@
+ memcpy(compute_hmac+hmac_size, al, 8);
+ hmac_size += 8;
+ 
+-if (!(res = gnutls_hmac_fast(mac, jwe->key, 16, compute_hmac, hmac_size, 
tag))) {
++if (!(res = gnutls_hmac_fast(mac, jwe->key, jwe->key_len/2, compute_hmac, 
hmac_size, tag))) {
+   *tag_len = gnutls_hmac_get_len(mac)/2;
+   ret = RHN_OK;
+ } else {
+--- a/src/jws.c
 b/src/jws.c
+@@ -1268,9 +1268,6 @@
+ case R_JWA_ALG_ES256K:
+   ret = RHN_ERROR_UNSUPPORTED;
+   break;
+-case R_JWA_ALG_NONE:
+-  ret = RHN_OK;
+-  break;
+ default:
+   ret = RHN_ERROR_INVALID;
+   break;
+--- a/test/jws_core.c
 b/test/jws_core.c
+@@ -496,7 +496,7 @@
+   ck_assert_ptr_ne((token = r_jws_serialize(jws_sign, NULL, 0)), NULL);
+   
+   ck_assert_int_eq(r_jws_parse(jws_verify, token, 0), RHN_OK);
+-  ck_assert_int_eq(r_jws_verify_signature(jws_verify, NULL, 0), RHN_OK);
++  ck_assert_int_eq(r_jws_verify_signature(jws_verify, NULL, 0), 
RHN_ERROR_INVALID);
+   o_free(token);
+   
+   r_jws_free(jws_sign);
diff -Nru rhonabwy-0.9.13/debian/patches/series 
rhonabwy-0.9.13/debian/patches/series
--- rhonabwy-0.9.13/debian/patches/series   2021-02-09 07:33:21.0 
-0500
+++ rhonabwy-0.9.13/debian/patches/series   2021-09-22 07:29:46.0 
-0400
@@ -1,2 +1,3 @@
 library_info.patch
 disable_test_rhonabwy_generate_key_pair.patch
+bugfixes.patch

Bug#991982: nano fails to start when TERM is unset

[Benno Schulenberg]

Op 11-08-2021 om 09:51 schreef Benno Schulenberg:
> Nano will "run" in any terminal, but the user (or rather: the system) /must/
> specify the terminal.  There does not seem to be a way for a program to probe
> which terminal is being used.

Mitigated in git, commit 46cdf8b7, by setting TERM to vt220 when it is unset.
The vt220 terminfo is likely to be present on any system, and will probably
be good enough to give a usable nano.

Benno



OpenPGP_signature
Description: OpenPGP digital signature

Bug#994833: OpenCL programs abort when intel-opencl-icd is installed

[Giuseppe Bilotta]

On Wed, Sep 22, 2021 at 8:32 AM Andreas Beckmann  wrote:
> So if it does matter abi-wise for intel-opencl-icd which version of llvm
> libigfoo1 was compiled against, we should model this in the dependency
> chain.

To be able to confirm this, I would need a version of all the libig*
stuff correctly
compiled against LLVM12 (rather than the mix-up we currently have for
libigdfcl1).
I can then test against intel-opencl-icd version 20.x, which is built
with LLVM11,
and (most probably) confirm that the setup is broken.

> It's probably best if all libigfoo1 library packages provide a virtual
> package libigfoo1-llvmXX (don't hardcode it, use substvars) and
> intel-opencl-icd depends on that (in addition to libigfoo1 (>= xx)) to
> specify the specific abi needed.
> (renaming the real package to libigfoo1-llvmXX each time the llvm major
> version changes is probably overkill)

The virtual ABI package sounds like the best choice.
I don't think renaming the real package makes sense,
at least at the moment. It might become useful if there ever is a need
for the different ABIs to be co-installed.

> Are there other users of libigfoo1 besides intel-opencl-icd?

The only one I can see is intel-media-va-driver{,-non-free} depending
on libigdgmm11,
but that particular package doesn't seem to have an LLVM dependency
(directly or not).

> We will proably still run into problems if different ICDs built against
> different LLVM versions are going to be loaded at the same time (e.g.
> pocl/llvm9 and intel/llvm1x) because the different llvm versions seem to
> stomp on each others internal bits. There are bugs open about that ...

FWIW, I haven't had these issues in a while now
(but I'm also building my own pocl, so maybe by chance I'm using the
same LLVM version anyway.)

> I may come up with a patch if time permits.

Much appreciated.

-- 
Giuseppe "Oblomov" Bilotta

Bug#993269: RFS: e-antic 0.1.8+ds-2

[Torrance, Douglas]

On Wed 22 Sep 2021 08:50:51 AM EDT, Nilesh Patra  wrote:
> On Wed, 22 Sept 2021 at 16:49, Torrance, Douglas 
> wrote:
>
>> Control: tags -1 pending
>>
>> e-antic and its reverse dependencies (macaulay2, normaliz, polymake,
>> pynac, and
>> singular) are currently scheduled for autoremoval on 2021-10-12 due to RC
>> bug
>> #993269.  Peter Green tracked down a fix and submitted a patch, which I've
>> pushed to Salsa, along with a couple other minor things.
>>
>> Would anyone be able to review/sponsor, or alternatively, grant me DM
>> upload
>> permissions for e-antic?
>>
>
> $ dcut ssh-upload dm --uid dtorra...@piedmont.edu --allow e-antic
>
> Uploading commands file to ssh.upload.debian.org (incoming: /srv/
> upload.debian.org/UploadQueue/)
> Picking DM Doug Torrance  with fingerprint
> 803CE41F4DC252ECB5E5F1B9D12B2BE26D3FF663
> SCP is deprecated. Please consider upgrading to SFTP.
> Uploading nilesh-1632314835.dak-commands to ssh-upload
>
> Enjoy!

Thanks, Nilesh!

However, since Jerome also responded, I'll hold off on uploading for now.

Bug#994880: bullseye-pu: package ulfius/2.7.1-1

[Nicolas Mora]

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

Fix CVE-2021-40540 in Bullseye

[ Reason ]
Ulfius package contains the bug that is rewferred by CVE-2021-40540

[ Impact ]
Application segfault when a malformed http request is received

[ Tests ]
none

[ Risks ]
the patch is trivial, the risk is low

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
add 'memset(con_info, 0, sizeof(struct connection_info_struct));' after
con_info is malloced to initialize the structure and avoid testing an undefined
value.

[ Other info ]
(Anything else the release team should know.)
diff -Nru ulfius-2.7.1/debian/changelog ulfius-2.7.1/debian/changelog
--- ulfius-2.7.1/debian/changelog   2021-01-03 09:03:05.0 -0500
+++ ulfius-2.7.1/debian/changelog   2021-09-19 15:39:39.0 -0400
@@ -1,3 +1,9 @@
+ulfius (2.7.1-1+deb11u1) bullseye; urgency=medium
+
+  * d/patches: Fix CVE-2021-40540 (Closes: #994763)
+
+ -- Nicolas Mora   Sun, 19 Sep 2021 15:39:39 -0400
+
 ulfius (2.7.1-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru ulfius-2.7.1/debian/patches/CVE-2021-40540.patch 
ulfius-2.7.1/debian/patches/CVE-2021-40540.patch
--- ulfius-2.7.1/debian/patches/CVE-2021-40540.patch1969-12-31 
19:00:00.0 -0500
+++ ulfius-2.7.1/debian/patches/CVE-2021-40540.patch2021-09-19 
15:39:20.0 -0400
@@ -0,0 +1,13 @@
+Description: Fix CVE-2021-40540
+Author: Nicolas Mora 
+Forwarded: not-needed
+--- a/src/ulfius.c
 b/src/ulfius.c
+@@ -207,6 +207,7 @@
+   UNUSED(cls);
+ 
+   if (con_info != NULL) {
++memset(con_info, 0, sizeof(struct connection_info_struct));
+ con_info->callback_first_iteration = 1;
+ con_info->u_instance = NULL;
+ u_map_init(_info->map_url_initial);
diff -Nru ulfius-2.7.1/debian/patches/series ulfius-2.7.1/debian/patches/series
--- ulfius-2.7.1/debian/patches/series  2021-01-03 09:03:05.0 -0500
+++ ulfius-2.7.1/debian/patches/series  2021-09-19 15:39:39.0 -0400
@@ -1,2 +1,3 @@
 examples.patch
 doc.patch
+CVE-2021-40540.patch

Bug#917103: dh_elpa_test: test bytecompilability

[David Bremner]

Sean Whitton  writes:

> On Tue 21 Sep 2021 at 01:26PM -03, David Bremner wrote:
>>
>> As long as Testsuite: autopkgtest-pkg-elpa is present in debian/control,
>> the binary packages are installed and hence byte compiled. Until the
>> upload 20210916git0-2, racket-mode [1] had this configuration with
>> Testsuite defined, but disabled in debian/elpa-test.
>>
>> [1]: 
>> https://ci.debian.net/data/autopkgtest/testing/amd64/r/racket-mode/15323474/log.gz
>
> Oh great, and if that installation fails the autopkgtest is considered
> to fail?

Yes, confirmed with debci team, any postinst failure will be (hard) fail
as opposed to network problems which tmpfail.

d

Bug#868861: High priority

[Michiel Hazelhof]

Can we set this bug to high priority?

This is a sneaky bug that causes instances to get whacked by systemd and
causes random dropouts that are (very) hard to diagnose depending on the
users skill level.

-- 
With regards,

Michiel Hazelhof.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#994869: Bug in gnulib parse-datetime?

[Lars Kindermann]

The difference when using "T" as seperator is 7 hours.

GNU date.c uses parse-datetime from gnulib:
https://github.com/coreutils/gnulib/blob/master/lib/parse-datetime.y

There is a definition of a

/* Military time zone table.
   RFC 822 got these backwards, but RFC 5322 makes the incorrect
   treatment optional, so do them the right way here.
   Note 'T' is a special case, as it is used as the separator in ISO
   8601 date and time of day representation.  */

static table const military_table[] =
{
  { "A", tZONE,  HOUR ( 1) },
  { "B", tZONE,  HOUR ( 2) },
...
  { "S", tZONE, -HOUR ( 6) },
  { "T", 'T',0 },
  { "U", tZONE, -HOUR ( 8) },
  { "V", tZONE, -HOUR ( 9) },
  { "W", tZONE, -HOUR (10) },
  { "X", tZONE, -HOUR (11) },
  { "Y", tZONE, -HOUR (12) },
  { "Z", tZONE,  HOUR ( 0) },
  { NULL, 0, 0 }
};

So probably the "T" is incorrectly interpreted as a "Military time zone 
offset" instead of a delimiter.

Bug#994741: regression tests: skipped vs failed

[Mattia Rizzolo]

On Wed, Sep 22, 2021 at 03:31:36PM +0300, Andrius Merkys wrote:
> On 2021-09-21 20:03, Mattia Rizzolo wrote:
> > Then, concerning the ftbfs of 1.1.  I know of it of course.  Just that
> > I've been busy over the past month.  I'm as weirded out by that test
> > failure as you, especially since I couldn't reproduce it anywhere else.
> > But no, I'm not going to ignore a test failure just because it's skipped
> > in other architectures for different reasons: I'll need more convincing
> > reasons.
> 
> Thanks Mattia for letting us know you are working on it. Have you tried
> building inkscape with network disabled?

?? of course.  that's basically standard building env for me since I
use pbuilder.  by contrast, know that the debian buildds do *not*
disable the network.

Anyway, I'm first going to upload 1.1.1 to experimental today and see
how that goes, otherwise I'm going to start debugging more.

There is also another failure I need to take care of, as building in
ubuntu exposed an unaligned memory access that causes bus errors in
armhf (when run in a arm64 cpu).

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#980300: libcbor: Please upgrade to new version 0.8.0

[Vincent Bernat]

 ❦ 21 September 2021 14:54 -04, Nicolas Mora:

> Friendly ping request for this bug.
> If you need help, I'll be happy to help you with this upgrade.

Done. It is waiting in NEW.
-- 
Identify bad input; recover if possible.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#994770: RFS: binutils-m68hc1x/1:3 -- GNU binary utilities for Motorola's 68HC11/12 targets

[Adam Borowski]

On Mon, Sep 20, 2021 at 07:16:30PM +0200, Vincent Smeets wrote:
>  * Package name: binutils-m68hc1x

> Changes since the last upload:
> 
>  binutils-m68hc1x (1:3) unstable; urgency=medium
>  .
>* Repackaged as a native package based on binutils-source (Closes: #982848)

Fails to build with:

cd obj-x86_64-linux-gnu && ../src/configure --build=x86_64-linux-gnu 
--prefix=/usr --includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-option-checking --disable-silent-rules 
--libdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run 
--disable-maintainer-mode --disable-dependency-tracking --target=m68hc11 
--libdir=\${prefix}/lib/m68hc11 --with-bugurl=https://www.debian.org/Bugs/ 
--with-system-zlib --with-pkgversion=1:2.37\+3 --enable-deterministic-archives 
--enable-targets=m68hc11,m68hc12
configure: error: unrecognized option: `--runstatedir=/run'


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ If you ponder doing what Jesus did, remember than flipping tables
⢿⡄⠘⠷⠚⠋⠀ and chasing people with a whip is a prime choice.
⠈⠳⣄

Bug#993269: RFS: e-antic 0.1.8+ds-2

[Nilesh Patra]

On Wed, 22 Sept 2021 at 16:49, Torrance, Douglas 
wrote:

> Control: tags -1 pending
>
> e-antic and its reverse dependencies (macaulay2, normaliz, polymake,
> pynac, and
> singular) are currently scheduled for autoremoval on 2021-10-12 due to RC
> bug
> #993269.  Peter Green tracked down a fix and submitted a patch, which I've
> pushed to Salsa, along with a couple other minor things.
>
> Would anyone be able to review/sponsor, or alternatively, grant me DM
> upload
> permissions for e-antic?
>

$ dcut ssh-upload dm --uid dtorra...@piedmont.edu --allow e-antic

Uploading commands file to ssh.upload.debian.org (incoming: /srv/
upload.debian.org/UploadQueue/)
Picking DM Doug Torrance  with fingerprint
803CE41F4DC252ECB5E5F1B9D12B2BE26D3FF663
SCP is deprecated. Please consider upgrading to SFTP.
Uploading nilesh-1632314835.dak-commands to ssh-upload

Enjoy!

Bug#965947: lintian: uses-dpkg-database-directly no longer detected for python3-reportbug

[Felix Lechner]

Control: lintian: Extract string constants from interpreter scripts and modules

Hi Nis,

On Sat, Sep 4, 2021 at 7:21 AM Nis Martensen  wrote:
>
> The content of the python module files is not checked.

Sorry I took so long. Your bug is real, but I am not clear about the
best solution.

The change in behavior was probably introduced when I rewrote the file
indices to reside in memory. Among other things, I made the code more
"literate" in the sense that routines now have names that resemble
more closely what they do. Twenty-two years of collective patching had
led to a bit of a jumble.

>From other, more prominent parts of the code I had decided that
scripts were executable files with a hashbang. We devote a whole check
to them. It is called 'scripts'.

For your package python3-reportbug, the change resulted in a loss of
functionality. I am not sure, however, that the best fix is to simply
add *.py files—without an executable flag or a hashbang—to the
definition of a script.

For ELF executables, Lintian looks at the equivalent of 'nm' strings.
It is not perfect but avoids confusion with documentation or code
comments.

We struggle with the issue of script parsing in other parts of
Lintian, too. (See open bugs.) For this bug, I would really like to
use a Python parser that extracts string constants from Python modules
under /usr/lib/python3/dist-packages/. I would also like to find
similar solutions for other scripting languages—especially for Perl.

Thank you for your diligent maintainership, and especially for this report!

Kind regards
Felix Lechner

Bug#994741: regression tests: skipped vs failed

[Andrius Merkys]

On 2021-09-21 20:03, Mattia Rizzolo wrote:
> Then, concerning the ftbfs of 1.1.  I know of it of course.  Just that
> I've been busy over the past month.  I'm as weirded out by that test
> failure as you, especially since I couldn't reproduce it anywhere else.
> But no, I'm not going to ignore a test failure just because it's skipped
> in other architectures for different reasons: I'll need more convincing
> reasons.

Thanks Mattia for letting us know you are working on it. Have you tried
building inkscape with network disabled?

Andrius

Bug#988696: connman does not respect /etc/network/interfaces when upgrading from buster to bullseye and more general considerations

[Andreas Tille]

Hi,

I'd like to draw the attention of debian-devel to the problem below
(reported ad bug #994875) which breaks certain systems on upgrades.

As I described in bug #988696 which boils down to my last message to
this bug report where I wrote "No idea how to configure network easily
after fresh lxde install."  This means:  Even an experienced user like
me does not obviously find easy access to a very important feature of a
fresh installation to login to a network.

My reason to bring this up on debian devel is that I have the feeling
that while we provide lots of different desktops in dedicated images the
general QA how useful these might be is left to the maintainers of this
desktop who probably have a focussed view and do not realise what
hurdles newcomers might need to take.

My other point is that we here have another case where the freedom of
choice of tools to use leads to non-default behaviour.  I simply assumed
that network-manager would be some kind of default and if it would be
used in lxde task those two problems would not have happened.  So my
suggestion is to propose some set of default tools for every desktop
environment we are providing and network configuration should be part of
it.  (I admit I also had trouble with wicd which until some point of
time was installed as default with xfce4 installer media - no idea
whether this is the case any more - my arguing would be the same here.)

Kind regards

 Andreas.

PS: I also CCed debian-desktop list.  If you feel the discussion
should happen there please CC me since I'm not subscribed to
that list.

On Wed, Sep 22, 2021 at 01:09:17PM +0200, Andreas Tille wrote:
> Package: connman
> Version: 1.36-2.2
> Severity: important
> 
> Hi,
> 
> recently I was upgrading a workstation running buster to bullseye from
> remote.  This box had a fixed IP set in /etc/network/interfaces.  After
> a rebooting I've "lost" the machine and I had to check the machine
> physicaly.  It was asking for a totally different IP address via DHCP.
> I found out that connman was installed on this machine due to lxde
> metapackage Recommends.  After simply purging connman which is not used
> anyway all went fine on this machine.
> 
> I would have loved to track this down in more detail but this
> workstation is mission critical and there is no option to bother users
> with fiddling around on the system that is now running as expected
> again.  I'm fine with digging in the logs if you tell me what kind of
> information is needed.
> 
> Kind regards
> Andreas.
> 
> 
> -- System Information:
> Debian Release: 11.0
>   APT prefers testing
>   APT policy: (501, 'testing'), (50, 'buildd-unstable'), (50, 'unstable'), 
> (5, 'experimental'), (1, 'buildd-experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
> LANGUAGE=de_DE:de
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages connman depends on:
> ii  dbus 1.12.20-2
> ii  init-system-helpers  1.60
> ii  iptables 1.8.7-1
> ii  libc62.31-13
> ii  libdbus-1-3  1.12.20-2
> ii  libglib2.0-0 2.68.4-1
> ii  libgnutls30  3.7.1-5
> ii  libreadline8 8.1-1
> ii  libxtables12 1.8.7-1
> ii  lsb-base 11.1.0
> 
> Versions of packages connman recommends:
> pn  bluez  
> pn  ofono  
> ii  wpasupplicant  2:2.9.0-21
> 
> Versions of packages connman suggests:
> pn  connman-vpn  
> 
> 

-- 
http://fam-tille.de

Bug#994879: sssd: SSSD requirement for CLDAP support in libldap should be optional, fail to get groups from AD

[Sven Probst]

Package: sssd
Version: 2.4.1-2
Severity: normal
Tags: upstream

Dear Maintainer,

   after joining my computer to an active directory, users are visible
   as expected but groups are not resolved.

   sssd-log shows an error like this:
   [sss_ldap_init_sys_connect_done] (0x0020): ldap_init_fd failed: Bad
parameter to an ldap routine. [27][cldap://xxx.xxx.xxx:389]

   Applying the upstream-patch https://github.com/SSSD/sssd/pull/5743 
to
   the bullseye-sssd-src fixes this problem for me. Could you please
   include this patch?

Thank you..

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

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

Versions of packages sssd depends on:
ii  python3-sss  2.4.1-2
ii  sssd-ad  2.4.1-2
ii  sssd-common  2.4.1-2
ii  sssd-ipa 2.4.1-2
ii  sssd-krb52.4.1-2
ii  sssd-ldap2.4.1-2
ii  sssd-proxy   2.4.1-2

sssd recommends no packages.

sssd suggests no packages.

-- no debconf information

Bug#994775: flowblade: No module name 'mlt'

[Eric Collins]

I have tried this fix and the application now opens, but for some reason fade 
ins/outs don't appear to be working anymore. They seem to be completely 
ignored. I've only tested this on one machine, but will test another soon.

On Tue, Sep 21, 2021, at 08:59, Alexandre Lymberopoulos wrote:
> Thank you, Gürkan!
>
> Your solution provides a local fix for the problem. I think it may work
> as a fixz when packaging, right?
>
> Best, Alexandre
>
> On Sep 20 2021, Gürkan Myczko wrote:
>> solution is here:
>> 
>> https://github.com/jliljebl/flowblade/issues/1016
>> 
>> sorry for the issue will try to fix
>> 
>> 
>> > On 20 Sep 2021, at 21:03, Alexandre Lymberopoulos  wrote:
>> > 
>> > Package: flowblade
>> > Version: 2.8.0.3-2
>> > Severity: grave
>> > Justification: renders package unusable
>> > 
>> > Dear Maintainer,
>> > 
>> > When I tried to open flowblade from terminal in my XFCE session I get the 
>> > following:
>> > 
>> > FLOWBLADE MOVIE EDITOR 2.8
>> > --
>> > Launch script dir: /usr/bin
>> > Running from installation...
>> > modules path: /usr/share/flowblade/Flowblade
>> > MLT not found, exiting...
>> > ERROR: No module named 'mlt'
>> > 
>> > But it seems that all the dependencies are installed here. I may provide 
>> > any further information upon request and guidance.
>> > 
>> > Thanks in advance and best regards, Alexandre
>> > 
>> > -- System Information:
>> > Debian Release: bookworm/sid
>> >  APT prefers testing
>> >  APT policy: (900, 'testing'), (800, 'unstable')
>> > Architecture: amd64 (x86_64)
>> > 
>> > Kernel: Linux 5.10.0-8-rt-amd64 (SMP w/4 CPU threads; PREEMPT)
>> > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
>> > LANGUAGE=en_US:en
>> > Shell: /bin/sh linked to /bin/dash
>> > Init: systemd (via /run/systemd/system)
>> > 
>> > Versions of packages flowblade depends on:
>> > ii  frei0r-plugins1.7.0-1
>> > ii  gir1.2-gdkpixbuf-2.0  2.42.6+dfsg-2
>> > ii  gir1.2-glib-2.0   1.68.0-2
>> > ii  gir1.2-gtk-3.03.24.30-3
>> > ii  gir1.2-pango-1.0  1.48.9+ds1-2
>> > ii  gmic  2.9.4-4
>> > ii  libmlt-data   7.0.1-3
>> > ii  librsvg2-common   2.50.3+dfsg-1
>> > ii  python3   3.9.2-3
>> > ii  python3-cairo 1.16.2-4+b2
>> > ii  python3-dbus  1.2.18-2
>> > ii  python3-distutils 3.9.7-1
>> > ii  python3-gi3.40.1-2
>> > ii  python3-gi-cairo  3.40.1-2
>> > ii  python3-mlt   7.0.1-3
>> > ii  python3-numpy 1:1.19.5-1
>> > ii  python3-opencv4.5.3+dfsg-1+b1
>> > ii  python3-pil   8.1.2+dfsg-0.3
>> > ii  swh-plugins   0.4.17-2
>> > 
>> > flowblade recommends no packages.
>> > 
>> > flowblade suggests no packages.
>> > 
>> > -- no debconf information
>> > 
>
> -- 
> ===
> Alexandre Lymberopoulos - lym...@gmail.com
> ===
>
> -- 
> To unsubscribe, send mail to 994775-unsubscr...@bugs.debian.org.