Bug#992051: security archive layout change needs more configuration changes

[Paul Gevers]

Package: release-notes

Hi,

I just sent this message to the security team, the release notes need
adapting.

Paul

 Forwarded Message 
Subject: security archive layout change warrants announcement
Date: Tue, 10 Aug 2021 07:44:07 +0200
From: Paul Gevers 
To: Debian Security Team 

Hi security team,

I don't know if you already planned on an announcement after the
bullseye release about the security archive layout change, but below I
urge you to think about it.

Yesterday I noticed that the layout change of the security impacts more
than just the apt *sources* as my system wasn't updating perl,
libencode-perl and exiv2. I already enabled the new security archive
layout a long time ago (and apt will complain when the sources are not
found). I discussed the issue on IRC on #d-release with juliank (apt
upstream). What users *need* to be aware of is that apt pinning (pabs
told me) and APT::Default-Release (found myself) may need adjustments
too, otherwise security updates are not installed.

I'm working on text for the release notes, but I fear a lot of users
will not be reading those and when they upgrade their secure buster
systems and only fix their apt sources, depending on how they configure
their system to follow bullseye, they may easily miss out on security
updates.

I therefore recommend you to send out an security announcement too after
the bullseye release (or whatever you feel is most appropriate)
explaining the layout change and the configuration impact.

Paul
PS: yesterday I learned that APT::Default-Release also supports "POSIX
fnmatch patterns or regular expressions inside /" On suggestion by
juliank I now have this APT::Default-Release myself (which worked for me):
APT::Default-Release "/^bullseye(|-security|-upgrades)$/";





OpenPGP_signature
Description: OpenPGP digital signature

Bug#892664: dpkg: Please add support for zstd (Zstandard) compressed packages

[Samuel Johnston]

The Linux kernel is now supplying modules compressed with zstd. Version
updates for 5.12 and 5.13 are unable to be installed anymore on Debian due
to this issue being unresolved.

Thanks,
Sam Johnston

