Bug#1033631: papi FTBFS on ppc64el with LTO enabled

[Steve Langasek]

Package: papi
Version: 7.0.0-2
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch

Dear maintainers,

In Ubuntu we have observed that papi fails to build from source on ppc64el:

[...]
cc -I../testlib -I../validation_tests -I.. -I. -g -O3 
-ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -g -Wextra  -Wall -DHAVE_ROCM_SMI -DPAPI_NUM_COMP=5 -O1  
exeinfo.c ../testlib/libtestlib.a ../libpapi.so.7.0.0.0 
-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -Wl,-z,relro -Wl,-z,now 
-Wl,--enable-new-dtags-o exeinfo
/usr/bin/ld: /tmp/ccNFJgHF.ltrans0.ltrans.o:(.rodata+0x10): undefined reference 
to `f08_callback_'
/usr/bin/ld: BFD (GNU Binutils for Ubuntu) 2.40 assertion fail 
../../bfd/elf64-ppc.c:17380
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:151: sde_test_f08] Error 1
[...]

This error only happens when LTO is enabled.  It is likely a bug in the LTO
toolchain implementation, but to work around the build failure, I have
uploaded the attached patch to Ubuntu which disables LTO on ppc64el.

This patch should presently be a safe no-op in Debian, since Debian does not
enable LTO by default.  But as there are discussions to enable it by default
in the future, I am forwarding this patch to you in case it proves useful.

Thanks for considering,
-- 
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 papi-7.0.0/debian/rules papi-7.0.0/debian/rules
--- papi-7.0.0/debian/rules 2022-11-29 05:40:48.0 -0800
+++ papi-7.0.0/debian/rules 2023-03-28 21:18:17.0 -0700
@@ -8,9 +8,14 @@
 # see FEATURE AREAS in dpkg-buildflags(1)
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
+include /usr/share/dpkg/architecture.mk
+
+ifeq ($(DEB_HOST_ARCH),ppc64el)
+DEB_BUILD_MAINT_OPTIONS += optimize=-lto
+endif
+
 DPKG_EXPORT_BUILDFLAGS  = yes
 include /usr/share/dpkg/buildflags.mk
-include /usr/share/dpkg/architecture.mk
 
 # Upstream does not use CPPFLAGS
 CFLAGS += $(CPPFLAGS)

Bug#1033630: debian-installer: should fstab swap entries use "sw" as option?

[David]

On Wed, 29 Mar 2023 at 02:49, Christoph Anton Mitterer
 wrote:
> On Wed, 2023-03-29 at 02:25 +, David wrote:

> > My thought process is as follows:
> > Field 4 is for mount options. This is just the same as providing
> > options to the 'mount' command issued at the command line.
> > And it is ok to use the 'mount' command without options.
>
> Well that's clear and it probably just works like that in the end.
>
> But still, if the manpage is considered the "formal specification" of
> the fstab format, than 4th field seems to be needed.
> That even says: "contains at least the type of mount (ro or rw)", which
> would be fulfilled by default (as that implies rw).
>
> That's what I've meant by strictly speaking before... parsers of fstab
> could in principle rely on that.

I think the formal specification of the fstab format would be
'man 3 getfsent' because that is the canonical method to
parse /etc/fstab.

I agree that reading the manpage like a lawyer probably
isn't helpful.

Perhaps 'sw' in field 4 became obsolete. What does it achieve?

It does seem redundant to have to specify both 'swap' and 'sw'
for every swap partition. And if we have to specify 'sw' in field 4,
how is it an "option"?

Perhaps it is a historic artifact that does nothing. Perhaps it
predates 'swap' being recognised in field 3, and then documentation
of 'sw' wasn't removed when 'swap' was introduced.
I don't know the history.

If codesearch doesn't show anything using FSTAB_SW then
perhaps it just does not matter.

Anyway, just to be clear, I'm not the person advocating change here.

I am simply sharing the fact that I have configured swap in /etc/fstab
with blank field 4,5 and 6, as I showed previously, for as long as I can
remember, without experiencing any problem. And I have explained
my reasoning about that, when requested.

I hope that helps :)

Bug#1033170: libitext-rups-java: Does not work at all

[tony mancill]

On Tue, Mar 28, 2023 at 12:05:26PM +0200, Emmanuel Bourg wrote:
> Le 2023-03-28 05:28, tony mancill a écrit :
> 
> > The upload is ready.  Any concerns?
> > 
> > $ reverse-depends libitext-rups-java
> > No reverse dependencies found
> > 
> > $ reverse-depends -b libitext-rups-java
> > No reverse dependencies found
> 
> +1 for removing libitext-rups-java, and maybe libitext-rtf-java too.

Thank you for responding.  Removing libitext-rtf-java is a good idea.
I opted to keep the debdiff minimal for this upload in deference to the
Release Team, but could be convinced otherwise if anyone feels strongly
about it.


signature.asc
Description: PGP signature

Bug#1033626: sbuild: Dependencies should not be required outside the chroot (--no-clean should be the default)

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Dima Kogan (2023-03-29 03:33:46)
> The feature I'm asking for is that on a brand-new Debian install I think I
> should be able to
> 
>   1. apt install sbuild
> 
>   2. create schroot for sbuild in whatever way
> 
>   3. apt source package
> 
>   4. cd package
> 
>   5. sbuild
> 
> Today this doesn't always work, because sbuild wants to "dh clean" outside
> the chroot.

that is correct. But it could be said that this is still not a bug because you
are using sbuild wrong. ;)

> Omitting the "dh clean" (by relying on dpkg complaining) would be one way to
> get this working.

Yes. The downside would be, that this would mean you've this check that figures
out whether you made any changes every time you run it. I'd argue that the most
common way to run sbuild is *after* you've made some changes and not on a
source package without modifications. If you want to build a source package
without having modified it, then your above list of steps are wasting CPU
cycles. Instead of unpacking the source package and then repacking it again,
you could just:

apt-get source --download-only package
sbuild -d unstable package_*.dsc

Or could could leave even the downloading of the .dsc to sbuild:

sbuild -d unstable package

Or instead of using apt to download and unpack, you could get the source
package with debcheckout and build with gbp buildpackage and then use the
--git-cleaner option to run something like "git clean -fdx && git reset --hard"
before running sbuild. Cleaning like that also doesn't require any additional
dependencies on the outside being installed.

Would either of this solve your use-case?

> Doing the "dh clean" inside the chroot after the Build-Depends have been
> installed is another.

No. Doing the dh clean on the inside does not solve your problem because before
anything can be run inside the chroot, a .dsc has to be made availabe on the
outside so that something can be copied into the chroot. To make the .dsc
available on an unpackaged source package, sbuild runs the clean target first.
I've explained this already in past mails. The input to sbuild is the .dsc. If
you want to put anything in, it has to be made a .dsc first. If your input is
an unpacked directory, it has to be made into a .dsc first. In that case, your
directory needs to be cleaned before a .dsc can be made.

> Maybe the above sequence shouldn't be expected to work, but that makes sbuild
> less useful in my view.

I'm still trying to figure out what you are trying to do. If you want to build
a source package without modifications, don't unpack it but feed sbuild the
.dsc directly. If you want to make changes to it, unpack it. But then, after
you've made changes, the directory needs to be clean before it can be made into
a .dsc again.

> I can make --no-clean the default in my config, I suppose.

Beware that this will lead to broken packages if you did make the wrong
changes. That's why it's not the default.

> Probably others use sbuild in this way too? I guess I have no way of knowing.

Me neither. I can find two other mails from people who didn't know that the
input to sbuild is a .dsc (and thus the clean target needs to be run if you
start from an unpacked source directory) in my inbox from the past eight years
i've maintained sbuild.

At this point I don't know anything that can be done from the sbuild side to
act on this bug (hence the "wontfix" tag):

 - cleaning on the inside is pointless because it would not avoid having to
   clean on the outside
 - detecting changes would be pointless in most cases and a waste of CPU cycles
   because most people run sbuild *after* having made changes. If you don't
   want to change anything, then don't run from an unpacked source directory.
   Is there any reason to unpack a .dsc other than to make changes to it?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1033630: debian-installer: should fstab swap entries use "sw" as option?

[Christoph Anton Mitterer]

On Wed, 2023-03-29 at 02:25 +, David wrote:
> My thought process is as follows:
> Field 4 is for mount options. This is just the same as providing
> options to the 'mount' command issued at the command line.
> And it is ok to use the 'mount' command without options.

Well that's clear and it probably just works like that in the end.

But still, if the manpage is considered the "formal specification" of
the fstab format, than 4th field seems to be needed.
That even says: "contains at least the type of mount (ro or rw)", which
would be fulfilled by default (as that implies rw).

That's what I've meant by strictly speaking before... parsers of fstab
could in principle rely on that.


I guess a simpler way might be to use:
… rw,auto,nouser 0 0

cause that what it effectively seems to be.


Or... improve the fstab manpage... because it doesn't make sense IMO to
say that it "contains at least the type of mount (ro or rw)" while
leaving auto/noauto optional (with a default).



Cheers,
Chris.

Bug#1019732: apt-listbugs: undefined method `default' for " # returns password\n":String

[Vincent Lefevre]

On 2023-03-29 03:59:24 +0200, Vincent Lefevre wrote:
> BTW, I also note in the second failure
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019732#34
> 
> that one has the following in the output:
> 
> $stdout.print " " * Unicode.width(@old)
>^^

More precisely, one has

Performing actions...
E: undefined method `default' for "if /proxy_detect='(.*)'/ =~ `apt-config 
\#{@apt_conf} shell proxy_detect acquire::http::proxy-auto-detect`\n":String

$stdout.print " " * Unicode.width(@old)
   ^^
E: Unterprozess /usr/bin/apt-listbugs apt hat Fehlercode zurückgegeben (1)
E: Failure running script /usr/bin/apt-listbugs apt

The "Performing actions..." line and the last two "E:" lines come from
aptitude. What is between comes from the program run by aptitude, i.e.
"/usr/bin/apt-listbugs apt":

E: undefined method `default' for "if /proxy_detect='(.*)'/ =~ `apt-config 
\#{@apt_conf} shell proxy_detect acquire::http::proxy-auto-detect`\n":String

$stdout.print " " * Unicode.width(@old)
   ^^

On my machine, I get the following:

zira:~> grep -r '\ BigDecimal
/usr/lib/ruby/gems/3.1.0/gems/rbs-2.1.0/core/math.rbs:Math::E: Float
/usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb:  $stderr.puts _("E: ") + 
_("You need to specify a command.")
/usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb:  $stderr.puts _("E: ") + 
_("Unknown command ") +  "'#{command}'."
/usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb:$stderr.puts _("E: ") + 
_("HTTP GET failed")
/usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb:$stderr.puts _("E: ") + 
_("Empty stream from SOAP")
/usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb:$stderr.puts _("E: ") + 
"#{$!}"
/usr/lib/ruby/vendor_ruby/debian.rb:  "E: invalid format #{line} in 
#{line}"
/usr/lib/ruby/vendor_ruby/debian.rb:"E: duplicate control info 
#{field} in #{line}"
/usr/lib/ruby/vendor_ruby/debian.rb:"E: required field #{f} not found 
in #{c}"
/usr/lib/ruby/vendor_ruby/debian.rb:  raise DepError, "E: trying package 
override"
/usr/lib/ruby/vendor_ruby/debian.rb:  raise DepError, "E: trying relation 
override"
/usr/lib/ruby/vendor_ruby/debian.rb:  raise Debian::DepError, "E: unknown 
operation #{@op}"
/usr/lib/ruby/vendor_ruby/debian.rb:  "E: `+' type mismatch #{self.class} 
!= #{da.class}"
/usr/lib/ruby/vendor_ruby/debian.rb:  "E: `-' type mismatch 
#{self.class} != #{da.class}"
/usr/lib/ruby/vendor_ruby/debian.rb:  "E: `-' type mismatch #{self.class} 
!= #{da.class}"

The almost-only possibility would be:

  $stderr.puts _("E: ") + "#{$!}"

The code in /usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb is:

[...]
  rescue Exception => exception
