date:20220718

Source: haskell-crypto-numbers
Version: 0.2.7-10
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-crypto-numbers=sid

...
Crypto/Number/Prime.hs:82:6: error:
Variable not in scope: nextPrimeInteger :: Integer -> Integer
   |
82 | (nextPrimeInteger n, rng)
   |  

Crypto/Number/Prime.hs:92:10: error:
• Variable not in scope:
testPrimeInteger :: Integer -> Int# -> Int#
• Perhaps you meant ‘testBitInteger’ (imported from 
GHC.Integer.GMP.Internals)
   |
92 | case testPrimeInteger n tries of
   |  
 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 709
Debian::Debhelper::Buildsystem::Haskell::Recipes::haddock_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1015176: guake fails to start

2022-07-18 Thread Awtul

Package: guake
Followup-For: Bug #1015176

Problem is now solved. "guake" starts normaly. That is because of the recent 
upgrade,
I guess (gir1.2-notify-0.7:amd64 (0.8.0-1, 0.8.1-1)).


Thanks for your work!

Bug#1015290: haskell-hsini FTBFS: error: Couldn't match type

Source: haskell-hsini
Version: 0.5.1.2-6
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-hsini=sid

...
tst/ReaderI.hs:118:27: error:
• Couldn't match type: String -> IniFile
 with: 
template-haskell-2.17.0.0:Language.Haskell.TH.Syntax.Q
 
template-haskell-2.17.0.0:Language.Haskell.TH.Syntax.Exp
  Expected: template-haskell-2.17.0.0:Language.Haskell.TH.Lib.Internal.ExpQ
Actual: String -> IniFile
• Probable cause: ‘OptionContL’ is applied to too few arguments
  In the expression: OptionContL
  In the untyped splice: $OptionContL
|
118 | expected = Right $OptionContL "foo"
|   ^^^
 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "build", "--builddir=dist-ghc") called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"build", "--builddir=dist-ghc") called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 642
Debian::Debhelper::Buildsystem::Haskell::Recipes::build_recipe() called 
at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1015289: haskell-genvalidity FTBFS: error: Could not find module ‘Data.RelativeValidity’

Source: haskell-genvalidity
Version: 0.11.0.0-1
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-genvalidity=sid

...
src/Data/GenRelativeValidity.hs:9:1: error:
Could not find module ‘Data.RelativeValidity’
Use -v (or `:set -v` in ghci) to see a list of the files searched for.
  |
9 | import Data.RelativeValidity
  | 
 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 709
Debian::Debhelper::Buildsystem::Haskell::Recipes::haddock_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1015288: haskell-test-framework-th-prime FTBFS: Couldn't match expected type ‘Maybe Exp’ with actual type ‘Exp’

Source: haskell-test-framework-th-prime
Version: 0.0.10-4
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-test-framework-th-prime=sid

...
Test/Framework/TH/Prime/Parser.hs:41:20: error:
• Couldn't match expected type ‘Maybe Exp’ with actual type ‘Exp’
• In the expression: ListE (map toCase cases)
  In the first argument of ‘TupE’, namely
‘[ListE (map toCase cases), ListE (map toProp props)]’
  In the second argument of ‘($)’, namely
‘TupE [ListE (map toCase cases), ListE (map toProp props)]’
   |
41 | return $ TupE [ListE (map toCase cases), ListE (map toProp props)]
   |

Test/Framework/TH/Prime/Parser.hs:41:46: error:
• Couldn't match expected type ‘Maybe Exp’ with actual type ‘Exp’
• In the expression: ListE (map toProp props)
  In the first argument of ‘TupE’, namely
‘[ListE (map toCase cases), ListE (map toProp props)]’
  In the second argument of ‘($)’, namely
‘TupE [ListE (map toCase cases), ListE (map toProp props)]’
   |
41 | return $ TupE [ListE (map toCase cases), ListE (map toProp props)]
   |  
 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 709
Debian::Debhelper::Buildsystem::Haskell::Recipes::haddock_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1015287: dropbear-initramfs: Configure dropbear to use VLAN

2022-07-18 Thread Graham Cobb

Package: dropbear-initramfs
Version: 2022.82-3
Severity: wishlist

I have recently started using dropbear-initramfs to try to help with situations
where boot problems need to be resolved remotely.

I have it working on one system but when I try to use it on a second system it 
doesn't work.
This second system is a server which is connected directly to a VLAN trunk, so 
the IP config
needs to specify a VLAN to use.

I tried using the kernel command line "ip=" to specify the interface name with 
a VLAN id
in the same format as used in /etc/network/interfaces:

ip=192.168.0.205name.a.b.c:eth0.100::192.168.0.1:

However, this did not work.

It would be great if I could use dropbear-initramfs on the host systems
which are directly connected to the VLAN trunk.


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

Kernel: Linux 5.16.0-5-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_IE.utf8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dropbear-initramfs depends on:
ii  busybox  1:1.35.0-1
ii  dropbear-bin 2022.82-3
ii  initramfs-tools  0.140
ii  udev 250.4-1

Versions of packages dropbear-initramfs recommends:
ii  cryptsetup-initramfs  2:2.4.3-1

dropbear-initramfs suggests no packages.

-- debconf-show failed

Bug#1015259: calibre: preferences link no longer available

2022-07-18 Thread yokota

Hello Gary,

> Wanted to edit Calibre preferences and attempted to find link fo them.  No 
> such
> link exists any more.

Right most command buttons are not display when Calibre window is too smalll.
Enlarge Calibre window to display more icons on command tool bar.

Use shortcut key "Ctrl+p" to show preferences window.
Use "Toolbars & menus" configuration item on preferences window to
arrange command icons order on tool bars.
Use "Look & feel" configuretion item to change command icon size.

--
YOKOTA

Bug#1014350: Disowning the package

2022-07-18 Thread Ben Westover

Control: retitle -1 RFP: nuxhash -- NiceHash cryptocurrency mining client for 
Linux
Control: noowner -1

I no longer own an NVIDIA graphics card, so I will not be able to fully
test this package well outside of making sure it builds. The package  
was ready for upload, but never got sponsored. It's still available in
Salsa at https://salsa.debian.org/python-team/packages/nuxhash.

--
Ben Westover


OpenPGP_signature
Description: OpenPGP digital signature

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

2022-07-18 Thread Guillem Jover

Hi!

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.

While only having skimmed over the logs, the first suspect for me would
be the Linux kernel, where liburing might be triggering some kernel bug.
Were the systems upgraded around that time with a newer kernel version
(is that a 5.18.x from bpo)? The only other options if that would not
have been the case that seem plausible would be glibc (which was uploaded
on the 10th, and could be a suspect), or lxc itself or similar, but that
has not been uploaded for a while in sid.

Thanks,
Guillem

Bug#1015285: RM: librest/experimental -- ROM; wrong version for transition

2022-07-18 Thread PaulLiu

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

Dear ftp-master,

Please remove librest in experimental. This version is wrong for transition.

Thanks,
Paul

Bug#1013684: closed by Debian FTP Masters (reply to Héctor Orón Martínez ) (Bug#1013684: fixed in dejagnu 1.6.3-1)

2022-07-18 Thread Hilmar Preuße


Control: reopen -1
Control: found -1 1.6.3-1

Am 12.07.2022 um 10:36 teilte Debian Bug Tracking System mit:

The issue is not solved you. the Dep line was not fixed, it still 
displays a Dep on "dpkg (>= 1.15.4) | install-info". Both can be removed.


Hilmar


This is an automatic notification regarding your Bug report
which was filed against the dejagnu package:

#1013684: dejagnu: Please remove dependency on install-info

It has been closed by Debian FTP Masters  (reply to 
Héctor Orón Martínez ).

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Debian FTP Masters 
 (reply to Héctor Orón Martínez 
) by
replying to this email.




--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1015284: haskell-githash FTBFS: error: Couldn't match expected type

Source: haskell-githash
Version: 0.1.4.0-1
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-githash=sid

...
test/GitHashSpec.hs:14:21: error:
• Couldn't match expected type: Language.Haskell.TH.Syntax.Code
  Language.Haskell.TH.Syntax.Q t0
  with actual type: Language.Haskell.TH.Syntax.Q
  (Language.Haskell.TH.Syntax.TExp (Either 
String GitInfo))
• In the expression: tGitInfoCwdTry
  In the Template Haskell splice $$tGitInfoCwdTry
  In the expression: $$tGitInfoCwdTry
• Relevant bindings include
egi :: t0 (bound at test/GitHashSpec.hs:14:13)
   |
14 | let egi = $$tGitInfoCwdTry
   | ^^
 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "build", "--builddir=dist-ghc") called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"build", "--builddir=dist-ghc") called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 642
Debian::Debhelper::Buildsystem::Haskell::Recipes::build_recipe() called 
at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1015283: [INTL:de] Update of German translation

2022-07-18 Thread Dr. Tobias Quathamer


Package: adduser
Version: 3.122
Severity: wishlist
Tags: l10n patch

Hi,

I've updated the German translation of adduser (po/de.po).

Regards,
Tobias
# German translation of adduser
# Copyright © 2000, 2006 Free Software Foundation, Inc.
# Copyright © Roland Bauerschmidt , 2000.
# Copyright © Dr. Tobias Quathamer , 2006, 2010, 2017, 2022.
msgid ""
msgstr ""
"Project-Id-Version: adduser 3.116\n"
"Report-Msgid-Bugs-To: addu...@packages.debian.org\n"
"POT-Creation-Date: 2022-03-08 15:19+0100\n"
"PO-Revision-Date: 2022-07-18 22:16+0200\n"
"Last-Translator: Dr. Tobias Quathamer \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Lokalize 21.12.3\n"
"Plural-Forms:  nplurals=2; plural=(n != 1);\n"

#. everyone can issue "--help" and "--version", but only root can go on
#: ../adduser:138
msgid "Only root may add a user or group to the system.\n"
msgstr "Nur root darf Benutzer oder Gruppen zum System hinzufügen.\n"

#: ../adduser:164 ../deluser:133
msgid "Only one or two names allowed.\n"
msgstr "Nur ein oder zwei Namen erlaubt.\n"

#. must be addusertogroup
#: ../adduser:169
msgid "Specify only one name in this mode.\n"
msgstr "Geben Sie in diesem Modus nur einen Namen an.\n"

#: ../adduser:185
msgid "The --group, --ingroup, and --gid options are mutually exclusive.\n"
msgstr ""
"Die Optionen --group, --ingroup und --gid schließen sich gegenseitig aus.\n"

#: ../adduser:190
msgid "The home dir must be an absolute path.\n"
msgstr "Das Home-Verzeichnis muss ein absoluter Pfad sein.\n"

#: ../adduser:194
#, perl-format
msgid "Warning: The home dir %s you specified already exists.\n"
msgstr ""
"Warnung: Das von Ihnen angegebene Home-Verzeichnis %s existiert bereits.\n"

#: ../adduser:196
#, perl-format
msgid "Warning: The home dir %s you specified can't be accessed: %s\n"
msgstr ""
"Warnung: Auf das von Ihnen angegebene Home-Verzeichnis %s kann nicht "
"zugegriffen werden: %s\n"

#: ../adduser:258
#, perl-format
msgid "The group `%s' already exists as a system group. Exiting.\n"
msgstr "Die Gruppe »%s« existiert bereits als Systemgruppe. Programmende.\n"

#: ../adduser:264
#, perl-format
msgid "The group `%s' already exists and is not a system group. Exiting.\n"
msgstr ""
"Die Gruppe »%s« existiert bereits und ist keine Systemgruppe. Programmende.\n"

#: ../adduser:270
#, perl-format
msgid "The group `%s' already exists, but has a different GID. Exiting.\n"
msgstr ""
"Die Gruppe »%s« existiert bereits, hat aber eine andere GID. Programmende.\n"

#: ../adduser:274 ../adduser:304
#, perl-format
msgid "The GID `%s' is already in use.\n"
msgstr "Die GID »%s« wird bereits verwendet.\n"

#: ../adduser:282
#, perl-format
msgid ""
"No GID is available in the range %d-%d (FIRST_SYS_GID - LAST_SYS_GID).\n"
msgstr ""
"Es ist keine GID im Bereich %d-%d verfügbar (FIRST_SYS_GID - LAST_SYS_GID).\n"

#: ../adduser:283 ../adduser:313
#, perl-format
msgid "The group `%s' was not created.\n"
msgstr "Gruppe »%s« wurde nicht angelegt.\n"

#: ../adduser:288 ../adduser:317
#, perl-format
msgid "Adding group `%s' (GID %d) ...\n"
msgstr "Lege Gruppe »%s« (GID %d) an ...\n"

