Bug#1010576: akonadi-server: Akonadi/Kontact hangs after resuming from standby

[gis-w]

Exactly, but be careful with kill -9. I once broke my database with it such 
that mariadb would not even start anymore. I had to delete the entire directory 
and let akonadi recreate it from scratch.

Bug#1009188: closing

[alain]

like the solution is found , you can close this thread .


waiting for the time of the development and the publication in the 
distribution.



friendly ,

alain .

Bug#1009188: solution :

[alain]

here is  what alex pevzner found :


1) compile the git  version of ipp-usb :

https://github.com/OpenPrinting/ipp-usb


2) install the latest version of ipp-usb of the repositories

sudo apt install --reinstall ipp-usb


3) copy and add this quirk in  /usr/share/ipp-usb/quirks/HP.conf

[HP ENVY 5530 series]
  disable-fax = true


4) replace /usr/sbin/ipp-usb with the one you compiled .


5) tests .

all must be ok .

Bug#1008997: solution

[alain]

here is  what alex pevzner found :


1) compile the git  version of ipp-usb :

https://github.com/OpenPrinting/ipp-usb


2) install the latest version of ipp-usb of the repositories

sudo apt install --reinstall ipp-usb


3) copy and add this quirk in  /usr/share/ipp-usb/quirks/HP.conf

[HP ENVY 5530 series]
  disable-fax = true


4) replace /usr/sbin/ipp-usb with the one you compiled .


5) tests .

all must be ok .


you can close this thread .

Bug#1010682: sysvinit-core: let's default LANG to C.UTF-8

[Mark Hindley]

Hi,

On Sat, May 07, 2022 at 05:19:05AM +0200, Thorsten Glaser wrote:
> On Sat, 7 May 2022, Adam Borowski wrote:
> 
> > But, as glibc still considers unset locale to mean "C" rather than
> > "C.UTF-8", _something_ must set these variables.  Debian-installer does
> 
> There's talk to chage that in glibc-in-Debian at least.

[snip..]

> > As systemd does define LANG=C.UTF-8, I'm not hopeful the default will

Since we seem to agree glibc would be the best place to make this change and if
there is already talk about changing it there let's add our voice to that
discussion first?

Mark

Bug#1010686: golang-github-boltdb-bolt: ftbfs issue on riscv64 arch

[Bo YU]

Source: golang-github-boltdb-bolt
Version: 1.3.1-7
Severity: normal
Tags: ftbfs
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org, debian...@lists.debian.go

Dear Maintainer,

In fact the reported bug does not match as the title describes, but
it was found while trying to fix ftbfs issue on riscv64.

Basically these packages that depend on golang-github-boltdb-bolt
have ftbfs issue on riscv64(maybe include other arch):

```
vimer@dev:~$  build-rdeps golang-github-boltdb-bolt-dev
[sudo] password for vimer:
WARNING: dose-extra >= 4.0 is not installed. Falling back to old unreliable 
behaviour.
Reverse Build-depends in main:
--

nomad
golang-github-blevesearch-bleve
influxdb
snapd
vuls
golang-github-hashicorp-raft-boltdb
golang-github-micromdm-scep
```

Those packages list that have ftbfs issue on riscv64 is here:
https://udd.debian.org/cgi-bin/ftbfs.cgi?arch=riscv64

If learn more about golang-github-boltdb-bolt-bolt, we will notice the upstream 
is
public archive: https://github.com/boltdb/bolt but the other repo that forked 
from
it is active:  https://github.com/etcd-io/bbolt. And the bblot has supported 
many arch

I am doing to ask the relative package's upstream to swtich to bblot but i do 
not
this is enough. Can the go-*-bolt package swtich to bblot also? If do so,
it will fix many ftbfs issues as early as possible.

BR,
Bo

Bug#1010685: dpkg-buildflags: Please enable -ftrivial-auto-var-init=zero

[Kees Cook]

Package: dpkg-dev
Version: 1.21.7
Severity: normal

Please add "-ftrivial-auto-var-init=zero" for GCC 12 (which is the first
release of GCC to provide this flag).

It goes well with the other important security flaw mitigation flags
already enabled in Debian:
https://wiki.debian.org/Hardening#dpkg-buildflags

While many variables are initialized (due to -Wuninitialized), there is
a blind spot for variables passed by reference, padding, and cases where
-Wuninitialized just fails to track it. Universally wiping the variables
eliminates nearly the entire class of uninitialized stack variable use
(https://cwe.mitre.org/data/definitions/457.html) with nearly no overhead
(e.g. any duplicate assignments will already be squashed during dead
store elimination, etc).

-- Package-specific info:

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

Kernel: Linux 5.13.0-37-generic (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/dash
Init: sysvinit (via /sbin/init)

Versions of packages dpkg-dev depends on:
ii  binutils  2.38-3
ii  bzip2 1.0.8-5
ii  libdpkg-perl  1.21.7
ii  make  4.3-4.1
ii  patch 2.7.6-7
ii  perl  5.34.0-4
ii  tar   1.34+dfsg-1
ii  xz-utils  5.2.5-2.1

Versions of packages dpkg-dev recommends:
pn  build-essential  
ii  fakeroot 1.28-1
ii  gcc [c-compiler] 4:11.2.0-2
ii  gcc-10 [c-compiler]  10.3.0-15
ii  gcc-11 [c-compiler]  11.2.0-20
ii  gcc-4.2 [c-compiler] 4.2.4-6
ii  gcc-4.4 [c-compiler] 4.4.7-8
ii  gcc-4.5 [c-compiler] 4.5.4-1
ii  gcc-4.6 [c-compiler] 4.6.4-7
ii  gcc-4.7 [c-compiler] 4.7.4-3
ii  gcc-4.8 [c-compiler] 4.8.5-4
ii  gcc-4.9 [c-compiler] 4.9.4-2
ii  gcc-5 [c-compiler]   5.5.0-12
ii  gcc-6 [c-compiler]   6.5.0-2
ii  gcc-9 [c-compiler]   9.4.0-5
pn  gnupg
ii  gpgv 2.2.34-1
ii  libalgorithm-merge-perl  0.08-3

Versions of packages dpkg-dev suggests:
ii  debian-keyring  2021.12.24

-- no debconf information

Bug#1010682: sysvinit-core: let's default LANG to C.UTF-8

[Thorsten Glaser]

On Sat, 7 May 2022, Adam Borowski wrote:

> As of Bookworm, ancient encodings are no longer supported.  There are

?

> But, as glibc still considers unset locale to mean "C" rather than
> "C.UTF-8", _something_ must set these variables.  Debian-installer does

There's talk to chage that in glibc-in-Debian at least.

> that, but bare debootstrap does not, and neither do some other ways of
> installing Debian.  Baring explicit configuration by the user, the
> locale will remain unset.

Debian officially only supports d-i though, but getting C as default
is not a bad thing compared to other available options.

> Thus, let's add putenv("LANG=C.UTF-8") to pid 1; further startup will
> usually overwrite that with whatever values are configured -- possibly
> "C" to go back to the old state.

Not exactly: if explicitly unconfigured to keep C, it’ll change.

It will change in a compatibl-ish way, sure (which is why I proposed
C.UTF-8 to be created about nine years ago in the first place), but
things can break (tr -dc '[[:alpha:]]' changes meaning, for example).

> As systemd does define LANG=C.UTF-8, I'm not hopeful the default will

They do? Ugh. Of course they do whatever suits Poettering’s laptop.

I’m personally not convinced in favour of this switch, but, yeah,
let’s do this for inner consistency in Debian.

I’d put it into /etc/rc, not the init binary, though, but I see that
such a thing doesn’t exist… and I guess it would not handle whatever
is run from inittab, so… probably, yeah.

I was just writing about calling init scripts, but my cleanenv script
has been using C.UTF-8 in LC_ALL for 15 months already, too… so, okay.

Not making much sense this late in the night? IF so, sorry.

gn8,
//mirabilos
-- 
Yes, I hate users and I want them to suffer.
-- Marco d'Itri on gmane.linux.debian.devel.general

Bug#1010684: Boot parameter to specify directory of filesystem.squashfs (other than /boot)

[Ben Westover]

Package: live-boot
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: kwestover...@gmail.com

Hello,

I have made a multiboot USB using SYSLINUX. For distributions that use
dracut, I can specify the rd.live.dir boot parameter to change the
directory that it looks for filesystem.squashfs in. There are similar
options for other live systems, like Arch Linux's archisobasedir.
This is useful to me because I can put each distribution's filesystem in
its own folder.

I was not able to find such a parameter for Debian, which limits me to
only one Debian-based distribution on the drive because the filesystem
squashfs must be in /boot, and there can only be one.
If a simple livedir= option could be added to specify the directory, it
would help me tremendously.

Thanks,
--
Ben Westover


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

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

Versions of packages live-boot depends on:
pn  live-boot-initramfs-tools | live-boot-backend  

Versions of packages live-boot recommends:
ii  live-boot-doc  1:20220505
pn  live-tools 
ii  rsync  3.2.4-1
pn  uuid-runtime   

Versions of packages live-boot suggests:
ii  cryptsetup  2:2.4.3-1
pn  curlftpfs   
pn  httpfs2 
ii  wget1.21.3-1+b1


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010683: No boot option to increase DHCP timeout

[Ben Westover]

Package: live-boot
Severity: normal
Tags: upstream
X-Debbugs-Cc: kwestover...@gmail.com

Hello,

All of my ethernet connections go through an old Cisco switch I have. It
takes just over 30 seconds to assign an IP address, and this can cause
problems with programs that completely fail if DHCP isn't quick enough.
For example, I always have to retry network autoconfiguration in the
Debian Installer because it gives up before the switch is done.

I have PXE boot set up for easy netbooting of many different operating
systems, and it works very well, except for the fact that I need to add
boot parameters such as rd.net.timeout.dhcp=40 (dracut example) to give
the switch more time to set up the network before failing to boot.

I recently discovered the excellent work done here in the Debian Live
images, and decided to add one to my PXE by booting its kernel and
initrd with the fetch= boot parameter for the filesystem.squashfs.
Upon attempting to boot it, everything worked fine until it tried to
initialize the network, giving up after 15 seconds. I did a lot of
research to see how I could increase the timeout, but couldn't find any
useful information.

It would be helpful if a boot parameter could be added that sets the
length of time dhclient waits until giving up. Another solution would be
one that sets a number of retries.

Thanks,
--
Ben Westover


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

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

Versions of packages live-boot depends on:
pn  live-boot-initramfs-tools | live-boot-backend  

Versions of packages live-boot recommends:
ii  live-boot-doc  1:20220505
pn  live-tools 
ii  rsync  3.2.4-1
pn  uuid-runtime   

Versions of packages live-boot suggests:
ii  cryptsetup  2:2.4.3-1
pn  curlftpfs   
pn  httpfs2 
ii  wget1.21.3-1+b1


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008858: [pkg-lua-devel] Bug#1008858: Please support s390x

[Thomas Ward]

This may sound annoying or a counterintuitive argument, but have we 
considered that this has sat for years without ANY activity from LuaJIT 
upstream that they may not care to?  Could we do any kind of testing on 
our side in terms of a 'distribution-level' patch to support S390X?  
Because it does make sense that this hasn't been handled for 4+ years 
that upstream has no intention to support this.



Thomas


On Sun, 3 Apr 2022 00:49:53 +0200 =?UTF-8?B?SsOpcsOpbXkgTGFs?= 
 wrote:
> On Sun, Apr 3, 2022 at 12:21 AM Thomas Ward  
wrote:

>
> > Source: luajit
> > Severity: wishlist
> >
> > Please support s390x if possible. NGINX's Lua module support depends on
> > libluajit exclusively now, and would need s390x support for proper 
support.

> >
>
> There is a PR for that
> https://github.com/LuaJIT/LuaJIT/pull/395
>
> however it still requires to be tested and reviewed.

Bug#1010682: sysvinit-core: let's default LANG to C.UTF-8

[Adam Borowski]

Package: sysvinit-core
Version: 3.03-1
Severity: wishlist
X-Debbugs-Cc: kilob...@angband.pl


As of Bookworm, ancient encodings are no longer supported.  There are
still vestiges of their support, and you can force generation of such
a locale, but more and more things break.  And I'd be glad if it's all
gone.  It's good if you can rely on the encoding being UTF-8.

But, as glibc still considers unset locale to mean "C" rather than
"C.UTF-8", _something_ must set these variables.  Debian-installer does
that, but bare debootstrap does not, and neither do some other ways of
installing Debian.  Baring explicit configuration by the user, the
locale will remain unset.

As systemd does define LANG=C.UTF-8, I'm not hopeful the default will
be handled in a better place like glibc.

Thus, let's add putenv("LANG=C.UTF-8") to pid 1; further startup will
usually overwrite that with whatever values are configured -- possibly
"C" to go back to the old state.

(I just had an example -- an ARM box whose install started from an
upstream image lacked the locale setting.)


Meow!
-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (490, 'testing'), (250, 'unstable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.17.0-1-arm64 (SMP w/6 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages sysvinit-core depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  initscripts3.03-1
ii  libc6  2.33-7
ii  libselinux13.3-1+b2
ii  mount  2.38-4
ii  sysv-rc3.03-1
ii  sysvinit-utils 3.03-1

Versions of packages sysvinit-core recommends:
pn  orphan-sysvinit-scripts  

Versions of packages sysvinit-core suggests:
pn  bootlogd  

-- debconf information:
  sysvinit/hurd-fix-inittab:

Bug#997851: Update on doas package status

[Scupake]

Hello,

A little update on this issue. I found out that I am not be able to
upload both packages into the Debian repositories since the two programs are
too similar to each other. However I can provide packages for slicer69/doas on
a git repo since the packaging for it is pretty much done.
I am sorry about not being able to include slicer69/doas in the Debian
repos.

-- 
Scupake :D
4737A2C0A769B53AE82F77922BD8BE5CDD5ADA16


signature.asc
Description: PGP signature

Bug#991761: ITP: swc -- A super-fast typescript / javascript compiler written in rust

[Jonas Smedegaard]

1.2.177 draft 1 needs embedding 197 crates (119 missing, 4 broken, 4 
incomplete, 61 outdated, 8 ahead); builds in ~30 minutes with a 2-core 
i5 CPU; not yet usable as it needs to link with node-napi-rs that is not 
yet packaged.

My plan now is to keep up with upstream code development, package 
dependencies (notably node-napi-rs), and encourage the Rust team to 
update/upgrade existing but unaligned crate packages.

You can help by building this draft package and try improve integration 
with draft packaging of node-napi-rs available at 
, and provide feedback 
here about that.

You can also help by joining the Rust team in Debian and help unbreak 
and upgrade packaged crates, and add more: 
https://salsa.debian.org/js-team/node-swc-core/-/blob/debian/latest/debian/TODO


Thanks,

 - Jonas

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

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

signature.asc
Description: signature

Bug#1010681: arqiver: wrong dependency

[Kacper Gutowski]

Package: arqiver
Version: 0.9.0-1+b1
Severity: normal

Currently arqiver depends on '7zip' but it makes no use of it at all. 
On the other hand it complains about '7z' command being missing when 
opening or creating 7z file unless 'p7zip-full' package that provides 
the 7z command is installed.


Either '7zip' dependency needs to be replaced with 'p7zip-full', or 
the package patched to use '7zz' command instead of '7z' (or, even 
better, make it work with either).


-k

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

Kernel: Linux 5.17.0-1-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.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 arqiver depends on:
ii  7zip  21.07+dfsg-4
ii  gzip  1.12-1
ii  libarchive-tools  3.6.0-1
ii  libc6 2.33-7
ii  libgcc-s1 12-20220428-1
ii  libqt5core5a  5.15.2+dfsg-16+b1
ii  libqt5gui55.15.2+dfsg-16+b1
ii  libqt5svg55.15.2-4
ii  libqt5widgets55.15.2+dfsg-16+b1
ii  libstdc++612-20220428-1

arqiver recommends no packages.

arqiver suggests no packages.

-- no debconf information

Bug#599309: mutt: Reply->Postpone->Recall loses message associations

[Kevin J. McCarthy]

On Thu, 30 Dec 2010 13:56:51 + Antonio Radici  wrote:

tag 599309 +confirmed upstream
thanks

Hi Toni,
thanks for your report, I will forward this issue upstream.


The threading issue was fixed upstream in commits

1) 3c44f482
   


2) 31bc8262
   


The second commit was released with Mutt 1.8.0.

This should set reply flag in parent *provided* you are still in the 
same mailbox when you recall the message.


If you believe this addresses the issue adequately, please feel free to 
close it.  Thank you.


signature.asc
Description: PGP signature

Bug#1010676: chromium-l10n: -l10n version behind chromium version in Sid

[Andres Salomon]

I think the buildd got stuck: 
https://buildd.debian.org/status/package.php?p=chromium


It finally built the arch:all package(s) 5 hours ago, so they should 
enter the archive soon. I noticed earlier that it had been building for 
2+ days, despite normally taking about 15 mins to build. :)


