Re: Updating the “pre-push” Git hook

[Efraim Flashner]

On Sun, May 24, 2020 at 11:45:34PM +0200, Ludovic Courtès wrote:
> Hi,
> 
> Efraim Flashner  skribis:
> 
> > On Fri, May 22, 2020 at 10:44:48PM +0200, Ludovic Courtès wrote:
> >> Hello Guix!
> >> 
> >> I think we should change our pre-push hook as shown below.
> >> 
> >> Thoughts?
> >> 
> >> Thanks,
> >> Ludo’.
> >> 
> >
> > (ins)efraim@E5400 ~$ type -P make
> > (ins)efraim@E5400 ~$ command -v make
> >
> > I'd need to run 'guix environment --ad-hoc make -- git push'
> 
> You’d need to run ‘git push’ from a full Guix development environment.
> Do you think it could be a problem?

I'd probably run 'guix environment guix -- git push origin master' and
view it as an additional safe guard to not push to the wrong branch or
something, similar to how I view the password on the key. I bet there's
an option to create a repo-specific alias in .git/config so that 'git
push' will run inside 'guix environment guix'.

I'm not convinced that my case is unique or that it should hold back the
change. How does it work if 'make authenticate' fails?

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: best practise between git-fetch vs url-fetch?

[Jack Hill]

On Sun, 24 May 2020, Ludovic Courtès wrote:

[…]


Another improvement we could make here is improving the message about
Software Heritage in guix lint. Most of the other messages it emits
are things that the author of a package should consider improving. If
the Software Heritage message is less actionable, let's make that
clearer so that people don't think there is a problem with their
package definition.


What message would you suggest?


How about expanding section 7.7 "Invoking Guix Lint" in the manual to 
include a paragraph of advice in the explanation for each checker. For 
example, the advice could be could be "change the source to use git-fetch" 
for "source-unstable-tarball", "exercise judgment on the long-term 
availability of software sources. We think that code hosted on the GNU ftp 
servers will be around for a long time, but code on people's personal 
websites may not be. The greater the risk of the software disappearing, 
the more important is is to use git-fetch in sources so we can trigger 
archiving at Software Heritage" for "archival", and "double check whether 
these inputs really should be native [link to appropriate section of the 
manual]. If they really need to be, leave a comment in the code briefly 
explaining why to help future contributors" for "inputs-should-be-native".


Obviously, those aren't fit to be included in the manual as is, but 
hopefully they give a good idea of what I was thinking. guix lint could 
remind people to check the manual for advice when it detects lint.


That said, I am open to other options, including that this isn't a problem 
that we need to solve.


Best,
Jack

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: Updating the “pre-push” Git hook

[Ludovic Courtès]

Hi,

Efraim Flashner  skribis:

> On Fri, May 22, 2020 at 10:44:48PM +0200, Ludovic Courtès wrote:
>> Hello Guix!
>> 
>> I think we should change our pre-push hook as shown below.
>> 
>> Thoughts?
>> 
>> Thanks,
>> Ludo’.
>> 
>
> (ins)efraim@E5400 ~$ type -P make
> (ins)efraim@E5400 ~$ command -v make
>
> I'd need to run 'guix environment --ad-hoc make -- git push'

You’d need to run ‘git push’ from a full Guix development environment.
Do you think it could be a problem?

Thanks,
Ludo’.

Re: Updating the “pre-push” Git hook

[Ludovic Courtès]

Hi,

Ricardo Wurmus  skribis:

> Leo Famulari  writes:
>
>> On Fri, May 22, 2020 at 10:44:48PM +0200, Ludovic Courtès wrote:
>>> Hello Guix!
>>> 
>>> I think we should change our pre-push hook as shown below.
>>> 
>>> Thoughts?
>>
>> Is it fast? :)
>
> This depends on how many commits you have previously authenticated.  But
> even the slow case is pretty fast.  I just authenticated 16,290 commits
> in less than a minute.  Regular contributors won’t have to authenticate
> nearly as many commits.
>
> For 0 commits it takes 4 seconds.

Hmm for me it’s more like 0 to 1 second, and it’s ~20s to authenticate
14K commits:

  https://issues.guix.gnu.org/issue/22883#61

Could you try:

  mv ~/.cache/guix/authentication/channels/guix{,.bak}
  time make authenticate
  mv ~/.cache/guix/authentication/channels/guix{.bak,}

