Bug#988947: Re: Bug#988947: redis configuration does not load fragments by default

[Sam Bortman]

Thank you, for your reply and time.
I have taken your advice and looked this up on github.  It turns out that
someone already asked the dev to add this functionality.
Here's a URL:
https://github.com/redis/redis/issues/6351

Hopefully, the dev will produce a fix soon.  When they do, I'll update you
here.

Thanks again!
  S.

On Sat, 22 May 2021 11:35:31 +0100 "Chris Lamb"  wrote:
> tags 988947 + upstream
> Redis does not currently support this. Can you therefore file a
> request with upstream?

Bug#988652: logrotate: kern.log,syslog and other files in /var/log not rotating

[UN-pi]

> syslog.1 is newer then syslog. So some log messages ended up in syslog,
> but rsyslog then continued to write to syslog.1 ?
> If you were referring to that problem, can you share what has been
> written to syslog and syslog.1?

Please take a look on my message from Sat, 22 May 2021 03:18:01 +0200,
where I uploaded parts of syslog und syslog.1.

The protocols look similar today.The entries in syslog.1 do not end at
midnight.

Bug#814382: RFH: samba -- SMB/CIFS file, print, and login server for Unix

[Abi]

Hello Mathieu,

I saw the help request submitted to the samba mailing list by A. 
Bartlett on 05/14 . I would love to help with triaging bug 
reports/improving tests .  What steps would I need to take in order to 
get involved?


Let me know. Thanks.

Bug#989001: follow up on memtest86+ issue

[Junichi Uekawa]

Hi,

Seems like I was too quick to decide it was graphics mode, after setting 
/etc/default/grub with:

  # Uncomment to disable graphical terminal (grub-pc only)
  GRUB_TERMINAL=console


with a text mode console, after selecting memtest86+ in grub menu the
screen is black and nothing appears. Might be something with the
machine.

Bug#988951: regression: focus_path on last items no longer works properly

[Cyril Brulebois]

Cyril Brulebois  (2021-05-21):
> There might be simpler (shorter) ways to trigger this but the following
> is robust:
> 
>  - Initially detected while testing an encrypted LVM install in Swedish
>(confirming all hangs go away), when reaching the partition layout
>confirmation dialog, the selected entry is the last one in the list,
>but the selection isn't seen. One might wonder where the focus is,
>why no entry was selected, etc. Since that can happen in various
>places, I think users might get confused. That should not be specific
>to Swedish, it just happens to be the first occurrence I noticed.

That particular part seems solved with my current hackish patch series.

>  - Slightly shorter (`kvm -m 1G -cdrom mini.iso`, no disk layout or even
>disk required), pick a language like French and all default choices,
>until the mirror country selection, pick the very last one
>(États-Unis), and on the mirror host selection, pick the very last
>one again (the actual hostname doesn't matter). Now, on the next
>dialog, hit “Revenir en arrière” (Back), and see the selected
>hostname isn't focussed. Another step back shows the selected country
>isn't focussed either. That should happen with other languages as
>well, using French has the main advantage for me to get the
>appropriate keyboard layout automatically plus get two “back” steps
>that exhibit the problem (other countries might not have a mirror
>list as big as the US one).

That one is strange:
 - getting back to mirror hostname selection is still buggy;
 - getting back to mirror country selection is no longer buggy.

I'm not sure whether my current approach can be refined to work in all
cases, but solving at least the obvious “forward-only” (= no step back)
issue that was seen at least on the layout confirmation screen… seems
worth considering for bullseye, even if it's ugly and doesn't solve all
cases? And maybe users are going to tell us about other occurrences
because of different languages/options combinations that result in
different layout, triggering the scrolling issue or not.

> Next on my list of things to try was adding a pointer to the frontend
> object (and its `data` member) so that we could keep the callback alive
> until set_text_in_idle has done its job. I thought it might need some
> mutex or locking around a counter of pending set_text calls and I
> haven't touched that yet. And today, the following rang a bell… :)
>   https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/7

Merging that on top of my code didn't seem to make any difference
regarding the “back to the mirror hostname selection” issue that
remains.

I'll try and tidy up my patches, and push a branch somewhere, also
posting traces that show that events seem to have happened in the right
order.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#989002: freshclam: apparmor denial: operation="capable" capability=2 capname="dac_read_search"

[Paul Wise]

Package: clamav-freshclam
Version: 0.103.2+dfsg-2
Severity: normal
File: /etc/apparmor.d/usr.bin.freshclam
Usertags: apparmor

Whenever freshclam gets restarted, either manually or automatically
during package upgrades, I get an apparmor denial in the logs. I
haven't seen any adverse effects from this denial. Reading the
capabilities(7) manual page where CAP_DAC_READ_SEARCH is mentioned,
there doesn't seem to be any reason for freshclam to need this
capability so I don't think the freshclam binary should be using this
capability. I note that the clamav codebase doesn't mention this
capability at all. I note that the apparmor profile mentions
dac_override and a comment next to that mentions a Launchpad bug that
explains this is for the AllowSupplementaryGroups option, which is
disabled by default. I wonder if whatever allows that to work has
switched from dac_override to dac_read_search, but I'm still not sure
why freshclam should also be using that capability.

https://manpages.debian.org/capabilities
https://launchpad.net/bugs/433764

   May 23 08:16:39 sudo[95446]: pabs : TTY=pts/7 ; PWD=/home/pabs ; 
USER=root ; COMMAND=/usr/sbin/service clamav-freshclam restart
   May 23 08:16:39 sudo[95446]: pam_unix(sudo:session): session opened for user 
root(uid=0) by (uid=1000)
   May 23 08:16:39 kernel: audit: type=1400 audit(1621728999.029:77): 
apparmor="DENIED" operation="capable" profile="/usr/bin/freshclam" pid=95452 
comm="freshclam" capability=2  capname="dac_read_search"
   May 23 08:16:39 audit[95452]: AVC apparmor="DENIED" operation="capable" 
profile="/usr/bin/freshclam" pid=95452 comm="freshclam" capability=2  
capname="dac_read_search"
   May 23 08:16:39 freshclam[95358]: Update process terminated
   May 23 08:16:39 sudo[95446]: pam_unix(sudo:session): session closed for user 
root
   May 23 08:16:39 systemd[1]: Stopping ClamAV virus database updater...
   May 23 08:16:39 systemd[1]: clamav-freshclam.service: Succeeded.
   May 23 08:16:39 freshclam[95452]: ClamAV update process started at Sun May 
23 08:16:39 2021
   May 23 08:16:39 freshclam[95452]: daily.cld database is up-to-date (version: 
26178, sigs: 3982081, f-level: 63, builder: raynman)
   May 23 08:16:39 freshclam[95452]: main.cld database is up-to-date (version: 
59, sigs: 4564902, f-level: 60, builder: sigmgr)
   May 23 08:16:39 freshclam[95452]: bytecode.cld database is up-to-date 
(version: 333, sigs: 92, f-level: 63, builder: awillia2)
   May 23 08:16:39 systemd[1]: Stopped ClamAV virus database updater.
   May 23 08:16:39 systemd[1]: Started ClamAV virus database updater.

-- Package-specific info:
--- configuration ---
Checking configuration files in /etc/clamav

Config file: clamd.conf
---
AlertExceedsMax disabled
PreludeEnable disabled
PreludeAnalyzerName = "ClamAV"
LogFile = "/var/log/clamav/clamav.log"
LogFileUnlock disabled
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogClean disabled
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
LogRotate = "yes"
ExtendedDetectionInfo = "yes"
PidFile disabled
TemporaryDirectory = "/tmp"
DatabaseDirectory = "/var/lib/clamav"
OfficialDatabaseOnly disabled
LocalSocket = "/var/run/clamav/clamd.ctl"
LocalSocketGroup = "clamav"
LocalSocketMode = "666"
FixStaleSocket = "yes"
TCPSocket disabled
TCPAddr disabled
MaxConnectionQueueLength = "15"
StreamMaxLength = "10485760"
StreamMinPort = "1024"
StreamMaxPort = "2048"
MaxThreads = "12"
ReadTimeout = "180"
CommandReadTimeout = "5"
SendBufTimeout = "200"
MaxQueue = "100"
IdleTimeout = "30"
ExcludePath disabled
MaxDirectoryRecursion = "15"
FollowDirectorySymlinks disabled
FollowFileSymlinks disabled
CrossFilesystems = "yes"
SelfCheck = "3600"
ConcurrentDatabaseReload = "yes"
DisableCache disabled
VirusEvent disabled
ExitOnOOM disabled
AllowAllMatchScan = "yes"
Foreground disabled
Debug disabled
LeaveTemporaryFiles disabled
User = "clamav"
Bytecode = "yes"
BytecodeSecurity = "TrustSigned"
BytecodeTimeout = "6"
BytecodeUnsigned disabled
BytecodeMode = "Auto"
DetectPUA disabled
ExcludePUA disabled
IncludePUA disabled
ScanPE = "yes"
ScanELF = "yes"
ScanMail = "yes"
ScanPartialMessages disabled
PhishingSignatures = "yes"
PhishingScanURLs = "yes"
HeuristicAlerts = "yes"
HeuristicScanPrecedence disabled
StructuredDataDetection disabled
StructuredMinCreditCardCount = "3"
StructuredMinSSNCount = "3"
StructuredSSNFormatNormal = "yes"
StructuredSSNFormatStripped disabled
ScanHTML = "yes"
ScanOLE2 = "yes"
AlertBrokenExecutables disabled
AlertBrokenMedia disabled
AlertEncrypted disabled
StructuredCCOnly disabled
AlertEncryptedArchive disabled
AlertEncryptedDoc disabled
AlertOLE2Macros disabled
AlertPhishingSSLMismatch disabled
AlertPhishingCloak disabled
AlertPartitionIntersection disabled
ScanPDF = "yes"
ScanSWF = "yes"
ScanXMLDOCS = "yes"
ScanHWP3 = "yes"
ScanArchive = "yes"
ForceToDisk disabled
MaxScanTime = "12"
MaxScanSize = "104857600"
MaxFileSize = "26214400"
MaxRecursion = "16"
MaxFiles = "1"

Bug#988217: u-boot: bootefi causes boot failure with boot.scr

[Cyril Brulebois]

Vagrant Cascadian  (2021-05-22):
> This could impact debian-installer as it build-depends on it for
> armhf/arm64, though I think the chance of regressions are minimal. Is
> there a release candidate planned in the immediate future?

Exact plans are still sketchy, but I expect one in the next week or so
(we need linux to migrate first, and I'm trying to finalize the cdebconf
workaround-/hack-athon).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#988174: (/usr/bin/qemu-aarch64-static: Segfaults sometimes on python3-minimal on arm64)

[Diederik de Haas]

On zaterdag 22 mei 2021 20:58:12 CEST Diederik de Haas wrote:
> On zaterdag 22 mei 2021 17:14:34 CEST Christopher Obbard wrote:
> > Looks like a new version of qemu is in experimental - which has some
> > changes to linux-user/mmap.c
> > Perhaps it would be a good idea to see if the bug is still present in 6.0?
> Thanks for that excellent suggestion; I upgraded immediately.
> First run was successful, but I'll run (some) more and report back whether
> the issue is indeed solved with 6.0.

I've now run it 8 times and it succeeded all 8 times.
Another person on #debian-raspberrypi did 3 runs and those succeeded as well.

So afaic this is a strong indication that the problem is indeed resolved with 
version 6.0. I'll do some more runs later in the week and if those (all) 
succeeded as well, I'll close the bug.

I think it's worth investigating by the maintainers whether a targeted fix can 
be backported to Bullseye as I think it's  likely more people will run into 
this problem once Bullseye becomes Stable.

Thank you all for participating :)

Diederik

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

Bug#989001: memtest86+: Fails to run in Grub graphical(?) mode?

[Junichi Uekawa]

Package: memtest86+
Version: 5.01-3.1
Severity: normal

Dear Maintainer,

I think I default installed Debian bullseye and Grub is configured to
use graphical framebuffer and render text. When invoked from there
memtest86+ doesn't seem to update the screen at all (presumably trying
to write to text buffer?).




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

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

Versions of packages memtest86+ depends on:
ii  debconf [debconf-2.0]  1.5.75

memtest86+ recommends no packages.

Versions of packages memtest86+ suggests:
pn  grub-pc | grub-legacy  
pn  hwtools
pn  kernel-patch-badram
pn  memtest86  
pn  memtester  
pn  mtools 

-- debconf information:
  shared/memtest86-run-lilo: false

Bug#988998: lava: autopkgtest needs update for new version of pyyaml

[Stefano Rivera]

Hi Paul (2021.05.22_15:22:35_-0400)
> Currently this regression is blocking the migration of pyyaml to testing
> [1]. Of course, pyyaml shouldn't just break your autopkgtest (or even
> worse, your package), but it seems to me that the change in pyyaml was
> intended and your package needs to update to the new situation.

Yeah, intended. The unsafe load functions in pyyaml had some obvious
remote code execution paths blocked, by disabling loading some types of
Python object.

That's a backwards-incompatible change, but made for security reasons.

Back-story in: 
https://github.com/yaml/pyyaml/wiki/PyYAML-yaml.load(input)-Deprecation

The Ubuntu patch is the minimal solution to the problem. Replacing
.load() with .unsafe_load() or Loader=UnsafeLoader.

Ideally, anything that handles untrusted input (not sure if that's an
issue in Lava) should use the safe load functions. But those can't load
all types of object.

SR

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

Bug#856273: vim: Presence/absence of a personal vimrc -> big behavior changes

[Ross Boylan]

Package: vim
Version: 2:8.1.0875-5
Followup-For: Bug #856273

Since I just spent several hours tracking down a vimrc-related
problem, I thought I'd add a couple of comments.

Short Version:

It would be good if there were a README.Debian, and it would be good
if it noted that a personal vimrc will block loading standard defaults
that, among other things, enable syntax highlighting and filetype
detection, and that to retain this one can put
source $VIMRUNTINE/defaults.vim
at the start of the personal vimrc.

Longer Version:

First, it would be helpful if there were a README.Debian as well as a
NEWS.Debian file.

Second, I tried adding a small customization and discovered it
completely disabled a plugin I had installed to
~/.vim/pack/thirdparty/start.  Even the most trivial vimrc did so.  I
found this extremely surprising and wonder if it must be so.  If it
must, it would be helpful to document it more prominently.

When I had a vimrc, $VIMRUNTIME/defaults.vim was never sourced and
syntax and filetype detection were never enabled.  I believe, based on
vim -V's output, that the activation of these features caused my
plugin to be scanned properly.

I even tried adding source $VIM/vimrc early on to my personal vimrc,
which didn't help.  Adding source $VIMRUNTINE/defaults.vim to my vimrc
did fix the problem.

It is true that NEWS.Debian is pretty explicit that any personal vimrc
prevents loading of the defaults, though the implication that plugins
and syntax highlighting would stop working was not. And you comment
that the blocked loading of the defaults is upstream behavior.

:he vimrc does in fact describe this behavior in the Initialization
section (4), item 3 c; 3 c V even notes that the defaults.vim file
sets syntax on and filetype on, so that information is somewhere :)
But it then goes on in item 4 to say that plugin scripts are loaded,
which sounds unconditional.  BTW, I didn't fully get this because 3
describes the loading of personal vimrc in its introduction and then 3
b says system configuration is loaded unconditionally.  I.e., I kind
of stopped reading there.  The problem is that 3 b's $VIM/vimrc is not
the same as 3 c V's $VIMRUNTIME/defaults.vim.

The origin of my difficulty was the belief that my vimrc was just
adding tweaks to what I had without it, when it is actually replacing
all the configuration that is setup in defaults.vim.

BTW, the plugin in question was vimoutliner.  I don't know if a vim
plugin packaged for Debian and installed with Debian vim's manager
would behave the same way.  vimoutliner used to be in Debian, but it
was unmaintained and got kicked out.  I've since worked with upstream
on the installation process and documentation of same.

-- Package-specific info:

--- real paths of main Vim binaries ---
/usr/bin/vi is /usr/bin/vim.basic
/usr/bin/vim is /usr/bin/vim.basic

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

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

Versions of packages vim depends on:
ii  libacl1  2.2.53-4
ii  libc62.28-10
ii  libgpm2  1.20.7-5
ii  libselinux1  2.8-1+b1
ii  libtinfo66.1+20181013-2+deb10u2
ii  vim-common   2:8.1.0875-5
ii  vim-runtime  2:8.1.0875-5

vim recommends no packages.

Versions of packages vim suggests:
pn  ctags
ii  vim-doc  2:8.1.0875-5
pn  vim-scripts  

-- no debconf information

Bug#988217: u-boot: bootefi causes boot failure with boot.scr

[Vagrant Cascadian]

On 2021-05-16, Vagrant Cascadian wrote:
> On 2021-05-07, Vagrant Cascadian wrote:
>> On 2021-04-16, Bastian Germann wrote:
>>> On a Lamobo R1, I can verify 2021.01 versions not to boot with a
>>> default environment. However, 2020.10+dfsg-2 boots. Even though the
>>> original issue has the same outcome, I guess it is caused by something
>>> else.
>>
>> Different enough to warrant it's own bug, cloning...
>>
>>
>>> I figured out my problem is caused by
>>> https://github.com/u-boot/u-boot/commit/f3866909e35074ea6f50226d40487a180de1132f.
>>>  The
>>> boot_efi_bootmgr will run and read a bad dtb, which makes a boot.scr
>>> boot fail.
>>
>> This would definitely be good to fix in bullseye, but this is quite late
>> in the release cycle.
>
> After recently upgrading several more systems that turned out to be
> affected by this, I'm bumping the severity of this bug...
>
>
>> Will need to test failure and success cases with and without EFI as well
>> as boot.scr and extlinux.conf to make sure this doesn't cause
>> regressions in other boot paths...
>
> This still needs some work!

I know it is terribly late in the release cycle, but this breaks default
boot on several systems I've tested, and likely to affect others in
reasonable configurations, so I intend to upload a fix with the upstream
the patch very soon.

This could impact debian-installer as it build-depends on it for
armhf/arm64, though I think the chance of regressions are minimal. Is
there a release candidate planned in the immediate future?

I've tested that the fix works for Lamobo-R1, though I haven't yet
tested if it breaks u-boot as an EFI implementation (which seems like
the only significant regression risk). Will test that before uploading.

The upstream patch (which is in debian/patches on the sid branch):


From 82d01f04facef1276cede067efd02d2a731ffe83 Mon Sep 17 00:00:00 2001
From: Heinrich Schuchardt 
Date: Sun, 24 Jan 2021 14:34:12 +
Subject: [PATCH] efi_loader: switch to non-secure mode later
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Some ARMv7 boards using PSCI require to be in secure-mode when booted via
'bootz' or 'bootm'. During distro-boot 'bootefi bootmgr' is called to check
if booting via UEFI is possible.

With the change we change the switch from secure mode to non-secure mode is
moved from the UEFI subsystem setup to just before calling StartImage().

Cc: Jernej Škrabec 
Reported by: Andre Przywara 
Signed-off-by: Heinrich Schuchardt 
---
 cmd/bootefi.c  | 4 
 lib/efi_loader/efi_setup.c | 4 
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index c8eb5c32b0..81dd8e0284 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -8,6 +8,7 @@
 #define LOG_CATEGORY LOGC_EFI
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -338,6 +339,9 @@ static efi_status_t do_bootefi_exec(efi_handle_t handle, 
void *load_options)
efi_uintn_t exit_data_size = 0;
u16 *exit_data = NULL;
 