On 5/5/22 05:34, Sebastien KALT wrote:

Package: chromium-l10n
Severity: normal

Dear Maintainer,

Chromium is in version 01.0.4951.54-1 in Sid.

But chromium-l10n is older :

$ apt-cache policy chromium-l10n
chromium-l10n:
   Installed: (none)
   Candidate: 101.0.4951.41-2
   Version table:
  101.0.4951.41-2 970
 970 http://ftp.fr.debian.org/debian testing/main amd64 Packages
  99.0.4844.74-1~deb11u1 960
 960 http://ftp.fr.debian.org/debian stable/main amd64 Packages

$  apt-cache policy chromium
chromium:
   Installed: 101.0.4951.54-1
   Candidate: 101.0.4951.54-1
   Version table:
  *** 101.0.4951.54-1 980
 980 http://ftp.fr.debian.org/debian sid/main amd64 Packages
 100 /var/lib/dpkg/status
  101.0.4951.41-2 970
 970 http://ftp.fr.debian.org/debian testing/main amd64 Packages
  99.0.4844.74-1~deb11u1 960
 960 http://ftp.fr.debian.org/debian stable/main amd64 Packages

Thus chromium-l10n is not installable :

# apt install chromium-l10n
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
  chromium-l10n : Depends: chromium (< 101.0.4951.41-2.1~) but 101.0.4951.54-1
is to be installed
E: Unable to correct problems, you have held broken packages.

Regards,

Sébastien KALT


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

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

Versions of packages chromium-l10n depends on:
ii  chromium  101.0.4951.54-1

chromium-l10n recommends no packages.

chromium-l10n suggests no packages.

Bug#1004107: meson: flaky autopkgtest on armhf: dictionary changed size during iteration -> timeout

[Jussi Pakkanen]

On Thu, 5 May 2022 at 22:39, Paul Gevers  wrote:

> It just occurred to me that it may be useful to try and reduce the
> number of concurrent running tests to something you would expect on a
> more normal computer (under conditions where the framework is better
> tested). Our armel host has 160 cores, similar, our amd64 ci-worker13
> host has 56.

No harm in trying I guess:

https://github.com/mesonbuild/meson/pull/10358

Bug#1010576: akonadi-server: Akonadi/Kontact hangs after resuming from standby

[Frank Mehnert]

Exact same behavior here. I have this behavior for about 6-8 weeks. After each 
resume I have to stop akonadi and then kill mariadb (normal kill is nossible 
due to apparmor, only kill -9 works). After that, akonadi works again.

Thanks!

Bug#1010608: openldap: Flaky test test063-delta-multiprovider

[Adrian Bunk]

On Fri, May 06, 2022 at 01:04:54PM -0700, Ryan Tandy wrote:
> Control: tag -1 help
> 
> Hi Adrian,

Hi Ryan,

> On Thu, May 05, 2022 at 02:54:14PM +0300, Adrian Bunk wrote:
> > https://tests.reproducible-builds.org/debian/rbuild/unstable/i386/openldap_2.5.11+dfsg-1.rbuild.log.gz
> 
> I'm afraid this link has been superseded by the new upload (which built
> successfully & reproducibly). Just to confirm, you're saying that it failed
> for the same reason as the amd64 build?
> 
> > Using ldapadd to populate server 2...
> > Using ldapsearch to read all the entries from server 1...
> > Using ldapsearch to read all the entries from server 2...
> > Using ldapsearch to read all the entries from server 3...
> > Using ldapsearch to read all the entries from server 4...
> > Comparing retrieved entries from server 1 and server 2...
> > Comparing retrieved entries from server 1 and server 3...
> > test failed - server 1 and server 3 databases differ

this was from the reproducible build log.

It is the same reason, except that it was "server 3" instead of "server 4"
in the "test failed" line.

>...
> thanks,
> Ryan

cu
Adrian

Bug#1010608: openldap: Flaky test test063-delta-multiprovider

[Ryan Tandy]

Control: tag -1 help

Hi Adrian,

On Thu, May 05, 2022 at 02:54:14PM +0300, Adrian Bunk wrote:

https://tests.reproducible-builds.org/debian/rbuild/unstable/i386/openldap_2.5.11+dfsg-1.rbuild.log.gz


I'm afraid this link has been superseded by the new upload (which built 
successfully & reproducibly). Just to confirm, you're saying that it 
failed for the same reason as the amd64 build?



Using ldapadd to populate server 2...
Using ldapsearch to read all the entries from server 1...
Using ldapsearch to read all the entries from server 2...
Using ldapsearch to read all the entries from server 3...
Using ldapsearch to read all the entries from server 4...
Comparing retrieved entries from server 1 and server 2...
Comparing retrieved entries from server 1 and server 3...
test failed - server 1 and server 3 databases differ


I looked at this script, and I think I see how this part might be 
fragile: *if* I'm reading correctly, it waits for server 1 to receive 
the changes, but then I think it proceeds with the comparison 
immediately, and could fail if server 3 or 4 was slower.


https://git.openldap.org/openldap/openldap/-/blob/master/tests/scripts/test063-delta-multiprovider#L309-359

This is also different from the previous section (lines 264-294) which 
waits a flat $SLEEP1 seconds (default: 7) for changes to be synced.


However I'm not comfortable proposing changes to the script if I can't 
validate them. I could really use some help figuring out how to 
reproduce this failure. I would need to have just server 3 or 4 affected 
by some slowdown - and not sure what kind, whether CPU or network or 
disk. I guess I'll start by seeing if I can use tc to add latency to 
just the specific port...


thanks,
Ryan

Bug#1010658: mutt: SMTP SASL authentication broken (base64 encoding?)

[Kevin J. McCarthy]

On Fri, 6 May 2022 11:18:39 -0700 "Kevin J. McCarthy"  wrote:
According to my understanding of RFC4954, the "server challenge" 334 
response must either be blank (i.e., "334 "), or if there is data it 
must be base64 encoded.


I'm still interested to hear if 'set smtp_authenticators=login' works 
for you, just to make sure there isn't another issue I need to be aware 
of.


However, in the mean time I've pushed a commit up to branch 
'kevin/gsasl-smtp-plain-workarounds' on gitlab: 



Would you be willing to try that patch - either via compiling from git, 
or modifying the deb package and adding the patch to it?


thank you,

-Kevin


signature.asc
Description: PGP signature

Bug#1010680: dpkg: warning: while removing fonts-open-sans, directory '/usr/share/fonts/truetype/open-sans' not empty so not removed

[積丹尼 Dan Jacobson]

Package: fonts-open-sans
Version: 1.11-2

dpkg: warning: while removing fonts-open-sans, directory 
'/usr/share/fonts/truetype/open-sans' not empty so not removed

due to

/usr/share/fonts/truetype/open-sans/.uuid

Bug#1010679: golang-openldap: should this package be removed?

[Ryan Tandy]

Source: golang-openldap
Version: 0.2-2
Severity: serious
Tags: bookworm sid

Dear Go team,

