<dongcarl>But somehow him doing `guix pull` solved it and it didn't for me? <OriansJ>dongcarl: guix pull updates the version to the latest published and the later published version can be different and thus not have the build problem the currently published one does. <dongcarl>OriansJ: You're saying he was on an earlier version than me? <dongcarl>Looking at the guix codebase there hasn't been any changes to the mariadb packages since Nov 23 <dongcarl>OriansJ: Looking at mariadb's bug trackers this seem to be caused by race conditions... It seems I need to make that test single threaded <dongcarl>what's the best workflow for mucking about with the package definition locally? <OriansJ>dongcarl: that very well would be non-deterministic behavior in a package's build <OriansJ>dongcarl: just copy it into a text file and use guix build on it <OriansJ>This can be done for any package you want; it makes it trivial to experiment locally before creating patches or pull requests *dongcarl is excited about his first guix package! <OriansJ>dongcarl: for example, you could very easily take the current guix package definition for bitcoin-core and simply modify it and publish and all guix users would be able to download that definition and build it. <OriansJ>It makes creating new packages and updating packages very easy for everyone <dongcarl>Nice! A lot like the AUR but much nicer! <OriansJ>plus it has numerous other advantages <vagrantc>oh, didn't know about that way of creating ad-hoc package definitions <eubarbosa>Thats really sweet! Up to channeling Pandoc hehe <OriansJ>vagrantc: it is a way of giving users power and the ability to get their hands dirty in a way that solves their personal problems while giving them something they can contribute back to the community <dongcarl>Once I've got a working definition, how do I contribute it upstream? Also, can I just build bitcoin-core now and it will know to use the working one? <dongcarl>I think I got the definition working with a 1 line change haha, there was already a list of flaky tests, just added it to that <vagrantc>OriansJ: sure! just didn't know that specific mechanism before <vagrantc>i first tried GUIX_PACKAGE_PATH and dropping files in there ... then i just started using a local git repositorying and "guix pull --url=/path/to/local/git --commit=..." ... and lately i've been "building from git" from the manual ... but that had some weird issues too. <OriansJ>dongcarl: once you have the definition done, you can install it using guix package <dongcarl>OriansJ: Cool! It built successfully :-) <OriansJ>dongcarl: now guix package -f filename.scm <OriansJ>replacing the name with the one of your file with your definition. <OriansJ>or you can use --ad-hoc to play with it but not have it in your package list <dongcarl>I did a `--check` and it seems like there are even more flaky tests... <dongcarl>Guess I'll include all of them in `unstable-tests` <OriansJ>for example if you didn't want games in your package lists but you really wanted to play freecell; guix environment --ad-hoc aisleriot --fallback && sol <dongcarl>OriansJ: Is an ad hoc environment temporary? <OriansJ>dongcarl: well the package will exist in your repo until you do a guix gc <OriansJ>But effectively it is a temp environment for experimentation or development <dongcarl>Could I build (but not install) bitcoin-core and specify to use my file for the mariadb dependency? <OriansJ>for example you need a bunch of programs to build debian's jack https://github.com/jack-cli-cd-ripper/jack and there isn't a package definition in guix (there isn't) and you wanted a way to figure out the dependencies for building jack the cd ripper; --ad-hoc makes it rather easy <dongcarl>I guess I'd use `guix build -L <dir/of/mariadb.scm> bitcoin-core`? <OriansJ>dongcarl: you have a bunch of options <dongcarl>I installed mariadb with `guix package -f mariadb.scm`, but it seems that `guix build bitcoin-core` still wants to build mariadb itself <vagrantc>it doesn't use installed packages to build <vagrantc>it builds a build environment on the fly with the packages needed to build <dongcarl>I see, how can I do: build bitcoin-core but with MY version of mariadb as defined in mariadb.scm? <vagrantc>i presume you'd have to include it in the foo.scm that you're building bitcoin-core with <vagrantc>but i haven't used this approach so just guessing <dongcarl>:-/ I'm using the bitcoin-core definition from the guix repo, didn't write my own .scm <dongcarl>OriansJ: I don't think `guix environment` takes in `-f` <OriansJ>dongcarl: fyi all guix commands have a --help option <serichsen>If I find that I need to build a custom kernel, how would I go about that? I found linux.scm in the guix/packages directory, which defines linux-libre packages. I'd add a personal channel to make a modified version, but what parts do I actually need from there? <dongcarl>I'm doing `guix environment --ad-hoc mariadb.scm -- guix build bitcoin-core` <OriansJ>dongcarl: you might wish to note --bootstrap <dongcarl>I'm going thru the guix manual right now <OriansJ>--help gives a quick list of options <dongcarl>OriansJ: Yeah... I've been using that but it's a little vague for someone new to the tools/mindset <dongcarl>Hmmm that `guix environment` one didn't work... <mange>dongcarl: You can use --with-input to replace a dependency. Load a file that defines a different mariadb version (with -L) and call it something like my-mariadb, then use --with-input=mariadb=my-mariadb. <dongcarl>I'm getting errors if I don't change anything <mange>Was that meant to be a paste of mescc-tools? <mange>Also, I don't really know what you're trying to do. Are you trying to build a version of bitcoin-core with a different mariadb dependency? <dongcarl>Exactly, build a version of bitcoin-core with a mariadb package definition that I've fixed (the one in guix is broken) <dongcarl>The file name needs to be the same as the module name <dongcarl>I just changed the module and file name to both be bitcoin, and changed the package name to be my-mariadb <mange>I would have thought you could write a file similar to that mescc-tools one, but called my-mariadb then run "guix build -L my-mariadb.scm --with-inputs=mariadb=my-mariadb bitcoin-core". <dongcarl>mange: Unfortunately not... that file was more for consumption by `-f`, but `-L` expects a directory of module files <mange>It should work with -L as well. <mange>Ah, right. -L has to be a dir, not a single file. If you put http://paste.debian.net/1061652/ ./my-mariadb/my-mariadb.scm then run "guix build -L my-mariadb --with-inputs=mariadb=my-mariadb bitcoin-core" then it should start building. <mange>Although, actually, you need to change the source URL. <dongcarl>Yup I did something similar and it started working! <mange>It uses name, but I changed the name, so it broke that. <dongcarl>I think with all the changes I'll have to make I might just start a bitcoin guix channel for my own package definitions <mange>Why is this change necessary? Is it something that should be in mainline Guix? <dongcarl>mange: The changes to mariadb should be in mainline Guix, the mariadb package in mainline guix right now fails to build if you have too many cores <dongcarl>Okay! Now I can finally solve reproducibility issues in bitcoin-core <dongcarl>It would seem that for several files, there is a difference in the number of "Links" <OriansJ>dongcarl: one possible meaning is there are a different set of files or that the number of files included is not consistent <dongcarl>OriansJ: It would seem that running `diff -rl if8q3l3mmk3mk38c2vznpla55dms5l3j-bitcoin-core-0.16.1{,-check}` shows that only the `bitcoin-qt` binaries are different <dongcarl>perhaps I should ignore the "Links" that diffoscope turns up? <mange>I think that it refers to the number of hard-links to the file. Guix de-duplicates, so the number of hard-links might be different. *dongcarl figuring out how to set an env var to make qt not non-deterministic based on time <dongcarl>How do I set an environment variable for a package build? <dongcarl>I have reproducible builds for bitcoin! :-) <dongcarl>So just to confirm I'm not crazy... A successful `guix build` followed by a successful `guix build --check --no-grafts --keep-failed` means that I most likely have reproducible builds working, correct? *dongcarl waits patiently <mange>If the --check build passes, then that's a good sign for reproducibility. You could also try using --rounds, but I assume it would give you the same result. <mange>The first thing to do to upstream your changes is get get a git checkout working. See "(guix) Building from Git" in the manual. <mange>Then see "(guix) Submitting Patches" for details about submitting patches. <jonsger>is the release of 1.0 "scheduled" before, at or after the FOSDEM? <reepca>civodul: question regarding warn-about-old-distro: is the objective to warn about the guix that is currently running or the guix the current user has most recently guix pull'ed? <jonsger>guix 0.16 now finally arrives in opensuse tumbleweed :) <civodul>reepca: about the guix currently running <reepca>wouldn't the "time" to compare the current time to be known at compile-time then? <jonsger>I just forgot to submit it, because I was busy with guile-2.2 stuff... <efraim>If anyone is curious, special-files-service-type can be used to plop a file into /etc <civodul>reepca: it is, but we don't want to make the build time an input to the derivations <civodul>jonsger: re 1.0, it's scheduled before FOSDEM but... i don't know what rekado_ thinks but i think it might happen after :-) ***rekado_ is now known as rekado
<rekado>I think we’re making good progress towards 1.0, but I don’t want to rush it. I think it would be fine to have a release after FOSDEM if this means that we can fix a few more bugs. <rekado>civodul: I wonder if maybe some of the Guix modular outputs we serve from berlin are broken. <rekado>we’ve had a lot of people report that miscompilation bug after “guix pull”. <efraim>the last time 'hydra' successfully built was march 2017 <rekado>I’ve been trying to upgrade scons to 3.0.3, but I’m getting a weird byte vs str error. I’m guessing that this is something to do with Python 3.7. <efraim>we probably should've waited for 3.7.1 <rekado>do you know of a way to work around a problem like that? <rekado>the error is “TypeError: a bytes-like object is required, not 'str'” and happens in Python 3.7’s imp.py <efraim>although I guess that's using scons and not building scons <rekado>I’m trying to use old.encode('utf-8') now. <civodul>efraim: uninteresting if you ask me ;-) <roptat>sounds good, but it'll give me more work :) <g_bor>civodul: this seems like it mixes Guix and Guix System stuff more. If this is the direction you set, then it looks good to me. However, this should be accompanied with relevant changes on the website. There were several discussions that revolved around the confusion between Guix and Guix System. WDYT? <civodul>roptat: heh, for sure! though the actual text is mostly unchanged <civodul>i thought we'd rather do it before sending things to the TP <civodul>g_bor: yes, you're right, we'll have to work on related changes on the web site, etc. <rekado>g_bor: yes, the goal is to “despecialize” GuixSD and have it become “Guix system”. <civodul>Lprdn seemed like they might be intesrested in working on the web site <g_bor>Ok, thanks for the clarification. I think these changes are fine then. <rekado>ugh, scons sources are littered with __DATE___ … <g_bor>anyone more into java than me? <g_bor>I have a classes/module-info.class that is not reproducible. Any idea? *rekado is not into Java in any sense of the word <g_bor>rekado: it's in openjdk11, embedded into java.base.jmod <g_bor>rekado: I don't know yet, I am currently at the sympthom level. <g_bor>Digging this info up was not even very easy, as diffoscope can't handle jmod yet. <g_bor>What I believe, that this problem comes in concert with libs/modules not reproducible. <roptat>g_bor, there should be a module-info.java file, no? <g_bor>roptat: I will have a look around... <g_bor>but if there is, then it is the same, as it is not shown in the diff... <roptat>can you use openjdk11 to build a module-info.java and see if that's reproducible? <g_bor>ok, I will have a look around. <g_bor>At least it is not in this archive. <roptat>g_bor, it's probably somewhere in the sources <g_bor>yes, most probably, and I guess it is generated... <roptat>btw, I've updated my gradle package and now I'm absolutely sure it requires kotlin <roptat>its build file is even build.gradle.kts ^^" <g_bor>│ │ #493 // jdk.management.jfr <g_bor>│ │ - hash: [5300a40a9429c79edceb7e2a6fcac0ca6ad534329bf494b431f693f8123a501d] <g_bor>│ │ + hash: [acdbbcd705d86c2d01ae62163818026e2776c0267d42f191f7d35ebeb48da882] <g_bor>│ │ - hash: [9825f0c9f647f6574fad6650dcf084d72fa755798e3fa5b280eabfd2c522b38a] <g_bor>│ │ + hash: [6fa3454e132684dcab925d69c4ee5dee1d472a8c6002b88c06538e43f5d49346] <g_bor>something like this from diffoscope. <roptat>g_bor, actually, can you send me the files? <g_bor>yes, I can. How should I pass them? <roptat>mail or any file sharing website <g_bor>They also have an embedded jar with the timestamps problem, but that is not bothering me, we have a soultion for that :) <g_bor>Is it ok for you to send the slightly modified version with the binary header strippes, so that you can use zip and diffoscope on them, or you need them as they are generated? <roptat>the modified version is fine with me <roptat>civodul, so the failing test is a curl test, where an invalid url is generated. the expected error is "invalid protocol" or something, but the actual error that happens is "malformed url" <roptat>looks like curl changed its validation algorithm <g_bor>roptat: meanwhile I squashed one, ct.sym is a zip archive embedded in jdk.complier.jmod, and that seems to be the only cause of difference there. <roptat>g_bor, well, giving my email address to someone else is not very nice :/ <roptat>I was thinking a website that just gives you a link that you can send however you like <g_bor>roptat: ouch, sorry about that. <roptat>so there's classes/module-info.class and lib/jrt-fs.jar in that file that differ <roptat>the later looks like it's simple to fix <g_bor>I will do that later today, or tomorrow. That leaves them module-info stuff. <g_bor>I will try to send you the lib/modules also, I think it is related <roptat>so, it's a list of hashes of other modules <g_bor>yes, I belive they are the modules I would like to pass to you now. <g_bor>ok, they are being uploaded, I am very low on upload bandwith here... <efraim>is there an alternative miniperl implementation somewhere? <roptat>shows the option that's used to generate these modulehashes <roptat>I wonder if we could add a phase to rehash everything before repacking? <roptat>I'm a bit confused by how it works though <roptat>does it mean it hashes dependents instead of dependencies? that's weird <g_bor>I believe we can, but not before the modules themselves are really the same... <g_bor>something seems to be off at generating thes modules... <g_bor>what I've found out so far regarding the modules file, is that it is an undocumented binary format, that can change at any time... <civodul>roptat: if PHP happens to make assumptions about curl that are no longer valid, we can skip that test <g_bor>the other is still uploading ***massimo_zaniboni is now known as mzan
<g_bor>I have to now, have a nice day! *civodul thinks we should make t-shirts with "Hello Guix!" on the front and a logo on the back :-) <civodul>i find it funny that newcomers already know that "Hello Guix" is how we greet each other :-) <tune>is there a #guix-offtopic or similar where people hang out? <OriansJ>tune: dozens of different channels like #bootstrappable for those in the bootstrap team or #guix-homesteading, etc With some busier than others <roelj>How can I make a tarball (with guix pack?) of a certain profile generation? <rekado>roelj: looks like you can’t (yet). “guix pack” will always build a profile. It doesn’t take a store path as an input, though I suppose it could. <roelj>rekado: Okay. So I could just pack all the packages in the profile generation with the same version of Guix of that profile generation, and it should produce something similar. <rekado>yes. You can also use a manifest. <tune>OriansJ: what is #guix-homesteading about? <efraim>It's been pretty quiet recently, but mostly about homesteading and not much about guix <OriansJ>tune: it is a discussion area for people interested in homesteading <dongcarl>Hi all, what should the body of the message be when sending in a patch? Just the result of `git diff` when invoked from the guix repo? <rekado>dongcarl: the body can be the result of “git format-patch -1” <rekado>dongcarl: or you could use git send-email <dongcarl>rekado: :-/ Don't have command line email set up <rekado>then “git format-patch” is the tool to use <rekado>it generates patches that you can attach to emails. <dongcarl>Okay I sent in the patch for mariadb, is there a place to check on the CI on the patch? (sorry GitHub n00b here) <dongcarl>rekado: No I know, I'm just saying what's the equivalent of checking CI on GitHub on your system (which is hydra?) <roptat>we don't have CI for patches (yet) <roptat>our CI is actually our build farms, and they build only packages that were already added to guix <roptat>so, you'll get actual human feedback when someone will have checked your patch :) <bavier>dongcarl: a few days ago I added "main.mysqldump" to the disabled mariadb tests on the core-updates branch; does it also sporadically fail on master? <dongcarl>bavier: Yup! That one has been very consistently failing <dongcarl>The other one I've added fails about 1/5 of the time <bavier>hydra hasn't built a new mariadb since early december. Maybe it got lucky :) <dongcarl>bavier: Yeah the two I've added have been added to the official unstable-tests list for later versions <dongcarl>bavier: Could you explain to me how core-updates and master interact? <bavier>dongcarl: core-updates gets patches to packages that would cause a lot of rebuilds because they have a lot of dependents <bavier>dongcarl: the build servers usually build out the master branch on a continualy basis, but core-updates less frequently <dongcarl>bavier: Ah I see! I bet mariadb has a lot of dependents huh? <bavier>and when core-updates has been stabilized and built, it is merged into master <dongcarl>bavier: Cool, but the second test I added in there... Will it get into core-updates eventually after people review? <bavier>dongcarl: not a ton, actually, 486, but the test failures at the time were keeping me from building the parts of core-updates I was interested in <sneek>quiliro, you have 3 messages. <sneek>quiliro, reepca says: have you tried 'fc-cache -f'? <sneek>quiliro, adfeno says: Also, I'm trying to debug this by building IceCat with debug symbols enabled, but Mozilla Firefox's Cargo/RustC build system is giving segmentation fault due to some "invalid memory reference" when compiling a specific file (something like "encoding_c", if I recall). <quiliro>there are no .scm files with this example spec <quiliro>is there a manual to add pata support? <bavier>quiliro: trying to get a few package updates polished up <quiliro>what is the syntax for initrd-modules <dongcarl>Hey, I submitted a bunch of patches, they were mostly orthogonal to each other so I submitted them separately. Please let me know if I could format them better or something <dongcarl>Haha no thank YOU guys for making the easiest system to do deterministic builds in <dongcarl>I will be spending some time setting up Bitcoin Core to do deterministic builds in guix now for our releases <quiliro>is there a way to use only substitutes? I am installing in an old machine and i do not have an offload machine available <vagrantc>i don't believe so ... especially if any of the substitutes are missing, then some packages would simply fail to be available <quiliro>then i have to wait and it will work later? <civodul>rekado: i'm looking at the tests/usptream.scm failure; can you remind me why 'input-changes' is thunked? <vagrantc>quiliro: some packages might never become available <roptat>quiliro, and some packages are necessarily built locally (your profile for instance), but they're not special in any way for guix <roptat>if you only allowed substitutes, you would be able to build any profile <civodul>staging has 61.6% substitutes available for x86_64+i686 <quiliro>what is built locally even if substitutes are available for all packages? <civodul>quiliro: things that are specific to your system, such as profiles ***Elon_Satoshi is now known as Copenhagen_Bram
<quiliro>I have successfully: guix system init bare-bones.scm <quiliro>but the following command does nothing: guix system reconfigure /etc/config.scm <ngz>I'm making a package B inheriting from a package A. I want to use new configure flags in B, ignoring any defined in A. Do I need to use `substitute-keyword-arguments' or can I simply write (argumes `(#:configure-flags: ...))? <quiliro>worked: guix system init bare-bones.scm /mnt <quiliro>after reboot: guix system reconfigure config.scm <quiliro>last command gives no output, just command prompt (as root user)