Bug#994074: ITP: kubernetes-split-yaml -- Split a giant yaml file into one file per Kubernetes resource

[Arthur Diniz]

Package: wnpp
Severity: wishlist
Owner: Arthur Diniz 

* Package name: kubernetes-split-yaml
  Version : 0.3.0-1
  Upstream Author : Frederik Mogensen
* URL : https://github.com/mogensen/kubernetes-split-yaml
* License : Expat
  Programming Lang: Go
  Description : Split the 'giant yaml file' into one file pr kubernetes 
resource

 This program can be usefull in case it's necessary to split a big Kubernetes
 yaml manifest files into small ones.
 .
 It supports filters using namespaced hierarchy, Kubernetes objects starting
 with a word or Deployments and StatefulSets types.

Bug#743694: lintian: Downgrade most of privacy-breach* tags from severity: error to pedantic

[Paul Wise]

I think that the privacy breaches that lintian complains about
represent several sets of bugs that all need fixing:

The browsers shipping in Debian place no barriers between local files
on disk, sites on the local network and sites on the Internet. So if
someone reads some local documentation they didn't get from Debian
using a browser from Debian, they could have a privacy violation.

The documentation available in Debian may suggest readers request
resources not available as local files on disk. Even if we fix the
browsers available in Debian, users may read Debian documentation using
browsers not available in Debian, they could have a privacy violation.
When Debian documentation is copied to the web the same occurs.

The web applications available in Debian may suggest visitors request
resources not available on the same web service. Since most web
browsers don't block third-party requests by default, those visitors,
who are only indirectly Debian users, could have a privacy violation.
The same applies when Debian documentation is copied to a website.

Daniel Leidert wrote:

> To put packages through NEW they have to be lintian clean.

Not in my experience, I haven't tested it for the privacy tags though.

> The severity is not backed up by any of our policies.

I believe the issues to be a violation of the social contract,
albeit one of the parts that are aspirational rather than concrete.

> what right do we have to remove donation requests

That would be the wrong thing to do but that isn't what is requested.

> you have already configured your whole system

The majority people who are affected by privacy violations probably
don't understand that those violations exist, nor that mitigations
exist nor what those mitigations are nor how to configure them and
probably those mitigations are going to break their workflows.

> they are still tracked by hundreds of cookies
> while browsing websites or reading mails

This is being improved by the browser vendors, which are moving towards
blocking third-party cookies entirely.

> It just creates burden on fellow developers.

I believe that the burden exists, but is fairly minimal, replacing an
image with a styled button or similar is usually fairly simple.

PS: there are many more types of privacy violations in Debian:

https://wiki.debian.org/PrivacyIssues

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#994073: RM: libepsilon -- ROM; Dead upstream, no longer used by gdal

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org
Control: block -1 by 992527

Please remove libepsilon from the archive, it's dead upstream and no longer 
used by gdal.

Kind Regards,

Bas

Bug#994072: simplescreenrecorder: Please ask upstream to support VP9 and Opus

[mooff]

Package: simplescreenrecorder
Version: 0.4.2-2+b1
Severity: important
X-Debbugs-Cc: mooff@awful.cooking

Dear Maintainer,

VP9 and Opus are modern codecs which greatly improve the quality/size
ratio we can get with free tools.

Please ask upstream if they have any plans to support VP9 and Opus, or
similar public codecs, and include them post-haste in Debian Bullseye
and Bookworm :-)

Yours,
mooff

-- no debconf information

Bug#994071: ITP: aws-nuke -- Nuke a whole AWS account and delete all its resources.

[Arthur Diniz]

Package: wnpp
Severity: wishlist
Owner: Arthur Diniz 

* Package name: aws-nuke
  Version : 2.16.0-1
  Upstream Author : reBuy reCommerce GmbH
* URL : https://github.com/rebuy-de/aws-nuke
* License : Expat
  Programming Lang: Go
  Description : Nuke a whole AWS account and delete all its resources.

 Remove all resources from an AWS account.
 .
 Be aware that aws-nuke is a very destructive tool, hence be very careful while
 using it. Otherwise can cause production data deletion.
 .
 As an advise try to not run this application on any AWS account, where cannot
 be afforded to lose all resources. By default aws-nuke only lists all resources
 to delete. It's necessary to add --no-dry-run to actually delete resources.
 .
 This tool retries deleting all resources until all specified ones are deleted
 or until there are only resources with errors left. AWS Credentials There are
 two ways to authenticate aws-nuke. There are static credentials and profiles.
 The later one can be configured in the shared credentials file or the shared
 config file.

Bug#994070: Subject: reportbug: fluxbox-menu.5 manpage refers to nonexistent configuration files

[pell]

Package: fluxbox
Version: 1.3.5-2+b2
Severity: minor
Tags: patch

Dear Maintainer,

The fluxbox-menu.5 manpage refers several times to two nonexistent 
configuration files. Equivalent files

do exist in a different location with different names:

  - '/usr/share/fluxbox/menu' should be '/etc/X11/fluxbox/fluxbox-menu'
  - '/usr/share/fluxbox/windowmenu' should be 
'/etc/X11/fluxbox/window.menu'


I don't know if the manpage is wrong or if files are being installed in 
the wrong place.


Less critical, there is a near duplicate sentence in the DESCRIPTION 
section of the manpage:


  The first is the root menu, which normally appears when you 
right-click on the desktop.


  The first is the ROOT MENU (Or right-click menu), is usually bound to 
a right-click on the desktop,
  though this binding can be changed in the ‘keys’ file 
(fluxbox-keys(5)). This same
  syntax is used for the CustomMenu command, also mentioned in 
fluxbox-keys(5).


I suggest the first sentence be removed.

Below I'm pasting a patch with my suggested changes.

= fluxbox-menu.5 manpage patch begins 
=

34c34
< /usr/share/fluxbox/menu
---

/etc/X11/fluxbox/fluxbox-menu

48,49d47
< The first is the root menu, which normally appears when you 
right\-click on the desktop\&.

