Bug#1062739: marked as done (libydpdict: NMU diff for 64-bit time_t transition)

[Marcin Owsiany]

I just wanted to make sure this was not closed by mistake, since the
subject of your message mentions libydpdict, while the body
mentions cuneiform.

Marcin

śr., 14 lut 2024 o 22:18 Debian Bug Tracking System 
napisał(a):

> Your message dated Wed, 14 Feb 2024 13:15:04 -0800
> with message-id 
> and subject line Re: libydpdict: NMU diff for 64-bit time_t transition
> has caused the Debian Bug report #1062739,
> regarding libydpdict: NMU diff for 64-bit time_t transition
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 1062739: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062739
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Steve Langasek 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Fri, 02 Feb 2024 23:00:51 +
> Subject: libydpdict: NMU diff for 64-bit time_t transition
> Source: libydpdict
> Version: 1.0.4-3
> Severity: serious
> Tags: patch pending sid trixie
> Justification: library ABI skew on upgrade
> User: debian-...@lists.debian.org
> Usertags: time-t
>
> NOTICE: these changes must not be uploaded to unstable yet!
>
> Dear maintainer,
>
> As part of the 64-bit time_t transition required to support 32-bit
> architectures in 2038 and beyond
> (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> libydpdict as a source package shipping runtime libraries whose ABI
> either is affected by the change in size of time_t, or could not be
> analyzed via abi-compliance-checker (and therefore to be on the safe
> side we assume is affected).
>
> To ensure that inconsistent combinations of libraries with their
> reverse-dependencies are never installed together, it is necessary to
> have a library transition, which is most easily done by renaming the
> runtime library package.
>
> Since turning on 64-bit time_t is being handled centrally through a change
> to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
> important that libraries affected by this ABI change all be uploaded close
> together in time.  Therefore I have prepared a 0-day NMU for libydpdict
> which will initially be uploaded to experimental if possible, then to
> unstable after packages have cleared binary NEW.
>
> Please find the patch for this NMU attached.
>
> If you have any concerns about this patch, please reach out ASAP.  Although
> this package will be uploaded to experimental immediately, there will be a
> period of several days before we begin uploads to unstable; so if
> information
> becomes available that your package should not be included in the
> transition,
> there is time for us to amend the planned uploads.
>
>
>
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
> 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
>
>
>
> -- Forwarded message --
> From: Steve Langasek 
> To: 1062739-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Wed, 14 Feb 2024 13:15:04 -0800
> Subject: Re: libydpdict: NMU diff for 64-bit time_t transition
> Happily, we can report that an improved analysis shows cuneiform does not
> have an ABI affected by this transition.  We will not be uploading to
> unstable, and the NMU in experimental can be ignored/superseded/requested
> to
> be removed.
>
> --
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> Ubuntu Developer   https://www.debian.org/
> slanga...@ubuntu.com vor...@debian.org
>

Bug#1055032: Please update to latest upstream version

[Marcin Owsiany]

Awesome, looking forward to seeing it in the archive!
BTW, the package description might need some refresh (the promise about CSS
seems to have come to life already).

Marcin

pt., 17 lis 2023 o 12:11 Antonio Terceiro  napisał(a):

> On Fri, Nov 17, 2023 at 10:05:19AM +0100, Marcin Owsiany wrote:
> > Antonio, https://salsa.debian.org/terceiro/textual is now a 404.
> > Is your work available somwehere else?
>
> No, by mistake I ended up not making it public in the first place. It's
> public now.
>

Bug#1055032: Please update to latest upstream version

[Marcin Owsiany]

On Thu, 16 Nov 2023 09:01:56 -0300 Antonio Terceiro  wrote:
> On Sat, Nov 04, 2023 at 10:38:32AM -0300, Antonio Terceiro wrote:
> > On Fri, Nov 03, 2023 at 09:07:49PM -0300, Antonio Terceiro wrote:
> > > On Sun, Oct 29, 2023 at 09:29:04PM +0200, Jonathan Carter wrote:
> > > > Package: python3-textual
> > > > Severity: normal
> > > > X-Debbugs-Cc: 
> > > > 
> > > > Dear maintainer,
> > > > 
> > > > The current version of python3-textual in Debian is quite out of date,
> > > > and it's not possible to run newer textual apps with it anymore.,
> > > > Please upgrade to the latest upstream version (currenly (0.40.0) so
> > > > that this package can be useful again.
> > > 
> > > I have a textual locally updated to the latest upstream version:
> > > https://salsa.debian.org/terceiro/textual
> > > 
> > > I had to disable a few tests due to either missing dependencies, of
> > > mismatching expectations between the versions in Debian and the ones
> > > assumed by upstream (poetry.lock). There is still some work to do, e.g.
> > > converting the autopkgtest to use autopkgtest-pkg-pybuild.
> > 
> > This is now done.
> > 
> > BTW there is a new build dependency, python3-time-machine, which is in
> > NEW right now:
> > 
> > https://salsa.debian.org/python-team/packages/python-time-machine
> 
> FWIW this package has passed NEW and is even already in testing.

Antonio, https://salsa.debian.org/terceiro/textual is now a 404.
Is your work available somwehere else?

-- 
Marcin Owsiany   http://marcin.owsiany.pl/
GnuPG: 4096R/CDFB68E9  59F4 A7DE D37D 95C5 8939  FDDB EFDE D44B CDFB 68E9

Bug#1054139: file conflict between python3-ledger-dbgsym and ledger-dbgsym

[Marcin Owsiany]

reassign 1054139 debhelper
thanks

I guess this means there should be a way to influence the auto-generated
control file for dbgsym packages?

Marcin

śr., 18 paź 2023, 11:57 użytkownik David Bremner 
napisał:

>
> Control: tag -1 wontfix
>
> Marcin Owsiany  writes:
>
> > Package: python3-ledger-dbgsym
> > Version: 3.3.0-3
> > Severity: normal
> >
> > I got the following error when trying to install ledger-dbgsym while
> > python3-ledger-dbgsym is already installed:
> >
> > Przygotowywanie do rozpakowania pakietu
> .../ledger-dbgsym_3.3.0-3_amd64.deb ...
> > Rozpakowywanie pakietu ledger-dbgsym (3.3.0-3) ...
> > dpkg: błąd przetwarzania archiwum
> /var/cache/apt/archives/ledger-dbgsym_3.3.0-3_amd64.deb (--unpack):
> >  próba nadpisania
> "/usr/lib/debug/.build-id/bb/b9da531167728c34db6adc7a5ace6f0d21a6d2.debug",
> który istnieje także w pakiecie python3-ledger-dbgsym 3.3.0-3
> > Wystąpiły błędy podczas przetwarzania:
> >  /var/cache/apt/archives/ledger-dbgsym_3.3.0-3_amd64.deb
> >
>
> For future reference, it is better to generate such output with LANG=C
>
> > I guess the packages should conflict with each other?
> >
>
> Probably, but since they are automatically generated, I have no idea how
> to do that.
>
>

Bug#1054139: file conflict between python3-ledger-dbgsym and ledger-dbgsym

[Marcin Owsiany]

Package: python3-ledger-dbgsym
Version: 3.3.0-3
Severity: normal

I got the following error when trying to install ledger-dbgsym while
python3-ledger-dbgsym is already installed:

Przygotowywanie do rozpakowania pakietu .../ledger-dbgsym_3.3.0-3_amd64.deb ...
Rozpakowywanie pakietu ledger-dbgsym (3.3.0-3) ...
dpkg: błąd przetwarzania archiwum 
/var/cache/apt/archives/ledger-dbgsym_3.3.0-3_amd64.deb (--unpack):
 próba nadpisania 
"/usr/lib/debug/.build-id/bb/b9da531167728c34db6adc7a5ace6f0d21a6d2.debug", 
który istnieje także w pakiecie python3-ledger-dbgsym 3.3.0-3
Wystąpiły błędy podczas przetwarzania:
 /var/cache/apt/archives/ledger-dbgsym_3.3.0-3_amd64.deb

I guess the packages should conflict with each other?

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

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

Versions of packages python3-ledger-dbgsym depends on:
ii  python3-ledger  3.3.0-3

python3-ledger-dbgsym recommends no packages.

python3-ledger-dbgsym suggests no packages.

-- no debconf information

Bug#1051367: More versions

[Marcin Owsiany]

found 5.10.197-1
thanks

Yesterday I installed and tested a dozen or so kernel images from
snapshot.debian.org starting with 5.10.197-1 and ending with
6.4.4-3~bpo12+1. Unfortunately I was able to reproduce the issue on every
single one of them, although with older versions it usually takes around 10
executions of `xset dpms force off`, while on 6.x kernels it usually
freezes on the first attempt.

One thing I noticed is that most of the time, regardless of kernel version,
if I hit the keyboard within the first second of the screen going black,
then the screen lights up again and the system does not freeze.

This issue might after all be a sign of a hardware issue - sometimes
Windows that I dual-boot to seems to be similarly hung. I also used to have
weird freezes at early boot time. That problem disappeared initially - when
a device was plugged into a USB port, and later - seemingly without reason
- disappeared altogether.

However I'll keep the bug open in case some kind soul decides to share a
way to work around this.

Marcin

Bug#1051367: Acknowledgement (regression: powersave screen blank causes system freeze after upgrade to Debian 12)

[Marcin Owsiany]

Unfortunately it's not fixed. Looks like the probability of a freeze is
just lower :-(

Bug#1051367: Acknowledgement (regression: powersave screen blank causes system freeze after upgrade to Debian 12)

[Marcin Owsiany]

Turns out this issue is already fixed in the 6.4.4-3~bpo12+1 version
available in bookworm-backports \o/

Bug#1051367: Acknowledgement (regression: powersave screen blank causes system freeze after upgrade to Debian 12)

[Marcin Owsiany]

Today I switched to an Xorg-based GNOME session, and found out that
invoking `xset dpms force off` also results in the system freezing.
Interestingly, the system was responsive via ssh for another couple seconds
or so.

So I think this regression must be related to the kernel version change
more than anything else. Reassigning the bug.

Again, I'd be more than happy to do whatever is needed to investigate this
deeper. The only idea comes to mind is to try and bisect the kernel history
between 5.10.179-2 and 6.1.38-4, but I'm not sure how feasible it is these
days (it's been almost two decades since I last built my own kernel package
and don't know what config to use between these two versions).

Bug#1051367: regression: powersave screen blank causes system freeze after upgrade to Debian 12

[Marcin Owsiany]

Package: gnome
Version: 1:43+1
Severity: normal

Dear Maintainer,

After upgrading from Debian 11 to Debian 12, my system freezes hard at
the moment GNOME blanks the screen (the second setting in power saving
options in GNOME settings). Sometimes, additionally, after 10-15 more
seconds - the system hard reboots. Otherwise, I need to powercycle
manually. Either way, there is no clean shutdown.

This happens on AC power, and I confirmed this is the screen blanking,
and NOT suspend that causes this.

I also confirmed that if I switch to a text VT and leave the system
idle, the freeze does not happen.

I tried running `journalctl --follow` through an SSH connection to this
machine, but nothing appears before the connection freezes.

The system information about the computer that suffers from this problem
is below. Another laptop that I have (different hardware) running the
same software, does not exhibit this issue.

I'd be happy to try and isolate/debug this issue further, but I don't
know where to start. Hints most welcome.

regards,
Marcin

-- System Information:
Lenovo laptop: "ideapad FLEX 5-1570"
Graphics: Mesa Intel® UHD Graphics 620 (KBL GT2)
CPU: Intel® Core™ i5-8250U × 8
Using GNOME with Wayland

Debian Release: 12.1
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-11-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.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 gnome depends on:
ii  avahi-daemon 0.8-10
ii  cheese   43.0-1
ii  cups-pk-helper   0.2.6-1+b1
ii  desktop-base 12.0.6+nmu1~deb12u1
ii  evolution3.46.4-2
ii  evolution-plugins3.46.4-2
ii  file-roller  43.0-1
ii  gnome-calendar   43.1-2
ii  gnome-clocks 43.0-1
ii  gnome-color-manager  3.36.0-1+b1
ii  gnome-core   1:43+1
ii  gnome-maps   43.5-2~deb12u1
ii  gnome-music  42.1-1
ii  gnome-sound-recorder 43~beta-1
ii  gnome-tweaks 42~beta-4
ii  gnome-weather43.0-1
ii  gstreamer1.0-libav   1.22.0-2
ii  gstreamer1.0-plugins-ugly1.22.0-2+deb12u1
ii  libgsf-bin   1.14.50-1
ii  libproxy1-plugin-networkmanager  0.4.18-1.2
ii  libreoffice-calc 4:7.4.7-1
ii  libreoffice-gnome4:7.4.7-1
ii  libreoffice-impress  4:7.4.7-1
ii  libreoffice-writer   4:7.4.7-1
ii  network-manager-gnome1.30.0-2
ii  orca 43.1-1
ii  rhythmbox3.4.6-2+b1
ii  rhythmbox-plugin-cdrecorder  3.4.6-2+b1
ii  rhythmbox-plugins3.4.6-2+b1
ii  rygel-playbin0.42.1-1
ii  rygel-tracker0.42.1-1
ii  seahorse 43.0-1
ii  shotwell 0.30.17-1+b1
ii  simple-scan  42.5-2
ii  totem-plugins43.0-2
ii  xdg-user-dirs-gtk0.11-1

Versions of packages gnome recommends:
ii  gnome-games   1:43+1
ii  gnome-initial-setup   43.2-6
ii  gnome-remote-desktop  43.3-1
ii  transmission-gtk  3.00-2.1+b1

Versions of packages gnome suggests:
pn  alacarte  
pn  empathy   
pn  firefox-esr-l10n-all | firefox-l10n-all   
pn  goobox | sound-juicer 
pn  polari
ii  vinagre   3.22.0-8.1
pn  webext-ublock-origin-firefox | webext-ublock-origin-chromium  

Versions of packages gnome-core depends on:
ii  adwaita-icon-theme43-1
ii  at-spi2-core  2.46.0-5
ii  baobab43.0-1
ii  dconf-cli 0.40.0-4
ii  dconf-gsettings-backend   0.40.0-4
ii  eog   43.2-1
ii  evince43.1-2+b1
ii  evolution-data-server 3.46.4-2
ii  fonts-cantarell   0.303.1-1
ii  gdm3  43.0-3
ii  gkbd-capplet  3.28.1-1
ii  glib-networking   2.74.0-4
ii  gnome-backgrounds 43.1-1
ii  gnome-bluetooth-sendto42.5-3
ii  gnome-calculator  1:43.0.1-2
ii  gnome-characters  43.1-1
ii  gnome-contacts43.1-1
ii  gnome-control-center  1:43.6-2~deb12u1
ii  gnome-disk-utility43.0-1
ii  gnome-font-viewer 43.0-1
ii  gno

Bug#1050122: smokeping: CGI script hogs CPU and OOMs on fping graphs with pings=2000

[Marcin Owsiany]

Package: smokeping
Version: 2.7.3-4.1
Severity: normal

Dear Maintainer,

I changed the configuration to add an FPing probe flavor with pings=2000
(and step=2100) specified, and a few targets using that probe.

The motication for this is that my ISP considers the number of packets
lost within a 2000-ping sample to be a canonical metric for reliability.
So I would like to collect statistics using this metric in order to have
have data for any complaints in the future.

The backend smokeping process seems to work just fine. The data is being
collected, and the 3 and 30 hour graphs are rendered in reasonable time
(~2s).

However when I go to the 10 day (or longer) graph URL for such target,
the CGI script hogs CPU and eats all available RAM (8GB) until it is
terminated by the OOM-killer after four minutes or so, resulting in a
503 or 504 response from Apache. The longest period I was able to graph
successfully was about 4 days.

Note that the above is with about 18 hours worth of data. The RRD files
for targets with default configuration are about 2.9MB, and the ones for
2000 pings are 248MB.


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

Kernel: Linux 6.1.0-10-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.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 smokeping depends on:
ii  adduser3.134
ii  exim4-daemon-light [mail-transport-agent]  4.96-15+deb12u1
ii  fping  5.1-1
ii  init-system-helpers1.65.2
ii  libcgi-fast-perl   1:2.15-1
ii  libconfig-grammar-perl 1.13-5
ii  libdigest-hmac-perl1.04+dfsg-2
ii  libjs-cropper  1.2.2-1.1
ii  libjs-prototype1.7.3-1
ii  libjs-scriptaculous1.9.0-3
ii  librrds-perl   1.7.2-4+b8
ii  libsnmp-session-perl   1.14~git20221124T101957-1
ii  liburi-perl5.17-1
ii  libwww-perl6.68-1
ii  lsb-base   11.6
ii  perl   5.36.0-7
ii  sysvinit-utils [lsb-base]  3.06-4
ii  ucf3.0043+nmu1

Versions of packages smokeping recommends:
ii  apache2 [httpd-cgi]2.4.57-2
ii  bind9-dnsutils [dnsutils]  1:9.18.16-1~deb12u1
ii  dnsutils   1:9.18.16-1~deb12u1
pn  echoping   
ii  libsocket6-perl0.29-3

Versions of packages smokeping suggests:
ii  curl   7.88.1-10+deb12u1
pn  libauthen-radius-perl  
ii  libio-socket-ssl-perl  2.081-2
ii  libnet-dns-perl1.36-1
pn  libnet-ldap-perl   
pn  libnet-telnet-perl 
ii  openssh-client 1:9.2p1-2

-- Configuration Files:
/etc/smokeping/config.d/Probes changed [not included]
/etc/smokeping/config.d/Targets changed [not included]
/etc/smokeping/smokeping_secrets [Errno 13] Brak dostępu: 
'/etc/smokeping/smokeping_secrets'

-- no debconf information

Bug#983357: Debian 11 does not boot to Xen - thank you for your support

[Marcin Cieslak]

On Fri, 16 Sep 2022, Chuck Zmudzinski wrote:


On 9/16/22 1:53 PM, Sam Hartman wrote:

"Chuck" == Chuck Zmudzinski  writes:


Chuck> Debian processes: AFAIK there is no process for a user to
Chuck> resort to when an important bug has been ignored for over a
Chuck> year except to make some noise on mailing lists like
Chuck> debian-user and debian-project. What would you suggest as a
Chuck> better process to handle cases like #983357?

TL;DR: Maintainers do not have to work on any particular problem, but
 they do not get to block others' work.  First step is to figure out the
 fix for a problem, propose the fix, and eventually get to an NMU
 proposal.

Hi.
I agree with Branden that engaging with Chuck may not be the most
productive use of my time.
However, I think the above question is a great one, and regardless of
whether my answer is useful to Chuck, I think  it might be generally
useful.


Fast forward to April 2023:

I am a casual user (helping someone to resolve some unrelated issue with their 
Debian 11 installation)
and I can't use the default debian-11.6.0-amd64-netinst.iso installer
(sha256sum e482910626b30f9a7de9b0cc142c3d4a079fbfa96110083be1d0b473671ce08d) on 
Xen.

I just wanted to say big thanks to Chuck Zmudzinski  
for documenting this on a Xen wiki[1] - I could quickly

find this info using a search engine buy asking for "debian 11 install crash 
xen"
and it saved me hours of heads scratching and troubleshooting.

Also big thanks to Phillip Susi  for digging deep
enough to find a root cause of this problem.

I can see that using Debian cloud installer allows me to get past this 
particular
problem, but I get dropped to the initramfs prompt due to rootfs missing (Hope 
to figure
this out).

One small note, my naïve attempt to say "install nousb" as a response
to the "boot: " prompt as advised by the installer Help page  did not 
change anything.

This is just a thank-you note, feel free to respond off-list if needed.

Marcin Cieślak

[1] 
https://wiki.xenproject.org/index.php?title=Debian_Guest_Installation_Using_Debian_Installer=revision=19945=5280

Bug#790883: Possible workaround

[Marcin Owsiany]

The command from the original report fails for me with openssl 3.0.7 with
>>bad decrypt<< even with the newline.

I came up with a slightly different set of commands that reproduce this
behaviour, and which also includes -pbkdf2 that now seems to be required to
avoid a warning.

porridge@fujitsu:~$ echo peekaboo | openssl enc -aes-256-cbc -pbkdf2 -pass
pass:bar  -base64
U2FsdGVkX190F0Gf0mikyIDlIh9oDADRLtCA0wSMEHg=
porridge@fujitsu:~$ echo -n U2FsdGVkX190F0Gf0mikyIDlIh9oDADRLtCA0wSMEHg= |
openssl enc -aes-256-cbc -pbkdf2 -pass pass:bar -d -base64
error reading input file

I also learned about the -A flag which seems to make openssl work in this
case:

porridge@fujitsu:~$ echo -n U2FsdGVkX190F0Gf0mikyIDlIh9oDADRLtCA0wSMEHg= |
openssl enc -aes-256-cbc -A -pbkdf2 -pass pass:bar -d -base64
peekaboo

However even in the manpage it is mentioned to be buggy:

   The -A option when used with large files doesn't work properly.

I also found an upstream issue about base64 handling which seems to be
closely related to this bug report:
https://github.com/openssl/openssl/issues/18780
Jean-Michel, if you consider this a good enough workaround for your use
case, please consider closing this bug.

Marcin

Bug#1025485: pybuild-plugin-pyproject: pyproject plugin installs data_files in wrong place

[Marcin Owsiany]

Package: pybuild-plugin-pyproject
Version: 5.20221122
Severity: important

TL;DR: plugin_pyproject.py installs files listed under
[options.data_files] (such as manpages) in an unexpected place,
different than pip would have.

Dear Maintainer,

First, a disclaimer: I have almost zero experience and knowledge about
Python project installation tools, and setup.cfg in particular.
So please let me know if I'm talking nonsense here.

A bit of background:

Upstream of ledgerhelpers has recently switched from setup.py to
pyproject.toml + setup.cfg. The latter file contains a bunch of data
files (desktop files, documentation, and manpages) which are supposed to
be installed in FHS-compliant places under /usr/share:
https://github.com/Rudd-O/ledgerhelpers/blob/48ba347b3a81b8759850e5b454bb91c03bce/setup.cfg#L38-L58

This is indeed more or less when these files land when the application
is installed using pip or the RPM package prepared by the upstream
maintainer. However when I tried to adapt my debian package to the
current upstream version, the pyproject plugin for pybuild installs them
together with the python modules. So for example the manpages end up in
somewhat weird location like /usr/lib/python3.10/dist-packages/share/man/man1

I had a look at the code, and I think this FIXME is exactly about this
issue I'm having:

https://salsa.debian.org/python-team/tools/dh-python/-/blob/master/dhpython/build/plugin_pyproject.py#L131-132

If I correctly understand what is going on in build_step2() and
install() then I think data_files should be treated similarly to
scripts: unpacked into a separate directory and then copied into something like:
args['destdir'] + paths['data']

While the data_files concept seems to be deprecated according to
https://setuptools.pypa.io/en/latest/userguide/declarative_config.html#opt-4I
and does not have a replacement judging by
https://github.com/pypa/packaging-problems/issues/72
I think it would still make sense to try and imitate what pip is doing at
the moment.

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

Kernel: Linux 5.19.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.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 pybuild-plugin-pyproject depends on:
ii  dh-python  5.20221122
ii  python3-build  0.7.0-4
ii  python3-installer  0.5.1+dfsg1-2
ii  python3-tomli  2.0.1-1

pybuild-plugin-pyproject recommends no packages.

pybuild-plugin-pyproject suggests no packages.

-- no debconf information

Bug#1024389: python3-ledger: sefault during garbage collection

[Marcin Owsiany]

4, 
-8777406471407748592, -8777389044246857200}, mask_was_saved = 0}}, priv = {pad 
= {0x0, 0x0, 0x2, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 2}}}
not_first_call = 
#48 0x77c292bc in __libc_start_main_impl (main=0x557950e0 , 
argc=2, argv=0x7fffe0a8, init=, fini=, 
rtld_fini=, stack_end=0x7fffe098) at ../csu/libc-start.c:389
No locals.
#49 0x55795011 in _start ()
No symbol table info available.
(gdb) 


