cloud-init?
Hi I would like to deploy Guix VM's and in many VM hosting environments, having cloud-init on the Guix VM image would be useful for configuration of network interfaces etc. I tried searching the mailing list archives and bug database, but could not find anything except that the cloud-utils package has been added to Guix. The philosophy of cloud-init and Guix system configuration is probably at odds, but basic support for booting and starting sshd and printing the SSH fingerprint, and possibly some DHCP/network config is probably not too difficult to achieve. A 'cloud-init' package in Guix could do as much as is possible to do, or at least document the gap between philosophies. I haven't looked into packaging cloud-init, but first wanted to ask if anyone is aware of work in this area? Are people interested in this? I think I have three goals with this: 1) Package 'cloud-init' in Guix so that it is possible to create a VM image that virt-install can install with the --cloud-init parameters, that has basic support for booting the image and get network and sshd running. 2) Write a system.scm could eventually be used to prepare an official Guix "Cloud image". 3) Verify that Guix can be used as the VM host. I've already tried this a bit, and never ran into troubles so I don't expect any issues here. But maybe something is required to support virt-install --cloud-init. I know the quality of cloud-init infrastructure leaves a lot to be desired, but I think it has become too widespread to ignore. Fortunately cloud-init can be ignored once the system is up and running. I'm using it for VM installation of Debian, and once installed I just remove the cloud-init tools, and I would expect to do the same with Guix. See hints at the end of https://blog.josefsson.org/2022/08/22/static-network-config-with-debian-cloud-images/ /Simon signature.asc Description: PGP signature
Re: Disarchive database includes tar.xz archives
Hi, Cool! On dim., 07 août 2022 at 19:27, Ludovic Courtès wrote: > Computing these has been possible since Disarchive 0.4.0, which Timothy > released in Dec. 2021 but we had not updated > ‘etc/disarchive-manifest.scm’ to disassemble tar.xz archives in addition > to tar.gz. I do not the remember the status of tar.xz in nixguix SWH loader. > Note commit eab5366e679c149cf0a5abeb9a196700b171d9da excludes that > Chromium tarball: it takes 1.4 GiB (!) and when running ‘disarchive > disassemble’ on it, we hit the default max-silent time of 1h (and (gnu > ci) doesn’t let us specify a different timeout in this particular case.) > We could work around it by making Disarchive print a progress report, > which would be nice to have anyway. Or we could also ask if we need to disassemble and archive this Chromium tarball. Does the world need to hold such big program for just web browsing ? I am half-joking. :-) Cheers, simon
Re: [RFC] Use LLVM_BUILD_LLVM_DYLIB instead of BUILD_SHARED_LIBS
Hello, On Mon, Aug 22, 2022 at 11:57 PM, Maxim Cournoyer wrote: > Zhu Zihao writes: > [...] > >> # Solution >> >> I suggest to replace `-DBUILD_SHARED_LIBS:BOOL=TRUE` with >> `-DLLVM_BUILD_LLVM_DYLIB:BOOL=TRUE`. > > That's something I had been meaning to do for some time, but it fell > into the cracks. I'd welcome this change; you may want to look at > 'llvm-cling', which already builds using such flag. > Just wanted to chime in that I ran across this unexpected configuration when debugging some unrelated issues (had to do with Mesa library loading, so was looking at its dependencies). I think it would be good to follow this more expected and typical configuration for building LLVM, at least as far as I understand it. John
Re: Clarify the license field of the package
Hello 宋文武, On Mon, Aug 22, 2022 at 05:02 PM, 宋文武 wrote: > Hello list, I have some questions about the 'license' of a package, > currently defined as: > > The license of the package; a value from ‘(guix licenses)’, or a > list of such values. > > 1. It's the license of source files (guix build -S) or built binary >files? > Not a lawyer by any means, so I'm not sure how it works. For sure it applies to the source, but after building the binary output will contain a LICENSE or COPYING file (always? I would assume). Other than that, I don't know :) > 2. When its value is a list of multiple licenses, it's files under >different licenses (eg: lib/*.so under LGPL, while bin/* under GPL), >or files under one license select from choices? > In packaging, I have seen this when a package contains multiple sources for whatever reason, though we do try to unbundle as much as possible. I've also seen a few that just have multiple licenses as the source had specified multiple licenses, whether for different files or for user choice. Often, this is commented in the package definition for which license applies to which files, or why multiple are listed. For example, in the recent haxe package (which I wrote and I believe you pushed), the compiler and standard library are packaged together with different licenses. This is noted in the comments of the license field. While it may be possible to package these separately, I'm not sure if it really makes sense given how they are used and what upstream intends. > My guess is that the license field is for source files since we can > disable binary substitutes, and list is used for files under different > licenses. > > Does my guess is correct? Thank you! Those are my guesses/experiences above, hope that is helpful. John
Re: [RFC] Use LLVM_BUILD_LLVM_DYLIB instead of BUILD_SHARED_LIBS
On 20-04-2022 12:56, Zhu Zihao wrote: We may introduce following problems if we apply this solution. 1. Increase the closure size of LLVM. By default, if LLVM_BUILD_LLVM_DYLIB is set true, LLVM still tries to build the static archive. This may increase the closure size of LLVM. And some package linking with LLVM may use the static archive instead of linking to the dynamic library. My opinion: If we're OK with the bigger closure size, that's not a problem. If not, we may consider disable the static archive generation. For LLVM components, we can use `LLVM_LINK_LLVM_DYLIB` to ask these packages to link with the shared version. For package use `llvm-config` directly or indirectly, we can pass `--link-shared` to it. IIUC, this causes the static libraries to be built, right? If so, they could be moved into a separate output. I would prefer to disable static libraries, those cause problems with grafts and size usage. If not possible, I would prefer them to be in a separate output, to avoid them being used by accident and to reduce the closure size of dependents of LLVM that use the shared version. Greetings, Maxime. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Clarify the license field of the package
On 22-08-2022 11:02, 宋文武 wrote: Hello list, I have some questions about the 'license' of a package, currently defined as: The license of the package; a value from ‘(guix licenses)’, or a list of such values. 1. It's the license of source files (guix build -S) or built binary files? (If 'built binary files', I would include generated or copied documentation in the list. And icons, .desktop files, ..., I'm not restricting myself to _executable_ binaries here and also not to binaries that aren't sources as well.) Rarely, there is some weirdness where the source code is free (VSCodium?) but the official build has a non-free license (VSCode?). At least for that example, it doesn't apply to Guix though (because VSCodium is not packaged, and because with some rare exceptions we build from source). However, in my experience, in free software they almost always have the same license, so the distinction appears meaningless to me with the possible exception of build scripts and test files (including, but not limited to, test code). I think it should include the source files, as the license of the source is important for people doing 'guix build --source'. 2. When its value is a list of multiple licenses, it's files under different licenses (eg: lib/*.so under LGPL, while bin/* under GPL), or files under one license select from choices? My guess is that the license field is for source files since we can disable binary substitutes, and list is used for files under different licenses. Does my guess is correct? Thank you! As answered in a reply to a patch, myself I go for 'files under different licenses' -- to me it seems hard to go wrong with 'just include all participating licenses' instead of trying to make a selection. However, keep in mind that sometimes a file is part licensed as, say, BSD(*), part as Expat, with modifications under the GPL -- to me it appears that for practical purposes you could consider such a thing to be 'effectively GPL', but that's not 100% accurate, as it appears required to preserve the BSD and Expat license text. (Such things can happen when incorporating code from other, differently-licensed, projects). (*) let's say without the advertising clause or whatever it was (IIRC and IIUC the original BSD was incompatible with the GPL?). If there's some consensus, I think it would be nice to clarify this matter in the manual. Greetings, Maxime. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: cloud-init?
Hi Simon! I've been interested in adding cloud-init support for a while already. It would make Guix much easier to use in a cloud setting. I did ask people weather anyone is interested in it couple of times in #guix and also mentioned it on the mailing list couple of times. People didn't seem to express much interest but once they have it they'll like it a lot I think :) It is common practice to spawn other distro type and turn it into Guix or install Guix on it and do "guix system init" on mounted volume and then swap them. Not to mention the fact that every now and then there is a new question on running Guix on some other vendor. Guix deploy was made exactly for that in mind, wasn't it? I hacked together a little module that provides "cloud-init" service that makes a query to DigitalOcean HTTP API hosted on link-local address and does some essential stuff like configure the network, add SSH key and resize partitions and filesystem. https://github.com/ipdb/bigchaindb-guix/blob/master/bigchaindb-guix/services/cloud-init.scm So as you see I went in a different direction - rather than integrating actual cloud-init package I just made a Guile substitute for it. I am not sure which approach is best though. There are many cloud vendors and they all have slightly different APIs. On the other side, my guess is that cloud-init (the real one) is designed specifically to work with systemd and Debian derived distributions. I am not sure which way is a bigger hassle — to rewrite it our-self or try and add Guix support to cloud-init. I doubt that cloud-init team would be interested in Guix support upstreaming either. I tend to think that adding Guix-style cloud-init service could still be easier in the end. APIs don't differ that much and are pretty stable, plus all investigation is already done by cloud-init team — I didn't even read DigitalOcean docs when I wrote my module I just looked up what cloud-init does. But I'm interested in your opinion on it. Wait there is more on Guix cloud-init service. If you followed the code above, what it essentially does is it compiles a giant g-expression that does everything. As a result I borrowed some code from already existing Guix services. If cloud-init service was to do more it would mean even more duplication. But it is not how I wanted in a first place. It ended up like this because as I found out later that 1.) not all module are importable into a g-expression so I can't just import other Guix services procedures and reuse them 2.) you need to know all service-type arguments in advance (which not compatible with having idea of cloud-init at all :)). I think you can't spawn one service from another service either, you'll probably need to dig deeper and reach shepherd for that. But I am not sure about that. Someone mentioned "recursive derivations" that are not yet possible when I discussed that topic. But it would be cool if there was a way for Guix cloud-init service to query the environment compose and start other Guix services at startup. So-called "user-data" can be also used in interesting way too. There could be a "user-data" guile record that extends operating system somehow rather that bash-script. All in all I am glad I am not the only one interested in it. Cheers, -- David
