Bug#996955: task-desktop silently pulls in task-desktop-gnome via Recommends

[Fabian Greffrath]

Am 21.10.2021 21:05, schrieb Brian Potkin:

Fortunately, not selecting it isn't of any consequence. A user gets
what else is chosen.


I don't consider it "fortunate", it is inconsistent that having that 
choice selected or not does not make a difference as long as any other 
choice is selected. And that having that choice selected but none of the 
others will indeed install one of the others.



No, that is not the case. Selecting "Desktop Environment" only will
have the effect of selecting the default desktop. This could be Xfce,
which is not the first one in the list.


Yes, right, that's on non-amd64/non-i386. That's even more confusing, 
that selecting the generic choice but not explicitly selecting any of 
the choices in the list will implicitly install the third choice in that 
list.


 - Fabian

Bug#993948: kernel/amd64: system hang on HPE ProLiant BL460c Gen9

[YunQiang Su]

Claudio Kuenzler  于2021年10月22日周五 下午1:18写道：
>
> Also look at the following links and compare. Might be related or even the 
> same as you are seeing:
>
> https://www.claudiokuenzler.com/blog/1125/debian-11-bullseye-boot-freeze-kernel-panic-hp-proliant-dl380
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898336
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995773
>

I built kernel by myself (5.14.12), same version as the current debian sid one.
   in fact 5.14.14 is also tested.
It won't trigger this problem.
And I make sure that hpwdt module is loaded.

No idea why Debian's kernel cannot work.

>
> On Thu, Oct 21, 2021 at 10:42 AM Yunqiang Su  wrote:
>>
>> On Fri, 10 Sep 2021 09:40:41 +0800 YunQiang Su  wrote:
>> > Yunqiang Su  于2021年9月9日周四 上午11:11写道：
>> > >
>> > >
>> > > On Wed, 8 Sep 2021 20:53:27 +0800 YunQiang Su  wrote:
>> > > > Package: src:linux
>> > > > Version: 5.10
>> > > >
>> > > > After upgrade to bullseyes' kernel, the system always hang after about 
>> > > > 10 min
>> > > > with an error from IML log
>> > > >
>> > > > An Unrecoverable System Error (NMI) has occurred (Service Information:
>> > > > 0x0008, 0x8948)
>> > > >
>> > > > Kernel 5.14 from experimental also has this problem.
>> > > > Kernel 4.19 works fine.
>> > > > Fedora 34 seems to be working well.
>> > >
>> > > This is the output of dmesg and lspci from both Fedora 34 and Debian 
>> > > bullseye.
>> > > Wish they are useful.
>> > >
>> >
>> > Finally, we find the problem:
>> >
>> > https://github.com/torvalds/linux/commit/8343b1f8b97ac016150c8303f95b63b20b98edf8
>> > https://github.com/torvalds/linux/commit/65161c35554f7135e6656b3df1ce2c500ca0bdcf
>> >
>> > In the first patch:
>> >They thought `err' is not used at all, and removed it.
>> > In the second patch:
>> >They add it back and a wrong value "-EINVAL" is given.
>> >
>> > Better KPI got.
>> >
>>
>> The NICs can be detected now, while the machine continue to hang…
>> 4.19.y works fine, while 5.10, 5.14 cannot.
>>
>> I think that we need more dig.
>>
>> > > >
>> > > > --
>> > > > YunQiang Su
>> > > >
>> > > >
>> >
>> >
>> >
>> > --
>> > YunQiang Su
>> >
>> >
>>


-- 
YunQiang Su

Bug#996993: ITP: biojava5-live -- Java API to biological data and applications (version 5)

[Pierre Gruet]

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

* Package name: biojava5-live
  Version : 5.4.0
  Upstream Author : BioJava Developers 
* URL : https://www.biojava.org/
* License : LGPL-2.1
  Programming Lang: Java
  Description : Java API to biological data and applications (version 5)

This package presents the Open Source Java API to biological databases
and a series of mostly sequence-based algorithms.

BioJava is an open-source project dedicated to providing a Java framework
for processing biological data. It includes objects for manipulating
sequences, file parsers, server support, access to BioSQL
and Ensembl databases, and powerful analysis and statistical routines
including a dynamic programming toolkit.

This is the version 5 of biojava, which brings several changes compared to
version 4, packaged in biojava4-live.
It will be maintained by the Debian-med team.

Bug#993948: kernel/amd64: system hang on HPE ProLiant BL460c Gen9

[Claudio Kuenzler]

Also look at the following links and compare. Might be related or even the
same as you are seeing:

https://www.claudiokuenzler.com/blog/1125/debian-11-bullseye-boot-freeze-kernel-panic-hp-proliant-dl380
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898336
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995773


On Thu, Oct 21, 2021 at 10:42 AM Yunqiang Su  wrote:

> On Fri, 10 Sep 2021 09:40:41 +0800 YunQiang Su  wrote:
> > Yunqiang Su  于2021年9月9日周四 上午11:11写道：
> > >
> > >
> > > On Wed, 8 Sep 2021 20:53:27 +0800 YunQiang Su 
> wrote:
> > > > Package: src:linux
> > > > Version: 5.10
> > > >
> > > > After upgrade to bullseyes' kernel, the system always hang after
> about 10 min
> > > > with an error from IML log
> > > >
> > > > An Unrecoverable System Error (NMI) has occurred (Service
> Information:
> > > > 0x0008, 0x8948)
> > > >
> > > > Kernel 5.14 from experimental also has this problem.
> > > > Kernel 4.19 works fine.
> > > > Fedora 34 seems to be working well.
> > >
> > > This is the output of dmesg and lspci from both Fedora 34 and Debian
> bullseye.
> > > Wish they are useful.
> > >
> >
> > Finally, we find the problem:
> >
> >
> https://github.com/torvalds/linux/commit/8343b1f8b97ac016150c8303f95b63b20b98edf8
> >
> https://github.com/torvalds/linux/commit/65161c35554f7135e6656b3df1ce2c500ca0bdcf
> >
> > In the first patch:
> >They thought `err' is not used at all, and removed it.
> > In the second patch:
> >They add it back and a wrong value "-EINVAL" is given.
> >
> > Better KPI got.
> >
>
> The NICs can be detected now, while the machine continue to hang…
> 4.19.y works fine, while 5.10, 5.14 cannot.
>
> I think that we need more dig.
>
> > > >
> > > > --
> > > > YunQiang Su
> > > >
> > > >
> >
> >
> >
> > --
> > YunQiang Su
> >
> >
>
>

Bug#996662: Additional information

[debian-testing]

I checked a few other packages quickly. It seems like evolution email client 
has no apparmor profile. Thunderbird mail client has an apparmor profile and 
the symlink works, but the apparmor profile seems to be including 
/etc/apparmor.d/abstractions/ubuntu-helpers which seems to provide symlink 
support, but also has security warnings.

I also tried following as described in the qtox documentation in 
/etc/apparmor.d/tunables/usr.bin.qtox.
"Create /etc/apparmor.d/tunables/usr.bin.qtox.d/local file to append values 
as..."

However, apparmor failed to load the new profile saying that variable 
"qtox_additional_rw_dirs" was already created. Changing 
/etc/apparmor.d/tunables/usr.bin.qtox partially worked, the profile was loaded, 
but all history was gone from qtox. I also was able to create a new profile, 
but all history was lost between sessions.

As a last resort, I tried a bind mount, and that works. The steps are below. I 
make the original directory chmod 000 when it is not yet bound to ensure that 
qtox doesn't write to it if ever the bind fails. However, a symlink would be 
better. There should be a way in the qtox code to open the symlink without 
de-referencing it, but I would have to look later. There is also probably a way 
to make the apparmor profile work for symlinks.

See "man realpath". realpath will resolve the symlink, but option -s will 
preserve the symlink in the path.

Bind mount alternative (user called user, thus ~/ is /home/user):
mkdir /test/
mv ~/.config/tox /test/
mkdir ~/.config/tox
chmod 000 ~/.config/tox
mount --bind /test/tox ~/.config/tox
umount ~/.config/tox

Make it automatic on startup (add the following to fstab)
nano /etc/fstab
/test/tox /home/user/.config/tox none defaults,bind 0 0

Bug#996973: ITP: msc-generator -- Draws signalling charts from textual description

[Geert Stappers]

On Thu, Oct 21, 2021 at 08:43:55PM +0200, Gábor Németh wrote:
> * Package name: msc-generator
>   ... I wish to bring it to Debian proper though.
> I can maintain the package myself, but need a sponsor.


Please ping me when there is something to review.


Regards
Geert Stappers
DD
-- 
Silence is hard to parse


signature.asc
Description: PGP signature

Bug#996991: ITP: jgrapht -- Java library of graph theory data structures and algorithms

[Pierre Gruet]

Package: wnpp
Severity: wishlist
Owner: Pierre Gruet 
User: debian-scie...@lists.debian.org
Usertags: field..science
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org

* Package name: jgrapht
  Version : 1.5.1
  Upstream Author : Abdallah Atouani and collaborators
* URL : https://jgrapht.org/
* License : LGPL-2.1 or EPL-2.0
  Programming Lang: Java
  Description : Java library of graph theory data structures and algorithms

JGraphT is a free Java class library that provides mathematical graph-theory
objects and algorithms. In JGraphT, a graph is defined as a set of vertices
connected by a set of edges.

It is possible to define graphs, to modify, compare or generate them, to run
many algorithms through them. One may also import or export graphs.


The library is needed for the packaging of biojava5, which is an aim of the
Debian med team. It is also a nice adddition to Debian to have this Java
library to tackle graph theory problems.
Many years ago, libgrapht0.6-java and libjgrapht0.8-java have been packaged
because new upstream versions of jgrapht generally incorporated ABI changes.
Now this seems not to be the case, hence this unversioned package name.
The packaging will be done in the Debian-science team.

Bug#983224: proj transition has started

[Sebastiaan Couwenberg]

Control: severity -1 serious

The proj transition has started, raising the severity accordingly.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#996990: gnome-shell-extension-appindicator: regression: icon leakage after shell lock/unlock cycle when pidgin is running

[Paul Wise]

Package: gnome-shell-extension-appindicator
Version: 41-1
Severity: important
Usertags: leakage

When I have pidgin running and I lock the screen and unlock again, an
appindicator item with no icon is added to the top panel. I can tell
this blank indicator is present because a mouseover highlights it, as
is normal for appindicator that do have icons. This blank indicator
does everything the same as the pidgin indicator (show/hide pidgin on
left click, pidgin context menu on right click). This blank indicator
is never deleted. Over successive lock/unlock cycles more blank
indicators are added and eventually all the other items on the GNOME
shell top bar are pushed off the screen making them unusable. This
issue is a regression from bullseye, but I'm not sure if GNOME shell or
the appindicator extension is responsible for it.

There are two workarounds for this issue:

 * Close all apps, log out, log in, open all apps.
 * Open Looking Glass, select blank indicator, .destroy() it.

-- System Information:
Debian Release: bookworm/sid
 APT prefers testing-debug
 APT policy: (900, 'testing-debug'), (900, 'testing'), (860, 
'testing-proposed-updates-debug'), (860, 'testing-proposed-updates'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages gnome-shell-extension-appindicator depends on:
ii dconf-gsettings-backend [gsettings-backend] 0.40.0-2
ii gnome-shell 41.0-2

gnome-shell-extension-appindicator recommends no packages.

Versions of packages gnome-shell-extension-appindicator suggests:
ii gnome-shell-extension-prefs 41.0-2
pn libappindicator3-1 
ii libayatana-appindicator3-1 0.5.5-3

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#996989: ITP: fonts-lxgw-wenkai -- Chinese font "LXGW WenKai"

[肖盛文]

Package: wnpp
Severity: wishlist
Owner: xiao sheng wen(肖盛文) 
X-Debbugs-Cc: debian-de...@lists.debian.org, atzli...@sina.com

* Package name: fonts-lxgw-wenkai
  Version : 1.110
  Upstream Author : lxgw 
* URL : https://github.com/lxgw/LxgwWenKai
* License : SIL-1.1
  Description : Chinese font "LXGW WenKai"

 LxgwWenKai is an open-source Chinese font derived from Fontworks' Klee One.
 LXGW is an abbreviation for Chinese word Pinyin "Luo Xiao Gu Wu".
 .
 Include the following font files:
 .
 - LXGWWenKai-Bold.ttf
 - LXGWWenKai-Light.ttf
 - LXGWWenKaiMono-Bold.ttf
 - LxgwWenKaiMonoLatin-Bold.ttf
 - LxgwWenKaiMonoLatin-Light.ttf
 - LxgwWenKaiMonoLatin-Regular.ttf
 - LXGWWenKaiMono-Light.ttf
 - LXGWWenKaiMono-Regular.ttf
 - LXGWWenKai-Regular.ttf

I intend to maintain this package as part of the Debian Font team.
I need a sponsor.

Bug#996968: bts: uses the deprecated 'close' control command

[Paul Wise]

On Thu, 21 Oct 2021 19:47:21 +0200 Mattia Rizzolo wrote:

> There are uses of closing a bug without notifying anybody, and I really
> want `bts` to retain that use.

I suggest a new design for bug closing:

Make `bts done` and `bts close` both be able to do notified closings
and silent closings.

Add command-line options --notify and --silent to `bts done/close`,
make --notify the default for `bts done` and --silent for `bts close`.

Add config file options for each of `bts close/done` to let people
customise them independently as desired.

Change the template for notified closings to mail -done instead of
control@ and place a Version pseudo-header into the template even when
a version isn't specified.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#996988: Should Provide: flash-kernel on ARM(64)

[Elliott Mitchell]

Package: pv-grub-menu
Version: 1.3

SSIA.  On ARM(64) systems typical Linux kernel packages Recommends
"flash-kernel", but for VMs this is quite undesireable.  As such I would
suggest pv-grub-menu should be marked as providing flash-kernel on
ARM(64).

(I suspect this is harmless on other architectures, but is only really
needed on ARM(64))


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#992463: shite appears in wbritish

[mooff]

Not that I can see:

mooff@desktop:/usr/share/dict$ ag shite
british-english-huge
13688:Cushite
13689:Cushites
163155:gobshite
163156:gobshites

british-english-insane
34351:Cushite
34352:Cushite's
34353:Cushites
43030:Elkoshite
43031:Elkoshite's
53787:Girgashite
53788:Girgashite's
71179:Kaneshite
71180:Kaneshite's
74707:Koreishite
74708:Koreishite's
203408:brushite
322749:gobshite
322750:gobshites
390347:mackintoshite
395210:marshite
400913:metabrushite
542621:shited
542622:shitepoke

british-english-large
6589:Cushite

cracklib-small
44399:shitepoke
mooff@desktop:/usr/share/dict$ apt-show-versions -r 'wbritish.*'
wbritish:all/bullseye 2019.10.06-1 uptodate
wbritish-huge:all/bullseye 2019.10.06-1 uptodate
wbritish-insane:all/bullseye 2019.10.06-1 uptodate
wbritish-large:all/bullseye 2019.10.06-1 uptodate


On Thu, 21 Oct 2021 15:26:59 -0700 Don Armstrong  wrote:
> Shite appears in wbritish-large, wbritish-huge, and wbritish-insane 
[and

> in the underlying wordlists.]
>
> --
> Don Armstrong  https://www.donarmstrong.com
>
> The terrorist's job is to terrorize the people, to interfere with
> freedom in such a way that disrupts ordinary life and commerce. With
> due respect, it is clear that the above referenced governmental
> agencies are aiding the terrorists' objective.
>  -- Gary Fielder in Gary Fielder vs Janet Napolitano et al.
>
>

Bug#996977: kbd-chooser: can't chose keyboard variant keymap

[Holger Wansing]

Hi,

Xavier Brochard  wrote (Thu, 21 Oct 2021 21:09:26 +0200):
> Package: kbd-chooser
> Version: 1.71
> Severity: important
> Tags: d-i l10n
> 
> Dear Maintainer,
> 
> I allways use a keyboard variant. While installing Debian 11, the only 
> keyboard layout
> offered was the most common in my language (French Azerty). This may sound 
> minor as one can install 
> another layout at the first boot, but it breaks security during install as 
> user is unable to type
> a good password.
> This was checked on AMD64 netinstall CD and AMD64 firmware DVD, under textual 
> and graphical UI, 
> distant installer with ssh, and with low priority option.

kbd-chooser is no longer used in the installer (since 2012).
The installer has switched to console-setup/keyboard-configuration.

Comparing a Debian 6 installer against one from Debian 7, it seems to me
that the functionality for choosing keyboard variants was dropped in the
installer with this switch.

Unsure, if this was intended? 
Samuel, any idea? (hmm, this was more than 9 years ago)


Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#996815: libfreetype6: upgrade from 2.10.4+dfsg-1 to 2.11.0+dfsg-1 changes terminal text rendering

[Ryan Kavanagh]

Control: tags -1 - patch

I discussed the patch with rxvt-unicode's author. It is a variant on a
broken patch that has been circulating for a long time. It works with
some poorly behaved fonts, but breaks the well-behaved ones. The patch
is broken because xOff has nothing to do with the width of the
character: xOff,yOff are the distance from the glyph origin to the next
glyph origin.

-- 
|)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#996270: false positive custom-library-search-path