#: ../adduser:293 ../adduser:322 ../adduser:343 ../deluser:361 ../deluser:401
#: ../deluser:438
msgid "Done.\n"
msgstr "Fertig.\n"

#: ../adduser:302 ../adduser:764
#, perl-format
msgid "The group `%s' already exists.\n"
msgstr "Die Gruppe »%s« existiert bereits.\n"

#: ../adduser:312
#, perl-format
msgid "No GID is available in the range %d-%d (FIRST_GID - LAST_GID).\n"
msgstr "Es ist keine GID im Bereich %d-%d verfügbar (FIRST_GID - LAST_GID).\n"

#: ../adduser:329 ../deluser:225 ../deluser:410
#, perl-format
msgid "The user `%s' does not exist.\n"
msgstr "Der Benutzer »%s« existiert nicht.\n"

#: ../adduser:330 ../adduser:563 ../adduser:771 ../deluser:370 ../deluser:413
#, perl-format
msgid "The group `%s' does not exist.\n"
msgstr "Die Gruppe »%s« existiert nicht.\n"

#: ../adduser:333 ../adduser:567
#, perl-format
msgid "The user `%s' is already a member of `%s'.\n"
msgstr "Der Benutzer »%s« ist bereits ein Mitglied der Gruppe »%s«.\n"

#: ../adduser:337 ../adduser:573
#, perl-format
msgid "Adding user `%s' to group `%s' ...\n"
msgstr "Füge Benutzer »%s« der Gruppe »%s« hinzu ...\n"

#: ../adduser:354
#, perl-format
msgid "The system user `%s' already exists. Exiting.\n"
msgstr "Der Systembenutzer »%s« existiert bereits. Programmende.\n"

#: ../adduser:357
#, perl-format
msgid "The user `%s' already exists, but is not a system user. Exiting.\n"
msgstr ""
"Der Benutzer »%s« existiert bereits, ist aber kein Systembenutzer. "
"Programmende.\n"

#: ../adduser:361
#, perl-format
msgid "The user `%s' already exists with a different UID. Exiting.\n"
msgstr ""
"Der Benutzer »%s« existiert bereits mit einer anderen UID. Programmende.\n"

#: ../adduser:375
#, perl-format
msgid ""
"No UID/GID pair is available in the range %d-%d (FIRST_SYS_UID - "
"LAST_SYS_UID).\n"

Bug#1015281: haskell-vault FTBFS: Encountered missing or private dependencies: base >=4.5 && <4.15

Source: haskell-vault
Version: 0.3.1.4-1
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-vault=sid

...
hlibrary.setup: Encountered missing or private dependencies:
base >=4.5 && <4.15

 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 622
Debian::Debhelper::Buildsystem::Haskell::Recipes::configure_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1015280: haskell-pipes-zlib FTBFS: error: Couldn't match type

Source: haskell-pipes-zlib
Version: 0.4.4.2-3
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-pipes-zlib=sid

...
src/Pipes/Zlib.hs:81:13: error:
• Couldn't match type: forall x'1 x1.
   Proxy x'1 x1 () B.ByteString m0 ()
 with: Proxy x' x () B.ByteString m1 a0
  Expected: Popper -> Proxy x' x () B.ByteString m1 a0
Actual: Popper -> Producer' B.ByteString m0 ()
• In the first argument of ‘(=<<)’, namely ‘fromPopper’
  In a stmt of a 'do' block:
fromPopper =<< liftIO (feedInflate inf bs)
  In the expression:
do fromPopper =<< liftIO (feedInflate inf bs)
   flush inf
   leftover <- liftIO $ getUnusedInflate inf
   if B.null leftover then
   go p' inf
   else
   return $ Left (yield leftover >> p')
• Relevant bindings include
p' :: Producer B.ByteString m1 b (bound at src/Pipes/Zlib.hs:80:21)
res :: Either b (B.ByteString, Producer B.ByteString m1 b)
  (bound at src/Pipes/Zlib.hs:77:7)
p :: Producer B.ByteString m1 b (bound at src/Pipes/Zlib.hs:76:8)
go :: Producer B.ByteString m1 b
  -> Inflate
  -> Proxy
   x'
   x
   ()
   B.ByteString
   m1
   (Either (Proxy X () () B.ByteString m1 b) b)
  (bound at src/Pipes/Zlib.hs:76:5)
   |
81 | fromPopper =<< liftIO (Z.feedInflate inf bs)
   | ^^
 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 709
Debian::Debhelper::Buildsystem::Haskell::Recipes::haddock_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1015279: ITP: python-pywayland -- provides Python bindings to the Wayland library

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

* Package name: python-pywayland
  Version : 0.4.13
  Upstream Author : Sean Vig
* URL : https://pywayland.readthedocs.io/en/latest/
* License : Apache
  Programming Lang: Python
  Description : provides Python bindings to the Wayland library

PyWayland provides Python bindings to the Wayland library, using pure Python by
making calls through the CFFI module.

I plan to maintain this within the Python Team.

Bug#1007752: NMU in DELAYED/7

2022-07-18 Thread Florian Ernst

Greetings,

On Mon, Jul 18, 2022 at 09:34:22AM +0200, Adam Borowski wrote:
> On Mon, Jul 18, 2022 at 07:56:14AM +0200, Florian Ernst wrote:
> > [...]
> > As such I really wouldn't like to see this uploaded in its current form.
> 
> Ok, cancelled.

Thanks.

> > Still, given the apparent lack of public respone I was considering
> > starting the salvaging process for lcms2
> 
> Sounds good.  Of course, I have no interest in lcms2 itself.

On Mon, Jul 18, 2022 at 09:43:31AM +0200, Mathieu Malaterre wrote:
> On Mon, Jul 18, 2022 at 8:00 AM Florian Ernst  wrote:
> > Still, given the apparent lack of public respone I was considering
> > starting the salvaging process for lcms2 as described in the Developer's
> > Reference (5.12) and the Debian Wiki
> > . Of course, this would result
> > in some more delay until the new version could get uploaded. Unless
> > Thomas does it himself, of course.
> 
> Excellent, thanks for volunteering.

JFTR, an ITS has now been filed in ,
with both of you also X-Debbugs-Cc'd.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1015278: ITP: python-pywlroots -- Python binding to the wlroots library using cffi

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

* Package name: python-pywlroots
  Version : 0.15.18
  Upstream Author : Sean Vig
* URL : https://github.com/flacjacket/pywlroots
* License : UIUC (NCSA)
  Programming Lang: Python
  Description : Python binding to the wlroots library using cffi
 A Python binding to the wlroots library using cffi.
 The library uses pywayland to provide the Wayland
 bindings and python-xkbcommon to provide wlroots
 keyboard functionality.

Bug#1015151: firejail: (Regression) Segfault when using --net=$namespace

2022-07-18 Thread anonymous coward

Package: firejail
Followup-For: Bug #1015151
X-Debbugs-Cc: debbug.1015...@sideload.33mail.com

I tried the suggestion and it made no difference, but I suspect I have
a separate problem with local profiles.  I first looked through the
man page for a commandline equivalent to “ignore noroot” and found
nothing.  So then I created:

  /home/user/my_symlinked_configs/firejail/my_app.local

with “ignore noroot” along with a whitelisted path and “net
vnet0”. Then I ran:

  $ firejail --profile=/home/user/my_symlinked_configs/firejail/my_app.local\
 --dns="$(ip address show dev vnet0 | awk 
'/inet\>/{gsub(/[/].*/,""); print $2 }')\
 my_app

(note that the --dns option *must* be on the CLI because unfortunately
 profiles are incapable of command substitution)

It got the segfault as before.  Then I downgraded to version
0.9.64.4-2 again and ran the same command.  The app ran but it acted
as if the whitelisted folder did not exist.  So I have a problem
making profiles work (likely because firejail cannot handle symlinks
properly [or even real dirs that happen to have a symlink]). So
apparently I cannot test the “ignore noroot” profile-only option.

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

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

Versions of packages firejail depends on:
ii  libapparmor1  2.13.6-10
ii  libc6 2.31-13+deb11u3
ii  libselinux1   3.1-3

Versions of packages firejail recommends:
ii  firejail-profiles  0.9.64.4-2+deb11u1
ii  iproute2   5.10.0-4
ii  iptables   1.8.7-1
ii  xauth  1:1.1-1
ii  xdg-dbus-proxy 0.1.2-2
ii  xpra   3.0.13+dfsg1-1
ii  xvfb   2:1.20.11-1+deb11u1

firejail suggests no packages.

-- Configuration Files:
/etc/firejail/firejail.config changed [not included]

-- no debconf information

Bug#1015276: ITS: lcms2

2022-07-18 Thread Florian Ernst

Source: lcms2
Version: 2.12~rc1-2
Severity: important
X-Debbugs-Cc: Thomas Weber , lc...@packages.debian.org, 
Mathieu Malaterre , Adam Borowski 

Greetings,

hereby I declare my intention to salvage the "lcms2" package using the
procedure described in the Developer's Reference (5.12) and the Debian
Wiki .

Criteria are met as follows:

* The package is in clear need of some love and care:
  * There are three upstream releases missing (2.12, 2.13, 2.13.1), cf.
, filed 16 Mar 2022.
  * There is work needed from a quality-assurance perspective as the
packaging uses outdated / deprecated standards, cf.


AND

* An upload is needed to fix this.

AND

* At least one to the following applies (non-applicable omitted):
  * There is no visible activity regarding the package for six months.
Attempting to elicit a maintainer response failed, cf.
 ff.

My objective is to have this package in Debian, and in good shape. So
if you (maintainer) want to resume taking care of it, please do. And in
case you object or already have other plans, just let me know.

I am well aware that filing this ITS is a stretch as the criteria are
hardly met. I'm filing it nonetheless already due to demand for an
updated package for matching upstream requirements. Given these
circumstances I plan to wait a bit longer with the ITS waiting phase.

Kind regards,
Flo


signature.asc
Description: PGP signature

Bug#1015274: haskell-cryptonite FTBFS: error: Variable not in scope

Source: haskell-cryptonite
Version: 0.26-1
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-cryptonite=sid

...
Crypto/Number/Compat.hs:76:43: error:
• Variable not in scope:
powModSecInteger :: Integer -> Integer -> Integer -> Integer
• Perhaps you meant one of these:
‘gmpPowModSecInteger’ (line 76),
‘powModInteger’ (imported from GHC.Integer.GMP.Internals)
   |
76 | gmpPowModSecInteger b e m = GmpSupported (powModSecInteger b e m)
   |   

Crypto/Number/Compat.hs:107:32: error:
Variable not in scope: nextPrimeInteger :: Integer -> Integer
|
107 | gmpNextPrime n = GmpSupported (nextPrimeInteger n)
|

Crypto/Number/Compat.hs:116:10: error:
• Variable not in scope:
testPrimeInteger :: Integer -> Int# -> Int#
• Perhaps you meant ‘testBitInteger’ (imported from 
GHC.Integer.GMP.Internals)
|
116 | case testPrimeInteger n tries of
|  
 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 709
Debian::Debhelper::Buildsystem::Haskell::Recipes::haddock_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

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

2022-07-18 Thread Brian Murray

On Mon, Jul 18, 2022 at 09:07:28PM +0200, Paul Gevers wrote:
> Source: liburing
> Version: 2.1-2
> Severity: important
> X-Debbugs-Cc: br...@ubuntu.com
> 
> Dear Guillem,
> 
> 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.

I managed to capture some information from an instance in an Ubuntu bug
report - http://launchpad.net/bugs/1981636.

--
Brian Murray @ubuntu.com

Bug#1015273: coreutils: rm -d doesn't try to remove unreadable directories, lies in error message, with fails to prompt with -i

2022-07-18 Thread наб

Package: coreutils
Version: 8.32-4.1
Severity: normal

Dear Maintainer,

Fun one for ya: the baseline:
-- >8 --
$ mkdir -p /tmp/psko
$ rm -vid /tmp/psko
rm: remove directory '/tmp/psko'? y
removed directory '/tmp/psko'
-- >8 --

Bug a:
-- >8 --
$ mkdir -p /tmp/psko
$ chmod -r /tmp/psko
$ rm -vid /tmp/psko; echo $?
rm: cannot remove '/tmp/psko': Directory not empty
1
-- >8 --

Absolutely 0 prompt, despite -i!
That's very fun (and a POSIX violation)!