config.frontend.puts _(" Fail")
$stderr.puts " Exception: " + exception.class.to_s if $DEBUG
config.frontend.puts _("Error retrieving bug reports from the server 
with the following error message:")
$stderr.puts _("E: ") + "#{$!}"
if exception.kind_of? SocketError
  config.frontend.puts _("It appears that your network connection is 
down. Check network configuration and try again")
else
  config.frontend.puts _("It could be because your network is down, or 
because of broken proxy servers, or the BTS server itself is down. Check 
network configuration and try again")
end
retrycount -= 1
if config.frontend.yes_or_no?(_("Retry downloading bug information?")) 
&& retrycount > 0
  config.querystep = 1 if config.querystep != 1 && 
config.frontend.yes_or_no?(_("One package at a time?"))
  config.parsestep = 1 if config.parsestep != 1 && 
config.frontend.yes_or_no?(_("One bug report at a time?"))
  retry
end
raise _("Exiting with error") if ! 
config.frontend.yes_or_no?(_("Continue the installation anyway?"), false)
bugs = []

But in such a case, wouldn't one have other messages, corresponding
to config.frontend.puts?

The other possibility is some other error, say

  $stderr.puts _("E: ") + _("Empty stream from SOAP")

Note that the error message does not correspond at all. However,
the exact error message is obtained via gettext, and this is where
something ugly could potentially occur. This might explain that
the error message contains text from the .rb source (which is
something that is not available normally).

> The "$stdout.print..." line comes from
> /usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb but what could yield
> this output with carets?

Any explanation for this one? FYI, the context in logic.rb:

[...]
  def progress(msg, val)
$stdout.print "\r"
$stdout.print " " * Unicode.width(@old)
$stdout.print "\r"
@old = "#{msg} #{val}"
$stdout.print @old
$stdout.flush
$stdout.puts "" if Factory.done?(val)
  end
[...]

-- 
Vincent Lefèvre  - Web: 
100% accessible 

Bug#1033630: debian-installer: should fstab swap entries use "sw" as option?

[David]

On Wed, 29 Mar 2023 at 01:56, Christoph Anton Mitterer
 wrote:
> On Wed, 2023-03-29 at 01:41 +, David wrote:

> > Yes, for many years using Debian stable, my swap lines in
> > /etc/fstab look like this:
> >   none  swap
>
> Hmm, I'm not sure whether strictly speaking it's allowed to skip the
> 4th field.
> The manpage explicitly documents so for the 5th and the 6th, but not
> for the 4th.
>
> So it's questionable if all possible tools which may parse fstab really
> deal with that gracefully.
> Plus users might be confused and expect 6 fields.

My thought process is as follows:
Field 4 is for mount options. This is just the same as providing
options to the 'mount' command issued at the command line.
And it is ok to use the 'mount' command without options.

Regarding omitting 'sw', I'm not seeing any problem.
This might be a good starting point to investigate whether
anything uses it:
  https://codesearch.debian.net/search?q=FSTAB_SW=1

Bug#973414: rustc: produces non-baseline opcodes for compiler_builtins::int::udiv::__udivmoddi4 on i386

[James Addison]

Package: rustc
Followup-For: Bug #973414
X-Debbugs-Cc: fierel...@gmail.com

After a few false starts, I've built libstd-rust-dev:i386 targeting i686 in the
way I'd expected (and to clarify: the interpretation I'm using is to match
Debian's baseline and a strict-ish reading of what P6 / i686 was when
originally specified).

Editing the 'd-rustc-i686-baseline.patch'[1] to specify "i686" instead of the
current "pentiumpro" achieved the result I was looking for: absence of NOPL in
the libstd libraries included when users compile statically-linked Rust code.

I'll double-check the results soon, and go back to see how that result affects
the original bugreport here.  My hope is that it helps to verify that the
rustc target spec is where we should be looking, but further work may be
required.

Caveats / todo items:

  * Check that "i686" is a valid CPU (not architecture) target

  * Ideally, test this on relevant hardware (non-NOPL, non-SSE2?)


Apologies, Fierelier - I didn't see your update until after these results
arrived.  Your links look relevant though, yep.  I _think_ Debian has patched
both those locations; I'll check in detail within the next day or two.

[1] - 
https://sources.debian.org/src/rustc/1.63.0%2Bdfsg1-2/debian/patches/d-rustc-i686-baseline.patch/

Bug#1019732: apt-listbugs: undefined method `default' for " # returns password\n":String

[Vincent Lefevre]

BTW, I also note in the second failure

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019732#34

that one has the following in the output:

$stdout.print " " * Unicode.width(@old)
   ^^

The "$stdout.print..." line comes from
/usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb but what could yield
this output with carets?

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

Bug#1033630: debian-installer: should fstab swap entries use "sw" as option?

[Christoph Anton Mitterer]

On Wed, 2023-03-29 at 01:41 +, David wrote:
> Yes, for many years using Debian stable, my swap lines in
> /etc/fstab look like this:
>   none  swap

Hmm, I'm not sure whether strictly speaking it's allowed to skip the
4th field.
The manpage explicitly documents so for the 5th and the 6th, but not
for the 4th.

So it's questionable if all possible tools which may parse fstab really
deal with that gracefully.
Plus users might be confused and expect 6 fields.


Cheers,
Chris.

Bug#1033626: sbuild: Dependencies should not be required outside the chroot (--no-clean should be the default)

[Dima Kogan]

Johannes Schauer Marin Rodrigues  writes:

> I fear I do not quite understand what kind of feature you are asking for. Do
> you really think it would be a good idea if sbuild, every time you run it,
> first locates a .dsc, unpacks the .dsc, compares the unpacked .dsc to your
> current directory and only invokes the clean target if it finds differences?
> Would there not almost always be differences because you only invoke sbuild
> *after* you've made some changes to the unpacked source directory? And what
> should sbuild do if it has detected changes? It would still need to run the
> clean target before it can create the new source package.
>
>> Other than that, can we run "dh clean" inside the chroot?
>
> What would that accomplish? At the point where the .dsc is unpacked
> inside the chroot, it already is clean. You need a clean unpacked
> source directory, so that you can build a .dsc so that it can be
> copied into the chroot. So this cleaning has to happen on the outside.

Those questions are all valid, of course, if you think of the .dsc as
the input to sbuild. Up until today I was not even aware that this is
how it works.

The feature I'm asking for is that on a brand-new Debian install I
think I should be able to

  1. apt install sbuild

  2. create schroot for sbuild in whatever way

  3. apt source package

  4. cd package

  5. sbuild

Today this doesn't always work, because sbuild wants to "dh clean"
outside the chroot. Omitting the "dh clean" (by relying on dpkg
complaining) would be one way to get this working. Doing the "dh clean"
inside the chroot after the Build-Depends have been installed is
another.

Maybe the above sequence shouldn't be expected to work, but that makes
sbuild less useful in my view. I can make --no-clean the default in my
config, I suppose. Probably others use sbuild in this way too? I guess I
have no way of knowing.

Bug#1033630: debian-installer: should fstab swap entries use "sw" as option?

[David]

On Wed, 29 Mar 2023 at 00:54, Christoph Anton Mitterer
 wrote:
> On Wed, 2023-03-29 at 00:49 +, David wrote:

> > In that situation, field 4 has to be non-blank, which is when setting
> > it to "defaults" becomes useful.
> >
> > Otherwise, putting "defaults" in field 4 achieves nothing, because
> > defaults are defaults so there is no reason to specify them.
>
> Does that imply you'd simply skip fields 4 to 6 for swap entries?

Yes, for many years using Debian stable, my swap lines in
/etc/fstab look like this:
  none  swap

Bug#1019732: apt-listbugs: undefined method `default' for " # returns password\n":String

[Vincent Lefevre]

On 2023-03-28 20:37:56 -0300, Antonio Terceiro wrote:
> Still, I see no evidence that this is caused by the Ruby interpreter.
> For example apt-listbugs uses a SOAP library that is severely
> unmaintained upstream and has been on life support for some time now. It
> could be that library that is doing crazy things when the server does
> not reply in exactly the way it expects.

Note that in both failures, a line of the source, e.g.

  /usr/lib/ruby/3.0.0/uri/generic.rb

or

  /usr/lib/ruby/3.0.0/bundler/vendor/uri/lib/uri/generic.rb

for "  # returns password\n" in my case in 2022, and

  /usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb

for "if /proxy_detect='(.*)'/ =~ `apt-config \#{@apt_conf} shell 
proxy_detect acquire::http::proxy-auto-detect`\n"
in the other case a few days ago, is regarded by the Ruby interpreter
as a String. Has any .rb library, even if severely buggy, the power
to do that?

Otherwise, could it be that apt-listbugs invokes the `default' method
of some object obtained by SOAP, but this would mean that the server
sends some part of .rb code as a String object in some cases? (This
seems rather unlikely, and that could imply a security issue on the
client side, if the client doesn't check what it receives.)

IMHO, this looks like some kind of pointer corruption.

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

Bug#1033630: debian-installer: should fstab swap entries use "sw" as option?

[Christoph Anton Mitterer]

On Wed, 2023-03-29 at 00:49 +, David wrote:
> In that situation, field 4 has to be non-blank, which is when setting
> it
> to "defaults" becomes useful.
> 
> Otherwise, putting "defaults" in field 4 achieves nothing, because
> defaults
> are defaults so there is no reason to specify them.

Does that imply you'd simply skip fields 4 to 6 for swap entries?

Bug#1033630: debian-installer: should fstab swap entries use "sw" as option?

[David]

On Wed, 29 Mar 2023 at 00:33, Christoph Anton Mitterer
 wrote:

> Anyway... maybe it makes sense to use some other value, most likely
> "defaults" then...

Hi, the only time that "defaults" should be used in field 4 of /etc/fstab is
when a value to the right of it (field 5 or 6) are required to be non-empty
AND no non-default options are required.

In that situation, field 4 has to be non-blank, which is when setting it
to "defaults" becomes useful.

Otherwise, putting "defaults" in field 4 achieves nothing, because defaults
are defaults so there is no reason to specify them.

Bug#1033624: obs-studio: Pipewire capture source not listed

[Kevin Otte]

I have xdg-desktop-portal-{wlr,gtk} installed, which is appropriate for 
a wlroots compositor.


On 3/28/23 19:32, Richard B. Kreckel wrote:

On 3/28/23 22:12, Kevin Otte wrote:
When I attempt to add a source to the current scene, I do not see the 
"Screen Capture (Pipewire)" option listed as demonstrated in the 
screenshot at 
https://www.linuxuprising.com/2021/06/obs-studio-27-released-with-wayland-and.html


As such, I am unable to capture the screen under Wayland 
(specifically, sway).


Do you have xdg-desktop-portal-gnome installed? (See bug #1031645.)

   -richy.

Bug#1033630: debian-installer: should fstab swap entries use "sw" as option?

[Christoph Anton Mitterer]

Source: debian-installer
Version: 20230217
Severity: minor


Hey.

In the end this is probably anyway completely ignored, so consider this
just a cosmetic issue:


AFAICS, the installer cretes swap entries in fstab as:
 none swap sw 0 0

https://salsa.debian.org/installer-team/partman-basicfilesystems/-/blob/master/fstab.d/basic#L32
and also at least there:
https://salsa.debian.org/installer-team/partman-swapfile/-/blob/master/finish.d/fstab_swapfile#L10

I wondered whether "sw" is still the "canonical" value for the 4th field.

fstab(5) describes the appropriate values for swap for fields 1 to 3
(inclusive).
But it gives nothing about the 4th.
Neither do e.g. the manpages mount(8) or swapon(8).

I briefly tried to track down where the "sw" actually came from, seems
it might be from BDS times?


Anyway... maybe it makes sense to use some other value, most likely
"defaults" then... or perhaps "auto,nouser"?
"defaults" would be a bit misleading as its documented to be:
   defaults
   use default options: rw, suid, dev, exec, auto, nouser, and async.
which most make no sense for swap.
So perhaps "auto,nouser" would be the most reasonable ones?


Alternatively, this should perhaps be reassigned to mount, with the request
that "sw" is documented somehow, and if it's just that it's ignored for
entries of type swap.
Sidenote: It doesn't seem as if the 4th field would be generally ignored
for swap, e.g. nofail, noauto are considered.


Cheers,
Chris.

Bug#1031771: linphone-desktop: Update check recommends AppImage

[Daniel Kahn Gillmor]

Hi Dennis--

On Wed 2023-02-22 21:44:20 +0100, Dennis Filder wrote:
> Control: reassign -1 linphone 5.1.65-3
> X-Debbugs-CC: Bastian Germann 
>
> On Wed, Feb 22, 2023 at 02:15:09PM +0100, Bastian Germann wrote:
>> The update check in the "burger menu" should be disabled because it
>> downloads the AppImage version of linphone-desktop.
>
> Patching an envvar-overridable early return and warning message into
> linphone/coreapi/update_check.c:linphone_core_check_for_update() seems
> to me like the easiest way to address this.  It would also function as
> a stop-gap for any new mechanisms that try to trigger an update check.

Thanks for this fix!  I notice that the text says:

>>> To enable it restart the program with the variable
>>> LINPHONE_DO_APPIMAGE_DOWNLOAD set to "y" in the environment.

but the actual check is just whether the variable is set, not whether it
is set to "y".

This means that:

LINPHONE_DO_APPIMAGE_DOWNLOAD=n linphone

will actually enable the check.  Maybe make sure it checks for "y" as
well?

I've offered
https://salsa.debian.org/pkg-voip-team/linphone-stack/linphone/-/merge_requests/3
that tries to do that (but haven't really tested it, sorry!)

--dkg

Bug#1033624: obs-studio: Pipewire capture source not listed

[Richard B. Kreckel]

On 3/28/23 22:12, Kevin Otte wrote:

When I attempt to add a source to the current scene, I do not see the "Screen 
Capture (Pipewire)" option listed as demonstrated in the screenshot at 
https://www.linuxuprising.com/2021/06/obs-studio-27-released-with-wayland-and.html

As such, I am unable to capture the screen under Wayland (specifically, sway).


Do you have xdg-desktop-portal-gnome installed? (See bug #1031645.)

  -richy.
--
Richard B. Kreckel




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019732: apt-listbugs: undefined method `default' for " # returns password\n":String

[Antonio Terceiro]

On Tue, Mar 28, 2023 at 09:26:29PM +0200, Vincent Lefevre wrote:
> On 2023-03-28 15:20:17 -0300, Antonio Terceiro wrote:
> > I'm sorry but this bug report assumes an unsupported configuration:
> > 
> > >  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
> > > 'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), 
> > > (1, 'experimental')
> > 
> > This is not supportable at all.
> 
> Why not? Anyway, I doubt that this is related to the issue: packages
> appear in unstable first, so that "testing" and "stable" should have
> no effect in normal time.
> 
> > Plus:
> > 
> > > Versions of packages apt-listbugs depends on:
> > [...]
> > > ii  ruby1:3.0+1
> > 
> > Ruby 3.0, which is explicitly mentioned in the bug report as being used,
> > was just temporarily in bookworm as an intermediate step between 2.7
> > (bullseye) and 3.1 which is the version that is actually to be released
> > with bookworm.
> 
> But at some point (when I reported the bug), it was in unstable.
> See https://tracker.debian.org/pkg/ruby-defaults
> 
> [2022-09-20] Accepted ruby-defaults 1:3.0+3.1 (source) into unstable (Antonio 
> Terceiro)
> [2022-05-01] Accepted ruby-defaults 1:3.0+2 (source) into experimental 
> (Antonio Terceiro)
> [2022-03-10] ruby-defaults 1:3.0+1 MIGRATED to testing (Debian testing watch)
> [2022-03-07] Accepted ruby-defaults 1:3.0+1 (source) into unstable (Lucas 
> Kanashiro)
> 
> I had ruby 1:3.0+1 because it got into unstable on 2022-03-07.

Fair enough. I missed the date of the original bug report, I'm sorry
about that.

Still, I see no evidence that this is caused by the Ruby interpreter.
For example apt-listbugs uses a SOAP library that is severely
unmaintained upstream and has been on life support for some time now. It
could be that library that is doing crazy things when the server does
not reply in exactly the way it expects.


signature.asc
Description: PGP signature

Bug#1026118: thunderbird: please add support for riscv64

[Bo YU]

Source: thunderbird
Version: 1:110.0~b4-1
Followup-For: Bug #1026118

FYI, I just can build the thunderbird package on qemu-user with the
patch. Once it can be built on Unmatched, I will update it here.

The riscv64 binary packages here:
https://drive.google.com/drive/folders/1klWvrjq-geMFAWIXTas6lPz8e8_7Eavo


-- 
Regards,
--
  Bo YU

From f042ccc6f2bda11cc7fad587dc075734766f04f3 Mon Sep 17 00:00:00 2001
From: Bo YU 
Date: Thu, 23 Mar 2023 06:48:11 +0800
Subject: [PATCH] support riscv64

Signed-off-by: Bo YU 
---
 debian/changelog | 7 +++
 debian/control   | 2 +-
 debian/mozconfig.default | 5 +
 debian/rules | 2 ++
 4 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 988bedc1c1d..6699d54b4a3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+thunderbird (1:110.0~b4-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Support riscv64
+
+ -- Bo YU   Thu, 23 Mar 2023 06:47:28 +0800
+
 thunderbird (1:110.0~b4-1) experimental; urgency=medium
 
 
diff --git a/debian/control b/debian/control
index 232a43e6578..bd0ba9e936e 100644
--- a/debian/control
+++ b/debian/control
@@ -62,7 +62,7 @@ X-Debian-Homepage: http://wiki.debian.org/Thunderbird
 Standards-Version: 4.6.1
 
 Package: thunderbird
-Architecture: amd64 arm64 i386 mips64el ppc64el s390x ppc64
+Architecture: amd64 arm64 i386 mips64el ppc64el s390x ppc64 riscv64
 Depends:
  debianutils (>= 1.16),
  fontconfig,
diff --git a/debian/mozconfig.default b/debian/mozconfig.default
index aff9e4a8bca..551798e9271 100644
--- a/debian/mozconfig.default
+++ b/debian/mozconfig.default
@@ -117,6 +117,11 @@ case `dpkg --print-architecture` in
   ppc64el)
 ac_add_options --with-intl-api
 ;;
+  riscv64)
+ac_add_options --disable-jit
+ac_add_options --disable-debug
+ac_add_options --disable-debug-symbols
+;;
   sh4)
 ac_add_options --disable-pie
 ;;
diff --git a/debian/rules b/debian/rules
index 14290f73661..8b0acfee0a3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -67,7 +67,9 @@ LDFLAGS += -Wl,--stats
 # are performing a dist-upgrade to a new release.
 export MOZ_BUILD_DATE := ${shell head -n1 $(CURDIR)/sourcestamp.txt}
 export MOZCONFIG=$(shell pwd)/mozconfig.thunderbird
+ifneq ($(DEB_BUILD_ARCH),riscv64)
 export MOZILLA_OFFICIAL=1
+endif
 export DEB_BUILD_GNU_TYPE
 export DEB_HOST_GNU_TYPE
 export DEB_BUILD_OPTIONS
-- 
2.39.2



signature.asc
Description: PGP signature

Bug#1033629: ruby-devise: workaround to pass riscv64 autopkgtest

[Bo YU]

Source: ruby-devise
Version: 4.8.1-1
Severity: wishlist
Tags: patch
X-Debbugs-Cc: debian...@lists.debian.org

Dear Maintainer,

The ruby-devise has a tmpfail issue when it rm of autopkgtest tested
after finishing debci test on riscv64:

```
autopkgtest [18:09:56]: test smoke-test: ---]
smoke-test   PASS
autopkgtest [18:09:57]: test smoke-test:  - - - - - - - - - - results
- - - - - - - - - -
autopkgtest [18:10:15]: ERROR: "rm -rf
/tmp/autopkgtest-lxc.g1pgc3ei/downtmp/smoke-test-artifacts
/tmp/autopkgtest-lxc.g1pgc3ei/downtmp/autopkgtest_tmp" failed with
stderr "rm: cannot remove
'/tmp/autopkgtest-lxc.g1pgc3ei/downtmp/autopkgtest_tmp/myapp/tmp/cache/bootsnap/compile-cache-iseq':
Directory not empty
```

With help of Paul, the workaround is to postpone the deletion of testbed
on riscv64[0].

I have tested it on real riscv64 machine and amd64.

Please let me know if there is any issues.

[0]: https://lists.debian.org/debian-ci/2023/03/msg4.html



-- 
Regards,
--
  Bo YU

diff -Nru ruby-devise-4.8.1/debian/changelog ruby-devise-4.8.1/debian/changelog
--- ruby-devise-4.8.1/debian/changelog  2022-10-09 00:21:10.0 +0800
+++ ruby-devise-4.8.1/debian/changelog  2023-03-28 21:25:14.0 +0800
@@ -1,3 +1,10 @@
+ruby-devise (4.8.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Workaround to pass autopkgtest on riscv64 debci
+
+ -- Bo YU   Tue, 28 Mar 2023 21:25:14 +0800
+
 ruby-devise (4.8.1-1) unstable; urgency=medium
 
   [ Debian Janitor ]
diff -Nru ruby-devise-4.8.1/debian/tests/smoke-test 
ruby-devise-4.8.1/debian/tests/smoke-test
--- ruby-devise-4.8.1/debian/tests/smoke-test   2022-10-09 00:13:10.0 
+0800
+++ ruby-devise-4.8.1/debian/tests/smoke-test   2023-03-28 21:25:14.0 
+0800
@@ -32,3 +32,9 @@
 
 test -f config/initializers/devise.rb
 test -f config/locales/devise.en.yml
+
+ARCH=$(dpkg --print-architecture)
+if test "$ARCH" = "riscv64" 
+then
+   sleep 5
+fi


signature.asc
Description: PGP signature

Bug#705244: gajim hanged and threw some exception

[Martin]

Control: close -1 1.0.0-1

Please reopen, if this issue persists.
So far, it is not reproducible.
With 1.0.0 the code has been rewritten, and many old bugs are gone.

Bug#625265: gajim: all in one display-mode not maximisable

[Martin]

Control: close -1 1.4.0-1

I'm not sure, when this has been fixed, but at least since 1.4.0, when
the Gajim moved to single window layout.

Bug#911368: In a chatroom, people with emojis in their nick disappear

[Martin]

Control: close -1 1.1.0-1

Fixed long time ago...

Bug#1033625: cups constantly without timeout connects to network printer, does not print

[Brian Potkin]

On Tue 28 Mar 2023 at 23:01:47 +0200, Johan Kröckel wrote:

> Package: cups
> Version: 2.4.2-2
> Severity: important
> X-Debbugs-Cc: johan.kroec...@gmail.com
> 
> I am using a Kyocera Ecosys m5526cdw over the network. Printing
> stopped working (worked with this version before).
> 
> Now when I try to start a print job cups ends with a message "Der
> Druckauftrag wurde nicht angenommen.". BUT:
> 
> Now cups connects to the printer (LED on printer lights up as long as
> the pc is on) but nothing is printed. When I reboot, the LED stops to
> blink as long as the system is not completely booted, then the
> connection starts again.
> 
> After running cupsctl --debug-logging, error_log grows by around 30
> megabytes per hour.

Thank you for your report, Johan.

Please provude outputs for

  lpstat -l -e
  lpstat -t
  avahi-browse -rt _ipp._tcp
  avahi-browse -rt _uscan._tcp
  driverless
  lpoptions -p PRINTER_NAME

avahi-browse is in the avahi-utils package.

Regards,

Brian.

Bug#1033626: sbuild: Dependencies should not be required outside the chroot (--no-clean should be the default)

[Johannes Schauer Marin Rodrigues]

Quoting Dima Kogan (2023-03-28 23:27:55)
> I have never once in my life ran sbuild from a .dsc file. In fact I don't
> think I've ever done anything with .dsc files directly. I'm always sitting on
> the sources, with a ../whatever.orig.tar.gz on disk.

Yes, since most people want to use it like that, the convenience wrapper was
added. That way, you do not have to manually build the .dsc before calling
sbuild. But building the .dsc is mandatory one way or another because that's
the input for sbuild. It's how the source package is transferred into the
chroot.

> If I've been using it wrong this whole time, I guess that's on me. But
> starting from sources feels like the natural flow to me, so can we make this
> work a bit better?

You have not been using it wrongly. And you are not clear in your terminology.
The source is the .dsc. You could also call the unpacked .dsc source but the
disadvantage of that kind of source is, that in contrast to the .dsc, the
unpacked source can be tainted and thus has to be cleaned first.

I don't think you've been doing anything wrong. You've just taken advantage of
a convenience feature sbuild offers to be able to run from within an unpacked
source package.

> If we wanted to make the clean step optional, sbuild can check for source
> differences, and barf if any are detected. It mostly does that already.

No it does not. Maybe what you observed is, that dpkg dies if it finds
unexpected changes but sbuild does no such checks.

> I believe it doesn't complain if there are extra files on disk, but we could
> make it do that too.

That's dpkg complaining, not sbuild.

I fear I do not quite understand what kind of feature you are asking for. Do
you really think it would be a good idea if sbuild, every time you run it,
first locates a .dsc, unpacks the .dsc, compares the unpacked .dsc to your
current directory and only invokes the clean target if it finds differences?
Would there not almost always be differences because you only invoke sbuild
*after* you've made some changes to the unpacked source directory? And what
should sbuild do if it has detected changes? It would still need to run the
clean target before it can create the new source package.

> Other than that, can we run "dh clean" inside the chroot?

What would that accomplish? At the point where the .dsc is unpacked inside the
chroot, it already is clean. You need a clean unpacked source directory, so
that you can build a .dsc so that it can be copied into the chroot. So this
cleaning has to happen on the outside.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#973414: rustc: produces non-baseline opcodes for compiler_builtins::int::udiv::__udivmoddi4 on i386

[Fierelier OwO]

@jay - I hope this helps you:
- issue 1: i386, i486, i586, i686 are considered as Pentium 4 in LLVM,
which might be relevant if Rust is compiled with it:
https://github.com/llvm/llvm-project/issues/61347
- issue 2: Rust considers i686 as Pentium 4, and i586 as Pentium:
https://github.com/rust-lang/rust/issues/82435

So, what I'm thinking is:
- When building the Rust toolchain itself, if Debian uses LLVM for it,
it might be a good idea to set the CPU target explicitly to pentiumpro
in LLVM's flags (fix issue 1) (It could also be a good idea to set
this for LLVM in general if possible, if not already done so). -- Also
compile the i586 Rust toolchain, not the i686 one (fix issue 2).
- For Rust programs, I'd probably recommend setting the target for all
(?) of them to i586 (fix issue 2). One can also try to add "-C
target-cpu=pentiumpro -C target-feature=-mmx -C target-feature=-sse -C
target-feature=-sse2" to RUSTFLAGS, if the above doesn't work.

Most of this is assumptions, but I hope it brings some progress.

Best of luck and thank you.

Bug#1033626: sbuild: Dependencies should not be required outside the chroot (--no-clean should be the default)

[Dima Kogan]

Hi. Thanks for the explanation.

I have never once in my life ran sbuild from a .dsc file. In fact I
don't think I've ever done anything with .dsc files directly. I'm always
sitting on the sources, with a ../whatever.orig.tar.gz on disk.

If I've been using it wrong this whole time, I guess that's on me. But
starting from sources feels like the natural flow to me, so can we make
this work a bit better?

If we wanted to make the clean step optional, sbuild can check for
source differences, and barf if any are detected. It mostly does that
already. I believe it doesn't complain if there are extra files on disk,
but we could make it do that too.

Other than that, can we run "dh clean" inside the chroot?

Thanks!

Bug#1033626: sbuild: Dependencies should not be required outside the chroot (--no-clean should be the default)

[Johannes Schauer Marin Rodrigues]

Control: tag -1 + wontfix

Quoting Dima Kogan (2023-03-28 23:13:16)
> Hi. This just happened:
> 
>   dima@shorty:/tmp/opencv-4.6.0+dfsg$ sbuild -c sid-amd64 -d unstable -s -A 
> --anything-failed-commands '%s'  
> 
>   dh clean
>   dh: error: unable to load addon maven-repo-helper: Can't locate 
> Debian/Debhelper/Sequence/maven_repo_helper.pm in @INC (you may need to 
> install the Debian::Debhelper::Sequence::maven_repo_helper module) (@INC 
> contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 
> /usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 
> /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base 
> /usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 
> /usr/local/lib/site_perl) at (eval 14) line 1.
>   BEGIN failed--compilation aborted at (eval 14) line 1.
> 
>   make: *** [debian/rules:126: clean] Error 255
>   E: Failed to clean source directory /tmp/opencv-4.6.0+dfsg 
> (/tmp/opencv_4.6.0+dfsg-11.dsc)
> 
> The user expectation is that sbuild takes care of all the Build-Depends
> (by installing them in the chroot), but this apparently isn't 100% true:
> it runs "dh clean" outside the chroot, so any extra debhelper bits must
> be installed outside.
> 
> Can we fix this by not doing anything outside the chroot that sbuild
> itself doesn't Depend on? The simplest way to do that is to make
> --no-clean the default. Of we can run "dh clean" inside the chroot. Can we do
> something like that?

no. This is a feature not a bug. From your invocation I assume that you ran
sbuild inside and unpacked source directory? The input for sbuild is a .dsc. To
make it easier for the user, sbuild contains some code that automatically
builds the .dsc for you if you run sbuild inside an unpacked source directory.
To build the .dsc you need a clean source directory. Since sbuild cannot know
whether or not your source directory is clean, it runs the clean target by
default. If you know it's clean, then you can force sbuild to not do that by
passing --no-clean. If you do not want to pass --no-clean, then you can instead
create the .dsc in any other way you like and then pass the .dsc to sbuild. If
you pass a .dsc to sbuild, then sbuild will not attempt to run the lean target.

Does that make sense?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1033628: "full-upgrade" failed to resolve conflicts properly, while "safe-upgrade" did it perfectly fine

[Piotr H. Dabrowski]

Package: aptitude
Version: 0.8.13

"aptitude full-upgrade" failed to resolve conflicts properly, proposing
many removals of vital packages.
Meanwhile "aptitude safe-upgrade" proposed an ideal solution immediately.

This happened while using aptitude in Kubuntu, but I think Debian may have
similar issues when upgrading related KDE packages.
I upgraded Kubuntu 22.04 to 22.10 (which went smoothly), cleaned up any
leftover obsolete packages afterwards (nothing important and related to
this problem).
Then I added (back) kubuntu-backports repository to get the latest version
of KDE for Kubuntu 22.10 (upgrade from KDE 5.25.5 to 5.27.3) and tried to
apply the updates with "aptitude full-upgrade".

I attach solutions proposed by both "full-upgrade" and "safe-upgrade", and
also aptitude's log on what "safe-upgrade" eventually did.

It seems that the right solution (immediately proposed by "safe-upgrade")
was to remove obsolete packages, mainly:
- libkf5screen7
- libkwineffects13
- libkwinglutils13
and replace them with their newer releases (as required by other vital KDE
packages):
- libkf5screen8
- libkwineffects14
- libkwinglutils14

Instead "full-upgrade" tried to keep old versions of the above libraries
while removing vital KDE packages that depended on them (kscreen,
kwin-common, kwin-wayland, kwin-x11, libkscreenlocker5,
libnotificationmanager1, powerdevil, ...).

To my understanding, "full-upgrade" ought to be a stronger version of
upgrade, that resolves conflicts at least as good as "safe-upgrade" while
allowing to also remove packages in the process.
But it should not *needlessly* propose removal of important packages, when
there is a better solution (not requiring removal of vital packages), which
"safe-upgrade" finds in no time.

Is there a bug in "full-upgrade" conflict resolution in that case?
Or is such thing supposed to occur for "full-upgrade" ?

Maybe "full-upgrade" should simply begin with suggesting a solution that
"safe-upgrade" would propose, if it is a sane one?
 $ LANG=C sudo aptitude safe-upgrade
Resolving dependencies...
The following packages will be DOWNGRADED:
  thunderbird thunderbird-locale-en thunderbird-locale-en-us 
thunderbird-locale-pl
The following NEW packages will be installed:
  libkdecorations2private10{a} libkf5archive-data{a} libkf5screen-data{a} 
libkf5screen8{a} libkf5screendpms8{a} libkpipewire5{a} libkpipewiredmabuf5{a} 
libkpipewirerecord5{a} libksanecore1{a} libkwineffects14{a} libkwinglutils14{a}
  libqt5webview5{a} qml-module-org-kde-pipewire{a}
The following packages will be REMOVED:
  encfs{u} kwin-wayland-backend-drm{u} libkdecorations2private9{u} 
libkf5screen7{u} libkwineffects13{u} libkwinglutils13{u} 
libkwinxrenderutils13{u} libtinyxml2-9{u}
The following packages will be upgraded:
  ark baloo-kf5 bluedevil breeze breeze-cursor-theme breeze-gtk-theme 
breeze-icon-theme dolphin drkonqi elisa ffmpegthumbs firefox fonts-opensymbol 
frameworkintegration gwenview kaccounts-integration kaccounts-providers
  kactivities-bin kactivitymanagerd kamera kate kate5-data kcalc kde-cli-tools 
kde-cli-tools-data kde-config-gtk-style kde-config-gtk-style-preview 
kde-config-screenlocker kde-config-sddm kde-config-updates kde-spectacle
  kde-style-breeze kde-style-oxygen-qt5 kdeconnect kded5 kdegames-card-data-kf5 
kdegames-mahjongg-data-kf5 kdegraphics-thumbnailers kdenetwork-filesharing 
kdeplasma-addons-data kdialog kdoctools5 keditbookmarks kgamma5 khelpcenter
  khotkeys khotkeys-data kimageformat-plugins kinfocenter kinit kio kio-audiocd 
kio-extras kio-extras-data kmahjongg kmenuedit kmines konsole konsole-kpart 
konversation konversation-data kpackagelauncherqml kpackagetool5 kpat krdc
  kross kscreen ksshaskpass ksudoku ksystemlog ksystemstats ktexteditor-data 
ktexteditor-katepart ktorrent ktorrent-data kwalletmanager kwayland-data 
kwayland-integration kwin-addons kwin-common kwin-data kwin-style-breeze
  kwin-wayland kwin-x11 kwrited layer-shell-qt libcolorcorrect5 libdolphinvcs5 
libkaccounts2 libkdecorations2-5v5 libkf5activities5 libkf5activitiesstats1 
libkf5archive5 libkf5attica5 libkf5auth-data libkf5auth5 libkf5authcore5
  libkf5baloo5 libkf5balooengine5 libkf5baloowidgets-bin libkf5baloowidgets5 
libkf5bluezqt-data libkf5bluezqt6 libkf5bookmarks-data libkf5bookmarks5 
libkf5calendarevents5 libkf5cddb5 libkf5codecs-data libkf5codecs5
  libkf5compactdisc5 libkf5completion-data libkf5completion5 libkf5config-bin 
libkf5config-data libkf5configcore5 libkf5configgui5 libkf5configqml5 
libkf5configwidgets-data libkf5configwidgets5 libkf5contacts-data 
libkf5contacts5
  libkf5coreaddons-data libkf5coreaddons5 libkf5crash5 libkf5dbusaddons-bin 
libkf5dbusaddons-data libkf5dbusaddons5 libkf5declarative-data 
libkf5declarative5 libkf5dnssd-data libkf5dnssd5 libkf5doctools5 
libkf5filemetadata-bin
  libkf5filemetadata-data libkf5filemetadata3 libkf5globalaccel-bin 
libkf5globalaccel-data libkf5globalaccel5 libkf5globalaccelprivate5 
libkf5guiaddons-bin 

Bug#1033626: sbuild: Dependencies should not be required outside the chroot (--no-clean should be the default)

[Dima Kogan]

Package: sbuild
Version: 0.85.2
Severity: normal

Hi. This just happened:

  dima@shorty:/tmp/opencv-4.6.0+dfsg$ sbuild -c sid-amd64 -d unstable -s -A 
--anything-failed-commands '%s'  

  dh clean
  dh: error: unable to load addon maven-repo-helper: Can't locate 
Debian/Debhelper/Sequence/maven_repo_helper.pm in @INC (you may need to install 
the Debian::Debhelper::Sequence::maven_repo_helper module) (@INC contains: 
/etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 
/usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 
/usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base 
/usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 
/usr/local/lib/site_perl) at (eval 14) line 1.
  BEGIN failed--compilation aborted at (eval 14) line 1.

  make: *** [debian/rules:126: clean] Error 255
  E: Failed to clean source directory /tmp/opencv-4.6.0+dfsg 
(/tmp/opencv_4.6.0+dfsg-11.dsc)

The user expectation is that sbuild takes care of all the Build-Depends
(by installing them in the chroot), but this apparently isn't 100% true:
it runs "dh clean" outside the chroot, so any extra debhelper bits must
be installed outside.

Can we fix this by not doing anything outside the chroot that sbuild
itself doesn't Depend on? The simplest way to do that is to make
--no-clean the default. Of we can run "dh clean" inside the chroot. Can
we do something like that?

Thanks

Bug#1033627: exporttree=yes data loss

[Joey Hess]

Package: git-annex
Version: 10.20230126-2
Severity: important

git-annex has this bug, which can result in data loss when using an 
external special remote with exporttree=yes
https://git-annex.branchable.com/bugs/external_remote_export_sent_to_wrong_process/

This is fixed in version 10.20230329.

I've attached a patch series that fixes this. Note that the second patch
is not strictly necessary, but it's all that's needed to support
VERSION 2, which some external special remote programs will now be
using to avoid being used with the buggy git-annex. So, I strongly
recommend including it.

(The patches are lightly trimmed versions of upstream commits 
02662f52920e84cd9464641ada84f6c3bbe3f86a and
18d326cb6f27912542f41fbb9525eefdbd553d09)

-- 
see shy jo
From 02662f52920e84cd9464641ada84f6c3bbe3f86a Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Tue, 28 Mar 2023 15:21:10 -0400
Subject: [PATCH 1/6] fix concurrency bug causing EXPORT to be sent to the
 wrong external

Fix bug that caused broken protocol to be used with external remotes that
use exporttree=yes. In some cases this could result in the wrong content
being exported to, or retrieved from the remote.

Sponsored-by: Nicholas Golder-Manning on Patreon

diff --git a/Remote/External.hs b/Remote/External.hs
index 4077030fa3..352b9eb68d 100644
--- a/Remote/External.hs
+++ b/Remote/External.hs
@@ -377,19 +377,27 @@ handleRequest external req mp responsehandler =
 		handleRequest' st external req mp responsehandler
 
 handleRequestKey :: External -> (SafeKey -> Request) -> Key -> Maybe MeterUpdate -> ResponseHandler a -> Annex a
-handleRequestKey external mkreq k mp responsehandler = case mkSafeKey k of
-	Right sk -> handleRequest external (mkreq sk) mp responsehandler
+handleRequestKey external mkreq k mp responsehandler = 
+	withSafeKey k $ \sk -> handleRequest external (mkreq sk) mp responsehandler
+
+withSafeKey :: Key -> (SafeKey -> Annex a) -> Annex a
+withSafeKey k a = case mkSafeKey k of
+	Right sk -> a sk
 	Left e -> giveup e
 
 {- Export location is first sent in an EXPORT message before
  - the main request. This is done because the ExportLocation can
  - contain spaces etc. -}
 handleRequestExport :: External -> ExportLocation -> (SafeKey -> Request) -> Key -> Maybe MeterUpdate -> ResponseHandler a -> Annex a
-handleRequestExport external loc mkreq k mp responsehandler = do
-	withExternalState external $ \st -> do
-		checkPrepared st external
-		sendMessage st (EXPORT loc)
-	handleRequestKey external mkreq k mp responsehandler
+handleRequestExport external loc mkreq k mp responsehandler = 
+	withSafeKey k $ \sk ->
+		-- Both the EXPORT and subsequent request must be sent to the
+		-- same external process, so run both with the same external
+		-- state.
+		withExternalState external $ \st -> do
+			checkPrepared st external
+			sendMessage st (EXPORT loc)
+			handleRequest' st external (mkreq sk) mp responsehandler
 
 handleRequest' :: ExternalState -> External -> Request -> Maybe MeterUpdate -> ResponseHandler a -> Annex a
 handleRequest' st external req mp responsehandler
-- 
2.39.1

From 18d326cb6f27912542f41fbb9525eefdbd553d09 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Tue, 28 Mar 2023 17:00:08 -0400
Subject: [PATCH 4/6] external protocol VERSION 2

Support VERSION 2 in the external special remote protocol, which is
identical to VERSION 1, but avoids external remote programs neededing to
work around the above bug. External remote program that support
exporttree=yes are recommended to be updated to send VERSION 2.

Sponsored-by: Kevin Mueller on Patreon

diff --git a/Remote/External/Types.hs b/Remote/External/Types.hs
index 894f09dc30..633dc641bd 100644
--- a/Remote/External/Types.hs
+++ b/Remote/External/Types.hs
@@ -415,7 +415,7 @@ newtype JobId = JobId Integer
 	deriving (Eq, Ord, Show)
 
 supportedProtocolVersions :: [ProtocolVersion]
-supportedProtocolVersions = [1]
+supportedProtocolVersions = [1, 2]
 
 instance Proto.Serializable JobId where
 	serialize (JobId n) = show n
diff --git a/doc/design/external_special_remote_protocol.mdwn b/doc/design/external_special_remote_protocol.mdwn
index 3d2f0588ae..665687f5be 100644
--- a/doc/design/external_special_remote_protocol.mdwn
+++ b/doc/design/external_special_remote_protocol.mdwn
@@ -39,7 +39,7 @@ empty, but the separating spaces are still required in that case.
 The special remote is responsible for sending the first message, indicating
 the version of the protocol it is using.
 
-	VERSION 1
+	VERSION 2
 
 Recent versions of git-annex respond with a message indicating
 protocol extensions that it supports. Older versions of
@@ -271,7 +271,7 @@ These messages may be sent by the special remote at any time that it's
 handling a request.
 
 * `VERSION Int`  
-  Supported protocol version. Current version is 1. Must be sent first
+  Supported protocol version. Current version is 2. Must be sent first
   thing at startup, as until it sees this git-annex does not know how to
   talk with 

Bug#1026277: Quadrilateral Cowboy on Debian

[James Addison]

Hi Brendon (and with the relevant Debian bug thread on cc),

I've uploaded a copy of the packaged quadrilateralcowboy game source -
with some small modifications and fixes, including ARM64 support - to
the 'mentors.debian.net' pre-review site at
https://mentors.debian.net/package/quadrilateralcowboy/

It isn't eligible for inclusion in the upcoming Debian 12 "bookworm"
release, but it's possible it could be included in Debian "trixie"
(the next release.. each is named after a Toy Story character), if it
or another packaging attempt passes review.

To confirm: the package contains only the game engine, without any
game data; there is, however, separate support provided to make it
easier for users with Steam accounts to install the game data if they
have already purchased it.

Thanks,
James

Bug#1030959: singular-doc: install-info reports /usr/share/info/singular.info has no info dir entry

[Jerome BENOIT]

Hi Eric, thanks for your report.

The info for singular comes uncompressed because singular itself may read it.
Unfortunately singular can only read it uncompressed. Previously this 
singular.info
file was somewhere in the doc. The info file has been in the proper place
since version 1:4.3.0-p1+ds-1 (then in experimental).
Therefore fixing this issue requires to implement a z-read machinery in 
singular itself.
I might be easy but heavy to write. A patch is welcome.

Concerning the info dir entry issue, I will have a look to the machinery that 
seems
to generate the tex source. Thanks for pointing this issue.

Cheers, Jerome
--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033625: cups constantly without timeout connects to network printer, does not print

[Johan Kröckel]

Package: cups
Version: 2.4.2-2
Severity: important
X-Debbugs-Cc: johan.kroec...@gmail.com

I am using a Kyocera Ecosys m5526cdw over the network. Printing stopped working 
(worked with this version before).

Now when I try to start a print job cups ends with a message "Der Druckauftrag 
wurde nicht angenommen.". BUT:

Now cups connects to the printer (LED on printer lights up as long as the pc is 
on) but nothing is printed. When I reboot, the LED stops to blink as long as 
the system is not completely booted, then the connection starts again.

After running cupsctl --debug-logging, error_log grows by around 30 megabytes 
per hour.

-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages cups depends on:
ii  cups-client2.4.2-2
ii  cups-common2.4.2-2
ii  cups-core-drivers  2.4.2-2
ii  cups-daemon2.4.2-2
ii  cups-filters   1.28.17-2
ii  cups-ppdc  2.4.2-2
ii  cups-server-common 2.4.2-2
ii  debconf [debconf-2.0]  1.5.82
ii  ghostscript10.0.0~dfsg-9+b1
ii  libavahi-client3   0.8-9
ii  libavahi-common3   0.8-9
ii  libc6  2.36-8
ii  libcups2   2.4.2-2
ii  libgcc-s1  12.2.0-14
ii  libstdc++6 12.2.0-14
ii  libusb-1.0-0   2:1.0.26-1
ii  poppler-utils  22.12.0-2+b1
ii  procps 2:4.0.2-3

Versions of packages cups recommends:
ii  avahi-daemon  0.8-9
ii  colord1.4.6-2.2

Versions of packages cups suggests:
pn  cups-bsd   
pn  cups-pdf   
pn  foomatic-db-compressed-ppds | foomatic-db  
pn  smbclient  
ii  udev   252.6-1

-- debconf information:
  cupsys/backend: lpd, socket, usb, snmp, dnssd
  cupsys/raw-print: true

Bug#1033624: obs-studio: Pipewire capture source not listed

[Kevin Otte]

Package: obs-studio
Version: 29.0.2+dfsg-1+b1
Severity: important

Dear Maintainer,

The release notes for OBS Studio 27 indicate:
Added support for Wayland on Linux. This includes a new PipeWire capture source 
when using Wayland...

When I attempt to add a source to the current scene, I do not see the "Screen 
Capture (Pipewire)" option listed as demonstrated in the screenshot at 
https://www.linuxuprising.com/2021/06/obs-studio-27-released-with-wayland-and.html

As such, I am unable to capture the screen under Wayland (specifically, sway).

-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages obs-studio depends on:
ii  libavcodec59   7:5.1.2-3
ii  libavdevice59  7:5.1.2-3
ii  libavformat59  7:5.1.2-3
ii  libavutil577:5.1.2-3
ii  libc6  2.36-8
ii  libcurl3-gnutls7.88.1-7
ii  libfontconfig1 2.14.1-4
ii  libfreetype6   2.12.1+dfsg-4
ii  libgcc-s1  12.2.0-14
ii  libjansson42.14-2
ii  libluajit2-5.1-2   2.1-20230119-1
ii  libmbedcrypto7 2.28.2-1
ii  libmbedtls14   2.28.2-1
ii  libmbedx509-1  2.28.2-1
ii  libobs029.0.2+dfsg-1+b1
ii  libpci31:3.9.0-4
ii  libpulse0  16.1+dfsg1-2+b1
ii  libpython3.11  3.11.2-6
ii  libqt5core5a   5.15.8+dfsg-3
ii  libqt5gui5 5.15.8+dfsg-3
ii  libqt5network5 5.15.8+dfsg-3
ii  libqt5svg5 5.15.8-2
ii  libqt5widgets5 5.15.8+dfsg-3
ii  libqt5xml5 5.15.8+dfsg-3
ii  librist4   0.2.7+dfsg-1
ii  libspeexdsp1   1.2.1-1
ii  libsrt1.5-openssl  1.5.1-1
ii  libstdc++6 12.2.0-14
ii  libswscale67:5.1.2-3
ii  libudev1   252.6-1
ii  libv4l-0   1.22.1-5+b2
ii  libva-drm2 2.17.0-1
ii  libva2 2.17.0-1
ii  libx11-6   2:1.8.4-2
ii  libx264-1642:0.164.3095+gitbaee400-2+b1
ii  libxcb-composite0  1.15-1
ii  libxcb-randr0  1.15-1
ii  libxcb-shm01.15-1
ii  libxcb-xfixes0 1.15-1
ii  libxcb-xinerama0   1.15-1
ii  libxcb11.15-1
ii  python33.11.2-1
ii  python3.11 3.11.2-6

Versions of packages obs-studio recommends:
ii  obs-plugins  29.0.2+dfsg-1+b1

Versions of packages obs-studio suggests:
ii  pkexec 122-3
ii  policykit-1122-3
pn  v4l2loopback-dkms  

-- no debconf information

Bug#1033623: aptitude TUI does not provide a way to invoke "safe-upgrade" command

[Piotr Dąbrowski]

Package: aptitude
Version: 0.8.13

There is no way to invoke "safe-upgrade" command from aptitude TUI.
It only provides "full-upgrade" command (in menu and as shortcut "U").

Maybe a new menu item and a shortcut should be added for "safe-upgrade"?
Or "U" replaced with "safe-upgrade", while "full-upgrade" given a new
shortcut?
Or a dialog could ask which type of upgrade the user wants to invoke?

Bug#1033622: gnome-boxes: EFI option silently breaks snapshots

[Jeremy Bícha]

Source: gnome-boxes
Version: 43.2-1
Forwarded: https://gitlab.gnome.org/GNOME/gnome-boxes/-/issues/920

When I click the Create a Virtual Machine button, I often choose the
"Use EFI" option. I did not realize that this breaks snapshots because
the app doesn't tell me that it will. Also, the snapshot UI is still
there; it just doesn't work.

I wanted to just remove the Use EFI option, but there are some use cases for it.

Thank you,
Jeremy Bícha

Bug#1030600: redis breaks python-fakeredis autopkgtest: Connection refused

[Paul Gevers]

reassign 1030600 src:redis 5:7.0.8-2
affects 1030600 src:python-fakeredis
fixed 1030600 5:7.0.10-1
done 1030600
thanks


On Mon, Feb 06, 2023 at 10:46:52AM -0800, Chris Lamb wrote:

Paul Gevers wrote:


With a recent upload of redis the autopkgtest of python-fakeredis fails
in testing when that autopkgtest is run with the binary packages of
redis from unstable. It passes when run with only packages from testing.


Just had a stab at this. Unfortunately, I tried updating the
python-fakeredis package to the latest upstream version (hey, it worked
before!), but I believe I get the same errors.

Some thoughts:

* I wonder if this is a compatibility issue with python3-redis; a few
   issues on upstream's Github project seem to suggest the two projects
   are more interconnected that one might initially believe.


Apparently redis reverted or fixed the issue.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033621: node-matrix-js-sdk: CVE-2023-28427

[Salvatore Bonaccorso]

Source: node-matrix-js-sdk
Version: 9.11.0+~cs9.9.16-2
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for node-matrix-js-sdk.

CVE-2023-28427[0]:
| Prototype pollution

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-28427
https://www.cve.org/CVERecord?id=CVE-2023-28427
[1] 
https://github.com/matrix-org/matrix-js-sdk/security/advisories/GHSA-mwq8-fjpf-c2gr

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1033620: unblock: python-scrapy/2.8.0-2

[Andrey Rakhmatullin]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: python-scr...@packages.debian.org
Control: affects -1 + src:python-scrapy

Please unblock package python-scrapy. It fixes an RC bug (#1033425) by removing
mitmproxy from B-D, as the tests that use it don't work with the mitmproxy
version currently in testing/sid (the problem is known by the upstream but not
fixed there). The software itself doesn't use mitmproxy so this is a test-only
problem.


unblock python-scrapy/2.8.0-2
diff -Nru python-scrapy-2.8.0/debian/changelog 
python-scrapy-2.8.0/debian/changelog
--- python-scrapy-2.8.0/debian/changelog2023-02-02 13:43:11.0 
+0400
+++ python-scrapy-2.8.0/debian/changelog2023-03-26 17:57:50.0 
+0400
@@ -1,3 +1,10 @@
+python-scrapy (2.8.0-2) unstable; urgency=medium
+
+  * Remove B-D: mitmproxy as tests break with the new version of it (Closes:
+#1033425).
+
+ -- Andrey Rakhmatullin   Sun, 26 Mar 2023 17:57:50 +0400
+
 python-scrapy (2.8.0-1) unstable; urgency=medium
 
   * New upstream version.
diff -Nru python-scrapy-2.8.0/debian/control python-scrapy-2.8.0/debian/control
--- python-scrapy-2.8.0/debian/control  2023-02-02 13:43:11.0 +0400
+++ python-scrapy-2.8.0/debian/control  2023-03-26 17:57:50.0 +0400
@@ -11,7 +11,8 @@
  python3-all,
 Build-Depends-Indep:
  libjs-jquery ,
- mitmproxy ,
+# mitmproxy > 8 breaks the tests, https://github.com/scrapy/scrapy/issues/5454
+# mitmproxy ,
  python3-botocore ,
  python3-itemadapter  ,
  python3-itemloaders  ,

Bug#988948: CVE-2019-11939

[Salvatore Bonaccorso]

Hi László,

On Sun, Mar 26, 2023 at 04:13:01PM +0200, László Böszörményi wrote:
> Hi,
> 
> On Fri, Mar 17, 2023 at 7:54 PM László Böszörményi (GCS)  
> wrote:
> > On Thu, Mar 16, 2023 at 11:15 PM Moritz Mühlenhoff  wrote:
> > > Am Fri, May 21, 2021 at 09:46:31PM +0200 schrieb Moritz Muehlenhoff:
> > > > CVE-2019-11939:
> > > > https://github.com/facebook/fbthrift/commit/483ed864d69f307e9e3b9dadec048216100c0757
> > > is this fixed in Bookworm?
> >  I let the Security Team decide how this should be treated. I will try
> > to describe it in full and short.
>  Friendly ping, how the Security Team sees this issue. I've provided
> insights [1] and tend to think it's safe for Bullseye and later.

Strictly speaking if the code base diverged, CVE-2019-11939 would be
for facebook's fbthrift only. If Apache thrift has a similar issue,
which is my understanding of the THRIFT-5322 then it would need a own
CVE, which does not seem to exist (In some cases a CVE might be used
by multiple projects even if the code base is not the same).

I'm leaning to mark CVE-2019-11939 as NFU for facebook fbthrift
specifically, and let alone the Apache Thrift issues for similar case.
Given the issue would be no-dsa for bullseye and fixed in bookworm I
would not do anything particular unless a CVE get assigned.

Moritz, do you agree?

Regards,
Salvatore

Bug#1019732: apt-listbugs: undefined method `default' for " # returns password\n":String

[Vincent Lefevre]

On 2023-03-28 15:20:17 -0300, Antonio Terceiro wrote:
> I'm sorry but this bug report assumes an unsupported configuration:
> 
> >  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
> > 'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), 
> > (1, 'experimental')
> 
> This is not supportable at all.

Why not? Anyway, I doubt that this is related to the issue: packages
appear in unstable first, so that "testing" and "stable" should have
no effect in normal time.

> Plus:
> 
> > Versions of packages apt-listbugs depends on:
> [...]
> > ii  ruby1:3.0+1
> 
> Ruby 3.0, which is explicitly mentioned in the bug report as being used,
> was just temporarily in bookworm as an intermediate step between 2.7
> (bullseye) and 3.1 which is the version that is actually to be released
> with bookworm.

But at some point (when I reported the bug), it was in unstable.
See https://tracker.debian.org/pkg/ruby-defaults

[2022-09-20] Accepted ruby-defaults 1:3.0+3.1 (source) into unstable (Antonio 
Terceiro)
[2022-05-01] Accepted ruby-defaults 1:3.0+2 (source) into experimental (Antonio 
Terceiro)
[2022-03-10] ruby-defaults 1:3.0+1 MIGRATED to testing (Debian testing watch)
[2022-03-07] Accepted ruby-defaults 1:3.0+1 (source) into unstable (Lucas 
Kanashiro)

I had ruby 1:3.0+1 because it got into unstable on 2022-03-07.

ruby-defaults 1:3.0+3.1 went into unstable on 2022-09-20, while
I reported the bug on 2022-09-14. So it is completely normal
that I had ruby 1:3.0+1 at that time.

> One cannot really support a package that is not even in Debian
> anymore,

Well, the bug report was valid on 2022-09-14. Perhaps ruby got
fixed in the mean time. But perhaps the bug is still not fixed.
And according to

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019732#34

(for the error reproduced a second time), the bug is still there:

ii  apt 2.6.0
ii  ruby1:3.1
ii  ruby-debian 0.3.10+b8
ii  ruby-gettext3.3.3-2
ii  ruby-soap4r 2.0.5-6
ii  ruby-unicode0.4.4.4-1+b5
ii  ruby-xmlparser  0.7.3-4+b4

i.e. ruby 1:3.1, which is the current version.

> or to a system that mixes random versions of packages
> that were once in testing.

There are no mixed random versions.

Moreover, when there are incompatibilities between packages,
co-installation must be prevented by "Breaks:", etc. because
upgrades for unstable may be asynchronous.

> Unless you are able to reproduce this in a supported configuration
> (either stable or testing, but not something random in between), this is
> not a valid bug report. It's also not OK to reassign it to the Ruby
> interpreter, since there is no evidence of this actually being a bug in
> it, or even in a supported version of Ruby.

You should really learn how to read a bug report. It is normal that
bug reports mention old versions of packages, because after some
time, packages are updated. And bugs in old versions could still be
there in newer versions if they have not been fixed, which precisely
seems to be the case here: bug in ruby 1:3.0+1 on 2022-09-14, and the
same bug in ruby 1:3.1 a few days ago (reported by another user).

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

Bug#1033619: libboost-serialization1.74-dev: C++ builds fail when using optional.hpp

[Karl Pirton]

Package: libboost-serialization1.74-dev
Version: 1.74.0+ds1-20
Severity: important
X-Debbugs-Cc: jsupert...@dnmx.org

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***

How to reproduce: create a simple project that includes 
boost/serialization/optional.hpp, like so:
CMakeLists.txt:
cmake_minimum_required(VERSION 3.25)
project(BoostTest LANGUAGES CXX)

find_package(Boost REQUIRED COMPONENTS serialization)

add_library(mylibrary SHARED
main.cpp)

target_link_libraries(mylibrary INTERFACE Boost::serialization)

main.cpp:
#include 

void main (int argc, char* argv[])
{
return 0;
}


This configures fine, but breaks when compiling. 
CMake output:
$ cmake ..
-- The CXX compiler identification is GNU 12.2.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.74.0/BoostConfig.cmake 
(found version "1.74.0") found components: serialization 
-- Configuring done
-- Generating done
-- Build files have been written to: /home/sdebian/custom-deb/boosttest/build

Compiler output:
$ make
[ 50%] Building CXX object CMakeFiles/mylibrary.dir/main.cpp.o
In file included from /home/sdebian/custom-deb/boosttest/main.cpp:1:
/usr/include/boost/serialization/optional.hpp:98:8: error: ‘version’ is not a 
class template
   98 | struct version > {
  |^~~
/home/sdebian/custom-deb/boosttest/main.cpp:3:1: error: ‘::main’ must return 
‘int’
3 | void main (int argc, char* argv[])
  | ^~~~
make[2]: *** [CMakeFiles/mylibrary.dir/build.make:76: 
CMakeFiles/mylibrary.dir/main.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/mylibrary.dir/all] Error 2
make: *** [Makefile:91: all] Error 2



-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libboost-serialization1.74-dev depends on:
ii  libboost-serialization1.74.0  1.74.0+ds1-20
ii  libboost1.74-dev  1.74.0+ds1-20

libboost-serialization1.74-dev recommends no packages.

libboost-serialization1.74-dev suggests no packages.

-- no debconf information

Bug#1033618: kscreen_osd_service segfaults

[Maksim Dmitrichenko]

Package: kscreen
Version: 4:5.27.2-1
Severity: normal
X-Debbugs-Cc: dmitr...@gmail.com

kscreen_osd_service segfault when I hit Win+P and cancel switching between 
screens.
If that matters it happens in Plasma Wayland session. Stack trace from 
journalctl is below:

Mar 28 22:34:09 zinc dbus-daemon[1053]: [session uid=1001 pid=1053] Activating 
via systemd: service name='org.kde.kscreen.osdService' 
unit='plasma-kscreen-osd.service' requested by ':1.16' (uid=1001 pid=1252 
comm="/usr/bin/kded5")
Mar 28 22:34:09 zinc systemd[1034]: Starting plasma-kscreen-osd.service - 
KScreen OSD service...
Mar 28 22:34:09 zinc dbus-daemon[1053]: [session uid=1001 pid=1053] 
Successfully activated service 'org.kde.kscreen.osdService'
Mar 28 22:34:09 zinc systemd[1034]: Started plasma-kscreen-osd.service - 
KScreen OSD service.
Mar 28 22:34:09 zinc kscreen_osd_service[12991]: qrc:/qml/OsdSelector.qml:71:9: 
QML Heading: Binding loop detected for property "verticalAlignment"
Mar 28 22:34:12 zinc kernel: kscreen_osd_ser[12991]: segfault at 3256 ip 
7fdeeb34631e sp 7ffe549895f0 error 4 in 
libQt5Gui.so.5.15.8[7fdeeb2e2000+4d] likely on CPU 1 (core 0, socket 0)
Mar 28 22:34:12 zinc kernel: Code: 15 07 1b 00 00 41 55 44 0f b6 ee 41 54 55 53 
48 83 ec 20 48 8b 5f 08 64 48 8b 04 25 28 00 00 00 48 89 44 24 18 31 c0 48 8b 
03 <48> 8b 40 20 48 39 d0 0f 85 bd 00 00 00 4c 8b 63 08 89 f5 40 3a 73
Mar 28 22:34:12 zinc systemd[1]: Started systemd-coredump@2-13015-0.service - 
Process Core Dump (PID 13015/UID 0).
Mar 28 22:34:12 zinc systemd-coredump[13016]: [LNK] Process 12991 
(kscreen_osd_ser) of user 1001 dumped core.
  
  Module libudev.so.1 from deb 
systemd-252.6-1.amd64
  Module libsystemd.so.0 from deb 
systemd-252.6-1.amd64
  Stack trace of thread 12991:
  #0  0x7fdeeb34631e 
_ZN7QWindow10setVisibleEb (libQt5Gui.so.5 + 0x14631e)
  #1  0x7fdeeaee8f4f n/a 
(libQt5Core.so.5 + 0x2e8f4f)
  #2  0x7fdeeaee229f 
_ZN7QObject9destroyedEPS_ (libQt5Core.so.5 + 0x2e229f)
  #3  0x7fdeeaee7254 
_ZN7QObjectD2Ev (libQt5Core.so.5 + 0x2e7254)
  #4  0x7fdeec6494b9 
_ZN7KScreen6OutputD0Ev (libKF5Screen.so.8 + 0x354b9)
  #5  0x562cc7fc7165 n/a 
(kscreen_osd_service + 0x9165)
  #6  0x562cc7fc71a9 n/a 
(kscreen_osd_service + 0x91a9)
  #7  0x562cc7fc4b9f n/a 
(kscreen_osd_service + 0x6b9f)
  #8  0x7fdeeaedd6f0 
_ZN7QObject5eventEP6QEvent (libQt5Core.so.5 + 0x2dd6f0)
  #9  0x7fdeeaeb16f8 
_ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent (libQt5Core.so.5 + 
0x2b16f8)
  #10 0x7fdeeaeb4681 
_ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData 
(libQt5Core.so.5 + 0x2b4681)
  #11 0x7fdeeaf0a153 n/a 
(libQt5Core.so.5 + 0x30a153)
  #12 0x7fdee92627a9 
g_main_context_dispatch (libglib-2.0.so.0 + 0x547a9)
  #13 0x7fdee9262a38 n/a 
(libglib-2.0.so.0 + 0x54a38)
  #14 0x7fdee9262acc 
g_main_context_iteration (libglib-2.0.so.0 + 0x54acc)
  #15 0x7fdeeaf09836 
_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE
 (libQt5Core.so.5 + 0x309836)
  #16 0x7fdeeaeb017b 
_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 
0x2b017b)
  #17 0x7fdeeaeb82d6 
_ZN16QCoreApplication4execEv (libQt5Core.so.5 + 0x2b82d6)
  #18 0x562cc7fc38d2 n/a 
(kscreen_osd_service + 0x58d2)
  #19 0x7fdeeaa4618a n/a 
(libc.so.6 + 0x2718a)
  #20 0x7fdeeaa46245 
__libc_start_main (libc.so.6 + 0x27245)
  #21 0x562cc7fc3961 n/a 
(kscreen_osd_service + 0x5961)
  
  Stack trace of thread 12992:
  #0  0x7fdeeab1b0af __poll 
(libc.so.6 + 0xfc0af)
  #1  0x7fdee92629ae n/a 
(libglib-2.0.so.0 + 0x549ae)
  

Bug#1033492: unblock: php8.2/8.2.4-1 ????

[Salvatore Bonaccorso]

Hi Paul,

On Sun, Mar 26, 2023 at 01:40:10PM +0200, Paul Gevers wrote:
> Hi Ondřej,
> 
> On 26-03-2023 08:36, Ondřej Surý wrote:
> > just a quick reply - PHP already has a security (and if I remember 
> > correctly release) team exception from the last time. So, we already had 
> > this talk about upstream policies.
> 
> I *suspect* the same, but because of the shear amount of work ongoing for
> the release team at the moment, I hope people can help point to the relevant
> information instead of us needing to find it.
> 
> It can obviously wait a couple of days, we're not *that* close to releasing
> yet.

if this helps on the decision: We would, similarly as done for
bullseye already, want to follow the upstream releases until supported
by upstream and then switch to cherry-pick security fixes only on top.

Ondrej can give a more detailed input, so please wait for his reply.

Regards,
Salvatore

Bug#1033569: systemd-boot-efi: Secure Boot via shim broken on arm64 due to missing SBAT section

[Emanuele Rocca]

Hi,

On Mon, Mar 27, 2023 at 06:23:57PM +0200, Michael Biebl wrote:
> Please consider raising this issue upstream

There's no need, the bug is fixed in main (currently at 3a051522).

It is however reproducible checking out tag v253, so presumably upstream
version v254 will be the first release fixing this.

I see that there's been quite some work in the area, eg. commit 2afeaf16.

Thanks,
  Emanuele

Bug#1022837: /lib/runit/run_sysv_scripts uses wrong test to skip initscripts

[Andras Korn]

On Tue, Mar 28, 2023 at 01:10:36AM +0200, Lorenzo wrote:

Hi,

> Please follow up and let me know if my idea would solve this issue or at 
> least improve the situation from your point of view:
> > 
> > Checking for /etc/sv/$name and skipping initscripts if those directories 
> > exist is wrong for two reasons:
> > 
> >  1. /etc/sv/$name may not be symlinked into /etc/service (false positive);
> > 
> >  2. /etc/service may contain a symlink to a service directory for this 
> > service that is elsewhere in the filesystem, not in /etc/sv (false 
> > negative).
> > 
> > As a minimum, I suggest the following: instead of /etc/sv/$name, check for 
> > /etc/service/$name (and $name-daemon if necessary), and not with "-d" but 
> > "-L" (because when running rcS.d, the target of the symlink may only appear 
> > later, for example when a new filesystem is mounted).
> 
> I propose the following:
> 
> * patch runit-helper, update-service and /lib/runit/trigger_sv so that every 
> (package provided) runit service is always represented in /etc/service/, 
> either with a foo symlink (enabled) or with a .foo symlink (disabled).

OK, this works (although I don't see why it's necessary), as long as nothing 
gets confused by the existence of both symlinks. For example, under this 
scheme, I may have:

/service/ssh -> /some/dir/where/I/keep/my/services/ssh  # created "manually"
/service/.ssh -> /etc/sv/ssh# created during 
container provisioning to prevent the ssh package from installing its version 
of the service (otherwise it creates /etc/service/ssh/ssh)

If there is potential for confusion, then a mechanism to delete the .ssh 
symlink if/when the plain ssh symlink is present would also be needed.

>   This way I (as a packager) can test /etc/service/ to know if a runscript 
> exists in /etc/sv/.

You can, but I'm not sure I see why you have to. The /etc/sv location is not 
special per se; why does it matter whether there is anything there in 
particular?

>   For users that have their own runscripts collection somewhere in the 
> filesystem: they will enable their services by creating the foo symlink, and 
> they can have the sysv emulation skip certain services (let's say a bar 
> service) by creating a /etc/service/.bar symlink.

That's a needless extra hoop to jump through. When deciding whether to skip 
invoking /etc/init.d/bar, why is it better to check for the existence of 
"/etc/service/.bar" than "/etc/service/bar"? The latter needs to exist anyway, 
because that's what will cause runit to start the service.

>   This would also prevent runit package (and runit-helper) to enable the bar 
> service, if any /etc/sv/bar exists, because the logic in runit-helper and 
> sv_trigger only test if the symlink (or dot-symlink) exists, but it doesn't 
> care where it points.

Again, to me it seems that the existence of /etc/service/bar should be 
sufficient. If it exists, the service is enabled. If it needs to be disabled in 
a way that it can be re-enabled later, you can rename the existing bar symlink 
to ".bar", regardless of where it points.

>   In any case runit/runit-helper only creates and remove links in the 
> /etc/runit/runsvdir/default directory, so if you point runsvdir to another 
> directory runit package doesn't enable or disable anything for you.

Perhaps it should be called debian-default; but it's good to know that using a 
differently-named runsvdir is a way of opting out of much of the 
nanny-automation I find so annoying. :)

> * turn the run_sysv_scripts into a runit service that test for 
> /etc/service/$name. Two main reason for this:

This needs to be thought through carefully (it would need to only run once, but 
finish before other services are started -- for example, it could do a 
runsvchdir in ./finish).

>   1. users can disable it, or change it at their will, while any change into 
> /lib/runit/run_sysv_scripts is overwritten by the package, so users are 
> forced to change stage 2 and create their own version of the script

You could also achieve this by preferring /etc/runit/lib/run_sysv_scripts if it 
is executable, and only running /lib/runit/run_sysv_scripts if not. Even more 
complex setups would also be possible, with /lib/runit/run_sysv_scripts relying 
on shell functions that a user-supplied sourced file could override, but I 
think that would go too far.

>   2. when runit services are mixed with sysv scripts in the start sequence, 
> the run_sysv_scripts can be RC-buggy, see #1024969 [1] for an example

Yeah, that's a hard problem to solve cleanly.

Maybe you just shouldn't ship (or enable by default) runit services that 
initscript-based stuff frequently depends on. I'm not sure how much else there 
is, other than dbus.

Alternatively, you could ship a one-shot runit service that depends on the dbus 
service and that invokes all initscripts that declare a dependency on dbus... 
Far from my idea of clean.

I also have another idea but it's so complex 

Bug#1033617: libopenexr-dev: Cannot just upgrade libopenexr-dev to 3.1.5-4 because of file conflict with older version of libilmbase-dev

[Felix Stupp]

for documentation purposes, I now fixed the issue for my systems by 
force-removing the old package first with dpkg and then installing its 
replacements with markauto:

sudo dpkg --remove --force-depends libilmbase-dev
sudo aptitude install lib{imath,openexr}-dev+M  # or apt install --mark-auto 
lib{imath,openexr}-dev

Bug#1033617: libopenexr-dev: Cannot just upgrade libopenexr-dev to 3.1.5-4 because of file conflict with older version of libilmbase-dev

[Felix Stupp]

Package: libopenexr-dev
Version: 3.1.5-4
Severity: serious
Justification: Policy 7.4
X-Debbugs-Cc: me+debian-b...@banananet.work

Dear Maintainer,

I cannot upgrade this package from version 2.5.7-1 to version 3.1.5-4
due to a file conflict with the package libilmbase-dev on version
2.5.4-1. I tried with apt & aptitude as well. Both want to replace
libilmbase-dev with libopenexr-dev in a single execution of them, but
fail to do that in a way that dpkg allows that (tries first to install
the new package and then uninstall the old one).
Currently I see no other solution than removing the old one first aside
with all packages depending it on it, and then installing the new one
with all packages which were removed before.

They already have a "Breaks" & a "Replace" relationship, which seems to
be right, but I assume adding a "Conflicts" relation will fix that,
for "Breaks" "dpkg will refuse to allow the package […] to be unpacked
unless the broken package is deconfigured first", while for "Conflicts"
it says that "dpkg will refuse to allow them to be unpacked on the
system at the same time".

I marked this bug as serious as I think, even if another solution may be
found, that still a Conflicts field on this package referring to the
older one may be required unless that is not possible. However, I'm not
100% sure, so feel free to change the severity. Maybe I just ran into
this problem due to other circumstances a stable user will not run into.

Also I assume that if this configuration will be released into bookworm,
others will having problems as well.

Best Regards,
Felix Stupp


-- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (550, 'testing'), (500, 'testing-security'), (400, 
'stable-updates'), (400, 'stable-security'), (400, 'stable'), (110, 
'unstable'), (102, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libopenexr-dev depends on:
pn  libilmbase-dev  
ii  libopenexr252.5.7-1

libopenexr-dev recommends no packages.

libopenexr-dev suggests no packages.

-- no debconf information

Bug#1019732: apt-listbugs: undefined method `default' for " # returns password\n":String

[Antonio Terceiro]

Control: reassign -1 apt-listbugs

On Tue, Mar 28, 2023 at 06:39:35PM +0200, Francesco Poli wrote:
> Control: reassign -1 ruby 1:3.0+1
> Control: affects -1 + apt-listbugs
> 
> 
> On Fri, 24 Mar 2023 00:40:41 +0100 Francesco Poli wrote:
> 
> [...]
> > What you saw seems to be another case where some text from the source
> > (a line taken from /usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb, in
> > this instance) is treated as a String by the Ruby interpreter and its
> > `default' method is invoked. But the String class has no `default'
> > method, which causes the error.
> > 
> > This seems to happen sporadically and cannot be easily reproduced.
> > 
> > I cannot understand what's going on.
> > I am more and more persuaded that this bug report should be reassigned
> > to another package (probably package ruby), in order to ask for an
> > investigation by people more knowledgeable than me...
> 
> 
> Dear Debian Ruby Team,
> I am reassigning this [bug] to package ruby, since a couple of users
> are experiencing awkward and sporadic behaviors that I really cannot
> understand and do not seem due to the code of apt-listbugs or of the
> libraries.
> 
> [bug]: 
> 
> Could you please investigate these sporadic issues?
> Refer to the [bug] log for more detailed information.
> 
> Thanks for your time and dedication!

I'm sorry but this bug report assumes an unsupported configuration:

>  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
> 'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
> 'experimental')

This is not supportable at all.

Plus:

> Versions of packages apt-listbugs depends on:
[...]
> ii  ruby1:3.0+1

Ruby 3.0, which is explicitly mentioned in the bug report as being used,
was just temporarily in bookworm as an intermediate step between 2.7
(bullseye) and 3.1 which is the version that is actually to be released
with bookworm. One cannot really support a package that is not even in
Debian anymore, or to a system that mixes random versions of packages
that were once in testing.

Unless you are able to reproduce this in a supported configuration
(either stable or testing, but not something random in between), this is
not a valid bug report. It's also not OK to reassign it to the Ruby
interpreter, since there is no evidence of this actually being a bug in
it, or even in a supported version of Ruby.


signature.asc
Description: PGP signature

Bug#1033616: cups prepends job number to job-name so job names near 255 characters may be too long

[John Hughes]

Package: cups
Version: 2.3.3op2-3+deb11u2
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I printed a page from firefox with a very, very long URL.  Firefox used the 
first 255 bytes of the URL as the job name.

   * What was the outcome of this action?

The job mysteriously didn't print.  Lookin in the cups log (with debug on) I 
found the lines:

D [28/Mar/2023:18:14:44 +0200] [Job 365] job-name nameWithoutLanguage 365 - 
https://xxx//xx

D [28/Mar/2023:18:27:36 +0200] [Job 369] Validate-Job: 
client-error-request-value-too-long (client-error-request-value-too-long)

notice how the job name passed to cups ("https://xxx...;) is shorter than 255 
characters, but when the job number "365 - " is prepended it is longer tnan 255 
characters and so overflows.

   * What outcome did you expect instead?

That my print job be printed rather than just geting stuck in the print queue 
forever.

How to reproduce:

lp -o 
'job-name=https://xxx//xx'


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

Kernel: Linux 5.10.0-21-amd64 (SMP w/4 CPU threads)
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)
LSM: AppArmor: enabled

Versions of packages cups depends on:
ii  cups-client2.3.3op2-3+deb11u2
ii  cups-common2.3.3op2-3+deb11u2
ii  cups-core-drivers  2.3.3op2-3+deb11u2
ii  cups-daemon2.3.3op2-3+deb11u2
ii  cups-filters   1.28.7-1+deb11u1
ii  cups-ppdc  2.3.3op2-3+deb11u2
ii  cups-server-common 2.3.3op2-3+deb11u2
ii  debconf [debconf-2.0]  1.5.77
ii  ghostscript9.53.3~dfsg-7+deb11u2
ii  libavahi-client3   0.8-5+deb11u1
ii  libavahi-common3   0.8-5+deb11u1
ii  libc6  2.31-13+deb11u5
ii  libcups2   2.3.3op2-3+deb11u2
ii  libgcc-s1  10.2.1-6
ii  libstdc++6 10.2.1-6
ii  libusb-1.0-0   2:1.0.24-3
ii  poppler-utils  20.09.0-3.1+deb11u1
ii  procps 2:3.3.17-5

Versions of packages cups recommends:
ii  avahi-daemon  0.8-5+deb11u1
ii  colord1.4.5-3

Versions of packages cups suggests:
ii  cups-bsd   2.3.3op2-3+deb11u2
pn  cups-pdf   
ii  foomatic-db-compressed-ppds [foomatic-db]  20200820-1
ii  smbclient  2:4.13.13+dfsg-1~deb11u5
ii  udev   247.3-7+deb11u1

-- debconf information:
  cupsys/backend: lpd, socket, usb, snmp, dnssd
  cupsys/raw-print: true

Bug#1019732: apt-listbugs: undefined method `default' for " # returns password\n":String

[Francesco Poli]

Control: reassign -1 ruby 1:3.0+1
Control: affects -1 + apt-listbugs


On Fri, 24 Mar 2023 00:40:41 +0100 Francesco Poli wrote:

[...]
> What you saw seems to be another case where some text from the source
> (a line taken from /usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb, in
> this instance) is treated as a String by the Ruby interpreter and its
> `default' method is invoked. But the String class has no `default'
> method, which causes the error.
> 
> This seems to happen sporadically and cannot be easily reproduced.
> 
> I cannot understand what's going on.
> I am more and more persuaded that this bug report should be reassigned
> to another package (probably package ruby), in order to ask for an
> investigation by people more knowledgeable than me...


Dear Debian Ruby Team,
I am reassigning this [bug] to package ruby, since a couple of users
are experiencing awkward and sporadic behaviors that I really cannot
understand and do not seem due to the code of apt-listbugs or of the
libraries.

[bug]: 

Could you please investigate these sporadic issues?
Refer to the [bug] log for more detailed information.

Thanks for your time and dedication!
Bye.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp05090y1bHF.pgp
Description: PGP signature

Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program

[Thorsten Glaser]

On Tue, 28 Mar 2023, Jesse Smith wrote:

>pidof isn't going to chase down multiple layers of symbolic links. If

I consider that a (not release-critical) bug that should be
addressed by a Debian-local patch if upstream is hostile.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#1033615: RFS: runit-services/0.6.0 -- UNIX init scheme with service supervision (services)

[Lorenzo]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "runit-services":

 * Package name : runit-services
   Version  : 0.6.0
   Upstream contact : [fill in name and email of upstream]
 * URL  : [fill in URL of upstream's web site]
 * License  : BSD-3-Clause, CC0-1.0
 * Vcs  :
   https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services Section
  : admin

The source builds the following binary packages:

  runit-services - UNIX init scheme with service supervision (services)

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

  https://mentors.debian.net/package/runit-services/

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

  dget -x
  
https://mentors.debian.net/debian/pool/main/r/runit-services/runit-services_0.6.0.dsc

Git repo:

  https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/tree/next

Changes since the last upload:

 runit-services (0.6.0) experimental; urgency=medium
 .
   * update-copyright script: allow "Comment:" line
   * new runscripts:
  avahi-daemon, avahi-dnsconfd, uuidd, bluetooth,
  network-manager, connman (Closes: #1032657)
   * dhclient: don't hardcode interfaces (Closes: #1033542)
   * update copyright
   * testsuite:
 - block all systemd services
 - fix pkgname detection with systemd service

Regards,
Lorenzo

Bug#1033614: unblock: zfs-linux/2.1.9-3

[Aron Xu]

Package: release.debian.org
Severity: normal
User:release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc:pkg-zfsonlinux-de...@alioth-lists.debian.net

Please unblock the package zfs-linux/2.1.9-3.

[ Reason ]

zfs-linux has autopkgtest but it never passed on armel (because the
kernel header detection logic), even though this
is marked as "Not a regression" auto-migration is blocked.

See https://ci.debian.net/packages/z/zfs-linux/testing/armel/

Changes included are targeted small fixes based on upstream
2.1.10-staging branch, which is intended for releasing
the next stable minor release. Most importantly, there is a change
fixing https://github.com/openzfs/zfs/issues/14599
which we have in the previous 2.1.9-2 that would affect some users
from booting the system.

[ Impact ]

The user won't notice any difference except some bugs have been fixed.

[ Tests ]

Manually installed the binaries and verified that things work as expected.

[ Risks ]

Changes are minimal. I can't think of any negative side effects.
Because some of the new patches are added to series
file in the middle, it results in quite some noise in the debdiff
(some old patches are shown as removed). To help
reviewing the patches, the commit itself can be found on salsa:
https://salsa.debian.org/zfsonlinux-team/zfs/-/commit/a02ecc74c240e64ead560091ae68f2252b072adf

New patches are:
* 0002-System-wide-speculative-prefetch-limit.patch
  include/sys/arc_impl.h | 1 +
  module/zfs/dmu_zfetch.c | 29 -
  2 files changed, 25 insertions(+), 5 deletions(-)
* 0003-Add-missing-increment-to-dsl_deadlist_move_bpobj.patch
  module/zfs/dsl_deadlist.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
* 0008-initramfs-fix-zpool-get-argument-order.patch
  contrib/initramfs/scripts/zfs | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)
* 0011-Fix-for-mountpoint-legacy.patch
  contrib/initramfs/scripts/zfs | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)
* 0012-QAT-Fix-uninitialized-seed-in-QAT-compression.patch
  module/os/linux/zfs/qat_compress.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

[ Checklist ]

  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock zfs-linux/2.1.9-3


zfs-linux_2.1.9-3.debdiff
Description: Binary data

Bug#1033613: edk2: please provide DEBUG versions of OVMF_CODE and AAVMF_CODE

[Emanuele Rocca]

Source: edk2
Version: 2022.11-6
Severity: wishlist

Hi,

edk2 binaries are currently built with BUILD_TYPE = RELEASE [1].

For debugging purposes, it is also possible to build them with
BUILD_TYPE = DEBUG. It would be great if debug versions of OVMF_CODE and
AAVMF_CODE could be built, perhaps named AAVMF_CODE.debug.fd and
OVMF_CODE.debug.fd

Thanks,
  Emanuele

[1] https://sources.debian.org/src/edk2/2022.11-6/debian/rules/#L7

Bug#1033542: runit-services: dhclient spamming syslog (eth1 hardcoded)

[Lorenzo]

Control: tags -1 patch

Hi Dimitris,

since the fix for this goes to experimental and it may takes some time,
I'm attaching a patch that should stop the flooding of logs; you need
to manually edit files in /etc/sv/dhclient/* thought ..

diff --git a/sv/dhclient/check b/sv/dhclient/check
index e406a77..ad2a474 100755
--- a/sv/dhclient/check
+++ b/sv/dhclient/check
@@ -1,5 +1,9 @@
 #!/bin/sh
-. ./conf/interfaces || exit 1
-for i in $INTERFACES; do
-  ifconfig $i |grep 'inet' >/dev/null || exit 1
-done
+. ./conf/interfaces
+if [ -n "$INTERFACES" ]; then
+  for i in $INTERFACES; do
+ifconfig $i |grep 'inet' >/dev/null || exit 1
+  done
+else
+  ifconfig |grep 'inet' >/dev/null || exit 1
+fi
diff --git a/sv/dhclient/conf/interfaces b/sv/dhclient/conf/interfaces
index c5f1bb2..1f9775b 100644
--- a/sv/dhclient/conf/interfaces
+++ b/sv/dhclient/conf/interfaces
@@ -1 +1 @@
-INTERFACES=eth1
+INTERFACES=
diff --git a/sv/dhclient/run b/sv/dhclient/run
index 2cc7fca..7bc3482 100755
--- a/sv/dhclient/run
+++ b/sv/dhclient/run
@@ -1,10 +1,10 @@
 #!/usr/bin/env /lib/runit/invoke-run
 #Copyright: 2005-2008 Gerrit Pape 
-# 2022  Lorenzo Puliti 
+# 2022-2023  Lorenzo Puliti 
 #License: BSD-3-Clause
 
 exec 2>&1
 
 . ./conf/interfaces || exit 162
 
-exec chpst -m1200 dhclient -d $INTERFACES
+exec chpst -m1200 dhclient -d ${INTERFACES:-}
-- 

On Mon, 27 Mar 2023 11:06:55 +0300 "Dimitris T."
 wrote:
> Package: runit-services
> Version: 0.5.4
> Severity: normal
> 
> Hey Lorenzo,
> 
> have been flooded with syslog entries of : 
> 
> "
> 2023-03-26_18:39:14.63103 Internet Systems Consortium DHCP Client
> 4.4.3-P1 2023-03-26_18:39:14.63109 Copyright 2004-2022 Internet
> Systems Consortium. 2023-03-26_18:39:14.63110 All rights reserved.
> 2023-03-26_18:39:14.63116 For info, please visit
> https://www.isc.org/software/dhcp/ 2023-03-26_18:39:14.63117 
> 2023-03-26_18:39:14.65832 Cannot find device "eth1"
> 2023-03-26_18:39:14.67499 Failed to get interface index: No such
> device 2023-03-26_18:39:14.67502 
> 2023-03-26_18:39:14.67503 If you think you have received this message
> due to a bug rather 2023-03-26_18:39:14.67503 than a configuration
> issue please read the section on submitting 2023-03-26_18:39:14.67504
> bugs on either our web page at www.isc.org or in the README file
> 2023-03-26_18:39:14.67505 before submitting a bug.  These pages
> explain the proper 2023-03-26_18:39:14.67509 process and the
> information we find helpful for debugging. 2023-03-26_18:39:14.67510
> 2023-03-26_18:39:14.67511 exiting. "
> 
> those log entries are written every second(!) in syslog AND
> /var/log/runit/dhclient/current... source of the "problem" seems to
> be that /usr/share/runit/sv/dhclient/conf/interfaces uses hardcoded
> "eth1" by default, when there is no "eth1" on this system.. maybe
> option value should be empty by default or commented out (?). not
> sure what's the best approach for defaults in this runit service.
> 
> thx in advance,
> d.
> 
> 
> 
> -- System Information:
> Debian Release: 12.0
> merged-usr: no
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.1.18-antix.1-amd64-smp (SMP w/4 CPU threads; PREEMPT)
> Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8),
> LANGUAGE not set Shell: /bin/sh linked to /bin/dash
> Init: runit (via /run/runit.stopit)
> 
> Versions of packages runit-services depends on:
> ii  runit 2.1.2-54
> ii  runit-helper  2.15.2
> 
> Versions of packages runit-services recommends:
> ii  runit-init  2.1.2-54
> 
> Versions of packages runit-services suggests:
> pn  socklog  
> 
> -- no debconf information
> 
> 

Bug#1033612: unblock: cinnamon-settings-daemon/5.6.2-1

[Fabio Fantoni]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: cinnamon-settings-dae...@packages.debian.org, 
fantonifa...@tiscali.it

Control: affects -1 + src:cinnamon-settings-daemon

Please unblock package cinnamon-settings-daemon

5.6.2-1 include a new bugfix release with 2 fixes:
- xsettings: Round the Xft.dpi setting to an integer
- power: Fix free order

I also added replace of libfontconfig1-dev build-dep. with 
libfontconfig-dev,

libfontconfig1-dev is a transition metapackage from bullseye so should don't
be a risk FWIK.

No regression found or reported, I think is good to have in bookworm.

[ Risks ]
I consider the risk of regression very small

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]

unblock cinnamon-settings-daemon/5.6.2-1
diff --git a/debian/changelog b/debian/changelog
index 170bcc6..f843ec7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+cinnamon-settings-daemon (5.6.2-1) unstable; urgency=medium
+
+  * New upstream bugfix version 5.6.2
+  * Replace libfontconfig1-dev build-dep. with libfontconfig-dev
+
+ -- Fabio Fantoni   Sun, 19 Mar 2023 22:29:11 +0100
+
 cinnamon-settings-daemon (5.6.1-1) unstable; urgency=medium
 
   [ Debian Janitor ]
diff --git a/debian/control b/debian/control
index a8ec4c0..1ca4a36 100644
--- a/debian/control
+++ b/debian/control
@@ -18,7 +18,7 @@ Build-Depends:
  libcinnamon-desktop-dev (>= 5.6.1~),
  libcolord-dev,
  libcups2-dev,
- libfontconfig1-dev,
+ libfontconfig-dev,
  libglib2.0-dev,
  libgnomekbd-dev,
  libgtk-3-dev,
diff --git a/meson.build b/meson.build
index ab48440..108d7e5 100644
--- a/meson.build
+++ b/meson.build
@@ -1,4 +1,4 @@
-project('cinnamon-settings-daemon', 'c', version: '5.6.1', meson_version: '>= 
0.47')
+project('cinnamon-settings-daemon', 'c', version: '5.6.2', meson_version: '>= 
0.47')
 
 gnome = import('gnome')
 i18n = import('i18n')
diff --git a/plugins/power/gpm-idletime.c b/plugins/power/gpm-idletime.c
index 1a41a14..aaadb89 100644
--- a/plugins/power/gpm-idletime.c
+++ b/plugins/power/gpm-idletime.c
@@ -349,8 +349,8 @@ gpm_idletime_alarm_free (GpmIdletime *idletime,
alarm_item->xalarm);
 }
 g_object_unref (alarm_item->idletime);
-g_free (alarm_item);
 g_ptr_array_remove (idletime->priv->array, alarm_item);
+g_free (alarm_item);
 return TRUE;
 }
 
diff --git a/plugins/xsettings/csd-xsettings-manager.c 
b/plugins/xsettings/csd-xsettings-manager.c
index 30bbbed..07ab142 100644
--- a/plugins/xsettings/csd-xsettings-manager.c
+++ b/plugins/xsettings/csd-xsettings-manager.c
@@ -761,8 +761,8 @@ xft_settings_set_xresources (CinnamonSettingsXftSettings 
*settings)
 
 g_debug("xft_settings_set_xresources: orig res '%s'", add_string->str);
 
-update_property (add_string, "Xft.dpi",
-g_ascii_dtostr (dpibuf, sizeof (dpibuf), 
(double) settings->scaled_dpi / 1024.0));
+g_snprintf (dpibuf, sizeof (dpibuf), "%d", (int) (settings->scaled_dpi 
/ 1024.0 + 0.5));
+update_property (add_string, "Xft.dpi", dpibuf);
 update_property (add_string, "Xft.antialias",
 settings->antialias ? "1" : "0");
 update_property (add_string, "Xft.hinting",

Bug#1033602: nvidia-graphics-drivers: dh_missing finds missing files and I think it is my fault

[Renato Gallo]

Now I am following your lead and what you wrote.
Tried with the untouched source version and it worked.
I have noticed that the dch foo edits the changelog so I tried to
update it to the actual version.
Now it fails at the checksums . since your method seems to differ
from the kernel deb compilation I was asking myself how does he
updates the checksums ?

On Tue, 2023-03-28 at 17:16 +0200, Andreas Beckmann wrote:
> On 28/03/2023 16.11, Renato Gallo wrote:
> > First things first Thanks again I will try
> > I based my experiment onto the master main git
> > what should I clone to be reasonably safe and follow your lead ?
> 
> 525 or better 530. master is ancient and stale (and is no longer 
> refreenced in metadata, so should really go away.
> 
> 
> Andreas

Bug#1033609: ytdl_hook: EDL doesn't support fragmentswithout duration with MP4 DASH

[eng . stk]

Sorry, this is duplicate of #1033595, should have caught it beforehand.

Please close this and merge with that bug report discussion instead.

Thanks!

Bug#1033602: nvidia-graphics-drivers: dh_missing finds missing files and I think it is my fault

[Andreas Beckmann]

On 28/03/2023 16.11, Renato Gallo wrote:

First things first Thanks again I will try
I based my experiment onto the master main git
what should I clone to be reasonably safe and follow your lead ?


525 or better 530. master is ancient and stale (and is no longer 
refreenced in metadata, so should really go away.



Andreas

Bug#1020469: Ready to Implement

[Soren Stoutner]

The dependencies are finally in place so this can be implemented.

To make things simpler for dictionary packagers, we are using a virtual package 
and an 
unversioned path for the conversion tool so that dictionary packagers don’t 
have to make 
modifications to their packages when the versions of Qt change in Debian.

All you should need to do is the following:

1.  Build-depend on `convert-bdic`.
2.  Use /usr/bin/convert-bdic to do the dictionary conversion.
3.  Place the .bdic files in /usr/share/hunspell-bdic.

More detailed information can be found in the dictionary packager documentation 
at:

file:///usr/share/doc/dictionaries-common-dev/dsdt-policy.html#hunspell-bdic

Thanks,

Soren

-- 
Soren Stoutner
so...@stoutner.com


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

Bug#1028149: bookworm: ntp has been replaced by ntpsec

[Antoine Beaupré]

On 2023-03-27 11:15:20, Miroslav Lichvar wrote:
> On Thu, 23 Mar 2023 12:12:04 + Richard Lewis 
>  wrote:
>> Presumably the release notes should also say that most people should
>> consider systemd-timesyncd as this is priority:standard (since at
>> least buster, but i dont remember seeing this in release notes then)?
>> - i assume the idea is that if you dont have any special needs beyond
>> "set the clock" should use systemd-timesyncd, And people who need
>> extra features (like running their own ntp server) should install
>> ntpsec / chrony / opennntpd ?
>
> Recommending timesyncd as an NTP client to replace ntpd would not be a
> good idea, especially if you consider the default configuration using
> servers from pool.ntp.org.
>
> The pool is very robust as a whole, but individual servers cannot be
> relied on. They are run by volunteers. Some are well maintained, some
> are not. Occasionally, servers drift away or step to a distant past or
> future, e.g. due to GPS firmware bugs. The pool monitoring system
> detects such servers and quickly removes them from the pool DNS, but
> simple clients like timesyncd cannot recover from that. Once they got
> the address from DNS, they will follow the server for as long as it
> claims to be synchronized, no matter how wrong it is. A full-featured
> NTP client is needed to detect and replace falsetickers. With
> timesyncd the only option is to restart the service when you notice
> the clock is wrong. I've seen many times users complaining about that
> and getting this advice over the years.
>
> timesyncd needs to be configured with a reliable server to work well.
> Canonical maintains their own NTP servers and uses them by default in
> Ubuntu. That makes senses. Debian uses pool.ntp.org, so it should
> recommend a proper NTP client for a reliable service.

It seems to me this should be reported as a bug against the
systemd-timesyncd package, at the very least.

Right now this is completely empty:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=systemd-timesyncd;dist=unstable

Now I agree that timesyncd might not be the best default NTP server: my
vote goes for chrony, personnally. But if we're going to object to it,
it should be at least properly documented in that package's bug list...

(To be fair, there *were* bugs reported agains the package before:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;dist=unstable;package=systemd-timesyncd

... just not this specific one.)

a.

-- 
Si l'image donne l'illusion de savoir
C'est que l'adage pretend que pour croire,
L'important ne serait que de voir
- Lofofora

Bug#1033602: nvidia-graphics-drivers: dh_missing finds missing files and I think it is my fault

[Renato Gallo]

Tried 

Now I am trying to build the new version and obviously it fails on the
checksums.
When you try with the kernel in debian/bin there's a gen.py
command that does it.
How do you update the checksums ?

Thanks again  :)

On Tue, 2023-03-28 at 15:20 +0200, Andreas Beckmann wrote:
> On 28/03/2023 11.24, Renato Gallo wrote:
> > I am mainly blaming myself, and I would be grateful if you
> > can give me a hint about what am I missing.
> 
> You should start with rebuilding the package that is in the archive -
> that obviously works for me and the buildds ;-)
> This should help to separate errors on your side (please take no
> offense 
> here, the documentation for working with these packages is likely
> bad, 
> incomplete and outdated (patches welcome!), so its unfortunately hard
> for outsiders to get the workflow running) from problems caused by 
> possible upstream layout changes ...
> 
> Which packaging code did you base your work on? Branch 530 in git? (I
> hope I pushed that after uploading the beta packages.)
> 
> I only build these packages with gbp (git-buildpackage) backed by 
> pbuilder, but sbuild should work as well. I never used debuild (or 
> dpkg-buildpackage) directly on them.
> 
> Just tried in a chroot with build-essential and devscripts installed:
> 
> # apt-get build-dep nvidia-graphics-drivers
> # su -s /bin/bash - nobody
> $ cd /tmp
> $ apt-get source nvidia-graphics-drivers
> $ cd nvidia-graphics-drivers-530.30.02/
> $ dch foo
> $ debuild
> 
> and I got ../nvidia-graphics-drivers_530.30.02-1.1_amd64.changes
> 
> Andreas

Bug#1033294: lintian: detect and warn about Python 2 related paths within packages

[James Addison]

Package: lintian
Followup-For: Bug #1033294
X-Debbugs-Cc: patrice.dur...@gmail.com, debian...@lists.debian.org

As guidance for potential contributors: it looks like the logic for the
existing 'python-module-in-wrong-location' check (mentioned in the mailing list
thread) is here:

https://sources.debian.org/src/lintian/2.116.3/lib/Lintian/Check/Languages/Python.pm/?hl=392#L317-L370

Each lintian check should include accompanying test coverage; there is some
Debian package scripting to create good and bad install paths that are suitable
for test purposes here:

https://sources.debian.org/src/lintian/2.116.3/t/recipes/checks/languages/python/files-python-modules/build-spec/debian/install

Bug#1033611: ecflow-client: Icons in programs not visible due to missing dependency libqt6svg6

[Blaz Jesenko]

Package: ecflow-client
Version: 5.9.2-1+b1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
Icons not visible, program not usable
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
apt get install libqt6svg6
   * What was the outcome of this action?
fixed it
   * What outcome did you expect instead?
Could someone please add missing dependency (libqt6svg6) to bookworm 
repository? It is fixed in experimental. Not sure how to report this.
*** End of the template - remove these template lines ***


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

Kernel: Linux 6.1.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
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 ecflow-client depends on:
ii  libboost-filesystem1.74.0   1.74.0+ds1-20
ii  libboost-program-options1.74.0  1.74.0+ds1-20
ii  libc6   2.36-8
ii  libcrypt1   1:4.4.33-2
ii  libgcc-s1   12.2.0-14
ii  libqt6charts6   6.4.2-2
ii  libqt6core5compat6  6.4.2-1
ii  libqt6core6 6.4.2+dfsg-7
ii  libqt6gui6  6.4.2+dfsg-7
ii  libqt6network6  6.4.2+dfsg-7
ii  libqt6widgets6  6.4.2+dfsg-7
ii  libssl3 3.0.8-1
ii  libstdc++6  12.2.0-14
ii  python3 3.11.2-1
ii  python3-fuse2:1.0.5-1+b3

ecflow-client recommends no packages.

ecflow-client suggests no packages.

-- no debconf information

Bug#1033610: RFS: dh-sysuser/1.3.10+really1.4.4 -- debhelper addon to handle creation of system users

[Lorenzo]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "dh-sysuser":

 * Package name : dh-sysuser
   Version  : 1.3.10+really1.4.4
   Upstream contact : [fill in name and email of upstream]
 * URL  : https://salsa.debian.org/debian/dh-sysuser
 * License  : GPL-3+
 * Vcs  : https://salsa.debian.org/debian/dh-sysuser
   Section  : admin

The source builds the following binary packages:

  dh-sysuser - debhelper addon to handle creation of system users
  sysuser-helper - dh-sysuser implementation detail

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

  https://mentors.debian.net/package/dh-sysuser/

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

  dget -x
  
https://mentors.debian.net/debian/pool/main/d/dh-sysuser/dh-sysuser_1.3.10+really1.4.4.dsc

Git repo:

  https://salsa.debian.org/debian/dh-sysuser/-/tree/next

Changes since the last upload:

 dh-sysuser (1.3.10+really1.4.4) experimental; urgency=medium
 .
   * Fix typo in postrm snippet (Closes: #1032947)
   * update copyright years

Regards,
Lorenzo

Bug#1033609: ytdl_hook: EDL doesn't support fragmentswithout duration with MP4 DASH

[eng . stk]

Package: mpv

Version: 0.35.1-1

Since yt-dlp package updated to v2023.03.04-1, mpv errors out opening  
some streams from youtube for instance, giving no sound or no playback  
at all in some situations:


"ytdl_hook: EDL doesn't support fragmentswithout duration with MP4  
DASH", described here:


https://github.com/flathub/io.mpv.Mpv/issues/159

There's a mpv upstream fix for this bug, please consider merging this PR:

https://github.com/mpv-player/mpv/pull/11398/commits

Thanks!

Bug#1033602: nvidia-graphics-drivers: dh_missing finds missing files and I think it is my fault

[Renato Gallo]

First things first Thanks again I will try
I based my experiment onto the master main git
what should I clone to be reasonably safe and follow your lead ?

On Tue, 28 Mar 2023 15:20:47 +0200 Andreas Beckmann  wrote:
> On 28/03/2023 11.24, Renato Gallo wrote:
> > I am mainly blaming myself, and I would be grateful if you can give me
a hint about what am I missing.
>
> You should start with rebuilding the package that is in the archive -
> that obviously works for me and the buildds ;-)
> This should help to separate errors on your side (please take no offense
> here, the documentation for working with these packages is likely bad,
> incomplete and outdated (patches welcome!), so its unfortunately hard
> for outsiders to get the workflow running) from problems caused by
> possible upstream layout changes ...
>
> Which packaging code did you base your work on? Branch 530 in git? (I
> hope I pushed that after uploading the beta packages.)
>
> I only build these packages with gbp (git-buildpackage) backed by
> pbuilder, but sbuild should work as well. I never used debuild (or
> dpkg-buildpackage) directly on them.
>
> Just tried in a chroot with build-essential and devscripts installed:
>
> # apt-get build-dep nvidia-graphics-drivers
> # su -s /bin/bash - nobody
> $ cd /tmp
> $ apt-get source nvidia-graphics-drivers
> $ cd nvidia-graphics-drivers-530.30.02/
> $ dch foo
> $ debuild
>
> and I got ../nvidia-graphics-drivers_530.30.02-1.1_amd64.changes
>
> Andreas
>
>

Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program

[Jesse Smith]

On 2023-03-28 10:56 a.m., Markus Fischer wrote:
> I did a few more tests of my own and didn't find any other issues.
>
> - Markus
>

Thank you. I'm planning to do the same and then publish an update to
sysvinit.

Bug#1033608: Exception: ModuleNotFoundError: No module named 'core.pe.photo'

[Ionuț Ciocîrlan]

Package: dupeguru
Version: 4.3.1-3+b1
Severity: grave
Justification: renders package unusable


The upstream vanilla build symlinks /usr/share/dupeguru/core/pe
and /usr/share/dupeguru/qt/pe to /usr/lib/dupeguru/core/pe and
/usr/lib/dupeguru/qt/pe respectively.

In the debian package these symlinks are missing, and emptu directories
are created instead (although the lib files are built and packaged).

This causes an immediate exception on run.


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

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

Versions of packages dupeguru depends on:
ii  libc6 2.36-8
ii  python3   3.11.2-1
ii  python3-distro1.8.0-1
ii  python3-mutagen   1.46.0-1
ii  python3-pyqt5 5.15.9+dfsg-1
ii  python3-semantic-version  2.9.0-2
ii  python3-send2trash1.8.1~b0-2
ii  python3-xxhash3.2.0-1+b1

dupeguru recommends no packages.

dupeguru suggests no packages.

-- no debconf information

Bug#1017787: ikhal crashes regularly when creating events

[Dirk Griesbach]

Hi,

Am Sa, 20. Aug 2022 um 16:04:19 +0200 schrieb VA:

ikhal crashes regularly when creating events, with this backtrace:


Looking at the traceback, this seems to be the same issue as #1023341 
and #1007255. Both are already fixed with khal version 1:0.10.5-1. Thus 
this bug could also be closed.

Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program

[Markus Fischer]

I did a few more tests of my own and didn't find any other issues.

- Markus

Am 24.03.23 um 15:17 schrieb Jesse Smith:



On 2023-03-24 6:44 a.m., Markus Fischer wrote:

I think I've figured it out. With the following patch I don't see the
unexpected behaviour anymore:

--- a/src/killall5.c
+++ b/src/killall5.c
@@ -662,6 +662,7 @@ int readproc()
     /* Try to stat the executable. */
     snprintf(path, sizeof(path), "/proc/%s/exe", d->d_name);
  p->pathname = (char *)xmalloc(PATH_MAX);
+   memset(p->pathname, 0, PATH_MAX);
     if (readlink(path, p->pathname, PATH_MAX) == -1) {
     p->pathname = NULL;
     }



This patch looks good to me. I'm adding it upstream.

Will run some more tests before publishing 3.07. And would appreciate it
if everyone following this issue could test too and provide feedback.

- Jesse

Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program

[Jesse Smith]

On 2023-03-28 10:40 a.m., Mark Hindley wrote:
> On Thu, Mar 23, 2023 at 11:25:02AM -0300, Jesse Smith wrote:
>>> $ ls -l $(which vi)
>>> lrwxrwxrwx 1 root root 20 Jan 11 04:16 /usr/bin/vi ->
>>> /etc/alternatives/vi
>>> $ ls -l /etc/alternatives/vi
>>> lrwxrwxrwx 1 root root 17 Jan 11 04:16 /etc/alternatives/vi ->
>>> /usr/bin/vim.tiny
>>> $ ls -l /usr/bin/vim.tiny
>>> -rwxr-xr-x 1 root root 1713240 Jan 11 04:16 /usr/bin/vim.tiny
>>
>> Okay, yes, this makes sense. The symbolic links are making multiple
>> jumps so it won't work. This is expected behaviour because there is no
>> executable running called /usr/bin/vi or /etc/alternatives/vi. Running
>> "pidof vi.tiny" would work. Or if /usr/bin/vi was a link to
>> /usr/bin/vim.tiny then "pidof $(which vi)" would work. pidof won't
>> follow aliases or symbolic links with multiple hops and different names.
> As Thorsten pointed out, multiple layers of symlinks is used in several places
> in Debian, not least the alternatives system.
>
> Shouldn't src/killall.c readproc() run readlink(2) until it gets the canonical
> executable path?
>
> Alternatively, if you really want to keep the behaviour change then pidof.8
> needs updating to reflect the new behaviour.
>
>
I would say the manual page is already accurate. It says symbolic links
to executables will return a match. This is true. It doesn't say
symbolic links to symbolic links will return a match. Though perhaps
this should be explicitly stated to clarify. I'll update the wording.

pidof isn't going to chase down multiple layers of symbolic links. If
the operator is dealing with situations like Debian's alternatives
system then they should just use the real name of the executable (gcc vs
cc, for example). Using a name that links to a name that links to
another name is likely to bite people.

Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program

[Mark Hindley]

On Thu, Mar 23, 2023 at 11:25:02AM -0300, Jesse Smith wrote:
> > $ ls -l $(which vi)
> > lrwxrwxrwx 1 root root 20 Jan 11 04:16 /usr/bin/vi ->
> > /etc/alternatives/vi
> > $ ls -l /etc/alternatives/vi
> > lrwxrwxrwx 1 root root 17 Jan 11 04:16 /etc/alternatives/vi ->
> > /usr/bin/vim.tiny
> > $ ls -l /usr/bin/vim.tiny
> > -rwxr-xr-x 1 root root 1713240 Jan 11 04:16 /usr/bin/vim.tiny
> 
> 
> Okay, yes, this makes sense. The symbolic links are making multiple
> jumps so it won't work. This is expected behaviour because there is no
> executable running called /usr/bin/vi or /etc/alternatives/vi. Running
> "pidof vi.tiny" would work. Or if /usr/bin/vi was a link to
> /usr/bin/vim.tiny then "pidof $(which vi)" would work. pidof won't
> follow aliases or symbolic links with multiple hops and different names.

As Thorsten pointed out, multiple layers of symlinks is used in several places
in Debian, not least the alternatives system.

Shouldn't src/killall.c readproc() run readlink(2) until it gets the canonical
executable path?

Alternatively, if you really want to keep the behaviour change then pidof.8
needs updating to reflect the new behaviour.

Mark

Bug#1032070: fixed in ruby3.1 3.1.2-7~exp

[Praveen Arimbrathodiyil]

On 28/03/23 6:44 pm, Antonio Terceiro wrote:

On Fri, Mar 24, 2023 at 02:23:07PM +0530, Pirate Praveen wrote:

On Wed, 15 Mar 2023 01:05:14 +0530 Pirate Praveen 
wrote:

Are you planning to upload this to bookworm? We are starting to test
gitlab on bookworm to be able to provide gitlab via bookworm-fasttrack
when bookworm releases. I hit this issue today when testing gitlab on
bookworm.


I uploaded it yesterday and there is an unblock request already in
place.


Thanks! We added a work around to install openssl 3.0.2 from 
rubygems.org for now (as we are in contrib, we occasionally have to 
resort to this when we can fix some packages fast enough, but we still 
prefer to use as much packaged dependencies as possible). Though this 
will need a depends on ruby-dev and libssl-dev, which we can remove once 
it gits bookworm. Though I noticed a regression in ppc64el 
https://ci.debian.net/data/autopkgtest/testing/ppc64el/n/nanoc/32447890/log.gz



I tried rebuilding ruby in bookworm, but one test failed. Not sure if this
is a random failure or is it actually using the internet?

See #1033395


I didn't really try on bookworm, but the difference between it and sid
at this point is probably small and it just worked for me and on the
buildds. it might be random.



Though on a second try also it failed for me. But if it is building fine 
on buildd, may be we can ignore it for now.


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032070: fixed in ruby3.1 3.1.2-7~exp

[Praveen Arimbrathodiyil]

On 28/03/23 6:44 pm, Antonio Terceiro wrote:

I didn't really try on bookworm, but the difference between it and sid
at this point is probably small and it just worked for me and on the
buildds. it might be random.


Though on a second try also it failed for me. But if it is building fine 
on buildd, may be we can ignore it for now.


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033602: nvidia-graphics-drivers: dh_missing finds missing files and I think it is my fault

[Andreas Beckmann]

On 28/03/2023 11.24, Renato Gallo wrote:

I am mainly blaming myself, and I would be grateful if you can give me 
a hint about what am I missing.


You should start with rebuilding the package that is in the archive - 
that obviously works for me and the buildds ;-)
This should help to separate errors on your side (please take no offense 
here, the documentation for working with these packages is likely bad, 
incomplete and outdated (patches welcome!), so its unfortunately hard 
for outsiders to get the workflow running) from problems caused by 
possible upstream layout changes ...


Which packaging code did you base your work on? Branch 530 in git? (I 
hope I pushed that after uploading the beta packages.)


I only build these packages with gbp (git-buildpackage) backed by 
pbuilder, but sbuild should work as well. I never used debuild (or 
dpkg-buildpackage) directly on them.


Just tried in a chroot with build-essential and devscripts installed:

# apt-get build-dep nvidia-graphics-drivers
# su -s /bin/bash - nobody
$ cd /tmp
$ apt-get source nvidia-graphics-drivers
$ cd nvidia-graphics-drivers-530.30.02/
$ dch foo
$ debuild

and I got ../nvidia-graphics-drivers_530.30.02-1.1_amd64.changes

Andreas

Bug#1032070: fixed in ruby3.1 3.1.2-7~exp

[Antonio Terceiro]

On Fri, Mar 24, 2023 at 02:23:07PM +0530, Pirate Praveen wrote:
> On Wed, 15 Mar 2023 01:05:14 +0530 Pirate Praveen 
> wrote:
> > Are you planning to upload this to bookworm? We are starting to test
> > gitlab on bookworm to be able to provide gitlab via bookworm-fasttrack
> > when bookworm releases. I hit this issue today when testing gitlab on
> > bookworm.

I uploaded it yesterday and there is an unblock request already in
place.

> I tried rebuilding ruby in bookworm, but one test failed. Not sure if this
> is a random failure or is it actually using the internet?
> 
> See #1033395

I didn't really try on bookworm, but the difference between it and sid
at this point is probably small and it just worked for me and on the
buildds. it might be random.


signature.asc
Description: PGP signature

Bug#1030854: kded5: It keeps on crashing everytime I boot into the system

[André Verwijs]

Package: kded5
Version: 5.103.0-1
Followup-For: Bug #1030854
X-Debbugs-Cc: dutchgig...@gmail.com

still happening with Bookworm release...
Hint: You are currently not seeing messages from other users and the system.
  Users in groups 'adm', 'systemd-journal' can see all messages.
  Pass -q to turn off this notice.
   PID: 13997 (kded5)
   UID: 1000 (verwijs)
   GID: 1000 (verwijs)
Signal: 11 (SEGV)
 Timestamp: Tue 2023-03-28 14:44:49 CEST (5min ago)
  Command Line: /usr/bin/kded5
Executable: /usr/bin/kded5
 Control Group:
/user.slice/user-1000.slice/user@1000.service/session.slice/dbus.service
  Unit: user@1000.service
 User Unit: dbus.service
 Slice: user-1000.slice
 Owner UID: 1000 (verwijs)
   Boot ID: b42844118a6548a98d3b3f60093f2ecd
Machine ID: caaee3f8a89d430081634817f93feaa6
  Hostname: debian-verwijs
   Storage:
/var/lib/systemd/coredump/core.kded5.1000.b42844118a6548a98d3b3f60093f2ecd.13997.168000748900.zst
(present)
  Size on Disk: 3.7M
   Message: Process 13997 (kded5) of user 1000 dumped core.

Module libsystemd.so.0 from deb systemd-252.6-1.amd64
Module libudev.so.1 from deb systemd-252.6-1.amd64
Stack trace of thread 14017:
#0  0x7f068f6a9ccc n/a (libc.so.6 + 0x8accc)
#1  0x7f068f65aef2 raise (libc.so.6 + 0x3bef2)
#2  0x7f0690756b46 _ZN6KCrash19defaultCrashHandlerEi
(libKF5Crash.so.5 + 0x5b46)
#3  0x7f068f65af90 n/a (libc.so.6 + 0x3bf90)
#4  0x7f068f6a9ccc n/a (libc.so.6 + 0x8accc)
#5  0x7f068f65aef2 raise (libc.so.6 + 0x3bef2)
#6  0x7f068f65af90 n/a (libc.so.6 + 0x3bf90)
#7  0x7f068f6a9ccc n/a (libc.so.6 + 0x8accc)
#8  0x7f068f65aef2 raise (libc.so.6 + 0x3bef2)
#9  0x7f06727f13b0 g_closure_invoke (libgobject-2.0.so.0 +
0x163b0)
#10 0x7f06728041a5 n/a (libgobject-2.0.so.0 + 0x291a5)
#11 0x7f067280abf5 g_signal_emit_valist
(libgobject-2.0.so.0 + 0x2fbf5)
#12 0x7f067280adbf g_signal_emit (libgobject-2.0.so.0 +
0x2fdbf)
#13 0x7f067293d115 n/a (libgio-2.0.so.0 + 0x103115)
#14 0x7f068e86267f g_main_context_dispatch
(libglib-2.0.so.0 + 0x5467f)
#15 0x7f068e862a38 n/a (libglib-2.0.so.0 + 0x54a38)
#16 0x7f068e862acc g_main_context_iteration
(libglib-2.0.so.0 + 0x54acc)
#17 0x7f06727d44bd n/a (libdconfsettings.so + 0xb4bd)
#18 0x7f068e88ccfd n/a (libglib-2.0.so.0 + 0x7ecfd)
#19 0x7f068f6a7fd4 n/a (libc.so.6 + 0x88fd4)
#20 0x7f068f72866c n/a (libc.so.6 + 0x10966c)

Stack trace of thread 13997:
#0  0x7f068f71b0af __poll (libc.so.6 + 0xfc0af)
#1  0x7f0690756150 n/a (libKF5Crash.so.5 + 0x5150)
#2  0x7f0690756ad6 _ZN6KCrash19defaultCrashHandlerEi
(libKF5Crash.so.5 + 0x5ad6)
#3  0x7f068f65af90 n/a (libc.so.6 + 0x3bf90)
#4  0x7f06705eeba4 _ZNK10PackageKit11Transaction4roleEv
(libpackagekitqt5.so.1 + 0x1aba4)
#5  0x7f067068ccae n/a (kded_apperd.so + 0xfcae)
#6  0x7f067068cdf6 n/a (kded_apperd.so + 0xfdf6)
#7  0x7f068fae8f4f n/a (libQt5Core.so.5 + 0x2e8f4f)
#8  0x7f06705e2095
_ZN10PackageKit6Daemon22transactionListChangedERK11QStringList
(libpackagekitqt5.so.1 + 0xe095)
#9  0x7f068fae8f7c n/a (libQt5Core.so.5 + 0x2e8f7c)
#10 0x7f06705fab38 n/a (libpackagekitqt5.so.1 + 0x26b38)
#11 0x7f06705fbd73 n/a (libpackagekitqt5.so.1 + 0x27d73)
#12 0x7f06905ad61b n/a (libQt5DBus.so.5 + 0x2361b)
#13 0x7f068fadd6f0 _ZN7QObject5eventEP6QEvent
(libQt5Core.so.5 + 0x2dd6f0)
#14 0x7f0690962fae
_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent (libQt5Widgets.so.5 +
0x162fae)
#15 0x7f068fab16f8
_ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent (libQt5Core.so.5 +
0x2b16f8)
#16 0x7f068fab4681
_ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData
(libQt5Core.so.5 + 0x2b4681)
#17 0x7f068fb0a153 n/a (libQt5Core.so.5 + 0x30a153)
#18 0x7f068e8627a9 g_main_context_dispatch
(libglib-2.0.so.0 + 0x547a9)
#19 0x7f068e862a38 n/a (libglib-2.0.so.0 + 0x54a38)
#20 0x7f068e862acc g_main_context_iteration
(libglib-2.0.so.0 + 0x54acc)
#21 0x7f068fb09836
_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE
(libQt5Core.so.5 + 0x309836)
#22 0x7f068fab017b

Bug#924052: debhelper: dh_auto_test should prefer 'make check' over 'make test'

[Jerome BENOIT]

Dear Maintainer,

I second the request by Benjamin.

According to the interesting discussion on a very near subject for igraph [1],
VSCode and cmake appear to attribute a different purpose to the target `test`.

For packaging igraph I set a workaround in the `d/rules`.
However, I guess that the `test` and `check` targets must be considered to have
different purposes according to some current standards.
That is, they are not interchangeable.

hth,
Jerome

[1] https://github.com/igraph/igraph/issues/2290


--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033607: sogo: /usr/bin/sogo linked against wrong version of libgnustep-base

[Philipp Gruber]

Package: sogo
Version: 5.0.1-4+deb11u1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

The binary of /usr/sbin/sogod contained in bullseye is linked to
libgnustep-base.so.1.24.
However, the package depends on libgnustep-base.so.1.27,
which is the current version of bullseye.

Downgrading is not possible due to dependencies. I assume re-building
the binary with correct dependencies will fix this.

Kind regards,
Phil


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

Kernel: Linux 5.10.0-20-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_GB.UTF-8), LANGUAGE=en_GB.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sogo depends on:
ii  adduser   3.118
ii  gnustep-base-runtime  1.27.0-3
ii  init-system-helpers   1.60
ii  libc6 2.31-13+deb11u5
ii  libcrypt1 1:4.4.18-4
ii  libcurl4  7.74.0-1.3+deb11u3
ii  libgcc-s1 10.2.1-6
ii  libglib2.0-0  2.66.8-1
ii  libgnustep-base1.27   1.27.0-3
ii  liblasso3 2.6.1-3
ii  libmemcached111.0.18-4.2
ii  liboath0  2.6.6-3
ii  libobjc4  10.2.1-6
ii  libsbjson2.3  2.3.2-4+b2
ii  libsodium23   1.0.18-1
ii  libsope1  5.0.1-2
ii  libssl1.1 1.1.1n-0+deb11u3
ii  libzip4   1.7.3-1
ii  lsb-base  11.1.0
ii  memcached 1.6.9+dfsg-1
ii  sogo-common   5.0.1-4+deb11u1
ii  systemd   247.3-7+deb11u1
ii  zip   3.0-12

