IRC channel logs


back to list of logs

<iyzsong>mark_weaver: oh, thanks for revert it!
<mark_weaver>iyzsong: np, thank you for gnome-updates! I'm very much looking forward to it :)
<lfam>mark_weaver: I'm working on the openldap graft. When I create a replacement with a different version, it creates a different output path in the store, and then building an openldap dependent package (like curl) fails. Instead, I've given the replacement package the old version, and put the new version in the source URI "by hand". That works but it's an ugly solution.
<lfam>What I mean by "different" output path is that the name-version part of the path is different. Of course the hash is different
<lfam>I'll probably file a bug report for what happens when the graft fails. It's very noisy and it leaves an incomplete store directory in the store (and I think a reference is also left in the database)
<lfam>Actually, I can send you the failing version of the patch, if you like
<mark_weaver>yes, please
<lfam>mark_weaver: Sent
<lfam>And I've sent the (possibly) working version to guix-devel
<mark_weaver>lfam: openldap-fixed needs (replacement #f)
<lfam>ACTION D'oh
<mark_weaver>but also, you cannot change the version number
<mark_weaver>currently, the only part of a store filename that is permitted to change in a graft is the hash part.
<lfam>Yes, I read the code that checks for string equality
<mark_weaver>we could in theory loosen this restriction, but we'd certainly need to preserve the length
<lfam>So, in a case like this, do you think it's acceptable to put the desired version in the URI?
<mark_weaver>here's how civodul does it: caeadfddb01d2cda19d2f761ba9906ef8f162173
<mark_weaver>your own commit d8173f21f7b4e3cb83541b8fa70621d2b6d4ce1c uses the same approach
<mark_weaver>note the 'let' within the 'source'
<mark_weaver>so, the 'name' and 'version' fields of the package object are left unchanged, and the 'let' binds local variables used only for the URI computation
<lfam>Right, the scope is restricted so that the output path is correct, but the correct version can still be used to build the URI?
<lfam>Typing at the same time ;)
<lfam>Okay, I'll rewrite and resubmit
<lfam>Hm, there's another problem with my patch (the third URI is truncated for some reason)
<mark_weaver>lfam: regarding the corrupted store directory that had only a few empty files: iirc, that can happen with ext3 and ext4 filesystems (with typical mount options) if the system crashes soon after the directory is populated
<mark_weaver>did your system crash shortly after building curl?
<lfam>mark_weaver: No, the system seemed unaffected. But, my $TMPDIR is on btrfs, while my store is on ext4.
<mark_weaver>lfam: your latest openldap patch looks good to me, except that the new variable name is wrong in the commit log.
<lfam>Argh! Thanks for your attention
<lfam>mark_weaver: Okay to apply with a fixed commit log? And how about a "regular" update on security-updates?
<mark_weaver>lfam: okay to push if it's at least minimally tested
<mark_weaver>I'm not sure whether it's worth building a security-updates branch before core-updates
***lyk_ is now known as lyk
<micxjo>is there a command to delete old system generations (similar to guix package -d)?
<lfam>mark_weaver: Regarding updating openldap without a graft, I don't have an opinion about what branch it goes on. But it would be convenient for me to put the commit somewhere that will eventually be merged into master.
<iyzsong>when try package gspell, some tests fails. then it turn out that the code to list aspell dicts in enchat doesn't use ASPELL_CONF at all, so gspell can't find any dicts..
<jmd>Using a scheme expression, how can I get a list of all packages?
***Guest68430 is now known as vimuser
***vimuser is now known as mevirus
***mevirus is now known as Guest24122
***Guest24122 is now known as vimuser
***vimuser is now known as Guest75935
***Guest75935 is now known as sanctuary
***sanctuary is now known as vimuser
***vimuser is now known as mevirus
<htgoebel>jmd: AFAIR in one of the talk at FOSDEM there was an example for this. In the area where it comes to the benefits of guile instead of a own DSL.
<df_>I think the easiest way to do it with the exported interface is (fold-packages cons '())
<df_>there are also various find- methods in (gnu packages)
<robsyme>Hi all. I've got a question about `guix environment -l package.scm` - specifically about what package.scm needs to contain. I'd like to build a small ruby project that requires the httparty gem. I've got a package.scm file that describes both a package for the httparty gem and a package for httparty's dependency ruby-json: When I run `guix environment
<robsyme> -l package.json` and try to run `irb -rhttparty`, the gem is not installed. Any pointers would be greatly appreciated.
<civodul>Hello Guix!
<ADFENO>Hi civodul :D
<ADFENO>Hi koosha :D
<koosha>For perceiving more guix , I have to learn Guile or Scheme ?
<koosha>Hi everyone :)
<civodul>koosha: not necessarily, depends on what you want to achieve
<civodul>i'd recommend browsing the manual to get an idea
<koosha>I really like guix but I have seen that in many parts of the manual it points to Scheme language
<jmd>Thats why we like it!
<koosha>What do you mean of that ? :)
<koosha>* What do you mean of "that" ?
<jmd>Well at least that is one of the reasons we like it.
<jmd>It uses a high level yet expressive language which makes it hackable.
<koosha>Guile or Scheme ?
<koosha>jmd : (Are you German ? )
<koosha>jmd : Okay . So ,Guile or Scheme ?
<jmd>Scheme is the language. Guile one particular implementation of the language.
<jmd>From scheme, how can I get a list of all packages ?
<civodul>jmd: (use-modules (gnu packages)) (fold-packages cons '())
<civodul>see also the example at
<robsyme>Ah, I see what I was doing wrong. I needed to specify another package (for my project) that loaded the httparty gem as an input. Silly me.
<robsyme>Actually, no. That didn't work.
<jmd>civodul: in that example, In procedure module-lookup: Unbound variable: package-name
<davexunit>robsyme: here's an example of such a file:
<jmd>How can I add an extra path to what pre-inst-env sets?
<davexunit>use another wrapper script, or modify pre-inst-env directly
<davexunit>pre-inst-env shouldn't clobber any environment variables
<robsyme>davexunit: Thanks! Having a look now (P.S. I was just watching your LibrePlanet talk while I was waiting!
<robsyme>davexunit: (great talk, btw).
<davexunit>robsyme: thanks!
<jmd>I thought that GUILE_LOAD_COMPILED_PATH should do that job. But it still complains "no code for module"
<robsyme>davexunit: If I have (source #f) because I just want to build an dev environment, does the value of (build-system) matter?
<davexunit>robsyme: yes
<davexunit>because the build-system influences the inputs
<robsyme>davexunit: Aha.
<jmd>and if I try running ./pre-inst-env on top of an already set-up environment, I get "libgcrypt", message: "file not found"
<davexunit>for a ruby project, you would want ruby-build-system
<robsyme>davexunit: Aaaaaaah!
<davexunit>that implicitly provides all the necessities for building ruby software
<jmd>(although libgcrypt is certainly in the path)
<davexunit>jmd: pre-inst-env doesn't clobber the existing search paths
<davexunit>so I think your problem lies elsewhere
<jmd>That's why I don't understand why it doesn't work under ./pre-inst-env but does without.
<jmd>I think its because guix treats libgcrypt specially. But I fear that uninstalling it will break lots of things.
<jmd>(or both)
<koosha>I have a question but not about guix . It's almost about free software . Can I ask ?
<jmd>koosha: You can try. But it might be more on topic at #fsf
<koosha>Thank you for the channel
<robsyme>I'm clearly missing some conceptual piece in `guix environment`. Am I right in thinking that this scheme code should provide an environment with the httparty gem installed?
<davexunit>robsyme: no
<davexunit>the result of evaluating this file is the "ruby-httparty" package object
<davexunit>because it is the last expression
<davexunit>so using 'guix environment -l' on that file will create an environment in which all of the dependencies for ruby-httparty are available.
<davexunit>so this is less of a misunderstanding of 'guix environment' and more of a misunderstanding of Guile.
<robsyme>davexunit: Aha, so you get the result of the last expression?
<davexunit>guile can evaluate files from disk with the 'load' procedure
<davexunit>the return value of 'load' is the result of the last expression in that file
<davexunit>robsyme: right.
<davexunit>the package expression for "robsyme-test" does nothing
<davexunit>it is evaluated, which produces a package object, but it promptly thrown away.
<robsyme>davexunit: If I switch them around, I get 'Unbound variable: ruby-httparty', so I need to assign the previous package to a variable?
<davexunit>robsyme: yes, exactly.
<davexunit>'package' is a constructor procedure for packages
<davexunit>just like how (+ 1 2 3) wouldn't assign to a variable, neither does (package ...)
<davexunit>and of course, you can name your variable whatever you'd like.
<davexunit>the code you currently have expects a variable named ruby-httparty to exist.
<robsyme>davexunit: ... as long as it matches (("ruby-httparty" ,matchesThis)) right?
<davexunit>right, you need to refer to that variable, whatever its name is
<slim404>davexunit: hi
<robsyme>davexunit: Thanks so much for the Guile tip.s
<slim404>davexunit: since you are giving beginner questions I thought maybe you could explain to me how the #:key construct works
<slim404>davexunit: i mean you ar giving beginner lessons :)
<davexunit>slim404: see
<slim404>davexunit: I'm trying to configure my display manager using guix system configure
<slim404>davexunit: and I stumbled on (xorg-configuration-file #:extra-config)
<slim404>davexunit: I can't get the syntax right
<davexunit>right, that exists. I've never used it.
<davexunit>well, you need a value after #:extra-config
<davexunit>the syntax is #:key value
<slim404>davexunit: doc says "extra-config is a list of strings or objects appended to the text-file* argument list. It is used to pass extra text to be added verbatim to the configuration file"
<slim404>when I pass a string as an argument such as xorg-configuration-file
<slim404> #:extra-config "\\"Option\\" \\"XkbLayout\\" \\"fr\\"")
<davexunit>slim404: the documentation says "list of strings or objects"
<davexunit>you cannot pass a single string
<slim404>davexunit: so I tried (text-file* "\\"Option\\" \\"XkbLayout\\" \\"fr\\"")
<davexunit>and you cannot pass multiple strings and expect it to magically become a list
<davexunit>slim404: that's also not a list
<slim404>davexunit: I have to use cons
<davexunit>#:extra-config '("Option XkbLayout fr\\n") is probably what you want
<davexunit>passing in a list of three strings like that will result in them being concatenated
<davexunit>that wouldn't be correct xorg configuration
<slim404>davexunit: so '("Option XkbLayout fr\\n") is a list of one element?
<davexunit>it's a quoted list containing a single string
<slim404>davexunit: and when it says "objects appended to the text-file* argument list"
<slim404>what does it mean
<davexunit>(list "Option XkbLayout fr\\n") is another valid representation
<davexunit>slim404: that the list passed in via #:extra-config is added to the argument list of the call to the 'text-file*' procedure when building the xorg configuration file.
<slim404>davexunit: thanks for your help. it seems to work :)
<slim404>davexunit: do you have any suggestions on how to get quickly into guile? a book, a tutorial,..
<slim404>davexunit: or into scheme
<cbaines>I've just tried installing Guix in a VM using Gnome Boxes, but it does not like loading the installation image, any ideas? (I'm trying to use the 0.10.0 image, and have verified the signature)
<ajgrf>slim404: i just recently used the guile reference manual and tyscheme ( for that purpose
<slim404>ajgrf: thank you
<ajgrf>slim404: also, there is some really incredible technical literature that uses scheme, once you no longer feel the need for tutorial-style documentation
<ajgrf>sussman's sicp being the most obvious one
<slim404>ajgrf: I've read some of sicp multiple times :P so I feel like I know scheme, it's just that I feel I still can't parse it. I'm stuck with my non-LISP programming language paradigms
<ADFENO>Hi, does anyone know a tutorial about Guile that is, at least, legally shareable?
<robsyme>davexunit: `guix environment -l package.scm` works perfectly! Thanks again.
<ajgrf>slim404: i know what you mean. sicp was actually my first exposure to programming back in my freshman year of college, but it didn't really help me understand guix's code base
<cbaines>I tried loading the 0.9.0 image also, but that didn't work either. Are the images expected to work like this?
<slim404>ajgrf: I feel I "just" need 2 or 3 years of experience uploaded in my memory
<davexunit>cbaines: the disk image isn't an ISO, if that's what you're asking.
<davexunit>it's a raw disk image.
<cbaines>I'm not sure of the difference between the two, but I guess there is one?
<cbaines>Are iso's available for installing guix, or can I make one?
<davexunit>no ISOs at this time.
<davexunit>making one is non-trivial
<davexunit>people have had good luck converting to qcow2 or something
<davexunit>I've never used gnome boxes
<davexunit>so I can't help further
<cbaines>I was actually going to try creating a server running Guix (with Bytemark), but that requires an ISO (as it loads as a cd)
<cbaines>I'm just a bit too used to the Debian images, that work whatever you do with them
<davexunit>someone would need to write the necessary code to produce something in ISO format
<davexunit>there are complications, IIRC.
<efraim>could you start with a minimal install in a qcow format and convert it into an ISO?
<davexunit>efraim: maybe!
<efraim>or start with a foreign distro and `guix system init /` on top of it?
<davexunit>I have literally no idea how that works
<efraim>qemu doesn't seem to have an image-convert command
<efraim>i know virtualbox has something, but there should be another program that can also convert image files
<cbaines>Another problem I would appreciate some advice on is changing keyboard layout in Gnome
<ng0>cbaines: afaik that is done via system config file of guix
<df_>efraim: qemu-img?
<mark_weaver>ng0: I don't think so
<cbaines>I have the localle set correctly
<cbaines>and I have the console-keymap-service set correctly
<df_>I don't know what formats it supports
<ng0>sorry i jumped in, only responded to the one line
<cbaines>(or at least, the keyboard layout is correct in the console)
<ng0>ACTION afk again reassembling things
<mark_weaver>cbaines: you've looked in the gnome settings "region and language" panel?
<koosha>What source do you suggest for Scheme learning ?
<mark_weaver>I confess I don't know how this works in gnome, except that I strongly expect it is per-user in gnome
<cbaines>mark_weaver, I did, but I obviously did not spot how to make it work
<cbaines>there was no imput source, and I could not work out how to add one, but it just involved clicking some more
<cbaines>I have it sorted now :)
<mark_weaver>cbaines: are you trying to do some custom keymapping, or a common layout for your locale?
<mark_weaver>ah, good!
<mark_weaver>nevermind my last question then :)
<cbaines>I just needed to move from what I assume was English (US) to English (UK)
<mark_weaver>it would be nice if gnome, by default, chose a keyboard layout based on the default system locale in the OS config
<efraim>koosha: I've heard of but haven't tried it out
<koosha>efraim : Thank you
<koosha>Isn't there any official document for Scheme ?
<mark_weaver>koosha: there are some relevant Scheme standards, but in some ways it's more useful to think of Scheme as a family of languages. there are a great many implementations, each implementing their own dialect
<mark_weaver>and in the Scheme world, the situation is made a bit more complicated by a split that occurred in the standards process. R6RS and R7RS are two competing standards, both based on R5RS
<mark_weaver>koosha: if you want pointers to learn more Scheme or Guile, it would be helpful to know what kind of programs you wish to learn how to write
<koosha>Right , Thanks
<koosha>But , why Scheme ? Why gnu choosed it ? Why not python or something else ?
<koosha>I just want learn Scheme because of guix
<davexunit>Python lacks many features that Scheme provides
<davexunit>and doesn't support purely functional programming very well
<koosha>Which features ?
<mark_weaver>I don't have time for this conversation, sorry.
<davexunit>yeah I don't have a lot of time to dedicate to this.
<davexunit>but to be brief: s-expressions are a key component of Scheme that allow us to specify build scripts as Scheme code in package recipes.
<koosha>Okay , thank you all of you
<mark_weaver>I'll just briefly say that scheme allows you to build up languages that are most suitable to the problem at hand, and to use a great variety of programming styles, even ones that haven't yet been invented.
<mark_weaver>and the book "The Reasoned Scheme", shows an example of the kind of radically different language that can be very easily built on and integrated with Scheme.
<mark_weaver>"The Reasoned Schemer" (missed the last "r")
<mark_weaver>whereas python, like most other languages, are specifically optimized for a particular style of programming
<mark_weaver>and python in particular was intentionally designed to minimize the amount of variation in the ways that programmers tend to write python code
<mark_weaver>which has its benefit: it means more uniformity in coding style, so it is easier for people to read each other's code, and so mediocre programmers are accommodated more easily
<mark_weaver>whereas in the lisp world we have vastly greater diversity in programming styles, and many different dialects, which has its pros and cons.
<mark_weaver>richard stallman prefers the lisp world, and so do I
<df_>heh... it has its cons
<mark_weaver>it certainly does
<Acou_Bass>there seems to be certain sort of things that most lisp guys follow, not because lisp forces them to but just because we learn from other people and good ideas stick
<Acou_Bass>like, a lot of the time, i can read other people's lisp code because they all tend to lay it out vaguely similarly
<Acou_Bass>except me, because most of mine is from when i first started and looks like a dog ate it
<jmd>Something is odd with fold-packages. It seems to disable the terminal.
<davexunit>that can't possibly be the case.
<jmd>davexunit: Try this:
<jmd>And then try again uncommenting the call to put-name-in-window
<jmd>I wish could be used from eww mode
<davexunit>jmd: I can't try the code right now, but I see one major problem right away.
<davexunit>you are performing side-effects during package-fold
<jmd>Why should that be a problem?
<davexunit>because a fold isn't for side-effects
<davexunit>it's for accumulating a value
<davexunit>this isn't related to whatever problem you insist fold-packages is doing, but I'm pretty sure the problem is with your use of ncurses
<jmd>So ok the order will be undetermined.
<davexunit>no, that's not the problem.
<davexunit>or not the most important problem
<mark_weaver>davexunit: what is the problem exactly?
<davexunit>there's 2 problems:
<davexunit>1) jmd is using fold-packages improperly
<davexunit>2) something in the guile-ncurses is causing some terminal problem which I don't understand
<mark_weaver>I'm not sure that there's any prohibition in the use of side effects within fold
<jmd>Looking at the comment at the top of fold-packages I don't see anything improper about the way I'm using it.
<davexunit>there's not, but it's not good form and explain why jmd is insisting that fold-packages is broken.
<mark_weaver>fold has no freedom in the order in which the procedures are applied anyway, because of the nature of the data flow
<davexunit>when in fact it's the procedure given to fold-packages that is broken
<jmd> "Call (PROC PACKAGE RESULT) for each available package, using INIT as
<jmd>the initial value of RESULT. It is guaranteed to never traverse the
<jmd>same package twice."
<davexunit>"It seems to disable the terminal." is certainly not a fold-packages problem. it does *nothing* to interact with the outside UNIX world.
<mark_weaver>of course, I prefer to avoid side effects in my code, but I don't think jmd has broken any contract that I'm aware of
<davexunit>okay, nevermind the style issue then.
<davexunit>the problem of blaming the wrong part remains.
<mark_weaver>jmd: it's possible that 'fold-packages' might produce console output
<mark_weaver>but I guess that wouldn't explain what you're seeing
<davexunit>what would be better anyway is to use fold-packages to build a list of all packages
<davexunit>and then use for-each to render with ncurses
<jmd>I wanted to avoid doing that. The list could be huge.
<mark_weaver>jmd: what do you mean by "disable the terminal". what exactly are you seeing? can you run it within strace and search the syscall log for ideas of what might cause the problem?
<davexunit>jmd: so?
<davexunit>sounds like a premature optimization
<mark_weaver>jmd: forcing curses to refresh on every package will also be bad if the list is huge, no?
<jmd>mark_weaver: You're right. That was a late attempt to fix the problem.
<mark_weaver>its on the order of thousands of packages, which is reasonable list size. and then you could handle the incremental output more efficiently
<jmd>My idea was to use fold-packages to populate the visible part of the window. The window will be hundreds of entries long at the most.
<mark_weaver>anyway, to investigate further, we need to understand what "disabling the terminal" means.
<jmd>mark_weaver: It means I see a blank screen.
<jmd>Yet exactly what I would expect to see, if I call my lamba myself.
<mark_weaver>jmd: does the 'fold-packages' call finish?
<jmd>The program runs without error. It just doesn't show anything.
<cbaines>(wrong terminal...)
<cbaines>I'm using Guix on two machines, one Debian, and one GuixSD. I have installed emacs and notmuch on both, but on Debian, I am missing the symlinks to the store from .guix-profile/share/emacs/site-lisp/
<cbaines>any idea why they just are not there?
<mark_weaver>jmd: 'fold-packages' loads all scheme modules in certain directories, to try to find all packages. this includes GUIX_PACKAGE_PATH. my first guess at the moment is that one of those modules, when loaded, does something that messes up curses
<mark_weaver>maybe it changes the buffering on stdout, or something
<mark_weaver>but I'm sorry, I don't have time to go further on this right now.
<cbaines>ah interesting, on Debian .guix-profile/share/emacs is a symlink to the store, whereas on GuixSD, it is not
<mark_weaver>jmd: I would try experimenting with things like the order in which things are done. you could try building a list of packages with 'fold-packages' *before* initializing curses and displaying, and see if that changes anything.
<jmd>mark_weaver: Yes. That works.
<jmd>But I wanted to avoid doing that.
<mark_weaver>cbaines: the profile generator makes the links as high up in the tree as possible, so if the 'share' directory contains files from only one package, then 'share' will be the symlink instead of share/emacs
<mark_weaver>jmd: do you have GUIX_PACKAGE_PATH set? what is in that directory?
<jmd>No. It is unset.
<cbaines>mark_weaver, that would explain it
<cbaines>I guess the question then comes, why is the profile generator not installing the emacs related files in the notmuch package in to my profile...?
<jmd>mark_weaver: Yes. It seems that if fold-packages is called before any ncurses procedures then everything is fine.
<jmd>However if it is called after ncurses is initialized, bad things happen.
<mark_weaver>jmd: that suggests that one of the modules loaded by fold-packages is changing some state that curses depends on
<jmd>That's what it looks like.
<mark_weaver>you could try determining the set of modules loaded during 'fold-packages', perhaps using strace and seeing the files being opened.
<mark_weaver>and then you could write your own loop that loads all those modules after initializing curses, to see if the same problem occurs
<jmd>I'm not sure how to do an explicit module load.
<mark_weaver>and if so, then you could use binary search, loading only some of the files, and thereby find the culprit
<mark_weaver>the 'load' procedure will do it
<mark_weaver>jmd: actually, it would be simpler to just use the code that already exists in gnu/packages.scm
<mark_weaver>see 'fold-packages' in there, which uses 'all-package-modules'
<jmd>So long as I'm sure which path is the one being used.
<mark_weaver>'package-modules' is where the modules are loaded, using 'resolve-module'
<mark_weaver>sorry, 'resolve-interface'
<mark_weaver>jmd: as an easy hack, you could insert some debugging code before and after the 'resolve-interface' call in 'package-modules', that tries to update the curses display
<mark_weaver>and thereby determine which module was being loaded when curses stops working.
<lfam>mark_weaver: I rebuilt curl and libreoffice against the replacement openldap, and they both seem to work. But, I don't have any LDAP infrastructure to test against. Do you think that's an acceptable test of the replacement?
<mark_weaver>lfam: yes, that's fine. go ahead and push. thank you!
<lfam>I also built gnupg, wine, and samba. Gnupg also seems to work. I don't have any way to test wine or samba
<lfam>Okay, commit on the way!
<paroneayea>time to package 8sync for guix :)
<mark_weaver>sounds good!
<lfam>There are so many python packages waiting for review on the list... :o
<lfam>Also that PyPi API change...
<jmd>What does "Unbound variable: GOOF----LE-8-2.0" indicate?
<mark_weaver>maybe that you're trying to 'load' a .go file
<mark_weaver>load is called on the .scm
<mark_weaver>but anyway, you should see my more recent suggestion above for how to debug this. much easier and more reliable
<jmd>I'm not sure that it'll be easier. I'd have to set up a lot of global variables somehow.
<mark_weaver>hmm, yeah, I guess it might not be
<mark_weaver>well, it's your call..
<cbaines>For some reason guix package -l shows that I am on generation 15, but my user profile is linked to guix-profile-9-link... on GuixSD, these numbers match?
<mark_weaver>ACTION goes afk for a bit
<cbaines>Sorted, turns out I had stuff in /var/guix and /usr/local/var/guix (I guess I must have recompiled guix at some point with different settings)
<lfam>Ah, the notorious --localstatedir=
<lfam>What is the best way to determine the version of the Python interpreter at build time? I'd rather not use the method shown here:
<jmd>So far as I can make out, there is no one particular module which upsets ncurses. It is just the sheer quantity of them which get loaded.
<mark_weaver>that doesn't sound sensible to me
<jmd>Neither to me.
<jmd>But the only thing which seems consistent is that the more modules loaded, the high the probability of failure.
<civodul>hey, mark_weaver
<mark_weaver>jmd: it might be that the modules being loaded are not the problem, but rather some module elsewhere that is imported by many of our package modules
<civodul>mark_weaver: what should we do about gnome-updates?
<mark_weaver>hi civodul!
<civodul>ACTION would like to start a core-updates evaluation
<mark_weaver>civodul: I just created a new evaluation of gnome-updates on hydra
<mark_weaver>it finished very recently. just started building it
<civodul>ah ok
<civodul>was it broken or something?
<mark_weaver>although it's not much different than evaluation 108920 on 'master'
<mark_weaver>civodul: it was merged prematurely. there were several broken packages that needed to be fixed before it would be possible to update to it, and meanwhile it was blocking some possibly security-relevant updates to linux-libre and webkitgtk
<mark_weaver>effectively blocking users from getting those updates in a timely fashion.
<civodul>oh i see
<civodul>the broken packages have been fixed in the meantime?
<civodul>ACTION catches up :-)
<mark_weaver>some of them have been fixed, others remain
<mark_weaver>civodul: also, hydra was out of disk space and needed GC, which I did last night
<mark_weaver>reverting the merge allowed us to do GC while 'master' was in a good state
<civodul>oh, ok
<civodul>good that you noticed!
<jmd>Anyway. One thing is for sure. guix and gnome-ncurses don't play nicely together.
<civodul>in what sense?
<mark_weaver>civodul: one of the problems that was worked-around in a hurry, before I reverted the 'gnome-updates' merge, was a failing test in gjs.
<mark_weaver>that commit simply disables the failing test, but I think the failed test might indicate a real problem that should be investigated more properly
<mark_weaver>civodul: jmd has found that if 'fold-patches' is used after initializing 'curses', for some reason curses stops working.
<civodul>oh, not good
<mark_weaver>civodul: it seems that when the modules are loaded, something happens that breaks curses
<civodul>jmd: could you paste an example that does that?
<mark_weaver>if 'fold-packages' is done before initializing curses, it everything works find.
<jmd>I did earlier.
<mark_weaver>civodul: earlier, jmd pasted this:
<jmd>and uncomment the call to put-name-in-window
<janneke>ACTION almost has a new mingw patch set ready; starts one more round of building ~90 packages
<civodul>mark_weaver: here jmd's examples displays two boxes "as expected", no?
<koz_>I'm getting a weird message from 'guix pull': substitute: error: executing `/usr/libexec/guix/substitute': No such file or directory
<koz_>Could someone please fill me in on what on earth I missed?
<civodul>does that file exist?