IRC channel logs

<reepca>rekado: I think you have to run something after adding it to LD_LIBRARY_CONFIG, something with the linker... ldconfig I think?

<reepca>Question... if I have a directory containing my/packages/some-package.scm, and I pass that directory in with --load-path, should I be able to use whatever is in some-package.scm if I put (use-modules (my packages some-package)) in my /etc/config.scm?

<ng0>I think I should stick with what I have now... where Gentoo is just the blueprint for good examples and maintaining my few packages, and building gnurl.. and I fix up in Guix I need and want. it's the longer, more painful way but to encounter bugs twice is not productive.

<reepca>I'm currently trying to do what I described above, but am getting "no code for module (my packages some-package)".

<lfam>reepca: Yes, that's the idea. Make sure that some-package.scm exports the correct module path. I have to go now, but check out my repo for an example: https://github.com/lfam/guix/

<lfam>Good luck!

<plopito>plop, i can't run slim DM : /

<plopito>i installed xorg-server, my GPU driver, mesa, slim and openbox. And added 'slim-service' in the operation-system configuration file

<plopito>i have "Unbound-variable slim-service"

<ng0>can you upload your system config.scm to a pastebin?

<ng0>brb

<reepca>ah, never mind, the define-module was giving the wrong name... reading comprehension, man...

<lfam>reepca: I gave you the URL of the wrong repo earlier. This is the one I meant to link to: https://github.com/lfam/pkgs

<reepca>all good, I got it figured out anyway

<lfam>Great :)

<lfam>efraim: Did you check that the new jasper release fixes all those bugs?

<lfam>efraim: I just checked by looking for the CVE IDs in the jasper commit log. Looks pretty good :) And there are a few CVE patches you removed that aren't named in the jasper commit log, but whose changes were made upstream.

<lfam>Does anyone have any ideas about this Diffoscope test failure from core-updates? http://paste.lisp.org/+71Q2/1

<lfam>If you want to try reproducing that diffoscope test failure, you'll need these two patches on core-updates: http://paste.lisp.org/+71Q2/2

<lfam>I think something is wrong in the latest master -> core-updates merge

<lfam> http://paste.lisp.org/+71Q6

<lfam>mark_weaver: Are you able to build the latest core-updates branch, after your recent merge? (commit dcaf70897a0bad38a4638a2905aaa3c46b1f1402)

<lfam>Hm, it works when I replace dbus-1.10.12's package-source inheritance and just manually specify the patch

<lfam>I

<lfam>I'd like to push that change but I don't know how to title it.

<lfam>Oops, I mangled that paste. Here is the corrected version: http://paste.lisp.org/+71Q6/1

<enderby>hi, i just installed emacs using guix on a 'foreign distro' and i got version 24.5. is there a way to get emacs 25.1 as it says on https://www.gnu.org/software/guix/packages/ ?

<lfam>enderby: Have you run `guix pull` yet?

<enderby>lol, my bad. just remembered you telling me to do that last time. sry!

<lfam>Heh :) It's important, because it's how we make security updates available.

<lfam>Note that `guix pull` merely updates what is available to you. You would still have to run `guix package --upgrade` to actually update your packages to the latest

<enderby>ah

<enderby>alright will run that after

<lfam>If you are familiar with Debian / Ubuntu, `guix pull` is roughly analogous to `apt-get update`, and `guix package --upgrade` to `apt-get upgrade`

<enderby>ya, okies

<enderby>thank you again

<lfam>Any ideas about this internal compiler error building Vigra on i686-linux? https://hydra.gnu.org/build/1542038/nixlog/1/tail-reload

<Apteryx>Hi! I'm trying to install from the live USB image; after "guix system init /mnt/etc/config.scm /mnt", eventually it gets to a point where the message "Initializing operating system under '/mnt'" is printed, then I got: guix system: error: copy-file: ...

<Apteryx>I think it had to do with the filesystem being full. Indeed when looking at df -h, I have two filesystems listed as "unionfs" of 2.7 GB which are fully used.

<Apteryx>This machine has 4GB of RAM. Any idea? :)

<ng0>do you mount a harddrive at /mnt or do you mount the live usb at /mnt ?

<Apteryx>ng0: Rereading the installation manual, it does look like I forgot to mount the partition I created at /mnt. That would explain. Let's see if I can recover from this mistake.

<ng0>oftc is often worse than freenode with tor.. good thing we do not use oftc. both solve it too naive

<efraim>Also did you remember to start cow-store (or however that line goes)

