IRC channel logs


back to list of logs

<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>please read 'info mcron'
<fnstudio>apteryx: thanks, excellent
<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.
<gunix>where can I find the source code of this package?
<apteryx>the package definition says:
<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
<gunix>the equivalent of this:
<apteryx>guix edit go@1.14.4
<apteryx>if you want an editable copy, clone the Guix sources from
<apteryx>err, from:
***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
***apteryx is now known as Guest38011
***apteryx_ is now known as apteryx
<civodul>Hello Guix!
<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:
<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>nckx: Hiiiiiiiiii!
*vits-n-guix ---> RAAAAN! Bwaaah!
<civodul>that was fast :-)
<janneke>Hello Guix!
<mothacehe>hey janneke!
<janneke>hey mothacehe!
<janneke>hi user_oreloznog
<BlackMug>Hi There
<BlackMug>I saw that i2pd shipped in guixsd, but wonder why not i2pjava not included?
<wehlutyk>hello guix!
<rekado_>BlackMug: if you’re familiar with i2pd perhaps you could add i2pjava?
<BlackMug>how to add i2pjava?
<BlackMug>instructions or something if available
<rekado_>the cookbook (part of the Guix documentation) includes a packaging tutorial
<raghavgururajan>Hello Guix!
<raghavgururajan>> BlackMug‎: how to add i2pjava?
<raghavgururajan>It is easy. `guix add i2pjava`. 😜
*raghavgururajan was kidding
<leoprikler>guix import aether i2pjava
<BlackMug>rekado_ found it thank you
<BlackMug>raghavgururajan imagine one day we have this ability
<raghavgururajan>BlackMug, Yeah :-)
<BlackMug>i added this feature request
<BlackMug>how on the new guixsd version can be added
*rekado_ is a bot
<BlackMug>not how , hope* errr
<BlackMug>actually the only thing that i can use or test guix is due to that issue
<BlackMug>i cant*
<Librecat>do you have a channel for off-topic chat
<leoprikler>What kind of 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
<BlackMug>definitely by 1.0" <- This is done ?
<brendyyn>Librecat: dont think so but perhaps we can make one ;)
<Librecat>gentoo has one called gentoo-chat
<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>ah i se
<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
<leoprikler>scala/sbt and maybe gradle
<BlackMug>Whonix Anonymous OS is watching your development road:
<Librecat>im impressed
<rekado_>“How to create a repository?” doesn’t mention channels
<rekado_>I think it should
<rekado_>“5k packages” is a rather outdated number
<alextee[m]><rekado_ ""> this would be great if you could install offline
<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
<civodul>BlackMug: all the details re authentication are at
<BlackMug>civodul ah cool thanks alot
<BlackMug>can the sysadmin hardenize guix website TLS
<BlackMug>enable TLS 1.3
<BlackMug>this is essential specially for EncryptedSNI
<Librecat>did you fix the partitioner
<Librecat>i think its a problem with nvme in general
<Librecat>because distrotube also had the same issue
<civodul>Librecat: i think so yes; you can try the latest (development) ISO images at
<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:
<wehlutyk>Here's my current package definition
<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>right, thanks for that
<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.
<wehlutyk>brendyyn: ok! I'll try that :)
<wehlutyk>thanks all!
***dddddd_ is now known as dddddd
***deesix_ is now known as deesix
<abralek>Hi Guix
<kmicu>( ^_^)/
<civodul>hey ho!
<roptat>Hi guix!
<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!)
<wehlutyk>(forget about this, problem solved)
<raghavgururajan>sneek, later tell nckx: My ssh key has been changed. Could you please update my fingerprint on Bayfront? SHA256:VGr0IEtNuIiUSTIysfcXMzoj71jtD9k9x7sOiIZuQ4Q
<sneek>Will do.
<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_>that’s one of the intended uses
<rekado_>Guix manages much more than just packages, though
<str1ngs>Guix is like GNU stow!
<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: hardly
<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 )
<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
<civodul>lizE1: this new section should also be helpful as you get started:
<wehlutyk>ok thanks!
<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
<wehlutyk>yes I was a bit surprised 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
<apteryx>it's from the same guix checkout
<apteryx>the complete output looks like:
<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]>raghavgururajan: are you here?
<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
<raghavgururajan>alextee[m]: I am here.
<alextee[m]>is it an upstream bug?
<raghavgururajan>Yeah, it is as efraim said.
<alextee[m]>im on commit f6bc9113cef765d363e8af6e0e8d3379c8b09c1e
<raghavgururajan>alextee[m], You can patching the source or passing libdir related flags.
<raghavgururajan>*can try
<alextee[m]>it fails with 0.3.10 too..
<alextee[m]>how is the build passing on your side? raghavgururajan:
<alextee[m]>can you post your package deifnition pls?
<alextee[m]>i think it's the udevrulesdir meson option
<alextee[m]>it's hardcoded to /lib if it's not passed
<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]>but it looks like it's passing prefix
<alextee[m]>maybe that makes sense, idk
<alextee[m]>raghavgururajan: that does not build
<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
<civodul>grrr why has Magit become this slow
<apteryx>since when?
<apteryx>Emacs 27? Or post magit 1.0?
<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.
<alextee[m]>makes sense
<rekado_>leoprikler: sorry, I don’t know the context. Is this about mumi not sending email or debbugs not Ccing?
<leoprikler>nah, just my git setup
<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
<rekado_>there’s just too much of it :)
<leoprikler>in this case it's the small patch for 43296 in which I forgot #t
<alextee[m]>civodul: updated patches sent
*rekado_ reviewed, reworked, and applied a whole bunch of R package patches from guix-patches
<rekado_>efraim: have you seen this: ?
<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>alextee[m], Ah I see.
<raghavgururajan>I was building a python package. The build fails with "python3 headers not found", despite python as input. Any ideas?
<raghavgururajan>I also added the pkg-config. Still not finding the headers.
<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
<leoprikler>okay, my shell was trolling me
<roptat>I thought we had antlr4 in guix though?
<leoprikler>perhaps the include path is set wrong
<leoprikler>it should produce -I/gnu/store/kmfg2lq2aqgmdrr16hk7nc878aafpqhn-python-3.8.2/include/python3.8/ tho
<leoprikler>cc is wrong
<leoprikler>substitute it for gcc ;)
<roptat>Ah nevermind, we don't havc it
<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.
<raghavgururajan>leoprikler, There is Python.h and python3.pc
<leoprikler>cc is wrong, substitute it for gcc ;)
<raghavgururajan>leoprikler, So 'CC', 'cc' ---> 'CC', 'gcc'
<leoprikler>or simply 'cc' → 'gcc'
*raghavgururajan finished packaging Poezio (, \o/
<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?
*apteryx checks
<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.
<raghavgururajan>Who was asking around for plugins support in Profanity?
<raghavgururajan>nly ?
<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
<hacktivista>how could I make it 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>*on a guix location
<hacktivista>well, I'll just make a symlink to which `env`
<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>so, it doesnt work
<hacktivista>I dont think I should edit my scripts since its common convention to have env on that location
<hacktivista>so... I'll use a symlink
<NieDzejkob>something like --expose="$(guix build coreutils)/bin/env=/usr/bin/env"
<NieDzejkob>should do it
<zimoun>maybe you need to replace with $GUIX_ENVIRONMENT/bin/env
<hacktivista>nice, thanks you guys
<nly>raghavgururajan: not me, you'd never catch me using a profanity
<raghavgururajan>nly: Cool!
<raghavgururajan>The logs are missing in