Bug#1017075: #1017075 dask - autopkgtest regression on i386 and armhf

[Graham Inggs]

Hi Drew

On Sun, 21 Aug 2022 at 19:08, Drew Parsons  wrote:
> In regards to bug severity, the dask debci failures are now marked as
> "Not a regression" so they won't hold up migration of dask.

Dask's autopkgtests are failing in testing since the removal of
scikit-learn.  I raised the severity of this bug precisely to prevent
this accidental migration.

> Graham, should the bug severity therefore be reduced from Serious back
> down to Important to enable migration of both dask and scipy?

Please don't.

Regards
Graham

Bug#1015782: live-build: Replace a few more values in the splash SVG

[Petter Reinholdtsen]

Control: tags -1 + patch

Do you need a new patch with less variables, or is the patch as sent OK?
I believe it is better to make the complete set of variables available
for SVG authors, and thus hope the original patch can be accepted.
-- 
Happy hacking
Petter Reinholdtsen

Bug#974154: ocrad: RFA -> ITA

[Andrius Merkys]

control: retitle -1 ITA: ocrad -- optical character recognition program
control: owner -1 !

Hello,

I would like to adopt ocrad.

Best,
Andrius

Bug#1017584: bullseye launch failures in IPv6-only VPC subnets

[Ross Vandegrift]

On Wed, Aug 17, 2022 at 07:40:04PM -0700, Noah Meyerhans wrote:
> Adding some tracing to the dhclient-script, I can see that
> /etc/dhcp/dhclient-exit-hooks.d/rfc3442-classless-routes is trying to add
> the routes with calls like:
> 
> ip -4 route add 169.254.169.254/32 via 169.254.0.1 dev ens5
> 
> However, because there's no route to 169.254.0.1, the call fails with
> "Error: Nexthop has invalid gateway."
> 
> On systems where the routes are properly configured, there's a link scope
> route to that address, e.g. on sid:
> 
> 169.254.0.1 dev ens5 proto dhcp scope link src 169.254.2.187 metric 100
> 
> If we create this route on bullseye, then the rest of the IPv4 routes are
> installed as expected.  Something like the following could work, but I'm
> open to other options:
> 
> services/admin@i-07e63055bb304147c:~$ cat /etc/dhcp/dhclient-exit-hooks.d/gw
> case "$reason" in
>   BOUND|RENEW|REBIND|REBOOT)
> if [ -z "$old_ip_address" ] ||
>[ "$old_ip_address" != "$new_ip_address" ]; then
> case "$new_ip_address" in
>   169.254.*)
> ip -4 ro add 169.254.0.1 dev "$interface" scope link

Should this also have "src $new_ip_address"?  I can't think of a case where it
would clearly make a difference, but it might be worth matching sid exactly.

Ross

Bug#1017848: netdata: systemd unit specifies syslog+console, but this is obsolete

[Daniel Baumann]

close 1017848 1.31.0-2
thanks

Hi,

On 8/21/22 15:14, Athanasius wrote:
> Aug 20 16:44:09 dot systemd[1]: /lib/systemd/system/netdata.service:55: 
> Standard output type syslog+console is obsolete, automatically updating to 
> journal+console. Please update your unit file, and consider removing the 
> setting altogether.

thank you for reporting, this has been fixed in above version in July
2021 already, thus marking the bug as fixed.

Regards,
Daniel

Bug#1016828: poc-streamer: flaky autopkgtest: regularly times out on i386

[Eriberto]

> I looked at the results of the autopkgtest of you package because it was
> showing up on our "slow" page [1]. I noticed that there were several
> runs that took 8:21 (our timeout time per test times 3), while
> successful runs more in the order of a minute.
>
> Because the unstable-to-testing migration software now blocks on
> regressions in testing, flaky tests, i.e. tests that flip between
> passing and failing without changes to the list of installed packages,
> are causing people unrelated to your package to spend time on these
> tests.
[...]
>
> [1] https://ci.debian.net/status/slow/

Hi Paul,

I noticed that superficial tests around pob-2250, pob-3119 and pob-fec
are failing. I set a timeout (3 minutes) for these tests and I set
them as flaky. I hope these procedures fix all issues.

Cheers,

Eriberto

Bug#1014511: sysvinit: debian/copyright reports incorrect licenses

[binh1.tranhai]

Hi Mark Hindley and Axel Beckert,

I sent an e-mail "sysvinit: License of debian/po/vi.po file" to Clytie Siddall 
from 2022/07/11
But maybe Clytie Siddall is busy in his/her work.
And I haven't received  any feedback from him/her.

Currently, we don't have any license information of debian/po/vi.po file.
I think that we should update copyright information of debian/po/vi.po in 
debian/copyright file follow 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014511#20
I didn't see it in copyright file or 
0001-d-copyright-add-missing-entries-and-sort-by-date-Clo.patch file at Mark 
Hindley's attachment.

Thanks,
Binh.


From: Mark Hindley 
Sent: Sunday, July 10, 2022 11:27 PM
To: Axel Beckert; 1014...@bugs.debian.org
Cc: tran hai binh(ＴＳＤＶ Ｅｎｇ　１)
Subject: Re: Bug#1014511: sysvinit: debian/copyright reports incorrect licenses

Thanks both.

Please find attached a new d/copyright file together with the diff. I have tried
to take your comments into account and make the file more complete and
consistent without introducing a level of specificity which may not be
warranted.

Any comments?

Thanks.

Mark

Bug#952159: rust-nodrop-union: FTBFS: dh_auto_test: error: /usr/share/cargo/bin/cargo build returned exit code 101

[Eric Long]

> Was this patch just a result of general QA activity or is there some 
> program you are trying to package?

Yes, this patch is for QA. I assumed there are important packages that rely
on this abandoned crate, hence the workaround. Otherwise removing it from
Debian seems a better choice.

Bug#1017888: adduser: in-adduser.conf documentation of defaults is unfortunate

[Christoph Anton Mitterer]

Package: adduser
Version: 3.127
Severity: minor


Hey.

The following is rather just cosmetics...

The new adduser.conf says:
# A commented out setting indicates that this is the default in the
# code. If you need to change those settings, remove the comment and
# make your intended change.


IMO that system of documenting defaults is generally unfortunate.

What may easily happen is, that people follow that advise but later
comment some value again without setting it back to the original
value (which, when commented, is - as per documentation above -
ought to be the default).


This can easily cause confusion on what's *actually* the default,
especially when multiple admins work on the system.



Perhaps it would be better to either include the defaults as written
comments as in:
# The DHOME variable specifies the directory containing users' home
# directories.
# Default: /home
#DHOME=/home

or not include the defaults in the actual conffile at all but just
in the manpage (IMO better, since that cannot (easily) be changed and
will always be up-to-date).

Same could btw. be done for the in-conffile documentation. Kinda overlaps
with the manpage, an just makes handling the file on upgrades
trickier.


Cheers,
Chris.

Bug#1014511: sysvinit: debian/copyright reports incorrect licenses

[binh1.tranhai]

Hi Mark Hindley and Axel Beckert,

I sent an e-mail "sysvinit: License of debian/po/vi.po file" to Clytie Siddall 
(cly...@riverland.net.au) from 2022/07/11
Maybe Clytie Siddall is busy in his/her work.
And I haven't received  any feedback from him/her.

Currently, we don't have any license information of debian/po/vi.po file.
I think that we should update copyright information of debian/po/vi.po in 
debian/copyright file follow 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014511#20
I didn't see it in copyright file or 
0001-d-copyright-add-missing-entries-and-sort-by-date-Clo.patch file at Mark 
Hindley's attachment.

Thanks,
Binh.

Bug#1017887: grub-efi-amd64-signed: SecureBoot Grub-Install with Custom Bootloader ID Drops Grub into Grub Shell

[Chew Kean Ho]

Package: grub-efi-amd64-bin
Version: 1+2.04+20
Severity: important
X-Debbugs-Cc: hollowaykea...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
When performing a manual grub-install in a debootstrap Debian OS setup,
installing SecureBoot Grub with --bootloader-id value other than 'debian' causes
the Grub to drop into Grub Shell (failed to locate /boot/grub/grub.cfg) despite
having the UUID and root prefix values correct at /boot/EFI//grub.cfg
level.

Exact cause is unknown (still not sure what causes the drop). The only
workaround is NOT to mess with the --bootloader-id or set --bootloader-id to
strictly 'debian' as value.

The same thing happens when SecureBoot is turned off at BIOS.

Investigation steps are properly documented, made available at:
https://salsa.debian.org/-/snippets/617


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

Don't mess with --bootloader-id or set --bootloader-id to 'debian' only have
the target OS bootable and not drop into Grub Shell.

Messing it with anything else than 'debian', Grub will drop into Grub Shell.


   * What was the outcome of this action?

Option is offered but not functioning as expected. At the moment, it's
compulsory not to use that option.


   * What outcome did you expect instead?

Some unknown bug(s) are fixed or detailed documentations are published regarding
the --bootloader-id usage.




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

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

Versions of packages grub-efi-amd64-signed depends on:
ii  grub-common  2.04-20

Versions of packages grub-efi-amd64-signed recommends:
ii  shim-signed  1.38+15.4-7

grub-efi-amd64-signed suggests no packages.

Versions of packages grub-efi-amd64-bin depends on:
ii  grub-common  2.04-20

Versions of packages grub-efi-amd64-bin recommends:
ii  efibootmgr  17-1

-- no debconf information

Bug#1017684: tiledb-r: ftbfs on riscv64("undefined symbol: __atomic_compare_exchange_1")

[Bo YU]

Hi,
On Sun, Aug 21, 2022 at 09:44:27PM -0500, Dirk Eddelbuettel wrote:


On 22 August 2022 at 10:20, Bo YU wrote:
| Hi,
| On Sun, Aug 21, 2022 at 09:41:39AM -0500, Dirk Eddelbuettel wrote:
| >
| >| Oh, yes, It is applied to debian/rules and I forget to mention it.:)
| >
| >No worries :)   Do you have easy-enough access to the platform?  Could you
| >test this diff (and then also run 'autoconf' to regenerate 'configure'; else
| >I can send you a longer diff including it).  And of course remove what we had
| >added to src/Makevars.in 'by hand'.
| >
| >
| >| modified   configure.ac
| >@@ -153,6 +153,13 @@ if test x"${uname}" = x"Darwin" -a x"${machine}" = 
x"x86_64"; then
| > AC_MSG_RESULT([${CXX17_MACOS}])
| > fi
| >
| >+## Take care of riscv64 machines and need for -latomic
| >+if test x"${uname}" = x"riscv64"; then
| >+AC_MSG_CHECKING([for riscv64 linker adjustment])
| >+CXX17_MACOS="-mmacosx-version-min=10.14"
| >+TILEDB_LIBS="${TILEDB_LIBS} -latomic"
| >+AC_MSG_RESULT([${TILEDB_LIBS}])
| >+fi
|
| It works except with word modifications:
|
| --- a/configure.ac
| +++ b/configure.ac
| @@ -153,6 +153,14 @@
|   AC_MSG_RESULT([${CXX17_MACOS}])
|   fi
|
| +## Take care of riscv64 machines and need for -latomic
| +if test x"${machine}" = x"riscv64"; then

Excellent catch. ${machine} is what uname -m is set to and what I meant.

| +AC_MSG_CHECKING([for riscv64 linker adjustment])
| +#CXX17_MACOS="-mmacosx-version-min=10.14"
| +TILEDB_LIBS="${TILEDB_LIBS} -latomic"
| +AC_MSG_RESULT([${TILEDB_LIBS}])
| +fi
| +
|
| And I tested it on real riscv64 hardware successfully.
|
| here:
|
| uname == linux
|
| CXX17_MACOS should be redundant and can be safely deleted:
| g++ -std=gnu++17 -shared -L/usr/lib/R/lib -Wl,-z,relro -o tiledb.so 
RcppExports.o arrowio.o batched.o deprecation.o durations.o libtiledb.o 
nullable.o shmem.o utilities.o -mmacosx-version-min=10.14 -ltiledb -latomic 
-L/usr/lib/R/lib -lR
| g++: error: unrecognized command-line option ‘-mmacosx-version-min=10.14’
| make[2]: *** [/usr/share/R/share/make/shlib.mk:10: tiledb.so] Error 1

The fail is from my version with typo, not your catch, correct?


yes. This error appeared in the original patch.

The patch that is tested on my real riscv64 hardware:
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1017684;filename=fix-ftbfs-riscv64.patch;msg=60
It is ok:)



Thanks for all your help on this,  Dirk


Np.



| --
| Regards,
| --
|Bo YU
|
| [DELETED ATTACHMENT fix-ftbfs-riscv64.patch, text/x-diff]
| [DELETED ATTACHMENT signature.asc, application/pgp-signature]

--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org


--
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1017684: tiledb-r: ftbfs on riscv64("undefined symbol: __atomic_compare_exchange_1")

[Dirk Eddelbuettel]

On 22 August 2022 at 10:20, Bo YU wrote:
| Hi,
| On Sun, Aug 21, 2022 at 09:41:39AM -0500, Dirk Eddelbuettel wrote:
| >
| >| Oh, yes, It is applied to debian/rules and I forget to mention it.:)
| >
| >No worries :)   Do you have easy-enough access to the platform?  Could you
| >test this diff (and then also run 'autoconf' to regenerate 'configure'; else
| >I can send you a longer diff including it).  And of course remove what we had
| >added to src/Makevars.in 'by hand'.
| >
| >
| >| modified   configure.ac
| >@@ -153,6 +153,13 @@ if test x"${uname}" = x"Darwin" -a x"${machine}" = 
x"x86_64"; then
| > AC_MSG_RESULT([${CXX17_MACOS}])
| > fi
| >
| >+## Take care of riscv64 machines and need for -latomic
| >+if test x"${uname}" = x"riscv64"; then
| >+AC_MSG_CHECKING([for riscv64 linker adjustment])
| >+CXX17_MACOS="-mmacosx-version-min=10.14"
| >+TILEDB_LIBS="${TILEDB_LIBS} -latomic"
| >+AC_MSG_RESULT([${TILEDB_LIBS}])
| >+fi
| 
| It works except with word modifications:
| 
| --- a/configure.ac
| +++ b/configure.ac
| @@ -153,6 +153,14 @@
|   AC_MSG_RESULT([${CXX17_MACOS}])
|   fi
| 
| +## Take care of riscv64 machines and need for -latomic
| +if test x"${machine}" = x"riscv64"; then

Excellent catch. ${machine} is what uname -m is set to and what I meant.

| +AC_MSG_CHECKING([for riscv64 linker adjustment])
| +#CXX17_MACOS="-mmacosx-version-min=10.14"
| +TILEDB_LIBS="${TILEDB_LIBS} -latomic"
| +AC_MSG_RESULT([${TILEDB_LIBS}])
| +fi
| +
| 
| And I tested it on real riscv64 hardware successfully.
| 
| here:
| 
| uname == linux 
| 
| CXX17_MACOS should be redundant and can be safely deleted:
| g++ -std=gnu++17 -shared -L/usr/lib/R/lib -Wl,-z,relro -o tiledb.so 
RcppExports.o arrowio.o batched.o deprecation.o durations.o libtiledb.o 
nullable.o shmem.o utilities.o -mmacosx-version-min=10.14 -ltiledb -latomic 
-L/usr/lib/R/lib -lR
| g++: error: unrecognized command-line option ‘-mmacosx-version-min=10.14’
| make[2]: *** [/usr/share/R/share/make/shlib.mk:10: tiledb.so] Error 1

