Re: git based code review

[raingloom]

On 2024-06-24 16:18, Ekaitz Zarraga wrote:
> Hi,
> 
> On 2024-06-24 11:31, raingl...@riseup.net wrote:
>> Since the email based workflow has put off quite a few potential
>> contributors, maybe this could be a good distributed alternative:
>> https://github.com/google/git-appraise
>> 
>> Disclaimer: haven't tried it myself, also haven't tried packaging it.
>> The Go and Rust dependencies could be hard to package with Guix's
>> current tools.
>> 
> 
> Arun is also developing a similar thing but it's not based on the git-notes 
> for the issue system. I don't remember the name, maybe he can talk more about 
> it.
> 
> Also `fossil` does all this but "better" integrated.
> 
> It's a very interesting thing to test but also our repo is already kind of 
> huge. If we merge all the issues and stuff in it... It might become even 
> gigantic.
> 
> Also, the Mumi based workflow described here:
> https://guix.gnu.org/manual/devel/en/html_node/Debbugs-User-Interfaces.html#Command_002dline-interface
> 
> ...is probably way better than using `git send-email` raw. WDYT?
> 
> I started with `git send-email` not that long ago, and *I* didn't find the 
> workflow hard to follow. In fact, *I* think it's even easier than the PR 
> based thing that is widespread right now.
> 
> I'm not saying it isn't true that there is people that was put off by the 
> email based workflow, but I'd like to know how many.
> 
> In any case, it's a very interesting link! Thanks for sharing!
> 
> Cheers!


This is specifically for code *review*, not issue tracking or simply
sending patches.  PR review was one of the major problems with the email
tools that I've seen mentioned.

git based code review

[raingloom]

Since the email based workflow has put off quite a few potential
contributors, maybe this could be a good distributed alternative:
https://github.com/google/git-appraise

Disclaimer: haven't tried it myself, also haven't tried packaging it. 
The Go and Rust dependencies could be hard to package with Guix's
current tools.

Re: Next Steps For the Software Heritage Problem

[raingloom]

On 2024-06-18 20:08, Ian Eure wrote:
> Andy Tai  writes:
> 
>> What is the role of GNU Guix in this? If Guix is mainly a referral
>> mechanism like web page links to the actual contents, the real problem
>> is not Guix but the use of free software which can be obtained via
>> other mechanisms directly anyway to train LLMs if Guix is not in the
>> loop?

> Guix sends archive requests to SWH.  SWH gives that source code to 
> HuggingFace.  HuggingFace demonstrably violates the licenses.
> 
> Guix could stop sending archive requests to SWH.  This wouldn’t *stop* the 
> bad things from happening, but it would *stop condoning* them.  The same as 
> how Guix not allowing non-free software doesn’t stop people from running it, 
> but doesn’t condone it.
> ...

Guix doesn't just condone it in this case, it's actively helping SWH out
by submitting packages.

Re: Next Steps For the Software Heritage Problem

[raingloom]

On 2024-06-19 11:54, Efraim Flashner wrote:
> On Wed, Jun 19, 2024 at 12:13:38PM +0300, MSavoritias wrote:
> ...
> One of our packages, dbxfs, left Github a while ago and continued
> development on a different forge. They adjusted their README to disallow
> hosting of their code on Github. Based on this restriction we have
> labeled later versions of the software as non-free and have not updated
> the package. IMO saying that source code cannot be uploaded to SWH would
> fall into the same category.

No wonder more and more people are growing dissatisfied with the free
software movement.

Re: Are 'guix gc' stats exaggerated?

[raingloom]

