IRC channel logs


back to list of logs

<GNUtoo-irssi>hi, I don't know yet what my issue was exactly, but following the manual for the binary installation worked.
<GNUtoo-irssi>That meant not using parabola's package
<GNUtoo-irssi>(no binary seem to be built for hello)
<lfam>GNUtoo-irssi: Hm, so the Parabola package didn't work? That's not optimal...
<OriansJ>Cross platform VM finally became turing complete. Thus far the VM is only 20KB, well under my 64KB budget.
<koz_>I'm trying to install Guix on Parabola. However, I can't seem to get the systemd guix-daemon service to fire. 'sudo systemctl start guix-daemon.service' basically fails to find 'guix-daemon'.
<koz_>It *is* located where the docs for Guix say it should be, but that doesn't seem to help.
<koz_>Moving it to /etc/systemd/system doesn't allow the call to work either.
<koz_>Am I missing something obvious?
<adfeno>koz_: What is the thing that you want to move to "/etc/systemd"
<adfeno>A text/configuration file?
<adfeno>koz_: Got it...
<adfeno>... Use: systemctl enable [Absolute path]
<adfeno>This is a design choice. See:
***Sornaensis is now known as SornaYomi
<OriansJ>Endianness correctness >.<
<OriansJ>The price I guess that will ultimately have to be paid
<OriansJ>Largely with my sanity
<adfeno>OriansJ: ?
<koz_>adfeno: Thanks! I got it going without using systemd in the end, but I'll remember that for next time.
<adfeno>koz_: You're welcome. :d
<adfeno>:D Actually... I just looked it up on the Internet...
<adfeno>... I'm no way a systemd user. But when it comes to me, I'll learn it and use it (I'm not against it).
<koz_>I don't really have major feelings either way about systemd - this is *literally* the first time it's given me trouble.
<adfeno>koz_: Just like everything in life: try to be patient with it... You might not make it today. But once you learn how to use it, you'll probably make it. :D
<koz_>adfeno: Yeah, I know.
<adfeno>And of course, take your time. Learn when you can, and don't rush yourself. If you have to use a replacement until you learn how to use the real thing, do so. But make sure to come back learning the real thing. :D
<koz_>adfeno: Is 'systemctl enable [Absolute path]' supposed to take ages and ages?
<koz_>And then time out?
<adfeno>Did it really output a "timeout message"?
<koz_>koz@Emi system ☛ sudo systemctl enable /usr/lib/systemd/system/guix-daemon.service
<koz_>Failed to execute operation: Connection timed out
<koz_>Unless I'm asking it to enable the wrong thing.
<adfeno>I don't know if this will change something....
<koz_>Should I try enabling just guix-daemon instead of guix-daemon.service?
<adfeno>... But can you try placing the .service file under "/etc/systemd/system/"?
<koz_>OK, that doesn't work.
<koz_>And then try enabling it from that new path?
<koz_>If I try that, it gives a 'file exists'.
<koz_>Huh, OK, *now* it starts fine...
<koz_>Never mind, I'm just insane apparently.
<Emacsite>ACTION gives koz_ a strawberry smoothie
<koz_>Emacsite: Aww, thanks! You even guessed my flavour of choice.
<koz_>Hopefully *now* I'll get Guix to work correctly - Parabola's build for it is borked.
<koz_>(hopefully I've now unborked it)
***Emacsite is now known as calher
<OriansJ>adfeno: I'm currently trying to reduce the bootstrap binary assumption down to 512 Bytes per platform and build a VM that will produce identicial results regardless of platform it is run on.
<OriansJ>adfeno: Added to the goal that the VM itself needs to be under 64KB in size and not have any dependencies besides a hex compiler
<adfeno>"Endian correctness" (whatever it really means, since I'm not a programmer) seems to be nasty.... :S
<OriansJ>lets just say, it is a pain to always make sure the bits and the bytes are always in the exact same order, esp since x86 and AMD64 do it backwards...
<OriansJ>But the good news is that aside from eliminating those hard to find ordering bugs and flushing out a bunch of instructions [only a couple lines of easy work usually], the VM is functional.
<OriansJ>And I have added a Opcode HEX Map for those who wish to write a assembler for the VM [Or port one], if not I'll probably implement that too.
<adfeno>Wow! :D
<adfeno>ACTION 's eyes roll around...
<OriansJ>adfeno: You can actually track my work on it here:
<adfeno>This is what I like on every free software project, there's some great people :D
<OriansJ>The best part, is 90% of the assembler could be achieved with a greedy regex engine, which could have the interesting side effect that assembly comments would be preserved after the source has been converted to Hex. It'll be more of a feat to achieve that in a C Compiler but imagine, user readible comments preserved and useful when C is converted to Assembly and Assembly is converted to Hex.
<koz_>I just tried to 'guix pull'. After a lot of work, I got this:
<koz_>unpacking '/gnu/store/ggmwgcmxzc9gzfvzp4lifyxwyvs0ba4h-guix-latest.tar.gz'...
<koz_>guix pull: error: failed to unpack source code
<civodul>Hello Guix!
<Sleep_Walker>I feel a bit stupid but what is default password for users or root? :)
<efraim>no default password for root, you have to log in as root and set a password for the users before they can log in
<Sleep_Walker>so when I have auto-login in slim, I just need to switch to console
<jluttine>how mature guixsd is atm? should i expect many things not to work? gnome support got just added so i'm a bit worried :)
<jluttine>is there a list of included software packages? i'd like to know if most of the apps i need are available or do i need to write my own configs(?) for them.
<kmicu>A. to the 2. question:
<jluttine>and how much (if at all) guixsd uses nixos as an upstream? is it totally separate or does the work done for nixos somehow help guixsd too? i'm just curious that how strong the basis is :)
<jluttine>kmicu: oh, thanks, how i missed that...
<kmicu>GuixSD is different from NixOS. Guix has some libstore internals pretty much the same as Nix, but nowadays we could consider them as separate projects. Only technical ideas are shared. There is also Triton (fork of Nixpkgs), but for now, it’s just a cleaner (e.g. Darwin removed :) version of Nixpkgs.
<jluttine>kmicu: ok. i find that a bit sad. for instance, with parabola it's great that there is this upstream arch community. i'm not convinced that there can be enough manpower in a pure libre os community alone but i'd like be proved wrong :)
<jluttine>perhaps i'll give guixsd a try and see what happens
<jluttine>list of packages was quite impressive!
<jluttine>found most of what i want :)
<jluttine>just icedove/thunderbird was missing. also, iceweasel is missing, but icecat exists
<civodul>jluttine: re GuixSD, see also
<Sleep_Walker>suspicious ownership or permission on `/gnu/store/0ppwqmh1zqp5vyhl1zmb6imbqcshr9ad-glibmm-2.48.1'; rejecting this build output
<Sleep_Walker>drwxrwxrwx 4 guixbuilder01 guixbuild 4096 30. kvě 11.16 /gnu/store/0ppwqmh1zqp5vyhl1zmb6imbqcshr9ad-glibmm-2.48.1/
<civodul>Sleep_Walker: yeah :-/
<civodul>i haven't found a good way to reproduce it
<civodul>it seems to be non-deterministic
<Sleep_Walker>I'll keep that in mind
<civodul>for the French speakers among us, i put together an introduction to Guix in "GNU/Linux Magazine France" this month:
<civodul>not available on-line yet, though
<civodul>i don't think you'd learn much ;-), but hopefully people will learn about the thing!
<efraim>I backed up the cve checker a bit and here's the output I got:
<civodul>efraim: interesting, so "just" a handful of additional vulnerabilities
<efraim>i'm amused by the two games on the list
<civodul>maybe the vulnerabilty allows one to forge a high score? ;-)
<efraim>and a2ps had one going back to 2001
<civodul>oh, so it hasn't seen any release since then?
<civodul>that sounds bad
<efraim> publish date was april 2014
<efraim>so I don't know how they got a 2001 cve for it
<efraim>CVE-2004-0149 for the game "you're so good at this game, we'll give you root access on this computer" ;p
<civodul>efraim: thanks also for updating the SF mirror list, BTW
<lumidragon>Hi all, are there any packages for handling cgroups and namespaces with regards to guix containers system/environment? I'm wondering if it would be possible to setup network interfaces for guix containers.
<civodul>lumidragon: there's no API for cgroups, but there's call-with-container, which takes care of namespaces
<civodul>that's what 'guix environment --container' uses
<civodul>'guix system container' uses that, too
<lumidragon>Is it possible to setup any network interfaces for either the system containers or the ones created with environment?
<civodul>there's no real support for that yet
<lumidragon>oh ok.
<civodul>maybe davexunit has ideas? :-)
<lumidragon>Was just thinking it would be nice to do all my development with guix.
<civodul>it surely is ;-)
<civodul>what did you have in mind wrt. network interfaces?
<lumidragon>when I do web dev, I usually run postgresql (or some dbms) in a container accesible by ip address. Then I run my my web container with environment variables telling it how to connect to that dbms.
<civodul>ah yes
<civodul>that's indeed a use case that was discussed previously, but there's no good answer yet
<lumidragon>I got rails to run on guix yesterday, still need to add the generated gem dependencies though, so the thought came to mind why not just go full guix. ^_^.
<civodul>obviously you could run pgsql in a 'guix environment --container --network', say
<civodul>and have a second environment for other parts of the software
<civodul>and have them talk to each other at
<civodul>dunno if that's an acceptable setting
<lumidragon>ah using the ports are the seperator.
<lumidragon>been a while since I thought about that.
<taylan>ACTION has quit work, is fully available for free software hacking for the next couple months, barring for laziness
<taylan>gotta dig up my todo
<lumidragon>the guixSD kernel does have cgroups and namespaces capability right?
<civodul>taylan: nice ;-)
<lumidragon>ok cool, guess I'll need to look at how to change my workflow/habbits.
<lumidragon>another question, is it a good idea to send multiple related packages in one patch, or is it better put each packages in an individual patch?
<rekado_>I just built rstudio server, but it bundles too much to be added now.
<rekado_>lumidragon: we usually require one patch per package.
<lumidragon>oh ok, cause was looking at my rails stuff. And it's a lot of packages.
<civodul>lumidragon: i think these packages will be very welcome!
<lumidragon>really kk, I didn't want to over do it. esp since I sent some go stuff recently. I'll try and send them bit by bit then.
<lumidragon>prb later today once I get some stuff out of the way and iron out the generated deps produced by 'rails new'.
<lumidragon>are there plans for an npm importer?
<OriansJ>lumidragon: The only plans are the tasks we have assigned ourselves. Thus unless someone has decided to do it, the answer would be no. However we always love it when other people pitch in and fill a hole we have missed.
<civodul>lumidragon: jlicht is a GSoC student who's started working on it, see
<lumidragon>OriansJ: ah I see, guess I would have to learn some more about guix internals and guile before look into that.
<lumidragon>civodul: thanks
<davexunit>darn, just as I was about to reply.
<davexunit>the syscall interface for making/manipulating network devices is... complicated.
<davexunit>I would *love* it if someone who had some prior knowledge would chip in so that guix containers could use virtualized network devices
<efraim>for the cpan mirrors, `guix build perl-uri -S --no-substitutes' fails because on our list of mirrors it got rotated out as "too old of a version"
<efraim> has all the old versions (as far as I can tell), but it fails to load gnutls with ERROR: In procedure module-lookup: Unbound variable: make-session
<efraim>nvm, I'm going to figure out this one
<efraim>note to self: the kids have a set of 6 rubber duckies, grab one and stick it next to the computer
<civodul>davexunit: we have some of it in (guix build syscalls), but maybe more is needed in this context?
<civodul>efraim: :-)
<davexunit>civodul: yeah, I don't remember details but I remember looking at what was there awhile ago and realizing it wasn't sufficient.
<davexunit>civodul: the pflask project has a pretty concise source file with what seems to be everything needed:
<davexunit>I don't quite understand it yet.
<OriansJ>raw0 = vm->memory[utmp1 + c->raw_Immediate];
<OriansJ>raw1 = vm->memory[utmp1 + c->raw_Immediate + 1];
<OriansJ>raw2 = vm->memory[utmp1 + c->raw_Immediate + 2];
<OriansJ>raw3 = vm->memory[utmp1 + c->raw_Immediate + 3];
<OriansJ>int32_t tmp = raw0*0x1000000 +
<OriansJ> raw1*0x10000 +
<OriansJ> raw2*0x100 +
<OriansJ> raw3;
<OriansJ>/* Sign extend Register */
<OriansJ>tmp = tmp << 32;
<OriansJ>tmp = tmp >> 32;
<davexunit>please use a paste site
<OriansJ>vm->reg[c->reg0] = tmp;
<OriansJ>davexunit: That was an accident, wrong buffer >.<
<davexunit>OriansJ: no worries!
<civodul>davexunit: we don't have everything it uses, in particular libnl bindings
<davexunit>civodul: yeah
<davexunit>libnl sounds familiar
<davexunit>I got kind of overwhelmed trying to figure it all out and put it on the back burner
<davexunit>ACTION sees that a patch of mine caused quite a discussion
<OriansJ>davexunit: Don't try to figure it all out, rather try to figure out a single small simple thing. Then another single small simple thing ... etc
<davexunit>OriansJ: sure, I got stuck whilst doing that. :)
<davexunit>that's how I implemented the rest of the container implementation
<civodul>davexunit: tl;dr: the outcome of the discussion is positive ;-)
<davexunit>1) have no idea what you're doing
<davexunit>2) figure it out
<davexunit>civodul: seems so. I'll get my patches cleaned up, pushed, and remove uncompressed-file-fetch.
<OriansJ>3) if 2) isn't working, try to make the problem smaller
<OriansJ>The first version of everything is Janky, don't fear Jankiness
<davexunit>I think my issue with networking was that it was hard to figure out what the starting point is and what were the minimal set of networking devices I needed.
<OriansJ>davexunit: The starting point is none, then you add exactly one and then you are done
<OriansJ>davexunit: Don't worry about performance or features, until you have made what is being done is correct.
<davexunit>OriansJ: thanks. I more or less know all of this.
<OriansJ>davexunit: Of course you do, but sometimes we forget this because we want to build something impressive.
<davexunit>civodul: did you envision one or two follow-up commits that change users of uncompressed-file-fetch back to url-fetch and then remove uncompressed-file-fetch?
<davexunit>I guess one commit will do it. didn't realize it was defined right in emacs.scm
<civodul>davexunit: one commit is fine, yes
<davexunit>ACTION sees people posting patches for AVR flashing tools
<davexunit>better dust off the avr-gcc patches and get those in
<efraim> lists aegis as being affected by CVE-2008-4938, but i'm pretty sure its because the patches applied don't name the CVE
<lfam>I'm trying to build the latest version of weex. It fails during configure with this: checking build system type... /gnu/store/b1yqjimbdh5bf9jnizd4h7yf110744j2-bash-4.3.42/bin/bash: ./config.guess: No such file or directory
<lfam>configure: error: cannot guess build type; you must specify one
<lfam>Do we have any examples of doing that?
<Guest82087>can i follow the archlinux wiki for the post-installation of guixSD? To know which packages to install.
<lfam>Guest82087: Can you provide a link to the page?
<lfam>Guest82087: That page seems to be about Arch Linux in general. Can you clarify your question?
<Guest82087>use this page to see step by step how to install my X server, video drivers, DM or WM, etc
<lfam>Guest82087: For those tasks, that page will probably only be helpful in a very tangential way, similar to how reading Linux From Scratch would be helpful.
<lfam>If you have a more specific question, you should search for it in our manual, ask here, or send your question to
<Guest82087>okay, i will first try to make guixSD booting : )
<lfam>When it comes to setting up a graphical environment, that page probably won't help at all
<lfam>Guest82087: I recommend reading section 7 of the manual (GNU Distribution), especially section 7.2 System Configuration
<lfam>Section 3 Package Management is also essential
<efraim>lfam: I see you found my CVE list
<lfam>efraim: Yes, I was planning to do the same thing ;)
<efraim>I only went as far as 2003
<lfam>I noticed you fixed a bug from 2001!
<efraim>I came across it while fixing the other one
<efraim>but that's what made me think of checking further back
<lfam>How far back does the database go?
<efraim>1999 I think
<efraim>thats as far back as goes
<efraim>I didn't check mitre itself
<efraim>aegis should be good, the patches don't mention the CVE numbers
<efraim>and I think jasper is fine, I tried applying a patch from debian but it conflicted with a whole bunch of other patches
<lfam>Jasper is a disaster. It's unmaintained for a very long time and all the distros have to maintain their own set of patches, which can be incompatible, as you've found
<efraim>ubuntu referenced "02_security.patch" which is only in some of the debian patch sets
<lfam>We should try to not add new references to jasper if we can help it
<efraim>i have devil and id3lib locally patched
<lfam>We should coordinate more. I just committed a patch for devil (CVE-2009-3994)
<lfam>At the very least we can compare work and confirm that the right thing has been done
<efraim>I can drop mine
<lfam>Did you use the same patch?
<efraim>haven't fetched it yet, currently building wordnet
<lfam>I'm trying to make sense of what to do with graphicsmagick:
<efraim>it makes sure ValLen can't be greater than 64?
<lfam>efraim: yes
<efraim>then yeah it should be the same
<lfam>It's interesting to see the differences between graphicsmagick and imagemagick. Imagemagick is basically not communicating at all. Even their source code repo doesn't include descriptive commit messages. Whereas graphicsmagick, which seems to be used much less, is working very publicly
<efraim>I think for iptables you could've mentioned the CVE if you wanted
<lfam>efraim: I don't think the bug (CVE-2012-2663)is fixed in that version of iptables.
<efraim> you're right
<lfam>It's just the last release from that series. The new series has new dependencies and I decided to put it on the back burner while checking if there was something more urgent.
<lfam>The discussion of that bug made me think it was partially mitigated by improvements to the kernel
<lfam>Based on this discussion:
<lfam>efraim: Have you read the first comment on this page?
<lfam>That person exploited the bug in question to break their twitter avatar
<lfam>The bug being discussed on that page, that is
<efraim>that's great
<lfam>And scary ;)
<Guest82087>++ everybody : )
<efraim>looks like 1988 was the first year or so, only breaking 200 in 1997
<lfam>I was unconcerned with software bugs in 1988 ;)
<lfam>More concerned with real bugs
<efraim>lfam: I finally tracked down the mcrypt patches
<efraim>CVE-2012-4426 was hard ti find
<lfam>Some of these bugs seem to have never been patched
<efraim>i saw that too
<phant0mas>davexunit: avr woohoo :-D
<davexunit>phant0mas: :)
<efraim>I'm adding some cpan mirrors that have some of the old perl modules, that should help with some of the "source is missing" errors
<suitsmeveryfine>Hi! I have a question regarding encrypted /home. Is it necessary to include, as I do currently, "(needed-for-boot? #t)" or could I leave that part out?
<suitsmeveryfine>My problem is that I have no working screen in GRUB only get one after I've entered the LUKS password. By encrypting just /home I had hoped to see something on the screen, but with my current configuration I don't.
<mark_weaver>lfam: I think we should assume for now that the libxml2 update is ABI compatible, and just push the update
<mark_weaver>I'm more worried about our systems getting hacked than I am about possible ABI incompatibility.
<mark_weaver>in the unlikely case that there's a problem, we have nice roll-back abilities for people to use
<mark_weaver>suitsmeveryfine: I'd be very surprised if (needed-for-boot? #t) is needed for /home.
<suitsmeveryfine>mark_weaver: what would happen if I just remove that part you think? Would I need to mount /home manually?
<mark_weaver>suitsmeveryfine: no, it should still be mounted automatically, but at a later stage
<suitsmeveryfine>I see. Well, OK I'll remove it and try. With the latest unstable version of libreboot I can see things in GNU screen if needed.
<suitsmeveryfine>thanks Mark
<mark_weaver>you're welcome!
<mark_weaver>ACTION cherry-picks the libxml2 update
<brainiarc7>Hey guys
<brainiarc7>Small question
<brainiarc7>How does one pick a specific version of a package when multiple versions are available?
<brainiarc7>Say, from clang-runtime-3.6.2 and clang-runtime-3.5.0
<mark_weaver>brainiarc7: from the command-line utilities like "guix package", say something like "clang@3.6"
<brainiarc7>Ah, thanks :-)
<brainiarc7>I tried using the dash separator and it failed :-0
<mark_weaver>from scheme code, e.g. the OS configuration or package recipes, refer to the scheme variable name
<mark_weaver>which is the identifier after 'define' or 'define-public'
<suitsmeveryfine>Oh, another quick question to you mark_weaver: with the new indendation rules for Emacs, is your workaround config no longer needed?
<suitsmeveryfine>guile scheme indentation I mean