Bug#987430: upgrade-reports: KDE Plasma without panels and without background after upgrade from Buster to Bullseye

[Norbert Preining]

Hi Malvin,

> > I have now upgraded three different machines from (fully updated) Buster
> > to Bullseye, and all three times KDE Plasma was not usable afterwards.

Interesting.

Do you know which set of packages you had installed? Which meta-package?

> > The problem goes away after reinstalling everything that is installed
> > and has "plasma" in the name, but unfortunately I cannot say which of

This is even stranger. Did you see **new** packages being installed
during the apt install --reinstall session?

Ah and yes, you did reboot before logging into the updated system,
right? Or did you do the update from a running Plasma session?

Best

Norbert

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

Bug#989033: equivs-build fails when multiple 'Links:' have the same filename

[Andrew Pam]

Package: equivs
Version: 2.2.0
Severity: normal

Dear Maintainer,

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


   * What led up to the situation?

   Using equivs to build a package that contains multiple 'Links:'
   values that reference the same target filename with different paths

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

   Example:

 Links: /var/lib/qmail/bin/sendmail /usr/sbin/sendmail
  ../sbin/sendmail /usr/lib/sendmail

   * What was the outcome of this action?

   equivs-build fails with 'File exists' error

   * What outcome did you expect instead?

   equivs-build should include all requested links

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


-- 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.8.0-54-generic (SMP w/16 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)

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

Versions of packages equivs depends on:
ii  debhelper  12.10ubuntu1
ii  dpkg-dev   1.19.7ubuntu3
ii  fakeroot   1.24-1
ii  make   4.2.1-1.2
ii  perl   5.30.0-9ubuntu0.2

equivs recommends no packages.

equivs suggests no packages.

-- no debconf information

--
mailto:and...@sericyb.com.au  Andrew Pam
https://sericyb.com.au/   Manager, Serious Cybernetics
https://glasswings.com.au/Partner, Glass Wings

Bug#987430: upgrade-reports: KDE Plasma without panels and without background after upgrade from Buster to Bullseye

[Paul Gevers]

Control: reassign -1 plasma-workspace

@ Qt/KDE maintainers: slightly random chosen reassignment

Hi Malvin,

Thanks for your report. Unfortunately it fell through the cracks for
some time. I have reassigned you bug report to one of the packages you
reported you reinstalled, I hope the Qt/KDE maintainers are better able
to triage than I am.

Paul

On 23-04-2021 20:56, Malvin Gattinger wrote:
> Package: upgrade-reports
> Severity: important
> 
> My previous release is: buster (fully updated)
> I am upgrading to: bullseye
> Archive date: Fri Apr 23 14:17:55 UTC 2021
> Upgrade date: Fri Apr 23 16:00:00 UTC 2021
> uname -a before upgrade: Linux hostname 4.19.0-16-amd64 #1 SMP Debian
> 4.19.181-1 (2021-03-19) x86_64 GNU/Linux
> uname -a after upgrade: Linux hostname 5.10.0-6-amd64 #1 SMP Debian
> 5.10.28-1 (2021-04-09) x86_64 GNU/Linux
> Method: apt upgrade --without-new-pkgs && apt full-upgrade
> 
> I have now upgraded three different machines from (fully updated) Buster
> to Bullseye, and all three times KDE Plasma was not usable afterwards.
> 
> Symptoms:
> - No panels are shown and instead of the desktop/background the screen
> is black.
> - Right-click on the desktop works, but the settings do not allow me to
> set a background image.
> - Pressing the super key opens the launcher menu, next to where the
> panel should be shown.
> - Alt+Tab works, kwin is running normally
> - krunner was unusable on two of the machines, but worked on the third.
> 
> I think the same problems was described by a reddit user here:
> https://www.reddit.com/r/debian/comments/li4vvc/debian_bullseye_has_entered_softfreeze/gnbp9up/?context=3
> 
> 
> WORKAROUND:
> The problem goes away after reinstalling everything that is installed
> and has "plasma" in the name, but unfortunately I cannot say which of
> those package reinstalls is actually doing the trick:
> 
> sudo apt install --reinstall kdeplasma-addons-data libkf5plasma5:amd64
> libkf5plasmaquick5:amd64 libplasma-geolocation-interface5
> libreoffice-plasma plasma-dataengines-addons:amd64 plasma-desktop
> plasma-desktop-data plasma-disks plasma-framework plasma-integration
> plasma-nm plasma-pa plasma-runners-addons:amd64
> plasma-wallpapers-addons:amd64 plasma-widgets-addons plasma-workspace
> plasma-workspace-data
> 
> 
> After this and logging out and back in, all of KDE Plasma works as normal.
> 



OpenPGP_signature
Description: OpenPGP digital signature

Bug#986728: upgrade-reports: boot fail until kernel 4.19.0.14

[Paul Gevers]

Control: reassign -1 linux

Hi Lamome,

Sorry it took so long to respond, but normally upgrade-reports as pseudo
package in the bts is used for upgrade reports from the current (or just
replaced) stable to the future (or just released) stable. I was confused
by your "version numbers" of linux as I didn't recognize them from
anywhere. However, I realized today that the linux version is different
than the version of the linux package.

I already pointed Salvatore at this bug over IRC long time ago, but I
guess that got lost. It's a bit late, but let's reassign this bug to the
package it probably belongs to.

On 10-04-2021 14:56, Lamome Julien wrote:
> Package: upgrade-reports
> Severity: critical
> Justification: breaks the whole system
> 
> Dear Maintainer,
> 
> 
>* What led up to the situation?
> try to boot on kernel 4.19.0-14 or 4.19.0-16
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> update kernel via aptitude
>* What was the outcome of this action?
>* What outcome did you expect instead?
> boot...
> 
> The boot fail (freeze, block) just after "initrd" print on screen.
> I notice that initrd of kernel ..14 and ..16 are bigger than other.
> 
> Thank
> 
> -- 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-9-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= 
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 




OpenPGP_signature
Description: OpenPGP digital signature

Bug#920404: (no subject)

[Pablo Mestre]

retitle 920404 ITA: rope -- Python refactoring library

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.

Bug#920404: ITA: rope -- Python refactoring library

[Pablo Mestre]

Package: wnpp
Severity: normal

Hello!

I would like to adopt this package.

Work has already been done at
https://salsa.debian.org/elMor3no-guest/rope

Format: 1.8
Date: Mon, 24 May 2021 02:06:44 -0300
Source: rope
Binary: python3-rope
Architecture: source all
Version: 0.19.0-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Python Team 
Changed-By: Pablo Mestre Drake 
Description:
 python3-rope - Python 3 refactoring library
Changes:
 rope (0.19.0-1) unstable; urgency=medium
 .
   [ Pablo Mestre Drake ]
   * New upstream version 0.19.0
   * Add salsa-ci.yml copied from Debian pipeline for Developers
   * debian/watch: Update parameters to check for newer versions
Checksums-Sha1:
 b73cf15a129d6170ae2b3f450752554f97c81c52 1132 rope_0.19.0-1.dsc
 7bc85c8029ff0d5776f704500bbf2e687579378b 252902 rope_0.19.0.orig.tar.gz
 308eb1aea011cfb0cef94b960e95c5a67e173634 3872 rope_0.19.0-1.debian.tar.xz
 c8b7ec9c344c14a4fa7d3ede0697d1b36b8b6608 137832 python3-rope_0.19.0-1_all.deb
 7e5f3ac0f3bee5210f395fadb3f47e968b4dcc70 5382 rope_0.19.0-1_amd64.buildinfo
Checksums-Sha256:
 e590d89a80d33cf5c742ea44a39d5633a2b11210bbf051a80dc7f9f5c43e00b2 1132 
rope_0.19.0-1.dsc
 64e6d747532e1f5c8009ec5aae3e5523a5bcedf516f39a750d57d8ed749d90da 252902 
rope_0.19.0.orig.tar.gz
 3214d6de2a0f4eaa7c3b17c1a2a6c875d1e4fede9c77315f1cc1bf0018211f20 3872 
rope_0.19.0-1.debian.tar.xz
 ac7423e4f7035590283bf3cfcb4aae922b61ecd9dfcf65257406ef6b5fae4823 137832 
python3-rope_0.19.0-1_all.deb
 312b271c796cd6b1c1a876ccd8b9ff9ff63a02cbb35fec9060921c9870f2710a 5382 
rope_0.19.0-1_amd64.buildinfo
Files:
 d337bf7373a8e79ab23dd72d734bf634 1132 devel optional rope_0.19.0-1.dsc
 8f844c0d5545b0034820074c1cd7ec10 252902 devel optional rope_0.19.0.orig.tar.gz
 dd0e2252025e9f5f67b7fb8fb479e2b0 3872 devel optional 
rope_0.19.0-1.debian.tar.xz
 bfc5d7d2b2d6dcbf18121ea015296959 137832 devel optional 
python3-rope_0.19.0-1_all.deb
 1d0a73b606204c920f7c5776efee06dc 5382 devel optional 
rope_0.19.0-1_amd64.buildinfo

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.

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

[Abi]

Hello again, thanks for responding.

My skills include:

 * An amateur understanding of Samba4 AD DC and file server. I manage a
   dozen or so installations ( addc and fs ), and I know how to spin up
   and manage installations as well as troubleshoot issues when they
   occur. I also read through the mailing list daily in order to have a
   better grasp possible issues.
 * Identifying warnings/errors from log output within code. I wouldn't
   call myself an advanced C or Python developer ( I mostly write
   golang/php ), however I should be able to look through the source
   code and trace issues based off the output reporters provide.

I'm also interested in debian packaging, but I know absolutely nothing 
apart from a few links I've read through. Would you be able to forward 
me some relevant reading so I'll be able to assist on that front ( if 
needed ) in the future?




By default, sending to n...@bugs.debian.org won't be sent to the submitter,
carefully read https://www.debian.org/Bugs/Developer#followup to ensure that
both submitter and maintainer (pkg-samba list) have the mail (nnn +
nnn-submitter)
I read through that section that you've linked and I think I understand. 
Since you are the maintainer and the person I am replying to, this 
message will actually get to you twice. However, if you were not a 
maintainer and just a user in the bug report I was replying to, you 
would receive this once. If I wanted to reply directly to the bug 
submitter and maintainer, I would tag 814...@bugs.debian.org ( so the 
maintainer receives it ) and 814382-submit...@bugs.debian.org ( so the 
submitter receives it ) - I'm assuming it will only be filed in the bug 
report once. Alternatively, couldn't I just send a reply to 
814...@bugs.debian.org and {submitter email address} ? or should I stick 
with nnn-submitter?



Debian's bug tracker is managed thru mails, you can look at
https://www.debian.org/Bugs/  and
https://www.debian.org/Bugs/server-control  to start with.
I've gone ahead and read through both links ( and the links within those 
links ), and I think I have a good understanding of the various 
levels/tags that should be assigned to a report and what the standard 
operating procedure is, as well as the control request server commands.



Tagging bugs and closing with the relevant version of the fix would help a lot!
Sure, where should I start? I looked through 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=samba#_0_4_4 
, and found: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765408 . 
I guess what needs to be changed is:


 * Tag set to fixed-upstream
 * Security level: important
 * Add wheezy tag

I'm assuming it's okay to close the bug report after that since the 
wheezy is EOL, and there is no hope for backporting?


Am I on the right track, or totally off?


Let me know if there's a particular system you'd like me to follow when 
triaging. I can start right away.



Thanks!


On 5/23/21 3:02 PM, Mathieu Parent wrote:

Le dim. 23 mai 2021 à 04:33, Abi  a écrit :

Hello Mathieu,

Hello Abi,


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.

Thanks for proposing your help.What are your skills?

Debian's bug tracker is managed thru mails, you can look at
https://www.debian.org/Bugs/ and
https://www.debian.org/Bugs/server-control to start with.

By default, sending to n...@bugs.debian.org won't be sent to the submitter,
carefully read https://www.debian.org/Bugs/Developer#followup to ensure that
both submitter and maintainer (pkg-samba list) have the mail (nnn +
nnn-submitter)

Tagging bugs and closing with the relevant version of the fix would help a lot!

On the test side, I have a WIP mrege request at:
https://salsa.debian.org/samba-team/samba/-/merge_requests/6

But we'll wait for bullseye to be released to start working on this.

If you know about Debian packaging, there other possible tasks.

Regards

Mathieu Parent

Bug#989025: unblock: micro-evtd/3.4-7

[Cyril Brulebois]

Paul Gevers  (2021-05-24):
> Control: tags -1 d-i confirmed
> 
> Hi kibi,
> 
> On 24-05-2021 00:42, Ryan Tandy wrote:
> > Please unblock package micro-evtd
> > 
> > [ Reason ]
> > 
> > Fix micro-evtd creating its pid and status files in /var/run with
> > world-writable permissions (#988119).
> > 
> > [ Impact ]
> > 
> > - The pid and status files in /var/run are mode 666, which could be a
> >  potential security issue.
> > - micro-evtd does not stop when asked to with "/etc/init.d/micro-evtd
> >  stop", because start-stop-daemon refuses to use the insecure pid file.
> > - Because of that, the daemon also does not restart on upgrade as it
> >  should, instead the old version remains running.
> > 
> > [ Tests ]
> > 
> > There are no automated tests. I manually tested the install and upgrade
> > cases (testing→unstable).
> > 
> > [ Risks ]
> > 
> > The change should be trivial, but it is possible (if unlikely) that I
> > missed some case where the umask 000 was actually needed.
> > 
> > [ Checklist ]
> >  [✓] all changes are documented in the d/changelog
> >  [✓] I reviewed all changes and I approve them
> >  [✓] attach debdiff against the package in testing
> > 
> > [ Other info ]
> > 
> > The package builds a udeb. I tested an installation using a d-i daily
> > build with the updated package included, and confirmed the corrected
> > file permissions in the d-i environment.
> 
> Your opinion too please.

The code change looks innocent enough, the postinst change doesn't
affect the udeb, and same comment as in #988083 regarding d-i having
been tested by Ryan → please go ahead.


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


signature.asc
Description: PGP signature

Bug#989025: unblock: micro-evtd/3.4-7

[Paul Gevers]

Control: tags -1 d-i confirmed

Hi kibi,

On 24-05-2021 00:42, Ryan Tandy wrote:
> Please unblock package micro-evtd
> 
> [ Reason ]
> 
> Fix micro-evtd creating its pid and status files in /var/run with
> world-writable permissions (#988119).
> 
> [ Impact ]
> 
> - The pid and status files in /var/run are mode 666, which could be a
>  potential security issue.
> - micro-evtd does not stop when asked to with "/etc/init.d/micro-evtd
>  stop", because start-stop-daemon refuses to use the insecure pid file.
> - Because of that, the daemon also does not restart on upgrade as it
>  should, instead the old version remains running.
> 
> [ Tests ]
> 
> There are no automated tests. I manually tested the install and upgrade
> cases (testing→unstable).
> 
> [ Risks ]
> 
> The change should be trivial, but it is possible (if unlikely) that I
> missed some case where the umask 000 was actually needed.
> 
> [ Checklist ]
>  [✓] all changes are documented in the d/changelog
>  [✓] I reviewed all changes and I approve them
>  [✓] attach debdiff against the package in testing
> 
> [ Other info ]
> 
> The package builds a udeb. I tested an installation using a d-i daily
> build with the updated package included, and confirmed the corrected
> file permissions in the d-i environment.

Your opinion too please.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#988740: unblock: glibc/2.31-12

[Paul Gevers]

Hi kibi,

On 24-05-2021 06:30, Cyril Brulebois wrote:
> Nothing dramatic, we'll be more explicit next time and pick an option
> for real instead of considering both options and letting one pick a
> favorite. :)

Let's agree on that indeed. It's a shame that we get into these
annoyances, while all we try to do is help each other.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#988740: unblock: glibc/2.31-12

[Cyril Brulebois]

Hi Paul,

Paul Gevers  (2021-05-20):
> On 20-05-2021 08:23, Cyril Brulebois wrote:
> > Having udeb-producing packages change under our feet when we're in
> > the middle of unentangling the rendering mess isn't exactly nice…
> 
> I'm terribly sorry, but I thought we discussed migrating udeb generating
> packages recently on IRC #d-release. I now realize that's a bit longer
> ago than I though. To quote you:
> 
> [00:00:00] - {Day changed to Monday, 26 April 2021}
> [22:06:17]  looks to me we have enough to fix and/or to debug on
> our plate that we won't be issuing another RC in a week or so, so
> freezing everyone (keeping everyone frozen) will only generate more
> requests for acks; at this stage, it's likely easier to let stuff
> migrate and deal with consequences afterward
> 
> I interpreted that as you are sort of fine at this moment if we
> migrated the packages if they are otherwise fine. We should have
> agreed on a schedule and it was on my TODO list to ask you today.

I'm a little too lazy to dig into IRC logs, but I'm pretty sure we had
two possibilities: either keep all udeb-producing frozen and deal with
individual requests; or lift the general block-udeb. Given nothing
changed in britney1.git since Apr 14, I seemed to me we went for d-i
acks (which I've tried to handle swiftly) and that's what got me
surprised for the glibc thing.

Nothing dramatic, we'll be more explicit next time and pick an option
for real instead of considering both options and letting one pick a
favorite. :)


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


signature.asc
Description: PGP signature

Bug#989027: kate: Kate hangs (approx 30 seconds) after reassign existing keyboard shortcut.

[Norbert Preining]

Hi

> 1. Settings -> Configure Keyboard Shortcuts
> 2. Search dup
> 3. Assign Duplicate Selected Lines Down to Ctrl+D
> 4. Accept warning about replacing existing usage of Ctrl+D.

At least with 21.04 I cannot reproduce this, kate returns immediatly.

Best

Norbert

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

Bug#983357: Netinst crashes xen domU when loading kernel

[Cyril Brulebois]

Hi Phillip,

And thanks for debugging this… I must confess I've never touched
anything Xen related and I'd like to keep it that way in the near
future. ;-)

Phillip Susi  (2021-05-19):
> The discussion upstream does not seem to be converging on a proper fix
> in the kernel, so I'm going to clone this bug and suggest that
> debian-installer patch the start-udev script to ignore the failure of
> the udevadm trigger command.
> 
> To summarize: init ends up calling start-udev which calls udevadm
> trigger to cold plug all devices.  Both scripts are set -e.  The Xen
> Virtual Keyboard driver and at least one other driver have always failed
> to trigger due to having absurdly long modalias, but the error used to
> be ignored.  The kernel now returns the error to udevadm, so it exits
> with an error, so start-udev exits with an error, so init exits with an
> error, causing the kernel to panic.

Well, it's a little more complicated:
 - start-udev is actually a script shipped by the udev udeb, i.e. the
   responsibility of systemd maintainers;
 - based on a quick grep, the installer contains two calls to that
   start-udev script, in the rootskel source package:
+ rootskel/src/init(shipped as /init in the udeb)
+ rootskel/src/sbin/init-linux (shipped as /sbin/init in the udeb)

I'd be happy to have a comment from systemd maintainers before thinking
about patching rootskel. :)


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


signature.asc
Description: PGP signature

Bug#987377: rescue-mode: when in graphical mode, locks up one prompt before the shell

[Cyril Brulebois]

Hi Étienne,

Étienne Mollier  (2021-04-28):
> Cyril Brulebois, on 2021-04-28 06:08:30 +0200:
> > Let's see if this helps!
> >   https://people.debian.org/~kibi/bug-987377/
> 
> According to my observations, I does help with all the known bad
> cases I have hit so far; I notably double checked the "Generic"
> partition schemes:
> 
>   Device   en_US  fr_FR
>   /dev/sdb1ok ok
>   /dev/nvme0n1p1   ok ok
>   /dev/md/0ok ok
>   /dev/debian-vg/root  ok ok
> 
> Just in case, the mini ISOs never booted EFI, and I never
> managed to get the ZBook to Bios boot USB thumbs.  So I had to
> carry out the NVMe test in a virtual machine to get some working
> Bios boot, and use PCI host passthrough on the second NVMe of
> the machine, to get it to be visible to the installer and rescue
> environment.  I don't believe it affected much the test results,
> but fyi, just in case it turned out it would make a difference.
> 
> > Also, thanks for all the tests so far, I've seen the follow-ups…
> > that's much appreciated (even if slightly frightening if the image
> > linked above doesn't make the problem go away altogether).
> 
> You're welcome, I hope the the above is reassuring.

