<bluekeys_>I tell you what, maav, that mount command, combined with and fdisk -l, shockingly affective! <bluekeys_>It's a shame the files I wanted are elsewhere! <vagrantc>apparently master is not a descendent of 1.1.x ... so git describe gets the wrong tag <vagrantc>well ... git describe --match='v*' isn't getting the right tag. <vagrantc>same commit ... git describe --match=v* v1.0.1-23826-g02c3c51e0c ; git describe --match=v1.1* v1.1.0-66828-g02c3c51e0c <vagrantc>v1.1.0 is older than v1.0.1, according to git. <maav>bluekeys_: bye, good luck finding them :) <maav>vagrantc: maybe it is a bug in git? <maav>because i'd say v1.1 is newer than v1.0.1 <vagrantc>it probably has to do with the order in which they were merged to master or something <maav>hey, no, the second number is the number of commits, how is it getting three times more from there? <vagrantc>i swear, make dist is absolutely maddening. <maav>apart from the issue with the texi, and the wrong version :) <vagrantc>seriously ... what's wrong with "git archive ../guix-version.tar.gz" :) <vagrantc>i guess the GNU conventions existed well before git. <maav>tar was the next one? i've just hit it :) <vagrantc>the sheer amount of time it takes is one strike against it ... just to produce a tarball <maav>the reason, i guess, is that some things are distributed but not in git <vagrantc>the convention these days is to build those at ... build time :) <maav>the convention should be build what is needed; I don't think manuals should be generated on each build after a "traditional" release, for example ;) <maav>on the code path, sure, but not everything is code <maav>well, i'm leaving for today, good luck with make dist, vagrantc :) <civodul>vagrantc: "make dist" works for me, i've just pushed aa7edc9449a7cf796892f5a0369295a95ddbbcf8 which might have fixed it <civodul>though i didn't actually reproduce the problem before <civodul>well i reproduced the problem with guix-cookbook.de.texi, not sure if that's the same thing you saw <dufresnep>$ qemu-system-i386 --drive file=./dkq47627ymdv5p45sv5mg2qh3dqj4lg3-hurd-barebones.qcow2,if=virtio,cache=off -m 1G --boot c <dufresnep>qemu-system-i386: warning: dbind: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-B50XsMkQ2G: No such file or directory <dufresnep>$ qemu-system-i386 --drive file=./dkq47627ymdv5p45sv5mg2qh3dqj4lg3-hurd-barebones.qcow2,if=virtio,cache=off -m 1G --boot c <dufresnep>$ qemu-system-i386 --drive file=./dkq47627ymdv5p45sv5mg2qh3dqj4lg3-hurd-barebones.qcow2,if=virtio,cache=off -m 1G --boot c <dufresnep>$ qemu-system-i386 --drive file=./dkq47627ymdv5p45sv5mg2qh3dqj4lg3-hurd-barebones.qcow2,if=virtio,cache=off -m 1G --boot c <dufresnep>qemu-system-i386 --drive file=./dkq47627ymdv5p45sv5mg2qh3dqj4lg3-hurd-barebones.qcow2,if=virtio,cache=off -m 1G --boot c <dufresnep>sorry! Problem: start ext2s: device hd0s1: No such device or adddress <dufresnep>I just sent an email to the authors of the blog. ***catonano_ is now known as catonano
<brendyyn>the polkit service uses /run/current-system/profile/sbin/nologin as the default shell, where others use (file-append shadow /sbin/nologin). Is one more correct than the other? <xelxebar>Heh. We might be able to precisely show that Guix is also one of these generalized lasers :) <brendyyn>inkscape failes to build for me, but i have a build of it somehow anyway, must be a substitute that worked, but i cant build it locally <brendyyn>Did someone forget to export console-keymap-service-type ? ***amiloradovsky1 is now known as amiloradovsky
***apteryx_ is now known as apteryx
<efraim>vits-test: thanks. it's a bit more complex than the last time I tried to make a custom kernel :/ <vits-test>but 'eval is steel helps, as 'make-linux-libre* and some others aren't public. <efraim>I'll see about tossing 'eval in my version. I keep on getting that linux-libre-source is a procedure and not a string ***botsnack is now known as divoplade
<divoplade> /msg NickServ DROP divoplade YPX7QFIsyZHfgsMXlNcCIBJtNt24LmJf e3a52e35:1443972a <efraim>divoplade: might want to change your password now <divoplade>I needed to register to speak to #guile, but I don't like the fact that I lock a username <efraim>not a problem, just letting you know we've now all seen your nickserv password <divoplade>OK it was automatically generated only for freenode so I don't care :) <bluekeys_>Also, these conversations are logged, so for the sake of someone nicking your nick, it may be worth re-generating and changing it. <brendyyn>failing to guix pull from a 484 day old system :/ <leoprikler>I think you might to pull intermediary commits first. <refcfar>I see that there are several versions of `guile` in guix, all just named `guile`. How do I choose a specific version? <refcfar>Another question: how can I inspect the source of the current system's available modules? Like when I `guix search guile` and see for example `location: gnu/packages/guile.scm:271:2` I would like to just quickly read the source code of that module. <refcfar>Oh I think I just found the answer to both questions: `guix edit guile@2.2` <refcfar>Thanks leoprikler, you were too fast :) <cbaines>ci.guix.gnu.org hasn't finished the evaluation yet, but I'd expect a large number of new builds when it does <cbaines>yeah, the current rust packages do look weird, literally the only thing rust-serde contains is a couple of licenses, but that's not even relevant, as there isn't anything for those licenses to apply to! <rekado>it’s because all inputs need to be available in source form when the leaf package is built; so for many packages that we have *nothing* is built, because they are only used as inputs for some other package that *is* built. <stikonas>civodul: that's because rust doesn't really have a stable ABI, so no libraries <janneke>civodul: i'm starting a daemon from a relocatable guix pack and it looks like that daemon "loses" it's mnt/file system view when the process that starts the daemon exits -- ring any bells? <janneke>as long as the process that start the daemon lives, the daemon behaves fine <PurpleSym>stikonas: Does that matter for guix though? A packages is rebuilt if any input changes anyway (unless grafted). <stikonas>PurpleSym: well, depends on what you mean by matter. Same library is compiled into many different executables, so no space savings. Other than that I guess it doesn't matter <leoprikler>It does, because it means, that Guix can't rebuild those packages separately. <mothacehe>the deamon is joining the it's parent mnt namespace <mothacehe>maybe it should just join PID 1 mnt namespace <nixo_>Hi guix! I have a packaging dilemma. Should I replace bundled fonts? It would drop in 1.4G for a 7M ttf file <civodul>mothacehe: hey! i think janneke is running the daemon by hand though, not on Guix System <civodul>janneke: doesn't ring a bell; that's with the proot execution engine? <janneke>civodul, mothacehe; exactly, an "own" daemon on a foreighn distro; using userns <janneke>(when using proot, the parent process currently doesn't exit -- that's another issue) <civodul>what do you mean that it loses its file system view? <janneke>maybe i should fix thath and force proot <civodul>with proot it's going to be terribly slow, though <janneke>i haven't investigated, upon a new connection the daemon screams /dev/urandom no such file <civodul>it's great that you're testing this BTW <civodul>nixo_: i'd unbundle fonts, that should make the package smaller, right? <janneke>hehe, other than this new discovery it works really great <civodul>so we can see what needs to be ironed out <civodul>well, in addition to these bugs you're reporting :-) <janneke>yes, okay i'll create a bug report :-) <janneke>ah yes, well there's a binary download somewhere of something that should be free software rsn (famous last words...?) <nixo_>civodul: I guess yes, it's 21M less <civodul>so i guess i don't see why it's a dilemma :-) <nixo_>civodul: because then emoji rendering will not work, unless you install font-google-noto (1.4G) and openemoji (which I'd need to package XD) <civodul>so why does the ttf weigh in at 7M and those at 1+G? <nixo_>The difference is between needing just one ttf, and the whole set of ttfs + otfs packaged in font-google-noto <rekado>nixo_: can’t you take the needed ttfs + otfs from font-google-noto? <rekado>this way you get to unbundle *and* only use a subset <nixo_>rekado: you mean just to copy it during build or is it possible to do it in the (source (snippet)) phase? <rekado>we reserve snippets for … ‘serious’ patching that should be reflected in ‘guix build -S’ <nixo_>rekado, civodul: ok, thanks! <wleslie>I don't seem to have gotten the configure flags line right (line 24). is %inputs the wrong variable, or should I be unquoting part of that arguments field initialiser? https://bpa.st/PQJA <efraim>just tabbed back here, yeah, all the rust packages in rust-XXX.scm are leaf nodes and are built more for CI than anything. we only have ~15 "real" rust packages. <efraim>*except for rust-apps.scm and the few scattered in other modules <cbaines>efraim, they might be leaf nodes in one interpretation of the package graph, but they're definately not in terms of the derivation graph. <cbaines>For example, changing rust-serde impacts rust-cbindgen, which is used by icecat <efraim>true. i normally try to push rust changes all at once because of that though. <cbaines>I'm looking at what it would take to package fractal, a Matrix messaging app for Gnome. I've got a working package definition, but there are 127 commits on the branch <cbaines>Nearly all of those commits are adding new rust things <civodul>the problem is that the package graph doesn't reflect that, AFAICS <civodul>"guix refresh -l rust-serde" says nothing depends on it <efraim>we would want (package-source rust-serde-1) <nly>anybody using shepherd or guix for user services? <nly>nice: ungoogled-chromium: Embed absolute references to libGL and friends <vits-test>sneek become to cool for that den. We are loosers. <leoprikler>sneek probably starved due to a lack of botsnacks. <vits-test>psst.. prepare the nets. It may be dangerous now. <madage>cbaines & efraim, since my rust patches caused such turmoil and I have others on the list, let me see if I grok things right: it is better to send as many rust changes as possible in one go, right? <cbaines>madage, well batching changes can help to reduce the number of builds that are involved, but it's a trade off between batching and the delays that introduces <cbaines>one complication with rust package changes is it's more difficult than normal to tell what other packages are effected when a package is changed <madage>cbaines: right and I guess there's no easy way out since we will not be able to change the cargo-inputs+vendoring on cargo-build-system.. <cbaines>madage, in any case, I wouldn't worry too much about it, having better packages is better <Kimapr[m]>is there a way to import substitutes manually? i downloaded a big substitute with wget since guix's builtin substitute downloader kept freezing and tried to pipe it to guix archive --import <ani__> modified: po/packages/da.po <ani__> modified: po/packages/de.po <ani__> modified: po/packages/eo.po <ani__> modified: po/packages/es.po <ani__> modified: po/packages/fr.po <ani__> modified: po/packages/hu.po <ani__> modified: po/packages/pl.po <ani__> modified: po/packages/pt_BR.po <ani__> modified: po/packages/sr.po <ani__> modified: po/packages/vi.po <ani__> modified: po/packages/zh_CN.po <ani__>in my git status after running make in environment <Kimapr[m]>i'm not sure but this many lines deems to be pastebinned <leoprikler>ani__: that's mostly harmless. We don't update potfiles after each commit, so things are bound to get out of sync <ani__>am I supposed to add them? Now when I change gnu/packages/cran.scm I get the error saying <ani__>leoprikler: look at the pastebin file I am posting now. <leoprikler>Nah, the Guix team takes care of that once every major release. <ani__>So I didn't add those files in my git commit. I made commit went back, came again, configured environment. I get that error. <ani__>what does that mean licenses:gpl3+? <leoprikler>the variable gpl3+ is not bound, most likely because it has been prefixed <ani__>sending gpl3+ to guix environment guix --pure command? <leoprikler>Guix does that, because there are some licenses named like libraries, e.g. expat <ani__>like guix environment guix --pure gpl3+ <ani__>so what am I doing wrong here? <leoprikler>have a look at the #:use-module clause for (guix licenses) in that file and prepend the symbol behind #:prefix to gpl3+ <ani__>Okay let me explain, I imported a module <ani__>appended it to gnu/packages/cran.scm <ani__>So I am not getting what tp do next? <leoprikler>the output of `guix import` does not always take Guix programming practices into account <ani__>okay so I must have runned linter first. to check whether <ani__>and then should have commited. <leoprikler>it's rather meant for short files where you can just (use-modules ...) everything that guix suggests if you pipe it into a file <leoprikler>since you can't push your commits, committing and then amending is super fine <ani__>I will send it as patches. :) <ani__>I did get what I was doing wrong. <leoprikler>Oh, sure, sending patches is the preferred way of handling things, I just wanted to clear this up in case you were wondering whether you messed up your local git tree. <leoprikler>Sorry if my responses weren't 100% clear, I've been rather hasty because I needed to set up my equipment for an online lecture on another machine. <ani__>leoprikler: oh cool. No problem. lecture is about which topic? are you lecturer or studetn? <Kimapr[m]>vits-test: guix archive: error: corrupt input while restoring './openjdk' from #<input: file 0> <roptat>ani__, you can run "git checkout po" when you get that, usually, you only get these uncommited files the first time you make the repo <vits-test>Kimapr[m]: +1, manual pipes wget|gunzip|guix archive -x <Kimapr[m]>guix archive: error: corrupt input while restoring './openjdk' from #<input: file 0> <vits-test>Kimapr[m]: what format the wgetted file is? Maybe it zstd then? <Kimapr[m]>it has lzip in it, so i tried `lzip -d`ing it <bluekeys_>Hi guix. I'm doing a system reconfigure and building chromium is taking ages... Which got me thinking, once it's built, is there a way I can share my build back with everyone automatically? <roptat>it lets you host a substitute server on your machine, so people can use it to fetch substitutes for chromium as long as they have allowed your public key <bluekeys_>So, when it's built, do I just guix publish ungoogled-chromium and all is well in the world? <roptat>simply "guix publish", is publishes your whole store, not just a few substitutes <roptat>once you publish your substitutes, you still need to tell people to use your substitute server and give them your public key so they can start downloading trusted binaries from you <roptat>the substitute servers are not decentralized (yet :)), so people still need a way to know where to fetch them; similarly you could claim to have built chromium from the source, but actually included a backdoor in there, so you need to trust the person who built it <vits-test>Kimapr[m]: oh. Looks it just extracts. Not to store. <roptat>hence the requirement for a public key (you need to generate the keys with "guix archive --generate-keys", then guix publish takes care of signing everything) <efraim>madage: sorry, i'm in and out all day and idle on IRC. it's a toss-up. queueing many rust changes at once reduces the rebuilding but makes reviewing take longer :) <vagrantc>make[4]: *** No rule to make target 'etc/gnu-store.mount', needed by 'all-am'. Stop. <civodul>mothacehe: hey! yesterday i pushed build system fixes to guile-avahi <civodul>i noticed that our guile-avahi package installs .scm files in the wrong place <civodul>so we'd need to pass --with-guile-module-dir <mothacehe>civodul: hey! oh, missed that, thanks. That will require a 0.4.1 I guess <civodul>mothacehe: your call; it can be worked around in the meantime <mothacehe>yup, I guess there will be other material for a new release soon, so maybe I'll just hack the package definition in the meantime ***stikonas_ is now known as stikonas
<vagrantc>hrm. apparently gnu-store.mount.in is missing somehow ... <nikita`>hi folx. i don't really have the capacity (or am i even still subscribed to the lists?) to reply to the email i just got about tor-browser on guix, so if the person is around who asked this (someone who goes by procmem): you should be able to infer from my long silence in guix that at least i am not working on tor-browser. <vagrantc>why is it so hard to generate a workable upstream tarball for guix? :P <vagrantc>there are so many small things that appear to sabotage the process <nikita`>will still reply to the email in days/weeks whenever i don't fear not having enough money to make it through a month anymore <nikita`>it's however interesting what people remember and nice to hear back offlist sometimes and in other places. while i'm mainly working in NetBSD now, I still appreciate the people and community i met here back then <madage>efraim: that's what I was thinking and I take human reviewing time to be more 'expensive' than machine rebuilding time, so I'll try to strike somewhere in the middle but favoring reviewers where needed :) <madage>and I'm always in and out, so no problem, take your time... <civodul>vagrantc: ah so we need to add gnu-store.mount.in; do you have a patch for that or should i do it? <civodul>it's hard because i guess this build system is becoming more and more foreign to Guix <vagrantc>civodul: i haven't even figured out where it should be added, so if you get a chance :) *civodul goes afk for a bit <rekado>oof, our sphinx package is very far behind <rekado>I’m trying to build packages on wip-texlive to make sure that the LaTeX changes don’t break anything, but python-numpy-documentation appears to be broken independent of my changes. <zimoun`>rekado: about R and Bioconductor, sometimes there is a folder build/ containing vignettes.rds and the doc/ seems using this instead of the real sources vignettes/. Do I miss something? <vagrantc>i wonder if the etc/git/pre-push could include checks for things like patch added in gnu/packages/patches but not added to gnu/local.mk and other such easy-to-forget things <zimoun`>rekado: hum? I am puzzled by the Bioconductor and I am not sure to understand if the doc is generated from source by r-build-system or bundled by upstream. <rekado>zimoun`: I don’t know. Haven’t looked at this since writing the build system. <mfg>if someone with commit access has some time it would be nice to see if 39918 is okay or if theres something missing :-) <zimoun`>rekado: OK. I will try to send an email with some explanations. Maybe I am missing the obvious. :-) <rekado>it’s possible that we aren’t doing the right thing <rekado>so it would be good to see a concrete example that we can investigate <rekado>(much like the PDF generation of the manual resulted in a very productive debugging session because it was so easy to reproduce) <zimoun`>yeah, I hit a concrete example. :-) I guess. Trying to package diffcyt. <rekado>zimoun`: good good. Looking forward to the explanations then :) <rekado>I might package this when I go back to work at the end of November <zimoun`>no, never used. Hum? interesting… I will give a look <pineapples>Hi! I'm unable to wrap my head around as to why gnu-trivial-build-system's 'find-files' traverses the root of the GNU store when I ask it to copy files from (package (string-append (assoc-ref %build-inputs "package") "/")) to my "%output out" directory. I have to append any character to the slash mark to prevent guix build from attempting to copy the whole GNU store to my own package's build directory <pineapples>roptat, It's that same package wrapper I was writing two weeks ago. I have come a long way, and made a lot of progress. I could say the wrapper is done, if it weren't for the gnu trivial build system's very oddity I'm dealing with rn. <rekado>gnu-build-system or trivial-build-system? <pineapples>rekado, trivial-build-system, very similar to autoconf-wrapper's code <roptat>if you don't share the code, I can't help you <roptat>my only advice can be to add some pk so you can see what intermediate values are <roptat>I mean, trivial-build-system is not supposed to do anything by itself, so really I don't understand what you're trying to do <roptat>if all you want is copy files, maybe you actually want the copy-build-system? <pineapples>roptat: Here's code that reproduces my issue: https://paste.debian.net/1168868 If you try to build this on your machine, the guix build command should yield the list of all directories in the GNU store (not the behavior I'm hoping for). If you append any character to "/" in the autoconf-src field, only the contents of the autconf directory will be displayed (the behavior I'm expecting) <rekado>zimoun`: maybe I’m missing something, but it seems that you should add r-rmarkdown to the native-inputs <rekado>zimoun`: the package does seem to bundle generated files, but the vignette builder shouldn’t use them. <zimoun`>rekado: ah I should have miss to report but I have tried with r-rmarkdown. It does not change the issue. <zimoun`>I have not checked all the packages, but I think that bioconductor (tarball) bundles generated files in inst/ and r-build-system uses them in the “installing vignettes” step. <roptat>pineapples, autoconf-src is /gnu/store/...-autoconf-.../ so (dirname autoconf-src) is /gnu/store, so find-files acts as expected and returns everything under /gnu/store <roptat>(sorry for the delay, I had to go out for a bit) <pineapples>roptat: Thanks! Good to know that it's to be expected, not a bug. Anyway, what can/should I change in autoconf-src for find-files to return files under /gnu/store/...-autoconf-../ instead? <roptat>nothing, just change (dirname autoconf-src) to autoconf-src <pineapples>You're a life saver, roptat! Thanks a lot :) You're right - removing "dirname" did the trick! <rekado>zimoun`: huh, so even with r-rmarkdown you get the line about knitr::rmarkdown missing? <zimoun`>rekado: the line is not there but the missing file yes.