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

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

Dnia Tue, Feb 22, 2022 at 08:57:25AM +0100, Andreas Tille napisał(a):
> I had a look into this issue since a Debian Med package received a
> testing removal warning.  I can confirm the build fails with
> 
>Segmentation fault
> 
> in the build time test suite.

Just out of curiosity I ran the tests during build under GDB (simply
inserting "gdb --args" right before the "{interpreter}" in the
overrite_dh_auto_test rule in debian/rules).

It seems like the segfault is in the freetype library, when loading a font,
rather than in pygame (though I guess the root cause could be pygame passing
garbage to freetype? - I have zero knowledge about the API).

Cc-ing Hugh in case he can provide some hints about what might be going on here.

This does not change the fact that it would be great to move to pygame2 :-)

loading pygame.tests.freetype_test
loading pygame.tests.ftfont_test

Thread 1 "python3.10" received signal SIGSEGV, Segmentation fault.
0x7fde9aeb34e3 in FT_Done_Face (face=0x7fde96aa04d8) at 
./src/base/ftobjs.c:2836
2836./src/base/ftobjs.c: No such file or directory.
(gdb) bt full
#0  0x7fde9aeb34e3 in FT_Done_Face (face=0x7fde96aa04d8) at 
./src/base/ftobjs.c:2836
error = 35
driver = 
memory = 
node = 
#1  0x7fde9af11479 in ftc_face_node_done (ftcnode=0x1fce450, 
ftcmanager=) at ./src/cache/ftcmanag.c:272
node = 0x1fce450
manager = 
#2  0x7fde9af11872 in FTC_MruList_New (list=0x1ec9928, key=0x7fde970bb200, 
anode=anode@entry=0x7ffce3eb1bc0) at ./src/cache/ftcmru.c:281
error = 1
node = 0x1fce450
memory = 0x1e70c40
#3  0x7fde9af12bbf in FTC_Manager_LookupFace (manager=, 
face_id=face_id@entry=0x7fde970bb200, aface=aface@entry=0x7ffce3eb1be0) at 
./src/cache/ftcmanag.c:324
_pfirst = 
_compare = 0x7fde9af102d0 
_first = 
_node = 
error = 0
mrunode = 0x7fde9ca14638
#4  0x7fde982a5228 in _PGFT_GetFont (ft=ft@entry=0x20bc470, 
fontobj=fontobj@entry=0x7fde970bb1f0) at src_c/freetype/ft_wrap.c:321
error = 
font = 0x0
#5  0x7fde982a550c in init (ft=ft@entry=0x20bc470, 
fontobj=fontobj@entry=0x7fde970bb1f0) at src_c/freetype/ft_wrap.c:386
font = 
#6  0x7fde982a58be in _PGFT_TryLoadFont_Filename (ft=ft@entry=0x20bc470, 
fontobj=fontobj@entry=0x7fde970bb1f0, filename=, 
font_index=) at src_c/freetype/ft_wrap.c:442
filename_alloc = 
file_len = 
#7  0x7fde9829d3d0 in _ftfont_init (self=0x7fde970bb1f0, args=, kwds=) at src_c/_freetype.c:823
kwlist = {0x7fde982a7bb3 "file", 0x7fde982a7cca "size", 0x7fde982a75cc 
"font_index", 0x7fde982a777c "resolution", 0x7fde982a75d7 "ucs4", 0x0}
file = 0x7fde96f44d30
original_file = 0x7fde96f2a240
font_index = 0
face_size = {x = 1280, y = 0}
ucs4 = 0
resolution = 0
size = 0
height = 0
width = 0
x_ppem = 0
y_ppem = 0
rval = -1
source = 
ft = 0x20bc470
#8  0x00599823 in  ()
#9  0x00531efb in _PyObject_MakeTpCall ()
#10 0x0052c946 in _PyEval_EvalFrameDefault ()
#11 0x0053105a in _PyObject_FastCallDictTstate ()
#12 0x005446ab in  ()
#13 0x00532228 in  ()
#14 0x00549149 in PyObject_Call ()
#15 0x00528a93 in _PyEval_EvalFrameDefault ()
#16 0x0053b7ff in _PyFunction_Vectorcall ()
#17 0x00526ca7 in _PyEval_EvalFrameDefault ()
#18 0x0053b7ff in _PyFunction_Vectorcall ()
--Type  for more, q to quit, c to continue without paging--c
#19 0x00526ca7 in _PyEval_EvalFrameDefault ()
#20 0x0054884c in  ()
#21 0x00526aba in _PyEval_EvalFrameDefault ()
#22 0x0053b7ff in _PyFunction_Vectorcall ()
#23 0x00526ca7 in _PyEval_EvalFrameDefault ()
#24 0x0053b7ff in _PyFunction_Vectorcall ()
#25 0x0054893a in  ()
#26 0x00528a93 in _PyEval_EvalFrameDefault ()
#27 0x0053105a in _PyObject_FastCallDictTstate ()
#28 0x005459b9 in _PyObject_Call_Prepend ()
#29 0x005c2c33 in  ()
#30 0x00531efb in _PyObject_MakeTpCall ()
#31 0x0052b9ee in _PyEval_EvalFrameDefault ()
#32 0x0053b7ff in _PyFunction_Vectorcall ()
#33 0x0054893a in  ()
#34 0x00528a93 in _PyEval_EvalFrameDefault ()
#35 0x0053105a in _PyObject_FastCallDictTstate ()
#36 0x005459b9 in _PyObject_Call_Prepend ()
#37 0x005c2c33 in  ()
#38 0x00531efb in _PyObject_MakeTpCall ()
#39 0x0052b9ee in _PyEval_EvalFrameDefault ()
#40 0x0053b7ff in _PyFunction_Vectorcall ()
#41 0x0054893a in  ()
#42 0x00528a93 in _PyEval_EvalFrameDefault ()
#43 0x0053105a in _PyObject_FastCallDictTstate ()
#44 0x005459b9 in _PyObject_Call_Prepend ()
#45 0x005c2c33 in  ()
#46 0x00531efb in _PyObject_MakeTpCall ()
#47 0x0052b9ee in _PyEval_EvalFrameDefault ()
#48 

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