I'm not sure whether you followed the recent developments on the
cdebconf and gtk+2.0 side, but we're slowly reaching a point where stuff
should just work again.

If you try daily builds (built against unstable), the problem should not
appear. Depending on which build you grab, it might still be affected by
#988951 (another cdebconf upload happened a few minutes, to avoid that
issue entirely).

Feel free to confirm! :)


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


signature.asc
Description: PGP signature

Bug#987368: Installer fails at first menu "Choose language"

[Cyril Brulebois]

Hi Frédéric,

Frédéric Bonnard  (2021-04-26):
> Thanks for willing to investigate !

Thanks for the detailed steps!

> LPAR setup in PowerVM can not be reproduced to my knowledge with qemu;
> this a partitioning configuration with PHYP proprietary firmware by
> IBM.  Using a ppc64el vm, I never had the issue, since I think, hvc0
> does not exist and thus does not create race condition with tty0. The
> last possible configuration providing hvc0 is the baremetal mode
> (PowerNV), installating a physical Power machine with linux on top of
> it.
> Hopefully, qemu is able to emulate a baremetal machine (PowerNV) as
> skiboot firmware is opensource (compared to PHYP).
> I tried and could reproduce the bug after 3 tries.
> 
> For this, on your amd64 machine :
> - install qemu-system-ppc 5.2 (in my case, using stable, I used 
> 1:5.2+dfsg-9~bpo10+1 )
> - get those :
>   * 
> https://openpower.xyz/job/openpower/job/openpower-op-build/label=slave,target=witherspoon/lastSuccessfulBuild/artifact/images/rootfs.cpio.xz
>   * 
> https://openpower.xyz/job/openpower/job/openpower-op-build/label=slave,target=witherspoon/lastSuccessfulBuild/artifact/images/zImage.epapr
> - use the following to emulate the P9 PowerNV Witherspoon machine :
>   qemu-system-ppc64 -m 2G -machine powernv9 -smp 8,cores=8,threads=1 \
> -accel tcg,thread=single \
> -device e1000e,netdev=net0,mac=C0:FF:EE:00:00:02,bus=pcie.0,addr=0x0  \
> -netdev user,id=net0,hostfwd=::20022-:22,hostname=pnv \
> -kernel ./zImage.epapr  \
> -initrd ./rootfs.cpio.xz \
> -nographic
> - Once you get into the petitboot menu, "Exit to shell"

Using a rather similar qemu package, but on bullseye (1:5.2+dfsg-10),
I'm not able to get to the petitboot menu:

kibi@tokyo:~/downloads$ qemu-system-ppc64 -m 2G -machine powernv9 -smp 
8,cores=8,threads=1 \
-accel tcg,thread=single \
-device e1000e,netdev=net0,mac=C0:FF:EE:00:00:02,bus=pcie.0,addr=0x0  \
-netdev user,id=net0,hostfwd=::20022-:22,hostname=pnv \
-kernel ./zImage.epapr  \
-initrd ./rootfs.cpio.xz \
-nographic
[0.015788836,5] OPAL v6.4 starting...
[0.016283111,7] initial console log level: memory 7, driver 5
[0.016319531,6] CPU: P9 generation processor (max 4 threads/core)
[0.016335507,7] CPU: Boot CPU PIR is 0x PVR is 0x004e1200
[0.016452461,7] OPAL table: 0x30110530 .. 0x30110aa0, branch table: 
0x30002000
[0.016622304,7] Assigning physical memory map table for nimbus
[0.016979537,7] FDT: Parsing fdt @0x100
[0.019592646,5] CHIP: Detected Qemu simulator
[0.019757972,6] CHIP: Initialised chip 0 from xscom@603fc
[0.020117574,6] P9 DD2.00 detected
[0.020142490,5] CHIP: Chip ID  type: P9N DD2.00
[0.020155985,7] XSCOM: Base address: 0x603fc
[0.020192159,7] XSTOP: ibm,sw-checkstop-fir prop not found
[0.020301881,6] MFSI 0:0: Initialized
[0.020313870,6] MFSI 0:2: Initialized
[0.020323201,6] MFSI 0:1: Initialized
[0.020848585,6] LPC: LPC[000]: Initialized
[0.020858725,7] LPC: access via MMIO @0x60300
[0.020894150,7] LPC: Default bus on chip 0x0
[0.020998003,7] CPU: New max PIR set to 0x1f
[0.021512680,7] MEM: parsing reserved memory from 
reserved-names/-ranges properties
[0.021609903,7] CPU: decrementer bits 56
[0.021668231,6] CPU: CPU from DT PIR=0x Server#=0x0 State=3
[0.021750145,6] CPU:  1 secondary threads
[0.021766340,6] CPU: CPU from DT PIR=0x0004 Server#=0x4 State=3
[0.021788849,6] CPU:  1 secondary threads
[0.021797000,6] CPU: CPU from DT PIR=0x0008 Server#=0x8 State=3
[0.021807120,6] CPU:  1 secondary threads
[0.021814202,6] CPU: CPU from DT PIR=0x000c Server#=0xc State=3
[0.021823785,6] CPU:  1 secondary threads
[0.021834496,6] CPU: CPU from DT PIR=0x0010 Server#=0x10 State=3
[0.021846219,6] CPU:  1 secondary threads
[0.021858600,6] CPU: CPU from DT PIR=0x0014 Server#=0x14 State=3
[0.021870856,6] CPU:  1 secondary threads
[0.021878195,6] CPU: CPU from DT PIR=0x0018 Server#=0x18 State=3
[0.021887826,6] CPU:  1 secondary threads
[0.021894705,6] CPU: CPU from DT PIR=0x001c Server#=0x1c State=3
[0.021904113,6] CPU:  1 secondary threads
[0.023185494,5] PLAT: Using SuperIO UART
[0.023483354,7] UART: Using LPC IRQ 4
[0.028248102,5] PLAT: Detected QEMU POWER9 platform
[0.028385817,5] PLAT: Detected BMC platform ast2500:openbmc
[0.059238262,5] CPU: All 8 processors called in...
[0.059731948,3] SBE: Master chip ID not found.
[0.060360004,7] LPC: Routing irq 10, policy: 0 (r=1)
[0.060430008,7] LPC: SerIRQ 10 using route 0 targetted at OPAL
[0.082669345,5] HIOMAP: Negotiated hiomap protocol v2
[0.082815227,5] HIOMAP: Block size is 4KiB
   

Bug#987441: debian-installer: D-I must get ready for Bullseye

[Cyril Brulebois]

Control: tag -1 - pending
Control: block -1 by 988951

Cyril Brulebois  (2021-04-25):
> Feel free to “nominate”/mention any other bug reports that seem worth
> considering. I've seen you went through a number of installation
> reports, and I'm pretty sure you have a better overview of the current
> state of things than I do.

