GNU bug report logs - #61882
emacs-next-pgtk does not find emacs-org-roam, other path issues

Previous Next

Full log

View this message in rfc822 format

From: Csepp <raingloom <at> riseup.net>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 61882 <at> debbugs.gnu.org, Csepp <raingloom <at> riseup.net>
Subject: bug#61882: emacs-next-pgtk does not find emacs-org-roam, other path issues
Date: Sun, 15 Oct 2023 22:06:50 +0200

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:

> tags 61882 = moreinfo unreproducible
> quit
>
> Hi,
>
> Csepp <raingloom <at> riseup.net> writes:
>
>> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
>>
>>> Hi,
>>>
>>> Csepp <raingloom <at> riseup.net> writes:
>>>
>>>> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
>>>>
>>>>> tags 61882 +notabug
>>>>> quit
>>>>
>>>> I don't think notabug applies until we actually know the root
>>>> cause.
>>>
>>> Sadly I don't think there's anything actionable here until you can
>>> reproduce the problem and share the recipe with us, so I wanted to
>>> close
>>> the issue without it being marked as "resolved".
>>
>> Neither "resolved" nor "notabug" are applicable. If stalled incident
>> reports / issues are a problem, they should probably be marked as
>> stalled, or needinfo, for easy filtering. Marking it as notabug is
>> just
>> going to make the job of the next person harder when they search for
>> issues related to these symptoms.
>
> I don't think a bug as particular as 'my profile got corrupted'
> without
> any way to recreate it has much value; it's also the first time I've
> heard of such a report. That's why I'd prefer to treat it as an oddity
> and close it; if it reproduces (by you or others) let's reopen it,
> with
> fresh and clear information.
>
>> I appreciate all the work going into closing old issues, but I don't
>> think chasing a low open issue count should be a goal unto itself
>> See https://fvsch.com/stale-bots .
>
> To be clear, I wholly agree.  I've now tagged it as moreinfo and
> unreproducible.

It could be a file system bug, but while there are reports of BTRFS
being unstable in certain RAID modes, I would be very surprised if there
was a data corruption issue in the default single device mode.

My hunch is that Guix's profile update logic is not actually as atomic
as it's advertised and I interrupted it at the wrong moment.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.