IRC channel logs


back to list of logs

<fogbugz>Hi, I have my first Guix package working (for LyX, a LaTeX editor). I'm experiencing a little glitch. It's a QT app, and icons don't load. Logs show it's looking for icons inside /home/joe/.guix-profile/share/lyx/images/label-insert.svgz instead of /gnu/store/swvf9m3cc1z299ki929fg8cgkgmlixqv-lyx-2.2.3/share/lyx/images (where they are correctly installed).
<fogbugz>Is there any obvious gnu-build-system flag i'm missing?
<fogbugz>AFAIK Nix has this broken too, here's their package
<fogbugz>And this is my early draft package:
<brendyn>fogbugz: It sounds like a common kind of Guix/Nix specific bug. Maybe download the lyx source in search for 'images/label-instert' and see how it is referenced. Maybe a patch is required to change it from a relative path to an absolute one
<brendyn>fogbugz: When you tested it, did you install it, or just run the binary from it's path in the /gnu/store?
<brendyn>fogbugz: the nix versions wraps the program. Perhaps that is required?
<fogbugz>brendyn: Sorigged into the issue a bit deeper, and the files are there. It's the correct path. But there's a symlink to cross. Maybe this is giving LyX some trouble.
<fogbugz>s/Sorigged/Sorry, I digged/g
<fogbugz>brendyn: yeah
<fogbugz>Does it make sense? I've seen some programs that have issues crossing symlinks
<fogbugz>I'm trying to find the offending LOC now.
<zacts>so can I still build my own projects on guix via ./configure; make; make install?
<zacts>or must I utilize the nix aspect of guix to build anything?
<zacts>(I don't currently have a machine to test this out with)
<zacts>I disliked NixOS due to the inability to really do ./configure;make;make install effectively
<zacts>(ruby was an issue)
<fogbugz>zacts: in nixos, i used systemd lightweight containers when I couldn't use configure/make/make install
<zacts>I like local rubies and stuff like that
<fogbugz>but i'd like to hear other emergency solutions from other, im very inexperienced
<zacts>I mean I _want_ the _ability_ to ./configure;make;make install, and I may switch to guix if I can do this
<brendyn>GuixSD is the same in that regard, because it also uses the store.
<zacts>I want most of my packages to be guix managed, but for my own personal projects and ruby I want ./configure;make;make install
<zacts>or perhaps I can learn more of how local packages work on guix
<zacts>I mean it just /feels/ really odd to not do the traditional Makefile way of installing local apps
<pkill9>does GuixSD support the open source AMD drivers?
<brendyn>Probably you would just make a simple package definition with gnu-build-system and the dependencies
<fogbugz>in general its easy to package the nix way, but it exposes some ugly hacks in some applications that make your life hard!
<pkill9>maybe you could also drop into a guix shell and run ./configure;make;make install there
<lfam>fogbugz: We have a meta-package 'gcc-toolchain' that you can use that way on GuixSD
<rekado>huh, looks my laptop screen is … burning?
<rekado>the lower right corner has become black and it smells of burnt plastic
<rekado>ACTION makes a quick backup
<str1ngs>you might have a short
<str1ngs>which is dangerous
<str1ngs>also, check fan is working.
<rekado>and the screen flickers
<rekado>fan works
<str1ngs>sound like a short, I would not mess around. you can always pull the drive
<rekado>looks like this:
<rekado>black spot has disappeared.
<str1ngs>oh black spot was dead pixels? I thought because you smelt burnt. it was burnt black. lol
<rekado>I think the backlight is dying, which leads to overheating in the backlight itself.
<rekado>and that leads to the smell.
<str1ngs>which is slightly better, then a short
<rekado>heh, I guess so
<rekado>I’m waiting for a replacement laptop since about a month
<civodul>Hello Guix!
<playX>How i can enable os-prober in GuixSD?
***pksadiq_ is now known as pksadiq
<civodul>ACTION embarks on a core-updates fixup trip
<efraim>Everytime I get an email from gnu-announce from Werner Koch I always worry what I might have done
***propumpkin is now known as contrapumpkin
<mb[m]1>GRUB fails to build on core-updates.
<ArneBab>is there a guide for making a guix package to use in guix environment?
<ArneBab>… without having to create releases?
<ArneBab>(of the package)
<ArneBab>… but with the minimal support I need to use guix pack (I’d like to use it for releases)
<ArneBab>(or at least something resembling them which avoids the need to tell others to install dependencies)
<ArneBab>^ this is at work
<ArneBab>s/at work/for tasks at new work/
<catonano>ArneBab: this package of mine is not in the guix collection but it has a guix.scm file that allows guix to build and run it
<ArneBab> (source (local-file %source-dir — nice!
<ArneBab>catonano: thank you!
<civodul>mb[m]1: i have a couple of gcc-related fixes for core-updates
<civodul>cbaines: <- yay!
<civodul>the weird thing is that i got a message saying my proposal was rejected, but i didn't propose anything in this track
<civodul>and that message as no "To:" field (how's that possible?)
<civodul>it has: X-Mailer: Apple Mail (2.3273)
<civodul>what does "FOSDEM" mean already? :-)
<mb[m]1>civodul: OK! Can you upload a new glibc while at it? Three new CVEs..
<mb[m]1>I'll try to push Python 3.6.4 as well since we're doing a full rebuild.
<efraim>here's the current CVE list as reported by `guix lint -c cve'
<efraim>... and now that i've dropped that I'm off to bed
<civodul>mb[m]1: oh nice :-/
<civodul>mb[m]1: note that these last two commits in release/2.26 are not critical as Florian Weimer wrote in 'NEWS'
<lfam>I had felt like there was a large number of recent CVE IDs piling up. `guix lint -c cve` thinks so too :(
<lfam>The fuzzers are working overtime
<lfam>Hence the surge past 4-digit identifiers
<civodul>yeah :-/
<lfam>I have a lot of weeks-old browser tabs open to MITRE
<civodul>fuzzers keep us safer and keep security businesses happy too
<lfam>It's definitely a good thing!
<civodul>even better would be to use memory-safe languages :-)
<lfam>I think that people were already fuzzing, but now some people are also getting paid to publish their findings, so we all benefit
<lfam>Yes, please
<lfam>I also have this tab open for a while now:
<civodul>"i chose to rewrite the thing in C++/CMake because it's 'modern'"
<civodul>not it's not :-)
<lfam>So we have critical codebases used *everywhere* and even their authors don't understand them well :/
<civodul>well it's always hard to understand code, even code you wrote yourself :-)
<lfam>Yes, we are constantly surpassing ourselves :)
<lfam>I'm not trying to denigrate the authors, but rather the tools that assume we are superhuman
<lfam>The task is too great!
<civodul>yeah definitely, that's what i meant too
<civodul>esp. with code where you have to keep a mental picture of the global state, heap state, etc.
<lfam>Right, it requires a huge commitment to mental discipline and even then one may fall short
<civodul>in that sense the recent message on oss-sec about "rewriting in C++ cuz it's modern" was a disappointment to me
<lfam>Was that in the discussion of GnuPG?
<civodul>lfam: yes
<lfam>That was a frustrating conversation
<lfam>The patches you sent regarding urandom-seed are number N/3, but I only got two patches. Is it just those two?
<lfam>civodul ^
<rekado>huh, is that the same Marcus Brinkmann who co-authored the Hurd critique?
<civodul>rekado: yes!
<civodul>lfam: it's ok!
<civodul>i had a third one that adds a 'default-value' field in one of these services
<civodul>not directly related to the problem at hand
<civodul>sorry for the confusion
<lfam>I've been testing the urandom-seed-service by adding some print statements and monitoring filesystem access while restarting it, but now I'm unable to stop the service
<lfam>Which is fine, it's not necessary to restart it while the system is running
<civodul>oh right, you can't really stop it now
<civodul>if you do, you no longer have a tty
<lfam>Previously, by chance, it always seemed to start after udev had created the /dev/hwrng device. I'd like to check if that is still the case. Even better if we can be sure that the udev service starts first
<civodul>oh right, we should explicitly make it depend on udev
<lfam>I'm running without KVM so I can read the console as it boots up :p
<lfam>I suspect that OpenSSH is using getrandom(), since it always seems to generate the host keys immediately after the kernel finishes initializing the CRNG
<rekado>ACTION notices that “light-weight replacement” is often used to mean “non-GNU alternative”
<civodul>rekado: is it?
<rekado>back then when I played with Arch that seemed to be the shared assumption. The same assumption seems to prevalent on HN and sites that lean towards “open source”.
<civodul>yeah GNU software is often painted as "bloated" on HN
<rekado>I haven’t performed any text mining, but I have a feeling that “bloat” and “GNU” are often used together — and “bloat” probably means “mature”.
<civodul>heheh :-)
<civodul>i think that's the case indeed
<lfam>Yes, bloat is often the accumulated bug fixes and corner cases that the lightweight replacement will also handle after ~20 years of development
<civodul>that and portability stuff
<CompanionCube>lol @ 'rewriting C++ because modern'
<CompanionCube>if you explicitly want what's considered to be 'modern' right now, y u no Rust?
<brendyn>modern means shiny stainless steal, rust means old and worn.
<civodul>CompanionCube: exactly :-)
<civodul>the message mentioned CMake/C++ as "modern", and i couldn't help but think that next month somebody would come up with Meson/Rust because "it's more modern" :-)
<CompanionCube>ACTION doesn't actually know anything about meson other than it being some build system
<civodul>it's a modern build system ;-)
<lfam>Apparently it's the future of software building
<civodul>the essence of modernness in a way
<civodul>modernity, even
<civodul>oh "modernness" seems to be a real word
<CompanionCube>lfam: which was the previous one to claim that? I don't remember
<CompanionCube>maybe google's bazel? cmake?
<lfam>I guess nobody ever figured out how to use bazel outside of google
<lfam>And since their language (go) contains its own build mechanisms, it seems unlikely that bazel will really take off
<CompanionCube>does meson actually claim any fundamental or architectural improvements or is it just CMake 2/3/x/.0?
<civodul>ACTION doesn't know
<civodul>good night/evening people!
<lfam>I don't know either, I haven't read much about it
<lfam>Just enough to know that we have to handle it in Guix