Re: Feedback from JRES in Dijon
Hi Bengt, > BTW3, Konrad, > That was a nice presentation -- are the tools you used to prepare it and > present it > available as libre packages? (I'm not insisting you answer ;-) That's LaTeX with the Beamer package, plus Inkscape for the graphics. It's all in Guix. A bit of history: for many years I used Apple's Keynote software for my presentations. Until I discovered one day that I couldn't open my old presentations any more. Apple had changed the format a few times, and then quietly dropped support for the older formats. And the older software versions that could read the old presentations were no longer available. So now it's LibreOffice for short quick-and-dirty slide hacking, and LaTeX with Beamer for everything else. Cheers, Konrad.
Re: Overhauling the cargo-build-system
Hi,
Ludovic Courtès writes:
> 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 nice. However, it doesn't seem possible to express
Cargo's "dependencies" and "dev-dependencies" concepts using Guix's
current package DSL.
Consider the proc-macro2 and quote crates. We added these two crates in
commit 2444abd9c124cc55f8f19a0462e06a2094f25a9d, in the same patch
series where we added #:cargo-inputs and #:cargo-development-inputs:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35318
Here is the Cargo.toml file for proc-macro2:
https://github.com/alexcrichton/proc-macro2/blob/master/Cargo.toml
[dev-dependencies]
quote = { version = "1.0", default_features = false }
And here is the Cargo.toml file for quote:
https://github.com/dtolnay/quote/blob/master/Cargo.toml
[dependencies]
proc-macro2 = { version = "1.0", default-features = false }
Here is a diagram of their dependency relationship:
+---+
| quote | <+
+---+ |
||
| dependencies | dev-dependencies
v|
+---+ |
| proc-macro2 | -+
+---+
To Cargo, this cycle is not a problem, since "dev-dependencies" are
treated differently from "dependencies":
https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html
"Dev-dependencies are not used when compiling a package for building,
but are used for compiling tests, examples, and benchmarks.
These dependencies are not propagated to other packages which depend
on this package."
The reason proc-macro2 declares a "dev-dependency" on quote is because
proc-macro2 uses quote in its doc tests:
https://github.com/alexcrichton/proc-macro2/blob/e82e8571460a0a0e00f52f011a74a5e0359acf3e/src/lib.rs#L785
This relationship between proc-macro2 and quote cannot be readily
expressed using the current package DSL in Guix. If you try to model
"dependencies" and "dev-dependencies" as "inputs" (or "native-inputs",
or some combination of the two), Guix will fail due to the cycle.
Presumably, proc-macro2 just needs the source of quote (and the source
of proc-macro2's other dependency, unicode-xid). When Cargo builds
proc-macro2, it will take care of building quote and making it available
during proc-macro2's tests. Guix "just" needs to provide proc-macro2
with the quote source. You might think this poses a bootstrapping
problem for Cargo, but I guess it doesn't. As long as Cargo has the
source for proc-macro2, quote, and unicode-xid, I guess it can build
proc-macro2 and quote in any order.
Unless we missed something in our discussion of patch 35318, there is no
easy way to express the relationship between proc-macro2 and quote
without changing (or mis-using) the existing package DSL. In the same
way that the package DSL introduced "native-inputs" and "inputs" as
concepts to facilitate cross-compilation, one way to solve this problem
might be to introduce a new concept to the package DSL that would make
it possible for Guix to express this kind of relationship correctly.
However, in the discussion of patch 35318, everyone (myself included)
seemed opposed to changing the package DSL if we didn't have to. For
example, in response to an earlier version of the patch series in which
we tried to map "dependencies" and "dev-dependencies" onto the "inputs"
and "native-inputs" concepts (which was probably an abuse of the package
DSL, since "native-inputs" is a cross-compilation concept), you said: "I
don't understand yet why you change the role of 'inputs' compared to how
it is in the rest of Guix." Ultimately, we decided not to modify the
package DSL or the meaning of "inputs". Instead, we decided to encode
the necessary information about dependencies in the cargo-build-system's
arguments. That is how we arrived at #:cargo-inputs and
#:cargo-development-inputs.
By introducing #:cargo-inputs and #:cargo-development-inputs as package
arguments to the cargo-build-system, we were able to solve the cyclic
dependency problem in one specific way. Perhaps there are better ways.
I agree it would be nice if it were integrated into the package DSL. I
think that changing the package DSL to suit our needs might work, but
I'm not sure how to change it without making it too Cargo-specific.
> 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.
Well, you're not alone! I'm not (yet!) an expert in Rust, but I find
these problems difficult to understand, too. Cyclic dependencies are
just one issue. There are other problems, too.
One problem that Efraim has mentioned is that every crate wants all of
its sources to be available at build time. It's as if each crate wants
all of its source crates (and all of their source crates, transitively)
to be propagated
Re: New POWER9 machines for the Guix build farm?
On 12/9/19 1:19 AM, Chris Marusich wrote: Tobias Geerinckx-Rice writes: Fellow Guix, The Guix sysadmins are considering buying shiny hardware for the ci.guix.gnu.org build farm, and it would be awesome if that included our first POWER9 machine(s)! However, few (if any) Guixers have any hands-on experience with this architecture, let alone buying and installing whole systems. Some remember a bad experience with a prominent vendor, and it would appear that they're not alone[0]. There's also some concern that getting these machines up and running will take significant effort. So please, share your expertise and experience in this area! Ideally, we need someone to volunteer to (help) set up any new POWER9 boxes and later take care of them when needed. It would certainly help justify the multi-thousand-euro bill. Kind regards, T G-R PS: For the shorter term, I've applied for an 8-core POWER9 LE instance (with 16 GiB of RAM) for Guix at OSUOSL[1]. Assuming that it's accepted, it should be available within a week. [0]: https://drewdevault.com/2019/09/23/RaptorCS-Blackbird-a-horror-story.html, but read https://drewdevault.com/2019/10/10/RaptorCS-redemption.html as well :-) [1]: https://osuosl.org/services/powerdev/ I think it's a great idea. To test the waters, someone could try using one of these free VMs and see how Guix System does on them: https://openpowerfoundation.org/minicloud-free-openpower-cloud/ First, bootstrap binaries have to be built for the hardware, anyway, right? Maybe someone can do that work on one of those free VMs? That work is already done! See: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38459 Current issue is gcc-cross-boot0 not building. See build log at: https://gitlab.com/lle-bout/guix/-/jobs/372934160
Re: New POWER9 machines for the Guix build farm?
Tobias Geerinckx-Rice writes: > Fellow Guix, > > The Guix sysadmins are considering buying shiny hardware for the > ci.guix.gnu.org build farm, and it would be awesome if that included > our first POWER9 machine(s)! > > However, few (if any) Guixers have any hands-on experience with this > architecture, let alone buying and installing whole systems. Some > remember a bad experience with a prominent vendor, and it would appear > that they're not alone[0]. > > There's also some concern that getting these machines up and running > will take significant effort. > > So please, share your expertise and experience in this area! Ideally, > we need someone to volunteer to (help) set up any new POWER9 boxes and > later take care of them when needed. It would certainly help justify > the multi-thousand-euro bill. > > Kind regards, > > T G-R > > PS: For the shorter term, I've applied for an 8-core POWER9 LE > instance (with 16 GiB of RAM) for Guix at OSUOSL[1]. Assuming that > it's accepted, it should be available within a week. > > [0]: > https://drewdevault.com/2019/09/23/RaptorCS-Blackbird-a-horror-story.html, > but read https://drewdevault.com/2019/10/10/RaptorCS-redemption.html > as well :-) > [1]: https://osuosl.org/services/powerdev/ I think it's a great idea. To test the waters, someone could try using one of these free VMs and see how Guix System does on them: https://openpowerfoundation.org/minicloud-free-openpower-cloud/ First, bootstrap binaries have to be built for the hardware, anyway, right? Maybe someone can do that work on one of those free VMs? -- Chris signature.asc Description: PGP signature
Re: Feedback from JRES in Dijon
Hi Tim, Konrad, On +2019-12-07 23:11:19 -0500, Timothy Sample wrote: > Hi Bengt, > > I omitted a lot of your message, but I hope I have the easy explanation > you’re looking for. :) > > Bengt Richter writes: > > > On +2019-12-07 11:35:02 -0500, Timothy Sample wrote: > >> > >> [...] > >> > >> Unfortunately, I got certificate errors, but VLC lets you temporarily > >> ignore those. > > > > [...] > > > > Anyone see an easy explanation? > > After a little more digging, it seems that the certificate sent for > “ccwebcast.in2p3.fr” is signed with an intermediate certificate from > “TERENA”. This is in turn signed with a DigiCert root certificate. > Unfortunately it looks like “ccwebcast.in2p3.fr” doesn’t send the whole > certificate chain, and the TERENA cert is not part of our “nss-certs” > package, so tools using certs from that package (basically everything on > a normal Guix install) will be unwilling to trust “ccwebcast.in2p3.fr”. > IceCat is okay with it, but it uses its own certificates (it must know > about the TERENA cert, so it doesn’t need the whole chain). > > Fortunately, for exceptional situations like this, you can tell most > tools to skip certificate validation (like I mentioned with VLC). For > youtube-dl, you can use the “--no-check-certificate” option. Note > however that this is rather dangerous in general, since you are telling > youtube-dl allow anyone to pretend to be anyone else! In this case, > since it’s just a video and IceCat is okay with the certificate it’s > probably fine. Just be careful. :) > > > -- Tim Thank you very much for digging and providing the dangerous solution :) (I suppressed my paranoia this once, and it did work BTW :) BTW2, I have icecat installed, so I wonder if, given that it "uses its own certificates" (and knows about TEREMA) is there a cert-PATH that could be extended so other apps see icecat's cert info in addition to their own? BTW3, Konrad, That was a nice presentation -- are the tools you used to prepare it and present it available as libre packages? (I'm not insisting you answer ;-) -- Regards, Bengt Richter
Re: Running Guix on a Hetzner Virtual Machine
On 08.12.19 18:50, Christopher Baines wrote: > Hey, > > I just succeeded in setting in getting Guix running on a virtual server > hosted by Hetzner. > > They don't offer an ISO image for Guix (yet… I've submitted a ticket), > so I installed from the rescue system. The only snag was virtio_scsi > Linux module needed adding to the initramfs, otherwise /dev/sda didn't > show up. Nice, I did the same. See https://lists.gnu.org/archive/html/guix-devel/2019-06/msg00036.html If we ask often enough, they maybe will add Guix to the default ISOs.
Re: Running Guix on a Hetzner Virtual Machine
Pierre Neidhardt writes: > What about a "Hardware and Hosting" section in the cookbook? Haha, I meant to say in my email that maybe the manual isn't appropriate, but there could be a section in the _cookbook_. signature.asc Description: PGP signature
Running Guix on a Hetzner Virtual Machine
Hey, I just succeeded in setting in getting Guix running on a virtual server hosted by Hetzner. They don't offer an ISO image for Guix (yet… I've submitted a ticket), so I installed from the rescue system. The only snag was virtio_scsi Linux module needed adding to the initramfs, otherwise /dev/sda didn't show up. Is there a best place to document these little configuration issues? The manual probably isn't appropriate, but maybe there could be a "Hardware and Hosting" section in the manual to document this? Chris signature.asc Description: PGP signature
Package request: FNA-XNA (Mono)
Has anyone worked on FNA-XNA? https://github.com/FNA-XNA/FNA If not, I'd like to package it. This is my first Mono package, any recommendation? Cheers! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: On DSLs
Hi Simon, > Out of curiosity, do you have examples about YAML or JSON with an > interpreter running it? I just encountered an example: GitHub actions. Cheers, Konrad.
