bug#39160: TeX Live 2019 wanted
Mikhail Kryshen writes: > - font files are missing from texlive-latex-lh (shouldn't it be called > texlive-lh?). Thank you, that’s a good one. Generally, the texlive-latex-* packages are of the old type that may very well be incomplete. I’ll replace this one with texlive-lh which will include all the source files as it should. Thanks for the report! -- Ricardo
bug#39161: TeX Live issues
Hi Marco, > I am unable to use LaTeX and friends. I get this error: Hmm, something broke here. I also cannot compile my older documents any more. I’ll investigate. > Can I do something to test the more modular set-up of TeX Live? I’m only using the modular set up and it appears to suffer from the exact same issue. -- Ricardo
bug#39161: TeX Live issues
texlive-latex-base provides ltluatex.lua. This file is generated from ltluatex.dtx. ltluatex.dtx contains literal tabs in the embedded Lua sources. Upon unpacking the dtx file to generate the file ltluatex.lua these tabs are erroneously converted to the string “^^I”, which breaks the lualatex tool and all other tools that derive from it. It is easy to patch ltluatex.dtx, but this will lead to rebuilding 3480 dependent packages. -- Ricardo
bug#39161: TeX Live issues
Ricardo Wurmus writes: > texlive-latex-base provides ltluatex.lua. This file is generated from > ltluatex.dtx. > > ltluatex.dtx contains literal tabs in the embedded Lua sources. Upon > unpacking the dtx file to generate the file ltluatex.lua these tabs are > erroneously converted to the string “^^I”, which breaks the lualatex > tool and all other tools that derive from it. > > It is easy to patch ltluatex.dtx, but this will lead to rebuilding 3480 > dependent packages. Done on core-updates in commit 201015b10e. -- Ricardo
bug#30756: GCC >= 6 '-isystem' and C_INCLUDE_PATH behavior changed, breaking
So what is the workaround for this bug when one wants to use gcc >= 6.0.0 with a cmake build system?
bug#39079: SBCL CFFI from Guix unable to find dynamic libraries
Hi! Konrad Hinsen skribis: > Pierre Neidhardt writes: [...] >> Try exporting LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu in the >> environment in which you run SBCL. > > Guix' ldd has been patched to ignore LD_LIBRARY_PATH, so my prediction > is that this won't change anything. ‘ldd’ is a script that simply invokes the program with LD_TRACE_LOADED_OBJECTS=1 (honored by ‘ld.so’), and Guix ‘ld.so’ does honor ‘LD_LIBRARY_PATH’, it’s no different here. Ludo’.
bug#39079: SBCL CFFI from Guix unable to find dynamic libraries
Hi Evan, Evan Straw skribis: > I am attempting to load "/usr/lib/x86_64-linux-gnu/libcurl.so.4" since > the tutorial for CFFI starts by loading libcurl. This library depends on > the following other libraries, as reported by `ldd > /usr/lib/x86_64-linux-gnu/libcurl.so.4`: That cannot work: this libcurl.so is linked against a different libc (among other things) than the ‘sbcl’ program from Guix, so trying to load it in a running Guix ‘sbcl’ is bound to fail. What would work instead is loading Guix’ libcurl.so. I suppose you could do that by removing /usr/lib from ‘*foreign-library-directories*’. HTH! Ludo’.
bug#39089: Guix System: Very long, scary boot time
Hello! Danny Milosavljevic skribis: > I think it's our job as a distribution to integrate the components properly > into > the system so that confusing stuff like that doesn't happen. > > As a first step, we could just not start a getty on tty1 when gdm is > configured > to start (see tty1 in %base-services in (gnu services base)). Then the thing > above wouldn't appear. > > The usual fix a lot of other distributions (and BIOSes) have is to display a > splash screen on top. I think that would be the better fix: add the splash screen thing (I forgot the name) to ‘%desktop-services’, but keep functional TTYs. > Because of long boot times (15 s is ALSO too long) I almost never reboot Heh same here. We should do some profiling with “bootchart” I think it’s called. I’m sure systemd does a better job that the Shepherd, in particular by starting more things on demand and doing others in parallel. We’ll get there. > I've tried booting Guix now and I took note of the following points in time: > > t = 0 s: I press the power button > t = 8 s: Grub asks for my system password > t = 45 s: Console login prompt appears > t = 55 s: GDM login prompt appears That’s roughly what I get on my laptop. (Note: Guix cannot be blamed for what happens until the kernel has booted. :-)) Ludo’.
bug#38086: RAID installation script with ‘mdadm’ no longer works
On 2019-11-12, Ludovic Courtès wrote: > Gábor Boskovits skribis: > >>> + mdadm --create /dev/md0 --verbose --level=stripe --raid-devices=2 >>> /dev/vdb2 /dev/vdb3 >>> mdadm: chunk size defaults to 512K >>> mdadm: Defaulting to version 1.2 metadata >>> [ 13.890586] md/raid0:md0: cannot assemble multi-zone RAID0 with >>> default_layout setting >>> [ 13.894691] md/raid0: please set raid0.default_layout to 1 or 2 >>> [ 13.896000] md: pers->run() failed ... >>> mdadm: RUN_ARRAY failed: Unknown error 524 >>> [ 13.901603] md: md0 stopped. >>> --8<---cut here---end--->8--- >>> >>> Anyone knows what it takes to “set raid0.default_layout to 1 or 2”? >>> >> >> On kernel 5.3.4 and above the >> raid0.default_layout=2 kernel boot paramter should be set. We should >> generate our grub configuration accordingly. So, this might be sort of a tangent, but I'm wondering why you're testing raid0 (striping, for performance+capacity at risk of data loss) instead of raid1 (mirroring, for redundancy, fast reads, slow writes, half capacity of storage), or another raid level with more disks (raid5, raid6, raid10). raid1 would be the simplest to switch the code to, since it uses only two disks. The issue triggering this bug might be a non-issue on other raid levels that in my mind might make more sense for rootfs. Or maybe people have use-casese for rootfs on raid0 that I'm too uncreative to think of? :) live well, vagrant signature.asc Description: PGP signature
