<rockandska>rekado: but having a search engine and command parameters for will be nice <rockandska>we had a conversation sometimes ago to have the possibility to use the "generated" manifest with all the informations needed to rebuild an env from it with the exact same versions (profile construct in the time) <rockandska>is there any following regarding this possibility ? <rekado>re command line for searching past versions: it’s not clear how this would be implemented, nor is it clear how this should behave. <rekado>do you have a suggestion as to how this would be implemented? <rekado>it’s not a good idea to tie this to hydra <rockandska>this is the only place i've found to search all versions of a package <rekado>it also wouldn’t be good to have Guix depend on an instance of Cuirass. <rockandska>but if hydra is on the way out, i don't know where i will find the commit corresponding to an old version <rockandska>(even not relaying on it for the command-line, even manually, it is my only search engine for this purpose right now i'm aware of) <rekado>you can use the git log instead of hydra <rockandska>rekado: that was my first idea, but not much accurate or easy from my first try <rockandska>cuirass should have the same search engine as hydra have now and who is really handy <nckx>rockandska: We should do as much as possible locally, though. A local search engine would be much more valuable than some service. *nckx hit RET too soon. s/service/remote service/ <nckx>One should never have to visit Cuirass to learn about anything one just ‘guix pulled’. Only to find out about the builds on that specific farm. <rockandska>nckx: but will require to have the whole repository locally, and seems to be a huge one, didn't find it locally even after a pulling <nckx>rockandska: If that's what it requires, that's what must be done. <nckx>Does ‘guix pull’ only do shallow clones? Makes sense, I guess. <nckx>Farming (ugh) out git-history-as-a-service isn't acceptable tho'. Savannah regularly goes offline, so will Cuirass. <nckx>$ du -hs ~/guix/.git → 189M /home/nckx/guix/.git <nckx>Not too bad. And that's everything, not just the small subset of data required to map package versions to commits :-) <nckx>Doable! Now somene go do it thx. <rockandska>and after that, the search engine would need to go through each commit to see version changes over the time and use the scm aprser <nckx>rockandska: Sure, host a version of the service on a big beefy public box. Just make it part of guix proper. (Much like ‘ci.guix.info’ is really just ‘guix publish’, available at your fingertips too. Cuirass is just scheduling sugar.) <pinoaffe>nckx: command -v guix prints /run/current-system/profile/bin/guix <nckx>Aha. So your shell was *still* running the wrong ‘guix’ even after ‘hash guix’. <nckx>pinoaffe: Thanks for satisfying my curiosity. I wonder why that happens… <nckx>(You did run ‘hash guix’, right?) <pinoaffe>yes, and it did not work afterwards, but I'm unsure whether I restarted the VM since <pinoaffe>so the command -v output might not be correct, will try again <nckx>pinoaffe: The reason I wanted ‘command -v’ and not ‘which’ was that command is a shell built-in, so it should use the exact same logic that your shell will use when you type ‘guix’. <nckx>‘which’ is a stand-alone tool with similar *rules*, but it can't guarantee that your shell will run what it prints. <nckx>So ‘command -v’ is ‘correct’ by definition, even if it's wrong ;-) <nckx>(That or I completely misread your point.) <lsl88>nckx: my reconfigure ended unsuccessfully. And my bad for not pastedebianing my output. I am running it again. <lsl88>nckx: my teenager computer will not refuse to have guixSD <lsl88>so, unless she wants me to stop defeating her when they say it is garbage, she will run a beautiful GuixSD <lsl88>(will let you know when I have the output to see which derivation was failing) <lsl88>but my echo $? ended with a 134, if that is useful (? <pinoaffe>nckx: this time it seems to have worked after doing hash guix, and command -v showed guix as updated to /root/.config/..... <nckx>pinoaffe: Hm. I guess we'll never know what really happened. <nckx>lsl88: I'm not that deep into Guix that I know its exit codes by heart. Probably a good thing. <nckx>(And probably a Guile thing anyway.) <nckx>A message would be better :-) <nckx>lsl88: How did you deal with the GuixSD → Guix System rebranding? Does it affect your videos at all? <lsl88>nckx: hahaha (for the codes, PLEASE NOT!) .I am thinking.... it doesn't affect the logo, right? Because the videos are for the package manager, even the installation one, is for Guix <nckx>lsl88: Ah, OK. No problem then ☺ <nckx>The logo remains its beautiful self. <lsl88>nckx: if the logo changed, then 1) I NEED A NEW T-SHIRT 2)I've been promoting the community with the wrong T shirt ;) <lsl88>(I gave a talk here in Argentina) <nckx>lsl88: I still have the old logo on my laptop and still managed to convert someone while sitting in my hotel at FOSDEM :-) But yes, our logo is great. It helped convince me that Guix was a serious thing back when I was still a Nixer. <nckx>Not ashamed to admit that. <lsl88>I have the old one - if they were the ones at FOSDEM- on my two machines for working -one has the new one too - and on my termo (where you put hot water for drinking mate) <nckx>lsl88: Yep, that's the one. <nckx>lsl88: I have one of your stickers, but my laptop is full. <nckx>lsl88: Where'd you get that shirt, by the way? Custom order? <lsl88>nckx: mine's too. I want more computers. Maybe if I add a sticker to my teen she accepts her new OS -she had it since last year, I guess before starting the internship, but remaned a bare bones intallation). I really want to have it there to be able to play :). And my T shirt was a gift from one of my mentors :) <nckx>Oh well. We knew that was coming. With output? <lsl88>I will debianpaste the output, but it complains about quemu derivation but afterwards about grub, which is quite understandable I guess, because I made a mistake with the initial configuration and changed the partition <nckx>lsl88: Oh. That's almost the end! <lsl88>nckx: you mean that I should do a fresh install? <nckx>lsl88: Er, no, not at all. I mean that GRUB installation is the very last step of ‘guix system reconfigure’, so you're very close to a (happy) ending. <lsl88>I am taking a look at the error file <lsl88>will paste debian it in a sec <nckx>lsl88: Sure. Take your time. <lsl88>apparently it has to do with memory <nckx>lsl88: Oh. OOM killer in dmesg again, by any chance? <lsl88>sorry for the delay, I have to copy the number to answer from my laptop <lsl88>that is the output of the bzip2 file <lsl88>I will try running the command killing the GUI <lsl88>but I was monitoring with top <lsl88>I didn't mount swap because I thought that maybe it could interfere with my configuration, sorry, my bad <nckx>lsl88: My substitute server has the qemu you need… but ci.guix.info doesn't :-/ <lsl88>I have just mounted and ran again <lsl88>why do you so many servers? and I am doing it the hard way because I want to learn and I want it to work, but if I had to be practical, my machine has no data, I would have done a fresh install in this case <nckx>lsl88: A fresh install would have had the same problem. <lsl88>really? so it is a bug? is it my teenager? <nckx>lsl88: No! It's ci.guix.info being slow to build qemu for some reason. <nckx>I don't have that many servers… I just like being self-sufficient. :-) <nckx>And to customise all my packages so ci.guix.info is of limited use to me. <lsl88>nckx: hahaha I also like that. That was how I learned to read when I was a kid :) But I don't have enough infrastructure and a looooot to learn also <lsl88>ok, I will give it one more try. <lsl88>and then try with your substitutes <lsl88>and then fresh install, I know the steps by heart <lsl88>but I really want to avoid the last option <lsl88>BTW, if I add your substitutes, then how can I tell that by default I want ci.guix.info? <nckx>lsl88: You'd only add them once on the command line. Remember, the --authorized keys don't do anything on their own. <nckx>(And you can remove the key from /etc/guix/acl once finished.) <lsl88>yes, but what I mean is that I want ci.guix.info be the default <lsl88>remember when hydra was down? that we were using the berlin (that now I am knowing that it is the default with another name ;) ) <nckx>lsl88: I avoid the term default. You can use as many substitute servers as you want, they are tried in order. If you have --substitute-urls="https://guix.tobias.gr https://ci.guix.info" like I do, Guix will try guix.tobias.gr first, *then* ci.guix.info. <nckx>But Guix also ships with %default-substitute-servers (I think that's what it's called) in the code, which it uses when you don't specify any on the command line or in your operating-system. <nckx>That's currently only ci.guix.info. <nckx>Does that make any sense? <nckx>Adding a server's public key means you trust it, but doesn't automatically make Guix use it. The two acts are separate. *nckx isn't that good at the explaining of the things. *lsl88 says that nckx is very good at explaining but she wants to set the "default" <nckx>lsl88: Would you like to set ci.guix.info as the default? <nckx>Because then you don't need to do anything. ;-) <nckx>And if you want to add a different server just once, use ‘guix xxx --substitute-urls="https://ci.guix.info https://some.other.server" xxx’ and Guix will download as much as possible from ci.guix.info, and only download from some.other.server what ci.guix.info is missing. And it will only have effect for that one command. <nckx>I'm afraid I can't do better than that. *lsl88 tells nckx that shouldn't feel overwhemeed by their explanation <nckx>(But that won't work if you haven't told Guix ‘I trust some.other.server’, which is what ‘guix archive --authorize’ does. But you only need to do that once. Even if you never use some.other.server again, it won't hurt.) *lsl88 brb, my dinner is getting cold and there is a gas shutdown in the block of flats <lsl88>nckx: if you have to go to bed, don't mind <nckx>lsl88: Bed? It's still dark out. Enjoy your dinner. <lsl88>nckx: but don't you live in Europe? <tune>Blackbeard[m]: fixed the problem how? <lsl88>nckx: it should be about 3 am there, isnt it? <lsl88>do you sleep during the day? <nckx>It is and not really. I don't sleep much. <lsl88>nckx: and how can you work and think without sleeping well? <lsl88>yeah, it failed again, will use your substitutes <nckx>lsl88: Who says I do? :o) <nckx>(I sleep well, just not for long. Tried all kinds of crazy polyphasic sleep schedules when I was at uni. Those were the days. And nights.) <lsl88>nckx: in my case if I don't sleep at least 6,5h per day zombie mode <lsl88>a bad zombie mode. And i can ask you things that I already know, or make a horrible mistake. <lsl88>when I was at university, I studied hard due to impostor syndrome that I keep having, but i always chose to sleep well. Studied long hours, but even when I had classes in the morning the first years, I had a nap before starting studying <nckx>I have close to zero tolerance for missing or disturbed sleep. If I miss 1 hour of sleep I'm probably more of a zombie than you after 5h. <nckx>lsl88: Good. I learned that a year too late… <nckx>buenouanq: Yes! >24h cycles are so much better. <lsl88>nckx: and buenouanq but how do you do with your work? I mean, if you have a fixed schedule then you can't do that <nckx>lsl88: I study and work (mostly) from home. It's a luxury I won't have much longer. <nckx>> Re: [apology] Falling asleep during the meeting (again) <lsl88>nckx: yes, i know, that was good about outreachy <lsl88>I want you to go to bed, really, if tired. <lsl88>with your substitutes I am a step further <nckx>lsl88: I take care of myself, don't worry. <nckx>Yes? Good, because I didn't see a request for zsp966m61a7gavv797h0qzcan78klyd1.narinfo (the qemu-minimal one) and was a bit worried. <lsl88>I only get the error: guis system error: symlink: permission denied "/var/guix/profiles/system-2-link.new" <lsl88>should I run reconfigure as root? I don't remember having to do that before <nckx>lsl88: ‘guix system’ is the only Guix command that (often) needs ‘sudo -E’. <nckx>The -E is very important. <nckx>lsl88: Reconfigure is always done as root, it wouldn't have worked otherwise. *nckx ^R s absolutely everything and never remembers commands, but this they know. <nckx>(In case you're wondering: the -E keeps most environment variables intact, so the guix running as root is the guix that you ‘guix pull’ed as a regular user. Otherwise you'd use root's Guix, which might be out of date or otherwise broken, and would have to be maintained separately which is at best a burden. So we use lsl88 's guix for everything, even as root.) *lsl88 also forget commands, I know that "there is a command that allows me to ..." thought that I was the only one. And that worries me and made my impostor syndrome worse <lsl88>nckx: it worked! will reboot and see what happens <lsl88>will tell you tomorrow if you are here *lsl88 says thank you for helping :) *lsl88 is not a mother ¬¬ don't have children *lsl88 complains living in South America. I get mails form FSF and want to be there :( ***renich_ is now known as renich
<rvgn>Can someone please suggest a good platform to write software manuals? Other than readthedocs as it requires me to have a repo. <Blackbeard[m]>I tried guixsd before and i remember downloading Firefox but it would not run <Blackbeard[m]>2. Also about Krita, are there still problems with kde libraries, or i should be able to compile it ? <Blackbeard[m]>Firefox i downloaded the binary from the website and tried to run it but it didn't work <Blackbeard[m]>Compil Krita from source code on Linux for cats - David Revoy <Blackbeard[m]>cmake -DCMAKE_INSTALL_PREFIX=$HOME/krita/inst $HOME/krita/src -DWITH_GMIC=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo -DPRODUCTSET=ALL -DPACKAGERS_BUILD=ON -DBUILD_TESTING=OFF -DKDE4_BUILD_TESTS=OFF <Blackbeard[m]>the only thing that i am worried about is long compilation time <efraim>if I want to declare my own xorg-modules, its '("one" "two" "three") or '(one two three)? <roptat>efraim, %default-xorg-modules is a list of packages, so neither symblos nor strings <allana> Hi guix! I have a mostly minimal guix system configuration, and I <allana> manage almost all of my packages in my user profile. I have a habit <allana> of running "sudo guix pull" and "guix pull" every day. Is it <allana> necessary to guix pull twice as I am doing, or is once enough? <allana>Sleep_Walker: thanks, glad to hear that it's a common pattern. <Sleep_Walker>allana: well, I'm curious now as well for answers of others... <allana>Although there is something that feels funny about it, like there must be a better way. <civodul>allana: no need to run "guix pull" twice <civodul>what i do is that i run "guix pull" only as my regular user <civodul>and then i do "sudo guix system reconfigure" when i want to <kmicu>nckx: lfam: ^^ and that’s how ‘always use sudo -E’ or ‘You almost never want plain sudo’ was crashed xD <efraim>i figured I could work on it by playing with the package definitions and seeing if it want to rebuild that driver or if my list works <efraim>so far explicit list works, 'fold remove %default-xorg-modules' doesn't <kmicu>(There is also Guix System manual’s 6.1.5 saying directly that ‘From then on, you can update GuixSD whenever you want by running guix pull as root’.) <rekado>Blackbeard[m]: we have the huge texlive package, but you may also find the modular texlive packages to be sufficient. *kmicu would appriciate consitent guidlines for newcomers how to canonically update Guix System. Then we should stick to that when helping newcomers on IRC. <rekado>kmicu: I believe there used to be a bug which made “sudo -E” necessary. *rekado pushed some fixes to 389-ds-base and managed to configure a little LDAP server <rekado>next step: write a simple LDAP directory server service; then revive the nslcd authentication service changes that I had stashed away for months. <kmicu>Should we, users, follow civodul’s (core developer) recommendation above and ‘guix pull’ as regular user or should we follow the manual recommending running guix pull as root? Should we use ‘sudo -E guix system reconfigure’ or ‘sudo guix system reconfigure’? Consistency = less confusion for newcomers. <htsr>Hi, I'm trying to install GuixSD with qemu but I have an error <htsr>When I try execute the command herd start cow-store /mnt this is what I get : <htsr>herd: service 'cow-store' could not be found <htsr>On Matrix someone pointed that the 'cow-store' service is missing from the disk-image <rekado>what installation image are you using? From where did you download it? <roptat>htsr, it's not an installation image, it's a qemu image already <roptat>you don't need to install anything, it's already installed ;) <roptat>if you want another system, you just guix reconfigure with your configuration <htsr>Ok :) , the manual is not very clear <htsr>"You’re now root in the VM, proceed with the installation process. See Preparing for Installation, and follow the instructions." <kmicu>That first step in ‘First, retrieve and decompress the GuixSD installation image as described previously (see USB Stick and DVD Installation).’ asks about regular ISO image. I see how that can be confusing. Manual could link directly to needed images. <kmicu>But, hey, IRC can help too ヽ(*＾▽＾)／ <rekado>htsr: I know nothing about nftables, but I don’t think we have service bindings for it. Would you like to give it a try to write service bindings and contribute them to Guix? <rekado>htsr: be sure to ask for help here on IRC or on help-guix@gnu.org — we don’t want you to give up in frustration. <rekado>apteryx: why do you double unquote on line 118? <rekado>to escape the “arguments” expression? <apteryx>rekado: the cmake-minimal builds fine <rekado>on line 158 add ` before “(append” <rekado>and add , before configure-flags in (append configure-flags…) <rekado>just like you do on line 164 (where it’s done correctly) <rekado>the default value for configure flags. <apteryx>indeed! I just tried removing it and it works... I'm not sure I understand why? Shouldn't (append '() '("some" "list")) works? <apteryx>any clue as to why the double quoting is needed here? <apteryx>I think it has to do with how the build system passes the arguments around, I see (configure-flags ''()) in (guix build-system cmake) as well <htsr>The manual should give command to resize the virtual size of the qemu image (I can't guix pull because it's too small) <apteryx>but still my understanding is naive ;-). I have to run. <roptat>htsr, from the motd of the system, you already have some hints (but no full command, sorry): 0) deleting and recreating the partition with fdisk, 1) reloading the partition table with partprobe, and then 2) resizing the filesystem with resize2fs. <htsr>roptat: I think it's possible to do it before launching the vm with the virt-resize command <rekado>htsr: if you think that there’s a better way, I’d like to encourage you to submit a patch or to discuss the possibility of a patch on guix-devel@gnu.org. You might be right and we missed an obviously better suggestion. <civodul>kmicu: re "sudo guix pull", commit 796a4491fdaa4a0a3d669457b89356f9fbfc966e hopefully clarified things <rekado>anadon: you may need to try a different key server. <roptat>I'm trying to list packages that (implicitely) depend on dune, but guix graph --type=reverse-package dune only outputs one node for dune <civodul>you would need reverse-bag or something <civodul>but note that your best bet may be --type=bag, and then use gvpr to filter things out <civodul>g_bor[m] demoed that to me at the Guix Days <roptat>I was just surprised at the number returned by guix refresh <civodul>but really we could add reverse-bag if it's not already there <civodul>right now i'm focusing on keyboard layout :-), so feel free to look into it <civodul>otherwise i could look into it later if needed *rekado builds qemu for an LDAP system test <nckx>civodul: Hehe. I forgot about my spam… It i did! <civodul>rekado: it means you can have a break (or write doc) *nckx updates iproute. Note that this version removes DECnet support. <rekado>I was going to write about texlive for the manual, but since package names are likely going to change soon I’ll wait it out… :) <rekado>and now I’m downloading a different version of qemu. Huh. <rekado>(built qemu-2.10.2, downloaded qemu-3.1.0) <mbakke>rekado: Qemu 2.10 is used for GRUBs test suite. <anadon>`guix package: error: build failed: the group `guixbuild' specified in `build-users-group' does not exist` -- Do I need to manually issue a `groupadd`? <anadon>I'm also running into rather loud warnings about locales. <rekado>anadon: look at the installation instructions again. They show you how to create all of the build users and the group. <anadon>rekado: Section 2.1? Or is there a different document I should be looking at? <efraim>I assume we don't want to import (guix build qt-utils) into package modules? <rekado>anadon: section 2.1 talks about using the installer script (which automates all of this), but if you absolutely want to do this manually be sure not to ignore step 4. <efraim>i would love to use wrap-qt-exectuable in packages <anadon>I may have blanked over the installer script. One second. <roptat>shouldn't we add a link to the installer script on the download page? <anadon>rekado: The GPG server errors from earlier cause the script to fail. <roptat>anadon, the fact that you started installing would cause the script to fail too, anyway <rekado>roptat: we link to installation instructions. At the very top it mentions the installer script. <rekado>in more recent version of the manual that’s highlighted. <roptat>anadon, as rekado said, make sure to follow step 4 (it's only one line, so very easy to skip) <anadon>But there does seem to be a reproducible and consistant failure related to the GPG servers that needs to be looked at. <rekado>anadon: it’s a pool of GPG servers that are not under our control <rekado>sometimes you’ll get a server from the pool that’s unreachable <rekado>in that case you’ll have to fetch the key by yourself <anadon>If it is a pool, and multiple entry points are not working, something odd is going on. <rekado>civodul: I’d like to automate the updating of guix.info and the manual hosted there. This depends on the Guix sources, though. I wonder if this could be built with Cuirass…? <anadon>How would I manually fetch the key for Guix? <efraim>There's also the copy ludo hosts, I don't remember where it is but it's in his email headers <efraim>Looks like the key uploaded is invalid <efraim>until gpg --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5; do echo "trying again..."; done <anadon>I mean, eventually in all of eternity there is a statistical convergence that it will _eventually_ work. <nckx>(Not meant as a dig at efraim, obviously.) <rekado>there are no substitutes for a great many packages <rekado>I’m building a bunch of ghc-* packages now with the latest version of Guix <apteryx>mbakke: I've just sent a patch for cmake + docs. This should go to core-updates. <mbakke>apteryx: Nice! LGTM at first glance, will have a closer look later. <mbakke>apteryx: It would be nice to move the configure flags to #:configure-flags while at it, instead of hard-coding them in the configure phase. <apteryx>mbakke: yes, we could do this and the 'new' cmake variable supports it. I can have a go at it. <rekado>I really shouldn’t have to build basic Haskell packages like ghc-yaml. I wonder if berlin is stuck building them…? <rekado>or rather: something wrong with the acl on this system <mbakke>rekado: I suppose they've been garbage collected, and berlin never baked any NARs in time. <rekado>no, looks like my /etc/guix/acl has again been reverted <rekado>I wonder if that’s puppet’s doing. *rekado stops worrying about the build farm <civodul>rekado: re missing substitutes, we should pick some of the missing substitutes and see what their status is <civodul>oh you're saying it's PEBKAC after all? <rekado>I think there may be some puppet automation that results in /etc/guix/acl to be reset *civodul to become an XKB wizard <mbakke>civodul: How do you fit so many wizard hats? :) <civodul>i had never really wondered about how this all works <mbakke>We should create some for next FOSDEM. <civodul>and i hadn't really plan to study it either :-) <rekado>it would be nice if the “name-service-switch” field in the operating-system record could be replaced with a system service instead. <rekado>this would allow us to automatically extend it. *rekado writes documentation for the nslcd-service-type <vagrantc>hrm. so i tried to add DM_CRYPT and freinds to the aus-c201/veyron-speedy kernel i've been working on, and for some reason on armhf it pretty much hangs indefinitely when doing any significant work on a crypted device <sneek>vagrantc, you have 2 messages. <vagrantc>that seems like that should be easy enough to patch... <apteryx>mbakke: I'm not sure it's possible to pull all the configure arguments out of 'arguments' for cmake, as we are using "out" which AFAICT is only made available on the builder side (inside build phases). <roptat>It happened again! The sd card seems to be corrupt again after guix pull :/ <roptat>Sure, I think that's what I'll use <vagrantc>i haven't run a cubietruck with recent kernels, but currently only use microsd for u-boot, loads kernel+initrd+dtb from sata partition just fine <mbakke>apteryx: You should be able to `(assoc-ref %outputs "out")` anywhere in arguments. <mbakke>(note %outputs, not the regular scoped "outputs") <vagrantc>so really disappointed i'm having troubles with encrypted rootfs with the asus-c201 ... kind of kills it for me ... not sure if i'm just missing some kernel options <apteryx>mbakke: ah, right, configure-flags *is* under arguments. eh. <roptat>vagrantc: how do you connect your sata disk to the board? I have a spare 2.5'' and a 3.5" too I can use :) <roptat>I have the extension board and cables, but not sure how to connect everything <roptat>Also not sure about voltage and such <vagrantc>roptat: it's been a while since i plugged it in, so not sure :) ... just used low-power ssd <roptat>Seems like I can power the 2.5" disk <vagrantc>yeah, the 3.5 probably would require external power <vagrantc>spinning 2.5" laptop disks i've had mixed success with; some draw too much power for little boards <vagrantc>anyone using pigz to compress the initrd instead of gzip ... it almost looks like it should be configurable in linux-initrd.scm <vagrantc>debian recently switched to using pigz for initramfs-tools, and it really makes a huge difference in time it takes to build the initrd <vagrantc>and if guix size is any indicator, pigz vs. gzip has a slightly smaller dependecy set ***englishm_ is now known as englishm
<htsr>I'm trying to guix pull but I have an error, the downloaded tar.xz for binutils-2.23.2 doesn't have the expected hash <nckx>htsr: Can you share (see pastebin in channel topic) the output? <nckx>htsr: And which branch is this? master is still on 2.31.1 AFAICT. <htsr>nckx: how can I tell which branch I'm on? <anadon_>I'd like a point of clarification: two packages installed with mutually incompatible runtime libraries do or do not work with guix under the same user at the same time. Which? <nckx>htsr: If you don't know, I must be mistaken. guix describe. <nckx>anadon_: s/user/profile/. Do they have the same file names? <anadon_>The two hypothetical packages would have different names, but their runtime dependancies would have the same name. <nckx>anadon_: But file names, as in two incompatible libraries both named /lib/libfoo.so.3.2? [Setting aside for how this is a huge red flag about the software itself, and it's not Guix you should be worried about.] <anadon_>Yup. Very alpha python stuff in a wider computing system, so that is a thing. <nckx>If the libraries are propagated so they end up in the same profile, then Guix would pick one at random, but this is such a broken situation that there's no sane way out anyway. <anadon_>Python does everything at runtime, so that is not something I have great control over. *nckx is not a Pythonist. <htsr>nckx: here the output of guix describe: guix describe: error: failed to determine origin <htsr>nckx: Maybe I've forget to run guix package -u after my first guix pull ^^ <nckx>htsr: ‘guix pull’ should immedately provide a working ‘guix’, no ‘guix pull’ necessary. <nckx>So something smells borky. <anadon_>Oh yeah, python is a peice of work. It only makes sense for a single user single project approach from what I get. There are ways to force it to work in various other convoluted ways, but they are not perfect. See: Python Poetry. <anadon_>Also virtual environments. If Guix could meet those kind of runtime isolation requirements, it would be utterly perfect. <anadon_>Like, toss out my companie's entire package management systems perfect. <nckx>anadon_: In general, I'd say: if it can be made to work on non-Guix systems (using virtual envs or whatever, look I know a Python word) it has to be able to work on Guix. But you'll have to talk to a more Pythonic Guixer than I am. <nckx>If none are here at convenient times try the ML. <anadon_>I'll do that. Maybe it'll end up as a feature request. <nckx>anadon_: If it's possible at all, it's possible already. It might just involve wrapping the leaf packages in a diffent way. <nckx>(Wrapping > propagated inputs, but I know Python is ‘special’.) *nckx will now shut up about a language they do not speak. <anadon_>I'm still wrapping my mind around Guix. It changes a lot of how I view package management. Still integrating this knowledge. <rekado>htsr: which Guix are you using? What does “which guix” say? <rekado>htsr: after “guix pull” you should have ~/.config/guix/current/bin/guix. Try using the full file name. *anadon_ will admit that python is a special snowflake. <nckx>rekado, hstr: Try ‘command -v guix’ instead. Someone in here yesterday got bitten. <rekado>Generally, we set PYTHONPATH automatically, and that’s not great when the profile contains both Python 2 things and Python 3 things. <rekado>because Python will load *anything* that’s found on PYTHONPATH, even if it’s incompatible (e.g. a Python 2 module will be loaded by Python 3 if it’s found on PYTHONPATH). <rekado>we had a discussion about implementing alternatives, but it died down without conclusion. <rekado>I’d love to see an alternative eventually. <rekado>relying on PYTHONPATH is not satisfactory. <rekado>it works fine for the most part, but the failure modes are very uncomfortable. <htsr>nckx: which and command return the same thing /run/current-system/profile/bin/guix <nckx>htsr: That is the ‘old’ guix. Try ‘hash guix’ and try again. <htsr>nckx: hash guix then command or guix pull? <rekado>“command” first, so that you see what you get when running “guix”. <nckx>and if it's different now: guix pull. <lfam>Hm... curl is not keeping references to libssh2. What's going on there? <nckx>htsr: Er. Hm. That happened to someone yesterday. It's not clear to me how. <nckx>htsr: Set PATH="$HOME/.config/guix/current/bin:$PATH" for now, then, I guess. <nckx>Maybe ‘hash guix’ again too. ‘command -v guix’ should then print the right guix, your current shell should find it, and at least you can continue. ***Elon_Satoshi is now known as Copenhagen_Bram
<anadon_>rekado: Can you link me to the discussion? <htsr>nckx: I'm trying to get to output of guix pull out of the vm but I can't connect with ssh <htsr>And the change in the PATH didn't work <htsr>I think I will keep this vm just in case and try to install Guix on another <nckx>htsr: Then there is no guix at ~/.config/guix/current/bin/guix ? Does ‘which -a guix’ show any stray guixes lying around? <htsr>There isn't any ~/.config directory, and which returned the same thing <nckx>‘guix pull’ should definitely create .config/guix/current/bin/guix. That is its purpose. I don't know what to say. <htsr>If I use the qemu image I don't need to do anything to install it like with the iso because it's already ready, right? <efraim>it looks like I have a working kde-connect on my enlightenment desktop! <lfam>Very cool efraim, that's awesome <efraim>getting popups from quassel on my laptop and from quassel through kdeconnect on my laptop <efraim>as far as I can tell it works just fine run as my user, no system service needed <vagrantc>was toying with the idea of partitioning a dm_crypt device, but might have to put a loopback device on top of the encrypted device to get that ... i guess i'd also need to figure out/enable loopback device support <nckx>vagrantc: dannym posted something to do with loopback booting to the ML very recently. It was for another purpose (booting from ISO images) but might overlap? <civodul>rekado: re nss, i agree we should make it extensible (currently we can extend nscd but not nss) <rekado>I just added the nslcd-service-type with a system test. I’m not 100% happy with it, though, because things like “id” don’t work without setting LD_LIBRARY_PATH. <rekado>I hope I can tweak this some more and then use it on the workstation in the office to finally replace Fedora. <roptat>I'm installing a guixsd system from a foreign distro installed on another distro, so I don't have cow-store. What should I do to ensure it can boot? <roptat>Should I simply copy /gnu/store to the other partition? <vagrantc>i think without the cow store it's just a slightly slower copy operation <vagrantc>e.g. builds and copies to /gnu/store, and then copies fron /gnu/store to /mnt/gnu/store <vagrantc>guix system init has worked in my experience <civodul>rekado: this looks like the mdns_nss thing: you need nscd to have libnss_*.so in its LD_LIBRARY_PATH, and for that you need to extend nscd-service-type <vagrantc>whereas i think with cow-store, it just overlays the two stores together somehow so that new operations only land in the new store? <vagrantc>my rough very rough understanding, happy to have better information :) <civodul>rekado: and then you need to make sure your applications resolve names via the nscd and not locally <rekado>I have extended nscd-service-type <rekado>don’t know how to make “id” resolve names via the nscd. <rekado>(it does work when I set LD_LIBRARY_PATH in the current shell session, though) <civodul>programs that use glibc first try to connect to the nscd and then fall back to local things <roptat>vagrantc: ok, it seems to be copying stuff now, so you might well be right :) <civodul>rekado: so you need to make sure nscd is up and running by the time "id" runs <nckx>roptat: cow-store is just a hack (in a good way) to make sure you don't fill up the RAM-disc /gnu/store of the live installer. It's not needed when installing from another system. <roptat>I hope u-boot is able to find the kernel and initramfs on the disk though <nckx>It might have unintentional speed benefits if what vagrantc says is true. I never thought of it that way. <civodul>rekado: the "nss-mdns" system test (which in fact doesn't quite work :-)) shows how to do that <roptat>I've read that you can't put u-boot itself on the disk, so I'm a bit worried <vagrantc>you still need to install u-boot itself on microsd <vagrantc>but u-boot can load from sata on that platform <vagrantc>(haven't specifically tested cubietruck on guix, but works fine on debian with same u-boot version) <vagrantc>heh, i even responded regarding the loopback devices in initramfs <rekado>civodul: ah, I see. I’ll give this a try. *rekado updates R packages in the background <roptat>And… I've successfully rebooted… to the foreign distro <roptat>Not sure why, the u-boot config seems ok, it's installed to the sd card <vagrantc>roptat: i didn't think it could handle split /boot ? <vagrantc>does it have an extlinux.conf in guix's /boot/ ? <roptat>Ah, I don't have a split /boot, is that what you mean? <roptat>Yes: /mnt/boot/extlinux/extlinux.conf <vagrantc>the boot order is probably/unfortunately probably microsd before sata, so that might be what happened <roptat>But that's no the same drive as the one on which u-boot is installed, could it be an issue? <roptat>Ah, so u-boot looks for extlinux.conf on any partition <vagrantc>interrupt u-boot and boot, and at the u-boot shell: setenv boot_targets sata0 && boot <vagrantc>any partition marked bootable, failing that, the first partition <roptat>Mh… I don't think I marked the partition bootable <roptat>Error: bootcmd_sata0 not defined <vagrantc>ok, now i need to check to make sure i haven't lead you entirely astray... <vagrantc>nope, i definitely have /boot on the sata device <roptat>I see "SCSI: SATA link 0 timeout" <vagrantc>u-boot is kind of arbitrary weather devices are called sata or scsi <roptat>boot_targets=fel mmc0 scsi0 usb0 pxe dhcp <roptat>so "setenv boot_targets scsi0 && boot"? <vagrantc>scsi rescan (or something like that ... "info scsi" should tell you) <roptat>I think the internet implies it's a power issue <lsl88>nckx: here I am. She accepted the reconfigure but the swap does not auto mount