<civodul>vagrantc: this may be related to bc60349b5bc58a0b803df5adce1de6db82453744, which fixed something in this area <civodul>(which may become master Anytime Now, for sure!) <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. <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? ***adriano is now known as Guest26142
<vagrantc>anyone working on updating linux-libre to 5.3.x? <vagrantc>wow... the fsfla.org 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>Note that not all the hashes change across versions. That can be confusing. <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>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 fsfla.org, 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). <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. <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 fsfla.org *nckx .oO One of the official gnu mirrors:// is tripadvisor.com. <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>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>vagrantc: Mine's *still* deblobbing… <nckx>I'm sure you'll win, I'm building *counts* 6 kernels on my laptop. <vagrantc>of course, i failed to update the actually aux-files/linux-libre/* <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>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? <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. :-/ <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 <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 ☹) <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 '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>oops. kernel module not found "ahci" "/gnu/store/pskf3kvk37v2aimlxzwshryd968890qx-linux-libre-5.3.1/lib/modules" ***MinceR_ is now known as MinceR
<tune>can someone help me update wl-clipboard? the current version is broken with the current sway <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 <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>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. <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]>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 <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 <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>tune: why do you say you cannot pull? <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 <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/id_rsa.pub for the gitolite user from config.scm. Many thanks! ***Digitteknohippie is now known as Digit
<roptat>the enchant tarball was updated in place :/ *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 <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 <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 <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 ;-) <civodul>it's bad that people don't realize the implications of modifying things in place <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>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>clawsmail is not detecting aspell dictionaries I installed <Paprika>is there some way to configure it especially for guix? <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>nckx: the overdrives are buildin' like crazy again, thanks! <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). <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 🙂 <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? <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? <raingloom>guix environment --ad-hoc nix -- nix-store --dump $PWD | sha256sum <roptat>you can run "guix download" on a directory I think <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>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. <civodul>'guix hash' uses the 'write-file' procedure to create a nar <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? <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 <mbakke>I wonder if we should unconditionally add Linux and glibc headers on C_INCLUDE_PATH in a future 'core-updates' revision. <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 <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" <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") <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]> * 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? <lfam>marius_k[m]: What is the output of `guix describe`? <lfam>And what command did you run? Just `guix pull` with no arguments? <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. <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]>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) <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 :( <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 <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>Maybe you can hack your own perfect search engine out of that 🙂 *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>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. <nckx>The hash is computed only over the inputs, yes. <ATuin>that's the next question then :) <ATuin>i was looking into ci.guix.gnu.org 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. <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>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>btw is there any API documented somewhere for the CI <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. <nckx>(Not a new paper, it was explicitly about Free software, I'm sure you're aware.) <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 🙂 <vagrantc>ah, that one. didn't know people read the credits :) <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>hah. one of the spelling typos lintian complained about is actually guix fixing the typo. <nckx>Always interesting to read descriptions of your own subculture. <vagrantc>in the description for python-py-bcrypt: " ... The computation cost of <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 <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. <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? <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>"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>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>so to fix that, we need to change the GC jobs on those machines <lfam>Maybe that is why there isn't a substitute for webkitgtk <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>That is something a bot would say... <civodul>what makes you think but only *like*, still not a bot? <civodul>can one be successfully considered a bot? :-) *janneke gets uneasy eliza visions <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. <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. <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. <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 wonders about resurrecting the 5.1.x series just to test <laz>cabal fails to work either <jackhill>sorry, I don't have haskell experience. Is it the cabal installed via Guix? <laz>i've been trying to compile anything for few days and now after i asked it suddenly works <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? <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? <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 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 <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 <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