I recently opened an RC bug against golang-openldap (#1007217). Rather 
than fixing the bug, I am wondering if golang-openldap should just be 
removed from Debian:


- It's an old library with no reverse-dependencies in the archive;
- Upstream has stopped development (last release in 2012, last commit in 
  2016);

- The package has been orphaned since 2016 (#836498);
- It looks like an actively maintained alternative exists: 
  golang-github-go-ldap-ldap.


thanks,
Ryan

Bug#1010678: slapd: dpkg-reconfigure doesn't restart slapd

[Ryan Tandy]

Package: slapd
Version: 2.5.12+dfsg-1
Severity: serious
Control: affects -1 src:sssd

The last upload of openldap is affected by #1010677 in debhelper: 
"dpkg-reconfigure slapd" doesn't restart slapd and the config reset 
isn't applied.


In addition to users' expectations, this breaks (at least) the 
autopkgtest of sssd, which uses dpkg-reconfigure to reset the 
configuration to a known starting point.

Bug#1010677: debhelper: dpkg-reconfigure doesn't restart --no-restart-after-upgrade services

[Ryan Tandy]

Package: debhelper
Version: 13.7.1
Control: affects -1 slapd

Hi Niels, hi Dave (in X-D-CC),

In #994204, Dave wrote:

I think it may be preferable to instead move the stop behaviour to the 
"preinst" script of the *new* version of the package so that both stop 
and start behaviours are encapsulated in a *single* version of the 
package (and hence can be freely moved between). This also means that 
"postinst" script's prior behaviour can be restored.


There's one issue with this: dpkg-reconfigure. It runs these scripts:

1. prerm upgrade
2. config reconfigure
3. postinst configure

The autoscripts now stop the service in "prerm remove" and "preinst 
upgrade". Unfortunately this means dpkg-reconfigure no longer 
restarts the service and the config changes are not applied.


I don't know what to suggest. I like Dave's solution for upgrades. Maybe 
dpkg-reconfigure should also run "preinst upgrade"? but I'm reluctant to 
suggest any change there, since its current behaviour has been stable 
for almost 20 years...


thanks,
Ryan

Bug#1010676: chromium-l10n: -l10n version behind chromium version in Sid

[Sebastien KALT]

Package: chromium-l10n
Severity: normal

Dear Maintainer,

Chromium is in version 01.0.4951.54-1 in Sid.

But chromium-l10n is older :

$ apt-cache policy chromium-l10n
chromium-l10n:
  Installed: (none)
  Candidate: 101.0.4951.41-2
  Version table:
 101.0.4951.41-2 970
970 http://ftp.fr.debian.org/debian testing/main amd64 Packages
 99.0.4844.74-1~deb11u1 960
960 http://ftp.fr.debian.org/debian stable/main amd64 Packages

$  apt-cache policy chromium
chromium:
  Installed: 101.0.4951.54-1
  Candidate: 101.0.4951.54-1
  Version table:
 *** 101.0.4951.54-1 980
980 http://ftp.fr.debian.org/debian sid/main amd64 Packages
100 /var/lib/dpkg/status
 101.0.4951.41-2 970
970 http://ftp.fr.debian.org/debian testing/main amd64 Packages
 99.0.4844.74-1~deb11u1 960
960 http://ftp.fr.debian.org/debian stable/main amd64 Packages

Thus chromium-l10n is not installable :

# apt install chromium-l10n
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 chromium-l10n : Depends: chromium (< 101.0.4951.41-2.1~) but 101.0.4951.54-1
is to be installed
E: Unable to correct problems, you have held broken packages.

Regards,

Sébastien KALT


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

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

Versions of packages chromium-l10n depends on:
ii  chromium  101.0.4951.54-1

chromium-l10n recommends no packages.

chromium-l10n suggests no packages.

Bug#1010658: mutt: SMTP SASL authentication broken (base64 encoding?)

[Kevin J. McCarthy]

On Fri, 06 May 2022 12:03:27 +0200 Vaclav Ovsik  wrote:

after Mutt upgrade from version 2.1.4-1 to version 2.2.3-2 SASL
authentication stopped working.

Debug from Mutt version 2.2.3:
[...]



 [2022-05-06 10:33:39] smtp_auth_gsasl: using mech PLAIN
 [2022-05-06 10:33:39] Authenticating (PLAIN)...
 [2022-05-06 10:33:39] 5> AUTH PLAIN^M
 [2022-05-06 10:33:39] 5< 334 Send base64(login\0login\0password)
 [2022-05-06 10:33:39] gsasl_step64() failed (8): Base 64 coding error in SASL 
library


According to my understanding of RFC4954, the "server challenge" 334 
response must either be blank (i.e., "334 "), or if there is data it 
must be base64 encoded.


The Cyrus SASL library also assumes all data from the server will be 
base64 encoded, but it is smarter and knows it can send an initial 
response with AUTH PLAIN.


What happens if you set smtp_authenticators=login?  Does the server also 
send plain text in the 334 response?


-Kevin



signature.asc
Description: PGP signature

Bug#1010469: Bug#1010437: autopkgtest: autopkgtest-build-lxc fails to build working lxc environment

[Julian Gilbey]

On Fri, May 06, 2022 at 02:08:23PM -0300, Antonio Terceiro wrote:
> > [...]
> > So now I'm in a quandry: despite installing lxc from scratch, and just
> > redoing so (purging the packages and removing all of the cached files,
> > /etc/lxc, /var/lib/lxc* and so on before reinstalling), I am still
> > experiencing the same problem.  I am running what I believe to be a
> > standard system - I first installed it in September 2020 or
> > thereabouts and have kept it up-to-date with testing ever since.  I
> > have no idea what might be causing this strange behaviour, and
> > therefore I have got no clue how to fix it.  I also don't know whether
> > what is wrong with my setup might affect other people as well.
> > 
> > If you have any suggestions of things I could look at on my system
> > (configuration files, other packages, ...) I'm all ears!
> 
> Are all packages recommended by lxc installed?

Yes, they are.  It's a standard Debian kernel (currently
linux-image-5.17.0-1-amd64 5.17.3-1).  I'm not aware of doing any
customisations that might have caused problems :(

/etc/lxc/default.conf is unmodified:

lxc.net.0.type = veth
lxc.net.0.link = lxcbr0
lxc.net.0.flags = up

lxc.apparmor.profile = generated
lxc.apparmor.allow_nesting = 1


and when I created a trial container, I get
/var/lib/lxc/debian-unstable-trial/config:

# Template used to create this container: /usr/share/lxc/templates/lxc-debian
# Parameters passed to the template: -r unstable
# For additional config options, please look at lxc.container.conf(5)

# Uncomment the following line to support nesting containers:
#lxc.include = /usr/share/lxc/config/nesting.conf
# (Be aware this has security implications)

lxc.net.0.type = veth
lxc.net.0.hwaddr = 00:16:3e:78:11:12
lxc.net.0.link = lxcbr0
lxc.net.0.flags = up
lxc.apparmor.profile = generated
lxc.apparmor.allow_nesting = 1
lxc.rootfs.path = dir:/var/lib/lxc/debian-unstable-trial/rootfs

# Common configuration
lxc.include = /usr/share/lxc/config/debian.common.conf

# Container specific configuration
lxc.tty.max = 4
lxc.uts.name = debian-unstable-trial
lxc.arch = amd64
lxc.pty.max = 1024


I've no idea if that is of any help.

Thanks!

   Julian

Bug#1010675: pcsc-cyberjack: uscan search for new upstream version with problem: search filter does not match new archive format

[mtths]

Source: pcsc-cyberjack
Version: 3.99.5final.sp14-2
Severity: minor

Dear Maintainer,

there is a new upstream version 3.99.5final.sp15 - but now the tar archive is
compressed by bzip2: pcsc-cyberjack_3.99.5final.SP15.tar.bz2
Therefore the current uscan filter looking for .tar.gz does not match anymore.

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

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

Bug#1010422: transition: r-api-bioc-3.15

[Andreas Tille]

Hi Nilesh,

Am Fri, May 06, 2022 at 06:10:52PM +0530 schrieb Nilesh Patra:
> 
> I think I did the changes as I wanted to, all graphics packages and all the
> important cran packages for that matter (including rmatrix) have now migrated.

Thanks a lot.
  
> > Please remove the moreinfo tag once you are ready.
> 
> I have done so, I think we can start the transition. Please consider pushing
> the buttons to get the tracker up :)

:-)
 
> PS: I will not be able to contribute in any capacity to bioc transition and 
> hope
> Andreas, you, Dylan et. al. would complete this :)

Same for me this weekend and start of next week.  I'm traveling and have
intentionally just my "traveling" laptop.  So I'm extremely limited with
contributions ... things will last as long they need.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#1010469: Bug#1010437: autopkgtest: autopkgtest-build-lxc fails to build working lxc environment

[Antonio Terceiro]

On Fri, May 06, 2022 at 04:13:28PM +0100, Julian Gilbey wrote:
> [excluding 1010437@bugs.d.o from reply list, as that's to do with
> eatmydata]
> 
> On Fri, May 06, 2022 at 08:53:35AM -0300, Antonio Terceiro wrote:
> > > [...]
> > > And I'm on 1:4.0.11-1.  So perhaps there was a regression in this
> > > regard?
> > 
> > No. I use this version and lxc just works for me. In fact everyone else
> > who is on testing/unstable is also using it. lxc also just works on a
> > clean VM. There is something wrong with your system that is causing
> > this, but it's in no way a general problem.
> 
> Dear Antonio,
> 
> It seems that you are right: I tried booting into Debian Live,
> upgrading to testing and running lxc; it ran without a problem.
> 
> So now I'm in a quandry: despite installing lxc from scratch, and just
> redoing so (purging the packages and removing all of the cached files,
> /etc/lxc, /var/lib/lxc* and so on before reinstalling), I am still
> experiencing the same problem.  I am running what I believe to be a
> standard system - I first installed it in September 2020 or
> thereabouts and have kept it up-to-date with testing ever since.  I
> have no idea what might be causing this strange behaviour, and
> therefore I have got no clue how to fix it.  I also don't know whether
> what is wrong with my setup might affect other people as well.
> 
> If you have any suggestions of things I could look at on my system
> (configuration files, other packages, ...) I'm all ears!

Are all packages recommended by lxc installed?


signature.asc
Description: PGP signature

Bug#1009776: podman: Packages uidmap and slirp4netns should be full dependencies

[Andrej Shadura]

On Sun, 17 Apr 2022 15:48:38 +0200 "Cal."  wrote:

My thinking was more along the lines of "If I'm going to run this as
root, I might as well run docker." And I saw podman rootless mode
kinda equivalent to the docker group when using docker. (But I am a
novice with podman, I pretty much just discovered it.)

If you want some comparisons, on Fedora podman rootless just works (I
don't actually know want dependencies they install, because I use it
to run one-off containers on my laptop -- the servers run docker)