+   /* On ARM switch from EL3 or secure mode to EL2 or non-secure mode */
+   switch_to_non_secure_mode();
+
/* Call our payload! */
ret = EFI_CALL(efi_start_image(handle, _data_size, _data));
if (ret != EFI_SUCCESS) {
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index 5800cbf6d4..b1c5125032 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -6,7 +6,6 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 
@@ -188,9 +187,6 @@ efi_status_t efi_init_obj_list(void)
/* Allow unaligned memory access */
allow_unaligned();
 
-   /* On ARM switch from EL3 or secure mode to EL2 or non-secure mode */
-   switch_to_non_secure_mode();
-
/* Initialize root node */
ret = efi_root_node_register();
if (ret != EFI_SUCCESS)
-- 
2.30.2


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#947064: Achat de machines pour l'exportation

[occasion]

Bonjour,



Je recherche régulièrement des véhicules d'occasion (Tracteurs, citernes,
grues, malaxeurs, benne, engin de constructions,TP...)


pour l'export.


Nous achetons même P.L accidenté ou HS.


En avez-vous en ce moment


Je vous prie de bien vouloir me faire parvenir vos offres.


Je reste à votre entière disposition pour toute proposition de votre part.



Tel./ Whatsaap: 0049163 694 6524




Cordialement,




Camion Export Deutschland


Auf der Held 13A



DE-54634 Bitburg-Matzen


Tax.Nr.: DE 236254859

 

Bug#987264: git-el: fails to install with xemacs21

[Fabrice Bauzac-Stehly]

For what it's worth, here's a patch for git-el to have the directory
created, after Agustin's suggestion.

diff -Naur git-2.30.2/debian/git-el.dirs git_2.30.2-1.1/debian/git-el.dirs
--- git-2.30.2/debian/git-el.dirs   1970-01-01 01:00:00.0 +0100
+++ git_2.30.2-1.1/debian/git-el.dirs   2021-05-22 23:52:16.409330369 +0200
@@ -0,0 +1 @@
+usr/share/emacs/site-lisp

Bug#975911: mariadb-client: appears to ignore ~/.editrc keybind settings

[Trevor Cordes]

Upstream, Jess and I did work out a fix and I made a "real" patch that
should fix the problem without a security hole.

http://thrysoee.dk/editline/

As projects pull from this upstream (as Fedora does, not sure about
Deb) they will get this fix.  If you don't want to wait, download the
source and compile/install or use your package manager build system
with this new source.  Restart your mysql client and the bug should be
gone: libedit should read your editrc, and from there you can customize
^W to do the "sane" thing.

So now mariadb should allow sane ^W settings now matter how it is
compiled:
- with readline: always worked
- with libedit that comes with maria-db: always worked
- with your system libedit: now works once you add settings to .editrc
  and use this latest libedit verion (libedit-20210522-3.1 or
  newer)

And hopefully that will be the last we ever see of this bug, which has
cropped up every few years since 2009, 2013, 2019, 2021?  :-)

Cheers.

Bug#988089: [debian-mysql] Bug#988089: Bug#988089: mariadb-server: MariaDB uninstalled on dist-upgrade Debian 10 -> 11

[Otto Kekäläinen]

Hello!

On Sun, May 16, 2021 at 4:18 PM Otto Kekäläinen  wrote:
>
>
>> > But as said, the bug #988089 can only be fixed by a change in galera-4
>> > debian/control. Changing the mariadb-10.5 debian/control to
>> > recommends:galera-4 is a separate change.
>> Ok but I have no idea how this should be handled then.
>
>
> I outlined the exact galera-4 debugging steps in my email on May 13th. The 
> solution can be found and also tested/validated easily with those steps.

I had some spare time today and followed those steps, resulting in
this MR: https://salsa.debian.org/mariadb-team/galera-4/-/merge_requests/5

Would somebody like to review/test it?

Bug#988963: upgrade-reports: upgrade process requires a second "apt full-upgrade"

[Vagrant Cascadian]

On 2021-05-22, Paul Gevers wrote:
> On 22-05-2021 21:42, Bill Allombert wrote:
>> Do you have a list of packages whose upgrade triggers this issue ?
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=988003;filename=Samantha_upgrade_logs.tar.gz;msg=5
> has a dpkg-get-selection file with the list of installed packages.
>
> And the reporter of that bug was very responsive, so we can ask further.
> Also Vagrant should be able to give feedback (in CC).

So far I've seen guile-2.2-libs on almost all of of the ~25 systems I've
upgraded. I noticed zile also on one of the recent ones. I have vague
memories of a small number of other packages, but unfortunately
neglected to record them.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#989000: distutils: missing CFLAGS/LDFLAGS from environment

[Samuel Thibault]

Samuel Thibault, le sam. 22 mai 2021 23:10:16 +0200, a ecrit:
> That can be seen in the brltty build log (as of current git version that
> enables verbose log):

That is

git clone https://salsa.debian.org/a11y-team/brltty.git 
cd brltty
git checkout cc47bc6d950c0bca6c061be6f4750661d17e977e

(In a later revision I added passing over CFLAGS/LDFLAGS by hand, but we
don't want to have to patch each and every debian python package like
this)

Samuel

Bug#989000: distutils: missing CFLAGS/LDFLAGS from environment

[Samuel Thibault]

Package: python3.9
Version: 3.9.2-1
Severity: normal
Affects: brltty

Hello,

The brltty package build is currently unreproducible because the build
path leaks into its Python bindings because distutils does not take
CFLAGS (and not LDFLAGS either) from the environment.

That can be seen in the brltty build log (as of current git version that
enables verbose log):

/tmp/brltty-6.3+dfsg$ dpkg-buildpackage
[...]
set -- --verbose build --build-temp .; \
[ "linux-gnu" != "mingw32" ] || set -- "${@}" --compiler mingw32; \
"/usr/bin/python3.9" ./setup.py "${@}"
running build
running build_ext
building 'brlapi' extension
x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g 
-fwrapv -O2 -Wall -g 
-ffile-prefix-map=/build/python3.9-RNBry6/python3.9-3.9.2=. 
-fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g 
-ffile-prefix-map=/build/python3.9-RNBry6/python3.9-3.9.2=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fPIC -I. -I../../../Bindings/Python -I../../Programs 
-I../../../Programs -I../../ -I../../../ -I/usr/include/python3.9 -c 
../../../Bindings/Python/bindings.c -o ./../../../Bindings/Python/bindings.o 
-Wno-parentheses -Wno-unused -fno-strict-aliasing -U_POSIX_C_SOURCE 
-U_XOPEN_SOURCE
x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g 
-fwrapv -O2 -Wall -g 
-ffile-prefix-map=/build/python3.9-RNBry6/python3.9-3.9.2=. 
-fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g 
-ffile-prefix-map=/build/python3.9-RNBry6/python3.9-3.9.2=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fPIC -I. -I../../../Bindings/Python -I../../Programs 
-I../../../Programs -I../../ -I../../../ -I/usr/include/python3.9 -c 
brlapi.auto.c -o ./brlapi.auto.o -Wno-parentheses -Wno-unused 
-fno-strict-aliasing -U_POSIX_C_SOURCE -U_XOPEN_SOURCE
creating build
creating build/lib.linux-x86_64-3.9
x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions 
-Wl,-z,relro -g -fwrapv -O2 -Wl,-z,relro -g -fwrapv -O2 -g 
-ffile-prefix-map=/build/python3.9-RNBry6/python3.9-3.9.2=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 ./../../../Bindings/Python/bindings.o ./brlapi.auto.o 
-L./../../Programs -lbrlapi -lpthread -o 
build/lib.linux-x86_64-3.9/brlapi.cpython-39-x86_64-linux-gnu.so

I.e. distutils passes to gcc the flags it got during python3.9 build
(which included -ffile-prefix-map=/build/python3.9-RNBry6/python3.9-3.9.2=.)
but it does not include the flags it got from the environment (which
includes -ffile-prefix-map=/tmp/brltty-6.3+dfsg=.), and as a result the
generated .o and .so files include the build path /tmp/brltty-6.3+dfsg.


blhc also notices that LDFLAGS is not getting included:

https://salsa.debian.org/a11y-team/brltty/-/jobs/1660079

2438:LDFLAGS missing (-Wl,-z,now): x86_64-linux-gnu-gcc -pthread -shared 
-Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro -g -fwrapv -O2 -Wl,-z,relro -g 
-fwrapv -O2 -g -ffile-prefix-map=/build/python3.9-RNBry6/python3.9-3.9.2=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 ./../../../Bindings/Python/bindings.o ./brlapi.auto.o 
-L./../../Programs -lbrlapi -lpthread -o 
build/lib.linux-x86_64-3.9/brlapi.cpython-39-x86_64-linux-gnu.so

Samuel

