<georges-duperon>Has anyone toyed with this? I wonder what the pros and cons would be :) <OriansJ>EternalZenith: Yes, add them to the sudo or wheel group and then have them run sudo shutdown -h now <EternalZenith>When I run M-x "counsel-linux-app" it fails to launch any of the candidates saying "Searching for program: No such file or directory, gtk-launch" <EternalZenith>gtk-launch doesn't seem to exist at all on the system, even though it looks to be a part of gtk+ <EternalZenith>I'm trying to switch to exwm, so any assistance would be greatly appreciated <iyzsong>EternalZenith: gtk-launch is packaged in the 'bin' output of gtk+, you can get it by 'guix package -i gtk+:bin' <iyzsong>well, for library packages, the convention is that the main 'out' is for development, and binaries are put into the 'bin' output. i have to agree we lack a tool for search which package provide that file... <EternalZenith>Ah, I was hopinig there was some undocumented feature of "guix package" that provided that <nly>I noticed unusually high CPU usage in normal desktop tasks, upto 50% just in just opening the browser. In dmesg I get 'fatal error during GPU init' and some more 'amd gpu...' errors <nly>My config: paste.debian.net/1045807/ <nly>dmesg error levels: paste.debian.net/1045810/ <nly>hwinfo: paste.debian.net/1045811/ <nly>I guess it's not that bad <nly>But I'll have to use lighter desktop env <efraim>I think it came down to your GPU not having free firmware so there's a lot of falling back to CPU <efraim>I don't know how heavy GNOME is though, the last version I used was 3.8 <nly>800mb ram usage when idle <nlyy>kernel driver: amdgpu.ko <nlyy>Dunno, which are the non-free parts? <efraim>Unfortunately I'll have to look a bit later, I'm on my phone atm ***runejuhl1 is now known as runejuhl_
***catonano_ is now known as catonano
*civodul pushes an update to 1.0.org <civodul>i'm about to push the Outreachy post <civodul>i just found myself entering a bug-fix loop while doing it :-) <roptat>g_bor: for the confusion about hstore in my patches, I wonder if I should rename the extensions field to extension-packages? <roptat>it would make it more explicit that the field should contain a list of packages, no? <g_bor>roptat: yes, that would do it, I think. <g_bor>I have seen something about tagging packages on the mailing list, civould commented we should improve guix package -s instead. <g_bor>Anyway, it would be really nice to be able to list the packages that can come to postgis extension-packages. That would reduce confusion. ***ChanServ sets mode: +o civodul
***civodul changes topic to 'GNU Guix | https://gnu.org/s/guix/ | videos: https://gnu.org/s/guix/blog/tags/talks/ | bugs and patches: https://issues.guix.info/ | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guixsd.org | Outreachy: https://gnu.org/s/guix/blog/2018/join-gnu-guix-through-outreachy/ | This channel is logged: https://bayfront.guixsd.org/.well-known/logs/'
<civodul>g_bor: i haven't followed the story about postgis <civodul>but in general i think tags are a false good idea :-) <civodul>i don't know if people use 'guix package -s' but the intention was to make it as useful and efficient as the usual search box <g_bor>civodul: it goes like this: postgresql has a few extensions that are packaged. But does not find them, unless we make them available. So roptat implemented an addition to our postgresql service, where you can list packages that are made available to the service. However it would be nice if we could list the packages that make sense in htis context. <g_bor>civodul: thanks for pushing the post. <civodul>g_bor: ok i see; it's a fairly common problem i guess, for all services that have plugins or extensions <civodul>we don't have a good answer yet other than "guix package -s postgresql" i guess <g_bor>civodul: I see. Maybe we should at least indicate in the description that this is a postgresql extension, should not be installed, but instead provided in the relevant field of the service definition? <civodul>g_bor: yeah, or just write "this package provides a PostgreSQL extension" or something <g_bor>or postgresql-extension, so that we can provide a keyword to use with guix package -s? <civodul>you can already run "guix package -s postgresql -s extension" <g_bor>I'm ok with adding "this package provides a PostgreSQL extension". <g_bor>civodul: I've noticed that here using two s flags for guix package I get the union rather than the intersection of matches. <roptat>g_bor: ok with the description change <roptat>can someone try to build a system on current master? info-dir-builder says it can't find (guix build utils) <roptat>ah it did work with "guix system build", but failed with "./pre-inst-env guix system build" <civodul>g_bor: i don't think this has changed, but note that you have to look at results with the highest relevance score <civodul>actually it's not an intersection but rather an extra criterion when computing the relevance score <g_bor>civodul: ok, I see it now, thanks. (I can easily get the intesection using a regexp by the way) <snape>How can I go to the build dir of a 'guix build' when the build succeeded? <snape>like the '-K' option does when it fails <snape>if I can't, what is the best way to force a build to "fail" so that I can get to its build dir? <g_bor>snape: I don't know of any other way except failing the build. I usually add a phase to make the build fail. <civodul>snape: you can't, but you can if you do "guix build --check -K" <snape>Great! It's prefect, thank you! <snape>g_bor: with --check there is no need for the extra phase! <g_bor>snape: thanks, I am always confused about working with check... for example it needs something to check..., so it doesn't not work when I build for the first time. <wingo>the new guix cli output is slick! <g_bor>IT is actually funny... I'm sitting next to a brand new server, that is installing openSuSe for over 3 hours... <wingo>very pleased to have a newer icecat, thanks all!! <civodul>wingo: yup, really happy about the new IceCat as well <rekado>it also fixed the tab crashes on the old Thinkpad. <jonsger>g_bor: make sure to issue "zypper install guix" :P <g_bor>rekado: we are slowly making progress here regarding the HBA thing. <rekado>g_bor: excellent! Thanks for playing with this! <jonsger>g_bor: could be possible that guix is broken, due to the fact that opensuse is still guile2.0 :( *rekado is stuck in a meeting for the whole day! <g_bor>What I have done so far: set boot to UEFI => that made the UEFI boot options available, including UEFI iSCSI settings. I set that up, so that that device1 had iscsi name, ip, netmask, iscsi gateway. That made the HBA appear in the storage administration interface. Now I am waiting for an admin to insert an install disk locally, so that I can go on. <rekado>we are booting with legacy BIOS mode. <rekado>the startup *looks* like UEFI boot, but it’s set up to legacy <g_bor>I have a setting there to make the device appear ad first hdd. I think that will do the trick. <rekado>does it not appear in GRUB when the device is *not* set to be the first disk? <g_bor>I could not test this yet, as we also accidentally installed in BIOS mode, so can't boot to GRUB right now. I will have to wait for the local admin to get this sorted. <rekado>can we easily switch an installed Guix system from BIOS to UEFI? <g_bor>I think it should appear in GRUB regardless. <civodul>jonsger: note that we'll probably remove Guile 2.0 support soonish <rekado>we’d only have to install the efi directory, right? <g_bor>rekado: I think so, but have not tried it yet. <jonsger>civodul: I know, but I didn't get the time to start updating guile in opensuse. gnutls-guile somehow doesn't like guile2.2... <civodul>jonsger: GnuTLS should be fine but if not, let me know! <roptat>jlicht: I've found your node-build-system and npm-importer, why weren't they merged in guix? <roptat>except for the recursive importer and some porting work to current master, I don't see any reason why we shouldn't use it <jlicht>roptat: the biggest problem is not with the node build system, but the importer (and the horrid npm situation) <roptat>is it the latest version of the patch? <jlicht>roptat: I should have a newer one somewhere, I can send it to you/the ML tonight <jlicht>the tl;dr of it is that the package path thing for node does not scale, as any non-trivial package has about 20 version of the same thing in its transitive dependency graph <roptat>yes, I've tried to run a script that draws that graph, selecting only the latest version of each package, and it just exploded <roptat>it seems that any node package requires the rest of the registry... <jlicht>roptat: yup! I packaged coffeescript up till version 1.0, and it already required about ~60 (custom!) versions of a coffeescript compiler to go from the last ruby-based version. <jlicht>not to mention the ~10 outdated and insecure versions of node needed to support this extremely brittle chain of bootstrapping transpilers <roptat>I tried to do that too, but got stuck because the initial versions required old nodejs versions <roptat>I didn't even manage to build an old nodejs <roptat>I found that 0.1.33 was the last with process.mixin, so I tried to build it <jlicht>the thing was that sometimes a Coffeescript feature was introduced in a commit, and already used in the source in that same commit. This happened like 5 times, and I basically had to backport the feature myself without using the feature, if that makes sense <roptat>yes, that's exactly what I was afraid of <roptat>the node scripts rebuild the js version everytime you run them, so I guess someone could easily introduce a feature in the compiler, compile it and then use it in compiler code before commiting <roptat>wouldn't it be simpler to re-implement coffeescript though? <jlicht> The approach that we now have for bootstraping rust seems to work; cut the dependency graph somewhere by having an alternative implementation with some simplifications, and use that to bootstrap more recent compilers. If something like that happened for coffeescript, it would help <jlicht>I've been looking at gash/geesh for inspiration, and already build a simple semver parser in guile for use in the importer <jlicht>basically, the "^1.0.2" things you see in package.json files are an extension of the semver spec <roptat>do you think it would be hard to write a coffeescript compiler? <civodul>i mean it sounds like a rabbit hole no? ;-) <civodul>that said, you should suggest doing just that to mwette, who is very much into these things with nyacc *civodul goes to boring meeting <jlicht>roptat: I don't know, but at least things have been documented well; you could try to play around with it using guile :-) <astronavt>maybe a stupid question, but what filesystem type should i choose in cfdisk for the guixsd boot partition? <roptat>I think that's "linux" near "linux swap" <astronavt>ok, some distros recommend using FAT so i wasnt sure. i dont even see that as an option in guix's version of cfdisk <roptat>astronavt: actually you don't need a boot partition <roptat>that's suggested in other distros because that's where the grub configuration and kernel is, but in guixsd, the kernel is elsewhere <astronavt>i see. still required for lvm/luks though, i assume? <astronavt>hmm, luks where /boot is part of the encryption? i think arch has instructions for something like that but it's not pretty <roptat>it's supported without any ugly configuration :) <roptat>I think there's an example in the manual, let me find it <roptat>look for the example that says "cryptsetup luksUUID" <rekado>I’ll revive a somewhat dated desktop machine in a few weeks, and I was wondering if anyone knows of a simple graphics card that I could use with Linux libre. <rekado>h-node tells me that the GeForce GT 710 should work with Linux libre, with 3D acceleration <rekado>does anyone here have this card and can confirm this? <davexunit>rekado: any objections to me bumping the commit for the guile-next package? andy just fixed a bug I found in master. <davexunit>thanks! can I also fix the native search paths while I'm at it? <davexunit>trying to benchmark my game library with JIT <efraim>guile-next built fine on aarch64, I'll test the next commit when I'm back at my computer <roptat>astronavt: in the example there is no separate /boot (there's no /boot declared) <roptat>it's all done automatically by guix <davexunit>efraim: thanks. I won't be able to commit this until about 6 hours from now. <roptat>astronavt: I have a similar setting on a laptop and didn't need to do any extra work (only encrypting the partition before installing guixsd of course) <roptat>grub asks for the password to decrypt de partition and then loads the kernel from there <astronavt>roptat similar settings to what, the example in the guixsd manual? <roptat>on the first sectors of the disk or the efi partition IIRC <roptat>the configuration is on disk, but the disk is decrypted before grub reads the configuration I think <rekado>it would be nice if we could install everything that’s needed for booting onto a different partition. <rekado>currently, /gnu must exist at boot time, right? <rekado>I wonder if we could let “guix system reconfigure” copy the kernel and whatnot to another disk, then boot Linux and mount /gnu from elsewhere. <rekado>this would allow us to circumvent problems when /gnu is on external storage. <pkill9>is it posible to bork GRUB if a `guix system reconfigure` is interrupted while it's being updated or something? <pkill9>while the grub install is being updated/modified i mean <efraim>nly: unless your kernel tried to load the driver and got a 'DEBLOBBED' error it looks like you should have support for amdgpu <efraim>our libdrm package builds amdgpu_drm and our mesa package is built with r600 support <nly>I got the deblobbed erorr <efraim>then it sounds like it got blocked by the linux-libre deblobbling scripts <nly>paste.debian.net/1045810/ <nly>I read somewhere that amdgpu just plain shuts off if there is no microcode rather than work at a degenerated performance <nly>Lucky, I use a ethernet <nly>efraim: I dunno r600 <efraim>according to the mesa source code r600 is the previous code/configure option for amdgpu <nly>Ty for looking into it :) <nly>Does guix have xf86-video-amdgpu? <nly>if anyone wants to package that go ahead, otherwise I might try to do it later. :) *nckx wants to find out if amdgpu supports their Radeon chip but every page just rambles on about islands... :-/ <davexunit>guix is so frustrating when it builds stuff from source that it shouldn't need to. <davexunit>I built guile-next on one machine, then generated an archive with 'guix archive' and shipped it over to another machine. <davexunit>I ran 'guix pull' on that machine to make sure I had the exact same guix commit as I was using on the other machine. <davexunit>am I wrong to think that running 'guix build guile-next' should just output the store item I just imported? <davexunit>because it's not doing that, it's trying to build from scratch. exactly what I was trying to avoid. <rekado>davexunit: could you use “guix copy” instead? <rekado>“guix archive” is a bit low-level and I wonder if it does the right thing wrt derivations, grafts, and the like. <rekado>(if it doesn’t do the right thing this might very well be a bug) <davexunit>I didn't know about 'guix copy' but I can't use it in this situation because the two machines are isolated from each other <efraim>I normally use no grafts and recursive <davexunit>I can try with --no-grafts and see if that works <rekado>davexunit: did you export recursively? <rekado>can you tell us if “guix build --no-grafts --dry-run guile-next” on the target machine says anything useful? <davexunit>I've checked a bunch of times and the guix versions are exactly the same :( <davexunit>I'll just wait for the build farm to rebuild guile-next *davexunit looks at cuirass web ui for first time on berlin.guixsd.org <Laalf>which etherpad(or similiar site) is ok for you? id like to get some help regarding libvirt with ovmf. <pkill9>davexunit: are the systems x86-64 or i686-linux? <pkill9>just checking they're the same, incase you gave that an oversight <nckx>When piping the new 'guix build' output to less (almost) every line is prefixed with ^M. <jlicht>is there an existing way to 'peel off' one layer of symlink-indirection in the guix codebase? So I have a -> b -> c via symlink, and I want to end up with a -> c. <pkill9>.tell jlicht `realpath` will 'peel' away all layers of symlinks, I think `readlink` will only 'peel' away one symlink <davexunit>ha, berlin has built the new guile-next and I *still* can't get a substitute, even with --no-grafts <davexunit>I have no idea what is going on but it's extremely frustrating <davexunit>I even checked the local derivation to see if the output directory matched and it does. <davexunit>and the derivation matches between local and berlin <davexunit>and the stuff I imported earlier also matches up <davexunit>yet guix still insists on building from source. I am baffled. <lfam>davexunit: Do you get other substitutes from berlin? That is, is the berlin signing key authorized on your machine? <davexunit>but maybe I don't have it authorized somehow... <lfam>If it's in '/etc/guix/acl' then you should be good <davexunit>I don't know how to find it on berlin.guixsd.org anymore <davexunit>lfam: wellp.... that was it. I feel very dumb now. <lfam>I *think* the canonical source of the key would be the 'maintenance.git' repo, but I'm not sure <davexunit>I thought for sure I had done this a year ago or something <lfam>It's a bit obscure to know which keys are authorized. I wish there was a "comment" field in the key s-expression *davexunit goes afk, a little happier now <pkill9>where are authorized keys stored? <pkill9>i thought that was the generated key <pkill9>yeah it would be helpful to have a comment field