<mbakke>joshuaBPMan: What happens when you try to launch one? <degauss>Here the sample output (hope it's not too long): <degauss>$ LANG=C guix package --dry-run -u python-jsonschema <degauss>The following package would be upgraded: <degauss> python-jsonschema 2.6.0 -> 3.0.1 /gnu/store/va4hgdfx8zbqzyah7vgqkm25g60p8lf3-python-jsonschema-3.0.1 <degauss>guix package: error: profile contains conflicting entries for python-attrs <degauss>guix package: error: first entry: python-attrs@18.2.0 /gnu/store/awb7awycpf1crpd1kllvk6qzchd4g7lw-python-attrs-18.2.0 <degauss>guix package: error: ... propagated from python-jsonschema@3.0.1 <wr>how do i install lxde on guix? <atw>wr: hello! If I were you, I would put lxde in the (packages ...) section of your operating-system. That way, sddm/slim/gdm should be able to find lxde and offer it to you as a choice at graphical login <wr>atw, i installed the guix with no DE, now i need to put something <atw>did you install GuixSD, or did you install Guix as a package manager on another distribution ("foreign distro" installation)? <wr>GNU Guix System 1.0.0 <atw>OK! and what distros, if any, are you familiar with? <brendyyn>I'm wondering did degauss get kicked for pasting all that? <atw>thanks, was gonna use that to tailor my answer :) so would you prefer to use slim/sddm/gdm, or to do startx yourself? <wr>atw, what distro would you say is most likely similar to guix? <atw>I would say Nix, but that's a bit of a cheap answer; Guix is based on Nix and uses Nix's build daemon (and for the record, I haven't used Nix) <atw>personal opinion: I think that Guix as a package manager has a bit in common with Homebrew as both use a general-purpose programming language to define packages, and I /think/ that's rare-ish. I'd love to hear the opinion of some more experienced people in the channel :) <oneness>Hello there, I am using the guided installer to install but got this error: .../grub-install --boot-directory /mnt/boot --bootloader-id=Guix --efi-directory /boot/efi exited with status 1 error message is failed to get canonical path of '/boot/efit'? Anyone had similar issues? I assume the the bios not get detected and defaulted to efi? <oneness>shoud be /boot/efi not /boo/efit. A typo <samplet>oneness: Are you saying you know for sure that it should use BIOS? If that is the case, you should be able to fix it manually. <samplet>If you can access the console and edit the configuration file, you can tell it not to use EFI. <oneness>Thanks samplet. Will change bios seeting to use legacy first to see if it is the issue <boogerlad>guix package --roll-back goes back a generation for the packages, but the guix version itself is still the same. I know you can access old guix versions in ~/.config/guix/, but if I wanted to remove some generations, how would I do that? <brendyyn>I think it may not have been implemented yet, but i think you may be able to do it using --profile and treating guix its self as a profile <boogerlad>I see "guix package -p ~/.config/guix/current --delete-generations=1" from "invoking guix pull" in the manual <boogerlad>if this is the suggested way, it seems pretty trivial - are there any edge cases that are preventing this from being implemented? <brendyyn>-p is --profile. That's what I was thinking of <boogerlad>if not, maybe it'll be my first contribution to guix =P <brendyyn>I'm not sure. It may be a simple matter of people being busy with all the other things they want to work on. <wr>atw, i made a interval starting to retake this <wr>atw, i'm starting to think that i need to read the manual a bit <crab1>0x0.st/zTU2.drv What does this mean? Trying to build a system configuration <atw>yup, that's the nix I was ref referring to <atw>I do not know offhand about the build error you ran into there. could you paste the build log (from /var/log/guix/drvs/pv/457...-lightdm-1.24.0.drv.bz2) with a paste service? https://paste.debian.net is liked <atw>please bear with me as I continue to make mistakes and not know things :) <atw>and heads up, I have to go to sleep at some point here <atw>sneek_: later tell crab1 could you post your operating-system config and talk a bit about how you're installing? <nlyy>What are profile hooks used for? <donofrio_>so ifI am compiling I need all these dependancies compiled into my /app directory I take it or can I just get these dependencies installed by os folks and keep within our /app directory for normal use (package updates and etc for /app is what I want/need) <donofrio_>also will this work on non-sse2 hardware (aka power8) <efraim>Work is ongoing to get powerpc64le support into Guix <efraim>If you're on power8 it you don't have to worry about using a different prefix than /gnu/store since we likely won't have any substitutes for a bit <dftxbs3e>efraim - donofrio_: https://gitlab.com/lle-bout/guix - powerpc64le (version 1 patched for powerpc64le support, /!\ you are trusting my bootstrap binaries) - powerpc64le-bootstrap (version 0.13.0 + some cherry-picked commits to cross compile bootstrap binaries, use this if you don't want to trust my bootstrap binaries, and then patch them in the powerpc64le branch) ***MinceR_ is now known as MinceR
<PotentialUser-41>Hello, Guix people! I've heard about the release of 1.0 and wanted to try it out on my minifree X200T, but I'm having some network issues after the successful install. When connecting to a WPA2 secured WiFi it keeps asking for the password without ever connecting. Open WiFis work. Could someone give me a pointer of where to start searching? Used gr <PotentialUser-41>According to Minifree it's “Upgraded with an 802.11n wireless card (Atheros AR5B95, AR9285 chipset), ensuring full compatibility with free drivers in GNU+Linux.” <PotentialUser-41>Also, hi; and thanks for your support. :) Any idea where the relevant log files should be? <cjb>does the x86_64 iso boot on systems with a 64bit CPU but a 32bit EFI? <cjb>efraim: hm, ok thanks. <g_bor[m]>Just an idea, what do you think about an extract-and-copy-build-system, that would extract the source like gnu-build-system, and then copy the exctracted source to the output? I believe this might be useful when we have something that can be used as is, without any further transformation. The idea came from trying to get a static website configured. This could be done very easily with what we have in place, but I feel it a bit <efraim>Similar to the font build system? <g_bor[m]>yes, something similar, but even more simpler. <g_bor[m]>If I had to do this now, I would delete all phases except unpack, and replace install with a copy-recursive to 'out'. <efraim>devil's advocate, can (package-source foo) be shoehorned into that role? <g_bor[m]>efraim: in this case I guess it can, now it's not a tarball. But it would be nice to have a generic method. Furher, you would still need to define a working package I guess. <roptat>g_bor[m], I think you can use an origin record instead of a package <roptat>they both produce a derivation and I know you can use an origin record in the inputs fields of a package for instance <civodul>i was wondering whether something had popped up on linuxfr <sirmacik>anybody here interested in fixing ghostscript/printing issue? <sirmacik>I'm able to test anything, in short time even propose some improvements, I'm still getting a hang of writing packages *civodul would love to see a fix for that <sirmacik>yep, it appears it's the only blocker for my daily work <sirmacik>(lots of inkscape and printing, which otherwise is my favourite way of taking a break from programming work) <sirmacik>are there some public servers to offload package building to, or it's more in roll your own manner? <civodul>sirmacik: strangely gs fails to handle *embedded* fonts, while it's happy with standard non-embedded fonts <sirmacik>civodul: yep, for me it fails randomly on embeded fonts <sirmacik>works for some documents but mostly fails for thos with additional graphic elements <civodul>yeah, those that follow "best practice", which is to embed fonts, aren't properly handled <sirmacik>i've seen that, but it seems like there is nothing happening <sirmacik>(it's the same for printing websites from icecat) <sirmacik>my idea is to replicate building process from arch here <civodul>it's probably a good approach, trying to see whether that works <sirmacik>this is the only ghostscript packaging which gave me amazing quality and results in my work <sirmacik>way way better than debian or fedora ones <sirmacik>main difference is that they remove almost all libraries from gs source in favour on system ones <sirmacik>in guix we have some patches and more libraries from gs source (some are removed) <civodul>oh we're still using bundled libraries? <sirmacik>unfortunately I need to push out some graphics today so I'm not able to make changes in package file before monday <sirmacik>but if someone has the time to make the changs I'll be happy to spin (build) them and test out <sirmacik>pkill9: tweaks package works like a charm, thanks! ***Rnytom[m] is now known as rnytom
***rnytom is now known as Rnytom[m]
<rekado>pkill9: have you sent the gnome-tweaks package to guix-patches@gnu.org already? <rekado>I guess you can take the changes from wip-gnome3.30 and adjust the version string. <pkill9>rekado: no i haven't and yea that's all i did <efraim>not guix related, enlightenment is taking almost 50% of the load on my PPC G4 <sirmacik>anybody has a package file for torbrowser? <sirmacik>unfortunately due to shebangs issues all over the code it won't work installed from website, maybe somebody has automated it? <rekado>pkill9: okay, I’ll push a gnome-tweaks patch to the master branch then. <sirmacik>rekado: what will be the way to proceed with the update? manual removal of tweak-tools and installation of tweaks or will it be done automatically? <rekado>(the old package will be marked as deprecated) <wingo>soo, it seems gnome desktop defaults to gdm now, which is pretty cool <wingo>but gdm is not working for me. it sorta flashes on, the console says "added seat blabla for gdm", then flashes off <wingo>and elogind says "removed seat blabla for gdm" <wingo>it does that 6 times then chills at the linux console <wingo>any ideas before i start digging? <wingo>this is on a system with intel graphics <wingo>i get a warning in /var/log/gdm/greeter.log about not being able to read /var/lib/gdm/.ICEauthority (permission denied) <wingo>indeed for some reason the skel files in /var/lib/gdm appear to be owned by lp:lpadmin instead of gdm:gdm, which is weird <wingo>not all of them but many. i will manually chown, la la la <wingo>yay, thank you all for working on gdm, this is great <rekado>sirmacik, pkill9: it’s fixed now. <wingo>yay, screensaver -> screen lock just works, yay! <wingo>i have been missing that for years, it was one of the first things i wanted working when i started hacking out elogind <wingo>and the system admins at work will be pleased i am no longer flouting the rules by having a laptop you could just open up and start stealing things from ;) <civodul>wingo: automatic screen locking in GNOME was a long-overdue feature :-) <civodul>i left it open because it was so terrrrible <wingo>humm i am having probs where emacs freezes up sometimes <wingo>will have to track it down later i guess <sirmacik>rekado: great, I'll pull it as soon as rust check phase finally finishes... I'd love this package to be installed from binary <dutchie>is there some equivalent to setuid-programs for a foreign install? <civodul>hmm hkp://pool.sks-keyservers.net is down? <tune>does anyone here play minetest? the "browse online content" option doesn't seem to work <civodul>dutchie: re setuid programs, there's no equivalent to the above on a "foreign distro" <dutchie>Hmm, irritating. Guess I'll have to use the system package for this one then *civodul had an idea while looking at hashes <civodul>why not have a service that offers "vanity store file names"? <roptat>donofrio_, are you trying to build guix so the store is in /app instead of /gnu? <roptat>the requirements can come from any source, the easiest is guix itself (with guix environment guix) but it could be from your os's package manager <donofrio_>ok so I just ask for these dependancies to be installed buy os folks, was wanting to keep them out of the endevor but I can include if that is best corse <donofrio_>aix may not have these dependancies availavle <roptat>donofrio_, that's only needed to build your first guix, then you can build guix with guix :) <roptat>another solution is to build them yourself, or create a guix pack <roptat>from another computer, create a guix pack with every guix dependencies and you should be able to use it to build guix <donofrio_>"Stop I can only get so....." lol what would step one be to start down this path <donofrio_>so wait all I need is guix installed on my workstation (wsl ubuntu - tinyurl.com/donofrioworkdesk) then I can make a pack for aix (without dependancies?) <roptat>I've never done that, but I think you can do it <roptat>that's how we create the binary installation tarball <donofrio_>so should I just boot guix in a vm and make tarbalss till I'm all set? <roptat>but in your case, since you can't access /gnu, you'll have to make them relocatable, so something like "guix pack -R guix" should be enough <roptat>or -RR if your target doesn't support user name spaces <roptat>(I really don't know if that will work actually...) <donofrio_>how do I run guix on a new host, or just feeling lost a bit with these packs...sounds magical, but I know unix is not magic just raw <donofrio_>I'll try to get /gnu shouldn't be that bad, but might be lol <roptat>once you have a pack, you can transfer the tarball to another machine and decompress it <roptat>if it's relocatable, it means that it will use user name spaces (or proot with -RR), so you just have to call the binaries from that archive to run them <roptat>if you can have access to /gnu it's much better: you'll be able to receive substitutes from our build farms (if you want to) <donofrio_> so first step is grab the iso boot on vm and start packs'ing <roptat>if you can have access to /gnu, you can simply run the install script <donofrio_>yah want nightly code updates, compiling like peasnts currently..... <roptat>if you want regular code updates, there's no need to use the git checkout: simply run guix pull regularly: it pulls from the master branch of the git repo anyway <roptat>I can only see two reasons to have the repo around: you're guix dev or you don't have access to /gnu or no installation tarball exist for your platform <donofrio_>ok I'll try to get the /gnu today let you know if I win or lost.... <roptat>also, I think you'll need root access to install the daemon <donofrio_>oh yah....where is daemon at so I can give them steps to install it... <roptat>it's part of installing stuff in /gnu <roptat>really, they should install the tarball as explained in the manual, as root, and they don't need to give you permission over /gnu <donofrio_>humm ok....hope this works (these folks are rather totalitarian) <brendyyn>perhaps guix should check its permissions <joshuaBPMan>morning guix people...mesa is not working for me anymore. _mesa_add_parameter is throwing an assertion. <dutchie>or >file 2>&1 if you want both stderr and stdout <donofrio_>so my appinfuser would own the /gnu directory (cause I thougyt root as well even though I could see this being shutdown on that requirement alone...) <joshuaBPMan>sway: ../mesa-18.3.5/src/mesa/program/prog_parameter.c:247: _mesa_add_parameter: Assertion `0 < size && size <=4' failed. <donofrio_>roptat, who is the owner of the /gnu directory? <donofrio_>that might be a stop point, but I won't know till I try... <brendyyn>Is there a tool to compute blake2b sum? b2sum only does blake2s it seems <str1ngs>try maybe with $ echo clear-text | openssl blake2s256 ? <brendyyn>thanks. i couldn't figure out how to get it to list the avaliable ones. i didnt actually know openssl was a repl ***apteryx_ is now known as apteryx
<apteryx>this is causing our jami package to not resolve any username, I think. <dutchie>Hmm, building qtwebkit fails by filling up my tmpfs <dutchie>Is there a way to have it build somewhere else? <apteryx>seems to, I've briefly tested it yesterday <apteryx>There should be a fresh build appearing on f-droid really soon also. This will be useful to test between my laptop and phone. <apteryx>you can use the long hash ID just fine, it's just less convenient to share with someone over a conversation ;-) <brendyyn>I'm so keen too one day make my own messaging system <brendyyn>can you call yourself phone to computer with one account? <apteryx>it should work in theory (you can link multiple devices to the same account) <apteryx>but it's also very easy to just generate a new, anonymous Jami account and use different accounts to test <brendyyn>its asking me fffor some weird pin number <apteryx>yeah, that's the mechanism to link with another device, correct? <apteryx>what it does it encrypt your account with your password + this PIN and share it to your 2nd device over the DHT. <apteryx>you have to initiate from the device which has the account already, it'll give you the pin <apteryx>For example, on Android, the option to "link another device to this account" leads to a "Generate PIN" button. <brendyyn>well im using link this device to another account <apteryx>yeah. You remember the password, right? It's the password that was requested when first creating the Jami account. It's purpose is to encrypt the account information on your file system. <apteryx>hmm, let me try that from the desktop <apteryx>OK, just to make sure: you already have a 2nd device where Jami is installed and with a configured Jami account, is that so? <apteryx>and you want to "share" or "link" this account with the 1st device? <apteryx>yeah, you have to add yourself first <apteryx>go into settings and copy your account ID string <apteryx>something like 540a931a0e01fccc5cce455b825e81b08cd6ca55 <apteryx>and normally you'd be able to input taht to the account search box and message/call the contact thereafter, but something is broken in the Jami Guix package at the moment it seems <apteryx>it seems you cannot put your own ID there... I thought you could. Sorry; yes, then you need a 2nd account to test. <brendyyn>ok im in a call but its just a black screen and no sound <apteryx>you are testing this on teh same device, correct? <apteryx>OK, that should work. I thought you were testing using two accounts on the same device <brendyyn>it says messages are still sending after they are already sent <brendyyn>f2e94ea35b174a5b258476f7ace2187fc308e541 <brendyyn>i wonder if it will call my phone or desktop <apteryx>and leave you the choice to answer from either <apteryx>it is P2P for most things, but it can be helped by TURN in NATed situations <sirmacik>my machine is compiling rust all day long (6 hours straight) <sirmacik>can I force to use sam prebuild package or why it's builidng three versions?! <pkill9>sirmacik: rust is built from previous versions of rust <sirmacik>I have it only for that damn icecat package <pkill9>so i guess something has changed and no substitutes are available for it yet <apteryx>brendyyn: what kind of WM or desktop environment do you use? One thing which is quite inconvenient with ratpoison which I'm using is the lack of notifications from Jami. <brendyyn>apteryx: On Arch I have KDE which is where I have Jami <brendyyn>and my phone sends notifications to my desktop too via KDE Connect <brendyyn>but my laptop is where Guix is and it's just i3. I haven't tried Jami on it yet. <brendyyn>I also setup a jitsi meet instance at meet.brendan.scot, but i found it was not as reliable as the official one. you can test it if you like <bavier>sirmacik: it unfortunately part of the rust bootstrap story <roptat>sirmacik, icecat depends on rust 1.24, which depends on 1.23, which depends on 1.22.... until 1.19 <bavier>and the chain will probably just keep getting longer <sirmacik>why icecat isn't installed from substitutes? <pkill9>did you run guix pull recently sirmacik? <sirmacik>(everytime I've tried to install it it had to compile) <roptat>probably because substitutes are not yet available <roptat>rust takes time and there could be build failures too <pkill9>sirmacik: you could try running a previous instance of guix to install icecat which the build servers might have substitutes for plus all it's dependencies <pkill9>sirmacik: run /var/guix/profile/per-user/$USER/current-guix-<some-previous-iteration>-link/bin/guix package -i icecat <roptat>from may 6th 2019, my icecat has substitutes <roptat>(that was last time I guix pulled) <roptat>did you enable substitutes? and for what server(s)? <roptat>looks like berlin has a substitute, but not hydra <apteryx>brendyyn: eh, I've used Jitsi in the past (the desktop app), but it pretty much was abandoned after the team was bought by Atlassian. <roptat>civodul, did you want me to send a 1.0.1-pre1 to Benno? <civodul>roptat: yes, today or this week-end if that's fine with you, WDYT? <civodul>that way we could release 1.0.1 next week <civodul>bavier: yes, given that we have a serious bug in the installer, it's best to not wait IMO <civodul>i'm trying to make 'guix system docker-image' easier to use <civodul>normally "docker run -ti" opens a shell in the container <civodul>but that doesn't work for us (after a series of fixes i made) <civodul>anyone knows how that thing works under the hood? <davexunit>is it broken because of some path assumption? /bin/bash, etc. <civodul>davexunit: good question, i don't know <civodul>when i do "docker run -ti IMG", it boots Guix System just fine, and then it sits there <civodul>so i wonder if the OS in the container is supposed to do something to notify Docker when it's done booting <sirmacik>btw. while we're talking about guided install <sirmacik>anyone noticed you can't enter encryption password longer then the textfield? <civodul>sirmacik: nope, is that really the case, or is it just that there's no visual feedback? <civodul>if that's the case, i invite you to email bug-guix@gnu.org :-) <yrk>finished installing guix sd yesterday, now going to re-install it with the hindsight gained from the initial install <dftxbs3e>donofrio_: that, I don't really know; use --prefix=/app when configuring each project? You'll probably be going crazy. <g_bor[m]>I have noticed a small thing with the way we are starting services on guix system. It would be nice if we could benefit from the possibility provided by some servers that allow live updating their configuration. One example is nginx. We could implement a reload action, that performs that, but currently the config file is referred as the absolute store path generated at system reconfigure time. I believe that using a link <g_bor[m]>instead of that, and pointing to the store item would work. The link could be updated on reconfigure, and then reload would be simply sending a SIGHUP. Wdyt? <cbaines>Is there any way to run a single srfi-64 test? I've got something kinda working with Geiser, but the error doesn't appear in the buffer geiser pops up <sirmacik>you cannot set longer password as it doesn't let you to type any more letters <sirmacik>furthermore first password field is open text <sirmacik>only confirmation shows **** instead of letters <g_bor[m]>afther a bit more thought, we might not be able to update the symlink on reconfigure, but then it could be done in the start, restart and reload actions... <cbaines>I'm still fighting srfi-64, I think the only way to get the default test runner to tell you what the failure is for a single test is to wrap it in a group, and set the aux-value for the runner to a port which you'll see the output to <cbaines>If anyone knows of a simpler way, I'd love to know! <apteryx>cbaines: FWIW, when I have to debug tests, I rename the test module so that it fits the Guile nomenclature, and then I can eval the module/run single tests with Geiser. <str1ngs>nly: I have resolved this ICU but I might need you to test something. *rekado just received a quote for the new ci.guix.gnu.org. <apteryx>rekado: eh, what's this quote about? <rekado>2 blade enclosures, 16 blade servers. <rekado>the build farm that’s currently backing ci.guix.gnu.org consists of retired Sun hardware. <rekado>the 7 year support contract is probably the most expensive here :) <rekado>we’ll keep parts of the old hardware in any case. <apteryx>is it really needed? (the 7 years support) -- things tend to run fine when they're brand new ;-) <rekado>in our experience the support contract is necessary. <rekado>we’ll get new disks within a day and hardware replacements without having to argue all the time <dftxbs3e>rekado: regarding the powerpc64le port, I think waiting for gcc-7+ stable support is needed. <rekado>(I think for public service purchases extended warranty is a requirement anyway.) <dftxbs3e>even though, the bootstrap binaries worked, the later commencement.scm stuff compiles glibc 2.28 which runs into the same problems <dftxbs3e>I have been trying to patch that for glibc 2.25 but I think it's the wrong route to take. <rekado>dftxbs3e: our best hope is getting the needed changes into core-updates and fixing the problems in other packages that this change might trigger. <dftxbs3e>rekado: Yes, I think when these changes are made, bootstrapping powerpc64le will Just Work (TM) <rekado>I just installed “guile-opengl” to play with computing on a GPU node on the cluster and I saw that it’s compiling the Scheme files. Something wrong with the installation location of the .go files? <rekado>let’s try to push core-updates into shape <davexunit>rekado: yes the compiled files don't get installed into the proper place. <davexunit>I use a variation of the package for my own projects. <davexunit>I patch Makefile.am but you can probably patch the makefile directly <davexunit>also when guile 3.0 becomes the default guile in guix the rest of my tweaks will become necessary. <sirmacik>rekado: are the bugs with luks passwords in guided install known or should I report them somewhere? <inaimathi`>Hi. I have a question about `guix pack` usage; is this the right place? <inaimathi`>Cool. So I'm trying to run `guix pack` to set up a basic `hello` pack. I run `guix pack -RR -S /bin/hello=hello hello`. After unpacking the resulting tarball, I get a `bin` and `gnu` directory, but when I try `./bin/hello`, I get the bash error of `No such file or directory`. <inaimathi`>The desired end state is a pack that I can use to run `hello` regardless of whether the target system has `guix` available; am I fundamentally misunderstanding the `-S` and `-RR` flags here? <cbaines>apteryx, what renaming do you do? I don't know what the Guile nomenclature is. <Blackbeard[m]>Tarballs, the ultimate container image format — 2018 — Blog — GNU Guix <apteryx>cbaines: I meant the name of the guile module should follow the layout of the file system (e.g. the name of tests/pypi.scm should be (tests pypi) rather than (test-pypi) in the define-module directive. <apteryx>otherwise Guile cannot evaluate the module as-is, which is a shame. <cbaines>apteryx, geiser seemed to make a go at compiling the module <cbaines>and I can actually run an individual test <cbaines>it's just that the default test runner doesn't tell you why the test failed <cbaines>and guessing is a slow and fustrating way of writing tests... <apteryx>doesn't work for me in Geiser, I get weird errors like: scheme@(test-pypi)> <apteryx><unnamed port>:593:25: error: define: unbound variabl <apteryx>when trying to evaluate (define test-json ...) <apteryx>cbaines: I'ne never used the builtin test runner, but I agree that if it doesn't tell you what failed, it's not very useful. <cbaines>huh, are you doing C-c C-b to evaluate the buffer? <apteryx>if I rename the module (tests pypi), simply doing C-c C-a loads the module and actually runs it. <apteryx>I usually "use" the module before running it, with C-c C-a, and this seems to be the part that doesn't like the module name. <cbaines>Right, I've just been doing C-c C-b, so I guess Guile doesn't see the name of the file <apteryx>I mean, it works without error, but anything after including C-c C-b. <apteryx>having the correct module name also allows me to "eval" fragments of the module (as a single test) compared to the whole module. <apteryx>hmm, wrong, it seems to work anyway... <apteryx>brendyyn: regarding the question "is jami using the TURN server or not", AmarOk from #jami answered to me that you can grep for "ice_transport.cpp.*connection pairs" in the "dring -cdp" daemon output. <sirgazil>cbaines: As far as I know, the default test runner does not print the complete information of failed tests, but the log files do contain details. I had to write a test runner for my own projects because I didn't like that. <cbaines>sirgazil, yep, that's indeed the problem I'm coming up against <cbaines>I think I've found that build-aux/test-driver.scm does contain a different test runner implementation, so I'm currently trying to work that out... <civodul>what i do in Geiser is that i C-M-x the 'define-module' form and top-level definitions, and then i evaluate the expressions i care about <civodul>it's pretty manual because you can't evaluate a whole test-assert expression, for instance <cbaines>evaluating a test-assert does work for me with Geiser, it just doesn't say why the test failed (if it failed) <apteryx>civodul: if I rename the module as (tests module-name), I seem to be able to eval test-equal or test-assert <apteryx>I also load the module in Geiser with C-c C-a before doing that <apteryx>any reason we can't stick with the normal module naming? Is the (test-modulename) style something that srfi-64 cares about? <civodul>but i mean, it doesn't make any difference, does it? <civodul>well, depends on how you evaluate the file i guess <civodul>for Docker, should shepherd be our "entrypoint"? <civodul>the command specified as the entry point is apparently PID 1, but at the same time "docker run" expects it to terminate quickly <rekado>for Docker system images? I think so. It’s usually the init. <civodul>but then if you do "docker run -ti IMG", the thing "hangs" <civodul>because it waits for shepherd to complete <civodul>it seems people specify /bin/sh or something as the entry point *civodul tries to make "guix system docker-image" produce a ready-to-use image <rekado>maybe “entrypoint” is the wrong thing here <apteryx>civodul: I might have something useful for that <apteryx>it's mostly a hack, but it might lead so some proper solution <civodul>actually, there's "images", and there's "containers" <civodul>so you first "docker load" the thing <civodul>then you can do "docker create IMG", and that gives a "container" <civodul>and *then*, you can do "docker start CONT" <civodul>and "docker ps" shows that the thing is running <civodul>and at that point, you can "docker exec CONT /bin/sh" <civodul>so i think shepherd is the right entry point, after all <civodul>it's just that "docker run -ti" is maybe not meant to be used in this context? <rekado>is that like the difference between “guix system container” (to attach to a running container) and “guix environment --container”? <cbaines>Often a Docker container will just run a single application, or group of processes *rekado has only ever used docker run, and that only with the things generated by “guix pack”… <cbaines>I guess if you build one from a Guix <operating-system> record, then having Docker start the shepherd, and then it start other services seems sensible *rekado nervously chuckles while thinking about year-old bugs and patches in debbugs… <cbaines>civodul, I think the biggest issue with Docker containers is running the build-daemon though. Having guix install ... start the build-daemon if it's not running, so you can just invoke guix install in a Dockerfile, and it works would be pretty convinient I think <g_bor[m]>civodul: I believe that something like docker run -ti bash would work... <rekado>civodul: I had a confusing interaction with a sysadmin today. He insisted that Singularity did not use a setuid binary. Showed me that /usr/bin/singularity was not a setuid binary. <rekado>but I could not find the setuid exec helper that they (used to?) install. <rekado>I know that “singularity build” must be run as root. <rekado>but apparently you don’t need root to run an application in a singularity image. <rekado>I find it really difficult to find related files on traditional systems since getting used to “ls $(guix build foo)” <civodul>cbaines: don't people run "full OSes" as containers, and not just mere applications? <civodul>i mean, if you have services inside your container, you prolly want systemd to start it all, right? <rekado>civodul: in the bioinfo world people run only applications, no full OSes. <civodul>to me, there's "guix pack" -> application <civodul>and "guix system docker-image" -> full OS <rekado>I guess even for deployment you don’t want systemd services <rekado>you just have one docker thing for each micro service <rekado>and you have a tool to manage these services (i.e. a tool to start and stop and relocate these containers) <civodul>but people do use "docker create" and "docker start" will something that's rather a full OS, no? <bavier>I've used docker for a "full OS" like that <civodul>for an application, "docker run" seems to be enough most of the time <bavier>I don't know that there were any services running though <rekado>civodul: ah, it’s probably /usr/libexec/singularity/bin/starter-suid <rekado>I wonder if that’s used even when user namespaces are available. What else would it be needed for…? <rekado>what’s a “full OS” when there’s neither a kernel nor any services…? <civodul>rekado: user namespaces aren't available on the machines they target :-) <rekado>(is this like a falling tree with nobody there to hear it, or more like the sound of one hand clapping?) <civodul>a "full OS" here means there's a PID 1-ish process that takes care of services <civodul>i don't know if it's a useful concept <bavier>right :) the only "service" in my case is usually a login shell <bavier>which, given the image, appears like a possibly different OS <rekado>civodul: do you think we can do without running the daemon as root when user namespaces *are* available? <civodul>rekado: hmm, there's perhaps and issue with the ownership of files in /gnu/store, no? <rekado>in the single user case (= on many laptops) this might not matter <civodul>currently things are root:root-owned <civodul>in the single-user case you don't really need a daemon <rekado>it may still make sense to have a daemon for handling locks. <rekado>yes, I remember the blog post. I was worried that it may no longer reflect the current version of singularity. <civodul>yeah the post was for 2.x (written in C) <civodul>but it's probably not very different now *civodul tries "guix build hello" in a Docker container in a Guix VM <civodul>funny thing: you can run "halt" in the Docker container, and then do "docker exec -ti" again to get a shell there <civodul>and at that point, "herd status" will show that everything is stopped <civodul>like you're running a shell in a system that's stopped <cbaines>wahoo! Hacking the test runner defined in build-aux/test-driver.scm in to a test module gives the actual error when you evaluate a single test! <cbaines>Unfortunately the colours don't work in the Geiser dbg buffer, but that's just a nice to have <cbaines>Maybe that can somehow be made the default test runner <cbaines>There's already a (guix tests) module <bandali>what's the general etiquette for requesting being added to the guix group? <bandali>i've made a few simple contributions so far <rekado>bandali: usually it’s not needed to be a member of the Guix group on Savannah because of our patch-based workflow. <rekado>you can contribute by sending patches and one of the people who have push access should review the patches and push them. <bandali>rekado: i do understand that :) but i thought it'd be nice if i could commit trivial changes myself without having to bother others <bandali>like bumping package versions or updating the pubkey file name in the installer script <rekado>people with push access are usually long term contributors and “with great powers comes great responsibility” :) so generally we only ask people to become a member when they’ve contributed for a while and have done patch reviews etc. <cbaines>For a few reasons, I'd actually prefer if less people had commit access to the repository. Always sending patches up for review is the best default I think. <cbaines>Even bumping package versions is often much more complex than just changing the number and the hash <bandali>i think that's fair. in the case of few packages i've bumped it was pretty trivial, but i agree it can be quite more complex depending on the package <nckx>cbaines: +1, ideally ‘nobody’ has commit access without some kind of (possibly) automated review. <cbaines>yeah, and it's good to concentrate on optimising a single contribution flow <nckx>*(possibly automated), God I'm a hopeless typofountain today. <cbaines>right, time for sleep, hopefully I can actually make some progress on re-writing these tests tomorrow :)