[Felix Lechner]

Control: tags -1 - pending

Hi,

On Tue, Oct 19, 2021 at 4:57 AM Yves-Alexis Perez  wrote:
>
> E: charon-cmd: custom-library-search-path usr/sbin/charon-cmd RUNPATH
> usr/lib/ipsec/

The relevant portion of the old binaries check may not have run for
your package previously. We replaced this code, which was part of a
large check :

-# rpath is disallowed, except in private directories
-if (exists $objdump->{RPATH} || exists $objdump->{RUNPATH}) {
-
-my @rpaths
-  = (keys %{$objdump->{RPATH}}, keys %{$objdump->{RUNPATH}});
-
-for my $rpath (map {File::Spec->canonpath($_)}@rpaths) {
-
-my $installable_name = $self->processable->name;
-my $source_name = $self->processable->source_name;
-
-my $madir = $self->DEB_HOST_MULTIARCH->{$architecture};
-return
-  unless length $madir;
-
-return
-  if $rpath
-  =~
m{^/usr/lib/(?:$madir/)?(?:games/)?(?:\Q$installable_name\E|\Q$source_name\E)(?:/|\z)};
-
-return
-  if $self->private_directories->{$rpath}
-  && $rpath !~ m{^(?:/usr)?/lib(?:/$madir)?/?\z};
-
-return
-  if $rpath =~ m{^\$\{?ORIGIN\}?};
-
-# GHC in Debian uses a scheme for RPATH. (#914873)
-return
-  if $rpath =~ m{^/usr/lib/ghc/};
-
-$self->hint('custom-library-search-path', $item, $rpath);
-}
-}

with this self-contained file: [1]

+for my $section (qw{RPATH RUNPATH}) {
+
+my @rpaths = keys %{$objdump->{$section} // {}};
+
+my @no_origin = grep { !m{^ \$ \{? ORIGIN \}? }x } @rpaths;
+
+my @canonical = map { File::Spec->canonpath($_) } @no_origin;
+
+my @normalized;
+for my $path (@canonical) {
+
+$path =~ s{^/}{};
+$path .= $SLASH
+  unless $path =~ m{/\z};
+
+push(@normalized, $path);
+}
+
+my @custom;
+for my $folder (@normalized) {
+
+# for shipped folders, would have to disallow system locations
+next
+  if any { $folder =~ m{^\Q$_\E} } @{$self->private_folders};
+
+# GHC in Debian uses a scheme for RPATH (#914873)
+next
+  if $folder =~ m{^usr/lib/ghc/};
+
+push(@custom, $folder);
+}
+
+$self->hint('custom-library-search-path', $item, $section, $_)
+  for @custom;
+}

I believe we only disabled the use of /usr/lib/${installable_name} in
favor of /usr/lib/${source_name}. (I think I was unable to find
packages using that exemption.) Is your package affected by that
change?

The commit [2] reduced the nesting depth and the complexity of the
conditionals. It is therefore possible that the relevant portion of
the check did not previously run for your package.

Kind regards
Felix Lechner

[1] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Binaries/Rpath.pm
[2] 
https://salsa.debian.org/lintian/lintian/-/commit/7a389940a560f556d0e240481f00302499a1fc66

Bug#996832: xpdf: segmentation fault in case of incorrect Xpdf*font X resource

[Vincent Lefevre]

On 2021-10-22 02:34:44 +0200, Vincent Lefevre wrote:
> Thanks for the quick fix, but there is still an issue. The segfault
> is gone, and the chosen font is taken into account, but if a
> Xpdf*font resource is given (even with a non-existing font,
> such as "foo"), the printed contents is interpreted as ISO-8859-1
> rather than UTF-8. And if I give an explicit UTF-8 font such as
> 
>   Xpdf*font: -misc-fixed-medium-r-normal--13-120-75-75-c-80-iso10646-1
> 
> I get complete garbage (lots of white squares).

Note: I mean for text on the outline pane on the left side of the
window (bookmarks).

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

Bug#996949: dh-python: Errors in python3 maintainer scripts caused by ordering of d.control fields

[Stefano Rivera]

A scan of unstable doesn't turn up any affected packages, phew.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#996832: xpdf: segmentation fault in case of incorrect Xpdf*font X resource

[Vincent Lefevre]

Hi Florian,

On 2021-10-21 15:08:51 +0200, Florian Schlichting wrote:
> I've just uploaded xpdf 3.04+git20211021-1 including this fix (thanks
> Adam!). Can you confirm that it fixes this issue?

Thanks for the quick fix, but there is still an issue. The segfault
is gone, and the chosen font is taken into account, but if a
Xpdf*font resource is given (even with a non-existing font,
such as "foo"), the printed contents is interpreted as ISO-8859-1
rather than UTF-8. And if I give an explicit UTF-8 font such as

  Xpdf*font: -misc-fixed-medium-r-normal--13-120-75-75-c-80-iso10646-1

I get complete garbage (lots of white squares).

I'm also wondering how Xft fonts can be used. Syntax like
xft:Bitstream:size=9 (as used by fvwm) doesn't work.

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

Bug#996903: xpdf 3.04+git20211001-1 crashes

[Florian Schlichting]

On Thu, Oct 21, 2021 at 04:25:28PM +0300, Eugene Berdnikov wrote:
>   Hi Florian.
>   
> On Thu, Oct 21, 2021 at 03:11:41PM +0200, Florian Schlichting wrote:
> > I've just uploaded xpdf 3.04+git20211021-1 which should fix #996832 -
> > once it hits the mirrors in a few hours, can you check if that improves
> > your issue as well?
> 
>  Can you give a direct url of package for download?

there's a mirror sync like 4 times a day, so it can take a while. By
now, the new package can be seen here:
https://packages.debian.org/sid/xpdf

from which you can follow links to (for example)
- 
http://ftp.ru.debian.org/debian/pool/main/x/xpdf/xpdf_3.04+git20211021-1_amd64.deb
- http://ftp.debian.org/debian/pool/main/x/xpdf/xpdf_3.04+git20211021-1_i386.deb
or whatever suits you

Bug#993176: libssh2 FTBFS: configure.ac:130: error: m4_undefine: undefined macro: backend

[Nicolas Mora]

The package libssh2 1.10.0-2 has successfully migrated to testing so I 
believe this bug is fixed now

Bug#996923: apt-listbugs: page long buglists

[Moshe Piekarski]

On 10/20/21 5:56 PM, Francesco Poli wrote:
> On Wed, 20 Oct 2021 16:40:46 -0400 Moshe Piekarski wrote:
>
> [...]
>> Apt-listtbugs output is less usefull on large upgrades due
>> to bugs scrolling offscreen
>> please implement paging for long buglists.
> Hello Moshe,
> thanks for your feature request.
Thank you for your quick answer.
>
> I am under the impression that your need is a bit unusual.
> The reason is that apt-listbugs is most useful (I think), when using
> Debian testing or unstable and upgrading reasonably often.
> In this scenario, it is quite uncommon to see a very long list of RC
> bugs during one upgrade session...
>
> However, I see that you are using Debian testing, but apparently you do
> not upgrade very often (your system still thinks that bullseye ==
> testing ...).
Good point I haven't had a chance to upgrade in a few months
> Oh, and I also see that you configured apt-listbugs to also show
> important bugs, along with RC bugs.
> These two points might explain the bigger number of bugs that you
> encounter.
However I believe this is probably a fairly common usecase
>
> I don't know whether I will consider implementing a paging option for
> apt-listbugs.
> A naive implementation could be feasible without too much hassle, but
> it would be too tied to specific tool choices (for instance, it could
> be written to forcibly use the "less" pager, but, what if a user has or
> prefers another pager?).
I was considering doing this for myself but thought that a more
generalized approach would be good
> Maybe a more general solution should be sought.
> Perhaps the use of a helper Ruby library, such as [tty-pager]?
> Unfortunately, it seems that this library is not (yet) included in
> Debian. Would you be willing to file an RFP bug for this library
> (or, better yet, to file an ITP bug and package it yourself)?
>
> [tty-pager]: 

I am not familiar enough with ruby (and only slightly more so with
Debian packaging),

but thank you for suggesting it.


Thank you for your time,

Moshe Piekarski

--

There's no such thing as a stupid question,

But there are plenty of inquisitive idiots.

Bug#984243: Help: mothur: ftbfs with GCC-11

[Étienne Mollier]

Hi Andreas,

Andreas Tille, on 2021-10-21:
> In file included from addtargets2.cpp:3:
> myutils.h:176:1: error: reference to 'byte' is ambiguous

Since C++ 2017, the std::byte type is defined:

>   176 | byte *ReadAllStdioFile(FILE *f, off_t );
>   | ^~~~
> In file included from /usr/include/c++/11/bits/stl_algobase.h:61,
>  from /usr/include/c++/11/bits/char_traits.h:39,
>  from /usr/include/c++/11/string:40,
>  from myutils.h:8,
>  from addtargets2.cpp:3:
> /usr/include/c++/11/bits/cpp_type_traits.h:404:30: note: candidates are: 
> 'enum class std::byte'

The redefinition below thus gives indeterminations, as the code
is running in namespace "std":

> In file included from addtargets2.cpp:3:
> myutils.h:42:23: note: 'typedef unsigned char byte'
>42 | typedef unsigned char byte;
>   |   ^~~~
> myutils.h:177:1: error: reference to 'byte' is ambiguous

The option which seems the most viable would be to replace all
occurrences of the "byte" type by something that does not clash
with the new standard library, maybe "byte8" to be somewhat
consistent with upstream naming conventions.


In hope this helps,

Have a nice evening,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/tty1, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#664828: carmetal: Newer version 3.7.1 available, missing watch file

[Ben Tris]

Package: carmetal
Followup-For: Bug #664828

On some Systems version 3.7.1 is used.
https://repology.org/project/carmetal/versions

There is a version 4.3 (2019).
http://carmetal2.free.fr/site/telechargements.php
Also see Wikipedia.

There is an archived version 3.8.7 (2015).
https://web.archive.org/web/20170714153726/http://carmetal.org/index.php/fr/telecharger




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

Kernel: Linux 4.19.0-18-amd64 (SMP w/4 CPU cores)
Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8), 
LANGUAGE=nl_NL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages carmetal depends on:
ii  default-jre [java7-runtime] 2:1.11-71
pn  jarwrapper  
ii  openjdk-11-jre [java7-runtime]  11.0.12+7-2~deb10u1

carmetal recommends no packages.

carmetal suggests no packages.

Bug#996971: systemd: clamav service units fail with StandardOutput=syslog

[Brown, Thomas]

On 10/21/21 4:00 PM, Michael Biebl wrote:

Am 21.10.2021 um 20:42 schrieb Michael Biebl:

[always CC the bug report email address on replies]

Am 21.10.21 um 20:25 schrieb Brown, Thomas:


On 10/21/21 2:14 PM, Michael Biebl wrote:

Control: reassign -1 clamav-daemon


Not sure why you filed this against the systemd package when the 
service file in question is shipped by clamav-daemon.

Reassigning accordingly.

This is a systemd problem that occurs when attempting to launch 
clamav-daemon.


systemd[1]: Condition check resulted in Clam AntiVirus userspace 
daemon being skipped.


This condition is specified by the clamav-daemon.service though.
I assume this means that the clamav daemon package is not properly 
set-up. not an issue of systemd.




Your service fails to start or rather is not started by systemd, as 
the condition(s) specified in


https://sources.debian.org/src/clamav/0.103.3+dfsg-1/clamd/clamav-daemon.service.in/ 




# Check for database existence
ConditionPathExistsGlob=@DBDIR@/main.{c[vl]d,inc}
ConditionPathExistsGlob=@DBDIR@/daily.{c[vl]d,inc}

is not met.

The log message about StandardOutput=syslog is just a warning but does 
not make the service fail.


Ok, but is there a way to throttle or stagger the condition checks so 
that they only happen once every 5 minutes for example?


This problem seems similar to https://github.com/systemd/systemd/issues/2467

Additionally I should be able to remove StandardOutput from the 
clamav-daemon.service configuration by removing it from the service unit 
definition in /etc/systemd/system/ but it still appears to be present or 
in effect because the Condition check error is still seen in this case 
but not when removed from the service unit definition in 
/lib/systemd/system/.


Finally it would appear that repeated condition check failures are 
resulting in a system reboot in the ConditionPathExistsGlob case.  Is 
there a recommended configuration to prevent this from happening?



--
Kind Regards,

Thomas Brown

Linux Developer
EPS PBU RT Solution Services

411 Leggett Drive
Suite 502
Kanata, ON, Canada
K2K 3C9
 
Tel: 613-963-1016

Fax: 613-599-1060

Bug#996987: dolfinx: FTBFS: unsatisfiable Build-Depends

[Sebastian Ramacher]

Source: dolfinx
Version: 2019.2.0~git20210130.c14cb0a-5
Severity: serious
Tags: sid bookworm ftbfs
X-Debbugs-Cc: sramac...@debian.org

dolfinx build-depends on missing:
- python3-ffcx:amd64 (< 2019.3)

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#996986: [kexec-tools] Postinst error when upgrading to 1:2.0.22-2+b1

[Sebastian Dalfuß]

Package: kexec-tools
Version: 1:2.0.22-2+b1

Output when upgrading kexec-tools (after dpkg --configure kexec-tools):

Setting up kexec-tools (1:2.0.22-2+b1) ...
Error: argument 'restart' not supported
invoke-rc.d: initscript kexec, action "restart" failed.
dpkg: error processing package kexec-tools (--configure):
installed kexec-tools package post-installation script subprocess returned 
error exit status 1
Errors were encountered while processing:
kexec-tools

Init is sysvinit.

The init script indeed does not support a restart action, as it is not 
necessary for kexec.

Removal of the following autogenerated lines from the postinst script 
seems to remedy the situation, as the package is then installable and 
kexec reboots do work:

# Automatically added by dh_installinit/13.4.1
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = 
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
if [ -z "${DPKG_ROOT:-}" ] && [ -x "/etc/init.d/kexec" ]; then
update-rc.d kexec defaults >/dev/null
invoke-rc.d kexec restart || exit 1
fi
fi
# End automatically added section
# Automatically added by dh_installinit/13.4.1
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = 
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
if [ -z "${DPKG_ROOT:-}" ] && [ -x "/etc/init.d/kexec-load" ]; then
update-rc.d kexec-load defaults >/dev/null
invoke-rc.d kexec-load restart || exit 1
fi
fi
# End automatically added section

Bug#996985: pbdagcon: autopkgtest regression

[Sebastian Ramacher]

Source: pbdagcon
Version: 0.3+git20180411.c14c422+dfsg-3
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

pbdagcon is unable to migrate due to an autopkgtest regression:
/tmp/autopkgtest-lxc.d4k06k9b/downtmp/build.abl/src/debian/tests/run-unit-test: 
line 18: rangen: command not found

See
https://ci.debian.net/data/autopkgtest/testing/amd64/p/pbdagcon/15843553/log.gz

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#996738: tinyproxy: Invalid fix for bug #968322 (issue still occurs): tinyproxy exits 2 on standard systemd stop signal SIGTERM

[RDS]

Apologies, didn't notice this was a new bug. Sending only to it now.

There's at least a handful of reasons why you've not see this failure when 
stopping other systemd-managed applications. None of which, IMO, necessarily 
point to or imply any weakness or shortcoming in tinyproxy's children stop 
approach. With the caveat that I've not examined systemd/systemctl's stop code, 
my opinion now and when first digging into this bug is the same: The likely 
better solution is small additions or backwards-compatible changes to 
systemd/systemctl, for technical and social reasons. But I could be wrong.