The fail is from my version with typo, not your catch, correct?

Thanks for all your help on this,  Dirk

 
| -- 
| Regards,
| --
|Bo YU
| 
| [DELETED ATTACHMENT fix-ftbfs-riscv64.patch, text/x-diff]
| [DELETED ATTACHMENT signature.asc, application/pgp-signature]

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1017684: tiledb-r: ftbfs on riscv64("undefined symbol: __atomic_compare_exchange_1")

[Bo YU]

Hi,
On Sun, Aug 21, 2022 at 09:41:39AM -0500, Dirk Eddelbuettel wrote:


| Oh, yes, It is applied to debian/rules and I forget to mention it.:)

No worries :)   Do you have easy-enough access to the platform?  Could you
test this diff (and then also run 'autoconf' to regenerate 'configure'; else
I can send you a longer diff including it).  And of course remove what we had
added to src/Makevars.in 'by hand'.


| modified   configure.ac
@@ -153,6 +153,13 @@ if test x"${uname}" = x"Darwin" -a x"${machine}" = 
x"x86_64"; then
AC_MSG_RESULT([${CXX17_MACOS}])
fi

+## Take care of riscv64 machines and need for -latomic
+if test x"${uname}" = x"riscv64"; then
+AC_MSG_CHECKING([for riscv64 linker adjustment])
+CXX17_MACOS="-mmacosx-version-min=10.14"
+TILEDB_LIBS="${TILEDB_LIBS} -latomic"
+AC_MSG_RESULT([${TILEDB_LIBS}])
+fi


It works except with word modifications:

--- a/configure.ac
+++ b/configure.ac
@@ -153,6 +153,14 @@
 AC_MSG_RESULT([${CXX17_MACOS}])
 fi

+## Take care of riscv64 machines and need for -latomic
+if test x"${machine}" = x"riscv64"; then
+AC_MSG_CHECKING([for riscv64 linker adjustment])
+#CXX17_MACOS="-mmacosx-version-min=10.14"
+TILEDB_LIBS="${TILEDB_LIBS} -latomic"
+AC_MSG_RESULT([${TILEDB_LIBS}])
+fi
+

And I tested it on real riscv64 hardware successfully.

here:

uname == linux 


CXX17_MACOS should be redundant and can be safely deleted:
g++ -std=gnu++17 -shared -L/usr/lib/R/lib -Wl,-z,relro -o tiledb.so 
RcppExports.o arrowio.o batched.o deprecation.o durations.o libtiledb.o 
nullable.o shmem.o utilities.o -mmacosx-version-min=10.14 -ltiledb -latomic 
-L/usr/lib/R/lib -lR
g++: error: unrecognized command-line option ‘-mmacosx-version-min=10.14’
make[2]: *** [/usr/share/R/share/make/shlib.mk:10: tiledb.so] Error 1


--
Regards,
--
  Bo YU

--- a/configure.ac
+++ b/configure.ac
@@ -153,6 +153,14 @@
 AC_MSG_RESULT([${CXX17_MACOS}])
 fi
 
+## Take care of riscv64 machines and need for -latomic
+if test x"${machine}" = x"riscv64"; then
+AC_MSG_CHECKING([for riscv64 linker adjustment])
+#CXX17_MACOS="-mmacosx-version-min=10.14"
+TILEDB_LIBS="${TILEDB_LIBS} -latomic"
+AC_MSG_RESULT([${TILEDB_LIBS}])
+fi
+
 
 ## -- Part 3: Check for TileDB --
 ##


signature.asc
Description: PGP signature

Bug#1017886: transition: zimlib

[Kunal Mehta]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: lego...@debian.org

Hi,

I'd like to do a transition of libzim 7->8. I've done local rebuilds
of all the reverse dependencies, python-libzim needs a patch (ready in
experimental), and all the rest (zim-tools, libkiwix, kiwix-tools, kiwix)
will need binNMUs.

Ben file:

title = "zimlib";
is_affected = .depends ~ "libzim7" | .depends ~ "libzim8";
is_good = .depends ~ "libzim8";
is_bad = .depends ~ "libzim7";

Thanks!
-- Kunal

Bug#1012289: Some questions about dpatch-related checks inside lintian (was: Re: Bug#1012289: RFH: lintian -- Debian package checker)

[Axel Beckert]

Hi again,

this mail contains several points. I separated them with markdown-like
headlines.


Removing dpatch stuff from Lintian?
---

Axel Beckert wrote:
> Bastien Roucariès wrote:
> > could you please check why autotest fail
> 
> Done now:
> 
> Lintian's autopkgtest fails on Salsa for a week now because dpatch has
> been removed from unstable a week ago: https://bugs.debian.org/1010626
> (Cc'ed)
[…]
> dpatch seems to be mentioned in 269 files of the test suite. I assume
> that at least all dpatch related tags can be removed now as there's no
> point in arguing about dpatch being used (or even used wrongly) if any
> package using it will FTBFS anyway.

Then again most of these cases seem to be the same case which was
split up in dozen cases (of which most still use but actually don't
seem to require dpatch anymore) when the test suite was changed from
running all checks against all test suite packages to running just
specific checks against each test suite package.

In other words: Code duplication and cruft at its best! :-(

But this also means that

a) in many cases we can just remove all the dpatch cruft without any
   impact. It's just not yet clear to me which cases those are were we
   can't remove the dpatch cruft.

b) It's currently unclear to me which test suite packages are just
   checked for source package checks. Those likely don't need dpatch
   as it's not needed to build the .dsc source package files.

So after a first try with removing all traces of dpatch, I decided
otherwise and I tried to just remove dpatch from debian/tests/control
and see what happens. I used a feature branch called "dpatch-removal"
for that (which I likely will force-push occasionally).


New test suite failures after dropping dpatch
-

But what happened was something completely unexpected and unrelated to
dpatch:

Errors were encountered while processing:
 emacs-nox
 dh-elpa
 autopkgtest-satdep

So this time it was the still very RC-buggy emacs 28.1 upload which
broke our test suite. *sigh*

I guess in this case we just have to wait until the emacs package is
fixed again.