<Apteryx>ng0: Now that I mounted my correct root partition (/dev/sda2) to /mnt, should I issue a "mv /gnu/store /mnt/gnu/store" ?

<Apteryx>I'm trying to recover from my silly mistake without having to reboot :)

<ng0>don't move the store

<Apteryx>OK. I'll retry from fresh tomorrow, as now guix system init seems to be confused.

<Apteryx>Good night!

<rekado>still waiting for my copyright assignment for Emacs to be processed… This is demotivating :(

<ng0>so i#ve just send a whois client because bind whois is so annoying and limited that I just had to

<civodul`>rekado: you should ping the copyright clerk

<civodul`>i forgot the address, but the explicitly said that people should do this

<civodul>but yeah, i can understand the frustration :-/

<efraim>oh, i tried 'guix-daemon --disable-chroot' on aarch64, I got the same (or similar) tar error I got trying to build bootstrap-tarballs for aarch on master, also on make-boot0

<efraim>/gnu/store/zfyqk0b6czgvdr2sr3snj7fas1p2h63x-bootstrap-binaries-0/bin/tar: Option --mtime: Treating date '@0' as 1970-01-01 00:00:00

<efraim>tar (child): xz: Cannot execmake-4.2/

<efraim>: No such file or directory

<efraim>tar (child): Error is not recoverable: exiting now

<efraim>starting phase `unpack'

<efraim>tar: This does not look like a tar archive

<efraim>xz: (stdin): File format not recognized

<efraim>tar: Child returned status 1

<efraim>tar: Error is not recoverable: exiting now

<civodul>efraim: did you follow the discussion with Carlos?

<efraim>nothing in /tmp/guix-build-make-boot0 after build -K

<efraim>some, I tried downgrading tar to 1.27 on master

<civodul> https://lists.gnu.org/archive/html/guix-devel/2016-10/msg00131.html

<civodul>and did it help?

<civodul>you should revive this thread to see what Carlos is up to

<civodul>the two solutions i proposed there should work, IIUC

<efraim>ok, i'll take another look at that

<efraim>thanks

<ng0>when I get no reply after a month or more on an old patch, and I've asked before and to their reply I offered to help, should I assume lack of interest and fix the old patch(es) up?

<civodul>ng0: never assume lack of interest; always assume overload :-)

<civodul>so if the patch is ready and marked as such, please send a reminder

<ng0>it's not even ready

<civodul>if it's a WIP patch, it's a different story

<ng0>the problem in the first place was wrong patch format

<ng0>I'm talking baout workrave

<ng0>sent in june

<civodul>but it's not ready you say?

<civodul>i'd suggest sending a patch that you think is ready to apply

<civodul>and then if nothing happens, ping people

<ng0>I've asked offlist to bring it to a format which is applicable, some messages went back and forth and so far no reply

<ng0>I've offered help on getting it ready though

<ng0>but it's been 3 weeks or 4 since the last reply

<ng0>so 'ping people' part is covered

<ng0>well not even 4 weeks

<ng0>more

<ng0> Date: Sun, 28 Aug 2016 01:14:29 -0500

<civodul>this one: https://lists.gnu.org/archive/html/guix-devel/2016-08/msg01779.html ?

<civodul>it's hard to do something of that message, honestly

<ng0>idk, I just have it as an email

<ng0>the more current thread happened off list

<civodul>what happens off-list is off-project too :-)

<ng0>it wasn't me.. jovany is no longer on the list or the first reply was without CC to the list

<civodul>well ok, so how do we move forward?

<ng0>I think I'll ask jovany about the current status (I was asked for helped, I offered help, nothing happened) and if nothing happens for another week (last reply was very quick), I'll assume I try to make workrave a git patch

<ng0>I have no self-interest in this but someone tried to contribute it, and there's some factor where it fails for them.. help offered, help not accepted somehow

<ng0>second choice:

<ng0>i have not looked at workrave too close.. if no one would use it, would there be a maintainer in here or would it just get old and dropped?

<ng0>it's in my 'wip' search because it was not finished

<ng0>i mean it sounds useful

<ng0>theoretically

<ng0>Workrave is a program that assists in the recovery and prevention of Repetitive Strain Injury (RSI). The program frequently alerts you to take micro-pauses, rest breaks and restricts you to your daily limit. http://www.workrave.org

<ng0>could possibly go into gnu/packages/health.scm and someone should http://health.gnu.org/ at some point then, could go into the same file. unrelated but somewhat related through health related issues

<ng0>*someone could package http://health.gnu.org/

<ng0>last time i looked at gnu health, no one had it packaged

<ng0>i mean no distros

<ng0>can someone comment on this http://lists.gnu.org/archive/html/guix-devel/2016-10/msg00145.html and the message afterwards? I don't see the format this comes in as problematic.

<efraim>that one was on my list to check and push, I've just been very slow with life and the holidays

<ng0>oh, ok :)

<ng0>I should check if we at the upstream side had new significant releases/commits and maybe push a new version of that patch series

<ng0>nothing merged into master at least.. so all still good.

<ng0>ftp of gnu does not like me

<ng0>i'm trying to find real download of gnu health, and not just the one they offer on their website..

<ng0>ah, it was jus tslow

<ng0>>.< bash setup

<ng0>interactive setup from first looks

<ng0>whyyyy

<ng0>I can see why no one packaged it so far..

<ng0>someone™ should offer help on something sane for a build system..

<ng0>if someone wants to clean up and help another GNU project: please do it for GNU Health

<ng0>this is horrible

<ng0>really

<ng0>not only clean up, get the message to them that a better build system would mean it's easier to package and deploy on other systems

<ng0>and can be packaged without re-inventing what they do

<civodul>on wrapping the compiler: https://gcc.gnu.org/ml/gcc/2016-10/msg00122.html

<civodul>davexunit, paroneayea: https://blog.wearewizards.io/how-to-use-nixops-in-a-team

<rekado>civodul: I already pinged the copyright clerk more than a week ago. No response. In total, a month has passed since my request for copyright assignment. I hardly even remember what I worked on.

<rekado>good thing Guix doesn’t do copyright assignments.

<rekado>ng0: if the original contributor is no longer interested, the patch is not ready, and you are not interested I’d suggest just dropping it. There are enough other patches that we can spend time on.

<ng0>rekado: true

<ng0>what if something uses ansible for installation... can we do that or do we have to rewrite the build system?

<ng0>*their

<ng0>wow. this looks so ansible stuck that they might have their reasons for recomending installation the way the handbook says

<lfam>Can anyone enlighten me? What does <>, as shown here, do? http://lists.gnu.org/archive/html/guix-devel/2016-10/msg00920.html

<ng0>when there's a psutils in a python's requirement.txt, is it psutils or is it some psutils which can be found on pypi?

<lfam>ng0: Usually those requirement.txt files only refer to things on pypi. And there is a psutil on pypi. But not a psutils

<ng0>I meant psutil. ok thanks

<ng0>trying to fix limnoria tests

<rekado>lfam: it’s a placeholder

<ng0>as far as i understand the test application we can even test irc servers with that

<rekado>(cut cons <> (list 1 2 3)) is a procedure that takes one argument and conses that onto a list '(1 2 3)

<rekado>it’s the same as (lambda (el) (cons el (list 1 2 3)))

<rekado>I like “cut” because it allows you to avoid this repetition of named arguments.

<lfam>Is (el) a well-known variable or procedure name? I don't see it in the Guile procedure index, which is where I usually look these things up.

<civodul>rekado: it was a deliberate choice to avoid copyright assignment for Guix...

<rekado>no, it's just a name for a variable

<rekado>civodul: yeah, and I'm glad that was done!

<lfam>rekado: Okay, thanks :)

<civodul>lfam: "surfee twenty-six": http://srfi.schemers.org/srfi-26/srfi-26.html

<civodul>:-)

<ng0>is this how you spell it, surfee?

<rekado>lfam: "cut" is useful especially in short anonymous functions where the intent is buried by the verbosity of (lambda (argument-name) ... argument-name ...)

<rekado>ng0: this is how you pronounce it :)

<ng0>pronounce

<ng0>sorry

<rekado>I only learned this pronunciation last FOSDEM.

<lfam>Thanks for the insider tip ;)

<lfam>By the way, am I the only person who can't build core-updates since the latest merge?

<civodul>it's one of these tricks that masters devised to distinguished insiders from newcomers

<civodul>lfam: what is it that you can't build?

<lfam>I can't `make` Guix itself. I even did `make clean-go`

<lfam>It specifically complains about how the grafted dbus inherits the package-source of the ungrafted dbus.

<civodul>oh

<civodul>ACTION checks

<lfam>I sent a patch to the list undoing that source inheritance, instead using (patches) to get the same effect

<ng0>I need a short synopsis for this already shortened extract of the description: "Library for retrieving information on running processes and system utilization" this is currently too long

<civodul>lfam: works for me, though i didn't try "make clean-go"

<lfam>Okay, I'll try some more things

<civodul>bavier: oh, the "stray .go file" warning mentions test-tmp/.../*.go, which is no good

<lfam>ng0: Is it for python psutil? The current python-psutil uses "Library for retrieving information on running processes"

<ng0>the current? we already have that?

<ng0>oh

<ng0>i searched psutils, that was my problem i think

<lfam>Isn't it nice when there's already a package? ;) Almost as nice as when we *don't* have a package for something on oss-sec

<civodul>heheh

<ng0>the search function should.. well I can imagine psutils also including psutil.. and to list a status on installed in profile

<ng0>thanks :)

<civodul>ng0: Freenode can be accessed over Tor again now?

<ng0>they solve it as naive as oftc

<ng0>but yes, it can

<ng0>I'd almost say hackint would be better if one were to use irc and wants to have a relatively okay solution for tor

<civodul>cool

<ng0>their approach is better.. I don't know how well they handle ddos..

<ng0>oftc almost never has an open line for tor (I've tried so often I just join without tor now there .. funny when tor itself has the irc channel there), and freenode requires to have an account before connecting via tor. and hackint has two "lanes" for tor: one for identified users and one for those who do not wish to sign up, get two different hostnames so channels can handle bans smarter

<lfam>Oh, I see that Mark committed a fix for that Guix build issue I mentioned :) http://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates&id=c9a71c6fdab6914dd648b76c349c3af9018cad35

<ng0>the test application should have a test itself

<ng0>"succeeded" .. okay

<ng0> https://github.com/ProgVal/Limnoria/blob/master/setup.py#L251 oh.. hm. well, we'll see when the first people start using limnoria through guix

<csanchezdll>guix build: error: build failed: build of `/gnu/store/v6qk5a6y8vlbd6ail37b213dk822af2y-libarchive-3.2.1.drv' failed

<csanchezdll>with current master, checks fail on my system

<csanchezdll>for libarchive :S

<csanchezdll>probably missing lz4 input

<csanchezdll>does it fail for someone else?

<ng0>A package definition, no matter how naive written, should not trigger a stack overflow.. should I report this as a bug?

<ng0>something I work on I mean

<rekado>ng0: you'll always get a stack overflow when circular dependencies are involved.

<ng0>ok

<ng0>that could explain it

<rekado>that's a side-effect of packages as part of a library.

<lfam>csanchezdll: It builds for me on x86_64. The lz4 test is skipped. Can you share more details about the failure?

<ng0>rekado: is this safe? as far as I know from gentoo hardened stack overflows are always bad

<rekado>not a problem.

<rekado>you wouldn't deploy Guix with a defect like this.

<ng0>because it fails when this is in the definition... right

<ng0>so no way to escalate, trampoline, whatever

<csanchezdll>lfam: lz4 test not skipped here... this rings some bell from the past

<rekado>this is not like an overflowing C array or anything

<ng0>ok :)

