<bandali>hey Blackbeard, how so? the pandemic? <lapinot>but anyway my problem is that the live guix image has outdated packages that i couldn't understand how to upgrade <Veera>how to install packages system wide <Veera>If I install them as root will it do <lfam>Veera: Are you on Guix System? Or using Guix on another distro? <Veera>I was reading Guix info Contributing pages <lfam>Veera: Add the packages to the (packages) field of your config.scm, reconfigure, and reboot <Veera>Since it needs some pkgs beforehand, I want to install them systemwide <lfam>To add them for all users, yes <Veera>yes. I read that. It says for all profiles do that way. <lfam>I would write it like this, for example: (packages (cons* vim rsync git %base-packages)) <Veera>so I want to make pkgs and build them to guix. <Veera>Is it okay to go with user install? <lfam>Yes, that is the recommended way to install packages <lfam>But for testing new packages I recommend `guix environment foo` <lfam>`guix environment --ad-hoc foo` <lfam>So if you are writing the package recipe in your Git repo you can build the repo and then use `./pre-inst-env guix environment --ad-hoc foo` <lfam>You will be able to try using foo and it will not stay in your profiles <lfam>When the package is done you can install it to your profile :) <Veera>Can git, emacs, qemu-emulated? be installed as non-root user and ... <nckx>lapinot: Do ‘guix pull’ and ‘guix install’ not work in the installer? <lfam>Yes, almost everything can be installed by non-root user <nckx>lapinot: GRUB doesn't support LUKS 2 yet, but will in the next release. <nckx>I'm not sure if something still needs to be done on the Guix side or if updating GRUB when it comes out will make everything just magically work. <nckx>I've already updated cryptsetup a while ago, so I hope for the latter. <Veera>One thing how to add new users outside of config.scm <Blackbeard>bandali: a bit, I also needed to trámit my proof of enrollment, I had to go to the bank to pay and it was super slow <Veera>Since gdm doesn't shows if I use adduser <Veera>But help pages says guix system reconfigure removes all added ones <nckx>Veera: Guix System requires all users to be declaratively declared in your system .scm. <nckx>Blackbeard: As in busy? (:-/) <Veera>nckx: Did ya said that for me "Don't" <nckx>Veera: Yes. Don't use adduser, add your users in your system .scm. *nckx .oO maybe we should move add{user,group} to a separate output, if that doesn't break anything. <Veera>nckx: And the mate sign in problem got solved. <Veera>nckx: Only after I type in the passwd the cog wheel shows <nckx>That legendary GNOME HIG UX. <Veera>nckx: Also in the default setup mate launcher complains of no gio-launch-desktop <nckx>Veera: I'm glad you figured that out, I was quite puzzled. <Veera>In first screen it does not shows it <Veera>Only if type some in passwd line it shows. <Veera>But after I set it, it becomes the default for next logins <Veera>for gio-launch-desktop the pages in mailing lists helped <nckx>I'll remember that if someone ever has the same problem, thanks. *nckx 's coughs up a lung; time for bed. Good night all o/ <Veera>installed the pkgs in config.scm and it now works <Veera>Why runnig guix pull run from user other than root is pulling all again <Veera>Well I used guix pull as root for updating config.scm. Now as another user it is pulling all again. <nckx>Veera: You shouldn't pull as root at all. Simply ‘guix pull’, then run ‘sudo guix system reconfigure’ or ‘guix install/remove/…’. <nckx>‘guix pull’ is per-user, but ‘sudo guix’ will do the right thing and use *your* (up-to-date) copy of guix, not root's. <nckx>Now I really must go. Good night & good luck. ***drakonis1 is now known as drakonis
<Veera>is that only one copy is present in the store <Veera> no matter from where we run pull <Blackbeard>When was the last time you did a guix pull as your user? <Veera>Actually after installing from iso img I logged in as root and did guix pull and guix system reconfigure thing... <Veera>Now I understand that I should have done that as normal user <Blackbeard>Veera: doing guix pull as root is independent from doing it as your user, so that's why it seems like a duplicated effort <Veera>In after system installation page it does not says from which user to do. so... <sirgazil>I didn't understand the problem Veera was experiencing with the gear button that lets you select a desktop environment before logging in... <guix-vits>sirgazil: maybe Veera'd installed MATE in user profile and system's GDM didn't seen this? ***apteryx_ is now known as apteryx
<KE0VVT>PotentialUser-35: Do you have Wi-Fi? <KE0VVT>PotentialUser-35: You would need either Ethernet or Wi-Fi. <mbakke>janneke: how is the Hurd porting work going? :) <janneke>mbakke: i did revise the ppatches/.patch files and rebased again on core-updates <mbakke>janneke: I noticed, exciting times! <janneke>trying to help with core-updates too and bisecting a mingw c++ cross build problem; melting iron left and right <mbakke>janneke: I restarted the failed GnuTLS build, let's see... <mbakke>bisecting core-updates sounds painful :/ <janneke>boost-1.72 just failed for me; and next i know i get a working substitute... <mbakke>janneke: I guess the mingw problems are due to the CPLUS_INCLUDE_PATH changes? <janneke>yes, i think so -- i first suspected gcc-7 <mbakke>janneke: there are some workarounds for the newfound CPLUS_INCLUDE_PATH problems floating around that branch, see e.g. gcc-4.9, qemu, or libcxx. <mbakke>janneke: /gnu/store/88w1ixijm4gshglaslajnz9cpvggm0f6-guile3.0-gnutls-3.6.12.drv succeeded this time <mbakke>you can force Cuirass to start a new evaluation by e.g. 'git commit -m "kick CI" --allow-empty' <mbakke>janneke: the CPLUS_INCLUDE_PATH workarounds, yes <mbakke>well, fixed as in restarted the build, not the underlying cause whatever that was :/ <mbakke>janneke: do you expect more low-level changes for Hurd, or can we merge the full-rebuild bits and start working on merging core-updates? <janneke>thanks! i've been "playing" with cross_cplus_include_path for wxwidgets, but the real understanding is still missing here...i'm in the "it works!" phase (esp. re -system vs -I, cross_, cpath, not easy!) <janneke>mbakke: i am not planning more low-level changes; the lowest level that i have pending is commenting-out failing tests for guile on the Hurd <janneke>current wip-hurd should be a nice basis to do initial hurd system image devolopment on, i think <mbakke>janneke: right, I suppose that change can be "spliced" so it does not affect other architectures <civodul>janneke: BTW, if there are changes we can apply in Guile proper, lemme know! <janneke>i could use some help/insight in what could be going on...like "we" looked at kill -1 <janneke>i suspect this is something similar, a glibc or hurd bug rather than guile; but i really don't know <janneke>mbakke: yeah, "we" need to feed civodul more interesting low-level things once in a while ;-) <civodul>mbakke: it's plesant to fix a 3-year old bug :-) <civodul>janneke: those 3 test failures look... interesting :-) <civodul>BTW, the recent low-level Guile fixes were thanks to wingo telling me about rr <mbakke>kmicu: not sure, but 1.1 is possibly out in a few weeks <civodul>mbakke: so what do you think of targeting next week? <civodul>and we'd merge core-updates in the weeks after <mbakke>civodul: next week sounds achievable, good timing now that many people have nothing better to do than try a new distribution :P <mbakke>"weeks after" love the optimism! <efraim>I guess i'll try to find a vim version that builds on armhf <mbakke>there is still something that pulls in Guile 2.2 on a minimal system configuration on core-updates, hmm *raghavgururajan is wondering if delta-updates are possible in guix. <efraim>ideally it shouldn't, it's "just" a binary patch <civodul>~10 years ago Nix used binary patches for substitutes, but that turned out to be inefficient *rekado tries to upgrade tensorflow to the latest 1.x release <guix-vits>raghavgururajan: when i'd seen delta-updates in Fedora, they were the less efficient the less frequently i'd updates installed (less than %5 traffic difference, usually). But for frequent updates, idk. <rekado>version 2 does not have CMake files anymore <raghavgururajan>rekado: *unrelated*. I wanted to ask if you are using gandi for your elephly.net domain? <civodul>rekado: right, i was asking because i thought CMake support was gone <rekado>civodul: since we can’t upgrade to 2.x I thought we might as well offer the latest 1.x version <rekado>1.x and 2.x might co-exist for some time. <mbakke>civodul: it's guile-wm, and apparently ld-wrapper-cross despite commit 1b70995498973fe899f8f039586e303c7ec7a3bd *mbakke goes afk for a bit <mbakke>can we bump guile-wm to Guile 3 on 'master'? <civodul>it's just to build the .guile-wm skeleton, right? <civodul>the one that'll default to GNU/Hurd? *janneke has a patch to remove it -- with sadness -- on my wip-hurd-system <janneke>it adds *a lot* to a simple disk image build closure <janneke>makes building on the hurd still pretty annoying <civodul>esp. when you rebase every other day :-) <civodul>let's just be sad together for a moment and get over it <janneke>pushed, sniff -- let's bring it back on 2.0! :-) <efraim>do we have an example of pulling in the gnu configure-phase and adding configure-flags? I need to set the configure-flags inside the phase i'm adding <mbakke>efraim: not sure what you are asking, but many packages with custom configure phases use #:configure-flags with (apply invoke "./configure" configure-flags). See e.g. ungoogled-chromium. <efraim>mbakke: I meant like in emacs-scel <mbakke>civodul: the remaining guile 2.2 reference on core-updates comes from (@ (gnu packages make-bootstrap) %guile-static) <mbakke>I tried to make it inherit from 3.0, but guile-relocatable.patch does not apply *janneke wonders why their M-x guix-edit can't find anything <mbakke>I can try to port the patches. Does it make sense to do this on 'master'? <mbakke>it's only used for the initrd AFAICT <janneke>oh well, it should go to ~/src/guix/master or core-updates instead of the store anyway... <mbakke>janneke: have you (setq guix-directory "/your/preferred/checkout") in .emacs? <janneke>mbakke: ah, no but that sounds good! <janneke>ah, and my emacs-guix uses guile-2.2 -- i finally see some errors; that helps <janneke>there was a talk on lp about "sugar" the desktop environment (distro?) that incubated in olpc; and i learned they have something like "show-lossage" for everything -- kinda alike why i love exwm so much except when i need to use a gui/browser <mbakke>it probably does not make sense to update %guile-static on master, because I get "incompatibly bytecode" warnings during boot on core-updates due to the Guile version mismatch <mbakke>janneke: what do you mean by "show-lossage"? <janneke>mbakke: ah, apparently i meant: M-x view-lossage; i.e. the promis of reading back the program you wrote/are writing while interacting with your computer <janneke>and then, of course, modifying and parameterizing it <mbakke>janneke: huh, neat, didn't know about view-lossage, sounds like a nice feature for a DE <janneke>yes, it seems to me that would be where you /start/ (next to integrating an interpreter; sugar chose python but yeah) <janneke>i'm not sure how we'd get there (Guix 2.0); exwm is nice, guile-wm might be nice -- the most pressing problem seems browsers (possibly non-emacs shell terminals?) but possibly nomad can help out (str1ngs?) <mbakke>arf, guile-linux-syscalls.patch applies on 3.0, but breaks pretty bad. I'm not enough of a Guile/C hacker to fix it. :-/ <guix-vits>(nomad) "Couldn't connect to DBus for name org.gnu.nomad.webview" -- do i need some service running? <janneke>mbakke: on wip-hurd, i have patch that /reverts/ %guile-static to 2.0... <janneke>mbakke: all bootstraps currently use a static guile-2.0 <mbakke>janneke: Cuirass made good progress on wip-hurd, but ultimately failed with 'In procedure scm_lreadr: #<unknown port>:15:133: Unknown # object: #\<' <janneke>using a guile-2.2 for the hurd bootstrap would mean ugly parameterizing make-bootstrap.scm; civodul suggested not to do that <mbakke>%guile-static is used for the initrd though, so it's not just for bootstrap <janneke>yeah -- also, earlier mipsel discussions suggested using guile-2.0 <mbakke>perhaps we should separate those <janneke>ah, let's see if i'm not confusing things then <mbakke>janneke: probably not, (guix build linux-initrd) snatches it straight from make-bootstrap <mbakke>janneke: let's take your wip-hurd changes first, and then add a %guile-static that uses 3.0 afterwards :-) <janneke>yes, hmm -- interesting i didn't (actively) know about that relationship <mbakke>it will give civodul some time to port the required changes to 3.0 😅 <janneke>mbakke: o yeah #\< that's often a very silly error although sometimes hard to find if you don't have a nice small diff to look at; which package would that be..hmm <brendyyn>why is it sometimes even with --check --rounds=9000, a package wond rebuild? <janneke>brendyyn: if you built it locally, it won't re-build to check (this situation could be improved on as was discussed yesterday) <janneke>does build --rounds=2 work after you guix gc -D it? <marmulak>This ungoogled-chromium thing looks tight <janneke>brendyyn: i agree that it's unexpected and surprising <brendyyn>guix has many strange things that could improve <andydarcyjewell>I'm making some progress on defining a package file for Factor, but I've hit an inevitable road-block: I can't work out how to get it to use the glib-or-gtk-build-system <mbakke>brendyyn: you'll need to add --no-grafts in addition to --check to actually rebuild the package <mbakke>brendyyn: otherwise you'll only re-graft it, which is not as interesting <mbakke>andydarcyjewell: do you have a package definition and/or error message we can look at to help? <mbakke>andydarcyjewell: please use paste.debian.net, as pastebin blocks Tor users <andydarcyjewell>mbakke: think the current problem is with: (guix build-system glib-or-gtk) <janneke>andydarcyjewell: are you using guix build -f <factor.scm> to build it? <janneke>okay, then you should put "factor" on the last line <andydarcyjewell>janneke: sorry, that got mangled by the IRC script, should be "guix package --install-from-file=factor.scm" <guix-vits>is `./build.sh update` a glib-or-gtk-build-system? <janneke>okay, it looks like you are using git-fetch on a tarball; try using url-fetch <andydarcyjewell>guix-vits: not as far as I know, I think it's just a custom build script that stands in for ./configure <andydarcyjewell>janneke: thanks, but the error I'm getting is: no code for module (guix build-system glib-or-gtk-build) <andydarcyjewell>janneke: Obviously, I'll change that anyway, but I don't think it's getting to that bit yet <janneke>andydarcyjewell: could your guix be too old? *janneke goes to have a proper look <janneke>yeah, the build starts for me; fails in configure <andydarcyjewell>janneke: the script goes off and checks for utilities existing, and also downloads some dependencies (but not all) <lapinot>nckx: i remember doing `guix pull` and it working, but then i tried `guix package -u cryptsetup` but i didn't do anything. Actually i think i more or less understand the guix concepts (from reading the manual), but now if there's a simple tutorial/cheatsheet lying around that would be awesome <andydarcyjewell>guix-vits: if I can do that, the I'll be happy, but it (build.sh) pulls in sources from outside of the guix ecosystem <mbakke>andydarcyjewell: there is no network access inside the build container, so you'll likely have to do it the "hard way" <andydarcyjewell>janneke: I don't think it's too old, as it's a fresh install from last week, with substitutes <mbakke>andydarcyjewell: I was able to start the build process by changing (guix git-download) to (guix download) and (method git-fetch) to (method url-fetch) <mbakke>I also added a line at the bottom of the file that just says "factor" so that the package is returned; and built with 'guix build -f factor.scm' <janneke>mbakke: bah; i mis-iterpreted the wip-hurd build log /again/; po4a built just locally here :-) *janneke would like to see the #\< error reproduce to debug it <mbakke>janneke: I scanned through "git diff 142cd4dc98ed439f32d2a903ff866ae345234c0f..f28c7f0080863124b6270615014c333f9eefd909" but could not find it either :-/ *janneke just goes to kick it again, you never know <janneke>our build farm is just tooo parallel <mbakke>janneke: I found it difficult to parse some of the (if (member (or ...))) lines, could you add the (package-supported-systems) clause on a line of its own instead of trailing the second argument to OR? <janneke>mbakke: sure, done -- that makes sense <janneke>(i'll push in a minute, after a rebase); thanks for the review! <mbakke>happy to help, really looking forward to trying GNU/Hurd! :D <janneke>my scratchbook/howto on hurd development with guix <mbakke>janneke: I had not, reading it now thanks! <mbakke>I'll give it a go once the branch stabilizes :-) <marmulak>hey so I installed ungoogled-chromium on fedora using guix using subtitutes, and it installed alright but when I try to execute `chromium` it looks like it segfaults <rekado>what does “look like it segfaults” mean? <civodul>grr my boss finds all the centralized + proprietary instant messaging tools so cool that they'd like us to use it <mbakke>marmulak: can you paste the error message? <civodul>rekado: they call XMPP "historical" because obviously it's more than 2 years old and so old-fashioned <marmulak>I mean, it didn't literally say "segfault" but signal 6 might be one I guess... <marmulak>keep in mind it could just because I set up Guix wrong on my system because I don't know what I'm doing <marmulak>XMPP is the hot new modern thing, in fact if this project had an XMPP chat instead of IRC I'd be on that already <mbakke>marmulak: the problem seems to be that it is unable to find any fonts <mbakke>according to the line [17912:17912:0319/163545.463044:FATAL:platform_font_skia.cc(97)] Check failed: InitDefaultFont(). Could not find the default font <mbakke>marmulak: does 'fc-list' return anything on your system? <marmulak>yeah I have a lot of fonts in the base system, in /usr/share <rekado>civodul: on the video chat front my team tries new applications every week. <mbakke>marmulak: as long as they show up in fc-list, that should be sufficient I think...hm. <rekado>had to install ungoogled-chromium to make some of them work, because who cares about web standards <marmulak>mbakke: I probably can't fix it myself, but let me know if you need anything from me <rekado>for Google Hangouts I thought I could reactivate my abandoned Google account. But to log on they want to send me an SMS — and I have no phone. <rekado>can’t edit my account settings because I need a phone to log in. <rekado>I guess Google is incompatible with my life style. <rekado>had to borrow somebody else’s device with logged in Google account to join the meeting. <civodul>i told them i'd skip the meeting scheduled today on discord.gg *civodul shares frustration <mbakke>rekado, civodul: tell them that matrix.org is the new hot IM thing, and they can even self-host it :) <rekado>the frustration that the requirement for Google accounts causes cannot be felt by those who use gmail and co. <mbakke>andydarcyjewell: can you format the paste so that it is not just a single line? <rekado>from their perspective it’s super convenient <rekado>mbakke: “self-host” seems to be a bad word now :( <janneke>rekado: just suggest that democracy is inconvenient too <janneke>doing what is right is often not convenient <brendyyn>civodul: meet.jit.si is good i think. your work can simply click a link that will work best in their google chrome. since it uses urls you could even set up your own node and use that, they will be none the wiser <mbakke>andydarcyjewell: the last line should just be 'factor' without parens <brendyyn>there is lots of crap in it i dont understand tho, like you can configure TURN servers, which use googles by default i think <mbakke>andydarcyjewell: we've all been there :-) <civodul>brendyyn: yeah, it's pretty good; it just seems terrible that an organization that size would outsource basic services to either non-profits or big corporations ("for free") <andydarcyjewell>wonderful... it did a lot more. now to try to chase the latest error down! thanks for all your help <Kimapr>this is completely unrelated, but i'm making a simple virtual machine <Kimapr>it has a simple custom architecture <rekado>civodul: our institute uses a DFG service, but since *everybody* uses it now people are looking for alternatives that aren’t yet overloaded. *civodul stops ranting (or tries to) <guix-vits>mbakke: aren't Chromium has a built-in fonts? <mbakke>marmulak: just to eliminate a possible source, can you check if 'guix environment --container' works on your system? <marmulak>mbakke: I ran it and it appears to be installing stuff. Appears to be working so far <mbakke>guix-vits: not to my knowledge, at least not our variant (which removes 3/4 of the original chromium tarball) <mbakke>marmulak: it spawns a shell, right? <mbakke>marmulak: ok, thanks for checking. Does IceCat work? <andydarcyjewell>is there a way to stop patch-source-shebangs from trying to patch bogus shebangs in the factor source? I'm seeing errors like this: patch-shebang: ./unmaintained/lambda/lambda.factor: warning: no binary for interpreter `An' found in $PATH <mbakke>andydarcyjewell: you can safely ignore those warnings <andydarcyjewell>mbakke: well, not if it actually patches a factor source file accidentally <mbakke>andydarcyjewell: it only patches the very first line of files that start with #!, and only if it can find the interpreter on $PATH <marmulak>mbakke: it runs but it looks like this, no fonts apparently <mbakke>marmulak: try to 'guix install fontconfig font-dejavu font-liberation gs-fonts font-gnu-freefont-ttf', and then run 'fc-cache -rv' <janneke>some progress on `hurd' pkg cross build, /me rebuilds gcc-7.5.0 another 3 times ***jason is now known as Guest38722
<apteryx>civodul: not sure what are the needs of your team communication, but for chat groups, we have Mattermost at work which works alright (Slack clone of sorts) <apteryx>for up to 3 people you could try Jami, but I think our packaging of it is not stellar at the moment (I've been wanting to take a look at this for...ever) <marmulak>mbakke: fixed. Some of those packages were already installed (font-gnu-freefont-ttf-20120503 and font-liberation-2.00.5 were new) but fc-cache appears to have done something good <civodul>apteryx: thanks; indeed, our Jami package is not functional ATM (it lacks ringd) <marmulak>mbakke: if I want to create a desktop launcher on my distro for this, is it enough to just point it at the guix binary? <mbakke>marmulak: yes, that should be enough and will always refer to the latest generation of your profile <mbakke>marmulak: if you mess with XDG_DATA_DIRS, you can have programs installed to ~/.guix-profile integrate nicely with whatever desktop environment / menus you are using <marmulak>if I were on Guix System would all my packages still by in my user's local profile? Does nothing get installed system-wide? <marmulak>thanks for the tip... I have no idea how XDG works but one day I'll learn! <mbakke>marmulak: you can install packages "globally" (available to all users) in your system configuration, but it's rarely used in practice <mbakke>marmulak: once you get more familiar with guix, you might want to start creating multiple profiles, i.e. not just ~/.guix-profile :-) <marmulak>ah yes, I see the .desktop files in .guix-profile/share/applications <mbakke>so you can have one profile for all your games, one for that web project you are working on, one for emacs, etc <marmulak>well apparently XDG_DATA_DIRS already includes my guix profile <marmulak>maybe I need to log out and log in again <jsoo_>mostly guix does the various paths management for you as long as you source the profile somewhere in a login location marmulak <jsoo_>you are not on the guix system, right? ***ericst_ is now known as ericst
<marmulak>does the password manager even work on ungoogled chromium? <efraim>I found a version of vim I got to work on armhf and then it failed on aarch64 :/ <civodul>efraim: oh, you're looking into the armhf test failure for vim? <efraim>I'm on 8.2.0374 to fix some 32-bit compile bugs and I've deleted src/testdir/test_startup.vim which hangs forever on armhf <mbakke>oh no, guix offload fails after migrating my server to core-updates <abralek>I build guix today in guix environment guix and got this zsh: /home/aabramov/.config/guix/current/bin/guix: bad interpreter: /gnu/store/0awhym5h0m890n0wq87y0dxznh14rk88-guile-next-3.0.1/bin/guile: no such file or directory <mbakke>civodul: 'guix offload test' says 'guix offload: error: unknown error while sending files over SSH' <mbakke>I'll try upgrading the profile of the offload user to 3.0 as well <abralek>mbake: I think you need to install guix under the remote user <mbakke>abralek: sounds like you have garbage collected the Guile that it was configured with <efraim>on another machine I'm working on librsvg@2.46 <mbakke>abralek: re-running ./configure inside the environment should do the trick <abralek>mbakke: guix reports bad inteptreter not only in the environment, but in my profile and root <mbakke>abralek: does /gnu/store/0awhym5h0m890n0wq87y0dxznh14rk88-guile-next-3.0.1/bin/guile exist? <efraim>10 test failures on aarch64 with 8.2.0374 :/ <abralek>aabramov@delta:~/factory/guix$ file /gnu/store/0awhym5h0m890n0wq87y0dxznh14rk88-guile-next-3.0.1/bin/guile <abralek>aabramov@delta:~/factory/guix$ strace -f /gnu/store/0awhym5h0m890n0wq87y0dxznh14rk88-guile-next-3.0.1/bin/guile <abralek>execve("/gnu/store/0awhym5h0m890n0wq87y0dxznh14rk88-guile-next-3.0.1/bin/guile", ["/gnu/store/0awhym5h0m890n0wq87y0"...], 0x7ffee57fa178 /* 99 vars */) = -1 ENOENT (No such file or directory) <abralek>strace: exec: No such file or directory <mbakke>abralek: try adding '-s 1024' to that strace command to see the whole line <nckx>lapinot: ‘guix install cryptsetup’ would probably have worked. On the installer all packages are ‘system packages’ (taken from the system .scm) which you can't upgrade using ‘guix package -u’, but you can install your own copy which takes precedence. <abralek>yeah, i definitely did something wrong <abralek>aabramov@delta:~/factory/guix$ strace -s 1024 -f /gnu/store/0awhym5h0m890n0wq87y0dxznh14rk88-guile-next-3.0.1/bin/guile <abralek>execve("/gnu/store/0awhym5h0m890n0wq87y0dxznh14rk88-guile-next-3.0.1/bin/guile", ["/gnu/store/0awhym5h0m890n0wq87y0dxznh14rk88-guile-next-3.0.1/bin/guile"], 0x7fff3fe63cd8 /* 99 vars */) = -1 ENOENT (No such file or directory) <abralek>strace: exec: No such file or directory <abralek>aabramov@delta:~/factory/guix$ file /gnu/store/0awhym5h0m890n0wq87y0dxznh14rk88-guile-next-3.0.1/bin/guile <abralek>aabramov@delta:~/factory/guix$ /gnu/store/0awhym5h0m890n0wq87y0dxznh14rk88-guile-next-3.0.1/bin/guile <abralek>bash: /gnu/store/0awhym5h0m890n0wq87y0dxznh14rk88-guile-next-3.0.1/bin/guile: No such file or directory <mbakke>abralek: any chance you ran 'guix gc' while /var/guix was unavailable? <abralek>aabramov@delta:/home/aabramov/factory/guix$ ls -lah /gnu/store/0awhym5h0m890n0wq87y0dxznh14rk88-guile-next-3.0.1/bin/guile <abralek>-r-xr-xr-x 2 root root 17K Jan 1 1970 /gnu/store/0awhym5h0m890n0wq87y0dxznh14rk88-guile-next-3.0.1/bin/guile <mbakke>abralek: 17k sounds about right... so the file does exist, but you still get 'No such file or directory'? <mbakke>abralek: can you run 'ldd' on that file? <abralek>➜ guix git:(wip-davmail) ✗ ldd /gnu/store/0awhym5h0m890n0wq87y0dxznh14rk88-guile-next-3.0.1/bin/guile <abralek> linux-vdso.so.1 (0x00007ffd1d52e000) <abralek> libguile-3.0.so.1 => /gnu/store/0awhym5h0m890n0wq87y0dxznh14rk88-guile-next-3.0.1/lib/libguile-3.0.so.1 (0x00007f0e29c3b000) <abralek> libgc.so.1 => /gnu/store/3xs3dnc28p9fi8in7hkfcdx20incrdvq-libgc-7.6.12/lib/libgc.so.1 (0x00007f0e29bc4000) <abralek> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0e29b77000) <abralek> libffi.so.6 => /gnu/store/ain96mrdwqd4s9shdd3s7m4syp5icdx5-libffi-3.2.1/lib/libffi.so.6 (0x00007f0e29b6b000) <abralek> libunistring.so.2 => /gnu/store/nsikjxykcaqa0zjpfmkqd569bngbv5nl-libunistring-0.9.10/lib/libunistring.so.2 (0x00007f0e299e5000) <abralek> libgmp.so.10 => /gnu/store/y7qk8raalgvdnxcglvxa320cfxrjk1x6-gmp-6.1.2/lib/libgmp.so.10 (0x00007f0e29952000) <abralek> libltdl.so.7 => /gnu/store/zasz52va238yyaq68rjm8ljwl4ikij4p-libltdl-2.4.6/lib/libltdl.so.7 (0x00007f0e29946000) <abralek> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0e29940000) <abralek> libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f0e29905000) <abralek> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0e297b6000) <mbakke>well that's odd, it's lacking references to a bunch of libraries <abralek>yeah I found ld-linux-x86-64.so.2 from readelf <mbakke>abralek: what distribution are you on? ***Guest38108 is now known as benny
***benny is now known as Guest90540
***Guest90540 is now known as benny
<mbakke>maybe AppArmor made some of these libraries invisible to 'guix gc'? <mbakke>hopefully there are other Ubuntu users around here who can chime in if some special care needs to be taken <marmulak>hmm apparently the .desktop files that appear in my gnome launcher do this thing where if I pin them to favorites, and then launch them, the window that opens doesn't show as belonging to that app but showing up as a separate item <marmulak>so chromium could open from the launcher but then the launcher shows two chromiums <guix-vits>marmulak: i'd seen something similar (before followed twohot and switched to sway); can you test this with KDE (it has window-list on the panel) or the other something? <nckx>I use Guix on (someone else's) Ubuntu machine (19.10 I believe) and have never had any such weirdness. <marmulak>guix-vits: I can, I'll need some time to install KDE on this sytem <abralek>nckx: Me too actually, but this is the second time I get this. <marmulak>for now the most obvious thing I see right now is that the launcher calls the app "Chromium" (the titles shows when I hover over), but when launched the resulting window is labeled "Chromium-browser" so it probably thinks they're different programs for having different names or titles somehow <nckx>I don't use or GC it often, I'll try that. Have to wait for them to switch it on so I can SSH into it though 🙂 <civodul>abralek: did you pass --localstatedir=/var to ./configure? <nckx>abralek: I used the binary installation method. <nckx>You did add --localstatedir=/var, rite? <nckx>Oh, civodul already asked. <marmulak>also do you guys know why when I run "guix upgrade" sometimes it says it will upgrade packages to the version they're already currently on? <nckx>When logs.guix.gnu.org shows more than your IRC client… <civodul>marmulak: it could be that a dependency of that package changed <civodul>abralek: and did you get a configure warning/error? (you can check 'config.log') <guix-vits>nckx: finally added me to fool list, yes? (joke) <mbakke>we should really change the manual so that it gives the correct configure line, and/or not recommend running the daemon from the checkout <NieDzejkob>is there a reason the correct settings aren't the default? <abralek>civodul: No warnings, localstatedir='${prefix}/var' but prefix='NONE' <nckx>NieDzejkob: GNU standards. <nckx>guix-vits: My fool list is getting impractically longer every day, but no. Why? <guix-vits>nckx: "When logs.guix.gnu.org shows more than your IRC client…" -- i'm generated a lot of post :) <abralek>Thanks anyway, I will take a close look next time. Recovering =) <nckx>Because of the log comment? That's just because I'm on an extremely laggy connexion, not because I've /ignored anyone 🙂 <nckx>guix-vits: Joking on IRC is hard. I fail all the time. <mbakke>civodul: the problem with guix offload was just that (gnu system) still referred to guile-2.2, so the wrong guile was picked up at some point <abralek>mbakke: so guix on the remote is just a workaround? <mbakke>abralek: if the remote is running guix system (as mine does), 'guix offload' works out of the box <mbakke>offloading to foreign distributions requires a bit more setup <apteryx>wondering why diffoscope /gnu/store...item{,-check} always hits the Internet? I've run my build with -K, so everything should be local <mbakke>out of the box, as long as you are not running super experimental branches ;-) <mbakke>agh, I'm unable to build a package with GCC6 on core-updates, no matter how I massage CPLUS_INCLUDE_PATH and friends <mbakke>error: ‘__builtin_isnan’ is not a member of ‘std’ <apteryx>haha, the output is just *very* similar to the Guix fetching output, got me confused. It's not fetching stuff from the Internet. <efraim>I suppose if I'm redoing librsvg@2.46 so it doesn't use any vendored crates I should remove the crates in a snippet <mroh>nckx: no, most of the time you dont fail: I drink coffee around the clock, and often this is very dangerous for my monitors while reading something from you ;) <jsoo_>efraim: are we close to removing all the vendored crates? :D ! <efraim>jsoo_: I have almost 50 patches here for librsvg-next, just need to actually get it to build correctly <jsoo_>efraim: oh boy! nice! thanks so much. <marmulak>I can't figure out how to open the man page for guix packages <marmulak>because it seems to be using my system's man <mbakke>marmulak: if you install 'man-db', then MANPATH will get configured, and the manuals becomes available <mbakke>you'll likely want to append "/usr/share/man" to MANPATH somehow in your login shell however <nckx>mroh: 😊 Greetings from a fellow coffee fiend. <nckx>mbakke: On the absolute ball updating git. Thanks! <nckx>Could someone build python-pykka locally? The build seems to hang forever on btrfs. <janneke>grrr /me's test-cross.scm passes while wxwidgets's configure still fails; me must copy even more careful <nckx>(It's just that this machine has a btrfs + slow RAID + low RAM + fast CPU combo that can trigger interesting timing issues.) <janneke>nckx: does it hang here: test_stop_all_stops_last_started_actor_first_if_blocking (tests.registry_test.ConcreteRegistryTest.<locals>.C) ... ok? <janneke>dunno, that's what my build shell's stuck at for 1m already now <janneke>./pre-inst-env guix build python-pykka @master... <nckx>I've cancelled the build for now; if I do look into it it'll have to be in more controlled circumstances anyway. But there was only one build process running IIRC, nothing to wait on. *janneke too -- all others go flying by -- this seems not OK <nckx>Does the strace look similar? Or if you can afford to leave it ‘running’ — shouldn't use any CPU — for a while so I can be sure this isn't just me I'd be much obliged. <nckx>Thanks regardless 🙂 /me back to work. *guix-vits guix build --check --no-substitutes pythin-pykka <str1ngs>janneke: I did not know about view-lossage. but this would be a good feature for emacsy I think. my guess is this does not exist right now. baring that you can script with nomad but that's not the same as view-lossage in terms of recording a session. *raghavgururajan requests to consider XMPP over Matrix <str1ngs>janneke: also with nomad I've added limited support for browser extensions. not to be confused with browser plugins. so theoretically in the future nomad should better support DOM introspection. so say using something like view-lossage you could do form automation etc. <guix-vits>str1ngs: how to run nomad ("Couldn't connect to DBus for name org.gnu.nomad.webview")? <str1ngs>guix-vits: are you using nomad from guix proper or git? <str1ngs>guix-vits: I'll look into that, it's possible something changed in guix recently. but it's better to use nomad git. there is about 250 revision difference since the latest release. <str1ngs>guix-vits: feature-g-golf is the current development branch <str1ngs>guix-vits: guix environment -L ./guix nomad-git should be enough to test locally <nckx>raghavgururajan: Consider in what way? <str1ngs>guix-vits: I can't replicate your error. have you tried starting nomad with a new terminal. assuming you just installed nomad <mbakke>raghavgururajan: intesting... however AFAICT the issues raised there are present on pretty much XMPP server you'll find in the wild, too. <guix-vits>str1ngs: same error in another tty with sway; but i'm using `guix environment --ad-hoc nomad -- nomad` with and without --pure. Also a week ago i'd tried to install it. Probably i miss some service running. <str1ngs>guix-vits: ahh that makes more sense. nomad had some experimental support for dbus which is probably not available with your session. nomad from git probably won't suffer from this issue. <mbakke>raghavgururajan: the person who wrote that document has nothing else on their github, and is working for a company that appears to sell competing solutions <rekado>bah, it’s hard enough to build tensorflow <guix-vits>str1ngs: as you'd no issues, then it is; i'll try later with %desktop-services and git version, if needed; thanks again. <rekado>why would the cmake stuff be inconsistent with what’s in the source tree? <rekado>referencing files that don’t exist or that have been moved <str1ngs>guix-vits: it's probably not worth that effort. I'd try cloning with git and locally testing with . guix environment -L ./guix nomad-git. then ./configure && make run <str1ngs>guix-vits: I use i3, so it's possible I need to make some fixes for wayland let me know if you have issues building with git. <str1ngs>guix-vits: building should be fine. but let me know if make run causes problems. you can report and issue in #nomad-browser <guix-vits>nckx, janneke: python-pykka: my CPU is silent there: "test_set_multiple_times_fails (tests.future_test.ThreadingFutureTest) ... ok" <str1ngs>guix-vits: I appreciate the feed back and extra testing. <mbakke>huh, the ice cream van just stopped outside. maybe they haven't read the news in a while. <mbakke>dustyweb: probably cups, though I'm too lazy to check <dustyweb>weird for some reason I thought it was something different and pre-cups <dustyweb>maybe because I remember some argument with a coworker 15y ago who said <dustyweb>"who needs cups when we can pipe lpr to netcat" <nckx>dustyweb: CUPS provides a ‘compatibility lpr’ which is probably the only lpr actually ever used now. <mbakke>it's also like 5 degrees here in Trondheim, who wants ice cream now :/ <nckx>Yah. It's 5° here and I want ice cream ☹ <nckx>‘I'll think you'll find I *am* shopping for necessities, sir.’ <civodul>it's 15° here and i want to go outside :-) <civodul>no, i have no idea (i think nobody really does) <nckx>raghavgururajan: That person is certainly doing their best to shoot their own message in the foot by being an insufferable tool, but maybe they're right. Are you simply recommending [m]-folks here consider XMPP, or that Guix should do something? AFAIK we don't recommend Matrix anywhere. Our on-ramp for newbies is Web IRC. <nckx>I'm also sceptical of the security of the average XMPP implementation/deployment in practice. *vagrantc runs xmpp on a device with dubious security but sort of respecting user freedoms <guix-vits>str1ngs: as i'd seen the "patching shebang" line, i'm assume that this is webkit2gtk compiling now. <nckx>Not a dig at XMPP by the way. It's almost 20 years old. <vagrantc>i like that xmpp has good multi-platform support and reasonbly good end-to-end encryption options <vagrantc>and interfaces that many not-highly-techie people might actually use <str1ngs>guix-vits: hmm wibkitgtk2 should have a substitute. are you using substitutes? <jsoo_>can i use emacs-minimal if i only use terminal emacs? <guix-vits>str1ngs: yes, but /gnu/store/h7wh25271mg5pldvb7wvidcv3jzf2p7y-webkitgtk-unstable-2.27.4.drv is compiling, for sure. <vagrantc>guessing emacs-minimal is even more barebones? <jsoo_>thanks vagrantc and str1ngs! <str1ngs>guix-vits: oh one sec, what branch are you on webkitgtk-unstable should not be needed now <str1ngs>guix-vits: ahh sorry use feature-windows. I need to merge that into feature-g-golf <guix-vits>str1ngs: it'd builded to 50%, or should i cancel it? <str1ngs>guix-vits: cancel it's not worth building since guix proper has webkitgtk 2.28 now <mroh>for fixing https://bugs.gnu.org/40015 (which was reported from a female, so i picked that one), I updated docker-compose to 1.25.4. should I send the patch to 40015@debbugs or guix-patches (for a new issue/bug) or (i guess) to both? <bricewge>mroh: Send an email to guix-patches and insert a link to the bug you fixed in your commit. <str1ngs>guix-vits: great thanks for testing. you can install with guix package -L guix -i nomad-git . or add the git directory to GUIX_PACKAGE_PATH <str1ngs>guix-vits: also guix.scm should work as well. which ever you preffer <mbakke>I added a custom ld wrapper using make-ld-wrapper for a package, but it does not add absolute RUNPATH entries. Is there some trick I'm missing? <mfg>hi, does anybody use guile as a scripting language? how is it? <guix-vits>mfg: (((("whole package management built around it")))) <civodul>mbakke: it adds them if it finds libraries passed as -l <civodul>there are env vars to get ld-wrapper to print debugging info <guix-vits>mfg: #!/bin/guile!# (define (println x) (display x) (newline)) (println "Hello, World") <guix-vits>pocket-pdf also available from "Unofficial Texinfo Format" <guix-vits>mfg: i'd forget to say: i'm not a developer. <mfg>that book seems nice, thx for the _info_ ;D <Kimapr>and also (((("whole OS built around package management built around it")))) <guix-vits>nckx: what to do with python-pykka build (it's frozen)? <nckx>guix-vits: Just cancel it, I was simply curious if it was ‘just me’ (it's not). Thanks! <nckx>I'll take a closer look at it later. <bavier`>nckx: why not have straw-viewer inherit from youtube-viewer? <Blackbeard>i am working on my thesis a bit and then I'll work on guix :) <Blackbeard>I have questions about my project, but for now I need to present my thesis <nckx>bavier`: Why do? They'd share 1 field: license. <efraim>I think I found a good vim commit, just want to test it again <mbakke>efraim: is vim really so fragile that it breaks on different architectures with every other version? <nckx>More personally: S-V isn't the kind of ‘Y-V + feature foo’ fork that I'd use inheritance for. They're separate projects that are already drifting apart. But if the author starts cross-porting patches, sure, maybe. Let's see if Y-V even survives. <bavier`>nckx: hmm.. I'm looking closer now at the inputs and arguments and realize they're *slightly* different <nckx>bavier`: Completely personally: what does inheritance even buy us beyond ‘here's a feature we have, let's use it today’? 😛 <bavier`>nckx: yes understood. I would personally use inheritence because it makes the subtle differences more obvious <mroh>mbakke: yes, it is, i have seen these kind problems also in gentoo and debian/sid <bavier`>btw, how much more work is needed for the S-V gtk gui? <nckx>bavier`: If you really think it adds value go for it. I'm going to maintain Guix's S-V going forward but have no interest in cross-checking with Y-V development every time to find out what the ‘right place’ to add new inputs is, though. <nckx>bavier`: Package Perl's GTK module to find out 🙂 <nckx>I was quite suprised that we don't have it yet. <nckx>Might want to double-check. <nckx>Does it have a reputation? <nckx>Didn't seem like a fun thing to package to me either, but I'm not familiar with it. <bavier`>well, not a reputation per se, but there's a few upstream bugs that are making the packaging easier to avoid than tackle <bavier`>nckx: I agree with you on maintaining s-v going forward; the api-key issue in y-v makes it a hard-sell for maintenance <bavier`>I was hoping another os project would create a "public" api key we could use. <efraim>mbakke: sometimes. We've also had a string of bad luck with versions not working on all the architectures <nckx>bavier`: That's exactly what I did for NixOS in days bygone, but that's exactly what Google's cracking down on now. They sent me some mails about that old key and this <https://stackoverflow.com/a/60264537> is exactly their attitude. It's not worth it, and asking a random Guixer/community member to sacrifice their freedom seems, while very rms, wrong. <apteryx>does anyone knows if it's possible to get a notification system atop minimal WM such as ratpoison? I used to get some with Icecat, but not anymore. <bavier`>apteryx: I use ratpoison's native messaging <bavier`>e.g. `ratpoison -c 'echo "Hello, world!"' <apteryx>nckx: will read, so far the Internet returned a photo of Kirsten Dunst <apteryx>'guix show dunst' is more to the point <bavier`>but yeah, ratpoison doesn't have a dbus daemon :) <apteryx>bavier`: that's cool, but how do you plug, say, your browser to this system? <bavier`>not so good for that afaik, I was using it as a dropin for 'notify-send' <apteryx>bavier`: OK :-) That's still cool. I could try setting some notifications for earlyoom with it. <mbakke>nckx: that would be a pretty sweet easter egg :D <apteryx>nckx: hehe. It'd need to use guile-picture. <nckx>‘So why haven't you folks finished the Hurd/Guile daemon/Jami/… yet?’ <nckx> ‘Oh, you know, volunteer time is scarce and w—’ <nckx> ‘Hey howsabout guix show ludo’ <nckx> ‘SAY NO MORE WE ARE ON IT’ <mbakke>perhaps we can bribe sirgazil to make an ASCII caricature :D <sirgazil>I'm trying to package a python thing but I don't know how to run the tests. <sneek>Welcome back sirgazil, you have 1 message! <sneek>sirgazil, guix-vits says: "<Veera>nckx: Only after I type in the passwd the cog wheel shows" -- trouble with the gear icon. <nckx>I don't think sirgazil is responsible for all the pixels in the world, guix-vits. <mbakke>I guess we'll have to pay you the usual fee then. <sirgazil>When I clone the python package and checkout the version I want to package, and install dependencies, I can run the tests like this: "./tests/run.sh" *alextee[m] wants to replace the old centos hetzner server with guix <sirgazil>But I don't know how to do the same thing in the Guix package definition. <guix-vits>nckx: sirgazil asked what trouble was; i'd found this whe read the log. <mbakke>sirgazil: you'll need to (replace 'check (lambda _ (invoke "./tests/run.sh"))) <alextee[m]>are there any server hosts that come with guix preinstalled? <apteryx>sirgazil: most python packages nowadays use pytest, (invoke "py.test") <nckx>sirgazil: (arguments `(#:phases (modify-phases %standard-phases (replace 'check (lambda _ (invoke "tests/run.sh")))))) if it really insists on that command. <nckx>Or yeah what mbakke wrote ages ago 😒 <mbakke>helping people on #guix is also more fun than doing actual work <sirgazil>mbakke: I did, but that gives me "command "./tests/run.sh" failed with status 127" <mbakke>not as fun as planting easter eggs featuring civodul, but still <nckx>sirgazil: 127 means not found. Are you sure you're in the directory you think you are? Could you share the full package? <NieDzejkob>sirgazil: The /bin/sh symlink is not present in the build root <nckx>sirgazil: It's also worth taking a look inside that script. If it does something trivial you might want to do that thing directly. <mbakke>NieDzejkob: it should get patched automatically as long as it's an actual shebang, and not some "/bin/sh" invocation in the middle of the script <nckx>If it's just a wrapper around ‘/bin/sh -c py.test’ I'm going to be annoyed but not surprised. <mbakke>yeah often it's easier to just re-create the script in Scheme <nckx>Wasn't there a ‘new standard’ to run Python tests in town? Or is that py.test? I'm not a Pythonist but overheard something about it. <sirgazil>apteryx: This package doesn't seem to use pytest. <NieDzejkob>Huh, rust-bindgen builds without any special provisions for finding libclang even though it depends on rust-clang-sys which has special phases for that. <mbakke>nckx: "python setup.py test" is officially deprecated, but there isn't really any official replacement <nckx>Oh, great, even better :-/ <NieDzejkob>(it might seem normal if you haven't had to deal with cargo-build-system) <mbakke>the recommendation is to use 'tox' which typically is a wrapper around either pytest or nosetest.. <mbakke>and does not work well in Guix since it wants to go on the internet and download a virtualenv :/ <nckx>This is the build-from-source equivalent of ‘upstream knows best, run their binary SnAppBlobPaks’. <mbakke>I think we're nearing a stage where python-build-system can default to 'pytest' instead of 'python setup.py test' -- pytest also includes support for nosetests *nckx was looking up whom to thank for patching the openssl CVE, of course it's mbakke. _o_ <mbakke>at least when pytest is available, and fall back to the good old setup.py <apteryx>Icecat 68 -> C M k -> window.Notification -> undefined. That explains the lack of notifications in my Icecat, I guess. <nckx>It does mean I'll have to wait about 10 more minutes to test sirgazil's patch, because such is grafting on the raidbeast 😛 <mbakke>or it could be that the script is not actually part of the uploaded PyPI tarball <sirgazil>mbakke: I Added dbus to native inputs thinking that would solve the problem. <mbakke>many python packages strip the tests before uploading to PyPI :/ <nckx>Oh, yes, that's always a fun one. sirgazil: You can run the (failing) build with -K to look inside the build directory, make sure everything's as and where you expect. <mbakke>there is something eerily familiar with that script, I'll need to check my branches :P <mbakke>is there a git command to grep ALL the branches at once? :P <nckx>Are push notifications those super-annoying ‘Would you like randomnewssiteyouclickedonfromddg to show notifications?’ things? Because I've never seen them on IceCat. And I'm sure they haven't just gone away. <apteryx>nckx: yes, they tend to be annoyed; I used to see them before the 62 or 64 releases IIRC. <nckx>sirgazil: I didn't see anyone explicitly saying so, so I will: there's no tests/ directory in that tarball at all. <nckx>I'm glad I don't see them but I guess they can be useful for webmail etc. <nckx>I wonder what the (privacy?) reasons are for disabling them. <apteryx>my coworkers are annoyed at me being for being blissfully unaware of their attempts to contact me over Mattermost in the browser, so I figured I should fix this. <sirgazil>nckx: Ah, I thought the packages generated by guix import used git-fetch instead of url-fetch. I'll try using the former. Thanks. <apteryx>ah, got it: it can be manually enable in about:config with the dom.webnotifications.enabled and dom.webnotifications.serviceworker.enabled options <sirgazil>No wonder why I haven't been able to run tests on other python packages I've tried... <mbakke>PyPI some times include repository URL as metadata, perhaps we should extract that when available <nckx>mbakke: Sounds good. The consensus seems to be shifting towards git-fetch over url-fetch because of SWH. <nckx>Yes, I know, I don't like SingleWord AcroNyms either, but that's what people call it around here. <Veera>I cloned guit.git repo but make authenticate says: No rule to make target authenticate <nckx>Veera: You need to enter ‘guix environment guix’ and run ’./configure --localstatedir=/var’ first. <nckx>And probably a ./bootstrap inbetween. <nckx>They are as old as the Guix you installed. <nckx>Or if you mean on the Web: yes. <Veera>do I have to do guix package -u ... <Veera>No installed from iso image 2019 latest <nckx>Hmno, that won't work because guix isn't part of the set of packages that ‘guix package’ manages. <nckx>Veera: What does ‘info -w guix’ print? <nckx>It should print /home/veera/.config/guix/current/share/info/guix.info.gz <nckx>That is the copy that is updated by ‘guix pull’. <KE0VVT>Are there any nice guides to living inside Emacs? <nckx>Veera: What does ‘~/.config/guix/current/bin/guix describe’ say? Your info pages come from the exact same commit. <NieDzejkob>nckx: The make authenticate instructions are wrong on current master <nckx>Maybe we should back up an—welp, there we go. <NieDzejkob>I mentioned that on the relevant bug, civodul responded "oh well" <nckx>—d figure out why you say it's out of date but never mind I guess. <NieDzejkob>my paraphrasing is not exactly accurate when I've been fighting bugs for too long <sirgazil>Veera: I think https://guix.gnu.org/videos/ is a good way to get started with guix and packaging. And it has an example of packaging R packages, which may be relevant for your contribution period. <nckx>NieDzejkob: Sure. We've all been there. <Veera>It says Generation 1 Mar 20 2020 01:06:07 <nckx>Veera: Yeah. Your manual is as up to date as possible. <Veera>guix environment guix --pure better? <nckx>It's just that the contents are, apparently, inaccurate. <nckx>Veera: Not better, not worse, just the usual trade-off. --pure gives you tighter control over what's in the environment, at the cost of having to add every single dependency you might need (bash, coreutils, <random tool you forget you use>, …) which are otherwise inherited from your normal environment. <Veera>web pages are different that info pages <nckx>The Web pages are pinned at 1.0.1 so they match the installer. There's a sekrit URL to the -devel pages that I always forget. <nckx>Someone will give it below: *nckx high-fives o/ efraim. *efraim always has the page open <Veera>in which directory I have to be in first? <nckx>The directory into which you cloned Guix, the one containing HACKING, CODE-OF-CONDUCT, &c. <Veera>Sorry I deleted those ones to save space when transferring, thinking git checkout will update them, but it is not doing it <Veera>directories are checked out but not the files <Veera>I used debian 10 to do initial cloning <KE0VVT>Does anybody here use Guix in Esperanto? <nckx>Oh, nothing. Switched to zh because I wasn't really using eo in daily life. <nckx>I think civodul uses eo, or used to at least. <KE0VVT>nckx: ĉu la ĥina estas via denaska lingvo? <KE0VVT>nckx: i thought of switching to eo <nckx>Ne estas. Angloj kaj, erm, nederlandajo(?). *civodul nune havas LANGUAGE=eo:ca <alextee[m]>if i have a launcher script for my app that uses the prefix, will guix patch it to the correct directory? <alextee[m]>also something i asked in #gnu: is 'share' always guaranteed to be at <where bin is>/../share on all distros? <nckx>KE0VVT: Kial ne? Mi vivis en Ĉinio. Multaj miaj amikoj parolas ĝin. Ne esperanto. <NieDzejkob>alextee[m]: prefix on guix is usually /gnu/store/hash-pkgname <nckx>alextee[m]: That sounds ominous, like you're writing code that does that. And I'd recommend against it; just use prefix. <NieDzejkob>alextee[m]: I think there's a standard configure flag akin to --bindir <nckx>Mia esperanto estas malbona. 👍 <str1ngs>alextee[m]: does the project use autotools? <alextee[m]>so you think i should use datadir and expect any system that doesn't use that exact path to do the job of patching the path instead of me? <alextee[m]>btw not a guix question, general for all distros including guix <str1ngs>alextee[m]: what you can do is substitute the command path to the full output path for the command. <str1ngs>alextee[m]: seem you want to call the full path for a command? <alextee[m]>i want to specify a gsettings schema directory before i run my app <alextee[m]>so i wrote a launcher script that should do `export GSETTINGS_SCHEMA_DIR=<the dir here> && zrythm` <alextee[m]>and i want the gsettings schema dir to be corresponding to where my app is (not only on guix, but generally on all gnu/linux or bsd distros) <str1ngs>alextee[m]: for this I would use sed to substitute. I know how to do with autotools either with AC_CONFIG_FILES or Makefile.am target <nckx>Then use datadir, don't reimplement the wheel. <alextee[m]>like if i install something under my $home/local and i run that launcher script, i want it to use $home/local/share/glib-2.0/schemas when running my app <str1ngs>alextee[m]: I'm not sure how you would do this with meson though <alextee[m]>nckx: i think that's the best solution too. i think guix will patch the path automatically too <alextee[m]>but also thinking about AppImage and other funky stuff. i hope they automatically patch the paths too <str1ngs>you need to use substitution for this. <str1ngs>ideally at the meson level to effect all distros. <alextee[m]>str1ngs: you mean substitution for the datadir right? <nckx>Patch isn't the right word here, but yes, Guix will call meson with the appropriate prefix= etc. <nckx>You're doing something extremely basic and common. If you need to resort to patching already, reconsider your premises 😉 <alextee[m]>yeah seems pretty basic, thanks for the advice :-) <str1ngs>alextee[m]: basically you add a token and then you substitute the token for the full path. ie in script.in you woudl add GSETTINGS_SCHEMA_DIR=@DATADIR@ . then you substiute that with PREFIX/share <str1ngs>alextee[m]: script.in will generate script . generally you can just use sed for this <alextee[m]>str1ngs: oh okay, yeah i was planning on doing that <alextee[m]>it's pretty trivial to do with meson. it has configure_file where you pass a hash of things to replace, and an input/output file <str1ngs>it's easier to do this with autotools and AC_CONFIG_FILES. so you'll have to figure out the meson way <str1ngs>maybe ask in some meson channel. there might be some syntax sugar that makes this easier. <str1ngs>worst case you do this with guix substition. but that's not distro agnostic of course <alextee[m]>i already know how to do it, i was just askingn if this was the right approach :) <str1ngs>sure. just make a meson target that takes script.in and has an output of script <str1ngs>dunno enough of meson to give you an example but should be as simple as that. <nckx>Like str1ngs said you *could* use Guix substitution to do this, but a lot of work has gone into making standards-conforming packages ‘just work’ on Guix. And they'll work on all other distros too. The ones that break are the ones that make assumptions like ‘$sysconfdir is always in $prefix’. Noes. Don't. <str1ngs>I think autotols uses PREFIX/etc unless you specify --sysconfdir=DIR. but ya some packages assume sysconfdir for some reason <alextee[m]>i still haven't come across any system that doesn't use "share" under "prefix" as the datadir though, i wonder if there's anything that separates them out there <str1ngs>alextee[m]: autotools has --datarootdir=DIR <nckx>str1ngs: Absolutely, that's the [sane] default. With Guix it's sometimes easier to set sysconfdir to something wildly different (vs. patching the makefile to not install example config files, for instance) and it's a pain if that breaks because ‘why would you do that I am clever package uwu’. <str1ngs>generally though you want a uniform disto share directory due to XDG_DATA_DIRS <str1ngs>but guix does not count here of course :P <alextee[m]>XDG_DATA_DIRS is the reason i have to do this hack btw lol <str1ngs>I wonder why GTK moved from autotools to meson. I kinda feel haveing so many build systems seems so NIH <alextee[m]>i was using autotools before too, meson is such a breeze to work with <alextee[m]>everything is so simple and easy and makes you do the right thing <alextee[m]>actually it was the GTK people that made me switch to meson lol <str1ngs>I write my gtk apps using autotools :P <str1ngs>maybe I'm just use to autotools I guess <alextee[m]>that's fine too, i can never wrap my head around m4 <str1ngs>they only draw back to autotools I've found is will windows is not supported <str1ngs>without some cygwin environment anyways <str1ngs>though I only use windows. I'm just looking at a pure portability standpoint. <alextee[m]>all the apps i know use mingw to compile stuff for windows anyway. trust me, you don't want to work with native windows stuff <str1ngs>I just read that as, trust me you don't want to work with windows :P <str1ngs>still I think its good to provide free software to windows uses. not everyone can pick and choose there OS <alextee[m]>also makes it easier to switch later on if you already use free software <daviid>fwiw, I use msys2 (when I have to port something for win users), which provides the right 'settings' to compile/use 64bits app/libs. It has a complete autotoolchain and guile 2.2.6, with posix support (for what it can support) which includes threads