<cbaines>civodul, I can also see how I'm misusing the request-accept thing, so I'll fix that at some point tomorrow too <Formbi>the files appeear in the profile, but texlive can't find them automatically <vagrantc>i think apteryx has been working hard all day to get it out today, but will need a large UTC offset to release on April 18th <Formbi>rekado: it also doesn't work with an ad-hoc environment <civodul>vagrantc: those timezone things are crazy <civodul>it'll be released on April 18th (UTC-624) <jackhill>Formbi: `guix environmet --ad-hoc texlive-bin texlive-lm` fails to even build for me: --ad-hoc texlive-bin texlive-lm <vagrantc>jonsger: sorry, being playful ... the original plan was to release on April 18th, but ... some bumps along the way <vagrantc>is there a way to use grub-efi but not actually mangle the efi variables? <vagrantc>when i run guix system init onto removable media, it mangles the server's efi variables <jackhill>Formbi: ah, indeed, I can create the environment that way. I'm afraid that I won't be much help to you since I don't understand how all the tex stuff fits together :/ <vagrantc>i definitely want it to install the bootloader, just not mangle the efi variables... <jackhill>how did you know to use texlive-tiny over texlive-bin? <Formbi>I asked if there's a texlive-minimal here :D <jackhill>Formbi: can you try adding texlive-bin to your environment? I was able to reproduce the problem with the hyperref package (a document I had handy needed it), and texlive-tiny and texlive-latex-hyperref were not enough, but creating an environment with all three worked. <jackhill>I wonder if this warrents a special section of the manual, or perhaps a cookbook entry. <vivien_>When the texlive build fails on my system, it’s because there’s not enough free space on my root partition <jackhill>Maybe we need to have a texlive-install-this-one that propagates texlive-bin and texlive-tiny <jackhill>vivien_: I assume that's because you're using the all-in-one texlive package that's a few GiBs? I think that's why we're trying to make use of these smaller packages <vivien_>jackhill, you nailed it. I had a few bad encounters with minimal texlive packages in debian, in which I was missing a package, so I installed a less minimalist version, but then the missing package missed a few more packages, so I ended up always using the full package <jackhill>vivien_: that's interesting to hear that it's not just Guix with minimal texlive gotchas. I've ended up installin the full texlive in a different profile than my main one. That way I avoid getting surprised by hours-long work when updating my default profile :) <vivien_>jackhill, I have the same bandwidth problems! <Formbi>hmm, maybe in my case it's also pandoc inserting trash into the file <flatwhatson>how do i declare that my package conflicts with another when installed to the same profile? <flatwhatson>specifically emacs-pgtk-native-comp-git and emacs don't play nice, but i'm not sure how to warn/prevent people from doing this <flatwhatson>they "don't play nice" because they both set EMACSLOADPATH <ryanprior>flatwhatson: I don't think there's a way to make packages exclusive like this. Maybe ask on the mailing list whether we can use a different env variable (PGTK_EMACSLOADPATH?) for one package to avoid this? <flatwhatson>problem is that other emacs packages add themselves to EMACSLOADPATH too, expecting that whichever emacs you use will find them there <Formbi>ok, I sorted out some stuff and now tex says: <Formbi>mktexpk: don't know how to create bitmap font for ec-lmri8. <Formbi>on the internet I found stuff like that: « pdftex.map in ~/.texmf-var that had been created before the installation of lmodern. Hence is did not contain the entries for the lm fonts and shadowed the correct pdftex.map in /var/lib/texmf.» <pkill9>i want to create a hybrid application browser and launcher <pkill9>something that lets you browse information and screenshots on applications, but with the keyboard accessibility of an application launcher <drakonis>the rfc might explain much better than i ever could <drakonis>is that its main purpose is to be able to evaluate lazily derivations and make them available <drakonis>so you could include an entire language package manager repository without maintaining individual derivations <drakonis>because nix offers entire snapshots that have to be manually updated from time to time <drakonis>the advantage here is much stronger adaptability to the presence of third party software that is developed without the intention of ever being packaged <drakonis>is that it gets rid of issues regarding package pinning <drakonis>so you can have access to something like node packages without having to pull in all of npm <drakonis>in guix terms, this would let you lazily evaluate the result of a guix import command <pkill9>often you have to make changes to the package thou <pkill9>well, generated by the import command <drakonis>it also has a big infrastructure for using generated packagesets <drakonis>there would technically be a few packages that still need patching on the side, like python packages <drakonis>but it would work extremely well with things like opam and hackage <drakonis>it would also be perfect with pulling from cran and bioconductor for R and cpan for perl <drakonis>this is a particular use case for the rfc <drakonis>anyways, this is called a dynamic derivation <pkill9>could guix have such functionality? <drakonis>i think it still needs to get rid of the nix daemon to achieve it? <drakonis>there also are a lot of other fancy tricks that can be used with it <drakonis>its interesting that it can be used to replace build systems entirely <lispmacs>hi, I was wanting to rebuild a store item (vice) from source, but was a little confused on how to do this. both `guix build --check vice' and `guix build --no-substitutes --check vice' are completed in about 2 seconds, so it can't be rebuilding the package <iskarian>lispmacs[work], I can repro. I'm not sure why, but adding --no-grafts makes it build. <iskarian>to be clear, that was the standard 'guix install vice', which downloaded a substitute and added it to the store... then a 'guix build --check --no-grafts vice' was required to make it re-build ***iyzsong-- is now known as iyzsong-w
<iskarian>Without --no-grafts, it just grafted vice from another vice store item. *apteryx just merged version-1.3.0 into master. If building the translated manuals give you grief, try: find -name *.??.texi -delete && ./bootstrap <apteryx>I think only the email announcement needs to be made now... pending the website coming up along the latest version of the manual <apteryx>that gives me some time to write that email <marusich>I'm actually testing rc2 right now on powerpc64le-linux, heh <marusich>I'm sure it'll be fine because it was fine on the rc1 version <apteryx>v1.3.0 is already on the GNU FTP, if you want to give it a try! <apteryx>marusich: mostly! I think just small translation issues got fixed + SPICE resolution resizing in the VM <apteryx>roptat: another mmap(PROT_NONE) failed building the doc on berlin <apteryx>sneek: later tell civodul any idea what this means: "announce-gen: none of guix-1.3.0.tar.gz, guix-1.3.0.tar.bz2, guix-1.3.0.tar.lz, guix-1.3.0.tar.lzma, guix-1.3.0.tar.xz were found"; there's a tar.gz on the ftp and I've passed --url-directory=https://ftp.gnu.org/gnu/guix. *vagrantc sees a tarball and a new v1.3.0 tag <apteryx>sneek: later tell civodul OK, got it with a bit of Perl studying; cp gnulib/build-aux/announce-gen ~/.local/bin && cd ~/src/guix/release-1.3.0 && announce-gen [...] --srcdir=.. <apteryx>it wanted to find the tarballs in the CWD <apteryx>actually, replace --srcdir=.. by just --news=../NEWS <apteryx>announce-gen made useful with that tarballs hack: my @tarballs = glob("*.[xlg]z *.qcow2 *.iso"); <apteryx>I'm a bit unsure about announce-gen's --bootstrap-tools argument. Is this intended for all the build (native) inputs? ***iyzsong-- is now known as iyzsong-w
<apteryx>sneek: later tell civodul I've got the announcement mail all ready to go, but was waiting for https://guix.gnu.org/en/manual/en/ to update to 1.3.0 (I've reconfigured berlin a couple hours ago with your commit) <apteryx>I just sent it now, as the timing is good and most links in the announcement work OK, although we should fix it ASAP. <tissevert>how pervasively do you folks use guix ? do you use a guix «package» to describe presentation you're compiling from Markdown to pdf with pandoc ? or do you simply have pandoc installed in your environment (or open up a dedicated environment with pandoc in it ?) <vivien_>tissevert, the former except it’s in org-mode converted with emacs <tissevert>vivien_: thanks ! well I don't know how to use emacs but surely I can do something similar with pandoc right ? <leoprikler>tissevert: of course, just guix environment --ad-hoc pandoc or guix install pandoc <tissevert>no, I meant writing a «package» calling pandoc as the «compiler» <tissevert>(is there a jargon for this ? I think nix uses «derivation», what is the guile equivalent ?) <leoprikler>oh, sure, you can do that, but I don't think it's necessary <tissevert>I thought what vivien_ had said described a compilation process with a proper guile package <cbaines>Guix has a Guile representation of derivations too, but there are higher level representations too (like packages and G-expressions) <tissevert>because I've seen civodul mention that about a literate programming document in a talk on monday and I was wondering if it was just technically possible and satisfying or a must-have for everyday's tasks <leoprikler>tissevert: I think you misunderstood them, they don't use Guile packages to compile their presentations, they compile them ad-hoc with {emacs,pandoc,...} <leoprikler>if you want to look into a Guix-related "Makefile" stuff, that constructs environments on-the-fly, look at GWL <leoprikler>note that it's somewhat geared towards scientific workflows though <tissevert>cbaines: so you mean derivations are a different level of object compared to packages ? <cbaines>In the Guile code, there are different record types for derivations and packages <cbaines>(derivations actually use a few records) <tissevert>is the «derivation» the content of the whole file describing packages by means of (define-public …) statements and «package» a statement of the form (package (name …) … (license …)) ? <tissevert>hmm I think I've seen it already ! but a good reminder never hurts, thanks ! <tissevert>it's really hard to read though, what with the text covering a part of the slide, and the long text having to be scrolled in the tiny window <Pascallor>Hi! Congratulations on the release of guix 1.3.0 <vivien_>I second Pascallor, I can’t find a way to turn on the new local discovery of substitutes <vivien_>I can’t build guile --with-latest, the test-out-of-memory fails. Do you have this problem too? <Pascallor>guix package's auto-complete does not suggest --export-manifest for me. Is that normal? The option works. <taylan>probably hasn't been added to the autocomplete metadata yet since it's new? <tissevert>what's the context ? have you freshly installed guix ? is it on another system (Debian ?) or on guixSD ? <tissevert>what does the log file says ? is there something relevant about this compilation failure ? <tissevert>anyway I see that the substitute is missing in guix weather, so that explains why your system is trying to build it locally <tissevert>and as for why it fails, I don't know but I've had similar troubles with vim-full <tissevert>all packages aren't perfect because the packages' own build process may have weird side effects sometimes <tissevert>(I think the one I faced was about a test running too slow…) <sneek>civodul, you have 3 messages! <sneek>civodul, apteryx says: any idea what this means: "announce-gen: none of guix-1.3.0.tar.gz, guix-1.3.0.tar.bz2, guix-1.3.0.tar.lz, guix-1.3.0.tar.lzma, guix-1.3.0.tar.xz were found"; there's a tar.gz on the ftp and I've passed --url-directory=https://ftp.gnu.org/gnu/guix. <sneek>civodul, apteryx says: OK, got it with a bit of Perl studying; cp gnulib/build-aux/announce-gen ~/.local/bin && cd ~/src/guix/release-1.3.0 && announce-gen [...] --srcdir=.. <sneek>civodul, apteryx says: I've got the announcement mail all ready to go, but was waiting for https://guix.gnu.org/en/manual/en/ to update to 1.3.0 (I've reconfigured berlin a couple hours ago with your commit) <civodul>looks like we have a new release out there! :-) <tissevert>PotentialUser-60: in any case you can sort of «pin» the packages that sometimes fail by not making them part of your system and making sure they are available as substitute before upgrading <tissevert>I do that for chromium and libreoffice and it's really nice *civodul updates the manual <tissevert>I haven't been here for long either so I hope I'm not saying anything wrong but if I understand your situation correctly, I'd just say: <tissevert>1. read the compilation log file: bzless /var/log/guix/drvs/vl/zrszqn9kj9x8lzyqh4144pq569ggab-phodav-2.5.drv.bz2 <tissevert>2. if it looks like something transient, try again or simply watch the availability of a substitute using «guix weather phodav» <tissevert>2'. if it looks like something serious about this package and it doesn't build anywhere for no one, then investigate into why this package stopped compiling <tissevert>does that help a bit ? (@others did I miss something or is that a reasonable course of action given the report ?) <leoprikler>2. could still be a reproducibility issue depending on the circumstances, but yeah ***ChanServ sets mode: +o civodul
***civodul changes topic to 'GNU Guix | 1.3.0 is out! https://guix.gnu.org/en/blog/2021/gnu-guix-1.3.0-released | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net/ | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: https://logs.guix.gnu.org'
***ChanServ sets mode: -o civodul
<civodul>apteryx: manual updated, everything's in order! <civodul>apteryx: congrats, and thanks a lot for all the work! <PotentialUser-96>hi all, i want to install Guix System as LXQt desktop. is it possible? i will use "Guided Graphical Installation" on my old netbook. i think this will give only a tty after reboot. i can connect internet only wi-fi. can somebody help, please? <civodul>PotentialUser-96: hi! if you choose LXQt (or GNOME, Xfce, etc.) in the guided installer, it'll give you a graphical desktop when you reboot <pkill9>has there been any work on adding file listings to guix data service? if not, where would you start? <Pascallor>vivien_ `guix build guile --with-latest=guile` just finished successfully <marusich>Congrats on 1.3.0! Time to go to sleep for me :) <mbakke>"Linux-libre 5.9.3" in the 1.3.0 release notes does not look quite correct :) <civodul>i wonder if it was a copy/paste issue *civodul goes afk for a while <avalenn>I see you publicized the Go importer in the release anouncement. <avalenn>The shortcomings of current go-build-system with multi-packages Go modules will become a big pain point. I hope to propose something simple next week to workaround the problem. <rekado_>Formbi: remove texlive-tiny; it’s only useful for packaging. <rekado_>Formbi: instead install texlive-base and whatever package you need. <rekado_>Formbi: what you found on the internet about dotfiles for TeX doesn’t apply here. <rekado_>when you install texlive-base Guix will build the TeX configuration for you, which will find all texlive-* packages you have installed in the same profile. <jeko>I can't update my profile unless I remove a package from my manifest because it seems broken. Is there an option to say to Guix, let's skip broken ones? <jeko>(speaking about texlive… haha) <rekado_>you *can* specify in your manifest that you want to use certain packages from an older version of Guix. <rekado_>look up “inferior” in the manual for more information <jeko>My manifest refers texlive-bin which needs texlive-configuration <rekado_>there used to be a bug in the profile hook <jeko>guix (GNU Guix) f8a4724c101880892640dcc2fe3438dc2a26b624 <rekado_>that’s after what I had hoped would fix the problem… <rekado_>is texlive-bin the only texlive package in the manifest? <civodul>avalenn: looking forward to improvements in this area <rekado_>jeko: I cannot reproduce this with just texlive-bin in the manifest. <civodul>bone-baboon: i think "no auth sock available" means SSH_AUTH_SOCK is unset, which in turn probably means there's no ssh agent running (either 'ssh-agent' or 'gpg-agent --enable-ssh-support') *rekado_ tries with more emacs stuff <emacs-user75>not sure if this was reported yet but the new installer restarts when you click on encrypt whole system <jeko>Hmm I did thought I could came from a kind of conflict between packages <rekado_>jeko: added back all the emacs stuff and I still can’t reproduce this. <jeko>in the default profile i have glibc-locales fontconfig and guile-studio <BlackShift>wrong slash, anyway, I wanted to thank atom` for connecting to eduroam with guix <rekado_>jeko: reproduced it with a more recent guix <rekado_>jeko: that’s a bug. Could you please replace “texlive-bin” with “texlive-base” and see if that’s okay? <rekado_>civodul: something went wrong when I hit submit — the title is chopped off. <jeko>rekado_: It' OK for me too with texlive-base <rekado_>I suppose the texlive-configuration hook just needs to be “hooked” to texlive-base then :) <jeko>I have absolutely no idea haha. I can declare a bug if it can help haha <vldn>how to escape a quoted list inside a quoted list..? xD <vldn>e.g. adding a defined variable with additional items for the list.. like '("item1" "item2" %additionalitems) .. <vldn>nope there a substitute server @ PotentialUser-71 <vldn>but you can build all from source and ignore the substitute servers <vldn>maybe you don't activated it upon installing the system? or do you use any additional channels? <apteryx>civodul: hi! Thanks for updating the manual1 What did I miss? <civodul>apteryx: hey, thanks a lot for everything, you rock! <civodul>apteryx: for the manual, it's a bit inconvenient <vldn>try "info guix substitute" <bone-baboon>civodul: Thank you. I have run `ssh-agent` and taken the environment variables it outputs and run `SSH_AUTH_SOCK=/tmp/ssh-XXXXXXhVZFkz/agent.15637 SSH_AGENT_PID=15638 guix pull` it outputs a new error "guix pull: error: Git error: Failed to retrieve list of SSH authentication methods: Failed getting response". <civodul>apteryx: after reconfigure, you have to "herd restart mcron" so it runs the new jobs, including the one that builds the manual from version-1.3.0 instead of version-1.2.0 <civodul>if you don't do that, it keeps building from version-1.2.0 <apteryx>ah, I see :-) I'll add this bit to doc/release.org <apteryx>civodul: I always mis a 'run' or 'test' action to mcron <civodul>apteryx: ah yes, i typically run "herd schedule mcron" and then "sudo - static-web-site -c /gnu/store/...-update-guix.gnu.org" or similar <civodul>bone-baboon: hmm no sure what that means <bone-baboon>civodul: I was just starting a web search for that error message. <civodul>apteryx: regarding the manual, we should have something more dynamic where we can switch without reconfiguring <vldn>you already have the guix binary running? @ PotentialUser-71? <apteryx>civodul: thanks to you, for this one and past releases too! I can now fully appreciate the amount of energy spent toward producing a release. We should try to automate it some more :-) <civodul>apteryx: definitely, we can do better; now you know ;-) <civodul>i'd like to avoid the 2nd commit/rebuild, for instance <apteryx>yes, that'd be nice. Also perhaps teach the update-guix-package script that if there's nothing new to update to, don't. <vldn>i don't know which installing method you are using for guix system <apteryx>and with a single commit bump, we could parallelize the binary and images generation instead of having them made sequentially, speeding things up <vldn>but you have to add ci.guix.gnu.org as a substitute server and authorize it with "guix archive --authorize < prefix/share/guix/ci.guix.gnu.org.pub" where prefix is the installing directory of guix, you can search for it system-wide with find / -iname "ci.guix.gnu.org.pub" <vldn>before running the guix system init command <emacs-user75>not sure if this was reported yet but the new installer restarts when you click on encrypt whole system <mothacehe>emacs-user75: no that's probably a new issue. Do you think you could send a mail to bug-guix@gnu.org explaining the steps you followed and the initial partionning of your hard drive? That would be very much appreciated :) <vldn>some guile wizards here? -> how to escape a quoted list inside a quoted list..? xD e.g. adding a defined variable with additional items for the list.. like '("item1" "item2" %additionalitems) .. <mothacehe>vldn: you can write something like `("item1" "item2" ,%additionalitems) <vldn> ty! so easy could it be.. :D <vldn>maybe trying to add --cores=4 (your number of cores in your pc) and --no-grafts commandline options <vldn>then you can hopp this step <vldn>but grafts are security updates and highly recommended :) <vldn>experimenting with guix will be a lot of trial and error in the first place but thanks to the system you can't destroy so much.. :D have fun! <vldn>if the bootloader and all is configured right.. :D you'll see <PotentialUser-ag>ok thanks but guix is really diffent and interesting; thanks for developing :) <apteryx>it also mentions 'guix system vm-image below' <vldn>mhh Wrong type argument in position 1 (expecting string): @ mothacehe <apteryx>civodul: this can't be changed on version-1.3.0 due to the string freeze though, no? <vldn>(define %additionalItems '("item3" "item3")) <vldn>(define %additionalItems `("item2" "item3")) <vldn>(display `("item1" ,%additionalItems)) <vldn>there are brackets in the output, that could be the problem: (item1 (item2 item3)) <mothacehe>vldn: (display `("item1" ,@%additionalItems)) should work as expected <vldn>where could i get more infos about the , and @ ? <roptat>jeko, je suis pas contre un peu d'aide :) <tissevert>roptat: je vais voir si l'inscription marche mieux que chez fedora ; ) <jeko>roptat: faudrait que je retrouve mes identifiants linuxfr haha et j'aurai peut etre un peu de temps ce soir si c'est pas trop tard <roptat>tissevert, toujours pas réussi ? <vivien_>Dommage qu’il n’y ait pas l’accent à publié dans l‘URL :( <tissevert>ok their account creation process is really slick Oo <tissevert>I'm in, but still looking how I can change the generated password sent in clear text by e-mail ^^ <apteryx>civodul: I've corrected the VM decompression part + 'vm-image' on master with 55aa50834f. <apteryx>civodul: the nix-dev@lists.science.uu.nl address bounced. What should it be updated with? <rekado_>they must have copied from HN, because they say it’s 1.3 instead of 1.3.0 <mbakke>efraim: thanks for bf8f33c31fe68ae0479ed6bc2c762dae99318562, I was wondering why many packages are 6 MiB smaller on core-updates :-) <pkill9>what is the name of that backend-agnostic package manager, i think it may be a GNOME project <pkill9>packagekit yea i think that's it <pkill9>i remember it having a slightly obscure name <pkill9>i want to take an existing frontend for a graphical application store, and have it use guix instead <pkill9>or package manager, not sure yet, or why not both <pkill9>application store will only work when guix data service provides file lists for packages, and lets you download individual files <pkill9>so you can see which packages provide applications <pkill9>then again idk, maybe just better to maintain it externally <civodul>apteryx: oh yes, you can remove nix-dev@, i think it no longer exists (and they must be tired of Guix ;-)) <roptat>civodul, on a presque fini avec tissevert :) <apteryx>on the HN news about the release, someones says 'Shepherd is pretty slow' compared to OpenRC; I find that hard to believe. Any one in the know? <raingloom>pkill9: afaik people have looked into that and guix's packaging being very different makes things difficult <civodul>tissevert, roptat: bravo à vous deux alors ! <civodul>apteryx: Shepherd is "slow" compared to systemd because it doesn't start services lazily currently ("socket activation") <civodul>i don't know OpenRC, but my understanding is that it's not this sophisticated <pkill9>just need to monitor a guix profile and use guix commands <pkill9>I think a simple server that shows a webpage of packages and executes commands could be a decent prototype <apteryx>civodul: yeah, comparing to systemd I'm sure, as systemd seems to go all-in on optimizing for speed <apteryx>but with OpenRC, I'd expect them to be in the same performance ball park (but I'm just assuming, never having used OpenRC myself!) <vivien_>I think shepherd is also slow because it reads things from the store, and reading from the store is slow <apteryx>why is reading from the store slow? because of symlink indirections? <civodul>tissevert: good point! i think we meant "packagers" here <civodul>though *maybe* packages do have feelings, who knows <vivien_>It’s not what hard drives are used to <tissevert>too bad, I would've loved to be using a distribution with sentient packages <tissevert>and *that* would set it apart other package distribution systems much more than reproducibility <civodul>until we have evidence that packages are sentient, i added a 'r' in guix-artwork.git <apteryx>civodul: about the '--bootstrap-tools' option to the announce-gen script, I noticed its output was not used in the 1.2.0 release announcement. Should we remove it from our doc? <apteryx>it doesn't support all the tools that we build Guix from (I tried) <beigel[m]>Anyone know why I might be getting that error whenever I try to do anything with guix in Emacs? That's from M-x Guix p a <ruffni>i set up a new guix machine, installed iptables (via `guix install iptables`) but `which iptables` doesn't find the newly installed binary. is this intentional? did i miss something? <tissevert>done ! (give or take a couple re-reading / appropriate fixes) <drakonis>apteryx: you want to post it on the nix discourse <nckx>Top of the morning Guix. <nckx>tissevert: <distribution with sentient packages> Until you have to kill a child process. <janneke>nckx: a world rebuild when merging core-updates <nckx>I hear 1.3.0 is out \o/ (because someone reported its ‘first’ bug, but still \o/) <nckx>janneke: Is sudo a world-rebuild package on the Hurd!? <nckx>I need to stop updating it on master if so. <pineapples>Since 1.3.0 is out, is there any ETA for merging core-upates? In some thread on the guix-devel mailing list, I read this has been long overdue <jonsger>from which commit where the ISOs build? I guess it's the one tagged with v1.3.0, but I'm not sure... <janneke>nckx: good question...i'm puzzled! only two packages seem dependent on sudo, same for the Hurd? <nckx>I was puzzled too and thought perhaps you knew (or forgot 😉) something that I don't. <nckx>I'll go ahead and remove it if there's no Hurd-only magic after all. <janneke>nckx: that's what i wondered too: am i missing something, or was this just an honest mistake at the time... <nckx>Later; I'll let you think at your leisure. <janneke>i do remember that in getting the hurd image to build, we needed a number of such changes and most would trigger world rebuilds <civodul>though it also includes "recursive Nix" IIUC <civodul>the examples they give (running cabal2Nix) don't make much sense in Guix because we can just as well run importers "live" <civodul>that's one of the nice things of having a general-purpose language :-) <apteryx>jonsger: v1.3.0 + 2 commits (see the release target of Makefile.am for the details) <vagrantc>i guess the + 2 commits is due to a bit of chicken-and-egg problem? <pepe6060>i'd like to try guix, but I don't know how to use wifi, my laptop has an AX201. Is this supported anyhow? <vagrantc>pepe6060: many wifi interfaces aren't supported, as they require non-free drivers <pepe6060>vagrantc: is there a way to use non-free drivers in guix? <apteryx>vagrantc: it is so that the images generated know the guix package corresponding to the tagged sources <apteryx>yeah, some chicken & egg problem :-) <apteryx>pepe6060: GNU Guix being committed to free software, you won't get help or support for running proprietary software here; that said, if you understand the risks and still choose to do so, there's nothing technically stopping you. <pepe6060>are there current laptops with supported (built-in) wifi? <vagrantc>some laptops allow you to swap the wifi card out, though there may be complications there too <apteryx>I happen to own a 2011 (?) Dell VostroV130 that does. Ancient. Also have thinkpad x200 that I'm currently using with a ath9K based USB dongle (pending me flashing the BIOS with something like Libreboot which should get rid of its wifi hardware white list!) <lfam>Sadly there are no current laptops or even current wifi implementations supported by linux-libre <apteryx>Otherwise on a desktop I use a 5 GHz AR928X-based pci-express adapter that works well <lfam>Nor have I found any activity to solve that <lfam>vagrantc: I'm sure the purism folks would like to use a wifi chip with free drivers but nothing exists since ath9k <lfam>So, you're limited to 802.11n which is quite useful but, at this point, slow <apteryx>before my wireless N bottlenecks our poor average internet access plans here, it'll take a few more years. <lfam>The other issue with be LTE modems, as they are probably going to replace wifi for most use cases <zzappie>I'm using tp-link archer t2u nano wi-fi usb dongle -- its super tiny and one of those hardwares you can grab in electronic stores available worldwide I think, it works with rtl8812au-aircrack-ng-linux-module <lfam>Wow, I didn't realize there was any 802.11ac implementations with free drivers <efraim>mbakke: I had to go and look up the commit. That was forever ago <zzappie>if you look for aircrack-ng headers it actually supports a bubch of devices <mbakke>efraim: yeah it's been way too long :/ I've started work on bringing it to a mergable state, hopefully we can get it rolling in a few weeks <lfam>vagrantc: Do you have any idea if `guix system init` using grub-efi on top of Tianocore / EFI could work on the macchiatobin? <lfam>Like, is it a realistic option? <roptat>tissevert, j'ai fait ma relecture :) <roptat>j'enverai dans quelques heures si personne ne proteste <mbakke>lfam: it should work as long as the kernel is compatible <lfam>Great mbakke. I'm already using linux-libre with the Debian install <lfam>I'm going to install it to a different disk for initial tests <lfam>I'm pretty happy with that computer. It compiles the kernel faster than my thinkpad x260 with an i5 <mbakke>lfam: wow :) I think you can also build and boot a USB EFI installer image for aarch64 <lfam>That's what I had in mind for the "initial test" <lfam>Or, not an installer image, but to install to USB <lfam>But maybe your idea is better <lfam>Is it simply a matter of `guix system image -t iso9660 gnu/system/install.scm` from the macchiatobin? <mbakke>lfam: that should work, yes. At least if EFI is worth its salt. <lfam>It worked great for Debian so I'll try it <lfam>Just to clarify, do you suggest iso9660? Or efi-raw? Or "dunno"? :) <mbakke>lfam: iso9660 should include an EFI bootloader that is recognized by compliant firmwares :) <lfam>I've never "built a PC" before so I'm learning every little thing as I go along <lfam>The first item should read "HTML, with a separate page per node" <lfam>Oh, I see this wasn't included in the 1.3.0 tag <lfam>apteryx: Could we cherry-pick commit 46852000c to the version-1.3.0 branch, so that the options on that page are more clearly distinguished? <lfam>AFAICT this stuff is not translated so it shouldn't cause any more work for the translators <roptat>wow, I actually needed to use --with-latest today :D <roptat>the build system switch from a Makefile to dune <apteryx>lfam: git grep indeed suggests it isn't translated! LGTM <apteryx>ah fun, some target was getting by Make in a Guix container; it seems the TZ is different from the host :-) <apteryx>host is using EDT but container is on UTC; any clue how to leak that into the container? <apteryx>ah, I probably need to expose /etc/timezone <apteryx>hmm, /etc/timezone is not enough in itself. <lfam>I pushed, apteryx. Do we know if this will trigger a rebuild of that page or does it require manual intervention? <apteryx>lfam: it's defined by a static-web-site-service-type that tracks the version-1.3.0 branch in berlin.scm <apteryx>actually, even if the timezone is not the same in the container, Make shouldn't care; the mtime still is the same. Mmh. <vagrantc>lfam: yeah, the mustang uses tianocore for EFI, and that works fine with grub-efi <apteryx>ah, I'm using a shell recipe hack in my makefile making use of the -nt test; that must be it. <lfam>The test suite timed out <civodul>lfam: this derivation is built on berlin though, so perhaps it was successfully retried in the meantime <vagrantc>yay, git describe on guix master actually compares against the most recent release! <vagrantc>for a long time it was really stuck on comparing against 1.0.x or something <nckx>Some bootstrap-$DATE branch even. <vagrantc>nckx: oh yeah ... i worked around that with --match=v'*' ... but now it "just works" <jonsger>apteryx: ah thanks, but that is +5 from the tagged commit... <vagrantc>jonsger: you might have pulled an earlier commit that was deleted <vagrantc>delete your local tag and fetch the new one ... :/ *vagrantc did the same thing <jonsger>vagrantc: I look at the cgit interface <vagrantc>as i recall the tag i first pulled was also ~5 commits behind <vagrantc>it also had some cruft in the tag annotation <vagrantc>yeah, i can confirm it matches what i have on my local git <jonsger>ah, so I'm wrong when I look at master. So the image was built from the version-1.3.0 branch <vagrantc>i recall there were some post-release plans to discuss different branch workflows ... <civodul>but that comes after the post-release break :-) *jonsger starts his post-release crunch time for downstream stuff :) <roptat>we said we'd use a separate branch and evaluate in parallel with our work on core-updates <roptat>so we can merge before core-updates <lfam>Yes, after the post-release break <lfam>Although, I could put together a new "ungrafting" branch tonight. There's probably no reason to delay building that <lfam>It might not really work... some of the grafts were too ambitious IMO <tissevert>I fixed another two typos but I don't see anything else <jackhill>I was so spoiled last time with our release song that I'm missing one now :) <vagrantc>lfam: oh, is 5.12 likely to get an update today too? <jackhill>I assume it's just a lot of effort to make one and no one was moved to do so <lfam>vagrantc: Probably. It depends on if linux-libre releases today or not <vagrantc>lfam: i haven't gotten around to testing the pinebook-pro patch on that properly, but i'm fairly sure it needs the same patch applied to 5.10 and 5.11 <lfam>Okay. Do you need me to do anything? <vagrantc>lfam: well, would love to get the patch in with the next 5.12.x update but might not have a chance to send a proper patch <vagrantc>lfam: it's just adding a single additional patch to linux-libre-5.12-source, just like done for linux-libre-5.11-source <lfam>Should I try adding it to linux-libre-5.12-pristine-source and decide based on whether or not it applies? <jackhill>trying to build core-updates: *** error: gettext infrastructure mismatch: using a Makefile.in.in from gettext version 0.18 but the autoconf macros are from gettext version 0.19. I remember reading advice about this somewhere, but I can't find it now. Any ideas? <vagrantc>i tested that it still applies, but haven't had a chance to test that it actually fixes the issue :) <lfam>vagrantc: Okay. Can you send an email to guix-devel asking for advice about making this conditional based on system type? It would be great to avoid using it on non-aarch64 systems <vagrantc>it's also a no-op for other systems, in that it is a one-line change to the pinebook-pro devicetree <lfam>Right, but it affects the source derivation <vagrantc>but it would be nice to figure out how to do that <vagrantc>so as to be able to commit more freely :) <vagrantc>gah, i seem to have botched the whitespace for the patch applied to 5.10 <raingloom>oh for... is gvfs broken for anyone else? it broke again for me and i have no clue why. maybe it's because i reconfigured but haven't rebooted yet? <raingloom>but it wouldn't be the first time it was completely broken. specifically i can't see anything in /run/user/$UID/gvfs but i can browse things through Nautilus. <raingloom>okay, a reboot fixed gvfs. i love it when things silently break. :)))) <raingloom>i wonder if the gvfs folks ever fixed the bug where symlinks would not work correctly that caused me to almost delete the entire file system on my old desktop install. :)))) <apteryx>guix pull --commit doesn't understand any git refspec such as tags, right? <apteryx>I wanted to do 'guix pull --commit=v1.3.0' but that doesn't seem to fly <apteryx>it says: guix pull: error: Git error: unable to parse OID - contains invalid characters <apteryx>I guess a non-exact workaround is --branch=version-1.3.0 <tissevert>really too bad that there's none around this time <raghavgururajan>> apteryx: I wanted to do 'guix pull --commit=v1.3.0' but that doesn't seem to fly <raghavgururajan>Also, the tag is on the commit a0178d34f582b50e9bdbb0403943129ae5b560ff. Shouldn't it be on 771b866c55e5f992df60f6c32f5fdd78b64e17f6 or b7cbca221f74e9e9ef43c228dca9fa9930babec5? ***rekado_ is now known as rekado
<NieDzejkob>I cannot ssh into bayfront; verbose logs are suggesting that the filesystem is full <lfam>I'm going off-topic, but I wonder if there is a way to prevent this condition from breaking remote login <lfam>Maybe it's /var/run/utmpx that requires a write to succeed <lfam>I pinged you because I think you are local <civodul>NieDzejkob: i can't log in either; it just gets stuck <civodul>i can hard-reboot it without leaving my chair though, if need be <NieDzejkob>oh, is it literally under your desk, or do you have a way to hard-reboot it remotely? <lfam>144 seems high for that machine <civodul>someone's building a huge C++ thing it seems 