<efraim>sneek: tell civodul I found scaleway.com, inexpensive armv7 hosting online for 3 euro/month, looks like it is possible to install guixsd on it <sneek>civodul, efraim says: I found scaleway.com, 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-> gtk-query-immodules-3.0 ~/.guix-profile/lib/gtk-3.0/3.0.0/immodules/im-ibus.so > ~/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->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. <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->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 :-) <efraim>I found scaleway.com, 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. <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>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). <mark_weaver>bah, it seems that the 'tar' in our bootstrap binaries does not know about the --sort option <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>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 <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. <rekado->ibus-libpinyin has an autogen.sh file that just calls gnome-autogen.sh (which I couldn't find). Does anyone know what this gnome-autogen.sh script does? <rekado->I tried "autoreconf -vif" but it complains: error: cannot find input file: `po/Makefile.in.in' <rekado->and when I create it myself it says: error: po/Makefile.in.in 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 <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>but something that causes errors during 'file-system-fold' to raise an exception instead of merely displaying a warning. <civodul>i don't think we could change the default though <civodul>i vaguely recall seeing those messages with the libxml2 search path <mark_weaver>I agree that we shouldn't change the default, at least not yet :) <rekado->woo, ibus-libpinyin works! Still no icons but it actually works right away (unlike 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 ;-) <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 :) ***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 :) <mark_weaver>civodul: your "Service refactoring" thoughts sound perfect to me :)