<lfam>csanchezdll: What Git commit are you using, and what command causes the failure?

<lfam>Also, what architecture are you using?

<csanchezdll>commit 1dc30f92320c5e1b528a7eec2b0a4ce529f70c56

<csanchezdll> ./pre-inst-env guix build libarchive

<lfam>csanchezdll: Can you copy and paste the full output of that command onto paste.lisp.org?

<csanchezdll>lfam: now I remember

<csanchezdll>I saw this in the past

<csanchezdll>the problem is how the test catches the error due to not finding lz4 program

<ng0>hm... a test for this seems a bit overkill

<ng0>i mean for limnoria/irctest

<csanchezdll>posix allows different behaviours here... test_option_lz4.c catches two (common) error messages when lz4 is not found, but in my case it gives an error different from ""Can't launch" or "Can't write"

<csanchezdll>so instead of skipping (as it should) reports a failure

<lfam>Sounds like an upstream bug, right?

<csanchezdll>yup, it is

<lfam>I'm testing the build on i686 now

<lfam>Hydra does have a substitute for i686

<lfam>I hope you will report it upstream. They are pretty responsive to bug reports from what I've seen

<sneek>I'll keep that in mind.

<lfam>sneek: botsnack. Go away :)

<sneek>:)

<csanchezdll>I think I already did, I step on this like 3 weeks ago, and then I forgot till yesterday when I hit again

