Re: Status of Gnome upgrade?
Timothy Sample writes: > Hi all, > > I’ve CC’d Kei who has been looking after this. Thanks Kei! > > Brett Gilio writes: > >> Ricardo Wurmus writes: >> >>> Hi Guix, >>> >>> does anyone know what’s holding up the Gnome upgrade? It’s sad to see >>> the upgrade languish when it was almost ready for a merge into master. >>> >>> Are there any open issues? Any problems that need solving? I think >>> this is a high priority item for Guix. I’d love to help getting it >>> done. >>> >>> Any ideas? >>> >>> -- >>> Ricardo >>> >>> >> >> I do not know of any open issues, but I agree with Ricardo fully. This >> is a high priority issue for Guix that needs to get done sooner rather >> than later. >> >> I am also willing to throw my weight behind it, even though I am not a >> regular GNOME user. > > I’m also willing to help. :) > > > -- Tim I've been more busy than I'd like over the past few weeks, but I've been using the "wip-gnome-updates" branch for a while now. Up to November 27 (the "master" branch hasn't been merged into "wip-gnome-updates" since then), I haven't noticed any regressions in GNOME's functionality. I'd be delighted to merge "wip-gnome-updates" into "master" and begin work on GNOME 3.34 updates starting late next week.
Re: Packaging Mercury & Some Struggles
Hi Brett, I like having mercury-minimal I think that’s pretty considerate. To use (ice-9 match) you will need to add it to the list of #:modules in the arguments field then use-module in your phase. I.E.: (arguments `( #:modules ,(cons '(ice-9 match) %gnu-build-system-modules) ... Then in your phase: (lambda ... (use-modules (ice-9 match)) ... A phase should work well for this purpose, as long as the submodule does not include any binaries. If it does, you should use the snippets field of the origin record instead. Happy to help, and good luck, John
Re: Guix pull chokes on uglify-js
Pierre Neidhardt 写道： Repushed with the last fix in. This time tested against a proper `guix pull`. Pfeww! :) Thank you! You can ignore channels.scm suggestion, was in a hurry $ thought you meant that *--url=* wasn't DTRT. Kind regards, T G-R signature.asc Description: PGP signature
Re: Feedback from JRES in Dijon
Hi,
On Thu, 5 Dec 2019 at 16:45, Konrad Hinsen wrote:
> > So they are doing physical simulation (fluid dynamics), so they don't
> > (can't) get the same result when running the same experiment
> > twice. They wart replicability, that is, even if the results are
> > different, they are close enough to each other that you have to draw
> > the same scientific conclusion, independent of your compiler or other
> > package inputs.
>
> That's a common point of view in the numerical simulation community.
> What the people defending it don't realize is that both reproducibility
> and replicability matter, but in different situations and for different
> reasons. Reproducibility matters for verification ("was the computation
> done correctly?"), replicability matters for validation ("was the
> computation the right one for the scientific question?").
If I might, one the best presentation [1] -- that I am aware of -- on
this. Sorry in French.
[1]
https://webcast.in2p3.fr/video/les-enjeux-et-defis-de-la-recherche-reproductible
https://aramis.resinfo.org/wiki/lib/exe/fetch.php?media=pleniaires:aramis_keynote_enjeux-et-defis-recherche-reproductible_konrad_hinsen.pdf
Maybe we could convert it to an entry for the HPC blog. What do you think?
Cheers,
simon
Re: Packaging Jami progress
On Thu, 05 Dec 2019 15:32:23 +0100 Pierre Neidhardt wrote: > Thanks! > > The first 5 commits look good overall. Good to know. > For the last one, I think there are a few confusions: > > - native-inputs takes packages or origins, it does not take a lambda. > > - To call a custom function from the builder, you need to include the > module that defines it for the build system, e.g. > > (arguments > `(#:modules ((gnu packages telephony) > ,@%gnu-build-system-modules) > ...) > > - In this particular case, you could even make a macro that is > expanded at definition time, so that you would not even need to > import the module. If you don't know how to write scheme macros, no > need to go down this road for now. I read about macros, but didn't write anything complicated myself. I would have to reread the manual again. > But before fixing this issue, what are you trying to do exactly? > Do you intend to reuse this `jami-apply-dependency-patches' procedure > somewhere else? Jami developers apply many patches for different projects - currently our package code only patches pjproject, but ffmpeg needs patches for instance for auto bitrate support and I don't really know what has to be patched next - I listed the output of "find -name "*.patch"" in the first mail. I think copying and pasting similar code from pjproject package definition to ffmpeg definition isn't a good practice, that's why I decided to create a procedure taking patches from ring-project/daemon/contrib/ and applying them. > > On a different topic, to avoid sending patch archives in the future, > you could use a public repository clone of Guix. > There are a couple of free services out there, like sr.ht, maybe > gogs.io, etc. > This would make it smoother to track your progress and help you in > the process. I'll check this out, thanks. Jan Wielkiewicz
Re: Feedback from JRES in Dijon
On Thu, 5 Dec 2019 at 15:43, Julien Lepiller wrote: > So they are doing physical simulation (fluid dynamics), so they don't (can't) > get the same result when running the same experiment twice. They wart > replicability, that is, even if the results are different, they are close > enough to each other that you have to draw the same scientific conclusion, > independent of your compiler or other package inputs. It is question for the Philosophy of Science. What is the status of error? ;-) In the area of controlling the error, Interval Arithmetic [1] gives interesting results. [1] https://en.wikipedia.org/wiki/Interval_arithmetic All the best, simon
Re: Feedback from JRES in Dijon
Hi Julien and Pierre,
> So they are doing physical simulation (fluid dynamics), so they don't
> (can't) get the same result when running the same experiment
> twice. They wart replicability, that is, even if the results are
> different, they are close enough to each other that you have to draw
> the same scientific conclusion, independent of your compiler or other
> package inputs.
That's a common point of view in the numerical simulation community.
What the people defending it don't realize is that both reproducibility
and replicability matter, but in different situations and for different
reasons. Reproducibility matters for verification ("was the computation
done correctly?"), replicability matters for validation ("was the
computation the right one for the scientific question?").
Moreover, there is a practical use for reproducibility when checking for
replicability. Suppose you have a program and a result, then you run the
program with a different compiler and get a different result, too
different to be scientifically equivalent. No replicability. Then what?
How do you figure out what went wrong? The very first thing you want to
check is reproducibility: can you get the same result by using the same
compiler? If yes, fine, you can then look at intermediate results in
both versions of the computation to figure out where the differences
come from. If not, there is no point in wasting time on that: there is
something wrong with the code or the data you got, and you have to check
your sources first.
Giving up on reproducibility thus means giving up a valuable debugging
technique.
Cheers,
Konrad
Re: Feedback from JRES in Dijon
Hi Julien, Thank you for this report. On Thu, 5 Dec 2019 at 15:25, Julien Lepiller wrote: > Another wanted to have some kind of doi for guix describe + manifest (a > better UI and easier thing to cite in a paper I suppose). I agree that something is lacking. I was not thinking about DOI but I was thinking a better UI similar to "git tag" to improve the current situation. It is not exactly the question that you had but it seems related, AFAIU. For example, it is hard to know which commit I need to "guix pull" to have Python 3.6, if we have. I tried to start a discussion in this topic there [1]. Another concrete example had been asked here [2]. [1] https://lists.gnu.org/archive/html/guix-devel/2019-11/msg00513.html [2] https://lists.gnu.org/archive/html/help-guix/2019-06/msg00098.html > The person I talked to at lunch was a bit skeptical about Guix. They have it > and Nix, with module on their cluster. They told me they were more concerned > about replicability than reproducibility. Also, their users are lost between > the options, they have trouble getting help on guix from their admins and > they end up using conda, yet another tool ^^". Bit-to-bit reproducibility is the first step to go to Replicability, IMHO. For sure, Conda is a no-go for this goal, again IMHO. :-) Modulefiles is loosing their time by re-doing what packagers are doing; it is the dependency hell because they spend their time on compiling libraries -- the code of interest depends on one lib which depends on other lib which depends on... So it requires a lot of manpower. Guix solves that elegantly IMO; considering channels. And the big issue of replicability is floating point. The same binary with the same inputs does not compute the same output. For example, see page 13 of [3]. [3] https://jcad2019.sciencesconf.org/data/2019_JCAD_Repro_Hill_vf.pdf Well I am not sure that a general solution can solve replicability... and it is software by software. Cheers, simon
Re: Guix pull chokes on uglify-js
Pierre Neidhardt writes: > Tobias Geerinckx-Rice writes: > >> Pierre Neidhardt 写道： >>> Let me know if there is anything else that bot broken in the >>> process. >> >> Adding your local repository to ~/.guix/config/channels.scm and >> running ‘guix pull’ after committing (and before pushing) should >> reproduce the downstream experience quite accurately, although I >> haven't tried it myself. > > Yes, it also works with `guix pull --url=...`, but I would like to avoid > touch my user guix checkout profile. > > Maybe this would be a viable alternative then: > > --8<---cut here---start->8--- > guix pull --url=... && guix package -p ~/.config/guix/current --roll-back > --8<---cut here---end--->8--- > > Not atomic, but good enough I suppose. > > Thoughts? You can 'guix pull -p /tmp/guix-master --url=.' to avoid clobbering your current-guix. signature.asc Description: PGP signature
Re: Guix pull chokes on uglify-js
Tobias Geerinckx-Rice writes: > Pierre Neidhardt 写道： >> Let me know if there is anything else that bot broken in the >> process. > > Adding your local repository to ~/.guix/config/channels.scm and > running ‘guix pull’ after committing (and before pushing) should > reproduce the downstream experience quite accurately, although I > haven't tried it myself. Yes, it also works with `guix pull --url=...`, but I would like to avoid touch my user guix checkout profile. Maybe this would be a viable alternative then: --8<---cut here---start->8--- guix pull --url=... && guix package -p ~/.config/guix/current --roll-back --8<---cut here---end--->8--- Not atomic, but good enough I suppose. Thoughts? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Status of Gnome upgrade?
Hi all, I’ve CC’d Kei who has been looking after this. Thanks Kei! Brett Gilio writes: > Ricardo Wurmus writes: > >> Hi Guix, >> >> does anyone know what’s holding up the Gnome upgrade? It’s sad to see >> the upgrade languish when it was almost ready for a merge into master. >> >> Are there any open issues? Any problems that need solving? I think >> this is a high priority item for Guix. I’d love to help getting it >> done. >> >> Any ideas? >> >> -- >> Ricardo >> >> > > I do not know of any open issues, but I agree with Ricardo fully. This > is a high priority issue for Guix that needs to get done sooner rather > than later. > > I am also willing to throw my weight behind it, even though I am not a > regular GNOME user. I’m also willing to help. :) -- Tim
Re: Guix pull chokes on uglify-js
Pierre Neidhardt 写道： Let me know if there is anything else that bot broken in the process. Adding your local repository to ~/.guix/config/channels.scm and running ‘guix pull’ after committing (and before pushing) should reproduce the downstream experience quite accurately, although I haven't tried it myself. Kind regards, T G-R signature.asc Description: PGP signature
Re: Guix pull chokes on uglify-js
Duh! :( So there is another issue, I'll fix it. Regarding the `guix pull` discussion: it seems that `--dry-run` does not build the package cache (beside many other things) and thus it does not catch many errors. So the trick of running --8<---cut here---start->8--- guix pull --url=... --dry-run --8<---cut here---end--->8--- does *not* work :( Shouldn't we change --dry-run so that it does *everything* except updating the symlink of the guix checkout profile? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Guix pull chokes on uglify-js
Pierre, Pierre Neidhardt 写道： I've just pushed ac1ee30f4f7f9d0ae2a655676b0e8b9eb90a35dd to move Lisp libraries to lisp-xyz again, this time fixing the pull issue with the minify build system. Let me know if there is anything else that bot broken in the process. Looks like it: $ guix pull Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... Building from this channel: guix https://git.savannah.gnu.org/git/guix.git 73bd8ab Computing Guix derivation for 'x86_64-linux'... | The following derivation will be built: /gnu/store/9byic43nh7yzi5hxscmy9q2lcagchnn5-profile.drv The following profile hook will be built: /gnu/store/kr7099ckaisng27dbpxb6jx55jdlk874-guix-package-cache.drv building package cache... /builder for `/gnu/store/kr7099ckaisng27dbpxb6jx55jdlk874-guix-package-cache.drv' failed to produce output path `/gnu/store/3igvnig0hd6b7mdm6q0dzdpja2pyvasc-guix-package-cache' build of /gnu/store/kr7099ckaisng27dbpxb6jx55jdlk874-guix-package-cache.drv failed View build log at '/var/log/guix/drvs/kr/7099ckaisng27dbpxb6jx55jdlk874-guix-package-cache.drv.bz2'. cannot build derivation `/gnu/store/9byic43nh7yzi5hxscmy9q2lcagchnn5-profile.drv': 1 dependencies couldn't be built guix pull: error: build of `/gnu/store/9byic43nh7yzi5hxscmy9q2lcagchnn5-profile.drv' failed Sorry! T G-R signature.asc Description: PGP signature
Re: Feedback from JRES in Dijon
So they are doing physical simulation (fluid dynamics), so they don't (can't) get the same result when running the same experiment twice. They wart replicability, that is, even if the results are different, they are close enough to each other that you have to draw the same scientific conclusion, independent of your compiler or other package inputs. Le 5 décembre 2019 15:34:15 GMT+01:00, Pierre Neidhardt a écrit : >Thanks for the feedback! > >> The person I talked to at lunch was a bit skeptical about Guix. They >> have it and Nix, with module on their cluster. They told me they were >> more concerned about replicability than reproducibility. > >What's replicability? > >-- >Pierre Neidhardt >https://ambrevar.xyz/ -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Re: Feedback from JRES in Dijon
I forgot to give you a link to the presentation. It's in French: https://replay.jres.org/videos/watch/c77b3a44-b75f-4c10-9f39-8fb55ae096d7 Also, Marc talked about jdev, another French conference where we could present Guix too: http://devlog.cnrs.fr/jdev2020 Le 5 décembre 2019 15:16:23 GMT+01:00, Julien Lepiller a écrit : >Hi Guix! > >I presented the project at JRES yesterday and had lots of questions and >reactions. > >One person was wondering whether Guix would be a good idea for there >cluster. I said yes then I redirected them to guix hpc. > >Another wanted to have some kind of doi for guix describe + manifest (a >better UI and easier thing to cite in a paper I suppose). > >Another was asking about the possibility ofusing Guix to have multiple >kernels and boot a debian with guix's kernel (so as to choose a >compatible kernel at boot iiuc). > >The person I talked to at lunch was a bit skeptical about Guix. They >have it and Nix, with module on their cluster. They told me they were >more concerned about replicability than reproducibility. Also, their >users are lost between the options, they have trouble getting help on >guix from their admins and they end up using conda, yet another tool >^^". > >That's only a few conversations that really marked me, but I had more, >and I'll hopefully have more this afternoon and tomorrow. > >Marc, who organised the guile and guix days in Strasbourg last summer >is here too and said he will write a tutorial on using vin to program >in scheme. I'm lookinq forward to reading it! -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Feedback from JRES in Dijon
Hi Guix! I presented the project at JRES yesterday and had lots of questions and reactions. One person was wondering whether Guix would be a good idea for there cluster. I said yes then I redirected them to guix hpc. Another wanted to have some kind of doi for guix describe + manifest (a better UI and easier thing to cite in a paper I suppose). Another was asking about the possibility ofusing Guix to have multiple kernels and boot a debian with guix's kernel (so as to choose a compatible kernel at boot iiuc). The person I talked to at lunch was a bit skeptical about Guix. They have it and Nix, with module on their cluster. They told me they were more concerned about replicability than reproducibility. Also, their users are lost between the options, they have trouble getting help on guix from their admins and they end up using conda, yet another tool ^^". That's only a few conversations that really marked me, but I had more, and I'll hopefully have more this afternoon and tomorrow. Marc, who organised the guile and guix days in Strasbourg last summer is here too and said he will write a tutorial on using vin to program in scheme. I'm lookinq forward to reading it!
Re: Status of Gnome upgrade?
Ricardo Wurmus writes: > Hi Guix, > > does anyone know what’s holding up the Gnome upgrade? It’s sad to see > the upgrade languish when it was almost ready for a merge into master. > > Are there any open issues? Any problems that need solving? I think > this is a high priority item for Guix. I’d love to help getting it > done. > > Any ideas? > > -- > Ricardo > > I do not know of any open issues, but I agree with Ricardo fully. This is a high priority issue for Guix that needs to get done sooner rather than later. I am also willing to throw my weight behind it, even though I am not a regular GNOME user. -- Brett M. Gilio https://git.sr.ht/~brettgilio/
Status of Gnome upgrade?
Hi Guix, does anyone know what’s holding up the Gnome upgrade? It’s sad to see the upgrade languish when it was almost ready for a merge into master. Are there any open issues? Any problems that need solving? I think this is a high priority item for Guix. I’d love to help getting it done. Any ideas? -- Ricardo