sogo recommends no packages.

Versions of packages sogo suggests:
ii  default-mysql-server1.0.7
ii  mariadb-server-10.5 [virtual-mysql-server]  1:10.5.18-0+deb11u1

-- Configuration Files:
/etc/sogo/sogo.conf [Errno 13] Permission denied: '/etc/sogo/sogo.conf'

-- no debconf information

Bug#1033606: Add dep8 tests for mosh

[Robie Basak]

Source: mosh
Version: 1.4.0-1
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch

Hi,

In Ubuntu, we added a couple of dep8 tests to the mosh package. These
should help detect any regressions caused by changes in dependencies
before they land. I think these should apply and be equally useful for
Debian. Please consider applying the attached patch. Thanks!

diff --git a/debian/changelog b/debian/changelog
index af36f16..2f1ba64 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+mosh (1.4.0-1ubuntu1) lunar; urgency=medium
+
+  [ Sergio Durigan Junior ]
+  * d/t/upstream-tests: New dep8 test which runs the upstream test
+suite against a system mosh.
+
+  [ Robie Basak ]
+  * d/t/smoke: smoke test for mosh using pexpect.
+
+ -- Robie Basak   Wed, 22 Mar 2023 13:36:00 +
+
 mosh (1.4.0-1build1) lunar; urgency=medium
 
   * Rebuild against new libprotobuf32.
