Bug#1003715: tigervnc-standalone-server: Typo in tigervncserver.1.gz

[Tim Phipps]

Package: tigervnc-standalone-server
Version: 1.11.0+dfsg-2
Severity: minor

Dear Maintainer,
Here is the first line of the tigervncserver man page:

   tigervncserver - start or stop a TigerVNC standaloe server

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

Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CPU_OUT_OF_SPEC, 
TAINT_WARN, 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)

-- Configuration Files:
/etc/tigervnc/vncserver.users changed [not included]

-- no debconf information

Bug#987276: [PATCH] Fix integer overflow in num_images

[Mathieu Malaterre]

Control: tags -1 patch fixed-upstream

https://github.com/uclouvain/openjpeg/commit/f0727df07c4d944d7d1c5002451cfbc9545d3288.patch

Bug#1003714: ITP: oci-cli -- Command Line Interface for Oracle Cloud Infrastructure

[Paul Wise]

Package: wnpp
Severity: wishlist
Owner: Paul Wise 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-cl...@lists.debian.org
Control: block -1 by 1003372

* Package name: oci-cli
  Version : 3.4.1
  Upstream Author : Mike Ross and others at Oracle
* URL : 
https://docs.cloud.oracle.com/Content/API/Concepts/cliconcepts.htm
* License : Universal Permissive License or Apache
  Programming Lang: Python
  Description : Command Line Interface for Oracle Cloud Infrastructure

This package is needed by my employer for managing their OCI instances.

I plan to maintain it within the Debian Cloud Team after joining it.

It depends on oci-python-sdk, which I also intend to package (#1003372).

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1002166: sdrangelove: FTBFS: gnuradiothread.cpp:139:23: error: no matching function for call to ‘gr::top_block::connect(osmosdr::source::sptr&, int, gr_adaptor_sptr&, int)’

[tony mancill]

On Tue, Jan 11, 2022 at 12:55:16PM +0100, Christoph Berg wrote:
> Re: Lucas Nussbaum
> > Source: sdrangelove
> > Version: 0.0.1.20150707-5
> > Severity: serious
> > Justification: FTBFS
> > Tags: bookworm sid ftbfs
> > User: lu...@debian.org
> > Usertags: ftbfs-20211220 ftbfs-bookworm
> > 
> > Hi,
> > 
> > During a rebuild of all packages in sid, your package failed to build
> > on amd64.
> 
> sdrangelove hasn't really been touched upstream since 2015 (except 3
> more or less boring git commits), so I propose we remove it.

Sounds like a reasonable goal for bookworm.

> (... and I should finally get around to upload sdrangel.)

https://github.com/f4exb/sdrangel looks to be quite active.

Thank you for your packaging work,
tony

Bug#1003712: bluez: CVE-2022-0204: Heap overflow vulnerability in the implementation of the gatt protocol

[Salvatore Bonaccorso]

Source: bluez
Version: 5.62-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for bluez.

CVE-2022-0204[0]:
| Heap overflow vulnerability in the implementation of the gatt
| protocol

Seems fixed with [2].

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-0204
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0204
[1] https://github.com/bluez/bluez/security/advisories/GHSA-479m-xcq5-9g2q
[2] 
https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=591c546c536b42bef696d027f64aa22434f8c3f0

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1003469: ceph: FTBFS with fmtlib/8.1.1

[Shengjing Zhu]

Control: tags -1 patch

Please see the patch in attachment.

Thanks.
Description: Fix build with fmtlib 8.1.1
 + changes in segment_manager.cc and segment_manager.h are backported from
   part of the large changes in https://github.com/ceph/ceph/commit/d5b0cd13
 + change in node_extent_accessor.h is not forwarded to upstream since it's
   a workaround. However it doesn't harm since it's just a error message
   which shouldn't happen anyway.
Author: Shengjing Zhu 
Bug: https://tracker.ceph.com/issues/53820
Bug-Debian: https://bugs.debian.org/1003469
Forwarded: no
Last-Update: 2022-01-14
---
--- a/src/crimson/os/seastore/CMakeLists.txt
+++ b/src/crimson/os/seastore/CMakeLists.txt
@@ -1,6 +1,7 @@
 add_library(crimson-seastore STATIC
   cached_extent.cc
   seastore_types.cc
+  segment_manager.cc
   segment_manager/ephemeral.cc
   segment_manager/block.cc
   transaction_manager.cc
--- a/src/crimson/os/seastore/onode_manager/staged-fltree/node_extent_accessor.h
+++ b/src/crimson/os/seastore/onode_manager/staged-fltree/node_extent_accessor.h
@@ -169,7 +169,7 @@
   }
   default:
 logger().error("OTree::Extent::Replay: got unknown op {} when replay {:#x}",
-   op, node.get_laddr());
+   static_cast(op), node.get_laddr());
 ceph_abort();
   }
 } catch (buffer::error& e) {
--- /dev/null
+++ b/src/crimson/os/seastore/segment_manager.cc
@@ -0,0 +1,19 @@
+#include "crimson/os/seastore/segment_manager.h"
+
+namespace crimson::os::seastore {
+
+  std::ostream& operator<<(std::ostream &out, Segment::segment_state_t s)
+  {
+using state_t = Segment::segment_state_t;
+switch (s) {
+  case state_t::EMPTY:
+return out << "EMPTY";
+  case state_t::OPEN:
+return out << "OPEN";
+  case state_t::CLOSED:
+return out << "CLOSED";
+  default:
+return out << "INVALID_SEGMENT_STATE!";
+}
+  }
+}
--- a/src/crimson/os/seastore/segment_manager.h
+++ b/src/crimson/os/seastore/segment_manager.h
@@ -73,6 +73,9 @@
 
   virtual ~Segment() {}
 };
+
+std::ostream& operator<<(std::ostream& out, Segment::segment_state_t);
+
 using SegmentRef = boost::intrusive_ptr;
 
 constexpr size_t PADDR_SIZE = sizeof(paddr_t);

Bug#1003711: autojump: Error if /bin/sh is linked to /bin/dash

[Jon Daley]

Package: autojump
Version: 22.5.1-1.1
Severity: normal

Dear Maintainer,

I'm trying to use autojump for the first time, and I use tcsh.  I added 
source ... to my .tcshrc file.

I get "BASH: Undefined variable." Looking at the script, I see that it 
says "it might cause problems if /bin/sh is linked to /bin/bash, and I 
assume a similar problem is for dash as well.  I think dash is the 
default now?  I vaguely remember that prompt to switch to dash a number 
of years back, but I haven't seen any problems in a long time.

Though, looking into it further, it appears the Debian version doesn't 
include the autojump.tcsh (and some others) that upstream has?  The 
package description claims to enhance tcsh, so probably the description 
should be changed or the file included.


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

Kernel: Linux 5.10.0-10-amd64 (SMP w/8 CPU threads)
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 autojump depends on:
ii  python3  3.9.2-3

autojump recommends no packages.

autojump suggests no packages.

-- no debconf information

Bug#1002617: RFS: carl9170fw/1.9.9-399-gcd480b9-1 [ITP] -- firmware for AR9170 USB wireless adapters

[Paul Wise]

On Thu, 2022-01-13 at 20:54 +, John Scott wrote:

> You might like to have a look at this mail from Ben Hutchings:
> https://lists.debian.org/msgid-search/179d6d32466dd13962a3aab251c45242fbf2d8ae.ca...@decadent.org.uk
> The reason that none of the other Wi-Fi firmware packages have them is
> because they're all non-free (with the exception of ath9k_htc).

Thanks for the link, I'm not subscribed to that list. Makes sense.

> I wasn't sure if there was any established convention; my thread "Naming
> convention for udebs: -udeb/-installer suffix" didn't garner any
> pertinent responses. I've switched the name though.

I did a search of a Debian mirror filesystem and found that only the
linux and linux-signed-* source packages use the -di suffix, most use
the -udeb suffix. The -installer suffix seems to be used only for udeb
packages when the source package has the -installer suffix too, such as
bootloader installers like grub-installer, with a few exceptions for
other udebs that install things. I suggest using the -udeb suffix.

> These are all good catches, I'm working on incorporating them and doing
> a slow and careful review.

Recently on another project I noticed an upstream commit that added
copyright information in the middle of a file alongside the functions
that were copied from elsewhere. This sort of thing is hard to notice
during the manual review of file headers I usually do using mc (after
enabling the preview pane and arrow keys for navigation), but some of
the copyright review tools might be helpful. I actually detected the
list.h LGPL license using debmake -k (as run by check-all-the-things).
Apparently the best option is ScanCode but that isn't in Debian yet.

https://wiki.debian.org/CopyrightReviewTools

> I think you're mistaken here, you should take a look at
> /usr/share/dpkg/buildopts.mk which I include via an include directive in
> debian/rules. Basically, DEB_BUILD_OPTION_PARALLEL is a helper macro for
> the value of parallel from DEB_BUILD_OPTIONS; these are one and the
> same.

I see, I wasn't aware of this snippet/variable.

> That's true. My intent was that, since it's a hidden directory, it would
> help remind one that that directory gets created. It seems to've only
> caused confusion, so I'll pull it.

That seems reasonable if you want to keep it. Maybe add a comment.

> Indeed, the documentation is rather old and terse and doesn't address
> this issue. I'll probably ask the Reportbug folks and send them a MR
> updating the docs.

Great.

> > Please ask upstream to make a new release, it has been a very long time
> > since the last one.
> I will do after making some of the following important changes.

Thanks.

> > Please ask upstream to send FindUSB-1.0.cmake & libusb-zeropacket.diff
> > to libusb upstream and then remove them from carl9170fw.
> I will ask, but with all due respect, I think this is lower priority and
> that I'll have limited ability to help them.

Sure. TBH they don't appear to be used by carl9170fw so I'm not sure
why they are in the source repository at all.

> I do not have a grasp, let alone a good one, of CMake, so this may be a
> challenge.

The documentation for CMake is fairly comprehensive, until recently I
had never touched CMake and didn't understand it but when I needed to
figure it out I found it to be reasonable and well documented.

> I actually think I'll do one better: I submitted upstream an AppStream
> metadata file a while ago, and although they haven't responded to it
> yet, perhaps my sending them other changes will get their attention.
> AppStream metadata and Debian upstream metadata files have considerable
> overlap, and in my personal opinion having good AppStream metadata makes
> an upstream metadata file unnecessary, but I'm willing to entertain
> arguments to the contrary.

I haven't looked at AppStream but I got the feeling they had different
audiences or purposes or tools looking at them.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1003710: stardict crash in gnome with message Segmentation fault

[Quanlin Jie]

Package: stardict
Version: 3.0.7+git20211225+dfsg-1
Severity: normal
X-Debbugs-Cc: ql...@whu.edu.cn

Dear Maintainer,

stardict does not start in gnome wayland. Every time I start it, I 
crashes with
a message "Segmentation fault". However, I does start in gnome for xorg. 
But it


crashes when scan option is turned on with the same "Segmentation fault" 
message. This is true for every user.



It works well when I log in as another user both in wayland and xorg, 
i.e., another user logs into my gnome environment , or I log into 
other's desktop environment, to start stardict.


*** 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 ***


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

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

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

Versions of packages stardict depends on:
ii stardict-gtk 3.0.7+git20211225+dfsg-1

stardict recommends no packages.

stardict suggests no packages.

-- no debconf information

Bug#1003709: ITP: libclass-tiny-antlers-perl -- Moose-like sugar for Class::Tiny

[Torrance, Douglas]

Package: wnpp
Severity: wishlist
Owner: Doug Torrance 
X-Debbugs-Cc: debian-de...@lists.debian.org, dtorra...@piedmont.edu

* Package name: libclass-tiny-antlers-perl
 Version : 0.024
 Upstream Author : Toby Inkster 
* URL : https://metacpan.org/release/Class-Tiny-Antlers
* License : GPL/Artistic
 Programming Lang: Perl
 Description : Moose-like sugar for Class::Tiny

Class::Tiny::Antlers provides Moose-like has, extends, with, before, after
and around keywords for Class::Tiny. (The with keyword requires Role::Tiny;
method modifiers require Class::Method::Modifiers.)

Class::Tiny doesn't support all Moose's attribute options; has should throw
you an error if you try to do something it doesn't support (like triggers).

Class::Tiny::Antlers does however hack in support for is => 'ro' and
Moo-style is => 'rwp', clearers and predicates.


From version 0.24, Class::Tiny::Antlers also adds support for `isa` and

`coerce` using Type::Tiny. (I mean, this is a TOBYINK module, so what do you
expect?!) Technically MooseX::Types, MouseX::Types, Specio, and Type::Nano
should work, but these are less tested.

I intend to maintain this package under the umbrella of the Debian Perl Team.


signature.asc
Description: PGP signature

Bug#1003631: dlocate: update-dpkg-list can deadlock

[Aaron M. Ucko]

Craig Sanders  writes:

> On Wed, Jan 12, 2022 at 06:06:45PM -0500, Aaron M. Ucko wrote:
>> Long story short, update-dpkg-list's batched bidirectional pipe usage wound
>> up deadlocking on a system with 20,000+ provided virtual packages, mostly
>> from installed librust-*-dev packages.
>
> what do you mean by "deadlocking"? some kind of lockup, i presume. what
> exactly happens? roughly how long is the script running before it happens?

As confirmed by strace, each side of the pipe is blocking on a write
call that won't complete until the other side issues a read, because the
kernel's buffer for the pipe has filled up.

I am comfortable with Perl, and having taken another look at the code,
was able to resolve the deadlock by arranging to feed xargs from a
dedicated subprocess, per the attached patch.

Could you please consider applying it?

Thanks!

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

diff -u update-dpkg-list~ update-dpkg-list
--- update-dpkg-list~	2022-01-13 20:52:49.875888185 -0500
+++ update-dpkg-list	2022-01-13 21:41:42.053617442 -0500
@@ -4,6 +4,7 @@
 use warnings;
 use IPC::Open2;
 use File::Basename;
+use POSIX qw(:sys_wait_h);
 
 my $program = basename($0);
 
@@ -59,14 +60,20 @@
   # apt-cache doesn't read stdin, so we have to use xargs to make sure we
   # never exceed the bash command line limit.
   my $pid = open2(\*ACS, \*XARGS, 'xargs -0r apt-cache show');
+  my $pid2 = fork();
 
-  print XARGS join("\0",@unknown);
-  close(XARGS);
+  if ($pid2 == 0) {
+print XARGS join("\0",@unknown);
+exit(0);
+  } else {
+close(XARGS);
+  }
 
   while () {
 parse_pkg('ACS',$_);
   };
   close(ACS);
+  waitpid($pid2, WNOHANG);
 };
 
 my $dlist = '/var/lib/dlocate/dpkg-list';

Bug#1003634: texlive-latex-base: \fontseries broken: seems to be cumulative until {m} or so?

[Thorsten Glaser]

Hi Norbert,

>Debian at all, and should be brought to the respective channels (TL
>mailing list, LaTeX team tracker, IRC, ...).

thank you for forwarding it there then ☻

bye,
//mirabilos
-- 
  "Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
 -- Henry Nelson, March 1999

Bug#980974: I just spent hours dealing with this

[Paul Rubin]

My printer wouldn't work and I eventually found the aacomplain 
workaround in the ubuntu printer debugging docs:


https://wiki.ubuntu.com/DebuggingPrintingProblems#AppArmor_Protection_of_the_printing_system

