<toothbrush0>question for Magit heroes: how does one split hunks when +/- won't go further? C-spc marking region doesn't do the trick either... <Morgawr>I wonder if somebody has tried to run guix on a Jolla phone yet... <Morgawr>I just got mine a few days ago and I've been compiling the worst kind of stuff just to see where I can push it, it would be a fun thing to do <ewemoa>toothbrush0: haven't found a good solution to that -- would like to know too :) <mark_weaver>toothbrush0: emacs' native diff-mode has a "Split hunk" command bound to C-c C-s by default. <toothbrush0>mark_weaver: ewemoa: I managed by adding whitespace before and after the terms i wanted to commit separately, then doing the C-spc trick, then removing the whitespace. <davexunit>you can't run the distro, but you can run the package manager on top of a host system. <davexunit>take a picture of the phone with the output of 'guix --version' or something if you get it running :) <Morgawr>yeah, I've been using their own package manager (pkcon) and zypper to install stuff but a lot of stuff is missing (understandably, not hoping it'd be there in guix either, just who knows) and I've been mostly installing stuff from source <Morgawr>maybe a bit overpriced hardware-wise, but I feel so free in comparison to my android phone and I can actually run and do whatever I want on it <davexunit>I really want things to get to the point where I can just use the distro of my choice + a phone friendly DE + programs with touch screen interfaces <Morgawr>At the moment I'm working on the phone by connecting it to my computer via USB, this creates a network connection between the two devices and you can ssh into it (private network) <Morgawr>I'm looking forward to the jolla tablet <davexunit>wouldn't matter if you ran debian, fedora, or guixsd ;) <davexunit>Morgawr: I would use a Jolla phone if the issue of Sailfish's proprietary components was fixed. <Morgawr>Which proprietarye pieces do they have yet <davexunit>I don't know much about it, but I hear that all the user interface stuff is proprietary <davexunit>so pretty much everything that the user interacts with is non-free, which is a real bummer. <davexunit>I just want free applications that I can use on any distro <davexunit>just like there are for all other types of computers <mark_weaver>Morgawr: one issue is that we don't yet have any ARM machines for our build farm, so there are no binary substitutes. <mark_weaver>and compiling the entire system from scratch is quite a big job, requiring a fairly powerful ARM system. <mark_weaver>I've never tried to bootstrap Guix on less than 1GB of RAM. <Morgawr>Oh, I'm fairly sure my dual core phone is powerful enough <Morgawr>but yeah, I'll try it out eventually :P just for fun <Morgawr>it took me like 2 hours to compile erlang <mark_weaver>still, bootstrapping the entire system from source is a big job. be prepared for it to take multiple days of continuous compiling. <mark_weaver>iyzsong: actually, we seem to have lost almost all of xfce <mark_weaver>I guess it's because xfconf wasn't updated. I'm working on it now. <mark_weaver>iyzsong: okay, I pushed the xfconf update. but no tests, for now at least. <mark_weaver>iyzsong: which output of font-adobe-source-han-sans do I need to see your name? <mark_weaver>well, I guess I should just install them all anyway. <mark_weaver>iyzsong: at first, I only ran "guix package -u", logged out, and logged back in, and it worked. <mark_weaver>but after running "guix system reconfigure" and then rebooting, now I can't log into XFCE anymore. <iyzsong>I haven't try 'system reconfigure', will check it next day. <mark_weaver>it says: xfce-session-CRITICAL **: Unable to contact D-Bus session bus: Failed to connect to socket /tmp/dbus-59DHMwourH: Connection refused <mark_weaver>but it's listening on /var/run/dbus/system_bus_socket <iyzsong>in the right situation, there should be a dbus-daemon (user session) running, listening on /tmp/xxx <mark_weaver>I searched in ~/.xfce4-session.verbose-log for dbus, and found nothing. <iyzsong>I guess use 'exec dbus-launch startxfce4' in ~/.xsession may help <mark_weaver>we may have to revert all of these updates if we can't fix this soon. <mark_weaver>I'm going to see if booting into my old system works with the new xfce. <mark_weaver>iyzsong: actually, it turns out that my new system doesn't work with either the new or old xfce4. <mark_weaver>and my old system works with both new and old xfce4. *mark_weaver looks suspiciously at ec4a4c46ef <mark_weaver>iyzsong: the problem was ec4a4c46ef, not anything you did. <mark_weaver>iyzsong: since I haven't said it recently: thank you very much for all of your wonderful work on Guix :) <iyzsong>I feel good when hacking on Guix, and learn a lot from folks, thanks ^o^ <toothbrush0>Hello! What can i do if "make test" fails with "Gtk-WARNING **: cannot open display:" ? <toothbrush0>I'm considering just disabling the tests that use Gtk, but that seems a little heavy, no? <iyzsong>toothbrush0: You can try to start Xvfb for tests, as in guile-sdl in gnu/packages/sdl.scm. <toothbrush0>iyzsong: That package (guile-sdl) doesn't seem to do anything with dbus, but when i use the technique from guile-sdl, it says that /etc/machine-id does not exist. Should i somehow generate that in the build envirnoment? <toothbrush0>iyzsong: Never mind, with DBUS_FATAL_WARNINGS=0 it tests fine! <iyzsong>toothbrush0: Great, I just want to say we can skip the tests, just like for dconf (in gnu/packages/gnome.scm) ;-) <civodul>mark_weaver: WDYT of building all of core-updates now? <mark_weaver>civodul: thanks for working through those encoding problems. now I'm glad that I let you handle that part :) <mark_weaver>these "lsh timed out" problems in the MIPS build box are quite a drag. <mark_weaver>I just changed things on my end so that my own server is doing the port forwarding instead of the router from my ISP. *mark_weaver hopes that will work better <davexunit>civodul: what's the purpose of the systemd-related GSoC project for dmd? Interoperability and migration? <jxself>My understanding is that it's for interoperability, so as to be able to run things like GNOME eventually. <mark_weaver>it's true that dmd can't hold a candle to systemd yet. <mark_weaver>but that can be fixed, and in the end I'll be glad to have scheme running there. <davexunit>I must admit that I haven't really learned how to use systemd <davexunit>I did a debian update awhile back and now have both systemd and sysvinit running on my systema <mark_weaver>but as I recall there are components of both used in some cases for compatibility <davexunit>yeah, I honestly don't know what's going on. <civodul>davexunit: the important part is really features (cgroups, etc.), not the syntactic stuff <mark_weaver>the other reason we can't use systemd is because it won't work on the hurd, and upstream apparently has no interest in portability to other kernels. <civodul>davexunit: so i referred to systemd because its .service model seems to make sense, but that's it <civodul>i'm neither for nor against systemd---on the contrary! :-) <civodul>(paraphrasing French humorist Coluche) <mark_weaver>civodul: until we implement the permissive UTF-8 encoding in Guile, we should probably use ISO-8859-1 for 'sed'-style operations. <mark_weaver>our patterns and replacements are probably all ASCII anyway <mark_weaver>if the patterns and replacements are ASCII, then the only thing this wouldn't get quite right is that '.' and [^...] will match a byte instead of a character in the general case. <mark_weaver>and actually, I'm not even sure it would get that part wrong, because the regexp-exec is done using the locale-encoding iirc, <civodul>mark_weaver: yes, we should have forced %default-port-encoding = #f in 'substitute' itself, but i wonder if we can still go fine from here <civodul>it's always a question of how much of an annoyance it is <civodul>if that's just a few packages to fix, that's fine, and we can fix it in the next round <civodul>if that's more, then perhaps we'll have to cancel rebuilds <mark_weaver>if you want to fix the non-UTF-8 cases individually, I'm okay with that for now. <civodul>let's see how much breaks because of that <mark_weaver>this is all temporary anyway. I intend to implement permissive-UTF-8 in Guile soon. ***Digit_ is now known as Digit
***Digit is now known as Guest71736
<bavier`>I don't know much about scons, so I might leave that to someone else perhaps ***Digit_ is now known as Digit
***Digit is now known as Guest8347
***Guest8347 is now known as Digit_
<toothbrush0>Hey, does anyone successfully use mpd (music player daemon) from Guix? <bavier`>toothbrush0: I vaguely recall encountering the same a while back. <toothbrush0>silly question though -- is there a decent emacs interface to mpd? <toothbrush0>my brief search turned up none, so i struggle along with an ncurses atrocity. <toothbrush0>i'll first have to look at the mpd segfault though. C debugging really isn't my forté. *civodul adds the /etc/ssl/certs thing in (gnu system) <mark_weaver>but several things still need the single-file bundle <mark_weaver>very carefully, maybe there's a way to get it to use the dir *mark_weaver is limited to one handed typing atm <mark_weaver>SSL_CERT_FILE and GIT_SSL_CAINFO should be /etc/ssl/certs/ca-certificates.crt <mark_weaver>(preferably the should be able to set them in .bash_profile and have them left alone) <a_e>civodul: This is not the single file in question. <a_e>This is the source code as in "preferred form of modification" (sic!) for the different files that nss-certs produces, which need to be concatenated for the single file. <a_e>I think that "cat *.pem > certs.txt" would be enough, actually. <a_e>mark_weaver: I had been reading the channel log :-) <mark_weaver>see the debian bug I cited in my email on this subject <a_e>That was a line break thing, right? <civodul>and the file name must be exactly /etc/ssl/ca-certificates.crt, right? <civodul>er, /etc/ssl/certs/ca-certificates.crt <mark_weaver>I don't think that path is currently hardcoded anywhere in our binaries <mark_weaver>/etc/ssl/certs is hardcoded in out gnutls via the configure flag though <mark_weaver>atm the moment, I have the single file in ~/ca-certificates.crt :) <mark_weaver>civodul: basically, for each *.pem file, strip the comments and make sure to output a newline after each .pem file when making the bundle. (they are not required to end with a newline, and apparently sometimes they don't) *mark_weaver has two hands again for the moment <civodul>mark_weaver: i would keep the comments to make it easier to see where each part comes from, no? <mark_weaver>civodul: it might be okay to keep the comments, I don't know. <jxself>Ah, okay. I was worried that something had happened to one of them. <a_e>civodul: It does not really make a difference. Noone is going to read the certificates in a text editor. <mark_weaver>civodul: you can read any of those certs by running "openssl x509 -text" <a_e>And if so, the .pem files have the same content. <mark_weaver>unhappy baby. need to give up some hands for a while... *civodul admits being lazy about comment stripping <civodul>for GuixSD, i guess a default value for GIT_SSL_CAINFO and SSL_CERT_FILE should go in /etc/profile, right? <mark_weaver>I guess you could test for that in /etc/profile though <a_e>SSL_CERT_DIR is easy, it is created as a search path for openssl. So this should be etc/ssl/certs inside the user profile. <mark_weaver>I always get mixed up about when /etc/profile is read <a_e>mark_weaver: Your suggestion of creating the bundled file inside the user profile sounded like the right approach to me. <mark_weaver>I think all three should be set in /etc/profile in GuixSD, and then the user can override them in their dot files if desired. <mark_weaver>I'm sorry, but the baby is not going to let me have this conversation now <toothbrush0>mark_weaver: incidentally, an upgrade of MPD fixes my issue. sending patch. <a_e>I think GSD should not provide certificates by default. <a_e>The users should make a conscious decision to install them. <mark_weaver>look, the overwhelmingly common case for GuixSD is a single-user computer. <civodul>are SSL_CERT_* honored by libssl itself or by applications? <mark_weaver>if you really disagree, we'll have to talk about this later. the baby is very unhappy with my typing right now <a_e>Have fun then! There is no urgency for us, contrarily to the baby! *mark_weaver summons a_e back to the channel <mark_weaver>I do think that we ought to create the single-file bundle in the profile creation code. <mark_weaver>and one reasonable option for GuixSD then would simply be to make /etc/ssl a symlink to /run/current-system/profile/etc/ssl <mark_weaver>and then we could provide any number of CA certificate packages, and the user could install whichever ones she wants, in either the system or the user profiles. <mark_weaver>but I'm also happy with what civodul has just commited. <civodul>mark_weaver: yes, i agree that we should do that <mark_weaver>civodul: except for one thing: the 'x509-certificates' field should be a list of packages, not just a single package. <civodul>(or you can mail a patch if you prefer ;-)) ***tschwing_ is now known as tschwinge