<ng0>rekado: do you have an idea how to solve it? the tests are not part of limnoria, but there are tests in irctest for limnoria (I have no idea what the "test" folder in limnoria itself does.

<csanchezdll>but I will recheck

<csanchezdll>it is possible I got distracted and did not send the bug report

<civodul>lfam: now i know why i never got that syntax error in glib.scm :-)

<civodul>howdy csanchezdll!

<civodul>csanchezdll: efraim is working on an aarch64 port and was wondering about the tar issue that you also had

<civodul>did you manage to work around it?

<lfam>csanchezdll: Searching for lz4 on the libarchive bug tracker returns many results, but none in the timeframe you mentioned. Please report it :)

<lfam>BTW, cross-building from x86_64 to i686, the test is properly skipped for me

<lfam>And, should we add lz4 to the inputs of our libarchive package?

<csanchezdll>civodul: yup, bootstraping powerpc is progressing. tar issue is solved, now the problem is the findutils test fail I mentioned last week

<csanchezdll>which is caused due to a known gcc bug with glibc-2.21+ in powerpc

<csanchezdll>so I have moved to gcc-4.9.4 locally

<rekado>sneek What are I hope you will report it upstream. They

<sneek>I've heard I hope you will report it upstream. They is pretty responsive to bug reports from what I've seen

