<thomassgn>sneek: tell atw thanks for the paste and info. Made my day even more productive :) <sneek>atw, thomassgn says: thanks for the paste and info. Made my day even more productive :) <thomassgn>sneek: botsnack, even though I think I failed... :) <atw>thomassgn: I read the log, thanks :) I think the sneek invokation is "sneek: later tell <person> ..." <Apteryx>can someone tell me if the usual docker stuff like: FROM:debian:stretch\\n apt-get update -qq && apt-get install -y means it's wasting Debian's mirror bandwith *every* time the docker container is fired up (typically at every CI job -- say, every commit!) ?? <thomassgn>no idea, potentially. They probably know better in some docker channel though. I know they host their own images/machines, but that's where my knowledge ends... <thomassgn>but it does seem like it is taxing someones, potentially debians, servers quite hard... <Apteryx>thomassgn: I just asked in #docker. Basically everything in the first RUN directive is cached (which means your apt-get update && apt-get install ...) is typically only run once. But it depends on how your Dockerfile is made. If you use apt-get install commands later on, then these will not be cached. <Apteryx>is it not possible to define authorized-keys for the lsh-service the way it is for openssh-service? <Apteryx>looking at the source, it seems not. <Apteryx>it's slow to download all the icecat patches over the network one by one <platoxia>is the package docker-compose just a front end for docker or is it actually docker by another name/functionality? <clacke[m]>it is a language and a tool for composing docker instances <platoxia>okay, so docker isn't available I take it...can't find it with guix package -s docker <Apteryx>platoxia: not yet. ng0 knows someone working on it IIRC. <atw>How can I use local-file to represent the current directory? I'd think it would be (local-file ".") but that fails. <Apteryx>you might need #:recursive #t, since this is a directory? <atw>hmm, I haven't gotten a single working invocation of local-file. I'm always getting "While compiling expression: ERROR: Throw to key `match-error' with args `("match" "no matching pattern" (filename . #f))'." <atw>ok, I was trying to use a local-file as the source in the package definition. It looks like (source (local-file "src" #:recursive? #t)) works, but I can't evaluate (local-file "src" #:recursive? #t) at the REPL. <atw>(I moved stuff into src/ to accomodate the above) <atw>anyway, I've got to call it a night. Later! <Apteryx>sneek: later tell atw right, the local-file and other file-like objects need to be "lowered" into actual things by a gexp compiler, so to try them out at the REPL you'd need to use the correct gexp facility (I'm not sure myself which one :). <sneek>Welcome back marusich, you have 4 messages. <sneek>marusich, buenouanq says: It only worked as expected/desired when sshd was the only service - After installing Gnome it fails again... I'm going to now try switching to Xfce or maybe just a raw %desktop-services to see if we can isolate it further. <sneek>marusich, buenouanq says: still fails to start properly with just %desktop-services (no xfce or gnome) <sneek>marusich, buenouanq says: if you move openssh after %desktop-services it starts up as expected... I don't understand why this is a thing. ntpd still fails though <sneek>marusich, catonano says: I appreciated your exchange with quiliro. It was valuable information for me too <quiliro>freedombone version for guix would be great <quiliro>marusich: how are you? what are you up to? <quiliro>having difficulties still with guix and with freedombone <quiliro>i think that 90% of email is a waste of time...i should find a way to help me waste less time on it <marusich>If you can devise an <operating-system> declaration that reproduces the problem, please share it with me so I can take a look, also. <marusich>Actually, if you can reproduce the issue, it'd be worth sending to bug-guix@. <marusich>CharlieBrown, it's possible that someone might do that simply because you asked, but if you get the ball rolling and submit even an incomplete patch for packaging it to guix-patches, I'm sure it will be more likely that someone will help you out. <marusich>The Guix manual should explain sufficiently well how to begin packaging the software. The logical place to start would be to check if the dependencies for the software are already packaged, and then go from there. <marusich>The manual also has a section called "Contributing" which describes in more detail how to contribute a patch, such as the addition of a new package definition. <CharlieBrown>marusich: Thanks, but I would rather pay someone to do the job than to deal with the community myself. <CharlieBrown>Speaking any further on this would constitute committing lashon hara. <clacke[m]>"The Hebrew term lashon hara is the halakhic term for derogatory speech about another person." <efraim>i saw that and had to double back to see if I was actually getting cross over between groups or if I read it wrong <CharlieBrown>clacke: Unlike slander or defamation, lashon hara is not a lie. <CharlieBrown>I tried looking for a suitable English term, but failed. <efraim>I would phrase it as "need not be untrue", I also have a hard time with a short english term/phrase <efraim>wow, clisp on aarch64 on core-updates almost passed the test phase, way better than segfaulting during build on main <CharlieBrown>IIRC, the Amish have the same principle and call it gossip. <efraim>we use it to build SBCL, which is used to uglify-js, which is needed for a couple of packages, one of which is a dependency of the mate desktop <g_bor>I was wondering how difficult it would be to regenerate the model of service runs as user, and configuration is read only by that user in guix/guixsd. <g_bor>I was thinking something along the lines of delegating some part of the sevices config to file in the user home directory... <g_bor>One of my concerns is that some files really should not be in the store, because it is world readable, but it would be great if we still had the opportunity to use guix facilities. <efraim>user run services? similar to systemd user services? <snape>g_bor: Services don't need to have all their files in store: you can put some of them in /etc for example, with special permissions. <efraim>i got clisp built for aarch64 on core-updates <civodul>efraim: dunno! how can i reproduce the issue? <civodul>just set up 'guix publish' without --cache, right? <efraim>i know I don't have --cache on my aarch64 boxes <efraim>it looks like it's expecting a gzip format, and now it's getting x-raw-something <efraim>I bet I could test it with 'sudo ./pre-inst-env guix-daemon ..' without having to rebuild a guix snapshot <efraim>clacke[m]: yeah, I think rekado found it easier to bootstrap using a lisp rather than bootstrapping javascript <efraim>civodul: sudo -E guix-daemon ... didn't magically solve it <civodul>rekado: i think it's Tramp that triggers our firewall rule <civodul>Tramp opens SSH connections too frequently, so we then get kicked out <catonano>good morning guixers. Webkitgtk keeps being unavailable :-/ <catonano>as a good new, it seems that the increase in coverage by berlin.guixsd.org hhas become faster. Several percentage points since yesterday <efraim>berlin's still at .0% for aarch64 <civodul>efraim: a little bit more if you look at core-updates :-) <civodul>but there are issues that i'm trying to debug <efraim>I have mine at just under 80% for master <efraim>right now it's wasting time building python-pandas <civodul>you could run guix-daemon with --cache-failures <efraim>and then it won't build known-to-fail packages? That'll help a bunch <civodul>for a build farm it's a good idea to use --cache-failure <wingo>so what are we going to share at fosdem <wingo>i will try to make half of that <wingo>i have a snabb day that day too <rekado>civodul: should we relax the SSH firewall rule on berlin (and bayfront) to allow TRAMP? <efraim>I wanted to get guixsd working on my odroid-c2 before FOSDEM, but I think the best I can possibly get is a guix system reconfigure on top of armbian <wingo>how are guix pull times now? did 2.2.3 end up making things appreciably better or does it feel the same? <wingo>i don't pull often enough to know <clacke[m]>wingo: I read about 3.0. Sounds like it adds a lot of work for the compiler, which would make things even worse? <civodul>wingo: it helps a bit, but it still feels "too slow" <wingo>clacke[m]: that is a separate question :) with guix, the big part is the package collection, and the packages are compiled without optimization <civodul>wingo: so part of it is not Guile's fault, but rather the fact that 'guix pull' builds everything <wingo>clacke[m]: so the amount of work in 3.0 will be similar, but it will run using an engine that i expect to be around 2x-5x as fast, depending on workload, so i expect that 3.0 will be better. <wingo>(b/c native code generation, the compiler will be running with native code instead of interpreted by bytecode vm) <wingo>it's true that the compiler tends to get larger, which is an opposing force, but i have some more knobs in 3.0 to let -O1 etc turn off more things, which is what you want in a package collection compiler <wingo>civodul: i wish guile could be smarter about that too -- to know what to recompile <wingo>or what to compile and what to cache <civodul>yeah, or it could provide tooling to help with that, rather than try to be smart <catonano>will debugging be improved ? Or is pk gonna be around some more ? ;-) <catonano>I'd love to see the talk by Eelco Dolstra about the futre of Nix <wingo>catonano: you mean in guile 3? i have nothing planned, so it depends on what people write :) <clacke[m]>the major issue on e.g. my VPS is RAM though, not CPU, but I guess the compiler improvements make a big difference on systems that have the RAM :-) <wingo>:) when i got into this i didn't realize that cpu and memory usage of the compiler itself were going to be such a big issue <Apteryx>wingo: in the case of Guix, there's not much point about smart caching/recompiling in Guile it seems; we just rebuild the whole thing everytime, and this is the way it is, for purity IIRC. <Apteryx>so it's all about raw compile speed. <Apteryx>catonano: agreed that a nicer debugging experience for Guile would be needed before it can claim superiority over Elisp in Emacs, which has great interactive debugging support. Maybe we could start by hooking the GNU debugger into RealGUD? <Apteryx>it's a rewrite of GUD (Grand Unified Debugger) that provides source debugger for Emacs and is supposedly easily extended to support extra debuggers. <Apteryx>it's not yet packaged for Guix but I've sent a patch recently\\ <catonano>Apteryx: I understand that the woes are not in the Emacs side, though <catonano>Apteryx: I suppose RealGUD needs a debugger backend. And it the backend can't step, then RealGUD won't be able to step, either <catonano>so, as wingo noted, the debugging inrrastructure in Guile is waiting for someone to pick it up <wingo>Apteryx: as ludovic noted, there are some optimization opportunities ther <snape>thank you for the fix civodul <Apteryx>catonano: right... I guess the Guile backend might be a bit spartan right now. <Apteryx>catonano: but the Guile debugger is already able to step. My understanding is that GUD and RealGUD plug into the text based interface of the debugger (the same it would into an REPL). <Apteryx>so at least visual stepping in the sources should be possible with Guile in Emacs. <civodul>Apteryx: instead GuixSD kindly invites you to use mcron <wigust>We don't have CRON at all as I see. :-) <Apteryx>can mcron be run as a non-admin user? I guess you could by running your own shepherd instance? <wigust>plain-file returns an object which could only be produced inside Gexp? Because of that plain-file couldn't be used in 'serialize-FIELD' in the context of define-configuration usage? <civodul>wigust: yes, 'plain-file' returns an object to be used in a gexp <civodul>roughly you could think of it as an opaque object, like a package <civodul>what's the story with serialize-FIELD? <wigust>civodul: '/gnu/store/…-cgitrc' text file could have a string 'project-list=/gnu/store/…-cgitrc-project-list'. The text for cgitrc is generated by serialize-configuration. serialize-configuration works only with fields of the record which should be evaluated to the plain text. <wigust>civodul: I was suggested to produce a 'project-list=/gnu/store/…-cgitrc-project-list' with 'plain-file' inside 'serialize-plain-file', but as we currently discuss it's not possible. <wigust>civodul: I could only manipulate Gexp in activation step or SERVICE-service-type step as I guess. <civodul>wigust: i don't know all the details of the cgit service, so take it with a grain of sale <civodul>but roughly, you could always have something that generates that contents of cgitrc as a file <civodul>then pass that string to 'plain-file' <civodul>actually, what part of the discussion in #29820 discusses this? <civodul>rather than make general statements ;-) <wigust>civodul: Dunno if it worth your time on THIS. <wigust>ACTION kinda thinks could find a work around <civodul>dunno, if you can reduce this to a small issue, that can make discussion easier <wigust>civodul: I think it could be just merged without project-list for now. <civodul>wigust: sounds good, let's not hold it for a small issue <civodul>we can address that small issue later on <civodul>that's (almost) always the best strategy! <rekado>the genomics pipelines that I’m working on are for a paper that mentions Guix in its title. <rekado>up to now I thought that Guix would only be a footnote in that paper, but my boss has other plans. <rekado>now I have to make sure that the claims of reproducibility actually apply in the case of our massive pipelines. <rekado>I wonder how best to do this. I need to build all packages more than once and record the reproducibility status of each package. <rekado>(I’d like Cuirass to have a little option for reproducibility checks.) <civodul>rekado: the pipeline itself is not a derivation, is it? <civodul>if it's a package, perhaps you can simply --check it? <rekado>I’m confident that our pipeline code itself is reproducible; but what about all of the tools it uses? <civodul>as a first approach you could try: guix build --check $(guix gc --references $(guix build the-thing)) <efraim>I don't think we have vixie cron packaged, and I know we don't have a service for it <efraim>Mcron does take vixie cron style cron jobs, but I don't think it supports @restart or other '@' commands <ng0>as a short notice: sonic pi was (one of the) reason(s) why I packaged supercollider. Now I need to wrap up some testing for supercollider, delayed for months, added no GUI because I delayed the GUI part. I'll get back to this in around mid-february and send a patch. Maybe I'll send a patch before that, I just don't have functional email right now, and until middle of february I'm busy. <ng0>iirc supercollider been potentially ready for many months. <ng0>offtopic: emacs singlethreaded slothliness currently delays responds to emails. <ng0>efraim: yes, that's what I haven't figured out in the short time with mcron so far - equivalents to @restart, @reboot, etc ***corpse is now known as mrostu
<civodul>i had been willing to fiberize *something* for a while <civodul>and it turns out that Cuirass deseparately needs more concurrency <m-o>civodul: your recent commits on Cuirass look awesome! <civodul>m-o: i got tired of not understanding what was going on <civodul>and not getting substitutes, all that :-) <m-o>that's how good things happend ;) <bavier`>civodul: anything exciting happening on guix-hpc in your world? <civodul>bavier`: FOSDEM and EasyBuild summit are approaching, that's the main thing :-) <civodul>also on my to-do list: write a post to summarize the discussions around ISA-extension-specific package optimizations <civodul>(this item is available for anyone to pick :-)) <civodul>bavier`: how's everything on your side? <bavier`>civodul: fine; working on packaging some solver libraries and tools <bavier`>slogging through test failures and broken build systems <civodul>did colleagues take a look at all this? <bavier`>the ISA-extensions thing would be important here for a broader audience <bavier`>for running application code; otherwise usefulness of guix would be for benchmarking and profiling tools <bavier`>and our benchmarkers would love it if I could figure out something for multiple-compiler support <rekado>GuixSD does not use systemd. You can use Guix applications with Systemd on a system that uses Systemd, though. <ng0>speaking of "we should make it more clear on the website what Guix and GuixSD is" <ng0>There's an IPA transcript for it, but I think we all pronounce it differently depending on regional background :) <ng0>how can I make guix forget a cached build failure when I'm running the daemon with --cache-failures on my build server? <ng0>is there some section in the manual I forgot? <rekado>have you checked the manual for “guix gc”? <ng0>I've gc deleted the listed items and the connected files, but I'll take another look at the section <ng0>well, no. guix gc --list-failures lists the failures, obviously. guix gc --clear-failures does not clear them. what do you do on for example berlin or hydra when the queue gets stuck on a cached failure? <ng0>do I have to restart the daemon? <ng0>wouldn't expect this.. <rekado>“Remove the specified store items” – you actually need to specify something. <rekado>you could, for example, take the output of guix gc --list-failures as an argument. <rekado>the documentation would be improved by changing --clear-failures to “--clear-failures [ITEM] […]” or so. <ng0>I might sent a patch for it, 91.000 emails to move left. <ng0>75% of the store builds for one architecture only is surprisingly smaller than I thought. <ng0>the help output of gc is already clear though: <ng0> --clear-failures remove PATHS from the set of cached failures <efraim>it looks like lookingglass has '-march=native' in its build flags <efraim>i have one successful build of clisp on core-updates, and it keeps on failing with --check with 3 test failures <bavier`>have we considered importers/updaters from parabola/arch/debian package databases? <rekado>civodul: “guix build --check --no-grafts” does not work on store items, it seems. It seems to require a package name, so I can’t just run it on the unaltered output of “guix gc --references” <efraim>there was a python based debian importer on the guix-devel mailinglist about 2 years ago, nothing came of rewriting it in guile <wigust>rekado: By store items do you mean derivations? 'guix build --check --no-grafts $(guix build -d hello)' works for me. <efraim>on my eventual todo list is writing an rss updater, which would cover at a minimum all of sourceforge <civodul>rekado: you can pass it the .drv name <rekado>yes, I’m filtering the references to extract the package name. <wigust>'guix build $(guix gc --references $(guix build -d hello))' gives guix build: error: reference to invalid output 'out' of derivation '/gnu/store/5vwj3m179ixw8r7gsaz0wimgs7fz9gaw-gcc-5.4.0.drv'. <rekado>that’s because the derivation hasn’t been built yet. <wigust>ACTION thought that derivations contains all the info to build itself <ng0>uhuh. we have software that requires 8+ GB RAM for its testsuite? xyce-parallel just gave me virtual memory exhausted: Cannot allocate memory <ng0>or maybe it was because the computer froze while I walked out for some minutes <efraim>Is it mongodb that wants like 25? <ng0>I think at this point I should try to run cuirass instead of my one-liner. getting stuck on test suites sucks. <efraim>Last time I tried I couldn't get it to run, not sure if it was aarch64 specific or non-GuixSD <ng0>my problem is I have x86_64 guix master + my own changes on top + some 60 or so packages in 2 of my repositories <ng0>guix package -A picks them all up. haven't had the time to look into the cuirass that much <ng0>shouldn't be too difficult. <CharlieBrown>I just realized something. It might be illegal to say "I'll help you install proprietary software on your system... for the low, low price of $5,000! huehuehue" <efraim>oooh cached build failures are nice, skipping a bunch of builds now <dustyweb>> Are you an underrepresented person in tech? Does "functional package management" sound like an intriguing? Always wanted to write some lisp but never got a chance? Submit your proposal today! <dustyweb>thinking of submitting that to the Guile social networks <dustyweb>oops, remove the "an" before "intriguing" <civodul>and thanks for taking care of this, rekado :-) <lfam>But it would be nice if existing packages didn't need to be changed to support that. I think that having multiple import-paths in one package will be relatively unusual <lfam>Is there a convention in Scheme for taking an argument that is either a list or an atom? <lfam>Or, is this just the wrong approach? <civodul>it's usually better to have one accepted type <civodul>but it's ok to expect both types (list or string) <civodul>in the implementation you can write: (let ((import-path (if (string? import-path) (list import-path) import-path))) ...) <slyfox>civodul: hia! by the way, i've fould out why guix-0.14 does not compile for me. if you are interested i can tell a horror story :) <lfam>Thanks for the advice civodul! I'm still thinking of the best way to handle Go libraries... <civodul>slyfox: i'm only interested in horror stories where Guix is the main actor :-) <slyfox>do you know how guile decides if it should use already compiled .go file or new .scm file? Is it exactly what has newest file timestamp or anything else? <slyfox>basically the issue was: i had guix-0.13 installed in system and it was installed after 0.14 was out. As a result I had fresh /usr/lib64/guile/2.2/site-ccache/guix/modules.go <slyfox>when guix-0.14 was unpacked on disk tar carefully preserved timestamps for local 'guix/modules.scm' to be older than .go file <slyfox>as a result every time when I was compiling guix-0.14 nothing good came out <slyfox>i've noticed guix has it's own compilation code thus i'm not sure what does the timestamp checking: guilx build system or guile's <rekado>dustyweb: please note that our application to participate in outreachy is still pending review, so my email is only about getting *current* contributors to Guix to consider volunteering as mentors. Only after the Outreachy organizers have finished their evaluation of our community can we advertise our participation and invite prospective interns. <rekado>I probably should have made that clearer. <dustyweb>nah, my bad... I should have probably read more judiciously ;) <dustyweb>ACTION was just saying in another channel, "I'm not volunteering to do *any* gsoc / outreachy mentoring this year" <dustyweb>I think I'd co-mentor a GuixOps thing with davexunit if I could convince them to co-mentor with me ;)