IRC channel logs


back to list of logs

<davexunit>oh hey, there's a new Geiser release
<davexunit>with Chicken support
<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.
<mark_weaver>I'm not sure what you mean by +/-
<mark_weaver>ah, I didn't know about those magit commands.
<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.
<toothbrush0>Seems magit wants "context" around hunks.
<davexunit>Morgawr: are those phones ARMv7?
<Morgawr>davexunit: Yep
<davexunit>we recently gained support for that.
<davexunit>you can't run the distro, but you can run the package manager on top of a host system.
<Morgawr>Yeah that's what I was meanin
<Morgawr>I might check it out
<davexunit>give it a shot if you're interested.
<davexunit>would be cool to see that.
<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>I definitely will :D
<Morgawr>It's a really fun phone to use
<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>that is appealing to me.
<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.
<Morgawr>ah, I see
<Morgawr>yeah I can see that being bad
<davexunit>I just want free applications that I can use on any distro
<davexunit>for phones
<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 kills himself
<Morgawr>but yeah, I'll try it out eventually :P just for fun
<mark_weaver>how much RAM does it have?
<Morgawr>it took me like 2 hours to compile erlang
<mark_weaver>ah, so maybe that will work!
<mark_weaver>still, bootstrapping the entire system from source is a big job. be prepared for it to take multiple days of continuous compiling.
<Morgawr>wow that sounds like fun :D
<mark_weaver>heh :)
<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.
<iyzsong>mark_weaver: ah, thanks!
<iyzsong>davexunit: thanks for review ;-)
<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.
<iyzsong>mark_weaver: any one should work
<mark_weaver>much better! no more squares :)
<mark_weaver>iyzsong: I'm having a problem with the new xfce
<iyzsong>mark_weaver: what's that?
<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>and indeed, that file doesn't even exist
<iyzsong>is there a dbus-daemon running?
<mark_weaver>well, the system one is running
<mark_weaver>but it's listening on /var/run/dbus/system_bus_socket
<mark_weaver>I'm not sure why it's looking for it in /tmp
<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>okay, I'll try
<mark_weaver>it doesn't help
<mark_weaver>same problem
<mark_weaver>we may have to revert all of these updates if we can't fix this soon.
<mark_weaver>it's not good to break our desktops like this
<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>so I guess the problem is somewhere else.
<mark_weaver>back in a bit...
*mark_weaver looks suspiciously at ec4a4c46ef
<mark_weaver>will try reverting it and see if that helps
<mark_weaver>yes, that was the problem.
<mark_weaver>iyzsong: the problem was ec4a4c46ef, not anything you did.
<mark_weaver>I just reverted it in master.
<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: i'll give that a try then, thanks.
<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) ;-)
<toothbrush0>I think this is nicer :)
<iyzsong>yes, of course
<civodul>Hello Guix!
<toothbrush0>civodul: hi!
<mark_weaver>hi civodul!
<civodul>mark_weaver: WDYT of building all of core-updates now?
<mark_weaver>civodul: sounds good to me!
<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
<mark_weaver>civodul: did you see the evaluation error?
<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.
<davexunit>jxself: ah okay, makes sense. thanks.
<davexunit>people give us flak for not using systemd.
<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
<davexunit>and it causes a lot of confusion
<mark_weaver>only one can be PID 1
<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.
<davexunit>I have systemd services now, I know that.
<davexunit>and some old init scripts
<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)
<davexunit>I'm in the same boat.
<civodul>mark_weaver: seems like we'll have to fix quite a bunch of these:
*mark_weaver looks
<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,
<mark_weaver>oh, forget that last message...
<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>and fix it 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.
<civodul>that'll be nice
<bavier`>no scons-build-system?
***Digit_ is now known as Digit
***Digit is now known as Guest71736
<mark_weaver>bavier`: not yet!
<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?
<toothbrush0>I'm getting segfaults.
<bavier`>toothbrush0: I vaguely recall encountering the same a while back.
<toothbrush0>bavier`: solution? Or should i go digging? :)
<bavier`>dig away
<davexunit>oh it doesn't work... bummer.
<davexunit>I packaged it. sorry :(
<toothbrush0>bavier`: ok :p
<toothbrush0>davexunit: don't sweat it.
*civodul uses plain EMMS
<toothbrush0>fair enough.
<davexunit>civodul: luddite ;)
<toothbrush0>haha :)
<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.
<davexunit>toothbrush0: emms :)
<toothbrush0>ah! my bad!
<toothbrush0>better try that out.
<toothbrush0>is it, um, decent, though?
<davexunit>it was buggy last I tried, though.
<davexunit>there's a new maintainer
<davexunit>and the mpd support was given some love
<davexunit>so I'd like to try again.
<davexunit>I use ncmpcpp in the meantime
<toothbrush0>i'll first have to look at the mpd segfault though. C debugging really isn't my forté.
<toothbrush0>yeah me too
<toothbrush0>hence why i packaged it
*civodul adds the /etc/ssl/certs thing in (gnu system)
<mark_weaver>ah, yes, I've using that for a while
<mark_weaver>but several things still need the single-file bundle
<civodul>yeah, right
<mark_weaver>(git and lynx are two examples)
<mark_weaver>well, I didn't investigate lynx vert
<civodul>could this be the single-file in question: ?
<mark_weaver>very carefully, maybe there's a way to get it to use the dir
<mark_weaver>civodul: no
*mark_weaver is limited to one handed typing atm
<mark_weaver>I already explained how to make the file in email
<civodul>oh right
<mark_weaver>SSL_CERT_DIR should be /etc/ssl/certs
<mark_weaver>SSL_CERT_FILE and GIT_SSL_CAINFO should be /etc/ssl/certs/ca-certificates.crt
<mark_weaver>but allowing the user to override those settings
<mark_weaver>in their dot files
<mark_weaver>(preferably the should be able to set them in .bash_profile and have them left alone)
<mark_weaver>hi a_e!
<a_e>civodul: This is not the single file in question.
<civodul>hi a_e!
<mark_weaver>good timing
<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.
<civodul>mark_weaver: ok
<a_e>I think that "cat *.pem > certs.txt" would be enough, actually.
<mark_weaver>a_e: not quite
<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?
<mark_weaver>also, it's probably better the remove the comments
<civodul>and the file name must be exactly /etc/ssl/ca-certificates.crt, right?
<mark_weaver>well, that's what debian calls it
<civodul>er, /etc/ssl/certs/ca-certificates.crt
<mark_weaver>but it's not standardized
<mark_weaver>fedora has a different layout
<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 :)
<civodul>heh :-)
<mark_weaver>since my /etc/ssl is now owned by guixsd
<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?
<jxself>You only had one before?
<mark_weaver>jxself: two *free* hands I should say :)
<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.
<mark_weaver>heh :)
<a_e>civodul: It does not really make a difference. Noone is going to read the certificates in a text editor.
<civodul>well yeah
<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>openssh x509 -text -in foo.pem
<mark_weaver>unhappy baby. need to give up some hands for a while...
*civodul admits being lazy about comment stripping
<mark_weaver>civodul: please test with git and lynx, to mal
<mark_weaver>make sure they are okay with the comments
<civodul>ok, works with both
<civodul>for GuixSD, i guess a default value for GIT_SSL_CAINFO and SSL_CERT_FILE should go in /etc/profile, right?
<civodul>and SSL_CERT_DIR
<mark_weaver>only for login shells
<mark_weaver>I guess you could test for that in /etc/profile though
<mark_weaver>oh, nevermind
<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
<mark_weaver>yes, /etc/profile sounds good
<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.
<mark_weaver>a_e: we can support both modes
<mark_weaver>but for guixsd uses
<mark_weaver>users, it should just work out of the box
<a_e>I think GSD should not provide certificates by default.
<mark_weaver>the overwhelming a
<a_e>The users should make a conscious decision to install them.
<mark_weaver>I strongly disagree
<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
<mark_weaver>civodul: libssl
<a_e>Have fun then! There is no urgency for us, contrarily to the baby!
<mark_weaver>okay, baby sleeping now.
*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>yeah, i wondered
<civodul>we can change that
<civodul>can you mail your suggestions?
<civodul>i'm going to sleep now
<civodul>(or you can mail a patch if you prefer ;-))
<mark_weaver>okay, thanks!
<mark_weaver>sleep well :)
<civodul>good day/night!
***tschwing_ is now known as tschwinge