>  (and then after pressing Enter
> for my test user's password, I'm back to my unlocked session, equivalent
> to ). 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
> .
>

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#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#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#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#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#929040: Blocked on an upstream issue

[Marcin Owsiany]

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

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#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#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#917942: RM: bugsx/experimental -- ROM; dead upstream, unused, removed from sid

[Marcin Owsiany]

Package: ftp.debian.org
Severity: normal

This package was removed from sid in #905863, and I don't think it makes
sense to keep it in experimental either.

Marcin

Bug#909352: Was severity serious intended?

[Marcin Owsiany]

śr., 3 paź 2018, 21:49 użytkownik Adrian Bunk  napisał:

> On Wed, Oct 03, 2018 at 09:14:15PM +0200, Marcin Owsiany wrote:
> > Maybe I'm missing something, but what was the reason for filing #909352
> as
> > serious? Looking at #892016 it does not seem like it was the cause of the
> > segfault? Or was it?
>
> No.
>
> > If not, then getting rid of squeak-plugins-scratch sounds more like a
> > wishlist cleanup request to me than a serious bug.
>
> "package is completely useless" tends to be treated as RC.
>

I'm not sure I agree, since having reverse-dependencies seems to prove the
contrary.


> > All the more that
> > removing squeak-plugins-scratch from testing will cause scratch to be
> > removed, which is not a great outcome for those using it.
> >
> > Can you please provide a rationale or downgrade the severity?
>
> Downgrading the severity wouldn't make sense.
>
> If it is intentional that squeak-plugins-scratch provides only plugins
> that are already in squeak-vm, then this bug should be closed with an
> explanation why this is intentional.
>
> If it is not intentional that squeak-plugins-scratch provides only
> plugins that are already in squeak-vm and it is no longer needed,
> then fixing the two reverse dependencies is trivial.
>

Right, but it still requires work, which nobody volunteered to do so far,
so one could argue that a high severity is a disservice for our users in
the short term...

Anyway, thank you for the explanation.


Marcin

Bug#909352: Was severity serious intended?

[Marcin Owsiany]

Maybe I'm missing something, but what was the reason for filing #909352 as
serious? Looking at #892016 it does not seem like it was the cause of the
segfault? Or was it?

If not, then getting rid of squeak-plugins-scratch sounds more like a
wishlist cleanup request to me than a serious bug. All the more that
removing squeak-plugins-scratch from testing will cause scratch to be
removed, which is not a great outcome for those using it.

Can you please provide a rationale or downgrade the severity?

Marcin

Bug#894089: linux-image-4.9.0-6-amd64: Please fix max supported i915 screen (not display) resolution

[Marcin Owsiany]

Thank you for the contact, Ben. I will follow up with them.
FWIW, this patch does not even seem to work properly. While it does change
the max supported size reported by xrandr, trying to use the space just
results in an error.

Bug#894089: linux-image-4.9.0-6-amd64: Please fix max supported i915 screen (not display) resolution

[Marcin Owsiany]

Package: src:linux
Version: 4.9.82-1+deb9u3
Severity: normal

Dear Maintainer,

The i915 driver needs the following patch to allow the actually
supported X screen size of more recent chips. Currently one gets:

 $ xrandr --fb 8960x2880
 xrandr: screen cannot be larger than 8192x8192 (desired size 8960x2880)

diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 59231312c4e0..5e94163077e1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -16457,9 +16457,12 @@ int intel_modeset_init(struct drm_device *dev)
} else if (IS_GEN3(dev_priv)) {
dev->mode_config.max_width = 4096;
dev->mode_config.max_height = 4096;
-   } else {
+   } else if (IS_GEN4(dev_priv) || IS_GEN5(dev_priv) ||
IS_GEN6(dev_priv)) {
dev->mode_config.max_width = 8192;
dev->mode_config.max_height = 8192;
+   } else {
+   dev->mode_config.max_width = 16384;
+   dev->mode_config.max_height = 16384;
}

if (IS_845G(dev_priv) || IS_I865G(dev_priv)) {


Patch from
https://www.reddit.com/r/linux/comments/6bghzm/increasing_maximum_xorg_virtual_screen_resolution/

-- Package-specific info:
** Version:
Linux version 4.9.0-6-amd64 (debian-ker...@lists.debian.org) (gcc version
6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.82-1+deb9u3
(2018-03-02)

** Command line:
BOOT_IMAGE=/vmlinuz-4.9.0-6-amd64 root=/dev/mapper/beczulka--vg-root ro
quiet

** Tainted: O (4096)
 * Out-of-tree module has been loaded.

** Kernel log:
[248016.585805] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[248171.894464] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[248172.002961] wlp4s0: authenticate with f4:f2:6d:de:d5:18
[248172.013554] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 1/3)
[248172.085251] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 2/3)
[248172.147040] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 3/3)
[248172.209781] wlp4s0: authentication with f4:f2:6d:de:d5:18 timed out
[248197.525015] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[248197.550377] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[248395.942863] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[248396.023748] wlp4s0: authenticate with f4:f2:6d:de:d5:18
[248396.032143] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 1/3)
[248396.107564] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 2/3)
[248396.159524] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 3/3)
[248396.221695] wlp4s0: authentication with f4:f2:6d:de:d5:18 timed out
[248421.595868] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[248421.611726] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[248492.951789] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[248493.025828] wlp4s0: authenticate with f4:f2:6d:de:d5:18
[248493.036767] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 1/3)
[248493.111697] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 2/3)
[248493.177987] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 3/3)
[248493.231629] wlp4s0: authentication with f4:f2:6d:de:d5:18 timed out
[248518.392729] wlp4s0: authenticate with f4:f2:6d:de:d5:18
[248518.402419] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 1/3)
[248518.468811] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 2/3)
[248518.514630] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 3/3)
[248518.516782] wlp4s0: aborting authentication with f4:f2:6d:de:d5:18 by
local choice (Reason: 3=DEAUTH_LEAVING)
[248518.529291] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[248518.552009] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[248818.541968] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[248819.526062] wlp4s0: authenticate with f4:f2:6d:de:d5:18
[248819.537268] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 1/3)
[248819.592445] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 2/3)
[248819.656363] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 3/3)
[248819.713262] wlp4s0: authentication with f4:f2:6d:de:d5:18 timed out
[248833.143991] wlp4s0: authenticate with f4:f2:6d:de:d5:18
[248833.152942] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 1/3)
[248833.219390] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 2/3)
[248833.280352] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 3/3)
[248833.326311] wlp4s0: authentication with f4:f2:6d:de:d5:18 timed out
[248843.520536] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[248843.608568] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[248843.664294] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[248844.469060] wlp4s0: authenticate with f4:f2:6d:de:d5:18
[248844.478301] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 1/3)
[248844.536858] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 2/3)
[248844.593867] wlp4s0: send auth to f4:f2:6d:de:d5:18 (try 3/3)
[248844.640307] wlp4s0: authentication with f4:f2:6d:de:d5:18 timed out
[248861.396446] wlp4s0: authenticate with f4:f2:6d:de:d5:18
[248861.405285] wlp4s0: send 

