Bug#1025045: Test failure in StructuralVariantAnnotation

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 Daniel Cameron 

Hi Daniel,

when upgrading StructuralVariantAnnotation to its latest version (1.13.0)
I noticed that some of its tests are failing.  I have reported this to
the Debian bug tracking system[1].  The errors are starting with

[ FAIL 30 | WARN 4 | SKIP 0 | PASS 85 ]

══ Failed tests 
── Error ('test-extensions-VCF.R:28'): INFO column import ──
Error in `h(simpleError(msg, call))`: error in evaluating the argument 'x' in 
selecting a method for function 'breakpointRanges': no 'header' line "#CHROM 
POS ID..."?
Backtrace:
 ▆
  1. 
├─StructuralVariantAnnotation::breakpointRanges(.testrecord(c("chr10\t2991435\tINV\tN\t\t.\tLowQual\tSVTYPE=INV;CHR2=chr1;END=19357517;CT=3to5")))
 at test-extensions-VCF.R:28:8
  2. 
├─StructuralVariantAnnotation:::.testrecord(c("chr10\t2991435\tINV\tN\t\t.\tLowQual\tSVTYPE=INV;CHR2=chr1;END=19357517;CT=3to5"))
  3. │ ├─VariantAnnotation::readVcf(.testfile(filename), "")
  4. │ └─VariantAnnotation::readVcf(.testfile(filename), "")
  5. │   └─VariantAnnotation (local) .local(file, genome = genome, param = 
param, ...)
  6. │ └─VariantAnnotation:::.readVcf(...)
  7. │   └─VariantAnnotation:::.scanVcfToVCF(...)
  8. │ ├─VariantAnnotation::scanVcfHeader(file)
  9. │ └─VariantAnnotation::scanVcfHeader(file)
 10. │   ├─Rsamtools::scanBcfHeader(file[[1]], ...)
 11. │   └─Rsamtools::scanBcfHeader(file[[1]], ...)
 12. │ └─BiocGenerics::Map(...)
 13. │   ├─BiocGenerics (local) standardGeneric("Map")
 14. │   │ ├─BiocGenerics::eval(mc, env)
 15. │   │ └─base::eval(mc, env)
 16. │   │   └─base::eval(mc, env)
 17. │   └─base::Map(f = f, ...)
 18. │ └─base::mapply(FUN = f, ..., SIMPLIFY = FALSE)
 19. │   └─Rsamtools (local) ``(dots[[1L]][[1L]])
 20. │ ├─Rsamtools::scanBcfHeader(bf)
 21. │ └─Rsamtools::scanBcfHeader(bf)
 22. └─base::.handleSimpleError(...)
 23.   └─base (local) h(simpleError(msg, call))
── Error ('test-extensions-VCF.R:49'): Delly TRA ───
Error in `h(simpleError(msg, call))`: error in evaluating the argument 'x' in 
selecting a method for function 'breakpointRanges': no 'header' line "#CHROM 
POS ID..."?
Backtrace:
 ▆
  1. 
├─StructuralVariantAnnotation::breakpointRanges(.testrecord(c("chr10\t2991435\tTRA0001\tN\t\t.\tLowQual\tCIEND=0,100;CIPOS=0,50;SVTYPE=TRA;CHR2=chr1;END=19357517;CT=3to5")))
 at test-extensions-VCF.R:49:4
  2. 
├─StructuralVariantAnnotation:::.testrecord(c("chr10\t2991435\tTRA0001\tN\t\t.\tLowQual\tCIEND=0,100;CIPOS=0,50;SVTYPE=TRA;CHR2=chr1;END=19357517;CT=3to5"))
  3. │ ├─VariantAnnotation::readVcf(.testfile(filename), "")
  4. │ └─VariantAnnotation::readVcf(.testfile(filename), "")
  5. │   └─VariantAnnotation (local) .local(file, genome = genome, param = 
param, ...)
  6. │ └─VariantAnnotation:::.readVcf(...)
  7. │   └─VariantAnnotation:::.scanVcfToVCF(...)
  8. │ ├─VariantAnnotation::scanVcfHeader(file)
  9. │ └─VariantAnnotation::scanVcfHeader(file)
 10. │   ├─Rsamtools::scanBcfHeader(file[[1]], ...)
 11. │   └─Rsamtools::scanBcfHeader(file[[1]], ...)
 12. │ └─BiocGenerics::Map(...)
 13. │   ├─BiocGenerics (local) standardGeneric("Map")
 14. │   │ ├─BiocGenerics::eval(mc, env)
 15. │   │ └─base::eval(mc, env)
 16. │   │   └─base::eval(mc, env)
 17. │   └─base::Map(f = f, ...)
 18. │ └─base::mapply(FUN = f, ..., SIMPLIFY = FALSE)
 19. │   └─Rsamtools (local) ``(dots[[1L]][[1L]])
 20. │ ├─Rsamtools::scanBcfHeader(bf)
 21. │ └─Rsamtools::scanBcfHeader(bf)
 22. └─base::.handleSimpleError(...)
 23.   └─base (local) h(simpleError(msg, call))
── Error ('test-extensions-VCF.R:71'): empty VCF ───
Error in `h(simpleError(msg, call))`: error in evaluating the argument 'x' in 
selecting a method for function 'breakpointRanges': no 'header' line "#CHROM 
POS ID..."?


You can find a full build log here

   
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-bioc-structuralvariantannotation/28747149/log.gz

Kind regards

 Andreas.


[1] https://bugs.debian.org/1025045

-- 
http://fam-tille.de

Bug#1025045: r-bioc-structuralvariantannotation: Test failures in autopkgtest

[Andreas Tille]

Source: r-bioc-structuralvariantannotation
Version: 1.13.0+ds-1
Severity: normal
X-Debbugs-Cc: 1023...@bugs.debian.org

Hi,

the package fails its autopkgtest.  The errors starts with:


[ FAIL 30 | WARN 4 | SKIP 0 | PASS 85 ]

══ Failed tests 
── Error ('test-extensions-VCF.R:28'): INFO column import ──
Error in `h(simpleError(msg, call))`: error in evaluating the argument 'x' in 
selecting a method for function 'breakpointRanges': no 'header' line "#CHROM 
POS ID..."?
Backtrace:
 ▆
  1. 
├─StructuralVariantAnnotation::breakpointRanges(.testrecord(c("chr10\t2991435\tINV\tN\t\t.\tLowQual\tSVTYPE=INV;CHR2=chr1;END=19357517;CT=3to5")))
 at test-extensions-VCF.R:28:8
  2. 
├─StructuralVariantAnnotation:::.testrecord(c("chr10\t2991435\tINV\tN\t\t.\tLowQual\tSVTYPE=INV;CHR2=chr1;END=19357517;CT=3to5"))
  3. │ ├─VariantAnnotation::readVcf(.testfile(filename), "")
  4. │ └─VariantAnnotation::readVcf(.testfile(filename), "")
  5. │   └─VariantAnnotation (local) .local(file, genome = genome, param = 
param, ...)
  6. │ └─VariantAnnotation:::.readVcf(...)
  7. │   └─VariantAnnotation:::.scanVcfToVCF(...)
  8. │ ├─VariantAnnotation::scanVcfHeader(file)
  9. │ └─VariantAnnotation::scanVcfHeader(file)
 10. │   ├─Rsamtools::scanBcfHeader(file[[1]], ...)
 11. │   └─Rsamtools::scanBcfHeader(file[[1]], ...)
 12. │ └─BiocGenerics::Map(...)
 13. │   ├─BiocGenerics (local) standardGeneric("Map")
 14. │   │ ├─BiocGenerics::eval(mc, env)
 15. │   │ └─base::eval(mc, env)
 16. │   │   └─base::eval(mc, env)
 17. │   └─base::Map(f = f, ...)
 18. │ └─base::mapply(FUN = f, ..., SIMPLIFY = FALSE)
 19. │   └─Rsamtools (local) ``(dots[[1L]][[1L]])
 20. │ ├─Rsamtools::scanBcfHeader(bf)
 21. │ └─Rsamtools::scanBcfHeader(bf)
 22. └─base::.handleSimpleError(...)
 23.   └─base (local) h(simpleError(msg, call))
── Error ('test-extensions-VCF.R:49'): Delly TRA ───
Error in `h(simpleError(msg, call))`: error in evaluating the argument 'x' in 
selecting a method for function 'breakpointRanges': no 'header' line "#CHROM 
POS ID..."?
Backtrace:
 ▆
  1. 
├─StructuralVariantAnnotation::breakpointRanges(.testrecord(c("chr10\t2991435\tTRA0001\tN\t\t.\tLowQual\tCIEND=0,100;CIPOS=0,50;SVTYPE=TRA;CHR2=chr1;END=19357517;CT=3to5")))
 at test-extensions-VCF.R:49:4
  2. 
├─StructuralVariantAnnotation:::.testrecord(c("chr10\t2991435\tTRA0001\tN\t\t.\tLowQual\tCIEND=0,100;CIPOS=0,50;SVTYPE=TRA;CHR2=chr1;END=19357517;CT=3to5"))
  3. │ ├─VariantAnnotation::readVcf(.testfile(filename), "")
  4. │ └─VariantAnnotation::readVcf(.testfile(filename), "")
  5. │   └─VariantAnnotation (local) .local(file, genome = genome, param = 
param, ...)
  6. │ └─VariantAnnotation:::.readVcf(...)
  7. │   └─VariantAnnotation:::.scanVcfToVCF(...)
  8. │ ├─VariantAnnotation::scanVcfHeader(file)
  9. │ └─VariantAnnotation::scanVcfHeader(file)
 10. │   ├─Rsamtools::scanBcfHeader(file[[1]], ...)
 11. │   └─Rsamtools::scanBcfHeader(file[[1]], ...)
 12. │ └─BiocGenerics::Map(...)
 13. │   ├─BiocGenerics (local) standardGeneric("Map")
 14. │   │ ├─BiocGenerics::eval(mc, env)
 15. │   │ └─base::eval(mc, env)
 16. │   │   └─base::eval(mc, env)
 17. │   └─base::Map(f = f, ...)
 18. │ └─base::mapply(FUN = f, ..., SIMPLIFY = FALSE)
 19. │   └─Rsamtools (local) ``(dots[[1L]][[1L]])
 20. │ ├─Rsamtools::scanBcfHeader(bf)
 21. │ └─Rsamtools::scanBcfHeader(bf)
 22. └─base::.handleSimpleError(...)
 23.   └─base (local) h(simpleError(msg, call))
── Error ('test-extensions-VCF.R:71'): empty VCF ───
Error in `h(simpleError(msg, call))`: error in evaluating the argument 'x' in 
selecting a method for function 'breakpointRanges': no 'header' line "#CHROM 
POS ID..."?


You can find a full build log here

   
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-bioc-structuralvariantannotation/28747149/log.gz

Kind regards

 Andreas.


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (501, 'testing'), (50, 'buildd-unstable'), (50, 'unstable'), (5, 
'experimental'), (1, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Bug#1025044: osmnx: Don't depend on python3-descartes

[Bas Couwenberg]

Source: osmnx
Version: 1.2.2+ds-1
Severity: important
Tags: patch

Dear Maintainer,

Your package depends on python3-descartes which is dead upstream and will be 
removed from Debian.

Upstream no longer uses it as noted in the ChangeLog for 1.1.0:

"
  - remove descartes dependency in line with geopandas
"

The attached patch resolves this issue by removing the (build) dependencies.

Kind Regards,

Bas
diff -Nru osmnx-1.2.2+ds/debian/changelog osmnx-1.2.2+ds/debian/changelog
--- osmnx-1.2.2+ds/debian/changelog 2022-08-14 18:49:34.0 +0200
+++ osmnx-1.2.2+ds/debian/changelog 2022-11-29 07:36:17.0 +0100
@@ -1,3 +1,10 @@
+osmnx (1.2.2+ds-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python3-descarted (build) dependencies.
+
+ -- Bas Couwenberg   Tue, 29 Nov 2022 07:36:17 +0100
+
 osmnx (1.2.2+ds-1) unstable; urgency=medium
 
   * New upstream nano version.
diff -Nru osmnx-1.2.2+ds/debian/control osmnx-1.2.2+ds/debian/control
--- osmnx-1.2.2+ds/debian/control   2022-05-28 17:39:21.0 +0200
+++ osmnx-1.2.2+ds/debian/control   2022-11-29 07:36:00.0 +0100
@@ -9,7 +9,6 @@
  dh-python,
  python3,
  python3-coverage,
- python3-descartes (>=1.1),
  python3-geopandas (>=0.7),
  python3-matplotlib (>=3.2),
  python3-networkx (>=2.4),
@@ -46,7 +45,7 @@
 Package: python3-osmnx
 Architecture: all
 Depends:
- ${python3:Depends}, python3-descartes, python3-distutils,
+ ${python3:Depends}, python3-distutils,
  ${misc:Depends}
 Recommends:
  python3-gdal, python3-rasterio,

Bug#1025032: kicad: Please add support for "riscv64" arch

[Carsten Schoenert]

Control: tags -1 pending

Hello Manuel,

Am 28.11.22 um 23:41 schrieb Manuel A. Fernandez Montecelo:

Hi,

Please enable this architecture, with the patch attached or an equivalent.

I built it locally on hardware, it built fine just by enabling the architecture
in debian/control, no other changes needed.


In fact, there doesn't seem to be fundamental reasons for this package to be
restricted to specific architectures, so perhaps it should just be set to "any".


the KiCad applications are using a small derived library from the Boost 
project which is included and shipped within the source of kicad.


https://gitlab.com/kicad/code/kicad/-/tree/master/thirdparty/libcontext

As I'm seeing now support for riscv64 was added in January 2022, so 
applying your suggested modification will work. But switching the 
Architecture field to any will not work.


I'm absolutely fine with adding riscv64 as additional supported 
architecture, I'm expecting at least one more release of the current 
stable 6.x branch before the hard freeze of bookworm will start. If 
things getting late I'll upload another version of 6.0.9 with the 
riscv64 architecture before.


--
Regards
Carsten

Bug#1022969: [EXTERNAL] Bug#1022969: isc-dhcp-client: dhcp6 client failing to renew the IPv6 address upon T1 expiry.

[Jack Aboutboul]

Ping on this Bastian. Can you please confirm we can get this into the next 
image refresh.

-Original Message-
From: Jack Aboutboul 
Sent: Tuesday, November 22, 2022 2:54 AM
To: 'Bastian Blank' ; Souradeep Chakrabarti 

Cc: 1022969-qu...@bugs.debian.org; 1022...@bugs.debian.org; 
1022969-submit...@bugs.debian.org; Anirudh Rayabharam 
; Jinank Jain 
Subject: RE: Bug#1022969: [EXTERNAL] Bug#1022969: isc-dhcp-client: dhcp6 client 
failing to renew the IPv6 address upon T1 expiry.

Thanks Bastian for the efforts on this.

Should this be the default behavior?

If so, can we get a package update and image refresh?

Thanks,
Jack

-Original Message-
From: Bastian Blank  
Sent: Tuesday, November 22, 2022 2:52 AM
To: Souradeep Chakrabarti 
Cc: 1022969-qu...@bugs.debian.org; 1022...@bugs.debian.org; 
1022969-submit...@bugs.debian.org; Jack Aboutboul ; 
Anirudh Rayabharam ; Jinank Jain 

Subject: Re: Bug#1022969: [EXTERNAL] Bug#1022969: isc-dhcp-client: dhcp6 client 
failing to renew the IPv6 address upon T1 expiry.

[Some people who received this message don't often get email from 
bastian.bl...@credativ.de. Learn why this is important at 
https://aka.ms/LearnAboutSenderIdentification ]

Hi Souradeep

On Tue, Nov 22, 2022 at 07:44:11AM +, Souradeep Chakrabarti wrote:
> Is there any work around for the time being?

Yes, you replace /sbin/dhclient-script with the file client/scripts/linux out 
of the isc-dhcp source.

Bastian

--
Bastian Blank
Berater
Telefon: +49 2166 9901-194
E-Mail: bastian.bl...@credativ.de
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209 
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, James Mark McGowan Unser Umgang mit 
personenbezogenen Daten unterliegt folgenden Bestimmungen: 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.credativ.de%2Fdatenschutz=05%7C01%7Cjaboutboul%40microsoft.com%7C51820d3fe8e94b397db408dacc5e79eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638047003427902103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=IMK67PgesfkjoLPVAYqs9Q9S4yAUfrJEB4VYgoVV5O8%3D=0

Bug#1023787: transition: liblxqt

[陳昌倬]

On Mon, Nov 28, 2022 at 08:07:14PM +0100, Paul Gevers wrote:
> Hi,
> 
> On 28-11-2022 17:50, ChangZhuo Chen (陳昌倬) wrote:
> > On Tue, Nov 22, 2022 at 09:58:48PM +0100, Paul Gevers wrote:
> > > Hi,
> > > 
> > > On 21-11-2022 01:05, ChangZhuo Chen (陳昌倬) wrote:
> > > > All affected packages have been uploaded to unstable. Sorry for the
> > > > mess.
> > > 
> > > Thanks. Let's see if they can migrate on their own to testing in the
> > > following days.
> > 
> > They do not migrate after 8 days, do we need to do anything?
> 
> Yes, bug 1024687 needs fixing.


In that case, we also need to finish libfm-qt migration. Please help to 
migrate libfm-qt in new queue [0] so that we can prepare the migration.


[0] https://ftp-master.debian.org/new/libfm-qt_1.2.0-2.html


-- 
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#1024979: please consider enabling gpsd support

[Mike Hommey]

On Mon, Nov 28, 2022 at 10:08:30PM +, John Scott wrote:
> On Tue, 2022-11-29 at 06:44 +0900, Mike Hommey wrote:
> > Support compiled in would make libgpsd a hard requirement, which some
> > other people would probably complain about. But anyways, the main
> > problem is that, as far as I know, it doesn't actually work.
> Your reasoning is sound. Thanks for your consideration. I have a
> proposition for you. Let's suppose I can get it to work on my local
> system (I haven't tried yet; as I'm sure you know, rebuilding Firefox
> takes a long time). In that case, would you be willing to entertain a
> merge request which adds an opt-in build profile to enable gpsd support?
> 
> This would make it a little easier for Debianites to experiment with it,
> and then we can revisit whether to enable it by default later down the
> road.

So, I poked upstream, and it turns out Firefox has geoclue support since
version 102 (https://bugzilla.mozilla.org/show_bug.cgi?id=1769664), and
geoclue supports GPS sources...

Mike

Bug#1025043: zookeeper: various improvement ideas for the package

[Christoph Anton Mitterer]

Source: zookeeper
Version: 3.8.0-10
Severity: wishlist

Hey.

While trying out the new packaging of 3.8, I've noticed a number
of things, which seem at least a bit unusual:


1) Using updates-alternatives mechanism, to set up the config.
   That seems quite unsual, and updates-alternatives is even
   documented as:
 "maintain symbolic links determining default commands"
   Commands, not config ;-)


   It would be easy for me to provide a patch which simply drops
   that, but the problem is we need to gracefully handle existing
   installations and properly clean it up there, too.
   Especially without accidentally deleting config. Not sure if this
   is really possibe, or whether we should just add a NEWS.Debian
   entry, telling, that config is now expeceted to bin
   /etc/zookeeer/conf and users must put it there.


2) /etc/zookeeper/conf_example/ (being there, in /etc) and
   /etc/zookeeper/conf being a symlink to that.

   Most packages I know, place *purely* exemplary config somewhere
   in /usr/share/doch//examples

   Whereas, if the config is more than just a *pure* example, but
   a - more or less working - default configu, they'd put it just
   in /etc/zookeeper/ or /etc/zookeeper/conf/ (if that's custom for
   ZK).

   Again, I could try to help, but how're we gonna take care of
   existing installations? Especially since we don't know wheter
   anyone used (1) to mess up, or like I did personally:
   just deleted the symlink and placed a real dir there.


3) There seems to be some mess / duplication between:
 /usr/share/zookeeper/bin/zkEnv.sh
   and
 /etc/zookeeper/conf/environment
   which, I guess, might also be the reason for my:
   #1025012
   because the former would contain the additional CLASSPATH stuff
   I've found out by trying (well, it also doesn't contain the jetty
   stuff).


4) Always found zkServer.sh pretty awkward, especially how it finds
   all the dirs,.. but okay that's upstream so we have to live with it.

   I guess there must be a:
   /var/lib/zookeeper/myid
   and it cannot be directly taken from /etc?
   Woudl be anyway just cosmetic.


5) The example config we ship as a more or less working config (just
   myid is missing) contains:
   dataDir=/tmp/zookeeper

   That's IMO bad. And we should directly use:
   /var/lib/zookeeper ?

   Could prove a PR with a quilt patch that does that.


5b) At some point in time, upstream announced that the `clientPort`
option would be deprecated in favour of:
server. = ::[:role];[:] 
See https://zookeeper.apache.org/doc/r3.5.3-beta/zookeeperReconfig.html

However, upstream itself doesn't really stick with that.
So I guess we should leave that in the config as is for now.


As said I could try to help with some stuff... but would want to know
what you think about these points.
And for some I have no real idea how to do it cleanly.


Thanks,
Chris.

Bug#950386: zookeeperd: missing-systemd-service-for-init.d-script

