Re: The case for moving raw binaries
Am Donnerstag, dem 28.04.2022 um 21:57 +0200 schrieb Maxime Devos: > Liliana Marie Prikler schreef op do 28-04-2022 om 19:27 [+0200]: > > > How does this help with double wrapping? Whether the wrappers / > > > originals are put in /bin or $RAWBIN_DIR, it's still wrapped twice. > > Because $RAWBIN_DIR can be ignored when wrapping. This means that > > stuff that's already in it won't be added again. > > [...] > > Constructing the wrapper is not so much the problem, it's not > > wrapping the already wrapped binaries. > > Why can $RAWBIN_DIR be ignored when wrapping? If the build system just > sets $X during its wrappers, but the application needs $Y as well > (wrapped in a build phase), then if the extra wrapping is cancelled, > then the application won't get its $Y variable, which seems like a bug > to me. The extra wrapping isn't cancelled though? You just append the definition of $Y to the the already existing definitions, but you don't move the wrapper to $RAWBIN_DIR, because the actual binary already exists there. In other words, you have after wrap: - bin/foo ~> rawbin/foo and after wrap-again - bin/foo ~> rawbin/foo where ~> is the wrapping relation. Currently, you have after one wrap - bin/foo ~> bin/.foo-real after two - bin/foo ~> bin/.foo-real - bin/.foo-real ~> bin/..foo-real-real after three - bin/foo ~> bin/.foo-real - bin/.foo-real ~> bin/..foo-real-real - bin/..foo-real-real ~> bin/...foo-real-real-real and so on. Is this clearer now? Cheers
Re: The case for moving raw binaries
On Thu, 28 Apr 2022 21:57:04 +0200 Maxime Devos wrote: > Liliana Marie Prikler schreef op do 28-04-2022 om 19:27 [+0200]: > > > How does this help with double wrapping? Whether the wrappers / > > > originals are put in /bin or $RAWBIN_DIR, it's still wrapped > > > twice. > > Because $RAWBIN_DIR can be ignored when wrapping. This means that > > stuff that's already in it won't be added again. > > [...] > > Constructing the wrapper is not so much the problem, it's not > > wrapping the already wrapped binaries. > > Why can $RAWBIN_DIR be ignored when wrapping? If the build system > just sets $X during its wrappers, but the application needs $Y as well > (wrapped in a build phase), then if the extra wrapping is cancelled, > then the application won't get its $Y variable, which seems like a bug > to me. > > Greetings, > Maxime. It should be pretty easy to detect a wrapped binary without moving it. We could just include a magic string in it and scan for that, the exact same way we scan for store references. If it contains the "wrapped" magic UUID, it's wrapped.
Re: Hardened toolchain
Vagrant Cascadian writes: > On 2022-04-28, Aurora wrote: >> There are multicore processors made in the last decade or two that >> aren't affected by speculative execution vulnerabilities? > > There are some, such as the ARM-based Allwinner A64 used in in the > pinebook and pinephone. Probably various processors targeted at the > mobile market as well. Oh that's neat, I'd thought effectively all multicore CPUs were vulnerable. Thanks.
Re: The case for moving raw binaries
Liliana Marie Prikler schreef op do 28-04-2022 om 19:27 [+0200]: > > How does this help with double wrapping? Whether the wrappers / > > originals are put in /bin or $RAWBIN_DIR, it's still wrapped twice. > Because $RAWBIN_DIR can be ignored when wrapping. This means that > stuff that's already in it won't be added again. > [...] > Constructing the wrapper is not so much the problem, it's not > wrapping the already wrapped binaries. Why can $RAWBIN_DIR be ignored when wrapping? If the build system just sets $X during its wrappers, but the application needs $Y as well (wrapped in a build phase), then if the extra wrapping is cancelled, then the application won't get its $Y variable, which seems like a bug to me. Greetings, Maxime. signature.asc Description: This is a digitally signed message part
Re: Hardened toolchain
Katherine Cox-Buday writes: > Aurora writes: >> There are multicore processors made in the last decade or two that >> aren't affected by speculative execution vulnerabilities? > > They are vulnerable to them, but not necessarily affected by them. > Consider a computer not networked to the internet and only running > trusted workloads (e.g. scientific HPC, etc.). This is why acknowledging that > everyone has a different threat model is important. > > I hope this helps to clarify. It does help, that makes sense, thanks.
Re: Hardened toolchain
On 2022-04-28, Aurora wrote: > Katherine Cox-Buday writes: > >> Everyone has different threat models and needs. A lot of computers have CPU >> speculative execution attack mitigation disabled because those types of >> attacks will never affect those computers, and it reduces the performance of >> the CPU a lot. > > There are multicore processors made in the last decade or two that > aren't affected by speculative execution vulnerabilities? There are some, such as the ARM-based Allwinner A64 used in in the pinebook and pinephone. Probably various processors targeted at the mobile market as well. live well, vagrant signature.asc Description: PGP signature
Re: Hardened toolchain
Aurora writes: > Katherine Cox-Buday writes: > >> Everyone has different threat models and needs. A lot of computers >> have CPU speculative execution attack mitigation disabled because >> those types of attacks will never affect those computers, and it >> reduces the performance of the CPU a lot. > > There are multicore processors made in the last decade or two that > aren't affected by speculative execution vulnerabilities? They are vulnerable to them, but not necessarily affected by them. Consider a computer not networked to the internet and only running trusted workloads (e.g. scientific HPC, etc.). This is why acknowledging that everyone has a different threat model is important. I hope this helps to clarify. Sincerely, -- Katherine
Re: Hardened toolchain
Katherine Cox-Buday writes: > Everyone has different threat models and needs. A lot of computers have CPU > speculative execution attack mitigation disabled because those types of > attacks will never affect those computers, and it reduces the performance of > the CPU a lot. There are multicore processors made in the last decade or two that aren't affected by speculative execution vulnerabilities?
Re: The case for moving raw binaries
Am Donnerstag, dem 28.04.2022 um 18:55 +0200 schrieb Maxime Devos: > Liliana Marie Prikler schreef op do 28-04-2022 om 18:37 [+0200]: > > the shell by typing a dot and using tab completion. What's more, > > in some build systems there might be two (or even more) off them. > > This makes a generic wrap after wrap pattern almost impossible to > > achieve. > > > > So, what's the fix? I propose moving rawbins to a different > > location. libexec would spring to mind as a place in which we > > could hide them, so > > How does this help with double wrapping? Whether the wrappers / > originals are put in /bin or $RAWBIN_DIR, it's still wrapped twice. Because $RAWBIN_DIR can be ignored when wrapping. This means that stuff that's already in it won't be added again. > Also, FWIW, double-wrapping works nicely for 'wrap-program' -- it > just appende or prepended some extra X=Y lines. With some work and > test cases, 'wrap-script' could be extended to support such a thing > as well. Constructing the wrapper is not so much the problem, it's not wrapping the already wrapped binaries. Plus the .-real binaries showing up in $PATH remains an issue if they don't move :)
Re: The case for moving raw binaries
Liliana Marie Prikler schreef op do 28-04-2022 om 18:37 [+0200]: > the shell by typing a dot and using tab completion. What's more, in > some build systems there might be two (or even more) off them. This > makes a generic wrap after wrap pattern almost impossible to achieve. > > So, what's the fix? I propose moving rawbins to a different location. > libexec would spring to mind as a place in which we could hide them, so How does this help with double wrapping? Whether the wrappers / originals are put in /bin or $RAWBIN_DIR, it's still wrapped twice. Also, FWIW, double-wrapping works nicely for 'wrap-program' -- it just appende or prepended some extra X=Y lines. With some work and test cases, 'wrap-script' could be extended to support such a thing as well. Greetings, Maxime. signature.asc Description: This is a digitally signed message part
Re: The case for moving raw binaries
Liliana Marie Prikler schreef op do 28-04-2022 om 18:37 [+0200]: > So, what do you think? Any candidates for $RAWBIN_DIR that we can > bikeshed? Any disagreements? /gnu/HASH-.../unwrapped-bin. Benefit above /gnu/HASH- .../libexec/SOMETHING/bin: the 'dirname' of $0 points to PREXIX, like for binaries in .../bin, whereas for libexec, the dirname points to a subdirectory of PREFIX, which some applications might not expect. Greetings, Maxime. signature.asc Description: This is a digitally signed message part
The case for moving raw binaries
Hi Guix, "raw binaries" (henceforth rawbins) are the unwrapped binaries that Guix leaves behind in $PACKAGE/bin with the .$WRAPPER-real name. This practise causes several issues. For one, those rawbins are visible in the shell by typing a dot and using tab completion. What's more, in some build systems there might be two (or even more) off them. This makes a generic wrap after wrap pattern almost impossible to achieve. So, what's the fix? I propose moving rawbins to a different location. libexec would spring to mind as a place in which we could hide them, so would a new directory in the root of $PACKAGE. Other than that, adding a rawbin output would also be possible, but I am not certain whether that'd be the right tradeoff. So, what do you think? Any candidates for $RAWBIN_DIR that we can bikeshed? Any disagreements? Cheers
Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues
Hi John John Soo writes: > Hi Gio! > > I am very sorry I have let it slip. Nothing to apologise for, you are doing your best: I did not mean to put pressure on you! > If there are patches I need to get to, I can put them in to > emacs-guix. I believe we should get the savannah version up to snuff > and use that as the one in guix. IMHO it's not "just" the two repos, but also the web page, MELPA and the issue tracking systems that we need to keep togheter [...] Thank you and Happy Hacking! Gio' -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues
Hi Ludovic: Ludovic Courtès writes: > Hi Giovanni, > > Giovanni Biscuolo skribis: > >> AFAIU since 2021-01-11 [1] the new official home of emacs-guix is on >> Savannah as a Guix sub-project [2]; Alex Kost agreed [3] and told us >> that: >> >> >> As for me, I will continue to use my version of Emacs-Guix and to adjust >> it for my needs. >> >> >> and that's what he is doing (see below), so now "officially" we have >> /two/ packages named emacs-guix: the official one at Savannah and the >> "personal" one maintained by Alex. > > I’m not sure what “personal” means in this case. Just my personal interpretation of the words "my version" and "for my needs" from Alex :-D... after all Alex's version is now the Guix "official" one (the one we are packaging) > Anyway, the situation is confusing; there’s no point in having two > slightly different variants. I suggest we check with Alex off-list to > get a better understanding of what they want. I agree, thank you for your off-list message, let's wait Alex reply. > Worst case, we can cherry-pick commits from Alex’s copy if Alex > doesn’t want to be involved in discussions around Emacs-Guix or Guix > development. In this worst case, we'll have two different emacs-guix packages, documentation, issue tracking: the situation will continue to be confusing, one of the two emacs-guix "ecosystems" (repo, web page, issue tracking) should be discontinued (or renamed?), IMHO, hopefully with both Alex and John as co-maintainers in one emacs-guix. > Thanks for the heads-up! Thank you all for your work! Gio' -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Errors with (display) when building derivations from the REPL.
I’m trying to do some work on Guix with Emacs and Geiser, and while a lot of things work fairly well, I consistently run into problems when trying to build derivations from the Geiser REPL. From what I can tell by looking at where it’s breaking, it seems to me like the output of the build process is supposed to be captured for display by the client, but (for whatever reason) the output port its supposed to go to is closed. The failing line appears to be these (found in guix/store.scm:758): --8<---cut here---start->8--- (let ((s (read-maybe-utf8-string p))) (display s (current-build-output-port)) --8<---cut here---end--->8--- I don’t know if this is an actual bug, or if I’m expected to set up the output port myself before attempting to do a build from the REPL. If it is an actual bug, I’ll be happy to submit this to the issue tracker. If it’s not, can someone tell me what I’m supposed to be doing for this to work? Also, is there a reason that the build’s output port doesn’t just default to standard output so no setup would be necessary? Sample code: --8<---cut here---start->8--- (define-module (bjc repltest) #:use-module (guix derivations) #:use-module (guix gexp) #:use-module (guix monads) #:use-module (guix store)) (define (m) (with-store store (run-with-store store (mlet %store-monad ((drv (lower-object (computed-file "test" #~(mkdir #$output) (mbegin %store-monad (built-derivations (list drv))) --8<---cut here---end--->8--- Backtrace: --8<---cut here---start->8--- scheme@(bjc repltest)> (m) ice-9/boot-9.scm:1685:16: In procedure raise-exception: In procedure display: Wrong type argument in position 2: #string 7f38350291c0> Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. scheme@(bjc repltest) [1]> ,bt In ice-9/boot-9.scm: 1752:10 8 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _) In guix/store.scm: 658:37 7 (thunk) In guix/monads.scm: 560:2 6 (run-with-store # 7f382193fb90> _ #:guile-for-build _ #:system _ #:target _) In guix/store.scm: 2001:38 5 (_ #) 1421:15 4 (_ # _ _) 759:14 3 (process-stderr _ _) In unknown file: 2 (display "substitute: \r" # 7f38350291c0>) In ice-9/boot-9.scm: 1685:16 1 (raise-exception _ #:continuable? _) 1685:16 0 (raise-exception _ #:continuable? _) --8<---cut here---end--->8--- -bjc
Re: PipeWire as a PulseAudio replacement (was Re: The Shepherd on Fibers)
Hello Tanguy, Tanguy LE CARROUR writes: > I recently switched from Xorg to Wayland and I'm quite happy with my new > setup! The only last "little" thing that doesn't work for me is > screen-sharing using Icecat and/or Chromium!? :-( I know that at least for icecat, it needs to dlopen pipewire for screen-sharing to work, but for now it isn't included in the icecat package. In the meantime, i've been using the command line `LD_LIBRARY_PATH="$(guix build pipewire)/lib" icecat` to get screensharing working in icecat. Also, you say you've set the env variables, but you need to set them for dbus: that means running `update-dbus-activation-environment WAYLAND_DISPLAY`, is that what you ended up doing? HTH, -- Josselin Poiret
Re: PipeWire as a PulseAudio replacement (was Re: The Shepherd on Fibers)
Hi Josselin, hi Brendan, hi Guix, Quoting Josselin Poiret (2022-03-29 15:22:35) > Brendan Tildesley writes: > > Which environment variables are you talking about? I'm running pipewire on > > Guix System > > and it seems to work fine. > > Right, I think I conflated too many different things, basically my > use-case was making screensharing work on wlroots-based compositors, but > the service that need these env variables (at least WAYLAND_DISPLAY I > think) is xdg-desktop-portal-wlr. WirePlumber and PipeWire should be > fine by themselves, since they're started by the session D-Bus and thus > should have access to it, and shouldn't need anything else. I recently switched from Xorg to Wayland and I'm quite happy with my new setup! The only last "little" thing that doesn't work for me is screen-sharing using Icecat and/or Chromium!? :-( And, I won't go back to Xorg "just" for that! ^_^' I would be grateful if someone could tell me how to set up the PipeWire thingy!? I've installed `pipewire`, `xdg-desktop-portal-wlr`, and `wireplumber`… set up the ENV variables `WAYLAND_DISPLAY` and `XDG_CURRENT_DESKTOP`… set the proper flag in Chromium… but it doesn't seem to work!? I thought it would be dbus "auto-magic", but apparently not. Event if I manually start `pipewire` and `wireplumber`, nothing happens when I try to share my screen, for instance while in a Jitsi Meet meeting. Any advice welcome! … even a good old RTFM, if it comes with a link to get the information from! :-) Regards, -- Tanguy
Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues
Hi Giovanni, Giovanni Biscuolo skribis: > AFAIU since 2021-01-11 [1] the new official home of emacs-guix is on > Savannah as a Guix sub-project [2]; Alex Kost agreed [3] and told us > that: > > > As for me, I will continue to use my version of Emacs-Guix and to adjust > it for my needs. > > > and that's what he is doing (see below), so now "officially" we have > /two/ packages named emacs-guix: the official one at Savannah and the > "personal" one maintained by Alex. I’m not sure what “personal” means in this case. Anyway, the situation is confusing; there’s no point in having two slightly different variants. I suggest we check with Alex off-list to get a better understanding of what they want. Worst case, we can cherry-pick commits from Alex’s copy if Alex doesn’t want to be involved in discussions around Emacs-Guix or Guix development. Thanks for the heads-up! Ludo’.
Re: antioxidant update: sniffglue builds
Hi! Maxime Devos skribis: > Status update about antioxidant-build-system: > > * sniffglue now builds (hexyl still builds) > * [[bins]] sections are recognised > * phases have been split for tidyness > * more environment variables expected by some build.rs are now set > * 'autobins' is respected > * some build failures involving C libraries (‘native libraries’, in > Rust terminology) are resolved, > * more structured parsing of Cargo.toml, using define-json-mapping > * some version incompatibilities resolved > * other things? > > Next step: try building other packages from (gnu packages rust-apps). Yay, that sounds promising! Looking forward to the next update… thank you! Ludo’.
Re: Viewing derivation output in the store
Hi! Josselin Poiret skribis: > As an aside: is there anything preventing us from having do notation à > la Haskell? This could help bridge mlet and mbegin with >>=, which in > its current form is impractical. Here's what it could look like: > > (mdo %store-monad > (drv <- (gexp-derivation "myderivation" test-gexp)) > (output <- (return (derivation->output-path drv))) > (built-derivations (list drv)) > (return (format #t "~a~%" output))) I guess we could do that, though it seems to me like a marginal improvement over ‘mbegin’ and ‘mlet’. Ludo’.
Re: Finding a “good” OpenPGP key server
Hi, Tanguy LE CARROUR skribis: > Actually, Nikita answered this question on a thread on GNUnet's mailing list: > > https://lists.gnu.org/archive/html/gnunet-developers/2022-04/msg00030.html > > The end of the discussion is off list. The key used to > sign the package is deprecated and not to be used any more/any where. Hmm, so how’s one supposed to authenticate it? > The proper solution should come from GNUnet, but maybe, we could bypass > the key verification in Guix. Or, I could clone the repo, claim > ownership and sign a new package myself. But that doesn't look like a > good/fair solution to me! Thoughts?! Sure, if you can update to what you think is genuinely the latest version, please go ahead. Thanks, Ludo’.