Bug#889740: Info received (Bug#889740: thunderbird: Faulty apparmor configuration)

[Marcin Owsiany]

FTR https://qa.debian.org/bls/packages/x/xmotd.html summarizes them nicely.

Bug#889740: thunderbird: Faulty apparmor configuration

[Marcin Owsiany]

The issue is caused by lack of getTimeStampName declaration in xmotd.c. The
implicit declaration assumed instead causes the pointer to buf to be cast
to an int, in turn causing some truncation of bits which are non-zero in
this case of a static buffer placed in a far location in address space
(probably in some special section when hardening is used). utime() detects
this and returns EFAULT.

The build log shows plenty of warnings, some of which might have a similar
effect.

Bug#886907: libgadu: ftbfs due to -Werror and gnutls_compression_get_name deprecated

[Marcin Owsiany]

Apparently TLS compression is no longer available. The fix would be to
remove the call and the corresponding format in the gg_debug_session call
which uses it.

Bug#868799: RM: command-runner-applet -- ROM; Incompatible with recent gnome-panel: #838903

[Marcin Owsiany]

Package: ftp.debian.org
Severity: normal

Recent gnome-panel dropped support for the API that this package uses,
making it unusable.
See bugs #838903 and #867713 for details.

Bug#562051: How does installation in polish work now?

[Marcin Owsiany]

debian-user-polish is almost dead at this point.
When trying to search the web to see if other Polish users have encountered
this recently, I only found two other posts from 2009 about Debian install
hanging at 52% when running the partitioning program, one being a question
and another more of a rant on why Linux will never go mainstream.

I haven't found any more recent reports.

If someone wanted to help with this, I would suggest replicating the
original reporter's setup as closely as possible in a virtual machine, and
try running the lenny installer on it.
If this reproduces the problem, then try to debug it and/or try a more
recent installer.
If it does not, then just close the bug.

Bug#855165: O: libgadu -- Gadu-Gadu protocol library

[Marcin Owsiany]

Package: wnpp
Severity: normal

It's been years since I've last used a chat program that uses the GG
protocol, so I think it's time for me to orphan this.

Bug#853928: TLS connections broken

[Marcin Owsiany]

Package: libgadu
Version: 1:1.12.1-3
Severity: important

Reportedly the service has changed in an incompatible way and TLS
connections no longer work.
http://www.kadu.im/redmine/issues/3117

This is fixed in libgadu 1.12.2 with this commit: https://github.com/
wojtekka/libgadu/commit/cf07f39da1d69c7219be928e3afcedbdd3c0f49c

Bug#721600: Wrong priority

[Marcin Owsiany]

FWIW, a simple:
 sudo cp /lib/udev/rules.d/52-nut-usbups.rules
/etc/udev/rules.d/63-nut-usbups.rules
fixed this issue for me on a jessie system, with freshly installed
nut-server 2.7.2-4 (I never had nut-server installed on this system before).

Bug#839541: libgadu FTCBFS: configure check assumes broken snprintf

[Marcin Owsiany]

I will try to do this next week.

Please feel free to NMU earlier if you feel like it, so you are not blocked
on me.
However if you do, then please just pass --with-c99-vsnprintf to configure
unconditionally. No need for the extra complexity with comparing
architectures.

Bug#838903: command-runner-applet: Incompatible with upcoming gnome-panel 3.22

[Marcin Owsiany]

2016-09-26 13:14 GMT+02:00 Dmitry Shachnev <mity...@debian.org>:

> Hi Marcin,
>
> On Mon, Sep 26, 2016 at 12:10:10PM +0200, Marcin Owsiany wrote:
> > Deleting in favour sounds good. Do you know if gnome-applets is
> guaranteed
> > (by virtue of depeds or recommends) to be auto-installed on an upgrade
> of a
> > system which has command-runner-applet installed? If not, then perhaps
> > command-runner-applet should be turned into a transitional meta-package
> > which depends on gnome-applets?
>
> gnome-panel recommends gnome-applets, so most users of gnome-panel have
> gnome-applets installed too.
>

OK


> I do not think that turning command-runner-applet into a transitional
> package
> will make sense: the new applet has a different name, and users will need
> to
> add it to the panel manually.


Well, then /usr/share/doc/command-runner-applet/Debian.NEWS could mention
that. But maybe it's an overkill.


> > Apart from that, a sentence about this should probably be dropped into
> > future release notes.
>
> Which release notes do you mean? This will definitely be documented in the
> gnome-panel changelog and release announcement.
>

stretch release notes. I think there is a section about removed/replaced
packages.

Marcin

Bug#838903: command-runner-applet: Incompatible with upcoming gnome-panel 3.22

[Marcin Owsiany]

Deleting in favour sounds good. Do you know if gnome-applets is guaranteed
(by virtue of depeds or recommends) to be auto-installed on an upgrade of a
system which has command-runner-applet installed? If not, then perhaps
command-runner-applet should be turned into a transitional meta-package
which depends on gnome-applets?

Apart from that, a sentence about this should probably be dropped into
future release notes.

Bug#830065: check that init.d script does not alias reload to restart

