<farkr>I'm very confused why guile-chickadee isn't appearing in /run/current-system/profile/share/ after I install it <nckx>farkr: How did you install it? <farkr>just "guix install guile-chickadee" on my main user account, no elevated privileges <nckx>/run/current-system/profile is your ‘system profile’, containing all the packages from your Guix System operating-system definition. Each user's profile (the one managed by ‘guix package’, ‘guix install’, etc.) is separate from that. You should find a chickadee hiding in your main user account's ~/.guix-profile/share. *nckx → very zzz, night all. <farkr>nckx: so why does GUILE_LOAD_PATH point to the system profile instead of the user one? how can I change that for my user's environment? <vagrantc>sometimes, redefining variables requires logging out and back in again ... (or setting them manually, but that's error prone) <farkr>I don't think it's a matter of having the system redefine them. I think it's just set to point to the system profile regardless. I've already rebooted after installing <mbakke>farkr: you also need to install 'guile' into your user profile to get the associated variables configured, it's a long-standing bug in guix :/ <farkr>mbakke: okay thank you. where I can I find this issue on the issue tracker? <rndd>mbakke: ohhhh, i thought this is a feature <rndd>i also have to do this for other interpreted languages ***catonano_ is now known as catonano
<apteryx>the load doesn't look weird on berlin <apteryx>any idea how come wget may fail on certs in a container where I --expose=/etc/ssl/certs ? <apteryx>from previous research, wget makes use of gnutls, which consults strictly /etc/ssl/certs for CA roots. <apteryx>guix environment is invoked with: --expose=/etc/ssl/certs --expose=/usr/bin/env --container --network <apteryx>when working, strace $wget-command |& grep -i ssl ends with: openat(AT_FDCWD, "/etc/ssl/certs/Global_Chambersign_Root_-_2008:2.9.0.201.205.211.233.213.125.35.206.pem", O_RDONLY|O_CLOEXEC) = 5 <apteryx>in the container where it fails, it ends on: stat("/etc/ssl/certs/Global_Chambersign_Root_-_2008:2.9.0.201.205.211.233.213.125.35.206.pem", 0x7fff715f0550) = -1 ENOENT (No such file or directory) <apteryx>oops, some files under /etc/ssl/certs are symlink to the store <apteryx>will need a --expose=/gnu/store I guess <MysteriousSilver>Hi! I installed Emacs from Guix (emacs-native-comp), why does it not display fonts like mentioned in .Xresources? Installing emacs from a Non-Guix package manager displays fonts fine. TIA. <apteryx>MysteriousSilver: hi! There's no emacs-native-comp in Guix proper, so you must be using a channel? <apteryx>it could be the way the package is built; I have some hack in my xsession script hacking the font size in my ~/.emacs, so that's not emacs-native-comp specific <apteryx>(I'm using the regular 'emacs' package) <apteryx>(answering my previous interrogation about certs failures in a container -- yes, the key was exposing both /etc/ssl/certs *and* /gnu/store) <jackhill>sort of sounds to me like I made a typo or other oopsie like that, but I sure can't spot it :) <jackhill>ah, found it: file-name nad sha256 should not be under uri <zzappie>anyone has a tip on what to check in case of: failed to connect over SSH to daemon at <ip> , socket /var/guix/daemon-socket/socket <zzappie>I can login into that machine via ssh and already imported guix signing key (this probably not related, not sure) ***apteryx_ is now known as apteryx
<leoprikler>okay, why tf is Guix bytecode incompatible with itself? <nly>can you run guix services on a foreign distro, like docker? <leoprikler>not easily, you can try to guix system container them or you can try to set them up in the same way as you would your foreign distro service <leoprikler>but other than that guix service is tied to Guix System <slyfox>Should './pre-inst-env guix refresh -u re2c' attempt to update files in local directory? FOr some reason it tries hard to update system-wide file: [pid 3014757] openat(AT_FDCWD, "/usr/share/guile/site/3.0/gnu/packages/re2c.scm.qilB0R", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied) <cbaines>slyfox, maybe check what ./pre-inst-env guix show re2c says for the location? <slyfox>It reports 'location: gnu/packages/re2c.scm:27:2' <slyfox>If I understand correctly it should follow %load-path, I think i have it correct: $ ./pre-inst-env guile -c '(display %load-path) (newline)' <slyfox>(/usr/share/guile/3.0 /usr/share/guile/site/3.0 /usr/share/guile/site /usr/share/guile /home/slyfox/dev/git/guix /home/slyfox/dev/git/guix) <cbaines>hmm, the guix repository should probably be first <MysteriousSilver>Hi! Fonts looked weird in emacs, installed `font-dejavu`, now emacs looks fine but chromium looks ugly. I don't know much about fonts in GNU/Linux, so what should i do? Running Guix on a non-guix operating system. <slyfox>Thank you for the pointers! I think I'll be able to figure it now. <cbaines>MysteriousSilver, maybe try installing font-liberation as well? <cbaines>also, running fc-cache -r can be useful when doing font things <cbaines>MysteriousSilver, maybe check what chromium says about fonts in the settings <slyfox>./pre-inst-env adds '.' to PATH where local `guile` is present. That unsets GUILE_LOAD_PATH / GUILE_LOAD_COMPILED_PATH and reverts the effect of pre-inst-env prepends. <slyfox>I think it's only intended to be used for non-pre-inst-env cases <MysteriousSilver>cbaines: The websites look fine, only the tabs, extensions menu, settings, menu bar etc look different. The settings don't say anything about them. <cbaines>MysteriousSilver, hmm, which desktop environment are you using? <cbaines>Ok, maybe check in the Gnome Tweaks app what the font settings are <cbaines>I've got Cantarell in different variants selected for most options <MysteriousSilver>cbaines: Running chromium from terminal says: `Fontconfig error: Cannot load default config file` <cbaines>all I know unfortunately is that I don't see that error <nckx>tissevert: I missed something: whence the version ‘1.0.0beta’ in your vim-solarized patch? I can't find it in the source or GitHub page. <karthik[m]>i cloned guix source code, added `gnome-help` build code gnome.scm. How can i specifically build that part? please help <leoprikler>karthik[m]: after bootstrap...make run ./pre-inst-env guix build gnome-tour <tissevert>I picked a later commit because there were changes on the vim files and that seemed to matter <tissevert>I supposed the tag was about fundamental design decision made on the color theme itself and then later the developer realised the vim implementation didn't reflect them and pushed the changes there as well ? <karthik[m]>leoprikler: i didn't get your instructions, what do you mean by bootstrap? <tissevert>this is really very confusing and somehow I feel I'm not the only one tormenting herself when tagging releases of my software <tissevert>no, exactly, the «vim-only» version doesn't have any release tag <leoprikler>karthik[m] inside your local guix checkout, first ./bootstrap, then ./configure (don't forget about localstatedir) and then make <tissevert>why wouldn't the prefix 'v' be correct ? is the version we use in Guix package a «guix thing» and not the will of the original developer ? <nckx>I'm confused as well. So we had the vim-scripts repo, which is downstream from altercation/vim-colors-solarized, which is downstream from altercation/solarized, but all implicitly follow the same versioning scheme? Can we be reasonably sure of that? <nckx>tissevert: ‘v’ isn't part of the version number, it just means ‘version’. <nckx>‘Version v1’ makes no sense. <nckx>So you can omit it here. <tissevert>yeah I know it just means that, but it's my fault some people decide to name their versions that way <tissevert>(some redundancy is sometimes useful : «p312» ? no, it can't be a version of my software, my versions follow the following pattern : «v[0-9]+.[0-9]»…) <tissevert>anyway, I think that answers my question: versions shouldn't be the version chosen by the packager but a guix-normalized representation of it <nckx>I don't really understand the problem. Guix has many packages with ‘v’ git tags. It's just not part of the version field. <tissevert>not a problem, I'm just trying to learn something here like a rationale so I can be a little more indenpendent and take less of guix' time next I try and make a package : ) <nckx>‘1.0.0beta1’ is the version chosen upstream, ‘v1.0.0beta1’ their corresponding git tag. Anyway. Not worth philosophising about. <tissevert>(I'm begining to appreciate the benefit of a «quick'n'dirty» local package that only has to «just work» ^^) <nckx>‘This is confusing, let's add a fourth repo.’ <tissevert>«there are too many standards, we need a new one !» <nckx>This last one is a modified variant, though. Which is fine, but then we should package it as ‘vim-solarized-lifepillar’ or so. <phireh>Hello! Guix noob here, I have problems making pkg-config find anything at all. Is there a magic value I should set PKG_CONFIG_PATH or pc_path to? Ty in advance <nckx>Oh, ‘solarized8’ is the name, never mind. *tissevert is going to ditch vim, learn emacs and never worry about colorschemes ever again <nckx>tissevert: As a vim-nonbeliever I'll happily defer to your judgment on which of the two to choose. Which do you prefer? Someone else can always add the other one. *nckx had literally just finished touching up the original patch. <nckx>Which, apart from needing a commit message matching our norms, was perfect. <tissevert>I'm not sure I really qualify to judge something like a colorscheme, not even sure I'd know the difference… <tissevert>honestly I just wanted a readable syntax coloring, I stumbled upon solarized a couple years ago and had been happy with it up to know without asking myself too many questions about it (less again about packaging it) <nckx>I don't know what bullshit solarized8 is talking about. <tissevert>I don't either but I had thought it could be somehow adjacent to your original critical stance regarding the description I had copy-pasted <vldn>mhh i thought a saw somewhere on github or gitlab a script to install guix system over a exisiting linux installation <vldn>like moving all from "/etc" before installation to trash and something.. someone knows where i could find it? <nckx>tissevert: Oh, I'm not critical of the project, my gustibusses just don't like the colours. Nothing more. *tissevert notes the emacs-solarized package is base on yet another repos that claims to have ported it to emacs (even though the original repos now features an emacs theme) <tissevert>what color scheme do you use ? honestly I'm curious about good recommendations <nckx>(I'm just going to commit your last patch 😉) <nckx>It's common to fix up minor things like that on the author's behalf. If you'd rather submit a new patch that's fine too, but it's not expected. <nckx>tissevert: I'm a very basic boy. I use ‘Leuven’, one of the default colour schemes included with Emacs. <tissevert>I thought I had you distracted over all this and you had forgotten about your original 'v' remark <nckx>You can't prove that you did and I only remembered at the last minute. <tissevert>oh, Leuven is pretty neat too, too bad there isn't a port of this scheme for vim ^^ <nckx>Can I just change it to 528a59f26d12278698bb946f8fb82a63711eec21? <tissevert>no, you're right, I meant to change the source to the main one <nckx>‘That commit’ here being 62f6. <nckx>Maybe you'd changed your mind. <tissevert>it was part of your remarks, that it was preferable to retrieved the whole 30M even for a tiny vim script because it was closer to the source and colud be useful for other packages <tissevert>I searched altercation/solarized to find the commit, and forgot to change the git-reference url <nckx>No problem. Guix being (relatively) content-addressed can be confusing. It treats the commit as authoritative, not the URL, and it managed to find that commit elsewhere so it built fine. <tissevert>that's kind of wonderful and scary at the same time <tissevert>how did you notice it was retrieving it like that and not the expected way ? <tissevert>(I ran the built, it built, I was happy with that) <nckx>Not very comforting, no. <nckx>tissevert: Does Vim call them ‘themes’, ‘colour schemes’, or something else? <nckx>Never mind. ‘This package provides the Solarized color scheme as a Vim theme.’ will have to do. <ekaitz>nckx: they are called colorscheme inside vim <nckx>(The description was too generic otherwise.) <ekaitz>in fact, the command to change between them is :colorscheme <nckx>ekaitz: Oh, thanks. I'll adjust it. <ekaitz>well, now i'm reading the documentation... the command is :colorscheme but the concept is, of course, separated: color scheme <nckx>Oh good. ‘colorscheme’ hurt to write. <ekaitz>(i'm not a native english speaker so everything is ok to me) <ekaitz>tissevert: it's the only editor I use <tissevert>what color scheme (^^) do you use ? I was curious to see that solarized wasn't packaged yet and I wondered if there was a good reason for it <ekaitz>well I use dracula color scheme but i don't install vim packages from guix but from vim's Vundle <ekaitz>so I have no idea why is not packaged yet in guix <tissevert>(like I said above, I'm not very knowledgeable about colors, plugins or anything, so I would expect «solarized» to be quite mainstream since even I heard about it) <ekaitz>I suppose we need someone to package it ;) <nckx>‘vim-solarized@1.0.0beta1-1.62f656a: can be upgraded to 1.0beta [from 1.0.0beta1]’ -- when you manage to confuse even poor ‘guix lint’. Fuck it, pushed. Thank you tissevert! :) <tissevert>yeah, sounded reasonable, I was just very suspicious for a long time I had missed something obvious <tissevert>nckx: thanks for all your help and patience ! <cbaines>I'm trying to update the guix package, but the challenge tests seem to hang for me :( <tissevert>oh, guix lint thinks 1.0beta is a later release ? <nckx>tissevert: Seems so. TBH I wouldn't be able to tell which is later blindly either. <nckx>This whole ordeal certainly proved Phil Karlton right. *tissevert deletes a package in ~/GUIX/homemade/gnu/packages/homemade.scm : ) <nckx>tissevert: ‘There are only two hard things in Computer Science: cache invalidation and naming things, and off-by-one errors.’ <nckx>Someone else added the 3rd. <nckx>Also, off-by-one errors. <tissevert>now seriously, did I pick the worst package possible to start ? should I consider doing something else than attempting to package things for guix ? was the issue something entirely different ? <tissevert>I didn't mean to wast so much of everyone's time for a mere theme that perfectly worked for me locally : / <nckx>No. I think you chose a good package. I normally would have pushed it and simply sent a mail with ‘I changed this & this & this, pushed, thanks!’ (as the one you've just received), but the confusing upstream situation & my lack of Vim background slowed things down a lot. <tissevert>ok, that's understandable, I see that emacs is really a central tool in the making of Guix <tissevert>and I haven't been very fast to answer your original mail, sorry about that <nckx>There are Guixers that use Vim. I don't use any of Emacs' power features or extra packages. You should be able to happily contribute to Guix from Vim. <tissevert>(I don't mind if I grasp a few things about emacs in the process, though) <leoprikler>The most important Emacs package for Guix is yasnippet :) <tissevert>leoprikler: I really have no idea what yasnippet is <tissevert>even reading guix search about it, it's very obscure <leoprikler>It's just snippet expansion, nothing more, nothing less. <tissevert>but why do you find it so important ? (yeah, I noticed the smiley, but still it looks like there's a story behind it, isn't there ?) <leoprikler>the package... snippet provided in etc/snippets gives you all the boilerplate you need to get started when packaging <tissevert>ahhh the things I'll need when I'll write *real* packages ^^ *tissevert makes a mental note to remember it one day <OriansJ>tissevert: all packages are *real* packages <OriansJ>even a badly written package definition for something that hasn't been packaged yet is measurable progress and paves the way for everyone else <OriansJ>although please actually test before sharing, otherwise one ends up with packages that build just fine but don't actually work (like meld) <tissevert>OriansJ: sure (I had been testing vim-solarized for a couple weeks when I submitted my patch) <leoprikler>how do I tell a fairly standard package using gnu-build-system and libtool to produce shared libraries instead of static ones? <OriansJ>tissevert: /gnu/store/1sqjpr9irxdg3d4d384sfyj0467wiq45-meld-3.20.3 is a broken build of meld if you wish to know the specific one that had the issue <tissevert>hmm I have never installed it and don't have this particular build <nckx>(I should know, nobody seem's to've touched it after me.) <nckx>OriansJ: If you have a specific problem with Meld, please report! <nckx>leoprikler: I didn't find it on berlin or bayfront. Did you have it locally? <OriansJ>nckx: sure here is the report (without a fix because I haven't had time to generate yet) meld when given 2 files to compare exits with "Couldn’t find colour scheme details for meld:insert-background; this is a bad install" <nckx>leoprikler: OK, that's the same one I have. <nckx>And how is that related to a lack of testing by whoever added Meld to Guix? <nckx>leoprikler: /gnu/store/*-meld-*/bin/meld should work. <OriansJ>nckx: because just running meld without file arguments loads just fine but giving it 2 files results in the crash (a common usage pattern for the tool) <davidl>as the root user I am apparently not allowed to use -D option when running sudo - how come_ <leoprikler>there are times when software only launches through guix environment <nckx>leoprikler: It wasn't hypothetical :) <leoprikler>hmm meld itself starts fine, but when it's asked to compare, it crashes <nckx>OriansJ: Obviously not as common as you think, nor does every package need to be fuzz tested. It presumably worked when added (I didn't dig), in the way the packager used it. That's enough. The rest is bug reports. <nckx>leoprikler: Is it possible that the bug is actually in your (plural) environments? <nckx>Otherwise I don't see why my build of the same Meld hash would be magically immune. <nckx>And I'm not, which is why I'm suspicious. <nckx>Both from the UI and with 2 arguments. <nckx>/gnu/store/m7vzq2qr3cbb277fccsljgwgfl7q1dxc-meld-3.20.3 <nckx>(Not that that should matter, but just to point out I've not been blessed by the GNOME runtime fairy.) <nckx>I can't get it to misbehave as ‘guix environment --ad-hoc meld -- meld’ either 🤷 <OriansJ>nckx: it is entirely possible it may be related to my setup. Hence why I tend not to report bugs until I also have a fix. <nckx>That's super-appreciated. <leoprikler>Interestingly it doesn't even work with --pure -E XAUTHORITY <nckx>Just don't hesitate to report bugs if you don't have time for a fix. <nckx>It's better than vague ‘lol that meld package am i right’ insinuations that are less universal than you might think. <nckx>leoprikler: Do you get the same error as OriansJ? <OriansJ>nckx: completely fair, however I did get tired of the "lol just use substitutes" <nckx>OriansJ: I agree that that's an unacceptable answer. <nckx>I'm now desperately trying to break a working package. Feels mean. <nckx>I'm sure --pure will break something, because gnomes, let's see what. <leoprikler>"Hello, I'm Meld, a GNOME package, let me be broken in GNOME." <nckx>Suspiciously weird, surely it needs gsettings-conf-daemon-gtk or something. <nckx>Same hash, no other commands work & ‘env’ doesn't look completely insane (thought maybe ‘guix env --pure’ had broken on me), … <apteryx>installing with the root partition on LVM is now supported, right? *nckx was just reading that but got distracted by the heuristic comment. <nckx>So it really crashes/exits, it doesn't just (say) show useless white text on a white background, looking broken? <nckx>I got it to do that while commenting out stuff trying to find your broken code path, but that's hardly fair. <apteryx>I guess I'll know if I write a system test; there's already one for home on LVM, but not root on LVM <vldn>*-bash-minimal-5.0.16/bin/sh: cc: command not found :( <vldn>what do i need to add to my package definition <nckx>This doesn't feel like an effective use of my time. Guessing what could go wrong in an environment with which I'm very unfamiliar. <nckx>vldn: Probably ,(string-append "CC=" (cc-for-target)) *somewhere*, for example (and in order) #:configure-flags, #:make-flags, or even setenv in a phase before 'configure, depending on your package's build system. <nckx>For native builds, that code is equivalent to simply setting CC=gcc. <nckx>Some broken packages don't honour $CC and need patching, but they are not common. <leoprikler>pdb things I'm joking when I call set_trace, it seems <vldn>(arguments '(#:make-flags ,(string-append "CC=" (cc-for-target))) <leoprikler>nckx are you using the dark style scheme by chance? <nckx>vldn: ' means quote which you need to turn into ` or quasiquote in order to , or unquote inside of it. <nckx>I'm not using anything deliberately. I haven't configured any GTK styles or anything else. Should be defaults all the way, although my ~ is old and crufty. <vldn>still error :/ (("which" #<procedure which (program)>) <nckx>vldn: Your example was missing a closing ) <nckx>leoprikler: How would I do that here? <nckx>Or undo. Or whatever is going on. <leoprikler>I knew it 2.0, propagating gtksourceview@3 fixes it <nckx>guix env --a-h glib:bin meld -- gsettings get org.gnome.meld style-scheme → 'classic' <nckx>If propagation is the answer (...) then I don't understand why meld works in my pure environment. <leoprikler>perhaps you have gtksourceview-3 propagated by some installed package? <nckx>Modulo icons but who uses those. <nckx>Are you saying gtksourceview-3 sneaks through the --pure somehow? <nckx>No share/gir-1.0/GtkSource-3.0.gir in ~/.guix-profile or /run/current-system/profile <nckx>Is there a more fundamental way to verify? <nckx>(I'd rather not rely on Guix UI until I'm sure it's trustworthy here.) <nckx>uix environment guix -- ./pre-inst-env guix environment --ad-hoc --pure meld bash -- bash -c 'XDG_DATA_DIRS= meld ~/A ~/B' works. <nckx>Next up --container I guess. <nckx>(It works without pre-inst-env too BTW, that's not it.) <nckx>--container can't talk to my display of course. <apteryx>any idea how to get the version of guile from './pre-inst-env guile --version' reconciled with the version I get in 'guix environment guix'? I tried deleting autom4te.cache directory and autoreconf + configure'ing, but nope. <apteryx>pre-inst-env reports Guile 3.0.5, while in the environment it's at 3.0.7 <apteryx>leoprikler: thank you! We should try to have it refresh automatically when the environment guile changes <nckx>leoprikler: That would let through ‘WAYLAND_DISPLAY’ but doesn't help. <nckx>I'd rather have it talk to :1 though. <nckx>And I prefer to fall back to decades of X knowledge when things get complicated. <nckx>And things are definitely complicated. <apteryx>seems to be this: pkglibexec_PROGRAMS = guile <fnstudio>hey nckx leoprikler, how are you? i see you're working on meld, i think i'm also affected by the same issue <nckx>fnstudio: "Couldn’t find colour scheme details for meld:insert-background; this is a bad install"? <fnstudio>i've been time-machine'ing back in time to make it work lately <fnstudio>i was able to find this commit where things work (in my setup): 5e00d147912c17f3abcef9af137fea462c250a78 <nckx>Welp, that settles it, I'm blessed amongst men and chosen by angels. Time to assemble acolytes. <fnstudio>also, if there's anything i can help test on my machine, glad to do so <nckx>fnstudio: Seems like I'm the only person unaffected by the bug. <nckx>Despite sextuple-checking the store hash &c. <nckx>This machine can't KVM, or I would've. <fnstudio>i should add that i'm running guix on a foreign distro? <leoprikler>fnstudio: which commit is the failing one for you? <fnstudio>leoprikler: anything past this one 5e00d147912c17f3abcef9af137fea462c250a78 fails, iirc <leoprikler>"anything past" is not nice if you're dealing with git <fnstudio>leoprikler: let me try and be more helpful <nckx>fnstudio: So you mean that 93872098eb4c66c01ee56ba5f0e568e029def326 is the breaking commit? <fnstudio>nope, i mean that if i time-machine back to that commit, then things work as expected <leoprikler>Meld 3.20.3 has worked at some point since March for others though, I'm pretty sure about that. <nckx>Well, 93872098eb4c66c01ee56ba5f0e568e029def326 is the very next commit and touches meld, so it's rather crucial to know if that's where things break. *nckx gets unpleasant feeling... Meld... About Meld … Meld 3.20.3. Phew. <fnstudio>sorry when i said "nope, i mean..." i thought you were referring to 5e00d1479... <fnstudio>so, to be clear: 5e00d1479... works while 93872098e... does not (just retested) <nckx>OMG I feel so offended right now. <OriansJ>it is nice to know that my bug isn't unique to me ^_^ <nckx>leoprikler: By the way, I didn't mean to derail you. If propagation fixes it for you, go ahead, no need to figure out my weirdness first. <pineapples>nckx: Hi! I'm sorry to bother you, but do you happen to use `wl-clipboard' on your system? <nckx>leoprikler: Yes, I should stop updating things now that I've been appointed The Bug-free One. :-/ <nckx>Or y'all should switch to Sway, the premier first-class Meld platform of choice. <OriansJ>nckx: or use a setup known to break often (I certainly seem to be that case) <leoprikler>I'm pretty sure things weren't broken back in that commit though. <leoprikler>Rather it's the combination of current system + time machine to that commit that lets us blame you. <nckx>leoprikler: I agree, I think people besides me were using it. *nckx doesn't feel blamed. <OriansJ>nckx: the only reason I haven't jumped form i3 to sway is because it didn't work right on debian the last few times it was tried and am waiting for it to be working nicely. <nckx>I can send you totally not suspicious-looking screenshots of Meld working fine and 3.20.3 not hand-written on top of 'em. <nckx>OriansJ: I switched only for the shiny feeling, nothing much changed, except my clipboard has become super-unreliable of late (circling back to pineapples). <nckx>I don't use wl-clipboard but have in the past. <nckx>I've seen much worse (that is not a challenge). <nckx>Or, well, in all honesty, yours looks very much like mine. <nckx>Make of that what you will... <OriansJ>nckx: clearly we are both insane guix users ^_^ <leoprikler>Honestly, the worst thing about it is the indentation <pineapples>nckx: I see! Anyway, it broke for me overnight... and it turns out it is inauspiciously dependent on `xdg-utils' :| <OriansJ>leoprikler: well I am a member of the cult of tabs for indention but spaces for alignment <nckx>pineapples: It requires them to be installed alongside it? <pineapples>nckx: It appears so, yes. I'll see if it has to be a propagted input or not <nckx>Ew. execlp("xdg-mime", "xdg-mime", "query", "filetype", file_path, NULL); <leoprikler>I just remembered a guile bug when I looked at my config.scm <nckx>pineapples: It should just be patched. Propagation, much like tabs, is the devil's didgeridoo. <nckx>He plays melodies so sweet, but we must resist. <pineapples>nckx: Do you mean pacthing the C source code, or wrapping the binary around? <nckx>I'm going to patch the code. <pineapples>This is not my league. Perhaps one day.. But not today :( Either way, thanks! You're the hero we all need :') <OriansJ>so we don't end up having to support a patchset for a package in guix forever... <nckx>But then I'd have to send a new patch upstream every time my /gnu/store hash for xdg-utils changes. I don't want to do that. <nckx>This about hard-coding an xdg-mime location, not an upstream bug. <OriansJ>ok, so a guix packaging change not a code change in meld. <nckx>If anything they're doing the right thing. My ‘ew’ was not of disgust, more like ‘oops yeah that was hard to miss how did we’. <nckx>It was not very idiomatic. <nckx>execlp("cat", "cat", NULL); …now that I don't get. <nckx>Some Wayland sandboxing thing? <pineapples>nckx: Don't quote me on this, but for a clipboard helper to work a certain Wayland protocol must be supported by it, but this is, by no means, a sandboxing mechanism per-se <nckx>I mean why would you ever shell out to cat from C code. You should barely ever do it from actual shell code. I'm genuinely intrigued. <pineapples>nckx: Pardon the ignorance, but what does "shell out" mean in that context? And, as for that protocol, yeah.. I guess that will require a Sway service or something in the worst world scenario, no? <pineapples>..unless I'm oblivious to the packaging problem that it might pose for us in the future, which is very likely haha.. <pineapples>Err, I mean, I may not simply get the gist of the issue here <pineapples>But, if I understand correctly, this is merely a problem of populating `/etc` with Sway-specific configuration files that specify Wayland clients' priveliges, and having Sway read them, yes? If so, perhaps this is a problem for `guix home' to solve? <leoprikler>pineapples "shell out" means calling a shell program rather than doing stuff in your own language <pineapples>..on the second thought, forget what I said about `guix home'. <pineapples>nckx: Welp. There is still a lot to unfold in that area. We still have time to share our concerns with Sway's development team as well as Wayland's before that materialises <nckx>I take heart in your optimism. <pineapples>With automation that GNU Guix provides, there has been only few things I couldn't at least work around in my config.scm. I doubt that you, as in everyone who makes up the collective driving force behind GNU Guix, wouldn't be able to come up with something tolerable and/or workable, either :) <admas>Do any of you post your system config on a public repo? I'm wondering if there are any security issues with doing this. <admas>I'm also curious if anyone has figured out how to use mcron to have Anacron like behavior of starting a cron job as soon as possible on startup if machine was off during scheduled run. <leoprikler>Well, you might expose your initial-passwords, so that's that <OriansJ>admas: if you can find security issues with my config, I would be happy to see suggestions for improvement. <OriansJ>but as long as one doesn't include credentials in their published config, there isn't much to go on besides what is installed. <admas>OriansJ, I'm slightly concerned that knowing what's installed on my machine could lead to easier exploitation if there is a zero day with some of the installed packages <pineapples>For example, a job that was supposed to run one day, will be run on the next day, missing its first appoinment by several hours :/ <admas>pineapples, thanks for sharing your experience with mcron. I see this may end up being another project to get that working the way I want <OriansJ>if one is really paranoid, add whitelisting to your kernel and then no zero-day could even run (unless run in one of the interpreted languages on your system) <pineapples>admas: I implore you to, if you can. This has been a major headache to me, and it forced me to configure unattended-upgrade-service to run daily to not miss any updates since I often turn off or suspend my system <admas>OriansJ, I love the comments on the packages btw. I may be being overly paranoid because I'm falling into the security through obscurity argument. <OriansJ>admas: checkout #bootstrappable if you want the extra paranoid defences (solving the Trusting Trust attack) where everything is built from source (starting from a 357byte binary written in hex) <admas>OriansJ, thanks for the suggestions. Though I am feeling overwhelmed by what I need to consider to be secure. <OriansJ>admas: security without understanding of what you are trying to protect yourself against isn't meaningful. <OriansJ>So the most important first question in regards to security is what do you want to defend yourself against? <admas>That's a good point. As it is now, my main source of worry is identity theft and hacking financial accounts <OriansJ>install keepassxc and use unique accounts for everything and long randomly generated passwords for all online services you use. Yubikey and/or mooltipass and/or hardware cryptowallet for credentials you want kept safe even from an infected computer. <admas>That's good news since I am currently using keypassxc to generate unique passwords. I haven't looked extensively into yubikey so I'll check that out. <pineapples>admas: Anyway, it goes without saying that I'm *very* interested in bringing anachronistical behaviour to mcron, and I'll gladly collaborate on it. Feel free to tag or PM me in regard to this :) <OriansJ>as for identity theft, well unfortunately most identities can be bought online for $3.18 due to breaches that have occurred in the various government agencies that might have a copy of that data. <OriansJ>and the credit companies that provide credit freeze services, tend to be vulnerable to a great deal (they have ALL been breached) and the freezes seem to be easy for a malicious third party to undo. <OriansJ>but that might just be me being jaded by my job. <cbaines>on the plus side, the Power9 hardware I've had on my floor for a while is now working <marusich>i've been trying to debug issues with check and haven't made any progress... so little time <cbaines>I spent more time swapping RAM and CPUs in and out, and then it finally booted <cbaines>then I had an issue with Gnome, where I thought the system was unstable, but it was just Gnome trying to suspend <marusich>yeah mine took a bit of fidgeting to make it work. i recall i had to do some nonsense like change the grub parameters. but once it booted, i didn't have to touch it again <cbaines>Yeah, although I'll try to install Guix as a system at some point soon <cbaines>currently I've got it building substitutes for bayfront.guix.gnu.org <cbaines>it has just started properly building things today though, so it hasn't got very far yet <marusich>I'm not sure how much work it will take to make it boot as a system. I haven't tried it. At the very least, I guess linux-libre has to work, and then using the --no-bootloader option, you might be able to manually update the GRUB configuration on the system to kexec the built kernel <marusich>sorry, I meant, update the petitboot configuration to load the grub configuration <cbaines>right, I don't have a good picture of what the problems would be <marusich>I'm doing alright. 2020 and 2021 have been rough to say the least <marusich>I have been trying to contribute to Guix in my spare time but have found very little <marusich>it's frustrating; i'm envious that you have a grant to work on it ;) <cbaines>haha, don't be too envious, that grant stuff isn't really working, at least not yet <marusich>but things could be much worse, I suppose. the weather is getting better, which is always nice <cbaines>I'm still trying to salvage some benefit from the Guix Build Coordinator stuff I've been working on for the last year+ <cbaines>I don't have the headspace yet to try and switch to a whole new stream of work <marusich>I also really want to try to shoehorn Guix more into my work, but every time I think about doing it, it seems like there are a bunch of obstacles that would take more time than I can allocate to fix <marusich>I find it difficult to easily integrate Guix into workflows that assume the environment is very different, but I guess that's to be expected. It's also very hard to integrate Guix into development workflows that rely on tools that are not packaged in Guix and assume they are running on a traditional distro <marusich>Maybe I just have bad luck. I once tried to learn Rust by going to an embedded rust workshop with friends, and although they installed things and were ready to go in an hour, I spent the next month trying to figure out how to get the toolchain working on guix system, and failed <cbaines>in some ways, I think that also trying to fit Guix in and around other tooling doesn't actually realise the potential <marusich>but that sort of thing happens a lot i feel <cbaines>in particular, Guix should escape the need for container images <marusich>it's hard to shift everything at once, though <marusich>another thing i wonder about is how people integrate their development workflow/environment with guix <marusich>I have been doing a lot of Java development, and in that world you rely on the IDE and on Maven quite a bit to get the dependencies. The IDE can "see" the dependencies you get via Maven etc, so it's easy to look up javadocs, jump to the source, etc. Simple but very convenient. <marusich>I find myself wondering if (how?) people develop "serious" projects, other than Guix of course, from within Guix system. <marusich>We have thousands of projects packaged, of course. So complex projects like Inkscape or Krita can be built, for sure. <marusich>But what about a Krita dev, for example? Would they feel comfortable using Guix System to do development? <marusich>Maybe it's not as bad for C or C++ projects, but for Java I have the nagging suspicion that right now, the answer is probably still "it isn't feasible" <marusich>the moment Maven tries to download some java code that includes native stuff, you're gonna have a bad time <marusich>As a work-around, the only path I can see is to use a "popular" distro like Debian and use Guix within it, but at that point you're basically not using Guix's features <marusich>so what I'm saying is Guix s great for packaging the final product, but it could also be great for the hacking workflow, the development part <cbaines>I guess I used to do semi-serious Ruby development, and I used Guix quite a bit, but I had to do quite a bit to make that possible <marusich>but right now i feel like it isn't so great, and i wonder if others feel the same <mstrom[m]><marusich "As a work-around, the only path "> Or develop within Docker? <cbaines>and it still wasn't a smooth experience <marusich>mstrom[m], that is another option, true. <marusich>mstrom[m], i haven't seriously explored that, but wouldn't it basically be the same as running on a foreign distro? in the sense that maven etc. would be relying on the container looking like a debian system or whatever. <marusich>in the case of java, i suspect there might be a way to add a "plugin" or equivalent for your favorite IDE that understands how to "get dependencies" from guix <marusich>since that's basically what is done for maven, and that's what I've seen at companies that have their own packaging systems built <marusich>so you'd have to like, do that for every language, which sucks admittedly <marusich>and of course you can do development just fine without your ide, if you just modify text files and use guix to build it <cbaines>which I didn't use, but I think writing lots of various integration plugins/scripts/tools is probably the way to go <marusich>but let's be real, few java devs will be willing to do that after experiencing the convenience, productivity, and safety (e.g., of refactoring support) of an IDE. <efraim>cbaines: I'd appreciate it if you could test mesa on power9, I wasn't able to test video output <marusich>yeah. the docker suggestion is also not bad, as much as I don't really like docker <cbaines>efraim, I can try building things, but I haven't got any graphical output from the system I've got yet, I'm still working on that <marusich>but making plugins for popular ides that support guix as a first-class dependency management solution seems better <marusich>efraim, what do you need tested exactly? <marusich>I have graphical output set up, although on Debian 10, GNOME crashed regularly for me. <cbaines>I guess the reality of the situation is that rational people are only going to put effort in to adopting Guix if there's more benefit than the effort required <mstrom[m]>I haven't explored Docker in Guix, but I used VSCode for a while and they have this feature called "Dev Containers" where basically if you have a docker_compose.yml in a repo for builds and tests, VSCode will spin up a docker and enter that environment so you can use e.g. the npm modules of that actual project, instead of your system-wide npm packages. Of course you lose everything you have system-wide, including your own <mstrom[m]>VSCode addons, which you have to specify in a file too for them to be rebuilt inside the container, but it works with fairly few snags <efraim>I guess anything with graphical output. I'm pretty confident about the powerpc64le bits of mesa but I wasn't able to test actual grahical outputs <marusich>cbaines, that is the prevailing opinion I have seen among "corporate" devs <efraim>even something like glxgears would be great <mstrom[m]>you could do something similar with emacs and TRAMP <marusich>of course 'popularity' isn't that important for this project, but i do think guix could be so much more awesome if it were easier to use for hacking on projects in practice <cbaines>marusich, I don't think that attitute/opinion is a problem though, it just means that highlighting the benefits, and the path to adoption is the way to go <cbaines>plus actually making things possible of course <marusich>it's just an indicator of something we could focus on to try to improve the user experience <marusich>mstrom[m], interesting. If the goal is to be able to use an IDE in Guix System and conveniently develop stuff, that might be one way to do it. (Assuming "Code - OSS", the FOSS version of VS Code, work on Guix System to begin with) <marusich>The idea of having an IDE delegate the dependency stuff to Docker containers doesn't have much to do with Guix per se, though. <marusich>Perhaps that's an easier path than making custom plugins for various IDEs? <marusich>I would still personally be greedily interested in a plugin / feature for any given IDE that provides direct support for connecting it to Guix's dependencies, rather than taking the shortcut of using an opaque Docker container. But I can see why that is potentially a good interim solution... <marusich>It doesn't help that the IDE I'm currently using is not packaged in Guix :( <marusich>It's NetBeans, which apparently is free software but for some reason isn't listed on the free software directory... Figuring out how what problems there are and maybe fixing those is another thing on my list of things to do, someday... <mstrom[m]>I don't have a clear picture of whether adapting the IDE would solve everything for e.g. your Java development <marusich>Is Eclipse packaged? I see a ton of eclipse packages <marusich>mstrom[m], yeah, I'm sure there are other rough edges. I just picked up NetBeans because where I started working recently has been using it for their IDE. It seems to have a *lot* of features, not all of which might mesh well with Guix. <marusich>NetBeans sort of feels like a kitchen sink of development. They have a feature for almost everything you'd want to do in the development lifecycle. <marusich>Building installers, deploying to remote servers, refactoring code, handling various build systems, their own implementation of a build system in ant... <marusich>they even have their own module system in netbeans platform and an entire ecosystem built around it...an automatic update center...tons of things. <cbaines>that should be less of an issue with Guix though <marusich>but not talking just about java... in general, I wonder what percentage of projects packaged in guix would feel comfortable developing that project in guix system. <marusich>Like, if you took their devs, gave them a guix system machine, and said "go do your thing," what percentage would be able to make it work for them today? <marusich>My guess is it's probably less than half for sure, if not close to 10 or 20% <marusich>or more accurately, I want that number to be closer to 90%. I don't think I've ever been able to do everything I needed in Guix System, which is frustrating because I really wish I could <cbaines>indeed, it's fustrating believing that it could work well, but being quite far off still <marusich>That said it's getting better every month. <cbaines>maybe I could do more around building Rails apps with Guix, I already spent quite a bit of time packaging it <mstrom[m]>marusich: not gonna lie, I've wanted to stick some developers in front of a guix machine and make them package their own project so they see how lacking is their documentation <cbaines>unfortunately, it's not up to date though, so straight away I'm back to the issues around merging patches, which I've been working on for a while <cbaines>and I haven't even been directly working on that recently, but instead trying to improve substitute availability and set the stage for building things affected by packages <ubuntuxp>Hi, several months back I submitted a patch to add slade as a package (#44039) and it seems to have been forgotten. Can I get an update? <marusich>Given my limited time right now I'm trying to focus on POWER9 things. I think it's OK to focus on the things you find most interesting or the things you need. <cbaines>it's almost like I'm yak shaving, but I've forgotten what I'm going to do with the wool <vagrantc>cbaines: there are a wide variety of fibre arts available <marusich>ubuntuxp, it's good to ask here, of course, but you might also consider sending an email to the people who participated in the bug discussion specifically. <cbaines>vagrantc, also, I've successfully used the Debian package for guix for ppc64el :) <mstrom[m]>cbaines: unlike shaving Arch or Gentoo, at least we're not just shaving our own systems. Guix feels like an immortal yak, and it will remember your toil <marusich>ubuntuxp, judging by the message it sounds like there was some uncertainty about what to do with the timestamps. was that resolved? <cbaines>mstrom[m], I admire you're sentiment, but it's been feeling like I've been making less and less progress recently <marusich>I thnk the reviewers wanted to make sure that the build output is reproducible. <mstrom[m]>cbaines: in that case, just enjoy yourself, maybe <marusich>ubuntuxp, I would recommend trying your patch like "./pre-inst-env guix build --rounds=2 slade", thus verifying that the output is reproducible. If it is, then I'm not sure what blocking issue would remain. Maybe the reviewers also thought that reset-slade.pk3-timestamps was unnecessary, so you could try removing it? <slyfox>i still find guix's process of making occasinal package tinkering a lot more cumbersome than say, gentoo's. especially when i need something like trying out gcc-11 real quick on that special package <vagrantc>cbaines: good to hear the ppc64el package of guix works on debian ... i did build-testing on ppc64el, but didn't actually have the ability to install test <cbaines>vagrantc, well, I can confirm that I haven't encountered any issues with installing it :) <cbaines>I did run out of build users, but I managed to add some more <marusich>slyfox, i was wondering about this recently, actually. Is it possible to build stuff using gcc-11 using --with-input or some other package transformation? <slyfox>--with-latest=gcc should work, but gcc-11 itself did not build for me <slyfox>and you know it only an hour later <slyfox>(and i have no idea how to easily get into a build directory to explire/change things a bit before continuing derivation build) <marusich>My first impression is that maybe that just means that there was a problem building cc-11? <vagrantc>cbaines: i think it provides ~10 users out of the box _guixbuilder0..9 that's consistent with other guix installations, no? <cbaines>vagrantc, yeah, I just needed more :) <vagrantc>ok, just making sure i'm setting reasonable defaults <marusich>slyfox, --keep-failed is the only way, really, and if you want to "stop" execution at a specific phase, the only way is to modify the package. I feel like an option such as --stop-before-phase would be a neat addition. <slyfox>aha, -keep-failed might be good enough <marusich>or maybe like, if guix could spit out the guile code to run each phase, and then let you run it by invoking a script in the build environment, so you can run each phase one at a time interactively...that would be neat <slyfox>Running 'make' should be good enough for my small needs <marusich>slyfox, you can actually do the phases one at a time, if you fire up a repl in the build environment <marusich>it's a bit cumbersome though, because you have to know what module contains the package, and then you have to fire up the repl, and you have to enter the right scheme code to execute it, so if you're not already familar with a lot of that stuff it's kind of a big wall to scale, even if it's simple in theory <slyfox>oh, nice. does guix doc (or something similar) have a hit how to do it? <marusich>basically you just use --keep-failed, so you get a build environment. or maybe you can start from the source code unpacked somewhere... <slyfox>my scheme knowledge is very limited and guix's use of syntax macros makes my head spin every time i try to reason about it's evaluation :) <marusich>then you would start a repl, probably by first cding into the directory, running '. environment-variables' to set up the environment (not pure, since you want to use guix also), then run "guix repl" to get a repl where you can do stuff with the package definitions *vagrantc is still cargo-culting guile after maybe a year or two of submitting commits <marusich>once in the repl, you can manually enter scheme forms. if the phases are simple, you might be able to just manually enter some of them. <marusich>if it's more complex...I'm not sure. I might have only used this trick to do simple things like "find and replace stuff" using the substitute* form. <marusich>I don't think there is an easy "run this phase" procedure though <vagrantc>hah, or three years ... my fist patch contribution was april 2018 ... wow <vagrantc>wow, and [bug#31447] [PATCH] linux-libre: Add aarch64-linux. was also from may of 2018 :) <slyfox>yeah, running phases would be useful. gentoo has 'ebuild $pkg [unpack | prepare | compile | install | merge]' (and i use it all the time) <vagrantc>i guess this is kind of my guix anniversary :) <mstrom[m]>vagrantc: i wonder what is a fist patch, perhaps you want it as an anniversary present <marusich>right...honestly if I really really need to debug phases, I would probably use a git checkout right now, and manually make the phase where I want it to stop error out, and then inspect the result with --keep-failed. <vagrantc>i can't seem to find when people were crazy, er, kind enough to give me commit rights <marusich>i wonder what it would take to have a "guix enter-build-environment" kind of command, which would drop you into a shell where you could somehow walk through the phases and inspect the results as you go. <marusich>Since the build happens in an isolated environment, I'm not sure how you would get input/output to there. <vagrantc>oh, looks like my commit access was late april 2019 ... so may/april really is a guix anniversary for me :) <mstrom[m]>marusich: it'd be like guix build --keep-failed but pauses at each step and waits for Y/N to proceed, so you can look at the build tree on a separate terminal/editor/file browser ? good enough? <jackhill>marusich: I also think that would be cool. Perhaps it doesn't have to be the real build environment, but something that lets folks run the code from the build side in their regular environment with fewer isolations. <jackhill>e.g. I often want to be able to run patch-source-shebangs and other prep steps outside of the deamon <marusich>If i were gonna try implementing something, I might try to make the builder script dump the phases as scripts you could invoke in order, sort of like how it currently dumps the environment into environment-variables so you can source it after running --keep-failed. <marusich>that would avoid the issue of having to make it interactive even though the build environment is isolated. <jackhill>marusich: that would be enought to at least make me happy :) <marusich>BTW does anyone know where exactly the official autotools documentation explains what changes, if any, ever require blasting away the entire repository and starting fresh? <marusich>When I've arleady run "make," I am always suspicious of running "make" after a "git checkout" without cleaning things first. But it's sooo slow if I do that. <marusich>When only the scm files have changed, I usually feel confident that nothing weird will happen, but when for example Makefile.am changes, I am more suspicious. <marusich>jackhill, yeah it's hard to predict what people neeed when debugging build failures, but being able to run the phases like that would sometimes be useful, I think... <vagrantc>what i get really frustrated by is the difference between guix environment and guix-daemon's build environment <marusich>yeah, which is why it would be super nice to have a "guix real-build-environment" command :) <vagrantc>sometimes things build fine in guix environment by fail from guix-daemon <marusich>but again i'm not sure how to set up the communication required to do so... <drakonis>soon the daemon will be entirely in guile <marusich>maybe it's something a systems programmer would know how to do in a heartbeat <vagrantc>guix-daemon by design tries to keep you from being able to interact with the environment <marusich>BTW I noticed that GCC 8.something was released very recently, and they said it was the last of the 8.x series. Apparently 8 and below will no longer be maintained. What does that mean for security etc. in Guix, since it is still using 7.5.0 on master? <marusich>On core-updates, I was hoping to upgrade at least to 8.something to fix powerpc64le-linux, which was broken on core-updates due to the upgrade from glibc 2.31 to 2.32. <vagrantc>civodul just proposed to update to gcc 10 on the recent "what next" mail <vagrantc>i was amazed it was still gcc 5 as of a short while ago <marusich>i am amazed that we were able to bootstrap powerpc64le-linux using gcc 5 <marusich>i guess in the future the bootstrap path will need to take a different route, via a later gcc version in the beginning, for future architectures <vagrantc>it may be possible to backport patches in some cases <vagrantc>pretty sure the folks in #bootstrappable are exploring that option for newish architectures <vagrantc>as newer gcc depends on a much larger bootstrap chain <colemickens>Can we discuss guix system on rpi4 here, or is that discouraged due to the non-free bootloader that is basically required? <vagrantc>if you don't get into the non-free bits ... :) <colemickens>Beautiful, it looks like "an opinionated distribution of u-boot" can encapsulate those nasty bits and leave me the ability to just present a UEFI system on my NVME drive. Leaving me to just focus on learning the clean guix bits. Very excited to dive in. 
