<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>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)
<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
<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.
<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
<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?
<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
<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
<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?
<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
<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.