<uniq10>Hi reepca. I was actually about to go sleep. But since you are up I have a few questions if you don't mind. <reepca>also, it seems that magit is expecting openssh to have an askpass program that it doesn't have... <uniq10>Well first off I didn't get your message about MS_PRIVATE. I would like to hear about that. And secondly were you trying to replicate what the c++ code did exactly or just the overall idea? <uniq10>Thank you so much for helping me out. <vagrantc>guix pull is requiring upwards of 3GB of ram+swap on aarch64... <uniq10>Got it reepca. Thanks. Yeah I came across the MS_SHARED issue too. <reepca>I think I was mostly trying to replicate the behavior exactly as far as it was visible to clients. It's a bit difficult to know exactly what that is, though - there isn't some nice specification that mentions "and all files in directory X other than Y and Z are implementation-defined". I'd say ask on a case-by-case basis. <uniq10>reepca: I was first going for a direct replication of c++ code. Your approach seems more reasonable. I think I will do that. <uniq10>reepca: When would you generally be active on the channel? <reepca>uniq10: hard to say. My family's situation is /really/ hectic right now. I would guess maybe on evenings in Nebraska time (so maybe 2400-0600 UTC?). <vagrantc>so, realistically ... running guix pull on anything less than 4GB of ram seems very ugly. <uniq10>reepca: Do you happen to know about this "rekado: I understood the difference between referrers and references. My question was regarding the effect of `includeDerivers` when the direction was flipped. When the direction is flipped `includeDerivers` seems to be adding derivation outputs. Thanks :-)" <reepca>well, it seems that flipDirection's objective is to basically reverse the direction of the edges (so still a directed graph, but a backwards directed graph). By default the direction is "from referencer to referencee", so the closure becomes "everything this references, and everything that everything this references references, and so on". When the direction is reversed, the closure becomes "everything that references this, and <reepca>everything that references everything that references this, and so on". It seems that the intent behind includeOutputs is to make it so that whenever there is a derivation in the closure, its outputs are in the closure as well. The intent behind includeDerivers is the opposite: whenever there is an output file in the closure, its deriver is in the closure as well. Flipping the direction flips the semantics. <reepca>If that sounds horribly complex, the good news is that nowhere in the C++ source that we have is it ever called with more than 3 arguments. So all 3 of the flags are always false (I assume that's the default...). <reepca>it's a weird way of naming things (just because the direction of traversal is flipped doesn't mean derivers are now outputs and outputs are now derivers), and in my opinion an overly-general procedure (as evidenced by the fact that 90% of it literally never gets used) <reepca-laptop>Anyway, so when I try adding a git remote with magit I get this: ssh_askpass: exec(/gnu/store/ygxgv74w6p13rk1gf1cnzfzfj7n9v01h-openssh-7.7p1/libexec/ssh-askpass): No such file or directory <reepca-laptop>huh, apparently I just needed to try again after the first command failed. <reepca-laptop>also, is anyone else's top sometimes saying that 229 trillion % memory is in use? <Guest64851>So I've been running GuixSD for quite a while now, but I've just realised I don't have any swap set up. Weirdly though, I've never had an out-of-memory error, and I'd swear I've seen the system behaving like it was swapping - disk light on solidly, slow performance etc. Is there something else going on here? <snape>Guest64851: swap might not be necessary if you have enough RAM <snape>I personnally never use swap <rekado_>poor responsiveness and lit disk light does seem to indicate swapping is happening. <snape>rekado_: .xsession should still work with EXWM <snape>also, I shamelessly click on the line/char button, but I yeah maybe it's time to learn about the shortcut <janneke>rekado_: i'm using the exwm-x default of C-t C-t, which means i lost transpose-chars <janneke>C-t seems to be a pretty universal WP prefix... <rekado_>I have mapped C-t to C-x in some cases (because I use Dvorak and “t” is right under my right middle finger whereas “x” can only be reached with some effort). <rekado_>For this reason I need to have EXWM capture C-t, which is unfortunate when using Epiphany (which uses C-t for opening a new tab). <rekado_>snape: when I only have .xsession and have it end on “exec exwm” I cannot get past the Slim login. <snape>rekado_: well, you should be able to get past it... does it work with another WM? If it does, maybe exwm isn't in your PATH? Did you try with 'exec /full/path/to/exwm'? <rekado_>snape: it did work with stumpwm. I’ll try with the full path to exwm next. ***Guest64851 is now known as sturm
<efraim>rekado_: if you want you can also add a default config to the gnome- and mate-desktop-service-types, and take a look at 'git-file-name' for future use :) <rekado_>efraim: ah, yes, I keep forgetting about the existence of “git-file-name”! <rekado_>I leave the default config for {gnome,mate}-destkop-service-types to someone else ;) <efraim>that's not actually a hard one, the services already have default values so its something like my comman one <rekado_>efraim: should we remove things like “mate-desktop-service” then? <rekado_>I believe these simple services predate the use of default configs. <efraim>We should remove them eventually but it'll break people's configs so it's waiting for a while <rekado_>yeah, first step is to provide the new alternatives for all services anyway. <efraim>i'm testing building the new qt 5.11.0 modules, this should take a while <efraim>qtbase 5.11.0 doesn't build with system sqlite, like 5.10 didn't <efraim>I'm not seeing an update for qtwebkit <mbakke>efraim: Wasn't "qtwebkit" a community project, and the "official" implementation called "qtwebengine"? <efraim>Qtwebengine uses chromium instead of webkit for rendering <twilk>I'm trying to set up build offloading. I have a laptop running Arch Linux with Guix 0.14.0, and a server running Debian stable with Guix 0.12.0. I followed the manual; the server can build packages, the machines are authorized with each other, etc. When I run guix offload test, sending a test store item works (and it shows up in /gnu/store on the server), but retrieving one fails with "build failed: bad archive: input doesn't look like <pkill9_>what could be the cause of this error during comilation: <pkill9_>the configure phase goes through without any issues <roptat>twilk: you're using an older version of guix, so there may be a conflict in the file format <roptat>twilk: you can try running "guix pull" on your server and restart the daemon <pkill9_>rekado_: yeah it is, both the 'bin' output and the default output <rekado_>oh, I don’t know what this “-lm” thing is. Maybe that library isn’t part of a default glib build. <pkill9_>i searched for it but nothing came up about what it is <roptat>-lm is libmath, it should be part of glibc <roptat>I remember haiku was fighting packages who used it without checking for it because it's bundled with their standard library (so removing -lm allowed the package to build) <rekado_>roptat: do you mean that “-lglib-2.0-lm” should actually be “-lglib-2.0 -lm”? <roptat>rekado_: oh I just saw "-lm" alone, so I think it was it, but nevermind that <pkill9_>in configure there's a 'LIBS="-lm $LIBS"' line <pkill9_>actually i think LIBM is a configure flag <pkill9_>you can run it with `guix build -f` if you're curious <pkill9_>hmm there's an 'openlibm' package in the maths module, i'll try adding that as an input <pkill9_>lol, i think i know what's happening: <pkill9_>configure:LIBINDICATOR_LIBS+="$LIBM" <pkill9_>so it's appending "-lm" to the LIBINDICATOR_LIBS without a space <roptat>twilk: so this is the output of "guix pull", right? <roptat>that may be because your guix is already so old. it might be easier to make smaller jumps <roptat>or reinstall completely a newer version <roptat>twilk: what does "guix --version" say? <twilk>roptat: guix (GNU Guix) 0.12.0 [...] <roptat>ok, so if you can't reinstall guix completely, you can start with "guix pull --commit=fd3782d13b8f2e835e9867c7abd92786a93e8ad6" which will update first to 0.13.0 <roptat>twilk: then you'll do the same to update to commit 5a2f019c7d35d539036825a7d0cc184f0c7dc60a (0.14.0) <twilk>roptat: that didn't work, guix says "unrecognized option". I'm now trying to install guix 0.14.0 using guix 0.12.0 <twilk>roptat: I might be very confused, but I ran sudo guix package -i guix. That should install the newest guix, so then I can hopefully use that instead of the Debian-packaged one <rekado_>guix 0.12.0 didn’t support “--commit” <pkill9_>hmm, I'm getting a compilation error saying bash can't find '--template', I had this same error before but I completely forgotten how i fixed it <pkill9_>ah fixed it, need to add glib:bin as an input <pkill9_>makefile tries to run `$(GLIB_MKENUM) --template blah blah` <roptat>twilk: actually that install the newest guix package your current guix knows of, which is 0.12.0 <pkill9_>is this a bug: this command spits out a directory which doesn't exist: <pkill9_>guix environment --ad-hoc pkg-config python2-pygtk -- pkg-config --variable=codegendir pygtk-2.0 <roptat>pkill9_: what is codegendir supposed to be? <roptat>if it's a directory where different packages put some code, that's not a bug, but will cause troubles for sure <pkill9_>it probably isn't a bug then, basically it's for this line: <pkill9_>PYGTK_CODEGEN="$PYTHON `$PKG_CONFIG --variable=codegendir pygtk-2.0`/codegen.py" <pkill9_>codegen.py is actually at $(guix build python2-pygtk)/bin/pygtk-codegen-2.0 i think <pkill9_>that line is in the configure file for libappindicator <roptat>what if you pass PYGTK_CODEGEN=pygtk-codegen-2.0 to configure? <pkill9_>it still fails, because they're silly and don't actually check if that path exists, so configure phase still passes but when it tries to use it in the build phase it fails <pkill9_>i'll just patch the configure file to replace it with the line you suggested <pkill9_>guix package definitions are like slackbuilds X 1000 <rekado_>ACTION does not know if this is a good thing or a bad thing <lfam>I'm reading through the resolution of the bug about the vm-image builder hanging, but I think it's resolved satisfactorily. <lfam>But AFAICT, the Linux people fixed their code rather than changing their advice, so we should be "good" <efraim>RNG stuff is definately something I don't understand much, but I'm glad (it seems) we're good <lfam>efraim: Turns out, nobody understands it very much... except for maybe Jann Horn <lfam>(Who found the linked bugs) <lfam>Okay, I have this lingering problem which is super annoying: <lfam>$ ./pre-inst-env guix system vm foo.scm <lfam>guix: system: command not found <lfam>It's just `guix system` that doesn't work on my Debian system anymore <lfam>Does it work for anyone else on a foreign distro? <lfam>For me, it doesn't work on either of my Debian systems, nor my NixOS system <lfam>It works outside of the 'pre-inst-env' <lfam>It fails when it can't find guile-json. It works after I install this package <lfam>PotentialUser-72: The package gcc-toolchain should make everything "just work" <lfam>PotentialUser-72: Can you give more details about what you tried and what goes wrong? The gcc-toolchain package is specifically intended to address your use case <PotentialUser-72>I'm trying to get opencl related stuffs working. The opencl source code is shipped as string and compiled at run time. So a correct ld at run time is needed. <lfam>Okay. And the ld you are trying to use, what provides it? <PotentialUser-72>I tried gcc-toolchain, bintuils, ld-wrapper, all of them results not finding "-lm" <efraim>qt modules updated locally to 5.11, now to break them all with enabling tests and such <lfam>PotentialUser-72: Okay, overall I recommend sticking with gcc-toolchain and ignoring those other packages. gcc-toolchain is *the* way to make it all work with Guix. <lfam>Second, I'm not sure where to go from here. It will help if you can share the code you are using, so others can try to reproduce the issue. Sending a message to <help-guix@gnu.org> will reach the broadest audience, including people who are not on IRC at this time <lfam>Cheers, let's work together to get OpenCL in Guix :) <vagrantcish>hrm. i'm not able to build linux-libre 4.16.11 natively on aarch64-linux, but cross-build on x86_64 works <lfam>vagrantcish: Does 4.16.10 still work on current Guix master branch? That is, is it a problem with 4.16.11 or with how we build it? <vagrantcish>lfam: i'm not sure ... it also seems like the few builds i've done don't fail in consistantly the same way... <vagrantcish>do failed builds keep log files? the logs scroll by so fast sometimes errors get lost in the buffer <vagrantcish>lfam: how would i test 4.16.10 ? fork gnu/packages/linux.scm and downgrade the version? <efraim>i normally revert the kernel upgrade when I don't feel like building it <vagrantcish>i've got two aarch64-linux guixsd machines now ... i'll try on the other one <efraim>looks like language switching doesn't work on enlightenment since we don't have scim packaged and we're not building efl with ibus <vagrantcish>ACTION was hoping to submit atf/u-boot patches for rk3399-puma-haikou too <efraim>guix size efl = 685, efl + ibus = 959 <efraim>looks like scim also uses gtk3 in its inputs ***ocharles is now known as Guest27988
***abbe is now known as Guest69495
***dellavg is now known as Guest74005
***piyo is now known as Guest31060
***benny is now known as Guest63762
***Guest69495 is now known as abbe
<ngz>Hello. I noticed Guix doesn't package ScummVM. Is this intentional, or the reason is just that no one bothered creating the package? I'm asking because I remember a rather heated discussion around MAME a couple of years ago. <areckx>so I instaled guix from the AUR and enabled the service, did the for i .. do.. etc, and packages are installed in /gnu/store but ~/.guix-profile is just empty <lfam>areckx: It will be created the first time you install a package <areckx>I did guix package -i glibc:debug <areckx>but I did that before I made a symbolic link so I'll try it again <areckx>if this fails I think I'm going to completely uninstall and remove all the files and start over without the AUR version and just follow the gnu info doc <civodul>ngz: what's MAME? was it the emulator thing? <ngz>It is packaged in, e.g., Debian stable main <civodul>ngz: so at first sight it's probably ok; what could be controversial is if it's only purpose is to play proprietary games, though one can always argue that it can be used for other purposes (hacking, etc.) <civodul>maybe double-check that old thread ;-) <lfam>I got the sense that whoever was interested in packaging MAME got scared off, regardless of the conclusion of the thread <ngz>civodul: It can run "freeware" games, not sure about free games <lfam>No, it was a very bad outcome IMO <ngz>Oh. There's a Public Domain game: Mystery House (Apple II) <ngz>I guess that counts as a free game :) <rekado>lfam: that discussion went off the rails and then died a very slow death :( <rekado>IIRC it even spread to other mailing lists <lfam>I'd argue it began off the rails <civodul>so anyway, i think it's OK per the FSDG, so we probably shouldn't be looking further than this <ngz>I'll add this to my TODO list. <rekado>in barely related news: I’ve got a Singularity package now. <civodul>(i need to check if i'm consistent is my old self, but hopefully i am :-)) <rekado>(it’s not an emulator, but people could use it to run proprietary software) <civodul>well, the same is true of ld-linux.so :-) <rekado>I was surprised to see that Singularity uses the GNU build system and has hardly any dependencies. <rekado>of course, the setuid stuff won’t work. <civodul>they have a funny convention: they use 0 as the true value for booleans <civodul>perhaps they're very much used to shell scripts <rekado>I also added a squashfs option for “guix pack”, but haven’t been able to use a squashfs pack with the new Singularity package. <rekado>once that works I’ll submit the work. <rekado>the squashfs bundle is slightly smaller than the tarball output. <rekado>I remember that squashfs was a recurring topic at the repro-builds summits. <civodul>there must be someone at Debian working on it <civodul>i gave a talk before roptat and colleagues today BTW, pretty interesting <civodul>well interesting questions/comments at least, though i hope the talk was interesting too ;-) <rekado>oh, yeah, I saw the announcement on that bird website. <civodul>someone used to CONDA was worried that we had a single version of packages <civodul>someone noted that when you do "guix pull --commit=someoldcommit", sure you get older packages, but you also get the old guix with old bugs potentially <civodul>which is true, but the alternative is decoupling things, which brings its own challenges <lfam>Hm... that's an interesting thing to point out <rekado>concerns like that are what made me suggest the “guix attic” project <rekado>at least for bioinfo that might make sense <rekado>I don’t see the need for old versions of libreoffice or icecat. <rekado>(for context: “guix attic” is just a name for an effort to revive older package variants and add them to a repository from which they could be built with the latest version of Guix) <civodul>i don't see the need in general TBH, though i can imagine that actual academic code could have such requirements <rekado>but in bioinfo people don’t take versioning seriously. <rekado>so a minor version bump could introduce a new file format, which causes other pipeline packages to break. <rekado>something like this happened to bedtools IIRC <areckx>should guix be owned by root or user? <areckx>it's supposed to exist entirely in userspace, right? but after install it's owned by root root <lfam>areckx: It allows unprivileged package management but the guix-daemon needs to have root privileges. It uses chroot to isolate the build environments and that requires root <areckx>right the daemon, I'm talking about the folder <lfam>Which folder, '/gnu/store'? <areckx>I am having issues because in my Makefile I put TARGET_LIB = $$GLIBC_DEBUG/libc*.so.debug and said file permission at make <areckx>where $$GLIBC_DEBUG is my export to the .guix-profile path <areckx>/usr/bin/ld: cannot open output file /home/areckx/.guix-profile/lib/debug/gnu/store/38kr8xi7nib8rx8xr4gi0w0d8knyca3k-glibc-2.25/lib/libc-2.25.so.debug: Permission denied <areckx>I am trying to get debug symbols into my test code so that valgrind can report back line numbers <areckx>right now it's just saying printf (in /usr/lib/libc-2.27.so) <areckx>but it's supposed to says printf.c:<line#> right? <areckx>ahhh I need to isntall libc 2.25 huh <lfam>Guix and debug symbols are a topic I haven't explored. Someone else may be able to guide you <lfam>If not, sending a message to <help-guix@gnu.org> should work <nckx>areckx: & be sure to install glibc:debug, not glibc. <lfam>nckx: I believe they did that (I helped them with it earlier) <civodul>areckx: you seem to be mixing /usr/bin/ld with Guix stuff, which could cause problems <areckx>yes I installed glibc:debug first <areckx>civodul: well how am I supposed to use debug symbols? <areckx>I am trying to make a Makeile that uses the ones that I install from guix <areckx>because arch doesn't have debug symbols unless I build from AUR and I'd rather manage my debug symbols with guix <areckx>seems like an elogant solution but I just don't know how to implement it <nckx>Oh, so (/usr/bin/)ld is trying to *write* to that location. I think I get it now. <civodul>the /usr/bin/ld message is hard to interpret without more context <civodul>areckx: how did you obtain that /usr/bin/ld message? <areckx>I am trying to use debug symbols from glibc:debug with a simple test C program with a Makeile <civodul>did you install the "gcc-toolchain" package? <areckx>I have gcc installed through pacman on my archlinux distro <areckx>but arch strips all of its debug symbols out <civodul>so you need to install Guix's "gcc-toolchain" package along with its "debug" output <civodul>or you do everything with Arch packages <areckx>and in order to get them I would need to compile every single update, which is not what I want to do, I would have installed gentoo if I wanted to compile <areckx>would I need to export PATH stuff? <civodul>yes, but 'guix package' will tell you <civodul>and you can source ~/.guix-profile/etc/profile <areckx>yeah I have been reading the info docs but sometimes it's not clear to me I think I am not understanding things <areckx>I think my next laptop I might just completely install using guix it seems very elogant <areckx>I'm so used to one way of doing things though so maybe not LOL <areckx>ok I think I'm going to uninstall all the guix/guile stuff from pacman and install guix from tarball <areckx>hmmm guess not guile it's needed by make