Bug#1016050: sddm: intermittedly shows black page instead of login screen

[Paolo Greppi]

Package: sddm
X-Debbugs-Cc: paolo.gre...@libpf.com
Version: 0.19.0-3
Severity: important

About 90% of the times after a fresh reboot, sddm shows a black page 
with mouse pointer instead of the login screen.


The systemd sddm service is up and running. If I restart it on tty 1, 
the login screen reappears.


I attach two extracts from journalctl -u sddm, one for a successful 
boot, where the login screen was showed so that I could login 
(success.log) and one for a non-successful boot (failure.log).


They are similar up to "Greeter session started successfully". But in 
failure.log after that it says:


  lug 25 17:25:50 localhost sddm[1442]: Greeter session started 
successfully
  lug 25 17:25:50 localhost.localdomain sddm-helper[1573]: [PAM] 
Closing session

  lug 25 17:25:50 localhost.localdomain sddm-helper[1573]: [PAM] Ended.
  lug 25 17:25:50 localhost.localdomain sddm-helper[1573]: 
pam_unix(sddm-greeter:session): session closed for user sddm
   lug 25 17:25:50 localhost.localdomain sddm[1442]: Auth: sddm-helper 
exited with 6

lug 25 17:25:50 localhost.localdomain sddm[1442]: Greeter stopped.

In that case at 17:27:21 I restarted the service ("Signal received: 
SIGTERM") and then I could login.


In success.log after "Greeter session started successfully" it goes on with:

  lug 26 06:54:27 localhost sddm[1503]: Greeter session started 
successfully
  lug 26 06:54:27 localhost sddm[1503]: Message received from greeter: 
Connect
  lug 26 06:54:38 localhost.localdomain sddm[1503]: Message received 
from greeter: Login
  lug 26 06:54:38 localhost.localdomain sddm[1503]: Reading from 
"/usr/share/xsessions/plasma.desktop"
  lug 26 06:54:38 localhost.localdomain sddm[1503]: Reading from 
"/usr/share/xsessions/plasma.desktop"
  lug 26 06:54:38 localhost.localdomain sddm[1503]: Session 
"/usr/share/xsessions/plasma.desktop" selected, command: 
"/usr/bin/startplasma-x11"
  lug 26 06:54:38 localhost.localdomain sddm-helper[1970]: [PAM] 
Starting...
  lug 26 06:54:38 localhost.localdomain sddm-helper[1970]: [PAM] 
Authenticating...
  lug 26 06:54:38 localhost.localdomain sddm-helper[1970]: [PAM] 
Preparing to converse...
  lug 26 06:54:38 localhost.localdomain sddm-helper[1970]: [PAM] 
Conversation with 1 messages
  lug 26 06:54:38 localhost.localdomain sddm-helper[1970]: 
pam_kwallet5(sddm:auth): (null): pam_sm_authenticate

  lug 26 06:54:38 localhost.localdomain sddm-helper[1970]: [PAM] returning.
  lug 26 06:54:38 localhost.localdomain sddm[1503]: Authenticated 
successfully
  lug 26 06:54:38 localhost.localdomain sddm-helper[1970]: 
pam_kwallet5(sddm:setcred): pam_kwallet5: pam_sm_setcred
  lug 26 06:54:38 localhost.localdomain sddm-helper[1970]: 
pam_unix(sddm:session): session opened for user paolog(uid=1000) by (uid=0)
  lug 26 06:54:38 localhost.localdomain sddm[1503]: Auth: sddm-helper 
exited successfully

  lug 26 06:54:38 localhost.localdomain sddm[1503]: Greeter stopped.
  lug 26 06:54:38 localhost.localdomain sddm-helper[1970]: 
pam_kwallet5(sddm:session): pam_kwallet5: pam_sm_open_session
  lug 26 06:54:38 localhost.localdomain sddm-helper[1970]: Starting: 
"/etc/sddm/Xsession \"/usr/bin/startplasma-x11\""

  lug 26 06:54:38 localhost.localdomain sddm[1503]: Session started

So the difference is that in the second case sddm gets to "Message 
received from greeter: Connect" and all goes well, whereas in the first 
case that status is never reached because sddm-helper closes the PAM 
session and bails out, causing the greeter to stop.


It looks to me as a race condition.

Probably the PAM system is not yet ready when sddm-helper tries to connect.

Paolo


-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'stable'), (400, 'unstable')

Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-16-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sddm depends on:
ii  adduser 3.118
ii  debconf [debconf-2.0]   1.5.77
ii  libc6   2.31-13+deb11u3
ii  libgcc-s1   10.2.1-6
ii  libpam0g1.4.0-9+deb11u1
ii  libqt5core5a5.15.2+dfsg-9
ii  libqt5dbus5 5.15.2+dfsg-9
ii  libqt5gui5  5.15.2+dfsg-9
ii  libqt5network5  5.15.2+dfsg-9
ii  libqt5qml5  5.15.2+dfsg-6
ii  libqt5quick55.15.2+dfsg-6
ii  libstdc++6  10.2.1-6
ii  libsystemd0 247.3-7
ii  libxcb-xkb1 1.14-3
ii  libxcb1 1.14-3
ii  qml-module-qtquick2 5.15.2+dfsg-6
ii  x11-common  1:7.7+22
ii  xauth   1:1.1-1
ii  xserver-xorg [xserver]  1:7.7+22

Versions of packages sddm 

Bug#994151: youtube-dl seems to be alive again

[Andreas Tille]

Am Tue, Jul 26, 2022 at 12:29:50AM -0400 schrieb Andres Salomon:
> Yeah, I was just noticing that. I'll wait a few more months to see if
> youtube-dl does an actual release, but long-term it might make sense to turn
> youtube-dl into an empty package that depends on yt-dlp.
> 
> Since they have different command-line arguments and people might be using
> youtube-dl in scripts, I do wonder if youtube-dl should remain in bookworm
> with a NEWS.Debian warning users to switch to yt-dlp, and have it become a
> dummy package in bookworm+1?

Whatever you people who are *way, way* better informed about youtube-dl than
I am / will be decide:  I would be really happyif you would consider team
maintaining youtube-dl and yt-dl since I'm really not the best person to
maintain this package.  I'm fine with sponsoring any of your work if you do
not have upload permissions.

Kind regards

  Andreas. 

-- 
http://fam-tille.de

Bug#1016003: yt-dlp: create youtube-dl compatability package

[okgomdjgbm...@gmail.com]

youtube-dl has now become openoffice and yt-dlp libeoffice. It had one release 
in the last 12 months 6 months ago. It's prospects are bleak. What i'm 
proposing is just to ease the transition.

Many applications are hard coded to expect "youtube-dl". You need a symlink for 
+90% and maybe more for some, so just adding a virtual package to yt-dlp will 
not be enough. It's best to have a separate package doing the interface and 
maybe other hacks(symlink, virtual package, maybe  compatibilities options...). 
The youtube-dl and the compat package should be able to coexist with a 
reconfigure alternatives and youtube-dl should be the default.

On Sun, 24 Jul 2022 23:14:43 -0700
Kip Warner  wrote:

> On Mon, 2022-07-25 at 08:06 +0200, michel wrote:
> > Several applications expect to find youtube-dl, not yt-dlp. Yet, the
> > two are almost the same.
> > It would be nice to have a new package, that wraps around yt-dlp and
> > make it look like youtube-dl.  
> 
> I think the way to handle this might be for the yt-dlp source package
> to also generate a virtual package with a Provides stanza for youtube-
> dl, like so:
> 
>
> https://www.debian.org/doc/debian-policy/ch-relationships.html#virtual-packages-provides
> 
> Of course this assumes that the two interfaces are the same. Right now
> for 99 % of users in the simple ways that they use the two, I think
> they probably are. Over time though they will inevitably diverge in the
> same way mplayer's descendants did, or ffmpeg and libav's CLI tools.
>

Bug#1014506: slurm-wlm: flaky autopkgtest: sbatch fails without

[Marc Haber]

Control: affects 1014506 src:adduser
thanks

On Sun, Jul 17, 2022 at 11:56:08AM +0200, Florian Ernst wrote:
> On Thu, Jul 07, 2022 at 11:22:44AM +0200, Paul Gevers wrote:
> > [...]
> > I looked at the results of the autopkgtest of you package on armhf because
> > it was showing up as a regression for the upload of perl. I noticed that the
> > test regularly fails and I saw failures on other architectures too.
> > 
> > Because the unstable-to-testing migration software now blocks on
> > regressions in testing, flaky tests, i.e. tests that flip between
> > passing and failing without changes to the list of installed packages,
> > are causing people unrelated to your package to spend time on these
> > tests.
> 
> JFTR, this now also affects the unstable-to-testing migration of libyaml,
> cf. https://tracker.debian.org/pkg/libyaml. Thus marking this issue here
> as such.

jftr, adduser is now also affected.

Greetings
Marc

Bug#1016049: coreutils: env --{default,ignore,block}-signal with empty argument is valid and does nothing?

[наб]

Package: coreutils
Version: 8.32-4+b1
Severity: minor

Dear Maintainer,

Quoth upstream NEWS:
-- >8 --
* Noteworthy changes in release 8.31 (2019-03-10) [stable]

** New features

  env now supports '--default-signal[=SIG]', '--ignore-signal[=SIG]', and
  '--block-signal[=SIG], to setup signal handling before executing a program.

  env now supports '--list-signal-handling' to indicate non-default
  signal handling before executing a program.
-- >8 --

Quoth env(1):
-- >8 --
   --block-signal[=SIG]
  block delivery of SIG signal(s) to COMMAND

   --default-signal[=SIG]
  reset handling of SIG signal(s) to the default

   --ignore-signal[=SIG]
  set handling of SIG signals(s) to do nothing

   SIG may be a signal name like 'PIPE', or a signal number like '13'.  
Without SIG, all known signals are included.  Multiple signals can be 
comma-separated.
-- >8 --

However:
-- >8 --
$ env -v --block-signal=1 ls /dev/null
signal HUP (1) mask set to BLOCK
executing: ls
   arg[0]= ‘ls’
   arg[1]= ‘/dev/null’
/dev/null
$ env -v --block-signal ls /dev/null 2>&1 | paste - - - -
signal HUP (1) mask set to BLOCKsignal INT (2) mask set to BLOCK
signal QUIT (3) mask set to BLOCK   signal ILL (4) mask set to BLOCK
signal TRAP (5) mask set to BLOCK   signal ABRT (6) mask set to BLOCK   
signal BUS (7) mask set to BLOCKsignal FPE (8) mask set to BLOCK
signal KILL (9) mask set to BLOCK   signal USR1 (10) mask set to BLOCK  
signal SEGV (11) mask set to BLOCK  signal USR2 (12) mask set to BLOCK
signal PIPE (13) mask set to BLOCK  signal ALRM (14) mask set to BLOCK  
signal TERM (15) mask set to BLOCK  signal STKFLT (16) mask set to BLOCK
signal CHLD (17) mask set to BLOCK  signal CONT (18) mask set to BLOCK  
signal STOP (19) mask set to BLOCK  signal TSTP (20) mask set to BLOCK
signal TTIN (21) mask set to BLOCK  signal TTOU (22) mask set to BLOCK  
signal URG (23) mask set to BLOCK   signal XCPU (24) mask set to BLOCK
signal XFSZ (25) mask set to BLOCK  signal VTALRM (26) mask set to BLOCK
signal PROF (27) mask set to BLOCK  signal WINCH (28) mask set to BLOCK
signal POLL (29) mask set to BLOCK  signal PWR (30) mask set to BLOCK   
signal SYS (31) mask set to BLOCK   signal RTMIN (34) mask set to BLOCK
signal RTMIN+1 (35) mask set to BLOCK   signal RTMIN+2 (36) mask set to BLOCK   
signal RTMIN+3 (37) mask set to BLOCK   signal RTMIN+4 (38) mask set to BLOCK
signal RTMIN+5 (39) mask set to BLOCK   signal RTMIN+6 (40) mask set to BLOCK   
signal RTMIN+7 (41) mask set to BLOCK   signal RTMIN+8 (42) mask set to BLOCK
signal RTMIN+9 (43) mask set to BLOCK   signal RTMIN+10 (44) mask set to BLOCK  
signal RTMIN+11 (45) mask set to BLOCK  signal RTMIN+12 (46) mask set to BLOCK
signal RTMIN+13 (47) mask set to BLOCK  signal RTMIN+14 (48) mask set to BLOCK  
signal RTMIN+15 (49) mask set to BLOCK  signal RTMAX-14 (50) mask set to BLOCK
signal RTMAX-13 (51) mask set to BLOCK  signal RTMAX-12 (52) mask set to BLOCK  
signal RTMAX-11 (53) mask set to BLOCK  signal RTMAX-10 (54) mask set to BLOCK
signal RTMAX-9 (55) mask set to BLOCK   signal RTMAX-8 (56) mask set to BLOCK   
signal RTMAX-7 (57) mask set to BLOCK   signal RTMAX-6 (58) mask set to BLOCK
signal RTMAX-5 (59) mask set to BLOCK   signal RTMAX-4 (60) mask set to BLOCK   
signal RTMAX-3 (61) mask set to BLOCK   signal RTMAX-2 (62) mask set to BLOCK
signal RTMAX-1 (63) mask set to BLOCK   signal RTMAX (64) mask set to BLOCK 
executing: ls  arg[0]= ‘ls’
   arg[1]= ‘/dev/null’  /dev/null
$ env -v --block-signal= ls /dev/null
executing: ls
   arg[0]= ‘ls’
   arg[1]= ‘/dev/null’
/dev/null
-- >8 --

Precedent dictates that an empty argument should be refused (right?),
practicality suggests that it's likely a mistake
(since, again, it does nothing).
and the manual says it's forbidden
(clumsily using SIG and prose to describe signal[,signal]...).

Best,
наб

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

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

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

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#994151: youtube-dl seems to be alive again

[Andres Salomon]

On Tue, 26 Jul 2022 02:44:37 +0200 Christoph Anton Mitterer 
 wrote:

> On Tue, 2022-07-26 at 02:36 +0200, Diederik de Haas wrote:
> > It looks like things have changed and 'dirkf' has become the new
> > maintainer:
>
> My understanding was the was mostly "maintaining" it for stuff that
> doesn't support new python versions.
>
> Commit-wise it doesn't seem near as active as yt-dlp.
>

Yeah, I was just noticing that. I'll wait a few more months to see if 
youtube-dl does an actual release, but long-term it might make sense to 
turn youtube-dl into an empty package that depends on yt-dlp.


Since they have different command-line arguments and people might be 
using youtube-dl in scripts, I do wonder if youtube-dl should remain in 
bookworm with a NEWS.Debian warning users to switch to yt-dlp, and have 
it become a dummy package in bookworm+1?

Bug#1016048: golang-context: Not release for bookworm

[Shengjing Zhu]

Source: golang-context
Version: 1.1-4
Severity: serious
X-Debbugs-Cc: z...@debian.org

The package is obsoleted. Since it can't be removed from unstable currently,
let's remove it from testing first.

See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015195

Bug#1016047: RFH: chromium -- web browser

[Andres Salomon]

Package: wnpp
Severity: normal

I'm currently the only active maintainer for the chromium package in 
Debian. This really needs to be maintained by a team, especially since 
it requires security updates for stable at least two times per month. 
It is likely that chromium will not be included in the next stable 
release (bookworm) unless there's an active team maintaining it, as 
described in . I've done a lot of 
simplification of the chromium patches and packaging in order to make 
it easier for people to join the team.


There are lots of available tasks to do, depending on someone's skill 
and hardware. I've listed some tasks/roles below, with the most urgent 
at the top.



1) Security updates. These usually only require Debian packaging 
knowledge, and be pretty simple. Most security updates can be built 
without having to touch any of the chromium patches, with only a 
debian/changelog entry update. However, builds take 3 hours on my 8 
cpu/32gb build machine (45 mins at best with ccache, due to a lot of 
python and node build stuff that can't be cached), so you'll want 
access to some good hardware. These can also happen at any time; 
holidays, weekends, even a day or two before a scheduled release. 
Ideally several people would be available for packaging security 
updates.



2) Fixing bugs. There's plenty of bugs at
. 
Some require simple follow-ups with the reporter to see if it's still 
an issue, others require in-depth C++ or chromium knowledge or special 
hardware, and still others require just testing out a build-argument to 
see if some feature is safe to enable.



3) Getting patches upstream. When I took over the package 6mo ago, 
there were around 70 or 80 debian patches. We're down to 43 patches. 
Only about 10 of those are debian-specific; the rest are patches that 
really belong upstream. If you want to actually hack on chromium, this 
is probably a good way to get started.



4) Improving chromium's privacy, as described at 
. 
It'd be really nice to not have chromium "phone home" to google.