?

Anyway, for normal usage, it should be faster than the shell script.
Also, it performs a different job: the shell script would only check
whether a commit is signed at all.

Well, give it a try and lemme know!

Ludo’.

Re: Release Guix 1.1.1?

[Ludovic Courtès]

Hi,

Mathieu Othacehe  skribis:

>> What do y'all think about targeting a 1.1.1 release a few weeks from
>> now?
>>
>> Any milestones we should try to complete before an eventual release?
>
> This seems like a very good idea. It would be good if this release could
> include:
>
> * A new shepherd release fixing this bug[1].

Coming soon!  (See also ).

> * A Cuirass update allowing to download disk-images built on top of
>   master[2].

Yay!

Initially I was hoping to get support for authenticated channels in that
release¹, but I don’t know if it can be ready and well-tested on time.
We’ll see.

Thanks,
Ludo’.

¹ https://issues.guix.gnu.org/22883

Re: Can we increase the print width/column in daemon backtraces

[Ludovic Courtès]

Hi,

Pierre Neidhardt  skribis:

> This has stopped working for me a while ago.

What stopped working exactly?

Users are not supposed to see backtraces coming from the daemon or its
helpers (‘guix substitute’, ‘guix offload’, etc.).

Thanks,
Ludo’.

Re: “guix --help” should point to https://guix.gnu.org/help/

[Ludovic Courtès]

Hi,

zimoun  skribis:

> On Fri, 15 May 2020 at 12:20, Ricardo Wurmus  wrote:
>
>>   General help using GNU software: 
>
> I have never read this.  It is not welcoming for newcomers, IMHO.
>
> First sentence: "The Free Software Foundation does not provide
> technical support." I give up.
> Second paragraph: RTFM! Well, click, click again, I give up.
> Third: Lengthy explanations... about bug report. I give up.
> Fourth: After scrolling, click, click again, I give up.
> Or click to IRC, #guix is not mentioned, I give up.
>
> If someone reaches the help they needs by this mean, they is my hero! :-)

This is harsh, maybe unnecessarily so, but still a very valid criticism
of that page.  I guess that page was created with good intentions, but
it’s pretty much useless indeed.  :-/

Probably we should work on the GNU side to make that page more useful,
but we should also definitely print the relevant Guix URL.

Ludo’.

Re: Routing Guix services traffic trough Tor

[Ludovic Courtès]

Hey Brice, I think you forgot to type your reply below.  :-)

Ludo’.

Brice Waegeneire  skribis:

> On 2020-05-17 22:33, Ludovic Courtès wrote:
>> Hi Brice,
>>
>> Brice Waegeneire  skribis:
>>
>>> Today I played a bit with Tor and Guix, trying to fetch substitutes
>>> trough
>>> the Tor network as blaze_cornbread asked on IRC[0] how to do this.  I
>>> managed to get it working but in the end I don't think we should
>>> encourage
>>> people doing it this way, that's why I haven't submitted a patch to
>>> the
>>> cookbook for it.  Currently the only supported way to proxy traffic
>>> for
>>> 'guix-daemon' is by setting a HTTP proxy[1] the drawback is that DNS
>>> query
>>> will still be in clear and wont go trough the proxy in contrast to a
>>> SOCKS5
>>> proxy where the query will happen on the other side of the proxy.
>>
>> I don’t think that’s the case: when an HTTP proxy is in use, clients
>> make a CONNECT or GET HTTP request to the proxy, which resolves the
>> host
>> name on their behalf.  That’s why you can pass
>> ‘--substitute-urls=http://bp7o7ckwlewr4slm.onion’ and it Just Works.
>>
>> So I think you message could make a great section in the cookbook.  :-)
>>
>> Thanks,
>> Ludo’.

Re: MIPS support

[Ludovic Courtès]

Hey!

Efraim Flashner  skribis:

