Re: Overhauling the cargo-build-system
On Sat, Nov 16, 2019 at 10:33:32PM +0100, Ludovic Courtès wrote: > Hello! > > Martin Becze skribis: > > > Sorry for digging up and old issue, but i just saw commit > > 86e443c71d4d19e6f80cad9ca15b9c3a301c738c > > > >> It makes for a very large package definition, but we > > wouldn't have to ensure thousands of other rust libraries built so we > > > > The whole point of package management is that you can use module > > building blocks. By having to specify the sub-dependencies in a top > > level definition kinda breaks the whole modular thing. In commit > > 86e443c71d4d19e6f80cad9ca15b9c3a301c738c all the inputs got removed for > > all the libraries. So if I'm trying to use guix as package manager for a > > rust project and I want to use one of the rust libraries in > > crates-io.scm, how am i suppose to do this? I can't just include it as > > an input to my project because now I have to look up all of it > > dependencies as well? > > I agree that removing all the dependencies from Rust packages feels > wrong. > > What I would have liked is to somehow replace the #:cargo-inputs > argument (which is build-system-specific and thus “opaque”) with regular > ‘native-inputs’ or ‘inputs’ field. > > I know it’s not that easy with Rust and Cargo, I just never manage to > fully grasp why :-), but at least that should be our horizon IMO. > > WDYT, Efraim, Martin, and other Rusty people? :-) > The big problems are the recursive dependencies, the partial dependencies and the versioning. There are some that are easy to figure out, serde always needs serde-derive, winapi always needs the winapi-[i686|x86_64] crates, rayon -> rayon-core, etc. The real problem is that each crate has a number of features, and only needs certain inputs based on those features. If we include too few then we're stuck specifying dependencies anyway. If we include all of them then we're stuck packaging way more versions of things than we actually need. This by itself might not be a problem; we could just say "this is what the importer gave us based on upstream, if you're missing something you're on your own to add it." I have one package that I was working on, a custom rust package (which is unfortunately still missing a license file). In the end I needed about 70 crates. Before the change I had it building with about 200 packaged crates but the file itself failed to compile with a 'guix pull' because of all the still unpackaged crates which were referenced by other packaged crates. I still haven't reached the bottom of that tree, and I have more than 500 crates that I haven't upstreamed yet. The current situation definitely could be better. Without opening the repo there's no way to know which crates are packaged. When updating a crate there's no way to know which packages will be rebuilt. I suppose one way to work around some of the issues is to make it so that the crates "build" by copying the source to %out/share/guix-vendor or something. -- 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: Overhauling the cargo-build-system
> What I would have liked is to somehow replace the #:cargo-inputs > argument (which is build-system-specific and thus “opaque”) with regular > ‘native-inputs’ or ‘inputs’ field. That would be lovely! I always wondered why "#:cargo-inputs" existed.
Re: gnome-characters
On Sat, 16 Nov 2019 19:50:12 -0500 Raghav Gururajan wrote > Hello Guix! > > So I was able to successfully package 'gnome-characters'. The following > is the package definition. I have attacted the package definition > (gnome-characters.scm) with this email. > > This is the first time for me with packaging. Can anyone help me how to > move forward from here, to integrate this with guix upstream? Maybe it could help to read the Contributing section in GNU Guix Reference Manual (https://guix.gnu.org/manual/en/html_node/Contributing.html#Contributing). You will find packaging guidelines and information about submitting patches to add your package. I haven't submitted any package myself yet, but I would start there, and ask here in case of doubts. Some things I noticed in your package definition: • Indentation probably does not follow the coding style of Guix. • Is the value for "home-page" correct? Maybe it should be https://wiki.gnome.org/Design/Apps/CharacterMap instead? • In origin's uri there seems to be an unnecessary use of "string-append", as you are only passing one string (not appending two or more). --- https://sirgazil.bitbucket.io/
Why is the default $HOME /homeless-shelter?
gnome-characters
Hello Guix!
So I was able to successfully package 'gnome-characters'. The following
is the package definition. I have attacted the package definition
(gnome-characters.scm) with this email.
This is the first time for me with packaging. Can anyone help me how to
move forward from here, to integrate this with guix upstream?
Thank you!
Regards,
RG.
(use-modules
(guix packages)
(guix download)
(guix build-system meson)
(guix licenses)
(gnu packages libunistring)
(gnu packages pkg-config)
(gnu packages gnome)
(gnu packages gtk)
(gnu packages gettext)
(gnu packages glib))
(package
(name "gnome-characters")
(version "3.30.0")
(source
(origin
(method url-fetch)
(uri
(string-append "https://download.gnome.org/sources/gnome-characters/3.30/gnome-characters-3.30.0.tar.xz;))
(sha256
(base32 "08cwz39iwgsyyb2wqhb8vfbmh1cwfkgfiy7adp08w7rwqi99x3dp"
(build-system meson-build-system)
(inputs
`(
("libunistring", libunistring)
("pkg-config", pkg-config)
("gjs", gjs)
("gtk+", gtk+)
("gettext", gettext-minimal)
("glib:bin", glib "bin")
("gtk+:bin", gtk+ "bin")))
(synopsis "GNOME Characters")
(description "Characters is a simple utility application to find and insert unusual characters. It allows you to quickly find the character you are looking for by searching for keywords.")
(home-page "https://wiki.gnome.org/Apps/Characters;)
(license gpl2))
signature.asc
Description: This is a digitally signed message part
Re: Stackage LTS 14
Hi, Marius Bakke writes: > I've read some of the changes and they LGTM. If Cuirass is happy, I > think you can go ahead and merge the branch. \o/ I just put everything together and rebased it all on master, fixing several typos as I did so. :) It seems that “ghc@8.6.5” has changed a few days ago on master, so everything will have to be rebuilt. Given that, I recreated the wip-haskell-updates branch so that the build farm can get to it. Once it’s done, I’ll push to master. The only thing I wanted to mention was that I sneaked a newer version of “libyaml” (0.2.1) in along side the old version (0.1.7). The Haskell bindings required the newer version. It’s possible that we could just update the old version, but it has quite a few dependencies, so I didn’t want to get tangled up in it. I’m bringing it up because it’s the only non-Haskell change in the commits, and I don’t want anyone to be surprised. :) -- Tim
Re: [PATCH 2/2] Support publishing evaluation events
Ludovic Courtès writes: > Christopher Baines skribis: > >> --- >> src/cuirass/base.scm | 5 + >> src/cuirass/database.scm | 6 +- >> src/cuirass/http.scm | 9 + >> 3 files changed, 19 insertions(+), 1 deletion(-) >> >> diff --git a/src/cuirass/base.scm b/src/cuirass/base.scm >> index fd10e35..943a4f2 100644 >> --- a/src/cuirass/base.scm >> +++ b/src/cuirass/base.scm >> @@ -724,6 +724,11 @@ started)." >> (checkouts (fetch-inputs spec)) >> (eval-id (db-add-evaluation name checkouts))) >> (when eval-id >> + (db-add-event 'evaluation >> +(time-second (current-time time-utc)) >> +`((#:evalutaion. ,eval-id) > ^^^ > Typo. Hmm, I remember testing this, but I guess it just sent out a JSON object with that typo in it. >> + (#:specification . ,name) >> + (#:in_progress . #t))) > ^ > Should it be a hyphen? This'll end up being part of the JSON object sent out. It looks like the existing /api/evaluations reponse uses in-progress, so this should probably also be a hyphen for consistency. > Otherwise LGTM. > > I think we should eventually use records everywhere instead of alists, > as that would catch such typos. We could use an approach similar to > that of ‘define-json-mapping’ to factorize > serialization/deserialization. That sounds like a good idea :) Thanks, Chris signature.asc Description: PGP signature
Re: Missing fonts when compiling latex documents
Pierre Neidhardt writes: > Sorry for the troubles, indeed only the big "texlive" package is fully > functional with Guix at the moment. This statement could be misunderstood. The individual texlive packages work pretty well for many use cases. I myself have been using them since they have become available and I have no problems formatting letters with g-brief, for example. Some package combinations might not work, but that’s not because only the big “texlive” package is fully functional, but because there are minor bugs in the configuration when using split packages that are exposed when certain packages are used. We should treat these bug reports on a case by case basis. There are no known big issues that need fixing with the individual packages. What should be done, though, is to provide a meta-package that installs most (if not all) of the individual packages for an experience similiar to that of having installed the big “texlive” package — only modular. @Alexandros: could you please show us the error message you get? The messages usually include the names of LaTeX packages that have not been found. -- Ricardo
Re: [PATCH 1/2] Support publishing build events
Ludovic Courtès writes: > Hi Chris, > > Christopher Baines skribis: > >> --- >> Makefile.am | 8 +- >> bin/cuirass-send-events.in | 90 +++ >> src/cuirass/base.scm| 9 ++- >> src/cuirass/database.scm| 142 +--- >> src/cuirass/http.scm| 24 ++ >> src/cuirass/send-events.scm | 69 ++ >> src/schema.sql | 12 +++ >> src/sql/upgrade-5.sql | 15 >> 8 files changed, 356 insertions(+), 13 deletions(-) >> create mode 100644 bin/cuirass-send-events.in >> create mode 100644 src/cuirass/send-events.scm >> create mode 100644 src/sql/upgrade-5.sql > > Sorry for the delay. It LGTM, thank you! > > Please add a commit log :-), and let us know when you’d like to test > with the instance on berlin or that on bayfront. Great :) I have access to bayfront already, so I think that's the place to try this out initially. > IIUC, the ‘send-events’ program is provided as a debugging aid, right? > I mean it’s not used anywhere in the code. Well, it would be potentially better to send the events from the same Cuirass process that manages the builds, as then the events could be sent out immediately. However, I don't really know how fibers work, so I went with a separate process to make it easier to manually test, and to reduce any risk of interfering with other Cuirass functions. > If you can think of ways to tests parts of this, that’d also be great, > but it shouldn’t block it. Ok. I'll hopefully have some time in the next week or two to take another look. I'll add change logs to the commits, do some more manual testing, and have a look at writing some automated tests. Thanks, Chris signature.asc Description: PGP signature
Re: Missing fonts when compiling latex documents
Hello! Pierre Neidhardt skribis: > Sorry for the troubles, indeed only the big "texlive" package is fully > functional with Guix at the moment. Hmm, is this accurate? I mean, all the packages uses ‘texlive-union’ internally, and with the texlive profile hook, we should now be able to make do with individual texlive packages, no? Thanks, Ludo’.
Re: #850644: RFP: Guix in Debian
Hi Vagrant, Vagrant Cascadian skribis: > On 2019-05-28, Vagrant Cascadian wrote: >> On 2019-05-16, Vagrant Cascadian wrote: >>> So in a bit of a focused run of packaging, I've been chasing the >>> dependency chain necessary to get guix building on Debian: > > Summary: all the dependencies are in Debian! Awesome! Congrats and a big thank you, wooohoo! \o/ Ludo’.
Re: Profiles/manifests-related command line interface enhancements
Howdy! Konrad Hinsen skribis: >> I think having ephemeral + persistent and declarative + imperative is >> cool—I’d call that “flexible” rather than “messy”. :-) > > I agree. What's messy is how the concepts map to commands. How many Guix > users understand that profiles are persistent environments, or > environments ephemeral profiles? And how many understand what "guix > environment -r" does exactly, and how it should be used? It took me a > while to figure this out. > > What we have is two commands (package and environment) each designed for > one main usage pattern, plus options to get something else. But even > those options don't overlap completely in functionality. For example, > how do I make a profile with the dependencies of a package? > > The current discussion started with adding more commands for different > specific usage patterns. If we go that route the mess will become worse. OK, I understand. >> It’s great to have “guix install” as an entry point; I’m sure it allows >> us to reach out to more people, and that matters too. (I actually use >> it, BTW, so it’s not an expert vs. newbie thing!) > > Me too :-) It's "guix package" that is the worst offender in my > opinion. It does two distinct things: querying the package database and > managing profiles. And now that we have "guix search" for queries, We also have ‘guix show’, but there’s no standalone command equivalent to ‘--list-installed’, ‘--list-available’, ‘--list-profiles’, and ‘--list-generations’. > I'd like to see "guix package" go away, to be replaced by either "guix > profile" for profile management, with as much overlap as possible in > options with "guix environment", or by a single command that handles > environments and profiles in a unified way. To me it’s not entirely clear that a unified command would be easier to use for newcomers. For example, I’m not fond of “guix profile” as a command name because that would mean users have to know what a “profile” is before they’ve even installed their first package. So I definitely agree we need to homogenize what ‘guix environment’ and ‘guix package’ currently provide, but I’m not sure where to go from there. Perhaps we need to discuss on concrete CLI proposals to have a better idea? Dunno! I have an actionable wishlist though: :-) 1. Arrange so that ‘--ad-hoc’ becomes the default in ‘guix environment’, and add a ‘--devel’ (?) option for what’s currently the default. Tricky because of compatibility considerations, but would be an improvement, and goes in the direction of shortening the distance between ‘guix environment’ and ‘guix package’. 2. Add that same ‘--devel’ option to ‘guix package’. Thoughts? >> I agree that sharing and publishing is important, and I think >> manifests support that. > > They do, but not very well in my opinion. I think everything meant to be > shared, published, and maintained should be accessible by name in a > database. A channel, for example. > > Some ideas that could make this possible (and convenient): > > - Better support for adding/managing channels at the user account >level. Users shouldn't have to edit Guile code (unless they want to). You mean like ‘guix channel add URL’? Are you looking at this from a UI perspective? Are you also suggesting a “GuixHub” (I already hate that name :-)) that would collect channels? In Strasbourg in June we discussed the possibility to have a service to register free software channels, we even came up with a name for that (was it “delta”?), and I think it could be useful. The “potluck” that Andy worked on a while back goes in that direction too. > - Support for creating and managing channels without having to >descend to the file and repository level. Not entirely sure what you mean. Could you give examples of what you’d type to create a channel, say? > - Support for something one could call super-packages or named >manifests. Named package groups that live in a channel (or a guix.scm >distributed with software external to Guix). Perhaps parametrizable >and/or containing configuration files, so you could put something >like (nginx #:port 8080) into a manifest file. So this thing would be a profile + services? >> What we’re now saying is “look, you can write a manifest, and then you >> can have it under version-control and publish it and it’s all up to you >> how you do that”; but you seem to suggest that we should offer a >> higher-level, more integrated solution, is that correct? > > Exactly. Every functionality that requires end-users to manage > Guile code will always be restricted to expert users. Manifest > files may look simple and understandable for simple cases, > but if you expect users to install manifests downloaded from > someone else, they need to be able to inspect them and be sure > that installing the manifest file won't delete their user account. > And that means they have to understand a lot about Guile. OK, I
Re: Profiles/manifests-related command line interface enhancements
Hi Konrad, Konrad Hinsen skribis: > YAML is for kids. Real managers won't settle for less than full XML. ;-) > > Seriously, as a power user, I am perfectly happy with Guile for > everything. I certainly don't want less. And for now, it's safe to > assume that most Guix users are power users. The question is if we want > Guix to remain exclusively a power tool for power users. I’d like to think that writing Guile declarations for the OS config, manifest, etc. is not just for “power users”. After all people, or rather “computer-savvy” people in a broad sense, write JSON, YAML, custom config files etc. routinely, and I don’t think the typical config we propose is any “harder”. You may say I’m a dreamer, but I’m not the only one. 텞텟 ;-) > If not, we need to make sure that it won't become a malware platform, > by making it safe to use for people who don't read Guile code. In > particular, common use cases should not require users do download > unrestricted Guile code from untrusted sources. Definitely! I think we need to focus on specific scenarios though. For example, when you add a channel to ~/.config/guix, you’ll end up running its unrestricted Guile code as soon as ‘guix pull’ is done. However, independently of that, you’ll most likely be installing packages defined in that channel, and then running them unrestricted. IOW, users of a channel have to trust it to not be malicious, regardless of the fact that its Guile code runs unrestricted. For manifests shared over the net, the situation may be different: a manifest could refer to packages in the channels you trust, and thus there’s value in not having to trust the manifest code itself. It’s still a bit too abstract, but for the purposes of sharing and publishing “super packages” as you wrote, we could define a purely-declarative format (could be JSON, could be Guile code that can run under (ice-9 sandbox) or with ‘eval/container’) that people could use instead unrestricted as is currently the case. Thanks, Ludo’.
Re: guix pull failed after 8 hours
Hi Chris, Chris Marusich skribis: > I've been updating some systems with a fairly old version of Guix, so > perhaps that contributed to the very long "guix pull" times. It felt > like Guix wanted to compile the whole world just to run "guix pull". Could it be that those old systems were talking to hydra.gnu.org and thus not getting any substitutes? https://lists.gnu.org/archive/html/info-guix/2019-06/msg1.html Thanks, Ludo’.
Re: [PATCH 2/2] Support publishing evaluation events
Christopher Baines skribis: > --- > src/cuirass/base.scm | 5 + > src/cuirass/database.scm | 6 +- > src/cuirass/http.scm | 9 + > 3 files changed, 19 insertions(+), 1 deletion(-) > > diff --git a/src/cuirass/base.scm b/src/cuirass/base.scm > index fd10e35..943a4f2 100644 > --- a/src/cuirass/base.scm > +++ b/src/cuirass/base.scm > @@ -724,6 +724,11 @@ started)." > (checkouts (fetch-inputs spec)) > (eval-id (db-add-evaluation name checkouts))) > (when eval-id > + (db-add-event 'evaluation > +(time-second (current-time time-utc)) > +`((#:evalutaion. ,eval-id) ^^^ Typo. > + (#:specification . ,name) > + (#:in_progress . #t))) ^ Should it be a hyphen? Otherwise LGTM. I think we should eventually use records everywhere instead of alists, as that would catch such typos. We could use an approach similar to that of ‘define-json-mapping’ to factorize serialization/deserialization. Thanks, Ludo’.
Re: [PATCH 1/2] Support publishing build events
Hi Chris, Christopher Baines skribis: > --- > Makefile.am | 8 +- > bin/cuirass-send-events.in | 90 +++ > src/cuirass/base.scm| 9 ++- > src/cuirass/database.scm| 142 +--- > src/cuirass/http.scm| 24 ++ > src/cuirass/send-events.scm | 69 ++ > src/schema.sql | 12 +++ > src/sql/upgrade-5.sql | 15 > 8 files changed, 356 insertions(+), 13 deletions(-) > create mode 100644 bin/cuirass-send-events.in > create mode 100644 src/cuirass/send-events.scm > create mode 100644 src/sql/upgrade-5.sql Sorry for the delay. It LGTM, thank you! Please add a commit log :-), and let us know when you’d like to test with the instance on berlin or that on bayfront. IIUC, the ‘send-events’ program is provided as a debugging aid, right? I mean it’s not used anywhere in the code. If you can think of ways to tests parts of this, that’d also be great, but it shouldn’t block it. Thanks, Ludo’.
Re: Overhauling the cargo-build-system
Hello! Martin Becze skribis: > Sorry for digging up and old issue, but i just saw commit > 86e443c71d4d19e6f80cad9ca15b9c3a301c738c > >> It makes for a very large package definition, but we > wouldn't have to ensure thousands of other rust libraries built so we > > The whole point of package management is that you can use module > building blocks. By having to specify the sub-dependencies in a top > level definition kinda breaks the whole modular thing. In commit > 86e443c71d4d19e6f80cad9ca15b9c3a301c738c all the inputs got removed for > all the libraries. So if I'm trying to use guix as package manager for a > rust project and I want to use one of the rust libraries in > crates-io.scm, how am i suppose to do this? I can't just include it as > an input to my project because now I have to look up all of it > dependencies as well? I agree that removing all the dependencies from Rust packages feels wrong. What I would have liked is to somehow replace the #:cargo-inputs argument (which is build-system-specific and thus “opaque”) with regular ‘native-inputs’ or ‘inputs’ field. I know it’s not that easy with Rust and Cargo, I just never manage to fully grasp why :-), but at least that should be our horizon IMO. WDYT, Efraim, Martin, and other Rusty people? :-) Thanks, Ludo’.
Re: Overhauling the cargo-build-system
> It is quite frustrating to have to specify transitive dependencies at > the top level. I’m not sure what else is to be done, though. How about having something like "propagated-input" for rust source dependencies? The top level package could use the source deps as development-inputs so the source files wouldn't end up polluting the environment. Would that make sense?
Re: Overhauling the cargo-build-system
Hi all, I agree with this: > The whole point of package management is that you can use module > building blocks. By having to specify the sub-dependencies in a top > level definition kinda breaks the whole modular thing. It is quite frustrating to have to specify transitive dependencies at the top level. I’m not sure what else is to be done, though. - John
Re: Packaging Jami progress
On Fri, 15 Nov 2019 10:07:38 +0100 Pierre Neidhardt wrote: Hello, When can I expect our changes to be merged? There's a new Jami version (20191115.5.b0a579d), I would like to update it to, but a strange conflict stops me from running "git pull". I also can't investigate the issue, until webkit-gtk substitute is available, because my laptop is underpowered. Jan Wielkiewicz
