IRC channel logs

2016-01-13.log

back to list of logs

<stormysea>hi, I am trying to learn about the possibility of running GUIX/GNU/Hurd on a system I wish to purchase. Where can I learn about this? All I have been able to find about about running GUIX on GNU/Hurd is that there is a "proof of concept."
<Digit>:) good question. *watches this space*
<francis7>mark_weaver, if you notice regressions on newer kernels in Guix, could you always try to bisect them and submit a bug report to kernel.org?
<francis7>This is important for libreboot systems, since we don't always catch bugs in time before a new kernel release
<mark_weaver>francis7: I'm sorry, but the regressions I'm seeing now don't reveal themselves until a fairly long and unpredictable amount of time after booting, and I have only one working Libreboot machine at the moment, which is my primary development machine.
<mark_weaver>even if I had time to add another significant job to my plate, which I don't, it wouldn't be practical for me to do this.
<mark_weaver>however, what I have done is to switch back to linux-libre-4.1.15 for now on my X60, and I'll report whether it seems to have the video playback problem or not.
<mark_weaver>as for the epoch fail problem, I've never seen that happen. but then, my X200 is not functional at the moment.
<mark_weaver>I've never seen it happen on my Libreboot X60 though.
<francis7>this doesn't sound like a problem that can be fixed in coreboot
<mark_weaver>(I never saw it happen on my Libreboot X200, but it've been a month or two since I was able to use it)
<francis7>it sounds like a linux bug (epoch failure)
<francis7>so this won't prevent a release
<francis7>the video issue on your X60 too, is most likely kernel related
<mark_weaver>agreed, almost certainly
<francis7>(we've had a lot of issues kernel-side for x60 especially, when it comes to video. I count at least 3-4 regressions we've had to get fixed upstream)
<vaeringjar>doing a new install
<vaeringjar>vlc seems like the heaviest package I have
***francis7 is now known as francis
***francis is now known as fchmmr
***fchmmr is now known as emacsuser
***emacsuser is now known as vimuser
***vimuser is now known as francis7
***francis7 is now known as gnuuser
***gnuuser is now known as francis7
<civodul>Hello Guix!
<efraim>hi!
<NiAsterisk>I have something more pressing than gnunet-gtk after starting with a book from the 80s.. but i don't know much about licenses. interlisp wasn't free, but is this interpreter free in the sense I could not only package it localy but also upload a patch for guix? https://github.com/blakemcbride/LISPF4
<rekado>NiAsterisk: the LICENSE.txt contains the text of the FreeBSD license: https://www.gnu.org/licenses/license-list.html#FreeBSD
<NiAsterisk>ah :) I'm not good at spotting BSD licenses
<NiAsterisk>thanks
<rekado>np!
<rekado>NiAsterisk: didn't you get quite far packaging gnunet-gtk?
<rekado>I'd like to play with it and if you don't mind I could try to finish what you've started.
<NiAsterisk>almost done.. I'm stuck debugging, but more stuck with a list of things I need to organize to get more room for packaging.
<NiAsterisk>yes, go ahead :) if somebody has their time schedule not so full as mine currently, i'd like to see gnunet-gtk out there. I'll send the latest versions I had later today to the dev list
<NiAsterisk>i'm new to this pcakage system, and while it was easy on gentoo to package for me, guix and debugging gnunet-gtk makes it a bit more difficult while I still learn about guix and what's available and not etc
<rekado>re time management: I'm trying to follow a variant of "Getting Things Done" built around org-mode.
<mark_weaver>hmm, my polkitd is using 195% CPU for quite a while now, keeping my X60 warm.
<mark_weaver>I wonder what's up with that
<rekado>NiAsterisk: it's essentially: write everything down, determine next immediate step, review list once a week.
<NiAsterisk>rekado: i found that too last week
<NiAsterisk>and now I'm trying to apply it in some way which fits my current vast amount of time and too much things I'm working on.
<rekado>I have yet to make it work for email. There's org-capture, but I haven't quite reached a point where it's convenient.
<rekado>I'm not following it religiously, but at least I can keep track of the very next step I need to do for each of the many things that are WIP.
<NiAsterisk>i'm not so convinced that emacs is okay for me for planing.. despite my dislike for "clouds", I do take lots of notes when I'm on the road or need to look up things.. I don't want to use papers, so I am using a proprietary websolution for now until I can try out open solutions on my own servers.
<NiAsterisk>and I want to combine email + projects in a workflow at some point, so I guess some combination of software on laptop + papers for things on the go are better.
<NiAsterisk>tbh org-mode planing looked to difficult to apply for me at the moment. It might work, but i need something which is easy accessible first, because for years I tried to get into planing and organizing and all concepts I tried failed.
<rekado>I usually have my laptop with me. When I don't I have a little notepad to quickly jot down things that I add to my org file once I'm home.
<rekado>(if the proprietary solution is trello: there is an Emacs package to sync trello to org-mode)
<rekado>org-mode has a *lot* of features and I'm probably using less than half a percent to organise stuff and keep track of projects.
<civodul>sneek: later tell alezost the top of the package-info buffers has changed from a large-font title with the package name to a small (and IMO useless) link; would be nice to revert maybe?
<sneek>Got it.
<NiAsterisk>no, it's todoist what I currently use.. but I found some open self-hosting solutions. so what I need to figure out are priorities mostly.. like, get sports + packaging + learning coding languages + learning/refreshing spoken languages + writing etc etc into an schedule which doesn't break me after a while.
<rekado>(for learning/refreshing natural languages I suggest the Assimil book series; they are really good and somewhat unusual in their approach)
<rekado>(setting priorities never worked for me; I just make sure to have *something* with me on the commute, either laptop or books. This approach doesn't work too well with sports, though.)
<NiAsterisk>(hm. thanks, I'll take a look at the books. so far I tried to avoid closed source applications. traveling to (france,spain,uk/us) and the countries where I want to learn an entire new language would be the easier fix, but travelling costs money.)
<fhmgufs>Hello, have you done an upgrade to dmd (shepherd?)? It has sucessfully built now on ARM.
<fhmgufs>Or is this distribution specific? I tested it with debian 8 before and now on Arch Linux ARM.
<fhmgufs>When I tried to build it the last time the test respawn.sh failed.
<civodul>fhmgufs: the failure was non-deterministic, it has been fixed upstream but not in Guix
<civodul> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22130
<civodul>so i guess you've just been lucky this time ;-)
<fhmgufs>Do you know what's the reason for that bug?
<fhmgufs>civodul: Oh, i didn't read your last line. So, when is that going to be fixed in guix?
<fhmgufs>Or, maybe, how long does it take until shepherd will be released?
<civodul>hopefully "not too long"!
<civodul>i'd like to do that before FOSDEM
<civodul>we'll see
<paron_remote>huh
<paron_remote>hmmm
<paron_remote>debian and guixsd store state stuff in fairly different places
<paron_remote>I wonder if I am playing with fire if they both use the same /gnu/store :)
<paron_remote>er, guix on debian and guixsd
<paron_remote>or at least iirc they do
<paron_remote>oh wait!
<paron_remote>my setup doesn't use the same /gnu/store
<paron_remote>I'm safe! :)
<civodul>application state usually goes to /var/run or /run
<civodul>or did you mean something else?
<paron_remote>civodul: right..
<paron_remote>I guess I'd better set it up to use a different profile
<paron_remote>that's probably more critical
<paron_remote>otherwise *who knows* what it'll point to :)
<paron_remote>ACTION has a shared home pratition between debian and guix
<civodul>the shared home should be fine
<paron_remote>civodul: but what about shared .guix-profile :)
<paron_remote>I think it'll be fine as long as I'm careful to have different profiles
<civodul>ah ha!
<civodul>the shared .guix-profile can only work if the underlying store is also shared
<civodul>otherwise it might work dependending on the phase of the moon
<civodul>but that's usually not a sufficient level of assurance ;-)
<paron_remote>GUIX_PROFILE="$HOME/.debian-guix-profile"
<paron_remote>how about that? :)
<civodul>should work, indeed :-)
<amz31>paron_remote: how do you deal with dual booting debian and guix?
<paron_remote>amz31: I have them on separate partitions, and have an encrypted /home/, which is mounted on both
<paron_remote>and I have each write out their own grub to their own root partition, and have the root grub load each distro's grub.cfg
<paron_remote>might be worth blogging about
<paron_remote>it took me a bit to figure out
<civodul>that would be interesting
<amz31>+1
<paron_remote>ACTION not sure the other coffee shop patrons appreciate all the package installing he's doing...
<efraim>fans whirring and everything?
<efraim>in the morning I put my coffee near the fan-out spot on my netbook
<paron_remote>probably, though at least that one you can't hear over the other coffee shop noise
<paron_remote>efraim: hehe, keep it warm?
<paron_remote>efraim: noticably the fans are noisier on the x200 I got from minifree, but also the laptop internals stay cool, which I often had problems with the x220 getting too hot
<paron_remote>so that's a tradeoff I'm happy to have
<efraim>my x120e doesn't get noisy, but it does get hotter than I'd like
<efraim>compiling i'm at high 90's, normal is 70's or 80's
<paron_remote>efraim: eek
<efraim>i installed the proprietary amd video driver as a test, at rest the laptop went down to 63
<efraim>it'll be 4 years feb 29th, and i'm into my 3rd battery now, it's survived pretty well
<NiAsterisk>rekado: patch is send, CC'ed you
<rekado>NiAsterisk: thanks!
<rekado>I sent the test log for GCJ on ARM to the GCJ mailing list and got confirmation that GCJ must be broken on ARM.
<rekado>will do the same for MIPS too.
<davexunit>soooo I just learned something that may complicate our Chicken package
<davexunit>if true
<davexunit> https://news.ycombinator.com/item?id=10896389
<davexunit>"Since Chicken's compiler always generates C code, which is then compiled by GCC (or Clang), one just releases both the source and the compiled C files."
<bavier>I was wondering about that while reading wingo's latest article
<davexunit>damn it.
<davexunit>I just checked Chicken's release tarball
<davexunit>there's a bunch of machine generated C files in it
<davexunit>"Generated from optimizer.scm by the CHICKEN compiler"
<rekado>bleh
<davexunit>filed a bug.
<davexunit>no idea how to resolve it
<davexunit>there's a really common misconception that machine generated text files are somehow not binaries
<davexunit>they aren't source code, so they are binaries, effectively.
<df_>but the source code is there?
<davexunit>yes, the Scheme source code.
<davexunit>but how do you build that code without a pre-built Chicken compiler?
<davexunit>this is the classic bootstrapping problem
<df_>how do you build gcc?
<davexunit>df_: gcc is another example of this.
<davexunit>a pre-built GCC is one of our bootstrap binaries, but GCC is absolutely essential.
<davexunit>I've heard talk of creating a tiny C compiler in assembly (for each platform) that can bootstrap GCC
<davexunit>I would really like that.
<rekado>as discussed a while ago, with some effort we might be able to do without GCC binaries.
<rekado>heh, davexunit beat me to it.
<davexunit>rekado: hehe
<davexunit>I saw where df_ was heading and wanted to nip that
<rekado>our bootstrap binaries include Guile. It's certainly easier to write a tiny C compiler in Guile.
<rekado>(would this help, though?)
<davexunit>rekado: no, because it just makes Guile the target ;)
<davexunit>we need tools written in assembly to bootstrap everything
<df_>but is auditing tools written in assembly any easier than manually verifying that a compiler has done its job?
<davexunit>df_: yes.
<davexunit>the tools would be minimal
<davexunit>just enough to bootstrap the next piece of the chain
<rekado>well, but it would still get us one step closer, by allowing us to drop the GCC bootstrap binary.
<davexunit>rekado: sure, as a short-term solution that is good.
<rekado>and to bootstrap Guile we'd hopefully need a smaller subset of a C compiler ... which could then be written in assembly (yuck)
<sprang>how about something like: assembly -> forth -> scheme -> C compiler
<davexunit>whatever works, honestly. :)
<sprang>it wouldn't be fast :)
<davexunit>speed doesn't matter
<davexunit>what matters is that it's possible
<sprang>right
<rekado> https://github.com/mortdeus/legacy-cc
<sprang>plus, you'd probably want to focus on readability/verifiability over performance anyway
<df_>so you need an assembler and something to generate the native executable format of your platform (ie ELF I guess)
<davexunit>there's likely a way to hand-write something minimal that can do that
<davexunit>but this isn't an easy problem, for sure!
<davexunit>but it's what we need to work towards
<df_>hmm
<df_>I think you have to have some kind of minimal binary to start from, but maybe it should come with extensive documentation
<df_>byte-by-byte explanation
<df_>although is that any better than distributing a generated binary along with its source?
<sprang> https://speakerdeck.com/nineties/creating-a-language-using-only-assembly-language
<sprang>he has an intermediate lisp stage
<rekado>sprang: very cool
<sprang>doesn't GCC use some C++ code now? can it be bootstrapped with only a C compiler?
<ecraven>münchhausen!
<rekado>sprang: it needs a C++ compiler
<sprang>hmm, that makes it a lot more complex
<davexunit>but an old version of gcc could perhaps build a newer one :)
<rekado>C compiler for Common Lisp: https://github.com/vsedach/Vacietis
<df_>nice
<rekado>civodul: re core-updates: do you think this can still go in this time: http://lists.gnu.org/archive/html/guix-devel/2016-01/msg00404.html ?
<civodul>rekado: hmm this causes a full rebuild starting from gcc-cross-boot0, right?
<civodul>actually no, no rebuild involved apart from the cross-compiled things
<civodul>rekado: just replied to the list
<rekado>civodul: thanks. I'll push it to core-updates as suggested.
<civodul>great
<bavier>civodul: http://hydra.gnu.org/job/gnu/master/boost-1.60.0.mips64el-linux
<mark_weaver>bavier: great, thanks very much!
<bavier>np
<civodul>bavier: yay, cool!
<alezost>sneek: ?
<sneek>Welcome back alezost, you have 1 message.
<sneek>alezost, civodul says: the top of the package-info buffers has changed from a large-font title with the package name to a small (and IMO useless) link; would be nice to revert maybe?
<alezost>civodul: it's a bug indeed. I didn't notice it because both 'guix-package-info-heading' and 'guix-package-info-name-button' faces are the same for me. I've just pushed a fix.
<alezost>the button is useful though (IMO)
<civodul>alezost: thanks!
<civodul>but the button links to itself no?
<civodul>it always says "A single package with name foo" for me
<alezost>yes, but it may be useful in some special situations :-) Sometimes I wanted to have this button in the past
<civodul>ok but what is it supposed to do? :-)
<alezost>civodul: It searches for packages by name. After "M-x guix-search-by-name guile" you'll get several guiles. After RET on any guile-2.0.11, this exact guile will be described. If you press this heading button, all guiles matching "guile-2.0.11" name will be shown.
<alezost>civodul: My common use case however is: if you kill Guix REPL, then switch to a Package Info buffer and try to update the buffer with "g", you can't do it because an old object-address of this package is dead, so you can press this button to find packages with this name
<alezost>civodul: And finally, there is a really useless option: try (setq guix-package-info-type 'output) and then press this heading button (press "l"/"r" to compare what you see)
<civodul>alezost: ok, i see
<paron_remote>hm
<paron_remote>does $GUIX_PROFILE really work?
<paron_remote>it's mentioned briefly in the manual
<paron_remote>so I tried export GUIX_PROFILE=$HOME/.debian-guix-profile
<paron_remote>but that didn't really work
<paron_remote>I expected it to put everything in ~/.debian-guix-profile but no cigar
<civodul>it's only used in the etc/profile file of the profile
<civodul>(read that twice :-))
<paron_remote>O_O
<civodul>so you can: export GUIX_PROFILE=foo; source $GUIX_PROFILE/etc/profile
<paron_remote>X_X
<civodul>heheh
<paron_remote>ACTION brain twists into a pretzel
<paron_remote>ACTION dips brain in mustard
<paron_remote>okay
<civodul>:-)
<paron_remote>so what I really want
<paron_remote>is a way so that *only* on my debian machine
<paron_remote>I set up some environment variable so it defaults to a different profile
<paron_remote>but.... it seems that this might not be easy :)
<paron_remote>"guix package -p" can do it, but not all guix subcommands take -p, and I'm not sure how to handle emacs knowing what profile to use
<civodul>you could always do something in ~/.bash_profile like: export GUIX_PROFILE="$HOME/.$(hostname)-guix-profile"
<bavier>I was looking for something like this recently too. Some way that I could have my default profile no in ~
<civodul>oh i see
<bavier>*not in
<civodul>GUIX_BUILD_OPTIONS maybe?
<civodul>or maybe not
<civodul>hmm
<paron_remote>I guess other people aren't being crazy like me
<civodul>or maybe 'guix package' should honor $GUIX_PROFILE
<paron_remote>booting two separate distros on different partitions that each have guix as a package manager on them, and then sharing a /home/ :)
<paron_remote>civodul: it feels like that one should be true, to me
<civodul>i didn't understand it, but you probably were expecting that?
<civodul>yeah
<civodul>why not
<civodul>maybe send it to bug-guix?
<civodul>(with a patch! :-))
<civodul>going to bed now, later!