diff --git a/debian/tests/control b/debian/tests/control
new file mode 100644
index 000..7623e07
--- /dev/null
+++ b/debian/tests/control
@@ -0,0 +1,7 @@
+Tests: upstream-tests
+Depends: @, @builddeps@
+Restrictions: allow-stderr
+
+Tests: smoke
+Depends: mosh, openssh-server, python3-pexpect
+Restrictions: allow-stderr, isolation-container, needs-root, superficial, 
breaks-testbed
diff --git a/debian/tests/smoke b/debian/tests/smoke
new file mode 100755
index 000..7ff856d
--- /dev/null
+++ b/debian/tests/smoke
@@ -0,0 +1,28 @@
+#!/bin/sh
+set -ex
+
+# HOME may not be set in an autopkgtest environment, but we want to be on the
+# same page as ssh on where ~/.ssh is. See LP: #2012514.
+if [ "$HOME" = "" ]; then
+   export HOME=$(getent passwd `whoami`|cut -d: -f6)
+fi
+
+echo 'mosh motd test' > /etc/motd
+mkdir -pm700 "$HOME"/.ssh
+if [ ! -f "$HOME"/.ssh/id_rsa ]; then
+   ssh-keygen -N '' -C mosh-smoke -f "$HOME"/.ssh/id_rsa
+fi
+if [ ! -f "$HOME"/.ssh/authorized_keys ] || ! grep -q mosh-smoke\$ 
"$HOME"/.ssh/authorized_keys; then
+   cat "$HOME"/.ssh/id_rsa.pub >> "$HOME"/.ssh/authorized_keys
+fi
+python3 <

