Re: SELinux log
Hi!
Hope to shed some light.
I followed all the steps that I hadn't followed before in the
documentation manual about SELinux for guix daemon (ran semodule,
restorecon for all the filesystem and restarted the daemon).
I forgot to set SELinux in permissive mode, so I still got the issue
with the socket.
Then I realized about this, and changed the mode. My log shows that
SELinux would have prevented the daemon from running, like when I had
it in enforcing mode:
---start
here---
type=SERVICE_START msg=audit(1559870054.070:258): pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='unit=flatpak-system-helper comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
res=success'^]UID="root" AUID="unset"
type=SERVICE_STOP msg=audit(1559870056.300:259): pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='unit=user@42 comm="systemd" exe="/usr/lib/systemd/systemd"
hostname=? addr=? terminal=? res=success'^]UID="root" AUID="unset"
type=SERVICE_STOP msg=audit(1559870056.340:260): pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='unit=user-runtime-dir@42 comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
res=success'^]UID="root" AUID="unset"
type=AVC msg=audit(1559870056.930:261): avc: denied { read } for
pid=750 comm="guix-daemon" name="libnss_files.so.2" dev="dm-0"
ino=559459 scontext=system_u:system_r:init_t:s0
tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=lnk_file
permissive=1
type=AVC msg=audit(1559870056.930:262): avc: denied { map } for
pid=750 comm="guix-daemon"
path="/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libnss_files-2.28.so"
dev="dm-0" ino=559457 scontext=system_u:system_r:init_t:s0
tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=1
type=AVC msg=audit(1559870056.930:263): avc: denied { execute } for
pid=750 comm="guix-daemon"
path="/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libnss_files-2.28.so"
dev="dm-0" ino=559457 scontext=system_u:system_r:init_t:s0
tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=1
type=AVC msg=audit(1559870056.937:264): avc: denied { create } for
pid=2170 comm="guix-daemon" name="reserved"
scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:user_tmp_t:s0 tclass=file permissive=1
type=AVC msg=audit(1559870056.937:265): avc: denied { write } for
pid=2170 comm="guix-daemon" path="/var/guix/db/reserved" dev="dm-0"
ino=306296 scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:user_tmp_t:s0 tclass=file permissive=1
type=AVC msg=audit(1559870056.940:266): avc: denied { write } for
pid=2170 comm="guix-daemon" name="db.sqlite" dev="dm-0" ino=306225
scontext=system_u:system_r:init_t:s0
tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=1
type=AVC msg=audit(1559870056.950:267): avc: denied { setattr } for
pid=2170 comm="guix-daemon" name="db.sqlite-wal" dev="dm-0" ino=306376
scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:user_tmp_t:s0 tclass=file permissive=1
type=AVC msg=audit(1559870056.950:268): avc: denied { map } for
pid=2170 comm="guix-daemon" path="/var/guix/db/db.sqlite-shm"
dev="dm-0" ino=306377 scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:user_tmp_t:s0 tclass=file permissive=1
type=AVC msg=audit(1559870058.000:269): avc: denied { link } for
pid=2170 comm="guix-daemon"
name="7f1alh9qj2h0wwy2220npgnmw6pbrkwx-mirrors" dev="dm-0" ino=551918
scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:user_tmp_t:s0 tclass=file permissive=1
type=AVC msg=audit(1559870058.130:270): avc: denied { rename } for
pid=2170 comm="guix-daemon" name=".tmp-link-2170-1804289383"
dev="dm-0" ino=551930 scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:user_tmp_t:s0 tclass=file permissive=1
type=AVC msg=audit(1559870060.410:271): avc: denied {
execute_no_trans } for pid=2173 comm="guix-daemon"
path="/gnu/store/ncknl03pkmamrxg7q9nxi1rn1qhvwbi9-guix-1.0.1/libexec/guix/substitute"
dev="dm-0" ino=679069 scontext=system_u:system_r:init_t:s0
tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=1
type=AVC msg=audit(1559870060.886:272): avc: denied { name_connect }
for pid=2173 comm=677569782073756273746974757465 dest=443
scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket
permissive=1
type=SERVICE_STOP msg=audit(1559870062.620:273): pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='unit=fprintd comm="systemd" exe="/usr/lib/systemd/systemd"
hostname=? addr=? terminal=? res=success'^]UID="root" AUID="unset"
type=SERVICE_STOP msg=audit(1559870070.140:274): pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='unit=systemd-localed comm="systemd"
exe="/usr/lib/systemd/systemd"
New German PO file for 'guix-manual' (version 1.0.1-pre1)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'guix-manual' has been submitted by the German team of translators. The file is available at: https://translationproject.org/latest/guix-manual/de.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: https://translationproject.org/latest/guix-manual/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/guix-manual.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: Crosscompiling C++ for powerpc64le fails
Ludovic Courtès writes: > Hi Marius, > > Marius Bakke skribis: > >> Ludovic Courtès writes: > > [...] > >>> The issue that Tobias reports reminds me of the CPATH vs. C_INCLUDE_PATH >>> issue that was causing troubles with newer GCCs, and that I think Marius >>> addressed in ‘core-updates’ (?). Marius, does that ring a bell? >> >> Unfortunately there are still issues with cross-compiling C++ on >> 'core-updates'. For 'C', the workaround was to go back to "CROSS_CPATH" >> instead of "CROSS_C_INCLUDE_PATH", like with native builds. > > That should also address C++, since CPATH (and CROSS_CPATH) are for all > language front-ends, no just C, no? Indeed. The cross-compilation problems are unrelated. >> For native builds on core-updates, GCC7 occasionally fails if the libc >> or kernel headers are not on C_INCUDE_PATH (see e.g. f90d6c3). It could >> be that cross builds need a similar workaround, but I have not found the >> magic incantation yet. > > How can it be that kernel headers are not on C_INCLUDE_PATH (or CPATH)? Sorry, this was a red herring. :-) (Kernel headers are of course on CPATH because they are propagated from glibc, but adding them on C_INCLUDE_PATH works around some corner cases because GCC disables warnings for such headers, which is expected by some build scripts.) I expected the problem with GCC not finding target libc headers to be a matter of getting it on CROSS_CPLUS_INCLUDE_PATH, just like we had to set C_INCLUDE_PATH for GCC 7's build processes to find libc. But, looking at this issue with a fresh mind I managed to locate the problem, and a one-liner fix: From dcdedf8d8460a032c0333f6050626a41b39ff461 Mon Sep 17 00:00:00 2001 From: Marius Bakke Date: Thu, 6 Jun 2019 19:33:05 +0200 Subject: [PATCH] gnu: cross-base: Fix C++ cross-compilation problems with GCC 7. * gnu/packages/cross-base.scm (cross-gcc-arguments)[#:configure-flags]: Add "--with-sysroot=/". --- gnu/packages/cross-base.scm | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/gnu/packages/cross-base.scm b/gnu/packages/cross-base.scm index 9fcf3bd780..0bd0cb3987 100644 --- a/gnu/packages/cross-base.scm +++ b/gnu/packages/cross-base.scm @@ -120,7 +120,15 @@ base compiler and using LIBC (which may be either a libc package or #f.)" ,@(if libc `( ;; Disable libcilkrts because it is not ;; ported to GNU/Hurd. - "--disable-libcilkrts") + "--disable-libcilkrts" + ;; When building a cross compiler, --with-sysroot is + ;; implicitly set to "$gcc_tooldir/sys-root". This does + ;; not work for us, because --with-native-system-header-dir + ;; is searched for relative to this location. Thus, we set + ;; it to "/" so GCC is able to find the target libc headers. + ;; This is safe because in practice GCC uses CROSS_CPATH + ;; & co to separate target and host libraries. + "--with-sysroot=/") `( ;; Disable features not needed at this stage. "--disable-shared" "--enable-static" "--enable-languages=c,c++" -- 2.21.0 WDYT? Cross-compiling bootstrap-tarballs still does not work, but I think we just need to reinstate some known workarounds... Will look into it the coming days so we can get this branch rolling :-) signature.asc Description: PGP signature
Re: SELinux log
Hi Laura, >> Thanks. Did you install the SELinux policy for the daemon that is >> included in the source code repository? (It is not included in the >> files that “guix pull” installs.) > My bad, I haven 't :/ Shall I put SELinux in enforcing mode and do so? Permissive mode is better. It will log violations but not prevent them. This allows us to see the details in the logs without impacting our use of Guix. -- Ricardo
Re: Lightning talk at IPFS camp
Pierre Neidhardt writes: >> I was thinking of the Guix package definitions. In the long run, >> assuming IPFS turns out to be reliable enough, we could put all source >> into IPFS with a CID reference, rather then today's many ways to >> download source files. > > There would be nothing special about it beside implementing an IPFS > fetcher, or would it? Let me know if I misunderstood. What's special about it is that it could replace all the other ones. > Didn't know Radicle, it looks fantabulous! And... it uses (or plans to) > a Scheme-based language! :) Exactly. > So you are saying that we could move the guix.git to a Radicle project, > right? Yes, assuming all that becomes stable at some point. Konrad.
Re: SELinux log
Hi! > Thanks. Did you install the SELinux policy for the daemon that is > included in the source code repository? (It is not included in the > files that “guix pull” installs.) My bad, I haven 't :/ Shall I put SELinux in enforcing mode and do so? Regards :) Laura
Re: Documentation videos are being uploaded!
Hi! > Thank you Laura for continuously caring about the videos even after > your internship ended! Of course Bruno :) I said I would go on as a contributor and here I am ;) Alles gute! Laura
Re: Lightning talk at IPFS camp
Konrad Hinsen writes: > I was thinking of the Guix package definitions. In the long run, > assuming IPFS turns out to be reliable enough, we could put all source > into IPFS with a CID reference, rather then today's many ways to > download source files. There would be nothing special about it beside implementing an IPFS fetcher, or would it? Let me know if I misunderstood. > Again in the long run, if we don't mind depending on IPFS, we don't need > the Guix store any more. Package installation would amount to local > pinning. Anyone could then build a package anywhere (home directory, > ...) and just add it to IPFS. Since that also eliminates the technical > constraints of the store, the same mechanism could be used for any kind > of data processing, with the results stored in IPFS. Reproducibility of > any kind of computation via Guix, with building software just an > important special case. Very good point, I like it. I think I'll mention this in the talk. > For human input, Git would be OK, with repositories stored in IPFS > (there's already some support for that, see > https://github.com/ipfs/go-ipld-git). A more radical redesign is > Radicle (http://www.radicle.xyz/), which uses IPFS as a collaboration > platform (still at the git level). I guess Radicle could be used for > much more than that in Guix, but I haven't looked at that in detail. Didn't know Radicle, it looks fantabulous! And... it uses (or plans to) a Scheme-based language! :) So you are saying that we could move the guix.git to a Radicle project, right? Makes sense to me. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Lightning talk at IPFS camp
Pierre Neidhardt writes: >> - A unified way to refer to stuff (I am thinking of IPLD here) >> No more tarballs, git commits, etc. CIDs everywhere. > > Do you have a concrete use case? I was thinking of the Guix package definitions. In the long run, assuming IPFS turns out to be reliable enough, we could put all source into IPFS with a CID reference, rather then today's many ways to download source files. >> - A unified storage scheme for all data, both "system" and "user". > > Can you elaborate? Again in the long run, if we don't mind depending on IPFS, we don't need the Guix store any more. Package installation would amount to local pinning. Anyone could then build a package anywhere (home directory, ...) and just add it to IPFS. Since that also eliminates the technical constraints of the store, the same mechanism could be used for any kind of data processing, with the results stored in IPFS. Reproducibility of any kind of computation via Guix, with building software just an important special case. > I'm not too sure about how human input would be logged, but at the very > least the idea of distributing the store seems amazing. For human input, Git would be OK, with repositories stored in IPFS (there's already some support for that, see https://github.com/ipfs/go-ipld-git). A more radical redesign is Radicle (http://www.radicle.xyz/), which uses IPFS as a collaboration platform (still at the git level). I guess Radicle could be used for much more than that in Guix, but I haven't looked at that in detail. Konrad.
Re: Running Guix System on Hetzner Cloud
On 6/6/19 12:37 PM, n...@n0.is wrote: > Jonathan Brielmaier transcribed 93K bytes: >> Hi fellow Guix hackers, >> >> the last weekend I tried to install Guix system on the Hetzner Cloud[0]. >> First I tried to use Ubuntu, install Guix with the installer script and >> then initiate Guix with "guix system init /mnt...". This wasn't >> successful as Guix system didn't boot. >> >> So I asked them if they could add the Guix ISO to there ISO image >> collection and they did it. At the moment only for my account, not general. > > How did you convince them? The last 3 times I asked for systems which weren't > in their ISO selection, I was told it isn't possible and I should find ways > to do it myself (which I did then). I just asked them over a support request :) The Guix ISO is only visible at my account, I didn't asked yet if they could add it for all customers... BTW: I built an ISO image with the fix from https://issues.guix.gnu.org/issue/36099. They added this ISO as well to my account and now the installation succeeds with the graphical installer :)
Re: Running Guix System on Hetzner Cloud
Jonathan Brielmaier transcribed 93K bytes:
> Hi fellow Guix hackers,
>
> the last weekend I tried to install Guix system on the Hetzner Cloud[0].
> First I tried to use Ubuntu, install Guix with the installer script and
> then initiate Guix with "guix system init /mnt...". This wasn't
> successful as Guix system didn't boot.
>
> So I asked them if they could add the Guix ISO to there ISO image
> collection and they did it. At the moment only for my account, not general.
How did you convince them? The last 3 times I asked for systems which weren't
in their ISO selection, I was told it isn't possible and I should find ways
to do it myself (which I did then).
> They provide some kind of serial console over the browser. So I just
> booted the server with Guix ISO mounted. I went through the graphical
> installer, which works very well in this environment :)
>
> During the installation step it fails due to missing "virtio_pci" initrd
> modules (see hetzner_cloud_installer_fails.png). In the installer there
> was no way to bypass this issue. But rebooting and installing manually
> with the configuration below did work :)
>
> I think it would be nice if the installer could handle that as he
> already cover the "virtio_scsi" module.
>
> In the end I got a working Guix system for 0,05 € :)
>
> Happy hacking
> Jonathan
>
> P.S: Did I already mentioned that the installer is _very_ nice?
>
> [0] https://www.hetzner.com/cloud
>
> ;; This is an operating system configuration generated
> ;; by the graphical installer.
>
> (use-modules (gnu))
> (use-service-modules databases desktop mail networking ssh xorg)
> (use-package-modules admin vim)
>
> (operating-system
> (locale "en_US.utf8")
> (timezone "Europe/Berlin")
> (keyboard-layout
> (keyboard-layout "de" "deadacute"))
> (bootloader
> (bootloader-configuration
> (bootloader grub-bootloader)
> (target "/dev/sda")
> (keyboard-layout keyboard-layout)))
> (initrd-modules '("virtio_scsi" "virtio_pci"))
> (swap-devices (list "/dev/sda1"))
> (file-systems
> (cons* (file-system
> (mount-point "/")
> (device
>(uuid "713cf8af-e503-45f9-9a10-a0c5a4ce709b"
> 'ext4))
> (type "ext4"))
>%base-file-systems))
> (host-name "guixone")
> (users (cons* (user-account
> (name "jonathan")
> (comment "Jonathan Brielmaier")
> (group "users")
> (home-directory "/home/jonathan")
> (supplementary-groups
> '("wheel" "netdev" "audio" "video")))
> %base-user-accounts))
> (packages
> (append
> (list (specification->package "nss-certs") nmap vim)
> %base-packages))
> (services
> (append
> (list (service dhcp-client-service-type)
> (dovecot-service)
> (mysql-service)
> (service openssh-service-type))
> %base-services)))
Re: Video license
Hello Björn, > For the code I would suggest GPL v3+, for the voices (currently Paul) > and videos I would suggest CC-BY-SA 4.0 > > What do you think? Does every contributor agree to that? That looks good to me. For the source code we could add copyright statements at the top of the files in a similar way to the rest of the Guix code. Also, would you like to take a look at the CREDITS file and add entries for the work that you have done?. The idea is twofold: to acknowledge the contributions made and also to make the steps more visible. Potential future contributors could then say ' hey, I could do that in my language'. Best regards, Paul.
Re: Testing needed for lzip substitutes!
I've switched to it yesterday and since then it seems I have to compile everything myself :( Subversion, git, boost, to name a few. I do get the source from qualif.ci.guix.gnu.org though: --8<---cut here---start->8--- downloading from https://qualif.ci.guix.gnu.org/nar/z4yv0m8wqfqgpgqalgx1dlqylq6rwqyg-git-2.21.0.tar.xz... --8<---cut here---end--->8--- Is this expected? If not, any idea how to investigate? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: New Russian PO file for 'guix-manual' (version 1.0.0-pre3)
On Thu, May 09, 2019 at 06:08:46PM +0300, Pavel Maryanov wrote:
> Ludovic, unfortunately Russian translation "Keyboard Layout and Networking
> and Partitioning" have to contain comma because of two 'and'. It is a rule
> of Russian language.
>
It appears you can write “@comma{}” instead of “,” according to the
Texinfo manual section “12.1.3 Inserting ',' with '@comma{}'”.
Regards,
Florian
