<mbakke>I think Hydra has given up on 'staging'. <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. <mbakke>Woah, WPA3 is "out". Hopefully it's easier to crack than WPA2... :( <mbakke>ACTION misses the WEP days with free internet everywhere <ngz>The good aircrack-ng old days. <sdb>which conferences does people from this community attend? libreplanet and fosdem? <noobly>where might one find a detailed comparison between guixsd and nixos? <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 <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>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'" <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) <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 <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 <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) <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 <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>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. <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>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, 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 <ngz>When I migrated old manual to the Org format, I wrote a couple of function to do some tedious work and finished manually. <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. <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_>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_>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. <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/guix-pack.sh 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>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. <efraim>Change the default libcs to gblic and glibc-1? <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 <rekado>is it unreasonable to make glibc-locales a proper dependency? <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>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>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>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>it's not optimal, but it should allow people to solve the issue quickly most of the time <rekado>what happens in the guile-2.2 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>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 <civodul>it's just the "warning:" line that's not shown in 2.2 <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... :( <civodul>rekado: i'm adding "See 'Application Setup' in the manual" <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>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? <sdb>I stumbled on just nodes and menus :p <efraim>rekado: I saw guix.info, 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>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.) <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>(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 [[my-other-document.org::*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 guix.info, 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>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 guix.info/manual/en and guix.info/manual/fr. <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 :-) <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> <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. <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. <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. <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? <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? <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 guix.gnu.org, ci.guix.gnu.org, and similarly with guix.info <civodul>roptat: is setting up Knot as easy as the manual suggests? :-) <rekado>I can add ci.guix.info 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>ci.guix.info now points to the berlin server. <rekado>I’m feeling like working a bit on the website to move all GuixSD things to guix.info/system <civodul>rekado: did you reconfigure berlin with a Knot thing? <civodul>rekado: Knot is the DNS service we have in GuixSD <civodul>it seems to be incredibly easy to use <rekado>(I added the record on the inwx.de web interface.) <civodul>rekado: i've emailed guix-sysadmin a plan to move forward with guix.gnu.org <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>efraim: 'guix offload test' fails with a timeout issue on berlin, but i can ssh just fine from my home <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 <efraim>You can try connecting directly, if its working directly it'll be at zebra.flashner.co.il <civodul>rekado: as time permits, could you give your IT colleagues the new IP of flashner.co.il? <efraim>Same for me with my other machines <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>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 paste.debian.net ? Which error are you getting? <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. <mbakke>That could probably use a better explanation in the manual. <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 <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>afaik, screen is a terminal multiplexer; I've used it to keep terminal sessions alive and connect to them over SSH. <jlicht>You could also consider tmux or abduco; I've heard good things about both. <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_COMPILED_PATH=$HOME/.guix-profile/share/guile/site/2.0 <g_bor[m]>efraim: could you find the problem with classpath? <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 kept on finding similar issues with armhf before I added the 'if' <efraim>might not like the two list thing <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 '(). <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? <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 <rekado_>efraim: is the build host available at zebra.flashner.co.il 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 git.flashner.co.il 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 ***Steap_ is now known as Steap
<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? :-) <taylan>chewzerita: I think you switch between it using F1, because for me it switches between "GNOME" and "GNOME (Xorg)" or something <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 <rekado_>The latest version appears to be 3.1