Bug#1003089: man-db has become prohibitively slow

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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

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

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

Bug#993684: plocate fails with assertion

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:

Bug#993354: zsh autocompletion files disappeared

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

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

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 /

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

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

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

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

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 */

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

Bug#988286: plocate: missing Breaks: mlocate

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.

Bug#988286: plocate: missing Breaks: mlocate

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

Bug#988286: plocate: missing Breaks: mlocate

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

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

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

Bug#986383: unblock: nageru/2.0.0-3

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

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

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)

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,

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

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,

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

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, on

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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?

Bug#977286: crash on H.264 encoding

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

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

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

Bug#918175: internal loop labels are kept as symbols

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

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)

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

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,

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)

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

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)

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,

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

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

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; /*

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

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

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)

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

Bug#976688: updatedb systemd service generates incomplete database

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

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

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

Bug#976321: plocate: generates an obsolete conffile

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

Bug#976313: new magic: plocate database

: /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

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

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

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

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

Bug#974150: Noto Mono looks completely different after upgrade

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

Bug#972758: ABI breakage without soname bump

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

Bug#972758: ABI breakage without soname bump

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

Bug#972758: ABI breakage without soname bump

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

Bug#972758: ABI breakage without soname bump

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

Bug#972758: ABI breakage without soname bump

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

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

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

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

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

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

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

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

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

Bug#933180: Patch for #933180

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

Bug#933180: Patch for #933180

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 >

Bug#933180: Patch for #933180

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

Bug#933180: Patch for #933180

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

Bug#933180: Patch for #933180

-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

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

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:

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

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

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

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

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

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

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

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

Bug#950028: nmu: nageru_1.9.1-1.1

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,

Bug#950028: nmu: nageru_1.9.1-1.1

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

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

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

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

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

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

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

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

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

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

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.

Bug#939333: varnish: VSV00003 DoS attack vector

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

Bug#832095: zita-resampler - debian bug

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

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

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.

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

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

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

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

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

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.

Bug#930756: unblock: movit/1.6.2-2

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

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

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,

<    1   2   3   4   5   6   7   8   9   10   >