<buenouanq>so, stock gnome doesn't have a `tap to click' touchpad setting <buenouanq>searching around, the newer libinput driver is mentioned <buenouanq>can I just install it as a normal user with guix and expect it to work? <buenouanq>which of the 3 we have packaged should I be getting? <ng0>I think I have just found the solution for fish on guix. I have to process the notes tomorrow. <ng0>heh. and zsh vendor path looks easy too. ***OriansJ`` is now known as oriansj
<oriansj>janneke: well M0/M1 is cpu agnostic. The definitions you create entirely define what target will be generated. Perhaps I should make a guide to clarify how it works and how to create and use definitions. <janneke>oriansj: ah, so you made it easy by adding MES_CORE_DEFS that can be used to replace everything in Mes and we do that first <janneke>when that works, we could translate some of that alphabet, if we want ***exio is now known as exio4
<jsierles>hey, got a strange error from the daemon: unexpected Nix daemon error: implementation cannot deal with > 32-bit integers <rekado>that’s a strange one indeed! Haven’t seen that before. <jsierles>i'm running on a 64 bit mac, can't imagine what it would be <jsierles>this happens when connecting to the daemon remotely over TCP <jsierles>ugh, and still have an issue with mounting the store into a docker container. 'guix package' fails half way through and seems to corrupt the store. <jsierles>could this have something to do with running in alpine? <jsierles>are there any plans to implement something like nix channels? <rekado>oriansj rain1 janneke I just registered #bootstrappable on IRC; feel free to discuss bootstrapping things there. <efraim>I'm not sure scm from scheme.scm supports aarch64 <oriansj>janneke: yes but I think a proper introduction to M0/M1 is probably required prior to its use. <rekado>I just got an interesting error. <rekado>Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS <rekado>mekeor: Please do not post resources for non-free software here. ***that_guy_ is now known as nliadm
***Exagone314 is now known as Exagone313
<gnewb>When I run guix system reconfigure /etc/config.scm it fails with following output: <gnewb>guix system: error: profile contains conflicting entries for python:out <gnewb>guix system: error: first entry: python@2.7.13:out /gnu/store/...-python-2.7.13 <gnewb>guix system: error: second entry: python@3.5.3:out /gnu/store/...-python-3.5.3 <mekeor>gnewb: could you paste your config.scm (e.g. on paste.lisp.org)? <rekado>gnewb: That’s a problem with our over-zealous conflict checker. <rekado>gnewb: For now it’s best not to install both variants of Python into the same profile, until this is fixed. <gnewb>mekeor: paste.lisp.org tells me that it "is available in 0 channels on the IRC network Freenode." <mekeor>gnewb: you don't have to select a channel, AFAIK <reepca>gnewb: that just means that the paste bot isn't here, but you can still put links in here yourself. <mekeor>gnewb: are you really sure that you need all those packages as system packages? <mekeor>gnewb: why not install them as user? – you could also use a user-manifest for that. <mekeor>gnewb: anyway, i think you have to strike-out one of "python@2" and "python" <gnewb>mekeor: When I remove the python@2 I get: <gnewb>guix system: error: profile contains conflicting entries for gtk+:out <gnewb>guix system: error: first entry: gtk+@2.24.31:out /gnu/store/xjccp5rck2nnw39wlyzyfc732cqhnlw4-gtk+-2.24.31 <gnewb>guix system: error: ... propagated from exo@0.10.3 <gnewb>guix system: error: ... propagated from xfce@4.12.0 <gnewb>guix system: error: second entry: gtk+@3.22.15:out /gnu/store/vqbk99lvz4bsc6gfn9hfrxs67daya4b9-gtk+-3.22.15 <gnewb>guix system: error: ... propagated from libxfce4ui@4.12.0 <gnewb>guix system: error: ... propagated from garcon@0.4.0 <gnewb>guix system: error: ... propagated from xfce@4.12.0 <mekeor>gnewb: it's better to use a pastebin (like paste.lisp.org) for snippets with more than two lines ;) <mekeor>anyway, i think the gtk+ conflict is a current bug with the xfce-package <mekeor>i'm not up-to-date with this issue. maybe others can help you? <mekeor>gnewb: still, i'd suggest you to remove most of those packages from the list of system-packages but instead install them as user! <gnewb>mekeor: I will try using the --manifest option in the future. I just read the documentation. <gnewb>Since the gtk+ conflict is a bug I will wait until it is gone before I try upgrading again. <reepca>If anyone wants a mind screw, glance through nix/libstore/globals.cc until you find get(), and then try to figure out which variable "settings" refers to <efraim>I looked through it a bit when trying to add aarch64 support, not something I really want to relive <efraim>I still can't figure out why I can run armhf guix-daemon but I can't get the aarch64 daemon to build for armhf even when mirroring the x86_64 and i686 code <reepca>I'll spoil it then - it's not the global variable declared in the same namespace at the top of the file, nor is it the global variable by the same name declared in another file. It's a "private" variable declared in another file. <boskovits>i'm interested in building maven projects the guix way. <boskovits>I have seen attempts to bootstrap maven and create a maven build system, but I don't know about the current status. <catonano>boskovits: you gotta askk rekado about this. He is working on bootstrapping teh jvm based stuff the Guix way <rekado>boskovits: I haven’t worked on maven recently. Not directly, anyway. <rekado>boskovits: but we’ve been getting closer to a maven package simply by building more and more java packages with the ant-build-system. <ng0>do we have something globally declared like NIX_PROFILES (with no bashism in it) where the users /home/user/.guix-profile/ is in? <jsierles>is there a built-in way to get a list of available packages in json format? <ng0>something= a variable <rekado>jsierles: no json, but you can easily hack it up with guile-json. <rekado>jsierles: or you can use recutils <espectalll>Uhm, is it normal that Guile takes forever to compile? <ng0>there's an open bug… yes <jsierles>ng0: i saw you reported an issue a while ago about an EOF error in the middle of substitute downloads. i'm getting just that same error now too. <ng0>oh? I don't remember this <jsierles>using a store that's mounted from my host into a docker container. did you ever find out what caused it? <jsierles>guix pull: error: build failed: unexpected EOF reading a line <ng0>espectalll: one moment <boskovits>Do you have a plan, or list of packages that are needed for maven and can be build from ant-build-system? <jsierles>this happens consistently if you mount the store into docker actually. <jsierles>running this actually corrupts the store and breaks guix completely <efraim>Sometimes when the substitute ends in the middle its a bad cached item and needs to be cleared manually by one of the server admins <jsierles>yeah, that happened to me before. but this is a different issue. something about mounting the store into container breaks the daemon <espectalll>ng0: I don't think it was the report you shared, as I meant compiling Guile itself (the package) and as my system was using less than a GB of RAM <jsierles>is there a way I can get more information about what's being run to fetch substitutes? <jsierles>OK - looks like my issue was the sqlite database wasn't available when starting the daemon. it created a new one, but by having some stuff already in the store, it broke. <rekado>jsierles: the db and the store must be consistent. <jsierles>rekado: yeah. so at least i solved the issue! that brings up the question, what happens if the db is corrupted? would the store have to be wiped? <rekado>boskovits: I have no plan. I usually just take one unpackaged piece of software and fall down the rabbit hole. <rekado>jsierles: it’s possible to fix the store contents given a good database. The other way around… probably not. <rekado>AFAIK “guix gc --verify” uses the database to check the store. <efraim>according to 'guix package -A | cut -f1 | sort -u | shuf | xargs guix build --no-grafts --no-substitutes --keep-going --sources=transitive' we're missing upstream sources for: ruby-mintar, libhilbert, handbrake, lightdm-gtk-greeter, xsge, gajim, unshield-avigomanager, 'svn-checkout', git-remote-gcrypt, Noto-hinted, libpng-1.6.28-apng, artanis <efraim>also I seem to be piping it through less for some reason <rekado>I can confirm that lightdm-gtk-greeter has disappeared. Tried building it today. <efraim>only took 4 hours to test this time, took ~18 the first time I ran it last month <rekado>janneke: I forgot to invite you: I’ve registered the #bootstrappable channel on freenode for discussions about bootstrapping work. <jsierles>what could cause this? guix substitute: error: mkdir: File exists <rekado>jsierles: could be that a directory exists when Guix expect it not to exist. “mkdir” fails in that case. <jsierles>rekado: why would it expect it not to exist? <jsierles>ncurses seems to be part of the initial binary tarball <rekado>I don’t know what it’s trying to do. <jsierles>not sure why it would be installing guile. <rekado>I don’t know what you are making it do :) <rekado>to me it looks like you already have the directory that it wants to create. <rekado>probably because you have a store that already contains it but with a database that doesn’t know about it. <jsierles>here's what i'm doing. unpacking the 0.13.0 tarball to gnu/store and var/guix/db <jsierles>then just running 'guix package -i bash' <rekado>is this in a container or is there anything special going on? <jsierles>yup in a container. let me try again from scratch to be sure. <jsierles>i see lock files in gnu/store for these packages <jsierles>gnu/store and var/guix/db are the only things required to run guix from binary install, right? <jsierles>i mean the only things needed from the tarball. <reepca>Well, at some point "guix" needs to be somewhere in the path, I think the manual recommended /usr/local/bin for that. Also a bunch of other directories in /var/guix, like gcroots, profiles, daemon-socket, etc. <jsierles>ok. so running from scratch, exactly as the manual suggests, the same issue happens. <jsierles>i also disabled deduplication. maybe related? <jsierles>nope, happens with that option removed too. <jsierles>rekado: so I removed the offending package from the store. running 'guix package -i bash' again, the directory is restored and the same error is thrown <jsierles>so the same build process seems to install the package and then complain that it exists <espectalll>May I ask a dumb question? I'm tired of asking stuff and this *should* be really easy, but I'm getting a bit desperate as I've been reading stuff and trying stuff for a while now. <jsierles>OK, fixed all my issues. the issue was using a bind mount from the OSX filesystem. something gets lost in translation there. using a docker data volume works. so, in conclusion, use docker data volumes for guix store on mac! <bavier>espectalll: there are no dumb questions here <buenouan1>or just install guixsd and forget about osx ┐( '~')┌ <buenouan1>that is neat though - does this have the potential to replace things like homebrew? <espectalll>PulseAudio just left me deaf for a moment, which means I have to set `flat-volumes` <espectalll>a setting which is on a system-wide, read-only file, `daemon.conf` (because of deterministic stuff I guess) <espectalll>So how do I configure PulseAudio? With my `config.scm`? <bavier>espectalll: that would be the way <bavier>espectalll: but iirc we don't have a pulse-audio service that exposes such configuration. <bavier>espectalll: so you'd need to use, I think, etc-service and plain-file to export the configuration file to the desired location. <rekado>isn’t pulseaudio started on demand as a user? <rekado>I don’t think we have a way to configure it system-wide at all <koosha>rekado: Every time i reinstall guix I get new errors :| <mekeor>go ahead, koosha, tell us the error message ;) <koosha>There is a Backtrace which has a lot of information . <ng0>hm.. anyone else who can't autojoin multiple channels anymore with weechat 1.9? <rekado>koosha: is this after “guix pull”? <koosha>rekado: No , after 'guix system init' <rekado>koosha: did you run “guix pull”, though? <koosha>rekado: And after that 'guix system init' ? <rekado>“guix pull” is going to take a while, but once complete you should get the latest substitutes <rekado>I tried installing from 0.13.0 just now and noticed that a lot of substitutes are missing. <rekado>so I’m also running “guix pull” right now. <jsierles>is there a way to get a binary install of git master? or, emulate the binary install process using master? <jsierles>iirc, rekado you are only using git, not 'guix pull' correct? <espectalll>rekado: You're right, there's an user-specific path for custom settings <espectalll>however, this is something that should be rather patched by default on the repo <espectalll>so at least I wanted to see how to set it globally <ng0>has someone tried building linux-libre without perl? I'm just watching a talk where it is mentioned that the author commited patches to linux to make it possible to build it without perl, a while back <jsierles>would 'guix pack guix' create the same thing as the binary install tarball? <rekado>jsierles: I’m using “guix pull” for a new installation. <koosha>rekado: I have a warning : "Failed to expand heap by 8388608 bytes" <koosha>"Unwind-only 'out-of-memory" exception; skipping pre-unwind handler. <koosha>Out of Memor Heap size: 752 MiB. Returning NULL! <koosha>Out of memory - trying to allocate requested amuont (552 bytes) ***oriansj` is now known as oriansj
<rekado>koosha: how much memory do you have? <rekado>there’s a bug in the latest version (latest Guile?). It needs way too much memory. <koosha>rekado: You mean RAM ? Its about 2G <iisjmii>Hello all, I'm new to Guix. I just installed GuixSD. Installation went without errors, but grub doesn't appear to be installed to my device. Which is set to "/dev/sda" which is correct. Any sollutions? <koosha>rekado: Sorry , I have 1G on this machine <lfam>iisjmii: Please share the output of `fdisk -l` and the GuixSD system configuration file that you used on paste.lisp.org <rekado>koosha: 1G will be very difficult. <rekado>I have one machine with 1G of RAM (it’s a i686) and I need to make sure to kill most processes when running “guix pull”. <rekado>otherwise it simply won’t finish. <rekado>koosha: it’s very unfortunate you’re having such a terrible first experience! <koosha>rekado: Yeah , nothing makes the process successful . <efraim>My laptop with spinning rust and my aarch64 board with an SD card take hours to complete 'guix pull' <efraim>My aarch64 board with 4GB of RAM is about 45 minutes <koosha>rekado: But why ? I had microsoft windows 7 on it and I ran some games on it in the past . <iisjmii>sorry for the wait, was trying getting scp/nc to work when I realised I could just use a thumbdrive :) <lfam>iisjmii: Does this machine use EFI? <iisjmii>It is disabled in the bios, set to use "Legacy BIOS" mode <lfam>Hm, does anyone else have any ideas for iisjmii? <iisjmii>related, is there a way to chroot into an installed system to try grub-install by hand. Or is this a bad idea? <rekado>koosha: it’s a regression. Previously 1GB would be absolutely sufficient. <rekado>koosha: Guile 2.2.2 has a problem with memory consumption. <efraim>I looked at arch's pkgbuild for links, I might need to tweak ours, framebuffer support would be nice <koosha>I think it's better to come back to ubuntu yet. <quigonjinn>iisjmii: could you try to boot the system via the grub in the installation image? If it works, and the grub.cfg is there, you could install grub manually <rekado>koosha: yes, I think you’re currently better served with a different distribution. <quigonjinn>iisjmii: boot the usb image, enter grub command line, then: 'set root=(hd1,msdos1)' 'configfile /boot/grub/grub.cfg' <rekado>koosha: I hope that by the time of the next release we will have fixed these issues. <rekado>ACTION just installed GuixSD on a server … but it fails to boot, waiting for “my-root” partition to appear… <quigonjinn>iisjmii: maybe grub is installed, but the BIOS is trying to boot the other disk? I see you have 2 <ng0>so I just had this epiphany and made a 360° circle in the development on my system, in other words I solved the knot I had and I hope that there can be an 100% compability between the systems. it is super modular and if this works out the way I think it does, I have just come up with the (currently) best way to start building customized and preconfigured systems on top of GuixSD with compability to GuixSD and <ng0>with custom packages and nar builds etc <ng0>now I need to write all of the notes I scribbeled into a chat down into comprehendable words of the design <ng0>there's a 0.1% modification of guix codebase needed, but I hope to get over that aswell <ng0>I'd rather just present the full first version of the handbook and maybe post an abstract of it once I'm done to the relevant mailinglists :) <ng0>it's about this minimal core system + extension of it (persistent live-system, etc) I've been looking into <rekado>error_error: that’s because they haven’t been updated yet. <janneke>probably upstream has not switched to GuixSD yet ;-) <ng0>oriansj: i would point to the website, but I really suck at written transparent full-length descriptions. when I talk about it (as in speaking) it's better <rekado>error_error: you would need to package it. See the Guix manual for information on how to do this. <ng0>oriansj: so I hope someone will fix the website once my idea is transported better <boskovits>I have found a reproducibility error in ghostscript. It seems, that it is already resolved upstream, how should I go on with this? <rekado>ACTION wonders if there’s something wrong with the initrd… <rekado>boskovits: you can change the ghostscript package by adding a patch to the source field <rekado>boskovits: we have a couple of packages that do this, so you can just search for “search-patches” in gnu/packages for a start. <rekado>error_error: if there are hardcoded file names they would have to be replaced. <rekado>error_error: we sometimes do this in an extra build phase, but often this is taken care of by the configure script. <oriansj>ng0: no worries, look forward to it. {now back to writing M1 documentation/tutorial) <jsierles>so once guix is bootstrapped into a store, can I use GUIX_PACKAGE_PATH to point at both guix and my own modules? <jsierles>what bugs me now is having to depend on slow `guix pull`, for example for rolling back to older core modules <rekado>jsierles: making “guix pull” fast is on the roadmap <jsierles>rekado: alright. but i'm curious, what does 'guix pull' do exactly? <jsierles>i'm really pedantic about being able to bootstrap whole environments in a declarative way. so this is one part that feels less safe. <rekado>“guix pull” downloads a tarball of master and builds it. <jsierles>ok. so we get a new derivation of 'guix' in the store? <jsierles>i see the package definitions are inside guix-0.13.0 in the store <jsierles>so just wondering, how does guix pull switch you to to new tools and definitions? <rekado>it sets ~/.config/guix/latest, which is checked first <janneke>error_error: if the package is well behaved, packaging is trivial <rekado>error_error: with “guix pull” and then “guix system reconfigure /etc/config.scm” <rekado>(note that “guix” is a per-user command) <jsierles>rekado: ok, now i get it. did you work on the julia definition? <ng0>error_error: and note that only privileged users / root can run reconfigure. <jsierles>guix package: error: build failed: while setting up the build environment: getting attributes of path `/etc/nsswitch.conf': No such file or directory <rekado>jsierles: I’d be happy if someone could figure out why some of the tests are failing… :) <jsierles>rekado: will look into that once i get my head around it <jsierles>why might guix be looking for nsswitch.conf? <boskovits>rekado: I am trying to package thrift. What do you think, in which file should I put the definition? <quigonjinn>iisjmii: or it might be 'hd0,msdos1', you can type 'ls' to see all partitions <catonano>keeping a spreadsheet opened and idle in Libreoffice gets my cpu to spin unreasonably and my laptop to get so hot ! Especially in these days this is no good ! I was wondering if anyone has any experience related to Libreoffice to share <lfam>catonano: Do you have access to another distro, so that you could see if their libreoffice package does the same thing? <catonano>my Fedora is on a deskktop so I'm less likely to get annoyed by cpu spinning, there. I'll ave to use top to check that out <lfam>catonano: I just got a Debian security advisory about a regression in libreoffice caused by the fix for CVE-2017-1000364. No details beyond that but perhaps a clue <lfam>Could be unrelated, but something to read about, anyways ;) <lfam>ng0: That looks unrelated, but we should deal with those bugs <lfam>Our libreoffice needs a lot of work. Most of the dependency tree is out-of-date <lfam>I wish somebody would adopt (gnu packages libreoffice) <lfam>Somebody with a very fast computer <catonano>lfam: the bug you indicated seems to be about Libreoffice not even starting <ng0>someone with 32 cores or something… <rekado>hmm, I have a big workstation at the office… <ng0>how does this thermald work? I'm not really convinced that 96°C while compiling is good. <ng0>everything I can offload to is much much slower <ng0>not how, but is it effective in preventing high temperature borderline? <lfam>ng0: Your CPU should self-regulate its temperature. I think you only need thermald when something is broken <lfam>Like, if a fan is broken or clogged with dust <ng0> but stays at 96°C when all cores are active at 100% <lfam>That's probably it's maximum temperature <lfam>Maybe you can use it to make tea <ng0>that's not helpful :D <ng0>last time it got this hot the wifi card binary blob segfaulted :D <rekado>ng0: is the sensor calibrated? I had sensors in past machines that would give bogus readouts. <ng0>I've never doen that anywhere <ng0>maybe I should find out how to do that <ng0>I already throttle the speed <catonano>ng0: in my experience, when my technician refreshes my thermal grease and cleans my grates, the computer seems like a brand new computer. Too bad that doesn't last very long, it should be done every couple of months <ng0>sometimes I just hate screws. <rekado>the IBM P70 is really easy to open. <rekado>it has three big spring-driven screws with screw heads that can be turned with a coin. <rekado>that’s enough to remove the back and get access to the math coprocessor, the CPU, all 8MB of RAM, the display card, the power supply, the 60MB hard disk… <janneke>wondering about running guix gc some time... <janneke>would it be possible to suggest removing store items that have "duplicates" and start by removing those that were built earlier?