<wolfspraul> xiangfu: I think I traced the python-sip problem down
<wolfspraul> in packages/python-sip/Makefile, there is a HOST_FPIC variable
<wolfspraul> it is dereferenced there with $(HOST_FPIC), but never set
<wolfspraul> maybe it was introduced in a later backfire revision, or in trunk?
<xiangfu> wolfspraul: let me check.
<wolfspraul> it brings us back to the old problem that the feeds are not in sync with the main OpenWrt tree
<wolfspraul> also (unrelated), maybe we should sync the tracking_backfire branch every 2 weeks or so? I think we should probably have a fixed time interval.
<xiangfu> wolfspraul: the 'packages' is not in feeds.
<wolfspraul> hmm, OK
<wolfspraul> then it can neither come from a feed problem nor from infrequent tracking_backfire updates :-)
<wolfspraul> HOST_FPIC should be set to -fPIC
<wolfspraul> or in that Makefile, we should replace $(HOST_FPIC) with just -fPIC
<wolfspraul> I did a grep over all feeds and packages, and nobody else is using HOST_FPIC
<xiangfu> wolfspraul: you compile today? got those error.
<xiangfu> wolfspraul: the build host compile fine in 1124.
<xiangfu> wolfspraul: sorry my bad. the python-sip is in feeds.
<xiangfu> wolfspraul: I grep all git source code. there is no HOST_FPIC either.
<xiangfu> wolfspraul: ok. the HOST_FPIC is define in 'trunk' rules.mk:50:HOST_FPIC:=-fPIC
<xiangfu> wolfspraul: 'backfire' upstream also no HOST_FPIC defined.
<wolfspraul> hmm
<wolfspraul> OK
<wolfspraul> so for now I will just export HOST_FPIC=-fPIC manually
<wolfspraul> even if the feature of tagging feeds is added to OpenWrt, we would still want to uptick them and run into a problem like this
<wolfspraul> I guess it's unavoidable ;-)
<qi-bot> [commit] Xiangfu Liu: add fw_setenv_default for set all u-boot variable to default http://qi-hw.com/p/openwrt-xburst/49f1bbf
<xiangfu> wolfspraul: I got an error when I "git push" : hooks/post-update: line 24: echo: write error: Broken pipe
<xiangfu> wolfspraul: where is the hooks ? maybe I  check that a little.
<wolfspraul> xiangfu: hmm
<wolfspraul> I rebooted fidelio a few hours ago (after a dist-upgrade), and sometimes the NFS share on turandot gets stuck with a 'stale NFS file handle'
<wolfspraul> maybe it's that
<wolfspraul> I will look into it
<wolfspraul> xiangfu (in absence) I remounted the nfs share, let's see on the next commit whether the broken pipe error is gone...
<wolfspraul> xiangfu: (repost) I remounted the nfs share, let's see on the next commit whether the broken pipe error is gone...
<xiangfu> wolfspraul: thanks.
<wolfspraul> xiangfu: I have a question/idea. see http://en.qi-hardware.com/wiki/Building_Software_Image#Feeds
<wolfspraul> to update the feeds, we recommend to run "scripts/feeds update -a && scripts/feeds install -a"
<wolfspraul> but in the root Makefile, there is a package/symlinks target that does exactly the same thing
<wolfspraul> so we could also recommend to run "make package/symlinks" instead
<wolfspraul> there are several pros and cons
<wolfspraul> package/symlinks is cleaner/shorter, and if some of the parameters of scripts/feeds change it will be updated
<wolfspraul> on the other hand package/symlinks is slower, because it will run through the whole openwrt prerequisites stuff
<wolfspraul> also it will hide some of the stdout output you see when running scripts/feeds directly
<wolfspraul> however, bottom line, on the wiki page I still think we should change it to "make package/symlinks"
<wolfspraul> what do you think?
<viric> wpwrak: I tried -p and -fp, no effect. But I'm using sysvinit 'halt'; I don't know what is there in openwrt
<xiangfu> agree.
<viric> larsc: do you know if there is anything special to poweroff the nanonote? sysvinit halt does not work for me, and busybox halt either
<xiangfu> wolfspraul: "run through the whole openwrt prerequisites stuff"  is better.  if there is no ".config" it's will start the "menuconfig" etc..
<xiangfu> wolfspraul: I found we can add "V=99" to "make package/symlinks" but it's give too much "WARNING ..." which is not good.
<xiangfu> wolfspraul: so just ""make package/symlinks"" is better.
<wolfspraul> xiangfu: hmm. if make package/symlinks checks the config, then on the wiki page we have to move the Feeds section after the Configuration section
<xiangfu> wolfspraul: yes.
<wolfspraul> I'll edit the page, you check whether you like it :-)
<kyak> it says on wiki that the release is not tagged
<kyak> but it is tagged now?
<wolfspraul> done
<wolfspraul> don't know the wiki needs lots of updates :-)
<wolfspraul> one thing I am planning to add is a little table for each configuration file to list disk space requirements and build time (on a given reference system)
<wolfspraul> because for minimal, xbboot, full_system or all_packages those will be dramatically different
<wolfspraul> tuxbrain: welcome back! :-)
<wolfspraul> good morning!
<tuxbrain> hehehe I miss you all too :)
<wolfspraul> how are the NanoNote sales?
<wolfspraul> mine are super low, maybe 2-5 / week
<tuxbrain> not espectacular but not bad as always, mmm same ratio aprox
<wolfspraul> ok, not bad, at least a few people discover the gem once in a while :-)
<wolfspraul> give me the chance to do stellar customer service for each one :-)
<tuxbrain> hehehe that's right :), at least we have achieve one thing, that any costumer is complaining, that's a real good achievement :)
<xiangfu> kyak: Hi.
<xiangfu> kyak: when I start the "ash(default)" in gmenu2x , I always got "sh: can't access tty; jo..."
<xiangfu> kyak: and I found this: http://www.busybox.net/FAQ.html#job_control
<xiangfu> kyak: which "exec </dev/tty1 >/dev/tty1 2>&1" make the warning gone.
<wolfspraul> tuxbrain: did you see the Milkymist One wood case roh made?
<wolfspraul> which case do you like?
<wolfspraul> do you think you can sell the product with a wood case?
<wolfspraul> roh is experimenting with an acrylic case next, and some other improvements (stability, labels, microphone, IR receiver, etc)
<tuxbrain> uff, electronics and wood.... did it pass any CE certificate???
<wolfspraul> but in the end your opinion matters because you represent customers
<wolfspraul> yeah that's the next question
<wolfspraul> in order to avoid CE/FCC, can we sell it as a kit?
<wolfspraul> so we put the bare board, plus some 'ikea style' stuff into the box
<wolfspraul> I'm wondering what this would mean in terms of CE/FCC.
<tuxbrain> not bad idea, I will ask victor to take a look at it, he is more used on that matters
<wolfspraul> when Asus sells bare mainboards, what certs do they pass?
<wolfspraul> can you look at the box of a bare mainboard sold in Spain, and let us know whether they have anything in the direction of CE/FCC?
<tuxbrain> ok I will
<wolfspraul> great, thanks
<tuxbrain> but whatever what is the cost of the case? aprox?
<tuxbrain> and how the linux port is going on?
<wolfspraul> cost of the case not known yet
<wolfspraul> the first wood one was ca. 20 EUR material cost
<wolfspraul> 12 EUR for the laser cutter, plus the wood
<wolfspraul> roh's time was for free :-)
<wolfspraul> now roh will experiment and improve some more, acrylic, etc.
<wolfspraul> he is hoping to sell them, and I am 100% willing and ready to buy what he produces
<wolfspraul> acrylic is more expensive than wood
<wolfspraul> but there are many unknowns at this point
<wolfspraul> because so many things in the case need to be improved, so it's not clear what the laser-cutter time will be in the end
<wolfspraul> and whether it can be optimized
<wolfspraul> or whether other production techniques will be added (for example the groove was manually carved out with a screwdriver on the first case)
<wolfspraul> the material cost will change (up or down, when buying larger amounts it may also go down)
<wolfspraul> and roh may need to charge some for his time
<wolfspraul> bottom line: the case will be anywhere between 20 and 50 EUR, my feeling
<wolfspraul> I'm not so much trying to bring this down right now, it's more important to get it done, improve details, optimize the process
<tuxbrain> so , what was the price of production of a MM and the intended PVP?
<wolfspraul> tuxbrain: linux port, well, Takeshi Matsuya keeps hacking, but lekernel thinks it's too early for the Linux kernel right now, and he wants to focus on the VJ application and RTEMS
<wolfspraul> PVP?
<wolfspraul> what is that?
<tuxbrain> sorry is spanish price to public
<kyak> xiangfu: that's an awesome trick!!!!
<wolfspraul> we are planning to sell the Milkymist One boards for 350 USD, if we can add the case I suggest we sell it for 499 USD
<kyak> xiangfu: this message was bugging me..
<wolfspraul> we want to add all sorts of goodies, like power adapter, jtag-serial board, etc. and all this costs money
<kyak> xiangfu: have you tested it? is it enough to start gmenu2x like this, and then all child processes will have the terminal?
<xiangfu> kyak: I just tested. seems not working
<kyak> @IF 2I =I3 2I H5,
<kyak> how do you do it?
<xiangfu> wait. maybe I just tested is wrong.  let me  try again.
<viric> what is milkymist one for?
<wolfspraul> viric: good question!
<wolfspraul> I haven't figured out the one way to describe it yet
<wolfspraul> first it's called an interactive VJ station
<wolfspraul> it's like a computer, but totally geared towards processing audio, video, instruments, lighting systems
<wolfspraul> basically if you would use it as your file server, that's exactly what it is not good at. it's the opposite.
<wolfspraul> at the beginning it will run a real-time kernel, RTEMS, although a Linux kernel port exists already (but not in kernel.org yet)
<viric> it's a nanonote with a dsp?
<wolfspraul> viric: does that make sense so you?
<wolfspraul> oh no
<wolfspraul> :-)
<wolfspraul> first it's not a mobile computer
<wolfspraul> it needs a lot of power, so it has to be plugged into the wall
<viric> close to xue?
<viric> Ah
<wolfspraul> it has no screen, no keyboard
<wolfspraul> just a box
<kyak> who would usually use it?
<viric> if it's interactive, it may have some way to get 'input' from a user...
<viric> Is it termenvox-controlled? :)
<viric> I always wanted an open-hardware termenvox
<wolfspraul> it's a computer, you can telnet into it, or ssh under Linux I would think
<viric> ahh.
<wolfspraul> it's a computer guys
<wolfspraul> of course :-)
<viric> meant to be used through a network
<wolfspraul> sure
<wolfspraul> Ethernet
<wolfspraul> USB
<wolfspraul> microSD
<wolfspraul> all there
<viric> ahh
<wolfspraul> but if you see it as a replacement of your aging NSLU2, that's wrong
<wolfspraul> totally wrong
<wolfspraul> the connectors that make it special, as seen from the outside, are :
<wolfspraul> video in
<wolfspraul> vga out, audio in/out
<wolfspraul> midi in/out
<wolfspraul> DMX512 (3-wire) in/out
<wolfspraul> and the hardware design inside is geared towards processing all that stuff
<wolfspraul> I really need to think of a sentence or two to describe it well...
<kyak> is it used by musicians? or who?
<wolfspraul> used by nobody right now, because it doesn't exist yet
<wolfspraul> who is 'musician'?
<wolfspraul> if you like to play the piano, you probably have no use for it
<wolfspraul> if you are Keith Richards, you probably also have no use for it
<kyak> whos "Keith Richards"? :)
<wolfspraul> but sure, like I said, you can plug MIDI instruments into it, and 'do stuff'
<kyak> i mean, it will be used by whom?
<kyak> i don't really udnerstand
<wolfspraul> Keith Richards is an old rocker (guitarist) from the Rolling Stones
<wolfspraul> VJ station
<wolfspraul> you can process audio and video
<viric> wolfspraul: is it outputting 320x240 video?
<kyak> uh, Rolling Stones i've heard about :)
<wolfspraul> I'm sure it can go much higher
<viric> what is there doing the heavy video processing?
<viric> (electronics)
<wolfspraul> right! good question
<wolfspraul> it's all based around a Xilinx Spartan-6 FPGA
<kyak> process audio and video.. right now i'm thinking about connecting it to a TV.. am i wrong?
<wolfspraul> quite powerful FPGA
<viric> can the fpga be reprogrammed at will?
<wolfspraul> running a GPL licensed CPU design, called... Milkymist! :-)
<viric> ahh
<wolfspraul> 'at will' maybe not yet, but that's one of the exercise to make that more open, yes
<viric> a spartan6 is better than a dsp there :)
<wolfspraul> hmm
<wolfspraul> that's a very good question
<wolfspraul> the two cannot easily be compared like that I think
<wolfspraul> wpwrak could probably give you a better analogy than me
<viric> ok
<viric> I design for spartan3... I know the spartan3 family
<viric> I'm going to get into spartan6 soon
<wolfspraul> a high-end DSP can be geared towards certain things, and manufactured in a high-end process, so then it can probably beat any FPGA at whatever it was optimized for
<wolfspraul> on the other hand an FPGA is programmable logic, so it's much more flexible
<wolfspraul> viric: oh wow. well then you should definitely consider taking a closer look at Milkymist One.
<wolfspraul> check that link I pasted above
<wolfspraul> here it is again
<viric> I'll spam about it among people with free time :)
<viric> thank you
<wolfspraul> that page needs to be MUCH BETTER at explaining what the product is
<wolfspraul> in the first line, first paragraph, etc.
<wolfspraul> but explaining is not so easy, need to zoom out mentally, use the right words to describe it, etc.
<wolfspraul> your feedback is very appreciated
<wolfspraul> we will probably go about marketing it strongly next year (it's not available yet)
<viric> ok
<xiangfu> kyak: I think we should remove the first line in /etc/profile "[ -f /etc/banner ] && cat /etc/banner"
<xiangfu> wait  if we remove the /etc/banner never show up. :(.
<wolfspraul> yes!
<wolfspraul> :-)
<wolfspraul> it's too much clutter
<wolfspraul> I think we should remove the banner entirely.
<wolfspraul> we have way too much text showing up all the time
<wolfspraul> banner, warnings, error messages, what not
<wolfspraul> the less the better, imho
<xiangfu> when we start the 'gmenu2x', it' always try to run "/etc/profile" it make the banner shows too much. which is not good.
<wolfspraul> sure, first remove the banner from /etc/profile - +1 from me
<wolfspraul> after that, delete /etc/banner entirely - +1
<wolfspraul> :-)
<kyak> yeah, perhaps this banner is not necessary in /etc/profile
<qi-bot> [commit] Xiangfu Liu: files: remove display banner in /etc/profile http://qi-hw.com/p/openwrt-xburst/011732f
<wpwrak> viric: (halt -fp) hmm, then busybox is exonerated for once. maybe your kernel just doesn't have the power-off code enabled. i think it lives somewhere in power management.
<viric> so, the kernel has a syscall for poweroff?
<viric> and all userland is expected to call that, right?
<viric> I mean there is a linux-abi defined way of powering off
<wpwrak> viric: yup, linux-*/kernel/sys.c:reboot (and kernel_power_off)
<viric> hm I'll check what I have there.
<viric> thank you!
<wpwrak> it's not so easy :) then you have to trace what machine_power_off does
<wpwrak> but that's at least the abi
<viric> I mean I will read that.
<wolfspraul> xiangfu: for the reflash_ben.sh problem that $? == "8" looks suspicious. Maybe you just try the .ubi whenever the ubi.bz2 wget fails? That would be more common I think...
<wolfspraul> is qi-kernel.git still up to date at all? I'm a bit worried if we leave stale trees around that people will get lost.
<viric> wolfspraul: I'm using the upstream kernel 2.6.35 + openwrt instead of the qi-hardware git; I remember something determined that choose, but I can't remember. Some talks here, I imagine.
<xiangfu> kyak: I just found , the new release in our openwrt-xburst.git openwrt-package.git is not tag. it's a new branch. :(
<xiangfu> wolfspraul: the 'master' branch is totally outdate.
<xiangfu> wolfspraul: others I am not sure.
<kyak> xiangfu: yeah.. isn't it the same?
<xiangfu> kyak: I think not same. at least the type is not same. one is tag another is branch :)
<kyak> xiangfu: i thought that it is the same in terms of git :)
<kyak> a branch is kind of "bookrmark"
<xiangfu> kyak: yes. it's kind of same. but when you use "gitk" "gitg", the display is different.
<kyak> okay..
<xiangfu> kyak: IMO. branch which is develop on it. new feature or less feature.  tag just a "bookmark"
<xiangfu> I just want make less confuse :) we should use tag in release.
<wolfspraul> xiangfu: so who is still using qi-kernel.git ?
<xiangfu> hmm... but for the last release . make it as tag is not easy. since it cherry-pick some commit. :(
<wolfspraul> or should anyone still use it? if not, why don't we delete it?
<xiangfu> wolfspraul: hmm... larsc use that develop the 2.6.36.
<wolfspraul> oh really?
<wolfspraul> well then larsc needs to tell us whether it was just a temporary working repository, or whether there is any future use for it, or in which cases we should direct people to use it, or not use it
<xiangfu> wolfspraul:  then we lost all lars commit history.
<wolfspraul> sure I am not advocating to delete it, I am just trying to understand its function right now.
<wolfspraul> when should someone use it? and how do we maintain it?
<wolfspraul> some people may just find that repository accidentally and basically get 'trapped'
<wolfspraul> and we don't seem to know clearly what to tell people :-)
<viric> specially those expecting the 'master' branch being "the stable kernel"
<wolfspraul> sure
<xiangfu> when we develop patches for openwrt. we may need such a repo.
<xiangfu> I think we can mark it as 'private'
<xiangfu> when we develop kernel with other peoples . we may need such a repo.
<wolfspraul> private is not good
<wolfspraul> we just need good documentation
<xiangfu> if the 'master' branch is auto sync with openwrt. that will be great.
<xiangfu> that is my plan . setup a auto sync in qi-kernel.git.
<xiangfu> I am a little lazy on qi-kernel.git :)
<xiangfu> since I am not using it much
<wolfspraul> we just need to document what it is used for, and what to expect from it
<wolfspraul> no need for 'auto sync', that sounds like asking for a lot of trouble
<viric> xiangfu: well, it's not that easy. 'master' reflects the final source code, while openwrt only has bunch of patches over mainline.
<viric> I don't think it is easy to sync. It's manual work.
<viric> additionally there are "the openwrt patches", and "the patches to make the linux work on nanonote" (generic vs xburst-qi_lb60)
<viric> I imagine larsc tries to make changes so they can go upstream, that is, unrelated to openwrt
<viric> - well, this is the picture I have in mind, that may be wrong, because I'm not doing any kernel development :)
<kyak> xiangfu: set up a sync with qi-kernel.git - good idea!
<xiangfu> we need a repo for co-work in kernel develop. that's why there is qi-kernel.git
<kyak> so that when we build from openwrt-xburst.git, we will get the latest kernel, right?
<kristianpaul> (high-end DSP) i need some for GPS correlation ;-)
<xiangfu> kyak: no.
<xiangfu> it's like : work on qi-kernel.git --> generate patches for openwrt.
<kyak> this is already how it works, i think?
<xiangfu> but at sometime. lars direct generate the patches for openwrt. that's why there are different. then I try to sync the openwrt to qi-kerne.git 'mater' because I am also in kernel develop :(
<xiangfu> because I am slow in kernel develop (sorry for typo)
<xiangfu> it's like  10 commit in qi-kernel.git --> one patch in openwrt. that is the origin plan.
<xiangfu> s/origin/original
<kyak> but since lars is working on 2.6.36, but openwrt is 2.6.32, there is some additional work backporting those patches?
<kyak> i suggest going to 2.6.36 in openwrt-xburst :)
<xiangfu> kyak: maybe. I am not look into the detail.
<xiangfu> kyak: then we far away from 'backfire' :)
<kyak> xiangfu: that's what i was going to say :) let's follow openwrt trunk
<xiangfu> kyak: back later (sorry)
<kyak> xiangfu: np!
<qi-bot> [commit] Xiangfu Liu: new package, tunec, A command line guitar tuner for linux http://qi-hw.com/p/openwrt-packages/1404776
<xiangfu> kyak: Hi I am back.
<kyak> hey xiangfu
<xiangfu> kyak: hmm... about track 'trunk', I am not sure. I think we better track 'backfire' because I guess
<xiangfu> If we track upstream. we may fall into DEBUG OpenWrt.
<kyak> heh
<kyak> guess you are right
<xiangfu> the 'backfire' is their most stable and last release.  then we can focus on NanoNote :)
<kyak> yeah, makes sense
<wolfspraul> and in addition, mirko is holding out the trunk for us
<wolfspraul> he's our trunk pioneer :-)
<xiangfu> I will give up 'private' qi-kernel.git, which is not good. yes we need document the qi-kernel.git well.
<wolfspraul> and he says openwrt trunk can build bootable images for the Ben, and he will continue to watch that that remains so
<wolfspraul> xiangfu: but didn't you say we loose some of larsc history then?
<xiangfu> thanks to Mirko. :)
<wolfspraul> did larsc develop in that qi-kernel.git repository or is the history also elsewhere?
<xiangfu> wolfspraul: in fact, I am not sure. I just check the commit log. I don't know is there some else.
<wolfspraul> xiangfu: when you say 'give up', what do you mean? do you plan to delete it or make it private?
<wolfspraul> if so, you should announce that on the mailing list first, and wait for feedback
<wolfspraul> since I guess some people have started to use that repository as the starting point for their work, and it would be quite unfriendly if it now suddenly disappeared, even if we realized that we need to clean it up, and maybe remove it
<xiangfu> wolfspraul: no. no. I mean we should document qi-kernel.git more. make it clear.
<wolfspraul> yes, for sure
<xiangfu> thinking about if we need sync with openwrt.
<wolfspraul> I don't think so, too much work.
<xiangfu> hmm...
<xiangfu> then we can try remove the 'master' branch. and document qi-kernel.git like:
<xiangfu> "this git is only for xburst cpu upstreaming works. nothing relate to openwrt-xburst.git, please use openwrt-xburst/target/linux/xburst for the last NanoNote kernel"
<xiangfu> (my bad English, maybe someone write a good one :)
<wolfspraul> sure, if that documentation is accurate (I don't know)
<wolfspraul> English is good, start with that
<wolfspraul> we only find out what it's used for if the people that use it start to speak up (like you just did)
<kyak> i silently use it to build latest 2.6.36 for Ben :)
<xiangfu> will modify the desc for qi-kernel.git for now.
<wolfspraul> kyak: have you tried to use the latest kernel.org mainline and see how much is missing?
<kyak> wolfspraul: nope, haven't tryed it
<xiangfu> some more 'Project Summary ' , hope it getting better.
<wolfspraul> looks pretty underground - nice
<xiangfu> there is still some message error message come out in tty1(before we start gmenu2x) ,
<xiangfu> all start with "ALSA lib .... : error ..."
<kyak> ah yeah, remember that...
<xiangfu> kyak: do you know why? how can we track down this error message?
<kyak> xiangfu: not sure.. haven't looked at it closely yet
<kristianpaul> viric: wich spartan3 board do you have? are u coding in verilog?
<kristianpaul> (i wonder if i asked this in the past)
<viric> no, vhdl.
<viric> you did not ask, I think
<viric> I never did verilog. I'm in the old continent :)
<kristianpaul> hehe
<kristianpaul> i did some *very* basic vhdl then discover verilog and start learning about ti
<viric> ok
<qi-bot> [commit] Xiangfu Liu: change the way of check wget error, which is more common http://qi-hw.com/p/openwrt-xburst/d3e685d
<xiangfu> wolfspraul: the " hooks/post-update: ...." message gone.
<wolfspraul> good, thanks
<xiangfu> kyak: will add them message to my TODO list :)
<xiangfu> s/them/those ALSA LIB/
<kyak> xiangfu: great ;)
<lekernel_> roh: hi
<lekernel_> roh: i'm doing a quick presentation tonight at atelier überall (near Schlesisches Tor)- do you have some pics of the acrylic case (or even the case itself :)?
<roh> lekernel i havent done milling yet. and it didnt come out as nice. wrong speed etc...
<roh> have the correct params now (and a process to find them (testpatterns))
<roh> but i need more acryllic and to complete milling. need to build some tool to help me align the lasered parts
<lekernel> ok, i'll take the wooden case then :)
<qi-bot> [commit] kyak: hide warning messages on gmenu2x start http://qi-hw.com/p/openwrt-xburst/ade739d
<qi-bot> [commit] kyak: Revert "hide warning messages on gmenu2x start" http://qi-hw.com/p/openwrt-xburst/f0ca65e
<kristianpaul> kyak: regret? why
<kyak> kristianpaul: when a shell is started afterwards, it's redirected to /dev/null, too
<kyak> must be some other way..
<kristianpaul> ahh
<kristianpaul> :)
<kristianpaul> i wonder if is just a debug parameter in gmenu
<kristianpaul> good openqrt xbusrt finished compilation with on error (btw i was commits from yday not today)
<kristianpaul> is GMT-5 here.
<kristianpaul> wonder if commits are in UTC ;)
<wpwrak> grmbl. this seems to be disk failure season. the one in the pc controlling my lab instruments is making scary noises and now the one in the pc controlling the mill doesn't mount :-(