IRC channel logs
2021-11-12.log
back to list of logs
<V>lilyp: it's fine, only your most recent mention did! it's case-sensitive & I have a bunch of ignore rules :) <quidnunc>I did "guix remove <package>" but I still have symlinks in .nix-profile/bin which are overriding other directories in $PATH. Why aren't those symlinks removed when I remove a package? <rekado_>civodul: I didn’t realize there were sources, because the texlive.tlpdb doesn’t mention source files :-/ <rekado_>I don’t like to complain, but of all the upstream databases that we can import from I find the texlive.tlpdb to be the least useful. <rekado_>quidnunc: guix doesn’t touch .nix-profile <Guest79>What's the workflow for modifying guix package definitions? <rekado_>Guest79: see the Contributing section in the manual. It describes it all. <rekado_>(made with the new texlive importer that I don’t dare release) <jackhill>rekado_: one of the tlpdb maintainers gave a presentation at packaging con. It sounded like its maintained by only two people! I bet they'd be willing to collaborate on improvements, althouth I think they are constrained by the desire to support legacy systems and practices <rekado_>jackhill: I wouldn’t even know how to improve on it. <civodul>hey jackhill, i'd be curious to hear your takeaways/recommendations from the conference (i haven't been able to attend as much as i wanted) <rekado_>I’m not saying they are doing bad work; it’s just that the way texlive works and is distributed doesn’t fit at all to how we’re doing things <jackhill>rekado_: yeah :\ one thing they complained about during their talk was the loose metadata practices at ctan v. say cran <jackhill>civodul: yeah, I enjoyed it. I'll try to write up someting for -discuss@ in the next couple of days <rekado_>the tlpdb lists runfiles and srcfiles, but it’s not clear which file is generated and which is a source file that is merely copied. <rekado_>but upstream ctan is even more confusing <rekado_>the lack of conventional build systems is another big problem <rekado_>license verification is also really difficult. <florhizome[m]>someone awake and knows how to match spaces with regex . _ . <flatwhatson>florhizome[m]: like (string-match " " "hello world")? <flatwhatson>or " +" for one-or-more spaces, or " *" for zero-or-more spaces <florhizome[m]>I want to substitute this „wayfire.get_variable( pkgconfig: ˋmetadatadirˋ )“ <florhizome[m]>It’s a pattern in the packages I’m doing , has the spaces inside the parenthesis ( ... ) <flatwhatson>florhizome[m]: so put " *" in your regex at the point where zero-or-more spaces can occur <florhizome[m]>Actually works now, probably something before didn’t work. But next time I know^^ <florhizome[m]>btw, there is a new emacs – webkit Integration on GitHub (emacs–webkit), it seems way better then xwidgets. I haven’t managed to build it yet but it makes that one obsolete probably... <florhizome[m]>Personally I want to try out the imagemagick/svg and glib configure options for emacs, when I get some room (: <Noisytoot>roptat, Where is config-foreach defined in gitile? I am trying to run it, but it says it's an unbound variable and I can't find where it's defined. <roptat>Noisytoot, never heard of that before <Noisytoot>It's probably not defined because I'm using debian's packaged version which is older than guix's <Noisytoot>the base-url in the example gitile.conf includes "https://", which means that if you use that, it includes "https://" twice in the clone url <Noisytoot>because now it literally says "git clone base-url/<repo>", without replacing base-url <Noisytoot>Only a 3-line change is required to support C syntax highlighting. Should I post a link to a patch? <apteryx>hmm. our fpc package takes prebuilt binaries as inputs to bootstrap itself, IIUC. <quidnunc>rekado: Ah, thanks. Got my wires crossed <excalamus>figured out why IceCat was being funny. I'm running a separate instance of Emacs from an env where I reset HOME. If I open a link in that Emacs with an external browser... <excalamus>it doesn't see usual HOME. Now I know how to decompress Firefox book <kittyblam>Hey, anyone know where beyond the cookbook I could learn about packaging? I haven't done packaging outside of guix and am struggling to apply packaging as shown in the cookbook etc. onto real packages <singpolyma>kittyblam: reading existing packages or the output of the importers I find useful <kittyblam>singpolyma: speaking of that, its baffling me right now that <kittyblam>guix edit (I assume thats the go to for looking at these?) just loads up nano when I have everything set to nvim I thought? lol <singpolyma>Not sure, I wasn't aware of guix edit. I just have a clone of the guix get repo and read things that way <apteryx>kittyblam: it honors the EDITOR environment variable <M6piz7wk[m]>and you shall honor the EDITOR environment variable by giving it emacs as it's value <vivien>dckc[m], do you have /run/current-system/configuration.scm? <vivien>That’s the system currently configured, it’s a failure of the installer, but you can copy that one, edit it and reconfigure it <dckc[m]>how do I find the definition of a service? are they collected in the filesystem somewhere? what's the search path for modules in `configuration.scm`? <dckc[m]>in particular, the `networking` service. `guid edit networking` didn't work <vivien>dckc[m], run guix system search <keyword> ... <vivien>I don’t understand why tracker-miners can’t find its tracker dependency on core-updates-frozen <M6piz7wk[m]><vivien> "dckc, run guix system search <..." <- Regex <vivien>Now that all the matrix people are asleep, I can say that XMPP is the best <vivien>I once again forgot to prefix my mail subject with [PATCH] <vivien>I wish there were a way to hide all the noise from the matrix bridge <nckx_>M6piz7wk[m]: The bridge probably went down again spamming everyone with leaves. <nckx_>Hullo from the Libera Chat Web Chat again Guix. <M6piz7wk[m]>nckx_: blame libera.chat then :p they are the one maintaining it last time i checked <civodul>idea of the day: have (guix packages) provide a 'define-public' binding that returns its value <civodul>that would allow people to do "guix build -f foo.scm" in most cases <civodul>instead of getting an error about the unspecified value <nckx_>Clever. Sneak define-package in whilst at it. ;-) <civodul>(guix packages) already provides its own define-public actually <abrenon>I simply skip the define-public in that case <civodul>vivien: if you try, say, "guix build -f gnu/packages/idutils.scm", you get an error <abrenon>I don't need the package named in the context of its own definition <nckx_>vivien: Now people have to say '(define-public package ...) package' to use -f. <M6piz7wk[m]>what the hell is google doing again the whole invidious is hugged up <nckx_>M6piz7wk[m]: The Throttling? <M6piz7wk[m]>> Could not check out a connection in 5.0 seconds (DB::PoolTimeout) <nckx_>Yes, they sent me a mail. They are all about positivity. <M6piz7wk[m]>yay time to check the viewvideo thing that GNU preinstalled in my icecat <vivien>civodul, how would that work with a module defining several packages? <nckx_>I do not know why I'm on their list but I'm apparently an API developer. <nckx_>vivien: Last one would be the value to which the file evaluates. <civodul>vivien: it would build the last one, which is not super useful <vivien>Wouldn’t it be better to build a file-union of all the packages? <civodul>but my experience is that newcomers naturally go to "guix build -f" instead of "guix build -L ..." <nckx_>vivien: I have never wanted that, so how would one opt out? <nckx_>A new switch would be better. <civodul>vivien: i'm just thinking of a two-line change that could improve the first-time user experience, not more :-) <abrenon>that's funny because that's one of the aspect that disturbed me the most at first when I was trying to write my first local packages (and one of the reasons why it seemed a good thing to me to centralize all my local packages in a single file instead of a guix.scm per repos) <abrenon>but now that I've made my peace with it, I simply skip define-public and live my best life <civodul>there are other Schemes were 'define' returns its value <vivien>Anyway, if I want a file union, I can very well end the module with (define-public everything (file-union ...)) <dthompson>has anyone else had a difficult time with font symbols using modular texlive packages? <dthompson>I've overcome dozens of issues trying to use the modular packages, but I cannot resolve this one. <nckx_>civodul: Is that not specced? Seems like such a fundamental thing to leave up to implementations. <civodul>nckx: normally you can't get at the value of a (define ...) expression <civodul>i think R5RS says it's "unspecified", which Guile interprets as "the unspecified value" <abrenon>civodul: that wasn't intended as support ; ) rather a plea for examples without "define-public" and the simplification of terms: a package file should intuitively hold an expression of type "package" <civodul>jbv1[m]: hi! are you sure you're using the modified julia-build-system? <jbv1[m]>and I have run make in the directory <jbv1[m]>well I am using ./pre-inst-env guix build julia-bufferedstream <jbv1[m]>and I am in a "guix environment --pure guix" <civodul>jbv1[m]: ah wait, you also need to modify the procedure called 'lower' in that file <civodul>and add the new keyword argument there <jbv1[m]>aaah I also found that I was only modifying julia-build-system.scm but I also need to modify julia.scm <jbv1[m]>and that is where the lower procedure is <jbv1[m]>also lower does not have julia-package-name in its arguments (the keyword that already exists) so I guess I do not need to add julia-package-uuid there? <apteryx>when verifying sigatures with gpg the advertised signing key must be publicly disclosed somewhere trustable, right? <civodul>apteryx: no, you "just" need to make sure the key really identifies the person/organization you think it does <apteryx>civodul: hmm, so if I download some .tar.xz release from github, with the accompanying .asc file, and there's no easy way to valite the GnuPG key used to produce the signature is the intended one, the check doesn't have any value, right? <vivien>apteryx, you need to rely on the web of trust <vivien>Anyway, you can also skip the gpg signature and trust github not to be compromised. <apteryx>yeah, the later is not very enticing <apteryx>but we do in many ways already (by updating packages without manually reviewing the whole source tree) <apteryx>vivien: can you give me an example on how to rely on the web of trust in this case? the GPG RSA key fingerprint to trust is 4360FE2109C49763186F8E21EBE41E90F6F12F6D. <vivien>Well, for a start, it seems that the public key is not published on key servers. <civodul>apteryx: in practice, for source download, it's really trust-on-first-use (TOFU), unless you already know personally (physically or not) the people releasing that code <civodul>the web of trust doesn't help much since it's about validating the key/user name/email binding <civodul>as opposed to the key/identity binding, where "identity" is to be understood as the characteristics that make the person unique <civodul>like "the one person who's hacked at night to shorten the Rust bootstrap chain" :-) <vivien>Also, once the guix hash for the archive is written down, all of that does not really matter anymore. <civodul>it could be useful for post-facto authentication <mjw>also so I could buy "the one person who's hacked at night to shorten the Rust bootstrap chain" a beer (or equivalent beverage) once we can come together in person again :) <vivien>mjw, for that you must know the person name and email! <mjw>last time I tried that on my little arm laptop it gave up someway after 48 hours building 10+ rustc and llvm builds... <mjw>vivien, can't I just ask them for the key fingerprint? <mjw>heck, I probably just buy anyone who shows me some random sequence of hex digits a beer :) <apteryx>civodul: haha, thanks for the illustrated examples <mjw>I will be so happy to meet people in person again that I probably don't even care if some of the characters aren't technically hex digits :) <apteryx>mjw: eh, you should rather thank Mutabah in #mrustc :-) They're working on bootstrapping 1.54 *directly* (apparently getting close to succeed). <vivien>apteryx, if you don’t check the signature at all, noone will notice anything. <civodul>vivien: you don't actually need to know the person name: just have a chat with them about Rust bootstrapping and you'll quickly find out if they're the one who did it :-) <civodul>mjw: hey! there've been talks of applying again, but i'm not sure if that happened <apteryx>would we have an example of a package that is wholly conditional to the host/target system? <roptat>mjw, we applied for a devroom at fosdem <xelxebar>A while back, there was talk of implementing "reverse search" (file path -> package). IIRC nckx (?) was working on a prototype. Did this end up going anywhere? <mjw>roptat, nice, hope it will be accepted, it would be nice to at least see some people virtually again (we are entering a new 3 week lockdown in the Netherlands again, it feels this pandemic will never end... sniff) <roptat>yeah, we've had great success the previous years, so I don't see why they'd reject it this year :) <roptat>in any case we'll probably have a fringe event too, just for guix <apteryx>civodul: so if downloading source code is TOFU, is there any value in checking the signature? Perhaps it helps detecting corruption (the same a checksum would) ? <roptat>compared to last year, it looks like there are a bit less proportion of apps that have at least a translation, and translations are a bit more spread out (some apps are only translated in one language that is neither German nor French, the top 2) <apteryx>still thinking in that context I don't have any mean to *verify* is truly own by whom it ought to. <florhizome[m]>Does sddm refuse to load new entries for others, too? The .desktop file gets installed in the right place, I checked a hundred times by now :/ <apteryx>our 'markdown' package seems to be from 2004; is there something newer to render markdown files? <abrenon>I didn't even know there was a markdown program to perform the rendering, I use pandoc all the time and it works great ! <Guest81>I have installed GNOME desktop environment in my first Guix install, but GDM is not starting? Can someone help please? <rekado>is there something of interest in /var/lib/gdm? <sneek>Welcome back dannym, you have 1 message! <sneek>dannym, raghavgururajan says: I am re-working patches in #42958, for applying them on current c-u. <Guest81>Thank for reply! But can you be more specific? <rekado>Guest81: IIRC /var/lib/gdm is the home directory of the gdm user account. So if there are logs they should be in that directory. With the logs you might be able to figure out why GDM isn’t starting. <rekado>apteryx: core-updates-frozen looks pretty good. I’ve built almost up to pigx. There are just a few broken packages left that I will need to fix. <Guest81>Okay! Currently I'm running guix pull, I will report you after that. <rekado>apteryx: most notably: python-nbconvert, which holds up python-notebook, python-widgetsnbextension, python-ipywidgets, python-rich, and multiqc <rekado>I’m also upgrading my profile; building blender now. So far there has only been one build failure (dino), which is now fixed. <rekado>apteryx: curiously, ‘guix system build’ complains about a conflict <rekado>different variants of at-spi2-core are used due to gnome and network-manager-applet. <civodul>apteryx: for TOFU, the major risk taken is on the first check, but from there you can assert it comes from the same source <civodul>"guix refresh -u" does that: it downloads/stores the key on the first download <rekado>oof, gnome uses at-spi2-core but at-spi2-atk propagates at-spi2-core-minimal <rekado>and because of that a Gnome system cannot currently be built. <rekado>because these two variants of at-spi2-core collide. <rekado>vivien: I’ll apply this later tonight. <shtumf[m]>Hello! Does guix system create any log files at startup ? <apteryx>at least core-updates-frozen hasn't got new substitutes built in the last couple hours <Guest81>I selected GNOME in graphical installer, but on rebooting I was greeted with TTY. Did I miss a step? <Guest81>On running gnome-session, it states unable to connect to init server? <vivien>rekado has said they’ll have to go <apteryx>Guest81: just ask to the channel, if someone can they will <vivien>Guest81, I suggest you send a mail to help-guix@gnu.org if you need a more in-depth discussion <vivien>So that the context won’t be lost. <Guest81>I don't that's possible as I'm trying to installation on my one-and-only lovely machine. <mothacehe>Guest81: do you have an error message in the TTY? What kind of graphic card are you using? <Guest81>I'm using a laptop with dual graphic card: Nvidia and Intel. Now can I disable the former? <mothacehe>yeah Nvidia could cause some issues, maybe check in the BIOS if you can disable it. <Guest81>On Arch, I would just ignore Nouveau packages. <apteryx>mothacehe: hello! sorry to poke you about cuirass everytime you are around, but do you know if it's healthy at the moment? it seems to not progress much building core-updates-frozen <mothacehe>apteryx: hello! yeah the GC has been running 14 hours now on berlin <mothacehe>and there are 6k builds waiting to be fetched from workers <mothacehe>i suspect that the GC is probably deadlocked or so, there's an ancient bug report about that <apteryx>OK! So while the GC is running the build results can't be repatriated home <mothacehe>exactly, once a worker is done building it pings the remote-server which tries to fetch it with an ensure-path RPC <mothacehe>which is blocked by the nix-daemon big garbage collector lock <mothacehe>I'd like to wait some more before killing the GC to see if it's just terribly long, or stuck <Guest81>mothacehe: I don't think there is an option to remove it from BIOS. Is there a way to let Guix ignore it? <mothacehe>Guest81: yeah I think people are often tweaking the kernel command line in Grub to work around that, but I can't remember exactly <Guest81>No! For example if I can remove Nouveau package? <apteryx>civodul: re guix refresh -u, it downloads the key referred to in the (detached?) signature? <apteryx>by the way, we should really choose another key server than the one currently in use; it never response, makes the --key-server argument necessary; info '(gnupg) Dirmngr Options' says the default is now 'https://keyserver.ubuntu.com'. <Guest81>mothacehe: What if I uninstall xf86-video-nouveau? <vivien>To blacklist a module, look in your system configuration, and add (kernel-argument `(,@%default-kernel-arguments "modprobe.blacklist=nouveau")) <Guest81>And the run guix system reconfigure... Right? <vivien>Run guix system reconfigure to aply your changes to the system configuration, yes :) <Guest81>Thank! One last question, I have copied /etc/config.scm to ~/.config/guix/system.scm <Guest81>And now I will have to tweak the latter? <vivien>You tweak whichever you want, but if you have a copy you risk forgetting that it is where you put it and have diverging changes <vivien>If you put your configuration somewhere else, I suggest creating a symlink from it to /etc/config.scm <rekado>mothacehe, apteryx FYI: we might be able to order some more storage for ci.guix.gnu.org. If you have some wishes please let me know! <vivien>Oh I missed that Guest81 has left <rekado>wi might even get some SSDs to replace the spinning disks on the x86_64 build nodes. <rekado>mothacehe: civodul killed the GC twice within the last couple of days. <rekado>each time it had been running for a suspiciously long time <vivien>I suggest putting a fresh disk in there when it is full ^^ <abrenon>any reason why a java AWT application would need something more than -E DISPLAY and --share=/tmp/.X11-unix to run from a shell container (guix shell -C) ? <apteryx>rekado: the fastest thing you can get your hands on <rekado>vivien: oh, apteryx was faster with applying your patch! <Guest97>Thank you! Everything is now working. <Guest97>One last question, if guix is rolling release, then why it is still using Gnome 3.34? <roptat>gnome is hard to update properly <rekado>Guest97: it’s using Gnome 40 on a different barnch <vivien>Guest97, if you maintain the system configuration elsewhere than /etc/config.scm, delete /etc/config.scm or make it a symlink to your configuration. <rekado>that branch is *almost* ready … and is a few months overdue :) <Guest97>rekado: Thank you for your contribution! <vivien>Thank you rekado for the Boxes patch :) <rekado>(I had forgotten to also apply the second of the patches; just pushed that one, too) <rekado>regarding this at-spi2-core collision: this happens because network-manager-applet propagates gtk+, which propagates at-spi2-atk, which in turn propagates at-spi2-core-minimal. <rekado>can we avoid propagating gtk+ from network-manager-applet? <rekado>can we avoid propagating at-spi2-core-minimal from at-spi2-atk? <rekado>we’re using that -minimal variant to prevent a cycle. Maybe there’s a better way? *rekado tries to fix nbconvert now <drakonis>Guest97: try deleting the hidden gdm files btw <abrenon>is wild xhost-tweaking expected to happen before attempting such a stunt ? <Guest97>I think problem is fixed as I shifted to Intel GPU. <rekado>vivien apteryx did the appstream-glib patch cause a world rebuild? *vivien quietly hides in a corner <rekado>vivien: is it a serious problem that appstream-glib doesn’t like libsoup3? <rekado>I wonder how it manifests itself. <civodul>abrenon: i think zimoun once reported that this example no longer works <vivien>It doesn’t pass the configure step <vivien>It requires libsoup-2.4 pkg-config module <civodul>abrenon: in the "guix shell" node i came up with another example that does work :-) <vivien>And I checked, there’s no new release yet <rekado>hmm, I reverted this change locally, but there must have been something else that also caused a rebuild of glib :-/ *rekado reverts more to get back to hacking <rekado>yelp-xsl looks like a good candidate <abrenon>(because it doesn't work either without the ugly 'xhost +' quirk here) <abrenon>(which is a relief, because I really didn''t see how an additional --no-cwd could be saving the day here) <apteryx>rekado: hmm yeah, yelp-xsl looks like it? <apteryx>rekado: gnome-boxes is currently broken though, no? it needs meson-0.59, then it fails finding webkit2gtk-4.0 (pkg-config), because it wants 2.32 not 2.34 <apteryx>didn't figure out how to resolve that, and #gnome isn't useful <mothacehe>rekado: re gc: yeah also killed it a couple of times, guess we're facing a serious problem <vivien>gnome-boxes built fine before the cufbc merge :( <apteryx>does it build fine on master? master uses webkitgtk 2.34 also (built with libsoup 2 not libsoup 3) <apteryx>maybe we can pass it webkitgtk-with-libsoup2 <apteryx>that's kind of twisted though, that a package provides different flavor of itself for the same version based on the version of one of its input <rekado>we’re having a problem with simple-texlive-package <rekado>when we copy built files we’re also copying trash <rekado>so packages end up with /share/texmf-dist/build, for example, or the package archive itself in /share/texmf-dist <rekado>once we’re done with core-updates-frozen we need to take a good look at texlive <rekado>we’re close to having something good here; but it needs all the attention to details that I couldn’t afford. <florhizome[m]>Not sure if I understood this: can I load multiple profiles in userspace at once? I created a couple profiles, it definitely helps (I also remarked that it is most definitely bigger icon packages and/or fonts that slow down the „generating profile with... ) part down to a near standstill.. <jpoiret>florhizome[m]: yes! loading a profile is simply a matter of adding some profile-specific paths to your environment variables, which is taken care of by $PROFILE/etc/profile <jpoiret>the preferred way is to set GUIX_PROFILE to a profile's path, then source $GUIX_PROFILE/etc/profile <jpoiret>the reason for that is that the /etc/profile will then use your GUIX_PROFILE variable instead of the store name in order to have a more human-readable path for your env vars <florhizome[m]>I just copied over a script from the cookbook, but actually that sounds like that hmmm <florhizome[m]>Maybe that was another thing^^... Are fonts and icon caches shared between those? <lenny>hi, the bashtop package seems to be broken on my install. I installed it via `guix install bashtop` but when i start it it displays: gnu/store/vxydnyix3nrgwgf4bc531qd2r31hs4af-profile/bin/bashtop: line 65: locale: command not found <lenny>ERROR: No UTF-8 locale found! <roptat>mh, this should have been hard-coded to a store path instead... <roptat>it should work if you also install glibc in the profile <lenny>roptat: you're right "guix environment --ad-hoc bashtop glibc -- bashtop" works <lenny>It seems like it should not be that way. I would like to learn about packaging on guix anyway. should i add glibc as a dependency to bahstop and submit a patch? <roptat>no, that's not how we do it, adding a dependency (input) would not change anything. With a propagated-inputs, it would force the installation of glibc, but it's not necessary. Instead, we should have a phase that hard-codes the store path to locale <roptat>if you want to have a look, you could search for "substitute*" in existing packages <roptat>otherwise, you can simply send a bug report with what you reported, and the "fix" we found :) <lenny>Hmm, somebody else could probably fix it faster, i'll try for this evening. If i don't get it working i'll submit a bug report <lilyp>rekado, vivien: ad gnome-boxes, is there perhaps a libsoup input already to gnome-boxes itself? <lilyp>it might be, that pkg-config simply fails the lookup because of (ugh) Requires.private <lenny>roptat: can you explain why installing glibc is not necessary? <Zambyte>I actually had a very similar issue as lenny but with foot. I installed foot on a foreign distro using `guix install foot`, but I get an error saying "locale is not UTF-8". If I run the package using `guix shell foot -- foot` it does run. <roptat>lenny, usually, we replace relative calls (like "locale") with absolute filenames (like "/gnu/store/.../bin/locale"), so it helps with reproducibility (we know it's always the same glibc that's being used, and not something else from a foreign distro that might interfere), and it reduces the number of packages explicitly or implicitly added to a profile, which helps reduce conflicts <roptat>lenny, in your case, we haven't done that, so installing glibc is necessary, but we should have replaced the call with an absolute filename <roptat>the goal is that whatever happens "guix shell <foo> -- foo" will always work <Zambyte>I was able to resolve my issue with foot by running `guix install glibc-locales`. Not sure why I didn't have that already <nckx>Zambyte: <Not sure why I didn't have that already> Why do you say that? <apteryx>Zambyte: guix should have print a hint about it if it was missing <Zambyte>It seems like sort of an essential package to me; especially if I've installed things that don't work without it. The guix info page says "in foreign distros, a few additional steps are needed to get everything in place" and lists installing the glibc-locales package as one of the steps. I feel like the script to install guix on a foreign distro should already do this if it's a needed step <Zambyte>`guix remove glibc-locales foot && guix install foot` doesn't print any warning that glibc-locales is missing <zamfofex>Zambyte: Some packages might be installed on the system profile, not in your profile. <zamfofex>Zambyte: E.g. you might not even have ‘glibc’ in your profile. <zamfofex>Check e.g. ‘guix package -I’ to see all you have in your profile. <zamfofex>(That’s an uppercase “i”, not a lowercase “L”.) <Zambyte>I don't actually think I even have a system profile... `guix system list-generations` says "profile /var/guix/profiles/system does not exist" <apteryx>Zambyte: it's something that could be done, I guess, but the install script currently doesn't touch a user profile (it takes care of the system-side configuration, as root) <Zambyte>You are right that I don't have glibc and glibc-locales in my user profile (at least I didn't), but I don't think it's installed in my system profile <apteryx>I'm surprised you didn't get the hint <apteryx>in any case the locale thing is not an error but an annoying warning <apteryx>lilyp: webkitgtk + libsoup3 -> webkit2gtk-4.1.pc. webkitgtk + libsoup2 -> webkit2gtk-4.0.pc. Makes sense, no? <apteryx>I want to try using gnome-boxes with libsoup-minimal-2 and webkitgtk-with-libsoup2, but the big rebuild I caused with yelp-xsl is slowing my iteration down <lilyp>makes sense from glibs multiversioning standpoint, yeah <lilyp>but still we might want to try patching the thing to just accept 4.1 <apteryx>it fails on some VAPI failed to find xxx or GObject-Introspection is missing xxx <apteryx>the xxx was something along webkit2gtk-4.1 <lilyp>do you have a log or something to share on the Webkit part? <apteryx>lilyp: cool, it built: /gnu/store/g40g8c63nina2ls9kj2rf082m4nd2mx6-gnome-boxes-41.1 <apteryx>with libsoup2 + webkitgtk-with-libsoup2 <lilyp>the patch lgtm, but you might alternatively just '(error ...) <civodul>rekado: the texlive-translator package you provided does the trick! should i let you push? <civodul>rekado: next up i'd like "fira" and "inconsolata", but we'll need your importer superpowers <apteryx>lilyp: thanks! I find in general punching the holes explicitly in the quasiquote is less shoot-your-feet prone. <apteryx>gnome-boxes should be fixed with 9c6a1d6933 <podiki[m]>is cuirass back to building core-updates-frozen? looks like latest failed? or is that due to the gc issue earlier? <apteryx>the failed evaluation was caused by me <apteryx>but cuirass also didn't do anything for many hours due to the GC <apteryx>I pushed a small fix that should make the next evaluation proceed <vivien>Are there a collection of guidelines for how to develop guix-friendly programs? <vivien>Is there, rather (sorry for my english, it’s late here) <apteryx>lilyp: arf, now fpc says: package `fpc@3.2.2' has an invalid input: ("fpc-binary" <apteryx>I guess attempting to raise an error in there is a bad idea <podiki[m]>great, been putting off doing a guix pull on c-u-f during this big merge but will update soon to do some testing <lenny>roptat: how would i go about finding the right gnu/store/.../locale path? I think i found where the "missing" program is called <lilyp>apteryx: I somewhat agree. My personal solution would be to have some bogus empty package or origin defined where, so that the build fails with "could not find xyz" <apteryx>the original solution is to rely exclusively on supported-systems as the gatekeeper <apteryx>close to what you propose, although it'd be cleaner to have a %null-package or something for that purpose <civodul>vivien: re guix-friendly programs, no guidelines, but we'd have to think about what we'd put in there <vivien>I have a hunch that propagated inputs might cause some disaster ^^ <vivien>But then, guile is very vulnerable itself :( <lilyp>We might alternatively use an error-input, which is a gexp that raises an error when it's to be computed to a filename. <lilyp>I'm not too sure about evaluation order in this context tho <lilyp>IIRC (computed-file "does-not-exist" (error "Whoops")) is too eager, but you might want to try