> On Mon, May 18, 2020 at 12:12:24AM +0200, Ludovic Courtès wrote:
>> Hi,
>> 
>> Leo Famulari  skribis:
>> 
>> > On Wed, May 06, 2020 at 06:27:31PM +0200, Vincent Legoll wrote:
>> >> From the manual or from the CI, to let the build farm do more useful 
>> >> things
>> >> I'm not against, but is it really making maintenance difficult by still 
>> >> being in
>> >> the codebase ?
>> >
>> > It's not really a maintenance burden currently since we don't actually
>> > build or maintain the Guix on MIPS at all.
>> >
>> > I think this discussion is evidence that people find the situation a bit
>> > confusing. When I am looking into a project, I find it demotivating to
>> > read documentation about features that may or may not work — it's best
>> > when the documentation accurately reflects what the software can do.
>> 
>> Right, that was my point: let’s remove mentions of MIPS from the manual
>> and from ‘configure.ac’ so people have the right expectations.
>> 
>> Thoughts?
>
> So change it so that mips needs '--with-courage' but not remove the
> bootstrap binaries from the code?

Yes.  (The code has references to those binaries but it no longer has
the binaries themselves.)

> Do we want to fully remove the mention of mips as a supported platform
> or change it to "in the past we had an active mips64el port which is
> in need of more attention to bring it back to a fully supported
> platform. Help wanted!"

Do we really want to call for help in this area?  To me, we just remove
it, and if there’s interest again in this architecture, people might
happily find that part of the work has already been done.

Would you like to send a patch?

Ludo’.

Re: Exact same 'call-with-temporary-directory' defined twice?

[Ludovic Courtès]

Hi,

zimoun  skribis:

> On Sun, 17 May 2020 at 23:53, Ludovic Courtès  wrote:
>
>> > Naively: does it make sense to move it to "guix/build/utils.scm"?
>>
>> No because it depends on (guix build syscalls) for ‘mkdtemp!’ and
>> there’s currently that assumption that (1) (guix build utils) can be
>> used on a statically-linked Guile, and (2) it has no dependencies.
>
> Thank you for the explanations.  I am not sure to understand the
> assumption (1) but never mind.

Regarding (1): a statically-linked Guile cannot call ‘dynamic-link’ to
access libc symbols, so it cannot use FFI bindings to libc such as those
in (guix build syscalls).

HTH!

Ludo’.

Re: [PATCH] Add Tor client only package definition

[Ludovic Courtès]

Hi Andre,

Andre Batista  skribis:

> Starting on version 0.4.3.5, Tor provides a configuration flag to
> disable relay code (--disable-module-relay). Considering most
> people are running clients, not relays, I thought it would be
> nice for guix to have a client-only package definition (maybe
> it could even be the default?). What do you think?

What difference does it make, for instance in terms of the total size
returned by “guix size tor-client” vs. “guix size tor”?

Are there other considerations, such as a reduced attack surface?

> I've tested the code below and it works as expected on my guix
> install. However, since I'm neither a schemer nor guixpert, fell
> free to teach me how to do it the guix way.

It looks good to me overall!  Some nitpicking:

