<ng0>nope. not fixed. temporarily fixed, back again <lfam>Any GNOME / GTK wizards around? I finally got gnome-maps-3.18 to work, but I want to to use 3.20.1. When I run it, it fails with "Gjs-WARNING **: JS ERROR: Error: Requiring Geoclue, version none: Typelib file for namespace 'Geoclue' (any version) not found" <lfam>The built output of our geoclue package doesn't have those <lfam>Should I add gobject-introspection to geoclue's native-inputs? <lfam>Well, I'm trying it anyways, but warn me if it's the wrong approach because it causes webkitgtk to be rebuilt and that takes a long time <sneek>Welcome back civodul, you have 3 messages. <sneek>civodul, lfam says: There's an open issue with msgpack, one of the opendht dependencies <sneek>civodul, lfam says: I'm not able to push a "forced-update" to Savannah, so I will `revert` instead of `rebase -i`. <sneek>civodul, lfam says: mthl pointed out that I could delete core-updates-next and then push the rebased branch to Savannah, so I did that. <lfam>Sorry for the bombardment <civodul>it must be late on your side of the pond, no? :-) <lfam>I'm a bit of a night owl <efraim>typing is hard, i'm going to suggest a patch to change --do-not-upgrade to --no-no-upgrade based on my latest typo <lfam>Wouldn't --no-no-upgrade be the same as --upgrade? ;) <efraim>you obviously don't have kids, "no no" is more than "no" but not as much as "NO NO NO NO NO NO NO!" <efraim>the gnu parallel maintainer's short gpg key is 88888888 <lfam>That's amazing. Is it recent? I think it's practical to brute force the short key ID now <efraim>i have mine set to show long key so I almost missed it <lfam>Apparently it takes 4 seconds on a GPU <boegel>anyone here can explain what's going on? is my only option to install Guix to a shorter install prefix? that seems like a silly limitation... <civodul>boegel: there's a relatively small limit of the length of socket file names in the kernel and libc <civodul>and the guix commands connect to the daemon over a PF_UNIX socket <civodul>so 'configure' is telling you that, given the --prefix and/or --localstatedir you gave, the socket file name would be longer than the limit <boegel>is there a reference for this in the documentation or something? <civodul>not in the documentation of Guix, no <civodul>it's not really a Guix problem, i'd say ;-) <civodul>you can work around it by using a different --prefix or --localstatedir <boegel>can it be tricked with symlinks? <civodul>FWIW 'configure' reports the length would be 109, and the limit is 108 (see <sys/un.h>) <boegel>anyway, nice job on catching this in the configure! :) <civodul>i think we wanted to avoid disappointing people after an hour of building stuff ;-) <boegel>I'm very interested in a setup where I don't need root <civodul>it's difficult though, because we're hitting OS limitations here <boegel>civodul: is it only chroot that make Guix require root for the daemon? or is there more to it? <civodul>boegel: chroot(2), mount(2), etc., everything needed to set up a container <civodul>one solution we could use, and which 'guix environment --container' implements, is "user namespaces" <boegel>civodul: seems like PRoot may be providing that? <civodul>however, this is relatively new and disabled on many GNU/Linux distros <civodul>some think the feature is not mature enough ***Digitteknohippie is now known as Digit
<jlicht>Can I let guix make use of the guile-json module on the build-side of things? <civodul>jlicht: you could; see how (guix download) manages to use the GnuTLS modules on the build side <civodul>it's less convenient than when using pure Scheme modules, but it's feasible <civodul>but still, it's outside of Guix, so you'd rather not just #:imported-modules '((json)) <jlicht>or you mean, rather not have the dependency? <civodul>jlicht: i mean that it's best to follow the same pattern that (guix download) uses <rekado_>I find it annoying that so many files need to be recompiled whenever I switch between git branches to apply patches. Is there a way to avoid this? <mark_weaver>rekado_: I use the 'git-new-workdir' script that comes in the contrib directory of the git sources <mark_weaver>and using that, I have multiple checkouts, each on their own branch, but sharing the same git repository <thomasd>Hi, I'm new to Guix. Trying to create a package where I have to patch the source, and not being successful ;) <rekado_>mark_weaver, civodul: Cool. I'll try that. <thomasd>When I don't include a patch, Guix builds/compiles the package right up until where it hits the bug I want to patch (so far, so good). <thomasd>But when I do include a patch, I run into "tar (child): gzip: Cannot exec: No such file or directory" <rekado_>thomasd: could you paste the complete package definition somewhere? <jlicht>thomasd: it seems tar can't find gzip. Is the only difference between your package definitions the patches in the `patches' field? <rekado_>civodul: I see that our patchwork page lists a lot of patches that have already been merged. <rekado_>eg. aqbanking, gwenhywfar, gnucash (2x), xmlsec. <rekado_>I have an account there, but I cannot modify patches there. <mark_weaver>thomasd: pastebin.com blocks tor users, so I can't access it <civodul>rekado_: yeah that sucks, i don't want to spend time clicking on it :-/ <civodul>thomasd: most like .Z is not handled <mark_weaver>thomasd: the problem is that guix doesn't recognize the .tar.Z suffix, so it doesn't know which decompression program to include <mark_weaver>I guess this is the first package we've come across so far that uses .Z suffix <civodul>i think we don't even have the package that provides 'uncompress', do we? <thomasd>it does uncompress and start to configure/compile the package when I leave out the patch <mark_weaver>gzip supports .Z, and it seems that 'tar' tried to run gunzip <civodul>in the old days there was an 'uncompress' command <mark_weaver>thomasd: as a temporary workaround, it *might* work to add a 'file-name' field to the 'origin' that changes the extension to .gz <mark_weaver>(file-name (string-append name "-" version ".tar.gz")) <mark_weaver>that would definitely warrant a comment explaining that this is just a workaround to cope with the fact that guix doesn't know about the .Z extension <civodul>ACTION asks Hydra to evaluate core-updates for the Boost changes <jlicht>mark_weaver: unclutter in (gnu packages xdisorg) also uses the .Z suffix. <thomasd>mark_weaver: the (file-name ...) work-around works! <thomasd>so it seems that the .Z suffix is only a problem at the patching stage? <civodul>though i'd rather use call-with-containers! <davexunit>on that glorious day when we replace the daemon with a guile program <jlicht>davexunit: what is wrong with the current daemon? <jlicht>(besides the RPC interface being perhaps a non-optimal way of interacting with it) <davexunit>jlicht: it's written in C++ and uses a custom protocol <davexunit>basically no one here wants to hack on C++ code <davexunit>and we can't share code from the rest of guix with the daemon <davexunit>rewriting it in Guile and using Scheme s-expressions as the serialization format would be great. <jlicht>davexunit: sounds like lots of {fun,work} <jlicht>btw, what is the reason for the tiny `; deprecated' next to `build-expression->derivation' in (guix derivations)? <civodul>jlicht: it's superseded by gexp->derivation <civodul>davexunit: re the daemon, there are many changes that we'd like to make and that are inconvenient to make <civodul>plus it's also not great to be downstream since there's too little discussion with upstream <civodul>plus the C++ code duplicates some of the things we have elsewhere <lfam>I am wading through compilation errors of gnome-maps 3.20. Fixing one at a time like hacking through vines in a jungle <lfam>The software is friendly enough to only present one at a time <lfam>Hmph. Can't build gnome-maps-3.18 without geoclue, but geoclue is not referred to by the gnome-maps output <rekado_>looks like a patch I've sent to the list more than two hours ago didn't make it to the archives. <rekado_>has anyone received a mail with a patch for r-bsgenome-mmusculus-ucsc-mm10? <rekado_>(we already have mm9, which is a different revision of the mouse genome) <lfam>rekado_: From you I received gengetopt and log4cpp <davexunit>civodul: I thought I was using the mirror so I was surprised to see a hydra.gnu.org URL <davexunit>for now I just did the ol' 'guix environment foo --search-paths && guix build --no-substitutes foo' trick <rekado_>lfam: thanks. I'll wait until tomorrow and then resend if it hasn't appeared by then. <optikalmouse>and of course their package definition files look like plain old BASH scripts, more similar to arch linux's package install scripts. <rekado_>davexunit: I found that on my laptop I'm still using hydra.gnu.org instead of the mirror. Not sure why. <lfam>rekado_: Maybe a spam filter found this string suspicious "r-bsgenome-mmusculus-ucsc-mm10" ;) <optikalmouse>davexunit: the only advantage I can see is that guix doesn't handle package interaction like a web server + database server configuration or whatever <optikalmouse>though I guess you do that with a custom package definition anyway? <davexunit>optikalmouse: of course it does! that's what GuixSD does <rekado_>I would like to have more of GuixSD on foreign distros. <rekado_>shepherd doesn't need to run as PID 1, after all. <optikalmouse>davexunit: how does that work, is there an example you can point to? <davexunit>optikalmouse: see any module in (gnu services ...) <davexunit>this Habitat thing is still most a stone-age packaging system. <davexunit>it seriously lets you specify "dependencies", but then run 'npm install' during the build <davexunit>I think that dependency graph might be missing a few hundred items! <davexunit>it conflates building the software with configuring and running it <civodul>woow, the level of marketing is so high on habitat.sh that it's hard to follow <lfam>You can run both greenfield *and* legacy applications! <lfam>The problem for my use case is that blue is my favorite color <lfam>Darn. Guess I'll stay here <civodul>OTOH most of the logos on that page are blueish <rekado_>I'm afraid that what makes these things successful is that they are undisciplined. "It's just bash scripts!!!" is a feature. It's also terrible. <rekado_>that's why conda is used by Galaxy to install applications. <lfam>In my experience people hate maintaining bash scripts. So, there must be a hangover later on, right? <rekado_>these conda recipes are yaml files with bash scripts to install. <rekado_>and these bash scripts do nasty things like copy a prebuilt binary somewhere. <lfam>Like how Docker seems great until you need to do a security update <rekado_>all this conda stuff quickly fell apart for us when we had to add our own application to the Galaxy system. <rekado_>these systems make it so easy to do bad things. <lfam>Here is a doozy: "...I think we have to pay particular attention to technologies that continuously deliver desired end-states, and across diverse production environments, otherwise we're just speeding up over-the-wall procedures." Somehow that is an endorsement of habitat.sh <lfam>Is "over-the-wall procedures" something I should know about? <rekado_>but they are flexible enough for "real world applications" (i.e. a poorly designed mess of bundled code) <lfam>True flexibility comes when you can understand and control your system <lfam>Anything else is just flailing <lfam>Here are some of the variables in gnome-map's ./configure script: GNOME_MAPS_LIBS, GNOME_MAPS_LIB_LIBS, GNOME_MAPS_CFLAGS, GNOME_MAPS_LIB_CFLAGS <optikalmouse>I think I have to do for gnu guix what I did for scheme many years ago; convert common usages from other tools to use it. <optikalmouse>like a few docker or habitat tutorials or something, best way to learn. <davexunit>civodul: how do you feel about adding an environment variable in 'guix environment' that contains the store path of the profile that was generated? <davexunit>or making that the new value of GUIX_ENVIRONMENT <lfam>If feasible, I would like that very much <lfam>So that I don't have to parse the output of $PATH or similar <civodul>davexunit: sure why not; what's your use case? <optikalmouse>davexunit: in the habitat example they have two steps; do_build whose guix is just using the right build system with the correct options, and they have do_install which are the shell commands to run after package install. what's the guix equivalent of that? <davexunit>civodul: the current use case is a script that will 'cd' into a directory within the profile before running a comamnd. <davexunit>I have a web application that needs to be run from its own special directory <davexunit>it's in the profile, I just need to know how to get there programmatically <rekado_>davexunit: I'd like that. I repeatedly had to cut out the profile dir from the PATH variable. (Forgot why I had to do this, though.) <davexunit>rekado_: heh, that's the hack I'm doing now. :) <efraim>about the guix-daemon from almost 2 hours ago, can we rewrite it piecemeal or are we looking more for a drop-in replacement? <lfam>I do it just to inspect package outputs when testing with `--ad-hoc` <davexunit>optikalmouse: can you send me an example of do_install? <davexunit>lfam: yeah, I think there are many use-cases here. <davexunit>that reminds that I've also been meaning to make 'guix environment' usable as a shebang <davexunit>but oh darn, I think there's a problem there. I *hate* shebangs. they are so limited. <davexunit>you couldn't do '#!/usr/bin/env guix environment' <rekado_>but in Guile extended shebangs work, no? <efraim>#!/usr/bin/env guix-environment? like man guix-environment? <davexunit>guix-environment isn't an executable, everything is under 'guix' <davexunit>anyway, that particular problem can be thought about later, but it would aid scripting <davexunit>rekado_: yeah there's a hack that we could also do. <davexunit>I guess we'd have to bake in the shebang stuff into the 'guix' program itself <CompanionCube>ACTION should investigate having a GuixSD stratum in his Bedrock at some point <davexunit>though I can't imagine it would be a pleasant interface. what other command could possibly interpret a shell script? <lfam>What I don't understand about that habitat script is why nothing seems to check if any of the commands succeeded. Unless there is a hidden 'set -e' somewhere <davexunit>optikalmouse: guix package build scripts have an install step that installs files into their output directory <rekado_>optikalmouse: this is abstracted away in build systems, but it is possible to add arbitrary build phases. <civodul>davexunit: speaking of 'guix env', i wonder if we should allow piggy-backing environment info in package 'properties' <efraim>we should add an addable autoconf phase <civodul>davexunit: for instance i often do "guix environment foo-dev --expose=$HOME/.gdbinit" <civodul>davexunit: i'd like to store this file-system-mapping somewhere so that it happens automatically <rekado_>efraim: dunno, it's usually just a couple of lines. <efraim>it is, but I'm sure we have a lot of occurances of it <rekado_>efraim: if it would also add the needed packages to native-inputs, that would be convenient, though. <civodul>davexunit: but maybe we need a different kind of objects to describe that, rather than abuse properties <rekado_>efraim: true. Just a build system flag "#:needs-bootstrapping? #f" <davexunit>civodul: so would the feature be: automatically expose directories in the user's home directory? <civodul>davexunit: rather, the feature would be: provide additional info on how to set up the environment <ng0>do i need something to make `guix import cpan` work? ERROR: no code for module (json) <civodul>davexunit: it could include things like the type of env (--container or not, --networking or not), file system mappings, commands to run on startup, etc. <civodul>rekado_: just because it's an easy hack :-) <rekado_>ng0: you need guile-json and it needs to be on the GUILE_LOAD_PATH. <davexunit>civodul: so this would probably be more for people's custom packages than stuff we'd have in guix itself, right? <ng0>ah, logical. thanks:) <optikalmouse>davexunit: is there an example of the package build scripts in the manual? or do I have to look at a repo's code for that? <davexunit>if you want to see implementation, then the source is where you want to look <lfam>optikalmouse: All the Guix code (package recipes and Guix itself) are in the same repo <optikalmouse>ah gotcha and then use trivial-build-system or just use my own symbol/procedure list passed to gnu-build-system? <lfam>It's much easier to read and write a modified gnu-build-system than trivial-build-system <lfam>You use modify-phases to alter the build system in the package recipe <davexunit>yeah, trivial-build-system has its place, but usually you want to use something else as a base <lfam>There are many examples in gnu/packages, although you should ask for help if you get stuck <davexunit>speaking of build systems, I should add a scons build system <lfam>Yes, I recently had to copy an existing example for a WIP package! <lfam>Cursing the upstream maintainers the whole time ;) <davexunit>... you don't even want to see my Kaldi package <lfam>Sounds like Kodi... another monster <lfam>I was really amazed by that. I should see if I can understand the package definition now <davexunit>I wonder if I even understand it now. hopefully I left a bunch of comments. <lfam>Is it preferred to use LDFLAGS at configure time rather than LD_LIBRARY_PATH at run time? <davexunit>lfam: you should basically never use LD_LIBRARY_PATH <lfam>gnome-maps can find gnome-online-accounts (goa) when I use LD_LIBRARY_PATH in a wrapper. But when I use LDFLAGS=-L$(goa)/lib and CFLAGS=-I$(goa)/include, gnome-maps cannot find goa <lfam>I also included LDLIBS=-lgoa <bavier>lfam: it's possible the build system clobbers a user-defined LDFLAGS in the build environment <lfam>bavier: I think the flags do work because I'm successfully using them to provide another library <lfam>Maybe -lgoa is wrong? Perhaps I should provide the full path since there is no file 'libgoa', but instead files such as 'libgoa-1.0.so' and ;libgoa-1.0.a' <bavier>-lgoa-1.0 might be appropriate then <kete>My installation finished, but guixsd would not boot. How can I troubleshoot? <lfam>kete: How does it fail to boot? <kete>It doesn't detect a system to boot. <ng0>hm.. perl package "Curses" wants DynaLoader ... or at least only for testing phase. can I disable the testing phase? <lfam>kete: Libreboot uses its own GRUB, right? So the system can't even reach the GRUB installed by Libreboot? <lfam>bavier: Thanks for the advice, but still no joy <ng0>my libreboot grub reaches the other grub just fine, the stock libreboot. <bavier>ng0: do we not have DynaLoader packaged? <lfam>kete: There are some Libreboot / GuixSD users here. I hope they see your messages and have some advice <ng0>kete: is this stock (prebuilt) libreboot or a custom one? <ng0>bavier: should I package DynaLoader? <kete>it was the latest libreboot, not custom <ng0>bavier: although i am not sure if it really wants dynaloader, it reads like it so i'm 99% sure <bavier>ng0: DynaLoader is in core in perl@5.25.1 <bavier>if its not in core in 5.22, then you can create a separate package <lfam>I wonder if there is some bug with gnome-maps and libgoa. The string 'goa' does not appear in the build log except where the configure flags that I have set are printed <bavier>if the cpan importer didn't put dynaloader in the inputs, its probably in core <ng0>it also did not put ncurses in there, but i did that because it requires it. <ng0>but there's moire than just ncurses, so idk how to fix that <bavier>its just saying it can't load the curses library <ng0>what do you suggest to do? <bavier>ng0: does the Curses.so perl xs library have the correct rpath to ncurses? <lfam>davexunit: "The main drawback of nix is that no one knows how to use it." <ng0>how do I check that? <davexunit>I responded to item #1 in that user's comment <lfam>"I really don't see how much it could possibly borrow from Nix if it threw out the most important part of it." :-o <bavier>ng0: build with --keep-failed and run readelf on the shared library <ng0>bavier: ncurses is not the only curses implementation i guess, so a input ncurses is just a beginning. <ng0>i don't see a .so , only a .o in the tmp dir <ng0>see/ sorry i forgot to grep <bavier>ng0: nothing in Curses-1.34/blib/arch/auto/Curses/? <ng0>i never used readelf, how can i just get what i need? <bavier>ng0: 'readelf -d' would be better <lfam>Okay, I checked the built output of gnome-maps. Nowhere in the binaries does the string 'goa' exist. Not even under /usr. <lfam>Does this indicate that it lacks the ability to embed the path to the library? <bavier>lfam: nothing in the libs either? <ng0>Ishould've read the INSTALL, i just assumed it would work this way. will do now, thanks :) <bavier>np, its nice if Things Just Work <ng0>what happens when we get more than just ncurses for curses? <ng0>currently it's theonly curses <lfam>bavier: No hits in lib/. There are some 'goa' strings in share/, but no 'libgoa' string <ng0>i know of at least a suckless implementation <lfam>It must use some GNOME thing to know to look for libgoa <ng0>probably the same puzzle than with libressl v openssl then. <bavier>lfam: ok, I thought maybe gnome might be dlopening libgoa <ng0>ah, it describes what happens with other curses <lfam>bavier: The files are in share/gnome-maps and they are GVariant Database files, and one gjs script <lfam>Oh, the gjs lacks a string <lfam>It's only the file share/gnome-maps/org.gnome.Maps.src.gresources <lfam>Which does import a number of libraries, but not libgoa <lfam>It must expect to find it in the environment <lfam>So, should we use LD_LIBRARY_PATH while packaging this slightly outdated version of gnome-maps? I'm hoping that the latest release doesn't have this issue, and if it does, I can file a bug report <lfam>Also, should GNOME applications be able to run outside of GNOME? <bavier>lfam: I run a few GNOME apps in ratpoison <lfam>Hm, okay :) This one doesn't work fine yet <lfam>Can you say which apps so I can compare them to gnome-maps? <bavier>gnome-mines, evince, shotwell, epiphany <efraim>wasn't gnome-mines one of the first applications they sandboxed? <lfam>I'm reminded that there is a new release of shotwell that fixes a nasty bug <bavier>lfam: I've updated shotwell, just haven't pushed it yet <bavier>I've been slow to push things lately <lfam>Maybe you should send it to guix-devel while it's on your mind :) <ng0>bavier: can I just use /lib/ncurses or do I have to let a path to be constrcuted? <ng0>looking at bioinformatics.scm for how to set it <bavier>lfam: for sure. looks like it was updated again in the meantime <lfam>It's worth having a newer-but-not-latest version if it fixes that bug <efraim>i'm taking a look at the qt inputs again, the necessary inputs look like they are so few that its not even worth inheriting <efraim>the only references for qtlocation are glibc, gcc:lib and qtbase <anthk_>hi, it's gdm + a wayland session planned for GuixSD? <davexunit>anthk_: if someone volunteers to do the work. <efraim>i was looking at getting wayland with enlightenment working, but that's still a ways off until I get to it <kristofer>hey guys! how do I get the current guile include directory in my package definition? <davexunit>they have the "do_download" function compute the checksum of the thing it just downloaded <davexunit>pkg_shasum=$(trim $(sha256sum $HAB_CACHE_SRC_PATH/${pkg_filename} | cut -d " " -f 1)) <davexunit>this gets the hash of the thing downloaded, and elsewhere in the package file you specify the expected hash. <optikalmouse>that's such a...this is what happens when you do have a real programming language available? <davexunit>are you referring to the fact that this is all in bash? <davexunit>yeah, it's bad. the core is written in Rust, but the programming interface is allll bash. <kristofer>I have to pass the include directory to cmake in order to build the guile bindings. It doesn't seem to care if GUILE_INCLUDE_DIR is set <davexunit>kristofer: I've never heard of GUILE_INCLUDE_DIR before <kristofer>me either, it's the command line variable passed to cmake to build opencog <davexunit>(string-append "-DGUILE_INCLUDE_DIR=" (getenv "GUILE_LOAD_PATH")) or whatever <kristofer>I need the path to include/guile/2.0/libguile.so <davexunit>GUILE_LOAD_PATH must not be what you're looking for <davexunit>okay, so assuming guile is an input to this recipe <davexunit>(string-append "-DGUILE_INCLUDE_DIR=" (assoc-ref inputs "guile") "/include/guile/2.0/libguile.h") <davexunit>again, just guessing but something resembling that <davexunit>also assuming that the code is within a build phase procedure that has bound the "inputs" keyword argument <kristofer>cogutil builds fine, and inside an environment I can build atomspace, but I've gotta figure out the -DGUILE_INCLUDE_DIR part <davexunit>if you don't know how to use it, refer to the many packages that specify it <kristofer>I'm getting a few warnings from ld saying libraries can't be found, it suggests using -rpath or -rpath-link <lfam>I already added gsettings-desktop-schemas and libgweather to the inputs in response to error messages <lfam>But, it does work within GNOME! <optikalmouse>a console to get you to learn the bad way of doing things. <bavier>maybe guix needs moar awesome ascii art and colors in its cli <cehteh>and nethack on a vc from the installer, like nix :D <lfam>We need to finish the nethack package <ozzloy>i installed guix, finally! i would like to use it to hack on guile and skribilo. what's a good place to start for that? <lfam>This is a really bizarre part of the gnome-maps error output: <lfam> Gjs-WARNING **: JS ERROR: Error: Unsupported type (null), deriving from fundamental (null <lfam>ozzloy: You will probably want to install them for your user with `guix package --install guile skribilo` <bavier>ozzloy: for hacking, `guix environment` is nice <lfam>Weird. gnome-maps isn't actually exiting with failure. It just hangs open <davexunit>ACTION is writing a Chef cookbook for installing Guix. weird times. <lfam>davexunit: You should use habitat.sh to continuously deliver the desired end-state <ozzloy>is anyone working on a debian package for guix? <lfam>ozzloy: Yes, detrout was working on one. I'm not sure of the status <lfam>It appears that Guix will never be in the official Debian repos because we don't respect the FHS. But, a package could be provided by a 3rd party repo <lfam>Search the guix-devel archives for debian and trout <efraim>iirc she built a working package, but it's not guaranteed to uninstall cleanly <ozzloy>is there no way for guix to respect the fhs? <cehteh>i wonder if one can make it FHS confirming again with namespaces/bind mounts etc. each user sees a fhs compliant filesystem for his profile <ozzloy>what would be involved in bringing the fhs in line with guix? <lfam>Bureaucratic blood, sweat, and tears <cehteh>but that would need a lot work and research <ozzloy>actually, i don't care about that right now <davexunit>cehteh: it's possible. we want to explore this. <davexunit>unprivileged user namespaces need wider adoption across distros, though. <bavier>didn't we at some point discuss the option of having `guix environment` create an env with FHS? <davexunit>the profile generated by 'guix environment' can simply be mounted at /usr <ozzloy>so i mentor a highschool robotics team at Fremont High School. i'm much more used to FHS referring to that <ozzloy>i was confused when you first mentioned it <lfam>Sorry, I should have unpacked it <ozzloy>no biggie. i figured it out. it was funny <lfam>Man, I wish my high school had had that. Sounds really fun <lfam>ozzloy: Are your Guix-installed applications working with UTF-8 correctly? <lfam>Is it just Guix itself that gives the warning? <lfam>Install a program that displays text and make it display some non-ASCII text <lfam>Also, did you try sourcing ~/.guix-profile/etc/profile wherever you configure your login shell? <lfam>It only takes effect when you log in? <ozzloy>bavier, i had not read that, but it has the same instructions as the page i did read <lfam>The locale warnings are just warnings. Unless you have trouble displaying UTF-8 it shouldn't stop you :) <lfam>ozzloy: A text editor should work. Find some non-ASCII text and try to view it in the editor <lfam>It also tests how much of the full Unicode plane you have fonts for <lfam>ozzloy: I don't know how to make it work on Debian for Guix itself <lfam>But in practice it's not a problem <lfam>Because I use the US English version. If I used a translation it might be an issue, I'm not sure <ozzloy>i'm going to not worry about it and move on to hacking skribilo <ozzloy>i want to add a (video ....) form <ozzloy>i have some ogv i want to embed in the html output of documentation i'm making <efraim>although interestingly it shows up better in links than in `links -g' <lfam>Do you have a big UTF-8 font installed? Like the Unifont? <lfam>Then I don't think that page will have much to look at :) <efraim>so I should get font-gnu-unifont? <lfam>I see less in links than in firefox, but there are still some things displayed <lfam>I keep that font installed <optikalmouse>ugh I'm just disappointed that coworkers are excited about it and I can't convince them that guix is neater <efraim>lfam: for unicode, you have just out or also the other outputs? <lfam>efraim: I didn't knowwhich output to install so I installed all of them :p <lfam>I think the difference is that they are different formats <lfam>You should get all the glyphs with any output, but in different formats <efraim>i'm wondering if I should get the console one <lfam>That's how I can read iyzsong's name properly in mutt :) <efraim>I see three diamonds with question marks in the middle of them <lfam>I don't think that's right ;) <civodul>"Habitat offers a new approach to deploying applications called application automation." <optikalmouse>snap apps from ubuntu. it looks like everyone is dissatisfied with package deps and installs <efraim>who doesn't love bundled dependencies? <lfam>Yeah, everyone has had their imperative package manager break their system completely <optikalmouse>this is an interesting point in the comments: "I question the security claims. Containerization is nice, but the next OpenSSL vulnerability will require every upstream to rebuild and distribute updated snaps instead of the distro providing a single patched OpenSSL build. " <lfam>It might be "required" but it probably will not happen <civodul>damn, anyone has contacts at Ars Technica? <civodul>"Goodbye apt, yum, and snap. Guix is coming to distros everywhere." <civodul>"Applications packaged by Habitat display the following characteristics in a production environment: [...] They are security aware, which means they are encrypted at the artifact and secret level." <lfam>Please, people might be allergic to bees in this channel ;) <civodul>there's no limit to what people write on marketingy web sites it seems! <lfam>I recently heard some people talking about "data lakes", so I looked it up on wikipedia. The entire article was metaphors and other symbolism <lfam>I still don't know what a data lake is <ng0>civodul: i think ars technica might be open to outside writers, so a journalist with some publications or affiliations might be the only thing to search for <civodul>anyway, i think we should encrypt our stuff at the artifact and secret level, or we're doomed <ng0>civodul: we had a short discussion.. the goal at the end of guix' roadmap is easy to reach, so I'll make things to work towards gnunet integration a priority .. but it might be in perl the first time, depending on what me and the other person agree upon.. i hope i can make it guile. <ng0>that would be one level of encryption etc <civodul>ng0: wait, the sentence above was a joke :-) <ng0>i did not follow the discussion <ng0>but it wasn't a direct reply either <ng0>just a "i think this is doable before 1.0" <ng0>but my understanding of guile needs to and will improve in the process. <optikalmouse>civodul: I've always thought free software needed some more marketing because apparently it does pay off even your product is garbage <civodul>yes, but at the same time, we're reaching unprecedented levels of bullshit these days :-) <civodul>that said, it would be awesome if someone would invest a bit more in promotion, i agree <civodul>ooooh, a patch from Dec. 2015 just pushed, thanks Steap! :-)