It really should be fixed.  I looked at /etc/apparmor.d/cupsd and there 
is quite a lot of stuff in there about cups-pdf that looked confusing to 
mess with.  Aacomplain at least allowed me to print, so I would say if 
nobody has a fix then apparmor for cups should be disabled by default 
until a proper fix is worked out. Otherwise it's a big regression, 
suddenly becoming unable to print stuff.  It ended up causing me 
significant inconvenience because I needed the printout for something 
that I wanted to do today, that will now have to wait til tomorrow.  
Fortunately this wasn't last-minute tax forms or I'd be in trouble :(

Bug#1003406: RFS: simple-scan/40.7-1 -- Simple Scanning Utility

[Adam Borowski]

On Sun, Jan 09, 2022 at 06:49:08PM +0100, Jörg Frings-Fürst wrote:
>Package name: simple-scan
>Version : 40.7-1

>  simple-scan (40.7-1) unstable; urgency=medium
>  .
>* New upstream release.
>* debian/copyright:
>  - Add year 2022 to myself.
>* Declare compliance with Debian Policy 4.6.0.1 (No changes needed).
>* New .gitignore.

Hi!
It fails to build:

../data/meson.build:11:5: ERROR: Function does not take positional arguments.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ At least spammers get it right: "Hello beautiful!".
⠈⠳⣄

Bug#995137: Can not get current location with gpsd

[Takeshi Soejima]

If marble 4:20.12.3-1 (in bullseye) is rebuilt with libgps23 (in
buster), I can get current location with gpsd (in bullseye).

Bug#965829: sofia-sip: Removal of obsolete debhelper compat 5 and 6 in bookworm

[Jonas Smedegaard]

I have filed bug#1003706 to salvage sofia-sip.

@Evangelos: If that process is not canceled, I would be more than happy 
to have you as co-maintainer.


 - Jonas

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

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

signature.asc
Description: signature

Bug#1003631: dlocate: update-dpkg-list can deadlock

[Craig Sanders]

On Wed, Jan 12, 2022 at 06:06:45PM -0500, Aaron M. Ucko wrote:
> Long story short, update-dpkg-list's batched bidirectional pipe usage wound
> up deadlocking on a system with 20,000+ provided virtual packages, mostly
> from installed librust-*-dev packages.

what do you mean by "deadlocking"? some kind of lockup, i presume. what
exactly happens? roughly how long is the script running before it happens?


BTW, update-dpkg-list runs fine on my 32GB Phenom II 1090T with over 38,000
packages known (over 8700 installed) - most actual packages from debian's own
repos, not an enormous set of virtual pkgs.  It has been doing so since I
built it ~ 10 years ago.

# wc -l /var/lib/dlocate/dpkg-list
38886 /var/lib/dlocate/dpkg-list

# grep '^.i' /var/lib/dlocate/dpkg-list | wc -l
8784

> Could you please take a look?

more info would be useful. at what stage does it lock up? is any output
produced in /var/lib/dlocate/dpkg-list?  Do you get an email from cron?


The only thing I can think of right now, is maybe try editing
/usr/share/dlocate/update-dpkg-list and, on line 61, change:

xargs -0r apt-cache show

to limit xargs to running apt-cache with only 1000 or 5000 package names at a
time, e.g.:

xargs -0r -n 1000 apt-cache show


I don't really think it will make any difference, apart from slowing it down
a bit, but it's worth trying...just in case apt-cache can't handle so many
package names on one command line, or maybe it doesn't like so many virtual
packages.

Also try adding some print statements before and after each "section" of code
in the script (i.e. before each open() and after each close(), and before
and after each loop) to pinpoint which part of the script is failing on your
system.  Add '$|=1;' (without quotes) near the top of the script, before
any print statements, to ensure that STDOUT is unbuffered.

I'd do that myself, but there's not much point since it doesn't happen on any
of my systems.  If you're not comfortable making changes to perl code, I've
attached a version of update-dpkg-list with all these changes.


You'll have to do the next suggestion yourself:

Also worth trying is generating a list of your 20K+ package names and feeding
that into 'xargs apt-cache show'  from bash to test whether it's apt-cache or
perl's IPC::Open2.  update-dpkg-list script doesn't do anything unusual, it 
just runs
'apt-cache show' and collects its output into an array.

BTW, the package list doesn't really need to be NUL separated. Using newline
(option "-d '\n'" with xargs instead of `-0`) or even spaces (xargs default)
as the separator for package names is fine, as package names don't and can't
contain whitespace.

craig
#!/usr/bin/perl

use strict;
use warnings;
use IPC::Open2;
use File::Basename;

$|=1;

my $program = basename($0);

my %packages = ();

my $myarch = qx(dpkg --print-architecture);
chomp $myarch;

# pre-declare subroutines (see below for implementation)
use subs qw(parse_pkg);

print "Getting details from dpkg...\n";
# get details for all packages known by dpkg
open(DPKG,'-|','dpkg -l "*"');
while() {
  next unless (m/^[uihrp][ncHUFWti]/);
  chomp;

  my ($status,$pkg,$version,$arch,$desc) = split /\s+/,$_,5;
  $pkg =~ s/:.*//;

  $packages{"$pkg"}->{$arch}->{'status'} = sprintf('%-3s',$status);
  $packages{"$pkg"}->{$arch}->{'version'} = $version;
  $packages{$pkg}->{$arch}->{'desc'} = $desc;
}
close(DPKG);
print "done.\n";

# now get missing details for uninstalled packages
$/='';
my $pkgfiles='/var/lib/dpkg/status /var/lib/dpkg/available';
my $fields= join(',',qw(Package Description Architecture Version));

print "Getting missing details from grep-dctrl...\n";
open(DCTRL,'-|',"grep-dctrl -e . -s $fields $pkgfiles");
while() {
  parse_pkg('DCTRL',$_);
};
close(DCTRL);
print "done.\n";


# as a last ressort, try to get missing details from apt-cache show
# if arch or version is ''
my @unknown = ();
foreach my $pkg (keys %packages) {
  foreach my $arch (keys %{ $packages{$pkg} } ) {

push @unknown, $pkg if (
$arch eq ''
 || $packages{$pkg}->{$arch}->{'version'} eq ''
);
  };
};

print "Running xargs apt-cache show...\n";
if (@unknown) {
  # apt-cache doesn't read stdin, so we have to use xargs to make sure we
  # never exceed the bash command line limit.
  #my $pid = open2(\*ACS, \*XARGS, 'xargs -0r apt-cache show');
  my $pid = open2(\*ACS, \*XARGS, 'xargs -0r -n 1000 apt-cache show');

  print XARGS join("\0",@unknown);
  close(XARGS);

  while () {
parse_pkg('ACS',$_);
  };
  close(ACS);
};
print "done.\n";

my $dlist = '/var/lib/dlocate/dpkg-list';

print "Writing to $dlist...\n";
open(DPKGLIST,'>', "$dlist.new") or die "$program: couldn't open $dlist.new for 
write: $!\n";
foreach (sort keys %packages) {
  foreach my $arch (sort keys %{ $packages{$_} } ) {
next if ($arch eq '');
my $pkg = ($arch =~ m/^($myarch|all)$/io) ? $_ : "$_:$arch";

printf DPKGLIST "%s\t%s\t%s:%s\t%s\n",
#printf DPKGLIST "%s\t%s\t%s\t%s\t%s\n",
  $pac

Bug#1003708: units: Segmentation fault on certain conversions in verbose mode

[Owen T. Heisler]

Package: units
Version: 2.21-1
Severity: normal
X-Debbugs-Cc: wri...@owenh.net

Hi, the following commands result in a segmentation fault:

$ echo -e "cm\nbrwiregauge" | units -v
$ echo -e "cm\nplategauge" | units -v

This was discovered while attempting to use the script example in the
"SCRIPTING WITH UNITS" section of the units(1) man page.

Thank you for maintaining this useful tool.

Owen T. Heisler

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

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

Versions of packages units depends on:
ii  libc6 2.31-13+deb11u2
ii  libreadline8  8.1-1

Versions of packages units recommends:
ii  python3   3.9.2-3
ii  python3-requests  2.25.1+dfsg-2

units suggests no packages.

-- debconf-show failed


signature.asc
Description: PGP signature

Bug#1003634: texlive-latex-base: \fontseries broken: seems to be cumulative until {m} or so?

[Norbert Preining]

Hi

I don't do ping-pong of bugs here, but this is not the least related to
Debian at all, and should be brought to the respective channels (TL
mailing list, LaTeX team tracker, IRC, ...).

All the best

Norbert

--
PREINING Norbert  https://www.preining.info
Fujitsu Research +IFMGA Guide +TU Wien+TeX Live
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#1003707: nvidia-legacy-340xx-driver

[Сергей Petrov]

Package: nvidia-legacy-340xx-driver
Version: 340.108-12

Jan 12 00:23:27 debian-home systemd[1]: Starting NVIDIA Persistence
Daemon...
Jan 12 00:23:27 debian-home nvidia-persistenced: Started (13397)
Jan 12 00:23:27 debian-home nvidia-persistenced: Failed to open
libnvidia-cfg.so.1: libnvidia-cfg.so.1: cannot open shared object file: No
such file or directory
Jan 12 00:23:27 debian-home nvidia-persistenced: Shutdown (13397)
Jan 12 00:23:27 debian-home nvidia-persistenced[13396]: nvidia-persistenced
failed to initialize. Check syslog for more details.
Jan 12 00:23:27 debian-home systemd[1]: nvidia-persistenced.service:
Control process exited, code=exited, status=1/FAILURE
Jan 12 00:23:27 debian-home systemd[1]: nvidia-persistenced.service: Failed
with result 'exit-code'.
Jan 12 00:23:27 debian-home systemd[1]: Failed to start NVIDIA Persistence
Daemon.

$find /usr/lib |grep libnvidia-cfg.so
/usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1
/usr/lib/x86_64-linux-gnu/nvidia/legacy-340xx/libnvidia-cfg.so.1
/usr/lib/x86_64-linux-gnu/nvidia/legacy-340xx/libnvidia-cfg.so.340.108
/usr/lib/x86_64-linux-gnu/nvidia/current/libnvidia-cfg.so.1
/usr/lib/x86_64-linux-gnu/nvidia/current/libnvidia-cfg.so.460.91.03
/usr/lib/i386-linux-gnu/nvidia/legacy-340xx/libnvidia-cfg.so.1
/usr/lib/i386-linux-gnu/nvidia/legacy-340xx/libnvidia-cfg.so.340.108

Maybe wrong this?
$file /usr/lib/x86_64-linux-gnu/nvidia/current/libnvidia-cfg.so.1
/usr/lib/x86_64-linux-gnu/nvidia/current/libnvidia-cfg.so.1: symbolic link
to libnvidia-cfg.so.460.91.03


Debian version: 11.2(stable)
Architecture: amd64

Bug#1003706: ITS: sofia-sip

[Jonas Smedegaard]

Source: sofia-sip
Version: 1.12.11+20110422.1-2.1
Severity: important
X-Debbugs-Cc: Ron Lee 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Ron,

It seems sofia-sip is not actively maintained, and I hereby request to
salvage the package.

The package has seen no uploads from you for 8 years, an NMU was made 5
years ago seemingly uncommented by you, and several important bugs have
been open for several years with no comment from you.

Point is not to point fingers, only to elaborate on why I propose that
salvation is needed and I thereby initiate that process.  If you prefer
to maintain the package yourself then that's great - please do.

As per the salvaging process, I now give you some some time to respond,
and otherwise will issue a delayed NMU which effectuates my salvation.

(I will most likely salvage as part of the VoIP team, and maintain it
together with Evangelos, in case someone wonders about how this might
collide/relate with the discussion in bug#965829).


Kind regards,

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmHgwrIACgkQLHwxRsGg
ASHuXg/+N35mRC4wIB8X0nrnYr13PNSMuAZTxNJ7i2r3ew5rvTidCVJD7iGHx60z
uzocaTriKF7EhFH8HfRzoZ8gjyeGq35JLip/WgDnGKgmysl5GeMk7mfV3s1Glp3o
+IoJw9M37lBfljyCleHzV0CTE6fk+0xdVC/ZW257xOn8LYjuYc3GWj0JRmsAK7+q
MtWckVLwsFN4zz+bUWXgiUiWnLvh/jaFBUrxHIW8iw1iECW5FD2IVRY4l6LcdBM0
ZRUJoDpy/A79LGcsa1kELz1TrN2adwXnUHu4RgHuPRrJHvKcTgMqKdYLI1S65sgE
UDy+CuFo2mW9KVP+VilxNC+q65JODdnQVzXaxttjHnzx7XsxHEqP5XnMaqOJWuei
SdXkPvP4pA5w8xV1rx80khojEcprGjuY1eVLqMNulGkpaLe3rkuLQ6YSOkYI8CZ4
bOLWXvoPFLVbx57ciImvbdbM8mP2GERHwYROvuy64hTvxSg//v7CIkgnQbQ1xo60
irKh2UQ23qNCiabWLIdcxjFKi8zARYQZHB1f5lRRrIw7e7ugNk2633dinfXceMXg
6gyr98TGwEWAiEMA5GpU4j2Ueb3pD5Q16Dzioqh3io0fFI//mqYdcXjc0C6nzgo3
4r+7O0SBpxRK20AC8Vnmu56jsk+wivphpiz0P+Q6YudFAQuzEVo=
=gIB5
-END PGP SIGNATURE-

Bug#1000871: [Pkg-tigervnc-devel] Bug#1000871: tigervnc-standalone-server: server fails to start

[Joachim Falk]

Hi All,

On 12/1/21 18:49, Celejar wrote:
>>> Primarily the segfault,

as far as I can tell, tigervnc does not segfault. The problem is that the
xfce session segfaults and terminates early. Moreover, default for tigervnc
is on session termination to kill the VNC server.

Try

  tigervncserver -autokill no

to prevent this. Moreover, try

  tigervncserver -xstartup /usr/bin/xterm --

to get a simple X terminal going in the VNC server.
Note the --. Otherwise /usr/bin/xterm will be started with
the session argument, i.e., startxfce4 in your case.
By the way, this is not the standard configuration. Someone
must have edited some configuration files to specify the xfce
session.

Best,

Joachim

Bug#1000871: [Pkg-tigervnc-devel] Bug#1000871: tigervnc-standalone-server: server fails to start

[Joachim Falk]

Hi All,

On 12/1/21 18:49, Celejar wrote:
>>> Primarily the segfault,

as far as I can tell, tigervnc does not segfault. The problem is that the
xfce session segfaults and terminates early. Moreover, default for tigervnc
is on session termination to kill the VNC server.

Try

  tigervncserver -autokill no

to prevent this. Moreover, try

  tigervncserver -xstartup /usr/bin/xterm --

to get a simple X terminal going in the VNC server.
Note the --. Otherwise /usr/bin/xterm will be started with
the session argument, i.e., startxfce4 in your case.
By the way, this is not the standard configuration. Someone
must have edited some configuration files to specify the xfce
session.

Best,

Joachim


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003095: /usr/bin/script: hangs when child doesn't read input fast enough

[наб]

Control: tag -1 + patch

Hi!

See scissor-patch, below, which fixes this.

I tortured it a bit and ironed out all the problems I could find;
both script and test_pty work (well, test_pty still doesn't process
newlines properly but it was like that when I found it).

Best,
наб

-- >8 --
Subject: Put master PTY into non-blocking mode and buffer its output
 to avoid deadlock

If we filled the script->child buffer before the child had a chance
to read any input, we'd sleep forever in write_all(pty->master),
and the child would sleep forever in write(1slave>)

By putting the master PTY in non-blocking mode, we can
poll(pty->master, POLLOUT) and keep supplying more data
as the child reads from the buffer

Fixes Debian bug #1003095
---
pty-session.h: +7
pty-session.c: +90 -23

--- util-linux-2.37.2.orig/include/pty-session.h
+++ util-linux-2.37.2/include/pty-session.h
@@ -81,6 +81,13 @@ struct ul_pty {
 
struct timeval  next_callback_time;
 
+   struct ul_pty_child_buffer {
+   struct ul_pty_child_buffer *next;
+   char buf[BUFSIZ];
+   size_t size, cursor;
+   unsigned int final_input:1; /* drain child before writing */
+   } *child_buffer_head, *child_buffer_tail;
+
unsigned int isterm:1,  /* is stdin terminal? */
 slave_echo:1;  /* keep ECHO on pty slave */
 };
--- util-linux-2.37.2.orig/lib/pty-session.c
+++ util-linux-2.37.2/lib/pty-session.c
@@ -69,6 +69,10 @@ struct ul_pty *ul_new_pty(int is_stdin_t
 
 void ul_free_pty(struct ul_pty *pty)
 {
+   for(struct ul_pty_child_buffer *hd; (hd = pty->child_buffer_head);) {
+   pty->child_buffer_head = hd->next;
+   free(hd);
+   }
free(pty);
 }
 
@@ -182,7 +186,7 @@ int ul_pty_setup(struct ul_pty *pty)
cfmakeraw(&attrs);
tcsetattr(STDIN_FILENO, TCSANOW, &attrs);
} else {
-   DBG(SETUP, ul_debugobj(pty, "create for non-terminal"));
+   DBG(SETUP, ul_debugobj(pty, "create for non-terminal"));
 
rc = openpty(&pty->master, &pty->slave, NULL, NULL, NULL);
if (rc)
@@ -198,6 +202,8 @@ int ul_pty_setup(struct ul_pty *pty)
tcsetattr(pty->slave, TCSANOW, &attrs);
}
 
+   fcntl(pty->master, F_SETFL, O_NONBLOCK);
+
sigfillset(&ourset);
if (sigprocmask(SIG_BLOCK, &ourset, NULL)) {
rc = -errno;
@@ -290,9 +296,21 @@ static int write_output(char *obuf, ssiz
return 0;
 }
 
-static int write_to_child(struct ul_pty *pty, char *buf, size_t bufsz)
+static int schedule_child_write(struct ul_pty *pty, char *buf, size_t bufsz, 
int final)
 {
-   return write_all(pty->master, buf, bufsz);
+   struct ul_pty_child_buffer *stash = calloc(1, sizeof(*stash));
+   if (!stash)
+   return -1;
+
+   memcpy(stash->buf, buf, bufsz);
+   stash->size = bufsz;
+   stash->final_input = final ? 1 : 0;
+
+   if (pty->child_buffer_head)
+   pty->child_buffer_tail = pty->child_buffer_tail->next = stash;
+   else
+   pty->child_buffer_head = pty->child_buffer_tail = stash;
+   return 0;
 }
 
 /*
@@ -311,16 +329,13 @@ static int write_to_child(struct ul_pty
  * maintains master+slave tty stuff within the session. Use pipe to write to
  * pty and assume non-interactive (tee-like) behavior is NOT well supported.
  */
-void ul_pty_write_eof_to_child(struct ul_pty *pty)
+static void drain(struct ul_pty *pty)
 {
unsigned int tries = 0;
-   struct pollfd fds[] = {
-  { .fd = pty->slave, .events = POLLIN }
-   };
-   char c = DEF_EOF;
+   struct pollfd fd = { .fd = pty->slave, .events = POLLIN };
 
DBG(IO, ul_debugobj(pty, " waiting for empty slave"));
-   while (poll(fds, 1, 10) == 1 && tries < 8) {
+   while (poll(&fd, 1, 10) == 1 && tries < 8) {
DBG(IO, ul_debugobj(pty, "   slave is not empty"));
xusleep(25);
tries++;
@@ -329,7 +344,51 @@ void ul_pty_write_eof_to_child(struct ul
DBG(IO, ul_debugobj(pty, "   slave is empty now"));
 
DBG(IO, ul_debugobj(pty, " sending EOF to master"));
-   write_to_child(pty, &c, sizeof(char));
+}
+
+static int flush_child_buffers(struct ul_pty *pty, int *anything)
+{
+   int ret = 0, any = 0;
+   while (pty->child_buffer_head) {
+   struct ul_pty_child_buffer *hd = pty->child_buffer_head;
+
+   if(hd->final_input)
+   drain(pty);
+
+   DBG(IO, ul_debugobj(hd, " stdin --> master trying %zu bytes", 
hd->size - hd->cursor));
+   ssize_t ret = write(pty->master, hd->buf + hd->cursor, hd->size 
- hd->cursor);
+   if (ret == -1) {
+   DBG(IO, ul_debugobj(hd, "   EAGAIN"));
+   if (!(errno == EINTR || errno == EAGAIN))
+   re

Bug#1003700: python-coverage: autopkgtest fails - pypy-coverage no longer built

[Ben Finney]

Control: tags -1 + confirmed pending

On 14-Jan-2022, Ben Finney wrote:

> Nothing in the Debian packaging (nor in the upstream) makes any
> reference to ‘pypy-coverage’. […]

My mistake, I failed to open the correct repository. The bug is in the
Autopkgtest control file. Thanks.

-- 
 \  “Contentment is a pearl of great price, and whosoever procures |
  `\it at the expense of ten thousand desires makes a wise and |
_o__)  happy purchase.” —J. Balguy |
Ben Finney 


signature.asc
Description: PGP signature

Bug#1003700: python-coverage: autopkgtest fails - pypy-coverage no longer built

[Ben Finney]

On 13-Jan-2022, Stefano Rivera wrote:
> https://ci.debian.net/packages/p/python-coverage/unstable/amd64/
> 
> E: Unable to locate package pypy-coverage
> module-scripts   FAIL badpkg
> blame: python-coverage

Looking at the test log, the failure is traceable to:

autopkgtest [02:39:33]: test module-scripts: preparing testbed
Reading package lists...
Building dependency tree...
Reading state information...
Correcting dependencies...Starting pkgProblemResolver with broken count: 1
Starting 2 pkgProblemResolver with broken count: 1
Investigating (0) autopkgtest-satdep:amd64 < 0 @iU K Nb Ib >
Broken autopkgtest-satdep:amd64 Depends on pypy-coverage:amd64 < none @un H 
>
  Removing autopkgtest-satdep:amd64 because I can't find pypy-coverage:amd64

Nothing in the Debian packaging (nor in the upstream) makes any
reference to ‘pypy-coverage’. What is causing ‘autopkgtest-satdep’ to
declare that dependency?

-- 
 \   “Crime is contagious… if the government becomes a lawbreaker, |
  `\  it breeds contempt for the law.” —Justice Louis Brandeis |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu

[Johannes Schauer Marin Rodrigues]

Quoting Francesco Poli (2022-01-13 23:52:02)
> On Mon, 10 Jan 2022 23:18:36 +0100 Johannes Schauer Marin Rodrigues
> wrote:
> 
> [...]
> > You could set TMPDIR to a location that has enough space.
> 
> I had tried, if you recall.
> But you told me that the temporary directory must be world-writable
> (and preferably with the sticky bit set) and all the directories in the
> path must be world-readable.
> 
> This rules out anything within my home directory (setting my home
> directory as world-readable is out of the question).
> 
> We have already seen that my /tmp lives in a partition which is too
> small.
> 
> I would rather not create some non-FHS directory for this specific
> purpose: it would effectively be a second non-standard /tmp directory
> somewhere...
> 
> So, what's left?!?
> 
> Is /dev/shm a possible choice?
> 
>   $ df --si /dev/shm
>   Filesystem  Size  Used Avail Use% Mounted on
>   tmpfs   8.3G  108M  8.2G   2% /dev/shm
> 
> It's half the size of my main memory and it's within the main memory.
> Should I try to set TMPDIR=/dev/shm ?

yes, I think that's worth a try.

Other than that, you could run mmdebstrap with --mode=fakechroot which, in
comparison to unshare mode, doesn't require the world-readable path for the
TMPDIR.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1003705: spice-html5: Spice-html5 has wrong path to main.js

[Michal Arbet]

Package: spice-html5
Version: 0.3.0-1
Severity: normal

Dear Maintainer,

As debian package is copying src/main.js to root
along with other files, there is needed to change a path
to this file.

Otherways js console reports 404.

GET https://api.xena.ultimum.cloud:6082/src/main.js net::ERR_ABORTED 404 (File 
not found)

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

Kernel: Linux 4.19.0-8-amd64 (SMP w/32 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages spice-html5 depends on:
ii  dpkg  1.19.7

Versions of packages spice-html5 recommends:
ii  websockify  0.8.0+dfsg1-10

spice-html5 suggests no packages.

Bug#1003704: bugs.debian.org: error compiling kernel 5.16

[gdaniel1358]

Package: bugs.debian.org
Severity: grave
Justification: can not compile kernel 5.16
X-Debbugs-Cc: gdaniel1...@hotmail.com

Dear Maintainer,

Hi, tried to compile kernel 5.16.0 from kernel.org.
At linking point I get:

 CHK include/generated/compile.h
  LD  vmlinux.o
  MODPOST vmlinux.symvers
  MODINFO modules.builtin.modinfo
  GEN modules.builtin
  LD  .tmp_vmlinux.btf
ld: BFD (GNU Binutils for Debian) 2.35.2 internal error, aborting at 
../../bfd/merge.c:939 in _bfd_merged_section_offset

ld: Please report this bug.



thanks in advance. 

Bug#726542: O: pngphoon -- Creates a png file with the current phase of the moon

[Paulo]

retitle 726542 ITA: pngphoon -- Creates a png file with the current phase of 
the moon
owner 726542 !
thanks


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003610: libc6 crashes with VIA C7 and VIA Eden processors starting with 2.33

[Aurelien Jarno]

On 2022-01-13 14:20, Wolfgang Walter wrote:
> Am 2022-01-12 16:46, schrieb Aurelien Jarno:
> > On 2022-01-12 16:14, Wolfgang Walter wrote:
> > > Package: libc6
> > > Version: 2.33-2
> > > Severity: important
> > > 
> > > After upgrading from libc6 2.32 to 2.33 all machines with a VIA C7
> > > or VIA
> > > Eden show segfaults in libc (i.e. hostname fails to work, or rebooting
> > > fails). Machines with VIA Nehemiah work fine.
> > 
> > Could you please provide more details? At least the content of dmesg
> > when it happens or ideally a core dump or a backtrace.
> 
> Not easy. These machines just boot into a initramfs (which is a very minimal
> debian sid) from an usb-stick and nothing survives a reboot. /bin/sh points
> to bash.
> 
> The system does not use systemd but sysv.
> 
> The login prompt is:
> 
> (none) login:
> 
> 
> I cannot log into the machine, login seems also be broken, it always says
> "login incorrect".
> 
> If I try to reboot by entering ctrl-alt-del the reboot fails with:
> 
> INIT: Switching to runlevel: 6
> INIT: No inittab.d directory found
> INIT: Sending processes configured via /etc/inittab the TERM signal
> [  305.550677][ T1235] rc[1235]: segfault at 1c81000 ip b7ebf634 sp bfb5ce78
> error 6 in libc-2.33.so[b7d8e000+158000]
> [  305.550791][ T1235] Code: 95 04 00 03 1c 8b 01 ca ff e3 29 d9 8d b4 26 00
> 00 00 00 8d 76 00 0f 18 8a c0 03 00 00 0f 18 8a 80 03 00 00 81 eb 80 00 00
> 00 <66> 0f 7f 02 66 0f 7f 42 10 66 0f 7f 42 20 66 0f 7f 42 30 66 0f 7f
> Give root password for maintenance
> (or press Control-D to continue):

Thanks. This codes corresponds to memset_sse2:

  14e607:   81 c3 69 95 04 00   add$0x49569,%ebx
  14e60d:   03 1c 8badd(%ebx,%ecx,4),%ebx
  14e610:   01 ca   add%ecx,%edx
  14e612:   ff e3   jmp*%ebx
  14e614:   29 d9   sub%ebx,%ecx
  14e616:   8d b4 26 00 00 00 00lea0x0(%esi,%eiz,1),%esi
  14e61d:   8d 76 00lea0x0(%esi),%esi
  14e620:   0f 18 8a c0 03 00 00prefetcht0 0x3c0(%edx)
  14e627:   0f 18 8a 80 03 00 00prefetcht0 0x380(%edx)
  14e62e:   81 eb 80 00 00 00   sub$0x80,%ebx
=>14e634:   66 0f 7f 02 movdqa %xmm0,(%edx)
  14e638:   66 0f 7f 42 10  movdqa %xmm0,0x10(%edx)
  14e63d:   66 0f 7f 42 20  movdqa %xmm0,0x20(%edx)
  14e642:   66 0f 7f 42 30  movdqa %xmm0,0x30(%edx)
  14e647:   66 0f 7f 42 40  movdqa %xmm0,0x40(%edx)
 
> But I cannot login (Login incorrect). If I enter control-d instead, I get
> "sulogin: cannot read /dev/tty1: Operation not permitted".
> 
> The very same usb stick boots just fine with non VIA 7 / VIA Eden
> processors.
> 
> 
> I modified it a bit an set --autologin for one getty. This did not worḱ, I
> get a lot of things like
> 
> [   ..][ T1231] login[1231]: segfault at bfd3d000 ip b7eb5656 sp
> bfd36978 error 6 in libc-2.33.so[b7d84000+158000]
> 
> or
> 
> [ ][ T1241] sh[1241]: segfault at 12ac000 ip b7e03638 sp bff99ff8
> error 6 in libc-2.33.so[b7cd2000+158000]
> 
> 
> Now I tried  getty -n -l /bin/dash. This worked.
> 
> If I try to start bash, bash crashes with a segmentation fault. I have no
> debugger and no debugging symbols in this image at the moment, only strace
> 
> If I strace -f bash I get:
> 
> The last thing done is reading the first line of passwd, closing the file.
> Then there is a SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR,
> si_addr=0x12d9000}
> 
> When I do a strace -f bash 2> /tmp/blub the last system call is uname(),
> then again a SEGV_MAPPERR
> 
> When bash segfaults I get no log that it crashed in libc6.
> 
> ls, rm, mount  etc seem to work.
> 
> But vim crashes in libc6, again at +158000 and with Code "1c 8b 01 ca ff e3
> 29 d9 8d b4 26 00 00 00 00 8d 76 00 0f 18 8a c0 03 00 00 0f 18 8a 80 03 00
> 00 81 eb 80 00 00 00 <66> 0f 7f 02 66 0f 7f 42 10 66 0f 7f 42 20 66 0f 7f 42
> 30 66 0f"
> 
> Also ip link ls crashes, again in libc6, again at +158000 and with Code "0f
> 18 8a 80 03 00 00 81 eb 80 00 00 00 00 66 0f 7f 02 66 0f 7f 42 10 66 0f 7f
> 42 20 66 0f 7f 42 30 66 0f 7f 42 40 66 0f 7f 42 50 <66> 0f 7f 02 66 0f 7f 42
> 70 71 c2 80 00 00 00 81 fb 80 00 00 00"
> 
> or ip addr ls
> 
> or less, perl, ssh, sshd, rsyslogd
> 
> The Code is not always the same, but <66> 0f 7f 42 seems to be and the crash
> in libc-2.33.so[x+158000]
> 

The above crashes are in memset_sse2 or bzero_sse2, I do not have enough
details to confirm, but that's not that important.


Thanks a lot for those details, they definitely help to understand
things a bit better, although things are not fully clear yet.

The memset_sse2 and bzero_sse2 are called only on a SSE2 capable CPU,
which is the case of the VIA C7, and that matches the fact the crash is
a segmentation fault and not an illegal instruction. The addresses
seems to be correctly aligned as required by SSE2 instructions. 

I do no

Bug#1003687: python-pip breaks python-virtualenv autopkgtest: invalid syntax

[stefanor]

Hi Paul (2022.01.13_18:00:41_+)

We have a transition in progress, although not coordinated with you guys.
See #1003573. Once that is done, all the python3 side will work again.

We need to get python2-pip through NEW to get 2.7 virtualenvs working
again. I'll probably mark those tests as skip-not-installable, for now.

SR

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

Bug#1003703: Print menu does not work well

[Paul van der Vlis]

Package: firefox-esr
Version: 91.5.0esr-1

In this version of Firefox there is a new Mozilla print dialog window 
active, what does not work well.


E.g. the default setting of my printer is black/white and double sided 
printing, but the dialog box displays color and single sided. When I 
print this way, it becomes black/white and double sided, so not what the 
print dialog says...


It is possible to use the system print dialog box with this setting in 
about:config:  print.tab_modal.enabled   false

In my opinion this would be a better default.

With regards,
Paul van der Vlis

--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl/

Bug#1002993: systemd: Setting access ACL: invalid argument (Upgrade to 247.3-6 from buster to bullseye in container)

[Michael Biebl]

On Sun, 2 Jan 2022 21:38:01 +0100 Tobias Frost  wrote:



Albeith, I cannot set ACLs in /var/log/journal:

setfacl --modify="u:unifi:rw" test.txt
setfacl: test.txt: Malformed access ACL 
`user::rw-,user:unifi:rw-,group::r-x,group:adm:r-x,group:4294967295:r-x,mask::rwx,other::r--':
 Duplicate entries at entry 5


Interesting.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778656
comes to mind here, but that should be fixed and cleaned up.

But tbh, I don't see the duplicate here...


I wonder whether this is might be a libacl or kernel bug.
See also https://lists.gnu.org/archive/html/acl-devel/2018-10/msg0.html

I've CCed guillem, maybe he has an idea.




Regards,
Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003702: node-postcss: uses internet during build

[Gianfranco Costamagna]

Source: node-postcss
Version: 8.4.5+~cs7.1.51-1
Severity: serious

Hello, looks like the software is trying to reach github.com and habr.com 
during node test/integration.js

This can be seen in Ubuntu build logs
https://launchpad.net/ubuntu/+source/node-postcss/8.4.5+~cs7.1.51-1/+build/23052474


ln -s ../. node_modules/postcss
/bin/sh -ex debian/tests/pkg-js/test
+ node test/integration.js
- github.com
- github.com
- habr.com
- github.com
- habr.com
- bootstrap.css
Error: getaddrinfo ENOTFOUND github.com
Error: getaddrinfo ENOTFOUND habr.com
Error: getaddrinfo ENOTFOUND github.com
Error: getaddrinfo ENOTFOUND habr.com
Error: getaddrinfo ENOTFOUND github.com
Error: getaddrinfo ENOTFOUND stackpath.bootstrapcdn.com
Error: getaddrinfo ENOTFOUND habr.com

https://github.com/
 Request error  Error: getaddrinfo ENOTFOUND github.com
dh_auto_test: error: /bin/sh -ex debian/tests/pkg-js/test returned exit code 1
make: *** [debian/rules:5: binary] Error 25


This is forbidden by policy.

Thanks for having a look

Gianfranco

Bug#996245: dh-make: make doc build arch-independent

[Craig Small]

Hi Drew,
  I've read this a few times, is there something we can do to fix this?
Should the commit be rolled back?

On Tue, 4 Jan 2022 at 07:30, Drew Parsons  wrote:

> Hi Craig, Commit 4ad43078 applied a patch for Bug#996245 to make the
> sample debian/rules for python packages suggest using
> override_dh_auto_build-indep instead of override_dh_auto_build to
> build docs only for arch-independent builds.


 - Craig

Bug#1003700: python-coverage: autopkgtest fails - pypy-coverage no longer built

[Stefano Rivera]

Source: python-coverage
Version: 6.2+dfsg1-1
Severity: normal

Since 6.2+dfsg1-1 the autopkgtest is failing, due to the removal of
pypy-coverage:

https://ci.debian.net/packages/p/python-coverage/unstable/amd64/

E: Unable to locate package pypy-coverage
module-scripts   FAIL badpkg
blame: python-coverage

SR

Bug#998058: intel-compute-runtime: FTBFS due to 2 failing tests

[Yuri D'Elia]

Package: intel-opencl-icd
Followup-For: Bug #998058

Any news?

Bug#978040: [Pkg-pascal-devel] Bug#978040: Warning: (9034) "crtbeginS.o" not found (on non-intel architectures)

[Abou Al Montacir]

Hi Paul,

On Sun, 2022-01-02 at 17:06 +0100, Paul Gevers wrote:
> I'm not sure your allowed to run dpkg-reconfigure on a trigger as that 
> requires admin interaction. That sounds weird. As an admin I wouldn't 
> expect my configuration to get updated (when installing an "unrelated" 
> package). 
I just wanted to say that re-running dpkg-reconfigure did the trick. So we may
be able to have a simpler script that regenerates the config file by running the
required command and only that one. No need for a full reconfiguration, just un
update of the path in /etc/fpc.cfg 

> And we would want to have a trigger on gcc upgrade? I don't 
> know how triggers work exactly, but wouldn't gcc need to provide the 
> trigger then?
As far as I could see in [1], [2] and [3] we may be able to bypass gcc by
triggering on /usr/lib/gcc or some of its sub folder.

[1] https://wiki.debian.org/DpkgTriggers
[2] https://stackoverflow.com/questions/15276535/dpkg-how-to-use-trigger
[3] 
https://web.archive.org/web/20111022012105/http://www.seanius.net/blog/2009/09/dpkg-triggers-howto/
-- 
Cheers,
Abou Al Montacir


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

Bug#1003699: libfido2-dev: missing dependency on libssl-dev breaks pkg-config

[Michael Biebl]

On Thu, 13 Jan 2022 20:55:45 + Luca Boccassi  wrote:

Package: libfido2-dev
Version: 1.9.0-1
Tags: patch

While adding libfido2-dev as a dependency to src:systemd, we noticed
that it fails to build if libssl-dev is not installed, because
libfido2.pc lists:

Requires: libcrypto

So pkg-config --cflags --libs libfido2 breaks:

pkg-config error with 'libfido2': Could not generate cargs for libfido2:
Package libcrypto was not found in the pkg-config search path.
Perhaps you should add the directory containing `libcrypto.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libcrypto', required by 'libfido2', not found

Could not generate cargs for libfido2:
Package libcrypto was not found in the pkg-config search path.
Perhaps you should add the directory containing `libcrypto.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libcrypto', required by 'libfido2', not found

libssl-dev is currently suggested, so it should be bumped to a dependency.


Without having looked at libfido2, an alternative might be the usage of 
Requires.private


"Requires.private: A list of private packages required by this package 
but not exposed to applications. The version specific rules from the 
Requires field also apply here."


IIRC, Requires.private dependencies are not required for determining CFLAGS.

Regards,
Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#998125: libasound2-plugins: Config file for a52 plugin (60-a52-encoder.conf) produces no/garbled sound via optical digital out (S/PDIF)

[Christian Welzel]

Hi there,

i also had these sound problems using a TOSLink to my external receiver. 
Today i compiled the new 1.2.6 packages of libasound2 and 
libasound2-plugins for bullseye and the 5.1 sound is working again.


I use the default 60-a52-encoder.conf fiĺe.

--
 MfG, Christian Welzel

 GPG-Key: pub 4096R/5117E119 2011-09-19
 Fingerprint: 3688 337C 0D3E 3725 94EC  E401 8D52 CDE9 5117 E119

Bug#1002617: RFS: carl9170fw/1.9.9-399-gcd480b9-1 [ITP] -- firmware for AR9170 USB wireless adapters

[John Scott]

Control: tags -1 moreinfo

Hi Paul,

Thanks for your very detailed review of carl9170fw. I'm still making my
changes to the package and will give you a poke and remove the moreinfo
tag once I have an upload ready for re-review.

> I don't think udebs are needed for firmware packages, none of the other
> WiFi firmware packages in Debian have them.
You might like to have a look at this mail from Ben Hutchings:
https://lists.debian.org/msgid-search/179d6d32466dd13962a3aab251c45242fbf2d8ae.ca...@decadent.org.uk
The reason that none of the other Wi-Fi firmware packages have them is
because they're all non-free (with the exception of ath9k_htc).

My understanding—which was most definitely not articulated by Ben—is
that the Debian Installer has a mechanism for loading the (non-free)
firmware from the ordinary .debs. Since the installer needs to have
logic to look for non-free firmware on removable media at runtime
anyway, that's quite a different situation to most that warrant udebs,
where the udeb is a "built-in" of the installer.

FYI, open-ath9k-htc-firmware is in NEW because my most recent upload
likewise adds a udeb for it.

> If the package is actually needed it should be named -udeb not -di,
> since other udebs use -udeb.
I wasn't sure if there was any established convention; my thread "Naming
convention for udebs: -udeb/-installer suffix" didn't garner any
pertinent responses. I've switched the name though.

> Several files have missing/incorrect information in debian/copyright,
> please do a full audit of the code looking for copyright/license info.
> 
>  * tools/include/list.h is LGPL
>  * tools/include/frame.h is partly from Linux, unknown copyright
>  * include/shared/eeprom.h also contains ISC code
These are all good catches, I'm working on incorporating them and doing
a slow and careful review.

> DEB_BUILD_OPTION_PARALLEL doesn't appear to be a standard variable,
> please switch to DEB_BUILD_OPTIONS=parallel=N instead, see Debian
> Policy, section 4.9.1 and debhelper(7) and dpkg-buildpackage(1).
I think you're mistaken here, you should take a look at
/usr/share/dpkg/buildopts.mk which I include via an include directive in
debian/rules. Basically, DEB_BUILD_OPTION_PARALLEL is a helper macro for
the value of parallel from DEB_BUILD_OPTIONS; these are one and the
same.

There's a chance of the DEB_BUILD_OPTION_PARALLEL Makefile macro still
being unset, so what this line does in my Makefile:
DEB_BUILD_OPTION_PARALLEL ?= 1
is set it to 1 if it's not set in one's DEB_BUILD_OPTIONS. That way,
calls like
make -j$(DEB_BUILD_OPTION_PARALLEL)
won't become
make -j
which would be very bad.

> Some things that would be nice to fix at some stage:
> 
> Nothing in debian/rules references .config so you can drop that from
> before the execute_before_dh_auto_configure target.
That's true. My intent was that, since it's a hidden directory, it would
help remind one that that directory gets created. It seems to've only
caused confusion, so I'll pull it.

> It seems like the Homepage should be the carl9170.fw firmware wiki page
> instead of the carl9170 driver wiki page.
> 
> https://wireless.wiki.kernel.org/en/users/drivers/carl9170.fw
Good catch, I will fix that.

> I would express the license of include/shared/fwcmd.h etc as GPL-2-only
> && ISC rather than putting a copy of the ISC license in a comment.
I agree that this is sensible.

> bug-presubj isn't well wrapped. I'm not sure if wrapped or unwrapped is
> the best option for this file though.
Indeed, the documentation is rather old and terse and doesn't address
this issue. I'll probably ask the Reportbug folks and send them a MR
updating the docs.

> Please ask upstream to make a new release, it has been a very long time
> since the last one.
I will do after making some of the following important changes.

> Please ask upstream to update their copies of code from the Linux
> kernel and other external sources to the latest versions.
I can probably help them with this.

> Please ask upstream to send FindUSB-1.0.cmake & libusb-zeropacket.diff
> to libusb upstream and then remove them from carl9170fw.
I will ask, but with all due respect, I think this is lower priority and
that I'll have limited ability to help them.

> Please ask upstream to delete FindPackageHandleStandardArgs.cmake,
> since that is now available from cmake upstream and from Debian cmake.
> Potentially cmake_minimum_required will need to be bumped for this.
Will do.

> Please ask upstream to include the copyright information
> for carlfw/src/memcpy.S and carlfw/src/memset.S in the files.
Especially since it is copyleft, I will definitely prioritize this.

> Please ask upstream to update the COPYRIGHT file.
I will be happy to do this.

> Please send upstream some changes that would allow building the
> upstream source using a pre-packaged toolchain like the Debian one.
> 
> Please also figure out how to eliminate the other debian/rules
> workarounds.
I do not have a grasp, let

Bug#1003699: libfido2-dev: missing dependency on libssl-dev breaks pkg-config

[Luca Boccassi]

Package: libfido2-dev
Version: 1.9.0-1
Tags: patch

While adding libfido2-dev as a dependency to src:systemd, we noticed
that it fails to build if libssl-dev is not installed, because
libfido2.pc lists:

Requires: libcrypto

So pkg-config --cflags --libs libfido2 breaks:

pkg-config error with 'libfido2': Could not generate cargs for libfido2:
Package libcrypto was not found in the pkg-config search path.
Perhaps you should add the directory containing `libcrypto.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libcrypto', required by 'libfido2', not found

Could not generate cargs for libfido2:
Package libcrypto was not found in the pkg-config search path.
Perhaps you should add the directory containing `libcrypto.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libcrypto', required by 'libfido2', not found

libssl-dev is currently suggested, so it should be bumped to a dependency.

MR submitted on Salsa:

https://salsa.debian.org/auth-team/libfido2/-/merge_requests/5

Kind regards,
Luca Boccassi

Bug#1003612: RFS: libview/0.6.6-3 [ITA] -- VMware's Incredibly Exciting Widgets

[Bastian Germann]

d/control: Remove or replace the Vcs-* fields.

Bug#1003696: prosody: CVE-2022-0217: Unauthenticated Remote Denial of Service Attack in the WebSocket interface

[Salvatore Bonaccorso]

Source: prosody
Version: 0.11.11-2
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for prosody.

CVE-2022-0217[0]:
| Unauthenticated Remote Denial of Service Attack in the WebSocket
| interface

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-0217
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0217
[1] https://prosody.im/security/advisory_20220113/
[2] https://www.openwall.com/lists/oss-security/2022/01/13/3

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#732788: Processed (with 5 errors): 732788

[Carl Karsten]

On Mon, Jan 3, 2022 at 3:51 AM Carl Karsten  wrote:
>
> https://salsa.debian.org/cloud-team/cloud-initramfs-tools/-/merge_requests/5

bump ^^^

>
> On Sat, Jan 1, 2022 at 8:28 AM Thomas Goirand  wrote:
> >
> > On 12/31/21 10:14 PM, Carl Karsten wrote:
> > > What do I need to do to get overlayroot into unstable?
> >
> > Hi,
> >
> > Thanks for your explanation, now I get it.
> >
> > If you want to work on this yourself, you can simply provide a merge
> > request in the Salsa repository over here:
> > https://salsa.debian.org/cloud-team/cloud-initramfs-tools
> >
> > then ping me again in this bug.
> >
> > Cheers,
> >
> > Thomas Goirand (zigo)
>
>
>
> --
> Carl K
>


-- 
Carl K

Bug#1003689: chromium: Chromium doesn't start

[Andres Salomon]

On Thu, 13 Jan 2022 19:24:30 +0100 Martin Dosch wrote:
> Package: chromium
> Version: 97.0.4692.71-0.1
> Severity: normal
> X-Debbugs-Cc: mar...@mdosch.de
>
> Dear Maintainer,
>
> chromium is no more starting on my system. If I try to start it in a 
terminal I

> get the following output:
>
> [708429:708429:0113/192057.675801:ERROR:gpu_init.cc(457)] Passthrough 
is not

> supported, GL is egl, ANGLE is
> [708429:708429:0113/192057.684752:ERROR:sandbox_linux.cc(378)]
> InitializeSandbox() called with multiple threads in process gpu-process.
> [708382:708382:0113/192057.717409:ERROR:cursor_loader.cc(114)] Failed 
to load a

> platform cursor of type kNull
> [708429:708429:0113/192059.334041:ERROR:gbm_pixmap_wayland.cc(76)] Cannot
> create bo with format= RGBA_ and usage=SCANOUT
> 
[708429:708429:0113/192059.334276:ERROR:gpu_memory_buffer_factory_native_pixmap.cc(261)]

> Failed to create pixmap 1024x512, RGBA_, usage SCANOUT
> [708429:708429:0113/192059.334443:ERROR:gbm_pixmap_wayland.cc(76)] Cannot
> create bo with format= RGBA_ and usage=GPU_READ
> 
[708429:708429:0113/192059.334549:ERROR:gpu_memory_buffer_factory_native_pixmap.cc(261)]

> Failed to create pixmap 1024x512, RGBA_, usage GPU_READ
> 
[708429:708429:0113/192059.334653:ERROR:shared_image_backing_factory_gl_image.cc(351)]

> CreateSharedImage: Failed to create bindable image
> [708429:708429:0113/192059.334742:ERROR:shared_image_factory.cc(586)]
> CreateSharedImage: could not create backing.
> 
[708429:708429:0113/192059.334976:ERROR:skia_output_surface_impl_on_gpu.cc(1714)]

> Failed to make current.
> [708429:708429:0113/192059.343452:ERROR:raster_decoder.cc(1238)]
> RasterDecoderImpl: Context lost during MakeCurrent.
> [708429:708429:0113/192059.343715:ERROR:shared_image_stub.cc(534)]
> SharedImageStub: context already lost
> [708429:708429:0113/192059.357480:ERROR:shared_image_stub.cc(534)]
> SharedImageStub: context already lost
> 
[708429:708429:0113/192059.387529:ERROR:skia_output_surface_impl_on_gpu.cc(1714)]

> Failed to make current.
> 
[708429:708429:0113/192059.403432:ERROR:skia_output_surface_impl_on_gpu.cc(1714)]

> Failed to make current.
> [708429:708429:0113/192059.493480:ERROR:gbm_pixmap_wayland.cc(76)] Cannot
> create bo with format= RGBA_ and usage=SCANOUT
> 
[708429:708429:0113/192059.493801:ERROR:gpu_memory_buffer_factory_native_pixmap.cc(261)]

> Failed to create pixmap 1024x512, RGBA_, usage SCANOUT
> [708429:708429:0113/192059.493972:ERROR:gbm_pixmap_wayland.cc(76)] Cannot
> create bo with format= RGBA_ and usage=GPU_READ
> 
[708429:708429:0113/192059.494115:ERROR:gpu_memory_buffer_factory_native_pixmap.cc(261)]

> Failed to create pixmap 1024x512, RGBA_, usage GPU_READ
> 
[708429:708429:0113/192059.494288:ERROR:shared_image_backing_factory_gl_image.cc(351)]

> CreateSharedImage: Failed to create bindable image
> [708429:708429:0113/192059.494469:ERROR:shared_image_factory.cc(586)]
> CreateSharedImage: could not create backing.
> [708382:708382:0113/192059.571489:ERROR:gpu_process_host.cc(968)] GPU 
process

> exited unexpectedly: exit_code=5
> [708569:708569:0113/192059.735783:ERROR:gpu_init.cc(457)] Passthrough 
is not

> supported, GL is egl, ANGLE is
> [708511:1:0113/192059.741308:ERROR:command_buffer_proxy_impl.cc(125)]
> ContextResult::kTransientFailure: Failed to send
> GpuControl.CreateCommandBuffer.
> [708569:708569:0113/192059.746960:ERROR:sandbox_linux.cc(378)]


Can you please try starting chromium with the argument 
"--use-gl=desktop" and see if that  fixes it?


Also, I'm guessing you're running this under Wayland. If 
--use-gl=desktop doesn't help, can you try deleting lines 61 through 63 
in /usr/bin/chromium? These are the lines to delete:


if [ -n "$WAYLAND_DISPLAY" ]; then
  CHROMIUM_FLAGS="$CHROMIUM_FLAGS --ozone-platform=wayland"
fi

Bug#1003426: glances: Provide this package in bullseye-backports?

[Boyuan Yang]

X-Debbugs-CC: epsi...@debian.org sba...@debian.org

Hi again,

I just made a no-change bullseye-backports upload onto BACKPORTS-NEW queue. I
will update the git packaging repo accordingly once this upload gets accepted.

Thanks,
Boyuan Yang

On Sun, 09 Jan 2022 18:59:30 -0500 Boyuan Yang  wrote:
> Source: glances
> Version: 3.2.4.2+dfsg-1
> Severity: normal
> X-Debbugs-CC: epsi...@debian.org sba...@debian.org
> 
> Dear Debian glances package maintainers,
> 
> According to https://tracker.debian.org/pkg/glances , package glances is
> currently missing in Debian 11 (bullseye). I have personally received some
> user requests to backport this package onto bullseye-backports. Just took a
> quick glance, and it seems that backporting is doable.
> 
> Now I am wondering if there are any important factors that would block
backage
> backporting. Otherwise I can make a backports upload and reflect related
> changes on https://salsa.debian.org/debian/glances . Please let me know if
> there are any issues.
> 
> Thanks!
> Boyuan Yang



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

Bug#1003678: sqlite3 breaks crowdsec autopkgtest: invalid type \"INTEGER\" for column

[GCS]

Control: reassign -1 src:golang-github-facebook-ent
Control: found -1 0.5.4-2
Control: tags -1 +patch

Hi Paul,

On Thu, Jan 13, 2022 at 3:54 PM Paul Gevers  wrote:
> With a recent upload of sqlite3 the autopkgtest of crowdsec fails in
> testing when that autopkgtest is run with the binary packages of sqlite3
> from unstable.
[...]
> Currently this regression is blocking the migration of sqlite3 to
> testing [1]. Due to the nature of this issue, I filed this bug report
> against both packages. Can you please investigate the situation and
> reassign the bug to the right package?
 SQLite3 used to store column data types as text with the same case it
was created. So it could have been 'integer', 'INTEGER' or even
'IntEGEr'. But with 3.37.0 and onwards it's now stored as an
enumerated value [1] and always translated to uppercase column type
[2].
Then golang-github-facebook-ent only checks for lowercase [3] values.
Meaning it was wrong for previous SQLite3 versions even.
The attached patch fixes this.

Hope this helps,
Laszlo/GCS
[1] https://github.com/sqlite/sqlite/blob/version-3.37.0/src/global.c#L388
[2] https://github.com/sqlite/sqlite/blob/version-3.37.0/src/global.c#L396
[3] https://github.com/ent/ent/blob/v0.5.4/dialect/sql/schema/sqlite.go#L284
Description: SQLite3 3.37.0+ use uppercase column tupe names
 Starting with SQLite3 3.37.0 it stores column type names as a value and
 always displayed in uppercase letters.
 Previously it stored type names as text with the same case as it was given. 
 This breaks testing where the column type is defined in lowercase and
 expects it to be given back as-is.
 Fix this with using type names in uppercase.
Author: Laszlo Boszormenyi (GCS) 
Forwarded: no
Last-Update: 2022-01-13

---

--- golang-github-facebook-ent-0.5.4.orig/dialect/sql/schema/sqlite.go
+++ golang-github-facebook-ent-0.5.4/dialect/sql/schema/sqlite.go
@@ -281,7 +281,7 @@ func (d *SQLite) scanColumn(c *Column, r
 	if err != nil {
 		return err
 	}
-	switch parts[0] {
+	switch strings.ToLower(parts[0]) {
 	case "bool", "boolean":
 		c.Type = field.TypeBool
 	case "blob":

Bug#1003693: ITP: fcitx5-keyman -- Fcitx5 wrapper for Keyman keyboarding platform

[Boyuan Yang]

Package: wnpp
Severity: wishlist

* Package name: fcitx5-keyman
  Version : 1.0.1-1
  Upstream Author : CSSlayer 
* URL : https://github.com/fcitx/fcitx5-keyman
* License : GPL-2.0-or-later
  Programming Lang: C++
  Description : Fcitx5 wrapper for Keyman keyboarding platform

 fcitx5-keyman is a wrapper of Keyman keyboarding platform for Fcitx5
 IM framework.
 .
 Keyman is now a free and open source keyboarding platform which allows
 anyone to write a keyboard layout for their language.

I plan to maintain this package under Debian Input Method Team:
https://salsa.debian.org/input-method-team/fcitx5-keyman .

Thanks,
Boyuan Yang


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

Bug#1003691: scim: diff for NMU version 1.4.18+git20211204-0.1

[Boyuan Yang]

Control: tags 1003691 + patch
Control: tags 1003691 + pending

Dear maintainer,

I've prepared an NMU for scim (versioned as 1.4.18+git20211204-0.1) and
uploaded it to DELAYED/14. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru scim-1.4.18/configure.ac scim-1.4.18+git20211204/configure.ac
--- scim-1.4.18/configure.ac2017-07-30 22:45:36.0 -0400
+++ scim-1.4.18+git20211204/configure.ac2021-12-04 05:40:01.0
-0500
@@ -242,6 +242,10 @@
[SCIM_HAS_GTK3=yes],
[SCIM_HAS_GTK3=no])
 
+PKG_CHECK_MODULES(GTK4, [gtk4 >= 4.0.0 pango >= 1.48.0 gdk-pixbuf-2.0 >=
2.42.0],
+   [SCIM_HAS_GTK4=yes],
+   [SCIM_HAS_GTK4=no])
+
 SCIM_HAS_GTK2_2=no
 if test "$SCIM_HAS_GTK2" = "yes"; then
   if $PKG_CONFIG --exists "gtk+-2.0 >= 2.2" ; then
@@ -261,6 +265,14 @@
   AC_SUBST(GTK3_IM_MODULEDIR)
 fi
 
+if test "$SCIM_HAS_GTK4" = "yes"; then
+  GTK4_VERSION=4.0.0
+  GTK4_BINARY_VERSION=`$PKG_CONFIG --variable=gtk_binary_version gtk4`
+  GTK4_LIBDIR=`$PKG_CONFIG --variable=libdir gtk4`
+  GTK4_IM_MODULEDIR=$GTK4_LIBDIR/gtk-4.0/$GTK4_BINARY_VERSION/immodules
+  AC_SUBST(GTK4_IM_MODULEDIR)
+fi
+
 # Check if we have gthread
 PKG_CHECK_MODULES(GTHREAD2,[gthread-2.0 >= 2.0.0],
[SCIM_HAS_GTHREAD2=yes],
@@ -344,6 +356,11 @@
[Select GTK3 immodule dir])],
[GTK3_IM_MODULEDIR=$with_gtk3_im_module_dir])
 
+AC_ARG_WITH([gtk4-im-module-dir],
+   [AS_HELP_STRING([--with-gtk4-im-module-dir=dir], 
+   [Select GTK4 immodule dir])],
+   [GTK4_IM_MODULEDIR=$with_gtk4_im_module_dir])
+
 AC_ARG_WITH([qt3-moc],
[AS_HELP_STRING([--with-qt3-moc=file],
[Select QT3 moc program (default to QT3_PREFIX/bin/moc)])],
@@ -483,6 +500,12 @@
[],
[enable_gtk3_immodule=yes])
 
+AC_ARG_ENABLE([gtk4-immodule],
+   [AS_HELP_STRING([--disable-gtk4-immodule],
+   [Do not build GTK4 IMModule])],
+   [],
+   [enable_gtk4_immodule=yes])
+
 AC_ARG_ENABLE([qt3-immodule],
[AS_HELP_STRING([--disable-qt3-immodule],
[Do not build QT3 IMModule])],
@@ -625,6 +648,15 @@
   enable_gtk3_immodule=no
 fi
 
+if test "$enable_gtk4_immodule" = "yes" -a "$SCIM_HAS_GTK4" = "yes"; then
+  SCIM_BUILD_GTK4_IMMODULE=1
+  SCIM_BUILD_IMMODULE=1
+  enable_immodule=yes
+else
+  SCIM_BUILD_GTK4_IMMODULE=0
+  enable_gtk4_immodule=no
+fi
+
 if test "$enable_im_agent" = "yes"; then
   SCIM_BUILD_IM_AGENT=1
 else
@@ -657,6 +689,17 @@
   enable_gtk3_immodule=no
 fi
 
+if test "$enable_gtk4_immodule" = "yes" -a "$SCIM_HAS_GTK4" = "yes"; then
+  SCIM_BUILD_GTK4_IMMODULE=1
+  SCIM_BUILD_IMMODULE=1
+  enable_immodule=yes
+  SCIM_BUILD_IM_AGENT=1
+  enable_im_agent=yes
+else
+  SCIM_BUILD_GTK4_IMMODULE=0
+  enable_gtk4_immodule=no
+fi
+
 if test "$enable_qt3_immodule" = "yes" -a "$SCIM_HAS_QT3" = "yes"; then
   SCIM_BUILD_QT3_IMMODULE=1
   SCIM_BUILD_IMMODULE=1
@@ -692,19 +735,37 @@
   enable_clutter_immodule=no
 fi
 
-if test "$SCIM_HAS_GTK3" = "yes" -a "$SCIM_HAS_GTK2" = "yes"; then
+if test "$SCIM_HAS_GTK4" = "yes" -a "$SCIM_HAS_GTK3" = "yes" -a
"$SCIM_HAS_GTK2" = "yes"; then
   if test "$WANT_GTK_VERSION" = "2"; then
USE_GTK_VERSION="2"
-  else
+  elif test "$WANT_GTK_VERSION" = "3"; then
USE_GTK_VERSION="3"
+  else
+   USE_GTK_VERSION="4"
   fi
+elif test "$SCIM_HAS_GTK4" = "yes"; then
+  USE_GTK_VERSION="4"
 elif test "$SCIM_HAS_GTK3" = "yes"; then
   USE_GTK_VERSION="3"
 elif test "$SCIM_HAS_GTK2" = "yes"; then
   USE_GTK_VERSION="2"
 fi
 
-if test "$USE_GTK_VERSION" = "3"; then
+if test "$USE_GTK_VERSION" = "4"; then
+  SCIM_HAS_GTK=yes
+  GTK_LIBDIR=$GTK4_LIBDIR
+  GTK_VERSION=$GTK4_VERSION
+  GTK_MAJOR_VERSION=4
+  GTK_BINARY_VERSION=$GTK4_BINARY_VERSION
+  GTK_CFLAGS=$GTK4_CFLAGS
+  GTK_LIBS=$GTK4_LIBS
+  AC_SUBST(GTK_LIBDIR)
+  AC_SUBST(GTK_VERSION)
+  AC_SUBST(GTK_MAJOR_VERSION)
+  AC_SUBST(GTK_BINARY_VERSION)
+  AC_SUBST(GTK_CFLAGS)
+  AC_SUBST(GTK_LIBS)
+elif test "$USE_GTK_VERSION" = "3"; then
   SCIM_HAS_GTK=yes
   GTK_LIBDIR=$GTK3_LIBDIR
   GTK_VERSION=$GTK3_VERSION
@@ -753,7 +814,7 @@
 fi
 
 enable_tray_icon=no
-if test \( "$SCIM_HAS_GTK3"="yes" -o "$SCIM_HAS_GTK2_2" = "yes" \) -a "$no_x"
!= "yes"; then
+if test \( "$SCIM_HAS_GTK4"="yes" -o "$SCIM_HAS_GTK3"="yes" -o
"$SCIM_HAS_GTK2_2" = "yes" \) -a "$no_x" != "yes"; then
   enable_tray_icon=yes
   AC_DEFINE(ENABLE_TRAY_ICON,1,[Enable the TrayIcon code.])
 fi
@@ -818,6 +879,9 @@
 AM_CONDITIONAL(SCIM_BUILD_GTK3_IMMODULE,
 [test "$enable_gtk3_immodule" = "yes"])
 
+AM_CONDITIONAL(SCIM_BUILD_GTK4_IMMODULE,
+[test "$enable_gtk4_immodule" = "yes"])
+
 AM_CONDITIONAL(SCIM_BUILD_QT3_IMMODULE,
 [test "$enable_qt3_immodule" = "yes"])
 
@@ -868,6 +932,7 @@
 AC_SUBST(SCIM_BUILD_IM_AGENT)
 AC_SUBST(SCIM_BUILD_GTK2_IMMODULE)
 AC_SUBST(SCIM_BUILD_GTK3_IMMODULE)
+AC_SUBST(SCIM_BUILD_GTK4_IMMODULE)
 AC_SUBST(SCIM_BUILD_QT3_IMMODULE)
 AC

Bug#1003692: libgupnp-1.2-1: new upstream version

[Jean Felder]

Package: libgupnp-1.2-1
Version: 1.4.1-1
Severity: wishlist

Dear Maintainer,

Upstream released gupnp 1.4.3 which contains several bug fixes.
Could you consider to update the package?

Regards,

Jean Felder


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

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

Versions of packages libgupnp-1.2-1 depends on:
ii  libc6 2.33-2
ii  libglib2.0-0  2.70.2-1
ii  libgssdp-1.2-01.4.0.1-2
ii  libsoup2.4-1  2.74.2-3
ii  libuuid1  2.37.2-6
ii  libxml2   2.9.12+dfsg-5+b1
ii  shared-mime-info  2.0-1

libgupnp-1.2-1 recommends no packages.

libgupnp-1.2-1 suggests no packages.

-- no debconf information

Bug#1003691: scim: Please add GTK4 immodule support

[Boyuan Yang]

Source: scim
Version: 1.4.18-2.2
Severity: normal
Tags: sid  bookworm

Dear package scim maintainers,

With recent upstream activities, GTK4 and Qt5 immmodule support is added in
git HEAD. Please consider backporting these support onto Debian's scim
packages.

Thanks,
Boyuan Yang


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

Bug#1002645: RFS: pass-audit/1.1-1 [ITP] -- Pass extension for auditing your password repository (Python library)

[Antoine Beaupré]

On 2022-01-13 13:37:47, Antoine Beaupré wrote:
> Any reason why you split the package in two binary packages? I don't see
> why the python3-* package would really be useful outside of the
> extension...

Another thing is that I can't build the package here, it seems to fail
on some weird gnupg error in the test suite. Log attached.

other than that, things look somewhat sane. i'm a little worried about
the security of the code, details in private (and sent to upstream on
twitter).

-- 
The idea that Bill Gates has appeared like a knight in shining armour to
lead all customers out of a mire of technological chaos neatly ignores
the fact that it was he who, by peddling second-rate technology, led
them into it in the first place. - Douglas Adams (1952-2001)
sbuild (Debian sbuild) 0.81.2 (31 January 2021) on curie.anarc.at

+==+
| pass-audit 1.1-1 (amd64) Thu, 13 Jan 2022 18:40:21 + |
+==+

Package: pass-audit
Version: 1.1-1
Source Version: 1.1-1
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: full

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-5e166863-e390-427a-9a82-74b7ee9909d6'
 with '<>'
I: NOTICE: Log filtering will replace 'build/pass-audit-GM6x6t/resolver-ZffJKv' 
with '<>'

+--+
| Update chroot|
+--+

Get:1 https://deb.debian.org/debian unstable InRelease [165 kB]
Get:2 https://deb.debian.org/debian unstable/main Sources.diff/Index [63.6 kB]
Get:3 https://deb.debian.org/debian unstable/main amd64 Packages.diff/Index 
[63.6 kB]
Get:4 https://deb.debian.org/debian unstable/main Sources 
T-2022-01-13-1402.41-F-2022-01-13-0804.32.pdiff [17.4 kB]
Get:4 https://deb.debian.org/debian unstable/main Sources 
T-2022-01-13-1402.41-F-2022-01-13-0804.32.pdiff [17.4 kB]
Get:5 https://deb.debian.org/debian unstable/main amd64 Packages 
T-2022-01-13-1402.41-F-2022-01-13-0804.32.pdiff [33.0 kB]
Get:5 https://deb.debian.org/debian unstable/main amd64 Packages 
T-2022-01-13-1402.41-F-2022-01-13-0804.32.pdiff [33.0 kB]
Fetched 343 kB in 5s (62.6 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following packages will be upgraded:
  cpp-11 g++-11 gcc-11 gcc-11-base libasan6 libatomic1 libcc1-0 libgcc-11-dev
  libgcc-s1 libgomp1 libitm1 liblsan0 libquadmath0 libstdc++-11-dev libstdc++6
  libtsan0 libubsan1
17 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 48.7 MB of archives.
After this operation, 47.1 kB disk space will be freed.
Get:1 https://deb.debian.org/debian unstable/main amd64 libcc1-0 amd64 
11.2.0-14 [47.1 kB]
Get:2 https://deb.debian.org/debian unstable/main amd64 libgomp1 amd64 
11.2.0-14 [106 kB]
Get:3 https://deb.debian.org/debian unstable/main amd64 libitm1 amd64 11.2.0-14 
[26.1 kB]
Get:4 https://deb.debian.org/debian unstable/main amd64 libatomic1 amd64 
11.2.0-14 [9044 B]
Get:5 https://deb.debian.org/debian unstable/main amd64 libasan6 amd64 
11.2.0-14 [2050 kB]
Get:6 https://deb.debian.org/debian unstable/main amd64 liblsan0 amd64 
11.2.0-14 [886 kB]
Get:7 https://deb.debian.org/debian unstable/main amd64 libtsan0 amd64 
11.2.0-14 [2016 kB]
Get:8 https://deb.debian.org/debian unstable/main amd64 libubsan1 amd64 
11.2.0-14 [835 kB]
Get:9 https://deb.debian.org/debian unstable/main amd64 libquadmath0 amd64 
11.2.0-14 [144 kB]
Get:10 https://deb.debian.org/debian unstable/main amd64 gcc-11-base amd64 
11.2.0-14 [207 kB]
Get:11 https://deb.debian.org/debian unstable/main amd64 libstdc++6 amd64 
11.2.0-14 [577 kB]
Get:12 https://deb.debian.org/debian unstable/main amd64 g++-11 amd64 11.2.0-14 
[10.2 MB]
Get:13 https://deb.debian.org/debian unstable/main amd64 libstdc++-11-dev amd64 
11.2.0-14 [1979 kB]
Get:14 https://deb.debian.org/debian unstable/main amd64 libgcc-11-dev amd64 
11.2.0-14 [2356 kB]
Get:15 https://deb.debian.org/debian unstable/main amd64 gcc-11 amd64 11.2.0-14 
[18.1 MB]
Get:16 https://deb.debian.org/debian unstable/main amd64 cpp-11 amd64 11.2.0-14 
[9151 kB]
Get:17 https://deb.debian.org/debian unstable/main amd64 libgcc-s1 amd64 
11.2.0-14 [42.0 kB]
debconf: delaying package configuration, since apt-utils is not installed
Fetched 48.7 MB in 4s (13.6 MB/s)
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Rea

Bug#1002645: RFS: pass-audit/1.1-1 [ITP] -- Pass extension for auditing your password repository (Python library)

[Antoine Beaupré]

Any reason why you split the package in two binary packages? I don't see
why the python3-* package would really be useful outside of the
extension...

a.
-- 
Ou bien Dieu voudrait supprimer le mal, mais il ne le peut pas
Ou bien Dieu pourrait supprimer le mal, mais il ne le veut pas.
- Sébastien Faure

Bug#1003688: ITP: fcitx5-sayura -- Fcitx5 wrapper for Sayura IM engine

[Boyuan Yang]

Package: wnpp
Severity: wishlist

* Package name: fcitx5-sayura
  Version : 5.0.4-1
  Upstream Author : CSSlayer 
* URL : https://github.com/fcitx/fcitx5-sayura
* License : GPL-2.0-or-later
  Programming Lang: C++
  Description : Fcitx5 wrapper for Sayura IM engine

 fcitx5-sayura is a wrapper of Sayura IM engine for Fcitx5 IM framework.
 .
 Sayura is a quasi-transliteration scheme for Sinhala script.
 Sayura uses individual Latin characters to signify unmodified consonants.


I plan to maintain this package under Debian Input Method Team:
https://salsa.debian.org/input-method-team/fcitx5-sayura .

Thanks,
Boyuan Yang



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

Bug#1002614: no longer report source-is-missing for binary file in source

[Shengjing Zhu]

Hi

On Fri, Jan 14, 2022 at 2:13 AM Felix Lechner
 wrote:
>
> Did you perhaps disable the cruft check locally with '-X cruft' in
> order to avoid the complications of Bug#993613? [1] That check
> likewise issues source-is-missing. [2]

Oh, that's the cause. I did disable cruft for  993613 some months ago.
But I didn't realize source-is-missing is from cruft too!

Thanks.

-- 
Shengjing Zhu

Bug#1002645: RFS: pass-audit/1.1-1 [ITP] -- Pass extension for auditing your password repository (Python library)

[Antoine Beaupré]

On 2021-12-26 16:07:47, Thomas Perret wrote:
> I am looking for a sponsor for my package "pass-audit". Please note that
> I would like, if possible, a sponsor that could help me in the process
> of becoming a Debian Developer (I'm currently a Debian Maintainer).
> Ideally, this would require reviewing some of my previous work[0], lead
> me in the tasks I should do before applying for DD and advocate for me
> in this process.

Hi,

I'm not sure I have the cycles to review your previous work (and btw the
[0] reference seems to be missing), but I am really interested in this
package so I'll do a quick audit of the code and review of your work and
report back here shortly.

a.

-- 
Use for yourself little but give to others much.
   - Albert Einstein

Bug#1003686: CVE-2021-4122: cryptsetup 2.x: decryption through LUKS2 reencryption crash recovery

[Guilhem Moulin]

Source: cryptsetup
Severity: grave
Tags: security upstream
Justification: root security hole
Control: found -1 2:2.3.5-1
Control: found -1 2:2.4.2-1
X-Debbugs-Cc: Debian Security Team 

Quoting :

| CVE-2021-4122 describes a possible attack against data confidentiality
| through LUKS2 online reencryption extension crash recovery.
| 
| An attacker can modify on-disk metadata to simulate decryption in
| progress with crashed (unfinished) reencryption step and persistently
| decrypt part of the LUKS device.
| 
| This attack requires repeated physical access to the LUKS device but
| no knowledge of user passphrases.
| 
| The decryption step is performed after a valid user activates
| the device with a correct passphrase and modified metadata.
| There are no visible warnings for the user that such recovery happened
| (except using the luksDump command). The attack can also be reversed
| afterward (simulating crashed encryption from a plaintext) with
| possible modification of revealed plaintext.
| […]
| The issue was found by Milan Broz as cryptsetup maintainer.

Upstream fixes:

  2.3 branch: 
https://gitlab.com/cryptsetup/cryptsetup/-/commit/60addcffa6794c29dccf33d8db5347f24b75f2fc
  2.4 branch: 
https://gitlab.com/cryptsetup/cryptsetup/-/commit/de98f011418c62e7b825a8ce3256e8fcdc84756e

Buster and earlier are not affected since their respective
(lib)cryptsetup don't support LUKS2 online reencryption.  I'll provide a
debdiff for bullseye-security.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1003687: python-pip breaks python-virtualenv autopkgtest: invalid syntax

[Paul Gevers]

Source: python-pip, python-virtualenv
Control: found -1 python-pip/21.3.1+dfsg-3
Control: found -1 python-virtualenv/20.12.1+ds-1
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of python-pip the autopkgtest of python-virtualenv 
fails in testing when that autopkgtest is run with the binary packages 
of python-pip from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
python-pip from testing21.3.1+dfsg-3
python-virtualenv  from testing20.12.1+ds-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of python-pip to 
testing [1]. Due to the nature of this issue, I filed this bug report 
against both packages. Can you please investigate the situation and 
reassign the bug to the right package?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=python-pip

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-virtualenv/18277593/log.gz

created virtual environment CPython2.7.18.final.0-64 in 446ms
  creator 
CPython2Posix(dest=/tmp/autopkgtest-lxc.tsxq3czm/downtmp/autopkgtest_tmp/ve, 
clear=False, no_vcs_ignore=False, global=False)
  seeder FromAppData(download=False, pip=bundle, setuptools=bundle, 
wheel=bundle, via=copy, 
app_data_dir=/tmp/autopkgtest-lxc.tsxq3czm/downtmp/autopkgtest_tmp/home/.local/share/virtualenv)
added seed packages: pip==21.3.1, pkg_resources==0.0.0, 
setuptools==59.6.0, wheel==0.34.2
  activators 
BashActivator,CShellActivator,FishActivator,NushellActivator,PowerShellActivator,PythonActivator

created virtual environment CPython2.7.18.final.0-64 in 185ms
  creator 
CPython2Posix(dest=/tmp/autopkgtest-lxc.tsxq3czm/downtmp/autopkgtest_tmp/sysve, 
clear=False, no_vcs_ignore=False, global=True)
  seeder FromAppData(download=False, pip=bundle, setuptools=bundle, 
wheel=bundle, via=copy, 
app_data_dir=/tmp/autopkgtest-lxc.tsxq3czm/downtmp/autopkgtest_tmp/home/.local/share/virtualenv)
added seed packages: pip==21.3.1, pkg_resources==0.0.0, 
setuptools==59.6.0, wheel==0.34.2
  activators 
BashActivator,CShellActivator,FishActivator,NushellActivator,PowerShellActivator,PythonActivator

testMPipHelp
Traceback (most recent call last):
  File "/usr/lib/python2.7/runpy.py", line 163, in _run_module_as_main
mod_name, _Error)
  File "/usr/lib/python2.7/runpy.py", line 111, in _get_module_details
__import__(mod_name)  # Do not catch exceptions initializing package
  File 
"/tmp/autopkgtest-lxc.tsxq3czm/downtmp/autopkgtest_tmp/ve/lib/python2.7/site-packages/pip/__init__.py", 
line 6

def main(args: Optional[List[str]] = None) -> int:
 ^
SyntaxError: invalid syntax
ASSERT:Execute bare pip
testSystemPackagesNotAvailable
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named six
Traceback (most recent call last):
  File "/usr/lib/python2.7/runpy.py", line 163, in _run_module_as_main
mod_name, _Error)
  File "/usr/lib/python2.7/runpy.py", line 111, in _get_module_details
__import__(mod_name)  # Do not catch exceptions initializing package
  File 
"/tmp/autopkgtest-lxc.tsxq3czm/downtmp/autopkgtest_tmp/ve/lib/python2.7/site-packages/pip/__init__.py", 
line 6

def main(args: Optional[List[str]] = None) -> int:
 ^
SyntaxError: invalid syntax
testSystemPackagesAvailable
Traceback (most recent call last):
  File "/usr/lib/python2.7/runpy.py", line 163, in _run_module_as_main
mod_name, _Error)
  File "/usr/lib/python2.7/runpy.py", line 111, in _get_module_details
__import__(mod_name)  # Do not catch exceptions initializing package
  File 
"/tmp/autopkgtest-lxc.tsxq3czm/downtmp/autopkgtest_tmp/sysve/lib/python2.7/site-packages/pip/__init__.py", 
line 6

def main(args: Optional[List[str]] = None) -> int:
 ^
SyntaxError: invalid syntax
ASSERT:pip freeze lists system module from system-site-packages VE
testSetuptoolsAvailable
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/tmp/autopkgtest-lxc.tsxq3czm/downtmp/autopkgtest_tmp/ve/lib/python2.7/site-packages/setuptools/__init__.py", 
line 16, in 

import setuptools.version
  File 
"/tmp/autopkgtest-lxc.tsxq3czm/downtmp/autopkgtest_tmp/ve/lib/python2.7/site-packages/setuptools/version.py", 
line 1, in 

import pkg_resources
  File 
"/tmp/autopkgtest-lxc.tsxq3czm/downtmp/autopkgtest_tmp/ve/lib/python2.7/site-packages/pkg_resources/__init__.py", 
line 117

f"{v} is an invalid version and will not be supported in "
 ^
SyntaxError: invalid syntax
ASSERT:Import 

Bug#1003617: libpam-runtime: When upgrading to libpam-runtime_1.4.0-11 pam_ssh is broken

[Steve Langasek]

Control: reassign -1 libpam-ssh
Control: affects -1 src:pam
Control: tags -1 - moreinfo unreproducible

On Thu, Jan 13, 2022 at 10:31:31AM +0100, Vincent-Xavier JUMEL wrote:
> The steps are :

> I've quickly reproduce the bug. You can follow these steps :
> 1. install debian stable in a vm
> 2. install libpam-ssh
> 3. upgrade it to debian sid

Ok, this is also reproducible by directly installing the unstable version of
the libpam-ssh package.  (I had attempted to do this before but missed that
my sources were out of date, so I was installing the stable version.)

/usr/share/pam-config/ssh-pwd declares an 'Additional' module and uses
'success=end'.  This is undefined behavior in pam-auth-update, which only
defines 'success=end' for 'Primary' module configs.

The pam package could potentially improve handling of this undefined
behavior, but in this case it's primarily a bug in libpam-ssh shipping a
broken config.

> Le 13 janv. à 10:06 Vincent-Xavier JUMEL a écrit
> > Hello,
> > 
> > I've quickly reproduce the bug. You can follow these steps :
> > 1. install debian stable in a vm
> > 2. upgrade it to debian sid
> > 
> > The mentionned line appears then in the /etc/pam.d/common-auth file
> > 
> > Le 13 janv. à 00:18 Steve Langasek a écrit
> > > Control: tags -1 moreinfo unreproducible
> > > 
> > > On Wed, Jan 12, 2022 at 06:28:45PM +0100, Vincent-Xavier JUMEL wrote:
> > > > Package: libpam-runtime
> > > > Version: 1.4.0-11
> > > > Severity: critical
> > > > Justification: breaks the whole system
> > > 
> > > > Dear Maintainer,
> > > > 
> > > >* Upgrade to the unstable version of libpam-runtime_1.14.0_11_all
> > > >with 
> > > >```
> > > >auth[success=0 default=ignore]  pam_ssh.so use_first_pass
> > > >```
> > > >* Login then failed
> > > >* I've modified "success=0" -> "success=1" to get back the login.
> > > 
> > > So where does this 'success=0' come from?  It doesn't come from
> > > /usr/share/pam-configs/ssh.  Installing libpam-ssh in unstable does not
> > > result in a config containing this line.  I'm not sure 'success=0' is 
> > > valid,
> > > and if it is, it means 'on success, process the next module' so your bug
> > > report, by slicing your config file to only show the single pam_ssh line,
> > > does not show what happens afterward that actually fails the stack.
> > > 
> > > -- 
> > > 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
> > 
> > 
> > 
> > -- 
> > Vincent-Xavier JUMEL Id: 0xBC8C2BAB14ABB3F2 https://blog.thetys-retz.net
> > 
> > Société Libre, Logiciel Libre http://www.april.org/adherer
> > Parinux, logiciel libre à Paris : http://www.parinux.org
> 
> -- 
> Vincent-Xavier JUMEL Id: 0xBC8C2BAB14ABB3F2 https://blog.thetys-retz.net
> 
> Société Libre, Logiciel Libre http://www.april.org/adherer
> Parinux, logiciel libre à Paris : http://www.parinux.org
> 

-- 
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


signature.asc
Description: PGP signature

Bug#1003685: cryptsetup: CVE-2021-4122

[Christoph Anton Mitterer]

Package: cryptsetup
Version: 2:2.4.2-1
Severity: critical
Tags: security upstream
Justification: root security hole


Hey.

You've probably seen it already... Milan found CVE-2021-4122, and
the package should be upgraded to 2.4.3 ASAP.

Thanks in advance,
Chris.

Bug#973570: fzf: keybinding files should be installed under /etc

[Tomas Janousek]

Hi,

On Fri, Jun 18, 2021 at 02:30:03PM +1000, Jai Flack wrote:

On Sun, 21 Feb 2021 17:11:28 +0100 Jonas Smedegaard  wrote:

Debian Policy §12.6 says that /usr/share/doc/*/examples/ is "for the
benefit of the system administrator and users as documentation only."

Notice the final part of "documentation only".


That is a good point; as they are intended for use I'll move them out of
doc/. This is also good opportinity to install the bash completions by
default and maybe the Vim plugin if it's not too intrusive.


It's worth noting that completion of command-line arguments of fzf 
itself is only a secondary purpose of 
/usr/share/bash-completion/completions/fzf, the primary purpose being 
augmenting completion of other commands to use fzf, as described here: 
https://github.com/junegunn/fzf#fuzzy-completion-for-bash-and-zsh


This primary purpose, however, isn't active via the bash-completion 
autoloading. As things currently stand, it only becomes active after one 
types fzf a presses Tab, which is probably not a good experience. So I 
believe the note in /usr/share/doc/fzf/README.Debian about the 
completion being installed by default is incorrect, and should be 
reverted and the path corrected to 
/usr/share/bash-completion/completions/fzf (rather than 
/usr/share/doc/fzf/examples/completion.bash, which is still in 
README.Debian).


Alternatively, the file can be installed into /etc/bash_completion.d, 
which is the compat (no autoload) dir for old-style bash-completion 
modules, so it will indeed get loaded unconditionally. I'd personally 
prefer the former solution, though.


--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/

Bug#1003684: double-conversion: autopkgtest regression on i386: ./run_tests: terminated by signal 6

[Paul Gevers]

Source: double-conversion
Version: 3.1.7-3
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of double-conversion the autopkgtest of 
double-conversion fails in testing when that autopkgtest is run with the 
binary packages of double-conversion from unstable on i386. It passes 
when run with only packages from testing. In tabular form:


   passfail
double-conversion  from testing3.1.7-3
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=double-conversion

https://ci.debian.net/data/autopkgtest/testing/i386/d/double-conversion/1826/log.gz

CXX test/cctest/test-fixed-dtoa.cc
CXX test/cctest/test-conversions.cc
CXX test/cctest/test-diy-fp.cc
CXX test/cctest/cctest.cc
CXX test/cctest/gay-shortest-single.cc
CXX test/cctest/gay-precision.cc
CXX test/cctest/gay-shortest.cc
CXX test/cctest/test-ieee.cc
CXX test/cctest/test-fast-dtoa.cc
CXX test/cctest/gay-fixed.cc
CXX test/cctest/test-strtod.cc
CXX test/cctest/test-bignum.cc
CXX test/cctest/test-dtoa.cc
CXX test/cctest/test-bignum-dtoa.cc
LD run_tests
xargs: ./run_tests: terminated by signal 6
autopkgtest [11:10:53]: test unittest.sh



OpenPGP_signature
Description: OpenPGP digital signature

Bug#725761: RFP: libervia-web -- web frontend for Libervia

[Martin]

Control: retitle -1 RFP: libervia-web -- web frontend for Libervia

The Salut à Toi project has been renamed to Libervia.
The former web frontend libervia has been renamed to libervia-web.

Bug#1003683: RFP: mob -- Smooth git handover for remote pair/mob programming.

[Antoine Beaupre]

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

* Package name: mob
  Version : 2.2.1
  Upstream Author : Dr. Simon Harrer
* URL : https://mob.sh/
* License : MIT
  Programming Lang: Golang
  Description : Smooth git handover for remote pair/mob programming.

mob is an open source command line tool written in go to hand over
code via git to other pair-programming partners. it keeps your
branches clean and only creates WIP commits on temporary branches



Not sure there's anything equivalent in Debian, but there are also
alternative packages that do similar things out there:

https://github.com/google/git-sync-changes
https://github.com/tkellogg/dura

i picked this one because it's specifically geared towards collaboration.

Bug#975055: Patch for 4.3-22

[tony mancill]

On Tue, Jan 11, 2022 at 09:43:28PM -0800, tony mancill wrote:
> On Tue, Jan 11, 2022 at 09:51:55AM +, Vincent G. wrote:
> > Hi,
> > Here is the patch for 4.3-22.
> > Regards,
> 
> Hello Vincent,
> 
> Thank you for the updated patch.  I intend to add some autopkgtests to
> bsdiff and then will apply the patch and upload.

Hi Vincent,

The upload of 4.3-23 updates the packaging and adds an autopkgtest.  It
doesn't include any changes to the sources, so you don't need to rework
the patch.

However, I'd like to ask whether you have reached out to upstream
regarding the mmap() improvement.  It would be preferable to get this
folded into the upstream release.  That makes it easier for us to assess
CVEs, etc.

Would you be willing to initiate a conversation with the upstream author
regarding the patch?

Thanks,
tony


signature.asc
Description: PGP signature

Bug#1003612: RFS: libview/0.6.6-3 [ITA] -- VMware's Incredibly Exciting Widgets

[Bastian Germann]

On Wed, 12 Jan 2022 16:04:57 + Ileana Dumitrescu 
 wrote:

Changes since the last upload:

 libview (0.6.6-3) unstable; urgency=medium
 .
   [ Ileana Dumitrescu ]
 .
   * New maintainer (Closes: #674884)
   * debian/control: Updated to dh version 13
   * debian/copyright: Updated to dep5 version 1.0 format
   * debian/compat: Removed to update dh version
   * debian/rules: Updated to use dh $@ and run on all architectures
   (Closes: #727446, #744625, #976498)


Does this close #998924 as well? If not, there is no point to upload this.


 .
   [ Andreas Moog ]
 .
   * debian/patches: Added patch to fix libview.pc (Closes: #650253)


Please consider writing an answer to #956789 on why you think this package 
should be kept around.

Bug#1003641: systemd-oomd.service already active, refusing

[Felipe Sateler]

On Thu, Jan 13, 2022 at 10:03 AM Michael Biebl  wrote:

> Am 13.01.22 um 08:36 schrieb Jérémy Lal:
> > Package: systemd-oomd
> > Version: 250.2-2
> > Severity: normal
> >
> > Hi,
> >
> > i've installed systemd-oomd 250.2-1 and on upgrade,
> > noticed this:
> >
> > systemd-oomd.socket: Socket service systemd-oomd.service already active,
> refusing.
> > Failed to listen on Userspace Out-Of-Memory (OOM) Killer Socket.
> >
> > I'm not sure what should be done. Stop the service, disable the socket ?
>
>
> The behaviour of dh_installsystemd is to treat systemd-oomd.service and
> systemd-oomd.socket as completely separate services.
> So it generates code for both units to enable/disable and restart those
> units (more or less independently).
>
> You can't really restart a socket unit though which is bound to a
> running service.
>
> What you see is basically a duplicate of
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955483
>
> We don't have a good answer here. This probably needs support from
> upstream as well.
>
> As a workaround, we could probably drop the restart/start of
> systemd-oomd.socket and only keep the enable/disable/stop-on-removal bits.
>
> For that we'd need separate calls to the dh_installsystemd override. One
> for systemd-oomd.service and one for systemd-oomd.socket.
>
> This is untested:
>
> override_dh_installsystemd:
> ...
> dh_installsystemd -Psystemd-oomd systemd-oomd.service
> dh_installsystemd -Psystemd-oomd --no-start --no-stop-on-upgrade
> systemd-oomd.socket
>
> (not quite sure if we need --no-restart-after-upgrade as well).
>
> This has the downside that the socket is no longer restarted on
> upgrades, so changes to the socket unit are not applied.
> It has the upside, that it doesn't interfere with the currently running
> .service unit.
>
> Ideally, this would be handled better by systemctl and/or debhelper by
> knowing that those units belong together and restarting them in the
> correct order.
>
>
I believe the ultimate fix is to actually fix
https://github.com/systemd/systemd/issues/8102 upstream. AFAICT, that would
resolve everything?


> Balint had some thoughts in #955483, but nothing really happened since then
>
>
>
>
>

-- 

Saludos,
Felipe Sateler

Bug#1003468: dynarmic: FTBFS with fmtlib/8.1.1 - fix in mentors

[Shengjing Zhu]

Hi,

On Thu, Jan 13, 2022 at 6:25 PM Andrea Pappacoda  wrote:
>
> Hi, thank you for letting me know. I've uploaded the fixed package to
> Mentors. Usually Bastian Germann (bage) takes a look at my packages
> there and uploads them if they are ok, but if you want the fixed
> version uploaded as soon as possible you could upload it yourself :)
>
> You can find the package here:
> https://mentors.debian.net/package/dynarmic/
>
>

Thanks for the update. I will take a look.

The VCS repo https://salsa.debian.org/tachi/dynarmic is 404 for me.
Maybe you have set it to private?
It would be much easier for me to review the changes in VCS to sponsor.

-- 
Shengjing Zhu

Bug#674884: ITA: libview -- VMware's Incredibly Exciting Widgets

[Bastian Germann]

Control: retitle -1 ITA: libview -- VMware's Incredibly Exciting Widgets
Control: owner -1 Ileana Dumitrescu 

On Wed, 12 Jan 2022 15:56:57 + Ileana Dumitrescu 
 wrote:

I intend to adopt the orphaned package libview.

Ileana Dumitrescu

Bug#976811: transition: php8.1

[Mike Gabriel]

Hi Paul,

On  Do 13 Jan 2022 14:55:40 CET, Paul Gevers wrote:


Dear horde maintainers, Mike,

On 05-12-2021 22:11, Paul Gevers wrote:
Bugs have been filed (with the exception of the horde stack, but  
they are aware) of items we're aware of. Let's give the maintainers  
a month. I propose we can start the php8.1 transition around  
Christmas 2021. Does that work for you Ondřej?


You will probably have noticed that the transition started and that  
I filed a bunch of bugs against php-horde-* packages about their  
failing autopkgtests. I'll stop filing more for now, to not flood  
your mail boxes, but I would like a response from your side about  
what your plan is with the horde packages and the php8.1 transition.


To progress the transition, I plan to "ignore" the autopkgtest  
failures that are merely due to deprecation warnings, but
1) I expect these deprecation warnings to end up in journals/logs,  
so they may flood them excessively
2) failing autopkgtests are (and remain) RC issues in testing but  
I'm willing to tolerate it for some time if you elaborate on the way  
forward and it makes sense.


I think it's necessary to either *fix* the issue, or suppress the  
deprecation warnings in the horde packages. Just ignoring them in  
the autopkgtests is probably the worse outcome.


Paul


I plan to fix those, but I can't see light at the end of customer  
project tunnels these days. So it might not be as promptly as required.


Mike
--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpP3msAAj6UL.pgp
Description: Digitale PGP-Signatur

Bug#1003680: [Pkg-javascript-devel] Bug#1003680: libjs-jquery-ui: ABI of jquery-ui.[min.].js changed in 1.13

[Yadd]

On 13/01/2022 16:18, Gordon Ball wrote:

Package: libjs-jquery-ui
Version: 1.13.0+dfsg-1
Severity: important
X-Debbugs-Cc: gor...@chronitis.net

When updating from 1.12.1 to 1.13.0, the ABI of the dist files
/usr/share/javascript/jquery-ui/jquery-ui[.min].js appears to have
changed.

In 1.12, it contained a single factory function which loaded the entire
library as a `define()` or global: `define([ "jquery" ], factory );`

In 1.13, it contains one factory function per source file in the
distribution, eg `define( 'ui/version.js',[ "jquery" ], factory );`

This does not match what you get using the jqueryui downloader, nor does
it match the reference file in the salsa jqueryui repository
(debian/reference-jquery-ui.js), which has an ABI like that seen in
1.12.

This change in ABI breaks jupyter-notebook.


Hi,

libjs-jquery-ui doesn't change upstream libraries, it just use uglifyjs 
to build minified files. Could you test with unminified files to be sure 
that the problem isn't in our side ?


Cheers,
Yadd

Bug#1003680: [Pkg-javascript-devel] Bug#1003680: libjs-jquery-ui: ABI of jquery-ui.[min.].js changed in 1.13

[Yadd]

On 13/01/2022 16:30, Yadd wrote:

On 13/01/2022 16:18, Gordon Ball wrote:

Package: libjs-jquery-ui
Version: 1.13.0+dfsg-1
Severity: important
X-Debbugs-Cc: gor...@chronitis.net

When updating from 1.12.1 to 1.13.0, the ABI of the dist files
/usr/share/javascript/jquery-ui/jquery-ui[.min].js appears to have
changed.

In 1.12, it contained a single factory function which loaded the entire
library as a `define()` or global: `define([ "jquery" ], factory );`

In 1.13, it contains one factory function per source file in the
distribution, eg `define( 'ui/version.js',[ "jquery" ], factory );`

This does not match what you get using the jqueryui downloader, nor does
it match the reference file in the salsa jqueryui repository
(debian/reference-jquery-ui.js), which has an ABI like that seen in
1.12.

This change in ABI breaks jupyter-notebook.


Hi,

libjs-jquery-ui doesn't change upstream libraries, it just use uglifyjs 
to build minified files. Could you test with unminified files to be sure 
that the problem isn't in our side ?


Oups, I'm wrong here. debian/rules launches grunt

Bug#907576: Salsa Access Project 7803

[Christoph Berg]

Re: GMiller
> Sorry. I didn't know it would do that just for archiving an old project. I 
> believe you are an admin. Could you restore me as member on 7803? Of course 
> keep my accounts open as might do some new projects if I ever get Dream done.

Done that, hopefully on the correct project with your correct account
name :)

> By the way, I have succeeded in getting Dream to compile and install locally 
> per Debian procedures. It still fails in run time due to a PulseAudio 
> problem. So that task is next. Upstream is aware.

Nice!

Christoph

Bug#1003680: libjs-jquery-ui: ABI of jquery-ui.[min.].js changed in 1.13

[Gordon Ball]

Package: libjs-jquery-ui
Version: 1.13.0+dfsg-1
Severity: important
X-Debbugs-Cc: gor...@chronitis.net

When updating from 1.12.1 to 1.13.0, the ABI of the dist files
/usr/share/javascript/jquery-ui/jquery-ui[.min].js appears to have
changed.

In 1.12, it contained a single factory function which loaded the entire
library as a `define()` or global: `define([ "jquery" ], factory );`

In 1.13, it contains one factory function per source file in the
distribution, eg `define( 'ui/version.js',[ "jquery" ], factory );`

This does not match what you get using the jqueryui downloader, nor does
it match the reference file in the salsa jqueryui repository
(debian/reference-jquery-ui.js), which has an ABI like that seen in
1.12.

This change in ABI breaks jupyter-notebook.


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

Kernel: Linux 5.15.0-2-amd64 (SMP w/1 CPU thread)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libjs-jquery-ui depends on:
ii  libjs-jquery  3.5.1+dfsg+~3.5.5-8

Versions of packages libjs-jquery-ui recommends:
ii  javascript-common  11+nmu1

Versions of packages libjs-jquery-ui suggests:
pn  libjs-jquery-ui-docs  

-- no debconf information

Bug#1003681: ITP: inotify-simple -- Simple Python wrapper around inotify

[Mechtilde Stehmann]

Package: wnpp
Severity: wishlist
Owner: Mechtilde Stehmann 
X-Debbugs-Cc: Debian Python Team , 
mechti...@debian.org

* Package name: python3-inotify-simple
  Version : 1.3.5
  Upstream Author : Chris Billington
* URL : https://github.com/chrisjbillington/inotify_simple
* License : BSD-2-clause
  Programming Lang: Python
  Description : Simple Python wrapper around inotify

It is a dependency of paperless (RFP #986227)

I want to package it inside the python-team

Bug#1003606: closed by Debian FTP Masters (reply to Martina Ferrari ) (Bug#1003606: fixed in python-flask-httpauth 4.5.0-2)

[Martina Ferrari]

Hi Andreas,

On 13/01/2022 12:51, Andreas Beckmann wrote:


you reinstated
   Breaks+Replaces: python-flask-httpauth (<< 3.2.4-1)
in the -doc package, which is actually no longer needed since the 
python2 package is gone.


OUCH, I guess I completely misread your report. Sorry, I hadn't slept 
well! :(


This B+R probably stems from the time when the man page was moved to 
-doc in oder to make the python2 and python3 packages co-installable and 
using alternatives (pure guess, many packages did it this way when 
adding python3 support).


Yes, AFAIR that was the reason.


As I said in the Subject, python3-flask-httpauth needs
   Breaks+Replaces: python-flask-httpauth-doc (<< 4)
So it's the other way around and in the python3 package this time for 
moving the man page back to the package containing /usr/bin/flask-httpauth.


WAIT, there is a flask-httpauth(1) manpage, but I cannot find the 
corresponding command anywhere. And the man page is actually not for a 
command, so it should not be in section 1. I'm not sure where it 
belongs, though (perhaps section 3 or 7).
So just move the manpage to the correct section and forget about 
Breaks+Replaces ;-)


Ah, good point. That man page is generated from the sphinx 
documentation. It was originally in the doc package, but I thought it 
made more sense in the main package. Will do the rename as you suggest, 
I think section 3 is the right place.


Thanks again.

--
Martina Ferrari (Tina)

Bug#1003168: qemu-user-static: fails to run lyx user directory configuation

[Andreas Beckmann]

On 11/01/2022 08.25, Michael Tokarev wrote:

1. try qemu 6.2 (qemu-user-static is self-contained, more or less, so
    it can be installed on earlier debian releases too)


same behavior :-(


2. try to figure out what exactly is failing in there:

support/Systemcall.cpp (276): Systemcall: 'python3 -tt 
"/usr/share/lyx/configure.py" --binary-dir="/usr/bin/"' finished with 
exit code -1


# t=$(mktemp -d) && cd $t && python3 -tt "/usr/share/lyx/configure.py" 
--binary-dir="/usr/bin/" ; cd -

Succeeds :-(

But if that command gets executed from lyx, we are in the realm of Qt::Process.
Perhaps if I find time, I can try to extract a minimized example only doing 
that call...


Andreas

Bug#1003679: cryfs: autopkgtest regression on armhf: Resource temporarily unavailable

[Paul Gevers]

Source: cryfs
Version: 0.11.1-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of cryfs the autopkgtest of cryfs fails in testing 
when that autopkgtest is run with the binary packages of cryfs from 
unstable. It passes when run with only packages from testing. In tabular 
form:


   passfail
cryfs  from testing0.11.1-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=cryfs

https://ci.debian.net/data/autopkgtest/testing/armhf/c/cryfs/18257610/log.gz


[--] 4 tests from QueueMapTest_MoveConstructor
[ RUN  ] QueueMapTest_MoveConstructor.PushingAndPopping_MoveIntoMap
[   OK ] QueueMapTest_MoveConstructor.PushingAndPopping_MoveIntoMap 
(0 ms)
[ RUN  ] 
QueueMapTest_MoveConstructor.PushingAndPoppingPerKey_MoveIntoMap
[   OK ] 
QueueMapTest_MoveConstructor.PushingAndPoppingPerKey_MoveIntoMap (0 ms)

[ RUN  ] QueueMapTest_MoveConstructor.PushingAndPopping_CopyIntoMap
[   OK ] QueueMapTest_MoveConstructor.PushingAndPopping_CopyIntoMap 
(0 ms)
[ RUN  ] 
QueueMapTest_MoveConstructor.PushingAndPoppingPerKey_CopyIntoMap
[   OK ] 
QueueMapTest_MoveConstructor.PushingAndPoppingPerKey_CopyIntoMap (0 ms)

[--] 4 tests from QueueMapTest_MoveConstructor (0 ms total)

[--] 12 tests from QueueMapTest_MemoryLeak
[ RUN  ] QueueMapTest_MemoryLeak.Empty
[   OK ] QueueMapTest_MemoryLeak.Empty (0 ms)
[ RUN  ] QueueMapTest_MemoryLeak.AfterPushingOne
[   OK ] QueueMapTest_MemoryLeak.AfterPushingOne (0 ms)
[ RUN  ] QueueMapTest_MemoryLeak.AfterPushingTwo
[   OK ] QueueMapTest_MemoryLeak.AfterPushingTwo (0 ms)
[ RUN  ] QueueMapTest_MemoryLeak.AfterPushingTwoAndPoppingOldest
[   OK ] QueueMapTest_MemoryLeak.AfterPushingTwoAndPoppingOldest (0 ms)
[ RUN  ] QueueMapTest_MemoryLeak.AfterPushingTwoAndPoppingFirst
[   OK ] QueueMapTest_MemoryLeak.AfterPushingTwoAndPoppingFirst (0 ms)
[ RUN  ] QueueMapTest_MemoryLeak.AfterPushingTwoAndPoppingLast
[   OK ] QueueMapTest_MemoryLeak.AfterPushingTwoAndPoppingLast (0 ms)
[ RUN  ] QueueMapTest_MemoryLeak.AfterPushingOnePoppingOne
[   OK ] QueueMapTest_MemoryLeak.AfterPushingOnePoppingOne (0 ms)
[ RUN  ] QueueMapTest_MemoryLeak.AfterPushingOnePoppingOnePerKey
[   OK ] QueueMapTest_MemoryLeak.AfterPushingOnePoppingOnePerKey (0 ms)
[ RUN  ] QueueMapTest_MemoryLeak.AfterPushingOnePoppingOnePushingOne
[   OK ] QueueMapTest_MemoryLeak.AfterPushingOnePoppingOnePushingOne 
(0 ms)
[ RUN  ] 
QueueMapTest_MemoryLeak.AfterPushingOnePoppingOnePerKeyPushingOne
[   OK ] 
QueueMapTest_MemoryLeak.AfterPushingOnePoppingOnePerKeyPushingOne (0 ms)

[ RUN  ] QueueMapTest_MemoryLeak.AfterPushingOnePoppingOnePushingSame
[   OK ] 
QueueMapTest_MemoryLeak.AfterPushingOnePoppingOnePushingSame (0 ms)
[ RUN  ] 
QueueMapTest_MemoryLeak.AfterPushingOnePoppingOnePerKeyPushingSame
[   OK ] 
QueueMapTest_MemoryLeak.AfterPushingOnePoppingOnePerKeyPushingSame (0 ms)

[--] 12 tests from QueueMapTest_MemoryLeak (1 ms total)

[--] 4 tests from CacheTest_RaceCondition
[ RUN  ] 
CacheTest_RaceCondition.PopBlocksWhileRequestedElementIsThrownOut_ByAge
[   OK ] 
CacheTest_RaceCondition.PopBlocksWhileRequestedElementIsThrownOut_ByAge 
(1543 ms)
[ RUN  ] 
CacheTest_RaceCondition.PopDoesntBlockWhileOtherElementIsThrownOut_ByAge

terminate called after throwing an instance of 'std::system_error'
  what():  Resource temporarily unavailable
Aborted
autopkgtest [06:35:46]: test blockstore



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003678: sqlite3 breaks crowdsec autopkgtest: invalid type \"INTEGER\" for column

[Paul Gevers]

Source: sqlite3, crowdsec
Control: found -1 sqlite3/3.37.2-1
Control: found -1 crowdsec/1.0.9-3
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of sqlite3 the autopkgtest of crowdsec fails in 
testing when that autopkgtest is run with the binary packages of sqlite3 
from unstable. It passes when run with only packages from testing. In 
tabular form:


   passfail
sqlite3from testing3.37.2-1
crowdsec   from testing1.0.9-3
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of sqlite3 to 
testing [1]. Due to the nature of this issue, I filed this bug report 
against both packages. Can you please investigate the situation and 
reassign the bug to the right package?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] You can see what packages were added from the second line of the log 
file quoted below. The migration software adds source package from 
unstable to the list if they are needed to install packages from 
sqlite3/3.37.2-1. I.e. due to versioned dependencies or breaks/conflicts.

[1] https://qa.debian.org/excuses.php?package=sqlite3

https://ci.debian.net/data/autopkgtest/testing/amd64/c/crowdsec/18271072/log.gz

=== RUN   TestSimulatedAlert
time="2022-01-12T20:11:40Z" level=info msg="Creating new API server"
 - [Wed, 12 Jan 2022 20:11:41 UTC] "POST /v1/watchers HTTP/1.1 201 
98.133294ms "crowdsec-test/" "
time="2022-01-12T20:11:41Z" level=fatal msg="unable to create new 
database client: failed creating schema resources: sql/schema: invalid 
type \"INTEGER\" for column \"events_count\""

FAILgithub.com/crowdsecurity/crowdsec/pkg/apiserver 0.130s
?   	github.com/crowdsecurity/crowdsec/pkg/apiserver/controllers	[no 
test files]
?   	github.com/crowdsecurity/crowdsec/pkg/apiserver/controllers/v1	[no 
test files]
?   	github.com/crowdsecurity/crowdsec/pkg/apiserver/middlewares/v1	[no 
test files]


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003677: Inadyn init scripts uses deprecated options & configuration template use deprecated format. Daemon can not start.

[vasilis g]

Package: inadyn

Version: 2.8.1-1



Inadyn has undergone some refactorings but the debian package has not
updated init scripts and configuration templates.

Namely daemon can not start because of deprecated arg in init script


journalctl -u inadyn -e
Jan 11 12:16:35 x inadyn[579096]: Starting DynDNS client : inadyn
Jan 11 12:16:35 x inadyn[579104]: /usr/bin/inadyn: unrecognized option
'--background'
Jan 11 12:16:35 x inadyn[579104]: Usage:



In adition the default configuration template has to be updated as per
the manual

For example  the following template block from /etc/inadyn.conf

system 
  # Please uncomment the following option if your DynDNS provider
supports HTTPS
  # ssl
  # Your username
  username 
  # Your password


has to be changed to

provider  {

  username = 
  password = 
}

as per  the man inadyn.conf says.


Kind regards

V.G.

Bug#1003676: The Build-Depends on libfuse-dev isn't needed

[Sebastien Bacher]

Package: ntfs-3g
Version: 1:2021.8.22-3

The package currently Build-Depends on libfuse-dev but that isn't useful 
since it's built using --with-fuse=internal. The attached patch removed 
the corresponding entry


Cheers,
diff -Nru ntfs-3g-2021.8.22/debian/changelog ntfs-3g-2021.8.22/debian/changelog
--- ntfs-3g-2021.8.22/debian/changelog	2021-10-10 19:59:33.0 +0200
+++ ntfs-3g-2021.8.22/debian/changelog	2022-01-13 15:23:39.0 +0100
@@ -1,3 +1,11 @@
+ntfs-3g (1:2021.8.22-4) UNRELEASED; urgency=medium
+
+  * debian/control:
+- don't Build-Depends on libfuse-dev since the package is built using
+  the --with-fuse=internal option
+
+ -- Sebastien Bacher   Thu, 13 Jan 2022 15:23:39 +0100
+
 ntfs-3g (1:2021.8.22-3) unstable; urgency=medium
 
   * Backport upstream documentation updates.
diff -Nru ntfs-3g-2021.8.22/debian/control ntfs-3g-2021.8.22/debian/control
--- ntfs-3g-2021.8.22/debian/control	2021-10-10 19:59:33.0 +0200
+++ ntfs-3g-2021.8.22/debian/control	2022-01-13 15:23:39.0 +0100
@@ -5,7 +5,6 @@
 Build-Depends:
  debhelper-compat (= 13),
  chrpath,
- libfuse-dev,
  libgcrypt20-dev,
  libgpg-error-dev,
  libgnutls28-dev,

Bug#1003675: The package still use fuse but fuse3 is available and better maintained

[Sebastien Bacher]

Package: ntfs-3g
Version: 1:2021.8.22-3

The package currently Pre-Depends on fuse, would it make sense to change 
to fuse3 which is the current version and better maintained?


Cheers,

Bug#1003674: php-sabre-vobject: (autopkgtest) needs update for php8.1: ValueError: Epoch doesn't fit in a PHP integer

[Paul Gevers]

Source: php-sabre-vobject
Version: 2.1.7-6
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:php-defaults

Dear maintainer(s),

We are in the transition of replacing php7.4 with php8.1 [0]. With a 
recent upload of php-defaults the autopkgtest of php-sabre-vobject fails 
in testing when that autopkgtest is run with the binary packages of 
php-defaults from unstable on armhf and i386 (both 32 bits 
architectures). It passes when run with only packages from testing. In 
tabular form:


   passfail
php-defaults   from testing92
php-sabre-vobject  from testing2.1.7-6
versioned deps from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of php-defaults to 
testing [1]. https://www.php.net/ChangeLog-8.php list the changes since 
7.4 and may help to identify what needs to be updated.


php-commom added a whole set of versioned Breaks to make sure the right 
packages from current unstable are pulled in during testing. If the 
issue is caused by a missing breaks, please reasign this bug to php-common.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] https://bugs.debian.org/976811
[1] https://qa.debian.org/excuses.php?package=php-defaults

https://ci.debian.net/data/autopkgtest/testing/armhf/p/php-sabre-vobject/18255681/log.gz

PHPUnit 9.5.11 by Sebastian Bergmann and contributors.

Warning:   Your XML configuration validates against a deprecated schema.
Suggestion:Migrate your XML configuration using 
"--migrate-configuration"!


...  63 / 
553 ( 11%)
... 126 / 
553 ( 22%)
...R... 189 / 
553 ( 34%)
.R..E.. 252 / 
553 ( 45%)
..RR..RR..R 315 / 
553 ( 56%)
RRR 378 / 
553 ( 68%)
RRR 441 / 
553 ( 79%)
RRR 504 / 
553 ( 91%)
RRR..   553 / 
553 (100%)


Time: 00:00.087, Memory: 12.00 MB

There was 1 error:

1) Sabre\VObject\RecurrenceIteratorTest::testYearly
ValueError: Epoch doesn't fit in a PHP integer

/usr/share/php/Sabre/VObject/RecurrenceIterator.php:687
/tmp/autopkgtest-lxc.20ggb02o/downtmp/build.CCT/src/tests/Sabre/VObject/RecurrenceIteratorTest.php:973


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003497: who-uploads don't show u...@debian.org email default

[肖盛文]

Hi Lin,

在 2022/1/13 21:06, Lance Lin 写道:

Hi Mattia, Xiao Sheng Wen,


looking, it has this:
249 »­­­UPLOADER=$($GPG $GPG_OPTIONS \
250 »­­­   "${GPG_DEFAULT_KEYRINGS[@]}" "${GPG_KEYRINGS[@]}" \
251 »­­­   --list-key --with-colons --fixed-list-mode $GPG_ID 
2>/dev/null |
252 »­­­   awk  -F: '/@debian\.org>/ { a = $10; exit} /^uid/ { a = $10; 
exit} END { print a }' )
So it already has something to handle what you ask, that is clearly not
working.
Probably somebody should try to debug those few lines.
(and don't be ... bothered ... by the way it gather that data… scraping
web pages was a good idea 15 years ago)

I believe have a fix for the issue. I made a merge request on salsa for your 
review.


Yes, your MR partly fix this question in code.

One suggestion is:

It's check the string "@debian.org" is enough, not need tailer >

awk  -F: '/@debian\.org>/  >

awk  -F: '/@debian\.org/

As some DD's public key not use   entry, only has 
u...@debian.org entry.





The issue is that the code above parses the key, however, this will only check 
the first email address on the key. If this first uid is a debian.org email, it 
will use it. Otherwise, this will pull the first uid email (non-debian). It 
seems the assumption is the first email uid on the key will always be 
@debian.org.

For the fix, I searched the entire key for @debian.org. If that is not found, 
search for a non-debian uid email to report back.
If DD's public key don't has the @debian.org entry, who-uploads still 
reply other email address.



A few test cases were the packages 'ucf' and 'tcsh'. The current version will 
not return a debian.org email for Thomas Lange (tcsh) or Manoj Srivastava 
(ucf). My version will return their @debian.org emails.

Please take a look and let me know your thoughts!

Lance Lin 
GPG Fingerprint:  8CAD 1250 8EE0 3A41 7223  03EC 7096 F91E D75D 028F



BTW:

Your MR in line 256, has one trailing-whitespace  , please delete it.

https://salsa.debian.org/debian/devscripts/-/merge_requests/260/diffs#ae7a6fd5b69ead4ea3e2f56f706397082357ad17_253_256


If you use vim, put the following in your .vimrc :

highlight RedundantSpaces ctermbg=red guibg=red
match RedundantSpaces /\s\+$/

You'll see the trailing-whitespace easy, :-)


Thanks!

--
肖盛文 xiao sheng wen Faris Xiao
微信(wechat)：atzlinux
《铜豌豆 Linux》https://www.atzlinux.com
基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
GnuPG Public Key: 0x00186602339240CB



OpenPGP_0x00186602339240CB.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003672: dpkg: [INTL:nl] Dutch translation for the dpkg package

[Frans Spiesschaert]

 
 
Package: dpkg 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch po file for the dpkg package. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as "po/nl.po" in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#1003671: dselect: [INTL:nl] Dutch translation for the dselect package

[Frans Spiesschaert]

 
 
Package: dselect 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch po file for the dselect package. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as "dselect/po/nl.po" in the build tree of the dpkg
source package. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#1003670: php-mockery: (autopkgtest) needs update for php8.1: Test directory "/tmp/autopkgtest-lxc.dt9l77z_/downtmp/build.5Ul/src/./tests/PHP80" not found

[Paul Gevers]

Source: php-mockery
Version: 1.4.2-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:php-defaults

Dear maintainer(s),

We are in the transition of replacing php7.4 with php8.1 [0]. With a 
recent upload of php-defaults the autopkgtest of php-mockery fails in 
testing when that autopkgtest is run with the binary packages of 
php-defaults from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
php-defaults   from testing92
php-mockeryfrom testing1.4.2-1
versioned deps from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of php-defaults to 
testing [1]. https://www.php.net/ChangeLog-8.php list the changes since 
7.4 and may help to identify what needs to be updated.


php-commom added a whole set of versioned Breaks to make sure the right 
packages from current unstable are pulled in during testing. If the 
issue is caused by a missing breaks, please reasign this bug to php-common.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] https://bugs.debian.org/976811
[1] https://qa.debian.org/excuses.php?package=php-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/p/php-mockery/18254695/log.gz

phpab %development% - Copyright (C) 2009 - 2022 by Arne Blankerts and 
Contributors


Scanning directory tests

Autoload file vendor/autoload.php generated.

PHP Deprecated:  Return type of 
MockeryTest_ImplementsIteratorAggregate::getIterator() should either be 
compatible with IteratorAggregate::getIterator(): Traversable, or the 
#[\ReturnTypeWillChange] attribute should be used to temporarily 
suppress the notice in 
/tmp/autopkgtest-lxc.dt9l77z_/downtmp/build.5Ul/src/tests/Mockery/ContainerTest.php 
on line 1759
PHP Deprecated:  Return type of 
MockeryTest_ImplementsIterator::current() should either be compatible 
with Iterator::current(): mixed, or the #[\ReturnTypeWillChange] 
attribute should be used to temporarily suppress the notice in 
/tmp/autopkgtest-lxc.dt9l77z_/downtmp/build.5Ul/src/tests/Mockery/ContainerTest.php 
on line 1771
PHP Deprecated:  Return type of MockeryTest_ImplementsIterator::next() 
should either be compatible with Iterator::next(): void, or the 
#[\ReturnTypeWillChange] attribute should be used to temporarily 
suppress the notice in 
/tmp/autopkgtest-lxc.dt9l77z_/downtmp/build.5Ul/src/tests/Mockery/ContainerTest.php 
on line 1779
PHP Deprecated:  Return type of MockeryTest_ImplementsIterator::key() 
should either be compatible with Iterator::key(): mixed, or the 
#[\ReturnTypeWillChange] attribute should be used to temporarily 
suppress the notice in 
/tmp/autopkgtest-lxc.dt9l77z_/downtmp/build.5Ul/src/tests/Mockery/ContainerTest.php 
on line 1775
PHP Deprecated:  Return type of MockeryTest_ImplementsIterator::valid() 
should either be compatible with Iterator::valid(): bool, or the 
#[\ReturnTypeWillChange] attribute should be used to temporarily 
suppress the notice in 
/tmp/autopkgtest-lxc.dt9l77z_/downtmp/build.5Ul/src/tests/Mockery/ContainerTest.php 
on line 1783
PHP Deprecated:  Return type of MockeryTest_ImplementsIterator::rewind() 
should either be compatible with Iterator::rewind(): void, or the 
#[\ReturnTypeWillChange] attribute should be used to temporarily 
suppress the notice in 
/tmp/autopkgtest-lxc.dt9l77z_/downtmp/build.5Ul/src/tests/Mockery/ContainerTest.php 
on line 1767
PHP Deprecated:  MockeryTest_ClassThatImplementsSerializable implements 
the Serializable interface, which is deprecated. Implement __serialize() 
and __unserialize() instead (or in addition, if support for old PHP 
versions is necessary) in 
/tmp/autopkgtest-lxc.dt9l77z_/downtmp/build.5Ul/src/tests/Mockery/ContainerTest.php 
on line 1848

PHPUnit 9.5.11 by Sebastian Bergmann and contributors.

Test directory 
"/tmp/autopkgtest-lxc.dt9l77z_/downtmp/build.5Ul/src/./tests/PHP80" not 
found

autopkgtest [05:27:48]: test command1



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003669: php-imagick: (autopkgtest) needs update for php8.1: No PHPT expectation found in /usr/share/php/PHPUnit/Runner/PhptTestCase.php

[Paul Gevers]

Source: php-imagick
Version: 3.6.0-4
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:php-defaults

Dear maintainer(s),

We are in the transition of replacing php7.4 with php8.1 [0]. With a 
recent upload of php-defaults the autopkgtest of php-imagick fails in 
testing when that autopkgtest is run with the binary packages of 
php-defaults from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
php-defaults   from testing92
php-imagickfrom testing3.6.0-4
versioned deps from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of php-defaults to 
testing [1]. https://www.php.net/ChangeLog-8.php list the changes since 
7.4 and may help to identify what needs to be updated.


php-commom added a whole set of versioned Breaks to make sure the right 
packages from current unstable are pulled in during testing. If the 
issue is caused by a missing breaks, please reasign this bug to php-common.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] https://bugs.debian.org/976811
[1] https://qa.debian.org/excuses.php?package=php-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/p/php-imagick/18254677/log.gz

PHPUnit 9.5.11 by Sebastian Bergmann and contributors.

Runtime:   PHP 8.1.1

.SI..S.SS..  63 / 
312 ( 20%)
S.. 126 / 
312 ( 40%)
.S. 189 / 
312 ( 60%)
..S.S...S..SS.. 252 / 
312 ( 80%)
S.S.S.SS.S.S..S...S...E..S..312 / 
312 (100%)


Time: 01:15.958, Memory: 4.00 MB

There was 1 error:

1) 
/tmp/autopkgtest-lxc.0xaw1h0b/downtmp/build.pyA/src/imagick-3.6.0/tests/bug81235.phpt
PHPUnit\Runner\Exception: No PHPT expectation found in 
/usr/share/php/PHPUnit/Runner/PhptTestCase.php:375

Stack trace:
#0 /usr/share/php/PHPUnit/Runner/PhptTestCase.php(203): 
PHPUnit\Runner\PhptTestCase->assertPhptExpectation()
#1 /usr/share/php/PHPUnit/Framework/TestSuite.php(678): 
PHPUnit\Runner\PhptTestCase->run()
#2 /usr/share/php/PHPUnit/TextUI/TestRunner.php(670): 
PHPUnit\Framework\TestSuite->run()
#3 /usr/share/php/PHPUnit/TextUI/Command.php(143): 
PHPUnit\TextUI\TestRunner->run()
#4 /usr/share/php/PHPUnit/TextUI/Command.php(96): 
PHPUnit\TextUI\Command->run()

#5 /usr/bin/phpunit(73): PHPUnit\TextUI\Command::main()
#6 {main}
--

There was 1 incomplete test:

1) 
/tmp/autopkgtest-lxc.0xaw1h0b/downtmp/build.pyA/src/imagick-3.6.0/tests/031_Imagick_affineTransformImage_basic.phpt

XFAIL section but test passes



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976811: transition: php8.1

[Paul Gevers]

Dear horde maintainers, Mike,

On 05-12-2021 22:11, Paul Gevers wrote:
Bugs have been filed (with the exception of the horde stack, but they 
are aware) of items we're aware of. Let's give the maintainers a month. 
I propose we can start the php8.1 transition around Christmas 2021. Does 
that work for you Ondřej?


You will probably have noticed that the transition started and that I 
filed a bunch of bugs against php-horde-* packages about their failing 
autopkgtests. I'll stop filing more for now, to not flood your mail 
boxes, but I would like a response from your side about what your plan 
is with the horde packages and the php8.1 transition.


To progress the transition, I plan to "ignore" the autopkgtest failures 
that are merely due to deprecation warnings, but
1) I expect these deprecation warnings to end up in journals/logs, so 
they may flood them excessively
2) failing autopkgtests are (and remain) RC issues in testing but I'm 
willing to tolerate it for some time if you elaborate on the way forward 
and it makes sense.


I think it's necessary to either *fix* the issue, or suppress the 
deprecation warnings in the horde packages. Just ignoring them in the 
autopkgtests is probably the worse outcome.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#916332: local tiled installation

[Julian Squires]

On Sun, 7 Apr 2019 15:35:05 +  wrote:
> The issue was for me (and I think is likely the same for you)
> that I had an older local tiled installation, built from source.
[...]
> You can find the offending lib, by doing `ldd /usr/bin/tiled`.
> 
> In short, this is not a bug in the packaged tiled.

I had the same issue, with no other local installation of tiled; ldd
reports

libtiled.so.1 => /usr/lib/x86_64-linux-gnu/libtiled.so.1 
(0x7f7d4f7d8000)

Upgrading the libtiled1 package fixed this.  Hence I think the tiled
package probably needs to explicitly depend on a specific version of
libtiled1, so that it gets upgraded when tiled gets upgraded.

<#secure method=pgpmime mode=sign>

-- 
Julian Squires

Bug#1003464: RFS: kic/2.4c-1 [QA] [RC] -- Enhanced KIC layout editor

[Andreas Beckmann]

Control: tag -1 pending
Control: tag 688189 pending
Control: tag 999088 pending

On 13/01/2022 04.21, Hugo Torres wrote:

thanks for the guidance. I have already made the suggested changes and 
correction of FTBFS.


Looks good. I'll wait for feedback on my autobuild whitelist request and 
upload afterwards.


Thanks for your work on kic!

Andreas

Bug#1003478: python-django: cannot import name 'RequestSite' from partially initialized module 'django.contrib.sites.requests' (most likely due to a circular import)

[Raphael Hertzog]

On Thu, 13 Jan 2022, Chris Lamb wrote:
> This should be fixed in bullseye-backports in 2:3.2.10-2~bpo11+2 and
> in bullseye itself via 2:2.2.26-1~deb11u1 (see #1003659 for the unblock
> request).

Thank you Chris!

-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#784136: Blocks when enabling logs display

[Philip Wyett]

On Sun, 03 May 2015 14:42:40 +0200 Erwan David  wrote:
> Package: filezilla
> Version: 3.9.0.5-1
> Severity: normal
> 
> When clicking on the "toggle display logs" button, filezilla blocks
> and must then be killed.
> 
> -- System Information:
> Debian Release: 8.0
>   APT prefers testing
>   APT policy: (900, 'testing'), (700, 'oldstable-proposed-updates'), (600, 
> 'stable'), (500,
'proposed-updates'), (400, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages filezilla depends on:
> ii  filezilla-common 3.9.0.5-1
> ii  libatk1.0-0  2.14.0-1
> ii  libc62.19-18
> ii  libcairo21.14.0-2.1
> ii  libdbus-1-3  1.8.16-1
> ii  libfontconfig1   2.11.0-6.3
> ii  libfreetype6 2.5.2-4
> ii  libgcc1  1:4.9.2-10
> ii  libgdk-pixbuf2.0-0   2.31.1-2+b1
> ii  libglib2.0-0 2.42.1-1
> ii  libgnutls-deb0-283.3.14-2
> ii  libgtk2.0-0  2.24.25-3
> ii  libidn11 1.30-1
> ii  libpango-1.0-0   1.36.8-3
> ii  libpangocairo-1.0-0  1.36.8-3
> ii  libpangoft2-1.0-01.36.8-3
> ii  libsqlite3-0 3.8.7.4-1
> ii  libstdc++6   4.9.2-10
> ii  libtinyxml2.6.2  2.6.2-2
> ii  libwxbase3.0-0   3.0.2-1+b1
> ii  libwxgtk3.0-03.0.2-1+b1
> 
> Versions of packages filezilla recommends:
> ii  xdg-utils  1.1.0~rc1+git20111210-7.4
> 
> filezilla suggests no packages.
> 
> -- no debconf information
> 
> 

Hi,

filezilla 3.9.0 has long since been unsupported. Do you see same issue with 
current stable
(11/bullseye)? Being that this is a legacy bug. If no update in the coming 
month, I will close the
bug.

Regards

Phil

-- 
*** Playing the game for the games own sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#1003610: libc6 crashes with VIA C7 and VIA Eden processors starting with 2.33

[Wolfgang Walter]

Am 2022-01-12 16:46, schrieb Aurelien Jarno:

On 2022-01-12 16:14, Wolfgang Walter wrote:

Package: libc6
Version: 2.33-2
Severity: important

After upgrading from libc6 2.32 to 2.33 all machines with a VIA C7 or 
VIA

Eden show segfaults in libc (i.e. hostname fails to work, or rebooting
fails). Machines with VIA Nehemiah work fine.


Could you please provide more details? At least the content of dmesg
when it happens or ideally a core dump or a backtrace.


Not easy. These machines just boot into a initramfs (which is a very 
minimal debian sid) from an usb-stick and nothing survives a reboot. 
/bin/sh points to bash.


The system does not use systemd but sysv.

The login prompt is:

(none) login:


I cannot log into the machine, login seems also be broken, it always 
says "login incorrect".


If I try to reboot by entering ctrl-alt-del the reboot fails with:

INIT: Switching to runlevel: 6
INIT: No inittab.d directory found
INIT: Sending processes configured via /etc/inittab the TERM signal
[  305.550677][ T1235] rc[1235]: segfault at 1c81000 ip b7ebf634 sp 
bfb5ce78 error 6 in libc-2.33.so[b7d8e000+158000]
[  305.550791][ T1235] Code: 95 04 00 03 1c 8b 01 ca ff e3 29 d9 8d b4 
26 00 00 00 00 8d 76 00 0f 18 8a c0 03 00 00 0f 18 8a 80 03 00 00 81 eb 
80 00 00 00 <66> 0f 7f 02 66 0f 7f 42 10 66 0f 7f 42 20 66 0f 7f 42 30 
66 0f 7f

Give root password for maintenance
(or press Control-D to continue):



But I cannot login (Login incorrect). If I enter control-d instead, I 
get "sulogin: cannot read /dev/tty1: Operation not permitted".


The very same usb stick boots just fine with non VIA 7 / VIA Eden 
processors.



I modified it a bit an set --autologin for one getty. This did not worḱ, 
I get a lot of things like


[   ..][ T1231] login[1231]: segfault at bfd3d000 ip b7eb5656 sp 
bfd36978 error 6 in libc-2.33.so[b7d84000+158000]


or

[ ][ T1241] sh[1241]: segfault at 12ac000 ip b7e03638 sp 
bff99ff8 error 6 in libc-2.33.so[b7cd2000+158000]



Now I tried  getty -n -l /bin/dash. This worked.

If I try to start bash, bash crashes with a segmentation fault. I have 
no debugger and no debugging symbols in this image at the moment, only 
strace


If I strace -f bash I get:

The last thing done is reading the first line of passwd, closing the 
file. Then there is a SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, 
si_addr=0x12d9000}


When I do a strace -f bash 2> /tmp/blub the last system call is uname(), 
then again a SEGV_MAPPERR


When bash segfaults I get no log that it crashed in libc6.

ls, rm, mount  etc seem to work.

But vim crashes in libc6, again at +158000 and with Code "1c 8b 01 ca ff 
e3 29 d9 8d b4 26 00 00 00 00 8d 76 00 0f 18 8a c0 03 00 00 0f 18 8a 80 
03 00 00 81 eb 80 00 00 00 <66> 0f 7f 02 66 0f 7f 42 10 66 0f 7f 42 20 
66 0f 7f 42 30 66 0f"


Also ip link ls crashes, again in libc6, again at +158000 and with Code 
"0f 18 8a 80 03 00 00 81 eb 80 00 00 00 00 66 0f 7f 02 66 0f 7f 42 10 66 
0f 7f 42 20 66 0f 7f 42 30 66 0f 7f 42 40 66 0f 7f 42 50 <66> 0f 7f 02 
66 0f 7f 42 70 71 c2 80 00 00 00 81 fb 80 00 00 00"


or ip addr ls

or less, perl, ssh, sshd, rsyslogd

The Code is not always the same, but <66> 0f 7f 42 seems to be and the 
crash in libc-2.33.so[x+158000]




Thanks,
Aurelien


Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts

Bug#928837: Regression of site manager default local directory

[Philip Wyett]

On Sun, 12 May 2019 10:54:35 +0900 hoxp18  wrote:
> Package: filezilla
> To: mainto...@bugs.debian.org
> Subject: Regression of site manager default local directory
> Package: filezilla
> Version: 3.39.0-2 amd64
> 
> Dear maintainers,
> 
> Filezilla's "default local directory" does not work properly.
> 
> * Site Manager -> Advanced tab -> Defailt local directory
> 
> * After connect, it does not move onto the local directory.
> 
> * Even with "Use synchronized browsing"
> 
> * Perhaps it is because of the AppArmor profile, enforce mode.
> 
>My own profile, had been worked several month on Stretch.
>(fixed some on the Buster machine, with aa-logprof.)
> 
> Regards.
> 
> 

Hi,

Do you still see this issue on latest stable (bullseye)?

You are using one of more custom AppArmor profiles?

Regards

Phil

-- 
*** Playing the game for the games own sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#1003641: systemd-oomd.service already active, refusing

[Michael Biebl]

Am 13.01.22 um 08:36 schrieb Jérémy Lal:

Package: systemd-oomd
Version: 250.2-2
Severity: normal

Hi,

i've installed systemd-oomd 250.2-1 and on upgrade,
noticed this:

systemd-oomd.socket: Socket service systemd-oomd.service already active, 
refusing.
Failed to listen on Userspace Out-Of-Memory (OOM) Killer Socket.

I'm not sure what should be done. Stop the service, disable the socket ?



The behaviour of dh_installsystemd is to treat systemd-oomd.service and
systemd-oomd.socket as completely separate services.
So it generates code for both units to enable/disable and restart those 
units (more or less independently).


You can't really restart a socket unit though which is bound to a 
running service.


What you see is basically a duplicate of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955483

We don't have a good answer here. This probably needs support from 
upstream as well.


As a workaround, we could probably drop the restart/start of 
systemd-oomd.socket and only keep the enable/disable/stop-on-removal bits.


For that we'd need separate calls to the dh_installsystemd override. One 
for systemd-oomd.service and one for systemd-oomd.socket.


This is untested:

override_dh_installsystemd:
... 
dh_installsystemd -Psystemd-oomd systemd-oomd.service
	dh_installsystemd -Psystemd-oomd --no-start --no-stop-on-upgrade 
systemd-oomd.socket


(not quite sure if we need --no-restart-after-upgrade as well).

This has the downside that the socket is no longer restarted on 
upgrades, so changes to the socket unit are not applied.
It has the upside, that it doesn't interfere with the currently running 
.service unit.


Ideally, this would be handled better by systemctl and/or debhelper by 
knowing that those units belong together and restarting them in the 
correct order.


Balint had some thoughts in #955483, but nothing really happened since then






OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003452: dpkg: missing alternatives for x-terminal-emulator

[Vincent Lefevre]

Control: found -1 1.21.0
Control: notfound -1 1.21.1

since the issue really occurred in dpkg 1.21.0.

On 2022-01-13 13:17:42 +0100, Guillem Jover wrote:
[...]

Thanks for the explanations.

> On Wed, 2022-01-12 at 14:17:17 +0100, Vincent Lefevre wrote:
> > If this is the case,
> > is there a way to know which alternatives are missing? Those that
> > appear in /var/log/alternatives.log* while dpkg 1.20.0 was installed?
> 
> As long as alternatives.log has been kept for long enough,

I keep them for 1 year. :-) So, this was OK for me, except that
this does not say which packages could be affected, i.e. which
installed packages provide the considered alternative.

> otherwise grepping for u-a in maintscripts in the dpkg db might be
> more effective.

This is more complex than just a grep due to continuation lines.
For instance, /var/lib/dpkg/info/mlterm.postinst contains

update-alternatives \
  --install /usr/bin/x-terminal-emulator x-terminal-emulator 
/usr/bin/mlterm 20 \
  --slave /usr/share/man/man1/x-terminal-emulator.1.gz 
x-terminal-emulator.1.gz /usr/share/man/man1/mlterm.1.gz

So, if I'm not mistaken:

  pcregrep -Mr 
'^(.|\\\n)*update-alternatives(.|\\\n)*--install(.|\\\n)*\bx-terminal-emulator\b(.|\n)*?[^\\]$'
 /var/lib/dpkg/info

based on the idea from .

If there were a field in the control file, this could have been
much easier (and could also be useful in a more general way, e.g.
to search for non-installed packages providing some alternative).

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

Bug#1003668: lintian: FP missing-build-dependency-for-dh-addon with pybuild-plugin-pyproject

[Andrius Merkys]

Package: lintian
Version: 2.114.0

Hello,

Recently, Python PEP-517 build plugin pybuild-plugin-pyproject has been
introduced [1]. This means that some packages will build-depend on
pybuild-plugin-pyproject instead of dh-python, as
pybuild-plugin-pyproject depends on dh-python. Thus packages depending
on pybuild-plugin-pyproject should be exempt from
missing-build-dependency-for-dh-addon lintian error.

Observed when running lintian 2.114.0 on poetry 1.1.12+dfsg-1.

[1] https://lists.debian.org/debian-python/2021/12/msg00043.html

Andrius