-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), 
(1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages python3.9 depends on:
ii  libpython3.9-stdlib  3.9.2-1
ii  media-types  4.0.0
ii  mime-support 3.66
ii  python3.9-minimal3.9.2-1

python3.9 recommends no packages.

Versions of packages python3.9 suggests:
ii  binutils2.35.2-2
pn  python3.9-doc   
ii  python3.9-venv  3.9.2-1

-- no debconf information

-- 
Samuel
 Profitant de cette occasion, vous serait-il possible de rebooter 
 aussi Modérator et son petit copain qui gère les ressources de 
 download ?
 -+- OB in NPC : Apprendre à flasher son personnel -+-

Bug#968257: no finding with stretch and buster; recommend closing bug: UpgradingToBuster: apt doesn't report how much space

[Federico Grau]

I updated my review of bug #968257, this time trying an upgrade from a fresh
minimal install of Debian 9 'stretch' to Debian 10 'buster'.

With the current Debian stretch (9.13 circa 2021-Q2), I found `apt' and
`apt-get' produced equivalent space usage estimates, and this bug report is
incorrect or no longer applicable.  Recommend to close #968257.

regards,
donfede

#
# console review of a Debian 9 to Debian 10 upgrade, with valid apt space 
estimates

root@saltdev09:~# apt -o APT::Get::Trivial-Only=true full-upgrade
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer
required:
  liblvm2app2.2 liblvm2cmd2.02 tcpd
Use 'apt autoremove' to remove them.
The following NEW packages will be installed:
  apparmor bzip2 ca-certificates dirmngr e2fsprogs-l10n exim4-base
...
  wamerican wget whiptail xauth xkb-data xxd zlib1g
217 upgraded, 90 newly installed, 0 to remove and 0 not upgraded.
Need to get 155 MB of archives.
After this operation, 441 MB of additional disk space will be used.
E: Trivial Only specified but this is not a trivial operation.
root@saltdev09:~# 
root@saltdev09:~# 
root@saltdev09:~# apt-get -o APT::Get::Trivial-Only=true full-upgrade
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer
required:
  liblvm2app2.2 liblvm2cmd2.02 tcpd
Use 'apt autoremove' to remove them.
The following NEW packages will be installed:
  apparmor bzip2 ca-certificates dirmngr e2fsprogs-l10n exim4-base
...
  wamerican wget whiptail xauth xkb-data xxd zlib1g
217 upgraded, 90 newly installed, 0 to remove and 0 not upgraded.
Need to get 155 MB of archives.
After this operation, 441 MB of additional disk space will be used.
E: Trivial Only specified but this is not a trivial operation.
root@saltdev09:~# 
root@saltdev09:~# 
root@saltdev09:~# cat /etc/debian_version 
9.13
root@saltdev09:~# hostnamectl
   Static hostname: saltdev09
 Icon name: computer-vm
   Chassis: vm
Machine ID: 8048838ca13549cf93e5bff5567fcba2
   Boot ID: a757f492a78840a4928d20b48b8d870d
Virtualization: qemu
  Operating System: Debian GNU/Linux 9 (stretch)
Kernel: Linux 4.9.0-15-amd64
  Architecture: x86-64
root@saltdev09:~# which apt
/usr/bin/apt
root@saltdev09:~# which apt-get
/usr/bin/apt-get
root@saltdev09:~# dpkg -S /usr/bin/apt
apt: /usr/bin/apt
root@saltdev09:~# dpkg -S /usr/bin/apt-get
apt: /usr/bin/apt-get
root@saltdev09:~# dpkg -l apt
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ NameVersionArchitecture
Description
+++-==---=
ii  apt1.4.11   amd64commandline package manager
root@saltdev09:~# 



signature.asc
Description: PGP signature

Bug#988963: upgrade-reports: upgrade process requires a second "apt full-upgrade"

[Paul Gevers]

Hi Bill,

On 22-05-2021 21:42, Bill Allombert wrote:
> Do you have a list of packages whose upgrade triggers this issue ?

https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=988003;filename=Samantha_upgrade_logs.tar.gz;msg=5
has a dpkg-get-selection file with the list of installed packages.

And the reporter of that bug was very responsive, so we can ask further.
Also Vagrant should be able to give feedback (in CC).

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#988999: cython3: Avoid including absolute paths

[Samuel Thibault]

Samuel Thibault, le sam. 22 mai 2021 22:38:17 +0200, a ecrit:
> But in the generated brlapi.auto.c file we can read:
> 
> static const char __pyx_k_tmp_brltty_6_3_dfsg_Bindings_Py[] = 
> "/tmp/brltty-6.3+dfsg/Bindings/Python/brlapi.pyx";
> 
> i.e. the relative ../../../Bindings/Python/brlapi.pyx got turned into
> absolute path /tmp/brltty-6.3+dfsg/Bindings/Python/brlapi.pyx, which is
> undesirable for reproducible builds.

Also not the variable name __pyx_k_tmp_brltty_6_3_dfsg_Bindings_Py, but
also

static PyObject *__pyx_kp_s_tmp_brltty_6_3_dfsg_Bindings_Py;
  {&__pyx_kp_s_tmp_brltty_6_3_dfsg_Bindings_Py, 
__pyx_k_tmp_brltty_6_3_dfsg_Bindings_Py, 
sizeof(__pyx_k_tmp_brltty_6_3_dfsg_Bindings_Py), 0, 0, 1, 0},
  etc.

which end up in the debugging symbols informations.

Samuel

Bug#988999: cython3: Avoid including absolute paths

[Samuel Thibault]

Package: cython3
Version: 0.29.21-3+b1
Severity: normal
Affects: brltty

Hello,

The brltty package build is currently non-reproducible only because of
the python bindings build. Notably, we can see in the build log:

"/usr/bin/cython3" -3 -I. -o brlapi.auto.c ../../../Bindings/Python/brlapi.pyx

But in the generated brlapi.auto.c file we can read:

static const char __pyx_k_tmp_brltty_6_3_dfsg_Bindings_Py[] = 
"/tmp/brltty-6.3+dfsg/Bindings/Python/brlapi.pyx";

i.e. the relative ../../../Bindings/Python/brlapi.pyx got turned into
absolute path /tmp/brltty-6.3+dfsg/Bindings/Python/brlapi.pyx, which is
undesirable for reproducible builds.

Samuel

-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), 
(1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages cython3 depends on:
ii  libc62.31-12
ii  python3  3.9.2-3

Versions of packages cython3 recommends:
ii  gcc  4:10.2.1-1
ii  python3-dev  3.9.2-3

Versions of packages cython3 suggests:
pn  cython-doc  

-- no debconf information

-- 
Samuel
 can you guys see what I type?
 no, raize
 How do I set it up so you can see it?

Bug#988540: im-config: breaks the keyboard configuration

[Vincent Lefevre]

On 2021-05-22 13:46:50 +0900, Osamu Aoki wrote:
> At least, zoom should have used RECOMMENDS and user should have avoided
> to install ibus.

I would even say "Suggests:", so that ibus isn't installed by default.

It seems that one cannot report a bug to Zoom without a Zoom account.
So I've just tweeted them about the issue:
  https://twitter.com/vinc17/status/1396199397428432902

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

Bug#986441: mirror listing update for mmc.geofisica.unam.mx

[Peter Palfrader]

It seems I'm unable to connect to
http://mmc.geofisica.unam.mx/debian/project/trace/

is that supposed to be up?

Cheers,

On Tue, 06 Apr 2021, Antonio Carrillo Ledesma wrote:

> Package: mirrors
> Severity: minor
> User: mirr...@packages.debian.org
> Usertags: mirror-list
> 
> Submission-Type: update
> Site: mmc.geofisica.unam.mx
> Type: leaf
> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 
> kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
> Archive-http: /debian/
> Archive-rsync: debian/
> Maintainer: Antonio Carrillo Ledesma 
> Country: MX Mexico
> Location: Instituto de Geofisica, UNAM
> Sponsor: Grupo de Geofísica Computacional  http://mmc.geofisica.unam.mx/
> 
> 
> 
> 
> Trace Url: http://mmc.geofisica.unam.mx/debian/project/trace/
> Trace Url: 
> http://mmc.geofisica.unam.mx/debian/project/trace/ftp-master.debian.org
> Trace Url: 
> http://mmc.geofisica.unam.mx/debian/project/trace/mmc.geofisica.unam.mx
> 

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#988988: RFS: logrotate/3.18.1-1 -- Log rotation utility

[Christian Göttsche]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "logrotate":

 * Package name: logrotate
   Version : 3.18.1-1
   Upstream Author : https://github.com/logrotate/logrotate/issues
 * URL : https://github.com/logrotate/logrotate
 * License : GPL-3+, BSD-3-Clause, GPL-2
 * Vcs : https://salsa.debian.org/debian/logrotate
   Section : admin

It builds those binary packages:

  logrotate - Log rotation utility

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

  https://mentors.debian.net/package/logrotate/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/l/logrotate/logrotate_3.18.1-1.dsc

Changes since the last upload:

 logrotate (3.18.1-1) experimental; urgency=medium
 .
   * New upstream version 3.18.1 (Closes: #987242)
 .
   * d/patches: drop upstream applied ones

Regards,
  Christian Göttsche

Bug#546671: Seeing similar with "einstein"

[Simon Waters]

The Einstein puzzle package uses SDL 1.2

If I run it in fullscreen on my desktop machine, the display is frequently 
(but not always) messed up on exit.

It can be reset with either KDE screen controls or xrandr

The onboard graphics has two outputs (DVI and VGA), the situation seems 
improved/fixed if I disable the second with this command.

$ xrandr --output VGA-0 --off

Obviously this is a works for me whilst I only have one monitor plugged in.

$ xrandr 
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384
DVI-0 connected primary 1920x1080+0+0 (normal left inverted right x axis y 
axis) 521mm x 293mm
   1920x1080 60.00*+
   1680x1050 59.88  
   1280x1024 75.0260.02  
   1440x900  74.9859.90  
   1280x960  60.00  
   1152x864  75.00  
   1024x768  75.0370.0760.00  
   832x624   74.55  
   800x600   72.1975.0060.3256.25  
   640x480   75.0072.8166.6759.94  
   720x400   70.08  
VGA-0 disconnected (normal left inverted right x axis y axis)

I got similar behaviour from trivially small test program. So confident this is 
libsdl1.2. Couldn't find a small code change that fixed Einstein but I'm 
learning SDL as I go, although it might be possible to scale in a resizeable 
window, since I doubt many people are running 800x600 only.

Will try SDL_VIDEO_FULLSCREEN_HEAD=0 environment variable when it recurs.

Bug#988972: Installed with --no-install-recommends

[Felicia]

I installed with the --no-install-recommends option

Bug#986902: mirror listing update for mirror.pit.teraswitch.com

[Peter Palfrader]

Thanks!

I've update the arch list, url, and maintainer.

I am not quite sure where cd mirrors are coordinated these days, though.
I'll ping people.

Cheers,

On Tue, 13 Apr 2021, Justin Goetz wrote:

> Package: mirrors
> Severity: minor
> User: mirr...@packages.debian.org
> Usertags: mirror-list
> 
> Submission-Type: update
> Site: mirror.pit.teraswitch.com
> Type: leaf
> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 
> kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
> Archive-http: /debian/
> Archive-rsync: debian/
> Maintainer: Justin Goetz 
> Country: US United States
> Location: Pittsburgh, Pennsylvania
> Sponsor: TeraSwitch Inc. https://teraswitch.com/
> Comment: Hello! 
>  
>  We have maintained a debian package repository mirror for a couple years 
> now, and we recently received a hardware upgrade on our mirror infrastructure 
> that allows us to now also host a debian-cd mirror.
>  
>  Please find our updated URLs for the debian-cd repo below:
>  
>  (http/https)://mirror.pit.teraswitch.com/debian-cd/
>  rsync://mirror.pit.teraswitch.com/debian-cd/
>  
>  Please let me know if any additional information is required. Thanks! 
>  
> 
> 
> 
> 
> Trace Url: http://mirror.pit.teraswitch.com/debian/project/trace/
> Trace Url: 
> http://mirror.pit.teraswitch.com/debian/project/trace/ftp-master.debian.org
> Trace Url: 
> http://mirror.pit.teraswitch.com/debian/project/trace/mirror.pit.teraswitch.com
> 

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#988633: mirror submission for mirror.djvg.sg

[Peter Palfrader]

Thanks, added!

On Mon, 17 May 2021, Daan van Gorkum wrote:

> Package: mirrors
> Severity: wishlist
> User: mirr...@packages.debian.org
> Usertags: mirror-submission
> 
> Submission-Type: new
> Site: mirror.djvg.sg
> Type: leaf
> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 
> kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
> Archive-http: /debian/
> Maintainer: Daan van Gorkum 
> Country: SG Singapore
> Location: Singapore
> 
> 
> 
> 
> Trace Url: http://mirror.djvg.sg/debian/project/trace/
> Trace Url: http://mirror.djvg.sg/debian/project/trace/ftp-master.debian.org
> Trace Url: http://mirror.djvg.sg/debian/project/trace/mirror.djvg.sg
> 

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#988761: mirror submission for mirror.bjtu.edu.cn

[Peter Palfrader]

Thanks, added

On Wed, 19 May 2021, Chestnut wrote:

> Package: mirrors
> Severity: wishlist
> User: mirr...@packages.debian.org
> Usertags: mirror-submission
> 
> Submission-Type: new
> Site: mirror.bjtu.edu.cn
> Type: leaf
> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 
> kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
> Archive-http: /debian/
> Maintainer: Chestnut 
> Country: CN China
> Location: Beijing
> Sponsor: Beijing Jiaotong University https://bjtu.edu.cn/
> 
> 
> 
> 
> Trace Url: http://mirror.bjtu.edu.cn/debian/project/trace/
> Trace Url: 
> http://mirror.bjtu.edu.cn/debian/project/trace/ftp-master.debian.org
> Trace Url: http://mirror.bjtu.edu.cn/debian/project/trace/mirror.bjtu.edu.cn
> 

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#988568: mirror submission for debian.qontinuum.space

[Peter Palfrader]

Thanks, added!

Qontinuum schrieb am Saturday, dem 15. May 2021:

> Package: mirrors
> Severity: wishlist
> User: mirr...@packages.debian.org
> Usertags: mirror-submission
> 
> Submission-Type: new
> Site: debian.qontinuum.space
> Type: leaf
> Archive-architecture: amd64 arm64 armel armhf i386 powerpc ppc64el
> Archive-http: /debian/
> Archive-rsync: debian/
> Maintainer: Qontinuum 
> Country: MC Monaco
> Comment: It can also be considered in france
> 
> 
> 
> 
> Trace Url: http://debian.qontinuum.space/debian/project/trace/
> Trace Url: 
> http://debian.qontinuum.space/debian/project/trace/ftp-master.debian.org
> Trace Url: 
> http://debian.qontinuum.space/debian/project/trace/debian.qontinuum.space
> 

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#988633: mirror submission for mirror.djvg.sg

[Peter Palfrader]

On Sat, 22 May 2021, Peter Palfrader wrote:

> Thanks, added!

Note:

o we recommend mirrors not sync directly from service aliases such as
  ftp..debian.org (only http is guaranteed to be available at
  ftp..d.o sites).  Maybe change your config to sync from
  the site currently backing the ftp..debian.org service you sync
  from?

Cheers,
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#988963: upgrade-reports: upgrade process requires a second "apt full-upgrade"

[Bill Allombert]

On Sat, May 22, 2021 at 09:52:11AM +0200, Paul Gevers wrote:
> Control: severity 988003 normal
> Control: merge -1 988003
> Control: affects -1 release-notes guile-2.2
> 
> Hi Apt maintainers, Rob,
> 
> On 21-05-2021 23:47, Vagrant Cascadian wrote:
> > Package: upgrade-reports
> > Severity: normal
> > X-Debbugs-Cc: vagr...@debian.org
> > 
> > On numerous systems I have upgraded recently, the process of:
> > 
> >   apt upgrade --without-new-pkgs
> >   apt full-upgrade
> > 
> > Results in at least one package (guile-2.2-libs, zile, sometimes others)
> > in an un-upgraded state.
> > 
> > Running a second "apt full-upgrade" seems to take care of the issue.
> > 
> > Maybe upgrading apt in-between "apt upgrade --without-new-pkgs" and "apt
> > full-upgrade" would resolve the issue?
> 
> This is the second report we receive about buster to bullseye upgrades
> leaving some packages in a non-upgraded state with the recommended
> upgrade procedure. Both reports involve guile-2.2-libs. Does any of you
> see why that could happen? Is this something we should worry about? Do
> we need to update the release notes update procedure (is apt upgrade and
> apt full-upgrade not enough) or is this the fault of guile-2.2-libs or
> apt? I tend to think there is probably a complex relation preventing apt
> to do the rigth thing in one go, but as the upgrade happens after a
> second run, apparently it's not really blocking

Do you have a list of packages whose upgrade triggers this issue ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#988986: cppcheck: Symbol `_ZTVN8tinyxml210XMLPrinterE' has different size in shared object, consider re-linking

[Christian Göttsche]

Package: cppcheck
Version: 2.3-1
Severity: important

Dear Maintainer,

running cppcheck prints the following message:

Symbol `_ZTVN8tinyxml210XMLPrinterE' has different size in shared
object, consider re-linking

Also reproducible with cppcheck version 2.4 from experimental.


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

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

Versions of packages cppcheck depends on:
ii  libc6 2.31-12
ii  libgcc-s1 11.1.0-2
ii  libpcre3  2:8.39-13
ii  libstdc++611.1.0-2
ii  libtinyxml2-8 8.1.0+dfsg-1
ii  libz3-4   4.8.10-1
ii  python3   3.9.2-3
ii  python3-pygments  2.7.1+dfsg-2

cppcheck recommends no packages.

Versions of packages cppcheck suggests:
pn  clang 
pn  clang-tidy
pn  cppcheck-gui  

-- no debconf information

Bug#988643: [RFS] vtk-dicom/0.8.12-3

[Andreas Beckmann]

On 22/05/2021 15.53, Étienne Mollier wrote:

I redid
the vtk-dicom/0.8.12-3 revision to simply remove the broken
symlink.

Sponsored.

The d/not-installed is probably not working as expected, IIRC it does 
not support wildcards. But you are still at compat level 12, so 
dh_missing will only warn. (but in compat 13, d/not-installed should 
support variable substitution, here ${DEB_HOST_MULTIARCH}, but then you 
should use it in the .install as well)


Andreas

Bug#987067: mirror submission for mirrors.pardisco.co

[Peter Palfrader]

Hi!

I added your mirror but I noticed it has both of its nameservers at the
same address.  Please fix.

On Fri, 16 Apr 2021, Amir Fouladvand wrote:

> Package: mirrors
> Severity: wishlist
> User: mirr...@packages.debian.org
> Usertags: mirror-submission
> 
> Submission-Type: new
> Site: mirrors.pardisco.co
> Type: leaf
> Archive-architecture: amd64 i386
> Archive-http: /debian/
> Archive-rsync: debian/
> Maintainer: Amir Fouladvand 
> Country: IR Iran, Islamic Republic of
> Location: Tehran
> Sponsor: Pardis Co. https://www.pardisco.co
> 
> 
> 
> 
> Trace Url: http://mirrors.pardisco.co/debian/project/trace/
> Trace Url: 
> http://mirrors.pardisco.co/debian/project/trace/ftp-master.debian.org
> Trace Url: http://mirrors.pardisco.co/debian/project/trace/mirrors.pardisco.co
> 

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#986133: mirror submission for mirrors.layerbridge.com

[Peter Palfrader]

Added, thanks!

On Tue, 30 Mar 2021, LayerBridge wrote:

> Package: mirrors
> Severity: wishlist
> User: mirr...@packages.debian.org
> Usertags: mirror-submission
> 
> Submission-Type: new
> Site: mirrors.layerbridge.com
> Type: leaf
> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 
> kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
> Archive-http: /debian/
> Archive-rsync: debian/
> Maintainer: LayerBridge 
> Country: RO Romania
> Location: Bucharest
> Sponsor: LayerBridge https://www.layerbridge.com
> 
> 
> 
> 
> Trace Url: http://mirrors.layerbridge.com/debian/project/trace/
> Trace Url: 
> http://mirrors.layerbridge.com/debian/project/trace/ftp-master.debian.org
> Trace Url: 
> http://mirrors.layerbridge.com/debian/project/trace/mirrors.layerbridge.com
> 

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#986088: mirror submission for uk.mirrors.clouvider.net

[Peter Palfrader]

Hi!

We added a bunch of your mirrors; I hope I got them all.  Thanks!

One thing that out checking script noticed is:

o we recommend mirrors not sync directly from service aliases such as
  ftp..debian.org (only http is guaranteed to be available at
  ftp..d.o sites).  Maybe change your config to sync from
  the site currently backing the ftp..debian.org service you sync
  from?

Cheers,

On Mon, 29 Mar 2021, Maciej Kupiec wrote:

> Package: mirrors
> Severity: wishlist
> User: mirr...@packages.debian.org
> Usertags: mirror-submission
> 
> Submission-Type: new
> Site: uk.mirrors.clouvider.net
> Type: leaf
> Archive-architecture: amd64 arm64 armel armhf i386 mips mips64el mipsel 
> ppc64el s390x
> Archive-http: /debian/
> Maintainer: Maciej Kupiec 
> Country: GB United Kingdom
> Location: London
> Sponsor: Clouvider Limited https://clouvider.co.uk
> 
> 
> 
> 
> Trace Url: http://uk.mirrors.clouvider.net/debian/project/trace/
> Trace Url: 
> http://uk.mirrors.clouvider.net/debian/project/trace/ftp-master.debian.org
> Trace Url: 
> http://uk.mirrors.clouvider.net/debian/project/trace/uk.mirrors.clouvider.net
> 

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#988998: lava: autopkgtest needs update for new version of pyyaml

[Paul Gevers]

Source: lava
Version: 2020.12-3
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, pyy...@packages.debian.org
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:pyyaml

Dear maintainer(s),

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

   passfail
pyyaml from testing5.3.1-4
lava   from testing2020.12-3
all others from testingfrom testing

I copied some of the output at the bottom of this report. It seems that
Ubuntu already has a patch since half of April [0].

Currently this regression is blocking the migration of pyyaml to testing
[1]. Of course, pyyaml shouldn't just break your autopkgtest (or even
worse, your package), but it seems to me that the change in pyyaml was
intended and your package needs to update to the new situation.

If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from pyyaml should really add
a versioned Breaks on the unfixed version of (one of your) package(s).
Note: the Breaks is nice even if the issue is only in the autopkgtest as
it helps the migration software to figure out the right versions to
combine in the tests.

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

Paul

[0] https://patches.ubuntu.com/l/lava/lava_2020.12-1ubuntu2.patch
[1] https://qa.debian.org/excuses.php?package=pyyaml

https://ci.debian.net/data/autopkgtest/testing/amd64/l/lava/12512203/log.gz
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
/usr/lib/python3/dist-packages/lava_common/compat.py:60: in yaml_load
return yaml.load(data, Loader=Loader)  # nosec
/usr/lib/python3/dist-packages/yaml/__init__.py:114: in load
return loader.get_single_data()
/usr/lib/python3/dist-packages/yaml/constructor.py:51: in get_single_data
return self.construct_document(node)
/usr/lib/python3/dist-packages/yaml/constructor.py:60: in construct_document
for dummy in generator:
/usr/lib/python3/dist-packages/yaml/constructor.py:413: in
construct_yaml_map
value = self.construct_mapping(node)
/usr/lib/python3/dist-packages/yaml/constructor.py:218: in construct_mapping
return super().construct_mapping(node, deep=deep)
/usr/lib/python3/dist-packages/yaml/constructor.py:143: in construct_mapping
value = self.construct_object(value_node, deep=deep)
/usr/lib/python3/dist-packages/yaml/constructor.py:100: in construct_object
data = constructor(self, node)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _

self = 
node =
MappingNode(tag='tag:yaml.org,2002:python/object/new:lava_dispatcher.device.PipelineDevice',
value=[(ScalarNode(tag='t...ScalarNode(tag='tag:yaml.org,2002:str',
value='target'), ScalarNode(tag='tag:yaml.org,2002:str',
value='black02'))]))])

def construct_undefined(self, node):
>   raise ConstructorError(None, None,
"could not determine a constructor for the tag %r" %
node.tag,
node.start_mark)
E   yaml.constructor.ConstructorError: could not determine a
constructor for the tag
'tag:yaml.org,2002:python/object/new:lava_dispatcher.device.PipelineDevice'
E in
"/tmp/lava-tests-pecpxeiwqT/tests/lava_scheduler_app/pipeline_refs/connection-description.yaml",
line 2, column 9

/usr/lib/python3/dist-packages/yaml/constructor.py:427: ConstructorError



OpenPGP_signature
Description: OpenPGP digital signature

Bug#988174: (/usr/bin/qemu-aarch64-static: Segfaults sometimes on python3-minimal on arm64)

[Diederik de Haas]

Hi Chris,

On zaterdag 22 mei 2021 17:14:34 CEST Christopher Obbard wrote:
> We're facing the same (similar?) problem with Debos - in some cases
> the qemu-user process seems to segfault.
> 
> Looks like a new version of qemu is in experimental - which has some
> changes to linux-user/mmap.c
> 
> Perhaps it would be a good idea to see if the bug is still present in 6.0?

Thanks for that excellent suggestion; I upgraded immediately.
First run was successful, but I'll run (some) more and report back whether
the issue is indeed solved with 6.0.

Cheers,
  Diederik

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

Bug#988997: Signature verification failed, key expired

[Mikko Viinamäki]

Package: torbrowser-launcher
Version: 0.3.2-14~bpo9+1
Severity: important

Dear Maintainer,

When installing on a stretch + backports-sloppy, torbrowser is 
downloaded, then this message is printed:


> SIGNATURE VERIFICATION FAILED
>
> Error Code: 110775B5(...)FF07E2: Key expired
>
> You might be under attack, there might be a network problem, or you
> might be missing a recently added Tor Browser verification key.

Bug#988972: Bug#988996: plasma-desktop-data: qml-module-org-kde-newstuff is listed as a dependency but is not installed

[Sami Erjomaa]

Looks like you aren't installing recommended pacvkages.

Have you disabled them in apt.conf or are you using "apt-get
--no-install-recommends"

Bug#988996: plasma-desktop-data: qml-module-org-kde-newstuff is listed as a dependency but is not installed

[Felicia Pacifica]

Package: plasma-desktop-data
Version: 4:5.20.5-4
Severity: normal

Dear Maintainer,

After a fresh install of kde-plasma-dekstop multiple components in
systemsettings are reporting "Error loading QML file"
"file:///user/share/kdpackage/kcms/kcm5_icons/contents/ui/main.qml:28
module "org.kde.newstuff" is not installed.

Even though qml-module-org-kde-newstuff is listed as a dependency of
plasma-desktop-data:

$ apt-cache showpkg qml-module-org-kde-newstuff
Reverse Depends:
  knewstuff-dialog,qml-module-org-kde-newstuff 5.78.0-4
  plasma-systemmonitor,qml-module-org-kde-newstuff 5.66.0~
  plasma-desktop-data...

qml-module-org-kde-newstuff is not actually installed and attempting to
reinstall plasma-desktop-data does not install it.



-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: i386 (i686)

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

Versions of packages plasma-desktop-data depends on:
ii  python3  3.9.2-3

Versions of packages plasma-desktop-data recommends:
ii  plasma-framework  5.78.0-3
ii  plasma-workspace  4:5.20.5-6
pn  qml-module-org-kde-activities 
ii  qml-module-org-kde-kwindowsystem  5.78.0-2
ii  qml-module-org-kde-newstuff   5.78.0-4
ii  qml-module-qtquick-dialogs5.15.2-2

plasma-desktop-data suggests no packages.

-- no debconf information

Bug#988972: Further dependencies missing

[Felicia]

Even though breeze-gtk-theme, kde-config-gtk-style, and 
kde-config-gtk-style-preview are installed as per the KDE wiki page, 
there are no titlebars for GTK apps.

Bug#988926: unblock: pyyaml/5.3.1-4

[Paul Gevers]

Control: tags -1 moreinfo

Hi Stefano,

On 21-05-2021 18:07, Stefano Rivera wrote:
>   [ Stefano Rivera ]
>   * Resolve CVE-2020-14343, more trivial RCEs in .load() and FullLoader.
> (Closes: #966233)

As mentioned on IRC (#d-devel), this seems to cause failure of the lava
autopkgtest. Did pyyaml also break lava itself?

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#975911: mariadb-client: appears to ignore ~/.editrc keybind settings

[Trevor Cordes]

On 2021-05-22 Olaf van der Spek wrote:
> Op za 22 mei 2021 om 04:27 schreef Trevor Cordes
> :
> >
> > On Thu, 26 Nov 2020 12:50:26 -0500 The Wanderer
> >  wrote:
> > Which means at one time this was fixed.  That's why this used to
> > work for us.  But something must have regressed in the source, and
> > the fix  
> 
> MariaDB 10.3 uses libreadline-gplv2
> MariaDB 10.5 uses libedit
> I think this explains the changes in behavior.

Sort of.  I think earlier MariaDB/Mysql gave the option for either
libreadline or libedit?  In any event, I experienced these symptoms a
few years ago with MariaDB, and at that time (going from memory) it was
because Fedora changed from compiling with readline to libedit.  And at
that time the solution was to make an .editrc with the bindings you
wanted.  Since I made an .editrc, and that fixed the symptoms, that
proves it was using libedit before this current fiasco.  That's my
theory, anyhow.

It's not two states we're dealing with, it's three:
1. MariaDB uses libreadline
2. MariaDB uses a working libedit that reads .editrc
3. MariaDB uses a broken libedit that doesn't read .editrc

We're in state 3 right now, not state 2.

That explains why the "fix" of using the included-with-MaraiDB libedit
solves the symptoms: because that's a non-broken libedit that reads
editrc.  But it's always better (IMHO) to use the system libraries, so
it seems prudent to get libedit fixed upstream.  For instance, if
libedit fixes a CVE, does MariaDB remember to patch or update their
in-tree version??

Upstream Jess Thrysoee has already gotten back to me with a better patch
and we're testing now.  So it seems like this won't be an issue soon
enough, once distros take on the upstream changes.

Bug#988995: unblock: openexr/2.5.4-2

[Matteo F. Vescovi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package openexr

This new revision aims to fix the CVE-2021-23169, regarding the
Heap-buffer-overflow in Imf_2_5::copyIntoFrameBuffer.

[ Reason ]
Framebuffer didn't handle images with nonzero dataWindow.min.x!=0 and
xSampling!=1, as well as in exrcheck's stream object, calling seekg()
with a bad value would still seek to a bad position, even though it
threw an exception, so a future read would segfault

[ Impact ]
The fix should handle xsampling and bad seekg() calls in exrcheck,
that in previous Debian revision weren't managed yet.

[ Tests ]
Tests were made upstream, back in December 2020.

[ Risks ]
Very low risk for regressions.

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

unblock openexr/2.5.4-2

-- 
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A

diff -Nru openexr-2.5.4/debian/changelog openexr-2.5.4/debian/changelog
--- openexr-2.5.4/debian/changelog	2021-01-21 23:24:00.0 +0100
+++ openexr-2.5.4/debian/changelog	2021-05-18 23:26:12.0 +0200
@@ -1,3 +1,14 @@
+openexr (2.5.4-2) unstable; urgency=high
+
+  * debian/patches/: patchset updated
+- CVE-2021-23169.diff added (Closes: #988240)
+| This patch aims to fix CVE-2021-23169:
+|   Heap-buffer-overflow in Imf_2_5::copyIntoFrameBuffer
+| The patch applied is a reduced version of the upstream
+| commit, given the code base has changed in the meanwhile.
+
+ -- Matteo F. Vescovi   Tue, 18 May 2021 23:26:12 +0200
+
 openexr (2.5.4-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru openexr-2.5.4/debian/patches/CVE-2021-23169.diff openexr-2.5.4/debian/patches/CVE-2021-23169.diff
--- openexr-2.5.4/debian/patches/CVE-2021-23169.diff	1970-01-01 01:00:00.0 +0100
+++ openexr-2.5.4/debian/patches/CVE-2021-23169.diff	2021-05-18 23:21:27.0 +0200
@@ -0,0 +1,19 @@
+Author: peterhillman 
+Date:   Thu Dec 3 10:53:32 2020 +1300
+Subject: Handle xsampling and bad seekg() calls in exrcheck
+Origin: https://github.com/AcademySoftwareFoundation/openexr/pull/872
+Bug-Debian: https://bugs.debian.org/988240
+
+diff --git a/OpenEXR/IlmImf/ImfDeepTiledInputFile.cpp b/OpenEXR/IlmImf/ImfDeepTiledInputFile.cpp
+index f5abe9c6..94452905 100644
+--- a/OpenEXR/IlmImf/ImfDeepTiledInputFile.cpp
 b/OpenEXR/IlmImf/ImfDeepTiledInputFile.cpp
+@@ -960,7 +960,7 @@ DeepTiledInputFile::compatibilityInitialize(OPENEXR_IMF_INTERNAL_NAMESPACE::IStr
+ void
+ DeepTiledInputFile::multiPartInitialize(InputPartData* part)
+ {
+-if (isTiled(part->header.type()) == false)
++if (part->header.type() != DEEPTILE)
+ THROW (IEX_NAMESPACE::ArgExc, "Can't build a DeepTiledInputFile from a part of type " << part->header.type());
+
+ _data->_streamData = part->mutex;
diff -Nru openexr-2.5.4/debian/patches/series openexr-2.5.4/debian/patches/series
--- openexr-2.5.4/debian/patches/series	2020-05-10 23:13:25.0 +0200
+++ openexr-2.5.4/debian/patches/series	2021-05-18 23:03:57.0 +0200
@@ -11,3 +11,4 @@
 #CVE-2017-911x.patch
 am_foreign_set_global.diff
 bug909865.patch
+CVE-2021-23169.diff


signature.asc
Description: PGP signature

Bug#988652: logrotate: kern.log,syslog and other files in /var/log not rotating

[Michael Biebl]

Am 21.05.21 um 05:47 schrieb Uwe Niemeyer:

I adjusted the settings for /etc/logrotate.d/rsyslog
---
/var/log/syslog
/var/log/mail.info
/var/log/mail.warn
/var/log/mail.err
/var/log/mail.log
/var/log/daemon.log
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
/var/log/lpr.log
/var/log/cron.log
/var/log/debug
/var/log/messages
{
     rotate 4
     daily
     missingok
     notifempty
     compress
     delaycompress
     sharedscripts
     postrotate
     /usr/lib/rsyslog/rsyslog-rotate
     endscript
}

based on

https://salsa.debian.org/debian/rsyslog/-/commit/651236c2319eb0ca13fd1d376eaf239a6dcd5c49     


an with "daily".

The problems outlined are still there :



I guess the relevant part is this:


-rw-r-  1 root adm 606 Mai 21 04:30 messages
-rw-r-  1 root adm    4404 Mai 21 04:00 messages.1




-rw-r-  1 root adm 606 Mai 21 04:30 syslog
-rw-r-  1 root adm  131397 Mai 21 04:55 syslog.1


syslog.1 is newer then syslog. So some log messages ended up in syslog, 
but rsyslog then continued to write to syslog.1 ?
If you were referring to that problem, can you share what has been 
written to syslog and syslog.1?




OpenPGP_signature
Description: OpenPGP digital signature

Bug#988994: no graphics, but a frozen console for kernel 5.12.6 and nvidia 460.80-1

[Harald Dunkel]

Package: nvidia-kernel-dkms
Version: 460.80-1

I've got a reproducible freeze for kernel 5.12.6 (built from git) and
the new 460.80-1 nvidia packages. Instead of a graphics screen I just
get a cursor in the top left corner. The console is unresponsive. I
cannot switch to another console. The Xorg executable cannot be killed.

Moving back to 460.73.01-1 fixes the issue.

Both Xorg.log files are attached.


Regards
Harri


Xorg.4.log.old
Description: application/trash
[46.947] 
X.Org X Server 1.20.11
X Protocol Version 11, Revision 0
[46.947] Build Operating System: linux Debian
[46.947] Current Operating System: Linux cecil.afaics.de 5.12.6-raw #1 SMP 
PREEMPT Sat May 22 12:04:49 CEST 2021 x86_64
[46.947] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.12.6-raw 
root=UUID=d6b6d2f3-8213-4221-9a69-df7dc69acc45 ro net.ifnames=0 
vsyscall=emulate mitigations=off
[46.947] Build Date: 13 April 2021  04:07:31PM
[46.947] xorg-server 2:1.20.11-1 (https://www.debian.org/support) 
[46.947] Current version of pixman: 0.40.0
[46.947]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[46.947] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[46.947] (==) Log file: "/var/log/Xorg.4.log", Time: Sat May 22 19:42:13 
2021
[46.948] (==) Using config file: "/etc/X11/xorg.conf"
[46.948] (==) Using config directory: "/etc/X11/xorg.conf.d"
[46.948] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[46.949] (==) ServerLayout "Layout0"
[46.949] (**) |-->Screen "Screen0" (0)
[46.949] (**) |   |-->Monitor "Monitor0"
[46.949] (**) |   |-->Device "Device0"
[46.949] (**) |-->Input Device "Keyboard0"
[46.949] (**) |-->Input Device "Mouse0"
[46.949] (**) Option "Xinerama" "0"
[46.949] (==) Automatically adding devices
[46.949] (==) Automatically enabling devices
[46.949] (==) Automatically adding GPU devices
[46.949] (==) Max clients allowed: 256, resource mask: 0x1f
[46.950] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[46.950]Entry deleted from font path.
[46.951] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[46.951] (==) ModulePath set to "/usr/lib/xorg/modules"
[46.951] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 
'vmmouse' will be disabled.
[46.951] (WW) Disabling Keyboard0
[46.951] (WW) Disabling Mouse0
[46.951] (II) Loader magic: 0x563a56349e40
[46.951] (II) Module ABI versions:
[46.951]X.Org ANSI C Emulation: 0.4
[46.951]X.Org Video Driver: 24.1
[46.951]X.Org XInput driver : 24.1
[46.951]X.Org Server Extension : 10.0
[46.952] (--) using VT number 7

[46.952] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[46.952] (II) xfree86: Adding drm device (/dev/dri/card0)
[46.953] (--) PCI:*(2@0:0:0) 10de:1f82:19da:1546 rev 161, Mem @ 
0xa200/16777216, 0x9000/268435456, 0xa000/33554432, I/O @ 
0x3000/128, BIOS @ 0x/131072
[46.953] (II) "glx" will be loaded. This was enabled by default and also 
specified in the config file.
[46.953] (II) LoadModule: "dbe"
[46.953] (II) Module "dbe" already built-in
[46.953] (II) LoadModule: "extmod"
[46.953] (II) Module "extmod" already built-in
[46.953] (II) LoadModule: "glx"
[46.954] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[46.957] (II) Module glx: vendor="X.Org Foundation"
[46.957]compiled for 1.20.11, module version = 1.0.0
[46.957]ABI class: X.Org Server Extension, version 10.0
[46.957] (II) LoadModule: "nvidia"
[46.957] (II) Loading /usr/lib/xorg/modules/drivers/nvidia_drv.so
[46.959] (II) Module nvidia: vendor="NVIDIA Corporation"
[46.959]compiled for 1.6.99.901, module version = 1.0.0
[46.959]Module class: X.Org Video Driver
[46.959] (II) NVIDIA dlloader X Driver  460.73.01  Thu Apr  1 21:37:53 UTC 
2021
[46.959] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
[47.086] (II) Loading sub module "fb"
[47.086] (II) LoadModule: "fb"
[47.087] (II) Loading /usr/lib/xorg/modules/libfb.so
[47.087] (II) Module fb: vendor="X.Org Foundation"
[47.087]compiled for 1.20.11, module version = 1.0.0
[47.087]ABI class: X.Org ANSI C Emulation, version 0.4
[47.087] (II) Loading sub module "wfb"
[47.087] (II) LoadModule: "wfb"
[47.087] (II) Loading /usr/lib/xorg/modules/libwfb.so
[47.087] (II) 

Bug#988993: ITP: vbz-compression -- VBZ compression plugin for nanopore signal data

[Nilesh Patra]

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

Subject: ITP: vbz-compression -- VBZ compression plugin for nanopore signal data
Package: wnpp
Owner: Nilesh Patra 
Severity: wishlist

* Package name: vbz-compression
  Version : 1.0.1
  Upstream Author : Copyright: Oxford Nanopore Technologies 
* URL : https://github.com/nanoporetech/vbz_compression/
* License : MPL-2.0
  Programming Lang: C
  Description : VBZ compression plugin for nanopore signal data
 VBZ Compression uses variable byte integer encoding to compress nanopore
 signal data.
 .
 The performance of VBZ is achieved by taking advantage of the properties
 of the raw signal and therefore is most effective when applied to the
 signal dataset. Other datasets you may have in your Fast5 files will not
 be able to take advantage of the default VBZ settings for compression.
 VBZ will be used as the default compression scheme in a future release
 of MinKNOW.
 .
 This package contains the shared object library.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/vbz-compression

Bug#988992: saods9: WCS of non-sky FITS displays %1.8G, original ds9 is ok

[Peter Teuben]

Package: saods9
Version: 8.1+repack-1
Severity: normal
Tags: upstream

Dear Maintainer,

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

   * What led up to the situation?

I have a fits file which has a linear WCS, not a sky image. It loads fine as an
image, but the panel display the various coordinates has an issue.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

move the mouse and see what coordinates are.

   * What was the outcome of this action?

it displays %1.8G for X, Y and Z coordinates.

   * What outcome did you expect instead?

I expected the values, as contracted via the CRPIX,CRVAL,CDELT values in the
header.
I should add the original ds9 from SAO (the large single executable) works
fine, this scripting version calling wish is the one with the problem.
I used sao V8.1 for both the ubuntu 20.04LTS and the one I had downloaded a
while back from SAO.

I have a fits file that exemplifies this, which hopefully I can attach in some
next menu.   If not, here's my personal URL (the file will be 48kB)

https://www.astro.umd.edu/~teuben/data/NGC2347.rvos.fits



-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages saods9 depends on:
ii  libtk-img 1:1.4.9+dfsg-1
ii  tcl-signal1.4.4-1
ii  tcl-tls [tcltls]  1.7.20-1
ii  tcl-xpa   2.1.19-1
ii  tcliis8.1+repack-1
ii  tcllib1.20+dfsg-1
ii  tclxml1:3.2.7-5
ii  tk8.6.9+1
ii  tk-html1  1.04-2
ii  tk-mpeg   1.0.7-2build1
ii  tk-table  2.10-4
ii  tkblt 3.2.21-1build1
ii  tkcon 2:2.7.3-1
ii  tksao 8.1+repack-1

Versions of packages saods9 recommends:
ii  saods9-doc  8.1+repack-1

Versions of packages saods9 suggests:
pn  python3-pyds9  
ii  xpa-tools  2.1.19-1

-- no debconf information

Bug#988991: wordpress: setup-mysql should also set FS_METHOD

[Paul Gevers]

Package: wordpress
Version: 5.0.12+dfsg1-0+deb10u1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Installed WordPress on a new host

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I created a new site with setup-mysql

   * What was the outcome of this action?

After some Apache2 tweaking, I got stuff working but installing plugins
or themes failed with a question to provide ftp credentials. As the host
I am migrating away from didn't need that I tried to achieve the same.
It took me quite some time to find out that I manually changed
/etc/wordpress/config-.php to include
`define('FS_METHOD', 'direct');`
After doing the same on the new host, installing plugin and themes works.

   * What outcome did you expect instead?

As this file is generated by setup-mysql, it could/should write this
line too, probablye with comments, maybe commented out.

I looked at
https://sources.debian.org/src/wordpress/5.7.1+dfsg1-2/debian/setup-mysql/
to see if the current version is better, but it doesn't seem to add it.

Paul

-- System Information:
Debian Release: 10.9
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 4.19.0-16-armmp-lpae (SMP w/2 CPU cores)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages wordpress depends on:
ii  apache2 [httpd] 2.4.38-3+deb10u4
ii  ca-certificates 20200601~deb10u2
ii  default-mysql-client1.0.5
ii  libapache2-mod-php  2:7.3+69
ii  libapache2-mod-php7.3 [libapache2-mod-php]  7.3.27-1~deb10u1
ii  libjs-cropper   1.2.2-1
ii  mariadb-client-10.3 [virtual-mysql-client]  1:10.3.27-0+deb10u1
ii  php-gd  2:7.3+69
ii  php-getid3  1.9.17+dfsg-1
ii  php-mysql   2:7.3+69
ii  php7.3-gd [php-gd]  7.3.27-1~deb10u1
ii  php7.3-mysql [php-mysqlnd]  7.3.27-1~deb10u1

Versions of packages wordpress recommends:
ii  wordpress-l10n  5.0.12+dfsg1-0+deb10u1
ii  wordpress-theme-twentynineteen  5.0.12+dfsg1-0+deb10u1

Versions of packages wordpress suggests:
ii  mariadb-server-10.3 [virtual-mysql-server]  1:10.3.27-0+deb10u1
pn  php-ssh2

-- Configuration Files:
/etc/wordpress/htaccess changed [not included]

-- debconf information excluded



OpenPGP_signature
Description: OpenPGP digital signature

Bug#988986: cppcheck: Symbol `_ZTVN8tinyxml210XMLPrinterE' has different size in shared object, consider re-linking

[Joachim Reichel]

reassign 988986 tinyxml2
severity 988986 serious
retitle 988986 ABI change in tinyxml2 8.1.0+dfsg-1
found 988986 8.1.0+dfsg-1
thanks


Hi Chow,

it seems that there's an ABI change in tinyxml2 8.1.0+dfsg-1.

cppcheck 2.3-1 was uploaded to unstable on 2020-12-17, compiled against tinyxml2 8.0.0+dfsg-2, and 
migrated to testing. On 2021-05-20, tinyxml2 8.1.0+dfsg-1 was uploaded to unstable.


Running "touch foo.cpp; cppcheck foo.cpp" works as expected in testing, but shows "_cppcheck: Symbol 
`_ZTVN8tinyxml210XMLPrinterE' has different size in shared object, consider re-linking" in unstable.


$ echo _ZTVN8tinyxml210XMLPrinterE | c++filt
vtable for tinyxml2::XMLPrinter

Indeed, the diff both between versions of tinyxml shows that the vtable of XMLPrinter has been 
extended. Looks to me as this ABI change requires at least a library transition.


Thinking a bit more about it ...

This also changes the vtable of derived class (XMLPrinter is not final) in an incompatible way , 
which can be seen with the example in the contrib folder. Building against 8.0.0+dfsg-2 and running 
with 8.1.0+dfsg-1 leads to a crash. I wonder why upstream did not bump the SOVERSION.


Best regards,
  Joachim

Bug#988844: daemon_notifier_socket bind: Address already in use

[Andreas Metzler]

Control: tags -1 confirmed

On 2021-05-20 Chris Hofstaedtler  wrote:
> Package: exim4-daemon-heavy
> Version: 4.94.2-1~bpo10+1
> Severity: important

> Dear Maintainer,

> thank you for maintaining exim, also in backports.

> I have recently upgraded from the version in buster to
> 4.94.2-1~bpo10+1 from buster-backports.

> Since then, on each service restart, I get this error in
> /var/log/exim4/paniclog:
>2021-05-20 11:41:39.862 [1309224] daemon_notifier_socket bind: Address 
> already in use

> Specialities about this setup:
>   /etc/default/exim4: QUEUERUNNER='separate'
[...]
> I guess upstream ticket 2616 could be used to mitigate this issue,
> if the startup scripts set the new option when QUEUERUNNER=separate:
>   https://bugs.exim.org/show_bug.cgi?id=2616

> Please consider applying and using the upstream patch on top of
> 4.94.2 for bullseye (and maybe buster-backports).

Hello Chris,

thanks for report and suggested fix.

Setting QUEUERUNNER='separate' seems to be enough to trigger the bug.
With the patch you linked to applied and globally disabled
notifier_socket I do not see the error anymore.

My current plan is to cherrypick the patch and set -oY in the initscript
for both daemon instances if QUEUERUNNER='separate' is set.

I will let -5 enter testing though, might upload to experimental for
earlier testing.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#988990: [Emulator Shell]

[Junie Vivian]

Package: Emulator Shell
Version: SoapFault - faultcode: 'SOAP-ENV:Server' faultstring: 'Processing
Failure' faultactor: 'null' detail: org.kxml2.kdom.Node@88e867a
Severity: 
Tags: 
X-Debbugs-CC: 
Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

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

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

Bug#988989: ITP: python-cigar -- manipulate SAM cigar strings

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: python-cigar -- manipulate SAM cigar strings
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: python-cigar
  Version : 0.1.3
  Upstream Author : Copyright: (c) 2013 Brent Pedersen - Bioinformatics
* URL : https://github.com/brentp/cigar
* License : MIT
  Programming Lang: Python
  Description : manipulate SAM cigar strings
 Cigar is a simple Python3 library for dealing with cigar strings. the most 
useful
 feature now is soft-masking from left or right. This allows one to adjust
 a SAM record only by changing the cigar string to soft-mask a number of bases
 such that the rest of the SAM record (pos, tlen, etc.) remain valid, but
 downstream tools will not consider the soft-masked bases in further analysis.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/python-cigar

Bug#988987: grub setup fails in VM environment when using raid setup

[Thomas Lange]

Package: fai-doc
Version: 5.10.2
Tags: patch


The example script for setting up the grub config fails for a software
raid setup in a virtual environment when using grub-pc.

In scipts/GRUB_PC/10-setup the variable mbrdevices is set to
+ mbrdevices+=', '

Error message:
+ mbrdevices=', '
+ echo 'grub-pc grub-pc/install_devices multiselect , '
+ unshare --pid --fork --kill-child --mount-proc chroot /target 
debconf-set-selections
+ unshare --pid --fork --kill-child --mount-proc chroot /target 
dpkg-reconfigure grub-pc
/, does not exist, so cannot grub-install to it!
You must correct your GRUB install devices before proceeding:




patch
Description: Binary data

-- 
viele Grüße Thomas

Bug#988968: unblock: e17/0.24.2-6

[Ross Vandegrift]

Control: tags -1 - moreinfo

Hello,

On Sat, May 22, 2021 at 09:53:26AM +0200, Sebastian Ramacher wrote:
> Control: tags -1 moreinfo
> 
> On 2021-05-21 22:23:20 -0700, Ross Vandegrift wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: unblock
> > X-Debbugs-Cc: rvandegr...@debian.org
> > 
> > Please unblock package e17
> > 
> > [ Reason ]
> > 
> > 0.24.2-6 recommends libddcutil2, which has been replaced by libddcutil3.  
> > 
> > [ Impact ]
> > 
> > A non-existant package will be recommended.  Backlight controls for 
> > external monitors won't work unless the user tries libddcutil3.
> > 
> > [ Tests ]
> > 
> > There are no automated tests.  I have used libddcutil3 without regression
> > since uploading the change.
> 
> Are you sure?
> 
> /tmp/e17-0.24.2%% rgrep ddcutil\.so
> src/bin/system/e_system_ddc.c:   ddc_lib = dlopen("libddcutil.so.2", RTLD_NOW 
> | RTLD_LOCAL);
> 
> I don't see libddcutil.so.3 used anywhere.

No, I'm not sure anymore - I must've messed up.  Apologies!

Upstream git after 0.24.2 has a patch to support libddcutil3.  There may not be
time for testing + migration before release.  But if there were, would the
below patch be acceptable during freeze?

Thanks,
Ross


commit ead43c40c36bb4f74426a8b1ca4418952e338ac1
Author: Carsten Haitzler 
Date:   Tue Aug 18 12:06:43 2020 +0100

ddc - add libddcutil.so.3 as supported as it is compatible for our uses

diff --git a/src/bin/system/e_system_ddc.c b/src/bin/system/e_system_ddc.c
index 2d57b3bac..74d48dd56 100644
--- a/src/bin/system/e_system_ddc.c
+++ b/src/bin/system/e_system_ddc.c
@@ -302,7 +302,11 @@ err:
 static Eina_Bool
 _ddc_init(void)
 {
-   ddc_lib = dlopen("libddcutil.so.2", RTLD_NOW | RTLD_LOCAL);
+   // .so.3 is ABI compatible twith .so.2 for out uses - see
+   // https://www.ddcutil.com/c_api_99/ for changes between them
+   ddc_lib = dlopen("libddcutil.so.3", RTLD_NOW | RTLD_LOCAL);
+   if (!ddc_lib)
+ ddc_lib = dlopen("libddcutil.so.2", RTLD_NOW | RTLD_LOCAL);
if (!ddc_lib) return EINA_FALSE;
 #define SYM(_x) \
do { \


signature.asc
Description: PGP signature

Bug#988174: (/usr/bin/qemu-aarch64-static: Segfaults sometimes on python3-minimal on arm64)

[Bernhard Übelacker]

Am 22.05.21 um 00:11 schrieb Bernhard Übelacker:

Maybe systemd-coredump would collect a core of such a crash?


And I did a debootstrap in a loop and got three crashes out of 20 tries.
A core was collected and shows the stack below.

It is strange that exec_path shows just "/arm64" and
trying gdb to print the variable mmap_lock_count shows
a warning about a corrupted shared library list.

Kind regards,
Bernhard




(gdb) bt
#0  have_mmap_lock () at ../../linux-user/mmap.c:43
#1  0x005863ac in page_set_flags (start=start@entry=4194304, 
end=end@entry=21041152, flags=flags@entry=8) at 
../../accel/tcg/translate-all.c:2568
#2  0x0056416d in target_mmap (start=start@entry=4194304, len=, len@entry=16842963, target_prot=target_prot@entry=0, flags=16434, 
fd=fd@entry=-1, offset=offset@entry=0) at ../../linux-user/mmap.c:602
#3  0x0057be4d in load_elf_image (image_name=0x7ffe12b44e4f "/arm64", image_fd=3, 
info=info@entry=0x7ffe12b43b20, pinterp_name=pinterp_name@entry=0x7ffe12b43880, 
bprm_buf=bprm_buf@entry=0x7ffe12b43d30 "\177ELF\002\001\001") at 
../../linux-user/elfload.c:2700
#4  0x0057c5bc in load_elf_binary (bprm=bprm@entry=0x7ffe12b43d30, 
info=info@entry=0x7ffe12b43b20) at ../../linux-user/elfload.c:3104
#5  0x00571a4b in loader_exec (fdexec=fdexec@entry=3, filename=, argv=argv@entry=0x20b8d20, envp=envp@entry=0x210db50, 
regs=regs@entry=0x7ffe12b43c20, infop=infop@entry=0x7ffe12b43b20, bprm=) at ../../linux-user/linuxload.c:147
#6  0x00402831 in main (argc=, argv=0x7ffe12b442e8, 
envp=) at ../../linux-user/main.c:831

(gdb) display/i $pc
1: x/i $pc
=> 0x5637c0 :   mov%fs:0xff50,%eax

(gdb) frame 6
#6  0x00402831 in main (argc=, argv=0x7ffe12b442e8, 
envp=) at ../../linux-user/main.c:831
831 ../../linux-user/main.c: Datei oder Verzeichnis nicht gefunden.
(gdb) print argv[0]
$6 = 0x7ffe12b44e25 "/usr/libexec/qemu-binfmt/aarch64-binfmt-P"
(gdb) print argv[1]
$7 = 0x7ffe12b44e4f "/arm64"
(gdb) print argv[2]
$8 = 0x7ffe12b44e56 "/arm64"
(gdb) print argv[3]
$9 = 0x0

(gdb) print _lock_count
warning: Corrupted shared library list: 0xd5f120 != 0x0
Cannot find thread-local storage for LWP 148246, executable file 
/usr/lib/debug/.build-id/2e/c1a124ce847ca347222b5ddcdb8639aadff4e0.debug:
Cannot find thread-local variables on this target

(gdb) print exec_path
$32 = 0x7ffe12b44e4f "/arm64"

From Diederik's second mail:
[44932.698657] python3.9[313800]: segfault at 2524310 ip 005637c0 sp 
7ffdeefd1098 error 4 in qemu-aarch64-static[401000+3e3000]
[44932.698664] Code: 00 e9 94 78 1c 00 0f 1f 40 00 64 83 2c 25 50 ff ff ff 01 
74 05 c3 0f 1f 40 00 48 8d 3d e9 d0 7f 00 e9 e4 85 1c 00 0f 1f 40 00 <64> 8b 04 
25 50 ff ff ff 85 c0 0f 9f c0 c3 66 90 48 83 ec 08 64 8b

https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash

error 4 == 0b0100:
bit 0 ==0: no page found
bit 1 ==0: read access
bit 2 ==1: user-mode access

echo -n "find /b ..., ..., 0x" && \
echo "00 e9 94 78 1c 00 0f 1f 40 00 64 83 2c 25 50 ff ff ff 01 74 05 c3 0f 1f 
40 00 48 8d 3d e9 d0 7f 00 e9 e4 85 1c 00 0f 1f 40 00 <64> 8b 04 25 50 ff ff ff 
85 c0 0f 9f c0 c3 66 90 48 83 ec 08 64 8b" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'

find /b ..., ..., 0x00, 0xe9, 0x94, 0x78, 0x1c, 0x00, 0x0f, 0x1f, 0x40, 0x00, 
0x64, 0x83, 0x2c, 0x25, 0x50, 0xff, 0xff, 0xff, 0x01, 0x74, 0x05, 0xc3, 0x0f, 
0x1f, 0x40, 0x00, 0x48, 0x8d, 0x3d, 0xe9, 0xd0, 0x7f, 0x00, 0xe9, 0xe4, 0x85, 
0x1c, 0x00, 0x0f, 0x1f, 0x40, 0x00, 0x64, 0x8b, 0x04, 0x25, 0x50, 0xff, 0xff, 
0xff, 0x85, 0xc0, 0x0f, 0x9f, 0xc0, 0xc3, 0x66, 0x90, 0x48, 0x83, 0xec, 0x08, 
0x64, 0x8b


##


# Bullseye/testing amd64 qemu VM 2021-05-21

dpkg --add-architecture arm64
apt update
apt dist-upgrade

apt install gdb qemu-user-static-dbgsym

echo "set enable-bracketed-paste off" >> /etc/inputrc; bash


gdb -q
set width 0
set pagination off
file /usr/bin/qemu-aarch64-static
tb main
run

(gdb) info target
Symbols from "/usr/bin/qemu-aarch64-static".
Native process:
Using the running image of child Thread 0xd873c0 (LWP 975).
While running this, GDB does not access memory from...
Local exec file:
`/usr/bin/qemu-aarch64-static', file type elf64-x86-64.
Entry point: 0x403670
...
0x00401140 - 0x007e2872 is .text
...
(gdb) find /b 0x00401140, 0x007e2872, 0x00, 0xe9, 0x94, 0x78, 
0x1c, 0x00, 0x0f, 0x1f, 0x40, 0x00, 0x64, 0x83, 0x2c, 0x25, 0x50, 0xff, 0xff, 
0xff, 0x01, 0x74, 0x05, 0xc3, 0x0f, 0x1f, 0x40, 0x00, 0x48, 0x8d, 0x3d, 0xe9, 
0xd0, 0x7f, 0x00, 0xe9, 0xe4, 0x85, 0x1c, 0x00, 0x0f, 0x1f, 0x40, 0x00, 0x64, 
0x8b, 0x04, 0x25, 0x50, 0xff, 0xff, 0xff, 0x85, 0xc0, 0x0f, 0x9f, 0xc0, 0xc3, 
0x66, 0x90, 0x48, 0x83, 0xec, 0x08, 0x64, 0x8b
0x563796 
1 pattern found.

(gdb) b * (0x563796 + 42)
Breakpoint 2 at 0x5637c0: file ../../linux-user/mmap.c, line 43.

(gdb) info b
Num Type   Disp Enb AddressWhat
2   

Bug#986356: Support SRV record and add cdn-fastly.deb.debian.org and avoid truncated InRelease

[Eduard Bloch]

Control: reopen 914852

Hallo,
* Osamu Aoki [Fri, Apr 23 2021, 02:35:08PM]:
> control: unmerge 986356
> control: merge 986356 954904
> control: retitle 954904 Support SRV record
> control: retitle 986356 Support SRV record
> control: clone 986356 -1 -2
> control: retitle -1 Add cdn-fastly.deb.debian.org to debvol_mirrors.gz
> control: tags -1 patch
> control: retitle -2 Truncated InRElease file
> control: severity -2 normal
> thanks

I am loosing track of this mess and I think I have closed on of this
issue with the latest experimental release by mistake.

> Although
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914852
> is likely caused by the same root cause, let me not get too agressive.
> So I am unmerging it.  But merging keep 2 bugs together.

Okay. Still, wrong issue was hit, sorry.

> As I grep the source for "SRV", I do not see it in apt-cacher-ng
> source.  So I am faily sure apt-cacher-ng doesn't support SRV record.
>
> https://en.wikipedia.org/wiki/SRV_record
>
> APT is also written in C++ and it has:
>   apt/apt-pkg/contrib/srvrec.cc
>   apt/apt-pkg/contrib/srvrec.h
> to support SRV record from 2015.
>
> It explains as:
>DNS SRV record support in apt
>=
>
>Apt supports a subset of the DNS SRV server records protocol as
>described in [RFC 2782](https://tools.ietf.org/html/rfc2782) for
>service discovery.
>
>Before connecting to the requested server APT will send a SRV
>record request of the form `_$protocol._tcp._$host`, e.g.
>`_http._tcp.ftp.debian.org` or `_http._tcp.security.debian.org`.

This is ongoing implementation. I switched the code to libc-ares which
has SRV support too. However it's not happening automatically (I need to
implement a bit of code which does similar considerations as APT) so it
is currently not utilized, also because I don't have a good test base to
implement it. For deb.debian.org it seems to be pointless because CNAME
does the job ATM, or am seing things wrong here?

$ host -t SRV deb.debian.org
deb.debian.org is an alias for debian.map.fastlydns.net.
$ host -t CNAME deb.debian.org
deb.debian.org is an alias for debian.map.fastlydns.net.


>If the server sends SRV records
>as a reply APT will use those to connect to the server(s) in
>this reply. It will honor the `priority` field in the reply.
>
>However it does not implement the `weight` algorithm as described
>in RFC 2782. It will use an equal weight for each server of the
>same priority.
>
>If connecting to a server fails APT will retry with the next one
>and remove the server from the list of valid servers for this
>session.
>
> Merging this part of code from apt to apt-cacher-ng should fix issues
> from the root cause.  I am afraid some repos such as one from Ubuntu
> may be using the similar configuration.  So other bugs may be solved
> too.
>
> Fixing this may fix truncated file problem too.  (I don't know)

File truncation is likely to be a bug somewhere deep in the downloading
code. I tried to find a workaround for the low hanging fruits in 3.6.3
but I am not sure whether it was doing it right. Another issue I have
found is with the connection closing code which was not done right and
could potentially kill open filehandles or even causing unrelated
activities to reuse the ID, therefore maybe even damaging data. This
should explains all that "bad file descriptor" issues.

I am going to prepare a backport of the changes from the experimental
release into stable-proposed-updates but the timing is very unfortunate.

> I also cloned this bug to make different issues separate.
>
> Since without adding cdn-fastly.deb.debian.org as attached file, it
> waste cache space if the user uses it in chroot etc..  Since it is
> small gz file I atach fixed file itselg here and mark this bug as
> patch.  This goes to -1 cloned bug.

First, the file you sent is generated, so patching it is not okay.

Second, I am not sure whether I can reproduce the original issue. Means:
for me, using deb.debian.org as source simply works and the last time I
checked it was transparently going to fastly service, no extra hops
there.

Best regards,
Eduard.

Bug#988174: (/usr/bin/qemu-aarch64-static: Segfaults sometimes on python3-minimal on arm64)

[Christopher Obbard]

Hi Diederik,

> FTR: it's not unwillingness to help, but apart from reporting the issue
> I'm not able to further help in any meaningful way to diagnose it.
> But as stated before, if someone provides a .deb file with a/the fix,
> I'm happy to test it.

We're facing the same (similar?) problem with Debos - in some cases
the qemu-user process seems to segfault.

Looks like a new version of qemu is in experimental - which has some
changes to linux-user/mmap.c

Perhaps it would be a good idea to see if the bug is still present in 6.0?

Thanks,
Chris

Bug#988985: CVE-2020-23856

[Moritz Muehlenhoff]

Package: cflow
Severity: normal
Tags: security
X-Debbugs-Cc: Debian Security Team 

This was assigned CVE-2020-23856:
https://lists.gnu.org/archive/html/bug-cflow/2020-07/msg0.html

Cheers,
Moritz

Bug#988982: apt-utils: does not sort the numbers correctly. Should be smallest to largest.

[David Bremner]

Control: severity -1 wishlist

Salman Mohammadi  writes:

> Package: elpa-debian-el
> Version: 37.10
> Severity: normal
> X-Debbugs-Cc: sal...@smoha.org
>
> Dear Maintainer,
>
> the command `apt-utils-search` does not sort the numbers based on integer 
> value
> from smallest to largest.
>
> How to reproduce:
> -
>  1. M-x apt-utils-search
>  2. Search packages for regexp: google-android-platform

Since the function does not promise any particular order, and the order
matches "apt search" on the command line, this seems more like a request
for an enhancement. I guess sorting by version might be possible,
although not trivial due to versions being complicated. Sorting by some
number embedded in the package name sounds messy.

d

Bug#988984: ITP: libtest-synopsis-expectation-perl -- test that SYNOPSIS code produces expected results

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Perl Group 


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: libtest-synopsis-expectation-perl
  Version : 0.12
  Upstream Author : moznion 
* URL : https://metacpan.org/pod/Test::Synopsis::Expectation
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : test that SYNOPSIS code produces expected results

 Test-Synopsis-Expectation checks
 that a perl module's SYNOPSIS section is syntactically correct,
 and will also check that it produces the expected results,
 based on annotations you add in comments.

This package will be maintained in the Debian Perl team.


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmCpGXgACgkQLHwxRsGg
ASGwcxAAh4s4WXqBF6t/5S/XO07e5hXFhAoaFFz5QiotpA/VzkbNjxTWaYxyFCSD
vH4NkJUk21OE1M21t+5EJmIn7JFWRX912bhjVmfs251zziHDFBMywfUkykJDByY0
SgYPgvSxqsgW6HsIxz8lZf8ROsIkM7cNMYI9BH05wKpaLbgFBq+KhWAT8UHdJCwZ
AnZbBCPsEf13BKHLLdaMsGP6zsc3+kJvkLX6GLE3liHy6PGF8gCyDtB/d6EdCb8c
Cz9aH4t2Pm8lB+pFbFrgfjflTt3audPjrlbomeDYZTL0stW1CiUFEisxvdhi8n6O
oJjyuMR27AtAlCxlpbpc4rtmogwAVlZnsmJcuj+3QHl/IL6+fJxRzQR1rO5NP+fh
b6bup7RGvZmccfpXR5ibD0oOJTBCB+TCx+Eiw4ayT8HNHgbq5SP2SXTgW6RT1/Ad
tYUb4L8bjnpAkblZVUnlAd0+OWFntYtSS1LuWQDot8/gYulwIGKRRUenTQGjhoZ4
hIHsNyOC62nLyhub0In9YqJ69BMqyl+vhO0T0drjyMj57Hzjs0L3lSKxjctd/BZH
49J5/KG/yVfLaks9gyMwWSVYC5dH7eqJRdpX7f8486RLKFwk8dyO+qxjyDBmTcKr
DnDDnfEE9miCWJtW/Bi3ryAhyMTgBWKmnFCZGAuZ7ZWjnICYyno=
=dSub
-END PGP SIGNATURE-

Bug#988983: unblock: golang-golang-x-net/1:0.0+git20210119.5f4716e+dfsg-4

[Shengjing Zhu]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: z...@debian.org

Please unblock package golang-golang-x-net

[ Reason ]
Backport patch for CVE-2021-33194
x/net/html: infinite loop in ParseFragment

[ Impact ]
It fixes security issues.

[ Tests ]
Upstream has added a unit test for the issue in the patch.

[ Risks ]
+ Diff is small
+ Key package

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

[ Other info ]
Need rebuild packages which have built-using with old version of
golang-golang-x-net

unblock golang-golang-x-net/1:0.0+git20210119.5f4716e+dfsg-4


diff -Nru golang-golang-x-net-0.0+git20210119.5f4716e+dfsg/debian/changelog 
golang-golang-x-net-0.0+git20210119.5f4716e+dfsg/debian/changelog
--- golang-golang-x-net-0.0+git20210119.5f4716e+dfsg/debian/changelog   
2021-05-08 12:12:17.0 +0800
+++ golang-golang-x-net-0.0+git20210119.5f4716e+dfsg/debian/changelog   
2021-05-22 22:01:02.0 +0800
@@ -1,3 +1,11 @@
+golang-golang-x-net (1:0.0+git20210119.5f4716e+dfsg-4) unstable; urgency=medium
+
+  * Team upload.
+  * Backport patch for CVE-2021-33194
+x/net/html: infinite loop in ParseFragment
+
+ -- Shengjing Zhu   Sat, 22 May 2021 22:01:02 +0800
+
 golang-golang-x-net (1:0.0+git20210119.5f4716e+dfsg-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru 
golang-golang-x-net-0.0+git20210119.5f4716e+dfsg/debian/patches/CVE-2021-33194.patch
 
golang-golang-x-net-0.0+git20210119.5f4716e+dfsg/debian/patches/CVE-2021-33194.patch
--- 
golang-golang-x-net-0.0+git20210119.5f4716e+dfsg/debian/patches/CVE-2021-33194.patch
1970-01-01 08:00:00.0 +0800
+++ 
golang-golang-x-net-0.0+git20210119.5f4716e+dfsg/debian/patches/CVE-2021-33194.patch
2021-05-22 22:01:02.0 +0800
@@ -0,0 +1,114 @@
+From: Nigel Tao 
+Date: Sun, 18 Apr 2021 21:15:27 +1000
+Subject: html: ignore templates nested within foreign content
+
+Fixes #46288
+Fixes CVE-2021-33194
+
+Change-Id: I2fe39702de8e9aab29965c1526e377a6f9cdf056
+Reviewed-on: https://go-review.googlesource.com/c/net/+/311090
+Reviewed-by: Filippo Valsorda 
+Run-TryBot: Filippo Valsorda 
+Trust: Roland Shoemaker 
+TryBot-Result: Go Bot 
+---
+ html/parse.go  | 24 +++-
+ html/parse_test.go | 22 ++
+ 2 files changed, 45 insertions(+), 1 deletion(-)
+
+diff --git a/html/parse.go b/html/parse.go
+index f91466f..038941d 100644
+--- a/html/parse.go
 b/html/parse.go
+@@ -663,6 +663,24 @@ func inHeadIM(p *parser) bool {
+   // Ignore the token.
+   return true
+   case a.Template:
++  // TODO: remove this divergence from the HTML5 spec.
++  //
++  // We don't handle all of the corner cases when mixing 
foreign
++  // content (i.e.  or ) with . 
Without this
++  // early return, we can get into an infinite loop, 
possibly because
++  // of the "TODO... further divergence" a little below.
++  //
++  // As a workaround, if we are mixing foreign content 
and templates,
++  // just ignore the rest of the HTML. Foreign content is 
rare and a
++  // relatively old HTML feature. Templates are also rare 
and a
++  // relatively new HTML feature. Their combination is 
very rare.
++  for _, e := range p.oe {
++  if e.Namespace != "" {
++  p.im = ignoreTheRemainingTokens
++  return true
++  }
++  }
++
+   p.addElement()
+   p.afe = append(p.afe, )
+   p.framesetOK = false
+@@ -683,7 +701,7 @@ func inHeadIM(p *parser) bool {
+   if !p.oe.contains(a.Template) {
+   return true
+   }
+-  // TODO: remove this divergence from the HTML5 spec.
++  // TODO: remove this further divergence from the HTML5 
spec.
+   //
+   // See 
https://bugs.chromium.org/p/chromium/issues/detail?id=829668
+   p.generateImpliedEndTags()
+@@ -2127,6 +2145,10 @@ func afterAfterFramesetIM(p *parser) bool {
+   return true
+ }
+ 
++func ignoreTheRemainingTokens(p *parser) bool {
++  return true
++}
++
+ const whitespaceOrNUL = whitespace + "\x00"
+ 
+ // Section 12.2.6.5
+diff --git a/html/parse_test.go b/html/parse_test.go
+index 58dce5f..019333d 100644
+--- a/html/parse_test.go
 b/html/parse_test.go
+@@ -267,6 +267,9 @@ func TestParser(t *testing.T) {
+  

Bug#988464: New mailing list: debian-enterprise

[Philip Wyett]

On Sat, 2021-05-22 at 13:49 +0200, Hanno 'Rince' Wagner wrote:
> Hi Philip!
> 
> On Sat, 22 May 2021, Philip Wyett wrote:
> 
> > I have tried twice over the last week to subscribe to this list. I get the 
> > "Subscription
> > request
> > processed" page, but do not get a confirmation email to be actioned as 
> > expected. This leaves me
> > not
> > knowing if the subscription has been processed at all.
> 
> well, you are subscribed to that list, so you are on it; and not
> subscribed as one of the last 10 members of that list...
> 
> maybe there is simply no traffic?
> 
> best regards, Hanno Wagner, Listmaster of the day

Hi,

Thank you for confirming my list subscription. Shame the old smartlist email 
confirmation was/is
not working as expected.

There has been no traffic since April. I hope maybe Mike can kick off by 
referencing his blog post
of today and start the ball rolling.

Regards

Phil

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

WWW: https://kathenas.org

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#988982: apt-utils: does not sort the numbers correctly. Should be smallest to largest.

[Salman Mohammadi]

Package: elpa-debian-el
Version: 37.10
Severity: normal
X-Debbugs-Cc: sal...@smoha.org

Dear Maintainer,

the command `apt-utils-search` does not sort the numbers based on integer value
from smallest to largest.

How to reproduce:
-
 1. M-x apt-utils-search
 2. Search packages for regexp: google-android-platform


The current sorted result:
-
google-android-platform-10-installer - Google's Android SDK Platform 10
Installer
google-android-platform-11-installer - Google's Android SDK Platform 11
Installer
google-android-platform-12-installer - Google's Android SDK Platform 12
Installer
google-android-platform-13-installer - Google's Android SDK Platform 13
Installer
google-android-platform-14-installer - Google's Android SDK Platform 14
Installer
google-android-platform-15-installer - Google's Android SDK Platform 15
Installer
google-android-platform-16-installer - Google's Android SDK Platform 16
Installer
google-android-platform-17-installer - Google's Android SDK Platform 17
Installer
google-android-platform-18-installer - Google's Android SDK Platform 18
Installer
google-android-platform-19-installer - Google's Android SDK Platform 19
Installer
google-android-platform-2-installer - Google's Android SDK Platform 2 Installer
google-android-platform-20-installer - Google's Android SDK Platform 20
Installer
google-android-platform-21-installer - Google's Android SDK Platform 21
Installer
google-android-platform-22-installer - Google's Android SDK Platform 22
Installer
google-android-platform-23-installer - Google's Android SDK Platform 23
Installer
google-android-platform-24-installer - Google's Android SDK Platform 24
Installer
google-android-platform-3-installer - Google's Android SDK Platform 3 Installer
google-android-platform-4-installer - Google's Android SDK Platform 4 Installer
google-android-platform-5-installer - Google's Android SDK Platform 5 Installer
google-android-platform-6-installer - Google's Android SDK Platform 6 Installer
google-android-platform-7-installer - Google's Android SDK Platform 7 Installer
google-android-platform-8-installer - Google's Android SDK Platform 8 Installer
google-android-platform-9-installer - Google's Android SDK Platform 9 Installer


The expected sorted result:
---
google-android-platform-2-installer - Google's Android SDK Platform 2 Installer
google-android-platform-3-installer - Google's Android SDK Platform 3 Installer
google-android-platform-4-installer - Google's Android SDK Platform 4 Installer
google-android-platform-5-installer - Google's Android SDK Platform 5 Installer
google-android-platform-6-installer - Google's Android SDK Platform 6 Installer
google-android-platform-7-installer - Google's Android SDK Platform 7 Installer
google-android-platform-8-installer - Google's Android SDK Platform 8 Installer
google-android-platform-9-installer - Google's Android SDK Platform 9 Installer
google-android-platform-10-installer - Google's Android SDK Platform 10
Installer
google-android-platform-11-installer - Google's Android SDK Platform 11
Installer
google-android-platform-12-installer - Google's Android SDK Platform 12
Installer
google-android-platform-13-installer - Google's Android SDK Platform 13
Installer
google-android-platform-14-installer - Google's Android SDK Platform 14
Installer
google-android-platform-15-installer - Google's Android SDK Platform 15
Installer
google-android-platform-16-installer - Google's Android SDK Platform 16
Installer
google-android-platform-17-installer - Google's Android SDK Platform 17
Installer
google-android-platform-18-installer - Google's Android SDK Platform 18
Installer
google-android-platform-19-installer - Google's Android SDK Platform 19
Installer
google-android-platform-20-installer - Google's Android SDK Platform 20
Installer
google-android-platform-21-installer - Google's Android SDK Platform 21
Installer
google-android-platform-22-installer - Google's Android SDK Platform 22
Installer
google-android-platform-23-installer - Google's Android SDK Platform 23
Installer
google-android-platform-24-installer - Google's Android SDK Platform 24
Installer


Thanks, Salman

-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages elpa-debian-el depends on:
ii  bzip2   1.0.8-4
ii  dh-elpa-helper  2.0.8
ii  dpkg1.20.9
ii  emacsen-common  3.0.4
ii  reportbug   7.10.3
ii  xz-utils5.2.5-2

Versions of packages elpa-debian-el recommends:
ii  emacs  1:27.1+1-3.1
ii  emacs-gtk [emacs]  1:27.1+1-3.1
ii  wget   1.21-1+b1

elpa-debian-el suggests no packages.

Bug#988643: [RFS] vtk-dicom/0.8.12-3

[Étienne Mollier]

Hi all,

Sorry for the noise with my previous sponsor request.  I redid
the vtk-dicom/0.8.12-3 revision to simply remove the broken
symlink.  Changes are available at the same location[1], updated
debdiff is available in attachment.  I redid the tests to make
sure no regressions were introduced, and it should be alright
for a hard freeze targeted update this time.

I'm much more confident with this iteration than the previous
one, but please review, and sponsor or grant DM permissions only
if this seems appropriate.

[1]: https://salsa.debian.org/med-team/vtk-dicom

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.
diff -Nru vtk-dicom-0.8.12/debian/changelog vtk-dicom-0.8.12/debian/changelog
--- vtk-dicom-0.8.12/debian/changelog	2019-12-22 14:42:19.0 +0100
+++ vtk-dicom-0.8.12/debian/changelog	2021-05-22 15:08:12.0 +0200
@@ -1,3 +1,19 @@
+vtk-dicom (0.8.12-3) unstable; urgency=medium
+
+  * Team upload.
+  * d/{python3-vtk-dicom,not-installed}: do not install libvtkDICOMPython*.so
+Closes: #988643
+
+ -- Étienne Mollier   Sat, 22 May 2021 15:08:12 +0200
+
+vtk-dicom (0.8.12-2) unstable; urgency=medium
+
+  * Team upload.
+  * Fix autopkgtest.  Thanks for the patch to Étienne Mollier.
+Closes: #988745
+
+ -- Andreas Tille   Wed, 19 May 2021 15:30:05 +0200
+
 vtk-dicom (0.8.12-1) unstable; urgency=medium
 
   * New upstream version 0.8.12
diff -Nru vtk-dicom-0.8.12/debian/not-installed vtk-dicom-0.8.12/debian/not-installed
--- vtk-dicom-0.8.12/debian/not-installed	1970-01-01 01:00:00.0 +0100
+++ vtk-dicom-0.8.12/debian/not-installed	2021-05-22 14:38:32.0 +0200
@@ -0,0 +1,2 @@
+# Linker name of Python module primitives probably not needed.  See #988643.
+usr/lib/*/libvtkDICOMPython*.so
diff -Nru vtk-dicom-0.8.12/debian/python3-vtk-dicom.install vtk-dicom-0.8.12/debian/python3-vtk-dicom.install
--- vtk-dicom-0.8.12/debian/python3-vtk-dicom.install	2019-12-22 14:42:19.0 +0100
+++ vtk-dicom-0.8.12/debian/python3-vtk-dicom.install	2021-05-22 14:32:04.0 +0200
@@ -1,5 +1,4 @@
 #!/usr/bin/dh-exec 
 usr/lib/*/libvtkDICOMPython*.so.* 
-usr/lib/*/libvtkDICOMPython*.so usr/lib/python${PYVER}/dist-packages
 usr/lib/*/vtkDICOMPython*.so usr/lib/python${PYVER}/dist-packages
 
diff -Nru vtk-dicom-0.8.12/debian/tests/autopkgtest-pkg-python.conf vtk-dicom-0.8.12/debian/tests/autopkgtest-pkg-python.conf
--- vtk-dicom-0.8.12/debian/tests/autopkgtest-pkg-python.conf	1970-01-01 01:00:00.0 +0100
+++ vtk-dicom-0.8.12/debian/tests/autopkgtest-pkg-python.conf	2021-05-19 22:40:52.0 +0200
@@ -0,0 +1 @@
+import_name = vtkDICOMPython


signature.asc
Description: PGP signature

Bug#956207: db_stop in postinst should do that

[Matus UHLAR - fantomas]

Hello,

I encountered the same problem although with 1.3.2-6+deb10u1:

installation of a package, or running dpkg-reconfigure opendmarc causes
script to hang at the stage:

root 27685  0.4  0.4  24488 16732 pts/5S+   15:20   0:00 /usr/bin/perl 
-w /usr/share/debconf/frontend /var/lib/dpkg/info/opendmarc.postinst configure 
1.3.2-6+deb10u1
root 27749  0.0  0.0  0 0 pts/5Z+   15:20   0:00 [opendmarc.posti] 

opendma+ 27904  0.0  0.0  47620  1920 ?Ssl  15:20   0:00 
/usr/sbin/opendmarc -c /etc/opendmarc.conf -u opendmarc -P 
/var/run/opendmarc/opendmarc.pid

adding "db_stop" at the end of postinst script (before exit 0) fixed the
problem.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
He who laughs last thinks slowest.

Bug#988973: CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY is deprecated

[Raul Tambre]

Package: debhelper
Version: 13.2.1+nmu1~cleveron1
Severity: wishlist

debhelper uses CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY, which since CMake 3.16 
is deprecated in favour of CMAKE_FIND_USE_PACKAGE_REGISTRY.
They're functionally equivalent, but the logic is switched, i.e. debhelper's 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON should become 
-DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF.

-- System Information:
Debian Release: 11.0
  APT prefers experimental
  APT policy: (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

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

Versions of packages debhelper depends on:
ii  autotools-dev20180224.1+nmu1
ii  dh-autoreconf20
ii  dh-strip-nondeterminism  1.12.0-1
ii  dpkg 1.20.9
ii  dpkg-dev 1.20.9
ii  dwz  0.14-1
ii  file 1:5.39-3
ii  libdebhelper-perl13.2.1+nmu1~cleveron1
ii  libdpkg-perl 1.20.9
ii  man-db   2.9.4-2
ii  perl 5.32.1-4
ii  po-debconf   1.0.21+nmu1

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  

-- no debconf information

Bug#988981: dh-autoreconf: please switch autoconf to verbose mode

[Nicolas Boulenguez]

Package: dh-autoreconf
Version: 20
Severity: wishlist
Tags: patch

Hello.
The policy now recommends verbose logs unless DEB_BUILD_OPTIONS
contains terse.
By default, autoreconf does not say in which subdirectory it enters,
which is quite inconvenient when debugging a failure.
Please consider applying the attached patch.
--- a/dh_autoreconf
+++ b/dh_autoreconf
@@ -75,7 +75,7 @@
 =item I B<--> I
 
 Run the program given by I with the arguments given by I
-instead of autoreconf -f -i. If you need to run multiple commands, put them in
+instead of autoreconf -f -i -v. If you need to run multiple commands, put them in
 a script and pass the script instead (or add a target to debian/rules).
 
 =back
@@ -175,8 +175,10 @@
 if (grep_configure("^XDT_")) {
 $ENV{NOCONFIGURE}='1';
 doit('xdt-autogen', @directories);
-} else {
+} elsif (get_buildoption("terse")) {
 doit('autoreconf', '-f', '-i', @directories);
+} else {
+doit('autoreconf', '-f', '-i', '-v', @directories);
 }
 }
 1;

Bug#988174: (/usr/bin/qemu-aarch64-static: Segfaults sometimes on python3-minimal on arm64)

[Diederik de Haas]

Hi Bernhard,

On zaterdag 22 mei 2021 00:11:22 CEST Bernhard Übelacker wrote:
> > Architecture: amd64 (x86_64)
> 
> The subject on the email mentions "on arm64".
>  From the Architecture line I assume this should read "on amd64"?

No.
While I build my images on an amd64 machine, the problem (so far) only 
occurs when building arm64 images, we haven't seen the problem with 
f.e. armhf images.

> The breaking instruction seems to be here:
> 0x5637c0: file ../../linux-user/mmap.c, line 43.
> 0x005637c0 :   64 8b 04 25 50 ff ff ff mov
>%fs:0xff50,%eax
> 
> I have hoped it might be more clear, but this might probably
> be related to the thread local storage of mmap_lock_count.
> Maybe systemd-coredump would collect a core of such a crash?

I'll take your word for it.
I'm assuming that the contents of debugging.txt is how you arrived at 
mmap.c line 43, but it's mostly abracadabra to me.
If someone would provide updated qemu debs with a potential fix, 
I can install them on my system to test it.
But it's very unlikely that I could (meaningfully) assist in tracking the 
core problem down or coming up with a fix. Installing systemd-coredump
would also be pretty useless if I did it.

OTOH, it *should* be rather easily reproducible by following the steps from
https://salsa.debian.org/raspi-team/image-specs#option-2-building-your-own-image

as that's how I and several others noticed the issue. The problem doesn't 
happen in 100% of the builds, but it is reproducible.
One could speed it up by using (f.e.) apt-cacher-ng and replacing 
'deb.debian.org' with 'localhost:3142/deb.debian.org' in raspi-master.yaml

FTR: it's not unwillingness to help, but apart from reporting the issue
I'm not able to further help in any meaningful way to diagnose it.
But as stated before, if someone provides a .deb file with a/the fix, 
I'm happy to test it.

> Kind regards,
> Bernhard

Cheers,
  Diederik

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

Bug#988643: [RFS] vtk-dicom/0.8.12-3

[Étienne Mollier]

Hi Andreas,

Andreas Beckmann, on 2021-05-22:
> On 22/05/2021 12.03, Étienne Mollier wrote:
> > consecutive to changes in multi-arch hints I had to bring per
> > lintian regression, I attempted to install concurrently the
> > package libvtk-dicom-dev both in native and foreign
> > architecture, and it would now fail with the following:
> 
> I'd leave out the M-A: same, that is usually not considered appropriate
> during the freeze. Especially if it does not lead to a M-A co-installable
> package.

Thanks for your advice!  This is not something I found in the
freeze policy, nor the FAQ, but given the effects, I must agree
with you.  I reverted my changes and will go for the removal of
the libvtkDICOMPython*.so symlink from any vtk-dicom packages
for the moment, since there haven't been much breakage with the
dangling symlink anyway.  It may not be entirely ideal, but
there is no risk of regression this way.

> This should be fixed for bookworm.
> 
> I find it a bit curious that a -dev package depends on a python module, but
> then again we seem to be dealing with something closely related to python
> here.

It's a bit curious for me too; double checking the source code
and shared objects relations, I believe libvtkDICOMPython*.so
only provides primitives for the Python module, which are not
relevant for the C++ VTK DICOM libraries, so probably not for
headers as well.

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


signature.asc
Description: PGP signature

Bug#988980: xfce4-mailwatch-plugin: memory leak with POP3

[Michael]

Package: xfce4-mailwatch-plugin
Version: 1.3.0-1
Severity: normal

I am using xfce4-mailwatch-plugin to check 3 POP3 mailboxes once per minute.
Here the output of 'ps -eo vsz,rsz,comm | grep mail' at three different times:

3942760 59948 panel-7-mailwat
3942760 59988 panel-7-mailwat
3967348 60028 panel-7-mailwat

Because I am not performing regular shutdowns/logouts this is a real problem.
After some days mailwatch has allocated more than 1GB resident memory!

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

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

Versions of packages xfce4-mailwatch-plugin depends on:
ii  libc62.31-12
ii  libexo-2-0   4.16.0-1
ii  libgdk-pixbuf2.0-0   2.40.2-2
ii  libglib2.0-0 2.66.8-1
ii  libgnutls30  3.7.1-3
ii  libgtk-3-0   3.24.24-4
ii  libxfce4panel-2.0-4  4.16.2-1
ii  libxfce4ui-2-0   4.16.0-1
ii  libxfce4util74.16.0-1

xfce4-mailwatch-plugin recommends no packages.

xfce4-mailwatch-plugin suggests no packages.

-- no debconf information

Bug#988643: [RFS] vtk-dicom/0.8.12-3

[Andreas Beckmann]

On 22/05/2021 12.03, Étienne Mollier wrote:

consecutive to changes in multi-arch hints I had to bring per
lintian regression, I attempted to install concurrently the
package libvtk-dicom-dev both in native and foreign
architecture, and it would now fail with the following:


I'd leave out the M-A: same, that is usually not considered appropriate 
during the freeze. Especially if it does not lead to a M-A 
co-installable package.

This should be fixed for bookworm.

I find it a bit curious that a -dev package depends on a python module, 
but then again we seem to be dealing with something closely related to 
python here.


Andreas

Bug#988549: Comments and questions resulting from Debian team comments and directives re: big report

[o1bigtenor]

Greetings

After subsequent reboot only one 0.14 item left and its for visual
properties - - - - I don't think its going to be an issue.

Absolutely love the condescension in the priority level change.
I find something that my system lists as a bug (dmesg info) with the
issue being found because my system has been rendered unusable needing
a reboot to clear and its priority is  classified as 'low'.

Seems like those reading bug reports only find things critical that
take down their systems.

Oh well - - - - seems the way of the world.

(By the way - - - - this kind of reaction and behavior is
'tremendously' encouraging re:continuing or new bug reporting. Seems
like the M$ attitude is permeating Debian.)

Can I assume that there is no interest in me posting any further
results re: this issue?

Please advise

Bug#988979: libwww-perl: Peculiar 308 Permanent redirect causes LWP::UserAgent to return an error

[Dominic Sweetman]

Package: libwww-perl
Version: 6.36-2
Severity: important

Dear Maintainer,


I'm using LWP::UserAgent to fetch json information: the page
https://www.radiotimes.com/film/g6j5ty/well-meet-again is showing the failure
today.

This results in a "308 Permanent redirect".  Using wget suggests that the
redirect is just the original URL with a '/' at the end.

But LWP::UserAgent returns with is_success false, and the response request->uri
method returns the original URL without the '/'.

A hack of detecting the combination of status 308 and an unchanged URL and
manually attaching a '/' has got it working again, but hardly seems correct.

It would seem more consistent with the way LWP::UserAgent handles redirects to
perform the redirect, while reporting the redirect target correctly through the
response request->uri method.




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

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

Versions of packages libwww-perl depends on:
ii  ca-certificates 20200601~deb10u2
ii  libencode-locale-perl   1.05-1
ii  libfile-listing-perl6.04-1
ii  libhtml-parser-perl 3.72-3+b3
ii  libhtml-tagset-perl 3.20-3
ii  libhtml-tree-perl   5.07-2
ii  libhttp-cookies-perl6.04-1
ii  libhttp-date-perl   6.02-1
ii  libhttp-message-perl6.18-1
ii  libhttp-negotiate-perl  6.01-1
ii  liblwp-mediatypes-perl  6.02-1
ii  liblwp-protocol-https-perl  6.07-2
ii  libnet-http-perl6.18-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.76-1
ii  libwww-robotrules-perl  6.02-1
ii  netbase 5.6
ii  perl5.28.1-6+deb10u1

Versions of packages libwww-perl recommends:
ii  libdata-dump-perl1.23-1
ii  libhtml-form-perl6.03-1
ii  libhtml-format-perl  2.12-1
ii  libhttp-daemon-perl  6.01-3
ii  libmailtools-perl2.18-1

Versions of packages libwww-perl suggests:
pn  libauthen-ntlm-perl  

-- no debconf information

Bug#988978: apispec: please make the build reproducible

[Chris Lamb]

forwarded 988978 https://github.com/marshmallow-code/apispec/pull/669
thanks

I've forwarded this upstream here:

  https://github.com/marshmallow-code/apispec/pull/669


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#988978: apispec: please make the build reproducible

[Chris Lamb]

Source: apispec
Version: 3.3.1-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
apispec could not be built reproducibly.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.patch   1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/reproducible-build.patch   2021-05-22 11:37:22.740539535 
+0100
@@ -0,0 +1,30 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2021-05-22
+
+--- apispec-3.3.1.orig/docs/conf.py
 apispec-3.3.1/docs/conf.py
+@@ -1,6 +1,7 @@
+ import datetime as dt
+ import os
+ import sys
++import time
+ 
+ sys.path.insert(0, os.path.abspath(os.path.join("..", "src")))
+ import apispec  # noqa: E402
+@@ -23,10 +24,14 @@ intersphinx_mapping = {
+ 
+ issues_github_path = "marshmallow-code/apispec"
+ 
++build_date = dt.datetime.utcfromtimestamp(
++int(os.environ.get('SOURCE_DATE_EPOCH', time.time()))
++)
++
+ source_suffix = ".rst"
+ master_doc = "index"
+ project = "apispec"
+-copyright = "Steven Loria {:%Y}".format(dt.datetime.utcnow())
++copyright = "Steven Loria {:%Y}".format(build_date)
+ 
+ version = release = apispec.__version__
+ 
--- a/debian/patches/series 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/series 2021-05-22 11:37:21.668527250 +0100
@@ -0,0 +1 @@
+reproducible-build.patch

Bug#988947: redis configuration does not load fragments by default

[Chris Lamb]

tags 988947 + upstream
thanks

> 3) it's not clear to me whether wildcard can actually currently be 
> specified in the include statement. If they currently cannot be 
> specified, please patch the code to glob using the pattern specified in 
> the include, instead of targeting an individual file.

Redis does not currently support this. Can you therefore file a
request with upstream?


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#988643: [RFS] vtk-dicom/0.8.12-3

[Étienne Mollier]

Greetings fellow maintainers,

I brought a few changes to vtk-dicom to address the remaining RC
bug #988643.  Changes are available on Salsa for review[1].  You
will find a debdiff against the version in bullseye attached.  I
did a few tests to make sure the issue is corrected, such as:
  - running the script Testing/TestDICOMPython.py to make sure
I introduced no regressions in the Python module;
  - running piuparts --fail-on-broken-symlinks to make sure the
issue was effectively fixed for vtk-dicom binary packages;
  - the usual build and (superficial) autopkgtest.

I did not leave the symlink in dist-packages/ because
libvtkDICOMPython*.so is not an importable Cython module (after
trying a import within Python), but a library used by the Cython
module vtkDICOMPython*.so (per `objdump -p` output).  However,
consecutive to changes in multi-arch hints I had to bring per
lintian regression, I attempted to install concurrently the
package libvtk-dicom-dev both in native and foreign
architecture, and it would now fail with the following:

# apt install libvtk-dicom-dev:i386
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 python3-vtk7:i386 : Depends: python3-autobahn:i386 but it is not 
installable
 Depends: python3-mpi4py:i386 but it is not going 
to be installed
 Depends: python3-twisted:i386 but it is not 
installable
E: Unable to correct problems, you have held broken packages.

Please let me know how much it is a concern as we are in hard
freeze, in which case an alternative approach might simply be to
not install the symlink libvtkDICOMPython*.so at all.  If it
seems otherwise alright, I will restore the git tag, and feel
free to sponsor upload, or proceed to DM grants as you see most
suitable.

[1]: https://salsa.debian.org/med-team/vtk-dicom

Thanks Andreas Beckmann for all your QA tests!

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/tty1, please excuse my verbosity.
diff -Nru vtk-dicom-0.8.12/debian/changelog vtk-dicom-0.8.12/debian/changelog
--- vtk-dicom-0.8.12/debian/changelog	2019-12-22 14:42:19.0 +0100
+++ vtk-dicom-0.8.12/debian/changelog	2021-05-21 23:33:15.0 +0200
@@ -1,3 +1,23 @@
+vtk-dicom (0.8.12-3) unstable; urgency=medium
+
+  * Team upload.
+  * Mark python3-vtk-dicom Multi-Arch: same.
+  * Make libvtk-dicom-dev depend on python3-vtk-dicom.
+  * Move libvtkDICOMPython*.so from /usr/lib/python3/dist-packages to
+/usr/lib/, and from python3-vtk-dicom to libvtk-dicom-dev:
+this whole dance repairs a broken symlink with limited side regressions.
+Closes: #988643
+
+ -- Étienne Mollier   Fri, 21 May 2021 23:33:15 +0200
+
+vtk-dicom (0.8.12-2) unstable; urgency=medium
+
+  * Team upload.
+  * Fix autopkgtest.  Thanks for the patch to Étienne Mollier.
+Closes: #988745
+
+ -- Andreas Tille   Wed, 19 May 2021 15:30:05 +0200
+
 vtk-dicom (0.8.12-1) unstable; urgency=medium
 
   * New upstream version 0.8.12
diff -Nru vtk-dicom-0.8.12/debian/control vtk-dicom-0.8.12/debian/control
--- vtk-dicom-0.8.12/debian/control	2019-12-22 14:42:19.0 +0100
+++ vtk-dicom-0.8.12/debian/control	2021-05-21 21:20:12.0 +0200
@@ -25,6 +25,7 @@
 Multi-Arch: same
 Section: libdevel
 Depends: libvtkdicom0.8 (= ${binary:Version}),
+ python3-vtk-dicom (= ${binary:Version}),
  ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
 Breaks: libvtk-dicom0.7-dev,
@@ -84,6 +85,7 @@
  ${misc:Depends},
  ${shlibs:Depends}
 Provides: ${python3:Provides}
+Multi-Arch: same
 Description: DICOM for VTK - Python
  This package contains a set of classes for managing DICOM
  files and metadata from within VTK, and some utility programs
diff -Nru vtk-dicom-0.8.12/debian/libvtk-dicom-dev.install vtk-dicom-0.8.12/debian/libvtk-dicom-dev.install
--- vtk-dicom-0.8.12/debian/libvtk-dicom-dev.install	2019-12-22 14:42:19.0 +0100
+++ vtk-dicom-0.8.12/debian/libvtk-dicom-dev.install	2021-05-21 20:26:37.0 +0200
@@ -1,5 +1,6 @@
 usr/include/*
 usr/lib/*/libvtkDICOM.so 
+usr/lib/*/libvtkDICOMPython*.so
 usr/lib/*/cmake/*
 
 
diff -Nru vtk-dicom-0.8.12/debian/python3-vtk-dicom.install vtk-dicom-0.8.12/debian/python3-vtk-dicom.install
--- vtk-dicom-0.8.12/debian/python3-vtk-dicom.install	2019-12-22 14:42:19.0 +0100
+++ vtk-dicom-0.8.12/debian/python3-vtk-dicom.install	2021-05-21 20:26:24.0 +0200
@@ -1,5 +1,4 @@
 

Bug#988977: buster-pu: package libbusiness-us-usps-webtools-perl/1.122-1+deb10u1

[Yadd]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: debian-p...@lists.debian.org

[ Reason ]
USPS is sending notices that HTTP access will be turned off shortly, in
favor of HTTPS.

Given that is a web service that will break in the wild, in addition to
a regular update for unstable, we should update buster (and stretch)
via stable-updates (and oldstable-updates).

[ Impact ]
libbusiness-us-usps-webtools-perl will be unusable after June 24th,
2021.

[ Tests ]
(What automated or manual tests cover the affected code?)

[ Risks ]
Patch is a backport of 1.124 -> 1.125 adapted for 1.122. Even if there
is a little risk (since I'm not able to fully test it), not updating
this package is a more elevated risk.

[ 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

[ Changes ]
API change

Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index 3a65ac0..964b422 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+libbusiness-us-usps-webtools-perl (1.122-1+deb10u1) buster; urgency=medium
+
+  * Update to new US-USPS API (Closes: #988330)
+
+ -- Yadd   Sat, 22 May 2021 12:17:01 +0200
+
 libbusiness-us-usps-webtools-perl (1.122-1) unstable; urgency=medium
 
   [ gregor herrmann ]
diff --git a/debian/patches/series b/debian/patches/series
index 38edaa7..4562936 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 spelling-errors.patch
+update-us-usps-webtools-to-https.patch
diff --git a/debian/patches/update-us-usps-webtools-to-https.patch 
b/debian/patches/update-us-usps-webtools-to-https.patch
new file mode 100644
index 000..7269fd1
--- /dev/null
+++ b/debian/patches/update-us-usps-webtools-to-https.patch
@@ -0,0 +1,307 @@
+Description: update due to US-USPS changes
+Author: Xavier Guimard 
+Forwarded: not-needed
+Last-Update: 2021-05-21
+
+--- a/lib/Business/US/USPS/WebTools.pm
 b/lib/Business/US/USPS/WebTools.pm
+@@ -41,7 +41,7 @@
+ =cut
+ 
+ my $LiveServer = "production.shippingapis.com";
+-my $TestServer = "testing.shippingapis.com";
++my $TestServer = "stg-production.shippingapis.com";
+ 
+ =item new( ANONYMOUS_HASH )
+ 
+@@ -123,7 +123,7 @@
+   $_[0]->_live ?
+   "/ShippingAPI.dll"
+   :
+-  "/ShippingAPITest.dll"
++  "/ShippingAPI.dll"
+   }
+ 
+ sub _make_query_string {
+@@ -145,7 +145,7 @@
+ sub _make_url {
+   my( $self, $hash ) = @_;
+ 
+-  $self->{url} = qq|http://| . $self->_api_host . $self->_api_path .
++  $self->{url} = qq|https://| . $self->_api_host . $self->_api_path .
+   "?" . $self->_make_query_string( $hash );
+   }
+ 
+--- a/t/address_verification.t
 b/t/address_verification.t
+@@ -21,23 +21,35 @@
+   "environment variables to run these tests\n";
+   }
+ 
++my $is_testing = uc($ENV{USPS_WEBTOOLS_ENVIRONMENT}) eq 'TESTING';
++
+ # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # 
#
+ use_ok( $class );
+ 
+ my $verifier;
+-my $base = 
qq|http://testing.shippingapis.com/ShippingAPITest.dll?API=Verify=%3CAddressValidateRequest+USERID%3D%22$ENV{USPS_WEBTOOLS_USERID}%22+PASSWORD%3D%22$ENV{USPS_WEBTOOLS_PASSWORD}%22%3E%3CIncludeOptionalElements%3Etrue%3C%2FIncludeOptionalElements%3E%3CReturnCarrierRoute%3Etrue%3C%2FReturnCarrierRoute%3E|;
++
++my $base = 'https://' . ($is_testing ? 'stg-' : '') . 
qq|production.shippingapis.com/ShippingAPI.dll?API=Verify=%3CAddressValidateRequest+USERID%3D%22$ENV{USPS_WEBTOOLS_USERID}%22+PASSWORD%3D%22$ENV{USPS_WEBTOOLS_PASSWORD}%22%3E%3CIncludeOptionalElements%3Etrue%3C%2FIncludeOptionalElements%3E%3CReturnCarrierRoute%3Etrue%3C%2FReturnCarrierRoute%3E|;
+ 
+ subtest setup => sub {
+   $verifier = $class->new( {
+   UserID   => $ENV{USPS_WEBTOOLS_USERID},
+   Password => $ENV{USPS_WEBTOOLS_PASSWORD},
+-  Testing  => 1,
++Testing  => $is_testing,
+   } );
+   isa_ok( $verifier,  $class );
+ 
+   can_ok( $verifier, $method );
+   };
+ 
++=pod
++
++2021-05-19: This test is failing because the API is no longer returning the
++expected output; it now includes the following warning:
++
++Default address: The address you entered was found but more information is
++needed (such as an apartment, suite, or box number) to match to a specific
++address.
++
+ # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # 
#
+ # Good response #1
+ subtest good_response_1 => sub {
+@@ -81,6 +93,8 @@
+   is( $hash->{Zip4}, '1441',  'Zip4 matches for 
Ivy Lane' );
+   };
+ 
++=cut
++
+ # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # 
#
+ # Good response #2
+ subtest good_response_1 => 

Bug#988976: apt-cacher-ng: Fix for reproducible build with varying locale

[Roland Clobus]

Package: apt-cacher-ng
Version: 3.6.3-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: locale
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org


Hello Eduard,

I'm rebuilding apt-cacher-ng with reprotest:

$ git status
On branch debian/sid

$ reprotest apt-cacher-ng_3.6.3-1.dsc --variations=+all,-build_path

The locale variation sets LANG, LC_ALL and LANGUAGE to a randomly selected
locale from a list.
When the value 'fr_CH.UTF-8' is selected, the Makefile in dbgen attempts to
detect whether a reproducible build should be attempted. However, setting
LANG=C for tar still shows the French help text. With LC_ALL=C the English help
is always shown. See the attached patch.

With kind regards,
Roland Clobus

PS: I'm also looking at the build_path variation


-- Package-specific info:

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

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

Versions of packages apt-cacher-ng depends on:
ii  adduser  3.118
ii  debconf [debconf-2.0]1.5.75
ii  dpkg 1.20.9
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-12
ii  libevent-2.1-7   2.1.12-stable-1
ii  libevent-pthreads-2.1-7  2.1.12-stable-1
ii  libgcc-s110.2.1-6
ii  liblzma5 5.2.5-2
ii  libssl1.11.1.1k-1
ii  libstdc++6   10.2.1-6
ii  libsystemd0  247.3-5
ii  libwrap0 7.6.q-31
ii  lsb-base 11.1.0
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages apt-cacher-ng recommends:
ii  ca-certificates  20210119

Versions of packages apt-cacher-ng suggests:
ii  avahi-daemon  0.8-5
pn  doc-base  
ii  libfuse2  2.9.9-5

-- Configuration Files:
/etc/apt-cacher-ng/acng.conf changed:
CacheDir: /media/data/apt-cacher-ng
LogDir: /var/log/apt-cacher-ng
SupportDir: /usr/lib/apt-cacher-ng
Remap-debrep: file:deb_mirror*.gz /debian ; file:backends_debian # Debian 
Archives
Remap-uburep: file:ubuntu_mirrors /ubuntu ; file:backends_ubuntu # Ubuntu 
Archives
Remap-klxrep: file:kali_mirrors /kali ; file:backends_kali # Kali Linux Archives
Remap-cygwin: file:cygwin_mirrors /cygwin # ; file:backends_cygwin # 
incomplete, please create this file or specify preferred mirrors here
Remap-sfnet:  file:sfnet_mirrors # ; file:backends_sfnet # incomplete, please 
create this file or specify preferred mirrors here
Remap-alxrep: file:archlx_mirrors /archlinux # ; file:backend_archlx # Arch 
Linux
Remap-fedora: file:fedora_mirrors # Fedora Linux
Remap-epel:   file:epel_mirrors # Fedora EPEL
Remap-slrep:  file:sl_mirrors # Scientific Linux
Remap-gentoo: file:gentoo_mirrors.gz /gentoo ; file:backends_gentoo # Gentoo 
Archives
Remap-secdeb: security.debian.org security.debian.org/debian-security 
deb.debian.org/debian-security /debian-security ; 
deb.debian.org/debian-security security.debian.org
ReportPage: acng-report.html
ExThreshold: 4
VfilePatternEx: /project/trace/ftp-master\.debian\.org$
LocalDirs: acng-doc /usr/share/doc/apt-cacher-ng

/etc/apt-cacher-ng/security.conf [Errno 13] Permission denied: 
'/etc/apt-cacher-ng/security.conf'

-- debconf information:
* apt-cacher-ng/tunnelenable: false
* apt-cacher-ng/proxy: keep
* apt-cacher-ng/bindaddress: keep
* apt-cacher-ng/gentargetmode: Set up now and update later
* apt-cacher-ng/cachedir: /media/data/apt-cacher-ng
* apt-cacher-ng/port: keep

-- debsums errors found:
debsums: changed file /lib/systemd/system/apt-cacher-ng.service (from 
apt-cacher-ng package)
diff --git a/dbgen/Makefile b/dbgen/Makefile
index c149964..e2466f3 100644
--- a/dbgen/Makefile
+++ b/dbgen/Makefile
@@ -118,10 +118,10 @@ TARARGS += --mtime=@1
 else
 TARARGS += --mtime=@$(SOURCE_DATE_EPOCH)
 endif
-ifneq ($(shell LANG=C tar --help | grep clamp-mtime),)
+ifneq ($(shell LC_ALL=C tar --help | grep clamp-mtime),)
 TARARGS += --clamp-mtime
 endif
-ifneq ($(shell LANG=C tar --help | grep "sort.*name"),)
+ifneq ($(shell LC_ALL=C tar --help | grep "sort.*name"),)
 TARARGS += --sort=name
 endif
 

Bug#988975: bash-completion: Wrong completion after some certain words such as TZ, TERM and LANG

[WHR]

Package: bash-completion
Version: 1:2.11-2
Severity: important
X-Debbugs-Cc: msl023...@gmail.com

This version has a bug that didn't exist in previous Debian release (Buster).
The completion becomes wrong after certain words; for exmaple I want to
search for word 'TERM' in a file, so I typed (^ indicates cursor position):

grep -F TERM 
 ^

however the completion here doesn't give the expected result, of listing
files in the working directory, but instead:

$ grep -F TERM 
Display all 1750 possibilities? (y or n)
9termhp2  screen.linux-m1
Etermhp236screen.linux-m1b
Eterm-256color   hp2382a  screen.linux-m2
Eterm-88colorhp2392   screen.minitel1
MtxOrb   hp2397a  screen.minitel1-nb
...

It appears that bash wrongly completed this as the TERM environmet variable,
which is obviously incorrect here.

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

Kernel: Linux 4.19.147-rivoreo-amd64 (SMP w/4 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: systemd (via /run/systemd/system)

-- no debconf information

Bug#988974: buster-pu: package fig2dev/1:3.2.7a-5+deb10u4

[Roland Rosenfeld]

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

I prepared an update for fig2dev 1:3.2.7a-5+deb10u3 to deb10u4, which
in the first time fixes CVE-2021-3561 (the security team doesn't
intend to create a DSA but redirected me here).

Additionally it fixes four other buffer overflows, that are all fixed
upstream and I backported the fixes.

Last I added a mechanism, that rebuilds the testsuite (used at build
time as well as in autopkgtest) to activate the tests that are added
by the above patches.

The salsa pipeline succeeded on this:
https://salsa.debian.org/debian/fig2dev/-/pipelines/256545

A diff against 3.2.7a-5+deb10u3 is attached.

Greetings
Roland

-- System Information:
Debian Release: 10.9
  APT prefers stable
  APT policy: (500, 'stable'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-16-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf-8, LC_CTYPE=de_DE.utf-8 (charmap=UTF-8), 
LANGUAGE=de_DE:de:en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru fig2dev-3.2.7a/debian/changelog fig2dev-3.2.7a/debian/changelog
--- fig2dev-3.2.7a/debian/changelog	2020-01-07 19:53:09.0 +0100
+++ fig2dev-3.2.7a/debian/changelog	2021-05-22 11:20:55.0 +0200
@@ -1,3 +1,16 @@
+fig2dev (1:3.2.7a-5+deb10u4) buster; urgency=medium
+
+  * 44_CVE-2021-3561: Fix buffer overflow color definitions.  This fixes
+CVE-2021-3561.
+  * Rename gitlab.yml to salsa.yml to activate pipeline again.
+  * 45_polyline2polygon: Convert polygons having too few points to polylines.
+  * 46_arrow-poly: Remove arrows from polygon with single point.
+  * 47_trunc-subsuper: Allow truncated sub/superscripts in text.
+  * 48_arrow-point: Omit arrows without points in svg output.
+  * Rebuild testsuite during build and in autopkgtest.
+
+ -- Roland Rosenfeld   Sat, 22 May 2021 11:20:55 +0200
+
 fig2dev (1:3.2.7a-5+deb10u3) buster; urgency=medium
 
   * 42_CVE-2019-19746: Reject huge arrow types causing integer overflow.
diff -Nru fig2dev-3.2.7a/debian/gitlab-ci.yml fig2dev-3.2.7a/debian/gitlab-ci.yml
--- fig2dev-3.2.7a/debian/gitlab-ci.yml	2020-01-07 19:53:09.0 +0100
+++ fig2dev-3.2.7a/debian/gitlab-ci.yml	1970-01-01 01:00:00.0 +0100
@@ -1,7 +0,0 @@

-include:
-  - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
-  - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
-
-variables:
-  RELEASE: 'buster'
diff -Nru fig2dev-3.2.7a/debian/patches/44_CVE-2021-3561.patch fig2dev-3.2.7a/debian/patches/44_CVE-2021-3561.patch
--- fig2dev-3.2.7a/debian/patches/44_CVE-2021-3561.patch	1970-01-01 01:00:00.0 +0100
+++ fig2dev-3.2.7a/debian/patches/44_CVE-2021-3561.patch	2021-05-22 11:20:55.0 +0200
@@ -0,0 +1,61 @@
+From: Thomas Loimer 
+Date: Sun Apr 25 00:49:15 2021 +0200
+Bug: https://sourceforge.net/p/mcj/tickets/116/
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/fig2dev/+bug/1926677
+Applied-Upstream: https://sourceforge.net/p/mcj/fig2dev/ci/6827c09d2d6491cb2ae3ac7196439ff3aa791fd9/
+Subject: Sanitize color definitions, ticket #116 (CVE-2021-3561)
+
+--- a/fig2dev/read.c
 b/fig2dev/read.c
+@@ -539,30 +539,37 @@ read_colordef(char *line, int line_no)
+ 
+ 	if (num_usr_cols >= MAX_USR_COLS) {
+ 		if (num_usr_cols == MAX_USR_COLS) {
+-			put_msg("Maximum number of color definitions (%d) exceeded at line %d.",
++			put_msg("Maximum number of color definitions (%d) "
++	"exceeded at line %d.",
+ 	MAX_USR_COLS, line_no);
+ 			++num_usr_cols;
+ 		}
+ 		/* ignore additional colors */
+ 		return;
+ 	}
+-	if (sscanf(line, "%*d %d #%2x%2x%2x", , , , ) != 4) {
+-		if (c >= NUM_STD_COLS && c < NUM_STD_COLS + MAX_USR_COLS) {
+-			put_msg("Invalid color definition at line %d: %s, setting to black (#0).",
+-	line_no, line);
+-			r = g = b = 0;
+-		} else {
+-			put_msg("User color number at line %d out of range (%d), should be between %d and %d.",
++	if (sscanf(line, "%*d %d #%2x%2x%2x", , , , ) == 4) {
++		if (c >= NUM_STD_COLS && c < NUM_STD_COLS + MAX_USR_COLS &&
++r >=0 && r < 256 && g >=0 && g < 256 &&
++b >= 0 && b < 256 ) {
++			user_col_indx[num_usr_cols] = c;
++			user_colors[num_usr_cols].r = r;
++			user_colors[num_usr_cols].g = g;
++			user_colors[num_usr_cols].b = b;
++			++num_usr_cols;
++		} else if (c < NUM_STD_COLS || c >= NUM_STD_COLS+MAX_USR_COLS) {
++			put_msg("User color number at line %d out of range (%d)"
++	", should be between %d and %d.",
+ 	line_no, c, NUM_STD_COLS,
+ 	NUM_STD_COLS + MAX_USR_COLS - 1);
+-			return;
++		} else {
++			put_msg("Invalid color definition at line %d: %s, color"
++   " values must be between 0 through 255.",
++line_no, line);
+ 		}
++	} else {
++		put_msg("Invalid color definition 

Bug#988464: New mailing list: debian-enterprise

[Philip Wyett]

On Thu, 13 May 2021 19:23:13 + Mike Gabriel  wrote:
> HI Alex,
> 
> On  Do 13 Mai 2021 18:47:24 CEST, Alexander Wirt wrote:
> 
> > On Thu, May 13, 2021 at 04:33:47PM +0200, Mike Gabriel wrote:
> >> Package: lists.debian.org
> >> Severity: wishlist
> >> X-Debbugs-Cc: Raphael Hertzog , Sébastien  
> >> Delafond , Michael Prokop , Chris  
> >> Hofstaedtler , Christian Kastner 
> >>
> >> Dear list admins,
> >>
> >> Please provide a new discussion mailing list for people with focus  
> >> on enterprise usage of Debian.
> >>
> >> Name: debian-enterprise (@lists.d.o)
> >> Rationale:
> > What about https://lists.debian.org/debian-enterprise/ ?
> >
> > Alex
> 
> ah, interesting... I guess none of us ever really looked. Thanks and  
> sorry for the noise.
> 
> Mike
> -- 
> 
> mike gabriel aka sunweaver (Debian Developer)
> mobile: +49 (1520) 1976 148
> landline: +49 (4351) 486 14 27
> 
> GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
> mail: sunwea...@debian.org, http://sunweavers.net
> 

Hi,

I have tried twice over the last week to subscribe to this list. I get the 
"Subscription request
processed" page, but do not get a confirmation email to be actioned as 
expected. This leaves me not
knowing if the subscription has been processed at all.

Regards

Phil

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

WWW: https://kathenas.org

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#959493: (no subject)

[Raul Tambre]

Has an upstream issue been filed for this?

Bug#695246: what's the status of this?

[Russell Coker]

This happens on the latest Debian/Testing when booting a HP ML110 Gen9 with 
EFI, the screen goes gray and nothing happens when it tries to boot 
Memtest86+.

An example of GRUB code to not show the Memtest86+ menu item when booted from 
EFI was given, why can't that be used?

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#987963: [Debichem-devel] Bug#987963: pymol: flaky autopkgtest on arm64: hits autopkgtest timeout

[Michael Banck]

Hi,

On Sun, May 02, 2021 at 09:17:26PM +0200, Paul Gevers wrote:
> Run 'pymol -c
> /tmp/autopkgtest-lxc.q81vxtos/downtmp/build.HQz/src/examples/cookbook/scenes2movie.pml'...
> :1: DeprecationWarning: the imp module is deprecated in favour
> of importlib; see the module's documentation for alternative uses
> autopkgtest [04:22:04]: ERROR: timed out on command "su -s /bin/bash

Ok, so on closer look (and after inspecting the other ci.d.b failures),
it seems it always hangs on the above scenes2movie.pml script. I'm not
sure why, and I can't reproduce it on amdahl (at least not during half a
dozen runs), but as we skip about a dozen scripts so far already, I
suggest to just add this one to it.


Michael

Bug#988947: redis configuration does not load fragments by default

[Chris Lamb]

severity 988947 wishlist
retitle 988947 Support /etc/redis/redis.conf.d/* configuration files
thanks

Good idea. :)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#976147: [debian-mysql] Bug#988089: Bug#988089: mariadb-server: MariaDB uninstalled on dist-upgrade Debian 10 -> 11

[Olaf van der Spek]

Op vr 14 mei 2021 om 09:53 schreef Otto Kekäläinen :
> Investigating (0) galera-4:amd64 < none -> 26.4.7-3 @un uN Ib >
> Broken galera-4:amd64 Conflicts on galera-3:amd64 < 25.3.25-2 ->
> 25.3.31-2+b1 @ii umU Ib >
>   Considering galera-3:amd64 0 as a solution to galera-4:amd64 0
>   Holding Back galera-4:amd64 rather than change galera-3:amd64

I think here it should remove galera-3 rather than holding back galera4..



-- 
Olaf

Bug#987963: [Debichem-devel] Bug#987963: pymol: flaky autopkgtest on arm64: hits autopkgtest timeout

[Paul Gevers]

Hi Michael,

On 22-05-2021 09:57, Michael Banck wrote:
>> Your package has an autopkgtest, great. However, because of the failure
>> "caused" by glbic, 
> 
> Can you elaborate what you mean by that, is that related to pymol? Or
> are you saying that due to glbic (glibc?) failures, you had to look at
> all flaky tests and pymol was one of them?

The last one (I looked at all failures, glibc typically lets me find
flaky tests as they trigger so many tests), hence the caused between
quotes. And indeed a typo: glibc.

>> I looked into the history of your autopkgtest [1] and I noticed it
>> fails regularly on arm64 because it hits the autopkgtest timeout after
>> 2:47 hours.
>>
>> Because the unstable-to-testing migration software now blocks on
>> regressions in testing, flaky tests, i.e. tests that flip between
>> passing and failing without changes to the list of installed packages,
>> are causing people unrelated to your package to spend time on these
>> tests.
> 
> Well I'm going to try to take a look, but this apparently being
> arm64-specific won't make it easier.

If I can help by extracting extra information from a failing run in one
of arm64 workers, don't hesitate to tell me/us what you would need.
Also, you could upload to experimental with extra debugging options (and
potentially store stuff in the artifacts) and re-trigger the britney
created runs for the pseudo excuses until you hit the failure mode.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#988972: kde-plasma-desktop missing systemsettings, kwin-x11 and other dependencies

[Felicia Pacifica]

Package: kde-plasma-desktop
Version: 5:111
Severity: important

Dear Maintainer,

On a fresh install install of Bullseye the kde-plasma-desktop
metapackage was installed as per information at
https://wiki.debian.org/KDE   kde-plasma-desktop was chosen as the most
minimal option for installing KDE.

However kwin-x11 is not installed which results in windows not having
titlebars and borders.  And systemsettings is not installed which
results in there being no System Settings application to configure KDE.

Other components are also missing as the following sections in
systemsettings, after systemssettings was manually installed, are not working: 
Global Theme, Plasma Style, Colors, Icons, and Cursors.





-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: i386 (i686)

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

Versions of packages kde-plasma-desktop depends on:
ii  kde-baseapps  4:20.12.0+5.111
ii  plasma-desktop4:5.20.5-4
ii  plasma-workspace  4:5.20.5-6
ii  udisks2   2.9.2-2
ii  upower0.99.11-2

Versions of packages kde-plasma-desktop recommends:
ii  kwin-x11  4:5.20.5-1
ii  sddm  0.19.0-3
ii  xserver-xorg  1:7.7+22

Versions of packages kde-plasma-desktop suggests:
pn  kdeconnect  

-- no debconf information

Bug#988963: upgrade-reports: upgrade process requires a second "apt full-upgrade"

[Paul Gevers]

Oops, one wrong address, re-sending.

On 22-05-2021 09:52, Paul Gevers wrote:
> Control: severity 988003 normal
> Control: merge -1 988003
> Control: affects -1 release-notes guile-2.2
> 
> Hi Apt maintainers, Rob,
> 
> On 21-05-2021 23:47, Vagrant Cascadian wrote:
>> Package: upgrade-reports
>> Severity: normal
>> X-Debbugs-Cc: vagr...@debian.org
>>
>> On numerous systems I have upgraded recently, the process of:
>>
>>   apt upgrade --without-new-pkgs
>>   apt full-upgrade
>>
>> Results in at least one package (guile-2.2-libs, zile, sometimes others)
>> in an un-upgraded state.
>>
>> Running a second "apt full-upgrade" seems to take care of the issue.
>>
>> Maybe upgrading apt in-between "apt upgrade --without-new-pkgs" and "apt
>> full-upgrade" would resolve the issue?
> 
> This is the second report we receive about buster to bullseye upgrades
> leaving some packages in a non-upgraded state with the recommended
> upgrade procedure. Both reports involve guile-2.2-libs. Does any of you
> see why that could happen? Is this something we should worry about? Do
> we need to update the release notes update procedure (is apt upgrade and
> apt full-upgrade not enough) or is this the fault of guile-2.2-libs or
> apt? I tend to think there is probably a complex relation preventing apt
> to do the rigth thing in one go, but as the upgrade happens after a
> second run, apparently it's not really blocking
> 
> Paul
> 



OpenPGP_signature
Description: OpenPGP digital signature

Bug#988963: upgrade-reports: upgrade process requires a second "apt full-upgrade"

[Paul Gevers]

Control: severity 988003 normal
Control: merge -1 988003
Control: affects -1 release-notes guile-2.2

Hi Apt maintainers, Rob,

On 21-05-2021 23:47, Vagrant Cascadian wrote:
> Package: upgrade-reports
> Severity: normal
> X-Debbugs-Cc: vagr...@debian.org
> 
> On numerous systems I have upgraded recently, the process of:
> 
>   apt upgrade --without-new-pkgs
>   apt full-upgrade
> 
> Results in at least one package (guile-2.2-libs, zile, sometimes others)
> in an un-upgraded state.
> 
> Running a second "apt full-upgrade" seems to take care of the issue.
> 
> Maybe upgrading apt in-between "apt upgrade --without-new-pkgs" and "apt
> full-upgrade" would resolve the issue?

This is the second report we receive about buster to bullseye upgrades
leaving some packages in a non-upgraded state with the recommended
upgrade procedure. Both reports involve guile-2.2-libs. Does any of you
see why that could happen? Is this something we should worry about? Do
we need to update the release notes update procedure (is apt upgrade and
apt full-upgrade not enough) or is this the fault of guile-2.2-libs or
apt? I tend to think there is probably a complex relation preventing apt
to do the rigth thing in one go, but as the upgrade happens after a
second run, apparently it's not really blocking

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#988968: unblock: e17/0.24.2-6

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2021-05-21 22:23:20 -0700, Ross Vandegrift wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: rvandegr...@debian.org
> 
> Please unblock package e17
> 
> [ Reason ]
> 
> 0.24.2-6 recommends libddcutil2, which has been replaced by libddcutil3.  
> 
> [ Impact ]
> 
> A non-existant package will be recommended.  Backlight controls for external 
> monitors won't work unless the user tries libddcutil3.
> 
> [ Tests ]
> 
> There are no automated tests.  I have used libddcutil3 without regression
> since uploading the change.

Are you sure?

/tmp/e17-0.24.2%% rgrep ddcutil\.so
src/bin/system/e_system_ddc.c:   ddc_lib = dlopen("libddcutil.so.2", RTLD_NOW | 
RTLD_LOCAL);

I don't see libddcutil.so.3 used anywhere.

Cheers

> 
> [ Risks ]
> 
> Low risk - e17 only builds leaf packages and the change is trivial.
> 
> [ Checklist ]
>   [x] all changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in testing
> 
> [ Other info ]
> 
> unblock e17/0.24.2-7

> diff -Nru e17-0.24.2/debian/changelog e17-0.24.2/debian/changelog
> --- e17-0.24.2/debian/changelog   2021-01-01 14:29:49.0 -0800
> +++ e17-0.24.2/debian/changelog   2021-05-02 22:02:56.0 -0700
> @@ -1,3 +1,10 @@
> +e17 (0.24.2-7) unstable; urgency=medium
> +
> +  * d/control: Recommend libddcutil3 instead of libddcutil2 which isn't in
> +bullseye
> +
> + -- Ross Vandegrift   Sun, 02 May 2021 22:02:56 -0700
> +
>  e17 (0.24.2-6) unstable; urgency=medium
>  
>* Recommend libddcutil2 and update NEWS with backlight control info
> diff -Nru e17-0.24.2/debian/control e17-0.24.2/debian/control
> --- e17-0.24.2/debian/control 2021-01-01 14:07:17.0 -0800
> +++ e17-0.24.2/debian/control 2021-05-02 21:57:47.0 -0700
> @@ -51,7 +51,7 @@
>   acpid,
>   bc,
>   bluez,
> - libddcutil2,
> + libddcutil3,
>   libevas-loaders,
>   packagekit,
>   terminology | x-terminal-emulator,


-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#987963: [Debichem-devel] Bug#987963: pymol: flaky autopkgtest on arm64: hits autopkgtest timeout

[Michael Banck]

Hi Paul,

On Sun, May 02, 2021 at 09:17:26PM +0200, Paul Gevers wrote:
> Source: pymol
> Version: 2.4.0+dfsg-1
> Severity: serious
> Tags: sid bullseye
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: flaky
> 
> Dear maintainer(s),
> 
> Your package has an autopkgtest, great. However, because of the failure
> "caused" by glbic, 

Can you elaborate what you mean by that, is that related to pymol? Or
are you saying that due to glbic (glibc?) failures, you had to look at
all flaky tests and pymol was one of them?

> I looked into the history of your autopkgtest [1] and I noticed it
> fails regularly on arm64 because it hits the autopkgtest timeout after
> 2:47 hours.
> 
> Because the unstable-to-testing migration software now blocks on
> regressions in testing, flaky tests, i.e. tests that flip between
> passing and failing without changes to the list of installed packages,
> are causing people unrelated to your package to spend time on these
> tests.

Well I'm going to try to take a look, but this apparently being
arm64-specific won't make it easier.


Michael

Bug#975911: mariadb-client: appears to ignore ~/.editrc keybind settings

[Olaf van der Spek]

Op za 22 mei 2021 om 04:27 schreef Trevor Cordes :
>
> On Thu, 26 Nov 2020 12:50:26 -0500 The Wanderer 
> wrote:
> Which means at one time this was fixed.  That's why this used to work
> for us.  But something must have regressed in the source, and the fix

MariaDB 10.3 uses libreadline-gplv2
MariaDB 10.5 uses libedit
I think this explains the changes in behavior.

-- 
Olaf

Bug#988619: Acknowledgement (unblock: kodi-pvr-mythtv/7.3.1+ds1-1)

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2021-05-18 08:38:47 +, Vasyl Gello wrote:
> This is a fixup release implementing seek feature.

Please go ahead and remove the moreinfo tag once the new version is
available in unstable.

Cheers

> -- 
> Vasyl Gello
> ==
> Certified SolidWorks Expert
> 
> Mob.:+380 (98) 465 66 77
> 
> E-Mail: vasek.ge...@gmail.com
> 
> Skype: vasek.gello
> ==
> 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature