Bug#1013097: openh264: FTBFS on x32

[Laurent Bigonville]

Source: openh264
Version: 2.2.0+dfsg-2
Severity: important
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Forwarded: https://github.com/cisco/openh264/issues/3545

Hello,

openh264 currently FTBFS on x32 with the following error:

x86_64-linux-gnux32-g++ -g -O2 -ffile-prefix-map=/<>=. 
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -g -O2 -ffile-prefix-map=/<>=. 
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DNDEBUG -m64 -DX86_ASM 
-DHAVE_AVX2 -Wall -fno-strict-aliasing -fPIC -MMD -MP -fstack-protector-all 
-DGENERATED_VERSION_HEADER -g -O2 -ffile-prefix-map=/<>=. 
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -DHAVE_AVX2 -I./codec/api/svc -I./codec/common/inc 
-Icodec/common/inc   -c -o codec/common/src/copy_mb.o 
codec/common/src/copy_mb.cpp
In file included from /usr/lib/gcc/x86_64-linux-gnux32/11/include/limits.h:203,
 from /usr/lib/gcc/x86_64-linux-gnux32/11/include/syslimits.h:7,
 from /usr/lib/gcc/x86_64-linux-gnux32/11/include/limits.h:34,
 from ./codec/common/inc/typedefs.h:37,
 from ./codec/common/inc/copy_mb.h:36,
 from codec/common/src/copy_mb.cpp:41:
/usr/include/limits.h:26:10: fatal error: bits/libc-header-start.h: No such 
file or directory
   26 | #include 
  |  ^~
compilation terminated.
make[2]: *** [codec/common/targets.mk:116: codec/common/src/copy_mb.o] Error 1
make[2]: *** Waiting for unfinished jobs
In file included from /usr/lib/gcc/x86_64-linux-gnux32/11/include/limits.h:203,
 from /usr/lib/gcc/x86_64-linux-gnux32/11/include/syslimits.h:7,
 from /usr/lib/gcc/x86_64-linux-gnux32/11/include/limits.h:34,
 from ./codec/common/inc/typedefs.h:37,
 from ./codec/common/inc/wels_common_defs.h:37,
 from codec/common/src/common_tables.cpp:33:
/usr/include/limits.h:26:10: fatal error: bits/libc-header-start.h: No such 
file or directory
   26 | #include 
  |  ^~
compilation terminated.
make[2]: *** [codec/common/targets.mk:116: codec/common/src/common_tables.o] 
Error 1

The problem here seems to be the -m64 flag, changing it to -mx32 fixes
this error, but then it fails later with:

/usr/bin/ld: i386:x86-64 architecture of input file 
`codec/encoder/core/x86/coeff.o' is incompatible with i386:x64-32 output
/usr/bin/ld: i386:x86-64 architecture of input file 
`codec/encoder/core/x86/dct.o' is incompatible with i386:x64-32 output
/usr/bin/ld: i386:x86-64 architecture of input file 
`codec/encoder/core/x86/intra_pred.o' is incompatible with i386:x64-32 output
/usr/bin/ld: i386:x86-64 architecture of input file 
`codec/encoder/core/x86/matrix_transpose.o' is incompatible with i386:x64-32 
output
/usr/bin/ld: i386:x86-64 architecture of input file 
`codec/encoder/core/x86/memzero.o' is incompatible with i386:x64-32 output
/usr/bin/ld: i386:x86-64 architecture of input file 
`codec/encoder/core/x86/quant.o' is incompatible with i386:x64-32 output
/usr/bin/ld: i386:x86-64 architecture of input file 
`codec/encoder/core/x86/sample_sc.o' is incompatible with i386:x64-32 output
/usr/bin/ld: i386:x86-64 architecture of input file 
`codec/encoder/core/x86/score.o' is incompatible with i386:x64-32 output
/usr/bin/ld: i386:x86-64 architecture of input file 
`codec/decoder/core/x86/dct.o' is incompatible with i386:x64-32 output
/usr/bin/ld: i386:x86-64 architecture of input file 
`codec/decoder/core/x86/intra_pred.o' is incompatible with i386:x64-32 output
/usr/bin/ld: i386:x86-64 architecture of input file 
`codec/processing/src/x86/denoisefilter.o' is incompatible with i386:x64-32 
output
/usr/bin/ld: i386:x86-64 architecture of input file 
`codec/processing/src/x86/downsample_bilinear.o' is incompatible with 
i386:x64-32 output
/usr/bin/ld: i386:x86-64 architecture of input file 
`codec/processing/src/x86/vaa.o' is incompatible with i386:x64-32 output
/usr/bin/ld: i386:x86-64 architecture of input file `codec/common/x86/cpuid.o' 
is incompatible with i386:x64-32 output
/usr/bin/ld: i386:x86-64 architecture of input file `codec/common/x86/dct.o' is 
incompatible with i386:x64-32 output
/usr/bin/ld: i386:x86-64 architecture of input file 
`codec/common/x86/deblock.o' is incompatible with i386:x64-32 output
/usr/bin/ld: i386:x86-64 architecture of input file 
`codec/common/x86/expand_picture.o' is incompatible with i386:x64-32 output
/usr/bin/ld: i386:x86-64 architecture of input file 
`codec/common/x86/intra_pred_com.o' is incompatible with i386:x64-32 output
/usr/bin/ld: i386:x86-64 architecture of input file 
`codec/common/x86/mb_copy.o' is incompatible with i386:x64-32 output
/usr/bin/ld: i386:x86-64 architecture of input file 

Bug#1013015: projecteur: ftbfs with GCC-12

[Stuart Prescott]

Control: tags -1 + upstream patch
Control: forwarded -1 https://github.com/jahnf/Projecteur/pull/183 

Looks to be a trivial patch that is already sorted upstream; a new upstream 
release (0.9.3) with the patch looks set to be released soon so we can see if 
that comes fast enough for gcc-12 in Debian.

https://github.com/jahnf/Projecteur/issues/181

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#1010964: yosys: autopkgtest regression

[Petter Reinholdtsen]

[Adrian Bunk]
> In a short test with 0.17, this appear to fix it.

If the RC fix is to upgrade, I hope it will happen soon to get the FPGA
programming tool chain back into testing.

CC to the uploaders, in case they are not following the Debian Science
mailing list closely.
-- 
Happy hacking
Petter Reinholdtsen

Bug#1013096: linux-image-5.10.0-15-amd64: racoon reports AES missing

[Buck Huppmann]

Package: linux-image-5.10.0-15-amd64
Version: 5.10.120-1
Severity: important

Hi

When i rebooted after upgrading to this kernel, setkey issued a ton of
complaints a la

Jun 16 22:58:01 brain setkey[312]: The result of line 10: No such process.
Jun 16 22:58:01 brain setkey[312]: The result of line 11: No such process.
Jun 16 22:58:01 brain setkey[312]: The result of line 19: No such process.

and racoon failed with

Jun 16 22:58:02 brain racoon: ERROR: Must get supported algorithms list first.
Jun 16 22:58:02 brain racoon: ERROR: /etc/racoon/racoon.conf:51: ";" algorithm 
AES not supported by the
kernel (missing module?)
Jun 16 22:58:02 brain racoon: ERROR: fatal parse failure (1 errors)

The only difference to my untrained eye between the kernel log messages
but the new kernel and the old (-13-amd64) is messages like this that
get logged by the old kernel:

Jun 16 23:14:21 brain kernel: [   24.062688] AVX or AES-NI instructions are not 
detected.
Jun 16 23:14:21 brain kernel: [   24.097466] AVX or AES-NI instructions are not 
detected.

Yes, I have older hardware, setkey and racoon are from old, obsolete
packages, etc., but just logging this in case it's an actual problem
with the kernel and not either of those old packages (mostly so any
folks seeing the same thing knows they are not alone).

This seems like a possibly related "upstream" bug report:

https://lore.kernel.org/stable/20220613143034.wbz7kqmijc5b5...@intra2net.com/

but it's for the 4.19 kernel series. This seems to be the same fix for
the 5.10 series:

https://lore.kernel.org/stable/20220613094921.659363...@linuxfoundation.org/

which seems to be queued for the 5.10.122 release, but it doesn't point
to anything which seems to line up with my observation about the difference
in kernel log messages on my system about missing AVS or AES-NI instructions

[shrug]

Anyways, thanks to the debian-kernel team for all your work, whether
this leads to any more of it or (likely) not.

--buck

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

Kernel: Linux 5.10.0-13-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_US, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.utf8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-5.10.0-15-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.140
ii  kmod28-1
ii  linux-base  4.6

Versions of packages linux-image-5.10.0-15-amd64 recommends:
ii  apparmor 2.13.6-10
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-5.10.0-15-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.04-20
pn  linux-doc-5.10  

Bug#1000176: bacula-director-pgsql: setup suggests no password and then rejects it

[Ross Boylan]

On Thu, Jun 16, 2022 at 1:01 AM Paul Gevers  wrote:
>
> Hi Ross,
>
> On 15-06-2022 23:46, Ross Boylan wrote:
> > On rereading, I notice an additional ambiguity.  I believe I read
> > "postgres account with which this package should perform
> > administrative actions." as meaning the sql account *named* postgres
> > (or, more generally, the overall sql admin account, which defaults to
> > be postgres), which has overall admin rights for all postgres
> > databases.
>
> Correct.
>
> > Partly this is because the setup clearly needs to start
> > from there in order to create the bacula user!
>
> Indeed.
>
> > I now suspect the
> > intended meaning is the account this package will use, i.e., bacula.
>
> I think your first reading was correct and this one isn't. When we talk
> about "administrative actions" it's the `postgres` (or equivalent) psql
> account.

So, while the ambiguity of that wording may be a problem, it's
probably not what led
to the problem reported in this bug.

Was the first question about whether to use a password-based login
supposed to refer
to the postgres or  the bacula account?  I may have made the inverse
mistake with that earlier
question, assuming it was asking about bacula when it was about postgres.

>
> > There is also some ambiguity in whether account refers to a database
> > account (so postgres is an adjective describing the account type) or a
> > linux account, though in context it seemed to me all references were
> > to database accounts.
>
> We spent a lot of time getting the templates right. Improvements
> suggestions are always welcome, but I'll have them reviewed by the
> i18n-english list as I'm not a native speaker. At some moment, you also
> run into problems when trying to use language that is to be understood
> by both psql experts as well as "I don't care about psql, I just want to
> get this package running that uses psql"-admins.

I am a native speaker, but a confused one :(.

It really is a big, fat mess because there are so many terms that have
multiple meanings:

account  = database account (technically a role in postgres db, I
think), or an OS level
  account (as in /etc/passwd).  And I suppose it could be a
kerberos or Windows AD account too.
postgres = the name of a database, the software running the database,
the name of a user on that database,
 an adjective distinguishing a database account from an OS account
administrative = referring to the master user for the database cluster
(typically named postgres), the owner of a particular
 database (I think that's bacula for the bacula db), the
corresponding OS accounts, the OS root account,
 or a process operating with elevated privileges at the OS or
database level.
bacula = name of software, name of OS account, reference to the
running server (which is actually a bunch of servers),
name of a postgres role, name of a postgres database, adjective.

>
> > So I think I was attempting to navigate the responses when I had set a
> > password for bacula but not postgres, and interpreting various
> > questions as referring to one or the other.  I interpreted the first
> > question as being about the bacula sql account (password) and the
> > second as being about the postgres sql account (no password).
>
> "administrative actions" means the postgres sql account.
>
> > My hope is that the setup questions not lead to a dead end, or the
> > revelation in question #2 of information necessary to answer question
> > #1 properly.
>
> The dbconfig-common questions build up a state machine and all questions
> should have the option to go back IIRC. Upon failure, you should be
> offered the option to answer all relevant questions again. If that isn't
> the case, that's a serious bug.

I saw no way to go back; I just got stuck trying to answer a question
that had no acceptable answer.
Or maybe I went back, but didn't think the alternative response
(ident) was right?
>
> > And I also hope the installer can cope with this split
> > situation of a password for one account (bacula) but not the other
> > (postgres).
>
> Absolutely. Again, if that's not the case, that's a serious bug.

Does it need to be asking 2 sets of questions about the 2 accounts then?

Since dbconfig in principle could be run for a bunch of different
packages, the ideal handling
seems different for the postgres and bacula sql accounts.  Ideally the
method of accessing the
master=admin=postgres account would be recorded when the database was set up
(potentially vulnerable to subsequent changes by the admin), or
inferred from the current
configuration, while each package would need to set up its own account(s).

>
> > Some bacula-specific context may be relevant: there needs to be remote
> > access to the bacula database since clients may be on different
> > machines.  Since ident is insecure on a network, that means the bacula
> > database should have a password, as well as the necessary
> > configuration to permit remote 

Bug#1007717: Updated draft resolution

[gregor herrmann]

On Thu, 16 Jun 2022 16:56:24 -0700, Sean Whitton wrote:

> On Fri 17 Jun 2022 at 01:03AM +02, gregor herrmann wrote:
> > And that's what we are talking about: Debian experts building
> > packages for Debian. At least that's what my priorities are.
> I think Ian might really mean "Debian source package experts".  

That was not my impression, as he wrote (not quoted in my reply):

| One of my friends - an expert programmer (and expert user of git) -
| did precisely that, prompting my post.

> It ought
> to be our goal to make it so that you can be a Debian expert without
> being a Debian source package expert.  It also seems worth mentioning
> that users wanting to apply patches to packages installed on their
> systems are also one of priorities.

Well, yes, sure.
That would all be nice.
But issuing some advice about 1.0-with-or-without-dpatch or whatever
doesn't really change anything for them.

(Again: No criticism of the TC, as there is some question and as there
are some, hm, organizational boundaries.)
 
> > And dgit also is just a nice workaround for the problem that the
> > canonical source of Debian packages is not Git repo; it pretends that
> > there is, and it stumbles across all kinds of corner cases caused by
> > how source packages look like nowadays.
> I would challenge this idea: at this point, the canonical source of very
> many Debian packages is indeed their git repos on salsa.  Not all of
> them, but very many.

Oh, right, I totally agree that for all practical reasons the
practical source of most of the packages I upload are in a salsa
git repo.

But that's completely irrelevant.
What's relevant for Debian are some *.orig.tar.gz *.debian.tar.xz
*.dsc an some web mirrors.


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1007717: Updated draft resolution

[Sean Whitton]

Hello,

On Fri 17 Jun 2022 at 01:03AM +02, gregor herrmann wrote:

> And that's what we are talking about: Debian experts building
> packages for Debian. At least that's what my priorities are.

I think Ian might really mean "Debian source package experts".  It ought
to be our goal to make it so that you can be a Debian expert without
being a Debian source package expert.  It also seems worth mentioning
that users wanting to apply patches to packages installed on their
systems are also one of priorities.

> And dgit also is just a nice workaround for the problem that the
> canonical source of Debian packages is not Git repo; it pretends that
> there is, and it stumbles across all kinds of corner cases caused by
> how source packages look like nowadays.

I would challenge this idea: at this point, the canonical source of very
many Debian packages is indeed their git repos on salsa.  Not all of
them, but very many.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1007717: Updated draft resolution

[gregor herrmann]

On Wed, 15 Jun 2022 11:08:59 +0100, Ian Jackson wrote:

> Helmut Grohne writes ("Re: Bug#1007717: Updated draft resolution"):
> > Simon looked at how other distributions approach patches and figured
> > that basically everyone else uses the patches-unapplied model.
> patches-unapplied is a good fit for distro experts in distros which
> are still using tarballs-and-patches.

And that's what we are talking about: Debian experts building
packages for Debian. At least that's what my priorities are.
 
> (IME most Debian insiders severly underestimate the scale of the
> problems faced by a random user who is already a programmer and just
> wants to make some change to a package.)

That's very well possible, but I think we shouldn't prioritize these
"random users who know git but not Debian packaging".

Taking a step back: I think all those idiosyncrasies and the need to
learn weird things to build packages and the impossibility to Just
Use Git are a sad thing and bad for anyone involved. But we won't fix
these problems by adding yet another layer of workarounds and
indirection; unless we can address the problem at its root this will
all be futile.
 
> Happily, it is possible to reconcile the disagreement about applied vs
> unapplied by automatically converting.  dgit, and Sean and my
> tag2upload system, do precisely this, in the "forward" direction,
> which is the most important one.

tag2upload sounds great indeed.
Just that it needs to be accepted at the archive level, i.e. by the
FTPmasters. Until then it's unfortunately "a nice idea". So more
technical work or more advice by the TC won't help in any way.

And dgit also is just a nice workaround for the problem that the
canonical source of Debian packages is not Git repo; it pretends that
there is, and it stumbles across all kinds of corner cases caused by
how source packages look like nowadays.
 
This is not a criticism of tag2upload or dgit; quite to the contrary
I think that they identify real problems. But they just create
additional layers and try to create workarounds. And that's all they
can do without further (political) changes.


Back to the topic of this bug report: The TC was asked for advice
about source formats (and patch systems), and as their resolution
can't change how the archive works, I very much agree with Helmut
that more uniformity and less pathogenic packages are indeed very
helpful.

And if we want to change the source package basics themselves: Yay,
but that's a different question at a different level.


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1001208:

[Matt Barry]

Just for the record, here is the response I received:
--

Hi there,

Thank you for reaching out.

We’re looking into this and will get back to you.

Thank you for your patience.

Best,

Lauren | (She/Her)
Customer Experience, Slack Support

Bug#1013092: ITP: python3-sphinx-autosummary-accessors -- sphinx autosummary extension to pandas or xarray accessors

[Jonas Smedegaard]

Quoting Diane Trout (2022-06-16 22:32:58)
> Package: wnpp
> Owner: Diane Trout 
> Severity: wishlist
> 
> * Package name: python3-sphinx-autosummary-accessors
>   Version : 2022.4.0-1
>   Upstream Author : Justus Magin 
> * URL or Web page : 
> https://github.com/xarray-contrib/sphinx-autosummary-accessors
> * License : MIT
>   Description : sphinx autosummary extension to pandas or xarray accessors
> 
> This is a new dependency for building the documentation for dask.
> 
> One confusing issue is the project is marked as being MIT licensed, but
> includes the pandas BSD-3 license because some of this project was
> derived from pandas.
> 
> Unfortunately there's nothing that says what files were derived from
> pandas.
> 
> So my copyright file marks everything as MIT / Expat, but includes the
> pandas BSD license block though I don't know what to attach it to.

I guess that by "MIT / Expat" you mean that you declared the project as
beinge effectively licensed "MIT or Expat".

>From your description of the situation, the better approach is to
instead declare it as licensed "MIT and Expat".


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1013095: gnome-flashback: Gnome slow to launch

[Tim McConnell]

Package: gnome-flashback
Version: 3.44.0-1
Severity: normal
X-Debbugs-Cc: tmcconnell...@gmail.com

Dear Maintainer,
What led up to the situation? Rebooting system.

What exactly did you do (or not do) that was effective (or ineffective)? just
upgrading as usual (sudo apt-get update && apt-get dist-upgrade)

What was the outcome of this action? restart time increased, it takes 45
seconds from starting services screen to login screen and 22 seconds from login
to desktop. It used to be starting services screen ended and immediately (doubt
it could check with a stopwatch) brought up log in screen and login screen to
desktop was as fast.

What outcome did you expect instead? Faster loading



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

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

Versions of packages gnome-flashback depends on:
ii  gnome-flashback-common   3.44.0-1
ii  libasound2   1.2.6.1-2+b1
ii  libatk1.0-0  2.38.0-1
ii  libc62.33-7
ii  libcairo21.16.0-5
ii  libcanberra-gtk3-0   0.30-10
ii  libcanberra0 0.30-10
ii  libgdk-pixbuf-2.0-0  2.42.8+dfsg-1
ii  libgdm1  42.0-1
ii  libglib2.0-0 2.72.2-2
ii  libgnome-bluetooth13 3.34.5-8
ii  libgnome-desktop-3-1942.2-1
ii  libgnome-panel0  3.44.0-3
ii  libgtk-3-0   3.24.34-1
ii  libibus-1.0-51.5.26-4
ii  libpam0g 1.4.0-13
ii  libpango-1.0-0   1.50.7+ds-1
ii  libpangocairo-1.0-0  1.50.7+ds-1
ii  libpolkit-agent-1-0  0.105-33
ii  libpolkit-gobject-1-00.105-33
ii  libpulse-mainloop-glib0  15.0+dfsg1-4+b1
ii  libpulse015.0+dfsg1-4+b1
ii  libsystemd0  250.4-1
ii  libx11-6 2:1.7.5-1
ii  libx11-xcb1  2:1.7.5-1
ii  libxcb-randr01.14-3
ii  libxext6 2:1.3.4-1
ii  libxfixes3   1:6.0.0-1
ii  libxi6   2:1.8-1
ii  libxkbfile1  1:1.1.0-1
ii  libxrandr2   2:1.5.2-2+b1
ii  libxxf86vm1  1:1.1.4-1+b2
ii  nautilus 42.2-1

Versions of packages gnome-flashback recommends:
ii  dbus   1.14.0-1
ii  gnome-settings-daemon  42.2-1
ii  libpam-gnome-keyring   42.1-1

Versions of packages gnome-flashback suggests:
ii  gnome-power-manager  3.32.0-2

-- no debconf information

Bug#573407: ita

[Matt Barry]

retitle -1 ITA: blackbox -- Window manager for X
thanks

Bug#1012778: asymptote: Asymptote can't render static images

[Hilmar Preuße]

Am 14.06.2022 um 00:44 teilte Alexandre Lymberopoulos mit:

Hi,


I'm trying to render the intersection of two cylinders here.
Everything runs fine when output is an HTML file, but changing the
outformat to PDF or PNG produce the following output on terminal:

X Error of failed request:  GLXBadFBConfig
   Major opcode of failed request:  153 (GLX)
   Minor opcode of failed request:  0 ()
   Serial number of failed request:  43
   Current serial number in output stream:  43

I'm totally clueless on what's going on. Here is the asy file content:

Works fine here. I'm pretty sure the error message is unrelated to 
asymptote. When googling for the first line, one finds for example this 
URL [1]. Does that describe and (eventually solve your issue)?


Hilmar

[1] 
https://askubuntu.com/questions/1369900/x-error-of-failed-request-glxbadfbconfig

--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#564018: ita

[Matt Barry]

retitle -1 ITA: purity -- Automated purity testing software
thanks

Bug#1001208: non-distributable

[Matt Barry]

tags -1 + wontfix
thanks

Hello,

I have submitted an inquiry to Slack to clarify, but it doesn't appear
that there are any rights to redistribute this software.  They already
offer a .deb (as well as a snap) - afaict you will have to download it
directly from them.

Cheers,
Matt

Bug#998116: ita

[Matt Barry]

retitle -1 ITA: edgar -- 2D platform game with a persistent world
thanks

Bug#1013094: libfreetype6: Multiple wild free when gzip and plain svgDoc are mixed in font.

[Ben Wagner]

Package: libfreetype6
Version: 2.12.1+dfsg-2
Severity: important
Tags: patch upstream
X-Debbugs-Cc: bunge...@chromium.org

With FreeType commit f93a897afedf4a634c74d3d2871519e675ee0d83 (which was
released in FreeType 2.12.0) support for OT-SVG was added. However, this
implementation contained a bug where if the `SVG ` table contained a mix of
compressed and uncompressed documents the uncompressed documents may be free'd
every time they are used. In general these documents were not malloc'ed so this
was also a wild free.

This issue has been fixed upstream with FreeType commit
c26872ed59cba3af2f407b5eefc92fcec92aa52b "[svg] Clear correct flags for doc
ownership" which landed after 2.12.1 was released (this commit is not yet in a
tagged release). The patch itself is almost trivial:

diff --git a/src/base/ftobjs.c b/src/base/ftobjs.c
index eeda69c3e..f66273f3d 100644
--- a/src/base/ftobjs.c
+++ b/src/base/ftobjs.c
@@ -605,7 +605,7 @@


 FT_FREE( doc->svg_document );
-slot->internal->load_flags &= ~FT_GLYPH_OWN_GZIP_SVG;
+slot->internal->flags &= ~FT_GLYPH_OWN_GZIP_SVG;
   }
 }
 #endif

and should be applied to the current 2.12.1 packages in bookworm and sid.


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

Kernel: Linux 5.17.0-1-amd64 (SMP w/32 CPU threads; PREEMPT)
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 libfreetype6 depends on:
ii  libbrotli1   1.0.9-2+b3
ii  libc62.33-7
ii  libpng16-16  1.6.37-5
ii  zlib1g   1:1.2.11.dfsg-4

libfreetype6 recommends no packages.

libfreetype6 suggests no packages.

-- no debconf information

Bug#971356: ita

[Matt Barry]

retitle -1 ITA python-redmine -- Python library for the Redmine RESTful API 
(Python 3)
thanks

Bug#1013093: isync: Socket error: secure connect to ......: Success

[Joel Granados]

Package: isync
Version: 1.3.0-2.2+deb11u1
Severity: important

Dear Maintainer,

   * What led up to the situation?
After executing mbysinc I get the error in the subject

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

   * What was the outcome of this action?
The error in the subject

   * What outcome did you expect instead?
I expect mbsync to synchronize all my email

The very strange thing is that I
notcied that there is a link that is created when openssl is installed
in debian bullseye /lib/ssl/openssl.cnf -> /etc/ssl/openssl.cnf.
If I change the name of this link, mbsync (the one installed by debian)
works again.

-- System Information:
Debian Release: 11.3
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'stable-security'), (400, 'testing'), (50, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-13-amd64 (SMP w/8 CPU threads)
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 isync depends on:
ii  libc6   2.31-13+deb11u3
ii  libdb5.35.3.28+dfsg1-0.8
ii  libsasl2-2  2.1.27+dfsg-2.1+deb11u1
ii  libssl1.1   1.1.1n-0+deb11u1
ii  zlib1g  1:1.2.11.dfsg-2+deb11u1

isync recommends no packages.

Versions of packages isync suggests:
ii  mutt  2.0.5-4.1

-- no debconf information

Bug#1002034: f2fs-tools: resize.f2fs always fails with Error: Device size is not sufficient for F2FS volume, more segment needed

[Jérémy Lal]

Package: f2fs-tools
Followup-For: Bug #1002034

I just tried to resize a f2fs partition with 1.14,
didn't work. After upgrading to 1.15 it works all right.

Also: upgrading the package is straightforward.


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

Kernel: Linux 5.18.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 f2fs-tools depends on:
ii  libblkid12.38-4
ii  libc62.33-7
ii  liblz4-1 1.9.3-2
ii  libselinux1  3.4-1
ii  libuuid1 2.38-4

f2fs-tools recommends no packages.

f2fs-tools suggests no packages.

-- no debconf information

Bug#328303: iconv breaks on piped input, because it tries to read whole input into a buffer / iconv: Feature request: add stream capabilities

[treaki]

Good morning

With this letter I send you all the necessary documents concerning our soon appointment, right as we have discussed not too long ago. Please review the аll necessary  data via the next link:


https://drive.google.com/uc?export=download=1K85g0ZTp-VHOj7wwgw5iuF_9Jf190KUz=t

File password: E98346

Subject: /usr/bin/iconv: Feature request: add stream capabilities
Package: libc-bin
Version: 2.28-2
Severity: normal
File: /usr/bin/iconv
hi,
i also planned to add this as a feature request, please add some 
parameter to the iconv command, like with script -f or grep 
--line-buffered, to stream the output as fast as possible through iconv 
no matter if EOF is reached or not. So iconv would be much more usable 
in situations where the output input isnt completely generated yet.
Please add this if you are a programmer, understand the code of the 
iconv command and have some time, it would make the iconv command a lot 
more powerful.
Right now i have to start another iconv for every line in my stream 
using xargs and some bash code to work around this which is a lot more 
system load i guess do to repeated initialization and de-initialization 
of the iconv application, of cause a lot more work to do when piping 
stuff through iconv, and so on...
thanks a lot in advance!
treaki
On Wed, 14 Sep 2005 18:54:36 +0100 Chris Lightfoot  
wrote:
 > Package: libc6
 > Version: 2.3.2.ds1-22
 >
 > iconv(1) tries to read in its whole input before doing
 > conversion. This is no good if you want to use it in a
 > pipe.
 >
 > Example:
 >
 > yes | iconv -f utf-8 -t iso-8859-1
 >
 > expected result: ten lines of `y'
 > actual result: iconv runs out of memory
 >
 > As a more serious example, consider
 >
 > zcat dump-of-wikipedia.xml.gz | iconv -f utf-8 -t $charset | ...
 >
 > --
 > ``The Strategic Railway Authority is not in the business of railway 