<rekado>sneek forget What are I hope you will report it upstream. They

<sneek>Last time I checked I hope you will report it upstream. They is pretty responsive to bug reports from what I've seen

<csanchezdll>I have to prepare a patch with tar stuff, just my real job getting in the way lately ;)

<lfam>Looks like the latest libarchive release will not work our version of lz4, but they have updated their lz4 interface in their development repo. So, when they release 3.22, we can try adding lz4

<rekado>sneek forget I hope you will report it upstream. They

<sneek>Okay.

<rekado>sneek: botsnack

<sneek>:)

<csanchezdll>lfam: right, I will report then, thanks :)

<lfam>How strange!

<lfam>csanchezdll: It's probably not necessary unless the error persists after the 3.22 release :)

<csanchezdll>well, it is an upstream bug anyways, now all the research I did back then comes to my mind

<csanchezdll>so no harm on letting them know

<lfam>Okay, that makes sense

<davexunit> http://rhelblog.redhat.com/2016/10/17/secure-your-containers-with-this-one-weird-trick/

<civodul>csanchezdll: thanks for the update; maybe you could post the tar patch that you have so efraim can use it as well?

<rekado>I’m trying to build GCC 4.3 (for GNU Pascal –> to bootstrap Freepascal –> for Hedgewars), but I’m getting an error:

<rekado>The directory that should contain system headers does not exist: /usr/include

<rekado>I see that this message exists in the latest GCC sources as well

<rekado>but building the latest GCC works fine.

<civodul>the "--with-native-system-header-dir=" configure flag does that

<civodul>but maybe it had a different name or didn't exist back then

<rekado>ok, thanks. I’ll take a look

<rekado>looks like it was called “--with-sysroot” before

<civodul>ISTR it's broader in scope, but maybe that's ok

<ng0>so I have python-repoze-lru and python-routes in a branch I want to delete.. I'm not sure if this was in another patchset (kallithea?) I've done before, those are very common

<ng0>yep, those were in the kallithea patches

<ng0>*are

<efraim>civodul: csanchezdll: I i grabbed the tar patch that Danny Milosavljevic proposed on the 'Bootstrap tar cannot exec xz' mail thread, its building out to bootstrap-binaries atm x86_64 -> aarch64

<jmd>Any fundamental reason why we shouldn't package lxc ?

<davexunit>no one has rejected such a package

<csanchezdll>efraim: building bootstrap-binaries did not require any patch for me

<csanchezdll>the problem was when using the boostrap tar in the target machine (ppc)

<csanchezdll>so the patch *affects* the bootstrap binaries build, but is not required for it to succeed

<csanchezdll>I am doing some rebase & cleanup to post my patch on the list

<quigonjinn>where should http://www.signal11.us/oss/hidapi/ package go in guix? in its own file?

<efraim>csanchezdll: about the same here, the tarballs on aarch64 wouldn't tar and untar correctly

<efraim>I had a different patch for isl since the release tarball was pre-aarch64 I had to add it to config.guess

<csanchezdll>cd ..

<csanchezdll>heh wrong windoe :D

<civodul>csanchezdll: BTW, does your work relate to https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workstation ?

<civodul>it looks like a promising platform

<csanchezdll>civodul: nothing that fancy, i am afraid. I just like guix and want to make it work on my old ibook g4

<civodul>that's fun too ;-)

<civodul>i had GNU/Linux on a G4 box 8-10 years ago