-- 
Marcin Owsiany   http://marcin.owsiany.pl/
GnuPG: 4096R/CDFB68E9  59F4 A7DE D37D 95C5 8939  FDDB EFDE D44B CDFB 68E9

Bug#1024389: python3-ledger: sefault during garbage collection

[Marcin Owsiany]

Package: python3-ledger
Version: 3.2.1-8+b5
Severity: normal

Dear Maintainer,

Here is a short repro script, that generates a segmentation violation on
completion. I include a backtrace from GDB, but unfortunately I could not find
debugging symbols for the ledger extension nor libboost-python.

porridge@fujitsu:~/Pulpit/debian/devel/ledgerhelpers/ledgerhelpers$ cat dtor.py 
import ledger
session = ledger.Session()
j = session.read_journal_from_string("""
2017-11-23 example
acct1  1 USD
acct2
""")

for post in j.query(""):
pass
print("Done.")
porridge@fujitsu:~/Pulpit/debian/devel/ledgerhelpers/ledgerhelpers$ gdb python3
GNU gdb (Debian 12.1-3) 12.1
[...]
Reading symbols from python3...
Reading symbols from 
/usr/lib/debug/.build-id/a4/6363cf9ae192e452957ceab1943bb70c310035.debug...
(gdb) r dtor.py 
Starting program: /usr/bin/python3 dtor.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Done.

Program received signal SIGSEGV, Segmentation fault.
0x7735efd8 in ledger::journal_t::clear_xdata() () from 
/usr/lib/python3/dist-packages/ledger.cpython-310-x86_64-linux-gnu.so
(gdb) bt full
#0  0x7735efd8 in ledger::journal_t::clear_xdata() () from 
/usr/lib/python3/dist-packages/ledger.cpython-310-x86_64-linux-gnu.so
No symbol table info available.
#1  0x77456af2 in ?? () from 
/usr/lib/python3/dist-packages/ledger.cpython-310-x86_64-linux-gnu.so
No symbol table info available.
#2  0x7745350d in ?? () from 
/usr/lib/python3/dist-packages/ledger.cpython-310-x86_64-linux-gnu.so
No symbol table info available.
#3  0x775e1a4f in ?? () from 
/lib/x86_64-linux-gnu/libboost_python310.so.1.74.0
No symbol table info available.
#4  0x556edc76 in subtype_dealloc (self=) at 
../Objects/typeobject.c:1460
_tstate = 
type_needs_decref = 1
type = 
base = 0x77602680
basedealloc = 0x775e1a30
has_finalizer = 
#5  0x7745880d in 
boost::python::objects::value_holder, 
__gnu_cxx::__normal_iterator > > > >::~value_holder() ()
   from /usr/lib/python3/dist-packages/ledger.cpython-310-x86_64-linux-gnu.so
No symbol table info available.
#6  0x775e1a4f in ?? () from 
/lib/x86_64-linux-gnu/libboost_python310.so.1.74.0
No symbol table info available.
#7  0x556edc76 in subtype_dealloc (self=) at 
../Objects/typeobject.c:1460
_tstate = 
type_needs_decref = 1
type = 
base = 0x77602680
basedealloc = 0x775e1a30
has_finalizer = 
#8  0x775e94a5 in ?? () from 
/lib/x86_64-linux-gnu/libboost_python310.so.1.74.0
No symbol table info available.
#9  0x556d001b in _PyObject_MakeTpCall (tstate=0x55b4eab0, 
callable=, args=, nargs=1, keywords=0x0)
at ../Objects/call.c:215
call = 
argstuple = (,)
kwdict = 0x0
result = 0x0
#10 0x556f1d83 in _PyObject_VectorcallTstate 
(nargsf=9223372036854775809, kwnames=0x0, args=0x7fffdba8, 
callable=, 
tstate=0x55b4eab0) at ../Include/cpython/abstract.h:112
nargs = 1
func = 
res = 
func = 
res = 
nargs = 
#11 PyObject_CallOneArg (arg=, func=) at ../Include/cpython/abstract.h:184
_args = {, 
}
args = 0x7fffdba8
tstate = 0x55b4eab0
nargsf = 9223372036854775809
_args = 
args = 
tstate = 
nargsf = 
#12 handle_callback (ref=, callback=) at ../Objects/weakrefobject.c:952
cbresult = 
#13 0x556ee5e1 in PyObject_ClearWeakRefs (object=) at 
../Objects/weakrefobject.c:998
callback = 
current = 
count = 1
err_type = 0x0
err_value = 0x0
err_tb = 0x0
list = 
#14 0x775e1a76 in ?? () from 
/lib/x86_64-linux-gnu/libboost_python310.so.1.74.0
No symbol table info available.
#15 0x556edc76 in subtype_dealloc (self=) at 
../Objects/typeobject.c:1460
_tstate = 
type_needs_decref = 1
type = 
base = 0x77602680
basedealloc = 0x775e1a30
has_finalizer = 
#16 0x556b99c9 in _Py_Dealloc (op=) at 
../Objects/object.c:2300
dealloc = 
dealloc = 
#17 _Py_DECREF (op=) at ../Include/object.h:500
No locals.
#18 _Py_XDECREF (op=) at ../Include/object.h:567
No locals.
#19 free_keys_object (keys=0x55c13a60) at ../Objects/dictobject.c:628
entries = 
i = 12
n = 13
state = 
#20 0x556b97b4 in dictkeys_decref (dk=) at 
../Objects/dictobject.c:337
No locals.
#21 dict_dealloc (mp=0x7773dec0) at ../Objects/dictobject.c:2076
_tstate = 0x55b4eab0
state = 
values = 0x0
keys = 0x55c13a60
i = 
n = 
#22 0x557c9890 in _Py_DECREF (op=) at 
../Include/object.h:500
No locals.
#23 _Py_XDECREF (op=) at ../Include/object.h:567
No locals.
#24 

Bug#1022074: ITP: ledgerhelpers -- collection of helper programs and a helper library for Ledger (ledger-cli)

[Marcin Owsiany]

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

* Package name: ledgerhelpers
  Version : 0.3.4
  Upstream Author : Manuel Amador (Rudd-O) 
* URL : https://github.com/Rudd-O/ledgerhelpers
* License : GPLv2+
  Programming Lang: Python
  Description : collection of helper programs and a helper library for 
Ledger (ledger-cli)

This is a collection of small single-purpose programs to aid your
accounting with Ledger (ledger-cli). Think of it as the batteries that
were never included with Ledger. What can you do with these programs:
 - Enter transactions easily with addtrans.
 - Update your price quotes with updateprices.
 - Record multi-currency ATM withdrawals with withdraw-cli.
 - Record FIFO stock or commodity sales with sellstock-cli.
 - Interactively clear transactions with cleartrans-cli.
 - Keep your ledger chronologically sorted with sorttrans-cli.


I plan to maintain this package inside the Debian Python Team.

Bug#1019374: Acknowledgement (deb-scrub-obsolete crashes with AttributeError)

[Marcin Owsiany]

I realized now this might be fixed already in
https://salsa.debian.org/jelmer/lintian-brush/-/commit/0812a32417e8f78278dc1f574c0e528919edc0db
but not rolled out yet?

Bug#1019374: deb-scrub-obsolete crashes with AttributeError

[Marcin Owsiany]

Package: lintian-brush

Please see
https://janitor.debian.net/cupboard/pkg/apt-forktracer/b292a431-c8b4-421b-9c7f-b3555ead4046/

Removing run time and build time constraints unnecessary since
busterTraceback (most recent call last):  File
"/code/lintian-brush/scripts/deb-scrub-obsolete", line 4, in 
  main()  File "/code/lintian-brush/lintian_brush/scrub_obsolete.py",
line 712, in mainresult = scrub_obsolete(  File
"/code/lintian-brush/lintian_brush/scrub_obsolete.py", line 529, in
scrub_obsolete+ release_aliases(release))  File
"/code/lintian-brush/lintian_brush/scrub_obsolete.py", line 471, in
release_aliasesdebian_distro_info.unstable:
'unstable',AttributeError: 'DebianDistroInfo' object has no attribute
'unstable'. Did you mean: 'stable'?

Bug#942399: rxvt-unicode: server lockup making all clients unresponsive

[Marcin Szewczyk]

On Tue, 15 Oct 2019 13:49:07 -0400 rharw...@club.cc.cmu.edu wrote:
> Occasionally, I will see urxvtc process become unresponsive to keyboard
> input.  It seems like processes may still be able to update their panes - my
> mosh session keeps updating the screen, for instance.

Hi,

after upgrading to bullseye I started experiencing a similar thing. This
might be a problem of urxvt interacting with ibus. Apparently this has a
long history.

See:
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753611
- http://lists.schmorp.de/pipermail/rxvt-unicode/2010q2/001177.html
- 
https://askubuntu.com/questions/746119/upgrade-ibus-or-export-ibus-enable-sync-mode-1-to-fix-intellij-android-studio
  because of the IBUS_ENABLE_SYNC_MODE remark

I do not use the daemon mode and it seems I did not have ibus daemon
installed before bullseye.

In my case input hangs from time to time after closing a tab using ^D.
>From technical point of view XFilterEvent() in rxvttoolkit.C starts
returning true for all key presses so urxvt stops processing them.

Running `ibus restart` unfreezes my terminals.

-- 
Marcin Szewczyk
http://wodny.org

Bug#973578: qemu-system-arm: -machine sbsa-ref does not boot UEFI

[Marcin Juszkiewicz]

W dniu 02.11.2020 o 05:00, Ryutaroh Matsumoto pisze:

Package: qemu-system-arm
Version: 1:5.1+dfsg-4+b1
Severity: minor

Dear Maintainer,

# cp /usr/share/AAVMF/AAVMF_VARS.fd /var/tmp/efivars.fd; qemu-system-aarch64 \
  -machine sbsa-ref -cpu cortex-a57  -nographic -net nic,model=virtio \
  -net user -object rng-random,filename=/dev/urandom,id=rng0 \
  -device virtio-rng-pci,rng=rng0,id=rng-device0 \
  -drive file=/var/lib/debci/qemu/sid-arm64.img,if=virtio,index=0,format=qcow2 \
  -drive if=pflash,format=raw,read-only,file=/usr/share/AAVMF/AAVMF_CODE.fd \
  -drive if=pflash,format=raw,file=/var/tmp/efivars.fd -m 1024

gives the error
qemu-system-aarch64: device requires 268435456 bytes, block backend provides 
67108864 bytes

On the other hand, if I change -machine sbsa-ref to -machine virt,
it works fine as


SBSA Reference Platform requires both UEFI firmware and UEFI variables 
file to be 256MB in size.


Virt machine uses 64MB files.

So it is not a bug in qemu.

Bug#1008729: bambam - needs a source only upload.

[Marcin Owsiany]

:facepalm: can you please point me at a place where the current
requirements are spelled out? Do that I have a reference once and for all?

Marcin

Bug#1008611: bambam autopkgtest failure with pygame 2.1

[Marcin Owsiany]

Thanks for the report. Since showing text is proven to still work (as seen
in the screenshots) I suspect the app is no longer receiving the
(simulated) keypresses, because otherwise it should show at least the
colorful "m" letters (even if rendering pictures would stop working for
some reason).

To fix this, I need to figure out a way to interactively run the app
against the new version of the library without messing up my (Debian
stable) system... I'll try running it under xvfb in a container, but other
ideas most welcome :-)

Marcin

Bug#1005438: pygame: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.10 3.9" --system=custom --test-args "/usr/bin/xvfb-run {interpreter} -m pygame.tests.__main__ --exclude opengl"

[Marcin Owsiany]

000531efb in _PyObject_MakeTpCall ()
#47 0x0052b9ee in _PyEval_EvalFrameDefault ()
#48 0x0053b7ff in _PyFunction_Vectorcall ()
#49 0x0054893a in  ()
#50 0x00528a93 in _PyEval_EvalFrameDefault ()
#51 0x0053105a in _PyObject_FastCallDictTstate ()
#52 0x005459b9 in _PyObject_Call_Prepend ()
#53 0x005c2c33 in  ()
#54 0x00531efb in _PyObject_MakeTpCall ()
#55 0x0052b9ee in _PyEval_EvalFrameDefault ()
#56 0x0053b7ff in _PyFunction_Vectorcall ()
#57 0x00526ca7 in _PyEval_EvalFrameDefault ()
#58 0x0053b7ff in _PyFunction_Vectorcall ()
#59 0x005490e2 in PyObject_Call ()
#60 0x00528a93 in _PyEval_EvalFrameDefault ()
#61 0x0053b7ff in _PyFunction_Vectorcall ()
#62 0x005490e2 in PyObject_Call ()
#63 0x00528a93 in _PyEval_EvalFrameDefault ()
#64 0x0053b7ff in _PyFunction_Vectorcall ()
#65 0x005490e2 in PyObject_Call ()
#66 0x00528a93 in _PyEval_EvalFrameDefault ()
#67 0x005ffd82 in  ()
#68 0x005ffcbb in PyEval_EvalCode ()
#69 0x0060493d in  ()
#70 0x0053ba2e in  ()
#71 0x00526aba in _PyEval_EvalFrameDefault ()
#72 0x0053b7ff in _PyFunction_Vectorcall ()
#73 0x00526aba in _PyEval_EvalFrameDefault ()
#74 0x0053b7ff in _PyFunction_Vectorcall ()
#75 0x00619450 in  ()
#76 0x006182cd in Py_RunMain ()
#77 0x005f4e89 in Py_BytesMain ()
#78 0x7fde9cb8b7fd in __libc_start_main (main=0x5f4e50, argc=5, 
argv=0x7ffce3eb4ee8, init=, fini=, 
rtld_fini=, stack_end=0x7ffce3eb4ed8) at ../csu/libc-start.c:332
self = 
result = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {7033120, 
4441673013700892507, 6245728, 0, 0, 0, -4442174567630989477, 
-4458907349788616869}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x5, 
0x7ffce3eb4ee8}, data = {prev = 0x0, cleanup = 0x0, canceltype = 5}}}
not_first_call = 
#79 0x005f4d8a in _start ()
(gdb)   


regards,
Marcin

Bug#1005943: --filesync is incompatible with --symlinks (symliks are always updated)

[Marcin Owsiany]

Package: zip
Version: 3.0-12
Severity: normal
Tags: patch upstream

How to reproduce:

Prep phase:

porridge@butla:~/tmp$ mkdir dir
porridge@butla:~/tmp$ echo foo > dir/file
porridge@butla:~/tmp$ ln -s file dir/link
porridge@butla:~/tmp$ find dir -ls
 50725398  4 drwxrwxr-x   2 porridge porridge 4096 lut 17 18:01 dir
 50725399  4 -rw-rw-r--   1 porridge porridge4 lut 17 18:01 dir/file
 50725400  0 lrwxrwxrwx   1 porridge porridge4 lut 17 18:01 
dir/link -> file
porridge@butla:~/tmp$ zip --verbose --symlink --recurse-paths --filesync 
dir.zip dir
  adding: dir/  (in=0) (out=0) (stored 0%)
  adding: dir/file  (in=4) (out=4) (stored 0%)
  adding: dir/link  (in=4) (out=4) (stored 0%)
total bytes=8, compressed=8 -> 0% savings
porridge@butla:~/tmp$

So far so good, now the unexpected part:

porridge@butla:~/tmp$ zip --verbose --symlink --recurse-paths --filesync 
dir.zip dir
  ok: dir/
  ok: dir/file
updating: dir/link  (in=4) (out=4) (stored 0%)
total bytes=8, compressed=8 -> 0% savings
porridge@butla:~/tmp$ zip --verbose --symlink --recurse-paths --filesync 
dir.zip dir
  ok: dir/
  ok: dir/file
