IRC channel logs

2021-03-25.log

back to list of logs

<civodul>yup :-)
*civodul -> zZz
<civodul>night!
<lle-bout>good night civodul!!
<lle-bout>jlicht: want access to the powerful server for GNU Guix dev?
<genr8_>how come sometimes ./configure stages seem to run single threaded, one line taking 1 second at a time, while other ones seem to blast through it at hundreds of lines per second ?
<genr8_>they all seem to be the same kind of "check for header, check for a function, check for a define" kind of tests
<lfam>They all work in the same way, and it's always single-threaded
<lfam>The tests may be fast or slow, depending on what they are testing
<lfam>And the rest of the difference will depend on I/O speed, I'd guess
<genr8_>i guess. but it doesnt seem to actually add up to what i see in reality
<lfam>For example, if everything being tested is in the page cache, it will be fast. If everything has to be fetched from disk, it will be slow.
<lfam>Things like that
<lfam>There are also different versions of configure, maybe some of them have some speed-ups
<lfam>In general, configure being slow and single-threaded is widely acknowledged and a primary motivator for the development of some other build systems
<genr8_>now that makes more sense. the slower ones were happening more often during the early bootstrap phases
<lfam>It's likely that your VM needed to page things in, assuming you're still starting from scratch every time
<lfam>I doubt there are significant speed differences in the configure scripts themselves (they are shell scripts)
<genr8_>it was like a 100x speed difference. enough to be concerning.
<lfam>That's the kind of benefit the page cache will give
<lfam>There's a nice graphic somewhere that illustrates the difference in data fetching speeds from different parts of the computer. Basically, each level closer to the CPU is an order of magnitude difference in speed
<lfam> https://gist.github.com/jboner/2841832
<lfam>It's 10 years old, and the calculation has changed with ultra-fast persistent flash storage
<lfam>./configure is the kind of thing that really exercises this
<genr8_>ok but i dont think thats it.
<lfam>Okay
<genr8_>moving on, i would like to report something else
<genr8_> /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/include/features.h:397:4: warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp] <--- now i'm getting this during a build of /gnu/store/2l8f4sjw0jbfll4ilp7pzwimrh5kjdgf-swig-4.0.1/
<genr8_>doesnt that seem like a significant oversight ?
<lfam>Most significant C and C++ codebases compile with a large number of warnings
<lfam>I would report it upstream if you are worried about it
<genr8_>that warning is not one to be ignored
<genr8_>I would assume its a build setting, not upstreams fault
<lfam>Right, but it's how Swig has written their build scripts
<lfam>Why would you assume that?
<lle-bout>genr8_: we are not at that level in GNU Guix where we can afford paying attention to details like that, it will come when packages in GNU Guix will have matured more and GNU Guix will have matured more in general, also more contributors.
<lfam>In general, in Guix we run the build scripts that upstream distributes
<lle-bout>genr8_: we may start studying enabling hardening compiler options at some point but not done yet
<genr8_>ok
<lfam>I would say, it's extremely typical to see warnings like that
<lfam>Especially for old-school things like SWIG
<lfam>In fact, these warnings have been brought to their attention previously: https://github.com/swig/swig/issues/997
<genr8_>ok maybe it is upstream then
<genr8_>one has to notice that he is also using a /gnu/store environment
<lfam>He is familiar around here
<genr8_>and the issue wasnt exactly related to the FORTIFY/optimization warning, it just happened to contain those words
<lfam>No, but the example was concise, and if they cared about that warning, they'd have acted
<lfam>If you google your error message, you'll see it elsewhere
<genr8_>lol, we both know thats not how things work
<genr8_>its a concern and people are discussing how to proceed
<lfam>Well, if it were me receiving a bug report that highlighted a violation of the Guix security model, I'd act. So, I know how things work around me
<lfam>Instead, I was the one sending the bug report. Go figure
<genr8_>ok. so you know.
<genr8_>i cant say for sure whether or not its a violation but it certainly seems better to bring it up than chuck the warning to /dev/null
<lfam>Sure, like I suggested, it should be reported upstream
<genr8_>ok
<genr8_>how do I find out why my system is trying to compile SWIG in the first place ? like what dependency pulled it in ?
<lfam>There is a tool `guix graph` that is helpful
<genr8_>oh, do i need graphviz ?
<lfam>For example, `guix graph --type=reverse-package swig` will output the graph of packages that depend on swig
<lfam>Yes, it outputs in graphviz format
<genr8_>ok
<lfam>Oh, it can also do d3 and something called cypher
<lfam>`guix graph --list-backends`
<lfam>Thousands of packages depend on swig, transitively, so the graph will be dense
<lle-bout>can I comment an offline mirror? what's the policy for that?
<lfam>You mean, from guix/download.scm?
<lle-bout>lfam: yes
<lfam>Can you tell if it's permanently offline?
<lfam>It shouldn't cause trouble if it's just temporary, but it depends on the details
<lle-bout>lfam: http://ftp.linux.org.uk/mirrors/ftp.gnome.org/
<lle-bout>been a while it's down for me, like at least a week
<lfam>Well, there's no policy. Just remove things that are gone and, once in a while, find some new ones to add
<lfam>It doesn't load for me either
<lfam>The main thing is to make it useful for most people, and not just for one self. Like yesterday somebody wanted to remove the primary GNU mirror because they were using some paid VPN that mis-advertised their location
<lfam>That's not a good reason
<lle-bout>okay then let's comment it out I guess, at least temporarily
<lfam>I would just remove it
<lle-bout>lfam: okay!
<lfam>Maybe send a message to guix-devel about it, so that other UK users can look for mirrors
*lfam afk again
<genr8_>i think "guix graph swig" without any options was more informative, at least it was readable. the reverse one was ridiculous
<lfam>`guix graph swig` shows what swig depends on, but that doesn't answer the question you had asked about
<genr8_>it kind of does
<genr8_>hmm i see what you're saying. theres got to be some better way then
<lfam>Sometimes it's enough to just see the first level of dependents
<lfam>guix package --search=. | recsel -e 'dependencies ~ "swig"' -p name,version,synopsis
<genr8_>nothing
<lfam>Anyways, I have to go afk. Good luck!
<genr8_>thanks
<genr8_>oh, recsel command was not found
<genr8_>need recutils
<genr8_>ok that worked. I think its coming from "subversion"
<marusich>lle-bout, thank you for updating the guix package. and yeah, lfam we couldn't do it during code review because it is awkward to do that on a branch that is going to be rebased frequently. I'm glad it's done now!
<lle-bout>marusich: hello :-) - I am updating my powerpc64le-linux machines with GNU Guix official master :-D
<lle-bout>OSUOSL one and my Debian VM
<marusich>I should probably have done it right after merging, but I wasn't sure what the policy was for updating the guix package (e.g., "does the release person want to do it just once before making a release?" I guess the answer is "no")
<lle-bout>Also for the security vuln in guix-daemon
<marusich>sweeet
<marusich>I need to do the same!
<lle-bout>marusich: next let's get some VM running with GNU Guix System on powerpc64le-linux so we can run services like Cuirass!
<marusich>I noticed tests/print.scm fails but it's unrelated to ppc
<marusich>not sure if it blocks guix pull, but i noticed it recently when rebasing onto master (the failure was present on master before rebasing)
<marusich>seems like a simple fix though
<lle-bout>guix pull has been working fine for me and test suite too so maybe it's your system that's a bit different triggering the failure
<marusich>lle-bout, yeah that's always possible, since I've been building guix manually on debian
<marusich>Gotta love that manual dependency management...
<lle-bout>cbaines: hey by the way my x86_64 VM that runs guix-build-coordinator-agent has been constantly busy for a while now, that's great!
<marusich>What's the process for adding an entry to news.scm? Do I just make a commit like f62633a527a7b54ab2c552b493dce382ab2365e6 in one language (english), and people will later maybe translate it into other languages...?
<lfam>The new Guix package failed to build on CI: https://ci.guix.gnu.org/build/117996/details
<lle-bout>lfam: o_O - guix pull succeeded etc. for me, I have my whole system reconfigured with it now in fact
<lfam>`guix pull` is not the same as the Guix package
<lfam>Did it build successfully for you locally?
<lfam>I'm retrying the build to see if it works
<lle-bout>lfam: seems it fails for me too, didnt know guix pull wasnt same, marusich you said it was an easy fix, what is it you think?
<genr8_>FAIL: tests/print.scm
<genr8_>There seems to be an asterisk where there shouldnt be: ctrl+F search for "(method url-fetch*)"
<lfam>marusich, lle-bout: Please hold off on the news entry
<lfam>I guess we need to adjust to f7008ca71351e5368a7c1c5bc3fe88fb80b01298
<lle-bout>lfam: don't we update the test?
<lfam>I don't know enough about this to say
<lfam>We don't want to just "fix tests", when there may be a real bug
<lle-bout>lfam: it seems the rename was intentional
<lfam>Yes, of course
<lfam>Alright, I am too tired to keep going for the night. It will be fixed! :)
<lfam>Good luck everybody
<lle-bout>Thanks good night
<genr8_>let me ask something. why would someone use "stable v1.2.0" if the first thing that happens is that guix pull just goes and grabs "latest" and updates all the internals of everything over top of itself again
<lle-bout>genr8_: tested install phase
<genr8_>so then that person, would never guix pull ?
<lle-bout>genr8_: they can, but the install phase will be tested and they are guaranteed to get something that works without guix pull
<lle-bout>we test things heavily on releases to make sure they work, otherwise things break and get fixed all the time
<lle-bout>the point of the rolling release model we have
<genr8_>im somewhat concerned about how far out of sync theyve gotten
<genr8_>its been 4 months now ?
<lle-bout>marusich: so I am not sure whether the test is faulty or.. the commit at f7008ca71351e5368a7c1c5bc3fe88fb80b01298, still figuring it out
<lle-bout>genr8_: you are warned to guix pull on the command line if you do anything with an out of date GNU Guix
<genr8_>right, and that is what has been messing me up, because it is so hard to actually build from master with outdated parts
<lle-bout>GNU Guix releases are mostly useful for GNU Guix System installer
<lle-bout>genr8_: what do you mean?
<genr8_>the main components are all out of date, and each one has hundreds of dependencies to build
<lle-bout>genr8_: you mean computational complexity of guix pull without substitutes from 1.2.0?
<genr8_>exactly
<lle-bout>genr8_: don't expect low computational complexity without substitutes
<lle-bout>no rolling release distro will give you that
<genr8_>i see. its extremely rough though. almost as if I need a seperate machine just to build guix, then transfer it over to not contaminate my main machine with a ton of build-deps
<lle-bout>genr8_: yes computational complexity of building requires build farms more or less
<genr8_>ok i have a related question
<genr8_>Can I obtain all of the logs from the build farm for such a process at once?
<lle-bout>I suggest you have some server you trust and share between several lower powered machines
<lle-bout>For building
<lle-bout>With e.g. GNU Guix offloading
<genr8_>yes it seems that way.
<lle-bout>It seems it could be a wrong import
<lle-bout>for the url-fetch issue
<lle-bout>genr8_: what do you mean exactly?
<lle-bout>download all logs for all evaluations of in a revision range?
<genr8_>I can only grab 1 log at a time
<genr8_>yes, all the logs in the complexity chain
<lle-bout>I don't think so, but I never needed this so wouldnt know
<lle-bout>you want to grep all the logs?
<genr8_>to have them, yes.
<genr8_>i assume the feature doesnt exist. but it could
<lle-bout>genr8_: there's also this: https://data.guix-patches.cbaines.net/ and https://builds.guix-patches.cbaines.net/ (normally last one isnt 403 but eh..)
<lle-bout>genr8_: we are in the process of adding more QA tools to GNU Guix, searching build logs massively could easily be one
<lle-bout>suggest that to guix-devel, it's a good idea
<genr8_>Ok. cool. I will try to rethink it as a complete concept
<lle-bout>genr8_: Guix Data Service and Cuirass, then there's guix-build-coordinator and friends by cbaines, Guix Data Service can integrate with guix-build-coordinator AIUI
<lle-bout>There's this one also: https://data.guix.gnu.org/
<genr8_>i will be interested in these things. im a new user and unfamiliar so i will have to investigate.
<genr8_>thanks
<roptat>genr8_, you can list the required derivations with guix graph and similar, then use that info to download corresponding logs, maybe?
<genr8_>right, but i just checked that, and the list is gigantic and i'm having a hard time even parsing it
<lle-bout>if the service supported HTTP2 then maybe it wouldnt be that much of a problem :-)
<lle-bout>roptat: do you know GNU Guix internals or Scheme well?
<roptat>lle-bout, depends on which parts, but I've touched some of them already
<roptat>heh, at some point I guess I'll try implementing http2 :p
<lle-bout>roptat: do you think such fix makes sense? https://paste.debian.net/plain/1190897 - for tests/print failure https://ci.guix.gnu.org/build/117996/log/raw - first bad commit: f7008ca71351e5368a7c1c5bc3fe88fb80b01298
<lle-bout>roptat: yay! http2! I am also thinking about it as soon as I know Scheme better
<roptat>right, not sure I'll work on that soon, and if I do, it might take a while to finish anyway :)
<lle-bout>we definitely need some well tied in asynchronous http2 impl
<roptat>lle-bout, no, (guix download) and (guix build download) really don't implement the same url-fetch
<roptat>I don't think you should replace the test that way, it's not how packages are expected to be defined
<roptat>I see that the problem seems to be that package->code uses the internal name of url-fetch (url-fetch*) instead of the exported name
<lle-bout>roptat: I submitted: https://issues.guix.gnu.org/47375
<lle-bout>package->code behaves as expected, no?
<roptat>so probably, it's an issue with package->code that we really have to fix, or say that url-fetch* is actually expected
<roptat>I don't know
<roptat>never seen that procedure before ^^'
<lle-bout>we'll wait for ludo I guess
<roptat>I'll send a reply, but I don't feel very competent on that one
<lle-bout>same
<roptat>ok, need to get some sleep now, see you soon!
<lle-bout>see you! good night!
<genr8_>(consider i know next to nothing) i would be careful. * sounds like a wildcard, and * on url-fetch sounds like it could invalidate some kind of "url must match exactly" security check
<lle-bout>genr8_: as far as I understand, wildcard in GNU Guile world more means like a function with increased functionality
<lle-bout>let vs let*
<genr8_>ok
<lle-bout>let lets you define one variable for a scope
<lle-bout>let* lets you define multiple for a scope
<lle-bout>but in this case, it seems it's only cosmetic
<lle-bout>To use another local name for url-fetch so some name does not clash
<lle-bout>To make autoload work, according to the commit message, but I don't know exactly what that is
<raghavgururajan>Anyone know what this error means?
<raghavgururajan>error: in phase 'bootstrap': uncaught exception:
<raghavgururajan>wrong-type-arg "car" "Wrong type argument in position 1 (expecting pair): ~S" (#f) (#f)
<lle-bout>raghavgururajan: hey, ohh that's the atkmm issue?
<raghavgururajan>lle-bout: Yep!!
<raghavgururajan>Btw, you got my DM? Just checking as I am messaging from XMPP.
<marusich>re: the breakage, lle-bout and lfam I think f7008ca71351e5368a7c1c5bc3fe88fb80b01298 may have broken it
<lle-bout>marusich: https://issues.guix.gnu.org/47375
<marusich>the failures: https://paste.debian.net/1190899/
<marusich>Need to go afk again, but it seems related to that commit, not sure why it would cause it though.
<genr8_> https://git.savannah.gnu.org/cgit/guix.git/commit/guix/download.scm?id=f7008ca71351e5368a7c1c5bc3fe88fb80b01298
<genr8_>yes, this is it.
<genr8_>theres some weird magic going on here with the local function overload reusing the same name, and the autoload
<marusich>Note that reverting the commit fixes it.
<marusich>The problem is probably (?) that (package->code pkg) incorrectly uses url-fetch*; it should be using url-fetch. So I guess the bad change altered this (so previously package->code wrote url-fetch, but now it's writing url-fetch*)
<marusich>I guess it's because, with the bad change, (origin-method source) in guix/import/print.scm procedure evaluates to the url-fetch* procedure (you can add a pk form like (pk (origin-method source)) to see this)
<marusich>presumably it ought to evaluate to url-fetch
<marusich>It invokes (procedure-name method) and gets url-fetch* because that is the name of the method. I wonder how you are supposed to get the "exported" name in the case where (as this change did) the function is exported under a different name?
<marusich>I've sent an email summarizing this; I think we should revert the change if we can, and hopefully Ludo will have some thoughts about how to fix it based on the info I've shared. I'm not sure how to solve it
<clacke>roptat> "[packages are] quite some work sometimes" lle-bout > "they are, but I feel like copyright is the wrong metric to define it, since most of the work is testing"
<clacke>ah, so patents then ;-D
<apteryx>raghavgururajan: still going through your patches! that bzrtpTest takes time
<marusich>lle-bout, I'll bet the reason why "guix pull" worked, even though "make check" doesn't, is because "guix pull" doesn't use the usual process for building Guix. It kind of reproduces the work, but in scheme (see: guix/self.scm).
<raghavgururajan>apteryx: Thanks so much for talking your time on this. Sorry, that I haven't replied to your emails yet, as I have been pre-occupied with gnome stuff.
<marusich>Time for sleep! Goodnight
<raghavgururajan>apteryx: FYI: Except bcunit, all other packages has to updated together, else their build fails.
<raghavgururajan>s/talking/taking
*raghavgururajan gonna burn the mid-night oil today, for gnome.
<genr8_>Is there an API list of everything exported out of the .scm files ?
<genr8_>some kind of doxygen type auto-documentation
***iyzsong-- is now known as iyzsong-w
<genr8_>linux-libre-headers-5.4.20 but linux-libre-5.9.3 - why ?
<cbaines>what's the context of your question genr8_?
<genr8_>why have the headers been left back ?
<cbaines>they haven't, the current revision of Guix I'm using has 8 different versions for the linux-libre-headers package
<genr8_>hmm
<cbaines>the latest being 5.11.7y
<cbaines>*5.11.7
<genr8_>ah I see, you're right, but - https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/linux.scm#n588 for 5.4.20 "The following package is used in the early bootstrap, and thus must be kept stable and with minimal build requirements."
<genr8_>its been like that since 2020-02-15
<genr8_>well, the message was there from before, but it was changed from 4.19.56 to 5.4.20
<genr8_>could it be time to do another change to 5.10 since its an LTS branch?
<cbaines>it's possibly just been a while since the version used has been changed, and since changing it means every package will change, it isn't something done lightly
<genr8_>i see
<genr8_>since you run the build logs server, do you know how to collect _ALL_ the logs from when such a massive rebuild is triggered ?
<cbaines>I don't run "the" build logs server, but I do operate a couple of build farms
<cbaines>I guess it would be possible to loop through all the relevant derivations, and look up the corresponding build logs
<genr8_>ok. i am wondering what can be done about bundling a collection of all the logs needed to build a complete GuixOS system
<cbaines>I'd suggest starting by getting a list of all the derivations involved, then looking up a build log for each derivation
<genr8_>ive started, but only to a depth of 1.
<genr8_>does the community have advance notice when such a "rebuild @world" will be triggered ?
<cbaines>to some extent, the current process is normally when core-updates is merged, that will normally affect most packages
<cbaines>and there's normally some coordination in the run up to that happening
<genr8_>i am going to concoct a plan to propose that the logs be bundled at such a milestone. its gonna be a couple gigs worth of logs i would think
<cbaines>for what purpose?
<genr8_>i think it would help to fulfill the transparency and auditing mission if the log for everything that goes into a running system is collected at once, instead of leaving it to me to pull one at a time.
<rekado>I don’t understand: why would you trust the logs when you don’t trust the build farm enough to use its binaries?
<genr8_>thats an oversimplification
<cbaines>hmm, in terms of substitutes, ci.guix.gnu.org can remove or change substitutes for outputs, so even if logs were provided, there's no guarrentee that they'll always correspond to the outputs
<genr8_>the logs would go a long way to trusting the binaries
<genr8_>hmmm
<genr8_>i didnt know that. i also don't exactly follow
<genr8_>I thought that if the hash value matched, then it was a guarantee
<cbaines>which hash?
<cbaines>or rather, which hash value?
<genr8_>the 32 char cryptographic hash in front of every /gnu/store package
<cbaines>in most cases, that hash represents the process used to create the output
<genr8_>yeah
<cbaines>while there is a push to make Guix things build reproducibly, it's not currently a requirement, at least one that's rigerously checked
<genr8_>ah
<abcdw>hi guix o/
<genr8_>\o
<efraim>lle-bout: I'm currently testing bumping gcc to 10 on core-updates, building to hello on aarch64 and to mesa on x86_64
<abcdw>`guix package -m manifest.scm` doesn't remove installed packages if I provide a manifest generated from empty list of packages. Is it a bug or feature?
<NieDzejkob>'guix download' fails with "X.509 certificate could not be verified". How can I debug this? wget works. $SSL_CERT_{DIR,FILE} are set.
<kcurtet>Hi guis, i'm installing an app with flatpak and the app can't start with the error net::ERR_CERT_AUTHORITY_INVALID
<kcurtet>it has something to do with nss-certs i know other people can use the app in guix without problems
<kcurtet>Sry its a question
<NieDzejkob>Hmm, what's the app? What does 'env | grep SSL' say?
<efraim>hmm, do you have SSL_CERT_DIR or SSL_CERT_FILE set?
<abr>hi
<kcurtet>No
<abr>how could I get some information about how/why GDM spawns an ibus-daemon process ? There's nothing in the documentation
<kcurtet>efraim: Yes I do, to some file in the store
<kcurtet>gnu/store/...3xxcw6gbcf4-profile/etc/ssl/certs
<kcurtet>>
<cups-help>Hi, guys!
<cups-help>I want add cups-service in my config.scm but I miss a use-module
<cups-help>How can I search the right module of (service cups-service-type)?
<abcdw>cups-help: guix system search cups
<cups-help>thanks
<cups-help>p.s. nice video!
<abcdw>cups-help: which one?
<cups-help>*p.s. nice videos!
<cups-help>On Youtube
<abcdw>cups-help: Thank you (:
<kcurtet>How i can find a solution for net::ERR_CERT_AUTHORITY_INVALID error in flatpak Discord
<kcurtet>flatpak uses nss-certs?
<abr>oh, so there *are* people who know something about this distro here and who can answer some questions
<abr>it's good to know
<nckx>Good morning, Guix.
<cbaines>hey nckx o/
<nckx>We know a few things about Guix, less about things specific to GNOME & Flatpak.
<nckx>Hi cbaines.
<jemarch>hi good peoples! :)
*nckx feels discriminated against.
<abr>nckx: ^^
<abr>I'm a bit distressed by the inclusion of «flashy things» like GNOME and such in Guix (which I'm definitely ignorant about) that «just work» except when they don't
<abr>because they are by construction very difficult to troubleshoot (to me)
<kcurtet>But my problem its with my config i think. I know other people using discord with flatpak in guix
<nckx>GNOME, IME, has never just worked and is rather notorious for it.
<jemarch>any cuirass developer around?
<nckx>In general, I mean.
<abr>so I expected you'd all be knowledgeable about them : )
<efraim>mesa FTBFS on core-updates with gcc-10, the llvm tests fail. Trying again now with gcc-9
<abr>well yes and no : I've never had any difficulties setting up input methods when I had to setup my desktop from scratch, but now I see there's an ibus spawning by itself and, not being able to trace where it comes from is very scary
<cbaines>jemarch, mothacehe has been working on Cuirass recently, but I don't think he's around currently
<jemarch>I was wondering whether we could use cuirass for GNU poke
<jemarch>it is a simple C program
<jemarch>and I am definitely too stupid to understand the CI systems out there, like the one in gitlab. They also require using web interfaces for everything
<cbaines>jemarch, even though the term "CI" is used around Cuirass, I'm not sure the use cases it's applicable to currently match up with GitLab's CI offering at least
<jemarch>that is actually good
<cbaines>Cuirass polls pre-configured branches and builds derivations, whereas I think GitLab can run arbitrary scripts
<jemarch>hm
<nckx>From what I've read so far it seems pretty clear that GNOME handles Ibus itself, not Guix. 2 of the top 3 workarounds in my search results, after ‘disable it in System Settings’ are ‘rename ibus-daemon to ibus-daemon.bak’ and ‘chmod -x ibus-daemon’.
<jemarch>can you define derivations in terms of, say, configure options?
<nckx>That says all that needs to be said.
<jemarch>like, --enable-this or --disable-that?
<nckx>I'm not sure what it says, but it's horrible.
<efraim>Isn't there an option to use a manifest file with cuirass? then we could create a manifest with a bunch of different poke packages with different configure options
<cbaines>jemarch, you could, but I'm not sure that information would elegantly show up in the web interface
<lle-bout>hello! :-D
<cbaines>o/
<jemarch>hmm
<jemarch>ok
<jemarch>cbaines: I will RTFM and see :)
<jemarch>thanks for the info!
<abr>nckx: : ) well that does sound horrible, especially since I didn't think I was running gnome (I installed XFCE, I guess it must come from the default GDM that handles login)
<abr>but it's at least a direction to start searching in, thank you !
<lle-bout>please review https://issues.guix.gnu.org/47231 (security)
<nckx>abr: Good luck! If you ever switch to Sway I'll be of more help 😉
<nckx>Shut up milkman.
<lle-bout>why are you swearing
<lle-bout>nckx: ^
<abr>awww ! I've been dreaming to make that switch for a long time but… yeah, hard time with the input method ^^ yeah
<nckx>I wasn't swearing? lle-bout: What's ‘wip’ about the fix?
<abr>I think it was about the milkman
<lle-bout>nckx: there's "Shut up milkman" messages being sent from you
<lle-bout>nckx: just need approval to push
<nckx>If that's swearing, you're in for a bad time when I actually do.
<nckx>I find milkman[bot]'s refusal to parse HTML correctly very annoying.
<lle-bout>I don't understand why you would say "shut up" to anyone nor I understand what is it doing here in context
<nckx>No one, what.
<nckx>The [bot] is a clue.
<nckx>All it does here is lurk and burp ‘Download’ whenever someone pastes an issue link.
<cbaines>... I don't see that
<abr>I don't either
<lle-bout>okay, I see nothing here, I don't like seeing words like "shut up" here very much that's all
<abr>does the bot posts messages visible only to admins or people with certain rights on the channel ?
<i1l>milkman[bot]: seen sneek?
<i1l>sneek: seen milkman?
<sneek>Sorry, no.
<i1l>milkman was scarred by "HOW TO UNZIP A GZIP FILE" last year.
<nckx>...huh.
<nckx>So none of you see an annoying spambot?
*nckx is too young to hear voices.
***ChanServ sets mode: +b milkman[bot]!*@*
***milkman[bot] was kicked by ChanServ (User is banned from this channel)
<abr>we're old enough that we can't hear them any more : )
<abr>poor milkman
<abr>I guess it'll be «no milk today»
<cbaines>nckx, no, just you when you mention it
<nckx>Well, sorry for the out-of-context being-driven-mad-by-a-bot. Had I known I'd have kicked it long ago.
<nckx>I don't call people ‘milkman’, no.
<cbaines>I'm not quite sure how that was affecting you though
<cbaines>I didn't think IRC was complicated enough to send messages to specific people in a channel
<nckx>I'm opped, which is the how, but I don't understand why. I didn't mute them.
<abr>yeah me neither it's an interesting discovery
<nckx>I don't like being opped, but there's a reason. Anyway. Sorry.
<nckx>I thought I was the only one finding it extremely rude & pointless. Which, in a way, I was.
<nckx>lle-bout: Your patch LGTM...
<lle-bout>maybe we can kick/ban that bot
<lle-bout>oh it was
<lle-bout>good
<nckx>Thanks, I did ☝
<lle-bout>nckx: good to know, can you post on the ML so I don't get accused of merging too fast again
<nckx>Will do. I'm now grafting IceCat as extra test.
<lle-bout>nckx: okay! thank you!
<lle-bout>nckx: not sure IceCat actually uses the sqlite package
<efraim>something about the profile IIRC
<nckx>lle-bout: Oh. Possible, but then how does it create its sqlite files?
<nckx>Bundled? :-/
<lle-bout>nckx: I think it bundles one because ours doesnt have necessary features
<lle-bout>es
<lle-bout>yes *
<nckx>FFS.
*nckx goes lookings for another test package.
<lle-bout>There's a comment in the sqlite package about it, it's some work but possible
<nckx>lle-bout: Well, yes, but it implies that IceCat *can* use our package, which is why I thought it would work.
<nckx>‘Add these options or IceCat won't use it’ → options are present → [nckx extrapolates] IceCat can use it. Granted, there's a small leap there.
<nckx>I didn't think about it that much :)
<lle-bout>I didnt check if they were present heh
<lle-bout>assumed they werent
<efraim>lle-bout: re mariadb, looks like you want (inherit (package-source mariadb)) instead of repeating all the fields
<lle-bout>efraim: the patch is wrong also, it doesnt apply, preparing v3
<lle-bout>efraim: I'll try, but never done before, it will look cleaner, thanks
*nckx continues building IceCat, now to test 2 things...
<abr>hmmm apparently there's so javascript (?!) configuration in the gnome-shell package, I might be on the right track, I'll keep digging
<nckx>abr: GNOME Shell is written in JavaScript.
<nckx>Sounds right.
<gagbo[m]>Hello, can I query locally the recipe for a package ? I'd like to check the commit used in the recipe for a package in my current env basically
<vldn>is it possible to split my personal config into different files and can activate options (like extra packages, service configs etc.) via a single flag in my main config?
<vldn>i already have a module defined via add-to-load-path and load it via (use-modules) but how to go further than defining a single package that i can load into my package list?
<pinoaffe>vldn: are you referring to system config or to manifests or something else?
<pinoaffe>anyhow, both are "generated" by evaluating guile scheme code, so if you know a bit of scheme you can make write a script to make the config vary based on a couple of flags
<gagbo[m]><gagbo[m] "Hello, can I query locally the r"> I ended up using `--export-channels` to get the commit and check in the repo using other means. I couldn't know which version of the channel I was using in my `/gnu/store` (had like 5 different ones)
<raghavgururajan>lle-bout: I have added some more commits in-between via rebase. https://git.disroot.org/raghavgururajan/guix-core-updates/commits/branch/rg-core-updates
*raghavgururajan 's mid-night oil has been burnt out -- light has come -- zzZ
<Mathias123>hello
<Mathias123>I am trying to use Guix in my distribution. I run:
<Mathias123>GUIX_LOCPATH=/root/.guix-profile/lib/locale
<Mathias123>GUIX_LOCPATH=/root/.guix-profile/lib/locale
<Mathias123>GUIX_LOCPATH=/root/.guix-profile/lib/locale
<Mathias123>GUIX_LOCPATH=/root/.guix-profile/lib/locale /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon --build-users-group=guixbuild
<Mathias123>in root user
<Mathias123>and I run in root also
<Mathias123>And I run /var/guix/profiles/per-user/root/current-guix/bin/guix pull
<Mathias123>what happen is that my system restart graphic interface
<Christoph[m]2>Hi guix! Can I use guix to set up a Nextcloud server? I saw only the Nextcloud client in the packages list.
<roptat>Christoph[m]2, I don't think we have the server packaged, and we would also need a service for that
<Mathias123>It it possible to run guix-daemon without being in systemd like what I did?
<roptat>Mathias123, yes, it's supposed to be supported
<roptat>what do you mean by "it restarts the graphics interface", do you suddenly get disconnected and you go back to the login screen? That's weird
<Christoph[m]2>roptat Thank you!
<Mathias123>so why is it frozen in my graphic interface? I tried the same in my laptop and even in TTY1 and
<Mathias123>exactly what you said roptat
<nckx>o_O
<roptat>Christoph[m]2, but there's no limitation except for lack of time, so if you want to contribute, we'll be glad to add the service to guix :)
<nckx>raghavgururajan: Good night!
<roptat>Mathias123, anything suspicious in the system's logs? (dmesg etc)
<roptat>I don't even understand how guix/guix-daemon could have an influence on your graphical display
<roptat>I mean it's a CLI tool, it doesn't even have any code to interact with X or anything like that...
<lle-bout>nckx: hey, how did icecat go?
<lle-bout>raghavgururajan: thanks! good night! looking for review
<nckx>lle-bout: You overestimate my lappy.
<lle-bout>nckx: I see, you don't have some offload server, even bayfront?
<nckx>Hm, no, you hinter of hints you.
<nckx>Thing is offloading has never worked reliably for me, to whatever server. But if you're still offering...
<lle-bout>nckx: Offloading works great for me, well turns out I can offer SSH access but offloading is insecure unless I create a VM for each so, bayfront seems to be a server that can be used for offload by GNU Guix committers, maybe use that?
<lle-bout>It's really helpful
<nckx>I've used it in the past.
<Mathias123>both of my NixOS machine and even with just TTY1 have this problem with guix-daemon
<nckx>A ‘transient’ failure rate close to 50% isn't worth it for me; it saves me no time. But thanks.
<Mathias123>Maybe, I should try running guix-daemon inside a container to see if it works
<nckx>In this specific case, I intend to use the resulting IceCat as my actual browser on my laptop, so I wouldn't offload it anyway.
<nckx>Trust goes both ways :)
<lle-bout>nckx: transient failure rate as in unreliable networking causing failures?
<nckx>Mathias123: Is it possible to provide a verbatim log of commands that lead from a NixOS VM to this failure? I know that's asking a lot, but this is a very strange bug.
<nckx>lle-bout: Yes, well, Guix's unreliable handling of normal network lossage.
<nckx>I know work has been done in this area.
<lle-bout>nckx: we should fix that in GNU Guix
<Mathias123>nckx I will try to figure out how to do that
<nckx>lle-bout: It might have been fixed or the fix might be on the patch tracker, I just don't have the energy to fight this particular issue now. Some things are fun to debug, networks have never been one of them for me.
<lle-bout>nckx: Sure, but I am also interested in it that's what I was saying, automatic retry policies etc, reliable software, I like this.
<nckx>I don't like puzzles where the answer changes, unless it's a Spooky Thing That Shouldn't Happen, then it's interesting again :) ‘<eof> during the pull backtrace’ isn't that.
<lle-bout>There might be a model where we can design offload based on the idea that real time networking isnt necessary (polling for results)
<nckx>lle-bout: Well, if you can offload reliably, then I don't know what to say to reproduce my suffering...
<lle-bout>I don't get any errors during offloading, I have a pretty reliable network here yep..
<nckx>lle-bout: Nice. I'm not generally a fan of polling, but falling back to it would be an improvement here.
<lle-bout>nckx: if not polling then some backlog buffer that can be sent after reconnecting
<lle-bout>sounds easy to me to remember some log file offset and resume from there on reconnect
<lle-bout>I wonder how we access the live logging feature of Cuirass
<apteryx>raghavgururajan: about ortp, nevermind, I understood
<apteryx>eh, I don't get it. As soon as I import the #:imported (,@%cmake-build-system-modules) build argument, the build system effectively switches to that of gnu-build-system
<apteryx>as soon as I use*
<apteryx>eh, I meant #:modules (,@%cmake-build-system-modules)
<apteryx>that seems dumb but it's a minimal reproducer
<roptat>maybe because of %standard-phases?
<roptat>ah no, I misread
<roptat>you use the cmake-build-system, right?
<apteryx>ah, that's really meant for *imported-modules*, not for modules
<apteryx>I always confused both; it'd be nice to have the defaults exported for both versions
<apteryx>so what is needed for #:modules is '((guix build cmake-build-system) (guix build utils)); but there's no variable exported with this to augment it with something else; so; copy paste!
<apteryx>raghavgururajan: althoug, at 44 KiB of README and CHANGELOG, I don't think it's worth splitting it into a doc output; especially compared to the size of the lib (2 MiB)
<paulj>Afternoon all! Had anyone had experience where the trackpad on a Lenovo laptop stops working? Everything was OK, but now it isn't, and I am not sure why (no error messages).
<paulj>External mouse works fine
<apteryx>raghavgururajan: oh wait, 1.5M /gnu/store/cc4sm3944kasbdrm7rljv0sq2j5kagkg-ortp-4.4.34/share/doc/ortp-4.4.0
<apteryx>seems I missed something
<happy_gnu>hi guix !
<happy_gnu>how can I disable the $PAGER when doing 'guix search'
<happy_gnu>it doesn't work well with Eshell :p
<roptat>PAGER= guix search
<roptat>or maybe PAGER=cat
<happy_gnu>ohh nice
<happy_gnu>thanks!
<roptat>:)
<roptat>paulj, not sure I can help :/ any message from your xorg logs maybe?
<roptat>(in ~/.local/share/xorg I think)
<paulj>Good thought - I checked the system logs, but not the xorg logs. One moment...
<paulj>Interesting. There is a log where you pointed to, but it was created on the 6th March. There is also a log in /var/log/ with today's date. The former shows the touchpad being recognised and configured, but the latter doesn't. I am not sure what changed around the 6th March to make xorg move the location of the log file. In the old logfile, the touchpad is identified under /dev/input/event8, but in the new logfile, this is shown as
<paulj>"ThinkPad Extra Buttons", and is being configured as a keyboard switch, and is then seems to be removed.
<paulj>Seems like udev is not identifying it properly?
<paulj>Successful configuration (6th March), around line 410: https://paste.debian.net/1190964
<paulj>Current status: around line 660: https://paste.debian.net/1190965
<paulj>Also in the latter, there are many lines with 'Option "_source" "server/udev"'
<paulj>These seem odd, to say the least...
<roptat>sorry, I don't know how to help
<roptat>if nobody can help here, maybe try to send to help-guix
<paulj>Thanks for responding. Looking through what I can find on the internet, there seems to be issues sometimes with these not being recognised, and there is a parameter which can be set when the module is loaded. What is strange is everything was working fine, but now doesn't without any change to my configuration!!
<roptat>well, maybe a software update
<roptat>sometimes they change the way configuration is handled
<roptat>or maybe a new version of guix has new defaults that don't play well in your case
<yoctocell>Hi, is there a way to "patch" channels? For example, there is a patch (https://issues.guix.gnu.org/47180) that fixes some problem with Racket but, it hasn't been merged yet. How would I use this patch in my Guix channel?
***pocketroid_ is now known as pocketroid
<mothacehe>hey guix!
<sneek>Welcome back mothacehe, you have 1 message!
<sneek>mothacehe, civodul says: the (guix channels) changes apparently broke Cuirass: https://ci.guix.gnu.org/eval/149790/log/raw
<civodul>hi mothacehe! wb! :-)
<civodul>we stumbled upon news from you that inadvertently made it to planet.gnu.org, and this looks like great news!
<mothacehe>hey civodul, thanks :)
<mothacehe>woops, it was meant to stay as a draft until next monday!
<mothacehe>but I spoiled the surprise using the wrong directory in guix-artwork :(
<civodul>heh, i think that's okay
<civodul>i thought it would disappear from planet.gnu.org when it would update, but apparently not
<civodul>i guess on Monday you can republish it with a new date and maybe a new slug
<mothacehe>will do, also read your draft article, terrific!
<civodul>ah cool, thanks!
<civodul>i think i'll publish tomorrow, then
<civodul>mothacehe: just this Monday i upgraded Cuirass at work to what turns out to be almost 1.0 :-)
<civodul>i'm using manifests and there were issues: https://guix.bordeaux.inria.fr/jobset/guix-hpc
<civodul>but since there seems to have been changes, i've now reconfigured it to see if the problems went away
<civodul>(the optimistic hacker's technique)
<mothacehe>hmmm, not nice
<mothacehe>you can also use the channels build type to build only the guix-hpc packages
<civodul>oh!
<civodul>that's even better
*civodul tries
<mothacehe>(you can even try it from the web interface)
<civodul>woow, fanciness
<mothacehe> https://guix.bordeaux.inria.fr/specification/add/
<civodul>i have to get used to it :-)
<civodul>neat
<civodul>actually, do changes in the service config have any effect?
<civodul>or is it just for the initial config?
<mothacehe>although it means trading sexp against huge amounts of js :p
<mothacehe>the service config does a insert-or-update in database
<abcdw>hi again, yoctocell: Probably, there is no way to do it easily. Patches doesn't have commits related to them => you can't use them in channels definition. The obvious option is to clone guix repo and apply patches on top of it and set guix channel to local repo.
<yoctocell>Hi abcdw! Ok, that seems to be only option for now.
<guixnoob>question about backups using guix package manager on foreign distro: is it enough to make sure that /gnu/store and /var are included in the backup? I use Timeshift for system (non-home) backups and Back in Time for home backups. I'm not sure the proper way to ensure that, should I have to reinstall my OS, my guix setup and packages restore as well.
<guixnoob>It seems like the guix stuff is spread across multiple places. /gnu/store, some files in /var, user home .guix-profile, root .guix-profile
<civodul>mothacehe: if i look at the spec via the "edit" web UI, it looks good; but it's still failing (with the "channels" build type now)
<civodul>saying there's no 'guix' channel
<mothacehe>civodul: yeah I just reproduced it locally
<civodul>mothacehe: oh good, thanks; i'll stay tuned
<abcdw>guixnoob: You actually do not need to backup guix stuff, if it is declared somewhere. Because of reproducibility it's enough to have only configs to be able to get all the stuff in /gnu/store again. However if you use guix package -i or guix install it's a little trickier. I would suggest to use manifests and later, when it will be finished - `guix home`.
<guixnoob>abcdw: I do use guix install. I've never used manifests and I don't know anything about the `guix home`.
<lle-bout>shouldnt we try to reorganize packages better and make better use of directories
<lle-bout>I think I would prefer if each package had it's own file
<guixnoob>Is there a way to generate a manifest for the current profile, including all the already installed packages?
<lle-bout>guixnoob: guix package --export-manifest
<abcdw>guixnoob: The really cool thing about guix is that with only two files (configuration/manifest and channels definition) you can reproduce the whole operating system bit for bit (or reproduce profile with packages in your case).
<abcdw>lle-bout: Do you mean to split modules like version-control, video, etc to multiple modules?
<guixnoob>The export-manifest output mentions using `guix describe` to get channel information.
<lle-bout>abcdw: yes, for example with gnome I feel like things are a bit spread out it's not easy
<yoctocell>guixnoob: You can put the output of `guix describe --format=channels` in ~/.config/guix/channels.scm to get the same channel versions.
<zimoun`>mothacehe: where do these specifications <http://ci.guix.gnu.org/specification/add/> end if I hit Submit?
<abcdw>guixnoob: You can do `guix describe -f channels` and later use it with `guix pull -C` or `guix time-machine -C`, but you need to read manual first to get better understanding of guix features and capabilities.
<mothacehe>zimoun`: nowhere because you don't have the admin access on ci.guix.gnu.org
<guixnoob>So if I save the output of `guix package --export-manifest` to a file somewhere, and save the output of `guix describe --format=channels` to another file somewhere, then I can just backup those two files? Then all I have to do on a new system is install guix, then [do something with the channels file ?], then `guix install -m <manifest file>`?
<lle-bout>guixnoob: also: guix package --export-channels
<lle-bout>guixnoob: yes
<abcdw>lle-bout: what do you mean by spread out?
<zimoun`>mothacehe: ahah! Ok :-)
<lle-bout>abcdw: that it is not entirely clear which packages should be upgraded when dealing with GNOME
<guixnoob>ah, so `guix package --export-channels > ~/.config/guix/channels.scm; guix package --export-manifest > ~/.config/guix/manifest.scm` would be a one-liner for backing up my guix?
<yoctocell>lle-bout: Agree, sometimes I find it hard to find where a package is defined. For example, guile-json is defined in guile-xyz.scm, but guile-curl is defined in curl.scm, not guile-xyz,scm.
<lle-bout>abcdw: I'll probably find out when doing it but they could all be in the same place and I would have more confidence
<abcdw>guixnoob: cp -r ~/.config/guix /mnt/backup-drive (:
***stikonas_ is now known as stikonas
<lle-bout>yoctocell: for finding particular packages 'guix edit <pkg>' helps but yes
<guixnoob>abcdw: That will happen when I Back in Time runs :-)
<abcdw>To restore from backup you can use `guix pull -C channels.scm && guix package -m manifest.scm` or `guix time-machine -C channels.scm -- package -m manifest.scm`.
<yoctocell>lle-bout: Aah, good point.
<abcdw>yoctocell: Also `guix search` show location:
<abcdw>shows*
<paulj>Found it. The boot command blacklists the usbmouse. If I remove this before booting, the trackpad is working. I now need to see where to edit this in my configuration...
<guixnoob>Excellent. :-) https://paste.debian.net/1190974/
<yoctocell>abcdw: Yeah, that's nice.
<abr>later
<zimoun`>yoctocell: guix show <pkg> | recsel -p location
<civodul>oh, new Emacs release; "guix install emacs --with-latest=emacs" anyone?
<guixnoob>Awesome. I have those aliases which save to .config/guix, which gets included in my Back in Time backups, and I have added that directory as a backup directory in my pCloud settings. 3-2-1 rule: achieved. Thanks!
<Raenis-Limenis>hey all, was wondering if I can get some help. I'm trying to use guix system disk-image on a install.scm I currently have on a ubuntu host. This is the error
<Raenis-Limenis>guix system: error: failed to load './install.scm': ice-9/boot-9.scm:3300:6: In procedure resolve-interface: no code for module (nongnu packages linux)
<Raenis-Limenis>the exact line was "guix system disk-image ./install.scm --image-size=10G
<NieDzejkob>looks like that file wants to use the files it was originally distributed with
<yoctocell>zimoun`: `recsel` is not installed on my system (:
<lle-bout>civodul: does it work? :-)
<civodul>lle-bout: i wasn't sure :-) so i tested and it actually works
<lle-bout>civodul: it's a small bugfix upgrade so it's an easy one but awesome :-D
<civodul>well, Emacs upgrades are rarely "small upgrades" :-)
<civodul>but yeah, not the hardest exercise either!
<vldn>how to make a module like a personal-sway-config.scm that appends automatically to the systempackage all defined user packages for the sway session upon loading the module in the main config.scm
<lle-bout>I already run emacs unreleased 28.x through flatwhatson channel with pgtk and native-comp
<Raenis-Limenis>did anyone see my message before? I just started seeing every one's messages so wasn't sure if anyone saw mine.
<vldn>without setting the self defined list manual to the packages or the services in my main config
<civodul>lle-bout: can't you run "emacs-next --with-branch=master" to that effect, for extra fun?
<cbaines>civodul, I'm going to look at reconfiguring bayfront shortly
<lle-bout>civodul: I am not sure native-comp or pgtk was merged to master actually
<lle-bout>guix build emacs-next --with-branch=emacs=master
<lle-bout>oops needs emacs-next=master instead probably
<dongcarl>Anyone know what can cause "git/bindings.scm:66:8: In procedure git_libgit2_init: Function not implemented"? This appears after "Updating channel 'guix' from Git repository..."
<lle-bout>jlicht: hey, are you here?
<vagrantc>Raenis-Limenis: saw your message, but not sure how to respond. maybe others can help
<vagrantc>Raenis-Limenis: although it sounds like you're using some custom modules ... pretty sure "nongnu" isn't in guix. :)
<civodul>cbaines: yay, thanks!
<civodul>dongcarl: uh, never seen that; is that 'guix' from "guix pull"?
<lle-bout>civodul: worked: guix build emacs-next --with-branch=emacs-next=master
<civodul>lle-bout: yay!
<Raenis-Limenis>hey all, I'm trying to install gnu guix on a laptop using an image made from guix system disk-image ./install.scm as described here https://github.com/daviwil/dotfiles/blob/master/Systems.org#system-installation
<paulj>If I define kernel-arguments under the operating-system definition, will this override arguments which are automatically provided?
<Raenis-Limenis>guix system: error: failed to load './installscm': ice-9/boot-9.scm:3300:6; In procedure resolve-interface: no code for module (nongnu packages linux)
<DavidWilson[m]><Raenis-Limenis "hey all, I'm trying to install g"> Hey! I can help you with that in the other place where we chat :)
<lle-bout>civodul: it also runs all fine and all!
<paulj>By default I have a "modprobe.blacklist=usbmouse,usbkeyboard" and want to disable it.
<zimoun`>yoctocell: “guix install recutils“ and done ;-) All the outputs of ‘search’ and ’show’ are formatted to be parsed by recutils.
<paulj>DavidWilson[m]: I am interested to know if you have come across any issues with the trackpads on your lenovo laptops recently...
<DavidWilson[m]><paulj "David Wilson: I am interested to"> Nothing in particular! What have you noticed?
<yoctocell>zimoun`: Aah, thanks!
<paulj>Mine stopped working completely sometime between the 6th March and today. For some reason the trackpad was no longer recognised. I have got around the problem by removing the blacklisted usbmouse (temporarily at the moment), but it doesn't seem right. I don't know if that has changed recently.
<paulj>My config is _very_ similar to yours, and uses libinput to manage the device
<dongcarl>civodul: I believe this was a `guix` built from source, I will double-check.
<dongcarl>PowerPC people: could someone sanity-check my patch here: https://issues.guix.gnu.org/47349
<DavidWilson[m]><paulj "Mine stopped working completely "> Interesting, I did a full system update yesterday on one of my machines and the track pad is still working. Does it improve the issue if you stop using libinput?
<dongcarl>lle-bout: Thanks :-)
<paulj>I haven't tried that yet. When I installed Guix everything just worked, and as I had an external mouse attached I never noticed the loss of the trackpad function. I'll do a bit more investigation and see whether I can narrow it down further. Interestingly, I have another X270 running Gentoo and this is also configured to use libinput, and has no issues. I am just updating that machine and will see if there is issue external to the
<paulj>distributions.
<paulj>I think there is a qtwebkit update waiting though, so it will be some time...!
<mbakke>efraim: did you find out anything regarding mesa and GCC 10?
<civodul>dongcarl: if it's a hand-crafted build: no guarantee! :-)
<maddo>is there a reason the package for gnome is over a year old?
<maddo>gnome 40 was released and guix is still at 3.34
<jonsger>maddo: that no one updatet it yet, or better that those changes are not yet merged
<lle-bout>maddo: reason is lack of contributors in that area
<lle-bout>I am trying to upgrade to GNOME 40 as we speak
<lle-bout>maddo: we don't have it easy with being a non-FHS distro and non-systemd too.
<jonsger>+1
<lle-bout>raghavgururajan is doing the GNOME 3.38 one in parallel
<acrow>On guix system -- what is the recommended way of managing /etc/hosts? Just stick a (substitute* "/etc/hosts" regex) into the operating-system declaration? Wouldn't shepherd overwrite a manual change?
<maddo>is gnome that reliant on systemd? Shouldn't the fallback session management still be there?
<dongcarl>civodul: I'm happy to dig into what's actually going wrong myself, just wanted some pointers like: is there something wrong on the GUILE_LOAD level, or the bindings level, or libgit2 itself? Things like that :-)
<lle-bout>maddo: it seems lots of functionality depends on systemd and is otherwise disabled yes
<lle-bout>maddo: https://github.com/dantrell/gentoo-project-gnome-without-systemd
<dongcarl>Looks like people have encountered my problem before: http://logs.guix.gnu.org/guile/2020-05-01.log#234400
<dongcarl>Also: https://logs.guix.gnu.org/guix/2020-05-04.log#092449
<efraim>mbakke: I haven't looked too closely yet. I started trying to get it to build with gcc-9 instead but now llvm-11 is failing during a linking phase. I also tried bumping mesa to 20.3.5 but it had the same error. between the two I'd rather debug mesa
<apteryx>in case a package installs a tester command that runs a self test, in what output should it go? Contenders are 'tester', 'test', something else?
<mbakke>efraim: I've noticed Arch has some GCC patches that fixes a Mesa issue. Possibly unrelated, but hard to tell.
<maddo>lle-bout: yikes
<maddo>so if someone didn't want a tiling wm/compositor, the answer is xfce?
<maddo>(too bad for wayland tho...)
<lle-bout>maddo: I use XFCE, there's also MATE, you can also run MATE over a Wayland compositor that supports layers (like sway or wayfire) but not all applets/.. are ported over to Wayland yet over at MATE's, I pushed patches to enable that for MATE recently.
<lle-bout>I am hoping to use GNOME 40 not because I don't want a tiling wm but because I can't deal with doing the desktop integration myself on top of Sway, I would install pop-os tiling shell probably.
<lle-bout>maddo: See https://github.com/mate-desktop/mate-panel/pull/991 for info
<efraim>hmm, logfile got cut off, i'm rebuilding mesa with gcc at 10
<lle-bout>In a few releases probably MATE will support Wayland completely and entirely but it doesnt yet, well it works fine but some applets etc. wont work, it's not a huge deal but still.
***Server sets mode: +cntz
<jonsger>mothacehe: oh simple cuirass is gone?
<mothacehe> jonsger: yes, but the good new is that Cuirass is now simple by itself :)
<apteryx>efraim: I really often get cut off logfile; is this a known issue? I think it has to do with multiple bulids in parallel
<apteryx>builds*
<mothacehe>I'll announce the 1.0 shortly but you can have a look to the online manual for information: https://guix.gnu.org/cuirass/manual/
<apteryx>I usually just relaunch the failed build to get a non-truncated log when this happens
<mothacehe>civodul: I updated Cuirass to fix your issue.
***sturm is now known as Guest47983
***sneek_ is now known as sneek
***apteryx is now known as Guest48998
***Noisytoot_ is now known as Noisytoot
***Noisytoot is now known as Noisytoot__
***Noisytoot__ is now known as Noisytoot
<jonsger>mothacehe: I guess I need to delete the old postgres db? or is there a working migration path?
***nckx[2] is now known as nckx
***Server sets mode: +cntz
***cyrozap is now known as Guest19902
<mothacehe>jonsger: no there's a new database schema. You need to remote it before proceeding.
***av0idr is now known as avoidr
***ba is now known as bandali
<lfam>Wow! A torrent of "bug closed" messages about Cuirass
<lfam>That's awesome
<mothacehe>hehe, thanks lfam :)
<lfam>I'm trying to coordinate getting some more of the Overdrives connected, mothacehe
<mothacehe>I think nckx has two Overdrives and will reconfigure to (sysadmin overdrive) when time permits.
<lfam>Yeah, we were talking about it on guix-sysadmin
<mothacehe>Thanks for taking care of that.
<lfam>The salient parts of (sysadmin overdrive) are the cuirass-remote-worker-service-type and wireguard-service-type, right?
<mothacehe>right
<lfam>I'm asking in case the hosters want to adapt an existing config.scm rather than replacing it completely
<lfam>Great
<mothacehe>the wireguard counterpart on berlin main node is manual
<mothacehe>I need to update berlin.scm
<mothacehe>(to allow build nodes wireguard worker keys)
<lfam>Right
<lfam>We'll notify you when the Overdrives should be ready
<mothacehe>I had overdrive1.scm inherit (sysadmin overdrive), we could do the same for the other overdrives.
<mothacehe>Thanks :)
<lle-bout`>I hope the openssl upgrade is OK, I didnt get it reviewed because for me it is a really safe graft to make
<mothacehe>lle-bout`: I think it broke guix@aarch64-linux
<lle-bout`>mothacehe: are you serious
<mothacehe> http://ci.guix.gnu.org/build/118948/log/raw
<lle-bout`>mothacehe: ok, the test suite succeeded for me here
<lfam>Files=158, Tests=2636, 1657 wallclock secs (10.59 usr 0.30 sys + 1508.88 cusr 133.54 csys = 1653.31 CPU)
<lfam>Am I correct to interpret this as meaning that it spent more than one hour on that test?
<lle-bout`>on aarch64-linux
<lle-bout`>maybe it's the emulation? or was that an overdrive?
<lfam>My question, exactly
<mothacehe>I need to add the machine name in the build details page
<lle-bout`>I don't think openssl adds or alters tests on security fix releases
<lfam>Hey mothacehe, I have a question about the wireguard setup. Will the new Overdrives use the same public-key for berlin-peer?
<mothacehe>lle-bout`: 118948 was emulated (hydra-guix-127)
<lfam>Do we have a technique for forcing it to use the Overdrive?
<mothacehe>lfam: A wireguard private key is generated in /etc/wireguard/private.key on the Overdrive
<lle-bout`>I would advocate for putting an end to emulated builds
<lle-bout`>I can fund baremetal hardware if required
<lfam>Indeed, lle-bout`, that's the goal
<lfam>We actually have the funds
<mothacehe>then the public key can be obtained this way: wg pubkey < /etc/wireguard/private.key
<lle-bout`>Also what's policy for renting hardware instead?
<lle-bout`>Could I donate rented hardware?
<mothacehe>and that's the key that needs to be authorized on berlin
<mothacehe>but I should write shomething about it
<lle-bout`>It's actually easier to follow up with hardware upgrades that way
<mothacehe>there's no way to force some builds to run on specific workers yet
<lle-bout`>E.g. get AMD Epyc 2 today, then AMD Epyc 3 a year later, AMD Epyc 4, .. or other types of machines
<lle-bout`>Without buying new machines each time
<lfam>lle-bout`: I'm not sure if there is a policy, but we have always preferred to own hardware, and host it somewhere "trusted". What is "trusted" is not easy to define, but we know it when we see it
<lle-bout`>Well to say within a datacenter it's not a trusted place.. I would say it's not the biggest concern, depends what you trust things for
<lfam>However, it has been difficult to do this reliably, especially with ARM. That is because, so far, there has never been any ARM hardware that was simple to install GNU / Linux on, and reliable enough to run fully-loaded 24/7
<lfam>Now, there is good ARM hardware
<lfam>It's still not simple to install a system onto, but at least it can handle the load
<lfam>The main blocker at this point is that somebody needs to lead the effort to purchase the hardware and coordinate hosting
<lfam>It's a significant leadership task
<lfam>The purchasing committee must be persuaded that the money is "worth it" somehow for the project, and that hosting will be reliable
<lle-bout`>We should definitely find a reliable colocation partner like Gitoyen in France
<lfam>It would be *amazing* if we could have donated colo
<lle-bout`>Gitoyen is a non-profit LIR
<lfam>Donated or at least discounted
<lle-bout`>Gitoyen has fixed costs, especially for bandwidth
<lle-bout`>LIR but also it can do colo
<lle-bout`> https://www.gitoyen.net/services-de-gitoyen.html
<lfam>It's actually better for us to spend money to buy hardware but then host it for free. This is why I keep pushing for workstation-type machines, since they can be hosted in homes and offices
<lfam>The one-time cost is easier to account for
<lle-bout`>Sure
<lfam>And lots of us wouldn't notice a workstation on our electricity bills
<lfam>And residential internet is typically unmetered
<lle-bout`>And fiber becomes more and more common
<lfam>Yeah, I have it now
<lfam>200 mbits symmetric, unmetered, for the cost of a restaurant meal
<lfam>And my electricity is very cheap
<lle-bout`>yay
<lle-bout`>how much?
<lfam>I don't know. Cheap enough that I never look at the bill
<lfam>And, I'm not a wealthy person
<lfam>USA power is really cheap
<lle-bout`>I pay 40 euros per month for 3500 Mbps down / 600 Mbps unmetered
<lfam>Oh, for internet, I pay ~$40
<lle-bout`>I meant the Internet access
<lfam>Yours is faster
<lle-bout`>Okay cool!
<lfam>Internet has historically been more expensive here than in Europe
<lle-bout`>But my appartment is expensive
<lfam>Bah
<lle-bout`>Paris location
<lfam>Okay, but look at what you get! You get to live in Paris!
<lfam>It's worth it :)
<lle-bout`>Hmm not sure
<jonsger>without Tourists even more, I guess :P
<lle-bout`>Lots of fantasm here and there about Paris
<lfam>Yes, of course
<lfam>The world loves Paris
<lfam>Maybe it's harder for Parisians
<lle-bout`>The world "loves" Paris's Bourgeoisie culture ***
<roptat>I don't like Paris
<lfam>There's nowhere in the world where the working class is truly loved
<lle-bout`>Hmm is it
<lle-bout`>Paris is great to meet people and find your social environment but other than that..
<lle-bout`>Basically it's also that you feel empowered geographically to attend or access many social environments of privilege to have some impact, it's crazy how France media scene is so self-centered around Paris
<lfam>I suppose that everbody always wants what they don't have :)
<lfam>Population density is extremely valuable to human civilization. Everywhere you go, the biggest cities are the most important areas
<ternary>Could someone give me a bit of guidance on how config files for services work? I'm using opensmtpd and want to populate the /etc/mailname file. I figured I could add a mailname field to the opensmtpd-configuration type and have it create the file, but in looking at gnu/services/mail.scm I don't see anywhere that the path for the existing config files is specified and so I'm not really sure how
<ternary>they're getting created
<ternary>Alternatively, is there a way for me to wrap the service inside some store-mutating expression that would allow me to make that file and have it be accessible to smtpd?
<roptat>I don't remember what that file does, but can you specify a custom location in your configuration?
<lle-bout`>lfam: main problem is access to buildings for poorer population but thankfully we have plenty of squats
<ternary>roptat: I'm no expert, but the man page indicates it gets the hostname from that file if it exists, or the system hostname if it doesn't
<roptat>ternary, I have an example here where I create an aliases, blacklist and relays file and use mixed-text-file to include them in my config: https://git.lepiller.eu/system-configuration/tree/-/modules/config/mail.scm
<ternary>Thanks, I'll look over that and see if it does what I need
<roptat>if it's necessarily /etc/mailname, then you can use the etc-service-type (or whatever it's called) to create it, outside your opensmtpd service
<roptat>although, it might be that our package will actually look at /gnu/store/...-opensmtpd-*/etc/mailname
<ternary>I haven't tested, but that's what I'm afraid of. The manpage has had the text changed to list that file
<roptat>right, that's probably what will happen then
<roptat>is there any other option that can change the hostname?
<ternary>There is a hostname directive, but it appears to take a list of domains that it applies to, and I haven't found any examples of someone using it, so I'm not 100% sure what it does
<roptat>I think it will only override the hostname on the HELO command
<roptat>that might be sufficient, I don't know
***sorki is now known as srk
<ternary>I haven't used mixed-test-file, seems pretty useful. Does it not allow me to specify a path for the file though?
<ternary>mixed-text-file*
<roptat>the first argument is the name of the file
<roptat>it will go to the store
<ternary>So the name could be /etc/mailname?
<roptat>nope
<roptat>the name should be a file name, not a path
<ternary>With the goal of it going in the store at /gnu/store/.../etc/mailname
<roptat>mh, why do that though?
<roptat>it creates a new store item, you can't modify an existing store item
<roptat>so if you wanted to replace /gnu/store/...-opensmtpd-*/etc/mailname, forget about it :p
<ternary>Oh right, the binary would have a different folder than the service
<roptat>the only way would be to override the opensmtpd package
<roptat>it's not too hard if that's really what you want to do, but it means you'll build the package yourself
<roptat>if I were you, I'd first set the hostname directive and see if that's working, if not, I'd then modify the package
<ternary>Makes sense, thanks
***capnick is now known as cap
<roptat>mh... I think I could reduce my spam by actually checking SPF of incoming email
<vagrantc>roptat: don't make any hard rules about it, though ...
<roptat>but all documentation I find is about setting the SPF record for myself...
<vagrantc>e.g. mailing lists violate SPF, for example
<roptat>arg, true
<roptat>ok, then maybe I need to find a way to integrate spamassassin or similar
<lle-bout`>roptat: it's not packaged AFAICT, but I saw few CVEs on it recently, so package it now latest it's great
<roptat>yeah, now I'm getting ~5 spam messages a day, it's annoying
<dongcarl>vagrantc: Hey hey, is the recommended use of the debian guix package to `guix pull` immediately after the install so that `guix` knows about itself and also to update the systemd service files to point to the right place?
<vagrantc>dongcarl: point at the right placE?
<dongcarl>vagrantc: well currently `guix-daemon.service` points to /usr/bin/guix-daemon, which doesn't get updated with `sudo --login guix pull` if I'm understanding correctly
<vagrantc>dongcarl: my theory is you can used the packaged guix-daemon/guix-publish
*vagrantc imposes a bit of feature-stability on guix :)
<vagrantc>dongcarl: the debian packaged guix is admittedly a bit of a complicated path to run guix pull, but it's likely what you'll want to do
<lle-bout`>vagrantc: what do you mean complicated?
<dongcarl>Yeah I'm just setting my community members up to run Guix on their Hirsute/Bullseye machines, and was wondering about "best-practices"
<vagrantc>lle-bout`: it's a lot of infrastructure to just eventually run guix pull ... e.g. all the packaged stuff isn't managed in /gnu/store and can't be gc'ed
<vagrantc>dongcarl: we're inventing it as we go :)
<dongcarl>vagrantc: Sounds good :-)
<lle-bout`>vagrantc ah yes but it means 'apt install guix' :-)
<vagrantc>crazy enough, i still mostly run guix on Guix System :)
<vagrantc>after all that work ... :)
<lle-bout`>We put lots of constraints onto ourselves for questionnable goals some times
<lle-bout`>I hate policy often
<vagrantc>looking forward to enabling ppc64le in the debian packages once 1.2.1 releases :)
<lle-bout`>vagrantc: you can do that *after* freeze?
<vagrantc>but policy is what keeps us from ad-hocracy ... rule by the whim of the moment
<vagrantc>lle-bout`: there's always experimental :)
<lle-bout`>vagrantc: so it means ppc64le support will come next cycle? baaah
<lle-bout`>bullseye-backports maybe
<vagrantc>lle-bout`: there are also -backports suites ... though i'm not sure how feasible that will be ... will see
<lle-bout`>thanks a lot for all the work again
<dongcarl>Oh... You can't bump minor versions in the main suite?
<vagrantc>it was, at times, mindbending ... but fun, and a great lot of community support :)
<vagrantc>dongcarl: it's more about how much the code has changed than the version number ... guix definitely moves a bit fast in that sense
<dongcarl>Ah okay
<vagrantc>so yeah ... debian will have 1.2.0 ... for a long time ... or someone will discover something horrible and it'll get yanked :)
<roptat>vagrantc, but then the daemon remains susceptible to the latest security issue we had
<roptat>vulnerable*
<vagrantc>roptat: targeted patches are fine
<vagrantc>i've already got those patches applied in git ... but need to upload the changes *soon*
<roptat>I see
<roptat>and the "apt upgrade" would get a fixed guix-daemon
<vagrantc>right
<roptat>mh, spamassassin fails to build: ./configure: line 5877: /bin/sh: No such file or directory
<roptat>and that's in the build phase :/
<roptat>it looks like there's a Makefile.PL that generates a Makefile that calls a configure.pl that generates the configure script and calls it
<vagrantc>roptat: the problem gets to be if guix-daemon diverges too much to easily backport the patches ...
<roptat>it shouldn't... until we rewrite it in guile
*vagrantc cheers roptat on!
<vagrantc>a counter to the rewrite it in rust meme
<lle-bout`>mothacehe: hey! does Cuirass have some policy to cancel all previous builds that don't apply for HEAD on core-updates?
<nckx>sneek: later tell mothacehe: One of them has a dead hard drive, and the other one dropped off the edge of the Internet just when I'd almost finished reconfiguring it. These things are cursed, but it shouldn't take much work once I can get to it.
<sneek>Okay.
<lfam>😭
<nckx>Yeah, that. 😒
*lle-bout` sees only cryptic utf-8 squares
<lfam>We are expressing sadness and annoynace
<lfam>annoyance
<lle-bout`>I see
<nckx>My ~/guix was just irrevocably corrupted.
<nckx>Today is cursed.
<lle-bout`>is my nick lle-bout banned?
<lfam>nckx: Guix's fault?
<nckx>lle-bout :No such nick/channel
<nckx>lle-bout`: No, of course not.
<lle-bout`>"sinisalo.freenode.net 435 lle-bout` lle-bout #guile Cannot change nickname
<lle-bout`> while banned/quieted on channel"
<nckx>lfam: No ☺
<lfam>Phew
<lle-bout`>on #guile it seems
<nckx>#guile/2021-03-25 [18:43:16] *** Quits: lle-bout (~user@2a01:e0a:2a2:1350:789c:dfaa:7d30:c38f) (*.net *.split)
<nckx>#guile/2021-03-25 [18:43:44] *** Joins: lle-bout` (~user@2a01:e0a:2a2:1350:789c:dfaa:7d30:c38f)
<nckx>No ban in between.
<lle-bout`>I can't talk in #guile
<roptat>lle-bout`, maybe you need to authenticate with nickserv?
<lle-bout`>hmm
<lle-bout`>maybe after the netsplit erc didnt re-auth
<lle-bout`>test
<nckx>No more quasiquote.
<lle-bout>hey
<lle-bout>I have been unquoted
<nckx>Welcome back, non-evil twin.
<lle-bout>I am back to 'code' mode
<lle-bout>erc was buggy a little maybe
<lle-bout>can't wait for results of https://ci.guix.gnu.org/eval/13148 see if sqlite upgrade to 3.35.2 on core-updates broke anything
<rhou[m]>has anybody experience developping haskell in guix?
<rhou[m]>I tried to replace cabal with guix ghc packages but got stuck
<lle-bout>nckx: what's up with the cve lint thing by the way
<lle-bout>I havent been looking at the cve linter results for a little while now, but this could get me back to it :-D
<lle-bout>rhou[m]: can you give more specific errors or issues you met?
<nckx>Well, the thing I just mentioned, for one.
<nckx>My hourly back-up server is behind the same dead router as the Overdrive.
<nckx>FFS.
<rhou[m]><lle-bout "rhou: can you give more specific"> I tried to compile a simple program with `import Prelude.Compat` (which is listed in `ghc-pkg list`) and failed with the error message `ld: cannot find -lHSbase-compat-0.10.5-FRXoAxOVtbG2qLNIZm1tTr`
<civodul>sneek: later tell mothacehe thanks for the Cuirass fix!
<sneek>Got it.
<lle-bout>rhou[m]: can you give the package definition and full error log please?
<lle-bout>rhou[m]: I am no expert with Haskell in GNU Guix, but do look at other packages prefixed with 'ghc-' in GNU Guix, you can do so with 'guix search ghc-' then guix edit 'ghc-xxx'
<lle-bout>guix edit ghc-xxx (no quotes needed)
<Gooberpatrol66>guix should fork guile if this happens: https://wingolog.org/archives/2021/03/25/here-we-go-again
<rhou[m]><lle-bout "rhou: can you give the package d"> sorry for my late answer, look at this repo: https://github.com/rezahousseini/test-ghc-guix there is a log from the compilation (`ghc -v src/Main.hs`) and all gets compiled inside the environment defined by the`manifest.scm` file
<crazazy>question: say i downloaded the guix package manager binary, how well would the package manager work on a chroot? has someone run guix in a chroot before?
<vagrantc>Gooberpatrol66: looks like a well written article
<vagrantc>Gooberpatrol66: thanks for the link
<rhou[m]><rhou[m] "sorry for my late answer, look a"> I found my problem, I was missing the `-dynamic` flag!
<crazazy>ok so i went on exploration myself, and to be honest it aint going great. probably actually need an actual container
<civodul>cbaines_: howdy! everything's alright with bayfront?
<civodul>looks like it at first sight :-)
<cbaines_>o/
<cbaines_>I believe so, I'm not aware of any problems
<civodul>coolio, thanks for taking care of it!
<cbaines_>there's a goggles related configuration issue that was causing activation issues, but I've just commented out a couple of the config lines
<crazazy>also for some reason the binary package is missing the guix-daemon binary
<civodul>cbaines_: ok, hopefully we can investigate that later
<civodul>i think part of goggles was started "by hand"
<cbaines_>yeah, it's not blocking anything
<cbaines_>how has your day been?
***cbaines_ is now known as cbaines
<vagrantc>is there a private list for the guix core team?
<civodul>vagrantc: there's guix-maintainer for the maintainers
<civodul>guix-sysadmin for the admins
<vagrantc>thanks!
<civodul>yw :-)
<vagrantc>is the list of those "teams" available anywhere?
*vagrantc vaguely recalls a changing of the guard at some point
<civodul>there's https://guix.gnu.org/en/contact/
<civodul>hmm guix-maintainers isn't there
<vagrantc>that's what i was thinking :)
<civodul>ah, it's at https://guix.gnu.org/en/about/
<civodul>maybe it should be in both places?
*vagrantc thinks so
<civodul>last "changing of the guard": https://guix.gnu.org/en/blog/2020/gnu-guix-maintainer-collective-update/
<civodul>that phrase makes me feel like we have one of those tall hats on our heads
<civodul>and walk in a weird way
<lfam>I notice that when I build aarch64 derivations "by hand" on ci.guix.gnu.org, they offload to overdrive1 and dover. But dover isn't listed on <https://ci.guix.gnu.org/workers>
<vagrantc>civodul: wait, whose key did i sign?
<lfam>I wonder if there is some missing configuration we can add to double our aarch64 capacity?
<vagrantc>if i had more bandwidth i'd try to get some boards up and running for guix ...
<civodul>vagrantc: i've added maintainers to /contact, should show up within an hour
<vagrantc>civodul: thanks!
<civodul>lfam: Cuirass doesn't use the offloading mechanism
<lfam>Right, but if dover is accessible, can we make Cuirass use it?
<civodul>so if dover is not running the "cuirass-remote-worker" service, it's invisble to Cuirass
<lfam>I see
<civodul>lemme see if i have access
<lfam>In hydra/machines-bayfront.scm, there is a comment: "dover ; currently in the berlin build farm"
<civodul>lfam: yes, it's there, but pre-new-Cuirass
<lfam>mothacehe, lle-bout: Building the openssl-1.1.1k derivation for aarch64 "by hand", it succeeded on the aarch64 hardware. So, there should be a substitute available shortly
<lfam>(That was built on dover)
<civodul>lfam: i've emailed guix-sysadmin about setting up cuirass-remote-worker on dover
<lfam>Hey civodul, I'm curious if you saw that the recent change to autoload (guix build download) caused a test failure of tests/print.scm. It's being tracked at <bugs.gnu.org/47375>
<lfam>Thanks!
<civodul>oops i didn't
<lle-bout>lfam, yay I knew it wasnt possible it broke anything
<lfam>It's interesting how much slower the emulation is, even on very fast host CPUs
<lfam>There is at least one improvement we can make to how we use QEMU: <https://bugs.gnu.org/47225> (slow I/O across the VM boundary)
<lle-bout>the search in https://logs.guix.gnu.org/ is rather bad it seems
<lle-bout>also the one in https://issues.guix.gnu.org
<lfam>I think the indexer for the IRC logs is not running
<lfam>Just based on what I've observed as a user
<lle-bout>I am looking for the command that builds world again that rekado_ sent I think
<lle-bout>lfam: just so you know, I am checking and keeping up with the https://nvd.nist.gov/feeds/xml/cve/misc/nvd-rss.xml feed every single day and I have not felt burnt out.
<lfam>I'm glad to hear it :)
<lle-bout>lfam: it's not that much load
<lfam>I've gone through cycles of burning out in the past and I'm more sensitive now, personally
<lle-bout>I understand
<lle-bout>I also have, but I feel healed now
<lle-bout>I realize most CVE entries do not have cpe-name/cpe-vendor
<lle-bout>I mean, it's kind of the point of unanalyzed feed, but
<oreoking[m]>Hello I am new too guix
<lle-bout>oreoking[m]: hello! :-D
<oreoking[m]>im trying it on a vm
<oreoking[m]>coming from nixos cuz nix lang sucks
<lle-bout>oreoking[m]: cool! in what way do you think nix lang sucks? I've came to GNU Guix for entirely different reasons but I find that one interesting
<oreoking[m]>I remember that icecat is on very old versions of firefox but I want the latest one
<lle-bout>oreoking[m]: IceCat is made off Firefox ESR
<oreoking[m]><lle-bout "oreoking: IceCat is made off Fir"> Is there a way to get icecat on the latest versions of firefox
<lle-bout>oreoking[m]: not AFAIK, but there's another interesting fork called Librewolf, I am looking forward to packaging it in GNU Guix
<lle-bout>oreoking[m]: see https://librewolf-community.gitlab.io/ - this one is on latest versions of Firefox
<oreoking[m]><lle-bout "oreoking: not AFAIK, but there's"> i was thinking about librewolf
<oreoking[m]>I was about too say that.
<oreoking[m]>But would it be able to go in official repos of Guix?
<lle-bout>well then! I am interested in getting it in GNU Guix, I will try soon
<lle-bout>Yes I think it will be able to
<lle-bout>We already have ungoogled-chromium
<oreoking[m]>I can't even figure out how to declaritvely install a package yet.
<lle-bout>oreoking[m]: use 'guix install hello' then 'guix package --export-manifest' for an example
<lfam> https://guix.gnu.org/manual/en/html_node/Invoking-guix-package.html#profile_002dmanifest
<lfam>Is --export-manifest new? :) That's a great addition
<civodul>lfam: don't you read 'guix pull' news? :-)
<lfam>Haha, sometimes!
<civodul>cbaines: looking again at http-multiple-get: really, we cannot get those exceptions while reading responses
<civodul>cached connections could lead to exceptions when we first use the connection, i.e., when writing the first request
<oreoking[m]>Where can I find the best docs
<civodul>cbaines: but if we get to the point where we read responses, that means the connection is valid
<lfam>The only docs are the manual, which is authoritative, and the cookbook, which is more like random recipes you might want to use
<lle-bout>oreoking[m]: here: https://guix.gnu.org/manual/devel/en/guix.html
<lle-bout>oreoking[m]: note the 'devel' in the url, it's built from master
<cbaines>civodul, OK, but some of those exceptions only apply to responses, so if parts of the error handling is unnecessary the code was unnecessary, it was
<cbaines>... unnecessary before
<lle-bout>oreoking[m]: you might be interested in https://sr.ht/~lle-bout/awesome-guix/ but it's not yet very complete (reminder for people to submit new entries)
<lle-bout>oreoking[m]: this channel is interesting for educational content: https://www.youtube.com/c/TROP1N/videos
<rekado_>re search on logs.*: the index is up to date (there’s a cron job) and goggles.scm has the index files open.
<rekado_>don’t know why it doesn’t find recent matches
<lle-bout>rekado_: is there a way to do an exact match search?
<rekado_>didn’t I … I remember that last time I looked into it the problem appeared to be premature filtering
<civodul>cbaines: there was no exception handling in http-multiple-get before 205833b72c5517915a47a50dbe28e7024dc74e57
<civodul>(sorry this is this complicated!)
<civodul>yesterday i think i was convinced we kinda need it, and now i can't convince myself again
<civodul>it's terrrible
<cbaines>civodul, indeed, but there was exception handling on the code path when calling it. I guess that could have only applied to processing substitutions
<rekado_>lle-bout: yes.
<rekado_>won’t help you when the set of results is limited too early
<civodul>cbaines: but http-multiple-get is not called when doing "guix substitute --substitute"
<rekado_>default page size is 100, and I think there’s no sorting before the result set is truncated
<civodul>only when fetching narinfos
<cbaines>civodul, yep, before the recent changes though, the error handling in question was used for both --substitute and --query
<civodul>ok
<civodul>(it feels a lot as if http-get was catching its own exceptions in a way)
<civodul>cbaines: i'll send you a variant of the patch you proposed, then
<civodul>and then i'll stick my head in the sand :-)
*rekado_ doesn’t fully understand xapian
<cbaines>civodul, I didn't actually realise quite how recent the addition of call-with-cached-connection was https://git.savannah.gnu.org/cgit/guix.git/commit/?id=5ff521452b9ec2aae9ed8e4bb7bdc250a581f203
<cbaines>civodul, at that point in time, it looks like it only applied to --substitute, although I'd guess the possible exceptions are the same
<darth-cheney>Hello all. I was just following the instructions here at: https://guix.gnu.org/manual/en/html_node/Binary-Installation.html
<lle-bout>raghavgururajan: hey, your glib cosmetic patch doesnt apply :-S
<darth-cheney>The last step, running guix install hello has been running on my machine now for well around 3 hours, is that right?
<lle-bout>raghavgururajan: I am not sure why
<civodul>cbaines: yes, i mentioned that commit in the bug i think :-)
<lfam>darth-cheney: That's unexpected. What does it look like it's doing?
<raghavgururajan>lle-bout: What? hmm
<civodul>cbaines: i posted a variant of the patch at <https://issues.guix.gnu.org/47288>; lemme know what you think!
<lle-bout>raghavgururajan: do you have the patches on a git branch
<lle-bout>raghavgururajan: curl https://issues.guix.gnu.org/issue/42958/attachment/63/0/0/1 | git am -s
<lle-bout>this doesnt apply ^
<raghavgururajan>Fantastic! the has been a merge between master and c-u
<lle-bout>raghavgururajan: master was merged into core-updates recently .. heh
<lle-bout>raghavgururajan: is it a problem..? :-S
<darth-cheney>lfam: here is a pastebin of the output: https://pastebin.com/TgiGLCV8
<lle-bout>I can try rebasing myself your patchset
<darth-cheney>(I also killed the process accidentally)
<raghavgururajan>Yeah, now I am back to sqaure-one. I have to re-work the patches again right?
<lfam>darth-cheney: "substitute: guix substitute: warning: ACL for archive imports seems to be uninitialized, substitutes may be unavailable"
<lle-bout>raghavgururajan: if you have the commit on which your patches are based I can rebase them myself
<lfam>darth-cheney: That means that you did not authorize Guix to download binaries, so you are building everything from source
<lfam>Is that intentional?
<raghavgururajan>lle-bout: I have it here, https://git.disroot.org/raghavgururajan/guix-core-updates/commits/branch/rg-core-updates
<cbaines>civodul, thanks, I'll have a think tomorrow
<lle-bout>raghavgururajan: ok wasnt sure it was the same, thanks
<darth-cheney>lfam: ugh, you're right I missed a step in the guide
<lfam>Alright, let us know how it goes :)
<darth-cheney>Is there anything I should do to clear this out and start over? sorry I'm just getting started with guix here
<lfam>No, you don't need to clear anything
<darth-cheney>ok thanks
<lfam>After you authorize the "substitution" of binaries, things should work more quickly
<lfam>I don't recall if you have to restart the guix-daemon for the authorization to take effect
<lfam>The idea behind the name "substitutes" is that Guix is actually a build-from-source distro, but we are able to transparently "substitute" binaries, due to the functional model of package management
<lfam>So, we can "substitute" building something with downloading something
<darth-cheney>So basically it was trying to build from source and entire system necessary to run this little hello thing, is that correct?
<lle-bout>efraim: seems you merged the zstd graft to core-updates when core-updates alreayd had 1.4.9 so no graft was needed
<lfam>Right, darth-cheney. From the "bootstrap" of the entire distro, up to the hello package
<darth-cheney>Hahah, yikes
<lfam>It would have taken some time, no matter how fast your computer :)
<darth-cheney>alright this seems to have worked, thanks for the help
<lfam>Awesome
<raghavgururajan>I don;t know what to do. I was asked to re-work the patches so that they apply cleanly on c-u and accommodate existing changes. So I spent past few days doing that. Now current c-u is changed, containing changes from master. I cannot do the same work all over again.
<lle-bout>this core-updates situation is messy
<lle-bout>it happened to me all the time with PowerPC 64-bits port as well
<lle-bout>I lost lots of time due to this too
<lle-bout>raghavgururajan: I am rebasing them with git it's manageable
<lfam>I'm surprised that core-updates is changing so quickly that it's a problem
<lfam>That's not something that usually happens
<lle-bout>lfam: when you do work that spans several weeks it usually is, well seemed common for me
<lfam>Hm, interesting! In the past, core-updates has not changed very fast
<lfam>Is master being merged into core-updates often or something like that?
<lle-bout>lfam: yes, also that happens because it's also important
<raghavgururajan>lle-bout: Thanks for the help. :)
<lfam>I guess that, in the past, it wasn't important
<lfam>Like, core-updates isn't expected to be usable right now
<lfam>But maybe the workflow has changed
<lfam>After the upcoming release, maybe we should have a big discussion about the branching workflow, and try to improve it
<lle-bout>yes
<lfam>The current workflow (described in the manual) was largely influenced by a build farm that no longer exists
<lfam>I'm not sure how it should change (or if it should change), but we shouldn't let old technological restraints guide us after they are gone
<lfam>We can all think about it for a few weeks :)
<lle-bout>lfam: one thing we could do to avoid merge conflict would be split things in more files
<lfam>Like which files?
<lle-bout>one folder/file per package and it's specific dependencies (like some fork only used by a package in the same file)
<lfam>That would be tens of thousands of files!
<lle-bout>lfam: yes and what's bad about that
<lfam>Merge conflicts are that bad in practice?
<lfam>In my experience they are annoying, but not very bad
<lle-bout>well you can't merge conflicts for commits you didnt do it's a bit awkward
<lfam>I've done it. It just takes some time to understand the rationale behind the changes
<lfam>I guess, I think that a radical reorganization of the source code should only be done if there is a problem that requires radical changes
<lfam>I'm not sure this qualifies
<lle-bout>I find nixpkgs file organization much better even if still not very perfect to me
<lle-bout>much more easily browsable
<lle-bout>also easier to include e.g. scheme scripts specific to aiding in maintaining some packages within the folders
<lfam>To me, they are about equal. I look in nixpkgs a lot when adding new packages or debugging our packages
<lfam>In both cases, `git grep` solves it
<raghavgururajan>lle-bout: Btw, my current patches are targeted for both gnome 3.38 and 40.
<lle-bout>the file organization right now in GNU Guix is not very consistent what we put in which files remain unclear
<lle-bout>raghavgururajan: what do you mean?
<rndd>hi everyone! does anybody do racket using guix system?
<lle-bout>rndd: dustyweb maybe
<raghavgururajan>lle-bout: glib, gtk, atk, cairo, pango .. are immediate dependencies of gnome-core packages like shell, gdm etc. I am updating the former to the lastest. So that gnome-core can be updated to either 3.38 ot 40.
<lle-bout>raghavgururajan: cool!
*raghavgururajan had a nice spreadsheet somewhere.
<lfam>nckx: Any news from MITRE?
<boomerchad>I'm trying to package DeaDBeeF for guix and I've run into a problem. guix build warns me that 'zlib' and 'imlib2' are imported from two different modules (compression/image and licenses) I assume this means that guix uses the same names zlib and imlib2 to refer to packages, and to their licenses. Is there a way to refer only to the package as I believe this will solve my problem.
<lle-bout>raghavgururajan: spreadsheets! :-D
<lfam>boomerchad: The issue is that Guix has two different things named "zlib": a package, and a license
<lfam>So, you'll need to prefix the import of the licenses in the file you are working in
<leoprikler>boomerchad: #:prefix license: helps all your problems
<lfam>Check 'gnu/packages/linux.scm' for an example
<lfam>In terms of how to submit this work, we'd prefer a patch that prefixes all the licenses in the file, and a second patch that adds the new package
<boomerchad>Ah, thanks.
<lfam>I didn't realize there was an "imlib2" license, but it's the same story as with zlib
<lfam>So, any file that uses one of these licenses and the same-named package needs this license prefixing workaround
<boomerchad>This is my first time trying to package something, I'll submit a patch once I'm sure I can even get it to work haha.
<lfam>Alright, don't hesitate to come back if you get stuck again
<lfam>We are here to help
<raghavgururajan>Found it! https://calc.disroot.org/2nu6mpf88ynq.html