The seeming stop-state status contradiction you found is not a true paradox, 
and would likely be resolved relatively soon into looking at systemctl's stop 
code. It's also likely not an indication that my proof of root casuse code may 
not be demonstrating what it claims. While this is possible, it's unlikely. The 
root cause of the issue is almost for sure that systemctl and tinyproxy are 
"racing" to send kill signals to tinyproxy's child processes, and in cases 
where systemctl looses the race*, it responds in an undesirable way (in the 
context of tinyproxy management).

*Pretty sure I'm remembering correctly that it's when systemctl looses the race 
that the false negative stop-states occur, but it might be the opposite.

Bug#996474: libical-dev: The libical-dev package does not provide CMake config files

[Nicolas Mora]

On Thu, 14 Oct 2021 16:02:07 +0200 Kevin Funk  wrote:


The Debian maintainer removed those in:
  https://salsa.debian.org/debian/libical3/-/commit/51ff45c7

... without documenting the change.



My bad, I must have removed these files without noticing it.

I'm uploading a new package to fix this issue

/Nicolas

Bug#994040: "SystemError: initialization of _psycopg raised unreported exception" when running under WSGI

[Raphael Hertzog]

Hello,

Le dimanche 03 octobre 2021, Sébastien Helleu a écrit :
> In my case, setting "WSGIApplicationGroup" to "%{GLOBAL}" doesn't help much.
> 
> But I found another solution, by enabling Daemon mode, as recommended by the
> Django docs:
> https://docs.djangoproject.com/en/3.2/howto/deployment/wsgi/modwsgi/#using-mod-wsgi-daemon-mode
> 
> So I added these two lines in each site (with appropriate domain name) and it
> works fine:
> 
> WSGIDaemonProcess example.com
> WSGIProcessGroup example.com

When we upgraded tracker.debian.org to bullseye, we were already using
"daemon mode" as recommended by the documentation but we still had the
above issue and setting "WSGIApplicationGroup" to "%{GLOBAL}" did
indeed fix the issue for us.

Adrian Bunk thinks that it could be fixed by
https://github.com/GrahamDumpleton/mod_wsgi/commit/9509e178e0583435a800b006b410df74e405e2b9

It would be nice if someone could double check that... we don't want to
use tracker.debian.org for that kind of test.

Cheers,
-- 
Raphaël Hertzog

Bug#993680: transition: proj

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2021-09-04 19:49:39 +0200, Bas Couwenberg wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org
> Control: forwarded -1 
> https://release.debian.org/transitions/html/auto-proj.html
> Control: block -1 by 983222 983224 983229 983230 983253 983254 983299 983345
> 
> For the Debian GIS team I'd like to transition to PROJ 8.

Please go ahead. Please also raise  the remaining FTBFS bugs to serious.

Cheers

