IRC channel logs


back to list of logs

<mbakke>I think Hydra has given up on 'staging'.
<mbakke>"No you build it"
<sdb>mbakke, LOL what to do about these machines becomming more and more self-aware.
<sdb>snape, no problems compiling with 4 cores. Took 30 min. at 800 mhz/core.
<snape>good :-)
<mbakke>Woah, WPA3 is "out". Hopefully it's easier to crack than WPA2... :(
<mbakke>ACTION misses the WEP days with free internet everywhere
<nckx>22000 IVs of power.
<ngz>The good aircrack-ng old days.
<reepca-laptop>sneek: do you know about aliases?
<sdb>which conferences does people from this community attend? libreplanet and fosdem?
<nckx>sdb: Definitely FOSDEM.
<noobly>where might one find a detailed comparison between guixsd and nixos?
<civodul>Hello Guix!
<sdb>good morning :)
<sdb>"make check" finished during the night with 3 failed tests.
<sdb>the log file is really huge. any ideas how to chop out the relevant lines?
<sdb>maybe grep -e "FAIL:" --after-context=10000 will work
<snape>grep FAIL maybe :)
<efraim>For the desktop services, we should add defaults to XXXX-desktop-service-type and descriptions and then change the examples in (gnu system examples)
<jlicht>hey guix
<civodul>guile-sqlite3 release → done
<g_bor[m]>Hello guix!
<jlicht>I'm having some issues getting my guile modules to compile using guix;
<jlicht>basically, it complains about compilation not being possible because guild would write to the store, which is of course Not Okay
<jlicht>I looked at the auto-{hell,tools} sources of other guile modules, but could not find what makes them not complain about auto-compilation of the sources :/
<sdb>hi, did any of you run make check with "-j"?
<jlicht>sdb: I have in the past, but I ran into some difficult-to-debug issues, so now I usually don't
<sdb>jlicht, so maybe the manual should tell people its fine to run make with -j (worked for me yesterday) and then run make check without.
<sdb>how can I tell make to rerun specific tests?
<jlicht>from yesterday's IRC log: "specifically, 'make check TESTS=tests/store-database.scm'"
<sdb>jlicht, thanks
<g_bor[m]>yes, it is also in the running the test suite section of the manual.
<sdb>g_bor[m], good. I should read that section
<jlicht>sdb: I'd rather have the default instructions point to something that always works (where 'expert' users can customize their own workflow to include potentially less reliable stuff)
<sdb>jlicht, agreed
<jlicht>although it might no longer lead to issues, as I stopped using the `-j' flag around the time of the guile-2.2 release
<sdb>I edited the documentation. Will running make automatically generate the info files on the changed .texi files?
<civodul>jlicht: the guild warning sucks, but it's just a warning
<civodul>sdb: regarding 'make check', see also:
<sdb>civodul, thanks I found and read it.
<jlicht>thanks civodul: I thought other modules did not have this issue, but a quic `guix build --no-grafts --check guile-git' has convinced me otherwsie
<civodul>yeah, we should really fix it
<sdb>editing the manual is... eh harder than I thought...
<sdb>I cannot visually see the difference in emacs between ( adn {
<sdb>now I succeded in changing the default font. In my opinion emacs should default to something that makes it easy to read the code... hm.
<jlicht>sdb: Emacs is used by many more than just programmers :-)
<jlicht>(Although that might just be arguing semantics if you consider anybody who configures Emacs a programmer)
<sdb>jlicht, on guixsd?
<jlicht>I am not disagreeing with you sdb, only stating that not everyone using Emacs (or Guix{,SD}) is a programmer.
<sdb>jlicht, ok. Maybe i'm a little grumpy this morning. I just wanted to change the manual to be more helpful and I end up with errors building the texi-files.
<sdb>i'm used to wiki-editing and this texi is.. eh rather different in a complaining/error spewing way.
<sdb>e.g. doc/contributing.texi:178: @pxref expected braces
<sdb>that I understand
<reepca-laptop>FWIW emacs picks DejaVu Sans Mono automatically for me, and it seems easy enough to distinguish ( and {
<sdb>doc/contributing.texi:90: @node `Bootstrapping' previously defined
<sdb>that I do not :(
<sdb>deja-vu fonts are not installed here it seems. hm. we may want to include those in the default templates too.
<jlicht>my experience with texinfo is also... less than amazing. I guess I'm more of the md-generation of documentation (or in my case, Emacs' org-mode).
<sdb>numbus fonts are available
<sdb>I have used org-mode for years.
<sdb>and md
<reepca-laptop>heh, I have a ton of fonts installed because I went a little crazy trying to figure out why certain characters weren't rendering prior to realizing I needed to run fc-cache -f after installing them
<ngz>Let's rewrite Guix manual in Org mode syntax :)
<sdb>what would it take to change from info -> org-mode. Is there an info-exporter? no?
<sdb>ngz, yeah!
<sdb>org generates beautiful html but not sectioned in multiple html-files to my knowledge. Perhaps we could improve org-mode.
<sdb>IDK if it is really needed. Having all in one page is probably fine for most use cases
<ngz>Org generate texinfo
***Gamayun_ is now known as Gamayun
<sdb>ngz, fantastic!
<sdb>never tried that
<ngz>For the record, the next Org manual will be generated from the following Org document:
<civodul>sneek: later tell lfam is now up-to-date
<sdb>ngz, thanks for the link. Looks good. It seems to be easier to read and edit.
<ngz>It makes it much easier to grasp the structure of the document, and fix it if needed.
<sdb>ngz, I just searched for texi2org and the like on duck duck go and found nothing. migrate texi to org also did not return anything usefull.
<ngz>I don't know about an importer from Texinfo to Org.
<sdb>so a migration sed-script is probably a good start
<sdb>sed is the shit
<sdb>old and gold :D
<ngz>When I migrated old manual to the Org format, I wrote a couple of function to do some tedious work and finished manually.
<ngz>low tech
<sdb>yeah that was my idea too
<sdb>we should publish these scripts to make it easier for others to follow
<sdb>do you still have these "functions" for me to see?
<ngz>Unfortunately, I don't think so.
<ngz>Most of them were basic though, e.g., convert @code{...} into ~...~.
<ngz>The most advanced ones would grab the description of a node in the detailed menu and insert it as a node property. That's not much either.
<sdb>ok, that one I already planned
<sdb>which program did you use to do this?
<ngz>It's an editor, after all :)
<sdb>what about the @item and @enumerate?
<ngz>Well, mostly @item -> "- " and @enumerate is ditched.
<ngz>I mean "1. "
<jlicht>phew, rust 1.26 builds :-)
<efraim>Isn't 1.27 out now?
<jlicht>efraim: it is, I think. My poor T400 can't even keep up with building rust at the speed of their releases.
<rekado>I just discovered Ctrl-Click in Emacs; it opens a menu to switch to buffers by mode.
<g_bor_>Hello guix!
<g_bor_>I have a little problem.
<g_bor_>It might be something trivial, but I can't get this working.
<g_bor_>I'm deleting a third party lib from a java package using a snippet.
<g_bor_>The I'm patching the build.xml to pick up our system package instead, but it seem that the package is somehow not picked up.
<g_bor_>Do you have any idea?
<g_bor_>I remember someone mentioning to not use snippets in java packages. Can this be related?
<rekado>g_bor_: ISTR that snippets don’t work for jar files.
<snape>rekado: pretty cool :)
<sdb>jlicht, LOL what is the specs? 2-core 3gb ram?
<jlicht>dual core + 4gb ram, but also me doing other work on it in the mean time
<sdb>ngz, how do you catch the ending } when converting @pxref{xxx} -> [[*xxx]]?
<ngz>(string-match "@pxref{") then (search-forward "}")
<sdb>I saw satithi worked with substring matching with guile - maybe I should do it in guile and learn by doing
<efraim>sdb jlicht I have a macbook 4,1, 2 cores 6 GB of RAM, I do most of my guix work on an aarch64 board, 6 cores 4 GB of RAM
<efraim>Rust takes about 12 hours per version
<sdb>I ran the 3 tests that failed again: make check TESTS=tests/store.scm TESTS=tests/ TESTS=tests/pack.scm
<jlicht>I had to build like 3 versions, so it took me about 30 hours as well :-)
<sdb>efraim, which board is it?
<sdb>FAIL: tests/pack.scm
<sdb> during build of gcc-5.drv
<efraim>sdb: firefly 3399
<mbakke>efraim: Classpath fails to build on 'staging' for x86_64, can you take a look?
<efraim>mbakke: yeah, but it's going to have to wait until later today
<g_bor_>efraim, mbakke: I've just checked what's with classpath. It fails with wrong type to apply, -Xnoinlining.
<rekado>I’m a little unsatisfied with the manual setup that’s required to get locales to work.
<rekado>This is also a common irritant for new users.
<rekado>And upgrades to the libc usually result in at least a short transition phase where locales are broken.
<rekado>Can we do better?
<efraim>Change the default libcs to gblic and glibc-1?
<rekado>(This is on foreign distros)
<rekado>The packages for glibc-locales@<previous> also don’t seem to be available
<g_bor_>efraim: the proble is in ecj-javac-wrappper, something is not right with the line containig Xnoinlinig.
<civodul>rekado: i agree that this is unsatisfying, but i'm not sure what to do
<civodul>the binary tarball contains glibc-utf8-locales since 0.14.0, with a proper GUIX_LOCPATH setting for the daemon
<civodul>what else can we do?
<rekado>is it unreasonable to make glibc-locales a proper dependency?
<civodul>dependency of what?
<civodul>problem is that glibc-utf8-locales contains an *arbitrary* set of locales anyway
<civodul>so we're helping users "like us", but not others
<rekado>“glibc-locales” contains all of the locales, no?
<rekado>I meant: as a dependency of everything that links with glibc.
<rekado>the reason for keeping it separate was, if I recall correctly, that it is “too large”.
<sdb>efraim, thanks for the link. I like it. Can you run guixsd on it too?
<efraim>You'd have to ask vagrantc, I haven't tried yet
<sdb>efraim, ok
<sdb>rekado, I thought about this problem too.
<sdb>My idea was to make a glibc-locale-package for groups of languages e.g. glibc-locales-scandinavia (EN,SV,NO,FI,Sami), glibc-locales-mainland-europe (DE,FR,etc.) etc.
<rekado>the full set of locales takes up 133M, which is large, but it would be shared by many packages.
<sdb>This does not solve the dependency warning thing but makes the sizes of locale-packages much smaller.
<sdb>In the install phase of guix you would then be prompted to choose one or more of these locale-packages.
<rekado>sdb: I suppose we could split it up into single locale packages.
<rekado>civodul: I guess one complication is that there can be different variants of the glibc-locales package, but deduplication takes care of that.
<sdb>rekado, thats also possible, would it entail more work because of the amount of locales?
<rekado>sdb: I expect that this can be automated.
<civodul>rekado: i think it's important to have reasonable closure sizes, and having locales as a separate package was a step in that direction
<civodul>added all of them back in would not be reasonable IMO
<civodul>it should be possible for users to select locales, or to just use the "C" locale if they want
<rekado>could a subset of the locales be built as a profile hook?
<civodul>yes, maybe
<civodul>or we could provide several packages like sdb proposed
<rekado>my goal is to find a more convenient solution compared to installing a glibc-locales package manually.
<civodul>what if, instead of "warning: could not install locale", the thing would print "condider installing 'glibc-utf8-locales'"?
<civodul>or something along these lines
<civodul>we could automatically install locales in the profile based on $LC_ALL & co., but then that wouldn't be reproducible
<civodul>so i think there has to be an explicit choice by the user
<rekado>yeah, this also just occured to me.
<rekado>printing a better warning would certainly be an improvement.
<civodul>rekado: how about this: ?
<civodul>it's not optimal, but it should allow people to solve the issue quickly most of the time
<rekado>very nice!
<rekado>what happens in the guile-2.2 case?
<rekado>(is that not the common case?)
<civodul>turns out that Guile 2.2 already prints "warning: failed to install locale"
<civodul>and yes, that's the common case, hopefully :-)
<civodul>actually i'd like to remove 2.0 support sometime after the 0.15 release
<rekado>sounds good to me
<rekado>but then the improved warning would not be shown in most cases?
<civodul>the hint is outside cond-expand, so it's shown in all cases
<rekado>oh, sorry, I missed that
<civodul>it's just the "warning:" line that's not shown in 2.2
<civodul>ok :-)
<rekado>thank you!
<civodul>so i'm committing this
<civodul>again maybe we could do better, but that's what we'll have for 0.15 :-)
<sdb>I like the change. Lets make it easy for people to know how to handle the warnings.
<jonsger>ACTION has a little fear of guile2.2... :(
<rekado>jonsger: don’t fear Guile!
<civodul>rekado: i'm adding "See 'Application Setup' in the manual"
<civodul>sounds good?
<jonsger>rekado: it's just the fact that in opensuse everything is still 2.0. We even wanted to use 2.2 for guix, but other packages relying still on guile2.0...
<civodul>jonsger: did you see the guile-sqlite3 release, BTW?
<jonsger>civodul: yes, thanks :) I'll update my package and submit it today to opensuse
<civodul>jonsger: mailutils and gdb are the big packages still stuck on 2.0 :-/
<sdb>considering the migration from texi to org-mode that I am about to do. What is the reason for contributing.texi to be a separate file?
<sdb>the is one big file
<sdb>is there a good reason for having it aside?
<civodul>sdb: you're not doing this migration for Guix, are you? :-)
<civodul>it's a good idea to have one file per chapter
<civodul>we don't quite do this, but contributing.texi was a step in that direction
<sdb>civodul, as a proposal at least. The main reason is that texi seems harder to read and edit.
<sdb>me and ngz talked about migrating here earlier. Should I email devel and open up a discussion about it first?
<sdb>org-mode generates tex-info so we would one win on this migration as I see it.
<civodul>sdb: FWIW, i much prefer Texinfo for documents this size, plus it's also a matter of consistency among GNU packages
<civodul>i've been a fan of "markup-less" approaches à la Org at some point
<civodul>but then, having used it for relatively large documents, i've come to think it just can't fit the bill
<civodul>that is, you do need markup sooner or later
<civodul>Texinfo is not that bad in that respect
<civodul>some things are clunky, nodes and menus especially
<civodul>but apart from that, i think it's rather good, as a markup language
<sdb>civodul, if you like texinfo maybe you can help me debug the compile errors I obviously introduced in contributing.texi?
<civodul>sdb: heh, well done ;-)
<civodul>sure, can you paste the errors?
<sdb>I stumbled on just nodes and menus :p
<civodul>ah yes
<civodul>well, yeah
<efraim>rekado: I saw, is there a copy of the manual too there somewhere?
<civodul>in short, you have to duplicate information about the structure of your document in those menus
<sdb>civodul, yeah, thought I did that... :p Well I can leave menus for the pro's and just add text.
<mbakke>GNU Make is also "stuck" on Guile 2.0, but that's changed in upstream git IIRC.
<civodul>sdb: if you send the patch and errors to help-guix or here, perhaps people can help you decipher the error messages and fix the issue
<civodul>mbakke: oh, is it?
<civodul>i think GNU Make doesn't use the one API that has changed in 2.2 (ports)
<civodul>so it might be just a matter of having configure accept 2.2?
<ngz>civodul: Notwithstanding the manual markup language, which I do not comment, Org does have markup. Not a superset of Texinfo's but not a subset either.
<civodul>ngz: i agree, but that's my point ;-)
<sdb>civodul, ok, but mind that this makes it quite cumbersome to contribute (I already know org-mode, I don't know texinfo and the errors are not self explainatory)
<civodul>ngz: it always starts as: look, it's simple, it's markup-less!
<mbakke>Oh, perhaps it's just a configure check that has been updated indeed. I tried switching to 2.2 during core-updates, but it failed.
<civodul>ngz: and then, you add markup, and that markup happens to have more complex rules than existing markup languages
<civodul>mbakke: it might be: GUILE_PKG([2.0]) → GUILE_PKG([2.2 2.0])
<ngz>I don't think it can be more complex than Texinfo's, which is only an order of magnitude below LaTeX.
<civodul>well, nodes/menus aside, Texinfo is simple IMO
<mbakke>civodul: I'll give it a go for the next core-updates.
<mbakke>Speaking of which, should we start planning a date? Maybe end of next month?
<civodul>ngz: i'd say, with all due respect ;-), that it's simpler/more regular than #+BEGIN_EXAMPLE and the like
<ngz>Ordered/unordered lists are messy, so are table. @ref/@xref/@pref are a pain, too.
<civodul>it also does fewer things, true (Babel, etc.)
<ngz>err @pxref
<civodul>they are a pain, true, but nothing else has similar functionality AFAIK
<civodul>that is, you can refer to nodes in another document
<civodul>and that works regardless of the backend
<ngz>Well, at least, in #+begin_example... you don't need to escape every @ with another @ ;)
<civodul>well you have to escape stars, right :-)
<ngz>So does Org.
<ngz>(about referring to other documents)
<ngz>Only at the beginning of the line: Org wins.
<civodul>but references are typically info:, or gnus:, or URLs, no?
<ngz>They can be [[*Section]]
<civodul>but that's much less expression than Texinfo references + htmlxref.cnf
<civodul>well, at least for the particular purpose of linking manuals together
<ngz>I don't know. I would need to look at an example to see what expressiveness you are talking about.
<civodul>for example, guix.texi contains references to the glibc manual
<civodul>in, you can follow those references
<civodul>and in guix.html, you get hyperlinks to the on-line HTML copy of the glibc manual
<civodul>and in guix.pdf, you get a human-readable reference
<ngz>So does Org :)
<civodul>how does it worK?
<ngz>We hard-code a list of manuals
<efraim>We also have some packages depending on guile 1.8.8
<ngz>See, e.g., org-info-other-documents
<rekado>efraim: yes, the manual there isn’t properly linked yet. It’s at and
<efraim>rekado: thanks
<ngz>And the function `org-info-map-html-url'
<efraim>I was going to write a service to have it on my own machine but that also work
<civodul>ngz: i see; org-info-other-documents is kinda like htmlxref.cnf, but without differences between mono/split HTML manuals ;-)
<ngz>There it is: org-info-emacs-documents
<civodul>then again, Org is extensible and Texinfo isn't
<rekado>ACTION thinks Texinfo has pretty simple markup.
<civodul>anyways, i'm a big fan and everyday user of Org!
<civodul>i just happen to prefer Texinfo for this particular job :-)
<civodul>as old-fashioned as it is ;-)
<sdb>I'm following the discussion.
<ngz>And I'm happy to have moved from Texinfo to Org for the Org manual :)
<rekado>mbakke: do you mean a date for merging core-updates?
<sdb>I just read up on the texinfo documentation. It seems pretty well written, I just did not read it before starting to edit.
<rekado>the next core-updates freeze will be on <2018-08-06 Mon>, merge is planned for <2018-08-20 Mon>
<rekado>(according to my org buffer)
<sdb>What I reacted to after having edited and created a submenu in contributing.texi was the error messages. e.g.
<sdb>doc/contributing.texi:30: warning: node next `Building from Git' in menu `Running Guix Before It Is Installed' and in sectioning `Cloning and setting up the environment' differ
<mbakke>rekado: Oh, I've missed that discussion. That merge date seems optimistic though ;-)
<sdb>maybe it is clear to others what I did wrong.
<mbakke>We'll get to beta test glibc 2.28 then, most likely :-)
<sdb>I imagine it would have been easier in an org-document similar to the one I linked to. maybe i'm wrong. At least org-mode is easier to navigate than a large texi-file. So if we keep to texi I agree it is a good idea to split it up.
<rekado>mbakke: the date stands or falls dependent on how serious people take it ;)
<mbakke>rekado: Even this 'staging' round has taken two weeks... But with luck we can start to decommission Hydra around that time.
<rekado>who is too optimistic now…? :)
<mbakke>Heheh :)
<sdb>civodul, ngz I think the errors I introduced is that I made a submenu with subsections but copied the @section (not knowing it should be @subsection)
<sdb>rendering this: doc/contributing.texi:1: node `Contributing' lacks menu item for `Compiling and running the Test Suite' despite being its Up target
<civodul>sdb: yes, it must be something like like missing nodes in the menu, or wrong node order, or wrong name
<sdb>civodul, I got it compiled finally. I made a submenu without adding sub to the sections.
<civodul>heh, good that you found out
<sdb>so after reading the documentation texinfo is not that bad, but the error-messages could be better regarding getting the menu and @section-stuff right.
<someUser>I can't seem to get guix installed. I made a root partition and ran this script. I made the script myself so it might have some problems.
<sdb>someUser, what error do you get?
<sdb>someUser, did you label the "root" partition?
<someUser>yes I did, it just didn't boot after a reboot
<someUser>can't remember the error but I only had one partition, do I need a partition for grub?
<sdb>a ha. So the guix system init succeded?
<someUser>no I was still in the installer
<sdb>someUser, I think I found the error in your config. one moment
<sdb>someUser, yep. Your target for the bootloader is incorrect.
<sdb>it should be a disk not a partition.
<sdb>e.g. /dev/sda (not ../sda1)
<someUser>ha and can it use the same disk as where the root one is stored? The disk probably needs some free space for grub?
<sdb>someUser, also there is an error in your (device...
<sdb>mine looks like this: (device (file-system-label "my-root"))
<sdb>which specifies what your are giving it (not a /dev/sdx1 or mapped-device but a label)
<someUser>Thanks! I will try to install it again a bit later today!
<mbakke>There are some xorg drivers for exotic hardware that fails to build against xorg-server 1.20. I wonder if we should remove them from %default-xorg-modules for now.
<civodul>mbakke: do you think it can be done safely before 0.15.0, or should we wait until after the release?
<efraim>If we do it now would it make the example os configs build?
<efraim>Do they build currently?
<jlicht>do we have anything packaged cq does there exist a free software package for 'pair-programming' remotely?
<civodul>rekado: we should consider setting up,, and similarly with
<civodul>roptat: is setting up Knot as easy as the manual suggests? :-)
<roptat>yes it is :)
<rekado>I can add and have it point to berlin’s new web interface — once that’s merged.
<efraim>I assume you don't count using 'screen -x' for multiple people in the same session
<rekado> now points to the berlin server.
<rekado>I’m feeling like working a bit on the website to move all GuixSD things to
<civodul>rekado: did you reconfigure berlin with a Knot thing?
<rekado>what is a knot thing?
<rekado>(I did not)
<civodul>rekado: Knot is the DNS service we have in GuixSD
<civodul>it seems to be incredibly easy to use
<rekado>I’ll have to take a look
<rekado>(I added the record on the web interface.)
<civodul>rekado: i've emailed guix-sysadmin a plan to move forward with
<civodul>rekado: relatedly, would you like to announce the "Guix System" idea on the list? :-)
<efraim>civodul: I have ssh forwarding up on the overdrive and my power is back on, want to test offloading?
<rekado>civodul: yes! I’ll do this in a couple of hours when I’m free.
<civodul>awesome :-)
<civodul>efraim: 'guix offload test' fails with a timeout issue on berlin, but i can ssh just fine from my home
<civodul>dunno what's going on
<civodul>the firewall at the MDC was set up correctly before
<efraim>I had to change my ISP and right now its using ssh forwarding through a VPS in Amsterdam
<civodul>that may be the reason
<efraim>You can try connecting directly, if its working directly it'll be at
<civodul>port 52522?
<civodul>doesn't seem to work
<civodul>rekado: as time permits, could you give your IT colleagues the new IP of
<efraim>Same for me with my other machines
<civodul>ACTION goes afk for a while
<someUser>hmmm, th guix installer gives me an error file-system-label unbound variable
<roptat>someUser: if you're using 0.14.0, simply remove file-system-label and use a string
<roptat>I think that's it
<roptat>we introduced file-system-label after 0.14.0
<someUser>ha that's why I had before, but I had some other things wrong so that might be it! Thanks!
<someUser>ok it's installing! I hope that it will work now!
<mbakke>civodul: There is very recent activity in upstream git for all three drivers, so I'll just take the patches unless they release in the next day or so.
<lukas__>Hi. could someone look at my very first config.scm? I tried setting up new system with encrypted home partition but guix is not initializing for some reason
<mbakke>lukas__: Sure, can you upload it to ? Which error are you getting?
<lukas__>@mbakke hi. procedure find-tail is complaining arg 2 is not list. here is the link :
<lukas__>do you want me to upload full error message too?
<someUser>I just finished with installing, I am glad that it works but I can't seem to find the default password online. A bit of a noob question.... but what is the default password?
<mbakke>lukas__: Try changing (dependencies "/") to (dependencies mapped-devices).
<mbakke>If that doesn't work, please upload the error message :-)
<mbakke>someUser: There is no default password, try logging in as root on the console to set one.
<someUser>ha ok, thanks!
<mbakke>That could probably use a better explanation in the manual.
<lukas__>@mbakke many thanks! now it is bootstrapping. mb it's time for me to study manual more closely and request update on this article :
<mbakke>lukas__: The home partition probably also doesn't need (needed-for-boot? #t).
<mbakke>lukas__: May I ask why you choose not to encrypt the entire disk?
<lukas__>@mbakke no special reason. I just find FDE pointless unless I keep the kernel on separate super secret USB device or smth
<lukas__>but I am thinking about going FDE on my laptop after becoming more familiar with guix(it's currently devuan). and maybe write useful howto article somewhere
<mbakke>lukas__: If you do FDE as in the manual, the kernel remains on encrypted storage.
<mbakke>Only the bootloader is unencrypted. Sure it can be subverted, but it's a lot better than nothing :-)
<lukas__>@mbakke welp, don't know how I missed that part
<mbakke>The drawback is that you need to unlock the root partition twice: once for GRUB to read the kernel and config, and second for Linux-Libre.
<someUser>well I can login now but i am stuck at the loggin in screen. I am not sure of xmonad is supported? or I missed something.
<mbakke>someUser: I suspect xmonad is not fully supported. Perhaps nckx knows the status.
<someUser>hmm, just wanted something light, how well is bspwm supported or any other wm?
<mbakke>someUser: i3 is very popular, I haven't tried bspwm.
<someUser>ok I am familiar with i3 so I will install that one then
<someUser>Thanks for the help!
<mbakke>someUser: Happy to be of service, enjoy your new distro :-)
<jonsger>civodul: is guile-sqlite3 under GPL3+ or LGPL3+ or both?
<someUser>searching a while on how I can add i3 into the display manager, what is the name of the default display manager? It looks like SLiM? Sorry for the many questions.
<jlicht>efraim: I'll consider 'screen -x' as a last-resort solution ;-)
<someUser>Hmmm, what is screen exactly? It isn't installed yet and I am not sure if I want that
<jlicht>someUser: hi!
<jlicht>afaik, screen is a terminal multiplexer; I've used it to keep terminal sessions alive and connect to them over SSH.
<someUser>hmm sounds useful!
<jlicht>You could also consider tmux or abduco; I've heard good things about both.
<sahithi-ihtihas_>Hello guix
<sahithi-ihtihas_>I am getting an error when i used make
<sahithi-ihtihas_>what might be the reason for that?
<sdb>hi, again
<g_bor[m]>The problem is the no code for module json.
<g_bor[m]>sahithi-ihtihas: Is this a fresh checkout?
<sahithi-ihtihas_>export GUILE_LOAD_PATH=$HOME/.guix-profile/share/guile/site/2.0
<sahithi-ihtihas_> export GUILE_LOAD_COMPILED_PATH=$HOME/.guix-profile/share/guile/site/2.0
<sahithi-ihtihas_> I used above to find guile-json
<efraim>on my computer it's 2.2
<g_bor[m]>I also expect it to be 2.2.
<g_bor[m]>efraim: could you find the problem with classpath?
<sahithi-ihtihas_>sorry , I used 2.2 itself...but still i find same error
<efraim>g_bor[m]: still looking at it, I didn't have any problems when I was testing both paths of the if statement on my arm board
<g_bor[m]>efraim: I think it is in the ecj-javac-bootstrap, but I could not find out why is it problematic. It seems that one more list it missing, as it tries to apply on a string... WDYT?
<efraim>i think it's in ant-bootstrap
<efraim>i kept on finding similar issues with armhf before I added the 'if'
<efraim>mmm, maybe ecj-javac-wrapper
<efraim>might not like the two list thing
<g_bor[m]>yes, that's what I meant, sorry.
<g_bor[m]>I'm testing my suspicion...
<g_bor[m]>there is and if statement containig this noinline stuff...
<efraim>the Xnoinlining was there before
<g_bor[m]>efraim: I've dropped that, and it now passes the configure test... Actually replace that also with '().
<g_bor[m]>Do we know why is it there?
<efraim>i tried putting Xnocompact in the armhf branch of the if and I get the same configure failure
<efraim>;; Without these JamVM options the build may freeze
<efraim>from ant-bootstrap, apparently it's needed for x86_64
<g_bor[m]>So, the problem definitely comes from ecj-javac-wrapper. I guess we can ignore ant-bootstrap now.
<efraim>i took out the whole 'if' on my x86_64 and aarch64(armhf) machines, testing it on both now
<g_bor[m]>sahithi-ihtihas_: could you try a make in a guix environment guix?
<efraim>seems to be working on both
<sahithi-ihtihas_>same error again
<g_bor[m]>opression in not ok. Maybe some quoting thing, but I could not yet find out the correct form...
<efraim>sahithi-ihtihas_: you're in the checkout? try with ./pre-inst-env guix environment guix
<g_bor[m]>efraim: Sorry, so the else expression is not ok, if it was working on armhf.
<efraim>g_bor[m]: looks like the 'true' branch of the if wasn't any good either, but the '() covered it up
<efraim>i took out the whole if and the list and now building to ecj-javac-wrapper-final on both machines
<g_bor[m]>sahithi-ihtihas_: If that still does not work, can you try to get a fresh checkout, bootstrap, configure and make?
<g_bor[m]>efraim: I think, that you can now solve it, WDYT?
<efraim>g_bor[m]: i was worried about my laptop overheating while testing but it seems to be alright, I have it from here
<g_bor[m]>efraim: Thanks.
<rekado_>efraim: is the build host available at now? Is the IP static?
<efraim>rekado_: I don't know how static the IP is, the overdrive is online now
<efraim>rekado_: from my VPS I can't ssh into it, but from home I can ssh into which has an ssh reverse tunnel
<rekado_>I’m asking because I have no personal control over the MDC firewall, so changes are very slow.
<civodul>jonsger: per the headers in source files it's under LGPLv3+
<civodul>but LGPLv3 is defined in terms of GPLv3, so you need both texts
<Rukako>that explains why LGPLv3 is so short compared to GPLv3, I was always wondering but was too scared to read the actual legal text
<civodul>it's not that bad ;-)
***Steap_ is now known as Steap
<jonsger>civodul: I made it LGPL and GPL
<g_bor[m]>sahithi-ihtihas_: How did it go?
<mbakke>efraim: I got a bad signature from you on <>.
<mbakke>Isn't that a duplicate of <> anyway?
<OriansJ>I don't know if you anyone else realized this but guix has an older version of astyle then debian. (2.0.5 vs 2.0.6) with 3.0.1 being more than a year old
<mbakke>OriansJ: Would you like to try updating it? :-)
<chewzerita>Does gnome on guixsd use wayland or x?
<taylan>chewzerita: I think you switch between it using F1, because for me it switches between "GNOME" and "GNOME (Xorg)" or something
<taylan>in the login screen that is
<chewzerita>taylan: and just "GNOME" is wayland?
<taylan>chewzerita: I assume so, but haven't checked. would be strange if it was also X.
<taylan>hmm, shows Type=x11 in 'loginctl show-session' output even when logging into the one without X11, so maybe I'm wrong
<taylan>ACTION shrugs and goes to sleep :)
<wliw>How do i add an additional initrd in grub. Im
<wliw>trying add intel-ucode.
<OriansJ>mbakke: here you go I have verified that it builds but I have not verified it builds reproducibly beyound --rounds=100
<rekado_>The latest version appears to be 3.1
<rekado_>I’ve just updated it.
<OriansJ>thank you rekado_