***pksadiq_ is now known as pksadiq
<brendyn>Now my android phone is displaying in nautilus 20 or so times <m-o>just saw your email, thanks a lot :) <brendyn>I didn't think we could make those yet <efraim>civodul: when its time ping me and I'll make sure my aarch64 box is ready and available for a binary install tarball <efraim>I don't know if something changed, but I built the latest guix snapshot on aarch64 in ~80 minutes <civodul>well tomorrow if everything goes well <civodul>can you already try to build the tarball just to see if everything's alright? <efraim>looks like its 'make guix-binary.aarch64-linux.tar.xz' <civodul>rekado: i haven't updated NEWS yet, but apart from that it seems that the lights are green <efraim>oops, forgot to prefix with 'guix environment guix' <efraim>'time' is also a bash built-in, right? <civodul>there's both a Bash built-in and external command, which behaves differently <efraim>`guix environment guix -- time echo hi' gave me this error: guix environment: error: execlp: No such file or directory <efraim>i don't have time in my profile, using bash's time <civodul>you'd need to so "guix environment guix -- sh -c 'time ...'" <pksadiq_>So, a new release is imminent? is mozjs, gjs, gnome-shell, and webkit upto date? I wish to have a try again, iff without hassles. :-) ***pksadiq_ is now known as pksadiq
<efraim>guix-binary.aarch64-linux.tar.xz: XZ compressed data <jonsger>civodul: the cert of guix-hpc.bordeaux.inria.fr expired yesterday :P <efraim>probably should've run make-clean first <civodul>the cert was up to date but nginx had not been restarted... <civodul>efraim: "make clean" doesn't make any difference here <efraim>all of 3.5 minutes, i already had all the pieces needed on the firefly <rekado>civodul: I’m working on berlin.guixsd.org again <rekado>I cannot guarantee that it will be ready in time <jonsger>pksadiq: you can just search for them here... <rekado>last time I ran out of space on berlin and guix would not time out waiting for berlin to respond. <civodul>rekado: it might be enough to know that it'll be ready "sometime soon" though, regarding the question of whether to enable berlin. by default in new installations <rekado>I’d like to be able to put berlin.guixsd.org under maintenance without stalling guix clients across the globe ***pksadiq_ is now known as pksadiq
<rekado>we can add the key, but I’m not sure if it should be contacted by default. The storage may have to be reconfigured at some point. <g_bor>It seems that we are having another issue in glibc on core updates. <g_bor>Upstream fixed that in commit 6913ad65e00bb32417ad39c41d292b976171e27e. <str1ngs>how do I list the contents of a package? <str1ngs>like apt-file list <pkg> or dnf repoquery -l <pkg> <civodul>g_bor: you should check with mb[m]1 our local glibc expert :-) <roptat>str1ngs: find $(guix build <pkg>)? <civodul>ACTION is being told that he just received donated aarch64 boxes at home :-) <civodul>efraim: i might be able to build the tarball locally, after all <rekado>civodul: nice! Are these the overdrive systems? <g_bor>I'm right now building with the newly pushed patch on core-updates, as I want to make sure that the current version does not adress the issue. <g_bor>If it's not, the I will file a bug. <str1ngs>(cd $(guix build <pkg>); find) is sorta what I was looking for I guess. thanks <str1ngs>I guess that breaks though if package is not installed and or built <brendyn>na it works fine because all the other output goes to the other ports <brendyn>so all the output from the build doesn't go to ls <efraim>I can send over the binary tarball I made earlier if you want to help speed up the setup :) <str1ngs>just if I try to list the files of a package I think is installed and it is not. it will try to build it. which could be expensive <brendyn>Yeah. But that's the only way to find out what files are in the package <str1ngs>roptat: I think I understand why it's like this. this helps either way <roptat>if substitutes were available for the package, we could implement something to ask for a file list, but I don't think there's much gain <roptat>and if there's no substitute, you have to build it to know what it installs anyway <str1ngs>another thing, my notebooks is taking a beating from guix. I have tried to offload building an publishing on my powerfull workstation. sometimes package -i seems to do the right thing. other times it wants to randomly build things. it's kinda frustration <efraim>i limit my laptop to 1 core while building <roptat>str1ngs: I know, I'd love to have a --only-substitutes option <str1ngs>it's not the building that bother's me. its randomness of what gets built and when. even after I have pre built on my workstation <str1ngs>granted this is a fresh install and I had to guix pull. but building glibc randomly on my notebook unexpectedly kinda throws me off <roptat>your workstation and notebook should use the same guix commit, otherwise they won't have the exact same packages and your notebook will rebuild what differs and anything that depend onit <str1ngs>roptat: that's a good idea. I'll make sure my guix hashes match at all times <roptat>if it rebuilds the exact same package when a substitute is available, that's a bug <str1ngs>keep in mind I'm still groking some guix concepts. so could be my fault <g_bor>ok, it seems that the same bug triggered the glibc update that later broke core-updates <g_bor>mb[m]1 just pushed a fix for that. <g_bor>I'm building right now to check the fix, then we can go on to change the default icedtea. <civodul>did you experience the same issue on your boxes? <efraim>I don't actually have guix running on any armhf boxes <efraim>I have one in a drawer that needs work and an RPi 1 <civodul>would be nice to investigate this test failure <civodul>i thought disabling parallel tests fixed it, but the arm failure suggests that it didn't <efraim>2.15.0 didn't give me any problems with parallel tests <civodul>it's a bad sign when our own bug report comes first in a search <civodul>i'm trying a patch to disable 3 of these git-svn tests that show up in build failures <civodul>it may that test parallelism was not to blame after all <str1ngs>I have a personal project using autotools. its still in development. its uses pkg-config to set CFLAGS. gdk pulls in wayland-protocols.pc but wayland-protocols.pc is found in PROFILE/share/pkgconfig and not in PKG_CONFIG_PATH. seems kinda wrong to me ***pksadiq_ is now known as pksadiq
<civodul>rekado: i was thinking that we could mention berlin.guixsd.org under "Substitutes" so that people can try <civodul>do you think that'd be OK or should we wait? <rekado>the big storage couldn’t be fixed today, but I’m currently trying to get the new server read with local disks. <civodul>let me know if anything important is missing! <m-o>civodul: maybe mention progress bar on guix system init, its a nice improvment :) <ng0>I'm trying to get used to it <ng0>for more than just getting used to it I'm using spectrwm/scrotwm and sometimes Mate <str1ngs>I use i3 before that dwm. there pretty much the same though <str1ngs>my requirements are minimal. thought I'd checkout guile-wm when I have more time. <ng0>be sure to check out issue #2 on the bugtracker and apply the solution to the default config <g_bor>Yesterday, after a reboot I found this in my shepherd log, and ssh did not start: 2017-12-03 22:47:39 Service ssh-daemon could not be started. <g_bor>How can I find out what happened there? <baconicsynergy>I'm going to attempt to convert the qcow2 vm image to vmdk for esxi... wish me luck <ng0>I think guile-wm has issues with some part.. somewhere.. I'm not in the mood for debugging, but after a certain amount of keystrokes (or a random amount)it crashes. <ng0>my favorite bug is when the master key combination no longer reacts :D <ng0>first time using it, so I hope when I read the source and a bit more of the Handbook I discover that I can set a key combination to restart it in place like spectrwm <str1ngs>ng0: I'm defiantly going to check it out. once I get guix working properly on my notebook. <ng0>baconicsynergy: there's even a couple of them already written in Rust, software among other Rust software I'm waiting to properly package. <ng0>or define it in the global list of packages for GuixSD <str1ngs>does guix only take stable packages? <lfam>str1ngs: What do you mean by "stable"? <str1ngs>I have a very alpha project, that I was thinking of creating a package.I'm the author of the project <lfam>Guix makes it pretty easy to package things "out of tree". In general, we prefer to only include upstream releases that are marked "final", "done", or whatever other term the upstream uses to distinguish from "beta", "alpha", "release candidate", etc <str1ngs>out of tree is not a big deal. it's just that it's guile project. and guix is the closest thing to guile package management <lfam>But in practice we have to evaluate it on a case-by-case basis <str1ngs>the project is C and guile. it's a web browser <lfam>Well, there's no harm in sending a patch :) <str1ngs>it won't be for awhile till it reaches alpha atleast. <ng0>in practice we also have my Fish guix completions and they require a last manual step to make them work in the end ;) <str1ngs>thanks for the info. though gives me at target. <lfam>Software is never really "done", so it's more about whether a particular release is "done". <lfam>If you issue a release and say it's a stable release, and it builds, that's probably enough to get started :) <lfam>Then, we forward the bug reports to you :) <ng0>guile-wm is nice and everything, but I guess I need to debbug it to make use of it without interruptions <str1ngs>that's one thing with guile, you need to handle exceptions <ng0>then you run su - deity rebuild world <vagrantc>ACTION notes that deity was one of the early frontends to dpkg <ng0>oof. why are we building guile-wm from an archive.org saved url instead of from github= <ng0>I can try and work on updated package definitions <myglc2>What's the easiest way to build the dev version of a guix package from its git repo? <bavier>myglc2: have you tried using --with-source ? <myglc2>Don't think that supports building from git checkout <ng0>myglc2: either inherit the package definition in a new definition in your GUIX_PACKAGE_PATH or a file you can point it to, or by including a file in the root of the git checkout <ng0>yeah I'll definitely package guile-xcb and guile-wm from a newer git checkout and test them <ng0>there are guile 2.2 compability commits in the recent commits for both of them <bavier>myglc2: afaik you can give --with-source a directory name <myglc2>bavier: oops, I miss-read. I see git clone example right there. Thanks. <myglc2>bavier: OK, that doesn't work because to build from repo takes more steps. <bavier>myglc2: oh, then you'll probably need to do like ng0 said, create a derivative package in GUIX_PACKAGE_PATH <myglc2>ng0: Thanks. Why do you say "file in the root of the git checkout" rather than in (gnu packages foo)? <ng0>because that's not what I meant <ng0>literally what I wrote. like I do this: I create a package definition in the source code tree somewhere. preferably in the root of it, but sometimes contrib or anything similar. then I use this file with guix package -f or guix build.. etc <ng0>see GNUnet, gnURL, python-pycanberra and so on <ofosos>ng0: I've picked up your krita patch from earlier this year, and am trying to build it now, had to overcome some problems :) <ng0>even a simple scripts collections is build like this for me <ng0>I've had a krita patch? cool <ng0>oh it was just identifying dependencies, right <ng0>nice that you made progress, however small or big my patch was :) <daviid>trying to compile gnutls, on debian buster, configure does not report any error, but make fails: verify.c:40:10: fatal error: supported_exts.h: No such file or directory ... anyone knows what package holds supported_exts.h on debian ? <ofosos>The only problem is, I had to throw out OpenEXR support, I think there's something fishy happening with ilmbase and openexr conflicting, they're both part of the same upstream and apparently everybody (besides guix) builds them as one package <myglc2>ng0: OK, I see I took your comment too literally. <ng0>checkout neomutt.git/contrib/ (if I ever commited it) and gnunet.git/contrib/packages/guix/ for more :) <efraim>daviid: apt-file search supported_exts.h came up blank for me <daviid>efraim: ah! just asked on debian-next, let's see... tx! <daviid>it surprises me that configure pass and make fails with such an error (that should be detected at configure precisely) <daviid>duckduck does not find any occurrence of this file either <daviid>voilà, there is no such file on debian <ofosos>huh? I thought running `./pre-inst-env guix build foobar` would recompile my local changes, but apparently it creates no .go files :( Did I forget something? <daviid>debian folks confirm there is no such file in debian <daviid>anyone has manually compild gutls on debian (to get guile-gnutls...) could give e a hint? <myglc2>ng0: If I go with local-file like neomutt with git repo source does that mean I another complete copy of the repo into the store for each build from a different commit? <ng0>yes, but they will get garbage collected <str1ngs>daviid: I have manually compiled gnutls with guile support. on fedora though <daviid>str1ngs: did it report the error above? from what branch did you compile? I tried master <str1ngs>what I did was. build guile 2.2 in /usr/local then gnutls in /usr/local. and remove all instance of guile 2.2 from system packages <str1ngs>you would have to install all depends for guile and gnutls including -dev packages though <str1ngs>daviid: can you repost error I missed it due to znc buffer playback <daviid>str1ngs: I have all dpes fine, it complains at make with an error nobody undertands <daviid>verify.c:40:10: fatal error: supported_exts.h: No such file or directory <daviid>that file should be part of gnutls <daviid>str1ngs: you installed from a tarball or from the source <daviid>I tried from a tarball (a while ago), it reported this same error <str1ngs>well gcc versions stuff like that can be a factor <str1ngs>I'm checking what that include is from. I don't think is from gnutls <str1ngs>gcc (GCC) 7.2.1 20170915 (Red Hat 7.2.1-2) <str1ngs>daviid: you were mentioning the other day, you thing the bindings should be seperate? <str1ngs>at the very least there should be a make install target <str1ngs>you can cd into guile and do make install though <str1ngs>but you'd have to be on point with system gnutls version <daviid>str1ngs: let's not have that discussion, it is useless <str1ngs>what code name of debian are you using? I can spin up a docker image <daviid>gpg --keyserver keys.gnupg.net --recv-keys A812CBFDFCDC4D0BE7A093129D5EAAF69013B842 <daviid>gpg: keyserver receive failed: Not enabled <daviid>i can't verify the tarball now :( <str1ngs>hmm gnutls is special, it might not be in the gnu keychain ***MightyJoe is now known as cyraxjoe
<str1ngs>I suspect you are using an older version or something? <daviid>str1ngs: i'm trying to compilefrom the tarball , lett's see <ofosos>rekado, thanks, that was what i was missing :) <str1ngs>daviid: maybe you are using git head? <str1ngs>also I found it easier to build guile into /usr/local due to load-paths <daviid>str1ngs: i was trying to build from the source, now from this latest stable (the last attempt using 3.3.8 failed, it's been 2y i try to install guile-gnutls ... :):) <str1ngs>but that might mess up things if you have a system installed guile 2.2 <str1ngs>how many people actually build guix from source? <daviid>when i work on somethig, i build from the source, always <str1ngs>normally though I don't /usr/local . just for system daemon it works better <str1ngs>daviid: also if you are using the guix-daemon.service you'll have to hack the binary path <rekado>in my opinion there is little benefit in building Guix from source. When you use Guix you will use a lot of packages from Guix anyway. <rekado>the binary installation is little more than a pre-populated /gnu/store <daviid>rekado: really/ but it seems so 'late' compared to guix 'the latest' <bavier>I build guix from source. I have it installed on a few systems where I don't have root, and on one system where "binary installs" are frowned upon. <str1ngs>guix should and must build from source. it hypocrisy <daviid>rekado: I actually need an empty guix (in terms of packages), but the one it needs to let me work on and build others, such as the packages i work on ... <ofosos>now, when building I get: ERROR: gzip: unbound variable <str1ngs>anyways this less an issue with guix and more an issue with distro support for gnutls guile <rekado>civodul: guile-git seems to have been made private <rekado>I can no longer build it from source on berlin, because the URL redirects to a sign-up page. <ofosos>When I try to compile guix/scripts/pack.scm I get `gzip: unbound variable`. Any ideas? <rekado>str1ngs: hypocrisy is a big word. Of course guix builds from source. <civodul>ofosos: somebody reported it before but i can't reproduce it <civodul>do you have more info? Guile version, Git version, build method, etc. <civodul>rekado: oh so that one ends up returning 200 because of the sign-in page, right? <rekado>I can’t build guile-git with 0.13.0 when doing “guix pull”. <rekado>I guess I need to import it from somewhere else <ofosos>I'm running `guix environment guix`, will lookup the individual versions <civodul>rekado: yes, like (guix download-nar) does <rekado>ACTION is installing 6 more servers for berlin.guixsd.org <str1ngs>rekado: the issue is not specifically with guix. but gnutls anyways <ofosos>guile: 2.2.2, git: just checked out, method: ./configure && make <civodul>ofosos: do you have stale .go files? <civodul>ofosos: what if you do: touch guix/scripts/pack.scm && make ? <ofosos>actually I did a make clean, before I did the ./configure, I'm doing it again to be sure <ofosos>after another make clean, same result, now trying your method <cbaines>evening all, I just sent a message to the list about this, but I've got stuck trying out the ISO image installer <cbaines>for some reason, when I run guix system init, it builds everything from source <ofosos>civodul, I did a fresh checkout and am now compiling that one <ofosos>same issue on the fresh checkout <rekado>bleh, and git fails to build from source (broken tests) <str1ngs>I though I saw something related to arm and git test earlier in the day. <str1ngs>rekado: git pull with 0.13.0 should install guile-git. you'll have to add it to GUILE_LOAD_PATH but it will tell you to do that. <rekado>str1ngs: it doesn’t because I’m not using substitutes and the source has moved. I’m building it myself now. <str1ngs>hmm without substitutes I'm not sure then <civodul>hey cbaines, i'll check your message <civodul>ofosos: can you paste the full output? <civodul>ofosos: can you show the full output starting from the prompt? i'd like to see whether (gnu packages compression) was loaded earlier or not <ofosos>starting from the beginning of the scheme stuff <rekado>oof, and libgit2 fails to build from source because the generated github tarball changed. <rekado>all of these are known issues and the new release will fix them. <rekado>I downloaded the sources and am now building libgit2 using “--with-source” <civodul>we must really use content-addressed storage before upstream <ofosos>Do you have any idea, how I could get to a point were I can locally test changes to guix? <civodul>you could always remove guix/scripts/pack.scm from Makefile.am if you're in a hurry <ofosos>civodul, that gives me an error about gnu-make in guix/scripts/refresh.scm :( <civodul>i have to sleep but perhaps you can email bug-guix with as much detail as possible? <ofosos>I did a change to gnu/packages/graphics.scm, adding a dependency, i rolled the dependency back and am recompiling <civodul>make sure to test on pristine master without any changes <ng0>I have 5 changes in guile-wm I'll be sending in tomorrow morning or evening <vagrantc>hrm... so experimenting with setting up a local caching proxy for berlin.guixsd.org and mirrors.hydra.gnu.org ... and now guix pull seems to be redownloading all the bootstrap binaries, even though guix is still building the exact same git commit ... how's that work? <vagrantc>hrm... and on a second run of the same command, it didn't do much <str1ngs>vagrantc: I've been seeing that as well