<dissoc>im trying to write a package that uses a sourceforge uri. i noticed other packages use mirror://sourceforge...tar.gz. how do i find the correct uri for the package i wwant to write? where do i find this on sourceforge? <fnstudio>bonjour! i'm running guix as a package manager on a host system and all is working great; i suppose it wouldn't be possible to use guix shepherd (eg mcron?) to replace my host system's cron mechanism, would it? <fnstudio>so basically, i'm migrating my system to guix step by step; but i'm now to the point of deciding what to do with some cron script <fnstudio>i suppose there's no gentle migration path for those cron scripts? i suppose those can't be "guixified" until i'm migrated to guix system altogether...? *fnstudio duck-duck-goes if "to guixify <apteryx>fnstudio: mcron is supposed to support traditional cron syntax <apteryx>the traditional cron syntax is called "Vixie syntax" <apteryx>there's a node about it 'info mcron' then in the reader: press 'm' for menu, then type "Vixie Simple Examples" or "Vixie Syntax" RET to access those sections. <fnstudio>apteryx: i'm guix installing mcron; in the meanwhile, for clarity, i'm not particularly worried about the portability of my old cron scripts but rather if mcron can be used outside the context of guix system <fnstudio>hm it seems like mcron can work on foreign distros; as a matter of fact my cron/crontab commands have all been converted to mcron symlinks *fnstudio scratches head... <fnstudio>does that mean that the newly installed mcron runs as a background process? can't be like that, i can't see it in my ps aux... <fnstudio>i must be missing something (sorry for the stream of consciousness) <apteryx>fnstudio: hehe, interesting. Perhaps after you restart your main cron service it'll make use of it? Not sure. <apteryx>I'm also unsure whether systemd reimplemented cron itself, it's quite possible. <apteryx>If your script are run as your user it may be easiest to have a a user ran mcron instance. <fnstudio>apteryx: yes, restarting the host might help i suppose, although this can only work if i guix install mcron as root <fnstudio>apteryx: (my experiments so far have been guix installing as a normal user) <fnstudio>apteryx: with regard to having a user-ran mcron, that's interesting <fnstudio>do you know how that would work? would that be a process that is always running in the background? <fnstudio>a user-ran mcron would actually be my favourite solutions but can't fully see how that could work without the support of a system-level cron or systemd or shepherd <apteryx>the 4.1 Invoking mcron menu says: "Mcron should be run by the user who wants to schedule their jobs." I'd expect that if you only want to run jobs as your own user, a user launched mcron should do just fine. <apteryx>clone that, then git checkout go1.14.4 <apteryx>else, if you don't need the version history, you can have the source easily with 'guix build --source go@1.14.4' <gunix>apteryx: i am talking about the source of the guix package ***catonano_ is now known as catonano
***yong is now known as Iacob
***Iacob is now known as yong
***lukedashjr is now known as luke-jr
<greenrd>heads up - I am almost done with a version upgrade of Coq and its dependents <greenrd>is there a standard way to announce you are working on non-trivial changes involving multiple packages, to avoid duplication of effort? other than the way I just did? <rekado_>greenrd: the only other way is to write to guix-devel@gnu.org ***apteryx is now known as Guest38011
***apteryx_ is now known as apteryx
<sneek>Welcome back civodul, you have 1 message! <sneek>civodul, rlb says: I'm leaning toward just suppressing this test on i386 for now. Please let me know if you happen to think that's not OK for the shorter term: https://debbugs.gnu.org/43262 <vits-n-guix>Hello dear Guixen. I wanted to check something out in M-x geiser: the (gnu services base). I get lots of compilation. It was because (version) ---> 3.0.2, while the `guix repl`'s version() returns 3.0.4. I installed guile-3.0-latest to my user's profile, and now everything is great. Why so? <vits-n-guix>Can either `guix` use stable guile-3.0, or the Users get the guile-3.0-latest as the default? It is confusing (lots of compilations due to incompatible (3.0.2 vs 3.0.4) bytecode.) <sneek>vits-n-guix, you have 2 messages! <sneek>vits-n-guix, str1ngs says: (service openntpd-service-type) should work as well. I used allow-large-adjustment? #t just to make sure it would adjust. <sneek>vits-n-guix, str1ngs says: I'm using (service openntpd-service-type) now anyways and it's working well. *vits-n-guix ---> RAAAAN! Bwaaah! <BlackMug>I saw that i2pd shipped in guixsd, but wonder why not i2pjava not included? <rekado_>BlackMug: if you’re familiar with i2pd perhaps you could add i2pjava? <rekado_>the cookbook (part of the Guix documentation) includes a packaging tutorial *raghavgururajan was kidding <BlackMug>raghavgururajan imagine one day we have this ability <BlackMug>how on the new guixsd version can be added <BlackMug>actually the only thing that i can use or test guix is due to that issue <Librecat>do you have a channel for off-topic chat <Librecat>a chat where most of you are joined and where people dont get punished for talking off-topic <BlackMug>"Guix is conceptually a source-based package manager, so what we want to <BlackMug>authenticate is Git checkouts of Guix itself. TUF needs to be “ported” <BlackMug>to this model. We’ll address this hopefully within a few months, and <brendyyn>Librecat: dont think so but perhaps we can make one ;) <Librecat>gentoo is only for support while gentoo-chat i dont know <rekado_>BlackMug: “guix pull” authenticates git checkouts, and “make authenticate” in a source checkout does the same. <BlackMug>what about onion mirror any success done for that? <leoprikler>regarding i2pjava, it looks like you have to go through several bootstrapping nightmares before you can package that <BlackMug>yeah i saw i2pjava dependencies its hell <rekado_>“How to create a repository?” doesn’t mention channels <rekado_>“5k packages” is a rather outdated number <alextee[m]>i think the iso should include the basic packages to get started and then show a message asking the user to pull and update <BlackMug>can the sysadmin hardenize guix website TLS <BlackMug>this is essential specially for EncryptedSNI <Librecat>i think its a problem with nvme in general <Librecat>because distrotube also had the same issue <wehlutyk>I'm trying to make a first simple package (ripmime) following the cookbook and the 'contributing' section of the manual, and I'm confused about which guix-daemon `./pre-inst-env` uses (I'm on GuixSD): <wehlutyk>- I bootstrapped well, ran `./configure --localstatedir=/var`, `make check` inside `guix environment guix --pure` all good <wehlutyk>- but then if I run `sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild`, that seems to kill my system daemon. Now with that, building my package fails at download (not allowed to run `scripts/guix`), and without that, it seems my system daemon is used to build. Either way, building fails when copying into the store: https://0x0.st/iIoj.txt <wehlutyk>Here's my current package definition 0x0.st/iIoe.diff <brendyyn>its fine using the system daemon instead of trying to manually start another. <rekado_>yes, there’s no need to use a different daemon <wehlutyk>do you have any idea why copying to the store fails? <rekado_>it says that the directory doesn’t exist <rekado_>you’ll have to create the bin directory first <wehlutyk>rekado_: I see, I was assuming the build system would take care of that automatically. Thanks! <brendyyn>maybe ripmime's makefile doesn't correctly say it needs to be made? <rekado_>had it used “install” instead of “cp” the target directory would have been created automatically <rekado_>the build system cannot know what the install target assumes <brendyyn>wehlutyk: It's common for programs build on traditional distros to have issues like this on guix, because its so different. normally a developer would never guess the /bin/ directory doesn't exist <brendyyn>it would be best to patch that make file and send it upstream <brendyyn>the patch can also be put into guix temporarily until its fixed. <brendyyn>its good to invest in helping upstream so everyone benefits, rather than just working around an issue. ***dddddd_ is now known as dddddd
***deesix_ is now known as deesix
<roptat>jgart[m]: my client lost your messages, only sent me a notification that you sent me some <wehlutyk>brendyyn: re: adding a patch until upstream merges. The patch is also adding lines, so I'm not sure it's easy to do with `substitute*` --> what's the best practice here? Should I add a patch in `gnu/packages/patches`? <wehlutyk>(or anyone else if someone has an answer actually!) <raghavgururajan>sneek, later tell nckx: My ssh key has been changed. Could you please update my fingerprint on Bayfront? SHA256:VGr0IEtNuIiUSTIysfcXMzoj71jtD9k9x7sOiIZuQ4Q <lizE1>I am rather confused about the use of guix. Not in how it's used but rather in what way and it's application. Can someone spoon-feed me on this? <rekado_>lizE1: do you have a more concrete question? <bdju>so, seems reloading my sway config causes a crash a lot of the time. and then after that crash the pulseaudio process uses 99% cpu until I kill it (starting from when I'm kicked back to the TTY, I can already hear fans spinning up). and when I kill pulseaudio, suddenly the mpd module for waybar doesn't know what song is playing anymore, it freezes on old info. (but reloading sway config to fix the bar causes <bdju>the crash, completing this loop) <bdju>I get the feeling it's several separate issues working together in an unfortunate way <lizE1>rekado_: Yeah thanks, perhaps a couple questions, first what is the intended use? I understand why it was made and the benefits it offers, but not how the end user is meant to take advantage of it. I guess the second question is more an extension of the first, but is it meant to be supplemental or a full replacement? <rekado_>in its simplest form Guix is a user-level package manager. <rekado_>different users on the same system can install packages without affecting one another. <rekado_>Guix manages much more than just packages, though <rekado_>you can enter ad-hoc environments that vanish upon exit, build container images containing only the specified packages (and their run-time dependencies), etc <rekado_>str1ngs: the only similarity is that symlinks are used <str1ngs>rekado_: the analogy sometimes helps though. <rekado_>lizE1: with “guix system” you can build complete operating systems, e.g. as a virtual machine image, or as a Docker thing. <rekado_>lizE1: all the while the aim is to be comprehensive <rekado_>unlike Conda, for example, Guix includes *all* dependencies and makes no assumptions about what the target system will have installed <rekado_>Guix doesn’t care what is installed on the build system, nor does it care about what is installed on the target system. <rekado_>this approach enables one core feature: reproducibility due to near-complete control over the build environment. <rekado_>lizE1: does this help? If not: could you clarify your question? <lizE1>Yes sure does, awesome information exactly what I was looking for, thank you! I hope I can contribute back to this whole project sometime :) <rekado_>excellent! Feel free to ask here any time if you’re not sure where to get information about the project. <wehlutyk>so, still packaging ripmime: the source has a "build codes" feature/bug, where a timestamp and machine name are included in the binary (the binary will give them back when called with `--buildcodes`). Is it best to strip that out in the source before building, or to set a stable value for those variables? (see https://github.com/inflex/ripMIME/blob/master/generate-buildcodes.sh ) <rekado_>the manual is a great resource, but it’s also pretty big and it can be hard to find what you’re looking for <rekado_>we also have a cookbook with more tutorial-style articles. <rekado_>wehlutyk: yes, this should be stripped <rekado_>wehlutyk: otherwise you’ll get different results every time the package is built, which prevents reproducibility <rekado_>wehlutyk: personally, I think that in 2020 this should be treated as a bug, because it doesn’t provide any useful diagnostics to anyone while also preventing bit-reproducible builds. <rekado_>but if you don’t want to report this to the developer that’s fine, too <rekado_>it should be enough to replace “`date…`” with "0" and “uname -a” with “Guix” <wehlutyk>I'll strip it, I don't want to start a petty argument about it <lizE1>rekado_: Oh didn't know about the cookbook great, and yeah I quite like the great docs but sometimes it helps to hear what the users have to say. <lizE1>civodul: Thanks I'll be sure to make friends with this : ) <apteryx>I wonder why when building the source of linux-libre, we get *two* source derivations with the same name: /gnu/store/9cszn3j2x070h37iq94csl0j0i5xkhsg-linux-libre-5.8.8-guix.tar.xz.drv and /gnu/store/0ds2skbm9i2wk5m0403r6xwpisc4vd8y-linux-libre-5.8.8-guix.tar.xz.drv, for instance. <apteryx>I can't figure out how that comes to be <str1ngs>apteryx: could it be from another guix describe? <apteryx>no, I'm using this command: ./pre-inst-env guix package -A '^linux-libre$' | awk '{ print("linux-libre@"$2) }' | xargs ./pre-inst-env guix build -S --no-offload --no-substitutes --no-grafts -n <str1ngs>apteryx: one could be a deblob step. just a guess on my part though. <rekado_>apteryx: /gnu/store/9cszn3j2x070h37iq94csl0j0i5xkhsg-linux-libre-5.8.8-guix.tar.xz.drv takes /gnu/store/0ds2skbm9i2wk5m0403r6xwpisc4vd8y-linux-libre-5.8.8-guix.tar.xz.drv as an input <rekado_>if you look at each of the builder scripts in those derivations you’ll see that they do different things <apteryx>rekado_: that's a good idea, to look at the drv <rekado_>one deblobs, the other applies patches <rekado_>it seems a bit wasteful to pack and unpack the sources twice <apteryx>That's what I thought, but I can't figure out how that expands to the same file name. I tried adding different file names to the origin resulting from make-linux-libre-source, and the inherit/modified version that comes out of source-with-patches, but still got duplicate names in the store. <apteryx>So it's as if lowering the inherited origin from source-with-patches was creating two derivations from the same origin. *apteryx looks at the .drvs ***stikonas_ is now known as stikonas
<leoprikler>rekado_: regarding my gnome-builder patch from yesterday, i already sent that again, but neither you nor mark got CC'd <alextee[m]>I'm trying to write a pipewire-git package to test the latest commit but it fails during installation <alextee[m]>i copied the package from wip-desktop inside linux.scm and just changed the commit version <alextee[m]>I get PermissionError: [Errno 13] Permission denied: '/lib' <efraim>It's literally trying to write to /lib, not %out/lib <alextee[m]>im on commit f6bc9113cef765d363e8af6e0e8d3379c8b09c1e <raghavgururajan>alextee[m], You can patching the source or passing libdir related flags. <alextee[m]>how is the build passing on your side? raghavgururajan: <alextee[m]>ok i see pipewire-0.3 passes it, i copied the wrong package <alextee[m]>weird, i thought guix was passing DESTDIR for meson <alextee[m]>maybe it does for 0.3.6 but not 0.3.10 or latest <alextee[m]>you need to set udevrulesdir like pipewire-0.3 does <alextee[m]>civodul: where should i add meson 55? right above the zrythm definition? <alextee[m]>with a TODO comment to remove it once c-u is merged <alextee[m]>or i guess next to the current meson makes more sense <NieDzejkob>alextee[m]: DESTDIR is incorrect in this case, as its semantics are "install to $DESTDIR/$prefix, but the package will actually run at $prefix". Used mostly by non-containerized packaging scripts. <rekado_>leoprikler: sorry, I don’t know the context. Is this about mumi not sending email or debbugs not Ccing? <leoprikler>you answered to that thread, so I thought you haven't noticed my reply <rekado_>there’s a lot of email I don’t notice, unfortunately <leoprikler>in this case it's the small patch for 43296 in which I forgot #t *rekado_ reviewed, reworked, and applied a whole bunch of R package patches from guix-patches <rekado_>efraim: I think this looks pretty good, so I’d like to merge it soon. <rekado_>IIRC you once tried to get icedtea to build on ARM. <raghavgururajan>I was building a python package. The build fails with "python3 headers not found", despite python as input. Any ideas? <leoprikler>if not check_include('python3', 'Python.h'): ← I don't see any such header in `guix build python` <leoprikler>the pkgconfig is python-3.8 in case you're wondering <NieDzejkob>/gnu/store/kmfg2lq2aqgmdrr16hk7nc878aafpqhn-python-3.8.2/include/python3.8/Python.h exists for me <NieDzejkob>roptat: I decided to scheck out the status of scabo, and java-antlr4 from guix-more fails to build with "javac: code too large" <roptat>NieDzejkob: scabo just doesn't work, and I kinda abandonned it now <roptat>I thought we had antlr4 in guix though? <leoprikler>it should produce -I/gnu/store/kmfg2lq2aqgmdrr16hk7nc878aafpqhn-python-3.8.2/include/python3.8/ tho <zimoun>Hi! Before I was doing ./pre-inst-env guix pull --branch=my-stuff --url=$PWD - p /tmp/new and I was happy. Now it raises an error about: cannot locate remote-tracking branch 'origin/keyring'. How can I fix this? <roptat>I think we have all of the dependencies thouqh, so maybe that'll work better with them. I'm not super motivated, but I'll see what I can do. <NieDzejkob>nckx: I remember your quoting a command to import a nar without authorizing the key, but IRC search is being a nuisance and I can't find it >.< <zimoun>apteryx: in the light of Snippet vs Phase and “guix build -S” should return something Guix agnostic, for example does the package Emacs respect such statements? <NieDzejkob>Does anybody here happen to dual-boot NixOS and Guix? <zimoun>apteryx: I have never tried to compile the result of “guix build -S emacs” on somethin not running Guix. Just the path ~/.guix-profile does not look portable. Maybe it does not change nothing. :-) *zimoun commutes, so afk and back in ~2h. <rekado_>zimoun: I just finished my R patch review spree. I’ll get to your issue of moving packages next. Thanks! <NieDzejkob>Theorem zimoun_commutes : forall x y, x zimoun y = y zimoun x. <zimoun>rekado_: Thank you for the quick review! :-) Sorry for the xml mistake. <zimoun>NieDzejkob: almost that kind of commutation. ;-) <hacktivista>hello guys... I'm using guix as package manager (not guix system) and creating a container with `guix environment --container --ad-hoc` <hacktivista>I need to execute some scripts, but /usr/bin/env is not available <zimoun>hacktivista: I think it is the option –share <zimoun>by default, only the current folder is shared with the container <hacktivista>Hmmm... yeah, but that is not containerized any longer... I see `env` exists on my container, but is located, as expected, to a guix location <hacktivista>probably I should be doing this on a .scm file in any case <zimoun>I am not sure to understand the problem. –ad-hoc coreutils provides env to the container <hacktivista>env is not on /usr/bin/env, as expected by my script <hacktivista>I dont think I should edit my scripts since its common convention to have env on that location <NieDzejkob>something like --expose="$(guix build coreutils)/bin/env=/usr/bin/env" <zimoun>maybe you need to replace with $GUIX_ENVIRONMENT/bin/env <nly>raghavgururajan: not me, you'd never catch me using a profanity