At least locally we can still use emacs from testing for testing, but
that also makes it a bit more annoying if I later need dpatch again
in case I need to convert some test package with quilt2dpatch which
actually uses dpatch. (Hmmm, quilt ships that script, but has no
package relation with dpatch. Isn't that an RC bug?!? SCNR ;-)


What about the tags patch-system and more-than-one-patch-system?


Another question which popped up is if we still need that
classification tag "patch-system" and the warning
"more-than-one-patch-system" since these only new about quilt and
dpatch and nothing more. So shall we remove these completely? Or keep
the dpatch detection?


More test suite failures / How to run the test suite


Additionally the test suite now fails due to
lib/Lintian/Check/Cruft.pm no more being tidy:

Failed test 'Test::Perl::Critic for "lib/Lintian/Check/Cruft.pm"'
#   at /usr/share/perl5/Test/Perl/Critic.pm line 121.
#
#   lib/Lintian/Check/Cruft.pm:82:1:Use '{' and '}' to delimit multi-line 
regexps
#   lib/Lintian/Check/Cruft.pm:107:1:Use '{' and '}' to delimit multi-line 
regexps
#   lib/Lintian/Check/Cruft.pm:232:17:Useless use of $_
#   lib/Lintian/Check/Cruft.pm:238:1:Subroutine "full_text_check" does not end 
with "return"
#   lib/Lintian/Check/Cruft.pm:249:21:Subroutine called with "&" sigil
#   lib/Lintian/Check/Cruft.pm:263:9:"%matchedkeyword" is declared but not used

(And after fixing these, some more return-related issues inside
full_text_check popped up.)

I've tried to fix these. Will push that commit later today if the test
suite run currently running here locally doesn't find anything
related. (Usually such a run takes around 40 minutes here and I really
should go to bed now.)

Hint: The test suite can be run by calling "private/runtests" nowadays.

P.S.: I'm generally open to changing what perlcritic considers bad and
what not inside lintian. For now I just haven't changed anything, but
am not 100% happy with the current settings.

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


signature.asc
Description: PGP signature

Bug#1017537: armel buildd misconfiguration (was Re: Bug#1017537: dietlibc: FTBFS on armel)

[Thorsten Glaser]

outlook 1017537 some armel buildds are misconfigured and lack SWP emulation
thanks

Dixi quod…

># if __ARM_ARCH__ < 6
>   swp r0, r1, [r2]
># else

And this, after some research, is it. This is needed for armel, which
is v5. Apparently, Linux has SWP emulation for v7/v8 hosts, but at least
one buildd listed does not have this enabled, breaking the armel ABI.

Please ensure that only hosts with working SWP emulation run armel.

(Can I reassign this bugreport to the buildd? Does it have a virtual
package in debbugs?)

Until then, I guess I’ll keep giveback’ing dietlibc on armel until
it builds…

bye,
//mirabilos
-- 
 den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt…
oder netzteile, an die man auch den monitor angeschlossen hat und die dann für
ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder
LAN party │  damals, als der pizzateig noch auf dem monior "gegangen" ist

Bug#1017885: dictionaries-common: debian-ispell.el triggers warnings in Emacs

[Vincent Lefevre]

Package: dictionaries-common
Version: 1.28.16
Severity: important

When running Emacs, its window is sometimes split to show warnings
in the bottom part (this occurred twice in a few days, after the
upgrade to Emacs 28.1):

Warning (comp): debian-ispell.el:229:17: Warning: assignment to free variable 
‘really-hunspell’ Disable showing Disable logging
Warning (comp): debian-ispell.el:228:28: Warning: reference to free variable 
‘really-hunspell’ Disable showing Disable logging
Warning (comp): debian-ispell.el:392:16: Warning: reference to free variable 
‘ispell-local-dictionary’ Disable showing Disable logging
Warning (comp): debian-ispell.el:403:24: Warning: assignment to free variable 
‘ispell-base-dicts-override-alist’ Disable showing Disable logging
Warning (comp): debian-ispell.el:403:20: Warning: reference to free variable 
‘ispell-base-dicts-override-alist’ Disable showing Disable logging
Warning (comp): debian-ispell.el:489:15: Warning: the function 
‘ispell-set-spellchecker-params’ is not known to be defined. Disable showing 
Disable logging

This is rather annoying.

-- 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')
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.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 dictionaries-common depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  emacsen-common 3.0.4
ii  libtext-iconv-perl 1.7-7+b2

dictionaries-common recommends no packages.

Versions of packages dictionaries-common suggests:
ii  aspell0.60.8-4
ii  hunspell  1.7.0-4
ii  ispell3.4.05-1
ii  wamerican [wordlist]  2020.12.07-2

-- debconf information:
  dictionaries-common/ispell-autobuildhash-message:
  dictionaries-common/selecting_ispell_wordlist_default:
* dictionaries-common/default-wordlist: american (American English)
  dictionaries-common/old_wordlist_link: true
  dictionaries-common/invalid_debconf_value:
  dictionaries-common/debconf_database_corruption:
  dictionaries-common/default-ispell: american (American English)

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

Bug#1017711: emacs-gtk: terminated with signal SIGABRT, 137 MB coredump

[Vincent Lefevre]

Control: found -1 1:28.1+1-2
Control: severity -1 serious

On 2022-08-19 12:10:31 +0200, Vincent Lefevre wrote:
> I have noticed that Emacs left a 137 MB coredump.

This has occurred again (this time a 54 MB coredump).
This is going to use much disk space...

> gdb says:
> 
> Reading symbols from /usr/bin/emacs...
> Reading symbols from 
> /usr/lib/debug/.build-id/d0/b7c40dc33110b0623ea2ca797a6d3f3eb166b5.debug...
> [New LWP 1483812]
> [New LWP 1483816]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `/usr/bin/emacs --batch -l 
> /tmp/emacs-async-comp-cc-engine.el-2UV1nf.el'.

This time,

Core was generated by `/usr/bin/emacs --batch -l 
/tmp/emacs-async-comp-auth-source.el-84YT0a.el'.
Program terminated with signal SIGABRT, Aborted.

I'm wondering whether this is related to bug 1017845, as a
"/usr/bin/emacs --batch -l /tmp/emacs-async-..." is also involved.

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

Bug#1017537: dietlibc: FTBFS on armel

[Thorsten Glaser]

Dixi quod…

>In case this makes anyone immediately think of whatever it is:

Code looks right enough (with an explanation of why this only
fails on armel but not on armhf which is perfectly fine):

$ cat arm/__testandset.S
#include "arm-features.h"

FUNC_START  __testandset
mov r2, r0
mov r1, #1
# if __ARM_ARCH__ < 6
swp r0, r1, [r2]
# else
1:  ldrex   r0, [r2]
strex   r3, r1, [r2]
cmp r3, #0
bne 1b
# endif
RET
FUNC_END__testandset

bye,
//mirabilos
-- 
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival

Bug#1017876: dropbear autopkgtest fails if ~/.ssh already exists

[Guilhem Moulin]

Control: tag -1 pending

Hi Steve,

On Sun, 21 Aug 2022 at 16:09:24 -0700, Steve Langasek wrote:
> The dropbear autopkgtest has been failing on all architectures in Ubuntu,
> because it tries to mkdir ~/.ssh and fails if this directory already exists.
> 
> The attached patch calls mkdir with -p, so that the call does not fail if the
> directory already exists.
> 
> Please consider including this patch in Debian.

Pushed to salsa, thanks for the patch!

(IIRC this was intentional at first to avoid being tempted to run 
d/t/upstream-tests
manually and mess up with the local environment, but the check for 
$AUTOPKGTEST_TMP
is a better guard against such mishaps.)

Cheers
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1017537: dietlibc: FTBFS on armel

[Thorsten Glaser]

>but it ALSO fails in a bullseye chroot, so this is possibly not related

In case this makes anyone immediately think of whatever it is:

(gdb) r
Starting program: /home/tg/dietlibc-0.34~cvs20160606-el-11/debian/unittests/ttt

Program received signal SIGILL, Illegal instruction.
__testandset () at arm/__testandset.S:7
7   swp r0, r1, [r2]
(gdb) bt
#0  __testandset () at arm/__testandset.S:7
#1  0x000113d4 in __pthread_lock (lock=lock@entry=0x25054 <_main_thread+20>) at 
libpthread/pthread_spinlock.c:84
#2  0x0001052c in __thread_find_ (pid=) at 
libpthread/pthread_internal.c:98
#3  0x00010578 in __thread_self () at libpthread/pthread_internal.c:127
#4  0x00010280 in malloc (size=32) at libpthread/pthread_sys_alloc.c:20
#5  0x00010124 in main ()
(gdb) info r
r0 0x25054 151636
r1 0x1 1
r2 0x25054 151636
r3 0x0 0
r4 0x0 0
r5 0x25054 151636
r6 0x0 0
r7 0x1e8481201
r8 0x1016
r9 0xfffef684  4294899332
r100xfffef68c  4294899340
r110xfffef67c  4294899324
r120x1420
sp 0xfffef3c0  0xfffef3c0
lr 0x113d4 70612
pc 0x11480 0x11480 <__testandset+8>
cpsr   0x6010  1610612752
fpscr  0x0 0
(gdb) disas
Dump of assembler code for function __testandset:
   0x00011478 <+0>: mov r2, r0
   0x0001147c <+4>: mov r1, #1
=> 0x00011480 <+8>: swp r0, r1, [r2]
   0x00011484 <+12>:bx  lr
End of assembler dump.

Bug#1017537: dietlibc: FTBFS on armel

[Thorsten Glaser]

outcome 1017537 fails on porterbox/bullseye as well, suspect 64-bit host to be 
an issue
tags 1017537 + help
thanks

In contrast to armhf, which works fine on the porterbox (amdahl; abel,
which I normally use, is currently down) for me, this one also fails,
but it ALSO fails in a bullseye chroot, so this is possibly not related
to a toolchain change.

I think I’ll have to track down a 32-bit ARM machine and test-build it
there. I recently got gifted a Raspbery Pi v1.2 so that’d be running
armel anyway, so I guess it’s installing Debian on that thing for me now.

bye,
//mirabilos
-- 
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent

Bug#1017538: dietlibc: FTBFS on armhf

[Thorsten Glaser]

tags 1017538 + unreproducible
thanks

This builds fine in a sid-armhf chroot on amdahl.

Bug#1017884: reportbug: qemu-system-x86_64 freezes after i access samba server on a windows-xp host

[Usama Makhzoum]

Package: qemu-system-x86
Version: 1:7.0+dfsg-7+b1
Severity: important
X-Debbugs-Cc: osma...@gmail.com


I use qemu as the following:

/usr/bin/qemu-system-x86_64  -soundhw ac97 -machine accel=kvm -m 1033 -cdrom
windowsxp.iso -hda windowsxp.img -boot once=d,menu=off -net nic,model=rtl8139
-net user -net user,smb="/path/to/shared/folder/inside/my/home" -rtc
base=localtime -name "Windows XP x32"


it boots normally after installation, but when i access shared folder (just by
typing qemu user network ip "\\10.0.2.2\qemu") inside the run dialog everything
freezed , i can't even grab my pointer outside qemu window without
restarting window manager.


i also have this inside my smb.conf




==
#
# Sample configuration file for the Samba suite for Debian GNU/Linux.
#
#
# This is the main Samba configuration file. You should read the
# smb.conf(5) manual page in order to understand the options listed
# here. Samba has a huge number of configurable options most of which
# are not shown in this example
#
# Some options that are often worth tuning have been included as
# commented-out examples in this file.
#  - When such options are commented with ";", the proposed setting
#differs from the default Samba behaviour
#  - When commented with "#", the proposed setting is the default
#behaviour of Samba but the option is considered important
#enough to be mentioned here
#
# NOTE: Whenever you modify this file you should run the command
# "testparm" to check that you have not made any basic syntactic
# errors.

#=== Global Settings ===

[global]

## Browsing/Identification ###

# Change this to the workgroup/NT-domain name your Samba server will part of
   workgroup = WORKGROUP

 Networking 

# The specific set of interfaces / networks to bind to
# This can be either the interface name or an IP address/netmask;
# interface names are normally preferred
;   interfaces = 127.0.0.0/8 eth0

# Only bind to the named interfaces and/or networks; you must use the
# 'interfaces' option above to use this.
# It is recommended that you enable this feature if your Samba machine is
# not protected by a firewall or is a firewall itself.  However, this
# option cannot handle dynamic or non-broadcast interfaces correctly.
;   bind interfaces only = yes



 Debugging/Accounting 

# This tells Samba to use a separate log file for each machine
# that connects
   log file = /var/log/samba/log.%m

# Cap the size of the individual log files (in KiB).
   max log size = 1000

# We want Samba to only log to /var/log/samba/log.{smbd,nmbd}.
# Append syslog@1 if you want important messages to be sent to syslog too.
   logging = file

# Do something sensible when Samba crashes: mail the admin a backtrace
   panic action = /usr/share/samba/panic-action %d


### Authentication ###

# Server role. Defines in which mode Samba will operate. Possible
# values are "standalone server", "member server", "classic primary
# domain controller", "classic backup domain controller", "active
# directory domain controller".
#
# Most people will want "standalone server" or "member server".
# Running as "active directory domain controller" will require first
# running "samba-tool domain provision" to wipe databases and create a
# new domain.
   server role = standalone server

   obey pam restrictions = yes

# This boolean parameter controls whether Samba attempts to sync the Unix
# password with the SMB password when the encrypted SMB password in the
# passdb is changed.
   unix password sync = yes

# For Unix password sync to work on a Debian GNU/Linux system, the following
# parameters must be set (thanks to Ian Kahan < for
# sending the correct chat script for the passwd program in Debian Sarge).
   passwd program = /usr/bin/passwd %u
   passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:*
%n\n *password\supdated\ssuccessfully* .

# This boolean controls whether PAM will be used for password changes
# when requested by an SMB client instead of the program listed in
# 'passwd program'. The default is 'no'.
   pam password change = yes

# This option controls how unsuccessful authentication attempts are mapped
# to anonymous connections
   map to guest = bad user

## Domains ###

#
# The following settings only takes effect if 'server role = classic
# primary domain controller', 'server role = classic backup domain controller'
# or 'domain logons' is set
#

# It specifies the location of the user's
# profile directory from the client point of view) The following
# required a [profiles] share to be setup on the samba server (see
# below)
;   logon path = \\%N\profiles\%U
# Another common choice is storing the profile in the user's home directory
# (this is Samba's default)
#   logon path = \\%N\%U\profile

# The following setting only takes effect if 'domain logons' is set
# It

Bug#1017873: RFA: pikepdf

[Sean Whitton]

Hello,

On Sun 21 Aug 2022 at 02:55PM -07, Sean Whitton wrote:

>
> Package: wnpp
> Severity: normal
> X-Debbugs-Cc: debian-pyt...@lists.debian.org, barlow@gmail.com
> Control: affects -1 src:pikepdf
>
> I request an adoptor for the pikepdf package.  It would be better if
> someone with more knowledge of either or both Python and PDFs were to
> maintain it.  I have also filed an RFA for ocrmypdf, the most important
> reverse dependency.

Looks like it has more rdeps these days than I realised!  ocrmypdf is
not the most important of them, apologies!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1017883: O: emacs-noflet -- Emacs Lisp noflet macro for dynamic, local advice

[Sean Whitton]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-emac...@lists.debian.org
Control: affects -1 src:emacs-noflet

I hereby orphan the emacs-noflet package.  I don't use it anymore, and
it would be better if someone who did maintains it.

This is a team-maintained package, so the adoptor should either replace
me in Uploaders:, or alternatively take the package out of the team's
hands.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1017882: O: pkg-info-el -- Emacs Lisp library providing information about Emacs packages

[Sean Whitton]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-emac...@lists.debian.org
Control: affects -1 src:pkg-info-el

I hereby orphan the pkg-info-el package.

This is a team-maintained package, so the adoptor should either replace
me in Uploaders:, or alternatively take the package out of the team's
hands.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1017881: O: unclutter-xfixes -- hide the X mouse cursor after a period of inactivity, using XFixes

[Sean Whitton]

Package: wnpp
Severity: normal
Control: affects -1 src:unclutter-xfixes

I hereby orphan the unclutter-xfixes package.  I have been using
exclusively Wayland for more than a year, so don't use this anymore.

The package description is:
 unclutter-xfixes is a rewrite of the popular tool unclutter, but
 using the x11-xfixes extension.  It has fewer bugs when used with
 modern applications and window managers.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1017880: O: emacs-pg-el -- Emacs Lisp interface for PostgreSQL

[Sean Whitton]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-emac...@lists.debian.org
Control: affects -1 src:emacs-pg-el

I hereby orphan the emacs-pg-el package.

This package is no longer in my init.el and it would be better if
someone who actually uses the package maintains it.

This is a team-maintained package, so the adoptor should either replace
me in Uploaders:, or alternatively take the package out of the team's
hands.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1017879: O: emacs-async -- simple library for asynchronous processing in Emacs

[Sean Whitton]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-emac...@lists.debian.org
Control: affects -1 src:emacs-async

I hereby orphan the emacs-async package.

This package has not been in my init.el for around years and it would be
better if someone who actually uses the package maintains it.

This is a team-maintained package, so the adoptor should either replace
me in Uploaders:, or alternatively take the package out of the team's
hands.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1017878: O: stylish-haskell -- Haskell code prettifier

[Sean Whitton]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-hask...@lists.debian.org
Control: affects -1 src:stylish-haskell

I hereby orphan the stylish-haskell package.

The package description is:
 stylish-haskell prettifies Haskell code.  A design goal is not
 getting in the user's way, so it restricts itself to formatting only
 some parts of the Haskell code piped to it, such as import
 statements.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1017877: ITP: reload4j -- Drop-in replacement for Apache log4j 1.2 Java logging framework

[tony mancill]

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

* Package name: reload4j
  Version : 1.2.22
  Upstream Author : Ceki Gülcü
* URL : https://reload4j.qos.ch/
* License : Apache 2.0
  Programming Lang: Java
  Description : Drop-in replacement for Apache log4j 1.2 Java logging 
framework

The reload4j project is a fork of Apache log4j version 1.2.17 in order
to fix most pressing security issues. It is intended as a drop-in
replacement for log4j version 1.2.17. By drop-in, we mean the
replacement of log4j.jar with reload4j.jar in your build without needing
to make changes to source code, i.e., to your java files.

With release 1.2.18.0 and later, the reload4j project offers a clear and
easy migration path for the thousands of users who have an urgent need
to fix vulnerabilities in log4j 1.2.17.

This is being packaged because it is a dependency of slf4j [1] since
version 1.7.33 (Debian currently ships version 1.7.32 [2]) and because a
number of upstream projects have switched to reload4j.  Having a
separate reload4j source package will allow us to provide a clean
transition from liblog4j1.2-java -> libreload4j-java and fully EOL
Apache log4j 1.2.

[1] https://www.slf4j.org/
[2] https://tracker.debian.org/pkg/libslf4j-java


signature.asc
Description: PGP signature

Bug#1017876: dropbear autopkgtest fails if ~/.ssh already exists

[Steve Langasek]

Package: dropbear
Version: 2022.82-3
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch

Hi Guilhem,

The dropbear autopkgtest has been failing on all architectures in Ubuntu,
because it tries to mkdir ~/.ssh and fails if this directory already exists.

The attached patch calls mkdir with -p, so that the call does not fail if the
directory already exists.

Please consider including this patch in Debian.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru dropbear-2022.82/debian/tests/upstream-tests 
dropbear-2022.82/debian/tests/upstream-tests
--- dropbear-2022.82/debian/tests/upstream-tests2022-04-04 
14:32:24.0 -0700
+++ dropbear-2022.82/debian/tests/upstream-tests2022-08-21 
16:05:02.0 -0700
@@ -17,7 +17,7 @@
 cd ./test
 
 # setup as in .github/workflows/build.yml
-mkdir -vm0700 ~/.ssh
+mkdir -p -vm0700 ~/.ssh
 $DROPBEARKEY -t ecdsa -f ~/.ssh/id_dropbear | grep ^ecdsa 
>~/.ssh/authorized_keys
 $DROPBEARKEY -t ecdsa -f ~/.ssh/id_dropbear_key2 | grep ^ecdsa | sed 's/[^ 
]*$/key2 extra/' >>~/.ssh/authorized_keys
 $DROPBEARKEY -t ecdsa -f ~/.ssh/id_dropbear_key3 | grep ^ecdsa | sed 's/[^ 
]*$/key3%char/' >>~/.ssh/authorized_keys

Bug#1012809: bump severity for poppler transition

[Jeremy Bicha]

Control: severity -1 serious

poppler 22.08 is in Unstable now.

Thank you,
Jeremy Bicha

Bug#1017875: RFS: blender-doc/3.2-1 [ITP] -- Blender Manual by the Blender Foundation

[Jonathan Rubenstein]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-multime...@lists.debian.org

Dear mentors and debian-multimedia,

I am looking for a sponsor for my package "blender-doc":

 * Package name: blender-doc
   Version : 3.2-1
   Upstream Author : Blender Documentation Team 
 * URL : https://docs.blender.org/manual/
 * License : CC-BY-SA-4.0
 * Vcs : https://salsa.debian.org/JJRcop/blender-doc
   Section : doc

The source builds the following binary packages:

  blender-doc - Blender Manual by the Blender Foundation

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


  https://mentors.debian.net/package/blender-doc/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/blender-doc/blender-doc_3.2-1.dsc


Changes for the initial release:

 blender-doc (3.2-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1006255)


Additional notes:

I am currently having trouble with lintian reporting source-is-missing 
because one of a file having very-long-line-length-in-source-file. I'm 
not sure how to solve this issue while conforming to Debian Policy, and 
need some help.


I'm sure this package needs a little bit of care as well in the control 
file, but otherwise I have tested it many times and it works the way I 
expect it, and as far as I know follows Debian Policy, but what do I know?


Regards,
--
  Jonathan Rubenstein

Bug#1016750: [Sbcl-bugs] Heap exhaustion problem with SBCL 2.2.6 on armel, armhf

[Sean Whitton]

Hello,

On Tue 09 Aug 2022 at 02:53PM -04, Douglas Katzman wrote:

>
> https://ci.debian.net/data/autopkgtest/testing/armhf/c/cl-ironclad/24441370/log.gz
> shows a GC invariant failure, not a heap exhaustion.
> How do I identify the exact git revision of SBCL you're using? I can only 
> guess at what
> line# failed an assertion in my current tree.

I've just updated SBCL in Debian to 2.2.7 and dropped two patches
included in that release, which simplifies things a bit.  ci.debian.net
will re-run the cl-ironclad test suite soon.  Let me know if it would be
useful for me to file a Launchpad bug gathering the various links
together.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1017874: music: no means to add music files

[Tom Kayser]

Source: music
Version: 3.36.7
Severity: important
X-Debbugs-Cc: foren...@milwpc.com

I opened the program, and expected to be able 
to add music files to build playlists.

I couldn't find a way to do it. I later 
discovered it is not possible.

Maybe some means to add music files could 
be added to music.


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

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

Bug#956012: Frightening!

[Andres Salomon]

I agree that it's a pretty annoying and scary message (and incorrect - 
"If a software program on your system has set enterprise policies that 
affect how Chrome works, you’ll see this message—even if it’s not 
fully managed by an organization." 
https://www.howtogeek.com/410106/why-does-chrome-say-its-managed-by-your-organization/ 
).


I'll switch it to using master_preferences so that message goes away, 
although it also means that some people who were switched to DDG will 
be switched back to Google.

On Sun, Aug 21, 2022 at 22:12, Steve McIntyre  wrote:



Nod. Even as an experienced user and developer, I was very surprised
to see this message. I have quite a few account identities set up in
my Chromium (e.g. for Google services), but I would never expect any
of them to be described as managing it.

--
Steve McIntyre, Cambridge, UK.
st...@einval.com

"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike 
Andrews

Bug#1017845: Endless fork loop at installation time: /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-7363726f6c6c2d6f746865722d77696e646f77_scroll_other_window_0-.el

[Axel Beckert]

Control: severity -1 grave
Control: retitle -1 emacs-common: Endless fork loop at installation and at run 
time: /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-_{scroll_other_window,delete_frame}_0-.el

Hi,

raising from serious (package installation fails) to grave (unusable)
as starting emacs ends (or rather does not starting) in an endless
loop for me now as well:

Axel Beckert wrote:
> > So far I had to unsinstall the following packages to make it go away,
> > i.e. these packages trigger the issue:
[List fixed to give actual package names]
> > elpa-folding
> > elpa-org
> > elpa-git-timemachine
> > elpa-password-store
> > 
> > There might be more.
> 
> Another one:
> 
> elpa-git-commit

In the meanwhile I also found elpa-smart-mode-line-powerline-theme and
elpa-ement being affected.

After removing all these packages and their reverse dependencies,
emacs' package installation finally passed through without endless
loops.

But when starting emacs, a very similar despite not identical endless
loop showed up — even twice and in parallel:

abe  25900  1.4  0.0 249576 60944 pts/14   Sl   23:53   0:01  \_ 
emacs
abe  25902  2.4  0.0 254052 61232 pts/20   Ssl+ 23:53   0:03  |   
\_ /usr/bin/emacs --batch -l /tmp/emacs-async-comp-seq-25-EX7HYr.el
abe  25908  2.4  0.0 254056 61284 ?Ssl  23:54   0:03  |   | 
  \_ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-Oknfek.el
abe  25913  2.4  0.0 254060 61256 ?Ssl  23:54   0:03  |   | 
  \_ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-LRg59v.el
abe  25917  2.5  0.0 254056 61060 ?Ssl  23:54   0:03  |   | 
  \_ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-V984rp.el
abe  25927  2.5  0.0 254060 63184 ?Ssl  23:54   0:02  |   | 
  \_ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-36KQ3Y.el
abe  25931  2.6  0.0 254056 61212 ?Ssl  23:54   0:03  |   | 
  \_ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-rc7Hc7.el
abe  25943  2.8  0.0 254060 61184 ?Ssl  23:54   0:03  |   | 
  \_ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-iHJ6VG.el
abe  25959  2.8  0.0 254056 61176 ?Ssl  23:54   0:03  |   | 
  \_ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-KPWHZf.el
abe  25973  2.8  0.0 254060 61284 ?Ssl  23:54   0:02  |   | 
  \_ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-ujNMu4.el
abe  25987  2.8  0.0 254056 61292 ?Ssl  23:54   0:02  |   | 
  \_ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-5spOXr.el
abe  25998  3.0  0.0 254060 61228 ?Ssl  23:54   0:02  |   | 
  \_ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-QU5Rk4.el
abe  26002  3.1  0.0 254056 61220 ?Ssl  23:54   0:02  |   | 
  \_ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-knkQvC.el
abe  26006  3.3  0.0 254060 61248 ?Ssl  23:54   0:03  |   | 
  \_ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-emW4ym.el
abe  26016  3.3  0.0 254056 61352 ?Ssl  23:54   0:02  |   | 
  \_ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-CGyFmX.el
abe  26035  3.4  0.0 254060 61276 ?Ssl  23:54   0:02  |   | 
  \_ /usr/bin/emacs --batch 
-l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-Rfnh3y.el
abe  26050  3.6  0.0 254056 63220 ?Ssl  23:54   0:02  |   | 
  \_ /usr/bin/emacs 
--batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-yb58VI.el
abe  26062  3.8  0.0 254060 61228 ?Ssl  23:54   0:03  |   | 
  \_ /usr/bin/emacs 
--batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-Y0EkN7.el
abe  2606

Bug#1017871: shiny-server: server-function don't run

[Krüger]

I forgot: The same problem exists on Debian/testing.

Bug#1017873: RFA: pikepdf

[Sean Whitton]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-pyt...@lists.debian.org, barlow@gmail.com
Control: affects -1 src:pikepdf

I request an adoptor for the pikepdf package.  It would be better if
someone with more knowledge of either or both Python and PDFs were to
maintain it.  I have also filed an RFA for ocrmypdf, the most important
reverse dependency.

The package description is:
 pikepdf is a Python library to read and write PDFs with QPDF.
 Features include:
 .
   * Editing, manipulation and transformation of existing PDFs
   * Based on the mature, proven QPDF C++ library
   * Works with encrypted PDFs
   * Supports all PDF compression filters
   * Can create "fast web view" (linearized) PDFs
   * Creates standards compliant PDFs that pass validation in other tools
   * Automatically repairs damaged PDFs, just like QPDF
   * Implements more of the PDF specification than existing Python PDF tools
   * IPython notebook and Jupyter integration

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1017872: RFA: ocrmypdf -- add an OCR text layer to PDF files

[Sean Whitton]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-pyt...@lists.debian.org, barlow@gmail.com
Control: affects -1 src:ocrmypdf

I request an adopter for the ocrmypdf package.  I don't use it as often
as I did (hardly ever the past couple of years), and anyway it would be
better for a Python programmer to maintain it.

The package description is:
 OCRmyPDF generates a searchable PDF/A file from a regular PDF
 containing only images, allowing it to be searched.
 .
 It uses the Tesseract OCR engine and so supports all the languages
 that Tesseract does.
 .
 Some other main features:
 .
   * Places OCR text accurately below the image to ease copy / paste
   * Keeps the exact resolution of the original embedded images
   * When possible, inserts OCR information as a lossless operation
 without rendering vector information
   * Keeps file size about the same
   * If requested deskews and/or cleans the image before performing OCR
   * Validates input and output files
   * Provides debug mode to enable easy verification of the OCR results
   * Processes pages in parallel when more than one CPU core is
 available
   * Battle-tested on thousands of PDFs, a test suite and continuous
 integration.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1017753: autopkgtest-virt-lxc regularly fails to start or return from reboot

[Simon McVittie]

On Sun, 21 Aug 2022 at 21:53:02 +0200, Paul Gevers wrote:
> I think I found part of the issue:
> 
> paul@mulciber ~ $ sudo lxc-start test && sudo lxc-attach test -- "runlevel"
> ; echo $? && sudo lxc-stop test
> unknown
> 1
> paul@mulciber ~ $ sudo lxc-start test && sudo lxc-attach test -- "if [ -d
> /run/systemd/system ]; then echo systemd ; exit 0 ; else echo unknown ; exit
> 0 ; fi" ; echo $? && sudo lxc-stop test
> lxc-attach: test: ../src/lxc/attach.c: lxc_attach_run_command: 1839 No such
> file or directory - Failed to exec "if [ -d /run/systemd/system ]; then echo
> systemd ; exit 0 ; else echo unknown ; exit 0 ; fi"
> 127

Does lxc-attach expect a single shell one-liner as argument (like su -c),
or an argv (like sudo)?

I would have expected that it wants an argv, in which case the first one
is searching PATH for /bin/runlevel or similar, which succeeds, but the
second is searching path for something like "/bin/if [ -d ..." which
doesn't exist (hence exit status 127).

If it wants argv as individual arguments, like I would have expected,
then the second command should be more like:

sudo lxc-start test && sudo lxc-attach test -- sh -ec "if [ -d ..."

which is how lib/VirtSubproc.py actually runs it.

If the root cause was me mixing up commands that want a shell one-liner
with commands that want argv, then I would have expected that virt-lxc
would *never* work in the current version, rather than only intermittently
working (but I'm fairly sure it passed its autopkgtest run in my
autopkgtest-virt-qemu, so it must work at least sometimes).

smcv

Bug#1017871: shiny-server: server-function don't run

[Sebastian Krüger]

Package: shiny-server
Version: 1.5.17.973-3+b1
Severity: important
X-Debbugs-Cc: sebastian.krue...@institut-ba.de

The server function does not seem to be started. There is no response to inputs
in the UI. However, there is also no reaction (in the LOG file) if the code in
the server function is completely nonsensical.


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

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

Versions of packages shiny-server depends on:
ii  handlebars [node-handlebars]  3:4.7.7+~4.1.0-1
ii  libc6 2.34-4
ii  libgcc-s1 12.1.0-8
ii  libnode10818.7.0+dfsg-1
ii  libstdc++612.1.0-8
ii  lsb-base  11.2
ii  mocha 10.0.0+ds1+~cs28.5.6-2
ii  node-bash 0.0.1-4
ii  node-client-sessions  0.8.0-3
ii  node-compression  1.7.4-3
ii  node-express  4.18.1+~4.17.13-1
ii  node-faye-websocket   0.11.4-1
ii  node-graceful-fs  4.2.10-1
ii  node-http-proxy   1.18.1-6
ii  node-ip-address   8.1.0-2
ii  node-log4js   6.6.1+~cs8.4.15-1
ii  node-moment   2.29.4+ds-1
ii  node-morgan   1.10.0-3
ii  node-nan  2.16.0-1
ii  node-optimist 0.6.1+~0.0.30-2
ii  node-pause0.1.0-4
ii  node-q1.5.1-4
ii  node-qs   6.11.0+ds+~6.9.7-1
ii  node-send 0.18.0+~cs1.19.1-3
ii  node-shiny-server-client  1.2.0+dfsg-1
ii  node-should   13.2.3~dfsg-5
ii  node-sinon14.0.0+ds+~cs71.22.25-1
ii  node-sockjs   0.3.24+~0.3.33-3
ii  node-sockjs-client1.6.0+dfsg1-2
ii  node-split1.0.1-1
ii  node-stable   0.1.8-3
ii  node-underscore   1.13.3~dfsg+~1.11.4-1
ii  nodejs18.7.0+dfsg-1
ii  npm   8.17.0~ds1-1
ii  pandoc2.17.1.1-1
ii  r-base4.2.1-2
ii  r-cran-shiny  1.7.2+dfsg-1

shiny-server recommends no packages.

shiny-server suggests no packages.

-- Configuration Files:
/etc/shiny-server/default.config changed [not included]

-- no debconf information

Bug#956012: Frightening!

[Steve McIntyre]

arthurweinber...@gmail.com wrote:
>
>Hi Mike,
>
>"Frightening" is my perspective on this.
>
>When an average user sees their chromium is suddenly "managed" by their
>organization and they know they are not part of any organization, then
>their first idea will be that they have been hacked. In my case I deleted
>my entire chromium profile before I realized that this was the root cause.
>
>I hope you quickly rollback this change to save others this pain and then
>figure out a better way to roll this forward.

Nod. Even as an experienced user and developer, I was very surprised
to see this message. I have quite a few account identities set up in
my Chromium (e.g. for Google services), but I would never expect any
of them to be described as managing it.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews

Bug#1010626: Bug#1012289: RFH: lintian -- Debian package checker

[Axel Beckert]

Hi Bastien,

Bastien Roucariès wrote:
> could you please check why autotest fail

Done now:

