Hello!
Ludovic Courtès writes:
> Maxim Cournoyer skribis:
[...]
>> It's a rather old install (late 2016 -- but kept up-to-date, of course
>> :-)) so there might be remnants from the past? How could I verify in
>> which locale the guix-daemon is running?
>
> You could check /proc/$(pidof
Hello,
Ludovic Courtès skribis:
> A simple thing would be to somehow get libssh to pass POLLIN | POLLRDHUP
> instead of just POLLIN.
Reported here:
https://www.libssh.org/archive/libssh/2019-01/000.html
A fix has been proposed by upstream and should be committed shortly.
>
I suggest your patch explain that crash involves man-db + add a link to this
discussion.
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
Correction, the file "charset.alias" is only installed for groff for glibc <
2.1 .
The code that reads charset.alias is always created.
What could possibly go wrong?
Anyway, I suggest the following minimal patch:
diff --git a/gnu/packages/groff.scm b/gnu/packages/groff.scm
index
Maybe I'm judging a bit too fast, but it seems to me that this part of the code
is rusty to the point that I wonder if getting down to understanding the hows
and the whys will ever reveal useful or enlightening at all. It's rather safe
to bet that nothing will ever depend on man-db's rendering
Hi Efraim,
Efraim Flashner writes:
> When using 'git-fetch' for the source, when a patch is applied part of
> the version number is truncated.
>
> The following derivations will be built:
>/gnu/store/zsy0j8jfg4q4nz8xk5bpc3h5qrclm679-opencv-3.4.3-checkout.drv
>
Hi Pierre,
Hi Ludo,
On Mon, 14 Jan 2019 21:27:35 +0100
Ludovic Courtès wrote:
> The ‘set_current_prefix’ logic is extremely fragile; it should readlink
> from /proc/self/exe on GNU/Linux.
>
> But in our case, no relocation happens, so we can just patch it to do:
>
> void set_current_prefix
Danny Milosavljevic skribis:
> On Mon, 14 Jan 2019 18:48:53 +0100
> Danny Milosavljevic wrote:
>
>> set_current_prefix() searches for the current program executable file in
>> $PATH,
>> and it can fail and return 0.
>>
>> In that case, relocatep will probably segfault at the location marked
Ludovic Courtès writes:
> Now I can’t find the ‘pplr’ font (actually Adobe’s Palatino).
In the texmf-dist tree these fonts are found under
“fonts/{tfm,afm,vf/adobe/palatino”. I don’t know if there are any
sources for generating these files, or if they are simply font blobs.
In the latter
You are right:
CHARSETALIASDIR=/does_not_exist
/gnu/store/fm7jlkf93bh7bw03m8hbha2b5qxjz0kz-man-db-2.8.3/bin/man nmcli-examples
also works.
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
On Mon, 14 Jan 2019 18:48:53 +0100
Danny Milosavljevic wrote:
> set_current_prefix() searches for the current program executable file in
> $PATH,
> and it can fail and return 0.
>
> In that case, relocatep will probably segfault at the location marked below:
>
> > char *relocated_path =
set_current_prefix() searches for the current program executable file in $PATH,
and it can fail and return 0.
In that case, relocatep will probably segfault at the location marked below:
> char *relocated_path = new char[curr_prefix_len + relative_path_len + 1];
> strcpy(relocated_path,
Hi Pierre,
On Mon, 14 Jan 2019 17:57:12 +0100
Pierre Neidhardt wrote:
> > (libs/libgroff/localcharset.c's locale_charset looks overly complicated,
> > WTF?)
>
> Oh dear... relocatep.cpp is not much better, here is the offending function:
>
> --8<---cut
Hi Ludo',
On 2019-01-14T01:41:16-0700, Ludovic Courtès wrote:
> Wasn’t there a message right above the backtrace?
Nothing obvious. Here's the whole thing:
https://paste.ubuntu.com/p/xRnhpGSghK/
--
Benjamin Slade - https://babbagefiles.xyz
`(pgp_fp: ,(21BA 2AE1 28F6 DF36 110A 0E9C A320 BBE8
Hi Pierre,
locale_charset, implemented in groff, uses nl_langinfo(CODESET)--and just a few
days ago we had a bug report that CP437 doesn't work there. Maybe it's related.
(libs/libgroff/localcharset.c's locale_charset looks overly complicated, WTF?)
Maybe argv[0] is still the cause, but try
Pierre Neidhardt skribis:
>> https://sourceware.org/gdb/onlinedocs/gdb/Forks.html
>>
>> this might help here.
>
> Thanks Gábor.
> So I tried the following in gdb:
>
>> set follow-for-mode child
>> set detach-on-fork off
>> run emacs
> [inferior 2 completes]
>> inferior 1
> [inferior 3
Now that we’re using Python 3.7 and this version supports hash-based pyc
files, is this still an issue? Do we need to do anything to enable
hash-based pyc compilation?
See:
https://docs.python.org/3/whatsnew/3.7.html#pep-552-hash-based-pyc-files
https://www.python.org/dev/peps/pep-0552/
Hello Pierre,
Pierre Neidhardt ezt írta (időpont: 2019. jan.
14., H, 11:42):
>
> Hmmm... Not sure how to trace that with GDB.
> I'm not sure how to handle child processes.
>
https://sourceware.org/gdb/onlinedocs/gdb/Forks.html
this might help here.
> The offending libpipeline call is
Hmmm... Not sure how to trace that with GDB.
I'm not sure how to handle child processes.
The offending libpipeline call is "pipeline_pump" in src/man.c:2329 in the
"display" function.
I'd need more time to investigate this, time which I don't have at the moment,
sorry :(
--
Pierre Neidhardt
When using 'git-fetch' for the source, when a patch is applied part of
the version number is truncated.
The following derivations will be built:
/gnu/store/zsy0j8jfg4q4nz8xk5bpc3h5qrclm679-opencv-3.4.3-checkout.drv
/gnu/store/kadg4jnyar79mpz5bmmg4w3qgn0iy81r-opencv-3.4.tar.xz.drv
--
Hi!
Maxim Cournoyer skribis:
> Ludovic Courtès writes:
> [...]
>> The wget commands above still give me the correct result, with hash
>> 101v69xp1qzw9v6pgmbhw7gfdaic8vvs4v5l567lx7f2mjp25rla.
>>
>> Are you running Guix on a foreign distro? If so, could it be that
>> guix-daemon is effectively
Hi,
Benjamin Slade skribis:
> On 2019-01-13T14:16:46-0700, Ludovic Courtès wrote:
> > Hello Benjamin,
>
> > Was there any hint before these lines?
>
> > Thanks,
> > Ludo’.
>
> Ah, yes, there's a backtrace I somehow missed:
>
> Backtrace:
> 10 (primitive-load
Hi,
Pierre Neidhardt skribis:
>> It would have the same effect as Marius’ commit
>> 296551a2e9310d4a030ee49530e9367e73aaeecf, wouldn’t it?
>
> I tested and it works! :)
>
>> My understanding, at this point, is that we need to find out why
>> ‘preconv’ segfaults, no?
>
> I'm not completely sure
23 matches
Mail list logo
