date:20211230

Package: primesense-nite-nonfree
Version: 0.1.1
Severity: serious
Tags: sid bookworm
User: nthyk...@master.debian.org
Usertags: compat-5-6-removal

Hi,

The package primesense-nite-nonfree uses debhelper with a compat level of 5 or 
6,
which is no longer supported [1].

Please bump the debhelper compat at your earliest convenience

  * Compat 13 is recommended (supported in stable-backports)

  * Compat 7 is the bare minimum


Thanks,
Andreas

[1] https://lists.debian.org/debian-devel/2020/07/msg00065.html

Bug#1002886: human-icon-theme: Removal of obsolete debhelper compat 5 and 6 in bookworm

Package: human-icon-theme
Version: 0.28.debian-6.1
Severity: serious
Tags: sid bookworm
User: nthyk...@master.debian.org
Usertags: compat-5-6-removal

Hi,

The package human-icon-theme uses debhelper with a compat level of 5 or 6,
which is no longer supported [1].

Please bump the debhelper compat at your earliest convenience

  * Compat 13 is recommended (supported in stable-backports)

  * Compat 7 is the bare minimum


Thanks,
Andreas

[1] https://lists.debian.org/debian-devel/2020/07/msg00065.html

Bug#1002885: tangerine-icon-theme: Removal of obsolete debhelper compat 5 and 6 in bookworm

Package: tangerine-icon-theme
Version: 0.26.debian-5
Severity: serious
Tags: sid bookworm
User: nthyk...@master.debian.org
Usertags: compat-5-6-removal

Hi,

The package tangerine-icon-theme uses debhelper with a compat level of 5 or 6,
which is no longer supported [1].

Please bump the debhelper compat at your earliest convenience

  * Compat 13 is recommended (supported in stable-backports)

  * Compat 7 is the bare minimum


Thanks,
Andreas

[1] https://lists.debian.org/debian-devel/2020/07/msg00065.html

Bug#1002884: titantools: Removal of obsolete debhelper compat 5 and 6 in bookworm

Package: titantools
Version: 4.0.11+notdfsg1-6
Severity: serious
Tags: sid bookworm
User: nthyk...@master.debian.org
Usertags: compat-5-6-removal

Hi,

The package titantools uses debhelper with a compat level of 5 or 6,
which is no longer supported [1].

Please bump the debhelper compat at your earliest convenience

  * Compat 13 is recommended (supported in stable-backports)

  * Compat 7 is the bare minimum


Thanks,
Andreas

[1] https://lists.debian.org/debian-devel/2020/07/msg00065.html

Bug#1002579: libfltk1.3-dev: libfltk1.3-dev is not Multi-Arch:same

2021-12-30 Thread Aaron M. Ucko

Dima Kogan  writes:

>   /bin/sh: 1: test: =: unexpected operator

For whatever reason, I didn't run into that one; I'll look into it.
Thanks for pointing it out and for confirming that all is otherwise
well.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#941214: [Pkg-zsh-devel] Bug#941214: mutt zsh completion broken, -a does not take email address

2021-12-30 Thread Daniel Shahaf

martin f krafft wrote on Fri, Dec 31, 2021 at 15:26:24 +1300:
> Regarding the following, written by "Daniel Shahaf" on 2021-12-31 at 02:16 
> Uhr +:
> > The two consecutive colons on the -a line mean the -a option takes an
> > optional argument.
> 
> Herein lies the problem:
> 
> ```
>   -a  [...] --  attach file(s) to the message
>   the list of files must be terminated with the "--" sequence
> ```
> 
> So it's neither optional, nor even a single word by necessity.

Good catch.

I think it's possible to teach _mutt how to complete this in the general
case, but the details are better hashed out upstream (zsh-work...@zsh.org).

Cheers,

Daniel

Bug#1002880: signing-party: caff defaults to retired pool.sks-keyservers.net

2021-12-30 Thread Aaron M. Ucko

Guilhem Moulin  writes:

> Hi,

Hi.  Thanks for the quick response!

> Seems I forgot to update caffrc.sample :-), but since 2.3-1 caff doesn't
> hardcode its own keyserver.

Ah, OK.  AFAICT, I've been using caff since 2010, so I suppose I
shouldn't be surprised that my ~/.caff could use some modernization. :-)
In particular, I still have a ~/.caff/gnupghome/options containing

  keyserver pool.sks-keyservers.net

> I'm not sure what's the best substitute at the moment as 
> hkps://keys.openpgp.org
> doesn't send third-party signatures.

That's fair.  In that case, though, perhaps caff should refrain from
suggesting any specific server or pool until there's a sufficiently good
choice again.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#941214: [Pkg-zsh-devel] Bug#941214: mutt zsh completion broken, -a does not take email address

2021-12-30 Thread martin f krafft


Regarding the following, written by "Daniel Shahaf" on 2021-12-31 at 02:16 Uhr 
+:
The two consecutive colons on the -a line mean the -a option takes 
an optional argument.


Herein lies the problem:

```
  -a  [...] --  attach file(s) to the message
the list of files must be terminated with the "--" sequence
```

So it's neither optional, nor even a single word by necessity.

--
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"the college students who are using lsd and marijuana today do not

 comprise a criminal class. they are not drug addicts seeking to
 escape. they're your best educated, your most creative, and your
 most couragious, young people. and like it or not, they might build
 you a new civilisation."   -- porcupine tree, voyage 34

Bug#941214: [Pkg-zsh-devel] Bug#941214: mutt zsh completion broken, -a does not take email address

2021-12-30 Thread Daniel Shahaf

David Bremner wrote on Sun, Dec 26, 2021 at 07:54:35 -0400:
> David Bremner  writes:
> 
> > martin f krafft  writes:
> >
> >> Package: notmuch
> >> Version: 0.29.1-2
> >> Severity: normal
> >> File: /usr/share/zsh/vendor-completions/_email-notmuch
> >>
> >> mutt has a command-line switch '-a' for attachments, and the Zsh 
> >> completer offers files and directories for its argument.
> >>
> >> As of late, _email-notmuch also adds all addresses into the mix:
> >>
> >> % mutt -a ^D
> >> directory
> >> […]
> >> file attachment
> >> […]
> >> email address (notmuch)
> >> […]
> >>
> >>
> >> In the context of '-a', no email addresses should be offered. Maybe 
> >> this is actually a problem with Zsh or Mutt, I can't figure it out. 
> >> But since I see mainly notmuch in the output, I am filing here…
> >
> > As far as I can tell, the whole point of _email-notmuch is to provide
> > addresses, so maybe it shouldn't be called there? To me that suggests
> > the bug should be reassigned to mutt. I am CCing the mutt maintainers,
> > in case they want to weigh in.
> >
> > d
> 
> My mistake, the mutt completion is actually shipped by zsh. I've
> attached _email-notmuch (installed by package notmuch) for feedback. If
> something looks wrong with it, please let me know. Otherwise I think I
> should reassign this bug to zsh, where it can at least get some more
> expert consideration.

By code inspection:

Email addresses are offered because the function _mutt (from the file of
the same name shipped by zsh-common) contains:
.
_arguments -s -S \
  '::recipient:_email_addresses -n mutt' \
  '*-a[attach file using MIME]::file attachment:_files' \
.
which is as self-explanatory as it gets, of course ☺

The two consecutive colons on the -a line mean the -a option takes an
optional argument.  Therefore, «mutt -a » completes both arguments
to -a, using _files, and email addresses, using «_email_addresses -n
mutt» (which presumably calls _email-notmuch along with other _email-*
functions).  Still by code inspection, if you remove one of the two
consecutive colons on the -a line, email addresses shouldn't be offered
any more.

If the above analysis is correct, this bug report belongs to zsh-common.

Furthermore, if invocations such as «mutt -a f...@example.com» and «mutt
-a» without further arguments are errors (they are in older mutts, but I
haven't tested in sid), then the report is valid and the fix would be to
drop the second consecutive colon from the -a line in _mutt.

Cheers,

Daniel

Bug#1002851: xdelta 1.1.3-10.2 merged, nmudiff

2021-12-30 Thread Jelmer Vernooĳ

Hi Ian,

Thanks for cleaning up this mess, and apologies for creating it in the
first place... I agree the tooling could & should be better here, but
I still should have caught this while I did the upload.

The changes look good to me.

Jelmer

On Fri, Dec 31, 2021 at 12:09:29AM +, Ian Jackson wrote:
> Hi.  I have just pushed a version of xdelta which resolves the changes
> made in 1.1.3-9.4 with those made in 1.1.3-10.1 (which was mistakenly
> based on 1.1.3-9, omitting the intervening NMU changes).
> 
> The resulting package now has the libraries in the multiarch paths.  I
> think all is probably well, but the package doesn't have
> autopkgtests.  Typing "xdelta" with the .debs installed works so I
> think it's fine ?  I hope some other package's autopkgtests will
> detect it if not.
> 
> Here is the numduff.  It is against 1.1.3-9.4.  I think this should be
> regarded as the nmudiff for both #965890 and #1002851.  Diffs
> involving 1.1.3-10.1 are unreasonably cluttered by autogenerated file
> changes.
> 
> I hope this meets with everyone's approval.
> Happy new year!
> 
> Ian.
> 


> 
> 
> -- 
> Ian JacksonThese opinions are my own.  
> 
> Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
> that is a private address which bypasses my fierce spamfilter.


-- 
Jelmer Vernooĳ 
PGP Key: https://www.jelmer.uk/D729A457.asc


signature.asc
Description: PGP signature

Bug#972536: close 972536

2021-12-30 Thread 肖盛文）


Yes, The old version 3.0.4+dfsg-23 is deleted from sid already.

Let us close it.



OpenPGP_0x2F338C7DC7909957.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1002850: Re (2): Bug#1002850: udev fails to create a symlink for a SDHC card; udevadm info reports.

2021-12-30 Thread peter

From: Michael Biebl 
Date:   Thu, 30 Dec 2021 23:56:05 +0100
> you posted the same info twice. Please drop the -a

Sorry; this should be from "udevadm info /dev/sdb1".

P: 
/devices/pci:00/:00:11.2/usb1/1-2/1-2:1.0/host3/target3:0:0/3:0:0:0/block/sdb/sdb1
N: sdb1
L: 0
S: disk/by-partuuid/000152b8-01
S: disk/by-uuid/d8082dc5-9243-433c-81bc-6388e3564117
S: disk/by-path/pci-:00:11.2-usb-0:2:1.0-scsi-0:0:0:0-part1
S: disk/by-label/GRNSD
S: disk/by-id/usb-USB2.0_CARD-READER_0201202010201000-0:0-part1
E: 
DEVPATH=/devices/pci:00/:00:11.2/usb1/1-2/1-2:1.0/host3/target3:0:0/3:0:0:0/block/sdb/sdb1
E: DEVNAME=/dev/sdb1
E: DEVTYPE=partition
E: PARTN=1
E: MAJOR=8
E: MINOR=17
E: SUBSYSTEM=block
E: USEC_INITIALIZED=19923576
E: ID_SCSI=1
E: SCSI_TPGS=0
E: SCSI_TYPE=disk
E: SCSI_VENDOR=USB2.0
E: SCSI_VENDOR_ENC=USB2.0\x20\x20
E: SCSI_MODEL=CARD-READER
E: SCSI_MODEL_ENC=CARD-READER\x20\x20\x20\x20\x20
E: SCSI_REVISION=1.01
E: ID_VENDOR=USB2.0
E: ID_VENDOR_ENC=USB2.0\x20\x20
E: ID_MODEL=CARD-READER
E: ID_MODEL_ENC=CARD-READER\x20\x20\x20\x20\x20
E: ID_REVISION=1.01
E: ID_TYPE=disk
E: ID_SCSI_INQUIRY=1
E: ID_VENDOR_ID=214b
E: ID_MODEL_ID=1101
E: ID_SERIAL=USB2.0_CARD-READER_0201202010201000-0:0
E: ID_SERIAL_SHORT=0201202010201000
E: ID_INSTANCE=0:0
E: ID_BUS=usb
E: ID_USB_INTERFACES=:080650:
E: ID_USB_INTERFACE_NUM=00
E: ID_USB_DRIVER=usb-storage
E: ID_PATH=pci-:00:11.2-usb-0:2:1.0-scsi-0:0:0:0
E: ID_PATH_TAG=pci-_00_11_2-usb-0_2_1_0-scsi-0_0_0_0
E: ID_PART_TABLE_UUID=000152b8
E: ID_PART_TABLE_TYPE=dos
E: ID_FS_LABEL=GRNSD
E: ID_FS_LABEL_ENC=GRNSD
E: ID_FS_UUID=d8082dc5-9243-433c-81bc-6388e3564117
E: ID_FS_UUID_ENC=d8082dc5-9243-433c-81bc-6388e3564117
E: ID_FS_VERSION=1.0
E: ID_FS_TYPE=ext2
E: ID_FS_USAGE=filesystem
E: ID_PART_ENTRY_SCHEME=dos
E: ID_PART_ENTRY_UUID=000152b8-01
E: ID_PART_ENTRY_TYPE=0x83
E: ID_PART_ENTRY_NUMBER=1
E: ID_PART_ENTRY_OFFSET=6144
E: ID_PART_ENTRY_SIZE=7434240
E: ID_PART_ENTRY_DISK=8:16
E: DEVLINKS=/dev/disk/by-partuuid/000152b8-01 
/dev/disk/by-uuid/d8082dc5-9243-433c-81bc-6388e3564117 
/dev/disk/by-path/pci-:00:11.2-usb-0:2:1.0-scsi-0:0:0:0-part1 
/dev/disk/by-label/GRNSD 
/dev/disk/by-id/usb-USB2.0_CARD-READER_0201202010201000-0:0-part1
E: TAGS=:systemd:
E: CURRENT_TAGS=:systemd:


-- 
mobile: +1 778 951 5147
  VoIP: +1 604 670 0140
   48.7693 N 123.3053 W

Bug#959412: Puppeteer status?

2021-12-30 Thread Martina Ferrari


Hi Andrius,

I was wondering what is the status of this ITP? I need puppeteer for 
$DAYJOB, and I would prefer to use a proper Debian package.


It seems not much has happened in the last year in the salsa repo, is 
there much left to be done? I would be happy to give it a go if you are 
not currently working on it..


Thanks.

--
Martina Ferrari (Tina)

Bug#1002583: O: pymongo

2021-12-30 Thread Sandro Tosi

On Tue, 28 Dec 2021 12:29:48 +0100 Agathe Porte  wrote:
> Hi,
>
> On Fri, 24 Dec 2021 19:24:54 + Federico Ceratto
>  wrote:
>
>  > Orphaning package.
>
> Currently adopting it inside the Debian Python Team:

then please retitle to ITA

>
> https://salsa.debian.org/python-team/packages/pymongo
>
> Bug will be closed when package will be ready for upload with DPT as
> maintainer.

via debian/changelog?

Bug#1002851: xdelta 1.1.3-10.2 merged, nmudiff

2021-12-30 Thread Ian Jackson

Hi.  I have just pushed a version of xdelta which resolves the changes
made in 1.1.3-9.4 with those made in 1.1.3-10.1 (which was mistakenly
based on 1.1.3-9, omitting the intervening NMU changes).

The resulting package now has the libraries in the multiarch paths.  I
think all is probably well, but the package doesn't have
autopkgtests.  Typing "xdelta" with the .debs installed works so I
think it's fine ?  I hope some other package's autopkgtests will
detect it if not.

Here is the numduff.  It is against 1.1.3-9.4.  I think this should be
regarded as the nmudiff for both #965890 and #1002851.  Diffs
involving 1.1.3-10.1 are unreasonably cluttered by autogenerated file
changes.

I hope this meets with everyone's approval.
Happy new year!

Ian.



xdelta_1.1.3-10.2_nmudiff.patch
Description: Binary data


-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1002096: grpc: FTBFS: AttributeError: 'NoneType' object has no attribute 'split'

2021-12-30 Thread tony mancill

Hi Lucas,

First, let me thank you for running these archive-wide rebuilds.  They
help uncover numerous bit-rot issues with the Java Team packages (and
others too).

I am not able to reproduce this specific FTBFS and am confident that the
it is another instance of the dh-python bug:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002182.

If you'd still like to look at the logs, I have uploaded my logs and the
diff here:

  https://people.debian.org/~tmancill/grpc-1002096/

On Tue, Dec 21, 2021 at 04:48:01PM +0100, Lucas Nussbaum wrote:
> Source: grpc
> Version: 1.30.2-3
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20211220 ftbfs-bookworm
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> 
> Relevant part (hopefully):
> > /usr/bin/ruby2.7 -S gem build --config-file /dev/null --verbose 
> > /tmp/d20211220-4096024-1kn6t4/gemspec
> > Failed to load /dev/null because it doesn't contain valid YAML hash

(The Ruby error output is the same in both builds.)

This is the portion of your build log that got me looking into build-dep
package versions:

< dh-python (5.20211217)
> dh-python (5.20211229)

> >dh_python3
> > I: dh_python3 pydist:313: Cannot find package that provides futures. Please 
> > add package that provides it to Build-Depends or add "futures 
> > python3-futures" line to debian/py3dist-overrides or add proper dependency 
> > to Depends by hand and ignore this info.
> > Traceback (most recent call last):
> >   File "/usr/bin/dh_python3", line 280, in 
> > main()
> >   File "/usr/bin/dh_python3", line 201, in main
> > dependencies.parse(stats, options)
> >   File "/usr/share/dh-python/dhpython/depends.py", line 242, in parse
> > deps = parse_pydep(self.impl, fn, bdep=self.bdep, **section_options)
> >   File "/usr/share/dh-python/dhpython/pydist.py", line 522, in parse_pydep
> > for part in dependency.split(','))
> > AttributeError: 'NoneType' object has no attribute 'split'
> > make: *** [debian/rules:92: binary] Error 1

