Bug#1029594: Fails to authenticate mit o365

[Klaus Ethgen]

Package: thunderbird
Version: 1:102.7.1-1
Severity: important

After upgrading from 1:102.6.0-1 this morning, thunderbird fails to
login into microsoft o365, making it impossible to access mails from
that account.

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

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

Versions of packages thunderbird depends on:
ii  debianutils  5.7-0.4
ii  fontconfig   2.14.1-3
ii  libasound2   1.2.8-1+b1
ii  libatk1.0-0  2.46.0-4
ii  libc62.36-8
ii  libcairo-gobject21.16.0-7
ii  libcairo21.16.0-7
ii  libdbus-1-3  1.14.4-1devuan1
ii  libdbus-glib-1-2 0.112-3
ii  libevent-2.1-7   2.1.12-stable-5+b1
ii  libffi8  3.4.4-1
ii  libfontconfig1   2.14.1-3
ii  libfreetype6 2.12.1+dfsg-4
ii  libgcc-s112.2.0-14
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.5-1
ii  libgtk-3-0   3.24.36-2
ii  libicu72 72.1-3
ii  libnspr4 2:4.35-1
ii  libnss3  2:3.87-1
ii  libpango-1.0-0   1.50.12+ds-1
ii  librnp0  0.16.2-1
ii  libstdc++6   12.2.0-14
ii  libvpx7  1.12.0-1
ii  libx11-6 2:1.8.3-3
ii  libx11-xcb1  2:1.8.3-3
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxext6 2:1.3.4-1+b1
ii  libxrandr2   2:1.5.2-2+b1
ii  psmisc   23.6-1
ii  x11-utils7.7+5
ii  zenity   3.43.0-1
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages thunderbird recommends:
ii  hunspell-de-ch [hunspell-dictionary]  20161207-11
ii  hunspell-de-de [hunspell-dictionary]  20161207-11

Versions of packages thunderbird suggests:
pn  apparmor  
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.20.1-1

-- Configuration Files:
/etc/thunderbird/pref/thunderbird.js changed:
// This is the Debian specific preferences file for Mozilla Thunderbird
// You can make any change in here, it is the purpose of this file.
// You can, with this file and all files present in the directory
//
//  /etc/thunderbird/pref directory
//
// override any preference that is present in the directory
//
//  /usr/lib/thunderbird/defaults/pref
//
// While your changes will be kept on upgrade if you modify files in
// /etc/thunderbird/pref, please note that they won't be kept if you
// do them in /usr/lib/thunderbird/defaults/pref.
pref("extensions.update.enabled", false, sticky);
// Use LANG environment variable to choose locale from system
// The old environment setting 'pref("intl.locale.matchOS", true);' is
// currently not working anymore. The new introduced setting
// 'intl.locale.requested' is now used for this. Setting an empty string is
// pulling the system locale into Thunderbird.
pref("intl.locale.requested", "");
// Disable default mail checking (gnome).
pref("mail.shell.checkDefaultMail", false, locked);
// Disable default mail client check
pref("mail.shell.checkDefaultClient", false, locked);
// if you are not using gnome
pref("network.protocol-handler.app.http", "x-www-browser");
pref("network.protocol-handler.app.https", "x-www-browser");
// This setting is a workaround for some crashes inside the JS engine.
// By this Thunderbird will use more memory and acting slower as the sharing
// memory between interacting JS files is disabled.
pref("javascript.options.baselinejit", false);
// Uncomment the follwing setting if you want to have a extra mail header field
// for X-Debbugs-Cc, only needed in case you have to work with the Debian
// Bug Tracking System more deeply
//pref("mail.compose.other.header", "X-Debbugs-Cc");
pref("datareporting.healthreport.uploadEnabled", false, locked);
pref("mail.mdn.report.enabled", false);
pref("mail.openpgp.allow_external_gnupg", true);
pref("mail.phishing.detection.enabled", false, locked);
pref("network.cookie.cookieBehavior", 2);
pref("network.cookie.lifetimePolicy", 2);
pref("security.OCSP.enabled", 0, locked);
// Empfehlungen von kuketz
pref("general.useragent.override", "", locked);
pref("mail.smtpserver.default.hello_argument", "[127.0.0.1]", locked);
pref("javascript.enabled", false);
pref("security.tls.enable_0rtt_data", false, locked);
pref("mailnews.headers.showUserAgent", true);
pref("mailnews.headers.showSender", true);
pref("mail.showCondensedAddresses", false);


-- no debconf information

-- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C


signature.asc
Description: PGP signature

Bug#1029593: nibabel: (armel autopkgtest) needs update for NumPy 1.24

[Graham Inggs]

Source: nibabel
Version: 4.0.2-1
Severity: serious
User: debian...@lists.debian.org
Usertags: needs-update

Hi Maintainer

The autopkgtests of nibabel fail with NumPy 1.24 on armel [1].  I've
copied what I hope is the relevant part of the log below.

Regards
Graham


[1] https://ci.debian.net/packages/n/nibabel/testing/armel/


=== FAILURES ===
___ test_a2f_nan2zero_range 

def test_a2f_nan2zero_range():
# array_to_file should check if nan can be represented as zero
# This comes about when the writer can't write the value (-intercept /
# divslope) because it does not fit in the output range.  Input clipping
# should not affect this
fobj = BytesIO()
# No problem for input integer types - they don't have NaNs
for dt in INT_TYPES:
arr_no_nan = np.array([-1, 0, 1, 2], dtype=dt)
# No errors from explicit thresholding (nor for input float types)
back_arr = write_return(arr_no_nan, fobj, np.int8, mn=1,
nan2zero=True)
assert_array_equal([1, 1, 1, 2], back_arr)
back_arr = write_return(arr_no_nan, fobj, np.int8, mx=-1,
nan2zero=True)
assert_array_equal([-1, -1, -1, -1], back_arr)
# Pushing zero outside the output data range does not generate error
back_arr = write_return(arr_no_nan, fobj, np.int8,
intercept=129, nan2zero=True)
assert_array_equal([-128, -128, -128, -127], back_arr)
back_arr = write_return(arr_no_nan, fobj, np.int8,
intercept=257.1, divslope=2, nan2zero=True)
assert_array_equal([-128, -128, -128, -128], back_arr)
for dt in CFLOAT_TYPES:
arr = np.array([-1, 0, 1, np.nan], dtype=dt)
# Error occurs for arrays without nans too
arr_no_nan = np.array([-1, 0, 1, 2], dtype=dt)
complex_warn = (np.ComplexWarning,) if np.issubdtype(dt,
np.complexfloating) else ()
# Casting nan to int will produce a RuntimeWarning in numpy 1.24
nan_warn = (RuntimeWarning,) if FP_RUNTIME_WARN else ()
c_and_n_warn = complex_warn + nan_warn
# No errors from explicit thresholding
# mn thresholding excluding zero
with pytest.warns(complex_warn) if complex_warn else
error_warnings():
assert_array_equal([1, 1, 1, 0],
   write_return(arr, fobj, np.int8, mn=1))
# mx thresholding excluding zero
with pytest.warns(complex_warn) if complex_warn else
error_warnings():
assert_array_equal([-1, -1, -1, 0],
   write_return(arr, fobj, np.int8, mx=-1))
# Errors from datatype threshold after scaling
with pytest.warns(complex_warn) if complex_warn else
error_warnings():
back_arr = write_return(arr, fobj, np.int8, intercept=128)
assert_array_equal([-128, -128, -127, -128], back_arr)
with pytest.raises(ValueError):
write_return(arr, fobj, np.int8, intercept=129)
with pytest.raises(ValueError):
write_return(arr_no_nan, fobj, np.int8, intercept=129)
# OK with nan2zero false, but we get whatever nan casts to
>   with pytest.warns(c_and_n_warn) if c_and_n_warn else 
> error_warnings():
E   Failed: DID NOT WARN. No warnings of type (,) were emitted.
E   The list of emitted warnings is: [].

nibabel/tests/test_volumeutils.py:700: Failed

Bug#1029516: Small patch

[Georg Gast]

Needed i just a small patch that makes it at least usable.

https://github.com/Steveorevo/phppgadmin/commit/6ae0b7b99b34adb85d253a0c545a220c54180f8e

Bug#1027915: systemd requires /run to be mounted with a minimum size of 20MB

[Helmut Grohne]

Hi Helge,

On Tue, Jan 24, 2023 at 10:30:37PM +0100, Helge Deller wrote:
> On 1/24/23 06:27, Helmut Grohne wrote:
> > On Mon, Jan 23, 2023 at 10:48:27PM +0100, Helge Deller wrote:
> > > --- ./init.org2023-01-23 21:40:33.079738389 +
> > > +++ ./init2023-01-23 21:40:45.983861851 +
> > > @@ -205,6 +205,15 @@ else
> > >   resume=${RESUME:-}
> > >   fi
> > > 
> > > +if [ -z "${RUNSIZE}" ] || [[ "${RUNSIZE}" \< "20" ]]; then
> > 
> > This is as bashism and init runs with dash as far as I can see.
> 
> Hmm... I did tested it, at it seemed to work...
> Which part of that line exactly do you think is problematic?
> I'm open for any other idea how to code it.

The lexicographic comparison is outside the realm of POSIX shell, but to
my surprise this actually is supported by dash. So fixing this would be
academic.

> Both will work, because I assume that on such systems you probably have more 
> than 200MB RAM
> and thus my patch won't touch the user-provided value at all.

Fair enough.

> > > + read MemTotal mem_kb rest < /proc/meminfo
> > > + # systemd requires at minumum 16MB for /run, so reserve
> > > + # 20MB for machines which have less than 200MB RAM
> > > + if [ "$mem_kb" -lt "20" ]; then
> > > + RUNSIZE=20M # for machines <= 200MB RAM

else
: "${RUNSIZE:=10%}"

> > 
> > Given that you initialize a default here, I think it would make the code
> > more obvious if you pulled the 10% default 4 lines later into an else
> > branch.
> 
> Not sure I understand this...?
> 
> > > + fi
> > > +fi
> > > +
> > >   mount -t tmpfs -o "nodev,noexec,nosuid,size=${RUNSIZE:-10%},mode=0755" 
> > > tmpfs /run

This is the other line that contains a default. I suggested moving this
default up to make it more obvious, but this is really only a cosmetic
improvement.

As such LGTM, but I am not an initramfs maintainer.

Helmut

Bug#1029063: anbox-binder issues reported to src:linux/src:dkms

[Aron Xu]

Control: severity -1 normal

dkms never risks creating an unbootable environment by exiting with an
error during the configuration of the corresponding linux-image-*
package when a module fails to build. Even though it looks annoying
when the failing dkms packages are not-so-critical to booting the
system, dkms has no knowledge about which package is critical and
which is less harmful.

I'm downgrading the issue to normal severity to allow more discussion
on possible better handling of such cases in the future.

For anbox-binder users who are reporting this issue to
src:linux/src:dkms on sid/testing, please look for updating the source
if it's very useful to you and hold the linux-image-* package for a
while, or remove it to allow upgrading to newer version of linux
packages for the moment.

Regards,
Aron

Bug#1029592: ITP: libtie-cycle-sinewave-perl -- mechanism to cycle through a series of values on a sinewave

[mtj]

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libtie-cycle-sinewave-perl
  Version : 0.05
  Upstream Author : David Landgren
* URL : https://metacpan.org/release/Tie-Cycle-Sinewave
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : mechanism to cycle through a series of values on a sinewave

Tie::Cycle::Sinewave allows you to make a scalar iterate through the values on
a sinewave. You set the maximum and minimum values and the number of steps and
you're set.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1029591: alot: traceback when pressing H on shown headers

[Paul Wise]

Package: alot
Version: 0.10-1
Severity: normal
Usertags: crash

When I open a message, press H to show the headers, then scroll down
into the headers, then press H again within the headers, then I get a
crash of alot with the following Python traceback. This could be a bug
in urwid or it could be a bug in alot allowing something it shouldn't,
please reassign it to the appropriate package.

   $ alot
   Traceback (most recent call last):
 File "/usr/bin/alot", line 33, in 
   sys.exit(load_entry_point('alot==0.10', 'console_scripts', 'alot')())
 File "/usr/share/alot/alot/__main__.py", line 137, in main
   UI(dbman, cmdstring)
 File "/usr/share/alot/alot/ui.py", line 146, in __init__
   self.mainloop.run()
 File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 287, in run
   self._run()
 File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 385, in _run
   self.event_loop.run()
 File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 1346, in run
   reraise(*exc_info)
 File "/usr/lib/python3/dist-packages/urwid/compat.py", line 58, in reraise
   raise value
 File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 1360, in 
wrapper
   rval = f(*args,**kargs)
 File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 1319, in 
_twisted_idle_callback
   callback()
 File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 574, in 
entering_idle
   self.draw_screen()
 File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 588, in 
draw_screen
   canvas = self._topmost_widget.render(self.screen_size, focus=True)
 File "/usr/lib/python3/dist-packages/urwid/widget.py", line 145, in 
cached_render
   canv = fn(self, size, focus=focus)
 File "/usr/lib/python3/dist-packages/urwid/decoration.py", line 226, in 
render
   canv = self._original_widget.render(size, focus=focus)
 File "/usr/lib/python3/dist-packages/urwid/widget.py", line 145, in 
cached_render
   canv = fn(self, size, focus=focus)
 File "/usr/lib/python3/dist-packages/urwid/container.py", line 1089, in 