On Sun, 10 Jan 2021 19:19:05 +0100 Balint Reczey <
balint.rec...@canonical.com> wrote:
> Hi Sebastian,
>
> On Sun, Apr 12, 2020 at 1:09 AM Sebastian Andrzej Siewior
>  wrote:
> >
> > On 2018-03-11 21:51:05 [+0100], Balint Reczey wrote:
> > > For the recompressed firefox .deb (Ubuntu's
> > > firefox_58.0.2+build1-0ubuntu0.17.10.1_amd64.deb) increased ~9% in
> > > size but decompressed in <20% of the original time:
> >
> > So you are saying that the decompression speed that is the bottleneck
> > here? I *assumed* that it is mostly the disk speed since I get around 60
> > to 80MiB/sec out of xz.
>
> I would not say bottleneck, but a very big contributor to the CPU time
> used. Some systems can have very slow IO and very fast CPU, but I
> think those typically correlate positively and SSDs are more common
> than spinning disks improving the typical IO speed.
>
> > > $ du -s firefox-*deb
> > > 43960 firefox-xz.deb
> > > 47924 firefox-zstd.deb
> >
> >   48M linux-image-5.5.0-1-amd64_5.5.13-2_amd64.data.tar.xz
> >   54M linux-image-5.5.0-1-amd64_5.5.13-2_amd64.data.tar.19.zstd
> >
> >  766M linux-image-5.5.0-1-amd64-dbg_5.5.13-2_amd64.data.tar.xz
> >  901M linux-image-5.5.0-1-amd64-dbg_5.5.13-2_amd64.data.tar.19.zstd
> >
> > zstd -19 -T16
> > |linux-image-5.5.0-1-amd64-dbg_5.5.13-2_amd64.data.tar : Completed in
287.37 sec  (cpu load : 1533%)
> > |
> > |real4m47,416s
> > |user73m23,825s
> > |sys 0m2,753s
> > |
> >
> > xz -T16
> > | real4m15,447s
> > | user66m51,572s
> > | sys 0m3,201s
> >
> >
> > > $ rm -rf firefox-xz/* ;time  dpkg-deb -R firefox-xz.deb firefox-xz/
> > > real 0m4,270s
> > > user 0m4,220s
> > > sys 0m0,630s
> > > $ rm -rf firefox-zstd/* ;time  dpkg-deb -R firefox-zstd.deb
firefox-zstd/
> > > real 0m0,765s
> > > user 0m0,556s
> > > sys 0m0,462s
> >
> > So this looks impressive. Is dpkg-deb also performing sync() on the
> > output or is the report when the files hit the disk cache? Either way,
> > should be noticeable on ssd/nvme which write at higher performance.
> >
> > > Tests on the full Ubuntu main archive showed ~6% average increase in
> > > the size of the binary packages.
> >
> > I guess the vast majority of packages are small and hardly increase in

Bug#991941: linux: Don't use nouveau with Nvidia GeForce 8500 GT or alert in dmesg that firmware is needed

[Laura Arjona Reina]

Hello again

El 10 de agosto de 2021 2:56:01 CEST, Ben Hutchings  
escribió:
>Control: tag -1 moreinfo
>
>On Fri, 2021-08-06 at 12:03 +0200, Laura Arjona Reina wrote:
>> Source: linux
>> Severity: normal
>> 
>> Dear Maintainer,
>> 
>> *** Reporter, please consider answering these questions, where 
>> appropriate ***
>> 
>> * What led up to the situation?
>> 
>> I have installed Debian 11 (debian installer RC3) on a PC having a 
>> Nvidia GeForce 8500 GT as main graphics card.
>> The graphicall install process went well. After finishing the 
>> installation and reboot, I got a blank screen and "Input not supported" 
>> on my monitor.
>> I changed to tty2 and logged in, and saved the dmesg output (attached), 
>> I noticed that "nouveau" driver was loaded but there was no info about 
>> my card not supported or needing additional firmware.
>
>The missing firmware should have been fixed in installer RC3 *if* you
>use an installer image that includes firmware, but not if you use the
>default images.  Which did you use?
>

I used the official image without firmware but was expecting that using 
isenkram-autoinstall-firmware afterwards was equivalent.

>On the kernel side we should try to fix the blank screen with an
>earlier check for firmware in nouveau, similarly to the way we patch
>the amdgpu and radeon drivers.  (Although those patches now seem not to
>be completely effective.)
>
>> * What exactly did you do (or not do) that was effective (or 
>> ineffective)?
>> 
>> I have rebooted and edited the "linux" line during Grub menu, to add 
>> "nomodeset" and then I could have a fallback graphics mode.
>> I have installed the isenkram-cli package and ran 
>> isenkram-autoinstall-firmware as suggested in the release notes and it 
>> installed firmware for my realtek card (unrelated) and 
>> firmware-misc-nonfree, but rebooting makes Linux pick the nouveau driver 
>> again.
>[...]
>
>Well that's expected.  The kernel driver and firmware are two different
>things that work together.  Installing the firmware should allow
>nouveau to work properly.
>
>Are you saying that even with firmware-misc-nonfree installed, you
>still get a black screen when you don't use "nomodeset"?
>

Exactly. 
At the end of August or beginning of September I can do an install using the 
image with firmware but I'll suspect that the results will be the same, because 
the needed firmware is not in Debian non-free either (card not supported in 
Bullseye). I think that nouveau should somehow output that message (card not 
supported) so the user gets a hint about what's happening.

Kind regards

-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona
Sent with K-9 mail

Bug#294124: Twoje Hasło do Konta E-mail Wygaśnie za 2 dni

[Administrator]

--

Twoje hasło do skrzynki pocztowej wygaśnie za 2 dni. aby zachować swoje 
hasło. KLIKNIJ TUTAJ [1], aby zaktualizować i natychmiast wysłać


Pozdrowienia
Wsparcie usług IT (c) 2021.

Links:
--
[1] https://jessica1mily12.wixsite.com/my-site

Bug#992050: [flex-old] homepage update

[McIntyre, Vincent (S, Marsfield)]

Package: flex-old
Version: 2.5.4a-10.1
Severity: minor

The upstream repo has moved from flex.sourceforge.net to
https://github.com/westes/flex

Kind regards
Vince

Bug#991971: [pkg-lynx-maint] Bug#991971: [CVE-2021-38165] lynx: bug in SSL certificate validation -> leaks password in clear text via SNI (under some circumstances)

[Axel Beckert]

Hi,

Axel Beckert wrote:
> I can also look into how well the patch applies to buster's version of
> Lynx, but it might take until Monday.

Done now, built with -sa, did a source-only uploaded to
security-master and pushed it into the branch 10_buster on Salsa
including the according git tag.

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


signature.asc
Description: PGP signature

Bug#990279: linux-image-5.10.0-7-powerpc64le: Upgrade to 5.10.0-7-powerpc64le from 5.10.0-0.bpo.5-powerpc64le breaks amdgpu

[Nathaniel Filardo]

I just now noticed Timothy Pearson's note about reverting the
alignment check patch.  An excellent thread to start pulling on, but I
don't think that is the correct fix in itself.  If the addresses
involved are not 64K aligned but merely 4K aligned, then the IOMMU
will have to open an overly wide aperture to include the misaligned
first (and possibly last) pages.

This may suggest that a fix is needed in userspace to ensure proper
alignment, or the misaligned addresses may be coming from somewhere
else in the kernel itself.  I suspect adding some WARN_ON (or perhaps
WARN_ON_ONCE, just in case) will prove informative.  If time permits,
I'll do that, but please don't wait on me.

Cheers,
--nwf;

Bug#991941: linux: Don't use nouveau with Nvidia GeForce 8500 GT or alert in dmesg that firmware is needed

[Ben Hutchings]

Control: tag -1 moreinfo

On Fri, 2021-08-06 at 12:03 +0200, Laura Arjona Reina wrote:
> Source: linux
> Severity: normal
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where 
> appropriate ***
> 
> * What led up to the situation?
> 
> I have installed Debian 11 (debian installer RC3) on a PC having a 
> Nvidia GeForce 8500 GT as main graphics card.
> The graphicall install process went well. After finishing the 
> installation and reboot, I got a blank screen and "Input not supported" 
> on my monitor.
> I changed to tty2 and logged in, and saved the dmesg output (attached), 
> I noticed that "nouveau" driver was loaded but there was no info about 
> my card not supported or needing additional firmware.

The missing firmware should have been fixed in installer RC3 *if* you
use an installer image that includes firmware, but not if you use the
default images.  Which did you use?

On the kernel side we should try to fix the blank screen with an
earlier check for firmware in nouveau, similarly to the way we patch
the amdgpu and radeon drivers.  (Although those patches now seem not to
be completely effective.)

> * What exactly did you do (or not do) that was effective (or 
> ineffective)?
> 
> I have rebooted and edited the "linux" line during Grub menu, to add 
> "nomodeset" and then I could have a fallback graphics mode.
> I have installed the isenkram-cli package and ran 
> isenkram-autoinstall-firmware as suggested in the release notes and it 
> installed firmware for my realtek card (unrelated) and 
> firmware-misc-nonfree, but rebooting makes Linux pick the nouveau driver 
> again.
[...]

Well that's expected.  The kernel driver and firmware are two different
things that work together.  Installing the firmware should allow
nouveau to work properly.

Are you saying that even with firmware-misc-nonfree installed, you
still get a black screen when you don't use "nomodeset"?

Ben.


-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer


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

Bug#992017: Changes in the build process

[Victor Grousset/tuxayo]

Hi :)

I case that helps, here are the changes in the two Arch Linux packaging 
scripts. It seems the build process didn't change. They had a workaround 
for recent version of Rust (0ad embeds Spidermonkey) which isn't 
necessary now for them.


https://github.com/archlinux/svntogit-community/commit/a53afd4986e5bb29cdb7adfdc9b62492850f194d#diff-3e341d2d9c67be01819b25b25d5e53ea3cdf3a38d28846cda85a195eb9b7203a
https://github.com/archlinux/svntogit-community/commit/d2ac1d8db4642cfbb010875942589ed61dfdf3fb#diff-3e341d2d9c67be01819b25b25d5e53ea3cdf3a38d28846cda85a195eb9b7203a


Cheers,

--
Victor Grousset/tuxayo

Bug#991896: New upstream version 2.1.0 available

[Niklas Wagner]

On 8/8/21 10:16 PM, Antonio Russo wrote:

> and I'd like to keep unstable/bookworm on 2.0, since my
understanding is that it is long-term stable, while 2.1 is short-
term stable.

Hi,

I am also not sure how the version system will work out in the future 
but *2.1 is a LTS release* for ZFS as you can see in their documentation 
[0]. "LTS releases will receive patches for at least 2 years. The 
*current LTS release is OpenZFS 2.1.*"


Since the 2.1.0 Release had several release canidats, over the span of 4 
months, there should be a low risk of major bugs. Additionally the new 
features are all behind feature flags (DRAID, InfluxDB, Compat Prob) and 
not enabled by default. Also some of the new feature are in the works 
for over 3 years and used in Production already.


Personally looking forward for a new release since I want to create my 
new RAID with ZFS DRAID. :)



[0] https://github.com/openzfs/zfs/blob/master/RELEASES.md


Best,

Niklas

Bug#992049: please build an API documentation package

[John Scott]

Source: zbar
Version: 0.23.90-1
Severity: wishlist

The zbar headers appear to have Doxygen annotations, and the doc folder
of the source tree has a doxygen.conf.in file. Please figure out how to
build the zbar documentation and put it in a libzbar-doc package, since
pre-built API documentation appears to be scarce on the web.

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

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



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

Bug#992048: NetworkManager-wait-online.service: fails to start correctly

[Brian May]

OK, I think I worked it out.

I followed instructions from
https://www.cyberciti.biz/faq/how-to-add-network-bridge-with-nmcli-networkmanager-on-linux/

On how to create a bridge.

These instructions while they tell you to shutdown the "Wired connection
1":

sudo nmcli con down "Wired connection 1"

They neglect to tell you how to ensure that the wired network connection
doesn't come up again after a reboot.

This meant that the bridge couldn't come up:

br0: connecting (getting IP configuration) to bridge-br0
"br0"
bridge, 06:55:A7:3D:DE:04, sw, mtu 1500

Which is why this service wasn't starting.

Once I shutdown the "Wired Connection 1" the "br0" could come up and
this service started working.

network-manager really needs to be a bit more transparent when things go
wrong. Such as printing a message "Waiting for br0 to come online" would
have really helped.
-- 
Brian May 

Bug#992034: installation-guide: Include a note on how to change init system during install

[Holger Wansing]

Hi,

Am 9. August 2021 17:19:03 MESZ schrieb Matthew Vernon :
>
>We are as a project meant to support use of alternative init systems; I 
>think that should include providing documentation to our users in the 
>appropriate place. And, as I said in response to Holger, it really is a 
>thing best done at install time, which is why the install guide is the 
>place for this documentation.

I tend to see it this way:
The installation-guide documents the functionality of 
debian-installer.
That change-init-system-during-install thing is not a function
of d-i (means: there is no question asking the user what init
system shall be used, or similar. Switching to the second
console and executing  there does not imply, 
that  is a function of d-i. 
On the console you can do *everything*).

Holger


-- 
Sent from /e/ OS on Fairphone3

Bug#992002: [PATCH][Debian#992002] tbl: allow two-character fonts and format fonts in -Thtml

[наб]

On Mon, Aug 09, 2021 at 10:58:19AM +0200, Ingo Schwarze wrote:
> Nab wrote on Sun, Aug 08, 2021 at 03:24:53PM +0200:
> > tbl's -Thtml ignores font requests;
> Not in CVS HEAD; see https://cvsweb.bsd.lv/mandoc/tbl_html.c revision 1.34,
> committed on May 16 earlier this year.
Oh, indeed. I tested and based my patch on 1.14.5 from Debian,
didn't realise that's almost two years old by now.
Will use the CVS next time.

> I started from your patch and changed a few aspects:
>  * You couldn't possibly know that i'm trying to work towards a
>unified system for identifying fonts using the mandoc.h
>enum mandoc_esc ESCAPE_FONT* identifiers.  Having different
>font identifiers for each output module is not good.
>So i added ESCAPE_FONTCB and ESCAPE_FONTCI and used those.
>A nice side effect is that CB and CI now work in HTML
>for all of \f, .ft, and tbl(7) f and that tbl(7) fBI
>now also works for terminal output.

> > text
> > text
> > text
> These become:
>   text
>   text
This is great news! A bunch of my pages use C[BI] and the HTML renders
look much better, thanks!

>  * GNU tbl(1) appears to ignore space characters between the f
>modifier and the font name, so "lf   B" is the same as "lfB".
Huh, so it does! That's not explicitly mentioned by the manual and so
I didn't think to test it. Now, tbl(1) says
  Key characters can be separated by spaces or tabs.
so consider the following document:
-- >8 --
.TS
lfBIlf BI   lf  BI  .
a   b   c
.TE
-- >8 --
(In order, none, space, tab follow 'f';
 base64: LlRTCmxmQkkJbGYgQkkJbGYJQkkJLgphCWIJYwouVEUK)

groff renders it with a, b, and c as BI,
but mandoc with your patch with a+b as BI and c as R, with -Tlint:
  mandoc: ./q.1:2:14: WARNING: unknown font, skipping request: TS f BI  
.

If you change tbl_layout.c L171 to match L75:
-- >8 --
-   while (p[*pos] == ' ')
+   while (p[*pos] == ' ' || p[*pos] == '\t')
-- >8 --
and L187:
-- >8 --
-   if (strchr(" .", p[*pos + isz]) == NULL)
+   if (strchr(" \t.", p[*pos + isz]) == NULL)
-- >8 --
The document renders correctly.

> > Renders to a teletype with the expected fonts:
> >   b, ul, bul;  b, ul, bul;  normal, b, ul
> Not quite.  The expected output for lbi is ul, not bul.
> The i overrides the b rather than add to it.
> So lbi is the same as lfI, not as lfBI.
Indeed, it looks like I got confused by the groff parsing
and thought it'd accumulate instead.

> Could you please check out from CVS (instead of the last release),
> apply the following patch, and tell me whether it looks reasonable
> and works for you?
Yeah, save for the tab thing above, I haven't managed to fault it,
in tests or real pages.

> When this gets committed, i will credit you for reporting the
> missing feature.  Do i understand correctly that "Nabija" is your
> first name and "Czleweli" your last name?
They aren't, but either "наб" or "nabijaczleweli" is fine.

Best,
наб


signature.asc
Description: PGP signature

Bug#992034: installation-guide: Include a note on how to change init system during install

[Matthew Vernon]

On 09/08/2021 20:01, Holger Wansing wrote:


I tend to see it this way:
The installation-guide documents the functionality of
debian-installer.
That change-init-system-during-install thing is not a function
of d-i (means: there is no question asking the user what init
system shall be used, or similar. Switching to the second
console and executing  there does not imply,
that  is a function of d-i.
On the console you can do *everything*).


With respect, I don't think the installation guide's scope can be that 
restricted - its preamble states "This document contains installation 
instructions for the Debian GNU/Linux 11 system (codename “bullseye”), 
for the 64-bit PC (“amd64”) architecture. It also contains pointers to 
more information and information on how to make the most of your new 
Debian system."


Further, the _only_ time you can easily switch init by just apt 
installing a different one is in the installer - systemd won't let you 
remove it if its running as pid 1. Here isn't the place to address the 
rights or wrongs of that; but it means that this isn't something that 
should be just left to later once the system is installed (unlike, say 
cron or email setup, both of which are covered in the installation guide).


Likewise, we could talk about whether the installer should provide 
better tooling for init switching, but that would be a discussion for 
elsewhere (and would be for a future release at this point anyway).


Regards,

Matthew

Bug#992048: [Pkg-utopia-maintainers] Bug#992048: NetworkManager-wait-online.service: fails to start correctly

[Michael Biebl]

Control: severity -1 normal

Am 10.08.21 um 00:18 schrieb Brian May:

$ /usr/bin/nm-online -s
Connecting...0s [startup-pending]
$ echo $?
1


Have you read the nm-online man page regarding "-s"?



   -s | --wait-for-startup
   Wait for NetworkManager startup to complete, rather than waiting for 
network connectivity specifically. Startup is
   considered complete once NetworkManager has activated (or attempted 
to activate) every auto-activate connection which
   is available given the current network state. This corresponds to the 
moment when NetworkManager logs "startup
   complete". This mode is generally only useful at boot time. After 
startup has completed, nm-online -s will just return
   immediately, regardless of the current network state.

   There are various ways to affect when startup complete is reached. 
For example, by setting a connection profile to
   autoconnect, such a profile possibly will activate during startup 
and thus delay startup complete being reached. Also,
   a profile is considered ready when it fully reached the logical 
connected state in NetworkManager. That means,
   properties like ipv4.may-fail and ipv6.may-fail affect whether a 
certain address family is required. Also, the
   connection property connection.wait-device-timeout affects whether 
to wait for the driver to detect a certain device.
   Generally, a failure of NetworkManager-wait-online.service indicates 
a configuration error, where NetworkManager won't
   be able to reach the desired connectivity state during startup. An 
example for that are bridge or bond master
   profiles, that get autoconnected but without activating any slaves. 
Such master devices hang in activating state
   indefinitely, and cause NetworkManager-wait-online.service to fail.


Has your NetworkManager log a "startup complete" message?
What kind of network connections have you marked as autoconnect?



OpenPGP_signature
Description: OpenPGP digital signature

Bug#992048: NetworkManager-wait-online.service: fails to start correctly

[Brian May]

Package: network-manager
Version: 1.30.0-2
Severity: important
File: NetworkManager-wait-online.service


$ systemctl status NetworkManager-wait-online.service
● NetworkManager-wait-online.service - Network Manager Wait Online
 Loaded: loaded (/lib/systemd/system/NetworkManager-wait-online.service; 
enabled; vendor preset: enabled)
 Active: failed (Result: exit-code) since Tue 2021-08-10 07:49:41 AEST; 
5min ago
   Docs: man:nm-online(1)
   Main PID: 1333 (code=exited, status=1/FAILURE)
CPU: 64ms

Aug 10 07:47:01 canidae systemd[1]: Starting Network Manager Wait Online...
Aug 10 07:49:41 canidae systemd[1]: NetworkManager-wait-online.service: Main 
process exited, code=exited, status=1/FAILURE
Aug 10 07:49:41 canidae systemd[1]: NetworkManager-wait-online.service: Failed 
with result 'exit-code'.
Aug 10 07:49:41 canidae systemd[1]: Failed to start Network Manager Wait Online.

$ systemctl restart NetworkManager-wait-online.service
[wait awhile ]
Job for NetworkManager-wait-online.service failed because the control process 
exited with error code.
See "systemctl status NetworkManager-wait-online.service" and "journalctl -xe" 
for details.

$ systemctl status NetworkManager-wait-online.service 
● NetworkManager-wait-online.service - Network Manager Wait Online
 Loaded: loaded (/lib/systemd/system/NetworkManager-wait-online.service; 
enabled; vendor preset: enabled)
 Active: failed (Result: exit-code) since Tue 2021-08-10 07:59:21 AEST; 45s 
ago
   Docs: man:nm-online(1)
Process: 7992 ExecStart=/usr/bin/nm-online -s -q (code=exited, 
status=1/FAILURE)
   Main PID: 7992 (code=exited, status=1/FAILURE)
CPU: 15ms

Aug 10 07:58:21 canidae systemd[1]: Starting Network Manager Wait Online...
Aug 10 07:59:21 canidae systemd[1]: NetworkManager-wait-online.service: Main 
process exited, code=exited, status=1/FAILURE
Aug 10 07:59:21 canidae systemd[1]: NetworkManager-wait-online.service: Failed 
with result 'exit-code'.
Aug 10 07:59:21 canidae systemd[1]: Failed to start Network Manager Wait Online.

$ journalctl -xe
[ no additional information ]

But networking - as soley setup by networkmanager - is working perfectly.

So why is NetworkManager-wait-online.service failing?

Possibly something here might help:

$ systemctl status NetworkManager.service
● NetworkManager.service - Network Manager
 Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; 
vendor preset: enabled)
 Active: active (running) since Tue 2021-08-10 07:47:01 AEST; 17min ago
   Docs: man:NetworkManager(8)
   Main PID: 1255 (NetworkManager)
  Tasks: 3 (limit: 76880)
 Memory: 11.1M
CPU: 907ms
 CGroup: /system.slice/NetworkManager.service
 └─1255 /usr/sbin/NetworkManager --no-daemon

Aug 10 07:50:21 canidae NetworkManager[1255]:   [1628545821.6920] device 
(wlo1): state change: activated -> deactivating (reason 'user>
Aug 10 07:50:21 canidae NetworkManager[1255]:   [1628545821.6952] audit: 
op="device-disconnect" interface="wlo1" ifindex=3 pid=3195 ui>
Aug 10 07:50:21 canidae NetworkManager[1255]:   [1628545821.7749] device 
(wlo1): supplicant interface state: completed -> disconnected
Aug 10 07:50:21 canidae NetworkManager[1255]:   [1628545821.7749] device 
(p2p-dev-wlo1): supplicant management interface state: comple>
Aug 10 07:50:21 canidae NetworkManager[1255]:   [1628545821.7752] device 
(wlo1): state change: deactivating -> disconnected (reason 'u>
Aug 10 07:50:21 canidae NetworkManager[1255]:   [1628545821.8051] dhcp4 
(wlo1): canceled DHCP transaction
Aug 10 07:50:21 canidae NetworkManager[1255]:   [1628545821.8052] dhcp4 
(wlo1): state changed bound -> done
Aug 10 07:50:21 canidae NetworkManager[1255]:   [1628545821.8077] device 
(wlo1): set-hw-addr: set MAC address to 9E:31:07:27:BC:D6 (sc>
Aug 10 07:57:14 canidae NetworkManager[1255]:   [1628546234.7268] device 
(wlo1): set-hw-addr: set MAC address to FE:E3:80:DD:B8:84 (sc>
Aug 10 08:04:07 canidae NetworkManager[1255]:   [1628546647.7041] device 
(wlo1): set-hw-addr: set MAC address to B2:36:55:FB:94:15 (sc>

$ ps auwx | grep -i NetworkManager
root1255  0.0  0.0 255040 17732 ?Ssl  07:48   0:00 
/usr/sbin/NetworkManager --no-daemon

$ /usr/bin/nm-online -s
Connecting...0s [startup-pending]
$ echo $?
1
canidae# 

For some reaason nm-online - which is used by
NetworkManager-wait-online.service - doesn't seem to be able to connect,
but I have no idea why.

strace isn't much help - it doesn't appear to be doing anything but
writing messages on the screen:

[...]
eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK)   = 3
[...]
Connecting) = 11e(1, "\rConnecting", 11
[pid 11384] write(1, ". 29s", 21. 29s) = 21
[pid 11384] poll([{fd=3, events=POLLIN}], 1, 998) = 0 (Timeout)
Connecting) = 11e(1, "\rConnecting", 11
[pid 11384] write(1, "..28s", 21..28s) = 21
[pid 11384] poll([{fd=3, events=POLLIN}], 1, 998) = 0 (Timeout)

Bug#734213: Forwarded

[bastien]

control: unforwarded -1
control: forwarded -1 https://bugs.astron.com/view.php?id=280

Thanks

Bug#734213: Still here

[bastien]

Control: tags -1 - moreinfo
control: forwarded -1 f...@astron.com

It is still here reported upstream

Bug#992047: rust-generator: CVE-2020-36471

[Moritz Mühlenhoff]

Source: rust-generator
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for rust-generator.

CVE-2020-36471[0]:
| An issue was discovered in the generator crate before 0.7.0 for Rust.
| It does not ensure that a function (for yielding values) has Send
| bounds.

https://rustsec.org/advisories/RUSTSEC-2020-0151.html

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-36471
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-36471

Please adjust the affected versions in the BTS as needed.

Bug#992046: rust-anymap: CVE-2021-38187

[Moritz Mühlenhoff]

Source: rust-anymap
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for rust-anymap.

CVE-2021-38187[0]:
| An issue was discovered in the anymap crate through 0.12.1 for Rust.
| It violates soundness via conversion of a *u8 to a *u64.

https://rustsec.org/advisories/RUSTSEC-2021-0065.html

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-38187
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-38187

Please adjust the affected versions in the BTS as needed.

Bug#834724:

[Enes Defne Karabak]

Bug#992045: CVE-2021-38185

[Moritz Muehlenhoff]

Package: cpio
Version: 2.13+dfsg-4
Severity: grave
Tags: security
X-Debbugs-Cc: Debian Security Team 

https://github.com/fangqyi/cpiopwn
https://git.savannah.gnu.org/cgit/cpio.git/commit/?id=dd96882877721703e19272fe25034560b794061b
https://lists.gnu.org/archive/html/bug-cpio/2021-08/msg0.html
https://lists.gnu.org/archive/html/bug-cpio/2021-08/msg2.html

Cheers,
 Moritz

Bug#992025: release-notes: Add section on switching init system

[Matthew Vernon]

On 09/08/2021 21:34, Paul Gevers wrote:



Short question (I'm low on time for this tonight): don't we have this
documented on the Wiki somewhere? It feels a bit long for the release notes.


Not currently (I imagine something like it will end up there 
eventually); I think it warrants being in the release notes because it's 
quite a significant change from Buster (where non-systemd inits were 
largely unusable on desktop systems).


Regards,

Matthew

Bug#989722: vim-youcompleteme: requires gopls binary in ~/go/bin

[Kyle Robbertze]

Hi,

On 2021/06/11 16:23, David Kalnischkies wrote:
> The patch[0] we use here is rather simplistic and does exactly what the
> README.Debian file says, as in: pick it up from ~/go/bin/gopls. So, this
> is technically not a bug, but documented behaviour…  close kthxbye ;P

:P I definitely should have read README.Debian

> If you could provide a (modified) patch to look at GOPATH first that
> would be nice. I don't have experience with Go apart from doing what the
> README said back than I adopted this package(set) and a smoke test so
> someone with actual go experience who can tell if its working would be
> cool!
>
> I think what we should arrive at is configured-path or /usr/bin/gopls¹ or
> $GOPATH/bin/gopls or ~/go/bin/gopls (although that is probably the
> default of $GOPATH). Upstream isn't going to be interested in any of
> this though, as you see in the patch they just use the binary they embed
> like they do for all the other things™, but I have already resigned to
> *go* a patch-heavy approach with these packages here so that is fine.
> (¹ or actually search in all of PATH now that I wrote this…)


Sure, I'm having a look at it. It seems the FindExecutableWithFallback
only expects 1 fallback, so it will need some modification to
ShouldEndableGoCompleter() and GoCompleter(). I think the hierarchy you
have described is correct (with PATH search over /usr/bin/gopls).

> [1] I am not too sure which version that is though. I got the ycmd
> testsuite mostly running earlier this week, but the go part is still
> mostly red. I hope it is just 'not the version upstream wrote their
> tests again' (as with clangd) but I haven't got that far in testing.

If I get a chance, I can take a look. No promises on the time-frame though


-- 

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Kyle Robbertze
⢿⡄⠘⠷⠚⠋⠀ Debian Developer
⠈⠳⣄ https://wiki.debian.org/KyleRobbertze

Bug#991970: [Piuparts-devel] Bug#991970: piuparts: ftbfs with golang-1.16

[Holger Levsen]

control: forward -1 https://salsa.debian.org/debian/piuparts/-/merge_requests/35
thanks

Hi Brian,

On Fri, Aug 06, 2021 at 01:06:02PM -0700, Brian Murray wrote:
> The attached patch will fix a FTBFS with golang-1.16.

thanks, this has already been proposed as MR35 and will be fixed in unstable
once bullseye has been released (or maybe after the first bullseye point
release, as Andreas suggest in in deb#991851 that there will be some more
adjustments needed for bullseye...


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Fascism is not just an opinion, it usually becomes a capital crime.


signature.asc
Description: PGP signature

Bug#992025: release-notes: Add section on switching init system

[Paul Gevers]

Hi,

On 09-08-2021 18:55, Matthew Vernon wrote:
> Hi,
> 
> Sorry, correct patch this time :-/
> 
> Regards,
> 
> Matthew

Short question (I'm low on time for this tonight): don't we have this
documented on the Wiki somewhere? It feels a bit long for the release notes.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#990831: $OPTIND issue solved in bash 5.1-2+b3

[kalle]

Dear maintainer,

With bash 5.1-2+b3, the output of
getopts abc opt hello; EC=$?; echo $opt $OPTIND $EC is
y 1 1

The value of $OPTIND is correct now.

But as already mentioned, $opt == x was strange, and the same holds for 
$opt == y now.


The bash manual states that if the first non-option arg is encountered, 
opt is set to ?,

so this is another bug.

For me, it's irrelevant since I don't use the value of $opt after 
getopts has exited with a non-zero exit value,

but maybe it's relevant to others.

Bug#992044: ITP: libgoby-java -- next-generation sequencing data and results analysis tool

[Pierre Gruet]

Package: wnpp
Severity: wishlist
Owner: Debian-med team 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-...@lists.debian.org

* Package name: libgoby-java
  Version : 3.3.1
  Upstream Author : Institute for Computational Biomedicine
* URL : https://github.com/CampagneLaboratory/goby3
* License : GPL-3
  Programming Lang: Java
  Description : next-generation sequencing data and results analysis tool

Goby is a next-gen data management framework designed to facilitate the
implementation of efficient data analysis pipelines.
Goby provides very efficient file formats to store next-generation sequencing
data and intermediary analysis results.
It also provides utilities that implement common next-gen data computations.
These utilities are designed to be relatively easy to use, yet very efficient.

One binary package will contain the Goby IO API, useful to read and write Goby
file formats. The related source code is licensed under LGPL-3.
The other binary package will contain the whole goby software, released under
GPL-3.

The package is long-needed by the Debian-med team as a dependency of igv, which
is currently in non-free.
It will be maintained inside the Debian-med team.

Bug#992043: RFS: ibmtss/1.6.0-1 -- IBM's TCG Software Stack (TSS) for TPM 2.0 and related utilities

[Debora Velarde Babb]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: ibmtss
   Version : 1.6.0-1
   Upstream Author : Ken Goldman 
 * URL : http://sourceforge.net/projects/ibmtpm20tss/
 * License : BSD-3-clause
 * Vcs : currently in an internal repo
   Section : admin

It builds those binary packages:

  tss2 - transitional dummy package
  libibmtss-dev - Development headers for IBM's TSS 2.0
  libibmtss1 - Development library for IBM's TSS 2.0
  ibmtss - IBM's TCG Software Stack (TSS) for TPM 2.0 and related
utilities

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/i/ibmtss/ibmtss_1.6.0-1.dsc

Changes for the initial release:

 ibmtss (1.6.0-1) unstable; urgency=medium
 .
   * Updated to work with latest ibmtss upstream release (1.6.0)

Regards,

Debora Velarde Babb
deb...@linux.ibm.com

Bug#990900: avahi: CVE-2021-36217

[Salvatore Bonaccorso]

Control: retitle 990900 avahi: CVE-2021-3502
Control: forcemerge 986018 990900

On Sat, Jul 10, 2021 at 11:22:51PM +0200, Salvatore Bonaccorso wrote:
> Source: avahi
> Version: 0.8-5
> Severity: important
> Tags: security upstream
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> 
> Hi,
> 
> The following vulnerability was published for avahi.
> 
> CVE-2021-36217[0]:
> | Avahi 0.8 allows a local denial of service (NULL pointer dereference
> | and daemon crash) against avahi-daemon via the D-Bus interface or a
> | "ping .local" command.
> 
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2021-36217
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-36217
> [1] https://bugzilla.suse.com/show_bug.cgi?id=1188083

This issue is actually a duplicate of CVE-2021-3502. CVE-2021-36217
got rejected.

Regards,
Salvatore

Bug#992042: please update to the last release 0.9.6

[Dmitry Baryshkov]

Package: fheroes2-pkg
Version: 0+svn20150122r3274-2-2
Severity: normal

FHeroes2 0.9.6 was releases recently. Could you please update the
package to support this version?


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
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)

Versions of packages fheroes2-pkg depends on:
ii  build-essential  12.9
ii  debconf [debconf-2.0]1.5.77
ii  debhelper13.3.4
ii  imagemagick  8:6.9.11.60+dfsg-1.3
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3
ii  libsdl-image1.2-dev  1.2.12-12
ii  libsdl-mixer1.2-dev  1.2.12-16+b1
ii  libsdl-net1.2-dev1.2.8-6+b1
ii  libsdl-ttf2.0-dev2.0.11-6
ii  libsdl1.2-dev [libsdl-dev]   1.2.15+dfsg2-6
ii  libtinyxml-dev   2.6.2-4
ii  libxdmf-dev  3.0+git20190531-7
ii  subversion   1.14.1-3

Versions of packages fheroes2-pkg recommends:
ii  freepats 20060219-3
ii  libcap2-bin  1:2.44-1

Versions of packages fheroes2-pkg suggests:
pn  ttf-dejavu-core  
pn  vrms 

-- debconf information:
* fheroes2-pkg/post-invoke_hook-install: true
  fheroes2-pkg/upgrade:
  fheroes2-pkg/title_u:
  fheroes2-pkg/post-invoke_hook-remove: false
  fheroes2-pkg/title_b-i:
* fheroes2-pkg/first-install:
* fheroes2-pkg/build: true

Bug#992034: installation-guide: Include a note on how to change init system during install

[Holger Wansing]

Hi,

Am 9. August 2021 16:36:33 MESZ schrieb Matthew Vernon :
>Source: installation-guide
>Severity: normal
>Tags: patch
>
>Hi,
>
>I've drafted a note on how to switch init system during the
>installation process; it's easiest to do it at this point rather than
>post-install, because it's tricky to remove the systemd package once
>systemd is running as pid 1.
>
>Could you include it in the install guide for bullseye, please? :)

I'm unsure, if this is the scope of this document ...
Maybe we would be better with adding such things to the wiki.

Holger

-- 
Sent from /e/ OS on Fairphone3

Bug#992008: ruby-google-protobuf: Missing lib/google/protobuf directory and fails require

[Pirate Praveen]

Control: tags -1 patch

On Mon, 09 Aug 2021 01:35:43 +0530 Pirate Praveen 
 wrote:

> Adding,
> ruby/lib/google usr/lib/ruby/vendor_ruby
> to debian/ruby-google-protobuf.install makes require 
'google/protobuf'

> to pass. This can be used as a workaround until we figure out why
> gem2deb is not installing these files even though gemspec includes 
them

> in files.

Hi Laszlo,

Can you upload this change? Or if you are okay with this change, I can 
upload it as well. Once this is fixed, I can switch back to the 
packaged version (currently using gem install google-protobuf as work 
around).


I had seen this bug earlier 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989774 but I thought 
it was something similar/related to 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966653 (between, this 
bug also seems to be fixed with newer protobuf/grpc versions in 
experimental).


diff -Nru protobuf-3.17.3/debian/changelog 
protobuf-3.17.3/debian/changelog

--- protobuf-3.17.3/debian/changelog 2021-06-23 21:06:44.0 +0530
+++ protobuf-3.17.3/debian/changelog 2021-08-09 21:32:33.0 +0530
@@ -1,3 +1,10 @@
+protobuf (3.17.3-1.1) experimental; urgency=medium
+
+ * Non-maintainer upload.
+ * Include ruby/lib in ruby-google-protobuf binary (Closes: #992008)
+
+ -- Pirate Praveen  Mon, 09 Aug 2021 21:32:33 +0530
+
protobuf (3.17.3-1) experimental; urgency=medium

  * New upstream release.
diff -Nru protobuf-3.17.3/debian/ruby-google-protobuf.install 
protobuf-3.17.3/debian/ruby-google-protobuf.install
--- protobuf-3.17.3/debian/ruby-google-protobuf.install 1970-01-01 
05:30:00.0 +0530
+++ protobuf-3.17.3/debian/ruby-google-protobuf.install 2021-08-09 
21:30:39.0 +0530

@@ -0,0 +1 @@
+ruby/lib/google usr/lib/ruby/vendor_ruby

Bug#992008: ruby-google-protobuf: Missing lib/google/protobuf directory and fails require

[Pirate Praveen]

On Mon, Aug 9, 2021 at 1:50 pm, Antonio Terceiro  
wrote:

On Mon, Aug 09, 2021 at 01:35:43AM +0530, Pirate Praveen wrote:
 On Mon, Aug 9, 2021 at 12:12 am, Pirate Praveen 


 wrote:
 > [copying debian-ruby list]
 >
 > On Sun, 08 Aug 2021 22:08:39 +0530 Akshay S Dinesh
 >  wrote:
 > > Package: ruby-google-protobuf
 > > Version: 3.17.3-1
 > > Severity: grave
 > > Justification: renders package unusable
 > >
 > > Dear Maintainer,
 > >
 > > I was trying to install gitlab to reproduce #966653
 > >
 > > Installed ruby-google-protobuf from experimental
 > >
 > > The pg_query library was erroring at startup,
 > > with failure to require 'google/protobuf'
 > >
 > > I tried to isolate it to debian by `gem install google-protobuf`
 > >
 > > It worked correctly with that.
 > >
 > > On comparing stable version
 > > 
http://ftp.debian.org/debian/pool/main/p/protobuf/ruby-google-protobuf_3.12.4-1_amd64.deb

 > > with the experimental version
 > > 
http://ftp.debian.org/debian/pool/main/p/protobuf/ruby-google-protobuf_3.17.3-1_amd64.deb

 > >
 > > I could see that the latter lacks the
 > /2.7.0/gems/lib/google/protobuf directory altogether
 > >
 > > The upstream gem at
 > https://rubygems.org/downloads/google-protobuf-3.17.3.gem includes
 > > this lib directory with lots of ruby files
 > >
 > > I'm suspecting that this folder is critical to the functioning 
of this

 > package
 > >
 >
 > I think this is a problem with gem2deb not including the pure 
ruby files
 > along with the extention. I think we have seen such issues 
before, but

 > don't remember how we fixed it.
 >
 > Another possibility is that the rules is calling ruby build only 
in

 > override_dh_auto_build-arch.

 Adding,
 ruby/lib/google usr/lib/ruby/vendor_ruby
 to debian/ruby-google-protobuf.install makes require 
'google/protobuf' to
 pass. This can be used as a workaround until we figure out why 
gem2deb is
 not installing these files even though gemspec includes them in 
files.


protobuf is nothing like an usual Ruby package.

The top of debian/rules has this:

export DH_RUBY = --gem-install
export DH_RUBY_USE_DH_AUTO_INSTALL_DESTDIR = 
debian/ruby-google-protobuf

export GEM2DEB_TEST_RUNNER = --check-dependencies


But this is completely misleading, since the part that seems to 
actually

do the Ruby build does not use gem2deb at all, and looks like this:

ifeq (,$(filter noruby,$(DEB_BUILD_PROFILES)))
# Ruby build
cd ruby && rake package genproto
endif

So this has definitively nothing to do with gem2deb.


Well, I tried with

dh_auto_build -O--buildsystem=ruby -O--package=ruby-google-protobuf

after this rake command without any change

Also it has the following lines below it and

dh_auto_install -O--buildsystem=ruby -O--package=ruby-google-protobuf 
--destdir=$(CURDIR)/debian/ruby-google-protobuf


and you can see in the build logs at 
https://buildd.debian.org/status/fetch.php?pkg=protobuf=amd64=3.17.3-1=1624466935=0 
this looks to me pretty much gem2deb's doing.


dh_auto_install -O--buildsystem=ruby -O--package=ruby-google-protobuf 
--destdir=/<>/debian/ruby-google-protobuf

dh_ruby --install /<>/debian/ruby-google-protobuf
  dh_ruby --install
/usr/bin/ruby2.7 -S gem build --config-file /dev/null --verbose 
/tmp/d20210623-865026-7jt4fj/gemspec

Failed to load /dev/null because it doesn't contain valid YAML hash
 Successfully built RubyGem
 Name: google-protobuf
 Version: 3.17.3
 File: google-protobuf-3.17.3.gem
/usr/bin/ruby2.7 -S gem install --config-file /dev/null --verbose 
--local --verbose --no-document --ignore-dependencies --install-dir 
/<>/debian/ruby-google-protobuf/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0 
/tmp/d20210623-865026-7jt4fj/google-protobuf-3.17.3.gem

Failed to load /dev/null because it doesn't contain valid YAML hash
/<>/debian/ruby-google-protobuf/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/gems/google-protobuf-3.17.3/ruby/ext/google/protobuf_c/convert.c
/<>/debian/ruby-google-protobuf/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/gems/google-protobuf-3.17.3/ruby/ext/google/protobuf_c/convert.h
/<>/debian/ruby-google-protobuf/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/gems/google-protobuf-3.17.3/ruby/ext/google/protobuf_c/defs.c
/<>/debian/ruby-google-protobuf/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/gems/google-protobuf-3.17.3/ruby/ext/google/protobuf_c/defs.h
/<>/debian/ruby-google-protobuf/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/gems/google-protobuf-3.17.3/ruby/ext/google/protobuf_c/extconf.rb
/<>/debian/ruby-google-protobuf/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/gems/google-protobuf-3.17.3/ruby/ext/google/protobuf_c/map.c
/<>/debian/ruby-google-protobuf/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/gems/google-protobuf-3.17.3/ruby/ext/google/protobuf_c/map.h

Bug#992025: release-notes: Add section on switching init system

[Holger Wansing]

Hi,

Am 9. August 2021 13:56:22 MESZ schrieb Justin B Rye 
:
>> +  
>> +If you encounter any issues specifically associated with using
>> +an alternative init system, there is a Debian init system
>> +diversity list (> +
>> url="debian-init-divers...@chiark.greenend.org.uk">debian-init-divers...@chiark.greenend.org.uk)
>> +who may be able to help.
>> +  
>> +
>>
>
>I wouldn't call a mailinglist a "who", and I wouldn't introduce a
>publicly archived list with just the To-address - perhaps make this
>
>an alternative init system, help may be available from the
> url="https://www.chiark.greenend.org.uk/mailman/listinfo/debian-init-diversity/;>Debian
>init system diversity list.
>

That's not a lists.debian.org mailinglist.
So, is it ok, to call it a " Debian ... list" ?

Holger


-- 
Sent from /e/ OS on Fairphone3

Bug#992038: systemd: regression with systemd-networkd + dropbear initramfs and kernel ip autoconfig(?)

[Michael Biebl]

Am 09.08.21 um 18:03 schrieb Axel Scheepers:

Package: systemd
Version: 247.3-6
Severity: normal

Dear Maintainer,

* What led up to the situation?

Testing bullseye rc-3 install on remote server.



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

I used encrypted root and dropbear initramfs to remote unlock, also setup 
systemd-networkd for
both wireless and wired interfaces:


How exactly do you configure your network in the initramfs?
systemd-networkd does not ship any hooks for that.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#992025: release-notes: Add section on switching init system

[Matthew Vernon]

Hi,

Sorry, correct patch this time :-/

Regards,

Matthew
>From a44e86218574309a747279d2cef3255772c0c632 Mon Sep 17 00:00:00 2001
From: Matthew Vernon 
Date: Mon, 9 Aug 2021 11:37:12 +0100
Subject: [PATCH] Add a subsection on changing init system

It's slightly fiddly to switch init system away from systemd, so
include a short note on doing so; and a pointer to the init-diversity
list for help.
---
 en/issues.dbk | 47 +++
 1 file changed, 47 insertions(+)

diff --git a/en/issues.dbk b/en/issues.dbk
index 1fbba7a3..cad2f9d0 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -719,6 +719,53 @@ Environment=SYSTEMD_SULOGIN_FORCE=1
 	#802211.
   
 
+
+
+  
+	Switching Init System
+  
+  
+	The default init system in Debian is systemd. In bullseye, a
+	number of alternative init systems are supported (such as
+	System-V-style init and OpenRC). Generally, to switch between
+	init systems, you install the new init system and reboot. The
+	exception is switching away from systemd - systemd's packages
+	will refuse to be removed if systemd is running; so the
+	process is a little more involved.
+  
+  
+	In outline, you need to download the new packages you need,
+	switch to single-user mode, install these new packages, and
+	then reboot. The recommended approach is as follows. First,
+clear out /var/cache/apt/archives by
+running apt clean (this makes identifying
+the packages to install later easier). Next, get
+	apt to download the new packages you need,
+e.g.: apt --download-only install sysvinit-core
+	libpam-elogind; libpam-elogind (and elogind which it Depends upon)
+	provide session management facilities, which you will likely
+	need on any system running a desktop environment. At this
+	point, review apt's proposed actions, and
+	if happy, let it carry on.
+  
+  
+	Now switch to single-user mode (systemctl
+	rescue) and install the packages you downloaded
+	using apt install
+	/var/cache/apt/archives/*.deb Once this has
+	completed, reboot your system.
+  
+  
+	If you encounter any issues specifically associated with using
+	an alternative init system, then help may be available from
+	https://www.chiark.greenend.org.uk/mailman/listinfo/debian-init-diversity/;
+	url="debian-init-divers...@chiark.greenend.org.uk">the
+	Debian-init-diversity list.
+  
+
   
 
   
-- 
2.11.0

Bug#992025: release-notes: Add section on switching init system

[Matthew Vernon]

Hi,

Thanks for the feedback; I've edited my patch in the light of your 
comments (see attached). There's an MR on salsa, too:

https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/119

Regards,

Matthew
>From 7e31020f328c1da9b452f9c9027dc9ba71e5a1cc Mon Sep 17 00:00:00 2001
From: Matthew Vernon 
Date: Mon, 9 Aug 2021 11:37:12 +0100
Subject: [PATCH] Add a subsection on changing init system

It's slightly fiddly to switch init system away from systemd, so
include a short note on doing so; and a pointer to the init-diversity
list for help.
---
 en/issues.dbk | 47 +++
 1 file changed, 47 insertions(+)

diff --git a/en/issues.dbk b/en/issues.dbk
index 1fbba7a3..cad2f9d0 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -719,6 +719,53 @@ Environment=SYSTEMD_SULOGIN_FORCE=1
 	#802211.
   
 
+
+
+  
+	Switching Init System
+  
+  
+	The default init system in Debian is systemd. In bullseye, a
+	number of alternative init systems are supported (such as
+	System-V-style init and OpenRC). Generally, to switch between
+	init systems, you install the new init system and reboot. The
+	exception is switching away from systemd - systemd's packages
+	will refuse to be removed if systemd is running; so the
+	process is a little more involved.
+  
+  
+	In outline, you need to download the new packages you need,
+	switch to single-user mode, install these new packages, and
+	then reboot. The recommended approach is as follows. First,
+clear out /var/cache/apt/archives by
+running apt clean (this makes identifying
+the packages to install later easier). Next, get
+	apt to download the new packages you need,
+e.g.: apt --download-only install sysvinit-core
+	libpam-elogind; libpam-elogind (and elogind which it Depends upon)
+	provide session management facilities, which you will likely
+	need on any system running a desktop environment. At this
+	point, review apt's proposed actions, and
+	if happy, let it carry on.
+  
+  
+	Now switch to single-user mode (systemctl
+	rescue) and install the packages you downloaded
+	using apt install
+	/var/cache/apt/archives/*.deb Once this has
+	completed, reboot your system.
+  
+  
+	If you encounter any issues specifically associated with using
+	an alternative init system, then help may be available from
+	https://www.chiark.greenend.org.uk/mailman/listinfo/debian-init-diversity/;
+	url="debian-init-divers...@chiark.greenend.org.uk">the
+	Debian-init-diversity list.
+  
+
   
 
   
-- 
2.11.0

Bug#992040: gitlab 2FA broken: NoMethodError (undefined method `module_count' for #

[Pirate Praveen]

Control: reassign ruby-rqrcode-rails3
Control: affects -1 gitlab
Control: forwarded -1 
https://github.com/samvincent/rqrcode-rails3/issues/21


On Mon, 09 Aug 2021 21:52:53 +0530 Pirate Praveen 
 wrote:

> NoMethodError (undefined method `module_count' for
> #
> Did you mean? modules):

Looks like there is an upstream merge request in ruby-rqrcode-rails3 
(https://github.com/samvincent/rqrcode-rails3/issues/21) but there is 
no recent releases.

Bug#992039: mapcache: please make the build reproducible

[Sebastiaan Couwenberg]

Control: tags -1 pending

Hi Chris,

Thanks for the patch, it's applied in git and will be included in the
next upload (after the bullseye release most likely).

Kind Regards,

Bas

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

Bug#992034: installation-guide: Include a note on how to change init system during install

[Matthew Vernon]

On 09/08/2021 16:35, Samuel Thibault wrote:

Matthew Vernon, le lun. 09 août 2021 16:19:03 +0100, a ecrit:

I don't think adding a subsection at the bottom of "Using Individual
Components" is really burdening the casual systemd user! We wouldn't say
that a subsection on serial braille displays should be left out because it's
a niche use case that burdens the casual user, would we?


That's an entirely different thing.


I'm not sure it's entirely different (and FTAOD I am not in any way 
suggesting we shouldn't document such things!). We support and document 
a wide range of things in the installation guide that most people won't 
need most of the time; we do this because some of our users will need 
and/or want them, and because the installation guide is the place to 
document things our users might want to know about installing Debian.


Wanting to run an alternative init system is something we have agreed as 
a project to support; the best way for our users to pick an alternative 
is during system install; so the install guide is the place to put that 
documentation. Plenty of people won't need to look at it, so they can 
skip over that subsection.


Regards,

Matthew

Bug#992040: gitlab 2FA broken: NoMethodError (undefined method `module_count' for #

[Pirate Praveen]

Package: gitlab
Version: 13.12.9+ds1-1
Severity: important

When trying to enable two factor authentication, gitlab shows a 500 
error and production.log has this error.


Started GET "/-/profile/two_factor_auth" for 192.168.122.1 at 
2021-08-09 16:19:49 +

Processing by Profiles::TwoFactorAuthsController#show as HTML
Completed 500 Internal Server Error in 349ms (ActiveRecord: 11.8ms | 
Elasticsearch: 0.0ms | Allocations: 84358)


NoMethodError (undefined method `module_count' for 
#

Did you mean? modules):

app/controllers/profiles/two_factor_auths_controller.rb:134:in 
`build_qr_code'

app/controllers/profiles/two_factor_auths_controller.rb:39:in `show'
app/controllers/application_controller.rb:490:in `set_current_admin'
lib/gitlab/session.rb:11:in `with_session'
app/controllers/application_controller.rb:481:in `set_session_storage'
lib/gitlab/i18n.rb:99:in `with_locale'
lib/gitlab/i18n.rb:105:in `with_user_locale'
app/controllers/application_controller.rb:475:in `set_locale'
app/controllers/application_controller.rb:468:in `block in 
set_current_context'

lib/gitlab/application_context.rb:70:in `block in use'
lib/gitlab/application_context.rb:70:in `use'
lib/gitlab/application_context.rb:27:in `with_context'
app/controllers/application_controller.rb:459:in `set_current_context'
lib/gitlab/middleware/speedscope.rb:13:in `call'
lib/gitlab/request_profiler/middleware.rb:17:in `call'
lib/gitlab/jira/middleware.rb:19:in `call'
lib/gitlab/middleware/go.rb:20:in `call'
lib/gitlab/etag_caching/middleware.rb:21:in `call'
lib/gitlab/middleware/multipart.rb:172:in `call'
lib/gitlab/middleware/read_only/controller.rb:50:in `call'
lib/gitlab/middleware/read_only.rb:18:in `call'
lib/gitlab/middleware/same_site_cookies.rb:27:in `call'
lib/gitlab/middleware/handle_malformed_strings.rb:21:in `call'
lib/gitlab/middleware/basic_health_check.rb:25:in `call'
lib/gitlab/middleware/handle_ip_spoof_attack_error.rb:25:in `call'
lib/gitlab/middleware/request_context.rb:21:in `call'
config/initializers/fix_local_cache_middleware.rb:11:in `call'
lib/gitlab/middleware/rack_multipart_tempfile_factory.rb:19:in `call'
lib/gitlab/metrics/requests_rack_middleware.rb:76:in `call'
lib/gitlab/middleware/release_env.rb:12:in `call'
Started GET "/favicon.ico" for 192.168.122.1 at 2021-08-09 16:19:49 
+

Bug#992039: mapcache: please make the build reproducible

[Chris Lamb]

Source: mapcache
Version: 1.10.0-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
mapcache could not be built reproducibly.

This is because CMake's RPATH is not stripped (even with chrpath it
seems!), needing us to avoid it being set with -DCMAKE_SKIP_RPATH=ON.

Patch attached.

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


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2021-08-09 16:59:37.972838427 +0100
--- b/debian/rules  2021-08-09 17:07:29.339959518 +0100
@@ -34,6 +34,7 @@
 CMAKE_OPTS:= \
-DCMAKE_INSTALL_PREFIX=/usr \
-DCMAKE_VERBOSE_MAKEFILE=1 \
+   -DCMAKE_SKIP_RPATH=ON \
-DWITH_PIXMAN=1 \
-DWITH_SQLITE=1 \
-DWITH_BERKELEY_DB=0 \

Bug#197428: i need your reply

[Maxwell Watford]

Greetings,

We are writing to you from Ecowas Finance Controller Office Lome Togo,
because we have received a file from the Ministry of Finance Lome-
Togo, concerning an Inherited Fund bearing your name on it, And after
our verifications, we found out that the funds belong to you.

It has been awarded and I will like to guide you to claim the funds.
Please contact me at my private email address
(mrmaxwellwatf...@gmail.com) for more information and directive

I am looking forward to your urgent reply,
Best regards
Mr Maxwell Watford

Bug#992034: installation-guide: Include a note on how to change init system during install

[Samuel Thibault]

Matthew Vernon, le lun. 09 août 2021 16:19:03 +0100, a ecrit:
> I don't think adding a subsection at the bottom of "Using Individual
> Components" is really burdening the casual systemd user! We wouldn't say
> that a subsection on serial braille displays should be left out because it's
> a niche use case that burdens the casual user, would we?

That's an entirely different thing.

People using serial Braille displays didn't choose to use them.

They *are* casual users, who happen to have to use Braille displays to
be able to use a Debian system at all.  Documenting the use of a Braille
display is thus *not* an option for them, to be able to use Debian at
all.

Samuel

Bug#977169: weechat-scripts breaks weechat-matrix on bullseye

[Felix Lechner]

Control: affects -1 + weechat-matrix

This bug amendment is intended to notify the maintainer of
weechat-matrix that their package in bullseye does not work because of
this bug in weechat-scripts. The amendment is warranted because this
bug was fixed in Debian unstable, but not being RC remains unfixed in
bullseye—even though weechat-matrix in bullseye is unusable.

A preliminary analysis indicates that there are two causes. This bug is one.

The second issue appears to relate to a name conflict caused by the
file /usr/share/weechat/python/queue.py shipped in weechat-scripts, or
possibly by the module loading process used for weechat-matrix. It is
described in this Ubuntu bug [2]  which was filed against
weechat-scripts. (Thank you to Sebastinas for locating it.) It is
unclear if the second issue was also fixed, like this bug, in unstable
with version 20210303-1 of weechat-scripts.

There was one report (from jochensp on IRC) that the Git version of
weechat-matrix works with version 20200815-1 of weechat-scripts in
bullseye. I could not verify that locally and installed
weechat-scripts from unstable instead. Unfortunately, I continued to
see Python connection errors which I have to investigate further.

Here is a brief description of how to reproduce the issue:

On bullseye, the command '/script load matrix.py', which I took from
the upstream instructions, [1] does not load the script but instead
produces the errors shown at the bottom of this message. (You may have
to run 'weechat-matrix-wrapper enable' beforehand.)

Hope this helps!

Kind regards
Felix Lechner

[1] https://github.com/poljar/weechat-matrix
[2] https://bugs.launchpad.net/ubuntu/+source/weechat-scripts/+bug/1903354

* * *

11:35 python: stdout/stderr (?): Traceback (most recent call last):
11:35 python: stdout/stderr (?):   File
"/usr/lib/python3/dist-packages/playhouse/sqliteq.py", line 7, in

11:35 python: stdout/stderr (?): from Queue import Queue
11:35 python: stdout/stderr (?): ModuleNotFoundError: No module named 'Queue'
11:35 python: stdout/stderr (?): During handling of the above
exception, another exception occurred:
11:35 python: stdout/stderr (?): Traceback (most recent call last):
11:35 python: stdout/stderr (?):   File
"/home/lechner/.weechat/python/autoload/matrix.py", line 53, in

11:35 python: stdout/stderr (?): from nio import
RemoteProtocolError, RemoteTransportError, TransportType
11:35 python: stdout/stderr (?):   File
"/usr/lib/python3/dist-packages/nio/__init__.py", line 2, in 
11:35 python: stdout/stderr (?): from .client import *
11:35 python: stdout/stderr (?):   File
"/usr/lib/python3/dist-packages/nio/client/__init__.py", line 3, in

11:35 python: stdout/stderr (?): from .base_client import Client,
ClientConfig
11:35 python: stdout/stderr (?):   File
"/usr/lib/python3/dist-packages/nio/client/base_client.py", line 35,
in 
11:35 python: stdout/stderr (?): from ..crypto import ENCRYPTION_ENABLED
11:35 python: stdout/stderr (?):   File
"/usr/lib/python3/dist-packages/nio/crypto/__init__.py", line 41, in

11:35 python: stdout/stderr (?): from .olm_machine import Olm
11:35 python: stdout/stderr (?):   File
"/usr/lib/python3/dist-packages/nio/crypto/olm_machine.py", line 52,
in 
11:35 python: stdout/stderr (?): from ..store import MatrixStore
11:35 python: stdout/stderr (?):   File
"/usr/lib/python3/dist-packages/nio/store/__init__.py", line 35, in

11:35 python: stdout/stderr (?): from .database import (
11:35 python: stdout/stderr (?):   File
"/usr/lib/python3/dist-packages/nio/store/database.py", line 22, in

11:35 python: stdout/stderr (?): from playhouse.sqliteq import
SqliteQueueDatabase
11:35 python: stdout/stderr (?):   File
"/usr/lib/python3/dist-packages/playhouse/sqliteq.py", line 9, in

11:35 python: stdout/stderr (?): from queue import Queue
11:35 python: stdout/stderr (?):   File
"/usr/share/weechat/python/queue.py", line 277
11:35 python: stdout/stderr (?): if args == "":
11:35 python: stdout/stderr (?): TabError: inconsistent use of tabs
and spaces in indentation
11:35 =!= python: unable to parse file
"/home/lechner/.weechat/python/autoload/matrix.py"

Bug#992028: transition: libidn

[Simon Josefsson]

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

Hello,

I want to transition libidn to a newer upstream version, and they
API/ABI bumped.  This is my first transition in many years, so I'm
looking for guidance here.

I have uploaded 1.38-1 to experimental, and it builds everywhere.  The
binary package libidn11 is replaced with libidn12; libidn11-dev renamed
to libidn-dev (adding a dummy package with the old name); and
libidn11-java is removed (not setup for java usage properly and <10
popcon).

Speaking as upstream of the package, I expect everything to build with
the new version, doing the API/ABI bump was a mistake but it is several
years old by now.

Reverse dependencies have been built here:
https://salsa.debian.org/debian/libidn/-/pipelines/273580

Some comments:

- clamav: libclamav-dev depends on libidn11-dev needessly:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991976
- echoping: ftbfs otherwise too, not related to this
- clickhouse: ftbfs due to 2h build timeout on salsa, otherwise should
  be okay.

Is there anything more I should do now?  Let me know when I can upload
to unstable.

Ben file (based on auto-generated output on the webpage -- not sure this
is correct -- why doesn't it output something in the right format?):

title = "libidn";
is_affected = .depends ~ "/\b(libidn\-dev|libidn12|libidn11|libidn11\-java)\b/";
is_good = .depends ~ "/\b(libidn\-dev|libidn12)\b/";
is_bad = .depends ~ "/\b(libidn11|libidn11\-java)\b/";

/Simon


signature.asc
Description: PGP signature

Bug#992034: installation-guide: Include a note on how to change init system during install

[Matthew Vernon]

On 09/08/2021 16:12, Cyril Brulebois wrote:

Holger Wansing  (2021-08-09):

Am 9. August 2021 16:36:33 MESZ schrieb Matthew Vernon :

Source: installation-guide
Severity: normal
Tags: patch

Hi,

I've drafted a note on how to switch init system during the
installation process; it's easiest to do it at this point rather than
post-install, because it's tricky to remove the systemd package once
systemd is running as pid 1.

Could you include it in the install guide for bullseye, please? :)


I'm unsure, if this is the scope of this document ...
Maybe we would be better with adding such things to the wiki.


The wiki looks better to me to address that niche use case. No need to
burden translators or casual users with that.


We are as a project meant to support use of alternative init systems; I 
think that should include providing documentation to our users in the 
appropriate place. And, as I said in response to Holger, it really is a 
thing best done at install time, which is why the install guide is the 
place for this documentation.


I don't think adding a subsection at the bottom of "Using Individual 
Components" is really burdening the casual systemd user! We wouldn't say 
that a subsection on serial braille displays should be left out because 
it's a niche use case that burdens the casual user, would we?


Regards,

Matthew

Bug#992034: installation-guide: Include a note on how to change init system during install

[Matthew Vernon]

On 09/08/2021 15:57, Holger Wansing wrote:


Am 9. August 2021 16:36:33 MESZ schrieb Matthew Vernon :

Source: installation-guide
Severity: normal
Tags: patch

Hi,

I've drafted a note on how to switch init system during the
installation process; it's easiest to do it at this point rather than
post-install, because it's tricky to remove the systemd package once
systemd is running as pid 1.

Could you include it in the install guide for bullseye, please? :)


I'm unsure, if this is the scope of this document ...
Maybe we would be better with adding such things to the wiki.


I gave this some thought before submitting it, and I think it's of 
benefit to our users to put something in the installation guide. 
Particularly because at install-time is the best time to pick a 
different init.


Regards,

Matthew

Bug#992037: ITP: python-pillow -- successor of Python Image Library (PIL)

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: python-pillow -- successor of Python Image Library (PIL)
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: python-pillow
  Version : 8.3.1
  Upstream Author : by Secret Labs AB
* URL : https://github.com/python-pillow/Pillow
* License : HPND
  Programming Lang: Python
  Description : successor of Python Image Library (PIL)
 The PIL was _the_ library to use to craft images with Python.
 But last updates happened in 2010. All developments since then
 went into this "friendly fork". 

Remark: This package is maintained by Debian Python Team at
   https://salsa.debian.org/python-team/packages/python-pillow

Bug#992034: installation-guide: Include a note on how to change init system during install

[Cyril Brulebois]

Holger Wansing  (2021-08-09):
> Am 9. August 2021 16:36:33 MESZ schrieb Matthew Vernon :
> >Source: installation-guide
> >Severity: normal
> >Tags: patch
> >
> >Hi,
> >
> >I've drafted a note on how to switch init system during the
> >installation process; it's easiest to do it at this point rather than
> >post-install, because it's tricky to remove the systemd package once
> >systemd is running as pid 1.
> >
> >Could you include it in the install guide for bullseye, please? :)
> 
> I'm unsure, if this is the scope of this document ...
> Maybe we would be better with adding such things to the wiki.

The wiki looks better to me to address that niche use case. No need to
burden translators or casual users with that.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#992036: freeradius 3.0.x crashes with "attempting double-free"

[Bernhard Schmidt]

Package: src:freeradius
Version: 3.0.17+dfsg-1
Severity: important
Tags: patch

At $dayjob we tried migrating our central radius proxy from FreeRADIUS 2.x to
FreeRADIUS 3.x and have experienced several crashes under high load. 

A colleague worked closely together with upstream in
https://github.com/FreeRADIUS/freeradius-server/issues/3188 and it looks like
there is a two-line patch (already committed) that is fixing these crashes.

This bug is open for tracking, we are going to test whether 3.0.21+patch works
as well. In this case it might be included in a future stable update.

Bug#992035: mozc not built for riscv64

[Heinrich Schuchardt]

Package: mozc
Version: 2.26.4220.100+dfsg-4
Severity: normal

Dear maintainer,

please, add architecture riscv64 to the mozc build targets.

Best regards

Heinrich

Bug#992034: installation-guide: Include a note on how to change init system during install

[Matthew Vernon]

Source: installation-guide
Severity: normal
Tags: patch

Hi,

I've drafted a note on how to switch init system during the
installation process; it's easiest to do it at this point rather than
post-install, because it's tricky to remove the systemd package once
systemd is running as pid 1.

Could you include it in the install guide for bullseye, please? :)

Thanks,

Matthew

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

Kernel: Linux 4.9.0-16-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
>From 8a1342942cedd48a4a5655e9efc07e6bbd23bff5 Mon Sep 17 00:00:00 2001
From: Matthew Vernon 
Date: Mon, 9 Aug 2021 15:32:27 +0100
Subject: [PATCH] Notes on installing an alternative init system

The easiest time to switch init system is during the install (once
systemd is running as pid 1, it's harder to remove the systemd
package), so document how to do so.
---
 en/using-d-i/components.xml|  1 +
 en/using-d-i/modules/inits.xml | 78 ++
 2 files changed, 79 insertions(+)
 create mode 100644 en/using-d-i/modules/inits.xml

diff --git a/en/using-d-i/components.xml b/en/using-d-i/components.xml
index 702185e97..976d37c96 100644
--- a/en/using-d-i/components.xml
+++ b/en/using-d-i/components.xml
@@ -188,4 +188,5 @@ user in case something goes wrong.
 
   
 
+
  
diff --git a/en/using-d-i/modules/inits.xml b/en/using-d-i/modules/inits.xml
new file mode 100644
index 0..419a54fb1
--- /dev/null
+++ b/en/using-d-i/modules/inits.xml
@@ -0,0 +1,78 @@
+
+
+
+
+  Installing an alternative init system
+
+  
+
+ uses systemd as its default init system. Other init
+systems (such as sysvinit and OpenRC) are supported, and the
+easiest time to select an alternative init system is during the
+installation process.
+
+  
+
+  
+
+The best time to perform the switch is after . Note that the default GNOME desktop is harder
+to get to work without systemd in ,
+
+
+  Because its usual display-manager
+  gdm3 declares a dependency on
+  libpam-systemd
+
+
+ so if you want a desktop environment it will be easier
+to deselect GNOME and select another (Xfce, KDE Plasma, LXDE,
+Cinnamon, MATE, and LXQt have all been tested without systemd).
+
+  
+
+  
+
+Once that stage is complete, launch a shell (see ), and chroot into the installed system by typing
+chroot /target. You then need to tell
+apt to install your preferred init system and,
+unless you are not using a desktop environment at all,
+libpam-elogind to provide the necessary elogind session management
+facilities (which are provided by libpam-systemd and systemd in a
+default installation). For example, for System-V-like init, type
+apt install sysvinit-core libpam-elogind. This
+will install your new init system and elogind, and remove systemd,
+libpam-systemd and other components that can only work with
+systemd. If apt is proposing to remove a very
+large number of packages, then you probably selected a desktop
+environment that depends on systemd; it will be best to stop at
+this point and go back to the task selector to chose another
+instead.
+
+  
+
+  
+
+Once that is done, exit the chroot by typing
+exit, then switch back to the installer (if you
+were using a different virtual console by switching back; if you
+had selected the Execute a shell menu
+option, then by typing exit once more), and
+resume the installation by moving to the boot loader installation
+stage, which is typically installing GRUB (see ). You can now complete the
+installation process as normal.
+
+  
+
+  
+
+If you encounter any issues specifically associated with using an
+alternative init system, there is a https://www.chiark.greenend.org.uk/mailman/listinfo/debian-init-diversity/;>Debian
+init system diversity list who may be able to help.
+
+  
+
+
-- 
2.11.0

Bug#992033:

[Jay Aurabind]

Ugh, sorry the title should be:

"Drop down terminal hides after focus is lost"

Steps to repro:

1. Launch qterminal
2. With the qterminal active, other a tool to take screenshot, like
Spectacle for example.
3. Qterminal loses focus

Due to this bug, I'm unable to select a 'rectangular area' for the
screenshot which includes contents in the terminal.

Bug#992025: release-notes: Add section on switching init system

[Matthew Vernon]

Hi,

Thanks for your comments; I'll try and make a revised patch.

On 09/08/2021 12:56, Justin B Rye wrote:

Matthew Vernon wrote:



+   init systems, you install the new init system and reboot. The
+   exception is switching away from systemd - systemd's packages


(We don't seem to be consistent about our em dashes.)


Sorry, I'm not sure if you're saying you want an em-dash instead of a 
hyphen here, or if you don't think it matters?



+   identifying the packages to install later easier). Next, get
+   apt to download the new packages you need,


If you mean the whole package/dependency management system and not the
/usr/bin/apt executable then I'd recommend calling it APT.  On the


I in fact meant apt-get :)

Should I replace that with apt throughout? I tend to use apt-get for 
everything myself.


Regards,

Matthew

Bug#991999: ejabberd: Enable Elixir support

[Philipp Huebner]

Hi there!

> Dear Maintainer,
> 
> are there any plans to enable Elixir support?

So far there aren't any.


> I think Elixir support would make ejabberd more hackable.
> Writing custom modules is probably too hard for people (like me)
> unfamiliar with Erlang. Elixir language seems easier to learn.
> 
> I already managed to build a Debian package ejabberd-21.07 with Elixir
> support from salsa. (thank you for your great packaging job!)
> But my package is not ready for production. There is still a lot of
> work to do and my skills in Debian packaging and erlang/elixir/mix
> toolchain are too limited to work on this alone.
> 
> If you consider implementing this feature, I'd be happy to help.
> 

I know next to nothing about Elixir, but if you can help out I'd be
happy to add Elixir support to ejabberd in Debian.

It might be sensible to loop in the maintainers of Elixir in Debian.


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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#992033: qterminal: Drop down terminal closes are focus is lost

[Jay]

Package: qterminal
Version: 0.16.1-1
Severity: important
X-Debbugs-Cc: jay.aurab...@gmail.com

Dear Maintainer,

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

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

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


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

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

Versions of packages qterminal depends on:
ii  libc6  2.31-13
ii  libqt5core5a   5.15.2+dfsg-9
ii  libqt5dbus55.15.2+dfsg-9
ii  libqt5gui5 5.15.2+dfsg-9
ii  libqt5widgets5 5.15.2+dfsg-9
ii  libqt5x11extras5   5.15.2-2
ii  libqtermwidget5-0  0.16.1-1
ii  libstdc++6 10.2.1-6
ii  libx11-6   2:1.7.2-1

Versions of packages qterminal recommends:
ii  qterminal-l10n  0.16.1-1

qterminal suggests no packages.

Bug#992029: qemu-system-x86: microvm binary has no virtio device emulation

[Christian Ehrhardt]

 > qemu-system-x86_64-mircovm binary has no virtio device emulation.

Yeah it is pretty minimal as - after all - this is what it is about.

> $ qemu-system-x86_64-microvm -device ? |grep virtio | grep -v pci
> name "vhost-user-fs-device", bus virtio-bus
> name "virtio-serial-device", bus virtio-bus
> name "vhost-user-vsock-device", bus virtio-bus
> name "vhost-vsock-device", bus virtio-bus

This somewhat intentional as it is what you get with
--without-default-devices which is the root of the microvm thought.
And you also see how the devices that are present match the
competitors in the same space like firecracker - serial/user-fs/vsock
is almost an exact match to that.

> I want to use device emulations on qemu-system-x86_64-microvm,
>   virtconsole
>   virtio-blk-device
>   virtio-net-device
>   virtio-balloon-device
>   virtio-rng-device

I agree that some of them may be in the scope of a microvm.
blk / net / rng - I think those have valid use cases - not too aligned
to firecracker but in a minimal VM.
Balloon IMHO might be too much, OTOH microvms are even more about
density than usual VMs so maybe it is ok.
You see I'm torn ...

Eventually the microvm examples at
  https://github.com/bonzini/qemu/blob/master/docs/system/i386/microvm.rst
use virtio-blk-device and virtio-net-device, so that might suggest
some "agreement" with your request.

OTOH I'm still somewhat afraid that if we add devices with each
request that is valid on its own we end up with another full qemu.
And TBH I'd not even know if there are configure flags to enable those
after --without-default-devices, might be a set of messing with
config-target.h which sounds wrong.

Maybe one should even first start a discussion with Paolo about what
set of devices would be "the right ones" to configure for a microvm
instead of us and maybe others changing it every now and then.

TL;DR I appreciate the bug and discussion but I'm unsure how to
continue on this :-/
Michael do you have a strict opinion on this other than not being 100%
convinced of the microvm approach in the first place?

Bug#992025: release-notes: Add section on switching init system

[Justin B Rye]

Matthew Vernon wrote:
>> (We don't seem to be consistent about our em dashes.)
> 
> Sorry, I'm not sure if you're saying you want an em-dash instead of a hyphen
> here, or if you don't think it matters?

It probably doesn't matter.

>>> +   identifying the packages to install later easier). Next, get
>>> +   apt to download the new packages you need,
>> 
>> If you mean the whole package/dependency management system and not the
>> /usr/bin/apt executable then I'd recommend calling it APT.  On the
> 
> I in fact meant apt-get :)
> 
> Should I replace that with apt throughout? I tend to use apt-get for
> everything myself.

These days apt is supposed to be the basic tool for use whenever there
isn't some reason to resort to something more specialised; most of the
Internet sources that mention apt-get do so only because of decades of
documentational inertia.  (Speaking of which: I hadn't realised we
still had an APT User guide in https://www.debian.org/doc/user-manuals
with a 1998 last-modified date!)

On the other hand in this case we're not exactly writing this section
for an audience of inexperienced users who are keen early adopters of
the latest Debian standard...
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#992032: weechat-matrix: wrapper cannot 'disable'

[Felix Lechner]

Package: weechat-matrix
Severity: normal

Hi,

The command 'weechat-matrix-wrapper enable' sets symbolic links as
expected, but the corresponding

weechat-matrix-wrapper disable

does not remove them. IInstead, it produces this error message:

$ weechat-matrix-wrapper disable
Disabling Weechat-matrix
Weechat-matrix installed into /home/lechner/.weechat/python/matrix,
unable to continue

Upon inspection, the issue seems to relate to those lines in the wrapper:

if [ -d $DESTINATION/matrix ]; then
echo "Weechat-matrix installed into $DESTINATION/matrix,
unable to continue"
exit 1
fi

For the linked directory created by 'enable' the removal should
proceed, but the condition returns true and aborts.

Below is a patch that checks instead that both paths are links (which
is what 'enable' installed). The patch was tested locally. Thank you!

Kind regards
Felix Lechner

* * *

--- weechat-matrix-wrapper  2021-08-09 06:13:05.820766987 -0700
+++ /usr/bin/weechat-matrix-wrapper 2021-08-09 06:35:44.739926938 -0700
@@ -20,24 +20,26 @@
 if [ "$ACTION" = "enable" ]; then
 echo "Enabling Weechat-matrix"
 if [ -L $DESTINATION/matrix ]; then
-echo "Weechat-matrix already enabled"
+echo "Weechat-matrix was already enabled"
 exit 0
 fi
 if [ -d $DESTINATION/matrix ]; then
-echo "Weechat-matrix installed into $DESTINATION/matrix,
unable to continue"
+echo "$DESTINATION/matrix exists, unable to continue"
 exit 1
 fi
 ln -s $SOURCE/matrix $DESTINATION/matrix
 ln -s $SOURCE/matrix.py $DESTINATION/autoload/matrix.py
 elif [ "$ACTION" = "disable" ]; then
 echo "Disabling Weechat-matrix"
-if [ -d $DESTINATION/matrix ]; then
-echo "Weechat-matrix installed into $DESTINATION/matrix,
unable to continue"
+if [ ! -L $DESTINATION/matrix ]; then
+echo "$DESTINATION/matrix is not a link, unable to continue"
 exit 1
 fi
-if [ -L $DESTINATION/matrix ]; then
-rm $DESTINATION/matrix $DESTINATION/autoload/matrix.py
+if [ ! -L $DESTINATION/autoload/matrix.py ]; then
+echo "$DESTINATION/autoload/matrix.py is not a link, unable
to continue"
+exit 1
 fi
+rm -f $DESTINATION/matrix $DESTINATION/autoload/matrix.py
 else
 showhelp
 fi

Bug#992031: djview: Unable to add djview to Favorites in Gnome shell

[Janusz S. Bień]

Package: djview Version: 3.5.27.1-10 Severity: wishlist

For most program there is an option "Add to Favorities", but it is
absent for djview. The djview.desktop file missing?

There is the file
/usr/share/applications/djvulibre-djview4.desktop
but it seems not used in any way.

Calling explicitely djview4 does not solve the problem.

Best regards

Janusz

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

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

Versions of packages djview depends on:
ii  djview4  4.11-1

djview recommends no packages.

djview suggests no packages.

-- no debconf information

-- 
 ,   
Janusz S. Bien
emeryt (emeritus)
https://sites.google.com/view/jsbien

Bug#992025: release-notes: Add section on switching init system

[Justin B Rye]

Holger Wansing wrote:
>>> +   If you encounter any issues specifically associated with using
>>> +   an alternative init system, there is a Debian init system
>>> +   diversity list (>> +   
>>> url="debian-init-divers...@chiark.greenend.org.uk">debian-init-divers...@chiark.greenend.org.uk)
>>> +   who may be able to help.
>>> +  
>>> +
>>>
>>
>> I wouldn't call a mailinglist a "who", and I wouldn't introduce a
>> publicly archived list with just the To-address - perhaps make this
>>>
>>an alternative init system, help may be available from the >  
>> url="https://www.chiark.greenend.org.uk/mailman/listinfo/debian-init-diversity/;>Debian
>>init system diversity list.
 
> That's not a lists.debian.org mailinglist.
> So, is it ok, to call it a " Debian ... list" ?

In principle all we want to say is that it's a list named
"Debian-init-diversity" (because it's a list *about* Debian stuff).
We've expanded that name slightly by referring to it as the "Debian
init *system* diversity list", but if necessary it could just stick to

   an alternative init system, help may be available from https://www.chiark.greenend.org.uk/mailman/listinfo/debian-init-diversity/;>the
   Debian-init-diversity list.

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#990435: diodon: /etc/apport/ needed?

[Christoph Anton Mitterer]

Hey.

Seems that this didn't work perfectly:
Unpacking diodon (1.11.1-1) over (1.11.0-1) ...
dpkg: warning: unable to delete old directory '/etc/apport/crashdb.conf.d': 
Directory not empty
dpkg: warning: unable to delete old directory '/etc/apport': Directory not empty
Preparing to unpack .../libdiodon0_1.11.1-1_amd64.deb ...


However, the directories are empty, but now leftover :-(

# find /etc/apport/
/etc/apport/
/etc/apport/crashdb.conf.d



Cheers,
Chris.

Bug#991982: nano does not work with TERM unset

[Bastien Roucariès]

Le dimanche 8 août 2021, 10:04:30 UTC Benno Schulenberg a écrit :
> > $env -i nano
> > command fail because TERM is unset
> 
> I can work around an unset TERM.  But what if TERM=="" or TERM=="nonsense"?
> Checking whether TERM is a valid terminal name goes too far, in my opinion.
> 
> Also, is the 'vt100' terminal description guaranteed to exist?  I ask,
> because 'dumb' and 'vt52' are not good enough for nano (ncurses) to work
> properly, and 'ansi' leaves the cursor invisible on a VTE-based terminal.
nano work with TERM=dumb (but is strange but it work), so safer will be to 
consider as best effort TERM="" , TERM not set, equivalent to dumb.

At least it fix this bug.

Bastien
> 
> Benno



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

Bug#869169: RFP: minisign -- A dead simple tool to sign files and verify signatures

[Chirayu Desai]

Hi,

Are there any updates on this?

@fancycade do you have the package available somewhere by any chance?

--
Regards,
Chirayu Desai

Bug#992030: ghostscript: ps2epsi does not find ps2epsi.ps any more

[Markus Demleitner]

Package: ghostscript
Version: 9.53.3~dfsg-7
Severity: normal

Dear Maintainer,

In bullseye, the ps2epsi script appears broken.  ps2epsi something.ps
invariably ends in

  Error: /undefinedfilename in (/usr/bin/ps2epsi.ps)

(and a ghostscript stack dump).

Looking into the script, this doesn't seem surprising, given it explicitly
says

# Note, we expect 'ps2epsi.ps' to be in the same directory as 'ps2epsi'

Indeed, replacing the "$LIBDIR/ps2epsi.ps" in the next line with
/usr/share/ghostscript/9.53.3/lib/ps2epsi.ps restores functionality.
Well...  thinking again: just removing the "$LIBDIR/" and relying on
ghostscript's search path is fine, too.



-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: i386 (x86_64)

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

Versions of packages ghostscript depends on:
ii  libc6   2.31-13
ii  libgs9  9.53.3~dfsg-7

ghostscript recommends no packages.

Versions of packages ghostscript suggests:
ii  ghostscript-x  9.53.3~dfsg-7

-- no debconf information

Bug#992029: qemu-system-x86: microvm binary has no virtio device emulation

[Hiroaki Mizuguchi]

Package: qemu-system-x86
Version: 1:5.2+dfsg-11
Severity: wishlist

Dear Maintainer,

qemu-system-x86_64-mircovm binary has no virtio device emulation.
I want to use device emulations on qemu-system-x86_64-microvm,
  virtconsole
  virtio-blk-device
  virtio-net-device
  virtio-balloon-device
  virtio-rng-device

$ qemu-system-x86_64 -device ? |grep virtio | grep -v pci
name "vhost-scsi", bus virtio-bus
name "vhost-user-blk", bus virtio-bus
name "vhost-user-fs-device", bus virtio-bus
name "vhost-user-scsi", bus virtio-bus
name "virtio-9p-device", bus virtio-bus
name "virtio-blk-device", bus virtio-bus
name "virtio-scsi-device", bus virtio-bus
name "virtio-net-device", bus virtio-bus
name "vhost-user-input", bus virtio-bus
name "virtconsole", bus virtio-serial-bus
name "virtio-input-host-device", bus virtio-bus
name "virtio-keyboard-device", bus virtio-bus
name "virtio-mouse-device", bus virtio-bus
name "virtio-serial-device", bus virtio-bus
name "virtio-tablet-device", bus virtio-bus
name "virtserialport", bus virtio-serial-bus
name "vhost-user-gpu", bus virtio-bus
name "virtio-gpu-device", bus virtio-bus
name "virtio-vga", bus PCI
name "vhost-user-vsock-device", bus virtio-bus
name "vhost-vsock-device", bus virtio-bus
name "virtio-balloon-device", bus virtio-bus
name "virtio-crypto-device", bus virtio-bus
name "virtio-iommu-device", bus virtio-bus
name "virtio-mem", bus virtio-bus
name "virtio-rng-device", bus virtio-bus
name "virtio-pmem", bus virtio-bus

$ qemu-system-x86_64-microvm -device ? |grep virtio | grep -v pci
name "vhost-user-fs-device", bus virtio-bus
name "virtio-serial-device", bus virtio-bus
name "vhost-user-vsock-device", bus virtio-bus
name "vhost-vsock-device", bus virtio-bus

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

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

Versions of packages qemu-system-x86 depends on:
ii  ipxe-qemu 1.0.0+git-20190125.36a4c85-5.1
ii  libaio1   0.3.112-9
ii  libasound21.2.4-1.1
ii  libbrlapi0.8  6.3+dfsg-1
ii  libc6 2.31-13
ii  libcacard01:2.8.0-3
ii  libcapstone4  4.0.2-3
ii  libepoxy0 1.5.5-1
ii  libfdt1   1.6.0-1
ii  libgbm1   20.3.5-1
ii  libgcc-s1 10.2.1-6
ii  libglib2.0-0  2.66.8-1
ii  libgnutls30   3.7.1-5
ii  libibverbs1   33.2-1
ii  libjpeg62-turbo   1:2.0.6-4
ii  libncursesw6  6.2+20201114-2
ii  libnettle83.7.3-1
ii  libnuma1  2.0.12-1+b1
ii  libpixman-1-0 0.40.0-1
ii  libpmem1  1.10-2
ii  libpng16-16   1.6.37-3
ii  librdmacm133.2-1
ii  libsasl2-22.1.27+dfsg-2.1
ii  libseccomp2   2.5.1-1
ii  libslirp0 4.4.0-1
ii  libspice-server1  0.14.3-2.1
ii  libtinfo6 6.2+20201114-2
ii  libudev1  247.3-6
ii  liburing1 0.7-3
ii  libusb-1.0-0  2:1.0.24-3
ii  libusbredirparser10.8.0-1+b1
ii  libvdeplug2   4.0.1-2
ii  libvirglrenderer1 0.8.2-5
ii  libxendevicemodel14.14.2+25-gb6a8c4f72d-2
ii  libxenevtchn1 4.14.2+25-gb6a8c4f72d-2
ii  libxenforeignmemory1  4.14.2+25-gb6a8c4f72d-2
ii  libxengnttab1 4.14.2+25-gb6a8c4f72d-2
ii  libxenmisc4.144.14.2+25-gb6a8c4f72d-2
ii  libxenstore3.04.14.2+25-gb6a8c4f72d-2
ii  libxentoolcore1   4.14.2+25-gb6a8c4f72d-2
ii  qemu-system-common1:5.2+dfsg-11
ii  qemu-system-data  1:5.2+dfsg-11
ii  seabios   1.14.0-2
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages qemu-system-x86 recommends:
pn  ovmf 
pn  qemu-system-gui  
ii  qemu-utils   1:5.2+dfsg-11

Versions of packages qemu-system-x86 suggests:
pn  qemu-block-extra
ii  qemu-system-data [sgabios]  1:5.2+dfsg-11
pn  samba   
pn  vde2

-- no debconf information

Bug#992025: release-notes: Add section on switching init system

[Justin B Rye]

Matthew Vernon wrote:
> +
> +  
> + Switching Init System
> +  
> +  
> + The default init system in Debian is systemd. In bullseye, a
> + number of alternative init systems are supported (such as
> + System-V-style init and OpenRC). Generally, to switch between
> + init systems, you install the new init system and reboot. The
> + exception is switching away from systemd - systemd's packages

(We don't seem to be consistent about our em dashes.)

> + will refuse to be removed if systemd is running; so the
> + process is a little more involved.
> +  
> +  
> + In outline, you need to download the new packages you need,
> + switch to single-user mode, install these new packages, and
> + then reboot. The recommended approach is as follows. First,
> + clear out /var/cache/apt/archives by
> + running apt-get clean (this makes
> + identifying the packages to install later easier). Next, get
> + apt to download the new packages you need,

If you mean the whole package/dependency management system and not the
/usr/bin/apt executable then I'd recommend calling it APT.  On the
other hand all of these commands do seem to work equally well with apt
rather than apt-get, including the "apt clean" above.

> + e.g.: apt-get --download-only install sysvinit-core
> + libpam-elogind; libpam-elogind (and elogind which it
> + Depends upon) provide session management facilities, which you
> + will likely need on any system running a desktop
> + environment. At this point, review apt's proposed actions, and
> + if happy, let it carry on.

With some extra markup, not all of which makes any actual difference,
and with s/apt-get/apt/g:

clear out /var/cache/apt/archives by
running apt clean (this makes identifying
the packages to install later easier). Next, get
apt to download the new packages you need,
e.g.: apt --download-only install sysvinit-core
libpam-elogind; libpam-elogind (and elogind which it Depends upon)
provide session management facilities, which you will likely
need on any system running a desktop environment. At this
point, review apt's proposed actions, and
if happy, let it carry on.

> +  
> +  
> + Now switch to single-user mode (systemctl
> + rescue) and install the packages you downloaded
> + using dpkg -i; the packages will be in
> + /var/cache/apt/archives. Once dpkg has
> + completed, reboot your system.
> +  

(You could make this "apt install /var/cache/apt/archives/*deb"!)

> +  
> + If you encounter any issues specifically associated with using
> + an alternative init system, there is a Debian init system
> + diversity list ( + 
> url="debian-init-divers...@chiark.greenend.org.uk">debian-init-divers...@chiark.greenend.org.uk)
> + who may be able to help.
> +  
> +
>

I wouldn't call a mailinglist a "who", and I wouldn't introduce a
publicly archived list with just the To-address - perhaps make this

an alternative init system, help may be available from the https://www.chiark.greenend.org.uk/mailman/listinfo/debian-init-diversity/;>Debian
init system diversity list.

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#991813: [Pkg-net-snmp-devel] net-smnp packaging team also suitable for other snmp packages?

[Craig Small]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2021-08-03 at 08:48, t...@debian.org wrote:

> Best of course would be that the packages would be team maintained,
> so I'm wondering if the net-snmp would be open to the idea to expand
their
> scope to handle also such packages.

Hi Tobi,
  I don't think there really is much of a team. Not sure what happened (my
working theory is they all finally understood how to read ASN.1 and went
mad in the process).
I think I'm all that's left as far as active maintainers. The email list
has 5 members.

However, I'm willing to help. There's probably some overlap in the strange
sort of bugs snmp can bring.
The other complexity is that net-snmp uses the old style type of team, see
https://wiki.debian.org/Alioth/MailingListContinuation .  Looking into it,
I really should move it to the new-style team maintainership (like how the
Python team works).
I don't think it would be a good idea to make a new package use an
old-style team.

I'm not sure of your timings, but I probably should actually start to move
net-snmp onto the new style team. It would have been nice to do this before
the freeze but we are here now.

 - Craig
-BEGIN PGP SIGNATURE-
Version: FlowCrypt Email Encryption 8.1.3
Comment: Seamlessly send and receive encrypted email

wsFzBAEBCgAGBQJhERDBACEJEAIhZsD/PITjFiEEXT3w9TizJ8CqeneiAiFm
wP88hOPqBhAAjf6r5d7jFiirx/AiUZQbxTHHA50MimmiTaFSK7WPHwi9lM/1
EtJWJAoPdkqtwxHK5ip3rPjupfnVOMLoJitM9iejSRXLk9P5q6DM/3tFE0WH
AVgK+pN/EVyTAkGqVgwuSkfBZxT0x613Un5Y3k1kR3Q5YE47bGkttK9+/Uck
emeNbf3MUDixlaYrnxLasQl32K9F7XtnN7XJe1ymkoCi+uooGRN984qCzVOT
CBFYCzY8Rwe8LE5CK6kK5hZknSdspabyKefVhrzBnB9y5AL+3GA8Dp19glmo
eLyzDe8S9YG4y2b6YoDg3dcYgZN/aoZtuCNFMQvP+har0+Zvh8QGJ6/M70Uo
feSctT4Pq4jNvXQNheXsjIoyGsxZR6nMZ4zebQp5yUVcDYeYHj8xKVb6llh7
18WK7wNcRwSKNkWzP1kcZi+uSzdqMi6utak+pasjufov2syQKLwgQ2FLa4Tq
essut6dUjEcZN0cMS1EKCN0/oaob1qN00UOT6Q5R+2ZXQG7NM66W7s9UgQNZ
WSFWDNYr0CpZdlym3APUyWMzein8rstEN2EGSf/H+5KsXDMa0fDrKdQayXsG
cPtLreucdj3YS2FjyIe0aIiMj5s9P2Y0SiZC9AFANSu6C7Dc2dsuhOx0qVwN
YBGIGWEWwlmMBInXr7CnlpwZJedOH2Axv/E=
=ZrDE
-END PGP SIGNATURE-


0x3938F96BDF50FEA5.asc
Description: application/pgp-keys

Bug#992027: ITP: openqa-client -- Python API to access openQA server

[Sudip Mukherjee]

Package: wnpp
Severity: wishlist
Owner: Sudip Mukherjee 
X-Debbugs-Cc: debian-de...@lists.debian.org, sudipm.mukher...@gmail.com, Philip 
Hands 

* Package name: openqa-client
  Version : 4.1.2
* URL : https://github.com/os-autoinst/openQA-python-client
* License : GPL-2.0
  Programming Lang: Python
  Description : Python API to access openQA server

This is a client for the openQA API, based on requests.
The API always returns JSON responses; this client's
request functions parse the response before returning it.

There is already another RFP for openqa server and the client,
#840253 and I think Philip Hands is already working on that and
has made a great job at openqa.debian.net. This package is only
the python api to communicate with the openqa server. I do use
it as part of my role in https://openqa.qa.codethink.co.uk/.

Added Cc to Philip Hands also and if he is planning to add Python API
as part of his implementation then I can close this and wait for him.


--
Regards
Sudip

Bug#992026: AES-256 not supported in testing/unstable - maybe fix missing?

[Philipp Flesch]

Package: net-snmp
Version: 5.9+dfsg-3+b1

Hi from Munich,
we tried to fetch some information using snmp-get with v3 from a network 
device which failed ...


Current (testing) snmp-get only suppports -x des or -x aes ... while 
redhat works fine (-x aes256).
We finally found https://bugzilla.redhat.com/show_bug.cgi?id=1846252 and 
the corresponding diff which may fix the issue: 
https://bugzilla.redhat.com/attachment.cgi?id=1696699=diff


Regards

Philipp

Bug#992025: release-notes: Add section on switching init system

[Matthew Vernon]

Package: release-notes
Severity: normal
Tags: patch

Hi,

Support for alternative init systems in bullseye is better than in
buster, but the process for switching is still a bit involved; I've
drafted a new subsection on the switching process. Could it be
included in the release notes, please?

Thanks,

Matthew

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

Kernel: Linux 4.9.0-16-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
>From 8b723915627d2546d4266d360cc41fbf3f7c6ebf Mon Sep 17 00:00:00 2001
From: Matthew Vernon 
Date: Mon, 9 Aug 2021 11:37:12 +0100
Subject: [PATCH] Add a subsection on changing init system

It's slightly fiddly to switch init system away from systemd, so
include a short note on doing so; and a pointer to the init-diversity
list for help.
---
 en/issues.dbk | 44 
 1 file changed, 44 insertions(+)

diff --git a/en/issues.dbk b/en/issues.dbk
index 1fbba7a3..555daed4 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -719,6 +719,50 @@ Environment=SYSTEMD_SULOGIN_FORCE=1
#802211.
   
 
+
+
+  
+   Switching Init System
+  
+  
+   The default init system in Debian is systemd. In bullseye, a
+   number of alternative init systems are supported (such as
+   System-V-style init and OpenRC). Generally, to switch between
+   init systems, you install the new init system and reboot. The
+   exception is switching away from systemd - systemd's packages
+   will refuse to be removed if systemd is running; so the
+   process is a little more involved.
+  
+  
+   In outline, you need to download the new packages you need,
+   switch to single-user mode, install these new packages, and
+   then reboot. The recommended approach is as follows. First,
+   clear out /var/cache/apt/archives by
+   running apt-get clean (this makes
+   identifying the packages to install later easier). Next, get
+   apt to download the new packages you need,
+   e.g.: apt-get --download-only install sysvinit-core
+   libpam-elogind; libpam-elogind (and elogind which it
+   Depends upon) provide session management facilities, which you
+   will likely need on any system running a desktop
+   environment. At this point, review apt's proposed actions, and
+   if happy, let it carry on.
+  
+  
+   Now switch to single-user mode (systemctl
+   rescue) and install the packages you downloaded
+   using dpkg -i; the packages will be in
+   /var/cache/apt/archives. Once dpkg has
+   completed, reboot your system.
+  
+  
+   If you encounter any issues specifically associated with using
+   an alternative init system, there is a Debian init system
+   diversity list (debian-init-divers...@chiark.greenend.org.uk)
+   who may be able to help.
+  
+
   
 
   
-- 
2.11.0

Bug#991896: [Pkg-zfsonlinux-devel] Bug#991896: New upstream version 2.1.0 available

[Chris Dos]

On 8/8/21 10:16 PM, Antonio Russo wrote:
> With the release coming up, I don't think anyone has made getting
> new versions of software into Debian a major priority. (So that's
> the excuse this time!)
> 
> (Post-release) As for 2.1, I'd like to get this into experimental
> -- and I'd like to keep unstable/bookworm on 2.0, since my
> understanding is that it is long-term stable, while 2.1 is short-
> term stable.
> 
> If it turns out that 2.1 gets kernel compatibility updates faster/
> more reliably than 2.0, I think that's a good argument to jumping
> to 2.1.  But, some of the features in 2.1 look like they might be
> high-risk.  I'm personally not moving to 2.1 for a while, for this
> reason.
> 
> (This is just me musing right now, I'm certainly not able to give
> an official answer).
> 
> Best,
> Antonio

There is no new functionality in 2.1 that I'm looking for and I think DRAID is
good for very niche systems and raidz* offers more redundancy.  But the most
important thing in 2.1 for us is the faster pool import times.  We have two
pools over 1.5 PB with over 230 hard drives.  Pool imports take over an hour.
 If those patches (#11470 #11502 #11469 #11467 #11467) could be back ported to
2.0 that would be even better.

Chris

Bug#992024: ITP: airsane -- SANE WebScan frontend that supports Apple's AirScan protocol

[Bastien Roucariès]

Package: wnpp
Severity: wishlist
Owner: Bastien Roucariès 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: airsane
  Version : 0.3.2
  Upstream Author : Simul Piscator
* URL : https://github.com/SimulPiscator/AirSane
* License : GPL3
  Programming Lang: C++
  Description :  SANE WebScan frontend that supports Apple's AirScan
protocol

 SANE WebScan frontend that supports Apple's AirScan protocol. Scanners are
detected automatically, and published through mDNS. Acquired images may be
transferred in JPEG, PNG, and PDF/raster format.

AirSane's intended purpose is to be used with AirScan/eSCL clients such as
Apple's Image Capture, but a simple web interface is provided as well.

Images are encoded on-the-fly during acquisition, keeping memory/storage
demands low. Thus, AirSane will run fine on a Raspberry Pi or similar device.

Bastien

Bug#992023: latexdiff: with \cite commands -->source with mismatched braces

[Hugh Pumphrey]

Package: latexdiff
Version: 1.3.1-1
Severity: important 
Tags: upstream

Dear Maintainer,


On upgrading from buster to bullseye I note that latexdiff is now 
affected with a bug which causes it to emit latex source which
does not compile, if the original source contained \cite{} (or indeed
\citep{} and \citet{}). The bug has been reported elsewhere and is described
clearly and in some detail at 

https://tex.stackexchange.com/questions/574280/latexdiff-with-cite-commands-gives-output-with-apparently-mismatched-braces

The stackexchange discussion provides a minimal working example and notes why
the bug occurs. It also suggests work-arounds.

Best wishes

Hugh Pumphrey


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

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

Versions of packages latexdiff depends on:
ii  perl  5.32.1-4

Versions of packages latexdiff recommends:
ii  texlive-latex-base 2020.20210202-3
ii  texlive-latex-extra2020.20210202-3
ii  texlive-latex-recommended  2020.20210202-3
ii  texlive-plain-generic  2020.20210202-3

Versions of packages latexdiff suggests:
ii  cvs 2:1.12.13+real-28
ii  git 1:2.30.2-1
ii  subversion  1.14.1-3

-- no debconf information

Bug#992002: [PATCH][Debian#992002] tbl: allow two-character fonts and format fonts in -Thtml

[Ingo Schwarze]

Hello Nab,

Nab wrote on Sun, Aug 08, 2021 at 03:24:53PM +0200:

> tbl's -Thtml ignores font requests;

Not in CVS HEAD; see https://cvsweb.bsd.lv/mandoc/tbl_html.c revision 1.34,
committed on May 16 earlier this year.

> additionally, the tbl f-request
> parser only allows single-character fonts.

Yes, that is still a missing feature.

> Cf. the Debian bug
> (http://bugs.debian.org/992002) for additional context.
> 
> Please consider the following patch.

Thank you very much for sending quite a non-trivial patch.
That was very helpful in understanding what exactly is needed.

I started from your patch and changed a few aspects:

 * You couldn't possibly know that i'm trying to work towards a
   unified system for identifying fonts using the mandoc.h
   enum mandoc_esc ESCAPE_FONT* identifiers.  Having different
   font identifiers for each output module is not good.
   So i added ESCAPE_FONTCB and ESCAPE_FONTCI and used those.
   A nice side effect is that CB and CI now work in HTML
   for all of \f, .ft, and tbl(7) f and that tbl(7) fBI
   now also works for terminal output.
 * GNU tbl(1) appears to ignore space characters between the f
   modifier and the font name, so "lf   B" is the same as "lfB".

> With this patch, the following document:
> -- >8 --
> .Dd
> .Dt V 1
> .Os
> .
> \fBtext\fItext\f(BItext\f(CRtext\f(CBtext\f(CItext\fR
> .Pp
> .TS
> lfB lfI lfBI lb li lbi lfCR lfCB lfCI .
> text  texttexttexttexttexttexttexttext
> .TE
> -- >8 --
> 
> Renders to a teletype with the expected fonts:
>   b, ul, bul;  b, ul, bul;  normal, b, ul

Not quite.  The expected output for lbi is ul, not bul.
The i overrides the b rather than add to it.
So lbi is the same as lfI, not as lfBI.

> -Thtml -Ofragment yields, as expected:
> -- >8 --
[...]
> 
>   
> text
> text
> text
> text
> text
> text

Again, text with my version of the patch.

> text
> text
> text

These become:

  text
  text

Could you please check out from CVS (instead of the last release),
apply the following patch, and tell me whether it looks reasonable
and works for you?

When this gets committed, i will credit you for reporting the
missing feature.  Do i understand correctly that "Nabija" is your
first name and "Czleweli" your last name?

Thanks again,
  Ingo

-- 
Ingo Schwarze 
http://www.openbsd.org/   
http://mandoc.bsd.lv/ 


Index: html.c
===
RCS file: /home/cvs/mandoc/mandoc/html.c,v
retrieving revision 1.273
diff -u -p -r1.273 html.c
--- html.c  2 Jun 2021 17:51:38 -   1.273
+++ html.c  9 Aug 2021 07:50:02 -
@@ -1,7 +1,7 @@
 /* $Id: html.c,v 1.273 2021/06/02 17:51:38 schwarze Exp $ */
 /*
- * Copyright (c) 2011-2015, 2017-2020 Ingo Schwarze 
  * Copyright (c) 2008-2011, 2014 Kristaps Dzonsons 
+ * Copyright (c) 2011-2015, 2017-2021 Ingo Schwarze 
  *
  * Permission to use, copy, modify, and distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
@@ -240,8 +240,10 @@ html_setfont(struct html *h, enum mandoc
case ESCAPE_FONTITALIC:
case ESCAPE_FONTBOLD:
case ESCAPE_FONTBI:
-   case ESCAPE_FONTCW:
case ESCAPE_FONTROMAN:
+   case ESCAPE_FONTCR:
+   case ESCAPE_FONTCB:
+   case ESCAPE_FONTCI:
break;
case ESCAPE_FONT:
font = ESCAPE_FONTROMAN;
@@ -272,9 +274,17 @@ print_metaf(struct html *h)
h->metaf = print_otag(h, TAG_B, "");
print_otag(h, TAG_I, "");
break;
-   case ESCAPE_FONTCW:
+   case ESCAPE_FONTCR:
h->metaf = print_otag(h, TAG_SPAN, "c", "Li");
break;
+   case ESCAPE_FONTCB:
+   h->metaf = print_otag(h, TAG_SPAN, "c", "Li");
+   print_otag(h, TAG_B, "");
+   break;
+   case ESCAPE_FONTCI:
+   h->metaf = print_otag(h, TAG_SPAN, "c", "Li");
+   print_otag(h, TAG_I, "");
+   break;
default:
break;
}
@@ -503,8 +513,10 @@ print_encode(struct html *h, const char 
case ESCAPE_FONTBOLD:
case ESCAPE_FONTITALIC:
case ESCAPE_FONTBI:
-   case ESCAPE_FONTCW:
case ESCAPE_FONTROMAN:
+   case ESCAPE_FONTCR:
+   case ESCAPE_FONTCB:
+   case ESCAPE_FONTCI:
if (0 == norecurse) {
h->flags |= HTML_NOSPACE;
if (html_setfont(h, esc))
Index: man_validate.c
===
RCS file: /home/cvs/mandoc/mandoc/man_validate.c,v
retrieving revision 1.155
diff -u -p -r1.155 man_validate.c
--- man_validate.c  30 Oct 2020 13:24:33 -  1.155
+++ man_validate.c  9 Aug 2021 07:50:02 -
@@ -239,7 +239,9 @@ 

Bug#991917: python3-wikitrans: Wiki 2 html conversion errors

[Erich Schubert]

Hi,

3. WikiDelimNodes (generated by wikimarkup: ''Example'') cause raw
JSON to be
inserted in the HTML:

Can you give more detail, please?


I believe this article causes the problem:

https://simpsons.fandom.com/wiki/John_Swartzwelder?action=edit

It may be because of seemingly mismatched quotes:

''The Simpsons''' 16th season

which is rendered (supposedly correct) as: "/The Simpsons'/ 16th season"

Regards,
Erich

Bug#991896: New upstream version 2.1.0 available

[Antonio Russo]

With the release coming up, I don't think anyone has made getting
new versions of software into Debian a major priority. (So that's
the excuse this time!)

(Post-release) As for 2.1, I'd like to get this into experimental
-- and I'd like to keep unstable/bookworm on 2.0, since my
understanding is that it is long-term stable, while 2.1 is short-
term stable.

If it turns out that 2.1 gets kernel compatibility updates faster/
more reliably than 2.0, I think that's a good argument to jumping
to 2.1.  But, some of the features in 2.1 look like they might be
high-risk.  I'm personally not moving to 2.1 for a while, for this
reason.

(This is just me musing right now, I'm certainly not able to give
an official answer).

Best,
Antonio

Bug#982598: incomplete logs for autopkg tests

[Holger Levsen]

On Sat, Aug 07, 2021 at 10:03:13PM +0200, Paul Gevers wrote:
> Control: retitle -1 trunkate huge logs at the start instead of the end
> > 
> > Unfortunately, we're hitting infrastructure issues if we don't cap the
> > logs [1]. However, I think we should save the last part (and not the
> > first part) if we have to cap, because normally the failure happens in
> > the end.

even better: keep the last part *and* the first 100 lines, because often
the start also has useful information. (that's what I've seen with both
piuparts and jenkins logs.)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

It's climate crime, not climate change.


signature.asc
Description: PGP signature

Bug#991558: marked as pending in ffmpeg

[Laurent Bigonville]

reopen 991558
Thanks

On Sun, 08 Aug 2021 20:24:31 + Sebastian Ramacher 
 wrote:



> Bug #991558 in ffmpeg reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:
>
> 
https://salsa.debian.org/multimedia-team/ffmpeg/-/commit/af2e638f462d6c5d040d337247b3aaddd543602d

>
> 
> Properly disable libsmbclient support only on hurd-i386
>
> Closes: #991558
> 

The build on hurd-i386 still fails for the same reason, the 
--enable-libsmbclient is apparently still passed on that architecture

Bug#991982: nano does not work with TERM unset

[Bastien Roucariès]

Le dimanche 8 août 2021, 14:57:42 UTC Bastien Roucariès a écrit :
> Le dimanche 8 août 2021, 10:04:30 UTC Benno Schulenberg a écrit :
> > > $env -i nano
> > > command fail because TERM is unset
> > 
> > I can work around an unset TERM.  But what if TERM=="" or
> > TERM=="nonsense"?
> > Checking whether TERM is a valid terminal name goes too far, in my
> > opinion.
> > 
> > Also, is the 'vt100' terminal description guaranteed to exist?  I ask,
> > because 'dumb' and 'vt52' are not good enough for nano (ncurses) to work
> > properly, and 'ansi' leaves the cursor invisible on a VTE-based terminal.
> 
> I do not know but I think the only sensible way to behave is like vi under
> POSIX (https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ex.html):
> TERM
> Determine the name of the terminal type. If this variable is unset or
> null, an unspecified default terminal type shall be used.
> 
> The other way are broken.

I should add if term is not supported failling with exit code 126 will help.
> 
> > Benno



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

Bug#111013: apt-listchanges fixes

[Brian Thompson]

On Mon, 12 Nov 2001 22:34:27 -0500 Matt Zimmerman  wrote:
> I must have completely overlooked the documentation fixes in your bug
> report; I thought you were just adding documentation for the option you
> added in your patch.  I've applied them in CVS now, thanks.
> 
> -- 
>  - mdz
> 
> 

Bug#111013: apt-listchanges fixes

[Brian Thompson]

On Mon, 12 Nov 2001 22:34:27 -0500 Matt Zimmerman  wrote:
> I must have completely overlooked the documentation fixes in your bug
> report; I thought you were just adding documentation for the option you
> added in your patch.  I've applied them in CVS now, thanks.
> 
> -- 
>  - mdz
> 
> 

Bug#992021: doc8: new upstream release (0.9.0) and homepage

[Paul Wise]

Package: python3-doc8
Version: 0.8.0-4
Severity: wishlist

The current Homepage redirects to a different page:

  https://git.openstack.org/cgit/openstack/doc8
   -> https://opendev.org/openstack/doc8/
   -> https://opendev.org/x/doc8

The final page in this chain of redirects has a plain text redirect:

   This project is no longer maintained in OpenStack.
   
   Please visit PyCQA to raise issues or make contributions:
   
   https://github.com/PyCQA/doc8

The new repository location lists a new release:

   0.9.0 Latest
   Jul 19, 2021

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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