Which led me to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002182.

> The full build log is available from:
> http://qa-logs.debian.net/2021/12/20/grpc_1.30.2-3_unstable.log
> 
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
> 
> If you reassign this bug to another package, please marking it as 
> 'affects'-ing
> this package. See https://www.debian.org/Bugs/server-control#affects
> 
> If you fail to reproduce this, please provide a build log and diff it with 
> mine
> so that we can identify if something relevant changed in the meantime.

Is it okay for me to reassign to dh-python and mark this closed in
5.20211225?  Or should I forcemerge this into 1002182?

Thank you,
tony


signature.asc
Description: PGP signature

Bug#1002882: yosys: Packaging new upstream release 0.12 (with patch)

2021-12-30 Thread Daniel Gröber

Source: yosys
Version: Packaging new upstream release 0.12 (with patch)
Severity: normal
Tags: patch
X-Debbugs-Cc: d...@darkboxed.org

Dear maintainer,

I've taken the time to package the latest yosys release, please see
the salsa MR below:

https://salsa.debian.org/science-team/yosys/-/merge_requests/1

--Daniel

Bug#1002880: signing-party: caff defaults to retired pool.sks-keyservers.net

2021-12-30 Thread Guilhem Moulin

Hi,

On Thu, 30 Dec 2021 at 17:05:39 -0500, Aaron M. Ucko wrote:
> caff has historically defaulted to looking keys up on
> pool.sks-keyservers.net

$CONFIG{'keyserver'} is deprecated since 2.3-1, and the default is to
use the keyserver in ~/.caff/gnupghome/gpg.conf, falling back to the
option value defined in ~/.gnupg/gpg.conf, falling back to the
dirmngr(8) default (hkps://keys.openpgp.org by — Debian — default).
Seems I forgot to update caffrc.sample :-), but since 2.3-1 caff doesn't
hardcode its own keyserver.

> and recommending that signees upload their
> keys there.  However, per https://sks-keyservers.net/, that pool is no
> longer in service.

I'm not sure what's the best substitute at the moment as hkps://keys.openpgp.org
doesn't send third-party signatures.  IIRC GnuPG upstream waits for 
a sane Hockeypuck-based pool to grow before switching the default, so it
might make sense for caff to wait too.  (https://keyserver.ubuntu.com/
is an example of an Hockeypuck-based key server, but of course it's
centralized and not a pool.)

-- 
Guilhem.

signature.asc
Description: PGP signature

Bug#947179: linux-image-5.3.0-3-amd64: Please provide CoreBoot (Google) firmware drivers

2021-12-30 Thread Tobias Gruetzmacher

Hi,

On Mon, Dec 13, 2021 at 10:14:22PM +0100, Uwe Kleine-König wrote:
> > it would be nice if the Debian kernel would provide drivers to interact
> > with CoreBoot. As far as I can see, those are "hidden" behind
> > CONFIG_GOOGLE_FIRMWARE ...
> 
> The helptext for GOOGLE_FIRMWARE reads:
> 
>   These firmware drivers are used by Google's servers.  They are
>   only useful if you are working directly on one of their
>   proprietary servers.  If in doubt, say "N".

Yes, that is a very unfortunate help text...

> Is this text wrong, or are you working on Google's servers? In case
> you're not on Google's servers: Did you verify these settings are
> beneficial on your machine?

I'm not working on Google servers, but on a "generic" CoreBoot-device. I
can confirm that when using linux-image-5.16.0-rc7-amd64-unsigned, I can
load memconsole-coreboot, which in turn gives me access to CoreBoot logs
in /sys/firmware/log, so the feature is working as intended!

(As an aside: The file /sys/firmware/log is world-readable after the
module is loaded, this might leak some information about the hardware to
users)

Regards, Tobias

Bug#1002850: udev fails to create a symlink for a SDHC card; udevadm info reports.

2021-12-30 Thread Michael Biebl



On 30.12.21 22:58, pe...@easthope.ca wrote:

and
udevadm info/dev/

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

   looking at device 
'/devices/pci:00/:00:11.2/usb1/1-2/1-2:1.0/host3/target3:0:0/3:0:0:0/block/sdb/sdb1':
 KERNEL=="sdb1"


you posted the same info twice. Please drop the -a


OpenPGP_signature
Description: OpenPGP digital signature

Bug#964762: postfix: sometimes cannot send mail if IPv6 is local only

2021-12-30 Thread Vincent Lefevre

On 2021-12-29 16:38:15 -0500, Scott Kitterman wrote:
> On Wednesday, December 29, 2021 3:26:00 PM EST Vincent Lefevre wrote:
> > I don't have resolvconf installed (it is not installed by default).
> > If you think that this is the way this should be done, then perhaps
> > postfix should recommend resolvconf.
> 
> Thanks.  I'll do some research and figure something out.  Can you verify that 
> installing resolvconf solves the problem?

After installing resolvconf, I can see that /etc/resolv.conf has
been updated and that /var/spool/postfix/etc/resolv.conf has been
changed to have the same content. So I assume that this solves
the problem.

This doesn't change much on this machine since I'm using unbound,
so that /etc/resolv.conf will never change (by default, resolvconf
truncates after the local nameserver, though I may change its config
if I see that this yields problems: in the past, on another machine,
I got timeout problems with the default resolvconf config + bind in
case of many requests at the same time, but I hope that unbound is
better than bind).

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

Bug#1002850: udev fails to create a symlink for a SDHC card; udevadm info reports.

2021-12-30 Thread peter

From:   Michael Biebl 
Date:   Thu, 30 Dec 2021 17:47:27 +0100
> What's the actual device name?

In this trial, /dev/sdb1.

peter@joule:/home/peter$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
  sda  8:00  18.6G  0 disk 
  sda1   8:10   6.8G  0 part /
  sda2   8:20   6.8G  0 part 
  sda3   8:30 1G  0 part [SWAP]
  sda4   8:40 1K  0 part 
  sda5   8:50   3.8G  0 part /home
  sda6   8:60   100M  0 part 
  sda7   8:7099M  0 part 
sdb  8:16   1   3.7G  0 disk 
  sdb1   8:17   1   3.5G  0 part 
  sdb3   8:19   1   100M  0 part 
sdc  8:32   1 245.5M  0 disk 
  sdc1   8:33   1   244M  0 part 
sr0 11:01  1024M  0 rom  

> Please post the output of
> udevadm info -a /dev/

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device 
'/devices/pci:00/:00:11.2/usb1/1-2/1-2:1.0/host3/target3:0:0/3:0:0:0/block/sdb/sdb1':
KERNEL=="sdb1"
SUBSYSTEM=="block"
DRIVER==""
ATTR{alignment_offset}=="0"
ATTR{discard_alignment}=="0"
ATTR{inflight}=="   00"
ATTR{partition}=="1"
ATTR{power/async}=="disabled"
ATTR{power/control}=="auto"
ATTR{power/runtime_active_kids}=="0"
ATTR{power/runtime_active_time}=="0"
ATTR{power/runtime_enabled}=="disabled"
ATTR{power/runtime_status}=="unsupported"
ATTR{power/runtime_suspended_time}=="0"
ATTR{power/runtime_usage}=="0"
ATTR{ro}=="0"
ATTR{size}=="7434240"
ATTR{start}=="6144"
ATTR{stat}=="  770 4200 7409000 
   00 5280 74090000
00"

  looking at parent device 
'/devices/pci:00/:00:11.2/usb1/1-2/1-2:1.0/host3/target3:0:0/3:0:0:0/block/sdb':
KERNELS=="sdb"
SUBSYSTEMS=="block"
DRIVERS==""
ATTRS{alignment_offset}=="0"
ATTRS{capability}=="51"
ATTRS{discard_alignment}=="0"
ATTRS{events}=="media_change"
ATTRS{events_async}==""
ATTRS{events_poll_msecs}=="-1"
ATTRS{ext_range}=="256"
ATTRS{hidden}=="0"
ATTRS{inflight}=="   00"
ATTRS{integrity/device_is_integrity_capable}=="0"
ATTRS{integrity/format}=="none"
ATTRS{integrity/protection_interval_bytes}=="0"
ATTRS{integrity/read_verify}=="0"
ATTRS{integrity/tag_size}=="0"
ATTRS{integrity/write_generate}=="0"
ATTRS{mq/0/cpu_list}=="0"
ATTRS{mq/0/nr_reserved_tags}=="0"
ATTRS{mq/0/nr_tags}=="1"
ATTRS{power/async}=="disabled"
ATTRS{power/control}=="auto"
ATTRS{power/runtime_active_kids}=="0"
ATTRS{power/runtime_active_time}=="0"
ATTRS{power/runtime_enabled}=="disabled"
ATTRS{power/runtime_status}=="unsupported"
ATTRS{power/runtime_suspended_time}=="0"
ATTRS{power/runtime_usage}=="0"
ATTRS{queue/add_random}=="1"
ATTRS{queue/chunk_sectors}=="0"
ATTRS{queue/dax}=="0"
ATTRS{queue/discard_granularity}=="0"
ATTRS{queue/discard_max_bytes}=="0"
ATTRS{queue/discard_max_hw_bytes}=="0"
ATTRS{queue/discard_zeroes_data}=="0"
ATTRS{queue/fua}=="0"
ATTRS{queue/hw_sector_size}=="512"
ATTRS{queue/io_poll}=="0"
ATTRS{queue/io_poll_delay}=="-1"
ATTRS{queue/io_timeout}=="3"
ATTRS{queue/iosched/fifo_batch}=="16"
ATTRS{queue/iosched/front_merges}=="1"
ATTRS{queue/iosched/read_expire}=="500"
ATTRS{queue/iosched/write_expire}=="5000"
ATTRS{queue/iosched/writes_starved}=="2"
ATTRS{queue/iostats}=="1"
ATTRS{queue/logical_block_size}=="512"
ATTRS{queue/max_discard_segments}=="1"
ATTRS{queue/max_hw_sectors_kb}=="120"
ATTRS{queue/max_integrity_segments}=="0"
ATTRS{queue/max_sectors_kb}=="120"
ATTRS{queue/max_segment_size}=="65536"
ATTRS{queue/max_segments}=="2048"
ATTRS{queue/minimum_io_size}=="512"
ATTRS{queue/nomerges}=="0"
ATTRS{queue/nr_requests}=="2"
ATTRS{queue/nr_zones}=="0"
ATTRS{queue/optimal_io_size}=="0"
ATTRS{queue/physical_block_size}=="512"
ATTRS{queue/read_ahead_kb}=="128"
ATTRS{queue/rotational}=="1"
ATTRS{queue/rq_affinity}=="1"
ATTRS{queue/scheduler}=="[mq-deadline] none"
ATTRS{queue/stable_writes}=="0"
ATTRS{queue/wbt_lat_usec}=="75000"
ATTRS{queue/write_cache}=="write through"
ATTRS{queue/write_same_max_bytes}=="0"
ATTRS{queue/write_zeroes_max_bytes}=="0"
ATTRS{queue/zone_append_max_bytes}=="0"
ATTRS{queue/zoned}=="none"
ATTRS{range}=="16"
ATTRS{removable}=="1"
ATTRS{ro}=="0"
ATTRS{size}=="7837696"
ATTRS{stat}==" 3410142162353600
00014020235360000   
 00"

  looking at parent device

Bug#1002881: Backport 0.13.0-1 to bullseye

2021-12-30 Thread Jonas Meurer

Package: prometheus-mysqld-exporter
Severity: normal

Hello,

it would be nice if prometheus-mysqld-exporter 0.13.0 could be uploaded to
bullseye-backports (or maybe even bullseye-updates). The version shipped
in bullseye (0.12.1) has broken collect.info_schema.innodb_metrics with
the MariaDB version shipped in bullseye.

See https://github.com/prometheus/mysqld_exporter/issues/494 for the
corresponding upstream bug.

Kind regards
 Jonas

Bug#1002880: signing-party: caff defaults to retired pool.sks-keyservers.net

2021-12-30 Thread Aaron M. Ucko

Package: signing-party
Version: 2.11-1
Severity: normal

caff has historically defaulted to looking keys up on
pool.sks-keyservers.net and recommending that signees upload their
keys there.  However, per https://sks-keyservers.net/, that pool is no
longer in service.

Could you please substitute some other server or pool, both in code
and in the sample caffrc?

Thanks!

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

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

Versions of packages signing-party depends on:
ii  gnupg  2.2.27-2
ii  libc6  2.33-1
ii  libclass-methodmaker-perl  2.24-2+b1
ii  libgnupg-interface-perl1.02-1
ii  libmailtools-perl  2.21-1
ii  libmd0 1.0.4-1
ii  libmime-tools-perl 5.509-1
ii  libnet-idn-encode-perl 2.500-2
ii  libterm-readkey-perl   2.38-1+b2
ii  libtext-template-perl  1.60-1
ii  perl   5.32.1-6
ii  python33.9.7-1
ii  qprint 1.1.dfsg.2-2.1

Versions of packages signing-party recommends:
ii  dialog 1.3-20201126-1
ii  exim4-daemon-heavy [mail-transport-agent]  4.95-3
ii  libgd-perl [libgd-gd2-perl]2.73-1+b1
ii  libpaper-utils 1.1.28+b1
ii  whiptail   0.52.21-5+b1

Versions of packages signing-party suggests:
pn  fonts-noto-cjk   
ii  fonts-noto-mono  20201225-1
ii  imagemagick  8:6.9.11.60+dfsg-1.3
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3
ii  mutt 2.1.4-1
ii  neomutt  20211029+dfsg1-1
ii  qrencode 4.1.1-1
ii  texlive-font-utils   2021.20211217-1
ii  texlive-latex-extra  2021.20211217-1
ii  texlive-latex-recommended2021.20211217-1
ii  texlive-xetex2021.20211217-1
ii  wipe 0.24-9

-- debconf-show failed

Bug#1002846: git-buildpackage: gbp buildpackage should work with doas

2021-12-30 Thread Guido Günther

Hi,
On Thu, Dec 30, 2021 at 11:24:59AM +0100, Andrea Pappacoda wrote:
> Hi, thanks for the reply.
> 
> > Logs please.
> 
> Logs when running without sudo: https://paste.debian.net/1225228/
> Logs when running with sudo linked to doas:
> https://paste.debian.net/1225229/
> 
> > gbp itself isn't using sudo so this looks like an issue with the builder
> > you invoke. git-pbuilder uses sudo but its not using `sudo -E` (and not
> > inolved in the actual build step) so you likely want to reassign to the
> > builder you're using.
> 
> Sorry but I'm quite new to packaging, and I don't understand fully what you
> mean. By looking at the logs it seems that gbp is invoking git-pbuilder,
> which causes doas to throw an invalid option error; if nothing in the build
> process invokes `sudo -E` the build should complete successfully, as doas
> and sudo behave similarly when ran without options.

I didn't say *nothing* in the build invokes `sudo -E` - gbp and
git-pbuilder don't. git-pbuilder invokes pbuilder (which isn't part of
git-buildpackage) and that invokes `sudo -E`. See e.g.

PBUILDERROOTCMD in `man pbuilderrc`.

So I don't think there's anything to fix on the gbp side and the bug
should be reassigned to pbuilder.

> 
> Do you know how I could workaround this, and who should I report this bug
> to? Thanks :)

The pbuilder options should allow you to work around this but doas not
supporting `-E` looks like another bug to me.

Cheers,
 -- Guido

Bug#1002851: xdelta: /usr/bin/xdelta-config moved from libxdelta2-dev to xdeltaTo:

2021-12-30 Thread Ian Jackson

(CCing everyone who recently touched this...)

I wrote in #1002851:
> FTR, I am looking at this.

Andreas wrote:
> The git repository is missing the NMUs -9.[1-4], and the package could
> be missing the corresponding changes, I haven't checked.

The debian/changelog was also missing the NMUs.  I did some dgit
import-dsc to reproduce various elements of the the history, and when
I build it the 10.1 NMU has a similar file list to 9.  The changelog
entry for 9.2 NMU says "Move xdelta-config libxdelta2-dev".

After retconning a git history of dgit branches based on the theory
that 10.1 was based on 9 rather than 9.4, I was able to "git merge"
and had only textual or trivial conflicts to resolve in debian/rules
and debian/control.

The result seems to build, after I fixed a multiarch paths problem.

I will be uploading the result shortly.

If I may do a bit of root cause analysis, and make a bit of a plug for
my own tooling:

Debian's "usual~ git usage practices are terrible.  They set the
uploader of 10.2 up to make this mistake.  So I don't think this
reflects badly on the NMUer in question.  The solution is not for us
to all "try harder" or "be more careful"; the solution is for us to
adopt better workflows which are supported by more competent software.

