IRC channel logs

2021-05-05.log

back to list of logs

<nckx>jonsger: Yes, assuming ‘file://’ was a typo (file: URLs don't support relative paths).
*nckx will not forget.
<jonsger>nckx: yeah, I always forget the 3rd / ^^
<nckx>‘Double slash in Web addresses 'a bit of a mistake'’, to quote the immortal Tim.
<iskarian>Huh, is there some reason packages like git and go are dynamically linked to compiler libraries like libgcc_s.so rather than statically linked like I'm seeing on most distributed binaries?
<u41c>Hi there
<u41c>I need some help getting grub to refresh and probe for my windows installation
<u41c>Also the package manager is unbelievably slow
<u41c>I've spent the past 30 minutes now just trying to get stuff to view my partitions
<raghavgururajan>Did 1.3.0 get merge into master or not yet?
<civodul>raghavgururajan: no, that'll probably be after the release
<raghavgururajan>Ah Cool!
***sneek_ is now known as sneek
<raghavgururajan>nckx: In your build farm, do you have have rust builds cached for c-u? If so, can you try building gtkmm in c-u and let me know if the build fails or passes?
<nckx>Alas I do not.
<raghavgururajan>Okay.
<nckx>bayfront?
<Formbi>iskarian_: maybe to save space
<Formbi>and maybe to graft stuff?
<iskarian_>Hmm, I'm not sure I buy the saving space argument, especially not when compared with the potential brittleness of setting runpath
<jorge[m]>Buenas, que browser puedo usar con licencia GPL 3 ?
<raghavgururajan>nckx: I tried bayfront, but something(s) were building somewhere. I got something like SQL is busy.
<apteryx>sneek: later tell civodul it'd be neat if 'guix describe' could show the tag in parenthesis guix describe -> guix 0d353b0 (v1.3.0rc1), or something like what git describe does
<sneek>Will do.
<raingloom>is there a way to use time-machine for commits that have errors like "%guix-register-program: unbound variable" ? (trying to bisect a chez-scheme bug)
<Noclip><nckx "Noclip: I haven't forgot. I'll "> Ok. Ping me then, otherwise I probably won't read it.
<rhou[m]><jorge[m] "Buenas, que browser puedo usar c"> el official de GNU es icecat, pero la licecia es MPL, probaste qutebrowser, tiene licencia GPL
<tissevert>Hello, guix !
<mbakke>'guix pack -f docker -S /etc=etc [...]' does not seem to work: /etc inside the container contains only "hostname hosts mtab resolv.conf"
<mbakke>ooh, '-S /etc/profile=etc/profile' works fine :)
<abcdw>hi guix!
<emacsen>hi abcdw
<devnull[m]3>Hi abcdw I've been following your videos since last year. Great format, and very nice to refer back
<emacsen>oh nice. I haven't seen this!
<kotik>Hello everyone :)
<emacsen>hi kotik
<civodul>o/
<sneek>Welcome back civodul, you have 1 message!
<sneek>civodul, apteryx says: it'd be neat if 'guix describe' could show the tag in parenthesis guix describe -> guix 0d353b0 (v1.3.0rc1), or something like what git describe does
<civodul>heheh
<abcdw>devnull[m]3: Very glad to hear it!) Thank you for kind words.
<rekado_>apteryx: I worked on this some months ago; it depended on a missing feature in guile-git
<rekado_>might no longer be missing
<civodul>rekado_: the feature is here now, thanks to mbakke
<civodul>but i think it's trickier than it sounds because we probably don't want 'guix describe' to access the Git repo
<civodul>esp. since that could trigger a full clone or checkout
<civodul>so we would need to precompute that string in 'guix pull' or similar
<efraim>isn't it already there in (guix config)
<efraim>it might need some tweaking though (define %guix-version "1.0.1.33072-1b792")
<efraim>oh, wait, that's from the git repo, my custom os-release has a better one
<efraim>VERSION="1.2.0-21.4dff6ec"
<civodul>but %guix-version is a plain commit ID in what 'guix pull' produces
<civodul>but you're right, it's probably the right place for this
<efraim>(ins)efraim@3900XT ~$ /run/current-system/profile/bin/guix --version
<efraim>guix (GNU Guix) 1.2.0-21.4dff6ec
<efraim>it's in there somewhere
<efraim>:)
<civodul>yes, that's for Guix as compiled via ./configure && make
<civodul>we're lucky enough to have two build systems :-)
<leoprikler>two build systems doesn't sound like much in 2021, especially when they're not interwoven
<karthik[m]>appimages won't run in guix?
<karthik[m]>it's not recognized
<rekado_>that’s because appimages make assumptions about the system that are not valid when using Guix System
<leoprikler>you can get them to run in guix with lots of patchelf trickery, but we usually recommend against it and for packaging
<rekado_>(e.g. the global location of the runtime linker/loader)
<tissevert>what are appimages ? the apple format ? ^^
<rekado_>no, they are an application bundle format
<tissevert>hmm like 0install ?
<rekado_> https://appimage.org/
<tissevert>thanks !
<rekado_>“apps that run anywhere”, except where they don’t
<tissevert>as always
<leoprikler>Well, that's Nix/Guix fault for being so contrarian 😉️
<leoprikler>They work on Debian *and* Fedora 😄️
<tissevert>people who publish things that work «all the time» or «everywhere» or «for all p where p is a useful parameter» certainly are very optimistic
<tissevert>leoprikler: yeah, so everywhere
<tissevert>see ? problem solved
<leoprikler>It'd really hurt if they worked on Gentoo though, since our installer currently doesn't take care of all of Gentoo's quirks.
<tissevert>I wonder what doesn't work, it seems to try to bundle everything into a directory, that could look like a directory in /gnu/store
<tissevert>wait it doesn't work on gentoo either ?
<tissevert>I saw several distro logos on the page, I assumed it was like «all known distros but those with a radically different architecture»
<civodul>packs produced by "guix pack -RR" *truly* run everywhere﹡
<leoprikler>Can confirm, tested on Guix System :)
<tissevert>I hope so
<mjw>-RR stands for Really-Relocatable ?
<tissevert>the point of guix is to be able to trace the deps so I expect it is able to put everything in a single archive
<civodul>mjw: exactly
<civodul>(we're working on -TRR, for Truly-Really-Relocatable)
<tissevert>^^
<mjw>:)
<apteryx>rekado_: haha (about “apps that run anywhere”, except where they don’t)
<tissevert>okay so appimages are a package format, would it be interesting to get an importer for this format ?
<apteryx>perhaps you meant as an output format to guix pack? It seems that should be possible
<civodul>rekado_: there are etc/committer.scm changes at https://issues.guix.gnu.org/48120; would be nice if you could review or delegate to a person of your choosing :-)
<apteryx>(disclaimer: I don't know anything about appimage)
<tissevert>no, no, I meant for guix import, like importing from hackage or cran or other soruces
<leoprikler>I don't think AppImages have any sort of usable metadata
<leoprikler>they're just binary blobs
<andreas-e>And I expect them to be just binaries.
<tissevert>oh
<tissevert>: (
<avalenn>as appimages seems to be a format of binary packages I don't see it fit for source-based Guix
<tissevert>I hoped it was like .deb archives with a certain amount of descriptions for the package
<tissevert>people like to know what they install, don't they ?
<avalenn>they don't
<leoprikler>well, .deb metainfo is not enough for an importer either, is it?
<leoprikler>also appimages aren't meant for installation IIRC
<leoprikler>it's meant to satisfy the clicky-runny folks coming from the Microsoft OS
<tissevert>oh, it's a portable click'n'run thing ?
<tissevert>^^
<civodul>appimage is a neat hack, perhaps even slightly neater than "pack -RR" (which tells a lot)
<civodul>it would be a nice target for "guix pack", for absolute neatness
<leoprikler>But how would you verify it works? 🤔️
<tissevert>I still haven't formatted my Devuan…
<tissevert>civodul: neater ? why so ?
<avalenn> https://github.com/AppImage/AppImageSpec/blob/master/draft.md
<avalenn>It seems clever indeed.
<tissevert>I see ROX mentioned
<rekado_>civodul: oh, new tricks for etc/committer.scm! I like it. I’ll review this today.
<apteryx>civodul: my 'git log' somehow sees "9bf205e5a0 (origin/version-1.3.0) gnu: guix: Update to 6fd7f16." as the last commit on the remote; but https://git.savannah.gnu.org/cgit/guix.git/log/?h=version-1.3.0 suggests otherwise. Do you have that same situation in your tree?
<rekado_>civodul: for “guix pack -RR” it would be nice to have it produce an executable; unpacking a tarball could become unnecessary.
<rekado_>e.g. a wrapper around a squashfs image, which mounts the image
<avalenn>this seems to be the AppImage approach. executable file wrap around a FS.
<apteryx>have others used Vagrant before? It's like Docker but for VM. It's able to quickly fetch and setup a VM and provide some Ruby-based DSL to provision it. Seems it'd be nifty to test our guix-install.sh script on an array of systems.
<apteryx>with the vagrant-libvirt service it can apparently use qemu/kvm
*apteryx puts it on its packaging todo list
<apteryx>civodul: about my earlier question with the state of my tree, that was a local mistake (the remote branch had been relabled locally it seems). A clean clone doesn't exhibit the problem.
<Akawama>When I run guix pull, I get 'git.savannah.gnu.org: network is unreachable'. What am I missing here?
<Akawama>I am connected to the internet.
<apteryx>I just tested with git://git.savannah.gnu.org/guix.git, it works here
<Akawama>ping also gives deatination host unreachable.
<Akawama>is it possible to get blocked?
<apteryx>here it pings OK
<Akawama>seems other devices can reach it, i will try rebooting
<Akawama>it worked ^_^
<apteryx>eh; was that on Guix System?
<civodul>apteryx: alright!
<nly>how do i install guile2-json
<civodul>hi nly :-)
<civodul>you can run "guix install guile2.2-json"
<civodul>apteryx: BTW, i see you changed the glibc-locales suggestion, which changes strings; is roptat okay?
<nly>thanks :)
<nly>hello
*civodul is in patch-review mode
<civodul>Java code compiles remarkably quickly (but runs slowly)
<roptat>civodul, it's always ok for master, but can you link to the patch if it needs to go to version-1.3.0?
<apteryx>civodul: that's on master though, no?
<civodul>/gnu/store/di7ypb61bmzwbg3qrmjp37d3qmx5myan-openjdk-11.28-jdk alone takes 1 GiB, uh
<civodul>apteryx: ah it's probably for master, my bad then!
<civodul>this string freeze thing makes me nervous :-)
<apteryx>there's one last thing I'd like to do for the VM image on version-1.3.0; and that's adding the spice-vdagent service.
***attila_lendvai_ is now known as attila_lendvai
<apteryx>civodul: good catch for the locale warning on guix substitute; that was annoying
<wonko7>hi all!
<apteryx>I'm not sure I understand why bash would through such a locale warning though; if locales were installed in the user profile?
<wonko7>I'm trying to package a program with a plugin, so I've got two things I'd like to specify as to be downloaded from a URL
<wonko7>and I've seen patches and snippets, but that's not exactly my case, I'm not sure what I should be looking for
<roptat>you can use an origin as an input
<roptat>but, probably, you want to build the program and the plugin separately, no?
<roptat>so users can choose which plugins they want?
<wonko7>no, I think that works
<wonko7>no choice in this case
<roptat>why?
<wonko7>I thought it would be simpler and I want it to work?
<wonko7>what's the correct way of doing this?
<roptat>I mean, you can certainly build both together, and that's maybe simpler, but from what you're explaining, there's a plugin system, so it's better to have one package for the program alone, and one package for each plugin, then use an environment variable to let the program know where its plugins are
<roptat>then users can install the program and chose which plugins they want or not
<roptat>to me, it sounds slightly easier to build two packages normally than have to write a new phase to decompress the second source archive, and that might not be accepted through review, unless you have a good reason to do so
<roptat>like, icedtea is made of different source repositories, and none of them really make sense to build alone (or even depend on each other), so we build them all in a single package, that's a good reason, because that's what's expected
<roptat>but in general, we try not to bundle packages together
<roptat>then again I don't know what you're packaging, so maybe there's really no choice but to build them together, it's up to you to decide which way is better for this package :)
<raghavgururajan>Hello Guix!
<wonko7>well it's for elasticsearch & a plugin I need, but that won't be accepted anyway because I'm not building from source. I get your point though, but I'm learning and hacking stuff together right now :)
<tissevert>roptat: still the same failures in fedoraproject.org for the translation
<tissevert>AFAICT their registration system is currently broken (password reset yields a 500, registering a new user doesn't work, the password just set doesn't let one in)
<mroh>wonko7: for elasticsearch, you could use https://issues.guix.gnu.org/issue/30803 as a starting/hacking point.
<apteryx>civodul: for the OPENPGP* variable updates in doc/guix.texi; it's OK to do this only on version-1.3.0 for now, right?
<wonko7>mroh: thanks, that's what I'm trying to do :)
<roptat>tissevert, mh, let me see if I can ask someone about that
<tissevert>thanks
<tissevert>their error messages aren't very useful it's just «bad credentials», which is a bit unhelpful for something you just copy-pasted ^^
<tissevert>for all I know they could handle mail adresses with a '+' in them badly
<tissevert>they apparently have a «unique mail adress» policy that prevents creating several accounts with the same adress (but the sign up form will still display a warning about the username, as if that part was already taken, which I doubt very much for a 16-long randomly generated username, and even more for 3 of them in a row)
<roptat>tissevert, can you describe the steps you took when registering your account?
<tissevert>that's what I was attempting to do in the previous lines, sorry ^^
<tissevert>do you want a more formal account ? I could send it to you on the fediverse to avoid spamming this chan even more
<roptat>just describe what you did, not what you think happened
<roptat>yeah, that'd be great
<roptat>I'm opening a ticket, so I'd like to have something to tell, more than "someone could not register" :)
<roptat>oh, and I can put you in contact with Jean-Baptiste, who manages the translation project at fedora
<tissevert>thanks
<roptat>that might even be easier than relaying your messages ^^
<roptat>tissevert, done, you should have a new mention :)
***stikonas_ is now known as stikonas
<raghavgururajan>Anyone know how to merge one branch into another? Is this better than rebase?
<andreas-e>I prefer rebasing - it keeps a linear history.
<andreas-e>Merging is like diverting a river and let the two branches flow together later.
<raghavgururajan>wip-gnome was started based-off of master. Now there are many new commits in master. So I would like to have them in wip-gnome as well. So rebase or merge? I never done either.
<raghavgururajan>andreas-e: Ah! How to do that kind of rebasing?
<andreas-e>I think Guix policy is to rebase: git checkout wip-gnome; git rebase master
<andreas-e>But it might not work, if there have been conflicting commits in the two branches.
<civodul>apteryx: by "do this", you mean revert 0f583f60f882d74f4cf2332c85343a2db67410c7 to have a single key, right?
<raghavgururajan>Thanks! I have checked-out wip-gnome as worktree. So now I just have to do `git rebase master` right?
<civodul>apteryx: ↑ this change must be done in version-1.3.0 only otherwise the manual would be wrong (until we release 1.3.0)
<andreas-e>TO be sure you are on the latest, you can do this: git fetch; git rebase origin/master
<civodul>apteryx: when we release 1.3.0, we'll merge version-1.3.0 in master and everything will be fine
<andreas-e>In case your local "master" is behind the one on the main server.
<andreas-e>Chances are there will be "merge conflicts". Then you can do "git rebase --abort" (or something similar, git makes the suggestion).
<raghavgururajan>andreas-e: Thanks! If things doesn't cleanly apply, will it ask for resolving conflicts?
<raghavgururajan>Gotcha!
<andreas-e>Then things become messy, and the emacs wizards will probably be able to tell you what to do... (I usually start with a fresh branch from master and cherry-pick from my conflicting branch, but I am not working on complex branches such as wip-gnome.)
<andreas-e>Did it work?
<wonko7>so my package fails in the install phase, can I go inspect the state of the temp work directory? I've got nothing in /gnu/tmp nor /tmp
<vivien_>wonko7, you need to pass --keep-failed
<andreas-e>raghavgururajan: So your rebase went well?
<vivien_>guix build ... --keep-failed
<raghavgururajan>andreas-e: I am working on something else at the moment, will let you know.
<wonko7>vivien_: thanks!
<Akawama>Trying to run 'guix system reconfigure /etc/config.scm' bu I keep running into this error https://dpaste.org/FbkS Please help.
<andreas-e>Akawama: I do not know. If you have enough computing power, you can always disable substitutes by adding "--no-substitutes" to your command.
<Akawama>andreas-e thanks i'll try it.
<raghavgururajan>efraim: By any chance you came across build failure of papi during your ppc work? If so, any ideas on what might be wrong?
<nly>(use-modules ((json) #:prefix json:)) look ok?
<roptat>tissevert, I think translate. and id.fedoraproject.org share some cookies, and probably want to check referer and other things...
<tissevert>ok that'd make sense
<efraim>raghavgururajan: not something I've built before, I can try it out though
<raghavgururajan>efraim: Thanks!
<raghavgururajan>efraim: I noticed papi build failure in c-u. Since I saw c-u commits in wip-ppc as well, I thought you might find the same issue there.
<efraim>looks like it might be up to a week to build out to it though
<raghavgururajan>You mean for the its deps to build?
<raghavgururajan>*for its
<efraim>yeah
<raghavgururajan>No worries!
<efraim>ok. I'll try poking it on my x86_64 machine
<raghavgururajan>:)
***iskarian_ is now known as iskarian
<iskarian>efraim, while you're around: in your gccgo > go patch from a few years ago, you suggest that go wants to be built with the gcc from the gccgo build... do you recall where you found that info (or, by trial & error)?
<efraim>Oh yeah, I meant to write back when I got back to my computer
<efraim>That was a plan for getting go working on other architectures, apparently now the way is to either use gccgo itself or to use go with gccgo as the backend
<nly>(artanis artanis) and (json) don't mix well
<wonko7>what's the equivalent of debian's libmysqlclient ?
<nckx>Morning, Guix.
<nckx>Well, ‘mysql’ sounds like a safe guess, wonko7.
***iskarian_ is now known as iskarian
<iskarian>"<efraim> ... use gccgo itself or to use go with gccgo as the backend" is this to support more architectures for the actual go packages?
<iskarian>I've got go-1.14 building with gccgo-11, using (essentially) the patch of yours I mentioned, and gc works fine, but there are some difficult errors with -compiler gccgo
<iskarian>My original question, though, was why I wouldn't want to use e.g. gcc-7.5.0 from gnu-build-system and gccgo-11 to build go.
***luke-jr- is now known as luke-jr
<wonko7>right, my question should have been: how do we get opam to see C_INCLUDE_PATH? I tried setting -I's in CFLAGS but that seems to also be ignored
<Thrilleratplay_>Quick question, hopefully. I am creating a package with a native input, how do I reference the path of this input? I want to use it as a parameter during the build package phase.
<apteryx>Thrilleratplay_: I'd grep for "assoc-ref inputs" in the code base :-)
<wonko7>Thrilleratplay_: (assoc-ref inputs "coreutils")
<Thrilleratplay_>ugh. I knew it was something obvious. Thanks.
<mekeor>why is the operating system declaration, which is also used to test guix' capability to create VMs, so configured that the bootloader targets "/dev/sdX"? why does that work? does the /dev/sdX exist? https://github.com/guix-mirror/guix/blob/master/gnu/tests.scm#L225
<nckx>mekeor: It's never used. The machinery behind ‘guix system vm’ overrides the field entirely with the correct value, but the field is mandatory so we can't omit it.
<raghavgururajan>nckx: I would like to pick your brain on this (https://issues.guix.gnu.org/issue/48028#46).
<raghavgururajan>I couldn't find any other way other than using custom versions as propagated-inputs.
<mekeor>nckx: awesome! whoo :)
<leoprikler>raghavgururajan: what about updating all of them to compatible versions?
<leoprikler>remember you're targeting c-u, so even if there's loads of rebuilds it's fine
<raghavgururajan>leoprikler: Oh hey. They are already up-to-date.
<leoprikler>so why the need to use versioned keys then?
<raghavgururajan>For some reason, latest gtkmm depends on older versions of cairomm, atkmm, pangomm
<leoprikler>is it strictly incompatible with newer ones? If so, we might want to hold cairomm atkmm and pangomm back
<nckx>raghavgururajan: If all that is true, what a mess you have to package...
<raghavgururajan>Yeah, strictly. I tried dirty hack of patching meson.build of gtkmm, to refer to latest versions of cairomm, atkmm, pangomm. Though, 'configure phase passes, 'build phase fails with *numerous* errors.
<iskarian>I've been wondering... why is it the status quo that everything on guix seems to be dynamically linked to libgcc_s.so? Is it because we expect gcc to always be installed anyway?
<leoprikler>I don't think gcc is normally installed
<nckx>raghavgururajan: Thanks for psychically answering my deleted question in detail, please continue doing so. Anyway: the other approach is to avoid propagation. I know the G-stack is a brittle mess but could we carve out a tiny island of unpropagated sanity just for this bit?
<raghavgururajan>> Thanks for psychically answering my deleted question in detail, please continue doing so.
<raghavgururajan>What?
<nckx>You know what you did. Stay out of my brain.
<raghavgururajan>> Anyway: the other approach is to avoid propagation.
<raghavgururajan>They are in requires field of .pc file.
<leoprikler>nckx is implying you have precognitive abilities.
<nckx>I know. Easier said than done I'm sure, but Mark is right that your current patchset will cause confusing errors for some users.
<nckx>It's not your fault, but it's not good.
<raghavgururajan>Yeah, true concern.
<nckx>And by confusing I mean ‘enraging’, that error is the #1 worst error.
*nckx gets called to dinner.
<leoprikler>Why do we even have newer atkmm etc.?
<leoprikler>When were those added?
<raghavgururajan>So if I de-propagate those inputs, packages that depends on gtkmm via pkg-config, gonna barf "gtkmm not found".
<raghavgururajan>Just a sec.
<raghavgururajan>They were updated as a part of #42958.
<leoprikler>IOW you created that mess on your own and didn't check whether gtkmm would correctly build?
<leoprikler>wait a sec, if you build gtkmm against older atkmm, but then inside another package use old gtkmm + new atkmm, what happens?
<ruffni>i'm unable to build a package, but in a "pure" environment it builds just fine. it's missing `math.h` even though glibc is an input. is my "pure" env not as pure as i'd hoped? did i mess up some of my env vars?
<raghavgururajan>leoprikler: That is something I am confused myself. At that time, gtkmm built fine. Not sure I was building it on wrong branch.
<raghavgururajan>Leo also tried building on his machine. It built fine.
<raghavgururajan>Now I am so confused what happened.
<raghavgururajan>just a sec.
<apteryx>civodul: ah! I just noticed that since the VM images are produced with 'guix system image', they are in *compressed* qcow2 format already. So we don't need to waste time attempting to compress them more with xz! It also makes them easier to use.
<nckx>raghavgururajan: Thanks, please let us know what happened. Also thanks for seeking feedback. I recommend, before pushing commits to one of the three ‘real’ branches (ma/st/c-u), ensuring that building everything listed by ‘guix refresh -l <affected packages>’ does not report any new build failures.
<civodul>apteryx: oh nice! how does the .qcow2.xz compare to the .qcow2?
<civodul>it'd be nice to get rid of xz there as well, more convenient
<raghavgururajan>nckx: 👍️
<nckx>raghavgururajan: If reverting the c-u updates fixes gtkmm, I think that's the way to go. There are other packages in Guix that are held back for whatever reason.
<nckx>> So if I de-propagate those inputs, packages that depends on gtkmm via pkg-config, gonna barf "gtkmm not found".
<nckx>I get that, and propagation is conventionally how we deal with that, but maybe we could find a hack way to avoid propagation just this once (like patching the .pc file, or I don't know).
*raghavgururajan thinks
<nckx>But try downgrading first. /me AFK
<apteryx>civodul: I think it's a handful of mibibytes bigger (~50 or so), on a file close to 1 GiB. I'm compressing it to see but it's taking forever on my desktop ;-)
<apteryx>roptat: the following fixes an annoying AM_GNU_GETTEXT warning: https://paste.debian.net/1196448/. Does it look reasonable to you?
<apteryx>civodul: oh, even better than this: compressed qcow2: 972 M, qcow2.xz: 940 M
<roptat>apteryx, I don't know, it looks reasonnable, but I'm not very knowledgeable about that
<apteryx>OK, it's just somewhere the macro seems hard-coded to look for 'po' directly in SUBDIRS
<apteryx>and warns about it missing otherwise
<civodul>apteryx: excellent! so yeah, let's drop .xz
<civodul>i hope roptat doesn't get mad at us though :-)
<civodul>apteryx: the extra Makefile is going to make things slower though
<civodul>"recursive makefiles considered harmful" and all
<civodul>as long as the warning is harmless, i'd rather keep it
<apteryx>civodul: I reckon the performance cost should be negligible. I think people are more likely to notice the warning than the (miliseconds?) cost of adding one makefile indirection :-)
<civodul>apteryx: i think it's noticeable (first by the number of extra lines printed by "make"), and we'd pay it each time we type "make"
<raghavgururajan>leoprikler, nckx: So libsigc++, glibmm, cairomm, pangomm and atkmm; play well with each other's latest stable version. The gtkmm is the only outlier.
<raghavgururajan>So I think it would be better to either de-propagate them in gtkmm; or use the patch as-is and remove -x.y when new gtkmm version is released. WDYT?
<bone-baboon>When a package build fails it says where to look for the build log. Where should I look for the build log when a package builds successfully?
<civodul>bone-baboon: "guix build --log-file --no-grafts the-package" will tell you where the build log lives
<bone-baboon>civodul: `guix build --log-file --no-grafts glib` says there is no build log. It has a different hash than the glib which was successfully built with `--file`. What should I use for <the-package> in `guix build --log-file --no-grafts <the-package>` for a package that was built with `--file`?
<apteryx>civodul: here's the tradeoff, basically: https://paste.debian.net/1196458/. -1 warning at configure time, +12 ms at make time, +5 lines of output at make time
<lambdanon>Hey there. I'm trying to load cl-opengl on SBCL, installed through GUIX. CFFI says I'm missing libGL.so. I try and look for libgl on guix and I don't find anything useful
<apteryx>err, https://paste.debian.net/1196461/ (the verbose output starting with fail=; \ is only seen when running with make -n)
<davexunit>lambdanon: you want the "mesa" package
<davexunit>but it's very likely there's something else wrong
<davexunit>every system has libgl on it these days
<lambdanon>Yeah, I have it in /usr/lib/x86_64-linux-gnu/libGL.so
<lambdanon>I'm running guix on debian
<davexunit>in these situations I tend to use strace to inspect what library files it is attempting to open
<lambdanon>The specific error is: Unable to load any of the alternatives:
<lambdanon> ("libGL.so.4" "libGL.so.3" "libGL.so.2" "libGL.so.1"
<lambdanon> "libGL.so")
<raghavgururajan>lambdanon: Try installing mesa via guix.
<lambdanon>Already did, but forgot to refresh profile. Relaunching a separate emacs with new profile to see if that improves matters
<raghavgururajan>Cool!
<lambdanon>same problem
<lambdanon>Now I'm getting the same problem with libsqlite
<jonsger>mbakke: for which purpose does chromium-wayland have this empty native-inputs https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/chromium.scm#n931 ?
<nckx>jonsger: Do disinherit ungoogled-chromium's, because it's really a very different beast.
<jonsger>?
<nckx>raghavgururajan: <use the patch as-is and remove -x.y when new gtkmm version is released> Would that be likely to happen before the next c-u merge?
<nckx>jonsger: ?
<nckx>It's empty because it doesn't use native-inputs, don't know what more to say.
<jonsger>ah, so it doesn't pull in the native-inputs of chromium. which are many. got it
<mbakke>indeed :)
<bone-baboon>Is their an equivalent to `--keep-failed` for builds that are successful?
<nckx>Oh, s/Do/To/, sorry.
<nckx>bone-baboon: No.
<bone-baboon>I am having trouble tracking down the test log for a successful build of glib that was built using `--file`. This is in regards to bug#48024.
<bone-baboon>I am trying to get the log for Efraim Flashner.
<apteryx>civodul, roptat what do you think of enabling SPICE for our VM on version-1.3.0? It greatly improves usability, at no extra disk space costs: https://paste.debian.net/1196464/ (tested)
<darth-cheney>hey all, anyone here have experience using guix system for doing node/npm development?
<civodul>apteryx: embarassingly i have to admin i don't use SPICE, but it sounds like a great improvement
<civodul>i say go for it!
<roptat>apteryx, I don't know about that, but no problem for string freeze :)
<apteryx>civodul: if you try it out in GNOME Boxes it comes 'for free'
<nckx>bone-baboon: Is ‘guix build glib --{no-grafts,log-file}’ not good?
<nckx>Er, --file glib.
<apteryx>civodul: or in QEMU you need the command line options detailed at the bottom of this page: https://gitlab.freedesktop.org/spice/linux/vd_agent
<raghavgururajan>nckx: That I am not sure.
<nckx>‘Removing them later’ doesn't address <https://issues.guix.gnu.org/issue/48028#68>. I share Mark's concern.
<lambdanon>Figured out how to solve my problem with foreign libraries in SBCL: (push #P"~/.guix-profile/lib/" cffi:*foreign-library-directories*)
<raghavgururajan>nckx: I just realized packages that depend on gtkmm, doesn't propagate it. So only way gtkmm, ends up in user-profiles is when explicitly installed.
<bone-baboon>nckx: That does not working for me. However I think there is enough information that I can get from my terminal scroll back. I will try sharing that and see if it is sufficient.
<ruffni>my build first does: "g++ -o fluxa/src/Sample.o [...]" and little later complains: "scons: *** [fluxa/src/Sample.o] sh: No such file or directory". does the guix build process do anything funny to .. object files? i'm sincerely puzzled
<leoprikler>raghavgururajan: I think the question is whether you can mix gtkmm and atkmm for packages even when building gtkmm against another atkmm
<leoprikler>iow if they are ABI-compatible
<leoprikler>if you can link against arbitrary atkmm, then not propagating should be fine
<raghavgururajan>leoprikler: Ah. I think that won't be an issue. If package abc depends on both gtkmm (latest) and atkmm (latest), we'll be adding both in the inputs. The pkg-config finds the correct version of atkmm as both version will be made available.
<nckx>bone-baboon: That's odd... it works here. It requires you to've built glib locally, but if you're copying build output from your scrollback I assume you've done so.
<raghavgururajan>* despite both newer and older versions being available.
<leoprikler>raghavgururajan: conflicts absolutely do happen when the user asks to "guix install gtkmm atkmm". Yes, there will be people doing that
<leoprikler>More importantly "guix environment --ad-hoc gtkmm atkmm" is a sane version of getting both inside an environment
<nckx>bone-baboon: Do you get ‘error: no build log for <DRV>’ or something more errory?
<raghavgururajan>That is true.
<raghavgururajan>I am thinking where we can make the trade-off.
<bone-baboon>Are build logs and what is output when the guix build command the same content?
<nckx>Almost.
<nckx>guix build outputs the build log + some status reports.
<bone-baboon>nckx: `guix build --log-file --no-grafts glib` says there is no build log. It has a different hash than the glib which was successfully built with `--file`.
<nckx>No, use --file there too.
<nckx>guix build --log-file --no-grafts --file=glib
<raghavgururajan>leoprikler, nckx: There are 17 packages that depends on gtkmm. So I am gonna try de-propagating inputs in gtkmm and see if those 17 packages build correctly.
<nckx>Hum, I severely doubt you'll be *that* lucky but perhaps you were kissed by a unicorn as a babe.
<bone-baboon>nckx: `guix build --log-file --no-grafts --file=<file>` outputs the location of the log. But when I try to navigate there it does not exist.
<raghavgururajan>nckx: You are right. :(
<apteryx>that appears to have been reported before: https://issues.guix.gnu.org/42902
<nckx>bone-baboon: ‘Navigate’ gives me pause (visions of buggy graphical file managers etc.), but if something like ‘bzless <full file name>.bz2’ doesn't work, that's a bug!
<nckx>If ‘guix build --log-file’ prints something, that something must exist.
<nckx>For example by transparently downloading it from the build farm first.
<bone-baboon>nckx: No graphical file manager here. I am using Emacs on a virtual terminal. When I do `C-x C-f` and try to tab complete to the location of the log I only get to /tmp/log/guix/drvs/ and then there is no match with tab completion. I double checked looking for the logs directory in /tmp/log/guix/drvs/ using Dired but it is not there (even after a buffer refresh with g). I triple checked with `ansi-term` the log file direct
<bone-baboon>there. However taking the entire location of the log from the output and pasting that into the prompt for `C-x C-f` opens the log.
<nckx>(/tmp typo local to IRC?)
<nckx>Well, assuming it's a typo and you're not rocking one custom localstatedir.
*mbakke reduced the size of python-django by some 70% :)
<mbakke>and gets reminded of https://issues.guix.gnu.org/25235 :/
<bone-baboon>nckx: Yes that is an IRC typo tmp should be var.
<mjw>wow, guix figured out everything. Thanks for that help2man hack in doc/local.mk. That is scarily clever.
<nckx>bone-baboon: Hm, C-x C-f /var/log/guix/drvs Tab Tab lists all 2-letter subdirectories here. I can further complete to an existing log file & see others along the way.
<civodul>mbakke: 70%, not bad!
<nckx>bone-baboon: C-x C-f /var/log/guix/drvs Tab Tab → just does nothing?
<nckx>70% of wha-- oh. Wow. Thanks.
<bone-baboon>nckx: On the computer in question with `C-x C-f` tab completion works up to /var/log/guix/drvs/ then when I type in 21 the next directory in the path to the log and press tab it says [No Match] in the minibuffer.
<nckx>Bizarre.