< .sp
52c50
< Fluxbox installs a default root menu file in 
\fB/usr/share/fluxbox/menu\fR\&. You can also use fluxbox \-i to confirm 
this location\&. Of course this system\-wide menu can be customized for 
all users at once, but it is also possible to create an individual menu 
file for each user\&. By convention, users create a menu file in 
\fB~/\&.fluxbox/menu\fR\&. Once you\(cqve created your own menu file, 
you\(cqll want to make sure that you properly declare this location in 
your \(oqinit\(cq file so that fluxbox knows where to look\&. See 
\fBRESOURCES\fR, below for details\&.

---
Fluxbox installs a default root menu file in 
\fB/etc/X11/fluxbox/fluxbox-menu\fR\&. You can also use fluxbox \-i to 
confirm this location\&. Of course this system\-wide menu can be 
customized for all users at once, but it is also possible to create an 
individual menu file for each user\&. By convention, users create a 
menu file in \fB~/\&.fluxbox/menu\fR\&. Once you\(cqve created your own 
menu file, you\(cqll want to make sure that you properly declare this 
location in your \(oqinit\(cq file so that fluxbox knows where to 
look\&. See \fBRESOURCES\fR, below for details\&.

54c52
< The second type is the \fBWINDOW MENU\fR, which defines the contents 
of the menu which appears when you right\-click on a window\(cqs 
titlebar or iconbar\&. This opens a menu file as defined by 
\fB~/\&.fluxbox/windowmenu\fR\&. If this file does not exist, fluxbox 
will copy in the default from \fB/usr/share/fluxbox/windowmenu\fR\&.

---
The second type is the \fBWINDOW MENU\fR, which defines the contents of 
the menu which appears when you right\-click on a window\(cqs titlebar 
or iconbar\&. This opens a menu file as defined by 
\fB~/\&.fluxbox/windowmenu\fR\&. If this file does not exist, fluxbox 
will copy in the default from \fB/etc/X11/fluxbox/window.menu\fR\&.

357c355
< \fB/usr/share/fluxbox/menu\fR
---

\fB/etc/X11/fluxbox/fluxbox-menu\fR

367c365
< \fB/usr/share/fluxbox/menu\fR
---

\fB/etc/X11/fluxbox/window.menu\fR
= fluxbox-menu.5 manpage patch ends 
=


I hope this helps. Thank you for your efforts to provide an excellent 
operating system.


pell (Eric Pellegrin)


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

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

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

Versions of packages fluxbox depends on:
ii  libc62.31-13
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libfribidi0  1.0.8-2
ii  libgcc-s1 [libgcc1]  10.2.1-6
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libice6  2:1.0.10-1
ii  libimlib21.7.1-2
ii  libsm6   2:1.2.3-1
ii  libstdc++6   10.2.1-6
ii  libx11-6 2:1.7.2-1
ii  libxext6 2:1.3.3-1.1
ii  libxft2  2.3.2-2
ii  libxinerama1 2:1.1.4-2
ii  libxpm4  1:3.5.12-1
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  menu 2.1.48

Versions of packages fluxbox recommends:
ii  feh  3.6.3-1
ii  xfonts-terminus  4.48-3

Versions of packages fluxbox suggests:
pn  fbautostart  
pn  fbdesk   
pn  fbpager  

-- no debconf information

Bug#994068: 1.4.11+dfsg.1-4: Please see issue at github: https://github.com/roundcube/roundcubemail/issues/8198

[Steve Dondley]

Package: 1.4.11+dfsg.1-4
Version: roundcube
Severity: normal

Dear Maintainer,

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

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

Bug#993971: kate: Kate puts a space when using some dead keys

[Adilson dos Santos Dantas]

Hi.

I have done a few tests on a virtual machine and I have discovered that the
problem is with ibus latest package.  I have problems with ibus 1.5.25  and
it is only fixed when I downgrade it to 1.5.24.

So I think that we should reassign this bug to ibus.

Regards,

Adilson

Em qui., 9 de set. de 2021 às 19:50, Norbert Preining 
escreveu:

> Hi all,
>
> > I did a test creating a file with the accented letters (my language is
> > LANG=it_it), getting these results:
> >
> > $ kate prova-accentate-àèéìòù-test
> >
> > prova-accentate-ￜￜￜￜￜￜ-test
>
> My guess is that there is a locale setup mismatch, and what happens is:
> - filename is encoded in latin1
> - kate expects utf8
> - kate replaces the non-interpretable characters from latin1 with
> �   (Unicode "REPLACEMENT CHARACTER")
>   which has hex utf-8 bytes
> EF BF BD
>   which you see in the hd output:
> > 0010  ef bf bd ef bf bd ef bf  bd ef bf bd ef bf bd ef
>
>
> I have never tried running KDE in a *non UTF-8* locale, that might be
> problematic.
>
> I tried to reproduce this with
> LANG=de_AT@euro kate
> (this is a iso locale defined on my computer) but kate always uses utf8.
>
> So I suggest that you make sure that your locales are properly set up,
> and match with the settings of kde.
>
> Best
>
> Norbert
>
> --
> PREINING Norbert  https://www.preining.info
> Fujitsu Research  +  IFMGA Guide  +  TU Wien  +  TeX Live  + Debian Dev
> GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
>


-- 
Adilson dos Santos Dantas
http://www.adilson.net.br
http://twitter.com/adilsond

Bug#993018: valgrind: vgcore files unusable in gdb

[Bernhard Übelacker]

Dear Maintainer,
I tried to find out when this started to happen.

And I found this issue in releases 11-bullseye, 10-buster and 9-stretch.
In 8-jessie such a vgcore shows in gdb the correct line information.

Further looking brought me to stretch/testing as of 29.10.2016,
where the issue starts to be visible.
At that date the gcc-6 version changed from 6.2.0-6 to 6.2.0-9.

The changelog [1] entries between these versions mention
a "--enable-default-pie".
So I tested to build the executable with the option "-no-pie"
in buster/stable which made the vgcore work. Therefore
this PIE option might be related.

Kind regards,
Bernhard

[1] 
https://metadata.ftp-master.debian.org/changelogs//main/g/gcc-6/gcc-6_6.3.0-18+deb9u1_changelog

Bug#994050: linux-image-5.10.0-8-amd64: Hauppauge WinTV-HVR1110 DVB-T/Hybrid bug 125 ms polling on ir-kbd-i2c.ko bad DEFAULT_POLLING_INTERVAL

[Joaquín Alberto Calderón Pozo]

Hi Salvatore.

As I mentioned early, I am newbie in reporting bugs and your help is much 
appreciated.

It is the first time I report a bug, and as you noticed I don't know where to 
start, this is the reason I read the debian documentation and using the 
reportbug program.

As after what you've told me it doesn't seem to be a downstream issue, I will 
investigate and further report in upstream and sorry for the inconveniences.

Best regards.

From: Salvatore Bonaccorso  on behalf of 
Salvatore Bonaccorso 
Sent: Friday, September 10, 2021 21:06
To: Joaquín Alberto Calderón ; 
994...@bugs.debian.org <994...@bugs.debian.org>
Subject: Re: Bug#994050: linux-image-5.10.0-8-amd64: Hauppauge WinTV-HVR1110 
DVB-T/Hybrid bug 125 ms polling on ir-kbd-i2c.ko bad DEFAULT_POLLING_INTERVAL

Control: tags -1 + moreinfo upstream

Hi

On Fri, Sep 10, 2021 at 07:18:07PM +0200, Joaquín Alberto Calderón wrote:
> Package: src:linux
> Version: 5.10.46-4
> Severity: important
> Tags: patch
> X-Debbugs-Cc: kini_calde...@hotmail.com
>
> Although I have a very old pci (not express) Hauppauge WinTV-HVR1110
> DVB-T/Hybrid TV card with a remote control, I am still using it because has
> fully support and functionallity and it's hardware capable of play DVB-T HD
> streams.
>
> It has a very strange behaviour:
>
> -One is it has a slow response when I push a key, has a delay, and sometimes
> even no key response, nothing happens, as if never push a key.
> -Other is when you hold a key, it start to begin the repeat key (characters
> like numerical) appears in the test app (kwrite) then, has a pause, stops to
> write characters, and begin the sequence again, writes some sequence, then
> stops... and so on. Even I noticed the repeat speed is a bit slow, compared to
> a keyboard key hold on.
>
> So... I began to investigates the causes and after two weeks of research,
> searchs on the web, I found the module affected and a solution.
>
> The module affected is ir-kbd-i2c.ko, this remote (rc5 protocol) uses this
> module as uinput (devinput) device, in resume as like an attatched keyboard.
> Resulting investigation in get noticed that this remote with rc5 protocol has
> 8hz of time frame when receiving the air gap code (rc5 procotol timing).
>
> Investigating the sources files in the kernel sources for try and fall, re-
> compiling the modules, get me to get noticed that the polling ir remote
> interval is 100ms which is 5hz, forcing this value to 125ms, re-compiling the
> module causes the remote to work normally as expecte, the response is like a
> real keyboard and the repeat sequence not only as speedy as a normal keyboard,
> but also hasn't got a pause in repetition. In resume, the problem is solved.
>
> Here is the patch:
>
> --- ir-kbd-i2c.original.c   2021-09-08 23:45:23.723210301 +0200
> +++ ir-kbd-i2c.hauppauge.patched.c  2021-09-10 03:55:28.003529072 +0200
> @@ -742,7 +742,7 @@
> return -ENOMEM;
>
> ir->c = client;
> -   ir->polling_interval = DEFAULT_POLLING_INTERVAL;
> +   ir->polling_interval = 125;
> i2c_set_clientdata(client, ir);
>
> switch(addr) {
>
> I am a experienced user, but not an experienced developer, also in
> editing/submitting bugs, I don't know if this is the right way to solve this,
> If the rest of brand remotes are affected for my solution, but for me, solved
> my problem in this particular case.
>
> I don't know where the value DEFAULT_POLLING_INTERVAL is get stablished or a
> way when detect a Hauppauge WinTV-HVR1110 DVB-T/Hybrid TV card to stablish
> 125ms instead of 100ms. As I said, I'm not an expert but experienced user.
>
> I don't know if this is the right package to post this bug. Thanks.

Thanks for the report!

This is IMHO not something which should handled with an entry point in
downstream in Debian, but rather going to report it upstream directly.
Can you do that?

Details on reporting: 
https://www.kernel.org/doc/html/latest/admin-guide/bug-hunting.html

Best guess for reporting the issue you are seeing:

$ ./scripts/get_maintainer.pl ./drivers/media/i2c/ir-kbd-i2c.c
Mauro Carvalho Chehab  (maintainer:MEDIA INPUT 
INFRASTRUCTURE (V4L/DVB),commit_signer:1/1=100%)
Sean Young  (commit_signer:1/1=100%)
Christophe JAILLET  
(commit_signer:1/1=100%,authored:1/1=100%,added_lines:2/2=100%,removed_lines:2/2=100%)
linux-me...@vger.kernel.org (open list:MEDIA INPUT INFRASTRUCTURE (V4L/DVB))
linux-ker...@vger.kernel.org (open list)

Feel free to keep this bugreport downstream into the loop.

Regards,
Salvatore

Bug#991967: #991967: Simply ACPI powerdown/reset issue?

[Elliott Mitchell]

An experiment lead to a potential alternative explanation for #991967.
The issue may be ACPI (non-UEFI) powerdown/reset was broken at
4.19.194-3.  Presence of Xen on the system may be unrelated.

Failing that, it could be Xen and non-UEFI systems are effected.  (Xen
was tried on a UEFI system and the issue wasn't observed)


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#993083: Info received (Patch attached)

[Rob]

Actually, totally munged that 1 line change somehow.

Corrected Patch attached.--- a/deluge/log.py
+++ b/deluge/log.py
@@ -86,7 +86,7 @@
 def exception(self, msg, *args, **kwargs):
 yield LoggingLoggerClass.exception(self, msg, *args, **kwargs)
 
-def findCaller(self, stack_info=False):  # NOQA: N802
+def findCaller(self, *args, **kwargs):  # NOQA: N802
 f = logging.currentframe().f_back
 rv = '(unknown file)', 0, '(unknown function)'
 while hasattr(f, 'f_code'):

Bug#993083: Patch attached

[Rob]

See attached for patch--- a/deluge/log.py
+++ b/deluge/log.py
@@ -86,7 +86,7 @@
 def exception(self, msg, *args, **kwargs):
 yield LoggingLoggerClass.exception(self, msg, *args, **kwargs)
 
-def findCaller(self, stack_info=False):  # NOQA: N802
+def findCaller(self, stack_info=False, **kwargs):  # NOQA: N802
 f = logging.currentframe().f_back
 rv = '(unknown file)', 0, '(unknown function)'
 while hasattr(f, 'f_code'):

Bug#901795: cryptsetup-initramfs: please provide documented shell functions to validate/sanitize cryptroot entries in 3rd party hook files

[Guilhem Moulin]

On Sat, 11 Sep 2021 at 01:31:31 +0200, Christoph Anton Mitterer wrote:
> I mean in a keyscript, CRYPTTAB_* are anyway already set for the
> "current" target, right?
> And in a initramfs hook, I anyway need to loop over all of them... or
> at least I wouldn't have a particular (target) name to search for?

Right.

> 2) crypttab_foreach_entry()
> That's what I'd use in the hook. But you've mentioned that the
> callbacks return value is ignored.
> Could that be changed perhaps?

If desired, yes.

> In my case it's probably not a big deal:
> - if the callback would find that the "current" entry isn't meant for
>  "my" script, then it could just return without doing anything
> - if however an error occurs (e.g. no pathname= set) it would anyway
>  just exit 1 the whole hook, since it's "catatrophic" failure and an
>  initramfs level device couldn't be unlocked

Right, that's what we're doing too.

> Also in crypttab_foreach_entry(), do I already have CRYPTTAB_OPTION_*?
> Or really just the four CRYPTTAB_{NAME,SOURCE,KEY,OPTIONS} and I need
> to call crypttab_parse_options to get the split up ones?

You need to call crypttab_parse_options() in the callback, see the
cryptgnupg keyscript for an example.  IIRC this is intentional because
te callback need to have the ability to bail out before option
validation.
 
> But in keyscripts I would already have CRYPTTAB_OPTION_*, too, right?

That's what's documented in crypttab(5).

> 3) Escaping
> My understanding is, that in both, the keyscript and the hook (when
> using e.g. crypttab_foreach_entry()) any CRYPTTAB_* is already
> unescaped, right?

Yes.  FWIW the original unescaped values can be found in _CRYPTTAB_*,
but this is undocumented and thus may not be relied upon.

> You also mention above, that CRYPTTAB_OPTIONS is not safe to use, when
> values contain ",".
> I assume this is because, the unescaped CRYPTTAB_OPTIONS would contain
> both, the "," from the values and the "," from the separators?
> While CRYPTTAB_OPTION_* would take care of that properly?

Correct.

> For which fields are the octal escapes handled? The manpage only
> mentions them for them for the key/3rd field.

My bad, it's supported in all fields.

> 4) Wishlist ;-)
> Can we have something like the option splitting for the key/3rd field,
> too?

That's too much a niche case IMHO.  When you use a key script the 3rd
field is an opaque value passed along and you might treat it any way you
see fit.

> In the end,... and you'll probably not like it ^^ ... I'd even suggest
> to rename the 3rd filed to something more generic... just KEY or
> KEYOPTIONS or so.

That would have have been a valid suggestion at the time the interface
was designed, but many releases later I'm afraid renaming is not an
option.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#994062: Acknowledgement (gnome-shell-extension-tilix-dropdown: No JS module 'tweener' found in search path)

[Ted To]

After updating extension.js along the lines of
https://askubuntu.com/questions/1286212/no-js-module-tweener-found-in-search-path-gnome-shell-extension-error-on-ubun,
there is still an error with a "No property x_fill on StBin" error.

Bug#994069: age: Update versions of age

[Filippo Valsorda]

> since v1.0.0-rc.3

This was meant to be v1.0.0-rc.1, the version in the Debian repositories now.

Bug#994069: age: Update versions of age

[Filippo Valsorda]

Package: age
Version: 1.0.0~rc1-2+b3
Severity: important
X-Debbugs-Cc: fili...@ml.filippo.io

Dear Maintainer,

We recently published upstream v1.0.0 of age. There are some important changes
since v1.0.0-rc.3: a bug was fixed that would cause a percentage of armored 
files
to become corrupted; ssh-rsa keys too small to be secure are now rejected; a
limit on the number of recipients in a file has been lifted; and a few more.

The release also includes comprehensive manual pages.

We'd like to see v1.0.0 imported into testing, but would also like to see the
important bugs fixed in Debian 11.1. These bugs can cause data loss or 
significant
confusion since the version of age in Debian would refuse to decrypt valid 
files.

We prepared a branch of backports for Debian 11.1, in case v1.0.0 is deemed too
large a change to import. https://github.com/FiloSottile/age/commits/debian/11

Thank you,
Filippo

-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.10.47-linuxkit (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_RANDSTRUCT
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages age depends on:
ii  libc6  2.31-13

age recommends no packages.

age suggests no packages.

-- no debconf information

Bug#993945: transition: evolution-data-server

[Jeremy Bicha]

I went ahead and uploaded evolution-data-server 3.41.3 to the NEW
queue for experimental. The only soname bump was for libcamel which
only has evolution and evolution-rss as reverse dependencies.

The evolution 3.42 stable release is scheduled for September 17. So I
believe we'll be able to do just one evolution-data-server transition
to get unstable all the way to 3.42.

Thanks,
Jeremy Bicha

Bug#901795: cryptsetup-initramfs: please provide documented shell functions to validate/sanitize cryptroot entries in 3rd party hook files

[Christoph Anton Mitterer]

Oh and one more thing which is a bit unrelated to this, but also a bit
related ;-)

Could you clarify:
   tries=
   Try to unlock the device  before failing. It's particularly
   useful when using a passphrase or a keyscript that asks for
   interactive input. If you want to disable retries, pass “tries=1”.
   Default is “3”. Setting “tries=0” means infinitive retries.


which AFAIU is how often cryptsetup invokes the keyscript and *not* how
often the keyscript itself tries (e.g. asking for a passphrase).

And that's also what should be clarified / "defined", like by saying:
   Try to unlock the device  before failing. Its how often
   the keyscript is invoked when it fails.
   If you want to disable retries, pass “tries=1”.
   Default is “3”. Setting “tries=0” means infinitive retries.
   Note that keyscripts themselves may do their own tries in
   addition.


What I describe above makes IMO actually sense, i.e. having two
different kind of tries:
Take my keyscript as an example, which waits for a device, reads a gpg-
enced key from it with passdev, then waits for a passphrase with
askpass and uses that to decrypt the data with gpg.

Currently, when I enter a wrong key (e.g. at boot time) I have to plug
the USB again (retry made by cryptsetup's 4th field tries=0), because
the keyscript exited and the already read stuff is gone.

With an additiones tries=, specific to the keyscript (and set again in
the 3rd field that I abuse so belovedly) I could do the following:

The "internal" tries is e.g. 3, so my own keyscript will already try
reading the passphrase and decrypting the previously read gpg-enced
file 3 times before giving up.

I could surround the asskpass with a timeout, just to make sure that
they keyscipt (with the precious key in memory, allowing for coldboot
attacks) doesn't stay there forever (e.g. if I forgot about the
computer and went shopping).
If the timeout would be e.g. 15s per default, and the internal tries 3,
they keyscript would wait at most 45s... and then exit.

Then the cryptsetup tries=n comes again (for the initramfs it probably
only makes sense with =0), but now, it would need the USB stick again.


Thanks,
Chris.

Bug#901795: cryptsetup-initramfs: please provide documented shell functions to validate/sanitize cryptroot entries in 3rd party hook files

[Christoph Anton Mitterer]

Hey.

Thanks for you reply. :-)

I'm still a bit unsure how to do it right, in certain aspects:

1) crypttab_find_entry()
What would be a use case for that?

I mean in a keyscript, CRYPTTAB_* are anyway already set for the
"current" target, right?
And in a initramfs hook, I anyway need to loop over all of them... or
at least I wouldn't have a particular (target) name to search for?




2) crypttab_foreach_entry()
That's what I'd use in the hook. But you've mentioned that the
callbacks return value is ignored.
Could that be changed perhaps?

In my case it's probably not a big deal:
- if the callback would find that the "current" entry isn't meant for
  "my" script, then it could just return without doing anything
- if however an error occurs (e.g. no pathname= set) it would anyway
  just exit 1 the whole hook, since it's "catatrophic" failure and an
  initramfs level device couldn't be unlocked

Still it might be nice to determine outside of the foreach to determine
what to do.
Of course one could just set a "global" variable, indicating an error
and set from within the callback.


Also in crypttab_foreach_entry(), do I already have CRYPTTAB_OPTION_*?
Or really just the four CRYPTTAB_{NAME,SOURCE,KEY,OPTIONS} and I need
to call crypttab_parse_options to get the split up ones?

But in keyscripts I would already have CRYPTTAB_OPTION_*, too, right?



3) Escaping
My understanding is, that in both, the keyscript and the hook (when
using e.g. crypttab_foreach_entry()) any CRYPTTAB_* is already
unescaped, right?

You also mention above, that CRYPTTAB_OPTIONS is not safe to use, when
values contain ",".
I assume this is because, the unescaped CRYPTTAB_OPTIONS would contain
both, the "," from the values and the "," from the separators?
While CRYPTTAB_OPTION_* would take care of that properly?

So could I do basically something like this for the 4th field:
luks,keyscript=stupid\054name
and I'd get
CRYPTTAB_OPTIONS='luks,keyscript=stupid,name'
but
CRYPTTAB_OPTION_luks='yes'
CRYPTTAB_OPTION_keyscript='stupid,name'


For which fields are the octal escapes handled? The manpage only
mentions them for them for the key/3rd field.



4) Wishlist ;-)
Can we have something like the option splitting for the key/3rd field,
too?

You remember what I did? E.g.:
device=/dev/disk/by-label/boot-usb-stick:pathname=/path-on-that-device/key.gpg

Obviously there's the same issue, if some value would contain my
separator character (I've used : cause I wasn't sure if it troubles the
parsers from crypttab if I use , ... but I'd happily change to
something recommended from upstream).

I think there might be more keyscripts that benefit from this:
The fourth fields is rather for general crypttab options and I don't
think it would be wise if keyscript-specific options would be put in
there (mostly because they could collide with different keyscripts).

To me, the natural place or any options related to retrieving the key
is the 3rd field.
That would also include e.g. hostnames/ports for a keyscript that
retrieves the key via SSH,... or maybe if one uses a smartcard that can
hold multiple keys, the identifier of that cards keyslot.


I guess that would work similar to crypttab_parse_options? Maybe just a
different name crypttab_parse_keyfile_as_options?
The unsetting of variables you do there... that might be difficult to
do, since we have no idea how these options could be named, e.g.
CRYPTTAB_KEYFILEOPTION_device

I also don't think it’s easily possible to unset any
CRYPTTAB_KEYFILEOPTION_* variables.

"set" lists all name=value, but these may contain newlines and I think
it might not be easy to sanitize that.
$ dash
$ set
COLORTERM='truecolor'
DBUS_SESSION_BUS_ADDRESS='unix:path=/run/user/1000/bus'
...
HOME='/home/calestyo'
IFS='   
'
LANG='en_DE.UTF-8'


One could have a var like:
FOO='
BAR=baz
'


However,... it might actually work to do this generically:
If dash's syntax is really always:
name=value-with-some-quoting
with the 2nd ' being possibly in another line, we could do e.g.

set | sed -n 's/^\(CRYPTTAB_KEYFILEOPTION_[a-zA-Z_0-9]\+\)=.*$/\1/p'

and unset everything that results.
Sure this could contain some false positives, if e.g. someone had set
BAR='
CRYPTTAB_KEYFILEOPTION_foo='"'"'is not a var'"'"'
'

we would also get CRYPTTAB_KEYFILEOPTION_foo, but who cares? It's "our"
namespace.


Maybe you could also use that for unsetting CRYPTTAB_OPTION_*



In the end,... and you'll probably not like it ^^ ... I'd even suggest
to rename the 3rd filed to something more generic... just KEY or
KEYOPTIONS or so.
Simply to make it clear that this doesn't have to be a file.



Cheers,
Chris.

Bug#994062: gnome-shell-extension-tilix-dropdown: No JS module 'tweener' found in search path

[Ted To]

Package: gnome-shell-extension-tilix-dropdown
Version: 7-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

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

   * What led up to the situation?
installed gnome-shell-extension-tilix-dropdown
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
attempted to enable extension
   * What was the outcome of this action?
extension not enabled with the error given in the subject line.
   * What outcome did you expect instead?
extension enabled

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


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

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

Versions of packages gnome-shell-extension-tilix-dropdown depends on:
ii  gnome-shell  3.38.4-1
ii  tilix1.9.4-2

gnome-shell-extension-tilix-dropdown recommends no packages.

gnome-shell-extension-tilix-dropdown suggests no packages.

-- no debconf information

Bug#994067: foremost: undefined behavior if option -c is used as last argument

[Example Name]

Package: foremost
Version: 1.5.7-9.1

Running "foremost -T -c something" results in undefined behavior.
First, it calls `fopen()` with NULL as pathname. Second, it uses
argv[i] with i > argc. In my case, it tries to read files with
pathnames as environment variables. See strace:

$ strace --trace=openat foremost -T -c something
...
openat(AT_FDCWD, "foremost", O_RDONLY)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "-T", O_RDONLY)= -1 ENOENT (No such file or directory)
openat(AT_FDCWD, NULL, O_RDONLY)= -1 EFAULT (Bad address)
openat(AT_FDCWD, "SHELL=/bin/bash", O_RDONLY) = -1 ENOENT (No such
file or directory)

...

This is because the program doesn't check if "-c something" are the
last arguments when skipping them at 

The following patch fixes it:

--- a/main.c
+++ b/main.c
@@ -272,6 +272,9 @@
 {
 /*jump past the conf file so we don't process it.*/
 argv+=2;
+if (*argv == NULL) {
+break;
+}
 }
 testFile = fopen(*argv, "rb");
 if (testFile)
--- a/main.c
+++ b/main.c
@@ -272,6 +272,9 @@
 		{
 			/*jump past the conf file so we don't process it.*/
 			argv+=2;
+			if (*argv == NULL) {
+break;
+			}
 		}
 		testFile = fopen(*argv, "rb");
 		if (testFile)

Bug#994049: libhwloc-contrib-plugins: hwloc displays misleading CUDA and NVML errors when running MPI programs

[Samuel Thibault]

Hello,

Baptiste Jonglez, le ven. 10 sept. 2021 18:20:58 +0200, a ecrit:
> When the libhwloc-contrib-plugins package is installed, running any MPI
> program on a Debian 11 host with no GPU produces the following errors:
> 
> $ mpirun hostname
> CUDA: Failed to get number of devices with cudaGetDeviceCount(): no 
> CUDA-capable device is detected
> NVML: Failed to initialize with nvmlInit(): Driver Not Loaded
> CUDA: Failed to get number of devices with cudaGetDeviceCount(): no 
> CUDA-capable device is detected
> NVML: Failed to initialize with nvmlInit(): Driver Not Loaded
> dahu-28.grenoble.grid5000.fr
[...]
> This bug has already been fixed upstream in version 2.5.0rc1:
> 
> 835dfbe577fcd7 ("core: don't display "less critical" error messages by 
> default")
> https://github.com/open-mpi/hwloc/issues/453
> 
> Would it be possible to backport this patch to Debian stable or,
> as an alternative, publish hwloc 2.5.0 in bullseye-backports?

I was waiting for a good reason to take the time to backport hwloc 2.5,
that was one, it's now in backports-NEW :)

That said perhaps we can ask d-release for a stable upload, Brice what
do you think?

Samuel

Bug#993018: valgrind: vgcore files unusable in gdb

[Samuel Thibault]

Bernhard Übelacker, le sam. 11 sept. 2021 00:17:38 +0200, a ecrit:
> So I tested to build the executable with the option "-no-pie"
> in buster/stable which made the vgcore work. Therefore
> this PIE option might be related.

Ooh, very probably indeed!

Samuel

Bug#994019: libraw-doc: Package should include the samples

[Matteo F. Vescovi]

Control: reopen -1

Hi Dima!

On 2021-09-10 at 14:46 (-07), Dima Kogan wrote:
> Unless I'm missing something, I don't see the samples. What package are
> they in? I see the binaries built from the samples in libraw-bin:

[...]

> But the request in this bug report was to ship the sources of the
> samples as documentation. So that a person who wants to use the library
> to do stuff would have a better sense of what to write. As far as I can
> tell, the sources are not shipped in any package.

Ah, now I see. You were referring to pure C++ source code files in
samples/ ! I can add them to libraw-doc, indeed. Gonna do that with
next revision.

> Also, do we want to ship the binaries? Any particular reason to put them
> in /usr/lib/libraw? That's an odd place for executables.

Good question. When I inherited the package, that part was already set.
But I can disable samples compiling and copying only the source code.

Cheers.


-- 
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A


signature.asc
Description: PGP signature

Bug#994066: flash-kernel: kernel size check doesn't take appended device tree into account

[Uwe Kleine-König]

Hello,

On 9/10/21 11:07 PM, Uwe Kleine-König wrote:

when the active machine entry has an "Mtd-Kernel" field, flash-kernel
checks if the kernel fits into the specified mtd partition. However if
the machine entry also has "DTB-Append: yes" the image written to said
partition is a combination of kernel and dtb, and so the check must
include the dtb's size, too.


This is actually wrong, the misleading bit is, that the kernel 
partition's size is checked twice. The first time with the plain 
kernel's size (which might be a too weak check) and then later with the 
actual size which also includes U-Boot header and initrd size (in the 
case of a multi image). See commit abdc93372ef965a992850af8eed9381ccad83f76.


So I suggest the following patch instead:

diff --git a/functions b/functions
index 260be2ba2b3d..9824f6534111 100644
--- a/functions
+++ b/functions
@@ -855,7 +855,10 @@ if [ -n "$mtd_kernel" ]; then
check_char_dev "$kmtd"
kmtdsize=$(mtdsize "$mtd_kernel")
kreqsize=$kfilesize
-   check_mtd_size "$mtd_kernel" $kreqsize $kmtdsize kernel
+
+   # The actual check is done later to take into account things 
added the

+   # kernel image (e.g. U-Boot image header, initrd (for multi images)
+   # and/or an appended dtb
 fi
 if [ -n "$mtd_initrd" ]; then
imtd=$(mtdchar "$mtd_initrd")



OpenPGP_signature
Description: OpenPGP digital signature

Bug#994066: flash-kernel: kernel size check doesn't take appended device tree into account

[Uwe Kleine-König]

Package: flash-kernel
Version: 3.104
Severity: normal

Hello,

when the active machine entry has an "Mtd-Kernel" field, flash-kernel
checks if the kernel fits into the specified mtd partition. However if
the machine entry also has "DTB-Append: yes" the image written to said
partition is a combination of kernel and dtb, and so the check must
include the dtb's size, too.

Here is an untested patch:

diff --git a/functions b/functions
index 260be2ba2b3d..d5fd0f714300 100644
--- a/functions
+++ b/functions
@@ -842,6 +842,12 @@ if [ -n "$dtb_append_from" ]; then
 fi
 fi
 
+if [ "$dtb_append" = "yes" ]; then
+   dtb=$(find_dtb_file)
+   dfilesize=$(stat -c '%s' "$dtb")
+   kfilesize=$(($kfilesize + $dfilesize))
+fi
+
 if [ -n "$mtd_kernel" ] || [ -n "$mtd_initrd" ]; then
if [ ! -e "$PROC_MTD" ]; then
error "$PROC_MTD doesn't exist"

Best regards
Uwe

Bug#994065: flash-kernel: Overwriting an entry doesn't support to remove a field

[Uwe Kleine-König]

Package: flash-kernel
Version: 3.104
Severity: normal

Hello,

for the Netgear ReadyNAS 104 there is an entry in the shipped db that
looks as follows:

Machine: NETGEAR ReadyNAS 104
DTB-Id: armada-370-netgear-rn104.dtb
DTB-Append: yes
Mtd-Kernel: uImage
Mtd-Initrd: minirootfs
U-Boot-Kernel-Address: 0x0400
U-Boot-Initrd-Address: 0x0500
Required-Packages: u-boot-tools
Bootloader-Sets-Incorrect-Root: yes

As the minirootfs partition is too small to hold a bullseye initramfs I
want to increase the uImage partition, remove the minirootfs partition
and use in /etc/flash-kernel/db:

Machine: NETGEAR ReadyNAS 104
DTB-Id: armada-370-netgear-rn104.dtb
DTB-Append: yes
U-Boot-Multi-Address: 0x200
Mtd-Kernel: uImage
Required-Packages: u-boot-tools
Bootloader-Sets-Incorrect-Root: yes

However this doesn't do what I intend because flash-kernel merges the
two entries which results in the following config:

Machine: NETGEAR ReadyNAS 104
DTB-Id: armada-370-netgear-rn104.dtb
DTB-Append: yes
U-Boot-Multi-Address: 0x200
Mtd-Kernel: uImage
Required-Packages: u-boot-tools
Bootloader-Sets-Incorrect-Root: yes
Mtd-Initrd: minirootfs
U-Boot-Kernel-Address: 0x0400
U-Boot-Initrd-Address: 0x0500

which is broken and makes flash-kernel stumble.

As for other use-cases (i.e. just overwriting a single field) the merge
mechanism is quite useful, my thought is to write something like the
following to /etc/flash-kernel/db:

Machine: NETGEAR ReadyNAS 104
DTB-Id: armada-370-netgear-rn104.dtb
DTB-Append: yes
U-Boot-Multi-Address: 0x200
Mtd-Kernel: uImage
Required-Packages: u-boot-tools
Bootloader-Sets-Incorrect-Root: yes
# machine-entry-complete

and make get_machine_field() return 1 if it sees the
machine-entry-complete entry in state "fields".

The ugly detail here however is that the comment becomes magic which I
don't like much. (Sidenote: I could write "Machine: dummy" instead of
the above comment. Apart from emitting an error message flash-kernel's
behaviour becomes right :-)

Any better ideas?

Best regards
Uwe

Bug#994017: python3-pynetbox: please provide a bullseye-backport

[sub_code . debian]

On 9/9/21 10:07 PM, Georg Faerber wrote:
> Package: python3-pynetbox
> Severity: wishlist
> 
> Dear maintainer,
> 
> Would it be possible to provide a backport targeting bullseye?
> 
> Thanks a lot for maintaining python3-pynetbox in Debian!
> 
> Cheers,
> Georg

Hello,

I'll have to see how backports are handled exactly, but the last
pynetbox versions already build fine on bullseye and shouldn't pose any
real issue.

-- 
Johann Queuniet



OpenPGP_signature
Description: OpenPGP digital signature

Bug#993475: installation-guide: Linux is no operating system, GNU/Linux is

[Holger Wansing]

Control: tags -1 + pending

Erik Pfannenstein  wrote (Wed, 01 Sep 2021 22:02:34 +0200):
> Package: installation-guide
> Severity: normal
> 
> Dear Maintainer,
> 
> a while ago we recieved an e-mail notifying us that the chapter 1.02 states:
> "Linux is an operating system: […]" and that it should read "GNU/Linux is an 
> operating system" instead.
> Technically, that's right. I ask you to correct this.

Just pushed. Thanks


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#992183: [installation-guide] in example-preseed.txt file is missing a line for apt-setup

[Holger Wansing]

Control: tags -1 + pending

Holger Wansing  wrote (Sun, 15 Aug 2021 12:16:52 +0200):
> The only question being asked during such installation was the above, all the
> rest worked via preseeding.
> 
> 
> A patch for the installation-guide is attached.

Now pushed; tagging this bug as pending.

Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#993822: bullseye-pu: package clamav/0.103.3+dfsg-0+deb11u1

[Sebastian Andrzej Siewior]

On 2021-09-10 11:49:39 [+0100], Adam D. Barratt wrote:
> It appears that the bullseye upload is stuck on the upload queue,
> because:

Thank you.

> Regards,
> 
> Adam
Sebastian

Bug#994042: libc6: debconf text fallback failed to accept input, had to be killed leading to broken dist-upgrade

[Aurelien Jarno]

On 2021-09-10 20:39, Colin Watson wrote:
> On Fri, Sep 10, 2021 at 09:03:32PM +0200, Aurelien Jarno wrote:
> > On 2021-09-10 16:51, Colin Watson wrote:
> > > The only way to fix what libc.preinst is currently trying to do would
> > > be:
> > > 
> > >  * Fetch the current debconf frontend *without* first sourcing the
> > >confmodule, e.g. using something like "echo GET debconf/frontend |
> > >debconf-communicate" which I *think* is safe as long as you haven't
> > >sourced the confmodule yet;
> > > 
> > >  * Decide whether to use debconf based on this and other information;
> > > 
> > >  * Only source the confmodule if you've positively decided to use it.
> > 
> > debconf-communicate might be safe, but its manpage explicitly says it
> > should not be used in maintainer scripts.
> 
> Strictly, it says "a maintainer script of a package that uses debconf".
> I think what that really means is that it shouldn't be used after
> sourcing the debconf confmodule (which is normally the same as using
> debconf since nearly everything sources it right at the top - but this
> is a weird edge case).  The point is to avoid having multiple processes
> with the debconf database open at the same time.
> 
> Put another way, for this purpose, libc6.preinst isn't really a
> maintainer script that uses debconf until it sources the confmodule.
> 
> > I gave a try with debconf-show instead. I have attached a totally
> > untested patch to check that we agree on the way to do it.
> 
> I think you forgot to attach the patch?

Dooh. Please find a new version attached.

> I wouldn't completely veto using debconf-show in this very specialized
> situation, as long as it came with a substantial comment explaining
> what's going on so that nobody else is tempted to copy it.  However, the
> output format of debconf-show isn't guaranteed, so I'm not very happy
> about it being used mechanically like this.  I'd prefer
> debconf-communicate if we can ensure that it works in this context,
> notwithstanding its documentation.

Ok, I have updated my patch to use that method.

> > > But a simpler approach might be to update debconf in buster with the
> > > change from 1.5.76 to check whether whiptail/dialog is usable before
> > > trying to use it, and then remove at least some of this fragile and
> > > broken code from libc.preinst.  At the very least, USE_DEBCONF=1 must
> > > always be set if (and only if) the debconf confmodule has been sourced.
> > 
> > While it is probably a good idea to backport that change in buster to
> > limit to reduce the risk, we don't require people to upgrade to the
> > latest buster release before starting an upgrade.
> > 
> > On the other hand, given that bullseye has a fixed debconf, I fully
> > agree that we should drop that fragile code for bookworm.
> 
> We probably agree on both points here.

Great.

> > > I'm currently seeing if I can construct a reduced reproduction recipe
> > > based on Neil's logs, since it evidently depends on exactly which order
> > > apt chooses to unpack things early on, and it would be very helpful to
> > > be able to test fixes properly.
> > 
> > Thanks, tell me if you need help on that.
> 
> I managed to reproduce the reported bug by taking Neil's full package
> list, mangling it to roughly make sense on buster, installing all of
> that, and then doing "apt upgrade && apt full-upgrade" (my own habit is
> just to do "apt full-upgrade", but in this case the initial "apt
> upgrade" is crucial).  I'm now trying to more or less bisect the package
> list to find something rather more minimal; this is a slow process, but
> no roadblocks so far, and I'll let you know when I have something.
> 

Thanks a lot for your help.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
commit d67e52a7d1997a3e461b6971b00ce94a136a5b2d
Author: Aurelien Jarno 
Date:   Fri Sep 10 20:58:48 2021 +0200

first fix for #994042

diff --git a/debian/debhelper.in/libc.preinst b/debian/debhelper.in/libc.preinst
index d679db4f..e7808a44 100644
--- a/debian/debhelper.in/libc.preinst
+++ b/debian/debhelper.in/libc.preinst
@@ -21,23 +21,22 @@ kfreebsd_compare_versions () {
 
 if [ "$type" != abort-upgrade -a -z "$DPKG_ROOT" ]
 then
-# Load debconf module if available and usable
+# Check if the debconf module is available and usable
 if [ -f /usr/share/debconf/confmodule ]; then
 # cdebconf has a working fallback mechanism in case dialog
 # is not usable, so do not try to do anything smart here
 if [ "$DEBCONF_USE_CDEBCONF" ] ; then
-. /usr/share/debconf/confmodule
 USE_DEBCONF=1
 # debconf requires perl
 elif perl -e "" 2>/dev/null ; then
-. /usr/share/debconf/confmodule
 # Check that the selected frontend will work
 if [ -n "$DEBIAN_FRONTEND" ] ; then
 frontend="$DEBIAN_FRONTEND"
 else
-   

Bug#989600: /usr/bin/swift-container-reconciler: reconciler's memcache connections fail when using hostnames

[Thomas Goirand]

On 9/10/21 11:40 AM, Filippo Giunchedi wrote:
> On Thu, Sep 09, 2021 at 09:32:34AM +0200, Thomas Goirand wrote:
>> Hi,
>>
>> Thanks a lot for working on this, it really is helpful.
>>
>> The pull request you're pointing at contains multiple commits. Would you
>> be able to transform this into a patch against the Eventlet versions
>> 0.26.1 (currently in Stable) and 0.30.2 (in Unstable and Testing)? If
>> you provide it, then I'll be very happy to add the patches to these
>> Debian packages. If I'm asking it's not because I don't want to do it
>> myself, but because you wrote it, you may be better at understanding how
>> to backport the patches.
> 
> Certainly, I did port the patch to our internal repo for Bullseye. You can 
> find
> the commit below, which modulo the changelog version obviously should work 
> as-is.
> 
> https://github.com/wikimedia/operations-debs-python-eventlet/commit/a93d2e0cd2cdf3efcd7915cb781355d58e5728ab
> 
> I didn't change 
> 'Replace-dnspython-_compute_expiration-by-_compute_times.patch'
> for a cleaner diff, although that patch a whole I think can be replaced with
> the PR's diff. What do you think?
> 
> best,
> Filippo
> 

Hi,

I'll try to get this in Bullseye proper. Thanks a lot for your work,
this is definitively very helpful, and may solve troubles with swift's
cname middleware also.

I'm not sure about
Replace-dnspython-_compute_expiration-by-_compute_times.patch, though
it's probably better, from the Debian Stable perspective, to not touch
the patches that are already there, so it is easier for the Stable
release team to review it.

I will also need a patch against the version 0.30.2-2 currently in
unstable/bookworms (again: otherwise the Debian Stable release team may
complain about it). Could you provide one?

Cheers,

Thomas Goirand (zigo)

Bug#994064: bullseye-pu: package python-eventlet/0.26.1-7

[Thomas Goirand]

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

Dear release team,

[ Reason ]
Eventlet 0.26.1 was unforunately incompatible with DNSPython 2.x
which is in Bullseye as well. This makes a few OpenStack components
fails, for example the cname middleware of Swift, and everything
that's using the greendns API of Eventlet.

Recently, Filippo Giunchedi from Wikimedia Foundation managed to
fix the situation with this patch:

https://github.com/eventlet/eventlet/pull/722

He nicely backported it to Eventlet 0.26.1 and provided me with
a patch that they use in production.

[ Impact ]
Failing cname swift middleware, as well as everything that's
using Eventlet's greendns.

[ Tests ]
Wikimedia foundation is using this in production.
There's also the unit tests at build time from the Eventlet package.

[ Risks ]
Hopefully, this wont break anything... :)

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

Cheers,

Thomas Goirand (zigo)
diff -Nru python-eventlet-0.26.1/debian/changelog 
python-eventlet-0.26.1/debian/changelog
--- python-eventlet-0.26.1/debian/changelog 2021-05-11 08:03:43.0 
+0200
+++ python-eventlet-0.26.1/debian/changelog 2021-09-10 21:42:12.0 
+0200
@@ -1,3 +1,12 @@
+python-eventlet (0.26.1-7+deb11u1) bullseye; urgency=medium
+
+  [ Filippo Giunchedi ]
+  * Fix dnspython 2 compat
+See also https://github.com/eventlet/eventlet/pull/722 and
+https://phabricator.wikimedia.org/T283714
+
+ -- Thomas Goirand   Fri, 10 Sep 2021 21:42:12 +0200
+
 python-eventlet (0.26.1-7) unstable; urgency=medium
 
   * CVE-2021-21419: Malicious peer may exhaust memory on Eventlet side
diff -Nru python-eventlet-0.26.1/debian/greendns.orig.py 
python-eventlet-0.26.1/debian/greendns.orig.py
--- python-eventlet-0.26.1/debian/greendns.orig.py  2021-05-11 
08:03:43.0 +0200
+++ python-eventlet-0.26.1/debian/greendns.orig.py  2021-09-10 
21:42:12.0 +0200
@@ -120,12 +120,13 @@
 return is_ipv4_addr(host) or is_ipv6_addr(host)
 
 
-def compute_expiration(query, timeout):
-# NOTE(ralonsoh): in dnspython v2.0.0, "_compute_expiration" was replaced
-# by "_compute_times".
-if hasattr(query, '_compute_expiration'):
+# NOTE(ralonsoh): in dnspython v2.0.0, "_compute_expiration" was replaced
+# by "_compute_times".
+if hasattr(dns.query, '_compute_expiration'):
+def compute_expiration(query, timeout):
 return query._compute_expiration(timeout)
-else:
+else:
+def compute_expiration(query, timeout):
 return query._compute_times(timeout)[1]
 
 
@@ -669,8 +670,21 @@
 raise dns.exception.Timeout
 
 
+# Test if raise_on_truncation is an argument we should handle.
+# It was newly added in dnspython 2.0
+try:
+dns.message.from_wire("", raise_on_truncation=True)
+except dns.message.ShortHeader:
+_handle_raise_on_truncation = True
+except TypeError:
+# Argument error, there is no argument "raise_on_truncation"
+_handle_raise_on_truncation = False
+
+
 def udp(q, where, timeout=DNS_QUERY_TIMEOUT, port=53,
-af=None, source=None, source_port=0, ignore_unexpected=False):
+af=None, source=None, source_port=0, ignore_unexpected=False,
+one_rr_per_rrset=False, ignore_trailing=False,
+raise_on_truncation=False, sock=None):
 """coro friendly replacement for dns.query.udp
 Return the response obtained after sending a query via UDP.
 
@@ -695,7 +709,21 @@
 @type source_port: int
 @param ignore_unexpected: If True, ignore responses from unexpected
 sources.  The default is False.
-@type ignore_unexpected: bool"""
+@type ignore_unexpected: bool
+@param one_rr_per_rrset: If True, put each RR into its own
+RRset.
+@type one_rr_per_rrset: bool
+@param ignore_trailing: If True, ignore trailing
+junk at end of the received message.
+@type ignore_trailing: bool
+@param raise_on_truncation: If True, raise an exception if
+the TC bit is set.
+@type raise_on_truncation: bool
+@param sock: the socket to use for the
+query.  If None, the default, a socket is created.  Note that
+if a socket is provided, it must be a nonblocking datagram socket,
+and the source and source_port are ignored.
+@type sock: socket.socket | None"""
 
 wire = q.to_wire()
 if af is None:
@@ -717,7 +745,10 @@
 if source is not None:
 source = (source, source_port, 0, 0)
 
-s = socket.socket(af, socket.SOCK_DGRAM)
+if sock:
+s = sock
+else:
+s = socket.socket(af, socket.SOCK_DGRAM)
 s.settimeout(timeout)
 try:
 expiration = compute_expiration(dns.query, timeout)
@@ -765,14 +796,23 @@
 finally:
 s.close()
 
-r = 

Bug#994063: src:ensmallen: fails to migrate to testing for too long: autopkgtest failure

[Paul Gevers]

Source: ensmallen
Version: 2.16.2-2
Severity: serious
Control: close -1 2.17.0-2
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 993043

Dear maintainer(s),

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

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

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

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

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

Paul

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




OpenPGP_signature
Description: OpenPGP digital signature

Bug#990406: groff SIGABRTs after negative .ta request

[G. Branden Robinson]

retitle 990406 groff: ".ta T -5" causes troff assertion failure
tag 990406 + upstream
thanks

What's going on is much clearer if groff Git HEAD, thanks to its
improved `assert()` implementation.

$ printf '.ta T -5\n\t' | tg
troff: ../src/roff/troff/env.cpp:2620: distance_to_next_tab(): assertion 
failed: 'lastpos > 0'
.../groff/build/groff: error: troff: Aborted (core dumped)

I'll have a look at this.

Regards,
Branden


signature.asc
Description: PGP signature

Bug#994042: libc6: debconf text fallback failed to accept input, had to be killed leading to broken dist-upgrade

[Colin Watson]

On Fri, Sep 10, 2021 at 09:03:32PM +0200, Aurelien Jarno wrote:
> On 2021-09-10 16:51, Colin Watson wrote:
> > The only way to fix what libc.preinst is currently trying to do would
> > be:
> > 
> >  * Fetch the current debconf frontend *without* first sourcing the
> >confmodule, e.g. using something like "echo GET debconf/frontend |
> >debconf-communicate" which I *think* is safe as long as you haven't
> >sourced the confmodule yet;
> > 
> >  * Decide whether to use debconf based on this and other information;
> > 
> >  * Only source the confmodule if you've positively decided to use it.
> 
> debconf-communicate might be safe, but its manpage explicitly says it
> should not be used in maintainer scripts.

Strictly, it says "a maintainer script of a package that uses debconf".
I think what that really means is that it shouldn't be used after
sourcing the debconf confmodule (which is normally the same as using
debconf since nearly everything sources it right at the top - but this
is a weird edge case).  The point is to avoid having multiple processes
with the debconf database open at the same time.

Put another way, for this purpose, libc6.preinst isn't really a
maintainer script that uses debconf until it sources the confmodule.

> I gave a try with debconf-show instead. I have attached a totally
> untested patch to check that we agree on the way to do it.

I think you forgot to attach the patch?

I wouldn't completely veto using debconf-show in this very specialized
situation, as long as it came with a substantial comment explaining
what's going on so that nobody else is tempted to copy it.  However, the
output format of debconf-show isn't guaranteed, so I'm not very happy
about it being used mechanically like this.  I'd prefer
debconf-communicate if we can ensure that it works in this context,
notwithstanding its documentation.

> > But a simpler approach might be to update debconf in buster with the
> > change from 1.5.76 to check whether whiptail/dialog is usable before
> > trying to use it, and then remove at least some of this fragile and
> > broken code from libc.preinst.  At the very least, USE_DEBCONF=1 must
> > always be set if (and only if) the debconf confmodule has been sourced.
> 
> While it is probably a good idea to backport that change in buster to
> limit to reduce the risk, we don't require people to upgrade to the
> latest buster release before starting an upgrade.
> 
> On the other hand, given that bullseye has a fixed debconf, I fully
> agree that we should drop that fragile code for bookworm.

We probably agree on both points here.

> > I'm currently seeing if I can construct a reduced reproduction recipe
> > based on Neil's logs, since it evidently depends on exactly which order
> > apt chooses to unpack things early on, and it would be very helpful to
> > be able to test fixes properly.
> 
> Thanks, tell me if you need help on that.

I managed to reproduce the reported bug by taking Neil's full package
list, mangling it to roughly make sense on buster, installing all of
that, and then doing "apt upgrade && apt full-upgrade" (my own habit is
just to do "apt full-upgrade", but in this case the initial "apt
upgrade" is crucial).  I'm now trying to more or less bisect the package
list to find something rather more minimal; this is a slow process, but
no roadblocks so far, and I'll let you know when I have something.

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

Bug#994059: wordpress: CVE-2021-39201

[Salvatore Bonaccorso]

Source: wordpress
Version: 5.7.1+dfsg1-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 5.0.12+dfsg1-0+deb10u1

Hi,

The following vulnerability was published for wordpress.

CVE-2021-39201[0]:
| WordPress is a free and open-source content management system written
| in PHP and paired with a MySQL or MariaDB database. ### Impact The
| issue allows an authenticated but low-privileged user (like
| contributor/author) to execute XSS in the editor. This bypasses the
| restrictions imposed on users who do not have the permission to post
| `unfiltered_html`. ### Patches This has been patched in WordPress 5.8,
| and will be pushed to older versions via minor releases (automatic
| updates). It's strongly recommended that you keep auto-updates enabled
| to receive the fix. ### References
| https://wordpress.org/news/category/releases/
| https://hackerone.com/reports/1142140 ### For more information If you
| have any questions or comments about this advisory: * Open an issue in
| [HackerOne](https://hackerone.com/wordpress)


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-39201
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-39201
[1] 
https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-wh69-25hr-h94v

Regards,
Salvatore

Bug#994061: libvirt: new upstream version available

[Salvatore Bonaccorso]

Source: libvirt
Version: 7.6.0-1
Severity: wishlist
X-Debbugs-Cc: car...@debian.org

Hi

When feasible, there is a new upstream version 7.7.0 available. Would
it be possible to push it to unstable?

Regards,
Salvatore

Bug#994060: wordpress: CVE-2021-39200

[Salvatore Bonaccorso]

Source: wordpress
Version: 5.7.1+dfsg1-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for wordpress.

CVE-2021-39200[0]:
| WordPress is a free and open-source content management system written
| in PHP and paired with a MySQL or MariaDB database. In affected
| versions output data of the function wp_die() can be leaked under
| certain conditions, which can include data like nonces. It can then be
| used to perform actions on your behalf. This has been patched in
| WordPress 5.8.1, along with any older affected versions via minor
| releases. It's strongly recommended that you keep auto-updates enabled
| to receive the fix.


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-39200
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-39200
[1] 
https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-m9hc-7v5q-x8q5

Regards,
Salvatore

Bug#994050: linux-image-5.10.0-8-amd64: Hauppauge WinTV-HVR1110 DVB-T/Hybrid bug 125 ms polling on ir-kbd-i2c.ko bad DEFAULT_POLLING_INTERVAL

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo upstream

Hi

On Fri, Sep 10, 2021 at 07:18:07PM +0200, Joaquín Alberto Calderón wrote:
> Package: src:linux
> Version: 5.10.46-4
> Severity: important
> Tags: patch
> X-Debbugs-Cc: kini_calde...@hotmail.com
> 
> Although I have a very old pci (not express) Hauppauge WinTV-HVR1110
> DVB-T/Hybrid TV card with a remote control, I am still using it because has
> fully support and functionallity and it's hardware capable of play DVB-T HD
> streams.
> 
> It has a very strange behaviour:
> 
> -One is it has a slow response when I push a key, has a delay, and sometimes
> even no key response, nothing happens, as if never push a key.
> -Other is when you hold a key, it start to begin the repeat key (characters
> like numerical) appears in the test app (kwrite) then, has a pause, stops to
> write characters, and begin the sequence again, writes some sequence, then
> stops... and so on. Even I noticed the repeat speed is a bit slow, compared to
> a keyboard key hold on.
> 
> So... I began to investigates the causes and after two weeks of research,
> searchs on the web, I found the module affected and a solution.
> 
> The module affected is ir-kbd-i2c.ko, this remote (rc5 protocol) uses this
> module as uinput (devinput) device, in resume as like an attatched keyboard.
> Resulting investigation in get noticed that this remote with rc5 protocol has
> 8hz of time frame when receiving the air gap code (rc5 procotol timing).
> 
> Investigating the sources files in the kernel sources for try and fall, re-
> compiling the modules, get me to get noticed that the polling ir remote
> interval is 100ms which is 5hz, forcing this value to 125ms, re-compiling the
> module causes the remote to work normally as expecte, the response is like a
> real keyboard and the repeat sequence not only as speedy as a normal keyboard,
> but also hasn't got a pause in repetition. In resume, the problem is solved.
> 
> Here is the patch:
> 
> --- ir-kbd-i2c.original.c   2021-09-08 23:45:23.723210301 +0200
> +++ ir-kbd-i2c.hauppauge.patched.c  2021-09-10 03:55:28.003529072 +0200
> @@ -742,7 +742,7 @@
> return -ENOMEM;
> 
> ir->c = client;
> -   ir->polling_interval = DEFAULT_POLLING_INTERVAL;
> +   ir->polling_interval = 125;
> i2c_set_clientdata(client, ir);
> 
> switch(addr) {
> 
> I am a experienced user, but not an experienced developer, also in
> editing/submitting bugs, I don't know if this is the right way to solve this,
> If the rest of brand remotes are affected for my solution, but for me, solved
> my problem in this particular case.
> 
> I don't know where the value DEFAULT_POLLING_INTERVAL is get stablished or a
> way when detect a Hauppauge WinTV-HVR1110 DVB-T/Hybrid TV card to stablish
> 125ms instead of 100ms. As I said, I'm not an expert but experienced user.
> 
> I don't know if this is the right package to post this bug. Thanks.

Thanks for the report!

This is IMHO not something which should handled with an entry point in
downstream in Debian, but rather going to report it upstream directly.
Can you do that?

Details on reporting: 
https://www.kernel.org/doc/html/latest/admin-guide/bug-hunting.html

Best guess for reporting the issue you are seeing:

$ ./scripts/get_maintainer.pl ./drivers/media/i2c/ir-kbd-i2c.c
Mauro Carvalho Chehab  (maintainer:MEDIA INPUT 
INFRASTRUCTURE (V4L/DVB),commit_signer:1/1=100%)
Sean Young  (commit_signer:1/1=100%)
Christophe JAILLET  
(commit_signer:1/1=100%,authored:1/1=100%,added_lines:2/2=100%,removed_lines:2/2=100%)
linux-me...@vger.kernel.org (open list:MEDIA INPUT INFRASTRUCTURE (V4L/DVB))
linux-ker...@vger.kernel.org (open list)

Feel free to keep this bugreport downstream into the loop.

Regards,
Salvatore

Bug#994042: libc6: debconf text fallback failed to accept input, had to be killed leading to broken dist-upgrade

[Aurelien Jarno]

Hi Colin,

On 2021-09-10 16:51, Colin Watson wrote:
> On Fri, Sep 10, 2021 at 04:02:06PM +0100, Neil Williams wrote:
> > This is related to #984533 - in my case, there was no effect on the 
> > initramfs.
> > 
> > I am attaching the section of the apt log. (gzipped)
> > I am also attaching the dpkg -l output for the package list (after upgrade).
> > 
> > The apt log includes the details of the --purge autoremove operation I 
> > completed
> > after a reboot, so those packages were also installed on buster too.
> > 
> > This was an upgrade from buster to bullseye.
> > apt upgrade worked fine (first part of the log).
> > 
> > When dist-upgrade started, I got:
> > 
> > Preparing to unpack .../92-libc6_2.31-13_amd64.deb ...
> > debconf: unable to initialize frontend: Dialog
> > debconf: (No usable dialog-like program is installed, so the dialog based 
> > frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm 
> > line 78.)
> > debconf: falling back to frontend: Readline
> > Checking for services that may need to be restarted...
> > Checking init scripts...
> > Do you want to upgrade glibc now?
> > 
> > Running services and programs that are using NSS need to be restarted,
> > otherwise they might not be able to do lookup or authentication any more.
> > The installation process is able to restart some services (such as ssh or
> > telnetd), but other programs cannot be restarted automatically.  One such
> > program that needs manual stopping and restart after the glibc upgrade by
> > yourself is xdm - because automatic restart might disconnect your active
> > X11 sessions.
> > 
> > This script detected the following installed services which must be
> > stopped before the upgrade: postgresql 
> > 
> > If you want to interrupt the upgrade now and continue later, please
> > answer No to the question below.
> > 
> > Do you want to upgrade glibc now? [Y/n] y
> > Y
> 
> The code in libc.preinst that attempts to fall back to text mode,
> introduced in 2.31-10, is clearly incorrect; apologies for not noticing
> this earlier.  It sources the debconf confmodule and then conditionally
> sets USE_DEBCONF; but since the debconf confmodule has already been
> sourced by this point, text mode won't work properly since standard
> input and output refer to the debconf frontend.  (In particular, reading
> from stdin can't work.)

Thanks for the fast analysis, and apologies for introducing that bug.

> The only way to fix what libc.preinst is currently trying to do would
> be:
> 
>  * Fetch the current debconf frontend *without* first sourcing the
>confmodule, e.g. using something like "echo GET debconf/frontend |
>debconf-communicate" which I *think* is safe as long as you haven't
>sourced the confmodule yet;
> 
>  * Decide whether to use debconf based on this and other information;
> 
>  * Only source the confmodule if you've positively decided to use it.

debconf-communicate might be safe, but its manpage explicitly says it
should not be used in maintainer scripts. I gave a try with debconf-show
instead. I have attached a totally untested patch to check that we
agree on the way to do it.

> But a simpler approach might be to update debconf in buster with the
> change from 1.5.76 to check whether whiptail/dialog is usable before
> trying to use it, and then remove at least some of this fragile and
> broken code from libc.preinst.  At the very least, USE_DEBCONF=1 must
> always be set if (and only if) the debconf confmodule has been sourced.

While it is probably a good idea to backport that change in buster to
limit to reduce the risk, we don't require people to upgrade to the
latest buster release before starting an upgrade.

On the other hand, given that bullseye has a fixed debconf, I fully
agree that we should drop that fragile code for bookworm.

> I'm currently seeing if I can construct a reduced reproduction recipe
> based on Neil's logs, since it evidently depends on exactly which order
> apt chooses to unpack things early on, and it would be very helpful to
> be able to test fixes properly.

Thanks, tell me if you need help on that.

Regards,
Aurelien

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

Bug#946200: neomutt: decrypting email with gpg+pinentry-tty is broken

[Stefan]

I'm running NeoMutt 20201127 (bullseye). I'm using a Nitrokey and
switched via 

update-alternatives --config pinentry

to pinentry-tty.

I have the same issues, when I try to decrypt a message. But, signing
a message is working. When it's working, the screen shows the shell.
When it's not working, I can see a part of neomutt.

-- 
Stefan

Bug#994058: ITP: flict -- flict verifies license compatibility between software and software dependencies

[Jeremiah C. Foster]

Package: wnpp
Severity: wishlist
Owner: "Jeremiah C. Foster" 

* Package name: flict
  Version : v0.1.1
  Upstream Author : Henrik Sandklef h...@sandklef.com
* URL : https://github.com/vinland-technology/flict
* License : GPLv3
  Programming Lang: Python
  Description : flict verifies license compatibility between 
software and software dependencies


FOSS License Compatibility Tool (flict) is a Free and Open Source
Software tool to verify license compatibility for a package and its
dependencies. You can use the tool to automate license compatibility
verification in your compliance work flow.

flict can:
  - verify licenses compatibility for license expression and a packages 
and its dependencies

  - suggest candidate outbound licenses
  - simplify license expressions
  - display, in misc format, compatibility between licenses
  - check outbound licenses against a policy (policy as supplied by the 
user)

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

[Sylvain Tgz]

Package: libegl-mesa0
Version: 21.2.1-2
Severity: serious
Justification: unknow
X-Debbugs-Cc: tarjaiz...@gmail.com

Dear Maintainer,

After upgraded libegl-mesa0 libgbm1 libgl1-mesa-dri libglapi-mesa libglx-mesa0 
libllvm11 to 21.2.1-2, I have artifacts with firefox-esr. For example, with 
right click on a tab, I can see artifact. 
For the moment, I have not seen any problem with other software.

If I downgrade to 20.3.5-1, the problem is no longer present.

I use Intel graphic card (UHD Graphics 630), lightdm and i3.
On another system, nvidia card is used, 21.2.1-2 has no problems. (lightdm and 
i3 are also used)

I think it is related to mesa but I am not sure.
Am I the only one in this case?

Thanks

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation CoffeeLake-H GT2 
[UHD Graphics 630] [8086:3e9b] (rev 02)

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 0

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 5.10.0-8-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.46-4 (2021-08-03)

DRM Information from dmesg:
---


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

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

Versions of packages libegl-mesa0 depends on:
ii  libc6   2.32-2
ii  libdrm2 2.4.107-2
ii  libexpat1   2.4.1-2
ii  libgbm1 21.2.1-2
ii  libgcc-s1   11.2.0-5
ii  libglapi-mesa   21.2.1-2
ii  libwayland-client0  1.19.0-2
ii  libwayland-server0  1.19.0-2
ii  libx11-xcb1 2:1.7.2-1
ii  libxcb-dri2-0   1.14-3
ii  libxcb-dri3-0   1.14-3
ii  libxcb-present0 1.14-3
ii  libxcb-sync11.14-3
ii  libxcb-xfixes0  1.14-3
ii  libxcb1 1.14-3
ii  libxshmfence1   1.3-1

libegl-mesa0 recommends no packages.

libegl-mesa0 suggests no packages.

Versions of packages xserver-xorg depends on:
ii  x11-xkb-utils   7.7+5
ii  xkb-data2.33-1
ii  xorgxrdp [xorg-driver-video]1:0.2.15-1
ii  xserver-xorg-core   2:1.20.11-1
ii  xserver-xorg-input-all  1:7.7+23
ii  xserver-xorg-input-libinput [xorg-driver-input  1.1.0-1
ii  xserver-xorg-input-wacom [xorg-driver-input]0.34.99.1-1+b1
ii  xserver-xorg-video-all  1:7.7+23
ii  xserver-xorg-video-amdgpu [xorg-driver-video]   19.1.0-2
ii  xserver-xorg-video-ati [xorg-driver-video]  1:19.1.0-2
ii  xserver-xorg-video-fbdev [xorg-driver-video]1:0.5.0-1
ii  xserver-xorg-video-intel [xorg-driver-video]2:2.99.917+git20200714-1+b1
ii  xserver-xorg-video-nouveau [xorg-driver-video]  1:1.0.17-1
ii  xserver-xorg-video-qxl [xorg-driver-video]  0.1.5+git20200331-1
ii  xserver-xorg-video-radeon [xorg-driver-video]   1:19.1.0-2
ii  xserver-xorg-video-vesa [xorg-driver-video] 1:2.5.0-1
ii  xserver-xorg-video-vmware [xorg-driver-video]   1:13.3.0-3

Versions of packages xserver-xorg recommends:
ii  libgl1-mesa-dri  21.2.1-2
ii  xserver-xorg-legacy  2:1.20.11-1

Versions of packages xserver-xorg-core depends on:
ii  keyboard-configuration  1.205
ii  libaudit1   1:3.0.5-1
ii  libbsd0 0.11.3-1
ii  libc6   2.32-2
ii  libdbus-1-3 1.12.20-2
ii  libdrm2 2.4.107-2
ii  libegl1 1.3.4-1
ii  libepoxy0   1.5.8-1
ii  libgbm1 21.2.1-2
ii  libgcrypt20 1.9.4-2
ii  libgl1  1.3.4-1
ii  libpciaccess0   0.16-1
ii  libpixman-1-0   0.40.0-1
ii  libselinux1 3.1-3
ii  libsystemd0 247.9-1
ii  libudev1247.9-1
ii  libunwind8  1.3.2-2
ii  libxau6 1:1.0.9-1
ii  libxdmcp6   1:1.1.2-3
ii  libxfont2   1:2.0.4-1
ii  libxshmfence1   1.3-1
ii  udev247.9-1
ii  xserver-common  2:1.20.11-1

Versions of packages xserver-xorg-core recommends:
ii  libgl1-mesa-dri  21.2.1-2
ii  libpam-systemd [logind]  247.9-1

Versions of packages xserver-xorg-core suggests:
ii  xfonts-100dpi1:1.0.4+nmu1.1
ii  xfonts-75dpi 1:1.0.4+nmu1.1
ii  xfonts-scalable  1:1.0.3-1.2

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

[Danny van Heumen]

Actually, what I said below is meaningless. The fact is, that precedence was 
chosen by design. The fix we're talking about here merely ensures consistent 
behavior under all circumstances. (Correcting mainly because I'm annoyed by my 
own inaccurate response.)

‐‐‐ Original Message ‐‐‐

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

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

Bug#242510: screen: spins when pasting

[Ivan Shmakov]

Control: found -1 4.6.2-3+deb10u1
Control: found -1 4.8.0-6

> On 2004-04-06 22:31:43 -0400, Allan Wind wrote:

 > Package: screen
 > Version: 4.0.2-3
 > Severity: normal

 > I have been seeing an issue for a while, where screen appears to be
 > going into a busy loop when pasting data into vim.  Not exactly sure
 > how to reproduce this, but something along these lines seem to always
 > work when the data is important (but I cannot reproduce it consistently):

[…]

 > When it works, it takes ~3 sec paste the 10k lines on my box, and when
 > you hit the issue I never seen it terminate.

I was able to reproduce it with both 4.6.2-3+deb10u1 and 4.8.0-6;
it seems, however, that an important part is to signal Screen
while it sends the data down to the application; such as with:

1. $ seq 1 0x10 | fmt -w78 > /tmp/screen-exchange .

2. $ screen ; then load the file with C-a < .

3. $ vim.tiny ; start pasting the data there with C-a ] .

4. Press ^C while Screen is still sending the data.

5. Screen appears to enter an infinite loop: 100% CPU
   utilization, no syscalls seen via strace(1), etc.

Given that this bug effectively results in the loss of a given
Screen session, possibly with all the (‘unsaved’) data therein,
I believe it deserves a higher Severity: .

(Could #524304 be possibly related?)

As a workaround, some applications may be salvaged with
reptyr(1); like:

1. Find out the PID of the ‘broken’ session:

$ pgrep --full -u"$(id -u)" -- ^SCREEN\\b 
1234
$ 

   (It’s possible to $ kill -STOP the process here so that it no
longer consumes CPU cycles.)

2. Find out the PIDs of the programs running under:

$ pstree -Apl -- 1234 
screen(1234)-+-vim(2468)
 `-lynx(5678)

3. Move said programs to another Screen session:

$ screen -t vim 10 reptyr -V -- 2468 
$ screen -t lynx 11 reptyr -V -- 5678 

4. Once all the programs are recovered, terminate their original
   Screen instance:

$ kill -- 1234 

   (If the process was stopped before, as suggested above, also
resume it with $ kill -CONT , so it can process the signal
sent and terminate.)

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#994056: cryptsetup: blkid check fails to take offset option into account

[Thorsten Glaser]

Package: cryptsetup
Version: 2:2.3.5-1
Severity: important
X-Debbugs-Cc: t...@mirbsd.de

In order to use a cryptsetup swap with a very tiny protective ext2fs
filesystem so we can use LABEL= as source device, I use offset= as
shown in the Arch Linux wiki.

However it fails in Debian:

tglase@tglase-nb:~ $ sudo cryptdisks_start cswap
Starting crypto disk...cswap (starting)...cswap: the precheck for '/dev/sda2' 
failed: - The device /dev/sda2 contains a filesystem type ext2. ... (warning).
failed.

The cause is missing option processing for offset there, with a
very simple fix. I have attached a “git diff” against the git tag
corresponding to the version in bullseye right now; it applies to
the following files “in situ”, in patch order (so people can fix
their local systems, even if this is not applied):

• /lib/cryptsetup/checks/blkid
• /lib/cryptsetup/checks/un_blkid
• /lib/cryptsetup/cryptdisks-functions

I’m writing this all up as well at:
https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=shellsnippets/shellsnippets.git;a=blob;f=posix/swapcycle;hb=HEAD


-- Package-specific info:
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-5.10.0-8-amd64 root=/dev/sda4 ro rootdelay=5 syscall.x32=y 
vsyscall=emulate net.ifnames=0 kaslr pcie_aspm=force consoleblank=0

-- /etc/crypttab
# 
cswap   LABEL=swp_tglase-nb /dev/random 
offset=1024,discard,cipher=aes-xts-plain64,size=256,plain,swap

-- /etc/fstab
/dev/sda4  /   ext4   
relatime,errors=remount-ro,auto_da_alloc  0  1
/dev/sda1  /boot   ext4   noatime,sync,auto_da_alloc
0  2
swap   /var/cache/apt  tmpfs  nosuid,noexec,mode=0755   
0  0
/dev/mapper/cswap  swapswap   sw,discard
0  0

-- lsmod
Module  Size  Used by
apple_mfi_fastcharge20480  0
cpuid  16384  0
snd_seq_dummy  16384  0
fuse  167936  2
ctr16384  3
ccm20480  9
cpufreq_conservative16384  0
cpufreq_ondemand   16384  2
cpufreq_userspace  20480  0
cpufreq_powersave  20480  0
binfmt_misc24576  1
nft_counter16384  1
nft_chain_nat  16384  1
xt_MASQUERADE  20480  1
nf_nat 53248  2 nft_chain_nat,xt_MASQUERADE
nf_conntrack  176128  2 nf_nat,xt_MASQUERADE
nf_defrag_ipv6 24576  1 nf_conntrack
nf_defrag_ipv4 16384  1 nf_conntrack
nft_compat 20480  1
nf_tables 245760  5 nft_compat,nft_counter,nft_chain_nat
x_tables   53248  2 nft_compat,xt_MASQUERADE
libcrc32c  16384  3 nf_conntrack,nf_nat,nf_tables
nfnetlink  16384  2 nft_compat,nf_tables
tun57344  3
snd_seq_midi   20480  0
snd_seq_midi_event 16384  1 snd_seq_midi
snd_rawmidi45056  1 snd_seq_midi
snd_seq86016  3 snd_seq_midi,snd_seq_midi_event,snd_seq_dummy
snd_seq_device 16384  3 snd_seq,snd_seq_midi,snd_rawmidi
msr16384  0
ecb16384  1
aes_generic36864  8
libaes 16384  1 aes_generic
crypto_simd16384  0
cryptd 24576  1 crypto_simd
glue_helper16384  0
xts16384  1
dm_crypt   53248  1
dm_mod163840  2 dm_crypt
snd_hda_codec_analog20480  1
snd_hda_codec_generic98304  1 snd_hda_codec_analog
iwl4965   110592  0
iwlegacy   90112  1 iwl4965
ppdev  24576  0
snd_hda_intel  57344  0
snd_intel_dspcfg   28672  1 snd_hda_intel
pcmcia 77824  0
soundwire_intel45056  1 snd_intel_dspcfg
mac80211  983040  2 iwl4965,iwlegacy
coretemp   20480  0
soundwire_generic_allocation16384  1 soundwire_intel
snd_soc_core  315392  1 soundwire_intel
kvm_intel 327680  0
snd_compress   32768  1 snd_soc_core
soundwire_cadence  36864  1 soundwire_intel
snd_hda_codec 172032  3 
snd_hda_codec_generic,snd_hda_intel,snd_hda_codec_analog
snd_hda_core  110592  4 
snd_hda_codec_generic,snd_hda_intel,snd_hda_codec_analog,snd_hda_codec
snd_hwdep  16384  1 snd_hda_codec
iTCO_wdt   16384  0
kvm   917504  1 kvm_intel
intel_pmc_bxt  16384  1 iTCO_wdt
irqbypass  16384  1 kvm
soundwire_bus  90112  3 
soundwire_intel,soundwire_generic_allocation,soundwire_cadence
cfg80211  970752  3 iwl4965,iwlegacy,mac80211
iTCO_vendor_support16384  1 iTCO_wdt
serio_raw  20480  0
pcspkr 16384  0
yenta_socket   53248  0
sg 36864  0
pcmcia_rsrc24576  1 yenta_socket
snd_pcm_oss65536  0
watchdog   28672  1 iTCO_wdt
thinkpad_acpi 118784  0
snd_mixer_oss  28672  1 snd_pcm_oss

Bug#994055: cunit: FTBFS: format not a string literal and no format arguments [-Werror=format-security]

[Sven Joachim]

Source: cunit
Version: 2.1-3-dfsg-2.3
Severity: serious
Tags: ftbfs bookworm sid

Your package FTBFS with libncurses-dev 6.2+20210905-1, as several
mvwprintw() calls now trigger format warnings from gcc which
dpkg-buildflags turns into errors thanks to -Werror=format-security:

,
| Curses.c: In function 'show_suite_level_help':
| Curses.c:955:37: error: format not a string literal and no format arguments 
[-Werror=format-security]
|   955 |   mvwprintw(details_pad.pPad, 0, 0, szTemp);
|   | ^~
| Curses.c:959:37: error: format not a string literal and no format arguments 
[-Werror=format-security]
|   959 |   mvwprintw(details_pad.pPad, 2, 0, szTemp);
|   | ^~
| Curses.c: In function 'list_tests':
| Curses.c:1071:37: error: format not a string literal and no format arguments 
[-Werror=format-security]
|  1071 |   mvwprintw(details_pad.pPad, 0, 0, szTemp);
|   | ^~
| Curses.c:1078:37: error: format not a string literal and no format arguments 
[-Werror=format-security]
|  1078 |   mvwprintw(details_pad.pPad, 1, 0, szTemp);
|   | ^~
| Curses.c: In function 'curses_set_options_run':
| Curses.c:1161:39: error: format not a string literal and no format arguments 
[-Werror=format-security]
|  1161 | mvwprintw(details_pad.pPad, 2, 0, szTemp);
|   |   ^~
| cc1: some warnings being treated as errors
`

A full build log is at [1].

See #993179 for the change in ncurses which lead to these new errors.


1. https://ci.debian.net/data/autopkgtest/testing/amd64/c/cunit/15168126/log.gz

Bug#585720:

[Adamu Haruna]

Bug#993591: borgmatic: systemd unit not shipped (related to #989322)

[kaliko]

On Fri, 03 Sep 2021 15:21:58 +0200 kaliko  wrote:


Here is a patch (also on salsa
https://salsa.debian.org/debian/borgmatic/-/merge_requests/4)


Patch updated on salsa, please forget the attachment in the bug report.

Please review
Cheers



OpenPGP_signature
Description: OpenPGP digital signature

Bug#994054: [INTL:sv] Swedish strings for sympa debconf

[Martin Bagge / brother]

package: sympa
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.
--
brother
# Translation of sympa debconf template to Swedish
# Copyright (C) 2021 Martin Bagge 
# This file is distributed under the same license as the sympa package.
#
# Martin Bagge , 2010, 2021
msgid ""
msgstr ""
"Project-Id-Version: sympa\n"
"Report-Msgid-Bugs-To: sy...@packages.debian.org\n"
"POT-Creation-Date: 2020-11-28 15:04+0100\n"
"PO-Revision-Date: 2021-09-09 21:41+0200\n"
"Last-Translator: Martin Bagge \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Poedit-Language: Swedish\n"
"X-Poedit-Country: Sweden\n"

#. Type: select
#. Description
#: ../templates:1001
msgid "Default language for Sympa:"
msgstr "Ange standardspråket för Sympa:"

#. Type: string
#. Description
#: ../templates:2001
msgid "Sympa hostname:"
msgstr "Ange värdnamnet för sympa:"

#. Type: string
#. Description
#: ../templates:2001
msgid ""
"This is the name of the machine or the alias you will use to reach sympa."
msgstr ""
"Detta är namnet på maskinen eller det alias som du vill använda för att nå "
"sympa."

#. Type: string
#. Description
#. Type: string
#. Description
#: ../templates:2001 ../templates:3001
msgid "Example:"
msgstr "Exempel:"

#. Type: string
#. Description
#: ../templates:2001
msgid "  listhost.cru.fr"
msgstr "  listhost.cru.fr"

#. Type: string
#. Description
#: ../templates:2001
msgid "  Then, you will send your sympa commands to:"
msgstr "  Sedan kan du skicka dina sympa-kommandon till:"

#. Type: string
#. Description
#: ../templates:2001
msgid "  sy...@listhost.cru.fr"
msgstr "  sy...@listhost.cru.fr"

#. Type: string
#. Description
#: ../templates:3001
msgid "Listmaster email address(es):"
msgstr "Ange e-postadresserna till listmästarna:"

#. Type: string
#. Description
#: ../templates:3001
msgid ""
"Listmasters are privileged people who administrate mailing lists (mailing "
"list superusers)."
msgstr ""
"Listmästarna är privilegierade folk som administrerar sändlistor "
"(superanvändare för sändlistor)."

#. Type: string
#. Description
#: ../templates:3001
msgid "Please give listmasters email addresses separated by commas."
msgstr "Ange listmästarnas e-postadresser separerade med kommatecken."

#. Type: string
#. Description
#: ../templates:3001
msgid "  postmas...@cru.fr, r...@home.cru.fr"
msgstr "  postmas...@cru.fr, r...@home.cru.fr"

#. Type: boolean
#. Description
#: ../templates:4001
msgid "Should lists home and spool directories be removed?"
msgstr "Ska listornas hem- och kökataloger tas bort?"

#. Type: boolean
#. Description
#: ../templates:4001
msgid ""
"The lists home directory (/var/lib/sympa) contains the mailing lists "
"configurations, mailing list archives and S/MIME user certificates (when "
"sympa is configured for using S/MIME encryption and authentication). The "
"spool directory (/var/spool/sympa) contains various queue directories."
msgstr ""
"Listornas hemkatalog (/var/lib/sympa) innehåller konfigurationer för "
"sändlistor och användarnas S/MIME-certifikat (när sympa är konfigurerad till "
"att använda S/MIME-kryptering och autentisering). Kökatalogen (/var/spool/"
"sympa) innehåller olika kökataloger."

#. Type: boolean
#. Description
#: ../templates:4001
msgid ""
"Note that if those directories are empty, they will be automatically removed."
msgstr ""
"Observera att om dessa kataloger är tomma kommer de automatiskt att tas bort."

#. Type: boolean
#. Description
#: ../templates:4001
msgid ""
"Please choose whether you want to remove lists home and spool directories."
msgstr "Välj huruvida du vill ta bort listornas hem- och kökataloger."

#. Type: string
#. Description
#: ../templates:5001
msgid "URL to access WWSympa:"
msgstr "URL för att komma åt WWSympa:"

#. Type: select
#. Choices
#: ../templates:6001
msgid "Apache 2"
msgstr "Apache 2"

#. Type: select
#. Choices
#: ../templates:6001
msgid "Other"
msgstr "Annan"

#. Type: select
#. Description
#: ../templates:6002
msgid "Which Web Server(s) are you running?"
msgstr "Vilken typ av webbserver kör du?"

#. Type: boolean
#. Description
#: ../templates:7001
msgid "Do you want the sympa SOAP server to be used?"
msgstr "Vill du att sympas SOAP-server ska användas?"

#. Type: boolean
#. Description
#: ../templates:7001
msgid ""
"Sympa SOAP server allows to access a Sympa service from within another "
"program, written in any programming language and on any computer. The SOAP "
"server provides a limited set of high level functions including login, "
"which, lists, subscribe, signoff."
msgstr ""
"Sympas SOAP-server tillåter åtkomst till en Sympa-tjänst inifrån ett annat "
"program, skrivet i valfritt programmeringsspråk och på valfri dator. SOAP-"
"servern tillhandahåller en begränsad uppsättning högnivåfunktioner som "
"inkluderar login, which, lists, subscribe, signoff."

#. Type: boolean
#. Description
#: 

Bug#994053: RM: qgis [mips64el mipsel] -- ROM; FTFBS, blocks gdal transition

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal

Please remove qgis from mips64el & mipsel where it FTBFS as part of the gdal 
transition.

Kind Regards,

Bas

Bug#994051: [INTL:sv] Swedish strings for ircd-hybrid debconf

[Martin Bagge / brother]

package: ircd-hybrid
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.
--
brother
# Translation of ircd-hybrid debconf template to Swedish
# Copyright (C) 2008, 2013-2014, 2021 Martin Bagge 
# This file is distributed under the same license as the ircd-hybrid package.
#
# Martin Bagge , 2008, 2013-2014, 2021
msgid ""
msgstr ""
"Project-Id-Version: ircd-hybrid\n"
"Report-Msgid-Bugs-To: ircd-hyb...@packages.debian.org\n"
"POT-Creation-Date: 2021-02-07 15:23+\n"
"PO-Revision-Date: 2021-09-08 23:14+0200\n"
"Last-Translator: Martin Bagge / brother \n"
"Language-Team: Swedish \n"
"Language: Swedish\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 1.5.4\n"

#. Type: boolean
#. Description
#: ../ircd-hybrid.templates:2001
msgid "Restart ircd-hybrid on each upgrade?"
msgstr "Starta om ircd-hybrid efter varje uppgradering?"

#. Type: boolean
#. Description
#: ../ircd-hybrid.templates:2001
msgid ""
"Please choose whether the ircd-hybrid daemon should be restarted every time "
"a new version of this package is installed."
msgstr ""
"Ange om ircd-hybrid-tjänsten ska startas om varje gång en ny version av "
"detta paket installeras."

#. Type: boolean
#. Description
#: ../ircd-hybrid.templates:2001
msgid ""
"Automatic restarts may be problematic if, for instance, the server is "
"running with manually loaded modules, which will need to be reloaded after "
"the restart."
msgstr ""
"Automatisk omstart kan vara problematisk exempelvis om servern kör med "
"moduler som läses in manuellt då dessa måste laddas om efter en omstart."

#. Type: boolean
#. Description
#: ../ircd-hybrid.templates:2001
msgid ""
"If you reject this option, you will have to restart ircd-hybrid via "
"\"service ircd-hybrid restart\" when needed."
msgstr ""
"Om du avböjer måste du starta om ircd-hybrid manuellt via \"service ircd-"
"hybrid restart\" när det behövs."

#. Type: boolean
#. Description
#: ../ircd-hybrid.templates:3001
msgid "Automatically fix references to obsolete config options?"
msgstr "Ska referenser till utdaterade inställningar justeras automatiskt?"

#. Type: boolean
#. Description
#: ../ircd-hybrid.templates:3001
msgid ""
"Several ssl configuration variables have been renamed to tls-like ones in "
"version 8.2.30, with some further changes to rename network_desc and "
"max_watch in 8.2.36, and dots_in_ident in 8.2.38. If enabled, the post-"
"installation script will attempt to automatically fix them before the server "
"is restarted. If not, and you have these options specified, the "
"configuration will become invalid, and server restart will fail."
msgstr ""
"Ett flertal inställningar för SSL har bytt namn till TLS-liknande i version "
"8.2.30. I 8.2.36 har dessutom network_desc och max_watch bytt namn. Vidare i "
"8.2.38 har namnet för dots_in_ident bytt namn. Om detta val aktiveras kommer "
"namnbytena att korrigera i inställningarna i det avslutande "
"installationsscriptet så är inställningarna redo till nästa start. Om du "
"avböjer detta och några av dessa alternativ behöver vara korrekt satt leder "
"det till att inställningarna kommer att bli inkorrekta och servern kommer "
"inte starta."

Bug#994052: [INTL:sv] Swedish strings for horizon debconf

[Martin Bagge / brother]

package: horizon
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.

--
brother
# Translation of horizon debconf template to Swedish
# Copyright (C) 2021 Martin Bagge 
# This file is distributed under the same license as the horizon package.
#
# Martin Bagge , 2013, 2015, 2021
msgid ""
msgstr ""
"Project-Id-Version: horizon\n"
"Report-Msgid-Bugs-To: hori...@packages.debian.org\n"
"POT-Creation-Date: 2018-08-30 11:59+0200\n"
"PO-Revision-Date: 2021-09-08 23:08+0200\n"
"Last-Translator: Martin Bagge / brother \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 1.6.10\n"

#. Type: boolean
#. Description
#: ../openstack-dashboard-apache.templates:2001
msgid "Activate Dashboard and disable default VirtualHost?"
msgstr ""
"Aktivera Dashboard och avaktivera den standardiserade virtuella värden?"

#. Type: boolean
#. Description
#: ../openstack-dashboard-apache.templates:2001
msgid ""
"The Apache package sets up a default web site and a default page, configured "
"in /etc/apache2/sites-available/000-default.conf."
msgstr ""
"Apache-paketet levereras med en standard webbplats och en standard sida, "
"dessa inställningar finns i /etc/apache2/sites-available/000-default.conf."

#. Type: boolean
#. Description
#: ../openstack-dashboard-apache.templates:2001
msgid ""
"If this option is not selected, Horizon will be installed using /horizon "
"instead of the webroot."
msgstr ""
"Om detta alternativ inte används kommer Horizon att installeras på platsen /"
"horizon istället för i roten."

#. Type: boolean
#. Description
#: ../openstack-dashboard-apache.templates:2001
msgid ""
"Choose this option to replace that default with the OpenStack Dashboard "
"configuration."
msgstr ""
"Välj denna väg för att ersätta standard-Dashboard i OpenStack med Horizon."

#. Type: boolean
#. Description
#: ../openstack-dashboard-apache.templates:3001
msgid "Should the Dashboard use HTTPS?"
msgstr "Ska Dashboard använda HTTPS?"

#. Type: boolean
#. Description
#: ../openstack-dashboard-apache.templates:3001
msgid ""
"Select this option if you would like Horizon to be served over HTTPS only, "
"with a redirection to HTTPS if HTTP is in use."
msgstr ""
"Välj detta om du vill att Horizon endast ska levereras på HTTPS, en "
"omdirigering av HTTP till HTTPS kommer att aktiveras."

#. Type: string
#. Description
#: ../openstack-dashboard.templates:2001
msgid "Allowed hostname(s):"
msgstr "Tillåtna värdnamn:"

#. Type: string
#. Description
#: ../openstack-dashboard.templates:2001
msgid ""
"Please enter the list of hostnames that can be used to reach your OpenStack "
"Dashboard server. This is a security measure to prevent HTTP Host header "
"attacks, which are possible even under many seemingly-safe web server "
"configurations."
msgstr ""
"Ange de värdnamn som kan användas för att nå din OpenStack Dashboard-server. "
"Detta är en säkerhetsfiness för att motverka så kallade HTTP host header-"
"attacker. Dessa kan genomföras även på i övrigt säkra webbserver-"
"inställningar."

#. Type: string
#. Description
#: ../openstack-dashboard.templates:2001
msgid ""
"Enter values separated by commas. Any space will be removed, so you can add "
"some to make it more readable."
msgstr ""
"Separera värdena med kommatecken. Blanksteg kommer att tas bort så de kan "
"användas för att göra det mer läsbart."

#. Type: string
#. Description
#: ../openstack-dashboard.templates:2001
msgid ""
"Values in this list can be fully qualified names like \"www.example.com\", "
"in which case they will be matched against the request's Host header exactly "
"(case-insensitive, not including port). A value beginning with a period can "
"be used as a subdomain wildcard: \".example.com\" will match example.com, "
"www.example.com, and any other subdomain of example.com. A value of \"*\" "
"will match anything; in this case you are responsible for providing your own "
"validation of the Host header (perhaps in middleware; if so this middleware "
"must be listed first in MIDDLEWARE)."
msgstr ""
"Värdena i denna lista kan vara ett fullständigt kvalificerat domännamn som "
"\"www.example.com\" och då kommer exakt (dock ej skiftlägeskänsligt och "
"porten kommer inte tas med) träff i host header-fältet att krävas. Om "
"strängen börjar med en punkt tolkas detta som att alla underdomäner är "
"tillåtna - \".example.com\" kommer att stämma överens med example.com, www."
"example.com och alla andra subdomäner på example.com. Anges jokertecken \"*"
"\" kommer allt att stämma överens, i detta fall kommer du själv behöva lösa "
"kontrollen av host-header (exempelvis via middleware, då måste detta vara "
"placerat först i filen MIDDLEWARE)."

Bug#994050: linux-image-5.10.0-8-amd64: Hauppauge WinTV-HVR1110 DVB-T/Hybrid bug 125 ms polling on ir-kbd-i2c.ko bad DEFAULT_POLLING_INTERVAL

[Joaquín Alberto Calderón]

Package: src:linux
Version: 5.10.46-4
Severity: important
Tags: patch
X-Debbugs-Cc: kini_calde...@hotmail.com

Although I have a very old pci (not express) Hauppauge WinTV-HVR1110
DVB-T/Hybrid TV card with a remote control, I am still using it because has
fully support and functionallity and it's hardware capable of play DVB-T HD
streams.

It has a very strange behaviour:

-One is it has a slow response when I push a key, has a delay, and sometimes
even no key response, nothing happens, as if never push a key.
-Other is when you hold a key, it start to begin the repeat key (characters
like numerical) appears in the test app (kwrite) then, has a pause, stops to
write characters, and begin the sequence again, writes some sequence, then
stops... and so on. Even I noticed the repeat speed is a bit slow, compared to
a keyboard key hold on.

So... I began to investigates the causes and after two weeks of research,
searchs on the web, I found the module affected and a solution.

The module affected is ir-kbd-i2c.ko, this remote (rc5 protocol) uses this
module as uinput (devinput) device, in resume as like an attatched keyboard.
Resulting investigation in get noticed that this remote with rc5 protocol has
8hz of time frame when receiving the air gap code (rc5 procotol timing).

Investigating the sources files in the kernel sources for try and fall, re-
compiling the modules, get me to get noticed that the polling ir remote
interval is 100ms which is 5hz, forcing this value to 125ms, re-compiling the
module causes the remote to work normally as expecte, the response is like a
real keyboard and the repeat sequence not only as speedy as a normal keyboard,
but also hasn't got a pause in repetition. In resume, the problem is solved.

Here is the patch:

--- ir-kbd-i2c.original.c   2021-09-08 23:45:23.723210301 +0200
+++ ir-kbd-i2c.hauppauge.patched.c  2021-09-10 03:55:28.003529072 +0200
@@ -742,7 +742,7 @@
return -ENOMEM;

ir->c = client;
-   ir->polling_interval = DEFAULT_POLLING_INTERVAL;
+   ir->polling_interval = 125;
i2c_set_clientdata(client, ir);

switch(addr) {

I am a experienced user, but not an experienced developer, also in
editing/submitting bugs, I don't know if this is the right way to solve this,
If the rest of brand remotes are affected for my solution, but for me, solved
my problem in this particular case.

I don't know where the value DEFAULT_POLLING_INTERVAL is get stablished or a
way when detect a Hauppauge WinTV-HVR1110 DVB-T/Hybrid TV card to stablish
125ms instead of 100ms. As I said, I'm not an expert but experienced user.

I don't know if this is the right package to post this bug. Thanks.


-- Package-specific info:
** Version:
Linux version 5.10.0-8-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.46-4 (2021-08-03)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-8-amd64 
root=UUID=0aa74469-7d27-4605-b6a8-9331ba5f3c26 ro quiet

** Tainted: OE (12288)
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[   15.205051] saa7134: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00
[   15.205052] saa7134: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00
[   15.205091] tveeprom: Hauppauge model 67019, rev B4B4, serial# 4030267784
[   15.205093] tveeprom: MAC address is 00:0d:fe:39:01:88
[   15.205094] tveeprom: tuner model is Philips 8275A (idx 114, type 4)
[   15.205096] tveeprom: TV standards PAL(B/G) NTSC(M) PAL(I) SECAM(L/L') 
PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xfc)
[   15.205097] tveeprom: audio processor is SAA7131 (idx 41)
[   15.205098] tveeprom: decoder processor is SAA7131 (idx 35)
[   15.205099] tveeprom: has radio, has IR receiver, has IR transmitter
[   15.205100] saa7134: saa7133[0]: hauppauge eeprom: model=67019
[   15.237132] intel_powerclamp: No package C-state available
[   15.305460] intel_powerclamp: No package C-state available
[   15.408789] tuner: 8-004b: Tuner -1 found with type(s) Radio TV.
[   15.524772] tda829x 8-004b: setting tuner address to 61
[   15.659862] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC1200: 
line_outs=4 (0x14/0x15/0x16/0x17/0x0) type:line
[   15.659867] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[   15.659870] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1 
(0x1b/0x0/0x0/0x0/0x0)
[   15.659871] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0
[   15.659873] snd_hda_codec_realtek hdaudioC0D0:dig-out=0x11/0x1e
[   15.659875] snd_hda_codec_realtek hdaudioC0D0:inputs:
[   15.659877] snd_hda_codec_realtek hdaudioC0D0:  Front Mic=0x19
[   15.659880] snd_hda_codec_realtek hdaudioC0D0:  Rear Mic=0x18
[   15.659882] snd_hda_codec_realtek hdaudioC0D0:  Line=0x1a
[   15.700783] tda829x 8-004b: type set to tda8290+75a
[   15.728552] input: HDA Digital PCBeep as 

Bug#994036: xkb-data: gives lots of internal errors with xkbcomp on XF86* keysyms

[Vincent Lefevre]

Control: tags -1 upstream
Control: forwarded -1 
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/282

This is apparently an upstream bug (which I have just reported),
introduced in 2.33, as some commit added these unknown keysyms.

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

Bug#993396: bullseye-pu: package flatpak/1.10.3-0+deb11u1

[Simon McVittie]

On Tue, 31 Aug 2021 at 20:10:17 +0100, Simon McVittie wrote:
>   [x] attach debdiff against the package in (old)stable
>   - It's a filtered git diff rather than a debdiff, but I upload with
> dgit, so what's in git has to match what's uploaded. I did a diff
> between patched trees, because the majority of the upstream code
> changes were previously in debian/patches.

Sorry, I was sure I'd attached the diff but it must have got lost. See
attached.

smcv
git diff patch-queue/debian/bullseye-r0..patch-queue/debian/bullseye |
filterdiff -p1 -xMakefile.in -xaclocal.m4 -xcompile -xconfig.guess \
 -xconfig.sub -xconfig.h.in -xconfigure -xdepcomp -x'*/Makefile.in' \
 -xinstall-sh -xltmain.sh -xm4/libtool.m4 -xmissing -x'po/*.pot' \
 -x'debian/patches/*.patch' -x'doc/reference/html/*' -x'po/*.po' \
 -xtest-driver

diff --git a/NEWS b/NEWS
index 06f6a2603..1a791f4a1 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,22 @@
+Changes in 1.10.3
+~
+Released: 2021-08-31
+
+This is a maintenance update with various bug fixes backported from 1.11.x.
+
+* Don't inherit an unusual $XDG_RUNTIME_DIR setting into the sandbox, fixing
+  a regression introduced when CVE-2021-21261 was fixed in 1.8.5 and 1.10.0
+* Fix various memory and file descriptor leaks, in particular with
+  flatpak-spawn --env=...
+* Fix fd confusion in flatpak-spawn --env=... --forward-fd=..., resolving a
+  regression introduced in 1.8.5 and 1.10.0
+* Fix deploys of local remotes in system-helper, possibly involving newer
+  GLib versions
+* Fix test failures on non-x86_64 systems
+* create-usb: Skip copying extra-data flatpaks
+* Improve test coverage on Debian derivatives by ensuring /sbin is in
+  tests' PATH
+
 Changes in 1.10.2
 ~
 Released: 2021-03-10
diff --git a/common/flatpak-run.c b/common/flatpak-run.c
index f48f402a9..81ead1e60 100644
--- a/common/flatpak-run.c
+++ b/common/flatpak-run.c
@@ -1525,6 +1525,10 @@ static const ExportData default_exports[] = {
   {"XDG_DATA_DIRS", "/app/share:/usr/share"},
   {"SHELL", "/bin/sh"},
   {"TMPDIR", NULL}, /* Unset TMPDIR as it may not exist in the sandbox */
+  /* We always use /run/user/UID, even if the user's XDG_RUNTIME_DIR
+   * outside the sandbox is somewhere else. Don't allow a different
+   * setting from outside the sandbox to overwrite this. */
+  {"XDG_RUNTIME_DIR", NULL},
 
   /* Some env vars are common enough and will affect the sandbox badly
  if set on the host. We clear these always. */
diff --git a/common/flatpak-version-macros.h b/common/flatpak-version-macros.h
index 2971afee0..210faa4c9 100644
--- a/common/flatpak-version-macros.h
+++ b/common/flatpak-version-macros.h
@@ -45,7 +45,7 @@
  *
  * The micro version.
  */
-#define FLATPAK_MICRO_VERSION (2)
+#define FLATPAK_MICRO_VERSION (3)
 
 /**
  * FLATPAK_CHECK_VERSION:
diff --git a/configure.ac b/configure.ac
index c879e472d..ad5d17d77 100644
--- a/configure.ac
+++ b/configure.ac
@@ -15,7 +15,7 @@ AC_PREREQ([2.63])
 
 m4_define([flatpak_major_version], [1])
 m4_define([flatpak_minor_version], [10])
-m4_define([flatpak_micro_version], [2])
+m4_define([flatpak_micro_version], [3])
 m4_define([flatpak_extra_version], [])
 m4_define([flatpak_interface_age], [0])
 m4_define([flatpak_binary_age],
diff --git a/debian/changelog b/debian/changelog
index 061ced8f9..8fc2067e1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,16 @@
+flatpak (1.10.3-1) UNRELEASED; urgency=medium
+
+  * New upstream stable release
+- Don't inherit an unusual $XDG_RUNTIME_DIR setting into the sandbox
+  (regression in 1.8.5 and 1.10.0)
+- Improve unit test coverage
+- Various other changes that were already in earlier releases to Debian
+  * Drop all patches, applied upstream
+  * d/gbp.conf, d/control: Branch for bullseye
+  * d/watch: Restrict to 1.10.x versions for bullseye
+
+ -- Simon McVittie   Thu, 26 Aug 2021 12:01:16 +0100
+
 flatpak (1.10.2-3) unstable; urgency=medium
 
   * d/patches: Align with upstream flatpak-1.10.x branch, making this
diff --git a/debian/control b/debian/control
index f60402586..c1e35889f 100644
--- a/debian/control
+++ b/debian/control
@@ -62,7 +62,7 @@ Build-Depends-Indep:
  libostree-doc,
 Standards-Version: 4.5.1
 Homepage: https://flatpak.org/
-Vcs-Git: https://salsa.debian.org/debian/flatpak.git
+Vcs-Git: https://salsa.debian.org/debian/flatpak.git -b debian/bullseye
 Vcs-Browser: https://salsa.debian.org/debian/flatpak
 Rules-Requires-Root: no
 
diff --git a/debian/gbp.conf b/debian/gbp.conf
index f331df1a9..dd1cde049 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,7 +1,7 @@
 [DEFAULT]
 pristine-tar = True
 compression = xz
-debian-branch = debian/unstable
+debian-branch = debian/bullseye
 upstream-branch = upstream/1.10.x
 patch-numbers = False
 upstream-vcs-tag = %(version)s
diff --git a/debian/patches/series b/debian/patches/series
deleted file mode 100644
index 0ab2b98a6..0
--- a/debian/patches/series
+++ /dev/null

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

[Holger Wansing]

Control: tags -1 + pending

Justin B Rye  wrote (Fri, 10 Sep 2021 08:50:30 
+0100):
> > + 
> > + Customization
> > + 
> > + Using the shell (see ), the installation process
> > + can be carefully customized, to fit exceptional use cases:
> > + 
> > + 
> > +   Installing an alternative init system
> > + 
> > +  uses systemd as its default init system. However, 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. For detailed instructions on how to do so,
> > + please see the  > + 
> > url="https://wiki.debian.org/Init#Changing_the_init_system_-_at_installation_time;>Init
> > + page on the Debian wiki.
> > + 
> > + 
> > +   
> > +  
> 
> Yes, that looks okay to me!

Ok. Thanks

Just pushed.

Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#942190: cups: Memory leak for WIFI enabled printer.

[Brian Potkin]

tags 942190 moreinfo
thanks


On Fri 11 Oct 2019 at 22:00:40 +0200, Mladen Mijatov wrote:

> Package: cups
> Version: 2.3.0-5
> Severity: normal
> 
> I have HP LaserJet 1102W which I use through WIFI network. Over time cupsd
> starts leaking memory and within few hours goes to 1GB sometimes.

Thank you for your report, Mladen. Is this still an issue on Debian 11
(bullseye)?
 
> Printer requires HP's LIP service and drivers to work.

HPLIP is not required. This printer should do driverless printing.
Please see our wiki.

> I have also noticed that when printer is interrupted in half-print, even if I
> rester printing service memory will leak. Since I have never reported cups
> related issues submitting additional information would require some level of
> guidance.

Regards,

Brian.

Bug#928838: cups: Printing from local queue via remote queue not working any more, jobs just vanish

[Brian Potkin]

tags 928838 moreinfo
thanks


On Sun 12 May 2019 at 04:20:12 +0200, Robert Senger wrote:

> Package: cups
> Version: 2.2.10-6
> Severity: normal
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
> Setup:
> 
> Laptop (Client) running Debian 9/10 and CUPS 2.2.1/2.2.10
> Server/Router running Debian 10 and CUPS 2.2.10
> Printer Samsung Xpress C480W, LAN/WLAN
> 
> Laptop is connected to Server via SSID WLAN_1, Subnet 1
> Printer is connected to Server via SSID WLAN_2, Subnet 2
> Server should act as a print server running CUPS. Clients (laptop, printer) in
> different subnets should not communicate directly.
> 
> Printer is configured in CUPS on the server as 
> ipp://printername:631/ipp/print,
> with Samsung C48x driver, queue name SAMSUNG, printing test pages from the
> server's web interface works fine
> Printer is configured in CUPS on the Laptop as
> ipps://servername:631/printers/SAMSUNG
> 
> With Debian 9 and CUPS 2.2.1 on the Server, this setup worked fine.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> Upgraded Server to Debian 10, CUPS 2.2.10
> 
>* What was the outcome of this action?
> 
> Printing as describes above stopped working. Jobs sent from the laptop just go
> into Nirvana, they vanish and do not show up in the server's queue. The 
> servers
> access_log reports success, but printing never happens. No errors are reported
> neither on the laptop nor on the server.
> 
>* What outcome did you expect instead?
> 
> Printing as before.
> 
>* Workaround(s)
> 
> - Downgrading CUPS from 2.2.10 to 2.2.1 (debs from Debian 9) on the Debian 10
> server fixes this problem, printing works fine again.
> - Using a client.conf file with "ServerName servername" makes printing
> possible, but without a local queue there's no queue dialog that can report
> failures (emtpy tray, paper jam) on the client
> - Printing directly to the printer from the laptop works, but is not desired
> 
> So, CUPS 2.2.10 is broken when used as a print server for clients running 
> local
> queues.

Thank you for your report, Robert. Did you ever resolve this issue for
yourself? Perhaps by upgrading to bullseye on client and server?

Regards,

Brian.

Bug#994049: libhwloc-contrib-plugins: hwloc displays misleading CUDA and NVML errors when running MPI programs

[Baptiste Jonglez]

Package: libhwloc-contrib-plugins
Version: 2.4.1+dfsg-2
Severity: important

Dear Maintainer,

When the libhwloc-contrib-plugins package is installed, running any MPI
program on a Debian 11 host with no GPU produces the following errors:

$ mpirun hostname
CUDA: Failed to get number of devices with cudaGetDeviceCount(): no 
CUDA-capable device is detected
NVML: Failed to initialize with nvmlInit(): Driver Not Loaded
CUDA: Failed to get number of devices with cudaGetDeviceCount(): no 
CUDA-capable device is detected
NVML: Failed to initialize with nvmlInit(): Driver Not Loaded
dahu-28.grenoble.grid5000.fr

For complex programs, it is quite hard to understand where these messages
come from and what the exact problem is.  After investigation, it turns out
that these messages are "warnings" and don't prevent the program from
executing, so they can be ignored.  But when the program fails for unrelated
reasons, these messages can mislead the user into thinking the problem is
CUDA-related, while it's actually not.

The expected behaviour is that hwloc should not print warnings about
hardware detection when nothing is actually wrong.

This bug has already been fixed upstream in version 2.5.0rc1:

835dfbe577fcd7 ("core: don't display "less critical" error messages by 
default")
https://github.com/open-mpi/hwloc/issues/453

Would it be possible to backport this patch to Debian stable or,
as an alternative, publish hwloc 2.5.0 in bullseye-backports?

Thanks for your time,
Baptiste

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

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

Versions of packages libhwloc-contrib-plugins depends on:
ii  libc6  2.31-13
ii  libcudart11.0  5000.0g5k1
ii  libhwloc15 2.4.1+dfsg-1
ii  libnvidia-ml1  5000.0g5k1

libhwloc-contrib-plugins recommends no packages.

libhwloc-contrib-plugins suggests no packages.

-- no debconf information

Bug#994042: libc6: debconf text fallback failed to accept input, had to be killed leading to broken dist-upgrade

[Colin Watson]

On Fri, Sep 10, 2021 at 04:02:06PM +0100, Neil Williams wrote:
> This is related to #984533 - in my case, there was no effect on the initramfs.
> 
> I am attaching the section of the apt log. (gzipped)
> I am also attaching the dpkg -l output for the package list (after upgrade).
> 
> The apt log includes the details of the --purge autoremove operation I 
> completed
> after a reboot, so those packages were also installed on buster too.
> 
> This was an upgrade from buster to bullseye.
> apt upgrade worked fine (first part of the log).
> 
> When dist-upgrade started, I got:
> 
> Preparing to unpack .../92-libc6_2.31-13_amd64.deb ...
> debconf: unable to initialize frontend: Dialog
> debconf: (No usable dialog-like program is installed, so the dialog based 
> frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
> 78.)
> debconf: falling back to frontend: Readline
> Checking for services that may need to be restarted...
> Checking init scripts...
> Do you want to upgrade glibc now?
> 
> Running services and programs that are using NSS need to be restarted,
> otherwise they might not be able to do lookup or authentication any more.
> The installation process is able to restart some services (such as ssh or
> telnetd), but other programs cannot be restarted automatically.  One such
> program that needs manual stopping and restart after the glibc upgrade by
> yourself is xdm - because automatic restart might disconnect your active
> X11 sessions.
> 
> This script detected the following installed services which must be
> stopped before the upgrade: postgresql 
> 
> If you want to interrupt the upgrade now and continue later, please
> answer No to the question below.
> 
> Do you want to upgrade glibc now? [Y/n] y
> Y

The code in libc.preinst that attempts to fall back to text mode,
introduced in 2.31-10, is clearly incorrect; apologies for not noticing
this earlier.  It sources the debconf confmodule and then conditionally
sets USE_DEBCONF; but since the debconf confmodule has already been
sourced by this point, text mode won't work properly since standard
input and output refer to the debconf frontend.  (In particular, reading
from stdin can't work.)

The only way to fix what libc.preinst is currently trying to do would
be:

 * Fetch the current debconf frontend *without* first sourcing the
   confmodule, e.g. using something like "echo GET debconf/frontend |
   debconf-communicate" which I *think* is safe as long as you haven't
   sourced the confmodule yet;

 * Decide whether to use debconf based on this and other information;

 * Only source the confmodule if you've positively decided to use it.

But a simpler approach might be to update debconf in buster with the
change from 1.5.76 to check whether whiptail/dialog is usable before
trying to use it, and then remove at least some of this fragile and
broken code from libc.preinst.  At the very least, USE_DEBCONF=1 must
always be set if (and only if) the debconf confmodule has been sourced.

I'm currently seeing if I can construct a reduced reproduction recipe
based on Neil's logs, since it evidently depends on exactly which order
apt chooses to unpack things early on, and it would be very helpful to
be able to test fixes properly.

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

Bug#994037: xkb-data: TWO_LEVEL is not available

[Vincent Lefevre]

Control: reassign -1 x11-xkb-utils 7.7+5
Control: retitle -1 x11-xkb-utils: xkbcomp fails with "X Error of failed 
request: BadValue" for XkbSetMap on specific config

On 2021-09-10 14:31:38 +0200, Vincent Lefevre wrote:
> cventin:~> xkbcomp -w 0 -I$HOME/.xkb -R$HOME/.xkb keymap/custom $DISPLAY
> Internal error:   Could not resolve keysym XF86BrightnessAuto
> Internal error:   Could not resolve keysym XF86DisplayOff
> [...]
> Internal error:   Could not resolve keysym XF86KbdLcdMenu4
> Internal error:   Could not resolve keysym XF86KbdLcdMenu5
> X Error of failed request:  BadValue (integer parameter out of range for 
> operation)
>   Major opcode of failed request:  135 (XKEYBOARD)
>   Minor opcode of failed request:  9 (XkbSetMap)
>   Value in failed request:  0x166c0002
>   Serial number of failed request:  120
>   Current serial number in output stream:  126
> 
> The internal errors are unrelated. The real issue is the BadValue.
> If I change TWO_LEVEL to ONE_LEVEL, the error disappears (but I
> don't get the second level).
> 
> There is no such issue with xkb-data 2.29-2.

This was due to the default ralt_switch_multikey option in 2.29-2.
So, this seems to be more a bug of xkbcomp. In particular, the
error message is very cryptic, and I couldn't find any clue on
the web (except from users who obtained a similar error several
years ago, but this was eventually fixed in xkbcomp, like
).

My problem is reproducible with:

zira:~> cat .xkb/keymap/custom
xkb_keymap {
xkb_keycodes  { include "evdev+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat{ include "complete" };
xkb_symbols   { include "pc+gb+level3(ralt_switch)+local" };
xkb_geometry  { include "pc(pc105)" };
};

zira:~> cat .xkb/symbols/local
xkb_symbols "local" {
key  {
type = "TWO_LEVEL",
symbols[Group1] = [ ISO_Level3_Shift, Multi_key ]
};
};

zira:~> xkbcomp -I$HOME/.xkb -R$HOME/.xkb keymap/custom $DISPLAY
[unrelated warnings]
X Error of failed request:  BadValue (integer parameter out of range for 
operation)
  Major opcode of failed request:  135 (XKEYBOARD)
  Minor opcode of failed request:  9 (XkbSetMap)
  Value in failed request:  0x166c0002
  Serial number of failed request:  120
  Current serial number in output stream:  126

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

Bug#994048: glewlwyd: [INTL:de] Updated German Debconf Translation

[Chris Leick]

Package: glewlwyd
Version: 2.5.2-3
Severity: wishlist
Tags: l10n patch



Hi,

please find attached the newest German debconf translation.

Kind regards,
Chris


de.po.gz
Description: application/gzip

Bug#994047: python3-jupyter-sphinx-theme: Switch to myst-parser instead of recommonmark

[Emmanuel Arias]

Source: jupyter-sphinx-theme
Version: 0.0.6+ds1-10
Severity: wishlist
X-Debbugs-Cc: eam...@yaerobi.com,team+pyt...@tracker.debian.org

Dear Maintainer,

python3-jupyter-sphinx-theme currently Build-Depends or Depends on 
python3-recommonmark
from recommonmark. This project is deprecated and upstream recommend the use
of and MyST [0][1] (see ITP: #993553). Please switch to MyST-Parse (when is
Ready).


[0] https://github.com/readthedocs/recommonmark
[1] https://github.com/executablebooks/MyST-Parser


Cheers
Emmanuel

Bug#994022: java-atk-wrapper 0.38.0-2+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 994022 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: java-atk-wrapper
Version: 0.38.0-2+deb11u1

Explanation: also use dbus to detect accessibility being enabled

Bug#994021: java-atk-wrapper 0.33.3-22+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 994021 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: java-atk-wrapper
Version: 0.33.3-22+deb10u1

Explanation: also use dbus to detect accessibility being enabled

Bug#993823: clamav 0.103.3+dfsg-0+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 993823 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: clamav
Version: 0.103.3+dfsg-0+deb10u1

Explanation: new upstream stable release; fix clamdscan segfaults when --fdpass 
and --multipass are used together with ExcludePath

Bug#993822: clamav 0.103.3+dfsg-0+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 993822 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: clamav
Version: 0.103.3+dfsg-0+deb11u1

Explanation: new upstream stable release; fix clamdscan segfaults when --fdpass 
and --multipass are used together with ExcludePath

Bug#992243: psmisc 23.2-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 992243 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: psmisc
Version: 23.2-1+deb10u1

Explanation: fix regression in killall not matching process with names longer 
than 15 characters

Bug#992374: nvidia-cuda-toolkit 9.2.148-7+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 992374 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: nvidia-cuda-toolkit
Version: 9.2.148-7+deb10u1

Explanation: fix setting of NVVMIR_LIBRARY_DIR on ppc64el

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

[Danny van Heumen]

Hi Eric,

Indeed, a fix was implemented.

Yes. I think that the address from the public-resolvers document should take 
precedence over the address from an arbitrary resolver.

Kind regards,
Danny

‐‐‐ Original Message ‐‐‐

On Friday, September 10th, 2021 at 7:40 AM, Eric Dorland  
wrote:

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

Bug#994046: formiko: Switch to myst-parser instead of recommonmark

[Emmanuel Arias]

Package: formiko
Version: 1.3.0-2
Severity: wishlist
X-Debbugs-Cc: eam...@yaerobi.com


Dear Maintainer,

formiko currently Build-Depends or Depends on python3-recommonmark
from recommonmark. This project is deprecated and upstream recommend the use
of and MyST [0][1] (see ITP: #993553). Please switch to MyST-Parse (when is
Ready).


[0] https://github.com/readthedocs/recommonmark
[1] https://github.com/executablebooks/MyST-Parser


Cheers,
Emmanuel

Bug#974205: Disconnects when sending specific character sequences on private chat

[Stefan]

This bug doesn't affects only profanity-light. The problem also
appears in profanity.

profanity is using the XMPP libstrophe. libstrophe should filter out
forbidden sequences. The issue in upstream's projects is
https://github.com/strophe/libstrophe/issues/170

-- 
Stefan

Bug#994045: python-pip-whl: pip 18.1 raises EnvironmentError on 404 from index, which leads to PIP_FIND_LINKS being ignored

[MrMino]

Package: python-pip-whl
Version: 18.1-5
Severity: important

Dear Maintainers,

TLDR: Current version of python-pip-whl breaks python-virtualenv if a custom
index-url is used inside ~/.pip/pip.conf.

Debian version of virtualenv uses PIP_FIND_LINKS environment variable to
inject files from /usr/share/python-wheels into pip's dependency resolution.

Since python-virtualenv will try to install pkg_resources==0.0.0 as a
separate package (which does not exist on any Python index, given that
it's a part of setuptools), it will instruct pip to do something akin to
"pip install pkg_resources". Pip will ask the index about pkg_resources,
which will return a 404. Then, pip will move to resolving the dependency
using PIP_FIND_LINKS.

That is, only if the original PyPI index is used. If you use a custom
index via ~/.pip/pip.conf file, Pip will fail with the following
message:

Could not install packages due to an EnvironmentError: 404
Client Error: Not Found for url: 

... and exit with RC=1 without going through PIP_FIND_LINKS directory.

This means, that if one has a custom index set in his ~/.pip/pip.conf,
virtualenv will fail with the following log:

New python executable in /env/bin/python2
Also creating executable in /env/bin/python
Installing setuptools, pkg_resources, pip, wheel...
  Complete output from command /env/bin/python2 - setuptools 
pkg_resources pip wheel:
  Looking in indexes: 
Looking in links: /usr/lib/python3/dist-packages, 
/usr/share/python-wheels/
Collecting setuptools
  Downloading 
Collecting pkg_resources
Could not install packages due to an EnvironmentError: 404 Client 
Error: Not Found for url: 


...Installing setuptools, pkg_resources, pip, wheel...done.
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/virtualenv.py", line 2379, in 

main()
  File "/usr/lib/python3/dist-packages/virtualenv.py", line 724, in main
symlink=options.symlink)
  File "/usr/lib/python3/dist-packages/virtualenv.py", line 996, in 
create_environment
download=download,
  File "/usr/lib/python3/dist-packages/virtualenv.py", line 926, in 
install_wheel
call_subprocess(cmd, show_stdout=False, extra_env=env, stdin=SCRIPT)
  File "/usr/lib/python3/dist-packages/virtualenv.py", line 817, in 
call_subprocess
% (cmd_desc, proc.returncode))
OSError: Command /env/bin/python2 - setuptools pkg_resources pip wheel 
failed with error code 1
Running virtualenv with interpreter /usr/bin/python2

None of this happens when using the upstream 18.1 version of pip, which
leads me to believe this bug is specific to python-pip-whl/python-pip.

During analysis, I created a simple Dockerfile for reproducing this
issue, but it requires setting up a custom index. Currently the behavior
has been observed when using Artifactory. We have at least one index
hosted internally via HTTP that does not lead to the aforementioned
buggy behavior, so the problem seems specific to HTTPS requests.

(_Replace  with a custom index_)

FROM debian:buster

RUN apt update
RUN apt install -y python2 virtualenv
RUN mkdir ~/.pip/
RUN echo "[global]" >> ~/.pip/pip.conf
RUN echo "index-url = " >> ~/.pip/pip.conf
CMD virtualenv env


Best Regards
Blazej Michalik


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

Kernel: Linux 5.11.0-27-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages python-pip-whl depends on:
ii  ca-certificates  20200601~deb10u2

python-pip-whl recommends no packages.

python-pip-whl suggests no packages.

-- no debconf information

Bug#994033: mpd: Fails to find ldd libraries from libraspberrypi0 that have moved

[kaliko]

Hi Tim

Max Kellermann wrote :

On 2021/09/10 11:43, Tim Phipps  wrote:

AN upgrade to rasbian stable ahs moved some ldd files included in the 
libraspberrypi0 packages and now mpd fails to start.


MPD doesn't use any of these libraries.  These are indirect
dependencies, maybe via FFmpeg?  In any case, this is not a MPD
packaging problem.


Did you mixed Debian/bullseye repositories with Raspbian|Raspberry Pi 
OS/bullseye?
These are not compatible, especially for non architecture independent package 
like MPD.
libmmal_core.so is provided by libraspberrypi0 package which is not in Debian 
repositories.

This issue is not Debian related IMHO.

By the way, I believe rasbian stable is still based on buster, not bullseye.

Cheers
k



OpenPGP_signature
Description: OpenPGP digital signature

Bug#989030: memtest86+: New upstream version available v5.31b

[Michael Prokop]

Hi,

* Junichi Uekawa [Mon May 24, 2021 at 08:44:15AM +0900]:

> According to memtest.org site, there's a new upstream version available for 
> testing. 
> https://www.memtest.org/#downcode

Friendly ping :)
Is there any chance to see version 5.31b in Debian?

FTR, this is also related to #977217. Furthermore the Grml team also
got a bug report, that the new version works fine on AMD Ryzen
systems, whereas previous versions of memtest86+ don't work (see
https://github.com/grml/grml/issues/178).

regards
-mika-


signature.asc
Description: Digital signature

Bug#712872: cups: [RFE] Modifying authentication data for a job in the queue

[Brian Potkin]

tags 712872 moreinfo
thanks



On Thu 20 Jun 2013 at 12:59:37 +0100, Sam Morris wrote:

> Package: cups
> Version: 1.6.2-9
> Severity: wishlist
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Some programs (such as Libreoffice) do not provide a way to specify a
> username and password when printing to a printer that has
> "AuthInfoRequired username,password" in its printers.conf entry.
> 
> A job created by such a program will sit in the queue until an
> administrator removes it.
> 
> I'd like a way for the administrator to specify authentication values
> for such a job that has been created without them. Something like:
> 
>   # lpmodify -o username=foo,password 7
>   Enter value for 'password': ***
> 
> Here the given value was used for username, and since no password was
> specified it was prompted so that it is not visible in the process's
> command line arguments, nor is it recorded in the user's shell history.

Hello Sam,

Michael Sweet presented some ideas. If the first one suits your
situation, I would suggest closing this rather old report.

If the second idea (involving lp and -i) is to be pursued, I would
suggest you submit an issue at

  https://github.com/OpenPrinting/cups/issues

Regards,

Brian.

Bug#994044: CAP_PERFMON should override kernel.perf_event_paranoid=3

[Stephan Hohe]

Package: linux
Version: 5.10.46-4

(Probably applies to all versions >=5.9)

Hello,

Debian adds kernel.perf_event_paranoid=3 as an additional restriction 
level for perf_event_open() 
(debian/patches/features/all/security-perf-allow-further-restriction-of-perf_event_open.patch). 
This can be overridden by the capability CAP_SYS_ADMIN.


Since the introduction of this patch, Linux introduced the new 
capability CAP_PERFMON [1] to guard access the perf_event_open() in a 
more granular way than CAT_SYS_ADMIN. Processes with CAP_PERFMON are 
intended to not be bound by kernel.perf_event_paranoid restrictions, but 
this does not currently work for kernel.perf_event_paranoid=3.


The code patched with 
security-perf-allow-further-restriction-of-perf_event_open.patch can be 
easily adjusted to also respect CAT_PERFMON by using the helper function 
perfmon_capable() in perf_event_open(). (This helper function is what 
all the other perf code uses for capability checks):


--- kernel/events/core.c.orig   2021-09-10 13:44:39.926796374 +0200
+++ kernel/events/core.c2021-09-10 13:44:44.430640895 +0200
@@ -11696,7 +11696,7 @@
if (flags & ~PERF_FLAG_ALL)
return -EINVAL;

-   if (perf_paranoid_any() && !capable(CAP_SYS_ADMIN))
+   if (perf_paranoid_any() && !perfmon_capable())
return -EACCES;

/* Do we allow access to perf_event_open(2) ? */


To test if perf_event_open() can be called successfully, a command like 
this can be used:


sudo capsh --caps="cap_perfmon+eip 
cap_setpcap,cap_setuid,cap_setgid+ep" \

   --keep=1 --user=nobody --addamb=cap_perfmon -- perf top

This shows an error and exits if access to perf_event_open() is denied.

/Stephan


[1]: 
https://lwn.net/ml/linux-kernel/c8de937a-0b3a-7147-f5ef-69f467e87...@linux.intel.com/

Bug#991747: dh-make-golang: create-salsa-project gives unexpected HTTP status code

[Aloïs Micard]

This error message happens because chuchi (the old CI runner) has been disabled.
the issue is already fixed on the new repository [1]. It is just awaiting
deployment.

Cheers,

[1]: https://salsa.debian.org/go-team/infra/pkg-go-tools

--
Aloïs Micard 

GPG: DA4A A436 9BFA E299 67CD E85B F733 E871 0859 FCD2

Bug#994043: plasma-discover: Unable to present the details page

[Bob Wong]

Package: plasma-discover
Version: 5.21.5-2
Severity: important

Dear Maintainer,

  I can only install/uninstall the software in the discovery and the
discovery cannot present the details page of the application.


-- System Information:
Debian Release: bookworm/sid
  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)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8),
LANGUAGE=zh_CN:zh
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages plasma-discover depends on:
ii  appstream0.14.4-1
ii  apt-config-icons 0.14.4-1
ii  kio  5.83.0-2
ii  libappstreamqt2  0.14.4-1
ii  libc62.31-17
ii  libkf5attica55.85.0-2
ii  libkf5configcore55.85.0-2
ii  libkf5configgui5 5.85.0-2
ii  libkf5configwidgets5 5.85.0-2
ii  libkf5coreaddons55.85.0-2
ii  libkf5crash5 5.85.0-2
ii  libkf5dbusaddons55.85.0-2
ii  libkf5i18n5  5.85.0-2
ii  libkf5idletime5  5.85.0-2
ii  libkf5itemmodels55.85.0-2
ii  libkf5kiocore5   5.83.0-2
ii  libkf5kiogui55.83.0-2
ii  libkf5kiowidgets55.83.0-2
ii  libkf5newstuffcore5  5.83.0-2
ii  libkf5notifications5 5.85.0-3
ii  libkf5quickaddons5   5.83.0-2
ii  libkf5service-bin5.85.0-2
ii  libkf5service5   5.85.0-2
ii  libkf5widgetsaddons5 5.85.0-2
ii  libkf5windowsystem5  5.85.0-2
ii  libkf5xmlgui55.85.0-3
ii  libmarkdown2 2.2.7-2
ii  libpackagekitqt5-1   1.0.2-1
ii  libqt5core5a 5.15.2+dfsg-10
ii  libqt5dbus5  5.15.2+dfsg-10
ii  libqt5gui5   5.15.2+dfsg-10
ii  libqt5network5   5.15.2+dfsg-10
ii  libqt5qml5   5.15.2+dfsg-8
ii  libqt5quick5 5.15.2+dfsg-8
ii  libqt5widgets5   5.15.2+dfsg-10
ii  libqt5x11extras5 5.15.2-2
ii  libqt5xml5   5.15.2+dfsg-10
ii  libstdc++6   11.2.0-4
ii  packagekit   1.2.2-2
ii  plasma-discover-common   5.21.5-2
ii  qml-module-org-kde-kcoreaddons   5.83.0-2
ii  qml-module-org-kde-kirigami2 5.85.0-2
ii  qml-module-org-kde-kquickcontrols5.83.0-2
ii  qml-module-org-kde-kquickcontrolsaddons  5.83.0-2
ii  qml-module-org-kde-qqc2desktopstyle  5.85.0-2
ii  qml-module-qtquick-dialogs   5.15.2-2

Versions of packages plasma-discover recommends:
ii  apt-config-icons-hidpi0.14.4-1
ii  apt-config-icons-large0.14.4-1
ii  apt-config-icons-large-hidpi  0.14.4-1
ii  kde-config-updates5.21.5-2
ii  software-properties-kde   0.96.20.2-2.1

Versions of packages plasma-discover suggests:
pn  plasma-discover-backend-flatpak  
pn  plasma-discover-backend-fwupd

Bug#994041:

[Bob Wong]

Package: plasma-desktop
Version: 4:5.21.5-2
Severity: important

Dear Maintainer,

 I followed the tutorial
https://wiki.debian.org/NVIDIA%20Optimus#Using_NVIDIA_GPU_as_the_primary_GPU,
and after I prepared everything ready, the panel cannot load. I can't add
the panel, either. However, when I start the desktop through the terminal
with the startx, everything worked fine.


-- System Information:
Debian Release: bookworm/sid
  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)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8),
LANGUAGE=zh_CN:zh
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages plasma-desktop depends on:
ii  accountsservice  0.6.55-3
ii  breeze   4:5.21.5-2
ii  kactivitymanagerd5.21.5-2
ii  kde-cli-tools4:5.21.5-2
ii  kded55.85.0-2
ii  kio  5.83.0-2
ii  kpackagetool55.85.0-2
ii  libaccounts-qt5-11.16-2
ii  libc62.31-17
ii  libcrypt11:4.4.25-2
ii  libglib2.0-0 2.68.4-1
ii  libibus-1.0-51.5.25-2
ii  libkaccounts24:21.08.0-1
ii  libkf5activities55.85.0-2
ii  libkf5activitiesstats1   5.85.0-2
ii  libkf5authcore5  5.85.0-2
ii  libkf5baloo5 5.83.0-2
ii  libkf5codecs55.85.0-2
ii  libkf5completion55.85.0-2
ii  libkf5configcore55.85.0-2
ii  libkf5configgui5 5.85.0-2
ii  libkf5configwidgets5 5.85.0-2
ii  libkf5coreaddons55.85.0-2
ii  libkf5crash5 5.85.0-2
ii  libkf5dbusaddons55.85.0-2
ii  libkf5declarative5   5.83.0-2
ii  libkf5globalaccel-bin5.85.0-2
ii  libkf5globalaccel5   5.85.0-2
ii  libkf5guiaddons5 5.85.0-2
ii  libkf5i18n5  5.85.0-2
ii  libkf5iconthemes55.85.0-2
ii  libkf5itemviews5 5.85.0-2
ii  libkf5jobwidgets55.85.0-2
ii  libkf5kcmutils5  5.83.0-2
ii  libkf5kdelibs4support5   5.83.0-2
ii  libkf5kiocore5   5.83.0-2
ii  libkf5kiofilewidgets55.83.0-2
ii  libkf5kiogui55.83.0-2
ii  libkf5kiowidgets55.83.0-2
ii  libkf5newstuff5  5.83.0-2
ii  libkf5notifications5 5.85.0-3
ii  libkf5notifyconfig5  5.83.0-2
ii  libkf5package5   5.85.0-2
ii  libkf5plasma55.83.0-2
ii  libkf5plasmaquick5   5.83.0-2
ii  libkf5quickaddons5   5.83.0-2
ii  libkf5runner55.83.0-3
ii  libkf5service-bin5.85.0-2
ii  libkf5service5   5.85.0-2
ii  libkf5solid5 5.85.0-2
ii  libkf5sonnetcore55.85.0-2
ii  libkf5sonnetui5  5.85.0-2
ii  libkf5wallet-bin 5.83.0-2
ii  libkf5wallet55.83.0-2
ii  libkf5widgetsaddons5 5.85.0-2
ii  libkf5windowsystem5  5.85.0-2
ii  libkf5xmlgui55.85.0-3
ii  libkworkspace5-5 4:5.21.5-3
ii  libnotificationmanager1  4:5.21.5-3
ii  libpackagekitqt5-1   1.0.2-1
ii  libphonon4qt5-4  4:4.11.1-4
ii  libprocesscore9  4:5.21.5-3
ii  libqt5concurrent55.15.2+dfsg-10
ii  libqt5core5a 5.15.2+dfsg-10
ii  libqt5dbus5  5.15.2+dfsg-10
ii  libqt5gui5   5.15.2+dfsg-10
ii  libqt5network5   5.15.2+dfsg-10
ii  libqt5qml5   5.15.2+dfsg-8
ii  libqt5quick5 5.15.2+dfsg-8
ii  libqt5quickwidgets5  5.15.2+dfsg-8
ii  libqt5sql5   5.15.2+dfsg-10
ii  libqt5widgets5   5.15.2+dfsg-10
ii  libqt5x11extras5 5.15.2-2
ii  libqt5xml5   5.15.2+dfsg-10
ii  libscim8v5   

Bug#992692: general: Use https for {deb,security}.debian.org by default

[Simon Richter]

Hi,

On 10.09.21 01:46, Paul Wise wrote:


Another important argument is that it creates a dependency on
third-party commercial CDNs, and their *continued* sponsorship.



This dependency on external providers is unavoidable, Debian
definitely cannot afford to run our own CDN at the scale needed to
support our existing userbase. For example the security mirrors
struggled with Linux kernel security updates, so security.d.o switched
to a commercial CDN. Also, we are dependent on continued sponsorship
for all of our infrastructure, paying for all of our hosting is likely
not feasible.


Yes -- and mirrors have traditionally been provided by third parties. 
What is new about the CDNs is that there are rather few of those, and 
this centralization aspect is what worries me.



Personally I'd like to see a larger variety of Debian delivery
mechanisms; copy Debian/snapshot to archive.org, create a multi-distro
FLOSS CDN, bring back httpredir, DebTorrent and apt-p2p, add an i2p
mirror, use IPFS and content oriented networking etc. Michael Stone's
apt://debian idea seems like a good way to move in that direction
while adding protocol agility.


Yes, absolutely -- and we especially want to have a better solution for 
containers, because my expectation is that a large fraction of our 
traffic is just people not bothering to set up caching.


   Simon

Bug#993037: Acknowledgement (nextcloud-desktop: Stop working since 3.3.1 release.)

[Christian Marillat]

tags 993037 fixed-upstream
thanks

Hi,

This bug has been fixed by upstream author in version 3.3.3

Christian

Bug#994040: "SystemError: initialization of _psycopg raised unreported exception" when running under WSGI

[Stephane Bortzmeyer]

Package: libapache2-mod-wsgi-py3
Version: 4.7.1-3+b1
Severity: normal

Dear Maintainer,

Since upgrading to bullseye, a WSGI script which imports psycopg2
fails sometimes (randomly?) with:

[Sun Aug 29 17:54:07.215719 2021] [wsgi:error] [pid 7705] [client 
127.0.0.1:33774] mod_wsgi (pid=7705): Exception occurred processing WSGI script 
'/var/www/wsgis-bortzmeyer/ni.py'.
[Sun Aug 29 17:54:07.215893 2021] [wsgi:error] [pid 7705] [client 
127.0.0.1:33774] Traceback (most recent call last):
[Sun Aug 29 17:54:07.215967 2021] [wsgi:error] [pid 7705] [client 
127.0.0.1:33774]   File "/var/www/wsgis-bortzmeyer/ni.py", line 11, in 
[Sun Aug 29 17:54:07.216000 2021] [wsgi:error] [pid 7705] [client 
127.0.0.1:33774] import psycopg2
[Sun Aug 29 17:54:07.216026 2021] [wsgi:error] [pid 7705] [client 
127.0.0.1:33774]   File "/usr/lib/python3/dist-packages/psycopg2/__init__.py", 
line 51, in 
[Sun Aug 29 17:54:07.216051 2021] [wsgi:error] [pid 7705] [client 
127.0.0.1:33774] from psycopg2._psycopg import ( # noqa
[Sun Aug 29 17:54:07.216087 2021] [wsgi:error] [pid 7705] [client 
127.0.0.1:33774] SystemError: initialization of _psycopg raised unreported 
exception

psycopg2 on the same machine always work when ran outside of WSGI.

Setting WSGIApplicationGroup %{GLOBAL} in the configuration cures the
problem.

I checked that there is only one Python (the Debian package) on the
machine.

A similar case is reported in 
.

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

Kernel: Linux 5.13.4-x86_64-linode146 (SMP w/2 CPU threads)
Locale: LANG=C, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libapache2-mod-wsgi-py3 depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.48-3.1+deb11u1
ii  libc6   2.31-13
ii  libpython3.93.9.2-1
ii  python3 3.9.2-3

libapache2-mod-wsgi-py3 recommends no packages.

libapache2-mod-wsgi-py3 suggests no packages.

-- no debconf information

Bug#994039: ITP: mirrorbits -- Geographical download redirector for distributing files efficiently across a set of mirrors.

[Arnaud Rebillout]

Package: wnpp
Severity: wishlist
Owner: Arnaud Rebillout 

* Package name: mirrorbits
  Version : 0.5.1+git20210123.eeea0e0-1
  Upstream Author : Ludovic Fauvet
* URL : https://github.com/etix/mirrorbits
* License : Expat
  Programming Lang: Go
  Description : Geographical download redirector for distributing files 
efficiently across a set of mirrors.

 Mirrorbits Mirrorbits is a geographical download redirector written in
 Go (https://golang.org) for distributing files efficiently across a set
 of mirrors. It offers a simple and economic way to create a Content
 Delivery Network layer using a pure software stack. It is primarily
 designed for the distribution of large-scale Open-Source projects with
 a lot of traffic.
 .
 Main Features
  * Blazing fast, can reach 8K QPS on a single laptop
  * Easy to deploy and maintain, everything is packed in a single
binary
  * Automatic synchronization with the mirrors over rsync or FTP
  * Response can be either JSON or HTTP redirect
  * Support partial repositories
  * Complete checksum / size control
  * Realtime monitoring and reports
  * Disable misbehaving mirrors without human intervention
  * Realtime decision making based on location, AS number and
defined rules
  * Smart load-balancing over multiple mirrors in the same area
to avoid hotspots
  * Ability to adjust the weight of each mirror
  * Limit access to a country, region or ASN for any mirror
  * Clustering (multiple mirrorbits instances)
  * High-availability using redis-sentinel
  * Automatically fix timezone offsets for broken mirrors
  * Realtime statistics per file / mirror / date
  * Realtime reconfiguration
  * Seamless binary upgrade (aka zero downtime upgrade)
  * Mirmon (http://www.staff.science.uu.nl/~penni101/mirmon/) support
  * Full IPv6 support
  * more...
 .
 Is it production ready?  Yes! Mirrorbits has served billions of files
 already and is known to be running in production at VideoLAN
 (http://www.videolan.org) to distribute VLC media player
 (http://www.videolan.org/vlc/) since April 2014

Bug#743694: lintian: Downgrade most of privacy-breach* tags from severity: error to pedantic

[Daniel Leidert]

Am Freitag, dem 10.09.2021 um 15:46 +0200 schrieb Bill Allombert:
> On Fri, Sep 10, 2021 at 02:41:20PM +0200, Daniel Leidert wrote:
> > And once again: What is the sense and what right do we have to remove
> > donation
> > requests just because they use icons of paypal/patreon/github/whatever
> > which we
> > cannot distribute?
> 
> If upstream cannot be bothered to provide a DFSG-compatible donation
> document, one can just replace it by an explicit link to the page on its
> website. Users need an internet connection to make a donation in any
> case.

What are you talking about? How is such a donation link not DFSG compatible and
how does it violate the DFSG?


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

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


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

Bug#743694: lintian: Downgrade most of privacy-breach* tags from severity: error to pedantic

[Bill Allombert]

On Fri, Sep 10, 2021 at 02:41:20PM +0200, Daniel Leidert wrote:
> And once again: What is the sense and what right do we have to remove donation
> requests just because they use icons of paypal/patreon/github/whatever which 
> we
> cannot distribute?

If upstream cannot be bothered to provide a DFSG-compatible donation
document, one can just replace it by an explicit link to the page on its
website. Users need an internet connection to make a donation in any
case.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#931831: cups: http://localhost:631/ is served with HTTP Content-Type: text/plain

[Brian Potkin]

tags 931831 moreinfo
thanks


On Thu 11 Jul 2019 at 05:30:32 +, Witold Baryluk wrote:

> Package: cups
> Version: 2.2.10-6
> Severity: important
> 
> 
> $ curl -v http://localhost:631/
> ...
> > GET / HTTP/1.1
> > Host: localhost:631
> > User-Agent: curl/7.64.0
> > Accept: */*
> > 
> < HTTP/1.1 200 OK
> < Connection: Keep-Alive
> < Content-Language: en_US
> < Content-Length: 2364
> < Content-Type: text/plain
> < Date: Thu, 11 Jul 2019 05:27:25 GMT
> < Keep-Alive: timeout=10
> < Last-Modified: Tue, 23 Apr 2019 06:33:01 GMT
> < Accept-Encoding: gzip, deflate, identity
> < Server: CUPS/2.2 IPP/2.1
> < X-Frame-Options: DENY
> < Content-Security-Policy: frame-ancestors 'none'
> < 
> 
> 
>   
> 
> 
> 
> 
> 
> 
> Home - CUPS 2.2.10
>   
>   
> 
> ...
> 
> 
> Obviously this is not correct.
> 
> CUPS should serve it as Content-Type: text/html
> 
> Firefox and Chromium display the served data as raw text, making web
> interface unusable.

Thank you for both your reports, Witold.

With cups 2.3.3op2-6 and 2.3.3op2-7 (the present unstable version)
I get:

brian@desktop:~$ curl -sSi http://localhost:631/ | grep ^Content-Type
Content-Type: text/html; charset=utf-8
brian@desktop:~$

Please would you test with either of these versions.

Regards,

Brian.

Bug#994026: xkb-data: breaks Multi_key, a.k.a. Compose key

[Vincent Lefevre]

On 2021-09-10 04:09:52 +0200, Vincent Lefevre wrote:
> Package: xkb-data
> Version: 2.33-1
> Severity: important
> 
> The upgrade from 2.29-2 to 2.33-1 silently breaks Multi_key.
> 
> A diff of the xkbcomp dump gives in particular:
> 
>  key  {
> -type= "TWO_LEVEL",
> -symbols[Group1]= [ ISO_Level3_Shift,   Multi_key ]
> +type= "ONE_LEVEL",
> +symbols[Group1]= [ ISO_Level3_Shift ]
>  };
> 
> i.e. Multi_key is no longer there.
> 
> Note: I use the gb keyboard layout.

This is apparently due to the following upstream change. But this is
the kind of thing that should be announced in NEWS.Debian.

commit 5ac82bfc696213eb24759bf81670bca21d122da3
Author: M Hickford 
Date:   2021-02-20 21:16:56 +0100

Simplify gb(basic) so that Shift+Right Alt behaves the same as Right 
Alt+Shift. Resolves #245

For the old behaviour, use `setxkbmap -option lv3:ralt_switch_multikey`

diff --git a/symbols/gb b/symbols/gb
index b5db5eb6..87d82170 100644
--- a/symbols/gb
+++ b/symbols/gb
@@ -20,7 +20,7 @@ xkb_symbols "basic" {
 key  { [numbersign, asciitilde,   dead_grave,   dead_breve ] };
 key  { [ backslash,bar,  bar,brokenbar ] };
 
-include "level3(ralt_switch_multikey)"
+include "level3(ralt_switch)"
 };
 
 partial alphanumeric_keys

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

Bug#994026: xkb-data: breaks Multi_key, a.k.a. Compose key

[Vincent Lefevre]

Control: retitle -1 The drop of Multi_key for gb in xkb-data 2.33 should be 
announced in NEWS.Debian

following my comment:

On 2021-09-10 15:06:40 +0200, Vincent Lefevre wrote:
> This is apparently due to the following upstream change. But this is
> the kind of thing that should be announced in NEWS.Debian.
> 
> commit 5ac82bfc696213eb24759bf81670bca21d122da3
> Author: M Hickford 
> Date:   2021-02-20 21:16:56 +0100
> 
> Simplify gb(basic) so that Shift+Right Alt behaves the same as Right 
> Alt+Shift. Resolves #245
> 
> For the old behaviour, use `setxkbmap -option lv3:ralt_switch_multikey`

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

Bug#743694: lintian: Downgrade most of privacy-breach* tags from severity: error to pedantic

[Daniel Leidert]

Am Freitag, dem 10.09.2021 um 15:10 +0200 schrieb Bill Allombert:
> On Fri, Sep 10, 2021 at 02:41:20PM +0200, Daniel Leidert wrote:
> > Am Freitag, dem 10.09.2021 um 13:56 +0200 schrieb Bill Allombert:

[..]
> > > Lintian errors do not by themselves create more work to package
> > > maintainers since they can be ignored,
> > 
> > a) This is untrue. To put packages through NEW they have to be lintian
> > clean.
> 
> Is it actually the case ?  This is not my experience.

Citing the Reject FAQ:

Lintian errors and warnings, without a good reason to ignore them, can get you
a reject. Sometimes there are valid reasons, but then you should either file a
bug against lintian if it's generally wrong, or include an override in your
package, giving a reason in the changelog for it.

I have seen it (and I would doubt our FTP masters if they accept packages with
lintian errors TBH). I filed a bug because I believe the severity is wrong.

https://bugs.debian.org/743649#13

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

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


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

Bug#743694: lintian: Downgrade most of privacy-breach* tags from severity: error to pedantic

[Bill Allombert]

On Fri, Sep 10, 2021 at 02:41:20PM +0200, Daniel Leidert wrote:
> I'm not sure why this x-post over a dozen addresses, but if you wish so...
> 
> Am Freitag, dem 10.09.2021 um 13:56 +0200 schrieb Bill Allombert:
> > On Fri, Sep 10, 2021 at 04:05:32AM -0700, Felix Lechner wrote:
> > > Hi,
> > > 
> > > > The severity chosen for these tags/checks is not justified by any of our
> > > > policies, neither the Debian policy, not the best packaging practises 
> > > > nor
> > > > any legal reason!
> > > > 
> > > > There is no technical nor social justification for this severity.
> > > > 
> > > > making our package compliant to this new privacy-policy doesn't add
> > > > any value to our users.
> 
> [snip]
> 
> > Thanks for taking this stance. Phoning home without the user consent has
> > always been treated as a RC bug.
> 
> Please provide examples.
> 
> > Lintian errors do not by themselves create more work to package
> > maintainers since they can be ignored,
> 
> a) This is untrue. To put packages through NEW they have to be lintian clean.

Is it actually the case ?  This is not my experience.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#743694: lintian: Downgrade most of privacy-breach* tags from severity: error to pedantic

[Daniel Leidert]

Same here, no idea why this x-post over so mayn addresses...

Am Freitag, dem 10.09.2021 um 04:05 -0700 schrieb Felix Lechner:
> 
> > The severity chosen for these tags/checks is not justified by any of our
> > policies, neither the Debian policy, not the best packaging practises nor
> > any legal reason!
> > 
> > There is no technical nor social justification for this severity.
> > 
> > making our package compliant to this new privacy-policy doesn't add
> > any value to our users.
> 
> I believe Debian users have a reasonable expectation to read static
> files on their own storage media without being monitored. That
> objection is based on my own everyday experience in working to improve
> Debian, the Golden rule [2] and item #4 of Debian's social contract
> ("Our priorities are our users"). [2]

If you are *that* concerned about the privacy breaches created by websites
contacting servers you have already configured your whole system to deal with
that. And then this whole thing here does not add any value. It also doesn't
add much value to other users less concerned either, because we only change a
few HTML sites while they are still tracked by hundreds of cookies while
browsing websites or reading mails.

It just creates burden on fellow developers. While we have often found
reasonable solutions (e.g. packaging javascript libraries and using them
instead of web resources), I don't think this here is one of them. IIRC I got
this error because of a donation request a software author made in their
software using an icon at an online resource. I am not willing to remove or
cripple that. If you are, well, then better come up with a solution for these
cases.

FTR: What I see is not users requesting this. What I see is a small group of
developers which made that their objective and try to enforce that objective by
misusing lintian to produce error messages instead of messages with a justified
priority.

> 
[..]
> I will likely close this bug without action.

Well, then I bring this to the TC's attention. I believe your actions aren't
justified.


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

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


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

Bug#743694: lintian: Downgrade most of privacy-breach* tags from severity: error to pedantic

[Daniel Leidert]

I'm not sure why this x-post over a dozen addresses, but if you wish so...

Am Freitag, dem 10.09.2021 um 13:56 +0200 schrieb Bill Allombert:
> On Fri, Sep 10, 2021 at 04:05:32AM -0700, Felix Lechner wrote:
> > Hi,
> > 
> > > The severity chosen for these tags/checks is not justified by any of our
> > > policies, neither the Debian policy, not the best packaging practises nor
> > > any legal reason!
> > > 
> > > There is no technical nor social justification for this severity.
> > > 
> > > making our package compliant to this new privacy-policy doesn't add
> > > any value to our users.

[snip]

> Thanks for taking this stance. Phoning home without the user consent has
> always been treated as a RC bug.

Please provide examples.

> Lintian errors do not by themselves create more work to package
> maintainers since they can be ignored,

a) This is untrue. To put packages through NEW they have to be lintian clean.

b) So what you are saying is, that I can ignore these? So then WHY make this a
serious offense then? Why not downgrade the severity as I have requested?

Again: The severity is not backed up by any of our policies. Please proove your
point if you disagree. Instead it is IMHO a personal objective that is forced
onto developers by a severity that is not justified by our policy.

And once again: What is the sense and what right do we have to remove donation
requests just because they use icons of paypal/patreon/github/whatever which we
cannot distribute?

> instead they present an
> advance warning of a potential bug report about privacy violation,
> which can save time unless the maintainers plan was to hide the issue
> under the carpet which contradict SC #3 "we will not hide problems".

This rule of the SC refers to something completely different. Please don't
misuse the SC for your personal objectives.

But JFTR: Ignoring this bug report with the other one for 7 years smells a lot
more like "hiding/ignoring the issue".

Neither of the reports requested to remove the affected tags. It was requested
to lower the severity as the chosen severity is not justified.

Regards, Daniel


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

Bug#994038: RM: ncl [i386] -- RoQA; FTBFS, blocks gdal transition

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal

Please remove ncl from i386 where it FTBFS as part of the gdal transition.

Kind Regards,

Bas

Bug#994037: xkb-data: TWO_LEVEL is not available

[Vincent Lefevre]

Package: xkb-data
Version: 2.33-1
Severity: important

On one of my machines:

cventin:~> cat .xkb/keymap/custom
xkb_keymap {
xkb_keycodes  { include "evdev+aliases(qwerty)" };
xkb_types { include "complete"  };
xkb_compat{ include "complete"  };
xkb_symbols   { include "pc+gb+inet(evdev)+local"   };
xkb_geometry  { include "pc(pc105)" };
};

cventin:~> cat .xkb/symbols/local
xkb_symbols "local" {
key  {
type = "TWO_LEVEL",
symbols[Group1] = [ ISO_Level3_Shift, Multi_key ]
};
};

cventin:~> xkbcomp -w 0 -I$HOME/.xkb -R$HOME/.xkb keymap/custom $DISPLAY
Internal error:   Could not resolve keysym XF86BrightnessAuto
Internal error:   Could not resolve keysym XF86DisplayOff
[...]
Internal error:   Could not resolve keysym XF86KbdLcdMenu4
Internal error:   Could not resolve keysym XF86KbdLcdMenu5
X Error of failed request:  BadValue (integer parameter out of range for 
operation)
  Major opcode of failed request:  135 (XKEYBOARD)
  Minor opcode of failed request:  9 (XkbSetMap)
  Value in failed request:  0x166c0002
  Serial number of failed request:  120
  Current serial number in output stream:  126

The internal errors are unrelated. The real issue is the BadValue.
If I change TWO_LEVEL to ONE_LEVEL, the error disappears (but I
don't get the second level).

There is no such issue with xkb-data 2.29-2.

Note: it is TWO_LEVEL that yields the error, not Multi_key (if I replace
Multi_key by a second ISO_Level3_Shift, I still get the error).

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

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

-- no debconf information

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

Bug#994036: xkb-data: gives lots of internal errors with xkbcomp on XF86* keysyms

[Vincent Lefevre]

Package: xkb-data
Version: 2.33-1
Severity: normal

On one of my machines, with a default configuration:

cventin:~> cat .xkb/keymap/custom
xkb_keymap {
xkb_keycodes  { include "evdev+aliases(qwerty)" };
xkb_types { include "complete"  };
xkb_compat{ include "complete"  };
xkb_symbols   { include "pc+gb+inet(evdev)" };
xkb_geometry  { include "pc(pc105)" };
};

cventin:~> xkbcomp -w 0 -I$HOME/.xkb -R$HOME/.xkb keymap/custom $DISPLAY
Internal error:   Could not resolve keysym XF86BrightnessAuto
Internal error:   Could not resolve keysym XF86DisplayOff
Internal error:   Could not resolve keysym XF86Info
Internal error:   Could not resolve keysym XF86AspectRatio
Internal error:   Could not resolve keysym XF86DVD
Internal error:   Could not resolve keysym XF86Audio
Internal error:   Could not resolve keysym XF86ChannelUp
Internal error:   Could not resolve keysym XF86ChannelDown
Internal error:   Could not resolve keysym XF86Break
Internal error:   Could not resolve keysym XF86VideoPhone
Internal error:   Could not resolve keysym XF86ZoomReset
Internal error:   Could not resolve keysym XF86Editor
Internal error:   Could not resolve keysym XF86GraphicsEditor
Internal error:   Could not resolve keysym XF86Presentation
Internal error:   Could not resolve keysym XF86Database
Internal error:   Could not resolve keysym XF86Voicemail
Internal error:   Could not resolve keysym XF86Addressbook
Internal error:   Could not resolve keysym XF86DisplayToggle
Internal error:   Could not resolve keysym XF86SpellCheck
Internal error:   Could not resolve keysym XF86ContextMenu
Internal error:   Could not resolve keysym XF86MediaRepeat
Internal error:   Could not resolve keysym XF8610ChannelsUp
Internal error:   Could not resolve keysym XF8610ChannelsDown
Internal error:   Could not resolve keysym XF86Images
Internal error:   Could not resolve keysym XF86NotificationCenter
Internal error:   Could not resolve keysym XF86PickupPhone
Internal error:   Could not resolve keysym XF86HangupPhone
Internal error:   Could not resolve keysym XF86Fn
Internal error:   Could not resolve keysym XF86Fn_Esc
Internal error:   Could not resolve keysym XF86FnRightShift
Internal error:   Could not resolve keysym XF86Numeric0
Internal error:   Could not resolve keysym XF86Numeric1
Internal error:   Could not resolve keysym XF86Numeric2
Internal error:   Could not resolve keysym XF86Numeric3
Internal error:   Could not resolve keysym XF86Numeric4
Internal error:   Could not resolve keysym XF86Numeric5
Internal error:   Could not resolve keysym XF86Numeric6
Internal error:   Could not resolve keysym XF86Numeric7
Internal error:   Could not resolve keysym XF86Numeric8
Internal error:   Could not resolve keysym XF86Numeric9
Internal error:   Could not resolve keysym XF86NumericStar
Internal error:   Could not resolve keysym XF86NumericPound
Internal error:   Could not resolve keysym XF86NumericA
Internal error:   Could not resolve keysym XF86NumericB
Internal error:   Could not resolve keysym XF86NumericC
Internal error:   Could not resolve keysym XF86NumericD
Internal error:   Could not resolve keysym XF86CameraFocus
Internal error:   Could not resolve keysym XF86WPSButton
Internal error:   Could not resolve keysym XF86CameraZoomIn
Internal error:   Could not resolve keysym XF86CameraZoomOut
Internal error:   Could not resolve keysym XF86CameraUp
Internal error:   Could not resolve keysym XF86CameraDown
Internal error:   Could not resolve keysym XF86CameraLeft
Internal error:   Could not resolve keysym XF86CameraRight
Internal error:   Could not resolve keysym XF86AttendantOn
Internal error:   Could not resolve keysym XF86AttendantOff
Internal error:   Could not resolve keysym XF86AttendantToggle
Internal error:   Could not resolve keysym XF86LightsToggle
Internal error:   Could not resolve keysym XF86ALSToggle
Internal error:   Could not resolve keysym XF86Buttonconfig
Internal error:   Could not resolve keysym XF86Taskmanager
Internal error:   Could not resolve keysym XF86Journal
Internal error:   Could not resolve keysym XF86ControlPanel
Internal error:   Could not resolve keysym XF86AppSelect
Internal error:   Could not resolve keysym XF86Screensaver
Internal error:   Could not resolve keysym XF86VoiceCommand
Internal error:   Could not resolve keysym XF86Assistant
Internal error:   Could not resolve keysym XF86BrightnessMin
Internal error:   Could not resolve keysym XF86BrightnessMax
Internal error:   Could not resolve keysym XF86KbdInputAssistPrev
Internal error:   Could not resolve keysym XF86KbdInputAssistNext
Internal error:   Could not resolve keysym XF86KbdInputAssistPrevgroup
Internal error:   Could not resolve keysym XF86KbdInputAssistNextgroup
Internal error:   Could not resolve keysym XF86KbdInputAssistAccept
Internal error:   Could not resolve keysym XF86KbdInputAssistCancel
Internal error:   Could not resolve keysym XF86RightUp
Internal error:   Could not resolve keysym