[Christoph Anton Mitterer]

Hey.

Just a side note on this:

One further problem with the sysvinit script, when via the virtual
systemd units, seems to be, that stopping that unit via systemd does no
necessarily work.

Namely if a connection to zookeeper is still open (e.g. via zkCli) the
daemon continued to run, and closed only after one left zkCli.


Cheers,
Chris.

Bug#1025042: zookeeperd: zookeeper may be started before network and crashes

[Christoph Anton Mitterer]

Control: tags -1 + patch


I've made a simple PR at:
https://salsa.debian.org/java-team/zookeeper/-/merge_requests/8

Cheers,
Chris.

Bug#409272: nfsmount: incompatible with nfsv4--workaround fails

[Ross Boylan]

Package: klibc-utils
Version: 2.0.8-6.1
Followup-For: Bug #409272
X-Debbugs-Cc: rossboy...@stanfordalumni.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Earlier in this bug, Trent Buck suggested an initramfs hook zz-nfs4 to work
around the problem.  I tried it, but I still can't get an NFS 4 mount.

I think the problem is that the script did not copy mount.nfs to nfsmount,
since the 2 files have completely different sizes.  I'm not familiar enough
with the details of hooks for initramfs to understand why.

I installed the script zz-nfs4 and made it executable, then ran
update-initramfs -u -v
and copied the result to where my tftp server could find it.  My server
continues to recieve MNT3 NFS requests, which it denied.

I used unkminitramfs to inspect the initrd.  Here is the file the script wants
to copy, followed by the target:

root@barley:~# ls -l /sbin/mount.nfs
- -rwsr-xr-x 1 root root 114784 Jun 28  2021 /sbin/mount.nfs
root@barley:~# ls -l initramfs/bin/nfs*
- -rwxr-xr-x 1 root root 15232 May 26  2021 initramfs/bin/nfsmount

Obviously different.

I ran update-initramfs within a chroot on the file system (direct, not NFS
mounted) and then used a virtual machine with bridged networking to try to PXE
boot.  I also tried earlier with a physical machine and got similar errors.

I have tried with and without vers as an option on nfsroot for the kernel
invocation, and vers=4 and vers=4.2.  Explicit specification just gets me an
error about an unrecognized option.  I saw some people suggesting this on the
internet, but I note the kernel documentation does *not* list vers as an
available option:
https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt.  Possibly
the documentation is dated.

Onward to making my server respond to NFSv3, I guess


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

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

Versions of packages klibc-utils depends on:
ii  libklibc  2.0.8-6.1

klibc-utils recommends no packages.

klibc-utils suggests no packages.


-BEGIN PGP SIGNATURE-

iQFSBAEBCgA8FiEEreS674/HIyV9gBfdnAYPmOsbK2AFAmOFZT8eHHJvc3Nib3ls
YW5Ac3RhbmZvcmRhbHVtbmkub3JnAAoJEJwGD5jrGytg8m4H/RCxhrS5TGI5QLXu
oNVqTif6+msKN9pCKs7SUBTY18ExwL3+sFBcxq+5bTn0m0ZSvda6sQsXeqg22+I1
FAUo1gX8Xu5Hx3+LtTZpHUzSscjdGcyiCE/Zx7WIYeIwN0uDcXDuJrQWU60S5I1s
vMhQiHxO2tGSww3MS6tbCL+7aFqcwPLFUvIHJcvffl0GvlDkutAUtQdKdp4qpX1/
bNv8fwyWtbIsaB6ThuDoUWUPgCMV+g1MSaSZtJYnc1Ti8hLKyZBGt4+7SM6+FaeW
IVbISwHhaJk+hEsurhXwslYNUe847vFKvQVsuVg7q64tkWnYpGuY6osBkNrDhd1i
YoSOvz4=
=czY4
-END PGP SIGNATURE-

Bug#1025042: zookeeperd: zookeeper may be started before network and crashes

[Christoph Anton Mitterer]

Package: zookeeperd
Version: 3.8.0-10
Severity: important


Hey.

The init.d script doesn't require networking, therefore it may happen.
that e.g. systemd starts zookeeper before the network is brought up,
in which case zookeeper crashes, as it cannot bind to the configured
server.N-option address.

Could be solved either by using e.g.:
# Required-Start:$remote_fs $network
# Required-Stop: $remote_fs $network

or by solving bug #950386 and providing systemd units, which would
make this bug obsole (unless sysvinit compatibility was to be kept).


Cheers,
Chris.

Bug#1025034: linux-image-6.0.0-0.deb11.2-amd64: snd fails on thinkpad

[Moessbauer, Felix]

On Mon, 2022-11-28 at 18:00 -0500, Mark A. Hershberger wrote:
> Package: src:linux
> Version: 6.0.3-1~bpo11+1
> Severity: normal
> 
> I updated to this kernel and sound stopped working. Gnome shows the
> output device (when it is working) as “Speaker - Tiger Lake-LP Smart
> Sound Technology Audio Controller”.

Same issue here, with Lenovo Thinkpad X13.
Information from dmidecode:
Manufacturer: LENOVO
Product Name: 20WLS4VJ07
Version: ThinkPad X13 Gen 2i

With 5.19 everything works properly.

> 
> I found a conversation about a similar bug here:
> 
>  
> https://lore.kernel.org/lkml/3f207f82-e177-c833-b2b0-ca9e64a6e...@linux.intel.com/T/

The reason is well documented in this link and this has already been
fixed upstream in the 6.0.x branch. Don't know if the maintainers want
to update this 6.0 kernel or simply move on to 6.1.

Felix

> 
> -- System Information
> Debian Release: bookworm/sid
> Kernel Version: Linux gabriel 5.19.0-0.deb11.2-amd64 #1 SMP
> PREEMPT_DYNAMIC Debian 5.19.11-1~bpo11+1 (2022-10-03) x86_64
> GNU/Linux
> 

Bug#1007545: NMU: flvstreamer: please consider upgrading to 3.0 source format

[Bastian Germann]