Bug#1023079: toot: manpage out of date

[Martin Dosch]

Package: toot
Version: 0.34.1-1
Followup-For: Bug #1023079

Dear Maintainer,

I can confirm that the manpage doesn't properly document the program. I 
discovered that the manpage mentions a `curses` command which is not 
implemented by the binary. The binary supports a `tui` command which is 
not described in the manpage.

Best regards,
Martin

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

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

Versions of packages toot depends on:
ii  python3   3.11.2-1
ii  python3-bs4   4.11.2-2
ii  python3-requests  2.28.1+dfsg-1
ii  python3-urwid 2.1.2-4+b1
ii  python3-wcwidth   0.2.5+dfsg1-1.1

toot recommends no packages.

toot suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1007926: opendmarc: backport opendmarc-1.4.2

[David Bürgin]

I’ve proposed a stable update in #1033591.

Bug#1033408: apache2: Segmentation fault + 503 on frontpage on 2.4.56-1

[Fabien LE BERRE]

 Hi,

Sorry for the delay, as it is a production server I won't be allowed to
compile a new apache2 with the patch.
FYI, I now have a second server (production too unfortunately) with the
same issue. Rollbacked on 2.4.54 as well to solve the segfaults.
I didn't try this workaround, but I guess disabling mod_http2 would "solve"
the issue as well ?


