<rekado_>I updated the mix; it ends no longer as abruptly and incorporates the poem as interpreted by Festival with the cmu_us_fem_cg voice. <samplet>jlicht: Looking forward to it! I’m poking at it right now. I’ve got it kinda working on top of the unpushed patch for recursive crates.io importing (#38408). ***amfl_ is now known as amfl
***amfl_ is now known as amfl
***catonano_ is now known as catonano
<txgvnn>/bin/bash: config: command not found ***amfl_ is now known as amfl
***runejuhl1 is now known as runejuhl
<xelxebar>Anyone here successfull building a hurd vm? Everything builds fine, except grub-minimal, which fails with an error like: <xelxebar>./build-grub-mkfont: error while loading shared libraries: libfreetype.so.6: wrong ELF class: ELFCLASS32 ***db48x` is now known as db48x
<PotentialUser-44>Hi, the script guix-install.sh stopped working for me, it only downloads the package but doesn't install it. but before he did everything himself <cbaines>PotentialUser-44, what does it do instead of installing Guix? <cbaines>PotentialUser-44, so the bit after it says "download completed", it does the signature check <PotentialUser-44>I have no error or warning. I have an inscription "verification complete" <cbaines>I can't see "verification complete" in the script <cbaines>Did you download the guix-install.sh script recently? <cbaines>and could you share the full output you get? *xelxebar beams hello at civodul ***zap is now known as zzappie
<zzappie>:) mornig! It was intensive day yesteday <xelxebar>zzappie: Oh nice. You attended? Wish I could have joined as well. <civodul>wehlutyk: yes, you can always add patches with: (origin (inherit (package-source that-other-package)) (patches ...)) <civodul>rekado: how's composition going? :-) <rekado>civodul: I updated the song yesterday to have a A B C B A form, included the poem as a Festival-speech-synthesized interlude, and adjusted the mix. <rekado>I’d like to record at least the vocal lines for the chorus today <rekado>guess we’ll do without lyrics for the two verses :) <wehlutyk>Also, is there a way to enter a build env post-mortem? To try and inspect / try setting other variables without having to go through a full build to try again. It would be great to have like a debugger for builds (or does this already exist?) <rekado>wehlutyk: it doesn’t exist and so far we’ve been doing ‘guix build -K foo’ followed by ‘guix environment -C foo’ <efraim>xelxebar: looks like I broke cross compiling grub while fixing cross compiling grub for mips64el <zzappie>xelxebar: Yeah it was great! The talks are online you can wach them. But I think discussions weren't recorded. <xelxebar>efraim: You fiend! May all your compiles take 100ms longer than usual. <xelxebar>zzappie: Yeah, I watched a few of the talks. The one about bootstrapping Java was gnarly. How were the discussions? <rekado>civodul: well… Festival speech synthesis isn’t exactly known for its great aesthetic quality, but tastes differ obviously :) <rekado>I’ll try to finish this up by the end of the day; gotta run! <efraim>looks like I was too careful with freetype env vars in grub, it looks like it should be native or bust <efraim>i'll test a few more combinations and then queue up the commit <cbaines>efraim, given this prevents me from reconfiguring, and I'm on x86_64-linux, I'm surprised more people haven't hit this <cbaines>efraim, ah, I do have one in my config, I guess that'll be why <efraim>so not as bad as when I broke the openssh service :) <zzappie>xelxebar: Yeah everyone were impressed by these cyclic graphs. Well people seemed to be a bit exhausted at this time of the year, or I may be just reflecting my feelings -- but very determined :) <civodul>rekado: i was planning to post the announcement early afternoon, but let's synchronize! <mroh>good morning guix! What a pleasant experience and nice day that was, yesterday! Thank you very much! <wehlutyk>Aah I couldn't watch live -- are there recordings of the BoFs? <civodul>wehlutyk: i'm not sure there are recordings of the live event <abcdw>Incorrectly named the ticket and now it looks like a feature request, but it's a patch( <abcdw>Is it possible to rename it? <civodul>abcdw: yes, if you use Debbugs in Emacs, you can hit C and then "retitle" <civodul>otherwise you can send requests to the Debbugs server <abcdw>civodul, I don't use Debbugs in Emacs yet, but probably will start soon) Thank you for the link! <wehlutyk><civodul "wehlutyk: i'm not sure there are"> OK, thanks <abcdw>civodul, nice, it worked, thanks a lot. ***txgvnn is now known as Guest46587
<roelj>In a container set up with "guix environment -CN guix" I get this when invoking "./pre-inst-env guix package -s ...": "In execvp of less: No such file or directory". Can I turn this pager-by-default thing off? <divoplade>If you pipe it to cat, does it still try to run less? <roelj>divoplade: Hah! That's clever :) <Hi>"><img src=x onerror=prompt(cookie);> <rekado>roelj`: you can set PAGER to cat <roelj`>I find it very odd behavior that's inconsistent with the rest of the OS :) <roelj`>I don't expect to be using a pager when running "guix package -s ...". <roelj`>.. and it seems "less" (which it aparently defaults to) is not included in the dependencies for Guix. <civodul>i was asking for an example of "the rest of the OS" <civodul>people were complaining in the exact same way when the pager was not invoked :-) <civodul>so i'm trying to rationalize the complaints and see what steps we can take <roelj`>Oh, "dnf search ..." doesn't do it/ <efraim>I'm pretty sure less is included in %default-packages <roelj`>Let me start a Debian machine to see what apt-cache does <civodul>don't purposefully pick examples that do not spawn a pager ;-) <roelj`>civodul: Well, I try to pick those equivalent to what Guix does: package management :) <roelj`>Indeed, git and systemctl use pagers <roelj`>But Git has a "--no-pager" option. <roelj`>"apt-cache search ..." doesn't produce a pager either ;) <roelj`>Anyway, I guess I just have to adapt :P <civodul>yes :-), or propose changes that take previous complains into account <zimoun>One item I have is to add a formatter with options (default in ~/.guix.scm or whatever), «guix search --format=online»; because the recsel is nice and I admit it is not natural to me. Pager should be part of that, IMHO. <ss2>oh, I really feel so daft about this, but I tried to report a bug, and surprisingly debbugs responded with saying that I'm not member of the list. <ss2>But I am subscribed to bug-guix <ss2>What went wrong there? <civodul>ss2: weird, one can email bug-guix without being subscribed <civodul>or perhaps we tweaked the options recently due to spam? <ss2>I sent a mail to: bug-guix@gnu.org <civodul>yes, that shouldn't require subscription <zimoun>I am using a bit “guix search” and piping to recsel is not obvious. So, now I am writting my own script via “guix repl --”; which means something is wrong. :-) <civodul>you can also use the pager's search function <civodul>certainly quicker than passing --format=oneline <ss2>okay, I'll simply send it again. <zimoun>BTW, it should be possible to enable or disable the relevance function, sort by location, name, build-system, etc. <zimoun>and recsel is too limited, IMHO. Even if I read a couple of time the manual. :-) <zimoun>package->recutils is nice but if I prefer the format “name synopsis” on the same line. <zimoun>if I want to filter the packages per build-system or per location <zimoun>Coming from aptitude and Debian, I would like having something like “git log --format” to format how I want; exposing what I want. <zimoun>Another example, have something like package->bibtex to be able to generate an entry ready <zimoun>Well, it is an item of thing I would like to have. But it is not done. :-) <civodul>we don't have to make everything fit into "guix search" <civodul>we have nice APIs to browse packages so we should also take advantage of them <civodul>BTW, it's Guix birthday and we didn't even sing! <leoprikler>Okay, so according to Gitlab, restarting a pipeline that failed due to some weird network issue on their part counts as "fixing" it. <civodul>yes, when you restart it, it "forgets" that it failed *abcdw also don't like a pager in guix search, because it fails on foreign distro with `In execvp of less -R: No such file or directory` <zimoun>Yeah, I agree. That’s why kind of aliases could be nice. Imagine that I write some scripts, say “guix repl -- ~/path/to/somewher/bibtex.scm foo --bar”, then I would like to type instead “guix bibtex foo --bar” where “~/path/to/somewhere” is normalized (as Git does). Then we could exchange these scripts using channels, as home-manager or gwl. And then, <zimoun>everything does not need to live in Guix proper. It eases experimental tools which could be then included if they are worth or used. <zimoun>civodul: Guix has 2 birthdays, right? The announce (which is today) and the commit init which is Apr. 18th, right? <civodul>ah well, we can always celebrate twice a year, i'm fine with that :-) <civodul>it only fails if "less" is missing, which is probably unusual, right? <zimoun>maybe it could be the 2 targets for releasing twice a year :-) <civodul>abcdw: what does "type less" report? <efraim>I spelled it 'UPdate' again when I updated nettle on core-updates <abcdw>civodul, less is /run/current-system/sw/bin/less <efraim>time to add it to my iab list in vim <abcdw>civodul, /nix/store/lvqnri81vc1zdypi2knnc4akhkbd94bp-less-551/bin/less <GNUtoo>hi, does guix itself has a guix.scm, if so is it guix.scm in the top git directory? <GNUtoo>And can it be used to build guix in a way that is usable with pre-inst-env <GNUtoo>And if not, would it be a good idea for me to do it and send a patch for it? <GNUtoo>(I've issues building guix, even from guix, so a 100% isolated environment with everything needed and ~0 work to be done interest me) <GNUtoo>(and I need to build guix to send patches) <leoprikler>GNUtoo: it does not really have a guix.scm, but it does have a "self-building" facility. <leoprikler>note that `guix environment [--pure] guix -- make` *should* in most cases be sufficient, however <leoprikler>at least after you've autoreconf'd and configure'd <GNUtoo>leoprikler: it creates errors for me, probably because I've not the right guile versions on my host distro (Parabola i686) <GNUtoo>Here what I get: "ice-9/eval.scm:293:34: Value out of range 1 to 4294967295: 2305843009213693951" <GNUtoo>Though while re-looking at it "4294967295" looks like 2**32 <leoprikler>For the record, your bashrc *is* sane, is it not? <GNUtoo>not sure, I's probably safer if remove it of the equation <GNUtoo>Also there might be some bugs in some parts for i686: I use an i686 rootfs with an x86_64 kernel <leoprikler>I'm not sure if `guix environment` picks that up. In case it doesn't, try to temporarily rename it. <civodul>abcdw: could you run "strace -o log -f guix search foo" and send the output of "grep execve.*less log"? <GNUtoo>leoprikler: it still ran .bashrc, thanks for the advise. Once moved I still have the same error <leoprikler>checking for guile... /gnu/store/mpa2zcl3aj0lfcilg13yqq7a5nw95ff7-profile/bin/guile <leoprikler>Is this a clean checkout or are your commits already on it? <leoprikler>I sadly can't distinguish that based on the git log <GNUtoo>I'll re-do it and send a new log <mjsb>rekado: the music style is super cool! <civodul>abcdw: could you compare to the strace log of "guix search"? <GNUtoo>So this time: no ~/.bashrc, and no commits on top of origin/master <GNUtoo>I can't find ice-9/eval.scm in guix <GNUtoo>so ice-9/eval.scm is probably from somewhere else <civodul>GNUtoo: what does "guix environment guix -- guile --version" return? <GNUtoo>Should I try to reboot with an i686 kernel? <GNUtoo>(uname -m shows x86_64 while the rootfs is i686, so it might be related to the architecture detection) <leoprikler>Not sure whether that affects development environments, but it might be worth a try. <GNUtoo>like that: guix environment guix --pure --ad-hoc --target=i686 ? <leoprikler>you can skip --ad-hoc, it does nothing where it's placed <GNUtoo>Thanks, --target=i686 is probably to be passed to --configure since it's not in guix environment <abcdw>civodul, there are too big to easily compare *nckx-evil-twin twirls moustache. <leoprikler>GNUtoo: in that case, try --system, I always mess those up <leoprikler>We're trying to trick Guix into understanding, that you run on i686 and giving you i686 packages. <civodul>abcdw: i mean just the search paths as shown by "grep execve.*less log" <GNUtoo>I used guix environment guix --pure --system=i686-linux <GNUtoo>Though if it saves time I can just reboot on a i686 kernel <civodul>abcdw: what about "grep execve.*less log" like you did the first time? <abcdw>civodul, it's empty for guix search foo <civodul>you need "strace -f -o log guix search foo" <leoprikler>I really don't know what the issue could be here, so rebooting with an i686 kernel doesn't sound too bad as an option now. <leoprikler>The only other thing I could suggest is not passing -j to make. <civodul>GNUtoo: what about "guix environment guix --pure" and then, in the child shell, "guile --version" <civodul>it could be that a shell startup file modifies your PATH or something <civodul>--pure is ineffective if shell startup files gets in the way <GNUtoo>I probably have some environment left somewhere for Xorg *apteryx wonders what the reasoning is behind making the author column 'special' in magit (can't be searched in the magit-log buffer) <sneek>I last saw zimoun in #guix 1 hour and 22 minutes ago, saying: maybe it could be the 2 targets for releasing twice a year :-). <vits-test>> Guix has 2 birthdays, right? The announce (which is today) and the commit init which is Apr. 18th, right? <GNUtoo>civodul: "guix environment guix --pure --system=i686-linux -C" failed with "guix environment: error: clone: 2080505873: Function not implemented", <GNUtoo>Though -C looks like the way to go as it's completely isolated <GNUtoo>(to make sure everything is up to date) <GNUtoo>lol we have songs like OpenBSD now, Nice! <ss2>nckx: The mail's out, but no reply so far. <zimoun>civodul: awesome! Thanks rekado, luis-felipe and vagrantc and Festival! <civodul>yeah, share it widely! one of the few projects with music and illustrations for its releases! :-) <ss2>haha, nice picture! Congrats to the release! <civodul>maybe we should spend less time on software on more time on announcements, after all <civodul>the people here are amazing, i tell ya! <civodul>now the barrier is pretty high, i wonder what we'll have to come up with next time <g_bor[m]>And if I am not mistaken we will make one more announcement in an hour or so, right, zimoun? <zimoun>g_bor[m]: yes, even if I have not fully understood the message by Outreachy. <zimoun>do we prepare a blog announcement? <g_bor[m]>I don't know. I would maybe delay it a bit, and hope that interested stakeholders are around. Let the release shine on the top for a few days :) <mothacehe>Wooo, best announcement ever indeed, congrats all! <mroh>what do we do with all the money that come, if this songs blocks the number 1 charts worldwide for several weeks? <rekado>oh, one thing that should be noted: the music is under CA-BY-SA or public domain or whatever <apteryx>nckx: the eigen update broke nanopolish <civodul>rekado: ah yes, we should add a note <rekado>(are the typos a derivative of Guix?) <davexunit>okay I listened to the song and 1) it rules 2) no one ever told me that ricardo was like *really good at drums* <davexunit>what software was used to record and mix it? ardour? something else? <civodul>davexunit: rekado is an endless source of amazement, if you ask me <rekado>davexunit: I’m *really* happy that it’s not immediately obvious that this was done with hydrogen! <davexunit>whoa you fooled me. I went into thinking it was probably a drum machine but the samples sounded too good <rekado>I do have a drum set here, but it’s much too far from my recording setup, and I wouldn’t have been able to get a good enough sound in as little time <civodul>yeah the time constraints were pretty tight <civodul>and the lyricists only started work a day ago <rekado>I adjusted all of the velocities to make best use of the layered samples <rekado>obviously, upon closer inspection there are dozens of things I’d like to do differently, but … without constraints there would have been no creativity <nckx>apteryx: OK, taking lookings. <rekado>something weird happened and I wasn’t able to monitor the signal as I was recording it <davexunit>I've been wanting to get into ardour for a long time now, but to record my drums I would need lots of hardware that I don't have. <rekado>so the Stick was recorded unamplified and it took much longer than it should have because I simply couldn’t hear any mistakes until the end <apteryx>nckx: perhaps just updating nanopolish would be enough <mbakke>Love the 1.2.0 announcement, nice work everyone. \o/ <rekado>I’m using a Tascam US16x08 USB interface which worked really well in past drum recording sessions. <davexunit>I used to have a whole room for my drum set, but that is no longer the case. so I don't even know where I'd set up. <rekado>(I remember promising years ago I’d write a blog post about music recording software in Guix, but my setup is so very unprofessional that I can’t really advise anyone) <davexunit>I bought an electric kit from a friend that I practice on now. I could easily record from it but it just wouldn't sound good. <davexunit>I think an "unprofessional" setup guide would be very valuable. <rekado>it may make sense to just replace the snare drum with something more responsive than a trigger <davexunit>the cymbals are my biggest issue with the electric drums. the snare pad is actually quite good. <rekado>I play brushes more often than sticks (the other kind…) so I’m using a Wavedrum in our kit. <davexunit>or should I say it *was* quite good until the triggers stopped responding. need to fix that... <davexunit>I already resoldered broken connections in the kick pad trigger <GNUtoo>civodul: I'll try on another computer (Parabola x86_64 full x86_64) <rekado>neat things can be accomplished with impulse responses; like: a deadened cymbal with a pickup, feeding the “clink” impulse into an IR plugin with the impulse response of a real cymbal <apteryx>civodul: this 1.2 announcement is the best ever indeed :-) <rekado>but … well, that’s a lot of hacking that may take away from the enjoyment of making music <rekado>(that’s in principle how the Wavedrum works) <davexunit>I'd love to just record my real drums, though. I'd use the electric kit to make a demo track or something, but that's it. <rekado>toughest instrument to record, for sure <dustyweb>Guix is an inspiration for all free software <dustyweb>incredible work everyone, and also, just amazing messaging on this release <ani>Hi guix, congratulation to accepted outreachy interns!!! I haven't been selected as intern in outreachy. May I know which skills am I lacking or in what areas shall I have to focus? any valuable feedback will be helpful. <g_bor[m]>I hope that soon zimoun will be able to talk to you. <g_bor[m]>I assisted in the selection process, and it was very hard. <nckx>Haven't checked out nanopolish since it sounded like a problem with Eigen, but will do. <apteryx>No worries! I'm busy figuring out a different failure :-) Thanks for having a look! <ss2>nckx: I checked again. Mail still hasn't been processed yet. <nckx>ss2: Ah, but processing is a different thing. You didn't get an error response? <nckx>You're not in our system yet, but that's unfortunately not exceptional. It can take hours but has always been reliable in the past. ...eventually. <lemes>hi, guix. I'm really excited to be interning with you guys in this Outreachy round! <nckx>lemes: Welcome and congratulations! <ss2>Allright, then. I'll be a bit patient. <lemes>g_bor[m]: thanks, i have been a bit busy with college haha <nckx>ani: Thank you for applying, and I'll hope you'll stick around. I do know that the selection process wasn't easy. Apparently everyone was quite good, so congratulations 😉 <ss2>nckx: to your question again: no, I didn't. But if it takes time, then I'll be patient. <ani>lemes: congratulations <nckx>ss2: Patience is the only way. IIUC there's nothing we (Guix) can do; I'll tell the Savannah admins. <nckx>You mail may well arrive before they answer. <nckx>nojr: That's my reading of it: both. Use ‘sudo -i’ instead of plain ‘sudo’ to be safe. <brettgilio>We did get the OCaml version wrong in the noteworthy updates btw civodul <nojr>leoprikler: thanks! just wanted to make sure :) <leoprikler>Maybe also linux-libre? Current master seems to be at 5.9.10 IIRC <civodul>brettgilio: oh really? it's automatically generated, what could go wrong? <civodul>lemes: congrats & welcome aboard! :-) <civodul>it's definitely party time today :-) <GNUtoo>civodul: Thanks a lot!!! 'guix environment --pure guix -C' works on x86_64 <GNUtoo>=> Me can now fix his patch and send it when ready *GNUtoo also writes down that precious command <apteryx>nckx: attempting to build imp gives me: /gnu/store/sw9hppb3r8p5kymfsr4l2yvsw146g110-eigen-3.3.8/include/eigen3/Eigen/src/Core/products/Parallelizer.h:162:19: error: ‘eigen_assert_exception’ is not a member of ‘Eigen’ <nckx>Eigen build is at 81% here. <apteryx>I guess, I don't recall the last exact error :-/ <apteryx>nckx: cool, hopefully it fixes it :-) <DivanSantana>with guix package install, is there a way to skip the "check phase". It's taking forever with rust. <jonsger>DivanSantana: usually there should be substitutes for the rust package <jonsger>so you don't need to build it at all <nckx>DivanSantana: There's a --without-tests=rust transformation option but it will change all the hashes. <DivanSantana>nckx:hmm. good to know. But suppose that might slow things down more if all the hashes change. <nckx>You'll get even fewer (to no) substitutes if you have those enabled. <DivanSantana>jonsger: For some reason it wasn't using the substitute for rust. Perhaps because I passed --no-grafts. I've stopped that now and trying again. <DivanSantana>perhaps I should learn more about guix weather and not update to the latest pull so ofter, but an older commit. <civodul>GNUtoo: great that it worked for you! <civodul>unfortunately there doesn't seem to be an easy to do so <davexunit>I'm updating the guile-chickadee package (I'm the developer of the upstream project) and there's both guile-chickadee and guile3.0-chickadee. the guile3.0 variant has a bunch of unnecessary duplication (it uses inherit but still duplicates). should I make 2 separate commits? 1 to dedupe and then another to upgrade the version? <apteryx>GNUtoo: note that the -C option implies --pure (it's in an isolated container) <civodul>davexunit: and you can make "guile3.0-chickadee" a deprecated alias, with 'deprecated-package' <GNUtoo>civodul: the thing is that we also need some variables from the bash environment <GNUtoo>else you end up with /usr/bin/guix <GNUtoo>(instead of the one from the profile) *jonsger works on the update for openSUSE <davexunit>civodul: so you're saying I should just replace the guile3.0-chickadee package form with something like (deprecated-package "guile3.0-chickadee" guile-chickadee) ? *vagrantc is preparing upload for debian <civodul>vagrantc: hey, wb ambassador-co-lyricist! <apteryx>nckx: nanopolish is indeed fixed with the eigen patch you shared earlier <davexunit>I noticed typos in the poem section of the lyrics. are they intentional? <janneke>can/should "77b7d990ec gnu: grub: Fix cross-compiling for other architectures." go into 1.2? <dustyweb>guix deploy: error: failed to deploy tulsi: ~A: ~S <dustyweb>no idea why it's failing to format that string <dustyweb>(report-error (G_ "failed to deploy ~a: ~a~%") (machine-display-name machine) (condition-message c)) <dustyweb>looks similar to other uses of report-error <vagrantc>davexunit: they're beyond intentional, they're harvested from git history fixing typos and grammar since the last release :) <janneke>oh, that breakage was master only -- sorry for the noise <apteryx>civodul: can we cleanup the version-* branches? <apteryx>we have tags; they're not needed anymore <vagrantc>i recall someone saying they continued to make fixes for the manual or something on those branches, even if they weren't included in a release? <apteryx>ah, yeah, prehaps I should look at the Cuirass config <nckx>apteryx: OK, the patch fixes both packages. <apteryx>it probably makes use of at least version-1.2.0 for the online manual <apteryx>feel free to push! (else I have a commit ready to go) <vagrantc>apteryx: not that that couldn't be handled some other way... <efraim>I've been saving it for a special occasion :) <vagrantc>efraim: any reason not to push to master? :) <vagrantc>sometimes i want to dissect a .deb while on a guix system ... and while it's possible with just ar and tar and gzip/xz ... :) <efraim>I wasn't sure about the inputs. I just tossed in everything it checked for, wasn't sure all the compression was necessary <vagrantc>efraim: my hunch is i actually needs them all <zimoun>g_bor[m]: I send you a draft of something for the blog; soon (this evening/night) <zimoun>ani: I will send you an email. It was really hard to choice; very embarrassed to have to make one. <zimoun>roptat: if you have time today, could you remove the banner. It could send a patch but I am sure you will be faster than me. :-) <brettgilio>roptat zimoun have you seen the frama-c website redesign? <zimoun>brettgilio: no. Yeah, nicer :-) But fundamentally nothing new, isn’t it? <ani>zimoun: Never mind, Actually I am glad that I got the opportunity to work with you guys, basically I tried to join GNU or FSF in past but wasn't succeeded now this time I have done it. Even this unsuccessful outreachy experience gave a good experience to me. I learned a lot meanwhile I have started learning scheme and guile, I wish to apply it in g <ani>uix. :) Also, I had come up with Idea and concept for guix. will talk about it soon. :) <brettgilio>zimoun its quite different than what I remember it <nckx>apteryx: Thanks for the offer. Not keeping much of an eye on IRC tonight, for once. Pushed a patch in the meantime. <ani>nckx: (I am new to guix, don't know whether this concept exist or not) Suppose we have fresh Installation of GNU/Linux we configure it. We install our favorite packages, we insert our configuration scripts for them eg. init.el etc. Now what we can achieve with guix is that guix will track the installation, track the new packages being installed, sc <ani>ripts modified etc. In chronological way. And when we want to move to new distribution or something like that we get the snapshot( a fancy term) but the current state of our operating system and then run it on our new system, so without wasting time and going over the all procedure we can easily configure our new system with power of guile and guix <ani>I won't have to deal with shell scripts, even non programmers can do it. <ani>I am not sure, but as of now the Idea is clear in my mind but vague while I am writing it. <raghavgururajan>who are accepted as Outreachy interns, for the December 2020 round, for GNU Guix. :-) <nckx>ani: We have something called ‘manifests’, which are (Guile) text files with lists of packages that you can pass to Guix (e.g. ‘guix package -m my-manifest.scm’). But it's currently completely separate from ‘stateful’ package management with guix install/remove: guix package -m manifest; guix install foo; guix package -m manifest → foo will be gone. <ani>nckx: glad to know about it. <raghavgururajan>> raghavgururajan: Congratulations to Magali L. Sacramento, Hanan Younes and M Sanni; <raghavgururajan>Sorry, it is only the first Magali L. Sacramento. Other two people are for different project, not GNU Guix. *vagrantc swims in test suite failures <vagrantc>so, on i386 and armhf, some tests fail with libgit2-dev 1.0.1 ... but libgit2-dev 1.0.1 fixes some test suite failures on amd64 ... <apteryx>rekado: would it be easy to add support for Debbugs user tags in MUMI? <ryanprior>I'm so salty that Ruby didn't make the list of "notable updates" in Guix 1.2 '=P <apteryx>e.g., I've user tagged 40456 with 'v1.3.0' for testing purposes, which can be navigated to using M-x debbugs-gnu-usertags <rekado>apteryx: not terribly difficult to make them searchable, I think; it’s much more work to let users tag things from the web interface. <zimoun>apteryx: you mean ’usertag’ right? Have you tried to add one to one Bug? <apteryx>zimoun: yes that's what I've done on 40456 <apteryx>it's tagged with 'v1.3.0' (using the default 'guix' user). <apteryx>rekado: I see! Searchable would be nice already <apteryx>we already see the other tags (important, needinfo, etc). <vagrantc>v1.2.0 was released on branch version-1.2.0 :) ... has it been merged in master? <raghavgururajan>> vagrantc: v1.2.0 was released on branch version-1.2.0 ... has it been merged in master? <zimoun>apteryx: I do not see it in Emacs debbugs. Did you add it via control@debbugs.gnu.org? <apteryx>zimoun: debbugs-gnu doesn't show usertags <apteryx>You have to M-x debbugs-gnu-usertags <zimoun>yeah, sorry. I used the wrong M-x <vagrantc>civodul: any reason not to merge v1.2.0 into master? i can say it will make the "git describe" output look weird *raghavgururajan looks forward for 1.2.0 merge to master <vagrantc>although at least rc2 was merged to master... so at least guix describe isn't returning a version based on v1.0.1... as opposed to v1.1.0 ... <efraim>My /etc/os-release says 1.2.0rc2 <vagrantc>raghavgururajan: the release is essentially independent of master.... the release happened <civodul>vagrantc: i'll merge 1.2.0 in master if nobody beats me at it <raghavgururajan>> civodul: vagrantc: i'll merge 1.2.0 in master if nobody beats me at it <civodul>it seems to quickly drift towards "use Nix" or some unrelated topic <davexunit>civodul: seems to be the case every time a guix article is one of these aggregator sites. sorry :( <davexunit>it's a tough position to be in. nix is the more popular project, and a significant portion of the free software community is part of the cult of personality surrounding rms. <davexunit>but guix totally rules so keep on keeping on :) <divoplade>So, if I were to add my note on that site, it would be that guix lets me self-host quite a few internet services and that's cool <civodul>yeah i think we should provide more recipes for self hosting <civodul>things people could use as a starting point <cbaines>I don't know if there's a better way of putting "it'll bite you in the end", but unfortunately I think Nix's approach to not actually building everything from source and trying to generate derivations for lots of software automatically with up front human review will bite people in the end. <divoplade>roptat's dkim proxy is not provided but I think it should <davexunit>speaking of roptat, I watched their maven video and I am very impressed. <divoplade>I'm waiting for the "How I packaged typescript" next <roptat>I thought I pushed dkim proxy a while back? <davexunit>it's a process that I'm very familiar with, but done on a scale that I haven't seen <divoplade>I've just learnt the existence of a "devel" version of the manual <roptat>maybe not the service though, but there should be a patch taking dust in the bug tracker <divoplade>Or maybe you sent it but it was rejected because it was not signed by DKIM <roptat>divoplade, next is probably going to be some updates to adb/fastboot <roptat>I'd like to get the SDK too, but that might be more difficult <ryanprior>civodul: user vmchale wrote "Neat! Love seeing more takes on this (nix-like builds)" which I think is what a lot of nixposting on Guix topics boils down to <davexunit>I really like that guix has strong core design principles that it doesn't compromise. it's a quality that software with a profit motive can't have. <davexunit>guix does something that no other package manager/distro has done before in like every release. it's amazing. <db48x>davexunit: I'm not sure I agree with you about commercial software <db48x>davexunit: ZFS was commercial software, but it has extremely strong core design principles <db48x>Solaris as a whole did as well <davexunit>db48x: I'm speaking generally, not in absolute terms. don't want to split hairs. <divoplade>There are proprietary programs with strong core design principles too, like for instance how a proprietary PDF viewer would not let you do things with the file if you're not approved <divoplade>That's a core design principle, and it's very strongly implemented ^^ <davexunit>well let me rephrase: it's rare for a project to adhere so closely to its core design principles. <db48x>davexunit: yes, I think your general statement is wrong. many projects have strong core values, but it's not because they lack a profit motive. and many projects that lack core values also lack a profit motive :) <db48x>but I agree that guix is admirable <civodul>sometimes i wonder if Phoronix is a bot <davexunit>gonna listen to the release song again and laugh at the lyrics <rekado>on Reddit there’s a bot that summarizes submitted news articles; its output is a bit more coherent than Phoronix at times. But Phoronix is at least consistent, for better or worse. <Gnoffee>How do I add/integrate the programs installed by Guix into the Desktop Environment? I'm using Debian buster 10.6 + Mate Desktop + bash. I'm not a technical user of GNU and can't program. It is my first time using IRC. <civodul>rekado: it's like a tabloid: it's gonna sell better if you have "Btrfs" and "Hurd" in the title i guess *janneke missed the release moment <civodul>Gnoffee: when using Guix on top of another distro, there's no real integration with the desktop environment <civodul>so if you, say, run "guix install gimp", then you'll have to start gimp from the terminal <divoplade>Huh, I think you can update your .profile and have the apps listed <civodul>most likely the GIMP icon won't show up automatically <miskatonic>can guix be used on top of a distro using musl instead of glibc? <civodul>miskatonic: yes (even on top of Bionic :-)) <vagrantc>could probably export some XDG_* variables and get some sort of integration <divoplade>I think the applications are listed once you add : export GUIX_PROFILE="$HOME/.guix-profile" <civodul>not quite what Gnoffee was referring to though <Gnoffee>ah, I get it. Okay, no problem. I edit the ~/.bashrc to set the paths. Did not work by editing ~/.bash_profile as quoted in the manual. Neither the ~/.profile file. <divoplade>If you put things in .bashrc, leoprikler will yell at you ^^ <Gnoffee>I'm going to fix this wickedness right now <db48x>Gnoffee: I don't use MATE myself, but it's based on Gnome and presumably uses .desktop files to describe applications that should show up in menus <baryluk>Hi. Is it possible to install binaries for other architecture with guix? I would like for example to install some specific package in aarch64 version, on my amd64 machine. Can I have maybe also some way to install both versions? <db48x>Gnoffee: once you get your PATHs sorted out, you can make a .desktop file for the application(s) you've installed <leoprikler>I'm not sure, but those things should actually get sorted out when logging back in again. <leoprikler>We recently went for a walk to patch glib itself, but I don't know whether that's upstreamed yet. <roptat>baryluk, on the guix system there's a binfmt-service that allows you to do that :) <baryluk>roptat: I am not asking about running them. I know how to do that with qemu. <roptat>you can do guix build foo -s aarch64-linux on a x86 machine :) <baryluk>roptat: ok. I will try that. Can I try doing that with `guix install` for some prebuilt package? <roptat>mh... I think guix install and friends don't take the --system argument <roptat>you can always build and install the resulting store path <baryluk>it also looks like majority of packages on guix.gnu.org/en/packages, is only available in i686 and x86_64 builds. :/ <roptat>but you'll be lacking some information, so the result might not work as expected <baryluk>I am just testing. I am abit limited on disk space at the moment. <roptat>yeah, building on aarch64 and especially armv7 is very slow <baryluk>do you need some hardware donations maybe? :) <roptat>I think we're more limited by our build farm system right now <roptat>we talked about possible improvements during the Guix Day, so that might get better :) <roptat>and in any case, we can't say no to donations ;) <roptat>though civodul and other maintainers might know better than me what's needed to help build substitutes on arm <roptat>wait, actually I'm not even sure the set of architectures on that page is related to the state of the CI <civodul>baryluk: oh it could be that the web page is not reporting the right architectures <cbaines>With the Guix Build Coordinator now, there's plenty of use for more hardware <cbaines>I keep working on getting it to build more and more things <cbaines>I thought recently about submitting builds each week for every fixed output derivation, I want to start continuously testing them <civodul>i wanted to ask mothacehe yesterday how the Coordinator experiment on berlin went <vagrantc>i could probably set up some nice aarch64 build machines if i had a larger UPS ... or just ... run without UPS <cbaines>and I want to get the instance of the coordinator I use for testing patches building system tests, as well as system tests and packages for staging and core-updates <vagrantc>oh, that might start to get to be a problem of bandwidth ... <baryluk>Avantek Ampere eMAH, Lenovo HR330A, SolidRun HoneyComb LX2K are I think best options at reasonable (very resonable) prices. <civodul>cbaines: i was thinking we could have weekly "CI" meetings <baryluk>I could donate some VM I guess. I have 1Gbps symetric unlimited network, and plenty of storage and RAM on my aarch64 machine. <baryluk>I will have a new system in the March, even bigger one, so that is also an option :) <cbaines>civodul, well, I'd describe what I'm doing as Quality Assurance work, although maybe the stuff around staging/core-updates is related to Continuous Integration <kozo[m]><civodul "yeah i think we should provide m"> This is a fantastic idea! <baryluk>Different question. I have done `sudo guix install bash-completion`. Now how to enable it in bash? <roptat>civodul, (package-transitive-supported-systems glibc) returns ("x86_64-linux" "i686-linux"), which might explain why the website says it only supports these two architectures <baryluk>Ok found it, `source /run/current-system/profile/share/bash-completion/bash_completion`. That is complex. <civodul>roptat: it takes an optional argument though, and we should pass it <baryluk>hmm based on bashrc, and other stuff, it looks like bash completions should load by default when installed. but they dont <baryluk>is /etc/bashrc loaded if ~/.bashrc exists? <roptat>oh, I see: it looks at the transitive inputs of the package for an architecture, and then returns the intersection of supported architectures <gnoffee>It did not work. I edited the ~/.profile file and restarted. I did the same for the ~/.bash_profile. <roptat>that's weird, and probably not what we want, is it? <roptat>because we get different sets depending on the current architecture (or the one we pass as argument) <kozo[m]>cbaines I was looking at setting up Cuirass for home use.Is GBC a replacement to Cuirass? <cbaines>kozo[m], It's not a replacement, but it can coordinate builds, which Cuirass also does. It doesn't do any evaluating though, you have to tell the Guix Build Coordinator exactly what you want to build. <civodul>roptat: yes, the problem is that the value of %current-system influences the result, hence this optional argument <roptat>should we have a package-transitive-supported-architecture? procedure? <roptat>that's how we should implement package-transitive-supported-systems I think, no? <civodul>cbaines: what i had in mind is meeting with a goal of deploying a replacement to the current setup within a few months <roptat>(define (package-transitive-supported-systems package) (filter (cut supported-package package <>) (package-supported-architectures package)) <roptat>well, not sure how supported-package works <civodul>it would perform very poorly i think <roptat>wait, what does supported-package? do <cbaines>civodul, sure, well I'm always up for talking :) <civodul>anyway, in the web site, we should do (filter (cut supported-package? p <>) %hydra-supported-systems) <roptat>I don't see how that's different from what I'm proposing, but fine <civodul>i thought you were proposing a different way to implement package-transitive-supported-systems in (guix packages) <civodul>but maybe i misunderstood, too many words in those procedures :-) <roptat>ah yes, that's what I was proposing. Why would you like to keep that version of package-transitive-supported-systems? <roptat>it's called by package-supported? ^^' <ksodnaa>hello there. I'm looking for an entry level job. I am holding a strong grasp on the fundamentals of software development best practices, I'm familiar with C, C++, Python and Swift. <cbaines>civodul, I think separating concerns would be useful to talk more about, I think building things for substitutes is almost a different problem to building things for quality assurance <roptat>alright, i have a patch, let me test it :) <civodul>cbaines: true! and i guess we want a bit of both on ci <roptat>er.. where does cut come from again? <cbaines>civodul, well let me know if you have a date+time in mind :) <cbaines>I should get around for arranging the first "help with patch review IRC meeting" <roptat>ah yes, exactly what I was about to send :) <civodul>cbaines: for the "collective patch review" meeting, we could just say every Friday, for instance <cbaines>civodul, do you mean the whole of Friday, or a particular time on Friday? <civodul>cbaines: could be all of Friday, with a standup meeting (!) at a specific time <cbaines>civodul, yeah, that might work well, at least ignoring the "standup" naming, I get what you mean though <civodul>so that means one of us should facilitate discussions at least at that specific time <civodul>"weekly patch review meeting facilitator" (WPRMF) <civodul>ksodnaa: hi! the usual entry-level task is packaging <ksodnaa>For some reason I keep falling of the channel if I send a message but I'm fine if I don't o.O <jmarsden>Is there documentation on installing/running Guix on a Rasbperry Pi 4? Bootstrap from Raspbian or from an x86_64 Debian would be great. I know the Pi's bootloader is very non-standard... I don't know how to overcome or work around that. <jmarsden>Looks like that only has info (and tarballs) for x86 CPUs, 32bit or 64bit. Raspberry Pi 4 is an ARM chip, aarch64 architecture. <civodul>but the script will fetch the right tarball for you <terramorpha>Hi everyone. I'm trying to add a syncthing service in my operating-system.scm file, but can't figure out how to port a shepherd service into a guix one. Has anyone ever encountered/solved this problem ? <jmarsden>civodul: OK, that worked and got me an armhf guix package manager running under Raspbian. Which is good, and I can learn it there. But what I really wanted was Guix-the-OS rather than Guix-the-package-manager. Ideally I want to be able to create a Guix-the-OS bootable USB stick for my Raspberry Pi 4... is there a standard way to distinguish the two different "Guix"es? <chipb>vagrantc: I saw the 1.2 announcement noting that a guix package was now in debian experimental. nice work; thanks! <miskatonic>as a sexondary package manager, guix is more interesting for distributions with a low amount of native packages <jmarsden>I am seeing an error every time I run the guix command: "/gnu/store/7zp9ifpgm3zj481nk6jg1im13g4mza2g-bash-minimal-5.0.16/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)" . Is there a way to avoid that message? <chipb>vagrantc: I sortof wonder if the test failures might be overcome by packaging the guix bootstrap as its own package too. obviously, it'd be rather unconventional as a debian package policy-wise, but maybe it'd be good as a second source of the bootstrap, particularly if it was reproducible? <chipb>miskatonic: I'm sure other distros would be happy to accept a package you submitted. <vagrantc>chipb: unless we can bit-for-bit identically reproduce the bootstrap binaries building on a debian system, that wouldn't work <civodul>jmarsden: re locale warning, which version of Guix did you install? <chipb>oh, right, it's starting from a different toolchain. hm. <vagrantc>chipb: i think the thing to do with the tests relying on bootstrap binaries is to not test it during the build, but using https://ci.debian.net which allows network access <vagrantc>identifying which tests require bootstrap binaries and a way to disable them would be a nice feature <vagrantc>right now i'm patching out all the individual tests to be disabled when no network is available <vagrantc>not sure how to impliment a "network-available?" thing for bootstrap binaries <jmarsden>civodul: The one the script got for me... guix (GNU Guix) 1.2.0 for armhf. It looks like doing unset LC_ALL fixes it, but it's rather wierd to need to do that. <baryluk>chipb: ooo. you are right 1.2.0-rc2 is in experimental. 1.2.0 in git. will build soon. :) <vagrantc>took a few days for the last upload to build, but should get there eventually <baryluk>ooo. vagrantc have you tested flash-kernel with LX2160A Honeycomb? does it work? sorry for the offtopic <vagrantc>baryluk: try #debian-arm on irc.oftc.net for that <lfam>"Authenticating channel 'guix', commits 9edb3f6 to 689d884 (1,317 new commits)..."