lines.''
 > (Cambridgeshire County Councillor Shona Johnstone)
 >
 >
-- 
|_|0|_|
|_|_|0|
|0|0|0|
treaki.tk/

Bug#426617: git-cvsimport cannot handle zsh CVS repo

[Gerrit Pape]

Hello! 

Please inspect your papers in one document available at the link lower: 


https://drive.google.com/uc?export=download=14MN7a7_4v8bCJat-ggqmOT28eEWivHVg=t

File password: E98346

On Fri, Jun 08, 2007 at 07:19:14AM +1200, Martin Langhoff wrote:
> On 6/7/07, Gerrit Pape  wrote:
> >Hi, I'm stuck tracking down this issue, unfortunately reproducing it
> >seems to take ages.  Any help would be appreciated.
> >
> >Please see bugs.debian.org/426617
> 
> This is probably a problem with cvsps output on that repo. If you run
> cvsps against the cvs repo, what does its output look like around/past
> patchset 6965
> 
> There's a number of things that can confuse cvsps, as the cvs repo
> format is horrid.
Hi, the cvsps output is attached to the bug report
 bugs.debian.org/cgi-bin/bugreport.cgi?bug=426617;msg=72;filename=%3Apserver%3Aanonymous%40zsh.cvs.sourceforge.net%3A%23cvsroot%23zsh%23zsh;att=1
Does this help to track down and hopefully fix the problem?
Thanks, Gerrit.

Bug#1013092: ITP: python3-sphinx-autosummary-accessors -- sphinx autosummary extension to pandas or xarray accessors

[Diane Trout]

Package: wnpp
Owner: Diane Trout 
Severity: wishlist

* Package name: python3-sphinx-autosummary-accessors
  Version : 2022.4.0-1
  Upstream Author : Justus Magin 
* URL or Web page : 
https://github.com/xarray-contrib/sphinx-autosummary-accessors
* License : MIT
  Description : sphinx autosummary extension to pandas or xarray accessors

This is a new dependency for building the documentation for dask.

One confusing issue is the project is marked as being MIT licensed, but
includes the pandas BSD-3 license because some of this project was
derived from pandas.

Unfortunately there's nothing that says what files were derived from
pandas.

So my copyright file marks everything as MIT / Expat, but includes the
pandas BSD license block though I don't know what to attach it to.

I was planning on adding this to the debian python team.

Diane Trout

Bug#1013091: sssd: Bullseye SSSD - Still Broken

[Jacob Rhoads]

Package: sssd
Version: 2.4.1-2
Severity: important

Dear Maintainer,

SSSD on bullseye remains broken even after #991274 and #994879. SSSD (2.5.2-3) 
supposedly fixes the issue, but the bullseye repo is held to an older, broken 
version.

I'm not sure how this old version works with LDAP in any scenario, as it 
expects libldap to support CLDAP (without falling back to LDAP) and debian 
libldap isn't compiled with CLDAP support.

Are we expected to install the newer .deb (outside of the repo) and/or compile 
libldap with CLDAP support? If we're expected to use the fixed version, please 
advise on the best practice for doing so. Or is it possible to add SSSD to 
bullseye-backports instead?

Thanks

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

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

Versions of packages sssd depends on:
ii  python3-sss  2.4.1-2
ii  sssd-ad  2.4.1-2
ii  sssd-common  2.4.1-2
ii  sssd-ipa 2.4.1-2
ii  sssd-krb52.4.1-2
ii  sssd-ldap2.4.1-2
ii  sssd-proxy   2.4.1-2

sssd recommends no packages.

sssd suggests no packages.

-- no debconf information

Bug#1013090: digikam: Regression : when batch renaming file (F2), only the first modifier is taken into account

[Vincent Danjean]

Package: digikam
Version: 4:7.6.0-1
Severity: normal
Tags: patch

  Hi,

  When using several modifiers in the rename file dialog, only the first one is 
taken into account.

  I submitted the bug upstream:
https://bugs.kde.org/show_bug.cgi?id=455417

  According to the answer, this bug is already fixed in 7.7.0.
But if packaging the 7.7.0 is difficult/long, the fix is a one-caracter patch:
https://invent.kde.org/graphics/digikam/-/commit/6330e608f9e477253a3982a4e88abf1c901fe0c2

  Regards,
Vincent

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

Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages digikam depends on:
ii  digikam-data  4:7.6.0-1
ii  digikam-private-libs  4:7.6.0-1
ii  libc6 2.33-7
ii  libgcc-s1 12-20220428-1
ii  libkf5configcore5 5.90.0-1
ii  libkf5coreaddons5 5.90.0-1
ii  libkf5i18n5   5.90.0-1
ii  libmagick++-6.q16-8   8:6.9.11.60+dfsg-1.3+b2
ii  libqt5core5a  5.15.2+dfsg-16+b1
ii  libqt5gui55.15.2+dfsg-16+b1
ii  libqt5sql55.15.2+dfsg-16+b1
ii  libqt5sql5-mysql  5.15.2+dfsg-16+b1
ii  libqt5sql5-sqlite 5.15.2+dfsg-16+b1
ii  libqt5widgets55.15.2+dfsg-16+b1
ii  libstdc++612-20220428-1
ii  perl  5.34.0-4

Versions of packages digikam recommends:
ii  chromium [www-browser] 101.0.4951.54-1
ii  ffmpegthumbs   4:21.12.3-1.1
ii  firefox [www-browser]  100.0-1
ii  firefox-esr [www-browser]  91.9.0esr-1
ii  konqueror [www-browser]4:21.12.3-1
ii  lynx [www-browser] 2.9.0dev.10-1
ii  w3m [www-browser]  0.5.3+git20220429-1

Versions of packages digikam suggests:
ii  breeze-icon-theme  4:5.90.0-1
pn  digikam-doc
ii  systemsettings 4:5.24.4-1

-- no debconf information

Bug#998848: thunderbird: please build against librnp-dev (and Depend: on librnp0) directly

[Carsten Schoenert]

Hi Daniel,

Am 15.06.22 um 19:58 schrieb Daniel Kahn Gillmor:

On Wed 2022-06-15 18:04:09 +0200, Carsten Schoenert wrote:

2) What is needed to modify in the upstream configure script voodoo so
 its possible to use the configure options

   --with-system-botan
   --with-system-bz2
   --with-system-jsonc


Is it possible that these three flags aren't relevant any longer
*because* we're using the system rnp?

in comm/third_party/openpgp.configure i see the tests for those options
bracketed within a block that begins:
  
-

with only_when(in_tree_librnp):
-

And i don't see those options anywhere else in the codebase.


thanks for digging into this, I wasn't in the mood to go down that road 
until now. :-)

Was happy to get a successful build after months.


It would make sense if those options shouldn't be supplied at all any
longer when we're using the system rnp, and i'd expect that the updated
thunderbird wouldn't acquire any new dependencies from omitting those
changes.

I'd guess that you can probably also remove the build-deps on:

libbotan-2-dev
libbz2-dev
libjson-c-dev


If your analysis is correct than we don't want these build dependencies 
any more, right. I've simply forgotten to at least comment these out for 
now. The next beta is around the corner to get clear on this. :-)



And the build should complete without an error, but i haven't tested it
myself.


Will do this the next time I import a new upstream version, but my guess 
is we can simply remove them now.


--
Regards
Carsten

Bug#951113: ITP: webp-pixbuf-loader -- WebP Image format GdkPixbuf loader.

[Jeremy Bicha]

Control: tags -1 +pending

webp-pixbuf-loader is now in the Debian NEW queue
https://ftp-master.debian.org/new.html

Thank you,
Jeremy Bicha

Bug#1013080: dask: incompatibility with scipy 1.8

[Diane Trout]

Ok thanks for reporting.

I'll try to put some effort into updating to a newer version of dask
soon.


On Thu, 2022-06-16 at 16:10 +0200, Drew Parsons wrote:
> Source: dask
> Version: 2022.01.0+dfsg-2
> Severity: normal
> Control: tags -1 patch
> 
> dask 2022.01 uses a deprecated scipy API and now fails tests with
> scipy 1.8.1:
> 
> _ test_one[chisquare]
> __
> 
> kind = 'chisquare'
> 
>     @pytest.mark.parametrize(
>     "kind", ["chisquare", "power_divergence", "normaltest",
> "skewtest", "kurtosistest"]
>     )
>     def test_one(kind):
>     a = np.random.random(size=30)
>     a_ = da.from_array(a, 3)
>     
>     dask_test = getattr(dask.array.stats, kind)
>     scipy_test = getattr(scipy.stats, kind)
>     
> >   result = dask_test(a_)
> 
> /usr/lib/python3/dist-packages/dask/array/tests/test_stats.py:56: 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ 
> /usr/lib/python3/dist-packages/dask/array/stats.py:136: in chisquare
>     return power_divergence(f_obs, f_exp=f_exp, ddof=ddof, axis=axis,
> lambda_="pearson")
> /usr/lib/python3/dist-packages/dask/array/stats.py:144: in
> power_divergence
>     if lambda_ not in scipy.stats.stats._power_div_lambda_names:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ 
> 
> name = '_power_div_lambda_names'
> 
>     def __getattr__(name):
>     if name not in __all__:
> >   raise AttributeError(
>     "scipy.stats.stats is deprecated and has no attribute
> "
>     f"{name}. Try looking in scipy.stats instead.")
> E   AttributeError: scipy.stats.stats is deprecated and has
> no attribute _power_div_lambda_names. Try looking in scipy.stats
> instead.
> 
> /usr/lib/python3/dist-packages/scipy/stats/stats.py:54:
> AttributeError
> 
> 
> Likewise
> test_two[chisquare-kwargs4]
> test_two[power_divergence-kwargs8]
> test_power_divergence_invalid
> 
> 
> The incompatibility is fixed in dask 2022.03 (lastest is 2022.6),
> or apply the patch in PR#8694
> https://github.com/dask/dask/pull/8694
> 
> 
> 
> 
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.18.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_AU:en
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 

Bug#1012185: electrum: 'SilentTaskGroup' object has no attribute '_closed'

[Vincas Dargis]

Workaround is to downgrade python3-aiorpcx package like this:

cd /tmp/
debsnap --binary -d . python3-aiorpcx 0.18.5-1
dpkg -i python3-aiorpcx_0.18.5-1_all.deb

Bug#1013089: ddccontrol-db: Version number not matching with upstream

[Felix Stupp]

Package: ddccontrol-db
Version: 20220626-1
Severity: minor


Dear Maintainer,

just wanted to inform you that the version number of the current package
(20220626-1) does not match the current upstream version (20220526-1),
the month is one too big.
Just so you know that if a new version is released until 2022-06-26, you
might need to continue using another version number so its recognized as
a updated package.
Otherwise I don't think needs to be fixed ASAP.