The errors were not that cryptic by themselves but required some
googling to understand what binaries were missing and what packages
provided them. I think adding some instructions on the wiki
(https://wiki.debian.org/Podman) should be enough if dependencies are
to be minimal.


Indeed. When I ran into this in #983395, I was told here I’m supposed to 
use sudo (or install Recommends, which IIRC are disabled in Docker 
images), while the upstream told me I should use rootless mode. 
Eventually I managed to get a change merged to improve the error 
message, but I still find this a bit suboptimal. Just installing the 
package should make the most desired mode work without fiddling with it, 
and the upstream states that mode is rootless mode, hence uidmap and its 
friend should be in Depends, not Recommends.


--
Cheers,
  Andrej

Bug#999544: Package new upstream version

[Antoine Beaupré]

Quick update on this, zhsj on IRC pointed out upstream changed their
import path, so that fixed most of the import problems. We're left with:

github.com/v2fly/BrowserBridge/handler github.com/v2fly/ss-bloomring 
inet.af/netaddr

make[1]: Entering directory '/<>'
DH_GOPKG="github.com/v2fly/v2ray-core/main" dh_auto_build -- -ldflags "-s -w 
-buildid= -X v2ray.com/core.codename=user -X 
v2ray.com/core.build=20220505-203716 -X v2ray.com/core.version=4.45.0"
cd obj-x86_64-linux-gnu && go install -trimpath -v -p 2 -ldflags "-s -w 
-buildid= -X v2ray.com/core.codename=user -X 
v2ray.com/core.build=20220505-203716 -X v2ray.com/core.version=4.45.0" 
github.com/v2fly/v2ray-core/main github.com/v2fly/v2ray-core/main/confloader 
github.com/v2fly/v2ray-core/main/confloader/external 
github.com/v2fly/v2ray-core/main/distro/all 
github.com/v2fly/v2ray-core/main/distro/debug 
github.com/v2fly/v2ray-core/main/json github.com/v2fly/v2ray-core/main/jsonem
src/github.com/v2fly/v2ray-core/app/browserforwarder/forwarder.go:14:2: cannot 
find package "github.com/v2fly/BrowserBridge/handler" in any of:
/usr/lib/go-1.18/src/github.com/v2fly/BrowserBridge/handler (from 
$GOROOT)

/<>/obj-x86_64-linux-gnu/src/github.com/v2fly/BrowserBridge/handler
 (from $GOPATH)
src/github.com/v2fly/v2ray-core/common/antireplay/bloomring.go:6:2: cannot find 
package "github.com/v2fly/ss-bloomring" in any of:
/usr/lib/go-1.18/src/github.com/v2fly/ss-bloomring (from $GOROOT)
/<>/obj-x86_64-linux-gnu/src/github.com/v2fly/ss-bloomring 
(from $GOPATH)
src/github.com/v2fly/v2ray-core/app/router/condition_geoip.go:7:2: cannot find 
package "inet.af/netaddr" in any of:
/usr/lib/go-1.18/src/inet.af/netaddr (from $GOROOT)
/<>/obj-x86_64-linux-gnu/src/inet.af/netaddr (from $GOPATH)
make[1]: Leaving directory '/<>'
dh_auto_build: error: cd obj-x86_64-linux-gnu && go install -trimpath -v -p 2 
-ldflags "-s -w -buildid= -X v2ray.com/core.codename=user -X 
v2ray.com/core.build=20220505-203716 -X v2ray.com/core.version=4.45.0" 
github.com/v2fly/v2ray-core/main github.com/v2fly/v2ray-core/main/confloader 
github.com/v2fly/v2ray-core/main/confloader/external 
github.com/v2fly/v2ray-core/main/distro/all 
github.com/v2fly/v2ray-core/main/distro/debug 
github.com/v2fly/v2ray-core/main/json github.com/v2fly/v2ray-core/main/jsonem 
returned exit code 1

... I guess those would need to be packaged as well. Or vendored?
Opinions on that?

-- 
Non qui parum habet, sed qui plus cupit, pauper est.
It is not the man who has too little, but the man who craves more,
that is poor.- Lucius Annaeus Seneca (65 AD)

Bug#1010673: quassel-client: "Layout engine couldn't workaround Qt bug 238249, please report!"

[Eric Cooper]

Package: quassel-client
Version: 1:0.14.0-1+b1
Severity: normal

I'm running Gnome with Wayland.
I get a screenful of these warnings when I have QT_QPA_PLATFORM=xcb.
When I have QT_QPA_PLATFORM=wayland, I get the warnings but the window never 
appears.

I also have these env vars set:
QT_ACCESSIBILITY=1
QT_QPA_PLATFORMTHEME=qt5ct

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

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

Versions of packages quassel-client depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.14.0-1
ii  dbus-x11 [dbus-session-bus]   1.14.0-1
ii  libc6 2.33-7
ii  libdbusmenu-qt5-2 0.9.3+16.04.20160218-2+b1
ii  libgcc-s1 12-20220428-1
ii  libkf5configwidgets5  5.90.1-4
ii  libkf5coreaddons5 5.90.0-1
ii  libkf5notifications5  5.90.0-1
ii  libkf5notifyconfig5   5.90.0-1
ii  libkf5sonnetui5   5.90.0-1
ii  libkf5textwidgets55.90.0-1
ii  libkf5widgetsaddons5  5.90.0-1
ii  libkf5xmlgui5 5.90.0-1
ii  libqt5core5a  5.15.2+dfsg-16+b1
ii  libqt5dbus5   5.15.2+dfsg-16+b1
ii  libqt5gui55.15.2+dfsg-16+b1
ii  libqt5multimedia5 5.15.2-3
ii  libqt5network55.15.2+dfsg-16+b1
ii  libqt5webenginewidgets5   5.15.8+dfsg-1+b2
ii  libqt5widgets55.15.2+dfsg-16+b1
ii  libstdc++612-20220428-1
ii  quassel-data  1:0.14.0-1
ii  zlib1g1:1.2.11.dfsg-4

quassel-client recommends no packages.

quassel-client suggests no packages.

-- no debconf information

Bug#1010215: fixed the bug.

[Georges Khaznadar]

The tiny changes are in a push request at salsa.debian.org

I apologize: I forgot the "--delayed 10" option when I made the NMU.
The new version of the package (revision 0.3.0-2.1) has been built
properly: https://buildd.debian.org/status/package.php?p=einsteinpy

Best regards,   Georges.

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



signature.asc
Description: PGP signature

Bug#1000440: pylev: new upstream version

[Emmanuel Arias]

HI Julian,

Sorry for the delay.

I already prepared the new upstream release 1.4.0. It would be great if you
can upload it.

Thanks!
Emmanuel

Bug#1010469: Bug#1010437: autopkgtest: autopkgtest-build-lxc fails to build working lxc environment

[Julian Gilbey]

[excluding 1010437@bugs.d.o from reply list, as that's to do with
eatmydata]

On Fri, May 06, 2022 at 08:53:35AM -0300, Antonio Terceiro wrote:
> > [...]
> > And I'm on 1:4.0.11-1.  So perhaps there was a regression in this
> > regard?
> 
> No. I use this version and lxc just works for me. In fact everyone else
> who is on testing/unstable is also using it. lxc also just works on a
> clean VM. There is something wrong with your system that is causing
> this, but it's in no way a general problem.

Dear Antonio,

It seems that you are right: I tried booting into Debian Live,
upgrading to testing and running lxc; it ran without a problem.

So now I'm in a quandry: despite installing lxc from scratch, and just
redoing so (purging the packages and removing all of the cached files,
/etc/lxc, /var/lib/lxc* and so on before reinstalling), I am still
experiencing the same problem.  I am running what I believe to be a
standard system - I first installed it in September 2020 or
thereabouts and have kept it up-to-date with testing ever since.  I
have no idea what might be causing this strange behaviour, and
therefore I have got no clue how to fix it.  I also don't know whether
what is wrong with my setup might affect other people as well.

If you have any suggestions of things I could look at on my system
(configuration files, other packages, ...) I'm all ears!

Many thanks,

   Julian

Bug#909750: applications tries to write to /usr/* directories via libfontconfig1

[Paul Gevers]

Hi all,

On Mon, 22 Feb 2021 18:41:15 +0100 Dennis Filder  wrote:

Fix was in v2.13.91 (c4324f54ee16e648ba91f3e9c66af13ab3b1754c) [1]
which removed the relevant codepath.


Is the current phase of the bookworm release a good moment to apply this?


If anyone still deems this worth addressing in 2.13.1, the attached
patch fontconfig-2.13.1-909750-access-w_ok.patch silences the warning
through an added writability check.


It's policy violation, I think it's worth to try and fix it.


However, while looking into this I ran into test suite issues:

- test/run-test-conf.sh needs dash.patch to work with dash as /bin/sh

- test/run-test.sh fails if /bin/bwrap (package bubblewrap) is
  installed; disable-bwrap.patch patches it out.


This last one can probably be dealt with via an Build-Conflicts stanza?


1: 
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/c4324f54ee16e648ba91f3e9c66af13ab3b1754c


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#999544: Package new upstream version

[Antoine Beaupré]

[context for the list: I'm working on upgrading the golang-v2ray-core
package to the latest upstream. i'm kind of stuck on a problem I can't
figure out.]

Thanks, those patch are great. I think it might be better to use build
tags to disable that functionality than to rip it out with a patch, but
I'm happy to carry the patch set for now.

It also seems to work, to the extent that the patch applies and I can
get further in the build. I had to disable protobuf regeneration because
that was failing with an error:

Regenerate v2ray.com/core/app/reverse/config.proto
github.com/v2fly/v2ray-core/v4/app/reverse/config.pb.go: while trying to create 
directory ./github.com/v2flyRegenerate 
v2ray.com/core/app/browserforwarder/config.proto
: Permission denied

This could just be a tooling issue on our side, but there's a newer
protobuf dep in experimental that we can use for now, so I dodged that
problem by targeting experimental for now.

The next hurdle is that the build fails on what looks like a go mod
issue:

make[1]: Entering directory '/<>'
DH_GOPKG="v2ray.com/core/main" dh_auto_build -- -ldflags "-s -w -buildid= -X 
v2ray.com/core.codename=user -X v2ray.com/core.build=20220505-203716 -X 
v2ray.com/core.version=4.45.0"
cd obj-x86_64-linux-gnu && go install -trimpath -v -p 2 -ldflags "-s -w 
-buildid= -X v2ray.com/core.codename=user -X 
v2ray.com/core.build=20220505-203716 -X v2ray.com/core.version=4.45.0" 
v2ray.com/core/main v2ray.com/core/main/confloader 
v2ray.com/core/main/confloader/external v2ray.com/core/main/distro/all 
v2ray.com/core/main/distro/debug v2ray.com/core/main/json 
v2ray.com/core/main/jsonem
make[1]: Leaving directory '/<>'
src/v2ray.com/core/main/main.go:17:2: cannot find package 
"github.com/v2fly/v2ray-core/v4" in any of:
/usr/lib/go-1.18/src/github.com/v2fly/v2ray-core/v4 (from $GOROOT)

/<>/obj-x86_64-linux-gnu/src/github.com/v2fly/v2ray-core/v4 (from 
$GOPATH)

... there's a bunch more of those, naturally.

Dear Debian go folks, how do we typically solve those issues?

Do we have any other "go mod" package around? How do they handle those
problems?

Build log is attached, code lives in the debian/experimental branch on
salsa:

https://salsa.debian.org/go-team/packages/golang-v2ray-core/-/tree/debian/experimental

Thanks!
-- 
Power is always dangerous.
Power attracts the worst and corrupts the best.
- Edward Abbey

Bug#1010671: libsdl2-ttf-dev: CVE-2022-27470 - Arbitrary memory overwrite loading glyphs and rendering text

[Neil Williams]

Package: libsdl2-ttf-dev
Version: 2.0.18+dfsg-2
Severity: important
Tags: security
X-Debbugs-Cc: codeh...@debian.org, Debian Security Team 


Hi,

The following vulnerability was published for libsdl2-ttf.

CVE-2022-27470[0]:
| SDL_ttf v2.0.18 and below was discovered to contain an arbitrary
| memory write via the function TTF_RenderText_Solid(). This
| vulnerability is triggered via a crafted TTF file.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-27470
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-27470

Please adjust the affected versions in the BTS as needed.



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

Kernel: Linux 5.17.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
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 libsdl2-ttf-dev depends on:
ii  libc6-dev  2.34-0experimental2
ii  libsdl2-dev2.0.22+dfsg-3
ii  libsdl2-ttf-2.0-0  2.0.18+dfsg-2

libsdl2-ttf-dev recommends no packages.

libsdl2-ttf-dev suggests no packages.

-- no debconf information

Bug#998557: spice-gtk: FTBFS: ../meson.build:4:0: ERROR: Unknown options: "celt051"

[Paul Gevers]

Source: spice-gtk
Version: 0.39-3
Tags: pending
Followup-For: Bug #998557

Dear maintainer,

I have uploaded an NMU to DELAYED/2 to fix this issue. Please let me
know if I should cancel or delay.

Paul
diff --git a/debian/changelog b/debian/changelog
index bf8a2aa..3d72d7c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+spice-gtk (0.39-3.1) unstable; urgency=medium
+
+  [ Paul Gevers ]
+  * Non-maintainer upload
+  * Add pyparsing-detection.patch (taken from upstream) to prevent FTBFS
+
+  [ Simon Chopin ]
+  * d/rules: remove the -Dcelt051=disabled option as the whole CELT
+support has been removed upstream (Closes: #998557)
+
+ -- Paul Gevers   Thu, 05 May 2022 22:15:35 +0200
+
 spice-gtk (0.39-3) unstable; urgency=medium
 
   * debian/control: Increased debhelper-compat to 13
diff --git a/debian/patches/pyparsing-detection.patch 
b/debian/patches/pyparsing-detection.patch
new file mode 100644
index 000..3fd5913
--- /dev/null
+++ b/debian/patches/pyparsing-detection.patch
@@ -0,0 +1,33 @@
+From a7b5474bf808934cf0ee1107a58d5f4d97b9afbf Mon Sep 17 00:00:00 2001
+From: Frediano Ziglio 
+Date: Thu, 28 Oct 2021 16:45:34 +0100
+Subject: [PATCH] build: Correctly check for Python modules
+
+Currently using Meson the command "python -m " is
+run. However this command instead of trying to import the module
+tried to execute it as a script failing for the updated pyparsing
+with:
+
+/usr/bin/python3: No module named pyparsing.__main__; 'pyparsing' is a 
package and cannot be directly executed
+
+So instead use "python -c 'import ".
+Autoconf is already using that command (see m4/ax_python_module.m4).
+
+Signed-off-by: Frediano Ziglio 
+---
+ meson.build | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+Index: spice-gtk/subprojects/spice-common/meson.build
+===
+--- spice-gtk.orig/subprojects/spice-common/meson.build
 spice-gtk/subprojects/spice-common/meson.build
+@@ -132,7 +132,7 @@ if spice_common_generate_client_code or
+   if get_option('python-checks')
+ foreach module : ['six', 'pyparsing']
+   message('Checking for python module @0@'.format(module))
+-  cmd = run_command(python, '-m', module)
++  cmd = run_command(python, '-c', 'import @0@'.format(module))
+   if cmd.returncode() != 0
+ error('Python module @0@ not found'.format(module))
+   endif
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..86fe649
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+pyparsing-detection.patch
diff --git a/debian/rules b/debian/rules
index 53672d4..83928b4 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,7 +6,7 @@
 override_dh_auto_configure:
dh_auto_configure -- \
 -Dsmartcard=enabled -Dgtk=enabled \
--Dintrospection=enabled -Dvapi=enabled -Dcelt051=disabled \
+-Dintrospection=enabled -Dvapi=enabled \
 -Dusbredir=enabled -Dpolkit=enabled \
 -Dlz4=enabled -Dgtk_doc=enabled \
 -Dusb-acl-helper-dir=/usr/libexec \

Bug#951627: isc-dhcp-server: Can't stop the daemon

[Santiago Ruano Rincón]

Control: tags -1 + moreinfo
Control: notfound -1 4.4.2-P1-1+b1

On Wed, 19 Feb 2020 04:32:13 + Russell Coker  wrote:
> Package: isc-dhcp-server
> Version: 4.4.1-2.1
> Severity: important
> 
> In a fairly default configuration with systemd I can't stop the daemon in a
> normal manner (this happens on Buster as well as Unstable).
> 
> # /etc/init.d/isc-dhcp-server stop
> Stopping isc-dhcp-server (via systemctl): isc-dhcp-server.service.
> (sysadm_t:s0-s0:c0.c1023)root@unstable:/var/log# ps aux|grep dhcp
> root 841  0.0  1.1  13520  9316 ?Ss   04:27   0:00 
> /usr/sbin/dhcpd -4 -q -cf /etc/dhcp/dhcpd.conf
> # ls -l /run/dhcpd.pid 
> -rw-r--r--. 1 root root 4 Feb 19 04:27 /run/dhcpd.pid
> 
> To stop it properly (so it can be restarted again) I have to manually kill the
> process and rm the pid file.

[...]

Thanks for your bug report. However, I am unable to reproduce it
(running on an lxc container with 4.4.2-P1-1+b1):

root@sid:~# /etc/init.d/isc-dhcp-server start
Starting isc-dhcp-server (via systemctl): isc-dhcp-server.service.
root@sid:~# ps -ef | grep dhcpd
root1232   1  0 14:00 ?00:00:00 /usr/sbin/dhcpd -4 -q -cf 
/etc/dhcp/dhcpd.conf eth1
root1244 355  0 14:00 pts/500:00:00 grep dhcpd
root@sid:~# /etc/init.d/isc-dhcp-server stop
Stopping isc-dhcp-server (via systemctl): isc-dhcp-server.service.
root@sid:~# ps -ef | grep dhcpd
root1271 355  0 14:00 pts/500:00:00 grep dhcpd

Could you please test the latest version in sid?

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1010670: libgoogle-gson-java: CVE-2022-25647 Deserialization of Untrusted Data via the writeReplace method

[Neil Williams]

Source: libgoogle-gson-java
Version: 2.8.8-1
Severity: important
Tags: security
X-Debbugs-Cc: codeh...@debian.org, Debian Security Team 


Hi,

The following vulnerability was published for libgoogle-gson-java.

CVE-2022-25647[0]:
| The package com.google.code.gson:gson before 2.8.9 are vulnerable to
| Deserialization of Untrusted Data via the writeReplace() method in
| internal classes, which may lead to DoS attacks.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-25647
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-25647

Please adjust the affected versions in the BTS as needed.


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

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

Bug#951627:

[Santiago Ruano Rincón]

unmerge 951627
severity 951627 important
tags 951627 - patch
tags 1009209 + pending
thanks

El 14/04/22 a las 12:58, H.-Dirk Schmitt escribió:
> forcemerge 1009209 951627
> thanks

Thanks, but I don't see how both bugs are the same.

I am applying your patch. I hope to upload a new revision shortly.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1010669: Does not include an autopkgtest

[Sebastien Bacher]

Package: ell
Version: 0.50-1

It would be nicer if the package had autopkgtests testing. The attached 
patch is adding a trivial build test on the model of the ones used for 
most GNOME libraries, it ensure that a simple case builds and that the 
dev isn't missing any depends


Thanks for considering
diff -Nru ell-0.50/debian/changelog ell-0.50/debian/changelog
--- ell-0.50/debian/changelog	2022-04-22 12:05:21.0 +0200
+++ ell-0.50/debian/changelog	2022-05-06 15:06:10.0 +0200
@@ -1,3 +1,9 @@
+ell (0.50-2) unstable; urgency=medium
+
+  * debian/tests: add a trivial build autopkgtest
+
+ -- Sebastien Bacher   Fri, 06 May 2022 15:06:10 +0200
+
 ell (0.50-1) unstable; urgency=medium
 
   [ upstream ]
diff -Nru ell-0.50/debian/tests/build ell-0.50/debian/tests/build
--- ell-0.50/debian/tests/build	1970-01-01 01:00:00.0 +0100
+++ ell-0.50/debian/tests/build	2022-05-06 14:43:27.0 +0200
@@ -0,0 +1,35 @@
+#!/bin/sh
+# Copyright 2020 Collabora Ltd.
+# SPDX-License-Identifier: GPL-2.0-or-later
+
+set -eux
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
+cd "$AUTOPKGTEST_TMP"
+
+cat > trivial.c <
+
+int main(void)
+{
+	l_log_set_stderr();
+
+	if (!l_main_init())
+		return -1;
+		
+	l_info("Trivial");
+	return 0;
+}
+EOF
+
+# Deliberately word-splitting pkg-config's output:
+# shellcheck disable=SC2046
+"${CROSS_COMPILE}gcc" -otrivial trivial.c $("${CROSS_COMPILE}pkg-config" --cflags --libs ell glib-2.0)
+echo "build: OK"
+./trivial
+echo "run: OK"
diff -Nru ell-0.50/debian/tests/control ell-0.50/debian/tests/control
--- ell-0.50/debian/tests/control	1970-01-01 01:00:00.0 +0100
+++ ell-0.50/debian/tests/control	2022-05-06 14:20:35.0 +0200
@@ -0,0 +1,3 @@
+Tests: build
+Depends: libglib2.0-dev, build-essential
+Restrictions: allow-stderr, superficial

Bug#1010616: libmnl-dev: The libmnl.a is missing in libmnl-dev. Static build fails.

[Jeremy Sowden]

On 2022-05-05, at 16:50:46 +0200, Lars Ekman wrote:
> Package: libmnl-dev
> Version: 1.0.4-3build2
> Severity: normal
> X-Debbugs-Cc: lars.g.ek...@est.tech
> 
> Dear Maintainer,
> 
>  # gcc -o /tmp/hello /tmp/hello.c -lmnl
> (dynamic libs work)
> # gcc -static -o /tmp/hello /tmp/hello.c -lmnl
> /usr/bin/ld: cannot find -lmnl: No such file or directory
> 
> Since this is on Ubuntu 22.04 I reported the bug here:
> 
> https://bugs.launchpad.net/ubuntu/+source/libmnl/+bug/1971523
> 
> but was told that this is a Debian bug and asked to report it to you
> to improve the quality of the original package.

The default build of libmnl doesn't include the static library: it needs
to be explicitly enabled.  I'll make the necessary changes.

J.


signature.asc
Description: PGP signature

Bug#1010668: ofono: According documentation both methods org.ofono.Manager.GetModems and org.ofono.HandsfreeAudioManager.GetCards should return with signature array{object,dict}.

[Emanoil Kotsev]

Package: ofono
Version: 1.31-3
Severity: normal
Tags: upstream

Dear Maintainer,

   * What led up to the situation?
 I was trying to get list of modems and cards via d-bus when a modem and 
card are avialable
 When my program initializes it should get those lists.
 However I did not get the expected results when implementing logic for 
array{object,dict} and came to reporting this issue.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 According to specification both methods should return array{object,dict}
 It was not possible to parse both with the same algorythm.
 Performing a query agains ofono dbus service revealed that it is actually 
returning different structures.
 qdbus --literal --system org.ofono / 
org.freedesktop.DBus.Introspectable.Introspect
 
 

Bug#1010570: binaries in source without related source

[Antoine Beaupré]

On 2022-05-06 10:54:56, Tino Mettler wrote:
> Hi Antoine,
>
> I just discussed this a bit on #debian-mentors in IRC.
>
> Conclusion:
>
> - autogenerated files in the upstream tarball might be okay, if they are
>   not used for the binary packages (upgrade.py, install.py) or if they
>   are regenerated during build time (qrc_resources.py)
>
> - the details about this should be documented in debian/copyright
>
> - the missing images to generate the qrc_resources.py file can be put
>   into debian/missing-sources
>
> - we can discuss this issue again with the upstream author once he has
>   recovered
>
> - it is unlikely that there will be a new upstream release
>   before this
>
> When we follow this, we don't need to repack the upstream source, just
> add the images to debian/missing-sources and document all that in
> debian/copyright.
>
> What do you thing about this?

That makes total sense to me.

-- 
If quantum mechanics hasn't profoundly shocked you, you haven't
understood it yet.
   - Niels Bohr

Bug#1010667: ruby-xmlhash: CVE-2022-21949 - Improper Restriction of XML External Entity Reference

[Neil Williams]

Source: ruby-xmlhash
Version: 1.3.6-2
Severity: important
Tags: security
X-Debbugs-Cc: codeh...@debian.org, Debian Security Team 


Hi,

The following vulnerability was published for ruby-xmlhash.

CVE-2022-21949[0]:
| A Improper Restriction of XML External Entity Reference vulnerability
| in SUSE Open Build Service allows remote attackers to reference
| external entities in certain operations. This can be used to gain
| information from the server that can be abused to escalate to Admin
| privileges on OBS. This issue affects: SUSE Open Build Service Open
| Build Service versions prior to 2.10.13.

The vulnerable code is in https://github.com/coolo/xmlhash and is fixed
in version 1.3.8 of ruby-xmlhash.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-21949
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21949

Please adjust the affected versions in the BTS as needed.


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

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

Bug#1010666: ofono: According documentation both methods org.ofono.Manager.GetModems and org.ofono.HandsfreeAudioManager.GetCards should return with signature array{object,dict}.

[deloptes]

Package: ofono
Version: 1.31-3
Severity: normal
Tags: upstream

Dear Maintainer,

   * What led up to the situation?
 I was trying to get list of modems and cards via d-bus when a
modem and card are avialable
 When my program initializes it should get those lists.
 However I did not get the expected results when implementing
logic for array{object,dict} and came to reporting this issue.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 According to specification both methods should return array{object,dict}
 It was not possible to parse both with the same algorythm.
 Performing a query agains ofono dbus service revealed that it is
actually returning different structures.
 qdbus --literal --system org.ofono /
org.freedesktop.DBus.Introspectable.Introspect
 
 

Bug#1010422: transition: r-api-bioc-3.15

[Nilesh Patra]

Control: tags -1 - moreinfo

Hi Graham/Andreas,

On Tue, May 03, 2022 at 04:04:22PM +0200, Graham Inggs wrote:
> On Tue, 3 May 2022 at 15:51, Nilesh Patra  wrote:
> > I am now trying to get ggplot2 and friends in testing. Please give
> > it time until this weekend to migrate after which I will remove
> > my hacks and re-upload.
> 
> Please also look at rmatrix, it is a build-dependency of several
> r-bioc-* packages.

I think I did the changes as I wanted to, all graphics packages and all the
important cran packages for that matter (including rmatrix) have now migrated.
 
> > Let's start bioc transition after this is done.
> 
> Please remove the moreinfo tag once you are ready.

I have done so, I think we can start the transition. Please consider pushing
the buttons to get the tracker up :)

PS: I will not be able to contribute in any capacity to bioc transition and hope
Andreas, you, Dylan et. al. would complete this :)

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1010607: transition: libpodofo