Adjusting things a little:
 - I used the wrong bug number (it should have been #988951 instead) in
   this cdebconf commit, hence tagpending's tag addition that I'm
   reverting with this mail:
 
https://salsa.debian.org/installer-team/cdebconf/-/commit/40481682a6fa46c901f8a48d08804d7acd6b5328
 - Blocking this bug by #988951 to make sure we don't forget about it.

Of course, a lot of blocking bugs will go away once we let cdebconf
and gtk+2.0 migrate to testing. I haven't been able to run into issues
with that last cdebconf patch, so I'm quite confident we might be able
to forget about those issues entirely.


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


signature.asc
Description: PGP signature

Bug#963509: [Python-apps-team] Bug#963509: Bug#963509: prospector: Version 1.3.1 now available

[Sandro Tosi]

On Sun, May 23, 2021 at 9:20 PM  wrote:
> Hi Salman (2021.05.23_21:53:21_+)
> > Hi dear maintainers,
> >
> > I would be happy to give a hand to upgrade this package and its orphaned
> > dependencies. What can I do to help?
>
> Not sure which orphaned dependencies you are referring to, but this

pylint-django and pylint-plugin-utils by the looks of it

https://packages.qa.debian.org/p/prospector.html

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#989031: pius: NameError: name 'util' is not defined

[Louis-Philippe Véronneau]

Package: pius
Version: 3.0.0-2
Severity: important

Dear maintainer,

When I try to use pius to sign a key, I get this error:

foo@bar:~/foo$ pius -s $my_key $some_other_key

Welcome to PIUS, the PGP Individual UID Signer.

Would you like to automatically send the signed UIDs to their owners using
PGP/Mime encryption as you sign each one? yes
What email address should we send from? "f...@bar.org"
Traceback (most recent call last):
  File "/usr/bin/pius", line 365, in 
main()
  File "/usr/bin/pius", line 291, in main
util.check_email(parser, "-m", ans)
NameError: name 'util' is not defined

This error can be bypassed by usinbg the "-m" parameter instead of
relying on the command prompt to ask the email address.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



OpenPGP_signature
Description: OpenPGP digital signature

Bug#963509: [Python-apps-team] Bug#963509: prospector: Version 1.3.1 now available

[stefanor]

Hi Salman (2021.05.23_21:53:21_+)
> Hi dear maintainers,
> 
> I would be happy to give a hand to upgrade this package and its orphaned
> dependencies. What can I do to help?

Not sure which orphaned dependencies you are referring to, but this
package, and many of its dependencies are maintained under the umbrella
of the Debian Python Team. https://wiki.debian.org/Teams/PythonTeam

You can join the team, and help to maintain them. It looks like you have
some experience with Debian packaging? If so, apply to the team, and
start working on them. Upload sponsorship can be requested via IRC, the
team mailing list, or debian mentors.

I'm afraid that at this point prospector is not going to be part of the
upcoming Debian bullseye release, the best we can do is get it in shape
for bookworm.

Hope that helps,

SR

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

Bug#989023: buster-pu: package libmateweather/1.20.2-1+deb10u1

[Mike Gabriel]

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

After a tzdata buster-pu update, libmateweather started failing to build
from source.

+  * debian/patches:
++ Add 1001_adapt-to-timezone-namechange-for-America-Nuuk.patch. (Closes
+  #959545).

[ Reason ]
The cause for this FTBFS was a renamed timezone (America/Godthab ->
America/Nuuk).

[ Impact ]
FTBFS of libmateweather in buster.

[ Tests ]
Successful rebuild with the patch applied.

[ Risks ]
None.

[ 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 ]
The timezone has now been adjusted in libmateweather and the packages
succeeds to build again.

[ Other info ]
None
diff -Nru libmateweather-1.20.2/debian/changelog 
libmateweather-1.20.2/debian/changelog
--- libmateweather-1.20.2/debian/changelog  2019-01-05 21:43:21.0 
+0100
+++ libmateweather-1.20.2/debian/changelog  2021-05-23 22:11:16.0 
+0200
@@ -1,3 +1,12 @@
+libmateweather (1.20.2-1+deb10u1) buster; urgency=medium
+
+  [ Pablo Barciela ]
+  * debian/patches:
++ Add 1001_adapt-to-timezone-namechange-for-America-Nuuk.patch. (Closes
+  #959545).
+
+ -- Mike Gabriel   Sun, 23 May 2021 22:11:16 +0200
+
 libmateweather (1.20.2-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru 
libmateweather-1.20.2/debian/patches/1001_adapt-to-timezone-namechange-for-America-Nuuk.patch
 
libmateweather-1.20.2/debian/patches/1001_adapt-to-timezone-namechange-for-America-Nuuk.patch
--- 
libmateweather-1.20.2/debian/patches/1001_adapt-to-timezone-namechange-for-America-Nuuk.patch
   1970-01-01 01:00:00.0 +0100
+++ 
libmateweather-1.20.2/debian/patches/1001_adapt-to-timezone-namechange-for-America-Nuuk.patch
   2021-05-23 22:11:16.0 +0200
@@ -0,0 +1,29 @@
+From 354086a51ea676b6575dbb3ec62d749ec0a7c607 Mon Sep 17 00:00:00 2001
+From: rbuj 
+Date: Fri, 22 May 2020 20:19:57 +0200
+Subject: [PATCH] Locations: America/Godthab was renamed to America/Nuuk
+
+---
+ data/Locations.xml.in | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/data/Locations.xml.in
 b/data/Locations.xml.in
+@@ -6482,7 +6482,7 @@
+ -->
+   <_name>Danmarkshavn
+ 
+-
++
+   

Bug#989022: unblock: lomiri-download-manager/0.1.0-8

[Mike Gabriel]

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

Please unblock package lomiri-download-manager

[ Reason ]
QA tests with piuparts revealed a wrong library dependency for one of the
dev:pkgs.

[ Impact ]
Not big. Lomiri Download Manager is part of the Lomiri Operating Environment
which has not yet been packaged for Debian.

[ Tests ]
Manual checks of debian/control.

[ Risks ]
No risk, really. The bug is now fixed and piuparts should succeed with this
version.

[ 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 ]
None.

unblock lomiri-download-manager/0.1.0-8
diff -Nru lomiri-download-manager-0.1.0/debian/changelog 
lomiri-download-manager-0.1.0/debian/changelog
--- lomiri-download-manager-0.1.0/debian/changelog  2020-12-13 
20:45:29.0 +0100
+++ lomiri-download-manager-0.1.0/debian/changelog  2021-05-23 
22:01:37.0 +0200
@@ -1,3 +1,13 @@
+lomiri-download-manager (0.1.0-8) unstable; urgency=medium
+
+  * debian/control:
++ Fix D (liblomiri-upload-manager-common-dev):
+  liblomiri-upload-manager-common0 instead of
+  liblomiri-download-manager-common0. Thanks piuparts.
+  (Closes: #988808).
+
+ -- Mike Gabriel   Sun, 23 May 2021 22:01:37 +0200
+
 lomiri-download-manager (0.1.0-7) unstable; urgency=medium
 
   * debian/changelog:
diff -Nru lomiri-download-manager-0.1.0/debian/control 
lomiri-download-manager-0.1.0/debian/control
--- lomiri-download-manager-0.1.0/debian/control2020-12-13 
20:45:14.0 +0100
+++ lomiri-download-manager-0.1.0/debian/control2021-05-23 
22:00:01.0 +0200
@@ -159,7 +159,7 @@
 Section: libdevel
 Architecture: any
 Depends: libldm-common-dev (= ${binary:Version}),
- liblomiri-download-manager-common0 (= ${binary:Version}),
+ liblomiri-upload-manager-common0 (= ${binary:Version}),
  qtbase5-dev,
  ${shlibs:Depends},
  ${misc:Depends}

Bug#988750: YAML dependencies should be optional/suggested

[dcook]

Thanks for looking into this, gregor. I'm looking forward to Tina's response
as well. 

David Cook
-Original Message-
From: gregor herrmann  
Sent: Saturday, 22 May 2021 3:35 AM
To: dc...@prosentient.com.au; 988...@bugs.debian.org
Subject: Re: Bug#988750: YAML dependencies should be optional/suggested

Control: forwarded -1 https://rt.cpan.org/Ticket/Display.html?id=136486

On Wed, 19 May 2021 10:09:54 +1000, dc...@prosentient.com.au wrote:

> The Debian package requires that libyaml-perl or libyaml-syck-perl be 
> installed, but it is possible to use this package without either of 
> those YAML modules. You can specify your own YAML parser (like YAML::XS).

Thanks for bringing this up.
 
> There is some discussion about this on CPAN:
> https://rt.cpan.org/Ticket/Display.html?id=136485
> https://rt.cpan.org/Ticket/Display.html?id=136486

It's a bit tricky from a packaging point of view; I've replied in
https://rt.cpan.org/Ticket/Display.html?id=136486
and I'm looking forward to working with Tina on this issue.
 

Cheers,
gregor

--
 .''`.  https://info.comodo.priv.at -- Debian Developer
https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649
AA06  `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation
Europe
   `-   NP: Diana Krall: Come Dance With Me

Bug#989030: memtest86+: New upstream version available v5.31b

[Junichi Uekawa]

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

Dear Maintainer,

According to memtest.org site, there's a new upstream version available for 
testing. 

https://www.memtest.org/#downcode


In diff I see something like:

+   }else if (mem_devs[i]->size == 0x7FFF){
+   // SMBIOS 2.7+
+   size_in_mb = mem_devs[i]->ext_size;
+   itoa(string, size_in_mb);
+   cprint(yof, POP2_X+4+18, st

so might be interesting.


-- 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/12 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to ja_JP.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#989029: info: scroll-backward is buggy

[Vincent Lefevre]

Package: info
Version: 6.7.0.dfsg.2-6
Severity: normal

The info manual says:

 ('scroll-backward')

 Shift the text in this window down.  The inverse of
 'scroll-forward'.  If you are at the start of a node,  takes
 you to the "previous" node, so that you can read an entire manual
 from finish to start by repeating .  The default scroll size
 can be changed by invoking the
 ('scroll-backward-page-only-set-window') command with a numeric
 argument.
[...]

But this doesn't behave like that in the gnuplot manual from the
gnuplot-doc 5.4.1+dfsg1-1 Debian package: Go to "Bugs". This gives


5 Bugs
**

Please e-mail bug reports to the gnuplot-bugs mailing list or upload the
report to the gnuplot web site on SourceForge.  Please give complete
information on the version of gnuplot you are using and, if possible, a
test script that demonstrates the bug.  See 'seeking-assistance'.

* Menu:

* known_limitations::
* External_libraries::


Then do a scroll-backward (with the Backspace or PageUp key).
This gives:


5.2 External libraries
==
[...]


which is not the "previous" node, but some later node.

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

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

Versions of packages info depends on:
ii  install-info  6.7.0.dfsg.2-6
ii  libc6 2.31-12
ii  libtinfo6 6.2+20201114-2

info recommends no packages.

info suggests no packages.

-- no debconf information

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

Bug#989028: gnuplot.info: missing terminal types

[Vincent Lefevre]

Package: gnuplot-doc
Version: 5.4.1+dfsg1-1
Severity: normal

After "info gnuplot", go to "Terminal_types::". One gets:


4 Terminal types


* Menu:

* complete_list_of_terminals::


The next page is just:


4.1 complete list of terminals
==

Gnuplot supports a large number of output formats.  These are selected
by choosing an appropriate terminal type, possibly with additional
modifying options.  See *note terminal::.

   This document may describe terminal types that are not available to
you because they were not configured or installed on your system.  To
see a list of terminals available on a particular gnuplot installation,
type 'set terminal' with no modifiers.

   Terminals marked 'legacy' are not built by default in recent gnuplot
versions and may not actually work.  @c <3 - all terminal stuff is
pulled from the .trm files

* Menu:

* Bugs::


without the complete list of terminals, contrary to the manual
in HTML.

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

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

-- no debconf information

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

Bug#989027: kate: Kate hangs (approx 30 seconds) after reassign existing keyboard shortcut.

[?]

Package: kate
Version: 4:20.12.2-1
Severity: normal
X-Debbugs-Cc: gmcpher...@outlook.com

Dear Maintainer,

1. Settings -> Configure Keyboard Shortcuts
2. Search dup
3. Assign Duplicate Selected Lines Down to Ctrl+D
4. Accept warning about replacing existing usage of Ctrl+D.

Undesired Result: Kate hangs approx 30 seconds (also may crash)

Expected result: 
Kate assigns shortcut within a second or two (or less) and returns
UI control back to the user.

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

Kernel: Linux 5.10.0-6-amd64 (SMP w/16 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 kate depends on:
ii  kate5-data   4:20.12.2-1
ii  kio  5.78.0-4
ii  ktexteditor-katepart 5.78.0-3
ii  libc62.31-12
ii  libkf5bookmarks5 5.78.0-2
ii  libkf5completion55.78.0-3
ii  libkf5configcore55.78.0-4
ii  libkf5configgui5 5.78.0-4
ii  libkf5configwidgets5 5.78.0-2
ii  libkf5coreaddons55.78.0-4
ii  libkf5crash5 5.78.0-3
ii  libkf5dbusaddons55.78.0-2
ii  libkf5guiaddons5 5.78.0-3
ii  libkf5i18n5  5.78.0-2
ii  libkf5iconthemes55.78.0-2
ii  libkf5jobwidgets55.78.0-2
ii  libkf5kiocore5   5.78.0-4
ii  libkf5kiofilewidgets55.78.0-4
ii  libkf5kiogui55.78.0-4
ii  libkf5kiowidgets55.78.0-4
ii  libkf5newstuff5  5.78.0-4
ii  libkf5parts5 5.78.0-3
ii  libkf5plasma55.78.0-3
ii  libkf5service-bin5.78.0-2
ii  libkf5service5   5.78.0-2
ii  libkf5syntaxhighlighting55.78.0-2
ii  libkf5texteditor55.78.0-3
ii  libkf5textwidgets5   5.78.0-2
ii  libkf5threadweaver5  5.78.0-2
ii  libkf5wallet-bin 5.78.0-2
ii  libkf5wallet55.78.0-2
ii  libkf5widgetsaddons5 5.78.0-2
ii  libkf5windowsystem5  5.78.0-2
ii  libkf5xmlgui55.78.0-2
ii  libkuserfeedbackcore11.0.0-3
ii  libkuserfeedbackwidgets1 1.0.0-3
ii  libqt5core5a 5.15.2+dfsg-5
ii  libqt5dbus5  5.15.2+dfsg-5
ii  libqt5gui5   5.15.2+dfsg-5
ii  libqt5sql5   5.15.2+dfsg-5
ii  libqt5widgets5   5.15.2+dfsg-5
ii  libqt5xml5   5.15.2+dfsg-5
ii  libstdc++6   10.2.1-6
ii  plasma-framework 5.78.0-3
ii  qml-module-org-kde-kquickcontrolsaddons  5.78.0-2
ii  qml-module-qtquick-layouts   5.15.2+dfsg-5
ii  qml-module-qtquick2  5.15.2+dfsg-5

Versions of packages kate recommends:
ii  sonnet-plugins  5.78.0-2

Versions of packages kate suggests:
pn  darcs
pn  exuberant-ctags  
ii  git  1:2.30.2-1
ii  khelpcenter  4:20.12.0-1
ii  konsole-kpart4:20.12.3-1
pn  mercurial
pn  subversion   

-- no debconf information

Bug#989026: unblock: lomiri-app-launch/0.0.90-8

[Mike Gabriel]

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

Please unblock package lomiri-app-launch

[ Reason ]
Builds failed on architectures alpha and hppa. This caused
a series of dependent packages not to be built for those archs.

[ Impact ]
Some ayatana-indicator-* packages are currently not available
for the above named architectures. These architectures are not
release architectures. So, accepting this unblock request
is not relevant to the release.

On the other hand, succeeding builds on more architectures don't hurt
either.

[ Tests ]
The real tests happen now on the buildd nodes (I haven't tested
the builds on a porter box as that's not necessary usually for
symbols updates via pkgkde-symbolshelper).

[ Risks ]
None.

[ 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 lomiri-app-launch/0.0.90-8
diff -Nru lomiri-app-launch-0.0.90/debian/changelog 
lomiri-app-launch-0.0.90/debian/changelog
--- lomiri-app-launch-0.0.90/debian/changelog   2020-12-21 13:35:03.0 
+0100
+++ lomiri-app-launch-0.0.90/debian/changelog   2021-05-24 00:41:04.0 
+0200
@@ -1,3 +1,15 @@
+lomiri-app-launch (0.0.90-8) unstable; urgency=medium
+
+  * debian/control:
++ Don't require a versioned B-D on libgtest-dev. (There have been some
+  revisions that were broken, but earlier googletest versions should work
+  in general).
+  * debian/liblomiri-app-launch0.symbols:
++ Update .symbols file for architectures 'alpha' and 'hppa' (Closes:
+  #982942).
+
+ -- Mike Gabriel   Mon, 24 May 2021 00:41:04 +0200
+
 lomiri-app-launch (0.0.90-7) unstable; urgency=medium
 
   * debian/liblomiri-app-launch0.symbols:
diff -Nru lomiri-app-launch-0.0.90/debian/control 
lomiri-app-launch-0.0.90/debian/control
--- lomiri-app-launch-0.0.90/debian/control 2020-12-13 20:33:11.0 
+0100
+++ lomiri-app-launch-0.0.90/debian/control 2021-01-27 16:18:59.0 
+0100
@@ -15,7 +15,7 @@
libdbustest1-dev (>= 14.04.0),
libgirepository1.0-dev,
libglib2.0-dev,
-   libgtest-dev (>= 1.10.0.20201025-1~),
+   libgtest-dev,
libjson-glib-dev (>= 1.1.2),
liblttng-ust-dev,
libmirclient-dev (>= 0.5),
diff -Nru lomiri-app-launch-0.0.90/debian/liblomiri-app-launch0.symbols 
lomiri-app-launch-0.0.90/debian/liblomiri-app-launch0.symbols
--- lomiri-app-launch-0.0.90/debian/liblomiri-app-launch0.symbols   
2020-12-21 13:17:07.0 +0100
+++ lomiri-app-launch-0.0.90/debian/liblomiri-app-launch0.symbols   
2021-05-24 00:38:47.0 +0200
@@ -1,4 +1,4 @@
-# SymbolsHelper-Confirmed: 0.0.90 amd64 arm64 armel armhf i386 m68k mips64el 
mipsel powerpc ppc64 ppc64el riscv64 s390x sh4 x32
+# SymbolsHelper-Confirmed: 0.0.90 alpha amd64 arm64 armel armhf hppa i386 m68k 
mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sh4 x32
 liblomiri-app-launch.so.0 liblomiri-app-launch0 #MINVER#
 * Build-Depends-Package: liblomiri-app-launch-dev
  
_ZN6lomiri10app_launch11Application6createERKNS0_5AppIDERKSt10shared_ptrINS0_8RegistryEE@Base
 0.0.90
@@ -17,10 +17,10 @@
  
_ZN6lomiri10app_launch5AppID8discoverERKSt10shared_ptrINS0_8RegistryEERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESE_NS1_15VersionWildcardE@Base
 0.0.90
  
_ZN6lomiri10app_launch5AppID8discoverERKSt10shared_ptrINS0_8RegistryEERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESE_SE_@Base
 0.0.90
  
_ZN6lomiri10app_launch5AppIDC1ENS0_10TypeTaggerINS1_10PackageTagENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcENS2_INS1_10AppNameTagES9_EENS2_INS1_10VersionTagES9_EE@Base
 0.0.90
- (arch=!amd64 !i386 !m68k !mips64el !mipsel !powerpc !ppc64 !ppc64el !riscv64 
!s390x !sh4 !x32)_ZN6lomiri10app_launch5AppIDC1ERKS1_@Base 0.0.90
+ (arch=!alpha !amd64 !hppa !i386 !m68k !mips64el !mipsel !powerpc !ppc64 
!ppc64el !riscv64 !s390x !sh4 !x32)_ZN6lomiri10app_launch5AppIDC1ERKS1_@Base 
0.0.90
  _ZN6lomiri10app_launch5AppIDC1Ev@Base 0.0.90
  
_ZN6lomiri10app_launch5AppIDC2ENS0_10TypeTaggerINS1_10PackageTagENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcENS2_INS1_10AppNameTagES9_EENS2_INS1_10VersionTagES9_EE@Base
 0.0.90
- (arch=!amd64 !i386 !m68k !mips64el !mipsel !powerpc !ppc64 !ppc64el !riscv64 
!s390x !sh4 !x32)_ZN6lomiri10app_launch5AppIDC2ERKS1_@Base 0.0.90
+ (arch=!alpha !amd64 !hppa !i386 !m68k !mips64el !mipsel !powerpc !ppc64 
!ppc64el !riscv64 !s390x !sh4 !x32)_ZN6lomiri10app_launch5AppIDC2ERKS1_@Base 
0.0.90
  _ZN6lomiri10app_launch5AppIDC2Ev@Base 0.0.90
  _ZN6lomiri10app_launch5AppIDD1Ev@Base 0.0.90
  _ZN6lomiri10app_launch5AppIDD2Ev@Base 0.0.90

Bug#989025: unblock: micro-evtd/3.4-7

[Ryan Tandy]

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

Please unblock package micro-evtd

[ Reason ]

Fix micro-evtd creating its pid and status files in /var/run with 
world-writable permissions (#988119).


[ Impact ]

- The pid and status files in /var/run are mode 666, which could be a 
 potential security issue.
- micro-evtd does not stop when asked to with "/etc/init.d/micro-evtd 
 stop", because start-stop-daemon refuses to use the insecure pid file.
- Because of that, the daemon also does not restart on upgrade as it 
 should, instead the old version remains running.


[ Tests ]

There are no automated tests. I manually tested the install and upgrade 
cases (testing→unstable).


[ Risks ]

The change should be trivial, but it is possible (if unlikely) that I 
missed some case where the umask 000 was actually needed.


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

[ Other info ]

The package builds a udeb. I tested an installation using a d-i daily 
build with the updated package included, and confirmed the corrected 
file permissions in the d-i environment.


The issue exists already in buster (not a regression).

unblock micro-evtd/3.4-7

Thank you,
Ryan
diff -Nru micro-evtd-3.4/debian/changelog micro-evtd-3.4/debian/changelog
--- micro-evtd-3.4/debian/changelog 2021-05-03 20:22:09.0 -0700
+++ micro-evtd-3.4/debian/changelog 2021-05-22 00:40:17.0 -0700
@@ -1,3 +1,12 @@
+micro-evtd (3.4-7) unstable; urgency=medium
+
+  [ Ryan Tandy ]
+  * Fix world-writable pid and status files in /var/run (Closes: #988119)
+- Patch micro-evtd.c to reset umask to 022 instead of 0.
+- Fix permissions on existing files on upgrade.
+
+ -- Roger Shimizu   Sat, 22 May 2021 16:40:17 +0900
+
 micro-evtd (3.4-6) unstable; urgency=medium
 
   [ Ryan Tandy ]
diff -Nru micro-evtd-3.4/debian/micro-evtd.postinst 
micro-evtd-3.4/debian/micro-evtd.postinst
--- micro-evtd-3.4/debian/micro-evtd.postinst   2021-05-03 20:22:09.0 
-0700
+++ micro-evtd-3.4/debian/micro-evtd.postinst   2021-05-22 00:40:17.0 
-0700
@@ -14,6 +14,18 @@
 rm /usr/sbin/micro-evtd.status
 fi
 fi
+
+if dpkg --compare-versions "$2" lt-nl "3.4-7~"; then
+# Fix permissions on the existing pid file
+# so that the daemon is actually restarted
+if [ -f /var/run/micro-evtd.pid ]; then
+chmod 644 /var/run/micro-evtd.pid
+fi
+
+if [ -f /var/run/micro-evtd.status ]; then
+chmod 644 /var/run/micro-evtd.status
+fi
+fi
 ;;
 
 *)
diff -Nru 
micro-evtd-3.4/debian/patches/0008-Don-t-create-world-writable-files.patch 
micro-evtd-3.4/debian/patches/0008-Don-t-create-world-writable-files.patch
--- micro-evtd-3.4/debian/patches/0008-Don-t-create-world-writable-files.patch  
1969-12-31 16:00:00.0 -0800
+++ micro-evtd-3.4/debian/patches/0008-Don-t-create-world-writable-files.patch  
2021-05-22 00:40:17.0 -0700
@@ -0,0 +1,26 @@
+From: Ryan Tandy 
+Date: Fri, 21 May 2021 13:06:41 -0700
+Subject: Don't create world-writable files
+
+Set umask to 022 on startup instead of 000.
+
+Fixes the pid and status files being created world-writable.
+
+Bug-Debian: https://bugs.debian.org/988119
+---
+ src/micro-evtd.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/micro-evtd.c b/src/micro-evtd.c
+index da91549..cc05b6a 100644
+--- a/src/micro-evtd.c
 b/src/micro-evtd.c
+@@ -1777,7 +1777,7 @@ int main(int argc, char *argv[])
+   setsid();
+ 
+   /* clear file creation mask */
+-  umask(0);
++  umask(022);
+ 
+   // Lock out device resource
+   getResourceLock();
diff -Nru micro-evtd-3.4/debian/patches/series 
micro-evtd-3.4/debian/patches/series
--- micro-evtd-3.4/debian/patches/series2021-05-03 20:22:09.0 
-0700
+++ micro-evtd-3.4/debian/patches/series2021-05-22 00:40:17.0 
-0700
@@ -5,3 +5,4 @@
 0005-Check-for-mmap-returning-MAP_FAILED.patch
 0006-Match-default-temperature-configuration-to-the-confi.patch
 0007-Fix-FTBFS-with-glibc-2.30.patch
+0008-Don-t-create-world-writable-files.patch

Bug#681694: brasero: Properly watch the child process state

[Darshaka Pathirana]

forwarded 681694 https://gitlab.gnome.org/GNOME/brasero/-/issues/274
tags 681694 - fixed-upstream
thanks

The bug has been migrated to GNOME's GitLab instance and was incorrectly tagged 
as fixed-upstream.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#680989: brasero: [libburnia plugin] Use traditional trailing padding of 300kB for TAO tracks

[Darshaka Pathirana]

forwarded 680989 https://gitlab.gnome.org/GNOME/brasero/-/issues/275
tags 680989 - fixed-upstream

The bug has been migrated to GNOME's GitLab instance and was incorrectly tagged 
as fixed-upstream.

thanks



OpenPGP_signature
Description: OpenPGP digital signature

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

[Vagrant Cascadian]

On 2021-05-23, Cyril Brulebois wrote:
> 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).

Ok; I went ahead and uploaded the fix to u-boot after a bit more
testing. It's only a few days behind linux, and will need to ask for an
unblock before too long...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#989024: buster-pu: package php-horde-text-filter/2.3.5-3+deb10u2

[Mike Gabriel]

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

[ Reason ]
 security fix for CVE-2021-26929. This is a forward port of
Sylvain Beucler's team of the LTS team.

[ Impact ]
XSS vulnerability in html2text converter of Horde.

[ Tests ]
Unfortunately, unit tests have been unreliable in Debian buster's
version of Horde. I have tested the package as best as possible
on a live Horde instance installed via Debian packages (based on
Debian buster).

[ Risks ]
Breakage of Horde websites if they have been set up with Debian
packages as provided in Debian buster.

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

+  * CVE-2021-26929: An XSS issue was discovered in Horde Groupware Webmail
+Edition (where the Horde_Text_Filter library is used). The attacker
+can send a plain text e-mail message, with JavaScript encoded as a
+link or email that is mishandled by preProcess in Text2html.php,
+because bespoke use of \x00\x00\x00 and \x01\x01\x01 interferes with
+XSS defenses. (Closes: #982769).

Additionally, I have dropped the Debian QA Group from the Uploaders: field
and put myself there (as I had taken over Horde maintenance during the
Debian 11 cycle.

[ Other info ]
None.
diff -Nru php-horde-text-filter-2.3.5/debian/changelog 
php-horde-text-filter-2.3.5/debian/changelog
--- php-horde-text-filter-2.3.5/debian/changelog2020-01-28 
10:41:46.0 +0100
+++ php-horde-text-filter-2.3.5/debian/changelog2021-05-24 
00:02:12.0 +0200
@@ -1,3 +1,19 @@
+php-horde-text-filter (2.3.5-3+deb10u2) buster; urgency=medium
+
+  [ Mike Gabriel ]
+  * debian/control:
++  Drop Debian QA Group from Uploaders: field, add myself instead.
+
+  [ Sylvain Beucler ]
+  * CVE-2021-26929: An XSS issue was discovered in Horde Groupware Webmail
+Edition (where the Horde_Text_Filter library is used). The attacker
+can send a plain text e-mail message, with JavaScript encoded as a
+link or email that is mishandled by preProcess in Text2html.php,
+because bespoke use of \x00\x00\x00 and \x01\x01\x01 interferes with
+XSS defenses. (Closes: #982769).
+
+ -- Mike Gabriel   Mon, 24 May 2021 00:02:12 +0200
+
 php-horde-text-filter (2.3.5-3+deb10u1) buster; urgency=medium
 
   * QA upload.
diff -Nru php-horde-text-filter-2.3.5/debian/control 
php-horde-text-filter-2.3.5/debian/control
--- php-horde-text-filter-2.3.5/debian/control  2020-01-28 10:41:46.0 
+0100
+++ php-horde-text-filter-2.3.5/debian/control  2021-05-24 00:00:51.0 
+0200
@@ -2,8 +2,8 @@
 Section: php
 Priority: optional
 Maintainer: Horde Maintainers 
-Uploaders: Debian QA Group 
-Build-Depends: debhelper (>= 11), pkg-php-tools (>= 1.1), pear-horde-channel
+Uploaders: Mike Gabriel 
+Build-Depends: debhelper (>= 11), pkg-php-tools (>= 1.1), pear-horde-channel, 
php-horde-secret
 Standards-Version: 4.1.4
 Homepage: http://www.horde.org/
 Vcs-Git: https://salsa.debian.org/horde-team/php-horde-text-filter.git
diff -Nru php-horde-text-filter-2.3.5/debian/patches/CVE-2021-26929.patch 
php-horde-text-filter-2.3.5/debian/patches/CVE-2021-26929.patch
--- php-horde-text-filter-2.3.5/debian/patches/CVE-2021-26929.patch 
1970-01-01 01:00:00.0 +0100
+++ php-horde-text-filter-2.3.5/debian/patches/CVE-2021-26929.patch 
2021-05-23 23:59:28.0 +0200
@@ -0,0 +1,202 @@
+Origin: 
https://github.com/horde/Text_Filter/commit/a2f67da064d7a91440b7a2448e56a6387ab94c67
+Reviewed-by: Sylvain Beucler 
+Last-Update: 2021-02-18
+
+From a2f67da064d7a91440b7a2448e56a6387ab94c67 Mon Sep 17 00:00:00 2001
+From: Michael J Rubinsky 
+Date: Sat, 13 Feb 2021 11:44:42 -0500
+Subject: [PATCH] [mjr] SECURITY: Fix XSS via Text2Html filter
+
+Reported by: Alex Birnberg '',
+-'encode' => false
++'encode' => false,
++'secret' => null
+ );
+ 
+ /**
+@@ -85,9 +86,12 @@ EOR;
+ public function regexCallback($matches)
+ {
+ $data = $this->_regexCallback($matches);
+-
++$secret = new Horde_Secret();
++if (empty($this->_params['secretKey'])) {
++$this->_params['secretKey'] = $secret->setKey();
++}
+ if ($this->_params['encode']) {
+-$data = "\01\01\01" . base64_encode($data) . "\01\01\01";
++$data = "\01\01\01" . 
base64_encode($secret->write($this->_params['secretKey'], $data)) . "\01\01\01";
+ }
+ 
+ return $matches[1] . $matches[2] . (isset($matches[9]) ? $matches[9] 
: '') .
+@@ -119,15 +123,22 @@ EOR;
+  * "Decodes" the text formerly encoded by using the "encode" parameter.
+  *
+  * @param string $text  An encoded text.
++ * @param string $key   An optional key to use with Horde_Secret 
encryption.
++ *  If omitt

Bug#963509: prospector: Version 1.3.1 now available

[Salman Mohammadi]

On Fri, 6 Nov 2020 19:59:43 -0300 =?utf-8?Q?Rog=C3=A9rio?= Brito 
 wrote:

> Package: prospector
> Version: 1.1.7-2
> Followup-For: Bug #963509
> X-Debbugs-Cc: team+pyt...@tracker.debian.org, 
locutusofb...@debian.org, mat...@debian.org, czc...@debian.org

>
> Hi.
>
> There is a new version of prospector upstream at
>
> https://pypi.org/project/prospector/
>
> that is supposed to fix all the problems that are currently in debian 
(read:

> prospector doesn't work at all).
>
> I'm including in the CC some of the people that last touched the 
package (at
> least according to changelog.Debian.gz in my system). If anybody 
could fix

> it, that would be awesome.
>
>
> Thanks,
>
> Rogério Brito.
>

Hi dear maintainers,

I would be happy to give a hand to upgrade this package and its orphaned 
dependencies. What can I do to help?



Thanks, Salman

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

[Cyril Brulebois]

Cyril Brulebois  (2021-05-23):
> And right before getting some rest, it struck me that I should be
> looking into the size-request and size-allocate signals. The latter is
> the right one and that's indeed getting me the focus where it should be!
> \o/ I suppose this isn't entirely crazy since that's an idea you had as
> well. :)
> 
> … back to MR #12, I'm a little reluctant to changing the workaround at
> this stage. After all, I've run a bunch of test cases already, which all
> looked good, and while reverting the initial workaround would mean less
> code / technical debt, all those lines should go away in bookworm
> anyway. So I think I would *slightly* prefer paper over the focus
> regression (this bug) with an extra callback. I would have to need to
> power up coffee and brain a little more though. :)

Apart from introducing a memory leak, that alone is sufficient to fix
the glitch:
  https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/13

For reference, here's what size-allocate events can look like. For the
avoidance of doubt, I logged x,y and w(idth),h(eight) on two separate
lines to ease comparing values, but each x,y + w,h couple of lines
come from the same size-allocate event (a GdkRectangle is provided):

May 23 19:57:01 debconf: - update title - ← mirror country selection
May 23 19:57:01 debconf: allocate: x,y=8x49
May 23 19:57:01 debconf: allocate: w,h=208x60
May 23 19:57:01 debconf: allocate: x,y=8x49
May 23 19:57:01 debconf: allocate: w,h=722x368
May 23 19:57:01 debconf: allocate: x,y=8x49
May 23 19:57:01 debconf: allocate: w,h=740x368
May 23 19:57:01 debconf: allocate: x,y=8x81
May 23 19:57:01 debconf: allocate: w,h=740x336
May 23 19:57:02 debconf: - update title - ← mirror hostname 
selection
May 23 19:57:02 debconf: allocate: x,y=8x49
May 23 19:57:02 debconf: allocate: w,h=241x60
May 23 19:57:02 debconf: allocate: x,y=8x49
May 23 19:57:02 debconf: allocate: w,h=722x368
May 23 19:57:02 debconf: allocate: x,y=8x49
May 23 19:57:02 debconf: allocate: w,h=740x368
May 23 19:57:02 debconf: allocate: x,y=8x66
May 23 19:57:02 debconf: allocate: w,h=740x351
May 23 19:57:02 debconf: allocate: x,y=8x95
May 23 19:57:02 debconf: allocate: w,h=740x322
May 23 19:57:02 debconf: - update title - ← proxy => Back
May 23 19:57:04 debconf: - update title - ← mirror hostname 
selection again
May 23 19:57:04 debconf: allocate: x,y=8x49
May 23 19:57:04 debconf: allocate: w,h=241x60
May 23 19:57:04 debconf: allocate: x,y=8x49
May 23 19:57:04 debconf: allocate: w,h=722x368
May 23 19:57:04 debconf: allocate: x,y=8x49
May 23 19:57:04 debconf: allocate: w,h=740x368
May 23 19:57:04 debconf: allocate: x,y=8x66
May 23 19:57:04 debconf: allocate: w,h=740x351
May 23 19:57:04 debconf: allocate: x,y=8x95
May 23 19:57:04 debconf: allocate: w,h=740x322


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


signature.asc
Description: PGP signature

Bug#989019: mirror submission for mirrors.xtom.de

[xTom]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirrors.xtom.de
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: xTom 
Country: DE Germany
Location: Duesseldorf
Sponsor: xTom https://xtom.com/
Comment: Hello,
 
 For the nameservers of domain xtom.de, we use anycast network with more than 
100+ PoPs around the world. You can check ns1.xtom.com on ping.sx to test




Trace Url: http://mirrors.xtom.de/debian/project/trace/
Trace Url: http://mirrors.xtom.de/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirrors.xtom.de/debian/project/trace/mirrors.xtom.de

Bug#988724: firefox: Firefox 88 unusable on intel gpu

[Mike Hommey]

On Sun, May 23, 2021 at 01:55:54PM +0200, Kamil Jońca wrote:
> 
> Mike Hommey  writes:
> 
> > On Tue, May 18, 2021 at 07:39:27PM +0200, Kamil Jońca wrote:
> >> Package: firefox
> >> Version: 87.0-2
> >> Severity: important
> >> X-Debbugs-Cc: kjo...@poczta.onet.pl
> >> 
> >> Dear Maintainer,
> >> 
> >> *** Reporter, please consider answering these questions, where appropriate 
> >> ***
> >> 
> >>* What led up to the situation?
> >> Upgrade to 88.0.1 version
> >>* What exactly did you do (or not do) that was effective (or
> >>  ineffective)?
> >> Start firefox 
> >> 
> >>* What was the outcome of this action?
> >> white window, not responsive.
> >> 
> >>* What outcome did you expect instead?
> >> 
> >> Normally functioning firefox.
> >> 
> >> *** End of the template - remove these template lines ***
> >
> > In Firefox 87, can you go to about:support and copy/paste its content?
> >
> 
> To record: I experimented after issuing bug and found that I have file
> for load intel drivers.:
> 
> --8<---cut here---start->8---
> %cat /etc/X11/xorg.conf.d/10-intel.conf
> Section "Device"
>Identifier  "Intel"
>Driver  "intel"
>BusID   "PCI:0:2:0"
> EndSection
> --8<---cut here---end--->8---
> 
> When I commented out this file (which I believe makes that x.org uses
> "modesetting" driver), firefox 88 starts to work.

Can you also provide about:support content for that working firefox 88?

Thanks

Mike

Bug#975490: u-boot-sunxi: A64-Olinuxino-eMMC boot stuck at "Starting kernel ..."

[Vagrant Cascadian]

Control: retitle 975490 u-boot-sunxi: A64-Olinuxino-eMMC boot stuck at 
"Starting kernel ..."
Control: tags 975490 moreinfo

On 2021-02-10, Ivo De Decker wrote:
> On Mon, Jan 04, 2021 at 08:27:51PM -0800, Vagrant Cascadian wrote:
>> >> I'll test on a few of my systems to see if I can reproduce the issue.
>> >
>> > I can confirm similar behavior on a pinebook, although the kernel does
>> > boot and actually load, and eventually displays on the LCD display (if I
>> > "setenv console" from u-boot commandline). It even responds
>> > appropriately to ctrl-alt-delete, so it is not a completely hung
>> > kernel...
>> 
>> With a locally built version of 2020.10+dfsg-2, I can no longer
>> reproduce this issue at all.
>> 
>> Could you try with the new version?
>
> Testing/unstable now has version 2021.01+dfsg-2. Benedikt, could you try this
> version to see if the issue is still there?

I've uploaded 2021.01+dfsg-5 to unstable that fixes a bug with similar
symptoms (Bug#988217); would you be able to test this version?

There is also a version in experimental that would be good to see if the
issue is fixed for you.

Thanks!

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#988549: lxqt: dmesg tail given before a reboot due to graphics subsystem freez

[Amy Kos]

Hi

issue still remains after full-upgrade?
Which version of pcmanfm-qt and libqt5core5a is installed?

Thanks,
Amy

Bug#809357: udisks2: Can't read files on video DVD

[Hugues Larrive]

I have a similar problem using udisks2:2.8.1-4 (buster).

$ ls -ld /media/hugues/\ DVD_RECORDER/
dr--r--r-- 3 hugues hugues 152 mars   7  2010 '/media/hugues/ DVD_RECORDER/'
$ ls -l /media/hugues/\ DVD_RECORDER/
ls: impossible d'accéder à '/media/hugues/ DVD_RECORDER/VIDEO_TS': Permission 
non accordée
total 0
?? ? ? ? ?  ? VIDEO_TS
$ udisksctl unmount -b /dev/sr0
Unmounted /dev/sr0.
$ udisksctl mount -b /dev/sr0 -o ro,dmode=0500
Error mounting /dev/sr0: 
GDBus.Error:org.freedesktop.UDisks2.Error.OptionNotPermitted: Mount option 
`dmode=0500' is not allowed

udf_allow is hardcoded prior to 2.9.0 version so I have used the following 
patch to workaround the issue :
--- udisks2-2.8.1.orig/src/udiskslinuxfilesystem.c
+++ udisks2-2.8.1/src/udiskslinuxfilesystem.c
@@ -352,8 +352,8 @@ static const gchar *iso9660_allow_gid_se

 /* -- udf  */

-static const gchar *udf_defaults[] = { "uid=", "gid=", "iocharset=utf8", NULL 
};
-static const gchar *udf_allow[] = { "iocharset", "umask", NULL };
+static const gchar *udf_defaults[] = { "uid=", "gid=", "iocharset=utf8", 
"mode=0400", "dmode=0500", NULL };
+static const gchar *udf_allow[] = { "iocharset", "umask", "mode", "dmode", 
NULL };
 static const gchar *udf_allow_uid_self[] = { "uid", NULL };
 static const gchar *udf_allow_gid_self[] = { "gid", NULL };


On Tue, 29 Dec 2015 19:42:17 + Sam Morris  wrote:> 
Package: udisks2
> Version: 2.1.3-5
> Severity: normal
>
> I've got a video DVD that I can't read the files on. Looks like the
> filesystem has nonsense permissions encoded within it:
>
>   $ sudo ls -ld /media/sam/DVD_VIDEO_RECORDER
>   dr 3 sam sam 88 Jul 13  2014 /media/sam/DVD_VIDEO_RECORDER
>
> Might be a good idea to ignore permissions on removable disks, since the
> user can always put them into another computer that they have root on.
>
> It looks like this was done a while ago in udisks
> 
> but presumably this didn't make it over to udisks2.
>
> -- System Information:
> Debian Release: 8.2
>   APT prefers stable-updates
>   APT policy: (550, 'stable-updates'), (550, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages udisks2 depends on:
> ii  dbus   1.8.20-0+deb8u1
> ii  libacl12.2.52-2
> ii  libatasmart4   0.19-3
> ii  libc6  2.19-18+deb8u1
> ii  libglib2.0-0   2.42.1-1
> ii  libgudev-1.0-0 215-17+deb8u2
> ii  libpam-systemd 215-17+deb8u2
> ii  libpolkit-agent-1-00.105-8
> ii  libpolkit-gobject-1-0  0.105-8
> ii  libsystemd0215-17+deb8u2
> ii  libudisks2-0   2.1.3-5
> ii  parted 3.2-7
> ii  udev   215-17+deb8u2
>
> Versions of packages udisks2 recommends:
> ii  dosfstools   3.0.27-1
> ii  eject2.1.5+deb1+cvs20081104-13.1
> ii  gdisk0.8.10-2
> ii  ntfs-3g  1:2014.2.15AR.2-1+deb8u2
> ii  policykit-1  0.105-8
>
> Versions of packages udisks2 suggests:
> pn  btrfs-tools 
> ii  cryptsetup-bin  2:1.6.6-5
> pn  exfat-utils 
> pn  mdadm   
> pn  reiserfsprogs   
> pn  xfsprogs
>
> -- no debconf information

Bug#988094: Tested further

[kurt]

I've tested the unpatched version further.  The number of services it 
works with is actually quite a bit fewer than I thought.  I am upgrading 
this bug to grave, since the package as shipped is "unusable or mostly 
so".

Bug#988512: ca-cacert: class3 certificate has expired

[Kevin Otte]

Now that the certificate has expired, this package is now useless. It
should either be updated and a backport applied to buster, or removed
ahead of the bullseye release.

Does this warrant raising the severity?

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

[Bernhard Übelacker]

Dear Maintainer,
I did a little further investigation and found that it could be
reproduced with just the following line, inside the arm64 chroot:

for i in {1..100}; do echo $i; python3.9 -c "exit()"; done

This produced 13 crashes for the 100 runs.

But the crashes stop to appear when /proc is mounted inside the chroot.

With the help of strace:amd64, rr:amd64 and a self-built qemu-aarch64-static
I could locate the access [2] to /proc that, if failing,
seem to cause the segfault.

And the backtrace leads to this upstream change [1],
which matches this bug and a qemu-aarch64-static built
with this patch does not show the segfault anymore,
when /proc is not available.

Kind regards,
Bernhard


[1] 
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=0266e8e3b3981b492e82be20bb97e8ed9792ed00


[2]
(rr) bt
#0  0x00607402 in read_self_maps () at ../../util/selfmap.c:60
#1  0x005b5124 in pgb_find_hole 
(guest_loaddr=guest_loaddr@entry=4194304, guest_size=guest_size@entry=22269416, 
align=align@entry=4096, offset=0) at ../../linux-user/elfload.c:2211
#2  0x005b69bf in pgb_static (align=4096, orig_hiaddr=, 
orig_loaddr=4194304, image_name=0x7ffc7ef22cf3 "/usr/bin/python3.9") at 
../../linux-user/elfload.c:2305
#3  probe_guest_base (image_name=image_name@entry=0x7ffc7ef22cf3 
"/usr/bin/python3.9", guest_loaddr=guest_loaddr@entry=4194304, 
guest_hiaddr=) at ../../linux-user/elfload.c:2389
#4  0x005b71e7 in load_elf_image (image_name=0x7ffc7ef22cf3 "/usr/bin/python3.9", 
image_fd=3, info=info@entry=0x7ffc7ef20bc0, pinterp_name=pinterp_name@entry=0x7ffc7ef20920, 
bprm_buf=bprm_buf@entry=0x7ffc7ef20dd0 "\177ELF\002\001\001") at 
../../linux-user/elfload.c:2676
#5  0x005b754c in load_elf_binary (bprm=bprm@entry=0x7ffc7ef20dd0, 
info=info@entry=0x7ffc7ef20bc0) at ../../linux-user/elfload.c:3104
#6  0x005b49db in loader_exec (fdexec=fdexec@entry=3, filename=, argv=argv@entry=0x23df520, envp=envp@entry=0x23eee00, 
regs=regs@entry=0x7ffc7ef20cc0, infop=infop@entry=0x7ffc7ef20bc0, bprm=) at ../../linux-user/linuxload.c:147
#7  0x00402801 in main (argc=, argv=0x7ffc7ef21388, 
envp=) at ../../linux-user/main.c:832

