<quiliro>mekeor: i will read the manual to see if i can learn to send a patch to the manual <quiliro>mekeor: i have not read that section consentiously....will do <thomassgn>trying to get dig into my path, how do I figure out what derivation bind utils are part of? Or is there another way to do this? <thomassgn>I can find bind utils in my store. It references bind among others. <reepca>thomassgn: have you installed bind utils (guix package -i bind:utils)? <reepca>oh hey, I'm not the only one who spontaneously died <Tekk_`>bavier: thanks, seems it may as well be an infinite loop on this poor little laptop though <Tekk_`>That or it just dies trying to merge all the information together <Tekk_`>I left the netbooks spinning on guix pull for a good 8 hours ***Tekk_` is now known as Tekk_
<catonano>the cuurrent Icecat version is not supported in the brand new Flattr beta program :-/ <mekeor>catonano: what is the Flattr beta program? ***eacces_ is now known as eacces
<catonano>mekeor Flattrr is launching an algorithm that should "understand" what ti is that you really want to contribute to on te basis of your browsing history. Because they realized that people don't want to manually manage flattrs <catonano>mekeor but that requires a browser plugin <catonano>Neither the current Icecat and theh Gnome Browser (I don't remember its name) are supported <rain1>if there's anything i can help with mes just say <ng0>is something wrong with our isync? the 'mbsync' binary of it took 24 hours to process 200.000 emails… at this speed it will take another 5 days to finish <ng0>this isn't the normal speed, is it? <janneke>rain1: thanks! my wip-hex2 now builds for me with gcc-7.1 and without i686-unknown-linux-gnu-gcc, IWBN if you were able to build it <mekeor>ng0: it is probably normal speed. i usually copy the maildir from one device to an usb-device, then copy it on another device. <rain1>I wanted to do it on my host instead of inside my guix VM but if making that work is too hard/out of scope, thats fine! <janneke>rain1: i just updated a couple of minutes ago, yet another configure bug <ng0>I can't just do that.. or for matters of security <ng0>It's a professional contract email-only service <ng0>in that case I will just take the time and wait.. initial sync is the slowest I hope. afterwards it's just adding and deleting <ng0>taking a plane to norway would be faster <ng0>what's worse, after 80000 I have to restart because the progress (not the process) hangs <rain1>ng0: did you ask about backticks on 's' shell? <ng0>i have a long delay sometimes, haven't forgotten about it <rain1>ok! I have made a start on it - not complete yet but i pushed a start on it <ng0>I think I had some more ideas. You probably don't aim for it, but what about being able to use it as a full login shell? Of course size will grow then with all the functions needed.. <rain1>i'd like that! feel free to suggest any ideas either as a issue or just say it to me <ng0>ok :) I'd love to contribute but things keep stacking up here <ng0>so suggesting ideas in form of bugtickets is the best I can do <janneke>rain1: great, thanks! i'll add a fix later, can you try: <ng0>mekeor: I used getmail for so long, it just worked. the speed of mbsync makes me regret the will to change <mekeor>ng0: i never heard of getmail. i only know offlineimap beside isync/mbsync which is even slower <ng0>getmail just does what it says <rain1>ah but make check stops here <rain1>make: *** No rule to make target 'out/m.mlibc', needed by 'm.mlibc-check'. Stop. <janneke>.mlibc are results of the CC32 compiler, those need to be disabled too <ng0>mekeor: I will abort this… maybe I'll try again when I have cleaned up from 710k to ~200k emails <koosha>Do I need to add something in "use-package-modules" for installing openbox ? <ng0>either wm or openbox, don't remember where it is <mekeor>koosha: you can run `guix package --show=openbox` and then look at the gnu/packages/<here> path <ng0>mekeor: on the downside, 177000 duplicates to delete now :D <mekeor>koosha: do you use use-package-modules in your user-manifest.scm or in your system-config.scm ? <koosha>mekeor: :D , and what shold be written in the "title" part ? <mekeor>koosha: sorry? i don't understand your question <koosha>mekeor: In the system-config.scm , there is a part like this : " (title 'label)" . <mekeor>the title part "is a symbol that specifies how the device field is to be interpreted." <mekeor>"When it is the symbol device, then the device field is interpreted as a file name; when it is label, then device is interpreted as a partition label name; when it is uuid, device is interpreted as a partition unique identifier (UUID)." <koosha>mekeor: Oh , Thank you so much and sorry for the question , I had to find it in the manual . <mekeor>no problem. it's not always easy to find things in the manual :) <mekeor>although some things are not yet documented, for example modify-phases <ng0>how's networkmanager doing? Are there any issues left with it? <mekeor>ng0: i use it and i'm content with it except one thing: sometimes i have to run `dhclient -v INTERFACE` manually <mekeor>i think i didn't yet report a bug regarding this issue, IIRC <ng0>do you just add something like (service networkmanager-service-type (network-manager-configuration)), exclude wicd from %desktop-services and configure networkmanager by hand? <ng0>ah, found your system config in the repo… okay you use base-services. I hate summer temperatures. <rekado_>I get a database error with Cuirass. <rekado_>something about a key not being unique <efraim>i don't think xf86-video-vmware is supposed to be allowed on aarch64 <efraim>it builds on armhf, i'll leave it for now <gmuh>Hi, total guix newbie here. I'd like to use GuixSD on my laptop/desktop, I was wondering how often the distro should be updated in order to avoid any breakage <buenouan1>gmuh: that's a very nonguix way of thinking about it ;3 <buenouan1>each user can update what they want as and when they need or desire <buenouan1>and there's no real fear of breakage because you can easily roll anything right back on the off chance of something going wrong <buenouan1>the awful days of rolling dice with sudo apt-get upgrade are over <gmuh>buenouan1: I always have a hard time believing claims that nothing will ever break, especially when talking about software <buenouan1>sure, but guix being a functional package manager does away with all the major and common breakages you're used to <gmuh>buenouan1: Alright, I'll give it a try then. Thanks :) <bavier>so gsl moved documentation to sphinx, eh <efraim>Maybe the tests will run o aarch64 this time <bavier>the rationale given in the release announcement was "built-in suport for latex in html output", but I thought texinfo could do that too, but I might be mistaken <bavier>I'd rather they had worked with texinfo devs to add support for that <mekeor>i wonder why nobody seems to care about bugs #27425 and #27418 which make guix stuck at updating substitutes, i.e. it's an important error. – i mean, there've been no responses to the bug-reports. <mekeor>well, maybe i'm just impatient. sorry <mekeor>i had a working guix instance after installing version of commit 01049bb0c1f3f69afb8d1782f99ca5c0adaed946, but guix upgraded itself at some point, i think <rekado_>I cannot respond to the bug report because I cannot reproduce this reliably <thomassgn>reepca: aha, no. I didn't realize it was an output. <rekado_>koosha: this is a bug that has been reported recently <bavier>koosha: the 'guix pull --url=...' bit <koosha>bavier: Won't be any problem during working with guix after that ? <bavier>koosha: it should help, but no guarantees <mekeor>koosha: it's a current bug, i'm also having problems with it <koosha>Is the installation finished after that or I should run the "guix system init" again ? <lambdatronic>Hi guys, is anyone having trouble with "guix system init"? After running it from the USB install image with my config.scm, I keep getting a grub-install error that's telling me the modinfo.sh is missing. When I check the directory it references, I can see that it, of course, doesn't exist. But it looks like it is trying to install to an EFI target when my system has a normal x86 BIOS. Help? <bavier>koosha: you'll need to run 'guix system init' if it hasn't already succeeded. <koosha>bavier: It returned me the message "substitute: updating list of ..." . <bavier>koosha: hopefully this time it complete that substitute lookup and move on to installation <janneke>rain1: got new set of non-Guix[SD] build up, if you'd want to check <janneke>rain1: i was wondering even if you don't use GuixSD yet, [why] aren't you using guix on top of Arch? <lambdatronic>Hi guys. I'd like to use GuixSD, but "guix system init" won't work for me. It runs for awhile installing packages onto my /mnt partition, but then it errors out at the grub-install stage, because it seems to think that my machine has an EFI boot setup, when it just has a normal ACPI BIOS. I tried running with --no-bootloader and then running grub-install manually with --target=i386-pc, but that errors out with complaints about <lambdatronic>"unionfs". Does anyone know how to fix this problem? I'd really like to run GuixSD, but if the grub-install stage won't complete, I'm stuck. <rain1>this is good! some tests failed but make check completed <janneke>rain1: good news, thanks for checking this. <janneke>rain1: the mes build system is currently terribly complicated. OriansJ wants to make that simpler at least for bootstrapping... <janneke>the thing is: mes.c is a scheme interpreter <janneke>that can be compiled with 1) CC: native gcc (usually x86_64), or 2) CC32 (usually i686-unknown-linux-gnu-gcc) without glibc, but using Mes's libc: mlibc, or 3) using Mescc: guile/mescc.scm run on Guile, or 4) using Mescc: scripts/mescc.mes run on mes <janneke>4) is the final bootstrap path, but 1), 2) and 3) have been of great help using development <rain1>janneke: I've been thinking about this... <rain1>is there any c compiler without a libc? <rain1>because it seems like goign from a c compiler without libc, to one with could be an important step <janneke>rain1: the i386 target aka `mlibc' uses i686-unknown-linux-gnu-gcc -nostdinc -nostdlib <janneke>mes can be built without external libc <janneke>rain1: those 2 test ar expected to fail (expect: 2) <janneke>well, we'll want to fix them, but they are not blocking and i don't see how yet <rain1>asm |> forth |> scheme interpreter |> mes could be an option <janneke>if you make that asm |> forth |> scheme compiler |> mes ... <rain1>yes, it might be important to comple for speed <janneke>the problem with too many layers is performance <janneke>asm => LISP1.5 => Scheme => Mes .. but that's just toooo slow <janneke>but, you never know...as OriansJ`` likes to say: we're finding out what works <janneke>many possibilities, only a few are probably practical <rain1>there's also questions about how to get linkers, binutils and things <rain1>there might be a couple levels of increasingly advanced linkers <janneke>rain1: currently, mescc does linking in scheme of hex3 formats <janneke>and OriansJ's MESCC_Tools's hex2 linker is used for hex2 format linking <janneke>i am working to remove hex3, which served as an intermediate step between Mescc's lambda-based object format and hex2 <rain1>ah i might be calling this the wrong thing, i'm thinking about combining multiple elf object files into a elf executable <janneke>hex2-linked ELF binaries cannot be used with GDB, but we're making good progress there <janneke>rain1: i think we're talking about the same thing <janneke>mescc can compile .c -> hex2 (or hex3), several hex2 or hex3's can be linked to an ELF <janneke>yesterday i succeeded in patching the hex2 linker and hand coding a gdb-debuggable hex2 <janneke>but i need OriansJ``'s opinion/input on that <janneke>yeah, i could have said: that's weird, i have no idea <reepca>I woulda asked them to provide their config.scm had I been awake <rain1>we can use a secondary channel for longer discussions about bootstrapping stuff if you likeo <janneke>not sure if that's needed, but we should try to be more open/friendly to people who seek help <ng0>hi :) can someone correct the hash of libpng-apng? It changed <ng0>it should be 0m5nv70n9903x3xzxw9qqc6sgf2rp106ha0x6gix0xf8wcrljaab <ng0>I don't know why, maybe it was changed in place <mekeor>are you too busy to correct the hash yourself? :D <rain1>ah. it would be nice to diff them though? <ng0>I can't push simple changes.. or at all <ng0>locally I just use a variant <OrangeShark>ng0: probably need to confirm that upstream did intend to change the file <ng0>well the hash of the file which comes from SF differs, that should be enough that at least someting changed <ng0>libpng was updated, but I guess that's in core-updates <rain1>but did the version number change <ng0>this is with the old and version matching libpng-apng <ng0>I have no way to diff changes <ng0>well.. okay. if it is on hydra someone could get the file from there and compare <ng0>I'm just pointing out it has changed, I'm working on something else. I won't send a patch for 1 line. <ng0>what I mean is, I don't think this is worth waiting review for, someone should control it and then just commit. <bavier>civodul: there were some reports earlier about guix hanging when fetching substitute info from mirrors. Do you have any insights about that? <reepca>Well, I'm just thinking, at the derivation-building level, there's no distinction between native, propagated, and normal inputs, right? So in copying stuff into the /gnu/store under the chroot, that means that if A is needed for building B, and B is needed for building C, A will need to be present along with B even though it's only needed for building. Is that right? <janneke>i have found `guix system reconfigure' on a 0.13 vm to break on failing to download linux-libre-headers. <janneke>manually doing: guix download "mirror://gnu/linux-libre/4.4.47-gnu/linux-libre-4.4.47-gnu.tar.xz" <janneke>usualy fails one or more times, to finally succeed -- pretty weird <civodul>janneke: how does the download fail? <civodul>reepca: derivations have no notion of native/propagated/other inputs indeed; just "inputs" and "sources" <civodul>reepca: so yes, in the chroot, everything that's needed at build time is visible <civodul>but wait, wasn't there a substitute for it in the first place? <civodul>also, even if none of the GNU mirror has it, it should be on mirror.hydra.gnu.org/file/... no? <janneke>civodul: exactly -- after this first download i can retry and see similar things -- dunno? <mekeor>civodul: please check out bugs #27418 and #27425 as your commit 3bacc655c5fd988f0199ef259adcb4fb3754042e may have caused them <mekeor>... (i.e. those bugs regarding guix getting stuck at updating list of substitutes) <civodul>janneke: 'guix publish' was seemingly hanging, but i don't know why <civodul>i've restarted it and everything looks better now <civodul>apparently it hadn't been producing substitutes over the last couple of days :-/ <janneke>civodul: ugh, had to reset guix publish also a couple of times (2?) in the past week <janneke>civodul: very good to know that we have a fallback for source tarballs :-) <mekeor>so, the bug regarding guix getting stuck at updating substitutes wasn't caused by a code-bug but by hydra?? <civodul>janneke: oh really? if you can grab data next time your 'guix publish' is stuck, that'd be great <civodul>here i looked at the backtrace and one of the threads was in poll(2), which looks normal <janneke>civodul: how do i `grab data'? I was looking for a log file... <janneke>civodul: also, sorry to say that if i now run: guix download mirror://gnu/linux-libre/4.4.47-gnu/linux-libre-4.4.47-gnu.tar.xz <civodul>try "guix build -S linux-libre-headers --check" instead <civodul>"guix download" only tries the URL that you give it, i.e., the list of GNU mirrors <civodul>whereas the code that downloads sources tries substitutes first, then the URL (GNU mirrors), and then the content-addressed mirror <civodul>i suppose that when something is removed from ftp.gnu.org, eventually all the mirrors erase it as well <janneke>why do people [try to] remove stuff... <civodul>janneke: apparently xl-mirror.nl just redirects to a random unrelated page <civodul>and then you get that wrong-hash error <civodul>problem here is that the hash is checked after the code that downloads stuff has run <civodul>the code that downloads stuff just makes sure that it gets HTTP 200 <civodul>when it does, it assumes everything's fine :-/ <janneke>could maybe be solved by throwing one sharply aimed if, could be terribly hard to fix -- new territory for me <civodul>things is currently there's a strict separation between what the daemon does and what 'guix substitute' does <civodul>the daemon checks the content hashes already <civodul>er, not 'guix substitute', (guix build download) rather <civodul>if we check hashes in (guix build download), it'll be redundant and costly <janneke>civodul: what if the (err, reepca' new) daemon would come back with a special error code: hash failed, would omething like that work <janneke>no redundancy, only pay upon failure <civodul>janneke: with the new daemon, we can have much tighter integration <civodul>so there won't be that artificial separation between download and daemon, i think <OriansJ``>sneek: later tell janneke that I have a present for him. (a hex assembler written in M0 for AMD64) <sneek>OriansJ``, you have 1 message. <sneek>OriansJ``, janneke says: on my wip-hex2 branch i have a handcoded exit42 example in hex2, that can be inspected with objdump and debugged with gdb. handcoded bits because i needed substraction. <reepca>sneek: later tell sneek: later tell sneek: hi <OriansJ``>rain1: also I have M0-macro little-endian patches and fully support for the new !@% data size encoding <rain1>i got mes building and the tests pass <rain1>im not sure how to use it yet but i'd like to help build 8cc with it