Bug#978040: Warning: (9034) "crtbeginS.o" not found (on non-intel architectures)

[Paul Gevers]

Hi,

On 29-12-2021 23:47, Abou Al Montacir wrote:

So it should work correctly on all targets.


Does this work correctly on all multiarch architectures too? I inspected 
only my own installation and there it only has cpui386 and cpux86_64.


However, it is true that if a new gcc version is installed after FPC 
then the logic will fall down.


Can't we use a wildcard for the version number? I mean, after 11 comes 
12 and 13 and ...



If this is judged OK, I propose to close this ticket


As long as we have a new fpc in every Debian release, we're fine in 
Debian, but e.g. Ubuntu users may experience issues when they carry the 
same fpc over to a new version of Ubuntu that comes with a new gcc 
version. So I don't think it's nice.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1002984: FTBFS with ocaml-migrate-parsetree 2.3.0

[Stéphane Glondu]

Source: mlpost
Version: 0.9-1
Severity: important
Tags: ftbfs

Dear Maintainer,

Your package FTBFS with ocaml-migrate-parsetree 2.3.0 with the
following error:
> File "customdoc/img.ml", line 2, characters 5-18:
> 2 | open OCaml_403.Ast
>  ^
> Error: Unbound module OCaml_403

This was discovered while preparing the transition to OCaml 4.13.1.

Packages rebuilt with OCaml 4.13.1 are available at:

  https://ocaml.debian.net/transitions/ocaml-4.13.1/


Cheers,