Bug b:
-- >8 --
$ strace rm -vid /tmp/psko 2>&1 | grep -v locale
execve("/bin/rm", ["rm", "-vid", "/tmp/psko"], 0xff8fbc48 /* 24 vars */) = 0
/* ... */
arch_prctl(ARCH_SET_FS, 0xf7f9e240) = 0
mprotect(0xf7f8b000, 8192, PROT_READ)   = 0
mprotect(0x40f000, 4096, PROT_READ) = 0
mprotect(0xf7fcd000, 8192, PROT_READ)   = 0
munmap(0xf7f96000, 26859)   = 0
brk(NULL)   = 0xaa6000
brk(0xac7000)   = 0xac7000
brk(0xac8000)   = 0xac8000
newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=3041504, ...}, AT_EMPTY_PATH) 
= 0
mmap(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf7a0
mmap(NULL, 2596864, PROT_READ, MAP_PRIVATE, 3, 0x6d000) = 0xf7786000
close(3)= 0
ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
newfstatat(AT_FDCWD, "/tmp/psko", {st_mode=S_IFDIR|0311, st_size=40, ...}, 
AT_SYMLINK_NOFOLLOW) = 0
openat(AT_FDCWD, "/tmp/psko", 
O_RDONLY|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW|O_DIRECTORY) = -1 EACCES (Permission 
denied)
newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=2996, ...}, AT_EMPTY_PATH) = 0
read(3, "# Locale name alias data base.\n#"..., 4096) = 2996
read(3, "", 4096)   = 0
close(3)= 0
write(2, "rm: ", 4rm: ) = 4
write(2, "cannot remove '/tmp/psko'", 25cannot remove '/tmp/psko') = 25
newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=1433, ...}, AT_EMPTY_PATH) = 0
mmap(NULL, 1433, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf7f9c000
close(3)= 0
write(2, ": Directory not empty", 21: Directory not empty)   = 21
write(2, "\n", 1
)   = 1
lseek(0, 0, SEEK_CUR)   = -1 ESPIPE (Illegal seek)
close(0)= 0
close(1)= 0
close(2)= 0
exit_group(1)   = ?
+++ exited with 1 +++
-- >8 --

Can you spot a rmdir(2) equivalent? I can't! So why does it lie and say
that it tried to remove it?

Also, the directory /isn't nonempty/! Bug c:
-- >8 --
$ rmdir -v /tmp/psko/; echo $?
rmdir: removing directory, '/tmp/psko/'
0
-- >8 --
And it's not there! Because, shockingly, there's nothing stopping you
from removing it! So why on /earth/ is rm failing to prompt, failing to
try to remove it, then lying that it had and failed with an obviously
false errno?

The same applies to just plain rm -d /tmp/psko (no -i)
(except for bug a).

All three bugs are POSIX violations
(a   : 202x/D2.1  : XCU, rm, DESCRIPTION, 3.,
 b, c: 202x/D2.1, 2008: XCU, rm, DESCRIPTION, 4.),
but more importantly render coreutils rm not fit for purpose.

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

Versions of packages coreutils depends on:
ii  libacl1  2.2.53-10
ii  libattr1 1:2.4.48-6
ii  libc62.31-13+deb11u3
ii  libgmp10 2:6.2.1+dfsg-1+deb11u1
ii  libselinux1  3.1-3

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

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

2022-07-18 Thread Paul Gevers

Source: liburing
Version: 2.1-2
Severity: important
X-Debbugs-Cc: br...@ubuntu.com

Dear Guillem,

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.

Paul

Bug#1014080: zutty: crashes on startup

2022-07-18 Thread Ricardo Mones

Hi David,

On Thu, 07 Jul 2022 08:47:45 -0300
David Bremner  wrote:

> Ricardo Mones  writes:
> 
> >
> > Indeed, seems something specific, had never seen a similar error. A list
> > of questions which I think would be useful to know before forwarding this
> > upstream:
[…]
> >  • Are compute shaders supported? (glxinfo | grep ARB_compute_shader)  
> 
> That seems to be the problem, nothing found. According to the xorg page
> 
>  https://www.x.org/wiki/RadeonFeature/
> 
> the hardware does not support compute shaders? Or at least they write
> "N/A".
> 
> I'm not sure you'll get much sympathy upstream, but IMHO the error
> message could be improved in any case.

Agreed, as currently is pretty obscure, IMHO.

Could you build zutty on your system with the attached patch and check if it
improves somehow?

thanks in advance,
-- 
 Ricardo Mones
 http://people.debian.org/~mones
 «You think Oedipus had a problem -- Adam was Eve's mother.»
diff --git a/src/charvdev.cc b/src/charvdev.cc
index 7eb1979..4620292 100644
--- a/src/charvdev.cc
+++ b/src/charvdev.cc
@@ -396,6 +396,7 @@ namespace zutty
   : px (fontpk->getPx ())
   , py (fontpk->getPy ())
{
+  checkExtensions ();
   createShaders ();
 
   /*
@@ -638,6 +639,20 @@ namespace zutty
 
// private methods
 
+   void
+   CharVdev::checkExtensions ()
+   {
+const GLubyte* what = glGetString(GL_EXTENSIONS);
+char* p = strtok ((char *) what, " ");
+while (p) {
+if (strstr (p, "compute") != NULL)
+return;
+p = strtok (nullptr, " ");
+}
+logE << "sorry, your OpenGL doesn't have compute shaders\n" << std::endl;
+exit (1);
+   }
+
void
CharVdev::createShaders ()
{
diff --git a/src/charvdev.h b/src/charvdev.h
index ae94fc4..2135407 100644
--- a/src/charvdev.h
+++ b/src/charvdev.h
@@ -133,6 +133,7 @@ namespace zutty
 
   Cell * cells = nullptr; // valid pointer if mapped, else nullptr
 
+  void checkExtensions ();
   void createShaders ();
};
 


pgplV_ENWgvga.pgp
Description: Firma digital OpenPGP

Bug#1015271: python3-libfdt: package is only build for python3.10, not 3.9

2022-07-18 Thread Agathe Porte

Package: python3-libfdt
Version: 1.6.1-2+b1
Severity: important
X-Debbugs-Cc: deb...@microjoe.org

Control: -1 blocks 1012369

Dear Maintainer,

The python3-libfdt package is currently only built against the
python3-dev Build-Dependency:

```
$ ls /usr/lib/python3/dist-packages/_libfdt*
/usr/lib/python3/dist-packages/_libfdt.cpython-310-x86_64-linux-gnu.so
```

This means that python3-libfdt is currently:

- Available for python3.10
- Not available for python3.9

Most of the time we have two concurrent Python versions in Debian to
allow for smooth upgrades. This is why this package is no exception and
needs to be built for every supported Python version in Debian.

I have tried to provide a patch using `py3versions -s` and replacing
`python3-dev` with `python3-all-dev` without success. It seems that I am
not able to pass multiple Python versions to the Makefile.

The patch is attached as a starting point, but I will not mark the bug
with the patch attribute since this patch is not working and needs
refinement.

I think folks on #debian-python on OFTC will be happy to help if you
encounter the same struggle as I did and need to reach out.

Thanks in advance.

Agathe


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

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

Versions of packages python3-libfdt depends on:
ii  libc62.33-8
ii  python3  3.10.4-1+b1

python3-libfdt recommends no packages.

python3-libfdt suggests no packages.

-- no debconf information
diff --git a/debian/control b/debian/control
index 1d10fd8..c69f8b8 100644
--- a/debian/control
+++ b/debian/control
@@ -10,7 +10,7 @@ Build-Depends: debhelper-compat (= 13),
  bison,
  libyaml-dev,
  pkg-config,
- python3-dev,
+ python3-all-dev,
  python3-setuptools,
  python3-setuptools-scm,
  swig,
diff --git a/debian/rules b/debian/rules
index 8a32ccf..2be35f2 100755
--- a/debian/rules
+++ b/debian/rules
@@ -5,6 +5,8 @@
 # respect SOURCE_DATE_EPOCH.
 export FORCE_SOURCE_DATE=1

+export DH_VERBOSE=1
+
 export SETUPTOOLS_SCM_PRETEND_VERSION=$(DEB_VERSION_UPSTREAM)
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all

@@ -28,10 +30,14 @@ endif

 override_dh_auto_install:
NO_PYTHON=1 $(MAKE) install DESTDIR=$(CURDIR)/debian/tmp PREFIX=/usr 
LIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH)
-   $(MAKE) maybe_install_pylibfdt EXTRA_CFLAGS="$(EXTRA_CFLAGS)" 
PREFIX=$(CURDIR)/debian/tmp/usr
+   set -e; for py in $(shell py3versions -s) ; do \
+   $(MAKE) maybe_install_pylibfdt EXTRA_CFLAGS="$(EXTRA_CFLAGS)" \
+   PREFIX=$(CURDIR)/debian/tmp/usr \
+   PYTHON=$$py ; \
+   done

 override_dh_auto_clean:
dh_auto_clean
[ ! -f Documentation/Makefile ] || $(MAKE) -C Documentation clean
[ ! -d build ] || rm -rf build
-   [ ! -d pylibfdt/libfdt.egg-info/] || rm -rf pylibfdt/libfdt.egg-info/
+   [ ! -d pylibfdt/libfdt.egg-info/ ] || rm -rf pylibfdt/libfdt.egg-info/

Bug#825317: Dzień dobry,

2022-07-18 Thread Albert Doe

 Dzień dobry,
Cieszę się, że mogę się z Państwem skontaktować w sprawie pozyskania
funduszy mojego zmarłego klienta, z którym macie to samo nazwisko i
obywatelstwo, który został wam przekazany jako jego najbliżsi krewni.
Skontaktuj się ze mną po więcej szczegółów, a dojdziemy do porozumienia w
sprawie legalności i uzyskania podstawy.
Dziękuję
Adwokat Albert Doe.

Bug#910261: New 0.2 release

2022-07-18 Thread Andre Heider


Woot, just shy of 4 years later and this can finally be closed :)

Bug#1015270: transition: nodejs

2022-07-18 Thread Jérémy Lal

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi,

nodejs 18.6.0 will soon be the active version of nodejs:
https://nodejs.org/en/about/releases/

I rebuilt and checked all reverse-build-deps of libnode-dev/nodejs,
and dealt with most of the regressions, or opened bugs proposing a solution.

Thanks,
Jérémy


Ben file:

title = "nodejs";
is_affected = .depends ~ /\b(libnode93)\b/ | .depends ~ /\b(libnode108)\b/;
is_good = .depends ~ /\b(libnode108)\b/;
is_bad = .depends ~ /\b(libnode93)\b/;

Bug#1015269: ITP: gnome-shell-extension-runcat -- desktop icon for showing CPU usage with cats

2022-07-18 Thread Shannon

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-gtk-gn...@lists.debian.org
Owner: duckydre...@gmail.com

Package Name: gnome-shell-extension-runcat
Version: 18
Upstream Author: Sergei Kolesnikov
License: GPL-3
Programming Lang: javascript

Description:desktop icon for showing CPU usage with cats
 RunCat provides a key-frame animation to the GNOME Shell top bar.
 Animation speed changes depending on CPU usage.


Other Info
--
This library will be maintained by the Debian GNOME team. Packaging is at
https://salsa.debian.org/gnome-team/shell-extensions/gnome-shell-extension-runcat/

Thanks,
Shannon Brady

Bug#1015268: olm: jasmine tests fail with nodejs 18

2022-07-18 Thread Jérémy Lal

Source: olm
Version: 3.2.11~dfsg-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

nodejs 18 exposes `global.fetch` API which makes some code
believe it is sitting in a real browser.

olm test fails because of that.
A workaround is to invoke it with

NODE_OPTIONS="--no-experimental-fetch" jasmine --config=test/jasmine.json

Jérémy

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

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

Bug#1015267: ITP: qtile -- A full-featured, hackable tiling window manager written and configured in Python

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

* Package name: qtile
  Version : 0.21.0
  Upstream Author : Aldo Cortesi
* URL : https://www.qtile.org/
* License : MIT
  Programming Lang: Python
  Description : A full-featured, hackable tiling window manager written and
configured in Python

Simple, small and extensible. It's easy to write your own layouts, widgets and
commands.  Runs as an X11 WM or a Wayland compositor.  Command shell that
allows all aspects of Qtile to be managed and inspected.  Complete remote
scriptability - write scripts to set up workspaces, manipulate windows, update
status bar widgets and more.  Qtile's remote scriptability makes it one of the
most thoroughly unit-tested window managers around.

I plan to maintain this under the auspices of the Python Team.

Bug#1014851: x86: Document new hardening options

2022-07-18 Thread Ben Hutchings

Here's a patch for the documentation.  This is a combination of the
omitted parts of the 3 upstream commits that touched it.

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained
by stupidity.
From: Ben Hutchings 
Date: Mon, 18 Jul 2022 15:50:38 +0200
Subject: x86: Document new hardening options
Origin: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=39d944c4237e5d35e28a2668d3b9a2e0f6f7bd01
Origin: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5d928740a533cd9e78673fad7ea86d20b2142277
Origin: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=58a4e292e8507a2968bfd2b10631ba95d5440c97

Changes to the docs from "x86: Add
-mharden-sls=[none|all|return|indirect-branch]", "x86: Add
-mindirect-branch-cs-prefix", and "x86: Rename
-harden-sls=indirect-branch to -harden-sls=indirect-jmp".
---
diff -u a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1409,7 +1409,8 @@
 -mstack-protector-guard-symbol=@var{symbol} @gol
 -mgeneral-regs-only  -mcall-ms2sysv-xlogues @gol
 -mindirect-branch=@var{choice}  -mfunction-return=@var{choice} @gol
--mindirect-branch-register -mneeded}
+-mindirect-branch-register -mharden-sls=@var{choice} @gol
+-mindirect-branch-cs-prefix -mneeded}
 
 @emph{x86 Windows Options}
 @gccoptlist{-mconsole  -mcygwin  -mno-cygwin  -mdll @gol
@@ -31724,6 +31725,21 @@
 @opindex mindirect-branch-register
 Force indirect call and jump via register.
 
+@item -mharden-sls=@var{choice}
+@opindex mharden-sls
+Generate code to mitigate against straight line speculation (SLS) with
+@var{choice}.  The default is @samp{none} which disables all SLS
+hardening.  @samp{return} enables SLS hardening for function returns.
+@samp{indirect-jmp} enables SLS hardening for indirect jumps.
+@samp{all} enables all SLS hardening.
+
+@item -mindirect-branch-cs-prefix
+@opindex mindirect-branch-cs-prefix
+Add CS prefix to call and jmp to indirect thunk with branch target in
+r8-r15 registers so that the call and jmp instruction length is 6 bytes
+to allow them to be replaced with @samp{lfence; call *%r8-r15} or
+@samp{lfence; jmp *%r8-r15} at run-time.
+
 @end table
 
 These @samp{-m} switches are supported in addition to the above


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

Bug#1015266: talkd: Issues in man pages

2022-07-18 Thread Helge Kreutzmann

Package: talkd
Severity: minor
Tags: patch l10n
X-Debbugs-CC: Mario Blättermann 

Dear talkd maintainer,
the manpage-l10n project maintains a large number of translations of
man pages both from a large variety of sources (including talkd) as
well for a large variety of target languages.

During their work translators notice different possible issues in the
original (english) man pages. Sometimes this is a straightforward
typo, sometimes a hard to read sentence, sometimes this is a
convention not held up and sometimes we simply do not understand the
original.

We use several distributions as sources and update regularly (at
least every 2 month). This means we are fairly recent (some
distributions like archlinux also update frequently) but might miss
the latest upstream version once in a while, so the error might be
already fixed. We apologize and ask you to close the issue immediately
if this should be the case, but given the huge volume of projects and
the very limited number of volunteers we are not able to double check
each and every issue.

Secondly we translators see the manpages in the neutral po format,
i.e. converted and harmonized, but not the original source (be it man,
groff, xml or other). So we cannot provide a true patch (where
possible), but only an approximation which you need to convert into
your source format.

Finally the issues I'm reporting have accumulated over time and are
not always discovered by me, so sometimes my description of the
problem my be a bit limited - do not hesitate to ask so we can clarify
them.

I'm now reporting the errors for your project. If future reports
should use another channel, please let me know. I initially used the 
e-mail adress net...@ftp.uk.linux.org as stated in the README file but 
this address no longer works as the homepage 
http://www.hcs.harvard.edu/~dholland/computers/netkit.html
no longer works. So kindly forward this to upstream.

Man page: in.ntalkd.8.po
Issue:E<.Nm Talkd> → E<.Nm>

"E<.Nm Talkd> is the server that notifies a user that someone else wants to "
"initiate a conversation.  It acts a repository of invitations, responding to "
"requests by clients wishing to rendezvous to hold a conversation.  In normal "
"operation, a client, the caller, initiates a rendezvous by sending a E<.Tn "
"CTL_MSG> to the server of type E<.Tn LOOK_UP> (see E<.Aq Pa protocols/talkd."
"h>).  This causes the server to search its invitation tables to check if an "
"invitation currently exists for the caller (to speak to the callee specified "
"in the message).  If the lookup fails, the caller then sends an E<.Tn "
"ANNOUNCE> message causing the server to broadcast an announcement on the "
"callee's login ports requesting contact.  When the callee responds, the "
"local server uses the recorded invitation to respond with the appropriate "
"rendezvous address and the caller and callee client programs establish a "
"stream connection through which the conversation takes place."

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1008730: abseil: Please update to latest upstream version

2022-07-18 Thread Benjamin Barenblat

Quick update – googletest 1.12 is in sid, and I’m working now to package
Abseil 20220623.

Bug#1015263: libidn2-0: Depends sgml-base

2022-07-18 Thread Thorsten Glaser

Package: libidn2-0
Version: 2.3.3-1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

A new dependency on sgml-base was introduced to the shared library
package, and it’s not documented in the changelog. This raises red
flags.


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

Kernel: Linux 5.10.0-10-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages libidn2-0 depends on:
ii  libc6  2.33-8
ii  libunistring2  1.0-1
ii  sgml-base  1.30

libidn2-0 recommends no packages.

libidn2-0 suggests no packages.

-- no debconf information

Bug#1015261: at: Errors in man pages

2022-07-18 Thread Helge Kreutzmann

Package: at
Severity: minor
Tags: patch l10n
X-Debbugs-CC: mario.blaetterm...@gmail.com

Dear at maintainer,
the manpage-l10n project maintains a large number of translations of
man pages both from a large variety of sources (including at) as
well for a large variety of target languages.

During their work translators notice different possible issues in the
original (english) man pages. Sometimes this is a straightforward
typo, sometimes a hard to read sentence, sometimes this is a
convention not held up and sometimes we simply do not understand the
original.

We use several distributions as sources and update regularly (at
least every 2 month). This means we are fairly recent (some
distributions like archlinux also update frequently) but might miss
the latest upstream version once in a while, so the error might be
already fixed. We apologize and ask you to close the issue immediately
if this should be the case, but given the huge volume of projects and
the very limited number of volunteers we are not able to double check
each and every issue.

Secondly we translators see the manpages in the neutral po format,
i.e. converted and harmonized, but not the original source (be it man,
groff, xml or other). So we cannot provide a true patch (where
possible), but only an approximation which you need to convert into
your source format.

Finally the issues I'm reporting have accumulated over time and are
not always discovered by me, so sometimes my description of the
problem my be a bit limited - do not hesitate to ask so we can clarify
them.

I'm now reporting the errors for your project. If future reports
should use another channel, please let me know.

Man page: atrun.8
Issue: B → B(1)

"B runs jobs queued by B. It is a shell script invoking B with the I<-s> option, and is provided for backward compatibility "
"with older installations."

--
Dr. Helge Kreutzmann deb...@helgefjell.de
Dipl.-Phys. http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
Help keep free software "libre": http://www.ffii.de/

signature.asc
Description: PGP signature

Bug#1011572: ITA: toilet -- display large colourful characters in text mode

retitle -1 ITA: toilet -- display large colourful characters in text mode
thanks

Bug#1015260: nqc: Get "Inappropriate ioctl for device" when trying to "nqc -firmware firm0332.lgo"

2022-07-18 Thread Sietse Achterop

Package: nqc
Version: 3.1.r6-7
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: s.achte...@rug.nl

Compiling works fine, but code cannot be downloaded to the RCX 2.0 via the 
device /dev/usb/legousbtower0.
stty also gives:
  stty: /dev/usb/legousbtower0: Inappropriate ioctl for device


-- System Information:
Debian Release: 11.4
  APT prefers stable
  APT policy: (990, 'stable'), (600, 'unstable'), (500, 'stable-security'), 
(400, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages nqc depends on:
ii  libc62.33-8
ii  libgcc-s1 [libgcc1]  10.2.1-6
ii  libstdc++6   10.2.1-6

nqc recommends no packages.

nqc suggests no packages.

-- no debconf information

Bug#1014996: [Pkg-rust-maintainers] Bug#1014996: librust-curl-sys-dev: has build loop with librust-curl-dev that causes rebuild delay when building against local debian source

2022-07-18 Thread Fabian Grünbichler

On July 18, 2022 4:22 pm, Daniel Kahn Gillmor wrote:
> Hi Fabian--
> 
> On Mon 2022-07-18 14:50:50 +0200, Fabian Grünbichler wrote:
>> note that the rerun line upstream refers to the vendored copy of the 
>> curl library which is contained as a git submodule (and directory, in 
>> the published .crate file) - to pick up any changes made to the 
>> submodule during development.
>>
>> we do (obviously ;)) remove that directory in Debian[0], which then 
>> makes the reference to 'curl' point to the 'curl' crate.
> 
> Thanks for this explanation!  I didn't realize that the string "curl"
> would change its semantics in the context the deletion of the
> submodule/directory, but it makes sense now that you've explained it.

you made me take a closer look - what I wrote above is actually not 
quite true at all. if I replace the rerun-if-changed to point to another 
path that doesn't exist (e.g., 'foobar' instead of 'curl'), the same 
behaviour is obversable. so it's a 'rerun-if-changed' stanza pointing at 
a path that doesn't exist at all that is the problem - if we had 
replaced the curl dir with an empty one instead of replacing it 
altogether it would have worked without the patch ;) and indeed, a 
simple `mkdir /usr/share/cargo/registry/curl-sys-0.4.49/curl` also fixes 
the spurious rebuild.

>> but, we also patch out the println[1]. seems like that fixed version
>> never got uploaded though - but that would likely fix it.
> 
> that would be great.  if i have time to do more work on debcargo in the
> nearterm, i'll probably start by finalizing the -2 of curl-sys, but if
> it takes me ~1 week to get to it, i'll just let you go forward with it
> as part of your cargo/debcargo work.
> 
>> note that I am currently working on upgrading cargo/debcargo which will 
>> also entail updating curl-sys and curl, so if you want to wait for that 
>> (ETA ~1 week) instead of uploading the prepared -2 that should also fix 
>> it in due course, but I am happy to rebase on top of a finalized -2 
>> version as well :)
> 
> ok, thanks for doing this work, i really appreciate it!

it's sorely needed - I've already started hitting crates where our 
outdated cargo version (used by debcargo) makes packaging current 
versions of crates impossible, since their crates.io index entries are 
not understood, falling back to the last 'v1' one:

 https://github.com/rust-lang/crates.io-index/blob/master/li/bg/libgit2-sys

only versions up to 0.13.2+1.4.2 are visible to our cargo/debcargo 
(which is especially fun given that it's in the dep tree of the current 
cargo version ;)).

thankfully this only affects ~400 crates at the moment, of which only 
libgit2-sys, phf and rpassword are packaged in Debian.. but it will 
become more widespread as more upstream devs make use of the new cargo 
features.

Bug#1000755: stellarium: Dialog boxes cause segfault crash under Wayland

2022-07-18 Thread Gard Spreemann


Bernhard Übelacker  writes:

> Control: tags -1 - moreinfo unreproducible
>
>
> Hello Gard,
> tried to reproduce on real hardware with an older Intel integrated
> graphics, but It still did not crash for me, sorry.
>
> One thing to test might be to add another user and check if the crash
> happens there too.
>
> Otherwise the maintainer might be able to reproduce.

Very strange! Thanks for checking. I'll see if I can find any more
clues.


 Best,
 Gard
 


signature.asc
Description: PGP signature

Bug#1011734: ruby-certificate-authority: FTBFS: ERROR: Test "ruby3.0" failed: Failure/Error: expect(@cert_with_extensions.extensions["authorityKeyIdentifier"]).to eq(expected_authorityKeyIdentifier)

2022-07-18 Thread Nick Rosbrook

Package: ruby-certificate-authority
Followup-For: Bug #1011734
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch
Control: tags -1 patch

Hi,

This was caused by a string format change in openssl >= 3.0. I created
an upstream issue with more information [1].

In Ubuntu, we applied this patch to resolve the FTBFS:

  * debian/patches/0004-remove-keyid-prefix-from-test-string.patch: 
Remove 'keyid:' prefix from test string to fix build with openssl >= 3.0.
(LP: #1981458)

Thanks,
Nick

[1] https://github.com/cchandler/certificate_authority/issues/62
diff -Nru 
ruby-certificate-authority-1.0.0/debian/patches/0004-remove-keyid-prefix-from-test-string.patch
 
ruby-certificate-authority-1.0.0/debian/patches/0004-remove-keyid-prefix-from-test-string.patch
--- 
ruby-certificate-authority-1.0.0/debian/patches/0004-remove-keyid-prefix-from-test-string.patch
 1969-12-31 19:00:00.0 -0500
+++ 
ruby-certificate-authority-1.0.0/debian/patches/0004-remove-keyid-prefix-from-test-string.patch
 2022-07-12 11:00:53.0 -0400
@@ -0,0 +1,21 @@
+Description: Remove 'keyid:' prefix from x509 v3 authorityKeyIdentifier test
+ This test case does a simple check for the expected authorityKeyIdentifier 
value
+ on a certificate, which includes a 'keyid:' prefix. This prefix was removed in
+ OpenSSL 3.0, which causes this test case to fail. Just remove the prefix from 
the
+ expected string to fix the test.
+Author: Nick Rosbrook 
+Bug: https://github.com/cchandler/certificate_authority/issues/62
+Bug-Ubuntu: 
https://bugs.launchpad.net/ubuntu/+source/ruby-certificate-authority/+bug/1981458
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011734
+Last-Update: 2022-07-12
+--- a/spec/units/certificate_spec.rb
 b/spec/units/certificate_spec.rb
+@@ -423,7 +423,7 @@
+   expect(@cert_with_extensions.extensions["subjectKeyIdentifier"]).to 
eq(expected_subjectKeyIdentifier)
+ 
+   expected_authorityKeyIdentifier = 
CertificateAuthority::Extensions::AuthorityKeyIdentifier.new
+-  expected_authorityKeyIdentifier.identifier = 
"keyid:4C:58:CB:25:F0:41:4F:52:F4:28:C8:81:43:9B:A6:A8:A0:E6:92:E5"
++  expected_authorityKeyIdentifier.identifier = 
"4C:58:CB:25:F0:41:4F:52:F4:28:C8:81:43:9B:A6:A8:A0:E6:92:E5"
+   expect(@cert_with_extensions.extensions["authorityKeyIdentifier"]).to 
eq(expected_authorityKeyIdentifier)
+ 
+   expected_authorityInfoAccess = 
CertificateAuthority::Extensions::AuthorityInfoAccess.new
diff -Nru ruby-certificate-authority-1.0.0/debian/patches/series 
ruby-certificate-authority-1.0.0/debian/patches/series
--- ruby-certificate-authority-1.0.0/debian/patches/series  2022-02-20 
17:24:24.0 -0500
+++ ruby-certificate-authority-1.0.0/debian/patches/series  2022-07-12 
11:00:53.0 -0400
@@ -1,3 +1,4 @@
 0001-Build-a-string-config-for-OpenSSL-Config-as-opposed-.patch
 0002-gemspec-don-t-use-git-to-get-list-of-files.patch
 0003-gemspec-don-t-load-file-from-lib-explicitly.patch
+0004-remove-keyid-prefix-from-test-string.patch

Bug#797363: doesn't occur with current version

2022-07-18 Thread cacatoes

This bug doesn't occur with currently packaged vcmi versions, buying a 
spell book works fine.
Tested on vcmi 0.99+dfsg+git20190113.f06c8a87-2 (bullseye) and on 
bookworm.

So I think this bug can be closed.

---

As a side note, I wasn't able to load the save game attached to this bug 
report.


Establishing connection...
Found endpoints:
0:127.0.0.1:3030
Trying connection to 127.0.0.1:3030(0)
Established connection with VCMI 0.99 GITDIR-NOTFOUND (server). UUID: 
6766579e-beca-4b08-a8db-6713f6356198
vcmiserver: /usr/include/boost/optional/optional.hpp:1212: 
boost::optional::reference_type boost::optional::get() [with T = 
boost::filesystem::path; boost::optional::reference_type = 
boost::filesystem::path&]: Assertion `this->is_initialized()' failed.

Aborted
Lost connection to server, ending listening thread!
read: End of file
Error: server failed to close correctly or crashed!
Check /home/fab/.cache/vcmi/server_log.txt for more info

(not exactly more info in server_log.txt)

Bug#1014435: libvirt-daemon-system-systemd: virbr0 default fails to connect

2022-07-18 Thread Andrea Bolognani

On Tue, Jul 05, 2022 at 08:06:44PM -0500, Tim McConnell wrote:
> Package: libvirt-daemon-system-systemd
> Version: 8.4.0-1
> Severity: grave
> Justification: renders package unusable

This doesn't feel right. According to [1], "grave" means that the bug

  makes the package in question unusable or mostly so, or causes data
  loss, or introduces a security hole allowing access to the accounts
  of users who use the package

The fact that a single libvirt feature (the default network) has been
reported as not working by a single person (I just tested it on my
machine and it seems okay) doesn't match the description of the
severity IMO. I'll lower it to "important", which indicates

  a bug which has a major effect on the usability of a package,
  without rendering it completely unusable to everyone

and seems to describe the actual impact much more accurately.

> Virbr0 won't connect to external network.It did once, I was able to install
> Debian from a net install image. Now it tells me the Virtual Machine can't
> connect.

Please be more specific. Does the VM fail to start? If so, what is
the exact error message? Or does the VM boot up, but the guest OS is
unable to connect to the Internet? Can the guest OS ping the host, or
does that not work either? If you try performing another
installation, does that work?

[1] https://www.debian.org/Bugs/Developer#severities
-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.

signature.asc
Description: PGP signature

Bug#1004508: ocrad: autopkgtest regression: undefined reference to `png_g*

2022-07-18 Thread Nick Rosbrook

In order to avoid future problems with compiling `ocradcheck`, would
it be better to build an additional binary package (ocradcheck or
ocrad-test) which can be installed during autopkgtest? This seems less
error-prone.

-Nick

Bug#1014996: [Pkg-rust-maintainers] Bug#1014996: librust-curl-sys-dev: has build loop with librust-curl-dev that causes rebuild delay when building against local debian source

2022-07-18 Thread Daniel Kahn Gillmor

Hi Fabian--

On Mon 2022-07-18 14:50:50 +0200, Fabian Grünbichler wrote:
> note that the rerun line upstream refers to the vendored copy of the 
> curl library which is contained as a git submodule (and directory, in 
> the published .crate file) - to pick up any changes made to the 
> submodule during development.
>
> we do (obviously ;)) remove that directory in Debian[0], which then 
> makes the reference to 'curl' point to the 'curl' crate.

Thanks for this explanation!  I didn't realize that the string "curl"
would change its semantics in the context the deletion of the
submodule/directory, but it makes sense now that you've explained it.

> but, we also patch out the println[1]. seems like that fixed version
> never got uploaded though - but that would likely fix it.

that would be great.  if i have time to do more work on debcargo in the
nearterm, i'll probably start by finalizing the -2 of curl-sys, but if
it takes me ~1 week to get to it, i'll just let you go forward with it
as part of your cargo/debcargo work.

> note that I am currently working on upgrading cargo/debcargo which will 
> also entail updating curl-sys and curl, so if you want to wait for that 
> (ETA ~1 week) instead of uploading the prepared -2 that should also fix 
> it in due course, but I am happy to rebase on top of a finalized -2 
> version as well :)

ok, thanks for doing this work, i really appreciate it!

--dkg

signature.asc
Description: PGP signature

Bug#1013920: [Pkg-rust-maintainers] Bug#1013920: closed by Sylvestre Ledru (Re: Bug#1013920: rust-all: Debian violating Rust Trademark (as serious a situation as "iceweasel"))

ah!

some fascinating news (from another discussion) pulled up the fact
that ADA converted to a Certification Mark, back in 1987

http://archive.adaic.com/pol-hist/policy/trademrk.txt

In order to be a validated Ada compiler, a compiler must pass an extensive
suite of programs called the Ada Compiler Validation Capability (ACVC).  The
AJPO has adopted a certification mark to show that a compiler has passed the
ACVC and is a validated compiler or a compiler derived from a validated base
compiler as defined in the Ada Compiler Validations Procedures and Guidelines
(version 1.1 of which was issued in January 1987).  The certification mark may
also be used on certain literature accompanying or documenting a validated
compiler.  Information concerning the proper use of the certification mark was
distributed to interested parties during the summer of 1987.

*that* is what the Rust Foundation *should* be doing.
messing about prohibiting patching is going to end in tears.

if they instead state, "You must run the Test Suite (unmodified, as provided by
us), and it the results are a 100% pass then you're free and clear to distribute
without limitation [and use the word "rust"] in the distributed package"

then *that* would solve all of the problems.

unfortunately, as i said in comment #40
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920#40

if the Rust Foundation tries right now to convert the Trademark into a
Certification Mark it will be DENIED because they are selling product
(hats, T-shirts) and a Certification Mark Holder cannot compete with
its Licensees.

if they stop selling T-shirts and Merchandise and give assurances to
the Trademark Office that they will not do so then they should be ok
to convert to a Certification Mark.

l.

Bug#1014909: rust-cbindgen 0.23.0-1~deb10u2 flagged for acceptance

2022-07-18 Thread Adam D Barratt

package release.debian.org
tags 1014909 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: rust-cbindgen
Version: 0.23.0-1~deb10u2

Explanation: fix build failure due to too old timestamps

Bug#1015259: calibre: preferences link no longer available

2022-07-18 Thread Gary Koskenmaki

Package: calibre
Version: 6.1.0+dfsg-1
Severity: normal
X-Debbugs-Cc: garyk1...@charter.net

Dear Maintainer,

Wanted to edit Calibre preferences and attempted to find link fo them.  No such
link exists any more.


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

Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages calibre depends on:
ii  calibre-bin6.1.0+dfsg-1
ii  dpkg   1.21.9
ii  fonts-liberation2  2.1.5-1
ii  libjpeg-turbo-progs1:2.1.2-1
ii  libjxr-tools   1.2~git20170615.f752187-5
ii  libqt6webenginecore6-bin   6.2.4+dfsg-10
ii  optipng0.7.7-2
ii  poppler-utils  22.02.0-3
ii  python33.10.5-1
ii  python3-apsw   3.36.0-r1-2+b1
ii  python3-bs44.11.1-1
ii  python3-chardet4.0.0-2
ii  python3-chm0.8.6-3+b1
ii  python3-css-parser 1.0.7-1
ii  python3-cssselect  1.1.0+ds-3
ii  python3-dateutil   2.8.1-6
ii  python3-feedparser 6.0.8-2
ii  python3-html2text  2020.1.16-2
ii  python3-html5-parser   0.4.10-5
ii  python3-html5lib   1.1-3
ii  python3-jeepney0.8.0-1
ii  python3-lxml   4.9.1-1
ii  python3-markdown   3.4.1-1
ii  python3-mechanize  1:0.4.8+pypi-3
ii  python3-msgpack1.0.3-1
ii  python3-netifaces  0.11.0-1+b1
ii  python3-pil9.2.0-1
ii  python3-pkg-resources  59.6.0-1.2
ii  python3-py7zr  0.11.3+dfsg-4
ii  python3-pycryptodome   3.11.0+dfsg1-3
ii  python3-pygments   2.12.0+dfsg-2
ii  python3-pyparsing  3.0.7-2
ii  python3-pyqt6  6.3.1-1
ii  python3-pyqt6.qtsvg6.3.1-1
ii  python3-pyqt6.qtwebengine  6.3.1-1
ii  python3-pyqt6.sip  13.4.0-1
ii  python3-regex  0.1.2020-1
ii  python3-routes 2.5.1-3
ii  python3-speechd0.11.1-3
ii  python3-zeroconf   0.38.7-1
ii  python3.10 3.10.5-1
ii  qt6-qpa-plugins6.2.4+dfsg-10
ii  xdg-utils  1.1.3-4.1

Versions of packages calibre recommends:
ii  python3-dnspython  2.2.1-2
pn  python3-ipython
ii  udisks22.9.4-1+devuan1

Versions of packages calibre suggests:
ii  python3-openssl   21.0.0-1
pn  python3-unrardll  
pn  qt6-wayland   

-- no debconf information

Bug#1015191: vice: FTBFS against ffmpeg 5

2022-07-18 Thread GCS

Control: severity -1 important

Hi Andreas,

On Sun, Jul 17, 2022 at 2:39 PM Andreas Beckmann  wrote:
> vice FTBFS against ffmpeg 5:
 Indeed. Upstream says there will be no support for two FFmpeg
releases. Until 4.3.x+ is alive and well, there will be no 5.y
support.
Thus already uploaded a vice update which disables FFmpeg support, not
to fail with 5.y until then. I let this bug report open until the
support lands for that.

Regards,
Laszlo/GCS

Bug#1015258: fzf: Modify build to set FZF version

2022-07-18 Thread Laurent Cheylus

Package: fzf
Version: 0.30.0-1+b1
Severity: normal

Dear Maintainer,

with the latest version of FZF (v0.30.0), the version returned by the binary is 
:

$ fzf --version
0.30 (devel)

fzf Makefile uses git commands to determine the version and the revision
information for fzf --version, see
https://github.com/junegunn/fzf/blob/master/BUILD.md and 
https://github.com/junegunn/fzf/blob/master/Makefile#L20

Please, could you modify the Debian build of this package to use FZF_VERSION
and FZF_REVISION variables in Makefile to set the internal version ?

$ FZF_VERSION=0.30.0 FZF_REVISION=tarball make
(...)
$ fzf --version
0.30.0 (tarball)


Thanks for your work on Debian packaging of fzf tool.
regards, Laurent

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

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

-- no debconf information

Bug#1015257: misleading package description

2022-07-18 Thread Steinar H. Gunderson

Package: libsvtav1-dev
Version: 0.9.1+dfsg-1
Severity: minor

Hi,

libsvtav1-dev writes:

  This package provides the development files for libsvtav1dec and libsvtav1enc.

However, it does not. It provides _some_ development files (the header
files), but not _the_ development files; in fact, it is pretty useless
on its own. It took me a long time before I figured out that the package
that I wanted was libsvtav1enc-dev.

Suggested rewording:

  This package provides the header files shared between libsvtav1enc-dev
  and libsvtav1dec-dev.

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

Kernel: Linux 5.17.5 (SMP w/56 CPU threads; PREEMPT)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NO:en_US:en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#1015206: O: binutils-riscv64-unknown-elf -- GNU assembler, linker and binary utilities for RISC-V processors

2022-07-18 Thread Bo YU


Tags: newcomer

Hi, Vagrant!

Thank you report it. I am very interested in maintaining this package
in a *long* term. But given my current abilities now, Please do QA 
upload according to your original plan. Certainly if you need my

assistant please let me know:)

Bo
--
Best Regards,



signature.asc
Description: PGP signature

Bug#1015256: Revert EMU128 back to SCALAR

2022-07-18 Thread Mathieu Malaterre

Package: libhwy0
Version; 0.17.0-1

In version 0.17.0 baseline was changed from SCALAR to EMU128. While
some work can be done to make the test suite build and run on gcc-11
it appears that EMU128 code is making gcc-12 generates wrong-code at
-02 on some 32bits system (i386/armel were tested):

* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322

Please revert back to SCALAR for now. Upstream reference:

* https://github.com/google/highway/issues/635#issuecomment-1180260374

Bug#1014996: [Pkg-rust-maintainers] Bug#1014996: librust-curl-sys-dev: has build loop with librust-curl-dev that causes rebuild delay when building against local debian source

2022-07-18 Thread Fabian Grünbichler

On July 15, 2022 10:59 pm, Daniel Kahn Gillmor wrote:
> Package: librust-curl-sys-dev
> Version: 0.4.49-1
> Control: affects -1 src:rust-debcargo librust-curl-dev
> 
> There's a build loop between librust-curl-dev and librust-curl-sys-dev
> in debian: when i "cargo build" anything that depends on the curl crate,
> it causes a rebuild of curl-sys, which in turn causes a rebuild of curl
> on the next build.  So "cargo build" always has to do more building than
> it should.
> 
> [.. reproducing instructions omitted..]
> 
> OTOH, if i remove the .cargo/config.toml (so that it pulls from
> crates.io directly) i do not see the rebuild happening for either curl
> or curl-sys.  subsequent "cargo build" operations just terminate
> cleanly, even if i pin the versions of curl and curl-sys in Cargo.toml.
> 
> This is likely related to "cargo:rerun-if-changed=curl" in build.rs for
> librust-curl-sys-dev (see
> https://github.com/alexcrichton/curl-rust/pull/407) but I don't
> understand it.
> 
> But when i asked on ##rust on libera's IRC service, folks there not
> using debian were unable to reproduce this problem.

note that the rerun line upstream refers to the vendored copy of the 
curl library which is contained as a git submodule (and directory, in 
the published .crate file) - to pick up any changes made to the 
submodule during development.

we do (obviously ;)) remove that directory in Debian[0], which then 
makes the reference to 'curl' point to the 'curl' crate. but, we also 
patch out the println[1]. seems like that fixed version never got 
uploaded though - but that would likely fix it.

note that I am currently working on upgrading cargo/debcargo which will 
also entail updating curl-sys and curl, so if you want to wait for that 
(ETA ~1 week) instead of uploading the prepared -2 that should also fix 
it in due course, but I am happy to rebase on top of a finalized -2 
version as well :)

0: 
https://salsa.debian.org/rust-team/debcargo-conf/-/blob/master/src/curl-sys/debian/debcargo.toml#L3
1: 
https://salsa.debian.org/rust-team/debcargo-conf/-/blob/master/src/curl-sys/debian/patches/avoid-spurious-rebuilds.patch

Bug#1015254: transition: opencascade

2022-07-18 Thread Tobias Frost

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Control: block 1014964 by -1

Hi Release team,

opencascade has a new release with bumps so name to 7.6 The transition tracker 
[1]
correctly picked it up already after the upload to experimental.

[1] https://release.debian.org/transitions/html/auto-opencascade.html

This bug is also to help me keeping track of the transistion as it will need at 
least
one sourceful upload of netgen.

building the reverse depenencies, results are:

Dependency level 2

freecad (sid only)✔  (RC buggy due to other issues)
kicad ✔
netgen✘  (fixed upstream, #1014964))

With a local built of netgen (patched to just make it compile, not preserving 
functionality),
I could get also Dependency level 3 to be built:

gmsh_4.5.6+ds1   ✔   (BDs on netgen)

Dependency Level 4:
 deal.ii_9.1.1-9  ✔ (BDs on gmsh)


I'm not sure if I can come up with a proper patch for netgen, but I will try.

Cheers,

-- 
tobi

Bug#1015253: haskell-misfortune FTBFS: No instance for (mtl-2.2.2:Control.Monad.Reader.Class.MonadReader g0 IO) arising from a use of ‘sample’

Source: haskell-misfortune
Version: 0.1.1.2-10
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-misfortune=sid

...

src/Data/Fortune.hs:238:10: error:
• No instance for (mtl-2.2.2:Control.Monad.Reader.Class.MonadReader
 g0 IO)
arising from a use of ‘sample’
• In a stmt of a 'do' block: i <- sample (uniform 0 (n - 1))
  In the expression:
do f <- sample file
   n <- getNumFortunes f
   i <- sample (uniform 0 (n - 1))
   T.unpack <$> getFortune f i
  In an equation for ‘randomFortuneFromRandomFile’:
  randomFortuneFromRandomFile file
= do f <- sample file
 n <- getNumFortunes f
 i <- sample (uniform 0 (n - 1))
 
|
238 | i <- sample (uniform 0 (n-1))
|  
 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 709
Debian::Debhelper::Buildsystem::Haskell::Recipes::haddock_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1015252: haskell-hmatrix FTBFS: Couldn't match expected type ‘Int’ with actual type ‘CSR -> Int’

Source: haskell-hmatrix
Version: 0.20.0.0-1
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-hmatrix=sid

...
src/Internal/Sparse.hs:125:24: error:
• Couldn't match expected type ‘Int’ with actual type ‘CSR -> Int’
• Probable cause: ‘nRows’ is applied to too few arguments
  In the ‘nRows’ field of a record
  In the expression: SparseR {..}
  In an equation for ‘fromCSR’:
  fromCSR csr
= SparseR {..}
where
gmCSR @ CSR {..} = csr
nRows = csrNRows
nCols = csrNCols
|
125 | fromCSR csr = SparseR {..}
|^^
 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 709
Debian::Debhelper::Buildsystem::Haskell::Recipes::haddock_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1015251: haskell-formatting FTBFS: Ambiguous occurrence ‘quotRemInteger’

Source: haskell-formatting
Version: 6.3.7-2
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-formatting=sid

...
src/Data/Text/Format/Int.hs:121:30: error:
Ambiguous occurrence ‘quotRemInteger’
It could refer to
   either ‘GHC.Num.quotRemInteger’,
  imported from ‘GHC.Num’ at src/Data/Text/Format/Int.hs:27:17-30
   or ‘GHC.Integer.GMP.Internals.quotRemInteger’,
  imported from ‘GHC.Integer.GMP.Internals’ at 
src/Data/Text/Format/Int.hs:34:1-32
  (and originally defined in ‘GHC.Integer’)
|
121 | splith p (n:ns) = case n `quotRemInteger` p of
|  

src/Data/Text/Format/Int.hs:126:30: error:
Ambiguous occurrence ‘quotRemInteger’
It could refer to
   either ‘GHC.Num.quotRemInteger’,
  imported from ‘GHC.Num’ at src/Data/Text/Format/Int.hs:27:17-30
   or ‘GHC.Integer.GMP.Internals.quotRemInteger’,
  imported from ‘GHC.Integer.GMP.Internals’ at 
src/Data/Text/Format/Int.hs:34:1-32
  (and originally defined in ‘GHC.Integer’)
|
126 | splitb p (n:ns) = case n `quotRemInteger` p of
|  

src/Data/Text/Format/Int.hs:144:26: error:
Ambiguous occurrence ‘quotRemInteger’
It could refer to
   either ‘GHC.Num.quotRemInteger’,
  imported from ‘GHC.Num’ at src/Data/Text/Format/Int.hs:27:17-30
   or ‘GHC.Integer.GMP.Internals.quotRemInteger’,
  imported from ‘GHC.Integer.GMP.Internals’ at 
src/Data/Text/Format/Int.hs:34:1-32
  (and originally defined in ‘GHC.Integer’)
|
144 | putH (n:ns) = case n `quotRemInteger` maxInt of
|  

src/Data/Text/Format/Int.hs:152:26: error:
Ambiguous occurrence ‘quotRemInteger’
It could refer to
   either ‘GHC.Num.quotRemInteger’,
  imported from ‘GHC.Num’ at src/Data/Text/Format/Int.hs:27:17-30
   or ‘GHC.Integer.GMP.Internals.quotRemInteger’,
  imported from ‘GHC.Integer.GMP.Internals’ at 
src/Data/Text/Format/Int.hs:34:1-32
  (and originally defined in ‘GHC.Integer’)
|
152 | putB (n:ns) = case n `quotRemInteger` maxInt of
|  
 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"haddock", "--builddir=dist-ghc", "--with-haddock=/usr/bin/haddock", 
"--with-ghc=ghc", "--verbose=2", "--html", "--hoogle", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 709
Debian::Debhelper::Buildsystem::Haskell::Recipes::haddock_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1015242: gcc Trademark violation on the horizon

2022-07-18 Thread Matthias Klose


Control: severity -1 wishlist

if it's on the horizon, it's clearly not release-critical now.

Bug#918334: sqlite3: please support parallel builds

2022-07-18 Thread GCS

Hi Helmut,

On Sat, Jan 5, 2019 at 10:24 AM Helmut Grohne  wrote:
> Given that sqlite3 compiles its whole source as one translation unit,
> the optimizations tend to take longer and longer and sqlite3's build
> time increases. Therefore I ask for supporting parallel builds. In my
> tests, we can achieve a 40% reduction in build time.
 Thanks for your work. As noted previously, upstream doesn't recommend
the individual source files. Of course, in Debian we use sources like
those that exist in the VCS repository for easy tracking of changes.
Upstream even says using / creating an amalgamation is how SQLite3
should be compiled to let the compiler choose the best optimization
techniques. That way the execution step can be increased by 5% to 10%
[1]. Compilation time however happens only once.
Once I already used parallel building and as I remember, not every
time but often enough it just broke. Can do testing locally and if
someone can help (donate) me old / small architectures - RISC-V for
example -, then I plan to re-test parallel compilation.

Regards,
Laszlo/GCS
[1] https://www.sqlite.org/howtocompile.html

Bug#1015250: q2-feature-table: Conflict with biom-format 2.1.12

2022-07-18 Thread Andreas Tille

Package: q2-feature-table
Severity: important
Tags: upstream

Hi,

as reported upstream[1] and can be seen in Salsa-CI[2] or ci.debian.net[3]
q2-feature-table fails its test with python3-biom-format version 2.1.12.

Kind regards

 Andreas.

[1] https://github.com/qiime2/q2-types/issues/279
[2] https://salsa.debian.org/med-team/q2-types/-/jobs/2936679
[3] 
https://ci.debian.net/data/autopkgtest/testing/amd64/q/q2-feature-table/23789186/log.gz


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

Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
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 q2-feature-table depends on:
ii  python3  3.10.4-1+b1
pn  python3-biom-format  
pn  python3-h5py 
pn  python3-ipywidgets   
ii  python3-numpy1:1.21.5-1
pn  python3-seaborn  
pn  python3-skbio
pn  q2-types 
pn  q2templates  
pn  qiime

q2-feature-table recommends no packages.

q2-feature-table suggests no packages.

Bug#1015249: haskell-boomerang FTBFS: Encountered missing or private dependencies: template-haskell <2.17

Source: haskell-boomerang
Version: 1.4.6-2
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=haskell-boomerang=sid

...
hlibrary.setup: Encountered missing or private dependencies:
template-haskell <2.17

 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 622
Debian::Debhelper::Buildsystem::Haskell::Recipes::configure_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: build-ghc-stamp] Error 25

Bug#1015248: RFS: scid/1:4.7.4+dfsg1-1 -- chess database with play and training functionality

2022-07-18 Thread Jose G. López

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: scid
   Version : 1:4.7.4+dfsg1-1
   Upstream Author : Fulvio Benini 
 * URL : http://scid.sf.net
 * License : GPL-2.0, Tklib
 * Vcs : https://salsa.debian.org/josgalo-guest/scid
   Section : games

The source builds the following binary packages:

  scid - chess database with play and training functionality
  scid-data - data files for scid, the chess database application

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/scid/scid_4.7.4+dfsg1-1.dsc

Changes since the last upload:

 scid (1:4.7.4+dfsg1-1) unstable; urgency=medium
 .
   * New upstream version.
   * debian/control:
 - Bump to Standards-Version 4.6.1. No changes required.
   * debain/copyright:
 - Update upstream and debian package copyright years.
   * debian/patches:
 - 02_uninitialized-memory-access.patch. Remove patch applied upstream.
 - 01_Makefile.conf.diff. Refresh patch.
   * debian/rules:
 - Remove 'OPTIMIZE' option as it gets the same value from default.

P.D: I know that three days ago a new upstream version (4.8) came out but I
couldn't test it and I prefer to upload this tested version
before packing the most recent.

Thanks and regards,


pgpfjUoFjfoGh.pgp
Description: PGP signature

Bug#1015247: RFS: phalanx/25-1 -- Chess playing program

2022-07-18 Thread Jose G. López

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: phalanx
   Version : 25-1
   Upstream Author : Dusan Dobes
 * URL : https://sourceforge.net/projects/phalanx
 * License : GPL-2.0+, public-domain
 * Vcs : https://salsa.debian.org/josgalo-guest/phalanx
   Section : games

The source builds the following binary packages:

  phalanx - Chess playing program

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/p/phalanx/phalanx_25-1.dsc

Changes since the last upload:

 phalanx (25-1) unstable; urgency=medium
 .
   * New upstream version.
   * debian/compat: Remove file.
   * debian/copyright: Update copyright year and my e-mail.
   * debian/control:
 - Bump to Standards-Version 4.6.1. No changes required.
 - Change maintainer's e-mail.
 - Set Vcs* fields to Salsa.
 - Upgrade to debhelper compat 13.
   * debian/install: Book files should install to phalanx dir as they're
 only usable with the program.
   * debian/menu: Remove as menu system is deprecated (Policy >= 3.9.8).
   * debian/patches:
 - 03_makefile_DEFINES.diff: Refresh and renamed it to 01_makefile.patch
 - 04_PG_setboard_command.diff: Remove, applied upstream.
 - 05_PG_version-string.diff,
   10_hardening-string-literal_search.diff,
   12_hardening-string-literal_io.diff,
   14_hardening-string-literal_book.diff,
   16_hardening-pointer-sign_bcreate: Remove, not needed anymore.
 - 16_hardening-unused-but-set_endgame,
   17_bcreate,
   20_fix_linker_problem: Not applicable.
 - 02_dereference_pointer.patch: Add to fix not dereferenced pointer.
   (Closes: #1001069). Thanks to Michael Soyka.
   * debian/rules:
 - Add override_dh_auto_install to overwrite install dir.
 - Remove unnecessary dh argument.
   * debian/watch:
 - Upgrade to version 4 and handle latest version (XXV).

Thanks and regards,


pgpeqBFgGnfAY.pgp
Description: PGP signature

Bug#1015246: zeal: please make the build reproducible

2022-07-18 Thread Chris Lamb

Source: zeal
Version: 1:0.6.1+git20220714+6fee23-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
zeal could not be built reproducibly.

This is because it adds a "development release" date to an XML file:

│ │ │ │ ├── ./usr/share/metainfo/org.zealdocs.zeal.appdata.xml
│ │ │ │ │ @@ -23,15 +23,15 @@
│ │ │ │ │https://i.imgur.com/qBkZduS.png
│ │ │ │ │  
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │  zeal.desktop
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │ -
│ │ │ │ │ +

Patch attached that simply drops this line.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.patch   1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/reproducible-build.patch   2022-07-18 11:47:48.221289879 
+0100
@@ -0,0 +1,18 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2022-07-18
+
+--- zeal-0.6.1+git20220714+6fee23.orig/CMakeLists.txt
 zeal-0.6.1+git20220714+6fee23/CMakeLists.txt
+@@ -44,11 +44,6 @@ endif()
+ 
+ set(ZEAL_VERSION_FULL "${Zeal_VERSION}${ZEAL_VERSION_SUFFIX}")
+ 
+-# For development builds insert an extra release in the AppStream metadata.
+-if(NOT RELEASE_VERSION)
+-string(TIMESTAMP ZEAL_APPSTREAM_DEV_RELEASE "\n")
+-endif()
+-
+ # A custom target to print the full version.
+ # Usage: cmake --build build --target zeal_version
+ add_custom_target(zeal_version
--- a/debian/patches/series 2022-07-18 11:36:13.167186089 +0100
--- b/debian/patches/series 2022-07-18 11:47:47.389286997 +0100
@@ -1,2 +1,3 @@
 disable-check-for-update.patch
 #system-cpp-httplib.patch # only needed with the next upstream release
+reproducible-build.patch

Bug#1015245: libshumate: please make the build reproducible

2022-07-18 Thread Chris Lamb

Source: libshumate
Version: 1.0.0~alpha.1-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
libshumate could not be built reproducibly.

This is because the generated enumerations file embeds the full build
path via @filename@:

-/* enumerations from 
"/build/1st/libshumate-1.0.0~alpha.1/obj-x86_64-linux-gnu/../shumate/shumate-file-cache.h"
 */
+/* enumerations from 
"/build/2/libshumate-1.0.0~alpha.1/2nd/obj-x86_64-linux-gnu/../shumate/shumate-file-cache.h"
 */

Patch attached that uses @basename@.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.patch   1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/reproducible-build.patch   2022-07-18 11:40:28.347866061 
+0100
@@ -0,0 +1,26 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2022-07-18
+
+--- libshumate-1.0.0~alpha.1.orig/shumate/shumate-enum-types.c.in
 libshumate-1.0.0~alpha.1/shumate/shumate-enum-types.c.in
+@@ -3,7 +3,7 @@
+ /*** END file-header ***/
+ 
+ /*** BEGIN file-production ***/
+-/* enumerations from "@filename@" */
++/* enumerations from "@basename@" */
+ /*** END file-production ***/
+ 
+ /*** BEGIN value-header ***/
+--- libshumate-1.0.0~alpha.1.orig/shumate/shumate-enum-types.h.in
 libshumate-1.0.0~alpha.1/shumate/shumate-enum-types.h.in
+@@ -9,7 +9,7 @@ G_BEGIN_DECLS
+ 
+ /*** BEGIN file-production ***/
+ 
+-/* enumerations from "@filename@" */
++/* enumerations from "@basename@" */
+ /*** END file-production ***/
+ 
+ /*** BEGIN value-header ***/
--- a/debian/patches/series 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/series 2022-07-18 11:40:27.299862984 +0100
@@ -0,0 +1 @@
+reproducible-build.patch

Bug#1013275: toil: FTBFS with Python 3.10 only

2022-07-18 Thread Graham Inggs

Control: severity -1 serious

The python3.10-only transition has now started.

Bug#1014193: segfault with libssl3

2022-07-18 Thread Klaus Ethgen

Am Mo den 18. Jul 2022 um 10:50 schrieb Bernhard Übelacker:
> --- encfs-1.9.5.orig/encfs/SSL_Cipher.cpp
> +++ encfs-1.9.5/encfs/SSL_Cipher.cpp
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -355,6 +356,9 @@ inline unsigned char *IVData(const std::
>  void initKey(const std::shared_ptr , const EVP_CIPHER 
> *_blockCipher,
>   const EVP_CIPHER *_streamCipher, int _keySize) {
>Lock lock(key->mutex);
> +
> +  OSSL_PROVIDER_load(NULL, "legacy");
> +
>// initialize the cipher context once so that we don't have to do it for
>// every block..
>EVP_EncryptInit_ex(key->block_enc, _blockCipher, nullptr, nullptr, 
> nullptr);

If I read the documentation correct, that will ONLY load the legacy
provider. So you have to also load the default provider explicitly.

Gruß
   Klaus
-- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C


signature.asc
Description: PGP signature

Bug#1014929: kea-dhcp4-server: uses predictable filenames in /tmp

2022-07-18 Thread Paride Legovini

Control: forwarded -1 https://gitlab.isc.org/isc-projects/kea/-/issues/2495

I forwarded this bug report upstream, as ideally I'd like not to diverge
from the upstream defaults. If upstream isn't responsive on this issue
I'll patch the default config files to put the sockets under /run/kea
and warn about this via d/NEWS or use debconf offer an optional conf
file migration option, applying a regexp to the conf files at postist.

Paride

Bug#1014193: segfault with libssl3

2022-07-18 Thread Klaus Ethgen

Hi Bernhard,

Am Mo den 18. Jul 2022 um 10:50 schrieb Bernhard Übelacker:
> And upstream seems to track this in following issue:
>   https://github.com/vgough/encfs/issues/651
> There is also another workaround by modifying the openssl
> configuration if the package rebuild is not wanted.

I read that and tried the config setting in /etc/ssl/openssl.cnf. But it
didn't work for me. I get the same segfault.

I had to also add `providers = provider_sect` in openssl_init section.
to let it work.

> --- encfs-1.9.5.orig/encfs/SSL_Cipher.cpp
> +++ encfs-1.9.5/encfs/SSL_Cipher.cpp
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -355,6 +356,9 @@ inline unsigned char *IVData(const std::
>  void initKey(const std::shared_ptr , const EVP_CIPHER 
> *_blockCipher,
>   const EVP_CIPHER *_streamCipher, int _keySize) {
>Lock lock(key->mutex);
> +
> +  OSSL_PROVIDER_load(NULL, "legacy");
> +
>// initialize the cipher context once so that we don't have to do it for
>// every block..
>EVP_EncryptInit_ex(key->block_enc, _blockCipher, nullptr, nullptr, 
> nullptr);

If that fixes the bug, it would be great to be applied.

However, I concider that a bug in openssl as it would need random
changes in many other software, I believe.

Gruß
   Klaus
-- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C


signature.asc
Description: PGP signature

Bug#1013920: [Pkg-rust-maintainers] Bug#1013920: closed by Sylvestre Ledru (Re: Bug#1013920: rust-all: Debian violating Rust Trademark (as serious a situation as "iceweasel"))

On Mon, Jul 18, 2022 at 11:06 AM Sylvestre Ledru  wrote:
>
> This bug is fixed.

i can see that you believe that to be true, otherwise you would
not have closed it.

what i am upset by is that you did not consider my opinion or
insight to be worth consulting.

i am deeply offended by that.

l.

Bug#1015243: buster-pu: package commons-daemon/1.0.15-8

2022-07-18 Thread Chris Hofstaedtler

* Chris Hofstaedtler  [220718 12:02]:
> [ Tests ]
> 
> I manually tested the built package on oldoldstable amd64.
 
Sorry, I got confused with the names. This should have read
oldstable (buster).

Chris

Bug#1015244: bullseye-pu: package commons-daemon/1.0.15-8

2022-07-18 Thread Chris Hofstaedtler

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-java-maintain...@lists.alioth.debian.org

[ Reason ]

Running a java daemon using jsvc and the JVM from (old)stable does not
work. It appears no java programs inside Debian still use jsvc,
otherwise people would have noticed earlier. This is bug #935336,
and I want to fix it in oldstable/buster (#1015243) and stable/bullseye
(this bug).

[ Impact ]

jsvc just does not work except if on upgrades one keeps the JVM from
oldoldstable (openjdk 8).

[ Tests ]

I manually tested the built package on bullseye amd64.

[ Risks ]

The workarounds are either to keep openjdk 8 if available, or use
another mechanism to start services. Some third party packages want to
use jsvc, so there is no good workaround for them.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in stable/bullseye
  [x] the issue is verified as fixed in unstable

[ Changes ]

Add (fixed) patch to find libjvm.so in the locations OpenJDK uses in
Version 11 and newer. The same patch is in unstable, and works on
oldstable, stable and in unstable/testing.

[ Other info ]

I only discovered the problem when recently updating a machine running
buster(!) and third-party software for managing wireless hotspots of a
somewhat popular brand. The third-party packages have "interesting"
dependencies, and only recently are usable with OpenJDK 11. I imagine
other users will also run into this problem.

[ debdiff ]

diff -Nru commons-daemon-1.0.15/debian/changelog 
commons-daemon-1.0.15/debian/changelog
--- commons-daemon-1.0.15/debian/changelog  2017-03-02 12:51:51.0 
+
+++ commons-daemon-1.0.15/debian/changelog  2022-07-16 00:03:17.0 
+
@@ -1,3 +1,10 @@
+commons-daemon (1.0.15-8+deb11u1) bullseye; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply patch from unstable to fix JVM detection. (Closes: #935336)
+
+ -- Chris Hofstaedtler   Sat, 16 Jul 2022 00:03:17 +
+
 commons-daemon (1.0.15-8) unstable; urgency=medium
 
   * Team upload.
diff -Nru commons-daemon-1.0.15/debian/patches/debian-935336.patch 
commons-daemon-1.0.15/debian/patches/debian-935336.patch
--- commons-daemon-1.0.15/debian/patches/debian-935336.patch1970-01-01 
00:00:00.0 +
+++ commons-daemon-1.0.15/debian/patches/debian-935336.patch2022-07-16 
00:03:00.0 +
@@ -0,0 +1,26 @@
+Description: locate more recent JVM (including OpenJDK)
+Author: Graeme Vetterlein ,
+Chris Hofstaedtler 
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935336
+Last-Update: 2022-07-09
+
+Index: commons-daemon-1.0.15/src/native/unix/native/location.c
+===
+--- commons-daemon-1.0.15.orig/src/native/unix/native/location.c
 commons-daemon-1.0.15/src/native/unix/native/location.c
+@@ -115,6 +115,7 @@ char *location_jvm_default[] = {
+ "$JAVA_HOME/jre/lib/libjvm.so",
+ "$JAVA_HOME/lib/classic/libjvm.so",
+ "$JAVA_HOME/lib/client/libjvm.so",
++"$JAVA_HOME/lib/server/libjvm.so",
+ "$JAVA_HOME/lib/libjvm.so",
+ "$JAVA_HOME/jre/bin/classic/libjvm.so",
+ "$JAVA_HOME/jre/bin/client/libjvm.so",
+@@ -149,6 +150,7 @@ char *location_jvm_configured[] = {
+ #elif defined(OS_LINUX) || defined(OS_SOLARIS) || defined(OS_BSD) || 
defined(OS_FREEBSD) || defined(OS_TRU64)
+ "$JAVA_HOME/jre/lib/" CPU "/$VM_NAME/libjvm.so",/* Sun JDK 1.3 */
+ "$JAVA_HOME/lib/" CPU "/$VM_NAME/libjvm.so",/* Sun JRE 1.3 */
++"$JAVA_HOME/lib/$VM_NAME/libjvm.so",
+ #elif defined(OS_HPUX)
+ "$JAVA_HOME/jre/lib/" CPU "/$VM_NAME/libjvm." SO_EXT,
+ "$JAVA_HOME/lib/" CPU "/$VM_NAME/libjvm." SO_EXT,
diff -Nru commons-daemon-1.0.15/debian/patches/series 
commons-daemon-1.0.15/debian/patches/series
--- commons-daemon-1.0.15/debian/patches/series 2017-03-02 12:51:51.0 
+
+++ commons-daemon-1.0.15/debian/patches/series 2022-07-16 00:03:10.0 
+
@@ -5,3 +5,4 @@
 mips_abi_n32_n64_support.diff
 arm64.diff
 ppc64el.diff
+debian-935336.patch

Bug#1013920: [Pkg-rust-maintainers] Bug#1013920: closed by Sylvestre Ledru (Re: Bug#1013920: rust-all: Debian violating Rust Trademark (as serious a situation as "iceweasel"))

2022-07-18 Thread Sylvestre Ledru


This bug is fixed. Please don't reopen it.
We are both now compliant with the DFSG and the Rust trademark.

I do understand that you feel differently but this worked well for years 
for Firefox and Thunderbird and

Debian derivatives. This isn't a different situation.

Regards,
Sylvestre


/
/

Le 18/07/2022 à 11:29, Luke Kenneth Casson Leighton a écrit :

reopen 1013920

sorry, Sylvestre, if you could possibly wait, on something this serious,
for a response as to whether the fix is valid, that will avoid me having
to spend my time reopening the issue or creating a second bugreport.

On Mon, Jul 18, 2022 at 10:21 AM Debian Bug Tracking System
  wrote:

This is an automatic notification regarding your Bug report
which was filed against the rust-all package:

#1013920: rust-all: Debian violating Rust Trademark (as serious a situation as 
"iceweasel")

It has been closed by Sylvestre Ledru.

___
Pkg-rust-maintainers mailing list
pkg-rust-maintain...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers

Bug#1015243: buster-pu: package commons-daemon/1.0.15-8

2022-07-18 Thread Chris Hofstaedtler

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-java-maintain...@lists.alioth.debian.org

[ Reason ]

Running a java daemon using jsvc and the JVM from (old)stable does not
work. It appears no java programs inside Debian still use jsvc,
otherwise people would have noticed earlier. This is bug #935336,
and I want to fix it in oldstable (this bug) and stable (to be filed).

[ Impact ]

jsvc just does not work except if on upgrades one keeps the JVM from
oldoldstable (openjdk 8).

[ Tests ]

I manually tested the built package on oldoldstable amd64.

[ Risks ]

The workarounds are either to keep openjdk 8 if available, or use
another mechanism to start services. Some third party packages want to
use jsvc, so there is no good workaround for them.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in oldstable
  [x] the issue is verified as fixed in unstable

[ Changes ]

Add (fixed) patch to find libjvm.so in the locations OpenJDK uses in
Version 11 and newer. The same patch is in unstable, and works on
oldstable, stable and in unstable/testing.

[ Other info ]

I only discovered the problem when recently updating a machine running
third-party software for managing wireless hotspots of a somewhat
popular brand. The third-party packages have "interesting" dependencies,
and only recently are usable with OpenJDK 11. I imagine other users will
also run into this problem.
I'm running the fixed jsvc_1.0.15-8+deb10u1_amd64.deb on that machine.

[ debdiff ]

diff -Nru commons-daemon-1.0.15/debian/changelog 
commons-daemon-1.0.15/debian/changelog
--- commons-daemon-1.0.15/debian/changelog  2017-03-02 12:51:51.0 
+
+++ commons-daemon-1.0.15/debian/changelog  2022-07-18 09:35:49.0 
+
@@ -1,3 +1,10 @@
+commons-daemon (1.0.15-8+deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply patch from unstable to fix JVM detection. (Closes: #935336)
+
+ -- Chris Hofstaedtler   Mon, 18 Jul 2022 09:35:49 +
+
 commons-daemon (1.0.15-8) unstable; urgency=medium
 
   * Team upload.
diff -Nru commons-daemon-1.0.15/debian/patches/debian-935336.patch 
commons-daemon-1.0.15/debian/patches/debian-935336.patch
--- commons-daemon-1.0.15/debian/patches/debian-935336.patch1970-01-01 
00:00:00.0 +
+++ commons-daemon-1.0.15/debian/patches/debian-935336.patch2022-07-16 
00:03:00.0 +
@@ -0,0 +1,26 @@
+Description: locate more recent JVM (including OpenJDK)
+Author: Graeme Vetterlein ,
+Chris Hofstaedtler 
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935336
+Last-Update: 2022-07-09
+
+Index: commons-daemon-1.0.15/src/native/unix/native/location.c
+===
+--- commons-daemon-1.0.15.orig/src/native/unix/native/location.c
 commons-daemon-1.0.15/src/native/unix/native/location.c
+@@ -115,6 +115,7 @@ char *location_jvm_default[] = {
+ "$JAVA_HOME/jre/lib/libjvm.so",
+ "$JAVA_HOME/lib/classic/libjvm.so",
+ "$JAVA_HOME/lib/client/libjvm.so",
++"$JAVA_HOME/lib/server/libjvm.so",
+ "$JAVA_HOME/lib/libjvm.so",
+ "$JAVA_HOME/jre/bin/classic/libjvm.so",
+ "$JAVA_HOME/jre/bin/client/libjvm.so",
+@@ -149,6 +150,7 @@ char *location_jvm_configured[] = {
+ #elif defined(OS_LINUX) || defined(OS_SOLARIS) || defined(OS_BSD) || 
defined(OS_FREEBSD) || defined(OS_TRU64)
+ "$JAVA_HOME/jre/lib/" CPU "/$VM_NAME/libjvm.so",/* Sun JDK 1.3 */
+ "$JAVA_HOME/lib/" CPU "/$VM_NAME/libjvm.so",/* Sun JRE 1.3 */
++"$JAVA_HOME/lib/$VM_NAME/libjvm.so",
+ #elif defined(OS_HPUX)
+ "$JAVA_HOME/jre/lib/" CPU "/$VM_NAME/libjvm." SO_EXT,
+ "$JAVA_HOME/lib/" CPU "/$VM_NAME/libjvm." SO_EXT,
diff -Nru commons-daemon-1.0.15/debian/patches/series 
commons-daemon-1.0.15/debian/patches/series
--- commons-daemon-1.0.15/debian/patches/series 2017-03-02 12:51:51.0 
+
+++ commons-daemon-1.0.15/debian/patches/series 2022-07-16 00:03:10.0 
+
@@ -5,3 +5,4 @@
 mips_abi_n32_n64_support.diff
 arm64.diff
 ppc64el.diff
+debian-935336.patch

Bug#970592: TypeError: a bytes-like object is required, not 'str

2022-07-18 Thread Daniel Baumann

close 970592 3.0.30-1
thanks

Hi,

I've tried to reproduce this but coudn't with current testing/unstable,
thus closing the bug.

Regards,
Daniel

Bug#1013920: closed by Sylvestre Ledru (Re: [Pkg-rust-maintainers] Bug#1013920: rust-all: Debian violating Rust Trademark (as serious a situation as "iceweasel"))

reopen 1013920

sorry, Sylvestre, if you could possibly wait, on something this serious,
for a response as to whether the fix is valid, that will avoid me having
to spend my time reopening the issue or creating a second bugreport.

On Mon, Jul 18, 2022 at 10:21 AM Debian Bug Tracking System
 wrote:
>
> This is an automatic notification regarding your Bug report
> which was filed against the rust-all package:
>
> #1013920: rust-all: Debian violating Rust Trademark (as serious a situation 
> as "iceweasel")
>
> It has been closed by Sylvestre Ledru .

Bug#1013920: [Pkg-rust-maintainers] Bug#1013920: rust-all: Debian violating Rust Trademark (as serious a situation as "iceweasel")

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Mon, Jul 18, 2022 at 10:16 AM Sylvestre Ledru  wrote:
>
> Thanks for bringing it to our attention, I have consulted with the Rust
> foundation, we have agreed a change, we think this change solves it.

ah! we may have just had some cross-over.

> See
> https://foundation.rust-lang.org/policies/logo-policy-and-media-guide/
> for the updated policy.

did you mean the sections "fixing local paths" (etc)?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920#60

no, that would not be sufficient.  it still violates DFSG (most of it).

there is also the issue that even placing a public copy of source
code on a git repository also constitutes "Distribution".

i gave some suggestions which would be much more reasonable
(and general) already, they may have been missed:

   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920#40

those much more general statements basically say

"we trust you not to do any damage under our name"

the new additions basically say:

"you're clearly too stupid to be trusted so we're going to
 lock out your rights"

it should therefore come as no surprise that trying to go in
that direction would directly conflict with everything that DFSG
strives towards.

l.

Bug#1013920: [Pkg-rust-maintainers] Bug#1013920: rust-all: Debian violating Rust Trademark (as serious a situation as "iceweasel")