IRC channel logs


back to list of logs

<davexunit>a_e: agreed about core-updates
<a_e>Okay, very well.
***grantix- is now known as grantix
<zacts>hey guix geeks
<rekado>mark_weaver: "A better solution going forward would be to implement and use a permissive UTF-8 encoding in Guile." <-- sounds like this would also make Lilypond happy.
<sirgazil>Hi, when using Guix on top of another GNU/Linux distro, what's the recommended way of running the software installed with Guix? (I don't have Guix installed, I use ./pre-inst-env).
<sirgazil>I'm worried about conflict with software installed with apt.
*sirgazil is on Debian, by the way.
<davexunit>sirgazil: I run guix on debian as well
<davexunit>you will want to add $HOME/.guix-profile/bin to your path, for one thing.
<davexunit>additionally, you will likely want to use the environment variables output by 'guix package --search-paths'
<sirgazil>But, say I have inkscape installed with apt and I install it again but using Guix... If I add my guix profile bin to PATH, what inkscape I'd be running? (sorry, I don't usually deal with env variables manually)
<mark_weaver>sirgazil: if you run /usr/bin/inkscape, you'll run the inkscape from Debian. if you run ~/.guix-profile/bin/inkscape, you'll run the one from Guix.
<mark_weaver>sirgazil: if you just run "inkscape", it'll run the one that is found first in $PATH
<mark_weaver>so it depends on the order of things in $PATH
<sirgazil>Ah, ok. I thought there was a way to avoid using those long paths to run the different versions.
<mark_weaver>if PATH=$HOME/.guix-profile/bin:/usr/bin:/bin then the one from Guix will take precedence over the one from Debian.
<mark_weaver>if PATH=/usr/bin:/bin:$HOME/.guix-profile/bin then the one from Debian will take precedence
<mark_weaver>long paths?
<davexunit>sirgazil: setting the appropriate $PATH will avoid having to use an absolute path
<davexunit>or relative path
<sirgazil>mark_weaver: with long I mean /.guix-profile/bin/inkscape instead of just inkscape.
<mark_weaver>sirgazil: right, no one actually does that. just set PATH
<sirgazil>davexunit: I'll do that.
<sirgazil>I'm starting to use the software installed with Guix anyway, so I'll put my guix profile bin first in PATH :)
<davexunit>yeah, guix software is newer so I tend to use the stuff from guix over the stuff from debian
<sirgazil>Another question: what benefits would I get if I install Guix, instead of keep using it with ./pre-inst-env?
<davexunit>sirgazil: it would be easier to call guix tools from anywhere in the system
<davexunit>that's about it.
<sirgazil>I see.
<davexunit>I'm always doing development, so I don't install.
<sirgazil>I'll keep using this way until I get a computer to install GuixSD.
<sirgazil>davexunit: When I run 'guix package --search-paths' I don't get any output...
<davexunit>sirgazil: that means that you haven't installed anything that requires setting additional search paths
<sirgazil>Ah, OK :) But during installation you will be told about additional search paths as well, right?
<sirgazil>I think I read that somewhere...
<davexunit>sirgazil: yes
<davexunit>what's the difference between package-search-paths and package-native-search-paths?
<davexunit>I only ever see native-search-paths being set
<sirgazil>Thanks to the person(s) who packaged Inkscape. I'm using it right now :)
<davexunit>sirgazil: I can't remember who packaged it, but I upgraded it to the brand new version recently.
<sirgazil>davexunit: thank you for upgrading it :)
<davexunit>yay, our mpd support is getting better.
<civodul>Hello Guix!
<sirgazil>Hi there :)
<Sleep_Walker>it would be nice to have such splash screen implemented in DMD :b
<Sleep_Walker>(sorry for offtopic :D )
<davexunit>Sleep_Walker: hahahahaha
<davexunit>that was muuuch longer than I was expecting
<Sleep_Walker>yeah, we would need to slow down the boot a bit :)
<davexunit>how long has this been around? they show an oooold ubuntu screenshot at the end
<Sleep_Walker>I don't know
<Sleep_Walker>I just got that on some gentoo channel
<Sleep_Walker>and I was laughing and crying :D
<davexunit>lol of course it was the gentoo folks that showed you
<Sleep_Walker>well, it's more complicated than that :)
<Sleep_Walker>quick question - I have multiline description, sentence is ending on a line, should that be followed by two spaces even it is in the end of line? should that be on beginning of first line? or should I just ommit it?
<Sleep_Walker>(uh, again my english - with "it" I mean two spaces separator between sentences)
<davexunit>Sleep_Walker: Omit it, since it would be trailing whitespace.
<davexunit>it's how M-x fill-paragraph does it in Emacs
<Sleep_Walker>will do
<civodul>mark_weaver: you around?
*civodul depresses while investigating
<sirgazil>Thanks to the people who have worked on IceCat package too. Now I'm using it :)
<civodul>good to hear :-)
<civodul>mark_weaver is doing a great job at keeping track of the security patches
<mark_weaver>hi! thanks for the kind words.
<civodul>hey, mark_weaver
<mark_weaver>though I'm not sure I'm as on top of it as we should be.
<mark_weaver>it's possible that I'm missing some things, and learning about problems later than I could.
<mark_weaver>but no one else is stepping up, so I do what I notice :)
*mark_weaver looks at that latest link
<civodul>i'm not sure i fully understand where that encoding-error comes from
<civodul>that seems to happen when there's a copyright sign in the 'configure' script
<mark_weaver>it's strange that it seems to be within a call to 'regexp-exec'
<mark_weaver>that's baffling to me
<civodul>right, so it's when doing scm_to_locale_string of the regexp-exec argument
<mark_weaver>what is the locale set to?
<civodul>but in the bootstrap guile, "locale encoding" is "UTF-8"
<mark_weaver>oh, interesting
<mark_weaver>ah right, we patch guile to do that?
<civodul>yes, see guile-default-utf8.patch
<civodul>that's inelegant, but hey
<mark_weaver>I think there might be some problems in that patch
<civodul>the problem is that i can't reproduce the problem outside of the build environment
<mark_weaver>@@ -2079,11 +2079,11 @@ scm_to_stringn
<mark_weaver>the change to that argument of mem_iconveh looks wrong
<mark_weaver>that "ISO-8859-1" refers to the internal encoding of the narrow string
<mark_weaver>also, I really don't think it's a good idea to change the port encoding of #f to be UTF-8
<mark_weaver>there's probably lots of code that assumes that port encoding #f means ISO-8859-1
<civodul>i said it's inelegant :-)
<civodul>that's a euphemism
<mark_weaver>I would change only the "locale encoding" to be UTF-8, and not mess with anything else.
<civodul>i think that's not enough
<civodul>but anyway, i'm not sure what's going on
<mark_weaver>this hunk is the same mistake: @@ -1887,7 +1887,7 @@ utf_encoding_name
<mark_weaver>(the first hunk of the patch)
<mark_weaver>I really think this patch goes way too far and will cause many problems.
<mark_weaver>most of what it changes can be done in other ways, without requiring a real locale.
<civodul>the problem is gconv modules
<civodul>i think we could work around that and that would be better
<civodul>but until then...
<mark_weaver>gconv modules?
<civodul>yes, this patch is here because the bootstrap guile cannot dlopen the gconv (iconv) modules
<mark_weaver>oh, you mean we can't use iconv?
<civodul>so eventually we should just arrange to have ISO-8859-1/UTF-8 transformations built-in
<mark_weaver>no need to apologize. sometimes it's better to get something working and then fix it up later. if it were me, my perfectionism probably would have prevented me from ever getting something like guix off the ground :)
<mark_weaver>civodul: agreed
<mark_weaver>civodul: well, i guess this means that during the bootstrap, dd0a8ef15f9 does not actually end up using ISO-8859-1, but rather UTF-8
<mark_weaver>because a port encoding of #f means UTF-8 in the bootstrap guile, right?
<civodul>problem is that if i manually run patch-/usr/bin/file from the bootstrap guile, it just works
<mark_weaver>how about this: I implement the permissive UTF-8 encoding right now, and we include that patch in our guile?
<mark_weaver>although I guess we'd have to make new bootstrap guiles
<mark_weaver>and by permissive, I mean that invalid byte sequences get mapped to some reserved set of unicode code points, as is done in emacs.
<mark_weaver>(this would be optional)
<mark_weaver>also, we should probably have a proper way to set the encoding used for POSIX byte strings (e.g. filenames, environment variables, comand line arguments) independently of the locale
<mark_weaver>these are things that we should really have in guile anyway.
<civodul>i wanted to have a short-term solution that would allow us to merge core-updates within a couple of days
<civodul>other than that what you propose is fine of course :-)
<mark_weaver>well, we could just punt on this UTF-8 encoding idea until the next core-updates merge
<civodul>if we are to rebuild, we may as well get built-in iconv modules for ISO-8859-1
<mark_weaver>yeah, makes sense
<mark_weaver>and of course, we could make the next core-updates merge fairly soon.
<mark_weaver>it needn't be a long time from now.
<civodul>i'll try some more to understand what's going on before deciding
<civodul>this is quite frustrating ;-)
<mark_weaver>honestly, I'm uncomfortable with the 'get-char*' for ISO-8859-1 input but UTF-8 output asymmetry that will corrupt non-ASCII characters.
<mark_weaver>which is what I tried to express in my response to that commit notification, but perhaps I've misunderstood something?
<civodul>no no, but it was already there in fact
<civodul>the commit just uses it for patch-shebangs, where it's harmless
<civodul>but yeah, i agree that it's not the right thing
<mark_weaver>ah, okay. well, it should be fixed anyway :)
<mark_weaver>sneek: seem jmd?
<mark_weaver>sneek: seen jmd?
<sneek>I last saw jmd on Feb 19 at 09:48 am UTC, saying: But that is not the case..
<mark_weaver>sirgazil, davexunit: I believe that jmd initially packaged inkscape
<sirgazil>Then, a million thanks to jmd :)
<mark_weaver>yeah :)
<mark_weaver>civodul: maybe running patch-/usr/bin/file manually in the bootstrap guile works because it's able to find the locales/modules it needs on your filesystem?
<mark_weaver>you might run it under strace and see if it's accessing something relevant that it wouldn't find in the guix-daemon build environment?
<civodul>i straced it but it doesn't open iconv modules
<civodul>so i don't know
<civodul>i was going to try and change gnu-build-system.scm like this:
<civodul> (when (false-if-exception (string->bytevector "works?" "ISO-8859-1"))
<civodul> (fluid-set! %default-port-conversion-strategy 'error))
<civodul>to allow for some sloppiness when using the bootstrap guile
<mark_weaver>I think the error is being caused by the mistakes I mentioned above: narrow string are being interpreted as UTF-8, so when it turns out they are not valid UTF-8 you'll get this error.
<mark_weaver>yes, I think that's the problem. the string being converted is from the file.
<mark_weaver>c_str = scm_to_locale_string (substr); (line 284 of regex-posix.c)
<mark_weaver>substr is from the string being tested
<mark_weaver>in this case, that string is the result of 'read-line'
<mark_weaver>being read with port-encoding #f, which for the bootstrap guile means UTF-8 I guess.
<mark_weaver>read-line uses %read-delimited! from rdelim.c
<mark_weaver>which uses scm_getc
<mark_weaver>if we assume that pti->encoding_mode is SCM_PORT_ENCODING_MODE_UTF8 (which I'm not yet sure), then the UTF-8 from the file will be converted to ISO-8859-1 in the string internal buffer, and then regexp-exec will interpret that ISO-8859-1 as UTF-8, which is certainly likely to fail.
<mark_weaver>so these are old problems that have been hidden for a long time.
<mark_weaver>civodul: ^^
<mark_weaver>not sure why it works when run outside of the build environment though.