Re: Document /homeless-shelter?
On Sat, Jan 15, 2022 at 10:19:54PM -0500, Matt wrote: > As I understand it, $HOME is set to /homeless-shelter during build because > that's how Nix does/did it and "there’s no home > directory in build environments, and perhaps Eelco Dolstra and others back > then found that setting ‘HOME’ to a non-existing directory broke > fewer builds that leaving it unset." A further rationale is that by using an obviously strange and bogus value for $HOME, all uses of $HOME in the build container are highlighted. Otherwise, if $HOME was unset, build scripts might fall back to something like $HOME/$USER. To be clear, the situation is not simply that "there's no home directory in the build environment". Rather, there must not be a home directory there. By design, that's a small part of how we ensure that builds are deterministic. In all cases, package builds should not be able to depend on the pathname of a home directory. > Is this something that should be documented, and if so, where? It could be documented briefly in the manual section Build Environment Setup.
Proposal: Separate the guix repo
Currently it's taking me 1~4 hours (depending on the system without outsourcing the load on high performance system) to build the guix repository in order to be able to test the contribution and contribute as such i am proposing to take an inspiration from Exherbo Linux and separate the repositories, see https://gitlab.exherbo.org/exherbo I believe that this approach has multiple advantages: 1. Significantly lower resource requirements to make a contribution 2. Better management as issue tracking can be done per repository and enable developers who are comfortable in specified programming language to focus on contributions there 3. It saves resources for automation as language and workflow specific automation can have more specific trigger thus saving processing resources. 4. Cleaner git history 5. Faster system deployment as the user can specify that they don't need e.g. engineering packages on their system 6. Much cleaner code as the packages would be separat ed to be less overwhelming (to reduce the files with thousands lines) -- Jacob Hrbek publickey - kreyren@rixotstudio.cz - 1677db82.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Document /homeless-shelter?
In the IRC, someone asked about an error message: PermissionError: [Errno 13] Permission denied: '/homeless-shelter' This error happened when trying to build a Python package, python-libpysal. The solution was to set HOME to /tmp: (arguments `(#:phases (modify-phases %standard-phases (add-before 'check 'fix-home-directory (lambda _ ;; Tests fail with "Permission denied: '/homeless-shelter'". (setenv "HOME" "/tmp" Basically, some projects expect a $HOME to be defined and will fail because Guix sets $HOME to /homeless-shelter, which doesn't exist in the build environment. As I understand it, $HOME is set to /homeless-shelter during build because that's how Nix does/did it and "there’s no home directory in build environments, and perhaps Eelco Dolstra and others back then found that setting ‘HOME’ to a non-existing directory broke fewer builds that leaving it unset." Is my understanding correct? Is this something that should be documented, and if so, where? IRC log: https://logs.guix.gnu.org/guix/2022-01-16.log#003312 Previous Guix discussion: https://lists.gnu.org/archive/html/guix-devel/2019-11/msg00311.html
Re: Guix Documentation Meetup This Saturday (January 15)
On Tue, 11 Jan 2022 11:29:44 -0500 jgart wrote: > On Tue, 11 Jan 2022 17:23:38 +0100 Oliver Propst > wrote: > > On 2022-01-11 17:01, jgart wrote: > > > Hi Guixers, > > > > Hi Jgart thanks for the *note. > > > > *will try to attend the meeting. > > Hi Oliver, > > Cool, hope to see you there! > > all best, > > jgart > Hi Guixers, We had a great turn out and insightful discussions about contibuting to and documenting Guix. Here are the notes and chat log the people added to BBB from today's Guix Documentation Meetup: https://paste.sr.ht/~whereiseveryone/69bad7722fad84edb1d6bed1f2c95b6e138f8154 https://paste.sr.ht/~whereiseveryone/11142d27dbe26732a8f5745e918ead9014b848f6 Our patch to upstream: https://issues.guix.gnu.org/53287 Hope to catch you on the next one! all best, jgart
Re: Release v1.4 (or 2.0): process and schedule ?
On 2021-12-26, Maxim Cournoyer wrote: > Vagrant Cascadian writes: >> On 2021-12-19, Maxim Cournoyer wrote: >>> zimoun writes: Now core-updates-frozen is merged. Now The Big Change [1 ]is done. Do we go for v1.4 or v2.0? ... >> Would it be appropriate to fix the ~700 low-hanbging fruit issues that >> are identified by: >> >> guix lint --checkers=description,synopsis >> >> It is not the most exciting work technically, but it is relatively easy, >> and low risk, maybe the worst it does is put a bit more work on >> translators... >> >> Maybe there are also other low hanging fruit guix lint knows about that >> would not be particularly disruptive? >> >> It is not particularly urgent for a release, per se, but I suspect it >> will just grow and grow without some sort of cycle to address such >> trivial issues... and doing such cleanup before making a release would >> aim for a higher standard of craftspersonship. :) > > About the current status, I'm nearing on pushing a version-1.4.0 branch > which is based on master with a few more (core-ish) updates. There's > still a few days ahead of that, so if you manage to get many of this > kind of problems fixed & merged in master they can easily be included in > the next release. I managed to get ~150 fixes in before version-1.4.0 was merged... Wondering if it would be possible to also merge or cherry-pick: 757a7978dd3de98d5bb033d27fd5a613038b4dc5 gnu: trytond-*: Fix grammar. 3c43f2b4f54dead73ce19427eb1e364581b7f2e0 gnu: julia-bioalignments: Fix spelling. That would fix a few more of these sorts of issues, and only affects synopsis and description strings in small ways. live well, vagrant signature.asc Description: PGP signature
GNU Shepherd config contribution
Hello! I would like to contribute examples of Shepherd services, by
sending my Shepherd system configuration file that I use. Attached is
the configuration file.
I hope this will help add more detailed examples to the GNU Shepherd manual.
;; init.scm -- default shepherd configuration file.
;; Services known to shepherd:
;; Add new services (defined using 'make ') to shepherd here by
;; providing them as arguments to 'register-services'.
(register-services
(make
#:provides '(getty@tty2)
#:requires '()
#:docstring "The getty@tty2 service provides a getty on tty2."
#:start (make-forkexec-constructor '("/usr/local/etc/init.d/getty@tty2"))
#:stop (make-kill-destructor)
#:respawn? #t)
(make
#:provides '(cron)
#:requires '()
#:docstring "The cron service provides execution of regularly scheduled commands."
#:start (make-forkexec-constructor '("cron" "-f"))
#:stop (make-kill-destructor)
#:respawn? #t)
(make
#:provides '(accounts-daemon)
#:requires '(dbus)
#:docstring "The accounts-daemon provides the Accounts Service."
#:start (make-forkexec-constructor '("/usr/lib/accountsservice/accounts-daemon")
#:environment-variables (append (environ) '("GVFS_DISABLE_FUSE=1" "GIO_USE_VFS=local" "GVFS_REMOTE_VOLUME_MONITOR_IGNORE=1")))
#:stop (make-kill-destructor)
#:respawn? #t)
(make
#:provides '(apparmor)
#:requires '()
#:docstring "Loads AppArmor profiles."
#:start (make-forkexec-constructor '("/lib/apparmor/apparmor.systemd" "reload"))
#:stop (make-kill-destructor)
#:oneshot? #t)
(make
#:provides '(avahi-daemon)
#:requires '(dbus)
#:docstring "The avahi-daemon provides the Avahi mDNS/DNS-SD Stack."
#:start (make-forkexec-constructor '("avahi-daemon" "-s"))
#:stop (make-kill-destructor)
#:respawn? #t)
(make
#:provides '(binfmt-support)
#:requires '()
#:docstring "Enables support for additional executable binary formats."
#:start (make-forkexec-constructor '("update-binfmts" "--enable"))
#:stop (make-system-destructor "update-binfmts --disable")
#:oneshot? #t)
(make
#:provides '(casper)
#:requires '()
#:docstring "Shuts down the 'live' preinstalled system cleanly."
#:start (make-forkexec-constructor '("casper-stop"))
#:stop (make-kill-destructor)
#:oneshot? #t)
(make
#:provides '(colord)
#:requires '(dbus)
#:docstring "The colord service is used to manage, install generate Colour Profiles."
#:start (make-forkexec-constructor '("/usr/libexec/colord") #:user "colord")
#:stop (make-kill-destructor)
#:respawn? #t)
(make
#:provides '(console-setup)
#:requires '()
#:docstring "Sets the system console font and keymap."
#:start (make-forkexec-constructor '("/lib/console-setup/console-setup.sh"))
#:stop (make-kill-destructor)
#:oneshot? #t)
(make
#:provides '(cups)
#:requires '()
#:docstring "The cups service provides the CUPS scheduler."
#:start (make-forkexec-constructor '("cupsd" "-f"))
#:stop (make-kill-destructor)
#:respawn? #t)
(make
#:provides '(cups-browsed)
#:requires '(cups)
#:docstring "The cups-browsed service makes remote CUPS printers available locally."
#:start (make-forkexec-constructor '("cups-browsed"))
#:stop (make-kill-destructor)
#:respawn? #t)
(make
#:provides '(dbus)
#:requires '()
#:docstring "The dbus service provides the D-Bus System Message Bus."
#:start (make-forkexec-constructor '("/usr/local/etc/init.d/dbus"))
#:stop (make-kill-destructor)
#:respawn? #t)
(make
#:provides '(lightdm display-manager)
#:requires '(dbus)
#:docstring "The lightdm service provides the Light Display Manager."
#:start (make-forkexec-constructor '("/usr/local/etc/init.d/lightdm"))
#:stop (make-kill-destructor)
#:respawn? #t)
(make
#:provides '(dm-event)
#:requires '()
#:docstring "The dm-event service provides an event monitoring daemon for device-mapper devices."
#:start (make-forkexec-constructor '("dmeventd" "-f") #:environment-variables (append (environ) '("SD_ACTIVATION=1")))
#:stop (make-kill-destructor)
#:respawn? #t)
(make
#:provides '(dns-clean)
#:requires '()
#:docstring "Clean up any mess left by 0dns-up"
#:start (make-forkexec-constructor '("/usr/local/etc/init.d/dns-clean"))
#:stop (make-kill-destructor)
#:oneshot? #t)
(make
#:provides '(firewalld)
#:requires '(dbus polkit)
#:docstring "The firewalld service provides a dynamically managed firewall."
#:start (make-forkexec-constructor '("firewalld" "--nofork" "--nopid"))
#:stop (make-kill-destructor)
#:respawn? #t)
(make
#:provides '(grub-common)
#:requires '()
#:docstring "Record successful boot for GRUB."
#:start (make-forkexec-constructor '("/usr/local/etc/init.d/grub-common"))
#:stop (make-kill-destructor)
#:oneshot? #t)
(make
#:provides '(grub-initrd-fallback)
#:requires '(grub-common)
#:docstring "GRUB failed boot detection."
#:start (make-forkexec-constructor '("/usr/local/etc/init.d/grub-in
Re: Caching The Python World: guix shell --container
jgart writes: > On Sat, 15 Jan 2022 08:45:57 +0100 Ricardo Wurmus wrote: >> >> jgart writes: >> >> > Is there currently a convenient way to tell Guix to build "all python-* >> > packages" and cache them? >> >> This should do it: >> >> guix build --keep-going -e '\ >> (begin \ >> (import (guix packages) (gnu packages) (guix build-system python)) \ >> (fold-packages \ >> (lambda (item acc) \ >> (if (eq? python-build-system (package-build-system item)) \ >> (cons item acc) acc)) \ >> (list)))' >> >> This will build all packages with python-build-system. fold-packages is really neat. You can also add even more filtering here; by package name, by inputs, anything really. For example, the expression above will give you any package built with python-build-system, but this may be too much, as it includes Python 2 packages. It is just a fold, though, so all work happens in that procedure that is given the current package and the accumulator from past invocations of the procedure. The only important thing is that the procedure always returns a value for the accumulator. It doesn’t have to be a list either; it could be a hash table so you can easily look up packages you’ve already accumulated so far and base your decision on that, etc. -- Ricardo
Re: Celebrating ten years of Guix
I still remember sending my first patch in 2014 and the happiness of getting it accepted. I am using Guix everywhere and has made my life so much simpler to experiment with things. I love the Guix Community! Looking forward to another 10 year and beyond :D On 1/15/22 06:52, Pjotr Prins wrote: On Wed, Jan 12, 2022 at 03:27:32PM +0100, Ludovic Courtès wrote: Hello Guix! This year marks the tenth anniversary of Guix; what if we used that as a pretext to join forces and organize “special events” throughout the year? Obviously the Guix Days are already a great start! Great idea. In 2014 I watched your first presentation of Guix at FOSDEM. I was sold on the spot! We use Guix containers and services through all our deployments - it is a massive success story. https://guix.gnu.org/guix-fosdem-20140201.pdf Onwards and upwards! Pj.
Re: Caching The Python World: guix shell --container
On Sat, 15 Jan 2022 08:45:57 +0100 Ricardo Wurmus wrote: > > jgart writes: > > > Is there currently a convenient way to tell Guix to build "all python-* > > packages" and cache them? > > This should do it: > > guix build --keep-going -e '\ > (begin \ > (import (guix packages) (gnu packages) (guix build-system python)) \ > (fold-packages \ > (lambda (item acc) \ > (if (eq? python-build-system (package-build-system item)) \ > (cons item acc) acc)) \ > (list)))' > > This will build all packages with python-build-system. > > -- > Ricardo Oh darn! Ricardo, THNX You've been giving me some great tips :) Much appreciated! all best, jgart
