On Sun, Apr 28, 2024 at 09:35:46AM +0200, Steinar H. Gunderson wrote:
> It would probably be more useful I package v4l2proxy, which has been part
> of bmusb for a while; it would allow “anything” to go use it, although
> with some local setup. I believe Nageru is the only other
On Sun, Apr 28, 2024 at 08:22:41AM +0200, Petter Reinholdtsen wrote:
> Here is a patch for bmusb to add Appstream metainfo XML announcing the
> hardware handled by this package.
Thanks for the patch. I assume this is also suitable for upstream?
> I was a bit unsure if it should be
> attached to
. (Closes: #1066136)
+
+ -- Steinar H. Gunderson Tue, 19 Mar 2024 23:35:19 +0100
+
python-xapian-haystack (2.1.1-1) unstable; urgency=low
[ Debian Janitor ]
diff -Nru python-xapian-haystack-2.1.1/debian/patches/0002-Remove-dependency-on-six.patch python-xapian-haystack-2.1.1/debian/patches/0002
On Mon, Mar 04, 2024 at 07:34:06PM +0100, Sven Joachim wrote:
> Not really, these arches now default to a 64-bit time_t and therefore
> you get the conflicting types (suseconds_t is a long int,
> __suseconds64_t a long long int). This has nothing to do with implicit
> function declarations.
It's
On Wed, Feb 14, 2024 at 12:32:13PM +0200, Jonathan Carter wrote:
>> Fair enough, do you want to do the honor as the maintainer? Or should
>> I change the upload's version number to 24+really1.4.2~git(etc).?
> Since you made the change, I think you should own it.
I don't have the resources to do
On Wed, Feb 14, 2024 at 11:53:23AM +0200, Jonathan Carter wrote:
> Thanks for the work, although Debian policy requires consensus from
> debian-devel before bumping an epoch:
>
> https://www.debian.org/doc/debian-policy/ch-controlfields.html#version
Fair enough, do you want to do the honor as
On Tue, Feb 06, 2024 at 11:55:55AM +0200, Faidon Liambotis wrote:
>> Still required.
> I uploaded that last week, currently sitting in NEW.
Now that this is through NEW, I uploaded an NMU to DELAYED/7-day.
I see that this package is in LowThresholdNmu, but given that it
adds an epoch, I'm giving
On Mon, Jan 29, 2024 at 06:42:41PM +0200, Peter Pentchev wrote:
> Hmmm, my understanding might be wrong, but when using dh_makeshlibs
> directly without a symbols file, isn't it going to be a problem if
> a program is built against libzstd 1.5.5 and it uses the new
> ZSTD_CCtx_setFParams()
Package: libzstd-dev
Version: 1.5.5+dfsg2-2
Severity: normal
Hi,
debian/rules contains
dh_makeshlibs -plibzstd1 -V'libzstd1 (>= 1.5.5)' --add-udeb=libzstd1-udeb
Would it be possible to change it to 1.5.4? I don't see anything between 1.5.4
and 1.5.5 that would mean 1.5.5-built packages
On Sun, Jan 28, 2024 at 10:06:48PM +0100, Steinar H. Gunderson wrote:
>> - The initramfs scripts attempt to rewrite UUID= _back_ to a
>>single /dev device through probing, and give that to mount. It needs
>>to avoid doing so for (multi-device) bc
forward 1061525 https://savannah.gnu.org/bugs/index.php?65151
block 1061525 by 1060256
block 1061525 by 1060411
tags 1061525 + patch
kthxbye
On Thu, Jan 25, 2024 at 10:44:04PM +0100, Steinar H. Gunderson wrote:
> - Likewise, root= on the kernel command line must contain the U
On Sun, Jan 28, 2024 at 11:06:53AM +0100, Steinar H. Gunderson wrote:
> I'm a bit unsure how this would work; unless you manually set
> rootfstype=bcachefs on the GRUB command line, I think this is autodetected
> from fstype (in klibc-utils), which doesn't understand bcachefs right now?
Package: klibc-utils
Version: 2.0.12-1
Severity: normal
Tags: upstream patch
Hi,
fstype should autodetect bcachefs, not the least because bcachefs filesystems
may require other treatment of UUID mounts (#1060411, #1061525). I've attached
a simple patch.
-- System Information:
Debian Release:
On Wed, Jan 10, 2024 at 09:34:18PM +0100, antonio wrote:
> The problem is in the file "/usr/share/initramfs-tools/scripts/functions" and
> depends on the "get_fstype" and "resolve_device" functions that cannot locate
> or determine the file system (since bcachefs uses the form
>
On Mon, Jan 08, 2024 at 12:45:35PM +0200, Faidon Liambotis wrote:
> The bcachefs-tools package builds the C portion of the tarball, and not
> the parts written in Rust (under rust-src/). This results in a crippled
> functionality, such as the missing "mount" binary (#1057295).
I took a stab at
On Thu, Jan 25, 2024 at 10:44:04PM +0100, Steinar H. Gunderson wrote:
> - The GRUB command line must be rw, not ro; mounting with -o remount,rw
>gives: “bcachefs: bch2_parse_mount_opts() Invalid mount option errors:
>invalid selection”. I don't know if this is an upstr
Package: bcachefs-tools
Version: 24+really1.3.4-2
Severity: normal
I have / as a multi-device bcachefs filesystem (two different SSDs,
with replicas=1). Booting from it was an, well, interesting endeavor :-)
It seems the following must be done in Debian before this Just Works(TM):
- /etc/fstab
On Wed, Jan 10, 2024 at 11:51:22PM +0100, Manolis Stamatogiannakis wrote:
> But I take this as a good opportunity to learn a bit about io_uring, so
> I'll give it a shot myself. From my first experiments, it appears that the
> code is deadlocking somewhere in IOUringEngine::finish().
Anything
On Tue, Jan 09, 2024 at 07:34:56PM +0100, Manolis Stamatogiannakis wrote:
> I also gave it a shot reproducing on a RPi Zero 2, but it's either too fast
> (even with cpulimit), or the issue is architecture-specific and does not
> manifest on ARMv7.
Can I claim “this is obviously a kernel bug” and
On Mon, Jan 08, 2024 at 08:44:25AM +0100, Steinar H. Gunderson wrote:
> Doing so, thanks. I could probably see if Debian has a porterbox where I can
> reproduce this, but I'm not too optimistic (and I don't have a lot of extra
> time to dedicate to this right now, unfortunately).
There's
tag 1060217 + unreproducible
thanks
On Mon, Jan 08, 2024 at 12:01:07AM +0100, Manolis Stamatogiannakis wrote:
> So, feel free to mark this as unreproducible for now.
Doing so, thanks. I could probably see if Debian has a porterbox where I can
reproduce this, but I'm not too optimistic (and I
On Sun, Jan 07, 2024 at 08:21:35PM +0200, Manolis Stamatogiannakis wrote:
> I am trying to get plocate to run on an old ARM-based NAS running Debian
> bookworm. Building the database with updatedb works fine, but plocate
> command itself blocks forever without giving any results back.
>
> I
On Wed, Nov 30, 2022 at 12:09:56AM +0100, Steinar H. Gunderson wrote:
> Most of this logic is inherited from mlocate's updatedb, though not all.
> It may be fixable or it may not; I'd really need to check. But it really
> sounds like one should be able to stat() something without b
On Mon, Dec 18, 2023 at 04:33:26PM +0100, Chris Hofstaedtler wrote:
> I don't think there is anything you can "ask" about this.
>
> Generally the idea is that in trixie and later, --prefix=/usr really
> means that. Anything that excluded subdirs from ${prefix} should be
> a thing of the past. If
On Mon, Dec 18, 2023 at 03:28:54PM +0100, Chris Hofstaedtler wrote:
> cubemap 1.5.1-1 introduced a new file into
> /lib/${DEB_HOST_MULTIARCH}. This is diametral to the ongoing
> UsrMerge effort [1].
Can you say something about where I should get libdir from?
Some dpkg invocation?
/* Steinar */
On Sat, Dec 02, 2023 at 02:32:03AM +0100, Chris Hofstaedtler wrote:
> thank you for forwarding the Makefile changes from #1056997 to upstream.
> The upstream change works as expected.
>
> However, udev.pc will change udevdir soon. When this happens, bmusb will
> FTBFS. The upstream build system
On Mon, Nov 27, 2023 at 06:57:05PM +0100, Chris Hofstaedtler wrote:
> your package ships a udev rules file in /lib/udev/rules.d, and currently
> hard-codes this path. As part of the UsrMerge effort[1], the install
> path for udev rules must and will change soon. To pick up this change
> with a
On Mon, Nov 06, 2023 at 07:15:55PM +0100, Alain Knaff wrote:
> But then, shouldn't it keep the shorter path (if both are the root of their
> filesystem)?
There's no heuristic that will work in all cases. What is a “shorter” path
anyway; is /var/spool/tmp shorter or longer than
On Mon, Nov 06, 2023 at 06:43:33PM +0100, Alain Knaff wrote:
> Nov 06 18:33:15 hitchhiker updatedb.plocate[98659]: => adding `/home'
> (duplicate of mount point
> `/run/schroot/mount/buster-53c7e4fc-0416-4408-8421-959dc1fdaa1d/home')
So your /home is mounted in two places, and updatedb picks
On Mon, Nov 06, 2023 at 03:09:48PM +0100, Alain Knaff wrote:
> On 2 separate Debian 12 machines, I'm observing the following issue:
>
> Search for a file that obviously exists returns nothing.
>
> Running updatedb and then locate doesn't fix this.
>
> Removing /var/lib/plocate/plocate.db, and
On Mon, Nov 06, 2023 at 03:41:50PM +0100, Alain Knaff wrote:
> On the box where plocate.db is currently corrupted, /home is a btrfs.
It it by any chance a subvolume? (If so, known btrfs bug/design issue;
see the updatedb.conf man page.)
/* Steinar */
--
Homepage: https://www.sesse.net/
Source: openssh
Version: 1:9.2p1-2+deb12u1
Severity: wishlist
Hi,
MPTCP support has been available in a pull request against upstream for a while:
https://github.com/openssh/openssh-portable/pull/335
Unfortunately, upstream does not want it because OpenBSD doesn't support MPTCP.
Would it be
On Tue, Sep 26, 2023 at 05:57:03PM +0100, Alastair Sherringham wrote:
> Is a re-assignment to LXC something you do, or I do?
Anyone can do it; you probably know better than me what the package name is.
/* Steinar */
--
Homepage: https://www.sesse.net/
On Tue, Sep 26, 2023 at 04:11:12PM +0100, Alastair Sherringham wrote:
> Yes, probably something somewhere else. Maybe a library plocate uses breaks
> with "PrivateNetwork" on. I do not know enough about the internals of
> containers, namespaces or systemd to know.
No, my point is; I don't see
On Tue, Sep 26, 2023 at 02:45:43PM +0100, Alastair Sherringham wrote:
> So there seems to be a problem with the systemd "PrivateNetwork" and
> plocate inside an LXC container - which might not surprise due to LXC
> using namespace magic as well.
Hi,
Thanks for tracking this down.
To me, this
On Mon, Aug 28, 2023 at 10:10:18PM +0200, Alexandre Detiste wrote:
> It was like 1h then we cancelled with ^C.
But normally it runs through cron/systemd, and then it should be fast the
next few times?
/* Steinar */
--
Homepage: https://www.sesse.net/
On Mon, Aug 28, 2023 at 09:37:01PM +0200, Alexandre Detiste wrote:
> Microsoft's "Windows Subsystem for Linux 2" emulator
> is reusing the old/experimental '9p' filesystem
> to mount the Windows filesystems inside then Debian container.
>
> This makes plocate takes forever to index local (/remote
On Sat, Jul 22, 2023 at 05:44:56PM +0200, Stefano Rivera wrote:
> You don't have any kind of upstream bug tracker, do you?
Unfortunately not :-) Feel free to report bugs here. I've fixed this one in
upstream now, updated Debian package is on its way.
/* Steinar */
--
Homepage:
On Sat, Jul 22, 2023 at 03:40:32PM +, stefa...@debian.org wrote:
> Nope, same error with LC_ALL=C.
> Nicolas next to me (also on an AMD system running Debian unstable) hits
> exactly the same bug.
I don't have any AMD machines anymore, unfortunately, only Intel and NVidia.
(Back when I had
On Sat, Jul 22, 2023 at 04:09:26PM +0200, Stefano Rivera wrote:
> I get this crash on nageru startup (AMD box, VA-API doesn't work, but
> that's another issue).
>
> Rolling back libmovit8 to 1.6.3-5 gets it working again.
This is very weird. It seems there's a truncation somewhere:
> /* 811 */
On Wed, Jul 05, 2023 at 12:41:51PM +0200, Larsen wrote:
> ...and then output the results for all files at once, leading to the same
> behaviour as mlocate while being much faster.
Because you would have to worry about deduplication of the results,
which is nontrivial to do without incurring
On Tue, Jul 04, 2023 at 11:22:15AM +0200, Steinar H. Gunderson wrote:
>> Instead of using this:
>> locate --existing dpkg-dist dpkg-new dpkg-old dpkg-bak ucf-dist ucf-new
>> ucf-old | egrep -v
>> "dpkg-distaddfile|dpkg_dateien_vor_update_|/var/backup/burp|/root/upgra
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: mloc...@packages.debian.org
Control: affects -1 + src:plocate
Hi,
After plocate 1.1.19-2, the mlocate binary package is no longer built
(it used to be a transitional package built by
tags 1040300 + wontfix
thanks
On Tue, Jul 04, 2023 at 10:34:34AM +0200, Larsen wrote:
> with the upgrade from Bullseye to Bookworm, mlocate got replaced by
> plocate. This introduced a breaking change as there is no OR-mode anymore
> on which I rely on in scripts and commands. "apt-listchanges"
On Tue, Jun 27, 2023 at 12:49:53AM +0200, Steinar H. Gunderson wrote:
> The attached patch seems to get us halfway there; screen now combines all of
> them correctly into one cluster. However, it's still split for whatever
> reason; only if I redraw (C-a l) the flag shows up, and the text
On Mon, Jun 26, 2023 at 08:04:28PM +0200, Steinar H. Gunderson wrote:
> Is it possible to retrofit these rules? This specific rule would seem to
> hit a lot of modern emoji sequences (the Unicode Consortium seems to prefer
> using such sequences instead of defining new code points where
Package: screen
Version: 4.9.0-4
Severity: normal
Tags: upstream
Hi,
I was trying to figure out why irssi sometimes garbles the display when certain
emoji are involved in the channel topic; after some debugging, it seems the
issue
is with screen, not irssi. To reproduce, start up screen and do
On Tue, May 30, 2023 at 05:09:07PM -0400, Nick Black (Public gmail account)
wrote:
> I've been using plocate for many months on all my machines without problems.
> Recently, I get a coredump on any search, on all the machines on which I've
> tested. I've got a stack trace that points at
@@
+nageru (2.2.1-1) unstable; urgency=medium
+
+ * New upstream release.
+* Fixes several crash bugs related to video inputs. (Closes: #1034471)
+
+ -- Steinar H. Gunderson Mon, 17 Apr 2023 18:37:27 +0200
+
nageru (2.2.0-2) unstable; urgency=medium
* Remove ppc64el from futatabi's
Package: nageru
Version: 2.2.0-2
Severity: important
Tags: upstream
How to reproduce:
1. Start Nageru.
2. Connect Larix Broadcaster (or a similar app) to Nageru over SRT.
3. Nageru crashes with a message that dts > pts.
The underlying problem is that Larix defaults to 60 fps
(on phones that
On Tue, Jan 24, 2023 at 06:25:57PM +0100, Gianfranco Costamagna wrote:
> Hello, with newer toolchains the default changed to sha256 IIRC, and lld
> fails to link objects
Shouldn't this be fixed in the Debian lld package, if you can't build Debian
packages with lld? It seems a bit weird to have
tags 1027702 + pending
thanks
On Mon, Jan 02, 2023 at 10:13:59AM +0100, Jakub Wilk wrote:
> I saw this in an error message sent by cron:
>
> Hint: Try `ulimit -n 262144' or similar (current limit is 0).
>
> The number in parentheses in wrong of course.
Fixed in upstream git, so this will
On Mon, Jan 02, 2023 at 10:13:59AM +0100, Jakub Wilk wrote:
> I saw this in an error message sent by cron:
>
> Hint: Try `ulimit -n 262144' or similar (current limit is 0).
>
> The number in parentheses in wrong of course.
>
> This is likely related to these compiler warnings:
>
>
On Fri, Dec 30, 2022 at 12:33:34PM +0100, Tobias Frost wrote:
> (as announced in #1018191) I've tried to packasge 2.17 to address
> the CVE. I've rebuilt all reverse depencies successfully (except lua-apr,
> which was alredy broken before, #935271)
>
> I've prepared an NMU for libapreq2
On Fri, Dec 30, 2022 at 12:04:29PM +0100, Tobias Frost wrote:
> (I'm currently take a look at 2.17, to see if I can get it packages, if I'm
> succeeding,
> there will be an NMU announcement :))
If you are NMUing, could you orphan the package in the upload?
/* Steinar */
--
Homepage:
On Fri, Dec 30, 2022 at 11:04:46AM +0100, Tobias Frost wrote:
> I was trying to triage this CVE and *maybe* those revisions are related:
>
> r1894937 ("apreq_parse_headers: Discard CRLF of folded values.")
> r1894940 ("reindent (no functional change).")
> r1894977 ("Follow up to r1894937: Fix
On Tue, Nov 29, 2022 at 03:04:01PM -0800, Ross Vandegrift wrote:
> Interesting - stat -f does the same, and it always returns nfs. Here's
> a lame idea: /proc/mounts knows it's actually autofs...
Most of this logic is inherited from mlocate's updatedb, though not all.
It may be fixable or it may
On Tue, Nov 29, 2022 at 11:31:39AM -0800, Ross Vandegrift wrote:
>> Subject: Bug#1025099: plocate: autofs pruning doesn't seem to work
> That subject wasn't too clear- updatedb.plocate does not index the
> remote filesystem, it just triggeres the automount unnecessarily.
I don't think that's
Package: ftp.debian.org
Severity: normal
Hi,
futatabi (nageru source package) no longer has ppc64el in its
architecture list, since libluajit-5.1-dev does not exist there.
This was already fixed for nageru itself, but futatabi has stuck
around due to an error. Please rm the binary package so
On Fri, Sep 23, 2022 at 12:09:45AM +0200, Ondřej Surý wrote:
> Nope, the plan to follow upstream releases was acked by both the security
> and release teams, so I am not doing anything really surprising here.
Well, it is really surprising to users :-) Other packages that have been
doing the same
On Thu, Sep 22, 2022 at 08:13:53PM +0200, Ondřej Surý wrote:
> I am sorry this has caused inconvenience for you, but the original problem
> here was that the implicit inline-signing with the dnssec-policy was also
> problematic and causing other problems, see the upstream issue:
>
Package: bind9
Version: 1:9.16.33-1~deb11u1
Severity: grave
Hi,
After applying the security updates for DSA 5235-1, named completely breaks
and refuses to start. (This caused downtime in production for us.) The reason
seems to be that the patch includes a full minor version bump, including
On Fri, Aug 26, 2022 at 09:07:06PM +0200, Salvatore Bonaccorso wrote:
> The following vulnerability was published for libapreq2.
>
> CVE-2022-22728[0]:
> | A flaw in Apache libapreq2 versions 2.16 and earlier could cause a
> | buffer overflow while processing multipart form uploads. A remote
> |
On Wed, Jul 20, 2022 at 12:24:56PM -0700, Ross Boylan wrote:
> I had read the man page, but none of my key partitions is mounted with
> a bind option, and so the bind mount exclusion did not seem to apply.
>
> Could you add a warning, like "btrfs may accomplish a subvolume mount
> with a bind
On Tue, Jul 19, 2022 at 02:37:17PM -0700, Ross Boylan wrote:
> I installed plocate; during installation it gave messages suggesting it was
> doing a scan, although it seemed awfully quick.
>
> After I ran locate, and again it missed directories it should have found:
> locate -r "/\.hg$"
The
Package: svt-av1
Version: 0.9.1+dfsg-1
Severity: wishlist
Hi,
SVT-AV1 0.11 has been available for a while, and 0.12 is now starting the
release process. There are quality and speed improvements (as well as the
occasional API extension); would it be possible to package the newer version?
--
Package: libsvtav1-dev
Version: 0.9.1+dfsg-1
Severity: minor
Hi,
libsvtav1-dev writes:
This package provides the development files for libsvtav1dec and libsvtav1enc.
However, it does not. It provides _some_ development files (the header
files), but not _the_ development files; in fact, it is
tags 1012619 + wontfix
thanks
On Sat, Jun 11, 2022 at 12:49:09PM +0100, Ian Jackson wrote:
> I don't think "if you are bothered by this" is really right. It's
> clearly a bug, and it can cause the backups to actually fail.
If so, that's a bug on chiark-backup.
I do not intend do to put
On Sat, Jun 11, 2022 at 02:12:50AM +0100, Ian Jackson wrote:
> How do you suggest I fix #1012617 ?
I don't know how your system works (and there's no documentation that I can
find), so I'm not in a position to say much about it. (If you use
filesystem-level snapshots, PRUNE_BIND_MOUNTS would take
On Fri, Jun 10, 2022 at 01:00:17PM +0100, Ian Jackson wrote:
> The updatedb cron job reads /etc/updatedb.conf.
>
> I have a package (chiark-backup) which sometimes mounts snapshot volumes in a
> predicteable location, and which should not be scanned by updatedb.
> I don't want to edit
On Thu, Jun 09, 2022 at 10:26:15AM +0200, Paul Gevers wrote:
> We're in the process of add support for a second implemtentation of
> luajit [1] that supposedly is properly supported on IBM architectures
> (ppc64el and s390x). While I scheduled binNMU's for nageru, I noticed
> it doesn't build on
On Fri, May 27, 2022 at 04:35:27PM +0200, rollopack wrote:
> close(50) = 0
> newfstatat(51, "", 0x7ffd0628d900, AT_EMPTY_PATH) = -1 EACCES (Permesso
> negato)
So basically, there is a directory that we can open, but not stat
once open? That's a bit weird, but I
On Thu, May 19, 2022 at 08:57:35PM +0200, Paul Gevers wrote:
> reassign -6 src:nageru 2.1.0-1
Hi,
If you're doing this kind of filing, perhaps also send an email to
maintainers? All I got was a message that Nageru was marked for autoremoval
for testing (over a bug I had never heard of before),
On Tue, May 03, 2022 at 07:59:48PM +0200, Julian Andres Klode wrote:
> I fail to see how naming it @root instead of @, or @screwedup for that
> matter makes a difference.
Try it. :-)
> This is a significant regression for users coming from mlocate. They had
> working locate
No, did they not.
On Mon, May 02, 2022 at 06:47:46PM +0200, Julian Andres Klode wrote:
> It says to make / as subvolume as well, which seems incomplete, as
> mounted at / is the subvolume @ (that's the standard Ubuntu layout);
That would be to make it at @root or similar.
> updatedb needs to parse /proc/mounts,
On Mon, Apr 18, 2022 at 04:50:58PM -0400, James Cloos wrote:
> SG> This was fixed in plocate 1.1.12. ... Which version are you running?
> as i mentioned the sbc has buster, so:
>
> ii plocate1.1.8-2~bpo10+1 armhfmuch faster locate
And also, a very old kernel?
/* Steinar */
--
On Mon, Apr 18, 2022 at 03:46:21PM -0400, Ron Murray wrote:
> root@khufu:~# systemctl status plocate-updatedb.timer
> ○ plocate-updatedb.timer - Update the plocate database daily
> Loaded: loaded (/lib/systemd/system/plocate-updatedb.timer; disabled;
> vendor preset: enabled)
The postinst script
On Mon, Apr 18, 2022 at 02:34:22PM -0400, Ron Murray wrote:
>The daily update.db job for plocate is not being run. Last time it
> ran on my system was December 30, 2021. Manual updates work fine.
What does systemd say about the timer? (E.g., sudo systemctl status
plocate-updatedb.timer.)
/*
On Mon, Apr 18, 2022 at 12:32:20AM -0400, James Cloos wrote:
> the strace output ends with:
>
> openat(AT_FDCWD, "/var/lib/plocate/", O_WRONLY|O_LARGEFILE|O_TMPFILE, 0640)
> = -1 EISDIR (Is a directory)
>
> i've only seen it on arm32 buster, though.
It shouldn't end there, though; if the
On Sun, Apr 17, 2022 at 04:39:30PM -0400, Ron Murray wrote:
>Sorry, perhaps I wasn’t too clear. Running updatedb manually works fine.
>I just had to do it again. I think the only issue is the auto update.
I think that should be on a different bug, then.
/* Steinar */
--
Homepage:
On Sun, Apr 17, 2022 at 04:07:21PM -0400, Ron Murray wrote:
> I think the problem is that the cron.daily plocate job isn't being run.
> I'd suspect the systemd timer doesn't work, but I'm not sure. I'll hack
> the cron.daily/plocate script to save some diagnostic information, and
> perhaps that'll
On Sat, Apr 09, 2022 at 07:50:09PM -0400, Ron Murray wrote:
>Steinar, you may be right about problems with the upgrade. I started
> looking into this earlier today because 'locate' couldn't find files
> that I knew were present in the filesystem. Based on what you said, I
> checked plocate.db
On Sat, Apr 09, 2022 at 11:28:58AM +0200, Christoph Berg wrote:
> I had not touched plocate after it got automatically installed as
> mlocate replacement.
>
> In fact I have this problem on three different bookworm machines (out
> of 3 I use), and only on one of them I got it working after trying
On Fri, Apr 08, 2022 at 10:26:46PM +0200, Christoph Berg wrote:
> $ sudo plocate --debug myon2.jpg
> Corpus init done after 0,1 ms.
> Dictionary initialized after 0,3 ms.
> Hashtable lookups done after 0,3 ms.
> trigram 'myo' (6 bytes) decoded to 3 entries
> trigram 'yon' (26 bytes) decoded to 20
On Thu, Apr 07, 2022 at 06:36:25PM +0200, Christoph Berg wrote:
> [0] 18:29 cbe@lehmann:~ master $ sudo updatedb
>
> [0] 18:32 cbe@lehmann:~ master $ l /var/lib/plocate/plocate.db
> -rw-r- 1 root plocate 6977518 7. Apr 18:32 /var/lib/plocate/plocate.db
>
> [0] 18:33 cbe@lehmann:~ master $ l
Package: libunbound8
Version: 1.13.1-1
Severity: normal
Hi,
We were investigating a performance regression in production that crept
in at some point (we noticed by accident that something had become very slow
and started investigating). It turns out the culprit was libunbound; we do
a series of
On Wed, Mar 09, 2022 at 04:03:01PM -0800, Edmund Biow wrote:
> Thank you for the suggestion. I noticed that the output of updatedb
> mentioned my server as cifs, which is how it is mounted, but also as "type
> 'autofs'", which I didn't have installed, so I didn't consider it. I removed
> autofs
On Mon, Mar 07, 2022 at 05:12:47PM -0800, Ed Biow wrote:
> I always change the /etc/updatedb.conf file to remove cifs from PRUNEFS. The
> command works as expected on my Ubuntu systems, mostly 20.04 using the
> 0.26-3ubuntu3 of mlocate. In the past mlocate worked on Debian.
> The locate command is
On Sun, Jan 30, 2022 at 01:42:54PM -0700, Kevin Locke wrote:
> Sure thing. After re-creating the broken CIFS mount on /mnt, I ran:
>
> updatedb -o /tmp/plocate.db
> locate -d /tmp/plocate.db debian_version
Great! Thanks for testing; I'll probably push out a new version shortly.
/* Steinar */
On Sun, Jan 30, 2022 at 07:25:55PM +0100, Steinar H. Gunderson wrote:
> Yes, I wonder if this is the best fix for this specific issue.
> If there's an error, there's no performance issue, since the alternative
> is total failure; we can check /proc/mounts before deciding to crash ou
On Sun, Jan 30, 2022 at 11:10:00AM -0700, Kevin Locke wrote:
> I think the behavior is understandable in both of the above cases,
> although it's unfortunate that a flakey mount on an excluded
> filesystem at an otherwise always empty directory causes updatedb to
> fail entirely. I'm not sure if
On Thu, Jan 20, 2022 at 08:05:14AM -0700, Kevin Locke wrote:
> It turns out this the failure was due to a network issue which
> prevented contacting the host for the CIFS mount on /mnt. However,
> this presents several issues that might be worth addressing:
>
> 1. The error message contains the
On Sat, Jan 22, 2022 at 12:41:56AM +, Colin Watson wrote:
>> Technically, UTF-8 validation can be done at a few gigabytes per second
>> per core:
>>
>>
>> https://lemire.me/blog/2018/05/16/validating-utf-8-strings-using-as-little-as-0-7-cycles-per-byte/
>>
>> but that is probably
On Fri, Jan 21, 2022 at 09:48:06PM +, Colin Watson wrote:
> So the current behaviour isn't a bug as such, but there's definitely
> room for optimization here: when operating in-process, and in the common
> case where the target encoding is UTF-8, the UTF-8 to UTF-8 trial
> decoding path could
On Mon, Jan 17, 2022 at 10:46:29PM +, Colin Watson wrote:
> test_manfile (which despite the name is not a test function) calls
> find_name with file!="-" and encoding=NULL; that causes find_name to
> call get_page_encoding, which always returns something non-NULL
> ("ISO-8859-1" for English
On Mon, Jan 17, 2022 at 10:46:29PM +, Colin Watson wrote:
> Mild preference for GitLab MR comments, but I'm not that fussy.
I dropped some comments (I've never used the interface before, but it seemed
to work OK). What I haven't done is to download the patch and test
performance myself; I'll
On Mon, Jan 17, 2022 at 04:10:02AM +, Colin Watson wrote:
> Significant progress! See the end of this email.
Thanks for dealing with this. I'm deleting most of your text, but be sure
that I've read it :-) And I understand most of it (although I of course
disagree at some points, I think
On Tue, Jan 04, 2022 at 10:28:51PM +0100, Steinar H. Gunderson wrote:
> I made a straw man to test whether this was really true, and it turns it is.
> See the attached patch,
Now actually attached.
/* Steinar */
--
Homepage: https://www.sesse.net/
--- man-db-2.9.4.orig/lib/sandbox.c
+++
On Tue, Jan 04, 2022 at 10:21:58AM +0100, Steinar H. Gunderson wrote:
> I took a look at mandb's profile in perf, and even after turning off
> libseccomp, it appears that perhaps 10–11% of its time is spent doing real
> work (decompression, lexer, malloc, character set conversion).
On Mon, Jan 03, 2022 at 10:34:08PM +, Colin Watson wrote:
> This part is already covered in https://bugs.debian.org/696503. I admit
> that this was last updated ten years ago; I really need to get back to
> that and get it to work one way or another. :-/
Ah, well, that wasn't so easy to
1 - 100 of 1960 matches
Mail list logo
