date:20230301

Package: wnpp
Owner: Yaroslav Halchenko , Vasyl Gello 

Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: datalad-deprecated
  Version : 0.2.8
  Upstream Author : DataLad Project Authors
* URL : https://datalad-deprecated.rtfd.org
* License : MIT
  Programming Lang: Python
  Description : DataLad extension for phased-out functionality

This extension provides deprecated modules for DataLad (https://datalad.org)
like web interface running on https://datasets.datalad.org

-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#1032230: ITP: datalad-deprecated -- DataLad extension for phased-out functionality

Package: wnpp
Owner: Yaroslav Halchenko , Vasyl Gello 

Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: datalad-deprecated
  Version : 0.2.8
  Upstream Author : DataLad Project Authors
* URL : https://datalad-deprecated.rtfd.org
* License : MIT
  Programming Lang: Python
  Description : DataLad extension for phased-out functionality

This extension provides deprecated modules for DataLad (https://datalad.org)
like web interface running on https://datasets.datalad.org

Bug#1032140: [External] Re: Bug#1032140: Lenovo Z16 Install issue

2023-03-01 Thread David Ober

Not the result I was expecting, here is the dmesg logs where it still failed to 
load the firmware


[   26.626868] ath11k_pci :04:00.0: BAR 0: assigned [mem 
0xb000-0xb01f 64bit]
[   26.627223] ath11k_pci :04:00.0: MSI vectors: 32
[   26.627228] ath11k_pci :04:00.0: wcn6855 hw2.1
[   26.630080] NET: Registered PF_QIPCRTR protocol family
[   26.785089] mhi mhi0: Requested to power ON
[   26.785102] mhi mhi0: Power on setup success
[   26.785400] mhi mhi0: firmware: failed to load ath11k/WCN6855/hw2.1/amss.bin 
(-2)
[   26.785407] firmware_class: See https://wiki.debian.org/Firmware for 
information about missing firmware
[   26.785422] mhi mhi0: firmware: failed to load ath11k/WCN6855/hw2.1/amss.bin 
(-2)
[   26.785425] mhi mhi0: Direct firmware load for ath11k/WCN6855/hw2.1/amss.bin 
failed with error -2
[   26.785430] mhi mhi0: Error loading firmware: -2
[   26.785589] ath11k_pci :04:00.0: failed to power up mhi: -110
[   26.785596] ath11k_pci :04:00.0: failed to start mhi: -110
[   26.785600] ath11k_pci :04:00.0: failed to power up :-110
[   26.820002] ath11k_pci :04:00.0: failed to create soc core: -110
[   26.820018] ath11k_pci :04:00.0: failed to init core: -110
[   27.036908] ath11k_pci: probe of :04:00.0 failed with error -110

David

-Original Message-
From: Cyril Brulebois  
Sent: Wednesday, March 1, 2023 3:23 AM
To: 1032...@bugs.debian.org
Cc: David Ober ; Steve McIntyre ; 
debian-ker...@lists.debian.org
Subject: Re: Bug#1032140: [External] Re: Bug#1032140: Lenovo Z16 Install issue

Control: reassign -1 src:linux 6.1.12-1
Control: forwarded -1 
https://salsa.debian.org/kernel-team/linux/-/merge_requests/667
Control: tag -1 patch

Cyril Brulebois  (2023-03-01):
> Thanks for this confirmation, I'll file the MR against linux later on.

Doing so now.


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

Bug#1032229: ITP: datalad-gooey -- Simple Graphical User Interface (GUI) for DataLad

Package: wnpp
Owner: 
Yaroslav Halchenko ,
Vasyl Gello 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: datalad-gooey
  Version : 0.2.0
  Upstream Author : DataLad Project Authors
* URL : https://datalad-gooey.rtfd.org
* License : MIT
  Programming Lang: Python
  Description : Simple Graphical User Interface (GUI) for DataLad

This extension provides a graphical user interface (GUI)
for DataLad (http://datalad.org).

It is specifically aiming at making key data management tasks more accessible
and more convenient, without requiring to become familiar with the command line.

This simplified interface to DataLad is built on a foundation that is capable
of providing graphical user interfaces for any DataLad command, including those
provided by extension packages. Moreover, extension packages can even provide
their own GUI suites, by mixing and tuning a custom set of commands and
parameters.

To try it out, install this package, and run `datalad gooey`.

Bug#1032228: ITP: datalad-fuse -- User-mode filesystem DataLad extension

Package: wnpp
Owner: 
Yaroslav Halchenko ,
Vasyl Gello 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: datalad-fuse
  Version : 0.4.2
  Upstream Author : DataLad Project Authors
* URL : https://datalad-fuse.rtfd.org
* License : MIT
  Programming Lang: Python
  Description : User-mode filesystem DataLad extension

This extension provides filesystems in userspace (FUSE) extension
for DataLad (http://datalad.org)

Bug#1032138: prometheus-snmp-exporter: generator doesn't honour snmp.conf, so it misses site-specific MIBs

On Thu, Mar 02, 2023 at 01:35:29PM +1300, Daniel Swarbrick wrote:
> It looks kinda odd to me. I don't recall ever including the MIB name in the
> list of objects to walk. Have you tried simply:

Yes, that is also, weirdly, broken (inasmuch I personally expected any
net-snmp OID spec you can put into read_objid(3) to be legal,
and MIB::oid is, like, the most canonical one, AIUI).

MIBDIRS=/usr/share/snmp/mibs:/usr/share/snmp/mibs/iana:/usr/share/snmp/mibs/ietf:/usr/local/share/snmp/mibs
\
MIBS=+ORNO-MIB prometheus-snmp-generator generate

Which, y'know, great, but I already have that in snmp.conf,
and all other libsnmp programs understand that
(defined as "my godawful libsnmp program does and i do the barest
minimum of libsnmp setup (i.e. just netsnmp_parse_args()),
and so does snmpbulkwalk(1) ").

So I guess what I originally expected is "p-s-g loads the snmp config"
and what I got was "it doesn't". Doesn't help that the READMEs don't
mention this. I guess the manual doesn't explicitly say it does,
but the manual is a usage string, so that hardly means anything.

On re-reading
/usr/share/doc/prometheus-snmp-exporter/generator/README.md.gz
I do notice the ‒ I think ‒ only thing that mentions MIBDIRS:
-- >8 --
## Running

```sh
export MIBDIRS=mibs
./generator generate
```

The generator reads in from `generator.yml` and writes to `snmp.yml`.

Additional command are available for debugging, use the `help` command to see
them.
-- >8 --
but, y'know, that overrides the MIB location to ./mibs for running
in-tree, which is not what anyone wants to do,
and I only noticed it because I was looking for it.

I didn't really see anything in the changelog that would imply anything
has changed in this regard, and my only sid system is x32, which you
don't build for, apparently. But from what I'd gotten out of the config
I did manage to generate, p-s-e is not the right tool for my use-case,
so it doesn't really matter either way.

Best,
наб

signature.asc
Description: PGP signature

Bug#1031928: python3-django-hyperkitty: Javascript not loaded because of HTML error

Package: python3-django-hyperkitty
Followup-For: Bug #1031928
X-Debbugs-Cc: h...@hjp.at
Control: tags -1 moreinfo

Hi Peter,

I'd like to gain some experience with configuring email infrastructure, and
this bug seems like a good opportunity to learn.

I haven't yet been able to reproduce the self-closing HTML script tags; here's
roughly the series of install steps I used (I may have omitted one or two
details) to get the interface up-and-running:

  # apt install mailman3-full
  # vim /etc/mailman3/mailman-web.py  # configure REST API creds
  # ln -s /etc/mailman3/apache.conf /etc/apache2/conf-available/mailman3.conf
  # a2enconf mailman3
  # a2enmod proxy_uwsgi
  # systemctl restart mailman3-web
  # systemctl restart apache2

(note that I also had postfix utilities installed on the system)

That seemed to work: I was able to browse the postorius web interface and see
that I had no mailing lists configured.

Checking the HTML source of the page, I did see some  tags -- including
for 'popper.js' -- each of them had a closing  tag, as expected.

Could you provide any more information on configuration steps / settings that
may be required to reproduce the problem?

Thanks!
James

Bug#1032227: Mention instead pic.txt

2023-03-01 Thread Dan Jacobson

Package: groff-base
Version: 1.22.4-9
Severity: minor
File: /usr/share/man/man1/pic.1.gz

We read

> A complete documentation is available in the file

> /usr/share/doc/groff-base/pic.ms.gz

Say /usr/share/doc/groff/pic.txt.gz

Else nobody can figure out how to read it, as they need to read it to be
able to figure out how to read it.

Bug#1032226: ITP: datalad-next -- Preview functionaity extension for DataLad

Package: wnpp
Owner: 
Yaroslav Halchenko ,
Vasyl Gello 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: datalad-next
  Version : 1.0.0~beta1
  Upstream Author : DataLad Project Authors
* URL : https://datalad-gooey.rtfd.org
* License : MIT
  Programming Lang: Python
  Description : Preview functionaity extension for DataLad

This extension provides the preview functionality extension
for DataLad (http://datalad.org).

It will eventually be merged into core DataLad codebase

Bug#1032225: Graph::Easy::Manual not found

2023-03-01 Thread Dan Jacobson

Package: libgraph-easy-perl
Version: 0.76-3
Severity: minor

We see
> Please see Graph::Easy::Manual for a full description of the syntax rules.
But that file is missing.

Bug#1031969: workaround

2023-03-01 Thread Sam Watkins

FWIW, I used the following hacky workaround for the moment:

Create a file: python3.10-distutils-bogus:

Section: python
Priority: optional
Standards-Version: 3.9.2

Package: python3.10-distutils-bogus
Version: 1.0
Maintainer: Sam Watkins 
Provides: python3.10-distutils
Description: Dummy package to satisfy python3.10-distutils

Run:

equivs-build python3.10-distutils
dpkg -i
sudo dpkg -i python3.10-distutils-bogus_1.0_all.deb
sudo apt install python3.10-venv

It does seem to work okay to create venvs.

Bug#1030857: verification issue

2023-03-01 Thread Barak A. Pearlmutter

Okay, I cherry-picked upstream commits 487cc27e1..d21a3b622, the
endpoint being the current upstream/main, and built, and installed,
and it seems to solve this problem. The "no bencoded data to parse"
messages are gone. And things verify upon request, with most of them
succeeding. A few failed to verify even though they are absolutely
downloaded; these are all single file torrents, instead of a directory
containing files. So that's a clue as to the bug, I suppose.

Anyway, this issue does seem at least mostly fixed upstream post-release.

Bug#1032138: prometheus-snmp-exporter: generator doesn't honour snmp.conf, so it misses site-specific MIBs

2023-03-01 Thread Daniel Swarbrick

Ah, my mistake, I did not notice that you already included your 
generator.yml:


modules:
  orno_or_we_504_505_507:
    walk:
  - ORNO-MIB::orno

It looks kinda odd to me. I don't recall ever including the MIB name in 
the list of objects to walk. Have you tried simply:


modules:
  orno_or_we_504_505_507:
    walk:
  - orno

(cf: 
https://github.com/prometheus/snmp_exporter/tree/main/generator#file-format)




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032202: New buttercup_eval directive

2023-03-01 Thread Sean Whitton

Hello,

On Wed 01 Mar 2023 at 10:51AM -05, Sergio Durigan Junior wrote:

> I would like to propose the inlined patch to implement a new
> buttercup_eval directive on dh-elpa.  Aside from the fact that this is a
> good-to-have feature, there is a bigger problem at play here: it's
> currently not possible to eval elisp code when buttercup is invoked
> during autopkgtest, which makes workarounds like the one uploaded for
> flycheck (at bug #1028725) incomplete.
>
> It'd be great if we could have this in bookworm, but due to the freeze
> I'd understand if it's not possible.  I'd like to have this in unstable
> ASAP, though, if that's OK with you.

If it is only for autopkgtests or similar, I don't think it's
appropriate for this stage of the freeze -- we can just disable the
relevant tests.  Thanks for the patch -- please ping once the next
release cycle opens up.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1032138: prometheus-snmp-exporter: generator doesn't honour snmp.conf, so it misses site-specific MIBs

2023-03-01 Thread Daniel Swarbrick

I don't currently use prometheus-snmp-exporter, however I have used it 
extensively in the past, and never encountered any problems with the 
generator loading third-party MIBs.


Most maintainers (including myself) are currently focused on fixing bugs 
in the upcoming bookworm release, so unless you can also demonstrate 
that this is an issue with prometheus-snmp-exporter 0.21.0-1, this bug 
is not likely to get a very prompt resolution. If the bug _is_ still 
present in the latest upstream version, you may have more success 
reporting the bug upstream, especially since it is not likely to be 
Debian-specific.


Can you at least include your generator.yml in this bug report?




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1030857: testing

2023-03-01 Thread Barak A. Pearlmutter

Okay, I installed the package generated by 16c2e55a0 in my repo, which
is a 4.0.1-1 candidate. It seems to work okay EXCEPT ...

(a) is kicks out messages like this

Feb 26 21:49:35 sweat transmission-daemon[1174]: [2023-02-26
21:49:35.396] ERR torrent-metainfo.cc:630 no bencoded data to parse
(84) (./libtransmission/torrent-metainfo.cc:630)
Feb 26 21:49:35 sweat transmission-daemon[1174]: [2023-02-26
21:49:35.396] ERR torrent-metainfo.cc:630 no bencoded data to parse
(84) (./libtransmission/torrent-metainfo.cc:630)
Feb 26 21:49:35 sweat transmission-daemon[1174]: [2023-02-26
21:49:35.396] ERR torrent-metainfo.cc:630 no bencoded data to parse
(84) (./libtransmission/torrent-metainfo.cc:630)
Feb 26 21:49:35 sweat transmission-daemon[1174]: [2023-02-26
21:49:35.396] ERR torrent-metainfo.cc:630 no bencoded data to parse
(84) (./libtransmission/torrent-metainfo.cc:630)
Feb 26 21:49:35 sweat transmission-daemon[1174]: [2023-02-26
21:49:35.396] ERR torrent-metainfo.cc:630 no bencoded data to parse
(84) (./libtransmission/torrent-metainfo.cc:630)
Feb 26 21:49:35 sweat transmission-daemon[1174]: [2023-02-26
21:49:35.396] ERR torrent-metainfo.cc:630 no bencoded data to parse
(84) (./libtransmission/torrent-metainfo.cc:630)
Feb 26 21:49:35 sweat transmission-daemon[1174]: [2023-02-26
21:49:35.396] ERR torrent-metainfo.cc:630 no bencoded data to parse
(84) (./libtransmission/torrent-metainfo.cc:630)
Feb 26 21:49:35 sweat transmission-daemon[1174]: [2023-02-26
21:49:35.396] ERR torrent-metainfo.cc:630 no bencoded data to parse
(84) (./libtransmission/torrent-metainfo.cc:630)

And, it is refusing to verify a whole bunch of stuff that to my
knowledge was already downloaded just fine under 3.x. It just lists
them as 0%. Hitting "verify" on them does nothing, nor does resume or
re-announce. Some of them list as downloading; of those, sometimes one
wakes up and verifies and jumps to seeding.

No idea what's going on.

Not sure this is a sufficient show-stopper to preclude uploading this
version, but thought I'd mention it.

Looking at the post-release upstream commits, I suspect some may
address this. I could try cherry-picking some of those commits, or
maybe just merging the development tip, and seeing if that fixes the
problem. Or, maybe we should wait for 4.0.2 which might address this
properly? Is anyone in touch with upstream? It might help to get their
take, find out if they're going to do a point release fixing this
stuff sometime soon.

Bug#1031909: python3-tk: bytecode not removed on upgrade

Package: python3-tk
Followup-For: Bug #1031909

Some notes from inspecting (but not yet testing) the relevant scripts:

  * There is an open merge request intended to fix a bug when too-many-files
are encountered by the lib2to3 'prerm' script:

* https://salsa.debian.org/cpython-team/python3-stdlib/-/merge_requests/1



  * The python3-distutils and python3-lib2to3 packages have prerm 'upgrade'
steps to remove bytecode; python3-tk does not:

* 
https://salsa.debian.org/cpython-team/python3-stdlib/-/blob/519a4643ba82ffd035827df37002c64853d4913b/debian/python3-distutils.prerm#L27-28

* 
https://salsa.debian.org/cpython-team/python3-stdlib/-/blob/519a4643ba82ffd035827df37002c64853d4913b/debian/python3-lib2to3.prerm#L27-28

* 
https://salsa.debian.org/cpython-team/python3-stdlib/-/blob/519a4643ba82ffd035827df37002c64853d4913b/debian/python3-tk.prerm#L27



  * All three of the previously-mentioned binary packages clear out
py3.9-and-older library content during 'postinst' of more recent package
versions; a similar step for py3.10 library content could be worth adding

* 
https://salsa.debian.org/cpython-team/python3-stdlib/-/blob/519a4643ba82ffd035827df37002c64853d4913b/debian/python3-lib2to3.postinst.in#L22-41

Bug#1032137: ITP: python-hardware -- hardware detection and classification utilities

2023-03-01 Thread Thomas Goirand


On 3/1/23 17:20, Antoine Beaupré wrote:

On 2023-02-28 15:18:33, Thomas Goirand wrote:

* Package name: python-hardware
   Description : hardware detection and classification utilities

  Detect hardware features of a Linux systems:
   * RAID
   * hard drives
   * IPMI
   * network cards
   * DMI infos
   * memory settings
   * processor features
  .
  Filter hardware according to hardware profiles.


Oh, this is interesting! There's very little documentation on the
upstream site, what do you plan on using this for?

It looks like a library I could very well use to rewrite stressant
into something more sane... It seems it even has benchmarks...

Thanks for any clarification!


Hi,

FYI, that's a dependency of ironic-python-agent [1], which does hardware 
discovery and image install for Ironic. I've just uploaded both packages 
and I intend to deploy my first Ironic-enabled cloud soonish. :)


Cheers,

Thomas Goirand (zigo)

[1] https://opendev.org/openstack/ironic-python-agent

Bug#1032223: fbb: Segmentation fault when listing subdirectories using FBBDOS

2023-03-01 Thread Mike Quin

Package: fbb
Version: 7.011-1
Severity: normal
X-Debbugs-Cc: m...@elite.uk.com

Dear Maintainer,

I've run into a crash bug when using the FBBDOS feature of fbb.

Using the 'DIR' command to list files works in FBBDOS's root directory.
If any non-empty subdirectory is entered with the 'CD' command, as subsequent
'DIR' will crash fbb.

Additionally, where 'DIR' does work, the file sizes and date stamps are wrong.

---
01-Mar-23 22:52  FBBDOS V7.0.11

Format :
(1)= (1 connected station)
[543/0kb] = [downloaded 543kb until now/max allowed 0kb] in this period
C:\>   = drive and path (like in MSDOS)

(1) [543/0kb] C:\>dir
   8 11-10-59 changelog.Debian
 524158 M 11-02-20 yapp
25734537216 bytes free.

(1) [543/0kb] C:\>cd yapp

(1) [543/0kb] C:\yapp>dir
---

Running xfbbd in gdb produced the following:

---
Program received signal SIGSEGV, Segmentation fault.
0x0058e9d4 in format_ffblk (blk=blk@entry=0x6be050, 
dir=dir@entry=0x747de8) at ./src/ibm.c:232
232 year = tm->tm_year %100;

(gdb) backtrace -full 1
#0  0x0058e9d4 in format_ffblk (blk=blk@entry=0x6be050, 
dir=dir@entry=0x747de8) at ./src/ibm.c:232
year = 
st = {st_dev = 366505350216, st_ino = 366504693376, st_mode = 
4294963176, st_nlink = 127, st_uid = 4294963179, st_gid = 127, st_rdev = 
549755810520, __pad1 = 549755810476, st_size = 8, st_blksize = -48, __pad2 = 
-128, st_blocks = 366504644080, st_atim = {tv_sec = 363676312022575, 
tv_nsec = 7090406762945589045}, st_mtim = {tv_sec = 7023696974707647586, 
tv_nsec = -1098803875728}, st_ctim = {tv_sec = 549683298305, tv_nsec = 
366504662168}, __glibc_reserved = {1432442871, 85}}
tm = 0x0
base = 
"\222TaUU\000\000\000\222TaUU\000\000\000\222TaUU\000\000\000\222TaUU\000\000\000\367WaUU\000\000\000\260\353\377\377\177\000\000\000l\360\334\367\177\000\000\000\000\000\356\367\177\000\000\000`\307\376\367\177\000\000\000\060\200\000\000\000\000\000\000X\000\000\000\000\000\000\000\000`\356\367\177\000\000\000\270\307\376\367\177\000\000\000\330\362\377\377\177\000\000\000\254\362\377\377\177\000\000\000\b\000\000\000\000\000\000",
 
ext = "\222TaU"
filename = 
"/var/ax25/fbb/fbbdos//yapp/test\000\360\353\377\377\177\000\000\000\064D\337\367\177\000\000\000\n\000\000\000\000\000\000\000\000\200\000\000\000\000\000\000X\340kUU\000\000\000\070\360\377\377\177\000\000\000\350\357\377\377\177\000\000\000\353\357\377\377\177\000\000\000\240\354\377\377\177\000\000\000P\353XUU\000\000\000\200\250aUU\000\000\000P\340kUU\000\000\000\060\354\377\377\177\000\000\000\002\263\000\000\000\000\000\000\034\016\002\000\000\000\000\000\355A\000\000\002\000\000\000\353\003\000\000\353\003",
 '\000' , 
"\020\000\000\000\000\000\000\240\354\377\377\177\000\000\000"...
---

I was able to produce an xfbbd binary that could perform the above operaiton 
without crashing by using 
DEB_CFLAGS_SET=-D_GNU_SOURCE , but I don't know if that will have wider 
consequences. The file sizes 
and dates returned by 'DIR' are still wrong but, oddly, different.

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 6.1.13-v8+ (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fbb depends on:
ii  libax25  0.0.12-rc5+git20190411+b17ff36-4+b1
ii  libc62.36-8
ii  libncurses6  6.4-2
ii  libtinfo66.4-2

fbb recommends no packages.

fbb suggests no packages.

-- no debconf information

Bug#1031324: crowdsec: 404 on cscli hub update

2023-03-01 Thread Cyril Brulebois

Control: tag -1 pending

Cyril Brulebois  (2023-02-14):
> The crowdsec binary package comes with a copy of hub files (“offline
> hub”) so that it's immediately useful. It's also possible to switch
> to using the “online hub” by running:
> 
> cscli hub update
> 
> With 1.4.2-1, an error is returned:
> 
> Failed to get Hub index : failed to download index: bad http code 404 
> while requesting https://hub-cdn.crowdsec.net/1.4.2/.index.json
> 
> I'll ask upstream to help debug this issue but since we have a copy
> shipped in the package, this seems to be important at most.

Apparently upstream needs to do something specific for each upstream
release that's getting packaged into Debian (so that the version we're
reporting — according to the version spec they requested — matches
something that's available on the hub).

That happened for v1.4.2 already, and the same needs to happen for
v1.4.6.

That doesn't require any code change in the package.

Marking with pending anyway, since that's about to be fixed upstream
(and documented as a known requirement so that they remember to do that
for later versions).


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature

Bug#1026539: How much do we lose if we remove theano (+keras, deepnano, invesalius)?

2023-03-01 Thread Rebecca N. Palmer

I agree that switching to Aesara is probably the only reasonable option 
other than removal.  (I'd given up on trying to fix 1.0, and was 
intending to let removal happen.)


However, it's a much bigger change than is normally allowed in bookworm 
at this point.  (1.1 includes multiple breaking changes, which is why 
it's in experimental, but a quick codesearch suggests these parts *may* 
not be used in keras/deepnano. 
https://github.com/aesara-devs/aesara/releases?page=8 )


Do you want to ask release team for permission to do this?  Or do you 
want to try the same patches on 1.0?  (I suspect that that won't work, 
but I haven't actually tried it.)


(Also, you might not want numpy1p24_compat.patch - the v1p0 branch is 
currently in whatever state it was in when I gave up on it, and my vague 
memory is that this was a failed experiment, though I don't know if that 
meant "actively bad" or just "not a (full) solution".)

Bug#1032222: zulucrypt-gui: Fail to mount hidden volume since upgrade from 5.7.1-2 to 6.2.0-1

2023-03-01 Thread Francois Le Hir

Package: zulucrypt-gui
Version: 5.7.1-2
Severity: important
X-Debbugs-Cc: fle...@yahoo.com

Dear Maintainer,

On Feb 11th 2023 I upgraded the following packages from 5.7.1-2 to 6.2.0-1 on 
my system when the packages migrated from unstable to testing:
libzulucrypt1.2.0
libzulucrypt-exe1.2.0
libzulucryptpluginmanager1.0.0
zulucrypt-cli
zulucrypt-gui
zulupolkit

Since then, zulucrypt is unable to mount a hiden volume. Mounting the primary 
volume from the same file works fine.
Reverting all 6 packages to 5.7.1-2 solves the issue and I am able to mount 
both volumes from that file again.

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

Kernel: Linux 6.1.0-5-amd64 (SMP w/16 CPU threads; PREEMPT)
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 zulucrypt-gui depends on:
ii  libblkid1   2.38.1-5
ii  libc6   2.36-8
ii  libgcc-s1   12.2.0-14
ii  libgcrypt20 1.10.1-3
ii  libpwquality1   1.4.5-1+b1
ii  libqt5core5a5.15.8+dfsg-2
ii  libqt5gui5  5.15.8+dfsg-2
ii  libqt5network5  5.15.8+dfsg-2
ii  libqt5widgets5  5.15.8+dfsg-2
ii  libsecret-1-0   0.20.5-3
ii  libstdc++6  12.2.0-14
ii  libzulucryptpluginmanager1.0.0  5.7.1-2
ii  zulucrypt-cli   5.7.1-2
ii  zulupolkit  5.7.1-2

zulucrypt-gui recommends no packages.

zulucrypt-gui suggests no packages.

-- no debconf information

Bug#1032221: cryptsetup: libgcc_s.so.1 must be installed for pthread_exit to work

2023-03-01 Thread Kai Weber

As a workaround I created a file /etc/initramfs-tools/hooks/libgcc:

. /usr/share/initramfs-tools/hook-functions
copy_file library /lib/x86_64-linux-gnu/libgcc_s.so.1 
/lib/x86_64-linux-gnu/libgcc_s.so.1

With this hook the lib is copied an I am able to provide a password at
login.

Bug#1032221: cryptsetup: libgcc_s.so.1 must be installed for pthread_exit to work

2023-03-01 Thread Kai Weber

Package: cryptsetup
Version: 2:2.6.1-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: kai.weber+deb...@glorybox.de

Dear Maintainer,

Today's upgrade triggered a rebuild of the initramfs. After a reboot I
can no longer login to my system. Using an older kernel worked. This ist
the error message:

Please unlock disk nvme0n1p3_crypt:
libgcc_s.so.1 must be installed for pthread_exit to work
Aborted
cryptsetup: ERROR: nvme0n1p3_crypt: cryptsetup failed, bad password or options?

Some investigations:

- update-initramfs does indeed not copy libpthread.so or libgcc_s.so
- none of the binaries copied during the update seem to depend on those 
libraries
- attached is the debug output I added to the copy_exec function
  (echo "$src $x" >> /tmp/dependencies.log)

Doing some research I found an older bug #950254 that helped me
debugging the issue


-- Package-specific info:
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.1.0-4-amd64 root=/dev/mapper/dummy--vg-root ro quiet

-- /etc/crypttab
nvme0n1p3_crypt UUID=e9aff144-a836-49d6-8640-01f4b7c3bb8b none luks,discard

-- /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# systemd generates mount units based on this file, see systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
#
/dev/mapper/dummy--vg-root /   ext4errors=remount-ro 0   1
# /boot was on /dev/nvme0n1p2 during installation
UUID=0d9a09b3-abe6-4831-ad3a-166f68e6c77f /boot   ext2defaults  
  0   2
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=D114-FD63  /boot/efi   vfatumask=0077  0   1
/dev/mapper/dummy--vg-swap_1 noneswapsw  0   0

-- lsmod
Module  Size  Used by
snd_usb_audio 376832  1
snd_usbmidi_lib45056  1 snd_usb_audio
snd_rawmidi53248  1 snd_usbmidi_lib
xt_conntrack   16384  1
nft_chain_nat  16384  3
xt_MASQUERADE  20480  1
nf_nat 57344  2 nft_chain_nat,xt_MASQUERADE
nf_conntrack_netlink57344  0
nf_conntrack  188416  4 
xt_conntrack,nf_nat,nf_conntrack_netlink,xt_MASQUERADE
nf_defrag_ipv6 24576  1 nf_conntrack
nf_defrag_ipv4 16384  1 nf_conntrack
xfrm_user  53248  1
xfrm_algo  16384  1 xfrm_user
xt_addrtype16384  2
nft_compat 20480  4
nf_tables 286720  57 nft_compat,nft_chain_nat
libcrc32c  16384  3 nf_conntrack,nf_nat,nf_tables
nfnetlink  20480  4 nft_compat,nf_conntrack_netlink,nf_tables
br_netfilter   32768  0
bridge311296  1 br_netfilter
stp16384  1 bridge
llc16384  2 bridge,stp
typec_displayport  16384  1
ctr16384  2
ccm20480  6
uhid   20480  1
rfcomm 94208  4
cmac   16384  3
snd_seq_dummy  16384  0
snd_hrtimer16384  1
algif_hash 16384  1
snd_seq90112  7 snd_seq_dummy
algif_skcipher 16384  1
snd_seq_device 16384  2 snd_seq,snd_rawmidi
af_alg 36864  6 algif_hash,algif_skcipher
overlay   159744  0
qrtr   49152  4
bnep   28672  2
binfmt_misc24576  1
nls_ascii  16384  1
nls_cp437  20480  1
vfat   24576  1
fat90112  1 vfat
snd_sof_pci_intel_skl16384  0
snd_sof_intel_hda_common   188416  1 snd_sof_pci_intel_skl
soundwire_intel49152  1 snd_sof_intel_hda_common
soundwire_generic_allocation16384  1 soundwire_intel
snd_hda_codec_hdmi 81920  1
soundwire_cadence  40960  1 soundwire_intel
snd_sof_intel_hda  20480  1 snd_sof_intel_hda_common
snd_sof_pci24576  2 snd_sof_intel_hda_common,snd_sof_pci_intel_skl
snd_sof_xtensa_dsp 16384  1 snd_sof_intel_hda_common
iwlmvm385024  0
snd_sof   274432  2 snd_sof_pci,snd_sof_intel_hda_common
snd_ctl_led24576  0
intel_pmc_core_pltdrv16384  0
intel_pmc_core 53248  0
snd_hda_codec_realtek   172032  1
snd_sof_utils  20480  1 snd_sof
soundwire_bus 102400  3 
soundwire_intel,soundwire_generic_allocation,soundwire_cadence
x86_pkg_temp_thermal20480  0
intel_powerclamp   20480  0
snd_hda_codec_generic98304  1 snd_hda_codec_realtek
joydev 28672  0
coretemp   20480  0
mac80211 1171456  1 iwlmvm
snd_soc_skl   184320  0
btusb  65536  0
snd_soc_hdac_hda   24576  2 snd_sof_intel_hda_common,snd_soc_skl
mei_hdcp   24576  0
snd_hda_ext_core   40960  3

Bug#884648: mate-panel occasionally crashes with segfault

2023-03-01 Thread william armstrong


Package: mate-panel
Version: 1.27.0-1
Followup-For: Bug #884648

Dear Maintainer,

Mate-Panel Randomly crashes while changing mate themes and some time it 
crashes
and does not reappear at all until leaving the desktop environment 
unusable and

sometimes alt-F2 key shortcut also does not work after mate-panel crashes


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

Kernel: Linux 6.1.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
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 mate-panel depends on:
ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4
ii libatk1.0-0 2.46.0-5
ii libc6 2.36-8
ii libcairo2 1.16.0-7
ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1
ii libglib2.0-0 2.74.5-1
ii libgtk-3-0 3.24.36-4
ii libgtk-layer-shell0 0.8.0-1
ii libice6 2:1.0.10-1
ii libmate-desktop-2-17 1.26.0-1
ii libmate-menu2 1.26.0-3
ii libmate-panel-applet-4-1 1.27.0-1
ii libmateweather1 1.26.0-1.1
ii libpango-1.0-0 1.50.12+ds-1
ii librda0 0.0.5-1.1
ii libsm6 2:1.2.3-1
ii libwayland-client0 1.21.0-1
ii libwnck-3-0 43.0-3
ii libx11-6 2:1.8.3-3
ii libxrandr2 2:1.5.2-2+b1
ii mate-desktop 1.26.0-1
ii mate-menus 1.26.0-3
ii mate-panel-common 1.27.0-1
ii mate-polkit 1.26.1-1

mate-panel recommends no packages.

mate-panel suggests no packages.

-- no debconf information

Bug#1031847: gnome-shell: Gnome crashes when laptop connected to ThinkPad Universal Thunderbolt 4 Dock (40B0), Oh no! Something has gone wrong error appears.

2023-03-01 Thread Kuba

Clarification: pasted output in previous mail is not consistent, `reportbug
--template gnome-shell` was done with colord patched, but then I
reinstalled it, rebooted machine and copied output of `$ dpkg --list | grep
colord` to the email.

Sorry for confusion.

All the best,
Kuba

Bug#1031847: gnome-shell: Gnome crashes when laptop connected to ThinkPad Universal Thunderbolt 4 Dock (40B0), Oh no! Something has gone wrong error appears.

2023-03-01 Thread Kuba

> Kuba (or anyone else who can reproduce this), please could
you try with mutter-related packages (at least libmutter-11-0)
upgraded to the version 43.3-3+1+g8c42befe7 that I have uploaded to
?

I have updated and it has resolved the crash :)

> You might still need the colord packages from there *as well*, I'm not
100% sure how necessary the colord change is.

I did test with and without updated colord, patch is not required to
resolve the crash (only mutter patch is required)

Below is output of packages installed with docking station working as
expected:

$ dpkg --list | grep colord
ii  colord  1.4.6-2.1
   amd64system service to manage device colour profiles --
system daemon
ii  colord-data 1.4.6-2.1
   all  system service to manage device colour profiles -- data
files
ii  gir1.2-colord-1.0:amd64 1.4.6-2.1
   amd64GObject introspection data for the colord library
ii  libcolord-gtk4-1:amd64  0.3.0-3
   amd64GTK4 convenience library for interacting with colord
ii  libcolord2:amd641.4.6-2.1
   amd64system service to manage device colour profiles --
runtime

$ reportbug --template gnome-shell
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Kuba 
To: Debian Bug Tracking System 
Subject: gnome-shell: none

Package: gnome-shell
Version: 43.3-1
Severity: wishlist
X-Debbugs-Cc: lxk...@wp.pl




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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gir1.2-accountsservice-1.0   22.08.8-6
ii  gir1.2-adw-1 1.2.2-1
ii  gir1.2-atk-1.0   2.46.0-5
ii  gir1.2-atspi-2.0 2.46.0-5
ii  gir1.2-freedesktop   1.74.0-3
ii  gir1.2-gcr-3 3.41.1-1+b1
ii  gir1.2-gdesktopenums-3.0 43.0-1
ii  gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-1+b1
ii  gir1.2-gdm-1.0   43.0-3
ii  gir1.2-geoclue-2.0   2.6.0-2
ii  gir1.2-glib-2.0  1.74.0-3
ii  gir1.2-gnomebluetooth-3.042.5-3
ii  gir1.2-gnomedesktop-3.0  43.2-1
ii  gir1.2-graphene-1.0  1.10.8-1
ii  gir1.2-gstreamer-1.0 1.22.0-2
ii  gir1.2-gtk-3.0   3.24.36-4
ii  gir1.2-gtk-4.0   4.8.3+ds-2
ii  gir1.2-gweather-4.0  4.2.0-1
ii  gir1.2-ibus-1.0  1.5.27-5
ii  gir1.2-mutter-11 43.3-3+1+g8c42befe7
ii  gir1.2-nm-1.01.42.2-1
ii  gir1.2-nma-1.0   1.10.6-1
ii  gir1.2-pango-1.0 1.50.12+ds-1
ii  gir1.2-polkit-1.0122-3
ii  gir1.2-rsvg-2.0  2.54.5+dfsg-1
ii  gir1.2-soup-3.0  3.2.2-1
ii  gir1.2-upowerglib-1.00.99.20-2
ii  gir1.2-webkit2-4.1   2.38.5-1
ii  gnome-backgrounds43.1-1
ii  gnome-settings-daemon43.0-4
ii  gnome-shell-common   43.3-1
ii  gsettings-desktop-schemas43.0-1
ii  gstreamer1.0-pipewire0.3.65-3
ii  libatk-bridge2.0-0   2.46.0-5
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-8
ii  libcairo21.16.0-7
ii  libecal-2.0-23.46.4-1
ii  libedataserver-1.2-273.46.4-1
ii  libgcr-base-3-1  3.41.1-1+b1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libgirepository-1.0-11.74.0-3
ii  libgjs0g 1.74.2-1
ii  libgles2 1.6.0-1
ii  libglib2.0-0 2.74.5-1
ii  libglib2.0-bin   2.74.5-1
ii  libgnome-autoar-0-0  0.4.3-1
ii  libgnome-desktop-3-20

Bug#920913: 2023 status for fakeroot under docker?

2023-03-01 Thread Olliver Schinagl

I've been using a docker container (either debian or alpine based) to 
build openwrt on my Arch system :)


OpenWRT pulls and builds fakeroot to do stuff with, but both containers 
choke in some form.


The debian based container launches 1 faked 100% process at a time, and 
takes forever to do things (but finishes eventually). A 'build' takes 
about 30 - 60 minutes.



```

buildbot@99419141cf36:/workdir$ cat /proc/sys/fs/file-max
9223372036854775807
buildbot@99419141cf36:/workdir$ cat /proc/sys/fs/nr_open
1073741816
buildbot@99419141cf36:/workdir$ ulimit
unlimited
buildbot@99419141cf36:/workdir$ ulimit -Hn
1073741816
buildbot@99419141cf36:/workdir$
```

On alpine (the same numbers) faked also gets lauched, and also takes 
100% CPU on a single core, but for some reason on alpine I see dozens of 
faked processes launched. Not sure how they related. Builds finish in 10 
or so minutes, so at least that's not so bad.



On my host, with systemd, I get far different numbers


```

% cat /proc/sys/fs/file-max
9223372036854775807
% cat /proc/sys/fs/nr_open
1073741816
%  ulimit -Hn
524288
% ulimit
unlimited

```

I'll find out if I can set ulimit during container creation/start to 
workaround the issue, but it's still quite annoying.


The reason for the ping/follow up? There where some good suggestions in 
this thread earlier, as having to close 524288 file descriptors isn't as 
bad as a billion, its still quite a lot of wasted resources for nothing. 
Think of the tree's ;)



Olliver

Bug#1030709: libvirt 7.0.0-3+deb11u2 flagged for acceptance

2023-03-01 Thread Adam D Barratt

package release.debian.org
tags 1030709 = 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: libvirt
Version: 7.0.0-3+deb11u2

Explanation: fix test failures when combined with newer Xen versions

Bug#1032160: tfortune FTCBFS: multiple reasons

2023-03-01 Thread Helmut Grohne

Hi,

On Wed, Mar 01, 2023 at 05:27:04PM +0100, Andre Noll wrote:
> If you are OK with the commit message shown below, I'll merge the
> commit into the master branch and push it out to the public repo.

Sure.

> This is where I need your help, as I'm unfamiliar with the usual
> Debian procedures. How exactly do I schedule an update for trixie?

This isn't exactly about scheduling and more about waiting. Do you mind
if I refer to https://release.debian.org/testing/freeze_policy.html for
details? In essence, this bug does not qualify as "targeted fix".

Helmut

Bug#1032220: multipath-tools: reports job failed on upgrade

2023-03-01 Thread Chris Hofstaedtler

* Ross Boylan  [230301 21:09]:
> It is unclear to me if there is any real problem, as it is unclear if the
> package
> is operating properly.  The journalctl logs seem to show a successful start,
> but
> the aptitude messages indicate a job failed.
> 
> The apparent failure messages buried in the logs are
> Mar 01 09:49:46 barley systemd[1]: multipathd.socket: Socket service
> multipathd.service already active, refusing.

Thats the part causing the failed message in the apt/dpkg postinst
output, and is TTBOMK harmless.

Chris

Bug#1032220: multipath-tools: reports job failed on upgrade

2023-03-01 Thread Ross Boylan

Package: multipath-tools
Version: 0.8.5-2+deb11u1
Severity: normal
X-Debbugs-Cc: rossboy...@stanfordalumni.org, t...@security.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Running on Debian 11.6 and applying the latest security update results in
some reported failures.

It is unclear to me if there is any real problem, as it is unclear if the
package
is operating properly.  The journalctl logs seem to show a successful start,
but
the aptitude messages indicate a job failed.

The apparent failure messages buried in the logs are
Mar 01 09:49:46 barley systemd[1]: multipathd.socket: Socket service
multipathd.service already active, refusing.
Mar 01 09:49:46 barley systemd[1]: Failed to listen on multipathd control
socket.

A start job for unit multipathd.socket has finished with a failure.

Mar 01 09:49:47 barley multipathd[842874]: failed to increase buffer size

So multipathd.socket reports failure, but multipathd.service reports success

Details
- ---


Setting up kpartx (0.8.5-2+deb11u1) ...
Setting up multipath-tools (0.8.5-2+deb11u1) ...
Installing new version of config file /etc/init.d/multipath-tools ...
Job failed. See "journalctl -xe" for details.
Processing triggers for man-db (2.9.4-2) ...
Processing triggers for libc-bin (2.31-13+deb11u5) ...



Mar 01 09:49:39 barley systemd[1]: multipathd.socket: Succeeded.
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit multipathd.socket has successfully entered the 'dead' state.
Mar 01 09:49:39 barley systemd[1]: Closed multipathd control socket.
░░ Subject: A stop job for unit multipathd.socket has finished
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A stop job for unit multipathd.socket has finished.
░░
░░ The job identifier is 168534 and the job result is done.
Mar 01 09:49:44 barley systemd[1]: Reloading.
Mar 01 09:49:45 barley systemd[1]: /lib/systemd/system/plymouth-
start.service:16: Unit configured to use KillMode=none. This is unsafe, as it
disables systemd's process lifecycle management for the service. Please update
your service to use a safer KillMode=, such as 'mixed' or 'control-group'.
Support for KillMode=none is deprecated and will eventually be removed.
Mar 01 09:49:46 barley systemd[1]: multipathd.socket: Socket service
multipathd.service already active, refusing.
Mar 01 09:49:46 barley systemd[1]: Failed to listen on multipathd control
socket.
░░ Subject: A start job for unit multipathd.socket has failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit multipathd.socket has finished with a failure.
░░
░░ The job identifier is 168535 and the job result is failed.
Mar 01 09:49:46 barley systemd[1]: Reloading.
Mar 01 09:49:46 barley systemd[1]: /lib/systemd/system/plymouth-
start.service:16: Unit configured to use KillMode=none. This is unsafe, as it
disables systemd's process lifecycle management for the service. Please update
your service to use a safer KillMode=, such as 'mixed' or 'control-group'.
Support for KillMode=none is deprecated and will eventually be removed.
Mar 01 09:49:47 barley multipathd[1378]: exit (signal)
Mar 01 09:49:47 barley systemd[1]: Stopping Device-Mapper Multipath Device
Controller...
░░ Subject: A stop job for unit multipathd.service has begun execution
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A stop job for unit multipathd.service has begun execution.
░░
░░ The job identifier is 168538.
Mar 01 09:49:47 barley multipathd[1378]: shut down---
Mar 01 09:49:47 barley systemd[1]: multipathd.service: Succeeded.
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit multipathd.service has successfully entered the 'dead' state.
Mar 01 09:49:47 barley systemd[1]: Stopped Device-Mapper Multipath Device
Controller.
░░ Subject: A stop job for unit multipathd.service has finished
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A stop job for unit multipathd.service has finished.
░░
░░ The job identifier is 168538 and the job result is done.
Mar 01 09:49:47 barley systemd[1]: multipathd.service: Consumed 1min 17.748s
CPU time.
░░ Subject: Resources consumed by unit runtime
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit multipathd.service completed and consumed the indicated resources.
Mar 01 09:49:47 barley systemd[1]: Starting Device-Mapper Multipath Device
Controller...
░░ Subject: A start job for unit multipathd.service has begun execution
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit multipathd.service has begun execution.
░░
░░ The job identifier is 168538.
Mar 01 09:49:47 barley multipathd[842874]: start up
Mar 01 09:49:47 barley multipathd[842874]: read /etc/multipath.conf
Mar 01 09:49:47 barley multipathd[842874]: failed to increase buffer size
Mar 01

Bug#1032219: apt-setup: Regression in a string which was correctly translated (es.po)

2023-03-01 Thread Santiago Vila


Package: apt-setup
Version: 1:0.177
Tags: patch

Hello.

After trying debian-installer alpha2 today I've noticed there is an
error in debian/po/es.po for the string "release updates",
introduced in commit 11c8e244 dated 2023-02-07.

Apparently, somebody has misinterpreted it as if "release" acted
as a verb and "updates" was the direct object of such verb (!).
The end result is a screen like this:

[ ] actualizaciones de seguridad (de security.debian.org)
[ ] Publicar actualizaciones
[ ] programas migrados a nuevas versiones


The old translation ("actualizaciones de la distribución")
was essentially correct (except that the previous extra ":"
is not needed).

(X-Debian-CC to debian-l10n-span...@lists.debian.org in
case they want to comment on this).

Patch attached.

Thanks.--- a/debian/po/es.po
+++ b/debian/po/es.po
@@ -219,7 +219,7 @@ msgstr "actualizaciones de seguridad (de ${SEC_HOST})"
 #. :sl1:
 #: ../apt-setup-udeb.templates:11001
 msgid "release updates"
-msgstr "Publicar actualizaciones"
+msgstr "actualizaciones de la distribución"
 
 #. Type: multiselect
 #. Choices

Bug#1031210: mitmproxy: please update to 9.0.1

2023-03-01 Thread Gianfranco Costamagna

Hello,

On Mon, 13 Feb 2023 18:13:24 +0100 Bastian Germann  wrote:

On Mon, 13 Feb 2023 09:41:15 +0100 Gianfranco Costamagna 
 wrote:
> mitmproxy-wireguard is already available as kali package, I think I'll just 
go ahead and start from that
> https://gitlab.com/kalilinux/packages/mitmproxy-wireguard

Please see https://github.com/mitmproxy/mitmproxy/pull/5909 and note
that upstream has already switched away from that for the next version.

thanks!
So we will have a newer mitmproxy soon?

G.

OpenPGP_signature
Description: OpenPGP digital signature

Bug#1031821: libreswan: remote crash, CVE-2023-23009

2023-03-01 Thread Salvatore Bonaccorso

Daniel,

On Wed, Mar 01, 2023 at 01:18:11PM -0500, Daniel Kahn Gillmor wrote:
> On Wed 2023-03-01 12:52:58 +0100, Salvatore Bonaccorso wrote:
> > Yes it does thank you. So even tough that's a bit a borderline case
> > (mean with it as with the vpn service case, where you have
> > authennticated users, but you might not entirely trust the entities)
> > let's release a DSA for it. Can you prepare a final debdiff for a
> > quick review for bullseye-security?
> 
> Sure, a proposed final debdiff is attached.  The code is also in the
> debian/bullseye branch on https://salsa.debian.org/debian/libreswan.
> 
> Please let me know if you think anything else should be done
> differently.
> 
> Thanks for keeping an eye on this, Salvatore!

Thanks to you actually. Looks good to me, please do upload.

Regards,
Salvatore

Bug#1032168: meson: autopkgtest fills disk completely

2023-03-01 Thread Paul Gevers


Hi Jussi,

On 01-03-2023 00:17, Jussi Pakkanen wrote:

On Tue, 28 Feb 2023 at 23:30, Paul Gevers  wrote:


With your last upload of meson, we're seeing issues on
ci.debian.net. It turns out that the autopkgtest of meson is using so
much disk space that the most of our hosts runs out of it when meson
is tested.


This is weird. As far as we know we have not made any changes that
should affect disk usage in 1.0.1.


Well, maybe something that meson uses has changed?


Is /tmp on the same file system as the rest of the image or is it a
separate partition?


Inside the lxc container, everything is on the same partition. Or are 
you really interested on the host that runs autopkgtest? There it's not 
the same across the workers.



Is it possible to know how close to filling up the disk the old
succeeding builds got?


No, but e.g. on s390x it never ever came close to filling the disk, so
the peaks of before today here are really new:
https://ci.debian.net/munin/ci-worker-s390x-01/ci-worker-s390x-01/df.html 
(but apparently another package is also suddenly misbehaving, so maybe 
it's indeed something *below* meson. I'll try to figure out tonight or 
tomorrow morning.



And how much disk space is given to the build
in total?


I've wished for a long time to provide that information on our site. To 
be able to quickly provide the info, I decided to quickly set up this wiki:

https://wiki.debian.org/ContinuousIntegration/WorkerSpecs

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1031821: libreswan: remote crash, CVE-2023-23009

2023-03-01 Thread Daniel Kahn Gillmor

On Wed 2023-03-01 12:52:58 +0100, Salvatore Bonaccorso wrote:
> Yes it does thank you. So even tough that's a bit a borderline case
> (mean with it as with the vpn service case, where you have
> authennticated users, but you might not entirely trust the entities)
> let's release a DSA for it. Can you prepare a final debdiff for a
> quick review for bullseye-security?

Sure, a proposed final debdiff is attached.  The code is also in the
debian/bullseye branch on https://salsa.debian.org/debian/libreswan.

Please let me know if you think anything else should be done
differently.

Thanks for keeping an eye on this, Salvatore!

  --dkg

diff --git libreswan-4.3/debian/changelog libreswan-4.3/debian/changelog
index ff60ad1b7b..8f709eec58 100644
--- libreswan-4.3/debian/changelog
+++ libreswan-4.3/debian/changelog
@@ -1,3 +1,9 @@
+libreswan (4.3-1+deb11u2) bullseye-security; urgency=high
+
+  * Fixes CVE-2023-23009 (Closes: #1031821)
+
+ -- Daniel Kahn Gillmor   Wed, 01 Mar 2023 13:11:05 -0500
+
 libreswan (4.3-1+deb11u1) bullseye-security; urgency=high
 
   * Fixes CVE-2022-23094
diff --git libreswan-4.3/debian/patches/0004-Fix-CVE-2023-23009.patch libreswan-4.3/debian/patches/0004-Fix-CVE-2023-23009.patch
new file mode 100644
index 00..851aa0d71d
--- /dev/null
+++ libreswan-4.3/debian/patches/0004-Fix-CVE-2023-23009.patch
@@ -0,0 +1,25 @@
+From: Daniel Kahn Gillmor 
+Date: Wed, 22 Feb 2023 14:57:02 -0500
+Subject: Fix CVE-2023-23009
+
+See https://github.com/libreswan/libreswan/issues/954
+---
+ programs/pluto/ikev2_ts.c | 5 +
+ 1 file changed, 5 insertions(+)
+
+diff --git a/programs/pluto/ikev2_ts.c b/programs/pluto/ikev2_ts.c
+index fba776a..c8ce761 100644
+--- a/programs/pluto/ikev2_ts.c
 b/programs/pluto/ikev2_ts.c
+@@ -421,6 +421,11 @@ static bool v2_parse_ts(struct payload_digest *const ts_pd,
+ 		d = pbs_in_struct(_pd->pbs, _ts_header_desc,
+ 			  _h, sizeof(ts_h), _body_pbs);
+ 
++		if (d != NULL) {
++			llog_diag(RC_LOG, logger, , "%s", "");
++			return false;
++		}
++
+ 		switch (ts_h.isath_type) {
+ 		case IKEv2_TS_IPV4_ADDR_RANGE:
+ 		case IKEv2_TS_IPV6_ADDR_RANGE:
diff --git libreswan-4.3/debian/patches/series libreswan-4.3/debian/patches/series
index ccb5ae82f7..7039666566 100644
--- libreswan-4.3/debian/patches/series
+++ libreswan-4.3/debian/patches/series
@@ -1,3 +1,4 @@
 0001-do-not-use-git-version.patch
 0002-debian-pam.d-pluto.patch
 CVE-2022-23094.patch
+0004-Fix-CVE-2023-23009.patch


signature.asc
Description: PGP signature

Bug#1032105: pkg-perl-tools: [dpt prepare] gitddiff shouldn't use last tag but last tag in current branch

2023-03-01 Thread gregor herrmann

On Wed, 01 Mar 2023 07:27:13 +0400, Yadd wrote:

> > > > In lib/dpt-lib.sh, maybe you could replace
> > > > TAG=$(git rev-list -n1 --tags)
> > > or simply
> > >TAG=$(git describe --abbrev=0)

> > But this works:
> > 
> >% git describe --abbrev=0 --match "debian/*" --tags # [1]
> >debian/1.62-3

> > Maybe, in order to git rid of the separation between native and
> > non-native package, something funky as
> > 
> >% git describe --abbrev=0 --match "$(gbp config DEFAULT.debian-tag | sed 
> > -e 's/%(version)s/*/g;')" --tags # [2]
> >debian/1.62-3
> > 

> > Alright, maybe we all try out either [1] or [2] a bit?
> > I've updated my .gitconfig and my local version of
> > scripts/lib/dpt-lib.sh to use [2].

> I tried also [2], perfect with all Perl packages I've locally + 1500 nodejs
> packages, works perfectly!

Thanks for trying and reporting back!

I was also quite happy so far -- until I hit a repository with no
debian tags (new package, in this case libjson-schema-modern-perl),
and there I got (at the end of dpt-import-orig):

  Git diff against last Debian tag
  
  fatal: No names found, cannot describe anything.


Directly in the shell:

  % git rev-list -n1 --tags=debian
  %

(No output, exit code 0)

  % git describe --abbrev=0 --match "$(gbp config DEFAULT.debian-tag | sed -e 
's/%(version)s/*/g;')" --tags
  fatal: No names found, cannot describe anything.

(Exit code 128)

Not sure what to do here; I mean

  % git describe --abbrev=0 --match "$(gbp config DEFAULT.debian-tag | sed -e 
's/%(version)s/*/g;')" --tags 2>/dev/null || true

works but …


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1032165: gcc-12-cross-ports: not binNMU safe

2023-03-01 Thread Sebastian Ramacher

Control: clone -1 -2 -3 -4
Control: reassign -2 gcc-9-cross-ports 25
Control: retitle -2 gcc-9-cross-ports: not binNMU-safe  
Control: reassign -3 gcc-9-cross 27
Control: retitle -3 gcc-9-cross: not binNMU-safe
Control: reassign -4 gcc-10-cross-mipsen 3+c5
Control: retitle -4 gcc-10-cross-mipsen: not binNMU-safe

On 2023-02-28 22:18:14 +0100, Sebastian Ramacher wrote:
> Control: clone -1 -2
> Control: reassign -2 gcc-11-cross-mipsen 5+c3
> Control: retitle -2 gcc-11-cross-mipsen: not binNMU-safe
> 
> On 2023-02-28 22:13:59 +0100, Sebastian Ramacher wrote:
> > Source: gcc-12-cross-ports
> > Version: 12
> > Severity: serious
> > 
> > The method to compute the version of the binary packages is not
> > binNMU-safe. This can be seen from the latest round of binNMUs to
> > rebuild for outdated Built-Using fields. See
> > https://buildd.debian.org/status/fetch.php?pkg=gcc-12-cross-ports=amd64=12%2Bb1=1677602107=0
> > 
> > As it can be seen from the log, the version computed for the binary
> > packages is the same as the one of the build of the initial upload of
> > version 12. The binNMU version -- b1 in this case -- is missing.
> 
> gcc-11-cross-mipsen is affected by the same issue. Cloning and
> reassigning.

… and there are more.

Cheers
-- 
Sebastian Ramacher

Bug#1032215: RM: libmath-units-perl -- NPOASR; No longer required for Geo::Calc

2023-03-01 Thread Bas Couwenberg

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: libmath-units-p...@packages.debian.org
Control: affects -1 + src:libmath-units-perl

Please remove libmath-units-perl from the archive, it was required for 
Geo::Calc which got removed (#1031604).

Kind Regards,

Bas

Bug#1032214: ITP: python-www-authenticate -- Parser for WWW-Authentication headers for Python 3

Package: wnpp
Owner: Yaroslav Halchenko , Vasyl Gello 

Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: python-www-authenticate
  Version : 0.9.2
  Upstream Author : Alexandre Dutton 
* URL : https://github.com/alexsdutton/www-authenticate
* License : BSD-3-clause
  Programming Lang: Python
  Description : Parser for WWW-Authentication headers for Python 3

This Python 3 library parses various WWW-Authenticate headers
including ones emitted by servers not conformant to RFCs.

Bug#1032213: ITP: python-wsgidav -- Generic and extendable WebDAV server

Package: wnpp
Owner: Yaroslav Halchenko ,
Vasyl Gello 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: python-wsgidav
  Version : 4.2.0
  Upstream Author : Martin Wendt 
* URL : https://wsgidav.readthedocs.org/
* License : MIT
  Programming Lang: Python
  Description : Generic and extendable WebDAV server

WsgiDAV is a stand-alone WebDAV server with SSL support,
that can be installed and run as Python command line script
on Linux, OSX, and Windows

Bug#1032212: ITP: python-wirerope -- Python3 library for manipulation with methods

Package: wnpp
Owner: Yaroslav Halchenko ,
Vasyl Gello 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: python-wirerope
  Version : 0.4.7
  Upstream Author : Jeong YunWon 
* URL : https://wirerope.readthedocs.org/
* License : BSD-2-clause
  Programming Lang: Python
  Description : Python3 library for manipulation with methods

It turns functions and methods into fully controllable object

Used in conjunction with methodtools.

Bug#1032210: ITP: python-methodtools -- Python3 library expanding standard functools to methods

Package: wnpp
Owner: Yaroslav Halchenko ,
Vasyl Gello 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: python-methodtools
  Version : 0.4.7
  Upstream Author : Jeong YunWon 
* URL : https://methodtools.readthedocs.org/
* License : BSD-2-clause
  Programming Lang: Python
  Description : Python3 library expanding standard functools to methods

Expand functools features to methods, classmethods, staticmethods
and even for (unofficial) hybrid methods.

For now, methodtools only provides `methodtools.lru_cache`.

Bug#1032211: ITP: python-outdated -- Check if a version of a PyPI package is outdated

Package: wnpp
Owner: Yaroslav Halchenko , Vasyl Gello 

Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: python-outdated
  Version : 0.2.2
  Upstream Author : Alex Hall 
* URL : https://github.com/alexmojaki/outdated
* License : MIT
  Programming Lang: Python
  Description : Check if a version of a PyPI package is outdated

This is a mini-library which, given a package name and a version,
checks if it's the latest version available on PyPI.

It does not check which version of package is actually installed,
but only checks if the provided version string of the given package
is latest or not.

Bug#1032209: ITP: python-linesep -- Python3 library for manipulation with lines with separators

Package: wnpp
Owner: Yaroslav Halchenko ,
Vasyl Gello 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: python-linesep
  Version : 0.5.0
  Upstream Author : John Thorvald Wodder II 
* URL : https://linesep.readthedocs.org/
* License : MIT
  Programming Lang: Python
  Description : Python3 library for manipulation with lines with separators

linesep provides basic functions & classes for reading, writing, splitting,
& joining text with custom separators that can occur either before, between, or
after the segments they separate

Bug#1032208: ITP: python-aiohttp-retry -- Simple aiohttp retry client

Package: wnpp
Owner: Yaroslav Halchenko ,
Vasyl Gello 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: python-aiohttp-retry
  Version : 2.8.3
  Upstream Author : Dmitry Inyutin 
* URL : https://github.com/inyutin/aiohttp_retry
* License : MIT
  Programming Lang: Python
  Description : Simple aiohttp retry client

This package provides aiohttp-retry - the python3 library extending
aiohttp with retry support.

Bug#1032207: libpam-modules: Drop pam_userdb

2023-03-01 Thread Bastian Germann


Package: libpam-modules
Severity: wishlist
Version: 1.5.2-6

libpam-modules is the only pseudo-essential module that depends on libdb5.3 via 
its pam_userdb module.
I have never seen a system actually using this so I suggest to remove during 
the trixie release cylce,
i.e. dropping the Build-Depends on libdb-dev.

Alternatively, it could be split out to a separate binary package, possibly 
with other less used modules.

Bug#1031969: this is an important bug, can't use torch on bookworm any longer

2023-03-01 Thread Sam Watkins

The package is not installable, and it's necessary for anyone who uses bookworm 
for AI work and anything else that might need 3.10.

I was using Debian "testing" with torch. Torch is not fully compatible with 
3.11,
and now the 3.10 packaging is broken and we can no longer create a 3.10 venv.

Bug#1032197: systemd: journalctl -o short-iso-precise not compatible with RFC 3339

2023-03-01 Thread Michael Biebl


Control: tags -1 + upstream

Hi

Am 01.03.23 um 14:32 schrieb Thomas Parmelan:

Would it be possible to change the short-iso-precise in this way, or if
you prefer not changing it, maybe adding a new short-rfc3339-precise
option ? (and probably doing the same thing for short-iso / short-rfc339
too) ?


I think this could be a useful addition. That said, this should be 
discussed/implemented upstream and not via a downstream patch.


Can you thus please file an issue upstream at
https://github.com/systemd/systemd/

Thanks,
Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1031863: libqt5sql5-mysql: incompatible change in libmariadb3 breaks kontact, needs upstream fix in libqt5sql5-mysql

2023-03-01 Thread Rai

Hi Paul,

Thanks for clearification.
At least we are 2 users and over the years I'm really happy with debian. ;)

Regards
Rai

Am 01.03.2023 um 16:13 schrieb Paul Boddie:

> On Wednesday, 1 March 2023 07:24:23 CET Otto Kekäläinen wrote:
>> 
>> The fact that his issue surfaced now about something that changed in
>> Debian 1-2 years ago and was changed upstream 2 years ago confuses me.
>> Also I don't have any easy way to fire up a container and reproduce
>> the issue.
> 
> It isn't really so mysterious, and I tried to explain it in the original bug 
> I 
> filed against Kontact:
> 
> 1. A change in MariaDB 10.6 broke Qt's MySQL support back in 2021.
> 
> 2. Someone decided to let this change leak into MariaDB 10.3.38.
> 
> 3. A Debian package for 10.3.38 was finalised in the last couple of weeks and 
> arrived last week.
> 
> 4. Suddenly, Akonadi cannot connect to MySQL properly and Kontact won't show 
> the contents of mail messages any more.
> 
> How the change leaked is more mysterious. However, going to the 10.3 branch 
> of 
> the server, following the link to libmariadb and the mariadb-connector-c 
> repository and using the "blame" tool yields this commit:
> 
> https://github.com/mariadb-corporation/mariadb-connector-c/commit/
> d204e83104222844251b221e9be7eb3dd9f8d63d
> 
> That was made two months ago, but I imagine that the workflow propagated it 
> in 
> various branches for a while before a release was actually made.
> 
>> However, as a clear patch was suggested I did it in
>> https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commits/bugfix/1031863->
>>  libmariadb3-version-id
> 
> I realised that I had messed up my own patch, explaining why I didn't see any 
> change in behaviour with my revised package, but rebuilding again and testing 
> now, I can confirm that the above patch fixes the problem. Reverting to the 
> distribution-supplied libqt5sql5-mysql package and using the patched version 
> of libmariadb3 makes Kontact and Akonadi work again.
> 
>> The the Salsa runner comes back online and pipeline works again, there
>> will be build artifacts available at
>> https://salsa.debian.org/mariadb-team/mariadb-10.3/-/jobs/4004950 and
>> you can download the libmariadb3 with this patched and test if it
>> fixes your mail client situation.
> 
> It seems that the pipeline failed, but I managed to build a revised package 
> anyway.
> 
> I have no idea about whether other software has been broken by this, but 
> anyone using the distribution-supplied packages for libmariadb3 and 
> libqt5sql5-mysql will have seen programs break.
> 
> Maybe only the Akonadi stack is affected as a consequence. Since people tend 
> to abandon the KDE groupware programs every time something breaks, it is 
> entirely possible that there are relatively few users left to complain.
> 
> All this effort for a single-token change in a file that shouldn't have been 
> made in the first place!
> 
> Paul

Bug#1025141: powermgmt-base: Doesn't correctly detect we are on AC power

2023-03-01 Thread Raymond S Brand


Followup to Santiago's report:

The script is also reporting that my Dell 3260CFF (Compact Form Factor) 
is not on AC power when it is since it doesn't have a battery option.


The following may be of some help:

$ sh -x /sbin/on_ac_power
+ set -e
+ OFF_LINE_P=no
+ [ -d /sys/class/power_supply/ ]
+ test -d /sys/class/power_supply/hidpp_battery_0
+ test -r /sys/class/power_supply/hidpp_battery_0/type
+ cat /sys/class/power_supply/hidpp_battery_0/type
+ type=Battery
+ test -d /sys/class/power_supply/ucsi-source-psy-USBC000:001
+ test -r /sys/class/power_supply/ucsi-source-psy-USBC000:001/type
+ cat /sys/class/power_supply/ucsi-source-psy-USBC000:001/type
+ type=USB
+ [ -r /sys/class/power_supply/ucsi-source-psy-USBC000:001/online ]
+ cat /sys/class/power_supply/ucsi-source-psy-USBC000:001/online
+ online=0
+ [ 0 = 1 ]
+ [ 0 = 0 ]
+ OFF_LINE_P=yes
+ [ yes = yes ]
+ exit 1
$

The H/W doesn't actually have a battery option but does use a laptop 
style power brick or USB-C to supply power.

Bug#1032206: fakeroot: [INTL:de] Updated German Translation

2023-03-01 Thread Chris Leick


Package: fakeroot
Version: 1.31-1
Severity: wishlist
Tags: l10n patch



Hi,

please find attached the newest German translation.

Kind regards,
Chris

de.po.gz
Description: application/gzip

Bug#995156: easy-rsa: vars Autodetection

2023-03-01 Thread Adrian Bunk

On Tue, Feb 14, 2023 at 10:28:16PM +0100, Lee Garrett wrote:
> I'm bumping the bug severity because currently it will ignore
> security-relevant settings like keysize and algo, and the defaults are
> pretty weak.

Has anyone discussed this with upstream?

This seems to be an area with frequent changes upstream, adding a patch 
that is not a backport from upstream might be a bad idea.

cu
Adrian

Bug#1032188: old old stable debdiff

2023-03-01 Thread Bastien Roucariès

Hi,

The old old stable debdiff now

diff -Nru node-css-what-2.1.0/debian/changelog node-css-what-2.1.0/debian/changelog
--- node-css-what-2.1.0/debian/changelog	2016-02-05 20:41:17.0 +
+++ node-css-what-2.1.0/debian/changelog	2023-03-01 15:33:15.0 +
@@ -1,3 +1,15 @@
+node-css-what (2.1.0-1+deb9u1) stretch-security; urgency=medium
+
+  * Team upload
+  * node-css-what was vulnerable to Regular Expression Denial of Service
+(ReDoS) due to the usage of insecure regular expression in the
+re_attr variable.
+The exploitation of this vulnerability could be triggered
+via the parse function.
+Fix CVE-2022-21222, CVE-2021-33587 (Closes: #989264, #1032188)
+
+ -- Bastien Roucariès   Wed, 01 Mar 2023 15:33:15 +
+
 node-css-what (2.1.0-1) unstable; urgency=medium
 
   * new upstream version
diff -Nru node-css-what-2.1.0/debian/patches/0001-Partial-fix-of-reDos-CVE-2022-21222-CVE-2021-33587-a.patch node-css-what-2.1.0/debian/patches/0001-Partial-fix-of-reDos-CVE-2022-21222-CVE-2021-33587-a.patch
--- node-css-what-2.1.0/debian/patches/0001-Partial-fix-of-reDos-CVE-2022-21222-CVE-2021-33587-a.patch	1970-01-01 00:00:00.0 +
+++ node-css-what-2.1.0/debian/patches/0001-Partial-fix-of-reDos-CVE-2022-21222-CVE-2021-33587-a.patch	2023-03-01 15:33:15.0 +
@@ -0,0 +1,37 @@
+From: =?utf-8?q?Bastien_Roucari=C3=A8s?= 
+Date: Wed, 1 Mar 2023 15:08:01 +
+Subject: Partial fix of reDos CVE-2022-21222/CVE-2021-33587: attribute
+ selector
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+Per https://w3c.github.io/csswg-drafts/selectors/#attribute-selectors only = ~= |= ^= $= *= are supported.
+
+Add also != that is checked as invalid latter in order to pass testsuite.
+
+So replace \S by [~|^$*!]
+
+Signed-off-by: Bastien Roucariès 
+bug-debian: https://bugs.debian.org/989264
+bug-debian: https://bugs.debian.org/1032188
+bug: https://www.cve.org/CVERecord?id=CVE-2022-21222
+bug: https://www.cve.org/CVERecord?id=CVE-2021-33587
+Signed-off-by: Bastien Roucariès 
+---
+ index.js | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/index.js b/index.js
+index 859324c..d7105f9 100644
+--- a/index.js
 b/index.js
+@@ -5,7 +5,7 @@ module.exports = parse;
+ var re_name = /^(?:\\.|[\w\-\u00c0-\u])+/,
+ re_escape = /\\([\da-f]{1,6}\s?|(\s)|.)/ig,
+ //modified version of https://github.com/jquery/sizzle/blob/master/src/sizzle.js#L87
+-re_attr = /^\s*((?:\\.|[\w\u00c0-\u\-])+)\s*(?:(\S?)=\s*(?:(['"])(.*?)\3|(#?(?:\\.|[\w\u00c0-\u\-])*)|)|)\s*(i)?\]/;
++re_attr = /^\s*((?:\\.|[\w\u00c0-\u\-])+)\s*(?:([~|^$*!]?)=\s*(?:(['"])(.*?)\3|(#?(?:\\.|[\w\u00c0-\u\-])*)|)|)\s*(i)?\]/;
+ 
+ var actionTypes = {
+ 	__proto__: null,
diff -Nru node-css-what-2.1.0/debian/patches/0002-Partial-fix-of-ReDos-CVE-2022-21222-CVE-2021-33587-t.patch node-css-what-2.1.0/debian/patches/0002-Partial-fix-of-ReDos-CVE-2022-21222-CVE-2021-33587-t.patch
--- node-css-what-2.1.0/debian/patches/0002-Partial-fix-of-ReDos-CVE-2022-21222-CVE-2021-33587-t.patch	1970-01-01 00:00:00.0 +
+++ node-css-what-2.1.0/debian/patches/0002-Partial-fix-of-ReDos-CVE-2022-21222-CVE-2021-33587-t.patch	2023-03-01 15:33:15.0 +
@@ -0,0 +1,43 @@
+From: =?utf-8?q?Bastien_Roucari=C3=A8s?= 
+Date: Wed, 1 Mar 2023 15:15:20 +
+Subject: Partial fix of ReDos CVE-2022-21222/CVE-2021-33587: trim string
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+Trim left the string avoiding a \s* at the beginning of the string, thus avoiding part of complexity.
+
+bug-debian: https://bugs.debian.org/989264
+bug-debian: https://bugs.debian.org/1032188
+bug: https://www.cve.org/CVERecord?id=CVE-2022-21222
+bug: https://www.cve.org/CVERecord?id=CVE-2021-33587
+Signed-off-by: Bastien Roucariès 
+---
+ index.js | 7 +--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/index.js b/index.js
+index d7105f9..1e7f145 100644
+--- a/index.js
 b/index.js
+@@ -5,7 +5,7 @@ module.exports = parse;
+ var re_name = /^(?:\\.|[\w\-\u00c0-\u])+/,
+ re_escape = /\\([\da-f]{1,6}\s?|(\s)|.)/ig,
+ //modified version of https://github.com/jquery/sizzle/blob/master/src/sizzle.js#L87
+-re_attr = /^\s*((?:\\.|[\w\u00c0-\u\-])+)\s*(?:([~|^$*!]?)=\s*(?:(['"])(.*?)\3|(#?(?:\\.|[\w\u00c0-\u\-])*)|)|)\s*(i)?\]/;
++re_attr = /^((?:\\.|[\w\u00c0-\u\-])+)\s*(?:([~|^$*!]?)=\s*(?:(['"])(.*?)\3|(#?(?:\\.|[\w\u00c0-\u\-])*)|)|)\s*(i)?\]/;
+ 
+ var actionTypes = {
+ 	__proto__: null,
+@@ -146,7 +146,10 @@ function parseSelector(subselects, selector, options){
+ 	ignoreCase: false
+ });
+ 			} else if(firstChar === "["){
+-selector = selector.substr(1);
++			selector = selector.substr(1);
++			var wspace = selector.match(/^\s*/);
++			var woffset = !wspace ? 0 : wspace[0].length;
++			selector =

Bug#1012016: libapache-poi-java breaks octave-io autopkgtest: assert (size (d) == [1001, 2]) failed

2023-03-01 Thread Sébastien Villemot

Control: severity -1 important

Le mardi 31 janvier 2023 à 18:09 +0100, Sébastien Villemot a écrit :
> Alternatively, I could try to patch octave-io so that it no longer uses
> libapache-poi-java for reading XLSX files. That is an inferior
> solution, because that will remove an important functionality from the
> package, but I may not have the choice.

I ended up implementing this “solution” in octave-io 2.4.6-3. So in
effect it no longer relies on libapache-poi-java + libxmlbeans-java for
reading XLSX files (fortunately octave-io has another, less efficient,
backend for reading XLSX files).

As a consequence, downgrading the severity of this bug.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org



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

Bug#1012016: libapache-poi-java breaks octave-io autopkgtest: assert (size (d) == [1001, 2]) failed

2023-03-01 Thread Sébastien Villemot

Le mercredi 01 mars 2023 à 17:58 +0100, Sébastien Villemot a écrit :
> I ended up implementing this “solution” in octave-io 2.4.6-3.

Sorry, I meant octave-io 2.6.4-3

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org



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

Bug#1029821: change gnome-desktop's default choice of Japanese input methods for Debian

Package: libgnome-desktop-4-2
Followup-For: Bug #1029821
X-Debbugs-Cc: yy.y.ja...@gmail.com

I'd like to contribute by testing d-i with Japanese input (I'm not a Japanese
speaker, but can offer some time to help).

My plan is to:

  1. run the graphical d-i install of a fresh GNOME 43 system
  2. select 'anthy' in 'gnome-initial-setup'
  3. attempt Japanese keyboard input

  4. run the graphical d-i install of a fresh GNOME 43 system
  5. select 'mozc-jp' in 'gnome-initial-setup'
  6. attempt Japanese keyboard input

For each path I may need help: how will I verify that Japanese input support
is working?  (maybe a naive question, but I don't know; I will search the web
to find out soon, but any guidance before then would be appreciated)

Also:

My understanding is that the _only_ difference that the patch will make is
that it will change the default in 'gnome-initial-setup'.  Users could still
choose 'anthy' -- or another input method -- if they want, for some reason.  Is
that correct?

Bug#1028549: Acknowledgement (xserver-xorg-video-radeon: [Radeon 680M]: not rendering/refreshing fullscreen properly with VSync off)

2023-03-01 Thread Linus Lüssing

Just for a small update:

Issue still persists, even with all packages updated to a current
Debian Sid (including adding the new "non-free-firmware" section
to apt).

ii  xserver-xorg-video-radeon1:19.1.0-3
ii  libc6:amd64  2.36-8
ii  libc6:i386   2.36-8
ii  libdrm-radeon1:amd64 2.4.114-1
ii  libdrm-radeon1:i386  2.4.114-1
ii  libgbm1:amd6422.3.6-1
ii  libgbm1:i386 22.3.6-1
ii  libudev1:i386252.6-1
ii  xserver-xorg-core2:21.1.7-1
ii  firmware-amd-graphics20230210-2

$ uname -a
Linux linus-lptp 6.1.0-5-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.12-1 
(2023-02-15) x86_64 GNU/Linux

Regards, Linus

Bug#1032188: Old stable debdiff

2023-03-01 Thread Bastien Roucariès

Hi,

The debdiff for buster. Please review, will upload, after a while.

ReDoS was checked by using (not yet packaged) rechek.

Bastiendiff -Nru node-css-what-2.1.0/debian/changelog node-css-what-2.1.0/debian/changelog
--- node-css-what-2.1.0/debian/changelog	2016-02-05 20:41:17.0 +
+++ node-css-what-2.1.0/debian/changelog	2023-03-01 15:33:15.0 +
@@ -1,3 +1,15 @@
+node-css-what (2.1.0-1+deb10u1) buster-security; urgency=medium
+
+  * Team upload
+  * node-css-what was vulnerable to Regular Expression Denial of Service
+(ReDoS) due to the usage of insecure regular expression in the
+re_attr variable.
+The exploitation of this vulnerability could be triggered
+via the parse function.
+Fix CVE-2022-21222, CVE-2021-33587 (Closes: #989264, #1032188)
+
+ -- Bastien Roucariès   Wed, 01 Mar 2023 15:33:15 +
+
 node-css-what (2.1.0-1) unstable; urgency=medium
 
   * new upstream version
diff -Nru node-css-what-2.1.0/debian/patches/0001-Partial-fix-of-reDos-CVE-2022-21222-CVE-2021-33587-a.patch node-css-what-2.1.0/debian/patches/0001-Partial-fix-of-reDos-CVE-2022-21222-CVE-2021-33587-a.patch
--- node-css-what-2.1.0/debian/patches/0001-Partial-fix-of-reDos-CVE-2022-21222-CVE-2021-33587-a.patch	1970-01-01 00:00:00.0 +
+++ node-css-what-2.1.0/debian/patches/0001-Partial-fix-of-reDos-CVE-2022-21222-CVE-2021-33587-a.patch	2023-03-01 15:29:40.0 +
@@ -0,0 +1,37 @@
+From: =?utf-8?q?Bastien_Roucari=C3=A8s?= 
+Date: Wed, 1 Mar 2023 15:08:01 +
+Subject: Partial fix of reDos CVE-2022-21222/CVE-2021-33587: attribute
+ selector
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+Per https://w3c.github.io/csswg-drafts/selectors/#attribute-selectors only = ~= |= ^= $= *= are supported.
+
+Add also != that is checked as invalid latter in order to pass testsuite.
+
+So replace \S by [~|^$*!]
+
+Signed-off-by: Bastien Roucariès 
+bug-debian: https://bugs.debian.org/989264
+bug-debian: https://bugs.debian.org/1032188
+bug: https://www.cve.org/CVERecord?id=CVE-2022-21222
+bug: https://www.cve.org/CVERecord?id=CVE-2021-33587
+Signed-off-by: Bastien Roucariès 
+---
+ index.js | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/index.js b/index.js
+index 859324c..d7105f9 100644
+--- a/index.js
 b/index.js
+@@ -5,7 +5,7 @@ module.exports = parse;
+ var re_name = /^(?:\\.|[\w\-\u00c0-\u])+/,
+ re_escape = /\\([\da-f]{1,6}\s?|(\s)|.)/ig,
+ //modified version of https://github.com/jquery/sizzle/blob/master/src/sizzle.js#L87
+-re_attr = /^\s*((?:\\.|[\w\u00c0-\u\-])+)\s*(?:(\S?)=\s*(?:(['"])(.*?)\3|(#?(?:\\.|[\w\u00c0-\u\-])*)|)|)\s*(i)?\]/;
++re_attr = /^\s*((?:\\.|[\w\u00c0-\u\-])+)\s*(?:([~|^$*!]?)=\s*(?:(['"])(.*?)\3|(#?(?:\\.|[\w\u00c0-\u\-])*)|)|)\s*(i)?\]/;
+ 
+ var actionTypes = {
+ 	__proto__: null,
diff -Nru node-css-what-2.1.0/debian/patches/0002-Partial-fix-of-ReDos-CVE-2022-21222-CVE-2021-33587-t.patch node-css-what-2.1.0/debian/patches/0002-Partial-fix-of-ReDos-CVE-2022-21222-CVE-2021-33587-t.patch
--- node-css-what-2.1.0/debian/patches/0002-Partial-fix-of-ReDos-CVE-2022-21222-CVE-2021-33587-t.patch	1970-01-01 00:00:00.0 +
+++ node-css-what-2.1.0/debian/patches/0002-Partial-fix-of-ReDos-CVE-2022-21222-CVE-2021-33587-t.patch	2023-03-01 15:29:40.0 +
@@ -0,0 +1,43 @@
+From: =?utf-8?q?Bastien_Roucari=C3=A8s?= 
+Date: Wed, 1 Mar 2023 15:15:20 +
+Subject: Partial fix of ReDos CVE-2022-21222/CVE-2021-33587: trim string
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+Trim left the string avoiding a \s* at the beginning of the string, thus avoiding part of complexity.
+
+bug-debian: https://bugs.debian.org/989264
+bug-debian: https://bugs.debian.org/1032188
+bug: https://www.cve.org/CVERecord?id=CVE-2022-21222
+bug: https://www.cve.org/CVERecord?id=CVE-2021-33587
+Signed-off-by: Bastien Roucariès 
+---
+ index.js | 7 +--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/index.js b/index.js
+index d7105f9..1e7f145 100644
+--- a/index.js
 b/index.js
+@@ -5,7 +5,7 @@ module.exports = parse;
+ var re_name = /^(?:\\.|[\w\-\u00c0-\u])+/,
+ re_escape = /\\([\da-f]{1,6}\s?|(\s)|.)/ig,
+ //modified version of https://github.com/jquery/sizzle/blob/master/src/sizzle.js#L87
+-re_attr = /^\s*((?:\\.|[\w\u00c0-\u\-])+)\s*(?:([~|^$*!]?)=\s*(?:(['"])(.*?)\3|(#?(?:\\.|[\w\u00c0-\u\-])*)|)|)\s*(i)?\]/;
++re_attr = /^((?:\\.|[\w\u00c0-\u\-])+)\s*(?:([~|^$*!]?)=\s*(?:(['"])(.*?)\3|(#?(?:\\.|[\w\u00c0-\u\-])*)|)|)\s*(i)?\]/;
+ 
+ var actionTypes = {
+ 	__proto__: null,
+@@ -146,7 +146,10 @@ function parseSelector(subselects, selector, options){
+ 	ignoreCase: false
+ });
+ 			} else if(firstChar === "["){
+-selector = selector.substr(1);
++			selector = selector.substr(1);
++			var wspace = selector.match(/^\s*/);
++

Bug#1032186: [Pkg-raspi-maintainers] Bug#1032186: raspi-firmware: Can make removing a kernel image fail and causing "apt upgrade" to fail early, too

2023-03-01 Thread Axel Beckert

Hi Diederik,

Diederik de Haas wrote:
> On Wednesday, 1 March 2023 12:48:49 CET Axel Beckert wrote:
> > A patch (without the proper indentation probably wanted for readability)
> > which seems to have helped for me:
[…]
> https://salsa.debian.org/debian/raspi-firmware/-/merge_requests/32 contains a 
> variation of your patch.

Thanks!

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

Bug#1032160: tfortune FTCBFS: multiple reasons

2023-03-01 Thread Andre Noll

On Wed, Mar 01, 01:12, Helmut Grohne wrote
> On Tue, Feb 28, 2023 at 11:13:24PM +0100, Andre Noll wrote:
> > > The immediate failure is failing to find the lopsub library since it
> > > configures for the build architecture. This happens as no --build nor 
> > > --host
> > > is passed which would have happened automatically if dh_auto_configure 
> > > could
> > > be used.  Thus it'll have to be passed manually.
> > 
> > Do you recommend to get rid of the override_dh_auto_configure target
> > in debian/rules?
> 
> As far as I understand it, you cannot. dh_auto_configure would pass
> options that configure does not understand.

This could be changed easily as the configure script of tfortune
is just a trivial wrapper which calls autoconf to create a standard
configure script and runs it. All arguments passed to configure are
passed through to the generated script.

> > I'm in favor of switching to something more standard, but I will
> > need your help. What's the best way forward to improve on the current
> > situation? Do you want me to apply your patch as is and push out the
> > result to the public repo? Is there anything else I can do to make
> > life easier for the Debian people?
> 
> If you are upstream, you can try making the build system behave more
> like a standard autoconf one. We tend to expect that:
>  * It uses a current version of autoconf that understands all options
>passed by dh_auto_configure (which could allow dropping the
>override).
>  * Enabling use of dh_autoreconf.
>  * Making the Makefile honour the settings (e.g. CC) detected by
>configure.
> 
> However, you may also choose to keep the present behaviour and apply my
> patch to make it cross buildable.

Let's take this easy route for now. I've applied your patch and used
most of the text of your original mail as the commit message. However,
I omitted the last part because I felt that the rant about the build
system, albeit justified, does not belong there :)

If you are OK with the commit message shown below, I'll merge the
commit into the master branch and push it out to the public repo.

> I recommend scheduling this update for the trixie cycle as bookworm is
> frozen and this is not an important bug.

This is where I need your help, as I'm unfamiliar with the usual
Debian procedures. How exactly do I schedule an update for trixie?

Thanks
Andre
---
commit 51a5a39de6d9527e38b84744abfa330ef36ab779
Author: Helmut Grohne 
Date:   Wed Mar 1 17:03:24 2023 +0100

Fix cross build.

The cross build fails to find the lopsub library since it configures
for the build architecture. This happens as no --build nor --host is
passed which would have happened automatically if dh_auto_configure
could be used. Thus it'll have to be passed manually. Then configure
fails finding config.h.in, which for some reason is not created (nor
asked for) by the override_dh_autoreconf. And finally, the actual
Makefile does not pick up the compiler detected by configure and
rather uses plain cc, so we'll have to tell it as well.

Signed-off-by: Andre Noll 

diff --git a/debian/changelog b/debian/changelog
index b54c641..ef53fa1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+tfortune (1.0.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Also ask for generating config.h.in, which otherwise goes missing in
+  cross builds.
++ Pass --build and --host to configure as we cannot use dh_auto_configure.
++ Also export cross tools for make.
+
+ -- Helmut Grohne   Tue, 28 Feb 2023 05:42:58 +0100
+
 tfortune (1.0.1-1) unstable; urgency=low
 
   * No changes relative to 1.0.0-2.
diff --git a/debian/rules b/debian/rules
index 03a9279..a360dc7 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,13 +1,18 @@
 #!/usr/bin/make -f
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+
+include /usr/share/dpkg/architecture.mk
+DPKG_EXPORT_BUILDTOOLS=1
+include /usr/share/dpkg/buildtools.mk
+
 %:
dh "$@"
 
 # plain dh_auto_configure uses options which configure does not understand
 override_dh_auto_configure:
./configure --prefix=/usr --bindir=/usr/games \
-   --datadir=/usr/share/games
+   --datadir=/usr/share/games --build=$(DEB_BUILD_GNU_TYPE) 
--host=$(DEB_HOST_GNU_TYPE)
 # needed because dh_autoreconf overwrites our configure wrapper
 override_dh_autoreconf:
-   $(MAKE) configure.sh
+   $(MAKE) config.h.in configure.sh
-- 
Max Planck Institute for Biology
Tel: (+49) 7071 601 829
Max-Planck-Ring 5, 72076 Tübingen, Germany
http://people.tuebingen.mpg.de/maan/


signature.asc
Description: PGP signature

Bug#1032205: bugs.debian.org: i915 GPU, displayport connector, monitor turns on and off randomly

2023-03-01 Thread Vladimir Egorin

Package: bugs.debian.org
Severity: normal

Dear Maintainer,

A NEC EA275UHD display is connected using DP cable
to an i3-8100 system. After turning the display
off using DPMS, the screen does not stay off.
It turns on at random intervals, displays a message that there
is no signal on the DP port, and goes back to sleep, repeat the cycle.

"cat /sys/devices/pci:00/:00:02.0/power/control"

outputs "auto".

echo "on" >  /sys/devices/pci:00/:00:02.0/power/control

eliminates this behavior.

I am using quality DP cables listed in VESA database, 2 meters long, and I tried
several cables from different manufactures.

I observe the same behavior with a different monitor connected
to the same machine.

Thanks.

Bug#1031863: libqt5sql5-mysql: incompatible change in libmariadb3 breaks kontact, needs upstream fix in libqt5sql5-mysql

2023-03-01 Thread Paul Boddie

On Wednesday, 1 March 2023 17:09:54 CET Otto Kekäläinen wrote:
> > > The fact that his issue surfaced now about something that changed in
> > > Debian 1-2 years ago and was changed upstream 2 years ago confuses me.
> > > Also I don't have any easy way to fire up a container and reproduce
> > > the issue.
> > 
> > It isn't really so mysterious, and I tried to explain it in the original
> > bug I filed against Kontact:
> i was referring to steps to reproduce.

Sorry, I can only really report how the bug arose on my system. Reproducing it 
would presumably involve creating an environment where Akonadi is initialised 
and then trying to access resources via Akonadi. Without some kind of test 
suite, which I presume does not already exist for Akonadi, that would 
potentially be a lot of work.

> > https://github.com/mariadb-corporation/mariadb-connector-c/commit/d204e831
> > 04222844251b221e9be7eb3dd9f8d63d
> Thanks for pointing this one. I was reading the commit
> https://github.com/mariadb-corporation/mariadb-connector-c/commit/a37b7c3965
> 706f9a062baaba0c494dd6efb2c306 that another reporter posted earlier.

Yes, it is difficult to navigate to the commit on the appropriate branch, and 
the involvement of mysql_get_client_info in that patch also confused me.

> > > However, as a clear patch was suggested I did it in
> > > https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commits/bugfix/1031
> > > 863-> libmariadb3-version-id
> ..
> 
> > It seems that the pipeline failed, but I managed to build a revised
> > package
> > anyway.
> 
> Salsa-CI is back online and
> https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commit/292377544983e0db
> 9b702399a977b900cdacbcee is building.

Thank you for activating this again.

Paul

Bug#1032137: ITP: python-hardware -- hardware detection and classification utilities

2023-03-01 Thread Antoine Beaupré

On 2023-02-28 15:18:33, Thomas Goirand wrote:
> * Package name: python-hardware
>   Description : hardware detection and classification utilities
>
>  Detect hardware features of a Linux systems:
>   * RAID
>   * hard drives
>   * IPMI
>   * network cards
>   * DMI infos
>   * memory settings
>   * processor features
>  .
>  Filter hardware according to hardware profiles.

Oh, this is interesting! There's very little documentation on the
upstream site, what do you plan on using this for?

It looks like a library I could very well use to rewrite stressant
into something more sane... It seems it even has benchmarks...

Thanks for any clarification!

-- 
We all pay for life with death, so everything in between should be
free.
 - Bill Hicks

signature.asc
Description: PGP signature

Bug#1032204: plover: Please upgrade to new version 4.0.0.dev12

2023-03-01 Thread Boyuan Yang

Source: plover
Severity: normal
Tags: sid
Version: 4.0.0~dev10-1

Dear Debian plover package maintainer,

Please consider packaging the new release of plover as released at
https://github.com/openstenoproject/plover/releases .

Just in case the new version needs some new dependency, I have packaged
plover-stroke at https://tracker.debian.org/pkg/plover-stroke . You are
welcome to examine and co-maintain plover-stroke as necessary.

Thanks,
Boyuan Yang


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

Bug#1032186: [Pkg-raspi-maintainers] Bug#1032186: raspi-firmware: Can make removing a kernel image fail and causing "apt upgrade" to fail early, too

2023-03-01 Thread Diederik de Haas

On Wednesday, 1 March 2023 12:48:49 CET Axel Beckert wrote:
> A patch (without the proper indentation probably wanted for readability)
> which seems to have helped for me:
> 
> diff --git a/kernel/postinst.d/z50-raspi-firmware
> b/kernel/postinst.d/z50-raspi-firmware index 1d3ae16..d898847 100755
> --- a/kernel/postinst.d/z50-raspi-firmware
> +++ b/kernel/postinst.d/z50-raspi-firmware
> @@ -115,6 +115,7 @@ else
>dtb_path="/usr/lib/linux-image-${latest_kernel#/boot/vmlinuz-}"
>  fi
> 
> +if [ "$1" != "remove" ]; then
>  if [ "$KERNEL" = "auto" ] ; then
>for dtb in "${dtb_path}"/bcm*.dtb; do
>  [ -e "${dtb}" ] || continue
> @@ -128,6 +129,7 @@ if [ "$KERNEL" = "auto" ] ; then
>cp "$latest_kernel" /boot/firmware/
>cp "$latest_initrd" /boot/firmware/
>  fi
> +fi

https://salsa.debian.org/debian/raspi-firmware/-/merge_requests/32 contains a 
variation of your patch.

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

Bug#1031863: libqt5sql5-mysql: incompatible change in libmariadb3 breaks kontact, needs upstream fix in libqt5sql5-mysql

2023-03-01 Thread Otto Kekäläinen

> > The fact that his issue surfaced now about something that changed in
> > Debian 1-2 years ago and was changed upstream 2 years ago confuses me.
> > Also I don't have any easy way to fire up a container and reproduce
> > the issue.
>
> It isn't really so mysterious, and I tried to explain it in the original bug I
> filed against Kontact:

i was referring to steps to reproduce.

> https://github.com/mariadb-corporation/mariadb-connector-c/commit/d204e83104222844251b221e9be7eb3dd9f8d63d

Thanks for pointing this one. I was reading the commit
https://github.com/mariadb-corporation/mariadb-connector-c/commit/a37b7c3965706f9a062baaba0c494dd6efb2c306
that another reporter posted earlier.

> > However, as a clear patch was suggested I did it in
> > https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commits/bugfix/1031863->
> >  libmariadb3-version-id
>
..
> It seems that the pipeline failed, but I managed to build a revised package
> anyway.

Salsa-CI is back online and
https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commit/292377544983e0db9b702399a977b900cdacbcee
is building.

Bug#1032203: Please backport version 4.4.0

2023-03-01 Thread Enrico Zini

Package: python3-typing-extensions
Version: 4.4.0-1
Severity: wishlist

Hello,

thanks for packaging python3-typing-extensions!

Now that 4.4.0 is in testing, would it be possible to also upload it to
backports?

It contains support for python 3.11 typing additions, and since python
3.11 is the version that is going to be in the new stable, having it in
bullseye-backports would allow to start targeting bookworm a bit more
during Python development.

Thanks,

Enrico


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

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

Versions of packages python3-typing-extensions depends on:
ii  python3  3.11.2-1

python3-typing-extensions recommends no packages.

python3-typing-extensions suggests no packages.

-- no debconf information

Bug#1032202: New buttercup_eval directive

2023-03-01 Thread Sergio Durigan Junior

Source: dh-elpa
Version: 2.0.16
Severity: normal

Hi,

I would like to propose the inlined patch to implement a new
buttercup_eval directive on dh-elpa.  Aside from the fact that this is a
good-to-have feature, there is a bigger problem at play here: it's
currently not possible to eval elisp code when buttercup is invoked
during autopkgtest, which makes workarounds like the one uploaded for
flycheck (at bug #1028725) incomplete.

It'd be great if we could have this in bookworm, but due to the freeze
I'd understand if it's not possible.  I'd like to have this in unstable
ASAP, though, if that's OK with you.

Thank you,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/

diff --git a/debian/changelog b/debian/changelog
index f4bee52..7782294 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+dh-elpa (2.0.17) unstable; urgency=medium
+
+  * dh_elpa_test: Implement new buttercup_eval directive.
+
+ -- Sergio Durigan Junior   Wed, 01 Mar 2023 10:26:11 
-0500
+
 dh-elpa (2.0.16) unstable; urgency=medium
 
   * Drop dependencies on emacs-el introduced in 2.0.11.
diff --git a/dh_elpa_test b/dh_elpa_test
index c2504bf..d0a252d 100755
--- a/dh_elpa_test
+++ b/dh_elpa_test
@@ -86,6 +86,10 @@ run.  If this key is not defined, all tests that can be found
 will be run.  Will be passed to buttercup(1) with its B<-p> command
 line argument.
 
+=item B
+
+Emacs Lisp code to be run by buttercup's --eval option.
+
 =item B
 
 A comma-separated list of file globs matching files containing ERT
@@ -341,6 +345,8 @@ if ($control->source->Build_Depends->has( "elpa-buttercup" 
)) {
 push @args, ('-p', "$pattern");
 }
 }
+push @args, ("--eval", $options->{_}->{'buttercup_eval'})
+  if (defined $options->{_}->{'buttercup_eval'});
 print_and_doit(@args);
 }
 


signature.asc
Description: PGP signature

Bug#1026539: How much do we lose if we remove theano (+keras, deepnano, invesalius)?

2023-03-01 Thread Andreas Tille

Control: tags -1 pending

Hi,

> Andrius Merkys wrote:
> That said, it is OK to omit keras in bookworm if need be, but I would 
> like to see it back for trixie.

I've spent some time into theano and it builds and runs its test suite
in Salsa CI[1].  Since despite some tests are failing in my local
pbuilder environment I'd be happy if someone else could run some test
build before uploading.  I decided for the latest upstream that was
prepared by Rebecca and I also sneaked into the aesara fork[2] to copy
some solutions they found for numpy 1.24 compatibility.

I think we can not really loose much by taking this code from
experimental since if we break something it can be removed which is
the consensus we've somehow found before.  In case it might work we
have saved something for bookworm.  Regarding future releases we
should probably check whether those packages we want to save will
work with aesara.

Kind regards
   Andreas.

[1] https://salsa.debian.org/science-team/theano/-/pipelines/506598
[2] https://github.com/aesara-devs/aesara

-- 
http://fam-tille.de

Bug#1031863: libqt5sql5-mysql: incompatible change in libmariadb3 breaks kontact, needs upstream fix in libqt5sql5-mysql

2023-03-01 Thread Paul Boddie

On Wednesday, 1 March 2023 07:24:23 CET Otto Kekäläinen wrote:
> 
> The fact that his issue surfaced now about something that changed in
> Debian 1-2 years ago and was changed upstream 2 years ago confuses me.
> Also I don't have any easy way to fire up a container and reproduce
> the issue.

It isn't really so mysterious, and I tried to explain it in the original bug I 
filed against Kontact:

1. A change in MariaDB 10.6 broke Qt's MySQL support back in 2021.

2. Someone decided to let this change leak into MariaDB 10.3.38.

3. A Debian package for 10.3.38 was finalised in the last couple of weeks and 
arrived last week.

4. Suddenly, Akonadi cannot connect to MySQL properly and Kontact won't show 
the contents of mail messages any more.

How the change leaked is more mysterious. However, going to the 10.3 branch of 
the server, following the link to libmariadb and the mariadb-connector-c 
repository and using the "blame" tool yields this commit:

https://github.com/mariadb-corporation/mariadb-connector-c/commit/
d204e83104222844251b221e9be7eb3dd9f8d63d

That was made two months ago, but I imagine that the workflow propagated it in 
various branches for a while before a release was actually made.

> However, as a clear patch was suggested I did it in
> https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commits/bugfix/1031863-> 
> libmariadb3-version-id

I realised that I had messed up my own patch, explaining why I didn't see any 
change in behaviour with my revised package, but rebuilding again and testing 
now, I can confirm that the above patch fixes the problem. Reverting to the 
distribution-supplied libqt5sql5-mysql package and using the patched version 
of libmariadb3 makes Kontact and Akonadi work again.

> The the Salsa runner comes back online and pipeline works again, there
> will be build artifacts available at
> https://salsa.debian.org/mariadb-team/mariadb-10.3/-/jobs/4004950 and
> you can download the libmariadb3 with this patched and test if it
> fixes your mail client situation.

It seems that the pipeline failed, but I managed to build a revised package 
anyway.

I have no idea about whether other software has been broken by this, but 
anyone using the distribution-supplied packages for libmariadb3 and 
libqt5sql5-mysql will have seen programs break.

Maybe only the Akonadi stack is affected as a consequence. Since people tend 
to abandon the KDE groupware programs every time something breaks, it is 
entirely possible that there are relatively few users left to complain.

All this effort for a single-token change in a file that shouldn't have been 
made in the first place!

Paul

Bug#1031622: d-i regression in weekly builds: FEATURE_C12 unsupported by the installed e2fsck

2023-03-01 Thread Marc Leeman

Note that updating ext2fs with these new features also breaks other
software components like refind (volume detection) in bookworm (this is how
I came to this bug).

Bug#1029821: change gnome-desktop's default choice of Japanese input methods

2023-03-01 Thread YOSHINO Yoshihito

Control: severity -1 grave

Dear Maintainer,

This bug is critical to most Japanese language users. In a fresh GNOME
desktop installation by bookworm d-i, after the first login
gnome-initial-setup pops up and breaks the default Japanese input method
with the inappropriate config in this package.

I really hope this will be fixed before the release.

Thanks in advance,
-- 
YOSHINO Yoshihito

Bug#1032188: debdiff

2023-03-01 Thread Bastien Roucariès

Dear security team,

For bullseye will you find the debdiff attached.

Waiting for your instruction

Bastiendiff -Nru node-css-what-4.0.0/debian/changelog node-css-what-4.0.0/debian/changelog
--- node-css-what-4.0.0/debian/changelog	2021-01-09 21:06:15.0 +
+++ node-css-what-4.0.0/debian/changelog	2023-03-01 13:47:23.0 +
@@ -1,3 +1,15 @@
+node-css-what (4.0.0-3+deb11u1) bullseye-security; urgency=medium
+
+  * Team upload
+  * node-css-what was vulnerable to Regular Expression Denial of Service
+(ReDoS) due to the usage of insecure regular expression in the
+re_attr variable.
+The exploitation of this vulnerability could be triggered
+via the parse function.
+Fix CVE-2022-21222, CVE-2021-33587 (Closes: #989264, #1032188)
+
+ -- Bastien Roucariès   Wed, 01 Mar 2023 13:47:23 +
+
 node-css-what (4.0.0-3) unstable; urgency=medium
 
   * Team upload
diff -Nru node-css-what-4.0.0/debian/patches/0001-Partial-fix-of-reDos-CVE-2022-21222-CVE-2021-33587-a.patch node-css-what-4.0.0/debian/patches/0001-Partial-fix-of-reDos-CVE-2022-21222-CVE-2021-33587-a.patch
--- node-css-what-4.0.0/debian/patches/0001-Partial-fix-of-reDos-CVE-2022-21222-CVE-2021-33587-a.patch	1970-01-01 00:00:00.0 +
+++ node-css-what-4.0.0/debian/patches/0001-Partial-fix-of-reDos-CVE-2022-21222-CVE-2021-33587-a.patch	2023-03-01 13:47:23.0 +
@@ -0,0 +1,36 @@
+From: =?utf-8?q?Bastien_Roucari=C3=A8s?= 
+Date: Wed, 1 Mar 2023 08:12:48 +
+Subject: Partial fix of reDos CVE-2022-21222/CVE-2021-33587: attribute
+ selector
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+Per https://w3c.github.io/csswg-drafts/selectors/#attribute-selectors only = ~= |= ^= $= *= are supported.
+
+Add also != that is checked as invalid latter in order to pass testsuite.
+
+So replace \S by [~|^$*!]
+
+Signed-off-by: Bastien Roucariès 
+bug-debian: https://bugs.debian.org/989264
+bug-debian: https://bugs.debian.org/1032188
+bug: https://www.cve.org/CVERecord?id=CVE-2022-21222
+bug: https://www.cve.org/CVERecord?id=CVE-2021-33587
+---
+ src/parse.ts | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/parse.ts b/src/parse.ts
+index 677a029..628561b 100644
+--- a/src/parse.ts
 b/src/parse.ts
+@@ -81,7 +81,7 @@ export type TraversalType =
+ const reName = /^[^\\#]?(?:\\(?:[\da-f]{1,6}\s?|.)|[\w\-\u00b0-\u])+/;
+ const reEscape = /\\([\da-f]{1,6}\s?|(\s)|.)/gi;
+ // Modified version of https://github.com/jquery/sizzle/blob/master/src/sizzle.js#L87
+-const reAttr = /^\s*(?:(\*|[-\w]*)\|)?((?:\\.|[\w\u00b0-\u-])+)\s*(?:(\S?)=\s*(?:(['"])((?:[^\\]|\\[^])*?)\4|(#?(?:\\.|[\w\u00b0-\u-])*)|)|)\s*([iI])?\]/;
++const reAttr = /^\s*(?:(\*|[-\w]*)\|)?((?:\\.|[\w\u00b0-\u-])+)\s*(?:([~|^$*!]?)=\s*(?:(['"])((?:[^\\]|\\[^])*?)\4|(#?(?:\\.|[\w\u00b0-\u-])*)|)|)\s*([iI])?\]/;
+ 
+ const actionTypes: { [key: string]: AttributeAction } = {
+ undefined: "exists",
diff -Nru node-css-what-4.0.0/debian/patches/0002-Partial-fix-of-ReDos-CVE-2022-21222-CVE-2021-33587-t.patch node-css-what-4.0.0/debian/patches/0002-Partial-fix-of-ReDos-CVE-2022-21222-CVE-2021-33587-t.patch
--- node-css-what-4.0.0/debian/patches/0002-Partial-fix-of-ReDos-CVE-2022-21222-CVE-2021-33587-t.patch	1970-01-01 00:00:00.0 +
+++ node-css-what-4.0.0/debian/patches/0002-Partial-fix-of-ReDos-CVE-2022-21222-CVE-2021-33587-t.patch	2023-03-01 13:47:23.0 +
@@ -0,0 +1,55 @@
+From: =?utf-8?q?Bastien_Roucari=C3=A8s?= 
+Date: Wed, 1 Mar 2023 10:10:47 +
+Subject: Partial fix of ReDos CVE-2022-21222/CVE-2021-33587: trim string
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+Trim left the string avoiding a \s* at the beginning of the string, thus avoiding part of complexity.
+
+bug-debian: https://bugs.debian.org/989264
+bug-debian: https://bugs.debian.org/1032188
+bug: https://www.cve.org/CVERecord?id=CVE-2022-21222
+bug: https://www.cve.org/CVERecord?id=CVE-2021-33587
+Signed-off-by: Bastien Roucariès 
+---
+ src/parse.ts | 11 ---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+diff --git a/src/parse.ts b/src/parse.ts
+index 628561b..ad11230 100644
+--- a/src/parse.ts
 b/src/parse.ts
+@@ -81,7 +81,7 @@ export type TraversalType =
+ const reName = /^[^\\#]?(?:\\(?:[\da-f]{1,6}\s?|.)|[\w\-\u00b0-\u])+/;
+ const reEscape = /\\([\da-f]{1,6}\s?|(\s)|.)/gi;
+ // Modified version of https://github.com/jquery/sizzle/blob/master/src/sizzle.js#L87
+-const reAttr = /^\s*(?:(\*|[-\w]*)\|)?((?:\\.|[\w\u00b0-\u-])+)\s*(?:([~|^$*!]?)=\s*(?:(['"])((?:[^\\]|\\[^])*?)\4|(#?(?:\\.|[\w\u00b0-\u-])*)|)|)\s*([iI])?\]/;
++const reAttr = /^(?:(\*|[-\w]*)\|)?((?:\\.|[\w\u00b0-\u-])+)\s*(?:([~|^$*!]?)=\s*(?:(['"])((?:[^\\]|\\[^])*?)\4|(#?(?:\\.|[\w\u00b0-\u-])*)|)|)\s*([iI])?\]/;
+ 
+ const actionTypes: { [key: string]: AttributeAction } = {
+ undefined: "exists",
+@@ -263,8

Bug#1032201: snmpd: uses chown user.group syntax

Package: snmpd
Version: 5.9.3+dfsg-2
Severity: normal
Tags: patch

Dear Maintainer,

chown user.group is an ancient BSD remnant, and also invalid, since,
naturally, usernames can have dots in them
(coreutils really ought to start warning on this nonstandard usage).

Attaching patch based on current Salsa HEAD (e2da187de2da19a4aa8e9520)
to turn the one usage into correct user:group.

Best,
наб

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

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

Versions of packages snmpd depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.77
ii  init-system-helpers1.60
ii  libc6  2.31-13+deb11u5
ii  libsnmp-base   5.9+dfsg-4+deb11u1
ii  libsnmp40  5.9+dfsg-4+deb11u1
ii  lsb-base   11.1.0

snmpd recommends no packages.

Versions of packages snmpd suggests:
pn  snmptrapd  

-- Configuration Files:
/etc/snmp/snmpd.conf [Errno 13] Permission denied: '/etc/snmp/snmpd.conf'

-- debconf information excluded
From 6f657dbc5a1bcdaab4000eea628f4561a5228f18 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=BD=D0=B0=D0=B1?= 
Date: Wed, 1 Mar 2023 14:54:47 +0100
Subject: [PATCH] snmpd.postinst: use legal chown syntax
X-Mutt-PGP: OS

---
 debian/snmpd.postinst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/snmpd.postinst b/debian/snmpd.postinst
index 51b949f..e73f4c4 100644
--- a/debian/snmpd.postinst
+++ b/debian/snmpd.postinst
@@ -19,9 +19,9 @@ case "$1" in
 --shell "$SNMP_SHELL" --force-badname "$SNMP_USER"
 
 # care if SNMP_DIR is used by previous "snmp" user
-chown "$SNMP_USER"."$SNMP_GROUP" "$SNMP_DIR"
+chown "$SNMP_USER":"$SNMP_GROUP" "$SNMP_DIR"
 	if [ -f "$SNMP_DIR/snmpd.conf" ]; then
-chown "$SNMP_USER"."$SNMP_GROUP" "$SNMP_DIR/snmpd.conf"
+chown "$SNMP_USER":"$SNMP_GROUP" "$SNMP_DIR/snmpd.conf"
 	fi
 
 	# Change group of snmpd.conf to SNMP_GROUP #998152
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#1032200: mosquitto: leaves behind mosquitto user and group on purge

One day I'll attach a patch when I say I am.
From 67c3d7fb00b2e538d19eaa354afa51efe44dd7bf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=BD=D0=B0=D0=B1?= 
Date: Wed, 1 Mar 2023 14:51:03 +0100
Subject: [PATCH] Remove mosquitto UID and GID on purge
X-Mutt-PGP: OS

---
 debian/mosquitto.postrm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/mosquitto.postrm b/debian/mosquitto.postrm
index 17052329..ac5a13c4 100644
--- a/debian/mosquitto.postrm
+++ b/debian/mosquitto.postrm
@@ -19,6 +19,8 @@ case "$1" in
 		if [ -d /run/mosquitto ]; then
 			rmdir --ignore-fail-on-non-empty /run/mosquitto
 		fi
+		deluser --quiet --system mosquitto || :
+		delgroup --quiet --system mosquitto || :
 APP_PROFILE="usr.sbin.mosquitto"
 rm -f /etc/apparmor.d/disable/$APP_PROFILE >/dev/null 2>&1 || true
 	;;
-- 
2.30.2

signature.asc
Description: PGP signature

Bug#1032200: mosquitto: leaves behind mosquitto user and group on purge

Package: mosquitto
Version: 2.0.11-1
Severity: normal
Tags: patch

Dear Maintainer,

I purged mosquitto a few weeks ago; imagine my surprise when:
-- >8 --
$ getent passwd mosquitto
mosquitto:x:131:144::/var/lib/mosquitto:/usr/sbin/nologin
$ getent group mosquitto
mosquitto:x:144:
$ dpkg -l mosquitto
dpkg-query: no packages found matching mosquitto
-- >8 --

I'm attaching a patch that fixes this, based on the debian HEAD (1ca9e5984b2);
modelled off snmpd.postinst, so presumably correct.

Best,
наб

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

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

Versions of packages mosquitto depends on:
ii  adduser  3.118
ii  libc62.31-13+deb11u5
pn  libcjson1
pn  libdlt2  
pn  libmosquitto1
ii  libssl1.11.1.1n-0+deb11u4
ii  libsystemd0  247.3-7+deb11u1
pn  libwebsockets16  
ii  libwrap0 7.6.q-31
ii  lsb-base 11.1.0

mosquitto recommends no packages.

Versions of packages mosquitto suggests:
ii  apparmor  2.13.6-10


signature.asc
Description: PGP signature

Bug#1032199: Native compilation fails to generate trampolines on certain scenarios

2023-03-01 Thread Sergio Durigan Junior

Package: emacs
Version: 1:28.2+1-11
Severity: important
Forwarded: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61880

[ This is the downstream equivalent of
  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61880 ]

Hello,

While investigating a few bugs affecting Debian's and Ubuntu's Emacs
packages (for example,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028725), I stumbled
upon a problem that's affecting native compilation on Emacs 28.1+,
currently reproducible with git master as well.

I haven't been able to fully understand why the problem is happening,
but when there are two primitive functions (that would become
trampolines) being used sequentially, Emacs doesn't generate the
corresponding .eln file for the second function.

I spent some time investigating the problem and came up with a "minimal"
reproducer:

--8<---cut here---start->8---
(require 'cl-lib)

(defmacro foo--flet (funcs  body)
  "Like `cl-flet' but with dynamic function scope."
  (declare (indent 1))  

  
  (let* ((names (mapcar #'car funcs))
 (lambdas (mapcar #'cdr funcs))
 (gensyms (cl-loop for name in names
   collect (make-symbol (symbol-name name)
`(let ,(cl-loop for name in names
for gensym in gensyms
collect `(,gensym (symbol-function ',name)))
   (unwind-protect
   (progn
 ,@(cl-loop for name in names
for lambda in lambdas
for body = `(lambda ,@lambda)
collect `(setf (symbol-function ',name) ,body))
 ,@body)
 ,@(cl-loop for name in names
for gensym in gensyms
collect `(setf (symbol-function ',name) ,gensym))

(defun bar (file)
  (and (file-exists-p file) (file-readable-p file)))

(defun test ()
  (foo--flet ((file-exists-p (file) t)
  (file-readable-p (file) nil))
(message "%s" (bar "/home/sergio/.lesshst"
--8<---cut here---end--->8---

When I run it using the following Emacs:

--8<---cut here---start->8---
GNU Emacs 30.0.50
Development version 68cc286c0495 on master branch; build date 2023-02-28.
--8<---cut here---end--->8---

here is the output I see:

--8<---cut here---start->8---
$ emacs -batch -Q -l t.el -f test -L .
Error: native-lisp-load-failed ("file does not exists" 
"/home/sergio/.emacs.d/eln-cache/30.0.50-23de7b18/subr--trampoline-66696c652d7265616461626c652d70_file_readable_p_0.eln")
  debug-early-backtrace()
  debug-early(error (native-lisp-load-failed "file does not exists" 
"/home/sergio/.emacs.d/eln-cache/30.0.50-23de7b18/subr--trampoline-66696c652d7265616461626c652d70_file_readable_p_0.eln"))
  
native-elisp-load("/home/sergio/.emacs.d/eln-cache/30.0.50-23de7b18/subr--trampoline-66696c652d7265616461626c652d70_file_readable_p_0.eln")
  comp-trampoline-search(file-readable-p)
  comp-subr-trampoline-install(file-readable-p)
  fset(file-readable-p (lambda (file) nil))
  (progn (fset 'file-exists-p #'(lambda (file) t)) (fset 'file-readable-p 
#'(lambda (file) nil)) (message "%s" (bar "/home/sergio/.lesshst")))
  (unwind-protect (progn (fset 'file-exists-p #'(lambda (file) t)) (fset 
'file-readable-p #'(lambda (file) nil)) (message "%s" (bar 
"/home/sergio/.lesshst"))) (fset 'file-exists-p file-exist
s-p) (fset 'file-readable-p file-readable-p))
  (let ((file-exists-p (symbol-function 'file-exists-p)) (file-readable-p 
(symbol-function 'file-readable-p))) (unwind-protect (progn (fset 
'file-exists-p #'(lambda (file) t)) (fset 'file-re
adable-p #'(lambda (file) nil)) (message "%s" (bar "/home/sergio/.lesshst"))) 
(fset 'file-exists-p file-exists-p) (fset 'file-readable-p file-readable-p)))
  test()
  command-line-1(("-l" "t.el" "-f" "test" "-L" "."))
  command-line()
  normal-top-level()
Native elisp load failed: "file does not exists", 
"/home/sergio/.emacs.d/eln-cache/30.0.50-23de7b18/subr--trampoline-66696c652d7265616461626c652d70_file_readable_p_0.eln"
--8<---cut here---end--->8---

Do note that this is already affecting a few packages, like buttercup
(see https://github.com/jorgenschaefer/emacs-buttercup/issues/230) and
emacs-web-server, for example.

Please let me know if you need more information regarding the problem.

Thank you,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#1030284: [Pkg-javascript-devel] Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded

2023-03-01 Thread Jérémy Lal

Le mer. 1 mars 2023 à 14:39, James Addison  a écrit :

> If reproducible: would this bug be a good candidate for upload of a
> fix to 'experimental' so that it can be alpha-tested by others?
>

Sure.

For now I'm unlucky with the porterbox, because /var/run/schroot
disappeared yesterday.
Notified debian-admin.

Jérémy

Bug#1030284: [Pkg-javascript-devel] Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded