IRC channel logs

2018-07-18.log

back to list of logs

<pkill9>is civodul ludovic?
<ng0>yes
<rk4_>nice :)
<rk4_>gotta get to work, sadly no guix involved [yet!]
<snape>pkill9: the letters are in reverse order :-)
<pkill9>ahaha, i thought the names looked similar somehow
<lfam>"pull: Display new/upgraded packages upon completion." Very nice!
<A71788>Hello / Allô -- I have a post-installation question
<lfam>Hi A71788
<A71788>I installed used the "bare-bones" config. This is working, and I have added a non-root user account. What are the steps to add xorg and lxde ?
<A71788>Do I alter the config file in /etc and run reconfigure as root?
<lfam>A71788: That's right. You'll probably want to do something like what is shown here: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/examples/lightweight-desktop.tmpl
<lfam>It adds %desktop-services to set up xorg, and then adds some window managers and other useful packages
<A71788>Thanks lfam. Should I use "sudo <user>" or log in as root to execute reconfigure?
<lfam>A71788: I use `sudo --login` which logs in just for the duration of the command
<A71788>How does one add lxde? I don't like gnome or xfce?
<lfam>A71788: By adding the lxde package to the list of packages. In the example I showed you, this would be done in place of ratpoison and i3-wm
<A71788>Hmm, seems simple. // Is it possible to configure an xorg-DE env for userA and keep a "bare-bones" env for userB and root?
<lfam>A71788: No, they are system-wide. Depending on your use case, though, it might be enough to just use root and userB on the Linux console from another TTY (CTRL+ALT+F2, for example)
<lfam>Of course, many of the desktop services would still be running in the background
<A71788>lfam, thanks for answering my beginner questions. Cheers!
<lfam>You're welcome! Good luck!
<ecbrown>i'm running guixsd 0.15, and do guix package -u repeatedly, but there are a few packages that don't seem to update:
<ecbrown>is this normal behavior?
<lfam>ecbrown: What is `guix --version`?
<ecbrown>(i have done guix pull a couple of times until no change)
<lfam>Ah, okay
<ecbrown>guix (GNU Guix) 348edd91eff2c10448c4c5fc883e0cad3594adeb
<lfam>I think it's a bug, not sure if it's been reported or analyzed yet. It would be interesting to compare the derivations that would be built each time (guix build --derivations r)
<Guest36492>I'd like to configure OpenSMTPD to proxy to an external SMTP server, getting login details from a secrets.db file. How would one go about providing this file in the system configuration? It's an extra file in addition to the regular smtpd.conf
<Guest36492>I mean, I know how to configure OpenSMTPD, but I don't know how to make this secrets.db file exist on the read-only filesystem
<Guest36492>I suppose I could just stick it in /etc/, though this doesn't seem quite like the GuixSD way...
<lfam>Secrets can't be kept in /gnu/store because everything in there is world-readable
<lfam>I've never set up OpenSMTPD but I think it would be done in the regular way
<lfam>In case you haven't seen it, there is a little bit of documentation about configuring the OpenSMTPD service on GuixSD: https://www.gnu.org/software/guix/manual/en/html_node/Mail-Services.html#OpenSMTPD-Service
<Guest36492>lfam: thanks, yes I've been referring to that. Just unsure how best to deal with this secrets file.
<Guest36492>would you just put it in /etc do you think?
<lfam>Guest36492: Probably. I assume OpenSMTPD will need to be told where it is in that conf file. /etc seems standard for secrets as long as the permissions are set correctly.
<Guest36492> thanks lfam
<EuAndreh[m]>janneke: civodul: I've written about getting Guix working on NixOS https://euandre.org/2018/07/17/running-guix-on-nixos.html
<brendyn>I would like to read about running nix on guixsd :p
<brendyn>EuAndreh[m]: getting extra packages that aren't in guix yet. Actually Im interested in running all sorts of package managers on guix. I wonder if flatpack also works for graphical programs?
<EuAndreh[m]>brendyn: guix import nix isn't working well enough?
<baconicsynergy_>hurray for guix 0.15 :)))
<baconicsynergy_>congrats everyone :)
<brendyn>EuAndreh[m]: that doesn't really work at all
<EuAndreh[m]>brendyn: I haven't test yet, I'll try it soon now that I got Guix working
<brendyn>EuAndreh[m]: it's not even intended to work
<EuAndreh[m]>brendyn: Why is that?
<brendyn>EuAndreh[m]: because it's basically impossible. nix expressions are arbitrary code that could do anything
<brendyn>all it can really do is import the metadata
<davidl>has anyone here done a successful GuixSD backup AND recovery? I have a real problem with this. Neither rsync -qaHAXS or btrfs send/receive works completely, I suspect it's due to symlink confusions / recursion loops.
<davidl>for example, the following kept copying over 200GB, when it should only be about 100GB in total: sudo rsync -qaHAXS --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} / /mnt/backups/server1/
<davidl>and the btrfs receive on new target, althoug it could boot, started freezing after a small amount of read/write.
<efraim>I wouldn't bother backing up the store, pretty much just home
<kmicu>davidl_: any error messages in backup scripts? (E.g. complaining that guix store is mounted read_only?)
<kmicu>efraim: a store backup is not a pointless idea. Sources are not always there. The same for binary substitutes. Restoring backup could be much faster than hunting missing source links / binsubs.
<g_bor[m]>Hello guix!
<kmicu>( ^_^)/
<efraim>When I had to move my store to another partition I was told to do 'cp -a'
<davidl_>kmicu: nope, no error messages
<efraim>There's also guix archive, you could store a whole bunch as just a .nar
<davidl_>kmicu: actually, this time when I tried to repartition my target harddrive I got hardware error messages. Had to use dos instead of gpt. might be the btrfs receive problem.
<davidl_>efraim, thanks for the tip. I should perhaps backup /gnu/store separately.
<davidl_>but it's still a mystery why it wouldn't work. I have done migration before from LVM/ext4 source to a btrfs target with just rsync.
<davidl_>kmicu: actually, I ran a diff -r which complained about a symlink loop. but Im not sure that really counts.
<efraim>I have my install on btrfs for the checksuming and compression but not many fancy features
<davidl_>I haven't tried any of the fancy stuff either until now, trying send/receive.
<davidl_>I wrote a snapshot script with a little rotation, but the restore failed, so now Im bummed :(
<g_bor[m]>I have a bit of problem :)
<g_bor[m]>It seems that I got my filesystem corrupted, and I was dropped to a bournish-shell, recommending me to run fsck manually, but fsck is not found. What is the best course of action here?
<davidl_>g_bor: you could perhaps boot from a usb drive, which has fsck?
<siraben>Is there a way to get the Guix manual in A4 or do I have to clone the Git repository and run "make" myself?
<sneek>siraben, you have 1 message.
<sneek>siraben, ArneBab says: here’s an example of timing functions: https://bitbucket.org/ArneBab/wisp/src/7501dc0db3f8cebf49b48634719ab82b4a509a79/examples/benchmark.scm?#benchmark.scm-48
<siraben>Thank you ArneBab, that's very detailed.
<ng0>EuAndreh[m]: I run Nix on GuixSD. that you show the installation of hello is comfortable, now try something which requires dbus and other settings ;)
<ng0>I have mixed success with applications from Nix. I'm still experimenting with the right fixes
<ng0>but since this is out of scope for Guix project, I don't really feel like writing about it at the moment
<ng0>the takeaway so far: try running Nix on GuixSD or Guix on NixOS to experience the sometimes not so obvious differences in packaging :)
<snape>o/
<roptat>hi Guix!
<kmicu>( ^_^)/
<roptat>wow, guix pull now tells me "New in this revision:", fun :D
<jonsger>patch-usr-bin-file from gnu-build-system seems to have problems with locales when build glibc@2.25
<jonsger>it only fails for grep and gettext-minimal. for gcc-5.5.0 it works...
<mbakke>jonsger: Are you sure Guile has been built with the same glibc?
<jonsger>not sure...
<mbakke>Also, I'm curious what the problem with 2.27 is.
<mbakke>jonsger: If the "glibc" variable points to 2.25, you're probably good.
<jonsger>mbakke: 2.27 needs gcc>=6.2 for powerpc64le
<jonsger>which "glibc" variable do you mean?
<mbakke>jonsger: Oh. I meant 'glibc/linux', from (gnu packages base).
<mbakke>Anyway I've been meaning to update to GCC 6 the next cycle. Would you like to try it?
<jonsger>I build a glibc/powerpc64le-linux which inherit glibc-2.25
<mbakke>jonsger: Oh, ok. And I guess you're using that in %final-inputs?
<brendyn>How can I test cross compiling a package to all possible targets that guix supports?
<jonsger>at the moment I just do something like: ./pre-inst-env guix build -e '(@ (gnu packages base) glibc/powerpc64le-linux)' -K --target=powerpc64le-linux-gnu
<mbakke>There mights still be things dependent on glibc/linux, which could contribute to the locale issues.
<jonsger>mbakke: updating to gcc6 is "just" adjusting the default value in commencement.scm and gcc.scm and then patching until it works?
<mbakke>jonsger: Indeed!
<mbakke>You'll need to make sure that C_INCLUDE_PATH and CPLUS_INCLUDE_PATH is not set, since those are buggy for GCC > 5.
<jonsger>oke
<mbakke>But I think civodul already fixed that.
<jonsger>ACTION reserved a powerful x86 machine...
<g_bor>Hello guix!
<jonsger>mbakke: that one https://git.savannah.gnu.org/cgit/guix.git/commit/?id=91a56b4ab5e714e230c0088fb9f5ce0519efe1a0 or?
<g_bor>I'm currently building wip-java8 locally, and it seems to be in good shape.
<g_bor>So far I only had to add one input to java-asm.
<mbakke>jonsger: That one indeed.
<mbakke>Changing the default compiler should be as easy as changing the gcc, gfortran, etc variables to point to gcc-6.
<jonsger> https://gitlab.com/jonsger/Guix/commit/980aecf0d048d51f9196b7994320683b87aa43a5 I already tried that and found things to change...
<mbakke>Interesting that you had to disable C++ support in GMP.
<jonsger>:P
<mbakke>jonsger: Note that there is a 'gmp-6.0' package to work around a bootstrap issue on ARM, possibly related.
<jonsger>ah yeah, right below with explanation :)
<mbakke>No idea what's up with that perl bootstrap patch.
<roptat>g_bor: great!
<roptat>g_bor: when do you think it will be ready?
<jonsger>you mean perl-reproducible-build-date.patch mbakke
<mbakke>I will try the same thing on x86_64 in the next few days.
<mbakke>Ah yes.
<qwertasd>Hello, I just installed GuixSD with encrypted root partition. Everything kinda works right but when I boot I have to manually decrypt the partition from grub. I'm not sure what I have done wrong.
<roptat>qwertasd: grub needs to access /gnu/store, so it needs to decrypt your filesystem first
<qwertasd>roptat: I will try to edit my menuentry in grub to decrypt it
<ecbrown>i am seeing an issue where openssh logins are not permitted until i run guix system reconfigure /etc/config.scm
<ecbrown>(both with stock 0.15 guixsd install, and even have git pull, git package -u)
<ecbrown> https://paste.pound-python.org/raw/n8p8sdMVCVipYY43Xt6d/
<roptat>ecbrown: you mean after you boot, you can't login with ssh until you reconfigure?
<qwertasd>How do I add cryptomount to my menu-entry in the configuration file?
<ecbrown>roptat: that's correct
<roptat>ecbrown: what does "herd status openssh" says after you boot?
<ecbrown>roptat: i will have to reboot and see. (sorry i'm chatting on machine)
<roptat>qwertasd: oh I didn't understand. I thought you were complaining about grub asking for the passphrase
<roptat>ecbrown: no problem
<roptat>qwertasd: can you share your configuration?
<roptat>hm... ligcrypt isn't deterministic
<ecbrown>roptat: error: connect: /run/user/1000/shepherd/socket: No such file or directory
<roptat>the culprit seems to be man/man1/hmac256.1.gz/hmac256.1
<roptat>ecbrown: you have to run it as root
<ecbrown>oh right
<ecbrown>damn
<ecbrown>brb
<roptat>there's a timestamp in that file: .TH HMAC256 1 2018-07-18 "Libgcrypt 1.8.3" "Libgcrypt"
<roptat>that's tricky: if you rebuild the same day, you get the same result :)
<ecbrown>herd: service 'openssh' could not be found
<roptat>sshd maybe?
<roptat>I can't remember the correct name
<qwertasd>roptat: here https://pastebin.com/qir1Z7Sb
<roptat>ecbrown: ssh-daemon
<ecbrown>roptat: ok ssh-daemon worked, and i get a "happy" output on the machine with working ssh. now i will reboot
<g_bor[m]>roptat, ecbrown : I'm also having problems with that and, also lfam.
<ecbrown>thanks for confirming
<g_bor[m]>It seems that ssh does not start on boot.
<g_bor[m]>I could not yet find out what is going on, as shepherd loses the process output on tty1.
<efraim>It starts on boot on one of my two machines
<g_bor[m]>roptat: Did you also notice, that java-commons-collection testsuite fails indeterministically?
<g_bor[m]>efraim: Yes, I also have one where it starts :)
<roptat>g_bor[m]: no I haven't
<roptat>qwertasd: your system definition looks fine to me
<roptat>///boot is not encrypted, is it?
<qwertasd>it isn't
<roptat>mh… my irc client is doing weird things
<roptat>I have full-disk encryption here and it works perfectly fine. Maybe since /boot is not encrypted, grub doesn't try to decrypt anything?
<qwertasd>maybe I should try to encrypt /boot too
<roptat>yeah, it would be more secure too
<roptat>but grub should still ask to decrypt /
<qwertasd>grub only complains that it doesn't find linux and initrd
<qwertasd>I have to manually use cryptomount
<g_bor[m]>roptat: Actually I don't know how to reproduce it, but it seems that it managed to collapse the jvm, brought the daemon to an inconsistent state, so that the vm I was running became unresponsive. I had to force reboot, then recover from a filesystem corruption. I don't know what caused this, but it was a really interesting cascading failure to observe.
<roptat>g_bor[m]: maybe it's unrelated to java-commons-collection?
<roptat>I mean, maybe there was a filesystem corruption, and that's what brought down the jvm, the daemon and lead to the destruction of the world?
<g_bor[m]>roptat: It might be unrelated. After I managed to recover the system everything went fine.
<roptat>I recently blamed the guix daemon when it was actually a faulty disk, so I've learned my lesson :p
<roptat>qwertasd: I think this is worth a bug report to bug-guix@gnu.org
<roptat>I can't help you because I don't know how we build the grub configuration
<g_bor[m]>roptat: That is quite possible. I will do a disk check later. Now everything is in working order. One thing is sure, the errors were related somehow. :) This is a vm, so if there was a disk problem, then most probably the host disk is broken somehow.
<g_bor[m]>The first suspicious thing was that the jvm collapsed on an exception. There was an ignored error, something tried to unlink a file from a read only filesystem.
<g_bor[m]>roptat: How heavy do you think the reverse dependency graph of java-asm is? It says that there are 143 dependent packages. java-asm misses an input, but I'm not sure that I'm will to push this to master.
<roptat>I'd say staging, there very heavy packages that depend on java-asm
<g_bor[m]>roptat: Pushing it to wip-java8 is my current plan. How does that sound? The most interesting thing is, that it just work fine on java7...
<roptat>then wip-java8 would be merged in staging, right? that's fine for me
<g_bor[m]>I guess that's the plan.
<roptat>when I build java packages, maybe half of the time is bouncycastle tests doing nothing
<g_bor[m]>roptat: yes, if I remember correctly there is an open bug for that....
<roptat>I know... but I don't understand why it does nothing
<roptat>now that I think about it, our rule for pushing to master vs staging vs core-updates is based on the number of packages that have to be rebuilt
<roptat>when actually I think we care more about the time it takes to rebuild them
<g_bor[m]>We discussed this and came to the conclusion, that this is not a really good metric. Rekado proposed some changes, like to only update packages on feature branches, for example only update git in git-updates.
<g_bor[m]>Yes time to rebuild would be a good metric.
<roptat>also I'm wondering if there could be some changes to the branch policy
<roptat>like adding a "stable" branch (or some other name) that we never push to
<roptat>when hydra estimates that master doesn't break anything that used to work in "stable", it would automatically merge master onto stable
<roptat>otherwise, it would send a warning that "this package used to work on stable, but doesn't work on master anymore"
<roptat>I'm not sure if it would be a good policy: on the one hand, it means we never break anything for users, otoh it may take some time to fix every new build failure
<g_bor[m]>and also make guix pull pull stable by default, allowing a flag to pull from master.
<roptat>and guix pull would follow "stable" instead of "master"
<roptat>there's already --branch
<g_bor[m]>Actually this should be augmented by some additional methods to get security fixes to stable.
<g_bor[m]>There is a reason to allow breakage in case of serious security issues...
<roptat>that breaks my model where stable was a "snapshot" of master, but that's understandable
<roptat>or maybe there would be a "security" channel where users can get updates (and then graft the updates)
<g_bor[m]>That would be nice.
<roptat>no regression anymore :)
<roptat>and substitutes would always be available for stable
<roptat>well, packages could be broken, but they would build
<g_bor[m]>This would be a nice model, I think.
<roptat>but we need channels first :)
<g_bor[m]>Care should be taken to get the security channel in shape, and might involve some duplicated work.
<roptat>g_bor[m]: not much more than we do now I think
<g_bor[m]>Yes. :)
<roptat>when a security update affets a package that has a lot of dependents, it's fixed in core-updates and grafted in master
<g_bor[m]>I think that we have a channel RFC somewhere, but I did not see coordinated work on that. Do you know anything about the status of that?
<roptat>I think the new guix pull was a good step in that direction, but I haven't seen any work on that either
<g_bor[m]>roptat: Also, I wonder if we can switch to a model where we just build the branches before merging, so we have immediate substitute coverage. That would greatly empower feature branches.
<g_bor[m]>Also, when I finished this java8 stuff, I'm willing to have a look at what's needed for a maven-build-system. WDYT?
<roptat>I'll leave that to you
<roptat>I'm on the scala compiler
<roptat>and the more I work on it, the worse it becomes :/
<roptat>like, whatever I do, I'll have to do type inference
<roptat>even though I may not even care about type checking
<roptat>I'll have a hard time with builtins too
<roptat>but hey, I'm pretty confident I'll be able to reconstruct the AST of any scala source file by the end of next week
<g_bor[m]>roptat: Ok, that's fair enough. Actually I asked this because rekado mentioned, that the ant build system is a low tech one, and we should restructure once we have maven, so once we have that I can migrate packages outside the maven dependency graph to maven build system, if that is applicable.
<g_bor[m]>roptat: Wow, that's so nice!
<roptat>sounds reasonnable
<roptat>I'll be on vacation with family though, so I don't know how much time I can devote to that
<g_bor[m]>:) when on vacation, be on vacation. I think that you should spend your time with your family then. Take your time to relax.
<roptat>yeah, it's going to take a long time to build that compiler anyway
<g_bor[m]>roptat: I guess that this work is also tracked on #bootstrappable, right?
<roptat>I've talked about it, yes
<g_bor[m]>Now I've got to go, bye!
<roptat>bye!
<mbakke>jonsger: Did you get an error such as "error: ambiguates old declaration" from gcc-boot0?
<mbakke>I suspect it wants a newer libc.
<jonsger>mbakke: in which case? gcc6 or glibc-2.25
<mbakke>Gcc6.
<jonsger>just started some minutes ago, had first install guix for guix environment guix...
<brendyn>jonsger: did you put guix in your profile?
<jonsger>brendyn: ?
<ecbrown>[guixsd 0.15] on https://www.gnu.org/software/guix/manual/en/html_node/Packaging-Guidelines.html i see reference to ./pre-inst-env but i don't see it anywhere. is this optional?
<snape>ecbrown: pre-inst-env is generated
<ecbrown>i did see some pre-inst-env.in files, so i see what you mean. who/how is it generated?
<snape>ecbrown: I think on ./configure
<snape>yes, it's generated on ./configure
<ecbrown>thanks, i'm still trying to figure out where things are, and how any patch would be generated and sent in.
<snape>what do you mean "how many patch"?
<ecbrown>how *any* patch. i'm still scoping out the general process for adding a new package
<snape>Oops I can't read :p
<ecbrown>any putative contribution
<ecbrown>:-)
<snape>great! I hope we can see your contributions soon :-)
<ecbrown>i'm not terribly motivated, as i have emacs + spacemacs. what else does one need? ;-)
<snape>The Emacs of distros, of course.
<brendyn>We just need to build the spacemacs of distros ontop of the emacs of distros now
<nixd>Hello, where would I find files normally located in /usr/share in GuixSD? It seems they are not present in the system configuration folders or the per user configuration folders. Im looking for gnome-shell.css
<snape>feel free to do it :-) But I'm not a huge fan of Spacemacs hehe.
<snape>nixd: I don't know about Gnome files, but typically, they could be in /gnu/store or /var
<nixd>snape, Im looking at the system configuration folders now, there are a few files for Gnome, but not the ones Im looking for. Maybe this is more of a Gnome "issue" than a GuixSD issue in my case now.
<snape>nixd: yes, I can't help much with Gnome, unfortunately.
<jonsger>mbakke: thats what i get http://paste.opensuse.org/view/raw/30116438
<roptat>nixd: what do you want to do with this css file?
<nixd>roptat: actually I just want to get the default Gnome background (I know I can get it elsewhere) and I want to mess with the GDM background afterwards. This is obviously nothing critical, Im just trying things out
<roptat>ok, I don't know Gnome enough to help though
<demotri>Do we have something equivalent to "#define REPRODUCIBLE_BUILD" for Ant's build.xml? Someone is inserting tstamps in property files...
<civodul>hey demotri
<civodul>roptat is the local Ant expert :-)
<roptat>demotri: we don't
<roptat>most likely if they insert timestamps, they didn't had a way to not do that
<roptat>what you should do is remove the timestamp from teh property file before it gets into the jar file
<roptat>a better approach is to offer a patch to upstream so their build.xml suppots SOURCE_DATE_EPOCH
<roptat>like a conditional, if SOURCE_DATE_EPOCH exists, use it, otherwise build unreproducibly
<roptat>since the old behavior is preserved by default, upstreams are usually happy to use that kind of patch :)
<mbakke>jonsger: I get the same error. Will probably need to bootstrap GCC6 with GCC5.
<mbakke>Still a few weeks until core-updates starts, luckily :)
<jonsger>mbakke: how is the procedure for that?
<mbakke>I'm trying now to make gcc-boot0 GCC5, and then make a gcc-boot1 variant using that as the compiler. But don't know if it's the "correct" procedure ;-)
<mbakke>WDYT civodul ?
<mbakke>ACTION goes afk for some time
<demotri> roptat: Hm. I read https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal#Examples. Now I wonder who is "upstream" to send the patch to: Ant or Tomcat?
<demotri>I will explain, let me type...
<demotri>In Tomcat's build.xml, there is a <tstamp> <format property="tstamp" pattern=...> ... </tstamp>. That is then used in a <filter token="VERSION_BUILT" value="${today} ${tstamp} UTC"/>. At first, one could substittue* that. Second thought (Ant) is: <tstamp> should respect SOURCE_TIME_EPOCH. Third thought is (Tomcat): <filter> should check for SOURCE_TIME_EPOCH. But that could look a bit too complicated. What do you think?
<EuAndreh[m]>ng0: I didn't install any extra package now, I'm movingo to Guix slowly. I guess I'll hit some walls as you mentioned.
<demotri>roptat: BTW, I saw you used often java-tomcat at places where the pom.xml only needs a servlet-api. Any reason for that? I was trying to eliminate that, but did not succeed everywhere.
<ecbrown>roptat: efraim: i've submitted a bug report about the openssh server debbugs #32197
<pkill9>when i run `guix pull` it's hanging currently
<pkill9>is there an issue with build servers?
<nixd>Does building lyx (2.2.3) fail for anyone else? Can anyone try for a second?
<demotri>pkill9: It's not now, but some hours ago it worked: Jul 18 2018 13:38:12 (current) guix 208df8b
<pkill9>ah, now it's stopped hanging
<civodul>mbakke: re gcc-boot0, sorry i didn't quite follow
<civodul>are you trying to upgrade to gcc 6?
<jonsger>civodul: yes
<civodul>awesome
<civodul>mbakke: this is the patch i had: https://paste.debian.net/1034268/
<civodul>well the SIGCHLD part is unrelated
<jonsger> https://gitlab.com/jonsger/Guix/commit/980aecf0d048d51f9196b7994320683b87aa43a5 thats what we have
<civodul>now that we have replaced C_INCLUDE_PATH with CPATH, it should Just Work
<civodul>jonsger: oh excellent
<civodul>so how does it worK?
<jonsger> http://paste.opensuse.org/view/raw/30116438 thats what I get when build gcc6.4
<mbakke>civodul: The problem is that gcc-boot0 (when using GCC6) fails to build due to missing C++ features from the bootstrap compiler (IIUC).
<civodul>../../gcc-6.4.0/gcc/system.h:540:20: error: conflicting declaration of C function 'const char* strsignal(int)'
<civodul>this is a conflict between libiberty and glibc@2.27
<civodul>mbakke: really? the log above suggests conflicting libiberty declarations
<civodul>i'd look for a patch against libiberty
<mbakke>civodul: Oh :)
<civodul>first, is there a more recent GCC 6.x?
<jonsger>6.4
<jonsger>and we have 6.4
<civodul>ok
<civodul>or would it make sense to switch directly to 7.x?
<jonsger>I think I tried it already, but we can do it again
<roptat>demotri: I think I used tomcat when our servlet-api didn't work
<roptat>because tomcat also implements some version of servlet-api
<mbakke>I think it would be good to do a round with GCC6 first, just to document all the bugs coming from that, and then jump to GCC7 for the next core-updates.
<roptat>demotri: that's in tomcat, right?
<snape>ecbrown: and if you reboot again, it doesn't work anymore?
<ecbrown>snape: it quits again if i reboot
<ecbrown>doesnt start
<ecbrown>then reconfigure fixes it again
<roptat>demotri: ok, I've seen the issue. Fixing that in ant would be great!
<roptat>it seems to be the best solution, unless tstamp has a different semantics than what I think
<roptat>there are a few things to fix: https://ant.apache.org/manual/Tasks/tstamp.html
<roptat>DSTAMP, TSTAMP, and TODAY properties, as well as ant.tstamp.now and ant.tstamp.now.iso and of course the tstamp task
<mbakke>I could not find any libiberty related commits in the GCC6 branch (which seemed stale), so trying to bootstrap 7 now.
<roptat>ecbrown: when it fails to start, can you run "herd restart ssh-daemon"?
<roptat>and does it work?
<mbakke>ACTION goes afk again
<ecbrown>roptat: let me try that
<roptat>demotri: do you want to work on this issue?
<demotri>roptat: servlet-api: I added 3.1.0 from javaee. That eliminates most, but not all. Will send out patches soon.
<roptat>thanks!
<demotri>roptat: tomcat-timestamp: I think I will add a substitute*-patch to the stack. I don't know about Ant. I will look into it, but no promises. I have too many things on my desk ...
<ecbrown>roptat: yes i can successfully run that command. it says ssh-daemon is not running, then says has been started
<ecbrown>and it works
<snape>and then if you reboot it doesn't work again... very weird
<snape>hmm hmm hmm the openssh service doesn't depend on networking...
<demotri>nixd: lyx, that is not a second. Currently at texlive...
<ecbrown>/var/log/messages has a few other tidbits: theres a ton of services (avahi...) that can not be started
<snape>mbakke: why doesn't ssh depend on networking?
<roptat>I think it only depends on the loopback interface
<roptat>like, it's possible to run ssh-daemon without a configured network interface
<snape>maybe, so that would be the bug
<snape>it doesn't require "loopback"
<roptat>that should solve the bug then
<snape>yep. Who does the patch? :p
<roptat>I don't have access to my private key right now, but I can do that in a few hours
<snape>cool! I'll let you reply to the ticket as well then.
<ecbrown>thanks in advance
<roptat>ok
<demotri>roptat: BTW, any idea about #32193?
<roptat>no, I haven't investigated yet
<demotri>roptat: OK.
<pkill9>is anyone working on creating a 'user-friendly' installation? like with other distros?
<ecbrown>like create-virtualbox-vm ./my-config.scm ?
<ecbrown>or menu based like e.g. debian?
<pkill9>like you boot up and a window appears which guides you through the instlalation
<ecbrown>i use emacs-guix :-D
<demotri>pkill9: Yes, there is some branch for a graphical installer.
<nixd>Has anyone had problems installing the lyx package? It seems to consistently fail for me.
<demotri>nixd: I tried but had no space left for tex-live. I have to clean up some space :-)
<demotri>nixd: Hydra says it's failing since about 2018-05-28
<demotri>nixd: https://hydra.gnu.org/job/gnu/master/lyx-2.2.3.x86_64-linux
<demotri>nixd: Other platforms don't look better.
<demotri>nixd: Go into latest evaluation, click on the "raw" logs. Some QT issues.
<demotri>nixd: Sorry, have to go now.
<nixd>demotri, Alright, so its not just me. I tried looking at hydra but Im completely unfamiliar with it, so I wasn't sure. Thanks anyways
<wigust->Hello Guix, Could I create a symlink A -> B, where A and B are non-existing files in a package definition?
<wigust->‘ln -s A B’ does it unlike ‘symlink’ procedure. Should I use ‘ln’?
<lfam>wigust: The symlink procedure complains?
<wigust->lfam: yes, http://paste.debian.net/plain/1034282
<wigust->directory, where A file will be, exists
<lfam>I think it *should* work. symlink(2) allows for dangling links
<lfam>Are you sure you have the arguments in the right order?
<lfam>The Guile docs: https://www.gnu.org/software/guile/manual/html_node/File-System.html#index-symlink
<wigust->Hm, maybe I miss the order
<wigust->Yes, thank you, lfam
<lfam>It took me years to remember the order
<buenouanq>guix: system: command not found
<buenouanq>what on earth
<lfam>buenouanq: Is it with `./pre-inst-env`?
<buenouanq>guix system reconfigure /etc/config.scm
<buenouanq>is what I'm trying to run
<lfam>Hm... make sure you have guile-json and guile-sqlite3 available. My bet is that if you did `strace -f guix system reconfigure /etc/config.scm` the "missing command" would be one of those
<buenouanq>I think I'm just going to reinstall fresh from a USB - I haven't upgraded to .15 yet.
<pkill9>buenouanq: that's a common issue, apparently you need to run `guix pull` again
<pkill9>it's something to do with an update to guix
<pkill9>this download is taking ages
***jonsger1 is now known as jonsger
<efraim>the armhf builder hydra-slave2 needs to have its system clock checked
<efraim> https://hydra.gnu.org/build/2927988/log/raw
<efraim> https://hydra.gnu.org/build/2928117/log/raw
<roptat>ecbrown: can you try "guix pull" and reconfigure your system now? I think the ssh-daemon should be fixed now
<lfam>roptat: Wow, thanks! I will be trying it too :)
<lfam>efraim: Can you send a message to <guix-sysadmin@gnu.org>?
<efraim>lfam: sure
<davidl>I just managed to boot a btrfs subvolume running guix! :D
<hulten>Hello!
<davidl>Hello hulten!
<hulten>Why is there in my GuixSD a seemingly generic path name pointing to an openssh-specific path?
<hulten># realpath /run/current-system/profile/var
<hulten>The second paste, the output, is:
<hulten>For some reason I cannot paste it here.
<hulten>SLASHgnu/store/9skxkr5i1q2vcy1k9zzs0lg1lrf9q8xk-openssh-7.7p1/var
<hulten>Ah I should escape the slash in irc, probably :-)
<roptat>(you can't paste it because it starts with a /)
<hulten>\\/ maybe works
<roptat>or // depending on your client
<hulten>/works?
<hulten>Yes. In any case, why is my profile var pointing to a directory of an OpenSSH package?
<lfam>The reason is that OpenSSH uses /var/empty for some things, and all the packages used by the system are joined together in a union in that /run/current-system/profile directory
<roptat>the reason is that your system profile doesn't have any other package with a /var directory, so instead of linking all files from openssh, it just links the directory
<roptat>:)
<lfam>It's a race! ;)
<roptat>I lost though
<lfam>This case is a bit confusing, with only one package containing a var/ directory
<hulten>Could you show me a >=1 package case?
<lfam>The bin/ directory adjacent the the var/
<lfam>It has links to all the bin/ directories in all the packages used in the system profile
<lfam>Or rather, links the the contents of all those bin/ directories
<hulten>I understand. I guess you could say that Guix tries to minimize the number of inodes.. or that is a consequence of the underlying logic anyway.
<lfam>roptat: Your commit doesn't fix <https://bugs.gnu.org/30993> for me :( Oh well. I will do some debugging now
<pkill9>i shoulda got a sata-usb adapter
<roptat>lfam: oh, I was so sure it would fix everything :/
<roptat>actually it's not the bug I was trying to fix
<roptat>do you think it's related?
<lfam>No, but my fingers were crossed :)
<roptat>I don't reboot my server often, but I never had the issue I think
<pkill9>can you add luks encryption to a partition without wiping it?
<hulten>Does anyone here have experience in getting a Samsung printer work on GuixSD.
<hulten>I have a PPD file for it, so alternatively the question would be: How should I provide the PPD file properly to the cups service?
<hulten>(it's a ethernetworked printer)
<lfam>Hm, when I try to a shepherd@4.0 for my user it fails like this: No such file or directory: "/run/user/1000/shepherd"
<lfam>Shouldn't it be created automatically?
<hulten>(Nevermind, my printer seems to work now.)
<qwertasd>How should I write the path in shebang on GuixSD? I started reading the guile manual and tried to write a small script but I cannot execute it.
<lfam>qwertasd: You can rely on this existing: /run/current-system/profile/bin/bash
<qwertasd>lfam: oh, thanks
<nixd>I get an In procedure append error when trying to add the cups service to the system configuration, I added (service cups-service-type) to my services and cups to the use-service-modules list. I think this is what adding cups to the system should look like for the default configuration of cups according to the documentation. Am I missing something?
<lfam>nixd: Can you put your config.scm on <https://paste.debian.net>?
<civodul>ACTION submits guile-build-system
<lfam>Nice!
<nixd>lfam Here it is. https://paste.debian.net/1034314/
<civodul>lfam: long overdue!
<civodul>i was about to copy/paste once more
<civodul>and then i thought i'd rather do something about it
<lfam>civodul: I'm working on debugging my issues with the OpenSSH service being killed immediately with Shepherd 0.4.0. For now my best idea is to have make-kill-destructor log when it's invoked. Do you have any advice?
<civodul>lfam: no, that could work
<civodul>but note that make-kill-destructor returns a procedure, so logging should be inside that procedure
<civodul>the simplest way might be to add a patch to the shepherd packge
<civodul>*package
<civodul>you wrote above that roptat changed things in this area, right?
<lfam>I noticed that unprivileged Shepherd didn't work either because I didn't have XDG_RUNTIME_DIR set, and %elogind-file-systems (run/user/NNN) are not part of %base-file-systems, so there was nowhere to put the socket
<lfam>Yes, roptat made the openssh service depend on the loopback service today
<civodul>ok
<civodul>so you don't have elogind on your system?
<lfam>It's pretty close to the bare-bones template
<lfam>Anyways, I set XDG_RUNTIME_DIR for now, but I'm wondering if these issues could be related somehow
<civodul>yeah, good question
<civodul>would be interesting to compare with the OS configs in (gnu tests ssh) too
<lfam>I think OpenSSH *should* work without elogind or anything like it, since it's native to OpenBSD
<civodul>yes, definitely
<lfam>nixd: I'm not sure, but what if you put %base-services after the CUPS service?
<nixd>lfam Wow, that actually did the trick it seems, thanks a lot
<qwertasd>"libguile.h not found" hmmm
<qwertasd>pkg-config doesn't find guile package