IRC channel logs

2019-01-23.log

back to list of logs

<cnmne>/bye
<cnmne>
<marusich>Hi Guix! As previously announced, I am now changing ci.guix.info to serve requests via CloudFront. I will send another message once the change is complete and verified. There should be no downtime during the change. The original announcement: https://lists.gnu.org/archive/html/guix-devel/2019-01/msg00291.html
<vagrantc>marusich: thanks for work on it!
***catonano_ is now known as catonano
<marusich>This change is complete and verified. Substitutes are now being successfully served via ci.guix.info, over both HTTP and HTTPS like before. You can also continue to access Cuirass via the same website.
<marusich>Note that due to DNS propagation delay, it may take a few hours before you start seeing ci.guix.info resolve to the new CloudFront name (which is d3j65v8i7zliij.cloudfront.net).
<marusich>If you are curious to see how this has all been set up, please feel free to peruse the contents of the "cdn" directory in the maintenance.git Git repository here:
<marusich> https://savannah.gnu.org/git/?group=guix
<marusich>Happy hacking!
<reepca>anyone else's ibus-libpinyin stopped working recently? Mine will start the little popup as I type, but nothing gets sent to the program when I press space.
<reepca>Hm, I get a "locale not supported by C library." message when starting up graphical applications, but I'm on GuixSD. GUIX_LOCAPTH is set to /run/current-system/locale, and my system locale is set to "en_US.utf8". Any ideas?
<marusich>perhaps the version of libc against which the application is linked is not the same version that was used to build the current system?
<marusich>reepca, see https://www.gnu.org/software/guix/manual/en/html_node/Application-Setup.html
<marusich>If the version of Guix you used to reconfigure your system is sufficiently different from the version of Guix you used to create your current profile generation, then it's possible that you are getting the error because the libc versions between those two places are sufficiently different.
<marusich>That section in the manual has more information and a suggested course of action you can try to follow.
<reepca>hmm, if I install glibc-locales for my user, should GUIX_LOCPATH be augmented in ~/.guix-profile/etc/profile? What's the proper place to set it to?
<reepca>I tried setting GUIX_LOCPATH=~/.guix-profile/lib/locale and then running emacs, but still got the same message
<marusich>That's what the manual suggested.
<reepca>well, guess I'll try upgrading emacs and see if anything changes
<marusich>I wish I had something better to suggest. It was just a guess. Perhaps your old emacs links to an old version of glibc?
<marusich>I believe you can check the version of glibc that your program links against by using "ldd" (from the glibc package) on the executable, or by invoking "guix gc --references $the_path" where $the_path is the store path of the component, as in "guix gc --references /gnu/store/vsiqlxhj7lnydhhi85jc1pg0xzhcfdny-emacs-26.1"
<marusich>Anyway, upgrading to the latest is always a reasonable course of investigation.
<marusich>Sometimes, when it is possible at least, it is better to avoid a problem than to solve it. ;)
<reepca>annoying part is that because a bunch of propagated inputs are shared I actually need to upgrade 14 packages in total
<marusich>Try it in a fresh profile.
<marusich>If the same problem still occurs, then you probably won't solve it by upgrading.
<reepca>what, like 'guix environment --ad-hoc emacs'?
<marusich>I was thinking more like: "guix package -p /tmp/test-profile -i emacs"
<marusich>Then you can set the search paths for the profile using an invocation such as: eval "$(guix package --search-paths=prefix -p /tmp/test-profile)"
<marusich>You will probably still need to set the GUIX_LOCPATH manually (to point to the test profile), though.
<marusich>The point is, if it's a pain to upgrade your default user profile because you have many packages, you can try creating a new, test profile in place of upgrading your existing one.
<marusich>It is pretty easy to roll back, though, so I wouldn't bother if you can just run "guix package -u ." and go get a cup of coffee while it runs.
<reepca>'guix package -u' for me is more like a multi-hour affair. I probably shouldn't install everything any package I work on requires, heh.
<reepca>hm, interesting, in the environment with a fresh emacs I just spun up it seems to work
<reepca>\o/
<marusich>Maybe upgrading emacs will fix the problem, then.
<reepca>now I just need to wait for all 14 packages to get done
<reepca>maaan, llvm is among them, and it's not substituting :-/
<efraim>bavier: the handbrake update on core-updates, it needs something not in master?
<marusich>reepca, at least it isn't rust!
<efraim>I run 'guix package -u . -n' and then add '--do-not-upgrade=icecat libreoffice' and whatever else I don't want to build
<roptat>hi guix!
<roptat>so I was wrong there's non determinism in the modules' files: some module-info.class have hashes of non deterministic jar files (so we can fix that) and there's java.base.jdk.internal.module.SystemModules$all.class that contains a different bytecode
<roptat>same with SystemModules$default.class
<civodul>Hello Guix!
<roptat>hi :)
<g_bor>hello roptat!
<g_bor>I also some times see ordering differences in a module listing.
<g_bor>I could not check yet, but I also heard that there are some filesystem ordering differences.
<g_bor>Do we have a way to do a rounds 2 build on disorderfs? It would be a useful addition.
<efraim>do we have somewhere we want to list channels?
<roptat>g_bor, I guess since it's a filesystem, you can try mounting it on /tmp?
<roptat>I was thinking about a "guix profile" command yesterday, and I wanted to know what you think about it
<roptat>basically, we could do "guix profile list" (similar to ls /var/guix/profiles/per-user/roptat/) or "guix profile enter <profile>" (similar to "source /var/guix/profiles/per-user/roptat/<profile>/etc/profile)
<roptat>and we would change guix package's -p option to take only a profile name
<roptat>(but we would still have a --profile-path option or something)
<roptat>(I think we talked a bit about that during the last meeting in Paris)
<civodul>hey roptat!
<g_bor>roptat: profile list would be useful. Profile enter, I don't know...
<civodul>roptat: alezost made a similar proposal a couple of years ago
<roptat>did they send some code?
<g_bor>Yes, I might try to mount disorderfs on /tmp, but it would be nice if did not need to.
<civodul>i don't think so
<civodul>lemme see
<roptat>or is there something on the mailing list that I could look at?
<g_bor>What I would like instead is an option to have it enabled for a given build.
<civodul>roptat: https://lists.gnu.org/archive/html/guix-devel/2016-04/msg00724.html
<roptat>thanks
<efraim>apt-file on ubuntu reports screen has a tetris.c
<civodul>roptat: the actual proposal is here: https://lists.gnu.org/archive/html/guix-devel/2016-04/msg00764.html
<roptat>I was also thinking that we could port "guix package" command to "guix profile" because we actually manipulate profiles instead of packages
<roptat>I think it would make more sense, but then the "guix profile" command would be a bit cluttered I'm afraid
<g_bor>roptat: yes, that would make sense.
<g_bor>civodul: Do you think we should create the 2019 GSoC ideas page for guix?
<civodul>g_bor: yes, why not
<civodul>we'll need mentors :-)
<roptat>g_bor, do you want the result of diffoscope on the extracted files from modules? it really took a long time, so it might save you some :)
<roptat>it's 1.5 MB of diff!
<roptat>28K lines
<g_bor>roptat: yes, please. I guess I could use that.
<roptat> https://framadrop.org/r/ZsceuCjdDW#stw48twXgQwF1Rg6uLTGv266T1pixjRd1lmfWvsDnx0=
<g_bor>civodul: should I do it? Should we base it on last years?
<g_bor>roptat: these bytecode differences bother me... Where they might come from?
<rekado>shouldn’t “profile enter” be “environment --load” instead?
<roptat>no because environments are temporary
<roptat>I'm thinking of actual profiles registered as gc roots
<roptat>so you'd do "guix profile my-project -i pigx" then "guix profile enter my-project" for instance
<roptat>(not sure if that's a good idea to mix profile name and command names though)
<rekado>“guix environment --root=/some/where” is not temporary.
<roptat>mh... I'd really like to have some top-level command to do something like that
<civodul>g_bor: re GSoC: yes you can do it, starting from last year's page
<g_bor>ok, will do. reepca asked to remove the daemon rewrite, as they work on it. Is that ok?
<rekado>that’s fine
<civodul>+1
<civodul>really happy reepca is working on it!
<rekado>civodul: a rebuttal to tar as a decent container format: https://www.cyphar.com/blog/post/20190121-ociv2-images-i-tar
<rekado>(it mentions your Guix blog post)
<rekado>I don’t disagree. Tar is a crummy replacement for file systems.
<rEnr3n>is there a plan to make vagrant box for guixsd?
<rekado>I don’t know of any such plan.
<g_bor>I belive there is no plan, but it would not be hard to do.
<rEnr3n>i'm hoping for one :)
<civodul>rekado: in fact that post of mine didn't really argue in favor of tar, it was more about showing that we can make "app bundles" with very little
<rekado>yeah, I know. I found it odd that this could be understood as advocacy for tarballs :)
<civodul>well i guess if you only read the title that's the impression you get
<civodul>which was perhaps a bad idea on my part :-)
<rekado>na
<rekado>maybe you should have added a question mark
<rekado>:)
<rekado>7z + encryption: https://twitter.com/3lbios/status/1087848040583626753
<civodul>yeah :-)
<civodul>so!
<civodul>is today the day when we merge staging?
<rekado>I’d be happy to see it merged.
<rekado>mbakke, efraim what do you think?
*rekado rebased wip-gnome-upgrades (for a less ambitious upgrade to GNOME 2.28) on top of staging
<mbakke>Aloha Guix!
<mbakke>Merging staging will break `guix download`: https://issues.guix.info/issue/34102
<rekado>oh, I do remember seeing this bug report.
<rekado>A user installed “conda” via Guix and reported that it’s not working.
<rekado>I’m updating Conda now, but by default it tries to *write* to the directory containing Python…
<rekado>I’m screaming inside.
<roptat>Ha, I've seen similar behaviour from ocaml packages that assume they can write in the directory where the compiler is installed
<rekado>all of Conda is really frustrating to me.
<roptat>which makes sense when you use opam, but less when you use, say, guix
<rekado>it also scolds me for using “sudo”, when I’m totally not.
<rekado>it seems to have a bunch of heuristics that are simply resulting in wrong assumptions.
<rekado>that’s what I always fear we’d end up with if we worked around bugs in Guix instead of fixing them.
<rekado>there are also hundreds of tests that depend on Internet access, but they are not labelled, so they cannot easily be disabled… :-l
<htgoebel>rekado: Why is conda needed in guix? As far as I understood, this is just some kind of `guix environment`, isn't it?
<rekado>I don’t understand the question.
<rekado>it’s “needed” like any other package in Guix: because people want to use it.
<htgoebel>AFAIU conda is more or less the same as guix environment. Am I right on this?
<rekado>it’s a package manager.
<roptat>we also have pip, opam, cargo, ... so why not conda?
<htgoebel>I was just wondering.
<htgoebel>And pip, opam, cargo, etc. are language specific, while conda is for everything AFAIU
<civodul>we also have nix, rpm, and even debootstrap, so... :-)
<htgoebel>IC. Didn't know
<ng0>the guix 'tarballs' post has been referenced: https://www.cyphar.com/blog/post/20190121-ociv2-images-i-tar
***tilpner_ is now known as tilpner
<ng0>just sharing, I only started reading now.. found it through "OCI" and "pax"
<civodul>ng0: we discussed it earlier today :-)
<ng0>wrt package managers in a package manager: with some odd hacks we could even get apk, gentoo, etc. at least gentoo (Not gentoo with capital G, as in the OS, but the package manager) supports alternative prefixes
<ng0>ime it's not worth the work
<ng0>but it's interesting to package
<ng0>ah, I see
<htgoebel>imh there are more important packages then other package manager.
<htgoebel>E.g. KDE plasma desktop still missing (I have some draft, but this is very time consuming, so it is unfinished for one year now)
<ng0>right now I'm packaging guix for pkgsrc to be able to do work with guix without having to redo the setup everytime. so sometimes there is a need for PMs on PMs :)
<rekado>speaking of “important packages”: https://issues.guix.info/issue/33952 ;)
<htgoebel>ng0: this way round make a lot of sense for me :-)
<civodul>rekado: did "we" renew guixsd.org?
<htgoebel>rekado: Ahh, the good code quality from google
<jonsger>ng0: you can inspire you here https://build.opensuse.org/package/show/devel:languages:misc/guix and here https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=guix :P
<htgoebel>reminds me on my attempt to bootstrap the android build tools. I gave up after one week with the basic programs
<ng0>I know the packages, but thanks
<rekado>civodul: Andreas asked the SAC to agree to a renewal. I agreed already.
<civodul>awesome
<civodul>so it's renewed?
<rekado>well… I don’t know :)
<civodul>ok :-)
<rekado>I suppose Andreas would do that.
*civodul wonders in which folder his guix-europe messages go
<ng0>the worst part is I think I have to make it use /gnu/store because $PREFIX/gnu/store would probably hit limits in length.. have to do the math
<ng0>meaning, I can't make people opt-in to $PREFIX/...
<ng0>which is similar to the Debian situation, but for different reasons
<roptat>htgoebel, but thanks to your work, we now have maven :)
<roptat>the maven-build-system is still missing though
<rekado>civodul: I know it’s not the most pressing issue for the build farm, but I’d like to enable some hurd build nodes. Are the bootstrap binaries for the hurd uploaded somewhere?
<roptat>and somehow I got trapped in a cyclic dependency between apache-struts and velocity-tools
<efraim>ng0: I'd love to see your pkgsrc stuff for guix, I'm not really looking forward to trying to create debian packages for the dependencies for bootstrapping on powerpc
<rekado>(I only have my own set of bootstrap binaries for the hurd, but they are based on an old libc version)
<ng0>efraim: I'm still at the guile dependencies
<efraim>Do we have blessed Hurd bootstrap binaries?
<ng0>and I will probably go with the linux compat etc
<htgoebel>ropat: Oh, somebody managed to bootstrap maven? Great! (I did not follow the development for on year.)
<efraim>I've only packaged guile-bytestructures so far
<ng0>so binaries in the ideal case just work
<roptat>htgoebel, I did :)
<ng0>guile-git is the last package I need
<roptat>I took some parts of what you did, that really helped me
<civodul>rekado: no, i made progress on that to finally commit/upload those binaries, but got stuck: https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00364.html
<civodul>that message was meant as an incentive to phantomas et al. to continue the work :-), but it didn't work
<ng0>efraim: probably visible at pkgsrc.se as soon as commits get updated
<htgoebel>ropat: Thanks a lot! One of my important applications (freeplane) is build using maven. Now there is a chance to get it packaged :-)
<ng0>ah, I still need to do guile-json.. and a couple more new dependencies.. far from done
***ng0_ is now known as ng0
<stanleyno4>I'm trying to build emacs from git source using guix and its failing, complaining that autoconf is missing. I'm running "guix package -i emacs --with-source=emacs@27.0=./emacs" where "./emacs" is a master branch. After installing autoconf with "guix package -i autoconf" the same error remains. What do I need to do to build emacs from source using g
<stanleyno4>uix?
<rekado>stanleyno4: When building packages Guix purposefully ignores what you may have installed in your user profile.
<rekado>that’s by design.
<stanleyno4>rekado: Doesn't the emacs.scm already try to pull in autoconf? I thought it would reuse that spec to build a later version of emacs
<rekado>stanleyno4: you can check by running “guix edit emacs”
<rekado>it does not use autoconf because it is built from a bootstrapped release tarball.
<stanleyno4>after checking, hmm, actually it only list it for guile-emacs...
<stanleyno4>rekado: I'm not familiar with that process, do you recommend trying to replicate that approach or making a custom scm, or something else?
<rekado>one thing you can do is to generate the “configure” script in your checkout and then reuse the same package definition.
<rekado>ugh, conda tries to detect the location of the “python” executable and is sure it’s in a place where it isn’t, then acts surprised.
<bavier>efraim: yes, the latest handbrake needs ffmpeg 4.1, which is only on core-updates
<stanleyno4>rekado: ok, well your suggestion helped but I'm getting open-fdes: permission denied errors now. from an unknown file who's full path is truncated in the backtrace. This is in the 'reset-gzip-timestamps' phase. I'm not sure where to go from here, like if I should give up...
<stanleyno4>rekado: thanks for your help
<stanleyno4>I'm learning more about guix's build process thanks to you
<roptat>htgoebel, we're still far from having a maven-build-system though. Maybe you can try to use the ant-build-system to generate the right build.xml?
<roptat>stanleyno4, not sure, but you could try to run "make dist" and point guix to the resulting tarball?
<stanleyno4>roptat: make dist failed during some checking phase. Thanks for tip, but I think I'm giving up for now
***renich is now known as Renich
***Renich is now known as renich
<rekado>I’m not too happy with the python-build-system. It seems to me that in some cases “build”, “check”, and “install” all compile code.
<rekado>maybe this only happens when there are native bindings
<rekado>but it’s quite noticeable on some packages.
<efraim>rekado: you got python-coveralls' test to run?
<rekado>yes
<rekado>I think?
<rekado>oh
<rekado>it says “Ran 0 tests in 0.000s”
<rekado>I guess not.
<efraim>just tried to sync my mailbox in mutt with ':w' instead of '$'
<eubarbosa>Still waiting Wayland WM to arrive... no one so far, just Sway(beta), i3 clone.. meh
<eubarbosa>waymonad....please!
<joshuaBPMan>hmm?
<sisyphe_>hi guix, i have an issue packaging a cmake project building a python package
<sisyphe_>here is the project https://github.com/ros-visualization/python_qt_binding
<sisyphe_>I got "ValueError: ZIP does not support timestamps before 1980"
<sisyphe_>as far as I understand, python build system takes care of modifying timestamp before building the egg
<sisyphe_>but I have no success trying to make the cmake build system do the same
<sisyphe_>any help on how to do this ?
<dongcarl>how would I get the host triple inside a package?
<bavier>sisyphe_: maybe borrow the ensure-no-mtimes-pre-1980 procedure from (guix build python-build-system)
<dongcarl>I'm wondering what people's thoughts are on using faketime to achieve reproducible builds
<dongcarl>Do people think that it's just sidestepping the problem?
<dongcarl>Or that it's reasonable to use
<g_bor>hello dongcarl!
<dongcarl>Hi!
<g_bor>Most of the time it's not that simple.
*dongcarl is listening
<g_bor>When the only source of the problem can be solved by using faketime, then creating a patch is usually not so difficult.
<g_bor>In most of the cases these are inserted in a few, well defined locations in the code.
<g_bor>If only the timestamps are causing problems, the I am tempted to say that faketime can do...
<g_bor>On the long run it would be nice if tools could get SOURCE_DATE_EPOCH support, or something equivalent.
<g_bor>Also faketime can introduce interesting problems.
<g_bor>For example would you use it in relative or absolute mode?
<g_bor>For example some build system might use times to guess dependecies need to be updated...
<vagrantc>libfaketime does tend to cause problems with things like JIT compilers and Makefiles and such, which rely on the timestamp to do the right thing
<vagrantc>and in some cases even more severe problems
<g_bor>hi vagrantc!
<vagrantc>debian pretty much has shied away from using faketime lately
<g_bor>Yes, sometimes I feel it causes more problems than it solves. Breaking makefiles is one of the most prominent.
<g_bor>It is still useful in relative mode, to test time depent stuff, but it does not help to build reproducibly.
<g_bor>I still think it is useful when it works, at least as a band-aid :)
<g_bor>The biggest problem with this, and also with solutions like strip-nondeterminism, is that you never know when upstream breaks it.
<g_bor>One of the most useful side-effects in upstreaming a patch, is that they become aware that this is important, and also reduces duplicated work.
<g_bor>Whenever we have to do a workaround like using faketime, or adding a post-build phase to get these right, then there is a lot of other people on other distros/package managers/whatever doing the same thing.
<sisyphe_>thanks, I never used faketime,do you have examples of packages using it ?
*g_bor running diffoscope to make sense of openjdk11
<sisyphe_>I tried to reproduce what ensure-no-mtimes-pre-1980 does but I didn't manage to import ftw so I'm stuck
<g_bor>I did not do such a thing in guix. I had to do it at work...
<bavier>sisyphe_: (ice-9 ftw)
<g_bor>I will have look what I can share...
<g_bor>oh, yes.
<g_bor>I can tell you what there was... it was dead simple.
<sisyphe_>I have #:use-module (ice-9 ftw) but still get Unbound variable: ftw
<sisyphe_>so something else must be wrong
<bavier>sisyphe_: that module probably needs to be imported into the build code, see examples of #:modules and #:imported-modules for the arguments field
<g_bor>It was just faketime -f 'absolute-timestamp-here' build.sh executed from a script...
<g_bor>Very simplistic... as no build system was used, this did not cause any problems there.
<rekado>sisyphe_: Guix has different stages for code. Some code runs on the host side, other code runs on the build side.
<rekado>sisyphe_: modules that you import at the top of the file are for host side code.
<rekado>sisyphe_: see the ` character before the value of the “arguments” field? That’s a (quasi)quote, which says that everything that follows is inert data.
<rekado>that gets sent to the build side
<rekado>so if you want to use some modules on the build side you need to tell Guix about them
<rekado>e.g. by using #:modules in the arguments field
<sisyphe_>Ok, I understand
<sisyphe_>I'm trying to figure how to use #:modules with the cmake build system since all the examples I found use gnu build system
<rekado>it’s the same
<sisyphe_>g_bor: thanks, faketime will be the next thing I try
<rekado>the #:modules thing is independent of the build system.
<rekado>(most of the build systems inherit from the GNU build system, though, so what works for that build system often also works for others)
<sisyphe_> #:modules ((srfi srfi-1)
<sisyphe_> ,@%gnu-build-system-modules)
<sisyphe_>I don't get the ,@%gnu-build-system-modules) part
<rekado>the ` is a quasiquote. It’s like a toggle switch. When it’s up, i.e. “`” it means: data mode. When it’s down, i.e. “,”, it means: code mode.
<rekado>the “,@” means: code mode, but explode the list
<rekado>%gnu-build-system-modules is the name of a list value
<rekado>so ,@%gnu-build-system-modules means: inject all of the elements of this list right here, as if I had written them myself, one by one.
<rekado>the result is that the value for #:modules does not just hold (srfi srfi-1) but also all of the modules defined in the list %gnu-build-system-modules.
<sisyphe_>ok, got it
<rekado>you don’t *need* to use it like that.
<rekado>you can also type it all out by yourself.
<sisyphe_>is it because adding #:module remove all modules loaded by default, and I have to explicitly include them all ?
<rekado>e.g. #:modules ((guix build-system cmake) (ice-9 ftw))
<rekado>it overrides the list of modules
<sisyphe_>ok
*g_bor looking at diffoscope output...
<sisyphe_>now I'm wondering how append the original modules list since it looks like %gnu-build-system-modules is not enough in my case
<rekado>you’ll probably also need (guix build cmake-build-system)
<rekado>and maybe (guix build utils)
<sisyphe_>yes you are right
<g_bor>there is actually a %cmake-build-system-modules
<g_bor>that might do...
<roptat>Ah, I thenk I created an "ocaml" branch on guix' repo, but that wasn't intended… How to remove it?
<g_bor>it is defined as `((guix build cmake-build-system) ,@%gnu-build-system-modules))
<sisyphe_>%cmake-build-system-modules is not enough apparently
<g_bor>you might still need build utils...
<sisyphe_>yes
<sisyphe_>I would have fail at guessing missing module by myself, do you know what material can make me more knowledgeable ?
<sisyphe_>don't understand why but adding @%cmake-build-system-modules or @%gnu-build-system-modules makes it fail
<g_bor>roptat: you can try git push remote-name --delete branch-name
<sisyphe_>while #:modules ((guix build cmake-build-system) (guix build utils) (ice-9 ftw)) is ok
<roptat>Looks like it worked
<g_bor>it should look like #: modules `((ice-9 ftw) ,@cmake-build-system-modules)
<roptat>But I got a message "fatal: bad object 000000000000000000000000"
<g_bor>roptat: actually sometimes I also get that...
<rekado>roptat: that’s fine.
<rekado>it’s just the push hook that tries to check signatures, I think
<civodul>dongcarl: there's one case where faketime was really needed: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=bc9aa60bd574f44b0a75363d59c43a23cda6bdb0
<civodul>typically other things that test certificate/signature expiration dates may have the same problem
<civodul>TLS, OpenPGP, etc.
<civodul>though we haven't encountered them so far, i think
<dongcarl>Yeah I'm just thinking about the best way to transfer the bitcoin build system over to guix... We have this depends system: https://github.com/bitcoin/bitcoin/tree/master/depends, which basically bootstraps all of our dependencies for all triplets, but we use libfaketime to get most of the determinism
<dongcarl>BTW the patches directory might contain some determinism patches that's of interest to guix
<civodul>interesting!
<dongcarl>g_bor: Yeah I think it is important to get upstream to be aware of the issues.
<g_bor>dongcarl: by any chance, do we have any of these dependencies packaged?
<g_bor>we might already have a reproducible build for some...
<dongcarl>I think my current plan is to start with a gigantic package "bitcoin-depends" that does the bitcoin/depends build, then separate them into their own packages
<dongcarl>g_bor: Yes, but we're quite specific about the flags that we build our dependencies with I believe
<dongcarl>g_bor: I think I'll copy over the package definitions from guix, and modify it to fit our flags...
<dongcarl>Not sure if you guys think this is a good idea, but I think I should just make my own Guix channel
<g_bor>if these are not especially related to reproducibility, it might be aesy to use package inheritance, and base these off from what we have...
<dongcarl>g_bor: package inheritance? As in you can override existing guix packages?
<dongcarl>Or like override parts of it?
<g_bor>yes, just like that.
*rekado removes more instances of (zero? (system* …)) and simplifies old packages in the process…
<dongcarl>Hmmm that's a good point, I'll look into it
<g_bor>ok, good luck with that.
<dongcarl>g_bor: Thank you sir!
<g_bor>you can just grep for inherit in just about any package module
<dongcarl>g_bor: I think I'll do the copy paste first (cuz it's easier and I'm lazy lol), and then transition to inherit after I've gotten something working, but inheritance is definitely preferable
<g_bor>I believe that inheritance is easy to do, when you only change flags, it becomes complicate when you want to make more subtle modifications. There is a drawback, however: you are becoming dependent on the inherited package, and we might break it unintentionally.
<g_bor>Usually the preferred way is to keep the whole inheritance chain in one hand, so that it is tested together.
<dongcarl>g_bor: Yeah I don't think other Core Devs will accept being dependent on inherited package, they prefer that we have full control... Would you say that making a Channel for bitcoin packaging would make sense?
<g_bor>recursively stripping the zip achive timestamps worked fine, there is only the modules things differing now.
<g_bor>dongcarl: I believe it would. The safest bet on the long run would be to upstream whatever you can, as it could be tested against core guix changes, but having a channel does make sense while it is work in progress, or if you have parts you can't upstream yet.
<dongcarl>g_bor: Cool. How would naming conflicts be resolved when I have both the master and the bitcoin-builds channel?
<g_bor>be aware, that the guix developer team is not commited to keep channels working, so that we can keep our api-s in flux
<g_bor>you will have definition file for that, see http://guix.info/manual/en/Channels.html#Channels
<dongcarl>I see... But I'm guessing it won't matter if I develop against a certain version of guix right? Like build from a certain guix commit and never `guix pull`?
<g_bor>yes, that would be one way.
<g_bor>But I guess you could use an inferior for the channel, and then you can still safely pull, and get for example the upstream security updates...
<g_bor> https://guix.info/manual/en/Inferiors.html#Inferiors
<dongcarl>Wow that is...
<dongcarl>Cool
<dongcarl>Does anyone have an example of a stripped-down Channel that I can take a look at?
<dongcarl>I know guix itself is a Channel but it's a large beast
<g_bor>I currently don't have one, but I guess mbakke has chrome, and someone wrote they have one for neovim...
<g_bor>I will have a look around.
<dongcarl>That'd be wonderful!
<g_bor>here it is: https://gitlab.com/HiPhish/neovim-guix-channel/
<g_bor>I have to go now. See you later!
*dongcarl is thankful
*civodul fiddles with 'guix weather' so it can report missing package substitutes sorted by number of dependents
<quiliro>hello
<quiliro>i cannot view any youtube page on icecat
<quiliro>i cannot even search in order to view without js with mpv
<bavier>quiliro: maybe you could try youtube-viewer?
<quiliro>bavier: installing ....
<bavier>quiliro: I use the gtk interface often
<vagrantc>in linux-initrd.scm ... what are the criteria for weather something should go into default-initrd-modules vs. requiring a user to specify them in their config?
<civodul>vagrantc: there aren't really criteria other than keeping default-initrd-modules smallish because currently everything that's in there gets loaded