[Marcin Owsiany]

Package: lintian
Version: 2.5.22ubuntu1
Severity: wishlist

The debian policy (9.3.2) states:

reload
  cause the configuration of the service to be reloaded without actually
  stopping and restarting the service

However I feel that a lot of packages have init scripts which contain something
like:

  case "$1" in
  reload|restart)
stop_service
start_service
;;
  
Disobeying this rule in the SysV-init days was harmless. But it turns
out that systemd is more strict. It makes sure that after
"/etc/init.d/something reload" exits, no processes spawned by it remain
alive. I just plain kills them off with a SIGKILL (see log below).

This behaviour is not very well documented, and it took me a while to track
down the cause of the service disappearing (systemtap is awesome).
It would be nice if lintian caught this early, even if a simple regex check
would not be 100% accurate.


lip 05 08:50:25 piec systemd[3179]: Executing: /etc/init.d/knockd reload
lip 05 08:50:25 piec knockd[3179]: Stopping Port-knock daemon: knockd.
lip 05 08:50:26 piec knockd[3184]: starting up, listening on eth0
lip 05 08:50:26 piec knockd[3179]: Starting Port-knock daemon: knockd.
lip 05 08:50:31 piec systemd[1]: Received SIGCHLD from PID 3179 (knockd).
lip 05 08:50:31 piec systemd[1]: Child 3179 (knockd) died (code=exited, 
status=0/SUCCESS)   <--- init script exits
lip 05 08:50:31 piec systemd[1]: Child 3179 belongs to knockd.service
lip 05 08:50:31 piec systemd[1]: knockd.service: control process exited, 
code=exited status=0
lip 05 08:50:31 piec systemd[1]: knockd.service got final SIGCHLD for state 
reload
lip 05 08:50:31 piec systemd[1]: knockd.service changed reload -> running
lip 05 08:50:31 piec systemd[1]: Job knockd.service/reload finished, result=done
lip 05 08:50:31 piec systemd[1]: Reloaded LSB: port-knock daemon.
lip 05 08:50:31 piec systemd[1]: Got disconnect on private connection.
lip 05 08:50:31 piec systemd[1]: Received SIGCHLD from PID 3184 (knockd).
lip 05 08:50:31 piec systemd[1]: Child 3184 (knockd) died (code=killed, 
status=9/KILL)<--- service killed off
lip 05 08:50:31 piec systemd[1]: Child 3184 belongs to knockd.service
lip 05 08:50:31 piec systemd[1]: knockd.service: cgroup is empty
lip 05 08:50:31 piec systemd[1]: knockd.service changed running -> exited





-- System Information:
Debian Release: jessie/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-35-generic (SMP w/4 CPU cores)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: upstart (via init_is_upstart())

Versions of packages lintian depends on:
ii  binutils   2.24-5ubuntu14.1
ii  bzip2  1.0.6-5
ii  diffstat   1.58-1
ii  file   1:5.14-2ubuntu3.3
ii  gettext0.18.3.1-1ubuntu3
ii  hardening-includes 2.5ubuntu2.1
ii  intltool-debian0.35.0+20060710.1
ii  libapt-pkg-perl0.1.29build1
ii  libarchive-zip-perl1.30-7
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.36-1
ii  libdpkg-perl   1.17.5ubuntu5.6
ii  libemail-valid-perl1.192-1
ii  libfile-basedir-perl   0.03-1fakesync1
ii  libipc-run-perl0.92-1
ii  liblist-moreutils-perl 0.33-1build3
ii  libparse-debianchangelog-perl  1.2.0-1ubuntu1
ii  libtext-levenshtein-perl   0.06~01-2
ii  libtimedate-perl   2.3000-1
ii  liburi-perl1.60-1
ii  man-db 2.6.7.1-1ubuntu1
ii  patchutils 0.3.2-3
ii  perl [libdigest-sha-perl]  5.18.2-2ubuntu1.1
ii  t1utils1.37-2ubuntu1.1

Versions of packages lintian recommends:
ii  libautodie-perl 2.23-1
ii  libperlio-gzip-perl 0.18-1build3
ii  perl-modules [libautodie-perl]  5.18.2-2ubuntu1.1

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.17.5ubuntu5.6
ii  libhtml-parser-perl3.71-1build1
ii  libtext-template-perl  1.46-1
pn  libyaml-perl   
ii  xz-utils   5.1.1alpha+20120614-2ubuntu2

-- no debconf information

Bug#204614: mutt-like tag-foo would be VERY nice

[Marcin Owsiany]

What Manuel described is a strict subset of what I asked for. To be honest
I don't remember why I asked for that in the first place, as these days I
tend to mess around with package lists much less than I did twelve years
ago.

Bug#785238: Suggest apt-forktracer as a way to discover third-party packages

[Marcin Owsiany]

Package: release-notes

4.2 Checking system status says:

  The upgrade process described in this chapter has been designed for
upgrades
  from “pure” wheezy systems without third-party packages. For the greatest
reliability
  of the upgrade process, you may wish to remove third-party packages from
your system
  before you begin upgrading.

However it does not say how to find such packages on one's system.

There are probably many ways to do this, but an easy one is to install the
apt-forktracer package and just run apt-forktracer. It will list those
installed packages:
- which are not available from an official Debian repository, or
- whose installed version is more recent than the one in an official Debian
repository
which I think is a good approximation of the packages mentioned in that
section.


Example output on a wheezy system which shows some non-Debian packages, and
locally patched packages.

porridge@butla:~$ apt-forktracer | sort
adobereader-enu (9.5.5) #
bambam (0.5+dfsg-0.1)
command-runner-applet (0.3-1) [Debian: 0.2-2]
exiftran (2.07-10.1) [Debian: 2.07-10+b1]
google-chrome-stable (42.0.2311.152-1) [Google, Inc.: 42.0.2311.152-1]
how-can-i-help (7~bpo70+1)
skype (4.3.0.37-1)
xscreensaver-data (5.15-3.1) [Debian: 5.15-3]
xscreensaver-gl (5.15-3.1) [Debian: 5.15-3]
xscreensaver (5.15-3.1) [Debian: 5.15-3]
porridge@butla:~$

