IRC channel logs


back to list of logs

<civodul>vagrantc: this may be related to bc60349b5bc58a0b803df5adce1de6db82453744, which fixed something in this area
<civodul>but it's only on core-updates
<civodul>(which may become master Anytime Now, for sure!)
*civodul -> zZz
<tune>so what's going on when I have to build a new icecat but the version number is the same as my current one? 60.9.0 in this case
<tune>is that normal? some sort of small change that doesn't affect the version
<nckx>tune: Any change anywhere in IceCat's dependency graph.
<paprika>hi all
<sneek>paprika, you have 1 message.
<sneek>paprika, nckx says: Welcome back, glad you defeated the undead IceCat 🙂
<paprika>where do I place scripts if not in /usr/bin
*nckx puts them in .local/bin, adds it to $PATH in .bash_profile.
<zacts>is there now a substitute for IceCat?
<paprika>thanks nckx
***adriano is now known as Guest26142
<vagrantc>anyone working on updating linux-libre to 5.3.x?
<vagrantc>wow... the linux-libre archive is signed by a dsa1024 gpg key ... :/
<nckx>They should use at least DSA2048.
*nckx is bumping the currently packaged versions, at least.
*vagrantc thought dsa of any size wasn't viable
***akko is now known as stallman
***stallman is now known as gologolo
***gologolo is now known as akko
*nckx regrets everything.
<nckx>Building 4.4 and 4.9 now, this sure will take a while…
<nckx>s/building/deblobbing/, even.
<vagrantc>i think i've navigated the maze of linux-libre deblobbing scripts and upstream to produce a linux-libre-5.3.1 tarball
<vagrantc>i should definitely not be doing this on the armhf machine, though. :)
<vagrantc>all this blindly hoping that the veyron-speedy will "just work" again with 5.3.x
<vagrantc>hrm. nope, didn't have the tarball figured out.
<nckx>I've added a 5.3 variant too, but don't know what a speedy Veyron is (well, I know exactly what a speedy Veyron is, and doubt you'd be on IRC if you had one).
<nckx>I think it's better to follow the recipes in (gnu packages linux) than to recreate them by hand. If that's what you're doing.
<vagrantc>i'm trying to update the stuff in gnu/packages/linux.scm and verifying the hashes are actually correct is ... more unusual than most of the other packages i've edited so far
<vagrantc>nckx: veyron-speedy a.k.a. asus c201 chromebook
<nckx>vagrantc: How so?
<nckx>Note that not all the hashes change across versions. That can be confusing.
<nckx>vagrantc: Oh, thanks.
<nckx>Colour me ignorant about Chromebooks.
<vagrantc>most packages just have a single upstream tarball or git repository and you figure out the hash of that ... this is ... an adventure just to figure out what to edit
<vagrantc>but i guess/hope good practice
<vagrantc>so far i've added deblob-scripts-5.3, linux-libre-5.3-version and linux-libre-5.3-pristine-source ... hoping i could at least produce a tarball from that
<nckx>I think it's a pretty good design, considering the complexity involved.
<vagrantc>i do wonder why you can't just grab the pregenerated linux-libre tarballs off of, though
<vagrantc>i vaguely recall a post on the list talking a bit about why it changed not so long ago
<apteryx>olivuser: the game freeorion works fine on my X200 system. Are you using Guix System, or Guix on a foreign distro? What is your GPU?
<PotentialUser-82>Is it possible to install GuixSD on the PINE A64+ LTS, or do you need the non-LTS version? Currently thinking of a good SBC to buy to run GuixSD on - if anyone has any other suggestions for sub $50 I would gladly appreciate it.
<vagrantc>i guess using the scripts, patches, etc. makes sure they work
<apteryx>sneek: later tell civodul by the way, Shepherd works fine as an init even if its PID != 1, on Linux systems >= 3.4, where the process can have the PR_SET_CHILD_SUBREAPER attribute set (man prctl).
<sneek>Will do.
<nckx>vagrantc: If you can wait a day I think I'll have linux-libre@5.3 (and all others) ready to push by then. Unless something unexpectedly fails.
<vagrantc>nckx: i can of course wait a day ... but also walking through this as a learning excercise
<nckx>Sure, as long as it's voluntary.
<nckx>Learn away.
<vagrantc>really want to figure out why this machine stopped working since 5.2.x ...
<vagrantc>some chance it's configuration file related
<vagrantc>there were some changes to kernel options and such
<nckx>I was just reading be7eebe26dbbea10bf40e4cf54250c79ed581952
<nckx>but it's not like ARM stuff will jump out at me anyway.
<vagrantc>what exactly is (define %linux-libre-hash "1s9rcjwy2vmfpin5kxv015ys7lvv84y1pxl1y5aiw0y1mif0mgxb") defining a hash of?
<vagrantc>nckx: i think the switch to how it works also happened after the 5.1.x->5.2.x switch
<nckx>vagrantc: Could you unparaphrase that?
<nckx>I don't know what it defines, but that's moot since that code is nowhere in Guix.
<nckx>I'm not looking at historical code though, no time for that I'm afraid.
<vagrantc>nckx: 1ad9c105c208caa9059924cbfbe4759c8101f6c9
<vagrantc>nckx: the commit for the linux-libre 5.1->5.2 switch changed after that
<vagrantc>whereas before i think it just used the pre-deblobbed tarballs from
*nckx .oO One of the official gnu mirrors:// is
<nckx>vagrantc: It's not quite clear to me either but my guess would be those pre-deblobbed tarballs.
<vagrantc>nckx: well, in order to put the right hash in that definition... how do you get it?
<nckx>That's what I'm trying to find out.
<vagrantc>oh, you download the pre-deblobbed tarball, hash it ... and guix's generated tarball should match?
<vagrantc>at which point... why not just download the tarball
<nckx>vagrantc: I don't understand. That hash isn't used in current Guix.
<nckx>For one, the scripts don't really change that often between releases. Running them ourselves means we're not at the mercy of the linux-libre middlemen to do so for us and upload the results.
<vagrantc>fair enough
<vagrantc>nckx: doh. linux-libre-hash was removed and is just in the cookbook now.
<nckx>It's also just a lot more transparent. Maybe that's subjective. I much prefer this solution, now that it exists, to downloading patched sources.
<vagrantc>it was removed in 1ad9c105c208caa9059924cbfbe4759c8101f6c9
<nckx>Thank god, I thought you were reverting random commits.
<nckx>Then asking ‘why not work’.
<vagrantc>building /gnu/store/5r647yn0q9hkl75p3v3lclz8jpi33ng4-linux-libre-5.3.1-guix.tar.xz.drv...
<vagrantc>i think i must have just gotten confused in trying to disect how to actually do this :)
<nckx>Well, so my work doesn't go to waste: I can confirm that %linux-libre-hash matched then.
<nckx>vagrantc: Mine's *still* deblobbing…
<nckx>Makes you wonder.
<vagrantc>we're in a deblobbing race
<nckx>I'm sure you'll win, I'm building *counts* 6 kernels on my laptop.
<nckx>Free heating.
<vagrantc>of course, i failed to update the actually aux-files/linux-libre/*
<nckx>As in freedom.
<nckx>…if this deblobbing even finishes, actually compiling the 7 lines of Linux code that are apparently free should take no time at all…
<nckx>vagrantc: The update to linux-libre@5.2.1 predates the deblobbing-ourselves commit, so it should be easy to test whether 5.2 broke your system or Guix did.
<nckx>I thought you meant they were coincident.
<vagrantc>nckx: it happened before the deblobbing, i'm fairly sure ... someone else mentioned it too
<vagrantc>er, deblobbing-ourselves...
*vagrantc squints
<vagrantc>it is surprising to watch these deblobbing scripts run...
<nckx>I'm curious: how did you make oldconfig? Or did you just move the 5.2 files to 5.3?
<nckx>Indeed 🙂
<vagrantc>nckx: so far i just moved the files
<vagrantc>nckx: if oldconfig doesn't die as part of the linux build process, i'd probably just grab the generated .config files and stick them into guix
<vagrantc>nckx: #37398 mentioned one way to update the configs
<nckx>‘The MediaTek protocol support enables firmware download support and chip initialization for MediaTek Bluetooth USB controllers.’
<nckx>‘Say Y here to compile support for MediaTek protocol.’
<nckx>That's not as clear as I would like, Linux. :-/
*nckx goes with no.
<nckx>Wait. No.
*nckx goes with yes.
<vagrantc>if there's free firmware... if not, seems kind of frivalous
<nckx>But it's ambiguous (to me) whether ‘firmware loading and chip initialization’ are 1 set or 2.
<nckx>Anyway, I've reverted back to my original N so hah.
<nckx>vagrantc: Thanks for the links.
<nckx>That's just kernel configuration 101 though, I wonder if that's all that's needed. Anyway, I'll surely find out after a mere 2 hours of building.
<nckx>That mail makes me shudder as to why it was written, because it sure sounds like ‘someone was just catting random CONFIG_ values to .config’…
<vagrantc>well, i've done a lot of that sort of updating, since configs in debian are constructed, rather than a blind dump of the whole .config
<vagrantc>it's layered with a common config, and then the specific builds have their own overrides or options
<vagrantc>so you don't have divergence between x86_64 and aarch64 for the majority of options, just the architecture-specific ones
<vagrantc>advantages to both approaches, for sure
<nckx>vagrantc: Which approaches? AFAIK Guix does the same thing.
<nckx>(Guess who's machine went to swap heaven and now has to start over ☹)
<nckx>Whose? Whose.
<vagrantc>nckx: as far as i can see guix just dumps the whole .config into aux-files/linux-libre/*.conf
<nckx>Oh. It used to have schemey overrides (what you call layers). Maybe those are gone. Maybe it's an unholy mix of both (ding ding ding).
<vagrantc>nckx: whereas debian has for the armmp-lpae kernel, simply the 5 configuration options that differ from the armmp kernel
<nckx>…if you're lucky.
*nckx 's cranky because they're back at oldconfig square 1, and oldconfig is boring as hell, sorry.
<vagrantc>successfully built /gnu/store/vp2d6m7l5q0a4yclxin3i4wg94cc1mk7-linux-libre-5.3.1.drv
<vagrantc>wonder if it boots...
<vagrantc>oops. kernel module not found "ahci" "/gnu/store/pskf3kvk37v2aimlxzwshryd968890qx-linux-libre-5.3.1/lib/modules"
<vagrantc>i guess oldconfig wasn't good enough
<vagrantc>huh. -CONFIG_SATA_AHCI=m
<vagrantc>well, i learned some things. :)
***MinceR_ is now known as MinceR
<tune>can someone help me update wl-clipboard? the current version is broken with the current sway
<g_bor[m]>Hello guix!
<g_bor[m]>tune: what did you try?
<tune>I don't know what to do. I thought there was a command to attempt an update so I've been searching shell history, irc logs, etc.
<tune>it's already packaged so I shouldn't need to write a recipe, I just want to go from 1.0 to 2.0.0_beta2
<g_bor[m]>You could try guix refresh to get a new package definition
<tune>how should I use that?
<g_bor[m]>If you are lucky, then updating the package is just updating the version and the hash.
<tune>okay I found the refresh page in my browser history. attempting it now
<tune>I did it with the recursive argument. it's saying many things "would be upgraded". I guess it's like a dry run then maybe
<tune>maybe should've done without that first, it's stuck
<tune>> /gnu/store/g09y898mfwg1zx7bmfgv6g84805bjxwy-guix-module-union/share/guile/site/2.2/gnu/packages/xdisorg.scm:1691:13: 1.0.0 is already the latest version of wl-
<tune>I get this, maybe because the newer releases are semi-hidden
<g_bor[m]><g_bor[m] "If you are lucky, then updating "> tune: you could then copy the definition from the guix source, for example with guix edit, and manually update the version in it.
<tune>I was wondering about that but felt weird about trying it
<tune>wait, I'm a bit lost
<tune>guix edit is read-only, so I'm not editing the original am I?
<tune>and then I probably have to get a new hash too
<tune>okay got that with guix download
<tune>do I just have to add it to a channel or use --install-from-file or something now?
<tune>this is very annoying, may have to give up
<vagrantc>hrm. no luck with linux-libre 5.3.1 fixing boot on veyron-speedy/asus c201 :(
<g_bor[m]>tune: yes, a channel or intall from file would work.
<vagrantc>not used to not having a serial console to debug with...
*vagrantc has to remember how rockusb works
<g_bor[m]>tune: it is not easy the first time around, but once you are set up it goes really fast.
<tune>I have one thing installed from a channel, but I had a lot of help to get that going
<tune>it sucks because this is all free software, it should just be in the main repo but there aren't enough people contributing to keep up with demand I guess
<g_bor[m]>I am now on my phone and work in my shop, that is why I can't help much more right now.
<g_bor[m]>If you have some time and share the channel link I can document how to get that upstream.
<tune>it's a local channel
<g_bor[m]>I gave these advice to get rolling fast, but if you do packaging regularly, then having a guix development environment is the way to go.
<tune>is there an easy way to put my local repo on gitlab?
<g_bor[m]>Then you can use pre-inst.
<g_bor[m]>tune: you could do a channel setup and override guix channel in the channels configiration
<g_bor[m]>tune: oops, i thought a local guix repo, but yiu ment the channel, right?
<g_bor[m]>You can create an empty gitlab project. Make sure that you don't add any files, like license, readme...
<tune>yeah I think I got it now maybe
<g_bor[m]>Then you will get to a page with instructions on what you do next.
<tune>did git remote add... then git push gitlab master
<g_bor[m]>tune: ok
<tune>since it's normally a part of xdisorg, it's hard to tell what use-modules it should have
<efraim>I hope I'm not overstepping on learning-to-package steps but I bumped wl-clipboard to 2.0.0_beta
<tune>oh wow
<tune>thank you
<g_bor[m]>efraim: thanks.
<civodul>Hello Guix!
<sneek>civodul, you have 1 message.
<sneek>civodul, apteryx says: by the way, Shepherd works fine as an init even if its PID != 1, on Linux systems >= 3.4, where the process can have the PR_SET_CHILD_SUBREAPER attribute set (man prctl).
*civodul is running full core-updates \o/
<civodul>apteryx: what was the context again? :-)
<tune>ugh I broke something and can't guix pull
<tune>I think it's related to my channel, but I deleted the wl-clipboard file and didn't chang the other one, so I can't imagine what the issue is
<tune>unless it's looking at gitlab despite pointing to the local one
<tune>oh maybe I have to commit after the deletion
<civodul>hi wigust!
<civodul>tune: why do you say you cannot pull?
<tune>it fails at the end
<tune>gonna see if I fixed it now
<tune>okay I think I'm good now. my incorrect wl-clipboard recipe that was partially written was an issue
<numerobis>Hi #guix! This is more a guile question than a guix one, but hopefully it's fine to ask here. How do you know in what package a variable (or perhaps the correct name is symbol?) was defined in guix? In python, from module import * is considered bad practice, and it's preferable to write things like MODULE.FUNCTION() in the code, to make it clear that FUNCTION() is defined in MODULE. Is there something similar
<numerobis>for guix? Here is a use case: I installed tree from (gnu packages admin) 4 months ago, and now I no longer need it; thus I remove it from the list of packages in config.scm, but how do I know which package import becomes unnecessary?
<g_bor[m]>numerobis: you can guix package -s it, and it will tell you the location
<lprndn>Hello guix!
<numerobis>g_bor[m]: ok, thanks!
<numerobis>cd /home/urbain
<numerobis>tmux attach -t weechat
<numerobis>arh, sorry, my tmuxinator script didn't work as expected
<numerobis>And another question: is it possible to specify owner and group with the extra-special-file procedure? Or is there another function that enables that? Specifically, I have gitolite hooks to push changes to a backup server, so I'd like to create a .ssh/ for the gitolite user from config.scm. Many thanks!
***Digitteknohippie is now known as Digit
<roptat>the enchant tarball was updated in place :/
<numerobis>cd /home/urbain
<civodul>No such file or directory
*civodul pushed the new news thing \o/
<civodul>it's always a relief when you're done with a patch series
<civodul>and also a bit of stress, wondering how long it'll take before the first bug report comes in
<janneke>sneek: later tell vagrantc: yes, i am subscribed to rb-general
<sneek>Will do.
<janneke>sneek: botsnack
<olivuser>hello everyone. I've got two questions. First, do I have to reconfigure guix in order to have extra WM's that I installed - guile-wm and stumpwm - accessible via the login screen?
<olivuser>Second - even if it may be conflicting with guix's goal - is it possible to install games purchased from GOG on guix?
<civodul>olivuser: for #1, i think so, but otherwise you can also install them in your profile and have a ~/.xesssion file, without needing to reconfigure
<civodul>#2 is not a topic we would discuss here, because Guix focuses on free software
<olivuser>civodul, thanks :)
<civodul>(and i don't know the answer, too :-))
<janneke>"guix substitute: error: host name lookup error: Name or service not known" -- which host name?
<roptat>civodul, should we update the hash in the recipe? I've looked at the difference and it's small, but I don't really get what it does
<civodul>roptat: we can updated the hash, but the commit log should describe what the changes were
<civodul>or maybe a post to the ML
<civodul>janneke: ah, good question
<roptat>it's related to a message on help-guix
<civodul>janneke: certainly one of those passed as --substitute-urls, but the message could be improved
<roptat>somebody cannot download the sources (although it's available of berlin)
<civodul>roptat: so maybe you can send the diff there and refer to it in the commit log
***Digitteknohippie is now known as Digit
<roptat>it might be easier to update enchant to the latest version actually...
<roptat>I wouldn't have to understand the diff :p
<roptat>81 dependents, so it could go to master
<civodul>it's still good to post the diff if it's not too big
<civodul>so we have a track record of bad practices ;-)
<roptat>it looks like a partial revert of which is listed as the commit that created release 2.2.5
<janneke>civodul: okay, tnx
<roptat>civodul, ha it's actually this:
<civodul>oh indeed
<civodul>it's bad that people don't realize the implications of modifying things in place
<roptat>well, it was a mistake
<roptat>rrthomas didn't intend to update the tarball
***emyles` is now known as emyles
***Digitteknohippie is now known as Digit
***Digitteknohippie is now known as Digit
<raghavgururajan>Hello Guix!
<raghavgururajan>Half of the time when I do `guix pull`, the 'guix-packages-base' starts building and always fail. Other half of the time, I do not see 'guix-packages-base' buidling and `guix pull` sucessfully finished. Do anyone have any idea why this happens? Thanks!
<Paprika>hi all
<roptat>hi :)
<Paprika>clawsmail is not detecting aspell dictionaries I installed
<Paprika>is there some way to configure it especially for guix?
<Paprika>never mind
<Paprika>a reboot fixed it...
<Paprika>hi roptat :)
<roptat>probably an issue with environment variables :)
<civodul>there's an ASPELL_DICT_DIR env. variable, FWIW
<nckx>Good morning Guix. roptat: I was just testing enchant 2.2.7. Am I to take it that you're already on it?
<civodul>howdy nckx!
<civodul>nckx: the overdrives are buildin' like crazy again, thanks!
<civodul>do you know what happened to them?
<civodul>they didn't reboot, so it can't be the ssh-daemon service problem
<nckx>civodul: I don't! Isn't that fun.
<nckx>I think the problem was in the modem-router (one of those basically ISP-mandated models).
<civodul>ah ok, i've been there!
<nckx>Which would be problematic going forward but I'll cross that horse when I get to it. If it happens again I'll have more than half an hour, hopefully, to debug and will get more info.
<roptat>nckx, I'm on it, but can't do anything before this evening. I can let you do the patch if you prefer
<nckx>Well, debug, yell at things, unplug it, yell that there's no bug now, thanks a lot, leave.
<nckx>roptat: Unless you know of a gotcha that makes this more than a 2-line bump I'll push after (if) all dependents build. I don't care who fixes it as long as it's fixed soon 🙂
<roptat>nckx, no, it looks easy
<roptat>so go ahead :)
<nckx>Will do!
<nckx>Hopefully with some fresh linux-libre on top…
<raingloom>quick question, is there an easy way to create a NAR file without involving the store?
<civodul>raingloom: nope!
<civodul>what use case do you have in mind?
<raingloom>civodul, i wanna create a tar file locally and submit its checksum, so that if i end up having to send the file itself, people will be able to verify it's the same file, but if a tiny detail (like directory order) changes, it still generates the same checksum
<roptat>directory order will change the content of the tar file though
<roptat>it won't have the same hash, and I don't think a nar file will help you
<raingloom>roptat, doesn't a NAR sort its files by name?
<roptat>ah, yes of course
<raingloom>i think i figured out a solution
<raingloom>guix environment --ad-hoc nix -- nix-store --dump $PWD | sha256sum
<roptat>you can run "guix download" on a directory I think
<civodul>i think we lack "-r"
<roptat>that will give you a store path, and guix publish can serve this
<civodul>is't "nix-store --dump" equivalent to "guix archive --export"?
<civodul>ah no
<civodul>wait, you can do "guix hash -r $PWD" raingloom
<civodul>that does the same as the pipeline above
<civodul>or "guix hash -r -f hex $PWD", to be precise
<raingloom>civodul, indeed. thanks! but I still wouldn't have a way to publish the corresponding NAR.
<raingloom>(or use a different hashing algo)
<civodul>'guix hash' uses the 'write-file' procedure to create a nar
<civodul>it's not exposed at the CLI level
<civodul>we could do that, but i've never felt the need for it
<civodul>so i guess that's a discussion to have :-)
<roptat>it wouldn't hurt to have the option, right?
<civodul>adding support for other algorithms to 'guix hash' would also be nice and easy to do
<civodul>roptat: as an option of an existing command?
<roptat>guix hash --nar or something?
<civodul>maybe rather as part of "guix archive"?
<civodul>because 'guix hash' is about computing a hash
<civodul>what would be useful is "guix download -r" though
<civodul>one could run "guix download -r $PWD"
<civodul>and then thing would be "interned" in the store
<civodul>at which point you could run "guix archive --export" on it
<raingloom>civodul, $PWD might be big though, hence my need for the pipelined solution
<Minall>Hello guix!
<Minall>nckx: o/
<mbakke>I wonder if we should unconditionally add Linux and glibc headers on C_INCLUDE_PATH in a future 'core-updates' revision.
<civodul>hi mbakke!
<civodul>oh, why hard-code these specifically?
<mbakke>because there are a number of packages that fails to build due to -Werror on Linux headers, a recent example is 'perf'
<civodul>oh right, you mean -W vs. CPATH vs. C_INCLUDE_PATH
<civodul>well, yeah
<mbakke>then again, messing with C_INCLUDE_PATH will likely cause all kinds of bootstrapping problems
<civodul>perhaps we can teach GCC that these are "system include dirs"
<mbakke>that would be optimal
<civodul>or have CPATH behave like C_INCLUDE_PATH, but that's evil
<kirisime>How do I make search-patches find a patch available in my own channel?
<mbakke>I think I tried making --with-native-system-system-header-dir point to a glibc+linux header union at one point, without success
<civodul>kirisime: it should just work, but you have to give a file name relative to the root of your channel, i think
<civodul>alternately, you can use 'local-file' instead of 'search-patches'
<civodul>like so: (local-file "./patches/foo.patch")
*civodul has to go
<sirgazil>Hello, do you know how to modify IceCat DuckDuckGo search engine to use for search instead of
<sirgazil>Maybe I'll try "about:config"...
<marius_k[m]>Hello, I get some error when doing guix pull: guix pull: error: build failed: build of `/gnu/store/b7q78lqb0gsn95qdwa6r4hhb1i8pkp8j-profile.drv' failed
<marius_k[m]>is it something common?
<marius_k[m]> * Hello, I get some error when doing `guix pull:`: error: build failed: build of `/gnu/store/b7q78lqb0gsn95qdwa6r4hhb1i8pkp8j-profile.drv' failed
<marius_k[m]> * Hello, I get some error when doing `guix pull`: error: build failed: build of `/gnu/store/b7q78lqb0gsn95qdwa6r4hhb1i8pkp8j-profile.drv' failed
<lfam>marius_k[m]: Is that the only error?
*marius_k[m] sent a long message: < >
<lfam>marius_k[m]: What is the output of `guix describe`?
<lfam>And what command did you run? Just `guix pull` with no arguments?
<marius_k[m]>`guix describe: error: failed to determine origin`
<roptat>sirgazil, I think in about:preferences you'll find search engine parameters
<nckx>sirgazil: I don't think there's an easy way (at least I haven't found one, and I looked). I have a set of custom XML files with my preferred DDG settings, but they need to be added to the browser using JavaScript.
<nckx>Similar to the large selection at
<lfam>marius_k[m]: Okay, how about `guix --version`? I'm trying to figure out how to reproduce the issue to help you
*marius_k[m] sent a long message: < >
<marius_k[m]>I did several guix system reconfigure /etc/config.scm
<marius_k[m]>I also remember I once got out of RAM error (but not sure if it was guix pull or reconfigure)
<marius_k[m]>could that corrupt the system?
<marius_k[m]>Error only happens on root user
<marius_k[m]>when I switch to other user guix pull works ok.
<lfam>marius_k[m]: I'm not sure but I think the issue is too old version of Guix (0.16.0)
<lfam>The switch to Guix 1.0 brought a lot of changes and it might not be possible to go directly from 0.16.0 to 1.0.1
<lfam>Does anyone else know how to upgrade from this older version? There must be some intermediate version that marius_k[m] can use
<marius_k[m]>hmm I always thought guix used rolling release model and I never bothered about versions
<lfam>marius_k[m]: It is a rolling release, but we had to make some breaking changes in `guix pull` to enable new features like channels
<lfam>It's not something we want to do often but it was important to do
<lfam>Are you using Guix on another distro or the full Guix system?
<marius_k[m]>oh. that make sense. I installed it a while ago and I came back just yesterday to play with it. It runs somewhere in virtual server
<sirgazil>nckx: I see, thanks. I found a "keyword.URL" option in "about:config", but changing it does not do what I'd expect :(
<marius_k[m]>I think I will just reinstall it
<lfam>I'm not 100% sure but I think that the `guix pull` interface is versioned now so we shouldn't have issues like this again
<lfam>Okay, that is probably the easiest choice unless someone can recommend an multi-step upgrade path
<marius_k[m]>ok. Thanks for help
<lfam>You're welcome. I hope your next steps with Guix are more fruitful :)
*vagrantc vaguely recalls some tag that was the stepped upgrade
<nckx>sirgazil: Nope, it's not that simple unfortunately. Here's what I use when I install a new IceCat:
<nckx>Maybe you can hack your own perfect search engine out of that 🙂
<sirgazil>nckx: Thanks, that helps. I will :)
*sirgazil is not liking the IceCat experience, sadly...
<nckx>All browsers were written by the gods to punish us. IceCat/FF is the least worst.
<ATuin>i'm trying to update my profile with guix package -u but it always wants to compile some expensive packages like icecat
<ATuin>is there any way i can see why (it's not upgrading the version so i guess that some input has changed)
<ATuin>actually according to the output none of the packages is going to have a version upgrade
<efraim>ATuin: I normally do 'guix package -u . -n' and then I skip some packages like 'guix package -u . --do-not-upgrade=icecat libreoffice'
<ATuin>makes sense
<ATuin>but i'm quite confused why it wants to rebuild all those packages
<nckx>ATuin: Because a dependency changed (updated or otherwise). I can't immediately think of a command to print the exact diff, but there's no need to be confused. That's it.
<ATuin>yeah i understand that but how does the substitutes server works, is gonna be at some point a build ready there
<ATuin>i mean they should have the same inputs as the ones i want to install right?
<ATuin>so it should be exactly the same hash
<nckx>ATuin: At some point, yes, unless the build fails for some reason.
<ATuin>aha nice
<nckx>The hash is computed only over the inputs, yes.
<ATuin>that's the next question then :)
<ATuin>i was looking into but i could not found what are exactly those specifications
<ATuin>which one us used by guix and so on
<nckx>ATuin: guix-master is what you ‘guix pull’. So my first guess (I can't double-check now, sorry) would be that ‘guix pull --commit=6764870’ should give you all substitutes that are buildable. But I might be wrong.
<ATuin>nckx: I see, what are the other specifications used for? are there like different branches then?
<ATuin>and i guess that being a ci each commit triggers a new build that only builds those packages that changed on that commit
<nckx>ATuin: For example, yes. Most of them seem to be branches. guix-modular might be something else, a different set of derivations, dunno.
<ATuin>ok, clear enough i think
<nckx>ATuin: There is absolutely much room for improvement in the CI interface.
<nckx>It's very much a long work in progress.
<ATuin>yeah, i miss some documentation about it
<ATuin>i thinks it's worth at this point to read the code to see what it's doing
<nckx>I wish there were a way to map builds ( back to evaluations or even commits.
<nckx>I don't think there is.
<nckx>Which is my fault for never ever using it 🙂
<ATuin>ahh yes that would be nice to relate somehow what's the status of a specific build for an specific package per commit
<ATuin>that way i could know now what's going on with icecat for example right now
<ATuin>thanks for the explanation
<ATuin>btw is there any API documented somewhere for the CI
<nckx>I don't know…
<nckx>I ‘cheat’ by running my own build farm and ssh'ing into it when I have such questions. That of course doesn't scale and isn't helpful for others. And the damned thing's down now.
<vagrantc>guix really needs a spellchecker on submitted patches
<sneek>Welcome back vagrantc, you have 1 message.
<sneek>vagrantc, janneke says: yes, i am subscribed to rb-general
<vagrantc>i corrected a boatload of them, and now there are a bunch more again :/
<nckx>It happens. I've committed quite a few spelling fixes, other times it just feels like nitpicking.
<vagrantc>does core-updates get rebased? or is it merge-only?
*nckx pushes some typo fixes, thanks for the reminder.
<nckx>vagrantc: Merged; wouldn't rebasing imply force-pushing? (Which is only allowed for wip- branches.)
*janneke notices that sneek doesn't always notice someone waving
<vagrantc>nckx: imagine so; still learning the ropes here. :)
<nckx>I sometimes forget you haven't been here for $ages.
<nckx>I also recently read a sociological paper in which you were mentioned, which made me smile.
<vagrantc>nckx: oh?
<vagrantc>nckx: my curiosity is piqued
<nckx>(Not a new paper, it was explicitly about Free software, I'm sure you're aware.)
<vagrantc>nckx: i'm not sure :P
<nckx>Of course now I can't find the bloody thing. Maybe s/sociological/antropological/, if that rings a bell, although I read it as part of my sociology research 🙂
<nckx>Here we go, apologies for my abysmal memory:
<vagrantc>ah, that one. didn't know people read the credits :)
<erudition>Guess it's this?
<erudition>> Though there are many developers who have taken the time to share their thoughts about Debian and other F/OSS projects, Benjamin “mako” Hill, in particular, has been a close friend and collaborator. I wish him well as he embarks on his own academic career and look forward to future col-laborations. Martin Kraft, Clint Adams, Paul Wise, “vagrant,” Joey Hess, Erinn Clark, and Daniel Khan Gilmo
<erudition>also been great friends as well as teachers over this journey.
<vagrantc>it's a fun read :)
<vagrantc>hah. one of the spelling typos lintian complained about is actually guix fixing the typo.
<erudition>added to my reading list
<nckx>erudition: Yep.
<nckx>Always interesting to read descriptions of your own subculture.
<vagrantc>in the description for python-py-bcrypt: " ... The computation cost of
<vagrantc>the algorithm is parametised"
<vagrantc>is "parametised" some specific terminology i'm not aware of, or should it be "parameterized"?
<vagrantc>lintian suggests "parametrised" ... but that doesn't seem like a word either
<nckx>Deffo a typo for paramete?ri[sz]ed.
<nckx>Alternative forms: parametrize, parameterise, parameterize
<vagrantc>ah, this probably gets into en_US vs. en_GB
<nckx>And then into Oxford vs. not… (being of Greek origin, it would be -z- even in BrE.)
<nckx>Go with whatever you prefer.
<vagrantc>well, if i just go along with lintian's suggestion, eventually i won't see it again :)
<nckx>vagrantc: So lintian is a debian QA tool than can run on any source tree? Would it make sense to package it in Guix?
<nckx>vagrantc: As long as US spelling isn't forced upon us, that sounds rad.
<vagrantc>nckx: i think it only runs on debian packages; this is a byproduct of me working on packaging guix for debian :)
<vagrantc>might be possible to adapt to running on arbitrary source trees
<vagrantc>but it does have a lot of debian-specific logic embedded in it
<nckx>I assume the spell-checking component isn't home-brewn anyway & it just invokes $tool (which might even be in Guix already)?
<vagrantc>nckx: haven't looked deeply into it ... it's a bunch of perl :)
<nckx>That is the correct mass noun to use.
<vagrantc>@item Rec-VCO, a square / rectange oscillator ... rectange -> rectangle?
***jonsger1 is now known as jonsger
<nckx>vagrantc: Sounds like the description of a synth, so yes.
***emyles` is now known as myles
***myles is now known as emyles
<civodul>uh, it's that time of the day when all the build machines are reaching ENOSPC
<civodul>we gotta do something
<nckx>…plug in more USB drives?
<nckx>(No, seriously, is the solution just to manually GC ‘once in a while’ or…?)
<vagrantc>just get one of those subscription-based hard drives.
<janneke>smaller bytes
<nckx>vagrantc: I laugh but then I'm going to search for that and it's actually going to exist and I'm going to hate the world a little bit more, right?
<nckx> /dev/sdaaS
<vagrantc>the problem was switching to 64-bit when we should have been moving to 16-bit
<vagrantc>i swear i fixed a million "This packages ..." before. that seems a hard one to kill.
<vagrantc>i guess it was only 33.
<vagrantc>"allows to" -> "allows one to" just seems to pedantic for me ... but there are a lot of those.
<nckx>Not that I don't sympathi[sz]e, but all that's not that obvious when English is your 2nd, 3rd, or nth language.
<vagrantc>too pedantic...
<vagrantc>nckx: agreed, there are plenty of these that even i had to squint as a native english speaker
<civodul>nckx: on the build machine there's one or two daily GC mcron jobs, but apparently they don't collect enough
<civodul>so at 10PM CEST, we start seeing ENOSPC here and there
<civodul>offloading skips those machines, but eventually there aren't any usable machines left
<nckx>Oh, you were being literal. Wow.
<civodul>until the GC job gets started
<civodul>but we like to shave yaks, right?
<civodul>so to fix that, we need to change the GC jobs on those machines
<civodul>so we need to reconfigure them
<civodul>so we need 'guix deploy' in order
<nckx>I love these stories.
<vagrantc>i've been doing yak shaeving all day.
<lfam>Maybe that is why there isn't a substitute for webkitgtk
<civodul>ah ha!
<civodul>could be :-)
<civodul>on master?
<lfam>Yeah, pulled a few hours ago
<lfam>Oh, looks like it just succeeded a few minutes ago. I guess it takes a few minutes to become available
<lfam>Yup, same derivation. So I will wait a little bit
<civodul>hmm /gnu/store/9laclnnvgb8ih7y45hbjlzx0b59q4k0f-webkitgtk-2.24.4 is available
<lfam>It's this one:
*civodul is not a bot
<lfam>That is something a bot would say...
<janneke>civodul: human-snack
<civodul>like sneek says
<janneke>but only *like*, still not a bot
<civodul>what makes you think but only *like*, still not a bot?
<janneke>looking for confirmation
<civodul>it's the anti-Turing test
<civodul>can one be successfully considered a bot? :-)
*janneke gets uneasy eliza visions
<civodul>M-x doctor FTW!
<janneke>Can you elaborate on that?
<nckx>sneek: botsnack
<nckx>See, bots don't have noses.
<laz>hello, new guix user here!
<vagrantc>nckx: how'd your linux-libre 5.3.1 update go? i got it building, and even installed on one machine, but ... lots of problems with lazy make oldconfig.
<vagrantc>nckx: e.g. sata disappeared
<jackhill>hmm, so I guess webkit builds now (it also build fine on my system with -c 12). Does that mean the parallel build bug is no longer present, or did we just get lucky:
<nckx>vagrantc: It built successfully (without the troubles you encountered but then I am a leet kernel configuration professional), but I want to at least boot it on bare metal before I push. That won't happen just yet.
<vagrantc>qtwebkit is always the killer for me
<jackhill>laz: hi!
<laz>so, i installed guix system, set up my basic environment and now i have some questions, would appreciate some help
<vagrantc>nckx: cool. i have some bare metal i could test with.
<nckx>Welcome, laz!
<jackhill>ask away
<laz>first, i mostly program in haskell and i can't figure out how to set up development environment
<nckx>vagrantc: Which (Linux) arch?
<laz>on my debian machine i use stack, but it does not work here
<laz>there is plenty info about stack and nix integration, but i couldn't find anything about stack and guix
<vagrantc>nckx: x86_64, armhf ... maybe i could dig out an aarch64
<nckx>Stack's not even packaged yet.
<nckx>vagrantc: Oh, OK, I thought you wanted to test specifically on that Veyron thingy.
<vagrantc>nckx: i don't have high hopes for that one, since 5.2.x wasn't working, and i did get as far as booting it
<vagrantc>nckx: er, attempting to boot 5.3.x
*vagrantc wonders about resurrecting the 5.1.x series just to test
<laz>cabal fails to work either
*nckx hasta go for now.
<jackhill>sorry, I don't have haskell experience. Is it the cabal installed via Guix?
<laz>yes, but..
<laz>that's strange
<laz>i've been trying to compile anything for few days and now after i asked it suddenly works
<jackhill>very strange
<laz>actually, cabal fails to work on my laptop
<laz>i installed guix on desktop and asked about problem before i checked if it really exists
<laz>well, i have another question :)
<laz>i have two network interfaces, one for my internet connection, which is managed by dhcp-client, another one for my lan with statically configured address
<laz>the problem is that dhcp-client-service and static-networking-service conflict as both provide sheperd network service
<laz>is there any way to merge these services or to hook into them to redefine provision field of service?
<jackhill>laz: I'm not sure, but might give you some ideas (I believe that answer is that Guix isn't polished in this area yet, but the right building blocks are available).
<emyles>Hi guix
<emyles>Trying to make a package for Open Sans font but get "In procedure copy-file: Permission denied", does anyone know what the problem might be?
<emyles>Package here:
<laz>looks like guix networking service is not quite ready for complex network configuration like having three vlan interfaces, one with dhcp-client, two others in bridge with tun-device with static address on them
<jackhill>emyles: I believe this is a difference with using a git checkout compared to a tarball. You'll need something like:
<jackhill>to make the files writable first.
<jackhill>laz: yeah, unfortunately not yet :)
<jackhill>emyles: I remember that there was some discussion about this "problem" but I don't remember what the conclusion was.
*jackhill has to go for now. Happy Guix-ing everyone
<emyles>jackhill: thanks a lot, I'll try that
<jackhill>emyles: you're welcome, good luck!
<quiliro>What would you guix recommend for a new user as a first step to start to learn Guix and the steps after that in order to become a Guix developer?
<bavier>is there a url url to point to for discussion of 'GuixSD' vs 'Guix System'?
<bavier>that could be shared with maintainers of e.g. screenfetch, ufetch, etc?
*nckx is preparing a PR for screenfetch; why would a URL be needed?
<nckx>It's Guix System, not GuixSD, simple.
<nckx>Oh, I see efraim beat me to it.
<laz>heh, i thought that cabal works, but now it just cant find installed packages
<Minall>Hello guix!
<quiliro>Saluton Minall
<laz>ok, let's leave haskell for later
<laz>jackhill: thanks a lot!
<bavier>nckx: sure; I've noticed though in the past that simply providing a citation is often enough to prevent questioning an back-and-forths