<ngz>Hello. I'm trying to build a package using cmake-build-system. The GCC toolchain offered is 5.4.0. Is there any way to use a different version? <ng0>should we have minimal specs for Guix on the website? I increased my swap spaces now and I am waiting if the pull will suceed now <ng0>at least on IN-Berlin the RAM and small swap was to blame I think <ng0>for the pull fialing I meant <ryanwatkins>Hey guys, where can I locate tor logs for the tor service and also the torrc location? :D <brendyyn>I have to add #t to one line but now I'm stuggling with a rebase conflict <b11111000000>guixsd can't be installed from gnu server to couple of slow machines for now... It's always compile mesa or something... How to create installation media with force use of preloaded packages? <reepca>hm, it seems that installing gcc and mingw-w64 at the same time doesn't work too well - collisions in ~/.guix-profile/include <DoublePlusGood23>When I build a new package is the best way to exucute it just by running it directly `/gnu/store/blah/foobar-1.00/bin/foobar` ? <b11111000000>DoublePlusGood23: your package bin is in $PATH? Than it does't matter how you run it... But I have similar question about xdg configuration and app manifests <DoublePlusGood23>b11111000000: that will let me use tor, but it won't completely anon me. <reepca>DoublePlusGood23: for purpose of testing or for regular use? For regular use it would make sense to just install the package into your profile, for testing / development it would make sense to use the full path directly (adding it to PATH temporarily might help, or an alias, or a symlink somewhere). I don't know of any special way of dealing with that, though I do wonder what (if anything) keeps "guix build" outputs from being garbage <brendyyn>Can fonts in /share/fonts/truetype/ not be in subdirectories? <itsfemme[m]>DoublePlusGood23: ng0: the best would be to package torbrowser-launcher <reepca>guix environment foo && guix build foo --no-substitutes works okay for testing the building of foo quickly until it turns out to require subversion for fallback, which guix environment foo doesn't provide for some reason. <itsfemme[m]>b11111000000: tor browser exists so people dont try to torify a browser expecting to be anonymous because it's not, most browsers are very fingerprintable and with just torify you don't get stream isolation. I rec. reading the tor browser design document, it explains all of this very well <b11111000000>help! On Acer notebook - there is no way to set Bootable flag both in cfdisk and fdisk! <b11111000000>how to fix that? how fix when there is already installed Guix on `sda1` mounted to /mnt/ <b11111000000>Need I to use gdisk to convert my partition table from GPT to MBR? Or what? <brendyyn>Turns out it's a fc-cache thing. someone is working on a font-build-system it seems <b11111000000>2. how to gracefully umount (and then remount) /mnt to do manipulations with partition and then try to continue the installation? <Apteryx>brendyyn: You had to run fc-cache to get your fonts working? <Apteryx>Hmm. GUILE_LOAD_COMPILED_PATH is /run/current-system/profile/lib/guile/2.0/site-ccache:/run/current-system/profile/share/guile/site/2.0 on my GuixSD system. I would have expected 2.2 or something since I reconfigured and reboot this morning. <brendyyn>Now my chinese characters look great but the latin characters look terrible <brendyyn>Is it possible to set fonts for different character ranges like Emacs can? <Apteryx>brendyyn: maybe you'd want to customize ~/.config/fontconfig/fonts.conf ? <brendyyn>Maybe? Is it possible to do it with that? <Apteryx>brendyyn: I'm not sure what you mean by "character ranges", but if you meant font families (such as serif, sans, etc) yes that's where you'd do that <brendyyn>Apteryx: No, I want one font for ASCII and another font for Chinese characters <Apteryx>Hmm. Not sure how to do that, sorry :/ <brendyyn>Seems pretty basic to me but looks like it's impossible <brendyyn>I mean how is one even supposed to configure fonts then -.- <brendyyn>You just have to deal with having one font for everything <Apteryx>To match a font based on some "range representation" or unicode charset. <Apteryx>But finding actual examples might be hard. <Apteryx>Q: Are we supposed to do something special other than having the nss-certs package in my operating-system declaration? <Apteryx>Q (continued) to have working SSL in guix-emacs such as required when linting packages? <ng0>actually two questionmarks. <ng0>it's everywhere. I think this is some kind of decoration fallback <ng0>like this: This is nice, but what are the actual benefits of ?bootstrappable? implementations? <catonano>ng0: I see no question marks. This usually boils down to a character encoding issue <reepca>"Made with ? by humans and powered by GNU Guile." Hehe <ng0>question everything. <ng0>but in the sourcecode it is correct <ng0>didn't HE.net used to have some IPv6 static IP program for free? I can't find it anymore. Is this what their 'tunnelbroker' is? <rekado>ng0: thanks for the note about bootstrappable.org <rekado>must have broken when I had locale problems on the machine where I generated it <rekado>maybe the move to guile 2.2 didn’t work for haunt <efraim>i forgot about he.net, only ever heard good things about them <rekado>re haunt: it got confused by a mixed GUILE_LOAD_PATH <ng0>I'm looking into setting up my own dynamic dns where content is served from multiple locations, if I'm not satisfied with the features I can use. And I like documenting this for another project, so that's the diy thing <rekado>bootstrappable.org has been fixed. Thanks again. <rekado>I can’t compile Guix on my i686 machine any more. Running out of memory with Guile 2.2 :( <ng0>I needed 2.2 GB Swap for pull <rekado>is hydra still performing evaluations? <rekado>there are no substitutes for icecat on x86_64 and i686 <ng0>I really hope I get guix pull to finish in less than 15 hours when I upgrade to whole, unshared physical CPUs in the virtual machine oO <jlicht>civodul: no luck on reproducing my weird $TERM issues :/ <civodul>well if it doesn't happen again, we can consider it notabug :-) <civodul>rekado_: there was an eval this morning, but i just started a new one <civodul>rekado_: you might want to add bayfront.guixsd.org to your substitute list BTW :-) <jlicht>Do I also need to add bayfront manually if I am running GuixSD? <ng0>I really think we need to talk about the increased time of guix pull and the build of it. it is crap right now on small servers, even if it succeeds after 14+ hours <ng0>I think some benchmarks or specs would be good, to not give people who want to run it on servers once we have a server image false impressions <jlicht>ng0: guix pull takes 14+ hours for you :O? <ng0>it used to be zillion times faster on those shared CPUs before 2.2 <jlicht>would it be possible to somehow ´offload´ guix pull, or at least the computationally intensive parts? <ng0>after 13.15 hours I have 91 percent progress with pull <ng0>because there can be people who just want to have it on one server, I can offload but that doesn't make the problem go away <jlicht>ng0: of course, but it could alleviate the issue with having to wait almost an entire day for security updates on low-powered devices that might be connected to the Internet 24/7 <ng0>even dedicated hardware has considerable differences now. about 2 hours on this server, less than 5 minutes on my laptop and the vservers are in the range of 8+ hours <rekado_>I haven’t observed anything that slov <ng0>with low-powered devices you have other issues. when you get low-powered devices you don't want to get an high-.powered device to get the low-powered device to be usable <rekado_>compiling *is* much slower than before, but not on the order of 8+ hours. <jlicht>Me neither, and I have some *old* devices running GuixSD, and even there I barely have to wait 30 minutes <ng0>the 8+ hours are on x86_64,KVM and qemu with enough virtual CPUs to compile everythin <ng0>one debian and on guixsd <rekado_>because this sounds like a virtualized CPU to me <civodul>m-o: how is the bootloader patch series coming along? :-) <civodul>m-o: i'd like to merge the UEFI thing, which depends on part of that series <ng0>like I said, it used to be much better <ng0>and I didn't change hosts <ng0>so I wonder wth happened between 2.0 and 2.2 <ng0>I can (and will) upgrade the IN-Berlin one to a full, non-virtual CPU <rekado_>ng0: but your times are the outlier here, so it would be good to check if you’re actually using KVM or an emualated CPU via qemu. <rekado_>even on an old i686 netbook it’s not nearly as bad as in your case. <ng0>before 2.2 it wasn't this bad <ng0>there was no difference between servers and what I run here <efraim>My 10 yo laptop with a spinning drive is only 90 minutes if I close Firefox, times out otherwise <efraim>RAM might also be a deciding factor <brendyyn>ng0: 2.2 .go files are like 50% bigger I think <rekado_>if you have very limited RAM your system might swap out to disk all the time. <ng0>like I said, prior to 2.2 it ran perfectly fine with the 512MB RAM system and with the 1024MB RAM system <rekado_>brendyyn: size has nothing to do with it. The 2.2 go files are also a different format (ELF). <rekado_>ng0: 2.2 needs more RAM for compilation. <rekado_>but I think that’s only because we try to do parallel compilation <rekado_>maybe there’s a way to disable this on machines with less RAM. <ng0>which brings me to my statement, this should be mentioned public <rekado_>it’s not a secret. You can post your findings to guix-devel. <wingo>RAM usage of 2.2 .go files should be lower fwiw (in terms of RSS/PSS). <ng0>that's not where people installing GuixSD on servers will look first. they will look somewhere in the documentation or website for limitations. right now there's nothing listed for hardware, at least last time I checked <rekado_>ng0: the release is due this week. The switch to Guile 2.2 will be mentioned there. <jlicht>ng0: Are you referring to publishing recommended system specs on the website? <ng0>irc is suboptimal for good communication. what I meant is what jlicht wrote. <m-o>i rebased on top of leo patches <m-o>i guess i'm ready to push <jlicht>I actually think that is a good idea. It would help managing expectations people have as well. <m-o>civodul: i'm working on doc+test but i'll commit the serie anyway this evening <civodul>m-o: do you think you could push the patch that Marius needs earlier? <wingo>civodul, rekado_ do you want some part of the potluck patches for this release? maybe the services i guess <civodul>i was initially planning for the release tomorrow, which is why i'm getting nervous ;-) <civodul>wingo: yes i think the services were pretty much ready no? <civodul>and they're problably not disruptive anyway, so that sounds good to me <rekado_>ng0: you can disable parallel compilation by changing “par-for-each” with “for-each” in build-aux/compile-all.scm <rekado_>ng0: could you try this and see if it helps in your case? <ng0>i don't have enoigh software set up on either of these purpose restricted servers to test this. sorry. <rekado_>not enough software to run “make”? Ah, you’re using “guix pull” only. <jlicht>It actually left me wondering. civodul (and many, many others) spend astounding amounts of time on guix related things. Are you just very efficient with your time, or do you also work on guix during working hours? <wingo>i think you should be able to run the build-aux/compile-all.scm script without a git checkout <m-o>civodul: just pushed the serie, it was good to go for me anyway. <rekado_>sadly, even without parallel compilation I get a crash on my i686 netbook trying to build Guix. <rekado_>“GC Warning: Out of Memory! Heap size: 593 MiB. Returning NULL!” <civodul>jlicht: that was free time for me until recently <ng0>jlicht: filling the gap between last job, start of university, finding a job and actually using the work on Guix for looking into starting something which includes GuixSD among other things. <jlicht>ng0: civodul: lots of respect and thanks to you both <civodul>m-o, rekado_: i was wondering whether to take the bootloader patch set wholesale for the release <civodul>i'm tempted to be conservative and cherry-pick just what the UEFI patches need <rekado_>it would be a pity if we broke things right before the release <civodul>right, so we have them in master, but we can omit them from the 'version-0.13.0' branch <rekado_>since I haven’t been able to test the patch set yet, I’d be more comfortable with cherry-picking just the UEFI patches. <civodul>it would be awesome if people could review NEWS and add the missing bits! <civodul>wingo: i think we have a memory leak or something with compile-all.scm on 2.2 <civodul>it consumes much more than with 2.0, although i'd expect it to consume less memory <civodul>problem is that gcprof is not very helpful <rekado_>I observe the memory leak trying to compile gnu/packages/python.go <civodul>gcprof shows make-stack/vector-copy at the top because it doesn't know where its own stack frames are, due to multithreading <rekado_>memory usage ramps up to 80% of what my system has and then stays there, even as it eventually moves on to smaller modules like gnu/packages/qt.go <rekado_>FWIW: I get this also after changing “par-for-each” to “for-each” and removing mutex handling. <civodul>rekado_: it peaks at 900M RES for me (x86_64, with par-for-each) <rekado_>civodul: is it noteworthy (in NEWS) that R now builds reproducibly? <civodul>hmm time(1) reports "3827840maxresident", which would mean 3GiB? <rekado_>civodul: another notable thing under “Programming interfaces” might be various improvements to the asdf-build-system (done with 8a3814cdc5be79f4308ce20d8351d5bcc9536ee2) <civodul>"guild compile -O0 gnu/packages/python.scm" does a little better memory-wise, but not significantly so <m-o>civodul: what patch of the serie would you cherry-pick ? If you take the first one, sadly, you have to take the whole serie ! <rekado_>brendyyn: this news: “git show origin/version-0.13.0:NEWS” <civodul>m-o: uh, dunno, whatever Marius' patch needs <rekado_>civodul: one more thing for NEWS: the Cypher backend for “guix graph” (see 5899fafbfefcd7682aec8f2caaaad3add678a3c4) <efraim>I don't think I did as much random upgrading between 0.12 and 0.13 <rekado_>civodul: the “old distro” warning (commit 7fd952e05203d975fcb6cdabd2f742ade1b31b66) is probably also a good thing to mention. <m-o>civodul: i had a look to marius patch, he needs the whole serie indeed. <rekado_>going through the git log since 0.12.0 civodul’s work to get to a release target is really impressive! <rekado_>civodul: support for ISO-9960 images (06110559bbc1a73544b197dab4cde2439aad4c66) should also go into NEWS <rekado_>I think we ought to write the NEWS for 0.14.0 as we make noteworthy commits. <brendyyn>civodul: Will the news have the number of new contributors and packages? <ng0>for me it stays at 460MB RAM + around 1.6GB Swap, with some phases in between where RAM is used less <ng0>brendyyn: the people who contributed and the commit numbers since 0.12 <jlicht>civodul: I found the problem regarding the segfault :D <jlicht>well, actually not :D. I have a (use-modules (ice-9 readline)) (activate-readline) in my ~/.guile file <jlicht>So I guess I will try to see what is going on in guile and/or readline then <m-o>civodul: In 0.13 NEWS, you could mention the raw-initrd thing (for people with custom kernel configurations) <civodul>rekado_: while you're at it, could you add raw-initrd? ↑ <rekado_>on a really big system at work Guile 2.2 gets stuck compiling. <civodul>yeah memory usage seems to grow with the number of threads <rekado_>a user complains that the upgrade to Guile 2.2 isn’t smooth enough <rekado_>I wonder if we could just build Guix on hydra and have people download that instead of having to use “guix pull” or “git pull” <rekado_>we already build the “guix” package for releases and for a development snapshot, but maybe we could just offer a new binary continuously <ng0>trust is still given through hashes and checks, so why not.. <civodul>rekado_: yes, that's what we should do for the future 'guix pull' replacement <jlicht>how would that work? You can´t really have the hash of the latest checkout in the latest checkout :right? <rekado_>jlicht: it doesn’t need to be part of Guix, but could be a separate job set on hydra. <jlicht>ah that makes sense. And if you trust some machine to give you proper substitutes, why not use that same trust to have them serve you the latest-and-greatest of guix? <rekado_>there have been too many changes since the last release! <rekado_>how about I make the next release in 6 weeks? <ng0>17 hours, 94% of guix pull. yes there is a problem :) <ng0>just logged in to hope it was done <rekado_>ng0: it’s going to take a very long time if you’re swapping. <rekado_>maybe change swappiness or disable swap <rekado_>it worked for me within 30 mins after killing a few processes to free up memory <ng0>I have no processes I could kill, that's just a webserver. yeah, next time. with the recent changes I just wait for the release and try GuixSD on IN-Berlin with enough RAM. even if it's overkill <rekado_>I’m just saying that reporting how many hours have past when your machine is swapping isn’t really helpful. <rekado_>*everything* is going to be slow when the system is thrashing <brendyyn>It's been a while since I gave my computer a rest ***andreh1 is now known as andreh
<rekado_>oof, the build failure in python2-cryptography is due to “OSError: [Errno 12] Cannot allocate memory” <rekado_>so I guess I’ll just wait for a substitute <bavier>rekado_: like, exhausting your machine's memory? <wingo>civodul: if compile memory usage is an release blocker in the single-thread case then probably the guix release should be postponed, dunno <wingo>i can have a look but it is a tricky problem <wingo>can't promise quick solutions especially if they need a new guile release to solve them <civodul>i hadn't noticed it until recently, but that's also because i have a biffy laptop <rekado_>it’s especially bad when running “make -j 32” on a machine at work. <rekado_>I told the users to just run plain “make” <rekado_>it’s not a release blocker, but I think we ought to note it in the announcement as a known issue(?) <wingo>civodul: what provides the "time" binary? <efraim>'which time' doesn't show anything on my Debian box, so probably bash or busybox there <lfam>wingo: the 'time' package, right? <wingo>ACTION responded to compile-time mail <civodul>wingo: it's GNU time, "guix package -i time" <civodul>rekado_: "-j" actually has no effect on what compile-all.scm does <civodul>compile-all.scm always uses all the cores, which is something we should fix <civodul>but yeah, on a 32-core machine it's worse than on my 4-core laptop, i don't know why <ng0>on my 8 cores laptop it gets hot <rekado_>so what “fixed” it for me then was just that I aborted “make” and restarted it <DoublePlusGood23>I have an ok server that runs ubuntu, would it be possible to use it as an offload server using docker? <wingo>civodul: i get 120 MB heap size when compiling python.scm to 'cps in the repl. <wingo>and 132 MB of dirty private memory <wingo>so i just don't get the numbers you have been getting <wingo>unless something serious changed in the package macro since may 1 <civodul>wingo: yeah i just saw your message and i'm wondering about time(1) too <civodul>that said, its figures may be too high, but we're eating too much memory nonetheless <wingo>but i don't understand the details, and the details are important <wingo>if we attribute the problem to the wrong thing early on, then we waste time <civodul>time(1) uses wait3(2) to determine resource usage <rekado_>DoublePlusGood23: you can use it as an offload server without Docker. <rekado_>DoublePlusGood23: Docker would just be an additional level of indirection. <DoublePlusGood23>rekado_: I guess I try doing that. I've just had guix be very buggy on my ubuntu desktop <rekado_>DoublePlusGood23: you can install Guix as a package manager on top of Ubuntu, and configure the machine for offloading. <rekado_>DoublePlusGood23: anything that you could report to bug-guix? <rekado_>they are not harmful and it can be tricky to understand in which environment the locales need to be available. <DoublePlusGood23>openssh seems to be supported for offloading now so that should make it easier than the last time I tried <wingo>hoo, compiling python.scm with all the optimizations takes forever :P <wingo>i bet it's slot allocation, as usual... <wingo>allocates 11GB total for a heap size of 740 MB <civodul>rekado_: you can update version-0.13.0 as you see fit BTW <rekado_>civodul: I’ll make my changes to NEWS tomorrow morning. I just ran out of time. <civodul>we're still missing the UEFI changes though <civodul>i think the only "risky" changes in master are the bootloader refactoring <paroneayea>if python.scm is already taking up so much memory <paroneayea>I am wondering what would happen if we really did have more npm based packages ported in <rekado_>BTW: my workstation in the office is currently building icedtea 7 with the new Java bootstrap. I think I’ll have a complete patch set ready by tomorrow. <paroneayea><civodul> wingo: it's GNU time, "guix package -i time" <paroneayea>"It's GNU time!" they said, hitting hopping into the phonebooth and returning as a superhero <civodul>python.scm is pathological because it's so big <civodul>but also it looks like we have a bug somewhere <civodul>which is not to say that providing a million npm packages would be trivial either ;-) <bavier>we have some 1TB systems at $dayjob and I always wondered what we'd use them for; now I know ;) <paroneayea>ACTION speaks in "royal we", not having time emselves ;)