updating: dir/link  (in=4) (out=4) (stored 0%)
total bytes=8, compressed=8 -> 0% savings
porridge@butla:~/tmp$

As you can see, the symlink is always considered to be in need of update.
While the expected behaviour would be:

porridge@butla:~/tmp$ zip --verbose --symlink --recurse-paths --filesync 
dir.zip dir
Archive is current
porridge@butla:~/tmp$


I managed to produce the following patch which seems to fix the issue. It
basically changes the UNIX-specific implementation of the filetime() function
to retrieve the size not just for regular files, but also for symlinks. This
way the `current` flag is set to 1 in zip.c:6018 like for regular files.

The above (expected) behaviour is for a zip package built with this patch.

--- zip-3.0.orig/unix/unix.c
+++ zip-3.0/unix/unix.c
@@ -423,7 +423,7 @@ ulg filetime(f, a, n, t)
 }
   }
   if (n != NULL)
-*n = (s.st_mode & S_IFMT) == S_IFREG ? s.st_size : -1L;
+*n = ((s.st_mode & S_IFMT) == S_IFREG || (s.st_mode & S_IFMT) == S_IFLNK) 
? s.st_size : -1L;
   if (t != NULL) {
 t->atime = s.st_atime;
 t->mtime = s.st_mtime;


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

Kernel: Linux 5.10.0-11-amd64 (SMP w/4 CPU threads)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.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 zip depends on:
ii  libbz2-1.0  1.0.8-4
ii  libc6   2.31-13+deb11u2

Versions of packages zip recommends:
ii  unzip  6.0-26

zip suggests no packages.

-- no debconf information

Bug#998341: qemu-system-common: qemu in bullseye-backports is incompatible with bullseye libvirt

[Marcin Juszkiewicz]

W dniu 02.11.2021 o 22:26, Michael Tokarev pisze:


What do you want us to do here?
I know full well that libvirt in buster is too old for new qemu.

I don't have enough experience to backport libvirt (I never ever
used it myself). Even if I had such experience, what I should do
with this bugreport?


You are right. I am forgetting that there are people using qemu directly.


Should I maybe remove the qemu backport and hence close this bugreport?
More recent qemu is definitely useful on buster - for me and for some
other people as well, so I don't quite want to remove it from bpo.

So I don't see a way to deal with this bugreport.


Close it please. Sorry for that.

Bug#998337: Acknowledgement (KeyError: 'setuptools' when using pyproject-build (build))

[Marcin Szewczyk]

I couldn't run reportbug on the target machine, forgot to take a look on
bugs of the source package and missed the 994953[1]. Sorry for a
duplicate.


[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994953

-- 
Marcin Szewczyk
http://wodny.org

Bug#998341: qemu-system-common: qemu in bullseye-backports is incompatible with bullseye libvirt

[Marcin Juszkiewicz]

Package: qemu-system-common
Version: 1:5.2+dfsg-11
Severity: normal
X-Debbugs-Cc: marcin.juszkiew...@linaro.org

I am maintaining Debian support in OpenStack Kolla project. We are
building container images with OpenStack components and provide way to
deploy whole OpenStack from them.

As we have new release cycle now I looked into possible package
upgrades. Newer QEMU in bullseye-backports got my intention.

Then I tried to install it:

root@puchatek /]# apt-get install --no-install-recommends libvirt-clients 
libvirt-daemon-system qemu-block-extra qemu-system -t bullseye-backports 
libvirt-daemon
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 qemu-system-common : Breaks: libvirt-daemon (< 7.2.0-1) but 7.0.0-3 is to be 
installed
E: Unable to correct problems, you have held broken packages.


So it looks like I have to stay with previous version (libvirt maintainer was
never fan of backporting libvirt).