I discussed some of these issues on my blog in September
   https://diziet.dreamwidth.org/9556.html
One thing I failed to mention there is that of course if you use the
salsa history you may miss NMUs.  I think I will write another blog
post about this :-).

If you want to do an NMU and like to use git, dgit may suit you.
If you use dgit you cannot make this mistake.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#990999: biber: reproducible builds: timezone-specific timestamps in PDF

2021-12-30 Thread Hilmar Preuße


Am 09.09.2021 um 02:06 teilte Vagrant Cascadian mit:

Hi,


I could submit it upstream, if you'd like.

Since I'm not familiar with the biber package, I do like to solicit
input from the maintainers of the Debian packages as they often have a
working relationship with upstream.



Forwarded to upstream: https://github.com/plk/biber/issues/395

Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1002699: libc6: m68k,sh4 readdir not returning filled in dirent pointer

2021-12-30 Thread John Paul Adrian Glaubitz

On 12/30/21 22:05, John Paul Adrian Glaubitz wrote:
> Well, on sh4, it failed with linker errors. Seems to be a different problem 
> then
> what I previously assumed. Not sure what the problem is then.

The buildd hasn't picked up the updated glibc package yet [1]:

> libc-bin_2.33-1 libc-dev-bin_2.33-1 libc6_2.33-1 libc6-dev_2.33-1

I will regenerate the chroots.

Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=gcl=m68k=2.6.12-117=1640457045=0

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1002879: python3-pot: ships /usr/lib/python3/dist-packages/benchmarks/*.py

Package: python3-pot
Version: 0.8.1+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

python3-pot ships python scripts with generic names at a generic
location, causing file conflicts with packages doing the same mistake:

/usr/lib/python3/dist-packages/benchmarks
/usr/lib/python3/dist-packages/benchmarks/__init__.py
/usr/lib/python3/dist-packages/benchmarks/benchmark.py
/usr/lib/python3/dist-packages/benchmarks/emd.py
/usr/lib/python3/dist-packages/benchmarks/sinkhorn_knopp.py

Either these should not be shipped at all or they should be moved
to a package specific subdirectory.

Andreas

Bug#997948: [Pkg-pascal-devel] Bug#997948: Bug#997948: Bug#997948: Reassign to fp-units-rtl

Hi Paul,

On Thu, 2021-12-30 at 19:24 +0100, Paul Gevers wrote:
> Maybe we should move 
> the fp-units-$bar packages to the library section too and embed the ABI 
> version into the package name.

I like that idea. Let's go that way.

For FPC, libraries are already carrying the  ABI in their names. We only need to
change them from section devel to section lib, but maybe we can convince release
team to change a bit their script and check also for fp-units-* pattern in
section devel. I don't think fp-unit-* make sense in the lib section.

For Lazarus, it used to be that way too, but was simplified to carry the
upstream main version. We may revert to old way or implement a new and better
way to do that.
-- 
Cheers,
Abou Al Montacir

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

Bug#965739: myspell-fa: diff for NMU version 0.20070816-3.2

2021-12-30 Thread Adrian Bunk

On Thu, Dec 30, 2021 at 11:11:52PM +0200, Lior Kaplan wrote:
> You're welcome to upload.

Thanks, rescheduled for immediate upload.

cu
Adrian

Bug#965739: myspell-fa: diff for NMU version 0.20070816-3.2

2021-12-30 Thread Lior Kaplan

You're welcome to upload.

On Wed, Dec 29, 2021 at 5:57 PM Adrian Bunk  wrote:

> Control: tags 965739 + patch
> Control: tags 965739 + pending
> Control: tags 999040 + patch
> Control: tags 999040 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for myspell-fa (versioned as 0.20070816-3.2) and
> uploaded it to DELAYED/7. Please feel free to tell me if I should cancel
> it.
>
> cu
> Adrian
>

Bug#1002699: libc6: m68k,sh4 readdir not returning filled in dirent pointer

2021-12-30 Thread John Paul Adrian Glaubitz

Hello!

On 12/30/21 21:18, Camm Maguire wrote:
>> I have uploaded patched versions of glibc for m68k and sh4 and blocked the
>> autobuild for glibc on the buildds.
> 
> Greetings!  I think you meant blocked autobuild for gcl

No, I didn't. I meant glibc such that the autobuilders are not building the
glibc package without the patches I mentioned.

> In any case, after a delay, gcl just attempted autobuild on sh4 and failed the
> same way.

Well, on sh4, it failed with linker errors. Seems to be a different problem then
what I previously assumed. Not sure what the problem is then.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#996974: Update

2021-12-30 Thread Salvatore Bonaccorso

Control: tags -1 + pending

Hi Liam,

On Mon, Dec 13, 2021 at 12:57:27PM -0800, Liam Hopkins wrote:
> Any update on this request?

I have picked up the configuration change after talking to a stable
release manager. Adding additional support for running Debian are
thinkgs we can consider after the stable release is published.

https://salsa.debian.org/kernel-team/linux/-/commit/276b5febdbe2256c2f502efaa0b2958feb362376

As such it will be in the next point release update 11.3, once this is
scheduled.

Regards,
Salvatore

Bug#1002851: xdelta: /usr/bin/xdelta-config moved from libxdelta2-dev to xdeltaTo:

2021-12-30 Thread Ian Jackson

FTR, I am looking at this.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1002627: transition: alglib

2021-12-30 Thread Sebastian Ramacher

Control: tags -1 confirmed
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-alglib.html

On 2021-12-25 22:51:46 +0100, Anton Gladky wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> 
> Dear release team,
> 
> please provide a slot for the transition of alglib.
> All reverse-dependencies are checked and not FTBFS are detected.
> So the tranition should be short and easy.

Please go ahead

Cheers

> 
> Thanks,
> 
> Anton
> 
> 
> Ben file:
> 
> title = "alglib";
> is_affected = .depends ~ "libalglib3.17" | .depends ~ "libalglib3.18";
> is_good = .depends ~ "libalglib3.18";
> is_bad = .depends ~ "libalglib3.17";
> 
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1002699: libc6: m68k,sh4 readdir not returning filled in dirent pointer

2021-12-30 Thread Camm Maguire

John Paul Adrian Glaubitz  writes:

> Hi Camm!
>
> On 12/28/21 19:52, John Paul Adrian Glaubitz wrote:
>> On 12/28/21 19:20, Camm Maguire wrote:
>>> Correction, that is current autobuilders on 68k and sh4.
>> 
>> That's a known issue, see [1]. I will patch the glibc packages for m68k
>> and sh4 again to address this issue.
>
> I have uploaded patched versions of glibc for m68k and sh4 and blocked the
> autobuild for glibc on the buildds.

Greetings!  I think you meant blocked autobuild for gcl  In any
case, after a delay, gcl just attempted autobuild on sh4 and failed the
same way.

Take care,

>
> You may want to merge the bug with the existing bug report [1] and adjust the
> severity to normal.
>
> Adrian
>
>
>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916276

-- 
Camm Maguirec...@maguirefamily.org
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Bug#1002703: bullseye-pu: package libarchive/3.4.3-2+deb11u1

2021-12-30 Thread Salvatore Bonaccorso

Hi Peter,

On Mon, Dec 27, 2021 at 10:10:58PM +0200, Peter Pentchev wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bullseye
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-Cc: r...@ringlet.net
> 
> [ Reason ]
> This is a future unblock request before I upload
> libarchive-3.4.3-2+deb11u1 to fix a couple of bugs that were
> fixed in later upstream versions and in unstable. They are all
> related to setting permissions and ACLs when extracting
> archive members that represent symbolic and hard links.
> 
> [ Impact ]
> Extracting some (rarely seen) archives may result in files
> having the wrong access permissions.
> 
> [ Tests ]
> All the added patches are taken from upstream commits that
> include both the bugfixes and the testsuite additions to
> check for regressions.
> 
> [ Risks ]
> The code is mostly easy to follow, the fixes are straightforward.
> 
> [ Checklist ]
>   [x] *all* changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in stable
>   [x] the issue is verified as fixed in unstable
> 
> [ Changes ]
> - correctly extract a hardlink to a symlink using the linkat(2)
>   system call
> - do not change the ACLs on symlinks, since that would affect
>   the symlink target instead
> - do not accidentally change the access mode of a symlink target
>   when a change to the symlink's mode was intended
> 
> [ Other info ]
> Thanks in advance for looking at this, and keep up the great work!

> diff -Nru libarchive-3.4.3/debian/changelog libarchive-3.4.3/debian/changelog
> --- libarchive-3.4.3/debian/changelog 2020-08-01 21:46:12.0 +0300
> +++ libarchive-3.4.3/debian/changelog 2021-12-27 18:45:51.0 +0200
> @@ -1,3 +1,12 @@
> +libarchive (3.4.3-2+deb11u1) bullseye; urgency=medium
> +
> +  * Add four upstream fixes for various problems:
> +- fix extracting hardlinks to symlinks
> +- fix handling of symlink ACLs; Closes: 1001986
> +- never follow symlinks when setting file flags; Closes: 1001990

While at it, can you as well add the CVE references to the
debian/changelog?

Regards,
Salvatore

Bug#1002874: [Debian-on-mobile-maintainers] Bug#1002874: Unable to use pipewire bluetooth with phosh

2021-12-30 Thread Guido Günther

Hi,
On Thu, Dec 30, 2021 at 08:53:09PM +0530, Pirate Praveen via 
Debian-on-mobile-maintainers wrote:
> Package: phosh-core
> Version: 5
> Severity: important
> 
> I'm trying to follow https://wiki.debian.org/PipeWire#Bluetooth to use
> pipewire for bluetoth but when trying to remove pulseaudio-bluetooth-module,
> it tries to remove phosh-core. On desktop and gnome-shell this works
> well.

I think we can lower that to a ecommends. Package is called 
`pulseaudio-module-bluetooth`.

> Is pipewire expected to work with phosh?

There are distros using it like that (manjaro). I haven't tried it
myself.
Cheers,
 -- Guido

> 
> ___
> Debian-on-mobile-maintainers mailing list
> debian-on-mobile-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers
>

Bug#1002699: libc6: m68k,sh4 readdir not returning filled in dirent pointer

2021-12-30 Thread Camm Maguire

severity 1002699 normal
merge 1002699 916276
thanks

Thank you so much!

John Paul Adrian Glaubitz  writes:

> Hi Camm!
>
> On 12/28/21 19:52, John Paul Adrian Glaubitz wrote:
>> On 12/28/21 19:20, Camm Maguire wrote:
>>> Correction, that is current autobuilders on 68k and sh4.
>> 
>> That's a known issue, see [1]. I will patch the glibc packages for m68k
>> and sh4 again to address this issue.
>
> I have uploaded patched versions of glibc for m68k and sh4 and blocked the
> autobuild for glibc on the buildds.
>
> You may want to merge the bug with the existing bug report [1] and adjust the
> severity to normal.
>
> Adrian
>
>
>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916276

-- 
Camm Maguirec...@maguirefamily.org
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Bug#1002219: [PATCH] t/eml.t: ignore newer Email::MIME behavior

2021-12-30 Thread Eric Wong

Uwe Kleine-König  wrote:
> Hello,
> 
> adding the Debian Perl Group to Cc, maybe they can help here.
> (for context look at https://bugs.debian.org/1002219)
> 
> On 12/30/21 10:12, Uwe Kleine-König wrote:
> > I got a bug report against the public-inbox 1.6.1 package about a
> > failing test, see below for the whole output. I didn't have time yet to
> > look into it, so this is just a heads up to make you aware. If someone
> > has a hint what to do, this would be greatly appreciated. Maybe just
> > updating to 1.7 will help?
> > 
> > Best regards
> > Uwe
> > 
> > On 12/21/21 17:34, Lucas Nussbaum wrote:
> > > > #   Failed test 'filename decoded'
> > > > #   at t/eml.t line 407.
> > > > #  got: '=?utf-8?q?vtpm-makefile.patch?='
> > > > # expected: 'vtpm-makefile.patch'
> > > > # Looks like you failed 1 test of 146.
> > > > t/eml.t ..
> 
> I can reproduce this problem with 1.6.1 checked out. I played a bit around
> (suffering from my weak perl foo) and found that when I downgrade
> libemail-mime-perl from 1.952-1 (i.e. Debian unstable's version) to 1.949-1
> (i.e. Debian stable's version), this works.
> 
> The reproducer is:
> 
> $ perl -e 'use Email::MIME; print Email::MIME->new("Content-Type:
> text/x-patch; name=\"=?utf-8?q?vtpm-fakefile.patch?=\"\nContent-Disposition:
> attachment; filename=\"=?utf-8?q?vtpm-makefile.patch?=\"\n\n")->filename;'
> 
> which emits "vtpm-makefile.patch" with 1.949-1 (as public-inbox expects),
> but =?utf-8?q?vtpm-makefile.patch?= with 1.952-1.
> 
> So the key question is: Is the test correct and his is a regression in
> libemail-mime-perl, or is the test wrong and we need to fix the test (and
> PublicInbox::Eml)?

I thought I sent a fix to this; but I nuked the root FS on one of
my workstations on accident :<  Still recovering...

--8<-
Subject: [PATCH] t/eml.t: ignore newer Email::MIME behavior

Once again, our message parser class matches the more tolerant
behavior of older Email::MIME releases in order to handle
ancient messages.

This fixes , but dropping
Email::MIME entirely from the test suite may be prudent in
the future.
---
 t/eml.t | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/t/eml.t b/t/eml.t
index 2d8993a5..2e6a441f 100644
--- a/t/eml.t
+++ b/t/eml.t
@@ -417,13 +417,14 @@ Content-Type: text/x-patch; 
name="=?utf-8?q?vtpm-fakefile.patch?="
 Content-Disposition: attachment; filename="=?utf-8?q?vtpm-makefile.patch?="
 
 EOF
-   is($cls->new($s)->filename, 'vtpm-makefile.patch', 'filename decoded');
+   is($cls->new($s)->filename, 'vtpm-makefile.patch',
+   "filename decoded ($cls)") if $cls ne 'PublicInbox::MIME';
$s =~ s/^Content-Disposition:.*$//sm;
is($cls->new($s)->filename, 'vtpm-fakefile.patch',
"filename fallback ($cls)") if $cls ne 'PublicInbox::MIME';
is($cls->new($s)->content_type,
'text/x-patch; name="vtpm-fakefile.patch"',
-   'matches Email::MIME output, "correct" or not');
+   qq[matches Email::MIME output, "correct" or not ($cls)]);
 
$s = <<'EOF';
 Content-Type: multipart/foo; boundary=b

Bug#1002878: yosys: New upstream release not picked up by uscan

2021-12-30 Thread Daniel Gröber

Source: yosys
Severity: normal
Tags: patch
X-Debbugs-Cc: d...@darkboxed.org

Dear Maintiner,

the yosys package's debian/watch file seems to be out of date and
doesn't pick up current releases.

I'm attaching a patch that seems to fix the issue.

--Daniel

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

Kernel: Linux 5.10.0-9-amd64 (SMP w/16 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
>From 58852964c6c90320350e054526cf22260bcdf7ee Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Daniel=20Gr=C3=B6ber?= 
Date: Thu, 30 Dec 2021 17:06:15 +0100
Subject: [PATCH] Fix debian/watch

---
 debian/watch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/watch b/debian/watch
index 72d171cb..3cbdcff9 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,2 +1,2 @@
 version=3
-https://github.com/YosysHQ/yosys/releases 
/YosysHQ/yosys/archive/\w+-(\d\S+)\.tar\.(?:bz2|gz|xz)
+https://github.com/YosysHQ/yosys/releases 
/YosysHQ/yosys/archive/refs/tags/\w+-(\d\S+)\.tar\.(?:bz2|gz|xz)
-- 
2.30.2

Bug#1002219: public-inbox: FTBFS: dh_auto_test: error: make -j4 test TEST_VERBOSE=1 returned exit code 2

2021-12-30 Thread Uwe Kleine-König


Hello,

adding the Debian Perl Group to Cc, maybe they can help here.
(for context look at https://bugs.debian.org/1002219)

On 12/30/21 10:12, Uwe Kleine-König wrote:
I got a bug report against the public-inbox 1.6.1 package about a 
failing test, see below for the whole output. I didn't have time yet to 
look into it, so this is just a heads up to make you aware. If someone 
has a hint what to do, this would be greatly appreciated. Maybe just 
updating to 1.7 will help?


Best regards
Uwe

On 12/21/21 17:34, Lucas Nussbaum wrote:

#   Failed test 'filename decoded'
#   at t/eml.t line 407.
#  got: '=?utf-8?q?vtpm-makefile.patch?='
# expected: 'vtpm-makefile.patch'
# Looks like you failed 1 test of 146.
t/eml.t ..


I can reproduce this problem with 1.6.1 checked out. I played a bit 
around (suffering from my weak perl foo) and found that when I downgrade 
libemail-mime-perl from 1.952-1 (i.e. Debian unstable's version) to 
1.949-1 (i.e. Debian stable's version), this works.


The reproducer is:

$ perl -e 'use Email::MIME; print Email::MIME->new("Content-Type: 
text/x-patch; 
name=\"=?utf-8?q?vtpm-fakefile.patch?=\"\nContent-Disposition: 
attachment; filename=\"=?utf-8?q?vtpm-makefile.patch?=\"\n\n")->filename;'


which emits "vtpm-makefile.patch" with 1.949-1 (as public-inbox 
expects), but =?utf-8?q?vtpm-makefile.patch?= with 1.952-1.


So the key question is: Is the test correct and his is a regression in 
libemail-mime-perl, or is the test wrong and we need to fix the test 
(and PublicInbox::Eml)?


Best regards
Uwe


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1002877: src:vnlog: fails to migrate to testing for too long: uploader built binaries


Source: vnlog
Version: 1.31-1
Severity: serious
Control: close -1 1.32-1
Tags: sid bookworm pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

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


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


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


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


Your package is only blocked because the binary package(s) aren't built 
on a buildd. Unfortunately the Debian infrastructure doesn't allow 
arch:all packages to be properly binNMU'ed. Hence, I will shortly do a 
no-changes source-only upload to DELAYED/15, closing this bug. Please 
let me know if I should delay or cancel that upload.


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001815: transition: notcurses


Hi Nick,

On 22-12-2021 20:42, Paul Gevers wrote:

On 22-12-2021 11:54, Sebastian Ramacher wrote:

The autopkgtests of growlight all fail and is unable to migrate. Please
fix them so that the transition can be finished.


I discussed most of this problem with Nick in bug #1001122. The issue is 
in notcurses and is supposedly fixed in unstable. Unfortunately, 
notcurses itself regressed, so *that* needs to be fixed.


The latest version of notcurses migrated to testing, but growlight still 
fails its test.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1002876: darktable: embeds libraw

2021-12-30 Thread David Bremner

Package: darktable
Version: 3.8.0-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

As of version 3.8.0, darkatable is again embedding libraw.  I decided
to open a new bug rather than reopen #682980, since the situation this
time is somewhat different, and I'm not sure anyone getting up to
speed on the bug is well served by reading the 100 or so previous
messages.

Previously (i.e. #682980), darktable was using a forked copy of libraw
(although the change was textually small).  Currently darktable is
using a git submodule of upstream libraw, which means that it is at least
possible in principle that upstream will release a sufficiently recent
version that we can build against it. Or I guess we could package a
git snapshot of libraw in Debian.

As far as I understand, the snapshot of libraw is needed for Canon CR3
support.

I guess the other thing that has changed since #682980 was closed is
that libraw acquired a number of CVEs.

Darktable already appears in the embedded copies list for libraw [1],
but I'm not sure if "modified-embed" is still the right term.


[1]: 
https://salsa.debian.org/security-tracker-team/security-tracker/raw/master/data/embedded-code-copies
- -- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages darktable depends on:
ii  libc62.33-1
ii  libcairo21.16.0-5
ii  libcolord-gtk1   0.1.26-2+b1
ii  libcolord2   1.4.5-3
ii  libcups2 2.3.3op2-7
ii  libcurl3-gnutls  7.79.1-2
ii  libexiv2-27  0.27.3-3.1
ii  libgcc-s111.2.0-13
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libglib2.0-0 2.70.2-1
ii  libgomp1 11.2.0-13
ii  libgphoto2-6 2.5.27-1
ii  libgphoto2-port122.5.27-1
ii  libgraphicsmagick-q16-3  1.4+really1.3.37-1
ii  libgtk-3-0   3.24.31-1
ii  libicu67 67.1-7
ii  libilmbase25 2.5.7-2
ii  libjpeg62-turbo  1:2.1.2-1
ii  libjson-glib-1.0-0   1.6.6-1
ii  liblcms2-2   2.12~rc1-2
ii  liblensfun1  0.3.2-6
ii  libopenexr25 2.5.7-1
ii  libopenjp2-7 2.4.0-3
ii  libosmgpsmap-1.0-1   1.2.0-1
ii  libpango-1.0-0   1.48.10+ds1-1
ii  libpangocairo-1.0-0  1.48.10+ds1-1
ii  libpng16-16  1.6.37-3
ii  libpugixml1v51.11.4-1
ii  librsvg2-2   2.50.7+dfsg-2
ii  libsecret-1-00.20.4-2
ii  libsoup2.4-1 2.74.2-3
ii  libsqlite3-0 3.36.0-2
ii  libstdc++6   11.2.0-13
ii  libtiff5 4.3.0-2
ii  libwebp6 0.6.1-2.1
ii  libx11-6 2:1.7.2-2+b1
ii  libxml2  2.9.12+dfsg-5+b1
ii  libxrandr2   2:1.5.2-1
ii  zlib1g   1:1.2.11.dfsg-2

darktable recommends no packages.

darktable suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmHN/VYACgkQA0U5G1Wq
FSHOnw/+J+O8sR5k+UBBjLLf01STow0Sz8bX+yiSjLTf9p/XYHsFP0t0Ov7iFCco
Po+2lprkIuotFo+9114yc5rDgE8MKLctTM98CN6YbM5tMRTtTqUdQFhnty8T+qLO
tGlcozdHftzIT9nOKaAPWAVqS0uKNfFVGksHLQIDSJeIBSfn7sZiwYzHyNeXNIft
aaEOtrCp8adWq6L2QhIYqSY1C2rfvE41hG/FTkBNkAUB36sdOiBpGy+MRPmxxd3E
k/KIP70EBzY0SPdYEAPjE1uMpB8gnNBa8c5A1YDGUzwWfMxx9RYVkIkPvL/PS8uu
OzkOc7sWnfZnzhdC6rhLEXxpwTB2GlNxXfrqRd++4c9pLT8rEEJHcmQsxl+NYIpK
zV0gRI54TAbsAcLIltoJHDrERruBvgi4GkCQismRFQyvSCn1iECBbvYyiKcOMA+1
iEwPLWaEkJgNlO4ek2IruerSDcP7x2eFgFhWZliQPf+Rm+plbM79arJBVlpRonMf
QaELwCsuCgOIXszLV4zg+POBO3hdwNQ1qnUDXyx8OxmWMXeuGDZQB/AlYyMbKv6x
Nj8Mk1Tmh7lYE5luBJShw1rdXA5mPd1XFb+3UkNZIeM7WKwMGEeTafxIIyz/fBb0
ULDzzmAD13Uz/7Ufk0laGEAishuvIkZ+jXB0EqhkxkX0IisBj6Y=
=zxHR
-END PGP SIGNATURE-

Bug#997947: [Pkg-pascal-devel] Bug#997947: Bug#997947: Bug#997947: Bug#997947: doublecmd FTBFS: Fatal: (10022) Can't find unit ExtCtrls used by uCmdBox


Hi Abou,

On 30-12-2021 12:54, Abou Al Montacir wrote:

Of course, even if Bug#997948 is solved, there will be always a time windows
where doublecmd can be scheduled for build while Lazarus is not yet built.
However this is a temporary situation that I won't solve.


I think such time windows are OK, they happen regularly with other 
transitions too. As long as we try to make sure these windows don't 
exist unnecessarily long (by making sure rebuilds are triggered when 
needed).


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1002875: RFP:yt-dlp -- It is a fork of youtube-dl but with more fixes and features

2021-12-30 Thread shirish शिरीष

Package: wnpp
Severity: wishlist

* Package name: yt-dlp
  Version : 2021.12.27
  Upstream Author : Name 
* URL : https://github.com/yt-dlp/yt-dlp
* License : (unlicense)
  Programming Lang: Python or rather Python3
  Description : It is a fork of youtube-dl but with more fixes and features

(Include the long description here.)

Please also include as much relevant information as possible.
For example, consider answering the following questions:
 - why is this package useful/relevant? is it a dependency for
   another package? do you use it? if there are other packages
   providing similar functionality, how does it compare?

   I have been trying it out and it does have more features than plain
youtube-dl. Also, it has been getting more commits than youtube-dl.
Seems the package/utility has been there for around 6-7 months now.

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#997948: [Pkg-pascal-devel] Bug#997948: Bug#997948: Reassign to fp-units-rtl


Hi Abou,

On 30-12-2021 16:26, Abou Al Montacir wrote:
So now we need to implement this logic in a script that can be used by 
the release team or whatever bot that can trigger automatic rebuilds of 
fp-units-* packages.


The Release Team has tools in place to notify them if rebuilds are 
needed by looking at upper limits of Depends that are no longer 
satisfied. They show up as "auto-upperlimit-" on the transitions 
page [1]. If that  has "abi" in the name, it will be clear that a 
rebuild is needed.


All the rebuilds are manually scheduled, but that's OK. As long as the 
Release Team is aware via such a mechanism, it will be taken care of.


The other auto- items show up if a binary package disappears from 
the library section of the archive and another one shows up. This is how 
c transitions happen, because it's near required that a library binary 
package matches its SONAME, so when that's bumped (indicating a 
transition) the package name has to be updated too. Maybe we should move 
the fp-units-$bar packages to the library section too and embed the ABI 
version into the package name.


Paul

[1] https://release.debian.org/transitions/


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1002711: linux-image-5.14.0-4-amd64: poll syscall does not work on some /proc files

2021-12-30 Thread Vincent Danjean

On 30/12/2021 14:52, Bastian Blank wrote:

On Mon, Dec 27, 2021 at 11:31:21PM +0100, Vincent Danjean wrote:

On a plain (with more than two bytes) file, the second poll succeed.
On /proc/bus/input/devices, the second poll hangs.
Note: this is an old behavior. I initially observe it on an embeded system with
a 4.1 kernel.

/proc is no real filesystem. It simply does not support poll, because
the output is generated while you are reading it, so it does not know
when anything changes. See also
https://unix.stackexchange.com/questions/74713/how-frequently-is-the-proc-file-system-updated-on-linux?rq=1

If you want to know about hardware changes, use udev or listen to kernel
netlink messages.

I understand that /proc is different. But I'm not monitoring it.
My goal was only to read it totally from a busybox shell with a
"while read" loop to find the eventX associated with the
touchscreen of the e-reader.
And the first read from busybox shell never complete (instead of
returning the first line of the file) due to the fact that
busybox use poll, then read a byte, then use poll again.

Do you think I should reassign this bug to busybox?

Or do you think I'm wrong trying to read the /proc file
from a shell script without to copy it elsewhere before?

Stalling:
busybox sh -c 'while read l ; do echo $l ; done < /proc/bus/input/devices'
Working (but bash is not present on the initial target system):
bash -c 'while read l ; do echo $l ; done < /proc/bus/input/devices'

As workaround, I'm currently using a copy of the file
("busybox cp" works). It should probably also be possible
to get the same kind of info from /sys files but this seems
less easy.

I just saw that other files seems to work:
Ok:
busybox sh -c 'read l < /proc/bus/input/handlers ; echo $l'
Stale:
busybox sh -c 'read l < /proc/bus/input/devices ; echo $l'

Regards,
Vincent

Bastian

Bug#995393: fakeroot: FTBFS on ppc64el

2021-12-30 Thread Christoph Biedl

Control: reopen 995393
Control: tags 995393 patch

Christoph Biedl wrote...

> As a workaround I propose a tactical __attribute__ to locally disable
> optimization as this issue has been blocking eatmydata for way too long,
> and performance loss should be neglectable.

So as always with a band-aid, it's wiser to address the underlying
problem than to work around it - this time fakeroot broke the glibc
autopkgtest ...

As jtrc27 pointed out in IRC, ppc64el is fairly picky when it comes to
va_arg handling, and next_openat needs a correct "..." parameter in the
prototype to have proper code generated.

As a surprise, it seems the original submitter had that in mind by
introducing a sixth column to wrapfunc.inp, although it's not used by
wrapwak (and not documented either, fix for that included).

My solution isn't nice as it hardcodes the va_arg handling into the
expansion, making it a special for wrapping the openat call. There's
always room for improvement  B=)

Additionally, some headers are not necesarily re-generated - so add
an extra rm call in the clean target to enforce this.

Status: Passes on the porterbox, no compiler warnings/errors from
a prototype mismatch.

Christoph

From d30127a5b2a2f26ae2f6ddc8df077a548ec145e0 Mon Sep 17 00:00:00 2001
From: Christoph Biedl 
Date: Thu, 30 Dec 2021 19:05:37 +0100
Subject: [PATCH] Fix segfault on ppc64el, take 2

---
 debian/patches/fix-prototype-generation.patch | 53 +++
 debian/patches/ppc64el-workaround.patch   | 31 ---
 debian/patches/series |  2 +-
 debian/rules  |  1 +
 4 files changed, 55 insertions(+), 32 deletions(-)
 create mode 100644 debian/patches/fix-prototype-generation.patch
 delete mode 100644 debian/patches/ppc64el-workaround.patch

diff --git a/debian/patches/fix-prototype-generation.patch 
b/debian/patches/fix-prototype-generation.patch
new file mode 100644
index 000..d364c5c
--- /dev/null
+++ b/debian/patches/fix-prototype-generation.patch
@@ -0,0 +1,53 @@
+Subject: Fix prototype generation for openat
+Author: Christoph Biedl 
+Date: 2021-12-30
+Bug-Debian: https://bugs.debian.org/995393
+Forwarded: Yes (implicitely)
+
+As jtrc27 pointed out in IRC, ppc64el is fairly picky when it comes to
+va_arg handling, and next_openat needs a correct "..." parameter in the
+prototype to have proper code generated.
+
+--- a/wrapawk
 b/wrapawk
+@@ -37,7 +37,25 @@
+   argtype=$3;
+   argname=$4;
+   MACRO=$5;
+-  if(MACRO){
++  openat_extra=$6;
++  if(openat_extra){
++print "  {(void(*))_" name ", \"" name "\"},"  > structfile;
++print "extern " ret " (*next_" name ")" openat_extra ";" > headerfile;
++print ret " (*next_" name ")" openat_extra "=tmp_" name ";"> deffile;
++
++print ret " tmp_" name,  openat_extra "{" > tmpffile;
++print " mode_t mode = 0;"> tmpffile;
++print " if (flags & O_CREAT) {"> tmpffile;
++print " va_list args;"> tmpffile;
++print " va_start(args, flags);"> tmpffile;
++print " mode = va_arg(args, int);"> tmpffile;
++print " va_end(args);"> tmpffile;
++print " }"> tmpffile;
++print "  load_library_symbols();"   > tmpffile;
++print "  return  next_" name,  argname ";"   > tmpffile;
++print "}"   > tmpffile;
++print ""> tmpffile;
++  } else if(MACRO){
+ print "  {(void(*))_" MACRO "_NOARG, " name "_QUOTE},"  > structfile;
+ print "extern " ret " (*NEXT_" MACRO "_NOARG)" argtype ";" > headerfile;
+ print ret " (*NEXT_" MACRO "_NOARG)" argtype "=TMP_" MACRO ";"> deffile;
+--- a/wrapfunc.inp
 b/wrapfunc.inp
+@@ -9,8 +9,10 @@
+ /**/*/
+ /* each line of this file lists 4 fields, seperated by a ";".   */
+ /* The first field is the name of the wrapped function, then it's return  */
+-/* value. After that come the function arguments with types, and the last */
++/* value. After that come the function arguments with types, and the fifth */
+ /* field contains the function arguments without types.   */
++/* A sixth field is a special needed when wrapping the openat syscall.*/
++/* Otherwise it's like the third (function arguments with types). */
+ /**/
+ 
+ /* __*xstat are used on glibc systems instead of just *xstat. */
diff --git a/debian/patches/ppc64el-workaround.patch 
b/debian/patches/ppc64el-workaround.patch
deleted file mode 100644
index 95b0ff0..000
--- a/debian/patches/ppc64el-workaround.patch
+++ /dev/null
@@ -1,31 +0,0 @@
-Subject: Work around segfault on ppc64el
-Author: Christoph Biedl 
-Date: 2021-12-20
-Bug-Debian: https://bugs.debian.org/995393
-Forwarded: Yes
-
-For whatever reason the generated code segfaults on ppc64el when
-built with

