Re: should auto updaters be disabled?
On Fri, Feb 28, 2020 at 10:14:19PM +0530, Arun Isaac wrote: > I agree that auto updaters should be disabled where applicable. But, > ideally, like you said, this should be implemented upstream as a > configuration option we can set at build time. I also agree we should make an effort to disable these features, because they can confuse users about how to update software from Guix and also don't offer the "binary -> source" transparency that makes Guix so amazing. And I agree that it would be great if it was configurable in the upstream source, but we could also patch it out ourselves if upstream is not interested. For example, we build Syncthing with the '-no-upgrade' option which disables auto-upgrade functionality at build time. signature.asc Description: PGP signature
Re: [rb-general] Quick reproducible test for GNU Guix
Hi Vagrant, On Fri, Feb 07, 2020 at 03:08:59PM -0800, Vagrant Cascadian wrote: > I did some quick reproducibility testing running GNU Guix, and so far > got pretty good results: > > Using guix (and packages) built from commit: > f83d07f7778b699d46741a5667113342f5f0a737 > > $ guix challenge --verbose --diff=diffoscope ... > 2,463 store items were analyzed: > - 2,016 (81.9%) were identical > - 37 (1.5%) differed > - 410 (16.6%) were inconclusive thanks for sharing these results, very nice! I've added this to the February report and would be happy to receive future updates on this as well as setup some continuous testing! -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: rav1e AV1 encoder
On 2/27/20 12:26 PM, Leo Famulari wrote: I'm wondering if I can just push the crates as a single commit, after inserting them alphabetically and fixing any cosmetic issues, and also handling the semver-compatible package updates. I know that we don't usually do this when adding packages to an existing module. We do add packages en masse when creating a new module. The reason I'm asking to make an exception to our policy of one package or update per commit are that it will be a ton of work (several full days at least) to add software that is already working fine on the wip-rav1e branch. I don't see what value this additional labor will give to Guix users, including developers. At least, I don't think the value of individual commits will outweigh the value of my labor in this case. What do you all think? Yeah I have also wondered this. I think it would make things a lot easier if we could do single commits.
Re: should auto updaters be disabled?
I agree that auto updaters should be disabled where applicable. But, ideally, like you said, this should be implemented upstream as a configuration option we can set at build time. signature.asc Description: PGP signature
Re: 01/03: ui: Only display link in capable terminals.
Hi Ludo, On Fri, 28 Feb 2020 at 00:16, Ludovic Courtès wrote: > I’ve reverted it in c2f9ea2b502a617bb69227d5f858eee9d4288a6a, also > because if was causing a test failure. I understand and I am fine. This needs more discussion and polishing. > The way I see it, it’s on purpose that this piece of information was not > displayed before. For example, I think ‘guix describe’ should be > to-the-point. > > More generally, hyperlinks were introduced as a way to enhance the user > experience for those using capable terminals. Like for hyperlinks in > HTML, it’s a way to convey additional information; displaying all these > links in addition to the “invisible” hyperlink data can only lead to > clutter IMO, and defeats the point of hyperlinks. I do not buy your argument. :-) Hyperlinks means 2 things: how the link is displayed and how to follow the link. And they are generally connected. If you can click to the link to follow it then you can display it as you want. The point is to control how to display the link; whatever the way to follow it. However, I agree that INSIDE_EMACS is not the right environment variable to deal with that. > Ludo’, who’s supposed to be mostly away from keyboard this week. :-) Enjoy your holidays! :-) Cheers, simon
Re: rav1e AV1 encoder
On Thu, Feb 27, 2020 at 12:26:13PM -0500, Leo Famulari wrote: > I'm wondering if I can just push the crates as a single commit, after > inserting them alphabetically and fixing any cosmetic issues, and also > handling the semver-compatible package updates. > > I know that we don't usually do this when adding packages to an existing > module. We do add packages en masse when creating a new module. > > The reason I'm asking to make an exception to our policy of one package > or update per commit are that it will be a ton of work (several full > days at least) to add software that is already working fine on the > wip-rav1e branch. > It took me about 3 weeks to review ~270 patches for alacritty and it was easily more than 20 hours. > I don't see what value this additional labor will give to Guix users, > including developers. At least, I don't think the value of individual > commits will outweigh the value of my labor in this case. > > What do you all think? I suppose it's not that much different than updating all the GHC packages in one go, except that they're more interconnected. I suppose we could throw them all into the crates-io module and then hack on all 270 packages at once in a separate branch. That certainly would be easier than adding them one at a time. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: rav1e AV1 encoder
On Thu, Feb 27, 2020 at 12:16:02PM -0500, Leo Famulari wrote:
> On Wed, Feb 26, 2020 at 09:09:05AM +0200, Efraim Flashner wrote:
> > Short of resorting them I'd start with ones that have no dependencies,
> > just rely on rust-quote & friends or are older versions. Some packages,
> > like rust-futures-*, should be updated as a group since they all expect
> > to be the same version.
>
> Okay.
>
> > The only real builds that we care about are the packages in rust-apps
> > and librsvg-next (and librsvg-next is less important). And of course
> > that we don't reference packages that don't exist yet.
>
> Right, but keeping Guix building without "undefined variable" warnings
> is what I'm worried about here.
>
> > The ones that I spend the most amount of time reviewing are the ones
> > that end in -sys or otherwise reference system libraries. Sometimes more
> > effort is needed to unbundle libraries. In general anything that wants
> > rust-{cc,cmake,pkg-config} is suspect.
>
> Hm... you're saying they sometimes bundle C / C++ language libraries?
>
Just search for snippet in (gnu packages crates-io). rust-bzip2-sys was
particularly bad and basically needed to be replaced, but expat-sys,
jemalloc-sys, libgit2-sys, libssh2-sys etc all bundle the library.
> > > Would we have the same issue with updating this kind of large package
> > > tree automatically with `guix refresh` and committing the changes one at
> > > a time?
> > >
> >
> > Sometimes. We do have other upgrades where we go and do a bunch at once,
> > where they rely on each other and expect specific versions. The first
> > thing I can think of is certbot.
>
> Certbot is special in the sense that certbot and python-acme are
> actually developed in the same Git repo but are split up for PyPi
> distribution in the hope that other projects will build on python-acme.
There are a couple of those in rust-land too.
--
Efraim Flashner אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
signature.asc
Description: PGP signature
Re: Packaging UCSC
Pjotr Prins writes: > Anyone got UCSC running with Guix? May be easier than Galaxy which is > also on the books at some point. Most of the UCSC browser is non-free software. The kentutils make up a part of the code. Some of the kentutils are free software and are available in Guix as the “kentutils” package. -- Ricardo
Re: Packaging UCSC
Hi Giovanni, > AFAIU UCSC Genome Browser in "just" a browser [1] while Galaxy is a > "workflow management system" [2] (GWL is missing, and that _is_ the > solution to the workflow problem space :-) ) > > Is Galaxy also capable of genome browsing? Nothing I am aware of. But I am not an real Galaxy user. Note that GWL and Galaxy are not exactly in the same "problem space"; mainly because Galaxy is a monster hairy beast. ;-) Well, it depends on which level the comparison is done. Galaxy is based on visual "graphical programming" and IMHO that said a lot about the "problem space". > > You are talking about that [1], right? > > But is it free software? > > Unfortunately not [...] > This page also points to the EULA > http://genome.ucsc.edu/license/gbLicense2019.pdf Thank you for having looked into it. Cheers, simon
Re: Packaging UCSC
Hi, zimoun writes: > Hi Pjotr, > > On Thu, 27 Feb 2020 at 19:22, Pjotr Prins wrote: > >> Anyone got UCSC running with Guix? May be easier than Galaxy which is >> also on the books at some point. Just a curiosity: I'm completely ignorant on this tools but are UCSC Genome Browser and Galaxy in the same category? AFAIU UCSC Genome Browser in "just" a browser [1] while Galaxy is a "workflow management system" [2] (GWL is missing, and that _is_ the solution to the workflow problem space :-) ) Is Galaxy also capable of genome browsing? > You are talking about that [1], right? > But is it free software? Unfortunately not > I am not able to find the license and [2] is > not very helpful... > > [1] http://hgdownload.soe.ucsc.edu/downloads.html#source_downloads I know it's not a proper license attribution, but the very first sentence in "Source and utilities downloads" states: --8<---cut here---start->8--- The source for the Genome Browser, Blat, liftOver and other utilities is free for non-profit academic research and for personal use. For information on commercial licensing, see the Genome Browser and Blat licensing requirements. The source and executables for several of these products can be downloaded or purchased from our online store. --8<---cut here---end--->8--- To download the source code you have to buy it https://genome-store.ucsc.edu/ and on checkout there is this option: --8<---cut here---start->8--- During checkout, non-profit academic users will be given the option to declare that they are not using the products commercially and qualify for a free license. --8<---cut here---end--->8--- Source code is free like free beer. > [2] http://genome.ucsc.edu/license/ This page also points to the EULA http://genome.ucsc.edu/license/gbLicense2019.pdf HTH, Gio' [1] https://en.wikipedia.org/wiki/Genome_browser [2] https://en.wikipedia.org/wiki/Bioinformatics_workflow_management_system -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