It may be too late to change this for jessie, but please consider adding
this info for stretch.

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216

Every program in development at MIT expands until it can read mail.
-- Unknown

Bug#782166: command-runner-applet: Time between command runs should be configurable (currently 5 s)

[Marcin Owsiany]

The next command is scheduled to run 5s after *completion* of the previous
command, so I'm assuming the problem you speak about is too high frequency
of executions, not commands piling up on one another, right?

Contributions welcome :-)

Bug#778478: libgadu should have graphviz in build-depends

[Marcin Owsiany]

2015-02-15 16:50 GMT+01:00 Mateusz Łukasik mat...@linuxmint.pl:

 sh: 1: dot: not found
 error: Problems running dot: exit code=127, command='dot',
 arguments='/«PKGBUILDDIR»/docs/html/group__pubdir50.dot -Tpng -o
 /«PKGBUILDDIR»/docs/html/group__pubdir50.png'


Does this have any negative effects on the generated documentation, such as
broken images?

I'm asking since the doxygen documentation [1,2] claims that:

Doxygen has built-in support to generate inheritance diagrams for C++
classes.
Doxygen can use the dot tool from graphviz to generate more advanced
diagrams and graphs.
If you have the dot tool in the path, you can set HAVE_DOT to YES in the
configuration file to let doxygen use it.
The default value is: NO.

So it seems like these should be innocent warnings, since docs/Doxyfile.in
does not specity HAVE_DOT.

I would have no problems adding a build-dep if HAVE_DOT was explicitly set
to YES. But currently using dot is just an implementation detail of
doxygen, so I'm reluctant do add it to build-dependencies if dot is not
even mentioned anywhere in libgadu source.

Marcin

[1] http://www.stack.nl/~dimitri/doxygen/manual/diagrams.html
[2] http://www.stack.nl/~dimitri/doxygen/manual/config.html#cfg_have_dot

Bug#763888: O: cruft -- program that finds any cruft built up on your system

[Marcin Owsiany]

Package: wnpp
Severity: normal

I no longer have the time needed to maintain this package.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#723964: Fix uploaded

[Marcin Owsiany]

FTR, I've just uploaded a fix (Gregor's patch #2) to 7-day DELAYED.

-- 
Marcin Owsiany porri...@debian.org http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#755548: libgadu: build-deps on protobuf-c-compiler but uses embedded libprotobuf-c copy

[Marcin Owsiany]

Fix uploaded to experimental. It's not clear whether it's OK to proceed
with upload to sid ASAP, or wait for some coordinated action?

Bug#755548: libgadu: build-deps on protobuf-c-compiler but uses embedded libprotobuf-c copy

[Marcin Owsiany]

Hmm, I got build failures on a bunch of architectures. I guess I should fix
them first...

Bug#755212: transition: protobuf-c

[Marcin Owsiany]

2014-07-21 23:41 GMT+02:00 Robert Edmonds edmo...@debian.org:

 I looked over the changes to libgadu's convenience copy of protobuf-c.c
 and I *believe* that all the changes are relatively minor (fixing up
 warnings due to libgadu compiling with more -W flags, replacing
 C++-style comments with C89-compatible comments, etc.), or, at least,
 they don't change any of the semantics of the protobuf-c library.


Awesome, thanks for checking that. Changed semantics was what I was worried
about - until a few years ago the gadu-gadu protocol was completely
proprietary, so I thought maybe they improved the protobuf-based done
too. I'll do my best to upload this week.

Marcin

Bug#755212: transition: protobuf-c

[Marcin Owsiany]

The problem with libgadu is that the embedded copy also seems to have
libgadu-specific modifications applied. I've asked upstream to clarify
whether these could be dropped.

Marcin

Bug#685225: Adopting xmotd

[Marcin Owsiany]

+the correct bug address, FTR


2014-06-14 14:54 GMT+02:00 Marcin Owsiany porri...@debian.org:


 14 cze 2014 14:42 Hugo Lefeuvre hugo6...@orange.fr napisał(a):

 
  Hi Marcin,
 
  I'm interested in adopting xmotd.

 Please go ahead.

  I think this program still have its
  place in Debian. I just need an access to the Github repository in order
  to commit my changes.

 The git model is to clone the repo and send pull requests instead.

 Marcin

Bug#688363: Document network availability too

[Marcin Owsiany]

Another thing that should be documented is the availability of the
network (even just the loopback device). This is important for running
test suites of network-related software and there is some variance
between debian architectures regarding what is supported.

See #750843

-- 
Marcin Owsiany porri...@debian.org http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#750843: test/automatic/connect fails on kfreebsd-* bind: Cannot assign requested address

[Marcin Owsiany]

Thanks for filing the bug.

2014-06-07 15:24 GMT+02:00 Andreas Metzler ametz...@bebt.de:

 libgadu FTBFS on kfreebsd-*, test/automatic/connect fails with bind:
 Cannot assign requested address.


FTR, I've seen this a while ago, and asked on debian-bsd for advice
regardng binding to 127.0.0.2, but there was no response.
https://lists.debian.org/debian-bsd/2014/05/msg00047.html

Marcin

Bug#747407: experimental-to-unstable-without-comment should allow to sid

[Marcin Owsiany]

Package: lintian
Version: 2.5.22.1
Severity: wishlist

Lintian looks for the phrase to unstable.
I think it would be sensible to also allow the string to sid which is
a synonym for unstable for eternity AFAIK.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#745311: RFA: ekg2 -- instant messenger and IRC client for UNIX systems

[Marcin Owsiany]

25 kwi 2014 23:28 Mateusz Łukasik mat...@linuxmint.pl napisał(a):

 Hi,

 I can adopt ekg2 package.

Please go ahead.

Bug#745312: RFA: ekg -- console Gadu Gadu client for UNIX systems - ncurses UI

[Marcin Owsiany]

Package: wnpp
Severity: normal

I request an adopter for the ekg package.
I no longer use it and don't have time nor interest to maintain it.