Please consider helping out! There's surely more stuff that's needed to 
do as well, that I've forgotten about.

Bug#1012895: [Aptitude-devel] Bug#1012895: aptitude: ftbfs with GCC-12

[Axel Beckert]

Hi Paul,

Paul Wise wrote:
> On Tue, 2022-07-26 at 00:28 +0200, Axel Beckert wrote:
> > Paul Wise wrote:
> > > I tried to build aptitude, found it fails due to cwidget bug #1015925.
> > 
> > Do you intend to NMU that?
> 
> I'd prefer the cwidget team take care of it,
[…]
> > Not really true. It's just that we haven't made a real "upstream"
> > release for quite a while because Manuel is mostly busy with the RISC
> > V port.

Manuel is "the cwidget team":
https://salsa.debian.org/groups/cwidget-team/-/group_members

I've requested team membership now as it kinda doesn't make sense that
Manuel does this alone despite aptitude is AFAIK the only consumer so
far.

> > As far I understood, it doesn't make sense to upload a new aptitude
> > package before #1015925 is fixed.
> 
> Agreed.

Ok, so let's see if I get into that team. I'll also try to nudge
separately due to the current GMail fuckup.

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

Bug#994151: youtube-dl seems to be alive again

[Christoph Anton Mitterer]

On Tue, 2022-07-26 at 02:36 +0200, Diederik de Haas wrote:
> It looks like things have changed and 'dirkf' has become the new
> maintainer: 

My understanding was the was mostly "maintaining" it for stuff that
doesn't support new python versions.

Commit-wise it doesn't seem near as active as yt-dlp.


Cheers,
Chris.

Bug#998367: perlcritic: "Code not tidy' after perltidy

[Axel Beckert]

Control: reassign -1 perltidy
Control: found -1 20220217-1
Control: affects -1 + libperl-critic-perl

Hi,

Felix Lechner wrote:
> > The bug lies in the interaction between these 2 tools.
> 
> Yay, the problem was solved! […]
> https://github.com/Perl-Critic/Perl-Critic/issues/925#issuecomment-1048340859

Actually that "fix" still would have needed code changes in Lintian
and other consumers. These code changes additionally would have had to
check the version of perltidy and behave differently based on the version.

But according to
https://github.com/Perl-Critic/Perl-Critic/issues/925#issuecomment-1194737842
the issue should be fixed "in the most recent release of Perl::Tidy
(v20220613 or later)" due to a changed default value which seemingly
no more needs to the above mentioned code changes.

So please update perltidy to the most recent upstream release.

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

Bug#994151: youtube-dl seems to be alive again

[Diederik de Haas]

On Tue, 19 Apr 2022 17:45:46 -0400 Andres Salomon  wrote:
> I don't know what the current status of upstream is, but if youtube-dl 
> upstream continues - I would be happy to help co-maintain the package. 

It looks like things have changed and 'dirkf' has become the new maintainer: 
https://github.com/ytdl-org/youtube-dl/issues/30568

There have been new commit, but not (yet) a new upstream release.

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

Bug#1012895: aptitude: ftbfs with GCC-12

[Paul Wise]

On Tue, 2022-07-26 at 00:28 +0200, Axel Beckert wrote:
> Paul Wise wrote:
> > I tried to build aptitude, found it fails due to cwidget bug #1015925.
> 
> Do you intend to NMU that?

I'd prefer the cwidget team take care of it, since I don't have access
to their VCS, but if they don't have time right now, then I can do it.

> > and has debian/patches/
> 
> Correct, this is mostly used for short-term fixes.

Hmm, OK. I would have expected these would go into new upstream point
releases, like 0.8.13.1 or similar.

> > that seems to be unused.
> 
> Not really true. It's just that we haven't made a real "upstream"
> release for quite a while because Manuel is mostly busy with the RISC
> V port.
> ...

I see, thanks for the info.

> As far I understood, it doesn't make sense to upload a new aptitude
> package before #1015925 is fixed.

Agreed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1010095: performous: FTBFS on ppc64el

[Dan Bungert]

Just saw the existing merge request.  Oh well, I guess I can treat this as +1
for merging https://salsa.debian.org/games-team/performous/-/merge_requests/1 .

Bug#1004763: libopenshot: FTBFS with ffmpeg 5.0

[Steve Langasek]

Package: libopenshot
Version: 0.2.7+dfsg1-2
Followup-For: Bug #1004763
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch
Control: tags -1 patch

Please find attached a patch that cherry-picks support for ffmpeg 5.0 from
upstream.

This has been uploaded to Ubuntu as part of the ffmpeg 5.0 transition.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru libopenshot-0.2.7+dfsg1/debian/control 
libopenshot-0.2.7+dfsg1/debian/control
--- libopenshot-0.2.7+dfsg1/debian/control  2022-07-19 05:56:48.0 
-0700
+++ libopenshot-0.2.7+dfsg1/debian/control  2022-07-22 16:15:39.0 
-0700
@@ -1,6 +1,5 @@
 Source: libopenshot
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian Multimedia Maintainers 

+Maintainer: Debian Multimedia Maintainers 
 Uploaders: Dr. Tobias Quathamer ,
Anton Gladky 
 Section: libs
diff -Nru 
libopenshot-0.2.7+dfsg1/debian/patches/0001-constify-some-AVCodecIDs-necessary-for-new-ffmpeg.patch
 
libopenshot-0.2.7+dfsg1/debian/patches/0001-constify-some-AVCodecIDs-necessary-for-new-ffmpeg.patch
--- 
libopenshot-0.2.7+dfsg1/debian/patches/0001-constify-some-AVCodecIDs-necessary-for-new-ffmpeg.patch
 1969-12-31 16:00:00.0 -0800
+++ 
libopenshot-0.2.7+dfsg1/debian/patches/0001-constify-some-AVCodecIDs-necessary-for-new-ffmpeg.patch
 2022-07-22 16:15:08.0 -0700
@@ -0,0 +1,98 @@
+From 99034feb4e5a00eeea90fc8c55ce1a511a3e9736 Mon Sep 17 00:00:00 2001
+From: nick black 
+Date: Sun, 21 Nov 2021 23:25:37 -0500
+Subject: [PATCH] constify some AVCodecIDs, necessary for new ffmpeg
+
+Signed-off-by: nick black 
+---
+ src/FFmpegReader.cpp |  6 +++---
+ src/FFmpegWriter.cpp | 12 ++--
+ 2 files changed, 9 insertions(+), 9 deletions(-)
+
+diff --git a/src/FFmpegReader.cpp b/src/FFmpegReader.cpp
+index 19d038bf..a0d4c183 100644
+--- a/src/FFmpegReader.cpp
 b/src/FFmpegReader.cpp
