IRC channel logs


back to list of logs

<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>I noticed the typelib file in the directory listing of the Arch package:
<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
<civodul>Hello Guix!
<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.
<civodul>lfam: perfect :-)
<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>I'm running into this error when configuring Guix (to build from source): "socket file name would exceed the maxium allowed length", cfr.
<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>hello boegel!
<civodul>boegel: there's a relatively small limit of the length of socket file names in the kernel and libc
<boegel>hiya civodul
<civodul>AF_UNIX sockets
<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>hmm ok, that's unfortunate
<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>)
<civodul>off by one!
<boegel>urgh, just my luck :P
<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>hmm, is PRoot an option to alleviate the need to run the Guix daemon as root? cfr.
<civodul>good question, not sure
<civodul>maybe roelj knows? ↑
<boegel>I'm very interested in a setup where I don't need root
<civodul>yeah, that'd be great
<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
<boegel>civodul: why is it disabled?
<civodul>might be yes
<civodul>because of security concerns
<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
<davexunit>civodul: guile-json is pure scheme, fwiw.
<civodul>oh? oh!
<civodul>but still, it's outside of Guix, so you'd rather not just #:imported-modules '((json))
<jlicht>what would you rather do then?
<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
<jlicht>That'll do
<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?
<civodul>using multiple checkouts
<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?
<jlicht>or what rekado_ said ^
<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: blocks tor users, so I can't access it
<mark_weaver> is one possibility
<thomasd> : uncommenting the (patches ...) line break 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?
<jlicht>nope: unclutter also uses it
<jlicht>in gnu packages xdisorg
<mark_weaver>civodul: gunzip should work
<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>oh, ok
<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>alternately, this patch should fix the problem:
<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>ooh, nix-daemon uses user namespaces:
<civodul>roelj, davexunit: ↑
<davexunit>civodul: nice!
<davexunit>that's what I'm talkin' about!
<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)?
<davexunit>yeah it's a good amount of work
<civodul>jlicht: it's superseded by gexp->derivation
<civodul>see "Derivations" in the manual
<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
<civodul>be brave, lfam
<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>504 gateway timeout
<civodul>davexunit: use the mirror
<davexunit>civodul: I thought I was using the mirror so I was surprised to see a URL
<davexunit>I'll have to check my daemon settings
<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>apparently the people at Chef have created habitat:
<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 instead of the mirror. Not sure why.
<lfam>rekado_: Maybe a spam filter found this string suspicious "r-bsgenome-mmusculus-ucsc-mm10" ;)
<davexunit>optikalmouse: awful!
<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
<davexunit>er, services*
<rekado_>I would like to have more of GuixSD on foreign distros.
<rekado_>shepherd doesn't need to run as PID 1, after all.
<davexunit>yeah, that would be neat
<optikalmouse>davexunit: how does that work, is there an example you can point to?
<davexunit>optikalmouse: see any module in (gnu services ...)
<optikalmouse>k cool thx :D
<davexunit>it's just a matter of writing the services
<davexunit>this Habitat thing is still most a stone-age packaging system.
<davexunit>that is: imperative
<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's basically Docker
<davexunit>it conflates building the software with configuring and running it
<civodul>woow, the level of marketing is so high on that it's hard to follow
<lfam>You can run both greenfield *and* legacy applications!
<civodul>greenfield, can you imagine!
<lfam>The problem for my use case is that blue is my favorite color
<civodul>too bad for you
<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
<davexunit>lfam: omg
<davexunit>buzzword salad
<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
<rekado_>yes yes
<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'
<davexunit>only '#!/usr/bin/env guix'
<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
<davexunit>'make install' being the most common thing
<civodul>davexunit: ok, i see
<rekado_>optikalmouse: this is abstracted away in build systems, but it is possible to add arbitrary build phases.
<rekado_>(or to remove them)
<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.
<davexunit>civodul: hmmmmmm
<davexunit>that's an interesting idea
<davexunit>I do similar things
<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
<rekado_>why in package properties, though?
<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?
<davexunit>I could see that being useful.
<ng0>ah, logical. thanks:)
<civodul>davexunit: right
<rekado_>ah, that makes sense.
<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
<davexunit>civodul: it's a promising idea.
<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
<optikalmouse>ok awesome
<optikalmouse>would be nice if the manual included a link to it in this section:
<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
<davexunit>talk about cursing upstream...
<lfam>Sounds like Kodi... another monster
<davexunit>yeah Kodi took a lot of effort to package
<lfam>I was really amazed by that. I should see if I can understand the package definition now
<davexunit>it's a doozy ;)
<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
<davexunit>unless you're just after a quick hack
<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
<lfam>Should I try -rpath?
<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 '' 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.
<lfam>Does it reach GRUB?
<lfam>This is with Libreboot?
<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>lfam: too bad
<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>bavier: no
<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
<kete>not stable
<davexunit>HN discussion of Habitat
<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
<bavier>oh, I see
<ng0>it also did not put ncurses in there, but i did that because it requires it.
<bavier>ng0: dynaloader is there
<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 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>lfam: yeah, saw 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>there it is.
<ng0>that's much output.
<ng0>i never used readelf, how can i just get what i need?
<bavier>ng0: 'readelf -d' would be better
<ng0>*never used it much
<lfam>Okay, I checked the built output of gnome-maps. Nowhere in the binaries does the string 'goa' exist. Not even under /usr.
<lfam>A /usr path, that is
<lfam>Does this indicate that it lacks the ability to embed the path to the library?
<bavier>lfam: nothing in the libs either?
<ng0> i think i need to put ncurses in more than just inputs.
<bavier>ng0: According to did you set CURSES_LDFLAGS?
<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>My mistake
<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
<bavier>they seem to work fine
<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
<lfam>Oh, good!
<bavier>I've been slow to push things lately
<lfam>Maybe you should send it to guix-devel while it's on your mind :)
<lfam>Or push it to Savannah
<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
<ng0>*set a path
<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>is it just me or do instructions regarding checksums seem fishy here?
<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>how does the accomplish anything?
<davexunit>I guess it does it correctly.
<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
<davexunit>do you mean GUILE_LOAD_PATH?
<kristofer>me either, it's the command line variable passed to cmake to build opencog
<davexunit>oh maybe it does something weird
<davexunit>well try using (getenv "GUILE_LOAD_PATH")
<davexunit>(string-append "-DGUILE_INCLUDE_DIR=" (getenv "GUILE_LOAD_PATH")) or whatever
<kristofer>I need the path to include/guile/2.0/
<kristofer>I'll try it
<davexunit>I'm very confused
<davexunit>what's a shared library doing in /include ?
<davexunit>GUILE_LOAD_PATH must not be what you're looking for
<kristofer>libguile.h I mean
<davexunit>okay, so assuming guile is an input to this recipe
<kristofer>lemme share
<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>use the #:configure-flags argument
<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
<kristofer>nevermind, got it :)
<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>I think this is why habitat will be popular:
<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
<ozzloy>i did guix build skribilo
<ozzloy>and guix build guile
<lfam>ozzloy: You will probably want to install them for your user with `guix package --install guile skribilo`
<ozzloy>lfam, cool
<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 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?
<davexunit>no way.
<davexunit>we break the FHS on purpose.
<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
<davexunit>when using --container, of course.
<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
<bavier>ozzloy: heh :)
<ozzloy>no biggie. i figured it out. it was funny
<lfam>Man, I wish my high school had had that. Sounds really fun
<ozzloy>i keep getting "warning: failed to install locale: Invalid argument" even though i've followed the steps here
<lfam>ozzloy: Are your Guix-installed applications working with UTF-8 correctly?
<lfam>Is it just Guix itself that gives the warning?
<ozzloy>i don't know how to check that
<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?
<ozzloy>i do not source that
<ozzloy>so .bashrc?
<lfam>No :)
<bavier>ozzloy: did you read
<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 :)
<ozzloy>what's a good program to test non-ascii with? i found this list but it's not sorted and i didn't see an obvious choice after scrolling for a bit
<lfam>ozzloy: A text editor should work. Find some non-ASCII text and try to view it in the editor
<ozzloy>emacs worked
<ozzloy>so yeah, just guix itself
<lfam>I like this one:
<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>thanks for the help
<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> is full of fail in links
<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?
<efraim>don't think so
<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
<efraim>do you know if RTL fonts work?
<paroneayea>hello, *
<paroneayea>who's running cups? :)
<paroneayea>ACTION notices it mentioned not too far ago
<lfam>efraim: I don't know
<optikalmouse>davexunit: I think guix and guixSD just needs some web 3.0 design love and no doubt the smart devops people will use it:
<optikalmouse>ugh I'm just disappointed that coworkers are excited about it and I can't convince them that guix is neater
<davexunit>optikalmouse: yeah, need more marketing
<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>I use it there
<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>and I just noticed this:
<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
<ng0>just gueesing.
<civodul>anyway, i think we should encrypt our stuff at the artifact and secret level, or we're doomed
<bavier>bug reports sometimes pay off:
<civodul>excellent, thanks bavier!
<civodul>it's pleasant
<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>sorry :D
<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: emailing the journalist directly may work?
<optikalmouse>or twittering.
<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! :-)