Bug#989021: rxvt-unicode: new usptream version available: 9.26

[Robbie Harwood (frozencemetery)]

Source: rxvt-unicode
Severity: normal
X-Debbugs-Cc: rharw...@club.cc.cmu.edu

Dear Maintainer,

Version 9.26 is available upstream: http://dist.schmorp.de/rxvt-unicode/
(This isn't particularly high priority for me since you've already patched the
recent CVE.)

Thanks,
--Robbie

Bug#899044: Oops: 0000 [#1] SMP in skb_release_data, openvswitch related

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

On Fri, May 18, 2018 at 06:19:02PM +0200, Hans van Kranenburg wrote:
> Package: src:linux
> Version: 4.9.88-1
> 
> Hi,
> 
> I'm observing the attached errors on machines that are Xen dom0 and
> running the latest Debian Stretch 4.9 kernel as dom0 kernel. The errors
> have been happening a few times in the last few weeks. It started after
> upgrading them from Jessie and 3.16 kernel to Stretch with 4.9 kernel.
> 
> For networking between domUs and the outside world, we use openvswitch.
> 
> After such an error happens:
> * The amount of "flows" in the kernel quickly raises to the limit,
> 1, as seen in output of ovs-dpctl show.
> * Network traffic that should flow through the openvswitch bridge starts
> disappearing in a seemingly random way.
> * The memory usage of the userspace ovs-vswitchd starts growing quickly.
> * Many of the ovs commands, like to add or remove an interface or bridge
> hang.
> 
> After a restart of the openvswitch-switch service, and fixing up a bunch
> of configuration of connected interfaces, functionality is restored.
> 
> While most of the symptoms seem related to userspace openvswitch
> processes, the cause of it all seems to be in the kernel, while the
> userspace ovs-vswitchd process is receiving a network packet?
> 
> Sadly I do not know how to reproduce this, except for just waiting until
> it happens again.
> 
> Please advice what else I could use to help resolving this issue.

Is this still an issue? I notice that the upstream report did not got
a reply. If it still an issue, please try to prod upstream again. Is
it observable as well with recent kernels? If not I suggest to close
the issue.

Regards,
Salvatore

Bug#963964: release-notes: document aufs removal for bullseye

[Paul Gevers]

Control: tags -1 patch

Hi all,

As nobody replied to my request for help, I have come up with the
attached proposal. However, I *guessed* that the best advise we can give
to users of aufs-dkms is to migrate away from aufs-dkms *before*
upgrading to bullseye. Is that guess correct? If not, what should we
advise our users?

Paul
From b57d7ed3a3f21c3605dab0335604d74ed35a83b3 Mon Sep 17 00:00:00 2001
From: Paul Gevers 
Date: Sun, 23 May 2021 21:01:17 +0200
Subject: [PATCH] issues.dbk: aufs is not part of bullseye

Closes: #963964
---
 en/issues.dbk | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/en/issues.dbk b/en/issues.dbk
index 43c9534e..2079c0be 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -670,6 +670,24 @@ Environment=SYSTEMD_SULOGIN_FORCE=1
   3.
 
 	  
+	  
+	
+	  The aufs-dkms
+	  package is not part of bullseye. Most aufs-dkms users should be
+	  able to switch to kernel supported
+	  overlayfs to get similar
+	  functionality. However, it's possible to have a Debian
+	  installation on a filesystem that is not compatible with
+	  overlayfs,
+	  e.g. xfs without
+	  d_type. Users of aufs-dkms are advised to
+	  migrate away from aufs-dkms before upgrading
+	  to bullseye.
+	
+	  
 
 	
   
-- 
2.30.2



OpenPGP_signature
Description: OpenPGP digital signature

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

[Mathieu Parent]

Le dim. 23 mai 2021 à 04:33, Abi  a écrit :
>
> Hello Mathieu,

Hello Abi,

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

Thanks for proposing your help.What are your skills?

Debian's bug tracker is managed thru mails, you can look at
https://www.debian.org/Bugs/ and
https://www.debian.org/Bugs/server-control to start with.

By default, sending to n...@bugs.debian.org won't be sent to the submitter,
carefully read https://www.debian.org/Bugs/Developer#followup to ensure that
both submitter and maintainer (pkg-samba list) have the mail (nnn +
nnn-submitter)

Tagging bugs and closing with the relevant version of the fix would help a lot!

On the test side, I have a WIP mrege request at:
https://salsa.debian.org/samba-team/samba/-/merge_requests/6

But we'll wait for bullseye to be released to start working on this.

If you know about Debian packaging, there other possible tasks.

Regards

Mathieu Parent

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

[Cyril Brulebois]

Simon McVittie  (2021-05-23):
> > > I've tried various things like having the focus_path happens in a
> > > “_later” indirection using the same kind of logic as Simon
> > > introduced for setting the text (with a different priority), but
> > > that would happen waaay before set_text_in_idle anyway.
> > 
> > Please could you share what you tried so I can check whether it's
> > doing something wrong? I feel as though this approach ought to be
> > workable
> 
> Actually, never mind: the code structure for this gets increasingly
> messy, with components needing to know about implementation details of
> unrelated components. I think that's technical debt we probably don't
> want to pay.

I was willing to have that for buster, given we're planning on
rewriting the whole thing for GTK 3 next release cycle away. But indeed,
that's quite messy, keeping track of other things we shouldn't be caring
about. And as mentioned, we are a few events behind anyway.

> I have a couple of ideas for possible ways to deal with this.
> 
> One idea is to undo my workaround for #988787 on the cdebconf side,
> and instead, hook onto the GtkTextView's size-request signal and force
> it to be allocated with at least some arbitrary reasonable size (I'm
> trying 300px). This will hopefully still work around #988787, and if
> it doesn't, we have the workaround #988786 in GTK as a fallback.
> https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/12

I'll get back to that in a minute…

> Another idea, still in cdebconf, is to connect to whatever signal is
> emitted when the GtkTreeView is resized (I think this is
> size-allocate?), and take that opportunity to re-adjust the scroll
> position so the (first) selected row comes into view. However, I'm a
> bit concerned that this could itself cause an infinite loop like
> #988787 - I'd have to check the GtkTreeView implementation to make
> sure scrolling cannot schedule a resize.

I've also toyed with the idea of sending a specific “kibi-event” from
the set_text_in_idle that would have its dedicated, not one-shot
callback (focus_path disconnects itself) on the TreeView side, but that
one also comes in too early.