Lintian's autopkgtest fails on Salsa for a week now because dpatch has
been removed from unstable a week ago: https://bugs.debian.org/1010626
(Cc'ed)

It seems as if package removals do not take into account autopkgtest
dependencies yet. :-/

dpatch seems to be mentioned in 269 files of the test suite. I assume
that at least all dpatch related tags can be removed now as there's no
point in arguing about dpatch being used (or even used wrongly) if any
package using it will FTBFS anyway.

Thanks for notifying me of that issue!

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


signature.asc
Description: PGP signature

Bug#1017866: gtk4: FTBFS on non-linux

[Simon McVittie]

On Sun, 21 Aug 2022 at 16:21:39 -0400, Jeremy Bicha wrote:
> Simon, I was intending to upload gtk4 to Unstable now unless you want
> me to wait.

Yes, what I really meant by "soon" was "when Jeremy gets there". It would
be good if you could include Samuel's changes in this (already pushed),
but I don't think there's any other reason to delay this upload, as long
as we're expecting GTK 4.8 soon (which we are).

smcv

Bug#981577: fontconfig should prefer DejaVu over Bitstream Vera

[Dmitry Semyonov]

affects 981577 + fbreader
thanks

Another manifestation of the issue: broken rendering of cyrillic
symbols by the FBReader e-book reader.

Note that the ttf-bitstream-vera package description points users of
non-latin fonts into the right direction:
"Non-latin scripts are not supported (use ttf-dejavu instead)."
but does not stress it enough that the "instead" word should be
treated literally. (Not to mention that the referenced package name
should be changed to "fonts-dejavu" nowadays.)

P.S.
  I tried patching the /etc/fonts/conf.d/60-latin.conf locally as was
suggested in a similar bug discussion
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961389#15) but it
didn't work for the cyrillic issue by some reason. So, I ended up
removing the ttf-bitstream-vera package from my system, (luckily, I
had no other packages depending on it).

P.P.S.
  I think, something like the following could be used for quick test
of the preferred Bitstream Vera font on your system:

fc-match --sort ":family=Bitstream Vera Serif" |head

-- 
...Bye..Dmitrii.

Bug#1012196: buglist

[Bastian Germann]

Control: tags -1 moreinfo

Your d/watch file does not work. You want to scan GitHub releases and not tags 
and fix the version regex.
Also, your orig tarball does not fit the released tar.gz because it has 
differences in pt.po.
Please test the download via uscan --download-current-version.

Bug#1017870: gnome-shell-extension-gsconnect: Not compatible with gnome-shell 43

[Jeremy Bicha]

Source: gnome-shell-extension-gsconnect
Version: 50-3
Severity: serious
Tags: upstream
Forwarded: 
https://github.com/GSConnect/gnome-shell-extension-gsconnect/issues/1428

gnome-shell-extension-gsconnect isn't compatible with gnome-shell 43,
currently available in Debian Experimental.

Thank you,
Jeremy Bicha

Bug#1017866: gtk4: FTBFS on non-linux

[Jeremy Bicha]

On Sun, Aug 21, 2022 at 3:51 PM Simon McVittie  wrote:
> Thanks, applied in git (only for experimental for now, but the version
> in experimental will need to go to unstable soon anyway).
>
> For the documentation, I wonder whether it might be better to pass
> -Nlibgtk-4-doc to debhelper on non-Linux, so that the Arch: all
> documentation package is complete (includes the gdk-wayland documentation)
> on all the architectures where it's built, but is skipped entirely on
> non-Linux (d/rules will automatically disable the documentation if it isn't
> going to be packaged). That would avoid needing dh-exec.

Simon, I was intending to upload gtk4 to Unstable now unless you want
me to wait.

Thank you,
Jeremy Bicha

Bug#1017817: emacs: new release seems to have funny ideas about byte-compiling process

[Thorsten Bonow]

(Also a bit surprised this hasn't already been reported, and thus
afraid it's some quirk of my installation, but if not it's *got* to
be biting some other folks as least as badly.)


Hi,

this has happened to me, too.  OOM killer didn't prevent the system 
from becoming totally unresponsive.  (I was afk for a few hours.)


This appeared to have happened during compilation of the following 
packages:


cdargs
emms
elpa-bind-chord
ecb

De-installing these packages made the emacs package installation 
possible on my system.


Afterwards I was able to install the packages mentioned above one 
after the other, only the ecb package still leads to the "thundering 
compilation herd"...


GNU Emacs 28 spits out a lot of warnings once in a while but runs 
smoothly otherwise.  (I haven't updated to 1:28.1+1-2 yet.)  Thanks 
for the good work!


Toto

Bug#1017348: autopkgtest regression on ppc64el

[Alexis Bienvenüe]

Hi.

Thanks for the report.

This autopkgtest fail comes from a call to cv::boundingRect that works
differently between OpenCV versions 4.6.0+dfsg-4+b1 from testing and
4.6.0+dfsg-6+b1 from unstable, on a ppc64el virtual machine.

Running the sample code below, which computes a bounding rectangle for
three points, the output with OpenCV 4.6.0+dfsg-4+b1 is
  x: 3+4   y: 98+13
(which is what I was waiting for), and with OpenCV 4.6.0+dfsg-6+b1 is
  x: 3+4   y: 0+1
(I think the values for y are not correct here).
However, the output seems correct with both versions of OpenCV on
amd64.

As far as I understand this issue, I would say that the problem comes
from OpenCV and not auto-multiple-choice.

Regards,
Alexis Bienvenüe.

--
// gcc -o bounding bounding.cc -O2 -lstdc++ -lm -I/usr/include/opencv4
-lopencv_imgproc

#include 
#include 
#include "opencv2/core/core.hpp"
#include "opencv2/imgproc/imgproc.hpp"

int main(int argc, char** argv)
{

  std::vector pts;

  pts.push_back(cv::Point(3,100));
  pts.push_back(cv::Point(5,98));
  pts.push_back(cv::Point(6,110));

  cv::Rect rect = cv::boundingRect(pts);

  std::cout << "x: " << rect.x << "+" << rect.width
<< "   y: " << rect.y << "+" << rect.height
<< "\n";

}

Bug#1017779: emacs-common dies in postinst with "corrupted double-linked list"

[Kurt Meyer]

I've upgraded emacs-common on both of my computers without issue, so the issue 
that the OP is experiencing may be unique to the emacs-lucid package, which I 
do not have installed on either of my computers.

Bug#1017798: emacs-common can't be installed

[Kurt Meyer]

I've upgraded emacs-common on both of my computers without issue, so the issue 
that the OP is experiencing may be unique to the elpa-htmlize package, which I 
do not have installed on either of my computers.

Bug#998705: Many 502 errors, when using apt-cacher-ng for Debian installation

[Diane Trout]

On Wed, 16 Feb 2022 09:28:13 -0300 Eriberto Mota 
wrote:
> Hi guys,
> 
> I am running Debian Stable (Bullseye) in my desktop and in my local
server.
> 
> Yesterday I made a backport version of the apt-cacher-ng for me and I
put it
> in the server. The problem seems is solved.
> 
> Regards,
> 
> Eriberto
> 
> 


Just wanted to add in. I was experiencing the 502 errors, I installed
the version apt-cacher-ng 3.7.4-1~bpo11+1 from backports and the 502
errors went away.

Diane

Bug#1017753: autopkgtest-virt-lxc regularly fails to start or return from reboot

[Paul Gevers]

Hi,

I think I found part of the issue:

paul@mulciber ~ $ sudo lxc-start test && sudo lxc-attach test -- 
"runlevel" ; echo $? && sudo lxc-stop test

unknown
1
paul@mulciber ~ $ sudo lxc-start test && sudo lxc-attach test -- "if [ 
-d /run/systemd/system ]; then echo systemd ; exit 0 ; else echo unknown 
; exit 0 ; fi" ; echo $? && sudo lxc-stop test
lxc-attach: test: ../src/lxc/attach.c: lxc_attach_run_command: 1839 No 
such file or directory - Failed to exec "if [ -d /run/systemd/system ]; 
then echo systemd ; exit 0 ; else echo unknown ; exit 0 ; fi"

127
paul@mulciber ~ $

It seems the first command in the new flow is not suitable to run while 
the container is still starting up.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1017866: gtk4: FTBFS on non-linux

[Simon McVittie]

On Sun, 21 Aug 2022 at 21:02:01 +0200, Samuel Thibault wrote:
> gtk4 currently FTBFS on non-linux ports because it lists
> wayland-specific symbols and tries to install the wayland-specific
> documentation. The attach patch is fixing it:
> 
>   * debian/libgtk-4-1.symbols.in: Update symbols list for non-linux.
>   * debian/control, debian/control.in, debian/libgtk-4-doc.install: Build-dep
> on dh-exec and set +x on debian/libgtk-4-doc.install to easily avoid
> trying to install wayland documentation on non-linux.

Thanks, applied in git (only for experimental for now, but the version
in experimental will need to go to unstable soon anyway).

For the documentation, I wonder whether it might be better to pass
-Nlibgtk-4-doc to debhelper on non-Linux, so that the Arch: all
documentation package is complete (includes the gdk-wayland documentation)
on all the architectures where it's built, but is skipped entirely on
non-Linux (d/rules will automatically disable the documentation if it isn't
going to be packaged). That would avoid needing dh-exec.

smcv

Bug#1015272: liburing autopkgtest started to hang containers in Debian and Ubuntu since ~2022-07-11

[Bastian Blank]

Control: tags -1 moreinfo
Control: severity -1 normal

On Sun, Aug 21, 2022 at 07:42:10PM +0200, Guillem Jover wrote:
> It seems like there was a regression with the latest stable update
> that affects the autopkgtest for liburing. Reassigning.

Please provide enough information to make isolating the problem
possible.

https://ci.debian.net/packages/libu/liburing/ is completely silent as
there are not results for any of the failed runs.

Bastian

-- 
There is an order of things in this universe.
-- Apollo, "Who Mourns for Adonais?" stardate 3468.1

Bug#941480: Please package the new version of mediathekview

[Markus Koschany]

Let's use this bug report for updating mediathekview instead of 
https://bugs.debian.org/1011165

Quote from the other bug report:

I have pushed a new branch which includes version 13.9.1.

https://salsa.debian.org/debian/mediathekview/-/tree/experimental

As you can see I have started from scratch because this is basically a new
package now. In order to complete this upgrade we need at least 

an upgrade of okhttp to version 4.x

https://tracker.debian.org/pkg/libokhttp-java

an upgrade of okio to 3.x

https://tracker.debian.org/pkg/okio

tilesfx

a new package eu.hansolo tilesfx

https://github.com/HanSolo/tilesfx

a new package glazedlists

https://github.com/glazedlists/glazedlists

We could omit flatlaf because that seems to be only relevant for Windows


Those are the major issues we have to fix in order to package a new upstream
release of mediathekview. And we also need to fix kotlin in unstable. If
someone wants to help, that's our todo list.


I will package tilesfx and glazedlists but I suspect the major problem will be
kotlin. If we can't package a version that supports Java 17 then it makes no
sense to upgrade mediathekview too.




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

Bug#1017867: libapache2-mod-auth-gssapi: Undefined behaviour when compiled with OpenSSL 3 library

[Stefan Fleischmann]

Package: libapache2-mod-auth-gssapi
Version: 1.6.3-1+b1
Severity: important
Tags: patch

Dear Maintainer,

the package produces undefined behavior when compiled with OpenSSL 3
(instead of OpenSSL 1.1). The bug has been noticed and fixed upstream,
see: https://github.com/gssapi/mod_auth_gssapi/pull/256

I'm not qualified to say if this results in a security vulnerability,
but the results I see look suspicious imho.

I noticed this when testing installation of the latest FreeIPA release
on Ubuntu 22.04 and Debian. After successful installation I could not
log in to the web UI. The Apache error log showed lines like these:

 [client X.X.X.X:39170] KRB5CCNAME file (/run/ipa/ccaches/myuser@EXA) lookup 
failed!, referer: https://ldap-jammy.biophysics.kth.se/ipa/ui/
 [client X.X.X.X:39170] KRB5CCNAME file (/run/ipa/ccaches/myuser@EXA) lookup 
failed!, referer: https://ldap-jammy.biophysics.kth.se/ipa/ui/
 [client X.X.X.X:39170] KRB5CCNAME file (/run/ipa/ccaches/myuser@EXA:12:29:50 
+000) lookup failed!, referer: https://ldap-jammy.biophysics.kth.se/ipa/ui/
 [client X.X.X.X:39170] KRB5CCNAME file (/run/ipa/ccaches/myuser@EXA) lookup 
failed!, referer: https://ldap-jammy.biophysics.kth.se/ipa/ui/

Note the mangled KRB5CCNAME file name that contains parts of seemingly
random other strings. I've also seen for example:

 /run/ipa/ccaches/myuser@EXA\x95\xaa\xa6\t\x80 D\n\xef\xe2\xde\xf6\xa2\xce
 /run/ipa/ccaches/myuser@EXAMozilla/5.0 (X
 /run/ipa/ccaches/myuser@EXAa/session/logi

Valid filenames look like this:
 /run/ipa/ccaches/myu...@example.org-tBzEry
 /run/ipa/ccaches/myu...@example.org-3wYfMK

I've confirmed that the merge request mentioned above (#256) fixes the
problem at least to the point where the logs look okay and I can log in
to the web UI.

Best regards,
Stefan

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

Kernel: Linux 5.4.0-100-generic (SMP w/20 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libapache2-mod-auth-gssapi depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.54-2
ii  libc6   2.34-3
ii  libgssapi-krb5-21.20-1
ii  libssl3 3.0.5-2

libapache2-mod-auth-gssapi recommends no packages.

libapache2-mod-auth-gssapi suggests no packages.

-- no debconf information

Bug#1017853: emacs-nox: byte compiling debian-startup.el fails if emacs-el is not installed

[David Bremner]

David Bremner  writes:

> Package: emacs-nox
> Version: 1:28.1+1-2
> Severity: serious
> Justification: does not install
> X-Debbugs-Cc: debian-emac...@lists.debian.org

Here is the output of strace in case it is useful. It uncompresses to
16M, just FYI.



strace.log.xz
Description: application/xz

Bug#1017866: gtk4: FTBFS on non-linux

[Samuel Thibault]

Source: gtk4
Version: 4.6.6+ds-3
Severity: important
Tags: patch

Hello,

gtk4 currently FTBFS on non-linux ports because it lists
wayland-specific symbols and tries to install the wayland-specific
documentation. The attach patch is fixing it:

  * debian/libgtk-4-1.symbols.in: Update symbols list for non-linux.
  * debian/control, debian/control.in, debian/libgtk-4-doc.install: Build-dep
on dh-exec and set +x on debian/libgtk-4-doc.install to easily avoid
trying to install wayland documentation on non-linux.

Note that chmod +x debian/libgtk-4-doc.install needs to be done after
applying the patch.

Samuel

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

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

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
--- debian/control.in.original  2022-08-21 18:11:12.0 +
+++ debian/control.in   2022-08-21 18:17:19.0 +
@@ -7,6 +7,7 @@
at-spi2-core ,
dbus ,
debhelper-compat (= 13),
+   dh-exec,
docbook-xml,
docbook-xsl,
dpkg-dev (>= 1.17.14),
--- debian/control.original 2022-08-21 15:38:41.0 +
+++ debian/control  2022-08-21 18:17:19.0 +
@@ -7,6 +7,7 @@
at-spi2-core ,
dbus ,
debhelper-compat (= 13),
+   dh-exec,
docbook-xml,
docbook-xsl,
dpkg-dev (>= 1.17.14),
--- debian/libgtk-4-1.symbols.in.original   2022-08-21 13:47:20.0 
+
+++ debian/libgtk-4-1.symbols.in2022-08-21 13:47:47.0 +
@@ -537,8 +537,8 @@
  (arch=linux-any)gdk_wayland_device_get_wl_keyboard@Base 4.0.0
  (arch=linux-any)gdk_wayland_device_get_wl_pointer@Base 4.0.0
  (arch=linux-any)gdk_wayland_device_get_wl_seat@Base 4.0.0
- gdk_wayland_device_get_xkb_keymap@Base 4.3.1
- gdk_wayland_display_get_egl_display@Base 4.3.1
+ (arch=linux-any)gdk_wayland_device_get_xkb_keymap@Base 4.3.1
+ (arch=linux-any)gdk_wayland_display_get_egl_display@Base 4.3.1
  (arch=linux-any)gdk_wayland_display_get_startup_notification_id@Base 4.0.0
  (arch=linux-any)gdk_wayland_display_get_type@Base 4.0.0
  (arch=linux-any)gdk_wayland_display_get_wl_compositor@Base 4.0.0
@@ -550,7 +550,7 @@
  (arch=linux-any)gdk_wayland_monitor_get_type@Base 4.0.0
  (arch=linux-any)gdk_wayland_monitor_get_wl_output@Base 4.0.0
  (arch=linux-any)gdk_wayland_popup_get_type@Base 4.0.0
- gdk_wayland_seat_get_type@Base 4.0.0
+ (arch=linux-any)gdk_wayland_seat_get_type@Base 4.0.0
  (arch=linux-any)gdk_wayland_seat_get_wl_seat@Base 4.0.0
  (arch=linux-any)gdk_wayland_surface_get_type@Base 4.0.0
  (arch=linux-any)gdk_wayland_surface_get_wl_surface@Base 4.0.0
--- debian/libgtk-4-doc.install.original2022-08-21 15:38:51.0 
+
+++ debian/libgtk-4-doc.install 2022-08-21 15:39:01.0 +
@@ -1,5 +1,6 @@
+#! /usr/bin/dh-exec
 usr/share/doc/gdk4 usr/share/doc/${env:DOC_PKG}
-usr/share/doc/gdk4-wayland usr/share/doc/${env:DOC_PKG}
+[linux-any] usr/share/doc/gdk4-wayland usr/share/doc/${env:DOC_PKG}
 usr/share/doc/gdk4-x11 usr/share/doc/${env:DOC_PKG}
 usr/share/doc/gsk4 usr/share/doc/${env:DOC_PKG}
 usr/share/doc/gtk4 usr/share/doc/${env:DOC_PKG}

Bug#1017865: faketime: FTBFS on hurd-i386 with glibc 2.34

[Samuel Thibault]

Package: faketime
Version: 0.9.10-2.1
Severity: important
Tags: patch upstream

Hello,

With glibc 2.34, faketime now fails to build from source, because it
fails passing -lpthread to the linker:

cc -o libfaketime.so.1 -Wl,-soname,libfaketime.so.1 -Wl,-z,relro -Wl,-z,now  
-lpthread -Wl,--version-script=libfaketime.map -shared libfaketime.o -ldl -lm 
-lrt

since -lpthread is passed before libfaketime.o, libpthread is not
actually getting pulled in. It happens that things used to be working
before glibc 2.34 because librt.so depends on libpthread, and thus -lrt
would pull libpthread. But in version 2.34, librt.so doesn't do so any
more, so the lucky-pull is no more.

The attached patch fixes this by passing -lpthread along the other -l,
as it should anyway.

Samuel

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

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

Versions of packages faketime depends on:
ii  libc62.34-3
ii  libfaketime  0.9.10-2.1

faketime recommends no packages.

faketime suggests no packages.

-- no debconf information

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
Index: faketime-0.9.10/src/Makefile
===
--- faketime-0.9.10.orig/src/Makefile
+++ faketime-0.9.10/src/Makefile
@@ -117,13 +117,13 @@ endif
 
 LIB_LDFLAGS += -shared
 
-LDFLAGS += $(FAKETIME_LINK_FLAGS) -lpthread
+LDFLAGS += $(FAKETIME_LINK_FLAGS)
 ifneq ($(PLATFORM),SunOS)
 LDFLAGS += -Wl,--version-script=libfaketime.map
 endif
 
-LDADD += -ldl -lm -lrt
-BIN_LDFLAGS += -lrt
+LDADD += -ldl -lm -lrt -lpthread
+BIN_LDFLAGS += -lrt -lpthread
 
 SRC = libfaketime.c
 LIBS_OBJ = libfaketime.o libfaketimeMT.o

Bug#1017864: scipy: segfault on i386 in special test_kolmogorov.py TestSmirnovp

[Drew Parsons]

Source: scipy
Version: 1.8.1-8
Severity: important
Control: forwarded -1 https://github.com/scipy/scipy/issues/16700

scipy 1.8.1 fails debci tests on i386 with a segfault in test_kolmogorov.py

It can be located specifically in
special/tests/test_kolmogorov.py::TestSmirnovp::test_oneminusoneovern
and reproduced directly with 
  python3 ./runtests.py -v -n -s special -- -k "TestSmirnovp"
  
I'm marking with severity Important rather than Serious since we're free to
simply skip this one test.  The Serious bug preventing migration to testing
is Bug#1017862

Bug#1017863: numactl: FTBFS on riscv64

[Eric Long]

Source: numactl
Version: 2.0.14-3
Severity: important
Tags: ftbfs patch upstream
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: i...@hack3r.moe

Dear maintainer,

numactl currently failed to build on riscv64 from source:

...
/usr/bin/ld: ./.libs/libnuma.so: undefined reference to `__atomic_fetch_and_1'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:899: migratepages] Error 1
make[2]: *** Waiting for unfinished jobs
/usr/bin/ld: ./.libs/libnuma.so: undefined reference to `__atomic_fetch_and_1'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:903: migspeed] Error 1
/usr/bin/ld: ./.libs/libnuma.so: undefined reference to `__atomic_fetch_and_1'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:907: numactl] Error 1
/usr/bin/ld: ./.libs/libnuma.so: undefined reference to `__atomic_fetch_and_1'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:911: numademo] Error 1
...

Full buildd log: 
https://buildd.debian.org/status/fetch.php?pkg=numactl&arch=riscv64&ver=2.0.14-3&stamp=1632275973&raw=0

This can be fixed by linking to libatomic on riscv64, which I've written a
patch solving the problem. I will submit it to the upstream repo soon.

Please let me know if I miss something.

Cheers,
Eric

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

Kernel: Linux 5.10.0-17-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
--- a/Makefile.am
+++ b/Makefile.am
@@ -41,6 +41,9 @@
 
 libnuma_la_SOURCES = libnuma.c syscall.c distance.c affinity.c affinity.h 
sysfs.c sysfs.h rtnetlink.c rtnetlink.h versions.ldscript
 libnuma_la_LDFLAGS = -version-info 1:0:0 
-Wl,--version-script,$(srcdir)/versions.ldscript -Wl,-init,numa_init 
-Wl,-fini,numa_fini
+if RISCV64
+libnuma_la_LDFLAGS += -latomic
+endif
 
 check_PROGRAMS = \
test/distance \
--- a/configure.ac
+++ b/configure.ac
@@ -22,6 +22,9 @@
 AX_CHECK_COMPILE_FLAG([-ftree-vectorize], [tree_vectorize="true"])
 AM_CONDITIONAL([HAVE_TREE_VECTORIZE], [test x"${tree_vectorize}" = x"true"])
 
+AC_CANONICAL_TARGET
+AM_CONDITIONAL([RISCV64], [test x"${target_cpu}" = x"riscv64"])
+
 AC_CONFIG_FILES([Makefile])
 
 # GCC tries to be "helpful" and only issue a warning for unrecognized

Bug#1017808: ITP: zfp -- Fixed-Rate Compressed Floating-Point Arrays

[Gürkan Myczko]

Hi Antonio,

> On 21 Aug 2022, at 20:34, Antonio Valentino  
> wrote:
> 
> Dear Gürkan,
> 
> Il 21/08/22 11:45, Gürkan Myczko ha scritto:
>> Dear Antono,
>> Are you ever on irc? If so communication could be optimized (speedwise)
>> when you join #debian-science...
> 
> no sorry, I do not use irc

no problem,
> 
>>> On Sat, 20 Aug 2022 23:05:34 +0200 =?UTF-8?Q?G=C3=BCrkan_Myczko?=
>>>  wrote:
 Package: wnpp
 Severity: wishlist
 Owner: Gürkan Myczko 
 X-Debbugs-Cc: debian-de...@lists.debian.org
 
 * Package name: zfp
Version : 1.0.0
Upstream Authors: Peter Lindstrom
URL : https://github.com/LLNL/zfp
 * License : BSD-3-clause
Description : Fixed-Rate Compressed Floating-Point Arrays
   This is a compressed format for representing multidimensional 
 floating-point
   and integer arrays.  zfp provides compressed-array classes that support 
 high
   throughput read and write random access to individual array elements. zfp
   also supports serial and parallel (OpenMP and CUDA) compression of whole
   arrays, e.g., for applications that read and write large data sets to and
   from disk.
 
 It has bindings for C, C++, Fortran, and Python, as well as a cli tool
>>> 
>>> I'm very interested in having this library in Debian.
>>> If you need any help form me please let me know an I will be happy to
>>> support the packaging and maintenance of this library.
>> Sounds good, I wouldn't mind helping hands, am busy myself very much,
>> here's my work so far: http://sid.ethz.ch/debian/zfp/
> 
> I have create a "working" git repo on my area in salsa.
> 
> https://salsa.debian.org/antonio.valentino/zfp
> 
> I hope you don't mind.

that’s perfect, i wanted to suggest that, as well as adding yourself and/or 
team science
to d/control (Maintainers/Uploaders)
> 
> Once the package is ready we can create the proper "official" repository in 
> the proper location, import the package and drop the working one.
> 
> 
>> The package needs to rename zfp to libzfpN and add python(3?)-zfp
>> And maybe a better d/copyright, other than that it doesn't look too bad.
> 
> I have renamed/split the old zfp package into libzfp1 and python3-zfpy.
> I have also added a new package zfp for the command line utilities.
> 
> There is still some problem with the libzfp1-dbgsym package, I need to 
> investigate.
> Finally, I also plan to try to include symbol files.
> 
> Please let me know if you have any comments.

that also is perfect, tell me once you’re ready, i’ll be glad for final review, 
preferably
from mentors.debian.net  for sponsoring. depending 
on the team science or not,
it’d go to debian/ salsa or the team repo on salsa, i can create the repo there 
as well,
once it’s final.

kind regards, thank you so much for stepping in!
> 
> kind regards
> -- 
> Antonio Valentino

Bug#952159: rust-nodrop-union: FTBFS: dh_auto_test: error: /usr/share/cargo/bin/cargo build returned exit code 101

[Peter Michael Green]

I have written a merge request [1] to fix FTBFS on all platforms. Tested on my
dev machine on amd64 and riscv64. If more helps are needed, please let me know.

Thanks for the patch,

Was this patch just a result of general QA activity or is there some 
program you are trying to package?


We can fix this up if there is a good reason, but i'm more inclined to 
say a crate that is abandoned upstream, fails to build with current 
rustc and has been superseeded by funcationality in the standard library 
probablly doesn't belong in Debian.

Bug#1017746: assimp: CMake variable DRACO_LIBRARIES is deprecated

[Timo Röhling]

* IOhannes m zmölnig  [2022-08-21 11:01]:

I'm not an expert when it comes to Cmake (being an autotools guy), so patches 
welcome 😉

Sure, happy to help!
You could just replace "${DRACO_LIBRARIES}" with the literal
"draco::draco" target name, but in the attached patch, I added a check
to set the DRACO_LIBRARIES to draco::draco instead. This way, assimp
will build with both the bookworm and the bullseye version of draco.


Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯
diff --git a/debian/patches/use-system-libdraco.patch b/debian/patches/use-system-libdraco.patch
index 76c1bcb..0946461 100644
--- a/debian/patches/use-system-libdraco.patch
+++ b/debian/patches/use-system-libdraco.patch
@@ -12,6 +12,9 @@ This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
  ENDIF()
  
 +find_package(draco CONFIG REQUIRED)
++if(NOT DRACO_LIBRARIES)
++set(DRACO_LIBRARIES "draco::draco")
++endif()
 +target_link_libraries(assimp ${DRACO_LIBRARIES})
 +
  if(ASSIMP_ANDROID_JNIIOSYSTEM)


signature.asc
Description: PGP signature

Bug#956012: Frightening!

[Arthur Weinberger]

Hi Mike,

"Frightening" is my perspective on this.

When an average user sees their chromium is suddenly "managed" by their
organization and they know they are not part of any organization, then
their first idea will be that they have been hacked. In my case I deleted
my entire chromium profile before I realized that this was the root cause.

I hope you quickly rollback this change to save others this pain and then
figure out a better way to roll this forward.

Thanks
Arthur Weinberger
arthurweinber...@gmail.com


On Sun, Aug 21, 2022 at 9:13 AM Mike Gabriel <
mike.gabr...@das-netzwerkteam.de> wrote:

> Hi Andres,
>
> On  So 21 Aug 2022 09:47:51 CEST, Andres Salomon wrote:
>
> > It looks like the other way to do this is through
> > /etc/chromium/master_preferences, which will only take effect when
> > people first install and run chromium.
> >
> >  "search_provider_overrides": [{
> >"enabled": true,
> >"encoding": "UTF-8",
> >"favicon_url": "https://duckduckgo.com/favicon.ico";,
> >"new_tab_url": "https://duckduckgo.com/chrome_newtab";,
> >"id": 2,
> >"keyword": "duckduckgo.com",
> >"name": "DuckDuckGo",
> >"search_url": "https://duckduckgo.com/?q={searchTerms}";,
> >"suggest_url": "https://duckduckgo.com/ac/?q={searchTerms}&type=list";
> >  }],
> >  "search_provider_overrides_version": 1,
> >
> >
> > It's not clear if that's the route we should go, but it does get rid
> > of the notices about the browser being managed by an organization. 🤔
>
> why is this frightening? (your mail subject). Many distributors tinker
> with that master_preferences file for their likings.
>
> And policies/managed is definitely the wrong place for configuring the
> search provider, as that means that users can't change it.
>
> Another option is putting the default search provider in
> policies/recommended. Haven't tested it, but it should work, as well.
>
> See https://sunweavers.net/blog/node/135 for details / overview of
> tweaking features.
>
> Mike
>
>
> --
>
> DAS-NETZWERKTEAM
> c\o Technik- und Ökologiezentrum Eckernförde
> Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
> mobile: +49 (1520) 1976 148
> landline: +49 (4351) 850 8940
>
> GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
> mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de
>
>

Bug#1017808: ITP: zfp -- Fixed-Rate Compressed Floating-Point Arrays

[Antonio Valentino]

Dear Gürkan,

Il 21/08/22 11:45, Gürkan Myczko ha scritto:

Dear Antono,

Are you ever on irc? If so communication could be optimized (speedwise)
when you join #debian-science...


no sorry, I do not use irc


On Sat, 20 Aug 2022 23:05:34 +0200 =?UTF-8?Q?G=C3=BCrkan_Myczko?=
 wrote:

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name    : zfp
   Version : 1.0.0
   Upstream Authors: Peter Lindstrom
   URL : https://github.com/LLNL/zfp
* License : BSD-3-clause
   Description : Fixed-Rate Compressed Floating-Point Arrays
  This is a compressed format for representing multidimensional 
floating-point
  and integer arrays.  zfp provides compressed-array classes that 
support high
  throughput read and write random access to individual array 
elements. zfp
  also supports serial and parallel (OpenMP and CUDA) compression of 
whole
  arrays, e.g., for applications that read and write large data sets 
to and

  from disk.

It has bindings for C, C++, Fortran, and Python, as well as a cli tool


I'm very interested in having this library in Debian.
If you need any help form me please let me know an I will be happy to
support the packaging and maintenance of this library.


Sounds good, I wouldn't mind helping hands, am busy myself very much,
here's my work so far: http://sid.ethz.ch/debian/zfp/


I have create a "working" git repo on my area in salsa.

https://salsa.debian.org/antonio.valentino/zfp

I hope you don't mind.

Once the package is ready we can create the proper "official" repository 
in the proper location, import the package and drop the working one.




The package needs to rename zfp to libzfpN and add python(3?)-zfp
And maybe a better d/copyright, other than that it doesn't look too bad.


I have renamed/split the old zfp package into libzfp1 and python3-zfpy.
I have also added a new package zfp for the command line utilities.

There is still some problem with the libzfp1-dbgsym package, I need to 
investigate.

Finally, I also plan to try to include symbol files.

Please let me know if you have any comments.

kind regards
--
Antonio Valentino

Bug#1010731: bad bug title

[Thorsten Alteholz]

Control: tags -1 + moreinfo

Hi Peter,

unfortunately the bug title of this bug does not make sense.
Please change it accordingly, so that the resulting dak command visible on
[1] afterwards, really does what you intend.

Please remove the moreinfo tag once that is done.

Thanks!
  Thorsten

[1] https://ftp-master.debian.org/removals.html

Bug#1010709: bad bug title

[Thorsten Alteholz]

Control: tags -1 + moreinfo

Hi Peter,

unfortunately the bug title of this bug does not make sense.
Please change it accordingly, so that the resulting dak command visible on
[1] afterwards, really does what you intend.

Please remove the moreinfo tag once that is done.

Thanks!
  Thorsten

[1] https://ftp-master.debian.org/removals.html

Bug#1010322: bad bug title

[Thorsten Alteholz]

Control: tags -1 + moreinfo

Hi Peter,

unfortunately the bug title of this bug does not make sense.
Please change it accordingly, so that the resulting dak command visible on 
[1] afterwards, really does what you intend.


Please remove the moreinfo tag once that is done.

Thanks!
  Thorsten

[1] https://ftp-master.debian.org/removals.html

Bug#1011165: mediathekview: update of dependent libjiconfont-font-awesome-java package leads to hang during startup

[mtths]

Package: mediathekview
Version: 13.2.1-4
Followup-For: Bug #1011165

After updating libjiconfont-font-awesome-java from version 4.7.0.0-2 to 
4.7.0.1-1
during startup the following error messages occurs and mediathekview hangs:
Exception in thread "main" java.lang.NoClassDefFoundError: 
jiconfont/icons/FontAwesome
at mediathek.Main.main(Main.java:161)
Caused by: java.lang.ClassNotFoundException: jiconfont.icons.FontAwesome
at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)

In libjiconfont-font-awesome-java 4.7.0.1-1 there is a new subdirectory:
jiconfont/icons/font_awesome/FontAwesome

Bug#1017862: scipy: FTBFS on 32 bit arches: TestMLS: Invalid call to pythranized function

[Drew Parsons]

Source: scipy
Version: 1.8.1-8
Severity: serious
Justification: FTBFS
Control: forwarded -1 https://github.com/scipy/scipy/pull/16646

scipy FTBFS on 32 bits arches after pythran support was recently
activated. The error looks like:

___ TestMLS.test_mls_inputs 
/<>/.pybuild/cpython3_3.10_scipy/build/scipy/signal/tests/test_max_len_seq.py:21:
 in test_mls_inputs
assert_array_equal(max_len_seq(10, length=0)[0], [])
self   = 
/<>/.pybuild/cpython3_3.10_scipy/build/scipy/signal/_max_len_seq.py:136:
 in max_len_seq
state = _max_len_seq_inner(taps, state, nbits, length, seq)
E   TypeError: Invalid call to pythranized function 
`_max_len_seq_inner(intc[:], int8[:], int, int, int8[:])'
E   Candidates are:
E   
E   - _max_len_seq_inner(int[:], int8[:], int, int, int8[:])
E   - _max_len_seq_inner(int64[:], int8[:], int, int, int8[:])
length = 0
n_max  = 1023
nbits  = 10
seq= array([], dtype=int8)
state  = array([1, 1, 1, 1, 1, 1, 1, 1, 1, 1], dtype=int8)
taps   = array([7], dtype=int32)


Likewise with TestMLS.test_mls_output.

1.8.1-8 introduced debian patch pythran_type_PR16646.patch which
applied scipy upstream PR16646 to fix such pythran issues. The patch
fixed the problems reported at
https://github.com/serge-sans-paille/pythran/issues/2002
but two tests in TestMLS remain to be fixed.

This is the main problem keeping scipy 1.8 from migrating to testing,
hence marking bug severity Serioes.

Bug#1017815: RFS: rumur/2022.08.20-1 [RC] -- model checker for the Murphi language

[Matthew Fernandez]

On 8/21/22 00:32, Tobias Frost wrote:

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

Hi Matthew,

thanks for the updated package fixing an RC bug!

Thanks for sponsoring!

I have is some feedback regarding it:
- The format of d/changelog is a bit unusual, usually there are no
   blank lines between entries.
Ah I did not realise this was non-standard. Should I adjust the entire 
d/changelog in the next release? Or should I just omit blank lines from 
now on?

- d/changelog should document every change to the Debian packaging,
   there are many changes that are not documented:
   - update watch file
   - update Standard-Version
   - updates to d/control, versions of depdendencies.
I did not realise details of the packaging itself was relevant to the 
changelog. Though apparently past me did, as I see entries in previous 
releases about Standards-Version. In the next release, I'll try to be 
more comprehensive.

- d/copyright needs updating, at least some years.
   A remark on the copyright for debien/*: You've choosen
   a different license here than the upstream license. This
   is of course your choice, but if the license differ this could
   make it difficult to include stuff (like patches) to upstream,
   as GPL-3 and unlicense are not compatible in the GPL…
   As you are the only person working on the package and upstream,
   that be easily fixed by relicensing the debian directory to
   unlicense as well…
I did not realise is was permissible to license debian/* anything other 
than a GPL license. Will fix in the next release.

- There are a lots of tests skipped due to missing xmllint…
   Is there a missing B-D on libxml2-utils?
The test suite for this package is pretty long running, even without the 
XML tests, and I didn't think they were critical (it's pretty hard to 
break this functionality without the problem being obvious upstream 
first). I can certainly add libxml2-utils to enable them though if you 
think it's advisable. Another optional thing is the presence of an SMT 
solver like Z3 which would enable some other optional tests.

Those are not critcial issues, but please consider them for later
revisions of your package. So I'm going to upload your package soon.

Thanks for your contribution to Debian!

Bug#1015272: liburing autopkgtest started to hang containers in Debian and Ubuntu since ~2022-07-11

[Guillem Jover]

Control: reassign -1 linux
Control: affects -1 liburing debci

Hi!

It seems like there was a regression with the latest stable update
that affects the autopkgtest for liburing. Reassigning.

On Mon, 2022-07-18 at 21:07:28 +0200, Paul Gevers wrote:
> Source: liburing
> Version: 2.1-2
> Severity: important
> X-Debbugs-Cc: br...@ubuntu.com

> Some days ago (approximately 7) the autopkgtest of liburing started to
> behave badly on the Debian and Ubuntu infrastructure. It's not totally
> clear to me what happens, but I have lxc containers left behind after
> the test that I can't clean up.
> 
> A similar thing seems to happen on the Ubuntu side because they have
> blocked the test from running recently and I'll do the same on our
> side.
> 
> https://git.launchpad.net/~ubuntu-release/autopkgtest-cloud/+git/autopkgtest-package-configs/commit/?id=fedf747ea808837217d373773d105f242819702d
> 
> Because your package didn't change in that time, I suspect one of your
> dependencies caused liburing to behave differently. It would be great
> if we figured out what that is.

Thanks,
Guillem

Bug#1017075: #1017075 dask - autopkgtest regression on i386 and armhf

[Drew Parsons]

On 2022-08-21 19:04, Drew Parsons wrote:


In regards to bug severity, the dask debci failures are now marked as
"Not a regression" so they won't hold up migration of dask.

Graham, should the bug severity therefore be reduced from Serious back
down to Important to enable migration of both dask and scipy?


To be fair, we're still waiting for another pythran fix for scipy, so no 
need to rush dask through on scipy's behalf.


I'll file an RC bug against scipy so we don't get confused about what's 
holding scipy up.

Bug#1017476: transition: poppler 22.08

[Sebastian Ramacher]

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

On 2022-08-16 13:52:42 -0400, Jeremy Bicha wrote:
> Package: release.debian.org
> Tags: moreinfo
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: popp...@packages.debain.org
> Control: block -1 by 1012845
> Control: block -1 by 1012818
> 
> On Ubuntu, gambas3 began failing to build on armhf recently. That bug
> may affect Debian too.
> 
> inkscape fails to build on several architectures. On Ubuntu, we have
> continued using an older inksacpe version that does build.
> 
> https://launchpad.net/ubuntu/+source/gambas3/3.17.3-1build1
> 
> This tracker is good:
> https://release.debian.org/transitions/html/auto-poppler.html

Please go ahead

Cheers

> 
> Thank you,
> Jeremy Bicha
> 

-- 
Sebastian Ramacher

Bug#1017861: grub2: bug-script broken?

[наб]

Source: grub2
Version: 2.04-20
Severity: normal

Dear Maintainer,

When reporting #1017860, reportbug told me this:
-- >8 --
Please select tags: (one at a time) [done]
Gathering additional data, this may take a while...
The package bug script /usr/share/bug/grub-pc/script exited with an error 
status (return code = 256). Do you still want to file a report [y|N|q|?]?
-- >8 --

I can reproduce this every time while reporting for grub-pc.

Running it verbatim also doesn't work (but I'm not sure if that's
supported):
-- >8 --

$ /usr/share/bug/grub-pc/script
/usr/share/bug/grub-pc/script: line 11: 3: Bad file descriptor
$ echo $?
1
-- >8 --

The error points to the expected:
-- >8 --
$ head /usr/share/bug/grub-pc/script
#!/bin/bash
set -e

if test -e /boot/grub/setup_left_core_image_in_filesystem ; then
  echo >&3
  echo "*** WARNING grub-setup left core.img in filesystem" 
>&3
fi

for i in /proc/mounts ; do
  if test -e $i ; then
-- >8 --

I don't know what the ABI is, so I can't diagnose further.

Best,
наб

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

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


signature.asc
Description: PGP signature

Bug#1017075: #1017075 dask - autopkgtest regression on i386 and armhf

[Drew Parsons]

Control: forwarded 1017075 https://github.com/dask/dask/issues/8620

As far as I can tell this issue will be fixed by the patch discussed in 
upstream Issue#8620.


In regards to bug severity, the dask debci failures are now marked as 
"Not a regression" so they won't hold up migration of dask.


Graham, should the bug severity therefore be reduced from Serious back 
down to Important to enable migration of both dask and scipy?


Drew

Bug#1017705: transition: benchmark

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2022-08-19 10:15:50 +0200, Timo Röhling wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear release team,
> 
> I'd like to transition benchmark after upstream broke ABI compatibility
> with their latest release. The tracker at
> https://release.debian.org/transitions/html/auto-benchmark.html
> looks good.
> 
> My test rebuilds on amd64 had the following outcomes:
> - openrct2 has an unrelated FTBFS [1] but builds OK if worked around
>   the issue by dropping -Werror
> - ros2-performance-text-fixture builds OK
> - pytorch fails to build, but is RC-buggy and not in testing
> 
> Most packages depend on benchmark for build tests only and do not ship
> any binaries linked against it. I did a few random rebuilds without
> issues, but did not test the archive comprehensively.

Please go ahead

Cheers
-- 
Sebastian Ramacher

Bug#1017860: grub-pc: upgrade-from-grub-legacy: needless dependency on bash

[наб]

Package: grub-pc
Version: 2.04-20
Severity: minor
Tags: patch

Dear Maintainer,

upgrade-from-grub-legacy has a /bin/bash shebang but doesn't use it,
almost at all. Please see diff to make it into /bin/sh, below.

Best,
наб

-- Package-specific info:

*** BEGIN /proc/mounts

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

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

Versions of packages grub-pc depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  grub-common2.04-20
ii  grub-pc-bin2.04-20
ii  grub2-common   2.04-20
ii  ucf3.0043

grub-pc recommends no packages.

grub-pc suggests no packages.

-- debconf information excluded
--- grub2-2.06-orig/debian/legacy/upgrade-from-grub-legacy	2022-06-10 11:15:11.0 +0200
+++ grub2-2.06/debian/legacy/upgrade-from-grub-legacy	2022-08-21 18:53:04.011918812 +0200
@@ -1,7 +1,7 @@
-#!/bin/bash -e
+#!/bin/sh -e
 
-if test ! -f /boot/grub/core.img ; then
-  echo -e "\ncore.img doesn't exist, trying to create it.\n" >&2
+if ! [ -f /boot/grub/core.img ]; then
+  printf '%s\n' "" "core.img doesn't exist, trying to create it." "" >&2
   grub-install --no-floppy --grub-setup=/bin/true "(hd0)" > /dev/null
 fi
 
@@ -13,8 +13,8 @@
   UPGRADE_FROM_GRUB_LEGACY=1 \
   /var/lib/dpkg/info/grub-pc.postinst configure dummy-version
 
-if test ! -f /boot/grub/grub.cfg ; then
-  echo -e "\nCalling update-grub to generate grub.cfg\n" >&2
+if ! [ -f /boot/grub/grub.cfg ]; then
+  printf '%s\n' "" "Calling update-grub to generate grub.cfg" "" >&2
   update-grub || cat << EOF
 Failed to generate /boot/grub/grub.cfg but GRUB2 has been already installed to
 your MBR.
@@ -27,10 +27,18 @@
 
 # These never contain any valuable information, and they aren't useful for
 # boot anymore, since we just overwrote MBR/PBR.
-rm -f /boot/grub/{{xfs,reiserfs,e2fs,fat,jfs,minix}_stage1_5,stage{1,2}}
+#
 # Remove marker file used to indicate that grub-install was run rather than
 # this script.  Since stage2 has been removed, we don't need this any more.
-rm -f /boot/grub/grub2-installed
+rm -f /boot/grub/xfs_stage1_5 \
+  /boot/grub/reiserfs_stage1_5 \
+  /boot/grub/e2fs_stage1_5 \
+  /boot/grub/fat_stage1_5 \
+  /boot/grub/jfs_stage1_5 \
+  /boot/grub/minix_stage1_5 \
+  /boot/grub/stage1 \
+  /boot/grub/stage2 \
+  /boot/grub/grub2-installed
 
 cat << EOF
 


signature.asc
Description: PGP signature

Bug#1017859: RM: golang-toml-dev -- RoQA; Dropped by the source package but still in the archive

[Shengjing Zhu]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: z...@debian.org


In golang-toml 0.4.1-1 (1 year ago), golang-toml-dev binary package was dropped
as a transitional package.
However golang-toml-dev is still in the archive.

I guess it's because some packages still use golang-toml-dev in Build-Depends.
However golang-github-burntsushi-toml-dev Provides golang-toml-dev,
so they don't FTBFS.

Maybe it needs a manual removal?

--

golang-toml (0.4.1-1) unstable; urgency=medium

  * Drop golang-toml-dev. (Closes: #939237)

 -- Nobuhiro Iwamatsu   Sat, 02 Oct 2021 13:19:20 +0900

Bug#1017858: grub-efi-amd64-signed: Failed to Perform SecureBoot Grub EFI Installation via Debootstrap

[Chew Kean Ho]

Package: grub-efi-amd64-bin
Version: 1+2.04+20
Severity: important
X-Debbugs-Cc: hollowaykea...@gmail.com

Dear Maintainer,


   * What led up to the situation?
When building a new minimal Debian OS (Bullseye stable) via debootstrap
non-interactively using a script tool, the resulting medium failed to build
a SecureBoot capable Grub EFI bootloader Debian OS without heavy manual
interventions.

The reason this path is pursued over Calamares is the precise minimal setup and
seamless build automation for various targets, especially for building a
firmware-like OS image consistently (e.g. generate an img file and set it up for
disk flashing). Additionally, it has pinpoint percision for OS configurations
without too much manual interventions (e.g. percisely install non-free firmware,
fleet management configurations in 1 go).

There are 2 expectations:

1. Maintainer: keep everything inside `shim-signed` and `grub-efi-ARCH-signed`
   packages' automation and any additional steps are considered as bugs as noted
   in https://lists.debian.org/debian-efi/2022/08/msg00019.html.
2. Me: as long as the Grub-EFI removable SecureBoot installation using
   `grub-install` is working accordingly will do.


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

The ideal build step specified by Maintainer failed to install SecureBoot
grub-efi into the target OS at all (after Maintainer's guidance). Both apt
packages did not setup a grub inside /boot directory. The build steps are
available at (look for Apt installing bullseye-backports' SecureBoot EFI Grub
bootloader): https://salsa.debian.org/-/snippets/615

The workaround I'm looking for a fix (currently failed) would be having a
removable Secureboot grub-efi properly installed (without disabling SecureBoot
at target BIOS). The current result is that the target enters a boot-loop at EFI
level (contiue boot --> reset system) when SecureBoot is enabled at BIOS.
Disabling SecureBoot at BIOS works fine but SecureBoot benefits were forfeited.
The build steps are available at (look for Apt installing bullseye-backports'
SecureBoot EFI Grub bootloader...): https://salsa.debian.org/-/snippets/616

The only workaround left is to directly build the target OS on the target system
(breaking the firmware build tool's purpose) and must mess with its efi nvram.
This breaks existing Linux benefits where the installed medium can be swapped
across different (but same type) of hardware. The build steps are available at
(look for Apt installing bullseye-backports' SecureBoot EFI Grub bootloader...):
https://salsa.debian.org/-/snippets/614

NOTE:
1. all methods were properly investigated on a SecureBoot laptop target, with
   a complete built Debian OS using method in
   https://salsa.debian.org/-/snippets/614 manually.
2. Both `shim-signed` and `grub-efi-amd64-signed` packages where investigated
   with `defconf-show` command. No `debconf-set-selections` options available
   like `locales` and `keyboard-configuration` packages.


   * What was the outcome of this action?
Maintainer: apt installing `shim-signed` and `grub-efi-amd64-signed` packages
failed to install a working SecureBoot capable grub bootloader.

Me: Both removable and non-removable SecureBoot `grub-install` command failed
to install SecureBoot capable Grub bootloader. However, `shim-signed` and
`grub-efi-amd64-signed` current status are within expectations (I don't expect
them to smartly know what I'm planning to do BUT I don't mind for having
Maintainer's expectations).


   * What outcome did you expect instead?
Maintainer:
`apt install shim-signed grub-efi-amd64-signed` should automatically installed
everything. There is no need to manually setup or mess with `grub-install`.

Me:
`grub-install` command works for removable SecureBoot should work without any
manual intervention without forcing a requirement to mess with target's EFI
nvram stats. The built-target must maintain the Linux swappable capability in
both SecureBoot and non-SecureBoot UEFI boot boundaries.

Legacy boot support is outside of this report scope (I won't be looking for
non-SecureBoot hardware around year 2022).




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

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

Versions of packages grub-efi-amd64-signed depends on:
ii  grub-common  2.04-20

Versions of packages grub-efi-amd64-signed recommends:
ii  shim-signed  1.38+15.4-7

grub-efi-amd64-signed suggests no packages.

Versions of packages grub-efi-amd64-bin depends on:
ii  grub-common  2.04-20

Versions of packages grub-efi-amd64

Bug#1017857: RM: golang-codegangsta-cli -- RoQA; superseded by golang-github-urfave-cli; RC buggy

[Shengjing Zhu]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: z...@debian.org

The homepage of golang-codegangsta-cli https://github.com/codegangsta/cli
is redirected to https://github.com/codegangsta/cli

And the latter is packaged as golang-github-urfave-cli some years ago.

Dak complains:

# Broken Build-Depends:
golang-github-xenolf-lego: golang-github-codegangsta-cli-dev

This redundant Build-Depends has been removed in 
golang-github-xenolf-lego/4.1.3-4.

Bug#695835: Partnerstwo wewnetrzne

[Dave E. Ramsden]

Mam dla Ciebie poufna propozycje biznesowa, która jest warta znaczna kwote 
(13,5 mln GBP). Jesli jestes zainteresowany, odpowiedz, aby uzyskac wiecej 
informacji.
 
Jesli to mozliwe, wskaz swoje zainteresowanie jezykiem angielskim dla lepszej 
komunikacji.
 
Z powazaniem,
Dave Ramsden
__
Sekretarz: Chantal Salvi

Bug#1017852: libc6: C locale is 7-bit (127 characters), must be 8-bit (256 characters) since POSIX Issue 7 TC2/Issue 8

[Aurelien Jarno]

control: severity -1 normal
control: tag -1 + upstream
control: retitle -1 libc6: mb* functions consider C locale as 7-bit (128 
characters) instead of 8-bit (256 characters) since POSIX Issue 7 TC2/Issue 8

On 2022-08-21 16:23, наб wrote:
> Package: libc6
> Version: 2.33-8
> Severity: important
> 
> Dear Maintainer,
> 
> Consider the following reproducer:

[ snip ]
 
> This breaks all programs that expect to process text/data portably,
> since in LC_ALL=C half of all bytes collapse to one character

"breaks" is a bit strong there given that this behaviour of the C locale
has been there for decades. Note also that the C.UTF-8 helps there, even
if I agree that it should also work with the POSIX locale.

> (for sort this means that they all collate equally, &c., &c.)!

It depends what is used for sorting. For instance the sort(1) utility
behaves correctly with the C locale.

> Consider a diff of XBD 6.2 ("Character Encoding"), Issue 7 vs Issue 7 TC2:
> -- >8 --
> @@ -1768,9 +1664,13 @@
> 
> 6.2 Character Encoding
> 
> -The POSIX locale contains the characters in Portable 
> Character Set , which have the properties listed
> -in LC_CTYPE . 
> In other locales, the presence, meaning, and
> -representation of any additional characters are locale-specific.
> +The POSIX locale shall contain 256 single-byte characters including the 
> characters in Portable Character
> +Set and Non-Portable Control Characters, which 
> have the properties listed in  +"../basedefs/V1_chap07.html#tag_07_03_01">LC_CTYPE. It is 
> unspecified whether characters not listed in those two tables
> +are classified as punct or cntrl, or neither. Other locales 
> shall contain the characters in  +"#tagtcjh_3">Portable Character Set and may contain any or all of the 
> control characters identified in  +"#tagtcjh_4">Non-Portable Control Characters; the presence, meaning, and 
> representation of any additional characters are
> +locale-specific.
> 
>  In locales other than the POSIX locale, a character may have a 
> state-dependent encoding. There are two types of these
>  encodings:
> -- >8 --

That comes for bug 663. However for the functions listed in that bug,
only the mb* functions are affected. The strcasecmp, strncasecmp,
toupper, tolower and is* functions behave as in the standard. 

Anyway please bring this issue upstream, as it has to be solved there. 

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#1011165: org.h2.jdbc.JdbcSQLSyntaxErrorException: schema "MEDIATHEKVIEW" not found

[Markus Koschany]

Control: severity -1 wishlist
Control: retitle -1 mediathekview update discussion


I have fixed the underlying problem by using an internal version of the h2
database now. 

I will try to package tilesfx and glazedlists next.


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

Bug#1017856: new upstream folder syntax/shared is not packaged

[Gianluigi Tiesi]

Package: vim-runtime
Version: 2:9.0.0229-1
Severity: normal

Hi,
after upgrading to vim 2:9.0.0229-1, I've discovered that typescript syntax is 
broken:

Error detected while processing 
/home/sherpya/.vimrc[1]../usr/share/vim/vim90/syntax/syntax.vim[43]..BufRead 
Autocommands for "*.ts"..FileType Autocommands for "*"..Syntax Autocommands for 
"*"..function 5_SynSet[25]..script 
/usr/share/vim/vim90/syntax/typescript.vim:
line   38:
E484: Can't open file /usr/share/vim/vim90/syntax/shared/typescriptcommon.vim

Looks like upstream added runtime/syntax/shared folder with the missing file 
(only one for now)

The readme in that directory says:

This directory "runtime/syntax/shared" contains Vim script files that are
generated or used by more then one syntax file.

Regards

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

Kernel: Linux 4.19.0-21-amd64 (SMP w/8 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: sysvinit (via /sbin/init)

vim-runtime depends on no packages.

Versions of packages vim-runtime recommends:
ii  vim  2:9.0.0229-1

vim-runtime suggests no packages.

-- no debconf information

Bug#998306: dwarf2sources FTBFS with rust-object 0.20

[Peter Michael Green]

severity 998306 serious
thanks


I have uploaded rust-backtrace and related packages to experimental for now.


rust-backtrace and related packages have now been uploaded to unstable,
bumping to serious.

Bug#1017855: Support Sybil 3.0

[Andrey Rahmatullin]

Source: flufl.lock
Version: 5.0.1-3
Severity: normal

The new version of python3-sybil, currently available in experimental, breaks
building of the sid version of flufl.lock. The new upstream version of
flufl.lock support it. As I intend to update python3-sybil in sid before the
bookworm freeze, please upgrade flufl.lock to the latest upstream version or
patch the sid version to support new sybil.


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

Kernel: Linux 5.19.0-trunk-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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

Bug#970146: still blocked

[Andrey Rahmatullin]

On Fri, Jul 15, 2022 at 10:44:42AM -0400, Matt Barry wrote:
> block -1 by 1014974
> thanks

On Wed, Jun 29, 2022 at 01:15:23PM -0400, Matt Barry wrote:
> block -1 by 1014067
> thanks

On Thu, Jun 16, 2022 at 12:16:12PM -0400, Matt Barry wrote:
> retitle -1 ITA: python-public -- @public decorator for adding names to __all__
> thanks

Hi Matt, in case you haven't see that, your emails didn't have any effect
because you need to either send the commands to control@ or send them in
Control: pseudo-headers (and if you don't have anything human-readable to
add, you should just use bts(1)).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1017854: Support Sybil 3.0

[Andrey Rahmatullin]

Source: python-public
Version: 2.3-2
Severity: normal

The new version of python3-sybil, currently available in experimental, breaks
building of the sid version of python-public. The new upstream version of
python-public support it. As I intend to update python3-sybil in sid before the
bookworm freeze, please upgrade python-public to the latest upstream version or
patch the sid version to support new sybil.


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

Kernel: Linux 5.19.0-trunk-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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

Bug#1017853: emacs-nox: byte compiling debian-startup.el fails if emacs-el is not installed

[David Bremner]

Package: emacs-nox
Version: 1:28.1+1-2
Severity: serious
Justification: does not install
X-Debbugs-Cc: debian-emac...@lists.debian.org

Recipe to duplicate
===

(assuming schroot is set up in a more or less
standard way with a chroot called sid, and session support).

% schroot -c sid -n test -b

# the following fails with crash [1].
% sudo schroot -c test -r -- apt install --no-install-recommends emacs-nox

# the following succeeds:

sudo schroot -c test -r -- apt install --no-install-recommends emacs-nox 
emacs-el

Discussion
==

This is most likely the same bug as #1017798 and #1017779 (and probably others).

I don't think it depends on the flavour of emacs (I tested also emacs-gtk, same 
results).

[1]: crash log:

Install emacsen-common for emacs
emacsen-common: Handling install of emacsen flavor emacs
corrupted size vs. prev_size
Fatal error 6: Aborted
Backtrace:
emacs(+0xe9d13)[0x55ec81734d13]
emacs(+0x30fed)[0x55ec8167bfed]
emacs(+0x314b7)[0x55ec8167c4b7]
emacs(+0xe8058)[0x55ec81733058]
emacs(+0xe8149)[0x55ec81733149]
/lib/x86_64-linux-gnu/libc.so.6(+0x3daf0)[0x7f9f70c64af0]
/lib/x86_64-linux-gnu/libc.so.6(+0x8983c)[0x7f9f70cb083c]
/lib/x86_64-linux-gnu/libc.so.6(raise+0x12)[0x7f9f70c64a52]
/lib/x86_64-linux-gnu/libc.so.6(abort+0xcf)[0x7f9f70c4f469]
/lib/x86_64-linux-gnu/libc.so.6(+0x7dc18)[0x7f9f70ca4c18]
/lib/x86_64-linux-gnu/libc.so.6(+0x9355a)[0x7f9f70cba55a]
/lib/x86_64-linux-gnu/libc.so.6(+0x93eb6)[0x7f9f70cbaeb6]
/lib/x86_64-linux-gnu/libc.so.6(+0x967a1)[0x7f9f70cbd7a1]
/lib/x86_64-linux-gnu/libc.so.6(malloc+0x1a2)[0x7f9f70cbe382]
emacs(+0x12ba45)[0x55ec81776a45]
emacs(+0x12bbb6)[0x55ec81776bb6]
emacs(+0x12bdf2)[0x55ec81776df2]
emacs(+0x12bf21)[0x55ec81776f21]
emacs(+0x102c38)[0x55ec8174dc38]
emacs(+0x173a36)[0x55ec817bea36]
emacs(+0x17790b)[0x55ec817c290b]
emacs(+0x17850a)[0x55ec817c350a]
emacs(+0x14df36)[0x55ec81798f36]
emacs(+0x14e165)[0x55ec81799165]
emacs(+0x14e3af)[0x55ec817993af]
emacs(+0x1737a8)[0x55ec817be7a8]
emacs(+0x174170)[0x55ec817bf170]
emacs(+0x17790b)[0x55ec817c290b]
emacs(+0x17850a)[0x55ec817c350a]
emacs(+0x14df36)[0x55ec81798f36]
emacs(+0x14e165)[0x55ec81799165]
emacs(+0x14e3af)[0x55ec817993af]
emacs(+0x1737a8)[0x55ec817be7a8]
emacs(+0x174170)[0x55ec817bf170]
emacs(+0x17790b)[0x55ec817c290b]
emacs(+0x17850a)[0x55ec817c350a]
emacs(+0x14df36)[0x55ec81798f36]
emacs(+0x14e165)[0x55ec81799165]
emacs(+0x14e3af)[0x55ec817993af]
emacs(+0x1737a8)[0x55ec817be7a8]
emacs(+0x174170)[0x55ec817bf170]
...
Aborted

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

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

Versions of packages emacs-nox depends on:
ii  emacs-bin-common  1:27.1+1-3.1+b1
ii  emacs-common  1:27.1+1-3.1
ii  libacl1   2.3.1-1
ii  libasound21.2.7.2-1
ii  libc6 2.34-3
ii  libdbus-1-3   1.14.0-2
pn  libgccjit0
ii  libgmp10  2:6.2.1+dfsg1-1
ii  libgnutls30   3.7.7-2
ii  libgpm2   1.20.7-10
ii  libjansson4   2.14-2
ii  liblcms2-22.13.1-1
ii  libselinux1   3.4-1+b1
ii  libsystemd0   251.3-1
ii  libtinfo6 6.3+20220423-2
ii  libxml2   2.9.14+dfsg-1+b1
ii  zlib1g1:1.2.11.dfsg-4

emacs-nox recommends no packages.

Versions of packages emacs-nox suggests:
pn  emacs-common-non-dfsg  

Bug#1017779: please test

[David Bremner]

Can you test if having emacs-el installed (e.g. via recommends) allows
the installation / postinst to complete? That will help narrow down what
the bug is.

d

Bug#1011628: rust-fasteval FTBFS: test failure

[Eric Long]

Control: tags 1011628 + patch
Control: thanks

Hello Adrian and Maintainers,

I have submitted a merge request [1] that fixes the tests and FTBFS.

Please let me know if I missed something.

Cheers,
Eric

[1]: https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/378

Bug#1006026: ruby-axiom-types: FTBFS: ERROR: Test "ruby3.0" failed: ArgumentError: Cannot proxy frozen objects, rspec-mocks relies on proxies for method stubbing and expectations.

[Antonio Terceiro]

Control: retitle -1 ruby-axiom-types: FTBFS randomly: ArgumentError: Cannot 
proxy frozen objects, rspec-mocks relies on proxies for method stubbing and 
expectations.

I tried this locally and couldn't reproduce twice in row, first on my
main system, then with sbuild. I then tried 10 times in a row, and got a
60% failure rate. Tried again 20 times, then 55% failure rate.

I tried debugging this with the upstream sources from git and
ruby-standalone + bundler, but the upstream tree has broken dependencies
and I lost my patience.

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

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


signature.asc
Description: PGP signature