Le ven. 24 mars 2023 à 20:55, Salvatore Bonaccorso  a
écrit :

> Hi,
>
> On Fri, Mar 24, 2023 at 05:17:34PM +0100, Fabien LE BERRE wrote:
> > Yes it does look like the bug. The Backtrace looks a lot like the
> coredump
> > I've seen.
> > Thanks for the heads up. Looking forward for the patch to be applied
> > officially.
>
> Would you be able to have additionally test the patch on your case to
> confirm? That would be great and helpful for releasing the regression
> update.
>
> Regards,
> Salvatore
>


-- 
*Fabien Le Berre** Homme de la situation*
01 86 95 54 04 - 37 rue des Mathurins - 75008 Paris

Le ven. 24 mars 2023 à 20:55, Salvatore Bonaccorso  a
écrit :

> Hi,
>
> On Fri, Mar 24, 2023 at 05:17:34PM +0100, Fabien LE BERRE wrote:
> > Yes it does look like the bug. The Backtrace looks a lot like the
> coredump
> > I've seen.
> > Thanks for the heads up. Looking forward for the patch to be applied
> > officially.
>
> Would you be able to have additionally test the patch on your case to
> confirm? That would be great and helpful for releasing the regression
> update.
>
> Regards,
> Salvatore
>


-- 
*Fabien Le Berre** Homme de la situation*
01 86 95 54 04 - 37 rue des Mathurins - 75008 Paris