And right before getting some rest, it struck me that I should be
looking into the size-request and size-allocate signals. The latter is
the right one and that's indeed getting me the focus where it should be!
\o/ I suppose this isn't entirely crazy since that's an idea you had as
well. :)

… back to MR #12, I'm a little reluctant to changing the workaround at
this stage. After all, I've run a bunch of test cases already, which all
looked good, and while reverting the initial workaround would mean less
code / technical debt, all those lines should go away in bookworm
anyway. So I think I would *slightly* prefer paper over the focus
regression (this bug) with an extra callback. I would have to need to
power up coffee and brain a little more though. :)

Thanks for all your feedback, much appreciated as always.


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


signature.asc
Description: PGP signature

Bug#989012: linphone: DTMF tones seem to be incorrect

[Dennis Filder]

Control: tag -1 unreproducible moreinfo

On Sun, May 23, 2021 at 03:14:42PM +0200, Detlef Vollmann wrote:

> When dialling into a telephone conference system the DTMF tones
> for the conference ID produced by the popup keypad are not
> recognized by the system.
> I'm not even sure that I used the correct keypad, as it has an
> additional column with letters, but I couldn't find another one.
> With the old version from buster I don't have such problems.

Linphone supports two different modes for sending DTMF (default: RFC
2833).  You can configure which to use under: Menu -> Preferences ->
Network -> Transport -> DTMFs sending method

Let me know if switching that fixes this for you.  Also, could you
tell me which teleconferencing system you're connecting to (vendor,
product, version)?  That information can be helpful in tracking
interoperability problems.

Regards,
Dennis.

Bug#989020: linux-image-5.9.0-5-sh7751r entirely fails to boot in qemu-system-sh4

[Rich Ercolani]

Package: src:linux
Version: 5.9.15-1
Severity: normal
X-Debbugs-Cc: rincebr...@gmail.com

Dear Maintainer,

On a lark, I decided to try and get a sh4 boot environment running. So I
tried downloading the oldest (2019-11-21, with vmlinuz-4.19.0-5-sh7751r) 
and newest (2021-04-17, with vmlinuz-5.9.0-5-sh7751r) debian-installer 
tarballs, and they both did the same thing in qemu - no serial output, no 
graphical output.

So I found https://people.debian.org/~aurel32/qemu/sh4/, and tried booting
that kernel and initrd with my qemu command, and that worked fine.

So next I tried a debootstrap --arch=sh4 sh4_chroot, chrooted in, installed
the kernel (linux-image-5.9.0-5-sh7751r), generated an initrd, partitioned
the disk image file I made before, mkfs.ext4, rsync -avx everything over,
try booting with the kernel+initrd from the chroot...same result.

The qemu line I used is:
qemu-system-sh4 -M r2d -serial null -serial mon:stdio -m 1024 -usb -usbdevice 
keyboard -kernel sh4_chroot/boot/vmlinuz-5.9.0-5-sh7751r -initrd 
sh4_chroot/boot/initrd.img-5.9.0-5-sh7751r -drive file=sh4_disk,format=raw 
-append "root=/dev/sda1 console=tty0 noiotrap" -vnc :30

The qemu version is 5.2+dfsg-9~bpo10+1.

It's certainly possible that I could be holding it wrong, and something has
changed between 2.6.32 and 4.19.0 that means I need a different command line,
but I'm kind of surprised if the same command doesn't at least produce
_some_ output, and unsurprisingly it's quite difficult to find documentation
on how to do this properly.

- Rich

-- Package-specific info:
** Kernel log: boot messages should be attached


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

Kernel: Linux 4.19.0-16-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=/usr/bin/locale: Cannot set 
LC_MESSAGES to default locale: No such file or directory
/usr/bin/locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages linux-image-5.9.0-5-sh7751r depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.140
ii  kmod28-1
ii  linux-base  4.6

Versions of packages linux-image-5.9.0-5-sh7751r recommends:
ii  apparmor 2.13.6-10
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-5.9.0-5-sh7751r suggests:
pn  debian-kernel-handbook  
pn  linux-doc-5.9   

Versions of packages linux-image-5.9.0-5-sh7751r is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

Bug#989018: unblock: imv/4.2.0-1.1

[Baptiste Beauplat]

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

Please unblock package imv

[ Reason ]