Bug#983940: gf-complete: ftbfs with -march=x86-64-v3

2021-12-30 Thread Thomas Goirand

Hi Matthias,

Thanks for the bug report.

Since we use qemu for testing, would you know what kind of flag I need
to add to the qemu command line, so that its CPU has the correct flags?

Cheers,

Thomas Goirand (zigo)

Bug#1001849: Acknowledgement (bullseye-pu: package glewlwyd/2.5.2-2+deb11u1)

2021-12-30 Thread Nicolas Mora


Also, the bug is only for 2.x versions.

The package glewlwyd 1.4.9-1 in oldstable isn't vulnerable

Bug#1001849: Acknowledgement (bullseye-pu: package glewlwyd/2.5.2-2+deb11u1)

2021-12-30 Thread Nicolas Mora


Hello,

On Fri, 24 Dec 2021 14:39:14 -0500 Nicolas Mora  
wrote:

Hello Salvatore,

Le 2021-12-24 à 14 h 36, Salvatore Bonaccorso a écrit :
> 
> Any news on the CVE assignment? Did MITRE respond?
> 



The CVE has been attributed for this bug: CVE-2021-45379

Bug#1000293: Problems starting jackd: Method RequestRelease is not implemented on interface org.freedesktop.ReserveDevice1

2021-12-30 Thread chris