-- 
Stéphane


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (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

Bug#1002983: FTBFS with camlp5 8.00.02

[Stéphane Glondu]

Source: hol-light
Version: 20190729-4
Severity: important
Tags: ftbfs

Dear Maintainer,

Your package FTBFS with camlp5 8.00.02 with the following error:
> cp: cannot stat 'pa_j_3.1x_8.xx.ml': No such file or directory

This was discovered while preparing the transition to OCaml 4.13.1.

Packages rebuilt with OCaml 4.13.1 are available at:

  https://ocaml.debian.net/transitions/ocaml-4.13.1/


Cheers,

-- 
Stéphane


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (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

Bug#1002982: Acknowledgement (elpa-org: post-installation script subprocess returned error exit status 1)

[Lev Lamberov]

And here is Emacs debug output:

Debugger entered--Lisp error: (error "Invalid version syntax: ‘N/A’ (must start 
with a n...")
  signal(error ("Invalid version syntax: ‘N/A’ (must start with a n..."))
  error("Invalid version syntax: `%s' (must start with a nu..." "N/A")
  version-to-list("N/A")
  version<("N/A" "9.0")
  (if (version< (org-version) "9.0") (with-no-warnings (org-add-link-type 
"elfeed" #'elfeed-link-open) (add-hook 'org-store-link-functions 
#'elfeed-link-store-link)) (with-no-warnings (org-link-set-parameters "elfeed" 
:follow #'elfeed-link-open :store #'elfeed-link-store-link)))
  (lambda nil (if (version< (org-version) "9.0") (with-no-warnings 
(org-add-link-type "elfeed" #'elfeed-link-open) (add-hook 
'org-store-link-functions #'elfeed-link-store-link)) (with-no-warnings 
(org-link-set-parameters "elfeed" :follow #'elfeed-link-open :store 
#'elfeed-link-store-link()
  funcall((lambda nil (if (version< (org-version) "9.0") (with-no-warnings 
(org-add-link-type "elfeed" #'elfeed-link-open) (add-hook 
'org-store-link-functions #'elfeed-link-store-link)) (with-no-warnings 
(org-link-set-parameters "elfeed" :follow #'elfeed-link-open :store 
#'elfeed-link-store-link)
  (lambda nil (funcall '(lambda nil (if (version< (org-version) "9.0") 
(with-no-warnings (org-add-link-type "elfeed" #'elfeed-link-open) (add-hook 
'org-store-link-functions #'elfeed-link-store-link)) (with-no-warnings 
(org-link-set-parameters "elfeed" :follow #'elfeed-link-open :store 
#'elfeed-link-store-link))()
  eval-after-load-helper("/usr/share/emacs/site-lisp/elpa/org-9.5.2/org.elc")
  run-hook-with-args(eval-after-load-helper 
"/usr/share/emacs/site-lisp/elpa/org-9.5.2/org.elc")
  do-after-load-evaluation("/usr/share/emacs/site-lisp/elpa/org-9.5.2/org.elc")
  require(org)
  
byte-code("\300\301!\210\300\302!\210\300\303!\210\300\304!\210\300\305!\210\300\306!\210\300\307!\210\300\310!\210\300\311!\210\300\312!\210\300\313!\207"
 [require cl-lib org grep seq async dash f hl-todo magit pcre2el s] 2)
  require(magit-todos nil t)
  (not (require 'magit-todos nil t))
  (if (not (require 'magit-todos nil t)) (display-warning 'use-package (format 
"Cannot load %s" 'magit-todos) :error) (condition-case err (progn 
(magit-todos-mode) t) ((debug error) (funcall use-package--warning47 :config 
err
  (condition-case err (if (not (require 'magit-todos nil t)) (display-warning 
'use-package (format "Cannot load %s" 'magit-todos) :error) (condition-case err 
(progn (magit-todos-mode) t) ((debug error) (funcall use-package--warning47 
:config err ((debug error) (funcall use-package--warning47 :catch err)))
  eval-buffer(# nil "/home/dogsleg/.emacs.d/init.el" nil t)  ; 
Reading at buffer position 25241
  load-with-code-conversion("/home/dogsleg/.emacs.d/init.el" 
"/home/dogsleg/.emacs.d/init.el" t t)
  load("/home/dogsleg/.emacs.d/init" noerror nomessage)
  startup--load-user-init-file(#f(compiled-function () #) #f(compiled-function () #) t)
  command-line()
  normal-top-level()

Bug#1002982: elpa-org: post-installation script subprocess returned error exit status 1

[Lev Lamberov]

Package: elpa-org
Version: 9.5.2+dfsh-1
Severity: grave
X-Debbugs-Cc: none, Lev Lamberov 

Dear Maintainer,

While updating elpa-org (9.4.0+dfsg-1 -> 9.5.2+dfsh-1, in testing) I
faced a problem with post-installation, which is still there even in
case of completely removing elpa-org and then reinstalling it. Please,
see the followin apt output:

* Purging

$ LC_ALL=C.UTF-8 sudo apt purge elpa
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package elpa
10:43:17-dogsleg@shakva:~$ LC_ALL=C.UTF-8 sudo apt purge elpa-org
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following package was automatically installed and is no longer required:
  elpa-htmlize
Use 'sudo apt autoremove' to remove it.
The following packages will be REMOVED:
  elpa-org*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 5214 kB disk space will be freed.
Do you want to continue? [Y/n] 
(Reading database ... 486521 files and directories currently installed.)
Removing elpa-org (9.5.2+dfsh-1) ...
Remove elpa-org for emacs
remove/org-9.5.2: Handling removal of emacsen flavor emacs
dh-elpa: purging flavor specific files for emacs

* Installing again

$ LC_ALL=C.UTF-8 sudo apt install elpa-org
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Suggested packages:
  ditaa
The following NEW packages will be installed:
  elpa-org
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/949 kB of archives.
After this operation, 5214 kB of additional disk space will be used.
Selecting previously unselected package elpa-org.
(Reading database ... 486388 files and directories currently installed.)
Preparing to unpack .../elpa-org_9.5.2+dfsh-1_all.deb ...
Unpacking elpa-org (9.5.2+dfsh-1) ...
Setting up elpa-org (9.5.2+dfsh-1) ...
tsort: -: input contains a loop:
tsort: elpa-htmlize
tsort: emacsen-common
Install elpa-htmlize for emacs
install/htmlize-1.56: Handling install of emacsen flavor emacs
install/htmlize-1.56: byte-compiling for emacs
Install emacsen-common for emacs
emacsen-common: Handling install of emacsen flavor emacs
Install elpa-org for emacs
install/org-9.5.2: Handling install of emacsen flavor emacs
install/org-9.5.2: byte-compiling for emacs
Warning (emacs): Could not define org version correctly.  Check installation!

In toplevel form:
org-agenda.el:50:1:Error: Invalid version syntax: ‘N/A’ (must start with a 
number)
Warning (emacs): Could not define org version correctly.  Check installation!

In toplevel form:
org-archive.el:31:1:Error: Invalid version syntax: ‘N/A’ (must start with a 
number)
Warning (emacs): Could not define org version correctly.  Check installation!

In toplevel form:
org-attach-git.el:32:1:Error: Invalid version syntax: ‘N/A’ (must start with a 
number)
Warning (emacs): Could not define org version correctly.  Check installation!

In toplevel form:
org-attach.el:38:1:Error: Invalid version syntax: ‘N/A’ (must start with a 
number)
Warning (emacs): Could not define org version correctly.  Check installation!

In toplevel form:
org-capture.el:51:1:Error: Invalid version syntax: ‘N/A’ (must start with a 
number)
Warning (emacs): Could not define org version correctly.  Check installation!

In toplevel form:
org-clock.el:32:1:Error: Invalid version syntax: ‘N/A’ (must start with a 
number)
Warning (emacs): Could not define org version correctly.  Check installation!

In toplevel form:
org-colview.el:32:1:Error: Invalid version syntax: ‘N/A’ (must start with a 
number)
Warning (emacs): Could not define org version correctly.  Check installation!

In toplevel form:
org-ctags.el:141:1:Error: Invalid version syntax: ‘N/A’ (must start with a 
number)
Warning (emacs): Could not define org version correctly.  Check installation!

In toplevel form:
org-datetree.el:33:1:Error: Invalid version syntax: ‘N/A’ (must start with a 
number)
Warning (emacs): Could not define org version correctly.  Check installation!

In toplevel form:
org-element.el:64:1:Error: Invalid version syntax: ‘N/A’ (must start with a 
number)
Warning (emacs): Could not define org version correctly.  Check installation!

In toplevel form:
org-feed.el:91:1:Error: Invalid version syntax: ‘N/A’ (must start with a number)
Warning (emacs): Could not define org version correctly.  Check installation!

In toplevel form:
org-goto.el:25:1:Error: Invalid version syntax: ‘N/A’ (must start with a number)
Warning (emacs): Could not define org version correctly.  Check installation!

In toplevel form:
org-habit.el:32:1:Error: Invalid version syntax: ‘N/A’ (must start with a 
number)
Warning (emacs): Could not define org version correctly.  Check installation!

In toplevel form:
org-id.el:73:1:Error: Invalid version syntax: ‘N/A’ (must start with a number)
Warning (emacs): Could not define org version correctly. 

Bug#1002981: leaves callback registered after unload

[Simon Richter]

Package: libxext6
Version: 2:1.3.3-1.1
Severity: minor
Tags: upstream
X-Debbugs-Cc: s...@debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

I have a very basic Vulkan app that uses libXext only indirectly through
the Vulkan X11 extension, so my program is not linked against libXext
directly (and can be linked only with --no-as-needed).

During shutdown, the program crashes with a segmentation fault, during

63  for (ext = dpy->ext_procs; ext; ext = ext->next) {
64  if (ext->close_display)
65  (*ext->close_display)(dpy, >codes);

from src/ClDisplay.c in libX11. According to gdb,

*ext = {next = 0x558d0ee0, codes = {extension = 2, major_opcode = 128,
first_event = 0, first_error = 0}, create_GC = 0x0, copy_GC = 0x0,
  flush_GC = 0x0, free_GC = 0x0, create_Font = 0x0, free_Font = 0x0,
  close_display = 0x7fffed9c6ce0, error = 0x0, error_string = 0x0,
  name = 0x558d0ec0 "Generic Event Extension", error_values = 0x0,
  before_flush = 0x0, next_flush = 0x0}

The address for close_display refers to

0x7fffed9bd3d0  0x7fffed9c74ff  Yes (*) 
/lib/x86_64-linux-gnu/libXext.so.6

which has been unloaded at this point, together with the Vulkan driver.

It seems that libXext expects that it will remain loaded until
CloseDisplay() time, which is difficult to do here: I need to dismantle
Vulkan before closing the display connection, and libXext is only used
by an extension module that is loaded with dlopen(), so libXext will be
unloaded during Vulkan stack teardown.

I could reproduce this with both Intel and nVidia GPUs, using the source
attached. The problem goes away if I configure with

./configure LIBS='-Wl,--no-as-needed,-lXext'

to force link the application against libXext.

   Simon

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

Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages libxext6 depends on:
ii  libc6 2.31-13+deb11u2
ii  libx11-6  2:1.7.2-1

libxext6 recommends no packages.

libxext6 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQFDBAEBCgAtFiEEtjuqOJSXmNjSiX3Tfr04e7CZCBEFAmHRPB4PHHNqckBkZWJp
YW4ub3JnAAoJEH69OHuwmQgRhVcH/395wMUzc6/q2MPTES2qNGiLqdbvy2prlgLy
MFRhvuhNGYFIxOhjaDPP9XKpjQ7FnZo54mVNq9FhSipbzCkTscj27s8bOVkcQ3Sz
wIi2NRkNuUOsrHdylxnqH9+tDOd4LhcpWONf3ch65a4siXrw6VjQ4+tdgayBdVgD
DzF0Ax2aXUyO/cAiUCoq4rbd1gaXkiAPSL6sprzklpf2H/Jqj475fr0cxAEJh/Mc
QvtV1hh26Cl1AIIkAM8EcD49fHCWXxIWscZDv5Ubw9ROCs1fUbLdMwczzeC4H8im
pFpf3TphQyB3LaZ6qSqDR3kQOv3jGcHhCPYFoc7U6dCpTmblz8Q=
=SA2i
-END PGP SIGNATURE-


vkload-0.0.20211229.tar.gz
Description: application/gzip

Bug#1002980: linuxptp: providing time-daemon makes it impossible to install alongside chrony or other NTP servers

[Chris Lawrence]

Package: linuxptp
Version: 3.1.1-2
Severity: normal

Since version 3.1.1-2, linuxptp now provides the "time-daemon" virtual
package; this makes it impossible to install both PTP and NTP servers
side-by-side on the same system, even though chrony and ntpd are both
designed to work alongside linuxptp.

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

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

Versions of packages linuxptp depends on:
ii  libc6  2.33-1

linuxptp recommends no packages.

linuxptp suggests no packages.

-- Configuration Files:
/etc/linuxptp/ptp4l.conf changed:
[global]
twoStepFlag 1
slaveOnly   0
socket_priority 0
priority1   128
priority2   128
domainNumber0
clockClass  248
clockAccuracy   0xFE
offsetScaledLogVariance 0x
free_running0
freq_est_interval   1
dscp_event  0
dscp_general0
dataset_comparison  ieee1588
G.8275.defaultDS.localPriority  128
maxStepsRemoved 255
logAnnounceInterval 1
logSyncInterval 0
operLogSyncInterval 0
logMinDelayReqInterval  0
logMinPdelayReqInterval 0
operLogPdelayReqInterval 0
announceReceiptTimeout  3
syncReceiptTimeout  0
delayAsymmetry  0
fault_reset_interval4
neighborPropDelayThresh 2000
masterOnly  0
G.8275.portDS.localPriority 128
asCapable   auto
BMCAptp
inhibit_announce0
inhibit_delay_req   0
ignore_source_id0
assume_two_step 0
logging_level   6
path_trace_enabled  0
follow_up_info  0
hybrid_e2e  0
inhibit_multicast_service   0
net_sync_monitor0
tc_spanning_tree0
tx_timestamp_timeout1
unicast_listen  0
unicast_master_table0
unicast_req_duration3600
use_syslog  1
verbose 0
summary_interval6
kernel_leap 1
check_fup_sync  0
pi_proportional_const   0.0
pi_integral_const   0.0
pi_proportional_scale   0.0
pi_proportional_exponent-0.3
pi_proportional_norm_max0.7
pi_integral_scale   0.0
pi_integral_exponent0.4
pi_integral_norm_max0.3
step_threshold  0.0
first_step_threshold0.2
max_frequency   9
clock_servo ntpshm
sanity_freq_limit   2
ntpshm_segment  0
msg_interval_request0
servo_num_offset_values 10
servo_offset_threshold  0
write_phase_mode0
transportSpecific   0x0
ptp_dst_mac 01:1B:19:00:00:00
p2p_dst_mac 01:80:C2:00:00:0E
udp_ttl 1
udp6_scope  0x0E
uds_address /var/run/ptp4l
clock_type  OC
network_transport   UDPv4
delay_mechanism Auto
time_stamping   software
tsproc_mode filter
delay_filtermoving_median
delay_filter_length 10
egressLatency   0
ingressLatency  0
boundary_clock_jbod 0
productDescription  ;;
revisionData;;
manufacturerIdentity00:00:00
userDescription ;
timeSource  0xA0

/etc/linuxptp/timemaster.conf changed:
[timemaster]
ntp_program chronyd
[chrony.conf]
include /etc/chrony/chrony.conf
[ntp.conf]
includefile /etc/ntp.conf
[ptp4l.conf]
[chronyd]
path /usr/sbin/chronyd
[ntpd]
path /usr/sbin/ntpd
options -u ntp:ntp -g
[phc2sys]
path /usr/sbin/phc2sys
[ptp4l]
path /usr/sbin/ptp4l


-- no debconf information

Bug#1002979: FTBFS with camlp5 8.00.02

[Stéphane Glondu]

Source: geneweb
Version: 6.08+git20181019+dfsg-3
Severity: important
Tags: ftbfs

Dear Maintainer,

Your package FTBFS with camlp5 8.00.02 with the following error:
> camlp5r pa_extend.cmo q_MLast.cmo -o pa_macro5.ppo pa_macro5.ml
> File "pa_macro5.ml", line 162, characters 51-52:
> While expanding quotation "patt":
> Parse error: end of input expected after [patt] (in [patt_eoi])

This was discovered while preparing the transition to OCaml 4.13.1.

Packages rebuilt with OCaml 4.13.1 are available at:

  https://ocaml.debian.net/transitions/ocaml-4.13.1/


Cheers,

-- 
Stéphane

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (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

Bug#1002978: linux-image-5.10.0-10-amd64: Upgrade from Jessie to Bullseye produces frequent and painful INTEL i915 GPU Hangs

[CJ Fearnley]

Package: src:linux
Version: 5.10.84-1
Severity: important

Dear Maintainer,

Video on this system was pretty fast under Jessie. My notes suggest there
may have been issues when I upgraded to Stretch in 2018. I upgraded
to Buster in May 2021 and experienced some video hangs and slowness
switching desktops (fvwm window manager), but performance was mostly
tolerable. On Dec 25th I upgraded to Bullseye and video performance
is now frequently slow (sometimes it is OK if I'm working lightly,
sometimes I need to wait before I can launch fvwm menus: that used to
be nearly instantaneous after startx). Sometimes the GPU hangs become
frequent and can take many seconds to recover (I haven't timed them:
10 seconds or more it feels like) making productivity impossible. Once
the whole screen froze and I had to ssh in to kill mpv to free the screen.

I have rebooted more than 15 times trying various kernel command line
options to little avail so far.

Today's most recent experiment was setting intel_idle.max_cstate=1.

I triggered a GPU hang running mpv. After more than a minute of hanging, mpv
crashed with this error:
i965: Failed to submit batchbuffer: Input/output error0 Cache: 1285s/150MB

Here is the output from cat /sys/class/drm/card0/error after that mishap:
GPU HANG: ecode 6:0:
Kernel: 5.10.0-10-amd64 x86_64
Driver: 20200917
Time: 1641080764 s 722449 us
Boottime: 4174 s 920325 us
Uptime: 4168 s 5740 us
Capture: 4295936000 jiffies; 108272 ms ago
Reset count: 0
Suspend count: 0
Platform: SANDYBRIDGE
Subplatform: 0x0
PCI ID: 0x0102
PCI Revision: 0x09
PCI Subsystem: 1565:110d
IOMMU enabled?: 0
RPM wakelock: yes
PM suspended: no
GT awake: yes
EIR: 0x
IER: 0x82bc8585
GTIER[0]: 0x00401001
PGTBL_ER: 0x
FORCEWAKE: 0x
DERRMR: 0x
  fence[0] = 
  fence[1] = 120600701107003
  fence[2] = 
  fence[3] = 3dec03b03604001
  fence[4] = 
  fence[5] = 45d503b03ded001
  fence[6] = 4dbe03b045d6001
  fence[7] = 
  fence[8] = 
  fence[9] = 
  fence[10] = 
  fence[11] = 
  fence[12] = 
  fence[13] = 
  fence[14] = 
  fence[15] = 
ERROR: 0x
DONE_REG: 0x
available engines: 7
slice total: 0, mask=
subslice total: 0
EU total: 0
EU per subslice: 0
has slice power gating: no
has subslice power gating: no
has EU power gating: no
Unavailable
Num Pipes: 2
Pipe [0]:
  Power: on
  SRC: 077f0437
  STAT: 
Plane [0]:
  CNTR: d8004400
  STRIDE: 1e00
  ADDR: 
  SURF: 045d6000
  TILEOFF: 
Cursor [0]:
  CNTR: 04004027
  POS: 021004cb
  BASE: 00fdf000
Pipe [1]:
  Power: on
  SRC: 
  STAT: 
Plane [1]:
  CNTR: 4000
  STRIDE: 
  ADDR: 
  SURF: 
  TILEOFF: 
Cursor [1]:
  CNTR: 
  POS: 
  BASE: 
CPU transcoder: A
  Power: on
  CONF: c000
  HTOTAL: 0897077f
  HBLANK: 0897077f
  HSYNC: 080307d7
  VTOTAL: 04640437
  VBLANK: 04640437
  VSYNC: 0440043b
CPU transcoder: B
  Power: on
  CONF: 
  HTOTAL: 
  HBLANK: 
  HSYNC: 
  VTOTAL: 
  VBLANK: 
  VSYNC: 
gen: 6
gt: 1
iommu: disabled
memory-regions: 5
page-sizes: 1000
platform: SANDYBRIDGE
ppgtt-size: 31
ppgtt-type: 1
dma_mask_size: 40
is_mobile: no
is_lp: no
require_force_probe: no
is_dgfx: no
has_64bit_reloc: no
gpu_reset_clobbers_display: no
has_reset_engine: no
has_fpga_dbg: no
has_global_mocs: no
has_gt_uc: no
has_l3_dpf: no
has_llc: yes
has_logical_ring_contexts: no
has_logical_ring_elsq: no
has_logical_ring_preemption: no
has_master_unit_irq: no
has_pooled_eu: no
has_rc6: yes
has_rc6p: yes
has_rps: yes
has_runtime_pm: no
has_snoop: no
has_coherent_ggtt: yes
unfenced_needs_alignment: no
hws_needs_physical: no
cursor_needs_physical: no
has_csr: no
has_ddi: no
has_dp_mst: no
has_dsb: no
has_dsc: no
has_fbc: yes
has_gmch: no
has_hdcp: no
has_hotplug: yes
has_hti: no
has_ipc: no
has_modular_fia: no
has_overlay: no
has_psr: no
has_psr_hw_tracking: no
overlay_needs_physical: no
supports_tv: no
rawclk rate: 125000 kHz
CS timestamp frequency: 1250 Hz
Has logical contexts? yes
scheduler: 0
i915.vbt_firmware=(null)
i915.modeset=-1
i915.lvds_channel_mode=0
i915.panel_use_ssc=-1
i915.vbt_sdvo_panel_type=-1
i915.enable_dc=-1
i915.enable_fbc=0
i915.enable_psr=-1
i915.psr_safest_params=no
i915.enable_psr2_sel_fetch=no
i915.disable_power_well=1
i915.enable_ips=1
i915.invert_brightness=0
i915.enable_guc=0
i915.guc_log_level=-1
i915.guc_firmware_path=(null)
i915.huc_firmware_path=(null)
i915.dmc_firmware_path=(null)
i915.mmio_debug=0
i915.edp_vswing=0
i915.reset=3
i915.inject_probe_failure=0
i915.fastboot=-1
i915.enable_dpcd_backlight=-1
i915.force_probe=
i915.fake_lmem_start=0
i915.enable_hangcheck=yes
i915.load_detect_test=no
i915.force_reset_modeset_test=no
i915.error_capture=yes
i915.disable_display=no
i915.verbose_state_checks=yes
i915.nuclear_pageflip=no
i915.enable_dp_mst=yes
i915.enable_gvt=no

Most of 

Bug#1002977: rrdtool: "rrdtool fetch" outputs values even for CFs that are not stored

[Vincent Lefevre]

On 2022-01-02 04:17:35 +0100, Vincent Lefevre wrote:
> But
> 
>   rrdtool fetch cpuload.rrd MIN -s -108
> 
> also outputs values. Selected step is 300, and most values
> (for the oldest timestamps) are NaN. Instead, it should fail.

In case you're wondering why I try to read values associated with a CF
that has not been declared with "rrdtool create", this is because this
is done via a Perl script on several .rrd files, via the RRDs Perl
module. For some of these files, MIN has been declared, but not all of
them, and the script doesn't know which CFs are used. So it tries all
of them. If a CF isn't used, it expects an error so that it can skip
it instead of getting unexpected results.

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

Bug#1002977: rrdtool: "rrdtool fetch" outputs values even for CFs that are not stored

[Vincent Lefevre]

Package: rrdtool
Version: 1.7.2-3+b7
Severity: normal

I have created cpuload.rrd with

rrdtool create cpuload.rrd \
  DS:cpuload:GAUGE:600:0:U \
  RRA:AVERAGE:0.5:1:600 \
  RRA:AVERAGE:0.5:6:600 \
  RRA:AVERAGE:0.5:24:600 \
  RRA:AVERAGE:0.5:288:600 \
  RRA:MAX:0.5:1:600 \
  RRA:MAX:0.5:6:600 \
  RRA:MAX:0.5:24:600 \
  RRA:MAX:0.5:288:600

So there's AVERAGE and MAX, but not MIN.

As expected,

  rrdtool fetch cpuload.rrd AVERAGE -s -108

and

  rrdtool fetch cpuload.rrd MAX -s -108

both output values with step 1800.

But

  rrdtool fetch cpuload.rrd MIN -s -108

also outputs values. Selected step is 300, and most values
(for the oldest timestamps) are NaN. Instead, it should fail.

This is a regression.

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

Kernel: Linux 5.10.0-10-amd64 (SMP w/1 CPU thread)
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rrdtool depends on:
ii  libc6 2.31-13+deb11u2
ii  libglib2.0-0  2.66.8-1
ii  librrd8   1.7.2-3+b7

rrdtool recommends no packages.

Versions of packages rrdtool suggests:
ii  librrds-perl  1.7.2-3+b7

-- no debconf information

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

Bug#1002976: installation-reports: Installer Fault Accessibility No Screen Reader Heard

[David J. Ring, Jr.]

Package: installation-reports
Severity: important
X-Debbugs-Cc: n...@arrl.net




-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="11 (bullseye) - installer build 20210731+deb11u2"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux debian 5.10.0-10-amd64 #1 SMP Debian 5.10.84-1 (2021-12-08) 
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Broadwell-U Host 
Bridge -OPI [8086:1604] (rev 09)
lspci -knn: Subsystem: Intel Corporation Device [8086:2010]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation HD 
Graphics 5500 [8086:1616] (rev 09)
lspci -knn: Subsystem: Intel Corporation Device [8086:2010]
lspci -knn: 00:03.0 Audio device [0403]: Intel Corporation Broadwell-U Audio 
Controller [8086:160c] (rev 09)
lspci -knn: Subsystem: Intel Corporation Device [8086:2010]
lspci -knn: Kernel driver in use: snd_hda_intel
lspci -knn: Kernel modules: snd_hda_intel
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Wildcat 
Point-LP MEI Controller #1 [8086:9cba] (rev 03)
lspci -knn: Subsystem: Intel Corporation Device [8086:7270]
lspci -knn: 00:19.0 Ethernet controller [0200]: Intel Corporation Ethernet 
Connection I218-LM [8086:155a] (rev 03)
lspci -knn: Subsystem: Intel Corporation Device [8086:]
lspci -knn: Kernel driver in use: e1000e
lspci -knn: Kernel modules: e1000e
lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation Wildcat Point-LP 
High Definition Audio Controller [8086:9ca0] (rev 03)
lspci -knn: Subsystem: Intel Corporation Device [8086:7270]
lspci -knn: Kernel driver in use: snd_hda_intel
lspci -knn: Kernel modules: snd_hda_intel
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation Wildcat Point-LP PCI 
Express Root Port #3 [8086:9c94] (rev e3)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.3 PCI bridge [0604]: Intel Corporation Wildcat Point-LP PCI 
Express Root Port #4 [8086:9c96] (rev e3)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.4 PCI bridge [0604]: Intel Corporation Wildcat Point-LP PCI 
Express Root Port #5 [8086:9c98] (rev e3)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation Wildcat Point-LP 
USB EHCI Controller [8086:9ca6] (rev 03)
lspci -knn: Subsystem: Intel Corporation Device [8086:7270]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation Wildcat Point-LP LPC 
Controller [8086:9cc3] (rev 03)
lspci -knn: Subsystem: Intel Corporation Device [8086:7270]
lspci -knn: 00:1f.2 SATA controller [0106]: Intel Corporation Wildcat Point-LP 
SATA Controller [AHCI Mode] [8086:9c83] (rev 03)
lspci -knn: Subsystem: Intel Corporation Device [8086:7270]
lspci -knn: Kernel driver in use: ahci
lspci -knn: Kernel modules: ahci
lspci -knn: 00:1f.3 SMBus [0c05]: Intel Corporation Wildcat Point-LP SMBus 
Controller [8086:9ca2] (rev 03)
lspci -knn: Subsystem: Intel Corporation Device [8086:7270]
lspci -knn: 00:1f.6 Signal processing controller [1180]: Intel Corporation 
Wildcat Point-LP Thermal Management Controller [8086:9ca4] (rev 03)
lspci -knn: Subsystem: Intel Corporation Device [8086:7270]
lspci -knn: 01:00.0 Ethernet controller [0200]: Intel Corporation I211 Gigabit 
Network Connection [8086:1539] (rev 03)
lspci -knn: Subsystem: Intel Corporation Device [8086:]
lspci -knn: Kernel driver in use: igb
lspci -knn: Kernel modules: igb
lspci -knn: 02:00.0 Network controller [0280]: Intel Corporation Wireless 8260 
[8086:24f3] (rev 3a)
lspci -knn: Subsystem: Intel Corporation Device [8086:10b0]
lspci -knn: Kernel driver in use: iwlwifi
lspci -knn: Kernel modules: iwlwifi
lspci -knn: 03:00.0 PCI bridge [0604]: PLX Technology, Inc. PEX 8603 3-lane, 
3-Port PCI Express Gen 2 (5.0 GT/s) Switch [10b5:8603] (rev ab)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 04:01.0 PCI bridge [0604]: PLX Technology, Inc. PEX 8603 3-lane, 
3-Port PCI Express Gen 2 (5.0 GT/s) Switch [10b5:8603] (rev ab)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 04:02.0 PCI bridge [0604]: PLX Technology, Inc. PEX 8603 3-lane, 
3-Port PCI Express Gen 2 (5.0 GT/s) Switch [10b5:8603] (rev ab)
lspci -knn: Kernel driver in use: pcieport
usb-list: 
usb-list: Bus 01 Device 01: EHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 5.10.0-10-amd64 ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 01 Device 02: EHCI Host 

Bug#916894: #916894 Wrong path to the source files

[Thomas Dickey]

upstream URLs still work.  I'm preparing an updated package.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#965445: #965445 byacc: Removal of obsolete debhelper compat 5 and 6 in bookworm

[Thomas Dickey]

I'm told that Dave Becket is MIA.

I'm in the process of preparing an update for this package,
and will maintain it in Debian henceforth.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#1002975: capnproto: please migrate capnproto 0.8.0 from experimental to unstable -> testing

[tony mancill]

Source: capnproto
Version: 0.7.0-7
Severity: wishlist

This is a tracking bug to get capnproto 0.8.0 into unstable.

Bug#1002819: autopkgtest: --pin-packages assumes that the release has a "Suite" name

[Iain Lane]

Hey Paul, Raphael, happy new year to you,

On Sat, Jan 01, 2022 at 10:05:21PM +0100, Paul Gevers wrote:
> Hi Raphael,
> 
> On 01-01-2022 21:37, Raphael Hertzog wrote:
> > On Fri, 31 Dec 2021, Paul Gevers wrote:
> > > > Otherwise I would like to suggest to create two entries, one with
> > > > "Pin: release a=foo" and one with "Pin: release n=foo" so that
> > > > we are sure to match on any of the 3 fields.
> > > 
> > > I'll have to check and think about this. I remember that I had lots of
> > > issues with coming up with changes to autopkgtest that also worked for
> > > Ubuntu, as they use the same Codename for the real Suite and the 
> > > *-proposed
> > > Suite (which they call pocket). I don't recall if that was with respect to
> > > pinning or other aspects of autopkgtest and it's requirement to manipulate
> > > where packages should be installed from. Before committing your proposal I
> > > need to understand that I'm not breaking existing valid configurations 
> > > too.
> > 
> > I saw a comment mentionning this, but it was related to the "--apt-pocket"
> > option and I didn't change that part, which still uses the "a=foo" syntax.
> > 
> > https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/lib/adt_testbed.py#L1263
> 
> Right, thanks for referencing that line as it has the bug number where the
> relevant information was. As the --pin-packages option will already have the
> *-pocket in the name, I think this would work for Ubuntu too. CC-ing Iain
> for a sanity check on our reasoning.

Thanks for copying me on this. Julian might be a good one also.

I fear I've probably forgotten most of these details, so please pardon 
me for this response… Wasn't the problem for Ubuntu that 'Pin: release 
foo' also applies to foo-proposed too? I think 'Pin: release 
foo-proposed' will work as intended though, right?  Is the latter what 
we'll start generating with this? Seeing some example generated pins 
(before / after the patch) would be great to help reason about this.

I guess a test covering this for all of the Ubuntu, Debian & Kali cases 
would be helpful in terms of confidence both with this change and making 
any future changes here. The one thing I do remember is that it's hairy, 
like all the pinning stuff in autopkgtest. :-)

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]


signature.asc
Description: PGP signature

Bug#1002921: installation-reports: No Screen Reader, Cannot boot into MATE GUI, Root only can

[D.J.J. Ring, Jr.]

I made a new partition for /home and I reinstalled Debian, this time I
could lot in to MATE and I could log into the CLI.

But the issue remains of after the Installation disk detects my sound card,
it seems to find my sound card, but immediately after finding it, no
further sound is heard.

This remains.

Thanks for the help.

David


On Sat, Jan 1, 2022 at 6:16 PM D.J.J. Ring, Jr.  wrote:

> I don't know why when using the installer, not hearring espeak in console
> isn't a installer issue.
>
> I believe I have already done what you are speaking of.
>
> I have /home/djringjr.
>
> At first I reused this, the installer permits NOT formatting a separate
> /home partition.  That's what I did.
>
> I had problems I could not log in as my regular named user using my old
> /home/djringjr files.
>
> Then I reran the installer - again no sound during accessible
> installation, This time I made up a brand new never before user name.
>
> The result was the very same, I could not log in with my user account,
> only root.
>
> What is your next suggestion?
>
> There is an installer issue, not having speech during an accessible
> installation is an installer issue .
>
> Making a brand new user account and not being able to log in might be
> something else.  Where do I go to get this part fixed?
>
> Thanks,
> David
>
> On Sat, Jan 1, 2022 at 5:22 PM Holger Wansing 
> wrote:
>
>> Hi,
>>
>> Am 1. Januar 2022 21:38:39 MEZ schrieb "D.J.J. Ring, Jr." > >:
>> >No on the first run after installation, I cannot log in using my user
>> >account.
>> >
>> >I tried installation again, still keeping /home partition data but using
>> a
>> >brand-new user account. This installation also failed in the exact same
>> >way.  I had voice at the lightdm login prompt but I could not log in. I
>> >could log in as previously by using root.
>> >
>> >So reusing by /home/djringjr folder won't let me log in, using a
>> brand-new
>> >user account with brand new files from /etc/skel won't let me run the
>> GUI.
>>
>> When performing a default installation it is known, that logging in as a
>> normal user.
>>
>> So, if you have over and over the same issue, using that unusual
>> installation
>> concept (re-using pre-existing home data), which is not officially
>> supported by
>> the installer, you should probably try a default install, without any
>> old-home-data
>> tricks - just for a test.
>>
>> If that works, you could then carefully merge your home data back into
>> the new
>> system.
>>
>>
>> In summary, this all is not an installer issue, by the way.
>>
>> Holger
>>
>>
>>
>>
>> --
>> Sent from /e/ OS on Fairphone3
>>
>

Bug#1002974: dtc: Removal of obsolete debhelper compat 5 and 6 in bookworm

[Andreas Beckmann]

Source: dtc
Version: 0.35.5-1
Severity: serious
Tags: ftbfs
User: nthyk...@master.debian.org
Usertags: compat-5-6-removal

Hi,

The package dtc uses debhelper with a compat level of 5 or 6,
which is no longer supported [1].

Please bump the debhelper compat at your earliest convenience

  * Compat 13 is recommended (supported in stable-backports)

  * Compat 7 is the bare minimum


Thanks,
Andreas

[1] https://lists.debian.org/debian-devel/2020/07/msg00065.html

Bug#1002973: ITP: python-pytest-djangoapp -- Django pluggable application testing

[Michael Fladischer]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-pytest-djangoapp
  Version : 0.15.2
  Upstream Author : Igor Starikov 
* URL : https://github.com/idlesign/pytest-djangoapp/
* License : BSD-3-clause
  Programming Lang: Python
  Description : Django pluggable application testing


 This exposes some useful tools for Django applications developers to facilitate
 tests authoring, including:
 .
  * Settings overriding
  * Template tags testing
  * User creation
  * Request object creation
  * Management command calls
  * Mailing
  * Messages
  * DB queries audit

I intend to maintain this package as part of the DPT.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmHQ5WwRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WppiQf+Puvg87mRd+oTEpOtfHGyWpPZQfx1NJiS
kBas4phWBMv483Yrex71sXxqUCP++THkNuo3ho39WguVAVO06rG/YH6Gb8QfMGd9
CPMWHApjhxtO+lIvuCZyitgwXRMcb2lIqkd3PgmBKt1yluGg1/TTL0xvlvAau9AV
PY/D5DXj1GlBBwvyypJ2hOKe1fx3yt05qUKk3XFu2bGy0QwQG32nT34CtcIAcA2M
NxkcxGyTF4K0ltFnz0Bm8COCt65etN1B+uy2Ct5sSGbMlHY57G9bOiVd35UHrHmG
RsJKYZqGWc1154cryAjzvKXpTWpxMgzjZFwjHm8Cvuhwj/TBsSWw7A==
=Ftr+
-END PGP SIGNATURE-

Bug#1002972: qtfeedback-opensource-src: ftbfs on hppa - /usr/lib/qt5/bin/qdoc: not found

[John David Anglin]

Source: qtfeedback-opensource-src
Version: 5.0~git20180903.a14bd0b-1
Severity: normal

Dear Maintainer,

Build fails here:
make docs
make[2]: Entering directory '/<>'
make -f Makefile html_docs && make -f Makefile qch_docs
make[3]: Entering directory '/<>'
make -f Makefile prepare_docs && make -f Makefile generate_docs
make[4]: Entering directory '/<>'
cd src/ && ( test -e Makefile || /usr/lib/qt5/bin/qmake -o Makefile 
/<>/src/src.pro 'QMAKE_CFLAGS_RELEASE=-g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2' 'QMAKE_CFLAGS_DEBUG=-g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2' 'QMAKE_CXXFLAGS_RELEASE=-g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2' 'QMAKE_CXXFLAGS_DEBUG=-g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2' QMAKE_STRIP=: PREFIX=/usr ) && make -f 
Makefile prepare_docs
make[5]: Entering directory '/<>/src'
cd feedback/ && ( test -e Makefile || /usr/lib/qt5/bin/qmake -o Makefile 
/<>/src/feedback/feedback.pro 'QMAKE_CFLAGS_RELEASE=-g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2' 'QMAKE_CFLAGS_DEBUG=-g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2' 'QMAKE_CXXFLAGS_RELEASE=-g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2' 'QMAKE_CXXFLAGS_DEBUG=-g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2' QMAKE_STRIP=: PREFIX=/usr ) && make -f 
Makefile prepare_docs
make[6]: Entering directory '/<>/src/feedback'
/usr/lib/qt5/bin/qtattributionsscanner '/<>' --filter 
QDocModule=qtfeedback -o '/<>/src/feedback/codeattributions.qdoc'
'/<>/src/feedback/qdoc_wrapper.sh' -outputdir 
'/<>/doc/qtfeedback' -installdir /usr/share/qt5/doc 
/<>/src/feedback/../../doc/qtfeedback.qdocconf -prepare -indexdir 
/usr/share/qt5/doc -no-link-errors -I. -I../../include 
-I../../include/QtFeedback -I../../include/QtFeedback/5.0.0 
-I../../include/QtFeedback/5.0.0/QtFeedback -I/usr/include/hppa-linux-gnu/qt5 
-I/usr/include/hppa-linux-gnu/qt5/QtCore -I.moc 
-I/usr/lib/hppa-linux-gnu/qt5/mkspecs/linux-g++ -I/usr/include/c++/11 
-I/usr/include/hppa-linux-gnu/c++/11 -I/usr/include/c++/11/backward 
-I/usr/lib/gcc/hppa-linux-gnu/11/include -I/usr/local/include 
-I/usr/include/hppa-linux-gnu -I/usr/include
/<>/src/feedback/qdoc_wrapper.sh: 12: exec: /usr/lib/qt5/bin/qdoc: 
not found
make[6]: *** [Makefile:405: prepare_docs] Error 127

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=qtfeedback-opensource-src=hppa=5.0%7Egit20180903.a14bd0b-1=1641013764=0

/usr/lib/qt5/bin/qdoc is provided by qdoc-qt5 package.  It is not built on
hppa since it requires clang.

Similar fail is present on ia64.

Regards,
Dave Anglin

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

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

Bug#1002971: RM: python-aiortc/experimental -- RoQA; NVIU; new versions build on fewer architectures

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

Please clean up the cruft python-aiortc source packages in experimental,
the current version in sid no longer builds on mips*, ppc64el, s390x.

python-aiortc | 0.9.28-1  | experimental   | source
python-aiortc | 0.9.28-2  | experimental   | source
python-aiortc | 1.2.1-3   | testing| source
python-aiortc | 1.2.1-3   | unstable   | source
python-aiortc | 1.2.1-3   | unstable-debug | source

Andreas

Bug#1002921: installation-reports: No Screen Reader, Cannot boot into MATE GUI, Root only can

[D.J.J. Ring, Jr.]

I don't know why when using the installer, not hearring espeak in console
isn't a installer issue.

I believe I have already done what you are speaking of.

I have /home/djringjr.

At first I reused this, the installer permits NOT formatting a separate
/home partition.  That's what I did.

I had problems I could not log in as my regular named user using my old
/home/djringjr files.

Then I reran the installer - again no sound during accessible installation,
This time I made up a brand new never before user name.

The result was the very same, I could not log in with my user account, only
root.

What is your next suggestion?

There is an installer issue, not having speech during an accessible
installation is an installer issue .

Making a brand new user account and not being able to log in might be
something else.  Where do I go to get this part fixed?

Thanks,
David

On Sat, Jan 1, 2022 at 5:22 PM Holger Wansing  wrote:

> Hi,
>
> Am 1. Januar 2022 21:38:39 MEZ schrieb "D.J.J. Ring, Jr." :
> >No on the first run after installation, I cannot log in using my user
> >account.
> >
> >I tried installation again, still keeping /home partition data but using a
> >brand-new user account. This installation also failed in the exact same
> >way.  I had voice at the lightdm login prompt but I could not log in. I
> >could log in as previously by using root.
> >
> >So reusing by /home/djringjr folder won't let me log in, using a brand-new
> >user account with brand new files from /etc/skel won't let me run the GUI.
>
> When performing a default installation it is known, that logging in as a
> normal user.
>
> So, if you have over and over the same issue, using that unusual
> installation
> concept (re-using pre-existing home data), which is not officially
> supported by
> the installer, you should probably try a default install, without any
> old-home-data
> tricks - just for a test.
>
> If that works, you could then carefully merge your home data back into the
> new
> system.
>
>
> In summary, this all is not an installer issue, by the way.
>
> Holger
>
>
>
>
> --
> Sent from /e/ OS on Fairphone3
>

Bug#1002970: qtpim-opensource-src: ftbfs on hppa - build requires /usr/lib/qt5/bin/qdoc

[John David Anglin]

Source: qtpim-opensource-src
Version: 5.0~git20190618.8fec622c+dfsg1-8
Severity: normal

Dear Maintainer,

Build fails here:
make docs
make[2]: Entering directory '/<>'
make -f Makefile html_docs && make -f Makefile qch_docs
make[3]: Entering directory '/<>'
make -f Makefile prepare_docs && make -f Makefile generate_docs
make[4]: Entering directory '/<>'
cd src/ && ( test -e Makefile || /usr/lib/qt5/bin/qmake -o Makefile 
/<>/src/src.pro 'QMAKE_CFLAGS_RELEASE=-g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2' 'QMAKE_CFLAGS_DEBUG=-g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2' 'QMAKE_CXXFLAGS_RELEASE=-g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2' 'QMAKE_CXXFLAGS_DEBUG=-g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2' QMAKE_STRIP=: PREFIX=/usr 
QT_BUILD_PARTS+=tests ) && make -f Makefile prepare_docs
make[5]: Entering directory '/<>/src'
cd contacts/ && ( test -e Makefile || /usr/lib/qt5/bin/qmake -o Makefile 
/<>/src/contacts/contacts.pro 'QMAKE_CFLAGS_RELEASE=-g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2' 'QMAKE_CFLAGS_DEBUG=-g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2' 'QMAKE_CXXFLAGS_RELEASE=-g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2' 'QMAKE_CXXFLAGS_DEBUG=-g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2' QMAKE_STRIP=: PREFIX=/usr 
QT_BUILD_PARTS+=tests ) && make -f Makefile prepare_docs
make[6]: Entering directory '/<>/src/contacts'
/usr/lib/qt5/bin/qtattributionsscanner '/<>' --filter 
QDocModule=qtcontacts -o '/<>/src/contacts/codeattributions.qdoc'
'/<>/src/contacts/qdoc_wrapper.sh' -outputdir 
'/<>/doc/qtcontacts' -installdir /usr/share/qt5/doc 
/<>/src/contacts/doc/qtcontacts.qdocconf -prepare -indexdir 
/usr/share/qt5/doc -no-link-errors -I. -Idetails -I. -Iengines -Ifilters 
-Irequests -I../../include -I../../include/QtContacts 
-I../../include/QtContacts/5.0.0 -I../../include/QtContacts/5.0.0/QtContacts 
-I/usr/include/hppa-linux-gnu/qt5/QtCore/5.15.2 
-I/usr/include/hppa-linux-gnu/qt5/QtCore/5.15.2/QtCore 
-I/usr/include/hppa-linux-gnu/qt5 -I/usr/include/hppa-linux-gnu/qt5/QtCore 
-I.moc -I/usr/lib/hppa-linux-gnu/qt5/mkspecs/linux-g++ -I/usr/include/c++/11 
-I/usr/include/hppa-linux-gnu/c++/11 -I/usr/include/c++/11/backward 
-I/usr/lib/gcc/hppa-linux-gnu/11/include -I/usr/local/include 
-I/usr/include/hppa-linux-gnu -I/usr/include
/<>/src/contacts/qdoc_wrapper.sh: 12: exec: /usr/lib/qt5/bin/qdoc: 
not found
make[6]: *** [Makefile:663: prepare_docs] Error 127

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=qtpim-opensource-src=hppa=5.0%7Egit20190618.8fec622c%2Bdfsg1-8=1641014083=0

/usr/lib/qt5/bin/qdoc is provided qdoc-qt5 package.  It is not built on
hppa because it requires.  As a result, qt html documentation can't be built
on hppa and other targets that don't support clang.

I tried working around this issue by modifying control but this didn't work.

Regards,
Dave Anglin

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

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

Bug#1002969: golang-github-smallstep-certificates: FTBFS due to several test failures

[Andreas Beckmann]

Source: golang-github-smallstep-certificates
Version: 0.15.15-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi,

golang-github-smallstep-certificates recently started to FTBFS after
some build-dependency got updated.

I've successfully built the package on amd64 on Sept 3 and on i386 on Oct 14.
New attempts in December failed.

$ grep FAIL golang-github-smallstep-certificates_0.15.15-1.log
--- FAIL: TestTLSALPN01Validate (3.22s)
--- FAIL: TestTLSALPN01Validate/ok/error-no-protocol (0.00s)
--- FAIL: TestTLSALPN01Validate/fail/no-protocol-store-error (0.00s)
--- FAIL: TestTLSALPN01Validate/ok/tlsDial-timeout (1.00s)
FAIL
FAILgithub.com/smallstep/certificates/acme  3.278s
--- FAIL: TestNew (0.00s)
--- FAIL: TestNew/ok_with_uri (0.00s)
FAIL
FAILgithub.com/smallstep/certificates/kms/awskms0.005s
--- FAIL: TestNew (0.00s)
--- FAIL: TestNew/ok (0.00s)
--- FAIL: TestNew/ok_with_serial (0.00s)
--- FAIL: TestNew/ok_with_slot-id (0.00s)
--- FAIL: TestNew/ok_with_pin (0.00s)
--- FAIL: TestPKCS11_GetPublicKey (0.00s)
--- FAIL: TestPKCS11_GetPublicKey/RSA (0.00s)
--- FAIL: TestPKCS11_GetPublicKey/RSA_by_id (0.00s)
--- FAIL: TestPKCS11_GetPublicKey/RSA_by_label (0.00s)
--- FAIL: TestPKCS11_GetPublicKey/ECDSA (0.00s)
--- FAIL: TestPKCS11_GetPublicKey/ECDSA_by_id (0.00s)
--- FAIL: TestPKCS11_GetPublicKey/ECDSA_by_label (0.00s)
--- FAIL: TestPKCS11_CreateKey (0.00s)
--- FAIL: TestPKCS11_CreateKey/default (0.00s)
--- FAIL: TestPKCS11_CreateKey/RSA_SHA256WithRSA (0.00s)
--- FAIL: TestPKCS11_CreateKey/RSA_SHA384WithRSA (0.00s)
--- FAIL: TestPKCS11_CreateKey/RSA_SHA512WithRSA (0.00s)
--- FAIL: TestPKCS11_CreateKey/RSA_SHA256WithRSAPSS (0.00s)
--- FAIL: TestPKCS11_CreateKey/RSA_SHA384WithRSAPSS (0.00s)
--- FAIL: TestPKCS11_CreateKey/RSA_SHA512WithRSAPSS (0.00s)
--- FAIL: TestPKCS11_CreateKey/RSA_2048 (0.00s)
--- FAIL: TestPKCS11_CreateKey/RSA_4096 (0.00s)
--- FAIL: TestPKCS11_CreateKey/ECDSA_P256 (0.00s)
--- FAIL: TestPKCS11_CreateKey/ECDSA_P384 (0.00s)
--- FAIL: TestPKCS11_CreateKey/ECDSA_P521 (0.00s)
--- FAIL: TestPKCS11_CreateSigner (0.00s)
--- FAIL: TestPKCS11_CreateSigner/RSA (0.00s)
--- FAIL: TestPKCS11_CreateSigner/RSA_PSS (0.00s)
--- FAIL: TestPKCS11_CreateSigner/ECDSA_P256 (0.00s)
--- FAIL: TestPKCS11_CreateSigner/ECDSA_P384 (0.00s)
--- FAIL: TestPKCS11_CreateSigner/ECDSA_P521 (0.00s)
--- FAIL: TestPKCS11_LoadCertificate (0.00s)
--- FAIL: TestPKCS11_LoadCertificate/load (0.00s)
--- FAIL: TestPKCS11_LoadCertificate/load_by_id (0.00s)
--- FAIL: TestPKCS11_LoadCertificate/load_by_label (0.00s)
--- FAIL: TestPKCS11_LoadCertificate/load_by_serial (0.00s)
--- FAIL: TestPKCS11_StoreCertificate (0.00s)
--- FAIL: TestPKCS11_StoreCertificate/ok (0.00s)
--- FAIL: TestPKCS11_DeleteKey (0.00s)
--- FAIL: TestPKCS11_DeleteKey/delete (0.00s)
--- FAIL: TestPKCS11_DeleteKey/delete_by_id (0.00s)
--- FAIL: TestPKCS11_DeleteKey/delete_by_label (0.00s)
--- FAIL: TestPKCS11_DeleteKey/delete_missing (0.00s)
--- FAIL: TestPKCS11_DeleteKey/fail_name (0.00s)
--- FAIL: TestPKCS11_DeleteKey/fail_FindKeyPair (0.00s)
--- FAIL: TestPKCS11_DeleteCertificate (0.00s)
--- FAIL: TestPKCS11_DeleteCertificate/delete (0.00s)
--- FAIL: TestPKCS11_DeleteCertificate/delete_by_id (0.00s)
--- FAIL: TestPKCS11_DeleteCertificate/delete_by_label (0.00s)
--- FAIL: TestPKCS11_DeleteCertificate/delete_missing (0.00s)
--- FAIL: TestPKCS11_DeleteCertificate/fail_name (0.00s)
--- FAIL: TestPKCS11_DeleteCertificate/fail_DeleteCertificate (0.00s)
--- FAIL: TestPKCS11_Close (0.00s)
FAIL
FAILgithub.com/smallstep/certificates/kms/pkcs110.006s
--- FAIL: TestParse (0.00s)
--- FAIL: TestParse/ok_query (0.00s)
--- FAIL: TestURI_Get (0.00s)
--- FAIL: TestURI_GetEncoded (0.00s)
FAIL
FAILgithub.com/smallstep/certificates/kms/uri   0.002s
FAIL

I'm not going to attach the full 64MB build logfile.


Andreas

Bug#1002968: tbb: cmake support missing on ports architectures

[Aurelien Jarno]

Source: tbb
Version: 2020.3-1
Severity: important
User: debian-ri...@lists.debian.org
Usertags: riscv64

libtbb-dev only provides cmake files on official architectures, due to
this entry in debian/control:

| Build-Depends: debhelper-compat (= 12),
|libjs-jquery,
|dh-exec,
|gdb,
|    cmake [amd64 i386 arm64 armhf mips64el mipsel ppc64el s390x],

This causes some packages build-depending on libtbb-dev to fail to build
from sources on architectures not in the above list:
https://buildd.debian.org/status/fetch.php?pkg=slic3r-prusa=riscv64=2.4.0%2Bdfsg-1=1640971630=0

Therefore, could you please drop the architectures list from the
Build-Depends, as it is available on all architectures, including ports
ones?

Thanks,
Aurelien

Bug#1002967: php-doctrine-bundle: FTBFS in current sid

[Andreas Beckmann]

Source: php-doctrine-bundle
Version: 2.2.3-1
Severity: serious
Tags: ftbfs sid bookworm experimental
Justification: fails to build from source
Control: found -1 2.3.2-1

Hi,

php-doctrine-bundle recently started to FTBFS in sid and experimental
due to some updated build-dependency:


sid (2.2.3-1):

There were 2 failures:

1) 
Doctrine\Bundle\DoctrineBundle\Tests\DependencyInjection\XmlDoctrineExtensionTest::testAttachEntityListenersTwoConnections
Method 'addEventListener' is expected to be called once, definition does not 
contain a call though.

/build/php-doctrine-bundle-2.2.3/Tests/DependencyInjection/AbstractDoctrineExtensionTest.php:1263
/build/php-doctrine-bundle-2.2.3/Tests/DependencyInjection/AbstractDoctrineExtensionTest.php:1022

2) 
Doctrine\Bundle\DoctrineBundle\Tests\DependencyInjection\YamlDoctrineExtensionTest::testAttachEntityListenersTwoConnections
Method 'addEventListener' is expected to be called once, definition does not 
contain a call though.

/build/php-doctrine-bundle-2.2.3/Tests/DependencyInjection/AbstractDoctrineExtensionTest.php:1263
/build/php-doctrine-bundle-2.2.3/Tests/DependencyInjection/AbstractDoctrineExtensionTest.php:1022

ERRORS!
Tests: 251, Assertions: 720, Errors: 44, Failures: 2.


experimental (2.3.2-1):

   debian/rules override_dh_auto_test
make[1]: Entering directory '/build/php-doctrine-bundle-2.3.2'
SYMFONY_DEPRECATIONS_HELPER=99 phpunit -v
PHP Fatal error:  Class Doctrine\Bundle\DoctrineBundle\Tests\FakeDriver 
contains 1 abstract method and must therefore be declared abstract or implement 
the remaining methods (Doctrine\DBAL\Driver::getExceptionConverter) in 
/build/php-doctrine-bundle-2.3.2/Tests/ConnectionFactoryTest.php on line 107

Andreas


sid.build.gz
Description: application/gzip


experimental.build.gz
Description: application/gzip

Bug#1002921: installation-reports: No Screen Reader, Cannot boot into MATE GUI, Root only can

[D.J.J. Ring, Jr.]

To be clear,

On the first run after installation, I could not log in using my user
account.

I tried installation again, still keeping /home partition data but using a
brand-new user account. This installation also failed in the exact same
way. I had voice at the lightdm login prompt but I could not log in. I
could log in as previously by using root.

At that time, I didn't know a way to disable lightdm login and just log in
with the console. I suspect I'd get the same result as I do now, that I
could not log in with any user account, only the supervisor account, root.
At that time, I just suspected that my user account was just having
problems accessing Xorg, that's why I included the Xorg error logs, now I
see that the problem goes beyond this, that I cannot log in with any user
either using my old djringjr home folder which works if I reinstall latest
Debian 10, nor a previously non-existing username which created new file
folder populated by /etc/skel files.

I was able in all cases able to log into both the cli and the GUI with root.

I was able to log into root in the CLI then su to my original username in
all cases but starting GUI still failed.

Regards,

David



On Sat, Jan 1, 2022, 15:38 D.J.J. Ring, Jr.  wrote:

> No on the first run after installation, I cannot log in using my user
> account.
>
> I tried installation again, still keeping /home partition data but using a
> brand-new user account. This installation also failed in the exact same
> way.  I had voice at the lightdm login prompt but I could not log in. I
> could log in as previously by using root.
>
> So reusing by /home/djringjr folder won't let me log in, using a brand-new
> user account with brand new files from /etc/skel won't let me run the GUI.
>
> Since then I've discovered with my current installation not only can't I
> access the GUI but additionally I cannot access the CLI at least directly.
> I can login as root then su to my user name and access my user CLI but
> running startx still fails.
>
> I can install the last version of the previous Debian before Bullseye
> perfectly with my current /home folder.
>
> Best wishes,
>
> David
>
> Regards,
>
>
>
> On Sat, Jan 1, 2022, 14:39 Holger Wansing  wrote:
>
>> Hi,
>>
>> "D.J.J. Ring, Jr."  wrote (Sat, 1 Jan 2022 13:37:20
>> -0500):
>> > 1.  Cannot boot into MATE GUI means that I cannot boot into the MATE
>> > Graphical User Interface with the user account - which is what is
>> expected
>> > to happen after a normal successful installation.   I did some
>> > investigation  into this.
>> >
>> > This is what I did:  .  I disabled lightdm using systemctl disable
>> lightdm
>> > then more recently I used the root command "systemctl set-default
>> > multi-user.target" and now I see I cannot even log in as my regular
>> user.
>>
>> This is what I had expected, so in the first run it's not an issue with
>> the
>> MATE GUI.
>>
>> > I tried a new named user and did the same installation, I had the very
>> same
>> > problems with the new username.
>> >
>> > My /home/djringjr/ folder was used successfully with the last Debian
>> Buster
>> > release.
>>
>> Hmm, I wonder what that means exactly, as well as the following sentence:
>>
>> > [...]  When
>> > installing for my normal user account, I do not format /home/myuser
>> folder.
>>
>> Do you re-use an old/existing home folder of some user account somehow
>> for the
>> new user?
>> I don't know if that is supposed to work.
>> I only know the szenario, where a complete new home folder is created
>> automatically, when a new user is added to the system (with the "useradd"
>> command).
>>
>> > I have entered the root account and re-entered my useraccount
>> password.  I
>> > have done this several times.  Remember this also happened when I had an
>> > entirely new user account with a newly made /home/newuser folder.
>>
>> So you have tried, to log in as root on the console and type
>> "adduser yourusername" to create a completely new user?
>> And see if you can successfully login into that new account with
>> "su -l yourusername" ?
>>
>>
>> > I know the username password is correct because as root I enter "su
>> > myusername" and I am in user account, then from my user account,  I type
>> > "su myusername" and I receive a prompt for my password.  I have further
>> > checked by entering an incorrect password and received "authentication
>> > failure" response.
>> >
>> > root@debian:~# su djringjr
>> > djringjr@debian:/root$ su djringjr
>> > Password: [I enter the correct password\
>> > djringjr@debian:/root$ exit
>> > exit
>> > djringjr@debian:/root$ su djringjr
>> > Password: [I enter an incorrect password\
>> > su: Authentication failure
>> > djringjr@debian:/root$
>> >
>> > You asked me to state the problems again, here they are.
>> >
>> > 1. During installation I chose accessible text installation, the
>> installer
>> > appeared to detect my sound card, but after that I hear no sound from
>> the
>> > screen reader.
>>
>> That might be 

Bug#1002966: selfhtml: Removal of obsolete debhelper compat 5 and 6 in bookworm

[Andreas Beckmann]

Source: selfhtml
Version: 8.1.2-1
Severity: serious
Tags: sid bookworm
User: nthyk...@master.debian.org
Usertags: compat-5-6-removal

Hi,

The package selfhtml uses debhelper with a compat level of 5 or 6,
which is no longer supported [1].

Please bump the debhelper compat at your earliest convenience

  * Compat 13 is recommended (supported in stable-backports)

  * Compat 7 is the bare minimum


Thanks,
Andreas

[1] https://lists.debian.org/debian-devel/2020/07/msg00065.html

Bug#1002543: git-revise: please use package section vcs (not devel)

[Nicolas Schier]

tags 1002543 + pending confirmed

Hi Jonas,

> I notice that package git-revise is in package section "devel".
...
> Please change package section to vcs - 
...

thanks for your bug report!  I can't reconstruct why I chose package
section "devel" initially, thus I will follow your suggestion and change it
to "vcs" [1].  Upload will be prepared soon.

Kind regards and godt nytår!
Nicolas


[1]: 
https://salsa.debian.org/nsc/git-revise/-/commit/b9494c66f89f8bef0421930a29af6529c59840e7
-- 
epost|xmpp: nico...@fjasle.eu  irc://oftc.net/nsc
↳ gpg: 18ed 52db e34f 860e e9fb  c82b 7d97 0932 55a0 ce7f
 -- frykten for herren er opphav til kunnskap --

Bug#1002965: opens last ebook when asked to open corrupt file

[Joey Hess]

Package: fbreader
Version: 0.12.10dfsg2-5
Severity: normal

touch foo.epub
fbreader foo.epub 

This will display whatever ebook you last had open in fbreader, without
any indication that there's a problem with the file it was asked to open.

In some situations, this can be very confusing behavior.

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

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

Versions of packages fbreader depends on:
ii  libc6  2.32-4
ii  libsqlite3-0   3.36.0-2
ii  libstdc++6 11.2.0-12
ii  libzlcore0.13  0.12.10dfsg2-5
ii  libzltext0.13  0.12.10dfsg2-5
ii  libzlui-gtk0.12.10dfsg2-5

Versions of packages fbreader recommends:
ii  sensible-utils  0.0.17

fbreader suggests no packages.

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#1002583: O: pymongo

[Agathe Porte]

Control: -1 retitle ITP: pymongo

Hi,

31/12/2021 01:50, Sandro Tosi :

then please retitle to ITA

Done with above control command, hopefully.

https://salsa.debian.org/python-team/packages/pymongo

Bug will be closed when package will be ready for upload with DPT as
maintainer.

via debian/changelog?


Yes, see current propored d/changelog [1]:

[ Agathe Porte ]
* d/control: Fix build warnings
* d/copyright: Update authors
* d/upstream/metadata: add Bug-Database
* d/watch: mangle in personal devscripts instead
* d/changelog: update Maintainer to DPT (Closes: #1002583)
* d/control: Fix multiarch metadata

[1] 
https://salsa.debian.org/python-team/packages/pymongo/-/blob/55ff707918c79017f665533e37a588aefe69d75a/debian/changelog


Bests

Bug#712979: debbugs: get_bug_log can incorrectly return an e-mail body with xsi:type="xsd:long"

[Don Armstrong]

On Sat, 01 Jan 2022, Nis Martensen wrote:
> On 31.12.2021 Don Armstrong wrote in #1002595:
> > [Really, it's past time for us to support a REST interface and
> > abandon the SOAP interface.]
> Just wondering: Don, how much effort would you estimate is this? Do you
> have plans for working on this? Could this be a suitable project for a
> summer of code contribution?

I'm currently working on it, but my available time is so minimal, that
additional help would be welcome.

My current plan is to reimplement the log and database reading pieces in
python (SQLAlchemy + FastAPI) so that the number of people who can
contribute to the web frontend parts is significantly larger. [I've
started in on this, but it's slow going.]

-- 
Don Armstrong  https://www.donarmstrong.com

No matter how many instances of white swans we may have observed, this
does not justify the conclusion that all swans are white.
 -- Sir Karl Popper _Logic of Scientific Discovery_

Bug#1002840: ftp.debian.org: repo-source never updates new DEP-11/appstream-data in stable so screenshots fail HTTP 404 in gnome-software

[Jano John Akim Franke]

I believe the root cause is in 
https://salsa.debian.org/ftp-team/dak/-/blob/master/config/debian/dinstall.variables#L25

<<<
# dists for which we import external data (i18n, dep11)
# as thats usually testing and unstable, but we need codenames,
# get em out of the db.
extimportdists=""
if [ "${functionname}" = ftp-master.debian.org ]; then
  for suite in testing unstable; do
codename=$(dak admin suite-config get-value ${suite} codename)
extimportdists="${extimportdists} ${codename}"
  done
fi




${extimportdists} is later used for iteration in function dep11() in 
https://salsa.debian.org/ftp-team/dak/-/blob/master/config/debian/dinstall.functions#L106
 so only testing and unstable have updated AppStream-data.

https://blog.tenstral.net/2015/12/appstreamdep-11-fully-supported-in-debian-now.html
 and the debian wiki promote otherwise:

The second thing is full DEP-11 support in Debian! This means that you don’t 
need to copy metadata around manually, or install extra packages: All you need 
to do is to install the appstream package, everything else is done for you, and 
the data is kept up to date automatically.

This is made possible by APT 1.1 (thanks to the whole APT team!), some 
dedicated support for it in AppStream directly, the work of our Sysadmin team 
at Debian, which set up infrastructure to build the metadata automatically, as 
well as our FTPMasters team where Joerg helped with the final steps of getting 
the metadata into the archive.

Bug#1002819: autopkgtest: --pin-packages assumes that the release has a "Suite" name

[Paul Gevers]

Hi Raphael,

On 01-01-2022 21:37, Raphael Hertzog wrote:

On Fri, 31 Dec 2021, Paul Gevers wrote:

Otherwise I would like to suggest to create two entries, one with
"Pin: release a=foo" and one with "Pin: release n=foo" so that
we are sure to match on any of the 3 fields.


I'll have to check and think about this. I remember that I had lots of
issues with coming up with changes to autopkgtest that also worked for
Ubuntu, as they use the same Codename for the real Suite and the *-proposed
Suite (which they call pocket). I don't recall if that was with respect to
pinning or other aspects of autopkgtest and it's requirement to manipulate
where packages should be installed from. Before committing your proposal I
need to understand that I'm not breaking existing valid configurations too.


I saw a comment mentionning this, but it was related to the "--apt-pocket"
option and I didn't change that part, which still uses the "a=foo" syntax.

https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/lib/adt_testbed.py#L1263


Right, thanks for referencing that line as it has the bug number where 
the relevant information was. As the --pin-packages option will already 
have the *-pocket in the name, I think this would work for Ubuntu too. 
CC-ing Iain for a sanity check on our reasoning.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001709: amule-daemon: amuled crashes with segmentation fault on startup

[Sven Geuer]

I cannot reproduce this bug any more. Connecting to the Kademlia
network works again without any issues.

No packages had been upgraded since the initial bug report.

I suggest to reduce the bug's severity to normal.

-- 
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585


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

Bug#1002964: netpanzer: FTBFS with SCons 4.2.0+

[GCS]

Source: netpanzer
Version: 0.8.7+ds-4
Severity: important
Tags: patch

Hi,

SCons 4.3.0 was released some time ago. I've packaged it and would
like to upload it in the next day or so. Your package FTBFS with that,
for which a patch is attached to fix it.

Regards,
Laszlo/GCS
Description: SCons 4.2.0 no longer has env.has_key()
 Check env as an array.
Author: Laszlo Boszormenyi (GCS) 
Forwarded: no
Last-Update: 2022-01-01

---

--- netpanzer-0.8.7+ds.orig/SConstruct
+++ netpanzer-0.8.7+ds/SConstruct
@@ -237,7 +237,7 @@ npdirs = """
 """
 
 env.Append( NPSOURCES = globSources(env, 'src/NetPanzer', npdirs, "*.cpp") )
-if env.has_key('WINICON'):
+if 'WINICON' in env:
 env.Append( NPSOURCES = env['WINICON'] )
 
 env.Prepend( LIBS = ['np2d','lua5.1','npnetwork','nplibs','physfs'] )

Bug#965696: libwhisker2-perl: diff for NMU version 2.5-1.2

[Vincent Bernat]

Thanks! If you want to take over this package, be my guest!

On January 1, 2022 6:35:04 PM GMT+01:00, gregor herrmann  
wrote:
>Control: tags 965696 + patch
>Control: tags 965696 + pending
>Control: tags 999044 + patch
>Control: tags 999044 + pending
>
>
>Dear maintainer,
>
>I've prepared an NMU for libwhisker2-perl (versioned as 2.5-1.2) and
>uploaded it to DELAYED/5. Please feel free to tell me if I
>should delay it longer.
>
>Regards.
>
>
>-- 
> .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
> : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
> `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
>   `-   

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#712979: debbugs: get_bug_log can incorrectly return an e-mail body with xsi:type="xsd:long"

[Nis Martensen]

(Moving to #712979 for the REST interface thing, and adding Bastian to
recipients)

On 31.12.2021 Don Armstrong wrote in #1002595:
> [Really, it's past time for us to support a REST interface and
> abandon the SOAP interface.]
Just wondering: Don, how much effort would you estimate is this? Do you
have plans for working on this? Could this be a suitable project for a
summer of code contribution?

Since it is not mentioned in this bug yet - There was some discussion
about this on the mailing list some time ago:
https://lists.debian.org/debian-debbugs/2018/12/msg0.html
This is linked to https://github.com/venthur/debbugs-proposal

There seem to be several frameworks available in Perl to build REST
interfaces. Do you have any preference on which one should be used?

Bug#1002921: installation-reports: No Screen Reader, Cannot boot into MATE GUI, Root only can

[D.J.J. Ring, Jr.]

No on the first run after installation, I cannot log in using my user
account.

I tried installation again, still keeping /home partition data but using a
brand-new user account. This installation also failed in the exact same
way.  I had voice at the lightdm login prompt but I could not log in. I
could log in as previously by using root.

So reusing by /home/djringjr folder won't let me log in, using a brand-new
user account with brand new files from /etc/skel won't let me run the GUI.

Since then I've discovered with my current installation not only can't I
access the GUI but additionally I cannot access the CLI at least directly.
I can login as root then su to my user name and access my user CLI but
running startx still fails.

I can install the last version of the previous Debian before Bullseye
perfectly with my current /home folder.

Best wishes,

David

Regards,



On Sat, Jan 1, 2022, 14:39 Holger Wansing  wrote:

> Hi,
>
> "D.J.J. Ring, Jr."  wrote (Sat, 1 Jan 2022 13:37:20 -0500):
> > 1.  Cannot boot into MATE GUI means that I cannot boot into the MATE
> > Graphical User Interface with the user account - which is what is
> expected
> > to happen after a normal successful installation.   I did some
> > investigation  into this.
> >
> > This is what I did:  .  I disabled lightdm using systemctl disable
> lightdm
> > then more recently I used the root command "systemctl set-default
> > multi-user.target" and now I see I cannot even log in as my regular user.
>
> This is what I had expected, so in the first run it's not an issue with
> the
> MATE GUI.
>
> > I tried a new named user and did the same installation, I had the very
> same
> > problems with the new username.
> >
> > My /home/djringjr/ folder was used successfully with the last Debian
> Buster
> > release.
>
> Hmm, I wonder what that means exactly, as well as the following sentence:
>
> > [...]  When
> > installing for my normal user account, I do not format /home/myuser
> folder.
>
> Do you re-use an old/existing home folder of some user account somehow for
> the
> new user?
> I don't know if that is supposed to work.
> I only know the szenario, where a complete new home folder is created
> automatically, when a new user is added to the system (with the "useradd"
> command).
>
> > I have entered the root account and re-entered my useraccount password.
> I
> > have done this several times.  Remember this also happened when I had an
> > entirely new user account with a newly made /home/newuser folder.
>
> So you have tried, to log in as root on the console and type
> "adduser yourusername" to create a completely new user?
> And see if you can successfully login into that new account with
> "su -l yourusername" ?
>
>
> > I know the username password is correct because as root I enter "su
> > myusername" and I am in user account, then from my user account,  I type
> > "su myusername" and I receive a prompt for my password.  I have further
> > checked by entering an incorrect password and received "authentication
> > failure" response.
> >
> > root@debian:~# su djringjr
> > djringjr@debian:/root$ su djringjr
> > Password: [I enter the correct password\
> > djringjr@debian:/root$ exit
> > exit
> > djringjr@debian:/root$ su djringjr
> > Password: [I enter an incorrect password\
> > su: Authentication failure
> > djringjr@debian:/root$
> >
> > You asked me to state the problems again, here they are.
> >
> > 1. During installation I chose accessible text installation, the
> installer
> > appeared to detect my sound card, but after that I hear no sound from the
> > screen reader.
>
> That might be the issue described here:
> https://www.debian.org/releases/stable/debian-installer/#errata
>
> I do not  use a Braille device, so I cannot comment on
> > Braille.  I still have limited vision, so I was able to finish the
> > installation.
> > When I rebooted, I had screen reader, but there were additional problems.
> > I also tried the live DVD to install  and I had the exact problems.  I
> > believe I tried the 11.0 release with firmware four or five times,  and I
> > have tried the 11.2 firmware release at least four times, and the 11.2
> live
> > release twice, all gave me the exact same problems. The system was
> unusable
> > as regular user in every case except it WAS usable in the console if I
> > logged in as root, then logged in as username.
> >
> > 2. I cannot log in as my user account into console.  This also means had
> I
> > not disabled graphical user log on with lightdm, I would not  be able to
> > log on to the MATE GUI as is the subject of my error report.
> >
> > 3.  I can  log into my root account in console, and before I disabled
> > lightdm  I was able  to log in with lightdm to the MATE GUI, however,
> > running orca -s says no speech available.  See the error file I produced
> by
> > running "orca -s 2> orcaerrors" then interrupting the terminal with
> > control-c.  I also get multiple AT-SPI errors which are in the attached
> > 

Bug#1002819: autopkgtest: --pin-packages assumes that the release has a "Suite" name

[Raphael Hertzog]

Hi,

On Fri, 31 Dec 2021, Paul Gevers wrote:
> > Otherwise I would like to suggest to create two entries, one with
> > "Pin: release a=foo" and one with "Pin: release n=foo" so that
> > we are sure to match on any of the 3 fields.
> 
> I'll have to check and think about this. I remember that I had lots of
> issues with coming up with changes to autopkgtest that also worked for
> Ubuntu, as they use the same Codename for the real Suite and the *-proposed
> Suite (which they call pocket). I don't recall if that was with respect to
> pinning or other aspects of autopkgtest and it's requirement to manipulate
> where packages should be installed from. Before committing your proposal I
> need to understand that I'm not breaking existing valid configurations too.

I saw a comment mentionning this, but it was related to the "--apt-pocket"
option and I didn't change that part, which still uses the "a=foo" syntax.

https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/lib/adt_testbed.py#L1263

And indeed in http://archive.ubuntu.com/ubuntu/dists/jammy-proposed/Release you 
have
 
 Suite: jammy-proposed
 Codename: jammy

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


signature.asc
Description: PGP signature

Bug#1002963: [PATCH] local-debbugs: use FindBin

[Mike Frysinger]

Package: debbugs

This allows running of it from the git tree directly.
---
 bin/local-debbugs | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/bin/local-debbugs b/bin/local-debbugs
index 3e397f38999b..69406dd74585 100755
--- a/bin/local-debbugs
+++ b/bin/local-debbugs
@@ -122,6 +122,8 @@ use IPC::Run;
 use IO::File;
 use File::Path;
 use File::Spec;
+use FindBin;
+use lib "$FindBin::Bin/../lib";
 
 my %options = (debug   => 0,
   help=> 0,
@@ -162,8 +164,8 @@ if ($options{git_mode}) {
 $options{template_dir} = "/usr/share/debbugs/templates";
 }
 
-eval "use Debbugs::Common qw(checkpid lockpid get_hashname)";
-eval "use Debbugs::Mail qw(get_addresses)";
+use Debbugs::Common qw(checkpid lockpid get_hashname);
+use Debbugs::Mail qw(get_addresses);
 
 pod2usage() if $options{help};
 pod2usage({verbose=>2}) if $options{man};
-- 
2.33.0

Bug#1002840: ftp.debian.org: repo-source never updates new DEP-11/appstream-data in stable so screenshots fail HTTP 404 in gnome-software

[Jano John Akim Franke]

Checking all releases with the following script it seems to me that updates from appstream to ftp-master are 
done on "testing" and "unstable" only leaving out "stable" notably since the 
beginning in 2016. Is there some rationale behind this or is it a bug?
package appstream has hard reverse dependencies for GNOME and others that rely 
on it to get the *updated* AppStream-Data for them to use.

$ cat appstream-check.sh
#!/bin/bash

WGET='wget --quiet --show-progress --timestamping'
for RELEASE in sid buzz rex bo hamm slink potato woody sarge etch lenny squeeze 
wheezy jessie stretch buster bullseye bookworm trixie; do
for COMPONENT in main contrib non-free; do
${WGET} 
"https://appstream.debian.org/data/${RELEASE}/${COMPONENT}/Components-amd64.yml.gz;   
  -O "${RELEASE}-${COMPONENT}-appstream-Components-amd64.yml.gz"
${WGET} 
"https://ftp.debian.org/debian/dists/${RELEASE}/${COMPONENT}/dep11/Components-amd64.yml.gz;
 -O "${RELEASE}-${COMPONENT}-mirrorcpy-Components-amd64.yml.gz"
done
done
stat --format '%y %n X%sX' *.yml.gz | grep -v 'X0X' | cut -d' ' -f1,4 | column 
--table | sort
$ ./appstream-check.sh
[...]
2017-06-16  stretch-contrib-mirrorcpy-Components-amd64.yml.gz
2017-06-16  stretch-main-mirrorcpy-Components-amd64.yml.gz
2017-06-16  stretch-non-free-mirrorcpy-Components-amd64.yml.gz
2017-06-18  stretch-contrib-appstream-Components-amd64.yml.gz
2017-06-18  stretch-main-appstream-Components-amd64.yml.gz
2017-06-18  stretch-non-free-appstream-Components-amd64.yml.gz
2019-06-24  buster-non-free-appstream-Components-amd64.yml.gz
2019-06-24  buster-non-free-mirrorcpy-Components-amd64.yml.gz
2019-06-27  buster-contrib-appstream-Components-amd64.yml.gz
2019-06-27  buster-contrib-mirrorcpy-Components-amd64.yml.gz
2019-07-03  buster-main-appstream-Components-amd64.yml.gz
2019-07-03  buster-main-mirrorcpy-Components-amd64.yml.gz
2021-08-01  bullseye-contrib-mirrorcpy-Components-amd64.yml.gz
2021-08-08  bullseye-main-mirrorcpy-Components-amd64.yml.gz
2021-08-08  bullseye-non-free-mirrorcpy-Components-amd64.yml.gz
2021-09-11  bullseye-non-free-appstream-Components-amd64.yml.gz
2021-10-09  bullseye-contrib-appstream-Components-amd64.yml.gz
2021-12-18  bullseye-main-appstream-Components-amd64.yml.gz
2021-12-31  bookworm-contrib-appstream-Components-amd64.yml.gz
2021-12-31  bookworm-contrib-mirrorcpy-Components-amd64.yml.gz
2021-12-31  bookworm-non-free-appstream-Components-amd64.yml.gz
2021-12-31  bookworm-non-free-mirrorcpy-Components-amd64.yml.gz
2021-12-31  sid-contrib-appstream-Components-amd64.yml.gz
2021-12-31  sid-contrib-mirrorcpy-Components-amd64.yml.gz
2022-01-01  bookworm-main-appstream-Components-amd64.yml.gz
2022-01-01  bookworm-main-mirrorcpy-Components-amd64.yml.gz
2022-01-01  sid-main-appstream-Components-amd64.yml.gz
2022-01-01  sid-main-mirrorcpy-Components-amd64.yml.gz
2022-01-01  sid-non-free-appstream-Components-amd64.yml.gz
2022-01-01  sid-non-free-mirrorcpy-Components-amd64.yml.gz

Bug#918854: Disabling libgit2

[Jelmer Vernooij]

For those also affected by this and possibly unable to upgrade to the
new package (I'm on kali Linux):

You can set CARGO_NET_GIT_FETCH_WITH_CLI=true in the environment to
disable use of libgit2.

Jelmer

-- 
Jelmer Vernooij 
PGP Key: https://www.jelmer.uk/D729A457.asc

Bug#1002591: misdetects socket activated ssh

[Marc Haber]

Hi Thomas,

On Sat, Jan 01, 2022 at 02:31:04PM +0100, Thomas Liske wrote:
> could you please provide the content of /proc/$PID/cgroup for an socket
> activated sshd instance?

Sure:
1 [1/4996]mh@torres:~ $ pgrep ssh
315675
315738
[2/4997]mh@torres:~ $ sudo cat /proc/315675/cgroup
[sudo] password for mh on torres: 
0::/user.slice/user-1001.slice/session-296.scope
[3/4998]mh@torres:~ $ sudo cat /proc/315738/cgroup
0::/user.slice/user-1001.slice/session-296.scope
[4/4999]mh@torres:~ $ 

> As a workaround you might blacklist sshd in needrestart but I think a
> generic approach handling socket activation services in needrestart
> would be better. Therefore needrestart need a way to detect if the
> process belongs to a socket activated service.

It is also possible to mask ssh.service entirely in systemd. But of
couse having the heuristic fixed would be better.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1002308: lld-13: LLD is not found by a find_package cmake call.

[Maxime Chambonnet]

This should be solved by llvm main packages having been updated from 11 
to 13.

Bug#1002962: recode: Please switch to upstream as redirected by GNU

[Boyuan Yang]

Source: recode
Version: 3.6-24
Severity: normal
Tags: sid bookworm
X-Debbugs-CC: sanv...@debian.org

Hi Santiago,

Thanks for maintaining package recode in Debian as a separate fork. However
according to https://www.gnu.org/software/recode/ , a new active upstream is
now present at https://github.com/rrthomas/recode/ . Probably we should switch
to upstream and have Debian's own patches merged.

Thanks,
Boyuan Yang


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

Bug#1002961: src:castle-game-engine: fails to migrate to testing for too long: FTBFS on armel

[Paul Gevers]

Source: castle-game-engine
Version: 6.4+dfsg1-7
Severity: serious
Control: close -1 7.0~alpha.1+dfsg-4
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:castle-game-engine has been trying to 
migrate for 61 days [2]. Hence, I am filing this bug. Your package fails 
to build on armel, but is successfully built there in the past.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=castle-game-engine


OpenPGP_signature
Description: OpenPGP digital signature

Bug#997029: pysph: FTBFS in testing and unstable

[Antonio Valentino]

Hi Grisham,
Thanks for the quick reply.


> On 1 Jan 2022, at 20:10, Graham Inggs  wrote:
> 
> Hi Antonio
> 
> On Fri, 31 Dec 2021 at 14:27, Antonio Valentino
>  wrote:
>> Do you have an updated pointer to a build failure?
>> ... or can we consider to close or at least reduce the severity of this
>> issue?
> 
> builds failed again on amd64 yesterday in both testing and unstable
> 
> see https://tests.reproducible-builds.org/debian/rb-pkg/pysph.html

I have opened an issue upstream:
https://github.com/pypr/pysph/issues/326

Meanwhile I will try to work to a patch to fix the issue.

Kind regards
--
Antonio Valentino

Bug#1002960: webcamoid: ftbfs with GCC-11 on hppa

[John David Anglin]

Source: webcamoid
Version: 8.6.1+dfsg-2.1
Severity: normal

Dear Maintainer,

The build fails with following error:

g++ -c -pipe -g -O2 -ffile-prefix-map=/<>=. -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -std=gnu++11 
-Wall -Wextra -DCOMMONS_APPNAME="\"libAvKys\"" -DCOMMONS_TARGET="\"avkys\"" 
-DCOMMONS_VER_MAJ="\"8\"" -DCOMMONS_VERSION="\"8.6.1\"" -DPREFIX="\"/usr\"" 
-DEXECPREFIX="\"/usr\"" -DBINDIR="\"/usr/bin\"" -DSBINDIR="\"/usr/sbin\"" 
-DLIBEXECDIR="\"/usr/libexec\"" -DDATAROOTDIR="\"/usr/share\"" 
-DDATDIR="\"/usr/share/avkys\"" -DSYSCONFDIR="\"/usr/etc\"" 
-DSHAREDSTATEDIR="\"/usr/com\"" -DLOCALSTATEDIR="\"/usr/var\"" 
-DINCLUDEDIR="\"/usr/include\"" -DDOCDIR="\"/usr/share/doc/avkys\"" 
-DINFODIR="\"/usr/share/info\"" -DHTMLDIR="\"/usr/share/doc/avkys/html\"" 
-DDVIDIR="\"/usr/share/doc/avkys/dvi\"" -DPDFDIR="\"/usr/share/doc/avkys/pdf\"" 
-DPSDIR="\"/usr/share/doc/avkys/ps\"" -DLIBDIR="\"/usr/lib/hppa-linux-gnu\"" 
-DLOCALEDIR="\"/usr/share/webcamoid/locale\"" -DMANDIR="\"/usr/share/man\"" 
-DLICENSEDIR="\"/usr/share/licenses/avkys\"" -DLOCALDIR="\"/usr/local\"" 
-DLOCALLIBDIR="\"/usr/local/lib\"" 
-DINSTALLQMLDIR="\"/usr/lib/hppa-linux-gnu/qt5/qml\"" 
-DINSTALLPLUGINSDIR="\"/usr/lib/hppa-linux-gnu/avkys\"" 
-DQT_DEPRECATED_WARNINGS -DQT_NAMESPACE=AkVCam -I. 
-I/usr/lib/hppa-linux-gnu/qt5/mkspecs/linux-g++ -o 
release/Qt5.15.2/gpp/hppa/obj/videoformat.o src/image/videoformat.cpp
src/image/videoformat.cpp: In member function ‘AkVCam::VideoFormat 
AkVCam::VideoFormat::nearest(const std::vector&) const’:
src/image/videoformat.cpp:289:19: error: ‘numeric_limits’ is not a member of 
‘std’
  289 | auto q = std::numeric_limits::max();
  |   ^~
src/image/videoformat.cpp:289:42: error: expected primary-expression before ‘>’ 
token
  289 | auto q = std::numeric_limits::max();
  |  ^
src/image/videoformat.cpp:289:45: error: ‘::max’ has not been declared; did you 
mean ‘std::max’?
  289 | auto q = std::numeric_limits::max();
  | ^~~
  | std::max
In file included from /usr/include/c++/11/algorithm:62,
 from src/image/videoformat.cpp:21:
/usr/include/c++/11/bits/stl_algo.h:3467:5: note: ‘std::max’ declared here
 3467 | max(initializer_list<_Tp> __l, _Compare __comp)
  | ^~~

I believe this is likely caused by the following header dependency
changes in gcc-11:

Some C++ Standard Library headers have been changed to no longer include other 
headers that they do need to depend on. As such, C++ programs that used 
standard library components without including the right headers will no longer 
compile.

The following headers are used less widely in libstdc++ and may need to be 
included explicitly when compiled with GCC 11:

 (for std::numeric_limits)
 (for std::unique_ptr, std::shared_ptr etc.)
 (for std::pair, std::tuple_size, std::index_sequence etc.)
 (for members of namespace std::this_thread.)

See for more details:
https://www.gnu.org/software/gcc/gcc-11/porting_to.html

Regards,
Dave Anglin

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

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

Bug#997029: pysph: FTBFS in testing and unstable

[Graham Inggs]

Hi Antonio

On Fri, 31 Dec 2021 at 14:27, Antonio Valentino
 wrote:
> Do you have an updated pointer to a build failure?
> ... or can we consider to close or at least reduce the severity of this
> issue?

builds failed again on amd64 yesterday in both testing and unstable

see https://tests.reproducible-builds.org/debian/rb-pkg/pysph.html

Regards
Graham

Bug#1002033: ITP: lpairs2 -- Classic memory game with nice graphics

[Antoni Aloy Torrens]

Hello all,
I'll try packaging lpairs2. It may take some time, as I have recently 
become a Debian Contributor and this may be my first package attempt. If 
someone also wants to have this game package, please reply to this bug. 
Any help or contributions are appreciated!


--



INFORMACIÓ SOBRE PROTECCIÓ DE DADES DE LA UNIVERSITAT OBERTA DE 
CATALUNYA (UOC)


Us informem que les vostres dades identificatives i les 
contingudes en els missatges electrònics i fitxers adjunts es poden 
incorporar a les nostres bases de dades amb la finalitat de gestionar les 
relacions i comunicacions vinculades a la UOC, i que es poden conservar 
mentre es mantingui la relació. Si ho voleu, podeu exercir el dret a 
accedir a les vostres dades, rectificar-les i suprimir-les i altres drets 
reconeguts normativament adreçant-vos a l'adreça de correu emissora o a 
fuoc...@uoc.edu .


Aquest missatge i qualsevol 
fitxer que porti adjunt, si escau, tenen el caràcter de confidencials i 
s'adrecen únicament a la persona o entitat a qui s'han enviat.


Així 
mateix, posem a la vostra disposició un delegat de protecció de dades que 
no només s'encarregarà de supervisar tots els tractaments de dades de la 
nostra entitat, sinó que us podrà atendre per a qualsevol qüestió 
relacionada amb el tractament de dades. La seva adreça de contacte és 
d...@uoc.edu .
INFORMACIÓN SOBRE PROTECCIÓN DE DATOS DE 
LA UNIVERSITAT OBERTA DE CATALUNYA (UOC)
Os informamos de que vuestros 
datos identificativos y los contenidos en los mensajes electrónicos y 
ficheros adjuntos pueden incorporarse a nuestras bases de datos con el fin 
de gestionar las relaciones y comunicaciones vinculadas a la UOC, y de que 
pueden conservarse mientras se mantenga la relación. Si lo deseáis, podéis 
ejercer el derecho a acceder a vuestros datos, rectificarlos y suprimirlos 
y otros derechos reconocidos normativamente dirigiéndoos a la dirección de 
correo emisora o a fuoc...@uoc.edu .
Este mensaje y 
cualquier fichero que lleve adjunto, si procede, tienen el carácter de 
confidenciales y se dirigen únicamente a la persona o entidad a quien se 
han enviado.
Así mismo, ponemos a vuestra disposición a un delegado de 
protección de datos que no solo se encargará de supervisar todos los 
tratamientos de datos de nuestra entidad, sino que podrá atenderos para 
cualquier cuestión relacionada con el tratamiento de datos. Su dirección de 
contacto es d...@uoc.edu .



UNIVERSITAT OBERTA DE 
CATALUNYA (UOC) DATA PROTECTION INFORMATION
Your personal data and the data 
contained in your email messages and attached files may be stored in our 
databases for the purpose of maintaining relations and communications 
linked to the UOC, and the data may be stored for as long as these 
relations and communications are maintained. If you so wish, you can 
exercise your rights to access, rectification and erasure of your data, and 
any other legally held rights, by writing to the sender’s email address or 
to fuoc...@uoc.edu .
This message and, where 
applicable, any attachments are confidential and addressed solely to the 
individual or organization they were sent to.
The UOC has a data protection 
officer who not only supervises the data processing carried out at the 
University, but who will also respond to any questions you may have about 
this data processing. You can contact our data protection officer by 
writing to d...@uoc.edu .

Bug#1002958: python3-flask-migrate missing: No module named 'flask_migrate'

[Akkana Peck]

Package: python3-flask-migrate
Version: python3-flask-sqlalchemy
Severity: normal
X-Debbugs-Cc: d...@shallowsky.com

Dear Maintainer,

The package python3-flask-migrate is missing in bookworm even though
it's there in sid and in packages before bookworm:
https://packages.debian.org/search?keywords=python3-flask-migrate=names=all=all

This is a problem for anyone trying to use python3-flask-sqlalchemy
since most flask-sqlalchemy apps use migration (at least, all the
examples I've seen do, so I've followed that in my own apps).

Can python3-flask-migrate please be added back to bookworm? I know
it's possible to get it through pip install, but I prefer using Debian
packages when possible since they get security updates.

One easy way to see the problem is to use lesson 4 (or any later
lesson) of the Flask Mega Tutorial:

git clone https://github.com/miguelgrinberg/microblog.git
cd microblog/
git checkout tags/v0.4
export FLASK_APP=microblog.py
flask run

which produces output:

Error: While importing 'microblog', an ImportError was raised:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/flask/cli.py", line 256, in locate_app
__import__(module_name)
  File "/home/akkana/outsrc/microblog/microblog.py", line 1, in 
from app import app, db
  File "/home/akkana/outsrc/microblog/app/__init__.py", line 3, in 
from flask_migrate import Migrate
ModuleNotFoundError: No module named 'flask_migrate'


Thanks for considering this!


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

Kernel: Linux 5.15.0-2-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)

Bug#1002595: debbugs: get_bug_log can incorrectly return an e-mail body with xsi:type="xsd:long"

[Mike Frysinger]

On Fri, 31 Dec 2021 14:21:05 -0800, Don Armstrong wrote:
> On Fri, 31 Dec 2021, Mike Frysinger wrote:
> > i get that the server is misbehaving now so clients don't have much
> > choice but to workaround them, but the server response should be fixed
> > nevertheless.
>
> Happy to accept patches to fix the XML serialization in SOAP. The way
> that Debbugs is doing it is clearly not correct, but fixing it isn't
> high on my priority list. [Really, it's past time for us to support a
> REST interface and abandon the SOAP interface.]

i've dug around the source a bit.  tbh, the exclusive use of perl makes it
a pretty big barrier for contribution, and so it's unlikely i'll be able to
offer anything substantial.  i was barely able to get it running using the
incomplete/buggy README instructions.

i'm not asking/suggesting it be rewritten in a diff language of course as i
grok the long history and such.  just explaining why it's unlikely i'll be
sending any useful code patches.

Bug#1002921: installation-reports: No Screen Reader, Cannot boot into MATE GUI, Root only can

[D.J.J. Ring, Jr.]

Hello Holger Wansing,

Thanks for helping me with these problems.

Here are my answers to my best ability to answer them.

1.  Cannot boot into MATE GUI means that I cannot boot into the MATE
Graphical User Interface with the user account - which is what is expected
to happen after a normal successful installation.   I did some
investigation  into this.

This is what I did:  .  I disabled lightdm using systemctl disable lightdm
then more recently I used the root command "systemctl set-default
multi-user.target" and now I see I cannot even log in as my regular user.

I tried a new named user and did the same installation, I had the very same
problems with the new username.

My /home/djringjr/ folder was used successfully with the last Debian Buster
release.

If I reinstall the last Debian 10 firmware which I had been using prior to
Bullseys 11.0 release which also failed in the exact same way, everything
is excellent, my sound card is detected during accessible installation,
when I boot i go to the lightdm screen and I can  log in as my regular
user.  I also have sound as my regular user in GUI and also I have ORCA in
the GUI.

I have entered the root account and re-entered my useraccount password.  I
have done this several times.  Remember this also happened when I had an
entirely new user account with a newly made /home/newuser folder.  When
installing for my normal user account, I do not format /home/myuser folder.

I know the username password is correct because as root I enter "su
myusername" and I am in user account, then from my user account,  I type
"su myusername" and I receive a prompt for my password.  I have further
checked by entering an incorrect password and received "authentication
failure" response.

root@debian:~# su djringjr
djringjr@debian:/root$ su djringjr
Password: [I enter the correct password\
djringjr@debian:/root$ exit
exit
djringjr@debian:/root$ su djringjr
Password: [I enter an incorrect password\
su: Authentication failure
djringjr@debian:/root$

You asked me to state the problems again, here they are.

1. During installation I chose accessible text installation, the installer
appeared to detect my sound card, but after that I hear no sound from the
screen reader.  I do not  use a Braille device, so I cannot comment on
Braille.  I still have limited vision, so I was able to finish the
installation.
When I rebooted, I had screen reader, but there were additional problems.
I also tried the live DVD to install  and I had the exact problems.  I
believe I tried the 11.0 release with firmware four or five times,  and I
have tried the 11.2 firmware release at least four times, and the 11.2 live
release twice, all gave me the exact same problems. The system was unusable
as regular user in every case except it WAS usable in the console if I
logged in as root, then logged in as username.

2. I cannot log in as my user account into console.  This also means had I
not disabled graphical user log on with lightdm, I would not  be able to
log on to the MATE GUI as is the subject of my error report.

3.  I can  log into my root account in console, and before I disabled
lightdm  I was able  to log in with lightdm to the MATE GUI, however,
running orca -s says no speech available.  See the error file I produced by
running "orca -s 2> orcaerrors" then interrupting the terminal with
control-c.  I also get multiple AT-SPI errors which are in the attached
orcaerrors file.

.
Best regards,

David



On Sat, Jan 1, 2022 at 11:56 AM Holger Wansing  wrote:

> Hi,
>
> "D.J.J. Ring, Jr."  wrote (Sat, 1 Jan 2022 09:39:26 -0500):
> > Thanks,
> >
> > Here they are.
> >
> > Regards,
> > David
> >
> > On Sat, Jan 1, 2022 at 8:59 AM Holger Wansing 
> wrote:
> > > You should provide the installer log files (to be found in
> > > /var/log/installer).
> > > Sent them compressed to this bugreport.
>
> From your logs it seems your installation was a success, I cannot see any
> grave issues.
>
>
> So, we need to go back to the beginning:
> What are your problems, exaclty?
> What do you do, and what happens? Which error message exactly, and so on...
>
>
> The subject of this bug has "Cannot boot into MATE GUI".
> What does this mean? Could it be, that just the password is not correct?
> (Maybe you now have a different keyboard layout active than during
> installation, or similar?)
>
>
>
> Holger
>
>
> --
> Holger Wansing 
> PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
>


orcaerrors
Description: Binary data

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

On Thu, 23 Dec 2021 01:49:53 -0500
Andres Salomon  wrote:

> On 12/13/21 5:31 PM, Moritz Muehlenhoff wrote:
> > On Sun, Dec 12, 2021 at 08:11:00PM -0500, Andres Salomon wrote:  
> >> On 12/5/21 6:41 AM, Moritz Mühlenhoff wrote:  
> >>> Am Sun, Dec 05, 2021 at 10:53:56AM +0100 schrieb Paul Gevers:
> >>> Exactly that.
> >>>
> >>> I'd suggest anyone who's interested in seeing Chromium supported
> >>> to first update it in unstable (and then work towards updated in
> >>> bullseye-security).  
> >> I started doing just that:
> >> https://salsa.debian.org/dilinger/chromium (v96 and misc-fixes
> >> branches).  
> > As a side note: If any of the system/* patches cause issues, feel
> > free to switch to the vendored copies. Vendoring in general is
> > frowned upon since it requires that a fix in a libraries spreads
> > out to all vendored copies, but for Chromium there's a steady
> > stream of Chromium-internal security issues anyway, so for all
> > practical purposes it doesn't make a difference if the Chromium
> > security releases also include a fix for a vendored lib like ICU.
> >
> > Cheers,
> >  Moritz  
> 
> 
> I've got 96.0.4664.110 building on both bullseye and sid, and am
> currently
> 
> debugging some crashes. The only thing I had to vendor was some nodejs
> 
> libraries, although it's very tempting to take a chainsaw through the 
> various
> 
> patches and re-vendor a bunch of other libraries as Jeff suggested.
> Still on
> 
> the v96 branch of https://salsa.debian.org/dilinger/chromium
> 


Alright, crashes are solved and the packages are now usable. After some
cleanups (listing CVEs in changelogs, merging/pushing a bunch of
commits in my branch, possibly dropping strong stack protection from
builds to silence warnings from older clang versions, and going through
lintian errors/warnings), it should be ready to upload.

How should I handle this? NMU to sid, let people try it out, and then
deal with buster/bullseye? Upload everything all at once? I'm also
going to try building for buster, unless the security team doesn't
think I should bother. That may involve vendoring some additional
libraries, so we don't have to carry a bunch of additional patches.

I also haven't heard from anyone on the chromium team yet - should I
add myself as an uploader and do a normal (non-NMU) upload? Do any of
them care?

Thanks,
Andres

Bug#1002675: re hubic/pyrax problem

[Fabrice Lamareille]

Hello,

Firstly, the type error can be solved by doing this:

change in hubic.py in class HubicIdentity

def __init__(self)
by
def __init__(self, **kwargs)

However, the connection still fails with the following error:

Connection failed, please check your credentials: TypeError a bytes-like 
object is required, not 'str'


The full v9 log is not unfortunattly quite helpful ! Here is the output:

$ duplicity -v9  status cf+hubic://owncloud
Using archive dir: 
/data1/hubic/.cache/duplicity/ddc194b0289be77f5dd06ec911d17a78

Using backup name: ddc194b0289be77f5dd06ec911d17a78
GPG binary is gpg, version (2, 2, 27)
Import of duplicity.backends.adbackend Succeeded
Import of duplicity.backends.azurebackend Succeeded
Import of duplicity.backends.b2backend Succeeded
Import of duplicity.backends.boxbackend Succeeded
Import of duplicity.backends.cfbackend Succeeded
Import of duplicity.backends.dpbxbackend Succeeded
Import of duplicity.backends.gdocsbackend Succeeded
Import of duplicity.backends.gdrivebackend Succeeded
Import of duplicity.backends.giobackend Succeeded
Import of duplicity.backends.hsibackend Succeeded
Import of duplicity.backends.hubicbackend Succeeded
Import of duplicity.backends.idrivedbackend Succeeded
Import of duplicity.backends.imapbackend Succeeded
Import of duplicity.backends.jottacloudbackend Succeeded
Import of duplicity.backends.lftpbackend Succeeded
Import of duplicity.backends.localbackend Succeeded
Import of duplicity.backends.mediafirebackend Succeeded
Import of duplicity.backends.megabackend Succeeded
Import of duplicity.backends.megav2backend Succeeded
Import of duplicity.backends.megav3backend Succeeded
Import of duplicity.backends.multibackend Succeeded
Import of duplicity.backends.ncftpbackend Succeeded
Import of duplicity.backends.onedrivebackend Succeeded
Import of duplicity.backends.par2backend Succeeded
Import of duplicity.backends.pcabackend Succeeded
Import of duplicity.backends.pydrivebackend Succeeded
Import of duplicity.backends.rclonebackend Succeeded
Import of duplicity.backends.rsyncbackend Succeeded
Import of duplicity.backends.s3_boto3_backend Succeeded
Import of duplicity.backends.s3_boto_backend Succeeded
Import of duplicity.backends.ssh_paramiko_backend Succeeded
Import of duplicity.backends.ssh_pexpect_backend Succeeded
Import of duplicity.backends.swiftbackend Succeeded
Import of duplicity.backends.sxbackend Succeeded
Import of duplicity.backends.tahoebackend Succeeded
Import of duplicity.backends.webdavbackend Succeeded
Connection failed, please check your credentials: TypeError a bytes-like 
object is required, not 'str'

Using temporary directory /tmp/duplicity-xwljyau7-tempdir

Do you know how to get a more useful debug output (i.e. with the 
detailed python error and line numbers) ?


Thanks.

Bug#1002956: bullseye-pu: package rabbitmq-server/3.8.9-3 CVE-2021-32718, CVE-2021-32719

[Thomas Goirand]

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

[ Reason ]
Hi,

I'd like to update rabbitmq-server to address:
https://bugs.debian.org/990524

That's CVE-2021-32718, CVE-2021-32719.

[ Impact ]
XSS security bugs.

[ Risks ]
The patch only impacts some plugins which aren't activated
by default, so most user aren't even impacted. However, the
patches are also super-small, so why not approved them?

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

Cheers,

Thomas Goirand (zigo)
diff -Nru rabbitmq-server-3.8.9/debian/changelog 
rabbitmq-server-3.8.9/debian/changelog
--- rabbitmq-server-3.8.9/debian/changelog  2021-04-10 22:59:57.0 
+0200
+++ rabbitmq-server-3.8.9/debian/changelog  2022-01-01 18:46:04.0 
+0100
@@ -1,3 +1,23 @@
+rabbitmq-server (3.8.9-3+deb11u1) bullseye; urgency=medium
+
+  * CVE-2021-32719: In rabbitmq-server prior to version 3.8.18, when a
+federation link was displayed in the RabbitMQ management UI via the
+`rabbitmq_federation_management` plugin, its consumer tag was rendered
+without proper script tag sanitization. This potentially allows
+for JavaScript code execution in the context of the page. The user must
+be signed in and have elevated permissions (manage federation upstreams
+and policies) for this to occur. Applied upstream patch: Escape the
+consumer-tag value in federation mgmt.
+  * CVE-2021-32718: In rabbitmq-server prior to version 3.8.17, a new user
+being added via management UI could lead to the user's bane being
+rendered in a confirmation message without proper `script` tag
+sanitization, potentially allowing for JavaScript code execution in the
+context of the page. In order for this to occur, the user must be signed
+in and have elevated permissions (other user management).
+  * Closes: #990524
+
+ -- Thomas Goirand   Sat, 01 Jan 2022 18:46:04 +0100
+
 rabbitmq-server (3.8.9-3) unstable; urgency=medium
 
   [ Adam Cecile ]
diff -Nru 
rabbitmq-server-3.8.9/debian/patches/CVE-2021-32718_Escape_username_before_displaying_it.patch
 
rabbitmq-server-3.8.9/debian/patches/CVE-2021-32718_Escape_username_before_displaying_it.patch
--- 
rabbitmq-server-3.8.9/debian/patches/CVE-2021-32718_Escape_username_before_displaying_it.patch
  1970-01-01 01:00:00.0 +0100
+++ 
rabbitmq-server-3.8.9/debian/patches/CVE-2021-32718_Escape_username_before_displaying_it.patch
  2022-01-01 18:46:04.0 +0100
@@ -0,0 +1,21 @@
+Description: CVE-2021-32718: Escape username before displaying it
+ All other values displayed in pop-ups are already escaped.
+Author: Michael Klishin 
+Date: Thu, 6 May 2021 06:57:43 +0300
+Origin: upstream, 
https://github.com/rabbitmq/rabbitmq-server/commit/5d15ffc5ebfd9818fae488fc05d1f120ab02703c.patch
+Bug-Debian: https://bugs.debian.org/990524
+Last-Update: 2022-01-01
+
+diff --git a/deps/rabbitmq_management/priv/www/js/dispatcher.js 
b/deps/rabbitmq_management/priv/www/js/dispatcher.js
+index d2842c2da8a..5f1b54dbac8 100644
+--- a/deps/rabbitmq_management/priv/www/js/dispatcher.js
 b/deps/rabbitmq_management/priv/www/js/dispatcher.js
+@@ -189,7 +189,7 @@ dispatcher_add(function(sammy) {
+ res = sync_put(this, '/users/:username');
+ if (res) {
+ if (res.http_status === 204) {
+-username = res.req_params.username;
++username = fmt_escape_html(res.req_params.username);
+ show_popup('warn', "Updated an existing user: '" + 
username + "'");
+ }
+ update();
diff -Nru 
rabbitmq-server-3.8.9/debian/patches/CVE-2021-32719_Escape_the_consumer-tag_value_in_federation_mgmt.patch
 
rabbitmq-server-3.8.9/debian/patches/CVE-2021-32719_Escape_the_consumer-tag_value_in_federation_mgmt.patch
--- 
rabbitmq-server-3.8.9/debian/patches/CVE-2021-32719_Escape_the_consumer-tag_value_in_federation_mgmt.patch
  1970-01-01 01:00:00.0 +0100
+++ 
rabbitmq-server-3.8.9/debian/patches/CVE-2021-32719_Escape_the_consumer-tag_value_in_federation_mgmt.patch
  2022-01-01 18:46:04.0 +0100
@@ -0,0 +1,21 @@
+Description: CVE-2021-32719 Escape the consumer-tag value in federation mgmt
+ Patches persistent XSS.
+Author: Patrik Ragnarsson 
+Date: Sat, 19 Jun 2021 09:23:12 +0200
+Origin: upstream, https://github.com/rabbitmq/rabbitmq-server/pull/3122
+Bug-Debian: https://bugs.debian.org/990524
+Last-Update: 2021-01-01
+
+diff --git 
a/deps/rabbitmq_federation_management/priv/www/js/tmpl/federation-upstreams.ejs 
b/deps/rabbitmq_federation_management/priv/www/js/tmpl/federation-upstreams.ejs
+index 5b3e14d0638..838eac1eb3b 100644
+--- 
a/deps/rabbitmq_federation_management/priv/www/js/tmpl/federation-upstreams.ejs
 

Bug#1002955: libident: New version 0.32 available

[Boyuan Yang]

Source: libident
Severity: important
Version: 0.22-4
Tags: sid bookworm

The new upstream release is at https://www.remlab.net/files/libident/ .

Thanks,
Boyuan Yang


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

Bug#965641: libhtml-element-extended-perl: diff for NMU version 1.18-1.2

[gregor herrmann]

Control: tags 965641 + patch
Control: tags 965641 + pending
Control: tags 999154 + patch
Control: tags 999154 + pending


Hi Don,

I've prepared an NMU for libhtml-element-extended-perl (versioned as 1.18-1.2) 
and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   
diff -u libhtml-element-extended-perl-1.18/debian/changelog libhtml-element-extended-perl-1.18/debian/changelog
--- libhtml-element-extended-perl-1.18/debian/changelog
+++ libhtml-element-extended-perl-1.18/debian/changelog
@@ -1,3 +1,14 @@
+libhtml-element-extended-perl (1.18-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Modernize packaging:
++ use dh(1) in debian/rules
+  (Closes: #999154)
++ use debhelper-compat (= 13) in debian/control
+  (Closes: #965641)
+
+ -- gregor herrmann   Sat, 01 Jan 2022 18:44:32 +0100
+
 libhtml-element-extended-perl (1.18-1.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
reverted:
--- libhtml-element-extended-perl-1.18/debian/compat
+++ libhtml-element-extended-perl-1.18.orig/debian/compat
@@ -1 +0,0 @@
-5
diff -u libhtml-element-extended-perl-1.18/debian/control libhtml-element-extended-perl-1.18/debian/control
--- libhtml-element-extended-perl-1.18/debian/control
+++ libhtml-element-extended-perl-1.18/debian/control
@@ -2,7 +2,7 @@
 Section: perl
 Priority: extra
 Standards-Version: 3.9.1
-Build-Depends: debhelper (>=5)
+Build-Depends: debhelper-compat (= 13)
 Build-Depends-Indep: libhtml-tree-perl (>=3.01), libhtml-tableextract-perl (>= 2.08), perl(>= 5.6.0-16)
 Maintainer: Don Armstrong 
 
diff -u libhtml-element-extended-perl-1.18/debian/rules libhtml-element-extended-perl-1.18/debian/rules
--- libhtml-element-extended-perl-1.18/debian/rules
+++ libhtml-element-extended-perl-1.18/debian/rules
@@ -1,64 +1,4 @@
 #!/usr/bin/make -f
-# This file is public domain software, originally written by Joey Hess. 
 
-# Uncomment this to turn on verbose mode.
-#export DH_VERBOSE=1
-
-
-PACKAGE="libhtml-element-extended-perl"
-
-build: build-stamp
-build-stamp:
-	dh_testdir
-
-	perl Makefile.PL INSTALLDIRS=vendor
-	$(MAKE) OPTIMIZE="-02 -g -Wall"
-
-	touch build-stamp
-
-test: test-stamp
-test-stamp:
-	$(MAKE) test
-	touch $@
-
-clean:
-	dh_testdir
-	dh_testroot
-	rm -f build-stamp test-stamp
-
-	if [ -e Makefile ]; then $(MAKE) distclean; fi 
-
-	dh_clean
-
-install: build test
-	dh_testdir
-	dh_testroot
-	dh_clean -k
-	dh_installdirs
-
-	$(MAKE) install DESTDIR=$(CURDIR)/debian/$(PACKAGE)
-	[ ! -d $(CURDIR)/debian/$(PACKAGE)/usr/lib/perl5 ] || \
-		rmdir -p --ignore-fail-on-non-empty $(CURDIR)/debian/$(PACKAGE)/usr/lib/perl5;
-
-
-binary-indep: build install
-# We have nothing to do by default.
-	dh_testdir
-	dh_testroot
-	dh_installchangelogs
-	dh_installdocs
-	dh_installman
-	dh_compress
-	dh_fixperms
-	dh_installdeb
-	dh_perl
-	dh_shlibdeps
-	dh_gencontrol
-	dh_md5sums
-	dh_builddeb
-
-# Build architecture-dependent files here.
-binary-arch: build install
-
-binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install
+%:
+	dh $@


signature.asc
Description: Digital Signature

Bug#1002954: astunparse is not available

[Drew Parsons]

Source: astunparse
Version: 1.6.3-1~exp2
Severity: normal

python3-astunparse was uploaded to experimental, but never released to
unstable.

Should the astunparse package be removed, or should it be uploaded to
unstable?

mdtraj would use it if it was available.

Bug#965696: libwhisker2-perl: diff for NMU version 2.5-1.2

[gregor herrmann]

Control: tags 965696 + patch
Control: tags 965696 + pending
Control: tags 999044 + patch
Control: tags 999044 + pending


Dear maintainer,

I've prepared an NMU for libwhisker2-perl (versioned as 2.5-1.2) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   
diff -Nru libwhisker2-perl-2.5/debian/changelog libwhisker2-perl-2.5/debian/changelog
--- libwhisker2-perl-2.5/debian/changelog	2021-01-02 16:29:32.0 +0100
+++ libwhisker2-perl-2.5/debian/changelog	2022-01-01 18:31:42.0 +0100
@@ -1,3 +1,15 @@
+libwhisker2-perl (2.5-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "Removal of obsolete debhelper compat 5 and 6 in bookworm":
+Bump to 7 in debian/{compat,control}.
+(Closes: #965696)
+  * Fix "missing required debian/rules targets build-arch and/or build-
+indep": Add missing targets.
+(Closes: #999044)
+
+ -- gregor herrmann   Sat, 01 Jan 2022 18:31:42 +0100
+
 libwhisker2-perl (2.5-1.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru libwhisker2-perl-2.5/debian/compat libwhisker2-perl-2.5/debian/compat
--- libwhisker2-perl-2.5/debian/compat	2010-02-08 22:57:22.0 +0100
+++ libwhisker2-perl-2.5/debian/compat	2022-01-01 18:30:14.0 +0100
@@ -1 +1 @@
-5
+7
diff -Nru libwhisker2-perl-2.5/debian/control libwhisker2-perl-2.5/debian/control
--- libwhisker2-perl-2.5/debian/control	2010-02-08 22:57:22.0 +0100
+++ libwhisker2-perl-2.5/debian/control	2022-01-01 18:30:22.0 +0100
@@ -2,7 +2,7 @@
 Section: perl
 Priority: optional
 Maintainer: Vincent Bernat 
-Build-Depends: perl, debhelper (>= 5.0.0)
+Build-Depends: perl, debhelper (>= 7.0.0)
 Standards-Version: 3.8.4
 Homepage: http://www.wiretrip.net/rfp/lw.asp
 Vcs-Browser: http://git.debian.org/?p=collab-maint/libwhisker2-perl.git
diff -Nru libwhisker2-perl-2.5/debian/rules libwhisker2-perl-2.5/debian/rules
--- libwhisker2-perl-2.5/debian/rules	2010-02-08 22:57:22.0 +0100
+++ libwhisker2-perl-2.5/debian/rules	2022-01-01 18:31:38.0 +0100
@@ -5,7 +5,9 @@
 #export DH_VERBOSE=1
 
 
-build: build-stamp
+build: build-arch build-indep
+build-arch: build-stamp
+build-indep: build-stamp
 
 build-stamp:
 	dh_testdir
@@ -51,4 +53,4 @@
 	dh_builddeb
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install
+.PHONY: build-indep build-arch build clean binary-indep binary-arch binary install


signature.asc
Description: Digital Signature

Bug#1002953: RM: python-traceback2 -- ROM; Not needed anymore

[Thomas Goirand]

Package: ftp.debian.org
Severity: normal


Hi,

Traceback2 is a backport from Python 3.5 of the standard traceback library for
Python2. Unittest2 used to need traceback2, but I patched it so it can now
use the standard Python 3 traceback module. Unittest2 with this patch has now
reached testing, so we don't need traceback2 anymore.

Please remove python-traceback2 from Debian unstable and testing.

Note that at some point, unittest2 will have to be removed, though it has
many reverse dependencies to be addressed first.

Cheers,

Thomas Goirand (zigo)

Bug#960222: RM bug filed

[Thomas Goirand]

I just asked for traceback2 removal.

Bug#1002952: build-rdeps: Inconsistent defaults on Ubuntu (or other non-Debian systems)

[Matthijs Kooijman]

Package: devscripts
Version: 2.21.7
Severity: normal

Hi,

I was trying to use build-rdeps on Ubuntu today, and the default settings seem
unusable there. I tried both the Ubuntu version from impish and the Sid
version, both with the same result:

  $ sudo build-rdeps -d dh-cmake
  DEBUG: Package => dh-cmake
  DEBUG: running with dose-ceve resolver
  DEBUG: buildarch=amd64 hostarch=amd64
  DEBUG: Running 'apt-get' 'indextargets' 'DefaultEnabled: yes' 'Origin:
  Debian'
  build-rdeps: unable to find sources files.
  Did you forget to run apt-get update (or add --update to this command)?
  at /usr/bin/build-rdeps line 520.

Looking at the source code, I see that there does seem to be some code
in place to handle non-Debian vendors as well, but I think this does not
work well currently.

By default, the script only looks at sources that have 'Origin: Debian',
regardless of what the current system is:

  
https://salsa.debian.org/debian/devscripts/-/blob/master/scripts/build-rdeps.pl#L157
  my $opt_origin = 'Debian';

However, it then further limits sources to "development" releases only:

  
https://salsa.debian.org/debian/devscripts/-/blob/master/scripts/build-rdeps.pl#L227
  sub is_devel_release {
  my $ctrl = shift;
  if (get_current_vendor() eq 'Debian') {
  return $ctrl->{Suite} eq 'unstable' || $ctrl->{Codename} eq 'sid';
  } else {
  return $ctrl->{Suite} eq 'devel';
  }
  }

In this case, it *does* use the current vendor to determine the default
release to check for, meaning running build-rdeps without additional
options on non-Debian systems will never work (not even if you have
Debian deb-src lines in your sources.list as I have).

It seems like adding an explicit --origin Ubuntu would help here,
except:
 - Using a "devel" release of Ubuntu is apparently not a common practice
   (anymore):
   https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1728616/comments/2
 - If you *do* use e.g. `deb-src http://archive.ubuntu.com/ubuntu/ devel main`,
   this produces "Release: devel", not "Suite: devel", so the current
   code still does not match.

More generally, I wonder if build-rdeps should really limit itself to a
devel release only. This poses an additional requirement on your
sources.list (you need to have deb-src for sid or devel), which is not
documented in the manpage and not hinted at by the error message.

I can imagine it would *favor* unstable/devel if available (or maybe
testing if unstable is not found) , but fall back to the most recent
release (based on the Version field), or failing that, *any* available
src release instead?


As for the conflicting defaults, I can imagine:
 - Adding a --vendor option, defaulting to Dpkg::Vendor::get_current_vendor()
 - Pick the Origin based on the vendor (and maybe apply no origin limit
   for unknown vendors)
 - Pick the default distribution based on the vendor, like now (but
   checking against Release: devel instead of Suite:devel

Alternatively, if the "priority"-based scheme suggested above is
implemented, maybe there is no need at all to switch the distribution
based on the vendor at all. If you just apply a priority to each release
(sid/unstable/devel get max priority, testing nearly max priority,
others based on Version) this works regardless of the current vendor,
and you can switch between vendors based on the Origin (which should
probably still switch its default based on the vendor).


Note that there is also the matter of the list of components being
hardcoded currently, but that is already the subject of #913551.

As for making the current version work, what I can now do is:
 - Add a Ubuntu "devel" release to sources.list, patch build-rdeps to
   check Release: devel instead of Suite: devel, and run with `--origin
   Ubuntu".
 - Run with "--origin Ubuntu --distribution impish" (or whatever distro
   you're using).
 - Add "sid" sources to sources.list, and run with `--distribution sid`.

Gr.

Matthijs

-- Package-specific info:

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

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

-- System Information:
Debian Release: 11.0
  APT prefers jammy
  APT policy: (500, 'jammy'), (500, 'impish-updates'), (500, 
'impish-security'), (500, 'impish'), (100, 'impish-backports'), (50, 
'unstable-debug'), (50, 'testing-debug'), (50, 'stable-security'), (50, 
'stable-debug'), (50, 'unstable'), (50, 'testing'), (50, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.13.0-22-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
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 devscripts depends on:
ii  dpkg-dev  1.20.9ubuntu2
ii  fakeroot  1.25.3-1.1ubuntu2
ii  file  1:5.39-3
ii  gnupg 2.2.20-1ubuntu4
ii  gnupg22.2.20-1ubuntu4
ii  gpgv 

Bug#1002951: Updating the node-on-finished Uploaders list

[Tobias Frost]

Source: node-on-finished
Version: 2.3.0-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Leo Iannacone  has not been working on
the node-on-finished package for quite some time.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#1002950: Updating the node-cookiejar Uploaders list

[Tobias Frost]

Source: node-cookiejar
Version: 2.1.2-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Leo Iannacone  has not been working on
the node-cookiejar package for quite some time.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#1002949: Updating the node-promise Uploaders list

[Tobias Frost]

Source: node-promise
Version: 8.1.0-2
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Leo Iannacone  has not been working on
the node-promise package for quite some time.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#1002948: Updating the should.js Uploaders list

[Tobias Frost]

Source: should.js
Version: 13.2.3~dfsg-5
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Leo Iannacone  has not been working on
the should.js package for quite some time.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#1002947: Updating the node-dryice Uploaders list

[Tobias Frost]

Source: node-dryice
Version: 0.4.11-2
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Leo Iannacone  has not been working on
the node-dryice package for quite some time.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#1002946: Updating the node-transformers Uploaders list

[Tobias Frost]

Source: node-transformers
Version: 3.1.0-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Leo Iannacone  has not been working on
the node-transformers package for quite some time.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#1001815: transition: notcurses

[Nick Black (Public gmail account)]

> No, only in unstable [1]. Testing should still work.

hrmm, i'm a bit confused about how this works then. i can only
upload into unstable, and it then needs to pass autopkgtests to
get into testing. oh, i guess those autopkgtests are being run
in the "testing" context? if so, that makes sense.

anyway, uploading 1.2.38-3 to unstable now in the hope of
getting some useful debugging information.


signature.asc
Description: PGP signature

Bug#1002945: RM: usbmount -- RoQA; unmaintained, dead upstream, RC-buggy

[Tobias Frost]

Package: ftp.debian.org
Severity: normal

Dear ftp masters,

I guess its time to retire usbmount: It is RC buggy since 2014 (#774149) and has
been removed from testing in 2015. It has never been in a stable release.

--
tobi

Bug#1002944: build-rdeps: Shows unfriendly errors when deb-src lines are missing

[Matthijs Kooijman]

Package: devscripts
Version: 2.21.7
Severity: normal

Hi,

when running build-rdeps without deb-src lines in sources.list, it
produces perl errors, rather than providing useful feedback. This also
happens when a deb-src line is present for the main packages, but
missing for debug packages.

E.g. with these sources:

  deb http://ftp.nl.debian.org/debian/ sid main non-free contrib
  deb http://deb.debian.org/debian-debug/ unstable-debug main

I get:

  $ sudo build-rdeps -d dh-cmake --distribution sid
  DEBUG: Package => dh-cmake
  DEBUG: running with dose-ceve resolver
  DEBUG: buildarch=amd64 hostarch=amd64
  DEBUG: Running 'apt-get' 'indextargets' 'DefaultEnabled: yes' 'Origin: Debian'
  Reverse Build-depends in main:
  --

  Use of uninitialized value $source_file in concatenation (.) or string at 
/usr/bin/build-rdeps line 336.
  DEBUG: executing: dose-ceve -T debsrc -r dh-cmake -G pkg 
--deb-native-arch=amd64 
deb:///var/lib/apt/lists/deb.debian.org_debian-debug_dists_unstable-debug_main_binary-amd64_Packages
 debsrc://Fatal error in module dose_common.input: 
   Input file  does not exist.
  No reverse build-depends found for dh-cmake.

  Reverse Build-depends in main:
  --

  Use of uninitialized value $source_file in concatenation (.) or string at 
/usr/bin/build-rdeps line 336.
  DEBUG: executing: dose-ceve -T debsrc -r dh-cmake -G pkg 
--deb-native-arch=amd64 
deb:///var/lib/apt/lists/ftp.nl.debian.org_debian_dists_sid_main_binary-amd64_Packages
 debsrc://Fatal error in module dose_common.input: 
   Input file  does not exist.
  No reverse build-depends found for dh-cmake.

  Reverse Build-depends in contrib:
  --

  Use of uninitialized value $source_file in concatenation (.) or string at 
/usr/bin/build-rdeps line 336.
  DEBUG: executing: dose-ceve -T debsrc -r dh-cmake -G pkg 
--deb-native-arch=amd64 
deb:///var/lib/apt/lists/ftp.nl.debian.org_debian_dists_sid_contrib_binary-amd64_Packages
 debsrc://Fatal error in module dose_common.input: 
   Input file  does not exist.
  No reverse build-depends found for dh-cmake.

  Reverse Build-depends in non-free:
  --

  Use of uninitialized value $source_file in concatenation (.) or string at 
/usr/bin/build-rdeps line 336.
  DEBUG: executing: dose-ceve -T debsrc -r dh-cmake -G pkg 
--deb-native-arch=amd64 
deb:///var/lib/apt/lists/ftp.nl.debian.org_debian_dists_sid_non-free_binary-amd64_Packages
 debsrc://Fatal error in module dose_common.input: 
   Input file  does not exist.
  No reverse build-depends found for dh-cmake.


Looking at the source, it seems that collectfiles() looks at Sources files, but
also Packages to find the arch. So for dists without a deb-src line, this lets
collectfiles() return entries that have an `Architecture` field, but no
`sources` field,

This is probably easy to fix by just letting findreversebuilddeps() check for
missing `sources` and showing an appropriate message.

Gr.

Matthijs


-- Package-specific info:

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

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

-- System Information:
Debian Release: 11.0
  APT prefers impish-updates
  APT policy: (500, 'impish-updates'), (500, 'impish-security'), (500, 
'impish'), (100, 'impish-backports'), (50, 'testing-debug'), (50, 
'stable-security'), (50, 'stable-debug'), (50, 'unstable'), (50, 'testing'), 
(50, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.13.0-22-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
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 devscripts depends on:
ii  dpkg-dev  1.20.9ubuntu2
ii  fakeroot  1.25.3-1.1ubuntu2
ii  file  1:5.39-3
ii  gnupg 2.2.20-1ubuntu4
ii  gnupg22.2.20-1ubuntu4
ii  gpgv  2.2.20-1ubuntu4
ii  libc6 2.34-0ubuntu3
ii  libfile-dirlist-perl  0.05-2
ii  libfile-homedir-perl  1.006-1
ii  libfile-touch-perl0.11-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20200505.0-1
ii  libmoo-perl   2.004004-1
ii  libwww-perl   6.53-1
ii  patchutils0.4.2-1
ii  perl  5.32.1-3ubuntu3
ii  python3   3.9.4-1build1
ii  sensible-utils0.0.14
ii  wdiff 1.2.2-2build2

Versions of packages devscripts recommends:
ii  apt 2.3.9
ii  curl7.74.0-1.3ubuntu2
ii  dctrl-tools 2.24-3
ii  debian-keyring  2021.09.25
ii  dput1.1.0ubuntu2
ii  dupload 2.9.6
ii  equivs  2.3.1
ii  libdistro-info-perl 1.0
ii  libdpkg-perl1.20.9ubuntu2
ii  libencode-locale-perl   1.05-1.1
ii  

Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption

[GCS]

On Sat, Jan 1, 2022 at 2:30 PM Karsten  wrote:
> But it would be helpful for others what must be done to create and install 
> this new "client side certificate" that
> appears about 2018?
 I think the certificate issue was there right from the beginning.
OpenSSL might not have forced its usage or just ignored it if it
wasn't present? But in modern times everyone should be aware of
privacy and if s/he really connects to the valid server and not
suffering a man in the middle attack. As noted, if you don't care
about your own safety, just use fetchmail with --nosslcertck.
You should already have your Certificate Authority (CA) key. The
missing step documented there:
https://www.ssl.com/how-to/export-certificates-private-key-from-pkcs12-file-with-openssl/
and is (where INFILE is your CA key in PKCS #12 format):
openssl pkcs12 -in INFILE.p12 -out OUTFILE.crt -nokeys
Then feed it to fetchmail with --sslcertfile. But I don't do it often,
might be wrong as I don't even know your particular state.

Regards,
Laszlo/GCS

Bug#1002943: O: faenza-icon-theme -- Faenza icon theme

[Tobias Frost]

Package: wnpp

The current maintainer of faenza-icon-theme, Rogério Brito ,
has retired.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: faenza-icon-theme
Binary: faenza-icon-theme
Version: 1.3.1-1.1
Maintainer: Rogério Brito 
Build-Depends: debhelper (>= 9)
Architecture: all
Standards-Version: 3.9.5
Format: 3.0 (quilt)
Files:
 294fc7de6cee512f86aeb004fec9e18c 1936 faenza-icon-theme_1.3.1-1.1.dsc
 b5339b70cbb821b583499e725957b150 24647057 faenza-icon-theme_1.3.1.orig.tar.gz
 399a78467820518419496ea5d1500829 3764 faenza-icon-theme_1.3.1-1.1.debian.tar.xz
Vcs-Browser: https://github.com/rbrito/pkg-faenza-icon-theme
Vcs-Git: https://github.com/rbrito/pkg-faenza-icon-theme.git
Checksums-Sha256:
 ff963e7e187f92779834006242d299c8299e00d8609f21e6492c01d0d4db3c48 1936 
faenza-icon-theme_1.3.1-1.1.dsc
 afd1c32229989e4cf09733c1ce5f2a651e585d86f45e98e9de6e8813f15d0edc 24647057 
faenza-icon-theme_1.3.1.orig.tar.gz
 420175a2e2e5ee9c78ebde2686b639fe39bc57b03f1ad00a12b3e773c5df4bfa 3764 
faenza-icon-theme_1.3.1-1.1.debian.tar.xz
Homepage: http://launchpad.net/~tiheum/+archive/equinox
Package-List: 
 faenza-icon-theme deb gnome optional arch=all
Directory: pool/main/f/faenza-icon-theme
Priority: optional
Section: misc

Package: faenza-icon-theme
Version: 1.3.1-1.1
Installed-Size: 89381
Maintainer: Rogério Brito 
Architecture: all
Description-en: Faenza icon theme
 The Faenza icon theme provide monochromatic icons for panels, toolbars and
 buttons and squared colorful icons for applications, devices, folders and
 files.
Description-md5: 941fa312255dd677f04be27f31c278b0
Homepage: http://launchpad.net/~tiheum/+archive/equinox
Section: gnome
Priority: optional
Filename: pool/main/f/faenza-icon-theme/faenza-icon-theme_1.3.1-1.1_all.deb
Size: 17209488
MD5sum: 1dc39d54a66573e4a8de81c5145bde70
SHA256: ce2952f288b49c2bc75e051305c3e1276146ee86b3dcb5a6a0d71527ef362926

Bug#993001: ejabberd: send_message API command is broken in 21.01 (fixed in 21.04+)

[Philipp Huebner]

Hi Daniel,

I have prepared a fixed source package for Debian 11.
You can download a fixed binary package for amd64 here:
https://apt.debalance.de/pool/main/e/ejabberd/ejabberd_21.01-2+deb11u1_amd64.deb

Please verify the fix, I will then request Debian 11 to be updated.

Regards
-- 
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1002921: installation-reports: No Screen Reader, Cannot boot into MATE GUI, Root only can

[D.J.J. Ring, Jr.]

Also I just used
systemctl set-default multi-user.target to change to a console log in.

I cannot log in as user, only as root.
GUI can also only be started as root.
Have espeakup in console by as soon as log into Mate using root account, no
sound, Orca setup has no speech settings.

Regards,

David

On Sat, Jan 1, 2022 at 9:39 AM D.J.J. Ring, Jr.  wrote:

> Thanks,
>
> Here they are.
>
> Regards,
> David
>
> On Sat, Jan 1, 2022 at 8:59 AM Holger Wansing 
> wrote:
>
>> Hi,
>>
>> "David J. Ring, Jr."  wrote (Sat, 1 Jan 2022 00:11:22
>> -0500):
>> > Boot method: USB
>> > Image version: Image version: firmware-11.2.0-amd64-DVD-1.iso
>> https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/11.2.0+nonfree/amd64/iso-dvd/firmware-11.2.0-amd64-DVD-1.iso
>> 2021-12-18
>> > Date: 
>> >
>> > Machine: Machine: Intense-PC2-BRW (IPC2) (System SKUNumber)
>> > Partitions: 
>> >
>> >
>> > Base System Installation Checklist:
>> > [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
>> >
>> > Initial boot:   [ ]
>> > Detect network card:[ ]
>> > Configure network:  [ ]
>> > Detect media:   [ ]
>> > Load installer modules: [ ]
>> > Clock/timezone setup:   [ ]
>> > User/password setup:[ ]
>> > Detect hard drives: [ ]
>> > Partition hard drives:  [ ]
>> > Install base system:[ ]
>> > Install tasks:  [ ]
>> > Install boot loader:[ ]
>> > Overall install:[ ]
>>
>> You did not provide useful information about the installation, so there is
>> no way to debug your situation.
>>
>> You should provide the installer log files (to be found in
>> /var/log/installer).
>> Sent them compressed to this bugreport.
>>
>> I ran a test installation of Debian 11 with MATE, and everything seems to
>> work
>> fine so far...
>>
>>
>> Holger
>>
>>
>>
>>
>> --
>> Holger Wansing 
>> PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
>>
>

Bug#1002942: FTBFS with ocaml-migrate-parsetree 2.3.0

[Stéphane Glondu]

Source: ppxfind
Version: 1.4-1
Severity: important
Tags: ftbfs

Dear Maintainer,

Your package FTBFS with ocaml-migrate-parsetree 2.3.0 with the
following error:
> File "src/ppxfind.ml", line 74, characters 2-35:
> 74 |   Migrate_parsetree.Driver.register ~name:tool
>^
> Error: Unbound module Migrate_parsetree.Driver

This was discovered while preparing the transition to OCaml 4.13.1.

Packages rebuilt with OCaml 4.13.1 are available at:

  https://ocaml.debian.net/transitions/ocaml-4.13.1/


Cheers,

-- 
Stéphane


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (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

Bug#1002941: FTBFS with ocaml-migrate-parsetree 2.3.0

[Stéphane Glondu]

Source: ppx-tools-versioned
Version: 5.4.0-1
Severity: important
Tags: ftbfs

Dear Maintainer,

Your package FTBFS with ocaml-migrate-parsetree 2.3.0 with many errors.

This was discovered while preparing the transition to OCaml 4.13.1.

Packages rebuilt with OCaml 4.13.1 are available at:

  https://ocaml.debian.net/transitions/ocaml-4.13.1/


Cheers,

-- 
Stéphane


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (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

Bug#1002940: FTBFS with ocaml-migrate-parsetree 2.3.0

[Stéphane Glondu]

Source: otags
Version: 4.05.1-2
Severity: important
Tags: ftbfs

Dear Maintainer,

Your package FTBFS with ocaml-migrate-parsetree 2.3.0 with the
following error:
> ocamlopt.opt -c -w A-44 -safe-string -g -I +compiler-libs -I 
> +ocaml-migrate-parsetree otags.ml
> File "otags.ml", line 39, characters 34-52:
> 39 |   let interface = Parse.interface Versions.ocaml_405
>^^
> Error: Unbound module Versions

This was discovered while preparing the transition to OCaml 4.13.1.

Packages rebuilt with OCaml 4.13.1 are available at:

  https://ocaml.debian.net/transitions/ocaml-4.13.1/


Cheers,

-- 
Stéphane

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (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

Bug#1002937: [Pkg-nagios-devel] Bug#1002937: nagvis: [INTL:it] Italian translation of debconf messages

[Sebastiaan Couwenberg]

Control: tags -1 pending

Thanks for the updated translation, it has been applied in git and will 
be included in the next upload.


Kind Regards,

Bas

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

Bug#1002939: bilibop: [INTL:it] Italian translation of debconf messages

[Beatrice Torracca]

Package: bilibop
Severity: wishlist
Tags: patch l10n

Hi.

Please find attached the Italian translation of bilibop debconf messages.

Please include it in your next upload.

Thanks,
# Italian translation of bilibop debconf messages.
# This file is distributed under the same license as the bilibop package.
# Beatrice Torracca , 2013, 2022.
#
msgid ""
msgstr ""
"Project-Id-Version: bilibop 0.4.12\n"
"Report-Msgid-Bugs-To: bili...@packages.debian.org\n"
"POT-Creation-Date: 2020-02-08 18:15+\n"
"PO-Revision-Date: 2022-01-01 16:40+0100\n"
"Last-Translator: Beatrice Torracca \n"
"Language-Team: Italian \n"
"Language: it\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Poedit 3.0\n"

#. Type: boolean
#. Description
#: ../bilibop-rules.templates:1001
msgid "Do you intend to install bilibop-rules on a Live System ?"
msgstr "Si ha intenzione di installare bilibop-rules su un sistema Live?"

#. Type: boolean
#. Description
#: ../bilibop-rules.templates:1001
msgid ""
"Some bilibop-rules settings can be useful on non-volatile Operating Systems, "
"when running from a removable and writable media (USB sticks, external HDD "
"or SD cards); but they are currently useless or even harmful for LiveCD or "
"LiveUSB systems."
msgstr ""
"Alcune impostazioni di bilibop-rules possono essere utili su sistemi "
"operativi non volatili, quando in esecuzione da un supporto rimovibile e "
"scrivibile (pennine USB, hard-disc esterni o schede SD); sono però "
"attualmente inutili, o persino pericolose, per sistemi LiveCD o LiveUSB."

#. Type: boolean
#. Description
#: ../bilibop-rules.templates:1001
msgid ""
"If you choose this option, no other question will be asked; bilibop udev "
"rules will be applied but nothing else will be modified on your system. Note "
"that in that case, this package is overkill and you should probably replace "
"it by the lighter but as much as efficient bilibop-udev package."
msgstr ""
"Se si sceglie questa opzione, non verranno poste altre domande; le regole "
"udev di bilibop saranno applicate, ma nient'altro sarà modificato sul "
"sistema. Notare che in tale caso, questo pacchetto è sovradimensionato e si "
"dovrebbe probabilmente sostituirlo con il pacchetto bilibop-udev, più "
"leggero ma altrettanto efficiente."

#. Type: boolean
#. Description
#: ../bilibop-rules.templates:2001
msgid "Do you want to use custom bilibop rules and build them now ?"
msgstr "Usare le regole bilipop personalizzate e crearle ora?"

#. Type: boolean
#. Description
#: ../bilibop-rules.templates:2001
msgid ""
"If tens of removable media are plugged on the computer your system boots "
"from, bilibop udev rules can significantly increase boot time. This can be "
"avoided by using custom udev rules, which are specific to the device your "
"system is installed on."
msgstr ""
"Se nel computer da cui si avvia il sistema vengono inserite decine di "
"supporti rimovibili, le regole udev di bilibop possono aumentare "
"considerevolmente il tempo di avvio. Ciò può essere evitato usando regole "
"udev personalizzate che sono specifiche per il dispositivo su cui è "
"installato il proprio sistema."

#. Type: boolean
#. Description
#: ../bilibop-rules.templates:2001
msgid ""
"That said, if this device can boot from different hardware port types (as "
"USB/Firewire, USB/eSATA, USB/MMC/SD, etc.), you should check the resulting "
"rules by booting your system on the alternative port type, and if necessary "
"by running 'dpkg-reconfigure bilibop-rules' again with proper options, or "
"even by editing '/etc/udev/rules.d/66-bilibop.rules'."
msgstr ""
"Detto questo, se tale dispositivo può fare l'avvio da diversi tipi di porte "
"hardware (come USB/Firewire, USB/eSATA, USB/MMC/SD, ecc.), controllare le "
"regole risultanti avviando il sistema sul tipo alternativo di porta e, se "
"necessario, eseguendo nuovamente «dpkg-reconfigure bilibop-rules» con le "
"opzioni appropriate o anche modificando «/etc/udev/rules.d/66-bilibop.rules»."

#. Type: select
#. Choices
#: ../bilibop-rules.templates:3001
msgid "keep existing custom rules"
msgstr "mantenere le regole personalizzate esistenti"

#. Type: select
#. Choices
#: ../bilibop-rules.templates:3001
msgid "rebuild custom rules"
msgstr "ricreare le regole personalizzate"

#. Type: select
#. Choices
#: ../bilibop-rules.templates:3001
msgid "remove custom rules"
msgstr "rimuovere le regole personalizzate"

#. Type: select
#. Description
#: ../bilibop-rules.templates:3002
msgid "What do you want to do with your custom rules ?"
msgstr "Cosa si desidera fare con le regole personalizzate?"

#. Type: select
#. Description
#: ../bilibop-rules.templates:3002
msgid ""
"The file '/etc/udev/rules.d/66-bilibop.rules' exists. It is specific to the "
"drive on which your system is installed and overrides the one, more generic, "
"that is provided by the bilibop-rules package (in 

Bug#1002937: nagvis: [INTL:it] Italian translation of debconf messages

[Beatrice Torracca]

Package: nagvis
Severity: wishlist
Tags: patch l10n

Hi.

Please find attached the Italian translation of nagvis debconf messages.

Please include it in your next upload.

Thanks,
Beatrice
# Italian translation of nagvis debconf messages.
# Copyright (C) 2012, 2022 nagvis package copyright holder
# This file is distributed under the same license as the nagvis package.
# Beatrice Torracca , 2022.
msgid ""
msgstr ""
"Project-Id-Version: nagvis\n"
"Report-Msgid-Bugs-To: nag...@packages.debian.org\n"
"POT-Creation-Date: 2020-01-21 20:05+0100\n"
"PO-Revision-Date: 2022-01-01 16:44+0100\n"
"Last-Translator: Beatrice Torracca \n"
"Language-Team: Italian \n"
"Language: it\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Poedit 3.0\n"

#. Type: select
#. Choices
#: ../nagvis.templates:2001
msgid "shinken"
msgstr "shinken"

#. Type: select
#. Description
#: ../nagvis.templates:2002
msgid "Monitoring suite used with NagVis:"
msgstr "Suite di monitoraggio usata con NagVis:"

#. Type: select
#. Description
#: ../nagvis.templates:2002
msgid ""
"The NagVis package supports Icinga as well as Nagios, using the check-mk-"
"live broker backend."
msgstr ""
"Il pacchetto NagVis supporta Icinga così come Nagios, usando il backend "
"broker check-mk-live."

#. Type: select
#. Description
#: ../nagvis.templates:2002
msgid ""
"If you would like to use NagVis with a different backend or a different "
"monitoring suite, please choose \"other\". You'll have to configure it "
"manually."
msgstr ""
"Se si desidera usare NagVis con un backend diverso o una suite di "
"monitoraggio diversa, scegliere \"altro\". Sarà necessario configurarli "
"manualmente."

#. Type: boolean
#. Description
#: ../nagvis.templates:3001
msgid "Delete NagVis data when purging the package?"
msgstr "Cancellare i dati NagVis quando il pacchetto viene eliminato?"

#. Type: boolean
#. Description
#: ../nagvis.templates:3001
msgid ""
"NagVis creates files in /var/{cache,lib}/nagvis and /etc/nagvis (for "
"instance background images and map files), including a small database for "
"authentification. If you don't need any of these files, they can be removed "
"now, or you may want to keep them and clean up by hand later."
msgstr ""
"NagVis crea file in /var/{cache,lib}/nagvis e /etc/nagvis (ad esempio "
"immagini di sfondo e file mappa), incluso un piccolo database per "
"l'autenticazione. Se nessuno di questi file è necessario possono essere "
"rimossi adesso, oppure si può tenerli e ripulire a mano successivamente."

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

[Paul Gevers]

Hi,


Please enlighten me on the details of php packaging that I'm missing and that 
we should be aware of for this (and future) transition(s).


Is it true that because the api is already provided in testing that we 
now have some packages working with (and pulling in) php7.4 and some 
with php8.1 by default (in testing). Is that supposed to work 
gracefully? Or is this transition (in unstable) now also breaking 
testing in ways we don't want? Hmm, thinking a bit about this, I guess 
the php configuration needs to be enabled in mods-enabled, so package 
upgrades break already without admin intervention, right? And this has 
been that way for upgrades between stable releases as well? So, am I 
overly worried or is this all "by design"?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

[Paul Gevers]

Hi

On 01-01-2022 14:20, Ondřej Surý wrote:

2. Generate all binary packages to debian/control during the build,
but this would then require overrides (which I think doesn’t really
scale)
If you mean (re)generating debian/control during build, that's not 
allowed (albeit I can't quickly find a reference).


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1002916: [pkg-php-pear] Bug#1002916: RFS: php-nesbot-carbon/2.55.2-1 [RC] -- simple PHP API extension for DateTime

[David Prévot]

Hi Robin,

Le 01/01/2022 à 10:51, Robin Gustafsson a écrit :

On Fri, Dec 31, 2021 at 8:17 PM David Prévot  wrote:


[…]


Anyway, I just granted you DM rights on this package

[…]

Thank you! I still don't see it listed in dm.txt[1] though. Did it
process successfully?


Right, I messed up the “dcut dm” call, should be fixed now. Please do 
ping me if I failed again (might be an hourly cron to get the file updated).


Regards

David


OpenPGP_signature
Description: OpenPGP digital signature

Bug#974217: RFS: python-radexreader/1.2.1-1 [ITP] -- Reader for the RADEX RD1212 Geiger counter

[Bastian Germann]

Am 01.01.22 um 13:09 schrieb Fabrice Creuzot:
Do you know if I can add a translation of the man page in the package? Also, do you know where I can submit translation 
of the package description? I found https://ddtp.debian.org/ddtss/index.cgi/xx but I don't know if this is the right 
place or not.


I would have to check the Debian Policy for translation-related stuff as well. Maybe some other reader can answer this 
spontaneously.


Happy new year!

Bug#1002935: ITP: pwntools -- CTF framework and exploit development library

[Timo Röhling]

Package: wnpp
Severity: wishlist
Owner: Timo Röhling 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: pwntools
  Version : 4.7.0
  Upstream Author : Gallopsled et al. 
* URL : https://pwntools.com
* License : Expat, GPL, BSD
  Programming Lang: Python
  Description : CTF framework and exploit development library

pwntools is designed for rapid prototyping and development, to make
exploit writing as simple as possible. The primary use case of this
framework are CTF hacking contests, where vulnerabilities in a sandbox
environment are exploited to gain access to a "flag" file or secret
string, as proof of success.

I'm packaging this framework out of personal interest and intend to
maintain it as part of the Python Team. Most dependencies are available
in Debian already, with the exception of ROPgadget, colored_traceback,
and the RPyC Remote Procedure Call library, which are currently waiting
in NEW.


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmHQavAACgkQ+C8H+466
LVnoUwv9EUqhQQckIF2ZX4iXwJeAc8Nwtju4XZ+bq8pB1BeSjeCrfqiXeZPLrxl+
0iNS9m6uIt5dAVHcvivvyunnkKtZpc73HxUSOtbHiJd+D3Gs8CVaF32entfpqTys
o4M2yIBViKzE8mFuBZ052akWNEMVijRXaUMH+DPUvsMi6Z/iuL80J77cTzoQlweq
qoxnoI3XrY9lye58Dk5DHHTjAqIFiGju97tqxIiGs4ri3GW6MHFzflHCs65dPUt5
lpNNjGRk8p64s/wen5SAJumsVi9H8MA2u990RcYQ9WxwHISZ7FmXYfvEbgqklkx2
sWW+ENB4nRm+XeV1MVX/PG6yfRc3VUD6iR/++U+ZgBDacmjO50t152c6F1pK/MLc
SG9bvMnup4L4btX4GXYNZwkPMHHZqNzeWSjp+WT2LNqcNMk/Y4ORmAvWWeRkAID7
WwJ5Ib5nI7fSYWIFmL33ZYnFJ8xM8ZixbsFuSV6mhjzfMHUhc2bfD6AAMjHeHx9T
ef//esHq
=F7Gm
-END PGP SIGNATURE-

Bug#1002916: [pkg-php-pear] Bug#1002916: RFS: php-nesbot-carbon/2.55.2-1 [RC] -- simple PHP API extension for DateTime

[Robin Gustafsson]

Hi David,

On Fri, Dec 31, 2021 at 8:17 PM David Prévot  wrote:
>
> Hi Robin,
>
> Le 31/12/2021 à 12:56, Robin Gustafsson a écrit :
> […]
> > I am looking for a sponsor for my package "php-nesbot-carbon":
>
> I looked at the VCS and all your changes look (more than) fine, thanks
> (I only skimmed at upstream changes, but trust you did due diligence).
> You may also wish to build-depend on dh-sequence-phpcomposer (eventually
> instead of pkg-php-composer) instead of using --with phpcomposer in d/rules.

Thanks for the suggestion, I'd forgotten about that. I'll put it in
before uploading.

> Anyway, I just granted you DM rights on this package so you can upload
> it yourself (do tell if you want me to upload it directly in the mean time).

Thank you! I still don't see it listed in dm.txt[1] though. Did it
process successfully?

[1] https://ftp-master.debian.org/dm.txt#:~:text=ro...@rgson.se

Regards,
Robin

Bug#1002933: firefox-esr: crashes on armhf upon syncing

[Wenbin Lv]

Package: firefox-esr
Version: 91.4.1esr-1~deb11u1
Severity: important

Hello,

Firefox on bullseye armhf crashed after upgrading to 91esr. When I
tested with a fresh profile, firefox seemed to crash only when logged in.

Steps to reproduce:

1. run firefox-esr -profilemanager
2. create a new profile
3. log in to firefox account
4. wait some time or manually choose "sync now"

The firefox-esr-dbgsym is not ready yet for 91esr, so there's not much
interesting information I can get using gdb, except for the top of the
stack is memset(). So I submitted the crash
report to
https://crash-stats.mozilla.org/report/index/46eb6fa4-cff3-4156-a01b-7b1e90220101

Regards,
Wenbin Lv

-- Package-specific info:


-- Addons package information

-- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable')
Architecture: armhf (armv7l)

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

Versions of packages firefox-esr depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-13+deb11u2
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-2
ii  libdbus-glib-1-2 0.110-6
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi7  3.3-6
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libpango-1.0-0   1.46.2-3
ii  libstdc++6   10.2.1-6
ii  libvpx6  1.9.0-1
ii  libx11-6 2:1.7.2-1
ii  libx11-xcb1  2:1.7.2-1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxrender1  1:0.9.10-1
ii  procps   2:3.3.17-5
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages firefox-esr recommends:
ii  libavcodec58  7:4.3.3-0+deb11u1

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.004.5-6.1
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.18.3-6+deb11u1
ii  pulseaudio 14.2-2

-- no debconf information

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

[Thomas Goirand]

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)

Bug#1002932: RM: php-radius -- ROM; unsupported by PHP 8.x

[Ondřej Surý]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

PECL radius packages doesn't have support for PHP 8.x, so the package now FTBFS
after switch from PHP 7.4 to PHP 8.1 in unstable.  Please remove the package
from the archive.

Thank you,
Ondrej

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAmHQYYlfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcJ7+A//XyTc+Vqh9JJWpChGtXtHFnA1hhgGGmdO5eCvMauQ9R1Uh15KwBZ02mvB
fR5LUwAwglndZq/UHx9LgDX5fQ2focYWH6kuryMaYCexp246rw/qVfqnTVjJ+K2E
g5UN2gK+gY4jE1W/l4sYV2OwpaJkBVlLU0QXtiIGAraVsyYVZPLdTYBnBKRZX4UF
rSuAHe5VVPALu3ZaurGPjWZr/alQ3p/BFzbUFiNCy/oG5L3HG1YkE+nDLKJEtll4
zdsKfJaC3RBAyeOmBDVq1BP/9G5U7PInGKnxxQ7TbjaMMgVzDT+IH9MNh7dIYJ6N
pA4ZuqcIkPmvYM+gncf2wMSDPao376EXSVC9Gttc91y8vv1B5BHU018Kz5blV5Z3
TqrY0ietSF4NTtM3KGWjhDnyzlX8FmeXDz56M6vw+5nn/u5giZvRHsB8WMW2vOWN
uHOd82OUZ5FmJee8wYynQMwKxu3L/AKl99VgZJpqRwO6Y6htOMXNUnfVvXU5yiFz
30vMbttwJJ05kvM9N3ISjNhNh427c1Rq3X9mvUmbuA62SX2QQUUai2zonu+w8eF2
8APs19w+lyG/btnAoVyD27TZprx/9QZujRf3aMCfbpvtoGkxpStgPOCA/sgk20Iv
ljMhVFsy26Jz7qan/Co6mNsA3aJhgvwvopED7UuPMr+PpC/X/bI=
=sUhl
-END PGP SIGNATURE-

Bug#1002723: Problem is identified

[Karsten]

Hello Chris,

thank you for your support.

The problem is identified by the firewall of a Fritzbox, that is not able to 
handle correct IPV6.
After disabling IPV6 the problem disappears.

This bug report can be closed.

Happy new year
karsten

Bug#1002732: needrestart stalled in background when performing update with KDE Discover

[Thomas Liske]

Hi,

could you check running needrestart as root on cli if you have any
pending restarts?

You might try to reinstall a lib to trigger needrestart (i.e. via apt-
get install --reinstall libnss3 - this *should* not break anything) to
force to get a pending restarts.

Please check if needrestart and debconf-kde-helper are working when
using KDE Discover afterwards.


Regards,
Thomas


On Fri, 2021-12-31 at 10:10 -0500, Ryan Armstrong wrote:
> I did not, but your message prompted me to go looking a bit. I found
> I had 
> not installed debconf-kde-helper. I would have expected a package
> like this to 
> get pulled in when I installed KDE, so I expect it is missing as a
> dependency 
> (for plasma-discover perhaps?)
> 
> In my setup, KDE was installed onto an existing setup by running `apt
> install 
> kde-plasma-desktop`
> 
> I did one update after installing the helper, but didn't notice
> anything (it 
> didn't stall, though). As long as that fixes the problem, I guess
> this bug 
> should be redirected as a dependency issue?
> 
> Ryan
> 
> On Friday, December 31, 2021 9:54:02 A.M. EST you wrote:
> > Hi Ryan,
> > 
> > needrestart should not block if it is run non-interactive. On
> > Debian it
> > uses the debconf frontend which also has graphical frontends. Do
> > you
> > get debconf dialogs in KDE Discover when installing/updating
> > packages
> > at all? (Sorry I do not have an KDE environment for testing.)
> > 
> > 
> > Regards,
> > Thomas
> > 
> > On Tue, 2021-12-28 at 08:33 -0500, Ryan Armstrong wrote:
> > > Package: needrestart
> > > Version: 3.5-5
> > > Severity: normal
> > > 
> > > Dear Maintainer,
> > > 
> > > When I performed an update with KDE Discover, I noticed it
> > > stalled at
> > > 99% complete status and would not finish. When I checked the
> > > process
> > > tree with htop, I noticed the following lines from packagekitd
> > > and
> > > needrestart:
> > > 
> > >    2629 root   20   0  492M  124M 79624 S  0.0  0.8  0:29.20
> > > ├─
> > > /usr/libexec/packagekitd
> > >    2632 root   20   0  492M  124M 79624 S  0.0  0.8  0:00.00
> > > │ 
> > > ├─ /usr/libexec/packagekitd
> > >    2634 root   20   0  492M  124M 79624 S  0.0  0.8  0:00.05
> > > │ 
> > > ├─ /usr/libexec/packagekitd
> > >   14075 root   20   0  492M  124M 79624 S  0.0  0.8  0:05.78
> > > │ 
> > > ├─ /usr/libexec/packagekitd
> > >   14090 root   20   0  494M 99648 50800 S  0.0  0.6  0:00.24
> > > │ 
> > > └─ /usr/libexec/packagekitd
> > >   25864 root   20   0  494M 51924  2336 S  0.0  0.3  0:00.00
> > > │ └─ /usr/libexec/packagekitd
> > >   25872 root   20   0  2472   704   616 S  0.0  0.0  0:00.00
> > > │    └─ sh -c test -x /usr/lib/needrestart/apt-pinvoke &&
> > > /usr/lib/needrestart/apt-pinvoke || true
> > >   25873 root   20   0 35864 27816  6140 S  0.0  0.2  0:00.64
> > > │   └─ /usr/bin/perl /usr/sbin/needrestart
> > > 
> > > It appears that packagekit is still running needrestart to ask if
> > > I
> > > want to restart systemd services. However, this prompt is
> > > obviously
> > > not
> > > visible to me through KDE Discover, so it's stuck waiting
> > > forever.
> > > 
> > > If I use kill on needrestart, the Discover session completes.
> > > 
> > > Since, this is an interaction between Discover, packagekit, apt
> > > and
> > > needrestart (possibly others?), I'm not 100% sure this is the
> > > right
> > > place for it. Feel free to reassign if I got it wrong.
> > > 
> > > Ryan
> > > 
> > > -- Package-specific info:
> > > needrestart output:
> > > Your outdated processes:
> > > akonadi_archive[3076], akonadi_mailfil[3102],
> > > akonadi_sendlat[3116],
> > > akonadi_unified[3117], blueman-applet[2663], Discord[2921, 2924,
> > > 2967, 2922, 2958, 2917, 3276, 3044], DiscoverNotifie[2571],
> > > evolution-addre[2767], evolution-alarm[2660], evolution-
> > > calen[2742],
> > > evolution-sourc[2698], goa-daemon[2704], kmail[2936],
> > > kwin_x11[2488],
> > > nextcloud[2656], plasmashell[2554], QtWebEngineProc[6196, 6215,
> > > 6194,
> > > 6193], tracker-miner-f[2674], xdg-desktop-por[2375], xdg-
> > > document-
> > > po[2392], xdg-permission-[2397]
> > > 
> > > 
> > > 
> > > -- System Information:
> > > Debian Release: bookworm/sid
> > >   APT prefers testing
> > >   APT policy: (900, 'testing'), (300, 'unstable')
> > > Architecture: amd64 (x86_64)
> > > Foreign Architectures: i386
> > > 
> > > Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads)
> > > Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
> > > LANGUAGE=en_GB:en_US
> > > Shell: /bin/sh linked to /bin/dash
> > > Init: systemd (via /run/systemd/system)
> > > LSM: AppArmor: enabled
> > > 
> > > Versions of packages needrestart depends on:
> > > ii  binutils   2.37-7
> > > ii  dpkg   1.21.1
> > > ii  gettext-base   0.21-4
> > > ii  libintl-perl   1.26-3
> > > ii  libmodule-find-perl    0.15-1
> > > ii  libmodule-scandeps-perl    1.31-1
> > > 

Bug#1001067: synaptic: Crushing when searching. Error: Segmentation Fault

[Adrian Bunk]

On Fri, Dec 03, 2021 at 03:36:56PM +0100, Mirko Saulino wrote:
> Package: synaptic
> Version: 0.90.2
> Severity: grave
> Tags: a11y
> Justification: renders package unusable
> X-Debbugs-Cc: merambo...@gmail.com
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation? It happened after the installation of
> the makedeb package

The makedeb package is not in Debian, and synaptic does not seem to 
crash otherwise.

>* What exactly did you do (or not do) that was effective (or
>  ineffective)? After discovering the problem i uninstalled makedeb with 
> apt and all its dependencies but nothing changed
>...

Please provide a backtrace [1] for this segmentation fault.

Thanks
Adrian

[1] https://wiki.debian.org/HowToGetABacktrace

Bug#1002591: misdetects socket activated ssh

[Thomas Liske]

Hi Marc,


could you please provide the content of /proc/$PID/cgroup for an socket
activated sshd instance?

As a workaround you might blacklist sshd in needrestart but I think a
generic approach handling socket activation services in needrestart
would be better. Therefore needrestart need a way to detect if the
process belongs to a socket activated service.


TIA & HTH,
Thomas


On Fri, 2021-12-24 at 22:25 +0100, Marc Haber wrote:
> Package: needrestart
> Version: 3.5-5
> Severity: normal
> 
> Hi,
> 
> when using ssh as a socket activated service (systemctl stop/disable
> ssh.service, systemctl enable/start ssh.socket), after a library
> update
> needrestart will offer to restart ssh.service. This fails since port
> 22
> is occupied by the instance services and causes the machine to be
> without listening process after logging out.
> 
> A possible workaround is masking ssh.service, see #1001320.
> 
> Restarting services...
>  systemctl restart console-log.service cron.service exim4.service
> haveged.service ippl.service ntp.service rsyslog.service
> serial-getty@ttyS0.service ssh.service systemd-journald.service
> systemd-networkd.service systemd-resolved.service systemd-
> udevd.service
> Job for ssh.service failed because the control process exited with
> error code.
> See "systemctl status ssh.service" and "journalctl -xeu ssh.service"
> for details.
> Service restarts being deferred:
>  /etc/needrestart/restart.d/dbus.service
>  systemctl restart getty@tty1.service
>  systemctl restart systemd-logind.service
>  systemctl restart user@1001.service
> 
> and the following log entries:
> Dec  8 12:58:26 emptybookworm82 systemd[1]: Stopping LSB: Puts a
> logfile pager on virtual consoles...
> Dec  8 12:58:26 emptybookworm82 systemd[1]: Stopping Regular
> background program processing daemon...
> Dec  8 12:58:26 emptybookworm82 systemd[1]: cron.service: Deactivated
> successfully.
> Dec  8 12:58:26 emptybookworm82 cron[429258]: (CRON) INFO (pidfile fd
> = 3)
> Dec  8 12:58:26 emptybookworm82 systemd[1]: Stopped Regular
> background program processing daemon.
> Dec  8 12:58:26 emptybookworm82 systemd[1]: cron.service: Consumed
> 15min 4.856s CPU time.
> Dec  8 12:58:26 emptybookworm82 systemd[1]: Started Regular
> background program processing daemon.
> Dec  8 12:58:26 emptybookworm82 systemd[1]: Stopping LSB: exim Mail
> Transport Agent...
> Dec  8 12:58:26 emptybookworm82 systemd[1]: Stopping Entropy Daemon
> based on the HAVEGE algorithm...
> Dec  8 12:58:26 emptybookworm82 systemd[1]: Stopping LSB: IP
> protocols logger...
> Dec  8 12:58:26 emptybookworm82 systemd[1]: Stopping Network Time
> Service...
> Dec  8 12:58:26 emptybookworm82 systemd[1]: Stopping System Logging
> Service...
> Dec  8 12:58:26 emptybookworm82 systemd[1]: Stopping Serial Getty on
> ttyS0...
> Dec  8 12:58:26 emptybookworm82 systemd[1]:
> serial-getty@ttyS0.service: Deactivated successfully.
> Dec  8 12:58:26 emptybookworm82 systemd[1]: Stopped Serial Getty on
> ttyS0.
> Dec  8 12:58:26 emptybookworm82 systemd[1]: Started Serial Getty on
> ttyS0.
> Dec  8 12:58:26 emptybookworm82 systemd[1]: ssh.socket: Deactivated
> successfully.
> Dec  8 12:58:26 emptybookworm82 systemd[1]: Closed OpenBSD Secure
> Shell server socket.
> Dec  8 12:58:26 emptybookworm82 systemd[1]: ssh.socket: Consumed
> 10.571s CPU time.
> Dec  8 12:58:26 emptybookworm82 systemd[1]: Starting OpenBSD Secure
> Shell server...
> Dec  8 12:58:26 emptybookworm82 systemd[1]: Stopping Flush Journal to
> Persistent Storage...
> Dec  8 12:58:26 emptybookworm82 systemd[1]: systemd-networkd-wait-
> online.service: Deactivated successfully.
> Dec  8 12:58:26 emptybookworm82 systemd[1]: Stopped Wait for Network
> to be Configured.
> Dec  8 12:58:26 emptybookworm82 systemd[1]: Stopping Wait for Network
> to be Configured...
> Dec  8 12:58:26 emptybookworm82 systemd[1]: Stopping Network Name
> Resolution...
> Dec  8 12:58:26 emptybookworm82 systemd[1]: ssh.service: Main process
> exited, code=exited, status=255/EXCEPTION
> Dec  8 12:58:26 emptybookworm82 systemd[1]: ssh.service: Failed with
> result 'exit-code'.
> Dec  8 12:58:26 emptybookworm82 systemd[1]: Failed to start OpenBSD
> Secure Shell server.
> Dec  8 12:58:26 emptybookworm82 ntpd[298]: ntpd exiting on signal 15
> (Terminated)
> Dec  8 12:58:26 emptybookworm82 ntpd[298]: 2a01:4f8:140:246a::2 local
> addr 2a01:4f8:140:246a::52:100 -> 
> Dec  8 12:58:26 emptybookworm82 haveged[220]: haveged: Stopping due
> to signal 15
> Dec  8 12:58:27 emptybookworm82 cron[429258]: (CRON) INFO (Skipping
> @reboot jobs -- not system startup)
> Dec  8 12:58:27 emptybookworm82 systemd[1]: systemd-journal-
> flush.service: Deactivated successfully.
> Dec  8 12:58:27 emptybookworm82 systemd[1]: Stopped Flush Journal to
> Persistent Storage.
> Dec  8 12:58:27 emptybookworm82 exim4[429259]:  exim4_listener.
> 
> Here is what Timo Weingärtner found out in relation to my bug report
> against sshd:
> 
> > To me it looks like a problem in 

Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption

[Karsten]

Hello Matthias,

Am 01.01.22 um 14:10 schrieb Matthias Andree:
> Notice something?

i notice everything. :-)

> 
> You hijack somebody else's domain for "anonymization" purposes and
> expect someone to help you, and you did not respond to hints the server
> CA's signing certificate might be missing from the trust store.

I am the owner of the domain so nobody is hijacked!

A self signing certificate is absolutely sufficient and perfect for private use.
Why everybody has to be forced to use official certificates?

> Checking with another computer that has a proper installation is
> impossible if you fake data.

Sorry for that, but we are talking about private data and this is an official 
portal here.

> Be sure to install and configure the ca-certificates package - in case
> you had installed fetchmail with --no-install-recommends.

The server has been upgraded from Debian 9 to Debian 11.
So nothing has been manually installed or configured, espacially any 
ca-certificates package.

The same TLS1.2 as before shall be used, so it is not understandable why 
addtional things are mandantory now?
Why old certificates cannot be used any more when the client that uses a server 
is upgraded?

>> In the Internet are a mass of similar problems with fetchmail, but no 
>> description what exactly must be done to solve it.
> 
> Because "similar problems" are usually a broken setup of either
> server-side certificates that don't trace back to commonly used and
> trusted stores (Mozilla's trusted CA package, mostly), or local broken
> setups.

This "stores" are a big problem of public monitoring, because every certificate 
causes requests to this central "stores".

Another problem is to work with certificates and networks, that have no 
internet connection.

> HTH - else you need to provide original data and more information.

I can send this private to your email address.

But it would be helpful for others what must be done to create and install this 
new "client side certificate" that
appears about 2018?

Best regards
karsten

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

[Ondřej Surý]

> On 1. 1. 2022, at 9:01, Paul Gevers  wrote:
> 
> Hi,
> 
> On 31-12-2021 21:25, Paul Gevers wrote:
>> Hi Ondřej, PHP PECL Maintainers,
>> On 31-12-2021 12:50, Ondřej Surý wrote:
>>> Uploaded php 8.1.1 and php-defaults 91 switching the Debian PHP version to 
>>> PHP 8.1
>> Thanks.
>> Will you also upload src:php-imagick, which seems to block some rebuilds in 
>> the current state.
>> I want to update the ben transition tracker file to catch these kind of 
>> packages. Should I add a "Depends on php7.4-common" to the "bad" list?
> 
> It seems I don't understand how PHP packaging works. I scheduled rebuilds of 
> several packages that were yesterday on the tracker page [1] when that still 
> only had the phpapi-* listed. Several packages can't be build yet it seems 
> (because they depend on packages that need new uploads), but e.g. wikidiff2 
> built fine *but disappeared* from the tracker. I looked at a build log [2] 
> and noticed that the binary has files in /etc/php8.1 (and not in 
> /etc/php7.4), but doesn't tell otherwise (in package relations) that it's 
> meant for php8.1 and not for php7.4. Why did that phpapi-* thing disappear? 
> Is that intended? The built binaries already migrated to testing, while the 
> default there is still php7.4. I assume we can consider php-wikidiff2 
> (partially?) broken now *in testing*? Same for php-luasandbox [3], php-geos 
> [4], and php-excimer [5] (which also FTBFS on mipsel).

This has been tracker as #1000233 and hopefully fixed in dh-php 4.4

> Some rebuilds failed, e.g. php-horde-lz4 [6],

The FTBFS is unrelated to PHP 8.1 transition

> php-wmerrors [7], owfs [8].

These two need upstream update.

> I also notice that quite some php packages grew a php7.4-* package in 
> unstable. Is the idea that that needs to be done for php8.1 too and that all 
> those packages require a round trip through NEW? If that's the case, next 
> time please prepare those in experimental, such that we don't need to wait 
> for processing of NEW during the transition. If that's not the case, please 
> upload new versions of those packages dropping the php7.4 package.

Yes, I rewrote the helper scripts for PECL based packages, and I haven’t 
realized this. The idea is to align the embedded extensions schema[a] with the 
externally (PECL) distributed extensions. This is bit tricky though, I was 
faced with two options:

1. Add all binary packages to debian/control directly and do the NEW queue
2. Generate all binary packages to debian/control during the build, but this 
would then require overrides (which I think doesn’t really scale)

> Please enlighten me on the details of php packaging that I'm missing and that 
> we should be aware of for this (and future) transition(s).

Currently, there are two types:

1. arch:any php- that contains the extension and the configuration - uses 
whatever build system is there
2. arch:all php- depending on arch:any phpX.Y- that uses 
/usr/share/dh-php/pkg-pecl.mk Makefile snippet which does a lot of “magic”, but 
so is a bit fragile as everything that is “magic” is.

Ondrej

a. Arch: any package php.- and Arch: all  package php- that 
depend on it
--
Ondřej Surý (He/Him)
ond...@sury.org

> Paul
> 
> [1] https://release.debian.org/transitions/html/php8.1.html
> [2] 
> https://buildd.debian.org/status/fetch.php?pkg=wikidiff2=amd64=1.13.0-1%2Bb1=1640981156=0
> [3] https://buildd.debian.org/status/package.php?p=php-luasandbox
> [4] https://buildd.debian.org/status/package.php?p=php-geos
> [5] https://buildd.debian.org/status/package.php?p=php-excimer
> [6] https://buildd.debian.org/status/package.php?p=php-horde-lz4
> [7] https://buildd.debian.org/status/package.php?p=php-wmerrors
> [8] https://buildd.debian.org/status/package.php?p=owfs



signature.asc
Description: Message signed with OpenPGP

Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption

[Karsten]

Hello Matthias,

Am 31.12.21 um 20:05 schrieb Matthias Andree:
>> What must be done to get it working again?

This question has not been answered.
I could only find out that this problems did arrive with the introduction of 
TLS1.3.

> Unless you own "mydomain.de" you've now hit innocent bystanders, and in
> that case, making up log data with a domain you do not own is not helpful.

The security relevant logdata is of course anonymized or altered.

>
> If Thunderbird can fetch, either it has a local trust setting, or you've
> missed installing the ca-certificates package, or, as László suggested,
> the certificate is self-signed and you have not installed the signing
> CA's certificate in the trust store.

The OS of the client PC with Thunderbird and of the mailserver has not been 
upgraded, so why there should appear any
problem?
The problem only appears on the upgraded server, that downloads the emails and 
provides them internally.
There where no problems with the upgrade of exim or dovecot, only with 
fetchmail.

In the Internet are a mass of similar problems with fetchmail, but no 
description what exactly must be done to solve it.
So maybe it would be a good idea to create such needed certificates with the 
upgrade scripts.

Happy new year
karsten

Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption

[Matthias Andree]

Happy new year Karsten.


Am 01.01.22 um 13:53 schrieb Karsten:

Hello Matthias,

Am 31.12.21 um 20:05 schrieb Matthias Andree:

What must be done to get it working again?

This question has not been answered.
[...]
The security relevant logdata is of course anonymized or altered.


Notice something?

.

.

.

You hijack somebody else's domain for "anonymization" purposes and
expect someone to help you, and you did not respond to hints the server
CA's signing certificate might be missing from the trust store.

Checking with another computer that has a proper installation is
impossible if you fake data.

Be sure to install and configure the ca-certificates package - in case
you had installed fetchmail with --no-install-recommends.


In the Internet are a mass of similar problems with fetchmail, but no 
description what exactly must be done to solve it.


Because "similar problems" are usually a broken setup of either
server-side certificates that don't trace back to commonly used and
trusted stores (Mozilla's trusted CA package, mostly), or local broken
setups.

HTH - else you need to provide original data and more information.

Regards,
Matthias