Bug#1033605: ITP: sphinxcontrib-jquery -- extension to include jQuery on newer Sphinx releases

[Dmitry Shachnev]

Package: wnpp
Severity: wishlist
Owner: Dmitry Shachnev 

* Package name: sphinxcontrib-jquery
  Version : 4.1
  Upstream Contact: Adam Turner
* URL : https://github.com/sphinx-contrib/jquery
* License : 0BSD
  Programming Lang: Python
  Description : extension to include jQuery on newer Sphinx releases

sphinxcontrib-jquery ensures that jQuery is always installed for use in
Sphinx themes or extensions.

To use it, add sphinxcontrib.jquery as a Sphinx extension.

I am going to maintain this package under the Debian Python Team umbrella.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1033604: runc_1.0.0~rc6+dfsg1-3+deb10u2_amd64.deb: Built-Using refers to non-existing source package

[Sylvain Beucler]

Package: ftp.debian.org
X-Debbugs-Cc: b...@beuc.net
Severity: important

Hi,

(This was reported on #debian-ftp yesterday, submitting a bug report so it's 
not missed :))

All the 'any' parts of my 'runc' buster-lts update has been stuck at the 
"Uploaded" (not "Installed") stage for a day:
https://buildd.debian.org/status/package.php?suite=buster-security=runc

According to carnil, the error is:
runc_1.0.0~rc6+dfsg1-3+deb10u2_amd64.deb: Built-Using refers to non-existing 
source package golang-github-mrunalp-fileutils (= 0.0~git20160930.0.4ee1cc9-1)  
  

AFAICT we're missing these at security.debian.org/pool/:
- golang-github-mrunalp-fileutils (= 0.0~git20160930.0.4ee1cc9-1)
- golang-github-urfave-cli (= 1.20.0-1) 

Could an ftp-master inject these dependencies and re-process the .changes?

Cheers!
Sylvain Beucler
Debian LTS Team

Bug#1033170: libitext-rups-java: Does not work at all

[Emmanuel Bourg]

Le 2023-03-28 05:28, tony mancill a écrit :


The upload is ready.  Any concerns?

