<apteryx`>Is it acceptable to use Guile's SRFIs in a Guix package definition (builder side) ? <rekado>apteryx`: yes, but you need to declare them in #:modules if they are not already part of the default set. ***jonsger1 is now known as jonsger
<apteryx`>I guess that'd be a macro... I haven't delved in those much yet. <brendyn>my guix pull is taking 2 minutes 40 to compute the generation and decide there is nothing to be done <rekado_>apteryx`: substitute* supports regular expressions, but you could also map substitute* itself over a list of terms. <g_bor>Can someone confirm me that icedtea 7 and 8 now builds on master? <g_bor>I just can't seem to get on hydra... Always times out. <brendyn>i'm building all sorts of stuff with --no-substitutes. ill see how it goes <rekado_>brendyn: “--no-substitutes” will take a long time. <rekado_>the icedtea builds on their own already take a very long time. <brendyn>how can i just build icedtea then but use substitutes for other stuff <ngz`>icedtea-3.7.0 builds on x86_64 <ngz`>or maybe not... Last evaluation is from June? <g_bor>Thanks for help, well be back in an hour, I have to travel now. <rekado_>g_bor[m]: I’m building hotspot for icedtea-7 now. <civodul>cuirass.db is already at 2.8GB, even though it was emptied somehow a few weeks ago <civodul>we really need to do something about it :-) <rekado_>g_bor[m]: I had a silly idea just now. Maybe we can build much simpler versions of icedtea-6 and icedtea-7. <rekado_>currently, they include all sorts of stuff which is probably not needed for bootstrapping the latest version. <rekado_>I wonder if we could kick out all support for GUIs, sound, etc <rekado_>I also wonder if we could use JamVM instead of Hotspot for the early JDKs. <rekado_>it’s also a modern VM and would probably take much less time to build. <efraim>if we can skip icedtea-6 then we'd have a better chance of supporting aarch64 directly, but I think it makes more sense to get i686 and armhf working first <efraim>owncloud-client builds with qt updated to 5.11.1 <efraim>demotri: you probably want gcc-toolchain <demotri>efraim: Thanks, there it is. Took a while to build the environment. <ngz`>I think glibc was enough <ngz`>gcc-toolchain is a bit overkill if you only need ldd <g_bor[m]>brendyn: Actually 1.13 is known to work. <brendyn>guix build: error: build failed: some outputs of `/gnu/store/49shxlw4401h51ygdmjk3g9rb8x6wcf5-icedtea-3.7.0.drv' are not valid, so checking is not possible <g_bor[m]>I remember seeing this kind of message when the package was not build locally before. Check has nothing to compare the results to. <brendyn>/gnu/store/y0xsqlg8j9ycsyqk7p1s4z8qv9lcpz4m-icedtea-3.7.0 <g_bor[m]>brendyn: Thanks for checking :) It's just it was very late when I pushed this fix and could not make sure it's ok. <rekado_>efraim: I don’t think we can skip icedtea-6; it’s the first proper JDK in the bootstrap chain. But I hope we can make it build faster. <rekado_>efraim: would it make sense to use a different VM for arm? <rekado_>efraim: if you were able to build jamvm on arm, I think it would be good to disable hotspot and switch to jamvm for icedtea-6. <g_bor>ok, it seems that icedtea is ok now, and it also fixes the libsnappy problem <efraim>rekado_: looks like I have jamvm building on armhf <efraim>right now on staging armhf fails on icedtea-6 during configure with: checking if the VM and compiler work together... configure: error: VM failed to run compiled class. <efraim>but I figured it can wait until after qt-5.11.1, which fixes most of the qt-5.11 problems <rekado_>doesn’t that test use JamVM, though? <efraim>or at least I think it does on armhf <efraim>so its definately possible that jamvm isn't configured correctly yet for armhf <ng0>so I wrote a small hack to run nix-daemon on GuixSD... to spare anyone the disapointment^extrawork: the differences between Guix and Nix go deeper, some packages of nix are created in a way that you need to wrap them again <ng0>at least my 2 minute testing so far. some applications work, others don't /end offtopic :) <ng0>ah not end.. maybe we should mention that in the package description? <ng0>I tink guix has update nix again? I had 2.0.4 for a while before it landed in master <ng0>(~4 hours sleep, sorry for the broken grammar) <ng0>prof in the lecture is wondering right now about non-reproducible results of an application.. "all systems should act equal normally..." right... <efraim>I figured out rather late that computer science is way too "scientist-y" and theoretical for me, and I probably should've gone for something engineering <ng0>I just want the final paper.. maybe even do master, and then combine it with another master because I'll be almost 40 anyway when I'm done :) <efraim>or mechanical engineering. I almost tried for a degree in physics when I first tried uni <ng0>I'm like the go-to Unix, general OS, and langauges other than Java person for the students here xD <g_bor[m]>However on the first run powermock repack failed with some scheme error. What could that be? <rekado_>g_bor[m]: hard to tell without seeing the error message. <efraim>I know the feeling, I was the go-to Linux and English guy for years, when I emailed a professor asking about running some of the course programs under linux he sent me to talk to myself about the feasibility <g_bor[m]>I've lost that unfortunately, scrolled off the terminal. It is sure that it's not deterministic. <g_bor[m]>civodul: What do we know about the guile thread safety problem? Any more insight? <efraim>qsyncthingtray still FTBFS with qt5.11.1, different error, it seems qtwebkit-5.9 just isn't compatible with qt5.11.x <ngz`>IIRC, qtwebkit was removed from qt5.11 <ng0>I would've like the option to study languages rather than something at university of applied science. but life happened. <rekado_>g_bor[m]: with Guile 2.2.4 it should be gone AFAIU. <efraim>there's a community qtwebkit on github that debian is using <efraim>minimal update of coreutils-8.30 on core-updates failed, didn't try to debug it <civodul>i'm putting that on hold for now, though <ng0>contrary to my email: lots of projects this week came up and I can't work on the readme <civodul>rekado_: unfortunately one of the issues is still manifesting (that happens when using Guile 2.2 for grafting) <ng0>wow this is annoying. they are now 15 minutes into wondering why the application does not behave in a reproducible manner <civodul>but at least the 'guix pull' use case seems to be okay <rekado_>I’m building Guile 2.2.4 (as part of “guix pull”) right now. <rekado_>will try guix pull on one of the big servers <roptat>ng0: it's your time to show off and save the lecture :) <roptat>or hijack it and advertise reproducible-builds.org ;) <ng0>I don't want to spoil the fun of them almost not very likely ever figure out that reproducible builds excist <rekado_>(I’m a little bit scared that sleep is taking on an ever more important role in my life.) <g_bor[m]>rekado_: I'm thinking about injecting parameters to javadoc to leave out the timestamp. WDYT? <rekado_>maybe not on the master branch, though <ng0>JOption.Pain.sleep() <rekado_>the JDK builds are so slow and so are the builds of all Java packages. <civodul>does anyone remember if 'guix system init' was idempotent before? <civodul>currently it breaks if you run it a second time on an already-populated directory <roptat>I remember rebooting several times in the installation media and re-run guix system init <efraim>I believe we basically recommend running it over and over until it succeeds <ng0>in earlier versions it worked like that <efraim>I thought it as "like guix system reconfigure, but always produces generation 1" <roptat>if you fail your partition declarations and it installs a broken system, you want to start again <ng0>huh. emacs-guix builds with 2.2.3? <reepca>Agh, I really don't know where to ask this. What is the usual meaning of a "site" directory in a package's output? <civodul>reepca: i think the original meaning is lost in history :-) <reepca>is the modern meaning still around somewhere? <civodul>there's no modern meaning, it's just a sequence of letters ;-) <civodul>you thinking of Guile's site directory for instance? <civodul>it used to be something about "site-specific installations", i guess <ng0>last night I started reading into how nix handles python packages. how did we end up again with what we do now for python? <civodul>reepca: so in Guile's "site" dir, you put extra modules not part of Guile proper <reepca>Sounds like the directory I'm looking for. Now I just need to convince gforth to actually look in there for wrapper libraries... currently I just have my own "gforth-kitchen-sink" package and I'd really like to make separately-installable packages for the various wrappers. <ng0>got to change the room <brendyn>wow chez scheme takes a long time to build <brendyn>does guix have a way to build programs in parallel? <reepca>--cores and --max-jobs, depending on what kind of parallel you mean <reepca>sounds like you'd want --max-jobs, then, but I'm guessing it shouldn't be set higher than the number of guixbuilderX users you have. <rekado_>do you know how to make EXWM respond to screen resolution changes? <rekado_>when I connect to a projector with lower resolution it only displays a small fraction of the screen instead of scaling down to fit the new screen size. <brendyn>I made 10 builders but I wasn't aware I've ever been building multiple packages at the same time <reepca>well, in 2.5 of the manual, it says the default value is 1. <nckx>ACTION just sent mail saying I CC'd civodul in which I did not CC civodul no need to send me mail saying I did not CC civodul oops <nckx>QEMU works without graphics, rite? <jonsger>nckx: I wondered because guix-devel@gnu.org is a little general for one author :P <nckx>I am wearing the cone of shame. <nckx>Good thing it was a very serious bug and not some trivial annoyance! /s <nckx>ACTION crawls deeper into the cone. <nckx>civodul: Just a question about why we alias ls to always force coloured output. <civodul>nckx: it's not forced, it's --color=auto <civodul>you can override it in your own files, though <civodul>or would you like to override the default? <nckx>civodul: That's what I thought too, but nope: gnu/system/shadow.scm:alias ls='ls -p --color' <nckx>man ls: --color[=WHEN]: colorize the output; WHEN can be 'always' (default if omitted), 'auto', or 'never' <nckx>Turns out I've been overriding it for ages and hence didn't notice. <civodul>i must have another ls alias somewhere <demotri>nckx: Right, alias is set to color. When use ls --color=auto | less, it looks nice. <nckx>demotri: Thanks for the confirmation. I'll look into the environment variables to see if they're upstream-preferred somehow & push a patch later. I'm building the installer now. <apteryx`>rekado_: re substitute*, I'm not sure how I could use map over it? It seems to expect some patterns to match rather than variables and such (being a macro). <apteryx`>but you are right that I might be able to do everything without using my own regexps, since substitute* supports those... If I can prefix a submatch with some fixed text, that would work! <Rukako>civodul: what should I do about testing? you mentioned something about automake a while ago I think <rekado_>apteryx`: I meant to map a lambda using “substitute*” over a list of patterns, i.e. to patch the file multiple times, but admittedly that would be ugly. <rekado_>apteryx`: it is much better to use regexps here. <g_bor>roptat: maven-compat fails ArtifactDeployerTest for me. It is still masked by the ignored #f bug. <civodul>Rukako: for testing, see tests/*.sh in the Shepherd <civodul>Rukako: however, could you email us an update before diving into that? <g_bor[m]>Could you also include a short write up on how to test you project? It would be nice to let the community know, and maybe we could gain some additional insight. <Rukako>g_bor[m]: right now I am simply running shepherd as a user in order to test it, my method is quite primitive and unproductive which is why I am asking for something better <Rukako>civodul: sure, in fact I am preparing a set of patches to send along my next update <Rukako>something like ./shepherd && ./herd ... <civodul>don't wait until you have a perfect patch set--it's never perfect ;-) <snape>I think there is an issue with cloning cgit https repos <snape>it just displays "cloning into" with nothing else <snape>and guile-git doesn't seem to be able to clone them <civodul>roptat: is there a bug open for the issue with guix.fr showing up in 'dir'? <nckx>snape: I know ng0 does, but I don't know if it's Guix(SD)-based. <roptat>g_bor[m]: I found why the testsuite was failing for maven-compat: it requires jar files... that are actually text files that contain "foo", "local" or "dummy" <roptat>and we delete *.jar files in the snippet <roptat>actually there are some real jar files too <roptat>how do you create an empty file in guile? <snape>roptat: you can grep '(define (touch' in the Guix repo <rekado_>There’s a bioinfo tool that wants to be linked with -lieee; I see that older versions of glibc provided it. Where did it go? <civodul>didn't know about libieee and matherr <PotentialUser-48>when we set the configuration template which locale does we use for colombia'? <roptat>PotentialUser-48: it seems es_BO: "Spanish (Bolivia)" <roptat>so "es_CO.UTF-8" should work fine for you <demotri>Do we have an open bug with the locale? In the freshly installed GuixSD, 'info guix' is all French, although locale is en_US or es_CO. <g_bor[m]>demotri: There are problems with the texinfo locale handling. You can get the English manual using info '(guix)'. ***usuario is now known as bzp
<demotri>g_bor[m]: Thanks. Is that a Guix-specific problem? <roptat>demotri: it's more that there aren't many translated manuals <roptat>so info didn't implement anythingg to support translations <cryptocat1094>Is there a guide or blog post about running your own build farm somewhere? Current Hydra docs don't quite explain how one can get it to parse Scheme rather than just Nix. <rekado_>cryptocat1094: I would suggest using Cuirass for this purpose. <rekado_>there’s a Cuirass service for GuixSD. <snape>cryptocat1094: otherwise, if the expression is in a .scm file, Hydra assumes it's a Guile + Guix build expression <snape>but it's better if you use Cuirass :-) <rekado_>I’m trying to build a headless JDK, but the configure script provided by icedtea does not allow it. <rekado_>it checks for things that really should not be required for a headless JDK. <janneke>it seems there's almost no feedback loop to configure's use or implementation <janneke>and making minor adjustments was never a requirement <janneke>rekado_: if you're lucky, you can prepare a config.cache <rekado_>it’s also almost impossible to patch a configure script. It’s a little easier to patch the configure.ac, but even then it’s messy and I wish it was as easy as patching XML / S-exprs. <rekado_>but I feel that maybe there’s little point in using icedtea if I’m subverting it anyway. <rekado_>might as well use the OpenJDK Makefile directly and patch that as needed. <janneke>rekado_: chances are, it's impossible to reproduce the correct version of the autotools -- unless maybe your software is less than 2y old <rekado_>I’m not happy with the Java bootstrap. <rekado_>we build three versions of the full OpenJDK, each of which takes up a lot of space and needs a lot of time to build. <rekado_>maybe there’s a way to build javac, the standard libs and jamvm to get to an equivalent of JDK 6 (and then do the same thing for JDK 7) without having to build the whole shebang. <janneke>i'm hoping that when we get a full source/reduced binary seed bootstrap in place for GuixSD, we can generate some more discussion about usage of binary seeds <janneke>i'm guessing you experience this pain mainly because "everybody else" is just injecting binary seeds and ignoring the bootstrap problem? <rekado_>it’s a rather lonely island that I’m inhabiting with bootstrapping the JDK. <janneke>yes, if/when we get a broader bootstrapping community onboard, it will me much more fun and lots easier <rekado_>many others just use whatever the distribution offered as a previous JDK, or they use a JDK-sized blob. <janneke>being at the forefront of something new is never an easy task <janneke>it's by our own choice that we want to create a change, right? <rekado_>So… I’m not really happy with EXWM :-/ <rekado_>it’s really convenient, but it has a couple of quirks that I really don’t like. <janneke>it would be nice to get the debian people (vagrantc?) involved with this java/jdk bootstrapping <janneke>oh...sad -- i'm a happy user for about a year now (yes, there are problems but they seem not important to my use case) <rekado_>when I connect to an external display with lower resolution (e.g. a projector) the screen just gets cut off, for example. <rekado_>I learned today that this makes it rather difficult to give presentations this way :) <janneke>rekado_: ah yes, i only use xrandr mirror mode <jonsger>ACTION has no idea how opensuse handles java bootstrapping... <rekado_>I use lxrandr because I can’t remember the xrandr command line syntax :) <janneke>and re-adjust my resolution to that of the projector -- which isn't nice but doable <janneke>heh, i have mirror and unmirror scripts <rekado_>when I adjust the resolution EXWM does not resize the windows ¯\\_(ツ)_/¯ <rekado_>It’s probably my fault, but I’m too impatient to try to figure this out. <janneke>i have a hdpi, so i have to juggle GDK_SCALE and my frame-font and if i need to run (@#$&!!) QT apps i also need to run xrdb and set Xft.dpi <janneke>rekado_: here's my terribly mirror script <janneke>vagrantc and right you are -- but i hoped you'd have connections into the Debian/java world <janneke>to ask some "nice" questions about bootstrapping and introduce rekado_'s problem ;-) <vagrantc>i know some folks, true ... i'll see if they bite <cryptocat1094>Is our architecture different enough that the same solutions NixOps uses cannot simply be translated to Guix? <janneke>vagrantc: thanks...i know from working at #bootstrappable that facing a problem or even problem-area together is so much nicer than feeling alone <vagrantc>janneke: this is regarding bootstrapping openjdk? <demotri>cryptocat1094: Yes: In the sense that Guix complies with FSF's FSDG (Free Systems Distributions Guidelines). That means every peace has to be free software. And Guix has the aim to bootstrap everything from source. Nix is different: They are more "pragmatic" and just pack some binaries in for compilers or build tools. <janneke>vagrantc: yes -- here's what rekado_ said about it <janneke><rekado_> we build three versions of the full OpenJDK, each of which takes up <janneke> a lot of space and needs a lot of time to build. [22:17] <janneke><rekado_> all that just to get to OpenJDK 8. [22:18] <janneke>i'm not personally involved, please talk to rekado_ directly if you have a question <vagrantc>could also just email the java team directly, but i've pinged one of the folks i know directly <janneke>vagrantc, rekado_ were any of the Debian java team in Berlin? <cryptocat1094>demotri: That's not quite what I meant. I was talking about a configuration management tool Nix has and wondering if there was any particular difficulty in replicating it for Guix. https://nixos.org/nixops/ <cryptocat1094>demotri: In theory one could just have a few hundred pre-installed GuixSD server and then manage their services with "GuixOps" <rekado_>@ build-succeeded /gnu/store/lxp57avp7dll2l5zqx14z93adpzc65f0-langtools-jdk6-1.13.13.drv - <rekado_>janneke: I also avoided the Java discussions last time; or at least I don’t remember much about them :) <rekado_>IIRC most of the people who talked about Java were interested in how F-Droid does things. <vagrantc>doko maintains a number of compiler toolchains ... was at one of them in berlin, i forget which RB summit