[Mattia Rizzolo]

On Fri, May 06, 2022 at 12:42:30AM +0200, Sebastian Ramacher wrote:
> Control: tags -1 confirmed
> 
> On 2022-05-05 13:29:43 +0200, Mattia Rizzolo wrote:
> > Package: release.debian.org
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > Forwarded: https://release.debian.org/transitions/html/auto-libpodofo.html
> > 
> > Please schedule a transition for libpodofo.
> > 
> > I test-built all of the reverse deps (calibre, gimagereader,
> > horizon-eda, krename, scribus) and they all build.
> 
> Please go ahead

Thank you, uploaded!

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#1010665: sbuild-createchroot should not hardcode a default mirror

[Mattias Jernberg]

Source: sbuild
Version: 0.83.1
Severity: wishlist

sbuild-createchroot has an optional mirror argument, however if this is not
provided it has its own hardcoded mirror it uses when calling debootstrap.

This is unfortunate as debootstrap (and by extension sbuild) will happily work
with other distributions (such as ubuntu).

Included is a patch which makes sbuild let debootrap pick the mirror instead.

-- System Information:
Debian Release: 10.12
 APT prefers oldstable-updates
 APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores)
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 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
From 5fd7b6e404c8f5cf5c644199cc0626a71f969736 Mon Sep 17 00:00:00 2001
From: Mattias Jernberg 
Date: Fri, 6 May 2022 14:16:46 +0200
Subject: [PATCH] bin/sbuild-createchroot: Do not hardcode mirror argument to
 debootstrap

