<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:
<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>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
<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
<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
<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)
<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
<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 --firstname.lastname@example.org=./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>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...
<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...
<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