<csanchezdll>but yup, that board looks nice. Price tag won't be so nice I guess

<csanchezdll>I like making old machines work, kind of helps keeping my debugging skills honed ;)

<jmd>If I declare a service in /etc/config.scm and that service depends on some package, do I have to also declare that package? or will it be implicitly installed?

<civodul>jmd: the service should Just Work

<davexunit>services refer directly to things in the store, so it doesn't depend on the global profile at all

<efraim>What was the command to just build the static-binarires?

<civodul>guix build static-binaries-tarball?

<efraim>I'll try that one,

<efraim>as long as its shorter than bootstrap-binaries :)

<Apteryx>Does guix supports being installed on a LUKS encrypted partition?

<civodul>Apteryx: almost but not quite: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21843

<Apteryx>civodul: OK! Thanks :)

<civodul>davexunit: 'guix container exec' tries to setns(2) all the target namespaces, but that fails when the given process shares one of them with the host (as with "guix environment -C -N")

<Petter>Apteryx: I'm running GuixSD on a fully encrypted system, using Libreboot as boot firmware.

<davexunit>civodul: yeah, that's a bummer.

<davexunit>I haven't used that program in quite some time.

<davexunit>so it's surely full of bugs.

<davexunit>I was hoping that, since containers are the new cool thing, that some more people would have jumped in to help by now.

<davexunit>but alas...

<civodul>davexunit: i found it: 'container-excursion' was comparing namespaces by file descriptors (so comparison was always false) where it should compare the /proc/ns/XXX symlink target instead

<civodul>i'll push a fix later

<davexunit>civodul: oh great. thanks for finding that!

<civodul>yw!

<Apteryx>Petter: Cool! Was it difficult to setup?

<Petter>Apteryx: It wasn't supported when I installed, so it was pretty difficult yes :P But I got a lot of help, and the problems I faced have been fixed in Guix, so installation on similar systems should be pretty smooth sailing now : )

<Petter>Apteryx: As far as I understand though, the need boot firmware needs to have GRUB embedded, with the crypto modules loaded.

<Apteryx>OK! Good to know things are shaping up for encrypted root.

<csanchezdll>civodul, efraim: patch sent, quite simple after collapsing several wip commits into the final form

<civodul>tx!

<csanchezdll>efraim: you will most probably jump into another problem as bash build cannot detect whether getcwd correctly allocates memory or not

<csanchezdll>when cross-compiling

<csanchezdll>because it requires running compiled code

<csanchezdll>a small patch fixes it, I am sending it as well

<Apteryx>I'm trying the standard installation on a plain ext4 partition, and grub-install complains: Filesystem ext2 doesn't support embedding.

<Apteryx>Maybe the device I should give in the config.scm file should be /dev/sda instead /dev/sda2 ?

<Apteryx>*instead of

<Apteryx>(answering my own question): That was it. Using ext4, it seems embedding grub into a partition causes a warning and is not endorsed by Guix, so the device in the config.scm file should be /dev/sda instead of /dev/sdaX

<Apteryx>After changing from /dev/sda2 to /dev/sda, the guix system init completed!

<MinceR>hi

<MinceR>is it safe to ^C an ongoing installation?

<civodul>MinceR: yes!

<civodul>it's all transactional, you're safe ;-)

<MinceR>thanks

<civodul>csanchezdll: you can give ./configure the answer to the test by passing it "ac_cv_XXX=yes"

<civodul>instead of actually patching it

<ng0>cool. guile-1.8 just compiled without issues on a hardened uclibc-ng system

<ng0>hope new guile behaves the same

<ng0>could os-prober be useful for us to detect other systems, multiboot, later on?

<ng0>or isit easier to do this in completely in guile

<Apteryx>If I'm using the lightweight desktop (currently ratpoison), what is the way to configure the keyboard layout? Some xorg file?

<ng0>i use setxkb

<ng0>but i don't knowofother tools

<Apteryx>OK!

<ng0>eh

<ng0>setxkbmap

<ng0>that's what I meant

<Apteryx>Yeah, I figured you meant that :)

<Apteryx>Hmm, I guess this is a bit too barebone for my wife... Coming from Ubuntu she will be in shock.

<Apteryx>:D

<ng0>well you can 'setxkbmap neo2 &' in a script which automatically runs at start

<ng0>but i don't know ratpoison, tried it at some point in the last 17 years and did not like it

<Apteryx>What is your DE/WM right now?

<ng0>awesome

<Apteryx>ng0: OK!

<lfam>Tor users: Debian just published a security update for TOr

