***grantix- is now known as grantix
<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>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 <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 <davexunit>sirgazil: setting the appropriate $PATH will avoid having to use an absolute 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>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>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? <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 :) <Sleep_Walker>it would be nice to have such splash screen implemented in DMD :b <davexunit>how long has this been around? they show an oooold ubuntu screenshot at the end <davexunit>lol of course it was the gentoo folks that showed you <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 <sirgazil>Thanks to the people who have worked on IceCat package too. Now I'm using it :) <civodul>mark_weaver is doing a great job at keeping track of the security patches <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' <civodul>right, so it's when doing scm_to_locale_string of the regexp-exec argument <civodul>but in the bootstrap guile, "locale encoding" is "UTF-8" <civodul>the problem is that i can't reproduce the problem outside of the build environment <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 <mark_weaver>I would change only the "locale encoding" to be UTF-8, and not mess with anything else. <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>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>i think we could work around that and that would be better <civodul>yes, this patch is here because the bootstrap guile cannot dlopen the gconv (iconv) modules <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: 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>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>and of course, we could make the next core-updates merge fairly soon. <civodul>i'll try some more to understand what's going on before deciding <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 <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 <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>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>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>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>not sure why it works when run outside of the build environment though.