Bug#1003089: man-db has become prohibitively slow

[Steinar H. Gunderson]

Package: man-db
Version: 2.9.4-2
Severity: normal
Tags: upstream

Hi Colin,

I've noticed that during upgrades to bullseye, the man-db trigger now seems to
take a very long time; in fact, it frequently seems to be a significant time of
the total time of the full-upgrade (depending, of course, on network speeds).

After digging a bit, I think I've figured out why I haven't seen this before;
it's become a _lot_ slower recently, so it wasn't on the radar before. It seems
that due to a combination of the architecture chosen for these operations
(a pipeline system, seemingly forking off subprocesses and running lots of
syscalls in the process) and a new sandbox model (based on seccomp, which needs
a lot of setup for each new subprocess and adds considerable overhead to each
syscall), most of the total time is now spent in pure setup overhead.

As an example, a complete mandb run (mandb -c) on my laptop takes 3 minutes and
39 seconds. (Of course, the man-db trigger is incremental, but on a 
full-upgrade,
many man pages are likely to be updated.) If I set MAN_DISABLE_SECCOMP=1,
it drops to 1:41. If I recompile without HAVE_LIBSECCOMP, it's down to 51 
seconds!
I still honestly think this is slower than it should be for decompressing and
indexing 144 MB of data, but it means that the sandboxing has 329% overhead
on a modern kernel (5.15.0-2-amd64).

I don't honestly know what this database is for, but my guess is that it is
for the apropos command, which seems rare. (At least nothing obviously bad
happens to my man usage if I “rm -r /var/cache/man/*”, but apropos stops 
working.)
Is it possible to either speed up man-db so that it takes less time to build
its database, or otherwise perhaps split apropos out into a separate
not-installed-by-default package, so that normal installations do not need to
take this installation hit? Or maybe move man-db updating to cron?


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

Kernel: Linux 5.14.0 (SMP w/40 CPU threads)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NO:en_US:en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages man-db depends on:
ii  bsdextrautils  2.36.1-8
ii  bsdmainutils   12.1.7+nmu3
ii  debconf [debconf-2.0]  1.5.77
ii  dpkg   1.20.9
ii  groff-base 1.22.4-6
ii  libc6  2.31-13+deb11u2
ii  libgdbm6   1.19-2
ii  libpipeline1   1.5.3-1
ii  libseccomp22.5.1-1+deb11u1
ii  zlib1g 1:1.2.11.dfsg-2

man-db recommends no packages.

Versions of packages man-db suggests:
ii  apparmor   2.13.6-10
ii  chromium [www-browser] 90.0.4430.212-1
ii  firefox-esr [www-browser]  91.4.1esr-1~deb11u1
pn  groff  
ii  less   551-2
ii  lynx [www-browser] 2.9.0dev.6-3~deb11u1
ii  w3m [www-browser]  0.5.3+git20210102-6

-- debconf-show failed

Bug#999488: plocate: updatedb: cannot prune whitespace-containing directories / paths

[Steinar H. Gunderson]

On Fri, Nov 12, 2021 at 04:41:48AM +0300, Dmitry Alexandrov wrote:
>> It sounds pretty harsh to break a feature used by even the default 
>> configuration.
> Iʼm afraid, that Iʼve failed to locate where switches `-n` or `-e` (and
> command line options at all) are used in the default setup.

But /etc/updatedb.conf is read by default, uses the same space-separated
syntax, and has spaces in its argument in the default configuration.

> Well, Iʼm glad, that youʼve asked, as that allows me to highlight a quite
> minor, yet another UI/UX problem: since configuration file cannot be
> neither overridden (`--config FILE`) nor disabled entirely (`--no-config`),
> I actually feel about it like about a missing stair I have to bear in mind.
> It other words, it would not be much of an issue if updatedb did not
> support config files at all, and all necessary options were specified in a
> wrapper script or even directly in systemd-unit / initscript.

OK. I am afraid your feelings about how much of an issue it would be are
probably not universal, though.

>> and then a flag like --add-single-prunepath that does no splitting?
> If thatʼs a question, whether long options that do no splitting have to be
> named differently, then yes, sure, as they are explicitly plural now.

Well, it's not like I would design a system with this splitting if I made one
from scratch, but you know, if you go around changing even the smallest of
things between mlocate and plocate, there will be angry bug reports
complaining of changed behavior. :-)

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#999488: plocate: updatedb: cannot prune whitespace-containing directories / paths

[Steinar H. Gunderson]

severity 999488 wishlist
thanks

On Thu, Nov 11, 2021 at 11:19:47PM +0300, Dmitry Alexandrov wrote:
> as you find it okay to break backward-compatibility with mlocate
> , let me suggest you a thing, that is
> definitely worth being broken:

It sounds pretty harsh to break a feature used by even the default
configuration. I do agree it is problematic not to support pruning filenames
with spaces in them, though; how would you feel about escaping them in the
configuration file, and then a flag like --add-single-prunepath that does no
splitting?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#913995: [libcurl4-openssl-dev] arch-dependent files in "Multi-Arch: same" package

[Steinar H. Gunderson]

found 913995 7.74.0-1.3+b1
thanks

On Sun, Nov 18, 2018 at 11:25:16AM +0100, Stevie Trujillo wrote:
> libcurl4-openssl-dev is marked as "Multi-Arch: same", but the following 
> files are architecture-dependent:
> 
> /usr/include/curl/curlbuild.h
> 
> An example diff between i386 and amd64 is attached.

It seems this is a problem also in more recent versions;
libcurl4-openssl-dev:amd64 and libcurl4-openssl-dev:i386 are not
co-installable, because:

The following NEW packages will be installed:
  libcurl4-openssl-dev:i386
0 upgraded, 1 newly installed, 0 to remove and 359 not upgraded.
Need to get 0 B/476 kB of archives.
After this operation, 1502 kB of additional disk space will be used.
Selecting previously unselected package libcurl4-openssl-dev:i386.
(Reading database ... 516022 files and directories currently installed.)
Preparing to unpack .../libcurl4-openssl-dev_7.74.0-1.3+b1_i386.deb ...
Unpacking libcurl4-openssl-dev:i386 (7.74.0-1.3+b1) ...
dpkg: error processing archive 
/var/cache/apt/archives/libcurl4-openssl-dev_7.74.0-1.3+b1_i386.deb (--unpack):
 trying to overwrite shared '/usr/bin/curl-config', which is different from 
other instances of package libcurl4-openssl-dev:i386
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/libcurl4-openssl-dev_7.74.0-1.3+b1_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

/* Steinar */

Bug#998389: mlocate systemd timer appears to force execution at midnight, and the obvious override doesn't appear to be working

[Steinar H. Gunderson]

On Thu, Nov 04, 2021 at 12:24:26AM +1100, Tim Connors wrote:
> The new systemd mlocate.timer causes all of my machines to run mlocate
> exactly at midnight.

FWIW, this is fixed in plocate, which replaces mlocate in bookworm.
So this issue would potentially only be fixed in stable, and I doubt it would
be relevant for a stable mlocate update.

What plocate does is:

[Timer]
OnCalendar=daily
RandomizedDelaySec=12h
AccuracySec=20min
Persistent=true

/* Steinar */

Bug#998118: plocate: add an option to show all paths including those that don't exist

[Steinar H. Gunderson]

On Mon, Nov 01, 2021 at 11:31:13AM +0800, Paul Wise wrote:
>> #2 isn't possible; the file could be on a remote filesystem, with
>> arbitrarily complex and hidden ACLs
> I guess there are no libraries to simulate the result of a Linux kernel
> permissions check in userspace & doing that in plocate is too complex.

Again, you're not even guaranteed that you _know_ which ACLs are in force,
if the filesystem is remote. Nor that they are anything that the Linux kernel
understands.

>> (and they may have been changed since updatedb time).
> I feel like it is reasonable to do the access test based on the
> permissions at the time of the updatedb run.

I would disagree, sorry.

>> Is this a real problem, or just nice-to-have?
> I guess skipping stat when root will be a lot faster when there are a
> lot of files matched by the plocate query.

That's not my question. Is this a real problem you're having, that you're
doing locate as root and that it's markedly slow due to all the stat calls?
I'm sure skipping them will be _faster_, but I don't add new code just for
fun (especially code that's skipping security checks); I'd like to know that
it solves someone's real problem somewhere.

I could probably port the --require-visibility 0 option to the plocate client
and then have that drop root privileges, but it sounds very niche to me.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#998118: plocate: add an option to show all paths including those that don't exist

[Steinar H. Gunderson]

On Sun, Oct 31, 2021 at 06:42:20AM +0800, Paul Wise wrote:
>> We really can't do this without dropping sgid, though; that would be a
>> security hole. If a file you didn't have access to earlier was deleted,
>> locate shouldn't suddenly be able to find it.
> 
> There are two ways you could do this:
> 
> 1) simply make it a root-only feature
> 2) store perms information in the database
> 
> Both of these options would be acceptable to me.

#2 isn't possible; the file could be on a remote filesystem, with arbitrarily
complex and hidden ACLs (and they may have been changed since updatedb time).

> If you decide 2) is reasonable then when the database hasn't yet been
> updated for 2) you could do 1).

Is there a reason why you simply cannot build with --require-visibility 0,
if so?

> When root is running plocate please skip the stat checks for speed.

Is this a real problem, or just nice-to-have?

/* Steinar */

Bug#998118: plocate: add an option to show all paths including those that don't exist

[Steinar H. Gunderson]

On Sat, Oct 30, 2021 at 06:33:38PM +0800, Paul Wise wrote:
> When a directory has been deleted, plocate only shows the directory
> name, but not any of the files that were in the directory.

Nor any of the directories that were in that directory. You only get one
level deep (and only if you have access to seeing it).

> For situations where a directory was accidentally deleted it would be
> helpful to be able to list the files that used to be in that directory
> to find out what data was lost and needs to be restored from backup, to
> avoid restoring far too much from backup, which usually takes much
> longer. The plocate database has that information, but plocate does a
> stat and only lists files that still exist. I was able to achieve the
> result I'm looking for by making the stat_if_needed function return
> true, but I think it would be faster to have a codepath that doesn't
> call this function when the proposed option is enabled.

We really can't do this without dropping sgid, though; that would be a
security hole. If a file you didn't have access to earlier was deleted,
locate shouldn't suddenly be able to find it.

> PS: the -e/--existing flag doesn't appear to do anything, looking at
> the source code it only toggles a bool, which nothing looks at.

Really? stat_if_needed() checks it, and it seems to work just fine
for me:

kos:~> touch bug998118-test-file
kos:~> sudo updatedb
kos:~> rm bug998118-test-file 
kos:~> locate bug998118
/home/sesse/bug998118-test-file
kos:~> locate -e bug998118 
kos:~> 

/* Steinar */

Bug#996735: Wrong filename in error message: plocate.db is corrupt or an old version; please rebuild it.

[Steinar H. Gunderson]

tags 996735 + pending
thanks

On Mon, Oct 18, 2021 at 06:57:42AM +1100, Trent W. Buck wrote:
> I noticed plocate always reports a broken locatedb as "plocate.db", even when 
> the filename is something else:
> 
> twb@hera[Desktop]$ LOCATE_PATH=$PWD/test.mlocatedb  locate 'tinyssh*deb'
> plocate.db is corrupt or an old version; please rebuild it.

I've pushed a fix for this to the upstream git repository; I don't think it's
worthwhile making a release with that as the sole fix, but at least it will
go out whenever something else happens. Thanks for your report!

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#996735: Wrong filename in error message: plocate.db is corrupt or an old version; please rebuild it.

[Steinar H. Gunderson]

On Mon, Oct 18, 2021 at 06:57:42AM +1100, Trent W. Buck wrote:
>   2. mlocate is gone in Debian 12, so
>  I wanted to test if locate(1plocate) could read a database generated by 
> updatedb(8mlocate).
>  If it could, I wouldn't have to upgrade all clients and servers at once.
>  (It can't, hence the error message about "corrupt or an old version".)

Notwithstanding this bug, plocate-build(1) can convert mlocate databases
to plocate format. It may not be exactly what you're asking for, but it
should at least be cheaper to put in a cron job somewhere.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#995961: libapache2-mpm-itk: Error "AH00052: child pid exit signal Segmentation fault" after update to apache 2.4.51-1~deb11u1

[Steinar H. Gunderson]

reassign 995961 apache2
found 995961 2.4.51-1~deb11u1
found 995961 2.4.51-1
thanks

On Tue, Oct 12, 2021 at 11:56:20AM +0200, Jean Weisbuch wrote:
> It has also been reported on the HTTPD bugtracker :
> https://bz.apache.org/bugzilla/show_bug.cgi?id=65627

Given the analysis there, it doesn't really look like there's anything
mpm-itk can do, so I'm reassigning this to apache2.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#995961: libapache2-mpm-itk: Error "AH00052: child pid exit signal Segmentation fault" after update to apache 2.4.51-1~deb11u1

[Steinar H. Gunderson]

On Mon, Oct 11, 2021 at 06:06:04PM +0200, Jean Weisbuch wrote:
> Seems like re-compiling mpm-itk (using the exact same sourcecode as the
> previous time i compiled it) and even without any patch applied to HTTPD
> 2.4.51 did also fix the issue for me.

It seems to me that this is only in bullseye-proposed-updates, not actually a
security update yet? If it breaks mpm-itk and nobody really knows why,
I would say that's a good reason to stop the proposal process of the package.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#996167: dpkg: unrecoverable fatal error, aborting: unknown system group 'plocate' in statoverride file;

[Steinar H. Gunderson]

On Mon, Oct 11, 2021 at 06:17:51PM +, Thorsten Glaser wrote:
>> Is there any good reason why the plocate group would disappear
>> that you know of?
> Not that… wait, doesn’t schroot copy groups? Let me see…
> 
> AH! It does! And since my main system is now
> bullseye, not sid, this is the first time it broke. In this
> case, my sincere apology for the report.

Thanks for the quick reply!

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#996167: dpkg: unrecoverable fatal error, aborting: unknown system group 'plocate' in statoverride file;

[Steinar H. Gunderson]

On Mon, Oct 11, 2021 at 07:33:19PM +0200, Thorsten Glaser wrote:
> Package: plocate
> Version: 1.1.12-1
> Severity: critical
> Justification: breaks unrelated software
> X-Debbugs-Cc: t...@mirbsd.de
> 
> I'm encountering this:
> 
> [... apt-get dist-upgrade ...]

Can you say something about what you are upgrading from and to?
Is there any good reason why the plocate group would disappear
that you know of?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#995688: plocate: please support environment variable QUOTING_STYLE or add equivalent option

[Steinar H. Gunderson]

On Mon, Oct 04, 2021 at 01:13:02AM -0600, Liam Stitt wrote:
> Hi. plocate is quoting filenames annoyingly in output. This appears to
> resemble the breaking change in coreutils a few years ago that was
> revertible with the environment variable QUOTING_STYLE. Could plocate
> be taught about that or otherwise given an option to output as mlocate
> did?

Hi,

It's true that it mimics coreutils' changes, simply out of security reasons.
If you do not like it, the simplest solution is plocate | cat.

I could support QUOTING_STYLE, but it would be limited to supporting literal
and shell-escape-always, not the entire range of options. Optionally, I could
support -N/--literal, and you could create a plocate alias?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#911815: /usr/bin/perf_4.18: Please build perf against libbfd

[Steinar H. Gunderson]

On Thu, Sep 09, 2021 at 12:54:50PM +0200, Tony Garnock-Jones wrote:
> Thanks, Steinar, for your suggestion! I've written a patch against the
> non-libbfd code in perf to try it out.
> 
> It works very well. What used to take endless minutes now takes a few
> seconds.

Thanks for doing this! I can confirm; I tested this on “perf report” against
a perf.data with DWARF tracebacks, with perf 5.13.4 (the same file every
time), and here are the results:

  non-bfd, without patch:  7m59s
  non-bfd, with patch:   15s
  bfd:   15s 

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#993684: plocate fails with assertion

[Steinar H. Gunderson]

On Sat, Sep 04, 2021 at 08:17:14PM +0200, Michael Arndt wrote:
> running plocate with the options --existing and --regexp causes it to exit 
> with
> an assertion (exit code 134).

Hi,

You're entirely right; I can confirm. I'll have a look one of these days.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#993354: zsh autocompletion files disappeared

[Steinar H. Gunderson]

Package: ripgrep
Version: 13.0.0-1
Severity: important

Hi,

Since 13.0.0-1, the zsh completion files (/usr/share/zsh/vendor-completions/_rg)
are no longer shipped in the Debian package. This means that every time I write
rg foo , I get

  (eval):1: _rg: function definition file not found

This generally breaks my shell workflow. :-) Downgrading to 12.1.1-1+b1 (stable)
seems to fix the issue.


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

