<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...?
<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
<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.
<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?
<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
<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.
<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!)
<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>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_>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.
<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.
<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.
<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.
<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>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. :-)