IRC channel logs


back to list of logs

<efraim>sneek: tell civodul I found, inexpensive armv7 hosting online for 3 euro/month, looks like it is possible to install guixsd on it
<sneek>civodul, efraim says: I found, inexpensive armv7 hosting online for 3 euro/month, looks like it is possible to install guixsd on it
<rekado->I get a weird error whenever I try to start some xfce application (e.g. xfce4-appfinder): "*** Error in `xfce4-appfinder': malloc(): memory corruption (fast): 0x00000000023799a0 ***"
<rekado->And when starting icecat: "*** Error in `/gnu/store/cxhjczsmjf85znfjxy0jyh9fzc14hyfz-icecat-31.8.0-gnu1/lib/icecat-31.8.0/crashreporter': corrupted double-linked list: 0x0000000000d80e40 ***"
<rekado->already swapped the dimms for another pair, but I get the same error.
<rekado->I can log into Xfce with slim and Emacs starts up automatically. But beyond that I cannot start any programmes.
<rekado->hah, it's because I set GTK_IM_MODULE_FILE for ibus.
<rekado->wow, that's dangerous.
<rekado->What I did was this:
<rekado-> gtk-query-immodules-3.0 ~/.guix-profile/lib/gtk-3.0/3.0.0/immodules/ > ~/immodules.cache
<rekado->and then set GTK_IM_MODULE_FILE to ~/immodules.cache.
<rekado->looks like it's a bad idea to have only the ibus input method in the list of immodules.
<x-iyzsong>yes, i think it should be built in the profile hook.
<rekado->hmm, the problem is not with "im-ibus" being the only thing in the immodules.cache, but having it in there.
<rekado->I generated a cache file with "gtk-query-immodules-3.0 > ~/immodules.cache" and then appended the stuff for ibus and got the same malloc error.
<rekado->without it the error disappears.
<rekado->x-iyzsong: do you happen to know a little about how ibus works? I find it quite confusing.
<x-iyzsong>rekado-: basiclly, it provides im modules for gtk2, gtk3, qt, etc. but I don't know why it will crash :-
<x-iyzsong>do the im-ibus built with the same gtk version as gtk-query-immodules?
<rekado->.... I'm so confused now: in icecat the pinyin input method works right now and I have *no* idea what made it work.
<rekado->ibus builds two im-ibus modules, for each gtk version.
<rekado->if I use the gtk2 module in the cache file I just get a segfault when running xfce4-appfinder.
<rekado->with the gtk3 module I get this weird memory corruption error.
<rekado->but first I have to figure out what steps I took that just made pinyin work in icecat.
<rekado->this is so cool! (and so weird!)
<x-iyzsong>well, I haven't look much into IMs, I use fcitx with just XIM for all the things now. Having gtk im modules work would be great.
<rekado->it does *not* work with Emacs, unfortunately, but right now I can type pinyin in Icecat, Inkscape, and all XFCE applications I've tried so far (xfce4-terminal, xfce4-appfinder).
<x-iyzsong>rekado-: cool! do launch emacs with 'LC_CTYPE=zh_CN.utf8' works?
<rekado->I'll try
<rekado->the input method is a bit weird, though.
<x-iyzsong>well, I have the same issue with Emacs/fcitx in ArchLinux (installed today).
<rekado->e.g. I cannot input "hao", and when I type "cong" it recognises it as "cuo neng".
<rekado->but I think this can be configured somewhere.
<rekado->another weird thing: no icons are displayed, neither on the language bar nor in ibus-setup when selecting either of the Chinese IMs.
<x-iyzsong>that's the expected behaviors for me, I'll be surprised if something like ibus work-out-of-box for guix :-)
<civodul>Hey, Guix!
<efraim>I found, inexpensive armv7 hosting online for 3 euro/month, looks like it is possible to install guixsd on it
<mark_weaver>efraim: on the master branch, GuixSD only supports intel machines. on the wip-loongson2f branch, there is experimental support for the Lemote YeeLoong (MIPS based). armhf support in GuixSD doesn't yet exist in any branch.
<mark_weaver>I intend to rectify that at some point, of course.
<efraim>i know
<efraim>they have 50GB ssd targets, we could target a second one and use that as a system init target, and then boot from it
<efraim>so not quite a guixsd install, but still only running guix
<mark_weaver>sure, the main missing bits are the kernel and grub.
<efraim>it might need uboot
<efraim>there isn't a libre-linux kernel for arm?
<mark_weaver>I believe it should be possible to chainload grub from uboot
<mark_weaver>grub is kind of important for GuixSD, because it's the way we allow roll-back to earlier system generations.
<mark_weaver>as for linux-libre: I suppose that some armv7 machines will work on upstream linux-libre, but we need a configuration.
<efraim>apparently its a relatively old board
<mark_weaver>the armv7 board that I have to play with, the Novena, doesn't yet have all of its patches upstream, so I'll need to make another package that inherits from linux-libre, like I did with the YeeLoong.
<mark_weaver>all of the non-Intel machines I've worked on with Guix require non-upstream patches to the kernel, so I personally won't be able to help with the creation of "generic" kernels on non-Intel machines, if that sort of thing is even supported on non-Intel machines (I haven't yet researched that question).
<civodul>mark_weaver: gives me some hope
<mark_weaver>civodul: yes, indeed
<mark_weaver>bah, it seems that the 'tar' in our bootstrap binaries does not know about the --sort option
<mark_weaver>it was added in version 1.28
<mark_weaver>(released 2014-07-28)
<mark_weaver>well, that's okay, there are other ways...
<mark_weaver>we can use --no-recursion and --files-from to pass it the sorted list of files
***luaR is now known as Guest31798
***frob is now known as Guest13853
<civodul>mark_weaver: it might be simpler to build another tar in the bootstrap process, no?
<mark_weaver>civodul: unfortunately, 'tar' itself needs patches
<mark_weaver>although I suppose we could apply those outside of the 'origin'
<mark_weaver>or, maybe we could get away with omitting the patches for this bootstrap tar
<mark_weaver>ACTION looks
<civodul>yes, that's what i was looking at
<civodul>though the first one is supposedly to fix a Hurd build failure
<civodul>but yeah, we could apply them in an additional phase, for 'tar-boot0'
<mark_weaver>I don't know, now that I look more closely, I'm not sure this approach would be simpler.
<mark_weaver>generating the file list with 'file-system-fold' is not so bad
<mark_weaver>unfortunately, I can't use 'find-files' because there's no way to make it include the directories.
<davexunit>I remember wanting that recently, too.
<rekado->ibus-libpinyin has an file that just calls (which I couldn't find). Does anyone know what this script does?
<rekado->I tried "autoreconf -vif" but it complains: error: cannot find input file: `po/'
<rekado->and when I create it myself it says: error: po/ was not created by intltoolize.
<mark_weaver>civodul: I'd like to add a keyword argument to 'find-files' to include directories. wdyt?
<civodul>mark_weaver: why not, maybe #:directories?
<civodul>rekado-: try: gettextize && autoreconf -vfi
<civodul>(don't they provide a tarball?)
<mark_weaver>civodul: we need to remove xf86-video-intel from xserver.conf on non-intel platforms, because it only builds on intel. what's the best way to do that? xserver.conf is built using 'text-file*' in (gnu services xorg)
<rekado->civodul: thanks. No tarball, unfortunately.
<civodul>mark_weaver: some refactoring is needed there so that the list isn't hard-coded
<civodul>probably using 'gexp->file' instead of 'text-file*'
<civodul>and having a parameter for the list of packages for which a "ModulePath" clause must be added
<civodul>then that list can be made arch-dependent
<mark_weaver>civodul: one more thing: I'd like to also add a #:fail-on-error? keyword argument to 'find-files'. wdyt?
<mark_weaver>(not sure about the name)
<mark_weaver>but something that causes errors during 'file-system-fold' to raise an exception instead of merely displaying a warning.
<civodul>mark_weaver: sure, makes sense
<civodul>i don't think we could change the default though
<civodul>i vaguely recall seeing those messages with the libxml2 search path
<civodul>yeah, see evaluate-search-paths
<mark_weaver>I agree that we shouldn't change the default, at least not yet :)
<civodul>yep :-)
<rekado->woo, ibus-libpinyin works! Still no icons but it actually works right away (unlike ibus-pinyin).
<civodul>rekado-: nice!
<civodul>so ibus-libpinyin != ibus-pinyin?
<rekado->yes, they are different projects. "ibus-pinyin" uses the "pyzy" pinyin library, whereas "ibus-libpinyin" builds on top of "libpinyin".
<rekado->IBus needs the dconf-service to be running in any case. I'll write a service definition.
<civodul>i see ueno is here, ey might be able to help if needed ;-)
<civodul>interesting discussion of systemd's startup notifications:
<civodul>sneek: later tell davexunit see about systemd's startup notifications
<sneek>Will do.
<civodul>sneek: botsnack
<mark_weaver>well, I have a fix for core-updates to cope with the bootstrap tar not supporting --sort, but I don't currently have the means to test it. since my X200 is having problems at the moment, I'm currently limited to my YeeLoong.
<mark_weaver>I suppose I could just push it to core-updates and test it that way :)
<mark_weaver>or maybe to another branch. thoughts?
***frob_ is now known as lovro
<mark_weaver>well, I've stared at this code long enough, and done some pseudo-testing of the excerpts, so I guess I'll cross my fingers and push :)
<civodul>mark_weaver: okay, we'll see :-)
<mark_weaver>civodul: your "Service refactoring" thoughts sound perfect to me :)
<civodul>mark_weaver: aah good, thanks!
<civodul>now to come up with actual code
<civodul>well, not for today
<civodul>good night/day!