debootstrap understands distros better than sbuild, for instance it
has profiles for Ubuntu. By not giving the mirror argument when it
wasn't specified debootstrap will make the right choice of mirror
for Ubuntu as well, making it possible to do

  sbuild-createchroot focal /sbuild/focal-root

and having it work magically.
---
 bin/sbuild-createchroot | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/bin/sbuild-createchroot b/bin/sbuild-createchroot
index 7a106ef7..f504b3ff 100755
--- a/bin/sbuild-createchroot
+++ b/bin/sbuild-createchroot
@@ -334,15 +334,15 @@ if (-e $target) {
 }
 $target = abs_path($target);
 my $script = undef;
-my $mirror = "http://deb.debian.org/debian";;
+my $mirror = undef;
 
 $mirror = $ARGV[2] if $#ARGV >= 2;
-$script = $ARGV[3] if $#ARGV == 3;
+$script = $ARGV[3] if $#ARGV >= 3;
 
 if ($conf->get('VERBOSE')) {
 print "I: SUITE: $suite\n";
 print "I: TARGET: $target\n";
-print "I: MIRROR: $mirror\n";
+print "I: MIRROR: $mirror\n" if (defined($mirror));
 print "I: SCRIPT: $script\n" if (defined($script));
 }
 
@@ -363,7 +363,8 @@ if ($conf->get('MERGED_USR') ne 'auto') {
 	push @args, $conf->get('MERGED_USR') ?
 	"--merged-usr" : "--no-merged-usr";
 }
-push @args, "$suite", "$target", "$mirror";
+push @args, "$suite", "$target";
+push @args, "$mirror" if $mirror;
 push @args, "$script" if $script;
 
 # Set the path to debootstrap
-- 
2.20.1

Bug#1010664: ecdsautils: Upstream has moved

[Neil Williams]

Source: ecdsautils
Version: 0.3.2+git20151018-2
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: codeh...@debian.org

Hi,

I was checking new CVEs and noticed that ecdsautils uses an old fork of
the upstream project at https://github.com/tcatm/ecdsautils . This site
has since moved to https://github.com/freifunk-gluon/ecdsautils with a
latest release of v0.4.1 . 0.4.1 includes a fix for a CVE introduced
in the newer fork.


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

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

Bug#1010663: RFS: strawberry/1.0.4-1 [ITP] -- Audio player and music collection organizer

[Peter]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my[1] package "strawberry":

 * Package name    : strawberry
   Version : 1.0.4-1
   Upstream Author : Jonas Kvinge 
 * URL : https://www.strawberrymusicplayer.org/
 * License : GPL-3+, LGPL-2.1+, CC0-1.0, BSD-2-clause, GPL-3, 
Apache-2.0, GPL-2+, Expat, MIT, BSD-3-clause
   Section : sound

The source builds the following binary packages:

  strawberry - Audio player and music collection organizer

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/strawberry/strawberry_1.0.4-1.dsc