render
   body = self.body.render((maxcol, maxrow-ftrim-htrim),
 File "/usr/share/alot/alot/buffers/thread.py", line 138, in render
   return self.body.render(size, focus)
 File "/usr/lib/python3/dist-packages/urwid/widget.py", line 145, in 
cached_render
   canv = fn(self, size, focus=focus)
 File "/usr/lib/python3/dist-packages/urwid/widget.py", line 1761, in render
   canv = get_delegate(self).render(size, focus=focus)
 File "/usr/lib/python3/dist-packages/urwid/widget.py", line 145, in 
cached_render
   canv = fn(self, size, focus=focus)
 File "/usr/lib/python3/dist-packages/urwid/listbox.py", line 439, in render
   middle, top, bottom = self.calculate_visible(
 File "/usr/lib/python3/dist-packages/urwid/listbox.py", line 322, in 
calculate_visible
   self._set_focus_complete( (maxcol, maxrow), focus )
 File "/usr/lib/python3/dist-packages/urwid/listbox.py", line 703, in 
_set_focus_complete
   middle,top,bottom=self.calculate_visible((maxcol,maxrow),focus)
 File "/usr/lib/python3/dist-packages/urwid/listbox.py", line 325, in 
calculate_visible
   focus_widget, focus_pos = self._body.get_focus()
 File "/usr/lib/python3/dist-packages/urwidtrees/widgets.py", line 75, in 
get_focus
   return self._get(self._focus)
 File "/usr/lib/python3/dist-packages/urwidtrees/widgets.py", line 68, in 
_get
   res = self[pos], pos
 File "/usr/lib/python3/dist-packages/urwidtrees/widgets.py", line 54, in 
__getitem__
   entry = self._tree.get_decorated(pos)
 File "/usr/lib/python3/dist-packages/urwidtrees/nested.py", line 88, in 
get_decorated
   return self._get_decorated_entry(self._tree, pos)
 File "/usr/lib/python3/dist-packages/urwidtrees/nested.py", line 84, in 
_get_decorated_entry
   entry = tree.decorate(pos[0], entry, is_first=isf)
 File "/usr/lib/python3/dist-packages/urwidtrees/decoration.py", line 472, 
in decorate
   line = urwid.Columns(cols, box_columns=range(len(cols))[:-1])
 File "/usr/lib/python3/dist-packages/urwid/container.py", line 1787, in 
__init__
   self.contents.append((w, (WEIGHT, 1, i in box_columns)))
 File "/usr/lib/python3/dist-packages/urwid/monitored_list.py", line 384, 
in append
   rval = super(MonitoredFocusList, self).append(item)
 File "/usr/lib/python3/dist-packages/urwid/monitored_list.py", line 30, in 
call_modified_wrapper
   self._modified()
 File "/usr/lib/python3/dist-packages/urwid/container.py", line 1821, in 
_contents_modified
   self._selectable = any(w.selectable() for w, o in self.contents)
 File "/usr/lib/python3/dist-packages/urwid/container.py", line 1821, in 

   self._selectable = any(w.selectable() for w, o in self.contents)
   AttributeError: 'NoneType' object has no attribute 'selectable'

-- 

Bug#1029590: ITP: libcolor-spectrum-perl -- Perl module for generating HTML colors

[mtj]

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libcolor-spectrum-perl
  Version : 1.14
  Upstream Author : Jeff Anderson 
* URL : https://metacpan.org/release/Color-Spectrum
* License : Artistic-2.0
  Programming Lang: Perl
  Description : Perl module for generating HTML colors

Color::Spectrum is a module to make spectrums of colors for web page table
tags. It uses a real simple geometric conversion that gets the job done. It
can shade from dark to light, from saturated to dull, and around the
spectrum all at the same time. It can go thru the spectrum in either direction.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1029476: tuxguitar: arch-any build fails with current build system

[tony mancill]

Hi Helmar,

On Mon, Jan 23, 2023 at 10:39:52PM +0100, Helmar Gerloni wrote:
> According to the log the error happens at
> 
> Command: dpkg-buildpackage --sanitize-env -us -uc -mamd64 / i386 Build Daemon 
> (x86-ubc-01)  -B -rfakeroot 
> --changes-option=-O../tuxguitar_1.5.6+dfsg1-3_amd64-buildd.changes 
> --buildinfo-option=-O../tuxguitar_1.5.6+dfsg1-3_amd64-buildd.buildinfo
> ...
> cat: debian/tuxguitar-alsa.poms: No such file or directory
> ...
> 
> The same error also happens on my laptop. After adding the link
> 
> ln -s tuxguitar.poms debian/tuxguitar-alsa.poms
> 
> dpkg-buildpackage works. Maybe this could be a workaround?

Thanks!  I will give that a try.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#1024177: Cannot use jekyll-feed plugin due to incompatibility?

[Daniel Leidert]

Hi,

this issue was caused by an upload of ruby-liquid not compatible with Jekyll 3.
The latest Jekyll release has just entered Debian Sid and this problem has been
resolved. I'm going to close this report.

Regards, Daniel
-- 
Regards,
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

https://www.fiverr.com/dleidert
https://www.patreon.com/join/dleidert


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

Bug#1029588: bts: Changes in libio-socket-ssl-perl 2.078 make bts fail to send mail to mail-server via SSL/TLS - hostname verification failed

[Daniel Leidert]

Package: devscripts
Version: 2.22.2
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

I'm running a mail server. The server is using wildcard-certificates issued by
letsencrypt (but the same issue happens with a dedicated certificate). Since
the last update of libio-socket-ssl-perl, whenever I try to send mails via the
bts command, I receive the following error:

bts: failed to open SMTPS connection to smtps://mail.wgdd.de
(hostname verification failed)

Same happens if I use TLS. I checked the certificates and I cannot find any
issues. All other tools work well. If I downgrade libio-socket-ssl-perl to
version 2.077-1, everything works fine. The main change between versions 2.077
and 2.078 in libio-socket-ssl-perl is:

2.078 2022/12/11
- - revert decision from 2014 to not verify hostname by default if hostname is
  IP address but no explicit verification scheme given
  https://github.com/noxxi/p5-io-socket-ssl/issues/121

I found some hints, that Net::SMTPS, used by bts, does not support
SSL_verifycn_scheme smtp.  But this is not my expertise. I'd just like to see
bts fixed and being able to send mail to a mailserver via SSL/TLS.

Issues with SSL support in bts have come up multiple times. I remember, that I
even had to patch some code myself in the past to make it work. There are even
now patches (e.g. #853991), which might improve the situation. But like this,
bts is unusable.

Regards, Daniel



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

Kernel: Linux 6.1.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 libio-socket-ssl-perl depends on:
ii  libnet-ssleay-perl  1.92-2+b1
ii  netbase 6.4
ii  perl5.36.0-7

Versions of packages libio-socket-ssl-perl recommends:
pn  libio-socket-ip-perl | libio-socket-inet6-perl  
ii  libnet-idn-encode-perl  2.500-3+b1
ii  libnet-libidn-perl  0.12.ds-4+b1
ii  liburi-perl 5.17-1
ii  perl-base [libsocket-perl]  5.36.0-7

Versions of packages libio-socket-ssl-perl suggests:
ii  ca-certificates  20211016

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmPQmXwACgkQS80FZ8KW
0F1P+hAA1KcFh8/lqTRkrrL85H0vGbr82KNFvNRLGwqOyzL9N4vLjfIedlt+hzbU
6/YzRznl5dCzTHCwju4BYyZfrpo6NPPtfLjjwPRtajwUnbw3Q9INGACTupkTtwoC
eKCFQM2dpGODERD1zjPN16iBfoGc97pWzE3nCZpxUFZxhKTKw78tpmbr7LMnHx2j
DKXAJgejlmhtYxVLk9YKynLR0x8MoSNlYRB1T7hdoQt0lo5KnbQbEsZjlXSg9AFb
8I/T29YO9n2dA2litq4RMVONtDN9p1YyCsY+fBO8RUnLS6v+Wy+vCEhwBYPm/dQp
DajXqxmWwU94oMF3UT8NuvgGW2OCWOhbrpFaSRRnGctXoTHTzJ/D7qMza5Qakdxh
SdORO9d5LRAwFDti54zx9c62Z42wUn2P7tIIhYJpI/VcqMeVIlPw9lOzb/Xkur2e
lX2ARUbFxFuyP87pn90LNv+GIsNe6lrXfY9GXQ080RZ9lozui1YKk9bGVvLHYOVR
XGEIPSBX9FqosBA8ZQ6FrJiUZ7yC+1Cz0dToHMiGNaDSlS/naxadQCSp3ZHuHl0g
Esxq7MnnKIgzjqLx7PSgGzDNan5mnS+k0c5T6uC+6jL9z2m5czPqGLUVaAFYjwd3
X3+dsBZY34R1qZ1qzzqJutp0nZXO4NiIwSINbXVO8dcdsjTACoE=
=+f0s
-END PGP SIGNATURE-

Bug#1029587: Add simplest example

[Dan Jacobson]

Package: p7zip-full
Version: 16.02+dfsg-8
Severity: minor
File: /usr/share/man/man1/7z.1.gz
X-Debbugs-No-Ack: noack

On the 7z man page add an additional most simplest example of
7zipping and unzipping a single file. Thanks.

$ 7z a d.7z d

perhaps.

Bug#1029586: apt: "apt-cache rdepends --installed" false positives

[Vincent Lefevre]

Package: apt
Version: 2.5.5
Severity: normal

"apt-cache rdepends --installed" outputs false positives.
For instance:

zira:~> apt-cache rdepends --installed libpcre3:amd64
libpcre3
Reverse Depends:
[...]
  grep
[...]

But according to "dpkg -s grep":

Depends: dpkg (>= 1.15.4) | install-info
Pre-Depends: libc6 (>= 2.34), libpcre2-8-0 (>= 10.32)

there is no libpcre3!

I'm wondering whether apt is confused by old grep versions
(which depend on libpcre3, but they are not the currently
installed version).

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Never-MarkAuto-Sections:: "tasks";
APT::Never-MarkAuto-Sections:: "contrib/tasks";
APT::Never-MarkAuto-Sections:: "non-free/tasks";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::AutoRemove "";
APT::AutoRemove::SuggestsImportant "false";
APT::Clean-Installed "false";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "test -x /usr/bin/apt-show-versions || exit 
0 ; apt-show-versions -i";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "zstd";
APT::Compressor::zstd::Cost "60";
APT::Compressor::zstd::CompressArg "";
APT::Compressor::zstd::CompressArg:: "-19";
APT::Compressor::zstd::UncompressArg "";
APT::Compressor::zstd::UncompressArg:: "-d";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "lz4";
APT::Compressor::lz4::Cost "50";
APT::Compressor::lz4::CompressArg "";
APT::Compressor::lz4::CompressArg:: "-1";
APT::Compressor::lz4::UncompressArg "";
APT::Compressor::lz4::UncompressArg:: "-d";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "xz";
APT::Compressor::lzma::Cost "400";
APT::Compressor::lzma::CompressArg "";
APT::Compressor::lzma::CompressArg:: "--format=lzma";
APT::Compressor::lzma::CompressArg:: "-6";
APT::Compressor::lzma::UncompressArg "";
APT::Compressor::lzma::UncompressArg:: "--format=lzma";
APT::Compressor::lzma::UncompressArg:: "-d";
Dir "/";
Dir::State "var/lib/apt";
Dir::State::lists "lists/";
Dir::State::cdroms "cdroms.list";
Dir::State::extended_states "extended_states";
Dir::State::status "/var/lib/dpkg/status";
Dir::Cache "var/cache/apt";
Dir::Cache::archives "archives/";

Bug#1012666: ITS: wget2

[James Addison]

Source: wget2
Followup-For: Bug #1012666

Hi Boyuan,

A couple of review comments and a question for your wget2 copyright file:

  - As an execption, the 'include' directory (partly used for autogenerated
header file content) should be licensed under LGPL instead of GPL, I think.

  - It could be worthwhile to add an 'Upstream-Contact' entry in the file;
if there is no clear individual, then perhaps this could be a hyperlink to
the wget mailing lists[1].

  - Are the standalone license clauses necessary?  Both GPL-3 and LGPL-3
appear under /usr/share/common-licenses/ on Debian (bookworm) here.

Thank you for the ITS.

Regards,
James

[1] - https://savannah.gnu.org/mail/?group=wget

Bug#1022843: Bug#1029352: Bug#1022843: ifupdown: network down after systemctl restart

[Jeff King]

On Tue, Jan 24, 2023 at 02:32:07PM +0100, Santiago Ruano Rincón wrote:

> > Tests yesterday seem to indicate successful results, but again I've only
> > tested a few combinations in a VM (to keep the feedback loop short).
> > 
> > From the installer team point of view, I'd welcome a swift upload with
> > this patch, possibly with urgency=high so that the fix reaches testing
> > soon. This will another blocker out of the way for the next D-I release!
> 
> Just uploaded with your patched patch.

Thanks, I just booted with 0.8.41, and the result looks good to me!

-Peff

Bug#1029126: Wishing for Emacs 29 in Debian

[Sean Whitton]

Hello,

On Wed 25 Jan 2023 at 08:02AM +08, Dan Jacobson wrote:

> https://wiki.debian.org/DebianBookworm says it is "testing".
> Hmmm, I am using sid. Maybe it could go into sid?

It cannot.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1029126: Wishing for Emacs 29 in Debian

[Dan Jacobson]

https://wiki.debian.org/DebianBookworm says it is "testing".
Hmmm, I am using sid. Maybe it could go into sid?

> "SW" == Sean Whitton  writes:
SW> Hello,

SW> This can't happen before the release of bookworm.

Bug#1029469: RFP: anarch -- oldschool first-person-shooter game

[Paulo Henrique de Lima Santana]

Hi,

It's a good ideia you release a version of the game on the repository.

Best regards,


On Sun, 22 Jan 2023 22:32:14 +0100 Miloslav Ciz  
wrote:

Package: wnpp
Severity: wishlist

* package name: anarch
  upstream author: Miloslav Číž (drummyfish)
* URL: https://codeberg.org/drummyfish/Anarch
* license: CC0
* description: oldschool first-person-shooter game

Anarch is an oldschool first-person-shooter game mildly
inspired by the game Doom. It is completely public
domain, made to be as free as possible. It is also unique
in being very small, efficient, portable, dependency-free
and hackable.

This is my own software and I would be glad if someone
could package it for me as I have absolutely no experience
with packaging or maintaining packages. It gained some
attention and I got a lot of feedback from people that
told me they liked it, so I think it would be helpful to
include the game in Debian so that more people can find it
and play it.

Building is very easy, without requirement for any build
system (there is a shell script in the repository that
helps to compile the game with correct flags etc.). The only
modification that will probably need to be made is changing
the path to save file to some absolutely located file (e.g.
~/.anarch/anarch.sav) in settings.h before compiling
(currently the game saves its progress in the directory it
is run from). The only dependency is SDL2-dev (alternatively
csfml can also be used).




--
Paulo Henrique de Lima Santana (phls)
Belo Horizonte - Brasil
Debian Developer
Site: http://phls.com.br
GPG ID: 0443C450


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1029585: [pre-approval] unblock: dpkg/1.21.19

[Guillem Jover]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: d...@packages.debian.org
Control: affects -1 + src:dpkg

Hi!

(Even though I've noticed no blocking hints, given that the package
is supposed to be frozen, I'm requesting this pre-approval explicitly
anyway through the normal procedures as usual and expected.)

[ Reason ]

This dpkg release fixes several regressions. Reverts the loong64 arch
support given the uncertain status with its changing ABI. And updates
few translations.

[ Tests ]

The lto regression fix includes unit tests. The rest were tested
manually, the reproducible one by messing with the file perms of the
source, the GnuPG ones by creating fresh keys in a clean user home.

[ Risks ]

The changes seem targeted and small to me.

[ Checklist ]
  [√] all changes are documented in the d/changelog
  [√] I reviewed all changes and I approve them
  [√] attach debdiff against the package in testing

[ Other info ]

The attached debdiff is unfiltered, you might want to filterdiff with:

  xzcat dpkg-1.21.18-1.21.19.debdiff.xz |
filterdiff --exclude '*.po' --exclude '*.pot' \
   --exclude '*/man/*/*.pod' \
   --exclude '*/testsuite' --exclude '*/at/*.m4' \
   --exclude '*/configure'

Once (and iff) I get an approval, I'll upload to sid. I don't think
there's a need for an actual unblock hint though? :) But in any case:

unblock dpkg/1.21.19

Thanks,
Guillem


dpkg-1.21.18-1.21.19.debdiff.xz
Description: application/xz

Bug#1029497: closed by Ansgar (Bug#1029497 fixed in ftp.debian.org)

[Colin Watson]

On Tue, Jan 24, 2023 at 06:33:06PM +, Debian Bug Tracking System wrote:
> Date: Tue, 24 Jan 2023 18:29:25 +
> From: Ansgar 
> To: 1029497-d...@bugs.debian.org
> Subject: Bug#1029497 fixed in ftp.debian.org
> 
> Hello,
> 
> Bug #1029497 in ftp.debian.org reported by you has been fixed in the Git 
> repository.
> You can see the commit message below and you can check the diff of the fix at:
> 
> https://salsa.debian.org/ftp-team/dak/-/commit/09c13f37c04f8dcd994f3ee2e3e2137b03db7cbb

Confirmed, our importer is running properly again now.  Thanks!

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

Bug#1028192: libproxy1v5: Gajim 1.6.0-1 crashes in libproxy call

[Martin]

Hi Sebastian,

I wonder, if I should upload libproxy with your github patch¹ to
experimental. Then people affected (or not affected) by the bug can test
easily. Or you may upload, of course! :-)

Cheers

¹ https://github.com/libproxy/libproxy/issues/199#issuecomment-1401124997

Bug#1027506: Status of mozillavpn in Debian

[rbk]

On 22.01.2023 12:01, Sylvestre Ledru wrote:

Have you been able to try again?


Sorry, no. (I'm traveling with restricted network access.)
All I can say is that I was using dpkg-buildpackage on a sid host,
not pbuilder. Hope this helps.
  -richard.

Bug#1027506: Status of mozillavpn in Debian

[Sylvestre Ledru]

Le 24/01/2023 à 23:31, rbk a écrit :

On 22.01.2023 12:01, Sylvestre Ledru wrote:

Have you been able to try again?


Sorry, no. (I'm traveling with restricted network access.)
All I can say is that I was using dpkg-buildpackage on a sid host,
not pbuilder. Hope this helps.
  -richard.


Not really ;) but thanks

Bug#1029571: nageru: please build with sha1 to let lld link correctly

[Steinar H. Gunderson]

On Tue, Jan 24, 2023 at 06:25:57PM +0100, Gianfranco Costamagna wrote:
> Hello, with newer toolchains the default changed to sha256 IIRC, and lld 
> fails to link objects

Shouldn't this be fixed in the Debian lld package, if you can't build Debian
packages with lld? It seems a bit weird to have every package that could be
using lld deal with this. Or better yet, in debugedit :-)

> BTW according to your build log, you are using bfd linker, not lld, this is
> probably why its still working in Debian

That's pretty odd; I'll need to see what's going on at some point.
 
/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#1029584: Acknowledgement (linux-image-6.1.0-1-amd64: Mouswheel reports way too many events with Debian kernel config)

[Tobias Klausmann]

Hi! 

Some more experimentation has shows that this kernel, on the same
hardware, doe snot show the buggy behavior:

ii  linux-image-6.0.0-6-amd64   6.0.12-1 amd64Linux 6.0 for 
64-bit PCs (signed)

I don't know if there are any releases in between this and the kernel
mentioned in the original report that are worth testing.

Best,
Tobias

Bug#1028345:

[Jorge Moraleda]

Dear maintainer,

The package is also uninstallable in bookworm with:

The following packages have unmet dependencies:
 python3-sage : Depends: libgap7 (>= 4.11.0-1) but it is not installable
Depends: libpari-gmp-tls7 but it is not installable
Depends: libsingular4m2n1 (>= 1:4.2.1-p3+ds) but it is not
installable
Recommends: cysignals-tools but it is not going to be
installed
Recommends: maxima-sage-doc (>= 5.42.2) but it is not going
to be installed
Recommends: python3-sagenb-export (>= 3.2) but it is not
going to be installed
Recommends: singular-doc (>= 1:4.2.1-p2+ds-3) but it is not
going to be installed

With respect to the missing dependencies, I remark that bookworm contains
the following packages:
** libgap8* instead of *libgap7*
** libpari-gmp-tls8* instead of *libpari-gmp-tls7*
** libsingular4m3n0 *instead of

*libsingular4m2n1*
Potentially, fixing installability might be as simple as updating the
dependencies.

Bug#1029584: linux-image-6.1.0-1-amd64: Mouswheel reports way too many events with Debian kernel config

[Tobias Klausmann]

Package: src:linux
Version: 6.1.4-1
Severity: important

Dear Maintainer,

As of recent kernel versions, my mousewheel is nigh unusable: scrolling
emits 5-10 more events than it used to, just dropping the mouse from any
noticable height will create a whole bunch of events. It's now so
sensitive that middle-clicking a link in a browser is impossible.
Similar, switching desktops in my WM (Openbox) is impossible, since it
will rapidly scroll through all of them, stopping on a basically random
one.

I am pretty sure this is related to the somewhat-recent addition of
hires mouse wheel support to the kernel and libinput. I have found no
way to tell libinput to stop doing this. Online sources refer to quirks
in /etc/libinput, a directory which I do not have, and whil apt-file
says no Debian package installs.

I am well aware that this might be a libinput problem rather than a
kernel one, but I have to start somewhere. 

Not that my trimmed-down kernel config I use on some machines does not
have this problem, but of course tweaking the kernel config is no fix
for this. Plus, searching through the likely hundreds of differences
between my config and Debians is not really useful unless I have a
starting point --- something I couldn't find with some digging into what
make menuconfig shows me.

if you feel this needs to be directed to some other maintainer or
upstream, I am willing to carry it there, but I am at my wits' end
regarding what exactly the problem/config mismatch is. And hints are
appreciated.

Best,
Tobias Klausmann

-- Package-specific info:
** Version:
Linux version 6.1.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-13) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39.90.20221231) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.4-1 (2023-01-07)

** Command line:
BOOT_IMAGE=/@rootfs/boot/vmlinuz-6.1.0-1-amd64 
root=UUID=014c5cb3-1be0-461f-ba62-460df89062a3 ro rootflags=subvol=@rootfs 
consoleblank=0

** Not tainted