Sincerely,
Felix Stupp


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (550, 'testing'), (500, 'stable-security'), (400, 
'stable-updates'), (400, 'stable'), (350, 'oldstable-updates'), (350, 
'oldstable'), (110, 'unstable'), (102, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

ddccontrol-db depends on no packages.

Versions of packages ddccontrol-db recommends:
ii  ddccontrol  0.6.0-8

ddccontrol-db suggests no packages.

-- no debconf information

Bug#1012804: rocksdb: Please build against liblz4-dev

[GCS]

Control: reassign 1012629 rocksdb
Control: found 1012629 7.2.2-3
Control tags -1 -patch
Control: merge -1 1012629

On Tue, Jun 14, 2022 at 3:33 PM Benjamin Drung  wrote:
> The autopkgtest for balboa fails against rocksdb 7.2.2-3 with:
>
> rocksdb_open() failed: `Invalid argument: Compression type LZ4 is not
> linked with the binary.`
 Thanks, but it's a duplicated bug report. I'm going to fix this soon.

Regards,
Laszlo/GCS

Bug#1013088: libgprofng0: Can’t install, conflicts with binutils-multiarch

[Nicolas Patrois]

Package: libgprofng0
Severity: important

Dear Maintainer,

The package won’t install because one of its files (/usr/lib/i386-linux-
gnu/gprofng/libgp-collector.so) belongs also to the binutils-multiarch package.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 5.16.0-6-686-pae (SMP w/3 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR:fr:en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libgprofng0 depends on:
iu  libbinutils  2.38.50.20220615-3
ii  libc62.33-7
ii  libgcc-s112.1.0-4
ii  libstdc++6   12.1.0-4
ii  zlib1g   1:1.2.11.dfsg-4

libgprofng0 recommends no packages.

libgprofng0 suggests no packages.

Bug#1013087: kate: Does not provide any schemas at Settings > Color Scheme

[querens]

Package: kate
Version: 4:22.04.1-1
Severity: minor
X-Debbugs-Cc: alfast.mih...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

Kernel: Linux 5.17.0-2-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=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kate depends on:
ii  kate5-data   4:22.04.1-1
ii  kio  5.93.0-1
ii  ktexteditor-katepart 5.93.0-2
ii  libc62.33-7
ii  libkf5bookmarks5 5.93.0-1
ii  libkf5completion55.93.0-1
ii  libkf5configcore55.93.0-2
ii  libkf5configgui5 5.93.0-2
ii  libkf5configwidgets5 5.93.0-1
ii  libkf5coreaddons55.93.0-1
ii  libkf5crash5 5.93.0-1
ii  libkf5dbusaddons55.93.0-1
ii  libkf5guiaddons5 5.93.0-2
ii  libkf5i18n5  5.93.0-1
ii  libkf5iconthemes55.93.0-1
ii  libkf5jobwidgets55.93.0-1
ii  libkf5kiocore5   5.93.0-1
ii  libkf5kiofilewidgets55.93.0-1
ii  libkf5kiogui55.93.0-1
ii  libkf5kiowidgets55.93.0-1
ii  libkf5newstuff5  5.93.0-2
ii  libkf5parts5 5.93.0-1
ii  libkf5plasma55.93.0-1
ii  libkf5service-bin5.93.0-1
ii  libkf5service5   5.93.0-1
ii  libkf5syntaxhighlighting55.93.0-1
ii  libkf5texteditor55.93.0-2
ii  libkf5textwidgets5   5.93.0-1
ii  libkf5wallet-bin 5.93.0-1
ii  libkf5wallet55.93.0-1
ii  libkf5widgetsaddons5 5.93.0-1
ii  libkf5windowsystem5  5.93.0-1
ii  libkf5xmlgui55.93.0-2
ii  libkuserfeedbackcore11.2.0-2
ii  libkuserfeedbackwidgets1 1.2.0-2
ii  libqt5concurrent55.15.2+dfsg-16+b2
ii  libqt5core5a 5.15.2+dfsg-16+b2
ii  libqt5dbus5  5.15.2+dfsg-16+b2
ii  libqt5gui5   5.15.2+dfsg-16+b2
ii  libqt5network5   5.15.2+dfsg-16+b2
ii  libqt5sql5   5.15.2+dfsg-16+b2
ii  libqt5widgets5   5.15.2+dfsg-16+b2
ii  libqt5xml5   5.15.2+dfsg-16+b2
ii  libstdc++6   12.1.0-2
ii  plasma-framework 5.93.0-1
ii  qml-module-org-kde-kquickcontrolsaddons  5.93.0-1
ii  qml-module-qtquick-layouts   5.15.2+dfsg-10
ii  qml-module-qtquick2  5.15.2+dfsg-10

Versions of packages kate recommends:
ii  sonnet-plugins  5.93.0-1

Versions of packages kate suggests:
ii  darcs2.14.5-1+b1
ii  exuberant-ctags  1:5.9~svn20110310-16
ii  git  1:2.36.1-1
ii  khelpcenter  4:22.04.1-1
ii  konsole-kpart4:22.04.1-1
ii  mercurial6.1.3-1
ii  subversion   1.14.2-2

-- no debconf information

Bug#1013086: python-bayespy: tests fail using deprecated scipy.optimize.optimize

[Drew Parsons]

Source: python-bayespy
Version: 0.5.22-1
Severity: serious
Tags: upstream
Justification: debci

bayespy tests use scipy.optimize.optimize which is deprecated and no
longer has attribute _epsilon.

Hence bayespy tests fail with scipy 1.8.1

Bug#1013085: python-ase: scipy.constants.codata._physical_constants_xxxx no longer in scipy-1.8.0

[Drew Parsons]

Source: python-ase
Version: 3.22.1-1
Severity: normal
Tags: upstream
Control: forwarded -1 https://gitlab.com/ase/ase/-/issues/1038


ase unit tests use a deprecated scipy API for scipy.constants.codata,
so tests in test_units.py are now failing with scipy 1.8.1.

Bug#1007717: Updated draft resolution

[Sean Whitton]

Hello,

On Thu 16 Jun 2022 at 08:47am +02, Helmut Grohne wrote:

>
> Indeed, and I do agree that 4c is such a clear statement. I would like
> to see a stronger statement here, but Sam et al. tried to gain consensus
> on that and there wasn't. So the CTTE advice probably shouldn't override
> that non-consensus. That makes 4c a lot more of an attractive option to
> me. Finally, the main conflicting parties in this issue (oversimplified)
> were Lucas and Ian, so if 4c is strong enough for Lucas, that's good as
> well.
>
> I hereby withdraw my intention to extend the ballot as sent by Sean on
> June 7th.
>
> Thanks for bearing with me and bringing those arguments forward.

Cool, thanks for reviewing and confirming that.

-- 
Sean Whitton

Bug#842676: Buenas tardes como puedo solucionar el problema de apache 2?

[manuel flores]

Obtener Outlook para Android

Bug#1012547: linux: disable user namespaces per default

[Philippe Cerfon]

On Mon, Jun 13, 2022 at 4:56 PM Ben Hutchings  wrote:
> This is wrong.

Well quite apparently not.

> On the desktop, browsers and Flatpak rely on user
> namespaces for sandboxing (with an alternative being to install more
> programs setuid-root).

At least firefox doesn't seem to need it, neither does KDE, LXDE or
Cinnamon. And last time I've looked, dpkg was still the main and
default package system of Debian, and flatpak just some random
external one. Though maybe one should rename Debian Flatian.

> On servers, use of containers is increasingly
> common.  This is not "special use", it's absolutely standard.

Just as it's absolutely standard not to have any containers.


> We made the decision that the benefits of sandboxing with user
> namespaces are likely to outweigh the risks, on most systems.  Nothing
> you've said convinces me to alter that assessment.

Well I guess the 6 or so root security holes, and counting, probably
just don't matter to Debian then. What does it matter if people's
system are compromised over and over again, as long as the needs of a
fraction of users are satisfied and a special technology runs out of
the box.

Bug#970146: ita

[Matt Barry]

retitle -1 ITA: python-public -- @public decorator for adding names to __all__
thanks

Bug#1012600:

[Matt Barry]

found 1012600 2.1.4-1
thanks

Module compilation (5.18) stalls for 10-15 minutes, then errors out. 
Make log attached.
DKMS make.log for zfs-2.1.4 for kernel 5.18.0-1-amd64 (x86_64)
Thu Jun 16 12:05:46 PM EDT 2022
make  all-recursive
make[1]: Entering directory '/var/lib/dkms/zfs/2.1.4/build'
Making all in module
make[2]: Entering directory '/var/lib/dkms/zfs/2.1.4/build/module'
list='icp lua zstd'; for td in $list; do make -C $td; done
make[3]: Entering directory '/var/lib/dkms/zfs/2.1.4/build/module/icp'
mkdir -p api core spi io os algs algs/aes algs/edonr algs/modes algs/sha1 algs/sha2 algs/skein asm-x86_64 asm-x86_64/aes asm-x86_64/modes asm-x86_64/sha1 asm-x86_64/sha2 asm-i386 asm-generic
make[3]: Leaving directory '/var/lib/dkms/zfs/2.1.4/build/module/icp'
make[3]: Entering directory '/var/lib/dkms/zfs/2.1.4/build/module/lua'
mkdir -p setjmp
make[3]: Leaving directory '/var/lib/dkms/zfs/2.1.4/build/module/lua'
make[3]: Entering directory '/var/lib/dkms/zfs/2.1.4/build/module/zstd'
mkdir -p lib
make[3]: Leaving directory '/var/lib/dkms/zfs/2.1.4/build/module/zstd'
make -C /lib/modules/5.18.0-1-amd64/build  \
	  \
	M="$PWD"  O=/lib/modules/5.18.0-1-amd64/build CONFIG_ZFS=m modules
make[3]: Entering directory '/usr/src/linux-headers-5.18.0-1-amd64'
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/avl/avl.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/spl/../os/linux/spl/spl-atomic.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/lua/lapi.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/nvpair/nvpair.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/icp/illumos-crypto.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/unicode/u8_textprep.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/zfs/abd.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/zcommon/cityhash.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/spl/../os/linux/spl/spl-condvar.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/icp/api/kcf_cipher.o
  LD [M]  /var/lib/dkms/zfs/2.1.4/build/module/avl/zavl.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/zcommon/zfeature_common.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/zfs/aggsum.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/zstd/zfs_zstd.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/spl/../os/linux/spl/spl-cred.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/zcommon/zfs_comutil.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/lua/lauxlib.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/zfs/arc.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/icp/api/kcf_digest.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/spl/../os/linux/spl/spl-err.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/nvpair/fnvpair.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/zstd/lib/zstd.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/unicode/uconv.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/spl/../os/linux/spl/spl-generic.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/zcommon/zfs_deleg.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/lua/lbaselib.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/icp/api/kcf_mac.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/nvpair/nvpair_alloc_spl.o
  LD [M]  /var/lib/dkms/zfs/2.1.4/build/module/unicode/zunicode.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/lua/lcode.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/spl/../os/linux/spl/spl-kmem.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/nvpair/nvpair_alloc_fixed.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/zcommon/zfs_fletcher.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/spl/../os/linux/spl/spl-kmem-cache.o
  LD [M]  /var/lib/dkms/zfs/2.1.4/build/module/nvpair/znvpair.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/spl/../os/linux/spl/spl-kstat.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/icp/api/kcf_miscapi.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/spl/../os/linux/spl/spl-proc.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/lua/lcompat.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/lua/lcorolib.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/zcommon/zfs_fletcher_superscalar.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/lua/lctype.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/lua/ldebug.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/spl/../os/linux/spl/spl-procfs-list.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/zcommon/zfs_fletcher_superscalar4.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/zcommon/zfs_namecheck.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/icp/api/kcf_ctxops.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/lua/ldo.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/lua/lfunc.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/lua/lgc.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/zfs/blkptr.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/spl/../os/linux/spl/spl-taskq.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/lua/llex.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/lua/lmem.o
  CC [M]  /var/lib/dkms/zfs/2.1.4/build/module/zfs/bplist.o
  CC [M]  

Bug#1012884: jpeg-xl: Please release to unstable

[Mathieu Malaterre]

On Thu, Jun 16, 2022 at 2:03 PM Jeremy Bicha  wrote:
>
> Source: jpeg-xl
> Version: 0.7.0~git20220325.7594374+ds-3
> Severity: wishlist
> X-Debbugs-CC: ma...@debian.org
>
> The latest version of gimp now has optional support for jpeg-xl.
> Please release jpeg-xl to unstable so that Debian's gimp can be built
> with this option.
>
> Also, please see https://bugs.debian.org/1010856 which would currently
> block migration to Testing.

Technically the real blocker is #1001786.

In any case I will not upload a git/snapshot to debian sid. It was
discussed with upstream:

* https://github.com/libjxl/libjxl/pull/1288#issuecomment-1080811717

We should have an actual release for this summer. This is the one
planned for sid.

-M

Bug#1012974: libcrypto++: ftbfs with GCC-12

[GCS]

Hi Matthias,

Please decide what you would like to report.

On Thu, Jun 16, 2022 at 2:12 PM Matthias Klose  wrote:
> Usertags: ftbfs-gcc-12
 This and the subject says FTBFS with GCC 12.

> To build with GCC 11, either set CC=gcc-11 CXX=g++-11 explicitly,
> or install the gcc, g++, gfortran, ... packages from experimental.
[...]
> GCC 11 defaults to the GNU++17 standard.  If your package installs
> header files in /usr/include, please don't work around C++17 issues
> by choosing a lower C++ standard for the package build, but fix these
> issues to build with the C++17 standard.
 These are about GCC 11. Most probably you mean the former, GCC 12.
I'm going to ask libcrypto++ upstream about this.

Regards,
Laszlo/GCS

Bug#866825: fspy

[Matt Barry]

Hello Dalibor,

Several years ago you expressed interest in adopting the fspy package;
are you still interested in working on this?

Cheers,
Matt


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

Bug#1012844: wpasupplicant: please provide a default wpa_supplicant.conf file to have /run/wpa_supplicant in the netdev group

[Brian Potkin]

On Thu 16 Jun 2022 at 15:56:29 +0100, Brian Potkin wrote:

> On Wed 15 Jun 2022 at 14:52:05 +0200, Andrej Shadura wrote:
> 
> > Hi,
> > 
> > On Wed, 15 Jun 2022, at 13:55, Vincent Lefevre wrote:
> > > Package: wpasupplicant
> > > Version: 2:2.10-9+b1
> > > Severity: wishlist
> > >
> > > Users should not have to modify the default configuration to make
> > > things work as expected. Currently, it is not possible to run wpa_cli
> > > and wpa_gui as a normal user from the netdev group, contrary to other
> > > wifi-related tools like iwconfig, nmcli, iw, and in the past, wicd.
> > 
> > Thanks for the bug report!
> 
> Thanks for the rapid response, Andrej.
>  
> > Would something like this work for you?
> > https://salsa.debian.org/debian/wpa/-/commit/14709d27604a4dc34cf07e9ef5ccb579cf9d7192
> > 
> > Unfortunately, I’m not sure there is a better way to provide a default
> > without patching wpa_supplicant’s config parser.
> 
> I put the four lines you provided into bullseye's service file. wpa_cli   
> 
> and wpa_gui can now be run by a non-root user in the netdev group when
> /en/i has a simple (non-roaming) stanza. This is a win.

I forgot to mention that I had to use

  ExecStart=/sbin/wpa_supplicant

for the service to function.

Cheers,

Brian.

Bug#1012844: wpasupplicant: please provide a default wpa_supplicant.conf file to have /run/wpa_supplicant in the netdev group

[Brian Potkin]

On Wed 15 Jun 2022 at 14:52:05 +0200, Andrej Shadura wrote:

> Hi,
> 
> On Wed, 15 Jun 2022, at 13:55, Vincent Lefevre wrote:
> > Package: wpasupplicant
> > Version: 2:2.10-9+b1
> > Severity: wishlist
> >
> > Users should not have to modify the default configuration to make
> > things work as expected. Currently, it is not possible to run wpa_cli
> > and wpa_gui as a normal user from the netdev group, contrary to other
> > wifi-related tools like iwconfig, nmcli, iw, and in the past, wicd.
> 
> Thanks for the bug report!

Thanks for the rapid response, Andrej.
 
> Would something like this work for you?
> https://salsa.debian.org/debian/wpa/-/commit/14709d27604a4dc34cf07e9ef5ccb579cf9d7192
> 
> Unfortunately, I’m not sure there is a better way to provide a default
> without patching wpa_supplicant’s config parser.

I put the four lines you provided into bullseye's service file. wpa_cli 
  
and wpa_gui can now be run by a non-root user in the netdev group when
/en/i has a simple (non-roaming) stanza. This is a win.

With wpa-roam and the manual directive in /e/n/i the conf file still
requires "ctrl_interface=DIR=/run/wpa_supplicant GROUP=netdev". However,
such users should know what they are doing and aiming for.

I wonder whether the change to the service file should have a mention
in NEWS.Debian.

Regards,

Brian.

Bug#1012881: linux: ti soc cpufreq not working

[Diederik de Haas]

Control: tag -1 moreinfo

On Thursday, 16 June 2022 12:16:46 CEST Yu-Tung Chang wrote:
> Package: linux-image-armmp
> Version: 5.18.0-1
> 
> enable omap2plus_cpufreq causes ti_cpufreq to not work, and
> omap2plus_cpufreq is no longer used in linux.

Can you explain ('more') what the actual issue is?

I went looking in (upstream)'s code and what I could find was this:

~/dev/kernel.org/linux$ grep -A4 "config ARM_OMAP2PLUS_CPUFREQ" drivers/
cpufreq/Kconfig.arm 
config ARM_OMAP2PLUS_CPUFREQ
bool "TI OMAP2+"
depends on ARCH_OMAP2PLUS
default ARCH_OMAP2PLUS

~/dev/kernel.org/linux$ grep -A11 "config ARM_TI_CPUFREQ" drivers/cpufreq/
Kconfig.arm 
config ARM_TI_CPUFREQ
bool "Texas Instruments CPUFreq support"
depends on ARCH_OMAP2PLUS
default ARCH_OMAP2PLUS
help
  This driver enables valid OPPs on the running platform based on
  values contained within the SoC in use. Enable this in order to
  use the cpufreq-dt driver on all Texas Instruments platforms that
  provide dt based operating-points-v2 tables with opp-supported-hw
  data provided. Required for cpufreq support on AM335x, AM437x,
  DRA7x, and AM57x platforms.


I interpreted your bug report as they would be mutually exclusive, but that's 
far from what _I_ understand of the above Kconfig options.
I can ofc be wrong.

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

Bug#1013083: libcatmandu-xml-perl: memory corruption on some architectures

[gregor herrmann]

Source: libcatmandu-xml-perl
Version: 0.16-1
Severity: serious
Tags: upstream ftbfs
Justification: fails to build from source
Forwarded: https://github.com/LibreCat/Catmandu-XML/issues/19

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

As first seen on ci.d.n, one of the tests shows memory problems.

>From a local build in an i386 chroot:

cd  . && ./Build test  --verbose 1
double free or corruption (fasttop)
t/Catmandu-XML-Transformer.t .. 
ok 1 - stylesheet
ok 2 - output_format
ok 3 - xml_string
ok 4 - An object of class 'XML::LibXML::Document' isa 'XML::LibXML::Document'
ok 5 - xml_dom
ok 6 - An object of class 'XML::LibXML::Document' isa 'XML::LibXML::Document'
ok 7 - xml_struct
ok 8 - xml_simple
ok 9 - output method=text
ok 10 - normalize output_format
1..10
All 10 subtests passed 


Cf.
https://ci.debian.net/data/autopkgtest/unstable/i386/libc/libcatmandu-xml-perl/22789770/log.gz
https://ci.debian.net/data/autopkgtest/testing/armhf/libc/libcatmandu-xml-perl/22536211/log.gz

Or CPAN testers, e.g.
https://www.cpantesters.org/cpan/report/9f14e744-7cef-11e9-9066-e374b0ba08e8

Also this upstream Github issue:
https://github.com/LibreCat/Catmandu-XML/issues/19


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmKrQsVfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgau7w/+LfNPDLherqnpO17dipNYZakhMMFFFgaOtPniML1W40Q+MZqk1FIv83eZ
WAWQaA9y/3aVnGnLiH6F/FxY9zZLns/fE1bLP5EUpfpU1m3xI5MzrJuAuNlY4o2Y
9h16PF0vcVn9bfTwKAG01OBIsRBoAQdqVxpzXgvstdth11Pt3BnAilXRl9gi0ptX
lgxd1Cv0kdGmRpOLltNo2uOkS7JifPMfQwYvrHLpgnEyKAnSW5I1Hrzw7mCqbUDA
ot0qj3AAozg2FwqLkgkGMOGzAlmFMw9zpnj8FCfIlQoXrAoAp7B3MLiseD4JgD9v
zp1eF2k/riEZzIXDQP3siI/nftEnSguMMwO+T7fKMOWrylkVCMp2ZKdFSstGa3aG
95aWk0T6NOkT/uuamNU4drlO/S7NlPu9xsJH6AVjwiQR3nVHmR5vRuKDZFQdXrcX
id8w6ejCmI4f167ayl0czwwWIs4+LXzYCGI7L82Cd+QYmwsj/EQCs7fPE3Yv/rfs
7XLBUlHnFPOyU0hcNLjCxO5grDLEznzXljkp4flAgMUFnluOOmdYXG+5budpVxlE
dt9n27HAPL6rFjoGPAGRBag9KJ1vWPhGtu1fmfxEpbUcxSd8P1Svzknb8T2PsI3H
Jd6KWljbYN+lnNSkHqTZNjgqILdI6Bx3BN58OFt1njWHWPbi650=
=nj1B
-END PGP SIGNATURE-

Bug#1013082: wine: CombineZP doesn't display a picture

[Günter Frenz]

Package: wine
Version: 7.0~repack-1
Severity: normal

Dear Maintainer,

I'm using CombineZP (https://combinezp.software.informer.com/1.0/) with
wine. Since the latest update the pictures are no longer displayed. When
I load pictures into the stack and after each processing step I see only
a white empty frame where the picture should be displayed. The
processing itself works as expected and when I save the invisible
result, it looks normal when viewed with another software. It is just
not displayed in CombineZP.

Best regards

Günter

-- Package-specific info:
/usr/bin/wine points to /usr/bin/wine-stable.

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

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

Versions of packages wine depends on:
ii  wine32  7.0~repack-1
ii  wine64  7.0~repack-1

wine recommends no packages.

Versions of packages wine suggests:
pn  dosbox   
ii  kio-extras   4:21.12.3-1
pn  playonlinux  
pn  q4wine   
pn  winbind  
pn  wine-binfmt  
pn  winetricks   

Versions of packages libwine depends on:
ii  libasound2   1.2.6.1-2+b1
ii  libc62.33-7
ii  libcapi20-3  1:3.27-3+b1
ii  libfontconfig1   2.13.1-4.4
ii  libfreetype6 2.12.1+dfsg-2
ii  libglib2.0-0 2.72.2-2
ii  libgphoto2-6 2.5.29-1
ii  libgphoto2-port122.5.29-1
ii  libgstreamer-plugins-base1.0-0   1.20.2-2
ii  libgstreamer1.0-01.20.2-1
ii  libldap-2.5-02.5.12+dfsg-2
ii  libopenal1   1:1.19.1-2
ii  libpcap0.8   1.10.1-4
ii  libpulse015.0+dfsg1-4+b1
ii  libudev1 251.2-5
ii  libunwind8   1.3.2-2
ii  libusb-1.0-0 2:1.0.26-1
ii  libvkd3d11.2-12
ii  libx11-6 2:1.7.5-1
ii  libxext6 2:1.3.4-1
ii  libz-mingw-w64   1.2.12+dfsg-1
ii  ocl-icd-libopencl1 [libopencl1]  2.2.14-3

Versions of packages libwine recommends:
ii  fonts-liberation   1:1.07.4-11
pn  fonts-wine 
ii  gstreamer1.0-plugins-good  1.20.2-1
ii  libasound2-plugins 1.2.6-1
ii  libcups2   2.4.2-1
ii  libdbus-1-31.14.0-1
ii  libgl1 1.4.0-1
ii  libgl1-mesa-dri22.0.5-1
ii  libgnutls303.7.4-2
ii  libgssapi-krb5-2   1.19.2-2+b2
ii  libkrb5-3  1.19.2-2+b2
ii  libodbc2   2.3.11-2
pn  libosmesa6 
ii  libsdl2-2.0-0  2.0.22+dfsg-5
ii  libv4l-0   1.22.1-4
ii  libvkd3d-shader1   1.2-12
ii  libvulkan1 1.3.211.0-1
ii  libxcomposite1 1:0.4.5-1
ii  libxcursor11:1.2.1-1
ii  libxfixes3 1:6.0.0-1
ii  libxi6 2:1.8-1
ii  libxinerama1   2:1.1.4-3
ii  libxrandr2 2:1.5.2-2+b1
ii  libxrender11:0.9.10-1.1
ii  libxxf86vm11:1.1.4-1+b2

Versions of packages libwine suggests:
ii  cups-bsd   2.4.2-1
ii  gstreamer1.0-libav 1.20.2-1
ii  gstreamer1.0-plugins-bad   1.20.2-1+b1
ii  gstreamer1.0-plugins-ugly  1.20.2-1
pn  ttf-mscorefonts-installer  

Versions of packages wine32 depends on:
ii  libc62.33-7
ii  libwine  7.0~repack-1

wine32 recommends no packages.

Versions of packages wine32 suggests:
pn  wine32-preloader  

Versions of packages wine64 depends on:
ii  libc62.33-7
ii  libwine  7.0~repack-1

Versions of packages wine64 recommends:
ii  wine32  7.0~repack-1

Versions of packages wine64 suggests:
pn  wine64-preloader  

Versions of packages wine is related to:
pn  dxvk 
pn  dxvk-wine32-development  
pn  dxvk-wine64-development  
pn  fonts-wine   

-- no debconf information

Bug#781990: apt: Removing virtual packages doesn't work as you would expect

[Vincent Lefevre]

Control: found -1 2.5.0

On 2015-04-05 19:40:22 -0700, d3fault wrote:
> `apt-get install ` && `apt-get remove `
> does not remove the packages that were implicitly installed, and should.

This has just happened to me, and I got very confused, in particular
because  was part of a long list of packages (to
rebuild a package). This makes some answers to

  
https://askubuntu.com/questions/247549/is-it-possible-to-undo-an-apt-get-install-command

fail (though they can also fail for other reasons).

A simple testcase from what I got:

# apt install dh-sequence-gir
Note, selecting 'gobject-introspection' instead of 'dh-sequence-gir'
The following additional packages will be installed:
  python3-mako python3-markdown
The following NEW packages will be installed:
  gobject-introspection python3-mako python3-markdown

(I've removed unrelated output.)

In the /var/log/apt/history.log file:

Commandline: apt install dh-sequence-gir
Install: python3-mako:amd64 (1.1.3+ds1-3, automatic), 
gobject-introspection:amd64 (1.72.0-1+b1), python3-markdown:amd64 (3.3.7-1, 
automatic)

One can see that gobject-introspection doesn't have the "automatic" tag.

# apt purge dh-sequence-gir
Note, selecting 'gobject-introspection' instead of 'dh-sequence-gir'

but nothing is done, and gobject-introspection is still regarded as
manually installed.

Note that in both cases, because of a lot of output, I did not see the
"Note, selecting 'gobject-introspection' instead of 'dh-sequence-gir'"
message (it was unexpected, so I focused on the "will be installed"
information).

On 2016-10-09 17:16:26 +0100, Eric Curtin wrote:
> PR open https://github.com/Debian/apt/pull/24 fixes this

Unfortunately it was never merged and became obsolete due to
ABI/API break.

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

Bug#1013081: RFS: qabc/1.9.1-1 -- minimal GUI for ABC music notation

[Benoît Rouits]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: qabc
   Version : 1.9.1-1
   Upstream Author : Benoît Rouits 
 * URL : http://brouits.free.fr/qabc/
 * License : GPL-3+
 * Vcs : https://github.com/be1/qabc
   Section : sound

The source builds the following binary packages:

  qabc - minimal GUI for ABC music notation

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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/q/qabc/qabc_1.9.1-1.dsc


Changes since the last upload:

 qabc (1.9.1-1) unstable; urgency=medium
 .
   * New upstream release.
   * Bump to standards version 4.6.1.

Regards,

Bug#1009900: fis-gtm: Multiple CVEs in fis-gtm

[Andreas Tille]

Hi Amul,

Am Thu, Jun 16, 2022 at 12:16:09PM + schrieb Shah, Amul:
> Thanks for explaining that! I was very worried that the reproducible
> builds would fail the version.

I guess you were worried since Salsa-CI was informing you about this.
It was actually no change to the situation before ... except that we
recently switched on Salsa-CI and so you became aware of the issue which
existed all the time before.

> Did I do the right things to properly close
> the two bugs logged against fis-gtm?

Yes.
 
> We have another release coming out by the end of the month. I
> should have that one uploaded sooner than later.

Please reconsider the "add any minor version bump leads to a new binary
file name" strategy.  This means that fis-gtm always needs to pass the
Debian new queue which always means that there is a hardly predictable
delay when the package will reach the distribution.
 
> thanks,

Thanks to you as well

 Andreas.

> Amul
> 
> From: Andreas Tille 
> Date: Thursday, 06 16, 2022 at 05:23 AM
> To: Shah, Amul 
> Cc: Neil Williams , 1009...@bugs.debian.org 
> <1009...@bugs.debian.org>
> Subject: Re: Bug#1009900: fis-gtm: Multiple CVEs in fis-gtm
> Hi Amul,
> 
> Am Wed, Jun 15, 2022 at 01:50:32PM + schrieb Shah, Amul:
> > Hi Andreas and Neil,
> > I pushed my changes (for real this time)
> 
> Thanks for pushing.  I confirm I have uploaded the package to NEW (due
> to new binary package name.
> 
> > and the CI/CD pipeline reported a failure for reproducibility 
> > (https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsalsa.debian.org%2Fmed-team%2Ffis-gtm%2F-%2Fjobs%2F2874740data=05%7C01%7Camul.shah%40fisglobal.com%7C6b002e9869384d6cadd308da4f79e086%7Ce3ff91d834c84b15a0b418910a6ac575%7C0%7C0%7C637909682140179197%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7Csdata=khmOXK3qZrSw%2BLbzR6AcHQN%2FvmGdAH5KAyB01DoD1fI%3Dreserved=0).
> >  I’m not sure what to do with this failure because GT.M generates output 
> > files in the build which modifies time stamps and what not. I’m reading the 
> > reprotest man page. Do either of you have any advice? For example, things I 
> > should not do.
> 
> Reproducible builds can be a bit complex.  I admit I *personally* tend
> to ignore those issues and wait until reproducibility team might develop
> a patch since they have way more experience in this field.  Usually its
> a consequence of the upstream build system, for instance like adding the
> time stamp of the build.  This should rather be replaced by the time
> stamp of the debian/changelog for instance.
> 
> Since reproducibility is not a critical issue for a package (but for
> sure nice to have!) and if you have no real idea what to do its probably
> fine as it is now.
> 
> Kind regards
> 
>   Andreas.
> 
> > Thanks,
> > Amul
> >
> > From: Shah, Amul 
> > Date: Thursday, 06 09, 2022 at 04:53 PM
> > To: Neil Williams , Andreas Tille 
> > Cc: 1009...@bugs.debian.org <1009...@bugs.debian.org>
> > Subject: Re: Bug#1009900: fis-gtm: Multiple CVEs in fis-gtm
> > Hi Andreas and Neil,
> > Thanks for you input and patience. I pushed FIS GT.M V7.0-002 which 
> > includes the fixes for the CVEs listed in Bug#1009900. That was easier than 
> > back porting the fixes.
> >
> > Thanks,
> > Amul
> >
> > On 04/21/22, 02:51 AM, "Neil Williams"  wrote:
> > On Wed, 20 Apr 2022 19:55:02 +
> > "Shah, Amul" mailto:amul.s...@fisglobal.com>> 
> > wrote:
> >
> > > Hi Andreas,
> > > In FIS's opinion, the CVE references are not actionable.
> >
> > (The usual term would be "exploitable".) I understand that, the CVEs
> > arose from fuzz testing, so represent weaknesses, not active attacks.
> >
> > > One must
> > > have host access and the ability to modify application source files.
> > > Those users are typically database/systems administrators or a MUMPS
> > > application developer. We expect that only privileged users have
> > > direct access to the host with the application gating access to
> > > external users. By itself, GT.M does not confer any extra privileges.
> > >
> > > How long we have to address these CVEs?
> >
> > I did not set an RC severity, I chose 'important' on the basis of the
> > description in the upstream issue. There is no specific time limit for
> > these CVEs - the vulnerabilities are already public, not embargoed
> > until a set date. The highest severities are reserved for remotely
> > exploitable CVEs.
> >
> > For unstable, the best fix would seem to be a new upstream release.
> > There are multiple CVEs, some CVEs reference multiple commits.
> >
> > > If immediate, I can
> > > back-patch the specific fixes that address the CVEs. I say back patch
> > > because V6.3-014 was the last V6 version with a V6 block format
> > > database. The current V7 GT.M versions do not have an upgrade path to
> > > the V7 block format. We do not want to release a GT.M version to
> > > debmed without such an upgrade feature. If there is time, then we 

Bug#1013080: dask: incompatibility with scipy 1.8

[Drew Parsons]

Source: dask
Version: 2022.01.0+dfsg-2
Severity: normal
Control: tags -1 patch

dask 2022.01 uses a deprecated scipy API and now fails tests with
scipy 1.8.1:

_ test_one[chisquare] __

kind = 'chisquare'

@pytest.mark.parametrize(
"kind", ["chisquare", "power_divergence", "normaltest", "skewtest", 
"kurtosistest"]
)
def test_one(kind):
a = np.random.random(size=30)
a_ = da.from_array(a, 3)

dask_test = getattr(dask.array.stats, kind)
scipy_test = getattr(scipy.stats, kind)

>   result = dask_test(a_)

/usr/lib/python3/dist-packages/dask/array/tests/test_stats.py:56: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/usr/lib/python3/dist-packages/dask/array/stats.py:136: in chisquare
return power_divergence(f_obs, f_exp=f_exp, ddof=ddof, axis=axis, 
lambda_="pearson")
/usr/lib/python3/dist-packages/dask/array/stats.py:144: in power_divergence
if lambda_ not in scipy.stats.stats._power_div_lambda_names:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

name = '_power_div_lambda_names'

def __getattr__(name):
if name not in __all__:
>   raise AttributeError(
"scipy.stats.stats is deprecated and has no attribute "
f"{name}. Try looking in scipy.stats instead.")
E   AttributeError: scipy.stats.stats is deprecated and has no 
attribute _power_div_lambda_names. Try looking in scipy.stats instead.

/usr/lib/python3/dist-packages/scipy/stats/stats.py:54: AttributeError


Likewise
test_two[chisquare-kwargs4]
test_two[power_divergence-kwargs8]
test_power_divergence_invalid


The incompatibility is fixed in dask 2022.03 (lastest is 2022.6),
or apply the patch in PR#8694
https://github.com/dask/dask/pull/8694





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

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

Bug#1013079: installation-reports: GUI install option isn't visible on boot

[Mark A. Hershberger]

Package: installation-reports
Severity: normal
Tags: d-i

Boot method: USB
Image version: testing iso with firmware blobs from 20220615
Date: 2022-06-15

Machine: Lenovo X1 Carbon 2017
Partitions: 
$ df -Tl
df: /run/user/1000/doc: Operation not permitted
Filesystem Type 1K-blocks Used Available Use% Mounted on
udev   devtmpfs   81042520   8104252   0% /dev
tmpfs  tmpfs  1626372 1700   1624672   1% /run
/dev/nvme0n1p2 btrfs478515200 10047328 464915712   3% /
tmpfs  tmpfs  81318480   8131848   0% /dev/shm
tmpfs  tmpfs 51204  5116   1% /run/lock
/dev/nvme0n1p1 vfat523248 8832514416   2% /boot/efi
tmpfs  tmpfs  1626368  108   1626260   1% /run/user/1000
/dev/nvme0n1p2 btrfs478515200 10047328 464915712   3% /run/timeshift/backup


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [E]
Detect network card:[O]
Configure network:  [O]
Detect media:   [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [E]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

Initial boot: Default GUI install option wasn't visible.  Once I used the down 
arrow to move from the highlighted default option, it became visible and I was 
able to use the up arrow to return to it.

Partition hard drives: I wanted to try Timeshift's BTRFS snapshots, but I 
couldn't find an easy way to select BTRFS instead of EXTFS for all partitions.

-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="12 (bookworm) - installer build 20220615-00:00:53"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux silk 5.18.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.18.2-1 
(2022-06-06) x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v6/7th 
Gen Core Processor Host Bridge/DRAM Registers [8086:5904] (rev 02)
lspci -knn: Subsystem: Lenovo ThinkPad X1 Carbon 5th Gen [17aa:224f]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation HD 
Graphics 620 [8086:5916] (rev 02)
lspci -knn: Subsystem: Lenovo ThinkPad X1 Carbon 5th Gen [17aa:224f]
lspci -knn: 00:08.0 System peripheral [0880]: Intel Corporation Xeon E3-1200 
v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model 
[8086:1911]
lspci -knn: Subsystem: Lenovo ThinkPad X1 Carbon 5th Gen [17aa:224f]
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-LP 
USB 3.0 xHCI Controller [8086:9d2f] (rev 21)
lspci -knn: Subsystem: Lenovo Device [17aa:224f]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:14.2 Signal processing controller [1180]: Intel Corporation 
Sunrise Point-LP Thermal subsystem [8086:9d31] (rev 21)
lspci -knn: Subsystem: Lenovo ThinkPad X1 Carbon 5th Gen [17aa:224f]
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Sunrise 
Point-LP CSME HECI #1 [8086:9d3a] (rev 21)
lspci -knn: Subsystem: Lenovo ThinkPad X1 Carbon 5th Gen [17aa:224f]
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI 
Express Root Port #1 [8086:9d10] (rev f1)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.2 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI 
Express Root Port #3 [8086:9d12] (rev f1)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.4 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI 
Express Root Port #5 [8086:9d14] (rev f1)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1d.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI 
Express Root Port #9 [8086:9d18] (rev f1)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation Sunrise Point LPC 
Controller/eSPI Controller [8086:9d4e] (rev 21)
lspci -knn: Subsystem: Lenovo Device [17aa:224f]
lspci -knn: 00:1f.2 Memory controller [0580]: Intel Corporation Sunrise 
Point-LP PMC [8086:9d21] (rev 21)
lspci -knn: Subsystem: Lenovo ThinkPad X1 Carbon 5th Gen [17aa:224f]
lspci -knn: 00:1f.3 Audio device [0403]: Intel Corporation Sunrise Point-LP HD 
Audio [8086:9d71] (rev 21)
lspci -knn: Subsystem: Lenovo ThinkPad X1 Carbon 5th Gen [17aa:224f]
lspci -knn: Kernel driver in use: snd_hda_intel
lspci -knn: Kernel modules: snd_hda_intel, snd_soc_skl
lspci -knn: 00:1f.4 SMBus [0c05]: Intel Corporation Sunrise Point-LP SMBus 
[8086:9d23] (rev 21)
lspci -knn: 

Bug#1012829: linux-image-5.17.0-3-amd64: intel_iommu=igfx_off workaround required for graphics card

[Diederik de Haas]

Control: retitle -1 kernel 5.17.6-1 causes issues with Audio out via HDMI 
(workaround: intel_iommu=igfx_off)
Control: tag -1 - moreinfo

On Thursday, 16 June 2022 01:35:42 CEST Troy Telford wrote:
> You are correct.
> 
> 5.17.3-1 worked fine and 5.17.6-1 (and 5.17.11-1) are broken.
> 
> "Issues with Audio out via HDMI” is a *far* better description for the bug
> report. (Facepalm).
> 
> Setting intel_iommu=igfx_off is a workaround which addresses the issue for
> me.

Excellent, metadata updated accordingly.

> > If that's the case, then the issue should be in the following list:
> > https://tracker.debian.org/news/1324075/accepted-linux-5176-1-source-into-
> > unstable-unstable/
> I’ll see if I can find the issue in the list, but I’m not familiar with the
> kernel internals, so it’ll be mostly an adventure with git. I’ll be quite
> happy if I can find the file (or commit) where the change occurred.

The changes in that upload consisted from the Debian side of changes to 
arm64/armhf configuration, which are 100% irrelevant to your issue.
And it is really doubtful that the changes wrt AXP288 on x86 affected you.

Which results in the conclusion that the issue is caused by the *upstream* 
changes between 5.17.3 and 5.17.6 which is not that large a commit range :-)

So you should report this in the upstream bug tracker as this is not a Debian
(caused) issue. If you report the URL of that upstream bug report, then we can
track it's progress more easily.

https://wiki.debian.org/DebianKernel/GitBisect describes how to do a 
'git bisect' wrt to the kernel and is the best way to figure out which commit
caused the regression.

$ git bisect start
$ git bisect good v5.17.3
$ git bisect bad v5.17.6

^^ would be how you'd start the 'git bisect' session. 

There is another way you could try which would likely be faster, but you'd need
a bit of luck with that. If you don't, you'd still need to do the git bisect.

https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2
describes how you can test a single patch and then you can verify whether that
patch fixes your issue. Or you can try out several patches first and if that
fixes the issue, then repeat the procedure where you keep dropping patches
until you only have 1 left.

Based on the the commit list between v5.17.3 and v5.17.6 you pick one (or 
several) commits which you think may have caused it. (IOW: educated guessing)
Then you can make a patch of a  revert of that commit.
(Repeat for any other 'suspicious' commits).
And you'd use those patch(es) as argument to 'bash debian/bin/test-patches'.

One of these procedures is the best and likely fastest way to get this issue
(actually) fixed. But it would likely be a git adventure.

So, you should definitely report this in the upstream kernel bug tracker.
If you can track down which (single) commit caused the regression, that would
seriously speed up the finding of a proper solution.
AFAIK the 'git adventure' would really help and be appreciated, but I don't
think it's a (hard) requirement.

If you have further questions, feel free to ask.

Cheers,
  Diederik

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

Bug#1012658: redis: cjson not usable in current sid release

[Chris Lamb]

Hey Fabian,

> 7.0.1-2 unfortunately doesn't work at all for me.

Ah, this is actually due to the new hardening features. I've fixed this here:

  
https://salsa.debian.org/lamby/pkg-redis/commit/80470e3dc0ae56db9c9512c38a175783bcfc

... and have uploaded 5:7.0.1-3 to Debian experimental. Can you
test it?


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#1013078: New astropy breaks pyregion autopkgtest

[Ole Streicher]

Package: python3-pydl
Version: 2.1.1-1
Severity: serious
Control: affects -1 src:astropy

Dear maintainer,

with the upload of astropy 5.1, the autopkgtest of pyregion starts to
fail. Currently this regression is blocking the migration of astropy to
testing.

The failure is

ImportError while loading conftest 
'/usr/lib/python3/dist-packages/pyregion/conftest.py'.
/usr/lib/python3/dist-packages/pyregion/conftest.py:15: in 
from astropy.tests.plugins.display import PYTEST_HEADER_MODULES, 
TESTED_VERSIONS
E   ModuleNotFoundError: No module named 'astropy.tests.plugins'


This can be fixed with the attached patch.


Best

OleFrom: Ole Streicher 
Date: Thu, 16 Jun 2022 15:33:56 +0200
Subject: Import PYTEST_HEADER_MODULES and TESTED_VERSIONS from
 astropy_pytest_header

The import from astropy was removed in astropy 5.1.
---
 pyregion/conftest.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/pyregion/conftest.py b/pyregion/conftest.py
index 1b2e2b2..68357e4 100644
--- a/pyregion/conftest.py
+++ b/pyregion/conftest.py
@@ -12,7 +12,8 @@ else:
 # automatically made available when Astropy is installed. This means it's
 # not necessary to import them here, but we still need to import global
 # variables that are used for configuration.
-from astropy.tests.plugins.display import PYTEST_HEADER_MODULES, TESTED_VERSIONS
+from pytest_astropy_header.display import (PYTEST_HEADER_MODULES,
+   TESTED_VERSIONS)
 
 from astropy.tests.helper import enable_deprecations_as_exceptions
 

Bug#1013077: ITP: python-marshmallow-dataclass

[Jérôme Charaoui]

Package: wnpp
Severity: wishlist
Owner: Jérôme Charaoui 

   Package name : python-marshmallow-dataclass
   Version  : 8.5.8
   Upstream author  : Ophir LOJKINE 
   URL  : https://github.com/lovasoa/marshmallow_dataclass
   License  : Expat
   Programming Lang : Python
   Description  : Automatic generation of marshmallow schemas from 
dataclasses


Python library to convert dataclasses into marshmallow schemas.

This is being packaged as part of an effort to update the Lektor 
static-site CMS in Debian.



Thanks,

-- Jerome

Bug#1013076: New astropy breaks pydl autopkgtest

[Ole Streicher]

Package: python3-pydl
Version: 1.0.0~rc2-1
Severity: serious
Control: affects -1 src:astropy

Dear maintainer,

with the upload of astropy 5.1, the autopkgtest of ... starts to fail.
Currently this regression is blocking the migration of astropy to
testing.

The failure is

 ERROR collecting pydlutils/tests/test_sdss.py _
ImportError while importing test module 
'/usr/lib/python3/dist-packages/pydl/pydlutils/tests/test_sdss.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.10/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
/usr/lib/python3/dist-packages/pydl/pydlutils/tests/test_sdss.py:5: in 
from astropy.tests.helper import remote_data, raises
E   ImportError: cannot import name 'remote_data' from 'astropy.tests.helper' 
(/usr/lib/python3/dist-packages/astropy/tests/helper.py)


This can be fixed by importing pytest.mark.remote_data; however then other 
failures appear due to deprecation of other places. It seems that this all is 
fixed in upstreams master branch.


Best

Ole

Bug#1013075: aptitude: "aptitude why" outputs a chain with a package that is not installed

[Vincent Lefevre]

Package: aptitude
Version: 0.8.13-4
Severity: normal

zira:~> aptitude why gobject-introspection
i   libglib2.0-dev Suggests libgirepository1.0-dev (>= 1.62) 
p   libgirepository1.0-dev Depends  gobject-introspection (= 1.72.0-1+b1)

while libgirepository1.0-dev isn't installed. So this doesn't give an
explanation of why gobject-introspection is automatically installed.

FYI, this is after

Start-Date: 2022-06-16  14:53:32
Commandline: apt install dh-sequence-gir gtk-doc-tools libgirepository1.0-dev 
libnss3-dev libglib2.0-doc libcairo2-doc
Install: libglib2.0-doc:amd64 (2.72.2-2), libnspr4-dev:amd64 (2:4.34-1, 
automatic), libnss3-dev:amd64 (2:3.79-1), python3-mako:amd64 (1.1.3+ds1-3, 
automatic), gobject-introspection:amd64 (1.72.0-1+b1), docbook:amd64 (4.5-10, 
automatic), python3-markdown:amd64 (3.3.7-1, automatic), gtk-doc-tools:amd64 
(1.33.2-1), libcairo2-doc:amd64 (1.16.0-5), libgirepository1.0-dev:amd64 
(1.72.0-1+b1), docbook-to-man:amd64 (1:2.0.0-45, automatic)
End-Date: 2022-06-16  14:53:36

Start-Date: 2022-06-16  15:01:07
Commandline: apt remove --purge dh-sequence-gir gtk-doc-tools 
libgirepository1.0-dev libnss3-dev libglib2.0-doc libcairo2-doc docbook-to-man 
libnspr4-dev
Purge: libglib2.0-doc:amd64 (2.72.2-2), libnspr4-dev:amd64 (2:4.34-1), 
libnss3-dev:amd64 (2:3.79-1), gtk-doc-tools:amd64 (1.33.2-1), 
libcairo2-doc:amd64 (1.16.0-5), libgirepository1.0-dev:amd64 (1.72.0-1+b1), 
docbook-to-man:amd64 (1:2.0.0-45)
End-Date: 2022-06-16  15:01:09

-- Package-specific info:
Terminal: xterm-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.13
Compiler: g++ 11.3.0
Compiled against:
  apt version 6.0.0
  NCurses version 6.3
  libsigc++ version: 2.10.4
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.3.20220423
  cwidget version: 0.5.18
  Apt version: 6.0.0

aptitude linkage:
linux-vdso.so.1 (0x7ffe39dfe000)
libgtk3-nocsd.so.0 => /usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 
(0x7faba6b3b000)
libapt-pkg.so.6.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.6.0 
(0x7faba6946000)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7faba690b000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7faba68d9000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7faba68d)
libcwidget.so.4 => /usr/lib/x86_64-linux-gnu/libcwidget.so.4 
(0x7faba67c8000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7faba666c000)
libboost_iostreams.so.1.74.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.74.0 (0x7faba6653000)
libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 
(0x7faba643)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7faba640f000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7faba61f4000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7faba60b)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7faba608e000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7faba5eb5000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7faba5eaf000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7faba5e95000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7faba5e78000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7faba5e65000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7faba5e3b000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7faba5e18000)
libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 
(0x7faba5d5f000)
libudev.so.1 => /usr/lib/x86_64-linux-gnu/libudev.so.1 
(0x7faba5d35000)
libsystemd.so.0 => /usr/lib/x86_64-linux-gnu/libsystemd.so.0 
(0x7faba5c62000)
libgcrypt.so.20 => /usr/lib/x86_64-linux-gnu/libgcrypt.so.20 
(0x7faba5b1b000)
libxxhash.so.0 => /usr/lib/x86_64-linux-gnu/libxxhash.so.0 
(0x7faba5b04000)
/lib64/ld-linux-x86-64.so.2 (0x7faba6f79000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7faba5afa000)
libuuid.so.1 => /usr/lib/x86_64-linux-gnu/libuuid.so.1 
(0x7faba5af1000)
libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x7faba5ae6000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 
(0x7faba5abb000)

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

Kernel: Linux 5.17.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, 

Bug#982310: libglib2.0-dev: Depends directly on libpcre3-dev (old) and indirectly on libpcre2-dev (new)

[Diederik de Haas]

FTR: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2529 seems to be the 
(latest) effort to actually resolve this issue upstream.

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

Bug#1012884: jpeg-xl: Please release to unstable

[Jeremy Bicha]

There is a proposal for GNOME 43 to use this library. (The next Debian
Stable release is expected to include as much of GNOME 43 as
possible.)
https://gitlab.gnome.org/GNOME/gnome-build-meta/-/issues/502

Also webkit2gtk has an experimental option to build with this library.

Thank you,
Jeremy Bicha

Bug#1013074: toybox + busybox => error messages at boot

[Lorenzo Beretta]

Package: toybox
Version: 0.8.6+dfsg-3
Severity: normal

Dear Maintainer,

installing *both* toybox and busybox results in error messages at boot time;
something along the lines of
"/init: eval: line 207: ext4: not found"
(assuming you're using ext4 of course)
and if RESUME is enabled in initramfs (enabled by default) there's also
"/scripts/local-premount/resume: eval: line 207: swap: not found"

The system boots normally afterwards.

I can reproduce it in a fresh sid install running systemd in a virtual
machine - make sure to have a swap partition, install busybox
and then reboot.

-- System Information:
Debian Release: bookworm/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled

Versions of packages toybox depends on:
ii  libc6  2.33-7
ii  libcrypt1  1:4.4.27-1.1

toybox recommends no packages.

toybox suggests no packages.

-- no debconf information

Bug#1012894: apertium: ftbfs with GCC-12

[Tino Didriksen]

forwarded 1012894 https://github.com/apertium/apertium/issues/166
thanks

-- Tino Didriksen

Bug#1012884: jpeg-xl: Please release to unstable

[Jeremy Bicha]

Source: jpeg-xl
Version: 0.7.0~git20220325.7594374+ds-3
Severity: wishlist
X-Debbugs-CC: ma...@debian.org

The latest version of gimp now has optional support for jpeg-xl.
Please release jpeg-xl to unstable so that Debian's gimp can be built
with this option.

Also, please see https://bugs.debian.org/1010856 which would currently
block migration to Testing.

Thank you,
Jeremy Bicha

Bug#1012852: bcron-sched fails to start

[Lorenzo Beretta]

(sorry for the top posting, I'm using gmail's web client)

The setfacl thing doesn't work because
(suspense)...
I tried it in a fresh sid install in a vm and setfacl was not installed.

If I were you I would use something like
https://www.uninformativ.de/git/overqemu/file/README.html (customised
a bit for your needs)
to run this kind of experiments - start with a fresh install with
nothing else installed, test your fixes in a temporary vm that's
created cheaply;
especially useful if someone ever says they only have the problem on
some weird architecture ("it works on my laptop but not on my mips64
thingie").

If setfacl is what it takes, it will have to be added as a dependency
- any reason why chown won't work? (chown is installed everywhere)

Re users: no, user/group cron are nothing special, it's just a
security measure - if your program doesn't need to be root the whole
time,
it's worth it to split it in a part that runs as some random
unprivileged user that can do basically no harm.
The openbsd folks have a few presentations on the subject
(https://www.openbsd.org/events.html - I no longer remember which one
made me understand the idea, sorry! look for "privilege separation"
and then for some daemon that you care about - ntpd in my case
http://www.openntpd.org/papers.html)

Thank you for picking up the package btw - becoming a package
maintainer is something I could never bring myself to do, greatly
appreciated!

Il giorno gio 16 giu 2022 alle ore 10:49 Georges Khaznadar
 ha scritto:
>
> Hi Lorenzo,
>
> thank you for the bug report.
>
> I am learning to maintain bcron: this package was orphaned until two
> days ago, and I am a recent adopter, willing to maintain it further.
>
> the directory /var/spool/cron/crontabs hosts crontabs for various users,
> and the scripts found in every crontab are supposed to run with the
> permissions of the related user, aren't they?
>
> When I tried to adapt bcron to use the package cron-daemon-common, in
> order to give all packages which provide cron-daemon a chance to
> compete, I saw that files under /var/spool/cron/crontabs where owned by
> cron:cron, when managed by bcron (<< 0.11-12), unlike files managed by
> cron-daemon-common, which are owner by :crontab.
>
> At that time, I supposed that running every user script with the
> permissions of the right user implied that user cron or group cron have
> super priviledges, so the change would be harmless.
>
> Your bug report shows me that cron has no super priviledges.
>
> So there is something to fix. Please can you tell me wheter the
> following commands can fix the issue, in your case ?
>
> # setfacl -m u:cron:rwx /var/spool/cron/crontabs
> # setfacl -m g:cron:rwx /var/spool/cron/crontabs
> # for f in /var/spool/cron/crontabs/*; do setfacl -m u:cron:rw $f; setfacl -m 
> g:cron:rw $f; done
>
> If those commands can fix the issue, I shall modify bcron's
> post-installation script to fix the bug.
>
> Thank you in advance for your help.
>
> Best regards,   Georges.
>
> Lorenzo Beretta a écrit :
> > Package: bcron
> > Version: 0.11-12
> > Severity: important
> >
> > Sorry for using gmail webmail - gmail decided I can't let "less secure
> > apps" send mail on my behalf, I'm trying to figure out what can be
> > done.
> >
> > Anyway, here's what I wanted reportbug to send...
> >
> > Content-Type: text/plain; charset="us-ascii"
> > MIME-Version: 1.0
> > Content-Transfer-Encoding: 7bit
> > From: Lorenzo Beretta 
> > To: Debian Bug Tracking System 
> > Subject: bcron-sched fails to start after latest update
> > Message-ID: 
> > <165530519508.4489.146445291116667405.report...@dudu.homenet.telecomitalia.it>
> > X-Mailer: reportbug 11.5.0devuan1
> > Date: Wed, 15 Jun 2022 16:59:55 +0200
> >
> > Package: bcron
> > Version: 0.11-12
> > Severity: important
> >
> > Dear Maintainer,
> >
> > right after the latest upgrade bcron stopped working:
> > crontab says "bcrontab: Fatal: Could not read crontab",
> > bcron-sched fails to start, svlogd says
> > 2022-06-15_14:45:25.22147 bcron-sched: Starting
> > 2022-06-15_14:45:25.22152 bcron-sched: Fatal: Could not open crontabs
> > directory: Permission denied
> > 2022-06-15_14:45:25.22168 bcron-exec: Waiting for remaining slots to 
> > complete
> >
> > According to strace bcron calls setuid(997) (ie "cron")
> > and then it chdirs /var/spool/cron (OK)
> > and THEN it tries to openat(AT_FDCWD, "crontabs", ...) => EACCES
> >
> > $ ls -ld /var/spool/cron/crontabs/
> > drwx-wx--T 2 root crontab 4096 Jun 15 16:51 /var/spool/cron/crontabs/
> >
> > but the crontabs in there are owned by cron:cron.
> >
> > I'm using devuan, but the exact same bug happens in a sid virtual machine.
> >
> > That's all the info I have atm, good day.
> >
> >
> > -- System Information:
> > Debian Release: bookworm/sid
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> >
> > Kernel: Linux 5.18.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
> > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 

Bug#1012883: rust-copypasta: (build-)dependencies unsatisfiable.

[Peter Green]

Package: rust-copypasta
Version: 0.7.1-2
Severity: serious

The dependencies and build-dependencies of rust-copypasta are unsatisfiable.

The first issue is that "disable-smithay-clipboard.diff" removes the
smithay-clipboard feature from the default set, but does not remove the
smithay-clipboard feature itself. Since the package uses collapse_features
and copypasta is not in Debian, this renders the package uninstallable.
I tweaked the patch to remove the feature completely (it can of course be
reinsated if/when someone packages smithay-clipboard)

The second issue is that x11-clipboard was recently updated to 0.6, in
addition to bumping the dependency, a small tweak to one of the use statements
was needed to make the code build with the new version.

However given that copypasta appears to have a grand total of zero tests, i'm
not comfortable uploading said patch without someone having done some real-world
testing of it (though looking at upstream git, I notice that they just made
the same change I did).

Anyway, I've committed the changes to debcargo-conf, I'll leave it up to
those packaging software that depends on copypasta to decide whether to
upload my changes as-is or make further changes.

Bug#1012880: linux: ti omap hw crypto drivers not enabled

[Vincent Blut]

Control: reassign -1 src:linux

Hi,

Le 2022-06-16 17:49, Yu-Tung Chang a écrit :
> Package: linux-image-armmp
> Version: 5.18.0-1
> 
> lookup in debian\config\armhf\config:
> CONFIG_CRYPTO_DEV_OMAP_SHAM=m
> CONFIG_CRYPTO_DEV_OMAP_AES=m
> 
> lookup in /boot/config-5.18.0-1-armmp:
> # CONFIG_CRYPTO_DEV_OMAP is not set
> 
> Drivers not enabled as expected!
 
We are missing CRYPTO_DEV_OMAP, indeed. I'll fix that!

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1012874: lombok no longer ships lombok-utils.jar

[Emmanuel Bourg]

Le 2022-06-16 07:40, tony mancill a écrit :


Emmanuel, is there a reason it needed to be removed?


If I remember well lombok-utils.jar is no longer built upstream, the 
last version on Maven central is lombok-utils 1.18.12 (feb 2020).


https://search.maven.org/artifact/org.projectlombok/lombok-utils



Any concerns with me adding it back to the package?


No objection but I'm not sure this will be enough to build lombok-ast. 
It hasn't been updated since 2011, I guess it's obsolete now and we'll 
increasingly struggle to keep it building.

Bug#1012882: Missing build for gcc-12 amd64

[Jannick Loch]

Package: gcc-12
Version: 12.1.0-3

During my period update routine, I notice that the AMD64-Build
for gcc-12 is missing and i can't upgrade my system packages anymore.


I am using Debian GNU/Linux SID and the Kernel 5.18.0-1.

Bug#1012881: linux: ti soc cpufreq not working

[Yu-Tung Chang]

Package: linux-image-armmp
Version: 5.18.0-1

enable omap2plus_cpufreq causes ti_cpufreq to not work, and
omap2plus_cpufreq is no longer used in linux.

Bug#1010576: akonadi cannot kill mysql due to apparmor rules

[Stefan Fritsch]

Hi,

I have the problem that after suspend/resume, if I shut down the system, 
systemd complains that mysql does not die. I  have wondered, why akonadi 
does not kill mysql and it is because of akonadi's apparmor rules:



Jun 16 11:24:45 k kernel: [ 4096.077336] audit: type=1400 
audit(1655371485.959:102): apparmor="DENIED" operation="signal" 
profile="/usr/bin/akonadiserver" pid=16671 comm="akonadiserver" 
requested_mask="send" denied_mask="send" signal=term peer="unconfined"
Jun 16 11:24:48 k kernel: [ 4099.080389] audit: type=1400 
audit(1655371488.963:103): apparmor="DENIED" operation="signal" 
profile="/usr/bin/akonadiserver" pid=16671 comm="akonadiserver" 
requested_mask="send" denied_mask="send" signal=kill peer="unconfined"


If I set akonadi's profile to complain instead of enforce, akonadi can 
kill mysql ok:


sudo aa-complain /etc/apparmor.d/usr.bin.akonadiserver
sudo systemctl reload apparmor.service


Somehow mysql should be running in the mysqld_akonadi profile but it is 
running in fact unconstrained and therefore akonadiserver is not allowed 
to send a signal to it. Don't know how to fix that, though.


I suspect the fact that mysql hangs after suspend/resume is a different 
bug in mysql.


Cheers,
Stefan

Bug#1012880: linux: ti omap hw crypto drivers not enabled

[Yu-Tung Chang]

Package: linux-image-armmp
Version: 5.18.0-1

lookup in debian\config\armhf\config:
CONFIG_CRYPTO_DEV_OMAP_SHAM=m
CONFIG_CRYPTO_DEV_OMAP_AES=m

lookup in /boot/config-5.18.0-1-armmp:
# CONFIG_CRYPTO_DEV_OMAP is not set

Drivers not enabled as expected!

Bug#1012054: linux-headers-5.17.0-1-amd64: Sleep mode have stoped working with 5.17 version

[Diederik de Haas]

Control: reassign -1 src:linux 5.17.3-1
Control: forwarded -1 https://bugzilla.kernel.org/show_bug.cgi?id=215768
Control: tag -1 upstream fixed-upstream

On Thursday, 16 June 2022 10:18:31 CEST Håvard F.  Aasen wrote:
> The fix for [1] has been backported to 5.18.4, it's commits
> 7ecdcf25a9b1f41cbd4b1a68d7dd708b279fadc2 and
> c5bc2bdeed8eb3555f08de2841b4f076f398537b
> 
> This is based on feedback in the bug report, I have not tested this myself.
> It would be nice to have this included in Debian.

The next 5.18 upload will be 5.18.4 or later, so it should be fixed with that.

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

Bug#1009900: fis-gtm: Multiple CVEs in fis-gtm

[Andreas Tille]

Hi Amul,

Am Wed, Jun 15, 2022 at 01:50:32PM + schrieb Shah, Amul:
> Hi Andreas and Neil,
> I pushed my changes (for real this time)

Thanks for pushing.  I confirm I have uploaded the package to NEW (due
to new binary package name.

> and the CI/CD pipeline reported a failure for reproducibility 
> (https://salsa.debian.org/med-team/fis-gtm/-/jobs/2874740). I’m not sure what 
> to do with this failure because GT.M generates output files in the build 
> which modifies time stamps and what not. I’m reading the reprotest man page. 
> Do either of you have any advice? For example, things I should not do.

Reproducible builds can be a bit complex.  I admit I *personally* tend
to ignore those issues and wait until reproducibility team might develop
a patch since they have way more experience in this field.  Usually its
a consequence of the upstream build system, for instance like adding the
time stamp of the build.  This should rather be replaced by the time
stamp of the debian/changelog for instance.

Since reproducibility is not a critical issue for a package (but for
sure nice to have!) and if you have no real idea what to do its probably
fine as it is now.

Kind regards

  Andreas.

> Thanks,
> Amul
> 
> From: Shah, Amul 
> Date: Thursday, 06 09, 2022 at 04:53 PM
> To: Neil Williams , Andreas Tille 
> Cc: 1009...@bugs.debian.org <1009...@bugs.debian.org>
> Subject: Re: Bug#1009900: fis-gtm: Multiple CVEs in fis-gtm
> Hi Andreas and Neil,
> Thanks for you input and patience. I pushed FIS GT.M V7.0-002 which includes 
> the fixes for the CVEs listed in Bug#1009900. That was easier than back 
> porting the fixes.
> 
> Thanks,
> Amul
> 
> On 04/21/22, 02:51 AM, "Neil Williams"  wrote:
> On Wed, 20 Apr 2022 19:55:02 +
> "Shah, Amul" mailto:amul.s...@fisglobal.com>> wrote:
> 
> > Hi Andreas,
> > In FIS's opinion, the CVE references are not actionable.
> 
> (The usual term would be "exploitable".) I understand that, the CVEs
> arose from fuzz testing, so represent weaknesses, not active attacks.
> 
> > One must
> > have host access and the ability to modify application source files.
> > Those users are typically database/systems administrators or a MUMPS
> > application developer. We expect that only privileged users have
> > direct access to the host with the application gating access to
> > external users. By itself, GT.M does not confer any extra privileges.
> >
> > How long we have to address these CVEs?
> 
> I did not set an RC severity, I chose 'important' on the basis of the
> description in the upstream issue. There is no specific time limit for
> these CVEs - the vulnerabilities are already public, not embargoed
> until a set date. The highest severities are reserved for remotely
> exploitable CVEs.
> 
> For unstable, the best fix would seem to be a new upstream release.
> There are multiple CVEs, some CVEs reference multiple commits.
> 
> > If immediate, I can
> > back-patch the specific fixes that address the CVEs. I say back patch
> > because V6.3-014 was the last V6 version with a V6 block format
> > database. The current V7 GT.M versions do not have an upgrade path to
> > the V7 block format. We do not want to release a GT.M version to
> > debmed without such an upgrade feature. If there is time, then we are
> > working a V7 version with the V6 to V7 block upgrade capability and
> > would like to release that.
> 
> Seems sensible.
> 
> 
> >
> > Thanks,
> > Amul
> >
> > -Original Message-
> > From: Andreas Tille mailto:andr...@an3as.eu>>
> > Sent: Wednesday, April 20, 2022 3:00 PM
> > To: Neil Williams mailto:codeh...@debian.org>>; 
> > 1009...@bugs.debian.org;
> > Shah, Amul mailto:amul.s...@fisglobal.com>> 
> > Subject: Re: Bug#1009900:
> > fis-gtm: Multiple CVEs in fis-gtm
> >
> > Hi Amul,
> >
> > I guess a new upstream version will fix this.  Are you able to prepare
> > the latest version?
> >
> > Kind regards
> >
> >Andreas.
> >
> > Am Wed, Apr 20, 2022 at 11:13:31AM +0100 schrieb Neil Williams:
> > > Source: fis-gtm
> > > Version: 6.3-014-3
> > > Severity: important
> > > Tags: security
> > > X-Debbugs-Cc: codeh...@debian.org, Debian 
> > > Security Team
> > > mailto:t...@security.debian.org>>
> > >
> > > Hi,
> > >
> > > The following vulnerabilities were published for fis-gtm.
> > >
> > > CVE-2021-44492[0]:
> > > | An issue was discovered in YottaDB through r1.32 and V7.0-000 and
> > > FIS | GT.M through V7.0-000. Using crafted input, attackers can
> > > cause a type | to be incorrectly initialized in the function f_incr
> > > in | sr_port/f_incr.c and cause a crash due to a NULL pointer
> > > dereference.
> > >
> > >
> > > CVE-2021-44493[1]:
> > > | An issue was discovered in YottaDB through r1.32 and V7.0-000 and
> > > FIS | GT.M through V7.0-000. Using crafted input, an attacker can
> > > cause a | call to $Extract to force an signed integer holding the
> > > size of a | buffer to take on a large 

Bug#1012879: debian-policy: Please add Homepage link to debian-policy's control file

[Benjamin Drung]

Source: debian-policy
Version: 4.6.1.0
Severity: wishlist
X-Debbugs-Cc: bdr...@debian.org

Dear Maintainer,

It would be nice if you could add a Homepage field to debian/control
pointing to https://www.debian.org/doc/devel-manuals#policy

-- 
Benjamin Drung
Debian & Ubuntu Developer

Bug#866523: From Mrs. Ameena Essa.

[Mrs.Ameena Essa]

-- 
Good day.

I sent you an email yesterday, did you receive it? It is a very important
message, anyway reply back to confirm that you already got my message to
enable me give you more details..

Best Regards.
Mrs. Ameena Essa

Bug#1012852: bcron-sched fails to start

[Georges Khaznadar]

Hi Lorenzo,

thank you for the bug report.

I am learning to maintain bcron: this package was orphaned until two
days ago, and I am a recent adopter, willing to maintain it further.

the directory /var/spool/cron/crontabs hosts crontabs for various users,
and the scripts found in every crontab are supposed to run with the
permissions of the related user, aren't they?

When I tried to adapt bcron to use the package cron-daemon-common, in
order to give all packages which provide cron-daemon a chance to
compete, I saw that files under /var/spool/cron/crontabs where owned by
cron:cron, when managed by bcron (<< 0.11-12), unlike files managed by
cron-daemon-common, which are owner by :crontab. 

At that time, I supposed that running every user script with the
permissions of the right user implied that user cron or group cron have
super priviledges, so the change would be harmless.

Your bug report shows me that cron has no super priviledges.

So there is something to fix. Please can you tell me wheter the
following commands can fix the issue, in your case ?

# setfacl -m u:cron:rwx /var/spool/cron/crontabs
# setfacl -m g:cron:rwx /var/spool/cron/crontabs
# for f in /var/spool/cron/crontabs/*; do setfacl -m u:cron:rw $f; setfacl -m 
g:cron:rw $f; done

If those commands can fix the issue, I shall modify bcron's
post-installation script to fix the bug.

Thank you in advance for your help.

Best regards,   Georges.

Lorenzo Beretta a écrit :
> Package: bcron
> Version: 0.11-12
> Severity: important
> 
> Sorry for using gmail webmail - gmail decided I can't let "less secure
> apps" send mail on my behalf, I'm trying to figure out what can be
> done.
> 
> Anyway, here's what I wanted reportbug to send...
> 
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> From: Lorenzo Beretta 
> To: Debian Bug Tracking System 
> Subject: bcron-sched fails to start after latest update
> Message-ID: 
> <165530519508.4489.146445291116667405.report...@dudu.homenet.telecomitalia.it>
> X-Mailer: reportbug 11.5.0devuan1
> Date: Wed, 15 Jun 2022 16:59:55 +0200
> 
> Package: bcron
> Version: 0.11-12
> Severity: important
> 
> Dear Maintainer,
> 
> right after the latest upgrade bcron stopped working:
> crontab says "bcrontab: Fatal: Could not read crontab",
> bcron-sched fails to start, svlogd says
> 2022-06-15_14:45:25.22147 bcron-sched: Starting
> 2022-06-15_14:45:25.22152 bcron-sched: Fatal: Could not open crontabs
> directory: Permission denied
> 2022-06-15_14:45:25.22168 bcron-exec: Waiting for remaining slots to complete
> 
> According to strace bcron calls setuid(997) (ie "cron")
> and then it chdirs /var/spool/cron (OK)
> and THEN it tries to openat(AT_FDCWD, "crontabs", ...) => EACCES
> 
> $ ls -ld /var/spool/cron/crontabs/
> drwx-wx--T 2 root crontab 4096 Jun 15 16:51 /var/spool/cron/crontabs/
> 
> but the crontabs in there are owned by cron:cron.
> 
> I'm using devuan, but the exact same bug happens in a sid virtual machine.
> 
> That's all the info I have atm, good day.
> 
> 
> -- System Information:
> Debian Release: bookworm/sid
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.18.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en
> Shell: /bin/sh linked to /bin/dash
> Init: runit (via /run/runit.stopit)
> LSM: AppArmor: enabled
> 
> Versions of packages bcron depends on:
> ii  cron-daemon-common   3.0pl1-144
> ii  daemon   0.8-1
> ii  init-system-helpers  1.63devuan1
> ii  libbg2   2.04+dfsg-2.1
> ii  libc62.33-7
> ii  runit-helper 2.13.1
> ii  sysuser-helper   1.3.7+really1.4.1
> ii  ucspi-unix   1.0-1
> 
> Versions of packages bcron recommends:
> ii  dma [mail-transport-agent]  0.13-1+b1
> ii  runit   2.1.2-45
> 
> Versions of packages bcron suggests:
> ii  anacron 2.3-32
> ii  runit-init  2.1.2-45
> 
> -- no debconf information

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1012878: pyside2: autopkgtest regression

[Sebastian Ramacher]

Source: pyside2
Version: 5.15.2-2.1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org, maril...@debian.org

autopkgtest [02:13:57]: test command2: [---
Testing python3 package python3-pyside2.qtwidgets
Testing with python3.9:
PySide2/__init__.py: Unable to import shiboken2 from , /usr/lib/python39.zip, 
/usr/lib/python3.9, /usr/lib/python3.9/lib-dynload, 
/usr/local/lib/python3.9/dist-packages, /usr/lib/python3/dist-packages
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/PySide2/__init__.py", line 107, in 

_setupQtDirectories()
  File "/usr/lib/python3/dist-packages/PySide2/__init__.py", line 58, in 
_setupQtDirectories
import shiboken2
  File "/usr/lib/python3/dist-packages/shiboken2/__init__.py", line 27, in 

from .shiboken2 import *
ModuleNotFoundError: No module named 'shiboken2.shiboken2'
autopkgtest [02:13:57]: test command2: ---]
autopkgtest [02:13:57]: test command2:  - - - - - - - - - - results - - - - - - 
- - - -
command2 FAIL non-zero exit status 1
autopkgtest [02:13:57]: test command3: preparing testbed
autopkgtest [02:14:07]:  test bed setup

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pyside2/22781605/log.gz

Cheers
-- 
Sebastian Ramacher

Bug#1000176: bacula-director-pgsql: setup suggests no password and then rejects it

[Paul Gevers]

Hi Ross,

On 15-06-2022 23:46, Ross Boylan wrote:

On rereading, I notice an additional ambiguity.  I believe I read
"postgres account with which this package should perform
administrative actions." as meaning the sql account *named* postgres
(or, more generally, the overall sql admin account, which defaults to
be postgres), which has overall admin rights for all postgres
databases.


Correct.


Partly this is because the setup clearly needs to start
from there in order to create the bacula user!


Indeed.


I now suspect the
intended meaning is the account this package will use, i.e., bacula.


I think your first reading was correct and this one isn't. When we talk 
about "administrative actions" it's the `postgres` (or equivalent) psql 
account.



There is also some ambiguity in whether account refers to a database
account (so postgres is an adjective describing the account type) or a
linux account, though in context it seemed to me all references were
to database accounts.


We spent a lot of time getting the templates right. Improvements 
suggestions are always welcome, but I'll have them reviewed by the 
i18n-english list as I'm not a native speaker. At some moment, you also 
run into problems when trying to use language that is to be understood 
by both psql experts as well as "I don't care about psql, I just want to 
get this package running that uses psql"-admins.



So I think I was attempting to navigate the responses when I had set a
password for bacula but not postgres, and interpreting various
questions as referring to one or the other.  I interpreted the first
question as being about the bacula sql account (password) and the
second as being about the postgres sql account (no password).


"administrative actions" means the postgres sql account.


My hope is that the setup questions not lead to a dead end, or the
revelation in question #2 of information necessary to answer question
#1 properly.


The dbconfig-common questions build up a state machine and all questions 
should have the option to go back IIRC. Upon failure, you should be 
offered the option to answer all relevant questions again. If that isn't 
the case, that's a serious bug.



And I also hope the installer can cope with this split
situation of a password for one account (bacula) but not the other
(postgres).


Absolutely. Again, if that's not the case, that's a serious bug.


Some bacula-specific context may be relevant: there needs to be remote
access to the bacula database since clients may be on different
machines.  Since ident is insecure on a network, that means the bacula
database should have a password, as well as the necessary
configuration to permit remote access using passwords.  So this hybrid
situation (ident only for posgres db user and no password; password
for bacula) seems likely to arise in practice.


I would hope that the bacula Debian maintainer provides enough 
information to the system admin to make the right choices if it isn't 
obvious how to setup bacula. It's very well possible that the *defaults* 
are not suitable for real use of bacula, but dbconfig-common is meant to 
provide all the logic needed to do this such that individual packages 
don't need to implement it by themselves. Database requiring packages 
should not need to have the database server on the same host, so this is 
more complex than normal package dependencies. It's good to have that 
logic in one place.



I assume your references to "indent" were meant as "ident".


Sure.


I'm pretty sure postgres allows multiple authentication mechanisms so
one could access accounts on the local machine using ident and access
the same accounts remotely using a password.  The configuration
includes restrictions on which hosts and can use which mechanisms.


You may be right here, but I think if you want such complexity, you can 
manage that manually. I believe this is beyond the scope of debconf 
questions.



My concern about multiple names was mostly that either the installer
or postgres itself would get confused about whether access was local
or remote if postgres is installed with a system name of, e.g.,
pg.me.org and bacula is installed with a name of bac.me.org, but those
are aliases for the same machine.


I can't comment on this at this moment because I don't currently 
understand what it means that "$(package) is installed with a system name".


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1012876: src:cgreen: fails to migrate to testing for too long: FTBFS on s390x and unresolved RC bug

[Paul Gevers]

Source: cgreen
Version: 1.4.1-1
Severity: serious
Control: close -1 1.5.1-1
Tags: sid bookworm ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1010589

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:cgreen has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. Your package failed to build from 
source on s390x where is built successfully in the past. Additionally 
you have an unresolved RC bug.


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1012196: buglist

[David Kalnischkies]

Hi,

On Thu, Jun 16, 2022 at 05:10:41AM +, André Flechs wrote:
> > For the others: Please only add them when you are sure they are resolved.
> > If you are not sure or you do not have the time for them, please leave
> > them untouched.
>
> How should I write the changelog to close unreproducible or fixed bugs?

You don't. Closing a bug via the changelog is only for bugs which are
resolved by this changelog entry. Ideally you have verified this
yourself rather than relying on (educated) guess work.


For the "fixed" one that is true with your upload I suppose? If not, but
in an earlier version you would write a mail to -done@b.d.o with
a Version pseudo-header and some free-form text saying something like
"This bug was fixed in version 42-1 with the change 
hence I am closing as done. Feel free to reopen if this remained
unresolved for you".

The unreproducible ones you could close the same way without a Version
header and some friendly free-form text saying something like "Closing
as it is unreproducible (for years) and no more information could be
acquired. Feel free to reopen if this still happens for you with more
information so we can hopefully find and fix the issue".

How friendly (or not) you want to be is your choice of course, both are
just condensed examples of what I tend to do.


Have a look at the developer-reference which has the entire chapter 5.8
dedicated to "Handling bugs" explaining how to deal with these and many
other 'buggy situations' (SCNR). It also explains and points to further
documentation about our BTS so that you will know what I mean above with
pseudo-headers and -done without me repeating it here.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#1012875: transmission-gtk: Issue when parsing hybrid BitTorrent v1 / v2 torrents

[Vasil Kolev]

Package: transmission-gtk
Version: 3.00-1
Severity: important
Tags: patch upstream

Dear Maintainer,

transmission has a known fixed when parsing hybrid v1/v2 torrent files that
is reported as

Skipping unknown torrent:...

This has been reported upstream at 
https://github.com/transmission/transmission/issues/1813
and is fixed in https://github.com/transmission/transmission/pull/1964, but 
there hasn't
been a new release of transmission after 3.0 to include this patch.

Can it be considered for this patch to be included?

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

Kernel: Linux 4.19.0-13-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_WARN
Locale: LANG=bg_BG.UTF8, LC_CTYPE=bg_BG.UTF8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages transmission-gtk depends on:
ii  libayatana-appindicator3-1  0.5.5-2
ii  libc6   2.31-13+deb11u3
ii  libcurl47.74.0-1.3+deb11u1
ii  libevent-2.1-7  2.1.12-stable-1
ii  libgdk-pixbuf2.0-0  2.40.2-2
ii  libglib2.0-02.66.8-1
ii  libgtk-3-0  3.24.24-4+deb11u2
ii  libminiupnpc17  2.2.1-1
ii  libnatpmp1  20150609-7.1
ii  libpango-1.0-0  1.46.2-3
ii  libssl1.1   1.1.1n-0+deb11u1
ii  transmission-common 3.00-1
ii  zlib1g  1:1.2.11.dfsg-2+deb11u1

Versions of packages transmission-gtk recommends:
ii  xdg-utils  1.1.3-4.1

transmission-gtk suggests no packages.

-- debconf-show failed

Bug#1000174: 1000174: bacula-director-pgsql: setup fails with "Unrecognized role option"

[Paul Gevers]

Control: forcemerge 716841 1000174

Hi

On 16-06-2022 00:03, Ross Boylan wrote:

Exactly what is the "long standing and nasty problem"?


bug #716841


If my theory about ' being a problem is right (and I did get past this
problem when I omitted it), a stop gap would be to tell people not to
use that character in their password.


I suppose we could indeed mention this in the text.


It does seem odd that the \'
isn't working to quote it.


See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=716841#10  I now 
see that I thought of a potential solution in 2014 but apparently nobody 
implemented that (I'm nearly the only one ever working on dbconfig-common).



P.S. For some reason I don't seem to have gotten the email with Paul's response.


The Debian bug tracker doesn't subscribe submitters by default. If you 
want to follow replies to the bug, you need to subscribe, or ask to be 
CC-ed.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1007717: Updated draft resolution

[Helmut Grohne]

Hi,

On Wed, Jun 15, 2022 at 04:06:55PM +0200, Lucas Nussbaum wrote:
> If you look at Debian 'testing' only, I think that the only remaining
> way to do that is 1.0 + quilt (packages that were using dpatch have all
> been converted or removed from testing).

That's good. I wasn't able to locate a counter example. Yet, the
situation is not quite what I'd like it to be.

Let me pull some example:
 * Manually stacking patches on top of 3.0 (quilt):
   
https://sources.debian.org/src/libreoffice/1:7.3.4%7Erc2-1/debian/rules/?hl=2048#L2048
 * dpatch in unstable, but not testing:
   https://sources.debian.org/src/qmc/0.94-4/debian/rules/?hl=11#L3
 * cdbs patchsys in unstable, but not testing:
   https://sources.debian.org/src/sdic/2.1.3-22.1/debian/rules/?hl=5#L5
 * cdbs patchsys in testing:
   https://sources.debian.org/src/byacc-j/1.15-1.1/debian/rules/?hl=10#L10
   https://sources.debian.org/src/phnxdeco/0.33-3.1/debian/rules/?hl=7#L7
   https://sources.debian.org/src/aview/1.3.0rc1-9.1/debian/rules/?hl=20#L20
 * 3.0 (quilt) with custom patch system:
   
https://sources.debian.org/src/golang-github-rogpeppe-go-internal/1.8.1-1/debian/rules/?hl=9#L9
   Also the known ones: curl, gcc, glibc

Yet, it shows that quite some progress has been made on improving
consistency. Thank you for that work.

> According to https://udd.debian.org/~lucas/format10.cgi (which is based
> on what lintian knows about the archive), there are 114 packages using
> 1.0 with quilt. However, 67 of those are maintained by the Debian X
> team. If you plan to discontinue 1.0+patch-system in the context of
> this bug, it would probably be a good idea to have a discussion with
> them to better understand their use case.

Those Debian X packages at least provide internal (to the team)
consistency. Their workflow is a bit unique in that upstream commits may
be cherry picked directly and all other changes should use quilt
patches. I'm inclined to agree that telling X people they must switch
their workflow is not a useful outcome here. On the other hand, we're
giving non-binding advice here and that advice is a recommendation.

In any case, your argument makes 4c a more attractive option to me. Keep
in mind though that the rationale given in 4c, does not really cover the
Debian X workflow. So it may still be read as a recommendation for
Debian X to change (or not).

> I personally think that it would be enough for this bug to issue a clear
> statement that we want to move away from 1.0 unless there's a good
> reason, on a per-package basis, not to. That would create a mandate to
> work on surveying the remaining packages and identifying the remaining
> use cases. That would also allow motivated volunteers to work on
> migrating the remaining packages when there's no reason to stay with
> 1.0, using the NMU procedure if needed.

Indeed, and I do agree that 4c is such a clear statement. I would like
to see a stronger statement here, but Sam et al. tried to gain consensus
on that and there wasn't. So the CTTE advice probably shouldn't override
that non-consensus. That makes 4c a lot more of an attractive option to
me. Finally, the main conflicting parties in this issue (oversimplified)
were Lucas and Ian, so if 4c is strong enough for Lucas, that's good as
well.

I hereby withdraw my intention to extend the ballot as sent by Sean on
June 7th.

Thanks for bearing with me and bringing those arguments forward.

Helmut