The package description is:
 EKG (Eksperymentalny Klient Gadu-Gadu) is an open source
 Gadu-Gadu client for UNIX systems. Gadu-Gadu is an instant
 messaging program, very popular in Poland.
 .
 EKG features include:
   - irssi-like ncurses interface with mouse support
   - sending and receiving files
   - voice conversations
   - launching shell commands on certain events
   - reading input from pipe
   - Python scripting support
   - speech synthesis (using an external program)
   - encryption support
 .
 Please note that the program is not internationalized and all messages are in
 Polish (although the commands are in English).
 .
 This package contains the program built with just the (text) ncurses user
 interface. If you want to use the GTK+ graphical interface, install the
 ekg-gtk package as well.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#745311: RFA: ekg2 -- instant messenger and IRC client for UNIX systems

[Marcin Owsiany]

Package: wnpp
Severity: normal

I request an adopter for the ekg2 package.
I no longer use it and don't have time to maintain it.

The package description is:
 EKG2 is an open source instant messenger program for UNIX systems. The program
 has a plugin-based structure, and supports multiple protocols, currently
 Jabber, ICQ, Gadu-Gadu, IRC, RivChat, PolChat, NNTP and RSS. Also a generic
 filesystem-based communication mechanism called xmsg is supported.
 .
 The program has many useful features. Here is a list - unless specified they
 are included in the ekg2-core package.
   - irssi-like ncurses interface, with mouse support [ekg2-ui-ncurses]
   - experimental GTK+ interface [ekg2-ui-gtk]
   - experimental HTTP interface
   - experimental 'remote' interface [ekg2-remote]
   - spell checking [ekg2-ui-ncurses]
   - remote control via pipe or socket
   - XOSD support [ekg2-xosd]
   - jogger.pl blog update support
   - a simple CAPTCHA (autoresponder)
   - Python and Perl scripting [ekg2-scripting-python, ekg2-scripting-perl]
   - launching shell commands on certain events
   - encryption support (SIM, GnuPG, ROT13) [ekg2-core, ekg2-gnupg]
   - logging to SQLite, plain text or XML files
   - sending SMs (using an external program such as sms-pl)
   - mail checking
 .
 This is a meta-package which depends on a set of commonly used EKG2 packages.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#745317: RFA: gaduhistory -- EKG history viewer

[Marcin Owsiany]

Package: wnpp
Severity: normal

I request an adopter for the gaduhistory package.
I no longer use it and don't have time nor interest to maintain it.

The package description is:
 This program lets you view Gadu-Gadu chat history of the EKG and EKG2 programs
 in an ncurses-based text interface. It uses SQLite databases internally for
 fast access.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#743098: passing NULL argv to gtestutils.

[Marcin Owsiany]

2014-04-06 19:19 GMT+02:00 Andreas Henriksson andr...@fatal.se:

 Hello Marcin Owsiany!

 In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743098
 you wrote:

  This seems to be a regression in glib, which used to support passing an
  empty argv:

 Looks to me like it at best used to work by chance.

 Could you please explain what you mean by supported


Only that it used to be accepted, and now crashes the program.


 and
 why you think passing an empty argv is a sane thing to do?


It's just one way of passing nothing. Unless the semantics are
documented, this way is as sane as any other :-)

regards,
Marcin

Bug#743098: ekg2: FTBFS: Makefile.am:144: error: 'plugins/autoresponder/autoresponder.la' is not a standard libtool library name

[Marcin Owsiany]

retitle gtestutils crashes with an empty argv
reassign 743098 libglib2.0-dev
thanks

On Sun, Mar 30, 2014 at 06:46:11PM +0200, David Suárez wrote:
  make[5]: Entering directory `/«BUILDDIR»/ekg2-0.4~pre+20120506.1'
  PASS: check_potfiles
  FAIL: check_ekg2

Apparently the binary segfaults during the test:

warning: no loadable sections found in added symbol-file system-supplied DSO at 
0x7fff705fe000
Core was generated by `./ekg2 -F check -n quit'.
Program terminated with signal 11, Segmentation fault.
#0  0x2b0b0df49c3a in g_test_init () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
(gdb) bt full
#0  0x2b0b0df49c3a in g_test_init () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#1  0x2b0b0fd1dfae in check_plugin_init (prio=prio@entry=-254) at 
plugins/check/check.c:26
argc = 0
argv = 0x0
__func__ = check_plugin_init
#2  0x00424818 in plugin_load (name=0x974950 check, 
prio=prio@entry=-254, quiet=quiet@entry=1) at ekg/plugins.c:282
env_ekg_plugins_path = optimized out
init = 0x993b70 \240M\231
lib = optimized out
libname = optimized out
plugin = 0x995680
pl = optimized out
plugin_init = 0x2b0b0fd1df60 check_plugin_init
__func__ = plugin_load
#3  0x0040e60b in main (argc=2, argv=0x7fff7040ad28) at ekg/ekg.c:648
auto_connect = 0
no_global_config = 0
no_config = 0
new_status = 0
print_version = 0
tmp = 0x0
new_descr = 0x0
load_theme = 0x0
new_profile = 0x0
frontend = 0x974950 check
err = 0x0
rlim = {rlim_cur = 18446744073709551615, rlim_max = 
18446744073709551615}
(gdb) 

So it's the same as https://bugs.launchpad.net/bugs/1251887
Citing that bug:

(gdb) bt full
#0 parse_args (argv_p=0x7fff49a8cc18, argc_p=0x7fff49a8cc14) at 
/build/buildd/glib2.0-2.38.1/./glib/gtestutils.c:815
argc = 0
argv = 0x0
i = optimized out
e = optimized out
#1 g_test_init (argc=argc@entry=0x7fff49a8cc14, argv=argv@entry=0x7fff49a8cc18) 
at /build/buildd/glib2.0-2.38.1/./glib/gtestutils.c:1120
seedstr = R02S0449cf08e0df592837157c37845fed72
args = {{gp_offset = 16, fp_offset = 0, overflow_arg_area = 
0x7fff49a8cc10, reg_save_area = 0x7fff49a8cba0}}
vararg1 = optimized out
fatal_mask = optimized out
__PRETTY_FUNCTION__ = g_test_init
#2 0x2b0a5b4dcfde in check_plugin_init (prio=prio@entry=-254) at 
plugins/check/check.c:26
argc = 0
argv = 0x0
__func__ = check_plugin_init
[...]
Line 815 is:
  test_argv0 = argv[0];