-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.14.0-0.bpo.2-arm64 (SMP w/16 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages qemu-system-common depends on:
ii  libaio10.3.112-9
ii  libc6  2.31-13+deb11u2
ii  libcap-ng0 0.7.9-2.2+b1
ii  libgbm120.3.5-1
ii  libglib2.0-0   2.66.8-1
ii  libgnutls303.7.1-5
ii  libnettle8 3.7.3-1
ii  libpixman-1-0  0.40.0-1
ii  libseccomp22.5.1-1
pn  liburing1  
pn  libvirglrenderer1  
ii  zlib1g 1:1.2.11.dfsg-2

qemu-system-common recommends no packages.

qemu-system-common suggests no packages.

-- no debconf information

Bug#998337: KeyError: 'setuptools' when using pyproject-build (build)

[Marcin Szewczyk]

Package: python3-virtualenv
Version: 20.4.0+ds-2

An attempt to invoke pyproject-build (build v0.7.0) ends up with:
#v+
* Creating virtualenv isolated environment...

Traceback (most recent call last):
  File "/home/mszewczyk/.local/lib/python3.9/site-packages/build/__main__.py", 
line 372, in main
built = build_call(
  File "/home/mszewczyk/.local/lib/python3.9/site-packages/build/__main__.py", 
line 229, in build_package_via_sdist
sdist = _build(isolation, builder, outdir, 'sdist', config_settings, 
skip_dependency_check)
  File "/home/mszewczyk/.local/lib/python3.9/site-packages/build/__main__.py", 
line 140, in _build
return _build_in_isolated_env(builder, outdir, distribution, 
config_settings)
  File "/home/mszewczyk/.local/lib/python3.9/site-packages/build/__main__.py", 
line 104, in _build_in_isolated_env
with _IsolatedEnvBuilder() as env:
  File "/home/mszewczyk/.local/lib/python3.9/site-packages/build/env.py", line 
101, in __enter__
executable, scripts_dir = _create_isolated_env_virtualenv(self._path)
  File "/home/mszewczyk/.local/lib/python3.9/site-packages/build/env.py", line 
226, in _create_isolated_env_virtualenv
result = virtualenv.cli_run(cmd, setup_logging=False)
  File "/usr/lib/python3/dist-packages/virtualenv/run/__init__.py", line 32, in 
cli_run
of_session.run()
  File "/usr/lib/python3/dist-packages/virtualenv/run/session.py", line 47, in 
run
self._seed()
  File "/usr/lib/python3/dist-packages/virtualenv/run/session.py", line 60, in 
_seed
self.seeder.run(self.creator)
  File 
"/usr/lib/python3/dist-packages/virtualenv/seed/embed/via_app_data/via_app_data.py",
 line 43, in run
with self._get_seed_wheels(creator) as name_to_whl:
  File "/usr/lib/python3.9/contextlib.py", line 117, in __enter__
return next(self.gen)
  File 
"/usr/lib/python3/dist-packages/virtualenv/seed/embed/via_app_data/via_app_data.py",
 line 131, in _get_seed_wheels
if name_to_whl['setuptools'].path.is_relative_to(BUNDLE_FOLDER):
KeyError: 'setuptools'

ERROR 'setuptools'
#v-

It looks like `include-pkg_resources.patch` is the culprit and two
things conflict with each other:

- virtualenv (Debian version)


/usr/lib/python3/dist-packages/virtualenv/seed/embed/via_app_data/via_app_data.py:130,
`if name_to_whl['setuptools'].path.is_relative_to(BUNDLE_FOLDER):`

- build (v0.7.0 from pypi)

…/python3.9/site-packages/build/env.py:224
`--no-setuptools`, probably since:

https://github.com/pypa/build/blame/6cdcdc1f3d7124ed8f8a11d5974a6c0b1c07cc7b/src/build/env.py#L163

Adding `"setuptools" in name_to_whl` or removing `--no-setuptools`
respectively solves the problem (not sure if properly).

-- 
Marcin Szewczyk
http://wodny.org

Bug#894384: More info

[Marcin Owsiany]

I have the same problem.
I noticed today that the option does appear while the backup is running. As
soon as it's done, the option disappears again.

Marcin

Bug#989446: unblock: apt-transport-s3/2.0.0-2

[Marcin Kulisz]

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

Please unblock package apt-transport-s3

We need this package to be included in the Bullseye release, changeset is
minimal and only contains fix for the RC bug (#986647).
Impact of this change should be minimal as the change is really simple type
casting.
Set of manual tests including fetching and installing packages via apt with this
transport has been run successfully.

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

unblock apt-transport-s3/2.0.0-2

*** /tmp/apt-transport-s3.debdiff
diff -Nru apt-transport-s3-2.0.0/debian/changelog 
apt-transport-s3-2.0.0/debian/changelog
--- apt-transport-s3-2.0.0/debian/changelog 2019-08-27 14:22:40.0 
+0100
+++ apt-transport-s3-2.0.0/debian/changelog 2021-06-03 20:20:49.0 
+0100
@@ -1,3 +1,9 @@
+apt-transport-s3 (2.0.0-2) unstable; urgency=medium
+
+  * Applying patch fixing string opperations (Closes: #986647)
+
+ -- Marcin Kulisz   Thu, 03 Jun 2021 20:20:49 +0100
+
 apt-transport-s3 (2.0.0-1) unstable; urgency=medium
 
   [ Hayden Myers ]
diff -Nru 
apt-transport-s3-2.0.0/debian/patches/0001-Added-explicit-string-casing-Closes-986647.patch
 
apt-transport-s3-2.0.0/debian/patches/0001-Added-explicit-string-casing-Closes-986647.patch
--- 
apt-transport-s3-2.0.0/debian/patches/0001-Added-explicit-string-casing-Closes-986647.patch
 1970-01-01 01:00:00.0 +0100
+++ 
apt-transport-s3-2.0.0/debian/patches/0001-Added-explicit-string-casing-Closes-986647.patch
 2021-06-03 20:20:49.0 +0100
@@ -0,0 +1,24 @@
+From: Marcin Kulisz 
+Date: Thu, 3 Jun 2021 20:10:24 +0100
+Subject: Added explicit string casing (Closes: #986647)
+
+---
+ s3 | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/s3 b/s3
+index 01b1d9d..83a6dfa 100755
+--- a/s3
 b/s3
+@@ -187,8 +187,9 @@ class AWSCredentials(object):
+ 
+ if data.get("AccessKeyId") is None:
+ self.__get_role()
+-data = 
self.__request_json(urllib.parse.urljoin(self.credentials_metadata,
+-self.iamrole))
++data = self.__request_json(urllib.parse.urljoin(
++str(self.credentials_metadata, 'utf-8'),
++str(self.iamrole, 'utf-8')))
+ 
+ self.access_key = data['AccessKeyId']
+ if self.access_key is None or self.access_key == '':
diff -Nru apt-transport-s3-2.0.0/debian/patches/series 
apt-transport-s3-2.0.0/debian/patches/series
--- apt-transport-s3-2.0.0/debian/patches/series1970-01-01 
01:00:00.0 +0100
+++ apt-transport-s3-2.0.0/debian/patches/series2021-06-03 
20:20:49.0 +0100
@@ -0,0 +1 @@
+0001-Added-explicit-string-casing-Closes-986647.patch

Bug#988969: kdenlive crashes on start with "Cyclic dependency detected between" message

[Marcin Kucharczyk]

Package: kdenlive
Version: 20.12.3-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: mar...@kucharczyk.im

Hi,

When I try to start Kdenlive it welcome screen appears for a few seconds
and then crashes:

$ kdenlive
Invalid metadata for "telecide"
Failed to parse "telecide"
Invalid metadata for "jack"
Failed to parse "jack"
Invalid metadata for "deinterlace"
Failed to parse "deinterlace"
Invalid metadata for "avcolour_space"
Failed to parse "avcolour_space"
Invalid metadata for "avcolor_space"
Failed to parse "avcolor_space"
Invalid metadata for "avdeinterlace"
Failed to parse "avdeinterlace"
Invalid metadata for "swscale"
Failed to parse "swscale"
Invalid metadata for "swresample"
Failed to parse "swresample"
Invalid title/identifier for "crop_detect"
Failed to parse "crop_detect"
Invalid metadata for "audiochannels"
Failed to parse "audiochannels"
Invalid metadata for "audioconvert"
Failed to parse "audioconvert"
Invalid metadata for "data_feed"
Failed to parse "data_feed"
Invalid metadata for "imageconvert"
Failed to parse "imageconvert"
Invalid metadata for "glsl.manager"
Failed to parse "glsl.manager"
Invalid metadata for "movit.convert"
Failed to parse "movit.convert"
Invalid metadata for "movit.crop"
Failed to parse "movit.crop"
Invalid metadata for "movit.resample"
Failed to parse "movit.resample"
Invalid metadata for "movit.resize"
Failed to parse "movit.resize"
Unknown asset "avfilter.acompressor"
Unknown asset "avfilter.aecho"
Unknown asset "avfilter.agate"
Unknown asset "avfilter.atadenoise"
Unknown asset "avfilter.bwdif"
Unknown asset "avfilter.deblock"
Unknown asset "avfilter.dedot"
Unknown asset "avfilter.deflate"
Unknown asset "avfilter.derain"
Unknown asset "avfilter.doubleweave"
Unknown asset "avfilter.field"
Unknown asset "avfilter.framestep"
Unknown asset "avfilter.fspp"
Unknown asset "avfilter.graphmonitor"
Unknown asset "avfilter.hqdn3d"
Unknown asset "avfilter.inflate"
Unknown asset "avfilter.lagfun"
Unknown asset "avfilter.random"
Unknown asset "avfilter.removegrain"
Unknown asset "avfilter.separatefields"
Unknown asset "avfilter.shuffleplanes"
Unknown asset "avfilter.sr"
Unknown asset "avfilter.tmix"
Unknown asset "avfilter.w3fdif"
Unknown asset "avfilter.weave"
Unknown asset "avfilter.yadif"
Unknown asset "frei0r.baltan"
Unknown asset "frei0r.bgsubtract0r"
Unknown asset "frei0r.bigsh0t_eq_mask"
Unknown asset "frei0r.bigsh0t_eq_to_rect"
Unknown asset "frei0r.bigsh0t_hemi_to_eq"
Unknown asset "frei0r.bigsh0t_rect_to_eq"
Unknown asset "frei0r.bigsh0t_stabilize_360"
Unknown asset "frei0r.bigsh0t_transform_360"
Unknown asset "frei0r.delay0r"
Unknown asset "frei0r.delaygrab"
Unknown asset "frei0r.facebl0r"
Unknown asset "frei0r.facedetect"
Unknown asset "frei0r.lightgraffiti"
Unknown asset "frei0r.lightgraffiti"
Unknown asset "frei0r.tehRoxx0r"
Unknown asset "movit.unsharp_mask"
Unknown asset "region"
Unknown asset "timewarp"
Unknown asset "opencv.tracker"
Unknown asset "opencv.tracker"
Unknown asset "typewriter"
Cyclic dependency detected between 
"file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/styles/org.kde.desktop.plasma/Units.qml"
 and 
"file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/styles/org.kde.desktop.plasma/Units.qml"
Cyclic dependency detected between 
"file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/styles/org.kde.desktop.plasma/Units.qml"
 and 
"file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/styles/org.kde.desktop.plasma/Units.qml"
QQmlEngine::setContextForObject(): Object already has a QQmlContext
Cyclic dependency detected between 
"file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/styles/org.kde.desktop.plasma/Units.qml"
 and 
"file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/styles/org.kde.desktop.plasma/Units.qml"
QQmlEngine::setContextForObject(): Object already has a QQmlContext
QWaylandGLContext::makeCurrent: eglError: 3009, this: 0x555c4734dcc0

QWaylandGLContext::makeCurrent: eglError: 3009, this: 0x555c4744d920

QWaylandGLContext::makeCurrent: eglError: 3009, this: 0x7f1b3800a2a0

QOpenGLFunctions created with non-current context
Unable to start Dr. Konqi




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

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

Versions of packages kdenlive depends on:
ii  ffmpeg 7:4.3.2-0+deb11u1
ii  gstreamer1.0-plugins-bad   1.18.4-3
ii  kded5  5.78.0-2
ii  kdenlive-data  20.12.3-1
ii  kinit  5.78.0-2
ii  kio5.78.0-4
ii  libc6  

Bug#987353: CVE-2020-8903 CVE-2020-8907 CVE-2020-8933

[Marcin Kulisz]

On 2021-05-10 12:16:09, Noah Meyerhans wrote:
> On Mon, May 10, 2021 at 09:00:34PM +0200, Moritz Mühlenhoff wrote:
> > > Hi, since this package was brought into Debian in ~2018, there have been
> > > several transformations in the GCE guest software stack and thus the
> > > current landscape is very different. Google doesn't actually maintain the
> > > official Debian package and we're not sure who is, if anyone. The Google
> > > provided packages are shipped separately and will override the Debian
> > > package if you use them from our repositories. Please see either our 
> > > Google
> > > Cloud docs 
> > > 
> > > or github readme
> > >  for info 
> > > on
> > > the packages we are maintaining and shipping for Debian systems and on the
> > > base Google provided GCE Debian images. Unfortunately, we never did find a
> > > DD sponsor to help maintain our guest packages in Debian on the cadence
> > > that we needed. I would advocate for removing this package from Debian if
> > > we can't find a set of maintainers.
> > 
> > Hi Zach,
> > as it stands google-compute-image-packages won't be part of the next Debian
> > stable release. Givem the last upload was in Oct 2019 the package seems
> > unmaintained anyway, so if noone steps up to maintain it in the next months
> > it's probably best to remove it entirely.
> 
> If we ever want to get to a point where the Debian cloud team is able to
> publish useful images to the Google cloud service, we'll need to get
> this package into shape for inclusion in a stable release.  The lack of
> good maintenance of packages such as this one is a big factor in us not
> being able to do so.  The package is nominally maintained by the cloud
> team, but none of the current members is active in working with it.

I hope that we're be able to change it, but for me fundamental question is if
Google is interested in participating in effort to keep those packages in
Debian main and if so what resources can be committed to do so.
From my side I can say that I'll try to find time to work on the relevant
packages or to sponsor uploads if somebody else want to take on this task.

So for me fist step for restarting this work would be to have a conversation
with Zach about agreeing what need to be done, how are we going to do it and
what commitments are we going to put in place to make it relevant in the long
run.

> As there seems to be interest within some members of the Debian
> community in having Debian-published images available for GCE, we should
> try to solicit help with package maintenance before we kick it out for
> good.

Thanks Noah for motivating me to reply to this email. I think this is worthy 
cause
thus I hope we can have sorted without removing those packages from Debian.
-- 

|_|0|_|  |
|_|_|0|  "Panta rei" |
|0|0|0|  kuLa    |

gpg --keyserver pgp.mit.edu --recv-keys 0x686930DD58C338B3
3DF1  A4DF  C732  4688  38BC  F121  6869  30DD  58C3  38B3


signature.asc
Description: PGP signature

Bug#985787: init-system-helpers: deb-systemd-helper - incoherent enable after WantedBy change

[Marcin Szewczyk]

On Tue, Mar 23, 2021 at 04:20:18PM +0100, Michael Biebl wrote:
> Am 23.03.21 um 15:32 schrieb Marcin Szewczyk:
> > Package: init-system-helpers
> > Version: 1.56+nmu1
> > Severity: normal
> > 
> > I use debhelper to install and enable systemd user units. I noticed that
> > after changing the `WantedBy` value from default.target to
> > graphical.target the new symlink was not created.
> 
> This happens rarely enough, that adding explicit support for that in i-s-h
> is probably not worth the complications.
> That said, if someone can come up with a clean patch to do that, I'm happy
> to take a look.

I attach a patch (against debian/1.60). It differs from the one in
#797108. Maybe it goes in an acceptable direction. Please take a look if
you have some time.

Pardon my Perl. I have not used it for 15 years.

>From the commit message:
> take changes in references to units into account
> 
> - react to changes eg. in WantedBy
> - enable: add symlinks to added units
> - update-state: remove state files of no longer managed links (garbage
>   collection)

-- 
Marcin Szewczyk
http://wodny.org
>From bfb0aecc46009cca72f5a3c1b0ca3fb2a2280048 Mon Sep 17 00:00:00 2001
From: Marcin Szewczyk 
Date: Wed, 24 Mar 2021 13:35:22 +0100
Subject: [PATCH] take changes in references to units into account

- react to changes eg. in WantedBy
- enable: add symlinks to added units
- update-state: remove state files of no longer managed links (garbage
  collection)
---
 script/deb-systemd-helper | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/script/deb-systemd-helper b/script/deb-systemd-helper
index 7e929ed..e626380 100755
--- a/script/deb-systemd-helper
+++ b/script/deb-systemd-helper
@@ -250,6 +250,11 @@ sub no_link_installed {
 my ($scriptname, $service_path) = @_;
 
 my @links = get_link_closure($scriptname, $service_path);
+# Previous package version might have managed additional links.
+# Take them into account to determine if the service was previously 
enabled.
+my $dsh_state = dsh_state_path($scriptname);
+my @dsh_links = map { { src => $_ } } state_file_entries($dsh_state);
+push(@links, @dsh_links);
 my @existing_links = grep { -l $_->{src} } @links;
 
 return (@existing_links == 0);
@@ -329,6 +334,7 @@ sub update_state {
 
 my $dsh_state = dsh_state_path($scriptname);
 my @links = get_link_closure($scriptname, $service_path);
+my @dsh_links = state_file_entries($dsh_state);
 
 debug "Old state file contents: " .
 Data::Dumper::Dumper([ state_file_entries($dsh_state) ]);
@@ -344,6 +350,14 @@ sub update_state {
 }
 close($outfh);
 
+# Remove state files of previously managed links if they are no longer 
managed.
+my %links = map { $_->{src} => 1 } @links;
+for my $dsh_link (@dsh_links) {
+my $statefile = $dsh_link;
+$statefile =~ s,^/etc/systemd/$instance/,$enabled_state_dir/,;
+unlink($statefile) unless exists($links{$dsh_link});
+}
+
 debug "Renaming temp file $tmpname to state file $dsh_state";
 rename($tmpname, $dsh_state) or
 error("Unable to move $tmpname to $dsh_state");
-- 
2.25.0

Bug#985787: init-system-helpers: deb-systemd-helper - incoherent enable after WantedBy change

[Marcin Szewczyk]

Package: init-system-helpers
Version: 1.56+nmu1
Severity: normal

Hi,

I use debhelper to install and enable systemd user units. I noticed that
after changing the `WantedBy` value from default.target to
graphical.target the new symlink was not created.

I attach a GraphViz .dot graph which visualizes a troubling number of
states caused by `dpkg -i`. Even more troubling are the facts that:
- reinstallation of the same version changes the state,
- purging the package (`dpkg -P`) can leave dead symlinks.

What do you think about that?

About the graph:
- version 4.0 has `WantedBy=default.target`,
- version 4.3 has `WantedBy=graphical.target`,
- `link` is the state of symlinks in /etc/systemd/user/*.target.wants,
- `dsh` is the state of the .dsh-also file.

At the same time systemctl:
- `enable` would add the second link leaving the first one,
- `disable` would remove both symlinks even if one of them is no longer
  referenced by the unit file,
- `reenable` would leave only the symlink pointing to the currently
  selected target.

I have some additional questions:

Why is `no_link_installed(…)` taken into account when setting
$create_links in `enable(…)`[1]?

[1]: 
https://salsa.debian.org/debian/init-system-helpers/-/blob/master/script/deb-systemd-helper

Is there a reason not to just use `reenable` in postinst scripts?

An old discussion in #717603 suggests[2] that it was intended to take
changes in the [Install] section into account.

[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717603



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

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

Versions of packages init-system-helpers depends on:
ii  perl-base  5.28.1-6+deb10u1

init-system-helpers recommends no packages.

init-system-helpers suggests no packages.

Versions of packages init-system-helpers is related to:
pn  insserv  

-- no debconf information

-- 
Marcin Szewczyk
http://wodny.org
digraph g {
none [ label = "link: (removed)\ndsh: (removed)" ]
none -> def_def [ label = "-i 4.0\nwas-enabled" ]
def_def [ label = "link: default\ndsh: default" ]
def_def -> none [ label = "-P" ]
def_def -> def_def [ label = "-i 4.0\nwas-enabled" ]
def_def -> def_def_graph [ label = "-i 4.3\nwas-enabled" ]
def_def_graph [ label = "link: default\ndsh: default, graphical" ]
def_def_graph -> def_graph [ label = "-i 4.3\nwas-disabled" ]
def_def_graph -> none [ label = "-P" ]
def_graph [ label = "link: default\ndsh: graphical" ]
def_graph -> def_graph [ label = "-i 4.3\nwas-disabled" ]
def_graph -> def_dead [ label = "-P" ]
def_dead [ label = "link: default (dead)\ndsh: (removed)" ]
none -> graph_graph [ label = "-i 4.3\nwas-enabled" ]
graph_graph [ label = "link: graph\ndsh: graph" ]
graph_graph -> none [ label = "-P"]
}

Bug#973474: Info received (Bug#973474: gnome: Unable to log back in in after screen lock)

[Marcin Owsiany]

tag 973474 -unreproducible -moreinfo
thanks

I think now that I have provided the requested information and we know how
to reproduce the bug, and have a rough idea what the issue is, we can
remove these tags.

Marcin

Bug#983178: Created a merge request fixing this issue

[Marcin Owsiany]

pt., 5 mar 2021 o 10:44 Marcin Owsiany  napisał(a):

> Let me change the code to avoid sending it if the output is empty.
>

Done, PTAL.
https://salsa.debian.org/webmaster-team/cron/-/merge_requests/6

Marcin

Bug#983178: Created a merge request fixing this issue

[Marcin Owsiany]

HI Laura,

czw., 4 mar 2021 o 22:52 Laura Arjona Reina  napisał(a):

> Hello Marcin
> thank you very much for working on this!
>

My pleasure ;-)


> I have had a look at the merge request in salsa, but couldn't test the
> script myself (yet).
>
> For what I understood (please correct me if I am wrong), the output is
> filtered when composing the mail, so for languages having only the same
> validation issues than English, translators would get a mail anyway, just
> with almost empty content.
>

Ouch, you're completely right, and that was *not* my intention.


> I wonder if it's maybe better to filter and rewrite the log files, so the
> languages having derived from English issues don't receive mail (at least
> until English is fixed), or better to just add a sentence like "you may
> have additional validation issues that need to be fixed in the
> corresponding English file(s), too." to the mail.


The whole reason for me filing this bug and writing this code was to avoid
receiving the email. And an empty one would be even more annoying than the
current state :-D
Let me change the code to avoid sending it if the output is empty. However
I think it's better to keep the log files intact, in case one wants to see
the full picture via https://www-master.debian.org/build-logs/validate

Marcin

Bug#983178: Created a merge request fixing this issue

[Marcin Owsiany]

I created https://salsa.debian.org/webmaster-team/cron/-/merge_requests/6
which fixes this issue.
It would be great if someone could review and/or merge.

Marcin

Bug#973474: gnome: Unable to log back in in after screen lock

[Marcin Owsiany]

Hi again,

wt., 2 mar 2021 o 02:31 Simon McVittie  napisał(a):

> On Mon, 01 Mar 2021 at 22:48:47 +0100, Marcin Owsiany wrote:
> > I installed from debian-bullseye-DI-alpha3-amd64-netinst.iso in
> virt-manager VM
> > with 2 VCPUs and 4GB of RAM.
> > Other than selecting Polish locale and installing ssh server and all
> possible
> > display managers and window environments that debian-installer allows I
> don't
> > remember doing anything special.
>
> I hope that's pl_PL.UTF-8 rather than a non-Unicode character set?
>

Yes, the latin2 nightmare is long gone :-)


> Installing all possible desktop environments probably results in each
> desktop environment having a "thundering herd" of session services all
> trying to jump in and do similar things at around the same time, so it
> doesn't entirely surprise me if some of them end up fighting.
> Unfortunately, the same pile of extra processes also obscures what is
> going on in the log.
>

Right. I made yet another attempt to reproduce this, aiming for as short a
journal log as I could.
The result is "just" 2570 lines this time.
https://people.debian.org/~porridge/journal3.txt
It also includes "logger" markers which I made from a single ssh session,
which helps reduce the overall number of sessions.
It might serve better as a minimal repro for filing an upstream bug.

$ egrep --color 'Session [0-9a-f]|porridge\[[0-9]*\]:' journal3.txt
mar 02 22:37:39 debian systemd[1]: Started Session c1 of user Debian-gdm.
mar 02 22:38:10 debian systemd[1]: Started Session 2 of user porridge.
mar 02 22:38:22 debian porridge[5608]: ssh-logged-in
mar 02 22:38:35 debian porridge[5615]: cinnamon-starting-login
mar 02 22:38:36 debian systemd[1]: Started Session 4 of user porridge.
mar 02 22:38:47 debian systemd-logind[465]: Session c1 logged out. Waiting
for processes to exit.
mar 02 22:38:49 debian porridge[7641]: cinnamon-starting-logout
mar 02 22:38:50 debian systemd-logind[465]: Session 4 logged out. Waiting
for processes to exit.
mar 02 22:38:50 debian systemd[1]: Started Session c2 of user Debian-gdm.
mar 02 22:39:02 debian porridge[7905]: gnome-starting-login
mar 02 22:39:04 debian systemd[1]: Started Session 5 of user porridge.
mar 02 22:39:07 debian systemd-logind[465]: Session c2 logged out. Waiting
for processes to exit.
mar 02 22:39:10 debian porridge[9464]: gnome-starting-screenlock
mar 02 22:39:24 debian porridge[9739]: gnome-attempting-unlock
mar 02 22:39:27 debian porridge[10824]: gnome-stuck
mar 02 22:39:29 debian porridge[10831]: ssh-logging-out
mar 02 22:39:30 debian systemd-logind[465]: Session 2 logged out. Waiting
for processes to exit.
mar 02 22:39:36 debian systemd[1]: Started Session 6 of user porridge.

To summarize the above:
- c1 is the gdm session where I log into cinnamon
- 2 is my ssh session for calling logger
- 4 is the cinnamon X session
- c2 is the gdm session where I log into GNOME
- 5 is the GNOME session
- 6 is another ssh login, irrelevant

And now it's pretty clear that indeed gnome-shell for some reason thinks it
belongs to session 4, while it's part of session 5.

$ grep NoSuchSession journal3.txt
mar 02 22:39:05 debian gnome-shell[7965]: JS ERROR: Could not get a proxy
for the current session: Gio.IOErrorEnum:
GDBus.Error:org.freedesktop.login1.NoSuchSession: No session '4' known

In fact, session 4 is reported to be gone for good 4 seconds before I even
press ENTER after the password to log into GNOME:
mar 02 22:38:57 debian systemd-logind[465]: Removed session 4.
mar 02 22:39:02 debian porridge[7905]: gnome-starting-login

Now back to your questions from the previous time:

> To verify, I subsequently (without rebooting the VM) logged into and out
> of
> > Cinnamon session once more, and then logged into the GNOME session again
> > (without running the logger commands this time), and WAS able to
> reproduce the
> > issue.
> >
> > I have a full output of journalctl for that run of the VM, at [8]https://
> > people.debian.org/~porridge/journal.txt.gz
>
> At what time did you log into and out of Cinnamon, and at what time did you
> log into GNOME?
>
> If they are the last ones in the log,


Sorry, I didn't record the times, but yes, they should be the last two
sessions in this order.


> then the timeline is:
>
> 22:22:47 start to log in to Cinnamon on tty4, logind session 13
> 22:22:58 gdm greeter on tty1 exits
> 22:23:02 log out from Cinnamon
> 22:23:03 gdm vt-switches back to tty1 and launches a new greeter
> 22:23:08 logind session 13 ends
> 22:23:16 start to log in to GNOME (session 15)
>
> This is where it gets confusing. systemd --user process 23531 seems to be
> trying to start a GNOME Shell session on Wayland and on X11 simultaneously
> (or something?) and then at 22:23:19 we see:

Bug#973474: gnome: Unable to log back in in after screen lock

[Marcin Owsiany]

Hello again,

sob., 27 lut 2021 o 22:28 Simon McVittie  napisał(a):

> <https://people.debian.org/~smcv/973474/> (and then after pressing Enter
> for my test user's password, I'm back to my unlocked session, equivalent
> to <https://people.debian.org/~smcv/973474/5.png>). At what point does
> what you see diverge from that?
>

See the files {1,2,3,4}-*.png in https://people.debian.org/~porridge/ which
illustrate what happens step by step when I try to unlock.


> Given that you see messages from Xorg, I would also expect to see more
> messages than just those. Before locking the screen, please run
>
> logger "before locking"
>
> to leave a marker in the system log; and then please look back through
> the system log at least as far as that marker.
>

Today I managed to reproduce the bug by doing the following:
- boot the VM
- log into the "Cinnamon" session
- log out
- log into the "Gnome" session
- run `logger "before lock"` via ssh into the VM
- lock screen
- try to unlock

This is the contents of journal (from `sudo journalctl`) between the logger
line and the message produced when trying to unlock:
http://paste.debian.net/1187416/

If you look at the systemd journal (as root) instead of syslog, you'll
> also see "auth" messages, which could be relevant: for instance, when
> you enter a wrong password, that should be logged as an "auth" message
> from PAM.
>
> Please describe the steps you took to install your test VM, including
> any non-default settings used? For example, I wonder whether this is
> locale-sensitive - I'm using en_GB.UTF-8 but you seem to be using a
> non-English locale.
>

I installed from debian-bullseye-DI-alpha3-amd64-netinst.iso in
virt-manager VM with 2 VCPUs and 4GB of RAM.
Other than selecting Polish locale and installing ssh server and all
possible display managers and window environments that debian-installer
allows I don't remember doing anything special.


> If your test VM does not contain any personal or confidential data,
> and you can can transfer files off it with ssh, a shared filesystem or
> paste.debian.net, it would be useful to see the entire systemd journal
> (starting from boot) for this procedure:
>
> - boot the VM
> - log in as a user
> - lock the screen
> - unlock with a correct password
>
> and compare it with
> <https://people.debian.org/~smcv/973474/journalctl_-b.log.gz>.
>

So as mentioned before the above is not enough to reproduce the bug for me
either.
But I rebooted the VM and tried to reproduce again using the steps I
mentioned above, in order to grab a clean log from boot.
I also ran "logger" commands at a few steps to make the log easier to read,
and... this time the problem did not appear.
My gut feeling is that the additional switching to and from an ssh session
to run these commands slowed me down a little, and the changed timing was
enough for some leftover process from the Cinnamon session to disappear
before I locked the screen.
To verify, I subsequently (without rebooting the VM) logged into and out of
Cinnamon session once more, and then logged into the GNOME session again
(without running the logger commands this time), and WAS able to reproduce
the issue.

I have a full output of journalctl for that run of the VM, at
https://people.debian.org/~porridge/journal.txt.gz


> > Is there perhaps some setting I could tweak to convince gnome-shell to
> produce
> > some debug output when I attempt unlocking?
>
> Try these:
>
> systemctl --user edit gnome-shell@x11.service
> systemctl --user edit gnome-shell@wayland.service
> sudo systemctl edit gdm.service
>
> and in each case, add this:
>
> [Service]
> Environment=G_MESSAGES_DEBUG=all
>

I also attempted to increase verbosity level with the commands you
provided, but the first two ones failed for me:
porridge@debian:~$ systemctl --user edit gnome-shell@x11.service
No files found for gnome-shell@x11.service.
Run 'systemctl edit --user --force --full gnome-shell@x11.service' to
create a new unit.
porridge@debian:~$ systemctl --user edit gnome-shell@wayland.service
No files found for gnome-shell@wayland.service.
Run 'systemctl edit --user --force --full gnome-shell@wayland.service' to
create a new unit.

I wasn't sure whether it was OK to `--force`, or whether editing
gdm.service made sense without the other two. Please advise.

Marcin

Bug#973474: gnome: Unable to log back in in after screen lock

[Marcin Owsiany]

Just a quick note because I think I have a lead, but won't be able to go
through all your suggestions today.

First of all, I'm also unable to reproduce the issue if I go straight to
logging into the Gnome session after booting my VM.

However I am able to reproduce it if I first log into and log out of a few
other session types.
I'm still trying to figure out the minimal set which triggers the issue
consistently, but so far I can see the issue if I:
- boot the VM
- log into LXDE session and log out
- log into Cinnamon session and log out
- log into "System X11 default" session which I think is LXQT in this case,
and log out
- log into Gnome session
- lock the screen through the menu in upper right-hand corner
- try to unlock

FWIW, the message which "journalctl -f" shows (in an ssh session running in
parallel) when I enter the unlock password is:

lut 28 21:48:52 debian gdm-password][38277]: gkr-pam: unlocked login keyring

A few replies to some of your points below, I'll keep digging whenever I
have some free time in the coming week.

sob., 27 lut 2021 o 22:28 Simon McVittie  napisał(a):

> On Sat, 27 Feb 2021 at 19:21:46 +0100, Marcin Owsiany wrote:
> > Regarding the messages I see in syslog, see the screenshot I had
> attached to my
> > previous message.
>
> On a freshly-installed, up to date test VM, you should find that the gdm
> login screen has a grey background, but the gnome-shell lock screen has a
> dark blue background (it's a blurred version of your desktop background,
> for which the default in Debian 11 is going to be dark blue).


Right, I'm pretty sure the weird behaviour is in the lock screen, not the
gdm login screen.


> It would
> be useful if you could describe the steps you use to reproduce this bug,
> and at each step that involves a login screen, say whether the background
> is grey or blue.
>
> Here is a sequence of screenshots illustrating my
> attempt to reproduce this, together with my system log:
> <https://people.debian.org/~smcv/973474/> (and then after pressing Enter
> for my test user's password, I'm back to my unlocked session, equivalent
> to <https://people.debian.org/~smcv/973474/5.png>). At what point does
> what you see diverge from that?
>
> I'm surprised you see messages from Xorg: those should only appear when
> you start a completely new session, not when you just lock and unlock
> the screen. This suggests that maybe the session is crashing, and instead
> of the gnome-shell lock screen on tty7, you are going back to the gdm
> login screen on tty1.
>

As far as I can tell it's not crashing. Could they have been triggered by
switching between virtual consoles?
Going forward I'll try to use a parallel SSH login rather than messing
around with CTRL+ALT+Fx to keep things simpler.


> Given that you see messages from Xorg, I would also expect to see more
> messages than just those. Before locking the screen, please run
>
> logger "before locking"
>
> to leave a marker in the system log; and then please look back through
> the system log at least as far as that marker.
>
> If you look at the systemd journal (as root) instead of syslog, you'll
> also see "auth" messages, which could be relevant: for instance, when
> you enter a wrong password, that should be logged as an "auth" message
> from PAM.
>
> Please describe the steps you took to install your test VM, including
> any non-default settings used? For example, I wonder whether this is
> locale-sensitive - I'm using en_GB.UTF-8 but you seem to be using a
> non-English locale.
>
> If your test VM does not contain any personal or confidential data,
> and you can can transfer files off it with ssh, a shared filesystem or
> paste.debian.net, it would be useful to see the entire systemd journal
> (starting from boot) for this procedure:
>
> - boot the VM
> - log in as a user
> - lock the screen
> - unlock with a correct password
>
> and compare it with
> <https://people.debian.org/~smcv/973474/journalctl_-b.log.gz>.
>
> Or if your test VM contains personal/confidential things, please could
> you try to set up a similar VM without those and reproduce the bug there?
>
> > Is there perhaps some setting I could tweak to convince gnome-shell to
> produce
> > some debug output when I attempt unlocking?
>
> Try these:
>
> systemctl --user edit gnome-shell@x11.service
> systemctl --user edit gnome-shell@wayland.service
> sudo systemctl edit gdm.service
>
> and in each case, add this:
>
> [Service]
> Environment=G_MESSAGES_DEBUG=all
>
> Thanks,
> smcv
>

Bug#973474: gnome: Unable to log back in in after screen lock

[Marcin Owsiany]

Thank you for looking into this Simon.

Regarding the messages I see in syslog, see the screenshot I had attached
to my previous message.

Is there perhaps some setting I could tweak to convince gnome-shell to
produce some debug output when I attempt unlocking?

Marcin

Bug#983178: Some validation errors are not actionable for translators

[Marcin Owsiany]

Package: www.debian.org
Severity: minor
Tags: l10n

Background
--

Validation errors are emailed daily to (among others) translation
coordinators by the validate-mail script:
https://salsa.debian.org/webmaster-team/cron/-/blob/master/scripts/validate-mail

This is very useful, since I *DO* want to be notified about issues
introduced by those who translate to my language (whether it's me or
someone else).


The issue
-

*However*, since most translated WML files have the same markup
structure as the English originals, most (if not all) validation errors
for English pages also apply to the translated pages. Compare for
example:

https://www-master.debian.org/build-logs/validate/en
and
https://www-master.debian.org/build-logs/validate/pl

In a typical ephemeral case (someone commits broken markup and it gets
fixed a couple days later) this is merely distracting. It was bugging me
whan I was actively working on the translations a couple of decades ago
:-) but it was never annoying enough to do something about it.

However these days there are some long-standing issues which will
probably take some more time to resolve: https://bugs.debian.org/980921
The fix is being discussed for weeks and is likely to take some more
time. This means it is not really actionable to a typical translator.

Even in case of smaller issues, unfortunately having very limited time
resources I cannot afford to chase every markup validation issue in the
that is merely copied with the structure of the page translated to my
language.


My proposal
---

What I'd like to propose is to take advantage of the fact that the
original and translated pages have the same structure, in order to make
translation coordinators' lives a little easier.

My idea is to change the validate-mail script: when mailing validation
errors of a given language (other than English), omit all the errors
which *also* appear in the English validation output.  It's not going to
be perfect (because line numbers will have to be ignored), but should
work reasonably well in most cases, and not interfere the steady state
(no validation errors in the English version).


regards,
Marcin

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

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

Bug#980921: Validation of HTML5

[Marcin Owsiany]

Package: www.debian.org
Followup-For: Bug #980921

When thinking about the migration, please also take into account the
effect of moving to HTML on the validation script.

I don't know whether I did it correctly, but for me simply replacing the
doctype with "html" caused the validation script to fail with:

*** Errors validating ../view-source_https___www.debian.org.html: ***
Line 1, character 15:  no internal or external document type declaration
subset; will parse without validation
Line 51, character 24:  general entity "nbsp" not defined and no default
entity
Line 51, character 28:  reference to entity "nbsp" for which no system
identifier could be generated
Line 256, character 115:  reference to entity "nbsp" for which no system
identifier could be generated
Line 257, character 121:  reference to entity "nbsp" for which no system
identifier could be generated
Line 261, character 117:  reference to entity "nbsp" for which no system
identifier could be generated
Line 265, character 118:  reference to entity "nbsp" for which no system
identifier could be generated
Line 267, character 115:  reference to entity "nbsp" for which no system
identifier could be generated
Line 270, character 116:  reference to entity "nbsp" for which no system
identifier could be generated
Line 272, character 118:  reference to entity "nbsp" for which no system
identifier could be generated

I suppose this is because the validator is based on the DTDs in
/usr/share/sgml/html/... and there is none for HTML5 there?

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

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

Bug#973474: Same problem here

[Marcin Owsiany]

severity 973474 grave
thanks

Upgrading the bug severity since it requires killing one's session to
recover from, taking all unsaved work with it.

I installed Debian testing today in a VM and have the same problem in the
GNOME+X11 session.
When I type the wrong password in the lock screen, there is a spinner and
after a few seconds an error message.
When I type the correct password, it *immediately* goes back to asking for
the password.
I can CTRL+ALT+F2 to log in at a text console to debug this, but I'm not
sure how to go about this. "DISPLAY=:0 xlsclients" does not show a
screensaver process running. Is the locking done by gnome-shell itself
these days?
I do not see anything related in syslog. Attaching a screenshot of what was
logged while I switched to the locked session, attempted a login, and
switched back to text console, in case someone wants to take a look.

Bug#981201: The autopkgtests are flaky on slow architectures

[Marcin Owsiany]

reassign 981201 xvfb
thanks

I've submitted a pull request against xvfb-run to achieve this.
https://salsa.debian.org/xorg-team/xserver/xorg-server/-/merge_requests/6
Hopefully the X strike force folks will look at it kindly.

FWIW, the way this can be reproduced easily even on amd64 is:
1. in first terminal, run "Xvfb :66"
2. in second terminal, run "DISPLAY=:66 xeyes"
3. in third terminal, run xlsclients in a tight loop: "while :;do
DISPLAY=:66 xlsclients || echo FAIL;done" - it will produce a stream of
"yourhostname xeyes"
4. then press CTRL+C in the second terminal
5. notice how in the third terminal, xlsclients has failed to connect

Bug#981201: The autopkgtests are flaky on slow architectures

[Marcin Owsiany]

Thanks, I'll check it out.

My concern here is that we're effectively papering over some issue in xvfb,
in multiple places rather than fixing it once properly at the source.

Marcin

Bug#981201: The autopkgtests are flaky on slow architectures

[Marcin Owsiany]

Thanks for the report, Sebastien!
I'd like to understand the issue better. Can you please point me at an
example flake?

Marcin

Bug#977562: systemd: Incorrect order of agetty arguments in serial-getty@ttyS0.service definition file

[Marcin Krol]

Well, I hoped that you'd simply change that order in the service file 
(I'm new to this, do you expect me to produce patch or something like 
that?). Otherwise serial comm doesn't work, at least for me.





On 1/14/21 3:06 PM, Michael Biebl wrote:

Am 19.12.20 um 16:47 schrieb Andreas Henriksson:

Control: tags -1 + moreinfo

On Wed, Dec 16, 2020 at 11:39:06PM +0100, Michael Biebl wrote:

Am 16.12.20 um 20:49 schrieb MK:

Package: systemd
Version: 241-7~deb10u5
Severity: normal

[...]
Incorrect order of arguments to agetty in the 
serial-getty@ttyS0.service

unit file.

It is:

ExecStart=/sbin/agetty --autologin root -8 --keep-baud 
115200,38400,9600 ttyS0 xterm-256color



While it should be like:

ExecStart=/sbin/agetty --autologin root -8 --keep-baud ttyS0 115200 
xterm-256color

[...]

According to the examples in man agetty, both should work.

Andreas, can you comment here?
If what MK is saying, should the "EXAMPLE" section in man agetty be 
updated?




I don't really have much prior knowledge about *getty, but in my past
experience with other util-linux tools it is often the case that
(likely for historical reasons/compatibility) the arguments that
doesn't come in a dash-form is attempted to be accepted in either
order based on guessing which one was specified. In my past experience
something that was guessable in the past might in later years become
sometimes impossible to correctly guess right, so sticking with
what synopsis describes is usually the safest as far as I'm concerned.

In the agetty case, the guessing is done here:
https://sources.debian.org/src/util-linux/2.36.1-2/term-utils/agetty.c/#L897 



is_speed basically checks if the current argument only consists of
either 0-9 or ','.

It is not obvious to me how it could go wrong in the example originally
described in this bug report.

Please also note that for example sysvinit's inittab also uses getty
with arguments in both orders.

Simply it should work either way.

Please also note that the argument order is not the only thing changed.
It was also changed from specifying 3 speeds to only 1.

Maybe the real issue here is that line speed detection isn't working?
I'd appreciate if the bug reporter could dive a bit deeper into the
problem.



@MK any further feedback? Otherwise I would close this bug report.

Regards,
Michael

Bug#979245: RFS: xylib/1.6-0.1 [RC] [NMU] -- Library for reading x-y data from several file formats

[Marcin Wojdyr]

Thanks Fabian!
To make it official, I orphaned xylib in #979256.
Happy 2021!
Marcin


On Mon, 4 Jan 2021 at 17:54, Fabian Wolff  wrote:
>
> Package: sponsorship-requests
> Severity: important
> X-Debbugs-CC: woj...@gmail.com
>
> Dear mentors,
>
> I am looking for a sponsor for a non-maintainer upload for the 'xylib'
> package.
>
> The package currently suffers from RC bug #975672; in the bug
> discussion, the current package maintainer has pointed out that the
> latest upstream release solves the bug, and that he is no longer able
> to maintain the Debian package (the last upload was five years ago).
>
> I have thus taken the liberty to package this new upstream release and
> perform some maintenance work which may exceed what is considered
> customary for a normal NMU but is arguably non-controversial and
> reversible (e.g., updating debian/copyright and changing it to the
> machine-readable format).
>
> I have also added the current package maintainer in X-Debbugs-CC so
> that he can voice any objections he may have regarding this NMU.
>
> The package is on Salsa and on Mentors:
>
>   https://mentors.debian.net/package/xylib/
>   https://salsa.debian.org/science-team/xylib
>
> Thanks!
> Fabian

Bug#979256: O: xylib - library for reading x-y data from several file formats

[Marcin Wojdyr]

Package: wnpp
Severity: normal

Hi, I haven't been really maintaining xylib (nor any other Debian
package) for years, so I guess it's time for me to officially orphan
it.

Package description:
C++ library for reading files that contain x-y data from powder
diffraction, spectroscopy and other experimental methods. The
supported formats include: VAMAS, pdCIF, Bruker UXD and RAW, Philips
UDF and RD, Rigaku DAT, Sietronics CPI, DBWS/DMPLOT, Koalariet XDD and
others.

Probably the only package that depends on it is fityk.

Thanks,
Marcin

Bug#975672: xylib: FTBFS against boost_1.74

[Marcin Wojdyr]

This was fixed in the latest release upstream:
https://github.com/wojdyr/xylib/releases
but unfortunately I'm no longer able to maintain the Debian package.
The only package that depends on xylib is fityk. Perhaps fityk
maintainers could help.

Best wishes,
Marcin

Bug#976808: d-i Alpha 3 seems unusable for qemu-system-aarch64

[Marcin Juszkiewicz]

W dniu 08.12.2020 o 11:13, Alper Nebi Yasak pisze:

On 08/12/2020 12:26, Marcin Juszkiewicz wrote:



Both standard and graphical installer contain kernel modules for virtio
framebuffer. And both ignore video output forcing user to use serial
console. Also while 'standard' installer gives "d-i in screen",
graphical one gave just d-i on serial console.

/proc/consoles has only ttyAMA0


This only happens on arm64 ACPI systems with SPCR (QEMU VM is one) now.
The arm64 graphical installer should be working fine in this release
with device-tree systems, which do have tty0 in /proc/consoles.


So maybe there should be message "Debian is for SBC, please use 
$OTHER_DISTRO for servers/etc" on d-i website?



You can still work around it with "console=tty0". Even more, the ACPI
case is fixed on git (by explicitly checking /dev/tty0), but that didn't
make into this alpha release.


D-I has issues with AArch64/ACPI systems since probably forever.

Bug#976808: d-i Alpha 3 seems unusable for qemu-system-aarch64

[Marcin Juszkiewicz]

W dniu 08.12.2020 o 09:06, Ryutaroh Matsumoto pisze:

Hi Debian Arm users,

I tried Bullseye d-i Alpha3 released on December 6 for
building a qemu disk image usable by qemu-system-aarch64.
To me, Alpha 3 d-i seems almost unusable for that purpose.
I filed a report at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976808

If you have interest, please have a look.  Ryutaroh


You have started machine in QEMU without any graphics support and got 
surprised by lack of graphics?


But even with "-device virtio-gpu-pci" added Bullseye alpha3 installer 
follows the path of Buster :(


Both standard and graphical installer contain kernel modules for virtio 
framebuffer. And both ignore video output forcing user to use serial 
console. Also while 'standard' installer gives "d-i in screen", 
graphical one gave just d-i on serial console.


/proc/consoles has only ttyAMA0


I used fresh build of upstream EDK2. Command used:

qemu-system-aarch64 \
 -drive if=pflash,format=raw,file=QEMU_EFI.fd \
 -drive if=pflash,format=raw,file=QEMU_EFI-vars.fd \
 -drive 
if=virtio,format=raw,readonly=on,media=cdrom,file=debian-bullseye-DI-alpha3-arm64-netinst.iso 
\

 -device virtio-gpu-pci \
 -device qemu-xhci,id=usb \
 -usb \
 -device usb-kbd \
 -device usb-tablet \
 -machine virt,gic-version=3,iommu=smmuv3  \
 -cpu max  \
 -smp 2 \
 -m 4096  \
 -monitor telnet::45454,server,nowait \
 -serial stdio


I gave up on getting sane installer experience in Debian/arm64.

Bug#973683: some images blacklisted by Google Chrome safe browsing

[Marcin Owsiany]

If it would be possible to include a few words of warning at the top of
file listings, that would be great.
I vaguely remember it was possible to configure Apache in a way that it
would include the contents of a README file in the index itself?

Unfortunately I don't think patching Debian-distributed Firefox is going to
help much here. The point is that these files need to be downloadable from
a non-Debian OS!

Did we try talking to the problematic mirror providers about the issues our
users are facing? I understand this may be a delicate issue to some, but I
guess it does not hurt to at least start a discussion?
FWIW I don't think Google's file scanner cares whether the mirror is in
Sweden or not :-)

Bug#973683: some images blacklisted by Google Chrome safe browsing

[Marcin Owsiany]

It's not a problem for me, I'm more concerned about other users who may not
have access to another browser or HTTP client.
For all they will know, Debian has been pwned :-/

Bug#973683: some images blacklisted by Google Chrome safe browsing

[Marcin Owsiany]

Package: cdimage.debian.org
Severity: important

Noticed today that when I tried to download
https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-10.6.0-amd64-gnome.iso
my browser (Google chrome) refused to fetch the file (giving me no way
to override) saying that it is unsafe, therefore it was blocked by
Chrome.

I think this feature is called "safe browsing" and in general helps users
avoid getting phished.

Clicking "more information" leads me to 
https://support.google.com/chrome/answer/6261569?p=ib_download_blocked

FWIW downloading the unofficial gnome image from
https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/10.6.0-live+nonfree/amd64/iso-hybrid/debian-live-10.6.0-amd64-gnome+nonfree.iso
was fine.


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

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

Bug#972940: pmdk: Provide pmdk packages for arm64 for buster

[Marcin Juszkiewicz]

W dniu 26.10.2020 o 13:56, Adam Borowski pisze:

On Mon, Oct 26, 2020 at 12:46:01PM +, Marcin Juszkiewicz wrote:



Once libfabric gets fixed then pmdk 1.9.1-3 can get most of it's
dependencies from buster-backports. Valgrind 0.15 is not available for
buster.


Without that fix, valgrind tests crash on cache flush instructions.


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973009 oponed for 
Valgrind.

Bug#973009: valgrind: Backport 3.16 to buster

[Marcin Juszkiewicz]

Source: valgrind
Severity: normal

Could you update version of valgrind package in buster to 3.16? Let me
tell you why.

Recently OpenStack 'victoria' got released. It requires qemu 4.0.0 or
higher. Debian has 3.1 in buster and 5.0 in buster-backports but newer
one is not available for arm64 architecture (bug [1] reported)

1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971442

The reason is lack of pmdk build for arm64. Which requires valgrind
3.15+ to pass tests on arm64 (information from bug [2] against pmdk).

2. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972940

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

Kernel: Linux 5.8.14-300.fc33.x86_64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Bug#972940: pmdk: Provide pmdk packages for arm64 for buster

[Marcin Juszkiewicz]

Source: pmdk
Severity: important

Could you provide arm64 version of pmdk package in buster (or
buster-backports)?

Recently OpenStack 'victoria' got released. It requires qemu 4.0.0 or
higher. Debian has 3.1 in buster and 5.0 in buster-backports but newer
one is not available for arm64 architecture (bug [1] reported)

1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971442

The reason is lack of pmdk build for arm64. Which requires libfabric.
Both those packages are amd64/i386 only in buster. I reported bug [2]
against libfabric already.

2. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972939

Once libfabric gets fixed then pmdk 1.9.1-3 can get most of it's
dependencies from buster-backports. Valgrind 0.15 is not available for
buster.

pmdk 1.9.1-3 compiles for arm64 - it is going through tests while I
report bug.


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

Kernel: Linux 5.8.14-300.fc33.x86_64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Bug#972939: libfabric: Provide libfabric packages for arm64

[Marcin Juszkiewicz]

Source: libfabric
Severity: important

Could you provide arm64 version of libfabric package in buster (or
buster-backports)?

Recently OpenStack 'victoria' got released. It requires qemu 4.0.0 or
higher. Debian has 3.1 in buster and 5.0 in buster-backports but newer
one is not available for arm64 architecture (bug [1] reported)

1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971442

The reason is lack of pmdk build for arm64. Which requires libfabric.
Both those packages are amd64/i386 only in buster. I will report bug
against pmdk too.

libfabric 1.11.0-2 built fine on buster. 1.6.2-3 requires
libpsm-infinipath1-dev package which is not available for arm64.

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

Kernel: Linux 5.8.14-300.fc33.x86_64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Bug#971442: qemu: No arm64 package in buster-backports

[Marcin Juszkiewicz]

Source: qemu
Version: 1:5.0-14~bpo10+1
Severity: important

QEMU 5.0 build depends on libpmem which is x86 only in Buster. Due to this
there is no arm64 package available in buster-backports repository.

This cause a problem because if we want to use current OpenStack then we are
not able to - Nova (compute component) requires QEMU 4.0.0 or latest.

Rebuild of qemu backport without pmem support for arm64 looks like the easiest
solution.

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

Kernel: Linux 4.19.0-11-amd64 (SMP w/5 CPU cores)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), 
LANGUAGE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#968190: gnome-terminal is not listed by firefox when it wants to share a screen

[Marcin Szamotulski]

Thanks, that's indeed the case.

On Mon, 10 Aug 2020 19:19:29 +0100 Simon McVittie  wrote:
> On Mon, 10 Aug 2020 at 11:20:33 +0000, Marcin Szamotulski wrote:
> >Trying to share a gnome-terminal window in firefox (firefox-79.0, but
> >also in previous versions of firefox).
> 
> If you're in the default (Wayland) GNOME session, gnome-terminal doesn't
> have any X11 windows. I suspect Firefox can only share X11 windows.
> 
> Please try this workaround (this assumes you are using gdm, other display
> managers will probably have a similar flow):
> 
> - save documents, etc.
> - log out
> - choose/enter your username
> - before typing your password, click the gear-wheel icon and select
>   session type "GNOME on Xorg"
> - finish logging back in
> 
> If that is successful, then my guess about the cause was probably correct.
> 
> The long-term solution to window and desktop sharing in GNOME Wayland
> sessions is to use Pipewire, but the version of Pipewire currently in
> Debian is too old (#954022) and Firefox doesn't support it yet anyway
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1430775).
> 
> smcv
> 
> 


signature.asc
Description: PGP signature


signature.asc
Description: OpenPGP digital signature

Bug#968190: gnome-terminal is not listed by firefox when it wants to share a screen

[Marcin Szamotulski]

Package: gnome-terminal
Version: 3.36.2-1
Severity: normal
X-Debbugs-Cc: profunc...@pm.me

Dear Maintainer,

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

   * What led up to the situation?

   Trying to share a gnome-terminal window in firefox (firefox-79.0, but
   also in previous versions of firefox).

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



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

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

Versions of packages gnome-terminal depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-1
ii  dbus-x11 [dbus-session-bus]   1.12.20-1
ii  dconf-gsettings-backend [gsettings-backend]   0.36.0-1
ii  gnome-terminal-data   3.36.2-1
ii  gsettings-desktop-schemas 3.36.1-1
ii  libatk1.0-0   2.36.0-2
ii  libc6 2.31-3
ii  libdconf1 0.36.0-1
ii  libglib2.0-0  2.64.4-1
ii  libgtk-3-03.24.20-1
ii  libpango-1.0-01.44.7-5
ii  libuuid1  2.36-2
ii  libvte-2.91-0 0.60.3-1
ii  libx11-6  2:1.6.10-3

Versions of packages gnome-terminal recommends:
ii  gvfs   1.44.1-1
ii  nautilus-extension-gnome-terminal  3.36.2-1
ii  yelp   3.36.0-1

gnome-terminal suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature


signature.asc
Description: OpenPGP digital signature

Bug#966438: src:bambam: Autopkgtest fail wiht newer imagemagick*

[Marcin Owsiany]

Bastien, the screenshot is there, in the artifact tarball from autopkgtest.

I had some free time today and took a look at this in some detail. The
problem is indeed in the changed output format from "convert", bambam is
working as expected.

I have a fix ready and hope to upload it this weekend or next week.

wt., 28 lip 2020, 16:54 użytkownik Bastien Roucariès <
roucaries.bast...@gmail.com> napisał:

> Package: src:bambam
> Version: 1.0.1+dfsg-1
> Severity: serious
> Justification: block imagemagick
>
> Dear Maintainer,
>
> Upgrading imagemagick fail due to autopkg test failling for your package.
> See
> https://ci.debian.net/data/autopkgtest/testing/amd64/b/bambam/6448023/log.gz
>
> Could you :
> 1. Fix the failure
> 2. Please in case of error take a screenshot convert it to png and print
> the png as base64 (help debugging)
>
> Bastien
>

Bug#966437: bambam: autopkgtest failure with imagemagick 8:6.9.11.24+dfsg-1

[Marcin Owsiany]

Just a quick note before I get a chance to look at this closer, in case
anyone else wants to take a stab at it.
It's one thing that the color output format changed in a way that the test
program does not know how to parse it. That's easy to fix.

It's more worrying that the reported average color stays at
"srgb(98.0209%,98.0209%,98.0209%)"
for 40 attempts. This means that either the screen color isn't in fact
changing (i.e. the game is broken) or that the way the average color is
calculated by imagemagick has changed in a way which makes it unusable :-/

wt., 28 lip 2020 o 16:36 Adrian Bunk  napisał(a):

> Source: bambam
> Version: 1.0.1+dfsg-1
> Severity: serious
> Tags: bullseye sid
>
> https://ci.debian.net/packages/b/bambam/unstable/amd64/
>
> Test success with imagemagick < 8:6.9.11.24+dfsg-1:
> ...
> On attempt 5 the average screen color was too close to white: 233,230,235.
> On attempt 6 the average screen color was too close to white: 225,223,231.
> On attempt 7 the average screen color was too close to white: 223,220,226.
> ...
>
> Test failure with imagemagick 8:6.9.11.24+dfsg-1:
> ...
> On attempt 37 the average screen color was
> srgb(98.0209%,98.0209%,98.0209%).
> On attempt 38 the average screen color was
> srgb(98.0209%,98.0209%,98.0209%).
> On attempt 39 the average screen color was
> srgb(98.0209%,98.0209%,98.0209%).
> Traceback (most recent call last):
>   File "./debian/tests/smoke-meat", line 101, in 
> main()
>   File "./debian/tests/smoke-meat", line 24, in main
> await_startup()
>   File "./debian/tests/smoke-meat", line 45, in await_startup
> raise Exception('Failed to see bambam start after %d attempts.' %
> attempt_count)
> Exception: Failed to see bambam start after 40 attempts.
>
>
> I suspect the output of convert changed that is parsed in
>
> https://sources.debian.org/src/bambam/1.0.1+dfsg-1/debian/tests/smoke-meat/#L83
>

Bug#963208: Grub can not be installed on AArch64 board when booted from U-Boot via EFI services

[Marcin Juszkiewicz]

Package: debian-installer
Severity: important

I am trying to install Debian 'testing' on RockPro64 board.

System booted from mainline U-Boot with EFI services enabled. Directly
into d-i from 2020.06.15 copy of debian-testing-arm64-netinst.iso [1].

1. 
https://cdimage.debian.org/cdimage/weekly-builds/arm64/iso-cd/debian-testing-arm64-netinst.iso

Whole installation went fine until Grub installation:

Jun 20 14:44:56 os-prober: debug: running /usr/lib/os-probes/50mounted-tests on 
/dev/sdb2
Jun 20 14:44:56 50mounted-tests: debug: mounted using GRUB fat filesystem driver
Jun 20 14:44:56 50mounted-tests: debug: running subtest 
/usr/lib/os-probes/mounted/40lsb
Jun 20 14:44:56 50mounted-tests: debug: running subtest 
/usr/lib/os-probes/mounted/90linux-distro
Jun 20 14:44:56 grub-installer: info: Installing grub on 'dummy'
Jun 20 14:44:57 grub-installer: info: grub-install does not support --no-floppy
Jun 20 14:44:57 grub-installer: info: Running chroot /target grub-install  
--force "dummy"
Jun 20 14:44:57 grub-installer: Installing for arm64-efi platform.
Jun 20 14:45:01 grub-installer: grub-install: warning: Cannot set EFI variable 
Boot.
Jun 20 14:45:01 grub-installer: grub-install: warning: vars_set_variable: 
write() failed: Invalid argument.
Jun 20 14:45:01 grub-installer: grub-install: warning: _efi_set_variable_mode: 
ops->set_variable() failed: No such file or directory.
Jun 20 14:45:01 grub-installer: grub-install: error: failed to register the EFI 
boot entry: No such file or directory.
Jun 20 14:45:01 grub-installer: error: Running 'grub-install  --force "dummy"' 
failed.

I see Grub being present in /target/boot/efi:

~ # ls -l /target/boot/efi/
drwx--3 root root  8192 Jun 20 14:44 EFI
~ # ls -l /target/boot/efi/EFI/
drwx--2 root root  8192 Jun 20 14:45 debian
~ # ls -l /target/boot/efi/EFI/debian/
-rwx--1 root root   110 Jun 20 14:45 BOOTAA64.CSV
-rwx--1 root root819152 Jun 20 14:45 fbaa64.efi
-rwx--1 root root   126 Jun 20 14:45 grub.cfg
-rwx--1 root root   1799536 Jun 20 14:45 grubaa64.efi
-rwx--1 root root884952 Jun 20 14:45 mmaa64.efi
-rwx--1 root root918872 Jun 20 14:45 shimaa64.efi
~ #

But 'grub.cfg' in /target/boot/grub/ directory was not created:

~ # ls -l /target/boot/grub/
drwxr-xr-x2 root root 12288 Jun 20 14:45 arm64-efi
drwxr-xr-x2 root root  4096 Jun 20 14:45 fonts
-rw-r--r--1 root root  1024 Jun 20 14:45 grubenv
-rw-r--r--1 root root   2395475 Jun 20 14:44 unicode.pf2

I chrooted to /target and started 'update-grub' by hand to create config
file:

~ # chroot /target/
# update-grub
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-5.6.0-2-arm64
Found initrd image: /boot/initrd.img-5.6.0-2-arm64
done

Then I went back to D-I and selected 'continue without boot loader'
option.

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

Kernel: Linux 5.6.13-300.fc32.x86_64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Bug#929040: ITP: tty-solitaire -- klondike solitaire game for text terminal

[Marcin Owsiany]

close 929040
thanks

After a reconsideration I decided to not package this program after all. In
the year that passed since I filed this ITP it turned I keep finding myself
having less and less free time. I also don't really play solitaire and to
be a good maintainer one needs to use the software regularly. Finally, lack
of pings shows that it is not an eagerly awaited package.

Luckily upstream recently fixed
https://github.com/mpereira/tty-solitaire/issues/14 so of anyone else is
inclined to package it, they should have an easier time doing so.

Marcin

Bug#961637: bambam should not apply Caps-Lock or Num-Lock conditions upon exit.

[Marcin Owsiany]

retitle 961637 restore Caps-Lock or Num-Lock conditions upon exit
tag 961637 + upstream help newcomer
thanks

I don't think CTRL+S/scroll lock apply to bambam as such, because it's not
a terminal application.
However I agree it would be nice to restore prior condition on exit.

Bug#961590: Include drm modules in non-gtk arm64 cdrom initrds

[Marcin Juszkiewicz]

W dniu 26.05.2020 o 20:33, Alper Nebi Yasak pisze:
> Control: retitle -1 Include drm modules in non-gtk arm64 cdrom initrds

>> And that's plain wrong.
>>
>> I want to run D-I on my monitor. Nevermind is it text mode one or gtk
>> one. My board does not require serial console to boot as I have
>> graphical output in U-Boot and can control it using USB keyboard.
> 
> I agree they should be included, so I'm changing bug metadata to that 
> (hopefully correctly).

Thanks!

Bug#961590: d-i: add 'panfrost' to 'fb-modules' so graphical installer can be used

[Marcin Juszkiewicz]

W dniu 26.05.2020 o 19:25, Alper Nebi Yasak pisze:
> On 26/05/2020 20:09, Marcin Juszkiewicz wrote:
>> RockPro64 does not enable screen at all. And there are no DRM
>> modules in netinstall image [1]:
>> 
>> ~ # cd /lib/modules/5.6.0-1-arm64/ /lib/modules/5.6.0-1-arm64 #
>> find . -name *drm* /lib/modules/5.6.0-1-arm64 #
>> 
>> 1.
>> https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/arm64/iso-cd/debian-testing-arm64-netinst.iso
>
>> 
> There are two initrds in that iso, 'install.a64/initrd.gz' doesn't
> have drm modules, but the 'install.a64/gtk/initrd.gz' one has them.
> Can you try booting the gtk one? If you boot to GRUB, 'Graphical
> Install' should be using that.

And that's plain wrong.

I want to run D-I on my monitor. Nevermind is it text mode one or gtk
one. My board does not require serial console to boot as I have
graphical output in U-Boot and can control it using USB keyboard.

And I prefer text mode D-I over gtk one.

> However, that image is currently broken due to a kernel version
> mismatch and won't actually install, try the weekly build instead:
> 
> https://cdimage.debian.org/cdimage/weekly-builds/arm64/iso-cd/debian-testing-arm64-netinst.iso

Thanks. Works like a charm.

Bug#961590: d-i: add 'panfrost' to 'fb-modules' so graphical installer can be used

[Marcin Juszkiewicz]

W dniu 26.05.2020 o 16:41, Alper Nebi Yasak pisze:
> On 26/05/2020 15:03, Marcin Juszkiewicz wrote:
>> Devices with Mali gpu can use 'panfrost' driver to provide working
>> framebuffer. And then Debian installer can be run on screen instead of
>> serial console.
>>
>> But 'panfrost' module is not available when d-i starts ;(
>>
>> So please include 'panfrost' in 'fb-modules' udeb.
> 
> Panfrost shouldn't be necessary for a working framebuffer. On my
> rk3399-gru-kevin, rockchipdrmfb handles that and d-i runs on the
> screen just fine.
> 
> Which device are you having this issue with?

RockPro64 does not enable screen at all. And there are no DRM modules in
netinstall image [1]:

~ # cd /lib/modules/5.6.0-1-arm64/
/lib/modules/5.6.0-1-arm64 # find . -name *drm*
/lib/modules/5.6.0-1-arm64 # 

1. 
https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/arm64/iso-cd/debian-testing-arm64-netinst.iso

Bug#961590: d-i: add 'panfrost' to 'fb-modules' so graphical installer can be used

[Marcin Juszkiewicz]

Package: linux
Severity: important
Tags: d-i

Devices with Mali gpu can use 'panfrost' driver to provide working
framebuffer. And then Debian installer can be run on screen instead of
serial console.

But 'panfrost' module is not available when d-i starts ;(

So please include 'panfrost' in 'fb-modules' udeb.

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

Kernel: Linux 5.6.13-300.fc32.x86_64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Bug#960924: librdkafka: Backport 1.4.2 to buster

[Marcin Juszkiewicz]

Source: librdkafka
Version: 1.4.2-1
Severity: important

I work on getting OpenStack working on AArch64 (arm64) architecture.
Using Debian 'buster' as main development platform.

The problem is "confluent-kafka" Python package. For x86 arch it is easy
as wheel is provided on Pypi.org website. But on other architectures we
need to build it. And it requires librdkafka development headers in
version newer than one in Buster:

building 'confluent_kafka.cimpl' extension  

 [78/1959]
creating build/temp.linux-aarch64-3.6
creating build/temp.linux-aarch64-3.6/tmp
creating build/temp.linux-aarch64-3.6/tmp/pip-build-b71a1ssk
creating build/temp.linux-aarch64-3.6/tmp/pip-build-b71a1ssk/confluent-kafka
creating 
build/temp.linux-aarch64-3.6/tmp/pip-build-b71a1ssk/confluent-kafka/confluent_kafka
creating 
build/temp.linux-aarch64-3.6/tmp/pip-build-b71a1ssk/confluent-kafka/confluent_kafka/src
aarch64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -g 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/python3.6m -c 
/tmp/pip-build-b71a1ssk/confluent
ka/confluent_kafka/src/confluent_kafka.c -o 
build/temp.linux-aarch64-3.6/tmp/pip-build-b71a1ssk/confluent-kafka/confluent_kafka/src/confluent_kafka.o
In file included from 
/tmp/pip-build-b71a1ssk/confluent-kafka/confluent_kafka/src/confluent_kafka.c:17:0:
/tmp/pip-build-b71a1ssk/confluent-kafka/confluent_kafka/src/confluent_kafka.h:65:2:
 error: #error "confluent-kafka-python requires librdkafka v1.4.0 or later. 
Install the latest version of librdkafka from the Confluent rep
ories, see http://docs.confluent.io/current/installation.html;
 #error "confluent-kafka-python requires librdkafka v1.4.0 or later. Install 
the latest version of librdkafka from the Confluent repositories, see 
http://docs.confluent.io/current/installation.html;
  ^
In file included from 
/tmp/pip-build-b71a1ssk/confluent-kafka/confluent_kafka/src/confluent_kafka.c:17:0:


1.4.2-1 from Debian 'testing' builds fine in 'buster' so maybe it would
be possible to get it as official backport?

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

Kernel: Linux 5.6.12-300.fc32.x86_64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Bug#954849: libreoffice: crash after update

[Marcin Krawczyk]

Hi,

When I recreate the yesterday I remember that first when I opened a 
document  I saw a graphical interface without any icons and menus. I 
opened calc and I was able to make some calculations but no menus and no 
icons appear (bars existed and I can see menus of these bars). After 
some runs, LibreOffice doesn't opened just show start banner and 
progress bar is going to end. At the console, I get a message about LLVM.
 I think that some files are corrupted. Files responsible for 
displaying GUI. I don't know why it's reproducible after reinstalling 
LibreOffice (with purge option and installation packages from official 
site too and purge it more time) and a gnome with downgrading to 
testing. Maybe a Glibc library is to new for it. Or other libraries or 
settings responsible to display GUI.


When You can tell me what I can check more, I will be grateful. I'm a 
Debian user for nearly 18 years, I never had such problems. On Sid, I 
work for several years too.


When You ask for alien packages. Yes, I have some of it eg. Rstudio, the 
gdmsetup package I wanted to use to personalize my GDM but it fails and 
I uninstall it. Before yesterday's crash, everything was worked fine.


This version of Debian is a half year old on my laptop dell precision 
7530. I'm afraid after yesterday's partial reinstallation of the system 
the solution is a full reinstalling the system. So I need to find 1TB to 
save my home folder.


Regards and thank You for help
Marcin Krawczyk

On 24.03.2020 22:20, Rene Engelhard wrote:

Hi,

On Tue, Mar 24, 2020 at 10:08:03PM +0100, Marcin Krawczyk wrote:

: CommandLine Error: Option 'limited-coverage-experimental' registered more
than once!
LLVM ERROR: inconsistency in registered CommandLine options

Thq question still is what involves some CommandLine thingy of LLVM
here.


Start-Date: 2020-03-23  21:38:19
Commandline: apt install ./gdm3setup-utils-20140306-1.deb
Requested-By: marcin (1000)
Install: gdm3setup-utils:amd64 (20140306-1)
End-Date: 2020-03-23  21:38:20

Are you installing random package from somewhere?


LLVM ERROR: inconsistency in registered CommandLine options

LO does not use LLVM. So what are you using which is and throws this
error?

There is just xterm, but console doesn't matter
Only libreoffice crashes and I don't know why all rest apps works fine

I was more aiming at some tool using libreoffice, extension,  Or
some library from Debian replaced why whatever you installed from
somewhere


Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE

what that means

Oh my..

... or some proprietary X driver or some else proprietary stuff.

Regards,

Rene

Bug#954849: libreoffice: crash after update

[Marcin Krawczyk]

Hi

Thank You for reaction.

My answers bellow.

Little update, I purge libreoffice, change my source.apt to testing, 
uninstall gnome, python3 etc... then I install testing with libreoffice. 
Unfortunately error is still, after first run libreoffice show banner 
sometimes show it twice, new user doesn't help, remove local files 
doesn't help. If I can check something I can, please send where to look 
for it.
Only libreoffice --version is finished OK. Rest close and invoked in 
console send error


: CommandLine Error: Option 'limited-coverage-experimental' registered more
than once!
LLVM ERROR: inconsistency in registered CommandLine options


On 24.03.2020 16:59, Rene Engelhard wrote:

tag 954849 + moreinfo
tag 954849 + unreproducible
thanks

Hi,

On Tue, Mar 24, 2020 at 02:06:52PM +0100, Marcin Krawczyk wrote:

* What led up to the situation?
After night upgrade libreoffice crash when is opened

Which packages did get upgraded?

There is my /var/log/apt/history

Start-Date: 2020-03-23  00:45:49
Requested-By: marcin (1000)
Install: bind9-dnsutils:amd64 (1:9.16.1-2, automatic), 
libprotobuf-lite22:amd64 (3.11.4-2, automatic), libprotobuf22:amd64 
(3.11.4-2, automatic), libgeos-3.8.1:amd64 (3.8.1-1, automatic), 
bind9-libs:amd64 (1:9.16.1-2, automatic)
Upgrade: vlc-plugin-video-output:amd64 (3.0.8-4, 3.0.8-4+b1), 
python3-doc:amd64 (3.8.2-1, 3.8.2-2), libcom-err2:amd64 (1.45.5-2, 
1.45.6-1), libcom-err2:i386 (1.45.5-2, 1.45.6-1), 
libnet-ssleay-perl:amd64 (1.88-2, 1.88-3), gcc-9-base:amd64 (9.3.0-5, 
9.3.0-6), gcc-9-base:i386 (9.3.0-5, 9.3.0-6), lib32stdc++6:amd64 
(10-20200312-2, 10-20200321-1), libgeos-c1v5:amd64 (3.8.0-1, 3.8.1-1), 
gcc-10-base:amd64 (10-20200312-2, 10-20200321-1), gcc-10-base:i386 
(10-20200312-2, 10-20200321-1), r-cran-diffobj:amd64 (0.2.3-1, 0.2.4-1), 
libgeos-dev:amd64 (3.8.0-1, 3.8.1-1), libobjc4:amd64 (10-20200312-2, 
10-20200321-1), cpp-9:amd64 (9.3.0-5, 9.3.0-6), lib32gcc-s1:amd64 
(10-20200312-2, 10-20200321-1), bind9-host:amd64 (1:9.11.16+dfsg-2, 
1:9.16.1-2), e2fsprogs:amd64 (1.45.5-2, 1.45.6-1), libitm1:amd64 
(10-20200312-2, 10-20200321-1), dnsutils:amd64 (1:9.11.16+dfsg-2, 
1:9.16.1-2), libgfortran-9-dev:amd64 (9.3.0-5, 9.3.0-6), sudo:amd64 
(1.8.31-1, 1.8.31p1-1), gobjc-9:amd64 (9.3.0-5, 9.3.0-6), libvlc5:amd64 
(3.0.8-4, 3.0.8-4+b1), libasan5:amd64 (9.3.0-5, 9.3.0-6), 
libquadmath0:amd64 (10-20200312-2, 10-20200321-1), 
libisc-export1105:amd64 (1:9.11.16+dfsg-2, 1:9.11.17+dfsg-2), 
mozc-utils-gui:amd64 (2.23.2815.102+dfsg-8+b1, 2.23.2815.102+dfsg-8+b2), 
libvlccore9:amd64 (3.0.8-4, 3.0.8-4+b1), libvlc-bin:amd64 (3.0.8-4, 
3.0.8-4+b1), libstdc++-9-dev:amd64 (9.3.0-5, 9.3.0-6), libgcc1:amd64 
(1:10-20200312-2, 1:10-20200321-1), libss2:amd64 (1.45.5-2, 1.45.6-1), 
libext2fs2:amd64 (1.45.5-2, 1.45.6-1), lib32gcc1:amd64 (1:10-20200312-2, 
1:10-20200321-1), php-phpmyadmin-sql-parser:amd64 (4.4.0-1, 4.6.1-1), 
python3-ipykernel:amd64 (5.1.4-2, 5.2.0-1), libtsan0:amd64 
(10-20200312-2, 10-20200321-1), libubsan1:amd64 (10-20200312-2, 
10-20200321-1), pci.ids:amd64 (0.0~2020.02.22-1, 0.0~2020.03.20-1), 
g++-9:amd64 (9.3.0-5, 9.3.0-6), libgfortran5:amd64 (10-20200312-2, 
10-20200321-1), mozc-server:amd64 (2.23.2815.102+dfsg-8+b1, 
2.23.2815.102+dfsg-8+b2), gcc-9:amd64 (9.3.0-5, 9.3.0-6), 
libobjc-9-dev:amd64 (9.3.0-5, 9.3.0-6), libprotobuf-c1:amd64 (1.3.3-1, 
1.3.3-1+b1), gfortran-9:amd64 (9.3.0-5, 9.3.0-6), liblsan0:amd64 
(10-20200312-2, 10-20200321-1), libgomp1:amd64 (10-20200312-2, 
10-20200321-1), libgomp1:i386 (10-20200312-2, 10-20200321-1), zsh:amd64 
(5.8-3, 5.8-4), libtss2-esys0:amd64 (2.3.3-1, 2.4.0-1), libgcc-s1:amd64 
(10-20200312-2, 10-20200321-1), libgcc-s1:i386 (10-20200312-2, 
10-20200321-1), libphonenumber7:amd64 (7.1.0-5+b4, 7.1.0-5+b5), 
uim-mozc:amd64 (2.23.2815.102+dfsg-8+b1, 2.23.2815.102+dfsg-8+b2), 
python-concurrent.futures:amd64 (3.3.0-3, 3.3.0-4), libatomic1:amd64 
(10-20200312-2, 10-20200321-1), libatomic1:i386 (10-20200312-2, 
10-20200321-1), zsh-common:amd64 (5.8-3, 5.8-4), logsave:amd64 
(1.45.5-2, 1.45.6-1), libcc1-0:amd64 (10-20200312-2, 10-20200321-1), 
vlc-plugin-base:amd64 (3.0.8-4, 3.0.8-4+b1), libstdc++6:amd64 
(10-20200312-2, 10-20200321-1), libstdc++6:i386 (10-20200312-2, 
10-20200321-1), libgcc-9-dev:amd64 (9.3.0-5, 9.3.0-6), aspell-ga:amd64 
(0.50-4-4.2, 0.50-4-5)
Remove: libisccfg163:amd64 (1:9.11.16+dfsg-2), libirs161:amd64 
(1:9.11.16+dfsg-2), libisc1105:amd64 (1:9.11.16+dfsg-2), 
libprotobuf-lite17:amd64 (3.6.1.3-2+b3), libboost-chrono1.67.0:amd64 
(1.67.0-17), liblwres161:amd64 (1:9.11.16+dfsg-2), 
libboost-atomic1.67.0:amd64 (1.67.0-17), libisccc161:amd64 
(1:9.11.16+dfsg-2), libbind9-161:amd64 (1:9.11.16+dfsg-2), 
libgeos-3.8.0:amd64 (3.8.0-1), libdns1109:amd64 (1:9.11.16+dfsg-2)

End-Date: 2020-03-23  00:46:35

Start-Date: 2020-03-23  00:53:00
Requested-By: marcin (1000)
Install: csh:amd64 (20110502-5)
End-Date: 2020-03-23  00:53:01

Start-Date: 2020-03-23  01:05:34
Requested-By: marcin (1000)
Install: ksh:amd64 (2020.0.0-5)
End

Bug#954849: libreoffice: crash after update

[Marcin Krawczyk]

Package: libreoffice
Version: 1:6.4.2-2
Severity: important

Dear Maintainer,

* What led up to the situation?
After night upgrade libreoffice crash when is opened

* What exactly did you do (or not do) that was effective (or ineffective)?
Ineffective: reinstalling, trying install older version, change Windowmanager
to other as Gnome

* What was the outcome of this action?

in console I get message:
: CommandLine Error: Option 'limited-coverage-experimental' registered more
than once!
LLVM ERROR: inconsistency in registered CommandLine options



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

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

Versions of packages libreoffice depends on:
ii  libreoffice-base1:6.4.2-2
ii  libreoffice-calc1:6.4.2-2
ii  libreoffice-core1:6.4.2-2
ii  libreoffice-draw1:6.4.2-2
ii  libreoffice-impress 1:6.4.2-2
ii  libreoffice-math1:6.4.2-2
ii  libreoffice-report-builder-bin  1:6.4.2-2
ii  libreoffice-writer  1:6.4.2-2
ii  python3-uno 1:6.4.2-2

Versions of packages libreoffice recommends:
ii  fonts-crosextra-caladea 20130214-2
ii  fonts-crosextra-carlito 20130920-1
ii  fonts-dejavu2.37-1
ii  fonts-liberation1:1.07.4-11
ii  fonts-liberation2   2.1.0-1
ii  fonts-linuxlibertine5.3.0-4
ii  fonts-noto-core 20200103-3
ii  fonts-noto-extra20200103-3
ii  fonts-noto-mono 20200103-3
ii  fonts-noto-ui-core  20200103-3
ii  fonts-sil-gentium-basic 1.102-1
ii  libreoffice-java-common 1:6.4.2-2
ii  libreoffice-nlpsolver   0.9+LibO6.4.2-2
ii  libreoffice-report-builder  1:6.4.2-2
ii  libreoffice-script-provider-bsh 1:6.4.2-2
ii  libreoffice-script-provider-js  1:6.4.2-2
ii  libreoffice-script-provider-python  1:6.4.2-2
ii  libreoffice-sdbc-mysql  1:6.4.2-2
ii  libreoffice-sdbc-postgresql 1:6.4.2-2
ii  libreoffice-wiki-publisher  1.2.0+LibO6.4.2-2

Versions of packages libreoffice suggests:
ii  cups-bsd2.3.1-11
ii  default-jre [java8-runtime] 2:1.11-72
ii  firefox-esr 68.6.0esr-1
ii  ghostscript 9.52~dfsg-1
pn  gnupg   
pn  gpa 
ii  gstreamer1.0-libav  1.16.2-2
ii  gstreamer1.0-plugins-bad1.16.2-2.1
ii  gstreamer1.0-plugins-base   1.16.2-2
ii  gstreamer1.0-plugins-good   1.16.2-2
ii  gstreamer1.0-plugins-ugly   1.16.2-2
ii  hunspell-ar [hunspell-dictionary]   3.2-1.1
ii  hunspell-be [hunspell-dictionary]   0.53-3
ii  hunspell-bg [hunspell-dictionary]   1:6.4.0~rc2-1
ii  hunspell-bs [hunspell-dictionary]   1:6.4.0~rc2-1
ii  hunspell-ca [hunspell-dictionary]   3.0.4+repack1-1
ii  hunspell-cs [hunspell-dictionary]   1:6.4.0~rc2-1
ii  hunspell-da [hunspell-dictionary]   1:6.4.0~rc2-1
ii  hunspell-de-at [hunspell-dictionary]20161207-7
ii  hunspell-de-ch [hunspell-dictionary]20161207-7
ii  hunspell-de-de [hunspell-dictionary]20161207-7
ii  hunspell-en-gb [hunspell-dictionary]1:6.4.0~rc2-1
ii  hunspell-en-us [hunspell-dictionary]1:2018.04.16-1
ii  hunspell-eu [hunspell-dictionary]   0.5.20151110-5
ii  hunspell-fr-classical [hunspell-dictionary] 1:6.4.1-1
ii  hunspell-gl [hunspell-dictionary]   1:6.4.0~rc2-1
ii  hunspell-gu [hunspell-dictionary]   1:6.4.0~rc2-1
ii  hunspell-hi [hunspell-dictionary]   1:6.4.0~rc2-1
ii  hunspell-hr [hunspell-dictionary]   1:6.4.0~rc2-1
ii  hunspell-hu [hunspell-dictionary]   1:6.4.0~rc2-1
ii  hunspell-id [hunspell-dictionary]   1:6.4.0~rc2-1
ii  hunspell-is [hunspell-dictionary]   1:6.4.0~rc2-1
ii  hunspell-it [hunspell-dictionary]   1:6.4.0~rc2-1
ii  hunspell-kk [myspell-dictionary]1.1-2
ii  hunspell-kmr 

Bug#951680: inetutils-inetd

[Marcin Sacha]

Package: inetutils-inetd

Version: 2:1.9.4-7

 

Option -p do not work - pidfile is not created. Pidfile is created only,
when option -p is not present.

 

Environment:

Debian GNU/Linux 10 (buster)

Architecture: i386

libc6: 2.28-10

kernel: 4.19.98-1

 

MJS

 

Bug#950995: [Pkg-libvirt-maintainers] Bug#950995: [arm64] virNetDevGetPhysicalFunction:1391 : internal error: The PF device for VF eth1 has no network device name

[Marcin Juszkiewicz]

W dniu 09.02.2020 o 14:55, Guido Günther pisze:
> Thanks for digging out the patches.  Marking as fixed in newer versions
> then. We might want to fold this into a point release at some point.
> Cheers,
>  -- Guido

Any plans for 5.6.0 backport maybe?

Bug#950995: [arm64] virNetDevGetPhysicalFunction:1391 : internal error: The PF device for VF eth1 has no network device name

[Marcin Juszkiewicz]

Source: libvirt
Version: 5.0.0-4
Severity: normal

On AArch64 systems with Cavium ThunderX cpus libvirt refuses to handle
on board network cards:

2018-04-30 15:50:09.053+: 5069: info : hostname: uk-dc-cavium-01
2018-04-30 15:50:09.249+: 5069: error : virNetDevGetPhysicalFunction:1391 : 
internal error: The PF device for VF eth0 has no network device name

https://bugs.linaro.org/show_bug.cgi?id=3778 has more details.

Fixes were merged into 5.1.0 upstream release:

>From 6452e2f5e1837bd753ee465e6607ed3c4f62b815 Mon Sep 17 00:00:00 2001
From: Radoslaw Biernacki 
Date: Tue, 22 Jan 2019 12:26:12 -0700
Subject: [PATCH 1/4] util: fixing wrong assumption that PF has to have netdev 
assigned


>From 10bca495e040ef834760a244a31f8b87391c2378 Mon Sep 17 00:00:00 2001
From: Radoslaw Biernacki 
Date: Tue, 22 Jan 2019 12:26:13 -0700
Subject: [PATCH 2/4] util: Code simplification


>From 8fac64db5e7941efb820626f0043f5e0a31c79ee Mon Sep 17 00:00:00 2001
From: Radoslaw Biernacki 
Date: Tue, 22 Jan 2019 12:26:14 -0700
Subject: [PATCH 3/4] util: Fix for NULL dereference


>From 04983c3c6a821f67994b1c65d4d6175f3ac49d69 Mon Sep 17 00:00:00 2001
From: Radoslaw Biernacki 
Date: Tue, 22 Jan 2019 12:26:15 -0700
Subject: [PATCH 4/4] util: Fixing invalid error checking from virPCIGetNetname()


Those patches apply to 5.0.0-4 Debian package without any problems. 
I have patched version in my repository [1].

1. http://obs.linaro.org/home:/marcin.juszkiewicz/debian-buster/


-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.4.0-1-arm64 (SMP w/46 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

>From 6452e2f5e1837bd753ee465e6607ed3c4f62b815 Mon Sep 17 00:00:00 2001
From: Radoslaw Biernacki 
Date: Tue, 22 Jan 2019 12:26:12 -0700
Subject: [PATCH 1/4] util: fixing wrong assumption that PF has to have netdev
 assigned

libvirt wrongly assumes that VF netdev has to have the
netdev assigned to PF. There is no such requirement in SRIOV standard.
This patch change the virNetDevSwitchdevFeature() function to deal
with SRIOV devices which does not have netdev on PF. Also corrects
one comment about PF netdev assumption.

One example of such devices is ThunderX VNIC.
By applying this change, VF device is used for virNetlinkCommand() as
it is the only netdev assigned to VNIC.

Signed-off-by: Radoslaw Biernacki 
Signed-off-by: dann frazier 
Signed-off-by: Michal Privoznik 
---
 src/util/virnetdev.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

--- a/src/util/virnetdev.c
+++ b/src/util/virnetdev.c
@@ -1355,9 +1355,8 @@
 }
 
 if (!*pfname) {
-/* this shouldn't be possible. A VF can't exist unless its
- * PF device is bound to a network driver
- */
+/* The SRIOV standard does not require VF netdevs to have
+ * the netdev assigned to a PF. */
 virReportError(VIR_ERR_INTERNAL_ERROR,
_("The PF device for VF %s has no network device name"),
ifname);
@@ -3178,8 +3177,12 @@
 if ((is_vf = virNetDevIsVirtualFunction(ifname)) < 0)
 return ret;
 
-if (is_vf == 1 && virNetDevGetPhysicalFunction(ifname, ) < 0)
-goto cleanup;
+if (is_vf == 1) {
+/* Ignore error if PF does not have netdev assigned.
+ * In that case pfname == NULL. */
+if (virNetDevGetPhysicalFunction(ifname, ) < 0)
+virResetLastError();
+}
 
 pci_device_ptr = pfname ? virNetDevGetPCIDevice(pfname) :
   virNetDevGetPCIDevice(ifname);

>From 10bca495e040ef834760a244a31f8b87391c2378 Mon Sep 17 00:00:00 2001
From: Radoslaw Biernacki 
Date: Tue, 22 Jan 2019 12:26:13 -0700
Subject: [PATCH 2/4] util: Code simplification

Removing redundant sections of the code

Signed-off-by: Radoslaw Biernacki 
Signed-off-by: dann frazier 
Signed-off-by: Michal Privoznik 
---
 src/util/virnetdev.c | 33 ++---
 1 file changed, 6 insertions(+), 27 deletions(-)

--- a/src/util/virnetdev.c
+++ b/src/util/virnetdev.c
@@ -1443,29 +1443,20 @@
 virNetDevGetVirtualFunctionInfo(const char *vfname, char **pfname,
 int *vf)
 {
-char *pf_sysfs_path = NULL, *vf_sysfs_path = NULL;
 int ret = -1;
 
 *pfname = NULL;
 
 if (virNetDevGetPhysicalFunction(vfname, pfname) < 0)
-return ret;
-
-if (virNetDevSysfsFile(_sysfs_path, *pfname, "device") < 0)
-goto cleanup;
+return -1;
 
-if (virNetDevSysfsFile(_sysfs_path, vfname, "device") < 0)
+if (virNetDevGetVirtualFunctionIndex(*pfname, vfname, vf) < 0)
 goto cleanup;
 
-ret = virPCIGetVirtualFunctionIndex(pf_sysfs_path, vf_sysfs_path, vf);
-
+ret = 0;
  

Bug#947661: optirun fails

[Marcin Szamotulski]

Package: optirun
Version: bumblebee
Severity: normal
Tags: patch

Dear Maintainer,

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

   * What led up to the situation?
I upgraded from debian-stable to sid.

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

I run `optirun glxinfo`


   * What was the outcome of this action?

The outcome is:
```
optirun glxinfo
primus: fatal: failed to load any of the libraries: /usr/lib/x86_64-linux-
gnu/nvidia/libGL.so.1:/usr/lib/i386-linux-
gnu/nvidia/libGL.so.1:/usr/lib/nvidia/libGL.so.1
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1: cannot open shared object file: No
such file or directory
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1: cannot open shared object file: No
such file or directory
/usr/lib/nvidia/libGL.so.1: cannot open shared object file: No such file or
directory

```


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



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

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

Bug#946193: Refuses to use profiles from stretch after upgrade to buster 68.2.0esr-1~deb9u2 -> 68.2.0esr-1~deb10u1

[Marcin Owsiany]

Package: firefox-esr
Version: 68.2.0esr-1~deb10u1
Severity: important

After upgrade from stretch to buster and starting firefox-esr, I was
greeted with a dialog box saying "You've launched an older version of
Firefox", refusing to use the existing profile.

Turns out that as a result of using the latest stretch version, the file
.mozilla/firefox/d0e3mzzp.default/compatibility.ini contained:

[Compatibility]
LastVersion=68.2.0_20191106112211/20191106112211

After upgrade to buster, a newly created profile contained:

LastVersion=68.2.0_20191022215001/20191022215001


I was able to work around the issue by hand-editing the file in the
older profile and pasting the newer version string, however:
- not all users might be savvy enough to perfom this trick
- there is still a chance I might face corruption due to using a profile
  creaed by the older version

It would be great if a version equivalent to the stretch one could be
uploaded to buster, to prevent this issue.


-- Package-specific info:


-- Addons package information

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

Kernel: Linux 5.3.0-0.bpo.2-amd64 (SMP w/8 CPU cores)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), 
LANGUAGE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firefox-esr depends on:
ii  debianutils   4.8.6.1
ii  fontconfig2.13.1-2
ii  libasound21.1.8-1
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-10
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.16-1
ii  libdbus-glib-1-2  0.110-4
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-9
ii  libfontconfig12.13.1-2
ii  libfreetype6  2.9.1-3+deb10u1
ii  libgcc1   1:8.3.0-6
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.58.3-2+deb10u2
ii  libgtk-3-03.24.5-1
ii  libjsoncpp1   1.7.4-3
ii  libpango-1.0-01.42.4-7~deb10u1
ii  libstartup-notification0  0.12-6
ii  libstdc++68.3.0-6
ii  libvpx5   1.7.0-3+deb10u1
ii  libx11-6  2:1.6.7-1
ii  libx11-xcb1   2:1.6.7-1
ii  libxcb-shm0   1.13.1-2
ii  libxcb1   1.13.1-2
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-3+b3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1+b3
ii  procps2:3.3.15-2
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages firefox-esr recommends:
ii  libavcodec58  7:4.1.4-1~deb10u1

Versions of packages firefox-esr suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.17-3
ii  libgtk2.0-02.24.32-3
ii  pulseaudio 12.2-4+deb10u1

-- no debconf information

Bug#940084: RM: euca2ools -- ROM; It's python2 without python3 support

[Marcin Kulisz]

Package: ftp.debian.org
Severity: normal

As per subject please remove this package from the archive, just to keep it
clear, upstream is not showing any movement towards py3 support, thus Cloud Team
agreed to remove it fromt the archive.
Thanks.

Bug#929040: Blocked on an upstream issue

[Marcin Owsiany]

FTR, the upload is blocked on
https://github.com/mpereira/tty-solitaire/issues/14

Bug#939485: RM: bootstrap-vz -- ROM; It's python2 only

[Marcin Kulisz]

Package: ftp.debian.org
Severity: normal


It's python2 only, no longer maintained upstream and Cloud Team is also not
interested in maintaining it anylonger.

Bug#939470: haproxy: Haproxy fails to install if there is 'haproxy' user already in system

[Marcin Juszkiewicz]

Source: haproxy
Severity: normal

I am using Kolla to build container images with OpenStack components.
One of images contains haproxy. And it fails to build.

Part of build is creation of users with fixed UID/GID values. Which
works fine for most situations as packages usually are fine with user
accounts already existing. But not haproxy ;(

root@2a75f0b07b80:/# id haproxy 

   
uid=42454(haproxy) gid=42454(haproxy) groups=42454(haproxy)

root@2a75f0b07b80:/# apt install haproxy -y 

   
Reading package lists... Done
Building dependency tree
Reading state information... Done
haproxy is already the newest version (1.8.19-1).
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up haproxy (1.8.19-1) ...
adduser: The user `haproxy' already exists, but is not a system user. Exiting.
dpkg: error processing package haproxy (--configure):
 installed haproxy package post-installation script subprocess returned error 
exit status 1   
 
Errors were encountered while processing:
 haproxy
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@2a75f0b07b80:/#


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

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

Bug#926731: ITS: urlscan/0.9.2 - extract and browse email URLs

[Marcin Kulisz]

Package: urlscan
Version: 0.8.2-1
Followup-For: Bug #926731

Boruch are you still interested in maintaining this package?
If not I my intent is to salvage/adopt it in the next couple of weeks, so please
let me know asap if you're planning to do it.

Bug#936171: autorenamer: Python2 removal in sid/bullseye

[Marcin Owsiany]

FTR, I'm the upstream and plan to convert it to Python3, as long as needed
libraries exist.

Bug#934274: (no subject)

[Marcin Kulisz]

Tarjei, Noah

I think I managed to activate those 2 new regions, please give it a go and
shout if something is not working.

Bug#883003: (no subject)

[Marcin Kulisz]

Hi Guido,

I know it's late but I'm going to ask anyway.
Do you still want this to be backported to Stretch when it's already oldstable?

This issue has been sorted in 1.3.0 which is in current stable, so if this is
something which will work for you then please feel free to close this bug
report.


signature.asc
Description: PGP signature

Bug#926731: (no subject)

[Marcin Kulisz]

If you're still interested in maintaining urlscan in Debian and are looking for
sponsor I think I can help with this, If you could also point me to from where I
could grab your packaging work, it'd be great.

I'm a bit busy lately and don't have much time but would like to see urlscan
better maintained so I'll try to help you with it.

Bug#929040: ITP: tty-solitaire -- klondike solitaire game for text terminal

[Marcin Owsiany]

Package: wnpp
Severity: wishlist
Owner: Marcin Owsiany 

* Package name: tty-solitaire
  Version : 1.1.1
  Upstream Author : Murilo Pereira 
* URL : https://github.com/mpereira/tty-solitaire
* License : MIT
  Programming Lang: C
  Description : klondike solitaire game for text terminal

  This game runs in any terminal with UTF-8 support.

Bug#928121: [i915] *ERROR* rcs0: reset request timeout; intel_do_flush_locked failed: Input/output error

[Marcin Owsiany]

Package: src:linux
Version: 4.19.16-1~bpo9+1
Severity: important

Every couple of weeks or so my laptop experiences some graphics-related crash.

As you can see from the log below, sometimes there is just a single "Resetting
rcs0 for hang on rcs0" from which it recovers, while at other times it is
followed by "reset request timeout", together with an X server crash.

At that point, systemd tries to restart the X server, but it never succeeds,
each time /usr/lib/gdm3/gdm-x-session reports: "intel_do_flush_locked failed: 
Input/output error".
The only thing that helps at that point is a reboot.

All I'm running is GNOME, Firefox, Google chrome and Zoom (a proprietary video
conferencing program, though during the last couple of crashes it was just
running in background, not really displaying anything).

A possibly important detail is that I have an external DELL U2717D monitor
attached over DisplayPort in addition to the built-in display.

This is a backport linux package, but apparently the next Debian release will
use basically the same kernel version. I'm a little worried this unhapiness
will continue for a while :-(

Please do let me know whether I can do anything to help debug this.


-- Package-specific info:
** Version:
Linux version 4.19.0-0.bpo.2-amd64 (debian-ker...@lists.debian.org) (gcc 
version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP Debian 4.19.16-1~bpo9+1 
(2019-02-07)

** Command line:
BOOT_IMAGE=/vmlinuz-4.19.0-0.bpo.2-amd64 root=/dev/mapper/beczulka--vg-root ro 
quiet

** Tainted: W (512)
 * Taint on warning.

** Kernel log: (zgrep 915 over the last few /var/log/kern.log*)
[4038641.201633] i915 :00:02.0: Resetting rcs0 for hang on rcs0
[4097895.262528] i915 :00:02.0: Resetting rcs0 for hang on rcs0
[4097895.263808] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request 
timeout
[4097895.263989] i915 :00:02.0: Resetting chip for hang on rcs0
[4097895.266296] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request 
timeout
[4097895.375626] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request 
timeout
[4097895.483621] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request 
timeout
[4097895.590309] i915 :00:02.0: Failed to reset chip
[4097895.591607] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request 
timeout
[   16.505146] i915 :00:02.0: enabling device (0006 -> 0007)
[   16.508667] i915 :00:02.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=io+mem:owns=mem
[   16.508708] i915 :00:02.0: firmware: failed to load 
i915/kbl_dmc_ver1_04.bin (-2)
[   16.508712] i915 :00:02.0: Direct firmware load for 
i915/kbl_dmc_ver1_04.bin failed with error -2
[   16.508713] i915 :00:02.0: Failed to load DMC firmware 
i915/kbl_dmc_ver1_04.bin. Disabling runtime power management.
[   16.508714] i915 :00:02.0: DMC firmware homepage: 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915
[   16.896879] [drm] Initialized i915 1.6.0 20180719 for :00:02.0 on minor 0
[   16.912106] snd_hda_intel :00:1f.3: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[   18.499873] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[113350.724745] i915 :00:02.0: Resetting rcs0 for hang on rcs0
[113796.730317] i915 :00:02.0: Resetting rcs0 for hang on rcs0
[116658.722200] i915 :00:02.0: Resetting rcs0 for hang on rcs0
[180404.755657] i915 :00:02.0: Resetting rcs0 for hang on rcs0
[180404.757430] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request 
timeout
[180404.757537] i915 :00:02.0: Resetting chip for hang on rcs0
[180404.761122] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request 
timeout
[180404.868367] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request 
timeout
[180404.976368] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request 
timeout
[180405.082559] i915 :00:02.0: Failed to reset chip
[180405.085348] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request 
timeout
[   21.419336] i915 :00:02.0: enabling device (0006 -> 0007)
[   21.432919] i915 :00:02.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=io+mem:owns=mem
[   21.432960] i915 :00:02.0: firmware: failed to load 
i915/kbl_dmc_ver1_04.bin (-2)
[   21.432966] i915 :00:02.0: Direct firmware load for 
i915/kbl_dmc_ver1_04.bin failed with error -2
[   21.432968] i915 :00:02.0: Failed to load DMC firmware 
i915/kbl_dmc_ver1_04.bin. Disabling runtime power management.
[   21.432969] i915 :00:02.0: DMC firmware homepage: 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915
[   21.745713] [drm] Initialized i915 1.6.0 20180719 for :00:02.0 on minor 0
[   21.749585] snd_hda_intel :00:1f.3: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[   23.362631] i915 :00:02.0: fb0: inteldrmfb frame buffer device

** Model information
sys_vendor: LENOVO
product_name: 20L9001TUS
product_version: 

Bug#925143: ceph-common drags Python 2.7 into system

[Marcin Juszkiewicz]

Package: ceph-common
Version: 12.2.11+dfsg1-2
Severity: normal

Dear Maintainer,

I am working on moving container images built with OpenStack Kolla to
use Python 3 where possible.

Got images building without Python 2.7 but with one exception: all
images involving Ceph (directly or via qemu/libvirt) get Python 2.7
installed.

Checked and it looks that 'ceph-common' is to blame:

$ aptitude why python2.7
i   ceph-common Depends python-rbd (= 12.2.11+dfsg1-2)
i A python-rbd  Depends python (>= 2.7~)  
i A python  Depends python2.7 (>= 2.7.15-1~)  


Are there plans to change it?


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

Kernel: Linux 3.10.0-957.5.1.el7.x86_64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages ceph-common depends on:
ii  libbabeltrace1  1.5.6-2
ii  libblkid1   2.33.1-0.1
ii  libboost-iostreams1.67.01.67.0-13
ii  libboost-program-options1.67.0  1.67.0-13
ii  libboost-regex1.67.01.67.0-13
ii  libboost-system1.67.0   1.67.0-13
ii  libboost-thread1.67.0   1.67.0-13
ii  libc6   2.28-7
ii  libcurl3-gnutls 7.64.0-1
ii  libexpat1   2.2.6-1
ii  libgcc1 1:8.2.0-21
ii  libgoogle-perftools42.7-1
ii  libibverbs1 22.1-1
ii  libkeyutils11.6-6
ii  libldap-2.4-2   2.4.47+dfsg-3
ii  libnspr42:4.20-1
ii  libnss3 2:3.42.1-1
ii  librados2   12.2.11+dfsg1-2
ii  libradosstriper112.2.11+dfsg1-2
ii  librbd1 12.2.11+dfsg1-2
ii  libsnappy1v51.1.7-1
ii  libstdc++6  8.2.0-21
ii  libudev1240-6
ii  python  2.7.15-4
ii  python-cephfs   12.2.11+dfsg1-2
ii  python-prettytable  0.7.2-4
ii  python-rados12.2.11+dfsg1-2
ii  python-rbd  12.2.11+dfsg1-2
ii  python-requests 2.21.0-1
ii  python2.7   2.7.16~rc1-1
ii  python3 3.7.2-1
ii  python3-prettytable 0.7.2-4
ii  zlib1g  1:1.2.11.dfsg-1

ceph-common recommends no packages.

Versions of packages ceph-common suggests:
pn  ceph  
pn  ceph-mds  

-- no debconf information

Bug#838903: A note about switching to the new "Command" applet

[Marcin Owsiany]

FTR, I added a little note that might help anyone wanting to switch to the
"Command" applet from command-runner-applet:
https://github.com/porridge/command-runner-applet/blob/master/README#L15-L18

Bug#924691: unblock: potool/0.16-4

[Marcin Owsiany]

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

Please unblock package potool

I was not able to upload this update earlier in the freeze cycle, but I
think our users will be better served by having -4 in buster than -3:
- these are rather low risk changes,
- the added autopkgtests means we now actually check whether it does
  work,
- it's a leaf package, so no impact to other packages.

Summary of key changes between 0.16-3 and 0.16-4:
- add a missing depends on sensible-utils
- properly pass all hardening flags (by using a more recent DH compat
  level and dropping explicit *FLAGS variables from debian/rules)

While at it, I also:
- added DEP8 tests
- bumped standards-version
- moved Homepage field to where it belongs
- added vcs-* fields
- bumped copyright years

Src debdiff attached.

unblock potool/0.16-4
diff -Nru potool-0.16/debian/changelog potool-0.16/debian/changelog
--- potool-0.16/debian/changelog	2017-09-24 21:00:55.0 +0200
+++ potool-0.16/debian/changelog	2019-03-04 21:42:07.0 +0100
@@ -1,3 +1,14 @@
+potool (0.16-4) unstable; urgency=medium
+
+  * Bumped debhelper compat level to 9
+  * Bumped Standards-Version, no changes needed
+  * Added Vcs-* headers, moved the Homepage one to the top stanza
+  * Declared a dependency on sensible-utils
+  * Removed explicit setting of *FLAGS, as dh does this more correctly
+  * Enabled all hardening options
+
+ -- Marcin Owsiany   Mon, 04 Mar 2019 21:42:07 +0100
+
 potool (0.16-3) unstable; urgency=medium
 
   * Updated standards-version, no changes needed
diff -Nru potool-0.16/debian/compat potool-0.16/debian/compat
--- potool-0.16/debian/compat	2013-02-27 07:37:29.0 +0100
+++ potool-0.16/debian/compat	2019-03-04 20:13:06.0 +0100
@@ -1 +1 @@
-8
+9
diff -Nru potool-0.16/debian/control potool-0.16/debian/control
--- potool-0.16/debian/control	2017-09-24 21:00:48.0 +0200
+++ potool-0.16/debian/control	2019-03-04 21:42:07.0 +0100
@@ -2,14 +2,16 @@
 Section: utils
 Priority: optional
 Maintainer: Marcin Owsiany 
-Standards-Version: 4.1.0
-Build-Depends: libglib2.0-dev, bison, flex, debhelper (>= 8), rename
+Standards-Version: 4.3.0
+Build-Depends: libglib2.0-dev, bison, flex, debhelper (>> 9), rename
+Vcs-Git: https://github.com/porridge/potool -b debian
+Vcs-Browser: https://github.com/porridge/potool/tree/debian
+Homepage: http://marcin.owsiany.pl/potool-page
 
 Package: potool
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}, sensible-utils
 Breaks: poedit (<< 1.0.3-2)
-Homepage: http://marcin.owsiany.pl/potool-page
 Description: program to aid manipulation of gettext po files
  This package contains the filter program 'potool', as well
  as a few helper scripts:
diff -Nru potool-0.16/debian/copyright potool-0.16/debian/copyright
--- potool-0.16/debian/copyright	2013-02-27 07:37:29.0 +0100
+++ potool-0.16/debian/copyright	2019-03-04 21:15:59.0 +0100
@@ -11,7 +11,7 @@
 
 potool is a program aiding editing of po files
 Copyright (C) 1999-2000 Zbigniew Chyla 
-Copyright (C) 2000-2012 Marcin Owsiany 
+Copyright (C) 2000-2019 Marcin Owsiany 
 
 License information:
 
diff -Nru potool-0.16/debian/rules potool-0.16/debian/rules
--- potool-0.16/debian/rules	2013-02-27 07:37:29.0 +0100
+++ potool-0.16/debian/rules	2019-03-04 21:36:18.0 +0100
@@ -1,10 +1,8 @@
 #!/usr/bin/make -f
-# Copyright 2012 Marcin Owsiany 
+# Copyright 2012,2019 Marcin Owsiany 
 
 export DH_VERBOSE=1
-export CFLAGS   := $(shell dpkg-buildflags --get CFLAGS)
-export CPPFLAGS := $(shell dpkg-buildflags --get CPPFLAGS)
-export LDFLAGS  := $(shell dpkg-buildflags --get LDFLAGS)
+export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 %:
 	dh $@
 
diff -Nru potool-0.16/debian/tests/control potool-0.16/debian/tests/control
--- potool-0.16/debian/tests/control	1970-01-01 01:00:00.0 +0100
+++ potool-0.16/debian/tests/control	2019-03-04 21:13:41.0 +0100
@@ -0,0 +1,2 @@
+Test-Command: test $(potool -n ctxt -n str -n dcmt -n linf -s -fnt debian/tests/data/smoke-test-input.po) -eq 0
+Features: test-name=smoke
diff -Nru potool-0.16/debian/tests/data/smoke-test-input.po potool-0.16/debian/tests/data/smoke-test-input.po
--- potool-0.16/debian/tests/data/smoke-test-input.po	1970-01-01 01:00:00.0 +0100
+++ potool-0.16/debian/tests/data/smoke-test-input.po	2019-03-04 21:12:12.0 +0100
@@ -0,0 +1,25 @@
+# file comment
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: blah 0.0.1\n"
+"Language: pl\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"Plural-Forms: nplurals=3; plural=(n==1 ? 0 : n%10>=2 && n%10<=4 && (n%100<10 "
+"|| n%100>=20) ? 1 : 2);\n"
+
+#: src/simple.c:757
+msgid "one"
+msgstr "two"
+
+#: src/a.c:52 src/b.c:69
+#: src/c.c:305
+#, c-format
+msgid ""
+"fo%so \n"
+"\\bar"
+msgstr ""
+"blah\n"
+"\\boom%s"

Bug#920800: ValueError: could not convert string to float: '6.06 LTS'

[Marcin Juszkiewicz]

Package: lsb-release
Version: 10.2018112800
Severity: normal

Dear Maintainer,

* What led up to the situation?

At first this system was Ubuntu 13.04, then 13.10, 14.04 and 16.04
version. Yesterday I upgraded it to Debian 10 with just APT/Aptitude.

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

$ lsb_release -a

* What was the outcome of this action?

Traceback (most recent call last):
  File "/usr/bin/lsb_release", line 95, in 
main()
  File "/usr/bin/lsb_release", line 59, in main
distinfo = lsb_release.get_distro_information()
  File "/usr/lib/python3/dist-packages/lsb_release.py", line 356, in 
get_distro_information
distinfo = guess_debian_release()
  File "/usr/lib/python3/dist-packages/lsb_release.py", line 246, in 
guess_debian_release
get_distro_info(distinfo['ID'])
  File "/usr/lib/python3/dist-packages/lsb_release.py", line 48, in 
get_distro_info
RELEASES_ORDER.sort(key=lambda n: float(n[0]))
  File "/usr/lib/python3/dist-packages/lsb_release.py", line 48, in 
RELEASES_ORDER.sort(key=lambda n: float(n[0]))
ValueError: could not convert string to float: '6.06 LTS'

* What outcome did you expect instead?

Some sensible output.


-- Package-specific info:
lsb_release output
-*- -*- -*- -*- -*-
-*- -*- -*- -*- -*-
Apt policy
-*- -*- -*- -*- -*-
Package files:
 100 /var/lib/dpkg/status
 release a=now
 500 https://deb.debian.org/debian buster/main i386 Packages
 release o=Debian,a=testing,n=buster,l=Debian,c=main,b=i386
 origin deb.debian.org
 500 https://deb.debian.org/debian buster/main amd64 Packages
 release o=Debian,a=testing,n=buster,l=Debian,c=main,b=amd64
 origin deb.debian.org
Pinned packages:
-*- -*- -*- -*- -*-
   sources.list
-*- -*- -*- -*- -*-
-*- -*- -*- -*- -*-
 /etc/lsb_release
-*- -*- -*- -*- -*-
- none

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

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

Versions of packages lsb-release depends on:
ii  distro-info-data  0.39
ii  python3   3.7.2-1

Versions of packages lsb-release recommends:
ii  apt  1.8.0~beta1

Versions of packages lsb-release suggests:
pn  lsb  

-- debconf-show failed

Bug#864657: ca-certificates-java: Can we have fix for this in Stretch as well, please.

[Marcin Kulisz]

Package: ca-certificates-java
Followup-For: Bug #864657

Hi I just want to add that at the moment Stretch current stable has this broken
to the point that neither openjdk nor ca-certificates-java packages can be
installed making all java dependant apps useless.

It's due to ca-certificates-java dependencies be:
openjdk-7-jre-headless | java7-runtime-headless
and those packages are not available anymore in Stretch.

Instead only openjdk for java8 is available so please provide update to stable
fixing those dependencies by replacing:
openjdk-7-jre-headless | java7-runtime-headless
with
openjdk-8-jre-headless

Bug#920295: buku: No module named buku

[Marcin Kulisz]

Package: buku
Version: 4.1+ds-1
Severity: grave
Justification: renders package unusable

Looks like binary package doesn't contain required modules. When trying to run 
buku
following error pops up:

Traceback (most recent call last):
  File "/usr/bin/buku", line 11, in 
load_entry_point('buku==4.1', 'console_scripts', 'buku')()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 487, in 
load_entry_point
return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2728, 
in load_entry_point
return ep.load()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2346, 
in load
return self.resolve()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2352, 
in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
ModuleNotFoundError: No module named 'buku

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (100, 'unstable'), (10, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages buku depends on:
ii  python3   3.7.1-3
ii  python3-bs4   4.6.3-2
ii  python3-certifi   2018.8.24-1
ii  python3-cryptography  2.3-1
ii  python3-html5lib  1.0.1-1
ii  python3-urllib3   1.24-1

buku recommends no packages.

buku suggests no packages.

-- no debconf information