On 2024-05-26 22:13, Felix Lechner via "Development of GNU Guix and the
GNU System distribution." wrote:
> Hi,
> 
> Today I ran 'guix gc' on equipment with an ext4 root partition.  It had
> these space characteristics beforehand:
> 
> Filesystem  Size   Used  Avail Use% Mounted on
> /dev/dm-3   309047680  157252980 138126064  54% /
> 
> or for human eyes:
> 
> /dev/dm-3   295G150G  132G  54% /
> 
> After the run, the drive showed:
> 
> /dev/dm-3   309047680   88267956 207111088  30% /
> 
> or for human eyes:
> 
> /dev/dm-3   295G 85G  198G  30% /
> 
> By my math, about 65.8 GiB were recovered.
> 
> When 'guix gc' was done, it announced:
> 
> [184389 MiB] deleting '/gnu/store/...'
> deleting `/gnu/store/trash'
> deleting unused links...
> note: currently hard linking saves 59224.03 MiB
> guix gc: freed 110,649.49 MiBs
> 
> Seeing the 184389 MiB number, or 180 GiB, already made me suspicious.
> It exceeded my drive usage by 30 GiB.  Even the more conservative 110649
> MiB "freed," however, are off by a mile. That would have been 108 GiB,
> or 42 GiB more than the space actually recovered.
> 
> Am I looking at those numbers the wrong way?  Thanks!
> 
> Kind regards
> Felix

Are you using compression? (BTRFS, ZFS, etc)

watchdog triggered auto-rollback

[raingloom]

Since I've been experimenting with a foolproof unikernel based static
website deployment lately, I realized I should write down this idea I've
been chewing for a while:

It would be very nice to have automatic system rollbacks when certain
things break.
One example is broken SSH config that makes a machine unreachable.
Local testing is useful, but like in the SSH example, some issues only
become apparent when you are deploying to the production environment.

Would others find this useful?  Where in the stack would this be solved?
 Could we, for example, catch an issue in the init system and still
perform a rollback?  Or if not a full rollback, then at least a reboot
into the previous config?  (And if that is also broken, then the one
before, etc, etc)

Obviously there are a lot of edge cases and potential bugs in this
mechanism as well.  Sticking with the SSH example, rolling back to a
version that was kept around where the authorized keys are different
would also make the machine unreachable via SSH.

Re: guix --container is RAM hungry

[raingloom]

On 2024-03-21 22:44, Edouard Klein wrote:
> Dear Guixers,
> 
> I'm a huge fan of guix --container, and I created a system to use those
> by default for network services. But the VPS these services run on has
> only 2GB of RAM, and I just realized that a container, by default,
> requires at least 200MB.
> 
> Try it:
> guix shell time which -- bash -c "$(which time) -v guix shell
> --container"
> 
> Then Ctrl-D, and look for this line:
>   Maximum resident set size (kbytes): 291300
> 
> 291MB of RAM to run bash.
> 
> 
> By contrast, removing the --container option from above yields:
>   Maximum resident set size (kbytes): 64496
> 
> 64MB, still a lot, but I can live with that.
> 
> I tried various calls to unshare, but got no significant increase of
> RAM.
> 
> From an outsider's point of view, the --container option is a wrapper
> for unshare, and the dependency resolution is done by guix shell with
> or without the --container option, so I don't understand where the RAM
> explosion come from.
> I mean no implication that '--container' is simple or trivial to
> implement, I just wrestled with namespaces for a few weeks and I know
> they're a pain, to stay polite. I'm thankful for the tool and would like
> to use it more, but I can't in its current state.
> 
> 
> Any ideas ?
> 
> Thanks in advance,
> 
> Edouard.

My first guess is that the Guile process is hanging around waiting for
the process it launched, instead of exec-ing into it directly.

Re: Shepherd timers

[raingloom]

On 2024-03-24 22:20, Ludovic Courtès wrote:
> Hello Guix!
> 
> I pushed to the ‘devel’ branch of the Shepherd a new module that
> implements “timers” along with ‘herd’ support to display information
> about them.
> 
> It lets you provide configuration like this one:
> 
> --8<---cut here---start->8---
> (use-modules (shepherd service timer))
> 
> (define timer
>   (service '(my-timer)
>#:start (make-timer-constructor
> (calendar-event #:seconds '(0 7 15 22 30 45))
> (command '("sh" "-c" "echo Hi from $PWD.; sleep 20; echo 
> done")))
>#:stop (make-timer-destructor)))
> 
> (register-services (list timer))
> (start-in-the-background '(my-timer))
> --8<---cut here---end--->8---
> 
> And then ‘my-timer’ invokes the given command at the moments that match
> the constraints defined by ‘calendar-event’—in this case any time the
> number of seconds is equal to 0, 7, 15, 22, 30, or 45.  You can also
> make it every Monday at 9AM etc., as you would expect.
> 
> The ‘herd’ command provides details information about the timer:
> 
> --8<---cut here---start->8---
> $ ./herd -s sock status my-timer
> Status of my-timer:
>   It is running since 21:09:32 (68 seconds ago).
>   Timed service.
>   Periodically running: sh -c "echo Hi from $PWD.; sleep 20; echo done".
>   Child process: 1814
>   It is enabled.
>   Provides (my-timer).
>   Requires ().
>   Will not be respawned.
> 
> Recent runs:
>   2024-03-24 21:10:04 Process exited successfully.
>   2024-03-24 21:10:19 Process exited successfully.
>   2024-03-24 21:10:26 Process exited successfully.
>   2024-03-24 21:10:34 Process exited successfully.
>   2024-03-24 21:10:35 Process terminated with signal 15.
> 
> Recent messages:
>   2024-03-24 21:10:29 Hi from /home/ludo.
> 
> Upcoming timer alarms:
>   21:10:45 (in 5 seconds)
>   21:11:00 (in 20 seconds)
>   21:11:07 (in 27 seconds)
>   21:11:15 (in 35 seconds)
>   21:11:22 (in 42 seconds)
> --8<---cut here---end--->8---
> 
> And of course you can do anything you can do with a service: stop it,
> unload it, load a replacement, and so on.
> 
> Feedback & suggestions welcome!
> 
> Ludo’.

Does it support RTC wakeup?

Re: Teams

[raingloom]

I'd definitely love to see an A/V or graphics production team, making
Guix more suitable for artists has been on my TODO list for a while,
even made some tentative steps towards packaging Blender addons.
Personally, I'd love to help out with testing and/or developing Blender
stuff.

On Mon, 13 Jun 2022 13:38:16 +
Blake Shaw  wrote:

> Hi folks,
> 
> I'm just getting back to the list after finishing a gig, but want to
> raise my hand to join both the scheme team and perhaps something like
> an A/V team if folks think that would be a desirable team to put
> together. I think an A/V team would look after:
> 
> #+begin_example scheme
>  (gnu packages gstreamer)
>  (gnu packages gl) ;; Maybe games could handle this?
>  (gnu packages video)
>  (gnu packages graphics)
>  (gnu packages music)
> #+end_example
> 
> Which is quite a lot! So maybe some of this should be split up with
> the "games" team.
> 
> On another note, I'll be getting back to the Guile Docs soon, and
> before that I plan on taking a stab at refactoring the patch
> submission criteria, which I think could use some work. As it is
> currently, it personally becomes a hurdle of a checklist when I want
> to quickly submit a patch, which has lead me to running a hotfix
> branch so that I can quickly fix an issue and move on, therefore
> contributing what I should be. I think it could express all the same
> requirements in less rules, making it easier to ensure what you're
> handing in is in order. But I still need to take a stab at it and see.
> 
> Best,
> 
> On Fri, Jun 10, 2022, 03:29 Arun Isaac 
> wrote:
> 
> >
> > Hi Guix,
> >
> > I like the idea of teams. And, it's nice to see so many volunteers
> > raise their hands!
> >  
> > > * Rust team
> > > Efraim Flashner
> > > Aleksandr Vityazev
> > > Arun Isaac
> > > John Soo
> > > Maxim Cournoyer
> > > Nicolas Goaziou
> > > Tobias Geerinckx-Rice  
> >
> > However, I know very little about Rust, and I'm not a good fit for
> > this team. I could easily be a part of the python, emacs lisp,
> > common lisp, scheme teams, etc if necessary.
> >
> > But, what I'd really like is to be part of a mumi+tooling team.
> > Maybe we should have such a team?
> >
> > Also, since we have so many ideas for teams, can we have some
> > structured way to suggest teams, and add or remove them as needs
> > change?
> >
> > Regards,
> > Arun
> >
> >  

Re: A corner case of broken reproducibility

[raingloom]

On Wed, 01 Jun 2022 22:09:11 +0200
Maxime Devos  wrote:

> Ludovic Courtès schreef op wo 01-06-2022 om 18:38 [+0200]:
> > There’s a talk by Lennart Poettering where he explains that,
> > contrary to what one might think, “chown -R $HOME” turns out to be
> > fast enough that systemd-homed can do that unconditionally (off the
> > of my head).  
> 
> Interesting.
> Taking "find $HOME > /dev/null" as an approximation of how long "chown
> -R $HOME" would take:
> 
> $ time find . > /dev/null 
> 
> real  0m7,066s
> user  0m0,427s
> sys   0m1,341s
> 
> Assuming that ‘unconditionally = only chown -R $HOME if the uid of
> $HOME isn't what was expected’ (otherwise, +7sec for every boot),
> that's not too bad.
> 
> That's on a SSD and not a hard disk though, I'd image it would be
> worse on a hard disk.
> 
> Depending on the size of $HOME, it could be a lot longer though:
> 
> $ time find /gnu/store > /dev/null 
> 
> real  1m9,729s
> user  0m4,135s
> sys   0m13,840s
> 
> Might still be acceptable as long as uids aren't switched too often
> ...
> 
> Can we, as-is in Guix, assume we can modify /home/foo though?  E.g.
> what if it's put on a separate storage medium not attached at boot.
> 
> Greetings,
> Maxime.

Could we instead check for existing homes and set uids in
/etc/passwd based on that instead? That's practically O(1), but is a
bit more involved.

Re: Building hexyl (a rust app) without cargo, with antioxidant-build-system

[raingloom]

On Mon, 30 May 2022 11:23:21 +0300
Efraim Flashner  wrote:

> On Sat, Apr 02, 2022 at 05:18:55PM +0200, Maxime Devos wrote:
> > Hi,
> > 
> > antioxidant-build-system can now be used for some ‘real’ software
> > -- it compiles 'hexyl'.  To test, download
> >  (commit:
> > d09fd93750ac6d77e0c85623286b45cf5c3b055b) and run
> > "guix build -L . -f guix.scm" and then
> > 
> > $ cat guix.scm | /gnu/store/[...]-hexyl-0.8.0/bin/hexyl  
> > > lots of coloured hex output  
> > 
> > Some features of antioxidant-build-system:
> > 
> >   * no copying source code of dependencies
> >   * no compiling dependencies again -- old artifacts are reused
> >   * all dependencies use the usual package input system
> > (native-inputs, inputs, propagated-inputs)
> > 
> > Limitations:
> > 
> >   * no support for linking to arbitrary shared libraries yet
> > (only rust deps)
> >   * makes a few assumptions on the source layout (can be fixed
> > by using more info from Cargo.toml)
> >   * no tests
> >   * no cross-compilation yet
> >   * no shared libraries (just replacing 'rlib' by 'dylib' causes
> > problems)
> >   * code is a bit messy
> >   * no cdylib yet (probably needed for librsvg)  
> 
> Something that might help with that would be to also include the
> source of the crate somewhere in the output. Then at the worst we
> could just put the rust inputs of librsvg as regular inputs and let
> librsvg do its own special build thing. We'd then still keep the
> build dependency tree you've got working.
> 
> 

Maybe put the source in an extra output, not the main "out" one.
Splitting them up later for size reduction will be much more difficult
than doing this from the get-go.

Re: The case for moving raw binaries

[raingloom]

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

[raingloom]

On Fri, 15 Apr 2022 15:36:25 -0500
Nathan Dehnel  wrote:

> >People shouldn't have to take extra steps and burn extra CPU cycles
> >for  
> security. If I have to recompile everything to harden my system, I
> likely won't bother.
> >Pretty much everyone benefits from hardening, but not everyone has
> >the  
> resources and know how to do it manually. Just choosing what to harden
> is already not a trivial question.
> 
> Then have hardened be the default and have --hardened=off be the
> package transform option?

Yes, that seems like a better solution. Maybe call it
--without-hardening, to match the current convention.
(Like --with-latest, --without-tests, etc)

Re: Hardened toolchain

[raingloom]

On Sat, 16 Apr 2022 00:04:37 +0800
Zhu Zihao  wrote:

> > I like this idea.  I propose we make harden? default to #t.  That
> > way practically most packages will be built with hardened features.
> > Let's face it, I am a bit lazy, if I submit a package to guix, I am
> > usually going to be it the easy way. If the easy way is harden? #f,
> > then that's is how I will submit it. :)  
> 
> I suggest a build transform flag like `--hardened` for people who
> wants a hardened software, just like `--tune` for SIMD instructions.

People shouldn't have to take extra steps and burn extra CPU cycles for
security. If I have to recompile everything to harden my system, I
likely won't bother.
Pretty much everyone benefits from hardening, but not everyone has the
resources and know how to do it manually. Just choosing what to harden
is already not a trivial question.

Re: phrasing of project vision

[raingloom]

On Fri, 15 Apr 2022 23:39:07 +0800
Zhu Zihao  wrote:

> Joshua Branson  writes:
> 
> > +The vision of the GNU Guix project is to replace proprietary
> > software with +freedom respecting software.  We hope to create a
> > general purpose and +extensible operating system that works well
> > accross embedded environments to +extremely powerful server setups.
> >  When this vision is complete (it may never +be complete, that's
> > why it is a vision!) all software will be free software.  
> 
> IMO, replacing proprietary software with libre software should be the
> vision of the whole GNU project. 
> 
> Maybe we can change it to "The vision of the GNU Guix project is
> providing a reliable and convenient way for people to use, distribute,
> develop libre software."
> 
> Other parts LGTM :)

It might be worth bikeshedding the phrasing a bit, because "freedom
respecting" and "libre" only really mean something to people who are
already on board with these ideas. The end goal is software that serves
people, instead of controlling and coercing them. Maybe it's worth
emphasizing that.

(Also please fill the subject line next time, it's hard to keep track
of threads when they are unlabeled.)

Re: Building hexyl (a rust app) without cargo, with antioxidant-build-system

[raingloom]

On Mon, 04 Apr 2022 11:26:45 +0200
Maxime Devos  wrote:

> Brendan Tildesley schreef op ma 04-04-2022 om 15:10 [+1000]:
> >  I would have called it cargone.
> >  
> >  Do you believe sidestepping cargo all together like this is a good
> > long term strategy?  In particular that importing packages will
> > still be easy.   
> 
> The package definitions look almost the same, except for:
> 
>   * #:cargo-inputs and #:cargo-development-inputs are moved to
> 'inputs'/'propagated-inputs' and 'native-inputs'
>   * For a few packages, #:features ~'(...) needs to be added
>   * antioxidant-build-system doesn't look at version numbers,
> so the numbers of variants of packages that needs to be defined
> could perhaps be reduced
>   * Cycles are not supported
> 
> The fourth point might make things difficult though I have some ideas
> on how to resolve it (without simply disabling tests)  (TBI!). 
> Otherwise, I don't see much complications with importing packages.
> 
> Greetings,
> Maxime.

I'm also a bit worried with the trend of Guix trying to duplicate
functionality already present in language package managers and config
file formats. It creates a two-sources-of-truth situation. Trying to
keep one up to date with the other can be an issue, this is why I
didn't create a custom record type for Yggdrasil config files and just
used a generic JSON converter. Which paid off, since there were in fact
changes in the config fields between versions.
Will this build system avoid that issue as well?
I guess if the data it operates on has truly stable semantics, then
writing an independent implementation is not as big a problem, since
once written and debugged, it won't need to change.
(And getting rid of cargo would be nice for Rust dev on Guix.)

Re: PipeWire as a PulseAudio replacement (was Re: The Shepherd on Fibers)

[raingloom]

On Sun, 27 Mar 2022 22:55:36 +1100
Brendan Tildesley  wrote:

> On 27/3/22 01:24, Josselin Poiret wrote:
> 
> > Hello Brendan,
> >
> > Brendan Tildesley  writes:  
> >> I would like to replace pulseaudio with pipewire as the default in
> >> %desktop-services, the only hurdle is how to launch the user
> >> daemons in all the different desktop configurations one might use.
> >> Other distros use systemd's socket activation to magically launch
> >> pipewire.
> >>
> >> Otherwise XDG autostarts or some kind of guix home service could
> >> launch it?  
> > The main issue for PipeWire is that it really doesn't support
> > running a single system-wide daemon as we're doing with PulseAudio,
> > so you would need to launch it through XDG autostart, guix home or
> > something similar like you said!  
> 
> I think this is not right. Pulseaudio and Pipewire are both "user
> services". The Guix (pulseaudio-service-type) merely sets up some
> global configuration files and evironment variables. Actually these
> could be a part of the user profile if one really wanted. The only
> parts that actually need to be done by root is the udev service and
> the alsa service setting two configuration files.
> 
> Pulseaudio is automatically started by applications that make use of
> it via DBUS. I don't understand how that works, but for whatever
> reason Pipewire's official way to launch is via systemd sockets.
> Systems without systemd use XDG autolaunch with a trivial script like
> this one:
> https://gitweb.gentoo.org/repo/gentoo.git/tree/media-video/pipewire/files/gentoo-pipewire-launcher.in
> 
> So it is not difficult at all to run Pipewire, just a method must be
> chosen.
> 
> >
> > One thing that I think is blocking right now is that PipeWire (or
> > actually WirePlumber, I don't remember) would need to see some
> > environment variables set by other user services eg. session D-Bus
> > or even the compositor, which isn't possible yet with Shepherd.  
> 
> Which environment variables are you talking about? I'm running
> pipewire on Guix System
> 
> and it seems to work fine.
> 
> > Best,  

This might be of interest.

https://freeradical.zone/@craftyguy/107981283066383952
https://sr.ht/~craftyguy/superd

Re: Documentation of what is appropriate for #guix?

[raingloom]

On Sun, 20 Feb 2022 11:41:23 +0900
Yasuaki Kudo  wrote:

> Or even better, create an alternative community of practitioners who 
> don't give a damn (for their purposes)...   Let me know if other
> people also want to create a corruption-admitted-community as well
> .  We can work together.  -Yasu
> 
> On 2/20/22 11:33, Vagrant Cascadian wrote:
> > Every now and then someone stumbles into #guix and ask questions
> > that I've gleaned over time are off-topic (e.g. non-free software).
> > While I have a pretty good idea what is appropriate for the
> > channel, it is not clear to me where that is documentated.
> >
> > I figured maybe it is referenced in the code of conduct, but then I
> > see no reference to the code of conduct on https://guix.gnu.org,
> > although it is in the toplevel directory of guix.git as
> > "CODE-OF-CONDUCT".
> >
> > Still, the CODE-OF-CONDUCT doesn't really say anything about what is
> > on-topic for #guix on irc...
> >
> > It would be helpful to have a link to be able to point to more
> > easily whenever either subjects come up in the irc channel, ideally
> > somewhere a little easier to find. :)
> >
> >
> > live well,
> >vagrant  
> 

Something like that already exists for The Channel That May Not Be
Named.

By the way, I think it's kind of silly that that is completely banned
from discussion. When I wanted help on getting my GPU to work, I
mentioned for reference purposes that I tried the proprietary driver
from The Forbidden Channel - and was subsequently warned that I must
not do that. Which I find ridiculous. You can't even discuss results
obtained by running closed source drivers and firmware, so how do you
debug the libre firmwares and drivers, when you have nothing to compare
against?

Also, I think people who want to overwhelmingly use free software but
need proprietary drivers for their computer to function should be
offered better help than "buy a new computer". Currently I'm a mostly
happy user of an AMDGPU based desktop, which lets me create creative
commons artwork in Blender, that I would not be able to do without
proprietary firmware.

I think The Forbidden Channel should be raised to a status similar to
the AUR: it's recognized and its existence is documented, but all
responsibility is very explicitly disclaimed and support is relegated
to special channels.

Re: Excessively energy-consuming software considered malware?

[raingloom]

On Mon, 21 Feb 2022 14:06:07 +0100
Maxime Devos  wrote:

> Attila Lendvai schreef op ma 21-02-2022 om 09:29 [+]:
> > let me add, though, that a more apples-to-apples comparison here
> > would be to compare Bitcoin to the FED, and PoW to the costs of
> > enforcing the PetroDollar system on the entire world.  
> 
> Here PetroDollar = US dollar and FED=US Federal Government?
> 
> > these costs not only include the direct environmental damages of
> > wars and militaries. more generally, it also includes the costs of
> > enforcing a certain economic structure globally, instead of
> > potential better alternatives for facilitating cooperation between
> > strangers that may very well promote peace and prosperity more
> > effectively and efficiently than the current system.  
> 
> If the US Government enforces the US Dollar with wars etc., then this
> seems more a bug of the US than a benefit of Bitcoin to me.  Also, I
> don't understand what you mean with ‘enforcing’ here.
> 
> Locally, in Belgium, I can use the Euro as currency.  The US isn't
> forcing me to use the US dollar, in fact I have never seen a US dollar
> in person and most (all?) local businesses accept the Euro as currency
> and most physical shops wouldn't accept foreign currency(*).
> 
> I can also use the US dollar as currency to buy from overseas (after
> trading Euro for US dollar, this happens automatically when
> e-shopping), even though the US hasn't stationed military forces
> at the banks to force the banks to allow converting Euro<->US dollar.
> 
> I'm not seeing any enforcement here, nor any need for enforcement to
> make the US dollar a usable currency.
> 
> While the US would (does?) wage wars to force countries to trade with
> the US (and perhaps force them to accept US dollar maybe?), I don't
> see how Bitcoin would change this -- Bitcoin might change the
> currency used for the forced trade, but not the existence of the
> forced trade.
> 
> (*) at least, I think so, I haven't ever tried.
> 
> > and from that perspective i don't see the use of 'absurd amount'
> > justified, by a large margin.
> > 
> > and the more some of us disagree with the above, the more
> > appropriate it seems to have been to use 'controversial morality'
> > by Martin.  
> 
> Greetings,
> Maxime.

For some reason, assholes like Peter Thiel (co-founder of Palantir
among others) seem to love cryptocurrencies, so maybe remember to
mention that next time in comparisons with the US government. I think
something about the total lack of regulations and customer protections
appeals to his ilk, but what do I know. :)
As Folding Ideas put it (paraphrased): the problem is patterns of human
behaviour, it's what people do to eachother, not that the building they
do it in has the word "Bank" written on it.
If you haven't seen it, I really recommend it:
https://redirect.invidious.io/watch?v=YQ_xWvX1n9g

I'd much rather see Spritely's OCAP money and LETS take off than the
"everything is a stock market" future that cryptocurrency fans envision.

Anyways, IMHO a blanket ban on blockchain based cryptocurrency in Guix
is not necessarily the best step to take, but I also don't think we
should welcome all such packages with open arms. But if others want to
ban some of them, I won't complain.

Re: File search

[raingloom]

On Fri, 21 Jan 2022 10:03:43 +0100
Ludovic Courtès  wrote:

> Hello Guix!
> 
> Lately I found myself going several times to
>  to look for packages providing a given
> file and I thought it’s time to do something about it.
> 
> The script below creates an SQLite database for the current set of
> packages, but only for those already in the store:
> 
>   guix repl file-database.scm populate
> 
> That creates /tmp/db; it took about 25mn on berlin, for 18K packages.
> Then you can run, say:
> 
>   guix repl file-database.scm search boot-9.scm
> 
> to find which packages provide a file named ‘boot-9.scm’.  That part
> is instantaneous.
> 
> The database for 18K packages is quite big:
> 
> --8<---cut here---start->8---
> $ du -h /tmp/db*
> 389M/tmp/db
> 82M /tmp/db.gz
> 61M /tmp/db.zst
> --8<---cut here---end--->8---
> 
> How do we expose that information?  There are several criteria I can
> think of: accuracy, freshness, privacy, responsiveness, off-line
> operation.
> 
> I think accuracy (making sure you get results that correspond
> precisely to, say, your current channel revisions and your current
> system) is not a high priority: some result is better than no result.
>  Likewise for freshness: results for an older version of a given
> package may still be valid now.
> 
> In terms of privacy, I think it’s better if we can avoid making one
> request per file searched for.  Off-line operation would be sweet, and
> it comes with responsiveness; fast off-line search is necessary for
> things like ‘command-not-found’ (where the shell tells you what
> package to install when a command is not found).
> 
> Based on that, it is tempting to just distribute a full database from
> ci.guix, say, that the client command would regularly fetch.  The
> downside is that that’s quite a lot of data to download; if you use
> the file search command infrequently, you might find yourself
> spending more time downloading the database than actually searching
> it.
> 
> We could have a hybrid solution: distribute a database that contains
> only files in /bin and /sbin (it should be much smaller), and for
> everything else, resort to a web service (the Data Service could be
> extended to include file lists).  That way, we’d have fast
> privacy-respecting search for command names, and on-line search for
> everything else.
> 
> Thoughts?
> 
> Ludo’.
> 

One use case that I hope can be addressed is TeXlive packages. Trying
to figure out which package corresponded to which missing file was a
nightmare the last I had to use LaTeX.

Re: git hook error

[raingloom]

On Tue, 28 Dec 2021 16:40:15 -0500
Leo Famulari  wrote:

> On Tue, Dec 28, 2021 at 10:09:06PM +0100, Ricardo Wurmus wrote:
> > So… uhm, what do you all think about hosting our Git repos by
> > ourselves? Ideally *not* on the servers of the build farm, but on
> > other hardware?  
> 
> I would ask, why would we want to do that?
> 

Maybe not self-hosting, but I would really appreciate a move to a
better forge, like Sourcehut. I have... very few positive
things to say about Savannah's UI, at least from a casual user
perspective. I don't know what it's like for contributors.

Re: Guix "R" Us - GNU's joy store!

[raingloom]

On Tue, 28 Dec 2021 08:40:20 -0500
jgart  wrote:

> On Tue, 28 Dec 2021 13:14:45 +0100 Ricardo Wurmus
>  wrote:
> > 
> > jgart  writes:
> >   
> > > * Yet to be merged upstream.  
> > 
> > Are these going to be submitted and merged upstream eventually?
> 
> Hi Ricardo,
> 
> From our README:
> 
> ```
> The goal of this guix channel is to provide packages and services
> that are:
> 
> * Yet to be merged upstream.
> * In alpha or beta stage of development.
> * Customized to certain use-cases.
> * Nightly releases.
> ```
> 
> To expound on the above a bit:
> 
> > Yet to be merged upstream.  
> 
> You can think of GuixRUs as a pre-release channel for software that
> is waiting to be reviewed upstream.
> 
> Sometimes patches can sit for a while while waiting for upstream
> review and GuixRUs hopes to alleviate some of this anxiety by
> providing those patches as "pre-releases" in a community channel that
> makes them available through an expedited review process. We're
> interested in developing tooling to help facilitate this ambitious
> endeavour.

I think guix time-machine and some options to guix pull already let you
build with some patches or from a custom git URL. If not, maybe making
that easier would be preferable to making a separate channel.

> > In alpha or beta stage of development.  
> 
> We'll make grumble available through GuixRUs and provide a service:
> 
> https://issues.guix.gnu.org/
> 
> Another software that is in heavy development but useable:
> 
> https://wahay.org/
> 
> > Nightly releases.  
> 
> GuixRUs will start by tracking olive-editor nightlies:
> 
> https://www.olivevideoeditor.org/nightly.php

What's the improvement with this channel compared to just using the
various package transformations, like --with-latest or --with-branch or
whatever?

> > What's the intended process to avoid this?  
> 
> Packages that are suitable for upstream will be sent in batches. 
> 
> whereiseveryone community are active contributors and we'll make sure
> to send over any developments suitable for upstream.
> 
> We welcome anyone to help contribute in those efforts. 
> 
> Feel free to upstream anything in GuixRUs that you see suitable if we
> don't get around to it.
> 
> If you remember to list the original author/packager when upstreaming
> from GuixRUs it would be much appreciated.
> 
> The first batch to be sent from GuixRUs for upstream will be these
> emacs packages we recently packaged:
> 
> https://git.sr.ht/~whereiseveryone/guixrus/tree/master/item/guixrus/packages/emacs.scm
> 
> > Customized to certain use-cases.  
> 
> I recently forked vis to provide language server protocol support
> "out of the box".[1]
> 
> We're also packaging all the suckless patches for dwm, st, dmenu,
> surf, etc... and making them available as guile variables/code in
> order to easily assemble your own suckless forks with guix[2][3]. In
> other words, GuixRUs can also be thought of as a library for
> assembling your own suckless fork.

Again, package transformations already let you do this. Might make more
sense to just set up a substitute server.

> > Is only free software acceptable in this channel?  
> 
> Yes, we only accept free software. GuixRUs is a free software bazaar.
> 
> GuixRUs is at the service of assisting upstream and the Guix
> community at large.
> 
> all best,
> 
> jgart
> 
> 
> [1]
> https://github.com/fischerling/vis-lspc#easy-vis-lspc-installation-with-guixrus
> [2]
> https://git.sr.ht/~whereiseveryone/guixrus/tree/master/item/guixrus/patches/suckless.scm#L28
> [3]
> https://git.sr.ht/~whereiseveryone/guixrus/tree/master/item/guixrus/packages/suckless.scm#L44
> 

TLDR how much of the effort spent on this channel is really justified
compared to making the underserved use-cases easier in upstream Guix?

useful snippet for debugging a package that builds but shouldn't

[raingloom]

I used it to run `make localmodconfig` in a linux build, others might
find it useful as well. Should I contribute it to the cookbook or Guix
itself as well?

```
(define (error-before phase pkg)
  (package
   (inherit pkg)
   (arguments
(substitute-keyword-arguments
(package-arguments pkg)
  ((#:phases phases)
   `(modify-phases ,phases
  (add-before (quote ,phase) 'error-on-purpose
   (lambda _
 (error "error on purpose")
```

Re: Release v1.4 (or 2.0): process and schedule ?

[raingloom]

On Sun, 19 Dec 2021 21:12:36 -0500
Maxim Cournoyer  wrote:

> Hi Simon,
> 
> zimoun  writes:
> 
> > Hi,
> >
> > Now core-updates-frozen is merged.  Now The Big Change [1 ]is done.
> >  Do we go for v1.4 or v2.0?  
> 
> As I've mentioned previously, I'd go for a 1.4.0 release, since
> overall we've refined and improved (greatly!) what we already had
> rather than introduced something revolutionary.  I'd keep a 2.0.0 for
> when we have p2p distributed substitutes, a custom graphical tool
> and/or integration with the 'Software' application in GNOME, this
> kind of big user-facing changes.  But that's just my personal opinion
> :-).  If the majority feels a 2.0.0 is more suitable, I won't mind.

Agreed, if we go by something like semver.

Re: How to test modified shepherd services

[raingloom]

On Sun, 19 Dec 2021 16:47:07 -0600
Nathan Dehnel  wrote:

> I modified a shepherd service to accept a new field from config.scm
> and I was wondering how to test that it works correctly. Do I need to
> make a VM from my modified guix repo with pre-inst-env?
> 

That's probably the best way, it's how I was testing the yggdrasil
service. Definitely do not reconfigure without first testing it in a VM
or container or something.

Word of warning: shepherd is not very forthcoming with logs. You might
want to add some extra logging and redirect output to a file.

Re: Could the Go importer use the Go toolchain? (was Re: Go importer and packages with version flags)

[raingloom]

On Thu, 30 Sep 2021 10:31:08 -0500
Katherine Cox-Buday  wrote:

> Sarah Morgensen  writes:
> > Did you have something particular in mind as far as leveraging the
> > Go tooling?  
> 
> I haven't though too much about it, but ~GOPROXY=direct~ was my guess
> too. Thinking about this, would a shallow fetch into a bare
> repository be so bad?
> 
> It made me start wondering why our ~git-download~ type /doesn't/ have
> this behavior. Are we unnecessarily pulling down the entire commit
> history with all tags and branches of a large repository?
> 
> I don't even know what the philosophy is being doing this or not.
> Isn't the only commitment a Guix package makes for software at a
> particular version/commit that the store contains that immutable
> version of the source, not the complete repository?

AFAIK there is a long standing libgit2 bug for adding support for
shallow fetches. Or rather operations on shallow repositories.
https://github.com/libgit2/libgit2/issues/3058

So guile-git can't have shallow fetches until libgit2 gets its act
together. Or Guix could use a patched libgit2 I guess.

Re: goproxy notes

[raingloom]

On Fri, 27 Aug 2021 09:56:30 -0500
Katherine Cox-Buday  wrote:

> raingloom  writes:
> 
> > do we depend on this? if yes, it might be a good idea to disable the
> > proxy in the importer.
> > sorry, i don't have time to look into it myself right now, so i'm
> > dumping it here.
> >
> > https://drewdevault.com/2021/08/06/goproxy-breaks-go.html  
> 
> Thanks a lot for bringing this up.
> 
> The Go importer has a flag for specifying the proxy server to check
> (Google's is used by default), but this is only used to fetch
> preliminary information about a module, i.e. =go.mod=, the repo's URL,
> and what the proxy thinks is the latest version. The VCS type, VCS
> URL, and actual source code are fetched from the module's defined
> source (i.e. github, etc.).
> 
> It would have been much easier on everyone involved with writing the
> Go importer to just fetch the package from the proxy, but we had the
> foresight to realize it would cause this exact issue: centralization
> on a single service owned by a single company. Since we did not do
> that, a brief scan of our Go packages suggests that all of them are
> fetching source from their respective repositories, and not a proxy
> server.
> 
> As I understand it, Guix builds cannot reach out to the network, so
> there is no risk of leaking metadata to Google via invocation of Go
> commands. Further, our current Go build system does not even use
> modules (this needs to change).
> 
> I think this addresses all the points in this blog post. Overall, I
> think Guix is very well positioned because of how we generate Go
> packages, how our build system works, and how Guix emphasises
> reproducibility.
> 

Guix wins again. UwU
Thanks for looking into it!

goproxy notes

[raingloom]

do we depend on this? if yes, it might be a good idea to disable the
proxy in the importer.
sorry, i don't have time to look into it myself right now, so i'm
dumping it here.

https://drewdevault.com/2021/08/06/goproxy-breaks-go.html

Re: issue tracking in git

[raingloom]

On Fri, 13 Aug 2021 08:29:07 +0200
Adriano Peluso  wrote:

> Hello
> 
> some time ago, in the context of an on line conference about Guix,
> someone suggested me that the bitcoin community had run a survey about
> available solutions for issue tracking in git
> 
> I don't remember the name of such person and I am wondering if amy
> progress has been achieved on that front
> 
> So if they're reading, please, chime in
> 
> I looked on line and found nothing
> 
> Thanks
> 
> 

I think this might be the result of that survey?
https://github.com/bitcoin-core/bitcoin-devwiki/wiki/GitHub-alternatives-for-Bitcoin-Core

cmake importer

[raingloom]

With the growing popularity of using CMake as a language specific
package manager, it might be a good idea to write an importer for it.

Re: What’s next?

[raingloom]

On Tue, 18 May 2021 10:05:05 -0400
Leo Famulari  wrote:

> On Mon, May 17, 2021 at 10:35:22PM -0400, Joshua Branson wrote:
> > I suppose someone should fix the Hurd vulnerabilities as reported
> > here:
> > 
> > https://lists.gnu.org/archive/html/bug-hurd/2021-05/msg00079.html
> > 
> > I don't think the vulnerabilities have been disclosed yet nor has
> > there been a fix yet.  
> 
> That message is the disclosure.
> 

Why not put our eggs in a few more baskets with way fewer holes and
more, uh, basket inspectors looking at them, like maybe packaging Minix,
or OpenBSD, or MirageOS, or whatever? I think I stretched that metaphor
but yknow what I mean.
They have seen way more scrutiny than Hurd and also run on more
architectures and while not GPL licensed, AFAIK they are all libre.

Maybe they can't be used in the operating-system-kernel struct field,
but I don't see anything wrong with using Guix to deploy Mirage
unikernel images for instance.
There is even a nascent Scheme unikernel project with Loko Scheme.

Ooor maybe compile some things to WASM and use a WASM+WASI runtime. I
hate webshit but at least there is already tooling and major porting
efforts for WASM.

Re: Freenode Administration

[raingloom]

On Thu, 20 May 2021 01:40:08 -0400
Bone Baboon  wrote:

> Bone Baboon writes:
> > # IRC alternatives / compliments
> >
> > Some criteria that I have come up with are:
> > * Free software
> > * Can be used without a graphical user interface as many GPUs are
> > not compatible with Linux-libre and can not run Xorg or Wayland
> > window managers / desktops.
> > * Peer to peer as a way to avoid the issue of a centralized
> >   administrator changing their administration in undesirable ways.
> >  
> 
> One more criteria.  Is an Emacs client available.  Inspired by
> .
> 
> > Some alternatives that come to mind that would need further
> > investigation include the following.  I do not know if any of these
> > meet all the criteria I mention above.
> >
> > * Scuttlebutt
> > ** https://scuttlebutt.nz/
> > ** Is there a client that works without a graphical environment?
> >
> > * DAT
> > ** Are there messaging application for DAT?
> > ** https://www.datprotocol.com/
> >
> > * IPFS
> > ** Are there messaging application for IPFS?
> > ** https://ipfs.io/
> >
> > * Jami
> > ** https://jami.net/
> > ** Swarms specifically
> > ***
> > https://jami.net/swarm-introducing-a-new-generation-of-group-conversations/
> > *** Swarms are fully distributed and peer-to-peer text
> > conversations, with a potentially unlimited number of participants.
> > **  on Freenode #jami said:
> > "https://github.com/AmarOk1412/jami-cli/ no video/audio support but
> > support swarm"
> >
> > * RetroShare
> > ** http://retroshare.cc/
> > ** Is there a client that works without a graphical environment?  
> 
> Here is what I have discovered after some further preliminary
> exploration.  I have added XMPP and Tox.
> 
> ## Scuttlebutt
> 
> 
> 
> * Free libre - yes
> * Peer to peer - yes
> * Non graphical client - yes
> ** scat 
> ** scatzero 
> ** scuttle-chat 
> * IRC capabilities - ?
> * Emacs client - no
> 
> ## DAT
> 
> 
> 
> * Free libre - yes
> * Peer to peer - yes
> * Non graphical client - yes
> ** cabal-cli 
> * IRC capabilities - yes
> ** 
> * Emacs client - no

I don't think we can package NPM stuff.

Both the Dat and SSB cores have non-JavaScript implementations AFAIK,
but Cabal itself is JavaScript-only and so are all the SSB clients that
I've seen, but admittedly I haven't looked at the state of the SSB
ecosystem in a few months, so maybe that has changed.
The various sbot implementations do not count as proper clients.

Re: unifying mcron and shepherd, service woes, improvements

[raingloom]

On Sat, 15 May 2021 18:59:52 +0200
Ludovic Courtès  wrote:

> > Security could also be improved probably. Can we have an OCAP model?
> > I feel like I don't know enough to say, so this mail is meant more
> > as a conversation starter.  
> 
> I think “having an ocap model” sounds nice but also vague.  :-)
> 
> A concrete step we can take is follow the principle of least authority
> (POLA) for more services.  That was the spirit of
> .

By OCAP I was thinking of things like not having global state, or at
least not having it implicitly. Something more functional. The lambda
calculus supports the OCAP model, and Guix is all about being
functional, so service management should not be any different.

Would also be nice if replacing running components was supported, a la
Erlang. Maybe steal the supervisor tree idea as well.

Re: What’s next?

[raingloom]

On Sat, 15 May 2021 23:24:41 +0300
Efraim Flashner  wrote:

> package-transformations applied to the operating-system field of the
> os-config.
> 

Gosh, yes please. I keep bumping into this while debugging services.

Also:
* substitutes over bittorrent might be cool.
* split packages more, similar to how Alpine does it. (i said i'd work
  on this and i intend to)
* deduplicate similar but not identical files (if the file system
  allows it)
* better GDB integration
* better initramfs environment, so debugging isn't such a horrible
  experience
* integrate environments with GUIs. if you've used nested rio on Plan
  9, you know what I'm talking about. I already have some utility
  programs for this, but they are pretty basic and only tested on my
  setup.
* accessible installer! even Arch has this now. (also something I want
  to work on eventually)

[spitball] integrating analyzers into build systems

[raingloom]

Would it make sense to run analyzers like Infer or MyPy at build time?
Maybe have something like --with-debug, so if there is an analyzer-log
output, only then is Infer ran?

In theory these tools are more useful for developers, but it's still
potentially useful to independently analyze our software for memory
safety and other errors, but also the build might run in or target an
environment the upstream developer didn't anticipate, for example when
cross compiling, or it could just straight up be patched and not
identical to whatever upstream verified as working.

Could also just be used to scan our software for vulnerabilities.

Anyways, just throwing this out there. I don't think it would have
immediate benefits, but it could be nice in the long term.

unifying mcron and shepherd, service woes, improvements

[raingloom]

Just throwing this out there:
mcron is basically a very simple service manager, so, why not just move
all its timer functionality into shepherd (like systemd's timer units)
and then we can have a unified way to manage and debug services.

But also, shepherd debugging is kind of terrible too, at least on Guix,
so we (and if no one else gets on it that probably means I) should do
something about that.
For example, it's pretty nontrivial to figure out how to run a
service's command in isolation. So far I always had to find it in
/proc, which is not great. stracing a service that fails to start is
also rather tricky. The best I could come up with is to run strace in a
loop and pgrep for the PIDs I'm interested in. Same goes for GDB, which
was still bad in general last time I tried it.

Security could also be improved probably. Can we have an OCAP model?
I feel like I don't know enough to say, so this mail is meant more as a
conversation starter.

So, can we do better? What other issues are there with Shepherd? Are
they fundamental design problems or just plain old bugs?

Or is everyone else happy with the current design and it's just me who
can't use Shepherd properly? 

Re: Making technology more inclusive Was: Leaving the GNU Guix community

[raingloom]

On Sun, 2 May 2021 02:15:31 +0200
Denis 'GNUtoo' Carikli  wrote:

> On Fri, 30 Apr 2021 01:43:37 +0200
> Leo Le Bouter  wrote:
> 
> > I think that the technicality of software development must be
> > redefined so that the hierarchy between the experienced and the
> > beginner disappears [...]  
> I've been thinking a lot about these topics, and there are radical
> solutions that can work today, but the scope is quite limited.
> 
> Sadly, technology in general is way too complex to enable any
> individual to be able to practically exercise the freedom to modify
> how it works at every level

A lot of complexity is essential complexity. Just as an example: type
systems are more complex than dynamic typing, but they would make it
easier to safely customize code without breaking crucial invariants.
Also s-expressions being "parsable" does not make them much better,
because often you have no way of knowing what type some piece of code
expects. They are better than sed, but they only enable intelligent
refactoring, they don't provide them automatically.

I am often more productive in Haskell than in Scheme, because I don't
waste time tracking down trivial errors that can be caught by a type
system, and because it has (and pervasively uses) typeclasses (aka.:
"interfaces"), so I can just use fmap instead of map, vector-map,
bytevector-map, and so on.
Of course you can add type systems to otherwise dynamic languages too,
so this isn't a dichotomy.

Simplicity also shouldn't come at the cost of efficiency. A compiler is
more complex than an interpreter, but it lets you target a wider array
of hardware.

There is a lot to be improved in programming languages and libraries,
but there there is a complexity bedrock you can't dig under.

Re: Symbolics. Look at a Symbolics demo if you want to see some frankly
embarrassing performance. Genera had interesting ideas but no one who
values making the most of their hardware is going to be using it. And
remember, it was even slower on Symbolics hardware, because they
couldn't iterate their CPU designs quickly enough, whereas general
purpose CPUs just kept getting faster and cheaper. Also Lisp compilers
became better at targeting generic ISAs.

But there are interesting ISA designs that actually do improve
performance. My favorites:
* Mill https://millcomputing.com/
* Reduceron https://github.com/tommythorn/Reduceron
* CHERI https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

As for languages, I want to see more types, generics/typeclasses,
effect systems, and more AOT or multi-stage compiled implementations.


Anyways, complexity probably won't entirely go away. It's very difficult
to make an already complex system simpler, building a new simpler one is
easier, which is sad, because I don't think we can afford not being
compatible with existing software and especially existing hardware.

But having a VM based system could help with both. See the classic
talk: The Life and Death of Javascript.

Oh and we should heed Chris Webber's advice and work on OCAP security.
Because yeah, simplicity also mustn't come at the expense of security,
but OCAP would make things both simpler and more secure.

So, yeah, a lot of this complexity is going to stay, but we can at
least try to not make it worse.

Oh, and social issues won't be solved by technology alone. There will
always be complex technological issues and the distribution of the
knowledge to tackle them is a social issue. We have to make our
communities inclusive for vulnerable people if we want to actually
meaningfully help them. Also sometimes you just have to work on featues
that other people want, not just features you want.

ps.: on that note, go ask some blind people about the state
of accessibility on Linux. It's not pretty.
And stop writing curses TUIs. And in general just go learn about
accessible design and test software with actual humans.

Okay, I'll stop here because this is a complex topic (quite fittingly)
and this mail is already (too) long enough.

Re: Leaving the GNU Guix community

[raingloom]

On Sat, 01 May 2021 19:47:40 +0200
Léo Le Bouter  wrote:

> I think it is a disaster that you (maintainers) choose to blame
> someone publicly for feeling so bad after having received messages of
> exceptional aggressivity.

Disclaimer: I only saw some of the relevant discussion, so, please don't
shout at me or assume I'm saying this to hurt anyone.

For what it's worth, blame-free security culture is possible. I was
reading Google's Site Reliability Engineering stuff a few months ago,
which - among other things - talked about exactly this. People need to
feel like they can make mistakes without being attacked for them,
otherwise they won't be open when they inevitably do mess something up.
But I should add that if someone does mess up, it should not be
controversial - to them or their team - to put more oversight on them.

Anyways, I hope you'll stay, and that everyone will strive to make this
an actually inclusive community.

Re: Best practices for writing services

[raingloom]

On Thu, 22 Apr 2021 09:19:56 +0200
Xinglu Chen  wrote:

> On Thu, Apr 22 2021, raingloom wrote:
> 
> >> One thing that I find a little annoying is that you have to
> >> specify a default value for the fields.  
> >
> > Are you sure? If you don't specify a default, won't the user just be
> > forced to write
> > (service whatever
> > (whatever-configuration
> > (mandatory-field 'bleepbloop)))
> >
> > instead of the shorter (service whatever)?  
> 
> If I write something like this
> 
> #+begin_src scheme
> (use-modules (gnu services configuration))
> (define (serialize-list field-name val) "")
> (define-configuration test-config
>   (config
>(list)
>"configuration for test"))
> #+end_src
> 
> and evaluate it, I will get an error.  I have to specify a default
> value for the ‘config’ field to make it work.
> 
> #+begin_src scheme
> (use-modules (gnu services configuration))
> (define (serialize-list field-name val) "")
> (define-configuration test-config
>   (config
>(list '())   ;default to '()
>"configuration for test"))
> #+end_src
> 

Weird. I'd consider this a bug in define-configuration.
define-record-type* does not have this limitation.

Re: Best practices for writing services

[raingloom]

On Wed, 21 Apr 2021 12:45:21 +0200
Xinglu Chen  wrote:

> One thing that I find a little annoying is that you have to specify a
> default value for the fields.

Are you sure? If you don't specify a default, won't the user just be
forced to write
(service whatever
(whatever-configuration
(mandatory-field 'bleepbloop)))

instead of the shorter (service whatever)?

Splitting up packages, targeting smaller/older devices

[raingloom]

I've been pondering installing Guix onto some of my devices that have
tiny amounts of storage. I have an old desktop PC that had an old
version of Uhu Linux on it on a mere 4 gigs of HDD space. Full
graphical desktop, office suite, etc.
A minimal Guix install can just barely fit on it, but can't upgrade
itself. I think it could be possible.

One thing I'd like to try is to split up packages into more outputs,
kinda like what Alpine does. This isn't really technically challenging,
it's mostly just busywork and adding some default build phases and
maybe some more default outputs. But it is a pretty big change, so, is
this something that could eventually be upstreamed?

I'm not planning on starting work on this any time soon, so there's no
rush. Just testing the water for now.
So, is this something that would be welcome in Guix? Do we also want to
target even smaller devices, like OpenWRT supported routers? NixWRT
already exists, so it's not like this is unexplored territory.
PostmarketOS supported devices could be supported too in the future,
storage is also at a premium on those, not to mention flash memory wear
from needless writes.

Re: Idea: when in a guix environment, have guix install packages by default to that environment

[raingloom]

On Fri, 16 Apr 2021 17:09:26 +0100
pkill9  wrote:

> darth-cheney asked in IRC if from inside a guix environment you would
> install the packages instead of pip/node, and maybe having guix
> install packages to current guix environment would be a good idea.
> 
> Possible issue would be how to change the current guix environment to
> the new profile, without creating a nest of environments for every
> `guix install` or `guix package -i`.
> 

You don't have to source the environment again if it was
source with GUIX_PROFILE defined.
I have some notes about this on my Gemini memex that go into more
detail:
gemini://blobpat.space/memex/guix.gem

http proxy in case you don't have a Gemini client at hand:
https://portal.mozz.us/gemini/blobpat.space/memex/guix.gem


You can also add things to your current environment with 
source <(guix environment --search-paths bleep-bloop --ad-hoc whatever)

Re: OUTREACHY INTERNSHIP - INTRODUCING MYSELF

[raingloom]

On Wed, 14 Apr 2021 07:12:51 +0100
obaseki osakpolor  wrote:

> Hello everyone,
> 
> *I am Obaseki, Osakpolor from Lagos, Nigeria. An Outreachy internship
> candidate*.
> I am interested in working with you and contributing to the project
>  - *Guix Data Service: revision processing instrumentation and
> performance.*
> 
> While I have lots of experience using git, writing code with Java,
> Kotlin, and SQL databases
> I am new to contributing to FOSS, Guile, and Guix.
> 
> I look forward to the experience.
> Guile seems pretty interesting to work with so far, and guix has been
> a delight to use.
> I am looking forward to hearing from and working with everyone.
> 
> Regards,
> Osakpolor.

Hi, and welcome to Guix! UwU

Re: Following Guix weather.

[raingloom]

On Fri, 09 Apr 2021 15:53:49 +0200
Mathieu Othacehe  wrote:

> Hello,
> 
> I have deployed a bunch of changes at https://ci.guix.gnu.org/. I'd
> like to introduce some of them here.
> 
> First, there are some new specifications: "images", "tarball" and
> "tests".  Those specifications are configured to build respectively,
> the %guix-system-images declared in (gnu ci), the Guix binary tarball
> and the Guix System tests.
> 
> Each Guix commit potentially triggers a rebuilt of all those
> specifications. We have previously established that this is too
> resource consuming.
> 
> That's why I have added a "period" field to the specification
> definition.  This field only allows a new evaluation when at least X
> seconds have elapsed since the last evaluation.  Right now, the three
> aforementioned specifications have a period field set to 86400 seconds
> (24 hours).
> 
> I have also improved the visibility of latest state of a
> specification. For instance, if you want to know what's the current
> status of the "master" branch or the "staging" branch, you will find
> some statistics directly on the home page. For a more detailed view,
> you can consult dashboards for each specification.
> 
> master dashboard: https://ci.guix.gnu.org/eval/19534/dashboard
> staging dashboard: https://ci.guix.gnu.org/eval/19488/dashboard
> test dashboard: https://ci.guix.gnu.org/eval/19464/dashboard
> 
> By having a look at those dashboards, it's obvious that we still have
> a lot of work before all those circles turn to green.
> 
> Finally, in the evaluation view there's a "Toggle" button to switch
> between:
> 
> - The number of newly fixed/broken/pending builds for each evaluation
>   (default)
> - The total number of fixed/broken/pending builds for each evaluation.
> 
> Don't hesitate to comment on those new features :)
> 
> Thanks,
> 
> Mathieu
> 
> 

Speaking of visibility, please don't use color as the sole carrier of
information. I don't know if you did any accessibility testing for that
page, but not requiring perfect color vision should be step 0. Luckily
it should be an easy fix, just use some shapes.

Re: Question about compile packages

[raingloom]

On Tue, 30 Mar 2021 07:12:27 -0400
Julien Lepiller  wrote:

> Not sure about your first question. Maybe create your own fork and
> regularly rebase it? Guix will not be very happy with that I think,
> but it should work.
> 
> To pass --no-substitutes, you can pass it to guix-daemon, or remove
> the authorized keys from /etc/guix/acl. The second option lets you
> download substitutes for fixed output derivations (basically source
> tarballs), so it's easier in case some of those tarballs disappear
> from their original location.
> 
> I think the first option is selectable from the installer, but I
> might be wrong. Otherwise, stop guix-daemon from herd and run it
> manually with your options.
> 
> Le 29 mars 2021 15:05:08 GMT-04:00, Charles Direg
>  a écrit :
> > Dear,
> >
> >How can I modify the flags that any program is compiled with within
> >guix? That
> >is, I can allow in the gnu-build-system to modify it globally so
> >that I can
> >add the build flags to any package, for example, add the flags -O2
> >-march=native -mtune=native so global as I already mentioned, so that
> >these
> >are added to each package at the time of compilation, this would not
> >be within the guix development environment, because what I want is
> >that this
> >compilation is natively for my pc.
> >
> >As a second question, how could I set the --no-susbtitutes option
> >when installing the guix system from ISO, since I would like all
> >installed packages to be compiled natively first?
> >
> >I really appreciate your kind time and I look forward to your
> >responses.
> >
> >Sincerely,
> >~ Abraham Huerta  

I'm mostly guessing here, but wrapping gcc with a script that sets the
options you want might work. Could try creating a gcc-toolchain that
is set up the way you want it (don't even have to recompile, like i
said, just create a wrapper script that calls the original toolchain)
and then run guix build --with-toolchain=gcc-impure-native-toolchain

At least that's how I'd get started.

You could also just modify the toolchain package, but then you'd have
to recompile everything.

Anyways, if you want -march=native optimisations, there is some recent
discussion around some new GCC feature that detects CPU features at
runtime. The high performance computing (HPC) related developers are
very interested in using it in Guix.

Utility for copying environments

[raingloom]

Tale as old as time: I was fed up with some software and instead of
patching it I created a workaround. But I think it could be genuinely
useful for some other folks too.
My main use case is gonna be opening new kakoune windows, but it should
be useful more generally as well.

https://git.sr.ht/~raingloom/with-env

Patches and feedback are welcome, as usual.

ps.: please forgive my typos. i really should not have stayed awake to
finish this.

Re: Self-contained GuixSD Installer

[raingloom]

On Sun, 21 Mar 2021 18:56:05 -0700
Gurjeet Singh  wrote:

> Does a self-contained GuixSD installer exist? I tried running GuixSD
> in a VM (in VBox, on macOS), and for that I downloaded the ISO image.
> The ISO image, after a few prompts, then tries to install everything
> from the internet.
> 
> If everything is being downloaded and installed from the internet, why
> does the image have to be so huge (~500MB
> guix-system-install-1.2.0.x86_64-linux.iso.xz)?
> 
> Is it possible to deliver the /gnu/store on the ISO so that a minimal
> system can be installed and started, without having to connect to the
> Internet? The user is free to install and upgrade packages from the
> internet, but they should be able to run GuixSD without the Internet
> being a hard requirement.
> 
> Best regards,
> --
> Gurjeet Singh http://gurjeet.singh.im/
> 

I think the installer does a `guix pull` before running `guix system
init`, so it has to download fresh packages.
I haven't used the graphical installer, but at leat that's how the old
school CLI install worked, at least as far as I remember.

You could just not guix pull, or if you did, you could pull the
specific commit that was used to build the system.

At least in theory.

Re: A Critique of Shepherd Design

[raingloom]

On Fri, 19 Mar 2021 17:33:57 +
raid5atemyhomework  wrote:

> The Shepherd language for describing actions on Shepherd daemons is a
> Turing-complete Guile language.  Turing completeness runs afoul of
> the Principle of Least Power.

Erlang is turing complete and yet it is famously excellent at managing
services in a robust way.

Re: [opinion] CVE-patching is not sufficient for package security patching

[raingloom]

On Sat, 20 Mar 2021 12:19:11 +0100
Ludovic Courtès  wrote:

> Hi,
> 
> Mark H Weaver  skribis:
> 
> > Ultimately, I gave up.  In my opinion, Guix has never achieved
> > usability as a desktop system on non-Intel systems.  Therefore, the
> > Guix community is unable to attract many developers who want a
> > distro that supports non-Intel systems well.  Our community has
> > thus become dominated by Intel users, and there's unsufficient
> > political will to adopt policies that would enable us to provide a
> > usable system for non-Intel users.  
> 
> A practical problem that’s been mentioned repeatedly is lack of
> ci.guix hardware for non-Intel architectures: please everyone,
> consider helping the project find either sponsors or companies that
> sell fitting hardware, along with a plan to host it and maintain it
> over time!
> 
> Ludo’.
> 

What about a Liberapay for Guix? Could also be used to pay developers.

Sharing system users for related services

[raingloom]

I'm packaging the Molly Brown Gemini server and I'm trying to play nice
with the already packaged gmnisrv.
Should the two use the same service name and system users? Most users
probably won't want to run both servers at the same time, so the former
seems like a good idea. And the latter would be preferable because if
they use the same certs, %gmnisrv-activation will trample over the
permissions when they do want to run both for some reason.

So should I just reuse %gmnisrv-accounts or should they both use a
shared %gemini-server-accounts?

Re: [SPITBALL] Jehanne as another kernel option / porting target

[raingloom]

On Fri, 19 Mar 2021 20:42:19 +0100
Vincent Legoll  wrote:

> + '(#:tests? #f ;; No need for tests when you have formal proof
> of correctness
In just about any talk about Idris and Type Driven Development, Edwin
Brady always starts with "you still need tests".

[SPITBALL] Jehanne as another kernel option / porting target

[raingloom]

http://jehanne.io/2021/01/06/gcc_on_jehanne.html

Should support more architectures than Hurd ;)

Anyways, just throwing this out there, as I - and I imagine every
other contributor - have some more pressing projects.

It probably wouldn't be able to run most packages and services without
some significant work but it could maybe still use Guix as a package
manager.

seL4 would be cool too.

Rust and parametric packages

[raingloom]

I'm re-reading the threads about Rust packaging and I realized there
might be a solution to the build artifact reuse problem.

As I understand it, the problem is that crates can be compiled with any
number of features enabled or disabled. If this and the compiler
version are truly the only variables to consider, we could just lift
the features to the package level, right?

https://lists.gnu.org/archive/html/guix-devel/2021-02/msg00269.html

Re: FOSDEM + Guix Day: hurrah!

[raingloom]

On Thu, 11 Feb 2021 12:14:34 +0100
Léo Le Bouter  wrote:

> On Thu, 2021-02-11 at 11:07 +0100, Ludovic Courtès wrote:
> > Hello Guix!
> > 
> > With all the excitement and activity these days, I almost forgot to
> > say
> > it: *big thanks* to Pjotr and Manolis for organizing the FOSDEM
> > “Declarative and Minimalistic Computing” devroom, with a great
> > program!
> > It was a delightful day for me, so thanks also to the speakers and
> > to those who hosted the sessions.
> > 
> > Thanks again to everyone who participated in the Guix Day!  It’s
> > always
> > pleasant to be able to discuss things live, especially these days.
> > 
> > Cheers,
> > Ludo’.
> >   
> 
> It was very exciting and I wish we could do more of those online
> meetings on a more regular basis. It's key to motivation for me.
> 
> Too bad nothing was recorded with Big Blue Button (it has a recording
> feature).

Wait what???
I was under the impression that talks would be recorded. So they...
weren't??? At all??? Am I waiting for an upload in vain?

[PATCH] WIP snapper fixes and snapperd service

[raingloom]

uot;
+   ,(package-version docbook-xsl)
+   "/xhtml/docbook.xsl")))
+ (substitute* "doc/manpages.xsl"
+   (("http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl;)
+(string-append (assoc-ref inputs "docbook-xsl")
+   "/xml/xsl/docbook-xsl-"
+   ,(package-version docbook-xsl)
+   "/manpages/docbook.xsl")))
+ #t))
+ (add-before 'build 'patch-makefiles
+   (lambda* (#:key outputs #:allow-other-keys)
+ (let ((out (assoc-ref outputs "out")))
+   (substitute* "client/Makefile.am"
+ (("libexecdir = /usr/lib/snapper")
+  (string-append "libexecdir = " out
+ "/lib/snapper")))
+   ;; TODO: Why is $(DESTDIR) not doing the right thing for scripts?
+   ;; Changing it in #:make-flags produces the wrong behaviour.
+   (substitute* "scripts/Makefile.am"
+ (("\\$\\(DESTDIR\\)") out)
+ (("(pam_snapperdir = )/usr(/lib/pam_snapper)" _ before after)
+  (string-append before out after)))
+   (substitute* "data/Makefile.am"
+ (("\\$\\(DESTDIR\\)") out))
+   (substitute* "pam/Makefile.am"
+ (("(securelibdir = )\\$\\(shell echo /`basename \\$\\(libdir\\)`/security\\)" _ before)
+  (string-append before out "/lib/security"
+ #t))
+ (add-after 'install 'clean-up-systemd-services
+   (lambda* (#:key outputs #:allow-other-keys)
+ ;; TODO: Maybe we should not remove everything, we need dbus.
+ (delete-file-recursively
+  (string-append (assoc-ref outputs "out") "/usr"))
+ #t)
+(native-inputs
+ `(("pkg-config" ,pkg-config)
+   ("gettext" ,gettext-minimal) ;for msgfmt
+   ("libxslt" ,libxslt)
+   ("docbook-xsl" ,docbook-xsl)
+   ("autoconf" ,autoconf)
+   ("automake" ,automake)))
+(inputs
+ `(("libmount" ,util-linux)
+   ("dbus" ,dbus)
+   ("acl" ,acl)
+   ("boost" ,boost)
+   ("libxml2" ,libxml2)
+   ("btrfs-progs" ,btrfs-progs)
+   ("e2fsprogs" ,e2fsprogs)
+   ("linux-pam" ,linux-pam)))
+(home-page "http://snapper.io/;)
+(synopsis "Manage BTRFS and LVM snapshots")
+(description " Snapper is a tool for Linux filesystem snapshot
+management.  Apart from the obvious creation and deletion of snapshots, it can
+compare snapshots and revert differences between snapshots.  In simple terms,
+this allows root and non-root users to view older versions of files and revert
+changes.
+
+The features include:
+
+@itemize
+@item Manually create snapshots.
+@item Automatically create snapshots.
+@item Automatically create timeline of snapshots.
+@item Show and revert changes between snapshots.
+@item Works with btrfs, ext4 and thin-provisioned LVM volumes.
+@item Supports Access Control Lists and Extended Attributes.
+@item Automatic cleanup of old snapshots.
+@item Command line interface.
+@item D-Bus interface.
+@item PAM module to create snapshots during login and logout.
+@end itemize\n")
+(license license:gpl2)))
+
 (define-public f2fs-tools-1.7
   (package
 (name "f2fs-tools")
-- 
2.30.0

>From e7e454785b7d449376448485643e704e72a20d9e Mon Sep 17 00:00:00 2001
From: raingloom 
Date: Wed, 6 Jan 2021 22:13:14 +0100
Subject: [PATCH 2/3] gnu: WIP update Snapper.

---
 gnu/packages/linux.scm | 78 --
 1 file changed, 52 insertions(+), 26 deletions(-)

diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 6bc3f1e52a..16279e50c3 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -74,6 +74,7 @@
   #:use-module (gnu packages acl)
   #:use-module (gnu packages admin)
   #:use-module (gnu packages algebra)
+  #:use-module (gnu packages attr)
   #:use-module (gnu packages audio)
   #:use-module (gnu packages autotools)
   #:use-module (gnu packages backup)
@@ -5084,15 +5085,15 @@ obviously it can be shared with files outside our set).")
 (define-public snapper
   (package
 (name "snapper")
-(version "0.8.2")
+(version "0.8.15")
 (source (origin
-  (method url-fetch)
-  (uri (string-append "ftp://ftp.suse.com/pub/projects/snapper/snapper-;
-  version
- 

Re: Snapper DBus woes

[raingloom]

On Fri, 08 Jan 2021 13:54:06 -0500
"Leo Famulari"  wrote:

> Can you share with us the full error messages you got? And a more
> full description of what you tried?
> 
> On Thu, Jan 7, 2021, at 20:16, raingloom wrote:
> > Hiya folks.
> > 
> > I'm trying to finish up that Snapper package that Pierre Neidhardt
> > abandoned and am also running into DBus issues.
> > Could someone who knows DBus look into it? I really think we should
> > get this package working on Guix sooner rather than later, because
> > right now there is no way to protect against an accidental `rm -rf
> > $HOME` without a full backup.
> > This is my branch:
> > https://git.sr.ht/~raingloom/guix-source/tree/raingloom/snapper
> > 
> >  

That part is taken care of now. Turns out I needed to add a service
that extends D-Bus and run snapperd from there.
Now I just have to figure out how to actually create a snapshot.

Snapper DBus woes

[raingloom]

Hiya folks.

I'm trying to finish up that Snapper package that Pierre Neidhardt
abandoned and am also running into DBus issues.
Could someone who knows DBus look into it? I really think we should get
this package working on Guix sooner rather than later, because right
now there is no way to protect against an accidental `rm -rf $HOME`
without a full backup.
This is my branch:
https://git.sr.ht/~raingloom/guix-source/tree/raingloom/snapper

Re: BUG: Re: guix environment: error: cannot create container: unprivileged user cannot create user namespaces

[raingloom]

On Mon, 07 Dec 2020 05:51:05 +0900
yasu  wrote:

> Hi Zimoun,
> 
> I tried as you suggested but it didn't work...
> 
> 
>root@guix ~# echo "kernel.unprivileged_userns_clone = 1" >
>/etc/sysctl.d/local.conf
>-bash: /etc/sysctl.d/local.conf: No such file or directory

This could mean you have to create the sysctl.d directory.
Try running this:
```
# mkdir -p /etc/sysctl.d/
# echo "kernel.unprivileged_userns_clone = 1" > /etc/sysctl.d/local.conf
```

Re: Thank you for participating in the Guix Day!

[raingloom]

On Wed, 25 Nov 2020 23:17:57 -0500
Leo Famulari  wrote:

> On Wed, Nov 25, 2020 at 11:31:53PM +0100, raingloom wrote:
> > Oh yea, regarding that, I really think it would have made a whole
> > lot more sense if people just sent in a photo, instead of DDoS-ing
> > the network.  
> 
> I don't know how BBB works nor did I measure it, but one can expect a
> videochat feed to require basically the same amount of bandwidth as
> watching a Youtube video.

Since people reported everyone turning their cameras on significantly
degrading performance, that is unlikely to be an accurate analogy.
My guess is that it's more similar to watching N simultaneous streams,
where N is the number of people with active webcams.

Re: Thank you for participating in the Guix Day!

[raingloom]

On Thu, 26 Nov 2020 00:00:17 +0100
zimoun  wrote:

> Hi,
> 
> On Wed, 25 Nov 2020 at 23:28, raingloom  wrote:
> >> On Tue, Nov 24, 2020 at 09:26:37PM +0100, raingloom wrote:  
> >> > My only issue was that I had to reconnect audio every 3-4
> >> > minutes, sometimes having to do a full reload. BBB was nice, but
> >> > apparently it's still pretty heavy.
> 
> What do you mean by “reconnect audio”?
> 
> Since your browser looks usual, maybe it comes from the configuration
> of your audio.  I do not know, just guessing.
> 
> 
> All the best,
> simon

There is an icon to turn audio on or off.

I'm starting to suspect my IceCat was (and still is) a version behind,
so that might have caused it. (still is because substitutes aren't up
yet)

Gosh, I just love how stable web browsers are. :)))

Re: Thank you for participating in the Guix Day!

[raingloom]

On Wed, 25 Nov 2020 11:47:46 +0100
Michael Rohleder  wrote:

> raingloom  writes:
> > My only issue was that I had to reconnect audio every 3-4 minutes,
> > sometimes having to do a full reload. BBB was nice, but apparently
> > it's still pretty heavy.  
> 
> I had a similar issue, but only in the break where we had lots of
> webcams: After about 5 or 6 webcams, my (slow) net connection became
> satturated and BBB seems to loose more and more
> informations/connections/gets out of sync.  After that, audio didn't
> work anymore (but was still transmitted) and I had to
> reconnect/reload.
> 

Oh yea, regarding that, I really think it would have made a whole lot
more sense if people just sent in a photo, instead of DDoS-ing the
network.

Re: Thank you for participating in the Guix Day!

[raingloom]

On Tue, 24 Nov 2020 22:53:21 -0500
Leo Famulari  wrote:

> On Tue, Nov 24, 2020 at 09:26:37PM +0100, raingloom wrote:
> > My only issue was that I had to reconnect audio every 3-4 minutes,
> > sometimes having to do a full reload. BBB was nice, but apparently
> > it's still pretty heavy.  
> 
> Can you say what web browser you were using? Bonus points if you can
> give us the exact version, assuming it's from Guix. And what kind of
> computer did you use?

IceCat, from a recent commit. Couldn't try with Chromium.
version string: 78.4.1-guix0-preview1
store path:
/gnu/store/pzcqndbiwzs1gddlkmsbqalf3r6yfx5d-icecat-78.4.1-guix0-preview1

The hardware has about 4 gigs of RAM, and earlyoom was running, but I
can only see one IceCat related event in its log, but even that might
be unrelated. I can't really tell, because the log has no timestamps.

Re: Thank you for participating in the Guix Day!

[raingloom]

On Tue, 24 Nov 2020 03:00:56 +0100
Julien Lepiller  wrote:

> Hi Guixers!
> 
> Thank you for your participation to the Guix Days on this November
> 22nd. We were around 60 people at all time, for a total of over 80
> people during the day.  We hope to see you again soon on IRC or the
> mailing lists!
> 
> Warm thanks to the presenters who did wonders in a very short
> timeframe, as well as to our moderators. :-)
> 
> The day was really rich for us.  Fruitful discussions happened and it
> is always amazing to see the diversity in action.  Hope that you
> enjoyed!
> 
> Since this is the first time we tried to organize an online event,
> we know that some things were good, others were bad, and maybe even a
> couple were ugly for you.  We want to hear from you.  What did you
> enjoy, what should be avoided, what could be improved for next time?
> 
> Feel free to pragmatically dream and help us sketch the next event!
> 
> You might think of this event as a `--dry-run', and we think it was
> very successful.  Let's prepare the `--rounds=2'. ;-)
> 
> If any of you have taken some notes during the event, it would be nice
> to summarize the discussions that happened in a blog post (and in
> `maintenance/doc').
> 
> Please drop us an email to guix-devel@gnu.org.  If you are shy, send
> it to guix-d...@gnu.org, a private alias reaching only the organizers
> of the event (Julien Lepiller (roptat) and Simon Tournier (zimoun))
> and the maintainers.
> 
> We'd like to address a special thanks to Fosshost, for hosting the
> BigBlueButton instance.  It worked amazingly well!
> 

My only issue was that I had to reconnect audio every 3-4 minutes,
sometimes having to do a full reload. BBB was nice, but apparently it's
still pretty heavy.

Re: A plan for parameterized packages

[raingloom]

On Sun, 15 Nov 2020 21:46:58 +0100
Danny Milosavljevic  wrote:

> Hi Ludo,
> 
> nice feature!
> 
> On Sun, 15 Nov 2020 17:33:28 +0100
> Ludovic Courtès  wrote:
> 
> > An important question: do we have examples of packages for which
> > we’d like to have parameters?
> 
> For the embedded/flash rom side:
> 
> * Enable/disable building the documentation.  I really don't need a
> 40 MiB manual stored onto a 16 MiB firmware flash chip.  If that's
> better done as an extra output, fair enough.
> ..

Alpine already achieves an incredibly tiny install size by splitting
packages into many outputs. We could and should do the same.
As far as I know, they do not have parameterized packages.

Re: Continuous integration - automatic EMAIL

[raingloom]

On Wed, 7 Oct 2020 17:39:35 +0200
Danny Milosavljevic  wrote:

> Hi,
> 
> please, let's improve building and testing processes.
> 
> Please, can we have the build servers send build failures to
> guix-devel instead of hoping that people check manually?  I have
> other things to do in my life than to poll random servers every few
> hours.
> 
> If you don't want to send e-mail on all failures (probably an
> overwhelming flood at first--that's how bad the current state is!),
> then I suggest to:
> 

Could an RSS feed work?

Or just don't send it to devel, make a new list for it. Or send it to
bugs.

Secrets in (generated) configs. How to deal with them?

[raingloom]

Hi all!

I'm trying to package Yggdrasil as a Guix service and I took a look at
what NixOS does and they actually don't simply generate the config in
the store, instead it's combined with another input of the service and
the combined JSON is fed to Yggdrasil on stdin.

Is this how I should do it as well? Or maybe the Guix store can make
some outputs private?

Git repos with large submodules

[raingloom]

Hey all!

So, I recently gave a go to packaging EDK2 on my channel, and found out
that it requires several submodules, including OpenSSL, which take up
quite a bit of space and take way longer to download than necessary.

Since I couldn't find a way to shallow-init the submodules, I added
them as separate origins and copied / symlinked them after the unpack
phase.

Is there a better way to do this? I don't see any equivalent of
--shallow-submodules in guile-git or libgit2.

I was thinking of writing a bit of Scheme to handle importing git repos
with their submodules as origins, but that feels like a rather ugly
hack.
Maybe libgit or guile-git would be the best layer to fix this at.

Re: Guix scheme code being recompiled when target ARCH changes

[raingloom]

On Fri, 15 May 2020 10:33:14 +0200
Vincent Legoll  wrote:

> And as an additionnal question, are the ./pre-inst-envs needed on
> all the CLIs above ?

No, only the guix invocations need it.
make, ./configure, ./bootstrap, those don't need it.
But guix always does.

Re: Towards a graphical installer?

[raingloom]

On Mon, 11 May 2020 18:29:09 +0200
"pelzflorian (Florian Pelz)"  wrote:

> On Mon, May 11, 2020 at 03:27:29PM +0200, Mathieu Othacehe wrote:
> > A way to move forward with the installer could be to propose an ISO
> > image starting a desktop-environment by default. […]  
> 
> Thank you for investigating.
> 
> I suppose keyboard input method (IME) support is a reason why someone
> might wish to use an Xorg-based installer.  Are there other reasons?
> What are the reasons for a real desktop environment; is the goal to
> offer a live image?  Previously I would have thought a virtual console
> is more likely to work everywhere, but kmscon has the same
> requirements as Xorg and without kmscon we’d lose i18n.
> 
> Regards,
> Florian
> 

Can the TUI installer be used with a screen reader? AFAIK it can't but
I'd love to be proven wrong.
Anyway, there are also other accessibility options that are useful. High
contrast, magnifier, sticky keys, etc. GNOME provides these.
Even if you aren't blind or disabled in general, you might just have to
install an operating system without a working screen one day.

Re: Medium-term road map

[raingloom]

On Sat, 25 Apr 2020 15:37:44 +0200
Ludovic Courtès  wrote:

> Hello Guix!
> 
> We released 1.1.0, but what’s coming next?  What would you like to
> see?
> 
> There are many exciting things being developed and great ideas
> floating around.  For myself, I feel like focusing on “consolidating”
> what we have in the coming weeks.  Here are the areas I hope to focus
> on (and embarking as many of you as possible :-)):
> 
>   1. Authentication.  I want to finally provide a standardized
> mechanism to allow channels to be authenticated upon ‘guix pull’.
> “make authenticate” was a first milestone, let’s get it done.  See
>  .
> 
>   2. Performance.  There are many things we can improve there, first
> and foremost: the “Computing derivation” part of ‘guix pull’, Guile’s
>  compiler terrible time and space requirements, further optimizing
>  core operations like ‘package-derivation’, as well as low-level
>  stuff as described at .
> 
>  Related to that is the question of substitute availability,
> another major hindrance to usability.  We should address this both in
> the build farm (reducing the
>  time-to-push-to-time-of-substitute-availability, tracking random
>  build failures), and on the client side (can we provide ways for
>  users to pull to a commit that won’t require them to build
>  everything from source, while not compromising on their
> security?).
> 
>   3. G-exps.  We should really finish the migration to gexps, as in
> the ‘wip-build-system-gexp’ branch, and adjust our APIs accordingly.
> 
>   4. User interface.  Let’s get our act together with ‘guix shell’ and
>  ‘guix run-script’, and let’s address other annoyances that
>  newcomers keep stumbling upon!
> 
> Thoughts?
> 
> Happy hacking!  :-)
> 
> Ludo’.
> 

I would love to see better tools for debugging boot time issues and a
way to not have to rewrite the entire target directory during a
repeated `guix system init` that only changes a few things. I don't
want to waste my SSD's write cycles. And it's also pointlessly slow.

Right now the debugging experience in the Guile rescue shell is...
ugh. Not great. GRUB 0.9 has a CLI that's easier to navigate.
What I'd like to see:
 - tab autocomplete
 - recovery from errors
The latter is quite hard, because certain steps don't work well when
run multiple times. For example, if you want to re-run the procedure
that mounts essential file systems, it will complain that /dev is
already mounted, instead of just realizing that it can skip mounting it.

Something equivalent to `arch-chroot` would also be nice, again for
debugging. I'm sure there is some way to make modifications to a store
on a different device, but it's not easy to find.

I've written something simple that adresses the overwriting issue, but
since it's a modification to Guix itself, it triggered a full rebuild
of the world, and I did not have the patience to sit through that, so I
just installed a more minimal system instead.

Re: initrd: why do we need static linking?

[raingloom]

On Tue, 05 May 2020 11:33:17 +0200
Ludovic Courtès  wrote:

> Hi,
> 
> Ricardo Wurmus  skribis:
> 
> > why do we need to link packages statically to include them in the
> > initrd?  Can’t we just copy the package closure into the initrd?  
> 
> You can refer to any package in the initrd gexp and its whole closure
> is automatically included in the initrd.
> 
> However, to minimize the size of the initrd (it must fit in memory,
> uncompressed), we typically use stripped statically-linked packages.
> 
> HTH!
> 
> Ludo’.
> 

It'd actually be nice if static linking could be used in places other
than the initrd. I'm experimenting with some old resource constrained
machines, and it made me realize just how much space even a basic `guix
pull` can take up.

Re: Guix System video review on YouTube

[raingloom]

On Mon, 27 Apr 2020 12:11:05 +0200
Jonathan Brielmaier  wrote:

> $ echo "hello"
> hello
> $ guix install emacs
> 
> Then while installing emacs, try to reach the hello. It will be tricky
> as every new output line from `guix install emacs` will reset you to
> the bottom of your terminal. That's annoying.
> 

This is not related to the distribution, it's a terminal emulator
default. The behavior is the same in every other distribution I've used.
If they think this is a bad default, they should write on the
terminal emulator's bug tracker.

But then again, you usually want new (possibly quite important)
messages to catch the user's attention, so I'd say it's a good default.

Anyways, the option is trivial to change in the settings. You don't
even have to look too hard.

> So I would propose an interface like:
> $ guix search vim
> | Name  | Synopsis   | Version  | Outputs
> |
> +---++--+-+
> | vim   | Text editor based on vi| 8.2.0411 | out
> | | vim-airline   | ... [...]

Please don't, ASCII formatting always messes things up. Use the
terminal for text. If you want a more visual package manager, don't use
a CLI tool. A proper GUI will be more accessible.

As one example, ASCII formatting makes screen readers a lot harder to
use.

Re: Wacom tablet issues

[raingloom]

I tried sway and it's broken there too. Not sure if I started it up 
correctly though, as I just opened it on a separate virtual terminal.


On Thu, Mar 5, 2020 at 18:27, raingloom  wrote:

Well, udevadm shows it, but only as a single device instead of three.

On Thu, Mar 5, 2020 at 18:25, pelzflorian (Florian Pelz) 
 wrote:

On Thu, Mar 05, 2020 at 05:12:57PM +0100, raingloom wrote:
 What about i3? Because that's what I used on all three distros. 
(also GNOME

 on Guix)


i3 is not Wayland.  Note that I only remember GTK people say it works
differently.  What I said about Wayland is a possible reason why Arch
behaves differently if you used Wayland on Arch.  In theory it should
be possible to make old xf86-input-wacom work too, I do not know how
and have no wacom tablet at hand.  Then again, I do not know why
udevadm does not show the device.

Regards,
Florian

Re: Wacom tablet issues

[raingloom]

Well, udevadm shows it, but only as a single device instead of three.

On Thu, Mar 5, 2020 at 18:25, pelzflorian (Florian Pelz) 
 wrote:

On Thu, Mar 05, 2020 at 05:12:57PM +0100, raingloom wrote:
 What about i3? Because that's what I used on all three distros. 
(also GNOME

 on Guix)


i3 is not Wayland.  Note that I only remember GTK people say it works
differently.  What I said about Wayland is a possible reason why Arch
behaves differently if you used Wayland on Arch.  In theory it should
be possible to make old xf86-input-wacom work too, I do not know how
and have no wacom tablet at hand.  Then again, I do not know why
udevadm does not show the device.

Regards,
Florian

Re: Wacom tablet issues

[raingloom]

What about i3? Because that's what I used on all three distros. (also 
GNOME on Guix)


On Thu, Mar 5, 2020 at 17:10, pelzflorian (Florian Pelz) 
 wrote:

Also note that GNOME on Wayland may work better than GNOME on Xorg
with regard to wacom/libinput/GTK.  I presume on Arch you used
Wayland.

Regards,
Florian

Wacom tablet issues

[raingloom]

I'm having trouble properly setting up my Wacom Intuos CTH-480 tablet. 
It is recognized as a tablet and pressure sensitivity is working, but 
the eraser is not recognized as a separate input device. I used it in 
Arch, where it worked flawlessly, so it's not a driver bug.


`libwacom-list-local-devices` shows them, but `xsetwacom --list 
devices` does not.


I think it is a udev issue.

I ran `udevadm info $(libwacom-list-local-devices | grep 'Device node' 
| cut -f 4- -d ' ')` in both Guix and a NixOS VM and in Guix it seems 
to only show a single device, while in Nix it shows 3.


I managed to get the libwacom udev rules in my system config, at least 
I think I did, since the following files exist:


```
/run/booted-system/profile/lib/udev/rules.d/65-libwacom.rules
/run/booted-system/profile/lib/udev/rules.d/wacom.rules
```

Not sure how to proceed. Any tips?

should auto updaters be disabled?

[raingloom]

I've been using gPodder and Gajim for a while and right now both are 
notifying me about new versions, gPodder about an update to itself and 
Gajim about an update to OMEMO. Both the OMEMO plugin and gPodder are 
managed by Guix, so the builtin updaters don't really have any business 
mucking with my setup.


I want to patch it out of gPodder, but what do others think? Would it 
make more sense to add a configuration option and fix it upstream?


For Gajim, I'm not yet sure, since not all plugins are managed by the 
distro.

Re: Package file indexing

[raingloom]

On Thu, 2020-01-02 at 23:50 +0100, zimoun wrote:
> Hi,
> 
> On Thu, 2 Jan 2020 at 18:12, Pierre Neidhardt 
> wrote:
> 
> > Last but not least: previously we suggested adding a subcommand
> > like
> > "guix which" or "guix filesearch".  In another thread, Simon
> > suggested
> > that this would be a bad idea and factoring the file search into
> > "guix
> > search" is probably better.
> 
> It appears to me better for 2 reasons:
>  1. because obviously "filesearch" is a kind of "search" ;-) so it
> adds consistency.
>  2. because it allows (in the near future) mixed research: "guix
> search bin/hg python" applying the "python" filter only to the
> packages returned by "bin/hg". And "guix search python bin/hg" search
> the binary file "hg" only to the packages matching "python.
> 

What about files in root (so, ones with no slashes in their path, at
least in your syntax) and files you don't know the full path of, only
their basename?

Do you search for every word as a file path, just in case it might be
one?

To avoid confusion, I think this should be an option/subcommand of
search. Something like -path and -name in find(1).