which leads to a null pointer dereference in this case.

This seems to be a regression in glib, which used to support passing an
empty argv:
http://sources.debian.net/src/glib2.0/2.36.4-1/glib/gtestutils.c

-- 
Marcin Owsiany porri...@debian.org http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#739718: Please package version 0.5

[Marcin Owsiany]

Package: bambam
Version: 0.4.dfsg-2.1
Severity: wishlist

This version is available from the original repository at
https://code.google.com/p/bambam/wiki/ReleaseHistory

It includes all changes from the original repository, as well as merges
back the (now-defunct) fork from launchpad.net/bambam. It also has a few
improvements, among other things fixing:
  #708119  Please support printing upper-case letters
  #708124  Please support blacklisting individual files


-- System Information:
Debian Release: wheezy/sid
  APT prefers precise-updates
  APT policy: (600, 'precise-updates'), (600, 'precise-security'), (600, 
'precise'), (400, 'precise-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.8.0-35-generic (SMP w/4 CPU cores)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages bambam depends on:
ii  python-pygame  1.9.1release+dfsg-5

bambam recommends no packages.

bambam suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#718060: libgadu: FTBFS: autoreconf: automake-1.11 failed with exit status: 63

[Marcin Owsiany]

On Mon, Nov 11, 2013 at 07:33:38PM +0100, Balint Reczey wrote:
 tags 718060 pending confirmed
 thanks
 
 Hi,
 
 On 07/27/2013 10:49 PM, David Suárez wrote:
 ...
  
  Hi,
  
  During a rebuild of all packages in sid, your package failed to build on
  amd64.
 I have sponsored Mateusz's fix and uploaded it to delayed/2.

I believe the recommended practice is to upload the debdiff to the bug
before or when uploading, but I haven't seen it so far. Am I missing
something?

-- 
Marcin Owsiany porri...@debian.org http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#591387: [doxygen] unreproducible

[Marcin Owsiany]

On Fri, Aug 23, 2013 at 05:27:02PM +0200, Paolo Greppi wrote:
 Also, there is no installdox file at all on my debian wheezy system:
 locate -i installdox

That's because libgadu build process deletes it:

libgadu-1.11.2$ rgrep -i installdox .
./debian/rules: rm -f docs/html/installdox

-- 
Marcin Owsiany porri...@debian.org http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#591387: [doxygen] unreproducible

[Marcin Owsiany]

On Fri, Aug 23, 2013 at 06:31:12PM +0200, Marcin Owsiany wrote:
 On Fri, Aug 23, 2013 at 05:27:02PM +0200, Paolo Greppi wrote:
  Also, there is no installdox file at all on my debian wheezy system:
  locate -i installdox
 
 That's because libgadu build process deletes it:
 
 libgadu-1.11.2$ rgrep -i installdox .
 ./debian/rules:   rm -f docs/html/installdox

No, hang on, the file is not there even if I remove this line.

Indeed, it looks like the bug was fixed at some point.

-- 
Marcin Owsiany porri...@debian.org http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#685225: Note

[Marcin Owsiany]

Nathan is no longer interested in maintaining xmotd.  I'm still the
maintainer, as Nathan did not upload a version with changed
Maintainer:.  Resetting back to the RFA state.

-- 
Marcin Owsiany porri...@debian.org http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#708892: gaduhistory: diff for NMU version 0.5-2.1

[Marcin Owsiany]

On Fri, Jun 28, 2013 at 06:46:03PM +0200, Andrea Colangelo wrote:
 tags 708892 + patch
 tags 708892 + pending
 thanks
 
 Dear maintainer,
 
 I've prepared an NMU for gaduhistory (versioned as 0.5-2.1). The debdiff is
 attached here.

Thank you, please proceeed with upload.

-- 
Marcin Owsiany porri...@debian.org http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#714312: command-runner-applet: Neither the Preferences nor the About dialogues open.

[Marcin Owsiany]

severity 714312 grave
tags 714312 + confirmed pending
thanks

On Thu, Jun 27, 2013 at 11:11:27PM +0300, Axel Stammler wrote:
 After installing the package and adding the applet to the panel, ‘Hello.’ 
 appeared in the
 panel, as it probably should. Pressing the right mouse button on the word 
 caused the
 context menu to open as t should and to show ‘Preferences’ and ‘About.’ But a 
 click on
 neither of these two caused anything else to happen (visibly), so I could not 
 change the
 command being run.

Thanks for the report. I noticed this very recently and have not yet
uploaded a fix. The reason seems to be an incompatibility introduced in
recent versions of GTK.

-- 
Marcin Owsiany porri...@debian.org http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#684217: Optionally show package description in its own column

[Marcin Owsiany]

Thanks for looking at this bug,

On Sat, May 25, 2013 at 06:22:00PM +0200, Joachim Breitner wrote:
 the package name already has the description as a tooltip.

Right, I'm aware of this. However it's not obvious to a casual user.

 Is that sufficient?

No, I'd like it to be visible as a column.

-- 
Marcin Owsiany porri...@debian.org http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#685225: Mentoring

[Marcin Owsiany]

I can take a stab at mentoring you w.r.t. this package.

-- 
Marcin Owsiany porri...@debian.org http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#708119: Please support printing upper-case letters

[Marcin Owsiany]

Package: bambam
Version: 0.4.dfsg-2
Severity: wishlist
Tags: patch

Children in Poland usually begin their literacy education by using
upper-case letters. I guess the reason is that they are easier to write
and distinguish.

The attached patch adds a command-line flag to flip to using upper-case.
The default is still to use lower-case but I'd personally vote to switch
it.

BTW, my 18-month son loves this app, thanks!

-- System Information:
Debian Release: wheezy/sid
  APT prefers precise-updates
  APT policy: (600, 'precise-updates'), (600, 'precise-security'), (600, 
'precise'), (400, 'precise-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.5.0-28-generic (SMP w/4 CPU cores)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages bambam depends on:
ii  python-pygame  1.9.1release+dfsg-5

bambam recommends no packages.

bambam suggests no packages.

-- no debconf information
Index: bambam-0.4.dfsg/bambam.py
===
--- bambam-0.4.dfsg.orig/bambam.py	2013-05-13 12:03:52.0 +0200
+++ bambam-0.4.dfsg/bambam.py	2013-05-13 12:37:16.171299738 +0200
@@ -14,6 +14,7 @@
 #along with this program.  If not, see http://www.gnu.org/licenses/.
 
 import pygame, sys,os, random, string
+import argparse
 from pygame.locals import * 
 
 # figure out the install base to use with image and sound loading
@@ -107,8 +108,13 @@
 # Prints a letter at a random location
 def print_letter(key):
 global screenheight, screenwidth
+global args
 font = pygame.font.Font(None, 256)
-text = font.render(chr(key), 1, colors[random.randint(0, len(colors) -1)])
+if args.uppercase:
+char = chr(key).upper()
+else:
+char = chr(key)
+text = font.render(char, 1, colors[random.randint(0, len(colors) -1)])
 textpos = text.get_rect()
 center = (textpos.width / 2, textpos.height / 2)
 w = random.randint(0+center[0], screenwidth-center[0])
@@ -119,6 +125,10 @@
 
 # Main application
 #
+parser = argparse.ArgumentParser(description='A keyboard mashing game for babies.')
+parser.add_argument('-u', '--uppercase', action='store_true', help='Whether to show UPPER-CASE letters.')	
+args = parser.parse_args()
+
 if not pygame.font: print 'Warning, fonts disabled'
 if not pygame.mixer: print 'Warning, sound disabled'
  

Bug#708124: Please support blacklisting individual files

[Marcin Owsiany]

Package: bambam
Version: 0.4.dfsg-2
Severity: wishlist
Tags: patch

There is a sound (house_lo) that I find very annoying when my son is
using the app. The attached patch lets one specify a blacklist of files
that should never be played. By default the blacklist is empty.


-- System Information:
Debian Release: wheezy/sid
  APT prefers precise-updates
  APT policy: (600, 'precise-updates'), (600, 'precise-security'), (600, 
'precise'), (400, 'precise-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.5.0-28-generic (SMP w/4 CPU cores)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages bambam depends on:
ii  python-pygame  1.9.1release+dfsg-5

bambam recommends no packages.

bambam suggests no packages.

-- no debconf information
Index: bambam-0.4.dfsg/bambam.py
===
--- bambam-0.4.dfsg.orig/bambam.py	2013-05-13 13:24:35.209105954 +0200
+++ bambam-0.4.dfsg/bambam.py	2013-05-13 13:32:00.944652311 +0200
@@ -15,6 +15,7 @@
 
 import pygame, sys,os, random, string
 import argparse
+import fnmatch
 from pygame.locals import * 
 
 # figure out the install base to use with image and sound loading
@@ -54,8 +55,12 @@
 # Loads a list of sounds
 def load_sounds(lst):
 result = []
+global args
 for name in lst:
-result.append(load_sound(name))
+if True in [fnmatch.fnmatch(name, p) for p in args.sound_blacklist]:
+print Skipping blacklisted sound:, name
+else:
+result.append(load_sound(name))
 return result
 
 # Processes events
@@ -127,6 +132,7 @@
 #
 parser = argparse.ArgumentParser(description='A keyboard mashing game for babies.')
 parser.add_argument('-u', '--uppercase', action='store_true', help='Whether to show UPPER-CASE letters.')	
+parser.add_argument('--sound_blacklist', action='append', default=[], help='List of sound filename patterns to never play.')
 args = parser.parse_args()
 
 if not pygame.font: print 'Warning, fonts disabled'

Bug#700206: unblock: ekg2/1:0.3.1-3

[Marcin Owsiany]

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

Please unblock package ekg2

Policy violation Bug#685469, present in backports, is not automatically cleared
on upgrade to squeeze. This upload adds a cleanup step to the postinst script.

Bug is not RC because we don't officially support backports, but I still
consider this important.

--- ekg2-0.3.1/debian/changelog 2012-08-21 22:01:07.0 +0100
+++ ekg2-0.3.1/debian/changelog 2013-02-09 21:02:24.0 +
@@ -1,3 +1,14 @@
+ekg2 (1:0.3.1-3) unstable; urgency=medium
+
+  [ Andreas Beckmann ]
+  * Add ekg2.postinst script to perform the directory to symlink
+transformation of /usr/share/doc/ekg2.  (Closes: #685469)
+
+  [ Marcin Owsiany ]
+  * important bug fix upload, aimed at testing
+
+ -- Marcin Owsiany porri...@debian.org  Sat, 09 Feb 2013 21:00:43 +
+
 ekg2 (1:0.3.1-2) unstable; urgency=medium
 
   * RC-bugfix upload aimed at testing
diff -Nru ekg2-0.3.1/debian/ekg2.postinst ekg2-0.3.1/debian/ekg2.postinst
--- ekg2-0.3.1/debian/ekg2.postinst 1970-01-01 01:00:00.0 +0100
+++ ekg2-0.3.1/debian/ekg2.postinst 2013-02-09 21:02:24.0 +
@@ -0,0 +1,15 @@
+#!/bin/sh
+set -e
+
+if [ $1 = configure ]; then
+   docdir=/usr/share/doc/ekg2
+   # /usr/share/doc/ekg2 was shipped as a directory in ekg2-core by
+   # mistake in 1:0.3.1-1 (#685469). dpkg does not fix this automatically
+   # on upgrades, we need to do it manually here.
+   if [ ! -L $docdir ]  [ -d $docdir ]; then
+   rmdir $docdir
+   ln -s ekg2-core $docdir
+   fi
+fi
+
+#DEBHELPER#

unblock ekg2/1:0.3.1-3

-- System Information:
Debian Release: squeeze/sid
  APT prefers lucid-updates
  APT policy: (600, 'lucid-updates'), (600, 'lucid-security'), (600, 'lucid'), 
(400, 'lucid-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.38-16-generic (SMP w/4 CPU cores)
Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org