`pipewire` is providing its own replacement for `jack`, so if you are using 
`pipewire` 
maybe you should not have `jackd2` installed at all.
I think I've done exactly the following:
```
aptitude --schedule-only install libspa-0.2-jack qsynth rosegarden; aptitude 
--schedule-only 
full-upgrade; aptitude install 
aptitude purge pulseaudio pulseaudio-module-bluetooth 
pulseaudio-module-gsettings 
aptitude purge qjackctl jackd jackd2 
```

Then, to start an app needing `jack`, I did:
`pw-jack qsynth` (don't forget to add a soundfont in `settups/soudfounts`)
then:
`rosegarden 28316.mid` (you must go in `studio/manage midi devices` and select 
a mdi 
output)
And it worked.

I'm using unstable.


Right after switching to pipewire, I did:
```
aptitude install libspa-0.2-bluetooth pipewire-audio-client-libraries 
aptitude purge pipewire-media-session 
aptitude reinstall wireplumber
```

Maybe as a user you should do:
```
systemctl --user --now disable pulseaudio.service pulseaudio.socket
systemctl --user mask pulseaudio
systemctl --user restart pipewire 
```

Maybe there should be a dependency conflict between `pipewire `and `jackd`?
Also, concerning
https://wiki.debian.org/PipeWire#For_JACK[1];>
Either run JACK clients using the pw-jack wrapper, or copy: 
# cp /usr/share/doc/pipewire/examples/ld.so.conf.d/pipewire-jack-*.conf 
/etc/ld.so.conf.d/
And run: 
# ldconfig

maybe it should be fixed at the debian package level, and hence a bug should be 
filled 
against `libspa-0.2-jack[2]`?

I hope it helps,
Chris


[1] https://wiki.debian.org/PipeWire#For_JACK
[2] https://packages.debian.org/libspa-0.2-jack

Bug#1002648: RM: r-cran-multicore -- ROM: retired upstream years ago

2021-12-30 Thread Dirk Eddelbuettel



tags 1002648 - moreinfo
thanks

This has now been taken care of in #1002512 (which was just closed) so
r-cran-multicore no longer has any reverse depends in unstable.

Please remove it and close this bug.

Thanks as always,  Dirk
 
| On 26 December 2021 at 12:53, Scott Kitterman wrote:
| | On Sun, 26 Dec 2021 10:20:51 -0600 Dirk Eddelbuettel  
wrote:
| | > 
| | > Package: ftp.debian.org
| | > Severity: normal
| | > 
| | > The 'multicore' package for R was an early extension (during 2009 to 
2011) 
| | to
| | > support process-parallel work. Its key parts (especially those that matter
| | > for us on Linux) were replaced / rewritten many years ago by package
| | > 'parallel' which is a part of base R and installed with every R 
| | installation.
| | > Consequently 'multicore' had a final transition release in 2014 but has
| | > itself been removed from CRAN for several years.
| | > 
| | > We have kept 'r-cran-multicore' around for some time but it is time to 
let 
| | it
| | > go now. I updated my own two reverse dependencies 'r-cran-dosnow' and
| | > 'r-cran-domc', and filed 
| | 
| | Checking reverse dependencies...
| | # Broken Depends:
| | r-other-mott-happy: r-other-mott-happy.hbrem
| | 
| | # Broken Build-Depends:
| | r-other-mott-happy: r-cran-multicore
| | 
| | Dependency problem found.
| | 
| | Please remove the moreinfo tag when this is resolved.
| 
| The removal of quoted text was a little unfortunate in your email.  As I
| wrote, this is not entirely under my control. Requoting in full:
| 
|We have kept 'r-cran-multicore' around for some time but it is time to let 
it
|go now. I updated my own two reverse dependencies 'r-cran-dosnow' and
|'r-cran-domc', and filed #1002512 to have package 
'r-other-mott-happy.hbrem'
|updated too.
| 
| And I sent a gentle reminder to #1002512.  I will try my best to update this
| accordingly but it may be a while.
| 
| Dirk
|  
| | Scott K
| | x[DELETED ATTACHMENT signature.asc, application/pgp-signature]
| 
| -- 
| https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1002850: Re (2): Bug#1002850: udev fails to create a symlink for a SDHC card connected to a Sharp Mebius laptop.

2021-12-30 Thread Michael Biebl

On 30.12.21 16:47, pe...@easthope.ca wrote:

Hello Michael,

From: Michael Biebl 
Date: Thu, 30 Dec 2021 08:43:32 +0100

What procedures?

In essence I followed the procedure to attach a SYMLINK name to the
SDHC card as described here.  https://wiki.debian.org/udev

The salient step is to make an effective udev rule.  More details are
in the message at debian-user, linked in the preceeding message 10.

I'm not going to extract the information from debian-user. Those should 
be provided by you in the bug report.

The result is these two different rules; each being effective in the
desktop system.

KERNEL=="sd?1", ATTR{size}=="7434240", SYMLINK+="GRNSD", \
  OWNER="peter", GROUP="users"

KERNEL=="sd?1", ENV{ID_SERIAL_SHORT}=="0201202010201000", SYMLINK+="GRNSD", \

  OWNER="peter", GROUP="peter"

Neither of these produces the SYMLINK in Debian 11 on the Sharp Mebius.

What's the actual device name?
Please post the output of
udevadm info -a /dev/
and
udevadm info /dev/

What the debug output of systemd-udevd when you attach the device?

This command will allow one to observe the execution of rules:

udevadm control --log-priority=debug
journalctl -f

(and udevadm control --log-priority=info to set it back to sane levels)

OpenPGP_signature
Description: OpenPGP digital signature

Bug#1002850: Re (2): Bug#1002850: udev fails to create a symlink for a SDHC card connected to a Sharp Mebius laptop.

2021-12-30 Thread peter

Hello Michael,

From: Michael Biebl 
Date: Thu, 30 Dec 2021 08:43:32 +0100
> What procedures?

In essence I followed the procedure to attach a SYMLINK name to the 
SDHC card as described here.  https://wiki.debian.org/udev

The salient step is to make an effective udev rule.  More details are 
in the message at debian-user, linked in the preceeding message 10.
The result is these two different rules; each being effective in the 
desktop system.

KERNEL=="sd?1", ATTR{size}=="7434240", SYMLINK+="GRNSD", \
 OWNER="peter", GROUP="users"

KERNEL=="sd?1", ENV{ID_SERIAL_SHORT}=="0201202010201000", SYMLINK+="GRNSD", \
 OWNER="peter", GROUP="peter"

Neither of these produces the SYMLINK in Debian 11 on the Sharp Mebius.

> What symlink? Please be more specific.
> Have you created custom udev rules or what?

Yes, certainly the rules above were defined in the systems.  Described 
in detail in the message to debian-user.   Here is the link again.
https://lists.debian.org/debian-user/2021/12/msg00937.html

The SYMLINK name "GRNSD", is visible in each rule above.  The 
essential concept is that 'KERNEL=="sd?1", ATTR{size}=="7434240"' in 
the first rule and 
'KERNEL=="sd?1", ENV{ID_SERIAL_SHORT}=="0201202010201000"' in the 
second rule identify the SDHC.  Then 'SYMLINK+="GRNSD"' connects the 
name to the device. Note that each rule should accomplish the same 
result.  Only one rule should be required. The rule using SERIAL 
avoids the risk of ambiguity in the unlikely case of two devices 
containing parts exactly the same size.  That is 7434240 byte parts.

In Debian 11 on the generic desktop machine, all works as expected.
Neither rule produces the symlink in Debian 11 on the Sharp Mebius.
For background, I've used rules containing ATTR{size} in various 
desktop and laptop machines through several Debian releases.  
According to Wikipedia, the initial release of udev was in 2003. In 
Debian I guess udev first appeared after Woody, Debian 3. I don't 
recall specifically but I've used udev successfully for about a 
decade.  This is the first instance of failure.

Before submitting the message to debian-user I had hoped that others 
might have noticed a related problem.  Apparently not.  Therefore the 
next step should be a debug procedure.  Maybe you have an idea or tip 
before I try debugging.  =8~)

Thanks,... Peter E.

-- 
mobile: +1 778 951 5147
  VoIP: +1 604 670 0140
   48.7693 N 123.3053 W

Bug#1002794: Package removed upstream

2021-12-30 Thread Andreas Tille

Control: retitle -1 ROM: r-cran-rsgcc -- Package removed upstream
Control: reassign -1 ftp.debian.org

Hi,

Am Tue, Dec 28, 2021 at 05:11:06PM -0600 schrieb Dirk Eddelbuettel:
> 
> Package: r-cran-rsgcc
> Severity: normal
> 
> rsgcc has been off CRAN for a while:
>https://cran.r-project.org/web/packages/rsgcc/index.html
> It would be nice if you could retire the package

I've removed it from med-bio and med-bio-dev task.  I'd intend to wait
for some migrations of other packages before releasing the metapackages
but since these are only suggests currently it should be fine to remove
r-cran-rsgcc from Debian right now thus reasigning the bug to
ftp.debian.org for removal.


> also retire 'r-cran-gwidgetsrgtk2' which was also remove from CRAN
>https://cran.r-project.org/web/packages/gWidgetsRGtk2/index.html
> 
> Removing both would allow me to retire RGtk2 aka r-cran-rgtk2 which
> was more recently retired from CRAN. gWidgetsRGtk2 has only has rsgcc as a
> user.  It may be time to do some cleanup.

Yes.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#1002863: node-react-audio-player: FTBFS with webpack5: Error: Invalid webpack options

Thanks a lot!

no specific dates yet, if the majority of reverse build dependencies
of node-webpack are fixed we can upload to unstable

On Thu, Dec 30, 2021 at 3:01 PM Nicolas Mora  wrote:
>
> Hello,
>
> Le 2021-12-30 à 06 h 22, Ayoyimika Ajibade a écrit :
> >
> > We are starting to build against webpack5 in experimental and the
> > package needed for local build is webpack and node-webpack-source from
> > experimental.
> > During a test rebuild, node-react-audio-player was found to fail to
> > build in that situation.
> >
> Thanks for reporting, I'll fix the package for experimental.
>
> Do you have an expected date when webpack 5 will be uploaded in unstable?
>
> /Nicolas

Bug#997948: [Pkg-pascal-devel] Bug#997948: Bug#997948: Reassign to fp-units-rtl

Let's assume any FP unit is shipped in a package named fp-units-some-package-
name.
Let's assume package fp-units-foo was changed and uploaded to unstable.
Let's assume package fp-units-bar depends directly or indirectly on fp-units-
foo, then fp-units-bar needs to be rebuilt after every upload of fp-units-foo
that changes interfaces checksum stored in the ppu files.

By depends directly we mean: fp-units-bar has fp-units-foo in its Build-Depends
stanza.
By depends indirectly we mean: fp-units-bar has a package that depends directly
or indirectly on fp-units-bar.

Please note that if fp-units-bar build depends on fp-units-foo, then it is
likely that it will depend on it, unless fp-units-bar is build together with
other set of fp-units-* packages that depend on fp-units-foo (like the case of
Lazarus and FPC fp-units-* packages).

So now we need to implement this logic in a script that can be used by the
release team or whatever bot that can trigger automatic rebuilds of fp-units-*
packages.

For sake of simplicity, we ca assume that any new upload of fp-units-foo will
break the interface which will cause higher load on building, but simpler logic
to be implemented.
-- 
Cheers,
Abou Al Montacir


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

Bug#1002873: reportbug: prints "Illegal instruction"

2021-12-30 Thread NoSSE2

Package: reportbug
Version: 11.1.0
Severity: normal
X-Debbugs-Cc: karogyoker2+deb...@gmail.com

Dear Maintainer,

I was submitting a bug regarding a different, unrelated package (libgl1-mesa-
dri).
Before the screen where I can type the message, a black console area appeared.
I was able to see "Illegal instruction" twice, but the whole console area
disappeared
automatically and brought me to the page where I can type the message.

I suspect that some command tried to run which required SSE2, what my CPU lacks
of.

cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 10
model name  : AMD Athlon(tm)
stepping: 0
cpu MHz : 1143.835
cache size  : 512 KB
physical id : 0
siblings: 1
core id : 0
cpu cores   : 1
apicid  : 0
initial apicid  : 0
fdiv_bug: no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow cpuid 3dnowprefetch
vmmcall
bugs: fxsave_leak sysret_ss_attrs spectre_v1 spectre_v2
spec_store_bypass
bogomips: 2287.67
clflush size: 32
cache_alignment : 32
address sizes   : 34 bits physical, 32 bits virtual
power management: ts

It shows some weird info due to the fact that I have downclocked the
CPU to be more stable, it is an Athlon XP 2600+ (Barton).



-- Package-specific info:
** Environment settings:
INTERFACE="gtk"

** /home/user/.reportbugrc:
reportbug_version "11.1.0"
mode standard
ui gtk
realname "NoSSE2"
email "karogyoker2+deb...@gmail.com"
no-cc
list-cc-me
smtphost reportbug.debian.org

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 5.15.0-2-686-pae (SMP w/1 CPU thread)
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 reportbug depends on:
ii  apt2.3.13
ii  python33.9.7-1
ii  python3-reportbug  11.1.0
ii  sensible-utils 0.0.17

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail
ii  debconf   1.5.79
pn  debsums   
pn  default-mta | postfix | exim4 | mail-transport-agent  
pn  dlocate   
pn  emacs-bin-common  
ii  file  1:5.41-2
ii  gnupg 2.2.27-2
pn  python3-urwid 
pn  reportbug-gtk 
ii  xdg-utils 1.1.3-4.1

Versions of packages python3-reportbug depends on:
ii  apt2.3.13
ii  file   1:5.41-2
ii  python33.9.7-1
ii  python3-apt2.3.0+b1
ii  python3-debian 0.1.42
ii  python3-debianbts  3.2.0
ii  python3-requests   2.25.1+dfsg-2
ii  sensible-utils 0.0.17

python3-reportbug suggests no packages.

-- no debconf information

Bug#1002872: libgl1-mesa-dri: crashes on pre-SSE2 CPUs due to movsd

2021-12-30 Thread NoSSE2

Package: libgl1-mesa-dri
Version: 21.3.0~rc5-1
Severity: critical
Justification: breaks the whole system
X-Debbugs-Cc: karogyoker2+deb...@gmail.com

Dear Maintainer,

When I start GNOME Web (epiphany-browser) and open certain pages
(almost any page, but for example gmail.com), the tab crashes
with a white background and a very sad face in a gray rounded rectangle
saying that something wrong happened and that I have to contact
my system administrator.

The same screen is being shown if I choose gdm3 as the default
desktop manager, making the system unbootable as I cannot log
in or do anything.

I can boot into Debian if I set the desktop manager to lightdm
by selecting the rescue option from GRUB and then changing the
desktop manager via dpkg-reconfigure lightdm.
Then the same crash screen shows for a few seconds but then
it disappears and lightdm's login screen shows up.

After logging in via lightdm, it is using the MATE desktop
environment and I receive multiple "Cinnamon just crashed"
error messages, do I want to restart it or not, I can just
close the dialog and then it works seemingly fine.

I cannot open any web pages with firefox-esr at all. The tabs
are crashing due to illegal instruction. Here is a report
about it:
https://crash-
stats.mozilla.org/report/index/bp-04d2a015-e8bf-463f-a9da-a3ad40211221

I cannot play any videos with smplayer, mplayer or with vlc.

I've tried the same image (debian-testing-i386-netinst.iso)
in a virtual machine on a computer with SSE2 and everything just
worked fine. I was able to open any web page in GNOME Web or firefox-esr
and log in via gdm3 without any issues. "Cinnamon just crashed"
error messages were not present at all. I didn't see any sad faces
in a gray rounded rectangle on a white background. I was able to play
videos in smplayer, mplayer and vlc.

I suggest that https://wiki.debian.org/SIMDEverywhere might be
helpful in developing a patch, if it isn't just a compiler
flag fix.

If this issue/bug is unfixable, the package should depend on
package sse2-support (i386 only).

Back to GNOME Web: I have attached gdb to the WebKitWebProcess
and tried to open gmail.com to see what happens. This happens:

Thread 8 "eadedCompositor" received signal SIGILL, Illegal instruction.
[Switching to Thread 0xa9263ac0 (LWP 13336)]
0xa6ca3a2e in ?? () from target:/usr/lib/i386-linux-gnu/dri/swrast_dri.so
(gdb) bt full
#0  0xa6ca3a2e in ?? () from target:/usr/lib/i386-linux-gnu/dri/swrast_dri.so
No symbol table info available.
#1  0xa72653fa in ?? () from target:/usr/lib/i386-linux-gnu/dri/swrast_dri.so
No symbol table info available.
#2  0xa7266629 in ?? () from target:/usr/lib/i386-linux-gnu/dri/swrast_dri.so
No symbol table info available.
#3  0xa6d6d998 in ?? () from target:/usr/lib/i386-linux-gnu/dri/swrast_dri.so
No symbol table info available.
#4  0xa677bc43 in ?? () from target:/usr/lib/i386-linux-gnu/dri/swrast_dri.so
No symbol table info available.
#5  0xa6717676 in ?? () from target:/usr/lib/i386-linux-gnu/dri/swrast_dri.so
No symbol table info available.
#6  0xa6c53370 in ?? () from target:/usr/lib/i386-linux-gnu/dri/swrast_dri.so
No symbol table info available.
#7  0xa838bebe in ?? () from target:/lib/i386-linux-gnu/libGLX_mesa.so.0
No symbol table info available.
#8  0xa8389a25 in ?? () from target:/lib/i386-linux-gnu/libGLX_mesa.so.0
No symbol table info available.
#9  0xb08e5e04 in ?? () from target:/lib/i386-linux-gnu/libGLX.so.0
No symbol table info available.
#10 0xb6389e59 in ?? () from target:/lib/i386-linux-gnu/libwebkit2gtk-4.0.so.37
No symbol table info available.
#11 0xb638a534 in ?? () from target:/lib/i386-linux-gnu/libwebkit2gtk-4.0.so.37
--Type  for more, q to quit, c to continue without paging--c
No symbol table info available.
#12 0xb638c70e in ?? () from target:/lib/i386-linux-gnu/libwebkit2gtk-4.0.so.37
No symbol table info available.
#13 0xb6349fb9 in ?? () from target:/lib/i386-linux-gnu/libwebkit2gtk-4.0.so.37
No symbol table info available.
#14 0xb634ab8e in ?? () from target:/lib/i386-linux-gnu/libwebkit2gtk-4.0.so.37
No symbol table info available.
#15 0xb638c5cc in ?? () from target:/lib/i386-linux-gnu/libwebkit2gtk-4.0.so.37
No symbol table info available.
#16 0xb6349db7 in ?? () from target:/lib/i386-linux-gnu/libwebkit2gtk-4.0.so.37
No symbol table info available.
#17 0xb4b9acbb in ?? () from target:/lib/i386-linux-gnu/libwebkit2gtk-4.0.so.37
No symbol table info available.
#18 0xb4b9ada8 in ?? () from target:/lib/i386-linux-gnu/libwebkit2gtk-4.0.so.37
No symbol table info available.
#19 0xb4b98608 in ?? () from target:/lib/i386-linux-gnu/libwebkit2gtk-4.0.so.37
No symbol table info available.
#20 0xb3b25d57 in WTF::RunLoop::performWork() () from target:/lib/i386-linux-
gnu/libjavascriptcoregtk-4.0.so.18
No symbol table info available.
#21 0xb3b7ab78 in ?? () from target:/lib/i386-linux-
gnu/libjavascriptcoregtk-4.0.so.18
No symbol table info available.
#22 0xb3b7b689 in ?? () from target:/lib/i386-linux-

Bug#979764: nfs-common: NFSv4 with mit kerberos sec. mounts fail after kernel update 5.9 to 5.10

2021-12-30 Thread Birger Brunswiek


Hi all,

Linux kernel 5.10 removed support for RC4-HMAC [1] from Kerberos. I 
suspect the reporter's client is using that encryption type. Samba used 
to create keytabs only containing RC4-HMAC, DES-CBC-MD5 and DES-CBC-CRC. 
Current versions of rpc.gssd use any of DES3-CBC-SHA1, 
AES256-CTS-HMAC-SHA1-96 or AES128-CTS-HMAC-SHA1-96. That could be the 
reason for the mount to fail. This can be checked using `klist -ke`. The 
list should contain AES256-CTS-HMAC-SHA1-96 or AES128-CTS-HMAC-SHA1-96 
and I guess they are missing.


Starting rpc.gssd with the `-l` to allow weak cyphers would seem like a 
workaround at first but this does not work because the weak cyphers are 
no longer available in the underlying libraries.


Current versions of Samba do include AES encryption types in keytab 
exports. If not, it's probably because the the account's password has 
not been changed since Sambe introduced support for AES. Rejoining the 
client or resetting its AD account's password should help. Note, 
hoewever, that AES encrption types are not exported if service 
principals are used. In that case they need to be explicitly enabled 
before the export [2]. For my clients I used `net ads enctypes set 
 24`.


[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e33d2a7b3041d7f8cd1f0a2a4ca42a5bc112b14e

[2] https://wiki.samba.org/index.php/Generating_Keytabs

Cheers
Birger

Bug#1002711: linux-image-5.14.0-4-amd64: poll syscall does not work on some /proc files

2021-12-30 Thread Bastian Blank

On Mon, Dec 27, 2021 at 11:31:21PM +0100, Vincent Danjean wrote:
> On a plain (with more than two bytes) file, the second poll succeed.
> On /proc/bus/input/devices, the second poll hangs.
> Note: this is an old behavior. I initially observe it on an embeded system 
> with
> a 4.1 kernel.

/proc is no real filesystem.  It simply does not support poll, because
the output is generated while you are reading it, so it does not know
when anything changes.  See also
https://unix.stackexchange.com/questions/74713/how-frequently-is-the-proc-file-system-updated-on-linux?rq=1

If you want to know about hardware changes, use udev or listen to kernel
netlink messages.

Bastian

-- 
Earth -- mother of the most beautiful women in the universe.
-- Apollo, "Who Mourns for Adonais?" stardate 3468.1

Bug#1002863: node-react-audio-player: FTBFS with webpack5: Error: Invalid webpack options

2021-12-30 Thread Nicolas Mora


Hello,

Le 2021-12-30 à 06 h 22, Ayoyimika Ajibade a écrit :


We are starting to build against webpack5 in experimental and the 
package needed for local build is webpack and node-webpack-source from 
experimental.
During a test rebuild, node-react-audio-player was found to fail to 
build in that situation.



Thanks for reporting, I'll fix the package for experimental.

Do you have an expected date when webpack 5 will be uploaded in unstable?

/Nicolas

Bug#972536: [Pkg-pascal-devel] Bug#972536: fpc: the old version 3.0.4+dfsg-23 still in sid

Hi Xiao

On Wed, 2020-10-21 at 10:28 +0800, xiao sheng wen wrote:
> Perhaps the newer version of fpc upload to sid in next time, this old 
> version 3.0.4+dfsg-23 would automatically removed.
> 
> Let us wait for some times.

Can we close this ticket now that FPC-3.2.2 is in sid?
-- 
Cheers,
Abou Al Montacir


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

Bug#1002733: Improve /sbin/runlevel for runlevels 0 and 6

2021-12-30 Thread Andras Korn

On Thu, Dec 30, 2021 at 10:02:55AM +0100, Andras Korn wrote:

> On Wed, Dec 29, 2021 at 03:07:38AM +0100, Lorenzo wrote:
> 
> > I'm going to accept a fix for this issue, but I prefer to not have to
> > parse a file and also to not add another flag file only for this, if
> > it's possible.
> 
> Well, getting the first character from a file and printing it verbatim is
> hardly "parsing". :)

I gave this more thought.

I hadn't considered that even /etc/runit/3 depends on /run/runit.reboot
being present and having the correct mode.

I checked the source of runit-init and it creates /run/runit.reboot if it
doesn't exist, not just sets its mode.

Thus, purely for the purpose of rebooting via kexec, depending on
/run/runit.reboot existing and having the correct mode at the time
/etc/runit/3 is executed seems adequate (even if technically racy).

I still worry that by changing the behaviour of runlevel(8) so it depends on
/run/runit.reboot will break something for someone somewhere, but I suppose
you can say they broke it for themselves by fiddling with /run/runit.reboot.

I can think of more convoluted ways of keeping track of the runlevel and
reporting it, but I'll spare you. :) (Avoiding race conditions completely is
not possible since no matter what we do, "check runlevel"; "do something
based on runlevel" will never be an atomic operation in the kexec
initscript. While technically correct is the best kind of correct, it's
probably not worth it to aim for perfection in this instance.)

András

-- 
In the context of marriage, a moral victory is something you'll
  invariably end up celebrating on your own.

Bug#1002837: tiledb: diff for NMU version 1.7.7-1.2

2021-12-30 Thread Dirk Eddelbuettel



Hi Adam,

On 30 December 2021 at 11:12, Adam Cécile wrote:
| Sure, I was suggesting adding you directly to uploaders because the 
| package is maintained on Salsa, sadly I see we both missed each other there:
| 
| https://salsa.debian.org/acecile-guest/tiledb
| https://salsa.debian.org/debian/tiledb
| 
| It seems you forked mine, which is fine but I think only one repo must 
| survive ;-)

Actually that repo creation was (I asumme) Utkarsh, not me. I didn't touch
tiledb on salsa in any form til this week.  

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1002838: pdfarranger: Error "Can't convert ObjectHelper" when saving

2021-12-30 Thread Erich Schubert


Package: pdfarranger
Version: 1.8.0-1
Followup-For: Bug #1002838

Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/pdfarranger/pdfarranger.py", line 976,
in choose_export_pdf_name
self.save(mode, file_out)
File "/usr/lib/python3/dist-packages/pdfarranger/pdfarranger.py", line 160,
in wrapper
func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/pdfarranger/pdfarranger.py", line 1050,
in save
exporter.export(self.pdfqueue, to_export, file_out, mode, m)
File "/usr/lib/python3/dist-packages/pdfarranger/exporter.py", line 165, in
export
new_page = pdf_output.make_indirect(new_page)
TypeError: Can't convert ObjectHelper (or subclass) to Object 
implicitly. Use

.obj to get access the underlying object.


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

Kernel: Linux 5.14.0-1-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
LC_ALL set to de_DE.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 pdfarranger depends on:
ii gir1.2-glib-2.0 1.70.0-2
ii gir1.2-gtk-3.0 3.24.31-1
ii gir1.2-poppler-0.18 21.11.0-1
ii python3 3.9.8-1
ii python3-cairo 1.20.1-3
ii python3-dateutil 2.8.1-6
ii python3-gi 3.42.0-3
ii python3-gi-cairo 3.42.0-3
ii python3-pikepdf 4.2.0+dfsg-1
ii python3-pkg-resources 59.6.0-1

Versions of packages pdfarranger recommends:
ii python3-img2pdf 0.4.2-1

pdfarranger suggests no packages.

-- no debconf information

Bug#1002869: node-vue-resource: FTBFS with webpack5: Error: Invalid webpack options


Source: node-vue-resource
Version:  1.5.3+dfsg+~1.3.6-2
Severity: important
Justification: ftbfs
Tags: ftbfs
User: pkg-javascript-de...@alioth-lists.debian.net
Usertags: webpack5


Hi,

We are starting to build against webpack5 in experimental and the 
package needed for local build is webpack and node-webpack-source from 
experimental.
During a test rebuild, node-vue-resource was found to fail to build in 
that situation.


Relevant part (hopefully):

   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
webpack --config debian/webpack.config.js --mode development \
--entry ./src/index.js --output dist/vue-resource.common.js \
--output-library-target commonjs \
--module-bind 'js=babel-loader'
[webpack-cli] Error: Unknown option '--output'
make[1]: *** [debian/rules:10: override_dh_auto_build] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:6: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2


The full log is attached to this mail
sbuild (Debian sbuild) 0.81.2 (31 January 2021) on Ayoyimika-PC.localdomain

+===+
| node-vue-resource 1.5.3+dfsg+~1.3.6-2 (amd64) Thu, 30 Dec 2021 10:12:11 + 
|
+===+

Package: node-vue-resource
Version: 1.5.3+dfsg+~1.3.6-2
Source Version: 1.5.3+dfsg+~1.3.6-2
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-c1dd29bf-113d-4ea4-8699-1ff571390dc3'
 with '<>'
I: NOTICE: Log filtering will replace 
'build/node-vue-resource-DJJm1n/resolver-vf5qvV' with '<>'

+--+
| Update chroot|
+--+

Get:1 file:/build/node-vue-resource-DJJm1n/resolver-D9O9zU/apt_archive ./ 
InRelease
Ign:1 file:/build/node-vue-resource-DJJm1n/resolver-D9O9zU/apt_archive ./ 
InRelease
Get:2 file:/build/node-vue-resource-DJJm1n/resolver-D9O9zU/apt_archive ./ 
Release [951 B]
Get:2 file:/build/node-vue-resource-DJJm1n/resolver-D9O9zU/apt_archive ./ 
Release [951 B]
Get:3 file:/build/node-vue-resource-DJJm1n/resolver-D9O9zU/apt_archive ./ 
Release.gpg
Ign:3 file:/build/node-vue-resource-DJJm1n/resolver-D9O9zU/apt_archive ./ 
Release.gpg
Get:4 file:/build/node-vue-resource-DJJm1n/resolver-D9O9zU/apt_archive ./ 
Packages [798 B]
Err:4 file:/build/node-vue-resource-DJJm1n/resolver-D9O9zU/apt_archive ./ 
Packages
  Could not open file 
/build/node-vue-resource-DJJm1n/resolver-D9O9zU/apt_archive/./Packages - open 
(13: Permission denied)
Get:4 file:/build/node-vue-resource-DJJm1n/resolver-D9O9zU/apt_archive ./ 
Packages [1381 B]
Get:5 http://deb.debian.org/debian unstable InRelease [165 kB]
Get:6 http://deb.debian.org/debian experimental InRelease [75.4 kB]
Get:7 http://deb.debian.org/debian unstable/main Sources.diff/Index [63.6 kB]
Get:8 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index 
[63.6 kB]
Get:9 http://deb.debian.org/debian unstable/main all Contents (deb).diff/Index 
[63.8 kB]
Get:10 http://deb.debian.org/debian unstable/main amd64 Contents 
(deb).diff/Index [63.8 kB]
Get:11 http://deb.debian.org/debian experimental/main Sources.diff/Index [63.3 
kB]
Get:12 http://deb.debian.org/debian experimental/main amd64 Packages.diff/Index 
[63.3 kB]
Get:13 http://deb.debian.org/debian experimental/main amd64 Contents 
(deb).diff/Index [63.6 kB]
Get:14 http://deb.debian.org/debian experimental/main all Contents 
(deb).diff/Index [63.6 kB]
Get:15 http://deb.debian.org/debian unstable/main Sources 
T-2021-12-30-0801.19-F-2021-12-22-2012.55.pdiff [266 kB]
Get:16 http://deb.debian.org/debian unstable/main amd64 Packages 
T-2021-12-30-0801.19-F-2021-12-22-2012.55.pdiff [277 kB]
Get:15 http://deb.debian.org/debian unstable/main Sources 
T-2021-12-30-0801.19-F-2021-12-22-2012.55.pdiff [266 kB]
Get:17 http://deb.debian.org/debian unstable/main all Contents (deb) 
T-2021-12-30-0801.19-F-2021-12-22-2012.55.pdiff [152 kB]
Get:18 http://deb.debian.org/debian unstable/main amd64 Contents (deb) 
T-2021-12-30-0801.19-F-2021-12-22-2012.55.pdiff [90.8 kB]
Get:19 http://deb.debian.org/debian experimental/main Sources 
T-2021-12-30-0201.21-F-2021-12-22-2012.55.pdiff [48.5 kB]
Get:20 http://deb.debian.org/debian experimental/main amd64 Packages 
T-2021-12-29-2008.02-F-2021-12-22-2012.55.pdiff [76.8 kB]
Get:16 http://deb.debian.org/debian unstable/main amd64 Packages 
T-2021-12-30-0801.19-F-2021-12-22-2012.55.pdiff [277 kB]
Get:19 http://deb.debian.org/debian experimental/main Sources 
T-2021-12-30-0201.21-F-2021-12-22-2012.55.pdiff [48.5 kB]
Get:17 http://deb.debian.org/debian unstable/main all Contents (deb)

Bug#1002867: node-url-parse: FTBFS with webpack5: Error: Invalid webpack options


Source: node-url-parse
Version: 1.5.3-1
Severity: important
Justification: ftbfs
Tags: ftbfs
User: pkg-javascript-de...@alioth-lists.debian.net
Usertags: webpack5


Hi,

We are starting to build against webpack5 in experimental and the 
package needed for local build is webpack and node-webpack-source from 
experimental.
During a test rebuild, node-url-parse was found to fail to build in that 
situation.


Relevant part (hopefully):

   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
webpack --config debian/webpack.config.js --output-library=URLParse \
--entry index.js --output dist/url-parse.js --mode development
[webpack-cli] Error: Unknown option '--output'
make[1]: *** [debian/rules:11: override_dh_auto_build] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:8: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2



The full log is attached to this mail
sbuild (Debian sbuild) 0.81.2 (31 January 2021) on Ayoyimika-PC.localdomain

+==+
| node-url-parse 1.5.3-1 (amd64)   Thu, 30 Dec 2021 10:10:35 + |
+==+

Package: node-url-parse
Version: 1.5.3-1
Source Version: 1.5.3-1
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-79c8dc0e-f192-48ad-922b-7f493e63e429'
 with '<>'
I: NOTICE: Log filtering will replace 
'build/node-url-parse-Bytisy/resolver-9Dr5NL' with '<>'

+--+
| Update chroot|
+--+

Get:1 file:/build/node-url-parse-Bytisy/resolver-77EQAf/apt_archive ./ InRelease
Ign:1 file:/build/node-url-parse-Bytisy/resolver-77EQAf/apt_archive ./ InRelease
Get:2 file:/build/node-url-parse-Bytisy/resolver-77EQAf/apt_archive ./ Release 
[951 B]
Get:2 file:/build/node-url-parse-Bytisy/resolver-77EQAf/apt_archive ./ Release 
[951 B]
Get:3 file:/build/node-url-parse-Bytisy/resolver-77EQAf/apt_archive ./ 
Release.gpg
Ign:3 file:/build/node-url-parse-Bytisy/resolver-77EQAf/apt_archive ./ 
Release.gpg
Get:4 file:/build/node-url-parse-Bytisy/resolver-77EQAf/apt_archive ./ Packages 
[798 B]
Err:4 file:/build/node-url-parse-Bytisy/resolver-77EQAf/apt_archive ./ Packages
  Could not open file 