> + (define-public tor-client
> +   (package
> + (inherit tor)
> + (name "tor-client")
> + (arguments
> +  `(#:configure-flags
> +`(,@(cons "--disable-module-relay"
> + ,(cadr (package-arguments tor))

We’d rather use ‘substitute-keyword-arguments’ to augment
#:configure-flags without touching the other keyword arguments (there
are several examples in the source).

> + (synopsis "Client to the anonymous Tor network")
> + (description
> +  (string-append (package-description tor)
> +   "\n\nThis package only provides the client funcionality to the Tor
> +Network.  If you want to setup a relay you need to install @code{tor}."

We generally avoid concatenating text like this, for the reasons
explained at:

  https://guix.gnu.org/manual/en/html_node/Synopses-and-Descriptions.html

Regarding the format of patches, you can take a look at this:

  https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html

Thanks,
Ludo’.

Re: Propose to distribute a user-only install script, not admin required

[Ludovic Courtès]

Hi Josh,

Josh Marshall  skribis:

> One thing which I think could significantly aid adoption would be up
> either add an option or add a new installer script with guix
> configured to install and run purely out of the user's home directory
> without any special permissions.  Conceptually, guix shouldn't need to
> have any elevated permissions given it is acceptable to use resources
> less efficiently when they are in contention.  This would also allow
> guix to be a drop in replacement to tools which already allow
> individual users to install and use them without a hassle, like
> Anaconda.

I think we should consider providing a binary tarball produced with
‘guix pack -RR’ instead of just ‘guix pack’.  It’s possible to run
“rootless” Guix from there:

  https://lists.gnu.org/archive/html/guix-devel/2018-05/msg00139.html

With minor changes to the daemon, we could arrange so that users don’t
have to fiddle with environment variables or anything.

Now, I fear that the typical use case for that is places where user
namespaces aren’t available, which means a degraded experience.  (See
the rant at the bottom of
.)

Thoughts?

Ludo’.

Re: best practise between git-fetch vs url-fetch?

[Ludovic Courtès]

Hi,

Leo Famulari  skribis:

> I think we should try to avoid a situation where we have to bootstrap
> Git. We do have git-minimal, which works for now. Libgit2 recently
> started releasing tarballs, so that could be an option, too.

Good point.  We could work around that by adding a derivation “built-in
builder” for Git clones, just like we have “builtin:download”.

> Another point for url-fetch is that Git's transition from SHA1 to SHA256
> identifiers may be easy for us, or it may not be. We don't know yet.

I’m “curious” about that transition…

Ludo’.

Re: best practise between git-fetch vs url-fetch?

[Ludovic Courtès]

Hi,

Jack Hill  skribis:

> It seems a bigger problem is when the build method for the git
> repository and release tarball are different. In many packages this is
> because of the pre-generated autotools build system in the release
> tarballs. Should we bootstrap the autotools build system even when
> building from a release tarball? As I understand it, autotools has
> historically been treated this way in part to allow building on
> systems without the right version of autotools, but is that really a
> problem in Guix? Why should it be treated differently than other
> pre-generated artifacts which we rebuild?

You’re pointing out a contradiction here.  On one hand, we take
advantage that Autotools-based programs require nothing but a POSIX
shell and make to be built, unlike most other build systems, which
greatly simplifies our dependency tree.  On the other hand, we’re
striving to build everything from source, and Autotools-generated files
look like elephants in this room.  Debian has been dismissing those
files for a long time.

Probably we should aim towards not using pre-built Autotools generated
files and, by extension, probably not using pre-built tarballs when VCS
checkouts are available.

It’s kinda happening on leaf packages, often upstream developers people
don’t bother running “make dist”.  It’ll take some time before tarballs
disappear and needs some thought in particular from a bootstrapping
standpoint.

> Another improvement we could make here is improving the message about
> Software Heritage in guix lint. Most of the other messages it emits
> are things that the author of a package should consider improving. If
> the Software Heritage message is less actionable, let's make that
> clearer so that people don't think there is a problem with their
> package definition.

What message would you suggest?

Thanks,
Ludo’.

Re: Towards a graphical installer?

[Ludovic Courtès]

Hello,

Mathieu Othacehe  skribis:

> I think switching to a DE based installer could:
>
> * Allow the user to browse for some questions or contact #guix while in
>   the installation process.
>
> * Bring better control of network connection, with a dedicated tool such
>   as NetworkManager applet.

I think the Connman-based option we currently have is pretty good
(modulo the WiFi bug we had ;-)) and has the advantage of being well
integrated, no?

> * Make easier to add accessibility support to the installer.

Really?  Text-based interfaces tend to lend themselves well to
accessibility support, I think, with things like BRLTTY.  I would think
that using a graphical DE is more challenging because one has to know
how to navigate between windows, how to query the currently-focused
window, etc., which requires a screen reader like Orca or similar, which
is not really a panacea.

I also wonder whether the extra hundreds of megabytes for “just” running
a terminal under X11 are warranted.  It would be a different story if
the installer itself were graphical.  But at any rate, I think closure
size is an issue.

Thoughts?

Ludo’.

Re: best practise between git-fetch vs url-fetch?

[Josh Marshall]

Hello all,

Continuing my Sunday catch-up, I'd like to kick the tires on this.

Tarballs seem to have the following:
+ Faster to build
+ Faster first time download
- Larger downloads for smaller changes
- Autotools are pre-built, negating bootstrapping
- SWH not yet supported (https://forge.softwareheritage.org/T1352)
+ Fewer package dependencies\
+ Can use alternative source versions via `--with-source` -- more
likely for each to work, but fewer options

Git seems to have the following:
- Slower to build
- Slower first time download
+ Smaller incremental downloads
+ More complete bootstrapping
+ SWH support is working
- Adds extra dependency on git
+ Easy use of alternative commits via `--with-commit`

Practically, these options are highly similar, with git having some
edge when it comes to bootstrapping the software more completely, and
avoiding using as many non-source executable things.  But that is
extendable to tarballs as well.

What it comes down for me is that git offers a more coherent history
of a piece of software all in one location.  Tarballs are snapshots in
a software's history, and I'd prefer to just have the entire history
already in one managed and organized location.  That is one things
tarballs can't practically accomplish.

I am also for having a de-factco, soft suggestion that packages use.
I think git-fetch is ever so slightly the better option, and so should
be a "default" recommendation over url-fetch.  That being said, I am
more in favor of having a default than what that default is.

On Thu, May 14, 2020 at 12:16 PM Jack Hill  wrote:
>
> On Wed, 13 May 2020, Tobias Geerinckx-Rice wrote:
>
> >> --with-commit
> >
> > Yes, this is niice.  ♥
> >
> > For the sake of argument¹, though, so is --with-source= > and
> > supported upstream tarball dot tar>.
> >
> > Somehow erasing that hard distinction is the real winning move.
> >
> > Kind regards,
> >
> > T G-R
> >
> > [1]: Obligatory .
>
> Heh, I'll take the bait. I also really appreciate how easy we make it for
> people to exercise their software freedom and run modified software. How
> best to make that possible and balance it with other usability constraints
> (e.g. mirror:// urls should be more robust) may vary by package, so I
> agree with Leo that some discretion is needed. However, that's not to say
> that I wouldn't appreciate some guidance as to our default preference when
> there is no package-specific reason to prefer one way over the other.
>
> It seems a bigger problem is when the build method for the git repository
> and release tarball are different. In many packages this is because of the
> pre-generated autotools build system in the release tarballs. Should we
> bootstrap the autotools build system even when building from a release
> tarball? As I understand it, autotools has historically been treated this
> way in part to allow building on systems without the right version of
> autotools, but is that really a problem in Guix? Why should it be treated
> differently than other pre-generated artifacts which we rebuild?
>
> Another improvement we could make here is improving the message about
> Software Heritage in guix lint. Most of the other messages it emits are
> things that the author of a package should consider improving. If the
> Software Heritage message is less actionable, let's make that clearer so
> that people don't think there is a problem with their package definition.
>
> Best,
> Jack

Re: Should guix track package aliases?

[Josh Marshall]

Checking http://guix.gnu.org/packages.json again, it seems like the
server changes to not misrepresent dates have not been applied yet.
Can someone get in and do that?

On Sun, May 10, 2020 at 2:16 PM Josh Marshall
 wrote:
>
> This back and forth is what I've been having going on in my head.  We might 
> be able to leverage repology.org for their work on mapping packages across 
> distros.  Yesterday, civodul entered a bug to remove the Etag and 
> last-modified headers in the nginx config to fix a bug on our side so 
> repology will update info on guix.  That code is GPL'd so some of it could be 
> incorporated, and maybe even be leveraged to interpret foreign distro's 
> packages to create package prototypes which we could then use to more rapidly 
> expand what packages are available through guix.  I could see this as a 
> high-payoff medium effort development for guix.
>
> On Sun, May 10, 2020 at 9:34 AM zimoun  wrote:
>>
>> Hi Julien,
>>
>> On Sun, 10 May 2020 at 14:13, Julien Lepiller  wrote:
>>
>> > The proposal was about suggesting anotger nameqwhen no package was found, 
>> > not to install something else.
>>
>> Sorry I misinterpreted.
>>
>>
>> > >Well, do you have specific example in mind?
>> >
>> > $ guix install gcc
>> > guix install: error: gcc: unknown package
>> > Hint: did you mean `guix install gcc-toolchain`?
>> >
>> > Since not being able to install gcc is surprising, and you don't always 
>> > know about gcc-toolchain.
>>
>> I understand even if this one is the wrong example. :-)
>> It even deserves an entry in the manual.
>> Well, but I understand what you mean.
>>
>>
>> > $ guix install gpg
>> > Hint: did you mean `guix install gnupg`?
>>
>> The question is: why do you type 'gpg'?
>>
>> I mean, the upstream name is really GnuPG so it is not one "stupid"
>> Guix devs arbitrary rename because in their infinite wisdom they
>> decided to. ;-)
>>
>> Well, do you type 'gpg' because
>> a) it is the name of the binary?
>> or b) it is the name of the package in your previous favourite distro?
>>
>> If it is a), then a proposal by Pierre named "filesearch" is floating
>> around.  And this should improve the situation.
>>
>> If it is b), then I do not see how to improve the situation in the
>> general case.  But maybe there is some well-known cases.
>>
>>
>> > Often a name is used to refer to a package, and it's annoying to go 
>> > through a search, especially when you have to filter a big output.
>>
>> I agree.  From my point the issue is that "guix search" is not doing
>> the job and the improvement should come from this.  And your 'gpg'
>> example is a good one, IMHO:
>>
>> --8<---cut here---start->8---
>> $ guix search gpg | recsel -C -p name,relevance
>> name: signing-party
>> relevance: 16
>> name: qgpgme
>> relevance: 15
>> name: libgpg-error
>> relevance: 14
>> name: python2-gpg
>> relevance: 11
>> name: python-gpg
>> relevance: 11
>> name: ledger-agent
>> relevance: 9
>> name: python2-pygpgme
>> relevance: 8
>> name: python-pygpgme
>> relevance: 8
>> name: gpgme
>> relevance: 8
>> name: kgpg
>> relevance: 6
>> name: jetring
>> relevance: 6
>> name: emacs-pinentry
>> relevance: 6
>> name: trezor-agent
>> relevance: 5
>> name: python-trezor-agent
>> relevance: 5
>> name: keepkey-agent
>> relevance: 5
>> name: qtpass
>> relevance: 2
>> name: pinentry
>> relevance: 2
>> name: pinentry-tty
>> relevance: 2
>> name: pinentry-qt
>> relevance: 2
>> name: pinentry-gtk2
>> relevance: 2
>> name: pinentry-gnome3
>> relevance: 2
>> name: pinentry-emacs
>> relevance: 2
>> name: pinentry-efl
>> relevance: 2
>> name: kleopatra
>> relevance: 2
>> name: gnupg
>> relevance: 2
>> name: gnupg
>> relevance: 2
>> name: git-remote-gcrypt
>> relevance: 2
>> name: gajim
>> relevance: 2
>> name: emacs-extend-smime
>> relevance: 2
>> name: assword
>> relevance: 2
>> --8<---cut here---end--->8---
>>
>> The expected package 'gnupg' appears... piouf!
>>
>> I fully agree that the experience with "guix search" is frustating.
>> And maybe using both the 'upstream-name' and an extra 'properties'
>> such as 'alternative-names' or 'extra-keywords' should help for
>> discoverability.
>>
>>
>> WDYT?
>>
>> All the best,
>> simon

Re: Propose to distribute a user-only install script, not admin required

[Josh Marshall]

Another non-chroot option is `fakechroot`, which seems to get the same
effect without root.  It does make me wonder why `chroot` requires
privileged access at all.

As I'm slowly getting more familiar with guix, the more I think the
internal design ought to change.  I'm finding that how it works right
now is inelegant if you need to shift the application of guix a little
bit.  If you want a native guix experience vs secondary package
manager they have to be configured differently and daemon details seem
to need to leak to the client.  For users who need unprivileged access
to use guix, setup is more difficult when similar tools can work
without hassle.  Tracing back errors across the client and server
requires extra knowledge of implementation to understand what errors
actually mean, increasing the barrier to entry.

If guix changed such that it had the ability to work as a single
standalone binary, and optionally checked something with dbus or a
reserved unix socket to coordinate with an existing daemon, other
instances of guix running on the system, or launch a daemon on demand
then the number of use cases where guix would just work would
significantly increase.  Having all functionality in a single binary
would also make error handling and determination easier.  There are
ways to make the current approach accomplish all of these goals, but
it would be more complex and seems like it is ultimately trying to
approximate the restructuring I'm suggesting.


On Sat, May 16, 2020 at 10:05 PM Bengt Richter  wrote:
>
> Hi Josh, Tobias, et al,
>
> On +2020-05-16 17:47:39 +0200, Tobias Geerinckx-Rice wrote:
> > Josh,
> >
> > Josh Marshall 写道：
> > > One thing which I think could significantly aid adoption would be up
> > > either add an option or add a new installer script with guix
> > > configured to install and run purely out of the user's home directory
> > > without any special permissions.
> >
> > An old but classic place to start is [0] which explains some of the problems
> > & trade-offs, and illustrates an approach that may or may not still work
> > today.
> >
> > My subjective impression was that this used to be more of a big deal (i.e. a
> > few years ago) than it is now.  I don't know if it's less of a problem these
> > days, or people gave up on asking, or perhaps I'm not in the right channels
> > to hear the clamouring.
> >
> > Part of me thanks you for bringing this up again.  I'm interested to see
> > where it goes.
> >
> > Another part of me fears that ‘rootless Guix’ is just the perfect excuse for
> > misguided admins to give their users a pale and flavourless Guix experience.
> > It would rather taint the brand.
> >
> > Kind regards,
> >
> > T G-R
> >
> > [0]: https://github.com/pjotrp/guix-notes/blob/master/GUIX-NO-ROOT.org
>
> (I hadn't seen [0] above, but now I have :) So I will be wondering if
> proot is a good path to get where I want to go. I hope this thread
> will provide further input).
>
> I am happy to see this suggestion, as I have been experimenting with
> re-writing guix-install.sh to do something very related:
>
> (I am assuming a user who _can_ do useradd and groupadd, or get it done,
> but wants to run guix totally without needing root priviliges
> beyond that).
>
> It boils down to creating a new user-mode user called guixurootd
> to serve as "guix-root" daemon and manage running the builders
> with inter-user permission isolation but not involving root.
>
> I'm hoping some combination of group membership and permissions
> will enable safe multithread isolation without involving actual root
> privileges for guixurootd.
>
> My motivation was really not liking to run guix-install.sh as root.
> Big complex chains of actions that involve unnecessary global
> root privileges scare me, even if I can inspect the script.
>
> So my first thought was to split it into two: the part that can
> run fine without sudo to root (which is most of it) and the part that
> requires sudo to root, which is creating the daemon and builders, and
> writing to / and ~root, and something I forgot probably :).
>
> The latter requirement goes away when writing to / becomes
> writing to /home/guixurootd/ and /home/guixurootd/root
>
> I really would like the entire guix usage of "/" to become
> usage of "/home/guixurootd/" including /var /etc /root/.dotfiles
> /tmp and _everything_, so that the impact on a "foreign distro"
> is totally contained in the guixurootd $HOME file space plus
> the existence of the $HOME-less builders.
>
> I am in a design-churn phase for the moment, trying to
> factor everything into place ;-)
>
> Ideally installation could become something like
> --8<---cut here---start->8---
> 1. sudo sys_create_build_user # as defined in guix-install.sh
> 2. sudo useradd -U -G guixbuild  \
>  -m -k $tmp_skeldir -s "$(which nologin)"\
>  -c "Guix user-root daemon" --system \
>  "guixurootd";
> 3. download and verify 

