IRC channel logs


back to list of logs

<nckhexen>I'll look at /v/l/messages too.
<nckhexen>Kolev: It does that a lot, it's very sensitive to having a UTF-8 locale configured on both ends.
<nckhexen>ACTION away.
<Kolev>nckhexen, weird. Didn't have that issue on Fedora. I'll just use regular SSH I guess.
<NewGuixUser>rekado so is the result of that map compose the input to my manifest? like (packages->manifest (map ....))?
<rekado>NewGuixUser: yes
<rekado>I haven’t tested this whole composition myself, so there’s a good chance I overlooked something
<rekado>but it’s very similar to what we did in guix-past, so it (or a variant of it) should work
<NewGuixUser>Yeah I'm seeing "guix/packages.scm:1419:23: In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): "python-coloredlog""
<rekado>oops, somewhere you’re passing a string instead of a package value
<rekado>could you show me the whole thing you’ve got?
<jbnote>nckhexen: thanks for the tip about (command-line). The targets are absolute for netboot-installer, contrary to the other bootloaders, so I have to resort to this.
<NewGuixUser>rekado Yeah I'm using strings at the bottom
<NewGuixUser>i wasn't thinking
<nckhexen>Kolev: I can't reproduce it now, of course, but it's a classic. I don't have a remote Fedora system, only Debian, and I can mosh just fine to that from my Guix System.
<NewGuixUser>when I unquote them I get errors about unbound variable, so I guess I need to import the appropriate modules containing each one?
<nckhexen>I think I last got it when 2 Guix Systems had different glibc locale versions.
<nckhexen>jbnote: That doesn't sound right.
<nckhexen>They are ‘absolute’ relative to the target system, not the host system.
<nckhexen>Are you doing some double-nesting-type-deal-thing-amabob?
<nckhexen>If they really are absolute relative to / during installation, that sounds like a mere bug that should be fixed in Guix, since it directly contradicts [my reading of] the docstring.
<rekado>NewGuixUser: just a moment; I’ll prepare something
<NewGuixUser>Take your time
<NewGuixUser>I really appreciate the help
<jbnote>nckhexen: for grub-efi-netboot-bootloader, the target directory is *not* relativized to MOUNT-POINT (the last argument to guix system init). This is a special case; I guess the rationale is to decorrelate the tftp directory from the NFS root. However, i'd like both to be linked, as in the standard case, which I find more easy to handle.
<nckhexen>‘MOUNT-POINT is the last argument in 'guix system init /etc/config.scm mnt/point'’
<nckhexen>That rationale wouldn't make sense.
<jbnote>nckhexen: the grub-efi-netboot-bootloader codepath is probably not very well tested; for instance it breaks if you don't put a trailing slash in the targets directories.
<nckhexen>Yes, it's just a bug.
<nckhexen>Anything making a user think they need to parse the command line is a bug 😉
<nckhexen>It's a clever workaround, but I urge you to submit a bug report when you have the time.
<jbnote>nckhexen: Ok, will do along with the trailing slash bug (which I have fixed locally). Thanks for your insight. The documentation not being very clear, I didn't recognize this as a bug.
<rekado>NewGuixUser: I’m still having some trouble to cut the recursion early
<jbnote>nckhexen: I don't mean to be mean to guix documentation. It is generally completely awesome, btw.
<nckhexen>It's not mean, it falls short in places.
<nckhexen>During this discussion, I was referring to <> by the way.
<nckhexen>Perhaps you were reading something else.
<nckhexen>Said something might be in need of loving improvement.
<nckhexen>And not to offload (more) work, but said improvement would ideally be done by someone actually familiar with netboot, which is not me.
<NewGuixUser>rekado: so you mean you're still seeing it build unnecessary packages e.g. inkscape?
<jbnote>nckhexen: thanks for pointing out the documentation in the code. I was reading in the website html manual. This is definitely more clear.
<nckhexen>It's a habit I don't often notice I have.
<rekado>NewGuixUser: yes, the problem was with the order of the transformations
<rekado>there’s some verbose debugging output in this code; hope you don’t mind :)
<rekado>I’m building this with this command: guix time-machine -C channels.scm -- environment -m manifest.scm
<nckhexen>jbnote: Not to make excuses for the manual, but do make sure you're reading the ‘devel’ version at <> if you aren't already. The other ‘stable’ one matches 1.4.0, for now.
<rekado>channels.scm only contains this:
<nckhexen>jbnote: I doubt it'll make a difference in this case, just general advice.
<rekado>(not Guix Past, because I didn’t want to figure out which version of that channel works with 1.4.0 of the Guix main channel)
<NewGuixUser>Yeah I saw that comment. That makes sense
<NewGuixUser>I'm running the build on my end as well with the same channels.scm you provided
<jbnote>nckhexen: thanks a lot for your guidance.
<rekado>I haven’t built it all, but the initial output looked fine to me
<NewGuixUser>it failed almost immediately for me
<NewGuixUser>cannot build derivation `/gnu/store/gw34l7ikhmvpdm4862c9m721207z4acx-python38-attrs-bootstrap-21.2.0.drv': 1 dependencies couldn't be built
<NewGuixUser>checking the log now
<NewGuixUser>the error from the log is "zipimport.ZipImportError: can't decompress data; zlib not available"
<rekado>I see that too
<rekado>that’s in the build of python 3.8
<rekado>I need to go now
<rekado>maybe worth adding guix past for that package after all…
<rekado>ACTION –> zzzZ
<NewGuixUser>alright I'll try to figure that out
<NewGuixUser>thank you for your help
<NewGuixUser>hmmmm so even the most recent commit on v1.4.0 cannot build python@3.8.5
<Kolev>How do I use my personal shell scripts?
<mwette>Does anyone have an idea of the minimum RAM requirements for a Guix System?
<mwette>no graphics
<Kolev>I've thought of putting Guix System on an SBC, configuring it as a Kodi machine.
<vagrantc>based on experience, 2gb is painful, but not impossible ... 4gb is a bit rough ... 8gb is pretty ok
<singpolyma>Probably depends if you can get substitutes for everything you need ;)
<vagrantc>even if you can get substitutes, guix pull has a fair amount of non-substitutable bits
<singpolyma>That's true
<vagrantc>although there may have been some work to improve that a bit ...
<Kolev>Has anybody configured Guix as a Kodi system?
<mwette>I'm guessing substituions won't help w/ riscv. I have a VisionFive2 w/ 4 GB.
<singpolyma>Yeah. I would be prepared to wait many weeks to install stuff
<Kolev>singpolyma, that idea reminds me of my FreeBSD days.
<Kolev>singpolyma, I got Guix System doing all my jobs.
<vagrantc>mwette: another option might be to cross-compile your image on another machine with more resources ... but then you'll need to regenerate the image rather than upgrade in place for the most part
<mwette>vagrantc: thanks. I am toying with the guix option for my box, and would look to keep the package and service count small.
<NewGuixUser>rekado: so this "(use-modules (past packages python)) (specifications->manifest '("python@3.8.5"))" builds on v1.4.0
<NewGuixUser>I guess all I can really do is very slowly add things in one by one
<NewGuixUser>guix doesn't like the 5th line in this function, it's giving me "Wrong number of arguments to #<procedure member (_ _)>".
<ulfvonbe`>there are two 'member' procedures: (@ (guile) member) and (@ (srfi srfi-1) member)
<ulfvonbe`>the former is documented in section "API Reference > Data Types > Lists > List Searching" of the guile reference manual, and the latter is documented in section "Guile Modules > SRFI Support > SRFI-1 > SRFI-1 Searching" of the guile reference manual
<ulfvonbe`>note that because the former uses 'equal?' for comparison by default, it will work everywhere that 'string=?' works
<ulfvonbe`>NewGuixUser: ^
<NewGuixUser>honestly I didn't write that function and I don't fully understand the broader context yet, but I know the code loads srfi-1
<NewGuixUser>so I guess it's using the wrong member procedure
<ulfvonbe`>note that the uses of modules in the "host" and "build" sides are independent
<ulfvonbe`>this looks like it's used in the host side
<ulfvonbe`>so, for example, a #:modules argument to the package won't affect it
<NewGuixUser>This is all happening in a manifest file
<ulfvonbe`>and it has a (use-modules ... (srfi srfi-1) ...) somewhere before where this is defined?
<ulfvonbe`>or a (define-module ... #:use-module (srfi srfi-1) ...)
<NewGuixUser>the former
<ulfvonbe`>then that is strange indeed
<ulfvonbe`>my tests in a repl suggest that after (use-modules (srfi srfi-1)), a plain 'member' should refer to the srfi-1 member
<NewGuixUser>rekado had written the bulk of it while trying to help me effectively do this but for python3.8.5
<ulfvonbe`>you could check whether replacing the 'member' on that line with '(@ (srfi srfi-1) member)' makes it work
<NewGuixUser>I'll try that once this current build either succeeds or fails. I ended up going back to a very simple/naive approach in hopes that I can get something building
<NewGuixUser>I can't tell if that helped or not because I can't figure out which channels.scm I used with it and haven't been able to reproduce the error. I've just been trying so many different things.
<NewGuixUser>One interesting thing though is if I build python@3.8.5 and use a transformation to skip tests the build fails due to missing zlib, but if I don't skip tests the build succeeds and then fails on a test
<ulfvonbe`>could you paste a more-or-less minimal reproducer of that?
<NewGuixUser>ulfvonbe`: of my python3.8.5 stuff you mean?
<ulfvonbe`>of anything you'd like a closer look at, really
<jaeme>When should I CC people from the mentors team?
<jaeme>I noticed that theres no team within scope of gnu/packages/wm.scm
<NewGuixUser>ulfvonbe`: so here's my manifest and channels I've gone back to a much more simple approach just trying to get really anything building. I can run that with "guix time-machine -C channels.scm -- environment -m manifest.scm -c 0" and I get an environment with Python 3.8.5 as expected, but the pypi packages
<NewGuixUser>are still built with 3.9.9 so they aren't available in the python repl.
<ulfvonbe`>I would expect that's happening because you're using a graft to go from 3.9.9 --> 3.8.5
<NewGuixUser>I originally tried to do a package transformation but that was when I was getting those odd build issues so I switched to pulling it from guix-past and the build succeeds
<ulfvonbe`>you can use with-input instead of with-graft. It will result in the builds being done post-replacement, instead of first building everything with 3.9.9, then trying to patch all references to refer to 3.8.5
<NewGuixUser>so just swap out with-graft for with-input?
<ulfvonbe`>should work, yeah
<ulfvonbe`>note that it will likely cause significantly more builds
<NewGuixUser>Ok I'll try that now and see
<NewGuixUser>rekado was trying to help me reduce the number of builds, but honestly if I can just get the packages I need built I'll put up with any number of builds
<NewGuixUser>Ok so switching to with-input fails when building "python-pytest-forked-1.3.0". The log doesn't help much, just says there was an uncaught exception
<NewGuixUser>I can skip the tests on that and get further, but then a direct dependency of numpy ends up failing a test case. I'm a little hesitant to skip the tests on that one since it's a direct dependency"
<NewGuixUser>Ok I think this is my last question for now. So I ended up skipping that direct dependency and numpy built fine, it exists in the environment with the right python version and I can import it. However, if I rebuild and don't skip numpy's tests the build fails and the error is "ModuleNotFoundError: No module named 'numpy'". I'm assuming there's
<NewGuixUser>something odd going on where the tests are expecting the package to be installed under a specific version of Python and that's why they're failing, but I don't know how I could confirm that. Do you have any advice on how I should proceed? It looks like I can install it fine, I'm just wary about installing packages that look like they work but don't
<NewGuixUser>actually work.
<Kolev>Where is the system declaration for the installer? I want a live system with GNOME.
<Lumine>Hello, linux-libre-deblob-check-6.5.9-gnu fails to build this morning on a hash mismatch
<Lumine>First time I see this fail
<NewGuixUser>rekado: Whenever you're online I would appreciate it if you could take a look at this That almost builds properly and the couple remaining errors were things that I thought could be resolved by adding back in the cut? strategy you were helping with earlier. However, when I do that I get back to the same
<NewGuixUser>build failure on "python38-attrs-bootstrap" we saw previously. I'm hoping there's just a bug in the recursion because otherwise I'm unsure what else to try.
<jbnote>Hi there, i'm using Guix on a cluster configuration, as described /home is also shared, as you can imagine. The nodes are GuixSD (completely diskless and netbooted, but this is a detail); they mix x86_64 and aarch64. Problem is, the default profile as setup with /etc/profile is from one arch. Is there a standard way to handle this use case? I'm starting to
<jbnote>customize /etc/profile to source different profiles depending on the arch but i'm anticipating problems with guix install being hard to use for simple users (would there be a way to customize the "default profile" through environment variables?) and guix home does not seem compatible with this approach (unless ~/.profile can be also customized?)
<jbnote>same for the default profile used by guix pull BTW: can it be customized dynamically and transparently through environment variables?
<lilyp>jbnote, you can use (getenv) in your config.scm
<lilyp>I'd recommend doing that + (operating-system (inherit base-config))
<rekado>NewGuixUser: and channels:
<rekado>NewGuixUser: this builds python38-attrs-bootstrap and many more just fine
<rekado>but once those python38-* packages have been built there’s another round of builds which is not correct
<rekado>I’m busy most of the day today, but I can take a closer look later
<jbnote>lilyp: thanks a lot. I'm a bit new; which config.scm are you referring to? there are so many config hooks that it is not clear to me :)
<lilyp>jbnote most folks refer to /etc/config.scm when they say config.scm – the one you use to reconfigure your operating system config
<lilyp>not sure what the canonical name for your home config is
<cow_2001>How did you put links in Guix search output? I see, for example, a license "ASL 2.0" is a link to the GNU web page describing the license.
<theesm>Lumine: there has been an update to the 6.5.x linux-libre deblob-scripts in linux-libres upstream three days ago that causes the hash mismatch to happen, should be quick to fix
<Lumine>theesm: all right
<jlicht>Just sent a patch to the ML to fix the hash:
<jlicht>I've been a bit out of the loop, what's this "Change-Id" that is now added to my commit messages?
<Lumine>jlicht: thanks!
<jlicht>rekado: thanks! That's a pretty nifty feature to have \o/
<graywolf>This is interesting, when using guile-build-system, the target output directory's scm path is *not* added into %load-path, but go path *is* added into %load-compiled-path. Would anyone know why?
<graywolf>Seems weirdly asymetrical, so I assume it is intentional.
<vivien>I am skeptical installing the scm files is needed at all.
<graywolf>Isn't having the source code useful (for a user) when trying to figure out how stuff works?
<graywolf>I guess there could be a separat :scm output I guess...
<vivien>We don’t install source code for C programs and libraries
<graywolf>Hm, fair point. I somehow consider "scripting" languages different, but cannot exactly pinpoint why.
<nckhexen>cow_2001: The <license> record has an URI field, and helpers like non-copyleft take one as an argument (although it's frequently a relative file:// link into the source so won't 'do' anything; this is fine). If you mean lower-level: because package->recutils emits them:
<snape>Hi, how can I use guix shell so that it sets GUILE_LOAD_PATH corresponding to my currently pulled guix?
<snape>so that I can use guix modules from there
<snape>it seems to me that 'guix shell -C guile guix' sets GUILE_LOAD_PATH corresponding to the guix package, which is old
<graywolf>snape: How are you running the guile? Using `guile' command?
<snape>well yes
<graywolf>Can you use `guix repl' instead?
<snape>i don't want to use guix repl because my goal is to put this in direnv
<graywolf>Running just guile does not set the paths correctly afaik, but I will not pretend why. There was a fairly deep dive into this done on a bug tracker for a popular channel that packages non free software. You could try reading more there (MR about .dir-locals.el).
<graywolf>Maybe that will help.
<graywolf>not pretend to understand why*
<cow_2001>The magic is in colors.scm's definition of the procedure "hyperlink": (string-append "\x1b]8;;" uri "\x1b\\" text "\x1b]8;;\x1b\\")
<snape>graywolf, do you have a link to the ticket?
<graywolf>I do, but I think pasting it here would violate the channel rules, which I do not want to do, sorry.
<graywolf>ACTION wonders how to direct messages in irc
<snape>what rules
<graywolf>"Please do NOT promote or refer to this repository on any official Guix communication channels."
<snape>that's not a guix rule
<snape>not that I know
<snape>and you already broke it btw
<snape>I guess my solution is to manually set GUILE_LOAD_PATH to ~/.config/guix/current/share/guile/site/3.0
<vivien>I seem to remember #guile was not open to participation of the public, is it still true?
<snape>I don't think it's true
<vivien>snape, would you try to say something there?
<snape>well no because it's really a guix issue
<snape>a 'guix shell' issue
<vivien>Sorry my question was unrelated to yours
<snape>ok I said sth
<snape>it worked
<vivien>Did you get back my o/?
<vivien>OK so that’s just me then!
<vivien>Maybe I’m banned? How would I know?
<snape>they say: "Nobody is banned!"
<snape>so I don't think you are
<snape>maybe you need to be logged in
<phf_>Hi #guix! Where can I find help to make a build system reproducible? I've this result: from: diffoscope --html diff.html /gnu/store/gjg...-elixir-dialyxir-1.4.1 /gnu/store/gjg...-elixir-dialyxir-1.4.1-check
<civodul>phf_: hi! there are several strategies
<civodul>one is to check the build logs and/or the code for things that record timestamps, which is quite common
<civodul>that typically leads to either entire strings (date/time) or 32-bit values to change in the resulting binaries
<phf_>Hi civodul! You have all my attention.
<civodul>the other approach is to start from the binary diff reported by diffoscope and figure out how that file is produced, what the differing bytes represent, etc. (harder!)
<civodul> has some tips
<civodul>another strategy is to look for bug reports and patches in Debian :-)
<civodul>though apparently there’s no “dialyxir” package there
<civodul>you can also check the issue database at
<phf_>I'm pretty new to these things. You mean that people in Debian have Elixir packages and should have face the same reproducibility issues and should have also found fixes?
<civodul>reproducibility issues are usually shared among all distros
<civodul>and Debian is one of the most active distros fixing these things
<phf_>So, I'll look at other dristros since Debian does not have a dialyxir package.
<phf_>So, to understand what's happening here: a value may be time dependent at compile time and then transported in the resulting artifact.
<phf_>That is the main reason of non-reproducibility and other causes are to be found in
<phf_>Ok, I'll try: 1) check the build logs and/or the code for things that record timestamps 2) bug reports and patches in a distro, maybe Debian 3) issue database and 4) diff reported by diffoscope and figure out how that file is produced
<phf_>Great, thanks civodul!
<civodul>yw :-)
<phf_>If all Guix packages are supposed to be bit reproducible, then I guess that rebar3 is not since I get: from: guix build --rounds=2 -K rebar3 and diffoscope --html /tmp/diff.html /gnu/store/1ylhh2j996bnnm9mxac2d7y06c7l0fa6-rebar3-3.18.0 /gnu/store/1ylhh2j996bnnm9mxac2d7y06c7l0fa6-rebar3-3.18.0-check
<jaeme`>What should I do if my patch hasn't been responded to in nearly a week?
<mirai>sneek, later tell phf: perhaps a matter of supporting SOURCE_DATE_EPOCH ?
<nckhexen>vivien: You need to be registered with (and logged into) NickServ to speak in #guile.
<nckhexen>Or a chanop needs to unset +R on the channel.
<vivien>nckhexen, I constantly bump into the same issue and forget the details a few months later
<vivien>If the channel message could make it explicit, that would be nice
<vivien>the welcome channel
<vivien>the welcome message*
<nckhexen>#guile doesn't have an entry message, but civodul could set one with ‘/msg ChanServ SET #guile ENTRYMSG Blah blah welcome to #guile blah blah.‘. Or add it to the topic. I'm not a chanop there.
<nckhexen>jaeme: You can send a ping to the bug# and/or link it here asking for reviewers.
<vivien>nckhexen, when I join, I get: Welcome to #guile. See for more information. Guile 3.0.9 is out! <>. This channel is logged, see <>. Bug database at <>.
<vivien>That’s what I mean by “welcome message”
<nckhexen>That's the topic. Entrymsg is an extra message (#guix has one).
<nckhexen>It may also be that the reason for having +R set has passed.
<nckhexen>Only civodul (or wingo) can say.
<mirai>lilyp: WDYT on renaming service fields directly with no deprecation warning as described in <>?
<mirai>tldr; use NEWS to announce field renames & co. instead of spreading deprecation-handling code
<pastor>Is it posible to use `substitute*' to replace multiple lines?
<NewGuixUser>rekado: Thank you, I'll give those a try now and see if I can figure out any of those new failures
<nckhexen>sneek: later tell pastor Sometimes. Depends on the exact requirements & how hacky a result you can get away with.
<santiagopim>Hi, 'guix pull' creates a new generation in the 'guix describe' stack, but how can you list or switch those generations ? When 'system' or 'home' it is possible to browse the respective generations.
<santiagopim>I usually use 'guix describe; guix system describe; guix home describe' as a command in my bash prompt.
<NewGuixUser>Looks like the cut? isn't working quite right. My build hasn't failed yet but it is currently trying to build inkscape. It's weird because I feel like I understand how cut? works and it seems clear to me that it should be skipping inkscape.
<lilyp>mirai: As Ludo points out, longer-term we need a way to signal deprecation :)
<rekado>NewGuixUser: this is what I’m working with right now:
<rekado>python38-pytest-asyncio fails its tests, though
<rekado>perhaps the old package definition does not respect #:tests?
<santiagopim>Well, I suspect 'guix pull' has no possible roll-back, so no listing or switch. Only with version controlling the 'channels' definition, if there is any customization there ... *digging
<nckhexen>santiagopim: Why don't --list-generations and --roll-back suffice?
<santiagopim>'guix system' and 'guix home' have that options, but for the 'guix pull' there is not.
<nckhexen>I'm not aware of any breakage in that area.
<nckhexen>What happens?
<santiagopim>Not a bug, just asking. Try 'guix describe; guix system describe; guix home
<santiagopim> describe' to see the different generations stacks.
<santiagopim>* ups
<nckhexen>‘guix pull --list-generations’ or ‘guix pull --roll-back’ no longer working is definitely a bug.
<nckhexen>But we'll need more info if so.
<santiagopim>Ah, didn't know it worked ... let me try again.
<nckhexen>All options listed by ‘guix pull --help’ should work.
<santiagopim>Ups, yes. Working. My fault ... so ashamed :|
<nckhexen>No need.
<nckhexen>All these options & subcommands & profiles can be confusing.
<nckhexen>And to your point: I do also recommend keeping your system configuration under version control, like all code.
<nckhexen>But that's separate from Guix.
<santiagopim>Yes, thank you a lot.
<RavenJoad>Hey Guix! I have factored the base16/32/64 modules out to a separate library. Did I miss anything when factoring these modules out?
<vivien>I think QA won’t build my patch series,, because it can’t build the tip of gnome-team to compare
<vivien>If I click “View Guix Data Service comparison” link, I go to
<vivien>And the “base commit”, which is the tip of gnome-team, is marked as “yet to process revision”
<vivien>And sure enough, gnome-team points to 2677bf985c. QA has not built that yet:
<vivien>The QA page for gnome-team has the same problem:
<vivien>Could someone restart that revision?
<NewGuixUser>rekado: I'm running that build now. Is there a reason we couldn't just skip the tests with a transformation on python38-pytest-asyncio?
<NewGuixUser>Wait it looks like you've already disabled tests with "#:tests? #false"?
<NewGuixUser>nevermind I just read your next message
<Lumine>Hi, after fresh guix pull, Guix tries to build linux-libre-6.5.9-guix.tar.xz but fails on this part:
<NewGuixUser>rekado: I was just double checking my existing requirements.txt and saw that I need to include boto3 and do not need to include pytest-asyncio. I'm going to make those changes to the latest manifest you shared and see if that builds. I must have tried adding in an old pytest-asyncio at some point to work around another build issue.
<nckhexen>Lumine: Thanks for the report. I'm trying to reproduce it. I've also noticed something's wrong with the deblob script hashes.
<Lumine>nckhexen: a patch was submitted for the hash earlier by jlicht
<nckhexen>Lumine: Thanks. Pushed.
<Lumine>nckhexen: nice
<NewGuixUser>python-pytest-asyncio still fails. I guess I'll try re-enabling tests in the python38 function but disable them specifically for python38-pytest-asyncio in my initial transform function. If that still fails my only other thought is to copy the package code into my manifest and manually remove the tests.
<NewGuixUser>rekado: I'm assuming that lines 1810-1812 are overriding the "#:tests? #false". This is what my manifest currently looks like
<NewGuixUser>Lines 1810-1812 here I mean
<Altadil>Do we have in the documentation some examples of good and bad outputs of guix build --rounds=2 ? I mean, when testing for reproducibility.
<rekado>NewGuixUser: that’s right. This 'check phase ignores #:tests?.
<rekado>so we’d need to modify this package and delete its check phase directly
<nckhexen>Altadil: What kind of examples? (But no, I don't think so.)
<nckhexen>Mainly because ‘good’ is identical output, and ‘bad’ is anything else.
<Altadil>nckhexen: one for a package that builds reproducibly and an example of one of the types of common failures. I’m very new, so I find it difficult to understand the output of the command.
<NewGuixUser>rekado: I've created this package that deletes the check phase and pasted it into my manifest Do I need to implement a wrapper function similar to what guix/packages/python has for python3?
<nckhexen>Altadil: I don't remember what exactly it prints, but all it does is report whether both builds are identical. It does not give hints or report common failures.
<nckhexen>That is up to you, a suspected human.
<nckhexen>Altadil: If you're at a loss for what to do when it reports a mismatch: use --keep-failed, then use diffoscope to compare the two reported store items.
<Altadil>nckhexen: I guess I’m missing basic understanding of it then. ^^
<Altadil>It’s telling me about the sucessfull build, as it does without the rounds option, but then prints :
<Altadil>The following build is still in progress:
<Altadil> <path to the same drv>
<Altadil>and finally shows the path of the package
<Altadil>nckhexen: Sorry, I wasn’t clear : I don’t even know if what I am seeing is OK or not
<nckhexen>Oh, let me see.
<rekado>NewGuixUser: I do this now as part of the python38 transform:
<rekado>added a special case for python-pytest-asyncio
<rekado>(situations like this are the reason why we added #:tests?)
<nckhexen>Hm. I agree that this is a bit confusing. ‘guix build --rounds=2 hello’ does absolutely nothing twice, and immediately reports an already built hello. ‘guix build --check --rounds=2 hello’ does the pedantically correct thing, which you must be a seasoned Guixer to recognise (test the grafting derivation twice), so what the average user would want is ‘guix build [--rounds=N] --check --no-grafts PACKAGE’.
<nckhexen>Not great UX, and maybe could be improved beyond merely documenting the status quo.
<NewGuixUser>I'm seeing a build error on python38-importlib-metadata which I could have sworn had been building previously, but I may be mistaken
<fnat>If I roll-back to a previous generation - say from 100 to 90 - and then redeploy (in my particular case, this means "guix home reconfigure config.scm"), what I get is generation 91, which overwrites the original generation 91 - is my understanding correct?
<Altadil>nckhexen: Ok, it’s clearer in my head now, thanks!
<nckhexen>fnat: I think so, or something very close to that. There isn't some fancy undo tree.
<rekado>NewGuixUser: I’m still building pandas…
<fnat>nckhexen: oh ok, no prob, I can live with that - good to know I wasn't missing anything major then - thanks
<rekado>NewGuixUser: it complains about not having setuptools>=56
<NewGuixUser>rekado: I think mine tried to build importlib-metadata before pandas, at least for me pandas is at the bottom of the "The following derivations will be built:" list
<johnwind>happy holloween everyone. I have a question about eBPF and the package bcc. I couldnt import it while using python, does anyone have any experience on setting up bcc ?
<rekado>added a new special case for importlib, but matplotlib fails for a similar reason
<rekado>(it’s a bit annoying that Guix keeps downloading the replacement sources over and over again)
<rekado>(this still fails on matplotlib, but we’re getting close)
<NewGuixUser>My build is running now
<nckhexen>fnat: Sorry for the disappointing answer. If you want to document your journey it would certainly be a welcome addition to the cookbook. If ‘guix build --check --no-grafts […] PACKAGE’ doesn't say ‘differ’, but just prints a store file name, that's good.
<Altadil>nckhexen: not disappointing at all! You’re helping me a great deal, thanks. :)
<Altadil>I guess we should document this in the "22.7 Submitting Patches" part of the manual, since that is what I was getting my initial info from. I haven’t looked into how to contribute documentation yet, but I’ll try to make this my next patch after this one I’m testing.
<NewGuixUser>Ok my build finally finished. I'm looking at that matplotlib error now.
<NewGuixUser>This error is bizarre. I thought that maybe the issue was that setuptools wasn't installing properly and we're just seeing it complain about the setuptools_scm_git_archive plugin but that doesn't seem to be the case.
<nckhexen>Something about how Guix runs the deblob scripts results in a different output than GNU's own run, and hence us failing the blob test:
<nckhexen>Pretty colours:
<cbaines>vivien, regarding processing revisions for gnome-team, you can see the queue here
<cbaines>it just hasn't been processed yet
<jaeme`>May someone review my patch for ani-cli? <>
<nckhexen>‘inferior propagated-inputs’ ♥
<jaeme`>And when someone does that, can they close the cloned issue? <>
<jaeme`>or merge it
<nckhexen>I've merged it, but it hasn't showed up yet.
<nckhexen>jaeme`: Where do you get gpl3-only?
<nckhexen>All mentions I find say ‘either version 3 of the License, or (at your option) any later version.’.
<jaeme`>nckhexen: wdym?
<nckhexen>I think this is your latest version, which as license:gpl3:
<nckhexen>Shouldn't it be ‘license:gpl3+’?
<nckhexen>Just want to check I didn't miss a ‘version 3, full stop’ somewhere.
<jaeme`>Oh, I just checked the LICENSE file of the project repo and it says gpl3, I don't see where it says and later.
<jaeme`>oh wait
<jaeme`>I see it in the man file
<nckhexen>And in the script itself.
<jaeme`>nckhexen: You're right it should be gpl3+.
<jaeme`>Should know better to check further than the LICENSE file.
<nckhexen>Counterintuitively, LICENSE or COPYING files aren't the ideal source of licencing information, since they just say ‘yo I'm the GPLv3’. A file header with ‘this software is licenced under the GPL, but only uneven versions, and under the MIT licence if you're Spanish’ takes precedence.
<jaeme`>Why couldn't they have a nice gpl3+ flair in their README /half-joke?
<jaeme`>nckhexen: yeah so I have to check out for that.
<nckhexen>No biggie. I'll adjust it here, I just wanted to double-check.
<nckhexen>(General WTF) uhm does the copy-build-system just compeletely ignore cross-targets? Like, at all? Because that does seem to be the case.
<nckhexen>Reader, it does.