+@@ -241,10 +241,10 @@ void FFmpegReader::Open() {
+   pStream = pFormatCtx->streams[videoStream];
+ 
+   // Find the codec ID from stream
+-  AVCodecID codecId = AV_FIND_DECODER_CODEC_ID(pStream);
++  const AVCodecID codecId = 
AV_FIND_DECODER_CODEC_ID(pStream);
+ 
+   // Get codec and codec context from stream
+-  AVCodec *pCodec = avcodec_find_decoder(codecId);
++  const AVCodec *pCodec = avcodec_find_decoder(codecId);
+   AVDictionary *opts = NULL;
+   int retry_decode_open = 2;
+   // If hw accel is selected but hardware cannot handle 
repeat with software decoding
+@@ -498,7 +498,7 @@ void FFmpegReader::Open() {
+   AVCodecID codecId = AV_FIND_DECODER_CODEC_ID(aStream);
+ 
+   // Get codec and codec context from stream
+-  AVCodec *aCodec = avcodec_find_decoder(codecId);
++  const AVCodec *aCodec = avcodec_find_decoder(codecId);
+   aCodecCtx = AV_GET_CODEC_CONTEXT(aStream, aCodec);
+ 
+   // Set number of threads equal to number of processors 
(not to exceed 16)
+diff --git a/src/FFmpegWriter.cpp b/src/FFmpegWriter.cpp
+index a959fc4d..5662c271 100644
+--- a/src/FFmpegWriter.cpp
 b/src/FFmpegWriter.cpp
+@@ -151,7 +151,7 @@ void FFmpegWriter::initialize_streams() {
+ void FFmpegWriter::SetVideoOptions(bool has_video, std::string codec, 
Fraction fps, int width, int height, Fraction pixel_ratio, bool interlaced, 
bool top_field_first, int bit_rate) {
+   // Set the video options
+   if (codec.length() > 0) {
+-  AVCodec *new_codec;
++  const AVCodec *new_codec;
+   // Check if the codec selected is a hardware accelerated codec
+ #if USE_HW_ACCEL
+ #if defined(__linux__)
+@@ -273,7 +273,7 @@ void FFmpegWriter::SetVideoOptions(std::string codec, int 
width, int height,  Fr
+ void FFmpegWriter::SetAudioOptions(bool has_audio, std::string codec, int 
sample_rate, int channels, ChannelLayout channel_layout, int bit_rate) {
+   // Set audio options
+   if (codec.length() > 0) {
+-  AVCodec *new_codec = 
avcodec_find_encoder_by_name(codec.c_str());
++  const AVCodec *new_codec = 
avcodec_find_encoder_by_name(codec.c_str());
+   if (new_codec == NULL)
+   throw InvalidCodec("A valid audio codec could not be 
found for this file.", path);
+   else {
+@@ -1033,7 +1033,7 @@ AVStream *FFmpegWriter::add_audio_stream() {
+   AVStream *st;
+ 
+   // Find the audio codec
+-  AVCodec *codec = avcodec_find_encoder_by_name(info.acodec.c_str());

Bug#1012895: aptitude: ftbfs with GCC-12

[Axel Beckert]

Hi Paul,

Paul Wise wrote:
> I tried to build aptitude, found it fails due to cwidget bug #1015925.

Do you intend to NMU that?

> The issue is that the operator<< functions are not declared before the
> call site, so forward declarations before HelperMacros.h are needed:

Thanks for having looked into this.

> I'm not sure how to contribute this change to the package because this
> should be a native package but isn't

I'm not that sure about this. But it is probably historically grown.

> and has debian/patches/

Correct, this is mostly used for short-term fixes.

> but also an upstream master branch

Correct. This is where actual development and new "upstream" releases
happen.

> that seems to be unused.

Not really true. It's just that we haven't made a real "upstream"
release for quite a while because Manuel is mostly busy with the RISC
V port.

> I suggest merging the contents of debian/patches/ to the upstream
> master branch

IIRC this is partially already done.

> and then cherry-picking the FTBFS patches to a new minor
> release branch instead of using debian/patches/.

If it needs to be done quick, it will not happen that way.

> I've filed two merge requests with two different approaches, one is a
> commit for the master branch and one a patch for the debian-sid branch.

Thanks. Attaching the patch here would have sufficed, though.

As far I understood, it doesn't make sense to upload a new aptitude
package before #1015925 is fixed.

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

Bug#1010095: performous: FTBFS on ppc64el

[Dan Bungert]

Hi Maintainer,

I was able to get it building again, at least on the ppc64el machine I tested,
by not using with -mno-altivec.

Builds both with Sid and Ubuntu Kinetic, if you use my patch from bug 1004616
and no longer set -mno-altivec.

See also this commit:
https://salsa.debian.org/games-team/performous/-/commit/de72e1dfae743adb65a444341872bda06d6941e7

Is -mno-altivec still required?

-Dan

Bug#1015044: sshuttle: FTBFS: dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 2

[Brian May]

> > dpkg-source: info: local changes detected, the modified files are:
> >  sshuttle-1.1.0/sshuttle/version.py

I think this is a bug in setuptools-scm, it looks like it is generating
an invalid version.py file:

--- sshuttle/version.py 2022-01-28 09:37:51.0 +1100
+++ /tmp/version.py 2022-07-26 07:58:22.490171539 +1000
@@ -1,5 +1,5 @@
 # coding: utf-8
 # file generated by setuptools_scm
 # don't change, don't track in version control
-version = '1.1.0'
-version_tuple = (1, 1, 0)
+__version__ = version = '1.1.0'
+__version_tuple__ = version_tuple = (1, 1, 0)
-- 
Brian May 

Bug#1016046: ITP: genomicsdb -- sparse array storage library for genomics

[Pierre Gruet]

Package: wnpp
Severity: wishlist
Owner: Debian-med team 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-...@lists.debian.org

* Package name: genomicsdb
  Version : 1.4.3
  Upstream Author : Intel Health and Lifesciences
* URL : https://www.genomicsdb.org/
* License : Expat
  Programming Lang: C++, Java
  Description : sparse array storage library for genomics

GenomicsDB is built on top of a htslib fork and an internal array storage
system for importing, querying and transforming variant data. Variant data is
sparse by nature (sparse relative to the whole genome) and using sparse array
data stores is a perfect fit for storing such data.

The GenomicsDB stores variant data in a 2D array where:
 - Each column corresponds to a genomic position (chromosome + position);
 - Each row corresponds to a sample in a VCF (or CallSet in the GA4GH
   terminology);
 - Each cell contains data for a given sample/CallSet at a given position;
   data is stored in the form of cell attributes;
 - Cells are stored in column major order - this makes accessing cells with
   the same column index (i.e. data for a given genomic position over all
   samples) fast.
 - Variant interval/gVCF interval data is stored in a cell at the start of the
   interval. The END is stored as a cell attribute. For variant intervals
   (such as deletions and gVCF REF blocks), an additional cell is stored at
   the END value of the variant interval. When queried for a given genomic
   position, the query library performs an efficient sweep to determine all
   intervals that intersect with the queried position.

There is a C++ library and a Java library, we plan to ship both of them.

This library is needed as a dependency of gatk, which is a packaging target of
the Debian-med team.

Bug#1001214: Getting EFI Boot Guard into Debian

[Bastian Germann]

Am 24.07.22 um 16:09 schrieb Jan Kiszka:

Hi all,

it would be really great to have EBG as an official package in bookworm.
There is the initial work done by Bastian with contributions by Quirin
already [1], but EBG moved on since then and needs some more work to
support 0.12. Likely, we will need patches from current next as bookworm
is broken with that release. Some bits to account for structural changes
in the latest releases is in [2], possibly not in Debian shape yet.

Bastian, do you have the time to support this? What is needed from your
perspective, what should we contribute?


I have updated the package to build v0.12 but run into:
./configure: line 14997: syntax error near unexpected token 
`-mgeneral-regs-only,'
./configure: line 14997: `AX_CHECK_COMPILE_FLAG(-mgeneral-regs-only,'

Full log at https://salsa.debian.org/debian/efibootguard/-/jobs/3036697

The suggested "next" changes do not fix this.

So if you could provide a patch for this I can hand in the package.
I would prefer not to be responsible for it and can hand over maintainership to
somebody who actually uses the software. I can grant git access for that person 
with
a salsa (Gitlab) username provided.

Whoever wants to be the package maintainer please make #1001214 an ITP (retitle 
and own the bug).



Thanks,
Jan

[1] https://salsa.debian.org/debian/efibootguard/
[2]
https://gitlab.com/cip-project/cip-core/isar-cip-core/-/tree/master/recipes-bsp/efibootguard

Bug#1015976: Should vmm be removed?

[Bernd Zeimetz]

Hi,

well, I've started to work on the package, but I've not yet decided if I want 
to maintain it. Help would be very welcome.

Bernd

25.07.2022 21:53:09 Pascal Volk :

> On 7/24/22 18:05, Moritz Muehlenhoff wrote:
>> Source: vmm
>> Version: 0.6.2-2
>> Severity: serious
>> 
>> Your package came up as a candidate for removal from Debian:
>> - Still depends on Python 2
>> - Last upload in 2017, removed from testing since 2019
>> 
>> If you disagree and want to continue to maintain this package,
>> please just close this bug (and fix the open issues).
>> 
> 
> Hi Moritz,
> 
> looks like Bernd Zeimetz has taken over the maintenance for vmm. :-)
> https://salsa.debian.org/debian/vmm/-/commit/5f5c7ef13ed33c60fdb0d4eb140370d9593bce56
> 
> Bernd, that's why I've added you to CC.
> 
> 
> Regards,
> Pascal
> -- 
> Ubuntu is an ancient African word meaning “I can’t install Debian.”
>  -- unknown

Bug#1016045: sbcl FTBFS on !amd64

[Adrian Bunk]

Source: sbcl
Version: 2:2.2.6-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=sbcl=2%3A2.2.6-1

...
cd doc/manual && make docstrings && make
make[2]: Entering directory '/<>/doc/manual'
touch tempfiles-stamp
sh make-tempfiles.sh "" ""docstrings/"" && touch "docstrings/"
/creating docstring snippets
  from SBCL='../../src/runtime/sbcl --core ../../output/sbcl.core'
  for documented contribs
(sb-aclrepl sb-bsd-sockets sb-concurrency sb-cover sb-graph sb-grovel
 sb-md5 sb-posix sb-queue sb-rotate-byte sb-simd sb-simple-streams sb-sprof)
  for packages
(COMMON-LISP SB-ACLREPL SB-ALIEN SB-BSD-SOCKETS SB-CONCURRENCY SB-COVER
 SB-DEBUG SB-EXT SB-GRAPH SB-GRAY SB-GROVEL SB-MD5 SB-MOP SB-PCL SB-POSIX
 SB-PROFILE SB-QUEUE SB-ROTATE-BYTE SB-SEQUENCE SB-SIMD SB-SIMPLE-STREAMS
 SB-SPROF SB-SYS SB-THREAD SB-UNICODE)
Unhandled SB-INT:EXTENSION-FAILURE in thread #:
  Don't know how to REQUIRE sb-simd.
See also:
  The SBCL Manual, Variable *MODULE-PROVIDER-FUNCTIONS*
  The SBCL Manual, Function REQUIRE

Backtrace for: #
0: (SB-DEBUG::DEBUGGER-DISABLED-HOOK # # :QUIT T)
1: (SB-DEBUG::RUN-HOOK *INVOKE-DEBUGGER-HOOK* #)
2: (INVOKE-DEBUGGER #)
3: (ERROR SB-INT:EXTENSION-FAILURE :FORMAT-CONTROL "Don't know how to ~S ~A." 
:FORMAT-ARGUMENTS (REQUIRE "sb-simd") :REFERENCES ((:SBCL :VARIABLE 
*MODULE-PROVIDER-FUNCTIONS*) (:SBCL :FUNCTION REQUIRE)))
4: (REQUIRE "sb-simd" NIL)
5: (SB-KERNEL:%MAP-FOR-EFFECT-ARITY-1 # (("sb-aclrepl" . "SB-ACLREPL") 
("sb-bsd-sockets" . "SB-BSD-SOCKETS") ("sb-concurrency" . "SB-CONCURRENCY") 
("sb-cover" . "SB-COVER") ("sb-graph" . "SB-GRAPH") ("sb-grovel" . "SB-GROVEL") 
("sb-md5" . "SB-MD5") ("sb-posix" . "SB-POSIX") ("sb-queue" . "SB-QUEUE") 
("sb-rotate-byte" . "SB-ROTATE-BYTE") ("sb-simd" . "SB-SIMD") 
("sb-simple-streams" . "SB-SIMPLE-STREAMS") ...))
6: (GENERATE-DOCSTRINGS-TEXINFO "../../src/runtime/sbcl --core 
../../output/sbcl.core" :DOCSTRING-DIRECTORY "docstrings/")
7: ((LAMBDA NIL :IN "/<>/doc/manual/generate-texinfo.lisp"))
8: (SB-INT:SIMPLE-EVAL-IN-LEXENV (DESTRUCTURING-BIND (PROGRAM RUNTIME 
DOCSTRING-DIRECTORY) *POSIX-ARGV* (DECLARE (IGNORE PROGRAM)) 
(GENERATE-DOCSTRINGS-TEXINFO RUNTIME :DOCSTRING-DIRECTORY DOCSTRING-DIRECTORY) 
(EXPAND-VARIABLES) (GENERATE-EXTERNAL-FORMAT-TEXINFO)) #)
9: (EVAL-TLF (DESTRUCTURING-BIND (PROGRAM RUNTIME DOCSTRING-DIRECTORY) 
*POSIX-ARGV* (DECLARE (IGNORE PROGRAM)) (GENERATE-DOCSTRINGS-TEXINFO RUNTIME 
:DOCSTRING-DIRECTORY DOCSTRING-DIRECTORY) (EXPAND-VARIABLES) 
(GENERATE-EXTERNAL-FORMAT-TEXINFO)) 11 NIL)
10: ((LABELS SB-FASL::EVAL-FORM :IN SB-INT:LOAD-AS-SOURCE) (DESTRUCTURING-BIND 
(PROGRAM RUNTIME DOCSTRING-DIRECTORY) *POSIX-ARGV* (DECLARE (IGNORE PROGRAM)) 
(GENERATE-DOCSTRINGS-TEXINFO RUNTIME :DOCSTRING-DIRECTORY DOCSTRING-DIRECTORY) 
(EXPAND-VARIABLES) (GENERATE-EXTERNAL-FORMAT-TEXINFO)) 11)
11: ((LAMBDA (SB-KERNEL:FORM  :CURRENT-INDEX ) :IN 
SB-INT:LOAD-AS-SOURCE) (DESTRUCTURING-BIND (PROGRAM RUNTIME 
DOCSTRING-DIRECTORY) *POSIX-ARGV* (DECLARE (IGNORE PROGRAM)) 
(GENERATE-DOCSTRINGS-TEXINFO RUNTIME :DOCSTRING-DIRECTORY DOCSTRING-DIRECTORY) 
(EXPAND-VARIABLES) (GENERATE-EXTERNAL-FORMAT-TEXINFO)) :CURRENT-INDEX 11)
12: (SB-C::%DO-FORMS-FROM-INFO # 
# SB-C::INPUT-ERROR-IN-LOAD)
13: (SB-INT:LOAD-AS-SOURCE #>/doc/manual/generate-texinfo.lisp" {1005A40093}> :VERBOSE NIL 
:PRINT NIL :CONTEXT "loading")
14: ((LABELS SB-FASL::LOAD-STREAM-1 :IN LOAD) #>/doc/manual/generate-texinfo.lisp" {1005A40093}> NIL)
15: (SB-FASL::CALL-WITH-LOAD-BINDINGS # #>/doc/manual/generate-texinfo.lisp" {1005A40093}> NIL 
#>/doc/manual/generate-texinfo.lisp" 
{1005A40093}>)
16: (LOAD #>/doc/manual/generate-texinfo.lisp" {1005A40093}> :VERBOSE NIL 
:PRINT NIL :IF-DOES-NOT-EXIST :ERROR :EXTERNAL-FORMAT :DEFAULT)
17: ((FLET SB-IMPL::LOAD-SCRIPT :IN SB-IMPL::PROCESS-SCRIPT) #>/doc/manual/generate-texinfo.lisp" {1005A40093}>)
18: ((FLET SB-UNIX::BODY :IN SB-IMPL::PROCESS-SCRIPT))
19: ((FLET "WITHOUT-INTERRUPTS-BODY-11" :IN SB-IMPL::PROCESS-SCRIPT))
20: (SB-IMPL::PROCESS-SCRIPT "generate-texinfo.lisp")
21: (SB-IMPL::TOPLEVEL-INIT)
22: ((FLET SB-UNIX::BODY :IN SB-IMPL::START-LISP))
23: ((FLET "WITHOUT-INTERRUPTS-BODY-3" :IN SB-IMPL::START-LISP))
24: (SB-IMPL::%START-LISP)

unhandled condition in --disable-debugger mode, quitting
make[2]: *** [Makefile:91: docstrings] Error 1

Bug#1016044: deluge: Deluge floods syslog with error messages (builtins.KeyError: 'disk.num_blocks_cache_hits')

[Michel Casabona]

Package: deluge
Version: 2.0.3-3.1
Severity: normal
Tags: upstream

Hello, 

Deluge (gtk) is flooding syslog with groups of error messages at a rate of 72 
msgs/sec.
The last 3 messages: 

Jul 25 11:44:52 odysseus /usr/libexec/gdm-x-session[95923]:   File 
"/usr/lib/python3/dist-packages/deluge/core/core.py", line 361, in 
_update_session_cache_hit_ratio
Jul 25 11:44:52 odysseus /usr/libexec/gdm-x-session[95923]: 
self.session_status['disk.num_blocks_cache_hits'] / blocks_read
Jul 25 11:44:52 odysseus /usr/libexec/gdm-x-session[95923]: builtins.KeyError: 
'disk.num_blocks_cache_hits'

(this is +700Mb worth of logs a day, possibly duplicated in 
syslog/messages/user.log)

The bug is known and has been fixed upstream (release 2.0.4)

One bug report https://dev.deluge-torrent.org/ticket/3514

The fix 
https://github.com/deluge-torrent/deluge/commit/89189adb24321c3db6bfa816ec557d7d8367ba24

Thanks
-- 
Michel Casabona


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

Kernel: Linux 5.18.5 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: 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 deluge depends on:
ii  deluge-gtk  2.0.3-3.1
ii  python3 3.10.5-3
ii  python3-libtorrent  2.0.7-1

deluge recommends no packages.

deluge suggests no packages.

-- no debconf information

Bug#1016043: emacs-gtk: garbage in case of slow SSH connection

[Vincent Lefevre]

Package: emacs-gtk
Version: 1:27.1+1-3.1+b1
Severity: normal

I sometimes get garbage (e.g. 11;rgb:// or 41;351;0c)
either in the buffer or in the terminal when I run "emacs -nw" via a
slow SSH connection, actually a low latency (wifi via a 4G hotspot).

To reproduce: "/usr/bin/emacs-gtk -nw" then C-x C-c immediately after.

Reproducible with "/usr/bin/emacs-gtk -nw -Q".

This was supposed to be fixed upstream some years ago:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=12354

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

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

Versions of packages emacs-gtk depends on:
ii  emacs-bin-common 1:27.1+1-3.1+b1
ii  emacs-common 1:27.1+1-3.1
ii  libacl1  2.3.1-1
ii  libasound2   1.2.7.1-1
ii  libc62.33-7
ii  libcairo21.16.0-6
ii  libdbus-1-3  1.14.0-1
ii  libfontconfig1   2.13.1-4.4
ii  libfreetype6 2.12.1+dfsg-3
ii  libgdk-pixbuf-2.0-0  2.42.8+dfsg-1
ii  libgif7  5.2.1-2.5
ii  libglib2.0-0 2.72.3-1
ii  libgmp10 2:6.2.1+dfsg1-1
ii  libgnutls30  3.7.6-2
ii  libgpm2  1.20.7-10
ii  libgtk-3-0   3.24.34-1
ii  libharfbuzz0b2.7.4-1+b1
ii  libice6  2:1.0.10-1
ii  libjansson4  2.14-2
ii  libjpeg62-turbo  1:2.1.2-1
ii  liblcms2-2   2.12~rc1-2
ii  libm17n-01.8.0-4
ii  libotf1  0.9.16-3
ii  libpango-1.0-0   1.50.7+ds-1
ii  libpng16-16  1.6.37-5
ii  librsvg2-2   2.54.4+dfsg-1
ii  libselinux1  3.4-1
ii  libsm6   2:1.2.3-1
ii  libsystemd0  251.2-8
ii  libtiff5 4.4.0-3
ii  libtinfo66.3+20220423-2
ii  libx11-6 2:1.7.5-1
ii  libxext6 2:1.3.4-1
ii  libxfixes3   1:6.0.0-1
ii  libxml2  2.9.14+dfsg-1
ii  libxrender1  1:0.9.10-1.1
ii  zlib1g   1:1.2.11.dfsg-4

emacs-gtk recommends no packages.

Versions of packages emacs-gtk suggests:
ii  emacs-common-non-dfsg  1:27.1+1-2

-- no debconf information

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

Bug#1016042: haskell-inline-c FTBFS on 32bit: ghc runs forever

[Adrian Bunk]

Source: haskell-inline-c
Version: 0.9.1.6-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=haskell-inline-c=0.9.1.6-1

...
Running debian/hlibrary.setup build --builddir=dist-ghc
E: Build killed with signal TERM after 150 minutes of inactivity


There is a ghc process running at 100% CPU that is still running
after 2.5 hours.

Bug#1016041: libasan8: Should link to libatomic on armel

[Dmitry Shachnev]

Package: libasan8
Version: 12.1.0-7

Dear Maintainer,

Here is the test case:

(sid_armel-dchroot)mitya57@amdahl:~$ echo 'int main() { return 0; }' > test.c
(sid_armel-dchroot)mitya57@amdahl:~$ gcc test.c
(sid_armel-dchroot)mitya57@amdahl:~$ gcc -fsanitize=address test.c
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/12/libasan.so: undefined reference 
to `__atomic_store_8'
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/12/libasan.so: undefined reference 
to `__atomic_load_8'
collect2: error: ld returned 1 exit status

libasan.so seems to use symbols from libatomic, but is not linked to it:

(sid_armel-dchroot)mitya57@amdahl:~$ ldd 
/usr/lib/gcc/arm-linux-gnueabi/12/libasan.so
libdl.so.2 => /lib/arm-linux-gnueabi/libdl.so.2 (0xf7282000)
libpthread.so.0 => /lib/arm-linux-gnueabi/libpthread.so.0 (0xf724f000)
libm.so.6 => /lib/arm-linux-gnueabi/libm.so.6 (0xf71ae000)
libc.so.6 => /lib/arm-linux-gnueabi/libc.so.6 (0xf7045000)
libgcc_s.so.1 => /lib/arm-linux-gnueabi/libgcc_s.so.1 (0xf7014000)
/lib/ld-linux.so.3 (0xf788e000)

I have not seen it on architectures other than armel yet.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#858970: Still not in Debian

[Russ Allbery]

Sam Hartman  writes:

> In hopes of honoring this request, I just looked at the heimdal sources
> in debian.  I cannot find evidence of the includedir or include
> krb5.conf directives there even in 2022.
> Unless I'm missing something I still don't think it makes sense to add
> this to Debian without heimdal support.

Yes, agreed.  Heimdal upstream seems to have stalled out entirely on
issuing new releases, although there's still active development going into
their main branch.

includedir is supported in current Heimdal master (added in 2017), but so
far as I can tell it's never made it into a release.

-- 
Russ Allbery (r...@debian.org)  

Bug#1015181: libedata-cal-2.0-1: Process killed because of too much memory usage

[Simon McVittie]

On Sun, 17 Jul 2022 at 10:46:22 +0200, Michael Ott wrote:
> I want to read my calendar and tasks from my nextcloud server and there
> evolution crash.
..
> Jul 17 10:31:10 k-c13 kernel: [  549.943538] Isolated Web Co invoked 
> oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, 
> oom_score_adj=200
...
> ii  libglib2.0-0   2.73.2-1

I think this is an evolution-data-server bug triggered by using GLib
2.73.x from experimental. Fix in progress, workaround: use GLib from
unstable instead.

smcv

Bug#1013890: gmp-ecm breaks sagemath autopkgtest: lots of issues

[Paul Gevers]

Control: reassign 1013890 src:sagemath 9.5-4
Control: retitle 1013890 ABI breakage without SONAME bump

Hi,

On 05-07-2022 10:58, Tobias Hansen wrote:

And in the overview above that, it indicates a segfault:

sage/src/sage/libs/libecm.pyx  # Killed due to abort

sagemath probably just needs to be rebuilt against the new gmp-ecm. gmp-ecm 
should have done a library transition.


The rebuild happened for the flint transition and the package migrated. 
sagemath isn't involved anymore.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1015966: ci.debian.net: Please enable KVM support on all x86 runners

[Paul Gevers]

Hi Guilhem,

Thanks for your report. As this isn't a bug against debci, it would have 
been more appropriate to file it salsa against our ci.d.n configuration 
project: https://salsa.debian.org/ci-team/debian-ci-config/issues/


On 24-07-2022 16:53, Guilhem Moulin wrote:

Presumably all amd64 hosts actually do have KVM support but don't always
advertise the capability to the runner.


All amd64 (and i386) hosts apart from ci-worker13 are AWS VM's. I 
wouldn't be surprised if they don't support KVM.



Would it be possible to enable KVM support on all x86 runners?


Don't know.


Alternatively, is there a mechanism to
exclude specific runners for a given source package?


https://salsa.debian.org/ci-team/debci/-/issues/166 (not yet, and 
probably not real soon)



Also please consider pre-creating /dev/kvm on runners with KVM support
(this is normally taken care of by udev but can be done manually), that
way we can drop the ‘Restrictions: needs-root’ on our autopkgtests :-)


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1015976: Should vmm be removed?

[Pascal Volk]

On 7/24/22 18:05, Moritz Muehlenhoff wrote:
> Source: vmm
> Version: 0.6.2-2
> Severity: serious
> 
> Your package came up as a candidate for removal from Debian:
> - Still depends on Python 2
> - Last upload in 2017, removed from testing since 2019
> 
> If you disagree and want to continue to maintain this package,
> please just close this bug (and fix the open issues).
> 

Hi Moritz,

looks like Bernd Zeimetz has taken over the maintenance for vmm. :-)
https://salsa.debian.org/debian/vmm/-/commit/5f5c7ef13ed33c60fdb0d4eb140370d9593bce56

Bernd, that's why I've added you to CC.


Regards,
Pascal
-- 
Ubuntu is an ancient African word meaning “I can’t install Debian.”
 -- unknown

Bug#858970: Still not in Debian

[Sam Hartman]

In hopes of honoring this request, I just looked at the heimdal sources
in debian.  I cannot find evidence of the includedir or include
krb5.conf directives there even in 2022.
Unless I'm missing something I still don't think it makes sense to add
this to Debian without heimdal support.

Bug#1013222: Private headers

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

I would really love to know why Telegram developers require so many
private headers from Qt. They shouldn't be using them at all, and if
they really require some private part they need to work with upstream
to make it public API.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1016040: Transition Qt 6.3.1

[Patrick Franz]

Package: release.debian.org
Severity: normal
Usertags: transition
X-Debbugs-Cc: delta...@debian.org

Dear Release Team,

Qt 6.3.1 is packaged in experimental and hence needs a 
transition because of the usual ABI changes.

Here is the Ben file:

---
title = "Qt 6.3.1";

is_affected = .depends ~ /qt6-base-abi \(= 6\.2\.4\)/ | .depends ~ 
/qt6-base-abi \(= 6\.3\.1\)/;
is_good = .depends ~ /qt6-base-abi \(= 6\.3\.1\)/;
is_bad = .depends ~ /qt6-base-abi \(= 6\.2\.4\)/;
---

Thank you.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1004616: performous: FTBFS with ffmpeg 5.0

[Dan Bungert]

Dear Maintainer,

I did a test build using the version of performous in experimental on Sid and
Ubuntu Kinetic.  I found that it continues to have a const-related build
failure.

Upstream commit
https://github.com/performous/performous/pull/752/commits/80d5b08d34a97db16fe12f82e9060570087ef0f0
is a step in the right direction, but in this older codebase needed more.

Please see attached for a patch that fixes build of the version in experimental
with Sid and Ubuntu Kinetic.

-Dan
Description: constify AVCodec* for ffmpeg 5 compat
Origin:  https://github.com/performous/performous/pull/752/commits/80d5b08d34a97db16fe12f82e9060570087ef0f0
Author:  Dan Bungert 
Bug-Ubuntu:  https://bugs.launchpad.net/bugs/1982781
Bug-Debian:  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004616
Forwarded:   not-needed
Last-Update: 2022-07-25

Extended above commit to handle an additional const.
--- a/game/ffmpeg.cc
+++ b/game/ffmpeg.cc
@@ -96,10 +96,16 @@
 	if (avformat_find_stream_info(m_formatContext, nullptr) < 0) throw std::runtime_error("Cannot find stream information");
 	m_formatContext->flags |= AVFMT_FLAG_GENPTS;
 	// Find a track and open the codec
+#if (LIBAVFORMAT_VERSION_INT) >= (AV_VERSION_INT(59, 0, 100))
+	const
+#endif
 	AVCodec* codec = nullptr;
 	m_streamId = av_find_best_stream(m_formatContext, (AVMediaType)m_mediaType, -1, -1, , 0);
 	if (m_streamId < 0) throw std::runtime_error("No suitable track found");
 
+#if (LIBAVFORMAT_VERSION_INT) >= (AV_VERSION_INT(59, 0, 100))
+	const
+#endif
 #if (LIBAVCODEC_VERSION_INT) >= (AV_VERSION_INT(57,0,0))
 	AVCodec* pCodec = avcodec_find_decoder(m_formatContext->streams[m_streamId]->codecpar->codec_id);
 	AVCodecContext* pCodecCtx = avcodec_alloc_context3(pCodec);

Bug#1012143: Blocked by bug of r-cran-rstan

[Andreas Tille]

Control: block -1 by 1012219

The error

Error in dyn.load(file, DLLpath = DLLpath, ...) : 
  unable to load shared object '/usr/lib/R/site-library/rstan/libs/rstan.so':
  /usr/lib/R/site-library/rstan/libs/rstan.so: undefined symbol: 
_ZN3tbb8internal26task_scheduler_observer_v37observeEb
Calls:  ... lapply -> FUN -> loadNamespace -> library.dynam -> 
dyn.load

feeds the assumption that once r-cran-rstan is successfully build this issue
will most probably vanish.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#1016021: debhelper: Please change generated tmpfiles misc:Depends to systemd-standalone-tmpfiles | systemd-tmpfiles

[Ansgar]

On Mon, 25 Jul 2022 13:05:02 +0100 Mark Hindley wrote:
> It has been suggested that changing the dependency to
> 
>  systemd-standalone-tmpfiles | systemd-tmpfiles
> 
> would help the packaging system usually find the correct solution and reduce 
> the
> number of unexpected surprises users are reporting.

This change breaks debootstrap as expected:

+---
| W: Failure while installing base packages.  This will be re-attempted up to 
five times.
| W: See /tmp/u/unstable/debootstrap/debootstrap.log for details (possibly the 
package /var/cache/apt/archives/systemd-standalone-tmpfiles_251.3-1_amd64.deb 
is at fault)
+---

I hope this addresses the question for "evidence and rationale of this
concern" why I say this is problematic.

> With this change, on a systemd installation the dependency would already be
> satisfied and therefore noop for APT. For installations without systemd, be 
> that
> systems using other inits or in containers, APT would choose the standalone
> implementation.

You state this as a fact, but it is sadly false. See prior discussions
about systemd-shim which had similar problems and caused various
problems even after removal from the archive (because conffiles). (I'm
too lazy to look this up for another repeat of this argument, after all
it is your claim; I already wasted too much time on the test above.)

We also had the very same discussion about dependency ordering for
libpam-systemd (or default-logind these days). I don't see any
substantial difference here to handle it differently.

I don't think we should make dependencies more brittle by not following
the policy to list the preferred package first; exploring alternatives
can be done w/o doing so.

Ansgar

Bug#1016039: epiphany-browser: /var/log/messages WebKitNetworkProcess backtrace-like output while browsing with epiphany-browser

[Debian Live user]

Package: epiphany-browser
Version: 3.38.2-1+deb11u2
Severity: important
X-Debbugs-Cc: user9d...@gmail.com

Dear Maintainer,

   * What led up to the situation?
I was browsing the Internet like normal.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I tried:
rm -fr ~/.config/epiphany ~/.cache/epiphany ~/.local/share/epiphany 
~/.local/share/webkitgtk; epiphany-browser
   * What was the outcome of this action?
I'd still [eventually] get the backtrace output in /var/log/messages about 
WebKitNetworkProcess (spawned directly from the epiphany-browswer process).
   * What outcome did you expect instead?
That the /var/log/messages backtrace-like output wouldn't happen again :(


Here's a free sample-snippet of this /var/log/messages output while running 
epiphany-browser while browsing normally on the Internet:
(It just repeats itself 5x and keeps doing the same thing over time).

Jul 24 18:07:20 localhost WebKitNetworkProcess[137748]: 1   0x7f702326b26f
Jul 24 18:07:20 localhost WebKitNetworkProcess[137748]: 2   0x7f70231208da
Jul 24 18:07:20 localhost WebKitNetworkProcess[137748]: 3   0x7f70233e8dab
Jul 24 18:07:20 localhost WebKitNetworkProcess[137748]: 4   0x7f70233e909a
Jul 24 18:07:20 localhost WebKitNetworkProcess[137748]: 5   0x7f70233e937a
Jul 24 18:07:20 localhost WebKitNetworkProcess[137748]: 6   0x7f70219ecd20
Jul 24 18:07:20 localhost WebKitNetworkProcess[137748]: 7   0x7f7021a4dc56
Jul 24 18:07:20 localhost WebKitNetworkProcess[137748]: 8   0x7f7021a4d0ca
Jul 24 18:07:20 localhost WebKitNetworkProcess[137748]: 9   0x7f701e4bed6f 
g_main_context_dispatch
Jul 24 18:07:20 localhost WebKitNetworkProcess[137748]: 10  0x7f701e4bf118
Jul 24 18:07:20 localhost WebKitNetworkProcess[137748]: 11  0x7f701e4bf40b 
g_main_loop_run
Jul 24 18:07:20 localhost WebKitNetworkProcess[137748]: 12  0x7f7021a4d6a6 
WTF::RunLoop::run()
Jul 24 18:07:20 localhost WebKitNetworkProcess[137748]: 13  0x7f70233bcf16
Jul 24 18:07:20 localhost WebKitNetworkProcess[137748]: 14  0x7f701deadd0a 
__libc_start_main
Jul 24 18:07:20 localhost WebKitNetworkProcess[137748]: 15  0x40106a
Jul 24 18:08:15 localhost WebKitNetworkProcess[137748]: 1   0x7f702326b26f
Jul 24 18:08:15 localhost WebKitNetworkProcess[137748]: 2   0x7f70231208da
Jul 24 18:08:15 localhost WebKitNetworkProcess[137748]: 3   0x7f70233e8dab
Jul 24 18:08:15 localhost WebKitNetworkProcess[137748]: 4   0x7f70233e909a
Jul 24 18:08:15 localhost WebKitNetworkProcess[137748]: 5   0x7f70233e937a
Jul 24 18:08:15 localhost WebKitNetworkProcess[137748]: 6   0x7f70219ecd20
Jul 24 18:08:15 localhost WebKitNetworkProcess[137748]: 7   0x7f7021a4dc56
Jul 24 18:08:15 localhost WebKitNetworkProcess[137748]: 8   0x7f7021a4d0ca
Jul 24 18:08:15 localhost WebKitNetworkProcess[137748]: 9   0x7f701e4bed6f 
g_main_context_dispatch
Jul 24 18:08:15 localhost WebKitNetworkProcess[137748]: 10  0x7f701e4bf118
Jul 24 18:08:15 localhost WebKitNetworkProcess[137748]: 11  0x7f701e4bf40b 
g_main_loop_run
Jul 24 18:08:15 localhost WebKitNetworkProcess[137748]: 12  0x7f7021a4d6a6 
WTF::RunLoop::run()
Jul 24 18:08:15 localhost WebKitNetworkProcess[137748]: 13  0x7f70233bcf16
Jul 24 18:08:15 localhost WebKitNetworkProcess[137748]: 14  0x7f701deadd0a 
__libc_start_main
Jul 24 18:08:15 localhost WebKitNetworkProcess[137748]: 15  0x40106a
Jul 24 18:24:52 localhost WebKitNetworkProcess[137748]: 1   0x7f702326b26f
Jul 24 18:24:52 localhost WebKitNetworkProcess[137748]: 2   0x7f70231208da
Jul 24 18:24:52 localhost WebKitNetworkProcess[137748]: 3   0x7f70233e8dab
Jul 24 18:24:52 localhost WebKitNetworkProcess[137748]: 4   0x7f70233e909a
Jul 24 18:24:52 localhost WebKitNetworkProcess[137748]: 5   0x7f70233e937a
Jul 24 18:24:52 localhost WebKitNetworkProcess[137748]: 6   0x7f70219ecd20
Jul 24 18:24:52 localhost WebKitNetworkProcess[137748]: 7   0x7f7021a4dc56
Jul 24 18:24:52 localhost WebKitNetworkProcess[137748]: 8   0x7f7021a4d0ca
Jul 24 18:24:52 localhost WebKitNetworkProcess[137748]: 9   0x7f701e4bed6f 
g_main_context_dispatch
Jul 24 18:24:52 localhost WebKitNetworkProcess[137748]: 10  0x7f701e4bf118
Jul 24 18:24:52 localhost WebKitNetworkProcess[137748]: 11  0x7f701e4bf40b 
g_main_loop_run
Jul 24 18:24:52 localhost WebKitNetworkProcess[137748]: 12  0x7f7021a4d6a6 
WTF::RunLoop::run()
Jul 24 18:24:52 localhost WebKitNetworkProcess[137748]: 13  0x7f70233bcf16
Jul 24 18:24:52 localhost WebKitNetworkProcess[137748]: 14  0x7f701deadd0a 
__libc_start_main
Jul 24 18:24:52 localhost WebKitNetworkProcess[137748]: 15  0x40106a
Jul 24 20:46:24 localhost WebKitNetworkProcess[147709]: 1   0x7f40ebd1e26f
Jul 24 20:46:24 localhost WebKitNetworkProcess[147709]: 2   0x7f40ebbd38da
Jul 24 20:46:24 localhost WebKitNetworkProcess[147709]: 3   0x7f40ebe9bdab
Jul 24 20:46:24 localhost WebKitNetworkProcess[147709]: 4   0x7f40ebe9c09a
Jul 24 20:46:24 localhost WebKitNetworkProcess[147709]: 5   0x7f40ebe9c37a
Jul 24 20:46:24 localhost WebKitNetworkProcess[147709]: 6   0x7f40ea49fd20
Jul 24 20:46:24 

Bug#994212: ROM: r-cran-gprofiler: Obsolete package, replaced with r-cran-gprofiler2

[Andreas Tille]

Control: reassign -1 ftpmaster.debian.org
Control: retitle -1 ROM: r-cran-gprofiler: Obsolete package, replaced with 
r-cran-gprofiler2

Hi,

as per bug title this package should be removed from Debian since it
is obsolete and unmaintained.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#1006472: Upload to unstable?

[Roland Clobus]

Hello Fabio,

On 24/07/2022 23:00, Fabio Fantoni wrote:

Il 24/07/2022 22:12, Roland Clobus ha scritto:
would you consider to upload this fix to unstable? It is currently 
only in experimental.

...
I think however that within a few weeks with the next bugfixes they will 
be good enough to be able to migrate them to unstable.


Is it a problem to wait up to a few more weeks or I should upload this 
change to unstable faster?


No need to hurry. I now know that you are planning to bring the fix to 
unstable in a few weeks, when the issues are fixed.


I'm working together with Phil Hands on https://openqa.debian.net which 
contains automated testing. At the moment a Cinnamon image is not (yet) 
tested, but it could be possible to have a Cinnamon image with the 
packages from experimental (using apt-pinning) and some tests.

See e.g. the start-stop test for the GNOME apps:
https://openqa.debian.net/tests/65161
or the general tests of the live image:
https://openqa.debian.net/tests/overview?distri=debian=sid=20220711T17Z_sid=14

With kind regards,
Roland Clobus


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016021: debhelper: Please change generated tmpfiles misc:Depends to systemd-standalone-tmpfiles | systemd-tmpfiles

[Luca Boccassi]

On Mon, 25 Jul 2022 18:11:21 +0100 Mark Hindley 
wrote:
> Michael,
> 
> Thanks for this.
> 
> On Mon, Jul 25, 2022 at 04:08:28PM +0200, Michael Biebl wrote:
> > Am 25.07.22 um 14:05 schrieb Mark Hindley:
> > 
> > > It has been suggested that changing the dependency to
> > > 
> > >   systemd-standalone-tmpfiles | systemd-tmpfiles
> > > 
> > > would help the packaging system usually find the correct solution
and reduce the
> > > number of unexpected surprises users are reporting.
> > > 
> > > With this change, on a systemd installation the dependency would
already be
> > > satisfied and therefore noop for APT.
> > 
> > This is not correct. It would make the bootstrap phase more brittle
as
> > outlined by ansgar. So this is certainly a no-go.
> 
> I am afraid I can't find any detail of this beyond Ansgar's statement
of this as
> fact[1]. Could you point me to the evidence and rationale of this
concern,
> please?

It's very simple: the default is intentionally, and must remain, to
install the systemd package to provide those utilities, because that's
what gets the widest usage and the most testing. The alternatives are
provided as a courtesy, as optional alternatives for non-default use
cases, and are seldomly used and lightly tested.

> > I hate to repeat myself: add a Recommends or Depends on
> > systemd-standalone-tmpfiles to sysvinit-core to help apt choose the
right
> > solution for such non-standard configurations.
> 
> I also hate to repeat myself, but sysvinit-core makes no use of
tmpfiles,
> therefore to add the dependency there would be incorrect and an abuse
of the
> packaging system.

Dependencies can and are used to influence the behaviour of the
installed system all the time, it is not true that there must always be
a direct 1:1 mapping between a dependency and an artifact being
directly used. We have metapackages all over the places after all. But
even then, if you don't want that use a Recommends instead, or create a
new meta-package that you own and sets the preferences as you see fit,
or change the build scripts to use --include/--exclude, or have post-
build processing scripts to change the list of installed packages, and
so on. Or simply leave the systemd package installed, as by itself it
does nothing given the init system is not changed by simply having it
installed by itself, so there's no functional difference.

-- 
Kind regards,
Luca Boccassi


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

Bug#527397: [approx] Please add IPv6 support by default (inetd.conf change)

[Matt Taggart]

Here's an update on approx and IPv6:

* approx 5.4-1 (08 Dec 2013) first added the systemd socket files, but 
the postinst was still using update-inetd. This release also added an 
example xinetd conffile
* approx 5.7-3 removed the use of update-inetd in the postinst to enable 
the service. The patch included in this bug (and blocked by #24043) is 
no longer relevant.
* Users still using /etc/inetd.conf style inetd servers can add the tcp6 
entry themselves and that will work.
* (Most) users using the systemd socket files which use "ListenStream" 
will get IPv4 and IPv6 (unless BindIPv6Only is set)
* I don't know how xinetd will handle it (how does the provided example 
specify what port to listen on?)


So I think the spirit of the original wishlist bug "Please add IPv6 
support by default" is met by systemd doing that by default, and there 
are ways for enabling support on the other inetd servers.


So I think this can be closed, yay!

--
Matt Taggart
m...@lackof.org

Bug#1012981: libkiwix: ftbfs with GCC-12

[Kunal Mehta]

Hi,

On 6/16/22 08:11, Matthias Klose wrote:

In file included from /usr/include/xapian.h:44,
  from ../src/library.cpp:35:
/usr/include/xapian/version.h:29:2: error: #warning The C++ ABI version of 
compiler you are using does not exactly match [-Werror=cpp]
29 | #warning The C++ ABI version of compiler you are using does not 
exactly match
   |  ^~~
/usr/include/xapian/version.h:30:2: error: #warning that of the compiler used 
to build the library. If linking fails [-Werror=cpp]
30 | #warning that of the compiler used to build the library. If linking 
fails
   |  ^~~
/usr/include/xapian/version.h:31:2: error: #warning due to missing symbols, 
this is probably the reason why. [-Werror=cpp]
31 | #warning due to missing symbols, this is probably the reason why.
   |  ^~~
/usr/include/xapian/version.h:32:2: error: #warning The Xapian library was 
built with g++ 11.2.0 [-Werror=cpp]
32 | #warning The Xapian library was built with g++ 11.2.0
   |  ^~~
cc1plus: all warnings being treated as errors


This happens every GCC bump, so I think rather than asking for a binNMU 
of xapian we can just turn off -Werror in the libkiwix build.


-- Kunal

Bug#1015719: libc6-dev: Build glibc with latest packaged kernel version

[Alejandro Colomar]

Hi Aurelien,

On 7/25/22 19:39, Aurelien Jarno wrote:

On 2022-07-25 14:51, Alejandro Colomar wrote:

E.g., when one runs `apt-get upgrade`, if the kernel is upgraded,
update-libc-syscalls(1) would be called by apt-get as a post install script,
and libc macros would have the new syscall numbers provided by the new
kernel.  No need to wait glibc programmers to provide the backport.

Makes sense?


I don't think so. You do not want to modify files provided by a package.


Yeah, maybe it's better that the packagers run that script at packaging 
time, instead of apt-get at install time.  But, the script would be a 
good thing, I think, independently of who runs it.



Cheers,

Alex


--
Alejandro Colomar



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1015719: libc6-dev: Build glibc with latest packaged kernel version

[Aurelien Jarno]

On 2022-07-25 14:51, Alejandro Colomar wrote:
> Hi Florian!
> 
> On 7/25/22 12:38, Florian Weimer wrote:
> > * Alejandro Colomar via Libc-alpha:
> > 
> > > Is there an easy way to regenerate that header to get the tatest
> > > syscalls?  Maybe a command could be supplied so that users (or at
> > > least distributors) have it easy to regenerate them?  Maybe it already
> > > exists but it's not widely known?
> > 
> > I have recently backported the syscall-names.list updates to glibc 2.34,
> > but not glibc 2.33.  It's a simple backport.
> > 
> > We could perhaps enhance the glibc build process that it uses the union
> > of the known system call names and what's found in the kernel headers.
> 
> I guess it's a simple backport, since it's just adding the macros (I guess 0
> side effects).

In addition the goal is to switch to glibc 2.34 in the next weeks, not
that most problems related with the libpthread.so removal are
identified.

> But maybe providing a script, e.g., update-libc-syscalls(1), that
> distributions and users can call when updating a kernel to immediately
> backport syscalls to their system, would make it even simpler.
> 
> E.g., when one runs `apt-get upgrade`, if the kernel is upgraded,
> update-libc-syscalls(1) would be called by apt-get as a post install script,
> and libc macros would have the new syscall numbers provided by the new
> kernel.  No need to wait glibc programmers to provide the backport.
> 
> Makes sense?

I don't think so. You do not want to modify files provided by a package.

Regards
Aurelien

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


signature.asc
Description: PGP signature

Bug#1013447: gupnp-tools: gupnp-av-cp fails to detect upnp av serveur that kodi or vlc detects correctly

[Eric Valette]

On 25/07/2022 17:17, Andreas Henriksson wrote:

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



VLC and Kodi do detect them.


As kodi and VLC detect them on the same network at the same time and use 
also upnp-av serveur types (rendered, file serveur).


Anyway, the bug has vanished and way due to the upnp stack  has other 
using other upnp stack did work.


--eric

Bug#1016038: ITP: sysd-openrc -- Translator to convert systemd units to openrc scripts.

[Mark Hindley]

Package: wnpp
Severity: wishlist
Owner: Mark Hindley 
X-Debbugs-Cc: debian-de...@lists.debian.org, m...@kayg.org, 
ope...@packages.debian.org sysvi...@packages.debian.org

* Package name: sysd-openrc
  Version : Unversioned upstream
  Upstream Author : K Gopal Krishna  
* URL : https://salsa.debian.org/kayg/systemd-unit-translator
* License : BSD simplified 2 clause
  Programming Lang: Bash
  Description : Translator to convert systemd units to openrc scripts.

This was developed as part of the 2020 Google Summer of Code.

It is useful as part of exploring ways of deriving generic runlevel control
scripts for non-systemd init systems from unit files.

Mark

Bug#1014891: timeshift: New upstream release 22.06.3

[Steve M]

On Wed, 2022-07-13 at 17:32 -0400, Boyuan Yang wrote:
> Package: timeshift
> Version: 22.06.1-0.1
> Severity: normal
> X-Debbugs-CC: s...@swm1.com
> 
> Dear Debian timeshift package maintainers,
> 
> A new upstream release is available at
> https://github.com/linuxmint/timeshift/releases/tag/22.06.3 . Please
> consider packaging it.
> 
> Thanks,
> Boyuan Yang

Boyuan,

Thank you for this alert and for preparing 22.06.4 in the Salsa git
repo. I had a very busy two weeks when this happened but am
anticipating more time now to work on Timeshift updates. I see that
22.06.5 has been released so I will work on merging in that update.

Thanks
-Steve

Bug#1016037: bullseye-pu: package libreoffice/1:7.0.4-4+deb11u1

[Rene Engelhard]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
1) It seems the volution adress book is broken since 2015 due to a evolution
   change. Apparently noone noticed until 2021, where I backported the patch 
but then
   actually forgot to request a stable update
2) Croatia will join the Eurozone on 2023-01-01. I think we should
   prepare.
   TODO: After (or shortly before) 2023-01-01 we then can do a point release 
update
   to switch the default...

[ Impact ]
for 1) it stays broken.
for 2) EUR isn't supported in .hr locale

[ Tests ]
None, ttbomk.

[ Risks ]
for 2) trivial, and doesn't yet affect the default
for 1) it is a bigger patch but upstream since 2021. No regression known
and if it should regress, it can't get more broken than "broken".

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

(2) is not yet fixed in unstable, that will happen with the upload of
7.4.0 rc2 (or someting later) to it

[ Changes ]
See above. I just added the verbatim upstream commits.

Debdiff attached.

[ Other info ]
As said, for 2) we need a new update to switch the default later.

Regards,

Rene
diff --git a/changelog b/changelog
index bdd1d149..2baf8b2f 100644
--- a/changelog
+++ b/changelog
@@ -1,3 +1,12 @@
+libreoffice (1:7.0.4-4+deb11u2) stable; urgency=medium
+
+  * debian/patches/fix-e_book_client_connect_direct_sync-sig.diff:
+as name says; from libreoffice-7-2 branch
+  * debian/patches/hrk-euro.diff: add EUR to .hr i18n;
+add HRK<->EUR conversion rate to Calc and the Euro Wizard
+
+ -- Rene Engelhard   Mon, 25 Jul 2022 17:47:13 +0200
+
 libreoffice (1:7.0.4-4+deb11u1) bullseye-security; urgency=high
 
   * backport fixes from libreoffice-7-0 branch:
diff --git a/patches/fix-e_book_client_connect_direct_sync-sig.diff 
b/patches/fix-e_book_client_connect_direct_sync-sig.diff
new file mode 100644
index ..7aef915e
--- /dev/null
+++ b/patches/fix-e_book_client_connect_direct_sync-sig.diff
@@ -0,0 +1,417 @@
+From 3b9210195b8d2ac9861a1e607455ff9d16eb68fd Mon Sep 17 00:00:00 2001
+From: Julien Nabet 
+Date: Wed, 15 Dec 2021 22:45:47 +0100
+Subject: [PATCH] tdf#137101: fix e_book_client_connect_direct_sync signature
+ in Evolution
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+since it changed in 2015, see all details from tdf#137101
+Thank you to krumelmonster for having spotted this!
+
++ some cleanup to remove all eds_check_version calls
+and dependencies
+
+Change-Id: Iaf2437f8f5c04ab9674a380dac1dfb16ec8c7201
+Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126898
+Tested-by: Jenkins
+Tested-by: Caolán McNamara 
+Reviewed-by: Caolán McNamara 
+(cherry picked from commit 0661c796c767802c114441ad9a17fd0979d72ef4)
+Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126920
+---
+ connectivity/source/drivers/evoab2/EApi.cxx   |  54 +---
+ connectivity/source/drivers/evoab2/EApi.h |   2 +-
+ .../drivers/evoab2/NDatabaseMetaData.cxx  | 121 +
+ .../source/drivers/evoab2/NResultSet.cxx  | 125 +-
+ 4 files changed, 39 insertions(+), 263 deletions(-)
+
+diff --git a/connectivity/source/drivers/evoab2/EApi.cxx 
b/connectivity/source/drivers/evoab2/EApi.cxx
+index 12096bdade87..ebe710dedb57 100644
+--- a/connectivity/source/drivers/evoab2/EApi.cxx
 b/connectivity/source/drivers/evoab2/EApi.cxx
+@@ -23,16 +23,7 @@
+ static const char *eBookLibNames[] = {
+ "libebook-1.2.so.20", // evolution-data-server 3.33.2+
+ "libebook-1.2.so.19", // evolution-data-server 3.24+
+-"libebook-1.2.so.16",
+-"libebook-1.2.so.15",
+-"libebook-1.2.so.14", // bumped again (evolution-3.6)
+-"libebook-1.2.so.13", // bumped again (evolution-3.4)
+-"libebook-1.2.so.12", // bumped again
+-"libebook-1.2.so.10", // bumped again
+-"libebook-1.2.so.9",  // evolution-2.8
+-"libebook-1.2.so.5",  // evolution-2.4 and 2.6+
+-"libebook-1.2.so.3",  // evolution-2.2
+-"libebook.so.8"   // evolution-2.0
++"libebook-1.2.so.16"
+ };
+ 
+ typedef void (*SymbolFunc) ();
+@@ -71,19 +62,6 @@ static const ApiMap aCommonApiMap[] =
+ SYM_MAP( e_book_query_field_exists )
+ };
+ 
+-//< 3.6 api
+-static const ApiMap aOldApiMap[] =
+-{
+-SYM_MAP( e_book_get_addressbooks ),
+-SYM_MAP( e_book_get_uri ),
+-SYM_MAP( e_book_authenticate_user ),
+-SYM_MAP( e_source_group_peek_base_uri),
+-SYM_MAP( e_source_peek_name ),
+-SYM_MAP( e_source_get_property ),
+-SYM_MAP( e_source_list_peek_groups ),
+-SYM_MAP( e_source_group_peek_sources )
+-};
+-
+ //>= 3.6 api
+ static const ApiMap aNewApiMap[] =
+ {
+@@ -101,12 +79,6 @@ static const ApiMap aNewApiMap[] =
+ SYM_MAP( e_client_util_free_object_slist )
+ };
+ 
+-//== indirect read 

Bug#1016036: debhelper: t/Test/DH.pm should be included in the package

[Gioele Barabucci]

Package: debhelper
Version: 13.8

t/Test/DH.pm contains a test runner as well as various utilities for the 
testing of debhelper steps.


It would be nice that file were included in the package and installed so 
that other debhelper addons could use it by simply Build-Depending on 
debhelper instead of having to copy it.


Regards

--
Gioele Barabucci

Bug#1005821: please stop depending on bind9-host

[Sam Hartman]

control: retitle -1 Make krb5-config recommends
control: reassign -1 krb5-user

> "Michael" == Michael Tokarev  writes:

Michael> Um. I misfiled this bugreport actually. I started writing
Michael> it against krb5-user and realized the bind9-host dependency
Michael> comes from krb5-config not krb5-user.

Michael> And I think it is better to make krb5-CONFIG optional, not
Michael> krb5-USER.  Ie, for krb5-user, denote krb5-config from
Michael> Depends to Recommends.  Since actually, the only reason
Michael> krb5-config package is needed for krb5-user (and other krb5
Michael> stuff actually) is to *create* the initial configuration,
Michael> it does not need krb5-config package for runtime
Michael> operations, ie. krb5-config can be removed after
Michael> installation.

I agree with this analysis and will implement the change in a future
krb5 upload.
I wish I had looked at this bug in general  before the krb5 upload I
made Friday.


signature.asc
Description: PGP signature

Bug#1016021: debhelper: Please change generated tmpfiles misc:Depends to systemd-standalone-tmpfiles | systemd-tmpfiles

[Mark Hindley]

Michael,

On Mon, Jul 25, 2022 at 04:14:26PM +0200, Michael Biebl wrote:
> Fwiw, if there is no interest from the sysvinit camp to use the standalone
> versions, I'll probably drop them again in one of the next uploads.

Judging by the recent bugs on the issue, there is considerable interest within 
the
community in the standalone packages.

Mark

Bug#1016021: debhelper: Please change generated tmpfiles misc:Depends to systemd-standalone-tmpfiles | systemd-tmpfiles

[Mark Hindley]

Michael,

Thanks for this.

On Mon, Jul 25, 2022 at 04:08:28PM +0200, Michael Biebl wrote:
> Am 25.07.22 um 14:05 schrieb Mark Hindley:
> 
> > It has been suggested that changing the dependency to
> > 
> >   systemd-standalone-tmpfiles | systemd-tmpfiles
> > 
> > would help the packaging system usually find the correct solution and 
> > reduce the
> > number of unexpected surprises users are reporting.
> > 
> > With this change, on a systemd installation the dependency would already be
> > satisfied and therefore noop for APT.
> 
> This is not correct. It would make the bootstrap phase more brittle as
> outlined by ansgar. So this is certainly a no-go.

I am afraid I can't find any detail of this beyond Ansgar's statement of this as
fact[1]. Could you point me to the evidence and rationale of this concern,
please?

> I hate to repeat myself: add a Recommends or Depends on
> systemd-standalone-tmpfiles to sysvinit-core to help apt choose the right
> solution for such non-standard configurations.

I also hate to repeat myself, but sysvinit-core makes no use of tmpfiles,
therefore to add the dependency there would be incorrect and an abuse of the
packaging system.

In general, adding incorrect and spurious dependencies actually makes APT's job
more difficult.

And this proposal would have no benefit for users of other init systems.

And it would not help people who are finding systemd pulled into their minimal
containers[2].

Best wishes

Mark


[1]  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014805#24

[2]  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014805#35

Bug#1008816: ITP: kwin-bismuth -- KDE Plasma extension for tiling windows

[Blake Lee]

Okay sounds good, I'll get it moved over when I get some time.

I've been personally using and maintaining it for about 5 months now with no 
issues. It's the best solution I've found for a good tiling experience in KDE, 
previously I was using i3-gaps and picom, but there are a lot of minor 
inconveniences with this route.

Additionally my packaging was officially included in Ubuntu 22.04, with some 
changes to the debian files that I backported. I know there are at least some 
users of it as it's posted on bismuth's official GitHub. I've only ever 
received requests to update the package to a new upstream version.

On Mon, Jul 25, 2022, at 11:46 AM, Didier Raboud wrote:
> Le lundi, 25 juillet 2022, 17.35:43 h CEST Blake Lee a écrit :
> > As for the repo should I just mirror my current work from GitLab over to
> > Salsa?
> 
> If that's working well for you, I'd say yes; having team-maintained packages 
> in a common location makes most things easier; including common CI test 
> scripts, team-at-large changes, etc.
> 
> *Attachments:*
>  * signature.asc

Bug#1016027: fcitx5-bamboo FTBFS on 32bit

[Boyuan Yang]

Control: forwarded -1 https://github.com/fcitx/fcitx5-bamboo/issues/4

On Mon, 25 Jul 2022 16:46:32 +0300 Adrian Bunk  wrote:
> Source: fcitx5-bamboo
> Version: 1.0.0-2
> Severity: important
> Tags: ftbfs
> 
> https://buildd.debian.org/status/logs.php?pkg=fcitx5-bamboo=1.0.0-2
> 
> ...
> # command-line-arguments
> ./bamboo-c.go:162:30: type [1073741823]*_Ctype_char too large
> ./bamboo-c.go:194:30: type [1073741823]*_Ctype_char too large
> ./bamboo-c.go:222:28: type [1073741823]*_Ctype_char too large
> make[3]: *** [bamboo/CMakeFiles/bamboo-core.dir/build.make:91:
bamboo/bamboo-core.a] Error 2

Bug forwarded to upstream.

Thanks,
Boyuan Yang


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

Bug#1016011: ITP: pd-mapper -- Qualcomm PD mapper service

[IOhannes m zmölnig]

Am 25. Juli 2022 11:01:03 MESZ schrieb Arnaud Ferraris 
:
>Package: wnpp
>Severity: wishlist
>Owner: Arnaud Ferraris 
>X-Debbugs-Cc: debian-de...@lists.debian.org, aferra...@debian.org
>
>* Package name: pd-mapper
>  Version : 0.0+git20220208
>  Upstream Author : Bjorn Andersson 
>* URL : https://github.com/andersson/pd-mapper
>* License : BSD
>  Programming Lang: C
>  Description : Qualcomm PD mapper service
>
>'pd-mapper' is the reference implementation for Qualcomm's Protection
>Domain mapper service. It is required for userspace applications to
>access the various remote processors (Wi-Fi, modem, sensors...) on
>recent Qualcomm SoCs using the QRTR protocol.


Just to note: AFAIK all Debian packages that currently use the "pd-" prefix 
belong to the "pure-data" universe, just like Python packages have a "python-" 
prefix.
There is no formal "reservation" of that namespace, but I would expect quite 
some confusion if there are a few totally unrelated packages using the same 
naming scheme.

There's even an exusting pd-mapping package


So I humbly suggest to pick a name that reduces confusion, if possible.


mfh.her.fsr
IOhannes

mfh.her.fsr
IOhannes

Bug#892664: dpkg: Please add support for zstd (Zstandard) compressed packages

[Jan Kiszka]

Sorry to bother, but I heard rumors about potential progress, just found
no update here yet. Was there a decision made, or are there even changes
pending now?

Bug#1014805: Processed: Re: Bug#1014805: breaks users' systems

[Luca Boccassi]

On Sat, 23 Jul 2022 12:00:02 +0200 Adam Borowski 
wrote:
> On Fri, Jul 22, 2022 at 08:57:08PM +, Debian Bug Tracking System
wrote:
> > > severity -1 wishlist
> > Bug #1014805 [udev] udev: Please drop systemd from Depends
> > Severity set to 'wishlist' from 'critical'
> > > tags -1 wontfix
> > Bug #1014805 [udev] udev: Please drop systemd from Depends
> > Added tag(s) wontfix.
> > > close -1
> > Bug #1014805 [udev] udev: Please drop systemd from Depends
> > Marked Bug as done
> 
> And, thanks to this BTS ping-pong, this broken version has now
migrated to
> testing.  Big mighty thanks!  WTF...

First of all there was no migration this month as it can be trivially
seen on [0], and secondly there is nothing broken. Making wild
assertions does not help anybody.

[0] https://tracker.debian.org/pkg/systemd

-- 
Kind regards,
Luca Boccassi


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

Bug#1006179: clamav: please package 0.104.2

[Sebastian Andrzej Siewior]

On 2022-07-07 19:17:43 [+0300], Martin-Éric Racine wrote:
> Since the above bug report was filed, upstream has moved up to
> 0.105.0, while Debian is still at 0.103.6, so I was wondering what is
> going on?

The testing got a little bit easier since I had the same version
everywhere (old-stable/ stable/ unstable). 
Will try to make some time this or next week and package the current new
one for unstable.

> Martin-Éric

Sebastian

Bug#1016021: debhelper: Please change generated tmpfiles misc:Depends to systemd-standalone-tmpfiles | systemd-tmpfiles

[Luca Boccassi]

On Mon, 25 Jul 2022 16:08:28 +0200 Michael Biebl 
wrote:
> Am 25.07.22 um 14:05 schrieb Mark Hindley:
> 
> > It has been suggested that changing the dependency to
> > 
> >   systemd-standalone-tmpfiles | systemd-tmpfiles
> > 
> > would help the packaging system usually find the correct solution
and reduce the
> > number of unexpected surprises users are reporting.
> > 
> > With this change, on a systemd installation the dependency would
already be
> > satisfied and therefore noop for APT. 
> 
> This is not correct. It would make the bootstrap phase more brittle
as 
> outlined by ansgar. So this is certainly a no-go.

Indeed it would be wrong. Also the justification doesn't seem correct:
simply installing the 'systemd' binary does NOT switch the init system,
so it's difficult to see how it could 'significant problems' in and by
itself.

> I hate to repeat myself: add a Recommends or Depends on 
> systemd-standalone-tmpfiles to sysvinit-core to help apt choose the 
> right solution for such non-standard configurations.

On top of that, when building images debootstrap provides --include/--
exclude switches to also do that.

-- 
Kind regards,
Luca Boccassi


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

Bug#1008816: ITP: kwin-bismuth -- KDE Plasma extension for tiling windows

[Didier Raboud]

Le lundi, 25 juillet 2022, 17.35:43 h CEST Blake Lee a écrit :
> As for the repo should I just mirror my current work from GitLab over to
> Salsa?

If that's working well for you, I'd say yes; having team-maintained packages 
in a common location makes most things easier; including common CI test 
scripts, team-at-large changes, etc.

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

Bug#1008816: ITP: kwin-bismuth -- KDE Plasma extension for tiling windows

[Blake Lee]

Hello,

Thanks for the response. I'd say if John is interested in maintaining the 
package then it would definitely make sense to collaborate on it.

As for the repo should I just mirror my current work from GitLab over to Salsa?

Thanks,
Blake
On Mon, Jul 25, 2022, at 7:11 AM, Didier Raboud wrote:
> Hello there Blake,
> 
> I have heard about Bismuth and would like to see it in Debian.
> 
> Le samedi, 2 avril 2022, 06.42:10 h CEST Blake Lee a écrit :
> > * Package name: kwin-bismuth
> >   Version : 3.0.0
> > (...)
> >  I plan on maintaining this on my GitLab, but I would have
> >  no issue maintaining it with a team. I believe this is probably
> >  an area for the KDE Extras Team.
> 
> I see that John (cc'ed) has already started a Debian package on Salsa 
> (Debian's Gitlab instance): https://salsa.debian.org/jgoerzen/bismuth
> 
> Would it make sense for you two to collaborate on this?
> 
> I agree it would make sense in KDE Extras, so (as I had the rights), just 
> went 
> away and created a repo there:
> 
>   https://salsa.debian.org/qt-kde-team/extras/kwin-bismuth
> 
> I've invited John and you to it; don't hesitate to ask if you have questions!
> 
> >  I will need a sponsor to upload this package.
> 
> Happy to review and upload when that's Debian-ready!
> 
> *Attachments:*
>  * signature.asc

Bug#1015730: Please elaborate the move

[NG]

Hi,

On 2022-07-22 12:43, Geert Stappers wrote:
> [..]
> At https://sourceforge.net/projects/msc-generator/ is
>   NOTE! We have moved to
> https://gitlab.com/msc-generator/msc-generator Download releases,
> submit issues there.
> [..]
> I don't understand the strange relocation.
> [..]
> I could have understand
>   NOTE! We have moved to https://gitlab.com/msc-generator/msc-generator

The project was moved to GitLab. All interaction with users happens
there, like creating new issues, and releasing tarballs. The SF page is
kept for those who have bookmarked it earlier, with some discussions on
previously resolved issues that would have been not possible to copy
over to GL.

> [..]
> My misunderstanding might be that I can't see
> what is the leading git repository. Both, SF & GL, repos
> have recent changes in git.  It is "Where does the development happen"
> that I would like to have clarified. And I think other msc-generator
> users ought to know that.

Development happens at GL. The SF repo is mirroring official branches
(master, and debian/*), and is kept for the convenience of those who did
not yet rewrote their Git URLs.

Debian packaging starting with the upcoming 8.1-2 version uses the GL
URLs only.

BR,
Gábor Németh, .deb packager of msc-generator

Bug#1013447: gupnp-tools: gupnp-av-cp fails to detect upnp av serveur that kodi or vlc detects correctly

[Andreas Henriksson]

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

Hello Eric Valette,

On Thu, Jun 23, 2022 at 10:54:10PM +0200, Eric Valette wrote:
> Package: gupnp-tools
> Version: 0.10.3-1
> Severity: grave
> Justification: renders package unusable
> 

The gupnp-tools package consists of multiple tools. You're stating
the bug you report are making the package unusable, thus all tools are
supposedly completely unusable. Since you only actually briefly mention
gupnp-av-cp I'm going to downgrade severity right off the bat.

> starting gupnp-av-cp does not detect any DLNA (minidlnad, smartv TV,
> ...) content server on local network. 

Could you please give details on how these devices exposes themselves
on the network?

The gupnp-av-cp tool will only list Media Renderer and Media Servers.
That is devices exposing themselves as Type
urn:schemas-upnp-org:device:MediaRenderer:1 or
urn:schemas-upnp-org:device:MediaServer:1

See:
https://sources.debian.org/src/gupnp-tools/0.10.3-1/src/av-cp/main.c/#L112-L113
https://sources.debian.org/src/gupnp-tools/0.10.3-1/src/av-cp/main.c/#L40-L41

My Smart TV's for example exposes themselves as Type
urn:dial-multiscreen-org:device:dial:1
according to gupnp-universal-cp (also part of gupnp-tools package!).
They will thus be filtered out from being displayed in gupnp-av-cp.

If you want to test something which will expose itself as something that
will show up in gupnp-av-cp that could for example be gmediarender.

Things seems to work as expected to me, although DLNA/UPnP-AV itself and
proprietary vendors implementations of it are indeed quite confusing.

> 
> VLC and Kodi do detect them.

Regards,
Andreas Henriksson

Bug#1016034: PTS: lintian statuses very out of date

[Julian Gilbey]

Package: tracker.debian.org
Severity: normal

I'm looking at various packages on tracker.debian.org, and they say
things like "lintian reports NN errors and NN warnings", but when
opening the box, it says something along the lines of:
"Created: 2021-10-13  Last update: 2021-11-05 04:23".
It seems that the lintian status reports are no longer being updated.

Best wishes,

   Julian

Bug#939170: linux: does not suspend completely, locks up

[Jean-Michel Zwygart]

I updated a Thinkpad X1 Yoga (is detected as X1 Carbon 4th gen) from 
Buster to Bullseye a few months ago and after the update the shutdown 
reached status power off but didn't power off the machine. Tried 
different shutdown command options from terminal, with always the same 
result. As relatively new Linux Debian user with I fist thought that I 
did something wrong or that my Thinkpad had a problem. I installed other 
distro's and the problem disappeared... so I assumed it was a Debian issue.


But as I want to stay on Debian, I register to the Forum and fortunately 
found this post.


I modified blacklisted tpm, as mentioned by Frank Löffler, and the 
solution worked also for me!


Thanks a lot to Frank for his suggestion, and the others who confirmed 
this solution, that made me confident, as new user, to made the change.


Best regards

Jean-Michel

Bug#1016033: wireshark: process does not quit

[Erwan David]

Package: wireshark
Version: 3.6.6-1
Severity: normal

Starting wireshark with wireshark -r req.pcap

At end of use, click on "quit" in the File menu.
Window disappears, but process still here, blocked in a futex until I ^C in the 
launching terminal

% strace -p 29844
strace: Process 29844 attached
futex(0x7ffc5be8ec30, FUTEX_WAIT_PRIVATE, 0, NULL) = ? ERESTARTSYS (To be 
restarted if SA_RESTART is set)
--- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---
+++ killed by SIGINT +++



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

Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 wireshark depends on:
ii  wireshark-qt  3.6.6-1

wireshark recommends no packages.

wireshark suggests no packages.

-- no debconf information

Bug#1015719: libc6-dev: Build glibc with latest packaged kernel version

[Florian Weimer]

* Alejandro Colomar:

> Hi Florian!
>
> On 7/25/22 12:38, Florian Weimer wrote:
>> * Alejandro Colomar via Libc-alpha:
>> 
>>> Is there an easy way to regenerate that header to get the tatest
>>> syscalls?  Maybe a command could be supplied so that users (or at
>>> least distributors) have it easy to regenerate them?  Maybe it already
>>> exists but it's not widely known?
>> I have recently backported the syscall-names.list updates to glibc
>> 2.34,
>> but not glibc 2.33.  It's a simple backport.
>> We could perhaps enhance the glibc build process that it uses the
>> union
>> of the known system call names and what's found in the kernel headers.
>
> I guess it's a simple backport, since it's just adding the macros (I
> guess 0 side effects).
>
> But maybe providing a script, e.g., update-libc-syscalls(1), that
> distributions and users can call when updating a kernel to immediately 
> backport syscalls to their system, would make it even simpler.
>
> E.g., when one runs `apt-get upgrade`, if the kernel is upgraded,
> update-libc-syscalls(1) would be called by apt-get as a post install 
> script, and libc macros would have the new syscall numbers provided by
> the new kernel.  No need to wait glibc programmers to provide the
> backport.
>
> Makes sense?

Sure, that's a possibility.  We don't do this in Fedora because RPM does
not have delayed script execution, so it's hard to make sure everything
is installed properly when the processing script runs.

Thanks,
Florian

Bug#1014156: lintian: very-long-line-length-in-source-file for non-text source files

[Peter B]

Hi Axel,

I'm also seeing reports on qosmic
https://udd.debian.org/lintian/?qosmic

for file types qm & ts

ts> file qosmic_fr.qm
qosmic_fr.qm: Qt Translation file
ts>

ts> file qosmic_fr.ts
qosmic_fr.ts: XML 1.0 document, Unicode text, UTF-8 text, with very long lines 
(808)
ts>


qm files are binary.

ts files are XML, which often have long lines.



Cheers,
Peter

Bug#1016032: RM: fcitx5-configtool-data [all] -- NBS; No longer needed

[Boyuan Yang]

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

Dear Debian FTP Masters,

Please drop binary package fcitx5-configtool-data/5.0.14-3 (arch:all) from
Debian Unstable. https://packages.debian.org/unstable/fcitx5-configtool-data

This package was built out from src:fcitx5-configtool/5.0.14-3, but is now no
longer needed since the newer src:fcitx5-configtool/5.0.14-4 no longer builds
it out of the source package. The leftover package now blocks the testing
migration.

Thanks,
Boyuan Yang


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

Bug#1016021: debhelper: Please change generated tmpfiles misc:Depends to systemd-standalone-tmpfiles | systemd-tmpfiles

[Michael Biebl]

Am 25.07.22 um 16:08 schrieb Michael Biebl:

Am 25.07.22 um 14:05 schrieb Mark Hindley:


It has been suggested that changing the dependency to

  systemd-standalone-tmpfiles | systemd-tmpfiles

would help the packaging system usually find the correct solution and 
reduce the

number of unexpected surprises users are reporting.

With this change, on a systemd installation the dependency would 
already be
satisfied and therefore noop for APT. 


This is not correct. It would make the bootstrap phase more brittle as 
outlined by ansgar. So this is certainly a no-go.


I hate to repeat myself: add a Recommends or Depends on 
systemd-standalone-tmpfiles to sysvinit-core to help apt choose the 
right solution for such non-standard configurations.


Fwiw, if there is no interest from the sysvinit camp to use the 
standalone versions, I'll probably drop them again in one of the next 
uploads.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016021: debhelper: Please change generated tmpfiles misc:Depends to systemd-standalone-tmpfiles | systemd-tmpfiles

[Michael Biebl]

Am 25.07.22 um 14:05 schrieb Mark Hindley:


It has been suggested that changing the dependency to

  systemd-standalone-tmpfiles | systemd-tmpfiles

would help the packaging system usually find the correct solution and reduce the
number of unexpected surprises users are reporting.

With this change, on a systemd installation the dependency would already be
satisfied and therefore noop for APT. 


This is not correct. It would make the bootstrap phase more brittle as 
outlined by ansgar. So this is certainly a no-go.


I hate to repeat myself: add a Recommends or Depends on 
systemd-standalone-tmpfiles to sysvinit-core to help apt choose the 
right solution for such non-standard configurations.






OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016028: vagrant-libvirt: allow_existing for disks is broken with recent versions of libvirt

[anonym]

Package: vagrant-libvirt
Version: 0.9.0-1
Severity: normal
Tags: patch

Dear Maintainer,

Since libvirt 8.4.0 (or possibly earlier) the allow_existing option for disks 
has been broken in in vagrant-libvirt. The reason is that libvirt gives a 
slightly different error message when adding a disk that already exists than 
what vagrant-libvirt expects, leading to failure.

The attached patch fixes this, and is in fact already merged upstream, but not 
released yet. Would you mind applying it to the Debian package?

Cheers!From 1ed088924a1560375c353f91f79f4c1cd02de92d Mon Sep 17 00:00:00 2001
From: anonym 
Date: Wed, 8 Jun 2022 18:21:35 +
Subject: [PATCH] Fix allow_existing for disks against newer versions of
 libvirt. (#1507)

When running vagrant-libvirt on an up-to-date Debian unstable with
libvirt 8.4.0 the expected error message doesn't contain the full
path any more.
---
 lib/vagrant-libvirt/action/create_domain.rb | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/lib/vagrant-libvirt/action/create_domain.rb b/lib/vagrant-libvirt/action/create_domain.rb
index 7899424..9da82d3 100644
--- a/lib/vagrant-libvirt/action/create_domain.rb
+++ b/lib/vagrant-libvirt/action/create_domain.rb
@@ -151,9 +151,11 @@ module VagrantPlugins
 rescue Libvirt::Error => e
   # It is hard to believe that e contains just a string
   # and no useful error code!
-  msg = "Call to virStorageVolCreateXML failed: " +
-"storage volume '#{disk[:absolute_path]}' exists already"
-  if e.message == msg and disk[:allow_existing]
+  msgs = [disk[:name], disk[:absolute_path]].map do |name|
+"Call to virStorageVolCreateXML failed: " +
+"storage volume '#{name}' exists already"
+  end
+  if msgs.include?(e.message) and disk[:allow_existing]
 disk[:preexisting] = true
   else
 raise Errors::FogCreateDomainVolumeError,
-- 
2.36.1

Bug#1012987: libpodofo: ftbfs with GCC-12

[Mattia Rizzolo]

Hello,

On Mon, Jul 25, 2022 at 10:45:49PM +0900, yokota wrote:
> Hello Debian libpodofo maintainer,
> I maintain Debian Calibre which uses libpodofo.
> 
> I make FTBFS fix to Debian libpodofo at:
>   https://salsa.debian.org/debian/libpodofo/-/merge_requests/2
> 
> Please examine this merge request.

I saw it and I'm leaning towards rejecting that patch.

See also me asking upstream for a real patch here:
https://sourceforge.net/p/podofo/mailman/podofo-users/thread/Yt0dvCmE/ISNNwI3%40mapreri.org/#msg37684942

At the very least, I'd prefer fedora's patch better since it disable
specific tests and not the whole file the failing test lives in…
But I really don't like either.

-- 
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#1015085: texworks-manual: FTBFS: make[4]: *** [Makefile:66: index.ind] Error 1

[Hilmar Preuße]

Control: reassign -1 texlive-plain-generic
Control: tags -1 + pending

Am 16.07.2022 um 15:56 teilte Lucas Nussbaum mit:

Hi,


During a rebuild of all packages in sid, your package failed to build
on amd64.

It was a bug in TeX4HT. I have a patch for this and will upload fixed 
packages soon.


H.
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016027: fcitx5-bamboo FTBFS on 32bit

[Adrian Bunk]

Source: fcitx5-bamboo
Version: 1.0.0-2
Severity: important
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=fcitx5-bamboo=1.0.0-2

...
# command-line-arguments
./bamboo-c.go:162:30: type [1073741823]*_Ctype_char too large
./bamboo-c.go:194:30: type [1073741823]*_Ctype_char too large
./bamboo-c.go:222:28: type [1073741823]*_Ctype_char too large
make[3]: *** [bamboo/CMakeFiles/bamboo-core.dir/build.make:91: 
bamboo/bamboo-core.a] Error 2

Bug#1012987: libpodofo: ftbfs with GCC-12

[yokota]

Hello Debian libpodofo maintainer,
I maintain Debian Calibre which uses libpodofo.

I make FTBFS fix to Debian libpodofo at:
  https://salsa.debian.org/debian/libpodofo/-/merge_requests/2

Please examine this merge request.

--
YOKOTA

Bug#1016026: haskell-mono-traversable FTBFS on 32bit: test timeout

[Adrian Bunk]

Source: haskell-mono-traversable
Version: 1.0.15.3-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=haskell-mono-traversable=1.0.15.3-1

...
Running debian/hlibrary.setup test --builddir=dist-ghc --show-details=direct
E: Build killed with signal TERM after 150 minutes of inactivity


Running dist-ghc/build/test/test manually:

...
Containers
  Data.Map
difference
  +++ OK, passed 100 tests.
lookup
  +++ OK, passed 100 tests.
insert
  +++ OK, passed 100 tests.
delete
  +++ OK, passed 100 tests.
singletonMap
  +++ OK, passed 100 tests.
findWithDefault
  +++ OK, passed 100 tests.
insertWith
  +++ OK, passed 100 tests.
insertWithKey
  +++ OK, passed 100 tests.
insertLookupWithKey
  +++ OK, passed 100 tests.
adjustMap
  +++ OK, passed 100 tests.
adjustWithKey
  +++ OK, passed 100 tests.
updateMap
  +++ OK, passed 100 tests.
updateWithKey
  +++ OK, passed 100 tests.
updateLookupWithKey
  +++ OK, passed 100 tests.
alter
  +++ OK, passed 100 tests.
unionWith
  +++ OK, passed 100 tests.
unionWithKey
  +++ OK, passed 100 tests.
unionsWith
  +++ OK, passed 100 tests.
mapWithKey
  +++ OK, passed 100 tests.
omapKeysWith
  +++ OK, passed 100 tests.
  Data.IntMap
difference
  +++ OK, passed 100 tests.
lookup
  +++ OK, passed 100 tests.
insert
  +++ OK, passed 100 tests.
delete
  +++ OK, passed 100 tests.
singletonMap
  +++ OK, passed 100 tests.
findWithDefault
  +++ OK, passed 100 tests.
insertWith
  +++ OK, passed 100 tests.
insertWithKey
  +++ OK, passed 100 tests.
insertLookupWithKey
  +++ OK, passed 100 tests.
adjustMap
  +++ OK, passed 100 tests.
adjustWithKey
  +++ OK, passed 100 tests.
updateMap
  +++ OK, passed 100 tests.
updateWithKey
  +++ OK, passed 100 tests.
updateLookupWithKey
  +++ OK, passed 100 tests.
alter
  +++ OK, passed 100 tests.
unionWith
  +++ OK, passed 100 tests.
unionWithKey
  +++ OK, passed 100 tests.
unionsWith
  +++ OK, passed 100 tests.
mapWithKey
  +++ OK, passed 100 tests.
omapKeysWith
  +++ OK, passed 100 tests.
  Data.HashMap
difference
  +++ OK, passed 100 tests.
lookup
  +++ OK, passed 100 tests.
insert
  +++ OK, passed 100 tests.
delete
  +++ OK, passed 100 tests.
singletonMap
  +++ OK, passed 100 tests.
findWithDefault
  +++ OK, passed 100 tests.
insertWith
  +++ OK, passed 100 tests.
insertWithKey
  +++ OK, passed 100 tests.
insertLookupWithKey
  +++ OK, passed 100 tests.
adjustMap
  +++ OK, passed 100 tests.
adjustWithKey
  +++ OK, passed 100 tests.
updateMap
  +++ OK, passed 100 tests.
updateWithKey
  +++ OK, passed 100 tests.
updateLookupWithKey
  +++ OK, passed 100 tests.
alter
  +++ OK, passed 100 tests.
<-- no more output, and test runs with 100% CPU forever -->

Bug#1016025: ITP: mobian-keyring -- GPG keys for the Mobian package repository

[Arnaud Ferraris]

Package: wnpp
Severity: wishlist
Owner: Arnaud Ferraris 
X-Debbugs-Cc: debian-de...@lists.debian.org, aferra...@debian.org

* Package name: mobian-keyring
  Version : 20220725.0
  Upstream Author : Arnaud Ferraris 
* URL : https://salsa.debian.org/Mobian-team/mobian-keyring
* License : GPL
  Programming Lang: None (data only)
  Description : GPG keys for the Mobian package repository

Mobian is a Debian blend targeting mobile devices, such as phones and tablets.

This package provides the GnuPG public key(s) used to sign the Mobian package
repository, as well as the corresponding sources file and APT preferences as
recommended in https://wiki.debian.org/DebianRepository/UseThirdParty.

It will be maintained within the Mobian team.

Bug#1016024: deepin-boot-maker: please add support for riscv64

[Bo YU]

Source: deepin-boot-maker
Version: 5.7.6-1
Severity: wishlist
Tags: patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear deepin-boot-maker Maintainer,

The deepin-boot-maker package can be built on riscv64 arch with the 
patch attached, so could you please add riscv64 arch as a build target?
thanks.

-- 
Regards,
--
  Bo YU

diff -Nru deepin-boot-maker-5.7.8+dfsg/debian/control deepin-boot-maker-5.7.8+dfsg/debian/control
--- deepin-boot-maker-5.7.8+dfsg/debian/control	2022-05-30 11:41:27.0 +0800
+++ deepin-boot-maker-5.7.8+dfsg/debian/control	2022-05-30 13:08:27.0 +0800
@@ -26,7 +26,7 @@
 Vcs-Browser: https://salsa.debian.org/pkg-deepin-team/deepin-boot-maker
 
 Package: deepin-boot-maker
-Architecture: i386 amd64 armel armhf arm64 mipsel mips64el
+Architecture: i386 amd64 armel armhf arm64 mipsel mips64el riscv64
 Depends: ${shlibs:Depends}, ${misc:Depends}, p7zip-full, mtools, udisks2,
  syslinux [linux-amd64 linux-i386],
  syslinux-common [linux-amd64 linux-i386],genisoimage,dde-qt5integration


signature.asc
Description: PGP signature

Bug#929959: MAILFROM is supported by the last version of cron

[Georges Khaznadar]

Since a few weeks, I patched cron and set up a test, to ensure that the
variable MAILFROM is honored.

So bug #929959 can be closed now.

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#1015719: libc6-dev: Build glibc with latest packaged kernel version

[Alejandro Colomar]

Hi Florian!

On 7/25/22 12:38, Florian Weimer wrote:

* Alejandro Colomar via Libc-alpha:


Is there an easy way to regenerate that header to get the tatest
syscalls?  Maybe a command could be supplied so that users (or at
least distributors) have it easy to regenerate them?  Maybe it already
exists but it's not widely known?


I have recently backported the syscall-names.list updates to glibc 2.34,
but not glibc 2.33.  It's a simple backport.

We could perhaps enhance the glibc build process that it uses the union
of the known system call names and what's found in the kernel headers.


I guess it's a simple backport, since it's just adding the macros (I 
guess 0 side effects).


But maybe providing a script, e.g., update-libc-syscalls(1), that 
distributions and users can call when updating a kernel to immediately 
backport syscalls to their system, would make it even simpler.


E.g., when one runs `apt-get upgrade`, if the kernel is upgraded, 
update-libc-syscalls(1) would be called by apt-get as a post install 
script, and libc macros would have the new syscall numbers provided by 
the new kernel.  No need to wait glibc programmers to provide the backport.


Makes sense?

Cheers,

Alex

--
Alejandro Colomar



OpenPGP_signature
Description: OpenPGP digital signature

Bug#909200: Won't fix #909200

[Georges Khaznadar]

tag 909200 wontfix
thanks

I shall not fix this bug, as biebl's arguments are strong enough.

If I get no reply or suggestion about this bug report, I shall close it
in a few weeks.

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#1016023: pypi2deb : does not deal with proxy

[Picca Frédéric-Emmanuel]

Package: pypi2deb
Version: 3.20220721
Severity: normal
X-Debbugs-Cc: pi...@debian.org

Hello, In my institut there is https_proxy and 

py2dsp doesn not work behind there proxy. It seems that aihttp must be 
configure to use the system proxy.

https://docs.aiohttp.org/en/stable/client_advanced.html?highlight=proxy#proxy-support

Contrary to the requests library, it won’t read environment variables by 
default. But you can do so by passing trust_env=True into aiohttp.ClientSession 
constructor for extracting proxy configuration from HTTP_PROXY, HTTPS_PROXY, 
WS_PROXY or WSS_PROXY environment variables (all are case insensitive):

So can you set trust_env=True in the CLientSession instance

thanks for considering

Frederic


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

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

Versions of packages pypi2deb depends on:
ii  build-essential  12.9
ii  devscripts   2.22.2
ii  dh-python5.20220403
ii  python3  3.10.5-3
ii  python3-aiohttp  3.8.1-4+b1
ii  python3-debian   0.1.46
ii  python3-github   1.55-2
ii  python3-jinja2   3.0.3-1
ii  python3-redis4.3.4-3

Versions of packages pypi2deb recommends:
ii  python3-msgpack  1.0.3-1+b1

Versions of packages pypi2deb suggests:
pn  cython  
ii  cython3 0.29.30-1+b1
pn  pypy
pn  python-all-dev  
pn  python-nose 
pn  python-pytest   
ii  python-setuptools   44.1.1-1.2
ii  python3-all-dev 3.10.5-3
ii  python3-nose1.3.7-8
ii  python3-pytest  7.1.2-2
ii  python3-setuptools  59.6.0-1.2
ii  python3-sphinx  4.5.0-4

-- no debconf information

Bug#1016022: ITP: actions-for-nautilus -- A Gnome Files (Nautilus) extension for creating selection context menu entries that can execute arbitrary commands

[Martin Bartlett]

Package: wnpp
Severity: wishlist
Owner: Martin Bartlett 
X-Debbugs-Cc: debian-de...@lists.debian.org, martin.j.bartl...@gmail.com

* Package name: actions-for-nautilus
  Version : 1.0.0
  Upstream Author : Martin Bartlett 
* URL : https://github.com/bassmanitram/actions-for-nautilus
* License : Apache-2.0 license
  Programming Lang: Python, Javascript, HTML
  Description : A Gnome Files (Nautilus) extension for creating selection
context menu entries that can execute arbitrary commands

A "replacement" for the now-defunct filemanager/nautilus-actions project.

The extension supports many of the most commonly used features of the defunct
project, including:

* structuring context menu items for Nautilus File Manager selections including
nested sub menus filtering the displayed items based on:
* number of files in the selection,
* mimetypes of the selected files (matching and non-matching conditions
supported, as well as mimetype globs)
* basic filetypes of the selected files - e.g. 'file', 'directory', 'symbolic-
link' ... - (matching and non-matching conditions supported)
* execution of an arbitrary command/script when a menu item is activated

A configuration application by the name "Actions For Nautilus Configurator" is
installed into the desktop applications collection.
On first use of the configurator, if no existing configuration file is found,
the delivered sample configuration will be installed.

Maintenance should be trivial (it's a tiny extension) and I intend to provide
that myself (though collaborators are always welcome).

Translation is an issue - this is entirely in English at the moment.

I am looking for a sponsor, of course.

Bug#1016021: debhelper: Please change generated tmpfiles misc:Depends to systemd-standalone-tmpfiles | systemd-tmpfiles

[Mark Hindley]

Package: debhelper
Version: 13.8
Severity: normal

Niels,

Currently, debhelper generates

 systemd | systemd-tmpfiles

as the misc:Depends when a tmpfiles implementation is required.

However, that is causing significant problems for a number of users of
non-systemd systems and in containers when APT chooses the first option[1][2].

It has been suggested that changing the dependency to

 systemd-standalone-tmpfiles | systemd-tmpfiles

would help the packaging system usually find the correct solution and reduce the
number of unexpected surprises users are reporting.

With this change, on a systemd installation the dependency would already be
satisfied and therefore noop for APT. For installations without systemd, be that
systems using other inits or in containers, APT would choose the standalone
implementation.

Thanks and best wishes

Mark

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

Kernel: Linux 5.18.0-2-amd64 (SMP w/2 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 /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages debhelper depends on:
ii  autotools-dev20220109.1
ii  dh-autoreconf20
ii  dh-strip-nondeterminism  1.13.0-1
ii  dpkg 1.21.9
ii  dpkg-dev 1.21.9
ii  dwz  0.14-1
ii  file 1:5.41-4
ii  libdebhelper-perl13.8
ii  libdpkg-perl 1.21.9
ii  man-db   2.10.2-1
ii  perl 5.34.0-5
ii  po-debconf   1.0.21+nmu1

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  

-- no debconf information

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

[2]  https://bugs.debian.org/1014805

Bug#1016020: pinentry-gtk2: doesn't support ^U (control-U)

[Alejandro Colomar]

Package: pinentry-gtk2
Version: 1.2.0-2
Severity: important
Tags: upstream
X-Debbugs-Cc: alx.manpa...@gmail.com


Hi,

pinentry-gtk2 should support ^U to clear the password field,
as is common in many other places where a password is accepted
(login prompts, ...).

pinentry-tty added support for it ,
so maybe you can take a similar approach?

Cheers,

Alex


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

Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 pinentry-gtk2 depends on:
ii  libassuan0 2.5.5-4
ii  libc6  2.33-8
ii  libglib2.0-0   2.72.3-1
ii  libgpg-error0  1.45-2
ii  libgtk2.0-02.24.33-2
ii  libncursesw6   6.3+20220423-2
ii  libsecret-1-0  0.20.5-2
ii  libtinfo6  6.3+20220423-2

pinentry-gtk2 recommends no packages.

Versions of packages pinentry-gtk2 suggests:
pn  pinentry-doc  

-- no debconf information

Bug#1013554: golang-github-valyala-tcplisten: FTBFS: dh_auto_test: error: cd _build && go test -vet=off -v -p 8 github.com/valyala/tcplisten returned exit code 1

[Aloïs Micard]

Hello Mathias,

On 7/10/22 03:26, Mathias Gibbens wrote:

tags 1013554 + ipv6
thanks

   I've been unable to reproduce this locally, but have also seen
instances in the past where the buildds have difficulty running tests
that utilize IPv6.

   Maybe there's no "ip6-localhost" defined in /etc/hosts when the
package is built? Would it be worth tryin literal IP addresses for
localhost? I tested the following small patch locally and everything
still passes properly for me.



Your patch LGTM, we can try it and see if it works.
Do you want to submit a PR on salsa or should I backport it myself?



diff --git a/tcplisten_test.go b/tcplisten_test.go
index e7877d6..f2f04b6 100644
--- a/tcplisten_test.go
+++ b/tcplisten_test.go
@@ -37,8 +37,8 @@ func TestConfigBacklog(t *testing.T) {
  }
  
  func testConfig(t *testing.T, cfg Config) {

-   testConfigV(t, cfg, "tcp4", "localhost:10081")
-   testConfigV(t, cfg, "tcp6", "ip6-localhost:10081")
+   testConfigV(t, cfg, "tcp4", "127.0.0.1:10081")
+   testConfigV(t, cfg, "tcp6", "[::1]:10081")
  }
  
  func testConfigV(t *testing.T, cfg Config, network, addr string) {



Mathias


Cheers,

--
⢀⣴⠾⠻⢶⣦⠀  Aloïs Micard
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://creekorful.org
⠈⠳⣄  DA4A A436 9BFA E299 67CD E85B F733 E871 0859 FCD2


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016006: dbus-daemon: systemd | systemd-tmpfiles dependency not resolved gracefully on sysvinit systems

[Mark Hindley]

Michael,

Thanks for this.

On Mon, Jul 25, 2022 at 10:31:09AM +0200, Michael Biebl wrote:
> My recommendation in [1] was that sysvinit-core should add a Depends on
> systemd-standalone-tmpfiles (a Recommends would probably work fine as well).

There is an obvious reason: sysvinit-core itself does not depend on any
tempfiles implementation. Adding suprious dependencies to try to help APT find a
particular solution seems misplaced logic to me and is against the Policy.

Best wishes

Mark

Bug#1016006: dbus-daemon: systemd | systemd-tmpfiles dependency not resolved gracefully on sysvinit systems

[Mark Hindley]

Simon,

Thanks for this.

On Mon, Jul 25, 2022 at 09:22:34AM +0100, Simon McVittie wrote:
> Version 1.14.0-2 does not depend on systemd. It *does* depend
> on either systemd or systemd-tmpfiles, as a result of having
> /usr/lib/tmpfiles.d/dbus.conf (and will be one of increasingly many
> packages that do this).
> 
> systemd-tmpfiles is a virtual package representing any implementation
> of the tmpfiles.d API. You can get this on a sysvinit/sysv-rc system by
> installing the systemd-standalone-tmpfiles package.
 
> sysvinit/sysv-rc is a non-default init system for Debian, and the init
> system is a core component of the OS, so you can expect some upgrades
> with a non-default init system to be non-trivial.

Obviously the basic explanation here is perfrectly correct. However, as they
stand, the dependencies being generated are causing users significant difficulty
(judging by several bug reports in recent days with the same underlying cause)
and APT does not readily find the correct solution.

A suggestion to make the dependencies work better for everybody without manual
intervention has already been made[1], but rejected. Respectfully, I suggest
that is reconsidered. I see no downsides to making the dependency

 systemd-standalone-tmpfiles | systemd-tempfiles

On systems where systemd is installed, the dependency will be already satisfied
and therefore noop. On systems without systemd, apt install the standalone
implementation.

Are there any technical reasons why this is not a good technical solution?

Thanks.

Best wishes

Mark


[1]  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014805#15

Bug#1016019: ITP: libusbgx -- libusbgx is a C library encapsulating the kernel USB gadget-configfs

[Manuel Traut]

Package: wnpp
Severity: wishlist
Owner: Manuel Traut 
X-Debbugs-Cc: debian-de...@lists.debian.org, manuel.tr...@mt.com

* Package name: libusbgx
  Version : 0.2.0
  Upstream Author : Krzysztof Opasiak 
* URL : https://github.com/linux-usb-gadgets/libusbgx
* License : GPL, LGPL
  Programming Lang: C
  Description : libusbgx is a C library encapsulating the kernel USB 
gadget-configfs

It provides routines for creating and parsing USB gadget devices using
the configfs API. Currently, all USB gadget configfs functions that can
be enabled in kernel release 3.11 (Linux for Workgroups!) are supported.

The package is used in many embedded Linux based products.

I would need a sponsor and help for uploading the package.

Bug#1016018: ITP: rust-cid-npm -- CLI tool to generate CIDs without a full IPFS client

[Jochen Sprickerhof]

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

* Package name: rust-cid-npm
  Version : 0.0~git20200813.59cf068
  Upstream Author : Dan Shields 
* URL : https://gitlab.com/NukeManDan/rust_cid_npm
* License : MIT, Apache-2.0
  Programming Lang: Rust
  Description : CLI tool to generate CIDs without a full IPFS client

The intent of the tools is to be for CID generation/verification only. It is
not in any way an IPFS client.

The InterPlanetary File System (IPFS) is a protocol and peer-to-peer network
for storing and sharing data in a distributed file system. IPFS uses
content-addressing to uniquely identify each file in a global namespace
connecting all computing devices.[

A content identifier, or CID, is a label used to point to material in IPFS. It
doesn't indicate where the content is stored, but it forms a kind of address
based on the content itself. CIDs are short, regardless of the size of their
underlying content.

The package will be maintained by Jochen Sprickerhof 
at https://salsa.debian.org/debian/rust_cid_npm

Bug#1008816: ITP: kwin-bismuth -- KDE Plasma extension for tiling windows

[Didier Raboud]

Hello there Blake,

I have heard about Bismuth and would like to see it in Debian.

Le samedi, 2 avril 2022, 06.42:10 h CEST Blake Lee a écrit :
> * Package name: kwin-bismuth
>   Version : 3.0.0
> (...)
>  I plan on maintaining this on my GitLab, but I would have
>  no issue maintaining it with a team. I believe this is probably
>  an area for the KDE Extras Team.

I see that John (cc'ed) has already started a Debian package on Salsa 
(Debian's Gitlab instance): https://salsa.debian.org/jgoerzen/bismuth

Would it make sense for you two to collaborate on this?

I agree it would make sense in KDE Extras, so (as I had the rights), just went 
away and created a repo there:

  https://salsa.debian.org/qt-kde-team/extras/kwin-bismuth

I've invited John and you to it; don't hesitate to ask if you have questions!

>  I will need a sponsor to upload this package.

Happy to review and upload when that's Debian-ready!

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

Bug#1014374: tootle: Tootle only remembers 4 accounts (5th acct can be added but is lost)

[anonymous coward]

Package: tootle
Followup-For: Bug #1014374
X-Debbugs-Cc: debbug.1014...@sideload.33mail.com

I should also mention that it’s important that tootle uses the
XDG_CONFIG_HOME variable when referencing the config file. If not, and
the config file path is hardcoded to include a directory that the user
has converted into a symbolic link (e.g. ~/.config/), that’s one
scenario that will break access to that file within a firejail
environment.

So in short, it’s still feasible that there is a tootle bug here.
Certainly the man page should specify whether the XDG_CONFIG_HOME
variable is used and otherwise how the user can control the path to
the config file.

Bug#1014374: tootle: actually there is no account limit

[anonymous coward]

Package: tootle
Followup-For: Bug #1014374
X-Debbugs-Cc: debbug.1014...@sideload.33mail.com
Control: block 1014374 by 1016015
Control: severity 1014374 minor
Control: retitle 1014374 Accounts cannot be added when running in Firejail
Control: summary 1014374 This is possibly not a bug in tootle. It may be 
strictly a Firejail bug.

Tootle was likely running within a Firejail sandbox when this bug was
noticed. Considering another app (toot) has a very similar problem
when running in Firejail, it’s more likely that firejail is preventing
config files from being updated.

As an extra test, I ran tootle outside of firejail and was able to add
more accounts.

Bug#1015719: libc6-dev: Build glibc with latest packaged kernel version

[Florian Weimer]

* Alejandro Colomar via Libc-alpha:

> Is there an easy way to regenerate that header to get the tatest
> syscalls?  Maybe a command could be supplied so that users (or at
> least distributors) have it easy to regenerate them?  Maybe it already
> exists but it's not widely known?

I have recently backported the syscall-names.list updates to glibc 2.34,
but not glibc 2.33.  It's a simple backport.

We could perhaps enhance the glibc build process that it uses the union
of the known system call names and what's found in the kernel headers.

Thanks,
Florian

Bug#1013058: uncalled: ftbfs with GCC-12

[Nilesh Patra]

close -1

Can't repro.
Builds fine as seem on salsa CI as well, closing.

https://salsa.debian.org/med-team/uncalled/-/jobs/3035453

On Thu, 16 Jun 2022 12:14:39 + Matthias Klose  wrote:
> Package: src:uncalled
> Version: 2.2+ds1-1
> Severity: normal
> Tags: sid bookworm
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-12
> 
> [This bug is targeted to the upcoming bookworm release]
> 
> Please keep this issue open in the bug tracker for the package it
> was filed for.  If a fix in another package is required, please
> file a bug for the other package (or clone), and add a block in this
> package. Please keep the issue open until the package can be built in
> a follow-up test rebuild.
> 
> The package fails to build in a test rebuild on at least amd64 with
> gcc-12/g++-12, but succeeds to build with gcc-11/g++-11. The
> severity of this report will be raised before the bookworm release.
> 
> The full build log can be found at:
> http://qa-logs.debian.net/2022/06/09/gcc12/uncalled_2.2+ds1-1_unstable_gcc12.log
> The last lines of the build log are at the end of this report.
> 
> To build with GCC 11, either set CC=gcc-11 CXX=g++-11 explicitly,
> or install the gcc, g++, gfortran, ... packages from experimental.
> 
>   apt-get -t=experimental install g++ 
> 
> Common build failures are new warnings resulting in build failures with
> -Werror turned on, or new/dropped symbols in Debian symbols files.
> For other C/C++ related build failures see the porting guide at
> http://gcc.gnu.org/gcc-11/porting_to.html
> 
> GCC 11 defaults to the GNU++17 standard.  If your package installs
> header files in /usr/include, please don't work around C++17 issues
> by choosing a lower C++ standard for the package build, but fix these
> issues to build with the C++17 standard.
> 
> [...]
> creating build/temp.linux-x86_64-3.9/src
> x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g 
> -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat 
> -Werror=format-security -g -fwrapv -O2 -g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -DPYBIND 
> -I./submods -I/usr/include/hdf5/serial -I/usr/include/fast5/ -I/usr/include/ 
> -I/usr/lib/python3/dist-packages/pybind11/include -I/usr/include/python3.9 -c 
> src/chunk.cpp -o build/temp.linux-x86_64-3.9/src/chunk.o -std=c++11 -O3
> x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g 
> -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat 
> -Werror=format-security -g -fwrapv -O2 -g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -DPYBIND 
> -I./submods -I/usr/include/hdf5/serial -I/usr/include/fast5/ -I/usr/include/ 
> -I/usr/lib/python3/dist-packages/pybind11/include -I/usr/include/python3.9 -c 
> src/client_sim.cpp -o build/temp.linux-x86_64-3.9/src/client_sim.o -std=c++11 
> -O3
> x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g 
> -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat 
> -Werror=format-security -g -fwrapv -O2 -g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -DPYBIND 
> -I./submods -I/usr/include/hdf5/serial -I/usr/include/fast5/ -I/usr/include/ 
> -I/usr/lib/python3/dist-packages/pybind11/include -I/usr/include/python3.9 -c 
> src/event_detector.cpp -o build/temp.linux-x86_64-3.9/src/event_detector.o 
> -std=c++11 -O3
> x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g 
> -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat 
> -Werror=format-security -g -fwrapv -O2 -g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -DPYBIND 
> -I./submods -I/usr/include/hdf5/serial -I/usr/include/fast5/ -I/usr/include/ 
> -I/usr/lib/python3/dist-packages/pybind11/include -I/usr/include/python3.9 -c 
> src/event_profiler.cpp -o build/temp.linux-x86_64-3.9/src/event_profiler.o 
> -std=c++11 -O3
> x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g 
> -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat 
> -Werror=format-security -g -fwrapv -O2 -g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -DPYBIND 
> -I./submods -I/usr/include/hdf5/serial -I/usr/include/fast5/ -I/usr/include/ 
> -I/usr/lib/python3/dist-packages/pybind11/include -I/usr/include/python3.9 -c 
> src/fast5_reader.cpp -o build/temp.linux-x86_64-3.9/src/fast5_reader.o 
> -std=c++11 -O3
> In file included from src/read_buffer.hpp:30,
>  from src/fast5_reader.hpp:31,
>  from src/fast5_reader.cpp:26:
> /usr/include/fast5/hdf5_tools.hpp: In member function ‘void 
> hdf5_tools::detail::Reader::operator()(hid_t, const std::string&, 
> 

Bug#1016015: firejail: The --read-write option fails to enable file mods to persist after the sandbox is gone

[anonymous coward]

Package: firejail
Version: 0.9.64.4-2
Severity: important
X-Debbugs-Cc: debbug.firej...@sideload.33mail.com
Control: affects 1014374 + tootle

The command tootle was first executed outside firejail to establish a
working config file. This was motivated to work around bug
1015816. After tootle proved to function outside of firejail, it was
relaunched within firejail as follows:

  $ firejail --net=vnet0 --dns="$(ip address show dev vnet0 | awk 
'/inet\>/{gsub(/[/].*/,""); print $2 }')"\
 --env=XDG_CONFIG_HOME="$HOME"/my_config_files\
 --whitelist="$(readlink 
$HOME/.config)"com.github.bleakgrey.tootle/accounts.json\
 --noblacklist="$(readlink 
$HOME/.config)"com.github.bleakgrey.tootle/accounts.json\
 --read-write="$(readlink 
$HOME/.config)"com.github.bleakgrey.tootle/accounts.json\
 tootle

$HOME/.config is a symblic link to "$HOME"/my_config_files, and the
above configuration is crafted to ensure that firejail receives no
references to a symbolic file or directory.

Tootle was able to read the config file and make use of it within
firejail. Tootle was also able to update the config file during that
session, proven by its ability to add new accounts and interact with
them. But when the session ended, the config file updates were not
persistent and new accounts were lost.

Note that “tootle” and “toot” (mentioned in bug 1015816) are two
completely different applications, though they both serve the same
purpose.  Also note that bug 1015816 is very similar. The difference
is that in bug 1015816 the config file cannot be created, while the
bug herein reports that modifications to an existing config file do
not persist across sessions.  The bug herein may boil down to the same
bug affecting the same code as 1015816 (investigation needed).

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

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

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

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

firejail suggests no packages.

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

-- no debconf information

Bug#1015920: RFS: picklecast/1.0.2 [ITP] -- Screenshare receiver

[Bastian Germann]

On Sat, 23 Jul 2022 18:36:16 -0500 Evan  wrote:

Changes since the last upload:

  picklecast (1.0.2-1) unstable; urgency=low
  .
* source package automatically created by stdeb 0.10.0


Using the standard Debian tool "dh_make" for creating a source package would
have hinted you to have "Closes: #1015834" in your changelog entry.
Also, we do not care which tool you used to do that as long as it is correct.
So please replace the line with "Initial release (Closes: #1015834)".

What is that adapter-latest.js file in debian/copyright?

Please separate the Copyright info from the license text in debian/copyright.

Bug#1012096: RFS: tractor/3.14-1 [ITP] -- Setup an onion routing proxy

[دانیال بهزادی]

Control: tags -1 -moreinfo

Is this doing the job?
Danial Behzadi