I have uploaded a NMU to fix this. debdiff attached.diff -Nru flvstreamer-2.1c1/debian/changelog flvstreamer-2.1c1/debian/changelog
--- flvstreamer-2.1c1/debian/changelog  2022-11-29 02:15:49.0 +0100
+++ flvstreamer-2.1c1/debian/changelog  2022-11-29 02:11:49.0 +0100
@@ -1,3 +1,13 @@
+flvstreamer (2.1c1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Convert to 3.0 source format (Closes: #1007545)
+
+  [ Helmut Grohne ]
+  * Fix FTCBFS: Let dh_auto_build pass cross compilers (Closes: #850934)
+
+ -- Bastian Germann   Tue, 29 Nov 2022 02:11:49 +0100
+
 flvstreamer (2.1c1-1) unstable; urgency=low
 
   * New upstream release
diff -Nru flvstreamer-2.1c1/debian/rules flvstreamer-2.1c1/debian/rules
--- flvstreamer-2.1c1/debian/rules  2022-11-29 02:15:49.0 +0100
+++ flvstreamer-2.1c1/debian/rules  2022-11-29 02:11:49.0 +0100
@@ -4,7 +4,7 @@
dh $@
 
 override_dh_auto_build:
-   $(MAKE) flvstreamer streams
+   dh_auto_build -- flvstreamer streams
 
 override_dh_installdocs:
dh_installdocs README
diff -Nru flvstreamer-2.1c1/debian/source/format 
flvstreamer-2.1c1/debian/source/format
--- flvstreamer-2.1c1/debian/source/format  1970-01-01 01:00:00.0 
+0100
+++ flvstreamer-2.1c1/debian/source/format  2022-11-29 02:11:36.0 
+0100
@@ -0,0 +1 @@
+3.0 (quilt)

Bug#1024713: ansible-core: Fails autopkgtests in unstable due to new resolvelib

[Lee Garrett]

Hi Scott,

I got around to fix the issue. I took the upstream patch as yours didn't 
apply cleanly to 2.14 anymore. I will upload the package in the next hour.


Thanks for bringing this to my attention!

Regards,
Lee

On 23/11/2022 17:17, Scott Kitterman wrote:

Package: ansible-core
Version: 2.13.4-1
Severity: serious
Tags: patch upstream ftbfs
Justification: fails to build from source (but built successfully in the past)

The current ansible-core package fails autopkgtest in unstable and would
fail in testing if python3-resolvelib were to migrate [1].  The issue
has been fixed upstream [2].  I have tested both on unstable and testing
with the upstream fix using the attached debdiff and it corrects the
test failures.  It also still works with the older resolvelib.

Using the ftbfs tag for this report since it is the closest thing we
have for test failures.

I do intend to NMU in a week to fix this as it blocks testing migration
for python-resolvelib.  Please let me know if you want to take care of
it or your would prefer I go ahead.

Scott K


[1] 
https://ci.debian.net/data/autopkgtest/testing/amd64/a/ansible-core/28587311/log.gz
[2] https://github.com/ansible/ansible/pull/79399/files

Bug#1024999: Please consider to build with LTO enabled

[Gunnar Hjalmarsson]

Hi Mike,

On 2022-11-28 21:09, Mike Gabriel wrote:

Ok. From my side. Please feel free to do team uploads of maliit-*
packages in Debian whenever needed. This should speed up your
procegress.


Thanks for trusting me.

The goal is to make the source possible to autosync on the Ubuntu side, 
so your package updates are reflected also in Ubuntu without any manual 
intervention.


It's a two step thing. I just uploaded maliit-framework 2.3.0-3.1 to 
unstable. It will probably fail to build on most architectures, but that 
will be dealt with in the next upload.


Let's keep our fingers crossed.

--
Gunnar

Bug#1025041: changing patch level on `quilt import -f` doesn't change the patch level

[Lee Garrett]

Package: quilt
Version: 0.66-2.1
Severity: normal
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

when importing a patch with

$ quilt import -P 0009-resolvelib_0_9_0_compat.patch ../../tmp.patch -f -d n

and noticing that the patch level is wrong, the most intuitive next step is to
overwrite the patch with the correct patch level:

$ quilt import -p 0 -P 0009-resolvelib_0_9_0_compat.patch ../../tmp.patch -f -d 
n

However, subsequent import/overwrites will not update the patch level in
debian/patches/series. It would be great if quilt would in the above case also
add "-p0" to the line.

Regards,
Lee

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

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

Versions of packages quilt depends on:
ii  bsdextrautils   2.36.1-8+deb11u1
ii  bsdmainutils12.1.7+nmu3
ii  bzip2   1.0.8-4
ii  diffstat1.64-1
ii  ed  1.17-1
ii  gettext 0.21-4
ii  patch   2.7.6-7
ii  perl5.32.1-4+deb11u2
ii  sensible-utils  0.0.14

Versions of packages quilt recommends:
ii  less  551-2

Versions of packages quilt suggests:
pn  default-mta | mail-transport-agent  
ii  graphviz2.42.2-5
pn  procmail

-- no debconf information

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

[Samuel Thibault]

Arnaud Rebillout, le mer. 23 nov. 2022 08:19:07 +0700, a ecrit:
> Another interesting detail is that restarting espeakup makes it speaks
> again, like if nothing happens. So I think it could be useful to have
> something monitor the daemon and restart it in case it crashes. Would make
> it more reliable overall, I suppose.

Indeed (and debconf does that for its frontend so it's not unseen in d-i
:) ). I have now uploaded that, for a start.

> Unfortunately I'm not familiar with d-i and I couldn't even find from
> *where* espeakup is started (no etc/init.d, no systemd).

There is no init or systemd so we start it by hand from
/lib/debian-installer/startup.d/S51espeakup, installed from
debian/espeakup-udeb.start

Samuel

Bug#1024612: (no subject)

[Thomas Ward]

Response from upstream:


The pastebinit -P option seems to now require an argument even
though the option didn't require one before...

Yes, because 1.) this allows one to both enable and disable private 
pasting via command-line option which wasn't possible before, and 2.) 
there are pastebins that offer multiple levels on private pastes.


...and the docs mention a default.

Yes, like there are defaults on other options that require an argument 
when specified on the command line. So in this case, if you just want 
to make a private paste (and the bin only got one level of privacy), 
since the default is indeed |1| now whereas before private pasting was 
disabled by default, you'd not need to pass the option at all.


Basically, you don't need to specify `-P` at all - it defaults to 
'hidden' by default and does NOT need `-P` specified unless you want to 
change the default privacy level of 1.



This could be better specified in documentation and help output, or with 
a better mechanism to handle options (currently pastebinit is using 
getopt which is considered deprecated and undeveloped, so add this to 
the devel tasks for us upstream to modify this and use argparse or 
similar to better refine options).



Thomas

Bug#1025040: pdns-recursor: Please add support for "riscv64" arch

[Manuel A. Fernandez Montecelo]

Source: pdns-recursor
Version: 4.7.3-2
Severity: wishlist
Tags: ftbfs patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org

Hi,

Please enable this architecture, with the patch attached or an equivalent.

I built it locally on hardware, it built fine just by enabling the architecture
in debian/control, no other changes needed.

Perhaps it should just be set to "any" architectures, unlike what I did with the
patch, because it probably builds fine in other architectures too.


Thanks and cheers.
--
Manuel A. Fernandez Montecelo 
diff -Nru pdns-recursor-4.7.3/debian/changelog 
pdns-recursor-4.7.3/debian/changelog
--- pdns-recursor-4.7.3/debian/changelog2022-11-01 16:50:18.0 
+
+++ pdns-recursor-4.7.3/debian/changelog2022-11-22 17:18:25.0 
+
@@ -1,3 +1,10 @@
+pdns-recursor (4.7.3-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add support for riscv64 arch
+
+ -- Manuel A. Fernandez Montecelo   Tue, 22 Nov 2022 17:18:25 
+
+
 pdns-recursor (4.7.3-2) unstable; urgency=medium
 
   * Set explicit architecture list.
diff -Nru pdns-recursor-4.7.3/debian/control pdns-recursor-4.7.3/debian/control
--- pdns-recursor-4.7.3/debian/control  2022-11-01 16:50:18.0 +
+++ pdns-recursor-4.7.3/debian/control  2022-11-22 17:18:25.0 +
@@ -32,7 +32,7 @@
 Rules-Requires-Root: no
 
 Package: pdns-recursor
-Architecture: amd64 arm64 mips64el ppc64el s390x
+Architecture: amd64 arm64 mips64el ppc64el riscv64 s390x
 Pre-Depends: ${misc:Pre-Depends}
 Depends: adduser,
  dns-root-data,

Bug#1025039: pdns: Please add support for "riscv64" arch

[Manuel A. Fernandez Montecelo]

Source: pdns
Version: 4.7.2-1
Severity: wishlist
Tags: ftbfs patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org

Hi,

Please enable this architecture, with the patch attached or an equivalent.

I built it locally on hardware, it built fine just by enabling the architecture
in debian/control, no other changes needed.

Perhaps it should just be set to "any" architectures, unlike what I did with the
patch, because it probably builds fine in other architectures too.


Thanks and cheers.
--
Manuel A. Fernandez Montecelo 
diff -Nru pdns-4.7.2/debian/changelog pdns-4.7.2/debian/changelog
--- pdns-4.7.2/debian/changelog 2022-11-01 14:24:15.0 +
+++ pdns-4.7.2/debian/changelog 2022-11-22 10:46:12.0 +
@@ -1,3 +1,10 @@
+pdns (4.7.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add support for riscv64 arch
+
+ -- Manuel A. Fernandez Montecelo   Tue, 22 Nov 2022 10:46:12 
+
+
 pdns (4.7.2-1) unstable; urgency=medium
 
   * New upstream version 4.7.2
diff -Nru pdns-4.7.2/debian/control pdns-4.7.2/debian/control
--- pdns-4.7.2/debian/control   2022-11-01 14:24:15.0 +
+++ pdns-4.7.2/debian/control   2022-11-22 10:46:12.0 +
@@ -40,7 +40,7 @@
 Rules-Requires-Root: no
 
 Package: pdns-server
-Architecture: amd64 arm64 mips64el ppc64el s390x
+Architecture: amd64 arm64 mips64el ppc64el riscv64 s390x
 Depends: adduser,
  ${misc:Depends},
  ${shlibs:Depends}
@@ -57,7 +57,7 @@
  serve data.
 
 Package: pdns-tools
-Architecture: amd64 arm64 mips64el ppc64el s390x
+Architecture: amd64 arm64 mips64el ppc64el riscv64 s390x
 Depends: ${misc:Depends},
  ${shlibs:Depends}
 Description: Tools for DNS debugging by PowerDNS
@@ -81,7 +81,7 @@
* saxfr: AXFR zones and show extra information
 
 Package: pdns-ixfrdist
-Architecture: amd64 arm64 mips64el ppc64el s390x
+Architecture: amd64 arm64 mips64el ppc64el riscv64 s390x
 Pre-Depends: ${misc:Pre-Depends}
 Depends: adduser,
  ${misc:Depends},
@@ -93,7 +93,7 @@
  components to work.
 
 Package: pdns-backend-bind
-Architecture: amd64 arm64 mips64el ppc64el s390x
+Architecture: amd64 arm64 mips64el ppc64el riscv64 s390x
 Depends: pdns-server (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
@@ -109,7 +109,7 @@
  of zones needs to be given in a named.conf-style file.
 
 Package: pdns-backend-pipe
-Architecture: amd64 arm64 mips64el ppc64el s390x
+Architecture: amd64 arm64 mips64el ppc64el riscv64 s390x
 Depends: pdns-server (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
@@ -125,7 +125,7 @@
  questions on stdin and returns answers on stdout.
 
 Package: pdns-backend-ldap
-Architecture: amd64 arm64 mips64el ppc64el s390x
+Architecture: amd64 arm64 mips64el ppc64el riscv64 s390x
 Depends: pdns-server (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
@@ -139,7 +139,7 @@
  This package contains the LDAP backend for the PowerDNS nameserver.
 
 Package: pdns-backend-lmdb
-Architecture: amd64 arm64 mips64el ppc64el s390x
+Architecture: amd64 arm64 mips64el ppc64el riscv64 s390x
 Depends: pdns-server (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
@@ -153,7 +153,7 @@
  This package contains the LMDB backend for the PowerDNS nameserver.
 
 Package: pdns-backend-lua2
-Architecture: amd64 arm64 mips64el ppc64el s390x
+Architecture: amd64 arm64 mips64el ppc64el riscv64 s390x
 Depends: pdns-server (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
@@ -167,7 +167,7 @@
  This package contains the Lua2 backend for the PowerDNS nameserver.
 
 Package: pdns-backend-geoip
-Architecture: amd64 arm64 mips64el ppc64el s390x
+Architecture: amd64 arm64 mips64el ppc64el riscv64 s390x
 Depends: pdns-server (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
@@ -184,7 +184,7 @@
  YAML.
 
 Package: pdns-backend-mysql
-Architecture: amd64 arm64 mips64el ppc64el s390x
+Architecture: amd64 arm64 mips64el ppc64el riscv64 s390x
 Depends: pdns-server (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
@@ -200,7 +200,7 @@
  nameserver. It has configurable SQL statements.
 
 Package: pdns-backend-odbc
-Architecture: amd64 arm64 mips64el ppc64el s390x
+Architecture: amd64 arm64 mips64el ppc64el riscv64 s390x
 Depends: pdns-server (>= ${source:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
@@ -215,7 +215,7 @@
  nameserver. It has configurable SQL statements.
 
 Package: pdns-backend-pgsql
-Architecture: amd64 arm64 mips64el ppc64el s390x
+Architecture: amd64 arm64 mips64el ppc64el riscv64 s390x
 Depends: pdns-server (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
@@ -231,7 +231,7 @@
  nameserver. It has configurable SQL statements.
 
 Package: pdns-backend-sqlite3
-Architecture: amd64 arm64 mips64el ppc64el s390x

Bug#1023159: inkscape: crashes opening a pdf file

[Bernhard Übelacker]

Dear Maintainer,
I tried to investigate a little further and think
I have found some details.

When starting inkscape from a terminal and opening the
given PDF shows a "double free" message.

A valgrind run [2] shows the causing lines at a first glance.

On a second look [3] it might be related to
having the PDFDoc object constructed by libpoppler.so.123.
But the deconstructor is called from libpoppler.so.118.

These two versions of lippoppler in the same process seem
to be caused by the old version 1.1.2-3+b1 of inkscape still in testing
and the new version 1.2.1+ds-1 not transitioning
from unstable to testing [4] [6].

Unfortunately libpoppler-glib8 is already in a version in testing
that is pulling the newer libpoppler.so.123 into the process. [5]

As a workaround it might work to install just the inkscape package
from unstable into a testing system. The PDF import worked at least
for me in my test VM without this issue.

Kind regards,
Bernhard



[1]
free(): double free detected in tcache 2



[2]
==1617== Invalid free() / delete / delete[] / realloc()
==1617==at 0x484399B: operator delete(void*, unsigned long) 
(vg_replace_malloc.c:935)
==1617==by 0x75AD734: PDFDoc::~PDFDoc() (PDFDoc.cc:362)
==1617==by 0x77997BD: _poppler_document_new_from_pdfdoc(std::unique_ptr >&&, PDFDoc*, _GError**) 
(poppler-document.cc:148)
==1617==by 0x7799A43: poppler_document_new_from_file 
(poppler-document.cc:232)
...
==1617==  Address 0xe2b4ac0 is 0 bytes inside a block of size 62 free'd
==1617==at 0x484317B: free (vg_replace_malloc.c:872)
==1617==by 0x7799A33: poppler_document_new_from_file 
(poppler-document.cc:230)
...
==1617==  Block was alloc'd at
==1617==at 0x48407B4: malloc (vg_replace_malloc.c:381)
==1617==by 0x61FE678: g_malloc (gmem.c:130)
==1617==by 0x6218C8E: g_strdup (gstrfuncs.c:363)
==1617==by 0x61D75E8: g_filename_from_uri (gconvert.c:1786)
==1617==by 0x77998FA: poppler_document_new_from_file 
(poppler-document.cc:196)
...



[3]
(rr) bt 2
#0  PDFDoc::PDFDoc(std::unique_ptr >&&, std::optional 
const&, std::optional const&, void*, std::function const&) (this=this@entry=0x55746d763710, 
fileNameA=..., ownerPassword=std::optional [no contained value], userPassword=std::optional [no contained 
value], guiDataA=guiDataA@entry=0x0, xrefReconstructedCallback=...) at ./poppler/PDFDoc.cc:127
#1  0x7f31cfa0a9cd in poppler_document_new_from_file(char const*, char const*, 
GError**) (uri=, password=0x0, error=0x0) at 
./glib/poppler-document.cc:223
(More stack frames follow...)
(rr) info symbol $pc
PDFDoc::PDFDoc(std::unique_ptr >&&, std::optional 
const&, std::optional const&, void*, std::function const&) in section .text of 
/lib/x86_64-linux-gnu/libpoppler.so.123
(rr) ptype /o this
type = class PDFDoc {
 private:
/*  0  |   8 */std::unique_ptr fileName;
/*  8  |   8 */std::unique_ptr file;
/* 16  |   8 */BaseStream *str;
...
(rr) cont
...
(rr) bt 2
#0  PDFDoc::~PDFDoc() (this=0x55746d763710, __in_chrg=) at 
./poppler/PDFDoc.cc:334
#1  0x7f31cfa0a7be in _poppler_document_new_from_pdfdoc(std::unique_ptr >&&, PDFDoc*, GError**) (initer=..., 
newDoc=newDoc@entry=0x55746d763710, error=error@entry=0x0) at ./glib/poppler-document.cc:148
(More stack frames follow...)
(rr) info symbol $pc
PDFDoc::~PDFDoc() in section .text of 
/usr/bin/../lib/x86_64-linux-gnu/inkscape/../libpoppler.so.118
(rr) ptype /o this
type = class PDFDoc {
 private:
/*  0  |   8 */const GooString *fileName;
/*  8  |   8 */GooFile *file;
/* 16  |   8 */BaseStream *str;
...



[4]
$ dpkg -l | grep -E "inkscape|poppler"
ii  inkscape   1.1.2-3+b1amd64  
  vector-based drawing program
ii  libpoppler-glib8:amd64 22.08.0-2.1   amd64  
  PDF rendering library (GLib-based shared library)
ii  libpoppler118:amd6422.02.0-3 amd64  
  PDF rendering library
ii  libpoppler123:amd6422.08.0-2.1   amd64  
  PDF rendering library
...



[5]
# libtree /usr/bin/inkscape
/usr/bin/inkscape
├── libinkscape_base.so [runpath]
...
│   ├── libpoppler-glib.so.8 [runpath]
│   │   ├── libpoppler.so.123 [ld.so.conf]
...
│   ├── libpoppler.so.118 [runpath]
...



[6]
https://tracker.debian.org/pkg/inkscape

Bug#1025038: foomatic-filters: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Paulo Henrique de Lima Santana]

Package: foomatic-filters
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
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#1025037: ocsinventory-agent: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Paulo Henrique de Lima Santana]

Package: ocsinventory-agent
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
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#1025036: snort: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Paulo Henrique de Lima Santana]

Package: snort
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

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

Kind regards.

--
Paulo Henrique de Lima Santana (phls)
Belo Horizonte - Brasil
Debian Developer
Associado do Instituto para Conservação de Tecnologias Livres
Site: http://phls.com.br
GPG ID: 0443C450


pt_BR.po.gz
Description: application/gzip


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025035: pastebinit not returning proper URL for pastes going to paste.debian.net

[Thomas Ward]

Package: pastebinit
Severity: serious
Version: 1.6.2-1

(Serious severity selected by Package Maintainer - unfit for release in 
current state)


When using pastebinit to post to the Debian pastebin (default), the 
system returns a plain "https://paste.debian.net; link and NO link to an 
actual paste.


This is a Serious issue in the package and warrants removal from Testing 
until this is dug into and resolved.



Thomas

Bug#1025034: linux-image-6.0.0-0.deb11.2-amd64: snd fails on thinkpad

[Mark A. Hershberger]

Package: src:linux
Version: 6.0.3-1~bpo11+1
Severity: normal

I updated to this kernel and sound stopped working. Gnome shows the
output device (when it is working) as “Speaker - Tiger Lake-LP Smart
Sound Technology Audio Controller”.

I found a conversation about a similar bug here:

https://lore.kernel.org/lkml/3f207f82-e177-c833-b2b0-ca9e64a6e...@linux.intel.com/T/

-- System Information
Debian Release: bookworm/sid
Kernel Version: Linux gabriel 5.19.0-0.deb11.2-amd64 #1 SMP PREEMPT_DYNAMIC 
Debian 5.19.11-1~bpo11+1 (2022-10-03) x86_64 GNU/Linux

-- 
http://hexmode.com/

I cannot remember the books I've read any more than the meals I have eaten;
even so, they have made me.
-- Ralph Waldo Emerson

Bug#1025033: aqemu: Please add support for "riscv64" arch

[Manuel A. Fernandez Montecelo]

Source: aqemu
Version: 0.9.2-3
Severity: wishlist
Tags: ftbfs patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org

Hi,

Please enable this architecture, with the patch attached or an equivalent.

I built it locally on hardware, it built fine just by enabling the architecture
in debian/control, no other changes needed.


In fact, there doesn't seem to be fundamental reasons for this package to be
restricted to specific architectures, so perhaps it should just be set to "any"
as I did with the patch.


Thanks and cheers.
--
Manuel A. Fernandez Montecelo 
diff -Nru aqemu-0.9.2/debian/changelog aqemu-0.9.2/debian/changelog
--- aqemu-0.9.2/debian/changelog2020-12-05 21:45:24.0 +
+++ aqemu-0.9.2/debian/changelog2022-11-28 21:27:17.0 +
@@ -1,3 +1,10 @@
+aqemu (0.9.2-4) UNRELEASED; urgency=medium
+
+  * QA upload.
+  * Add support for riscv64 arch
+
+ -- Manuel A. Fernandez Montecelo   Mon, 28 Nov 2022 21:27:17 
+
+
 aqemu (0.9.2-3) unstable; urgency=medium
 
   * QA upload.
diff -Nru aqemu-0.9.2/debian/control aqemu-0.9.2/debian/control
--- aqemu-0.9.2/debian/control  2020-12-05 21:45:24.0 +
+++ aqemu-0.9.2/debian/control  2022-11-28 21:27:17.0 +
@@ -15,11 +15,11 @@
 Vcs-Browser: https://salsa.debian.org/debian/aqemu
 
 Package: aqemu
-Architecture: amd64 arm arm64 armel armhf hppa i386 ia64 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc powerpcspe ppc64 ppc64el s390x sparc sparc64 
x32
+Architecture: any
 Depends: ${shlibs:Depends},
  ${misc:Depends},
  libqt5dbus5,

Bug#1025032: kicad: Please add support for "riscv64" arch

[Manuel A. Fernandez Montecelo]

Source: kicad
Version: 6.0.9+dfsg-1
Severity: wishlist
Tags: ftbfs patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org

Hi,

Please enable this architecture, with the patch attached or an equivalent.

I built it locally on hardware, it built fine just by enabling the architecture
in debian/control, no other changes needed.


In fact, there doesn't seem to be fundamental reasons for this package to be
restricted to specific architectures, so perhaps it should just be set to "any".


Thanks and cheers.
--
Manuel A. Fernandez Montecelo 
diff -Nru kicad-6.0.9+dfsg/debian/changelog kicad-6.0.9+dfsg/debian/changelog
--- kicad-6.0.9+dfsg/debian/changelog   2022-10-29 11:54:45.0 +
+++ kicad-6.0.9+dfsg/debian/changelog   2022-11-22 10:10:48.0 +
@@ -1,3 +1,10 @@
+kicad (6.0.9+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add support for riscv64 arch
+
+ -- Manuel A. Fernandez Montecelo   Tue, 22 Nov 2022 10:10:48 
+
+
 kicad (6.0.9+dfsg-1) unstable; urgency=medium
 
   * [e85c0b0] New upstream version 6.0.9+dfsg
diff -Nru kicad-6.0.9+dfsg/debian/control kicad-6.0.9+dfsg/debian/control
--- kicad-6.0.9+dfsg/debian/control 2022-10-29 11:41:51.0 +
+++ kicad-6.0.9+dfsg/debian/control 2022-11-22 10:10:48.0 +
@@ -76,7 +76,7 @@
 Homepage: https://www.kicad.org
 
 Package: kicad
-Architecture: any-amd64 any-i386 arm64 armhf mips64el powerpc ppc64 ppc64el
+Architecture: any-amd64 any-i386 arm64 armhf mips64el powerpc ppc64 ppc64el 
riscv64
 Depends:
  libngspice0,
  python3-wxgtk4.0 (>= 4.2.0+dfsg-1~),

Bug#1020851: elpa-ement: fails to install along emacs

[Sean Whitton]

Hello,

On Fri 25 Nov 2022 at 09:47PM +01, Aymeric Agon-Rambosson wrote:

> Hello,
>
> Le vendredi 25 novembre 2022 à 10:31, Sean Whitton 
> a écrit :
>
>> It would?  The highest version is meant to take precedence. That's a
>> feature of package.el.
>
> I run some version of emacs 28.1, which ships xref 1.3.0.
>
> I installed elpa-eglot, which depends on elpa-xref version 1.0.2.
>
> Since then, I have had the following :
>
> (find-library-name "xref")
> "/usr/share/emacs/site-lisp/elpa-src/xref-1.0.2/xref.el"
>
> (locate-library "xref")
> "/usr/share/emacs/site-lisp/elpa/xref-1.0.2/xref.el"
>
> I do have /usr/share/emacs/28.1/lisp/progmodes in my load-path, which is the
> directory containing xref.el.gz.
>
> From what I can see, it would seem that /usr/share/emacs/site-lisp takes
> precedence over /usr/share/emacs/, rather than the highest
> library version.
>
> I'm not sure whether that is intended or not.

My understanding is that this is an upstream bug in Emacs, but ICBW.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1025031: RFS: streamlink/5.1.1-1 -- CLI for extracting video streams from various websites to a video player

[Alexis Murzeau]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "streamlink" for a new
upstream version 5.1.1.

* Package name: streamlink
  Version : 5.1.1-1
  Upstream Author : Streamlink Team
* URL : https://streamlink.github.io/
* License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
  Section : python

It builds those binary packages:

 python3-streamlink - Python module for extracting video streams from
various websites
 python3-streamlink-doc - CLI for extracting video streams from various
websites (documentation)
 streamlink - CLI for extracting video streams from various websites to
a video player

To access further information about this package, please visit the
following URL:
 https://mentors.debian.net/package/streamlink


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

 dget -x 
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_5.1.1-1.dsc

Changes since the last upload to unstable:
streamlink (5.1.1-1) unstable; urgency=medium

   * New upstream version 5.1.1

  -- Alexis Murzeau   Mon, 28 Nov 2022 21:49:55 +0100


Regards,
--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F

























OpenPGP_signature
Description: OpenPGP digital signature

Bug#1024997: install-info: dir entry for emacs is bolloxed

[Barak A. Pearlmutter]

Yes! That fixes it.

Bug#1023788: getfem: fails to build from source on s390x

[Drew Parsons]

severity 1023788 important
thanks

The problem is hidden in 5.4.2+dfsg1-2 by simply skipping tests on 
s390x.


This will enable getfem 5.4 to migrate to testing, so downgrading 
severity. But leaving the bug open since the problematic behaviour still 
needs to be fixed.


Drew

Bug#1024979: please consider enabling gpsd support

[John Scott]

On Tue, 2022-11-29 at 06:44 +0900, Mike Hommey wrote:
> Support compiled in would make libgpsd a hard requirement, which some
> other people would probably complain about. But anyways, the main
> problem is that, as far as I know, it doesn't actually work.
Your reasoning is sound. Thanks for your consideration. I have a
proposition for you. Let's suppose I can get it to work on my local
system (I haven't tried yet; as I'm sure you know, rebuilding Firefox
takes a long time). In that case, would you be willing to entertain a
merge request which adds an opt-in build profile to enable gpsd support?

This would make it a little easier for Debianites to experiment with it,
and then we can revisit whether to enable it by default later down the
road.


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

Bug#1024979: please consider enabling gpsd support

[Mike Hommey]

tag 1024979 + wontfix
thanks

On Mon, Nov 28, 2022 at 04:45:58AM +, John Scott wrote:
> Package: firefox-esr
> Version: 102.4.0esr-1
> Severity: normal
> 
> Hi,
> 
> Firefox has opt-in support for gpsd to determine user location. However, the 
> Debian package doesn't compile in support for it. It should be as easy as 
> configuring with --enable-gpsd and adding the Build-Depends. Even when 
> support is compiled in, this feature is opt-in for the user.

Support compiled in would make libgpsd a hard requirement, which some
other people would probably complain about. But anyways, the main
problem is that, as far as I know, it doesn't actually work.
https://bugzilla.mozilla.org/show_bug.cgi?id=1763347

Mike

Bug#1024997: install-info: dir entry for emacs is bolloxed

[Hilmar Preuße]

Am 28.11.2022 um 15:41 teilte Barak A. Pearlmutter mit:

Hi Barak,


Note the strange characters here that mess up the entry:

$ cat -v /usr/share/info/dir | egrep -2 '[(]emacs[)]'
* Magit: (magit).   Using Git from Emacs with Magit.
* With-Editor: (with-editor).   Using the Emacsclient as $EDITOR.
^ZM-^L}[^EM-^KM-6M-bd^E* Emacs: (emacs).   The extensible 
self-documenting text editor.
* Emacs FAQ: (efaq).Frequently Asked Questions about Emacs.
* Haskell Mode: (haskell-mode). Haskell Development Environment for Emacs(en)



I've uploaded texinfo 7.0 to experimental. Could you test if that
eventually solves the issue?

Hilmar
--
sigfault

Bug#1024637: libmartchus-qtforkawesome1: missing Breaks+Replaces: libmartchus-qtforkawesome0.0.3

[Nicholas D Steeves]

Hi Andreas!

Andreas Beckmann  writes:

> On 27/11/2022 21.11, Nicholas D Steeves wrote:
[snip]
> '/usr/lib/x86_64-linux-gnu/qt5/plugins/iconengines/libmartchus-qtforkawesomeiconengine.so'
> in this case. The majority of library packages don't do this and thus 
> different soversions are co-installable.

Thank you for pointing out that the package in question is unusual.  To
be honest I didn't/don't know if Qt plugins are typically soversioned
or sounversioned.  As a tangent: "sounversioned" sounds like DLL hell ;)

> I'm not sure whether this is avoidable in your case, except by splitting 
> of the plugin(s) into a separate package.
>

For this specific src:package, I feel like a bin:plugin-package
containing a single small file would probably be considered
micropackaging, unless it brought some other benefit.

> Perhaps the documentation should document when B+R are needed (see 
> above) and how this could be avoided. E.g. if libfoo42 needs a datafile 
> /usr/share/foo/bar.dat that
> a) could be moved to a separate package, assuming the datafiles are 
> compatible between all libfooXX

Hm, this seems like it may simultaneously be a Multi-Arch safety
question.

> b) moved to a package specific path, e.g. /usr/share/libfoo42/bar.dat
> if the library is the only user of this file the location/name does not 
> matter and each soversion would happily use its own file
> (I did this in libpapi6.0: /usr/share/papi/6.0/papi_events.csv)
>

That makes sense :) Should this point be qualified with a link to
wiki.d.o/MultiArch/Hints ?  As far as I know, that page is required
reading for "compatible between all libfooXX" questions...ouf, but so
dense...  I would much rather wait for Helmut to file a bug with a
helpful hint!

> Perhaps something like this would help:
> "... unless they are strictly neccessary (i.e. there are unavoidable
>   file conflicts between the packages)"
>
>> documentation seems misleading and bad, unless there is a special
>> exception for library versions involved in a transition.  Does such an
>> exception exist?
> Nope, transitions are not supposed to create more breakage tha normal 
> uploads.
>

Gotcha, so there is no magic.  The way the wiki article reads made me
wonder if there was magic that prevented this breakage...something like
a "ben info" -> file transition bug -> release team gives manual hint to
dak -> dak somehow attaches further instructions to the deb to do a
monkeypatched upgrade when the package is upgraded...of course that's
just imagination, but I still wondered.

[snip]
>
> Is the (only) consumer package in testing (if not, it's no transition)? 

Yes.

> Does a binNMU suffice for the consumer package (binNMU bug might 
> suffice)? Or do you need to upload a new version anyway to make it work 
> with the new version of the library (you upload both at the same time, 
> no transition bug unless there is potential interference with other 
> transitions)?

I discovered the need for the new version of this library (qtforkawesome)
when I packaged new version of the application and saw it ftbfs.

> BTW, you should get an auto-tracker automatically ... it 
> will tell you whether your mini-transition could interfere with other 
> transitions (transition bug if that's relevant).
>

Thank you for this tip! Everything looks clear, and I'm ready to
upload.  I'll wait a max of one week for your reply about updating the
docs before uploading.  Yes, they're two different things, but having an
RC bug hanging over my head functions as a strong reminder to update the
docs haha.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#1023697: Keep out of testing

[Jacob ..]

Thanks Bastian, will take a look at adding the patches on 4.6.0+p1-0+deb11u1.


From: Bastian Germann
Sent: Friday, November 25, 2022 5:25 AM
To: 1023...@bugs.debian.org; 
sirkilam...@msn.com
Subject: Re: Bug#1023697: Keep out of testing

On Tue, 15 Nov 2022 15:27:54 -0800 Felix Lechner  
wrote:
> On Tue, Nov 8, 2022 at 12:00 PM Moritz Muehlenhoff  wrote:
> >
> > open security issues
>
> I also just uploaded a backport for bullseye.

It would be great to address the CVEs with patches on 4.6.0+p1-0+deb11u1.
This would actually be helpful and will maybe convince the Security Team to 
keep wolfSSL in bookworm.
I am not able to identify the fixes for the CVEs quickly but I see that Jacob 
is affiliated with wolfSSL Inc.
so he is probably better equipped to do so. Jacob, would you please do those 
CVE fix backports?

Bug#1022122: node-minimatch 3.0.4+~3.0.3-1+deb11u1 flagged for acceptance

[Paul Gevers]

Hi Yadd,

On Sat, 26 Nov 2022 13:01:22 + Adam D Barratt 
 wrote:

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

Thanks for your contribution!

Upload details
==

Package: node-minimatch
Version: 3.0.4+~3.0.3-1+deb11u1

Explanation: improve protection against regular expression-based denial of 
service [CVE-2022-3517]


The upload breaks [1] the autopkgtest of node-glob. Can you have a look?

Paul

[1] https://ci.debian.net/packages/n/node-glob/stable/amd64/

  4 failing

  1) test/nocase-nomagic.js nocase, nomagic should be equivalent:

  Error: should be equivalent
  + expected - actual

  -[]
  +[
  +  "/TMP/A"
  +  "/TMP/a"
  +  "/tMP/A"
  +  "/tMP/a"
  +  "/tMp/A"
  +  "/tMp/a"
  +  "/tmp/A"
  +  "/tmp/a"
  +]

  at test/nocase-nomagic.js:98:7
  at f (/usr/lib/nodejs/once/once.js:25:25)
  at Glob. (/usr/share/nodejs/glob/glob.js:151:7)
  at Glob._finish (/usr/share/nodejs/glob/glob.js:197:8)
  at done (/usr/share/nodejs/glob/glob.js:182:14)
  at Glob._processSimple2 (/usr/share/nodejs/glob/glob.js:688:12)
  at /usr/share/nodejs/glob/glob.js:676:10
  at Glob._stat2 (/usr/share/nodejs/glob/glob.js:772:12)
  at lstatcb_ (/usr/share/nodejs/glob/glob.js:764:12)
  at RES (/usr/lib/nodejs/inflight/inflight.js:31:16)
  at f (/usr/lib/nodejs/once/once.js:25:25)

  2) test/nocase-nomagic.js nocase, nomagic should be equivalent:

  Error: should be equivalent
  + expected - actual

  -[]
  +[
  +  "/TMP/A"
  +  "/TMP/a"
  +  "/tMP/A"
  +  "/tMP/a"
  +  "/tMp/A"
  +  "/tMp/a"
  +  "/tmp/A"
  +  "/tmp/a"
  +]

  at test/nocase-nomagic.js:108:7
  at f (/usr/lib/nodejs/once/once.js:25:25)
  at Glob. (/usr/share/nodejs/glob/glob.js:151:7)
  at Glob._finish (/usr/share/nodejs/glob/glob.js:197:8)
  at done (/usr/share/nodejs/glob/glob.js:182:14)
  at Glob._processSimple2 (/usr/share/nodejs/glob/glob.js:688:12)
  at /usr/share/nodejs/glob/glob.js:676:10
  at Glob._stat2 (/usr/share/nodejs/glob/glob.js:772:12)
  at lstatcb_ (/usr/share/nodejs/glob/glob.js:764:12)
  at RES (/usr/lib/nodejs/inflight/inflight.js:31:16)
  at f (/usr/lib/nodejs/once/once.js:25:25)

  3) test/nocase-nomagic.js nocase, with some magic should be equivalent:

  Error: should be equivalent
  + expected - actual

   [
  +  "/TMP/A"
  +  "/TMP/a"
  +  "/tMP/A"
  +  "/tMP/a"
  +  "/tMp/A"
  +  "/tMp/a"
 "/tmp/A"
 "/tmp/a"
   ]

  at test/nocase-nomagic.js:137:7
  at f (/usr/lib/nodejs/once/once.js:25:25)
  at Glob. (/usr/share/nodejs/glob/glob.js:151:7)
  at Glob._finish (/usr/share/nodejs/glob/glob.js:197:8)
  at done (/usr/share/nodejs/glob/glob.js:182:14)
  at Glob._processReaddir2 (/usr/share/nodejs/glob/glob.js:434:12)
  at /usr/share/nodejs/glob/glob.js:371:17
  at RES (/usr/lib/nodejs/inflight/inflight.js:31:16)
  at f (/usr/lib/nodejs/once/once.js:25:25)
  at Glob._readdirEntries (/usr/share/nodejs/glob/glob.js:578:10)
  at /usr/share/nodejs/glob/glob.js:555:12
  at test/nocase-nomagic.js:62:9

  4) test/nocase-nomagic.js nocase, with some magic should be equivalent:

  Error: should be equivalent
  + expected - actual

   [
  +  "/TMP/A"
  +  "/TMP/a"
  +  "/tMP/A"
  +  "/tMP/a"
  +  "/tMp/A"
  +  "/tMp/a"
 "/tmp/A"
 "/tmp/a"
   ]

  at test/nocase-nomagic.js:147:7
  at f (/usr/lib/nodejs/once/once.js:25:25)
  at Glob. (/usr/share/nodejs/glob/glob.js:151:7)
  at Glob._finish (/usr/share/nodejs/glob/glob.js:197:8)
  at done (/usr/share/nodejs/glob/glob.js:182:14)
  at Glob._processReaddir2 (/usr/share/nodejs/glob/glob.js:434:12)
  at /usr/share/nodejs/glob/glob.js:371:17
  at RES (/usr/lib/nodejs/inflight/inflight.js:31:16)
  at f (/usr/lib/nodejs/once/once.js:25:25)
  at Glob._readdirEntries (/usr/share/nodejs/glob/glob.js:578:10)
  at /usr/share/nodejs/glob/glob.js:555:12
  at test/nocase-nomagic.js:62:9


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020576: please update sage for pari 2.15.0 and gap 4.12.0

[Tobias Hansen]

On 11/27/22 19:24, Nilesh Patra wrote:
> On Sun, Nov 27, 2022 at 05:35:17PM +, Tobias Hansen wrote:
>> On 11/27/22 06:37, Nilesh Patra wrote:
>>> Tobias, since this is done, would you consider to check sagemath now and 
>>> get the ball rolling? :-) 
>> Hi,
>>
>> I actually tried building with the new pari and gap versions a while ago 
>> (using sagemath 9.5 with upstream patches for the new pari and gap versions, 
>> I pushed them to the git repo today) and got stuck with a lot of errors like 
>> this (might be unrelated to pari and gap):
> I am having a hard time building/reproducing this because sage tends to need 
> a lot of compute power that I currently do not have, and it takes forever to 
> porter box too.
> But looking at the error, my hunch is that this is a setuptools related 
> monkeypatch issue (there are similar RC bugs filed for many packages). So 
> re-ordering cython import
> in sage/misc/cython.py file after setuptools along with ensuring distutils is 
> imported after setuptools will (very) likely help.
>
> Here is a related link that I found for the same
>
>   
> https://stackoverflow.com/questions/21594925/error-each-element-of-ext-modules-option-must-be-an-extension-instance-or-2-t
>
Thanks. The attached patch removed the error, but now there are these warnings 
when cython is used in doctests:

UserWarning: Distutils was imported before Setuptools, but importing Setuptools 
also replaces the `distutils` module in `sys.modules`. This may lead to 
undesirable behaviors or errors. To avoid these issues, avoid using distutils 
directly, ensure that setuptools is installed in the traditional way (e.g. not 
an editable install), and/or make sure that setuptools is always imported 
before distutils.

UserWarning: Setuptools is replacing distutils.

and

DeprecationWarning: msvccompiler is deprecated and slated to be removed in the 
future. Please discontinue use or file an issue with pypa/distutils describing 
your use case.

Best,

Tobias
Description: Import setuptools before cython
 To fix the error
 distutils.errors.DistutilsSetupError: each element of 'ext_modules' option must be an Extension instance or 2-tuple
Author: Tobias Hansen 

--- a/sage/src/sage/misc/cython.py
+++ b/sage/src/sage/misc/cython.py
@@ -285,9 +285,6 @@
 includes = [os.getcwd()] + standard_includes
 
 # Now do the actual build, directly calling Cython and distutils
-from Cython.Build import cythonize
-from Cython.Compiler.Errors import CompileError
-import Cython.Compiler.Options
 
 try:
 # Import setuptools before importing distutils, so that setuptools
@@ -301,6 +298,10 @@
 from distutils.dist import Distribution
 from distutils.core import Extension
 
+from Cython.Build import cythonize
+from Cython.Compiler.Errors import CompileError
+import Cython.Compiler.Options
+
 from distutils.log import set_verbosity
 set_verbosity(verbose)
 

Bug#1025029: python-docutils: (autopkgtest) needs update for python3.11: 'NoneType' object is not subscriptable

[Paul Gevers]

Source: python-docutils
Version: 0.17.1+dfsg-2
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-docutils fails in testing when that autopkgtest is run with the 
binary packages of python3-defaults from unstable. It passes when run 
with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-docutilsfrom testing0.17.1+dfsg-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-docutils/28728887/log.gz

/tmp/autopkgtest-lxc.7f33ovby/downtmp/autopkgtest_tmp/test/test_parsers/test_recommonmark/test_section_headers.py:37: 
DeprecationWarning: invalid escape sequence '\ '

  """\
/tmp/autopkgtest-lxc.7f33ovby/downtmp/autopkgtest_tmp/test/test_parsers/test_recommonmark/test_section_headers.py:50: 
DeprecationWarning: invalid escape sequence '\ '

  """\
/tmp/autopkgtest-lxc.7f33ovby/downtmp/autopkgtest_tmp/test/test_parsers/test_recommonmark/test_section_headers.py:164: 
DeprecationWarning: invalid escape sequence '\ '

  """\
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.7f33ovby/downtmp/autopkgtest_tmp/test/./alltests.py", 
line 88, in 

suite = suite()
^^^
  File 
"/tmp/autopkgtest-lxc.7f33ovby/downtmp/autopkgtest_tmp/test/./alltests.py", 
line 78, in suite

suite = package_unittest.loadTestModules(DocutilsTestSupport.testroot,
^^
  File 
"/tmp/autopkgtest-lxc.7f33ovby/downtmp/autopkgtest_tmp/test/package_unittest.py", 
line 102, in loadTestModules

module = import_module(mod)
 ^^
  File 
"/tmp/autopkgtest-lxc.7f33ovby/downtmp/autopkgtest_tmp/test/package_unittest.py", 
line 133, in import_module

mod = __import__(name)
  
  File 
"/tmp/autopkgtest-lxc.7f33ovby/downtmp/autopkgtest_tmp/test/test_parsers/test_rst/test_directives/test_tables.py", 
line 67, in 
null_bytes_exception = 
DocutilsTestSupport.exception_data(null_bytes)[0]


~~^^^
TypeError: 'NoneType' object is not subscriptable
/tmp/autopkgtest-lxc.7f33ovby/downtmp/autopkgtest_tmp/test/test_parsers/test_recommonmark/test_section_headers.py:37: 
DeprecationWarning: invalid escape sequence '\ '

  """\
/tmp/autopkgtest-lxc.7f33ovby/downtmp/autopkgtest_tmp/test/test_parsers/test_recommonmark/test_section_headers.py:50: 
DeprecationWarning: invalid escape sequence '\ '

  """\
/tmp/autopkgtest-lxc.7f33ovby/downtmp/autopkgtest_tmp/test/test_parsers/test_recommonmark/test_section_headers.py:164: 
DeprecationWarning: invalid escape sequence '\ '

  """\
Testing Docutils 0.17.1 with Python 3.10.8 on 2022-11-27 at 23:02:34
OS: Linux 5.10.0-19-cloud-amd64 #1 SMP Debian 5.10.149-2 (2022-10-21) 
(linux, Linux-5.10.0-19-cloud-amd64-x86_64-with-glibc2.36)
Working directory: 
/tmp/autopkgtest-lxc.7f33ovby/downtmp/autopkgtest_tmp/test

Docutils package: /usr/lib/python3/dist-packages/docutils
test_pickle (test_pickle.PickleTests) ... ok
test_error_handler (test_settings.ConfigEnvVarFileTests) ... ok
test_list (test_settings.ConfigEnvVarFileTests) ... ok
test_list2 (test_settings.ConfigEnvVarFileTests) ... ok


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025030: python-executing: (autopkgtest) needs update for python3.11: RuntimeError

[Paul Gevers]

Source: python-executing
Version: 0.8.0-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-executing fails in testing when that autopkgtest is run with the 
binary packages of python3-defaults from unstable. It passes when run 
with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-executing   from testing0.8.0-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-executing/2872/log.gz

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/executing/executing.py", line 
317, in executing

args = executing_cache[key]
   ~~~^
KeyError: ( at 0x2979bb0, file 
"/tmp/autopkgtest-lxc.dj7n_ez0/downtmp/build.A62/src/tests/test_main.py", 
line 1>, 43490224, 674)


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.dj7n_ez0/downtmp/build.A62/src/tests/test_main.py", 
line 682, in 

assert tester([1, 2, 3]) == [1, 2, 3]
   ^
  File 
"/tmp/autopkgtest-lxc.dj7n_ez0/downtmp/build.A62/src/tests/utils.py", 
line 40, in __call__

ex = self.get_executing(inspect.currentframe().f_back)
 ^
  File 
"/tmp/autopkgtest-lxc.dj7n_ez0/downtmp/build.A62/src/tests/utils.py", 
line 28, in get_executing

return Source.executing(frame)
   ^^^
  File "/usr/lib/python3/dist-packages/executing/executing.py", line 
354, in executing

args = find(source=cls.for_frame(frame), retry_cache=True)
   ^^^
  File "/usr/lib/python3/dist-packages/executing/executing.py", line 
331, in find

node_finder = NodeFinder(frame, stmts, tree, lasti)
  ^
  File "/usr/lib/python3/dist-packages/executing/executing.py", line 
608, in __init__

raise RuntimeError(op_name)
RuntimeError: CALL
autopkgtest [23:02:54]: test unittest



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025028: python-cinderclient: (autopkgtest) needs update for python3.11: conflicting subparser: another-fake-action

[Paul Gevers]

Source: python-cinderclient
Version: 1:9.1.0-2
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-cinderclient fails in testing when that autopkgtest is run with 
the binary packages of python3-defaults from unstable. It passes when 
run with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-cinderclientfrom testing1:9.1.0-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-cinderclient/28728886/log.gz

==
FAIL: 
cinderclient.tests.unit.test_shell.TestLoadVersionedActions.test_load_actions_with_versioned_args

cinderclient.tests.unit.test_shell.TestLoadVersionedActions.test_load_actions_with_versioned_args
--
testtools.testresult.real._StringException: Traceback (most recent call 
last):

  File "/usr/lib/python3.11/unittest/mock.py", line 1369, in patched
return func(*newargs, **newkeywargs)
   ^
  File 
"/tmp/autopkgtest-lxc.sogz78te/downtmp/build.8vO/src/cinderclient/tests/unit/test_shell.py", 
line 538, in test_load_actions_with_versioned_args

shell._find_actions(subparsers, fake_actions_module,
  File 
"/tmp/autopkgtest-lxc.sogz78te/downtmp/build.8vO/src/cinderclient/shell.py", 
line 427, in _find_actions

subparser = subparsers.add_parser(
^^
  File "/usr/lib/python3.11/argparse.py", line 1197, in add_parser
raise ArgumentError(self, _('conflicting subparser: %s') % name)
argparse.ArgumentError: argument : conflicting subparser: 
another-fake-action



==
FAIL: 
cinderclient.tests.unit.test_shell.TestLoadVersionedActions.test_load_versioned_actions

cinderclient.tests.unit.test_shell.TestLoadVersionedActions.test_load_versioned_actions
--
testtools.testresult.real._StringException: Traceback (most recent call 
last):
  File 
"/tmp/autopkgtest-lxc.sogz78te/downtmp/build.8vO/src/cinderclient/tests/unit/test_shell.py", 
line 392, in test_load_versioned_actions

shell._find_actions(subparsers, fake_actions_module,
  File 
"/tmp/autopkgtest-lxc.sogz78te/downtmp/build.8vO/src/cinderclient/shell.py", 
line 427, in _find_actions

subparser = subparsers.add_parser(
^^
  File "/usr/lib/python3.11/argparse.py", line 1197, in add_parser
raise ArgumentError(self, _('conflicting subparser: %s') % name)
argparse.ArgumentError: argument : conflicting subparser: 
fake-action



==
FAIL: cinderclient.tests.unit.test_shell.ShellTest.test_help
cinderclient.tests.unit.test_shell.ShellTest.test_help
--
testtools.testresult.real._StringException: Traceback (most recent call 
last):
  File 
"/tmp/autopkgtest-lxc.sogz78te/downtmp/build.8vO/src/cinderclient/tests/unit/test_shell.py", 
line 129, in test_help

self.assertThat(help_text,
  File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 
478, in assertThat

mismatch_error = self._matchHelper(matchee, matcher, message, verbose)
 ^
  File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 
530, in _matchHelper

mismatch = matcher.match(matchee)
   ^^
  File "/usr/lib/python3/dist-packages/testtools/matchers/_basic.py", 
line 356, in match

if not re.match(self.pattern, value, self.flags):
   ^
  File "/usr/lib/python3.11/re/__init__.py", line 166, in match
return _compile(pattern, flags).match(string)
   
  File "/usr/lib/python3.11/re/__init__.py", line 294, in _compile
p = _compiler.compile(pattern, flags)

Bug#1025027: python-cffi: (autopkgtest) needs update for python3.11: Aborted

[Paul Gevers]

Source: python-cffi
Version: 1.15.1-3
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-cffi fails in testing when that autopkgtest is run with the 
binary packages of python3-defaults from unstable. It passes when run 
with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-cffifrom testing1.15.1-3
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-cffi/28732274/log.gz

(0:04:55) =
=== python3.11-dbg ===
= test session starts 
==

platform linux -- Python 3.11.0+, pytest-7.1.2, pluggy-1.0.0+repack
rootdir: /tmp/autopkgtest-lxc.czowtejq/downtmp/autopkgtest_tmp
collected 2019 items

c/test_c.py  
[  2%]
 
[  6%]
...s...s 
[ 10%]
. 
[ 11%]
testing/cffi0/test_cdata.py . 
[ 11%]
testing/cffi0/test_ctypes.py ..s...s.s.s 
[ 13%]
...s.sss..s..s.. 
[ 17%]
...s 
[ 18%]
testing/cffi0/test_ffi_backend.py ..s... 
[ 20%]
..ss 
[ 23%]
...s...s 
[ 27%]
...s.s...s... 
[ 29%]
testing/cffi0/test_function.py ..s...s.s..ss..sss..ss 
[ 31%]
testing/cffi0/test_model.py . 
[ 31%]
testing/cffi0/test_ownlib.py ..ss...s 
[ 32%]
testing/cffi0/test_parsing.py .s.. 
[ 34%]
testing/cffi0/test_platform.py  
[ 34%]
testing/cffi0/test_unicode_literals.py  
[ 34%]
testing/cffi0/test_verify.py .s.s... 
[ 36%]
 
[ 40%]

..s...sAborted
autopkgtest [23:19:18]: test unittests3



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025026: python-bytecode: (autopkgtest) needs update for python3.11: invalid operation name

[Paul Gevers]

Source: python-bytecode
Version: 0.13.0-2
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-bytecode fails in testing when that autopkgtest is run with the 
binary packages of python3-defaults from unstable. It passes when run 
with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-bytecodefrom testing0.13.0-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-bytecode/28728884/log.gz

=== FAILURES 
===
_ BytecodeTests.test_empty_dup 
_


self = <[AttributeError("'Instr' object has no attribute '_arg'") raised 
in repr()] Instr object at 0x7fcc47774e00>

name = 'DUP_TOP', arg = , lineno = None

def _set(self, name, arg, lineno):
if not isinstance(name, str):
raise TypeError("operation name must be a str")
try:

  opcode = _opcode.opmap[name]

E   KeyError: 'DUP_TOP'

/usr/lib/python3/dist-packages/bytecode/instr.py:233: KeyError

During handling of the above exception, another exception occurred:

self = 

def test_empty_dup(self):
code = Bytecode()
code.first_lineno = 1

  code.extend([Instr("DUP_TOP")])


tests/test_bytecode.py:426: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/usr/lib/python3/dist-packages/bytecode/instr.py:171: in __init__

self._set(name, arg, lineno)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _
self = <[AttributeError("'Instr' object has no attribute '_arg'") raised 
in repr()] Instr object at 0x7fcc47774e00>

name = 'DUP_TOP', arg = , lineno = None

def _set(self, name, arg, lineno):
if not isinstance(name, str):
raise TypeError("operation name must be a str")
try:
opcode = _opcode.opmap[name]
except KeyError:

  raise ValueError("invalid operation name")

E   ValueError: invalid operation name

/usr/lib/python3/dist-packages/bytecode/instr.py:235: ValueError
_ BytecodeTests.test_for_iter_stack_effect_computation 
_


self = <[AttributeError("'Instr' object has no attribute '_arg'") raised 
in repr()] Instr object at 0x7fcc47774ea0>
name = 'JUMP_ABSOLUTE', arg = 0x7fcc4797afe0>

lineno = None

def _set(self, name, arg, lineno):
if not isinstance(name, str):
raise TypeError("operation name must be a str")
try:

  opcode = _opcode.opmap[name]

E   KeyError: 'JUMP_ABSOLUTE'

/usr/lib/python3/dist-packages/bytecode/instr.py:233: KeyError

During handling of the above exception, another exception occurred:

self = testMethod=test_for_iter_stack_effect_computation>


def test_for_iter_stack_effect_computation(self):
with self.subTest():
code = Bytecode()
code.first_lineno = 1
lab1 = Label()
lab2 = Label()
code.extend(
[
lab1,
Instr("FOR_ITER", lab2),
Instr("STORE_FAST", "i"),

  Instr("JUMP_ABSOLUTE", lab1),

lab2,
]
)

tests/test_bytecode.py:472: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/usr/lib/python3/dist-packages/bytecode/instr.py:171: in __init__

self._set(name, arg, lineno)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _
self = <[AttributeError("'Instr' object has no attribute '_arg'") raised 
in repr()] Instr object at 0x7fcc47774ea0>
name = 'JUMP_ABSOLUTE', arg = 0x7fcc4797afe0>

lineno = None

def _set(self, name, arg, lineno):
if not isinstance(name, str):
raise TypeError("operation name must be a str")
try:
opcode = _opcode.opmap[name]
except KeyError:

  raise ValueError("invalid operation name")

E   ValueError: invalid 

Bug#1025012: zookeeper: starts but is completely unusable

[Christoph Anton Mitterer]

And here we go:
CLASSPATH="/etc/zookeeper/conf:/usr/share/java/zookeeper.jar:/usr/share/java/slf4j-log4j12.jar:/usr/share/java/log4j-1.2.jar"

Seems to do the trick to get logging to /var/log/zookeeper/foobar .
The zkCli shows still no prompt, though.

It also needs the /usr/share/java/log4j-1.2.jar, 
/usr/share/java/slf4j-log4j12.jar alone ain't enough.


I wonder a bit whether the classpath is just completely mess up?

When installing, I needed the following dependencies:
[INSTALL, DEPENDENCIES] junit4:amd64 4.13.1-2
[INSTALL, DEPENDENCIES] libactivation-java:amd64 1.2.0-2
[INSTALL, DEPENDENCIES] libapache-pom-java:amd64 18-1
[INSTALL, DEPENDENCIES] libasm-java:amd64 9.1-1
[INSTALL, DEPENDENCIES] libatinject-jsr330-api-java:amd64 1.0+ds1-5
[INSTALL, DEPENDENCIES] libcommons-cli-java:amd64 1.4-2
[INSTALL, DEPENDENCIES] libcommons-io-java:amd64 2.8.0-1
[INSTALL, DEPENDENCIES] libcommons-logging-java:amd64 1.2-2
[INSTALL, DEPENDENCIES] libcommons-parent-java:amd64 43-1
[INSTALL, DEPENDENCIES] libdropwizard-metrics-java:amd64 3.2.6-1
[INSTALL, DEPENDENCIES] libeclipse-jdt-core-java:amd64 3.24.0+eclipse4.18-1
[INSTALL, DEPENDENCIES] libel-api-java:amd64 3.0.0-3
[INSTALL, DEPENDENCIES] libfindbugs-annotations-java:amd64 3.1.0~preview2-3
[INSTALL, DEPENDENCIES] libguava-java:amd64 29.0-6
[INSTALL, DEPENDENCIES] libhamcrest-java:amd64 1.3-9
[INSTALL, DEPENDENCIES] libjackson2-annotations-java:amd64 2.12.1-1
[INSTALL, DEPENDENCIES] libjackson2-core-java:amd64 2.12.1-1
[INSTALL, DEPENDENCIES] libjackson2-databind-java:amd64 2.12.1-1+deb11u1
[INSTALL, DEPENDENCIES] libjaxb-api-java:amd64 2.3.1-1
[INSTALL, DEPENDENCIES] libjctools-java:amd64 2.0.2-1
[INSTALL, DEPENDENCIES] libjetty9-extra-java:amd64 9.4.39-3+deb11u1
[INSTALL, DEPENDENCIES] libjetty9-java:amd64 9.4.39-3+deb11u1
[INSTALL, DEPENDENCIES] libjffi-java:amd64 1.2.7-11
[INSTALL, DEPENDENCIES] libjffi-jni:amd64 1.2.7-11+b1
[INSTALL, DEPENDENCIES] libjnr-constants-java:amd64 0.10.1-1
[INSTALL, DEPENDENCIES] libjnr-enxio-java:amd64 0.32.3-2
[INSTALL, DEPENDENCIES] libjnr-ffi-java:amd64 2.1.7-1
[INSTALL, DEPENDENCIES] libjnr-posix-java:amd64 3.0.45-2
[INSTALL, DEPENDENCIES] libjnr-unixsocket-java:amd64 0.18-4
[INSTALL, DEPENDENCIES] libjnr-x86asm-java:amd64 1.0.2-5.1
[INSTALL, DEPENDENCIES] libjsp-api-java:amd64 2.3.4-3
[INSTALL, DEPENDENCIES] libjsr305-java:amd64 0.1~+svn49-11
[INSTALL, DEPENDENCIES] liblog4j1.2-java:amd64 1.2.17-10+deb11u1
[INSTALL, DEPENDENCIES] libmail-java:amd64 1.6.5-1
[INSTALL, DEPENDENCIES] libnetty-java:amd64 1:4.1.48-4
[INSTALL, DEPENDENCIES] libnetty-tcnative-java:amd64 2.0.28-1
[INSTALL, DEPENDENCIES] libnetty-tcnative-jni:amd64 2.0.28-1
[INSTALL, DEPENDENCIES] libservlet-api-java:amd64 4.0.1-2
[INSTALL, DEPENDENCIES] libservlet3.1-java:amd64 1:4.0.1-2
[INSTALL, DEPENDENCIES] libslf4j-java:amd64 1.7.30-1
[INSTALL, DEPENDENCIES] libsnappy-java:amd64 1.1.8.3-1
[INSTALL, DEPENDENCIES] libsnappy-jni:amd64 1.1.8.3-1
[INSTALL, DEPENDENCIES] libsnappy1v5:amd64 1.1.8-1
[INSTALL, DEPENDENCIES] libspring-beans-java:amd64 4.3.30-1
[INSTALL, DEPENDENCIES] libspring-core-java:amd64 4.3.30-1
[INSTALL, DEPENDENCIES] libtaglibs-standard-impl-java:amd64 1.2.5-2.1
[INSTALL, DEPENDENCIES] libtaglibs-standard-spec-java:amd64 1.2.5-2.1
[INSTALL, DEPENDENCIES] libtomcat9-java:amd64 9.0.43-2~deb11u4
[INSTALL, DEPENDENCIES] libwebsocket-api-java:amd64 1.1-2
[INSTALL, DEPENDENCIES] libzookeeper-java:amd64 3.8.0-10
[INSTALL, DEPENDENCIES] zookeeperd:amd64 3.8.0-10
[INSTALL] zookeeper:amd64 3.8.0-10

Wouldn't there need to be some CLASSPATH settings for more or less all
of them?

I guess there's at least a problem with that:
2022-11-28 21:41:34,760 - WARN  [main:AdminServerFactory@58] - Unable to load 
jetty, not starting JettyAdminServer
java.lang.NoClassDefFoundError: javax/servlet/Servlet
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:315)
at 
org.apache.zookeeper.server.admin.AdminServerFactory.createAdminServer(AdminServerFactory.java:43)
at 
org.apache.zookeeper.server.quorum.QuorumPeer.(QuorumPeer.java:1070)
at 
org.apache.zookeeper.server.quorum.QuorumPeerMain.getQuorumPeer(QuorumPeerMain.java:246)
at 
org.apache.zookeeper.server.quorum.QuorumPeerMain.runFromConfig(QuorumPeerMain.java:177)
at 
org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:137)
at 
org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:91)
Caused by: java.lang.ClassNotFoundException: javax.servlet.Servlet
at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
... 8 more



Thanks,
Chris.

Bug#1025012: zookeeper: starts but is completely unusable

[Christoph Anton Mitterer]

I got a bit further:

Setting:
CLASSPATH="/etc/zookeeper/conf:/usr/share/java/zookeeper.jar:/usr/share/java/slf4j-simple.jar"
i.e. adding the ":/usr/share/java/slf4j-simple.jar" helps a bit...

The server seems to start now, and via zkCli, I can `ls` my paths and
`get` values.

But there's still no logging (neither to file nor to systemd)...


...and zkCli used to show a "prompt" like:
[zk: localhost:2181(CONNECTED) 3] commands go here

but now, there is nothing, though I can enter commands.

May be unrelated though

Bug#1023731: Any idea why debci picks old versions (Was: Bug#1023731: BioC Transition blocked by new dependencies)

[Andreas Tille]

Hi Paul,

Am Mon, Nov 28, 2022 at 08:23:12PM +0100 schrieb Paul Gevers:
> > I'm constantly checking the tracker page of r-bioc-biocgenerics[1] to
> > follow the transition status.  I realised that debci picks old, not yet
> > fixed package versions like:
> > 
> >r-bioc-biocfilecache/2.4.0+dfsg-1 while 2.4.0+dfsg-2 is in unstable
> >r-bioc-biocsingular/1.12.0+ds-1   while 1.14.0+ds-2 is in unstable
> >(I've just uploaded fixed r-bioc-bluster - lets see what will be picked)
> >r-bioc-edaseq/2.30.0+dfsg-1 while 2.32.0+dfsg-2 is in unstable
> 
> It's not debci that picks them, but rather britney (our migration software)
> that doesn't know from the information it uses that r-bioc-biocgenerics from
> unstable makes r-bioc-biocfilecache from testing uninstallable. I haven't
> checked but I suspect that this transition is declared via Provides and this
> *might* mean that britney doesn't handle Provides ideally for this use case.
> 
> > I wonder when debci will be run with the latest versions in unstable
> > that are fixing the build issues.
> 
> *Probably* when bugs in britney regarding this use of Provides are fixed.
> For now, I'll schedule some tests manually with the Release Team
> credentials.

So you want to say, the fact that the current debci results that are
listed on the r-bioc-biocgenerics page are based on packages that are
replaced in unstable and the current packages that are fixed are not
listed with recent debci results, is due to a bug in britney?

Thanks for the manual triggers, hope this will help here

   Andreas.

-- 
http://fam-tille.de

Bug#1025025: ImportError: cannot import name 'Application' from 'cleo'

[Agathe Porte]

Package: python3-poetry
Version: 1.1.14+dfsg-1
Severity: serious
X-Debbugs-Cc: deb...@microjoe.org

Dear Maintainer,

When invoking poetry locally, I get the following error:

Traceback (most recent call last):
  File "/usr/bin/poetry", line 5, in 
from poetry.console import main
  File "/usr/lib/python3/dist-packages/poetry/console/__init__.py", line 1, 
in 
from .application import Application
  File "/usr/lib/python3/dist-packages/poetry/console/application.py", line 
3, in 
from cleo import Application as BaseApplication
ImportError: cannot import name 'Application' from 'cleo' 
(/usr/lib/python3/dist-packages/cleo/__init__.py)

Indeed, the installed python3-cleo package does not seem to have the
'Application' item directly available into its namespace:

Python 3.10.8 (main, Nov  4 2022, 09:21:25) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import cleo
>>> dir(cleo)
['__builtins__', '__cached__', '__doc__', '__file__', '__loader__',
'__name__', '__package__', '__path__', '__spec__', '__version__',
'annotations']
>>>

The latest upstream poetry source code [1] seems to correctly use the
`cleo.application` namespace.

[1] 
https://github.com/python-poetry/poetry/blob/master/src/poetry/console/application.py

Thanks,

Agathe.

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

Kernel: Linux 6.0.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
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

Versions of packages python3-poetry depends on:
ii  python3 3.10.6-3
ii  python3-cachecontrol0.12.12-2
ii  python3-cachy   0.3.0-4
ii  python3-cleo1.0.0a5-1
ii  python3-clikit  0.6.2-3
ii  python3-html5lib1.1-3
ii  python3-importlib-metadata  4.12.0-1
ii  python3-lockfile1:0.12.2-2.2
ii  python3-packaging   21.3-1.1
ii  python3-pexpect 4.8.0-3
ii  python3-pkginfo 1.8.2-1
ii  python3-poetry-core 1.3.2-1
ii  python3-requests2.28.1+dfsg-1
ii  python3-requests-toolbelt   0.9.1-3
ii  python3-shellingham 1.5.0-1
ii  python3-tomlkit 0.11.6-1
ii  python3-virtualenv  20.16.6+ds-1

python3-poetry recommends no packages.

python3-poetry suggests no packages.

-- no debconf information

Bug#1025023: python-boltons: (autopkgtest) needs update for python3.11: new through_method __getstate__?

[Paul Gevers]

Source: python-boltons
Version: 21.0.0-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-boltons fails in testing when that autopkgtest is run with the 
binary packages of python3-defaults from unstable. It passes when run 
with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-boltons from testing21.0.0-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-boltons/28728882/log.gz

=== FAILURES 
===
_ test_frozendict_api 
__


def test_frozendict_api():
# all the read-only methods that are fine
through_methods = ['__class__',
   '__cmp__',
   '__contains__',
   '__delattr__',
   '__dir__',
   '__eq__',
   '__format__',
   '__ge__',
   '__getattribute__',
   '__getitem__',
   '__gt__',
   '__init__',
   '__iter__',
   '__le__',
   '__len__',
   '__lt__',
   '__ne__',
   '__new__',
   '__or__',
   '__reduce__',
   '__reversed__',
   '__ror__',
   '__setattr__',
   '__sizeof__',
   '__str__',
   'copy',
   'get',
   'has_key',
   'items',
   'iteritems',
   'iterkeys',
   'itervalues',
   'keys',
   'values',
   'viewitems',
   'viewkeys',
   'viewvalues']
fd = FrozenDict()
ret = []
for attrname in dir(fd):
if attrname == '_hash':  # in the dir, even before it's set
continue
attr = getattr(fd, attrname)
if not callable(attr):
continue
if getattr(FrozenDict, attrname) == getattr(dict, 
attrname, None) and attrname not in through_methods:

  assert attrname == False

E   AssertionError: assert '__getstate__' == False

tests/test_dictutils.py:515: AssertionError
=== short test summary info 

FAILED tests/test_dictutils.py::test_frozendict_api - AssertionError: 
assert ...
 1 failed, 389 passed in 2.32s 
=

autopkgtest [23:01:36]: test upstream



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025024: python-boto: (autopkgtest) needs update for python3.11: Cannot spec a Mock object

[Paul Gevers]

Source: python-boto
Version: 2.49.0-4
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-boto fails in testing when that autopkgtest is run with the 
binary packages of python3-defaults from unstable. It passes when run 
with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-botofrom testing2.49.0-4
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-boto/28728883/log.gz

...S...S.E...SS..SS...
==
ERROR: test_startElement_with_name_tagSet_calls_ResultSet 
(tests.unit.ec2.test_volume.VolumeTests.test_startElement_with_name_tagSet_calls_ResultSet)

--
Traceback (most recent call last):
  File "/usr/lib/python3.11/unittest/mock.py", line 1369, in patched
return func(*newargs, **newkeywargs)
   ^
  File 
"/tmp/autopkgtest-lxc.q5fss7zd/downtmp/autopkgtest_tmp/tests/unit/ec2/test_volume.py", 
line 58, in test_startElement_with_name_tagSet_calls_ResultSet

result_set = mock.Mock(ResultSet([("item", Tag)]))
 ^
  File "/usr/lib/python3.11/unittest/mock.py", line 1100, in __init__
_safe_super(CallableMixin, self).__init__(
  File "/usr/lib/python3.11/unittest/mock.py", line 451, in __init__
self._mock_add_spec(spec, spec_set, _spec_as_instance, _eat_self)
  File "/usr/lib/python3.11/unittest/mock.py", line 502, in _mock_add_spec
raise InvalidSpecError(f'Cannot spec a Mock object. [object={spec!r}]')
unittest.mock.InvalidSpecError: Cannot spec a Mock object. 
[object=]


--
Ran 1730 tests in 4.059s

FAILED (SKIP=6, errors=1)
autopkgtest [23:01:58]: test unit



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025022: python-bcbio-gff: (autopkgtest) needs update for python3.11: cannot import name '_aligners' from partially initialized module 'Bio.Align'

[Paul Gevers]

Source: python-bcbio-gff
Version: 0.6.9-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-bcbio-gff fails in testing when that autopkgtest is run with the 
binary packages of python3-defaults from unstable. It passes when run 
with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-bcbio-gff   from testing0.6.9-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-bcbio-gff/28728881/log.gz

Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.m7rgvaro/downtmp/autopkgtest_tmp/test_GFFSeqIOFeatureAdder.py", 
line 11, in 

from Bio import SeqIO
  File "/usr/lib/python3/dist-packages/Bio/SeqIO/__init__.py", line 
374, in 

from Bio.Align import MultipleSeqAlignment
  File "/usr/lib/python3/dist-packages/Bio/Align/__init__.py", line 18, 
in 

from Bio.Align import _aligners
ImportError: cannot import name '_aligners' from partially initialized 
module 'Bio.Align' (most likely due to a circular import) 
(/usr/lib/python3/dist-packages/Bio/Align/__init__.py)

autopkgtest [23:01:48]: test run-unit-test



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025021: python-bayespy: (autopkgtest) needs update for python3.11: module 'inspect' has no attribute 'getargspec'

[Paul Gevers]

Source: python-bayespy
Version: 0.5.22-2
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-bayespy fails in testing when that autopkgtest is run with the 
binary packages of python3-defaults from unstable. It passes when run 
with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-bayespy from testing0.5.22-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-bayespy/28728880/log.gz

==
ERROR: test suite for '/usr/lib/python3/dist-packages/bayespy/tests/__init__.py'>

--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/suite.py", line 209, in run
self.setUp()
  File "/usr/lib/python3/dist-packages/nose/suite.py", line 292, in setUp
self.setupContext(ancestor)
  File "/usr/lib/python3/dist-packages/nose/suite.py", line 315, in 
setupContext

try_run(context, names)
  File "/usr/lib/python3/dist-packages/nose/util.py", line 453, in try_run
inspect.getargspec(func)
^^
AttributeError: module 'inspect' has no attribute 'getargspec'

--
Ran 127 tests in 26.429s

FAILED (errors=1)
autopkgtest [23:02:54]: test upstream-unittest



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025019: python-aiosmtpd: (autopkgtest) needs update for python3.11: Can't decode base64

[Paul Gevers]

Source: python-aiosmtpd
Version: 1.4.2-4
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-aiosmtpd fails in testing when that autopkgtest is run with the 
binary packages of python3-defaults from unstable. It passes when run 
with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-aiosmtpdfrom testing1.4.2-4
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-aiosmtpd/28728877/log.gz

=== FAILURES 
===
__ TestSMTPAuth.test_auth_loginteract_warning 
__


self = 
client = 

@handler_data(class_=PeekerHandler)
def test_auth_loginteract_warning(self, client):
client.ehlo("example.com")
resp = client.docmd("AUTH WITH_UNDERSCORE")
assert resp == (334, b"challenge")
with warnings.catch_warnings(record=True) as w:

  assert client.docmd("=") == S.S235_AUTH_SUCCESS
E   assert (501, b"5.5.2...ecode base64") == StatusCode(co...n 
successful')

E At index 0 diff: 501 != 235
E Use -v to get more diff

tests/test_smtp.py:978: AssertionError
-- Captured log setup 
--
INFO mail.log:smtp.py:392 Available AUTH mechanisms: DENYFALSE 
DENYMISSING DONT LOGIN(builtin) NONE NULL PLAIN(builtin) WITH-DASH 
WITH-MULTI-DASH WITH_UNDERSCORE

INFO mail.log:smtp.py:504 Peer: ('::1', 44698, 0, 0)
INFO mail.log:smtp.py:584 ('::1', 44698, 0, 0) handling connection
DEBUGmail.log:smtp.py:570 ('::1', 44698, 0, 0) << b'220 
ci-331-51154d3a Python SMTP 1.4.2'

INFO mail.log:smtp.py:524 ('::1', 44698, 0, 0) EOF received
INFO mail.log:smtp.py:726 ('::1', 44698, 0, 0) Connection lost 
during _handle_client()
INFO mail.log:smtp.py:392 Available AUTH mechanisms: DENYFALSE 
DENYMISSING DONT LOGIN(builtin) NONE NULL PLAIN(builtin) WITH-DASH 
WITH-MULTI-DASH WITH_UNDERSCORE

INFO mail.log:smtp.py:510 ('::1', 44698, 0, 0) connection lost
INFO mail.log:smtp.py:504 Peer: ('::1', 44706, 0, 0)
INFO mail.log:smtp.py:584 ('::1', 44706, 0, 0) handling connection
DEBUGmail.log:smtp.py:570 ('::1', 44706, 0, 0) << b'220 
ci-331-51154d3a Python SMTP 1.4.2'
-- Captured log call 
---
DEBUGmail.log:smtp.py:271 _handle_client readline: b'ehlo 
example.com\r\n'

INFO mail.log:smtp.py:271 ('::1', 44706, 0, 0) >> b'ehlo example.com'
DEBUGmail.log:smtp.py:570 ('::1', 44706, 0, 0) << b'250-ci-331-51154d3a'
DEBUGmail.log:smtp.py:570 ('::1', 44706, 0, 0) << b'250-SIZE 33554432'
DEBUGmail.log:smtp.py:570 ('::1', 44706, 0, 0) << b'250-SMTPUTF8'
DEBUGmail.log:smtp.py:570 ('::1', 44706, 0, 0) << b'250-AUTH 
DENYFALSE DENYMISSING DONT LOGIN NONE NULL PLAIN WITH-DASH 
WITH-MULTI-DASH WITH_UNDERSCORE'

DEBUGmail.log:smtp.py:570 ('::1', 44706, 0, 0) << b'250 HELP'
DEBUGmail.log:smtp.py:271 _handle_client readline: b'AUTH 
WITH_UNDERSCORE\r\n'
INFO mail.log:smtp.py:271 ('::1', 44706, 0, 0) >> b'AUTH 
WITH_UNDERSCORE'

DEBUGmail.log:smtp.py:921 Using handler auth_ hook for 'WITH_UNDERSCORE'
DEBUGmail.log:smtp.py:991 ('::1', 44706, 0, 0) << challenge: b'334 
challenge'

DEBUGmail.log:smtp.py:570 ('::1', 44706, 0, 0) << b'334 challenge'
DEBUGmail.log:smtp.py:997 ('::1', 44706, 0, 0) >> b'=\r\n'
DEBUGmail.log:smtp.py:1007 ('::1', 44706, 0, 0) can't decode base64: 
b'='
DEBUGmail.log:smtp.py:570 ('::1', 44706, 0, 0) << b"501 5.5.2 Can't 
decode base64"

DEBUGmail.log:smtp.py:929 auth_WITH_UNDERSCORE returned '250 OK'
WARNING  mail.log:smtp.py:184 Session.login_data is deprecated and will 
be removed in version 2.0
DEBUGmail.log:smtp.py:570 ('::1', 44706, 0, 0) << b'235 2.7.0 
Authentication successful'
_ TestAuthMechanisms.test_plain1_empty 
_


self = 0x7f5de323b550>
do_auth_plain1 = .do 
at 0x7f5de3a0c0e0>


def test_plain1_empty(self, 

Bug#1025020: python-azure-devtools: (autopkgtest) needs update for python3.11: module 'inspect' has no attribute 'getargspec'

[Paul Gevers]

Source: python-azure-devtools
Version: 1.2.0-3
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-azure-devtools fails in testing when that autopkgtest is run with 
the binary packages of python3-defaults from unstable. It passes when 
run with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-azure-devtools  from testing1.2.0-3
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-azure-devtools/28728879/log.gz

=== FAILURES 
===
_ test_preparer_order 
__


def test_preparer_order():
# Mimic a real test runner, for better compat 2.7 / 3.x
suite = unittest.TestSuite()
suite.addTest(_TestClassSample('example_test'))
unittest.TextTestRunner().run(suite)
>   assert len(traces) == 4
E   AssertionError: assert 3 == 4
E+  where 3 = len(['create A', 'create B', 'remove A'])

tests/test_preparer_order.py:38: AssertionError
- Captured stderr call 
-

E
==
ERROR: example_test 
(tests.test_preparer_order._TestClassSample.example_test)

--
Traceback (most recent call last):
  File 
"/usr/lib/python3/dist-packages/azure_devtools/scenario_tests/preparers.py", 
line 50, in _preparer_wrapper

fn(test_class_instance, **kwargs)
  File 
"/usr/lib/python3/dist-packages/azure_devtools/scenario_tests/preparers.py", 
line 47, in _preparer_wrapper

trim_kwargs_from_test_function(fn, kwargs)
  File 
"/usr/lib/python3/dist-packages/azure_devtools/scenario_tests/utilities.py", 
line 73, in trim_kwargs_from_test_function
args, _, kw, _ = inspect.getargspec(fn)  # pylint: 
disable=deprecated-method

 ^^
AttributeError: module 'inspect' has no attribute 'getargspec'

--
Ran 1 test in 0.001s

FAILED (errors=1)
=== short test summary info 

FAILED tests/test_preparer_order.py::test_preparer_order - 
AssertionError: as...
== 1 failed, 16 passed, 1 deselected in 0.15s 
==

autopkgtest [23:00:54]: test command1



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025017: pymca: (autopkgtest) needs update for python3.11: 'TestPlotWidget' object has no attribute '_feedErrorsToResult'

[Paul Gevers]

Source: pymca
Version: 5.7.2+dfsg-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
pymca fails in testing when that autopkgtest is run with the binary 
packages of python3-defaults from unstable. It passes when run with only 
packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
pymca  from testing5.7.2+dfsg-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pymca/28728876/log.gz


==
ERROR: testShow (WidgetsInstantiationTest.TestPlotWidget.testShow)
--
Traceback (most recent call last):
  File 
"/usr/lib/python3/dist-packages/PyMca5/PyMcaGui/misc/testutils.py", line 
254, in tearDown

if self._currentTestSucceeded():
   
  File 
"/usr/lib/python3/dist-packages/PyMca5/PyMcaGui/misc/testutils.py", line 
207, in _currentTestSucceeded

self._feedErrorsToResult(result, self._outcome.errors)

AttributeError: 'TestPlotWidget' object has no attribute 
'_feedErrorsToResult'


==
ERROR: testShow (WidgetsInstantiationTest.TestPlotWindow.testShow)
--
Traceback (most recent call last):
  File 
"/usr/lib/python3/dist-packages/PyMca5/PyMcaGui/misc/testutils.py", line 
254, in tearDown

if self._currentTestSucceeded():
   
  File 
"/usr/lib/python3/dist-packages/PyMca5/PyMcaGui/misc/testutils.py", line 
207, in _currentTestSucceeded

self._feedErrorsToResult(result, self._outcome.errors)

AttributeError: 'TestPlotWindow' object has no attribute 
'_feedErrorsToResult'


==
ERROR: testShow (WidgetsInstantiationTest.TestRGBCorrelatorGraph.testShow)
--
Traceback (most recent call last):
  File 
"/usr/lib/python3/dist-packages/PyMca5/PyMcaGui/misc/testutils.py", line 
254, in tearDown

if self._currentTestSucceeded():
   
  File 
"/usr/lib/python3/dist-packages/PyMca5/PyMcaGui/misc/testutils.py", line 
207, in _currentTestSucceeded

self._feedErrorsToResult(result, self._outcome.errors)

AttributeError: 'TestRGBCorrelatorGraph' object has no attribute 
'_feedErrorsToResult'


==
ERROR: testShow (WidgetsInstantiationTest.TestRGBCorrelatorWidget.testShow)
--
Traceback (most recent call last):
  File 
"/usr/lib/python3/dist-packages/PyMca5/PyMcaGui/misc/testutils.py", line 
254, in tearDown

if self._currentTestSucceeded():
   
  File 
"/usr/lib/python3/dist-packages/PyMca5/PyMcaGui/misc/testutils.py", line 
207, in _currentTestSucceeded

self._feedErrorsToResult(result, self._outcome.errors)

AttributeError: 'TestRGBCorrelatorWidget' object has no attribute 
'_feedErrorsToResult'


==
ERROR: testShow 
(WidgetsInstantiationTest.TestXASNormalizationWindow.testShow)

--
Traceback (most recent call last):
  File 
"/usr/lib/python3/dist-packages/PyMca5/PyMcaGui/misc/testutils.py", line 
254, in tearDown

if self._currentTestSucceeded():
   
  File 
"/usr/lib/python3/dist-packages/PyMca5/PyMcaGui/misc/testutils.py", line 
207, in _currentTestSucceeded

self._feedErrorsToResult(result, self._outcome.errors)

AttributeError: 'TestXASNormalizationWindow' object has no attribute 
'_feedErrorsToResult'

Bug#1025018: python-aiomeasures: (autopkgtest) needs update for python3.11: module 'asyncio' has no attribute 'coroutine'

[Paul Gevers]

Source: python-aiomeasures
Version: 0.5.14-4
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-aiomeasures fails in testing when that autopkgtest is run with 
the binary packages of python3-defaults from unstable. It passes when 
run with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-aiomeasures from testing0.5.14-4
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-aiomeasures/28727759/log.gz

Testing with python3.11:
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/aiomeasures/__init__.py", line 
9, in 

from .clients import *
  File 
"/usr/lib/python3/dist-packages/aiomeasures/clients/__init__.py", line 
1, in 

from .datadog import Datadog
  File 
"/usr/lib/python3/dist-packages/aiomeasures/clients/datadog/__init__.py", 
line 1, in 

from .client import *
  File 
"/usr/lib/python3/dist-packages/aiomeasures/clients/datadog/client.py", 
line 4, in 

from aiomeasures.clients.bases import Client
  File "/usr/lib/python3/dist-packages/aiomeasures/clients/bases.py", 
line 10, in 

class Client(metaclass=ABCMeta):
  File "/usr/lib/python3/dist-packages/aiomeasures/clients/bases.py", 
line 57, in Client

@asyncio.coroutine
 ^
AttributeError: module 'asyncio' has no attribute 'coroutine'. Did you 
mean: 'coroutines'?

autopkgtest [20:13:44]: test autodep8-python3



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025016: onedrivesdk: (autopkgtest) needs update for python3.11: module 'asyncio' has no attribute 'coroutine'

[Paul Gevers]

Source: onedrivesdk
Version: 1.1.8-3
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
onedrivesdk fails in testing when that autopkgtest is run with the 
binary packages of python3-defaults from unstable. It passes when run 
with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
onedrivesdkfrom testing1.1.8-3
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/o/onedrivesdk/28727756/log.gz

Testing with python3.11:
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/onedrivesdk/__init__.py", line 
42, in 

from .request.drive_request import DriveRequest
  File 
"/usr/lib/python3/dist-packages/onedrivesdk/request/drive_request.py", 
line 13, in 

class DriveRequest(RequestBase):
  File 
"/usr/lib/python3/dist-packages/onedrivesdk/request/drive_request.py", 
line 34, in DriveRequest

@asyncio.coroutine
 ^
AttributeError: module 'asyncio' has no attribute 'coroutine'. Did you 
mean: 'coroutines'?

autopkgtest [20:13:33]: test autodep8-python3



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025015: objgraph: (autopkgtest) needs update for python3.11: graphs have less nodes

[Paul Gevers]

Source: objgraph
Version: 3.5.0-4
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
objgraph fails in testing when that autopkgtest is run with the binary 
packages of python3-defaults from unstable. It passes when run with only 
packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
objgraph   from testing3.5.0-4
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/o/objgraph/28727755/log.gz

=== python3.11 ===
...s.sFFF...
==
FAIL: 
/tmp/autopkgtest-lxc.6f6l_for/downtmp/autopkgtest_tmp/docs/generator-sample.txt

Doctest: generator-sample.txt
--
Traceback (most recent call last):
  File "/usr/lib/python3.11/doctest.py", line 2221, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for generator-sample.txt
  File 
"/tmp/autopkgtest-lxc.6f6l_for/downtmp/autopkgtest_tmp/docs/generator-sample.txt", 
line 0


--
File 
"/tmp/autopkgtest-lxc.6f6l_for/downtmp/autopkgtest_tmp/docs/generator-sample.txt", 
line 43, in generator-sample.txt

Failed example:
objgraph.show_chain(
objgraph.find_backref_chain(objgraph.by_type('Canary')[0],
objgraph.is_proper_module),
filename='canary-chain.png')
Expected:
Graph written to dot (11 nodes)
Image generated as canary-chain.png
Got:
Graph written to /tmp/test-objgraph-f9jou7lt/objgraph-wp5tc5pr.dot 
(9 nodes)

Image generated as canary-chain.png


==
FAIL: 
/tmp/autopkgtest-lxc.6f6l_for/downtmp/autopkgtest_tmp/docs/highlighting.txt

Doctest: highlighting.txt
--
Traceback (most recent call last):
  File "/usr/lib/python3.11/doctest.py", line 2221, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for highlighting.txt
  File 
"/tmp/autopkgtest-lxc.6f6l_for/downtmp/autopkgtest_tmp/docs/highlighting.txt", 
line 0


--
File 
"/tmp/autopkgtest-lxc.6f6l_for/downtmp/autopkgtest_tmp/docs/highlighting.txt", 
line 16, in highlighting.txt

Failed example:
objgraph.show_backrefs(a, max_depth=15,
extra_ignore=[id(locals())],
highlight=lambda x: isinstance(x, Node),
filename='highlight.png')
Expected:
Graph written to dot (12 nodes)
Image generated as highlight.png
Got:
Graph written to /tmp/test-objgraph-zuk_6rtx/objgraph-bbiglbtg.dot 
(8 nodes)

Image generated as highlight.png


==
FAIL: /tmp/autopkgtest-lxc.6f6l_for/downtmp/autopkgtest_tmp/docs/index.txt
Doctest: index.txt
--
Traceback (most recent call last):
  File "/usr/lib/python3.11/doctest.py", line 2221, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for index.txt
  File 
"/tmp/autopkgtest-lxc.6f6l_for/downtmp/autopkgtest_tmp/docs/index.txt", 
line 0


--
File 
"/tmp/autopkgtest-lxc.6f6l_for/downtmp/autopkgtest_tmp/docs/index.txt", 
line 110, in index.txt

Failed example:
objgraph.show_chain(
objgraph.find_backref_chain(
random.choice(objgraph.by_type('MyBigFatObject')),
objgraph.is_proper_module),
filename='chain.png')
Expected:
Graph written to ...dot (13 nodes)
Image generated as chain.png
Got:
Graph written to /tmp/test-objgraph-on6h8uo5/objgraph-5e7is2q7.dot 
(12 nodes)

Image generated as chain.png

Bug#1024969: runit-services: several Dbus services fail to start at boot when this package is installed

[Martin Steigerwald]

Lorenzo - 28.11.22, 01:46:04 CET:
> Hi Martin,
> 
> [ was Re: Runit-services RFS ]
> 
> > Martin Steigerwald  wrote:
> > > 1) Major issue: Once I install runit-services Network Manager is
> > > not started on boot automatically anymore. I tried it on two
> > > laptops. On one I removed runit-services again. Then Network
> > > Manager started again on next reboot. As I use Devuan
> > > network-manager package still has the init script
> > > /etc/init.d/network-manager. In /var/log/boot I have only:
[…]
> > > Another thing I just discovered. The bluetooth related services
> > > are not started when your package runit-services is installed.
> >
> > To summarize: for a runit-init user:
> >  * with this package installed, each service that connects to
> > (depends on) dbus for which there is a sysv service but not a
> > runscript will fail to start at boot, because it's started as sysv
> > script when dbus is still not available. Such services can be
> > started manually later.
> > 
> >  * without this package the sysv-emulation
> > 
> > (/lib/runit/run_sysv_scripts) run sysv scripts at boot in the
> > correct (Sysv) order, so everything works as expected

Do I get this right, that first runit sysv emulation runs the init 
scripts in the correct order and it starts native runit services? Could 
runit be instructed to start at least certain or even all Runit services 
before running the init scripts?

> > So installing this package will make dbus-services that are not
> > included in runit-services, like netwok-manager, bluetoothd and
> > others, fail to start at boot.

> run_sysv_scripts run sysvscripts at boot in the right order, but it
> skips the sysv script when a native runscript with the same name
> exists. This was designed to allow a gradual transition from
> sysvscripts to runscripts; of course it doesn't work with dbus
> because it's at the start of a dependency chain.
> 
> The very quick solution to this is to temporary remove dbus and maybe
> elogind from this package.
> 
> Another solution is to merge dbus services into this package like
> there's no tomorrow.

This has the disadvantage that whenever there is a new DBUS service 
introduced by some package it will fail again until your package "runit-
services" picks it up.

> So Network Manager, Avahi, bluez, wdm, lxdm, gdm3 (not sure gmd3 works
> with elogind). Any other relevant service that I'm not considering?

I remember Devuan installation reports that GNOME works with elogind. 
Not sure whether this was with gdm3 or another display manager.

Best,
-- 
Martin

Bug#1024998: g810-led: Security risk: Leaves /dev/input/event* with read and write permissions for all users

[Stephen Kitt]

Hi,

On Mon, 28 Nov 2022 15:45:16 +0100, Xavi Drudis Ferran 
wrote:
> I hesitate to file as critical, but I came across a bug report in
> upstream that looked serious enough since it would allow all local
> processes to eavesdrop on keyboard input, including passwords, etc. I
> haven't tried an exploit, but it seemed better to just restrict
> /dev/input/event* permissions to those of other event dev files.
> 
> Without this patch, I can read /dev/input/event2 and /dev/input/event3 as a
> normal user. I see bytes in /dev/input/event2 when typing as a normal
> user and also typing in another terminal (Konsole) typing as
> root. event3 only shows the characters typed by the normal user.
> 
> With the patch I can't read /dev/input/event* as a normal user.

Thanks for bringing this up! I’d rather use uaccess, see
https://github.com/MatMoul/g810-led/pull/297

I’ll upload a fixed package shortly and see about a security update for
stable.

Regards,

Stephen


pgpNel_TR6FzR.pgp
Description: OpenPGP digital signature

Bug#1025014: ncbi-acc-download: (autopkgtest) needs update for python3.11: Asked for extended validation, but Biopython not available

[Paul Gevers]

Source: ncbi-acc-download
Version: 0.2.8-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
ncbi-acc-download fails in testing when that autopkgtest is run with the 
binary packages of python3-defaults from unstable. It passes when run 
with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
ncbi-acc-download  from testing0.2.8-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/n/ncbi-acc-download/28727754/log.gz

=== FAILURES 
===
__ test_config_have_biopython 
__


def test_config_have_biopython():
"""Test we detect Biopython."""

  assert core.HAVE_BIOPYTHON

E   assert False
E+  where False = core.HAVE_BIOPYTHON

test_core.py:46: AssertionError
_ test_validate_and_write_extended_validation 
__


req = 

def test_validate_and_write_extended_validation(req):
"""Test extended validation before writing."""
handle = StringIO()
req.get('http://fake/', text=u'>foo\nMAGIC')
r = requests.get('http://fake/')

  config = core.Config(extended_validation='loads', molecule='protein')


test_core.py:226: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ 
/usr/lib/python3/dist-packages/ncbi_acc_download/core.py:64: in __init__

self.extended_validation = extended_validation
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _
self = , value = 
'loads'


@extended_validation.setter
def extended_validation(self, value):
if value != 'none' and not HAVE_BIOPYTHON:

  raise ValueError("Asked for extended validation, but Biopython not 
available")
E   ValueError: Asked for extended validation, but Biopython not 
available


/usr/lib/python3/dist-packages/ncbi_acc_download/core.py:96: ValueError
 test_download_and_validate_partial_wgs 



req = 

def test_download_and_validate_partial_wgs(req):
handle = StringIO(open(full_path('partialcontig.gbk'), 'r').read())

  assert validate.run_extended_validation(handle, 'genbank', 'loads')

E   AssertionError: assert False
E+  where False = 0x7f09f5882c00>(<_io.StringIO object at 0x7f09f5a3e710>, 'genbank', 'loads')
E+where  
= validate.run_extended_validation


test_correct.py:15: AssertionError
_ test_run_extended_validation_raises 
__


monkeypatch = <_pytest.monkeypatch.MonkeyPatch object at 0x7f09f5767850>
mocker = 

def test_run_extended_validation_raises(monkeypatch, mocker):
"""Test the "seqence loads" validator catches exceptions in 
SeqIO.parse()."""

seqio_mock = mocker.MagicMock()
seqio_mock.parse = mocker.MagicMock(side_effect=ValueError)

  monkeypatch.setattr(validate, 'SeqIO', seqio_mock)
E   AttributeError: '/usr/lib/python3/dist-packages/ncbi_acc_download/validate.py'> has no 
attribute 'SeqIO'


test_validate.py:19: AttributeError
__ test_run_extended_validation_loads 
__


def test_run_extended_validation_loads():
"""Test the "sequence loads" validator."""
handle = StringIO(u'>foo\nATGC\n>bar\nATGTGA\n')

  assert validate.run_extended_validation(handle, 'fasta', 'loads')

E   AssertionError: assert False
E+  where False = 0x7f09f5882c00>(<_io.StringIO object at 0x7f09f5a3ecb0>, 'fasta', 'loads')
E+where  
= validate.run_extended_validation


test_validate.py:29: AssertionError
_ test_download_wgs_parts_wgs 
__


req = 

def test_download_wgs_parts_wgs(req):
cfg = Config(format="genbank")
wgs_contig = open(full_path('wgs.gbk'), 'rt')
req.get(ENTREZ_URL, body=open(full_path('wgs_full.gbk'), 'rt'))
outhandle = wgs.download_wgs_parts(wgs_contig, cfg)

Bug#1025013: murano: (autopkgtest) needs update for python3.11: 'NoneType' object has no attribute 'object_store'

[Paul Gevers]

Source: murano
Version: 1:14.0.0-1.1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
murano fails in testing when that autopkgtest is run with the binary 
packages of python3-defaults from unstable. It passes when run with only 
packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
murano from testing1:14.0.0-1.1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/m/murano/28728875/log.gz

/tmp/autopkgtest-lxc.kds0pukh/downtmp/build.RVv/src/murano/db/models.py:292: 
SAWarning: implicitly coercing SELECT object to scalar subquery; please 
use the .scalar_subquery() method to produce a scalar subquery.

  package_count = sa_orm.column_property(
2022-11-27 23:02:40.207 11285 INFO oslo_db.sqlalchemy.provision [-] The 
mysql+pymysql backend is unavailable: (pymysql.err.OperationalError) 
(2003, "Can't connect to MySQL server on 'localhost' ([Errno 111] 
ECONNREFUSED)")

(Background on this error at: https://sqlalche.me/e/14/e3q8)
Exception ignored in: 0x7f987e85d6c0>

Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.kds0pukh/downtmp/build.RVv/src/murano/dsl/murano_object.py", 
line 410, in __del__

self.executor.object_store.schedule_object_destruction(self)
^^
AttributeError: 'NoneType' object has no attribute 'object_store'
Exception ignored in: 0x7f987e85d6c0>

Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.kds0pukh/downtmp/build.RVv/src/murano/dsl/murano_object.py", 
line 410, in __del__

self.executor.object_store.schedule_object_destruction(self)
^^
AttributeError: 'NoneType' object has no attribute 'object_store'
Exception ignored in: 0x7f987e85d6c0>

murano.tests.unit.dsl.test_agent.TestAgent.test_agent_disabled
murano.tests.unit.dsl.test_agent.TestAgent.test_agent_disabled ... ok
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.kds0pukh/downtmp/build.RVv/src/murano/dsl/murano_object.py", 
line 410, in __del__

self.executor.object_store.schedule_object_destruction(self)
^^
2022-11-27 23:02:40.266 11273 WARNING murano.engine.system.agent [None 
dummy-request test_user test_tenant - - - -] Key file %s does not exist. 
Message signing is disabled

AttributeError: 'NoneType' object has no attribute 'object_store'
murano.tests.unit.dsl.test_agent.TestAgent.test_agent_enabled
murano.tests.unit.dsl.test_agent.TestAgent.test_agent_enabled ... ok
2022-11-27 23:02:40.272 11273 WARNING murano.engine.system.agent [None 
dummy-request test_user test_tenant - - - -] Key file %s does not exist. 
Message signing is disabled


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1024999: Please consider to build with LTO enabled

[Mike Gabriel]

Hi Gunnar,

On  Mo 28 Nov 2022 16:12:03 CET, Gunnar Hjalmarsson wrote:


Package: src:maliit-framework
Version: 2.3.0-3
Severity: wishlist
X-Debbugs-Cc: mity...@ubuntu.com

Dear maintainer,

As you know from https://bugs.debian.org/1024593 I'm working with a  
libpinyin transition due to a SONAME bump. The transition has  
completed in Debian, but not yet in Ubuntu.


The problem in Ubuntu proved to be that maliit-framework in Ubuntu  
carries some changes, which prevent autosync and lead to the version  
in Ubuntu being too old. I have just uploaded a merged version:


https://launchpad.net/ubuntu/+source/maliit-framework/2.3.0-3ubuntu1

and hopefully that will lead to the libpinyin transition to complete  
also in Ubuntu.


For the future it would be more convenient if maliit-framework in  
Debian could be changed in a way which allows Ubuntu to simply sync  
the source. Deeming from other C++ packages I'm involved in, I think  
that could be achieved if maliit-framework is built in Debian with  
LTO enabled.


If you approve, I can try to make that change. If you look at the  
latest commits here:


https://salsa.debian.org/input-method-team/marisa/-/commits/master

you get an idea of what I have in mind.

Let me know.


Ok. From my side. Please feel free to do team uploads of maliit-*  
packages in Debian whenever needed. This should speed up your  
procegress.


Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpPigQMOxueM.pgp
Description: Digitale PGP-Signatur

Bug#1025012: zookeeper: starts but is completely unusable

[Christoph Anton Mitterer]

I should perhaps add, that I have installed the zookeeper packages
(zookeeper zookeeperd libzookeeper-java) from testing into stable
(bullseye), all other dependencies were already met with bullseye
versions.

Also, according to https://www.slf4j.org/codes.html#StaticLoggerBinder
and there the question "Failed to load class
org.slf4j.impl.StaticLoggerBinder"... the files "slf4j-nop.jar slf4j-
simple.jar, slf4j-log4j12.jar, slf4j-jdk14.jar or logback-classic.jar"
are needed,... but any except for the latter is in place.

All are in /usr/share/java.

Though manually adding this to the CLASSPATH in
/etc/zookeeper/conf/environment doesn't seem to help.

Bug#1025012: zookeeper: starts but is completely unusable

[Christoph Anton Mitterer]

Package: zookeeper
Version: 3.8.0-10
Severity: grave
Justification: renders package unusable


Hey.

I've tried the new packagin, but while all my config and data files are in 
place,
and while the server "runs", there is no logging (neither to stdout/err for 
systemd
nor /var/log/zookeeper .. not even any files get created in there).

Connecting via zkCli gives:
# /usr/share/zookeeper/bin/zkCli.sh
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further 
details.
Connecting to localhost:2181
Welcome to ZooKeeper!
JLine support is disabled
SLF4J: Failed to load class "org.slf4j.impl.StaticMDCBinder".
SLF4J: Defaulting to no-operation MDCAdapter implementation.
SLF4J: See http://www.slf4j.org/codes.html#no_static_mdc_binder for further 
details.



Perhaps some missing dependency?


Thanks,
Chris.

Bug#1024989: transition: simbody

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2022-11-28 13:42:56 +0200, Andrius Merkys wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hello,
> 
> I would like to request a transition slot for simbody
> (experimental -> unstable) due to soname bump. Current ben tracker [1]
> is OK. All reverse dependencies currently are not in testing:
> 
> * gazebo FTBFS with ffmpeg 5.0 [2], unrelated
> * molmodel builds OK, but needs minor adjustment (I will upload)
> 
> Migration of simbody is blocked by FTBFS on ppc64el, mips64el [3]. I will
> ask to RM packages for these architectures for now.

simbody is not in testing, so you can go ahead with that anytime.

Cheers
-- 
Sebastian Ramacher

Bug#1025011: Keep out of bookworm unless actively maintained

[Moritz Muehlenhoff]

Source: netatalk
Version: 3.1.13~ds-2
Severity: serious

netatalk should not enter bookworm unless it gets adopted and
actively maintained.

Cheers,
Moritz

Bug#1025010: bullseye-pu: package jtreg6/6.1+2-1~deb11u1

[Moritz Muehlenhoff]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: d...@debian.org

openjdk bumped the requirements for the test suite within
their 11.x branch (which is what we ship in Bullseye), it
now needs jtreg6.

The debdiff is relative to the version in bookworm:

Cheers,
Moritz

diff -Nru jtreg6-6.1+2/debian/changelog jtreg6-6.1+2/debian/changelog
--- jtreg6-6.1+2/debian/changelog   2022-07-20 12:40:06.0 +0200
+++ jtreg6-6.1+2/debian/changelog   2022-11-25 17:18:42.0 +0100
@@ -1,3 +1,9 @@
+jtreg6 (6.1+2-1~deb11u1) bullseye; urgency=medium
+
+  * Rebuild for bullseye, needed for latest OpenJDK 11.x release
+
+ -- Moritz Mühlenhoff   Fri, 25 Nov 2022 17:18:42 +0100
+
 jtreg6 (6.1+2-1) unstable; urgency=medium
 
   * New upstream version.

Bug#1010345: ansible: python3-resolvelib >= 0.6.0 breaks Ansible

[Lee Garrett]

Hi Gregor,

can you still reproduce this bug? AFAICS this was fixed in the 2.13.3 
upload.


Additionally, I'll tighten the package dependencies so this issue will 
be more apparent in the future.


Greetings,
Lee

On 29/04/2022 12:01, Gregor Riepl wrote:

Package: ansible
Version: 5.5.0-1
Severity: important
X-Debbugs-Cc: onit...@gmail.com

Dear Maintainer,

Ansible has a strict dependency on resolvelib >=0.5.3 && <0.6.0, which is
documented in the upstream requirements.txt:
https://github.com/ansible/ansible/blob/devel/requirements.txt

Debian bullseye/sid installs 0.8.1, which breaks some functionality in Ansible.

In particular, downloading collections with ansible-galaxy is no longer
possible:

$ ansible-galaxy install -r requirements.yml -vvv
...
Process install dependency map
ERROR! Unexpected Exception, this is probably a bug:
CollectionDependencyProvider.find_matches() got an unexpected keyword argument
'identifier'
the full traceback was:

Traceback (most recent call last):
   File "/usr/bin/ansible-galaxy", line 128, in 
 exit_code = cli.run()
   File "/usr/lib/python3/dist-packages/ansible/cli/galaxy.py", line 569, in run
 return context.CLIARGS['func']()
   File "/usr/lib/python3/dist-packages/ansible/cli/galaxy.py", line 86, in
method_wrapper
 return wrapped_method(*args, **kwargs)
   File "/usr/lib/python3/dist-packages/ansible/cli/galaxy.py", line 1203, in
execute_install
 self._execute_install_collection(
   File "/usr/lib/python3/dist-packages/ansible/cli/galaxy.py", line 1230, in
_execute_install_collection
 install_collections(
   File "/usr/lib/python3/dist-packages/ansible/galaxy/collection/__init__.py",
line 548, in install_collections
 dependency_map = _resolve_depenency_map(
   File "/usr/lib/python3/dist-packages/ansible/galaxy/collection/__init__.py",
line 1364, in _resolve_depenency_map
 return collection_dep_resolver.resolve(
   File "/usr/lib/python3/dist-packages/resolvelib/resolvers.py", line 481, in
resolve
 state = resolution.resolve(requirements, max_rounds=max_rounds)
   File "/usr/lib/python3/dist-packages/resolvelib/resolvers.py", line 348, in
resolve
 self._add_to_criteria(self.state.criteria, r, parent=None)
   File "/usr/lib/python3/dist-packages/resolvelib/resolvers.py", line 147, in
_add_to_criteria
 matches = self._p.find_matches(
TypeError: CollectionDependencyProvider.find_matches() got an unexpected
keyword argument 'identifier'


Related issue: https://bugs.gentoo.org/795933

I'm not aware of a proper patch for this issue.
Gentoo has fixed it by pinning the resolvelib dependency to the requested
version range.


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

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

Versions of packages ansible depends on:
ii  ansible-core   2.12.4-1
ii  openssh-client 1:9.0p1-1
ii  python33.10.4-1
ii  python3-distutils  3.9.12-1
ii  python3-dnspython  2.2.0-2
ii  python3-httplib2   0.20.2-2
ii  python3-jinja2 3.0.3-1
ii  python3-netaddr0.8.0-2
ii  python3-yaml   5.4.1-1+b1

Versions of packages ansible recommends:
ii  python3-argcomplete   1.12.3-0.1
ii  python3-cryptography  3.4.8-1
ii  python3-jmespath  1.0.0-1
ii  python3-kerberos  1.1.14-3.1+b4
ii  python3-libcloud  3.4.1-2
ii  python3-selinux   3.3-1+b2
ii  python3-winrm 0.3.0-2
ii  python3-xmltodict 0.12.0-2

Versions of packages ansible suggests:
pn  cowsay   
ii  sshpass  1.09-1+b1

-- no debconf information

Bug#1023035: gauche: Includes non-free software

[Jens Thiele]

upstream fixed it

fix will be in 0.9.13

Bug#1023731: Any idea why debci picks old versions (Was: Bug#1023731: BioC Transition blocked by new dependencies)

[Paul Gevers]

Hi Andreas,

On 28-11-2022 13:22, Andreas Tille wrote:

I'm constantly checking the tracker page of r-bioc-biocgenerics[1] to
follow the transition status.  I realised that debci picks old, not yet
fixed package versions like:

   r-bioc-biocfilecache/2.4.0+dfsg-1 while 2.4.0+dfsg-2 is in unstable
   r-bioc-biocsingular/1.12.0+ds-1   while 1.14.0+ds-2 is in unstable
   (I've just uploaded fixed r-bioc-bluster - lets see what will be picked)
   r-bioc-edaseq/2.30.0+dfsg-1 while 2.32.0+dfsg-2 is in unstable


It's not debci that picks them, but rather britney (our migration 
software) that doesn't know from the information it uses that 
r-bioc-biocgenerics from unstable makes r-bioc-biocfilecache from 
testing uninstallable. I haven't checked but I suspect that this 
transition is declared via Provides and this *might* mean that britney 
doesn't handle Provides ideally for this use case.



I wonder when debci will be run with the latest versions in unstable
that are fixing the build issues.


*Probably* when bugs in britney regarding this use of Provides are 
fixed. For now, I'll schedule some tests manually with the Release Team 
credentials.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023787: transition: liblxqt

[Paul Gevers]

Hi,

On 28-11-2022 17:50, ChangZhuo Chen (陳昌倬) wrote:

On Tue, Nov 22, 2022 at 09:58:48PM +0100, Paul Gevers wrote:

Hi,

On 21-11-2022 01:05, ChangZhuo Chen (陳昌倬) wrote:

All affected packages have been uploaded to unstable. Sorry for the
mess.


Thanks. Let's see if they can migrate on their own to testing in the
following days.


They do not migrate after 8 days, do we need to do anything?


Yes, bug 1024687 needs fixing.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021846: [programmer11...@programist.ru: Bug#1021846: grub-install is broken since 2.06-3: error: unknown filesystem]

[Robbie Harwood]

Steve McIntyre  writes:

> Hi all!
>
> программист некто (in CC) reported this bug a few weeks back in
> Debian. Since I applied the bundle of filesystem bounds-checking fixes
> a few months back, he can't run grub-install. He's done the work to
> determine that the patch that breaks things for him is
>
> 2d014248d540c7e087934a94b6e7a2aa7fc2c704 fs/f2fs: Do not read past the end of 
> nat journal entries
>
> The full thread of our discussion is at https://bugs.debian.org/1021846
>
> I don't have any knowledge of f2fs to go any further here. Help please! :-)

I don't know much about f2fs either, but has the value of `n` been
captured versus NAT_JOURNAL_ENTRIES in the failing case?  Might be
useful to know how much it's going over by.

Be well,
--Robbie


signature.asc
Description: PGP signature

Bug#1014274: reverse dependencies

[Scott Ashcroft]

Hi,

I've done some work on why the mips64el build fails.
The issue is that the test script tests/sat/grom.ys makes yosys core in
libs/fst/fstapi.cc:fstGetUint32

Looking at the code it is clear that, when FST_DO_MISALIGNED_OPS is not
defined, an address on the stack is returned to calling function.
Because the Debian build uses various hardening flags to protect
accesses to the stack that makes a segfault.

The quick fix appears to be to add:

-DFST_DO_MISALIGNED_OPS

to CPPFLAGS. (i386 and amd64 already have this hardwired in the code.)

I've tested this best I could by cross-compiling and running the binary
under qemu. It passed all the tests in tests/sat.

The real fix would be to either assume that all architectures can run
with FST_DO_MISALIGNED_OPS and remove the broken code or fix
fstGetUint32 so it returns memory allocated correctly, but either of
those is a job for upstream.

Cheers,
Scott

Bug#1024971: pybuild: should fail when the result of running tests is "Ran 0 tests in 0.000s"

[Stefano Rivera]

Hi Louis-Philippe (2022.11.27_23:46:58_+)
> When this happens, the result of the test command typically looks like "Ran
> 0 tests in 0.000s".

I don't think unittest provides an interface to achieve this.

We're probably stuck parsing logs if we want it.

Pytest makes it easy: https://github.com/pytest-dev/pytest/pull/817

SR

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

Bug#1024823: tech-ctte: Call for votes on TC membership of Matthew Garrett

[Niko Tyni]

On Fri, Nov 25, 2022 at 03:39:12PM -0700, Sean Whitton wrote:

> ===BEGIN
> The Technical Committee recommends that Matthew Garrett  be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> H: Recommend to Appoint Matthew Garrett 
> F: Further Discussion
> ===END

I vote: H > F

-- 
Niko


signature.asc
Description: PGP signature

Bug#1025009: emacs: CVE-2022-45939: ctags local command execute vulnerability

[Salvatore Bonaccorso]

Source: emacs
Version: 1:28.2+1-7
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for emacs.

CVE-2022-45939[0]:
| GNU Emacs through 28.2 allows attackers to execute commands via shell
| metacharacters in the name of a source-code file, because lib-
| src/etags.c uses the system C library function in its implementation
| of the ctags program. For example, a victim may use the "ctags *"
| command (suggested in the ctags documentation) in a situation where
| the current working directory has contents that depend on untrusted
| input.


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-45939
https://www.cve.org/CVERecord?id=CVE-2022-45939
[1] 
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=d48bb4874bc6cd3e69c7a15fc3c91cc141025c51

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1025008: deepin-movie-reborn: hardcoded dependency on libmpv1

[Sebastian Ramacher]

Source: deepin-movie-reborn
Version: 5.10.8-1
Severity: serious
Tags: sid bookworm

libmpv is currently transitioning from libmpv1 to libmpv2. Rebuild of
deepin-movie-reborn did not pick up the new dependency on libmpv2 since
it is hardcoded to libmpv1. In general, hardcoding shared library
dependencies is not necessary and if the binaries would be linked
properly, it would be taken care of by ${shlib:Depends}.

The build log indicates that with mpv 0.35.0, the mpv backend is no longer
built.

Cheers
-- 
Sebastian Ramacher

Bug#1004482: liblog4j1.2-java: CVE-2022-23307 CVE-2022-23305 CVE-2022-23302

[Christoph Anton Mitterer]

Hey.

I've just installed this again on some node, and for some reason apt-
listbugs still shows it as open:
# aptitude
Performing actions...
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
grave bugs of liblog4j1.2-java (→ 1.2.17-10+deb11u1) 
 b1 - #1004482 - liblog4j1.2-java: CVE-2022-23307 CVE-2022-23305 CVE-2022-23302 
(Fixed: apache-log4j1.2/1.2.17-11)
Summary:
 liblog4j1.2-java(1 bug)
Are you sure you want to install/upgrade the above packages? [Y/n/?/...] 


But that's the one now installed:
   liblog4j1.2-java 1.2.17-10+deb11u1
which, AFAIU should contain the fixes, right?

Does it need a:
  Control: fixed -1 1.2.17-10+deb11u1
?



Cheers,
Chris.

Bug#672699: ITP: spectrum2 -- XMPP transport/gateway

[Tobias Frost]

Package: wnpp
Followup-For: Bug #672699
Control: tags -1 pending

spectrum2 is now in NEW.

-- 
tobi

Bug#1024943: libgcrypt20: support the noudeb build profile

[Andreas Metzler]

Control: tags -1 pending

On 2022-11-27 Helmut Grohne  wrote:
> Source: libgcrypt20
> Version: 1.10.1-3
> Severity: minor
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap

> libgcrypt20 builds a udeb package. It would be nice to be able to opt
> out of building it via the noudeb build profile. I'm attaching a patch
> for your convenience.

Thank you, applied in GIT.

cu Andreas


signature.asc
Description: PGP signature

Bug#1024697: linux-image-5.10.0-19-cloud-amd64: Please backport fix for Bug #989040 : Missing CONFIG_AMD_MEM_ENCRYPT in kernel

[Salvatore Bonaccorso]

Hi Louis,

On Mon, Nov 28, 2022 at 10:19:16AM +0100, Louis Bouchard wrote:
> Hello Salvatore,
> 
> > I will likely pick that change as well for the next 5.10.y based
> > upload via the upcoming point release (it might count as "enabling
> > furhter hardware support" allowed for stable release updates).
> > 
> > Regards,
> > Salvatore
> 
> This is a very good news.
> 
> Would you happen to have an idea on the timetable for the availability of
> the upcoming 5.10 kernel ?
> 
> I am currently working on building a custom kernel with this option enabled
> so we can make Bullseye available again on our SEV enabled offer until the
> backport becomes available. If it is expected to happen soon, we may elect
> to wait for an official kernel.

The rough plan would be to have it included in the next bullseye point
release. That is scheduled to be on 17th of december[1]. It would be
great to recieve testing feedback actually on the change.

 [1] https://lists.debian.org/debian-live/2022/11/msg6.html

Regards,
Salvatore

Bug#1025007: rust-enumset: please update to v1.0.12

[Jonas Smedegaard]

Source: rust-enumset
Version: 1.0.11-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to newer upstream release v1.0.12.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmOE9dEACgkQLHwxRsGg
ASF8Fw//R0FmtpZUSrYpCkWgLF4B50sWwddYB2NejS9gftMFikrau809SSKHNfDK
d+WQO8v/7Fxeav0ShhL5qJblg5CoYHrRK82wkxm1lzHj70JgJ168osbsd1x81igV
QuagFPZoOZ6/RmeVYpRPeILecNl1fd6zsYnlLms+zry07nvTEeIHtXAhAtFSs9O/
25X+ygAIIktSI3GyTpGhZiSS1FeyeCWGtk0H7Iz7ThXatu16xm2LfbkM6QBepHZ6
heTrLxKqYPO0PNS4fYkFOKLCfXpDbf0yw/T+91CJQz0grDkLjNNkXIS3pGwKWoHk
67vO5uUUQxftyttmwSxuVzNTCRjAK1dkXiATZ4jWmrPswzbg98WvBXZ0XaDtTfml
OqA3jUZ6XRRo7iu0PG+dReGg6Zrl1nvi6fwHZq2nihdmyMaVgaH6QxVFTpUBi3nL
j5HE8HFzNKkuseb6b1OirvAdm3Bmz6+BMlibpzFuGSTCzZuzItuHU4Ly0i+VJE6D
ipY8zBBtQpyQabtrqQchGshEw2gT2EgSVtEA0ueV+VyxtJBayI4RcMB/aBaGuy5z
K3GyuzAHSMmIkWeYbi1xllyndP/Dv3fB8PblmiSTv2dLwiE1FrH1+dMUU5ejHdtZ
vUDC8Luhh5VafqInYbiJcEgjDCFfbr0Si1KSYiCmb8/XuH5BX2U=
=9cBF
-END PGP SIGNATURE-

Bug#982140: ITP: fuzzel -- Wayland-native application launcher

[Antoine Beaupré]

So this is now in unstable, but blocked from migrating because it was a
binary upload.

I'm happy to do a new source-only upload, but are there other changes
you have pending we could bundle up in there?

thanks
-- 
Seul a un caractère scientifique ce qui peut être réfuté. Ce qui n'est
pas réfutable relève de la magie ou de la mystique.
- Karl Popper

Bug#1025006: rust-console-error-panic-hook: please update to v0.1.7

[Jonas Smedegaard]

Source: rust-console-error-panic-hook
Version: 0.1.6-2
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to newer upstream release v0.1.7.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmOE62EACgkQLHwxRsGg
ASG2hQ//ZG10Q6Y+FEJ0B2FPfxIU3KXkZvFOkdyqBSParmxJM/ay1WxXL0pbcfTA
BUvtneiuvGPy6ic61x9Ix+RiUdu9G8L6e5yqBauT6qUlIeciaS9YYn8JzLVZiCok
N5EtK6LA6Ukr0p4v8v+xuBwM7RrFTtdftSedcdx5WNe3I5ScVnAVCP69J6NBL8lm
5iJUwC6tlmjBLdkaWBJsGizHTVw3pwbrVycAN0dYpD16GIYqUnXyG9Sz0hNQh4cl
HUKOl6w2aqtW/D+cL9LW9ao4UQmC55DGV82ahxDXY+b6Qkuz+R5T8SH08oyo25kD
fM1PZ6+L8C+u9vT0fNxeFzhFIsF3vd5f3MeSabIf1nSXy9hqwq0+ZDQo7u9NTxoB
mdouri+hZMWxO5JbByqs5uHTArFLwGeqca5gU0oBxZQkBo7xScui1zbw66ONrakN
VhXoWHsjkq9mprucdMAJfNx0zeg/tsg7UUQPJ5Zjt1YgsZBUP3YfCy/8NE9ez9QO
IvnQ3PVjdmMNpBW8Gy1/1BxrcpWuNgzKCb24dpD7n0R4NM+NzIEZqf8u/EBQXQzy
2YbcoIJh/mfPcEehFcMhIZSvnya1aBi3EOwLVSZ6OV1kfl7auKAfbCQ0bcsRBGcd
+OKx2PzEsePzDyJ6yYElqY+kL5NIBuHfc/jsB3lRoupmhqZNd6U=
=V+Qq
-END PGP SIGNATURE-

Bug#1023035: gauche: Includes non-free software

[Bastian Germann]

Then please document and comment this in d/copyright.

If the content of the file has changed with the version that is under a new 
license
you have to replace the file instead.

Bug#1023787: transition: liblxqt

[陳昌倬]

On Tue, Nov 22, 2022 at 09:58:48PM +0100, Paul Gevers wrote:
> Hi,
> 
> On 21-11-2022 01:05, ChangZhuo Chen (陳昌倬) wrote:
> > All affected packages have been uploaded to unstable. Sorry for the
> > mess.
> 
> Thanks. Let's see if they can migrate on their own to testing in the
> following days.

They do not migrate after 8 days, do we need to do anything?


-- 
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#1023035: gauche: Includes non-free software

[Jens Thiele]

Bastian Germann  writes:

> Source: gauche
> Severity: serious
> Version: 0.9.10-3
>
> debian/ext/srfi/srfi-19.scm has a license that reads "However, this document 
> itself may not be modified in any way"
> and is documented in d/copyright for lib/srfi-11.scm, which does not
> have that license (anymore). This clause makes the license
> non-free. Please remove files that are non-free or move the package to
> the non-free archive section.

current srfi-19.scm license [0] reads
"
;; SRFI-19: Time Data Types and Procedures.
;;
;; Copyright (C) I/NET, Inc. (2000, 2002, 2003). All Rights Reserved.
;;
;; Permission is hereby granted, free of charge, to any person obtaining
;; a copy of this software and associated documentation files (the
;; "Software"), to deal in the Software without restriction, including
;; without limitation the rights to use, copy, modify, merge, publish,
;; distribute, sublicense, and/or sell copies of the Software, and to
;; permit persons to whom the Software is furnished to do so, subject to
;; the following conditions:
;;
;; The above copyright notice and this permission notice shall be
;; included in all copies or substantial portions of the Software.
;;
;; THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
;; EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
;; MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
;; NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
;; LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
;; OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
;; WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
"

[0] https://srfi.schemers.org/srfi-19/srfi-19.scm

Bug#1024905: minidlna: new upstream version

[Barak A. Pearlmutter]

Just to be clear: I didn't get a chance yet to, like, actually test it.

Bug#1025005: rust-vergen: please upgrade to v7.3.2

[Jonas Smedegaard]

Source: rust-vergen
Version: 6.0.2-3
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to newer upstream release v7.3.2.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmOE458ACgkQLHwxRsGg
ASGCTg/+PxdshZ+6NdDbI8R32zXsQtxPDePXPkoq4XWDFaY0UTdP3KwCRXKV5ee5
GrLUm7OuEa0WwZa9VuBCpClpIRimJisdzrTQJj9omw77TWkvBLhX3Un2n7hOs8kr
z7bolE/EqzCABXAMh1TUSkno+URvtWB3nX3feVaq04BUGXFG2dWRkOWKGXKa0PoD
HgQ2MttV7OI2btTe8hGkL2c03OcgDvNtdY5qRbayj0PDtsd015dGDifyObDKYDOK
Xyq7nrciVna/0zXnZwXovdxdRHfTq71PTrSC1Zu3SN9ChGomzs+Bc01EaK9iz9Rz
N3MSoVUKwkk/UKcOLyKv/lQj2RBSB2glBqJZTZakHOxzxoAetq50cTTLIv1bHu1v
tntLm/ofBKEL/5W5Bu0d280LaWqf3sLe4Z+0H3VzFuWYsuGlN484Ez9NyiyBX00I
JHJi9yLozcbsNr8mwQ0xZZysptE0ZnrwKfqTbefLBFcWXQRAauLkThXvg9VDoRSF
/zb6RuMjz1h+G61CLLfLaDIMO8pSllWdhAr++GQBEzgZVidd9+FS+8CAOb/SV98W
Nz9JUyb1zjM8mNhUnsgiw2lgup1zciSw63CjQwUmq8I2A6rAJ8s9XeKSb7t3lwT5
Y5/VCwNHRjIF2r1nVyuBIDeDFusJUE/6JpByIfer+MJaUGY61i0=
=IQjU
-END PGP SIGNATURE-

Bug#1023386: pacman-package-manager: Please backport to bullseye-backports

[Ben Westover]

Bonjour Dylan,

On 11/22/22 04:09, Dylan Aïssi wrote:
> I just uploaded ppm 6.0.2-3~bpo11+1 to bullseye-backports with a delay of
> 6 days to be sure 6.0.2-3 lands in bookworm first.
>
> I also reverted 2e079e6d because this change is not in 6.0.2-3.

That commit was needed for the libraries to present the right version;
without it, the their Debian revision is -3 which conflicts with the
existing unstable/testing version of the package. That's why your upload
just got rejected.

Thanks,
--
Ben Westover


OpenPGP_signature
Description: PGP signature

Bug#1025004: dash: errors in sourced functions reported against wrong files

[Aaron M. Ucko]

Package: dash
Version: 0.5.11+git20210903+057cd650a4ed-9
Severity: normal

I have found that dash defers "bad substitution" errors until actually
attempting to evaluate the substitution in question.  That in itself
is plausibly legitimate, particularly given that bash does the same.

However, when such an error stems from a function defined in a sourced
file, dash cites it as coming from the file corresponding to the top
of the call stack, albeit with a line number indicating the relevant
line of the sourced file.

Could you please take a look?

Thanks!

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

Kernel: Linux 6.0.0-4-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 dash depends on:
ii  debianutils  5.7-0.4
ii  dpkg 1.21.9+b1
ii  libc62.36-5

dash recommends no packages.

dash suggests no packages.

-- debconf-show failed

Bug#1023196: fet: new version 6.7.0 available

[Alex Muntada]

Hi Gianfranco,

> Hello, please consider updating to version 6.7.0, capable of
> building with qt6 too, including new feature and bug fixes.

I just uploaded 6.7.3, that closed this bug. FYI, I tried to
build fet with Qt6 and failed. Then I decided to upgrade the
package with Qt5 first, polish a few packaging details and try
to build it with Qt6 next time.

It turns out that the build is missing qmake (FWIW, I've been
comparing debian/control from other Qt6 enabled packages because
I couldn't find any best practices on the KDE/Qt Team website).
Let me know if you can figure it out.

Cheers,
Alex

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature

Bug#1024991: RFS: jamulus/3.9.1+dfsg-1 [QA] -- real-time collaborative music session client and server

[Bo YU]

Package: sponsorship-requests
Followup-For: Bug #1024991

Hi,

According to #1024984
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024984#10

Now it is not suitable to add support for riscv64 arch.
So I have updated it again:

Changes since the last upload:

 jamulus (3.9.1+dfsg-1) unstable; urgency=medium
 .
   * QA upload.
   * Set Debian QA as maintainer. See #1023670.
   * New upstream version 3.9.1.
   * Update d/copyright:
 - adjust Files-Excluded due to repack.
 - update file-pattern due to upstream change.
   * Rebase all patches.
   * Adjust d/source/lintian-overrides
   * Update execute_after_dh_auto_install

Please let me know if there is any issues.

-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1025003: pocl-opencl-icd: segfault (llvm version confusion) with mesa-opencl-icd

[Claude Heiland-Allen]

Package: pocl-opencl-icd
Version: 3.0-7
Severity: normal
X-Debbugs-Cc: cla...@mathr.co.uk

Dear Maintainer,

   * What led up to the situation?

I have a program that uses OpenCL,
including simultaneous use of multiple platforms and devices.

When mesa-opencl-icd (Clover) is installed,
usage of pocl-opencl-icd (PoCL) segfaults.

The backtrace reveals
PoCL calls LLVM 13,
but somehow things get confused inside and
LLVM 13 calls LLVM 15
which causes a crash.
LLVM 15 is linked by mesa-opencl-icd.

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

Workaround to get functioning OpenCL:

Either uninstall mesa-opencl-icd,
and use pocl-opencl-icd for OpenCL,
or uninstall pocl-opencl-icd and libpocl2,
and use mesa-opencl-icd for OpenCL.

   * What outcome did you expect instead?

It would be great if pocl-opencl-icd could be used
at the same time as mesa-opencl-icd.

I don't know how the dynamic library linking works,
but maybe upgrading to LLVM 15 as used by mesa-opencl-icd
would mask the issue?


GDB Backtrace:

---8<---
(gdb) run
...
Thread 55 "fraktaler-3.gcc" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffab7fe6c0 (LWP 68040)]
0x7fffed0d1528 in 
llvm::AnalysisManager::getResultImpl(llvm::AnalysisKey*, 
llvm::Function&) () from /lib/x86_64-linux-gnu/libLLVM-15.so.1
(gdb) bt
#0  0x7fffed0d1528 in 
llvm::AnalysisManager::getResultImpl(llvm::AnalysisKey*, 
llvm::Function&) () from /lib/x86_64-linux-gnu/libLLVM-15.so.1
#1  0x7fffed0d13ca in 
llvm::AnalysisManager::getResultImpl(llvm::AnalysisKey*, 
llvm::Function&) () from /lib/x86_64-linux-gnu/libLLVM-15.so.1
#2  0x7fffee2749b6 in llvm::AAManager::run(llvm::Function&, 
llvm::AnalysisManager&) () from 
/lib/x86_64-linux-gnu/libLLVM-15.so.1
#3  0x7fffee52242b in ?? () from /lib/x86_64-linux-gnu/libLLVM-15.so.1
#4  0x7fff8375aba1 in 
llvm::AnalysisManager::getResultImpl(llvm::AnalysisKey*, 
llvm::Function&) () from /lib/x86_64-linux-gnu/libLLVM-13.so.1
#5  0x7fff841710e1 in llvm::InstCombinePass::run(llvm::Function&, 
llvm::AnalysisManager&) () from 
/lib/x86_64-linux-gnu/libLLVM-13.so.1
#6  0x7fff85cd3a9d in ?? () from /lib/x86_64-linux-gnu/libLLVM-13.so.1
#7  0x7fff8375841e in llvm::PassManager>::run(llvm::Function&, 
llvm::AnalysisManager&) () from 
/lib/x86_64-linux-gnu/libLLVM-13.so.1
#8  0x7fff8507e74d in ?? () from /lib/x86_64-linux-gnu/libLLVM-13.so.1
#9  0x7fff8375bf7a in llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, 
llvm::AnalysisManager&) () from 
/lib/x86_64-linux-gnu/libLLVM-13.so.1
#10 0x7fff8507e58d in ?? () from /lib/x86_64-linux-gnu/libLLVM-13.so.1
#11 0x7fff8375717e in llvm::PassManager>::run(llvm::Module&, 
llvm::AnalysisManager&) () from 
/lib/x86_64-linux-gnu/libLLVM-13.so.1
#12 0x7fff8a18270f in ?? () from /lib/x86_64-linux-gnu/libclang-cpp.so.13
#13 0x7fff8a17cf40 in clang::EmitBackendOutput(clang::DiagnosticsEngine&, 
clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, 
clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, 
llvm::Module*, clang::BackendAction, std::unique_ptr >) () from 
/lib/x86_64-linux-gnu/libclang-cpp.so.13
#14 0x7fff8a43fefe in ?? () from /lib/x86_64-linux-gnu/libclang-cpp.so.13
#15 0x7fff8941e794 in clang::ParseAST(clang::Sema&, bool, bool) () from 
/lib/x86_64-linux-gnu/libclang-cpp.so.13
#16 0x7fff8a43c6d1 in clang::CodeGenAction::ExecuteAction() () from 
/lib/x86_64-linux-gnu/libclang-cpp.so.13
#17 0x7fff8ac854a6 in clang::FrontendAction::Execute() () from 
/lib/x86_64-linux-gnu/libclang-cpp.so.13
#18 0x7fff8abfeca6 in 
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) () from 
/lib/x86_64-linux-gnu/libclang-cpp.so.13
#19 0x7fffa97acf86 in ?? () from /lib/x86_64-linux-gnu/libpocl.so.2.9.0
#20 0x7fffa973ed40 in ?? () from /lib/x86_64-linux-gnu/libpocl.so.2.9.0
#21 0x7fffa973d88c in ?? () from /lib/x86_64-linux-gnu/libpocl.so.2.9.0
#22 0x5563d383 in opencl_get_kernel 
(context=context@entry=0x7fffac001070, nt=nt@entry=nt_double, par=...) at 
src/opencl.cc:319
#23 0x5564bfd6 in render_device (queue=..., nt=nt_double, device=..., 
par=..., h=, ref_recalculated=, 
bla_recalculated=true, running=0x5578e9a6 ) at src/render.cc:137
#24 0x5564e58c in operator() (device=, 
__closure=0x7fffc5a9c630) at src/render.cc:293
#25 operator() (__closure=0x7fffb8000cd8) at src/parallel.h:149
#26 std::__invoke_impl >(int, coord_t, 
coord_t, coord_t, bool volatile*, render(const wlookup&, const param&, hooks*, 
bool, progress_t*, bool volatile*)::):: > (__f=...) 
at /usr/include/c++/12/bits/invoke.h:61
#27 std::__invoke >(int, coord_t, coord_t, 
coord_t, bool volatile*, render(const wlookup&, const param&, hooks*, bool, 
progress_t*, bool volatile*)::):: > (__fn=...) at 
/usr/include/c++/12/bits/invoke.h:96
#28 std::thread::_Invoker >(int, 
coord_t, coord_t, coord_t, bool volatile*, render(const wlookup&, const 

Bug#1024905: minidlna: new upstream version

[Alexander Gerasiov]

On Sun, 27 Nov 2022 20:07:41 +
"Barak A. Pearlmutter"  wrote:

> Package: minidlna
> Version: 1.3.0+dfsg-2.2+b3
> Severity: wishlist
> X-Debbugs-Cc: none, Barak A. Pearlmutter 
> 
> Merge upstream version 1.3.2, packaging updates, and minor patches.
> I've put these in a git fork on salsa, see
> https://salsa.debian.org/debian/minidlna/-/merge_requests/4

Thanks, will take a look on it this weekend

-- 
Best regards,
 Alexander Gerasiov

 Contacts:
 e-mail: a...@gerasiov.net  WWW: https://gerasiov.net  TG/Skype: gerasiov
 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49  BAEA CA87 E9E8 2AAC 33F1

Bug#1019808: [Debichem-devel] Bug#1019808: marked as pending in openbabel

[Andrius Merkys]

Hi Olly,

On 2022-11-27 21:09, Olly Betts wrote:

This transition is now down to just 3 packages needing updating (one
of which accidentally got uploaded over the weekend based on a
pre-transition version so we should be down to 2 packages soon).

This bug has been tagged as "pending" for over a month now - please
could a maintainer make an upload of openbabel soon?

Or if there's a problem with the update then please update this bug
so we know what the status is.


Thanks for a reminder. I will upload openbabel tomorrow at latest.

Best,
Andrius

Bug#1025002: lirc: new upstream version 0.10.2

[Thomas Uhle]

Source: lirc
Version: 0.10.1-7.1
Severity: normal

Dear maintainers,

after many years there is a new LIRC version with many fixes upstream 
now.  There is a good chance that it will also fix issues in Debian. 
So could you please consider to provide Debian packages for the new 
version 0.10.2.


Thank you in advance!

Best regards,

Thomas Uhle

Bug#1025001: gitlab: Some UI elements, including buttons, are replaced with "undefined"

[Fabien Givors]

Package: gitlab
Version: 15.4.2+ds1-1~fto11+3
Severity: important
X-Debbugs-Cc: f+deb...@chezlefab.net

Dear Maintainer,

   * What led up to the situation?

I upgraded gitlab from 15.3.4+ds1-1~fto11+1 to 15.4.2+ds1-1~fto11+3

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

Dancing around a bit with a large troot. Ineffective.

   * What was the outcome of this action?

Some actions requires a carefully crafted API request to be performed
since UI is not useable.

   * What outcome did you expect instead?

Useable UI, that is clickable buttons.


-- System Information:
Debian Release: 11.5
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable'), (100, 
'bullseye-fasttrack'), (100, 'bullseye-backports-staging')
Architecture: amd64 (x86_64)

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

Versions of packages gitlab depends on:
ii  asciidoctor 2.0.17-1~fto11+1
ii  bc  1.07.1-2+b2
ii  bundler 2.2.5-2
ii  bzip2   1.0.8-4
ii  dbconfig-pgsql  2.0.19
ii  debconf [debconf-2.0]   1.5.77
ii  exim4-daemon-light [mail-trans  4.94.2-7
ii  fonts-font-awesome [node-font-  5.0.10+really4.7.0~dfsg-4.1
ii  gitlab-common   15.4.2+dfsg-1~fto11+1
ii  gitlab-workhorse15.4.2+ds1-1~fto11+3
ii  katex [node-katex]  0.13.11+~cs6.0.0-2~bpo11+1
ii  libjs-bootstrap4 [node-bootstr  4.5.2+dfsg1-8~deb11u1
ii  libjs-pdf [node-pdfjs-dist] 2.6.347+dfsg-3
ii  libjs-popper.js [node-popper.j  1.16.1+ds-3
ii  libruby2.7 [ruby-webrick]   2.7.4-1+deb11u1
ii  lsb-base11.1.0
ii  nginx   1.18.0-6.1+deb11u3
ii  nginx-core [nginx]  1.18.0-6.1+deb11u3
ii  node-autosize   4.0.2~dfsg1-7
ii  node-axios  0.21.1+dfsg-1+deb11u1
ii  node-babel-loader   8.2.2-5
ii  node-babel-plugin-lodash3.3.4+~cs2.0.1-3
ii  node-babel7 7.12.12+~cs150.141.84-6
ii  node-brace-expansion2.0.0-1
ii  node-cache-loader   4.1.0+~cs2.0.0-1
ii  node-clipboard  2.0.8+ds+~cs9.6.11-1~bpo11+1
ii  node-compression-webpack-plugi  6.1.1-1
ii  node-copy-webpack-plugin5.1.2+~cs9.0.2-4
ii  node-core-js3.8.2-2
ii  node-cron-validator 1.3.1-1~bpo11+1
ii  node-css-loader 5.0.1+~cs14.0.5-1
ii  node-d3 5.16.0-4
ii  node-d3-selection   1.4.0-6
ii  node-dateformat 5.0.3-2~bpo11+1
ii  node-dompurify  2.3.7+dfsg-1~bpo11+1
ii  node-exports-loader 1.1.1-2
ii  node-file-loader6.2.0-2
ii  node-fuzzaldrin-plus0.5.0+dfsg-3
ii  node-glob   7.1.6+~7.1.3-1
ii  node-imports-loader 0.8.0-2
ii  node-jed1.1.1-2
ii  node-jquery 3.5.1+dfsg+~3.5.5-7
ii  node-jquery-ujs 1.2.2-2
ii  node-js-cookie  3.0.1+~3.0.0-2~bpo11+1
ii  node-js-yaml3.14.1+dfsg+~3.12.6-2
ii  node-jszip  3.5.0+dfsg-2
ii  node-jszip-utils0.0.2+dfsg-2
ii  node-lodash 4.17.21+dfsg+~cs8.31.198.20210220-9~bpo11+2
ii  node-marked 0.8.0+ds+repack-2
ii  node-mermaid8.14.0+~cs11.4.14-1~bpo11+1
ii  node-minimatch  3.0.4+~3.0.3-1
ii  node-miragejs   0.1.41+~cs5.6.6-4
ii  node-mousetrap  1.6.5~ds-1
ii  node-postcss8.4.8+~cs7.3.21-2~bpo11+2
ii  node-prismjs1.23.0+dfsg-1+deb11u2
ii  node-prosemirror-markdown   1.6.0-1~bpo11+2
ii  node-prosemirror-model  1.16.1+~cs1.1.5-1~bpo11+2
ii  node-prosemirror-state  1.3.4-1~bpo11+2
ii  node-prosemirror-view   1.23.13-1~bpo11+1
ii  node-raven-js   3.22.1+dfsg-2
ii  node-raw-loader 4.0.2-2
ii  node-style-loader   2.0.0-2
ii  node-three-orbit-controls   82.1.0-3
ii  node-three-stl-loader   1.0.6-3
ii  node-timeago.js 4.0.2-3
ii  node-underscore 1.9.1~dfsg-3
ii  node-url-loader 4.1.1-3
ii  node-uuid   8.3.2+~8.3.0-4
ii  node-vue2.6.12+dfsg-3
ii  node-vue-resource   1.5.1+dfsg-6
ii  node-webpack-stats-plugin   1.0.2-2
ii  node-worker-loader  3.0.5-2
ii  node-xterm  3.8.1+~cs0.9.0-1
ii  node-yaml   2.1.1-1~bpo11+1
ii  nodejs  12.22.12~dfsg-1~deb11u1
ii  ohai