<ng0>yeah tor called for hack on tor-unstable week

<ng0>seems to work out :)

<lfam>It seems to affect several versions of Tor. 0.2.5.12, 0.2.8.9, 0.2.9.4

<ng0>have you pushed the patch?

<lfam>No, I haven't looked at it at all. I just saw the email from Debian

<ng0>ah, ok

<ng0>do you have a linkfor it?

<ng0>or is it on tor-devel already?

<ng0>oh

<ng0>new torsocks released

<ng0>I need to setup a system.. any takers on 2.2.0 torsocks?

<ng0>i hope they fixed the bug i had.. if not i'd say trac is bad for keeping trac(k) of things

<ng0>things are compiling... I can update torsocks myself :)

<ng0>weird how it still lives in the people.torproject.org subdomain, but that's an official announcement email

<jmd>Something is buggy with the way things are logged to /var/log/secure

<lfam>efraim already did the Tor update. Awesome!

<ng0>ah, this update you mean

<ng0>i searched for a fix after the release

<lfam>0.2.8.9, released yesterday

<ng0>i've seen that.. yes :)

<ng0>i'll send the torsocks update soon

<ng0>it's building

<efraim>Yeah I get the tor release emails

<ng0>should i mention the chnage of source from git to file fetch?

<ng0>probably yes

<ng0>if i have to ask

<ng0>done

<ng0>well my bugs are still unchanged in trac... so I hope it's just ignored and fixed in the source

<rekado>ACTION just finished compiling GCC 4.3.6, then realised GCC 4.5.1 is actually needed

<rekado>not sure how I got to 4.3.6 in the first place.

<rekado>luckily they are very similar.

<rekado>if this works I’ll rebuild with the GPC patches from here: https://github.com/hebisch/gpc/tree/4.5.1

<rekado>and then we’ll see if this can be used to compile an early version of fpc (the Freepascal compiler)

<reepca>rekado: did you ever get swrast to work?

<rekado>reepca: it worked but supertuxkart still told me that opengl 3.1 is not supported.

<rekado>I could load the libs and I saw that everything was slower than before, but I wasn’t able to cheat supertuxkart to think I had an opengl 3.1 card.

<reepca>did glxinfo say it claimed 3.1+?

<rekado>reepca: no, it says “OpenGL version string: 2.1 Mesa 11.0.9”

<rekado>and it also says “OpenGL renderer string: Software Rasterizer” when loading the custom mesa libs

<rekado>I built mesa with "--with-gallium-drivers=i915", "--enable-gallium-llvm", and "--with-dri-drivers=swrast"

<rekado>but maybe I’m doing this wrong

<reepca>might require a newer mesa, based on this https://mesamatrix.net/ swrast doesn't get all of the 3.0 stuff until May 19, 2016. Based on the news here http://mesa3d.org/ 11.0.9 was released January 22, 2016.

<rekado>ha, funnily just using the regular mesa works when I start supertuxkart with LIBGL_ALWAYS_SOFTWARE=1

<rekado>how odd

<rekado>now it says: OpenGL version: 3.3

<rekado>OpenGL vendor: VMware, Inc.

<rekado>OpenGL renderer: Gallium 0.4 on softpipe

<rekado>softpipe probably means: slow (no llvm?)

<reepca>well according to http://www.mesa3d.org/llvmpipe.html llvmpipe is the fastest, so I guess softpipe must be slower

<rekado>I’ll try building mesa again then, this time without the configure flags I provided before but with llvm.

<rekado>(why does our default mesa package not come with llvm support?)

<mekeor>(how) can i install guixSD with non-free drivers?

<mekeor>i know, it's a common question...

<reepca>You'd have to package them yourself or find someone willing to / who has. See the manual if you want information on how to package stuff.

<mekeor>reepca: ah, i see.

<reepca>now wait, are we talking about userspace or kernel modules?

<mekeor>i think both.

<reepca>Is it a graphics card thing that isn't working?

<reepca>Or wifi?

<mekeor>i think both.

<reepca>Is it an NVIDIA graphics card?

<mekeor>yes. i need iwlwifi for wifi. and i have an NVIDIA graphics card.