Kernel: Linux 5.14.0 (SMP w/40 CPU threads)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NO:en_US:en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ripgrep depends on:
ii  libc6  2.31-13
ii  libgcc-s1  10.2.1-6

ripgrep recommends no packages.

ripgrep suggests no packages.

-- debconf-show failed

Bug#992540: mlocate: old conffile not removed due to error from dpkg-maintscript-helper

[Steinar H. Gunderson]

On Thu, Aug 19, 2021 at 11:11:52PM +0200, Sven Joachim wrote:
> So it seems you have to specify the package name in
> debian/mlocate.maintscript to rectify the problem.

Thanks for digging!

/* Steinar */

Bug#758559: mlocate: updatedb option to exclude all filesystems not in /

[Steinar H. Gunderson]

On Mon, Aug 18, 2014 at 04:06:38PM -0400, John Kennerson wrote:
> It would be nice if updatedb had an option to prune all file systems
> not listed in /etc/fstab. There doesn't seem to be an easy way to
> achieve this at the moment.

mlocate has been removed from Debian, and has been replaced with plocate.
I'm going through the list of mlocate bugs to try to figure out if any of
them are relevant for plocate.

Is this still a desire? Can you explain a bit what the use case is?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#681177: closed by "Steinar H. Gunderson" (Closing mlocate bugs)

[Steinar H. Gunderson]

On Tue, Aug 17, 2021 at 06:34:54PM +0300, Martin-Éric Racine wrote:
> You might wanna consider adding Provides: mlocate
> 
> Right now, packages that depend on mlocate refuse to install if
> plocate is installed.

Hm, can you give an example of such a package? There's still a dummy
transition package mlocate that depends on plocate, and I thought that would
be enough.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#681177: closed by "Steinar H. Gunderson" (Closing mlocate bugs)

[Steinar H. Gunderson]

On Tue, Aug 17, 2021 at 06:52:23PM +0300, Martin-Éric Racine wrote:
> For instance, cruft-ng.

cruft-ng installs just fine here (by pulling in the mlocate dummy package).
It isn't actually useful due to #976367, though (it expects to be able to
read mlocate's private data format).

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#530924: mlocate: Please add support for searching for files owned by a user

[Steinar H. Gunderson]

On Thu, May 28, 2009 at 08:42:16PM +0100, Dominic Hargreaves wrote:
> It would be really nice to have support for searching for files owned by
> a given user/group. Presumably the information is already in the database,
> for authorization reasons.

Hi,

As of bookworm, mlocate is removed from the archive in favor of plocate.
Is this bug still relevant for you? (If not, I will close it, along with the
other bugs inherited from plocate.)

Do note that the information is _not_ already in the database, neither for
mlocate nor plocate; authorization is done by checking every directory up
from the root, ie., effectively asking the kernel. (Notably, the file itself
isn't checked, since one doesn't need access to it to scan it.) Anything else
would be very difficult wrt. complicated ACLs, networked filesystems or
simply access rights that have been changed since the database was created.
Thus, if someone made such an option for plocate, it would be no more
efficient than piping the list of results through a shell script to check the
owner (and with ACLs, is the owner always what you want?).

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#992189: RM: mlocate -- ROM; replaced with plocate

[Steinar H. Gunderson]

On Tue, Aug 17, 2021 at 02:11:28PM +0200, Mattia Rizzolo wrote:
> As such, I'm closing this RM bug, since more than once I saw such bugs
> executed wrongly and also removed the binary….

OK =)

> In the case of a curft removal, no bugs are closed.
> However, this is not relevant in this case: bugs might be attached to
> either a binary package or a source package: taking over the bin:mlocate
> binary you also carried over all of its bugs already.
> See https://bugs.debian.org/src:plocate

Sure, but I specifically don't want to take over those bugs. (E.g., some of
them are wishlist bugs from 2009...) I could go ahead and close them all
myself, but it sounds maybe better to have the official “mlocate is gone”
mail?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#992189: RM: mlocate -- ROM; replaced with plocate

[Steinar H. Gunderson]

On Sun, Aug 15, 2021 at 01:56:50PM +0200, Steinar H. Gunderson wrote:
> mlocate in unstable has now been replaced with plocate, ie., plocate contains 
> a
> binary package “mlocate” that is a transitional package. Thus, please remove
> the mlocate source package in unstable (but not the mlocate binary package,
> which comes from the plocate source).
> 
> bullseye still contains both mlocate and plocate.

A question: Normally, when a package is removed, all bugs filed against it
are closed; does this also happen in this case? (It doesn't make sense for
plocate to “adopt” all of these bugs, they should probably just be closed.)

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#992189: RM: mlocate -- ROM; replaced with plocate

[Steinar H. Gunderson]

On Sun, Aug 15, 2021 at 08:31:12PM +0800, Paul Wise wrote:
>> mlocate in unstable has now been replaced with plocate, ie., plocate 
>> contains a
>> binary package “mlocate” that is a transitional package. Thus, please remove
>> the mlocate source package in unstable (but not the mlocate binary package,
>> which comes from the plocate source).
> That is going to break cruft-ng, which directly reads the mlocate database.

If so, I guess that's an RC bug on cruft-ng? It would need to be changed to
call the locate binary. (I'm not sure whether the database format is part of
mlocate's API, but in plocate, it's definitely private.)

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#992189: RM: mlocate -- ROM; replaced with plocate

[Steinar H. Gunderson]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: tfh...@debian.org

Hi,

mlocate in unstable has now been replaced with plocate, ie., plocate contains a
binary package “mlocate” that is a transitional package. Thus, please remove
the mlocate source package in unstable (but not the mlocate binary package,
which comes from the plocate source).

bullseye still contains both mlocate and plocate.

Bug#990165: perf: allow using other versions than the running kernel

[Steinar H. Gunderson]

Package: linux-base
Version: 4.6
Severity: normal
Tags: patch

Hi,

The perf wrapper script in Debian requires the perf binary of the running
kernel. However, there's not really a good reason for this; perf has a stable
ABI, and even though it's distributed and built with the kernel, you can freely
mix and match versions (I've done so, a lot).

There may still be reasons why people prefer to keep the versions matched,
but perf shouldn't just give up and die if it can't find the right version.
I've made a patch that makes this a bit more flexible; it first tries to
find a matching version, and if it doesn't exist, it simply picks the newest
one it can find. (If that's older than the kernel, it gives a warning,
since there may be new features the user would want to upgrade for, but it
doesn't die.)

Hopefully this should be safe, while being a lot less annoying when running
a newer or self-compiled kernel. :-)

--- linux-base-4.6.orig/bin/perf2018-07-20 03:35:21.0 +0200
+++ linux-base-4.6/bin/perf 2021-06-22 00:15:59.618443368 +0200
@@ -10,9 +10,11 @@
;;
 esac
 shopt -s execfail
-exec "perf_$version" "$@"
+if [ -x "/usr/bin/perf_$version" ]; then
+exec "perf_$version" "$@"
+fi
 
-# Not found? Tell the user which package to install.
+# Not found? Find out which version to install.
 case "$version" in
 3.* | 4.0 | 4.0.*)
package=linux-tools-$version
@@ -21,5 +23,16 @@
package=linux-perf-$version
;;
 esac
+
+# See if we have a usable alternative available.
+perfversion="$( linux-version sort --reverse $( echo /usr/bin/perf_* | sed 
"s,/usr/bin/perf_,,g" ) | head -n 1 )"
+if [ -x "/usr/bin/perf_$perfversion" ]; then
+if linux-version compare "$perfversion" lt "$version"; then
+echo >&2 "W: perf_$perfversion is older than the running kernel, 
consider installing $package."
+fi
+exec "perf_$perfversion" "$@"
+fi
+
+# Still nothing? Tell the user.
 echo >&2 "E: $package is not installed."
 exit 1

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

Kernel: Linux 5.12.8 (SMP w/40 CPU threads)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NO:en_US:en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-base depends on:
ii  debconf [debconf-2.0]  1.5.75

linux-base recommends no packages.

linux-base suggests no packages.

-- debconf-show failed

Bug#989520: plocate: fuse.rclone fs type should be on default prunefs list

[Steinar H. Gunderson]

On Sun, Jun 06, 2021 at 07:58:13AM +0200, Stefan Breunig wrote:
> plocate already excludes many FSes that are commonly mounted over the network,
> and thus slow (e.g. fuse.sshfs). I suggest to add "fuse.rclone" to the PRUNEFS
> list in the updatedb.conf, since rclone is also typically used to mount 
> network
> drives.

FWIW, this list comes from mlocate (and was shared with it until recently).
So you may want to file a parallel bug against mlocate.

/* Steinar */

Bug#988604: plocate: autopkgtest regression: plocate and mlocate can't be co-installed anymore

[Steinar H. Gunderson]