gnome-bluetooth

[Ekaitz Zarraga]

Hi,

I've been diging in a Bluetooth issue I had in the past[^1] and I found some 
interesting details I need help to tackle.

Looks like Gnome-bluetooth does NOT support Bluez5 which is what we are 
shipping right now. It's stated clearly in the project description:
https://gitlab.gnome.org/GNOME/gnome-bluetooth

I also found users in Arch's forums saying it started to fail since Bluez5.
Does it make sense to make a bluez4 package?

Did anyone manage to make gnome-bluetooth work in any way? It seems like 
gnome-bluetooth never worked in guix.

Best,
Ekaitz


[^1]: https://www.mail-archive.com/help-guix@gnu.org/msg08859.html

Re: Updating the “pre-push” Git hook

[Ricardo Wurmus]

Leo Famulari  writes:

> On Fri, May 22, 2020 at 10:44:48PM +0200, Ludovic Courtès wrote:
>> Hello Guix!
>> 
>> I think we should change our pre-push hook as shown below.
>> 
>> Thoughts?
>
> Is it fast? :)

This depends on how many commits you have previously authenticated.  But
even the slow case is pretty fast.  I just authenticated 16,290 commits
in less than a minute.  Regular contributors won’t have to authenticate
nearly as many commits.

For 0 commits it takes 4 seconds.

-- 
Ricardo

Re: Updating the “pre-push” Git hook

[Efraim Flashner]

On Fri, May 22, 2020 at 10:44:48PM +0200, Ludovic Courtès wrote:
> Hello Guix!
> 
> I think we should change our pre-push hook as shown below.
> 
> Thoughts?
> 
> Thanks,
> Ludo’.
> 

(ins)efraim@E5400 ~$ type -P make
(ins)efraim@E5400 ~$ command -v make

I'd need to run 'guix environment --ad-hoc make -- git push'


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature