Bug#1025515: ITP: libnginx-mod-http-brotli -- Nginx module libnginx-mod-http-brotli

[Jérémy Lal]

>
> Le mar. 6 déc. 2022 à 05:54, Jan Mojzis  a écrit :
>
>> Package: wnpp
>> Severity: wishlist
>> Owner: Jan Mojzis 
>> X-Debbugs-Cc: debian-de...@lists.debian.org
>>
>> * Package name: libnginx-mod-http-brotli
>>   Version : 1.0.0rc
>>   Upstream Author : Google Inc
>> * URL : https://github.com/google/ngx_brotli
>> * License : BSD
>>   Programming Lang: C
>>   Description : libnginx-mod-http-brotli module for Nginx
>>
>>
>> libnginx-mod-http-brotli is new module for Nginx web server.
>> it is a set of two nginx modules:
>> libnginx-mod-http-brotli-filter - filter module - used to compress
>> responses on-the-fly,
>> libnginx-mod-http-brotli-static - used to serve pre-compressed files.
>>
>> I would like to maintain the package using
>> https://salsa.debian.org/nginx-team/libnginx-mod-http-brotli
>>
>> I need sponsor only for the first upload (I'm DM).
>> Thank You!
>>
>
Upstream version apparently needs to be mangled:

W: libnginx-mod-http-brotli source:
rc-version-greater-than-expected-version 1.0.0rc > 1.0.0 (consider using
1.0.0~rc) [debian/changelog:1]
N:
N:   The package appears to be a release candidate or preview release, but
the version sorts higher
N:   than the expected final release.
N:
N:   For non-native packages, the check examines the upstream version. For
native packages, it
N:   looks at the Debian maintainer's revision.
N:
N:   Please refer to Version (Section 5.6.12) in the Debian Policy Manual
for details.
N:
N:   Visibility: warning
N:   Show-Always: no
N:   Check: debian/changelog
N:
Lintian OK

Jérémy

Bug#1025521: FTBFS: cannot change owner and permissions of 'debian/...'

[Shengjing Zhu]

Source: cross-toolchain-base
Version: 62
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: z...@debian.org

https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/cross-toolchain-base_62.rbuild.log.gz

dh_installdirs -plinux-libc-dev-amd64-cross \
  usr/share/doc/linux-libc-dev-amd64-cross \
  usr/share/lintian/overrides \
  usr/x86_64-linux-gnu
install: cannot change owner and permissions of 
'debian/linux-libc-dev-amd64-cross/usr/share/doc/linux-libc-dev-amd64-cross': 
Operation not permitted
install: cannot change owner and permissions of 
'debian/linux-libc-dev-amd64-cross/usr/share/lintian/overrides': Operation not 
permitted
install: cannot change owner and permissions of 
'debian/linux-libc-dev-amd64-cross/usr/x86_64-linux-gnu': Operation not 
permitted
dh_installdirs: error: install -m0755 -o 0 -g 0 -d 
debian/linux-libc-dev-amd64-cross/usr/share/doc/linux-libc-dev-amd64-cross 
debian/linux-libc-dev-amd64-cross/usr/share/lintian/overrides 
debian/linux-libc-dev-amd64-cross/usr/x86_64-linux-gnu returned exit code 1
make: *** [debian/rules:162: stamp-dir/install-linux.amd64] Error 25
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Bug#1025515: ITP: libnginx-mod-http-brotli -- Nginx module libnginx-mod-http-brotli

[Jérémy Lal]

ok, consider it done

Le mar. 6 déc. 2022 à 05:54, Jan Mojzis  a écrit :

> Package: wnpp
> Severity: wishlist
> Owner: Jan Mojzis 
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> * Package name: libnginx-mod-http-brotli
>   Version : 1.0.0rc
>   Upstream Author : Google Inc
> * URL : https://github.com/google/ngx_brotli
> * License : BSD
>   Programming Lang: C
>   Description : libnginx-mod-http-brotli module for Nginx
>
>
> libnginx-mod-http-brotli is new module for Nginx web server.
> it is a set of two nginx modules:
> libnginx-mod-http-brotli-filter - filter module - used to compress
> responses on-the-fly,
> libnginx-mod-http-brotli-static - used to serve pre-compressed files.
>
> I would like to maintain the package using
> https://salsa.debian.org/nginx-team/libnginx-mod-http-brotli
>
> I need sponsor only for the first upload (I'm DM).
> Thank You!
>
>

Bug#1011155: python-cryptography - please update to latest >= v35 releases

[Claudius Heine]

Hi Carsten,

On 2022-12-06 07:05, Carsten Schoenert wrote:

Hello Claudius, hello Tristan,

I'd like to ask if there are some more major issues outstanding to get
python-cryptography updated to a recent version as we are getting cloder
to the first freeze date of the bookworm release.

What is the status for this wishlist bug report?
I think it's quite important to get really recent versions ready for the
bookworm release, especially in the segement of cryptography.

Is there something a required update would need some help?


python-cryptography depends on the rust packages pyo3 and asn1, which 
both are now in unstable. However they have autopkgtest issues and are 
stuck there for now. For asn1 I fixed those:


https://salsa.debian.org/rust-team/debcargo-conf/-/blob/master/src/asn1/debian/changelog

So this is currently waiting for a sponsor.

For pyo3 I also fixed them here:
https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/395

Those changes need to be reviewed, merged and then uploaded.

regards,
Claudius



Am Fri, Jul 29, 2022 at 10:07:04AM -0400 schrieb Alex Gaynor:

As one of the maintainers of pyca/cryptography, I'm strongly in favor
of upgrading. Older releases do not receive support (including
security fixes) from the maintainers. And in the past few releases
we've added many new features, support for more strong cryptographic
algorithms, and significantly improved performance.


Regrads and thanks!
Carsten

Bug#1025203: r-cran-glmmtmb: FTBFS on mipsel

[Mathieu Malaterre]

I do not have a clean answer to this, but in my experience it is
getting more and more difficult to compile anything on mipsel with
g++-12. The default option `-g -O2` seems to imply `take as much
memory as you want to get things to compile` so this end up crossing
the 2GB hard-limit.

For example here is what webkit is doing to work around the symptoms:

* 
https://salsa.debian.org/webkit-team/webkit/-/blob/debian/2.39.1-1/debian/rules#L66-71

Previous reports on this issue:

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882490
* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78971

On Tue, Dec 6, 2022 at 8:10 AM Andreas Tille  wrote:
>
> Ping?  If this can't be clarified I'd probably ask ftpmaster for removal
> of the package for mipsel.
> Kind regards, Andreas.
>
> Am Thu, Dec 01, 2022 at 07:15:27AM +0100 schrieb Andreas Tille:
> > Hi,
> >
> > Am Wed, Nov 30, 2022 at 10:08:14PM +0100 schrieb Paul Gevers:
> > > Source: r-cran-glmmtmb
> > > Version: 1.1.4+dfsg-3
> > > Severity: serious
> > > Tags: ftbfs
> > > Justification: ftbfs
> > >
> > > Dear maintainer(s),
> > >
> > > Your package failed to build from source on mipsel, where it built
> > > successfully in the past.
> > >
> > > https://buildd.debian.org/status/fetch.php?pkg=r-cran-glmmtmb=mipsel=1.1.5%2Bdfsg-1=1669057119=0
> > > ...
> > > cc1plus: out of memory allocating 1058400 bytes after a total of 59473920 
> > > bytes
> >
> > Isn't this just a matter of the autobuilders hardware?
> >
> > If not I do not see any other clue but removing the package for mipsel.
> >
> > Kind regards
> >
> >  Andreas.
> >
> > --
> > http://fam-tille.de
>
> --
> http://fam-tille.de
>

Bug#1025520: dpkg-shlibdeps: error: no dependency information found for /usr/lib/x86_64-linux-gnu/libLLVM-14.so.1

[Mathieu Malaterre]

Package: libllvm14
Version: 1:14.0.6-6

Here is what I get when I compile openvdb with cmake+rpath (default option):

```
   dh_shlibdeps -a -O--buildsystem=cmake
dpkg-shlibdeps: error: no dependency information found for
/usr/lib/x86_64-linux-gnu/libLLVM-14.so.1 (used by
debian/libopenvdb-tools/usr/bin/vdb_ax)
Hint: check if the library actually comes from a package.
```

Obviously there are plenty of fixes for me to hide the symptoms (*)
however it would be nicer to have the actual root issue fixed in
libllvm14 package directly (hence my bug report).

What is actually surprising is that it failed everywhere but arm64
(not sure if shlib handling is supposed to be different) :

* 
https://buildd.debian.org/status/logs.php?pkg=openvdb=10.0.0-8=experimental

Thanks

(*) 
https://stackoverflow.com/questions/11238134/dpkg-shlibdeps-error-no-dependency-information-found-for

Bug#1025519: bind9: apparmor profile prevents openssl config files other than etc/ssl/openssl.cnf

[Arnaud Rebillout]

Package: bind9
Version: 9.18.8-1
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

This bug was initially reported against the Kali bug tracker:
https://bugs.kali.org/view.php?id=8079#c17121.

The issue is that, in Kali Linux, named crashes as it can't access the
file etc/openssl/kali.cnf. Here's the interesting part of the strace
output:

  $ sudo strace -e trace=file named --help
  [...]
  newfstatat(AT_FDCWD, "/etc/ssl/kali.cnf", {st_mode=S_IFREG|0644, st_size=653, 
...}, 0) = 0
  openat(AT_FDCWD, "/etc/ssl/kali.cnf", O_RDONLY) = -1 EACCES (Permission 
denied)
  tls.c:88: fatal error: RUNTIME_CHECK(OPENSSL_init_ssl((0x0200L | 
0x0400L | 0x1000L | 0x2000L | 0x4000L) | 0x0040L, ((void 
*)0)) == 1) failed
  --- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=2631, si_uid=0} ---
  +++ killed by SIGABRT +++
  zsh: IOT instruction sudo strace -e trace=file named --help

This is due to the apparmor profile for named, which is pretty
restrictive regarding which openssl config files are allowed:

  debian/extras/apparmor.d/usr.sbin.named
  
  # ssl
  /etc/ssl/openssl.cnf r,

I wonder if this part could be relaxed a bit, with something like:

  # ssl
  /etc/ssl/*.cnf r,
  /etc/ssl/*.conf r,

To give more context: in Kali Linux we ship the openssl config file at
the usual location /etc/ssl/openssl.cnf, but we also have a second file
with extra configuration at /etc/ssl/kali.cnf. This second file is
included from the main file, using the .include directive.

As documented in the openssl config man page (`man 5 config`), the
.include directive allows to include *any* location, which doesn't
really help here... But the man page also says (more or less) that the
standard extension for openssl config files should be .cnf or .conf.

The change I suggest above would give more rope to sysadmins (or
derivatives like Kali Linux), and would allow named to read any config
file, as long as it's located in /etc/ssl and have the .cnf or .conf
extension.

I looked at other packages and I found that cupsd does something
similar:
https://salsa.debian.org/printing-team/cups/-/blob/debian/main/debian/local/apparmor-profile


Best,

Arnaud

Bug#779707: Errors when reading dicomdir file: "No images found" / "Loading: DICM Error reading file"

[Andreas Tille]

Control: tags -1 wontfix

Hi Erik,

Am Tue, Dec 06, 2022 at 12:11:09AM +0100 schrieb Erik Nolf:
> Aah, dicomdir. This is something we leave to AMIDE, which is better suited
> and uses the established dcmtk toolkit.
> 
> (X)MedCon is really only capable of reading just one file (although with
> multiple images), like it was usual in nuclear medicine some decades ago.
> 
> Most other DICOM modalities are multiple files for multiple instances,
> sometimes referenced in a dicomdir file. My poor amateurish (X)MedCon
> coding decisions won't handle that. Sorry, I am afraid it will stay that
> way.

Thanks a lot for the clarification.  So I'm tagging the bug wontfix to
keep it documented that way.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Bug#779707: Errors when reading dicomdir file: "No images found" / "Loading: DICM Error reading file"

[Erik Nolf]

Hi Andreas

Op zo 4 dec. 2022 om 18:37 schreef Andreas Tille :

> Control: tags -1 upstream
> Control: forwarded -1 Erik Nolf 
> Hi Erik,
> there is a long standing bug report in the Debian bug tracking system.
> I'd like to bring this to your attention in case you see any chance
> to enhance xmedcon.
>

Aah, dicomdir. This is something we leave to AMIDE, which is better suited
and uses the established dcmtk toolkit.

(X)MedCon is really only capable of reading just one file (although with
multiple images), like it was usual in nuclear medicine some decades ago.

Most other DICOM modalities are multiple files for multiple instances,
sometimes referenced in a dicomdir file. My poor amateurish (X)MedCon
coding decisions won't handle that. Sorry, I am afraid it will stay that
way.

Cheers,
Erik

Kind regards
>  Andreas.
>
> --
> http://fam-tille.de
>

Bug#1025518: bullseye-pu: package capnproto/0.7.1-1+deb11u1

[tony mancill]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: capnpr...@packages.debian.org
Control: affects -1 + src:capnproto

Dear Release Team,

This is a bit of an odd one...  I have contacted the Security Team and
they have recommended that this go through stable-proposed-updates.

CVE-2022-46149 [1] is a recently announced vulnerability in the
capnproto [2] package that impacts the versions available in oldstable
and stable (0.7.0) and the upcoming bookworm release.

As the upstream author notes in [3], the issue is present in inlined
code, thus applications built against capnproto must be rebuilt against
the patched version.

The issue for unstable and bookworm is being addressed via an
upload to experimental [4] and a subsequent transition [5].  Easy
enough...

For stable (and old-stable), we need to introduce 0.7.1, a new upstream
version that generates a (new) libcapnp-0.7.1 binary package to address
the vulnerability.  Once those are present in the archive, we can
trigger rebuilds of the reverse dependencies.  At this time I am asking
for bullseye.

[ Reason ]
This is to address CVE-2022-46149 [1].

[ Impact ]
Packages built with capnproto in bullseye will remain potentially
vulnerable to the CVE.

[ Tests ]
I have built the package in a clean bullseye chroot and then used ratt to
rebuilt the (8) bullseye r-deps:

- clickhouse_18.16.1+ds-7.2
- harvest-tools_1.3-6
- laminar_1.0-3
- librime_1.6.1+dfsg1-1
- mash_2.2.2+dfsg-2
- mir_1.8.0+dfsg1-18
- rr_5.4.0-2
- sonic-visualiser_4.2-1

[ Risks ]
The upstream author has stated that there are no known vulnerable
applications, yet advises that all capnproto users rebuild their
applications using patched versions of capnproto.

The patch is simple enough, but obviously the transition process is not.  

[ 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 ] 
The upstream patch for this issue is small [6], but upstream used a
slightly newer version of autoconf when packaging 0.7.1 than was used in
0.7.0, and so the debdiff between the source versions ends up with a lot
of boilerplate autoconf diff.

The only change to the Debian packaging is the requisite SONAME bump to
generate the 0.7.1 library package for transition of the r-deps.

[ Other info ]
My email exchange with the Security Team included Salvatore Bonaccorso
and Moritz Muehlenhoff.  If this works and is amenable, old-stable would
be next.

If this is not amenable to stable-proposed-updates, would you recommend
backports?

Thank you for considering this request!
tony

[1] https://nvd.nist.gov/vuln/detail/CVE-2022-46149
[2] https://tracker.debian.org/pkg/capnproto
[3] 
https://github.com/capnproto/capnproto/security/advisories/GHSA-qqff-4vw4-f6hx
[4] 
https://tracker.debian.org/news/1393214/accepted-capnproto-092-1-source-amd64-into-experimental/
[5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025449
[6] 
https://github.com/capnproto/capnproto/commit/14adbb11e98db714f09c30b8c40415325a55157a


signature.asc
Description: PGP signature

Bug#1025517: ITP: firefox-esr-mobile-config -- Default mobile-friendly configuration for Firefox ESR

[undef]

Package: wnpp
Severity: wishlist
Owner: Jarrah Gosbell 
X-Debbugs-Cc: debian-de...@lists.debian.org, undef 

* Package name: firefox-esr-mobile-config
  Version : 3.1.0
  Upstream Author : Oliver Smith 
* URL : http://gitlab.com/postmarketOS/mobile-config-firefox
* License : MPL
  Programming Lang: CSS, JS
  Description : Default mobile-friendly configuration for Firefox ESR

This package provides a set of configuration files aimed at making Firefox ESR
more mobile-friendly. It provides:
  * default preferences values
  * custom userChrome.css

This package will be maintained under the Debian on Mobile team.

Bug#1025203: r-cran-glmmtmb: FTBFS on mipsel

[Andreas Tille]

Ping?  If this can't be clarified I'd probably ask ftpmaster for removal
of the package for mipsel.
Kind regards, Andreas.

Am Thu, Dec 01, 2022 at 07:15:27AM +0100 schrieb Andreas Tille:
> Hi,
> 
> Am Wed, Nov 30, 2022 at 10:08:14PM +0100 schrieb Paul Gevers:
> > Source: r-cran-glmmtmb
> > Version: 1.1.4+dfsg-3
> > Severity: serious
> > Tags: ftbfs
> > Justification: ftbfs
> > 
> > Dear maintainer(s),
> > 
> > Your package failed to build from source on mipsel, where it built
> > successfully in the past.
> > 
> > https://buildd.debian.org/status/fetch.php?pkg=r-cran-glmmtmb=mipsel=1.1.5%2Bdfsg-1=1669057119=0
> > ...
> > cc1plus: out of memory allocating 1058400 bytes after a total of 59473920 
> > bytes
> 
> Isn't this just a matter of the autobuilders hardware?
> 
> If not I do not see any other clue but removing the package for mipsel.
> 
> Kind regards
> 
>  Andreas.
> 
> -- 
> http://fam-tille.de

-- 
http://fam-tille.de

Bug#998779: bs1770gain: bashism in configure script

[Petter Reinholdtsen]

[Peter Belkner]
> Hi Petter,
> 
> I've tested it with all '=' replaced by '==' and it seemed to be ok.

Very good.  While these changes in the latest version of bs1770gain kept
the script working with bash, it was not enough to get it working with dash.

This is the output I get when trying 'dash ./configure':

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports the include directive... yes (GNU style)
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for ar... ar
checking the archiver (ar) interface... ar
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking dependency style of gcc... (cached) gcc3
checking for ranlib... ranlib
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
no
/usr/bin/ld: /tmp/user/1000/cctFYkiC.o: in function `main':
:(.text+0x5): undefined reference to `avutil_version'
collect2: error: ld returned 1 exit status
./configure: line 5754: /tmp/user/1000/tmp.xKhoNsmK13: No such file or directory
/usr/bin/ld: /tmp/user/1000/ccwi8v3m.o: in function `main':
:(.text+0x5): undefined reference to `avcodec_version'
collect2: error: ld returned 1 exit status
./configure: line 5774: /tmp/user/1000/tmp.fQaq5bsCgh: No such file or directory
/usr/bin/ld: /tmp/user/1000/ccbh40N8.o: in function `main':
:(.text+0x5): undefined reference to `avformat_version'
collect2: error: ld returned 1 exit status
./configure: line 5794: /tmp/user/1000/tmp.b0doz3j5GV: No such file or directory
/usr/bin/ld: /tmp/user/1000/ccfWZHiU.o: in function `main':
:(.text+0x5): undefined reference to `swresample_version'
collect2: error: ld returned 1 exit status
./configure: line 5814: /tmp/user/1000/tmp.nNEWDzzPrk: No such file or directory
/usr/bin/ld: /tmp/user/1000/cc0Noh1B.o: in function `main':
:(.text+0x5): undefined reference to `swscale_version'
collect2: error: ld returned 1 exit status
./configure: line 5834: /tmp/user/1000/tmp.D8Ug6LetJU: No such file or directory
/usr/bin/ld: /tmp/user/1000/ccVL8tbm.o: in function `main':
:(.text+0x5): undefined reference to `postproc_version'
collect2: error: ld returned 1 exit status
./configure: line 5854: /tmp/user/1000/tmp.LDKuGtXYra: No such file or directory
/usr/bin/ld: /tmp/user/1000/cc9Q27V7.o: in function `main':
:(.text+0x5): undefined reference to `avfilter_version'
collect2: error: ld returned 1 exit status
./configure: line 5874: /tmp/user/1000/tmp.WBZPnAaQZk: No such file or directory
configure: linking FFmpeg
checking pthread.h usability... yes
checking pthread.h presence... no
configure: WARNING: pthread.h: accepted by the compiler, rejected by the 
preprocessor!
configure: WARNING: pthread.h: proceeding with the compiler's result
checking for pthread.h... yes
checking for pthread_create in -lpthread... ./configure: line 6201: 
ac_fn_c_try_link: command not found
no
configure: ***
configure: * pthread not found.  *
configure: * bs10gain will be build without support for parallel processing. *
configure: ***
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating libpbutil/Makefile
config.status: creating lib1770-2/Makefile
config.status: creating libff/Makefile
config.status: creating libbg/Makefile
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands

Because of this I keep this bug report open.
-- 
Happy hacking
Petter Reinholdtsen

Bug#998779: bs1770gain: bashism in configure script

[Petter Reinholdtsen]

[Petter Reinholdtsen]
> Very good.  While these changes in the latest version of bs1770gain kept
> the script working with bash, it was not enough to get it working with
> dash.

Sorry, my mistake.

> This is the output I get when trying 'dash ./configure':

I have to use 'dash ./configure --with-ffmpeg=/usr', then it work.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1011155: python-cryptography - please update to latest >= v35 releases

[Carsten Schoenert]

Hello Claudius, hello Tristan,

I'd like to ask if there are some more major issues outstanding to get
python-cryptography updated to a recent version as we are getting cloder
to the first freeze date of the bookworm release.

What is the status for this wishlist bug report?
I think it's quite important to get really recent versions ready for the
bookworm release, especially in the segement of cryptography.

Is there something a required update would need some help?

Am Fri, Jul 29, 2022 at 10:07:04AM -0400 schrieb Alex Gaynor:
> As one of the maintainers of pyca/cryptography, I'm strongly in favor
> of upgrading. Older releases do not receive support (including
> security fixes) from the maintainers. And in the past few releases
> we've added many new features, support for more strong cryptographic
> algorithms, and significantly improved performance.

Regrads and thanks!
Carsten

Bug#942704: Breaking changes to bs1770gain XML output between 0.5 and 0.6

[Petter Reinholdtsen]

Control: tags -1 + wontfix

[Etienne Dechamps
> There are at least two breaking changes to the XML output format
> between 0.5 and 0.6: The  element disappeared and the
> "factor" attribute was renamed to "amplitude".

It is unfortunate that the XML output changed without warning.  I have been
in touch with upstream, and while he agrees that the XML output changed
in an incompatible way, he do not plan to keep the old format.  In fact
he is contemplating to drop the XML output completely in favour of CSV.

> I'm also wondering if that means bs1770gain 0.6 should
> be in a separate package altogether so that existing 0.5 packages
> won't be automatically upgraded?

I believe it is both too late for this, and that we lack the man-hours
needed to maintain a separarate 0.5 package with no upstream support
in Debian.

Sorry about this, but I believe the users of XML will have to move to
the new format.
-- 
Happy hacking
Petter Reinholdtsen

Bug#1016359: [edk2-devel] [Patch 1/2] OvmfPkg: Change default to disable MptScsi and PvScsi

[Gerd Hoffmann]

On Mon, Dec 05, 2022 at 04:36:15PM -0700, dann frazier wrote:
> On Tue, Jul 26, 2022 at 12:46:39PM -0700, Michael D Kinney wrote:
> > The email addresses for the reviewers of the MptScsi and
> > PvScsi are no longer valid.  Disable the MptScsi and PvScsi
> > drivers in all DSC files until new maintainers/reviewers can
> > be identified.
> 
> Hi Michael,
> 
>   This seems likely to be the reason for the following regression
> report in Debian:
>   
>   https://bugs.debian.org/1016359

I'm not so sure about that.

> > -  DEFINE PVSCSI_ENABLE   = TRUE
> > -  DEFINE MPT_SCSI_ENABLE = TRUE
> > +  DEFINE PVSCSI_ENABLE   = FALSE
> > +  DEFINE MPT_SCSI_ENABLE = FALSE
> >DEFINE LSI_SCSI_ENABLE = FALSE

The bug report talks about lsilogic and virtio-scsi.

lsilogic was already disabled by default before this patch.

virtio-scsi support is included and there are no plans to change
that because it is a rather essential driver.  It works just fine
upstream, and there isn't even a config switch to disable it.

take care,
  Gerd

Bug#909015: abiword: Crashes on startup with GLib-ERROR

[Alban Browaeys]

> this crash seems to be caused by a broken opengl configuration.
> It could still be seen with buster when e.g. someone has the
> nvidia-driver-libs-nonglvnd installed without the kernel module
loaded.
> 
> Unfortunately there is no output at stdout that would point
> the user to that direction. Instead the application just crashes.
> 
> With attached patch the cogl initialization would at least just fail
and
> clutter could write an error message to stdout.
>   Unable to initialize Clutter: Unable to initialize the Clutter
backend: no available drivers found.
> 
> Kind regards,
> Bernhard

Thanks for your work !

Note, your patch should limit itself to initialize num_extensions to
zero. Seems it was enough to fix the issue on your setup.

The other parts of the patch touches the gles not the gl code so it
does not run on your test setup. (ie gles is not run if nvidia GLX is
involved only gl. The gdb output you pasted to the bug report shows it:
#6  0xb5e46426 in _cogl_driver_update_features (ctx=0x988688, error=0xbfeecfa8) 
at driver/gl/gl/cogl-driver-gl.c:380
).

Maybe a patch local to debian would do per upstream is archived
https://discourse.gnome.org/t/retiring-clutter-and-friends/8949 "
Clutter, Cogl, Clutter-GTK, and Clutter-GStreamer will be moved to the
Archive group in GitLab 3 once GNOME 42 is released in March. You won’t
be able to file new issues, or open new merge requests. No new releases
will be made.
ebassi Emmanuele Bassi GNOME Team Feb 16 2022
"

If your are at ease with gitlab you could submit a Merge Request
to https://salsa.debian.org/gnome-team/cogl/-/tree/debian/master as a
patch file under debian/patches.


Best bet for abiword is to move out of clutter and clutter-gtk to fix
this issue (as the abiword stack trace the crashes happens in the call
gtk_clutter_init
#17 0xb60f65f2 in gtk_clutter_init (argc=0xbfeed254, argv=0xbfeed17c) at 
./gtk-clutter-util.c:233
libabiword-3.0 3.0.5~dfsg-3.2 in bookworm does not depend on libclutter (thus 
libcogl20) anymore.
bullseye libabiword-3.0 3.0.4~dfsg-3 still does thought.

The clutter-gtk library was included in abiword as it is a dependency of 
libchamplain-gtk (which abiword
be linked against optionaly).
The abiword debian package stopped requiring libchamplain-gtk-0.12-dev in 
abiword 3.0.5~dfsg-2 per 
https://salsa.debian.org/debian/abiword/-/blob/debian/3.0.5_dfsg-2/debian/control
thus the binary does not link to libchamplain-gtk anymore since libabiword-3.0 
3.0.5~dfsg-2.

Note that if one rebuild the package and has libchamplain-gtk-0.12-dev the 
clutter gtk dependency will
come back per champlain-gtk is not explicitly disabled in the abiword 
debian/rules.


https://salsa.debian.org/debian/abiword/-/blob/debian/latest/src/wp/ap/gtk/ap_UnixApp.cpp#L1300
#ifdef WITH_CHAMPLAIN
ClutterInitError err = gtk_clutter_init (, );
if (err != CLUTTER_INIT_SUCCESS) {
g_warning("clutter failed %d, get a life.", err);
}
#endif


There is no logged output from abiword about the crash because to get 
clutter/cogl debug output
one has to set an environment variables 
https://wiki.gnome.org/Projects/Clutter/Profiling
Setting COGL_DEBUG=all will output a lot of debug output (sadly Debian 
libclutter-1.0 is built with debug at
 minimum so CLUTTER_DEBUG=all does not give clutter debug messages).

Best Regards,
Alban

Bug#1025516: bugs.debian.org: affects from a library bug report against an application cannot be limited to a version

[Alban Browaeys]

Package: bugs.debian.org
Severity: wishlist

I would like to leave a bug report with its "affects" mark but version this one.

This as a bug report (#909015) against a libcogl20 issue which is marked as 
"affects"
abiword per abiword crashes due to this libcogl20 issue (but only on specific 
setups).

It turns out that abiword (in fact libabiword-3.0) does not link to
clutter/cogl (via its libchamplain-gtk-0.12-dev build depedency) anymore in 
bookworm
ie since libabiword-3.0 3.0.5~dfsg-2.

But I see no mean to set thhis libcogl20 bug as affects libabiword-3.0
but only below the 3.0.5~dfsg-2 version.

PS: an extreme use case would be to be able to set affects an application
but on multiple versions range (ie only not all versions).

Or maybe affects should simply not get used to tag an application as
affected by a library bug. Your call.

Best regards,
Alban

Bug#1025515: ITP: libnginx-mod-http-brotli -- Nginx module libnginx-mod-http-brotli

[Jan Mojzis]

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

* Package name: libnginx-mod-http-brotli
  Version : 1.0.0rc
  Upstream Author : Google Inc
* URL : https://github.com/google/ngx_brotli
* License : BSD
  Programming Lang: C
  Description : libnginx-mod-http-brotli module for Nginx


libnginx-mod-http-brotli is new module for Nginx web server.
it is a set of two nginx modules:
libnginx-mod-http-brotli-filter - filter module - used to compress responses 
on-the-fly,
libnginx-mod-http-brotli-static - used to serve pre-compressed files.

I would like to maintain the package using 
https://salsa.debian.org/nginx-team/libnginx-mod-http-brotli

I need sponsor only for the first upload (I'm DM).
Thank You!

Bug#1025514: xfsprogs: Allow by-uuid link in mount option logdev

[tomas k]

Package: xfsprogs
Version: 5.10.0-4
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: foren...@wi.rr.com

Is there any way for mkfs.xfs to give the external log a UUID,
so external drives with externaL logs can be mounted from fstab
even if the partition device files change letters?



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

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

Versions of packages xfsprogs depends on:
ii  libblkid1   2.36.1-8+deb11u1
ii  libc6   2.31-13+deb11u4
ii  libdevmapper1.02.1  2:1.02.175-2.1
ii  libedit23.1-20191231-2+b1
ii  libicu6767.1-7
ii  libinih153-1+b2
ii  libuuid12.36.1-8+deb11u1
ii  python3 3.9.2-3

xfsprogs recommends no packages.

Versions of packages xfsprogs suggests:
ii  acl  2.2.53-10
pn  attr 
pn  quota
pn  xfsdump  

-- no debconf information

Bug#1025513: ITP: ubelt -- A Python utility library with a stdlib like feel and extra batteries. Paths, Progress, Dicts, Downloads, Caching, Hashing: ubelt makes it easy!

[Bo YU]

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

* Package name: ubelt
  Version : 1.2.3 
  Upstream Author : Jon Crall 
* URL : https://github.com/Erotemic/ubelt
* License : (GPL, LGPL, BSD, MIT/X, etc.)
  Programming Lang: Python
  Description : A Python utility library with a stdlib like feel
  and extra batteries. Paths, Progress, Dicts, Downloads, Caching, 
  Hashing: ubelt makes it easy!

Ubelt is a small library of robust, tested, documented, and simple 
functions that extend the Python standard library. It has a flat API 
that all behaves similarly on Windows, Mac, and Linux (up to some small
unavoidable differences). Almost every function in ubelt was written 
with a doctest. This provides helpful documentation and example usage 
as well as helping achieve 100% test coverage (with minor exceptions 
on Windows).

The package blocks to be fixed for #1024047 and I will maintain it
under DPT. 

-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#638256: Bug 638256 Update - Still Exists

[Dave]

TO: 638...@bugs.debian.org


And... Still a bug.  Since at least 2010...

As of December 2022 this is still an issue in 3.1.23.1-1

ii  at 3.1.23-1.1   arm64Delayed job execution and 
batch processing


ls -l /usr/sbin/atd
-rwxr-xr-x 1 root root 26568 Sep 25  2020 /usr/sbin/atd


/var/log/syslog (and/or /var/log/cron) filled with:
...
Dec  5 21:11:36 mysys atd[17889]: File a006e001a8bf99 is in wrong format 
- aborting
Dec  5 21:11:36 mysys atd[17890]: File a006e001a8bf99 is in wrong format 
- aborting
Dec  5 21:11:36 mysys atd[17891]: File a006e001a8bf99 is in wrong format 
- aborting
Dec  5 21:11:36 mysys atd[17892]: File a006e001a8bf99 is in wrong format 
- aborting

...

/var/spool/cron/atjobs contained:
drwxrwx--T 2 daemon daemon 4096 Dec  5 21:11  .
drwxr-xr-x 5 root   root   4096 Dec  4 11:30  ..
-rw--- 1 daemon daemon6 Dec  4 13:18  .SEQ
-rwx-- 2 dabdaemon0 Dec  4 13:18 '=006e001a8bf99'
-rwx-- 2 dabdaemon0 Dec  4 13:18  a006e001a8bf99

Deleting these zero-sized files/jobs and restarting atd resolved the issue.

I'm not a developer, but a possible quick fix would be to add:
  find /var/spool/cron/atjobs/ -type f -empty -print -delete
to the /etc/init.d/atd start stanza

Although this would only cover instances when/where atd is (re)started.

Bug#809034: Vcs-Git point to upstream repository

[Bastian Germann]

The SVN repo does not exist anymore, so you should drop that as well.

Bug#1025512: elfutils: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Paulo Henrique de Lima Santana]

Package: elfutils
Tags: l10n patch
Severity: wishlist

Hello,

Could you please update this Brazilian Portuguese translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and
tested with msgfmt and podebconf-display-po.

Kind regards.

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


pt_BR.po.gz
Description: application/gzip


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023755: logcheck-database: New default rsyslog high-precision timestamp breaks most rules

[Richard Lewis]

On Mon, 5 Dec 2022, 09:29 Jose M Calhariz,  wrote:

> can someone do a minimal patch proposing a way to solve this issue?
>

Hi, Not a patch, but a recipe to patch every rule:

for x in ignore.d.* violations.*; do  sed -i -E
's,^\^((\\w|\[\[:alpha:\]\])\{3\} \[
:(0-9|\[:digit:\])\]\{11\}),^(\1|[0-9T:.+-]{32}),' $x/*; done

I make it 183 files modified (I dont know if the "for" loop is really
needed, but sed didnt want like than one glob on the line)

This is replacing ^ with ^(old prefix|new prefix) in every
rulefile. The regex-special chars need escaping in the first bit of sed,
but not the replacement. It is safe to run multiple times, but it does
modify files, so take care. I have not done a lot of testing on this yet
either.

There are several variants of  in the package:
^\w{3} [ :0-9]{11}  is the most common (eg ignore.d.server/acpid)
^[[:alpha:]]{3} [ :[:digit:]]{11}  is used in ignore.d.server/systemd
^\w{3} [ :[:digit:]]{11} is used in ignore.d.paranoid/bind
i didnt check if anything used the fourth variant, ie '^[[:alpha:]]{3} [
:0-9]{11}' but that would also be caught by the expression too

The sed expression preserves these variants, but it would be even better to
replace the \1 with whichever variant is preferred.

In the replacement, I  we want the old prefix _first_ for future-proofing:
rsyslog is being demoted in priority: it may still be pulled in as
dependencies, more and more we will see systems without rsyslog installed
at all - all the logging will be in the journal.  So to remain useful,
logcheck will need to enable checking of the systemd journal as well as
/var/log/syslog. And the journal lines are extracted by logcheck in the
"old" format. So I think we should do this change with that in mind.

The NEWS.Debian needs an entry as users will need to make a similar change
in their own rules - i assume no-one uses logcheck without hundreds of
local modifications in /etc/logcheck. I can help write that, but I didnt
find the time yet.

I didnt do a proper patch yet - i could build one on top of the merge
request submitted for
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020827  - i think
#1020827 is almost as important to fix as this bug.

Richard

Bug#1025511: Drop/replace the Vcs

[Bastian Germann]

Source: renaissance
Version: 0.9.0-4.1

Please drop or replace the Vcs fields from debian/control. The arch.debian.org 
is no longer in service.
The repository seems to be located at 
https://salsa.debian.org/gnustep-team/renaissance

Bug#1025510: Drop/replace the Vcs

[Bastian Germann]

Source: mpdcon.app
Version: 0+20080616+dfsg-2

Please drop or replace the Vcs fields from debian/control. The arch.debian.org 
is no longer in service.
The repository seems to be located at 
https://salsa.debian.org/gnustep-team/mpdcon.app

Bug#1025509: Drop/replace the Vcs

[Bastian Germann]

Source: etoile
Version: 0+20080616+dfsg-2

Please drop or replace the Vcs fields from debian/control. The arch.debian.org 
is no longer in service.
The repository seems to be located at 
https://salsa.debian.org/gnustep-team/etoile

Bug#1023988: Now file is attached

[Paulo Henrique de Lima Santana]

Hi,

Please, find attached the Brazilian Portuguese translation.
It is UTF-8 encoded, tested with msgfmt.

Best regards,

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


pt_BR.po.gz
Description: application/gzip


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025508: onionprobe: config and examples installed to unusual locations

[Stefano Rivera]

Source: onionprobe
Version: 1.0.0+ds-2.1
Severity: normal

The next upload of dh-python will change the layout of onionprobe's
installed data:

$ debdiff existing/onionprobe_1.0.0+ds-2.1_all.deb 
new/onionprobe_1.0.0+ds-2.1_all.deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .deb but not in first
-
-rw-r--r--  root/root   /usr/onionprobe/configs/real-world-onion-sites.yaml
-rw-r--r--  root/root   /usr/onionprobe/configs/securedrop.yaml
-rw-r--r--  root/root   /usr/onionprobe/configs/tor.yaml
-rwxr-xr-x  root/root   /usr/onionprobe/examples/real-world-onion-sites.py
-rwxr-xr-x  root/root   /usr/onionprobe/examples/securedrop.py
-rwxr-xr-x  root/root   /usr/onionprobe/examples/tpo.py

Files in first .deb but not in second
-
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/onionprobe/configs/real-world-onion-sites.yaml
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/onionprobe/configs/securedrop.yaml
-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/onionprobe/configs/tor.yaml
-rwxr-xr-x  root/root   
/usr/lib/python3/dist-packages/onionprobe/examples/real-world-onion-sites.py
-rwxr-xr-x  root/root   
/usr/lib/python3/dist-packages/onionprobe/examples/securedrop.py
-rwxr-xr-x  root/root   
/usr/lib/python3/dist-packages/onionprobe/examples/tpo.py

Control files: lines which differ (wdiff format)

Installed-Size: [-263-] {+264+}

This is due to the fix for #1025485.

Neither of these looks quite correct. /usr/onionprobe would be against
the FHS.

If the package expects to find configs and examples within its module,
then this change will break it, and you'll probably need to patch the
setup.cfg or manually move the files around.

If it doesn't, then they should probably be moved to /etc/ and
/usr/share/doc/onionprobe/.

SR

Bug#1024549: espeakup: crashes during speech synthesis installation, snd_pcm_area_copy assertion failed

[Samuel Thibault]

Arnaud Rebillout, le lun. 05 déc. 2022 16:05:00 +0700, a ecrit:
> On 05/12/2022 03:52, Samuel Thibault wrote:
> > I was about to try to investigate, but I cannot reproduce it with the
> > daily image any more. It uses the new alsa-lib 1.2.8 upstream version,
> > so perhaps the bug was just fixed, could you also give it a try?
> 
> I just grabbed the daily image. I can confirm that it comes with alsa 1.2.8,
> and also with espeakup 1:0.90-12 (ie. it contains your code to restart
> espeakup).
> 
> On my side, espeakup keeps crashing, but it's restarted thanks to your
> changes. I wouldn't have noticed the crashes if I didn't look at the logs.

Heh, obviously, didn't realize that my change was there and that I would
then not see the crash :D

Will have a better look next time I get around to it :)

Samuel

Bug#1025374: firefox: reproducible crashes on various websites

[Vincent Lefevre]

Control: reassign -1 nvidia-legacy-390xx-driver 390.154-2
Control: retitle -1 nvidia-legacy-390xx-driver less than 390.157 makes Firefox 
crash and prevents the X server from starting with recent Linux kernels
Control: fixed -1 390.157-1

On 2022-12-03 12:49:39 +0100, Vincent Lefevre wrote:
> Since FF 107, I've noticed crashes on several websites, including
> Facebook (even just after a restart).
> 
> In particular, I can reproduce the crash on http://www.sylvainshunt.com
> (where I don't expect the contents to change, so this should be a good
> testcase) with a new profile. Upstream's Firefox Nightly is also
> affected.
> 
> I don't know whether all these crashes are due to the same bug, though.
> But I had never had any such crash with FF in the previous months, and
> even years, IIRC.

I could reproduce the crashes with older FF versions, even FF 93.
When I logged out, the display manager was no longer working (ditto
for the Linux virtual terminals), apparently because the X server
could not restart, and reboots did not solve the issue.

The X server issue appeared at least with the 6.0.0-4-amd64 and
6.0.0-5-amd64 Linux kernels.

These crashes were actually due to the Nvidia driver and disappeared
with the upgrade to 390.157-1 (which appeared yesterday). In the
Debian changelog of this version:

  Improved compatibility with recent Linux kernels.

I suppose that this was the issue.

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

Bug#1013311: bug 1013311 libgl1-mesa-dri: mesa 22.x package build removes support for Intel Gen2 and Gen3 chipsets

[Felix Miata]

> Package: libgl1-mesa-dri
> Version: 22.2.0-1

See also:

[libgl1-mesa-dri] libgl1-mesa-dri: AIGLX error: dlopen of 
/usr/lib/x86_64-linux-gnu/dri/i965_dri.so


>From libgl1-mesa-dri:amd64 changelog:
mesa (22.0.0~rc2-1) experimental; urgency=medium

  * New upstream release candidate.
  * path_max.diff: Refreshed.
  * rules: Drop classic drivers (r100, r200, nouveau_vieux, i915, i965).

 -- Timo Aaltonen   Thu, 17 Feb 2022 22:04:03 +0200

# xdriinfo
libGL error: MESA-LOADER: failed to open i915: /usr/lib/dri/i915_dri.so: cannot 
open shared object file: No such file or directory (search paths 
/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)
libGL error: failed to load driver: i915
Screen 0: swrast

# pinxi -GSaz --vs --zl --hostname
pinxi 3.3.23-05 (2022-11-07)
System:
  Host: gx62b Kernel: 5.19.0-2-amd64 arch: x86_64 bits: 64 compiler: gcc
v: 11.3.0 parameters: root=LABEL= ipv6.disable=1 net.ifnames=0
biosdevname=0 plymouth.enable=0 noresume mitigations=auto consoleblank=0
  Desktop: Trinity v: R14.0.13 tk: Qt v: 3.5.0 info: kicker wm: Twin v: 3.0
vt: 7 dm: 1: TDM 2: XDM Distro: Debian GNU/Linux bookworm/sid
Graphics:
  Device-1: Intel 82945G/GZ Integrated Graphics vendor: Dell driver: i915
v: kernel arch: Gen-3.5 process: Intel 90nm built: 2005-06 ports:
active: DVI-D-1,VGA-1 empty: none bus-ID: 00:02.0 chip-ID: 8086:2772
class-ID: 0300
  Display: x11 server: X.Org v: 1.21.1.4 driver: X: loaded: modesetting
dri: swrast gpu: i915 display-ID: :0 screens: 1
  Screen-1: 0 s-res: 3600x1200 s-dpi: 120 s-size: 762x254mm (30.00x10.00")
s-diag: 803mm (31.62")
  Monitor-1: DVI-D-1 pos: primary,left model: NEC EA243WM serial: 
built: 2011 res: 1920x1200 hz: 60 dpi: 94 gamma: 1.2
size: 519x324mm (20.43x12.76") diag: 612mm (24.1") ratio: 16:10 modes:
max: 1920x1200 min: 640x480
  Monitor-2: VGA-1 pos: right model: Dell P2213 serial:  built: 2012
res: 1680x1050 hz: 60 dpi: 90 gamma: 1.2 size: 473x296mm (18.62x11.65")
diag: 558mm (22") ratio: 16:10 modes: max: 1680x1050 min: 720x400
  API: OpenGL v: 4.5 Mesa 22.2.4 renderer: llvmpipe (LLVM 15.0.5 128 bits)
direct render: Yes

In Bullseye:
...
  API: OpenGL v: 1.4 Mesa 20.3.5 renderer: Mesa DRI Intel 945G
direct render: Yes
# xdriinfo
Screen 0: i915

What are Bookworm users supposed to do to make Mesa DRI work correctly
now that i915_dri.so is missing? Did it get moved to some other .deb
I can't ID? I don't think Crocus is supposed to work on Gen3. At least,
export MESA_LOADER_DRIVER_OVERRIDE=crocus in /etc/X11/Xsession.d/10-crocus.sh
doesn't help.

Where is the "Gallium i915" driver?

In openSUSE Tumbleweed in 22.2.4 i915 is still included in its Mesa-dri
package, and Mesa DRI Intel 945G is working as expected.


Debian packaging apparently just decided not to include i915g in the
transition?  Not our fault.
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Bug#997222: libexplain: FTBFS in bullseye

[Santiago Vila]

Hi.

I'm considering to make an upload to fix this in bullseye.

Am I right to think that the termiox patch with the following changelog 
entry is also desirable to be able to build from bullseye+recent kernel?


  - Patch: termiox removed since kernel 5.12, from ALT Linux.

Thanks.

Bug#1025507: tightvnc-java: FTBFS with OpenJDK 17 due to unsupported javac source/target level 6

[Sven Geuer]

Package: tightvnc-java
Version: 1.3.10-3
Severity: important
Tags: ftbfs, sid, bookworm
User: debian-j...@lists.debian.org
Usertags: default-java17

tightvnc-java fails to build during reproducibility testing since the
transition from OpenJDK 11 to OpenJDK 17, see [1].

 Fri Nov 25 06:35:13 UTC 2022  I: starting to build tightvnc-
java/unstable/amd64 on jenkins on '2022-11-25 06:35'
 Fri Nov 25 06:35:13 UTC 2022  I: The jenkins build log is/was available at
https://jenkins.debian.net/userContent/reproducible/debian/build_service/amd64_27/16018/console.log
 Fri Nov 25 06:35:13 UTC 2022  I: Downloading source for unstable/tightvnc-
java=1.3.10-3
 [...]
 Setting up openjdk-17-jdk:amd64 (17.0.5+8-2) ...
 [...]
 error: Source option 6 is no longer supported. Use 7 or later.
 error: Target option 6 is no longer supported. Use 7 or later.
 [...]

[1] https://tests.reproducible-builds.org/debian/rb-
pkg/unstable/amd64/tightvnc-java.html


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

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

tightvnc-java depends on no packages.

tightvnc-java recommends no packages.

Versions of packages tightvnc-java suggests:
pn  tightvncserver  

-- no debconf information

Bug#1025506: procps: trying to overwrite 'free.1.gz', which is also in package manpages-zh

[Witold Baryluk]

Package: procps
Version: 2:3.3.17-7.1
Severity: normal
X-Debbugs-Cc: witold.bary...@gmail.com

Updating with a number of manpages packages installed, show this file
conflict:

Preparing to unpack .../01-procps_2%3a4.0.2-1_amd64.deb ...
Unpacking procps (2:4.0.2-1) over (2:3.3.17-7.1) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-nlCZ6Y/01-procps_2%3a4.0.2-1_amd64.deb (--unpack):
 trying to overwrite '/usr/share/man/zh_CN/man1/free.1.gz', which is also in 
package manpages-zh 1.6.3.6-1
dpkg: error while cleaning up:
 new procps package post-removal script subprocess returned error exit status 1

After uninstalling manpages-zh, but leaving other manpages packages
installed, procps updates without issues.




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

Kernel: Linux 6.1.0-rc6 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages procps depends on:
ii  init-system-helpers  1.65.2
ii  libc62.36-6
ii  libncurses6  6.3+20220423-2
ii  libncursesw6 6.3+20220423-2
ii  libprocps8   2:3.3.17-7.1
ii  libtinfo66.3+20220423-2

Versions of packages procps recommends:
ii  psmisc  23.5-3

procps suggests no packages.

-- no debconf information

Bug#1024438: mutter: autopkgtest regression: Segmentation fault

[Bernhard Übelacker]

Hello,
I tried to collect some informations.

The segfault happens because "workspace" contains a null pointer.
This null originates from "window->workspace".

Kind regards,
Bernhard



Core was generated by 
`/usr/libexec/installed-tests/mutter-11/mutter-test-runner --all'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0xb7ce33f4 in meta_workspace_index (workspace=0x0) at 
../src/core/workspace.c:722
722   ret = g_list_index (workspace->manager->workspaces, workspace);
[Current thread is 1 (Thread 0xb5082980 (LWP 11034))]
(gdb) bt
#0  0xb7ce33f4 in meta_workspace_index (workspace=0x0) at 
../src/core/workspace.c:722
#1  0xb2e96606 in switch_workspace (plugin=0xe9f200 [MetaDefaultPlugin], 
from=0, to=1, direction=META_MOTION_RIGHT) at 
../src/compositor/plugins/default.c:572
#2  0xb7c9e3a0 in meta_plugin_manager_switch_workspace (plugin_mgr=0xe9b3e0, 
from=0, to=1, direction=META_MOTION_RIGHT) at 
../src/compositor/meta-plugin-manager.c:272
#3  0xb7c94a98 in meta_compositor_switch_workspace (compositor=0xc0e9c0 
[MetaCompositorNative], from=0xe7a320 [MetaWorkspace], to=0xe7a370 
[MetaWorkspace], direction=META_MOTION_RIGHT) at 
../src/compositor/compositor.c:682
#4  0xb7ce5a2f in meta_workspace_activate_with_focus (workspace=0xe7a370 
[MetaWorkspace], focus_this=0x0, timestamp=492883) at 
../src/core/workspace.c:684
#5  0xb7ce5c1e in meta_workspace_activate (workspace=0xe7a370 [MetaWorkspace], 
timestamp=492883) at ../src/core/workspace.c:714
#6  0x0047d8a5 in test_case_do (error=0xbfeb8408, argv=, 
argc=, test=0xece680) at ../src/tests/test-runner.c:1068
#7  run_test (index=, filename=0xac7e20 
"/usr/share/mutter-11/tests/stacking/workspace-basic.metatest", context=) at ../src/tests/test-runner.c:1280
#8  run_tests (context=0xaa4c58 [MetaContextTest], info=0xbfeb8934) at 
../src/tests/test-runner.c:1361
#9  0xb5de77d8 in ffi_call_i386 () at ../src/x86/sysv.S:121
#10 0xb5de6d97 in ffi_call_int (cif=, fn=, rvalue=, rvalue@entry=0xbfeb8570, avalue=, closure=) at 
../src/x86/ffi.c:406
#11 0xb5de7001 in ffi_call (cif=, fn=, 
rvalue=0xbfeb8570, avalue=0xbfeb8530) at ../src/x86/ffi.c:415
#12 0xb7a6f8d5 in g_cclosure_marshal_generic_va (closure=, return_value=, 
instance=, args_list=, marshal_data=, 
n_params=, param_types=) at ../../../gobject/gclosure.c:1650
#13 0xb7a6eed6 in _g_closure_invoke_va (closure=0xab5eb0, return_value=0xbfeb8718, 
instance=0xaa4c58, args=0xbfeb87bc "ȇ\353\277\005", n_params=0, 
param_types=0x0) at ../../../gobject/gclosure.c:895
#14 0xb7a87e4a in g_signal_emit_valist (instance=, signal_id=, detail=, var_args=) at 
../../../gobject/gsignal.c:3456
#15 0xb7a88005 in g_signal_emit (instance=0xaa4c58, signal_id=3, detail=0) at 
../../../gobject/gsignal.c:3606
#16 0xb7eecdb8 in run_tests_idle (user_data=0xaa4c58) at 
../src/tests/meta-context-test.c:221
#17 0xb76fb41e in g_main_dispatch (context=0xaa93f0) at 
../../../glib/gmain.c:3444
#18 g_main_context_dispatch (context=0xaa93f0) at ../../../glib/gmain.c:4162
#19 0xb76fb819 in g_main_context_iterate (context=0xaa93f0, block=block@entry=1, 
dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:4238
#20 0xb76fbb31 in g_main_loop_run (loop=) at 
../../../glib/gmain.c:4438
#21 0xb7cc2c33 in meta_context_run_main_loop (context=0xaa4c58 
[MetaContextTest], error=0xbfeb88e8) at ../src/core/meta-context.c:453
#22 0xb7eed30c in meta_context_test_run_tests (context_test=0xaa4c58 
[MetaContextTest], flags=META_TEST_RUN_FLAG_NONE) at 
../src/tests/meta-context-test.c:283
#23 0x0047aa29 in main (argc=, argv=) at 
../src/tests/test-runner.c:1483

(gdb) print workspace
$1 = 0x0

(gdb) list meta_workspace_index
716
717 int
718 meta_workspace_index (MetaWorkspace *workspace)
719 {
720   int ret;
721
722   ret = g_list_index (workspace->manager->workspaces, workspace);
723   g_return_val_if_fail (ret >= 0, -1);





(gdb) up
#1  0xb2e96606 in switch_workspace (plugin=0xe9f200 [MetaDefaultPlugin], 
from=0, to=1, direction=META_MOTION_RIGHT) at 
../src/compositor/plugins/default.c:572
572   win_workspace = meta_workspace_index (workspace);

(gdb) print window->on_all_workspaces
$2 = 0
(gdb) print window->workspace
$3 = 0x0

(gdb) list switch_workspace
...
567 {
568   MetaWorkspace *workspace;
569   gint   win_workspace;
570
571   workspace = meta_window_get_workspace (window);
572   win_workspace = meta_workspace_index (workspace);
573
574   if (win_workspace == to || win_workspace == from)

Bug#1025505: RFS: runit-services/0.5.1 -- UNIX init scheme with service supervision (services)

[Lorenzo Puliti]

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: plore...@disroot.org

Dear mentors,

I am looking for a sponsor for my package "runit-services":

 * Package name : runit-services
   Version  : 0.5.1
   Upstream contact : [fill in name and email of upstream]
 * URL  : [fill in URL of upstream's web site]
 * License  : BSD-3-Clause, CC0-1.0
 * Vcs  : https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services
   Section  : admin

The source builds the following binary packages:

  runit-services - UNIX init scheme with service supervision (services)

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

  https://mentors.debian.net/package/runit-services/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/r/runit-services/runit-services_0.5.1.dsc

Git repo:

  https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/tree/next

Changes since the last upload:

 runit-services (0.5.1) experimental; urgency=medium
 .
   * dhclient:
  - raise memory limit
  - remove -e option
  - fix wrong keyword in check
  - move interfaces file in a conf subdirectory
   * update README
   * update copyright

Regards,
-- 
  Lorenzo Puliti

Bug#930247: bug#36148: Debian Bug#930247: grep: does not handle backreferences correctly, violating POSIX

[Thorsten Glaser]

Paul Eggert dixit:

> Although you sent your email to 36...@debbugs.gnu.org /
> 930247@bugs.debian.9org, your email is reporting a separate bug

Oh OK, I wasn’t aware, it sounded similar enough.

> I fixed it in the development version of GNU grep by installing the
> attached patch. This patch should appear in the next GNU grep release.

Thank you!

bye,
//mirabilos
-- 
  "Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
 -- Henry Nelson, March 1999

Bug#995670: Updated Zig package uploaded to mentors.d.n

[Nick Hastings]

Hi,

I did some more work on the copyright file, I think it may be ready to
be reviewed. The package is now again at
https://mentors.debian.net/package/zig/

I looked at updating to Zig 0.10.0 (released Oct 31). However, there are
significant changes to the build between 0.9.1 and 0.10.0.  Release
notes are at https://ziglang.org/download/0.10.0/release-notes.html

Zig 0.9.1 simply built a Zig compiler using the system provided compiler
and libraries. This new release attempts to do a self hosted build.
Details are at
https://ziglang.org/download/0.10.0/release-notes.html#Self-Hosted-Compiler

There are three stages to the 0.10.0 build. As I understand them, they
are:

1. Build a zig compiler using system compilers and libraries (similar to
   0.9.1).

2. Use the zig compiler from stage 1 to build a zig compiler from zig
   bundled libraries.

3. Repeat stage 2 using the zig compiler in produced in stage 2.

Attempting this on Debian unstable (and also on bullseye with backported
llvm-15) resulted in a failure at stage 2. It seems the build was not
able to find a particular header file. There may be other problems too,
but I did not investigate further.

The release notes actually suggest waiting until Zig 0.10.1 or Zig
0.11.0 before upgrading from 0.9.1. It seems there will be even larger
changes to the build system for Zig 0.11.0 so I'm not sure how much
effort upstream will be put into fixing build related issues in 0.10.0.

So, at this point I think it may be best to wait for the next release
before attempting to update this package.

Regards,

Nick.

Bug#1024757: Editor: -key ignored

[Kristian Nielsen]

Thanks a lot for the additional information,

"Dr. Nikolaus Klepp"  writes:

> This is what I get when I run "openscad --debug=scintillaeditor":
>
> Pressing  3 times:
> scintillaeditor: KeyRelease - modifiers: shift ctrl alt meta keypad GROUP
> scintillaeditor: KeyRelease - modifiers: shift ctrl alt meta keypad GROUP
> scintillaeditor: KeyRelease - modifiers: shift ctrl alt meta keypad GROUP

There are two interesting observations here:

1. the GROUP modifier (which is Qt::GroupSwitchModifier) is always set, here
and below.

2. The code only sees KeyRelease events for the  key, no key presses,
which could explain why the key has no effect.

I found this Qt bug report, which could be relevant:

  https://bugreports.qt.io/browse/QTBUG-95108

This bug report mentions:

 - As seen in your case, the Qt::GroupSwitchModifier is always set.

 - As a consequence  and other non-printing characters do not work.

 - Apparently introduced in Qt 5.15.5; Unstable has 5.15.6.

 - The problem seems to depend on the keyboard layout.

So some things you could try:

1. Try temporarily setting another keyboard map, eg. plain US layout, and
see if it makes the problem go away (the GROUP modifier in the printout, and
the non-functional  key). I think maybe this command can do it:

  setxkbmap -model pc105 -layout us

2. See if you can reproduce the problem with the Qt example program
"codeeditor", as in the Qt bug. It is available from package
qtbase5-examples as
/usr/lib/x86_64-linux-gnu/qt5/examples/widgets/widgets/codeeditor/codeeditor

3. It would be interesting to try to downgrade Qt to some 5.15.4 version and
see if that solves the problem. However, I'm not sure how feasible that is,
the dependencies around Qt are probably quite complex. The bug also mentions
that reverting patch from QTBUG-49771 fixes their issue, but again I'm not
sure how easy it would be to get a rebuilt Qt with that patch reverted to
test with.

Would be good to determine if the bug QTBUG-95108 could be the root cause.
If not, I'll try to think of a way to debug what is eating the KeyPress
events before they get into the openscad Editor event handler code.

 - Kristian.

Bug#1013662: core-async-clojure: FTBFS randomly in bullseye

[Santiago Vila]

Jérôme Charaoui wrote:
> I'm not opposed to uploading it but I'm curious to know why this is
> needed now, because the next stable release is also "around the
> corner", in relative terms...

I explained that here (sorry for the mistake in the email address).

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013662#25

Packages in stable must build in stable.
The current stable is bullseye.

[ Please cc me on any replies, the BTS does not automatically send 
messages to the bug submitter, and I'm not even the submitter here, I am 
just trying to ensure that we are free from FTBFS bugs in the current 
stable distribution ]


Thanks.

Bug#930247: bug#36148: Debian Bug#930247: grep: does not handle backreferences correctly, violating POSIX

[Paul Eggert]

On 12/1/22 17:21, Thorsten Glaser wrote:

Please fix this bug, it’s really bad and embarrassing.


Thanks for reporting it; I wasn't aware of it.

Although you sent your email to 36...@debbugs.gnu.org / 
930247@bugs.debian.9org, your email is reporting a separate bug, and I 
fixed it in the development version of GNU grep by installing the 
attached patch. This patch should appear in the next GNU grep release.


I suggest not closing the original bug reports, since the original bug 
remains. Of course fixes are welcome but they are lower priority.From b061d24916fb9a14da37a3f2a05cb80dc65cfd38 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Mon, 5 Dec 2022 14:16:45 -0800
Subject: [PATCH] grep: bug: backref in last of multiple patterns

* NEWS: Mention this.
* src/dfasearch.c (GEAcompile): Trim trailing newline from
the last pattern, even if it has back-references and follows
a pattern that lacks back-references.
* tests/backref: Add test for this bug.
---
 NEWS|  6 ++
 src/dfasearch.c | 25 -
 tests/backref   |  8 
 3 files changed, 26 insertions(+), 13 deletions(-)

diff --git a/NEWS b/NEWS
index da293a3..6c00b2b 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,12 @@ GNU grep NEWS-*- outline -*-
 
 * Noteworthy changes in release ?.? (-??-??) [?]
 
+** Bug fixes
+
+  When given multiple patterns the last of which has a back-reference,
+  grep no longer sometimes mistakenly matches lines in some cases.
+  [Bug#36148#13 introduced in grep 3.4]
+
 
 * Noteworthy changes in release 3.8 (2022-09-02) [stable]
 
diff --git a/src/dfasearch.c b/src/dfasearch.c
index a71902a..a5b0d90 100644
--- a/src/dfasearch.c
+++ b/src/dfasearch.c
@@ -281,20 +281,19 @@ GEAcompile (char *pattern, idx_t size, reg_syntax_t syntax_bits,
   if (compilation_failed)
 exit (EXIT_TROUBLE);
 
-  if (prev <= patlim)
+  if (patlim < prev)
+buflen--;
+  else if (pattern < prev)
 {
-  if (pattern < prev)
-{
-  idx_t prevlen = patlim - prev;
-  buf = xirealloc (buf, buflen + prevlen);
-  memcpy (buf + buflen, prev, prevlen);
-  buflen += prevlen;
-}
-  else
-{
-  buf = pattern;
-  buflen = size;
-}
+  idx_t prevlen = patlim - prev;
+  buf = xirealloc (buf, buflen + prevlen);
+  memcpy (buf + buflen, prev, prevlen);
+  buflen += prevlen;
+}
+  else
+{
+  buf = pattern;
+  buflen = size;
 }
 
   /* In the match_words and match_lines cases, we use a different pattern
diff --git a/tests/backref b/tests/backref
index 510e130..97cb157 100755
--- a/tests/backref
+++ b/tests/backref
@@ -43,4 +43,12 @@ if test $? -ne 2 ; then
 failures=1
 fi
 
+# https://bugs.gnu.org/36148#13
+echo 'Total failed: 2 (1 ignored)' |
+grep -e '^Total failed: 0$' -e '^Total failed: \([0-9]*\) (\1 ignored)$'
+if test $? -ne 1 ; then
+echo "Backref: Multiple -e test, test #5 failed"
+failures=1
+fi
+
 Exit $failures
-- 
2.38.1

Bug#1025502: dak: `dak rm -b ${package}` does not work if source of ${package} already gone

[Ansgar]

Package: ftp.debian.org

`dak rm -b ${package}` or other variants do not when when `${package}`'s
source is already removed. This happened with lostirc (bug #1024341).

The cause is likely the SQL queries in dak/rm.py that include

+---
| JOIN newest_source on s.source = newest_source.source AND su.id = 
newest_source.suite
+---[ dak/rm.py ]

which then results in an empty set if `${package}`'s source is no longer
in the suite.

Ansgar

Bug#1025492: openjdk-17: Upstream commit f71b21b causes segfault in hdf5 java test suite on arches i386 and mips64el

[Gilles Filippini]

On Mon, 05 Dec 2022 20:19:37 +0100 Gilles Filippini  wrote:

Package: openjdk-17
Version: 17~14-1
Severity: serious
Tags: upstream
Justification: makes unrelated software on the system break

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

A few weeks ago default-jdk was switched from openjdk-11 to openjdk-17.
Afterward hdf5 has been suffering FTBFS on arches i386 [1] and mips64el [2]
caused by a segfault in one of its java test case:

junit.sh: line 926: 3107321 Aborted ( $RUNSERIAL $JAVAEXE 
$JAVAEXEFLAGS -Xmx1024M -Dorg.slf4j.simpleLogger.defaultLog=trace 
-Djava.library.path=$BLDLIBDIR -cp $CLASSPATH -ea org.junit.runner.JUnitCore 
test.TestH5Arw > JUnit-TestH5Arw.ext )
**FAILED**JUnit-TestH5Arw
Expected result differs from actual result
*** JUnit-TestH5Arw.txt 2022-11-26 00:28:33.024585625 +
--- JUnit-TestH5Arw.out 2022-11-26 00:28:42.316468486 +
***
*** 7,13 
  .testH5Aread_32bit_floats
  .testH5Aread_16bit_ints
  
! Time:  
! 
! OK (7 tests)
! 
--- 7,27 

  .testH5Aread_32bit_floats
  .testH5Aread_16bit_ints
  
! #

! # A fatal error has been detected by the Java Runtime Environment:
! #
! #  SIGSEGV (0xb) at pc=0xf74070c5, pid=3107321, tid=3107322
! #
! # JRE version: OpenJDK Runtime Environment (version (number)) (build 
17.0.5+8-Debian-2)
! # Java VM: OpenJDK Server VM (version (number))
! # Problematic frame:
! # V  [libjvm.so+0x65e0c5]
! #
! # No core dump will be written. Core dumps have been disabled. To enable core 
dumping, try "ulimit -c unlimited" before starting Java again
! #
! # An error report file with more information is saved as:
! # /<>/hdf5-version (number)
! #
! # If you would like to submit a bug report, please visit:
! #   https://bugs.debian.org/openjdk-17
! #

[1] 
https://buildd.debian.org/status/fetch.php?pkg=hdf5=i386=1.10.8%2Brepack-3=1669422533=0
[2] 
https://buildd.debian.org/status/fetch.php?pkg=hdf5=mips64el=1.10.8%2Brepack-3=1669424344=0


Please find attached the related java error report file.

Best,
_g.


hs_err_pid59953.log.gz
Description: application/gzip


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025433: [Emc-developers] Bug#1025433: Bug#1025433: Copyright issue

[Alec Ari]

Both of these files are different, all authors are arguably correct. Paolo 
doesn't work on LinuxCNC, he didn't write the one in LinuxCNC. The LinuxCNC one 
is based off other work, and Paolo's as well.

My vote is on not a bug, not an issue.

Alec





On Monday, December 5, 2022 at 08:37:28 AM CST, andy pugh  
wrote: 





On Mon, 5 Dec 2022 at 14:14, Adam Ant  wrote:

> Source: linuxcnc
>
> src/rtapi/procfs_macros.h incorrectly attributes copyright.
>
> The original file can be found here:
>
> http://svn.savannah.gnu.org/viewvc/rtai/magma/base/include/rtai_proc_fs.h?view=markup


At what point does a file become a new file? The file in LinuxCNC appears
to be a sub-set of an original file contributed to RTAI by Erwin Roll.

So who would be the correct copyright holder?  It is possibly not Paulo
either,

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is designed
for the especial use of mechanical geniuses, daredevils and lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-developers mailing list
emc-develop...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Bug#1025501: pvm: Uninstallable in sid when openssh-client is installed

[Rafael Laboissière]

Package: pvm
Version: 3.4.6-3.2
Severity: serious

Dear Maintainer,

The pvm package is currently installable in sid when openssh-client is 
installed and there is no other package providing rsh-client:

  # apt install pvm
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  pvm is already the newest version (3.4.6-3.2+b1).
  pvm set to manually installed.
  0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
  2 not fully installed or removed.
  After this operation, 0 B of additional disk space will be used.
  Do you want to continue? [Y/n]
  Setting up pvm (3.4.6-3.2+b1) ...
  update-alternatives: error: alternative path /usr/bin/rsh doesn't exist
  dpkg: error processing package pvm (--configure):
   installed pvm package post-installation script subprocess returned error 
exit status 2
  dpkg: dependency problems prevent configuration of pvm-dev:
   pvm-dev depends on pvm; however:
Package pvm is not configured yet.

This is caused by a recent change in openssh-client:

  openssh (1:9.1p1-1) unstable; urgency=medium
[...]
* Remove obsolete and misleading rcp/rlogin/rsh alternatives, and stop
  providing rsh-client (closes: #197037).

A simple fix for this issue is changing the Depends field from:

  openssh-client | rsh-client

to:

  rsh-client

Best,

Rafael

-- System Information: 
Debian Release: bullseye/sid 
  APT prefers testing 
  APT policy: (650, 'testing'), (600, 'unstable') 
Architecture: amd64 (x86_64)

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

Versions of packages pvm depends on: 
ii  libc62.36-6 
pn  libpvm3   
ii  openssh-client [rsh-client]  1:9.1p1-1

pvm recommends no packages.

pvm suggests no packages.

Bug#1025485: pybuild-plugin-pyproject: pyproject plugin installs data_files in wrong place

[Stefano Rivera]

Hi Marcin (2022.12.05_12:40:17_-0400)
> TL;DR: plugin_pyproject.py installs files listed under
> [options.data_files] (such as manpages) in an unexpected place,
> different than pip would have.

Yeah, that's because we never got around to making a test case to see if
we were doing the right thing or not.

I think I've fixed that in 
https://salsa.debian.org/python-team/tools/dh-python/-/commit/afbc167a10c024ce4890a9d520e6a3ba513494f1

I'll need to do some verification that that doesn't break other
packages. And ideally add some test cases for other build systems.

Note that setuptools deprecated [options.data_files] because it doesn't
work correctly with wheels. But we can do our best to make it work as
much as possible.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1025500: libvpl-dev: Shouldn't libvpl-dev depends on its library libvp2.

[Alban Browaeys]

Package: libvpl-dev
Version: 2022.2.4-1
Severity: important

Dear Maintainer,
If I install libvp-dev and rebuild handbrake with --enable-qsv the build
fails. I have to also install libvp2 by hand (and will have to add both
to the build-depends to submit a patch if so).

All other -dev packages in Debian that I lloked at depends on their
library pacakge but not yours. From a google search, I have not found
the Debian policy requirement for that though.
Note that other pacakges depends on hte exact same versoin of the
libaray and dev package. Probably vi a dh helper.

The expected outcome is that with adding libvpx-dev to the build depends
of handbrake would be enough for it to build and run against libvp2 too
without having to hardcode this dependency.

Cheers,
Alban

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

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

-- no debconf information

Bug#433326: RFA: cbedic -- Text-mode Bulgarian/English Dictionary

[Bastian Germann]

On Mon, 16 Jul 2007 13:35:00 +0300 Anton Zinoviev  wrote:

Package: wnpp
Severity: normal

I suppose whoever maintains kbedic and/or its succesor should maintain
also cbedic and/or its successor.  So I am requesting an adopter for
the cbedic package.


kbedic was removed from the archive. Should cbedic also be removed?

Bug#1023545: systemd --user and sd-pam processes keep running after logout (again)

[Michael Biebl]

On Sun, 06 Nov 2022 14:37:39 +0100 =?utf-8?q?Patrick_H=C3=A4cker?= 
 wrote:

Package: systemd
Version: 252-2
Severity: normal

Dear Maintainer,

similar to #749268 there seems to be again the problem, that when logging
out, the systemd user process and sd-pam are not killed.

Take, e.g., this example:
# loginctl kill-session 34

# pgrep -a -u pat
11499 /lib/systemd/systemd --user
11500 (sd-pam)

# loginctl list-sessions
SESSION UID USER SEAT  TTY
 13   0 root seat0 tty2
 21   0 root seat0 tty2
 25   0 root seat0 tty2
 33   0 root seat0 tty2
 36   0 root seat0 tty2
 37 121 sddm seat0

6 sessions listed.

So although there is no logind session left, there are still the two user
processes around.

I added
KillUserProcesses=yes
but that did not help (is this an additional bug?).

Do I miss anything in order to kill the systemd user process automatically?



It looks like
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023545
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024080
might be duplicates.

If you think this is a regression in 252 and you can provide a way how 
this can be reproduced, my advice would be to file this upstream at


https://github.com/systemd/systemd/issues/



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025062: systemd-resolved Provides: resolvconf, but is missing the isc-dhcp-client integration from resolvconf

[Michael Biebl]

Control: reassign -1 isc-dhcp-client

On Mon, 28 Nov 2022 10:24:55 +0100 Helmut Grohne  wrote:

Package: systemd-resolved,isc-dhcp-client

Hi,

When systemd-resolved started replacing and providing resolvconf, things
looked good, but isc-dhcp-client no longer propagates DNS servers to
resolved. This used to work when resolvconf and systemd-resolved were
coinstallable and one used resolvectl to implement resolvconf. The crux
is that resolvconf contains the integration scripts that make
isc-dhcp-client run resolvconf even when resolvconf is provided by
systemd-resolved. Now that systemd-resolved conflicts with resolvconf,
it broke that integration, which is bad.

I briefly talked to Michael about this and he figured that we wouldn't
want to go through the extra resolvconf layer and rather do things
directly. Indeed, this is what has happened for ifupdown already.
ifupdown now contains /etc/network/if-*.d/resolved and integrates
directly. NetworkManager does it directly likewise. isc-dhcp-client
should likely do it as well.

Thus I think a good solution to this bug would be:
 * isc-dhcp-client ships scripts to directly integrate with resolved.
 * systemd-resolved Breaks isc-dhcp-client in versions that don't
   integrate.


It would be preferable if isc-dhcp-client ships the resolved integration 
bits.
The Debian package could steal from the Ubuntu package which appears to 
have some corresponding hooks:


# apt-file list isc-dhcp-client | grep resolved
isc-dhcp-client: /etc/dhcp/dhclient-enter-hooks.d/resolved-enter
isc-dhcp-client: /etc/dhcp/dhclient-exit-hooks.d/resolved

[Note: I did not have a look at those hook scripts at all]

I don't think we need a Breaks here.

With that said, I'm going to reassign this bug to isc-dhcp-client.

Regards,
Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003002: some more information - possible solution

[Maximilian Engelhardt]

On Sonntag, 4. Dezember 2022 01:42:14 CET Christian Kastner wrote:
> Can anyone else give this patch a try before I submit an MR?

Uh, this is great news and an easy fix.

I did some tests and can confirm that your patch fixes this problem for me.



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

Bug#1025499: ITP: libsuccinct -- succinct C++ data structures

[Federico Ceratto]

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

* Package name: libsuccinct
  Version : 0.20221205
  Upstream Author : Giuseppe Ottaviano 
* URL : https://github.com/ot/succinct
* License : Apache-2.0
  Programming Lang: C++
  Description : succinct C++ data structures

Succinct data structures used by various projects.

Required as a dependency for Organic Maps

Team-maintained at https://salsa.debian.org/debian/succinct

Bug#931591: Buster: upgraded Handbrake crashes on encode with custom preset

[Alban Browaeys]

On Wed, 14 Aug 2019 16:38:13 -0700 Seth Foley
 wrote:
> Installed gdb, updated sources, installed the two debug symbol
packages, 
> and ran those commands. (I had not rebooted since the crash on
Tuesday.)
> 
> The output of coredumpctl is attached.
> 
> I also copied the core dump file in case it's wanted later.
> 
> Thanks, --SF

Do you by any change know the path name to this external (5 TB) disk ?
It is probably /media// so the output of "lsblk -f" would do.
Or if you selected a subfolder on this external drive partition the
name of this subfolder.

It could be your system encoding is not UTF-8. "locale" command output
in your user session would help. Though debuggus output your system
locale as en_US.UTF-8 so unlikely. Still this output may give a clue.

I believe that handbrake did not support your destination directory
name (or file name) and thus bailed out and the job ended up with no
filenname set as destination. Thus the crash in ffmpeg code.

Or maybe the external drive partition was read only due to an hardware
issue, and handbrake bailed out due to that.


Also the bug may be already fixed (hard to tell without a reproducer),
if you still have the setup could you retry (you can downgrade
handbrake by installing a downloaded buster deb package
at https://packages.debian.org/buster/handbrake then clock on your
architecture). handbrake should not allow a job with a Destination
structure without a File field.


Still it would help a lot to find with which destination folder name it
fails.
Maybe it could get sorted out by reading the source but it will take a
certain amount of time.



my encode log shows a "File" field in the "Destination" structure.
Yours not. It may be why the gdb trace shows a filename=0x0 (ie no
filename) passed to ffmpeg avio_open2.

Mine:

"Destination": {
"AlignAVStart": false,
"ChapterList": [
{
"Name": "Chapter 1"
},
{
"Name": "Chapter 2"
},
{
"Name": "Chapter 3"
}],
"ChapterMarkers": true,
"File": "/media/prahal/4061-08F6/output_file.mkv",
"InlineParameterSets": false,
"Mp4Options": {
"IpodAtom": false,
"Mp4Optimize": false
},
"Mux": "mkv"
},

Yours:
  "Destination": {
"AlignAVStart": false,
"ChapterList": [
{
"Name": "Chapter 1"
},
{
"Name": "Chapter 2"
},
{
"Name": "Chapter 3"
},
{
"Name": "Chapter 4"
},
{
"Name": "Chapter 5"
},
{
"Name": "Chapter 6"
}
],
"ChapterMarkers": true,
"InlineParameterSets": false,
"Mp4Options": {
"IpodAtom": false,
"Mp4Optimize": false
},
"Mux": "mkv"
},




You gdb shows a 0x0 (null) filename passed to the ffmpeg library, which
is likely not supported by this library call, thus that points to an
handbrake bug:
#2  0x7f7cebc48102 in ffurl_alloc
(puc=0x7f7cd67fa820, filename=0x0, flags=2, int_cb=0x7f7cc19b8708)
at src/libavformat/avio.c:295
#3  0x7f7cebc48a2e in ffurl_open_whitelist
(puc=puc@entry=0x7f7cd67fa820, filename=,
flags=flags@entry=2, int_cb=, options=options@entry=0x0,
whitelist=whitelist@entry=0x0, blacklist=0x0, parent=0x0) at
src/libavformat/avio.c:314
#4  0x7f7cebc4d187 in ffio_open_whitelist
(s=0x7f7cc19b8260, filename=, flags=flags@entry=2,
int_cb=, options=options@entry=0x0,
whitelist=whitelist@entry=0x0, blacklist=0x0)
at src/libavformat/aviobuf.c:1167
#5  0x7f7cebc4d1ee in avio_open2
(s=, filename=, flags=flags@entry=2,
int_cb=, options=options@entry=0x0) at
src/libavformat/aviobuf.c:1181
#6  0x561ecd32d8fd in avformatInit (m=0x7f7cc19b7870) at
../libhb/muxavformat.c:179
#7  0x561ecd2e4112 in muxInit (muxer=0x7f7cc03ea500,
job=0x7f7cc004a340)
at ../libhb/muxcommon.c:649
#8  0x561ecd317e56 in do_job (job=0x7f7cc004a340) at
../libhb/work.c:1758

You also have in your encode.log
[19:00:07]  * destination
[19:00:07]+ (null)
[19:00:07]+ container: Matroska (libavformat)
[19:00:07]  + chapter markers

while here I have:
[21:46:17]  * destination
[21:46:17]+ /media/prahal/4061-08F6/output_file.mkv
[21:46:17]+ container: Matroska (libavformat)
[21:46:17]  + chapter markers


Note that my encode job output is via handbrake 1.2.2+ds1-1 with its
dependencies mostly downgraded to buster versions. And I cannot
reproduce with by selecting an usb drive with no label but UUID 4061-
08F6 for its partition as handbrake "destination".

Cheers,
Alban

Bug#1019147: [systemd-devel] systemd-container: Trying to use a bookworm chroot with a buster host fails / Failed to create /init.scope control group

[Michael Biebl]

Hi Bernhard

Am 05.12.22 um 18:31 schrieb Bernhard Übelacker:



Am 03.12.22 um 23:38 schrieb Bernhard Übelacker:


I thought if strace can observe the process in question, would gdb also
be able. And found starting nspawn with gdbserver, 'set 
follow-fork-mode child'

and gdb from inside the container via plain chroot seems working well.

So it looks like the failing "syscall_0x1b7" from strace is 
"faccessat2" [2].


And it seems "faccessat2" got added just in kernel 5.8 [3],
therefore it might fail with the kernel 4.19.
So I fear this needs a newer kernel, and/or this is more a glibc issue 
then?




Hello,
just a few short additions.
I was looking further into this issue, and found disabling apparmor
by booting the host with "apparmor=0" did not improve the situation.


Then I found following entry in the systemd debian package changelog 
[1][2]:


    * seccomp: allow turning off of seccomp filtering via env var.
  Since glibc 2.33 faccessat() is implemented via faccessat2(), which
  is breaking running containers that use such a version of glibc under
  systemd-nspawn in Buster.
  Turning off seccomp filtering via the SYSTEMD_SECCOMP env var 
makes it

  possible to run such new containers. (Closes: #984573)


This fits perfectly the situation and the container starts
successfully with this workaround:

     SYSTEMD_SECCOMP=0 systemd-nspawn 
--directory=/var/lib/machines/test-bookworm --boot


Thanks for the update!
I guess this means we can close the bug report?

Regards,
Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1013662: core-async-clojure: FTBFS randomly in bullseye

[Jérôme Charaoui]

On Mon, 5 Dec 2022 22:04:06 +0100 Santiago Vila  wrote:

Hi.

I attach an upload proposal for bullseye, in debdiff format against 
version 1.3.610-4 (stable version), so you can upload it "as is" if 
everything else is ok.


There is a stable point release around the corner, it would be wonderful 
if this could be fixed by then.



I'm not opposed to uploading it but I'm curious to know why this is 
needed now, because the next stable release is also "around the corner", 
in relative terms...


Thanks,

-- Jerome

Bug#1021391: Possible solution with kernel 6.0.11

[Salvatore Bonaccorso]

Hi Bernhard,

On Mon, Dec 05, 2022 at 12:21:48PM +, Bernhard wrote:
> Hello Salvatore
> 
> It is possible, that kernel 6.0.11 solves the Bug #1021391 because of
> 
> >>>
> - [arm64,armhf] bus: sunxi-rsb: Remove the shutdown callback
> - [arm64,armhf] bus: sunxi-rsb: Support atomic transfers
> <<<
> 
> If i have a look at the ARM kernel mailinglist, there are bugfixes for this 
> I2C:
> 
> >>>
> Shutting down the RSB controller prevents communicating with a PMIC
> inside pm_power_off(), so it breaks system poweroff on some boards.
> <<<
> 
> >>>
> This series fixes a couple of issues that occur when powering off a
> board using a PMIC attached to the RSB bus.
> 
> These issues only affected 32-bit platforms, because 64-bit platforms
> use PSCI for pm_power_off(), and the PSCI firmware reinitializes the
> RSB controller.
> <<<
> 
> >>>
> When communicating with a PMIC during system poweroff (pm_power_off()),
> IRQs are disabled and we are in a RCU read-side critical section, so we
> cannot use wait_for_completion_io_timeout(). Instead, poll the status
> register for transfer completion.
> <<<
> 
> Is it planned, to release this kernel in the next days?
> I'm really very interested in testing.

I was pondering it actually, and the changes are waiting in the sid
branch, but wanted to include the changes of upcoming 6.0.12 as well
in the next update.

Regards,
Salvatore

Bug#1013662: core-async-clojure: FTBFS randomly in bullseye

[Santiago Vila]

Hi.

I attach an upload proposal for bullseye, in debdiff format against 
version 1.3.610-4 (stable version), so you can upload it "as is" if 
everything else is ok.


There is a stable point release around the corner, it would be wonderful 
if this could be fixed by then.


Thanks.diff -Nru core-async-clojure-1.3.610/debian/changelog 
core-async-clojure-1.3.610/debian/changelog
--- core-async-clojure-1.3.610/debian/changelog 2020-12-15 21:19:54.0 
+0100
+++ core-async-clojure-1.3.610/debian/changelog 2022-12-05 21:36:00.0 
+0100
@@ -1,3 +1,10 @@
+core-async-clojure (1.3.610-4+deb11u1) bullseye; urgency=medium
+
+  * Team upload.
+  * Skip test assertions which hang in single-cpu env (Closes: #1013662).
+
+ -- Jérôme Charaoui   Mon, 05 Dec 2022 21:36:00 +0100
+
 core-async-clojure (1.3.610-4) unstable; urgency=medium
 
   * Team upload.
diff -Nru 
core-async-clojure-1.3.610/debian/patches/0003-Skip-test-assertions-which-hang-in-single-cpu-env.patch
 
core-async-clojure-1.3.610/debian/patches/0003-Skip-test-assertions-which-hang-in-single-cpu-env.patch
--- 
core-async-clojure-1.3.610/debian/patches/0003-Skip-test-assertions-which-hang-in-single-cpu-env.patch
  1970-01-01 01:00:00.0 +0100
+++ 
core-async-clojure-1.3.610/debian/patches/0003-Skip-test-assertions-which-hang-in-single-cpu-env.patch
  2022-12-05 21:35:30.0 +0100
@@ -0,0 +1,39 @@
+From: =?utf-8?b?SsOpcsO0bWUgQ2hhcmFvdWk=?= 
+Date: Tue, 5 Jul 2022 17:56:14 -0400
+Subject: Skip test assertions which hang in single-cpu env
+
+This part hangs indefinitely (possible deadlock) when running on a
+single-cpu system, or as a part of a single-cpu bound cgroup.
+
+Forwarded: no
+---
+ src/test/clojure/clojure/core/async_test.clj | 18 +-
+ 1 file changed, 1 insertion(+), 17 deletions(-)
+
+--- a/src/test/clojure/clojure/core/async_test.clj
 b/src/test/clojure/clojure/core/async_test.clj
+@@ -288,23 +288,7 @@
+   (is (= [0 1 2 3]
+  (

Bug#972146: /usr/share/applications/mono-runtime-common.desktop: should not handle MIME type by executing arbitrary code

[Gabriel Corona]

As a workaround, you should be able to disable this feature (and have 
the fix persist after a package update) with something like:


mkdir -p /usr/local/share/applications
cp /usr/share/applications/mono-runtime-*.desktop 
/usr/local/share/applications
sed -i 's/^Exec=.*/Exec=false/' 
/usr/local/share/applications/mono-runtime-*.desktop


Regards,

Gabriel

Bug#1025498: Links to old libavdevice58

[martin f krafft]

Package: scrcpy
Version: 1.24-1
Severity: grave

The package depends on libavdevice59, but it's apparently built 
against libavdevice58:

lotus:~% ldd =scrcpy | grep libavdevice
  libavdevice.so.58 => not found

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

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

Versions of packages scrcpy depends on:
ii  libavcodec59   7:5.1.2-1
ii  libavdevice59  7:5.1.2-1
ii  libavformat59  7:5.1.2-1
ii  libavutil577:5.1.2-1
ii  libc6  2.36-6
ii  libsdl2-2.0-0  2.26.0+dfsg-1
ii  libusb-1.0-0   2:1.0.26-1
ii  scrcpy-server  1.24-1

Versions of packages scrcpy recommends:
ii  adb  1:29.0.6-21

scrcpy suggests no packages.

-- no debconf information


-- 
 .''`.   martin f. krafft 
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems

Bug#1025308: gsequencer: FTBFS with fftw3 (3.3.10-1)

[Sebastian Ramacher]

On 2022-12-05 21:23:50 +0100, Philip Rinn wrote:
> On 05.12.22 at 17:26, Sebastiaan Couwenberg wrote:
> > On 12/5/22 16:51, Philip Rinn wrote:
> > > thanks for fixing gsequencer! Did you actually upload the NMU, I
> > > don't see it in the queue. If not, could you please upload DELAYED/5
> > > as per
> > > https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu
> > > so fftw3 can migrate?
> > 
> > Earlier today I contacted Joël Krähemann to ask if he has time to upload
> > a new revision of gsequencer. There is no need for an NMU if he does.
> 
> Fair enough, up to you of course. I just don't see why not uploading the NMU
> now - it seems, you already did all/most work needed anyway - and if Joël
> has a new version ready earlier than DELAYED/5 his upload will end up in the
> archive.
> 
> What I see is that this is currently blocking fftw3 migration which in turn
> blocks quite many packages (soon) - with the freeze not that far away, I
> just don't like these easily preventable delays.

If that was a concern, maybe those bugs should have been filed before
changing this in fftw3. In any case, the bug was filed three days ago.
That's too early to NMU. Please have some patience.

Cheers

> 
> Thanks for your work & best regards
> 
> Philip




-- 
Sebastian Ramacher

Bug#1025308: gsequencer: FTBFS with fftw3 (3.3.10-1)

[Philip Rinn]

On 05.12.22 at 17:26, Sebastiaan Couwenberg wrote:

On 12/5/22 16:51, Philip Rinn wrote:
thanks for fixing gsequencer! Did you actually upload the NMU, I don't see it 
in the queue. If not, could you please upload DELAYED/5 as per 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu so fftw3 
can migrate?


Earlier today I contacted Joël Krähemann to ask if he has time to upload a new 
revision of gsequencer. There is no need for an NMU if he does.


Fair enough, up to you of course. I just don't see why not uploading the NMU now 
- it seems, you already did all/most work needed anyway - and if Joël has a new 
version ready earlier than DELAYED/5 his upload will end up in the archive.


What I see is that this is currently blocking fftw3 migration which in turn 
blocks quite many packages (soon) - with the freeze not that far away, I just 
don't like these easily preventable delays.


Thanks for your work & best regards

Philip


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025497: python3-apt: cache update throws exception when some repositories are unreachable while apt update returns 0

[matlink]

Package: python3-apt
Version: 2.2.1
Severity: important
X-Debbugs-Cc: matl...@matlink.fr




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

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

Versions of packages python3-apt depends on:
ii  distro-info-data   0.51+deb11u2
ii  libapt-pkg6.0  2.2.4
ii  libc6  2.31-13+deb11u4
ii  libgcc-s1  10.2.1-6
ii  libstdc++6 10.2.1-6
ii  python-apt-common  2.2.1
ii  python33.9.2-3

Versions of packages python3-apt recommends:
ii  iso-codes4.6.0-1
ii  lsb-release  11.1.0

Versions of packages python3-apt suggests:
ii  apt  2.2.4
pn  python-apt-doc   
pn  python3-apt-dbg  

-- no debconf information

When some debian repositories are unreachable, python3-apt update cache 
functionality throws an unknown exception 'Failed to update apt cache: unknown 
reason'. This is hardly catchable. However, apt update returns exit code 0 in 
the same situation. Behaviors diverge which causes issues for higher level 
programs like ansible.

Bug#974768: handbrake: Saving custom presets in custom category is broken

[Alban Browaeys]

You can close this bug report as I can reproduce when I installed
stretch handbrake_1.2.2+ds1-1_amd64.deb with its required dependencies
from strech (libdvdread4_6.0.1-1, libx265-165_2.9-4, libx264-
155_0.155.2917+git0a84d98-2).
This even with bookworm libgtk-3-0 3.24.35-2 and all other dependencies
untouched.

And with only change being upgrading handbrake 1.5.1+ds1-3
(bookworm and sid) and handbrake 1.3.1+ds1-2+b3 (bullseye stable) the
issue is fixed.

Best Regards,
Alban

Bug#1025496: RFS: cheat/4.4.0+ds1-1 [ITP]-- Create and view interactive cheatsheets

[Stanislas Marquis]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : cheat
   Version  : 4.4.0+ds1-1
   Upstream contact : Christopher Allen Lane 
 * URL  : https://github.com/cheat/cheat
 * License  : Expat
 * Vcs  : https://salsa.debian.org/go-team/packages/cheat
   Section  : golang

The source builds the following binary packages:

  cheat - Create and view interactive cheatsheets

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/cheat/cheat_4.4.0+ds1-1.dsc

Changes for the initial release:

 cheat (4.4.0+ds1-1) unstable; urgency=medium
 .
   * Initial release (Closes: #1020744)
   * New upstream version 4.4.0+ds1

Regards,
-- 

  Stanislas Marquis

signature.asc
Description: OpenPGP digital signature

Bug#974768: handbrake: Saving custom presets in custom category is broken

[Alban Browaeys]

package handbrake
fixed 974768 1.3.1+ds1-2+b3
thanks


On Sat, 14 Nov 2020 21:38:27 +0100 =?utf-8?q?Johan_Kr=C3=B6ckel?=
 wrote:
> Package: handbrake
> Version: 1.2.2+ds1-1
> Severity: normal
> 
> Creating a custom preset category in the GUI is not possible. Saving
a new preset with the option "new category" enabled fails silently.


This issue is not reproducible here with handbrake 1.5.1+ds1-3
(bookworm and sid) and bullseye (stable) 1.3.1+ds1-2+b3.

I set a preset category name by clicking on hte "presets" menu entry
then its "save as" submenu entry, then in the category dropdown I
select "Add New Category" and enter "test" as name in the category name
input entry, then click OK and my preset is then available i the
presets drowdown under the "Custom" section.


Could you try anew and close the issue ?
Maybe this issue was unrelated to handbrake itself as my gtk3 GUI
framework is newer than stable. I have bookworm libgtk-3-0 3.24.35-2.

I set the issue as fixed in (at least) 1.3.1+ds1-2+b3 but if it is not
an handbrake bug per se it will require reopening and reassigning.

Cheers,
Alban

Bug#1025495: procps: FTBFS on s390x: test failure

[Sebastian Ramacher]

Source: procps
Version: 2:4.0.2-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=procps=s390x=2%3A4.0.2-1=1670241081=0

.. contents:: :depth: 2

FAIL: library/tests/test_pids
=

PASS: procps_pids_new() info=NULL returns -EINVAL
PASS: procps_pids new then unref
FAIL: check_fatal_proc_unmounted
FAIL library/tests/test_pids (exit status: 1)


Testsuite summary for procps-ng 4.0.2

# TOTAL: 7
# PASS:  6
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See ./test-suite.log
Please report to pro...@freelists.org

make[5]: *** [Makefile:2171: test-suite.log] Error 1
make[5]: Leaving directory '/<>'
make[4]: *** [Makefile:2279: check-TESTS] Error 2
make[4]: Leaving directory '/<>'
make[3]: *** [Makefile:2560: check-am] Error 2
make[3]: Leaving directory '/<>'
make[2]: *** [Makefile:2056: check-recursive] Error 1
make[2]: Leaving directory '/<>'
make[1]: *** [Makefile:2562: check] Error 2
make[1]: Leaving directory '/<>'
dh_auto_test: error: make -j2 check "TESTSUITEFLAGS=-j2 --verbose" VERBOSE=1 
returned exit code 2
make: *** [debian/rules:24: build-arch] Error 25


Cheers
-- 
Sebastian Ramacher

Bug#1025494: librust-lazy-regex-dev: Move proc-macro code into seperate package

[matthias . geiger1024]

 Also, IMHO proc-macro code should always go into a separate package.

---

Matthias

Bug#1025494: librust-lazy-regex-dev: Move proc-macro code into seperate package

[matthias . geiger1024]

Package: librust-lazy-regex-dev
X-Debbugs-Cc: 
Severity: important

Hi Jonas,

please move the lazy-regex-proc-macro code into a seperate package. The current 
state causes lfs-core to fail building:

debian cargo wrapper: options, profiles, parallel: ['parallel=6'] [] ['-j6']
debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu, 
x86_64-linux-gnu
debian cargo wrapper: running subprocess (['env', 'RUST_BACKTRACE=1', 
'/usr/bin/cargo', '-Zavoid-dev-deps', 'test', '--verbose', '--verbose', '-j6', 
'--target', 'x86_64-unknown-linux-gnu', '--all'],) {}
error: no matching package named `lazy-regex-proc_macros` found
location searched: registry `crates-io`
required by package `lazy-regex v2.3.1`
    ... which satisfies dependency `lazy-regex = "^2.2"` of package `lfs-core 
v0.11.0 (/<>)`
dh_auto_test: error: /usr/share/cargo/bin/cargo test --all returned exit code 
101
make[1]: *** [debian/rules:6: override_dh_auto_test] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:3: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

I'd appreciate it.

Cheers

Matthias

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

Kernel: Linux 6.0.9-surface (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages librust-lazy-regex-dev depends on:
pn  librust-once-cell-1+default-dev  
pn  librust-regex-1+default-dev  
pn  librust-regex-1+perf-cache-dev   
pn  librust-regex-1+perf-dev 
pn  librust-regex-1+perf-dfa-dev 
pn  librust-regex-1+perf-inline-dev  
pn  librust-regex-1+perf-literal-dev 
pn  librust-regex-1+std-dev  
pn  librust-regex-1+unicode-age-dev  
pn  librust-regex-1+unicode-bool-dev 
pn  librust-regex-1+unicode-case-dev 
pn  librust-regex-1+unicode-dev  
pn  librust-regex-1+unicode-gencat-dev   
pn  librust-regex-1+unicode-perl-dev 
pn  librust-regex-1+unicode-script-dev   
pn  librust-regex-1+unicode-segment-dev  

librust-lazy-regex-dev recommends no packages.

librust-lazy-regex-dev suggests no packages.
 

Bug#1023764: Bug 1023764

[Brian Haley]

It looks like the problem is that networking-l2gw is requiring a version 
of neutron that doesn't have this method. I've pushed a change that 
might solve the issue:


https://review.opendev.org/c/x/networking-l2gw/+/866620

Unless it's easier to just dump this in a package file?

Bug#1025493: firefox crashes instantly at start

[VA]

Package: firefox
Version: 107.0.1-1
Severity: important

It's not a broken profile, even when running "firefox --ProfileManager" 
or "firefox --safe-mode":


[GFX1-]: glxtest: VA-API test failed: failed to initialise VAAPI connection.
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
ExceptionHandler::GenerateDump cloned child 231737
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...

Bug#1025492: openjdk-17: Upstream commit f71b21b causes segfault in hdf5 java test suite on arches i386 and mips64el

[Gilles Filippini]

Package: openjdk-17
Version: 17~14-1
Severity: serious
Tags: upstream
Justification: makes unrelated software on the system break

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

A few weeks ago default-jdk was switched from openjdk-11 to openjdk-17.
Afterward hdf5 has been suffering FTBFS on arches i386 [1] and mips64el [2]
caused by a segfault in one of its java test case:

junit.sh: line 926: 3107321 Aborted ( $RUNSERIAL $JAVAEXE 
$JAVAEXEFLAGS -Xmx1024M -Dorg.slf4j.simpleLogger.defaultLog=trace 
-Djava.library.path=$BLDLIBDIR -cp $CLASSPATH -ea org.junit.runner.JUnitCore 
test.TestH5Arw > JUnit-TestH5Arw.ext )
**FAILED**JUnit-TestH5Arw
Expected result differs from actual result
*** JUnit-TestH5Arw.txt 2022-11-26 00:28:33.024585625 +
--- JUnit-TestH5Arw.out 2022-11-26 00:28:42.316468486 +
***
*** 7,13 
  .testH5Aread_32bit_floats
  .testH5Aread_16bit_ints
  
! Time:  
! 
! OK (7 tests)
! 
--- 7,27 
  .testH5Aread_32bit_floats
  .testH5Aread_16bit_ints
  
! #
! # A fatal error has been detected by the Java Runtime Environment:
! #
! #  SIGSEGV (0xb) at pc=0xf74070c5, pid=3107321, tid=3107322
! #
! # JRE version: OpenJDK Runtime Environment (version (number)) (build 
17.0.5+8-Debian-2)
! # Java VM: OpenJDK Server VM (version (number))
! # Problematic frame:
! # V  [libjvm.so+0x65e0c5]
! #
! # No core dump will be written. Core dumps have been disabled. To enable 
core dumping, try "ulimit -c unlimited" before starting Java again
! #
! # An error report file with more information is saved as:
! # /<>/hdf5-version (number)
! #
! # If you would like to submit a bug report, please visit:
! #   https://bugs.debian.org/openjdk-17
! #

[1] 
https://buildd.debian.org/status/fetch.php?pkg=hdf5=i386=1.10.8%2Brepack-3=1669422533=0
[2] 
https://buildd.debian.org/status/fetch.php?pkg=hdf5=mips64el=1.10.8%2Brepack-3=1669424344=0

Thanks to snapshot.debian.or I was able to spot that openjdk-17 17~14-1
was the first release with this issue in Debian.

I then ran a bisect against the openjdk upstream repo and found out that
upstream commit f71b21b [3]  was the culprit. Reverting this commit on
current openjdk-17 source (17.0.5+8-2) makes the hdf5 java test suite
successful.

[3] https://github.com/openjdk/jdk/commit/f71b21b

I don't know what to do from here. Any chance to release openjdk-17 with a patch
reverting the faulty commit?

Setting this bug as serious since it causes an unrelated package to FTBFS.

Thanks,
_g.


- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)

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

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAmOORD8ACgkQ7+hsbH/+
z4MFRQf+LG9hnV03M1QsxDPg7mHeDQBIzQEaBl6jTOjIgnQ0n7qwlxk+hKdhi4pw
5oKrDWN3XxzxpwDcP+PH8/7JBbtp1b6m+xFFTe12fogj3/So7/hsJRoImZFajbO3
VKEeCyV8K1d11T13nJdXXvcFtQ1ergeApI5ClY6JIsT499Lj0r6tTZNvblGXfDMp
qq2MHnNFM4AoRcXY+PGhnYJY4InmvL6Cg/1gUnWul45n63WrFE+R19MnLbnR+rLW
K1XAUDKG0jKxhkbOeZ6B80sYldza+vhuAsilga9Y6I1NludMLzR/91+u9GApBYRd
mUiUpIeWB3X/iwgPCkpS4v9DLvR+qg==
=KzlR
-END PGP SIGNATURE-

Bug#999485: firmware-brcm80211: Please add brcmfmac43456-sdio.* files for wifi support in Raspberry p400

[Diederik de Haas]

Control: retitle -1 Please add brcmfmac43456-sdio.* files as it's not just used 
in RPi devices

On 10 Nov 2022 11:40:06 +0100 Diederik de Haas  wrote:
> On Sat, 9 Apr 2022 17:52:00 -0500 Gunnar Wolf  wrote:
> > Please note I'm currenlty shipping the required files in
> > raspi-firmware -- I believe their right place is in
> > firmware-brcm80211, so please just ping me (or better, raise a bug on
> > raspi-firmware) whent they are added to this package.
> 
> I opened https://bugs.debian.org/1023741 for it.

>From https://bugs.debian.org/1023741:
> I completely agree that firmware-brcm80211 is the right place and
> raspi-firmware is the wrong place as this is about firmware for wifi
> devices which are f.e. also used on Pine64 devices.

Gunnar indicated that he's willing to remove the files from raspi-firmware,
but they still need to be added to firmware-brcm80211, so pretty please?

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

Bug#617296: debian packages of RStudio

[Andreas Tille]

Hi again,

for those who want to contribute to this:  I've setup Salsa-CI[1].  My
last commit will end up in build problem which is caused by the fact
that sqlite3 and pg library are not probably specified in the linker
flags.  It would be great if someone could fix the CmakeLists.txt
files to approach this properly.

I also think that d/copyright needs a review.

Any contributions are welcome

 Andreas.


[1] https://salsa.debian.org/r-pkg-team/rstudio/-/pipelines

-- 
http://fam-tille.de

Bug#1025491: open-vm-tools: FTBFS with grpc 1.51+

[GCS]

Source: open-vm-tools
Version: 12.1.0-2
Severity: important
Usertags: grpc1_51
Tags: ftbfs bookworm sid patch

Hi,

I would like to start the gRPC v1.51 transition real soon. Your
package fails to build with it. I have a simple patch for you which
fixes the problem.
Please be prepared to apply it when time comes.

Thanks,
Laszlo/GCS
diff -Nru open-vm-tools-12.1.0/debian/patches/grpc_1.51.patch open-vm-tools-12.1.0/debian/patches/grpc_1.51.patch
--- open-vm-tools-12.1.0/debian/patches/grpc_1.51.patch	1970-01-01 01:00:00.0 +0100
+++ open-vm-tools-12.1.0/debian/patches/grpc_1.51.patch	2022-12-05 19:10:31.0 +0100
@@ -0,0 +1,19 @@
+Description: additional libraries to link with for gRPC 1.51+
+ Just add libraries to link with.
+Author: Laszlo Boszormenyi (GCS) 
+Forwarded: no
+Last-Update: 2022-12-05
+
+---
+
+--- open-vm-tools-12.1.0.orig/open-vm-tools/services/plugins/containerInfo/Makefile.am
 open-vm-tools-12.1.0/open-vm-tools/services/plugins/containerInfo/Makefile.am
+@@ -63,6 +63,8 @@ libcontainerInfo_la_SOURCES += container
+ libcontainerInfo_la_CPPFLAGS += @GRPC_CPPFLAGS@
+ libcontainerInfo_la_LDFLAGS += -lprotobuf
+ libcontainerInfo_la_LDFLAGS += -lgrpc++
++libcontainerInfo_la_LDFLAGS += -lgpr
++libcontainerInfo_la_LDFLAGS += -labsl_synchronization
+ 
+ tasks.grpc.pb.cc containers.grpc.pb.cc: %.grpc.pb.cc : %.proto %.pb.cc
+ 	$(PROTOC) -I. -I$(GOGO_PROTOPATH) \
diff -Nru open-vm-tools-12.1.0/debian/patches/series open-vm-tools-12.1.0/debian/patches/series
--- open-vm-tools-12.1.0/debian/patches/series	2022-11-14 16:19:10.0 +0100
+++ open-vm-tools-12.1.0/debian/patches/series	2022-12-05 19:10:31.0 +0100
@@ -1,2 +1,3 @@
 use-debian-pam
 debian/scsi-udev-rule
+grpc_1.51.patch

Bug#1025490: fastnetmon: FTBFS with grpc 1.51+

[GCS]

Source: fastnetmon
Version: 1.2.3-2
Severity: important
Usertags: grpc1_51
Tags: ftbfs bookworm sid patch

Hi,

I would like to start the gRPC v1.51 transition real soon. Your
package fails to build with it. I have a simple patch for you which
fixes the problem.
Please be prepared to apply it when time comes.

Thanks,
Laszlo/GCS
diff -Nru fastnetmon-1.2.3/debian/rules fastnetmon-1.2.3/debian/rules
--- fastnetmon-1.2.3/debian/rules	2022-11-09 10:44:07.0 +0100
+++ fastnetmon-1.2.3/debian/rules	2022-12-05 18:31:22.0 +0100
@@ -10,4 +10,4 @@
 	dh $@ --buildsystem=cmake --sourcedirectory=src
 
 override_dh_auto_configure:
-	dh_auto_configure -- -DENABLE_CUSTOM_BOOST_BUILD=FALSE -DDO_NOT_USE_SYSTEM_LIBRARIES_FOR_BUILD=FALSE $(EXTRA_ARGS)
+	dh_auto_configure -- -DENABLE_CUSTOM_BOOST_BUILD=FALSE -DDO_NOT_USE_SYSTEM_LIBRARIES_FOR_BUILD=FALSE -DLINK_WITH_ABSL=TRUE $(EXTRA_ARGS)

Bug#1013330: linux-image-5.18.0-0.bpo.1-arm64: kernel panic in dpaa2_eth_free_tx_fd

[Diederik de Haas]

Control: tag -1 moreinfo

On woensdag 22 juni 2022 00:20:22 CET you wrote:
> Kernel 5.18.3 contains (at least) 2 patches related to dpaa2-eth.
> Kernel 5.18.5-1 (currently in Sid) does contain quite a few fixes vs 5.18.2,
> so it would be useful to verify if that fixes your issue. I don't know when
> or what version becomes available next in Stable Backports though.

Have you been able to test a more recent bpo kernel? If so, what was the 
result? If not, could you (and inform the bug about it)?

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

Bug#1025489: rxvt-unicode: CVE-2022-4170

[Salvatore Bonaccorso]

Source: rxvt-unicode
Version: 9.30-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for rxvt-unicode.

CVE-2022-4170[0]:
| code execution via background OSC

Fortunately in 9.30 the vulnerability is not exploitable, see [1]. I'm
still reporting it in the Debian BTS so we can track the fix upstream
once the patch from [2] lands in unstable.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-4170
https://www.cve.org/CVERecord?id=CVE-2022-4170
[1] https://www.openwall.com/lists/oss-security/2022/12/05/1
[2] 
http://cvs.schmorp.de/rxvt-unicode/src/perl/background?r1=1.105=1.109=patch

Regards,
Salvatore

Bug#1013180: System doesn't go to sleep in 5.18.0-1 kernel

[Diederik de Haas]

Control: tag -1 moreinfo

On 5 Jul 2022 18:21:27 +0500 Alexandr Podgorniy  wrote:
> I tried 5.18.0-2-amd64 kernel recently and noticed that it doesn't go to 
> sleep when Bluetooth mouse connected. Otherwise it's fine. Not tried 
> 5.18.5 yet.

FTR: 5.18.5 is 5.18.0-2 and if that didn't fix it, then it's a different issue.

What's the current status of this bug?
If the issue still occurs, do you have some logs/dmesg output you can share?

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

Bug#689962: linux: Compile with CONFIG_VIRTIO_CONSOLE=y

[Vincent Bernat]

  ❦ 24 avril 2021 16:15 +02, Salvatore Bonaccorso:


Is this still something we should consider, or can the bug be closed?


I suppose that's since almost nobody chimes in in all these years, there
is no need.


Now that 989153 and 989181 have been merged into this one and the bug is
reopened, then the next question becomes: how to proceed.

The current setting in debian/config/config (ie: globally) is this:
CONFIG_VIRTIO_CONSOLE=m

I can make a MR to change that to =y, but I'm not familiar with VIRTIO_CONSOLE
and thus can't assess whether it's useful on all architectures.

https://salsa.debian.org/kernel-team/linux/-/commit/e83e9da65cce7c870acc6b601738dd5d71bdc842
is where the above setting was made ... on 2008-09-04.

The helptext in drivers/char/Kconfig says:
"Virtio console for use with hypervisors."


Unfortunately, I don't know either for other architectures. It is useful 
at least for AMD64 (to make it work on VM with no ISA bus). For ARM64, I 
don't know if the platform has a better mechanism for serial consoles.

Bug#693230: ITA: multimail -- Offline reader for BW, QWK,OMEN and SOUP

[Bastian Germann]

Control: retitle -1 O: multimail -- Offline reader for BW, QWK,OMEN and SOUP
Control: noowner -1

On Sun, 3 Oct 2021 23:58:04 +0200 Bastian Germann  wrote:

d/changelog
===
Please merge all three changelog entries that have not appeared in Debian yet 
into one. Especially drop "Non-maintainer upload", "New snapshot from upstream" 
and one of the "New maintainer" entries in the process.


d/upstream/metadata
===
I do not see that you are the upstream maintainer, so please do not claim that.

d/compat

Do not use the deprecated v11 debhelper compat.

d/control
=
Please use debhelper-compat so that you can drop the compat file.

d/copyright
===
I think the licenses are complete. But please add missing copyright statements 
from University of Washington and Peter Krefting.


Thanks,
Bastian


I did this myself. If you still want to adopt the package, please make this 
your ITA again.

Bug#1008681: linux-image-5.16.0-5-amd64: WARNING: CPU: 1 PID: 1061 at fs/nfsd/nfs4state.c:5891 nfs4_preprocess_stateid_op+0x600/0x690 [nfsd]

[Laurent Bonnaud]

On 12/5/22 18:26, Diederik de Haas wrote:


Do you know what the faulty and fixed 5.10 version were/are?


The problem was not really in the kernel, but in rpc.svcgssd that has trouble 
with large Kerberos credentials.

The only problem with 5.10 kernels is that they only display warnings about 
hung rpc.svcgssd processes, instead of this warning message displayed by more 
recent kernels:

./net/sunrpc/auth_gss/svcauth_gss.c:  "RPCSEC/GSS credential too large - 
please use gssproxy\n");

Cheers,

--
Laurent.

Bug#1025488: rust-cache-padded: seems this package is obsolete and can be dropped

[Jonas Smedegaard]

Source: rust-cache-padded
Version: 1.1.1-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: block -1 by 1025487

This package is deprecated upstream:
https://github.com/smol-rs/cache-padded/issues/10

Only reverse dependency in Debian, rust-concurrent-queue, should stop
using it soon (see bug#1025487).

Please consider dropping this package (and perhaps make a note
somewhere, similar to https://wiki.debian.org/Javascript/KnownPatches
for NodeJS, that newly introduced (but maybe ancient) packages should be
patched to instead use crossbeam-utils (as noted in above Github issue).

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmOOMBoACgkQLHwxRsGg
ASGOLg/+Pftl+pzbTMtFP6sxzt4Dl94lLGLcpRHVlkAsey0ma8dggjxb+GKOYHFx
qureIpa4Alq8QDSiodM5sBaQtFxOhe1XvpV9Pqwmfq0/qZl7bN9bL5J81QPpFyPq
nmP3Kh1bp7lKrPsovKeD3hPHMceboNK7TVqu8Ww5svsaWC1dg/F/WD2R5d5tO8YM
DSPkqpKT8Z6usc5Md1Yvj6lmC0OL8vDjzfGtD+0oTq7FwJIQnX2p3OjYnY0Zwh1M
7Pp96bKnMtQhOD1uUWhlW+ewMHR0JwuGjMikjk+CZtqzLrJf7rs4uplQ+rM3aWS6
qsUAR+VcUkn77hYvnIYTflfPc8237AjDTFP/szEQNn1qLEA0yY4vN7He1x4NGczK
JN8xjINXZvNPxrbQWvb/UKoQrtvdAWgH9rvsiSTA3WJ/nUMkGYt0ZpDsviuhXHPk
5nmpBHZ+HJnxKHNL6aYPfzDlj5I+M/MY7mNEVA5lhcGiqdXD6xPPtirFpIu2saaH
9ubXN+I92qkPYrzizjmSFbD016QPMLS/hnHCsNJUakPOrxWLRDrYlUdlPdzw9sUh
olXS3uyptYyb+oHTiigI6koI3oQntgJdB6OFfhvMuaczIREfLBpnyBIiSiITgwlP
BiwnvazKfQGAfPAZxYQVV2YA7HV3EUUcO3jn1i5cJhet8aOTsM0=
=oHlY
-END PGP SIGNATURE-

Bug#1025487: rust-concurrent-queue: please upgrade to v2

[Jonas Smedegaard]

Source: rust-concurrent-queue
Version: 1.2.2-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to newer upstream branch v2.

Reverse-dependencies rust-async-channel and rust-async-executor are
ready for this transition, and seemingly the only other reverse
dependency rust-async-io should support this newer branch by updating to
v1.11.0 or newer.

- - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmOOLOwACgkQLHwxRsGg
ASHGZhAAn+hzAbnJj8ohByDL5Wwy7KgQDvwj7Q7rKmu1yi1lQ4dTIYHvNBO/Z5CS
/EBvuP2RbC1JDt42DVS1RWm2TwlFcYNj4Sd8ztTVFupIv9IlYZlQo2WhN/s2VcWj
TDRA825Z3fddAbhku71aeLYzt6yNb+9onxKjgw9whwQDklKbf5nh3L7wlV8JvsQL
ClIP/0pl36BxGaqI3mL/DOsHz/Hdv1iOr9K8emgkwIUSw+7cSh3RpSD7Cvizhh5x
3Qa2dPL5BUo5PtNdqM1CPNdrzJh9Cug65rJbSGAdFMUYzw+bCX+I7H2yNnam+sY/
RT1virbqZHmF0/93bdH2bEGgjGsolSTAHG18BCA3pB4hZ1f92Vzu8rxqobzKH1z0
p7V3rf+8utZhu1vYro+M1j/hbguasGriGkbtUC6XPTjH/raMlOI0QR5NKZ/68y0M
kLv6+6+95tAIFQAi2h9Z9pc9piycBO/xR4OHcQBFx+r9RNnjhelC56YLFIeYtCyg
mEi1jcv7hGrp7TBStXztNu7lcRA0aoWEWi3yQRWoPk9cqiSoYDYVUuZAOxEtlwPN
k1d2p7CpTG7+vMpO8hV9EAJ/hewy16iuE/s3xqE1+9jQsFqxXtzfWqyeRBL/+jsS
VNhPxjMe9zkZErRC35rYPe4BiYAwgBgHNIJBpXFYHa/7ajJyzSk=
=uNHd
-END PGP SIGNATURE-

Bug#689962: linux: Compile with CONFIG_VIRTIO_CONSOLE=y

[Diederik de Haas]

On Tuesday, 31 May 2022 18:52:44 CET Diederik de Haas wrote:
> Now that 989153 and 989181 have been merged into this one and the bug is
> reopened, then the next question becomes: how to proceed.

Ping?

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

Bug#1024395: not fixed for me and worse it did break a PC that was unaffected by previous version

[Steve McIntyre]

On Mon, Dec 05, 2022 at 06:19:53PM +0100, Eric Valette wrote:
>On 05/12/2022 18:07, Steve McIntyre wrote:
>
>> You're using the Secure Boot path (shim -> grub-efi-amd64-signed), so
>> the version of grub that matters for you is the signed version:
>> 1+2.06+5. That is (so far) still based on grub2 source version 2.06-5.
>> It takes a short while for the builds to propagate through the signing
>> machinery in Debian.
>> 
>> Please be patient, the fix is on the way to you. If you can check
>> again when 1+2.06+6 is available, that will be more helpful.
>
>Fair enough but for me this should be handled as a dependency so that you
>cannot upgrade only part of grub components. A meta package that makes sure
>all the dependencies are ok before starting the upgrade.

There are no dependency issues to worry about here, I'm afraid you
simply misunderstood the grub packaging setup. That's reasonable -
it's not obvious! Just don't expect the bug to be fixed until the
changes have propagated...

>And as explained I must play with windows bitlocker to suspend it before
>being able to install so I would prefer doing it all at once.

ACK, I understand your pain there. :-/

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Yes, of course duct tape works in a near-vacuum. Duct tape works
 anywhere. Duct tape is magic and should be worshipped."
   -― Andy Weir, "The Martian"

Bug#1019147: [systemd-devel] systemd-container: Trying to use a bookworm chroot with a buster host fails / Failed to create /init.scope control group

[Bernhard Übelacker]

Am 03.12.22 um 23:38 schrieb Bernhard Übelacker:


I thought if strace can observe the process in question, would gdb also
be able. And found starting nspawn with gdbserver, 'set follow-fork-mode 
child'

and gdb from inside the container via plain chroot seems working well.

So it looks like the failing "syscall_0x1b7" from strace is "faccessat2" 
[2].


And it seems "faccessat2" got added just in kernel 5.8 [3],
therefore it might fail with the kernel 4.19.
So I fear this needs a newer kernel, and/or this is more a glibc issue 
then?




Hello,
just a few short additions.
I was looking further into this issue, and found disabling apparmor
by booting the host with "apparmor=0" did not improve the situation.


Then I found following entry in the systemd debian package changelog [1][2]:

   * seccomp: allow turning off of seccomp filtering via env var.
 Since glibc 2.33 faccessat() is implemented via faccessat2(), which
 is breaking running containers that use such a version of glibc under
 systemd-nspawn in Buster.
 Turning off seccomp filtering via the SYSTEMD_SECCOMP env var makes it
 possible to run such new containers. (Closes: #984573)


This fits perfectly the situation and the container starts
successfully with this workaround:

SYSTEMD_SECCOMP=0 systemd-nspawn 
--directory=/var/lib/machines/test-bookworm --boot


Kind regards,
Bernhard


[1] 
https://metadata.ftp-master.debian.org/changelogs//main/s/systemd/systemd_241-7~deb10u8_changelog
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984573

Bug#1008681: linux-image-5.16.0-5-amd64: WARNING: CPU: 1 PID: 1061 at fs/nfsd/nfs4state.c:5891 nfs4_preprocess_stateid_op+0x600/0x690 [nfsd]

[Diederik de Haas]

On Monday, 5 December 2022 18:03:57 CET Laurent Bonnaud wrote:
> On 12/5/22 17:34, Diederik de Haas wrote:
> > btw: What's the reason for not using a 5.10 kernel on a Stable system?
> > (Not that I mind, just curious)
> 
> I had a NFS problem with the 5.10 kernel and tested a more recent kernel to
> see if this problem had been fixed.

Great, that's quite useful/helpful :-)

> > What's the current status wrt this issue?
> 
> Since then, I went back to using a 5.10 kernel, where this issue does not
> show up.

Do you know what the faulty and fixed 5.10 version were/are?
Not critical as this bug doesn't actually track that (now), but it could help 
in finding the exact commit which fixed it.

> I will test again when Debian chooses the kernel branch that will be used
> for Debian 12...

That will *probably* be 6.1 of which a rcX version is available in 
Experimental. Keep in mind that Bookworm will ship with NFS version 2.6+ 
whereas Bullseye had 1.3.4, so a MAJOR version upgrade.

Cheers,
  Diederik

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

Bug#1024395: not fixed for me and worse it did break a PC that was unaffected by previous version

[Eric Valette]

On 05/12/2022 18:07, Steve McIntyre wrote:


You're using the Secure Boot path (shim -> grub-efi-amd64-signed), so
the version of grub that matters for you is the signed version:
1+2.06+5. That is (so far) still based on grub2 source version 2.06-5.
It takes a short while for the builds to propagate through the signing
machinery in Debian.

Please be patient, the fix is on the way to you. If you can check
again when 1+2.06+6 is available, that will be more helpful.


Fair enough but for me this should be handled as a dependency so that 
you cannot upgrade only part of grub components. A meta package that 
makes sure all the dependencies are ok before starting the upgrade.


And as explained I must play with windows bitlocker to suspend it before 
being able to install so I would prefer doing it all at once.



-- eric

Bug#891197: Please switch to pcre2

[Aaron M. Ucko]

Andreas Tille  writes:

> Finally it seems to boil down to change four files of real code

Right, usage is centralized via wrappers, so they'll need extensive
changes but with any luck nothing else should (apart from necessary
build-system adjustments).  At any rate, upstream is now open to moving
on, albeit at low priority.

-- 
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#1024395: Side note : the packages are marked on hold in previous mail because of dual boot with windows bitlocker activated.

[Eric Valette]

If I upgrade EFI components without suspending bitlocker on Windows I 
need to enter the bitlocker key. Very annoying.


So I cannot update normally shim and grub EFI components. There are on 
hold until I know I have disabled bitlocker and can manually upgrade.


As soon as done, I put them again on hold.

--eric

Bug#617296: debian packages of RStudio

[Andreas Tille]

Hi Doug,

Am Mon, Dec 05, 2022 at 05:02:55PM + schrieb Torrance, Douglas:
> 
> I played around a little bit with packaging RStudio about a year ago.  If it's
> any help, here's a link to my work:
> https://salsa.debian.org/dtorrance/rstudio

Since I've found this on Salsa I've added you in CC. ;-)

I'd be happy if you would start contributing to the r-pkg-team
repository to join forces.  It might make sense if you would remove your
private repository to not mislead potential contributors.

Kind regards
Andreas.

-- 
http://fam-tille.de

Bug#1008681: linux-image-5.16.0-5-amd64: WARNING: CPU: 1 PID: 1061 at fs/nfsd/nfs4state.c:5891 nfs4_preprocess_stateid_op+0x600/0x690 [nfsd]

[Laurent Bonnaud]

On 12/5/22 17:34, Diederik de Haas wrote:


btw: What's the reason for not using a 5.10 kernel on a Stable system?
(Not that I mind, just curious)


Thanks for your interest :>.

I had a NFS problem with the 5.10 kernel and tested a more recent kernel to see 
if this problem had been fixed.

(For the sake of completeness, the problem was running rpc.svcgssd instead of 
gssproxy).


What's the current status wrt this issue?


Since then, I went back to using a 5.10 kernel, where this issue does not show 
up.

I will test again when Debian chooses the kernel branch that will be used for 
Debian 12...

Thanks again,

--
Laurent.

Bug#1024395: not fixed for me and worse it did break a PC that was unaffected by previous version

[Steve McIntyre]

On Mon, Dec 05, 2022 at 05:55:13PM +0100, Eric Valette wrote:
>I had the previous version 2.06-5 on a laptop, and it was not affected by the
>bug, Only my very old Desktop was.
>
>As the bug was closed, I did install 2.06-6 on my laptop (or at least the
>composant actually upgraded) and now it also fails on my laptop with same
>error than on my desktop.
>
>I now have apparently several grub version flavors and several shim version
>flavor:
>
>15.4 for shim-signed:amd64 and shim-signed-common and 15.6 for
>shim-helpers-amd64-signed and shim-unsigned
>
>And for grub, I have 2.06-6 except for the important part :
>grub-efi-amd64-signed that is still at 2.06-5.

The shim versions don't matter here, the issues are all in grub.

>root@:~# dpkg -l grub*
>Desired=Unknown/Install/Remove/Purge/Hold
>|
>Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
>|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
>||/ Name  Version  Architecture Description
>+++-=---=
...
>hi  grub-efi-amd64-signed 1+2.06+5 amd64GRand Unified Bootloader,
>version 2 (amd64 UEFI signed by Debian)

You're using the Secure Boot path (shim -> grub-efi-amd64-signed), so
the version of grub that matters for you is the signed version:
1+2.06+5. That is (so far) still based on grub2 source version 2.06-5.
It takes a short while for the builds to propagate through the signing
machinery in Debian.

Please be patient, the fix is on the way to you. If you can check
again when 1+2.06+6 is available, that will be more helpful.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"... the premise [is] that privacy is about hiding a wrong. It's not.
 Privacy is an inherent human right, and a requirement for maintaining
 the human condition with dignity and respect."
  -- Bruce Schneier

Bug#1025486: ModuleNotFoundError: No module named 'scrape_schema_recipe' / 'ebooklib'

[Philip Rinn]

Package: gourmand
Version: 1.1.0+really1.0.0-2
Severity: important
X-Debbugs-Cc: ri...@debian.org

Hi,

gourmand fails to load (at least) three of it's plugins due to missing Python
modules. As two of these plugins are importers for websites, it impacts
usability a lot.
Here is what I get when I run gourmand from console:

philip@debian:~$ gourmand
args = Namespace(db_url='', threads=False, gourmanddir='',
thread_debug_interval=5.0, thread_debug=False, debug_file='', time=False,
debug=None)
WARNING: Plugin module import failed
PATH: ['/usr/bin', '/usr/lib/python310.zip', '/usr/lib/python3.10',
'/usr/lib/python3.10/lib-dynload', '/usr/local/lib/python3.10/dist-packages',
'/usr/lib/python3/dist-packages', '/usr/lib/python3/dist-
packages/gourmand/plugins', '/usr/lib/python3/dist-
packages/gourmand/plugins/import_export']
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/gourmand/plugin_loader.py", line 300, in
get_module
self._loaded = __import__(self.module)
  File "/usr/lib/python3/dist-
packages/gourmand/plugins/import_export/web_import_plugin/__init__.py", line 1,
in 
from . import generic_web_importer_plugin
  File "/usr/lib/python3/dist-
packages/gourmand/plugins/import_export/web_import_plugin/generic_web_importer_plugin.py",
line 6, in 
from gourmand.plugins.import_export.website_import_plugins.state import \
  File "/usr/lib/python3/dist-
packages/gourmand/plugins/import_export/website_import_plugins/__init__.py",
line 1, in 
from . import (about_dot_com_plugin, allrecipes_plugin,
  File "/usr/lib/python3/dist-
packages/gourmand/plugins/import_export/website_import_plugins/allrecipes_plugin.py",
line 3, in 
from . import schema_org_parser
  File "/usr/lib/python3/dist-
packages/gourmand/plugins/import_export/website_import_plugins/schema_org_parser.py",
line 7, in 
import scrape_schema_recipe
ModuleNotFoundError: No module named 'scrape_schema_recipe'
WARNING: Failed to load plugin web_import_plugin
ERROR:root:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/gourmand/plugin_loader.py", line 129, in
load_active_plugins
self.active_plugins.extend(self.available_plugin_sets[p].plugins)
  File "/usr/lib/python3/dist-packages/gourmand/plugin_loader.py", line 312, in
__getattr__
return self.get_plugins()
  File "/usr/lib/python3/dist-packages/gourmand/plugin_loader.py", line 320, in
get_plugins
return self.get_module().plugins
AttributeError: 'NoneType' object has no attribute 'plugins'
WARNING: Plugin module import failed
PATH: ['/usr/bin', '/usr/lib/python310.zip', '/usr/lib/python3.10',
'/usr/lib/python3.10/lib-dynload', '/usr/local/lib/python3.10/dist-packages',
'/usr/lib/python3/dist-packages', '/usr/lib/python3/dist-
packages/gourmand/plugins', '/usr/lib/python3/dist-
packages/gourmand/plugins/import_export']
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/gourmand/plugin_loader.py", line 300, in
get_module
self._loaded = __import__(self.module)
  File "/usr/lib/python3/dist-
packages/gourmand/plugins/import_export/website_import_plugins/__init__.py",
line 1, in 
from . import (about_dot_com_plugin, allrecipes_plugin,
  File "/usr/lib/python3/dist-
packages/gourmand/plugins/import_export/website_import_plugins/allrecipes_plugin.py",
line 3, in 
from . import schema_org_parser
  File "/usr/lib/python3/dist-
packages/gourmand/plugins/import_export/website_import_plugins/schema_org_parser.py",
line 7, in 
import scrape_schema_recipe
ModuleNotFoundError: No module named 'scrape_schema_recipe'
WARNING: Failed to load plugin website_import_plugins
ERROR:root:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/gourmand/plugin_loader.py", line 129, in
load_active_plugins
self.active_plugins.extend(self.available_plugin_sets[p].plugins)
  File "/usr/lib/python3/dist-packages/gourmand/plugin_loader.py", line 312, in
__getattr__
return self.get_plugins()
  File "/usr/lib/python3/dist-packages/gourmand/plugin_loader.py", line 320, in
get_plugins
return self.get_module().plugins
AttributeError: 'NoneType' object has no attribute 'plugins'
WARNING: Plugin module import failed
PATH: ['/usr/bin', '/usr/lib/python310.zip', '/usr/lib/python3.10',
'/usr/lib/python3.10/lib-dynload', '/usr/local/lib/python3.10/dist-packages',
'/usr/lib/python3/dist-packages', '/usr/lib/python3/dist-
packages/gourmand/plugins', '/usr/lib/python3/dist-
packages/gourmand/plugins/import_export']
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/gourmand/plugin_loader.py", line 300, in
get_module
self._loaded = __import__(self.module)
  File "/usr/lib/python3/dist-
packages/gourmand/plugins/import_export/epub_plugin/__init__.py", line 1, in

from . import epub_exporter_plugin
  File "/usr/lib/python3/dist-
packages/gourmand/plugins/import_export/epub_plugin/epub_exporter_plugin.py",
line 4, in 
from . import epub_exporter
  File 

Bug#617296: debian packages of RStudio

[Torrance, Douglas]

On Mon 05 Dec 2022 11:24:22 AM -05, Andreas Tille  wrote:

Hi Neal,

Am Mon, Dec 05, 2022 at 07:55:36AM -0800 schrieb Neal Fultz:

I saw you left a ticket on the github repo for estimatr that I used to work
on about debian support.

I had started working on packaging RStudio for debian, but nobody ever
wrote back to my post:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617296#204


Great you worked on packaging RStudio.  It would be really welcome, if
you would move the package development to Debian R pkg team at

   https://salsa.debian.org/r-pkg-team/
 

It is something I'd like to eventually get into the main debian
repositories, was curious if you have any advice, it's the most confusing
build system I've had to deal with. I should have more time for open source
Q1 next year.


I have moved the rstudio repository on Salsa to R-pkg-team[1] and merged
those parts of your packaging from mentors into this.  I've droped the
unused example boilerplates and did some other polishing of your work.

Please create a login at salsa.debian.org and I'll add you to the
r-pkg-team to enable you contributing to this package.  Please note:
We do not work with mentors.debian.net for sponsoring inside the team.
You can ping us over the mailing list

debia...@lists.debian.org

for any packaging question.

I personally would love to see rstudio packaged and I think the most
promising way is to move the discussion about this to this list.

Kind regards
Andreas.

[1] https://salsa.debian.org/r-pkg-team/rstudio


I played around a little bit with packaging RStudio about a year ago.  If it's
any help, here's a link to my work:
https://salsa.debian.org/dtorrance/rstudio

Doug


signature.asc
Description: PGP signature

Bug#1025485: pybuild-plugin-pyproject: pyproject plugin installs data_files in wrong place

[Scott Kitterman]

I ran into a similar issue packaging the new spf-engine, which now uses flit 
and it's new external-data section [1].  I ended up using .install and 
.manpages files to get things in the right place.

The challenge is that none of this is standardized, so there's no way to come 
up with a general solution (pip is even somewhat inconsistent depending on how 
you do the installation).  At least arguably worse is that it appears that the 
upstream Python community largely regards this lack of standards as a feature.

Scott K

[1] 
https://flit.pypa.io/en/latest/pyproject_toml.html?highlight=data#external-data-section

On December 5, 2022 4:40:17 PM UTC, Marcin Owsiany  wrote:
>Package: pybuild-plugin-pyproject
>Version: 5.20221122
>Severity: important
>
>TL;DR: plugin_pyproject.py installs files listed under
>[options.data_files] (such as manpages) in an unexpected place,
>different than pip would have.
>
>Dear Maintainer,
>
>First, a disclaimer: I have almost zero experience and knowledge about
>Python project installation tools, and setup.cfg in particular.
>So please let me know if I'm talking nonsense here.
>
>A bit of background:
>
>Upstream of ledgerhelpers has recently switched from setup.py to
>pyproject.toml + setup.cfg. The latter file contains a bunch of data
>files (desktop files, documentation, and manpages) which are supposed to
>be installed in FHS-compliant places under /usr/share:
>https://github.com/Rudd-O/ledgerhelpers/blob/48ba347b3a81b8759850e5b454bb91c03bce/setup.cfg#L38-L58
>
>This is indeed more or less when these files land when the application
>is installed using pip or the RPM package prepared by the upstream
>maintainer. However when I tried to adapt my debian package to the
>current upstream version, the pyproject plugin for pybuild installs them
>together with the python modules. So for example the manpages end up in
>somewhat weird location like /usr/lib/python3.10/dist-packages/share/man/man1
>
>I had a look at the code, and I think this FIXME is exactly about this
>issue I'm having:
>
>https://salsa.debian.org/python-team/tools/dh-python/-/blob/master/dhpython/build/plugin_pyproject.py#L131-132
>
>If I correctly understand what is going on in build_step2() and
>install() then I think data_files should be treated similarly to
>scripts: unpacked into a separate directory and then copied into something 
>like:
>args['destdir'] + paths['data']
>
>While the data_files concept seems to be deprecated according to
>https://setuptools.pypa.io/en/latest/userguide/declarative_config.html#opt-4I
>and does not have a replacement judging by
>https://github.com/pypa/packaging-problems/issues/72
>I think it would still make sense to try and imitate what pip is doing at
>the moment.
>
>-- System Information:
>Debian Release: bookworm/sid
>  APT prefers testing-debug
>  APT policy: (500, 'testing-debug'), (500, 'testing')
>Architecture: amd64 (x86_64)
>
>Kernel: Linux 5.19.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
>Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE not 
>set
>Shell: /bin/sh linked to /usr/bin/dash
>Init: systemd (via /run/systemd/system)
>LSM: AppArmor: enabled
>
>Versions of packages pybuild-plugin-pyproject depends on:
>ii  dh-python  5.20221122
>ii  python3-build  0.7.0-4
>ii  python3-installer  0.5.1+dfsg1-2
>ii  python3-tomli  2.0.1-1
>
>pybuild-plugin-pyproject recommends no packages.
>
>pybuild-plugin-pyproject suggests no packages.
>
>-- no debconf information
>

Bug#1024395: not fixed for me and worse it did break a PC that was unaffected by previous version

[Eric Valette]

I had the previous version 2.06-5 on a laptop, and it was not affected 
by the bug, Only my very old Desktop was.


As the bug was closed, I did install 2.06-6 on my laptop (or at least 
the composant actually upgraded) and now it also fails on my laptop with 
same error than on my desktop.


I now have apparently several grub version flavors and several shim 
version flavor:


15.4 for shim-signed:amd64 and shim-signed-common and 15.6 for 
shim-helpers-amd64-signed and shim-unsigned


And for grub, I have 2.06-6 except for the important part : 
grub-efi-amd64-signed that is still at 2.06-5.



dpkg -l shim*
Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version  Architecture Description
+++-=---
un  shim(no description 
available)
hi  shim-helpers-amd64-signed 1+15.6+1 amd64boot loader to 
chain-load signed boot loaders (signed by Debian)
hi  shim-signed:amd64 1.38+15.4-7  amd64Secure Boot 
chain-loading bootloader (Microsoft-signed binary)
hi  shim-signed-common1.38+15.4-7  all  Secure Boot 
chain-loading bootloader (common helper scripts)
hi  shim-unsigned 15.6-1   amd64boot loader to 
chain-load signed boot loaders under Secure Boot

root@:~# dpkg -l grub*
Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version  Architecture Description
+++-=---=
un  grub(no description 
available)
un  grub-cloud-amd64(no description 
available)
hi  grub-common   2.06-6   amd64GRand Unified 
Bootloader (common files)
un  grub-coreboot   (no description 
available)
un  grub-doc(no description 
available)
hi  grub-efi  2.06-6   amd64GRand Unified 
Bootloader, version 2 (dummy package)
hi  grub-efi-amd642.06-6   amd64GRand Unified 
Bootloader, version 2 (EFI-AMD64 version)
hi  grub-efi-amd64-bin2.06-6   amd64GRand Unified 
Bootloader, version 2 (EFI-AMD64 modules)
hi  grub-efi-amd64-signed 1+2.06+5 amd64GRand Unified 
Bootloader, version 2 (amd64 UEFI signed by Debian)
un  grub-efi-arm(no description 
available)
un  grub-efi-arm64  (no description 
available)
un  grub-efi-ia32   (no description 
available)
un  grub-efi-ia64   (no description 
available)
un  grub-emu(no description 
available)
un  grub-ieee1275   (no description 
available)
un  grub-legacy (no description 
available)
un  grub-legacy-doc (no description 
available)
un  grub-linuxbios  (no description 
available)
un  grub-pc (no description 
available)
hi  grub-pc-bin   2.06-6   amd64GRand Unified 
Bootloader, version 2 (PC/BIOS modules)
un  grub-uboot  (no description 
available)
un  grub-xen(no description 
available)
un  grub-yeeloong   (no description 
available)
un  grub2   (no description 
available)
hi  grub2-common  2.06-6   amd64GRand Unified 
Bootloader (common files for version 2)

root@:~#


-- eric