IRC channel logs


back to list of logs

<joshuaBPMan>well sway is being weird.
<joshuaBPMan>I can't seem to launch any X application.
<joshuaBPMan>I've got xwayland-xorg-server installed...
<mbakke>joshuaBPMan: What happens when you try to launch one?
<degauss>Hi there! I have a question on conflicting entries in a user profile (somehow related with <>).
<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>atw, distro
<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?
<wr>atw, almost all
<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, 1
<atw>in that case, you'll want to modify your operating-system to to include the gdm service. You can use the "desktop" example in as a guide. Also make sure that the (packages ...) section includes lxde. Then, use guix system reconfigure to build and switch to the new operating-system
<atw>and I forgot to mention, %desktop-services includes gdm:
<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.
<atw>how's it going, wr?
<oneness>Thanks samplet. Will change bios seeting to use legacy first to see if it is the issue
<boogerlad>how do you --roll-back guix pull?
<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.
<boogerlad>thank you!
<atw>I don't want to confuse the question but some functionality demonstrated in may be interesting
<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
<wr>and i got one error before
<wr>atw, when you say nix you mean ?
<crab1> 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? 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_: - 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>aphical installer and chose Gnome by the way.
<Blackbeard[m]>PotentialUser-41: hi
<Blackbeard[m]>what wifi are you using
<Blackbeard[m]>maybe the driver is not fully libre?
<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?
<civodul>Hello Guix!
<cjb>does the x86_64 iso boot on systems with a 64bit CPU but a 32bit EFI?
<efraim>I don't believe so
<g_bor[m]>hello guix!
<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
<g_bor[m]>verbose. Wdyt?
<g_bor[m]>Or am I missing something?
<efraim>Similar to the font build system?
<g_bor[m]>efraim: I believe so.
<g_bor[m]>I did not have a look at that yet.
<g_bor[m]>I will do so now
<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?
<efraim>I guess not if it's a tarball
<roptat>hi guix!
<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
<g_bor[m]>roptat: that's nice.
<g_bor[m]>I did not know that :)
<g_bor[m]>I guess I can go by that :)
<civodul>roptat: yay!
<civodul>i was wondering whether something had popped up on linuxfr
<civodul>glad you did it! :-)
<civodul>or is it you?
<roptat>no it wasn't me
<civodul>even better then ;-)
<sirmacik>hey guix
<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)
<pkill9>gimp had a new major release
<pkill9>oh, maybe not
<pkill9>i read some old news
<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
<civodul>i would have expected the opposite
<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>and do not patch
<sirmacik>in guix we have some patches and more libraries from gs source (some are removed)
<civodul>oh we're still using bundled libraries?
<civodul>we should probably follow Arch
<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 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>sirmacik: it will be automatic
<rekado>(the old package will be marked as deprecated)
<sirmacik>great, thanks!
<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>and now that works!!!
<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 :-)
<rekado>civodul: we can close now, can’t we?
<civodul>rekado: i guess we can
<civodul>i left it open because it was so terrrrible
<civodul>but technically it's kinda fixed
<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?
<dutchie>(i haven't actually read the System Configuration chapter, so maybe I can still use the method from
<civodul>hmm hkp:// is down?
<civodul> as welL?
<pkill9>rekado: thanks
<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>could be
<civodul>or: switch to Guix System :-)
<dutchie>That's on the "eventually" list
*civodul had an idea while looking at hashes
<civodul>why not have a service that offers "vanity store file names"?
<civodul>like people do with Tor onion names
*brendyyn no comprende
<efraim>That sounfss
<efraim>That sounds absurd and fun
<civodul>we could make money, no doubt!
<donofrio_>dftxbs3e, I have no issue trusting your binaries.....I would like to be able to run this on, amd64 suse and redhat linux (again I am locked to /app - team lead gave me ok to work on this project - yah me) and ibm, how do I compile each depandancy without going crazy (and by compiling I mean into the /app directory only)
<roptat>donofrio_, are you trying to build guix so the store is in /app instead of /gnu?
<donofrio_>"if possable" but probably 'not requred'
<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 - then I can make a pack for aix (without dependancies?)
<roptat>I think so
<roptat>I've never done that, but I think you can do it
<donofrio_>what run's packs?
<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>no need to pack anything
<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
<roptat>(well that's three)
<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
<roptat>ask them to install the "GNU Guix binary" from here:
<donofrio_>humm ok....hope this works (these folks are rather totalitarian)
<roptat>I hope so too!
<donofrio_>who owns /gnu?
<brendyyn>Apparently my user owns /gnu
<brendyyn>what the hell
<roptat>root normally
<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.
<joshuaBPMan>how does one redirect stderr?
<dutchie>2> file
<dutchie>or >file 2>&1 if you want both stderr and stdout
<joshuaBPMan>dutchie: thanks.
<joshuaBPMan>This is the error I am getting:
<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.
<joshuaBPMan>I guess I should mention this in a bug report.
<donofrio_>roptat, who is the owner of the /gnu directory?
<roptat>donofrio_, root should own /gnu
<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>brendyyn: maybe openssl ?
<str1ngs>see openssl help
<str1ngs>try maybe with $ echo clear-text | openssl blake2s256 ?
<str1ngs>oh you want 2b
<str1ngs>blake2b512 digest exists
<brendyyn>thanks. i couldn't figure out how to get it to list the avaliable ones. i didnt actually know openssl was a repl
<str1ngs>no problem
***apteryx_ is now known as apteryx
<apteryx>could someone try: curl and see if they also get a SSL cert verification failure?
<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?
<brendyyn>errors for me too
<apteryx>ok, thanks for checking
<brendyyn>apteryx: does Jami work?
<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.
<brendyyn>ooh nice i notice its 3 months old
<brendyyn>failing to create a username...
<apteryx>this must be due to the SSL issue
<apteryx>but it's optional
<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>and you can call yourself o
<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?
<brendyyn>im already unimpressed
<apteryx>what it does it encrypt your account with your password + this PIN and share it to your 2nd device over the DHT.
<brendyyn>i cant find the pin
<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>mine doesnt
<brendyyn>it asks for my password and pin
<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.
<brendyyn>yes but i dont have a pin
<apteryx>hmm, let me try that from the desktop
<apteryx>(Guix System)
<brendyyn>it says to export account
<brendyyn>which just lets me save a .gz
<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?
<brendyyn>i found it
<apteryx>and you want to "share" or "link" this account with the 1st device?
<brendyyn>now i want to test call
<brendyyn>maybe i do need two accounts
<apteryx>try calling yourself
<brendyyn>im not in my contacts
<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>ah, nevermind
<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?
<brendyyn>what do you mean the same device
<brendyyn>im calling my desktop from my phone
<brendyyn>i got an audio only call to work
<apteryx>OK, that should work. I thought you were testing using two accounts on the same device
<brendyyn>but video call is dead
<brendyyn>welp there are certainly a lot of bugs
<brendyyn>it says messages are still sending after they are already sent
<apteryx>what's your ID?
<apteryx>if you want, we could test a call
<brendyyn>i wonder if it will call my phone or desktop
<apteryx>in theory both should ring
<apteryx>and leave you the choice to answer from either
<apteryx>did you get my test message yet?
<apteryx>ah sorry I sent to the wrong ID :D
<brendyyn>So it is not P2P?
<brendyyn>ok got it
<apteryx>it is P2P for most things, but it can be helped by TURN in NATed situations
<apteryx>testing audio call to start
<brendyyn>TURN is different to STUN?
<sirmacik>guix during today's reconfigure builds
<sirmacik>rust 1.20, 1.21 and 1.22???
<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
<sirmacik>I'd love not to have it at all
<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.
<apteryx>OK :-)
<brendyyn>I also setup a jitsi meet instance at, but i found it was not as reliable as the official one. you can test it if you like
<sirmacik>pkill9: but three versions?
<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
<sirmacik>but I'm also talking about 2-3 days ago
<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
<bavier>bugfix release so soon?
<civodul>bavier: yes, given that we have a serious bug in the installer, it's best to not wait IMO
<roptat>ok, I'll do that :)
<bavier>makes sense
<civodul>thanks, roptat!
<civodul>i'm trying to make 'guix system docker-image' easier to use
<civodul>by adding an entry point and all
<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>well, i don't think so
<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 :-)
<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]>hello guix!
<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>cbaines: thats a bug
<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
<sirmacik>cbaines: misclick, sorry
<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.
<str1ngs>ICU issue*
*rekado just received a quote for the new
<rekado>~170kEUR, weee!
<apteryx>rekado: eh, what's this quote about?
<rekado>2 blade enclosures, 16 blade servers.
<rekado>the build farm that’s currently backing consists of retired Sun hardware.
<rekado>we’ll get a new one.
<rekado>(or are trying to)
<apteryx>I see! pricey!
<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>dftxbs3e: neat!
<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>basically s/ccache/site-ccache/ is needed
<davexunit>I patch 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?
<Blackbeard[m]>inaimathi`: yes
<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
<Blackbeard[m]>inaimathi`: ^
<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
<apteryx>hm, let me try
<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>it's a bit confusing! eh.
<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>no, srfi-64 doesn't care
<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>i'm a bit confused
*civodul tries to make "guix system docker-image" produce a ready-to-use image
<rekado>maybe “entrypoint” is the wrong thing here
<civodul>ooh, wait
<apteryx>civodul: I might have something useful for that
<apteryx>the docker image thing
<civodul>tell me :-)
<apteryx>it's mostly a hack, but it might lead so some proper solution
<civodul>so i understood something (!)
<civodul>actually, there's "images", and there's "containers"
<civodul>(don't laugh at me)
<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>crazy stuff
<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
<davexunit>I patch I filed with xfce *years ago* was just merged:
<davexunit>er, "a path" that is
*rekado nervously chuckles while thinking about year-old bugs and patches in debbugs…
<bavier>davexunit: congrats :)
<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...
<davexunit>bavier: I only vaguely remember doing this.
<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>which is true
<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>there's necessarily a setuid help
<civodul>forgot the name
<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 they talk over network.
<civodul>yes, that also makes sense
<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?
<civodul>hmm maybe not
<bavier>I've used docker for a "full OS" like that
<civodul>so the use case exists :-)
<bavier>like "lightweight vm"
<civodul>i see
<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
<civodul>i thought i was :-)
<civodul>*it was
<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
<civodul>rekado: there's a note about the Singularity setuid helper in
<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>hi all,
<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.
<bandali>makes sense :)
<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 :)