a vector of colors
Hi,
Why was this defined as a vector instead of a list?
(define %colors
;; See colortbl.h in Graphviz.
#("red" "magenta" "blue" "cyan3" "darkseagreen"
"peachpuff4" "darkviolet" "dimgrey" "darkgoldenrod"))
Re: Renaming ‘master’ to ‘main’
Hi, On Tue, Aug 9, 2022 at 1:57 PM Ludovic Courtès wrote: > > Yes, this is something we should do. For what it's worth, I now use 'history' for primary development branches when possible. For me, it establishes a preeminence among branches by function rather than name. Plus, I like writing "It was merged into 'history'." Kind regards Felix Lechner
Re: Renaming ‘master’ to ‘main’
Hi, On Tue, Aug 9, 2022 at 1:57 PM Ludovic Courtès wrote: > > Yes, this is something we should do. For what it's worth, I now use 'history' for primary development branches when possible. To me, it establishes a preeminence among branches by function rather than name. Plus, I like writing "It was merged into 'history'." Kind regards Felix Lechner
Re: Enterprise Guix Hosting?
Let's do this! My partners and I are fired up about the idea and we would like this to be developed, along the way we continue to serve customers (or co-creators, in our worker coop world). Realistic, step by step implementation, niche to niche, until we make it big! -Yasu > On Aug 10, 2022, at 05:37, Ludovic Courtès wrote: > > Hi Phil, > > Phil skribis: > >> My own experience is that whilst it doesn't require a PhD to setup Guix >> for the enterprise, it is a non-trivial journey, and it does require >> a fair amount of time and effort to create something that regular >> developers/scientists (i.e. non-Guix converts who just want to get on with >> their >> day-jobs) accept is as good or better than regular tooling they are used >> to. There's certainly a barrier to entry for people who don't want to >> do a deep-dive and just want tooling to support them in their professional >> role, without them having to think about it too much. >> >> Upselling the real benefits of Guix like rollbacks, profiles, perfectly >> reproducable builds, swapping one dependency for another - even in a >> scientific/tech-savvy company with lots of PhDs took a bit of persuading >> from me. Even now I think our company is only using perhaps 30% of the >> true power of Guix. Making all that power accessible to people who just >> want to get on with their jobs in an easy, intuitive way is a challenge >> I'm continuously trying to address. I also hope things like PantherX >> might help bridge the gap in the near future! > > From your experience, would you say that persuading was hard primarily > because Guix was unknown (to them), or because getting started is > difficult? > > Personally I think we need to make Guix approachable to a wide audience, > meaning not just developers—that goes beyond your target audience, let’s > be ambitious! I’d like to think that ‘guix install’, ‘guix shell’, and > the likes have a rather low barrier to entry to someone who’s use the > command line before, but I’ve also seen newcomers confused because > “environment variables are hard” and get in the way. > > Are there any takeaways from your experience in terms of UX/UI > improvements we could work on? > > Thanks, > Ludo’.
Re: managing waiting patches
On 2022-08-09 22:54, Ludovic Courtès wrote: > This was discussed recently on guix-devel and I hope we can collectively > improve on that. The new teams that we devised (see ‘etc/teams.scm’) > should help, though we have yet to document them and publicize them. Thanks for your answer, I'll check that. > I don’t have any great suggestion here—you already seem to be doing > things rationally. In general, short, to-the-point patch series are > more likely to be reviewed quickly, so that’s one strategy you can adopt > here. And then you can locally keep branches for each part of the > broader patch series, possibly rebasing them until they’re applied. I finally went for the branching strategy, hence my patch frenzy trying to sort everything I wrote in well-ordered branches in one repo. Takes some time but I'll close to that. > You could send an updated patch series with the new version as v2; that > would also serve as a reminder for reviewers. > > Using ./etc/teams.scm you can also look for people working in this area > that you could ping. > > Last, if you’re on IRC, you’re welcome to occasionally ping people > there. Thanks for the advice. Not an IRC user for now, maybe I will come someday. Is there a requirement to help with patch reviewing? I feel I can tackle python or rust packages unless they are weird, I need not to spend too much time on that, but if it's just advising new beginners (I'm myself a 9 month old Guix user but went cold turkey on my main machine, while my first patches were a nightmare, now I hope/believe they are quite clean) or trying to patch and build locally for <1h a day, with proper guidelines I might be able to help here. -- Best regards, Nicolas Graves
GIO_EXTRA_MODULES breaking foreign-distro programs
Hi, I've encountered an issue with GIO_EXTRA_MODULES from my Guix profile preventing binaries from my foreign distro (Kubuntu 22.04) from running. The initial symptom was that running e.g. `/usr/bin/flatpak list` would terminate with the error: > /usr/bin/flatpak: symbol lookup error: > /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libpthread.so.0: > undefined symbol: __libc_pthread_init, version GLIBC_PRIVATE I've attached the output of running it with LD_DEBUG=libs, which seems to show that the it first fell into Guix's libraries via /home/philip/.guix-home/ profile/lib/gio/modules/libgiognomeproxy.so. I confirmed that `unset GIO_EXTRA_MODULES` fixes the problem. I plan to track down whatever package added GIO_EXTRA_MODULES to my profile and remove it for now, but that seems like a pretty drastic workaround. Is this a known issue? Is there a better way to deal with it, either from my side or within Guix? -Philip 1548077: find library=libappstream-glib.so.8 [0]; searching 1548077: search cache=/etc/ld.so.cache 1548077: trying file=/lib/x86_64-linux-gnu/libappstream-glib.so.8 1548077: 1548077: find library=libarchive.so.13 [0]; searching 1548077: search cache=/etc/ld.so.cache 1548077: trying file=/lib/x86_64-linux-gnu/libarchive.so.13 1548077: 1548077: find library=libzstd.so.1 [0]; searching 1548077: search cache=/etc/ld.so.cache 1548077: trying file=/lib/x86_64-linux-gnu/libzstd.so.1 1548077: 1548077: find library=libdconf.so.1 [0]; searching 1548077: search cache=/etc/ld.so.cache 1548077: trying file=/lib/x86_64-linux-gnu/libdconf.so.1 1548077: 1548077: find library=libjson-glib-1.0.so.0 [0]; searching 1548077: search cache=/etc/ld.so.cache 1548077: trying file=/lib/x86_64-linux-gnu/libjson-glib-1.0.so.0 1548077: 1548077: find library=libseccomp.so.2 [0]; searching 1548077: search cache=/etc/ld.so.cache 1548077: trying file=/lib/x86_64-linux-gnu/libseccomp.so.2 1548077: 1548077: find library=libmalcontent-0.so.0 [0]; searching 1548077: search cache=/etc/ld.so.cache 1548077: trying file=/lib/x86_64-linux-gnu/libmalcontent-0.so.0 1548077: 1548077: find library=libostree-1.so.1 [0]; searching 1548077: search cache=/etc/ld.so.cache 1548077: trying file=/lib/x86_64-linux-gnu/libostree-1.so.1 1548077: 1548077: find library=libpolkit-agent-1.so.0 [0]; searching 1548077: search cache=/etc/ld.so.cache 1548077: trying file=/lib/x86_64-linux-gnu/libpolkit-agent-1.so.0 1548077: 1548077: find library=libpolkit-gobject-1.so.0 [0]; searching 1548077: search cache=/etc/ld.so.cache 1548077: trying file=/lib/x86_64-linux-gnu/libpolkit-gobject-1.so.0 1548077: 1548077: find library=libsoup-2.4.so.1 [0]; searching 1548077: search cache=/etc/ld.so.cache 1548077: trying file=/lib/x86_64-linux-gnu/libsoup-2.4.so.1 1548077: 1548077: find library=libsystemd.so.0 [0]; searching 1548077: search cache=/etc/ld.so.cache 1548077: trying file=/lib/x86_64-linux-gnu/libsystemd.so.0 1548077: 1548077: find library=libXau.so.6 [0]; searching 1548077: search cache=/etc/ld.so.cache 1548077: trying file=/lib/x86_64-linux-gnu/libXau.so.6 1548077: 1548077: find library=libxml2.so.2 [0]; searching 1548077: search cache=/etc/ld.so.cache 1548077: trying file=/lib/x86_64-linux-gnu/libxml2.so.2 1548077: 1548077: find library=libgio-2.0.so.0 [0]; searching 1548077: search cache=/etc/ld.so.cache 1548077: trying file=/lib/x86_64-linux-gnu/libgio-2.0.so.0 1548077: 1548077: find library=libgobject-2.0.so.0 [0]; searching 1548077: search cache=/etc/ld.so.cache 1548077: trying file=/lib/x86_64-linux-gnu/libgobject-2.0.so.0 1548077: 1548077: find library=libglib-2.0.so.0 [0]; searching 1548077: search cache=/etc/ld.so.cache 1548077: trying file=/lib/x86_64-linux-gnu/libglib-2.0.so.0 1548077: 1548077: find library=libc.so.6 [0]; searching 1548077: search cache=/etc/ld.so.cache 1548077: trying file=/lib/x86_64-linux-gnu/libc.so.6 1548077: 1548077: find library=libgdk_pixbuf-2.0.so.0 [0]; searching 1548077: search cache=/etc/ld.so.cache 1548077: trying file=/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 1548077: 1548077: find library=libuuid.so.1 [0]; searching 1548077: search cache=/etc/ld.so.cache 1548077: trying file=/lib/x86_64-linux-gnu/libuuid.so.1 1548077: 1548077: find library=libyaml-0.so.2 [0]; searching 1548077: search cache=/etc/ld.so.cache 1548077: trying file=/lib/x86_64-linux-gnu/libyaml-0.so.2 1548077: 1548077: find library=libstemmer.so.0d [0]; searching 1548077: search cache=/etc/ld.so.cache 1548077: trying file=/lib/x86_64-linux-gnu/libstemmer.so.0d 1548077: 1548077: find library=libnettle.so.8 [0]; searching 1548077: search cache=/etc/ld.so.cache 1548077:
Renaming ‘master’ to ‘main’
Vagrant Cascadian skribis: > On 2022-08-06, Tobias Geerinckx-Rice wrote: >> On 2022-08-06 20:48, Tobias Geerinckx-Rice wrote: >>> guix pull: error: commit 39465409f0481f27d252ce25d2b02d3f5cbc6723 >>> not signed by an authorized key: >>> 2841 9AC6 5038 7440 C7E9 2FFA 2208 D209 58C1 DEB0 >> >> I tried a few other random things to wriggle out of this but I think >> we're stuck (which is, design-wise, probably a good thing). > > What a great opportunity to switch to using "main" instead of "master" > anyways. :) Yes, this is something we should do. There’s preliminary work here: https://issues.guix.gnu.org/49252 I eventually lost track of what the problem was, but we should resume. Ludo’.
Re: managing waiting patches
Hello Nicolas, Thanks for your message. Patch review is overall rather slow due to a mixture of Guix being a victim of its success and (perhaps more importantly) having too few people devoting time to patch review, and too few committers committing. This was discussed recently on guix-devel and I hope we can collectively improve on that. The new teams that we devised (see ‘etc/teams.scm’) should help, though we have yet to document them and publicize them. Nicolas Graves via skribis: > 1) how to manage and track series of patches one makes in his local repo > copy. > > For that, I will take a practical example. > > I made some rust patches a few days ago. The final goal of these first > patches would have been to add the package swayr@0.20, which is huge > when imported with recursive guix import (~2k lines). So I did split the > task in a few subgoals, by trying to first update packages that are > already present. By only doing that, I already had a stack of ~15 > commits. I couldn't contribute more at that moment, so I sent them in > the hope that they would get merged before a next partial goal. I don’t have any great suggestion here—you already seem to be doing things rationally. In general, short, to-the-point patch series are more likely to be reviewed quickly, so that’s one strategy you can adopt here. And then you can locally keep branches for each part of the broader patch series, possibly rebasing them until they’re applied. > 2) how to get one's patches to pass. > > Another problematic I encounter is having to wait for a patch series to > pass to send another one. Another example. > > I'm developing in my free time for an organisation using wagtail CMS for > its website. I thought that it would be a great occasion to send some > packages for guix, and get some experience with packaging. So I worked > on that and send some patches (55476 55475 55474 55473). They are pretty > clean (almost all tests enabled, tested as a user) (except maybe for > descriptions, I'm not sure I remember for that). > > At some point, wagtail made an upgrade to version 3.0.1, and I started > to update my packages locally, but don't want to make a totally new > series of patches while the previous was not accepted. In the meantime, > I send patches 56296 which would have been useful for later and actually > fixes some failing packages. I'm now stuck on this contributing task > because of this. I can sympathize. :-/ You could send an updated patch series with the new version as v2; that would also serve as a reminder for reviewers. Using ./etc/teams.scm you can also look for people working in this area that you could ping. Last, if you’re on IRC, you’re welcome to occasionally ping people there. [...] > What should I do in this case? Should I try to become a committer > myself? Have a "committer buddy" that can merge my sent packages? Keep > working in a personal channel or a channel like guixrus and rely on that > additionally to relying on guix? Other options? > > Thanks a lot for your answer, sorry if I don't have very acute developer > workflows, I'm only doing this in my free time ;) Understood! You can always keep your work in a channel of yours until it’s merged. I do encourage you to work to get it in Guix proper though, because in the end everyone benefits. I hope we can all work to reduce the bottleneck. Thanks, Ludo’.
Re: Enterprise Guix Hosting?
Hi Phil, Phil skribis: > My own experience is that whilst it doesn't require a PhD to setup Guix > for the enterprise, it is a non-trivial journey, and it does require > a fair amount of time and effort to create something that regular > developers/scientists (i.e. non-Guix converts who just want to get on with > their > day-jobs) accept is as good or better than regular tooling they are used > to. There's certainly a barrier to entry for people who don't want to > do a deep-dive and just want tooling to support them in their professional > role, without them having to think about it too much. > > Upselling the real benefits of Guix like rollbacks, profiles, perfectly > reproducable builds, swapping one dependency for another - even in a > scientific/tech-savvy company with lots of PhDs took a bit of persuading > from me. Even now I think our company is only using perhaps 30% of the > true power of Guix. Making all that power accessible to people who just > want to get on with their jobs in an easy, intuitive way is a challenge > I'm continuously trying to address. I also hope things like PantherX > might help bridge the gap in the near future! >From your experience, would you say that persuading was hard primarily because Guix was unknown (to them), or because getting started is difficult? Personally I think we need to make Guix approachable to a wide audience, meaning not just developers—that goes beyond your target audience, let’s be ambitious! I’d like to think that ‘guix install’, ‘guix shell’, and the likes have a rather low barrier to entry to someone who’s use the command line before, but I’ve also seen newcomers confused because “environment variables are hard” and get in the way. Are there any takeaways from your experience in terms of UX/UI improvements we could work on? Thanks, Ludo’.
Re: partial guix pack?
Hi, Andy Tai skribis: > Can a guix pack be partial? By that I meant one package that is not > completely stand alone but only contains a subset of needed software, > bundled libraries. for example, one that bundles specific version of > gtk+ but not glibc? Of course such a package depends on host glibc > and may have the risk of breakage but it is likely low risk if the > main problem is it needs specific version of gtk+. Currently there’s no way to do that. We could implement a feature that removes certain store items from the pack, say glibc. But then, all the binaries in the pack have Guix’s glibc in their RUNPATH and executables have its loader as an ELF interpreter. So that process would need to rewrite RUNPATHs and INTERPs to those commonly found on FHS distros… not impossible, but a bit tedious just to end up with binaries that may or may not work. Ludo’.
Re: uninstall/unmanage guix home on my foreign system
Hi jgart, jgart skribis: > How can I "uninstall" guix home or have it not manage my dotfiles or a > particular subset of dotfiles that I no longer want managed? Good question; I don’t think there’s an easy way to escape, it’s a bit of a trap. :-) What I would do is something like this (untested): 1. Make sure packages you need are installed on the system or in ~/.guix-profile, by running, say: guix package --export-manifest -p ~/.guix-home/profile/manifest > \ ~/my-manifest.scm guix package -m ~/my-manifest.scm 2. Restore dot files that were managed by Guix Home, for example by copying your original dot files from a backup such as the one created by ‘guix home reconfigure’: for i in .bashrc .bash_profile # add others here do rm "$HOME/$i" cp -v "$HOME/guix-home-backup-whatever-its-called/$i" "$HOME" fi 3. Remove your home profile: rm -v ~/.guix-home /var/guix/profiles/per-user/$USER/guix-home* IWBN to have a ‘guix home’ subcommand to do that automatically. HTH! Ludo’.
Re: Garbage Collector
Hi, Felix Lechner via skribis: > On Mon, Jul 25, 2022 at 2:52 AM Gottfried wrote: >> >> The manual says that it is dangerous to use: "guix gc" >> because it can delete too much. > > I agree that 'guix gc' deletes too much, but it's probably not > dangerous. You will just see some downloads and builds repeated when > reconfiguring later. Indeed, it’s not dangerous, and I don’t think the manual suggests that. To avoid collecting things just to redownload/rebuild them later, I usually ask ‘guix gc’ to free up some amount of space, as in: guix gc -F20G That ensures 20G (more or less) are available on my disk and doesn’t try to collect more than that. Thanks, Ludo’.
Re: Debugging cross-compilation dependencies
Hello! "Philip McGrath" skribis: > Much to my surprise, I discovered I can avoid the problem by changing code > for #:make-flags like this: > > ``` > #~(string-append "ZUO=" > #$(this-package-native-input "zuo") > "/bin/zuo")) > ``` You should prolly use ‘ungexp-native’ (aka. #+) instead of ‘ungexp’ (#$). #~(string-append … #+(this-package-native-input "zuo") …) HTH! Ludo’.
Re: Debugging cross-compilation dependencies
Hello! "Philip McGrath" skribis: > Much to my surprise, I discovered I can avoid the problem by changing code > for #:make-flags like this: > > ``` > #~(string-append "ZUO=" > #$(this-package-native-input "zuo") > "/bin/zuo")) > ``` You should prolly use ‘ungexp-native’ (aka. #+) instead of ‘ungexp’ (#$). #~(string-append … #+(this-package-native-input "zuo") …) HTH! Ludo’.