/build/node-url-parse-Bytisy/resolver-77EQAf/apt_archive/./Packages - open (13: 
Permission denied)
Get:4 file:/build/node-url-parse-Bytisy/resolver-77EQAf/apt_archive ./ Packages 
[1381 B]
Get:5 http://deb.debian.org/debian unstable InRelease [165 kB]
Get:6 http://deb.debian.org/debian experimental InRelease [75.4 kB]
Get:7 http://deb.debian.org/debian unstable/main Sources.diff/Index [63.6 kB]
Get:8 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index 
[63.6 kB]
Get:9 http://deb.debian.org/debian unstable/main all Contents (deb).diff/Index 
[63.8 kB]
Get:10 http://deb.debian.org/debian unstable/main amd64 Contents 
(deb).diff/Index [63.8 kB]
Get:11 http://deb.debian.org/debian experimental/main Sources.diff/Index [63.3 
kB]
Get:12 http://deb.debian.org/debian experimental/main amd64 Packages.diff/Index 
[63.3 kB]
Get:13 http://deb.debian.org/debian experimental/main amd64 Contents 
(deb).diff/Index [63.6 kB]
Get:14 http://deb.debian.org/debian experimental/main all Contents 
(deb).diff/Index [63.6 kB]
Get:15 http://deb.debian.org/debian unstable/main Sources 
T-2021-12-30-0801.19-F-2021-12-22-2012.55.pdiff [266 kB]
Get:16 http://deb.debian.org/debian unstable/main amd64 Packages 
T-2021-12-30-0801.19-F-2021-12-22-2012.55.pdiff [277 kB]
Get:15 http://deb.debian.org/debian unstable/main Sources 
T-2021-12-30-0801.19-F-2021-12-22-2012.55.pdiff [266 kB]
Get:17 http://deb.debian.org/debian unstable/main all Contents (deb) 
T-2021-12-30-0801.19-F-2021-12-22-2012.55.pdiff [152 kB]
Get:16 http://deb.debian.org/debian unstable/main amd64 Packages 
T-2021-12-30-0801.19-F-2021-12-22-2012.55.pdiff [277 kB]
Get:18 http://deb.debian.org/debian unstable/main amd64 Contents (deb) 
T-2021-12-30-0801.19-F-2021-12-22-2012.55.pdiff [90.8 kB]
Get:17 http://deb.debian.org/debian unstable/main all Contents (deb) 
T-2021-12-30-0801.19-F-2021-12-22-2012.55.pdiff [152 kB]
Get:19 http://deb.debian.org/debian experimental/main Sources 
T-2021-12-30-0201.21-F-2021-12-22-2012.55.pdiff [48.5 kB]
Get:18 http://deb.debian.org/debian unstable/main amd64 Contents (deb) 
T-2021-12-30-0801.19-F-2021-12-22-2012.55.pdiff [90.8 kB]
Get:20 http://deb.debian.org/debian experimental/main amd64 Packages 
T-2021-12-29-2008.02-F-2021-12-22-2012.55.pdiff [76.8 kB]
Get:19 http://deb.debian.org/debian experimental/main Sources

Bug#997947: [Pkg-pascal-devel] Bug#997947: Bug#997947: Bug#997947: Bug#997947: doublecmd FTBFS: Fatal: (10022) Can't find unit ExtCtrls used by uCmdBox

Control: merge -1 997948

After deeper analysis, I think, I finally found the issue:
* doublecmd depends on lc-utils and pulls it.
* lcl-utils depends on fp-compiler and pulls fp-compiler-3.2.2
* fp-compiler-3.2.2 pulls fp-units-rtl-3.2.0
* doublecmd depends on lc-units and pulls lcl-units-2.0 version 2.0.10 compiled
with fpc 3.2.0
* lcl-units-2.0 pulls fp-units-rtl-3.2.0 which can coexist with fp-units-rtl-
3.2.0 therefore no error and both versions are installed.
* doublecmd needs unit ExtCtrls which is compiled with fp-units-rtl-3.2.0
(installed) but the used compiler can only use system unit from fp-units-rtl-
3.2.2 thus the issue we see.

Unfortunately, the only way to solve this is either to force using fp-compiler-
3.2.0 (non sense) or to force using a version of lcl-units-2.0 compiled with fp-
compiler-3.2.2 (Bug#997948).

Of course, even if Bug#997948 is solved, there will be always a time windows
where doublecmd can be scheduled for build while Lazarus is not yet built.
However this is a temporary situation that I won't solve.

I advise, then, to close this ticket and let Bug#997948 open.
-- 
Cheers,
Abou Al Montacir


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

Bug#1002868: firefox-esr: Extensions thread/process consuming 100% CPU (single thread) indefinitely

2021-12-30 Thread Bruno Gravato

Package: firefox-esr
Version: 91.4.1esr-1~deb11u1
Severity: important
Tags: upstream
X-Debbugs-Cc: bgrav...@gmail.com

Dear Maintainer,

I justed wanted to report that I can confirm that bug #986027 reported for
firefox in unstable also applies to firefox-esr 91.4.1 (which is currently
available on bullseye security updates).

This started happening since I upgraded from firefox-esr 78 to 91 on bullseye.

I'm using the following extensions, installed from the debian packages:
- webext-privacy-badger
- webext-ublock-origin-firefox
- webext-keepassxc-browser

This happens (apparently) randomly and I couldn't spot any specific action that
triggers it, but it happens quite often (several times a day).

about:processes in firefox-esr reports that Extensions process is using 100%,
confirmed in htop (single thread using 100% CPU/core). It stays like that
indefinitely.

The solution so far has been restarting Firefox every time it happens.

According to bug #986027 this was fixed in firefox 95. Can it be backported to
firefox-esr 91?


-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox-esr depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-13+deb11u2
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-2
ii  libdbus-glib-1-2 0.110-6
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi7  3.3-6
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libpango-1.0-0   1.46.2-3
ii  libstdc++6   10.2.1-6
ii  libvpx6  1.9.0-1
ii  libx11-6 2:1.7.2-1
ii  libx11-xcb1  2:1.7.2-1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxrender1  1:0.9.10-1
ii  procps   2:3.3.17-5
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages firefox-esr recommends:
ii  libavcodec58  7:4.3.3-0+deb11u1

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.004.5-6.1
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.18.3-6+deb11u1
ii  pulseaudio 14.2-2

-- no debconf information

Bug#1002706: nftables stateless NAT in raw table mangles fragmented UDP packets also reproducible in linux-image-5.16.0-rc7-amd64-unsigned

2021-12-30 Thread Steffen Weinreich

Hi

The same behavior is reproducible in

Linux debian 5.16.0-rc7-amd64 #1 SMP PREEMPT Debian 5.16~rc7-1~exp1
(2021-12-26) x86_64 GNU/Linux

Package: linux-image-5.16.0-rc7-amd64-unsigned
Version: 5.16~rc7-1~exp1
Priority: optional
Section: kernel
Source: linux
Maintainer: Debian Kernel Team 
Installed-Size: 445 MB
Depends: kmod, linux-base (>= 4.3~), initramfs-tools (>= 0.120+deb8u2) |
linux-initramfs-tool
Recommends: firmware-linux-free, apparmor
Suggests: linux-doc-5.16, debian-kernel-handbook, grub-pc |
grub-efi-amd64 | extlinux
Conflicts: linux-image-5.16.0-rc7-amd64
Breaks: fwupdate (<< 12-7), initramfs-tools (<< 0.120+deb8u2),
wireless-regdb (<< 2019.06.03-1~), xserver-xorg-input-vmmouse (<< 1:13.0.99)
Replaces: linux-image-5.16.0-rc7-amd64
Homepage: https://www.kernel.org/
Download-Size: 66,1 MB
APT-Manual-Installed: yes
APT-Sources: http://deb.debian.org/debian experimental/main amd64 Packages
Description: Linux 5.16-rc7 for 64-bit PCs
 The Linux kernel 5.16-rc7 and modules for use on PCs with AMD64, Intel 64
 or VIA Nano processors.

Bug#1002866: node-turbolinks: FTBFS with webpack5: Error: Invalid webpack options


Source: node-turbolinks
Version: 5.2.0+dfsg-3
Severity: important
Justification: ftbfs
Tags: ftbfs
User: pkg-javascript-de...@alioth-lists.debian.net
Usertags: webpack5


Hi,

We are starting to build against webpack5 in experimental and the 
package needed for local build is webpack and node-webpack-source from 
experimental.
During a test rebuild, node-turbolinks was found to fail to build in 
that situation.


Relevant part (hopefully):

   dh_auto_build --buildsystem=nodejs
Found debian/nodejs/./build
cd ./. && sh -ex debian/nodejs/./build
+ coffee -c src/turbolinks/browser_adapter.coffee 
src/turbolinks/compatibility.coffee src/turbolinks/controller.coffee 
src/turbolinks/error_renderer.coffee src/turbolinks/head_details.coffee 
src/turbolinks/helpers.coffee src/turbolinks/history.coffee 
src/turbolinks/http_request.coffee src/turbolinks/index.coffee 
src/turbolinks/location.coffee src/turbolinks/progress_bar.coffee 
src/turbolinks/renderer.coffee src/turbolinks/script_warning.coffee 
src/turbolinks/scroll_manager.coffee src/turbolinks/snapshot.coffee 
src/turbolinks/snapshot_cache.coffee 
src/turbolinks/snapshot_renderer.coffee src/turbolinks/start.coffee 
src/turbolinks/view.coffee src/turbolinks/visit.coffee
+ webpack --output-library=Turbolinks --config debian/webpack.config.js 
--entry ./src/turbolinks/index.js --output dist/turbolinks.browser.js 
--mode development

[webpack-cli] Error: Unknown option '--output'
dh_auto_build: error: cd ./. && sh -ex debian/nodejs/./build returned 
exit code 1

make: *** [debian/rules:8: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2


The full log is attached to this mail
sbuild (Debian sbuild) 0.81.2 (31 January 2021) on Ayoyimika-PC.localdomain

+==+
| node-turbolinks 5.2.0+dfsg-3 (amd64) Thu, 30 Dec 2021 10:09:00 + |
+==+

Package: node-turbolinks
Version: 5.2.0+dfsg-3
Source Version: 5.2.0+dfsg-3
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-9c6d1015-2636-4a04-be51-56bb97b95e52'
 with '<>'
I: NOTICE: Log filtering will replace 
'build/node-turbolinks-32HYZx/resolver-HyIQwu' with '<>'

+--+
| Update chroot|
+--+

Get:1 file:/build/node-turbolinks-32HYZx/resolver-j6oplD/apt_archive ./ 
InRelease
Ign:1 file:/build/node-turbolinks-32HYZx/resolver-j6oplD/apt_archive ./ 
InRelease
Get:2 file:/build/node-turbolinks-32HYZx/resolver-j6oplD/apt_archive ./ Release 
[951 B]
Get:2 file:/build/node-turbolinks-32HYZx/resolver-j6oplD/apt_archive ./ Release 
[951 B]
Get:3 file:/build/node-turbolinks-32HYZx/resolver-j6oplD/apt_archive ./ 
Release.gpg
Ign:3 file:/build/node-turbolinks-32HYZx/resolver-j6oplD/apt_archive ./ 
Release.gpg
Get:4 file:/build/node-turbolinks-32HYZx/resolver-j6oplD/apt_archive ./ 
Packages [798 B]
Err:4 file:/build/node-turbolinks-32HYZx/resolver-j6oplD/apt_archive ./ Packages
  Could not open file 
/build/node-turbolinks-32HYZx/resolver-j6oplD/apt_archive/./Packages - open 
(13: Permission denied)
Get:4 file:/build/node-turbolinks-32HYZx/resolver-j6oplD/apt_archive ./ 
Packages [1381 B]
Get:5 http://deb.debian.org/debian unstable InRelease [165 kB]
Get:6 http://deb.debian.org/debian experimental InRelease [75.4 kB]
Get:7 http://deb.debian.org/debian unstable/main Sources.diff/Index [63.6 kB]
Get:8 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index 
[63.6 kB]
Get:9 http://deb.debian.org/debian unstable/main amd64 Contents 
(deb).diff/Index [63.8 kB]
Get:10 http://deb.debian.org/debian unstable/main all Contents (deb).diff/Index 
[63.8 kB]
Get:11 http://deb.debian.org/debian experimental/main Sources.diff/Index [63.3 
kB]
Get:12 http://deb.debian.org/debian experimental/main amd64 Packages.diff/Index 
[63.3 kB]
Get:13 http://deb.debian.org/debian experimental/main amd64 Contents 
(deb).diff/Index [63.6 kB]
Get:14 http://deb.debian.org/debian experimental/main all Contents 
(deb).diff/Index [63.6 kB]
Get:15 http://deb.debian.org/debian unstable/main Sources 
T-2021-12-30-0801.19-F-2021-12-22-2012.55.pdiff [266 kB]
Get:16 http://deb.debian.org/debian unstable/main amd64 Packages 
T-2021-12-30-0801.19-F-2021-12-22-2012.55.pdiff [277 kB]
Get:15 http://deb.debian.org/debian unstable/main Sources 
T-2021-12-30-0801.19-F-2021-12-22-2012.55.pdiff [266 kB]
Get:17 http://deb.debian.org/debian unstable/main amd64 Contents (deb) 
T-2021-12-30-0801.19-F-2021-12-22-2012.55.pdiff [90.8 kB]
Get:18 http://deb.debian.org/debian unstable/main all Contents (deb)

Bug#1002865: node-trust-json-document: FTBFS with webpack5: Error: Invalid webpack options


Source: node-trust-json-document
Version: 0.1.4~dfsg-10
Severity: important
Justification: ftbfs
Tags: ftbfs
User: pkg-javascript-de...@alioth-lists.debian.net
Usertags: webpack5


Hi,

We are starting to build against webpack5 in experimental and the 
package needed for local build is webpack and node-webpack-source from 
experimental.
During a test rebuild, node-trust-json-document was found to fail to 
build in that situation.


Relevant part (hopefully):

dpkg-buildpackage
-

Command: dpkg-buildpackage --sanitize-env -us -uc -b -rfakeroot
dpkg-buildpackage: info: source package node-trust-json-document
dpkg-buildpackage: info: source version 0.1.4~dfsg-10
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Yadd 
 dpkg-source --before-build .
dpkg-buildpackage: info: host architecture amd64
 debian/rules clean
dh clean
   dh_clean
 debian/rules binary
dh binary
   dh_update_autotools_config
   dh_autoreconf
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
babeljs --no-babelrc src -d lib --presets=@babel/preset-env
Successfully compiled 10 files with Babel (3109ms).
webpack -d --output-filename json-document.js
[webpack-cli] Invalid configuration object. Webpack has been initialized 
using a configuration object that does not match the API schema.
 - configuration.devtool should match pattern 
"^(inline-|hidden-|eval-)?(nosources-)?(cheap-(module-)?)?source-map$".

   BREAKING CHANGE since webpack 5: The devtool option is more strict.
   Please strictly follow the order of the keywords in the pattern.
make[1]: *** [debian/rules:32: debian/js/json-document.min.js] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:48: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2


The full log is attached to this mail
sbuild (Debian sbuild) 0.81.2 (31 January 2021) on Ayoyimika-PC.localdomain

++
| node-trust-json-document 0.1.4~dfsg-10 (amd64) Thu, 30 Dec 2021 10:06:58 
+ |
++

Package: node-trust-json-document
Version: 0.1.4~dfsg-10
Source Version: 0.1.4~dfsg-10
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-a60c6601-ae4b-4b23-bf2c-870a3a7e9a24'
 with '<>'
I: NOTICE: Log filtering will replace 
'build/node-trust-json-document-OwYUsS/resolver-2irPXa' with '<>'

+--+
| Update chroot|
+--+

Get:1 file:/build/node-trust-json-document-OwYUsS/resolver-i8v0Lk/apt_archive 
./ InRelease
Ign:1 file:/build/node-trust-json-document-OwYUsS/resolver-i8v0Lk/apt_archive 
./ InRelease
Get:2 file:/build/node-trust-json-document-OwYUsS/resolver-i8v0Lk/apt_archive 
./ Release [951 B]
Get:2 file:/build/node-trust-json-document-OwYUsS/resolver-i8v0Lk/apt_archive 
./ Release [951 B]
Get:3 file:/build/node-trust-json-document-OwYUsS/resolver-i8v0Lk/apt_archive 
./ Release.gpg
Ign:3 file:/build/node-trust-json-document-OwYUsS/resolver-i8v0Lk/apt_archive 
./ Release.gpg
Get:4 file:/build/node-trust-json-document-OwYUsS/resolver-i8v0Lk/apt_archive 
./ Packages [798 B]
Err:4 file:/build/node-trust-json-document-OwYUsS/resolver-i8v0Lk/apt_archive 
./ Packages
  Could not open file 
/build/node-trust-json-document-OwYUsS/resolver-i8v0Lk/apt_archive/./Packages - 
open (13: Permission denied)
Get:4 file:/build/node-trust-json-document-OwYUsS/resolver-i8v0Lk/apt_archive 
./ Packages [1381 B]
Get:5 http://deb.debian.org/debian unstable InRelease [165 kB]
Get:6 http://deb.debian.org/debian experimental InRelease [75.4 kB]
Get:7 http://deb.debian.org/debian unstable/main Sources.diff/Index [63.6 kB]
Get:8 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index 
[63.6 kB]
Get:9 http://deb.debian.org/debian unstable/main all Contents (deb).diff/Index 
[63.8 kB]
Get:10 http://deb.debian.org/debian unstable/main amd64 Contents 
(deb).diff/Index [63.8 kB]
Get:11 http://deb.debian.org/debian experimental/main Sources.diff/Index [63.3 
kB]
Get:12 http://deb.debian.org/debian experimental/main amd64 Packages.diff/Index 
[63.3 kB]
Get:13 http://deb.debian.org/debian experimental/main all Contents 
(deb).diff/Index [63.6 kB]
Get:14 http://deb.debian.org/debian experimental/main amd64 Contents 
(deb).diff/Index [63.6 kB]
Get:15 http://deb.debian.org/debian unstable/main Sources 
T-2021-12-30-0801.19-F-2021-12-22-2012.55.pdiff [266 kB]
Get:16 http://deb.debian.org/debian unstable/main amd64 Packages 
T-2021-12-30-0801.19-F-2021-12-22-2012.55.pdiff [277 kB]
Get:15