Changes for the initial release:

 strawberry (1.0.4-1) unstable; urgency=medium
 .
   * Initial release (Closes: #913079)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913079


Regards,
--
  Peter Blackman



[1] Regarding 'my' package;
The ITP was raised in 2018, I think the package qualifies for salvage.
https://wiki.debian.org/PackageSalvaging

Bug#1010437: autopkgtest: autopkgtest-build-lxc fails to build working lxc environment

[Antonio Terceiro]

On Fri, May 06, 2022 at 08:15:58AM +0100, Julian Gilbey wrote:
> Hi Paul and lxc maintainers,
> 
> lxc maintainers: sorry, I intended to copy in #1010469 in my previous
> message but didn't do so; a possible cause of this bug is discussed
> below
> 
> On Tue, May 03, 2022 at 06:36:36PM +0200, Paul Gevers wrote:
> > Hi Julian,
> > 
> > Sorry for the silence, you're doing great work.
> 
> Yes, I was determined to get it to work!
> 
> > On 03-05-2022 18:19, Julian Gilbey wrote:
> > > I've now done more searching, and the conclusion I've come to is that
> > > this is that this is the same issue discussed in
> > > https://wiki.debian.org/LXC/CGroupV2#LXC_containers_started_by_root
> > > (and in various other bug reports); by adding the two lines
> > > 
> > > lxc.cgroup.devices.allow =
> > > lxc.cgroup.devices.deny =
> > > 
> > > to the file /var/lib/lxc/autopkgtest-unstable/config, I was able to
> > > start the container.  But I'm running lxc version 1:4.0.11-1 and that
> > > wiki page says this change is unnecessary from version 4.0.2-1~1
> > > onwards, which does not seem to be the case.
> > > 
> > > lxc: I don't know whether the wiki is wrong or some change made in
> > > 4.0.2-1 has been reverted more recently.  Either way, it would be
> > > great to resolve this discrepancy.
> > 
> > I wonder if you refer to
> > https://bugs.debian.org/902394
> > https://bugs.debian.org/904732
> 
> I was thinking more of
> https://bugs.debian.org/944389
> 
> > Our infrastructure (where we don't experiences issues and are using the
> > autopkgtest/debci/autodep8 packages from unstable on an otherwise stable
> > system) runs lxc version 1:4.0.6-2. So that maybe limiting the changes
> > further.
> 
> And I'm on 1:4.0.11-1.  So perhaps there was a regression in this
> regard?

No. I use this version and lxc just works for me. In fact everyone else
who is on testing/unstable is also using it. lxc also just works on a
clean VM. There is something wrong with your system that is causing
this, but it's in no way a general problem.


signature.asc
Description: PGP signature

Bug#1010662: ITP: ros2-ament-index -- Fast resource indexing for ROS 2 packages

[Timo Röhling]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: roehl...@debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Subject: ITP: ros2-ament-index -- Fast resource indexing for ROS 2 packages
Package: wnpp
Owner: Timo Röhling 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: ros2-ament-index
  Version : 1.5.0
  Upstream Author : Open Source Robotics Foundation, Inc.
* URL : https://github.com/ament/ament_index
* License : Apache-2
  Programming Lang: Python, C++
  Description : Fast resource indexing for ROS 2 packages

The ament build system is the most common way to build packages for ROS 2.
ament_index is a filesystem-based resource management system which is
designed to allow queries on installed ROS 2 packages without crawling
the filesystem.

The package will be team-maintained under the umbrella of
Debian Robotics Team 
at https://salsa.debian.org/robotics-team/ros2-ament-index

Primary maintainer will be Timo Röhling .


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmJ1BCsACgkQ+C8H+466
LVnXGQwA7vFCzWpUHtTpH+gffGt+Yt5jIs5EuIL8jHIpICG1wTyz+9GKHZM0KRCA
qqvlj42B0tkFohPt+wgu6brnHGTEgYr+NYovw2FsBt661rAKGFOkcr0aXQO4hOwh
v6ldpSBImPh0cDMMtDb/uV2jmJyCLJ3jzVNFF1u10JDL3nPjv5Ak+grx86K/5+Uk
+riOW3+a743lKQZtJhWpF5hIfMS4hNFv46pkLMSE/i4UeyU26AQ8vynzEwsUR5lI
30nkGrXf0ccqhL2Z7IS8uggtytA4aZqeHUTF2wKcjcI4kpENtldjS1rmV1PP9Q4o
VqiZhYrGwhDqtXtbAc/2KXj+2RY52XqPAP9GuS0xu+CvZINVNq7z0lxOUnLFBqjr
w9g1a4HcQXnvdIIhP44lpEY7DBiPNyS2E1Fjt2IqeUIGvzWcS02NDvfO3N1zcY2o
w8kl7fYlqRqWcEmHol7uBATE5i6u78sM5jDyaOTSheG/4K/Cmq00K93vxR9fRgq/
RZI3pA6q
=DXK8
-END PGP SIGNATURE-

Bug#1010661: ITP: r-cran-lintr -- Linter for R Code

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: r-cran-lintr
  Version : 2.0.1
  Upstream Author : Jim Hester
* URL : https://cran.r-project.org/package=lintr
* License : Expat
  Programming Lang: GNU R
  Description : Linter for R Code

Checks adherence to a given style, syntax errors and possible semantic
issues. Supports on the fly checking of R code edited with RStudio IDE,
Emacs, Vim, Sublime Text and Atom.

I find this package useful to check ('lint') for various issues in my R
code.

Remark: This package is to be maintained with Debian R Packages
Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-lintr

Bug#1010660: dak: Crash with RecursionError: maximum recursion depth exceeded

[Christian Marillat]

Package: ftp.debian.org
Severity: normal

I'm using britney (last commit normally) 
2ccce826090ebc3f2cbdb26df3c5b0817f7a7cc2

You can download data used for this crash here :

https://www.deb-multimedia.org/tests/britney-2022-05-06.tar.xz

Since may 2, 2022 I see :

Traceback (most recent call last):
  File "/usr/bin/britney.py", line 1583, in 
Britney().main()
  File "/usr/bin/britney.py", line 1570, in main
self.upgrade_testing()
  File "/usr/bin/britney.py", line 1241, in upgrade_testing
self.run_auto_hinter()
  File "/usr/bin/britney.py", line 1515, in run_auto_hinter
for lst in self.get_auto_hinter_hints(self.upgrade_me):
  File "/usr/bin/britney.py", line 1479, in get_auto_hinter_hints
hint = find_related(e, set(), True)
  File "/usr/bin/britney.py", line 1468, in find_related
if not find_related(p, hint):
  File "/usr/bin/britney.py", line 1468, in find_related
if not find_related(p, hint):
  File "/usr/bin/britney.py", line 1468, in find_related
if not find_related(p, hint):
  [Previous line repeated 989 more times]
  File "/usr/bin/britney.py", line 1462, in find_related
hint.add(excuse.item)
  File "/usr/lib/python3/dist-packages/britney2/migrationitem.py", line 79, in 
__hash__
if not self.version:
RecursionError: maximum recursion depth exceeded

Christian

Bug#982085: gettext: Support autobuilding on emacsless and javaless architectures

[Laurent Bigonville]

Hello,

Any news about this?

By not allowing this package on some architectures, you are shifting the 
complexity of adding architecture qualifier to other packages higher in 
the dependency chain, so I'm also not sure this is a good thing either.


As said by other, disabling optional language bindings on architectures 
where the language is not supported is quite common...


my 2¢

Laurent Bigonville

Bug#1010659: systemd-networkd LLDP transmit broken since v250

[Matthijs van Duin]

Package: systemd
Version: 250.4-1
Severity: normal
Tags: patch upstream
X-Debbugs-Cc: matthijsvand...@gmail.com

Dear Maintainer,

Since systemd v250 (bookworm/testing), the LLDP packets transmitted by
systemd-networkd (with EmitLLDP=on) are malformed, causing debian systems
running bookworm to be unidentifiable by managed switches.

This is a regression relative to v247 (bullseye/stable).

The issue has been fixed upstream in git:
https://github.com/systemd/systemd/commit/b0221bb6a468e84841ad366ff39dcc4de97dc5db

Bug#1010658: mutt: SMTP SASL authentication broken (base64 encoding?)

[Vaclav Ovsik]

Package: mutt
Version: 2.2.3-2
Severity: normal

Dear Maintainer,
after Mutt upgrade from version 2.1.4-1 to version 2.2.3-2 SASL
authentication stopped working.

Debug from Mutt version 2.2.3:

 [2022-05-06 10:33:19] Mutt/2.2.3 (2022-04-12) debugging at level 7
 …
 [2022-05-06 10:33:37] Looking up smtp.seznam.cz...
 [2022-05-06 10:33:37] Connecting to smtp.seznam.cz...
 [2022-05-06 10:33:37] Connected to smtp.seznam.cz:587 on fd=5
 [2022-05-06 10:33:38] 5< 220 2.0.0 Seznam SMTP server waiting for your 
HELO/EHLO
 [2022-05-06 10:33:38] 5> EHLO bobekpc.i.cz^M
 [2022-05-06 10:33:38] 5< 250-Email.Seznam.cz - Email zdarma na cely zivot ESMTP
 [2022-05-06 10:33:38] 5< 250-AUTH LOGIN PLAIN
 [2022-05-06 10:33:38] 5< 250-8BITMIME
 [2022-05-06 10:33:38] 5< 250-PIPELINING
 [2022-05-06 10:33:38] 5< 250-SIZE 52428800
 [2022-05-06 10:33:38] 5< 250-ENHANCEDSTATUSCODES
 [2022-05-06 10:33:38] 5< 250-STARTTLS
 [2022-05-06 10:33:38] 5< 250 X-SZNEXTENSIONS
 [2022-05-06 10:33:38] 5> STARTTLS^M
 [2022-05-06 10:33:38] 5< 220 Ready to start TLS
 [2022-05-06 10:33:38] SSL/TLS connection using TLS1.3 
(ECDHE-RSA/AES-256-GCM/AEAD)
 [2022-05-06 10:33:39] 5> EHLO bobekpc.i.cz^M
 [2022-05-06 10:33:39] 5< 250-Email.Seznam.cz - Email zdarma na cely zivot ESMTP
 [2022-05-06 10:33:39] 5< 250-AUTH LOGIN PLAIN
 [2022-05-06 10:33:39] 5< 250-8BITMIME
 [2022-05-06 10:33:39] 5< 250-PIPELINING
 [2022-05-06 10:33:39] 5< 250-SIZE 52428800
 [2022-05-06 10:33:39] 5< 250-ENHANCEDSTATUSCODES
 [2022-05-06 10:33:39] 5< 250 X-SZNEXTENSIONS
 [2022-05-06 10:33:39] smtp_auth_gsasl: using mech PLAIN
 [2022-05-06 10:33:39] Authenticating (PLAIN)...
 [2022-05-06 10:33:39] 5> AUTH PLAIN^M
 [2022-05-06 10:33:39] 5< 334 Send base64(login\0login\0password)
 [2022-05-06 10:33:39] gsasl_step64() failed (8): Base 64 coding error in SASL 
library
 [2022-05-06 10:33:39] 5> *^M
 [2022-05-06 10:33:39] smtp_auth_gsasl: PLAIN failed
 [2022-05-06 10:33:39] SASL authentication failed


Debug from Mutt version 2.1.4:

 [2022-05-06 10:58:03] Mutt/2.1.4 (2021-12-11) debugging at level 7
 …
 [2022-05-06 10:58:16] Looking up smtp.seznam.cz...
 [2022-05-06 10:58:16] Connecting to smtp.seznam.cz...
 [2022-05-06 10:58:16] Connected to smtp.seznam.cz:587 on fd=5
 [2022-05-06 10:58:17] 5< 220 2.0.0 Seznam SMTP server waiting for your 
HELO/EHLO
 [2022-05-06 10:58:17] 5> EHLO bobekpc.i.cz^M
 [2022-05-06 10:58:17] 5< 250-Email.Seznam.cz - Email zdarma na cely zivot ESMTP
 [2022-05-06 10:58:17] 5< 250-AUTH LOGIN PLAIN
 [2022-05-06 10:58:17] 5< 250-8BITMIME
 [2022-05-06 10:58:17] 5< 250-PIPELINING
 [2022-05-06 10:58:17] 5< 250-SIZE 52428800
 [2022-05-06 10:58:17] 5< 250-ENHANCEDSTATUSCODES
 [2022-05-06 10:58:17] 5< 250-STARTTLS
 [2022-05-06 10:58:17] 5< 250 X-SZNEXTENSIONS
 [2022-05-06 10:58:17] 5> STARTTLS^M
 [2022-05-06 10:58:17] 5< 220 Ready to start TLS
 [2022-05-06 10:58:17] SSL/TLS connection using TLS1.3 
(ECDHE-RSA/AES-256-GCM/AEAD)
 [2022-05-06 10:58:18] 5> EHLO bobekpc.i.cz^M
 [2022-05-06 10:58:18] 5< 250-Email.Seznam.cz - Email zdarma na cely zivot ESMTP
 [2022-05-06 10:58:18] 5< 250-AUTH LOGIN PLAIN
 [2022-05-06 10:58:18] 5< 250-8BITMIME
 [2022-05-06 10:58:18] 5< 250-PIPELINING
 [2022-05-06 10:58:18] 5< 250-SIZE 52428800
 [2022-05-06 10:58:18] 5< 250-ENHANCEDSTATUSCODES
 [2022-05-06 10:58:18] 5< 250 X-SZNEXTENSIONS
 [2022-05-06 10:58:18] SASL local ip: 10.2.36.5;43614, remote ip:77.75.78.48;587
 [2022-05-06 10:58:18] External SSF: 256
 [2022-05-06 10:58:18] External authentication name: my-login-name
 [2022-05-06 10:58:18] mutt_sasl_cb_authname: getting authname for 
smtp.seznam.cz:587
 [2022-05-06 10:58:18] mutt_sasl_cb_authname: getting user for 
smtp.seznam.cz:587
 [2022-05-06 10:58:18] mutt_sasl_cb_pass: getting password for 
my-login-n...@smtp.seznam.cz:587
 [2022-05-06 10:58:18] Authenticating (PLAIN)...
 [2022-05-06 10:58:18] 5> AUTH PLAIN <<>>^M
 [2022-05-06 10:58:18] 5< 235 2.2.0 Authentication succeeded
 [2022-05-06 10:58:18] SASL protection strength: 0
 [2022-05-06 10:58:18] SASL protection buffer size: 65536

Thanks for maintaining Mutt
Regards
-- 
Zito


-- Package-specific info:
Mutt 2.2.3 (2022-04-12)
Copyright (C) 1996-2022 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 5.17.0-1-amd64 (x86_64)
ncurses: ncurses 6.3.20220423 (compiled with 6.3)
libidn2: 2.3.2 (compiled with 2.3.2)
hcache backend: tokyocabinet 1.4.48

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 11.2.0-20' 
--with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-11 
--pr

Bug#1010166: webkit2gtk: 2.36.1-1 apparent regression seen in devhelp autopkgtest

[Alberto Garcia]

On Mon, Apr 25, 2022 at 11:37:02AM -0400, Jeremy Bicha wrote:

> The new release of webkit2gtk won't migrate to Testing because of an
> autopkgtest regression in devhelp. I'm filing this bug to make sure
> that the maintainer notices the issue.

This has been fixed upstream but I think I'll just wait for the next
stable release instead of patching the current one.

Berto

Bug#1010570: binaries in source without related source

[Tino Mettler]

Hi Antoine,

I just discussed this a bit on #debian-mentors in IRC.

Conclusion:

- autogenerated files in the upstream tarball might be okay, if they are
  not used for the binary packages (upgrade.py, install.py) or if they
  are regenerated during build time (qrc_resources.py)

- the details about this should be documented in debian/copyright

- the missing images to generate the qrc_resources.py file can be put
  into debian/missing-sources

- we can discuss this issue again with the upstream author once he has
  recovered

- it is unlikely that there will be a new upstream release
  before this

When we follow this, we don't need to repack the upstream source, just
add the images to debian/missing-sources and document all that in
debian/copyright.

What do you thing about this?

Regards,
Tino

Bug#1010657: google-oauth-client-java: CVE-2021-22573 - IdTokenVerifier does not verify the signature of ID Token

[Neil Williams]

Source: google-oauth-client-java
Version: 1.28.0-2
Severity: grave
Tags: security
Justification: user security hole
X-Debbugs-Cc: codeh...@debian.org, Debian Security Team 


Hi,

The following vulnerability was published for google-oauth-client-java.

CVE-2021-22573[0]:
| The vulnerability is that IDToken verifier does not verify if token is
| properly signed. Signature verification makes sure that the token's
| payload comes from valid provider, not from someone else. An attacker
| can provide a compromised token with custom payload. The token will
| pass the validation on the client side. We recommend upgrading to
| version 1.33.3 or above


> The spec requires to validate the signature of ID token for apps that
> cannot guarantee TLS communication, which is the case for this library.
> This library initiates a local server that can run on any client machine
> without TLS support. So, it is critical to validate the signature, 
> before trusting the claims of an ID token, which can be received from 
> a malicious service provider.

Fixed in upstream release 1.33.3

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-22573
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22573

Please adjust the affected versions in the BTS as needed.



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

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

Bug#1010639: beep: Doesn't beep - could not open any device

[Rhonda D'Vine]

severity -1 minor

 Dear Richard,

* Richard Z  [2022-05-05 22:24:21 CEST]:
> Dear Maintainer,
> 
> installed the beep package and tried beep without any arguments and it does 
> not
> work.
> 
> $ BEEP_LOG_LEVEL=999 beep
> beep-log: Verbose: log_constructor
> beep-log: Verbose: beep_driver_console_constructor
> beep-log: Verbose: beep_drivers_register 0x5658c6a0 (console)
> beep-log: Verbose: beep_driver_evdev_constructor
> beep-log: Verbose: beep_drivers_register 0x5658c6e0 (evdev)
> beep: Verbose: evdev driver_detect 0x5658c6e0 (nil)
> beep: Verbose: b-lib: could not open(2) /dev/input/by-path/platform-pcspkr-
> event-spkr: Permission denied

 How are you logged into your system?  The udev rule that beep installs
requires you to be logged in on a virtual console.  Please be referred
to the documentation in /usr/share/doc/beep/PERMISSIONS.md.gz why this
is so. What always works is using beep as root, regardless of how people
are logged in, so I don't follow your call for that this is a grave bug
- in fact it works as intended and isn't even a bug at all.

 I am starting to (re)implement a specific beep group to which people
could be added on top of that. This requires a bit testing though, and
will hit unstable and only be in the next release then.  In the meantime
you could add a corresponding udev rule for giving access to users of a
specific group yourself while following the documentation in the
PERMISSIONS file.

 Hope that helps,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#1010651: debmake: add dependency “Suggests” for documentation

[Osamu Aoki]

Thanks.

I am updating source while fixing few minor gliches.  So I copied from your fix
without mering your branch via gitlab GUI.

It will be uploaded soon.

Osamu

> -Original Message-
> From: Ben Finney 
> Reply-To: Ben Finney , 1010...@bugs.debian.org
> To: 1010...@bugs.debian.org
> Subject: Bug#1010651: debmake: add dependency “Suggests” for documentation
> Date: Fri, 6 May 2022 15:54:35 +1000
> 
> Control: tags -1 + patch
> 
> On 06-May-2022, Ben Finney wrote:
> 
> > Please set a “Suggests: debmake-doc” dependency to the binary
> > package ‘debmake’.
> 
> The branch ‘wip/issue/1010651/dependency-for-documentation’
>  https://salsa.debian.org/bignose/debmake/-/commits/wip/issue/1010651/dependency-for-documentation
> >
> addresses this bug. The branch currently merges cleanly to the
> ‘main’ branch.
> 
> 

Bug#971249: waf: CHECK_VALUEOF does not work during cross compilation

[Michael Tokarev]

On Mon, 28 Sep 2020 06:53:03 +0200 Helmut Grohne  wrote:

Source: tevent
Version: 0.10.2-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

Thank you for applying my previous cross build patches. My previous
installment ended with:

> 5. waf has a mandatory run test for determining whether mkstemp works.
> 6. probably more

I've now looked into this and think that there are two bigger steps to
solve these. In the "probably more" department, there is a recurring
scheme of using a "CHECK_VALUEOF". It is used to determine the value of
an integer. If that value happens to be a compile time constant, it can
be determined using bisection. waf already does something similar in
CHECK_SIZEOF. I've implemented it for CHECK_VALUEOF and it now works
similar to autoconf's AC_COMPUTE_INT. In particular, it only does the
expensive bisection during cross compilation. In a native build, it
continues to use the quick run test it did before. I've attached a patch
for this.


Umm. waf in samba is doing many "bad" things which can be done in a more
efficient way not requiring to run compiled binaries. Yes, sizeof(foo) is
a good example, valueof is another example.

I think it is too much work to patch all these things out in debian.
It might be a good idea to try to ping upstream about this, maybe they'll
include similar change(s) to make cross-compilations easier.  But probably
not in Debian.

I'd not spend more time on trying to make waf-based samba builds to be
cross-compilable, unless upstream is actually willing to accept the
work somehow. So far, it seems like upstream isn't willing even to
accept simple spelling fixes.

FWIW, Helmut, what do you think about using qemu-user[-static] to help
cross-compiling stuff? It should significantly help in situations like
this one, to be able to run the small test binaries in an emulated mode,
provided you do have the foreign libs installed on the system.  Yes it
is not the fastest, but for sizeof/valueof tests like this it will
Just Work, hopefully...

Thanks,

/mjt

Bug#1006863: tevent: reproducible-builds: build path embedded in various libraries

[Michael Tokarev]

Control: tag -1 + moreinfo

On Sun, 06 Mar 2022 16:43:09 -0800 Vagrant Cascadian 
 wrote:

Source: tevent
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build path and resulting Build ID for various libraries is embedded:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/tevent.html

  /usr/lib/x86_64-linux-gnu/libtevent.so.0.11.0

  /build/1st/tevent-0.11.0/bin/default/../../tevent.c:303
  vs.
  /build/2/tevent-0.11.0/2nd/bin/default/../../tevent.c:303

The attached patch to debian/rules fixes this by passing
-ffile-prefix-map via CFLAGS in the dh_auto_configure override.


Hm. It looks like this flags is already being in use on unstable these days.

At least I see it in all recent unstable builds, eg:

 
https://buildd.debian.org/status/fetch.php?pkg=tevent&arch=amd64&ver=0.12.0-1&stamp=1651527651&raw=0

make[3]: Entering directory '/<>'
CC="x86_64-linux-gnu-gcc" CFLAGS="-g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat ...

I don't really know where it is coming from (my guess is dpkg-buildflags),
but it looks like this issue has already been solved in a more general
way meanwhile.

Can we perhaps close this bugreport now?

Thanks,

/mjt

Bug#1010656: libcoq-mathcomp-finmap: Depends: coq- but it is not installable

[Adrian Bunk]

Package: libcoq-mathcomp-finmap
Version: 1.5.1-3
Severity: serious

The following packages have unmet dependencies:
 libcoq-mathcomp-finmap : Depends: coq- but it is not installable

Bug#1010655: libcoq-mathcomp-bigenough: Depends: coq- but it is not installable

[Adrian Bunk]

Package: libcoq-mathcomp-bigenough
Version: 1.0.1-3
Severity: serious

The following packages have unmet dependencies:
 libcoq-mathcomp-bigenough : Depends: coq- but it is not installable

Bug#1010654: RFS: warpd/1.2.2-1 [ITP] -- modal keyboard driven pointer manipulation program

[clay stan]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: warpd
   Version : 1.2.2-1
   Upstream Author : https://github.com/rvaiya/warpd/issues
 * URL : https://github.com/rvaiya/warpd
 * License : MIT, ISC
 * Vcs : https://salsa.debian.org/claystan/warpd
   Section : utils

The source builds the following binary packages:

  warpd - modal keyboard driven pointer manipulation program

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/w/warpd/warpd_1.2.2-1.dsc

Changes for the initial release:

 warpd (1.2.2-1) unstable; urgency=medium
 .
   * Initial release (Closes: #1010296).

Regards,
-- 
  Clay Stan

Bug#951651: lsb_release does not check for existence of "apt-cache"

[Mark Hindley]

Control: tags -1 patch

Daniel,

Thanks for this and sorry for the slowness.

I am working on an update for lsb_release and have picked this up.

My proposed fix is attached. As far as I can see it is safe to continue if
apt-cache is not available and lsb_release will try other options.

Any comments?

Thanks

Mark
>From 3e32d1e9697dac52a77296bcc4f3d3129c8f153e Mon Sep 17 00:00:00 2001
From: Mark Hindley 
Date: Fri, 6 May 2022 08:13:25 +0100
Subject: [PATCH] Catch exceptions from running apt-cache and warn but
 continue.

Closes: #951651
---
 lsb_release.py | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/lsb_release.py b/lsb_release.py
index 5ef13ce..38d00c5 100644
--- a/lsb_release.py
+++ b/lsb_release.py
@@ -168,11 +168,16 @@ def parse_apt_policy():
 data = []
 
 C_env = os.environ.copy(); C_env['LC_ALL'] = 'C.UTF-8'
-policy = subprocess.Popen(['apt-cache','policy'],
-  env=C_env,
-  stdout=subprocess.PIPE,
-  stderr=subprocess.PIPE,
-  close_fds=True).communicate()[0].decode('utf-8')
+try:
+policy = subprocess.Popen(['apt-cache','policy'],
+  env=C_env,
+  stdout=subprocess.PIPE,
+  stderr=subprocess.PIPE,
+  close_fds=True).communicate()[0].decode('utf-8')
+except Exception as e:
+print('Failed to run apt-cache:', e, file=sys.stderr)
+return
+
 for line in policy.split('\n'):
 line = line.strip()
 m = re.match(r'(-?\d+)', line)
-- 
2.35.1

Bug#1010568: busco: missing dependencies on hmmer and prodigal

[Andrius Merkys]

Hi Andreas,

On 2022-05-05 22:42, Andreas Tille wrote:
> Am Thu, May 05, 2022 at 04:14:16PM +0300 schrieb Andrius Merkys:
>> Adding these surely are easy - thanks for doing so. Some maintainers
>> prefer keeping nonessential dependencies as Recommends or Suggests and
>> since this is my first encounter with busco I cannot say much about it.
> 
> I think in the field of bioinformatics there is no real point in beeing
> sparse with dependencies.  I think a failure due to a missing program is
> a pretty good reason to add a Depends.

Agree.

> I'm a big fan of fixing bugs quickly - so feel free to upload.

Done!

> May be some wishlist bug that describes the problem of the
> autopkgtest keeps a record about this issue.

Good point, opened #1010653.

Best wishes,
Andrius

Bug#1010653: busco: add autopkgtest to check integration with hmmer and prodigal

[Andrius Merkys]

Source: busco
Version: 5.3.2-2
Severity: wishlist

Hello,

As of 5.3.2-2, busco runs its build time tests during autopkgtest, which
is great. In addition, busco uses Debian-provided hmmer and prodigal
packages, but build time tests do not cover integration with these
tools. Thus it would be great to have an autopkgtest checking that (see
#1010568 for discussion). An example of busco call to execute could look
like this:

$ busco -i $FNA_FILE -l $LINEAGE -o output -m genome --offline

There is a couple of FNA files (for $FNA_FILE) given in test_data/ which
could be used for autopkgtest. For $LINEAGE, a matching genome should be
downloaded from BUSCO database [1] and specified. To have BUSCO lineages
in the archive their licensing details have to be clarified as the data
does not contain any explicit statements.

[1] https://busco-data.ezlab.org/v5/data/lineages/

Andrius

Bug#1010437: autopkgtest: autopkgtest-build-lxc fails to build working lxc environment

[Julian Gilbey]

Hi Paul and lxc maintainers,

lxc maintainers: sorry, I intended to copy in #1010469 in my previous
message but didn't do so; a possible cause of this bug is discussed
below

On Tue, May 03, 2022 at 06:36:36PM +0200, Paul Gevers wrote:
> Hi Julian,
> 
> Sorry for the silence, you're doing great work.

Yes, I was determined to get it to work!

> On 03-05-2022 18:19, Julian Gilbey wrote:
> > I've now done more searching, and the conclusion I've come to is that
> > this is that this is the same issue discussed in
> > https://wiki.debian.org/LXC/CGroupV2#LXC_containers_started_by_root
> > (and in various other bug reports); by adding the two lines
> > 
> > lxc.cgroup.devices.allow =
> > lxc.cgroup.devices.deny =
> > 
> > to the file /var/lib/lxc/autopkgtest-unstable/config, I was able to
> > start the container.  But I'm running lxc version 1:4.0.11-1 and that
> > wiki page says this change is unnecessary from version 4.0.2-1~1
> > onwards, which does not seem to be the case.
> > 
> > lxc: I don't know whether the wiki is wrong or some change made in
> > 4.0.2-1 has been reverted more recently.  Either way, it would be
> > great to resolve this discrepancy.
> 
> I wonder if you refer to
> https://bugs.debian.org/902394
> https://bugs.debian.org/904732

I was thinking more of
https://bugs.debian.org/944389

> Our infrastructure (where we don't experiences issues and are using the
> autopkgtest/debci/autodep8 packages from unstable on an otherwise stable
> system) runs lxc version 1:4.0.6-2. So that maybe limiting the changes
> further.

And I'm on 1:4.0.11-1.  So perhaps there was a regression in this
regard?

Best wishes,

   Julian

Bug#1010640: RFS: arbtt/0.11.1-1 [ITA] -- Automatic Rule-Based Time Tracker

[Bastian Germann]

Am 05.05.22 um 23:35 schrieb Robert Greener:

For the Vcs-*, I (obviously) don't have access to the Debian git
repositories. Is it okay to use my own personal GitHub / Sourcehut? The
original repo was a no longer active darcs repo.


You can do that or just drop them. Debian has a git service at
salsa.debian.org that you can also use.