Re: bug#60227: guile-ssh 0.16 update
On 2022-12-21, Ludovic Courtès wrote: > Vagrant Cascadian skribis: > >> Well, that is what I did, pulled guix to the curren wip-guile-ssh-0.16 >> branch (which contains an update to guile-ssh 0.16 and updates guix to >> use a commit containing that), and managed to guix copy from one machine >> to another, so I *think* we are good! > > As mentioned on IRC, I tested it with ‘GUIX_DAEMON_SOCKET=ssh://…’ and > ‘guix copy’, and it all seems good. So I think you can go ahead! Ok, pushed as 0744540d09ddef8dbf25cc5d65da9d029dab338c. >> Patch attached for the guile-ssh update. Once that lands in master we >> can consider updating guix to use it... > > No need to update the ‘guix’ package, or am I missing something? The > ‘guix’ package depends on guile-ssh, so it’ll end up using the new > version anyway. Probably (clearly?) just me overthinking it and somehow... guix builds with the inputs from the guix commit defined in the guix package, not just as the source code for the guix package built with the currently defined guix inputs to using the guix build tool... guix building guix with guix and with guix defining the guix inputs... to alleviate risk of casuing any genuine (further) confusion... I'll trust your judgement here! live well, vagrant signature.asc Description: PGP signature
security tracking NLNet grant
Anyone knows who is/was working on this and what happened to the project? The site only links to general Guix pages. https://nlnet.nl/project/GUIX-securitytracking/
Re: guix package path
Hi,
Antonio Carlos Padoan Junior skribis:
> I would like to give some feedback concerning this issue I faced.
> I found an offending package definition in my channel (but the issue is only
> present when using -L argument):
>
> (define-public gtklp
> (let ((toolchain (specification->package "clang-toolchain@10")))
> (package-with-c-toolchain gtklp-bad-tool `(("toolchain" ,toolchain)
>
> For instance, when using "guix build -L ... gtklp", the alternative toolchain
> did not
> get called and compilation fails because of that (toolchain must be
> clang-toolchain@10).
We don’t have enough info to be sure, but could it be that there are two
‘gtklp’ packages in your package collection, for instance because
‘gtklp-bad-tool’ is also public? ‘specification->package’ prints a
warning if it’s ambiguous.
HTH,
Ludo’.
Re: git-fetch without a hash
Hi, Stephen Paul Weber skribis: > It seem that url-fetch will work without a hash (that is, with (sha256 > #f)) but git-fetch will not. (sha256 #f) is not a documented use case. :-) > As near as I can tell this is because git-fetch uses a fixed > derivation build going via nix/build.cc stuff which contains this > line: > > if (i.second.hash == "") fixedOutput = false; > > And this results in /etc/resolv.conf not getting written and DNS > resolution failing. > > Now, I *think* by my reading that it is intended for *only* > fixed-output derivations to have network access, because otherwise the > operation would be impure? Yes, exactly. > And then url-fetch is just not actually ending up in a build container > and so it works even when it isn't fixed-output? If an origin has (sha256 #f), it is *not* lowered to a fixed-output derivation; consequently, its build environment lacks network access, etc. > However, there's no real reason that git-fetch *needs* to be > fixed-output in terms of having a hash pre-defined, at least for local > development and other purposes. So is there a way around this? What’s your use case? If you want a package to refer to, say, the tip of the “main” branch of some Git repo, then you can: • use ‘--with-branch=PKG=main’, or • write (package (source (git-checkout …)) …) Both are actually equivalent. ‘git-checkout’ represents a checkout made on the client side, without knowing in advance what you’ll get out of this checkout. (So use with care, too.) > If having a way around it is not desirable should url-fetch consider > this an error as well? I’m not sure; do you have an example where it’s not behaving as expected? > Finally, *if* git-fetch should not allow this, the current error > message is beyond confusing (DNS resolution fails during git fetch and > it tries to fall back to SWH). So should git-fetch check for hash of > #f and raise at that point with a better error message in that case? Ideally, ‘origin’ would prevent a hash of #f altogether. However, there are a couple of weird use cases in (gnu packages …) that need to be supported. We should probably consider using a different trick there, such as using a computed-file instead of an origin; we’ll have to check what’s feasible. Thanks, Ludo’.
Re: bug#60227: guile-ssh 0.16 update
Howdy! Vagrant Cascadian skribis: > Well, that is what I did, pulled guix to the curren wip-guile-ssh-0.16 > branch (which contains an update to guile-ssh 0.16 and updates guix to > use a commit containing that), and managed to guix copy from one machine > to another, so I *think* we are good! As mentioned on IRC, I tested it with ‘GUIX_DAEMON_SOCKET=ssh://…’ and ‘guix copy’, and it all seems good. So I think you can go ahead! > Patch attached for the guile-ssh update. Once that lands in master we > can consider updating guix to use it... No need to update the ‘guix’ package, or am I missing something? The ‘guix’ package depends on guile-ssh, so it’ll end up using the new version anyway. Thanks! Ludo’.
u-boot-am335x-boneblack -> u-boot-am335x-evm-boneblack
Wondering what necessitated this change from the old variable name to a new name... commit c04528d2a2597d79278833f3607c806278253446 Author: Maxim Cournoyer Date: Tue Dec 20 21:25:27 2022 -0500 gnu: u-boot-am335x-evm-boneblack: Fix variable name. * gnu/packages/bootloaders.scm (u-boot-am335x-boneblack): Rename to... (u-boot-am335x-evm-boneblack), to match the package name. * gnu/bootloader/u-boot.scm (u-boot-beaglebone-black-bootloader): Adjust accordingly. ... diff --git a/gnu/packages/bootloaders.scm b/gnu/packages/bootloaders.scm index bd9f7bb577..c8b8adbc93 100644 --- a/gnu/packages/bootloaders.scm +++ b/gnu/packages/bootloaders.scm @@ -889,7 +889,7 @@ (define*-public (make-u-boot-package board triplet (define-public u-boot-malta (make-u-boot-package "malta" "mips64el-linux-gnuabi64")) -(define-public u-boot-am335x-boneblack +(define-public u-boot-am335x-evm-boneblack (make-u-boot-package "am335x_evm" "arm-linux-gnueabihf" ;; Patch out other device trees to build an image small enough to fit The u-boot-am335x-boneblack was named to match the original target that was removed from upstream, adapting the upstream am335x-evm to fit into a smaller gap in the partition tables... (e.g. 2MB partition offset instead of 4MB offset required by the default am335x-evm board configuration). Was this a side-effect of some of the changes that were implemented with the raspberry pi series? Is the name change actually needed in some way, or is it just "housecleaning" ? It doesn't actually "match" the name of the target, which is "am335x_evm", not "am335x_evm_boneblack". I would think keeping the old name would allow for seamless upgrades. Or at least leaving a deprecated package placeholder or something like that if the rename is actually needed... but a little unclear on the situation at the moment. With all that said... having 512MB of ram, I wonder how well a beaglebone black would do running guix at all... Are people actually using some of these low-end boards with guix? I'll admit, I added a bunch of them in my early days of enthusiastically contributing to guix... but wonder if they are pragmatic to use. live well, vagrant signature.asc Description: PGP signature
Re: Status of hibernation (suspend to disk) in Guix
Ivan Vilata i Balaguer (2022-12-14 10:43:46 +0100) wrote: > Since it's unlikely that the file will change its block arrangement on disk, > and enlarging it requires another invocation of `mkswap`, it's probably enough > to tell the user to check for such warnings on `mkswap` invocation (in section > "(guix)Keyboard Layout, Networking, and Partitioning"), and then instructing > them to use `filefrag` in "(guix)Swap Space" should be ok. > > I can work on an additional patch for that, but I can't ensure that it'll be > ready before 1.4.0 (I'm not in the dev team, so I don't know what the planning > for the release is ). Ooops, too late anyway for 1.4.0 (congrats for the dev team BTW)! I sent an alternative, more elaborated patch to #59746. Some notes: - Both `mkswap` and `swapon` complain about swap files with holes, so I deemed it redundant to add notes about that (and besides, it should be rare enough when using the `dd`-based creation technique). - `filefrag` does work on non-Ext2 filesystems (by falling back to an older ioctl), one just needs to force the extents output (`-e`) and run it as root in case the newer ioctl fails. I used that in the swap file example. - Yeah, there's a specific swap file example now with instructions on how to get the offset with `filefrag`. I hope that the new patch is more complete and straightforward than the previous one. Thanks everyone for the extra info, cheers! -- Ivan Vilata i Balaguer -- https://elvil.net/ signature.asc Description: PGP signature
