***Lightsword_ is now known as Lightsword
***amiloradovsky1 is now known as amiloradovsky
<GNUtoo>Once a package is built, it is available in /gnu/store/..../somedir/ <GNUtoo>How can I get the path of that dir with the package definition or the package name? <GNUtoo>I'm trying with something like that (derivation->output-path testpackage->derivation) <GNUtoo>However I've a wrong type of argument. I'm trying to get a string with the path inside <kozo[m]>GNUtoo Hey, I use guix build <package> <kozo[m]>If it's built, it'll give me the store path <GNUtoo>kozo[m]: it was for using in a scm file to define a machine <apteryx>GNUtoo: out of curiosity, do you know how f-droid does its build? Is the full toolchain free software? It'd be cool to have an F-Droid service in Guix to test builds. <GNUtoo>I'm thinking of using (define some-path (with-store store (package-output store some-package))) <GNUtoo>apteryx: I don't know much about that, I know it was packaged in Debian at some point though <GNUtoo>The full toolchain should be free sofware but debian is not FSDG compliant anyway <GNUtoo>roptat may know about some of the f-droid dependencies <GNUtoo>In Debian they had a full Android SDK <GNUtoo>So I guess that was a dependncy of F-droid <GNUtoo>I also know that the packages definitions are in the f-droid data repository and that they are not FSDG compliant (see anti-features) <GNUtoo>Though it could easily be cleaned up by filtering the packages with anti-features and some additional packages like f-droid <GNUtoo>Example of problematic packages: yalp <GNUtoo>And by extension f-droid itself since it has yalp <GNUtoo>Not all anti-features are incompatible with the FSDG though, but even if all packages with anti-features are not built in Guix it would be awesome to have that in Guix <GNUtoo>It might be possible to go beyond merely building stuff and run them too, though it might require some more work <GNUtoo>apteryx: I also have no idea how the libc is handled in this case nor how it was handled in debian <GNUtoo>For Pure java stuff the libc is probably not relevant <GNUtoo>Note that I'm not an expert at all on that part so I might have made confusions in what I said above, so you'll have to research more on the topic yourself <lfam>Is it possible to `guix pull` a Git tag? I tried passing 'v1.2.0rc2' to both the --commit and --branch options but they both fail in different ways <lfam>The formers fails this way: <lfam>Git error: unable to parse OID - contains invalid characters <lfam>Git error: cannot locate remote-tracking branch 'origin/v1.2.0rc2' <lfam>I feel like one of these options used to work <cbaines>I'm going to give up and just rebuild the commit... <civodul>it has a couple of wrapped lines it seems <civodul>sometimes it's enough to just "join" those lines <cbaines>Git tells me line 8 is at issue, that's the gnu/packages/music.scm | 35 +++++++++++++++++++++++++++++++++++ line <cbaines>it's wrong, but I really don't want to try and edit it to put the corrent number of changes/pluses <civodul>often "patch" gives better results than "git am" <civodul>so i do: "git am -s", fails, then "git am --show-current-patch=diff | patch -p1", works with "fuzzing" <civodul>but yeah, something must be "even more wrong" here <wehlutyk>I'm trying to get a Qt/PySide2 app to work. It needs QtSvg, which currently is not included in the `python-pyside-2` build, so I'm trying to fix that build <wehlutyk>When deactivating that check, cmake finds the modules (including QtSvg), but <wehlutyk>And so doesn't find the include dirs for Qt modules in the store, but not under the QtCore folder <wehlutyk>I get the feeling changing this will require a lot of changes to the build config. Would anybody have advice on how to tackle this? <cbaines>wehlutyk, I'm not really following closely, but could you symlink from the store to the directory where the files are expected? <cbaines>wehlutyk, using symlink would be better if that works (avoiding the copying) <wehlutyk>can't find a guix help command for that (I'm fairly new to guile), what would I use? <wehlutyk>it would have to be file-by-file symlinking, because the destination directories already exist <cbaines>Could you delete the directories, and make them symlinks? <cbaines>Is the thing you're trying to package trying to bundle and build some of it's dependencies as part of it's build process then? <wehlutyk>I don't think so, as it does link to external libs later in the build process. The problem is again that the build config expects exactly 2 include folders for shiboken (which seems to be a preprocessing / code generation step): the qtcore folder, and the pyside2 source folder, so the headers for the external modules need to go at the right place in the pyside2 source <wehlutyk>(sorry I'm having a hard time abstracting out the problem and not giving the gritty details) <cbaines>Are you trying to modify the python-pyside-2 package? <cbaines>Ok, so I see qtsvg is an input, is it not using it? <wehlutyk>so yes, it is an input, but no, it's not using it <cbaines>Hmm, so locally when I see it say skipped, it does say it's looking in the store: Looked in: /gnu/store/7f809f0bhirn1vad1rr3srxk2c7qqang-qtsvg-5.14.2/lib/cmake/Qt5Svg <PurpleSym>Do we have any alternative to Cuirass? I’m giving up on it, because I can’t get it to build anything :/ <cbaines>PurpleSym, what are you trying to do with Cuirass? <cbaines>obviously build things, but what things and why? <PurpleSym>I want to provide substitutes for both channels. <PurpleSym>Yeah, I thought about writing a proper “client” for GitHub Actions… <civodul>PurpleSym: did any of your Cuirass evaluations succeed? <civodul>there's at least an issue with "subset" <PurpleSym>Logs in /var/log/cuirass/evaluations/ are empty :/ <civodul>should be (subset "pkg1" "pkg2" "pkg3") <civodul>i think we should change Cuirass to take a channels.scm and a manifest.scm file <civodul>we wouldn't lose anything in expressive power <divoplade>From one day to the next cuirass started to crash because the database was read-only <civodul>yeah those lists and consequent lack of error report look very much like configuring Gnus :-) <PurpleSym>civodul: Okay, thanks. Now it’s at least failing with an error message :D <cbaines>Unfortunately I've run out of time to help though <wehlutyk>cbaines: thank you for the help! I'll keep looking for a good solution for the shiboken error coming up after the change you just made <civodul>PurpleSym: namely, one of your packages must have a wrong 'license' field <civodul>PurpleSym: yes, it should be either a <license> or a list thereof <civodul>(another thing we could get rid of in Cuirass IMO) *zzappie get rid of Cuirass? checking the logs *zzappie sorry just joined in :) *zzappie oh "get rid of *in*" <PurpleSym>I think I’ll just go for the poor man’s mcron CI for now… <divoplade>You could also run guix build from within a git hook <civodul>PurpleSym: heh :-) the license issue should be easy to fix, at worst make it an empty list <efraim>are we still supporting guile2.0-shepherd? <PurpleSym>Afaik precompiled sources (often JavaScript) are also not acceptable usually. <abcdw>PurpleSym, yep, I'm curious more about the cases like precompiled js. <PurpleSym>I remember there was a bootstrapping issue with TypeScript (which is written in TypeScript). Also npm is a mess. <lane>i'm back with more linking problems (though I did manage to solve some from yesterday) <lane>Missing libstdc++ somehow... <civodul>are hard links to directories a thing nowadays? <nckx>civodul: Not on (GNU/?)Linux, I thought. Why? <efraim>Thinking how to save store space and time with gc? <efraim>My simple tests showed 3:1 compression with deduplication from the daemon and 2:1 with zstd compression from btrfs for 6:1 total. I didn't do the math on no deduplication but I think it wasn't as good as 2:1 <efraim>I wonder if there's some filesystem flag that would do hard linking on identical files <civodul>nckx: i was looking at the "guix system init" phases where it actually copies things from one place to another place on the same file system, thinking we could do better... <nckx>civodul: You should look into opportunistically creating reflinks (CoW copies) instead. <nckx>Although I don't know if it will save time. <nckx>Looks like it still makes you spin through each file. Drat. <nckx>Also hello good morning Guix 😴 hi. <zimoun>rekado: Roel did some work on the BioConductor update but it seems that our async work erase it on Savannah. Now they has almost everything ready locally but cannot push (even with -f). Configuration of the branch? <dongcarl>Hi all, trying to search thru #guile logs here... Seems the search is down? <nckx>zimoun: Force-pushing isn't possible, Roel needs to merge any relevant changes on the Savannah branch locally, delete it, then push. <nckx>dongcarl: Sounds like the indexer's down again since 12 Nov. <nckx>No, that's not it, never mind. <nckx>My connection to the server got reset. <zimoun>civodul: yes, for sure --substitutes-urls do the job, I even time to time use guix.tobias.gr or guix.cbaines.net. But one has to know it. For example, the official bayfront.guix.gnu.org is not reported in the manual (fixable, I will see what I can do). <zimoun>civodul: However, as a user, I expect “guix install gmsh” just works and not burn my CPU because I will never do C-c RTFM, “guix install gmsh --susbtitutes-urls=bayfront“. <nckx>dongcarl: Seems like it's the opposite, no logs before 12 Oct. You last spoke in #guile on 2020-09-23, correct? <dongcarl>nckx: Don't remember but that seems possible :-) <zimoun>nckx: thanks, but since it is a wip branch, all the history is rewritten etc. <nckx>zimoun: <the official bayfront.guix.gnu.org> How ‘official’ is bayfront, was my question yesterday. It's more of a policy question I guess. Do we want to support it as such, and (ask users to) trust it. <nckx>rekado: Did the goggles Xapian database get corrupted/reset/renamed/... on 12 Oct? No search results older than that. <civodul>zimoun: i'm aware we have a CI problem, if that's what you mean :-) <civodul>nckx: but CoW is a Btrfs thing in practice? <civodul>at the syscall level, there's just link(2), right? <zimoun>civodul: I am looking for a simple fix while waiting fixing the CI :-) <zimoun>nckx: I agree, I did am asumption about the policy. And I do not know, I would say yes. :-) <nckx>civodul: XFS perhaps, not sure. <nckx>In practice perhaps, but that's only a matter of time. <nckx>Didn't someone want to make btrfs the default anyway? 😛 <nckx>civodul: No, reflink is a syscall too. <nckx>OK, no, a syscall's weird creepy nephew: man ioctl_ficlonerange. <zimoun>roptat: The website is not fr translated, right? I was in mood to translate the v1.2 draft post, does it make sense? <nckx>It could work. It might not. <nckx>zimoun: <but since it is a wip branch, all the history is rewritten etc.> I don't understand. <nckx>How does that affect my answer? <nckx>zimoun: <I would say yes> I agree btw. It just needs to be discussed. If you want this, I suggest starting it on guix-devel. <zimoun>nckx: (topic: substitutes), I agree, you agree, we agree. How regular English is compared to French ;-) Ok, I will open the discussion. on guix-devel <nckx>OK, btrfs does not support ioctl_ficloneranging directories, so it wouldn't save any time here. Schade. <rekado>I just noticed that too and wanted to ask. <rekado>I didn’t know Roel pushed to our wip-r branch <zimoun>nckx: (topic: push) well I should miss something, but “pull, rebase (conflict), push (fast-forward)" is work when at the end the final result is already ‘push -f’ <roptat>zimoun, I don't think we have a way to translate posts <roptat>you can translate the website though :) <rekado>zimoun: what’s Roel’s last commit? Was it 8ed6a08a998d4abd58eb67c85699f38f87f76d05? <rekado>BTW the update commit messages are wrong <zimoun>roptat: the website is too much :-) Well, I would like to publish to linuxfr or something like that, so a win-win. Note that Spannish translation is not translated: http://guix.gnu.org/es/blog/2020/online-guix-day-announce-2/ So Maybe we could the opposite, serve a translation at fr/blog/blabla even if all the website is not translated; maybe just the front web page. Ok, I will see my motivation later. ;-) <jonsger>hm, networkmanager and dnsmasq didn't like each other. They are spamming /var/log/messages heavily... *zimoun is checking rekado question about Roel's commit <rekado>the WIP branch is like any other: we don’t do force pushes, but you can delete the branch and re-push. <rekado>all I did was delete origin/wip-r, reset my local copy to zimoun/wip-r, rebased on top of origin/master, and pushed origin/wip-r <zimoun>rekado: ok, thank you. I understand. :-) <kozo[m]>Hello, which alias is Mathieu Othacehe? <kozo[m]>civodul Since you are the other person on the pinebook pro issue that Mathieu submitted, how do I prep his code to try it on my PBP? <mothacehe>echo "(use-modules (gnu system images pinebook-pro)) pinebook-pro-barebones-os" > /tmp/os.scm <mothacehe>./pre-inst-env guix system disk-image -t pinebook-pro-raw /tmp/os.scm <kozo[m]>I don't know what a checkout is. Is there a spot in the manual or cookbook that explains it? <kozo[m]>Perfect. Thank you. I'll try it out and report back to that issue thread with the results <dongcarl>mothacehe: Found a bug in clang-8 that leads to non-reproducibility in .o outputs, it's fixed in clang-9... Would it make sense to backport that patch to Guix's clang-8? <dongcarl>(more specifically... llvm-8 not clang-8) <mothacehe>dongcarl: can't see any package referring to llvm-8 or clang-8, so maybe it's not needed. Unless you you have a specific need for this clang version? <zimoun>mothacehe: then the transformation --with-c-toolchain=clang-toolchain@8 will produce unreproducible build, right? <mothacehe>and then git am /tmp/patch from the Guix checkout directory <zimoun>so I do not know what kind of backport dongcarl speaks, but maybe it could be worth. I do not know. <jonsger>is there a way to debug mcron? Get it logging what it's doing, or better what is not doing? <jonsger>it has this job schedule: (job "*/10 * * * *" "speedtest --csv >> /tmp/speedtest.csv") but it just does not excecute it? <mothacehe>jonsger: you can run "herd schedule mcron 100" <jonsger>mothacehe: it's scheduled, but the script silently fails/does nothing/what ever <cbaines>jonsger, maybe check the mcron PATH (I'd check in /proc). It could be that speedtest isn't on the PATH. <cbaines>you could also just specify the full filename of speedtest <jonsger>or maybe "Command output is mailed to the crontab owner" <nckx>jonsger: Icedove benefits a lot from your commit bit 😊 Thanks! <nckx>Is the ‘update together with Icecat’ comment obsolete now? <jonsger>nckx: no, it would be best to update directly after icecat although I don't think it's a big problem <jonsger>most security issues will be fixed by the icecat updates as it ships most of the code... <jonsger>cbaines: it's in the path and mcron run as root. My "script" works running with root <cbaines>jonsger, OK, my mcron process has PATH=/run/current-system/profile/bin is that what you're expecting? <cbaines>Cool, well strace would probably be my next thing to try... <kozo[m]>Btw, thank you to whose idea and effort made downloads->latest a thing. <nckx>jonsger: Got it, thanks. <dongcarl>mothacehe: I use clang-8 mostly for *redacted unfree fruit company* cross-builds, and we want reproducibility for that. Ofc I can just apply the patch on my own manifest, but was just wondering if it might be of interest for others who are using clang-8 or packages which may require clang-8 specifically in the future. <jonsger>cbaines: while running it with strace it works, maybe it works with mcron-service as well... <mdevos>Is there a policy for or against responding to closed issues? My issue #44199 has been closed recently for its dependency GNUnet not being considered "stable" and the patch being rather incomplete (closed with my approval). But I'm not waiting with hacking on it until GNUnet is stable enough, so ocasionally posting follow-up e-mails in case of significant progress seems more natural to me than keeping people in the dar <mdevos>\me is pleasantly surprised with the complexity of writing a GNUnet DHT service <cbaines>jonsger, did you strace mcron, or you script? I was imaging stracing mcron and watching for when it tries to run your script <mdevos>sneek: later tell zimoun presuming free time and no scheduling conflicts, I will be present at the conference <nckx>mdevos <re: closed issues>: Go right ahead. <ngz>mdevos: I think it is fine to send information to a closed issue, since it can be re-opened anytime. <jonsger>cbaines: I strace the complete mcron with all it's parameters as root and then it worked. Running mcron via shepherd it does not work and I have a `[mcron] <defunct>` process + the mcron process <cbaines>jonsger, maybe try stracing mcron running via the shepherd then, maybe that'll reveal what's going wrong. <cbaines>so you can attach to a running process <jonsger>eh, yes. Originally I wanted to that but while reading the man page, I forgot about it :P <raghavgururajan>nckx: Sorry about the Gajim patch. I was misled by a gajim dev. I am working on it now. <nckx>All good. I'm more curious about the gajim <-> plug-in version mismatch on master. <nckx>How are they intended to be used? <cbaines>how often does it run the relevant thing? <cbaines>ah, maybe use -f with strace as well <cbaines>Maybe change it to every minute so you can test faster :) ***nckx is now known as jorts
<jonsger>cbaines: yeah or I can do other Guix stuff alongside :) <cbaines>I do often wonder how much I should try multitasking, especially while waiting for builds to finish <raghavgururajan>Regarding plugins, I think you installed plugins via both guix and gajim's plugin installer. <jonsger>ERROR: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate :P ***jorts is now known as nckx
<nckx>raghavgururajan: I ran ‘guix environment guix -- ./pre-inst-env guix environment --pure --ad-hoc gajim{,-openpgp,-omemo} -- gajim’, that's it. <nckx>I wouldn't know how to install plugins using another method ☺ <cbaines>jonsger, well, you found the missing environment variable(s) :D <jonsger>cbaines: what is the beste way to set them there? source a profile before? <raghavgururajan>nckx: Ah! I tested via `./pre-inst-env guix environment --pure --ad-hoc gajim gajim-omemo -- gajim`. The plugins are loaded and worked correctly. <cbaines>jonsger, you could use a gexp and set the right environment variable pointing at the nss-certs package, that might be the cleanest way <nckx>raghavgururajan: I've removed ~/.config/gajim & ~/.local/share/gajim, trying again. <nckx>raghavgururajan: So the only diff is the missing -openpgp. OK, will try without. <cbaines>jonsger, you could also just hardcode values from root's profile *jonsger goes hardcoding, don't understands gexp magic <nckx>raghavgururajan: But. If my patch works for you, I think it's good enough to include. *raghavgururajan clear his dor-files too <guix-user>After removing dot-files, the plugins did not work for me either. :-( <guix-user>I guess we should just remove the 'add-plugins-dir phase for now? <nckx>raghavgururajan: Please ask upstream to reconsider. PLUGINS_OS is a horrible name. This is a global variable, or at least it will be in Guix. Every programme will now see a PLUGINS_OS variable set to .../share/gajim/plugins. It should be at least be prefixed with GAJIM_, like other such variables. ‘PLUGINS OS’ is just bad English compared to ‘PLUGIN PATH’ but fine, that's their problem. The missing GAJIM_ is ours. <guix-user>That phase also affects PLUGINS_USER line in the code. So gajim plugins installed via internal plugin's installer is not working. But if I remove that phase, then it works. <nckx>guix-user: Your plug-ins won't load because the gajim plug-ins in Guix aren't compatible with the gajim in Guix. Guix's gajim needs to be updated or the plug-ins downgraded so we no longer ship a broken combination to users. <nckx>The patch is orthogonal to that. <davexunit>has anyone ever done anything to integrate guix environment into projectile-mode or similar? would be cool to have emacs automagically handle enviroment variable setup for my projects that use guix to pull in dependencies. <nckx>The fact that it now prints an version error implies the patch works. <guix-user>Oh wait, yeah, we can downgrade the plugins. <nckx>guix-user: So the packaged plug-ins are unstable? ‘1.2.91 <= 1.2.2 <= 1.3.90’ would imply as much. <guix-user>So could you push the patch you made? I'll send patches to fix plugin's versions. <cbaines>jonsger, ah, I didn't think to mention the log file, but yeah, before the logs just went to the 1st tty, which wasn't very useful <civodul>roptat: also in a couple of other places that can be seen by running "guix build -f doc/build.scm" <cbaines>(you can also filter for fixed packages) <cbaines>ngz, thanks, I'm hoping to do some more along this line to make it easy to spot when patches break existing packages *vagrantc grumbles about debian experimental's buildd queue being too long <civodul>ah ha! we're not the only distro having troubles building things! see? <ngz>cbaines: I tried the HEAD and HEAD^, but they are unknown to the service. OOC, what is the approximate time required for it to catch up? <jonsger>civodul: even at SUSE with a proper sysadmin + developer team and a big server farm, it's usual that you have days when the build service is overloaded <jonsger>nckx: did vim-8.2.2000 built when you updated it? <nckx>Nah but I pushed it anyway. <nckx>I gather it doesn't for you? <nckx>vim is notoriously flakey. <nckx>jonsger: Please file a bug, and note the failing test. <ngz>cbaines: there's a typo in the compare page, next to Unknown type description: "or not enought builds to determine a change" <nckx>jonsger: Oh, is this on non-x86_64? <nckx>jonsger: OK. Well, if you just want vim & accept substitutes, use guix.tobias.gr. Berlin hasn't started building yet. <jonsger>doing a `guix build vim` f*** up my terminal ^^ <nckx>Yeah, that's the (flakey) test suite. <jonsger>nckx: don't we have `--without-tests` now? <nckx>It's not in ‘guix build --help’ but perhaps. *vagrantc considers the guile-2.2 fallback plan for guix in debian... <vagrantc>i thin some more tests fail, but i've gotten so skilled at disabling test suites :/ <vagrantc>wonder if it will trigger some of those weird mismatched guile version problems i've heard about here-and-there <vagrantc>of course, once you do 'guix pull' you're not using much of the debian-packaged guix anyways... <nckx>Remember kidz, when you ass-ume... <jonsger>nckx: we disabled such tests, should I do it or do you want to fix it? <nckx>There's some non-determinism here too, I'm looking at (Guix's) vim .2000 here. <nckx>jonsger: (remembering PHP) You're a good test case for this stuff ☺ <roptat>civodul, oops, will fix, thanks! 