On Sun, May 16, 2021 at 10:46:30PM +0200, Paul Gevers wrote:
>> Thanks for noticing. Given how annoying everything in autopkgtest is,
>> perhaps the easiest thing is just deleting the tests. (1.1.7-3 wouldn't
>> migrate to bullseye, then, but that's fine.)
> As it stands, you'd only need to remove the third test, not all three.

This is true, but the ergonomics of autopkgtest have been a huge
disappointment for me in general (plocate was the first, and so far only,
package I've tried it on), and I'm not convinced they are likely to catch
any real bugs in the package.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#988604: plocate: autopkgtest regression: plocate and mlocate can't be co-installed anymore

[Steinar H. Gunderson]

On Sun, May 16, 2021 at 09:17:57PM +0200, Paul Gevers wrote:
> With a recent upload of plocate the autopkgtest of plocate fails in
> testing when that autopkgtest is run with the binary packages of plocate
> from unstable. It passes when run with only packages from testing. In
> tabular form:

Thanks for noticing. Given how annoying everything in autopkgtest is,
perhaps the easiest thing is just deleting the tests. (1.1.7-3 wouldn't
migrate to bullseye, then, but that's fine.)

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#988286: plocate: missing Breaks: mlocate

[Steinar H. Gunderson]

On Mon, May 10, 2021 at 11:23:05AM +0200, Andreas Beckmann wrote:
>> What is a good alternative? Can I “give it back” to mlocate in prerm if
>> mlocate is installed?
> Looks like a '$foo-locate-common' package is needed owning the conffile and
> its manpage and then have ?locate depend on it. (What about plain locate?
> Does it use the same config file, too? 'locate-common' looks like it would
> belong to 'locate's namespace.) Perhaps updatedb-common?

I guess this is a pretty large change to make in a freeze, though. The file
is only used for mlocate and plocate; locate.findutils doesn't have an
updatedb.conf IIRC.

The backup plan would possibly be that I move to updatedb.plocate.conf;
I'm not sure whether I should cp updatedb.conf updatedb.plocate.conf in
postinst (assuming it exists) or not. Or, yes, add breaks; there's limited
value to having both installed now that plocate has stabilized. What do you
think?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#988286: plocate: missing Breaks: mlocate

[Steinar H. Gunderson]

On Mon, May 10, 2021 at 10:45:44AM +0200, Andreas Beckmann wrote:
>> Note that plocate is meant to be able to be installed alongside mlocate,
>> so Breaks: is not appropriate. But they share updatedb.conf (they read it
>> using the same code).
> what do you expect to happen with updatedb.conf if both mlocate and plocate
> are installed and thereafter plocate gets purged?

One would hope it's kept. But if dpkg can't handle that, maybe either I
misunderstood the dpkg developers, or it is simply a bug.

What is a good alternative? Can I “give it back” to mlocate in prerm if
mlocate is installed? 

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#988286: plocate: missing Breaks: mlocate

[Steinar H. Gunderson]

forcemerge 976321 988286
thanks

On Sun, May 09, 2021 at 07:01:07PM +0200, Andreas Beckmann wrote:
> The list of installed files at points (1) and (2) should be identical,
> but the following files have disappeared:
> 
>   /etc/updatedb.conf
>   /usr/share/man/man5/updatedb.conf.5.gz

If so, I believe this is a dpkg issue; I asked #debian-dpkg about this at the
time, and was told sharing conffiles via Replaces: was explicitly allowed,
and unit tested for.

> This is a serious bug violating policy 7.6, see
> https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

I don't see anything in 7.6 that says a Breaks is needed? Only that it is
commonly used.

Note that plocate is meant to be able to be installed alongside mlocate,
so Breaks: is not appropriate. But they share updatedb.conf (they read it
using the same code).

> and also see the footnote that describes this incorrect behavior:
> https://www.debian.org/doc/debian-policy/ch-relationships.html#id13

This link is probably not what you meant; it highlights this footnote:

Build-Depends in the source package is not adequate since it (rightfully)
does not document the exact version used in the build.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#986378: linux-image-5.10.0-5-amd64: please enable CONFIG_TLS

[Steinar H. Gunderson]

On Sun, Apr 04, 2021 at 06:33:43PM +0200, Steinar H. Gunderson wrote:
> Please enable CONFIG_TLS=y (kTLS), so that we can get kernel-accelerated TLS
> for compatible software (e.g. cubemap). It's been supported since 4.17,
> so should be pretty mature by now.

Correction: CONFIG_TLS=m is enough. The module is self-contained with no
hooks unless you start enabling hardware acceleration etc. (I actually
enabled kTLS on a buster machine that way, two days ago).

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#986383: unblock: nageru/2.0.0-3

[Steinar H. Gunderson]

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

Please unblock package nageru

Hi Release Team and Hats,

Would it be possible to unblock nageru 2.0.1-3, which I just uploaded?
The changes are:

  1. Reenable build-dep on srt (I was asked to remove it, since srt was
 RC-buggy, but it turned out to stay in testing after all).
  2. A critical one-line bugfix (from upstream git) that prevents correct
 transcoding.

diff -Nru nageru-2.0.1/debian/changelog nageru-2.0.1/debian/changelog
--- nageru-2.0.1/debian/changelog   2021-01-10 13:39:12.0 +0100
+++ nageru-2.0.1/debian/changelog   2021-04-04 21:26:11.0 +0200
@@ -1,3 +1,11 @@
+nageru (2.0.1-3) unstable; urgency=medium
+
+  * Reenable the SRT support, as the srt package was fixed again. 
+  * fix-ffmpeg-height-calculation.diff: New patch from upstream git,
+fixes resolution calculation in kaeru due to a typo.
+
+ -- Steinar H. Gunderson   Sun, 04 Apr 2021 21:26:11 +0200
+
 nageru (2.0.1-2) unstable; urgency=medium
 
   * Build without SRT support (remove the build-dependency on
diff -Nru nageru-2.0.1/debian/control nageru-2.0.1/debian/control
--- nageru-2.0.1/debian/control 2021-01-10 13:39:08.0 +0100
+++ nageru-2.0.1/debian/control 2021-04-04 21:26:11.0 +0200
@@ -5,7 +5,7 @@
 # lld is strictly optional, but depending on it means the build is more 
reproducible;
 # the result doesn't depend on whether the package was installed or not.
 # However, there's a bug on i386 where it doesn't link properly.
-Build-Depends: debhelper (>= 13), qtbase5-dev, libqt5opengl5-dev, pkg-config, 
libusb-1.0-0-dev, libmovit-dev (>= 1.5.2), libmicrohttpd-dev, libx264-dev, 
libavcodec-dev, libavformat-dev (>= 7:3.1), libswscale-dev, libva-dev, 
libavresample-dev, libegl1-mesa-dev, libasound2-dev, libzita-resampler-dev, 
libluajit-5.1-dev, libbmusb-dev (>= 0.7.4), protobuf-compiler, libprotobuf-dev, 
libqcustomplot-dev, meson (>= 0.47), libjpeg-dev, libsqlite3-dev, libdrm-dev, 
lld [!i386]
+Build-Depends: debhelper (>= 13), qtbase5-dev, libqt5opengl5-dev, pkg-config, 
libusb-1.0-0-dev, libmovit-dev (>= 1.5.2), libmicrohttpd-dev, libx264-dev, 
libavcodec-dev, libavformat-dev (>= 7:3.1), libswscale-dev, libva-dev, 
libavresample-dev, libegl1-mesa-dev, libasound2-dev, libzita-resampler-dev, 
libluajit-5.1-dev, libbmusb-dev (>= 0.7.4), protobuf-compiler, libprotobuf-dev, 
libqcustomplot-dev, meson (>= 0.47), libjpeg-dev, libsqlite3-dev, libdrm-dev, 
lld [!i386], libsrt-gnutls-dev
 Build-Conflicts: lld [i386]
 Standards-Version: 4.5.0
 Homepage: https://nageru.sesse.net/
diff -Nru nageru-2.0.1/debian/patches/fix-ffmpeg-height-calculation.diff 
nageru-2.0.1/debian/patches/fix-ffmpeg-height-calculation.diff
--- nageru-2.0.1/debian/patches/fix-ffmpeg-height-calculation.diff  
1970-01-01 01:00:00.0 +0100
+++ nageru-2.0.1/debian/patches/fix-ffmpeg-height-calculation.diff  
2021-04-04 21:26:11.0 +0200
@@ -0,0 +1,13 @@
+Index: nageru-2.0.1/nageru/ffmpeg_capture.cpp
+===
+--- nageru-2.0.1.orig/nageru/ffmpeg_capture.cpp
 nageru-2.0.1/nageru/ffmpeg_capture.cpp
+@@ -1109,7 +1109,7 @@ unsigned FFmpegCapture::frame_height(con
+   if (height == 0) {
+   return frame->height;
+   } else {
+-  return width;
++  return height;
+   }
+ }
+ 
diff -Nru nageru-2.0.1/debian/patches/series nageru-2.0.1/debian/patches/series
--- nageru-2.0.1/debian/patches/series  2019-04-19 09:24:23.0 +0200
+++ nageru-2.0.1/debian/patches/series  2021-04-04 21:26:11.0 +0200
@@ -0,0 +1 @@
+fix-ffmpeg-height-calculation.diff

unblock nageru/2.0.0-3

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

Kernel: Linux 5.11.0 (SMP w/40 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NO:en_US:en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#986378: linux-image-5.10.0-5-amd64: please enable CONFIG_TLS

[Steinar H. Gunderson]

Package: src:linux
Version: 5.10.26-1
Severity: wishlist

Hi,

Please enable CONFIG_TLS=y (kTLS), so that we can get kernel-accelerated TLS
for compatible software (e.g. cubemap). It's been supported since 4.17,
so should be pretty mature by now.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#984698: closed by "Steinar H. Gunderson" (Re: Bug#984698: plocate: updatedb.plocate only indexes top directory of some xfs mounts)

[Steinar H. Gunderson]

On Sun, Mar 21, 2021 at 01:04:49PM +0100, Marcel Partap wrote:
> [pid 2968895] openat(AT_FDCWD, "/mnt/x", O_RDONLY|O_NOATIME|O_DIRECTORY) = 6
> [pid 2968895] fstat(6, {st_dev=makedev(0x8, 0x22), st_ino=128, 
> st_mode=S_IFDIR|0777, st_nlink=34, st_uid=0, st_gid=0, st_blksize=4096, 
> st_blocks=8, st_size=4096, st_atime=0, st_atime_nsec=0, st_mtime=1615114025 
> /* 2021-03-07T11:47:05.236030621+0100 */, st_mtime_nsec=236030621, 
> st_ctime=1615114025 /* 2021-03-07T11:47:05.236030621+0100 */, 
> st_ctime_nsec=236030621}) = 0
> [...]
> [pid 2968895] getdents64(6, [{d_ino=128, d_off=4, d_reclen=24, 
> d_type=DT_UNKNOWN, d_name="*"}, [...] 

The plot thickens; evidently, all of your files in /mnt/x are of type
DT_UNKNOWN, where they should be DT_DIR or DT_REG. Is there anything strange
about the filesystem on /mnt/x?

/* Steinar */

Bug#984698: closed by "Steinar H. Gunderson" (Re: Bug#984698: plocate: updatedb.plocate only indexes top directory of some xfs mounts)

[Steinar H. Gunderson]

On Sun, Mar 21, 2021 at 10:47:11AM +0100, Marcel Partap wrote:
> And what was I supposed to answer to the question "Did anything happen
> here?" .. Yes, something did happen here obviously, as described in the
> original report. And I asked for any recommendations to how to debug this
> further, as it is definitely reproducible on my system.

Yes:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984698#10

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#984698: plocate: updatedb.plocate only indexes top directory of some xfs mounts

[Steinar H. Gunderson]

On Sun, Mar 07, 2021 at 01:28:19PM +0100, Steinar H. Gunderson wrote:
> On Sun, Mar 07, 2021 at 12:51:36PM +0100, Marcel Partap wrote:
>> Quite strange; I noticed paths missing from my locate DB and digged a bit 
>> into
>> this. It seems for two (?!) of my XFS volumes, only the root directory is 
>> being
>> indexed; updatedb.mlocate recurses the whole tree on these.
>> Tested with
>> 
>>> # updatedb.plocate -vU /mnt/x -o /run/shm/updatedb.plocate.test|wc
>>>  35  37 795
>>> # updatedb.mlocate -vU /mnt/x -o /run/shm/updatedb.mlocate.test|wc
>>> […] ⌛️
>>> 4843228 6172553 528118933
>> 
>> Got the repo checked out, if you have recommendations for debugging this.. 
> Could you do strace -vff on updatedb.plocate? (Do note that it will contain
> all your file names, if you care about the privacy of them.)

Hi,

Did anything happen here? (I run XFS on my own machines, and see nothing like
this.)

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#984698: plocate: updatedb.plocate only indexes top directory of some xfs mounts

[Steinar H. Gunderson]

On Sun, Mar 07, 2021 at 12:51:36PM +0100, Marcel Partap wrote:
> Quite strange; I noticed paths missing from my locate DB and digged a bit into
> this. It seems for two (?!) of my XFS volumes, only the root directory is 
> being
> indexed; updatedb.mlocate recurses the whole tree on these.
> Tested with
> 
>> # updatedb.plocate -vU /mnt/x -o /run/shm/updatedb.plocate.test|wc
>>  35  37 795
>> # updatedb.mlocate -vU /mnt/x -o /run/shm/updatedb.mlocate.test|wc
>> […] ⌛️
>> 4843228 6172553 528118933
> 
> Got the repo checked out, if you have recommendations for debugging this.. 

Hi,

Could you do strace -vff on updatedb.plocate? (Do note that it will contain
all your file names, if you care about the privacy of them.)

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#983424: plocate-updatedb.service: PrivateTmp=true blocks indexing /tmp when removed from PRUNEPATHS

[Steinar H. Gunderson]

On Fri, Feb 26, 2021 at 04:13:56PM +0800, Paul Wise wrote:
> Looking at the code, the only possible use of /tmp in updatedb.plocate
> goes via mkstemp, which is secure even with PrivateTmp=false.

Currently, sure. But code has a habit of changing, and the point of
sandboxing is to be safer even against non-obvious bugs.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#983424: plocate-updatedb.service: PrivateTmp=true blocks indexing /tmp when removed from PRUNEPATHS

[Steinar H. Gunderson]

On Fri, Feb 26, 2021 at 09:59:00AM +0800, Paul Wise wrote:
> Well, you change the config, and it is still broken even though you
> changed the config, but you don't notice that, later on you do notice
> that, but you don't understand systemd so you don't know that it could
> have broken that and cannot figure out how to fix it so you contact the
> developers of plocate to find out, and they say to fix PrivateTmp too
> and then you wonder why you need to make essentially the same change to
> the settings of another program rather than just the plocate settings.
> 
> I think this is a fairly poor user experience for this situation.

Well, what do you think is the right fix? Setting PrivateTmp=false,
reducing security for everyone except the tiny minority who wants
/tmp indexed? Having something parse PRUNEPATHS and synthesize a systemd unit
from that?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#983426: plocate: install packages used in cron job: powermgmt-base nocache

[Steinar H. Gunderson]

severity 983426 minor
thanks

On Wed, Feb 24, 2021 at 08:47:49AM +0800, Paul Wise wrote:
> The cron job uses on_ac_power (from powermgmt-base) and nocache, I
> think it would be appropriate to install on those packages, with an
> alternative of systemd-sysv so that they get installed on systems that
> are not running systemd. The nocache package isn't available on all
> architectures so maybe it would be best to use Recommends for this.

Or more likely, Suggests? Recommends is for dependencies that should be
there in all but the most unusual of systems.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#983424: plocate-updatedb.service: PrivateTmp=true blocks indexing /tmp when removed from PRUNEPATHS

[Steinar H. Gunderson]

On Wed, Feb 24, 2021 at 08:24:55AM +0800, Paul Wise wrote:
> Package: plocate
> Version: 1.1.4-1
> Severity: important
> File: /lib/systemd/system/plocate-updatedb.service
> 
> I have emptied PRUNEPATHS since I want all real files indexed including
> the files in the /tmp directory. The PrivateTmp=true setting in the
> plocate-updatedb systemd service blocks /tmp from being indexed.

I don't count this as a bug, really. If you change config, you change config
-- and then you can also change the config of the systemd service by adding
an override in /etc.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#983002: plocate: updatedb fails with "/var/lib/plocate/: Operation not supported"

[Steinar H. Gunderson]

On Fri, Feb 19, 2021 at 08:28:25AM +0100, Steinar H. Gunderson wrote:
> Aha. So overlayfs simply does not support O_TMPFILE? I have a workaround for
> FreeBSD that can probably be reused, but it has the usual concerns of not
> going away if the process is forcibly interrupted.

Are you in a position to try latest git?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#983002: plocate: updatedb fails with "/var/lib/plocate/: Operation not supported"

[Steinar H. Gunderson]

retitle 983002 plocate: does not work with /var on overlayfs
severity 983002 normal
thanks

On Fri, Feb 19, 2021 at 01:20:00AM -0600, Daniel Lewart wrote:
>> Thanks for the bug report. Is there anything special about your
>> /var/lib/plocate? Unusual filesystems? SELinux permissions?
> Yes, it is a Debian Live image, so it is an Overlay filesystem
> (debian-live-testing-amd64-standard.iso).

Aha. So overlayfs simply does not support O_TMPFILE? I have a workaround for
FreeBSD that can probably be reused, but it has the usual concerns of not
going away if the process is forcibly interrupted.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#983002: plocate: updatedb fails with "/var/lib/plocate/: Operation not supported"

[Steinar H. Gunderson]

On Wed, Feb 17, 2021 at 09:30:00PM -0600, Daniel Lewart wrote:
> updatedb fails with:
>   /var/lib/plocate/: Operation not supported
> 
> However, writing to a database in a different directory works fine.

Hi,

Thanks for the bug report. Is there anything special about your
/var/lib/plocate? Unusual filesystems? SELinux permissions?

I assume this is the O_TMPFILE call somehow, but it would be nice if you
could verify by doing

  sudo strace updatedb

and seeing which call is the failing one.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#977286: crash on H.264 encoding

[Steinar H. Gunderson]

reopen 977268
tags 977286 - patch
thanks

On Sun, Dec 13, 2020 at 04:47:56PM +0100, Steinar H. Gunderson wrote:
> Whenever I start Nageru on my Kaby Lake laptop, it segfaults in the VA driver.
> This was fine in 20.3.0+ds1-1, broke in 20.4.1+ds1-1, and is still the case
> in 20.4.2+ds1-1. However, compiling upstream 20.4.3 appears to fix it.
> This is the relevant patch according to bisect:

Unfortunately, with 20.4.5, it's back, so I guess 20.4.3 fixing it was just
luck. The new backtrace is very similar:

Core was generated by `nageru'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f57cdfb767f in CodecHalSetRcsSurfaceState (hwInterface=, cmdBuffer=cmdBuffer@entry=0x7f57927fbfb0, 
surfaceCodecParams=surfaceCodecParams@entry=0x7f57927fbce0, 
kernelState=kernelState@entry=0x560628a1efd0)
at ./media_driver/agnostic/common/codec/hal/codechal_utilities.cpp:463
463 ./media_driver/agnostic/common/codec/hal/codechal_utilities.cpp: No 
such file or directory.
[Current thread is 1 (Thread 0x7f57927fe700 (LWP 3121820))]
(gdb) bt
#0  0x7f57cdfb767f in CodecHalSetRcsSurfaceState(CodechalHwInterface*, 
_MOS_COMMAND_BUFFER*, _CODECHAL_SURFACE_CODEC_PARAMS*, MHW_KERNEL_STATE*)
(hwInterface=, cmdBuffer=cmdBuffer@entry=0x7f57927fbfb0, 
surfaceCodecParams=surfaceCodecParams@entry=0x7f57927fbce0, 
kernelState=kernelState@entry=0x560628a1efd0) at 
./media_driver/agnostic/common/codec/hal/codechal_utilities.cpp:463
#1  0x7f57ce0db641 in 
CodechalEncodeAvcEncG9::SendAvcMbEncSurfaces(_MOS_COMMAND_BUFFER*, 
_CODECHAL_ENCODE_AVC_MBENC_SURFACE_PARAMS*) (this=0x5606289e8970, 
cmdBuffer=0x7f57927fbfb0, params=0x7f57927fc150)
at ./media_driver/agnostic/gen9/codec/hal/codechal_encode_avc_g9.cpp:1955
#2  0x7f57ce013230 in CodechalEncodeAvcEnc::MbEncKernel(bool) 
(this=0x5606289e8970, mbEncIFrameDistInUse=)
at ./media_driver/agnostic/common/codec/hal/codechal_encode_avc.cpp:3896
#3  0x7f57ce0174f9 in CodechalEncodeAvcEnc::ExecuteKernelFunctions() 
(this=0x5606289e8970)
at ./media_driver/agnostic/common/codec/hal/codechal_encode_avc.cpp:6460
#4  0x7f57cdffe870 in CodechalEncoderState::ExecuteEnc(EncoderParams*) 
(this=0x5606289e8970, encodeParams=0x5606289cad60)
at ./media_driver/agnostic/common/codec/hal/codechal_encoder_base.cpp:4755
#5  0x7f57ce300043 in DdiEncodeAvc::EncodeInCodecHal(unsigned int) 
(this=0x5606288e9a90, numSlices=1)
at ./media_driver/linux/common/codec/ddi/media_ddi_encode_avc.cpp:1141
#6  0x7f57ce2eb2d7 in DdiEncodeBase::EndPicture(VADriverContext*, unsigned 
int)
(this=0x5606288e9a90, ctx=, context=)
at ./media_driver/linux/common/codec/ddi/media_ddi_encode_base.cpp:77
#7  0x7f57ce2f05db in DdiEncode_EndPicture(VADriverContext*, unsigned int)
(ctx=ctx@entry=0x5606282f8830, context=context@entry=536870912)
at ./media_driver/linux/common/codec/ddi/media_libva_encoder.cpp:629
#8  0x7f57ce31d50b in DdiMedia_EndPicture(VADriverContextP, VAContextID) 
(ctx=0x5606282f8830, context=536870912)
at ./media_driver/linux/common/ddi/media_libva.cpp:3831
#9  0x7f57dad24adf in vaEndPicture () at /lib/x86_64-linux-gnu/libva.so.2
#10 0x56062716603c in  ()
#11 0x560627168409 in  ()
#12 0x560627168dec in  ()
#13 0x7f57d893bed0 in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
#14 0x7f57d86f5ea7 in start_thread (arg=) at 
pthread_create.c:477
#15 0x7f57d8623def in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#979582: nageru: please drop the Build-Depends on libsrt-gnutls-dev which is RC-buggy

[Steinar H. Gunderson]

On Fri, Jan 08, 2021 at 05:36:58PM +0100, Paul Gevers wrote:
> The srt source package is RC buggy and has just been orphaned. We'll
> probably remove it soon from bullseye. nageru will go too then, unless
> it drop the (apparent optional) Build-Depends.

That's sad to hear. I'll drop the B-D in an upcoming upload; thanks for the
heads-up.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#918175: internal loop labels are kept as symbols

[Steinar H. Gunderson]

On Fri, Jan 01, 2021 at 08:42:38PM +, Mike Gabriel wrote:
> Sorry for replying so late. Could you bring this up with the upstream
> maintainers of libjpeg-turbo? I guess you can explain everything much better
> than me (as you probably had to work around the above problem).
> 
> I'd be happy to apply your patchl, if upstream accepts it.

I've lost all context of this bug, sorry. It's a while back :-) And I don't
know who is upstream. I guess you could report it and they could figure out
if they like the solution or would prefer something else?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#977286: closed by Debian FTP Masters (reply to Sebastian Ramacher ) (Bug#977286: fixed in intel-media-driver-non-free 20.4.3+ds1-1)

[Steinar H. Gunderson]

On Sun, Dec 13, 2020 at 06:09:45PM +, Debian Bug Tracking System wrote:
> We believe that the bug you reported is fixed in the latest version of
> intel-media-driver-non-free, which is due to be installed in the Debian FTP 
> archive.

<3

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#977286: crash on H.264 encoding

[Steinar H. Gunderson]

Package: intel-media-va-driver-non-free
Version: 20.4.2+ds1-1
Severity: important
Tags: patch upstream

Hi,

Whenever I start Nageru on my Kaby Lake laptop, it segfaults in the VA driver.
This was fine in 20.3.0+ds1-1, broke in 20.4.1+ds1-1, and is still the case
in 20.4.2+ds1-1. However, compiling upstream 20.4.3 appears to fix it.
This is the relevant patch according to bisect:

  commit fe06066f8c643b75d6cdac21df8e16106d74e89c
  Author: JasonChen 
  Date:   Thu Nov 26 10:35:24 2020 +0800
  
  [Media Common] Integrate new gmm API for external surface
  
  Integrate new gmm API to create gmmResInfo for external surface.
  Need to update gmm to intel-gmmlib-20.3.3.

This is the backtrace:

Thread 15 "QS_Encode" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffb166d700 (LWP 1311008)]
0x7fffe930d8bf in CodecHalSetRcsSurfaceState (hwInterface=, 
cmdBuffer=cmdBuffer@entry=0x7fffb166af90, 
surfaceCodecParams=surfaceCodecParams@entry=0x7fffb166acc0, 
kernelState=kernelState@entry=0x56748fd0)
at ./media_driver/agnostic/common/codec/hal/codechal_utilities.cpp:463
463 ./media_driver/agnostic/common/codec/hal/codechal_utilities.cpp: Ingen 
slik fil eller filkatalog.
(gdb) bt
#0  0x7fffe930d8bf in CodecHalSetRcsSurfaceState(CodechalHwInterface*, 
_MOS_COMMAND_BUFFER*, _CODECHAL_SURFACE_CODEC_PARAMS*, MHW_KERNEL_STATE*)
(hwInterface=, cmdBuffer=cmdBuffer@entry=0x7fffb166af90, 
surfaceCodecParams=surfaceCodecParams@entry=0x7fffb166acc0, 
kernelState=kernelState@entry=0x56748fd0) at 
./media_driver/agnostic/common/codec/hal/codechal_utilities.cpp:463
#1  0x7fffe9431121 in 
CodechalEncodeAvcEncG9::SendAvcMbEncSurfaces(_MOS_COMMAND_BUFFER*, 
_CODECHAL_ENCODE_AVC_MBENC_SURFACE_PARAMS*)
(this=0x567124a0, cmdBuffer=0x7fffb166af90, params=0x7fffb166b140)
at ./media_driver/agnostic/gen9/codec/hal/codechal_encode_avc_g9.cpp:1955
#2  0x7fffe9369020 in CodechalEncodeAvcEnc::MbEncKernel(bool) 
(this=0x567124a0, mbEncIFrameDistInUse=)
at ./media_driver/agnostic/common/codec/hal/codechal_encode_avc.cpp:3896
#3  0x7fffe936d2e9 in CodechalEncodeAvcEnc::ExecuteKernelFunctions() 
(this=0x567124a0)
at ./media_driver/agnostic/common/codec/hal/codechal_encode_avc.cpp:6460
#4  0x7fffe9354660 in CodechalEncoderState::ExecuteEnc(EncoderParams*) 
(this=0x567124a0, encodeParams=0x566f41d8)
at ./media_driver/agnostic/common/codec/hal/codechal_encoder_base.cpp:4755
#5  0x7fffe96557f3 in DdiEncodeAvc::EncodeInCodecHal(unsigned int) 
(this=0x56614d40, numSlices=1)
at ./media_driver/linux/common/codec/ddi/media_ddi_encode_avc.cpp:1141
#6  0x7fffe9640a77 in DdiEncodeBase::EndPicture(VADriverContext*, unsigned 
int)
(this=0x56614d40, ctx=, context=) at 
./media_driver/linux/common/codec/ddi/media_ddi_encode_base.cpp:77
#7  0x7fffe9645d8b in DdiEncode_EndPicture(VADriverContext*, unsigned int) 
(ctx=ctx@entry=0x561c9590, context=context@entry=536870912)
at ./media_driver/linux/common/codec/ddi/media_libva_encoder.cpp:629
#8  0x7fffe9672b9b in DdiMedia_EndPicture(VADriverContextP, VAContextID) 
(ctx=0x561c9590, context=536870912)
at ./media_driver/linux/common/ddi/media_libva.cpp:3831
#9  0x76718adf in vaEndPicture () at /lib/x86_64-linux-gnu/libva.so.2
#10 0x555dc03e in 
QuickSyncEncoderImpl::encode_frame(QuickSyncEncoderImpl::PendingFrame, int, 
int, int, int, long, long, long, movit::YCbCrLumaCoefficients)
(this=this@entry=0x56633210, frame=..., 
encoding_frame_num=encoding_frame_num@entry=0, 
display_frame_num=display_frame_num@entry=0, 
gop_start_display_frame_num=gop_start_display_frame_num@entry=0, 
frame_type=frame_type@entry=7, pts=12000, dts=1, duration=24000, 
ycbcr_coefficients=movit::YCBCR_REC_601) at 
/usr/include/c++/10/bits/unique_ptr.h:173
#11 0x555de2e3 in QuickSyncEncoderImpl::encode_thread_func() 
(this=0x56633210) at ../nageru/quicksync_encoder.cpp:1832
#12 0x555decbc in operator() (__closure=0x5661e248) at 
../nageru/quicksync_encoder.cpp:1491
#13 std::__invoke_impl > (__f=...) at 
/usr/include/c++/10/bits/invoke.h:60
#14 std::__invoke > (__fn=...) at 
/usr/include/c++/10/bits/invoke.h:95
#15 
std::thread::_Invoker > 
>::_M_invoke<0> (this=0x5661e248) at /usr/include/c++/10/thread:264
#16 
std::thread::_Invoker > >::operator() 
(this=0x5661e248) at /usr/include/c++/10/thread:271
#17 
std::thread::_State_impl > > 
>::_M_run(void) (this=0x5661e240)
at /usr/include/c++/10/thread:215
#18 0x74077ed0 in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
#19 0x73e2fea7 in start_thread (arg=) at 
pthread_create.c:477
#20 0x73d5fd8f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Please upgrade to 20.4.3, and the crash should go away.

-- System Information:
Debian Release: 10.7
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'proposed-updates'), 

Bug#976427: Partial fix Re: Bug#976427 closed by Debian FTP Masters (reply to se...@debian.org (Steinar H. Gunderson)) (Bug#976427: fixed in plocate 1.1.1-2)

[Steinar H. Gunderson]

On Fri, Dec 11, 2020 at 12:07:26AM +0100, GSR wrote:
> The cron script still not installed as executable, which is required
> by run-parts.

Thanks, I'll try to remember next upload.

> Unsorted output of locate, or updatedb.plocate not building the db
> correctly? If the first, eg "apt-cache search locate" too gives poorly
> sorted results. Following Unix philosophy by adding a tool ("| sort")
> that does one thing well solves that cosmetic problem.

Primarily the former. I do not consider this a cosmetic problem; locate
output is meant to be read by end-users, not tools. ls sorts by default,
for instance, and as far as I can tell has done so nearly forever,
so there's nothing in UNIX philosophy that dictates unsorted output.
(POSIX mandates default sorting for ls, so it's not specific to GNU ls.)
There's already a bunch of logic in plocate to get ordering predictable and
correct, and this is _much_ more important to me than catering to fd limits
that mostly stopped making sense twenty years ago.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#976427: Partial fix Re: Bug#976427 closed by Debian FTP Masters (reply to se...@debian.org (Steinar H. Gunderson)) (Bug#976427: fixed in plocate 1.1.1-2)

[Steinar H. Gunderson]

On Thu, Dec 10, 2020 at 12:58:09AM +0100, GSR wrote:
> The solution I meant is "try working with less concurrently opened
> files" or something similar.

Yes, and that's fundamentally hard without creating races and still
maintaining the desired ordering of locate output. updatedb.mlocate
tries, and has to do a very complicated dance with chdir() back and forth.
It runs into lots of icky cases and has to just silently ignore some errors
(with associated races); the only winning move is not to play.

> I understand the concept beyond io_uring,
> but I have not checked any code, so maybe it can be asked to behave
> inside the limits, or the calling code must limit the requests or the
> processing of the answers, or maybe something else completly.

There's no io_uring in updatedb, so this isn't it.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#976843: plocate: cron job may hit open files limit

[Steinar H. Gunderson]

On Tue, Dec 08, 2020 at 04:22:29PM +0100, gregor herrmann wrote:
> This looks much better indeed :)

Thanks! I'll try to slot in a patch one of the coming days.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#976843: plocate: cron job may hit open files limit

[Steinar H. Gunderson]

On Tue, Dec 08, 2020 at 04:14:32PM +0100, gregor herrmann wrote:
> It looks like changing the value to 131072 doesn't work.

Hmm, perhaps one also needs to try raising rlim.rlim_max, which works since
we're root? What happens if you do something like

  rlim.rlim_cur = rlim.rlim_max = 131072;

 /* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#976843: plocate: cron job may hit open files limit

[Steinar H. Gunderson]

On Tue, Dec 08, 2020 at 02:49:48PM +0100, gregor herrmann wrote:
> Maybe something like `ulimit -n 131072' in /etc/cron.daily/plocate
> would be a good idea? (It seems to work for me.)

This is a bit strange, because updatedb attempts the same thing itself,
by means of setrlimit (and there's no reason why bash should be allowed 
to if updatedb isn't). Do you think you could strace it and see what happens
with the getrlimit() and setrlimit() calls?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#976427: Partial fix Re: Bug#976427 closed by Debian FTP Masters (reply to se...@debian.org (Steinar H. Gunderson)) (Bug#976427: fixed in plocate 1.1.1-2)

[Steinar H. Gunderson]

On Tue, Dec 08, 2020 at 01:04:07AM +0100, GSR wrote:
> And the ulimit line is missing, so when testing manually it fails with
> ---8<---
> /some/dir/somewhere: Too many open files
> Hint: Try `ulimit -n 8192' or similar (current limit is 4096).
> --->8---

That's odd; it should do setrlimit() itself at startup (LimitNOFILE=
in the systemd unit is just to set the hard limit). How can ulimit
in the shell succeed but setrlimit() fail?

> When run for personal databases the solution must come from the
> binary, as users will not be able to raise limit beyond the hard
> number.

updatedb isn't privileged, so it's no more able to raise the hard limit than
the user is.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#976688: updatedb systemd service generates incomplete database

[Steinar H. Gunderson]

On Mon, Dec 07, 2020 at 12:47:07AM +0100, Roderich Schupp wrote:
> The culprit seems to be
> 
> ProtectSystem=full
> 
> in plocate-updatedb.service. systemd.exec(5) has:

That's a great catch, thanks. It's probably bind mounts, yes. I'll turn off
ProtectSystem=, which should help matters.

/* Steinar */

Bug#976427: plocate: Please keep cron script for use without systemd

[Steinar H. Gunderson]

On Sat, Dec 05, 2020 at 12:18:26AM +0100, GSR wrote:
> Last update removed cron script, which was working OK. Not everyone
> uses systemd timers, so please keep the script.

Hi,

The cron script did the wrong thing from 1.1.0:

 - It depended on mlocate's database.
 - It would do double-work on top of the systemd timer.

I'm happy taking a patch to add back a script that fixes both of these
issues, ie., runs updatedb.plocate instead of plocate-build, and does not run
if the systemd timer would run instead. Would you like to contribute one?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#976321: plocate: generates an obsolete conffile

[Steinar H. Gunderson]

On Thu, Dec 03, 2020 at 11:05:32AM +0100, Laurent Bonnaud wrote:
> Dear Maintainer,
> 
> here is a sequence of commands to demonstrate the problem:
> 
>  - We start with a system with neither mlocate nor plocate and check that the 
> system is free of obsolete conffiles

Thanks for your bug report. I asked on #debian-dpkg before doing this,
and they said it was supported, so it might be a dpkg bug?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#976313: new magic: plocate database

[Steinar H. Gunderson]

Package: file
Version: 1:5.35-4+deb10u1
Severity: wishlist
Tags: upstream patch

Hi,

Here's a suggested magic entry for plocate databases:

# Summary: Database file for plocate
# Description: A database file as used by plocate, a locate(1) based
#  onposting lists.
# File path:   /var/lib/plocate/plocate.db by default (but configurable)
# Site:https://plocate.sesse.net/
# Format docs: https://git.sesse.net/?p=plocate;a=blob;f=db.h;hb=HEAD
# Type: plocate database file
# URL:  https://plocate.sesse.net/
# From: Steinar H. Gunderson 
0   string  \0plocate   plocate database
>8  long0   \b, version %d (obsolete)
>8  long>0  \b, version %d
>>40longx   \b, max version %d

I'm attaching a small sample of version 1, max version 2.

-- System Information:
Debian Release: 10.7
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'proposed-updates'), (500, 
'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.1 (SMP w/40 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NO:en_US:en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages file depends on:
ii  libc6  2.28-10
ii  libmagic1  1:5.35-4+deb10u1
ii  zlib1g 1:1.2.11.dfsg-1

file recommends no packages.

file suggests no packages.

-- debconf-show failed


plocate.db
Description: Binary data

Bug#974150: [Pkg-fonts-devel] Bug#974150: Noto Mono looks completely different after upgrade

[Steinar H. Gunderson]

On Tue, Nov 10, 2020 at 08:34:10PM +0100, Jonas Smedegaard wrote:
> Would you still find it relevant to pin the old font even if the new one 
> works but simply uses different visual style?

Yes. I find the new one fairly unreadable as a terminal font.

> Source for Debian package is https://github.com/googlefonts/noto-fonts/ 
> - but interestingly, the NotoMono fonts was renamed just 2 days after 
> our latest snapshot - with a totally unrevealing commit message of 
> "Published NotoTraditionalNushu hinted and unhinted static instances":
> https://github.com/googlefonts/noto-fonts/commit/1eda585
> 
> Seems Google changed their mind regarding the reuse of font name, and we 
> can go back to keeping the old legacy font alive...

It sounds they simply messed up the naming when uploading Noto Sans Mono,
and fixed it in that commit.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#974150: [Pkg-fonts-devel] Bug#974150: Noto Mono looks completely different after upgrade

[Steinar H. Gunderson]

On Tue, Nov 10, 2020 at 07:46:55PM +0100, Jonas Smedegaard wrote:
> Why the severity?
> 
> Visual changes does not seem reason release-critical to me.
> 
> "completely broken" need more than a vague suspicion, IMHO.

Feel free to downgrade. The background for the severity: I installed the
package to get a specific font, and that font suddenly disappeared and
was replaced by a completely different font. For me, that's completely
broken. If it's by intention, well... perhaps I'll need to pin the old one
indefinitely, then.

> Google dropped Noto Mono a few years ago.  We kept it alive, until 
> recently when Google re-introduced Noto Mono.

Huh, OK. But why is the web font different from the .ttf, then?
It doesn't make a lot of sense.

If I download the .ttf from https://www.google.com/get/noto/,
it looks like the one in stable. And https://github.com/googlefonts/noto-fonts
doesn't list any “Noto Mono” at all except “Noto Sans Mono”. Where's this new
font coming from?

> This shows which actual fonts are most likely used:
> 
>   fc-match -s 'Noto Mono' | head -n 5

Looks fine for me:

kos:~> fc-match -s 'Noto Mono' | head -n 5  

NotoMono-Regular.ttf: "Noto Mono" "Regular"
Vera.ttf: "Bitstream Vera Sans" "Roman"
DejaVuSans.ttf: "DejaVu Sans" "Book"
DejaVuSans-Bold.ttf: "DejaVu Sans" "Bold"
DejaVuSans-Oblique.ttf: "DejaVu Sans" "Oblique"


> 
> 
> Thanks for reporting this,
> 
>  - Jonas
> 
-- 
Homepage: https://www.sesse.net/

Bug#974150: Noto Mono looks completely different after upgrade

[Steinar H. Gunderson]

Package: fonts-noto-mono
Version: 20201027-3
Severity: grave

Hi,

For unknown reasons, Noto Mono looks completely different after
I upgraded my unstable machines recently, to the point that it's
not the same font anymore (for one, it has serifs). This affects
multiple machines, both rxvt-unicode and gnome-terminal, both
X11 and Wayland, and goes away if I downgrade. Compare the stable
and unstable fonts below (the version of fonts-noto-mono installed
when urxvt started is the sole difference between the two windows):

  https://home.samfundet.no/~sesse/noto-mono.png

The upper (stable) also matches what the font looks like if I
look at https://www.google.com/get/noto/#mono-mono. You can see
some fragments of it in the screenshot; look at e.g. the lowercase
g.

gnome-terminal doesn't even list Noto Mono in its list of available
fonts, so I'm wondering if it does some sort of fallback and that
the font just is completely broken somehow.

Bug#972758: ABI breakage without soname bump

[Steinar H. Gunderson]

On Fri, Oct 23, 2020 at 03:27:23PM +0200, Guillem Jover wrote:
> If we want to support the interim versions that have never been in a
> stable release, then I think the only way is to bump the minmum
> version in liburing shlibs and symbols files to 0.7, then rebuild the
> couple of packages built with 0.6 against 0.7, and then add Breaks in
> liburing against the old dependent package versions using the previous
> liburing releases.

Well, seemingly there are people who run old sid, and then only
“apt update ; apt install plocate” -- which will pull in newer plocate
but not liburing1 :-)

But all that _must_ be supported as per Policy is upgrades from stable to
stable, I believe? Not entirely sure how strict it is. It helps that
liburing1 has never been in stable (only stable-bpo).

> Otherwise I'll just package the new upstream release and request a
> rebuild of reverse dependencies, and we could just ignore 0.7 as if
> it never existed. :)

Yes, a soname bump would certainly do the trick for unstable.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#972758: ABI breakage without soname bump

[Steinar H. Gunderson]

On Fri, Oct 23, 2020 at 12:41:36PM +0200, Julien Cristau wrote:
> All that's needed is a 0.8 release I guess.

Yes, that would fix it. Optionally, one would require something like
a Breaks: liburing (<< 0.7-2) added on all packages compiled against
liburing, plus versioned Breaks on liburing1 on all packages in the
archive ever built against pre-0.7. :-/

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#972758: ABI breakage without soname bump

[Steinar H. Gunderson]

On Fri, Oct 23, 2020 at 11:33:41AM +0200, Julien Cristau wrote:
> https://github.com/axboe/liburing/commit/25bbcbef3e0a8bfba8044be55d08d5116c51dccd
> seems to have bumped SONAME upstream.

That would fix it, yes, but it seems to have missed the kflags change
(the commit says all added padding is at the end).

The kflags change was made a month or so before 0.7 release:

  
https://github.com/axboe/liburing/commit/0f0517331307605e576b3492c93dc4988e06fdc0

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#972758: ABI breakage without soname bump

[Steinar H. Gunderson]

On Fri, Oct 23, 2020 at 09:55:36AM +0200, Steinar H. Gunderson wrote:
> If this were somehow only about newer functionality or critical fixes, it 
> could
> be fixed by bumping the versioned dependency, but rhis goes both ways; if you
> build plocate against liburing 0.6-3, and then upgrade liburing1 to 0.7-1,
> you get a similar crash. So it would seem there's hidden ABI breakage here 
> that
> needs a soname bump.

It seems there's a new “unsigned *kflags;” added in the middle of
struct io_uring_cq that would explain this.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#972758: ABI breakage without soname bump

[Steinar H. Gunderson]

Package: liburing1
Version: 0.7-1
Severity: grave
Tags: upstream

Hi,

I've had a number of reports from people who are having problems with plocate,
that can be traced to differing versions of liburing1. Specifically, plocate
is built in sid against liburing1 0.7-1 (which gets a versioned dependency
only on liburing1 >= 0.4), but if people instead have liburing1 0.6-3 on their
systems, they crash:

kos:~> plocate plocate md5sums
/home/sesse/nmu/plocate-1.0.2/debian/.debhelper/plocate/dbgsym-root/DEBIAN/md5sums
/home/sesse/nmu/plocate-1.0.2/debian/plocate/DEBIAN/md5sums
/var/lib/dpkg/info/plocate-dbgsym.md5sums
/var/lib/dpkg/info/plocate.md5sums

kos:~> sudo dpkg -i liburing1_0.6-3_amd64.deb 
[...]

kos:~> plocate plocate md5sums   
zsh: segmentation fault  plocate plocate md5sums

If this were somehow only about newer functionality or critical fixes, it could
be fixed by bumping the versioned dependency, but rhis goes both ways; if you
build plocate against liburing 0.6-3, and then upgrade liburing1 to 0.7-1,
you get a similar crash. So it would seem there's hidden ABI breakage here that
needs a soname bump.

/* Steinar */

Bug#911815: /usr/bin/perf_4.18: Please build perf against libbfd

[Steinar H. Gunderson]

On Fri, Oct 26, 2018 at 01:12:51AM +0100, Ben Hutchings wrote:
> For future reference, that's the comment:
> 
> # perf can link against libbfd if available, but the result is
> # undistributable as they are licenced under GPL v2 and v3+
> # respectively.  Override detection of libbfd and insist that
> # cplus_demangle() can be found in libiberty (LGPL v2.1+).
> 
> Tagging this wontfix since we can't fix that problem.

But we can probably make the addr2line solution much faster?
perf runs:

scnprintf(cmd, sizeof(cmd), "addr2line -e %s %016"PRIx64,
  dso_name, addr);

fp = popen(cmd, "r");

but the normal way of running addr2line is to run it and then start feeding
it addresses on stdin (ie. don't start the program anew for each and every
address we want to look up). I haven't tried, but it sounds like that would
reduce overhead significantly?

I also don't know if there's a cache somewhere in front of this? It seems to
look up the same addresses over and over and over again, at least in my case
(decoding a processor trace).

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#964563: nageru: FTBFS: ../shared/httpd.cpp:47:25: error: invalid conversion

[Steinar H. Gunderson]

On Thu, Jul 09, 2020 at 09:41:16AM +0200, Sebastian Ramacher wrote:
> Looks like libmicrohttpd upstream didn't consider what it would mean for
> C++ users:
> https://lists.gnu.org/archive/html/libmicrohttpd/2020-07/msg00011.html

Indeed. But calling a function pointer through one of a different type is
undefined behavior even in C.

In any case, I'll need to add some #ifdefs, I believe.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#964563: nageru: FTBFS: ../shared/httpd.cpp:47:25: error: invalid conversion

[Steinar H. Gunderson]

On Wed, Jul 08, 2020 at 08:15:01PM +0200, Sebastian Ramacher wrote:
> | ../shared/httpd.cpp:47:25: error: invalid conversion from ‘int (*)(void*, 
> MHD_Connection*, const char*, const char*, const char*, const char*, size_t*, 
> void**)’ {aka ‘int (*)(void*, MHD_Connection*, const char*, const char*, 
> const char*, const char*, long unsigned int*, void**)’} to 
> ‘MHD_AccessHandlerCallback’ {aka ‘MHD_Result (*)(void*, MHD_Connection*, 
> const char*, const char*, const char*, const char*, long unsigned int*, 
> void**)’} [-fpermissive]
> |47 | _to_connection_thunk, this,
> |   | ^~~
> |   | |
> |   | int (*)(void*, MHD_Connection*, const 
> char*, const char*, const char*, const char*, size_t*, void**) {aka int 
> (*)(void*, MHD_Connection*, const char*, const char*, const char*, const 
> char*, long unsigned int*, void**)}

Has libmicrohttpd changed ABI or something? I assume the size of size_t
hasn't changed :-)

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#964563: nageru: FTBFS: ../shared/httpd.cpp:47:25: error: invalid conversion

[Steinar H. Gunderson]

On Wed, Jul 08, 2020 at 08:26:36PM +0200, Steinar H. Gunderson wrote:
> Has libmicrohttpd changed ABI or something? I assume the size of size_t
> hasn't changed :-)

Indeed, they broke the API:

Wed 08 Apr 2020 10:53:01 PM CEST
Introduce `enum MHD_Result` for #MHD_YES/#MHD_NO to avoid using 'int' so 
much.
Note that this change WILL cause compiler warnings until (most) MHD 
callbacks
in application code change their return type from 'int' to 'enum 
MHD_Result'.
That said, avoiding possible confusions of different enums is going to make
the code more robust in the future. For conditional compilation, test
for "MHD_VERSION >= 0x00097002". -CG

“Will cause compiler warnings”, aka errors in C++ and undefined behavior in C...

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#933180: Patch for #933180

[Steinar H. Gunderson]

On Tue, May 12, 2020 at 11:21:20PM +0200, Steinar H. Gunderson wrote:
>> Hello Steinar and thank you for the patch.
>> The current package contains version 1.4.1, also there was already a
>> branch on Salsa called "split" with ongoing work:
>> https://salsa.debian.org/debian/libsrt/-/tree/split
>> https://salsa.debian.org/debian/libsrt/-/jobs/729505
> Thank you -- no need for me to NMU, then. Do you know approximately when a
> new package will be uploaded to unstable (and presumably hit NEW)?

Hi,

Are there any updates on this? Is there anything you would like help with?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#933180: Patch for #933180

[Steinar H. Gunderson]

On Mon, May 11, 2020 at 12:17:33AM +0100, Federico Ceratto wrote:
> Hello Steinar and thank you for the patch.
> The current package contains version 1.4.1, also there was already a
> branch on Salsa called "split" with ongoing work:
> https://salsa.debian.org/debian/libsrt/-/tree/split
> https://salsa.debian.org/debian/libsrt/-/jobs/729504

Thank you -- no need for me to NMU, then. Do you know approximately when a
new package will be uploaded to unstable (and presumably hit NEW)?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#933180: Patch for #933180

[Steinar H. Gunderson]

On Sun, May 10, 2020 at 11:17:01AM +0200, Steinar H. Gunderson wrote:
> Evidently, libsrt-gnutls-dev has the wrong dependencies (depends on
> libsrt1 instead of libsrt1-gnutls). These are the right ones:

Newer version with some fixes attached.

/* Steinar */
-- 
Homepage: https://www.sesse.net/
diff -Nru srt-1.4.0/debian/changelog srt-1.4.0/debian/changelog
--- srt-1.4.0/debian/changelog	2019-09-17 11:38:25.0 +0200
+++ srt-1.4.0/debian/changelog	2020-05-09 20:28:05.0 +0200
@@ -1,3 +1,11 @@
+srt (1.4.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add a build against GnuTLS, for packages with licenses that are not
+compatible with OpenSSL. (Closes: #933180)
+
+ -- Steinar H. Gunderson   Sat, 09 May 2020 20:28:05 +0200
+
 srt (1.4.0-1) unstable; urgency=medium
 
   * New upstream release (Closes: #939040)
diff -Nru srt-1.4.0/debian/control srt-1.4.0/debian/control
--- srt-1.4.0/debian/control	2019-09-17 11:38:25.0 +0200
+++ srt-1.4.0/debian/control	2020-05-09 20:28:05.0 +0200
@@ -21,6 +21,7 @@
 Multi-Arch: same
 Depends: libsrt1 (= ${binary:Version}), ${misc:Depends}
 Suggests: libsrt-doc (= ${binary:Version})
+Conflicts: libsrt-gnutls-dev
 Description: Secure Reliable Transport UDP streaming library
  SRT is a latency-aware UDP transport mechanism optimized for video streams.
  It detects and compensates for jitter and bandwidth fluctuations due to
@@ -28,6 +29,20 @@
  .
  This package contains development files for libsrt1
 
+Package: libsrt-gnutls-dev
+Section: libdevel
+Architecture: any
+Multi-Arch: same
+Depends: libsrt-gnutls1 (= ${binary:Version}), ${misc:Depends}
+Suggests: libsrt-doc (= ${binary:Version})
+Conflicts: libsrt-dev
+Description: Secure Reliable Transport UDP streaming library
+ SRT is a latency-aware UDP transport mechanism optimized for video streams.
+ It detects and compensates for jitter and bandwidth fluctuations due to
+ network congestion. It mitigates packet loss and supports AES encryption.
+ .
+ This package contains development files for libsrt-gnutls1
+
 Package: libsrt-doc
 Section: doc
 Architecture: all
@@ -48,6 +63,19 @@
  It detects and compensates for jitter and bandwidth fluctuations due to
  network congestion. It mitigates packet loss and supports AES encryption.
 
+Package: libsrt-gnutls1
+Architecture: any
+Multi-Arch: same
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Secure Reliable Transport UDP streaming library
+ SRT is a latency-aware UDP transport mechanism optimized for video streams.
+ It detects and compensates for jitter and bandwidth fluctuations due to
+ network congestion. It mitigates packet loss and supports AES encryption.
+ .
+ The package contains a version of the shared library that is linked to
+ GnuTLS instead of OpenSSL. This is useful if you intend to use SRT in
+ software that is GPL-compatible but not compatible with the OpenSSL license.
+
 Package: srt-tools
 Architecture: any
 Section: utils
diff -Nru srt-1.4.0/debian/libsrt1.install srt-1.4.0/debian/libsrt1.install
--- srt-1.4.0/debian/libsrt1.install	2019-09-17 11:38:25.0 +0200
+++ srt-1.4.0/debian/libsrt1.install	2020-05-09 20:06:32.0 +0200
@@ -1 +1 @@
-usr/lib/*/lib*.so.*
+usr/lib/*/libsrt.so.*
diff -Nru srt-1.4.0/debian/libsrt-dev.install srt-1.4.0/debian/libsrt-dev.install
--- srt-1.4.0/debian/libsrt-dev.install	2019-09-17 11:38:25.0 +0200
+++ srt-1.4.0/debian/libsrt-dev.install	2020-05-09 20:28:05.0 +0200
@@ -1,3 +1,3 @@
 usr/include/*
-usr/lib/*/lib*.so
-usr/lib/*/pkgconfig/*
+usr/lib/*/libsrt.a
+usr/lib/*/libsrt.so
diff -Nru srt-1.4.0/debian/libsrt-gnutls1.install srt-1.4.0/debian/libsrt-gnutls1.install
--- srt-1.4.0/debian/libsrt-gnutls1.install	1970-01-01 01:00:00.0 +0100
+++ srt-1.4.0/debian/libsrt-gnutls1.install	2020-05-09 20:06:43.0 +0200
@@ -0,0 +1,2 @@
+usr/lib/*/libsrt-gnutls.so.*
+
diff -Nru srt-1.4.0/debian/libsrt-gnutls-dev.install srt-1.4.0/debian/libsrt-gnutls-dev.install
--- srt-1.4.0/debian/libsrt-gnutls-dev.install	1970-01-01 01:00:00.0 +0100
+++ srt-1.4.0/debian/libsrt-gnutls-dev.install	2020-05-09 20:28:05.0 +0200
@@ -0,0 +1,3 @@
+usr/include/*
+usr/lib/*/libsrt-gnutls.a
+usr/lib/*/libsrt-gnutls.so
diff -Nru srt-1.4.0/debian/rules srt-1.4.0/debian/rules
--- srt-1.4.0/debian/rules	2019-09-17 11:38:25.0 +0200
+++ srt-1.4.0/debian/rules	2020-05-09 20:28:05.0 +0200
@@ -4,6 +4,14 @@
 export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 
+# Standardized flags from /usr/share/perl5/Debian/Debhelper/Buildsystem/cmake.pm.
+CMAKE_OPTS := -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON
+
+ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
+  NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_O

Bug#933180: Patch for #933180

[Steinar H. Gunderson]

On Sat, May 09, 2020 at 08:33:33PM +0200, Steinar H. Gunderson wrote:
> The attached patch adds an extra build of srt linked to GnuTLS
> (on a different soname), complete with separate -dev packages.
> I intend to NMU with this (and a version bump to 1.4.1) in 14 days
> time; please let me know if you have any comments.

Evidently, libsrt-gnutls-dev has the wrong dependencies (depends on
libsrt1 instead of libsrt1-gnutls). These are the right ones:

Depends: libsrt1-gnutls (= ${binary:Version}), ${misc:Depends}

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#933180: Patch for #933180

[Steinar H. Gunderson]

tags 933180 + patch
thanks

The attached patch adds an extra build of srt linked to GnuTLS
(on a different soname), complete with separate -dev packages.
I intend to NMU with this (and a version bump to 1.4.1) in 14 days
time; please let me know if you have any comments.

/* Steinar */
-- 
Homepage: https://www.sesse.net/
diff -Nru srt-1.4.0/debian/changelog srt-1.4.0/debian/changelog
--- srt-1.4.0/debian/changelog	2019-09-17 11:38:25.0 +0200
+++ srt-1.4.0/debian/changelog	2020-05-09 20:28:05.0 +0200
@@ -1,3 +1,11 @@
+srt (1.4.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add a build against GnuTLS, for packages with licenses that are not
+compatible with OpenSSL. (Closes: #933180)
+
+ -- Steinar H. Gunderson   Sat, 09 May 2020 20:28:05 +0200
+
 srt (1.4.0-1) unstable; urgency=medium
 
   * New upstream release (Closes: #939040)
diff -Nru srt-1.4.0/debian/control srt-1.4.0/debian/control
--- srt-1.4.0/debian/control	2019-09-17 11:38:25.0 +0200
+++ srt-1.4.0/debian/control	2020-05-09 20:09:38.0 +0200
@@ -21,6 +21,7 @@
 Multi-Arch: same
 Depends: libsrt1 (= ${binary:Version}), ${misc:Depends}
 Suggests: libsrt-doc (= ${binary:Version})
+Conflicts: libsrt-gnutls-dev
 Description: Secure Reliable Transport UDP streaming library
  SRT is a latency-aware UDP transport mechanism optimized for video streams.
  It detects and compensates for jitter and bandwidth fluctuations due to
@@ -28,6 +29,20 @@
  .
  This package contains development files for libsrt1
 
+Package: libsrt-gnutls-dev
+Section: libdevel
+Architecture: any
+Multi-Arch: same
+Depends: libsrt1 (= ${binary:Version}), ${misc:Depends}
+Suggests: libsrt-doc (= ${binary:Version})
+Conflicts: libsrt-dev
+Description: Secure Reliable Transport UDP streaming library
+ SRT is a latency-aware UDP transport mechanism optimized for video streams.
+ It detects and compensates for jitter and bandwidth fluctuations due to
+ network congestion. It mitigates packet loss and supports AES encryption.
+ .
+ This package contains development files for libsrt1-gnutls
+
 Package: libsrt-doc
 Section: doc
 Architecture: all
@@ -48,6 +63,19 @@
  It detects and compensates for jitter and bandwidth fluctuations due to
  network congestion. It mitigates packet loss and supports AES encryption.
 
+Package: libsrt1-gnutls
+Architecture: any
+Multi-Arch: same
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Secure Reliable Transport UDP streaming library
+ SRT is a latency-aware UDP transport mechanism optimized for video streams.
+ It detects and compensates for jitter and bandwidth fluctuations due to
+ network congestion. It mitigates packet loss and supports AES encryption.
+ .
+ The package contains a version of the shared library that is linked to
+ GnuTLS instead of OpenSSL. This is useful if you intend to use SRT in
+ software that is GPL-compatible but not compatible with the OpenSSL license.
+
 Package: srt-tools
 Architecture: any
 Section: utils
diff -Nru srt-1.4.0/debian/libsrt1-gnutls.install srt-1.4.0/debian/libsrt1-gnutls.install
--- srt-1.4.0/debian/libsrt1-gnutls.install	1970-01-01 01:00:00.0 +0100
+++ srt-1.4.0/debian/libsrt1-gnutls.install	2020-05-09 20:06:43.0 +0200
@@ -0,0 +1,2 @@
+usr/lib/*/libsrt-gnutls.so.*
+
diff -Nru srt-1.4.0/debian/libsrt1.install srt-1.4.0/debian/libsrt1.install
--- srt-1.4.0/debian/libsrt1.install	2019-09-17 11:38:25.0 +0200
+++ srt-1.4.0/debian/libsrt1.install	2020-05-09 20:06:32.0 +0200
@@ -1 +1 @@
-usr/lib/*/lib*.so.*
+usr/lib/*/libsrt.so.*
diff -Nru srt-1.4.0/debian/libsrt-dev.install srt-1.4.0/debian/libsrt-dev.install
--- srt-1.4.0/debian/libsrt-dev.install	2019-09-17 11:38:25.0 +0200
+++ srt-1.4.0/debian/libsrt-dev.install	2020-05-09 20:26:24.0 +0200
@@ -1,3 +1,2 @@
 usr/include/*
-usr/lib/*/lib*.so
-usr/lib/*/pkgconfig/*
+usr/lib/*/libsrt.so
diff -Nru srt-1.4.0/debian/libsrt-gnutls-dev.install srt-1.4.0/debian/libsrt-gnutls-dev.install
--- srt-1.4.0/debian/libsrt-gnutls-dev.install	1970-01-01 01:00:00.0 +0100
+++ srt-1.4.0/debian/libsrt-gnutls-dev.install	2020-05-09 20:15:20.0 +0200
@@ -0,0 +1,2 @@
+usr/include/*
+usr/lib/*/libsrt-gnutls.so
diff -Nru srt-1.4.0/debian/rules srt-1.4.0/debian/rules
--- srt-1.4.0/debian/rules	2019-09-17 11:38:25.0 +0200
+++ srt-1.4.0/debian/rules	2020-05-09 20:26:11.0 +0200
@@ -4,6 +4,14 @@
 export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 
+# Standardized flags from /usr/share/perl5/Debian/Debhelper/Buildsystem/cmake.pm.
+CMAKE_OPTS := -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON
+
+ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
+  NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
+  MAKEFLAGS += -j$(NUMJOBS

Bug#956959: #956959 can no longer connect after dist-upgrading server

[Steinar H. Gunderson]

On Fri, Apr 24, 2020 at 03:12:00PM +0700, Antoine Martin wrote:
> The Solution has been posted here over 3 weeks ago:
> https://lists.devloop.org.uk/pipermail/shifter-users/2020-April/002555.html

“rm $XDG_RUNTIME_DIR/xpra/run-xpra” worked great, thanks!

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#956959: #956959 can no longer connect after dist-upgrading server

[Steinar H. Gunderson]

On Fri, Apr 24, 2020 at 08:45:38AM +1000, Dmitry Smirnov wrote:
> Since I could not reproduce on 3.0.9, I did not try to test 3.0.8.
> 
> Based on upstream changelog and the correction of another bug (that I've 
> thought to be related) in 3.0.9 I assumed this problem to be fixed.

OK. Is there anything I can do to try to debug this? I don't see anything
obvious in the debug logs, but obviously, _something_ is amiss.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#956959: #956959 can no longer connect after dist-upgrading server

[Steinar H. Gunderson]

On Thu, Apr 23, 2020 at 09:44:22AM +1000, Dmitry Smirnov wrote:
>> sesse@bigscreen:~$ xpra start ssh:sgunders@10.172.139.131 --start=urxvt
> I'm unable to reproduce the problem...

Were you able to reproduce it on 3.0.8? (Ie., is there any reason to believe
that 3.0.9 would fix this specific issue?)

> Also severity is certainly less than "grave".

If it can't connect anywhere, ie. completely broken, it's grave.
However, if it's just broken for some suitably small set of users,
it's probably important.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#956959: closed by Debian FTP Masters (reply to Dmitry Smirnov ) (Bug#956959: fixed in xpra 3.0.9+dfsg1-1)

[Steinar H. Gunderson]

reopen 956959
found 956959 3.0.9+dfsg1-1
thanks

On Mon, Apr 20, 2020 at 01:39:17AM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the xpra package:
> 
> #956959: can no longer connect after dist-upgrading server

Hi,

Unfortunately, 3.0.9 does not solve the problem. (I've upgraded both on the
client and the server.)

sesse@bigscreen:~$ xpra start ssh:sgunders@10.172.139.131 --start=urxvt
2020-04-21 09:59:40,056 Xpra GTK3 X11 client version 3.0.9-r26127 64-bit
2020-04-21 09:59:40,205  running on Linux Debian unstable sid
2020-04-21 09:59:40,206  window manager is 'Mutter (Muffin)'
2020-04-21 09:59:40,224 Warning: failed to import opencv:
2020-04-21 09:59:40,224  No module named 'cv2'
2020-04-21 09:59:40,224  webcam forwarding is disabled
2020-04-21 09:59:40,506 GStreamer version 1.16.2 for Python 3.8.2 64-bit
2020-04-21 09:59:40,587 No OpenGL_accelerate module loaded: No module named 
'OpenGL_accelerate'
2020-04-21 09:59:40,898 OpenGL enabled with GeForce GTX 950/PCIe/SSE2
2020-04-21 09:59:41,169 Connected (version 2.0, client OpenSSH_8.2p1)
2020-04-21 09:59:41,827 Authentication (publickey) successful!
2020-04-21 09:59:42,466 missing some build information: cannot import name 
'build_info' from 'xpra' (/usr/lib/python3/dist-packages/xpra/__init__.py)
2020-04-21 09:59:42,468  keyboard settings: rules=evdev, model=pc105, layout=no
2020-04-21 09:59:42,470  desktop size is 3840x2160 with 1 screen:
2020-04-21 09:59:42,470   :0.0 (1016x572 mm - DPI: 96x95) workarea: 3840x2120
2020-04-21 09:59:42,470 SAM HDMI-0 (521x293 mm - DPI: 187x187)
2020-04-21 09:59:42,512 Warning: the python netifaces package is missing
2020-04-21 09:59:42,630 Error: failed to receive anything, not an xpra server?
2020-04-21 09:59:42,630   could also be the wrong protocol, username, password 
or port
2020-04-21 09:59:42,630   or the session was not found
2020-04-21 09:59:42,631 Connection lost

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#951778: libva2: NULL vtable when querying nvidia render device

[Steinar H. Gunderson]

Package: libva2
Version: 2.6.1-1
Severity: grave

Hi,

It seems that after a recent full-upgrade, querying certain render nodes fails,
crashing my program; it is easily reproducible using vainfo:

  gruessi:~> vainfo --display drm --device /dev/dri/renderD129
  libva info: VA-API version 1.6.0
  vainfo: VA-API version: 1.6 (libva 2.6.0)
  vainfo: Driver version: 
  zsh: segmentation fault  vainfo --display drm --device /dev/dri/renderD129

The crash is in

  Program received signal SIGSEGV, Segmentation fault.
  0x77e254f2 in vaQueryConfigProfiles (dpy=0xd2d0, 
profile_list=0xdc10, 
  num_profiles=0x7fffe92c) at va.c:903
  903   va.c: Ingen slik fil eller filkatalog.
  (gdb) bt
  #0  0x77e254f2 in vaQueryConfigProfiles (dpy=0xd2d0, 
profile_list=0xdc10, 
  num_profiles=0x7fffe92c) at va.c:903
  #1  0x64e3 in ?? ()
  #2  0x77c73bbb in __libc_start_main (main=0x6370, argc=5, 
argv=0x7fffea48, 
  init=, fini=, rtld_fini=, 
stack_end=0x7fffea38)
  at ../csu/libc-start.c:308
  #3  0x68aa in ?? ()

It seems that somehow, the device is opened but gets a NULL vtable:

  (gdb) print *ctx
  $2 = {pDriverData = 0x0, vtable = 0x0, vtable_glx = 0x0, vtable_egl = 0x0, 
vtable_tpi = 0x0, 
native_dpy = 0x0, x11_screen = 0, version_major = 0, version_minor = 0, 
max_profiles = 0, 
max_entrypoints = 0, max_attributes = 0, max_image_formats = 0, 
max_subpic_formats = 0, 
max_display_attributes = 0, str_vendor = 0x0, handle = 0x0, drm_state = 
0xd2a0, glx = 0x0, 
display_type = 49, vtable_wayland = 0x0, vtable_vpp = 0x0, 
override_driver_name = 0x0, 
pDisplayContext = 0xd2d0, error_callback = 0x77e23540 
, 
info_callback = 0x77e23560 , reserved = {0 
}}

I can query renderD128, which corresponds to my Intel iGPU just fine.
renderD129 corresponds to my RTX 2070:

  gruessi:~> cat /sys/class/drm/renderD129/device/vendor
  0x10de
  gruessi:~> cat /sys/class/drm/renderD129/device/device
  0x1f02

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

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

Versions of packages libva2 depends on:
ii  libc6  2.29-10

Versions of packages libva2 recommends:
ii  i965-va-driver-shaders [va-driver]  2.4.0-1
ii  intel-media-va-driver-non-free [va-driver]  19.4.0+ds1-1
ii  mesa-va-drivers [va-driver] 19.3.3-1
ii  va-driver-all   2.6.1-1

libva2 suggests no packages.

-- no debconf information

Bug#950028: nmu: nageru_1.9.1-1.1

[Steinar H. Gunderson]

On Wed, Jan 29, 2020 at 08:57:30AM +0100, Sebastian Ramacher wrote:
> In this case a give-back is enough. These days you can also schedule
> them yourself (see
> https://debblog.philkern.de/2019/08/alpha-self-service-buildd-givebacks.html
> for details)
> 
> I have given back nageru on armel, amrhf, i386 and mipsel.

Thanks! It seems to build nicely now.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#950028: nmu: nageru_1.9.1-1.1

[Steinar H. Gunderson]

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

nmu nageru_1.9.1-1.1 . armel armhf i386 mipsel . unstable . -m "rebuild against 
movit 1.6.3-5"

Hi,

I'm unsure if this should be a binNMU request or not, but please retry
nageru 1.9.1-1.1 (currently in Build-Attempted) on 32-bit platforms
armel, armhf, i386, mipsel; newer movit should work around some Mesa breakage
on such platforms.

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

Kernel: Linux 5.3.11 (SMP w/40 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NO:en_US:en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#949264: nageru: FTBFS on arm/i386/mipsel architectures

[Steinar H. Gunderson]

On Mon, Jan 20, 2020 at 04:32:14PM -0500, Boyuan Yang wrote:
> In this case a rebuild might be worthwhile anyway. Rebuilding package is
> almost always harmless.

Well, rebuilding movit would fix it, but it would also break any reverse
dependency, so they would also need to be rebuilt. And if my theory is right,
this might affect other libraries (although taking in this specific type and
using C++ might not be that common).

> Are you going to trigger the rebuild recently? If not, I can help to trigger
> it through NMU.

I don't intend to do a Movit upload anytime soon, no, and I if I did one,
it would be unlikely to contain a soname bump.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#949264: nageru: FTBFS on arm/i386/mipsel architectures

[Steinar H. Gunderson]

On Sun, Jan 19, 2020 at 12:50:43AM -0500, Boyuan Yang wrote:
> Recent source-only rebuild for nageru has mulitple FTBFS architectures on
> buildd: https://buildd.debian.org/status/package.php?p=nageru
> 
> The tail log all reads like this:

It looks like the definition of GLsizeiptr is different between the movit and
nageru builds:

> ./obj-mipsel-linux-gnu/../nageru/timecode_renderer.cpp:51: undefined reference
> to `movit::generate_vbo(int, unsigned int, long, void const*)'
> /usr/bin/ld: ./obj-mipsel-linux-gnu/../nageru/timecode_renderer.cpp:51:
> undefined reference to `movit::generate_vbo(int, unsigned int, long, void
> const*)'

klump:~/dev/movit> nm --dynamic --demangle 
/usr/lib/i386-linux-gnu/libmovit.so.8 | grep vbo
0001b9a0 T movit::generate_vbo(int, unsigned int, int, void const*)   

Is this an ABI break caused by some recent Mesa change, perhaps? I guess one
could always rebuild Movit...

Seemingly it changed upstream from ptrdiff_t to khronos_ssize_t in Nov 2018,
but I don't know if that was the actual break. krhonos_ssize_t is defined as:

  typedef signed   long  int khronos_ssize_t;

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#946804: plugin download fails (broken keyserver, assumes Python 2)

[Steinar H. Gunderson]

On Mon, Dec 16, 2019 at 08:01:34AM +0100, Didier 'OdyX' Raboud wrote:
> That's really unfortunate indeed; and something I fixed in 3.19.8+dfsg0-2 
> through installing and using the PGP public key directly in the package.

OK.

> That's an upstream-provided "binary artifact"; which should be fixed by them.

I guess yes and no. You could very well argue that this isn't a bug in hplip
in the context of the Debian BTS. On the other hand, making this plugin work
is indeed one fairly important feature of hplip, and it wouldn't be
impossible for hplip to work around it (e.g. by patching the installer prior
to running it).

> hplip is a mess; and more so in stable; and I'm sorry for this (on upstream's 
> behalf I guess).
> 
> That said, I wonder if you could make reasonable use of your HP printer 
> through driverless: https://wiki.debian.org/DriverlessPrinting
> 
> For "normal" printing, it might very well be that you don't _actually_ need 
> hplip.

It might be; I certainly needed a few years back (for whatever reason, I
couldn't just send PostScript to it and make it stick), but times may have
changed.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#946804: plugin download fails (broken keyserver, assumes Python 2)

[Steinar H. Gunderson]

Source: hplip
Version: 3.18.12+dfsg0-2
Severity: important

Hi,

I upgraded a machine to buster recently, and printing (an HP 1025nw,
with HP's proprietary plugin) just silently broke. Everything looked
OK, but nothing was coming out. Finally I found in /var/log/debug:

  Dec 16 00:07:20 localhost hpcups[9302]: prnt/hpcups/HPCupsFilter.cpp 489: 
m_Job initialization failed with error = 48

The Internet suggested I needed to run hp-setup again (which needed
X forwarding, but OK...). It failed pretty badly, since it tried to
contact a keyserver that no longer existed, namely pgpkeys.mit.edu.
(Downloading the key manually from a different keyserver didn't help.)
Worse, however, is that the plugin installation just silently failed.

Eventually, I found out which file it was downloading, namely:

  
http://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/hplip-3.18.12-plugin.run

and ran it myself. It turned out that it couldn't find its HPLIP modules;
by that, it seemingly meant the Python CUPS modules. The problem is that
the .run file prefers /usr/bin/python, which is Python 2, but Debian now only
ships CUPS modules for Python 3. (If you don't have /usr/bin/python, it tries
python3.)

After installing the plugin properly and getting a success message, it _still_
claimed I needed a plugin that I didn't have, and offered to run hp-plugin
for me, but now my old printer definition worked again, so I could just abort
the wizard and print. But new installations will probably be broken.

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

Kernel: Linux 5.3.11 (SMP w/40 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NO:en_US:en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#939937: Acknowledgement (Remotely exploitable null pointer dereference bug)

[Steinar H. Gunderson]

On Wed, Sep 11, 2019 at 12:36:03PM +0200, Max Kellermann wrote:
> I committed my patch to libapreq's Subversion repository:
> 
>  http://svn.apache.org/viewvc?view=revision=1866760

Thanks! I'll make an upload to unstable when I get the time, but I guess the
security team should do one for stable. TBH I don't know how this process
works currently; perhaps security-team@ should be involved?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#939333: varnish: VSV00003 DoS attack vector

[Steinar H. Gunderson]

tags 939333 + patch
thanks

On Tue, Sep 03, 2019 at 02:27:33PM +0200, Salvatore Bonaccorso wrote:
> See https://varnish-cache.org/security/VSV3.html . A CVE does not
> seem yet to be assigned (but a request pending now).

I made a backport to 6.1.1 for stable. It consists of all changes between
6.2.0 and 6.2.1 in git, except:

 - No bumping of version number or changelog.
 - Removed some unrelated change of #include order in otherwise untouched
   files.
 - The tests are not included (probably should be; I removed them as part
   of trying to backport in a slightly different fashion).
 - bin/varnishtest/vtc_http.c needed additional changes from the 6.2.0 set
   to have the end pointer vct_iscrlf() and vct_skipcrlf() now need;
   since varnishtest is not meant to be run against untrusted servers,
   I changed the patch to simply use the old, insecure versions
   (now named vct_iscrlf_unsafe() and vct_skipcrlf_unsafe()).
 - The diff has been refreshed to fix line numbers.

With this patch in debian/patches/, Varnish compiles and appears to run
normally (we already use it in production).

/* Steinar */
-- 
Homepage: https://www.sesse.net/
Index: varnish-6.1.1/bin/varnishd/cache/cache_http.c
===
--- varnish-6.1.1.orig/bin/varnishd/cache/cache_http.c
+++ varnish-6.1.1/bin/varnishd/cache/cache_http.c
@@ -212,7 +212,8 @@ http_Proto(struct http *to)
 
 	fm = to->hd[HTTP_HDR_PROTO].b;
 
-	if ((fm[0] == 'H' || fm[0] == 'h') &&
+	if (fm != NULL &&
+	(fm[0] == 'H' || fm[0] == 'h') &&
 	(fm[1] == 'T' || fm[1] == 't') &&
 	(fm[2] == 'T' || fm[2] == 't') &&
 	(fm[3] == 'P' || fm[3] == 'p') &&
Index: varnish-6.1.1/bin/varnishd/http1/cache_http1_proto.c
===
--- varnish-6.1.1.orig/bin/varnishd/http1/cache_http1_proto.c
+++ varnish-6.1.1/bin/varnishd/http1/cache_http1_proto.c
@@ -111,6 +111,7 @@ http1_dissect_hdrs(struct http *hp, char
 unsigned maxhdr)
 {
 	char *q, *r, *s;
+	int i;
 
 	assert(p > htc->rxbuf_b);
 	assert(p <= htc->rxbuf_e);
@@ -121,31 +122,34 @@ http1_dissect_hdrs(struct http *hp, char
 
 		/* Find end of next header */
 		q = r = p;
-		if (vct_iscrlf(p))
+		if (vct_iscrlf(p, htc->rxbuf_e))
 			break;
 		while (r < htc->rxbuf_e) {
 			if (!vct_isctl(*r) || vct_issp(*r)) {
 r++;
 continue;
 			}
-			if (!vct_iscrlf(r)) {
+			i = vct_iscrlf(r, htc->rxbuf_e);
+			if (i == 0) {
 VSLb(hp->vsl, SLT_BogoHeader,
 "Header has ctrl char 0x%02x", *r);
 return (400);
 			}
 			q = r;
-			assert(r < htc->rxbuf_e);
-			r += vct_skipcrlf(r);
-			if (r >= htc->rxbuf_e)
+			r += i;
+			assert(r <= htc->rxbuf_e);
+			if (r == htc->rxbuf_e)
 break;
-			if (vct_iscrlf(r))
+			if (vct_iscrlf(r, htc->rxbuf_e))
 break;
 			/* If line does not continue: got it. */
 			if (!vct_issp(*r))
 break;
 
 			/* Clear line continuation LWS to spaces */
-			while (vct_islws(*q))
+			while (q < r)
+*q++ = ' ';
+			while (q < htc->rxbuf_e && vct_issp(*q))
 *q++ = ' ';
 		}
 
@@ -206,11 +210,9 @@ http1_dissect_hdrs(struct http *hp, char
 			return (400);
 		}
 	}
-	/* We cannot use vct_skipcrlf() we have to respect rxbuf_e */
-	if (p+2 <= htc->rxbuf_e && p[0] == '\r' && p[1] == '\n')
-		p += 2;
-	else if (p+1 <= htc->rxbuf_e && p[0] == '\n')
-		p += 1;
+	i = vct_iscrlf(p, htc->rxbuf_e);
+	assert(i > 0);		/* HTTP1_Complete guarantees this */
+	p += i;
 	HTC_RxPipeline(htc, p);
 	htc->rxbuf_e = p;
 	return (0);
@@ -224,7 +226,7 @@ static uint16_t
 http1_splitline(struct http *hp, struct http_conn *htc, const int *hf,
 unsigned maxhdr)
 {
-	char *p;
+	char *p, *q;
 	int i;
 
 	assert(hf == HTTP1_Req || hf == HTTP1_Resp);
@@ -265,26 +267,34 @@ http1_splitline(struct http *hp, struct
 	hp->hd[hf[1]].e = p;
 	if (!Tlen(hp->hd[hf[1]]))
 		return (400);
-	*p++ = '\0';
 
 	/* Skip SP */
+	q = p;
 	for (; vct_issp(*p); p++) {
 		if (vct_isctl(*p))
 			return (400);
 	}
-	hp->hd[hf[2]].b = p;
+	if (q < p)
+		*q = '\0';	/* Nul guard for the 2nd field. If q == p
+ * (the third optional field is not
+ * present), the last nul guard will
+ * cover this field. */
 
 	/* Third field is optional and cannot contain CTL except TAB */
-	for (; !vct_iscrlf(p); p++) {
-		if (vct_isctl(*p) && !vct_issp(*p)) {
-			hp->hd[hf[2]].b = NULL;
+	q = p;
+	for (; p < htc->rxbuf_e && !vct_iscrlf(p, htc->rxbuf_e); p++) {
+		if (vct_isctl(*p) && !vct_issp(*p))
 			return (400);
-		}
 	}
-	hp->hd[hf[2]].e = p;
+	if (p > q) {
+		hp->hd[hf[2]].b = q;
+		hp->hd[hf[2]].e = p;
+	}
 
 	/* Skip CRLF */
-	i = vct_skipcrlf(p);
+	i = vct_iscrlf(p, htc->rxbuf_e);
+	if (!i)
+		return (400);
 	*p = '\0';
 	p += i;
 
Index: varnish-6.1.1/include/vct.h
===
--- varnish-6.1.1.orig/include/vct.h
+++ varnish-6.1.1/include/vct.h
@@ -30,6 +30,8 @@
 
 /* from libvarnish/vct.c */
 
+#include "vas.h"
+
 #define VCT_SP			(1<<0)
 

Bug#832095: zita-resampler - debian bug

[Steinar H. Gunderson]

On Mon, Sep 05, 2016 at 01:24:59AM +0200, Steinar H. Gunderson wrote:
> I expanded on the patch; this new version supports 1, 2 and multiples of 4
> channels, and it no longer relies on the serial code (when I can't write past
> the end, I just write to a temporary buffer and copy out from there).
> Of course, you'll need to reorganize to fit the new structure once you have
> it, but hopefully, that should be simple.

I keep coming back to this. :-) Is there any progress here, three years later?
It would be really nice to have that reduced CPU usage; my laptop isn't
getting any faster. :-)

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#918960: libgl1-mesa-dri: lacks valgrind support

[Steinar H. Gunderson]

tags 918960 + patch
thanks

On Fri, Jan 11, 2019 at 01:29:35AM +0100, Momchil wrote:
> I would like you to compile the library with valgrind support turned on or
> create a separate package where the feature is turned on. This allows one to
> use valgrind to check for memory leaks in applications. In case the feature is
> not compiled, valgrind reports tons of memory problems with applications using
> OpenGL for example.

Note that this is utterly trivial; just add a Build-Dependency on valgrind,
and the build system will take care of the rest. My understanding is that
this has zero impact on runtime performance; it just adds a few very short
instruction sequences after each DRM allocation, only picked up when running
under Valgrind.

I tried rebuilding with the b-d in question, and indeed, the torrent of
Valgrind errors went away almost entirely.

> Please also refer to my other report Bug#918895: libdrm2:
> lacks valgrind support.

It looks as if libdrm2 is already built with Valgrind support.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#934043: segfaults with use-after-free when using KrbServiceName Any

[Steinar H. Gunderson]

Package: libapache2-mod-auth-kerb
Version: 5.4-2.3
Severity: grave
Tags: patch upstream

Hi,

After upgrading to buster, mod_auth_kerb keeps on crashing Apache (thus the
grave severity), after printing

  double free or corruption (out)

This is indeed a use-after-free; verify_krb5_user gets in a keytab as a
parameter, and chooses to deallocate it even though the parent expects to keep
using it. I don't know why this didn't trigger as often in stretch,
although we've certainly seen mod_auth_kerb segfaults there as well
(especially with outdated keytabs).

The patch is trivial and can be found in upstream's bug tracker; just don't
deallocate the keytab in verify_krb5_user():

  https://sourceforge.net/p/modauthkerb/bugs/61/

This is not a leak, since the parent closes it inself, in all paths. I've 
verified
that it applies in Debian (just some changed line numbers) and fixes the issue.

Please consider for a buster point release, in addition to unstable.
It makes mod_auth_kerb borderline unusable.

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

Kernel: Linux 5.1.11 (SMP w/40 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NO:en_US:en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libapache2-mod-auth-kerb depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.38-3
ii  krb5-config 2.6
ii  libc6   2.28-10
pn  libcomerr2  
ii  libgssapi-krb5-21.17-3
ii  libk5crypto31.17-3
ii  libkrb5-3   1.17-3

libapache2-mod-auth-kerb recommends no packages.

libapache2-mod-auth-kerb suggests no packages.

Bug#924267: intel-media-va-driver: [CFL] no H.264 encoding, no JPEG decoding

[Steinar H. Gunderson]

On Wed, Jul 10, 2019 at 10:43:30PM +0200, Sebastian Ramacher wrote:
> As far as I understand the feature matrices of 18.4.x and 19.2.x, the
> open source build supports H.264 and JPEG encoding for Coffee Lake only
> as of the 19.2.x. This version is now available in unstable. Could you
> try it again with the new version?

I don't have access to that machine right now, unfortunately. It will have to
wait until after the summer. :-/

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#930877: nageru FTCBFS: cannot use bin2h as a generator

[Steinar H. Gunderson]

On Fri, Jun 21, 2019 at 09:48:58PM +0200, Helmut Grohne wrote:
> nageru fails to cross build from source, because meson refuses to run
> the host binary bin2h. As it happens, bin2h is not installed by nageru.
> Its behaviour is architecture-independent. For these reasons we can mark
> it native. After doing so, nageru cross builds successfully. Please
> consider applying the attached patch.

Hi,

Applied in upstream git, but won't be uploaded to Debian yet due to the
freeze. Thanks for the patch!

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#930756: unblock: movit/1.6.2-2

[Steinar H. Gunderson]

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

Please unblock package movit

It contains a single, focused fix for a severity=important bug that I found,
backported from upstream git.

It's a bit unclear to me whether “corrupted display” would count as appropriate
for buster unblocks, but I thought it might go under the “crashes etc.” heading
(it's technically undefined behavior with a thread race, but I don't think
there are any real GL drivers where this actually causes _crashes_ per se).
If not, please let me know.

From the upstream commit message; especially the part about ABI stability at
the end should be relevant:

Fix an issue where temporary textures could be reused too early by a 
different thread.

When an EffectChain is done rendering (ie., has submitted all of the GL
rendering commands that it needs to), it releases all of the temporary
textures it's used back to a common freelist.

However, if another thread needs a texture of the same size and format,
it could be picking it off of the freelist before the GPU has actually
completed rendering the first thread's command list, and start uploading
into it. This is undefined behavior in OpenGL, and can create garbled
output depending on timing and driver. (I've seen this on at least the
classic Intel Mesa driver.)

Fix by setting fences, so that getting a texture from the freelist
will have an explicit ordering versus the previous work. This increases the
size of ResourcePool::TextureFormat, but it is only ever used in a private
std::map. std::map is node-based (it has to, since the C++ standard requires
iterators to it to be stable), and thus, sizeof(TextureFormat) does not 
factor
into sizeof(ResourcePool), and thus, there is no ABI break. Verified by
checking on libstdc++.

diff -Nru movit-1.6.2/debian/changelog movit-1.6.2/debian/changelog
--- movit-1.6.2/debian/changelog2018-03-18 16:25:30.0 +0100
+++ movit-1.6.2/debian/changelog2019-06-15 20:08:45.0 +0200
@@ -1,3 +1,11 @@
+movit (1.6.2-2) unstable; urgency=high
+
+  * fix-temporary-texture-race-issue.diff: New patch backported from upstream
+git, fixes a threading issue where a thread could start reusing a temporary
+texture while it's still being used in rendering. (Closes: #930570)
+
+ -- Steinar H. Gunderson   Sat, 15 Jun 2019 20:08:45 +0200
+
 movit (1.6.2-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru movit-1.6.2/debian/patches/fix-temporary-texture-race-issue.diff 
movit-1.6.2/debian/patches/fix-temporary-texture-race-issue.diff
--- movit-1.6.2/debian/patches/fix-temporary-texture-race-issue.diff
1970-01-01 01:00:00.0 +0100
+++ movit-1.6.2/debian/patches/fix-temporary-texture-race-issue.diff
2019-06-15 20:08:37.0 +0200
@@ -0,0 +1,50 @@
+Index: movit-1.6.2/resource_pool.cpp
+===
+--- movit-1.6.2.orig/resource_pool.cpp
 movit-1.6.2/resource_pool.cpp
+@@ -42,6 +42,7 @@ ResourcePool::~ResourcePool()
+   for (GLuint free_texture_num : texture_freelist) {
+   assert(texture_formats.count(free_texture_num) != 0);
+   texture_freelist_bytes -= 
estimate_texture_size(texture_formats[free_texture_num]);
++  glDeleteSync(texture_formats[free_texture_num].no_reuse_before);
+   texture_formats.erase(free_texture_num);
+   glDeleteTextures(1, _texture_num);
+   check_error();
+@@ -337,7 +338,10 @@ GLuint ResourcePool::create_2d_texture(G
+   format_it->second.height == height) {
+   texture_freelist_bytes -= 
estimate_texture_size(format_it->second);
+   texture_freelist.erase(freelist_it);
++  GLsync sync = format_it->second.no_reuse_before;
+   pthread_mutex_unlock();
++  glWaitSync(sync, 0, GL_TIMEOUT_IGNORED);
++  glDeleteSync(sync);
+   return texture_num;
+   }
+   }
+@@ -449,12 +453,14 @@ void ResourcePool::release_2d_texture(GL
+   texture_freelist.push_front(texture_num);
+   assert(texture_formats.count(texture_num) != 0);
+   texture_freelist_bytes += 
estimate_texture_size(texture_formats[texture_num]);
++  texture_formats[texture_num].no_reuse_before = 
glFenceSync(GL_SYNC_GPU_COMMANDS_COMPLETE, 0);
+ 
+   while (texture_freelist_bytes > texture_freelist_max_bytes) {
+   GLuint free_texture_num = texture_freelist.back();
+   texture_freelist.pop_back();
+   assert(texture_formats.count(free_texture_num) != 0);
+   texture_freelist_bytes -= 
estimate_texture_size(texture_formats[free_texture_num]);
++  glDeleteSync(texture_formats[free_texture_num].no_

Bug#930570: garbled output when using ResourcePool from multiple threads

[Steinar H. Gunderson]

Package: libmovit8
Version: 1.6.2-1
Severity: important
Tags: upstream

Hi,

I've noticed that occasionally in multithreaded contexts (which affects
at least Nageru on certain themes, but probably also Kdenlive, given its
heavy dependency on multiple threads), Movit will show corrupted imagery,
where textures from other threads show up at random.

I've traced this down to a bug in the multithread handling. From the upstream
commit message I wrote:

> When an EffectChain is done rendering (ie., has submitted all of the GL
> rendering commands that it needs to), it releases all of the temporary
> textures it's used back to a common freelist.
> 
> However, if another thread needs a texture of the same size and format,
> it could be picking it off of the freelist before the GPU has actually
> completed rendering the first thread's command list, and start uploading
> into it. This is undefined behavior in OpenGL, and can create garbled
> output depending on timing and driver. (I've seen this on at least the
> classic Intel Mesa driver.)
> 
> Fix by setting fences, so that getting a texture from the freelist
> will have an explicit ordering versus the previous work. This increases the
> size of ResourcePool::TextureFormat, but it is only ever used in a private
> std::map. std::map is node-based (it has to, since the C++ standard requires
> iterators to it to be stable), and thus, sizeof(TextureFormat) does not factor
> into sizeof(ResourcePool), and thus, there is no ABI break. Verified by
> checking on libstdc++.

The patch is small, doesn't break the ABI, and backports trivially from
upstream git. I'll be uploading through unstable, but it will probably be
stuck behind gcc-8 like Nageru was, so I assume eventually, a testing upload
will be required if the RMs accept it.

-- System Information:
Debian Release: 10.0
  APT prefers testing-proposed-updates
  APT policy: (500, 'testing-proposed-updates'), (500, 'testing-debug'), (500, 
'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.1.2 (SMP w/40 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NO:en_US:en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libmovit8 depends on:
ii  libc6 2.28-10
ii  libepoxy0 1.5.3-0.1
ii  libfftw3-double3  3.3.8-2
ii  libgcc1   1:9.1.0-2
ii  libstdc++69.1.0-2

libmovit8 recommends no packages.

libmovit8 suggests no packages.

-- debconf-show failed