- Non-key package
- No autopkgtest
- Fixes RC bug (#987536)

[ Impact ]

Low, this is a trivial fix for a FTBFS without internet access (one
B-D added).

[ Tests ]

The fix only affects generated manpages. I've confirmed, using diffoscope
that there is no changes to the previous version of the binary package,
except from some build metadata embeded in the manpage (timestamp and
version).

[ Risks ]

Very low:

- Changes are trivial
- Leaf package
- No functional changes
- Patch is taken from ubuntu

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

- Non-maintainer upload

unblock imv/4.2.0-1.1

-- 
Baptiste Beauplat - lyknode
diff -Nru imv-4.2.0/debian/changelog imv-4.2.0/debian/changelog
--- imv-4.2.0/debian/changelog  2021-01-31 13:03:12.0 +0100
+++ imv-4.2.0/debian/changelog  2021-05-18 13:51:05.0 +0200
@@ -1,3 +1,12 @@
+imv (4.2.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build-depend on docbook-xsl so that xsltproc doesn't try to access
+the internet for the stylesheet. Works around #980930. Thanks to Logan
+Rosen  for the patch. (Closes: #987536)
+
+ -- Baptiste Beauplat   Tue, 18 May 2021 13:51:05 +0200
+
 imv (4.2.0-1) unstable; urgency=medium
 
   * New upstream version 4.2.0.
diff -Nru imv-4.2.0/debian/control imv-4.2.0/debian/control
--- imv-4.2.0/debian/control2021-01-31 13:01:39.0 +0100
+++ imv-4.2.0/debian/control2021-05-18 13:49:39.0 +0200
@@ -6,6 +6,7 @@
 Build-Depends:
  asciidoc-base,
  debhelper-compat (= 13),
+ docbook-xsl,
  libcmocka-dev,
  libegl1-mesa-dev,
  libfreeimage-dev,


signature.asc
Description: PGP signature

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

[Salman Mohammadi]

Hi Nicholas,

On 5/23/21 5:21 PM, Nicholas D Steeves wrote:
On Sat, 22 May 2021 at 10:51, David Bremner > wrote:

>
> Salman Mohammadi mailto:sal...@smoha.org>> writes:
>
> > 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.


Salman, are you asking for a natural short, like piping a newline 
separated list to "sort -V" would provide?  I think this is what 
you're asking for.


David, AFAIK Emacs doesn't yet provide a natural sort algorithm, but 
is there any reason why it wouldn't be a good idea to pass the data to 
"sort -V" before outputting to the *APT package info* buffer?  I guess 
there's also the question of if a non-interactive call to 
apt-utils-search should return a natural sorted list...


But isn't the big question:  If a user-friendly natural sorted list is 
a reasonable expectation, shouldn't "apt (and aptitude) search" do 
this directly?  Better to fix it there, rather than in a way specific 
to debian-el, no?


Cheers,
Nicholas


I didn't mean exactly something like "sort -V" but an order in which 
something-here-24 does not fall behind something-here-3. My mistake was 
that I hadn't checked `apt search` for this behavior before filing a bug 
here. Apt gives the same order.


Here is the related bug, https://bugs.debian.org/681164 and already 
labeled as 'wontfix'.



Thanks, Salman

Bug#989017: pulseaudio-equalizer: No sound when Equalizer selected.

[Hoareau J.P.]

Package: pulseaudio-equalizer
Version: 14.2-2
Severity: important
X-Debbugs-Cc: hoarea...@orange.fr

Dear Maintainer,
Pulseaudio does not broadcast any sound when the "pulseaudio-equalizer"
equalizer is selected via pulseaudio (example playback> audacious> FFT based
equalizer on PCMxxx Audio codec stereo). This happens regardless of the
playback source. The equalizer is therefore useless.
The equalizer appear on the screen but as no effect on the sound.

Regards
Hoareau Jean Pierre


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

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

Versions of packages pulseaudio-equalizer depends on:
ii  libc62.31-12
ii  libdbus-1-3  1.12.20-2
ii  libfftw3-single3 3.3.8-2
ii  libpulse014.2-2
ii  pulseaudio   14.2-2
ii  python3  3.9.2-3
ii  python3-dbus 1.2.16-5
ii  python3-dbus.mainloop.pyqt5  5.15.2+dfsg-3
ii  python3-pyqt55.15.2+dfsg-3

pulseaudio-equalizer recommends no packages.

pulseaudio-equalizer suggests no packages.

Bug#989009: python-ddt: diff for NMU version 1.4.1-2.1

[Stefano Rivera]

Control: tags 989009 + pending


Dear maintainer,

I've prepared an NMU for python-ddt (versioned as 1.4.1-2.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

SR
diff -Nru python-ddt-1.4.1/debian/changelog python-ddt-1.4.1/debian/changelog
--- python-ddt-1.4.1/debian/changelog	2020-10-14 04:11:28.0 -0400
+++ python-ddt-1.4.1/debian/changelog	2021-05-23 11:51:10.0 -0400
@@ -1,3 +1,11 @@
+python-ddt (1.4.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Patch: Support pyyaml's security patch in 5.3.1-4 (from 5.4 upstream).
+(Closes: #989009)
+
+ -- Stefano Rivera   Sun, 23 May 2021 11:51:10 -0400
+
 python-ddt (1.4.1-2) unstable; urgency=medium
 
   * Uploading to unstable.
diff -Nru python-ddt-1.4.1/debian/patches/pyyaml-unsafeloader.patch python-ddt-1.4.1/debian/patches/pyyaml-unsafeloader.patch
--- python-ddt-1.4.1/debian/patches/pyyaml-unsafeloader.patch	1969-12-31 20:00:00.0 -0400
+++ python-ddt-1.4.1/debian/patches/pyyaml-unsafeloader.patch	2021-05-23 11:50:57.0 -0400
@@ -0,0 +1,56 @@
+From 97f0a2315736e50f1b34a015447cd751da66ecb6 Mon Sep 17 00:00:00 2001
+From: Dirk Mueller 
+Date: Mon, 25 Jan 2021 22:49:04 +0100
+Subject: [PATCH] Use Yaml's UnsafeLoader for Python embedding tests
+
+In newer PyYAML versions the default FullLoader has
+python/object/* integration removed. One has to use
+UnsafeLoader instead. see this issue for details:
+
+https://github.com/yaml/pyyaml/issues/321
+Bug-Debian: https://bugs.debian.org/989009
+---
+ test/test_example.py|  2 +-
+ test/test_functional.py | 10 +-
+ 2 files changed, 6 insertions(+), 6 deletions(-)
+
+--- a/test/test_example.py
 b/test/test_example.py
+@@ -151,7 +151,7 @@
+ 
+ @ddt
+ class YamlOnlyTestCase(unittest.TestCase):
+-@file_data('data/test_custom_yaml_loader.yaml', yaml.FullLoader)
++@file_data('data/test_custom_yaml_loader.yaml', yaml.UnsafeLoader)
+ def test_custom_yaml_loader(self, instance, expected):
+ """Test with yaml tags to create specific classes to compare"""
+ self.assertEqual(expected, instance)
+--- a/test/test_functional.py
 b/test/test_functional.py
+@@ -427,7 +427,7 @@
+ loader allowing python tags is passed.
+ """
+ 
+-from yaml import FullLoader
++from yaml import UnsafeLoader
+ from yaml.constructor import ConstructorError
+ 
+ def str_to_type(class_name):
+@@ -444,13 +444,13 @@
+ raise AssertionError()
+ 
+ @ddt
+-class YamlFullLoaderTest(object):
+-@file_data('data/test_functional_custom_tags.yaml', FullLoader)
++class YamlUnsafeLoaderTest(object):
++@file_data('data/test_functional_custom_tags.yaml', UnsafeLoader)
+ def test_cls_is_instance(self, instance, expected):
+ assert isinstance(instance, str_to_type(expected))
+ 
+-tests = list(filter(_is_test, YamlFullLoaderTest.__dict__))
+-obj = YamlFullLoaderTest()
++tests = list(filter(_is_test, YamlUnsafeLoaderTest.__dict__))
++obj = YamlUnsafeLoaderTest()
+ 
+ if not tests:
+ raise AssertionError('No tests have been found.')
diff -Nru python-ddt-1.4.1/debian/patches/series python-ddt-1.4.1/debian/patches/series
--- python-ddt-1.4.1/debian/patches/series	1969-12-31 20:00:00.0 -0400
+++ python-ddt-1.4.1/debian/patches/series	2021-05-23 11:50:33.0 -0400
@@ -0,0 +1 @@
+pyyaml-unsafeloader.patch

Bug#988998: lava: diff for NMU version 2020.12-4.1

[Stefano Rivera]

Control: tags 988998 + pending

Dear maintainer,

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

Regards,

SR
diff -Nru lava-2020.12/debian/changelog lava-2020.12/debian/changelog
--- lava-2020.12/debian/changelog	2021-05-12 09:34:00.0 -0400
+++ lava-2020.12/debian/changelog	2021-05-23 11:34:54.0 -0400
@@ -1,3 +1,11 @@
+lava (2020.12-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Patch: Support pyyaml's security patch in 5.3.1-4 (from 5.4 upstream).
+(Closes: #988998)
+
+ -- Stefano Rivera   Sun, 23 May 2021 11:34:54 -0400
+
 lava (2020.12-4) unstable; urgency=medium
 
   * Reinstate /etc/logrotate.d/lava-scheduler-log with the original contents
diff -Nru lava-2020.12/debian/patches/0002-Add-yaml_unsafe_load.patch lava-2020.12/debian/patches/0002-Add-yaml_unsafe_load.patch
--- lava-2020.12/debian/patches/0002-Add-yaml_unsafe_load.patch	1969-12-31 20:00:00.0 -0400
+++ lava-2020.12/debian/patches/0002-Add-yaml_unsafe_load.patch	2021-05-23 11:34:51.0 -0400
@@ -0,0 +1,90 @@
+From f09a08701539cf022f7507e376f26d2a3229a607 Mon Sep 17 00:00:00 2001
+From: Marc Deslauriers 
+Date: Sun, 23 May 2021 11:18:22 -0400
+Subject: [PATCH] Add yaml_unsafe_load
+
+And use it in test as some constructiors were removed in pyyaml security update
+
+Bug-Debian: https://bugs.debian.org/988998
+Forwarded: https://git.lavasoftware.org/lava/lava/-/issues/488
+
+---
+ lava_common/compat.py | 9 +
+ tests/lava_dispatcher/test_multinode.py   | 4 ++--
+ tests/lava_scheduler_app/test_pipeline.py | 4 ++--
+ 3 files changed, 13 insertions(+), 4 deletions(-)
+
+diff --git a/lava_common/compat.py b/lava_common/compat.py
+index dd35282fc..c8c981701 100644
+--- a/lava_common/compat.py
 b/lava_common/compat.py
+@@ -45,6 +45,10 @@ try:
+ from yaml import CSafeLoader as SafeLoader
+ except ImportError:
+ from yaml import SafeLoader
++try:
++from yaml import CUnsafeLoader as UnsafeLoader
++except ImportError:
++from yaml import UnsafeLoader
+ try:
+ from yaml import CSafeDumper as SafeDumper
+ except ImportError:
+@@ -65,6 +69,11 @@ def yaml_safe_load(data):
+ return yaml.load(data, Loader=SafeLoader)
+ 
+ 
++# handle compatibility for yaml.unsafe_load
++def yaml_unsafe_load(data):
++return yaml.load(data, Loader=UnsafeLoader)
++
++
+ # handle compatibility for yaml.dump
+ def yaml_dump(data, *args, **kwargs):
+ return yaml.dump(data, *args, Dumper=Dumper, **kwargs)
+diff --git a/tests/lava_dispatcher/test_multinode.py b/tests/lava_dispatcher/test_multinode.py
+index fee427cdd..e7a96b117 100644
+--- a/tests/lava_dispatcher/test_multinode.py
 b/tests/lava_dispatcher/test_multinode.py
+@@ -23,7 +23,7 @@ import os
+ import uuid
+ import json
+ 
+-from lava_common.compat import yaml_dump, yaml_load
++from lava_common.compat import yaml_dump, yaml_unsafe_load
+ from lava_common.constants import LAVA_MULTINODE_SYSTEM_TIMEOUT
+ from lava_common.timeout import Timeout
+ from lava_common.exceptions import TestError, JobError, InfrastructureError
+@@ -283,7 +283,7 @@ class TestMultinode(StdoutTestCase):
+ for action in self.client_job.pipeline.actions:
+ data = action.explode()
+ data_str = yaml_dump(data)
+-yaml_load(data_str)  # nosec not suitable for safe_load
++yaml_unsafe_load(data_str)  # nosec not suitable for safe_load
+ 
+ def test_multinode_timeout(self):
+ """
+diff --git a/tests/lava_scheduler_app/test_pipeline.py b/tests/lava_scheduler_app/test_pipeline.py
+index 1f58dfba5..3cc058dfa 100644
+--- a/tests/lava_scheduler_app/test_pipeline.py
 b/tests/lava_scheduler_app/test_pipeline.py
+@@ -26,7 +26,7 @@ from lava_scheduler_app.schema import (
+ SubmissionException,
+ )
+ 
+-from lava_common.compat import yaml_load
++from lava_common.compat import yaml_unsafe_load
+ from lava_dispatcher.device import PipelineDevice
+ from lava_dispatcher.parser import JobParser
+ from tests.lava_dispatcher.test_defs import check_missing_path
+@@ -1127,7 +1127,7 @@ class TestYamlMultinode(TestCaseWithFactory):
+ meta_dict,
+ )
+ # simulate dynamic connection
+-dynamic = yaml_load(  # nosec - not suitable for safe_load
++dynamic = yaml_unsafe_load(  # nosec - not suitable for safe_load
+ open(
+ os.path.join(
+ os.path.dirname(__file__),
+-- 
+2.30.2
+
diff -Nru lava-2020.12/debian/patches/series lava-2020.12/debian/patches/series
--- lava-2020.12/debian/patches/series	2021-05-12 09:34:00.0 -0400
+++ lava-2020.12/debian/patches/series	2021-05-23 11:34:10.0 -0400
@@ -1 +1,2 @@
 0001-lava_rest_app-fix-field-name-in-filters.patch
+0002-Add-yaml_unsafe_load.patch

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

[Nicholas D Steeves]

On Sat, 22 May 2021 at 10:51, David Bremner  wrote:
>
> Salman Mohammadi  writes:
>
> > 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.


Salman, are you asking for a natural short, like piping a newline separated
list to "sort -V" would provide?  I think this is what you're asking for.

David, AFAIK Emacs doesn't yet provide a natural sort algorithm, but is
there any reason why it wouldn't be a good idea to pass the data to "sort
-V" before outputting to the *APT package info* buffer?  I guess there's
also the question of if a non-interactive call to apt-utils-search should
return a natural sorted list...

But isn't the big question:  If a user-friendly natural sorted list is a
reasonable expectation, shouldn't "apt (and aptitude) search" do this
directly?  Better to fix it there, rather than in a way specific to
debian-el, no?

Cheers,
Nicholas

Bug#988986: ABI change in tinyxml2 8.1.0+dfsg-1

[Joachim Reichel]

For the missing major version/SONAME change I've created an issue in the upstream github project: 
https://github.com/leethomason/tinyxml2/issues/867


Best regards,
  Joachim

Bug#989015: ITP: catfishq -- concatenates fastq files

[Steffen Möller]

Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: catfishq
  Version : 1.1.3+ds
  Upstream Author : philres
* URL : https://github.com/philres/catfishq
* License : MIT
  Programming Lang: Python
  Description : concatenates fastq files
 FASTQ is the most common format to store the reads from high-throughput
 biological sequencing. This tool takes paths to an arbritary number
 of zipped and unzipped FASTQ files and/or folders containing zipped or
 unzipped FASTQ files, concatenates them and prints them to standard out
 (default) or an unzipped output file.
 .
 Supported file extensions are: '*.fastq', '*.fastq.gz', '*.fasta',
 '*.fasta.gz', '*.fa', '*.fa.gz', '*.fq', '*.fq.gz'

Remark: This package is about to be team-maintained
   https://salsa.debian.org/med-team/catfishq

Bug#988632: audacity: The main drawing area (sound wave) do not refresh

[EnjoyLinuxLinux 好好玩實驗室]

On Wed, 19 May 2021 18:09:27 +0200 Dennis Filder  wrote:
> X-Debbugs-CC: poming...@gmail.com
>
> This appears to be known problem:
> https://forum.audacityteam.org/viewtopic.php?f=48&t=110214
>
> You could still investigate further by testing if similar behaviour
> manifests in other wxwidgets applications.  Running
>
> aptitude search '~Guitoolkit::wxwidgets'
>
> will give you a list.
>
> I suspect that the issue is due to GL rendering problems.  You could
> try changing some environment variables.  A list of available ones is
> here: https://docs.mesa3d.org/envvars.html
> LIBGL_ALWAYS_SOFTWARE=true would be the first thing I'd try.
>
> Beyond that I doubt there is much anyone could do.  Since you report
> that it works with the newest release compiled from source, I would
> recommend to just hope and wait for a backport/proposed update.
>
> Regards,
> Dennis.
>
>
Dennis,

  Thank you for your response. Let's hope that there will be a backport
in the future.

Best Regards,

pmlee

Bug#988360: pod2pdf: diff for NMU version 0.42-5.2

[gregor herrmann]

Control: tags 988360 + patch
Control: tags 988360 + pending


Dear maintainer,

I've prepared an NMU for pod2pdf (versioned as 0.42-5.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   
diff -Nru pod2pdf-0.42/debian/changelog pod2pdf-0.42/debian/changelog
--- pod2pdf-0.42/debian/changelog	2020-11-08 19:22:34.0 +0100
+++ pod2pdf-0.42/debian/changelog	2021-05-23 16:34:13.0 +0200
@@ -1,3 +1,12 @@
+pod2pdf (0.42-5.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "please use versioned Depends: libpod-parser-perl (>= 1.63)":
+do as the bug report suggests (closes: #988360).
+Thanks to Andreas Beckmann for the report and the solution.
+
+ -- gregor herrmann   Sun, 23 May 2021 16:34:13 +0200
+
 pod2pdf (0.42-5.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru pod2pdf-0.42/debian/control pod2pdf-0.42/debian/control
--- pod2pdf-0.42/debian/control	2020-11-08 19:17:40.0 +0100
+++ pod2pdf-0.42/debian/control	2021-05-23 16:31:48.0 +0200
@@ -4,7 +4,7 @@
 Build-Depends: debhelper (>= 9)
 Build-Depends-Indep: perl (>= 5.6.0-12),
   libfile-spec-perl,
-  libpod-parser-perl, libpod-escapes-perl,
+  libpod-parser-perl (>= 1.63), libpod-escapes-perl,
   libpdf-api2-perl (>= 0.6), libgetopt-argvfile-perl
 Maintainer: Guo Yixuan (郭溢譞) 
 Standards-Version: 3.9.5
@@ -16,7 +16,7 @@
 Architecture: all
 Depends: ${perl:Depends}, ${misc:Depends},
   libfile-spec-perl,
-  libpod-parser-perl, libpod-escapes-perl,
+  libpod-parser-perl (>= 1.63), libpod-escapes-perl,
   libpdf-api2-perl (>= 0.6), libgetopt-argvfile-perl
 Recommends: libimage-size-perl, libfile-type-perl
 Suggests: libpaper-specs-perl


signature.asc
Description: Digital Signature

Bug#989014: vcflib: executables in scripts/* are not packaged

[Steffen Möller]

Source: libvcflib
Severity: normal

A reminder to self.

Bug#989010: linux-image-5.10.0-7-amd64: No display (post, grub, boot messages and desktop) after the upgrade to 5.10.38

[jim_p]

Source: linux
Followup-For: Bug #989010
X-Debbugs-Cc: pitsior...@gmail.com

First of all, I removed 5.10.38 because I want grub to directly boot to the
working kernel without me having to select it via grub's advanced menu.

Yes, nvidia (340 legacy) is the reason the tainted message pops up. To be
honest, I don't really want to remove nvidia (because unloading is not a real
option), and let me explain why.
First, I have to remove and purge every single nvidia package, so as to be sure
nouveau isn't blacklisted somewhere and can be loaded. Second, I have to remove
nomodeset from my kernel's boot parameters, because nouveau needs modesetting
to work.
Third, because nouveau does not do proper powersaving for almost any gpu, I
will have to reinstall 5.10.38 and do all the testing while my gpu will be
running at max clock speeds, and all that in a room that has 30oC now. That is
the core reason I avoid and dislike nouveau.

For the forementioned reasons, I would like to stick to nvidia and continue
troubleshooting in a different way, e.g. why did the system went to sleep since
I had disabled it completely years ago? Or why it has affected my system so
much that even the post and grub were not shown?
I must mention that I have already checked the package changelog for 5.10.38
and it does not mention nvidia somewhere.

In other observations, my drive's precious space has gone down ~300MB after
that incident and I can't find out why. I do not have a swap file or partition,
apt's cache is in /tmp and /tmp is in ram (tmpfs).

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

[Simon McVittie]

On Sun, 23 May 2021 at 14:43:33 +0100, Simon McVittie wrote:
> When the GtkTreeView is resized as a result of the text being added,
> the top left corner of the visible area is what's preserved; if its
> selected row was near the bottom, the result is that the selected row
> is no longer visible.

You can see similar behaviour in the "Tree View -> List Store" example in
gtk-demo, gtk3-demo or gtk4-demo (from gtk2.0-examples, gtk-3-examples or
gtk-4-examples respectively). If you select an item low down the list,
then resize the window, you'll see that it's the top left corner that
stays fixed within the window, and the selected item doesn't necessarily
stay visible.

smcv

Bug#958784: emacs: Compose key fails with " is undefined" if XMODIFIERS is set

[Stéphane Chauveau]

I just noticed that problem yesterday with emacs-gtk and I want to point 
out that the feature/pgtk (Pure GTK) branch of emacs does not seem to be 
affected.


This new emacs-pgtk is a true GTK3 application unlike the old emacs-gtk 
which is an X11 app using GTK widgets (see 
https://emacshorrors.com/posts/psa-emacs-is-not-a-proper-gtk-application.html).


The branch can be found in 
http://git.savannah.gnu.org/cgit/emacs.git/log/?h=feature/pgtk or 
https://github.com/emacs-mirror/emacs/tree/feature/pgtk


As far as I can tell, this new backend is working fine. You may have to 
update your .emacs if it relies on some X11 specific features (e.g. such 
as comparing window-system to 'x). Apart from fixing a few integration 
issues such as this one, another advantage of a pure gtk build is that 
it can run as a native Wayland application.


Hopefully, it will be officially included soon in emacs.

Bug#989013: fortunes-de: Spelling error: Alleinherrscer

[Hilmar Preuße]

Package: fortunes-de
Version: 0.34-1
Severity: minor

For any reasopn the word Alleinherrscer is spelled wrongly all times it
appears:

hille@haka2:/usr/share/games/fortunes/de$ grep Alleinherrsce *
zitate:Mit einem schlechten Alleinherrscer aber kann niemand
zitate:Alleinherrscer. Nicht ohne Grund vergleicht man die Stimme des Volkes
zitate:Wer sich zum Alleinherrscer erhebt und Brutus nicht tötet, oder wer
zitate.u8:Mit einem schlechten Alleinherrscer aber kann niemand
zitate.u8:Alleinherrscer. Nicht ohne Grund vergleicht man die Stimme des Volkes
zitate.u8:Wer sich zum Alleinherrscer erhebt und Brutus nicht tötet, oder wer

Consider to fix that.



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

Kernel: Linux 4.19.0-16-amd64 (SMP w/4 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=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fortunes-de depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  fortune-mod1:1.99.1-7+b1

fortunes-de recommends no packages.

fortunes-de suggests no packages.

-- debconf information:
  fortunes-de/fortunes_to_install: Anekdoten, ASCIIart, Bahnhof, Bauernregeln, 
Computer, Debian Tips, Elefanten, Fußball, Gedichte, Holenlassen, Huhn, Kinder, 
Letzte Worte, Lieber als, Löwe, Mathematiker, MS, Murphy, Namen, Quiz, 
Sicherheitshinweise, Sprichworte, Sprüche, Stilblüten, Tips, Translations, 
Unfug, Vornamen, Warmduscher, Witze, Wörterbuch, Wußten Sie, Zitate

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

[Simon McVittie]

On Sun, 23 May 2021 at 11:31:58 +0100, Simon McVittie wrote:
> >  - 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).
> 
> I can read French somewhat better than Swedish (and infinitely better
> than Sinhala where I don't even recognise the glyphs), so this is probably
> the more convenient test-case :-)

I can reproduce something similar with more defaults, like this:

* accept defaults (in particular en_US) until you reach the list of
  USA mirrors
* choose the last mirror
* the next question asks for a proxy; do not answer, but instead "Go back"
* good result: the mirror you chose is focused and visible
* bad result: the mirror you chose is focused but you have to scroll with
  the mouse to be able to see that

> > I suppose we have a slightly taller widget at
> > first, we scroll down to the bottom; then when set_text_in_idle happens,
> > the widget is resized slightly smaller, the position is not correct
> > anymore (it's no longer “full-bottom” but a little higher as seen in the
> > scrollbar), and the selected line gets out of sight.

I think you're correct. Deferring addition of the text to the GtkTextView
means the initial window layout for select/multiselect questions will
be done based on the assumption that there is no text, which means the
GtkTreeView will receive nearly the full window height. When we scroll
the GtkTreeView to bring the selected row into view, that also happens
before the text is added (I think we probably draw one frame without the
text, then add the text in the next frame).

When the GtkTreeView is resized as a result of the text being added,
the top left corner of the visible area is what's preserved; if its
selected row was near the bottom, the result is that the selected row
is no longer visible.

> > I've tried various things like having the focus_path happens in a
> > “_later” indirection using the same kind of logic as Simon introduced
> > for setting the text (with a different priority), but that would happen
> > waaay before set_text_in_idle anyway.
> 
> Please could you share what you tried so I can check whether it's doing
> something wrong? I feel as though this approach ought to be workable

Actually, never mind: the code structure for this gets increasingly messy,
with components needing to know about implementation details of unrelated
components. I think that's technical debt we probably don't want to pay.

I have a couple of ideas for possible ways to deal with this.

One idea is to undo my workaround for #988787 on the cdebconf side,
and instead, hook onto the GtkTextView's size-request signal and force
it to be allocated with at least some arbitrary reasonable size (I'm
trying 300px). This will hopefully still work around #988787, and if
it doesn't, we have the workaround #988786 in GTK as a fallback.
https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/12

Another idea, still in cdebconf, is to connect to whatever signal is
emitted when the GtkTreeView is resized (I think this is size-allocate?),
and take that opportunity to re-adjust the scroll position so the (first)
selected row comes into view. However, I'm a bit concerned that this
could itself cause an infinite loop like #988787 - I'd have to check
the GtkTreeView implementation to make sure scrolling cannot schedule
a resize.

smcv

Bug#895378: sky2: sky2: did not recover correctly after waking up from S3

[Manuel Bilderbeek]

Yes, it is. Just had it yesterday with an updated testing.

Op zo 23 mei 2021 14:58 schreef Salvatore Bonaccorso :

> Control: tags -1 + moreinfo
>
> Hi,
>
> On Sun, Oct 14, 2018 at 11:21:32AM +0200, Laurent Bigonville wrote:
> > Source: linux
> > Version: 4.18.10-2
> > Followup-For: Bug #895378
> >
> > Hi,
> >
> > I can confirm this (and it's quite annoying).
> >
> > It worked fine in 4.14 and it's broken since 4.15.
> >
> > I'm trying to bissect the kernel but it is not even booting ("32-bits
> > relocation outside of the kernel) and I'm not too sure how to fix that.
>
> Is this still an issue with a recent kernel?
>
> Regards,
> Salvatore
>

Bug#989012: linphone: DTMF tones seem to be incorrect

[Detlef Vollmann]

Package: linphone
Version: 4.2.5-3
Severity: important
X-Debbugs-Cc: d...@vollmann.ch

Dear Maintainer,


When dialling into a telephone conference system the DTMF tones
for the conference ID produced by the popup keypad are not
recognized by the system.
I'm not even sure that I used the correct keypad, as it has an
additional column with letters, but I couldn't find another one.
With the old version from buster I don't have such problems.

This is a bug report against the binary package linphone,
for which Debian unstable only provides 4.2.5-3, not against
the source package linphone, for which a newer version exists.

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

Kernel: Linux 5.10.0-6-rt-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND
Locale: LANG=POSIX, LC_CTYPE=C.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 linphone depends on:
ii  linphone-desktop  4.2.5-3

linphone recommends no packages.

linphone suggests no packages.

-- no debconf information

Bug#988584: manpages-hu: Contains undistributable content - All rights reserved

[Adrian Bunk]

On Sun, May 16, 2021 at 12:24:49PM +0200, Helge Kreutzmann wrote:
>...
> Short:
> man8/ssh.8 states:
> .\" Copyright (c) 1995 Tatu Ylonen , Espoo, Finland
> .\"All rights reserved

/usr/share/man/man1/ssh.1.gz in openssh-client (which is based on the 
later OpenSSH fork of this code) has this specific problem already resolved.

>...
> some require 
> redistribution of copyright information in binary versions (I'm not sure if 
> 2.3 Nr.3 remedies this), while others don't come with any statement at all.
> And debian/copyright places the burden of proof on the users in case comercial
> distribution is intended (e.g. Debian downstreams like Ubuntu). I wonder how
> this passed debian-legal?
>...

The 4-clause BSD license is clearly DFSG-free since it is listed as an 
example of a free license in section 10 of the DFSG (BSD licences with
fewer clauses did not exist at the time when the DFSG were written).

cu
Adrian

Bug#895378: sky2: sky2: did not recover correctly after waking up from S3

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi,

On Sun, Oct 14, 2018 at 11:21:32AM +0200, Laurent Bigonville wrote:
> Source: linux
> Version: 4.18.10-2
> Followup-For: Bug #895378
> 
> Hi,
> 
> I can confirm this (and it's quite annoying).
> 
> It worked fine in 4.14 and it's broken since 4.15.
> 
> I'm trying to bissect the kernel but it is not even booting ("32-bits
> relocation outside of the kernel) and I'm not too sure how to fix that.

Is this still an issue with a recent kernel?

Regards,
Salvatore

Bug#894403: linux-image-4.14.0-0.bpo.3-amd64: NAT66 (IPv6 SNAT masquerade) does not rewrite source address on kernel 4.14

[Salvatore Bonaccorso]

Control: tags -1 + moreinof

On Thu, Mar 29, 2018 at 09:40:38PM +0100, Rob Andrews wrote:
> Package: src:linux
> Version: 4.14.13-1~bpo9+1
> Severity: normal
> 
> Dear Maintainer,
> 
> I use Docker for application segregation on a remote server. The host has a 
> single v4 and a single v6 IP address allocated. On the host system, I have 
> NAT66 (SNAT, masquerading) setup with the following rules in order to provide 
> segregated IPv6 connectivity to Docker containers:
> 
> Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target prot opt in out source   
> destination 
> 0 0 DOCKER all  anyany anywhere anywhere  
>ADDRTYPE match dst-type LOCAL
> 
> Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target prot opt in out source   
> destination 
> 
> Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target prot opt in out source   
> destination 
> 0 0 DOCKER all  anyany anywhere anywhere  
>ADDRTYPE match dst-type LOCAL
> 
> Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target prot opt in out source   
> destination 
> 0 0 MASQUERADE  all  anydocker0  anywhere 
> anywhere ADDRTYPE match src-type LOCAL
> 0 0 MASQUERADE  all  any!docker0  fd00:bee:cafe::/64   
> anywhere
> 
> Chain DOCKER (2 references)
>  pkts bytes target prot opt in out source   
> destination 
> 
> On the standard stretch 4.9.x kernel, NAT66 works just fine as witnessed by 
> this tcpdump of a ping (note that the 2001:: address is that of the  
> record for debian.org):
> 
>   % sudo tcpdump -i ens3 -n 'not tcp and not udp'
>   tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>   listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes
>   19:56:24.980979 IP6 2a03:my:machines:v6:addr > 2001:41c8:1000:21::21:4: 
> ICMP6, echo request, seq 0, length 64
>   19:56:24.988597 IP6 2001:41c8:1000:21::21:4 > 2a03:my:machines:v6:addr: 
> ICMP6, echo reply, seq 0, length 64
>   19:56:25.981716 IP6 2a03:my:machines:v6:addr > 2001:41c8:1000:21::21:4: 
> ICMP6, echo request, seq 1, length 64
>   19:56:25.989010 IP6 2001:41c8:1000:21::21:4 > 2a03:my:machines:v6:addr: 
> ICMP6, echo reply, seq 1, length 64
>   19:56:26.982894 IP6 2a03:my:machines:v6:addr > 2001:41c8:1000:21::21:4: 
> ICMP6, echo request, seq 2, length 64
> 1  9:56:26.990022 IP6 2001:41c8:1000:21::21:4 > 2a03:my:machines:v6:addr: 
> ICMP6, echo reply, seq 2, length 64
> 
> Whilst on the backports kernel 4.14.x, NAT66 fails to rewrite the source 
> address, and all IPv6 traffic (not just ICMP) fails as a result:
> 
>   % sudo tcpdump -i ens3 -n 'not tcp and not udp'
>   tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>   listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes
>   20:00:39.711554 IP6 fd00:bee:cafe::242:ac11:2 > 2001:41c8:1000:21::21:4: 
> ICMP6, echo request, seq 0,length 64
>   20:00:40.712591 IP6 fd00:bee:cafe::242:ac11:2 > 2001:41c8:1000:21::21:4: 
> ICMP6, echo request, seq 1,length 64
>   20:00:41.713768 IP6 fd00:bee:cafe::242:ac11:2 > 2001:41c8:1000:21::21:4: 
> ICMP6, echo request, seq 2,length 64
>   20:00:42.714934 IP6 fd00:bee:cafe::242:ac11:2 > 2001:41c8:1000:21::21:4: 
> ICMP6, echo request, seq 3,length 64
>   20:00:43.716088 IP6 fd00:bee:cafe::242:ac11:2 > 2001:41c8:1000:21::21:4: 
> ICMP6, echo request, seq 4,length 64
>   20:00:44.717264 IP6 fd00:bee:cafe::242:ac11:2 > 2001:41c8:1000:21::21:4: 
> ICMP6, echo request, seq 5,length 64
> 
> The expected behaviour is what is witnessed with kernel 4.9.x - the source 
> address is rewritten with the outgoing interface address.
> 
> Ignoring the Docker aspect of this, the witnessed behaviour can be reproduced 
> without having to use a container: use 'ping6 -I  
> debian.org'. You'll need to setup some NAT66 rules and create a virtual 
> interface with a ULA address to simulate the behaviour - this stanza in an 
> interfaces file will suffice (make sure you have bridge-utils installed):
> 
>   iface br-nat-virt inet6 static
>   bridge_ports none
>   address fd00:bee:f00d:cafe::1/64
> 
> And the following NAT66 rule:
> 
>   ip6tables -A POSTROUTING -s fd00:bee:f00d:cafe::/64 ! -o br-nat-virt -j 
> MASQUERADE
> 
> Then reproduce the behaviour using 'ping6 -I fd00:bee:f00d:cafe::1 
> debian.org'.
> 
> I hope this makes sense. It's not a major biggy, I'm just falling back to 
> using the non-backports kernel in stretch in the meantime.

is this issue still reproducible with a recent kernel from unstable or
buster backports?

Regards,
Salvatore

Bug#851404: closed by car...@debian.org (Closing this bug (BTS maintenance for src:linux bugs))

[michael]

Am 2021-05-15 13:57, schrieb Debian Bug Tracking System:

This is an automatic notification regarding your Bug report
which was filed against the src:linux package:

#851404: linux-image-4.8.0-2-amd64: Internal speakers don't work after
standby on a Toshiba z20t-c-121

It has been closed by car...@debian.org.

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact car...@debian.org 
by

replying to this email.


Good day,

sadly, I can still reproduce this bug with 5.10.0-0.bpo.3-amd64 #1 SMP 
Debian 5.10.13-1~bpo10+1 (2021-02-11) x86_64 GNU/Linux.


Best regards,
Michael Fritscher

Bug#988724: firefox: Firefox 88 unusable on intel gpu

[Kamil Jońca]

Mike Hommey  writes:

> On Tue, May 18, 2021 at 07:39:27PM +0200, Kamil Jońca wrote:
>> Package: firefox
>> Version: 87.0-2
>> Severity: important
>> X-Debbugs-Cc: kjo...@poczta.onet.pl
>> 
>> Dear Maintainer,
>> 
>> *** Reporter, please consider answering these questions, where appropriate 
>> ***
>> 
>>* What led up to the situation?
>> Upgrade to 88.0.1 version
>>* What exactly did you do (or not do) that was effective (or
>>  ineffective)?
>> Start firefox 
>> 
>>* What was the outcome of this action?
>> white window, not responsive.
>> 
>>* What outcome did you expect instead?
>> 
>> Normally functioning firefox.
>> 
>> *** End of the template - remove these template lines ***
>
> In Firefox 87, can you go to about:support and copy/paste its content?
>

To record: I experimented after issuing bug and found that I have file
for load intel drivers.:

--8<---cut here---start->8---
%cat /etc/X11/xorg.conf.d/10-intel.conf
Section "Device"
   Identifier  "Intel"
   Driver  "intel"
   BusID   "PCI:0:2:0"
EndSection
--8<---cut here---end--->8---

When I commented out this file (which I believe makes that x.org uses
"modesetting" driver), firefox 88 starts to work.

So now I am not sure if it is bug in firefox or in intel driver.

After uncommenting back this file data from firefox 87 are:
Application Basics
--

Name: Firefox
Version: 87.0
Build ID: 20210318103112
Distribution ID:
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0
OS: Linux 5.10.0-6-amd64 #1 SMP Debian 5.10.28-1 (2021-04-09)
Multiprocess Windows: 1/1
Fission Windows: 0/1 Disabled by default
Remote Processes: 4
Enterprise Policies: Inactive
Google Location Service Key: Found
Google Safebrowsing Key: Found
Mozilla Location Service Key: Found
Safe Mode: false

Crash Reports for the Last 3 Days
-

Firefox Features


Name: DoH Roll-Out
Version: 2.0.0
ID: doh-roll...@mozilla.org

Name: Firefox Screenshots
Version: 39.0.0
ID: screensh...@mozilla.org

Name: Form Autofill
Version: 1.0
ID: formautof...@mozilla.org

Name: Web Compatibility Interventions
Version: 20.1.0
ID: webcom...@mozilla.org

Name: WebCompat Reporter
Version: 1.4.0
ID: webcompat-repor...@mozilla.org

Remote Features
---

bug-1701297-rollout-turn-off-networkjarrecord_failure_reason-release-87-88: 
active

Remote Processes


Type: Web Content
Count: 1 / 8

Type: Privileged About
Count: 1

Type: Extension
Count: 1

Type: Preallocated
Count: 1

Add-ons
---

Name: Amazon.com
Type: extension
Version: 1.3
Enabled: true
ID: amazondot...@search.mozilla.org

Name: Bing
Type: extension
Version: 1.3
Enabled: true
ID: b...@search.mozilla.org

Name: DuckDuckGo
Type: extension
Version: 1.1
Enabled: true
ID: d...@search.mozilla.org

Name: Google
Type: extension
Version: 1.1
Enabled: true
ID: goo...@search.mozilla.org

Name: Wikipedia (en)
Type: extension
Version: 1.1
Enabled: true
ID: wikipe...@search.mozilla.org

Graphics


Features
Compositing: Basic
Asynchronous Pan/Zoom: wheel input enabled; scrollbar drag enabled; keyboard 
enabled; autoscroll enabled; smooth pinch-zoom enabled
WebGL 1 Driver WSI Info: GLX 1.4 GLX_VENDOR(client): Mesa Project and SGI 
GLX_VENDOR(server): SGI Extensions: GLX_ARB_create_context 
GLX_ARB_create_context_no_error GLX_ARB_create_context_profile 
GLX_ARB_create_context_robustness GLX_ARB_fbconfig_float 
GLX_ARB_framebuffer_sRGB GLX_ARB_get_proc_address GLX_ARB_multisample 
GLX_EXT_create_context_es2_profile GLX_EXT_create_context_es_profile 
GLX_EXT_fbconfig_packed_float GLX_EXT_framebuffer_sRGB GLX_EXT_import_context 
GLX_EXT_swap_control GLX_EXT_texture_from_pixmap GLX_EXT_visual_info 
GLX_EXT_visual_rating GLX_INTEL_swap_event GLX_MESA_copy_sub_buffer 
GLX_MESA_query_renderer GLX_MESA_swap_control GLX_OML_swap_method 
GLX_OML_sync_control GLX_SGIS_multisample GLX_SGIX_fbconfig GLX_SGIX_pbuffer 
GLX_SGIX_visual_select_group GLX_SGI_make_current_read GLX_SGI_swap_control 
GLX_SGI_video_sync IsWebglOutOfProcessEnabled: 0
WebGL 1 Driver Renderer: Intel -- Mesa Intel(R) UHD Graphics 620 (WHL GT2)
WebGL 1 Driver Version: 4.6 (Compatibility Profile) Mesa 20.3.5
WebGL 1 Driver Extensions: GL_ARB_multisample GL_EXT_abgr GL_EXT_bgra 
GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract 
GL_EXT_copy_texture GL_EXT_subtexture GL_EXT_texture_object GL_EXT_vertex_array 
GL_EXT_compiled_vertex_array GL_EXT_texture GL_EXT_texture3D 
GL_IBM_rasterpos_clip GL_ARB_point_parameters GL_EXT_draw_range_elements 
GL_EXT_packed_pixels GL_EXT_point_parameters GL_EXT_rescale_normal 
GL_EXT_separate_specular_color GL_EXT_texture_edge_clamp 
GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp 
GL_SGIS_texture_lod GL_ARB_framebuffer_sRGB GL_ARB_multitexture 
GL_EXT_framebuffer_sRGB GL_IBM_multimode_draw_arrays 
GL_IBM_texture_mi

Bug#889831: USB rndis_host - slow download transfers, RX errors

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi Tomas,

[Dropping the broader lists for this reply only]

On Thu, Feb 08, 2018 at 12:02:42PM -0500, Tomasz Janowski wrote:
> On Thursday, February 8, 2018 5:37:25 PM EST Greg KH wrote:
> > On Thu, Feb 08, 2018 at 10:53:20AM -0500, Tomasz Janowski wrote:
> > > On Thursday, February 8, 2018 3:43:05 PM EST Greg KH wrote:
> > > > On Thu, Feb 08, 2018 at 02:16:08PM +, Tomasz Janowski, Ph.D. wrote:
> > > > > Dear USB developers,
> > > > > 
> > > > > Based on my google research, the problem I experience seems to happen
> > > > > with some newer smartphones. My test case is Samsung Galaxy S8
> > > > > (SM-950U1).
> > > > > I am trying to use USB tethering and everything seems to work as
> > > > > expected
> > > > > (modules are loaded, Ethernet devices are up and running, dhcp works
> > > > > fine). I can connect to the external world using both LTE or wireless
> > > > > network on the phone.
> > > > > 
> > > > > Now, the problem is that the download speeds are terrible, around 64
> > > > > KB/s,
> > > > > while uploads are fast, the order of 15 MB/s. These speeds do not
> > > > > depend
> > > > > on the wireless service provider: the results are similar when I
> > > > > tether
> > > > > wi-fi. The USB Ethernet interface on the Linux host reports a lot of
> > > > > receive errors (attached: device_state.txt), while kernel reports bad
> > > > > rndis messages (attached: kernel.log.txt).
> > > > > 
> > > > > Windows 10 works great with the same hardware (same PC and same
> > > > > phone),
> > > > > with uploads and downloads in the order of 150 Mbit/s, which is
> > > > > probably
> > > > > as fast as my wireless network can do. But some people reported issues
> > > > > with older Windows drivers too. Is possible that some newer version of
> > > > > RNDIS protocol is around and Linux hasn't updated its RNDIS module
> > > > > yet?
> > > > 
> > > > Hey, I was _just_ talking to someone at Google about this same issue
> > > > yesterday, you beat him sending this same type of report to the mailing
> > > > list, nice job :)
> > > > 
> > > > Yes, this is not good, and we should work to resolve this, but first,
> > > > what kernel version are you using?  I think some fixes for the rndis
> > > > driver went in recently to 4.15, but it would be good to verify that
> > > > this isn't already resolved.
> > > 
> > > The error messages which I have attached were produced by a precompiled
> > > Debian kernel: "Linux version 4.14.0-0.bpo.3-amd64
> > > (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170516 (Debian
> > > 6.3.0-18)) #1 SMP Debian 4.14.13-1~bpo9+1 (2018-01-14)".
> > > 
> > > But I have downloaded the most recent version of the kernel from the
> > > official git repository (last commit: Jan 31, 2018) and it had exactly
> > > the same problem. Unless a patch was submitted within the last week, the
> > > issue is still there.
> > > 
> > > Should I get the version as of today and test it again?
> > 
> > If you find a 4.15 tree, that would be great to test, but odds are, the
> > issues are still there.
> > 
> > I'll try to carve out some time to look at this tomorrow, as I have a
> > bunch of Android devices to test with, and there's no good reason why
> > Windows should be slower than Linux for stuff like this.  We should be
> > able to go as fast as the device lets us.  Most likely we are doing
> > something "stupid" in the rndis driver somewhere :)
> > 
> Thanks a lot!
> 
> I have tested with kernel downloaded from:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> The version was 4.15.0+, so I guess that was cutting edge kernel as of 
> 01/31/2018.
> Just to clarify, Windows is faster than Linux. 64 KB/s in Linux makes the USB 
> tethering not so useful, and if the "PC" is a laptop, one can live with wi-fi 
> hotspot, which works fine. Desktop PC must use USB. I also thought that USB 
> has 
> a greater potential to deliver better throughput than wifi hotspot.
> 
> I have tested another phone, Galaxy J7 Pro (2017 version). That phone uses a 
> different hardware, different USB connector, and an older kernel version. J7 
> works fine with current Linux kernel, so it is necessary to use as recent 
> Android (and possibly hardware) as possible.

The thread stopped after the above message, and I see no further
followups.

Is this issue still reproducible with a recent kernel (from unstable
or buster backports)?

If so might be worth to reping the thread and try to get the ball
rolling again.

If it is not reproducible anymore we might just close the bugreport.

Regards,
Salvatore

Bug#988581: bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"

[Michael Albinus]

Michael Albinus  writes:

Hi Robert,

>> Thanks for that. It works for me now with emacs-27 (but not on master).
>
> Thanks for the feedback. My patch is dedicated to the emacs-27 branch
> only; once I get confirmation from Rob or Thomas, I'll push it, and I'll
> prepare a similar patch for master.
>
> One step after the other.

The latest commit shall work in master branch.

>> Robert

Best regards, Michael.

Bug#989010: linux-image-5.10.0-7-amd64: No display (post, grub, boot messages and desktop) after the upgrade to 5.10.38

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi

On Sun, May 23, 2021 at 01:04:13PM +0300, jim_p wrote:
> Package: src:linux
> Version: 5.10.38-1
> Severity: important
> X-Debbugs-Cc: pitsior...@gmail.com
> 
> Preface.
> I have disabled sleep, hibernate etc via systemd as you can see below.
> 
> $ systemctl status sleep.target suspend.target hibernate.target hybrid-
> sleep.target
> ● sleep.target
>  Loaded: masked (Reason: Unit sleep.target is masked.)
>  Active: inactive (dead)
> 
> ● suspend.target
>  Loaded: masked (Reason: Unit suspend.target is masked.)
>  Active: inactive (dead)
> 
> ● hibernate.target
>  Loaded: masked (Reason: Unit hibernate.target is masked.)
>  Active: inactive (dead)
> 
> ● hybrid-sleep.target
>  Loaded: masked (Reason: Unit hybrid-sleep.target is masked.)
>  Active: inactive (dead)
> 
> and I have set my keyboard's sleep button to shutdown the system via systemctl
> 
> 
>   
> systemctl poweroff
>   
> 
> 
> So when I press the sleep button, the system shuts down. And I have been using
> it like so for the last 5+ years.
> 
> But today, after I upgraded to 5.10.38 and rebooted, I pressed sleep and the
> system... must have gone to sleep. Pressing the powerbutton did not get me to
> post or grub or anything. It was just working with nothing on screen. I could
> ssh to it from my phone or my laptop, so I ran reboot and it hypothetically
> rebooted. I say "hypothetically", because there was no post, grub, boot
> messages or desktop again. I rebooted it with reisub, but same thing happened.
> Both network (leds on nic) and usb (light on optical mouse) showed that it was
> really powered on, on all the forementioned situations.
> 
> Since I can ssh to it, I ran dmesg and it showed nothing weird. 
> Systemd-analyze
> blade showed no delays or issues too. I installed 5.10.28 again (because I
> remove every old kernel when the new one works) and now I am able to see my
> desktop and write all this.
> 
> Right now, I am on 5.10.28 (package linux-image-5.10.0-6-amd64) and I am 
> trying
> to figure out why all this happened.

It looks from the attached information that you have a tainted kernel,
with proprietary modules loaded (nvidia at least?). Could you please
try without those loading?

Regards,
Salvatore

Bug#989011: ksudoku FTBFS on armhf in buster

[Adrian Bunk]

Source: ksudoku
Version: 4:18.04.1-1
Severity: serious
Tags: ftbfs
Control: fixed -1 4:20.04.2-2

https://tests.reproducible-builds.org/debian/rb-pkg/buster/armhf/ksudoku.html

...
In file included from /usr/include/arm-linux-gnueabihf/qt5/QtCore/qglobal.h:50,
 from 
/usr/include/arm-linux-gnueabihf/qt5/QtCore/qnamespace.h:43,
 from 
/usr/include/arm-linux-gnueabihf/qt5/QtCore/qobjectdefs.h:48,
 from /usr/include/arm-linux-gnueabihf/qt5/QtCore/qobject.h:46,
 from /usr/include/arm-linux-gnueabihf/qt5/QtCore/QObject:1,
 from /build/ksudoku-18.04.1/src/gui/ksudokugame.h:26,
 from /build/ksudoku-18.04.1/src/gui/views/ksview.h:26,
 from /build/ksudoku-18.04.1/src/gui/views/ksview.cpp:23:
/usr/include/assert.h:92: note: this is the location of the previous definition
 #  define assert(expr)   \
 
In file included from /build/ksudoku-18.04.1/src/gui/views/roxdokuview.h:34,
 from /build/ksudoku-18.04.1/src/gui/views/ksview.cpp:35:
/build/ksudoku-18.04.1/src/gui/views/ArcBall.h:44:10: fatal error: GL/glu.h: No 
such file or directory
 #include 
// Header File For The GLu32 Library
  ^~
compilation terminated.
make[4]: *** [src/gui/CMakeFiles/ksudoku_gui.dir/build.make:212: 
src/gui/CMakeFiles/ksudoku_gui.dir/views/ksview.cpp.o] Error 1

Bug#961287: ITP: bootiso -- a bash program to securely create a bootable USB device from one image file

[Jonas Smedegaard]

Quoting Jules Sam. Randolph (2021-05-23 13:10:16)
> Dear Jonas,
> 
> Thank you for your proposition,
> 
> I tried to handle the packaging myself and even had a mentor review 
> the first steps of my work. Despite my interest in learning more about 
> Debian packaging and policies, I run out of time to continue the 
> process, given my different investments in open source and 
> professional work.
> 
> So please, go ahead! I would be so glad to see this program in Debian.

Just to make sure we are not talking past each other here...

I see several ways forward here:

 a) You package bootiso, and you find a mentor to release it to Debian
 b) You join the tinker team, and we package and release it there
 c) I package and release bootiso in the tinker team

I propose b) i.e. not you doing it (mostly) yourself but also not me 
doing it myself.

Would you be willing to try that?  Or have you lost interest in the 
package maintenance task altogether and would prefer someone else (e.g. 
me) fully caring for that?


Kind regards,

 - Jonas

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

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

signature.asc
Description: signature

Bug#988523: ugrep: please backport to Buster

[Ricardo Ribalda Delgado]

Hi Adam

I tried uploading directly myself and as you predicted it didn't work.

I uploaded the package to mentors:
https://mentors.debian.net/debian/pool/main/u/ugrep/ugrep_3.2.0+dfsg-1~bpo10+1.dsc

I guess you can fetch it from there and upload it yourself. Otherwise
I can ping who sponsored me for ugrep.

Thanks!

On Mon, May 17, 2021 at 10:24 AM Ricardo Ribalda Delgado
 wrote:
>
> Hi Adam
>
> Thanks for your email.
>
> Since one of the conditions is that the version needs to be at least
> in testing I think we should wait until Sunday to have version 3.2.0
> ported instead of 3.1.7.
>
> And thanks for your offer to help, I will probably need it ;P
>
> Best regards!
>
>
> On Fri, May 14, 2021 at 8:45 PM Adam Borowski  wrote:
> >
> > Package: ugrep
> > Version: 3.2.0+dfsg-1
> > Severity: wishlist
> >
> > Hi!
> > Could you please upload a version of ugrep to buster-bpo?
> >
> > To save you from having to RTFM, here's the procedure:
> > * append ~bpo10+1 to version number (+2 on 2nd upload...)
> > * set distribution in the new changelog entry to "buster-backports"
> > * first upload of a backport needs to go through bpo-NEW, thus binaries
> >   need to be included
> > * bpo uploads these days go to the same queue as regular uploads
> > * a version to be backported needs to be already in testing
> >
> > I'm not certain if DMs can upload their own packages to bpo-NEW, I think
> > they can't.  As there's no requirement for a backporter to be an uploader,
> > I can go through all the motions for +1 if you don't wish to bother with
> > a sponsored upload the first time.
> >
> >
> > Meow!
> > -- System Information:
> > Debian Release: 11.0
> >   APT prefers testing-security
> >   APT policy: (500, 'testing-security'), (500, 'unstable'), (500, 
> > 'testing'), (1, 'experimental')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> >
> > Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads)
> > Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
> > Shell: /bin/sh linked to /usr/bin/dash
> > Init: sysvinit (via /sbin/init)
> >
> > Versions of packages ugrep depends on:
> > ii  libbz2-1.01.0.8-4
> > ii  libc6 2.31-12
> > ii  libgcc-s1 11-20210319-1
> > ii  liblz4-1  1.9.3-2
> > ii  liblzma5  5.2.5-2
> > ii  libpcre2-8-0  10.36-2
> > ii  libstdc++611-20210319-1
> > ii  libzstd1  1.4.8+dfsg-2.1
> > ii  zlib1g1:1.2.11.dfsg-2
> >
> > ugrep recommends no packages.
> >
> > ugrep suggests no packages.
> >
> > -- no debconf information
>
>
>
> --
> Ricardo Ribalda



--
Ricardo Ribalda

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

[Peter Palfrader]

On Sat, 22 May 2021, Antonio Carrillo Ledesma wrote:

> The server is out of order and due to covid we cannot lift it.

Any idea when you'll be able to get to it?

Should I just close the ticket for now and you can file a new one when
things are working?

All the best,
Peter
> 
> El sáb., 22 de mayo de 2021 15:17, Peter Palfrader 
> escribió:
> 
> > 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/
> >

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

Bug#961287: ITP: bootiso -- a bash program to securely create a bootable USB device from one image file

[Jules Sam. Randolph]

Dear Jonas,

Thank you for your proposition,

I tried to handle the packaging myself and even had a mentor review the 
first steps of my work. Despite my interest in learning more about 
Debian packaging and policies, I run out of time to continue the 
process, given my different investments in open source and professional 
work.


So please, go ahead! I would be so glad to see this program in Debian.

Thank you again,

On 23/05/2021 07:52, Jonas Smedegaard wrote:

Hi Jules,

Quoting Jules Samuel Randolph (2020-05-22 18:42:54)

Package: wnpp
Severity: wishlist
Owner: Jules Samuel Randolph 

* Package name: bootiso
   Version : 4.0.1
   Upstream Author : Jules Samuel Randolph 
* URL : https://github.com/jsamr/bootiso
* License : GPLv3
   Programming Lang: bash
   Description : A bash program to securely create a bootable USB device 
from one image file.


[...]


I would love to have a sponsor to help me get in. I am curently taking
a look at Debian Policy Manual and other material to create a source
repository. If someone would like to review it when it's ready, that
would be amazing.

I might also be interrested in maintaining other packages in the
future, although this is not my top priority.


Bootiso seems a great tool, and I would love to see it in Debian.

If you would find it interesting to have the package group-maintained,
then I would be happy to help package and maintain it as part of the
tinker team.  For info on how to get in touch with us, see
https://wiki.debian.org/Teams/Tinker

If instead you prefer to maintain the package on your own, then I
encourage you to seek sponsorship at https://mentors.debian.net/


Kind regards,

  - Jonas

Bug#961287: ITP: bootiso -- a bash program to securely create a bootable USB device from one image file

[Jonas Smedegaard]

Hi Jules,

Quoting Jules Samuel Randolph (2020-05-22 18:42:54)
> Package: wnpp
> Severity: wishlist
> Owner: Jules Samuel Randolph 
> 
> * Package name: bootiso
>   Version : 4.0.1
>   Upstream Author : Jules Samuel Randolph 
> * URL : https://github.com/jsamr/bootiso
> * License : GPLv3
>   Programming Lang: bash
>   Description : A bash program to securely create a bootable USB device 
> from one image file.

[...]

> I would love to have a sponsor to help me get in. I am curently taking 
> a look at Debian Policy Manual and other material to create a source 
> repository. If someone would like to review it when it's ready, that 
> would be amazing.
> 
> I might also be interrested in maintaining other packages in the 
> future, although this is not my top priority.

Bootiso seems a great tool, and I would love to see it in Debian.

If you would find it interesting to have the package group-maintained, 
then I would be happy to help package and maintain it as part of the 
tinker team.  For info on how to get in touch with us, see 
https://wiki.debian.org/Teams/Tinker

If instead you prefer to maintain the package on your own, then I 
encourage you to seek sponsorship at https://mentors.debian.net/


Kind regards,

 - Jonas

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

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

signature.asc
Description: signature

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

[Simon McVittie]

On Fri, 21 May 2021 at 21:54:15 +0200, Cyril Brulebois wrote:
> focussing on the last items of a GtkTreeView
> no longer works correctly

FYI I didn't receive the initial message reporting this bug, only the
follow-up, despite you having X-Debbugs-Cc'd me. I'm not sure why. Luckily
`bts show --mbox` exists.

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

I can read French somewhat better than Swedish (and infinitely better
than Sinhala where I don't even recognise the glyphs), so this is probably
the more convenient test-case :-)

> My first hunch was that the focus_path callback (one-shot call, it
> disables itself once it has triggered gtk_tree_view_scroll_to_cell on
> the first expose event) happens before the set_text_in_idle one, and
> that's indeed correct. I suppose we have a slightly taller widget at
> first, we scroll down to the bottom; then when set_text_in_idle happens,
> the widget is resized slightly smaller, the position is not correct
> anymore (it's no longer “full-bottom” but a little higher as seen in the
> scrollbar), and the selected line gets out of sight.
> 
> I've tried various things like having the focus_path happens in a
> “_later” indirection using the same kind of logic as Simon introduced
> for setting the text (with a different priority), but that would happen
> waaay before set_text_in_idle anyway.

Please could you share what you tried so I can check whether it's doing
something wrong? I feel as though this approach ought to be workable -
an idle callback with higher priority is guaranteed to happen sooner
(but note that smaller numbers are higher priority), and in my experience
idle callbacks of the same priority seem to get run in the order they
were scheduled.

The stuff here with expose events is beyond my GTK knowledge, but I
feel as though it's probably not idiomatic, and there might well be a
higher-level way to do it.

Note that the use of focus_path says

We need to focus the row *after* the widget realization, see #340007

but #340007 was a bug in the old GTK-on-DirectFB installer, and the
message opening the bug specifically said that it didn't affect
GTK-on-X11. So perhaps this delay isn't even necessary any more?

smcv

Bug#989010: linux-image-5.10.0-7-amd64: No display (post, grub, boot messages and desktop) after the upgrade to 5.10.38

[jim_p]

Package: src:linux
Version: 5.10.38-1
Severity: important
X-Debbugs-Cc: pitsior...@gmail.com

Preface.
I have disabled sleep, hibernate etc via systemd as you can see below.

$ systemctl status sleep.target suspend.target hibernate.target hybrid-
sleep.target
● sleep.target
 Loaded: masked (Reason: Unit sleep.target is masked.)
 Active: inactive (dead)

● suspend.target
 Loaded: masked (Reason: Unit suspend.target is masked.)
 Active: inactive (dead)

● hibernate.target
 Loaded: masked (Reason: Unit hibernate.target is masked.)
 Active: inactive (dead)

● hybrid-sleep.target
 Loaded: masked (Reason: Unit hybrid-sleep.target is masked.)
 Active: inactive (dead)

and I have set my keyboard's sleep button to shutdown the system via systemctl


  
systemctl poweroff
  


So when I press the sleep button, the system shuts down. And I have been using
it like so for the last 5+ years.

But today, after I upgraded to 5.10.38 and rebooted, I pressed sleep and the
system... must have gone to sleep. Pressing the powerbutton did not get me to
post or grub or anything. It was just working with nothing on screen. I could
ssh to it from my phone or my laptop, so I ran reboot and it hypothetically
rebooted. I say "hypothetically", because there was no post, grub, boot
messages or desktop again. I rebooted it with reisub, but same thing happened.
Both network (leds on nic) and usb (light on optical mouse) showed that it was
really powered on, on all the forementioned situations.

Since I can ssh to it, I ran dmesg and it showed nothing weird. Systemd-analyze
blade showed no delays or issues too. I installed 5.10.28 again (because I
remove every old kernel when the new one works) and now I am able to see my
desktop and write all this.

Right now, I am on 5.10.28 (package linux-image-5.10.0-6-amd64) and I am trying
to figure out why all this happened.


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: Gigabyte Technology Co., Ltd.
product_name: P35-DS3R
product_version: 
chassis_vendor: Gigabyte Technology Co., Ltd.
chassis_version: 
bios_vendor: Award Software International, Inc.
bios_version: F13
board_vendor: Gigabyte Technology Co., Ltd.
board_name: P35-DS3R
board_version: 

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 82G33/G31/P35/P31 Express DRAM 
Controller [8086:29c0] (rev 02)
Subsystem: Gigabyte Technology Co., Ltd 82G33/G31/P35/P31 Express DRAM 
Controller [1458:5000]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:01.0 PCI bridge [0604]: Intel Corporation 82G33/G31/P35/P31 Express PCI 
Express Root Port [8086:29c1] (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:1a.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #4 [8086:2937] (rev 02) (prog-if 00 [UHCI])
Subsystem: Gigabyte Technology Co., Ltd 82801I (ICH9 Family) USB UHCI 
Controller [1458:5004]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd

00:1a.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #5 [8086:2938] (rev 02) (prog-if 00 [UHCI])
Subsystem: Gigabyte Technology Co., Ltd 82801I (ICH9 Family) USB UHCI 
Controller [1458:5004]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd

00:1a.2 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #6 [8086:2939] (rev 02) (prog-if 00 [UHCI])
Subsystem: Gigabyte Technology Co., Ltd 82801I (ICH9 Family) USB UHCI 
Controller [1458:5004]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd

00:1a.7 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI 
Controller #2 [8086:293c] (rev 02) (prog-if 20 [EHCI])
Subsystem: Gigabyte Technology Co., Ltd 82801I (ICH9 Family) USB2 EHCI 
Controller [1458:5006]
Control: I/O- Mem+ BusMast

Bug#988993: Retitle

[Nilesh Patra]

control: retitle -1 ITP: libvbz-hdf-plugin -- VBZ compression plugin for 
nanopore signal data

On Sat, 22 May 2021 23:23:22 +0530 Nilesh Patra  wrote:
> Remark: This package is maintained by Debian Med Packaging Team at
>https://salsa.debian.org/med-team/vbz-compression

Now here: https://salsa.debian.org/med-team/libvbz-hdf-plugin

Nilesh


signature.asc
Description: PGP signature

Bug#989009: python-ddt FTBFS with python3-yaml 5.3.1-4

[Adrian Bunk]

Source: python-ddt
Version: 1.4.1-2
Severity: serious
Tags: ftbfs fixed-upstream patch
Forwarded: https://github.com/datadriventests/ddt/issues/95

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-ddt.html

...
 ERRORS 
 ERROR collecting test/test_example.py _
test/test_example.py:153: in 
class YamlOnlyTestCase(unittest.TestCase):
ddt.py:372: in ddt
return wrapper(arg) if inspect.isclass(arg) else wrapper
ddt.py:366: in wrapper
process_file_data(cls, name, func, file_attr)
ddt.py:254: in process_file_data
data = yaml.load(f, Loader=yaml_loader)
/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)
/usr/lib/python3/dist-packages/yaml/constructor.py:427: in construct_undefined
raise ConstructorError(None, None,
E   yaml.constructor.ConstructorError: could not determine a constructor for 
the tag 'tag:yaml.org,2002:python/object:test.test_example.MyClass'
E in "/build/1st/python-ddt-1.4.1/test/data/test_custom_yaml_loader.yaml", 
line 36, column 13
=== warnings summary ===
ddt.py:42
  /build/1st/python-ddt-1.4.1/ddt.py:42: PytestCollectionWarning: cannot 
collect test class 'TestNameFormat' because it has a __new__ constructor (from: 
test/test_functional.py)
@unique

-- Docs: https://docs.pytest.org/en/stable/warnings.html
=== short test summary info 
ERROR test/test_example.py - yaml.constructor.ConstructorError: could not det...
 Interrupted: 1 error during collection 
= 1 warning, 1 error in 0.46s ==
make[1]: *** [debian/rules:26: override_dh_auto_test] Error 2




pyyaml (5.3.1-4) unstable; urgency=medium
...
  * Resolve CVE-2020-14343, more trivial RCEs in .load() and FullLoader.
(Closes: #966233)

 -- Stefano Rivera   Fri, 21 May 2021 11:11:00 -0400

Bug#734377: Greetings,

[Isabella.Ferreira]

Greetings,

I wonder why you continue neglecting my emails. Please, acknowledge
the receipt of this message in reference to the subject above as I
intend to send to you the details of the mail. Sometimes, try to check
your spam box because most of these correspondences fall out sometimes
in SPAM folder.

Best regards,
Isabella

Bug#989008: CVE-2021-32614

[Moritz Muehlenhoff]

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

This was assigned CVE-2021-32614:
https://github.com/Lekensteyn/dmg2img/issues/11

Cheers,
 Moritz

Bug#989007: usermode: please drop the custom XPM pixmaps

[Pino Toscano]

Package: usermode
Version: 1.114-1
Severity: wishlist
Tags: patch

Hi,

the Debian packaging converts 3 PNG icons to XPM pixmaps; they were used
in the past by the Debian menu files, which were removed with version
1.109-1. Hence, there is no more need to convert them, dropping also the
netpbm build dependency.

Attached patch for this.

Thanks,
-- 
Pino
>From 269b6b62379239e816e8a1fc2f0cc7e0f796f6d1 Mon Sep 17 00:00:00 2001
From: Pino Toscano 
Date: Sun, 23 May 2021 10:56:45 +0200
Subject: [PATCH] stop generating custom XPM pixmaps, as were only used with
 old Debian menu files (dropped in 1.109-1); drop netpbm B-D, no more needed

---
 debian/clean| 3 ---
 debian/control  | 1 -
 debian/rules| 7 +--
 debian/usermode.install | 1 -
 4 files changed, 1 insertion(+), 11 deletions(-)
 delete mode 100644 debian/clean
 delete mode 100644 debian/usermode.install

diff --git a/debian/clean b/debian/clean
deleted file mode 100644
index 25ccdef..000
--- a/debian/clean
+++ /dev/null
@@ -1,3 +0,0 @@
-debian/disks.xpm
-debian/password.xpm
-debian/user_icon.xpm
diff --git a/debian/control b/debian/control
index ed9e78e..c9ecc0f 100644
--- a/debian/control
+++ b/debian/control
@@ -14,7 +14,6 @@ Build-Depends:
  libsm-dev,
  libuser1-dev,
  libxml-parser-perl,
- netpbm,
 Rules-Requires-Root: no
 Standards-Version: 4.4.1
 Homepage: https://pagure.io/usermode/
diff --git a/debian/rules b/debian/rules
index d25cdb0..f8591a9 100755
--- a/debian/rules
+++ b/debian/rules
@@ -25,7 +25,7 @@ override_dh_auto_configure:
MKFS=/sbin/mkfs \
FDFORMAT=/usr/bin/fdformat
 
-override_dh_install: user_icon.xpm password.xpm disks.xpm
+override_dh_install:
dh_install
# this functionality doesn't appear to be supported in Debian
rm $(DEBDIR)/usr/bin/pam-panel-icon 
$(DEBDIR)/usr/share/pixmaps/badge-small.png
@@ -40,10 +40,5 @@ override_dh_fixperms:
dh_fixperms
chmod 04755 $(DEBDIR)/usr/sbin/userhelper
 
-%.xpm : %.png
-   pngtopnm -alpha $< | pnmscale -xysize 32 32 > debian/alpha.pnm
-   pngtopnm $< | pnmscale -xysize 32 32 | ppmtoxpm 
-alphamask=debian/alpha.pnm > debian/$@
-   rm debian/alpha.pnm
-
 override_dh_missing:
dh_missing --fail-missing
diff --git a/debian/usermode.install b/debian/usermode.install
deleted file mode 100644
index e95a7b7..000
--- a/debian/usermode.install
+++ /dev/null
@@ -1 +0,0 @@
-debian/user_icon.xpm debian/password.xpm debian/disks.xpm usr/share/pixmaps
-- 
2.30.2

Bug#987536: imv: diff for NMU version 4.2.0-1.1

[Baptiste Beauplat]

Dear maintainer,

I've prepared an NMU for imv (versioned as 4.2.0-1.1). The diff
is attached to this message. I'll open an unblock request of it too.

Regards.

-- 
Baptiste Beauplat - lyknode
diff -Nru imv-4.2.0/debian/changelog imv-4.2.0/debian/changelog
--- imv-4.2.0/debian/changelog	2021-01-31 13:03:12.0 +0100
+++ imv-4.2.0/debian/changelog	2021-05-18 13:51:05.0 +0200
@@ -1,3 +1,12 @@
+imv (4.2.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build-depend on docbook-xsl so that xsltproc doesn't try to access
+the internet for the stylesheet. Works around #980930. Thanks to Logan
+Rosen  for the patch. (Closes: #987536)
+
+ -- Baptiste Beauplat   Tue, 18 May 2021 13:51:05 +0200
+
 imv (4.2.0-1) unstable; urgency=medium
 
   * New upstream version 4.2.0.
diff -Nru imv-4.2.0/debian/control imv-4.2.0/debian/control
--- imv-4.2.0/debian/control	2021-01-31 13:01:39.0 +0100
+++ imv-4.2.0/debian/control	2021-05-18 13:49:39.0 +0200
@@ -6,6 +6,7 @@
 Build-Depends:
  asciidoc-base,
  debhelper-compat (= 13),
+ docbook-xsl,
  libcmocka-dev,
  libegl1-mesa-dev,
  libfreeimage-dev,


signature.asc
Description: PGP signature

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

[Olaf van der Spek]

Op za 22 mei 2021 om 23:30 schreef 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

Thanks a lot!

> Would somebody like to review/test it?

Conflicts: galera, galera-3, ...
Breaks: galera, galera-3

> When one binary package declares a conflict with another using a Conflicts 
> field, dpkg will refuse to allow them to be unpacked on the system at the 
> same time. This is a stronger restriction than Breaks,

Based on the text I'd assume it doesn't make sense to have a package
in both conflicts and breaks. Am I reading the text wrong?

https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts

-- 
Olaf

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

[Olaf van der Spek]

Op za 22 mei 2021 om 23:54 schreef Trevor Cordes :
> 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)

It'd be nice if ^W worked by default.


-- 
Olaf

Bug#884938: XFS: possible memory allocation deadlock in kmem_alloc

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo 

Hi Jason,

On Thu, Dec 21, 2017 at 11:30:28AM -0500, Jason Gill wrote:
> Package: src:linux
> Version: 3.16.51-3
> Severity: normal
> 
> Writing a large number of files to an XFS system with a larger
> directory block size causes slow performance and kernel log errors re:
> memory allocation deadlocks.
> 
> On the surface, looks very similar to this ubuntu issue:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1382333
> 
> This has been reproducible on 2/2 systems I've tried so far.
> 
> xfs_info output for the affected filesystem:
> meta-data=/dev/sdf   isize=2048   agcount=55, agsize=268435455 
> blks
>  =   sectsz=512   attr=2, projid32bit=1
>  =   crc=0finobt=0
> data =   bsize=4096   blocks=14648409600, imaxpct=1
>  =   sunit=0  swidth=0 blks
> naming   =version 2  bsize=65536  ascii-ci=0 ftype=0
> log  =internal   bsize=4096   blocks=521728, version=2
>  =   sectsz=512   sunit=0 blks, lazy-count=1
> realtime =none   extsz=4096   blocks=0, rtextents=0
> 
> To reproduce, make an XFS filesystem with a large directory block size:
> # /sbin/mkfs.xfs -n size=64k /dev/sdXX
> 
> Then mount the new filesystem and create a large number of small files 
> quickly:
> $ seq -w 0 1000 | xargs -P8 -n 256 touch

I have not looked into the fs/xfs history to find potential relevant
changes, but can you still reproduce the issue with recent kernels? In
a testsetup, but only quickly looked, I was not able to reproduce the
behaviour.

But possibly the issue could be still unfixed.

Regards,
Salvatore

Bug#989006: unblock: vtk-dicom/0.8.12-3

[Étienne Mollier]

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

Good day,

Please unblock package vtk-dicom

[ Reason ]
The version in unstable addresses RC bugs #988643 and #988745
affecting vtk-dicom in bullseye.

[ Impact ]
If the situation is left as is, then:
  * users of python3-vtk-dicom will see a dangling link in
dist-packages/, and think this is a broken Python module;
  * users willing to check the integrity of the package through
autopkgtest will see test failures due to improper module
being called by autodep8-python3.

[ Tests ]
Tests I carried on are:
  * the usual package building and autopkgtest on amd64;
  * piuparts --fail-on-broken-symlinks to make sure #988643 is
resolved;
  * running a test script I found in the source code, in the
file Testing/TestDICOMPython.py, a wee bit less superficial
than the autodep8 import.

[ Risks ]
Almost zero risk of regression, only a dangling link is removed,
and the test suite is adjusted.

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

unblock vtk-dicom/0.8.12-3

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/3, 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 15:08:12.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 15:08:12.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-22 15:08:12.0 +0200
@@ -0,0 +1 @@
+import_name = vtkDICOMPython


signature.asc
Description: PGP signature

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

[Norbert Preining]

severity 988972 wishlist
thanks

Hi

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

Well, then you get what you ask for. Windows are there, basic
functionality is working. You **CAN** if you want install a different
window manager then kwin - but then you also have to care for getting it
started.

Packages relations including recommends should only be broken if you
know what you are doing and are able to work around the limitations it
implies.

I adjusted severity and tend to close the report.

Best

Norbert

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

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

[Étienne Mollier]

Hi Andreas,

Andreas Beckmann, on 2021-05-22:
> 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.

Unblock request filed.

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

Thanks for the notice about the d/not-installed!  For the sake
of clarity, there is another file not installed and not recorded
in d/not-installed, hence dh_missing still raising warnings.
Otherwise agreed, I'm not myself a huge fan of wildcards, but
stuck to the coding style for consistency.  Same as M-A: same,
the compat 13 will wait for bookworm I guess.

Have a nice Sunday,  :)
-- 
É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