***Steap_ is now known as foobar__xxx
<epronk>When shepherd says "failed to start service 'foo'". How can I get some logging to see what failed? <janneke>epronk: are you booting through an rs232 cable, aka ttyS0? <janneke>ACTION adds experimental annotations to mescc's hex2 output ***zetok_ is now known as zetok
<quigonjinn>i have an issue packaging some software. package A's .pc file "Requires: python3". I am building package B which depends on package A, but if python is not listed as an input, pkg-config can't find it and cmake fails. Are there any examples fixing that without having python as an input, since it is not really required by package B? <quigonjinn>nvm, i see they should be listed ad propagated-inputs by package A <epronk>herd start gpm => "Service gpm could not be started. herd: failed to start service gpm". How do I debug? ***Introoter is now known as roo
***roo is now known as Guest51789
***Guest51789 is now known as Introoter
<ng0>I have mutliple definitions of gnunet in my path. none of them are named gnunet, the only pcakage and function name 'gnunet' I have is the canonical one in Guix. Why would a package defintion in the guix source (gnunet-fuse) suddenly pick up gnunetgt especially when I defined explicitly *gnunet* in the gnunet-fuse definition and not gnunetgt? <ng0>I mean, an entirely different function and package name is picked up.. this feels like a bug. <ng0>I can build gnunet on its own and I can build gnunetgt on its own and when I want to install gnunet as far as I know gnunet is picked and not gnunetgt or one of the 6 other gnunets <rekado_>Guix never just “picks” something. You use variable names and they must be unique. <ng0>which is why I don't understand this <ng0>gt isn't even installed in my profile <rekado_>wait, Guix doesn’t care what’s installed in your profile and what isn’t. <rekado_>can you provide a minimal example that demonstrates this behaviour? <ng0>I'm building profile updates.. in a while I can provided this <ng0>what I have is this: <ng0>gnunetgt and other variants inheriting from gnunet. They are in GUIX_PACKAGE_PATH, in (ng0 packages gnunet). gnunet-fuse is in src/guix/guix inside the 'normal' (gnu packages gnunet). I don't use the module ng0 packages gnunet in gnu packages gnunet <ng0>the minimal expample would be clone the packages repo (mirror with 48 hours delay is on notabug.org), include it in your package path, and apply the patch I'll send as soon as I can switch the branch again <ng0>that's as minimal as it is for what is needed to reproduce the error <ng0>shouldn't /tmp be cleared once in a while at least at shutdown? I just found directories of failed builds I kept and they are still there <ng0>this question I asked on the list about the keyboard in E21, Ithink we need to make enlightenment aware of the setxkbmap path. Or I searched for the wrong words <ng0>what else would provide XKB_BASE at configure time? <ng0>/* Define to the base directory for X keyboard configuration data */ <ng0>currently the keyboard switch in E21 is in a disfunctional state <ng0>even setxkbmap on its own is <ng0>some window and desktop managers seem to have no user base in GuixSD or at least none of those who are capable to report bugs <ng0>Like, Lua or some of its modules has some kind of Guix specific errors which affects runtime of awesome-wm. <cehteh>i use lua .. but i3-wm and not guix as main machine yet :D <brendyn>ACTION sorts python.scm alphabetically and submits it as a patch /s <quiliro>would someone please tell me how to make grub recognize guixsd installation? i installed it via guix on debian working on another partition <quigonjinn>in order for udev rules in a package's /lib/udev/rules.d/ to be applied, should the package be installed via the operating-system configuration? <nee````>Hello libgxps in gnome.scm has a download url. It starts with "mirror://gnome/sources" but should have a slash at the end "mirror://gnome/sources/". Since it is required for gnome over evince all gnome updates are failing right now. <quiliro>is there a way to install grub from a foreign distro to boot guixsd? <quiliro>guix is installed in the foreign distro <alezost>quiliro: you can add an entry for GuixSD to grub.cfg manually. I can show how it can look like, but adding it manually is not... an intended way :-) <quiliro>so what should i do? i cannot boot on guixsd which is in another partition from debian. <quiliro>since the network is not needed any more, i can use the usb port for the installer <quiliro>alezost: let me try that and i will report <quiliro>on another topic: i cannot connect to a machine via ssh <alezost>quiliro: ok, so you want to boot an arbitrary system from /gnu/store, right? <quiliro>how can i enable it? what is the name of the daemon? <alezost>quiliro: do you want to boot some /gnu/store/sf5lmfw12mwmhhfk8hggh3kimckzy6dy-system or /var/guix/profiles/system? <quiliro>on the laptop, i have debian with guix. on another partition, i installed guixsd with debian. but i could not boot it. at the end of the installation it gave me a grub error. possibly because it is an efi system....all i want is to boot from that guixsd partition but rEFInd would not detect it <quiliro>on the desktop, i have a bare-bones.scm installation <quiliro>i would like to know the name of the daemon so i can start it <alezost>quiliro: ok, at first, can you edit "grub.cfg" to add an entry for GuixSD there? <quiliro>alezost: not better to boot with the installer and do it from there? <alezost>I don't know what is better for you :-) I just said that I can show a menu entry for GuixSD that can be added to grub.cfg so that you can boot it <alezost>so I can show that entry, but you need to know how to add it to grub.cfg. Do you still want to go this way? <quiliro>alezost: i will try to do it with the installer...if it doesn't work, will you help me with what you are suggesting? <alezost>quiliro: sure, except: I assume that you know how to edit grub.cfg <quiliro>i don't but will ask after my return <quiliro>what about the daemon for starting ssh server? what is the name? <rain1>theres some old notes on itt, might be invalid by now <rain1>(service openssh-service-type (openssh-configuration (port-number 2222))) <rain1>this seems to be a new syntax <rain1>using openssh instead of lsh <quiliro>yes...mine is using openssh on the bare-bones.scm <sneek>Welcome back OriansJ, you have 1 message. <sneek>OriansJ, janneke says: i have removed 45/51 lambda's from mes's .o output -- hex3 now passes 80% of the test suite. I also have experimental hex2 output. Problem with hex2 is i need several flavours of labels: function-local goto labels, absolute address labels, relative address labels (and 1, 2, 4 bit labels -- that bit is easy and resolved). Usually assembly handles this, but with hex...I could do with some help here going <OriansJ>so a grand total of 8 different label types, not a problem <janneke>yeah, meanwhile all lambda's are gone <OriansJ>janneke: the good news it is simpler than you think, we simply add a couple new definitions and it should cover your requirements <janneke>and sexps-based hex3 looks a lot like hex2...indeed we only need to align on what we want, i think <janneke>and this morning i was playing with adding annotations/comments to hex2 <OriansJ>although I am honestly surprised you didn't go a simpler route and simply assume all displacements and immediate values were 32bits <janneke>OriansJ: that might just have been easier if i had done that from the start <OriansJ>Oh well, I'll modify the hex2 I wrote for you to include a few more and document them on the wiki <janneke>but mescc has been using 1,2,4 byte labels and changing that now is an extra step with quite a bit of work <janneke>OriansJ: i have no objection to remove those later, dunno... <OriansJ>so 1byte relative displacements, 4byte relative displacements are all you need added by the looks of it <janneke>ah great! if you could look at my latest wip-hex2 branch, using: `guile/mescc.scm -g' gives hex3, without -g gives hex2+ <janneke>OriansJ: oh, does mescc not use 2 byte? <OriansJ>janneke: actually the hex2 I wrote for mes already supports 2byte relative and absolute addressing @token and $token <OriansJ>&token covers 4byte absolute addressing and if I remember correctly x86 doesn't even support 1byte absolute addressing <janneke>oh, and there's another thing with globals, esp. strings -- you may have seen that <OriansJ>janneke: I may be able to program many things in x86 assembly but I can not even remotely claim to know half of everything in it <janneke>i have been using `s:' as prefix and then the whole literal string as a label (e.g.: "s:Hello world!\\n") to avoid duplication without adding any indirection or computation -- <janneke>`it works'(TM) for mescc, but we need a nice solution here <cbaines>reepca, amazing, thanks for pointing out canonicalize-path :) <OriansJ>janneke: If you look my macro assembler, you'll see I solved the string problem by simply converting it to hex and appending 00 to the end to pad to 4byte addresses <OriansJ>janneke: that way I don't have to treat strings as anything special <janneke>OriansJ: is that stage1/High_level_prototypes/M0-macro.c? <OriansJ>as you can see the hexify_string function is rather trivial <janneke>OriansJ: yes but: ah...i don't think that's my problem -- let me try to explain better with this example <janneke>the label you use for "DEFINE00" is :Identify_Macros_string <janneke>mescc would currently use the label: "s:DEFINE" pointing to similar hexified "DEFINE0" data <janneke>mescc cannot (currently does not try to) create a name such as `Identify_Macros_string' -- all it can work with is the string literal <janneke>we need something for that label indirection, i guess <OriansJ>janneke: or simply treat s:token the same as any other :token <janneke>OriansJ: possibly...but there might be spaces in the string <OriansJ>janneke: space converted to hex is 32, it isn't going to be a problem <OriansJ>as long as the characters in the string are converted to hex, hex2 will be able to process them to the desired output regardless of what they are <OriansJ>Even if what was needed was a dozen backspace characters (7F) it still would not produce a problem <janneke>yeah...come to think of tcc.c--strings can get quite large, we'll probably need a hash or something <OriansJ>janneke: umm why? worst case for string storage is a couple of megabytes <OriansJ>unless you expect the entire contents of war and peace to be contained in a resulting binary???? <janneke>just use the hexified string as its label then, prefixed with s: (i.e. 733a), yes that would work <janneke>mescc could produce for "DEFINE" something close to <rain1>why not add string constants to the language? <janneke>OriansJ: ys, that's probably better -- but we need a solution for the case where there's a function called "string_2" <OriansJ>janneke: We just need a consistent pattern that is unlikely to step on itself <janneke>yep, sorry to be so picky -- anything that works is ok, we can improve later if we want <OriansJ>rain1: we have that, it is part of Stage1's M0 macro language <OriansJ>janneke: only a suggestion and you are free to do as you wish. <janneke>OriansJ: :-) i'd like in my freedom to choose something that you'll be happy to implement (or better even: won't have to do anything special for) in your hex2 assembler <OriansJ>janneke: I did some checking and found that we could try something a little more radical, as we could encode all of your core assembly functions in about 200 lines of M0 macro <janneke>OriansJ: that's beautiful! i'm guessing R0 == eax, etc <OriansJ>it'll probably be more like DEFINE jmp E9 DEFINE inc_EAX 40 DEFINE inc_EBX 43 <janneke>yes, we can do that! oh, all that work you already did which i so blondly skipped over now seems to fit together -- very nice <OriansJ>so it will not be as beautiful but you'll have easy to read mnemonics, comments and maybe something special <OriansJ>rain1: would you be up to helping with this? <OriansJ>janneke: essentially we are going to have you output M0 macro assembly <janneke>OriansJ: yes...that will get us the ability to run mescc's C compiled output on stage0's VM and the step to x86_64 or arm becomes quite easy too? <OriansJ>rain1: documentation of the macro language is going to become important <OriansJ>janneke: well not exactly but it will make the task of making your compiler portable a simpler problem <OriansJ>janneke: as Stage1 M0 macro assembler is platform neutral and it is the definition files that make it produce result that target a specific platform <OriansJ>janneke: so what I am going to do is 2 fold, first extend the hex2 in MES to cover 1byte relative and 4byte relative displacements, incorporate a modified version of M0 and a definition file that should cover the x86 primitives that are essential (it is trivial to add more) <rain1>what about creating elf files? <rain1>so far we have just hard coded a header <janneke>rain1: yes, i'm in a split there too, currently <janneke>mescc now uses hex3 and its own hex3->elf for that, which allows objdump -d and gdb to work <rain1>we definitely dont need a full blown elf creation toolkit, we only need the bare minimum to reach the next bootstrap stage. then we can start pulling in more advanced linkers each time <janneke>everything about this is great, except for i fear we'll be losing the ability to use gdb <janneke>rain1: i guess mescc's elf creation bits are quite minimal, but somewhat bigger than just a header; it fills in the symbol tables <OriansJ>janneke: what has to be there to ensure gdb will continue to work properly? <janneke>OriansJ: sadly i don't exactly know...i was happily surprised when after adding more 'elfiness', symbol tables gdb worked -- possibly we even don't need everything that mescc does now <OriansJ>janneke: perhaps with some experimentation we could discover that answer and then embed that into our build process <janneke>OriansJ, rain1: everything relevant in is mes's module/mes/elf.mes; 300 lines of scheme <janneke>it would be totally acceptable to lose it temporarily <OriansJ>janneke: or I could build something more ambitious <rain1>i'd like to experiment with some of the smaller c compilers <rain1>and see if we could build up to tcc using smaller steps <rain1>it would be nice to get a sort of 'map' sketched out, showing all the stages of this long bootstarp path <OriansJ>rain1: well in theory we only need to be able to compile MES's lisp interpreter, then MESCC could then do the bootstrapping to TCC and then GCC <OriansJ>janneke: I know I can bootstrap a C compiler in assembly to the level of CC500 in about 3-5 months of work <OriansJ>in the mean time we can further simplify MES's bootstrap <OriansJ>M0 macro output and similar enhancements should allow us to convert the bootstrap problem into several easy to implement and fun pieces <janneke>i do not have a good idea about how cc500 or 8cc and the effort it takes to write something like that relates to mescc, or to our goal of closing the bootstrap loop to gcc... <janneke>closing stage0->MES's bootstrap would be great, we're getting close i think <OriansJ>janneke: ok, lets take this one step at a time. How about I build some fun examples for you to play with and see if you like them. <quiliro>booted a guixsd 0.13 installation usb <quiliro>and tryed to do a guix system reconfigure /mnt/etc/bare-bones.scm <quiliro>but gave me the error cannot build derivation <quiliro>it may be because it has not network connection <quiliro>/gnu/store/...-grub-2.02/lib/grub/x86_64-efi/modinfo.sh does not exist. Please specify --target or --directory. <quiliro>please give it a look...i will get a connection tomorrow and download all mail <rain1>i just heard about this, it looks very relevant