> 
> This release drops the deprecated proj_api.h for which not all rdeps have 
> been updated yet.
> 
> Several got updated with support for proj.h since the 8.0.0 release in 
> February however.
> 
> 
> Transition: proj
> 
>  libproj19 (7.2.1-1) -> libproj22 (8.1.1-1~exp1)
> 
> The status of the most recent rebuilds is as follows.
> 
>  atlas-ecmwf (0.26.0-1) OK
>  gammaray(2.11.2-2) OK
>  libgeotiff  (1.7.0-2)  OK
>  mshr(2019.2.0~git20200924.c27eb18+dfsg1-5) OK
>  octave-octproj  (2.0.1-4)  OK
>  osm2pgsql   (1.5.1+ds-1)   OK
>  pdl (1:2.057-3)OK
>  proj-rdnap  (2008+2018-5)  OK
>  python-cartopy  (0.19.0+dfsg-2)FTBFS
>(#983222)
>  python-pyproj   (3.1.0-1)  OK
>  sosi2osm(1.0.0-7)  FTBFS
>(#983224)
>  spatialite  (5.0.1-2)  OK
>  survex  (1.2.45-1) FTBFS
>(#983229)
>  xygrib  (1.2.6-2)  FTBFS
>(#983230)
> 
>  gdal(3.2.2+dfsg-3) OK
>  gnudatalanguage (1.0.0-4)  OK
>  librasterlite2  (1.1.0~beta1-2)OK
>  magics++(4.9.0-1)  OK
>  spatialite-tools(5.0.1-1)  OK
>  xastir  (2.1.6-3)  OK
> 
>  cdo (2.0.0~rc5-1)  OK
>  mapnik  (3.1.0+ds-1)   OK
>  mapserver   (7.6.4-1)  OK
>  merkaartor  (0.19.0+ds-2)  OK
>  metview (5.13.0-1) OK
>  mysql-workbench (8.0.26+dfsg-1)OK
>  ncl (6.6.2-7)  FTBFS
>(#983253)
>  openorienteering-mapper (0.9.4-2)  FTBFS
>(#983254)
>  pdal(2.2.0+ds-1)   OK
>  postgis (3.1.3+dfsg-1) OK
>  qmapshack   (1.16.0-2) OK
>  r-cran-rgdal(1.5-23+dfsg-1)OK
>  r-cran-sf   (0.9-7+dfsg-5) OK
>  saga(7.3.0+dfsg-5) OK
>  spatialite-gui  (2.1.0~beta1-1)OK
>  sumo(1.8.0+dfsg2-5)OK
>  vtk7(7.1.1+dfsg2-10)   OK
>  vtk9(9.0.1+dfsg1-8)FTBFS
>(#983299)
> 
>  freecad (0.19.1+dfsg1-2)   OK
>  grass   (7.8.5-2)  OK
>  r-cran-lwgeom   (0.2-5-2)  OK
>  therion (5.5.7ds1-2)   FTBFS
>(#983345)
> 
>  qgis(3.16.10+dfsg-1)   OK
> 
> 
> Kind Regards,
> 
> Bas
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#996977: kbd-chooser: can't chose keyboard variant keymap

[Samuel Thibault]

Hello,

Xavier Brochard, le jeu. 21 oct. 2021 21:09:26 +0200, a ecrit:
> I allways use a keyboard variant. While installing Debian 11, the only 
> keyboard layout
> offered was the most common in my language (French Azerty).

Yes, we do not want to clutter the menu with various variant choices for
each and every language.

> but it breaks security during install as user is unable to type a good
> password.

Why?

Samuel

Bug#996722: src:python-volatile: fails to migrate to testing for too long: uploader built arch:all binaries

[Nicholas D Steeves]

Hi Paul

Paul Gevers  writes:

> Hi Nicolas,
>
> Thanks you, but as I detect these issues in an automatic way without
> much manual labor, I don't need the credits :). And I uploaded to
> DELAYED exactly to give others the opportunity to fix it before me, so
> uploading to DELAYED in my opinion *always* has that ACK implied.
>

Thank you for providing the opportunity to respond, and ok, as you
prefer! :-)

> I have pasted the diff below, but for such a no change NMU, I'd just
> ignore it if I were you. It's not interesting especially if you beat the
> upload anyways.
>

Agreed.

> I can (and will try) to cancel my upload, but it's rather harmless if I
> fail because it will indeed be rejected if there is already an newer
> version in the suite and you'll only get a reject e-mail about it (which
> can still be annoying, so I'll try and cancel).
>

Ok, thank you for the guidance, and for a positive first "receiving an
NMU proposal" experience :-)  I'll upload momentarily.  For the record,
from the package maintainer perspective: good communication on the BTS,
integrating the proposed change, and uploading without cancelling the
NMU upload is the best social practice?  I'd like to keep things
positive, you know?

Best,
Nicholas

P.S. I won't be annoyed by the rejection email for -3.1.


signature.asc
Description: PGP signature

Bug#996982: gimp: Crash (segfault) when changing a font

[Leandro Lucarella]

Package: gimp
Version: 2.10.22-4
Severity: normal

Dear Maintainer,

GIMP crashed when trying to change some font.

```
GNU Image Manipulation Program version 2.10.22
git-describe: GIMP_2_10_20-217-g0c8a7891f7
Build: unknown rev 0 for linux
# C compiler #
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 
10.2.1-6' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-10 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib 
--enable-libphobos-checking=release --with-target-system-zlib=auto 
--enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib 
--with-tune=generic 
--enable-offload-targets=nvptx-none=/build/gcc-10-Km9U7s/gcc-10-10.2.1/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-Km9U7s/gcc-10-10.2.1/debian/tmp-gcn/usr,hsa
 --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu 
--with-build-config=bootstrap-lto-lean --enable-link-mutex
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.1 20210110 (Debian 10.2.1-6) 

# Libraries #
using babl version 0.1.82 (compiled against version 0.1.86)
using GEGL version 0.4.26 (compiled against version 0.4.28)
using GLib version 2.66.8 (compiled against version 2.66.8)
using GdkPixbuf version 2.42.2 (compiled against version 2.42.2)
using GTK+ version 2.24.33 (compiled against version 2.24.33)
using Pango version 1.46.2 (compiled against version 1.46.2)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```
> fatal error: Segmentation fault

Stack trace:
```

# Stack traces obtained from PID 851666 - Thread 851666 #

[New LWP 851667]
[New LWP 851668]
[New LWP 851669]
[New LWP 851670]
[New LWP 851671]
[New LWP 851672]
[New LWP 851673]
[New LWP 851677]
[New LWP 851678]
[New LWP 851682]
[New LWP 851800]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
__libc_read (nbytes=256, buf=0x7fff92220800, fd=17) at 
../sysdeps/unix/sysv/linux/read.c:26
  Id   Target IdFrame 
* 1Thread 0x7f7231de6e00 (LWP 851666) "gimp-2.10"   __libc_read 
(nbytes=256, buf=0x7fff92220800, fd=17) at ../sysdeps/unix/sysv/linux/read.c:26
  2Thread 0x7f72315a4700 (LWP 851667) "worker"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  3Thread 0x7f7230da3700 (LWP 851668) "worker"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  4Thread 0x7f72305a2700 (LWP 851669) "worker"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  5Thread 0x7f722fda1700 (LWP 851670) "worker"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  6Thread 0x7f722f5a0700 (LWP 851671) "worker"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  7Thread 0x7f722ed9f700 (LWP 851672) "worker"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  8Thread 0x7f722e59e700 (LWP 851673) "worker"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  9Thread 0x7f720700 (LWP 851677) "gmain"   0x7f723302e3ff in 
__GI___poll (fds=0x55c638b59850, nfds=2, timeout=-1) at 
../sysdeps/unix/sysv/linux/poll.c:29
  10   Thread 0x7f720f7fe700 (LWP 851678) "gdbus"   0x7f723302e3ff in 
__GI___poll (fds=0x55c638b6ec10, nfds=3, timeout=-1) at 
../sysdeps/unix/sysv/linux/poll.c:29
  11   Thread 0x7f71f3178700 (LWP 851682) "async"   syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  12   Thread 0x7f71f09aa700 (LWP 851800) "swap writer" syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38

Thread 12 (Thread 0x7f71f09aa700 (LWP 851800) "swap writer"):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x7f723331134f in g_cond_wait () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7f723381953d in  () at /usr/lib/x86_64-linux-gnu/libgegl-0.4.so.0
#3  0x7f72332e90bd in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7f7233108ea7 in start_thread (arg=) at 

Bug#996983: flameshot: Does not work with gnome-shell 40+ and Wayland: dbus call restricted

[Boyuan Yang]

Package: flameshot
Version: 0.10.1+ds1-1
Severity: important
Forwarded: https://github.com/flameshot-org/flameshot/issues/1910

Due to GNOME upstream restriction in
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1970 , GNOME shell
+ wayland users cannot use private D-Bus APIs to silently capture screenshots.

As discussed in https://github.com/flameshot-org/flameshot/issues/1910 ,
flameshot developers will turn to XDG desktop portal to capture screen
instead. This hasn't been implemented yet.

Thanks,
Boyuan Yang


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

Bug#996981: multiqc: Link to jquery missing

[Steffen Moeller]

Package: multiqc
Version: 1.11+dfsg-1
Severity: normal

Reminder to self:

distutils.errors.DistutilsFileError: can't copy 
'/usr/lib/python3/dist-packages/multiqc/templates/default/assets/js/packages/jquery-3.1.1.min.js':
 doesn't exist or not a regular file


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

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

Versions of packages multiqc depends on:
ii  fonts-glyphicons-halflings  1.009~3.4.1+dfsg-2
ii  libjs-bootstrap 3.4.1+dfsg-2
ii  libjs-jquery3.5.1+dfsg+~3.5.5-7
ii  libjs-jquery-tablesorter1:2.31.3+dfsg1-1
ii  libjs-jquery-ui 1.12.1+dfsg-8
ii  python3 3.9.2-3
ii  python3-click   8.0.2-1
ii  python3-coloredlogs 7.3-2
ii  python3-distutils   3.9.7-1
ii  python3-future  0.18.2-5
ii  python3-humanfriendly   10.0-1
ii  python3-jinja2  3.0.1-2
ii  python3-lzstring1.0.4-1.1
ii  python3-markdown3.3.4-1
ii  python3-matplotlib  3.3.4-2
ii  python3-networkx2.5+ds-2
ii  python3-numpy   1:1.19.5-1
ii  python3-requests2.25.1+dfsg-2
ii  python3-rich9.11.0-1
ii  python3-simplejson  3.17.5-2
ii  python3-spectra 0.0.11-2
ii  python3-yaml5.4.1-1

Versions of packages multiqc recommends:
ii  libjs-filesaver  2.0.2+dfsg-3
ii  node-clipboard   2.0.6+ds+~cs7.6.4-1
ii  pandoc   2.9.2.1-1+b2
ii  texlive-xetex2021.20210921-1

multiqc suggests no packages.

-- no debconf information

Bug#996980: khronos-opencl-clhpp: build-dependency loop between khronos-opencl-clhpp, khronos-opencl-headers, ocl-icd

[Steve Langasek]

Package: khronos-opencl-clhpp
Version: 3.0~2.0.15-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch

Dear maintainers,

With the unfreezing of the Ubuntu archive for jammy and the import of the
latest packages from Debian, khronos-opencl-clhpp was failing to build with
unsatisfied build-dependencies, due to a loop between khronos-opencl-clhpp,
khronos-opencl-headers, and ocl-icd:

  - khronos-opencl-clhpp build-depends ocl-icd-opencl-dev
  - ocl-icd-opencl-dev depends opencl-c-headers and opencl-clhpp-headers
  - current opencl-c-headers in unstable Breaks: previously available
versions of opencl-clhpp-headers

While this loop doesn't cause an ongoing problem once khronos-opencl-clhpp
3.0~2.0.15-1 is built, it still represents a bootstrap loop, which is
suboptimal.  Also, it seems strange that an arch: all headers-only package
build-depends on other -dev packages.

Digging in, I found that the build-dependency was because examples were
being compiled (and subsequently run).  While this is a good test to have
for the package, the current implementation only ensures the tests are run
on the architecture where arch: all packages are being built.  Surely this
would be better done as an autopkgtest, so that it runs for each
architecture?

(Also, btw, the implementation in debian/rules was testing the examples
outside of the 'nocheck' test, which would cause problems for cross-builds,
among other things)

I have applied the attached patch in Ubuntu to break the bootstrap loop. 
While I could drop the patch once the bootstrap is finished, I think this,
combined with adding the examples as an autopkgtest (which I have not
implemented here - sorry) would be an overall improvement in robustness, so
I'm submitting this bug for consideration.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru khronos-opencl-clhpp-3.0~2.0.15/debian/control 
khronos-opencl-clhpp-3.0~2.0.15/debian/control
--- khronos-opencl-clhpp-3.0~2.0.15/debian/control  2021-08-23 
16:17:49.0 -0700
+++ khronos-opencl-clhpp-3.0~2.0.15/debian/control  2021-10-21 
12:52:36.0 -0700
@@ -7,7 +7,6 @@
 Build-Depends: debhelper-compat (= 13),
opencl-c-headers (>= 3.0~2021.04.29),
cmake,
-   ocl-icd-opencl-dev,
doxygen,
 Rules-Requires-Root: no
 Standards-Version: 4.6.0
diff -Nru khronos-opencl-clhpp-3.0~2.0.15/debian/rules 
khronos-opencl-clhpp-3.0~2.0.15/debian/rules
--- khronos-opencl-clhpp-3.0~2.0.15/debian/rules2021-08-23 
16:17:49.0 -0700
+++ khronos-opencl-clhpp-3.0~2.0.15/debian/rules2021-10-21 
12:50:32.0 -0700
@@ -7,13 +7,12 @@
dh $@
 
 override_dh_auto_configure:
-   dh_auto_configure -- -DBUILD_TESTS=OFF 
-DCMAKE_LIBRARY_PATH=$(DEB_HOST_MULTIARCH)
+   dh_auto_configure -- -DBUILD_EXAMPLES=OFF -DBUILD_TESTS=OFF 
-DCMAKE_LIBRARY_PATH=$(DEB_HOST_MULTIARCH)
 
 override_dh_auto_build:
dh_auto_build -- all docs
 
 override_dh_auto_test:
-   dh_auto_test -- examples
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
$(MAKE) -C debian/t
 endif

Bug#996969: drop 'close' command --- deprecated since at least February 2002

[Adrian Bunk]

On Thu, Oct 21, 2021 at 12:17:25PM -0400, Ryan Kavanagh wrote:
> Package: bugs.debian.org
> Severity: wishlist
> X-Debbugs-Cc: r...@debian.org
> 
> The 'close' command has been deprecated since at least February 2002 [0],
> and its use is strongly discouraged by §5.8.2 of the developers
> reference:
> 
> You should never close bugs via the bug server close command sent to
> cont...@bugs.debian.org. If you do so, the original submitter will
> not receive any information about why the bug was closed. [1]
> 
> After almost 20 years of deprecation, maybe it's time to finally drop
> it?
>...

If this gets implemented, how are housekeeping actions like [1] supposed 
to be done?

How do you suggest to close bugs like #993125 on submission?

cu
Adrian

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984001;msg=15 

Bug#984243: Help: mothur: ftbfs with GCC-11

[Aaron M. Ucko]

Steffen Möller  writes:

> My C++ skills are a bit rosty but would removing the typedef for byte
> solve the problem?

No, because std::byte supports far too few operations [1].  Instead, I'd
suggest encouraging upstream to rename their type, and meanwhile locally
patching source/uchime_src/makefile to add -std=c++14 to CXXFLAGS,
thereby suppressing std::byte for now.

I also found massive link errors, resolvable by correcting the top-level
Makefile to pick up source/*.cpp and source/*.c rather than the
nonexistent *.cpp and *.c.

[1] https://en.cppreference.com/w/cpp/types/byte

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#995623: refind FTBFS: error: conflicting types for ‘EFI_DEVICE_PATH_UTILITIES_PROTOCOL’

[Rod Smith]

On 10/19/21 8:07 PM, Tianon Gravi wrote:
> Hey Rod, this is an interesting one -- looking at the definitions of
> the "EFI_DEVICE_PATH_UTILITIES_PROTOCOL" typedef in both refind's code
> and grub-efi's, they appear to be compatible to me (which makes sense,
> probably from the same original source?)
> 
> Is this something you plan to resolve in upstream refind source, or
> something we should patch around downstream in Debian?

I need to update my build environment to reproduce the problem. I expect
that once I do, I'll fix it upstream. I suspect that either some
conditional statements around the definition or renaming my own
in-source definition to something else will fix it.

I'll try to take a look at it this weekend.

> On Sun, 3 Oct 2021 at 04:15, Helmut Grohne  wrote:
>> Source: refind
>> Version: 0.12.0-1
>> Severity: serious
>> Tags: ftbfs
>>
>> refind fails to build from source in unstable on amd64 and it also fails
>> to cross build for arm64 for the same reason. A build ends as follows:
>>
>> | make[3]: Entering directory '/<>/EfiLib'
>> | /usr/bin/gcc -Os -fno-strict-aliasing -fno-tree-loop-distribute-patterns 
>> -fno-stack-protector -fshort-wchar -Wall -DEFIX64 -DEFI_FUNCTION_WRAPPER 
>> -m64 -mno-red-zone  -fpic -I/usr/include/efi -I/usr/include/efi/x86_64 
>> -I/usr/include/efi/protocol -I../include -I../refind -I../libeg -I../mok -I. 
>> -I./../include \
>> |   -D__MAKEWITH_GNUEFI -c gnuefi-helper.c -o gnuefi-helper.o
>> | In file included from gnuefi-helper.c:19:
>> | DevicePathUtilities.h:229:3: error: conflicting types for 
>> ‘EFI_DEVICE_PATH_UTILITIES_PROTOCOL’
>> |   229 | } EFI_DEVICE_PATH_UTILITIES_PROTOCOL;
>> |   |   ^~
>> | In file included from /usr/include/efi/efi.h:61,
>> |  from gnuefi-helper.h:24,
>> |  from gnuefi-helper.c:18:
>> | /usr/include/efi/efidevp.h:648:3: note: previous declaration of 
>> ‘EFI_DEVICE_PATH_UTILITIES_PROTOCOL’ was here
>> |   648 | } EFI_DEVICE_PATH_UTILITIES_PROTOCOL;
>> |   |   ^~
>> | make[3]: *** [../Make.common:164: gnuefi-helper.o] Error 1
>> | make[3]: Leaving directory '/<>/EfiLib'
>> | make[2]: *** [Makefile:86: gnuefi] Error 2
>> | make[2]: Leaving directory '/<>'
>> | dh_auto_build: error: make -j1 gnuefi ARCH=x86_64 returned exit code 2
>> | make[1]: *** [debian/rules:33: override_dh_auto_build] Error 25
>> | make[1]: Leaving directory '/<>'
>> | make: *** [debian/rules:26: build] Error 2
>> | dpkg-buildpackage: error: debian/rules build subprocess returned exit 
>> status 2
>>
>> Also seen by crossqa:
>> http://crossqa.debian.net
>>
>> Reproduced natively on arm64 by reproducible builds:
>> https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/refind_0.12.0-1.rbuild.log.gz
>>
>> Helmut
>>


-- 
Rod Smith
rodsm...@rodsbooks.com
http://www.rodsbooks.com

Bug#996971: systemd: clamav service units fail with StandardOutput=syslog

[Michael Biebl]

Am 21.10.2021 um 20:42 schrieb Michael Biebl:

[always CC the bug report email address on replies]

Am 21.10.21 um 20:25 schrieb Brown, Thomas:


On 10/21/21 2:14 PM, Michael Biebl wrote:

Control: reassign -1 clamav-daemon


Not sure why you filed this against the systemd package when the 
service file in question is shipped by clamav-daemon.

Reassigning accordingly.

This is a systemd problem that occurs when attempting to launch 
clamav-daemon.


systemd[1]: Condition check resulted in Clam AntiVirus userspace 
daemon being skipped.


This condition is specified by the clamav-daemon.service though.
I assume this means that the clamav daemon package is not properly 
set-up. not an issue of systemd.




Your service fails to start or rather is not started by systemd, as the 
condition(s) specified in


https://sources.debian.org/src/clamav/0.103.3+dfsg-1/clamd/clamav-daemon.service.in/ 




# Check for database existence
ConditionPathExistsGlob=@DBDIR@/main.{c[vl]d,inc}
ConditionPathExistsGlob=@DBDIR@/daily.{c[vl]d,inc}

is not met.

The log message about StandardOutput=syslog is just a warning but does 
not make the service fail.

Bug#996231: ruby-ftw: FTBFS: ERROR: Test "ruby2.7" failed: /<>/test/ftw/protocol.rb:19:in `test': wrong number of arguments (given 1, expected 2) (ArgumentError)

[Lucas Kanashiro]

Em 21/10/2021 16:30, Antonio Terceiro escreveu:

did you forget to push to git?
https://salsa.debian.org/ruby-team/ruby-ftw/-/commits/master does not
have any recent commits.


Sorry, yes, I forgot to git push the changes. Done now.

--

Lucas Kanashiro

Bug#996979: libsrtp2-dev: libpcap-dev really required?

[Alexander Traud]

Package: libsrtp2-dev
Version: 2.4.2-1

The -dev package has a dependency on libpcap, even on libpcap-dev. Once [1] you 
had a -utils package, and libpcap was required for its tool rtp_decoder. As I 
cannot find the -utils package anymore, is that dependency still required? When 
I build libsrtp2 manually via

./configure --enable-nss
make shared_library

and link against the resulting .so, I never required libpcap-dev. Therefore, I 
am curios.

[1] 

Bug#996978: libsrtp2-1: OpenSSL

[Alexander Traud]

Package: libsrtp2-1
Version: 2.4.2-1
Severity: wishlist

One year ago [1], you enabled NSS as crypto library. With that AES-GCM and 
AES-NI are possible. However, libSRTP can be built with NSS or OpenSSL. You 
played around with OpenSSL six years ago [2]. Do you remember why it failed? 
Curl has several packages [3], the default for OpenSSL and an alternative 
package for NSS. Is something like this possible with your libsrtp2 package?

[1] 
[2] 
[3] 

Bug#996231: ruby-ftw: FTBFS: ERROR: Test "ruby2.7" failed: /<>/test/ftw/protocol.rb:19:in `test': wrong number of arguments (given 1, expected 2) (ArgumentError)

[Antonio Terceiro]

On Wed, Oct 20, 2021 at 06:28:09PM -0300, Lucas Kanashiro wrote:
> I just uploaded version 0.0.44-2 to unstable and it built fine against both,
> ruby2.7 and ruby3.0. Build log attached.

did you forget to push to git?
https://salsa.debian.org/ruby-team/ruby-ftw/-/commits/master does not
have any recent commits.


signature.asc
Description: PGP signature

Bug#996662: Additional information

[debian-testing]

Understood, but I am testing on vanilla debian installs which always includes 
apparmor.  I haven't had this issue with any other vanilla debian packages with 
apparmor.   A specific example is evolution email client.

I am not sure if it is the way tox is reading the config or if it is specific 
to the qtox apparmor profile.  I will have to dig further.



‐‐‐ Original Message ‐‐‐
On Thursday, October 21, 2021 3:08 PM, Yangfl  wrote:

> debian-testing debian-test...@protonmail.com 于2021年10月21日周四 下午9:48写道：
>
> > Yangfl: Symlink outside of home, for example, if on a symlinked network 
> > drive or usb, etc.
> > Directory has appropriate permissions. Seems to be apparmor (see my more 
> > recent post), since works when apparmor is deactivate.
> > Sent with ProtonMail Secure Email.
>
> Then I'd rather mark this issue as wontfix since apparmor really did
> thr right thing to stop program from accessing files outside of /home.

Bug#996949: dh-python: Errors in python3 maintainer scripts caused by ordering of d.control fields

[Stefano Rivera]

Hi Neil (2021.10.21_02:25:00_-0700)
> After inspecting the locally built package against the package already
> in the archive and rolling back each change in turn, the only change
> which causes a failure is the change to reorder the fields in d.control.
> 
> With that identified, the only change in the resulting .deb binaries
> from that change is that the maintainer scripts call py3compile
> python3-envparse:amd64 instead of py3compile python3-envparse

Thanks for debugging that. Clearly fallout from the patch for bug
#991146.

> Policy requires that the ordering of *blocks* in d.control is
> significant (Source before Package) but Policy does not require any
> specific ordering of fields within the blocks. It appears that dh-python
> is reliant on what is only a convention - that Source and/or Package are
> the first fields in the relevant blocks of d.control.

Ack, I'll try to get that fixed ASAP.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#972950: ncal: cal fails to highlight current date (and rejects -h flag)

[Norman Ramsey]

Package: ncal
Version: 12.1.7+nmu3
Followup-For: Bug #972950

Dear Maintainer,

The regression is annoying, but if absolute compatibility with original `cal` 
must be maintained, I can live with that.  However, in that case the man page 
needs to be corrected.

Note to other users: using `ncal -b` provides the classic display, but with 
highlighting.


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

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

Versions of packages ncal depends on:
ii  libc6  2.31-13+deb11u2
ii  libtinfo6  6.2+20201114-2

ncal recommends no packages.

ncal suggests no packages.

-- no debconf information

Bug#996977: kbd-chooser: can't chose keyboard variant keymap

[Xavier Brochard]

Package: kbd-chooser
Version: 1.71
Severity: important
Tags: d-i l10n

Dear Maintainer,

I allways use a keyboard variant. While installing Debian 11, the only keyboard 
layout
offered was the most common in my language (French Azerty). This may sound 
minor as one can install 
another layout at the first boot, but it breaks security during install as user 
is unable to type
a good password.
This was checked on AMD64 netinstall CD and AMD64 firmware DVD, under textual 
and graphical UI, 
distant installer with ssh, and with low priority option.

Best regards and thank you for the hard work
Xavier

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

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

Bug#996955: task-desktop silently pulls in task-desktop-gnome via Recommends

[Brian Potkin]

On Thu 21 Oct 2021 at 20:39:01 +0200, Fabian Greffrath wrote:

> Am Donnerstag, dem 21.10.2021 um 18:33 +0100 schrieb Brian Potkin:
> > I think this is exactly the way it was designed. Whether the design
> > is the best is what has been brought up in this report.
> 
> The results are pretty surprising and unpredictable, though.

Indeed. Many users, myself included, have stared at the choices and
wondered what the first choice implies. "Default - Gnome" next to it
might have helped.

Fortunately, not selecting it isn't of any consequence. A user gets
what else is chosen.
 
> > There is the concept of "default desktop". At the present time it is
> > Gnome. The first selection is for the default. The description for
> > task-desktop says:
> 
> You don't have a chance to read the description of the task-desktop
> package during d-i. As Holger already stated, it must be made clear
> that merely selecting "Desktop Environment" will have the same effect
> as selecting the first one in the list, even if this has been
> explicitly unselected.

No, that is not the case. Selecting "Desktop Environment" only will
have the effect of selecting the default desktop. This could be Xfce,
which is not the first one in the list.

Cheers,

Brian.

Bug#996976: vtk6: Remove vtk6 from the Debian 12

[Anton Gladky]

Source: vtk6
Severity: serious


vtk has now 3 versions in archive: vtk6, vtk7 and vtk9.
Intention is to remove older unsupported versions in favour of cyrrent vtk9.

Bug#984243: Help: mothur: ftbfs with GCC-11

[Steffen Möller]

On 21.10.21 20:21, Étienne Mollier wrote:

Hi Andreas,

Andreas Tille, on 2021-10-21:

In file included from addtargets2.cpp:3:
myutils.h:176:1: error: reference to 'byte' is ambiguous

Since C++ 2017, the std::byte type is defined:


   176 | byte *ReadAllStdioFile(FILE *f, off_t );
   | ^~~~
In file included from /usr/include/c++/11/bits/stl_algobase.h:61,
  from /usr/include/c++/11/bits/char_traits.h:39,
  from /usr/include/c++/11/string:40,
  from myutils.h:8,
  from addtargets2.cpp:3:
/usr/include/c++/11/bits/cpp_type_traits.h:404:30: note: candidates are: 'enum 
class std::byte'

The redefinition below thus gives indeterminations, as the code
is running in namespace "std":


In file included from addtargets2.cpp:3:
myutils.h:42:23: note: 'typedef unsigned char byte'
42 | typedef unsigned char byte;
   |   ^~~~
myutils.h:177:1: error: reference to 'byte' is ambiguous

The option which seems the most viable would be to replace all
occurrences of the "byte" type by something that does not clash
with the new standard library, maybe "byte8" to be somewhat
consistent with upstream naming conventions.


In hope this helps,

Have a nice evening,  :)


My C++ skills are a bit rosty but would removing the typedef for byte
solve the problem?

Best,
Steffen

Bug#995376: wsjtx: Segfault when use refspec

[Benjamin Bänziger]

A patch to fix this bug is available:
https://sourceforge.net/p/wsjt/mailman/message/37370468/

It has also been fixed in the new wsjt-x release 2.5.1

Bug#996975: deluge-web: Systemd script for deluge-web needs amending to start the service

[Jonas Andradas]

Package: deluge-web
Version: 2.0.3-3.1
Severity: normal
X-Debbugs-Cc: j.andra...@gmail.com

Dear Maintainer,

the deluge-web systemd script that is shipped with Debian Bullseye 
(deluge-web 2.0.3-3.1) does not properly start the service in its 
current state (likely due to changes in deluge-web itself). 

The current systemd configuration uses Type=simple the ExecStart that
can be seen in the excerpt below:

-
[Unit]
Description=Deluge Bittorrent Client Web Interface
Documentation=man:deluge-web
After=network-online.target deluged.service
Wants=deluged.service
[Service]
Type=simple
User=debian-deluged
Group=debian-deluged
UMask=027
# This 5 second delay is necessary on some systems
# to ensure deluged has been fully started
ExecStartPre=/bin/sleep 5
ExecStart=/usr/bin/deluge-web
Restart=on-failure
[Install]
WantedBy=multi-user.target


This combination results in the binary not starting properly.  This can
be easily fixed by adding the '-d' flag to the ExecStart command,
resulting in:

ExecStart=/usr/bin/deluge-web -d

Other options might be possible, such as changing the Type of the
service, but I am not sure which approach would be preferable as the
default choice for the package.

Given that the systemd configuration exists, probably issues #966287 and
#927197 can be considered as closed.

Thank you very much,
Best Regards,
Jonas.

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

Kernel: Linux 5.11.22-2-pve (SMP w/6 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages deluge-web depends on:
ii  deluge-common  2.0.3-3.1
ii  python33.9.2-3
ii  python3-mako   1.1.3+ds1-2

deluge-web recommends no packages.

deluge-web suggests no packages.

-- no debconf information

Bug#996955: task-desktop silently pulls in task-desktop-gnome via Recommends

[Fabian Greffrath]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am Donnerstag, dem 21.10.2021 um 18:33 +0100 schrieb Brian Potkin:
> I think this is exactly the way it was designed. Whether the design
> is the best is what has been brought up in this report.

The results are pretty surprising and unpredictable, though.

> There is the concept of "default desktop". At the present time it is
> Gnome. The first selection is for the default. The description for
> task-desktop says:

You don't have a chance to read the description of the task-desktop
package during d-i. As Holger already stated, it must be made clear
that merely selecting "Desktop Environment" will have the same effect
as selecting the first one in the list, even if this has been
explicitly unselected.

 - Fabian

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEIsF2SKlSa4TfGRyWy+qOlwzNWd8FAmFxs8UACgkQy+qOlwzN
Wd/z1RAA5qtuYcv/O7hbs51+GgxM+Rw7GfokPKH84b5UuYlNs7qrvIHl7tL7dGY2
n76iyX0SI3QEPHnm99w+KjUv5XzOuFSIJIzFsbuywZTN96VH9fkDKIS6qhWmyvYj
djTdyPMhFqhDcnuC4ZMRsk/SKm1LCR2rj/GgNe3BlZKV81P04sKshVo+Z1IhiG8n
HZjn/APxLc/fZm/OcUIeZ3i9ANpD3/A4Snwc7/BNRWg6uO845xXIuJRyPRPpOfQv
6SVlhxeQG5aPqMxMjbc1LFD9KSvQKX5CEQWR1NM9od7GPfs/aa1YO3BaPfvT90h+
Hi9jbVNX4/oBJJ4eFiEjaCOzC5/6GIern1HYvnRvwZC5Ex2N9DgD/oz71lRTUAxA
JlSIRwL9ndoz2NSYISsV4d736jJ6EWtBHIk9+6y30D8KFzC3AsK3mmTroV7FuIA5
TsjeJvzgRrZWInudDPWqZsqXI4NOKbH2X7TPyQDLkoeKGky9LtS9Z6j8BMZraivO
QCIzOelZ/tlCsnXs1ftcgpNktDIaSTqOpLgF5YOVfkvRZYHvtf7AiS4f1iMM24jN
ooPWblioZGROAjxIR4/znjqWr4dVF8sv0aoSOeF6TgpxHrNBx2aWDHJYTd1u3s/F
POpn4AzdzvZOiOpSf/Cusm/ubCVRNoVSXxZPwsb8gzHivzJ3y+I=
=IFgM
-END PGP SIGNATURE-

Bug#996973: ITP: msc-generator -- Draws signalling charts from textual description

[Gábor Németh]

Package: wnpp
Severity: wishlist
Owner: Gábor Németh 
X-Debbugs-Cc: debian-de...@lists.debian.org, rody...@riseup.net

* Package name: msc-generator
  Version : 7.0.1
  Upstream Author : Zoltan Turanyi 
* URL : https://sourceforge.net/p/msc-generator/
* License : AGPL
  Programming Lang: C++
  Description : Draws signalling charts from textual description

Msc-generator is a program that parses textual Message Sequence
Chart descriptions and produces graphical output in a variety of file formats.

Msc-generator heavily borrows in concept from the 0.08 version of
Michael C McTernan's mscgen. However, it has been completely rewritten from
scratch and has a much more extensive (and only partially backwards compatible)
language. The command-line interface is fully backwards compatible with
mscgen, which enables using Msc-generator's commandline tool everywhere
where you can use mscgen, but with the richer syntax.
This includes the many tools integrated with mscgen, such as Doxygen, Sphinx
and Msctexen.

I am already packaging it in my Ubuntu Launchpad PPA, and it is used by some
(including myself). I wish to bring it to Debian proper though.
I can maintain the package myself, but need a sponsor.

Bug#996971: systemd: clamav service units fail with StandardOutput=syslog

[Michael Biebl]

[always CC the bug report email address on replies]

Am 21.10.21 um 20:25 schrieb Brown, Thomas:


On 10/21/21 2:14 PM, Michael Biebl wrote:

Control: reassign -1 clamav-daemon


Not sure why you filed this against the systemd package when the 
service file in question is shipped by clamav-daemon.

Reassigning accordingly.

This is a systemd problem that occurs when attempting to launch 
clamav-daemon.


systemd[1]: Condition check resulted in Clam AntiVirus userspace daemon 
being skipped.


This condition is specified by the clamav-daemon.service though.
I assume this means that the clamav daemon package is not properly 
set-up. not an issue of systemd.



These logs occur continuously while the clamav db is being downloaded.

We suspect that this problem may also be occurring with the 
ConditionPathExistsGlob field on an alternate platform when the clamav 
db download is rate limited.




Am 21.10.21 um 18:48 schrieb Brown, Thomas:


Package: systemd
Version: 247.3-6
Severity: important

Dear Maintainer,


With the default clamav buster version, 103, the service unit field
StandardOutput is set to syslog in clamav-daemon.service and
clamav-freshclam.service.  This ends up causing the following type of
error messages...

systemd[1]: Condition check resulted in Clam AntiVirus userspace daemon
being skipped.

which degrades the system performance significantly.

The field has been removed in clamav version 104 and an additional
message indicate that this field is problematic...

Oct 15 13:47:18 oct-test systemd[1]:
/lib/systemd/system/clamav-daemon.service:12:
Standard output type syslog is obsolete, automatically updating to
journal.
Please update your unit file, and consider removing the setting
altogether.

The only way to effectively address this problem appears to be removing
it from the service unit definition files under /lib. Using overrides
does not appear to correct this problem.


You can always override it by using a full copy in 
/etc/systemd/system/ or a drop-in snippet in 
/etc/systemd/system/clamav-daemon.service.d/


The "Condition check resulted in Clam AntiVirus userspace daemon being 
skipped" error is only resolved by removing it from the service unit 
definition files under /lib not with the full copy or drop in snippet.




-- Package-specific info:

-- System Information:
MEL Name: Siemens Industrial OS
   MEL Release: 3.0
   MEL Build: [undefined]
   Debian Release: 11.1
   MEL Features: 
active-directory,antivirus,apt,auditing,firewall,hardening,lttng,manifest,monitor,network-manager,offline-apt,perf,preempt_rt,rebuild-kernel,regular-user,selinux,s 


etup,ssh-server,tools-debug,tools-profile,total-uptime,udev,usrmerge
   Hostname: oct-test
   Host ID: none
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.59-rt52+ind1 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) 
(ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 
(charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages systemd depends on:
ii  adduser    3.118
ii  libacl1    2.2.53-10
ii  libapparmor1   2.13.6-10
ii  libaudit1  1:3.0-2
ii  libblkid1  2.36.1-8
ii  libc6  2.31-13+deb11u2
ii  libcap2    1:2.44-1
ii  libcrypt1  1:4.4.18-4
ii  libcryptsetup12    2:2.3.5-1
ii  libgcrypt20    1.8.7-6
ii  libgnutls30    3.7.1-5
ii  libgpg-error0  1.38-2
ii  libip4tc2  1.8.7-1
ii  libkmod2   28-1
ii  liblz4-1   1.9.3-2
ii  liblzma5   5.2.5-2
ii  libmount1  2.36.1-8
ii  libpam0g   1.4.0-9+deb11u1
ii  libseccomp2    2.5.1-1
ii  libselinux1    3.1-3
ii  libsystemd0    247.3-6
ii  libzstd1   1.4.8+dfsg-2.1
ii  mount  2.36.1-8
ii  ntp [time-daemon]  1:4.2.8p15+dfsg-1
ii  util-linux 2.36.1-8

Versions of packages systemd recommends:
ii  dbus  1.12.20-2

Versions of packages systemd suggests:
ii  policykit-1    0.105-31
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.140
pn  libnss-systemd   
ii  libpam-systemd   247.3-6
ii  udev 247.3-6

-- no debconf information








OpenPGP_signature
Description: OpenPGP digital signature

Bug#996949: python-envparse3 repairable in principle with higher-version .deb

[Ian Jackson]

Hi, FYI:

I spoke to Neil about this bug on IRC and was curious about the
behaviour of dpkg, which I thought had a fallback for this kind of
situation.

The fact that trying to reinstall a *lower-versioned* non-broken .deb
didn't work was a bug, which Guillem is going to sort out.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996959

(I don't think this is an immediately-useful workaround because no such
.deb exists in the archive right now.)

Regards,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#996955: task-desktop silently pulls in task-desktop-gnome via Recommends

[Holger Wansing]

Hi,

Fabian Greffrath  wrote (Thu, 21 Oct 2021 12:25:35 +0200):
> I just installed Debian stable in a virtual machine. When I was asked
> during the installation process which "meta-packages" to install I
> left "Desktop Environment" selected but explicitly deselected GNOME. I
> expected to end up with a minimal graphical environment, e.g. X with
> twm and xterm or similar. However, I was surprised to find out after
> installation that indeed the entire GNOME desktop was installed albeit
> me explicitly deselecting it during installation.

Selecting "Desktop Environment", but not choose one of the displayed 
possiblities (like "GNOME", "KDE" and so on) is not the way, how this
dialog was designed, I guess.

If you want a graphical desktop, select "Desktop Environment" and one of
the options under it; or if you dont't want a graphical UI, deselect all
those options.
There is no way in between of these two.

This is not optimal of course, and there have been reports from people, who
where irritated by the functionality of this dialog in the past as well.

I could imagine a solution, where the checkbox in the first line "Desktop 
Environment" is not directly changeable at all, but gets automatically 
checked or unchecked, if the user selects one of the desktop environment 
options below (or does not check any of them).
Or the first line having no checkbox at all would be even better.

Don't know, if something like this is possible with debconf...


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#996959: Revert (or document) 9d3ec0f5 (prerm fallback version test)

[Ian Jackson]

Guillem Jover writes ("Re: Bug#996959: Revert (or document) 9d3ec0f5 (prerm 
fallback version test)"):
> No, I've just reverted this locally and will be included in the next
> upload. Thanks for the digging and analysis.

Cool, thanks, you're welcome.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#996972: ITP: addrwatch -- Ethernet/IP address monitoring tool

[Tris Emmy Wilson]

Package: wnpp
Severity: wishlist

* Package name: addrwatch
  Version : 1.0.2
  Upstream Author : Julius Kriukas 
* URL : https://github.com/fln/addrwatch
* License : GPL-3
  Programming Lang: C
  Description : Ethernet/IP address monitoring tool

addrwatch is a tool similar to arpwatch. It monitors the network for ARP,
ICMPv6 Neighbor Discovery, and ICMPv6 Duplicate Address Detection messages,
and logs the discovered IP and Ethernet address pairs.

I use addrwatch across a dozen or so machines to log IPv4 address and
Ethernet address association changes (this is exactly the functionality
of arpwatch). However, addrwatch also provides similar monitoring
functionality for IPv6 address and Ethernet address association
monitoring using ICMPv6 Neighbor Discovery -- this functionality is
missing from arpwatch.

ndpmon provides the NDP monitoring functionality, but is not available
in bullseye -- it also does not provide ARP monitoring functionality.
addrwatch seems to be a better tool for dual-stack networks.

I plan to seek sponsorship for this package.

Bug#996028: InnoDB: corrupted TRX_NO after upgrading to 10.3.31

[Marc Gallet]

Package: mariadb-server
Followup-For: Bug #996028

Hi,

I've been brought to this bug by apt-listbugs while doing upgrades
on my buster install, warning me of a grave bug.

I have not attempted the upgrade yet, since, after reading this bug, I
see a risk of data corruption and I would like to avoid going into
recovery procedures (from backups) as a result of what should be a
stable upgrade.

It seems there was an attempt at fixing the problem for buster, but this
hasn't been pushed as a new version yet, right?

Am I correct to assume this issue is still relevant for buster and that
for now, I should simply defer the upgrade (marking the packages to be
held back) and simply wait for this bug to be resolved?

Thanks

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

Kernel: Linux 4.19.0-18-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mariadb-server depends on:
hi  mariadb-server-10.3  1:10.3.29-0+deb10u1

mariadb-server recommends no packages.

mariadb-server suggests no packages.

-- no debconf information

Bug#996911: systemd: dbus signal JobRemoved for a failed job is 'done' instead of 'failed'

[Michael Biebl]

Am 21.10.21 um 10:11 schrieb Alexandre Rossi:

Also I'll try to fix davmail following your advice.


Great, thanks!
If you have any other questions, please don't hesitate to ask.

Regards,
Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996971: systemd: clamav service units fail with StandardOutput=syslog

[Michael Biebl]

Control: reassign -1 clamav-daemon


Not sure why you filed this against the systemd package when the service 
file in question is shipped by clamav-daemon.

Reassigning accordingly.


Am 21.10.21 um 18:48 schrieb Brown, Thomas:


Package: systemd
Version: 247.3-6
Severity: important

Dear Maintainer,


With the default clamav buster version, 103, the service unit field
StandardOutput is set to syslog in clamav-daemon.service and
clamav-freshclam.service.  This ends up causing the following type of
error messages...

systemd[1]: Condition check resulted in Clam AntiVirus userspace daemon
being skipped.

which degrades the system performance significantly.

The field has been removed in clamav version 104 and an additional
message indicate that this field is problematic...

Oct 15 13:47:18 oct-test systemd[1]:
/lib/systemd/system/clamav-daemon.service:12:
Standard output type syslog is obsolete, automatically updating to
journal.
Please update your unit file, and consider removing the setting
altogether.

The only way to effectively address this problem appears to be removing
it from the service unit definition files under /lib. Using overrides
does not appear to correct this problem.


You can always override it by using a full copy in /etc/systemd/system/ 
or a drop-in snippet in /etc/systemd/system/clamav-daemon.service.d/




-- Package-specific info:

-- System Information:
MEL Name: Siemens Industrial OS
   MEL Release: 3.0
   MEL Build: [undefined]
   Debian Release: 11.1
   MEL Features: 
active-directory,antivirus,apt,auditing,firewall,hardening,lttng,manifest,monitor,network-manager,offline-apt,perf,preempt_rt,rebuild-kernel,regular-user,selinux,s 


etup,ssh-server,tools-debug,tools-profile,total-uptime,udev,usrmerge
   Hostname: oct-test
   Host ID: none
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.59-rt52+ind1 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) 
(ignored: LC_ALL set to en_US.UTF-8)

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages systemd depends on:
ii  adduser    3.118
ii  libacl1    2.2.53-10
ii  libapparmor1   2.13.6-10
ii  libaudit1  1:3.0-2
ii  libblkid1  2.36.1-8
ii  libc6  2.31-13+deb11u2
ii  libcap2    1:2.44-1
ii  libcrypt1  1:4.4.18-4
ii  libcryptsetup12    2:2.3.5-1
ii  libgcrypt20    1.8.7-6
ii  libgnutls30    3.7.1-5
ii  libgpg-error0  1.38-2
ii  libip4tc2  1.8.7-1
ii  libkmod2   28-1
ii  liblz4-1   1.9.3-2
ii  liblzma5   5.2.5-2
ii  libmount1  2.36.1-8
ii  libpam0g   1.4.0-9+deb11u1
ii  libseccomp2    2.5.1-1
ii  libselinux1    3.1-3
ii  libsystemd0    247.3-6
ii  libzstd1   1.4.8+dfsg-2.1
ii  mount  2.36.1-8
ii  ntp [time-daemon]  1:4.2.8p15+dfsg-1
ii  util-linux 2.36.1-8

Versions of packages systemd recommends:
ii  dbus  1.12.20-2

Versions of packages systemd suggests:
ii  policykit-1    0.105-31
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.140
pn  libnss-systemd   
ii  libpam-systemd   247.3-6
ii  udev 247.3-6

-- no debconf information





OpenPGP_signature
Description: OpenPGP digital signature

Bug#996856: libcamera: Update package to a more recent version

[Carsten Schoenert]

Hello Dorota,

Am 20.10.21 um 15:50 schrieb Dorota Czaplejewicz:
...

Currently lintian shows these interesting tags after a package build:


$ lintian -IE
E: libcamera-dev: lacks-ldconfig-trigger usr/lib/x86_64-linux-gnu/v4l2-compat.so


I think this error isn't a real error lintian is thinking about, the .so
file is within the -dev package is a real file and not a symlink as
usual in a -dev package.
OTOH I don't know enough about libcamera currently, is this file then
within the correct binary package? Or needs upstream to change the way
this library is built?


As far as I understand it, this file is not only useful for
development, so it should be in a non--dev package. It's part of a
compatibility layer that's meant to be used by applications at
runtime.


that was my thinking too after a while, it's maybe an oversight that 
this shared object file isn't places into the lib package (libcamera0).
Otherwise it doesn't make any sense for me to install v4l2-compat.so 
into the -dev package without any symlinks for versioning (which aren't 
available or provided currently).


Changing this in the packaging let lintian still warns about missing 
unversioned symlinks, but yeah, there is no versioning of v4l2-compat.so :)


...

Please let me know if it's possible to proceed and if you are interested
to pull in my current work.
If there are things we need to address upstream I think that this
partially can be done by Dorota at one point, I'm sure she will also
figure out things that need to get fixed, discussed or changed upstream.


I pushed my current WIP to https://salsa.debian.org/tijuca/libcamera


I checked the repository, and you left out the soname patch, but it
does not apply to ./src/libcamera/meson.build. It might apply to
./meson.build though, after some changes.


First I wasn't see your point, then I've looked again at the build log,


../src/libcamera/meson.build:129: WARNING: Keyword argument "version" defined 
multiple times.
WARNING: This will be an error in future Meson releases.


and yes, upstream is now also set up a version variable so we don't want 
this patch applying any more I guess.



129 libcamera = shared_library('libcamera',
130libcamera_sources,
131version : libcamera_version,   <--- upstream
132name_prefix : '',
133install : true,
134include_directories : includes,
135build_rpath : '/',
136dependencies : libcamera_deps)



$ git grep -n libcamera_version
...
include/libcamera/meson.build:78:version = libcamera_version.split('.')
include/libcamera/meson.build:79:libcamera_version_config = configuration_data()
include/libcamera/meson.build:80:libcamera_version_config.set('LIBCAMERA_VERSION_MAJOR',
 version[0])
include/libcamera/meson.build:81:libcamera_version_config.set('LIBCAMERA_VERSION_MINOR',
 version[1])
include/libcamera/meson.build:82:libcamera_version_config.set('LIBCAMERA_VERSION_PATCH',
 version[2])
include/libcamera/meson.build:86:   configuration : 
libcamera_version_config,
meson.build:15:# the libcamera_version variable contains the major.minor.patch 
(e.g. 1.2.3)
meson.build:25:libcamera_version = libcamera_git_version.split('+')[0]
src/libcamera/base/meson.build:50:version : 
libcamera_version,
src/libcamera/meson.build:131:   version : 
libcamera_version,


The soname.patch was added directly in preparation of the Debian 
packaging on top of the first imported upstream version.
Upstream changed and modified the variable 'version' from '0.1' to 
'0.0.0' since the import of 0~git20190625+cb21bb3 (the first imported 
version) but the patch wasn't turned back.


So currently the Debian packaging is adding a version 0.1.0 to the 
created shared library files while upstream is still using 0.0.0. I 
think it's not correct to still use the Debian added version and the 
patch should be dropped.
OTOH the library isn't real versioned nor is using a stable ABI/API. 
I've no idea how the future plans of upstream are.


I've done two modifications to the packaging (removing soname.patch and 
move v4l2-compat.so into libcamera0) and forced pushed this to my WIP tree.


--
Regards
Carsten Schoenert


OpenPGP_signature
Description: OpenPGP digital signature

Bug#941199: Upstream has valid debian packaging

[Tom W]

Is anyone looking into this? I sense increasing demand for swtpm +
qemu for Win 11 VM.

Bug#926896: sysvinit-utils: pidof is unreliable

[Jesse Smith]

> The RedHat bug that was the similar issue to #719273 (i.e. that
> resulted in the behaviour of pidof being changed) took a slightly
> different approach -
> https://bugzilla.redhat.com/show_bug.cgi?id=138788 (patch is
> https://bugzilla.redhat.com/attachment.cgi?id=113650=diff );
> did that ever make its way to upstream?

The Red Hat patch was a bit older, but I believe I've got it adjusted
and merged in okay. I've done some tests here and it looks like
everything is working with the newly patched pidof.

Here is what should happen now:

"pidof " should, without flags, display any processes
matches it finds, _except_ zombie processes. Basically anything running,
sleeping, or in uninterruptable sleep should now show up.

"pidof -z " should return all matching processes,
including those in the zombie state.

The attached patch also cleans up some code we don't need as a result of
this change and updates the man page.

Please give the attached patch a try and confirm it's working.  It's
working here for normal and zombie processes and it seems to be okay for
uninterruptable sleep processes too, but I'd like to have someone else
confirm everything looks right before I push this upstream.

- Jesse

diff --git a/man/pidof.8 b/man/pidof.8
index ebe5f55..84ed1e4 100644
--- a/man/pidof.8
+++ b/man/pidof.8
@@ -66,9 +66,12 @@ a status of true or false to indicate whether a matching PID was found.
 Scripts too - this causes the program to also return process id's of
 shells running the named scripts.
 .IP \-z
-Try to detect processes which are stuck in uninterruptible (D) or zombie (Z)
+Try to detect processes which are stuck in zombie (Z)
 status. Usually these processes are skipped as trying to deal with them can cause
-pidof to hang. 
+pidof or related tools to hang. Note: In the past pidof would ignore processes
+in the uninterruptable state (D), unless the \-z flag was specified. This is no
+longer the case. The pidof program will find and report processes in the D state
+whether \-z is specified or not.
 .IP "-d \fIsep\fP"
 Tells \fIpidof\fP to use \fIsep\fP as an output separator if more than one PID
 is shown. The default separator is a space.
diff --git a/src/killall5.c b/src/killall5.c
index 22d29dc..b0728fa 100644
--- a/src/killall5.c
+++ b/src/killall5.c
@@ -67,9 +67,6 @@
 #endif
 
 #define STATNAMELEN	15
-#define DO_NETFS 2
-#define DO_STAT 1
-#define NO_STAT 0
 
 /* Info about a process. */
 typedef struct proc {
@@ -79,8 +76,6 @@ typedef struct proc {
 	char *argv1;		/* Name as found out from argv[1] */
 	char *argv1base;	/* `basename argv[1]`		  */
 	char *statname;		/* the statname without braces*/
-	ino_t ino;		/* Inode number			  */
-	dev_t dev;		/* Device it is on		  */
 	pid_t pid;		/* Process ID.			  */
 	pid_t sid;		/* Session ID.			  */
 	char kernel;		/* Kernel thread or zombie.	  */
@@ -481,19 +476,17 @@ int readarg(FILE *fp, char *buf, int sz)
  *	Read the proc filesystem.
  *	CWD must be /proc to avoid problems if / is affected by the killing (ie depend on fuse).
  */
-int readproc(int do_stat)
+int readproc()
 {
 	DIR		*dir;
 	FILE		*fp;
 	PROC		*p, *n;
 	struct dirent	*d;
-	struct stat	st;
 	char		path[PATH_MAX+1];
 	char		buf[PATH_MAX+1];
 	char		*s, *q;
 	unsigned long	startcode, endcode;
 	int		pid, f;
-	ssize_t		len;
 charprocess_status[11];
 
 	/* Open the /proc directory. */
@@ -600,12 +593,8 @@ int readproc(int do_stat)
 p->kernel = 1;
 			fclose(fp);
 if ( (! list_dz_processes) &&
- ( (strchr(process_status, 'D') != NULL) ||
-   (strchr(process_status, 'Z') != NULL) ) ){
-   /* Ignore zombie processes or processes in
-  disk sleep, as attempts
-  to access the stats of these will
-  sometimes fail. */
+   (strchr(process_status, 'Z') != NULL) ) {
+   /* Ignore zombie processes */
   if (p->argv0) free(p->argv0);
   if (p->argv1) free(p->argv1);
   if (p->statname) free(p->statname);
@@ -672,55 +661,10 @@ int readproc(int do_stat)
 
 		/* Try to stat the executable. */
 		snprintf(path, sizeof(path), "/proc/%s/exe", d->d_name);
-
-		p->nfs = 0;
-
-		switch (do_stat) {
-		case DO_NETFS:
-			if ((p->nfs = check4nfs(path, buf)))
-goto link;
-/* else fall through */
-		case DO_STAT:
-			if (stat(path, ) != 0) {
-char * ptr;
-
-len = readlink(path, buf, PATH_MAX);
-if (len <= 0)
-	break;
-buf[len] = '\0';
-
-ptr = strstr(buf, " (deleted)");
-if (!ptr)
-	break;
-*ptr = '\0';
-len -= strlen(" (deleted)");
-
-if (stat(buf, ) != 0)
-	break;
-p->dev = st.st_dev;
-p->ino = st.st_ino;
-p->pathname = (char *)xmalloc(len + 1);
-memcpy(p->pathname, buf, 

Bug#996968: bts: uses the deprecated 'close' control command

[Mattia Rizzolo]

Control: tag -1 moreinfo

On Thu, Oct 21, 2021 at 12:12:24PM -0400, Ryan Kavanagh wrote:
> The 'bts done' command uses the 'close' control command to close bug
> reports. This command has been deprecated for almost 20 years (since at
> least February 2002) [0,1] and goes against the best practices set out
> in §5.8.2 of the developer's reference:
> 
> You should never close bugs via the bug server close command sent to
> cont...@bugs.debian.org. If you do so, the original submitter will
> not receive any information about why the bug was closed. [2]
> 
> Please use nnn-d...@bugs.debian.org instead.

I really disagree.

There are uses of closing a bug without notifying anybody, and I really
want `bts` to retain that use.

If you are going to do something notifying people, you already really
ought to write a longer mail, at that point you may as well send the
mail to -done@ yourself, IMHO.

> Similarly, the undocumented command 'bts close' should be dropped.

funnily enough, I don't think I ever used `bts done` but I used
`bts close` many times  :D  I never even realized it was undocumented…

(fwiw, I also normally mail -close@ instead of -done@, "done"
is just too hard on my mind since I really want to close a bug, not
"mark it as done", whatever that means.)

-- 
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#996662: Additional information

[debian-testing]

Yangfl: Symlink outside of home, for example, if on a symlinked network drive 
or usb, etc.

Directory has appropriate permissions. Seems to be apparmor (see my more recent 
post), since works when apparmor is deactivate.

Sent with [ProtonMail](https://protonmail.com) Secure Email.

Bug#996955: task-desktop silently pulls in task-desktop-gnome via Recommends

[Philip Hands]

Holger Wansing  writes:

> Hi,
>
> Fabian Greffrath  wrote (Thu, 21 Oct 2021 12:25:35 +0200):
>> I just installed Debian stable in a virtual machine. When I was asked
>> during the installation process which "meta-packages" to install I
>> left "Desktop Environment" selected but explicitly deselected GNOME. I
>> expected to end up with a minimal graphical environment, e.g. X with
>> twm and xterm or similar. However, I was surprised to find out after
>> installation that indeed the entire GNOME desktop was installed albeit
>> me explicitly deselecting it during installation.
>
> Selecting "Desktop Environment", but not choose one of the displayed 
> possiblities (like "GNOME", "KDE" and so on) is not the way, how this
> dialog was designed, I guess.
>
> If you want a graphical desktop, select "Desktop Environment" and one of
> the options under it; or if you dont't want a graphical UI, deselect all
> those options.
> There is no way in between of these two.

The outcome is the same if one does any of: setting just "Desktop
Environment"; setting just Gnome; or setting both of them at the same
time.  The reason being that setting just "Desktop Environment" results
in you getting the default desktop, which currently happens to be Gnome.

If there was a way of making "Desktop Environment" be a section heading
instead, without it having a checkbox next to it, that would have been
done, but AFAIK that is not currently possible with the way that the
menu is assembled.

Sadly, that's rather misleading.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY

Bug#983871: error: internal error: failed to get cgroup backend for 'pathOfController'

[Dio Putra]

Hi, this bug just happened right in front of me (see my picture attachment).
Fortunately, I was able to create a rebase patch to Debian Bullseye:
https://listman.redhat.com/archives/libvir-list/2021-April/msg00756.html

Here's my patch:
>From ea7d0ca37cce76e1327945c4864b996d7fd6d2e6 Mon Sep 17 00:00:00 2001
Message-Id: 

From: Michal Privoznik 
Date: Fri, 16 Apr 2021 16:39:14 +0200
Subject: [PATCH] vircgroup: Fix virCgroupKillRecursive() wrt nested
 controllers
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

I've encountered the following bug, but only on Gentoo with
systemd and CGroupsV2. I've started an LXC container successfully
but destroying it reported the following error:

  error: Failed to destroy domain 'amd64'
  error: internal error: failed to get cgroup backend for 'pathOfController'

Debugging showed, that CGroup hierarchy is full of surprises:

/sys/fs/cgroup/machine.slice/machine-lxc\x2d861\x2damd64.scope/
└── libvirt
├── dev-hugepages.mount
├── dev-mqueue.mount
├── init.scope
├── sys-fs-fuse-connections.mount
├── sys-kernel-config.mount
├── sys-kernel-debug.mount
├── sys-kernel-tracing.mount
├── system.slice
│   ├── console-getty.service
│   ├── dbus.service
│   ├── system-getty.slice
│   ├── system-modprobe.slice
│   ├── systemd-journald.service
│   ├── systemd-logind.service
│   └── tmp.mount
└── user.slice

For comparison, here's the same container on recent Rawhide:

/sys/fs/cgroup/machine.slice/machine-lxc\x2d13550\x2damd64.scope/
└── libvirt

Anyway, those nested directories should not be a problem, because
virCgroupKillRecursiveInternal() removes them recursively, right?
Sort of. The function really does remove nested directories, but
it assumes that every directory has the same controller as the
rest. Just take a look at virCgroupV2KillRecursive() - it gets
'Any' controller (the first one it found in ".scope") and then
passes it to virCgroupKillRecursiveInternal().

This assumption is not true though. The controllers found in
".scope" are the following:

  cpuset cpu io memory pids

while "libvirt" has fewer:

  cpuset cpu io memory

Up until now it's not problem, because of how we order
controllers internally - "cpu" is the first and thus picking
"Any" controller returns just that. But the rest of directories
has no controllers, their "cgroup.controllers" is just empty.

What fixes the bug is dropping @controller argument from
virCgroupKillRecursiveInternal() and letting each iteration work
pick its own controller.

Signed-off-by: Michal Privoznik 
Reviewed-by: Pavel Hrdina 
---
 src/util/vircgroup.c | 29 +
 src/util/vircgrouppriv.h |  1 -
 src/util/vircgroupv1.c   |  7 +--
 src/util/vircgroupv2.c   |  7 +--
 4 files changed, 27 insertions(+), 17 deletions(-)

Signed-off-by: Dio Putra 
---
--- libvirt-7.0.0.orig/src/util/vircgroup.c
+++ libvirt-7.0.0/src/util/vircgroup.c
@@ -1380,6 +1380,24 @@
 }


+static int
+virCgroupGetAnyController(virCgroup *cgroup)
+{
+size_t i;
+
+for (i = 0; i < VIR_CGROUP_BACKEND_TYPE_LAST; i++) {
+if (!cgroup->backends[i])
+continue;
+
+return cgroup->backends[i]->getAnyController(cgroup);
+}
+
+virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
+   _("Unable to get any controller"));
+return -1;
+}
+
+
 int
 virCgroupPathOfController(virCgroupPtr group,
   unsigned int controller,
@@ -2548,18 +2566,21 @@
 virCgroupKillRecursiveInternal(virCgroupPtr group,
int signum,
GHashTable *pids,
-   int controller,
const char *taskFile,
bool dormdir)
 {
 int rc;
+int controller;
 bool killedAny = false;
 g_autofree char *keypath = NULL;
 g_autoptr(DIR) dp = NULL;
 struct dirent *ent;
 int direrr;
-VIR_DEBUG("group=%p signum=%d pids=%p",
-  group, signum, pids);
+VIR_DEBUG("group=%p signum=%d pids=%p taskFile=%s dormdir=%d",
+  group, signum, pids, taskFile, dormdir);
+
+if ((controller = virCgroupGetAnyController(group)) < 0)
+return -1;

 if (virCgroupPathOfController(group, controller, "", ) < 0)
 return -1;
@@ -2593,7 +2614,7 @@
 return -1;

 if ((rc = virCgroupKillRecursiveInternal(subgroup, signum, pids,
- controller,
taskFile, true)) < 0)
+ taskFile, true)) < 0)
 return -1;
 if (rc == 1)
 killedAny = true;
--- libvirt-7.0.0.orig/src/util/vircgrouppriv.h
+++ libvirt-7.0.0/src/util/vircgrouppriv.h
@@ -128,6 +128,5 @@ int virCgroupRemoveRecursively(char *grp
 int virCgroupKillRecursiveInternal(virCgroupPtr group,
int 

Bug#996955: task-desktop silently pulls in task-desktop-gnome via Recommends

[Brian Potkin]

On Thu 21 Oct 2021 at 17:27:22 +0200, Fabian Greffrath wrote:

> Hi Holger,
> 
> thanks for your reply!
> 
> Am 21.10.2021 16:31, schrieb Holger Wansing:
> > Selecting "Desktop Environment", but not choose one of the displayed
> > possiblities (like "GNOME", "KDE" and so on) is not the way, how this
> > dialog was designed, I guess.
> 
> Yes, apparently. :/

I think this is exactly the way it was designed. Whether the design
is the best is what has been brought up in this report.

There is the concept of "default desktop". At the present time it is
Gnome. The first selection is for the default. The description for
task-desktop says:

  This task package is used to install the Debian desktop.

Regards,

Brian.

Bug#996662: Additional information

[debian-testing]

It seems like apparmor is blocking access to the symlink target. Qtox works 
with symlinks after deactivating apparmor. I guess the qtox apparmor profile 
needs to be corrected.

apparmor="DENIED" operation="open" profile="qtox" 
name="/test/.config/tox/qtox.ini" pid=1082 comm="qtox" requested_mask="r" 
denied_mask="r" fsuid=1000 ouid=1000
apparmor="DENIED" operation="open" profile="qtox" 
name="/test/.config/tox/test.tox" pid=1082 comm="qtox" requested_mask="r" 
denied_mask="r" fsuid=1000 ouid=1000
apparmor="DENIED" operation="mknod" profile="qtox" 
name="/test/.config/tox/test.lock" pid=1082 comm="qtox" requested_mask="c" 
denied_mask="c" fsuid=1000 ouid=1000

Bug#994405: Patch from upstream.

[Marco Bodrato]

Ciao!

There is a patch from upstream related to this issue.

https://gmplib.org/repo/gmp-6.2/rev/561a9c25298e

Ĝis,
m

Bug#996958: ITP: mumax -- GPU accelerated micromagnetic simulator

[Thaddeus H. Black]

> This sentence was copy/pasted from http://mumax.github.io/. I haven't really
> started working on the package yet, nor am I a regular user.

I see.

> I guess you should ask upstream rather than me, I'm just a poor packager in
> this case :-)

Thanks.


signature.asc
Description: PGP signature

Bug#926896: sysvinit-utils: pidof is unreliable

[Matthew Vernon]

Hi,

On 20/10/2021 15:29, Jesse Smith wrote:

Is there a reason for wanting to revert this behaviour instead of using
the "-z" flag on the command line? If you use pidof a lot and expect to
see processes that are in the uninterruptable sleep state then making an
alias of pidof='pidof -z' seems like a straight forward approach.

Reverting the change entirely means the default behaviour could hang in
NFS environments and I'm not sure non-functioning is a better situation
than skipping sleeping processes.


The RedHat bug that was the similar issue to #719273 (i.e. that resulted 
in the behaviour of pidof being changed) took a slightly different 
approach - https://bugzilla.redhat.com/show_bug.cgi?id=138788 (patch is 
https://bugzilla.redhat.com/attachment.cgi?id=113650=diff ); did 
that ever make its way to upstream?


My feeling is that I'd like us to follow upstream's approach here (hi 
Jesse :) ); it's not obvious to me that having "do look at D processes" 
be an optional switch is wrong.


Regards,

Matthew

Bug#926896: sysvinit-utils: pidof is unreliable

[Jesse Smith]

On 2021-10-21 1:40 p.m., Matthew Vernon wrote:
> Hi,
>
> On 20/10/2021 15:29, Jesse Smith wrote:
>> Is there a reason for wanting to revert this behaviour instead of using
>> the "-z" flag on the command line? If you use pidof a lot and expect to
>> see processes that are in the uninterruptable sleep state then making an
>> alias of pidof='pidof -z' seems like a straight forward approach.
>>
>> Reverting the change entirely means the default behaviour could hang in
>> NFS environments and I'm not sure non-functioning is a better situation
>> than skipping sleeping processes.
>
> The RedHat bug that was the similar issue to #719273 (i.e. that
> resulted in the behaviour of pidof being changed) took a slightly
> different approach -
> https://bugzilla.redhat.com/show_bug.cgi?id=138788 (patch is
> https://bugzilla.redhat.com/attachment.cgi?id=113650=diff );
> did that ever make its way to upstream?
>

I don't think this Red Hat patch ever made its way upstream. I'll give
it a test run. If it doesn't break anything it may prove to be a good
solution that makes everyone happy.

Bug#996971: systemd: clamav service units fail with StandardOutput=syslog

[Brown, Thomas]

Package: systemd
Version: 247.3-6
Severity: important

Dear Maintainer,


With the default clamav buster version, 103, the service unit field
StandardOutput is set to syslog in clamav-daemon.service and
clamav-freshclam.service.  This ends up causing the following type of
error messages...

systemd[1]: Condition check resulted in Clam AntiVirus userspace daemon
being skipped.

which degrades the system performance significantly.

The field has been removed in clamav version 104 and an additional
message indicate that this field is problematic...

Oct 15 13:47:18 oct-test systemd[1]:
/lib/systemd/system/clamav-daemon.service:12:
Standard output type syslog is obsolete, automatically updating to
journal.
Please update your unit file, and consider removing the setting
altogether.

The only way to effectively address this problem appears to be removing
it from the service unit definition files under /lib. Using overrides
does not appear to correct this problem.

-- Package-specific info:

-- System Information:
MEL Name: Siemens Industrial OS
  MEL Release: 3.0
  MEL Build: [undefined]
  Debian Release: 11.1
  MEL Features: 
active-directory,antivirus,apt,auditing,firewall,hardening,lttng,manifest,monitor,network-manager,offline-apt,perf,preempt_rt,rebuild-kernel,regular-user,selinux,s

etup,ssh-server,tools-debug,tools-profile,total-uptime,udev,usrmerge
  Hostname: oct-test
  Host ID: none
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.59-rt52+ind1 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) 
(ignored: LC_ALL set to en_US.UTF-8)

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages systemd depends on:
ii  adduser    3.118
ii  libacl1    2.2.53-10
ii  libapparmor1   2.13.6-10
ii  libaudit1  1:3.0-2
ii  libblkid1  2.36.1-8
ii  libc6  2.31-13+deb11u2
ii  libcap2    1:2.44-1
ii  libcrypt1  1:4.4.18-4
ii  libcryptsetup12    2:2.3.5-1
ii  libgcrypt20    1.8.7-6
ii  libgnutls30    3.7.1-5
ii  libgpg-error0  1.38-2
ii  libip4tc2  1.8.7-1
ii  libkmod2   28-1
ii  liblz4-1   1.9.3-2
ii  liblzma5   5.2.5-2
ii  libmount1  2.36.1-8
ii  libpam0g   1.4.0-9+deb11u1
ii  libseccomp2    2.5.1-1
ii  libselinux1    3.1-3
ii  libsystemd0    247.3-6
ii  libzstd1   1.4.8+dfsg-2.1
ii  mount  2.36.1-8
ii  ntp [time-daemon]  1:4.2.8p15+dfsg-1
ii  util-linux 2.36.1-8

Versions of packages systemd recommends:
ii  dbus  1.12.20-2

Versions of packages systemd suggests:
ii  policykit-1    0.105-31
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.140
pn  libnss-systemd   
ii  libpam-systemd   247.3-6
ii  udev 247.3-6

-- no debconf information

Bug#996935: gnome-shell-extension-shortcuts: settings dialog broken: Error: Type name ShortcutsPrefsWidget is already registered

[Christian Lauinger]

On Thu, 21 Oct 2021 10:28:30 +0800 Paul Wise  wrote:
> Package: gnome-shell-extension-shortcuts
> Version: 1.2.1-1
> Severity: important
> Usertags: crash
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: gnome-shell-41
> File: /usr/share/gnome-
shell/extensions/shortc...@kyle.aims.ac.za/prefs.js
> 
> Now that the extension is compatible with GNOME 41, when
> opening the settings dialog, I get a crash dialog instead:
> 
>    Error: Type name ShortcutsPrefsWidget is already registered
>    
>    Stack trace:
> 
_construct@resource:///org/gnome/gjs/modules/script/_legacy.js:536:31
> 
wrapper@resource:///org/gnome/gjs/modules/script/_legacy.js:83:27
> 
newClass@resource:///org/gnome/gjs/modules/script/_legacy.js:115:21
>  @/usr/share/gnome-
shell/extensions/shortc...@kyle.aims.ac.za/prefs.js:62:30
> 
_init@resource:///org/gnome/Shell/Extensions/js/extensionsService.js:20
6:33
> 
OpenExtensionPrefsAsync/<@resource:///org/gnome/Shell/Extensions/js/ext
ensionsService.js:122:28
> 
asyncCallback@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:1
15:22
> 
run@resource:///org/gnome/Shell/Extensions/js/dbusService.js:177:20
>  main@resource:///org/gnome/Shell/Extensions/js/main.js:19:13
>  run@resource:///org/gnome/gjs/modules/script/package.js:206:19
>  start@resource:///org/gnome/gjs/modules/script/package.js:190:8
>  @/usr/share/gnome-shell/org.gnome.Shell.Extensions:1:17
>   
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing-debug
>   APT policy: (900, 'testing-debug'), (900, 'testing'), (860,
'testing-proposed-updates-debug'), (860, 'testing-proposed-updates'),
(800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'),
(700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-
experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.14.0-3-amd64 (SMP w/8 CPU threads)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8),
LANGUAGE=en_AU:en
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages gnome-shell-extension-shortcuts depends on:
> ii  gnome-shell  41.0-2
> 
> gnome-shell-extension-shortcuts recommends no packages.
> 
> gnome-shell-extension-shortcuts suggests no packages.
> 
> -- no debconf information
> 
> -- 
> bye,
> pabs
> 
> https://wiki.debian.org/PaulWise

I updated to gnome shell 41 (sid). Still the dialog works.
Is really the newest version of the extension used ?

ShortcutsPrefsWidget is only used for major version of gnome returns 3
(Config.PACKAGE_VERSION[0] == 3) - which seems to be the case.
I dont know why tbh.


Greets

Chris

Bug#986821: freecad: Garbled menu makes freecad unusable

[Tobias Frost]

Control: forcemerge -1 987642
Control: forwarded -1 https://tracker.freecadweb.org/view.php?id=4351

Actually, there is a duplicate bug report that have extra information...
Lets merge those and add the meta data that this has been forwarded to upstream
already, but $someone might need to fill in the extra information that scale
values less than 1.0 are a problem... 

It might even be a qt5 problem, but can't tell for sure.

--
tobi

Bug#996970: r-cran-maotai: FTBFS on hppa with gcc-11

[John David Anglin]

Source: r-cran-maotai
Version: 0.2.1-1
Severity: normal

Dear Maintainer,

Build fails with the following error:
g++ -std=gnu++11 -shared -L/usr/lib/R/lib -o maotai.so RcppExports.o cpp_bmds.o 
cpp_casket.o cpp_mmds.o evaluations.o src_computations.o -fopenmp -llapack 
-lblas -lgfortran -lm /usr/lib/gcc/hppa-linux-gnu/10/libgcc.a -L/usr/lib/R/lib 
-lR
/usr/bin/ld: cannot find /usr/lib/gcc/hppa-linux-gnu/10/libgcc.a: No such file 
or directory
collect2: error: ld returned 1 exit status
make[1]: *** [/usr/share/R/share/make/shlib.mk:10: maotai.so] Error 1

It is not clear why the build directly tries to link against libgcc.a
from gcc-10.  The dependencies now for gcc-11 and g++-11 pull in the static
and shared libgcc libraries for gcc-11.  The control file doesn't require
the gcc-10 libraries.  See:
https://buildd.debian.org/status/fetch.php?pkg=r-cran-maotai=hppa=0.2.1-2=1634810036=0

The g++ driver automatically links against libgcc.  Maybe the intent is to link
against the static library.  If so, it now needs to link using the gcc-11
library.

This problem affect multiple r packages.

Regards,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 5.14.14+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#996969: drop 'close' command --- deprecated since at least February 2002

[Ryan Kavanagh]

Package: bugs.debian.org
Severity: wishlist
X-Debbugs-Cc: r...@debian.org

The 'close' command has been deprecated since at least February 2002 [0],
and its use is strongly discouraged by §5.8.2 of the developers
reference:

You should never close bugs via the bug server close command sent to
cont...@bugs.debian.org. If you do so, the original submitter will
not receive any information about why the bug was closed. [1]

After almost 20 years of deprecation, maybe it's time to finally drop
it?

[0] 
https://web.archive.org/web/20020202152705/http://www.debian.org:80/Bugs/server-control
[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#responding-to-bugs

-- 
|)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#996968: bts: uses the deprecated 'close' control command

[Ryan Kavanagh]

Package: devscripts
Version: 2.21.4
Severity: normal
X-Debbugs-Cc: r...@debian.org

The 'bts done' command uses the 'close' control command to close bug
reports. This command has been deprecated for almost 20 years (since at
least February 2002) [0,1] and goes against the best practices set out
in §5.8.2 of the developer's reference:

You should never close bugs via the bug server close command sent to
cont...@bugs.debian.org. If you do so, the original submitter will
not receive any information about why the bug was closed. [2]

Please use nnn-d...@bugs.debian.org instead.

Similarly, the undocumented command 'bts close' should be dropped.

[0] 
https://web.archive.org/web/20020202152705/http://www.debian.org:80/Bugs/server-control
[1] https://www.debian.org/Bugs/server-control#close
[2] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#responding-to-bugs

-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
Not present

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

Kernel: Linux 5.14.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.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 devscripts depends on:
ii  dpkg-dev  1.20.9
ii  fakeroot  1.26-1
ii  file  1:5.39-3
ii  gnupg 2.2.27-2
ii  gnupg22.2.27-2
ii  gpgv  2.2.27-2
ii  gpgv2 2.2.27-2
ii  libc6 2.32-4
ii  libfile-dirlist-perl  0.05-2
ii  libfile-homedir-perl  1.006-1
ii  libfile-touch-perl0.12-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20200505.0-1
ii  libmoo-perl   2.005004-2
ii  libwww-perl   6.57-1
ii  patchutils0.4.2-1
ii  perl  5.32.1-6
ii  python3   3.9.2-3
ii  sensible-utils0.0.17
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 2.3.10
ii  curl7.74.0-1.3+b1
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2021.09.25
ii  dput1.1.0
ii  equivs  2.3.1
ii  libdistro-info-perl 1.0
ii  libdpkg-perl1.20.9
ii  libencode-locale-perl   1.05-1.1
ii  libgit-wrapper-perl 0.048-1
ii  libgitlab-api-v4-perl   0.26-1
ii  liblist-compare-perl0.55-1
ii  liblwp-protocol-https-perl  6.10-1
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 5.08-1
pn  licensecheck
ii  lintian 2.109.0
ii  man-db  2.9.4-2
ii  patch   2.7.6-7
ii  pristine-tar1.49
ii  python3-apt 2.2.1
ii  python3-debian  0.1.42
ii  python3-magic   2:0.4.24-1
ii  python3-requests2.25.1+dfsg-2
ii  python3-unidiff 0.5.5-2
ii  python3-xdg 0.27-2
ii  strace  5.10-1
ii  unzip   6.0-26
ii  wget1.21.2-2+b1
ii  xz-utils5.2.5-2

Versions of packages devscripts suggests:
ii  adequate 0.15.6
ii  at   3.1.23-1.1
ii  autopkgtest  5.17
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20180807cvs-2
ii  build-essential  12.9
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper13.5.2
pn  devscripts-el
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  faketime 
ii  gnuplot-qt [gnuplot] 5.4.1+dfsg1-1
pn  how-can-i-help   
ii  libauthen-sasl-perl  2.1600-1.1
pn  libdbd-pg-perl   
ii  libfile-desktopentry-perl0.22-2
pn  libnet-smtps-perl
pn  libterm-size-perl
ii  libtimedate-perl 2.3300-2
pn  libyaml-syck-perl
pn  mmdebstrap   
pn  mozilla-devscripts   
pn  mutt 
ii  openssh-client [ssh-client]  1:8.4p1-6
ii  piuparts 1.1.5
pn  postgresql-client
pn  pristine-lfs 
ii  quilt0.66-2.1
pn  ratt 
pn  reprotest
pn  svn-buildpackage 
ii  w3m  

Bug#956440: freecad: Should suggest python3-phply for SCAD import.

[Tobias Frost]

> actually, I think it should should suggest python3-ply[1][2].

Well, it Depends: on it already, so I guess this is not sufficient...

--
tobi (realising only here that he is triaging his own bug...)

Bug#996910: linphone: Segmentation fault when registering a sip account

[Dennis Filder]

X-Debbugs-CC: Tiago Bortoletto Vaz 

On Wed, Oct 20, 2021 at 04:49:33PM -0400, Tiago Bortoletto Vaz wrote:
> Hi, thanks for the quick answer,
>
> On Wed, Oct 20, 2021 at 06:48:43PM +0200, Dennis Filder wrote:
> [...]
>
> > When you try to register the account, what steps to you go through?  I
> > presume in the main window you're clicking in this order: Home ->
> > Assistant -> Use a SIP Account.  If so, does Linphone still crash if
> > you omit the "sip:" prefix in the input field "SIP Domain"?  That
> > field must be a resolvable hostname, domain name or an IP address, and
> > unfortunately the input validation in that dialog is not as good as it
> > should be.
>
> Yes, it crashes when I use a domain name without "sip:" prefix.

What domain name are you using?  Also are you doing this from the same
dialog as before?  Because from the log output I would guess you are
using the settings menu instead of the account registering dialog.
Whether a crash happens from within the settings menu that would also
be important to know.  Also, are you running Orca by any chance?

> > If the above advice does not resolve the issue, please give detailed
> > steps on what you click and what information you enter in each field.
> > Also exit Linphone and then start a new Linphone instance from a
> > terminal like this:
> >
> >   catchsegv linphone 2>&1 | tee /tmp/linphone-segfault.txt
> >
> > Then post that file here after it has crashed.
>
> Sure, attached.
>
> Let me know if there is anything else I can do to help.

That was not as illuminating as I had hoped.  If you can, download the
debug symbols package for linphone-desktop (or wherever the segfault
happens) from
http://debug.mirrors.debian.org/debian-debug/pool/main/l/linphone-desktop/
and run it under gdb to get a stack trace.

Regards.

Bug#996708: open-iscsi: unusable with default installation

[Ritesh Raj Sarraf]

Control: tag -1 +confirmed pending


Thank you for reporting it. It is very rare to get a user bug report
during the development cycle.

On Thu, 2021-10-21 at 23:13 +0800, Yangfl wrote:
> > What do you mean by 'manually' ? Invoking the iscsid binary by hand
> > ?
> 
> Yes, `sudo iscsid`.
> 
> And I guess the issue is probably caused by missing
> /usr/lib/systemd/system/iscsid.service in
> https://packages.debian.org/sid/amd64/open-iscsi/filelist . After I
> manually download the service file from git repo, everything goes
> fine.

That was indeed the case. Something must have changed on the systemd
side of things. The debian specific service file used to get auto
picked during build, previously.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#969934: cloud-init: bullseye: sources.list template should switch from /updates to -security

[sub_code . debian]

I sent a fix upstream to the cloud-init project.

https://github.com/canonical/cloud-init/pull/1076

It should be usable as-if to cherry-pick into Bullseye.
-- 
Johann Queuniet



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996967: Please provide a systemd timer in addition to cron.daily

[Faidon Liambotis]

Package: apt-show-versions
Version: 0.22.12+nmu1
Severity: normal

apt-show-versions currently provides a /etc/cron.daily/apt-show-versions
file, to instruct cron daemons to run "apt-show-versions -i" on a daily
basis.

It'd be nice to also support systemd timers instead, as
apt-show-versions is one of the last remaining users of cron on my
system.

The addition should be relatively trivial, and you can follow the steps
of many other packages that have done so. For example, exim4-base does
that, as shipped on standard Debian installs.

Thanks for the consideration!

Best,
Faidon

Bug#994275: Call for votes on "Reverting breaking changes in debianutils"

[Gunnar Wolf]

Thank you very much for starting this vote, Sean.

I vote A > B > F.

> > === Resolution A ===
> >
> > The Technical Committee resolves:
> >
> > 1. The debianutils package must continue to provide the which(1) program
> >until a compatible utility is available in a package that is at least
> >transitively essential in Debian 12.
> >
> >For the Debian 12 release, we expect which(1) to be in either an
> >Essential package or a transitively Essential package (that is, a
> >package that is depended on by an Essential package).
> >
> > 2. The which(1) program must not print any deprecation warnings.
> >
> > 3. We decline to overrule the maintainer of debianutils regarding the
> >use of alternatives.  If another package takes over responsibility
> >for which(1), then the debianutils maintainers and the other
> >package's maintainers should coordinate to choose a suitable
> >mechanism, which might be either versioned Depends/Breaks/Replaces,
> >dpkg-divert, alternatives or something else.
> >
> > 4. The debianutils package must continue to provide the tempfile(1)
> >program until a compatible utility is available in a package that is
> >at least transitively essential in Debian 12.
> >
> >For the Debian 12 release, we expect tempfile(1) to be in either an
> >Essential package or a transitively Essential package.
> >
> > 5. Programs in debianutils must not be moved to /usr until we have a
> >project-wide consensus on going ahead with such a move, and any
> >programs that have already been moved must be moved back.  In
> >particular, this means debianutils must contain /bin/run-parts and
> >/sbin/installkernel for the time being.
> >
> > === Resolution B ===
> >
> > As Resolution A, except strike point (2) and renumber succeeding items.
> >
> > === End Resolutions ===
> >
> > A: Issue Resolution A
> > B: Issue Resolution B
> > F: Further Discussion
> 
> I vote:
> 
> A > B > F



-- 



signature.asc
Description: PGP signature

Bug#978458: freecad: Addon Manager doesn't fetch list of available addons properly

[Tobias Frost]

Control: forcemerge 974129 -1

I guess this is a duplicate of #974129, fixed with uploaded version
0.19~pre1+git20201123.8d73c8f0+dfsg1-1

Bug#996965: ITP: r-cran-bslib -- Custom 'Bootstrap' 'Sass' Themes for 'shiny' and 'rmarkdown'

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-bslib -- Custom 'Bootstrap' 'Sass' Themes for 'shiny' and 
'rmarkdown'
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-cran-bslib
  Version : 0.3.1
  Upstream Author : Carson Sievert,
* URL : https://cran.r-project.org/package=bslib
* License : MIT
  Programming Lang: GNU R
  Description : Custom 'Bootstrap' 'Sass' Themes for 'shiny' and 'rmarkdown'
 Simplifies custom 'CSS' styling of both 'shiny' and 'rmarkdown' via
 'Bootstrap' 'Sass'. Supports both 'Bootstrap' 3 and 4 as well as their
 various 'Bootswatch' themes. An interactive widget is also provided for
 previewing themes in real time.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-bslib

Bug#996955: task-desktop silently pulls in task-desktop-gnome via Recommends

[Fabian Greffrath]

Hi Holger,

thanks for your reply!

Am 21.10.2021 16:31, schrieb Holger Wansing:

Selecting "Desktop Environment", but not choose one of the displayed
possiblities (like "GNOME", "KDE" and so on) is not the way, how this
dialog was designed, I guess.


Yes, apparently. :/

I could imagine a solution, where the checkbox in the first line 
"Desktop

Environment" is not directly changeable at all, but gets automatically
checked or unchecked, if the user selects one of the desktop 
environment

options below (or does not check any of them).
Or the first line having no checkbox at all would be even better.


Yes, one of these options would clearly help improve this experience.

Thanks!

Cheers,

 - Fabian

Bug#996662: Additional information

[Yangfl]

Have no idea about apparmor, but any help is appreciated.

debian-testing  于2021年10月21日周四 下午11:22写道：
>
> Understood, but I am testing on vanilla debian installs which always includes 
> apparmor.  I haven't had this issue with any other vanilla debian packages 
> with apparmor.   A specific example is evolution email client.
>
> I am not sure if it is the way tox is reading the config or if it is specific 
> to the qtox apparmor profile.  I will have to dig further.
>
>
>
> ‐‐‐ Original Message ‐‐‐
> On Thursday, October 21, 2021 3:08 PM, Yangfl  wrote:
>
> > debian-testing debian-test...@protonmail.com 于2021年10月21日周四 下午9:48写道：
> >
> > > Yangfl: Symlink outside of home, for example, if on a symlinked network 
> > > drive or usb, etc.
> > > Directory has appropriate permissions. Seems to be apparmor (see my more 
> > > recent post), since works when apparmor is deactivate.
> > > Sent with ProtonMail Secure Email.
> >
> > Then I'd rather mark this issue as wontfix since apparmor really did
> > thr right thing to stop program from accessing files outside of /home.
>
>

Bug#969230: freecad crashes on wayland when opening FCStd files

[Tobias Frost]

Followup-For: Bug #969230
Control: reassign -1 coin3
Control: retitle -1 coin3: FreeCAD crashes because of GLX glue trying to use 
NULL display
Control: affects -1 freecad
Control: tags -1 fixed-upstream patch
Control: forwarded -1 https://github.com/coin3d/coin/pull/404

On Sat, 29 Aug 2020 18:32:02 +0100 =?utf-8?q?Pedro_=C3=82ngelo?= 
 wrote:
> Package: freecad
> Version: 0.18.4+dfsg2-5
> Severity: important
> Tags: upstream
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
> On Debian testing, under the Sway window manager (which is Wayland-based), it
> is not possible to read or write FCSstd files on Freecad. To reproduce:
> 
>  * use a wayland-based window manager
>  * open a shell and execute `QT_QPA_PLATFORM=wayland freecad`
>  * try to load an FCSstd file
> 
> this issue is known upstream:
> 
> https://forum.freecadweb.org/viewtopic.php?t=33359
> 
> the proper fix requires a patch recently merged to coin3d:
> 
> https://github.com/coin3d/coin/pull/404
> 
> I flagged this as important because it makes the package unusable on native
> Wayland setups. A workaround is to set `QT_QPA_PLATFORM=xcb` before starting
> Freecad.
> 

Lets reassign it to coin3 then. Unfortunatly the merge request has been fixed 
after
they released 4.0.0, so it is not in Debian yet, but maybe the maintainers of 
coin3d
want to cherry pick the patch at
https://patch-diff.githubusercontent.com/raw/coin3d/coin/pull/404.patch

-- 
tobi

Bug#996708: open-iscsi: unusable with default installation

[Yangfl]

Ritesh Raj Sarraf  于2021年10月21日周四 下午10:48写道：
>
> Hello,
>
> On Sun, 2021-10-17 at 23:34 +0800, Yangfl wrote:
> > Package: open-iscsi
> > Version: 2.1.4-2
> >
> > Hi,
> >
> > After installing open-iscsi without modifying any configuration,
> > iscsiadm can't do any discovery using `iscsiadm -m discovery -t
> > sendtargets -p `, which seemly caused by failure to start
> > iscsid. Some log:
> >
> >
>
> Was the daemon running at the time when you attempted the discovery  of
> the targets ?

See the status of iscsid.service is 'active (exited)', and no iscsid
is found using `ps`.

> > After stopping those services `systemctl stop iscsid.service;
> > systemctl stop iscsid.socket` and start iscsid manually, `iscsiadm -m
> > discovery` successes as expected.
> >
>
> What do you mean by 'manually' ? Invoking the iscsid binary by hand ?

Yes, `sudo iscsid`.

And I guess the issue is probably caused by missing
/usr/lib/systemd/system/iscsid.service in
https://packages.debian.org/sid/amd64/open-iscsi/filelist . After I
manually download the service file from git repo, everything goes
fine.

Bug#966141: Please retest with current version

[Neil Williams]

Version 18.9 is now only in oldstable - buster.

Stable has version 20.8 and testing/unstable have 21.4

Please can you retest with, preferably, 21.4 as the relevant code has
changed substantially compared to 18.9

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpMpmFOCg5h2.pgp
Description: OpenPGP digital signature

Bug#996964: [PATCH] cramfsswap/Makefile: add missing Makefile dependency

[Sergei Trofimovich]

Package: cramfsswap
Version: 1.4.2

Build failure noticed on NixOS when cramsfsswap
was built in parallel:

build flags: -j16 -l16 
SHELL=/nix/store/gln0pqkdxmsikdfpyv198dhl7wp34cr2-bash-5.1-p8/bin/bash
gcc -Wall -g -O-o cramfsswap cramfsswap.c -lz
strip cramfsswap
strip: 'cramfsswap': No such file

It's a race between 'cramfsswap' and 'strip' rules.
The change adds a dependency on 'cramfsswap'
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 0ceae72..2660a2c 100644
--- a/Makefile
+++ b/Makefile
@@ -6,7 +6,7 @@ debian: cramfsswap
 cramfsswap: cramfsswap.c
$(CC) -Wall -g -O $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) -o cramfsswap 
cramfsswap.c -lz
 
-strip:
+strip: cramfsswap
strip cramfsswap
 
 install: cramfsswap
-- 
2.33.0

Bug#996662: Additional information

[Yangfl]

debian-testing  于2021年10月21日周四 下午9:48写道：
>
> Yangfl: Symlink outside of home, for example, if on a symlinked network drive 
> or usb, etc.
>
> Directory has appropriate permissions.  Seems to be apparmor (see my more 
> recent post), since works when apparmor is deactivate.
>
>
> Sent with ProtonMail Secure Email.
>

Then I'd rather mark this issue as wontfix since apparmor really did
thr right thing to stop program from accessing files outside of /home.

Bug#994967: r-cran-googlesheets4_1.0.0-1_amd64.changes REJECTED

[Andreas Tille]

Hi Thorsten,

OK, I've re-uploaded to new with a hopefully proper fix.

Thanks for thorough checking

Andreas.

Am Wed, Oct 20, 2021 at 07:29:29PM +0200 schrieb Thorsten Alteholz:
> Hi Andreas,
> 
> 
> On 19.10.21 19:46, Andreas Tille wrote:
> > do you have an idea which package contains roxygen2, which is used to 
> > create googlesheets4-package.Rd?
> > The term "package" in CRAN terminology is usually what we have as a 
> > r-cran-CRANPACKAGE so this
> > is r-cran-roxygen2.
> 
> aaah, ok , I did find this.
> 
> > 
> > > Anyway, upstream has different ideas about the copyright holder in 
> > > googlesheets4-package.Rd and LICENSE.
> > > There seems to be room for improvement.
> > On what string is your statement based?  The copyright holder of the
> > automatically generated file should be the same as the source, shouldn't
> > it.
> 
> Yes, it is not the copyright of that file but its contents.
> 
>  googlesheets4-package.Rd  says: "\item RStudio [copyright holder, funder]"
>  LICENSE says:  COPYRIGHT HOLDER: Jennifer Bryan and RStudio
> 
> So I would say that Jennifer Bryan is paid by RStudio for the work on
> r-cran-googlesheets4, but RStudio is the only copyright holder.
> 
> > For the moment I've added a separate
> > 
> > Files: man/googlesheets4-package.Rd
> > 
> > paragraph even if I do not see any actual reason for it.
> 
> Neither do I, sorry.
> 
>    Thorsten
> 
> 
> ___
> R-pkg-team mailing list
> r-pkg-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/r-pkg-team

-- 
http://fam-tille.de