Bug#1002864: node-source-map: FTBFS with webpack5: Error: Invalid webpack options


Source: node-source-map
Version: 0.7.0++dfsg2+really.0.6.1-9
Severity: important
Justification: ftbfs
Tags: ftbfs
User: pkg-javascript-de...@alioth-lists.debian.net
Usertags: webpack5


Hi,

We are starting to build against webpack5 in experimental and the 
package needed for local build is webpack and node-webpack-source from 
experimental.
During a test rebuild, node-source-map was found to fail to build in 
that situation.


Relevant part (hopefully):

   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
mkdir -p dist
webpack --mode development
[webpack-cli] Failed to load '/<>/webpack.config.js' config
[webpack-cli] Error: Cannot find module 'uglifyjs-webpack-plugin'
Require stack:
- /<>/webpack.config.js
- /usr/share/nodejs/webpack-cli/lib/webpack-cli.js
- /usr/share/nodejs/webpack-cli/lib/bootstrap.js
- /usr/share/nodejs/webpack-cli/bin/cli.js
- /usr/share/nodejs/webpack/bin/webpack.js
at Function.Module._resolveFilename 
(internal/modules/cjs/loader.js:815:15)

at Function.Module._load (internal/modules/cjs/loader.js:667:27)
at Module.require (internal/modules/cjs/loader.js:887:19)
at require (internal/modules/cjs/helpers.js:74:18)
at Object. (/<>/webpack.config.js:5:22)
at Module._compile (internal/modules/cjs/loader.js:999:30)
at Object.Module._extensions..js 
(internal/modules/cjs/loader.js:1027:10)

at Module.load (internal/modules/cjs/loader.js:863:32)
at Function.Module._load (internal/modules/cjs/loader.js:708:14)
at Module.require (internal/modules/cjs/loader.js:887:19) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
'/<>/webpack.config.js',
'/usr/share/nodejs/webpack-cli/lib/webpack-cli.js',
'/usr/share/nodejs/webpack-cli/lib/bootstrap.js',
'/usr/share/nodejs/webpack-cli/bin/cli.js',
'/usr/share/nodejs/webpack/bin/webpack.js'
  ]
}
make[1]: *** [debian/rules:12: override_dh_auto_build] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:8: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2


The full log is attached to this mail
sbuild (Debian sbuild) 0.81.2 (31 January 2021) on Ayoyimika-PC.localdomain

+=+
| node-source-map 0.7.0++dfsg2+really.0.6.1-9 (amd64) Thu, 30 Dec 2021 10:05:21 
+ |
+=+

Package: node-source-map
Version: 0.7.0++dfsg2+really.0.6.1-9
Source Version: 0.7.0++dfsg2+really.0.6.1-9
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-720298ea-a666-4cb3-b3f7-3d35279ab4a4'
 with '<>'
I: NOTICE: Log filtering will replace 
'build/node-source-map-n5FNQG/resolver-XK85C7' with '<>'

+--+
| Update chroot|
+--+

Get:1 file:/build/node-source-map-n5FNQG/resolver-BYIqdH/apt_archive ./ 
InRelease
Ign:1 file:/build/node-source-map-n5FNQG/resolver-BYIqdH/apt_archive ./ 
InRelease
Get:2 file:/build/node-source-map-n5FNQG/resolver-BYIqdH/apt_archive ./ Release 
[951 B]
Get:2 file:/build/node-source-map-n5FNQG/resolver-BYIqdH/apt_archive ./ Release 
[951 B]
Get:3 file:/build/node-source-map-n5FNQG/resolver-BYIqdH/apt_archive ./ 
Release.gpg
Ign:3 file:/build/node-source-map-n5FNQG/resolver-BYIqdH/apt_archive ./ 
Release.gpg
Get:4 file:/build/node-source-map-n5FNQG/resolver-BYIqdH/apt_archive ./ 
Packages [798 B]
Err:4 file:/build/node-source-map-n5FNQG/resolver-BYIqdH/apt_archive ./ Packages
  Could not open file 
/build/node-source-map-n5FNQG/resolver-BYIqdH/apt_archive/./Packages - open 
(13: Permission denied)
Get:4 file:/build/node-source-map-n5FNQG/resolver-BYIqdH/apt_archive ./ 
Packages [1381 B]
Get:5 http://deb.debian.org/debian unstable InRelease [165 kB]
Get:6 http://deb.debian.org/debian experimental InRelease [75.4 kB]
Get:7 http://deb.debian.org/debian unstable/main Sources.diff/Index [63.6 kB]
Get:8 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index 
[63.6 kB]
Get:9 http://deb.debian.org/debian unstable/main amd64 Contents 
(deb).diff/Index [63.8 kB]
Get:10 http://deb.debian.org/debian unstable/main all Contents (deb).diff/Index 
[63.8 kB]
Get:11 http://deb.debian.org/debian experimental/main Sources.diff/Index [63.3 
kB]
Get:12 http://deb.debian.org/debian experimental/main amd64 Packages.diff/Index 
[63.3 kB]
Get:13 http://deb.debian.org/debian experimental/main all Contents 
(deb).diff/Index [63.6 kB]
Get:14 http://deb.debian.org/debian experimental/main amd64 Contents 
(deb).diff/Index [63.6 kB]
Get:15 http://deb.debian.org/debian unstable/main Sources

Bug#1002863: node-react-audio-player: FTBFS with webpack5: Error: Invalid webpack options


Source: node-react-audio-player
Version: 0.17.0-1
Severity: important
Justification: ftbfs
Tags: ftbfs
User: pkg-javascript-de...@alioth-lists.debian.net
Usertags: webpack5


Hi,

We are starting to build against webpack5 in experimental and the 
package needed for local build is webpack and node-webpack-source from 
experimental.
During a test rebuild, node-react-audio-player was found to fail to 
build in that situation.


Relevant part (hopefully):

   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
webpack -p
[webpack-cli] Error: Unknown option '-p'
make[1]: *** [debian/rules:11: override_dh_auto_build] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:8: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2


The full log is attached to this mail
sbuild (Debian sbuild) 0.81.2 (31 January 2021) on Ayoyimika-PC.localdomain

+==+
| node-react-audio-player 0.17.0-1 (amd64) Thu, 30 Dec 2021 10:03:44 + |
+==+

Package: node-react-audio-player
Version: 0.17.0-1
Source Version: 0.17.0-1
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-edd8bfd5-56d2-4cf6-830c-30a8e27dfc11'
 with '<>'
I: NOTICE: Log filtering will replace 
'build/node-react-audio-player-5xBmM0/resolver-AQ2HwR' with '<>'

+--+
| Update chroot|
+--+

Get:1 file:/build/node-react-audio-player-5xBmM0/resolver-T2XFCG/apt_archive ./ 
InRelease
Ign:1 file:/build/node-react-audio-player-5xBmM0/resolver-T2XFCG/apt_archive ./ 
InRelease
Get:2 file:/build/node-react-audio-player-5xBmM0/resolver-T2XFCG/apt_archive ./ 
Release [951 B]
Get:2 file:/build/node-react-audio-player-5xBmM0/resolver-T2XFCG/apt_archive ./ 
Release [951 B]
Get:3 file:/build/node-react-audio-player-5xBmM0/resolver-T2XFCG/apt_archive ./ 
Release.gpg
Ign:3 file:/build/node-react-audio-player-5xBmM0/resolver-T2XFCG/apt_archive ./ 
Release.gpg
Get:4 file:/build/node-react-audio-player-5xBmM0/resolver-T2XFCG/apt_archive ./ 
Packages [798 B]
Err:4 file:/build/node-react-audio-player-5xBmM0/resolver-T2XFCG/apt_archive ./ 
Packages
  Could not open file 
/build/node-react-audio-player-5xBmM0/resolver-T2XFCG/apt_archive/./Packages - 
open (13: Permission denied)
Get:4 file:/build/node-react-audio-player-5xBmM0/resolver-T2XFCG/apt_archive ./ 
Packages [1381 B]
Get:5 http://deb.debian.org/debian unstable InRelease [165 kB]
Get:6 http://deb.debian.org/debian experimental InRelease [75.4 kB]
Get:7 http://deb.debian.org/debian unstable/main Sources.diff/Index [63.6 kB]
Get:8 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index 
[63.6 kB]
Get:9 http://deb.debian.org/debian unstable/main all Contents (deb).diff/Index 
[63.8 kB]
Get:10 http://deb.debian.org/debian unstable/main amd64 Contents 
(deb).diff/Index [63.8 kB]
Get:11 http://deb.debian.org/debian experimental/main Sources.diff/Index [63.3 
kB]
Get:12 http://deb.debian.org/debian experimental/main amd64 Packages.diff/Index 
[63.3 kB]
Get:13 http://deb.debian.org/debian experimental/main amd64 Contents 
(deb).diff/Index [63.6 kB]
Get:14 http://deb.debian.org/debian experimental/main all Contents 
(deb).diff/Index [63.6 kB]
Get:15 http://deb.debian.org/debian unstable/main Sources 
T-2021-12-30-0801.19-F-2021-12-22-2012.55.pdiff [266 kB]
Get:16 http://deb.debian.org/debian unstable/main amd64 Packages 
T-2021-12-30-0801.19-F-2021-12-22-2012.55.pdiff [277 kB]
Get:15 http://deb.debian.org/debian unstable/main Sources 
T-2021-12-30-0801.19-F-2021-12-22-2012.55.pdiff [266 kB]
Get:17 http://deb.debian.org/debian unstable/main all Contents (deb) 
T-2021-12-30-0801.19-F-2021-12-22-2012.55.pdiff [152 kB]
Get:16 http://deb.debian.org/debian unstable/main amd64 Packages 
T-2021-12-30-0801.19-F-2021-12-22-2012.55.pdiff [277 kB]
Get:18 http://deb.debian.org/debian unstable/main amd64 Contents (deb) 
T-2021-12-30-0801.19-F-2021-12-22-2012.55.pdiff [90.8 kB]
Get:17 http://deb.debian.org/debian unstable/main all Contents (deb) 
T-2021-12-30-0801.19-F-2021-12-22-2012.55.pdiff [152 kB]
Get:19 http://deb.debian.org/debian experimental/main Sources 
T-2021-12-30-0201.21-F-2021-12-22-2012.55.pdiff [48.5 kB]
Get:18 http://deb.debian.org/debian unstable/main amd64 Contents (deb) 
T-2021-12-30-0801.19-F-2021-12-22-2012.55.pdiff [90.8 kB]
Get:20 http://deb.debian.org/debian experimental/main amd64 Packages 
T-2021-12-29-2008.02-F-2021-12-22-2012.55.pdiff [76.8 kB]
Get:19 http://deb.debian.org/debian experimental/main Sources

Bug#1002862: node-prop-types: FTBFS with webpack5: Error: Invalid webpack options


Source: node-prop-types
Version: 15.7.2+~15.7.4-2
Severity: important
Justification: ftbfs
Tags: ftbfs
User: pkg-javascript-de...@alioth-lists.debian.net
Usertags: webpack5


Hi,

We are starting to build against webpack5 in experimental and the 
package needed for local build is webpack and node-webpack-source from 
experimental.
During a test rebuild, node-prop-types was found to fail to build in 
that situation.


Relevant part (hopefully):

dpkg-buildpackage
-

Command: dpkg-buildpackage --sanitize-env -us -uc -b -rfakeroot
dpkg-buildpackage: info: source package node-prop-types
dpkg-buildpackage: info: source version 15.7.2+~15.7.4-2
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Jonas Smedegaard 
 dpkg-source --before-build .
dpkg-buildpackage: info: host architecture amd64
 debian/rules clean
dh clean
   dh_auto_clean --buildsystem=nodejs
rm -rf ./node_modules/.cache
rm -rf types-prop-types/node_modules/.cache
rm ./node_modules/.cache
rm types-prop-types/node_modules/.cache
unlink node_modules/@types/prop-types
   dh_clean
 debian/rules binary
dh binary
   dh_update_autotools_config
   dh_autoreconf
   dh_auto_configure --buildsystem=nodejs
Link node_modules/@types/prop-types -> ../../types-prop-types
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
webpack --config debian/webpack.config.js --output-library=PropTypes \
--entry index.js --output ./prop-types.js --mode development
[webpack-cli] Error: Unknown option '--output'
make[1]: *** [debian/rules:8: override_dh_auto_build] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:5: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2



The full log is attached to this mail
sbuild (Debian sbuild) 0.81.2 (31 January 2021) on Ayoyimika-PC.localdomain

+==+
| node-prop-types 15.7.2+~15.7.4-2 (amd64) Thu, 30 Dec 2021 10:01:58 + |
+==+

Package: node-prop-types
Version: 15.7.2+~15.7.4-2
Source Version: 15.7.2+~15.7.4-2
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-f7326ba8-7379-4c5d-9325-0e61419d2af6'
 with '<>'
I: NOTICE: Log filtering will replace 
'build/node-prop-types-C77rlO/resolver-6P30nj' with '<>'

+--+
| Update chroot|
+--+

Get:1 file:/build/node-prop-types-C77rlO/resolver-25PH8B/apt_archive ./ 
InRelease
Ign:1 file:/build/node-prop-types-C77rlO/resolver-25PH8B/apt_archive ./ 
InRelease
Get:2 file:/build/node-prop-types-C77rlO/resolver-25PH8B/apt_archive ./ Release 
[951 B]
Get:2 file:/build/node-prop-types-C77rlO/resolver-25PH8B/apt_archive ./ Release 
[951 B]
Get:3 file:/build/node-prop-types-C77rlO/resolver-25PH8B/apt_archive ./ 
Release.gpg
Ign:3 file:/build/node-prop-types-C77rlO/resolver-25PH8B/apt_archive ./ 
Release.gpg
Get:4 file:/build/node-prop-types-C77rlO/resolver-25PH8B/apt_archive ./ 
Packages [798 B]
Err:4 file:/build/node-prop-types-C77rlO/resolver-25PH8B/apt_archive ./ Packages
  Could not open file 
/build/node-prop-types-C77rlO/resolver-25PH8B/apt_archive/./Packages - open 
(13: Permission denied)
Get:4 file:/build/node-prop-types-C77rlO/resolver-25PH8B/apt_archive ./ 
Packages [1381 B]
Get:5 http://deb.debian.org/debian unstable InRelease [165 kB]
Get:6 http://deb.debian.org/debian experimental InRelease [75.4 kB]
Get:7 http://deb.debian.org/debian unstable/main Sources.diff/Index [63.6 kB]
Get:8 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index 
[63.6 kB]
Get:9 http://deb.debian.org/debian unstable/main amd64 Contents 
(deb).diff/Index [63.8 kB]
Get:10 http://deb.debian.org/debian unstable/main all Contents (deb).diff/Index 
[63.8 kB]
Get:11 http://deb.debian.org/debian experimental/main Sources.diff/Index [63.3 
kB]
Get:12 http://deb.debian.org/debian experimental/main amd64 Packages.diff/Index 
[63.3 kB]
Get:13 http://deb.debian.org/debian experimental/main all Contents 
(deb).diff/Index [63.6 kB]
Get:14 http://deb.debian.org/debian experimental/main amd64 Contents 
(deb).diff/Index [63.6 kB]
Get:15 http://deb.debian.org/debian unstable/main Sources 
T-2021-12-30-0801.19-F-2021-12-22-2012.55.pdiff [266 kB]
Get:16 http://deb.debian.org/debian unstable/main amd64 Packages 
T-2021-12-30-0801.19-F-2021-12-22-2012.55.pdiff [277 kB]
Get:15 http://deb.debian.org/debian unstable/main Sources 
T-2021-12-30-0801.19-F-2021-12-22-2012.55.pdiff [266 kB]
Get:16 http://deb.debian.org/debian unstable/main amd64 Packages

Bug#1002861: node-node-forge: FTBFS with webpack5: Error: Configuration object don't match the API schema