** Kernel log:
[6.136668] videodev: Linux video capture interface: v2.00
[6.136998] ccp :09:00.2: ccp enabled
[6.139899] ccp :09:00.2: psp enabled
[6.140341] input: PC Speaker as /devices/platform/pcspkr/input/input11
[6.150033] RAPL PMU: API unit is 2^-32 Joules, 1 fixed counters, 163840 ms 
ovfl timer
[6.151104] RAPL PMU: hw unit of domain package 2^-16 Joules
[6.155812] cryptd: max_cpu_qlen set to 1000
[6.166242] gspca_main: v2.14.0 registered
[6.172733] AVX2 version of gcm_enc/dec engaged.
[6.172780] AES CTR mode by8 optimization enabled
[6.177841] asus_wmi: ASUS WMI generic driver loaded
[6.183243] gspca_main: vc032x-2.14.0 probing 046d:0892
[6.184830] gspca_vc032x: reg_r err -32
[6.184836] vc032x: probe of 1-7.2:1.0 failed with error -32
[6.187845] usbcore: registered new interface driver vc032x
[6.188623] asus_wmi: Initialization: 0x0
[6.188654] asus_wmi: BIOS WMI version: 0.9
[6.188773] asus_wmi: SFUN value: 0x0
[6.188776] eeepc-wmi eeepc-wmi: Detected ASUSWMI, use DCTS
[6.190585] input: Eee PC WMI hotkeys as 
/devices/platform/eeepc-wmi/input/input12
[6.197904] audit: type=1400 audit(1674594983.762:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lsb_release" pid=615 
comm="apparmor_parser"
[6.197911] audit: type=1400 audit(1674594983.762:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=616 
comm="apparmor_parser"
[6.197917] audit: type=1400 audit(1674594983.762:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=616 comm="apparmor_parser"
[6.197921] audit: type=1400 audit(1674594983.762:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" 
pid=626 comm="apparmor_parser"
[6.197925] audit: type=1400 audit(1674594983.762:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-senddoc" 
pid=624 comm="apparmor_parser"
[6.198467] audit: type=1400 audit(1674594983.762:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oosplash" 
pid=623 comm="apparmor_parser"
[6.200666] audit: type=1400 audit(1674594983.766:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/cups-browsed" 
pid=629 comm="apparmor_parser"
[6.201955] asus_wmi: fan_curve_get_factory_default (0x00110024) failed: -61
[6.202038] audit: type=1400 audit(1674594983.766:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/chronyd" pid=627 
comm="apparmor_parser"
[6.203149] asus_wmi: fan_curve_get_factory_default (0x00110025) failed: -61
[6.204352] audit: type=1400 audit(1674594983.766:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=622 
comm="apparmor_parser"
[6.209318] audit: type=1400 audit(1674594983.766:11): apparmor="STATUS" 

Bug#1028433:

[Jorge Moraleda]

This other bug is at the core of why sagemath cannot be installed in
bookworm
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028345

Bug#996856: libcamera: Update package to a more recent version

[Dylan Aïssi]

Hello,

Since libcamera 0.0.2, I did several packaging changes. Are there any
other change required or can we close this bug?

Best regards,
Dylan

Bug#1027915: systemd requires /run to be mounted with a minimum size of 20MB

[Helge Deller]

Hi Helmut,

On 1/24/23 06:27, Helmut Grohne wrote:

On Mon, Jan 23, 2023 at 10:48:27PM +0100, Helge Deller wrote:

--- ./init.org  2023-01-23 21:40:33.079738389 +
+++ ./init  2023-01-23 21:40:45.983861851 +
@@ -205,6 +205,15 @@ else
resume=${RESUME:-}
  fi

+if [ -z "${RUNSIZE}" ] || [[ "${RUNSIZE}" \< "20" ]]; then


This is as bashism and init runs with dash as far as I can see.


Hmm... I did tested it, at it seemed to work...
Which part of that line exactly do you think is problematic?
I'm open for any other idea how to code it.


Also note that RUNSIZE may legitimately be given as "1g" or "19%", both
of which should work.


Both will work, because I assume that on such systems you probably have more 
than 200MB RAM
and thus my patch won't touch the user-provided value at all.


I suggest just not handling the case where RUNSIZE
is set by the user


Yes, I fully agree with you and had hoped to implement it that way.
Ideally RUNSIZE shouldn't be changed if it was already provided.
But the problem is, that on some/many systems RUNSIZE is *automatically* 
provided and added to
the bootloader via a default value (of 10%) given in 
/etc/initramfs-tools/update-initramfs.conf.
So, even if the user didn't changed or provided anything, the 10% is always set
and thus my check would never trigger


and letting them break their system however they
like rather than risk breaking legitimate configuration.


Again, the default value is the problem...


+   read MemTotal mem_kb rest < /proc/meminfo
+   # systemd requires at minumum 16MB for /run, so reserve
+   # 20MB for machines which have less than 200MB RAM
+   if [ "$mem_kb" -lt "20" ]; then
+   RUNSIZE=20M # for machines <= 200MB RAM


Given that you initialize a default here, I think it would make the code
more obvious if you pulled the 10% default 4 lines later into an else
branch.


Not sure I understand this...?


+   fi
+fi
+
  mount -t tmpfs -o "nodev,noexec,nosuid,size=${RUNSIZE:-10%},mode=0755" tmpfs 
/run
  mkdir -m 0700 /run/initramfs


Helmut


Thank you Helmut!
Helge

Bug#1029583: RFS: dmagnetic/0.35-1 -- Interpreter to play textadventures from Magnetic Scrolls in glorious ANSI Art

[Thomas Dettbarn]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : dmagnetic
Version : 0.35-1
Upstream contact : Thomas Dettbarn 
* URL : https://www.dettus.net/dMagnetic/
* License : BSD-2-Clause
* Vcs : [fill in URL of packaging vcs]
Section : games

The source builds the following binary packages:

dmagnetic - Interpreter to play textadventures from Magnetic Scrolls in 
glorious ANSI Art


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


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/d/dmagnetic/dmagnetic_0.35-1.dsc


Changes since the last upload:

dmagnetic (0.35-1) unstable; urgency=medium
.
* Minor bugfixes
* Reduced memory consumption
* New default format for savegames
* Better looking ANSI and ASCII output
* Much cleaner sourcecode

Regards,

Thomas

PS: I am also looking for a sponsor for my package "d11amp".

Bug#1029557: debian-edu-config: Session exits on first login on roaming-workstation fails

[Mike Gabriel]

Hi again,

On  Di 24 Jan 2023 15:19:15 CET, Petter Reinholdtsen wrote:


[Nico Winkelsträter]

When a user tries to log in at a romaing workstation for the very first time
the login prompt disappears, stays on the empty default-background for a few
seconds and the returns to lightdm with a brief black-screen.

On the second try everything works as expected.


This is by design.  There was (and probably still is) no way to change
$HOME from the PAM subsystem when the login already was in progress.  To
work around this limitiation the user is logged logged out on the first
try, after the home directory is created and /etc/passwd is updated with
the new home location, to ensure the new home directory is used during
future logins.  The home directory is changed from
/skole/tjener/home0/testes/ to /home/testes/ in your case.



please also note, that we recently changed stuff in libpam-python.so  
and also fixed a pam_session related bug in unit tests. I still need  
to test the Python3 port of libpam-python.so containing this fix (it's  
in Debian testing already) to see if above issue reported by Nico is  
possibly resolved.


Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgp4ASBGSzYrV.pgp
Description: Digitale PGP-Signatur

Bug#1029557: debian-edu-config: Session exits on first login on roaming-workstation fails

[Mike Gabriel]

Hi Petter,

On  Di 24 Jan 2023 15:19:15 CET, Petter Reinholdtsen wrote:


[Nico Winkelsträter]

When a user tries to log in at a romaing workstation for the very first time
the login prompt disappears, stays on the empty default-background for a few
seconds and the returns to lightdm with a brief black-screen.

On the second try everything works as expected.


This is by design.  There was (and probably still is) no way to change
$HOME from the PAM subsystem when the login already was in progress.  To
work around this limitiation the user is logged logged out on the first
try, after the home directory is created and /etc/passwd is updated with
the new home location, to ensure the new home directory is used during
future logins.  The home directory is changed from
/skole/tjener/home0/testes/ to /home/testes/ in your case.


the interesting bit of information is: when using GDM3, the first  
login succeeds and the session is in an intact state.


So, the follow-up question is: Why can this work in GDM3 while it  
fails in LightDM?


Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgplaPqbM78p6.pgp
Description: Digitale PGP-Signatur

Bug#1029582: claws-mail: Processing rules don't apply to newly-created folders

[Paul Evans]

Package: claws-mail
Version: 4.1.1-2+b1
Severity: normal

Dear Maintainer,

I have some pre-processing rules set to apply a colour to mails I've
sent. E.g.

   Condition: from matchcase "leon...@leonerd.org.uk"
   Action:color 5

These work fine on most of my "old" mail folders I've had for years.

But if I now create a new folder, the rules won't apply to any mails
that get filed into it.

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

Kernel: Linux 6.1.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages claws-mail depends on:
ii  libc62.36-8
ii  libcairo21.16.0-7
ii  libcompfaceg11:1.5.2-5.1
ii  libdbus-glib-1-2 0.112-3
ii  libenchant-2-2   2.3.3-2
ii  libetpan20   1.9.4-3.1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1
ii  libglib2.0-0 2.74.4-1
ii  libgnutls30  3.7.8-4
ii  libgtk-3-0   3.24.36-1
ii  libice6  2:1.0.10-1
ii  libldap-2.5-02.5.13+dfsg-3
ii  libnettle8   3.8.1-2
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  librsvg2-2   2.54.5+dfsg-1
ii  libsm6   2:1.2.3-1
ii  xdg-utils1.1.3-4.1

Versions of packages claws-mail recommends:
ii  aspell-en [aspell-dictionary]  2018.04.16-0-1
ii  claws-mail-i18n4.1.1-2
ii  xfonts-100dpi  1:1.0.5
ii  xfonts-75dpi   1:1.0.5

Versions of packages claws-mail suggests:
ii  chromium [www-browser]  109.0.5414.74-2
pn  claws-mail-doc  
pn  claws-mail-tools
ii  elinks [www-browser]0.13.2-1+b4
ii  firefox [www-browser]   109.0-1
ii  firefox-esr [www-browser]   102.6.0esr-1
ii  google-chrome-stable [www-browser]  109.0.5414.74-1
ii  lynx [www-browser]  2.9.0dev.11-1
ii  mousepad0.5.10-1
ii  w3m [www-browser]   0.5.3+git20220429-1+b1

-- no debconf information



-- 
Paul "LeoNerd" Evans

leon...@leonerd.org.uk  |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/

Bug#1029581: python-typing-extensions: Please package recent version 4.4.0

[Danilo Egea Gondolfo]

Source: python-typing-extensions
Version: 4.3.0-2
Severity: wishlist

Dear Maintainer,

upstream has release a new version (4.4.0) few months ago. Please
consider packaging the most recent version.

Thanks!

-- System Information:
Debian Release: bookworm/sid
APT prefers kinetic-updates
APT policy: (500, 'kinetic-updates'), (500, 'kinetic-security'), (500, 
'kinetic'), (100, 'kinetic-backports')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.0-29-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en

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

Bug#977780: connman: wifi stopped working with net.connman.Error.NoCarrier

[Manuel González]

Package: connman
Version: 1.41-2+b1
Followup-For: Bug #977780

Dear Maintainer,

I have been able to reproduce this issue in a more restricted manner and get an
output from syslog.

I am able to reproduce this issue with the error described in other emails and
subject to this bug report (as seen in connman-gtk). This error in my case
happens in case I attempt to connect to a hotspot created from my phone. This 
did
not happen in my case with earlier versions of the connman package.

Attached is a snippet taken from syslog when I attempt to connect to the 
hotspot enabled
from my phone, and conman fails. After the error, connman deflects to the SSID
for which has valid configs (SSID 'shrimp' in the below snippets).

Cheers,

-Manuel

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

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

Versions of packages connman depends on:
ii  dbus   1.14.4-1
ii  init-system-helpers1.65.2
ii  iptables   1.8.9-2
ii  libc6  2.36-8
ii  libdbus-1-31.14.4-1
ii  libglib2.0-0   2.74.4-1
ii  libgnutls303.7.8-4
ii  libreadline8   8.2-1.3
ii  libxtables12   1.8.9-2
ii  lsb-base   11.5
ii  sysvinit-utils [lsb-base]  3.06-2

Versions of packages connman recommends:
ii  bluez  5.66-1
pn  ofono  
ii  wpasupplicant  2:2.10-10

Versions of packages connman suggests:
pn  connman-vpn  

-- no debconf information
2023-01-24T22:16:37.894249+02:00 hecate avahi-daemon[966]: Withdrawing address 
record for 192.168.8.198 on wlp0s20f3.
2023-01-24T22:16:37.896665+02:00 hecate kernel: [ 1491.810923] wlp0s20f3: 
deauthenticating from 94:83:c4:12:df:b1 by local choice (Reason: 
3=DEAUTH_LEAVING)
2023-01-24T22:16:37.896712+02:00 hecate avahi-daemon[966]: Withdrawing address 
record for fe80::2641:8cff:fe33:ab17 on wlp0s20f3.
2023-01-24T22:16:37.897248+02:00 hecate avahi-daemon[966]: Leaving mDNS 
multicast group on interface wlp0s20f3.IPv6 with address 
fe80::2641:8cff:fe33:ab17.
2023-01-24T22:16:37.897476+02:00 hecate avahi-daemon[966]: Interface 
wlp0s20f3.IPv6 no longer relevant for mDNS.
2023-01-24T22:16:37.898464+02:00 hecate connmand[991]: wlp0s20f3 {del} address 
192.168.8.198/24 label wlp0s20f3
2023-01-24T22:16:37.898766+02:00 hecate connmand[991]: wlp0s20f3 {RX} 11991 
packets 8841500 bytes
2023-01-24T22:16:37.898980+02:00 hecate connmand[991]: wlp0s20f3 {TX} 8337 
packets 2800036 bytes
2023-01-24T22:16:37.899189+02:00 hecate connmand[991]: wlp0s20f3 {update} flags 
36867 
2023-01-24T22:16:37.899445+02:00 hecate connmand[991]: wlp0s20f3 {newlink} 
index 4 address 24:41:8C:33:AB:17 mtu 1500
2023-01-24T22:16:37.899685+02:00 hecate connmand[991]: wlp0s20f3 {newlink} 
index 4 operstate 2 
2023-01-24T22:16:37.899901+02:00 hecate connmand[991]: wlp0s20f3 {del} route 
0.0.0.0 gw 192.168.8.1 scope 0 
2023-01-24T22:16:37.900091+02:00 hecate connmand[991]: wlp0s20f3 {del} route 
192.168.8.1 gw 0.0.0.0 scope 253 
2023-01-24T22:16:37.900303+02:00 hecate connmand[991]: wlp0s20f3 {del} route 
fe80:: gw :: scope 0 
2023-01-24T22:16:38.000854+02:00 hecate wpa_supplicant[995]: wlp0s20f3: 
CTRL-EVENT-DISCONNECTED bssid=94:83:c4:12:df:b1 reason=3 locally_generated=1
2023-01-24T22:16:38.000944+02:00 hecate wpa_supplicant[995]: wlp0s20f3: 
CTRL-EVENT-DSCP-POLICY clear_all
2023-01-24T22:16:38.001156+02:00 hecate wpa_supplicant[995]: wlp0s20f3: 
PMKSA-CACHE-REMOVED 94:83:c4:12:df:b1 0
2023-01-24T22:16:38.864464+02:00 hecate wpa_supplicant[995]: wlp0s20f3: SME: 
Trying to authenticate with 94:83:c4:12:df:b1 (SSID='shrimp' freq=5745 MHz)
2023-01-24T22:16:38.864613+02:00 hecate kernel: [ 1492.780429] wlp0s20f3: 
authenticate with 94:83:c4:12:df:b1
2023-01-24T22:16:38.876668+02:00 hecate kernel: [ 1492.791050] wlp0s20f3: send 
auth to 94:83:c4:12:df:b1 (try 1/3)
2023-01-24T22:16:38.934056+02:00 hecate wpa_supplicant[995]: wlp0s20f3: SME: 
Trying to authenticate with 94:83:c4:12:df:b1 (SSID='shrimp' freq=5745 MHz)
2023-01-24T22:16:38.935959+02:00 hecate wpa_supplicant[995]: wlp0s20f3: 
PMKSA-CACHE-ADDED 94:83:c4:12:df:b1 0
2023-01-24T22:16:38.936172+02:00 hecate wpa_supplicant[995]: wlp0s20f3: Trying 
to associate with 94:83:c4:12:df:b1 (SSID='shrimp' freq=5745 MHz)
2023-01-24T22:16:38.936668+02:00 hecate kernel: [ 1492.849939] wlp0s20f3: 
authenticate with 94:83:c4:12:df:b1
2023-01-24T22:16:38.936684+02:00 hecate kernel: [ 1492.849956] wlp0s20f3: send 
auth to 94:83:c4:12:df:b1 (try 1/3)
2023-01-24T22:16:38.936687+02:00 hecate kernel: [ 1492.851506] wlp0s20f3: 
authenticated
2023-01-24T22:16:38.936699+02:00 hecate kernel: [ 1492.852679] wlp0s20f3: 
associate with 94:83:c4:12:df:b1 (try 

Bug#1029573: gnuserv: hangs while installing if xemacs21 is installed

[Alexander Zangerl]

On Tue, 24 Jan 2023 18:42:07 +0100, Andreas Beckmann writes:
>during a test with piuparts I noticed your package failed to install.

*agh*

>This is an automated install test with DEBIAN_FRONENT=noninteractive and 
>stdin coming from /dev/null which got killed after reaching a timeout,
> so there is no log output :-(

no problem, i'm relatively certain i know roughly where the gotcha is;
should get fixed tonight or tomorrow.


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/
Fachbegriffe der Informatik, Updateitis: Softwarebulemie -- Frank Klemm


signature.asc
Description: Digital Signature

Bug#859739: RFP: pm-graph -- performance analysis of boot, suspend, and resume

[Todd Brandt]

On Tue, 2022-10-11 at 12:53 -0400, Antoine Beaupré wrote:
> On 2017-04-07 11:42:54, Todd Brandt wrote:
> > On Thu, 06 Apr 2017 22:20:04 + Bart Martens 
> >  wrote:
> > > noowner 859739
> > > stop
> > > 
> > > A wnpp bug of type RFP should not have an owner.
> > 
> > I understand. I originally tagged it as ITP because I wanted to own
> > it 
> > but require a sponsor. If you require a sponsor is ITP even
> > allowed?
> 
> yes, I would think so. you can create a Debian package even if you're
> not part of Debian per se, and then the sponsor is the person who
> actually reviews the work and uploads it in Debian.
> 
> So in that sense, yes, it makes sense for an ITP to require a
> sponsor.
> 
> This looks like a really interesting tool, are you still planning on
> packaging it?
> 
> A.
> 
I've kept the debian folder mostly up to date so it's still capable of
being packaged. I include the source in the linux kernel source tree in
the tools folder, but I would very much like to see this thing show up
on ubuntu with an apt-cache search. If I could get a sponsor I'd be
happy to work with them.

Bug#1028862: xorg-gtest: FTBFS: dh_auto_test: error: make -j1 check "TESTSUITEFLAGS=-j1 --verbose" VERBOSE=1 returned exit code 2

[Santiago Vila]

Hello.

I can also reproduce this build failure.

My build environment is made of virtual machines in the cloud
with either 1 CPU or 2 CPUs.

This bug happens randomly, but the failure rate seems to depend on the machine.

On systems with 2 CPUs, the failure rate I get is around 50%.
On systems with 1 CPU, the failure rate I get is 100%.

Therefore I suggest using GRUB_CMDLINE_LINUX="nr_cpus=1" in /etc/default/grub
to reproduce it.

Thanks.

Bug#1029580: sepp fails with python3.11: "invalid mode rU"

[Steve Langasek]

Package: sepp
Version: 4.5.1+really4.5.1+dfsg-4
Severity: grave
Tags: patch
Justification: renders package unusable
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch

Dear maintainers,

sepp fails its autopkgtests with python3.11, revealing a bug in the
software, because it uses a mode flag to open() which has been deprecated
since python 3 and is now obsolete in python 3.11:

[...]
[06:42:37] checkpointing.py (line 68): INFO: Checkpoint Saved to: 
/tmp/sepp/output.lmge6vob/checkpoints/dumpl7z66ff0 and linked in 
/tmp/tmpae0xbm2t.
/usr/lib/python3/dist-packages/sepp/checkpointing.py:75: DeprecationWarning: 
setDaemon() is deprecated, set the daemon attribute instead
  checkpoint_manager.timer.setDaemon(True)
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/sepp/scheduler.py", line 321, in 
call_back
join._tick(job_in)
  File "/usr/lib/python3/dist-packages/sepp/scheduler.py", line 244, in _tick
self.perform()
  File "/usr/lib/python3/dist-packages/sepp/exhaustive.py", line 196, in perform
fullExtendedAlignments = self.merge_subalignments()
 ^^
  File "/usr/lib/python3/dist-packages/sepp/exhaustive.py", line 181, in 
merge_subalignments
ap_alg = ap.read_extendend_alignment_and_relabel_columns(
 
  File "/usr/lib/python3/dist-packages/sepp/problem.py", line 253, in 
read_extendend_alignment_and_relabel_columns
ap_alg.build_extended_alignment(
  File "/usr/lib/python3/dist-packages/sepp/alignment.py", line 555, in 
build_extended_alignment
self.read_filepath(base_alignment, "FASTA")
  File "/usr/lib/python3/dist-packages/sepp/alignment.py", line 294, in 
read_filepath
file_obj = open(filename, 'rU')
   
ValueError: invalid mode: 'rU'
ERROR
[...]

  (https://ci.debian.net/data/autopkgtest/unstable/amd64/s/sepp/30285435/log.gz)

This also impacts invocations of sepp in other autopkgtests
(q2-fragment-insertion; q2-sample-classifier) so I'm confident is reporting
this as 'grave'.

I've applied the attached straightforward patch in Ubuntu to fix the
regression there.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru sepp-4.5.1+really4.5.1+dfsg/debian/patches/open-U-obsolete.patch 
sepp-4.5.1+really4.5.1+dfsg/debian/patches/open-U-obsolete.patch
--- sepp-4.5.1+really4.5.1+dfsg/debian/patches/open-U-obsolete.patch
1969-12-31 16:00:00.0 -0800
+++ sepp-4.5.1+really4.5.1+dfsg/debian/patches/open-U-obsolete.patch
2023-01-24 12:07:06.0 -0800
@@ -0,0 +1,52 @@
+Description: Drop obsolete "U" mode passed to open()
+ The "U" mode has been deprecated in python since python3 and has had no
+ effect.  In python 3.11, it is now disallowed.  Drop this mode flag that
+ causes runtime failures.
+Author: Steve Langasek 
+Last-Update: 2023-01-24
+Forwarded: no
+
+Index: sepp-4.5.1+really4.5.1+dfsg/sepp/alignment.py
+===
+--- sepp-4.5.1+really4.5.1+dfsg.orig/sepp/alignment.py
 sepp-4.5.1+really4.5.1+dfsg/sepp/alignment.py
+@@ -108,7 +108,7 @@
+ file_obj = None
+ if isinstance(src, str):
+ try:
+-file_obj = open(src, "rU")
++file_obj = open(src, "r")
+ except IOError:
+ print(("The file `%s` does not exist, exiting gracefully" % src))
+ elif isinstance(src, filetypes):
+@@ -291,7 +291,7 @@
+ If duplicate sequence names are encountered then the old name will
+ be replaced.
+ """
+-file_obj = open(filename, 'rU')
++file_obj = open(filename, 'r')
+ return self.read_file_object(file_obj, file_format=file_format)
+ 
+ def read_file_object(self, file_obj, file_format='FASTA'):
+@@ -582,7 +582,7 @@
+ columns. Labels insertion columns with special labels and labels the
+ rest of columns (i.e. original columns) sequentially.
+ """
+-handle = open(path, 'rU')
++handle = open(path, 'r')
+ insertions = None
+ if aformat.lower() == "stockholm":
+ insertions = self._read_sto(handle)
+Index: sepp-4.5.1+really4.5.1+dfsg/sepp/tree.py
+===
+--- sepp-4.5.1+really4.5.1+dfsg.orig/sepp/tree.py
 sepp-4.5.1+really4.5.1+dfsg/sepp/tree.py
+@@ -314,7 +314,7 @@
+ 
+ def read_tree_from_file(self, treefile, file_format):
+ dataset = Dataset()
+-dataset.read(open(treefile, 'rU'), schema=file_format)
++dataset.read(open(treefile, 'r'), schema=file_format)
+ dendropy_tree = 

Bug#1023438: dpkg-checkbuilddeps: allow satisfying :native Build-Depends with Multi-Arch: foreign packages

[Helmut Grohne]

Hi Andreas,

On Tue, Jan 24, 2023 at 03:13:29PM +0100, Andreas Beckmann wrote:
> One package affected by this is src:reprepro in experimental where
> dpkg-checkbuilddeps now rejects db-util:native (which gained
> M-A: foreign in bookworm).

The reason to allow :native on M-A:foreign is to ease such transitions.
Nothing else. We could always drop :native in such cases. This allowance
is a convenience only.

> It may be useless to annotate an arch:all B-D package with :native (as
> src:reprepro/exoerimental currently does), or does the :native propagate to
> the non-arch:all dependencies of the annotated arch:all package?

An Arch:all package that isn't M-A:foreign, is implicitly considered to
have the "native" architecture (which is defined as the architecture of
the dpkg package). All dependencies of Arch:all packages are native
regardless of whether it is M-A:foreign or whether the dependency is
annotated :native or not. None of this influences the architecture of
indirect dependencies.

Helmut

Bug#1027915: systemd requires /run to be mounted with a minimum size of 20MB

[Helmut Grohne]

Hi Helge,

On Mon, Jan 23, 2023 at 10:48:27PM +0100, Helge Deller wrote:
> --- ./init.org2023-01-23 21:40:33.079738389 +
> +++ ./init2023-01-23 21:40:45.983861851 +
> @@ -205,6 +205,15 @@ else
>   resume=${RESUME:-}
>  fi
>  
> +if [ -z "${RUNSIZE}" ] || [[ "${RUNSIZE}" \< "20" ]]; then

This is as bashism and init runs with dash as far as I can see.

Also note that RUNSIZE may legitimately be given as "1g" or "19%", both
of which should work. I suggest just not handling the case where RUNSIZE
is set by the user and letting them break their system however they
like rather than risk breaking legitimate configuration.

> + read MemTotal mem_kb rest < /proc/meminfo
> + # systemd requires at minumum 16MB for /run, so reserve
> + # 20MB for machines which have less than 200MB RAM
> + if [ "$mem_kb" -lt "20" ]; then
> + RUNSIZE=20M # for machines <= 200MB RAM

Given that you initialize a default here, I think it would make the code
more obvious if you pulled the 10% default 4 lines later into an else
branch.

> + fi
> +fi
> +
>  mount -t tmpfs -o "nodev,noexec,nosuid,size=${RUNSIZE:-10%},mode=0755" tmpfs 
> /run
>  mkdir -m 0700 /run/initramfs

Helmut

Bug#1029574: indent shebang bug and misses LFS support

[Helge Deller]

Hi Santiago,

On 1/24/23 20:07, Santiago Vila wrote:

El 24/1/23 a las 18:48, Helge Deller escribió:

Package:  indent
Version: 2.2.12
Tags: hppa, patch, lfs, FTBFS

The indent package has a bug in the script "regression/TEST"
which starts with "#/bin/sh" instead of a correct
shebang which would be "#!/bin/sh". This leads to a FTBFS on
the hppa architecture when running virtualized in qemu-user.

Secondly it would be nice if the indent tool would be built
with large file support. Adding future=+lfs to DEB_BUILD_MAINT_OPTIONS
allows that.

Both are fixed with attached patch. Please apply for next upload.


Thanks for the report and the patch.

I'm curious about the LFS issue: Is it really a good idea to have a .c
file larger than 2GB? I did a quick search and found this tweet:


LFS is not just the 2GB limit (_LARGEFILE_SOURCE) when opening files.
I see in src/backup.c the readdir() glibc call is used, which
may fail randomly on big filesystems when built as 32bit binary.
See e.g: https://www.mjr19.org.uk/sw/inodes64.html
For that the define _FILE_OFFSET_BITS=64 is needed to work reliable.


https://twitter.com/cristalopes/status/776569616692752384

   The largest C++ file we found in GitHub has 528Mb, 57 lines of code.
   Contains the first 50,847,534 primes, all hard coded in an array.

So: What would be the rationale for adding LFS support to the indent program?
"Just in case"?


_FILE_OFFSET_BITS=64, needed for readdir() call.


Another question: I see there are now several ways to enable LFS. In procmail
I had this in debian/rules:

CFLAGS := $(shell dpkg-buildflags --get CFLAGS) $$(getconf LFS_CFLAGS)

Is that equivalent to using future=+lfs or are there any differences?


Yes, your above code should work:
(sid_hppa)deller@pacific:~/$getconf LFS_CFLAGS
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64

Those are the defines which are needed.

Btw, if you add the "_TIME_BITS=64" define too, your are even 64-bit ready...

Thanks!
Helge

Bug#1026503: libembperl-perl: FTBFS: Expected 6 more error(s) in logfile, tagging 1026503

[gregor herrmann]

On Sun, 22 Jan 2023 23:30:53 +0100, Axel Beckert wrote:

> This took me quite a few hours to figure out. Not sure what exactly
> changed in Debian Sid/Bookworm, but it might be even kernel or gcc
> related.
> The cause was intercepting STDERR into a file and reading from it
> while the writing file handle is still open for the purpose analyzing
> STDERR's content.

Very nice work, congratulations :)
 

Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1029579: twisted.python.failure._Code is incompatible with Python 3.11

[Andrey Rakhmatullin]

Package: python3-twisted
Version: 22.4.0-3
Severity: important
Tags: upstream fixed-upstream

https://github.com/twisted/twisted/issues/10336 causes tests of some other
packages (e.g. python-scrapy) to break on Python 3.11.


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

Kernel: Linux 6.1.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 python3-twisted depends on:
ii  python3   3.10.6-3+b1
ii  python3-attr  22.2.0-1
ii  python3-automat   22.10.0-1
ii  python3-bcrypt3.2.2-1
ii  python3-constantly15.1.0-4
ii  python3-cryptography  38.0.4-2
ii  python3-hamcrest  2.0.3-2
ii  python3-hyperlink 21.0.0-5
ii  python3-idna  3.3-1
ii  python3-incremental   21.3.0-2
ii  python3-openssl   22.1.0-1
ii  python3-service-identity  18.1.0-7
ii  python3-zope.interface5.5.2-1

python3-twisted recommends no packages.

Versions of packages python3-twisted suggests:
pn  python3-pampy 
pn  python3-serial
pn  python3-tk
pn  python3-wxgtk4.0  

-- no debconf information

Bug#1026725: Comment

[Dominik Stadler]

The next minor version 20.2.0 has this test removed as part of removing
support for Python2 and 3.5, see commit
https://github.com/hynek/structlog/commit/f65309d4f66fbd44c09288a485107d725c3da1d4#diff-673441c4b6dbee451d8130f1e9bb48f3dbc44d5d3acf1c21d52d0904002342d5

So it might be justified to simply remove or disable this test until the
next version-upgrade is done for the package.

Bug#1029574: indent shebang bug and misses LFS support

[Santiago Vila]

El 24/1/23 a las 18:48, Helge Deller escribió:

Package:  indent
Version: 2.2.12
Tags: hppa, patch, lfs, FTBFS

The indent package has a bug in the script "regression/TEST"
which starts with "#/bin/sh" instead of a correct
shebang which would be "#!/bin/sh". This leads to a FTBFS on
the hppa architecture when running virtualized in qemu-user.

Secondly it would be nice if the indent tool would be built
with large file support. Adding future=+lfs to DEB_BUILD_MAINT_OPTIONS
allows that.

Both are fixed with attached patch. Please apply for next upload.


Thanks for the report and the patch.

I'm curious about the LFS issue: Is it really a good idea to have a .c
file larger than 2GB? I did a quick search and found this tweet:

https://twitter.com/cristalopes/status/776569616692752384

  The largest C++ file we found in GitHub has 528Mb, 57 lines of code.
  Contains the first 50,847,534 primes, all hard coded in an array.

So: What would be the rationale for adding LFS support to the indent program?
"Just in case"?


Another question: I see there are now several ways to enable LFS. In procmail
I had this in debian/rules:

CFLAGS := $(shell dpkg-buildflags --get CFLAGS) $$(getconf LFS_CFLAGS)

Is that equivalent to using future=+lfs or are there any differences?

Thanks.

Bug#999322: Intent to NMU

[Andreas Henriksson]

Hello,

I intend to NMU changes to fix the outstanding RC bugs as well as some
related changes for bonnie++ in Debian.

The changes was made against the git repo and are available as a salsa
MR at: https://salsa.debian.org/etbe/bonnie/-/merge_requests/2

Since these bugs seems to have been around for a long time (some
including patches) and that we're getting really close to
freeze I'm uploading directly into unstable without any delay to
have a chance for bonnie++ to make it back into testing.
Please feel free to do a maintainer upload to override my
upload if there's anything in here that is controversial or wrong, but
hopefully there isn't.

Regards,
Andreas Henriksson

Bug#1029578: src:shunit2: fails to migrate to testing for too long

[Paul Gevers]

Source: shunit2
Version: 2.1.6-1.2
Severity: serious
Control: close -1 2.1.8-3
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:shunit2 has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. We've been communicating in 
private about the autopkgtest regressions, which points at behavior 
changes, that's causing the migration to being blocked.


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1026200: Please package LilyPond 2.24.0 if possible

[Anthony Fok]

On Sun, Jan 22, 2023 at 8:00 PM Rob Browning  wrote:
>
> Anthony Fok  writes:
>
> > Thank you so much for Cc'ing Rob regarding Guile-2.2.
> >
> > Rob, as you can see, there is a real need for Guile 2.2 for LilyPond
> > 2.24.0 (December 2022), this coming from LilyPond's Core Developer
> > Jonas Hahnfeld and "Factotum" and Jean Abou Samra.  If it is OK with
> > you, Rob, I would be more than happy to adopt guile-2.2 and maintain
> > it for the entire lifetime of Debian 12 (bookworm), and hopefully by
> > Debian 13 (trixie), LilyPond will be ready for guile-3.0.  :-)\
> > Many thanks for your understanding!

Hello Rob,

Thank you so much for your reply!

> I'd be very hesitant to include Guile 2.2 in bookworm since I believe
> it's explicitly not supported upstream and hasn't had a single commit
> in over two years.
>
> If there's any chance LilyPond will support something newer in a
> reasonable time-frame, I might suggest just waiting, and then
> introducing the new version via backports.
>
> But I don't really understand the situation and constraints.

The LilyPond development team actually values Debian very much, and
has specifically contacted me (the current maintainer of the LilyPond
package), and carefully planned and timed the LilyPond v2.24.0 release
to be just right for the Debian 12 bookworm release.  Unfortunately,
Guile-3.0 is still problematic for the just-released LilyPond v2.24.0,
especially concerning cross-platform compatibility, so much so that
the LilyPond development team is pleading us to keep Guile-2.2 in
Debian just a while longer.

> That said, I won't oppose reintroducing 2.2, as long as I'm not
> responsible for it, and you're willing to herd all the cats to get it
> removed again as soon as possible.  That was a good bit of work I'd
> prefer not to repeat.

Thank you so much for your understanding!
Yes, I'll be more than willing to take on the responsibility of
getting guile-2.2 removed from Debian 13 trixie as soon as LilyPond is
ready.
Your hard work in getting guile-2.2 removed from bookworm means that
almost all other software packages have migrated to guile-3.0, with
lilypond being the only odd one out.

Many thanks!

Anthony

Bug#1029577: ITP: dinit -- Service monitoring / "init" system

[Mobin]

Package: wnpp
Severity: wishlist
Owner: Mobin Aydinfar 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: dinit
  Version : 0.16.0
  Upstream Author : Davin McCall 
* URL : https://davmac.org/projects/dinit
* License : Apache-2.0
  Programming Lang: C++
  Description : Service monitoring / "init" system

Dinit is service-manager for UNIX-like systems. It's also can act as 
system init (PID 1) ([1]). Dinit designed to provide a robust, clean, 
portable, easy to use and fully documented service-manager with depends 
management design in mind. For more info See Author's Comparison [2].


 - I use Dinit for my daily use on Devuan. It helps me to start/stop 
some services in my user sessions and supervise them (such as pipewire, 
dbus and...).


 - I will maintain the software and the package for Debian,
   but since I'm not a DD yet, I'll need a sponsor for it.

Regards

[1]: But this package don't provide any file to use Dinit as PID 1 on 
Debian.


[2]: https://github.com/davmac314/dinit/blob/master/doc/COMPARISON

Bug#1029576: ITP: golang-github-hexops-gotextdiff -- Unified text diffing in Go (copy gopls internal diffing)

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-hexops-gotextdiff
  Version : 1.0.3-1
  Upstream Author : Hexops
* URL : https://github.com/hexops/gotextdiff
* License : BSD-3-clause
  Programming Lang: Go
  Description : Unified text diffing in Go (copy of gopls internal diffing)

 gotextdiff is a copy of the Go text diffing packages that the official Go
 language server gopls uses internally to generate unified diffs.
 .
 If you've previously tried to generate unified text diffs in Go (like
 the ones you see in Git and on GitHub), you may have found
 github.com/sergi/go-diff which is a Go port of Neil Fraser's
 google-diff-match-patch code - however it does not support unified diffs.
 .
 This is arguably one of the best (and most maintained) unified text
 diffing packages in Go as of at least 2020.
 .
 (All credit goes to the Go authors (http://tip.golang.org/AUTHORS), I am
 merely re-publishing their work so others can use it.)

Reason for packaging:
 Required by golang-github-alecthomas-assert 2.2.0,
 which is required by golang-github-alecthomas-chroma-v2 2.4.0,
 which in turn is required by hugo 0.107.0 and up.

Bug#1029575: RFP: woof -- share files through HTTP protocol

[Vilius Panevėžys]

Package: wnpp
Severity: wishlist

* Package name: woof
  Version : 20220202
  Upstream Author : Simon Budig 
* URL : http://www.home.unix-ag.org/simon/woof.html
* License : GPL 2 or later
  Programming Lang: Python
  Description : share files through HTTP protocol

Woof used to be part of Debian, but was removed as part of Python 3
migration [1]. However, it has since been migrated to Python 3 upstream,
so the removal reason no longer applies.

The best alternative I've found available in Debian is filetea, but it
does not seem to be actively maintained upstream. filetea is more
featureful, but also "heavier" (needs a service, both parties have to
use the web interface). So I prefer the simple and efficient Woof for my
use cases and would like to see it reintroduced to Debian archive.

I'm including the description of Woof package as previously used in
Debian below as prompted by the RFP bug template.

*   *   *

Woof (Web Offer One File) is a tool to copy files among hosts. It can
serve a specified file on HTTP, just for a given number of times, and
then exits.

It can be easily used to share files across the computers on a net,
enough the other ends have just a browser (that means you can share
things between different operating systems or different devices, even
phones).


[1] https://tracker.debian.org/news/1086863/woof-removed-from-testing/

Bug#1017941: marked as pending in greenbone-security-assistant

[Steve Langasek]

On Tue, Jan 24, 2023 at 05:31:46PM +, Sophie Brun wrote:
> Move package to non-free and mark it as not autobuildable (Closes: #1017941)

Why are you proposing to do this instead of including the actual source in
the source tarball?  This may fix the build failure, but it doesn't sound
like a good solution to me.  (I'm not sure if it's technically within the
bounds of what's allowed in the Debian archive, but IMHO it shouldn't be.)

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

Bug#1029568: xsimd: tests fail on armhf: Cannot access memory, store location is not properly aligned

[Drew Parsons]

Source: xsimd
Followup-For: Bug #1029568

The source of the armhf test error is actually the -mfpu=neon added
explicitly in debian/rules to DEB_CXXFLAGS_MAINT_APPEND on armhf.

Remove this flag, then armhf tests pass.

As far as other arches go, in general they should pass tests now (running
scalar tests).  I checked that tests pass on ppc64 and mipsel, for
instance.

powerpc failed because it does not have "-march=native".
https://github.com/xtensor-stack/xsimd/pull/296/files fixed that for
ppc64, but replacing the "ppc64" reference in tests/CMakeLists.txt
with "ppc*" simply results in 0 tests running on powerpc (so no point
testing it).

Bug#1029140: cron-apt refuses to run when RUNSLEEP is set

[Ola Lundqvist]

Argh!

Can you run it with bash -x from cron? Hopefully it tells where it breaks

Den tis 24 jan. 2023 17:06Richard Rosner 
skrev:

> No, and it did send a mail.
>
> --
> Richard Rosner
>
> Studierendenschaft der RWTH Aachen University
> Fachschaft Materialwissenschaft und Werkstofftechnik
> Intzestraße 1
> 52072 Aachen
> Tel.: +49 241 80-95781
> rros...@fsmuw.rwth-aachen.de
> www.fsmuw.rwth-aachen.de
>
> Am Dienstag, 24. Januar 2023 16:44 CET, schrieb Ola Lundqvist <
> o...@inguza.com>:
>
>
> Did you get that kernel error?
>
> Den tis 24 jan. 2023 14:12Richard Rosner 
> skrev:
>
>> This is the output (not sure if attachments are possible here, so I put
>> it into the body):
>>
>> + export PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
>> + PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
>> + UMASK_TIGHT=077
>> + UMASK_APT=022
>> + umask 077
>> + STDOUT=
>> + ALLCONFIGS=
>> + '[' -n '' ']'
>> + '[' -z '' ']'
>> + CONFIG=/etc/cron-apt/config
>> + ALLCONFIGS=/etc/cron-apt/config
>> + LIBDIR=/var/lib/cron-apt
>> + SHAREDIR=/usr/share/cron-apt
>> ++ echo /etc/cron-apt/config
>> ++ sed 's|/|_-_|g'
>> + CONFIGDIRNAME=_-_etc_-_cron-apt_-_config
>> ++ mktemp -d -t cron-apt.XX
>> + TMPDIR=/tmp/cron-apt.X5DFeL
>> + '[' 0 -ne 0 ']'
>> + INITLOG=/tmp/cron-apt.X5DFeL/initlog
>> + RUNERROR=/tmp/cron-apt.X5DFeL/runerror
>> + RUNSYSLOG=/tmp/cron-apt.X5DFeL/runsyslog
>> + RUNLOG=/tmp/cron-apt.X5DFeL/runlog
>> + RUNMAIL=/tmp/cron-apt.X5DFeL/runmail
>> + ACTIONERROR=/tmp/cron-apt.X5DFeL/actionerror
>> + ACTIONSYSLOG=/tmp/cron-apt.X5DFeL/actionsyslog
>> + ACTIONLOG=/tmp/cron-apt.X5DFeL/actionlog
>> + ACTIONMAIL=/tmp/cron-apt.X5DFeL/actionmail
>> + TEMP=/tmp/cron-apt.X5DFeL/temp
>> + MAIL=/tmp/cron-apt.X5DFeL/mail
>> + DIFF=/tmp/cron-apt.X5DFeL/difftemp
>> + STATUS=/tmp/cron-apt.X5DFeL/status
>> + LOCKFILE=/var/lib/cron-apt/lockfile
>> + MAILCHDIR=/var/lib/cron-apt/_-_etc_-_cron-apt_-_config/mailchanges
>> + ERROR=/tmp/cron-apt.X5DFeL/_-_etc_-_cron-apt_-_config-error
>> + ACTIONDIR=/etc/cron-apt/action.d
>> + ACTIONCONFDIR=/etc/cron-apt/config.d
>> + MAILMSGDIR=/etc/cron-apt/mailmsg.d
>> + MAILONMSGSDIR=/etc/cron-apt/mailonmsgs
>> + SYSLOGONMSGSDIR=/etc/cron-apt/syslogonmsgs
>> + REFRAINFILE=/etc/cron-apt/refrain
>> + NOLOCKWARN=
>> + ERRORMSGDIR=/etc/cron-apt/errormsg.d
>> + SYSLOGMSGDIR=/etc/cron-apt/syslogmsg.d
>> + LOGMSGDIR=/etc/cron-apt/logmsg.d
>> + LOGDIR=/var/log/cron-apt
>> + LOG=/var/log/cron-apt/log
>> + LASTFULLMESSAGE=/var/log/cron-apt/lastfullmessage
>> + DIFFONCHANGES=prepend
>> + SUBJECTPREFIX=CRON-APT
>> + MAILTO=root
>> + MAILWIDTH=900
>> + SYSLOGON=upgrade
>> + MAILON=error
>> + EXITON=error
>> + DEBUG=verbose
>> + OPTIONS='-o quiet=1'
>> + DONTRUN=
>> + RUNSLEEP=3600
>> + MINTMPDIRSIZE=10
>> + APTCOMMAND=/usr/bin/apt-get
>> + HOSTNAME=
>> + DIFFIGNORE=
>> + DIFFONCHANGES=prepend
>> + export DEBIAN_FRONTEND=noninteractive
>> + DEBIAN_FRONTEND=noninteractive
>> + export LANG=C
>> + LANG=C
>> + export LC_ALL=C
>> + LC_ALL=C
>> + for cfg in $ALLCONFIGS
>> + '[' -f /etc/cron-apt/config ']'
>> + . /etc/cron-apt/config
>> ++ APTCOMMAND=/usr/bin/apt-get
>> ++ MAILTO=administra...@fsmuw.rwth-aachen.de
>> ++ MAILON=upgrade
>> ++ SYSLOGON=always
>> + test '' = yes
>> + . /usr/share/cron-apt/functions
>> + '[' -d /var/lib/cron-apt/_-_etc_-_cron-apt_-_config ']'
>> + '[' -d /var/lib/cron-apt/_-_etc_-_cron-apt_-_config/mailchanges ']'
>> + '[' -e /etc/cron-apt/refrain ']'
>> + checktmpsize
>> ++ stat --file-system --format=%S /tmp/cron-apt.X5DFeL
>> + SSIZE=4096
>> ++ stat --file-system --format=%a /tmp/cron-apt.X5DFeL
>> + FSCOUNT=1021394
>> + '[' 1021394 -lt 33554432 ']'
>> + '[' 4085576 -lt 10 ']'
>> ++ date
>> + echo 'CRON-APT RUN [/etc/cron-apt/config]: Tue Jan 24 13:15:27 CET 2023'
>> + '[' -n 3600 ']'
>> + '[' 3600 -gt 0 ']'
>> + '[' -z 10031 ']'
>> + TIME=842
>> + sleep 842
>> ++ date
>> + echo 'CRON-APT SLEEP: 842, Tue Jan 24 13:29:29 CET 2023'
>> + '[' -e /etc/cron-apt/refrain ']'
>> + checktmpsize
>> ++ stat --file-system --format=%S /tmp/cron-apt.X5DFeL
>> + SSIZE=4096
>> ++ stat --file-system --format=%a /tmp/cron-apt.X5DFeL
>> + FSCOUNT=1021393
>> + '[' 1021393 -lt 33554432 ']'
>> + '[' 4085572 -lt 10 ']'
>> + '[' -x /usr/bin/dotlockfile ']'
>> + dotlockfile -l -p -r 10 /var/lib/cron-apt/lockfile
>> + cp /tmp/cron-apt.X5DFeL/initlog /tmp/cron-apt.X5DFeL/runmail
>> + cp /tmp/cron-apt.X5DFeL/initlog /tmp/cron-apt.X5DFeL/runlog
>> + cp /tmp/cron-apt.X5DFeL/initlog /tmp/cron-apt.X5DFeL/runsyslog
>> + cp /tmp/cron-apt.X5DFeL/initlog /tmp/cron-apt.X5DFeL/runerror
>> + rm -f /tmp/cron-apt.X5DFeL/initlog
>> ++ run_parts /etc/cron-apt/action.d
>> ++ unset LANG LC_COLLATE LC_ALL
>> ++ '[' -z /etc/cron-apt/action.d ']'
>> ++ '[' '!' -d /etc/cron-apt/action.d ']'
>> +++ ls /etc/cron-apt/action.d
>> ++ for F in $(ls $1)
>> ++ expr '#0-update#' : '[[:alnum:]_-]\+$'
>> ++ for F in $(ls $1)
>> ++ expr 0-update : '[[:alnum:]_-]\+$'
>> ++ '[' -f /etc/cron-apt/action.d/0-update ']'

Bug#1029574: indent shebang bug and misses LFS support

[Helge Deller]

Package:  indent
Version: 2.2.12
Tags: hppa, patch, lfs, FTBFS

The indent package has a bug in the script "regression/TEST"
which starts with "#/bin/sh" instead of a correct
shebang which would be "#!/bin/sh". This leads to a FTBFS on
the hppa architecture when running virtualized in qemu-user.

Secondly it would be nice if the indent tool would be built
with large file support. Adding future=+lfs to DEB_BUILD_MAINT_OPTIONS
allows that.

Both are fixed with attached patch. Please apply for next upload.

Thanks,
Helge
diff -up ./debian/rules.org ./debian/rules
--- ./debian/rules.org	2023-01-24 17:39:34.776049427 +
+++ ./debian/rules	2023-01-24 14:56:10.178242729 +
@@ -2,6 +2,8 @@
 %:
 	dh $@
 
+export DEB_BUILD_MAINT_OPTIONS = future=+lfs
+
 package = indent
 
 override_dh_auto_clean:
diff -up ./regression/TEST.org ./regression/TEST
--- ./regression/TEST.org	2023-01-24 17:38:56.199680344 +
+++ ./regression/TEST	2023-01-24 17:39:06.359777551 +
@@ -1,4 +1,4 @@
-#/bin/sh
+#!/bin/sh
 
 # Compare the output of ../src/indent to correct output
 # generated by earlier versions

Bug#1029573: gnuserv: hangs while installing if xemacs21 is installed

[Andreas Beckmann]

Package: gnuserv
Version: 3.12.8-10
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

This is an automated install test with DEBIAN_FRONENT=noninteractive and 
stdin coming from /dev/null which got killed after reaching a timeout,
 so there is no log output :-(


0m52.2s DEBUG: Starting command: ['chroot', 
'/tmp/piupartss/dose/tmpvFoO9h/chroot', 'apt-get', '-y', 'install', 
'gnuserv=3.12.8-10']
89m52.2s ERROR: Terminating command due to excessive runtime
89m52.7s DUMP: 
  
  
  * Command was terminated after exceeding runtime limit (5340 s) *


gnuserv installs fine if emacs is already installed, but xemacs21 causes
(reproducibly) problems.


cheers,

Andreas

Bug#971068: Assertion failure in i915 intel_display.c#assert_plane() after resume from hibernation

[наб]

Booted with both, hibernated, resumed; full dmesg below.

Best,
-- >8 --
[0.00] Linux version 6.1.0-2-686-pae (debian-ker...@lists.debian.org) 
(gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 
SMP PREEMPT_DYNAMIC Debian 6.1.7-1 (2023-01-18)
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] signal: max sigframe size: 1440
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009f3ff] usable
[0.00] BIOS-e820: [mem 0x0009f400-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000d2000-0x000d3fff] reserved
[0.00] BIOS-e820: [mem 0x000dc000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xb5aa0fff] usable
[0.00] BIOS-e820: [mem 0xb5aa1000-0xb5aa6fff] reserved
[0.00] BIOS-e820: [mem 0xb5aa7000-0xb5bb9fff] usable
[0.00] BIOS-e820: [mem 0xb5bba000-0xb5c0efff] reserved
[0.00] BIOS-e820: [mem 0xb5c0f000-0xb5d07fff] usable
[0.00] BIOS-e820: [mem 0xb5d08000-0xb5f0efff] reserved
[0.00] BIOS-e820: [mem 0xb5f0f000-0xb5f17fff] usable
[0.00] BIOS-e820: [mem 0xb5f18000-0xb5f1efff] reserved
[0.00] BIOS-e820: [mem 0xb5f1f000-0xb5f64fff] usable
[0.00] BIOS-e820: [mem 0xb5f65000-0xb5f9efff] ACPI NVS
[0.00] BIOS-e820: [mem 0xb5f9f000-0xb5fe0fff] usable
[0.00] BIOS-e820: [mem 0xb5fe1000-0xb5ffefff] ACPI data
[0.00] BIOS-e820: [mem 0xb5fff000-0xb5ff] usable
[0.00] BIOS-e820: [mem 0x0001-0x00013fff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.5 present.
[0.00] DMI: TOSHIBA Satellite Pro U400/Satellite Pro U400, BIOS V5.00   
 10/26/2010
[0.00] tsc: Fast TSC calibration using PIT
[0.00] tsc: Detected 2261.093 MHz processor
[0.002643] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.002647] e820: remove [mem 0x000a-0x000f] usable
[0.002660] last_pfn = 0x14 max_arch_pfn = 0x100
[0.003508] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.003945] e820: update [mem 0xb7e0-0x] usable ==> reserved
[0.011459] found SMP MP-table at [mem 0x000f6f30-0x000f6f3f]
[0.011474] initial memory mapped: [mem 0x-0x0b3f]
[0.011481] Kernel/User page tables isolation: disabled on command line.
[0.020647] printk: log_buf_len: 4194304 bytes
[0.020653] printk: early log buf free: 128848(98%)
[0.020655] RAMDISK: [mem 0x366d7000-0x37362fff]
[0.020658] Allocated new RAMDISK: [mem 0x349cb000-0x35656ed5]
[0.029796] Move RAMDISK from [mem 0x366d7000-0x37362ed5] to [mem 
0x349cb000-0x35656ed5]
[0.029807] ACPI: Early table checksum verification disabled
[0.029812] ACPI: RSDP 0x000F6E70 24 (v02 TOSQCI)
[0.029819] ACPI: XSDT 0xB5FF4A00 7C (v01 TOSQCI TOSQCI00 
0604  LTP )
[0.029827] ACPI: FACP 0xB5FE5000 F4 (v03 T0SQCI TOSQCI00 
0604 ALAN 0001)
[0.029836] ACPI: DSDT 0xB5FE6000 009F7C (v02 TOSQCI CANTIGA  
0604 INTL 20061109)
[0.029842] ACPI: FACS 0xB5F9EFC0 40
[0.029847] ACPI: FACS 0xB5F9EFC0 40
[0.029852] ACPI: APIC 0xB5FFED1E 68 (v01 INTEL  CRESTLNE 
0604 LOHR 005A)
[0.029858] ACPI: HPET 0xB5FFED86 38 (v01 TOSQCI TOSQCI00 
0604 LOHR 005A)
[0.029863] ACPI: MCFG 0xB5FFEDBE 3C (v01 TOSQCI TOSQCI00 
0604 LOHR 005A)
[0.029868] ACPI: APIC 0xB5FFEDFA 68 (v01 PTLTD  ? APIC   
0604  LTP )
[0.029874] ACPI: BOOT 0xB5FFEE62 28 (v01 PTLTD  $SBFTBL$ 
0604  LTP 0001)
[0.029879] ACPI: SLIC 0xB5FFEE8A 000176 (v01 TOSQCI TOSQCI00 
0604  LTP )
[0.029884] ACPI: SSDT 0xB5FF4AA4 000196 (v01 SataRe SataAhci 
1000 INTL 20061109)
[0.029890] ACPI: SSDT 0xB5FE4000 000655 (v01 PmRef  CpuPm
3000 INTL 20061109)
[0.029896] ACPI: SSDT 0xB5FE3000 000259 (v01 PmRef  Cpu0Tst  
3000 INTL 20061109)
[0.029901] ACPI: SSDT 0xB5FE2000 00020F (v01 PmRef  ApTst
3000 INTL 20061109)
[0.029906] ACPI: Reserving FACP table memory at [mem 0xb5fe5000-0xb5fe50f3]
[0.029908] ACPI: Reserving DSDT table memory at [mem 0xb5fe6000-0xb5feff7b]
[0.029910] ACPI: Reserving FACS table memory at [mem 0xb5f9efc0-0xb5f9efff]
[0.029912] ACPI: Reserving FACS table memory at [mem 0xb5f9efc0-0xb5f9efff]
[0.029914] ACPI: Reserving APIC table memory at [mem 0xb5ffed1e-0xb5ffed85]
[0.029916] ACPI: Reserving HPET table memory at [mem 0xb5ffed86-0xb5ffedbd]
[0.029918] ACPI: 

Bug#1029572: adduser: [INTL:de] updated German po file translation

[Helge Kreutzmann]

Package: adduser
Version: 3.130
Severity: wishlist
Tags: patch l10n

Please find the updated German po file translation for adduser
attached.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# German translation of adduser
# Copyright © 2000, 2006 Free Software Foundation, Inc.
# Copyright © Roland Bauerschmidt , 2000.
# Copyright © Dr. Tobias Quathamer , 2006, 2010, 2017, 2022.
# Copyright © Dr. Helge Kreutzmann , 2023.
# This file is distributed under the same license as the adduser package.
msgid ""
msgstr ""
"Project-Id-Version: adduser 3.130\n"
"Report-Msgid-Bugs-To: addu...@packages.debian.org\n"
"POT-Creation-Date: 2022-12-28 08:34+0100\n"
"PO-Revision-Date: 2023-01-24 18:09+0100\n"
"Last-Translator: Helge Kreutzmann \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms:  nplurals=2; plural=(n != 1);\n"

#. everyone can issue "--help" and "--version", but only root can go on
#: ../adduser:161
msgid "Only root may add a user or group to the system.\n"
msgstr "Nur root darf Benutzer oder Gruppen zum System hinzufügen.\n"

#: ../adduser:191 ../deluser:145
msgid "Only one or two names allowed.\n"
msgstr "Nur ein oder zwei Name(n) erlaubt.\n"

#: ../adduser:197
msgid "Specify only one name in this mode.\n"
msgstr "Geben Sie in diesem Modus nur einen Namen an.\n"

#: ../adduser:200
msgid "addgroup with two arguments is an unspecified operation.\n"
msgstr "addgroup mit zwei Argumenten ist eine unspezifizierte Aktion.\n"

#: ../adduser:224
msgid "The --group, --ingroup, and --gid options are mutually exclusive.\n"
msgstr ""
"Die Optionen --group, --ingroup und --gid schließen sich gegenseitig aus.\n"

#: ../adduser:229
msgid "The home dir must be an absolute path.\n"
msgstr "Das Home-Verzeichnis muss ein absoluter Pfad sein.\n"

#: ../adduser:233
#, perl-format
msgid "Warning: The home dir %s you specified already exists.\n"
msgstr ""
"Warnung: Das von Ihnen angegebene Home-Verzeichnis %s existiert bereits.\n"

#: ../adduser:235
#, perl-format
msgid "Warning: The home dir %s you specified can't be accessed: %s\n"
msgstr ""
"Warnung: Auf das von Ihnen angegebene Home-Verzeichnis %s kann nicht "
"zugegriffen werden: %s\n"

#: ../adduser:305
#, perl-format
msgid "The group `%s' already exists as a system group. Exiting.\n"
msgstr "Die Gruppe »%s« existiert bereits als Systemgruppe. Programmende.\n"

#: ../adduser:310
#, perl-format
msgid "The group `%s' already exists and is not a system group. Exiting.\n"
msgstr ""
"Die Gruppe »%s« existiert bereits und ist keine Systemgruppe. Programmende.\n"

#: ../adduser:315
#, perl-format
msgid "The group `%s' already exists, but has a different GID. Exiting.\n"
msgstr ""
"Die Gruppe »%s« existiert bereits, hat aber eine andere GID. Programmende.\n"

#: ../adduser:320 ../adduser:354
#, perl-format
msgid "The GID `%s' is already in use.\n"
msgstr "Die GID »%s« wird bereits verwendet.\n"

#: ../adduser:330
#, perl-format
msgid ""
"No GID is available in the range %d-%d (FIRST_SYS_GID - LAST_SYS_GID).\n"
msgstr ""
"Es ist keine GID im Bereich %d-%d verfügbar (FIRST_SYS_GID - LAST_SYS_GID).\n"

#: ../adduser:331 ../adduser:372
#, perl-format
msgid "The group `%s' was not created.\n"
msgstr "Gruppe »%s« wurde nicht angelegt.\n"

#: ../adduser:336 ../adduser:376
#, perl-format
msgid "Adding group `%s' (GID %d) ...\n"
msgstr "Lege Gruppe »%s« (GID %d) an …\n"

#: ../adduser:340 ../adduser:380 ../adduser:404 ../deluser:366 ../deluser:400
#: ../deluser:440
msgid "Done.\n"
msgstr "Fertig.\n"

#: ../adduser:351 ../adduser:991
#, perl-format
msgid "The group `%s' already exists.\n"
msgstr "Die Gruppe »%s« existiert bereits.\n"

#: ../adduser:371
#, perl-format
msgid "No GID is available in the range %d-%d (FIRST_GID - LAST_GID).\n"
msgstr "Es ist keine GID im Bereich %d-%d verfügbar (FIRST_GID - LAST_GID).\n"

#: ../adduser:390 ../deluser:235 ../deluser:408
#, perl-format
msgid "The user `%s' does not exist.\n"
msgstr "Der Benutzer »%s« existiert nicht.\n"

#: ../adduser:391 ../adduser:784 ../adduser:997 ../deluser:373 ../deluser:411
#, perl-format
msgid "The group `%s' does not exist.\n"
msgstr "Die Gruppe »%s« existiert nicht.\n"

#: ../adduser:394 ../adduser:788
#, perl-format
msgid "The user `%s' is already a member of `%s'.\n"
msgstr "Der Benutzer »%s« ist bereits ein Mitglied der Gruppe »%s«.\n"

#: ../adduser:398 ../adduser:794
#, perl-format
msgid "Adding user `%s' to group `%s' ...\n"
msgstr "Füge Benutzer »%s« der Gruppe »%s« hinzu …\n"

#: ../adduser:418
#, perl-format
msgid "The system user `%s' already exists. Exiting.\n"
msgstr "Der Systembenutzer »%s« existiert bereits. Programmende.\n"

#: ../adduser:421
#, perl-format
msgid "The user `%s' already exists, but is not a 

Bug#1029570: sc-im: debian/copyright file seems to be inaccurate

[Francesco Poli (wintermute)]

Package: sc-im
Version: 0.8.3+ds-1
Severity: serious
Justification: Policy 4.5

Hello!
Thanks for packaging this interesting program.

I noticed that the [debian/copyright] file seems to be inaccurate
with respect to the [upstream license].

The [debian/copyright] file states:

  [...]
  Files: *
  Copyright: 2013-2021, Andrés Martinelli 
  License: BSD-4-Clause
  [...]

which looks accurate, but then the documented license text
is not a verbatim copy of the [upstream license].

Most notably, clause 3 (out of 4) is missing.
Other minor differences are present.

Please fix the debian/copyright file by including the
correct verbatim copy of the upstream license text.

[debian/copyright]: 

[upstream license]: 


Please note that clause 3 is the infamous "obnoxious advertising
clause" [OAC], which, unfortunately, makes the 4-clause BSD license
GPL-incompatible.

[OAC]: 

As a consequence, I would also recommend to not license
debian/* files under GPL-2+, since having two incompatible
licenses in the same package is risky (it could lead to
a legally undistributable package, unless much care is
taken to never mix the two parts up...).
Maybe debian/* files could be relicensed under the terms
of some non-copyleft permissive license (such as
the Expat license or maybe the 3-clause BSD license...),
if the copyright holder (Joshua Peisach) agrees.


In the meanwhile, it would be really nice, if upstream could
be persuaded to drop the [OAC], thus relicensing the program
under the terms of the 3-clause BSD license.
Why? Because the 4-clause BSD license is a deprecated license,
which causes many GPL-compatibility troubles in the rare cases
where it is still used.
Since the upstream program copyright is currently held by one
sole person, it is still pretty easy to switch to a better
license: only one guy to be persuaded!   :-)

Please try and get in touch with upstream about this.

Thanks for your time and dedication!
Bye.

Bug#969482: ITP: glab -- An open-source GitLab command line tool

[Antoine Beaupré]

On 2020-09-03 16:21:32, TODO wrote:
> Package: wnpp
> Severity: wishlist
> Owner: TODO 
>
> * Package name: glab
>   Version : 1.10.0-1
>   Upstream Author : Clement Sam
> * URL : https://github.com/profclems/glab

Hi Clement Sam!

You filed this ITP (Intent To Package) back in 2020, do you still intend
on publishing your work in Debian?

I see there was a packaging discussion here:

https://gitlab.com/gitlab-org/cli/-/issues/205

... but it was closed in favor of using makedeb.org, which we typically
do not favor in debian.org itself. :)

As things stand now, you are the owner of this bug and others might be
respectfully waiting for you to complete the work instead of jumping in
and bringing glab in Debian per se. If you do not intend to continue
this work, let us know and someone else might step up. :)

As for packaging this inside Debian, I was hoping our tools would give
us a rough estimate but, alas, it seems like dh-make-golang still fails
sometimes:

anarcat@curie:dist$ dh-make-golang estimate gitlab.com/gitlab-org/cli
go get: 258.03 MiBpackage gitlab.com/gitlab-org/cli/cmd/gen-docs: cannot find 
package "github.com/hashicorp/hcl/hcl/printer" in any of:
/usr/lib/go-1.19/src/github.com/hashicorp/hcl/hcl/printer (from $GOROOT)
/tmp/dh-make-golang2745715808/src/github.com/hashicorp/hcl/hcl/printer 
(from $GOPATH)
2023/01/24 12:14:11 estimate: go get: exit status 1
anarcat@curie:dist[1]$ 

The makedeb "Debian package" is also pretty useless for our work here
because it only specifies golang as a dependency:

makedepends=('golang-go>=2:1.13')

so we don't actually know if we need to package more deps here...

Anyways, let us know where things are so we can move forward
here. Thanks!

a.
-- 
The problem is not a lack of highly educated workers, the problem is a
lack of highly educated workers willing to work for the minimum wage or
lower in the U.S. Costs are driving outsourcing, not the quality of
American schools.   - Scott Kirwin, IT Professionals Association

Bug#1029571: nageru: please build with sha1 to let lld link correctly

[Gianfranco Costamagna]

Source: nageru
Version: 2.2.0-2
tags: patch

Hello, with newer toolchains the default changed to sha256 IIRC, and lld fails 
to link objects

See: e.g. 
https://launchpadlibrarian.net/647717885/buildlog_ubuntu-lunar-arm64.nageru_2.2.0-2ubuntu1_BUILDING.txt.gz
debugedit: debian/nageru/usr/bin/kaeru: Unknown DWARF DW_FORM_0x1f20
debugedit: Cannot handle 8-byte build ID
dh_strip: error: debugedit --build-id --build-id-seed=nageru/2.2.0-2ubuntu1 
debian/nageru/usr/bin/kaeru returned exit code 1
debugedit: Cannot handle 8-byte build ID
dh_strip: error: debugedit --build-id --build-id-seed=futatabi/2.2.0-2ubuntu1 
debian/futatabi/usr/bin/futatabi returned exit code 1
dh_strip: error: Aborting due to earlier error
make: *** [debian/rules:9: binary-arch] Error 25
dpkg-buildpackage: error: fakeroot debian/rules binary-arch subprocess returned 
exit status 2

To avoid failures with lld-15, the suggestion is to add this on rules file:

ifneq (, $(shell which lld))
  export DEB_LDFLAGS_MAINT_APPEND += -fuse-ld=lld -Wl,--build-id=sha1
endif


after the

export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed -latomic

line.
This way you will be compatible with llvm-14 and llvm-15 and future releases.


BTW according to your build log, you are using bfd linker, not lld, this is 
probably why its still working in Debian

Build dir: /nageru-2.2.0/obj-x86_64-linux-gnu
Build type: native build
Project name: nageru
Project version: 2.2.0
C++ compiler for the host machine: c++ (gcc 12.2.0 "c++ (Debian 12.2.0-14) 
12.2.0")
C++ linker for the host machine: c++ ld.bfd 2.40.50.20230111
Host machine cpu family: x86_64
Host machine cpu: x86_64


G.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#757249: ITP: fonts-ekmukta -- humanist, mono-linear typeface for Devanagari and Latin scripts

[Bastian Germann]

Control: tags -1 wontfix

The font source is only available in the FontLab Studio vfb format.
There is no DFSG-free software for building a font from it or converting it to 
another format.

So this cannot be part of Debian. You can ask upstream to convert the font and 
work with a
different format as source (e.g. UFO).

Bug#1029569: fails to estimate: cannot find package "github.com/hashicorp/hcl/hcl/printer"

[Antoine Beaupre]

Package: dh-make-golang
Version: 0.6.0-2+b1
Severity: normal

I'm getting this while trying to do an estimate for #969482:

anarcat@curie:dist$ dh-make-golang estimate gitlab.com/gitlab-org/cli
go get: 258.03 MiBpackage gitlab.com/gitlab-org/cli/cmd/gen-docs: cannot find 
package "github.com/hashicorp/hcl/hcl/printer" in any of:
/usr/lib/go-1.19/src/github.com/hashicorp/hcl/hcl/printer (from $GOROOT)
/tmp/dh-make-golang2745715808/src/github.com/hashicorp/hcl/hcl/printer 
(from $GOPATH)
2023/01/24 12:14:11 estimate: go get: exit status 1
anarcat@curie:dist[1]$ 

I'm not sure what's going on here, maybe the import path is a little
weird (the hcl/printer subpath?) and is confusing
dh-make-golang... But in any case, it seems to me it shouldn't fail
outright and just mark that dependency as an unknown for manual
inspection...


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.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 dh-make-golang depends on:
ii  git   1:2.39.0-1
ii  git-buildpackage  0.9.30
ii  golang-any2:1.19~1
ii  libc6 2.36-8
ii  pristine-tar  1.50

Versions of packages dh-make-golang recommends:
ii  golang-golang-x-tools   1:0.2.0+ds-2
ii  postfix [mail-transport-agent]  3.7.3-4

dh-make-golang suggests no packages.

-- no debconf information

Bug#1028976: SVG support

[Ondřej Surý]

Thanks for the hint. I’ve realized that there might be SVG support external (as 
a plug-in) and that’s exactly the case. I’ve added -extra to autopkgtest 
control file as it does contain the dynamically loaded plugin for SVG files.

Ondrej
--
Ondřej Surý  (He/Him)

> On 24. 1. 2023, at 10:48, William Desportes  wrote:
> 
> Upstream said it was missing SVG support, but it's now fixed.
> Ref: https://github.com/Imagick/imagick/issues/575#issuecomment-1401630623
> 

Bug#970278: smartlist: please make the build reproducible

[Santiago Vila]

tags 970278 + moreinfo
tags 970278 - patch
thanks

Hi. To summarize: I'd appreciate a more detailed explanation about why
the patch is needed (if it's needed at all at this point).

Note: I have just switched to dh, which means the build now uses
dh_strip_nondeterminism (I guess this always helps).

Thanks.

Bug#1029568: xsimd: tests fail on armhf: Cannot access memory, store location is not properly aligned

[Drew Parsons]

Source: xsimd
Version: 10.0.0-1
Severity: normal
Control: forwarded -1 https://github.com/xtensor-stack/xsimd/issues/889

The build of xsimd 10.0.0-1 fails on armhf due to test failure:

test_xsimd: ./include/xsimd/types/xsimd_batch.hpp:567: void xsimd::batch::store_aligned(U*) const [with U = unsigned char; T = unsigned char; A = 
xsimd::neon]: Assertion `((reinterpret_cast(mem) % A::alignment()) 
== 0) && "store location is not properly aligned"' failed.

A gdb backtrace shows that xsimd::neon is involved:

Reading symbols from ./test_xsimd...
(gdb) run
Starting program: 
/home/xsimd/xsimd-10.0.0/obj-arm-linux-gnueabihf/test/test_xsimd 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[doctest] doctest version is "2.4.9"
[doctest] run with "--help" for options
test_xsimd: ./include/xsimd/types/xsimd_batch.hpp:567: void xsimd::batch::store_aligned(U*) const [with U = unsigned char; T = unsigned char; A = 
xsimd::neon]: Assertion `((reinterpret_cast(mem) % A::alignment()) 
== 0) && "store location is not properly aligned"' failed.

Program received signal SIGABRT, Aborted.
__libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:47
47  ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: No such file or 
directory.
(gdb) bt
#0  __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:47
#1  0xf7cce42c in __pthread_kill_implementation (threadid=4160618528, 
signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:43
#2  0xf7cce470 in __pthread_kill_internal (signo=6, threadid=) 
at pthread_kill.c:78
#3  0xf7c9d322 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4  0xf7c8e0ac in __GI_abort () at abort.c:79
#5  0xf7c98850 in __assert_fail_base (fmt=0x20 , assertion=0x122e7dc "((reinterpret_cast(mem) % 
A::alignment()) == 0) && \"store location is not properly aligned\"", 
assertion@entry=0xfffeed60 "", 
file=file@entry=0x20 , 
line=line@entry=567, function=0x122e76c "void xsimd::batch::store_aligned(U*) const [with U = unsigned char; T = unsigned char; A = 
xsimd::neon]", function@entry=0xf7fe0020 "") at assert.c:92
#6  0xf7c988ce in __GI___assert_fail (assertion=0xfffeed60 "", file=0x20 
, line=567, function=0xf7fe0020 
"") at assert.c:101
#7  0x00eb4c86 in xsimd::batch::store_aligned (mem=0xfffeee68 
"`b@\001\060\357\376\377\250\356\376\377\267\356\376\377$b@\001\307\356\376\377\001\001\001\001\001\001\001\001
 a?\001\001\001\001\001 a?\001\001\062)
at ./include/xsimd/types/xsimd_batch.hpp:567
#8  0x00f2c8b0 in xsimd::batch::store_aligned (mem=, 
this=) at ./test/test_batch.cpp:707
#9  xsimd::kernel::swizzle (self=...) at 
./include/xsimd/types/../arch/./xsimd_neon.hpp:2602
#10 xsimd::swizzle (mask=..., x=...) at 
./include/xsimd/types/xsimd_api.hpp:2048
#11 xsimd::kernel::detail::reduce(xsimd::batch const&, xsimd::generic 
const&)::{lambda(xsimd::batch const&, 
xsimd::batch const&)#1}, xsimd::neon, unsigned 
char, 16u>(xsimd::kernel::reduce_max(xsimd::batch const&, xsimd::generic 
const&)::{lambda(xsimd::batch const&, 
xsimd::batch const&)#1}, xsimd::batch const&, std::integral_constant) (op=..., 
self=...) at 
./include/xsimd/types/../arch/././generic/xsimd_generic_math.hpp:2000
#12 xsimd::kernel::reduce_max (self=...) at 
./include/xsimd/types/../arch/././generic/xsimd_generic_math.hpp:2009
#13 xsimd::reduce_max (x=...) at 
./include/xsimd/types/xsimd_api.hpp:905
#14 batch_test 
>::test_horizontal_operations (this=this@entry=0xfffef050) at 
./test/test_batch.cpp:708
#15 0x00eb in DOCTEST_ANON_TMP_623 > () at 
./test/test_batch.cpp:881
#16 0x00e1c036 in doctest::Context::run (this=this@entry=0xfffef3f0) at 
/usr/include/doctest/doctest.h:6930
#17 0x00e07bf6 in main (argc=, argv=) at 
/usr/include/doctest/doctest.h:7008


It might be best to treat armhf as a non-supported arch
(i.e. don't run build-time tests, perhaps not debian/tests either)
at least until upstream resolves
https://github.com/xtensor-stack/xsimd/issues/889

That said, it might now be possible to treat armel as a supported
arch. Diagnosing the armhf problem on the Debian porterbox
amdahl.debian.org, the sigabrt is reproducible on an armhf chroot. But
testing also in a armel chroot, the tests pass.

xsimd is supposed to have fixed scalar tests on "non-supported"
architectures, e.g. https://github.com/xtensor-stack/xsimd/pull/785
So possibly that is what passed on armel. If that is
the case then it might be safe to run xsimd tests on all arches
(meaning that scalar tests would be run on non-supported arches).

But in any case it looks like we should skip armhf tests for the time
being.

Bug#1029567: ITP: python-pyutil -- library of useful Python functions and classes

[Andrius Merkys]

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

* Package name: python-pyutil
  Version : 0.0~git20221225.46c0611
  Upstream Author : tpltnt 
* URL : https://github.com/tpltnt/pyutil
* License : GPL-2.0+ or SPL-1+ or TGPPL-1.0+
  Programming Lang: Python
  Description : library of useful Python functions and classes

Many of these utilities (or their ancestors) were developed originally 
by Zooko Wilcox-O'Hearn for the Mojo Nation, Mnet, Allmydata.com 
Mountain View, Tahoe-LAFS, or SimpleGeo's products.


python-pyutil is needed by tahoe-lafs.

Remark: This package is to be maintained with Debian Python Team at
   https://salsa.debian.org/python-team/packages/python-pyutil

Bug#1008220: Help needed to finalise the oneTBB migration of flexbar

[Andreas Tille]

Control: tags -1 help

Hi,

I made some progress[1] in converting flexbar (which seems to be
orphaned upstream[2] so we are on our own with the migration - but the
program ist interesting anyway) but finally have hit a blocker which
you can see in the build in Salsa CI[3].

It would be great if someone could help me over this blocker.

Kind regards
   Andreas.


[1] 
https://salsa.debian.org/med-team/flexbar/-/blob/master/debian/patches/onetbb.patch
[2] https://github.com/seqan/flexbar/issues/38
[3] https://salsa.debian.org/med-team/flexbar/-/jobs/3820125

-- 
http://fam-tille.de

Bug#1029566: transition: shibboleth-sp

[Ferenc Wágner]

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

Dear Release Team,

When reporting #1028286 (transition: xml-security-c) I totally missed
that one of the mentioned planned upper layer uploads is the
shibboleth-sp 3.3 -> 3.4 upgrade, which, contrary to the xml-security-c
transition, actually entails an SONAME change.  Since this wasn't
explicit in the original bug, we decided to ask for your ACK again.
As you can see in the autogenerated tracker at
https://release.debian.org/transitions/html/auto-shibboleth-sp.html,
there are only two reverse dependencies, both of which are internal to
the Shibboleth ecosystem (thus maintained by us) and both build without
changes against shibboleth-sp 3.4.1+dfsg-1.

Ben file:

title = "shibboleth-sp";
is_affected = .depends ~ "libshibsp10" | .depends ~ "libshibsp11";
is_good = .depends ~ "libshibsp11";
is_bad = .depends ~ "libshibsp10";

Bug#1029565: RFS: linux/6.1.8-1 -- Linux for amd64 new stable release [NMU] [RC]

[vmxevilstar]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : linux
   Version  : 6.1.8-1
   Upstream contact : debian-ker...@lists.debian.org
 * URL  : https://www.kernel.org/
 * License  : Unicode-data, LGPL-2.1, GPL-2+-or-X11, CRYPTOGAMS, 
LGPL-2.1 or BSD-2-clause, GPL-2 or BSD-2-clause, GPL-2, Xen-interface
 * Vcs  : https://salsa.debian.org/kernel-team/linux
   Section  : kernel

The source builds the following binary packages:
  
bpftool-dbgsym_7.1.0+6.1.8-1_amd64.deb  - Inspection and simple
manipulation of BPF programs and maps debug symbols   
bpftool_7.1.0+6.1.8-1_amd64.deb - Inspection and simple manipulation of
BPF programs and maps
hyperv-daemons-dbgsym_6.1.8-1_amd64.deb   - Support daemons for Linux
running on Hyper-V debug symbols
hyperv-daemons_6.1.8-1_amd64.deb - Support daemons for Linux running on
Hyper-V
libcpupower-dev_6.1.8-1_amd64.deb - CPU frequency and voltage scaling
tools for Linux (development files)
libcpupower1-dbgsym_6.1.8-1_amd64.deb - CPU frequency and voltage
scaling tools for Linux (libraries) debug symbols  
libcpupower1_6.1.8-1_amd64.deb - CPU frequency and voltage scaling
tools for Linux (libraries)
linux-compiler-gcc-12-x86_6.1.8-1_amd64.deb - Compiler for Linux on
amd64    
linux-config-6.1_6.1.8-1_amd64.deb - Debian kernel configurations for
Linux 6.1
linux-cpupower-dbgsym_6.1.8-1_amd64.deb- CPU power management tools for
Linuxdebug symbols
linux-cpupower_6.1.8-1_amd64.deb - CPU power management tools for Linux
linux-doc-6.1_6.1.8-1_all.deb - Linux kernel specific documentation
(meta-package)
linux-doc_6.1.8-1_all.deb - Linux kernel specific documentation for
version 6.1.8
linux-headers-6.1.0-0-amd64_6.1.8-1_amd64.deb - Header files for Linux
6.1.8-1-amd64  
linux-headers-6.1.0-0-cloud-amd64_6.1.8-1_amd64.deb - Header files for
Linux 6.1.8-cloud-amd64
linux-headers-6.1.0-0-common-rt_6.1.8-1_all.deb - Common header files
for Linux 6.1.8-rt-amd64  
linux-headers-6.1.0-0-common_6.1.8-1_all.deb - Common header files for
Linux 6.1.8  
linux-headers-6.1.0-0-rt-amd64_6.1.8-1_amd64.deb - Common header files
for Linux 6.1.8-rt  
linux-image-6.1.0-0-amd64-dbg_6.1.8-1_amd64.deb - Debug symbols for
linux-image-6.1.8-amd64  
linux-image-6.1.0-0-amd64-unsigned_6.1.8-1_amd64.deb - Linux 6.1.8 for
64-bit PCs
linux-image-6.1.0-0-cloud-amd64-dbg_6.1.8-1_amd64.deb - Debug symbols
for linux-image-6.1.8-cloud-amd64  
linux-image-6.1.0-0-cloud-amd64-unsigned_6.1.8-1_amd64.deb - Linux
6.1.8 for x86-64 cloud
linux-image-6.1.0-0-rt-amd64-dbg_6.1.8-1_amd64.deb - Debug symbols for
linux-image-6.1.8-rt-amd64  
linux-image-6.1.0-0-rt-amd64-unsigned_6.1.8-1_amd64.deb - Linux 6.1.8
for 64-bit PCs, PREEMPT_RT
linux-image-amd64-dbg_6.1.8-1_amd64.deb - Debug symbols for linux-
image-6.1.8-amd64
linux-image-amd64-signed-template_6.1.8-1_amd64.deb - Linux 6.1.8 for
amd64 cloud signed  
linux-image-cloud-amd64-dbg_6.1.8-1_amd64.deb - Debug symbols for Linux
6.1.8 cloud
linux-image-rt-amd64-dbg_6.1.8-1_amd64.deb - Debug symbols for Linux
6.1.8 for 64-bit PCs, PREEMPT_RT
linux-kbuild-6.1-dbgsym_6.1.8-1_amd64.deb - Kbuild infrastructure for
Linux 6.1.8 Debug symbols  
linux-kbuild-6.1_6.1.8-1_amd64.deb - Kbuild infrastructure for Linux
6.1.8
linux-libc-dev_6.1.8-1_amd64.deb - Linux support headers for userspace
development  
linux-perf-dbgsym_6.1.8-1_amd64.deb - Performance analysis tools for
Linux Debug symbols  
linux-perf_6.1.8-1_amd64.deb - Performance analysis tools for Linux   
linux-source-6.1_6.1.8-1_all.deb - Linux kernel source for version
6.1.8 with Debian patches  
linux-source_6.1.8-1_all.deb - Linux kernel source (meta-package)
linux-support-6.1.0-0_6.1.8-1_all.deb - Support files for Linux 6.1.8 
rtla_6.1.8-1_amd64.deb - Real-Time Linux Analysis tools
usbip-dbgsym_2.0+6.1.8-1_amd64.deb - USB device sharing system over IP
network Debug Symbols

To access further information about this package, please visit the following 
URL:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029553

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

  dget -x
https://mentors.debian.net/debian/pool/main/l/linux/linux_6.1.8-1.dsc

Changes since the last upload:

 linux (6.1.8-1) unstable; urgency=medium
https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.8
- soc: qcom: apr: Make qcom,protection-domain optional again
- wifi: Revert "wifi: mac80211: fix memory leak in
ieee80211_if_add()"
- block: mq-deadline: Rename deadline_is_seq_writes()
- net/mlx5: fix missing mutex_unlock in
mlx5_fw_fatal_reporter_err_work()
- net/mlx5: Add missing mutex_unlock() before returning from
- octeontx2-pf: Fix the use of GFP_KERNEL in atomic context on rt
- net/ulp: use consistent error code when blocking ULP
 

Bug#1029140: cron-apt refuses to run when RUNSLEEP is set

[Richard Rosner]

No, and it did send a mail.

-- 
Richard Rosner

Studierendenschaft der RWTH Aachen University
Fachschaft Materialwissenschaft und Werkstofftechnik
Intzestraße 1
52072 Aachen
Tel.: +49 241 80-95781
rros...@fsmuw.rwth-aachen.de
www.fsmuw.rwth-aachen.de

Am Dienstag, 24. Januar 2023 16:44 CET, schrieb Ola Lundqvist :
 Did you get that kernel error? Den tis 24 jan. 2023 14:12Richard Rosner 
 skrev:This is the output (not sure if 
attachments are possible here, so I put it into the body):
+ export PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
+ PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
+ UMASK_TIGHT=077
+ UMASK_APT=022
+ umask 077
+ STDOUT=
+ ALLCONFIGS=
+ '[' -n '' ']'
+ '[' -z '' ']'
+ CONFIG=/etc/cron-apt/config
+ ALLCONFIGS=/etc/cron-apt/config
+ LIBDIR=/var/lib/cron-apt
+ SHAREDIR=/usr/share/cron-apt
++ echo /etc/cron-apt/config
++ sed 's|/|_-_|g'
+ CONFIGDIRNAME=_-_etc_-_cron-apt_-_config
++ mktemp -d -t cron-apt.XX
+ TMPDIR=/tmp/cron-apt.X5DFeL
+ '[' 0 -ne 0 ']'
+ INITLOG=/tmp/cron-apt.X5DFeL/initlog
+ RUNERROR=/tmp/cron-apt.X5DFeL/runerror
+ RUNSYSLOG=/tmp/cron-apt.X5DFeL/runsyslog
+ RUNLOG=/tmp/cron-apt.X5DFeL/runlog
+ RUNMAIL=/tmp/cron-apt.X5DFeL/runmail
+ ACTIONERROR=/tmp/cron-apt.X5DFeL/actionerror
+ ACTIONSYSLOG=/tmp/cron-apt.X5DFeL/actionsyslog
+ ACTIONLOG=/tmp/cron-apt.X5DFeL/actionlog
+ ACTIONMAIL=/tmp/cron-apt.X5DFeL/actionmail
+ TEMP=/tmp/cron-apt.X5DFeL/temp
+ MAIL=/tmp/cron-apt.X5DFeL/mail
+ DIFF=/tmp/cron-apt.X5DFeL/difftemp
+ STATUS=/tmp/cron-apt.X5DFeL/status
+ LOCKFILE=/var/lib/cron-apt/lockfile
+ MAILCHDIR=/var/lib/cron-apt/_-_etc_-_cron-apt_-_config/mailchanges
+ ERROR=/tmp/cron-apt.X5DFeL/_-_etc_-_cron-apt_-_config-error
+ ACTIONDIR=/etc/cron-apt/action.d
+ ACTIONCONFDIR=/etc/cron-apt/config.d
+ MAILMSGDIR=/etc/cron-apt/mailmsg.d
+ MAILONMSGSDIR=/etc/cron-apt/mailonmsgs
+ SYSLOGONMSGSDIR=/etc/cron-apt/syslogonmsgs
+ REFRAINFILE=/etc/cron-apt/refrain
+ NOLOCKWARN=
+ ERRORMSGDIR=/etc/cron-apt/errormsg.d
+ SYSLOGMSGDIR=/etc/cron-apt/syslogmsg.d
+ LOGMSGDIR=/etc/cron-apt/logmsg.d
+ LOGDIR=/var/log/cron-apt
+ LOG=/var/log/cron-apt/log
+ LASTFULLMESSAGE=/var/log/cron-apt/lastfullmessage
+ DIFFONCHANGES=prepend
+ SUBJECTPREFIX=CRON-APT
+ MAILTO=root
+ MAILWIDTH=900
+ SYSLOGON=upgrade
+ MAILON=error
+ EXITON=error
+ DEBUG=verbose
+ OPTIONS='-o quiet=1'
+ DONTRUN=
+ RUNSLEEP=3600
+ MINTMPDIRSIZE=10
+ APTCOMMAND=/usr/bin/apt-get
+ HOSTNAME=
+ DIFFIGNORE=
+ DIFFONCHANGES=prepend
+ export DEBIAN_FRONTEND=noninteractive
+ DEBIAN_FRONTEND=noninteractive
+ export LANG=C
+ LANG=C
+ export LC_ALL=C
+ LC_ALL=C
+ for cfg in $ALLCONFIGS
+ '[' -f /etc/cron-apt/config ']'
+ . /etc/cron-apt/config
++ APTCOMMAND=/usr/bin/apt-get
++ MAILTO=administra...@fsmuw.rwth-aachen.de
++ MAILON=upgrade
++ SYSLOGON=always
+ test '' = yes
+ . /usr/share/cron-apt/functions
+ '[' -d /var/lib/cron-apt/_-_etc_-_cron-apt_-_config ']'
+ '[' -d /var/lib/cron-apt/_-_etc_-_cron-apt_-_config/mailchanges ']'
+ '[' -e /etc/cron-apt/refrain ']'
+ checktmpsize
++ stat --file-system --format=%S /tmp/cron-apt.X5DFeL
+ SSIZE=4096
++ stat --file-system --format=%a /tmp/cron-apt.X5DFeL
+ FSCOUNT=1021394
+ '[' 1021394 -lt 33554432 ']'
+ '[' 4085576 -lt 10 ']'
++ date
+ echo 'CRON-APT RUN [/etc/cron-apt/config]: Tue Jan 24 13:15:27 CET 2023'
+ '[' -n 3600 ']'
+ '[' 3600 -gt 0 ']'
+ '[' -z 10031 ']'
+ TIME=842
+ sleep 842
++ date
+ echo 'CRON-APT SLEEP: 842, Tue Jan 24 13:29:29 CET 2023'
+ '[' -e /etc/cron-apt/refrain ']'
+ checktmpsize
++ stat --file-system --format=%S /tmp/cron-apt.X5DFeL
+ SSIZE=4096
++ stat --file-system --format=%a /tmp/cron-apt.X5DFeL
+ FSCOUNT=1021393
+ '[' 1021393 -lt 33554432 ']'
+ '[' 4085572 -lt 10 ']'
+ '[' -x /usr/bin/dotlockfile ']'
+ dotlockfile -l -p -r 10 /var/lib/cron-apt/lockfile
+ cp /tmp/cron-apt.X5DFeL/initlog /tmp/cron-apt.X5DFeL/runmail
+ cp /tmp/cron-apt.X5DFeL/initlog /tmp/cron-apt.X5DFeL/runlog
+ cp /tmp/cron-apt.X5DFeL/initlog /tmp/cron-apt.X5DFeL/runsyslog
+ cp /tmp/cron-apt.X5DFeL/initlog /tmp/cron-apt.X5DFeL/runerror
+ rm -f /tmp/cron-apt.X5DFeL/initlog
++ run_parts /etc/cron-apt/action.d
++ unset LANG LC_COLLATE LC_ALL
++ '[' -z /etc/cron-apt/action.d ']'
++ '[' '!' -d /etc/cron-apt/action.d ']'
+++ ls /etc/cron-apt/action.d
++ for F in $(ls $1)
++ expr '#0-update#' : '[[:alnum:]_-]\+$'
++ for F in $(ls $1)
++ expr 0-update : '[[:alnum:]_-]\+$'
++ '[' -f /etc/cron-apt/action.d/0-update ']'
++ echo /etc/cron-apt/action.d/0-update
++ for F in $(ls $1)
++ expr 3-download : '[[:alnum:]_-]\+$'
++ '[' -f /etc/cron-apt/action.d/3-download ']'
++ echo /etc/cron-apt/action.d/3-download
+ for ACTION in $(run_parts "$ACTIONDIR")
++ echo /etc/cron-apt/action.d/0-update
++ sed 's|/etc/cron-apt/action.d/||'
+ ACTIONF=0-update
+ '[' -f /etc/cron-apt/config.d/0-update ']'
+ echo 'CRON-APT ACTION: 0-update'
+ echo 'CRON-APT ACTION: 0-update'
+ echo 'CRON-APT ACTION: 0-update'
+ echo 'CRON-APT ACTION: 0-update'
+ herevariables_store
+ general_varmove HERE STORED

Bug#902981: Font Awesome v5 in Debian

[Jonas Smedegaard]

Quoting Bastian Germann (2023-01-24 16:28:59)
> X-Debbugs-Cc: sebas...@xs4all.nl
> 
> On Thu, 27 Sep 2018 17:31:55 -0400 Alexandre Viau  wrote:
> > For software to be considered to be included in Debian, it must be free 
> > software. We try to evaluate whether or not something is free software 
> > by using the Debian Free Software Guidelines (DFSG)[1].
> > 
> > Font Awesome matches the DFSG on all points except one:
> > 
> >  > The program must include source code, and must allow distribution in 
> > source code as well as compiled form.
> > 
> > Font Awesome v5 is only available in compiled form, without the build 
> > tool. This makes it incompatible with our definition of Free Software.
> > 
> > To help explain our definition of source code, we often refer to "All 
> > sources in their preferred form of modification".
> > 
> > For example, minified JavaScript would fail that definition, even if it 
> > could technically be considered as modifiable code.
> > 
> > Is there something that could be done so that Font-Awesome v5 can match 
> > this interpretation of what is free software?
> > 
> > 1. https://www.debian.org/social_contract#guidelines
> 
> When you search Debian it turns out, Font Awesome 5 is around in A LOT of 
> packages.
> A good starting point is 
> https://lintian.debian.org/tags/font-in-non-font-package.
> It will take a lot of effort to get it out. I have started at #1025000.
> 
> I agree with Alexandre here but there seem to be people that ignore this 
> sentiment
> as you can see at #1027982. How would we go about it?

Thanks for looking into this, Bastian.

You are correct in filing such bugs with high severity.

If the reaction as seen with bug#1027982 is more widespread, you might
consider adding a usertag to those bugreports, to ease later raising as
a general concern to debian-devel the issue of relaxed treatment of
licensing violations.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1029140: cron-apt refuses to run when RUNSLEEP is set

[Ola Lundqvist]

Did you get that kernel error?

Den tis 24 jan. 2023 14:12Richard Rosner 
skrev:

> This is the output (not sure if attachments are possible here, so I put it
> into the body):
>
> + export PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
> + PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
> + UMASK_TIGHT=077
> + UMASK_APT=022
> + umask 077
> + STDOUT=
> + ALLCONFIGS=
> + '[' -n '' ']'
> + '[' -z '' ']'
> + CONFIG=/etc/cron-apt/config
> + ALLCONFIGS=/etc/cron-apt/config
> + LIBDIR=/var/lib/cron-apt
> + SHAREDIR=/usr/share/cron-apt
> ++ echo /etc/cron-apt/config
> ++ sed 's|/|_-_|g'
> + CONFIGDIRNAME=_-_etc_-_cron-apt_-_config
> ++ mktemp -d -t cron-apt.XX
> + TMPDIR=/tmp/cron-apt.X5DFeL
> + '[' 0 -ne 0 ']'
> + INITLOG=/tmp/cron-apt.X5DFeL/initlog
> + RUNERROR=/tmp/cron-apt.X5DFeL/runerror
> + RUNSYSLOG=/tmp/cron-apt.X5DFeL/runsyslog
> + RUNLOG=/tmp/cron-apt.X5DFeL/runlog
> + RUNMAIL=/tmp/cron-apt.X5DFeL/runmail
> + ACTIONERROR=/tmp/cron-apt.X5DFeL/actionerror
> + ACTIONSYSLOG=/tmp/cron-apt.X5DFeL/actionsyslog
> + ACTIONLOG=/tmp/cron-apt.X5DFeL/actionlog
> + ACTIONMAIL=/tmp/cron-apt.X5DFeL/actionmail
> + TEMP=/tmp/cron-apt.X5DFeL/temp
> + MAIL=/tmp/cron-apt.X5DFeL/mail
> + DIFF=/tmp/cron-apt.X5DFeL/difftemp
> + STATUS=/tmp/cron-apt.X5DFeL/status
> + LOCKFILE=/var/lib/cron-apt/lockfile
> + MAILCHDIR=/var/lib/cron-apt/_-_etc_-_cron-apt_-_config/mailchanges
> + ERROR=/tmp/cron-apt.X5DFeL/_-_etc_-_cron-apt_-_config-error
> + ACTIONDIR=/etc/cron-apt/action.d
> + ACTIONCONFDIR=/etc/cron-apt/config.d
> + MAILMSGDIR=/etc/cron-apt/mailmsg.d
> + MAILONMSGSDIR=/etc/cron-apt/mailonmsgs
> + SYSLOGONMSGSDIR=/etc/cron-apt/syslogonmsgs
> + REFRAINFILE=/etc/cron-apt/refrain
> + NOLOCKWARN=
> + ERRORMSGDIR=/etc/cron-apt/errormsg.d
> + SYSLOGMSGDIR=/etc/cron-apt/syslogmsg.d
> + LOGMSGDIR=/etc/cron-apt/logmsg.d
> + LOGDIR=/var/log/cron-apt
> + LOG=/var/log/cron-apt/log
> + LASTFULLMESSAGE=/var/log/cron-apt/lastfullmessage
> + DIFFONCHANGES=prepend
> + SUBJECTPREFIX=CRON-APT
> + MAILTO=root
> + MAILWIDTH=900
> + SYSLOGON=upgrade
> + MAILON=error
> + EXITON=error
> + DEBUG=verbose
> + OPTIONS='-o quiet=1'
> + DONTRUN=
> + RUNSLEEP=3600
> + MINTMPDIRSIZE=10
> + APTCOMMAND=/usr/bin/apt-get
> + HOSTNAME=
> + DIFFIGNORE=
> + DIFFONCHANGES=prepend
> + export DEBIAN_FRONTEND=noninteractive
> + DEBIAN_FRONTEND=noninteractive
> + export LANG=C
> + LANG=C
> + export LC_ALL=C
> + LC_ALL=C
> + for cfg in $ALLCONFIGS
> + '[' -f /etc/cron-apt/config ']'
> + . /etc/cron-apt/config
> ++ APTCOMMAND=/usr/bin/apt-get
> ++ MAILTO=administra...@fsmuw.rwth-aachen.de
> ++ MAILON=upgrade
> ++ SYSLOGON=always
> + test '' = yes
> + . /usr/share/cron-apt/functions
> + '[' -d /var/lib/cron-apt/_-_etc_-_cron-apt_-_config ']'
> + '[' -d /var/lib/cron-apt/_-_etc_-_cron-apt_-_config/mailchanges ']'
> + '[' -e /etc/cron-apt/refrain ']'
> + checktmpsize
> ++ stat --file-system --format=%S /tmp/cron-apt.X5DFeL
> + SSIZE=4096
> ++ stat --file-system --format=%a /tmp/cron-apt.X5DFeL
> + FSCOUNT=1021394
> + '[' 1021394 -lt 33554432 ']'
> + '[' 4085576 -lt 10 ']'
> ++ date
> + echo 'CRON-APT RUN [/etc/cron-apt/config]: Tue Jan 24 13:15:27 CET 2023'
> + '[' -n 3600 ']'
> + '[' 3600 -gt 0 ']'
> + '[' -z 10031 ']'
> + TIME=842
> + sleep 842
> ++ date
> + echo 'CRON-APT SLEEP: 842, Tue Jan 24 13:29:29 CET 2023'
> + '[' -e /etc/cron-apt/refrain ']'
> + checktmpsize
> ++ stat --file-system --format=%S /tmp/cron-apt.X5DFeL
> + SSIZE=4096
> ++ stat --file-system --format=%a /tmp/cron-apt.X5DFeL
> + FSCOUNT=1021393
> + '[' 1021393 -lt 33554432 ']'
> + '[' 4085572 -lt 10 ']'
> + '[' -x /usr/bin/dotlockfile ']'
> + dotlockfile -l -p -r 10 /var/lib/cron-apt/lockfile
> + cp /tmp/cron-apt.X5DFeL/initlog /tmp/cron-apt.X5DFeL/runmail
> + cp /tmp/cron-apt.X5DFeL/initlog /tmp/cron-apt.X5DFeL/runlog
> + cp /tmp/cron-apt.X5DFeL/initlog /tmp/cron-apt.X5DFeL/runsyslog
> + cp /tmp/cron-apt.X5DFeL/initlog /tmp/cron-apt.X5DFeL/runerror
> + rm -f /tmp/cron-apt.X5DFeL/initlog
> ++ run_parts /etc/cron-apt/action.d
> ++ unset LANG LC_COLLATE LC_ALL
> ++ '[' -z /etc/cron-apt/action.d ']'
> ++ '[' '!' -d /etc/cron-apt/action.d ']'
> +++ ls /etc/cron-apt/action.d
> ++ for F in $(ls $1)
> ++ expr '#0-update#' : '[[:alnum:]_-]\+$'
> ++ for F in $(ls $1)
> ++ expr 0-update : '[[:alnum:]_-]\+$'
> ++ '[' -f /etc/cron-apt/action.d/0-update ']'
> ++ echo /etc/cron-apt/action.d/0-update
> ++ for F in $(ls $1)
> ++ expr 3-download : '[[:alnum:]_-]\+$'
> ++ '[' -f /etc/cron-apt/action.d/3-download ']'
> ++ echo /etc/cron-apt/action.d/3-download
> + for ACTION in $(run_parts "$ACTIONDIR")
> ++ echo /etc/cron-apt/action.d/0-update
> ++ sed 's|/etc/cron-apt/action.d/||'
> + ACTIONF=0-update
> + '[' -f /etc/cron-apt/config.d/0-update ']'
> + echo 'CRON-APT ACTION: 0-update'
> + echo 'CRON-APT ACTION: 0-update'
> + echo 'CRON-APT ACTION: 0-update'
> + echo 'CRON-APT ACTION: 0-update'
> + herevariables_store
> + general_varmove HERE STORED
> + PREFIX=HERE
> + STORE=STORED
> 

Bug#1029377: pipewire-pulse: Please remove Recommends: pipewire-alsa

[eeickmeyer]

Hi Dylan,

On Tue, 2023-01-24 at 11:02 +0100, Dylan Aïssi wrote:
> Hello Erich,
> 
> Le dim. 22 janv. 2023 à 00:45, Erich Eickmeyer
>  a écrit :
> > 
> > The introduction of the "Recommends: pipewire-alsa" line in the
> > debian/control
> > file has reintroduced the problem resolved by bug #1020903 in which
> > pipewire-
> > pulse is causing a conflict with pulseaudio, albiet indirectly this
> > time.
> > 
> > As pipewire-pulse is now soft-depending on pipewire-alsa, which
> > does directly
> > conflict with pulseaudio. This is causing a package conflict,
> > especialy when
> > seeded, when pulseaudio is installed and is causing the Ubuntu
> > Studio seed to
> > fail to build.
> > 
> > Ubuntu Studio was intending to include, in their built-in-house
> > Studio Controls
> > utility, a way to easily switch between the traditional
> > Pulseaudio/JACK setup
> > and the Pipewire setup. Unfortunately, this recommends line,
> > however well-
> > intentioned, completely broke that.
> > 
> > My recommendation is to demote pulseaudio-alsa to a Suggests in
> > this case.
> > 
> 
> I removed pipewire-alsa from depends field of pipewire-pulse.
> Instead, I created
> a new metapackage pipewire-audio that depends on a set of pipewire
> packages
> recommended for a standard audio use of pipewire. A large part of bug
> reports
> against pipewire and wireplumber are mainly from users with broken
> config because
> they don't follow/install recommended packages. I guess this new
> package should
> make that clearer.
> 
> I agree that pulseaudio and pipewire-pulse can be installed together
> at same time,
> but for whatever reasons several users have reported conflicts
> between them. And
> it seems easier (at least for standard users of pipewire for audio)
> to
> add a conflict
> between them, but I guess users of Ubuntu Studio don't have a
> standard use of
> pipewire. This brings me to the question, why do you want both
> pulseaudio and
> pipewire-pulse to be co-installable?
> 
> Best regards,
> Dylan

We're planning on having pipewire with pipewire-jack as the default
configuration, but switchable via the enabling/disabling of services
using our built-in-house (but available to all distros) Studio Controls
utility (https://github.com/ovenwerks/studio-controls). The reason for
this is that there's currently no feasible way to bridge JACK to
pipewire, so having the "old school" pulseaudio setup and
starting/stopping JACK on demand as we've done in the past so that
workflows aren't broken and that professional audio users can still get
work done the way they always have.

Unfortunately, the pipewire-jack configuration isn't quite ready for
professional audio, but will work for most users, which is why we need
this particular configuration. Additionally, some Firewire audio aren't
supported under ALSA and require a completely different backend
(FFADO), and pipewire lacks the facility to support those interfaces.

So, as you can see, there's multiple reasons why we'd want to keep both
pipewire and pulseaudio installed simultaneously.

--
Erich Eickmeyer
Ubuntu Studio Project Leader
Ubuntu MOTU

Bug#1028634: tiledarray: FTBFS: Could not find a package configuration file provided by "blaspp"

[Adrian Bunk]

Control: reassign -1 libbtas-dev 0.0+git20221014.147bf4d4-1
Control: retitle -1 libbtas-dev requires blaspp
Control: affects -1 src:tiledarray

On Fri, Jan 13, 2023 at 11:59:48PM +0100, Sebastian Ramacher wrote:
> Source: tiledarray
> Version: 1.0.0-1
> Severity: serious
> Tags: ftbfs
>...
> blasppConfig.cmake
> blaspp-config.cmake
> 
>   Add the installation prefix of "blaspp" to CMAKE_PREFIX_PATH or set
>   "blaspp_DIR" to a directory containing one of the above files.  If "blaspp"
>   provides a separate development package or SDK, be sure it has been
>   installed.
> Call Stack (most recent call first):
>   /usr/lib/cmake/BTAS/btas-config.cmake:104 (find_dependency)
>   cmake/modules/FindOrFetchBTAS.cmake:1 (find_package)
>   CMakeLists.txt:279 (include)

This looks like a problem in libbtas-dev (unpackaged dependency blaspp?).

> Cheers

cu
Adrian

Bug#902981: Font Awesome v5 in Debian

[Bastian Germann]

X-Debbugs-Cc: sebas...@xs4all.nl

On Thu, 27 Sep 2018 17:31:55 -0400 Alexandre Viau  wrote:
For software to be considered to be included in Debian, it must be free 
software. We try to evaluate whether or not something is free software 
by using the Debian Free Software Guidelines (DFSG)[1].


Font Awesome matches the DFSG on all points except one:

 > The program must include source code, and must allow distribution in 
source code as well as compiled form.


Font Awesome v5 is only available in compiled form, without the build 
tool. This makes it incompatible with our definition of Free Software.


To help explain our definition of source code, we often refer to "All 
sources in their preferred form of modification".


For example, minified JavaScript would fail that definition, even if it 
could technically be considered as modifiable code.


Is there something that could be done so that Font-Awesome v5 can match 
this interpretation of what is free software?


1. https://www.debian.org/social_contract#guidelines


When you search Debian it turns out, Font Awesome 5 is around in A LOT of 
packages.
A good starting point is 
https://lintian.debian.org/tags/font-in-non-font-package.
It will take a lot of effort to get it out. I have started at #1025000.

I agree with Alexandre here but there seem to be people that ignore this 
sentiment
as you can see at #1027982. How would we go about it?

Bug#1029564: ITP: python-fingerprints -- Compare the names of companies and people with normalisation

[Edward Betts]

Package: wnpp
Severity: wishlist
Owner: Edward Betts 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python-fingerprints
  Version : 1.0.3
  Upstream Author : Friedrich Lindenberg 
* URL : https://github.com/alephdata/fingerprints
* License : MIT
  Programming Lang: Python
  Description : Compare the names of companies and people with normalisation

  Generate fingerprints for entity data. A fingerprint in this context is
  understood as a simplified entity identifier, derived from it's name or
  address and used for cross-referencing of entity across different datasets.
  .
  Examples:
  .
- Mr. Sherlock Holmes -> holmes sherlock
- Siemens Aktiengesellschaft -> ag siemens
- New York, New York -> new york
 
I plan to maintain this package as part of the Python team.

Bug#1029563: CVE-2022-47951: vulnerability in VMDK image processing

[Thomas Goirand]

Package: glance-api
Version: 2:25.0.0-1.1
Severity: grave
Tags: patch

This is an advance warning of a vulnerability discovered in
OpenStack, to give you, as downstream stakeholders, a chance to
coordinate the release of fixes and reduce the vulnerability window.
Please treat the following information as confidential until the
proposed public disclosure date.

Title: Arbitrary file access through custom VMDK flat descriptor
Reporter: Guillaume Espanel, Pierre Libeau, Arnaud Morin and Damien
  Rannou (OVH)
Products: Cinder, Glance, Nova
Affects: Cinder <19.1.2, >=20.0.0 <20.0.2, ==21.0.0;
 Glance <23.0.1, >=24.0.0 <24.1.1, ==25.0.0;
 Nova <24.1.2, >=25.0.0 <25.0.2, ==26.0.0

Description:
Guillaume Espanel, Pierre Libeau, Arnaud Morin and Damien Rannou
(OVH) reported a vulnerability in VMDK image processing for Cinder,
Glance and Nova. By supplying a specially created VMDK flat image
which references a specific backing file path, an authenticated user
may convince systems to return a copy of that file's contents from
the server resulting in unauthorized access to potentially sensitive
data. All Cinder deployments are affected; only Glance deployments
with image conversion enabled are affected; all Nova deployments are
affected.

Proposed patch:
See attached patches. Unless a flaw is discovered in them, these
patches will be merged to their corresponding branches on the public
disclosure date. Note that stable/wallaby and older branches are
under extended maintenance and will receive no new point releases,
but patches for some of them are provided as a courtesy.

CVE: CVE-2022-47951

Proposed public disclosure date/time:
2023-01-24, 1500UTC
Please do not make the issue public (or release public patches)
before this coordinated embargo date.

Original private report:
https://launchpad.net/bugs/1996188
For access to read and comment on this report, please reply to me
with your Launchpad username and I will subscribe you.
-- 
Jeremy Stanley
OpenStack Vulnerability Management Team

Bug#1029562: CVE-2022-47951: vulnerability in VMDK image processing

[Thomas Goirand]

Package: python3-cinder
Version: 2:21.0.0-2
Severity: grave
Tags: patch

This is an advance warning of a vulnerability discovered in
OpenStack, to give you, as downstream stakeholders, a chance to
coordinate the release of fixes and reduce the vulnerability window.
Please treat the following information as confidential until the
proposed public disclosure date.

Title: Arbitrary file access through custom VMDK flat descriptor
Reporter: Guillaume Espanel, Pierre Libeau, Arnaud Morin and Damien
  Rannou (OVH)
Products: Cinder, Glance, Nova
Affects: Cinder <19.1.2, >=20.0.0 <20.0.2, ==21.0.0;
 Glance <23.0.1, >=24.0.0 <24.1.1, ==25.0.0;
 Nova <24.1.2, >=25.0.0 <25.0.2, ==26.0.0

Description:
Guillaume Espanel, Pierre Libeau, Arnaud Morin and Damien Rannou
(OVH) reported a vulnerability in VMDK image processing for Cinder,
Glance and Nova. By supplying a specially created VMDK flat image
which references a specific backing file path, an authenticated user
may convince systems to return a copy of that file's contents from
the server resulting in unauthorized access to potentially sensitive
data. All Cinder deployments are affected; only Glance deployments
with image conversion enabled are affected; all Nova deployments are
affected.

Proposed patch:
See attached patches. Unless a flaw is discovered in them, these
patches will be merged to their corresponding branches on the public
disclosure date. Note that stable/wallaby and older branches are
under extended maintenance and will receive no new point releases,
but patches for some of them are provided as a courtesy.

CVE: CVE-2022-47951

Proposed public disclosure date/time:
2023-01-24, 1500UTC
Please do not make the issue public (or release public patches)
before this coordinated embargo date.

Original private report:
https://launchpad.net/bugs/1996188
For access to read and comment on this report, please reply to me
with your Launchpad username and I will subscribe you.
-- 
Jeremy Stanley
OpenStack Vulnerability Management Team

Bug#1029561: CVE-2022-47951: vulnerability in VMDK image processing

[Thomas Goirand]

Package: nova-compute
Version: 2:26.0.0-5
Severity: grave
Tags: patch

This is an advance warning of a vulnerability discovered in
OpenStack, to give you, as downstream stakeholders, a chance to
coordinate the release of fixes and reduce the vulnerability window.
Please treat the following information as confidential until the
proposed public disclosure date.

Title: Arbitrary file access through custom VMDK flat descriptor
Reporter: Guillaume Espanel, Pierre Libeau, Arnaud Morin and Damien
  Rannou (OVH)
Products: Cinder, Glance, Nova
Affects: Cinder <19.1.2, >=20.0.0 <20.0.2, ==21.0.0;
 Glance <23.0.1, >=24.0.0 <24.1.1, ==25.0.0;
 Nova <24.1.2, >=25.0.0 <25.0.2, ==26.0.0

Description:
Guillaume Espanel, Pierre Libeau, Arnaud Morin and Damien Rannou
(OVH) reported a vulnerability in VMDK image processing for Cinder,
Glance and Nova. By supplying a specially created VMDK flat image
which references a specific backing file path, an authenticated user
may convince systems to return a copy of that file's contents from
the server resulting in unauthorized access to potentially sensitive
data. All Cinder deployments are affected; only Glance deployments
with image conversion enabled are affected; all Nova deployments are
affected.

Proposed patch:
See attached patches. Unless a flaw is discovered in them, these
patches will be merged to their corresponding branches on the public
disclosure date. Note that stable/wallaby and older branches are
under extended maintenance and will receive no new point releases,
but patches for some of them are provided as a courtesy.

CVE: CVE-2022-47951

Proposed public disclosure date/time:
2023-01-24, 1500UTC
Please do not make the issue public (or release public patches)
before this coordinated embargo date.

Original private report:
https://launchpad.net/bugs/1996188
For access to read and comment on this report, please reply to me
with your Launchpad username and I will subscribe you.
-- 
Jeremy Stanley
OpenStack Vulnerability Management Team

Bug#1029560: ITP: obs-source-clone -- plugin for OBS Studio to clone sources from a scene

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho 
X-Debbugs-Cc: debian-de...@lists.debian.org, exel...@hotmail.com

* Package name: obs-source-clone
  Version : 0.1.1
  Upstream Author : Exeldro 
* URL : https://obsproject.com/forum/resources/source-clone.1632/
* License : GPL-2
  Programming Lang: C
  Description : plugin for OBS Studio to clone sources from a scene

This plugin lets to clone sources to allow different filters than the
original. The main idea is generate a new source type that gets sources
from a scene and clone them in current scene.

WARNING: Source Clone is not an async source. In OBS there are async
sources that can have more types of filters.

Bug#1028565: Acknowledgement (upgrade-reports: Audio breaks between 5.10.0-19-amd64 and 5.10.0-20-amd64)

[Michael Shuler]

This audio issue was resolved for me with the SoC updates included in 
stable linux-image:

  5.10.0-21-amd64 5.10.162-1 (2023-01-21) x86_64

For reference, my machine info:
  Product Name: 20QDCTO1WW
  Version: ThinkPad X1 Carbon 7th
  BIOS Version: N2HET68W (1.51)
  Audio PCI info:
  00:1f.3 Audio device [0403]: Intel Corporation Cannon Point-LP High 
Definition Audio Controller [8086:9dc8] (rev 11) (prog-if 80)


Thanks for this bug report, the build info and revert patch for -20, and 
for rolling in the additional SoC bits to make -21 work properly.


Kind regards,
Michael

Bug#1029559: sc-im FTBFS: link error

[Adrian Bunk]

Source: sc-im
Version: 0.8.3+ds-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=sc-im=0.8.3%2Bds-1

...
/usr/bin/ld: tui.o: warning: relocation against `COLORS' in read-only section 
`.text'
/usr/bin/ld: main.o: in function `sig_tstp':
./src/./src/main.c:633: undefined reference to `def_prog_mode'
/usr/bin/ld: ./src/./src/main.c:634: undefined reference to `endwin'
/usr/bin/ld: main.o: in function `sig_cont':
./src/./src/main.c:647: undefined reference to `reset_prog_mode'
/usr/bin/ld: ./src/./src/main.c:648: undefined reference to `stdscr'
/usr/bin/ld: ./src/./src/main.c:648: undefined reference to `wrefresh'
/usr/bin/ld: color.o: in function `redefine_color':
./src/./src/color.c:586: undefined reference to `has_colors'
/usr/bin/ld: ./src/./src/color.c:586: undefined reference to `can_change_color'
/usr/bin/ld: ./src/./src/color.c:594: undefined reference to 
`init_extended_color'
/usr/bin/ld: color.o: in function `define_color':
./src/./src/color.c:627: undefined reference to `has_colors'
/usr/bin/ld: ./src/./src/color.c:627: undefined reference to `can_change_color'
/usr/bin/ld: ./src/./src/color.c:627: undefined reference to `COLORS'
/usr/bin/ld: ./src/./src/color.c:661: undefined reference to 
`init_extended_color'
...
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:194: sc-im] Error 1

Bug#1029558: libahp-xc FTBFS: missing symbols

[Adrian Bunk]

Source: libahp-xc
Version: 1.3.3-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=libahp-xc=amd64=1.3.3-1%2Bb1=1674505043=0

...
   dh_makeshlibs -a
dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libahp-xc1/DEBIAN/symbols doesn't match 
completely debian/libahp-xc1.symbols
--- debian/libahp-xc1.symbols (libahp-xc1_1.3.3-1+b1_amd64)
+++ dpkg-gensymbolsmoIKwy   2023-01-23 20:17:16.748366045 +
...
+#MISSING: 1.3.3-1+b1# urj_vhdl_set_lineno@Base 1.3.3
+#MISSING: 1.3.3-1+b1# urj_vhdl_set_lval@Base 1.3.3
+#MISSING: 1.3.3-1+b1# urj_vhdl_set_out@Base 1.3.3
+#MISSING: 1.3.3-1+b1# urj_vhdl_wrap@Base 1.3.3
  wait_no_threads@Base 1.3.3
  wait_threads@Base 1.3.3
- xlx_bitstream_alloc@Base 1.3.3
- xlx_bitstream_free@Base 1.3.3
- xlx_bitstream_load_bit@Base 1.3.3
+#MISSING: 1.3.3-1+b1# xlx_bitstream_alloc@Base 1.3.3
+#MISSING: 1.3.3-1+b1# xlx_bitstream_free@Base 1.3.3
+#MISSING: 1.3.3-1+b1# xlx_bitstream_load_bit@Base 1.3.3
dh_makeshlibs: error: failing due to earlier errors
make: *** [debian/rules:7: binary-arch] Error 25



I don't know about the last 3 ones, but the rest looks as if libahp-xc
was listing symbols from liburjtag.

Bug#1019858: ITA: tcsh -- TENEX C Shell, an enhanced version of Berkeley csh

[Josef Schneider]

retitle 1019858 ITA: tcsh -- TENEX C Shell, an enhanced version of 
Berkeley csh


thanks

I request to adopt the package tcsh. I use this package and would like 
to maintain it.


--
Josef Schneider

GPG Fingerprint 3267 0331 DB61 A817 7D25 4D05 5A44 BC12 F2A8 E58F


OpenPGP_0x5A44BC12F2A8E58F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1017088: ITP: c4core -- library of low-level C++ utilities, written with low-latency projects in mind

[Daichi Fukui]

Hi all
CC: Iwamatsu-san

On Thu, 10 Nov 2022 21:57:30 +0900 Daichi Fukui <
when.a.cat.sits.beside@gmail.com> wrote:
> > > >> * Package name: c4core
> > > >>   Version : 0.1.9
> > > >>   Upstream Author : Joao Paulo Magalhaes 
> > > >> * URL : https://github.com/biojppm/c4core
> > > >> * License : MIT
> > > >>   Programming Lang: C++
> > > >>   Description : library of low-level C++ utilities, written
with
> > > low-latency projects in mind

I've uploaded the draft source package of c4core, which consists of
debian/master, upstream, pristine-tar [0].
When you have time, can you review it and help me upload to the archive?
Note that the upstream version was updated to 0.1.11.

As for the issue discussed earlier [1], I decided to keep fast_float.hpp
and fast_float_all.h header files embedded in c4core.
This is because they do not belong to src/c4/ext/debugbreak or
src/c4/ext/fast_float
in terms of source tree.

[0] https://salsa.debian.org/dfukui/c4core
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017088#30

Best,
Fukui

Bug#960339: ITP: adios2 -- Adaptable IO system for simulations

[Kyle Edwards]

On 1/24/23 09:33, Drew Parsons wrote:

affects 960339 src:fenics-dolfinx
thanks

VTX support in dolfinx requires adios2


I worked on this a few years ago but never finished, check out 
https://gitlab.kitware.com/debian/adios2 to see the progress I made.


Kyle

Bug#960339: ITP: adios2 -- Adaptable IO system for simulations

[Drew Parsons]

affects 960339 src:fenics-dolfinx
thanks

VTX support in dolfinx requires adios2

Bug#1029557: debian-edu-config: Session exits on first login on roaming-workstation fails

[Petter Reinholdtsen]

[Nico Winkelsträter]
> When a user tries to log in at a romaing workstation for the very first time
> the login prompt disappears, stays on the empty default-background for a few
> seconds and the returns to lightdm with a brief black-screen.
>
> On the second try everything works as expected.

This is by design.  There was (and probably still is) no way to change
$HOME from the PAM subsystem when the login already was in progress.  To
work around this limitiation the user is logged logged out on the first
try, after the home directory is created and /etc/passwd is updated with
the new home location, to ensure the new home directory is used during
future logins.  The home directory is changed from
/skole/tjener/home0/testes/ to /home/testes/ in your case.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1023438: dpkg-checkbuilddeps: allow satisfying :native Build-Depends with Multi-Arch: foreign packages

[Andreas Beckmann]

On Fri, 4 Nov 2022 06:58:07 +0100 Helmut Grohne  wrote:

I think dpkg-checkbuildeps should not reject a Multi-Arch: foreign
package satisfying a build dependency annotated :native. The internal


One package affected by this is src:reprepro in experimental where
dpkg-checkbuilddeps now rejects db-util:native (which gained
M-A: foreign in bookworm).

It may be useless to annotate an arch:all B-D package with :native (as 
src:reprepro/exoerimental currently does), or does the :native propagate 
to the non-arch:all dependencies of the annotated arch:all package?


Andreas

Bug#1029557: debian-edu-config: Session exits on first login on roaming-workstation fails

[Nico Winkelsträter]

Package: debian-edu-config
Version: 2.11.56+deb11u4
Severity: normal

Dear Maintainer,

When a user tries to log in at a romaing workstation for the very first time
the login prompt disappears, stays on the empty default-background for a few
seconds and the returns to lightdm with a brief black-screen.

On the second try everything works as expected.


I suspect that pam_mklocaluser does not properly initialize the environment
because the logs show some errors from pulseaudio as well as lightdm 
trying to

write to the wrong home directory:

Jan 24 14:08:38 am-5254007fbccd.intern pulseaudio[5100]: Failed to create
secure directory (/skole/tjener/home0/teste
s/.config/pulse): Datei oder Verzeichnis nicht gefunden

Jan 24 14:08:47 am-5254007fbccd.intern lightdm[5053]: Error writing X
authority: Failed to open X authority 
/skole/tjener/home0/testes/.Xauthority:

No such file or directory


This occurs on a debian-edu deployment which has been in use for about a 
year

and I could also reproduce this behavior locally on a fresh install with one
mainserver VM an one romaing-workstation VM.

Regards
Nico Winkelsträter


--
Mit freundlichen Grüßen

Nico Winkelsträter
Trainee Administrator

initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.

Phone:   +49 4105 56156-33
Fax: +49 4105 56156-10

Email:   nico.winkelstrae...@initos.com
Web: http://www.initos.com

Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Rosengarten – Klecken
Amtsgericht Tostedt, HRB 205226
Steuer-Nr: 15/200/53247
USt-IdNr: DE815580155Jan 24 14:08:37 am-5254007fbccd.intern lightdm[5053]: pam_sss(lightdm:auth): authentication success; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=testes
Jan 24 14:08:37 am-5254007fbccd.intern lightdm[5053]: gkr-pam: unable to locate daemon control file
Jan 24 14:08:37 am-5254007fbccd.intern lightdm[5053]: gkr-pam: stashed password to try later in open session
Jan 24 14:08:37 am-5254007fbccd.intern lightdm[5053]: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service files
Jan 24 14:08:37 am-5254007fbccd.intern lightdm[608]: g_dbus_connection_call_sync_internal: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
Jan 24 14:08:37 am-5254007fbccd.intern lightdm[608]: g_dbus_connection_call_sync_internal: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
Jan 24 14:08:37 am-5254007fbccd.intern systemd[1]: Stopping Session c8 of user lightdm.
Jan 24 14:08:37 am-5254007fbccd.intern lightdm[4969]: pam_unix(lightdm-greeter:session): session closed for user lightdm
Jan 24 14:08:37 am-5254007fbccd.intern systemd[1]: session-c8.scope: Succeeded.
Jan 24 14:08:37 am-5254007fbccd.intern systemd[1]: Stopped Session c8 of user lightdm.
Jan 24 14:08:37 am-5254007fbccd.intern systemd-logind[603]: Removed session c8.
Jan 24 14:08:37 am-5254007fbccd.intern lightdm[5053]: pam_unix(lightdm:session): session opened for user testes(uid=1007) by (uid=0)
Jan 24 14:08:37 am-5254007fbccd.intern systemd[1]: Created slice User Slice of UID 1007.
Jan 24 14:08:37 am-5254007fbccd.intern systemd[1]: Starting User Runtime Directory /run/user/1007...
Jan 24 14:08:37 am-5254007fbccd.intern pulseaudio[4990]: Unable to set sw params: Keine Berechtigung
Jan 24 14:08:37 am-5254007fbccd.intern pulseaudio[4990]: Failed to set software parameters: Keine Berechtigung
Jan 24 14:08:37 am-5254007fbccd.intern pulseaudio[4990]: Error opening PCM device front:0: Datei oder Verzeichnis nicht gefunden
Jan 24 14:08:37 am-5254007fbccd.intern systemd-logind[603]: New session 40 of user testes.
Jan 24 14:08:37 am-5254007fbccd.intern systemd[4973]: pulseaudio.service: Succeeded.
Jan 24 14:08:37 am-5254007fbccd.intern systemd[1]: Finished User Runtime Directory /run/user/1007.
Jan 24 14:08:37 am-5254007fbccd.intern systemd[1]: Starting User Manager for UID 1007...
Jan 24 14:08:37 am-5254007fbccd.intern systemd[5060]: pam_unix(systemd-user:session): session opened for user testes(uid=1007) by (uid=0)
Jan 24 14:08:37 am-5254007fbccd.intern systemd[5060]: Queued start job for default target Main User Target.
Jan 24 14:08:37 am-5254007fbccd.intern systemd[5060]: Created slice User Application Slice.
Jan 24 14:08:37 am-5254007fbccd.intern systemd[5060]: Reached target Paths.
Jan 24 14:08:37 am-5254007fbccd.intern systemd[5060]: Reached target Timers.
Jan 24 14:08:37 am-5254007fbccd.intern systemd[5060]: Starting D-Bus User Message Bus Socket.
Jan 24 14:08:37 am-5254007fbccd.intern systemd[5060]: Listening on GnuPG network certificate management daemon.
Jan 24 14:08:37 am-5254007fbccd.intern systemd[5060]: Listening on GnuPG cryptographic agent and passphrase cache (access for web browsers).
Jan 24 14:08:37 am-5254007fbccd.intern systemd[5060]: Listening on GnuPG cryptographic agent and passphrase cache (restricted).
Jan 24 14:08:37 am-5254007fbccd.intern systemd[5060]: Listening on GnuPG 

Bug#977294: nagios-plugins-contrib: (another) check_uptime is shipped with monitoring-plugins 2.3

[Jan Wagner]

Am 13.12.20 um 18:10 schrieb Jan Wagner:

Package: nagios-plugins-contrib
Severity: normal

Monitoring Plugins ships a check_uptime since version 2.3, see
https://github.com/monitoring-plugins/monitoring-plugins/commits/v2.3/plugins-scripts/check_uptime.pl

I would suggest to remove check_uptime from the package. If removing is
not an option, we should rename the script.


The check_uptime in monitoring-plugins is a script which has to be 
executed on the system that has to be monitored. The check_uptime of 
this package is working via SNMP and remote, so it's a completely 
different usecase.

Bug#1029547: RM: libcoq-ocaml-dev -- NBS; cruft

[Paul Tagliamonte]

On Tue, Jan 24, 2023 at 08:38:18AM -0500, Paul Tagliamonte wrote:
> Thanks! If you would be able to fix the r-deps to stop other packages
> from depending on a package that hasn't been built for a few months, we
> should be able to do this no problem. The auto-decrufter may even pick
> it up without humans after that's done :)

Sorry - one last note - if you do go about fixing this, since I did a rm
of coq-theories in #1029538 (which was safe as a one-off RM since it had
no r-deps), here's the *actual* command I want to run to decruft coq --
note it contains an additional binary package that no one has asked
about yet -- libcoq-ocaml.

dak rm -o -m "[auto-cruft] NBS (no longer built by coq)" -s unstable \
  -a amd64,arm64,armhf,i386,ppc64el,s390x -p -R -b libcoq-ocaml libcoq-ocaml-dev

Thanks for your work!
  Paul

-- 
:wq

Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing"

[Roland Rosenfeld]

Hi Fabian!

On Tue, 24 Jan 2023, fab...@greffrath.com wrote:

> Hi Sherlock,

:-)

> Could you please add a lintian overrides with a reference to this finding?

I just referenced http://bugs.debian.org/1029555 in the lintian-overrides.

> And probably file a bug against lintian?

Already did so: http://bugs.debian.org/1029555

> I guess this might have some impact on other packages providing
> Type1 font files as well.

Someone should update the wiki page referenced by lintian:
https://wiki.debian.org/qa.debian.org/type1nondfsg
I already replaced the links by links to archive.org (since the
original URLs are no longer existing), but maybe the sentence "Adobe
seems willing to relicense see mail here." should be updated pointing
to
https://github.com/adobe-type-tools/afdko/blob/develop/c/shared/source/t1write/t1write_hintothers.h

But I fear that I could make the page even worse, if I just change
it...

Greetings
Roland

Bug#1029556: espeak-ng: autopkgtest regression

[Gianfranco Costamagna]

Source: espeak-ng
Version: 1.51+dfsg-9
Severity: serious
tags: patch

Hello, autopkgtests started to fail I presume since llvm-default change.
To fix, you need to depend on clang-rt when you use fsanitize=fuzzer)

clang++ -DHAVE_CONFIG_H -I.   -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
-ffile-prefix-map=/tmp/autopkgtest-lxc.4x6n726o/downtmp/build.8AY/src=. 
-fstack-protector-strong -Wformat -Werror=format-security -c -o tests/dummy.o 
tests/dummy.cpp
/bin/bash ./libtool  --tag=CXX   --mode=link clang++  -g -O2 
-ffile-prefix-map=/tmp/autopkgtest-lxc.4x6n726o/downtmp/build.8AY/src=. 
-fstack-protector-strong -Wformat -Werror=format-security -fsanitize=fuzzer 
-Wl,-z,relro -o tests/ssml-fuzzer.test tests/ssml_fuzzer_test-ssml-fuzzer.o 
tests/dummy.o -lespeak-ng  -lsonic
libtool: link: clang++ -g -O2 
-ffile-prefix-map=/tmp/autopkgtest-lxc.4x6n726o/downtmp/build.8AY/src=. 
-fstack-protector-strong -Wformat -Werror=format-security -fsanitize=fuzzer 
-Wl,-z -Wl,relro -o tests/ssml-fuzzer.test tests/ssml_fuzzer_test-ssml-fuzzer.o 
tests/dummy.o  -lespeak-ng -lsonic
/usr/bin/ld: cannot find 
/usr/lib/llvm-14/lib/clang/14.0.6/lib/linux/libclang_rt.fuzzer-x86_64.a: No 
such file or directory
/usr/bin/ld: cannot find 
/usr/lib/llvm-14/lib/clang/14.0.6/lib/linux/libclang_rt.fuzzer_interceptors-x86_64.a:
 No such file or directory
/usr/bin/ld: cannot find 
/usr/lib/llvm-14/lib/clang/14.0.6/lib/linux/libclang_rt.ubsan_standalone-x86_64.a:
 No such file or directory
/usr/bin/ld: cannot find 
/usr/lib/llvm-14/lib/clang/14.0.6/lib/linux/libclang_rt.ubsan_standalone_cxx-x86_64.a:
 No such file or directory

This untested patch should do the trick:
 Tests: fuzz
 Architecture: amd64 arm64 i386
-Depends: @builddeps@, clang, libespeak-ng-dev
+Depends: @builddeps@, clang, clang-rt, libespeak-ng-dev

thanks

Gianfranco


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1029547: RM: libcoq-ocaml-dev -- NBS; cruft

[Paul Tagliamonte]

tags 1029547 + moreinfo
thanks

On Tue, Jan 24, 2023 at 10:53:49AM +0100, julien.pu...@gmail.com wrote:
> Dear FTP Team,
> 
> Please remove all libcoq-ocaml-dev (binary) packages from unstable. 

The (now) infamous coq package. It's on our cruft-report, but we're
unable to handle it very gracefully, since removing this package will
break r-deps. I've included the output[1] from
`mirror.ftp-master.debian.org` along with a removal command that we'd
run from ftp-master down below at[2]


> They correspond to an old coq source package, but coq has stopped
> building them for months.

Thanks! If you would be able to fix the r-deps to stop other packages
from depending on a package that hasn't been built for a few months, we
should be able to do this no problem. The auto-decrufter may even pick
it up without humans after that's done :)

[1]:

Checking reverse dependencies...
# Broken Depends:
coq-elpi: libcoq-elpi [amd64 arm64 i386 ppc64el]

# Broken Build-Depends:
coq-bignums: libcoq-ocaml-dev
coq-corn: libcoq-ocaml-dev
coq-deriving: libcoq-ocaml-dev
coq-dpdgraph: libcoq-ocaml-dev
coq-elpi: libcoq-ocaml-dev (8.15 >=)
coq-equations: libcoq-ocaml-dev
coq-ext-lib: libcoq-ocaml-dev
coq-extructures: libcoq-ocaml-dev
coq-gappa: libcoq-ocaml-dev
coq-hammer: libcoq-ocaml-dev
coq-hott: libcoq-ocaml-dev
coq-interval: libcoq-ocaml-dev
coq-iris: libcoq-ocaml-dev
coq-libhyps: libcoq-ocaml-dev
coq-math-classes: libcoq-ocaml-dev
coq-menhirlib: libcoq-ocaml-dev
coq-mtac2: libcoq-ocaml-dev
coq-quickchick: libcoq-ocaml-dev
coq-record-update: libcoq-ocaml-dev
coq-reduction-effects: libcoq-ocaml-dev
coq-reglang: libcoq-ocaml-dev
coq-relation-algebra: libcoq-ocaml-dev
coq-simple-io: libcoq-ocaml-dev
coq-stdpp: libcoq-ocaml-dev
coq-unicoq: libcoq-ocaml-dev
coq-unimath: libcoq-ocaml-dev
coqeal: libcoq-ocaml-dev
coqprime: libcoq-ocaml-dev
coquelicot: libcoq-ocaml-dev
flocq: libcoq-ocaml-dev
ott: libcoq-ocaml-dev
paramcoq: libcoq-ocaml-dev


[2]: 
 first `ssh mirror.ftp-master.debian.org`, and then run:
 dak rm -o -m "[auto-cruft] NBS (no longer built by coq)" -s unstable \
   -a amd64,arm64,armhf,i386,ppc64el,s390x -p -R -b libcoq-ocaml-dev
-- 
:wq

Bug#1022843: Bug#1029352: Bug#1022843: ifupdown: network down after systemctl restart

[Santiago Ruano Rincón]

Hi!

El 23/01/23 a las 16:19, Cyril Brulebois escribió:
> Hi Santiago,
> 
> Santiago Ruano Rincón  (2023-01-23):
> > Thanks everybody for the inputs. I've applied Paul's solution, and the
> > generated .deb can be downloaded from here:
> > 
> > https://salsa.debian.org/debian/ifupdown/-/jobs/3841392/artifacts/raw/debian/output/ifupdown_0.8.41~1.gbp3a6fae+salsaci+20230123+42_amd64.deb
> > 
> > Would it be possible for you (Oleg, Paul, Jeff, kibi et al.) to give it
> > a try?
> 
> (Reading your mail with s/Paul/Pascal/g in mind.)

Oups, sorry! Thanks for patching that too.

> 
> Tests yesterday seem to indicate successful results, but again I've only
> tested a few combinations in a VM (to keep the feedback loop short).
> 
> From the installer team point of view, I'd welcome a swift upload with
> this patch, possibly with urgency=high so that the fix reaches testing
> soon. This will another blocker out of the way for the next D-I release!

Just uploaded with your patched patch.

Cheers,

 -- S


signature.asc
Description: PGP signature

Bug#1029555: lintian: license-problem-font-adobe-copyrighted-fragment-no-credit false positive

[Roland Rosenfeld]

Package: lintian
Version: 2.116.1~bpo11+1
Severity: normal

Dear Maintainer,

during the work with fonts-urw-base35 https://bugs.debian.org/1029168
the lintian error
license-problem-font-adobe-copyrighted-fragment-no-credit was
triggered on all fonts, because of the following code in
lib/Lintian/Check/Fonts/Postscript/Type1.pm:

# If copy pasted from black book they are
# copyright adobe a few line before the only
# place where the startlock is documented is
# in the black book copyrighted fragment
if ($line =~ m/startlock\s*get\s*exec/) {

$self->pointed_hint(
'license-problem-font-adobe-copyrighted-fragment-no-credit',
$item->pointer);

last;
}

This refers to the following book:
https://web.archive.org/web/20150321034514/http://partners.adobe.com/public/developer/en/font/T1_SPEC.PDF
Appendix 3, page 95 (of the book) page 101 (of the PDF).

But while the code in the book contains 181 lines of code only the
following lines are used in the urw-base35 fonts:

{systemdict /internaldict known not
{pop 3}
{1183615869 systemdict /internaldict get exec
dup /startlock known
{/startlock get exec}
{dup /strtlck known
{/strtlck get exec}
{pop 3}
ifelse}
ifelse}
ifelse
} executeonly
] noaccess def


I searched for the number (1183615869) in afdko source and found the
following file:
https://github.com/adobe-type-tools/afdko/blob/develop/c/shared/source/t1write/t1write_hintothers.h

/* Copyright 2014 Adobe Systems Incorporated (http://www.adobe.com/). All 
Rights Reserved.
   This software is licensed as OpenSource, under the Apache License, Version 
2.0.
   This license is available at: http://opensource.org/licenses/Apache-2.0. */

"/OtherSubrs[{}{}{}{systemdict/internaldict known not{pop 3}{1183615869\n"
"systemdict/internaldict get exec dup/startlock known{/startlock get 
exec}{dup\n"
"/strtlck known{/strtlck get exec}{pop 3}ifelse}ifelse}ifelse}executeonly]def\n"

As far as I can see, that is exactly the code, that I found in the
urw-base35 fonts and that triggers the lintian error, but it is a
false positive, since the trigger ("startlock get exec") is now under
Apache-2.0 license and the rest of the Adobe code from the book isn't
used here.

So the lintian check should be changed to trigger on some other code,
that's only in the book but not in the part that's relicensed under
Apache-2.0.

Greetings
Roland