$ reverse-depends libitext-rups-java
No reverse dependencies found

$ reverse-depends -b libitext-rups-java
No reverse dependencies found


+1 for removing libitext-rups-java, and maybe libitext-rtf-java too.

Bug#1033600: emacs: File mode specification error: (file-missing Cannot open load file Aucun fichier ou dossier de ce type pylint)

[PICCA Frederic-Emmanuel]

If I remove the pylint package, no more error...

Bug#1033603: apt: Unattended-upgrades runs on shutdown while APT::Periodic::Unattended-Upgrade is not defined

[Yvan]

Package: apt
Version: 2.6.0
Severity: normal
X-Debbugs-Cc: y...@masson-informatique.fr

Dear Maintainers,

On a Debian bookworm system, I have the following configuration file for
unattended-upgrades:

Unattended-Upgrade::Origins-Pattern {
"origin=Debian,codename=${distro_codename},label=Debian-Security";

"origin=Debian,codename=${distro_codename}-security,label=Debian-Security";
}
Unattended-Upgrade::InstallOnShutdown "true";

Also, the setting `APT::Periodic::Unattended-Upgrade` is not defined in apt
(see apt-config dump below).

According to `/usr/share/doc/unattended-upgrades/README.md.gz` and to default
values in `/usr/lib/apt/apt.systemd.daily`, unattended-upgrades should not run.
However, unattended-upgrades runs on every shutdown on my system, so I believe
there is either a bug or an error in the documentation.

Regards,
Yvan

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "tasks";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/swcatalog -a 
-e /usr/bin/appstreamcli; then appstreamcli refresh --source=os > /dev/null || 
true; fi";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "zstd";
APT::Compressor::zstd::Cost "60";
APT::Compressor::zstd::CompressArg "";
APT::Compressor::zstd::CompressArg:: "-19";
APT::Compressor::zstd::UncompressArg "";
APT::Compressor::zstd::UncompressArg:: "-d";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "xz";
APT::Compressor::lzma::Cost "400";
APT::Compressor::lzma::CompressArg "";
APT::Compressor::lzma::CompressArg:: "--format=lzma";
APT::Compressor::lzma::CompressArg:: "-6";
APT::Compressor::lzma::UncompressArg "";
APT::Compressor::lzma::UncompressArg:: "--format=lzma";
APT::Compressor::lzma::UncompressArg:: "-d";
Dir "/";
Dir::State "var/lib/apt";
Dir::State::lists "lists/";
Dir::State::cdroms "cdroms.list";
Dir::State::extended_states "extended_states";
Dir::State::status "/var/lib/dpkg/status";
Dir::Cache "var/cache/apt";
Dir::Cache::archives "archives/";
Dir::Cache::srcpkgcache "srcpkgcache.bin";
Dir::Cache::pkgcache 

Bug#1033602: nvidia-graphics-drivers: dh_missing finds missing files and I think it is my fault

[Renato Gallo]

Source: nvidia-graphics-drivers
Version: 530.41.03
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

I am trying to debuild nvidia-graphics drivers 530.41.03 (since I would 
love to test the new 6.3.x kernels and I have read that the new version 
supports those,
I'd love to see if it is true)
I tried to follow the README.sources included in the git
Since I could not find the instruction to debuild the code I tried to 
use debuild -us -uc as usual
Sadly at the end of the process dh_missing finds missing files (I'd 
like to know how those can be included in the build)
The outcome I am expecting is to have the 530.41.03 dkms, bins, libs, 
debs ... etc, so I can test 
I am mainly blaming myself, and I would be grateful if you can give me 
a hint about what am I missing.

Thanks in advance for your time and effort.


p.s.

queue the boring error log

make[2]: Leaving directory '/usr/src/nvidia/nvidia-graphics-drivers'
   dh_lintian
   dh_perl
   dh_link
   dh_compress
   dh_fixperms
   dh_missing
dh_missing: warning: kernel-open/Kbuild exists in debian/tmp but is not 
installed to anywhere (related file: "debian/tmp/kernel/Kbuild")
dh_missing: warning: kernel-open/Makefile exists in debian/tmp but is not 
installed to anywhere (related file: "debian/tmp/kernel/Makefile")
dh_missing: warning: kernel-open/common/inc/conftest.h exists in debian/tmp but 
is not installed to anywhere 
dh_missing: warning: kernel-open/common/inc/cpuopsys.h exists in debian/tmp but 
is not installed to anywhere 
dh_missing: warning: kernel-open/common/inc/nv-caps.h exists in debian/tmp but 
is not installed to anywhere 
dh_missing: warning: kernel-open/common/inc/nv-dmabuf.h exists in debian/tmp 
but is not installed to anywhere 
dh_missing: warning: kernel-open/common/inc/nv-firmware.h exists in debian/tmp 
but is not installed to anywhere 
dh_missing: warning: kernel-open/common/inc/nv-gpu-info.h exists in debian/tmp 
but is not installed to anywhere 
dh_missing: warning: kernel-open/common/inc/nv-hash.h exists in debian/tmp but 
is not installed to anywhere 
dh_missing: warning: kernel-open/common/inc/nv-hypervisor.h exists in 
debian/tmp but is not installed to anywhere 
dh_missing: warning: kernel-open/common/inc/nv-ioctl-numa.h exists in 
debian/tmp but is not installed to anywhere 
dh_missing: warning: kernel-open/common/inc/nv-ioctl-numbers.h exists in 
debian/tmp but is not installed to anywhere 
dh_missing: warning: kernel-open/common/inc/nv-ioctl.h exists in debian/tmp but 
is not installed to anywhere 
dh_missing: warning: kernel-open/common/inc/nv-kernel-interface-api.h exists in 
debian/tmp but is not installed to anywhere 
dh_missing: warning: kernel-open/common/inc/nv-kref.h exists in debian/tmp but 
is not installed to anywhere 
dh_missing: warning: kernel-open/common/inc/nv-kthread-q.h exists in debian/tmp 
but is not installed to anywhere 
dh_missing: warning: kernel-open/common/inc/nv-linux.h exists in debian/tmp but 
is not installed to anywhere 
dh_missing: warning: kernel-open/common/inc/nv-list-helpers.h exists in 
debian/tmp but is not installed to anywhere 
dh_missing: warning: kernel-open/common/inc/nv-lock.h exists in debian/tmp but 
is not installed to anywhere 
dh_missing: warning: kernel-open/common/inc/nv-memdbg.h exists in debian/tmp 
but is not installed to anywhere 
dh_missing: warning: kernel-open/common/inc/nv-mm.h exists in debian/tmp but is 
not installed to anywhere 
dh_missing: warning: kernel-open/common/inc/nv-modeset-interface.h exists in 
debian/tmp but is not installed to anywhere 
dh_missing: warning: kernel-open/common/inc/nv-msi.h exists in debian/tmp but 
is not installed to anywhere 
dh_missing: warning: kernel-open/common/inc/nv-pci-types.h exists in debian/tmp 
but is not installed to anywhere 
dh_missing: warning: kernel-open/common/inc/nv-pci.h exists in debian/tmp but 
is not installed to anywhere 
dh_missing: warning: kernel-open/common/inc/nv-pgprot.h exists in debian/tmp 
but is not installed to anywhere 
dh_missing: warning: kernel-open/common/inc/nv-procfs-utils.h exists in 
debian/tmp but is not installed to anywhere 
dh_missing: warning: kernel-open/common/inc/nv-procfs.h exists in debian/tmp 
but is not installed to anywhere 
dh_missing: warning: kernel-open/common/inc/nv-proto.h exists in debian/tmp but 
is not installed to anywhere 
dh_missing: warning: kernel-open/common/inc/nv-register-module.h exists in 
debian/tmp but is not installed to anywhere 
dh_missing: warning: kernel-open/common/inc/nv-retpoline.h exists in debian/tmp 
but is not installed to anywhere 
dh_missing: warning: kernel-open/common/inc/nv-time.h exists in debian/tmp but 
is not installed to anywhere 
dh_missing: warning: kernel-open/common/inc/nv-timer.h exists in debian/tmp but 
is not installed to anywhere 
dh_missing: warning: kernel-open/common/inc/nv.h exists 

Bug#1033600: emacs: File mode specification error: (file-missing Cannot open load file Aucun fichier ou dossier de ce type pylint)

[Picca Frédéric-Emmanuel]

Package: emacs
Version: 1:28.2+1-13
Severity: normal

Dear Maintainer,

Hello, When I edit a python file and start emacs without .emacs file like this
I get this error message in the console.

Loading /etc/emacs/site-start.d/50pylint.el (source)...done
Loading /etc/emacs/site-start.d/50pymacs.el (source)...done
Loading /etc/emacs/site-start.d/50texlive-lang-english.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.
File mode specification error: (file-missing Cannot open load file Aucun 
fichier ou dossier de ce type pylint)
mouse-minibuffer-check: Minibuffer window is not active
Mark set [3 times]

This is not such an issue during an interractive session, but... I use this in 
the hkl package, and it cause an FTBFS like this

make[1] : on entre dans le répertoire « 
/home/picca/src/repo.or.cz/hkl/Documentation »
env GI_TYPELIB_PATH=../hkl \
/bin/bash ../libtool --mode=execute -dlopen ../hkl/libhkl.la \
/usr/bin/emacs hkl.org --batch -q --load ./hkl-default.el -f 
org-html-export-to-html --debug-init --kill
Loading /etc/emacs/site-start.d/00debian.el (source)...
Loading /etc/emacs/site-start.d/20apel.el (source)...
Loading /etc/emacs/site-start.d/50asymptote.el (source)...
Loading /etc/emacs/site-start.d/50autoconf.el (source)...
Loading /etc/emacs/site-start.d/50devhelp.el (source)...
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...
Loading debian-ispell (native compiled elisp)...
Loading /var/cache/dictionaries-common/emacsen-ispell-default.el (source)...
Loading /var/cache/dictionaries-common/emacsen-ispell-dicts.el (source)...
Loading /etc/emacs/site-start.d/50emacs-goodies-el.el (source)...
Package emacs-goodies-el removed but not purged.  Skipping setup.
Loading /etc/emacs/site-start.d/50gtk-doc-tools.el (source)...
Loading /etc/emacs/site-start.d/50haskell-mode.el (source)...
Loading 
/usr/share/emacs/site-lisp/elpa/haskell-mode-17.2snapshot/haskell-mode-autoloads.el
 (source)...
Loading /etc/emacs/site-start.d/50latex-cjk-common.el (source)...
Loading /usr/share/emacs/site-lisp/latex-cjk-common/cjk-enc.el (source)...
Loading /etc/emacs/site-start.d/50latex-cjk-thai.el (source)...
Loading /etc/emacs/site-start.d/50latexmk.el (source)...
Loading /etc/emacs/site-start.d/50lilypond-data.el (source)...
Loading /etc/emacs/site-start.d/50mu4e.el (source)...
Loading /etc/emacs/site-start.d/50pylint.el (source)...
Loading /etc/emacs/site-start.d/50pymacs.el (source)...
Loading /etc/emacs/site-start.d/50texlive-lang-english.el (source)...
executing Python code block...
Can’t guess python-indent-offset, using defaults: 4
Debugger entered--Lisp error: (file-missing "Cannot open load file" "Aucun 
fichier ou dossier de ce type" "pylint")
  pylint-add-key-bindings()
  run-hooks(change-major-mode-after-body-hook prog-mode-hook python-mode-hook)
  apply(run-hooks (change-major-mode-after-body-hook prog-mode-hook 
python-mode-hook))
  run-mode-hooks(python-mode-hook)
  python-mode()
  org-babel-python--shift-right("from gi.repository import Hkl\n\ndef 
bold(l):\nre...")
  org-babel-python-evaluate-external-process("from gi.repository import 
Hkl\n\ndef bold(l):\nre..." value ("raw" "value" "replace") nil)
  org-babel-python-evaluate(nil "from gi.repository import Hkl\n\ndef 
bold(l):\nre..." value ("raw" "value" "replace") nil nil)
  org-babel-execute:python("from gi.repository import Hkl\n\ndef bold(l):\n
re..." ((:colname-names) (:rowname-names) (:result-params "raw" "value" 
"replace") (:result-type . value) (:results . "raw value replace") (:exports . 
"results") (:cache . "no") (:hlines . "no") (:noweb . "no") (:session . "none") 
(:tangle . "no")))
  org-babel-execute-src-block(nil ("python" "from gi.repository import 
Hkl\n\ndef bold(l):\nre..." ((:colname-names) (:rowname-names) 
(:result-params "replace" "value" "raw") (:result-type . value) (:results . 
"replace value raw") (:exports . "results") (:tangle . "no") (:session . 
"none") (:noweb . "no") (:hlines . "no") (:cache . "no")) "" nil 16691 
"(ref:%s)"))
  org-babel-exp-results(("python" "from gi.repository import Hkl\n\ndef 
bold(l):\nre..." ((:cache . "no") (:colname-names) (:exports . "results") 
(:hlines . "no") (:noweb . "no") (:result-params "replace" "value" "raw") 
(:result-type . value) (:results . "replace value raw") (:rowname-names) 
(:session . "none") (:tangle . "no")) "" nil 16691 "(ref:%s)") block nil 
"c5e8d8dd74aadb2dbc5bed5e85740a69d84c7b38")
  org-babel-exp-do-export(("python" "from gi.repository import Hkl\n\ndef 
bold(l):\nre..." ((:cache . "no") (:colname-names) (:exports . "results") 
(:hlines . "no") (:noweb . "no") (:result-params "replace" "value" "raw") 
(:result-type . value) (:results . "replace value raw") (:rowname-names) 
(:session . "none") (:tangle . "no")) "" nil 16691 "(ref:%s)") block 
"c5e8d8dd74aadb2dbc5bed5e85740a69d84c7b38")
  org-babel-exp-src-block()
  org-babel-exp-process-buffer()
  org-export-as(html nil nil nil 

Bug#1033601: RFP: nelson -- Let's Nelson! matrix language for engineering and scientific applications

[Allan CORNET]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: nelson.numerical.computat...@gmail.com

* Package name: nelson
  Version : 0.7.3
  Upstream Author : Allan CORNET 
* URL : https://nelson-numerical-software.github.io/nelson-website/
* License : GPL
  Programming Lang: C, C++
  Description : Let's Nelson! matrix language for engineering and
scientific applications

Nelson is an matrix/array programming language providing a powerful open
computing environment for engineering and scientific applications using modern
C/C++ libraries (Boost, Eigen, …) and others state of art numerical libraries.
It has sophisticated data structures (including cell, struct, linear systems,
…), an interpreter and a high level programming language. Nelson has been
developed to be an open/modular system where an user can define these own data
types and operations on these data types by using overload. Syntax is very
similar to GNU Octave or MATLAB® so that most programs are easily portable.


 - how do you plan to maintain it? Yes

Bug#1029681: nvidia-legacy-340xx-driver: Qt5 apps fail to launch with a segfault

[jim_p]

Package: nvidia-legacy-340xx-driver
Version: 340.108-18
Followup-For: Bug #1029681
X-Debbugs-Cc: pitsior...@outlook.com

I contacted an arch user who still uses nvidia 340 from aur and, as he mentions
in the comments, there is no issue with qt5 apps and nvidia 340 there.
I do not know how arch builds qt5, or if it builds the -gles variant, but I
think someone with the relevant knowledge should check the patches there in
case they patch something differently.

In other news, gtk4 will bring more gl related issues as it seems. Pictured is
blackbox-terminal, a gtk4 app and that huge black rectangle around the menu is,
supposedly, where its shadow would be. Launching it from a terminal pops these
errors

$ blackbox-terminal
Gsk-Message: 11:43:02.022: Failed to realize renderer of type 'GskGLRenderer'
for surface 'GdkX11Toplevel': Compilation failure in shader.
Source Code:   1| #version 100

(140+ lines of source code here)

Error Message:
0(30) : error C7551: OpenGL first class arrays require #version 120
0(43) : error C7551: OpenGL first class arrays require #version 120
0(120) : error C7551: OpenGL first class arrays require #version 120


-- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages nvidia-legacy-340xx-driver depends on:
ii  nvidia-installer-cleanup 20220217+2
ii  nvidia-legacy-340xx-alternative  340.108-18
ii  nvidia-legacy-340xx-driver-bin   340.108-18
ii  nvidia-legacy-340xx-driver-libs  340.108-18
ii  nvidia-legacy-340xx-kernel-dkms [nvidia-legacy-340xx-kernel-340  340.108-18
.108]
ii  nvidia-legacy-340xx-vdpau-driver 340.108-18
ii  nvidia-support   20220217+2
ii  xserver-xorg-video-nvidia-legacy-340xx   340.108-18

Versions of packages nvidia-legacy-340xx-driver recommends:
pn  nvidia-persistenced   
ii  nvidia-settings-legacy-340xx  340.108-7

Versions of packages nvidia-legacy-340xx-driver suggests:
ii  nvidia-legacy-340xx-kernel-dkms  340.108-18

Versions of packages nvidia-legacy-340xx-driver-libs:amd64 depends on:
ii  libegl1-nvidia-legacy-340xx 340.108-18
ii  libgl1-nvidia-legacy-340xx-glx  340.108-18

Versions of packages nvidia-legacy-340xx-driver-libs:amd64 recommends:
ii  libgles1-nvidia-legacy-340xx  340.108-18
ii  libgles2-nvidia-legacy-340xx  340.108-18
pn  libnvidia-legacy-340xx-cfg1   
pn  libnvidia-legacy-340xx-encode1
pn  nvidia-legacy-340xx-driver-libs-i386  

Versions of packages libgl1-nvidia-legacy-340xx-glx:amd64 depends on:
ii  libc62.36-8
ii  libnvidia-legacy-340xx-glcore340.108-18
ii  libx11-6 2:1.8.4-2
ii  libxext6 2:1.3.4-1+b1
ii  nvidia-installer-cleanup 20220217+2
ii  nvidia-legacy-340xx-alternative  340.108-18
ii  nvidia-support   20220217+2

Versions of packages libgl1-nvidia-legacy-340xx-glx:amd64 recommends:
ii  nvidia-legacy-340xx-kernel-dkms [nvidia-legacy-340xx-kernel-340  340.108-18
.108]

Versions of packages libgl1-nvidia-legacy-340xx-glx:amd64 suggests:
ii  nvidia-legacy-340xx-kernel-dkms  340.108-18

Versions of packages xserver-xorg-video-nvidia-legacy-340xx depends on:
ii  libc6  2.36-8
ii  libnvidia-legacy-340xx-glcore  340.108-18
ii  nvidia-installer-cleanup   20220217+2
ii  nvidia-legacy-340xx-alternative340.108-18
ii  nvidia-support 20220217+2
ii  xserver-xorg-core [xorg-video-abi-25]  2:21.1.7-1

Versions of packages xserver-xorg-video-nvidia-legacy-340xx recommends:
ii  nvidia-legacy-340xx-kernel-dkms [nvidia-legacy-340xx-kernel-340  340.108-18
.108]
ii  nvidia-legacy-340xx-vdpau-driver 340.108-18
ii  nvidia-settings-legacy-340xx 340.108-7

Versions of packages xserver-xorg-video-nvidia-legacy-340xx suggests:
ii  nvidia-legacy-340xx-kernel-dkms  340.108-18

Versions of packages nvidia-legacy-340xx-alternative depends on:
ii  dpkg1.21.21
ii  glx-alternative-nvidia  1.2.2

Versions of packages nvidia-legacy-340xx-kernel-dkms depends on:
ii  dkms 3.0.10-6
ii  nvidia-installer-cleanup 20220217+2
ii  nvidia-legacy-340xx-kernel-support 

Bug#1033588: Info received (Bug#1033588: (bash-completion: unquoted tilde in _quote_readline_by_ref causes NSS lookups))

[Łukasz Stelmach]

Control: tags -1 +patch

Bug#1033588: (bash-completion: unquoted tilde in _quote_readline_by_ref causes NSS lookups)

[Łukasz Stelmach]

Control: -1 +patch

Bug#1031593: deluge-web: gettext error

[Daniel Baumann]

On 3/28/23 08:56, nb wrote:
> when will 2.1.1 version be available?

it's in experimental as testing/unstable is frozen.
I'll upload to unstable once bookworm is released.

Regards,
Daniel