<reepca>Out of curiosity, how new of an NVIDIA graphics card is it? That part might be able to be covered by the reverse-engineering efforts of Nouveau (although I don't remember whether the firmware in that is free or not)

<reepca>(And it's usually the more difficult part to replace)

<mekeor>NVIDIA Corporation GM107M [GeForce GTX 860M]

<reepca>Anyway, if you're really set on iwlwifi, I'd look at the .deb package, see what it does, where it gets stuff from, where it puts stuff, and try to replicate it with a guix package definition. See gnu/packages/firmware.scm for an example

<reepca>(that's assuming your current directory is the git repository of guix)

<mekeor>cool!

<mekeor>that'd be so super awesome!

<civodul>i'd instead recommend options that respect your freedom!

<civodul>see https://www.gnu.org/software/guix/manual/html_node/Hardware-Considerations.html

<mekeor>hmm. actually, i'm not even sure whether i'm using the nvidia card right now. because my laptop has two graphic cards.

<civodul>ACTION uses an ath9k wifi dongle

<davexunit>I use an nvidia graphics card with GuixSD, FWIW

<davexunit>and it works with nouveau

<davexunit>though I think our current nouveau build may have some issues regarding 3D acceleration

<mekeor>civodul: are you suggesting to look for another, free-software-compatible laptop?

<civodul>mekeor: that or simply an Atheros-based wifi dongle

<reepca>mekeor: I think the simpler solution would be to leave the wifi that comes with it alone and just use a little usb adapter

<civodul>it's cheap, easy, and non-intrusive

<reepca>anyway, you're in luck, the NV110 family (which your GTX 860M is part of) is supported! https://nouveau.freedesktop.org/wiki/CodeNames/#NV110

<mekeor>holy moly! YEAY :D

<reepca>although as you can see here https://nouveau.freedesktop.org/wiki/FeatureMatrix/ some features are still in progres, so don't expect too great of performance

<reepca>s/progres/progress

<mekeor>i don't need much

<mekeor>lspci -v | grep -i kernel > http://lpaste.net/7350167427033858048 # are there any other non-free kernel drivers i need?

<davexunit>ooh, looks like the new AMD GPUs have good free software driver support

<mekeor>hmm. also, the RealTek RTL-8169 Gigabit Ethernet driver ("r8169") is non-free

<mekeor>so i guess, i won't be able to access internet directly after installing guix sd

<reepca>Unless you swap out your wifi card for something else or get a usb one

<rekado>why are we using GCC 4.8 as the bootstrap GCC binary?

<rekado>why this particular version?

<rekado>it’s the first version that depends on a C++ compiler

<rekado>could we use 4.7 instead and then try to build that with a simpler compiler?

<civodul>rekado: i guess we could

<civodul>or we could use tinycc, build gcc 4.7, etc.

<ng0>tinycc?

<civodul>but we have to start somewhere, i think it makes sense to try out something in that direction

<ng0>i geuss i have to read the backlog

<civodul>janneke: speaking of which, it'd be great if you could give a talk about Mes at FOSDEM :-)

<ng0>i really hope I can afford fosdem.. i'd like to talk, but it's also very close to my travel to graz

<rekado>right, I was thinking of tinycc

<rekado>(although we’d have to use a different version with arm and mips support.)

<civodul>yeah

<rekado>maybe this would push us to add some more abstractions for cross-compilation

<rekado>bootstrapping other platforms from x86 :-/

<civodul>heh

<civodul>as to why 4.8, see 062134985802d85066418f6ee2f327122166a567

<civodul>i think i just found it "easier" to bootstrap from it, because of C++

<efraim>i figured it was because that was what was out then

<ng0>i hope we can go towards multiple libcs when i have finished uclibc-ng :) sorry, i'm multitasking and have to guess context x.x

<janneke>civodul: Mes...that would be nice. I added a REPL this weekend, let-syntax and thus match :-)

<civodul>fun :-)

<efraim>according to wiki.debian.org/Arm64Port , apparently aarch64 support was mostly there in gcc-4.7, with 4.9 having full support

<civodul>ok

<ng0>not related, http://uclibc-ng.org/wiki/matrix uclibc-ng supports more platforms than glibc but you can always exchange them (unlike musl) :)

<jonsger>ng0: you want guix on avr32 :P

<Digit>amidst doing mpv on a yt search merly for "libreplanet", got Dave Thompson & Christopher Webber's 2016 talk, on solving the deployment crisis. ace talk. v happy it's shown up in the top searches. would love to see feature parity between gui and command line, and have the gui express the command line equivalents of whatever's done in the gui, to keep the users aprised, and keep the emacsness, expediting newbies to empowered

<Digit>colaborators.

<efraim>In execvp of tar: No such file or directory

<efraim>should I be stracing the daemon and not guix build?

<efraim>ACTION goes to bed, will think about it tomorrow

IRC channel logs

2016-10-18.log