**** BEGIN LOGGING AT Mon Nov 18 02:59:59 2013
Nov 18 04:09:48 <builder> build #11 of mxs is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/mxs/builds/11
Nov 18 09:08:36 <blogic> tripolar: and the rootfs is in sync with the romfs ?
Nov 18 09:08:56 <blogic> because a "does not work" is no usefull at all
Nov 18 09:09:08 <blogic> you need to at least try to make an effort to make a bug report
Nov 18 09:09:14 <blogic> any piece of info can be usefull
Nov 18 09:10:57 <tripolar> blogic: the rootfs is mounted but ubus dies and it doesn't bring up the interfaces
Nov 18 09:11:04 <tripolar> i connected a serial console
Nov 18 09:11:27 <tripolar> and as logread is also using ubus i just get an error that it can't connect to ubus
Nov 18 09:12:50 <tripolar> using just squashfs and jffs2 works without a problem
Nov 18 09:14:03 <blogic> hmm
Nov 18 09:14:08 <blogic> because ubus should auto restart
Nov 18 09:14:12 <blogic> that works for me at least
Nov 18 09:14:16 <tripolar> blogic: reverting 38822 fixes the problem
Nov 18 09:14:21 <blogic> no it does not
Nov 18 09:14:32 <blogic> i vloses the eyes and reverst back to an old version with less features
Nov 18 09:14:39 <blogic> but it certainley is not the fix
Nov 18 09:14:54 <blogic> the fix is the patch that fixes the crash reason
Nov 18 09:15:05 <tripolar> yeah i know, but at least i could track down which commit introduced the error
Nov 18 09:15:10 <blogic> so, is your rootfs in sync with the romfs ?
Nov 18 09:15:19 <tripolar> yes
Nov 18 09:15:32 <tripolar> i use
Nov 18 09:15:33 <tripolar> config 'mount' option  target  '/' option  uuid    'c1231a56-bdf9-45b9-9838-21b60138712d' option  enabled '1'
Nov 18 09:15:55 <tripolar> before i copy over all files from squashfs to the device
Nov 18 09:16:03 <blogic> can oyu manually start ubus =3;2~
Nov 18 09:16:05 <blogic> can oyu manually start ubus ?
Nov 18 09:16:11 <blogic> /sbin/ubus
Nov 18 09:16:17 <tripolar> i don't havve the serial consolte connected anymore
Nov 18 09:16:26 <blogic> well, please rreattach it
Nov 18 09:16:37 <tripolar> and i don't have the device here right now
Nov 18 09:16:40 <blogic> ah ok
Nov 18 09:16:44 <tripolar> i can test it in the evening
Nov 18 09:16:49 <blogic> ping me when you have it setup again pleae
Nov 18 09:16:59 <tripolar> okay this will be in 8-10 hours
Nov 18 09:17:02 <blogic> sure
Nov 18 09:17:06 <blogic> i am not going anywhere ;)
Nov 18 09:17:11 <tripolar> :)
Nov 18 09:17:50 <tripolar> blogic: what das the "=3;2~" mean?
Nov 18 09:18:53 <tripolar> blogic: just restartin didn't help as i get something like - can't connect to socket
Nov 18 09:19:01 <tripolar> get=got
Nov 18 09:36:40 <OpenWrt-Commits> blogic r38844 trunk/target/linux/ramips/dts/MT7620a_MT7530.dts * ralink: make usb work on the mt7530 eval kit
Nov 18 09:37:05 <OpenWrt-Commits> blogic r38845 trunk/target/linux/ramips/base-files/etc/uci-defaults/02_network * ralink: make all none 3x5x boards default to a vlan1/2 setup
Nov 18 09:37:15 <OpenWrt-Commits> blogic r38846 trunk/target/linux/ ramips/mt7620a/config-3.10 ramips/patches-3.10/0250-nand-7620.patch * ralink: add mt7620 nand driver
Nov 18 09:37:23 <OpenWrt-Commits> blogic r38847 trunk/target/linux/ramips/patches-3.10/999-mt7620n.patch * ralink: improve mt7620n detection
Nov 18 09:37:32 <OpenWrt-Commits> blogic r38848 trunk/target/linux/ ramips/dts/MT7620a_V22SG.dts ramips/base-files/lib/ramips.sh ramips/image/Makefile * ralink: add support for ralink mt7620 nand eval board
Nov 18 10:22:53 <builder> build #445 of orion is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/445
Nov 18 12:01:18 <OpenWrt-Commits> jow r38849 trunk/package/network/config/firewall/Makefile * firewall: optimize DNAT rules and skip invalid rules and redirects (#14485)
Nov 18 12:07:02 <OpenWrt-Commits> kaloz r38850 trunk/target/linux/omap/Makefile * [omap]: make default packages selected for real
Nov 18 13:33:58 <OpenWrt-Commits> nbd r38851 trunk/toolchain/uClibc/patches-0.9.33.2/990-no-stack-cache.patch * uClibc: Deactivate oversized thread stack cache
Nov 18 13:49:35 <tripolar> nbd: hi, do you know who is now responsible for track? wouldn't it be a better idea to only allow bug reports from registered users? as it seems a lot of people are just lazy and don't want to read the documentation
Nov 18 13:50:21 <tripolar> or think we are motivated to implement stuff from "featurewonderland"
Nov 18 13:50:42 <jow_laptop> you cannot cure social problems with technical measures
Nov 18 13:51:00 <jow_laptop> I mean whatever scheme you'll implement in the end you still have to triage tickets
Nov 18 13:52:11 <nbd> i think it's worse to lose useful tickets because of user registration issues than to clean up bogus tickets that are easy to recognize
Nov 18 13:52:40 <nbd> testing is one of our biggest bottlenecks after all
Nov 18 13:53:50 <tripolar> okay
Nov 18 13:56:18 <OpenWrt-Commits> nbd r38852 trunk/package/network/ (6 files in 2 dirs)
Nov 18 13:56:18 <OpenWrt-Commits> hostapd: remove random pool support - the entropy it gathers is questionable and we have better entropy sources on common platforms now
Nov 18 14:12:03 <OpenWrt-Commits> nbd r38853 trunk/include/cmake.mk * cmake.mk: fix support for ccache
Nov 18 14:56:36 <DonkeyHotei> blogic: you asked for a patch that sits on top, i sent it
Nov 18 15:02:54 <builder> build #409 of rb532 is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/409
Nov 18 15:06:28 <builder> build #409 of ppc44x is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/409
Nov 18 15:14:42 <builder> build #446 of orion is complete: Failure [failed compile_8]  Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/446
Nov 18 15:23:30 <tripolar> hi
Nov 18 15:23:40 <tripolar> blogic: i'm currently flashing the latest firmware - are you here?
Nov 18 15:26:29 <tripolar> blogic: this is the system without hd during firstboot
Nov 18 15:26:29 <tripolar> http://paste.debian.net/66430/
Nov 18 15:31:47 <tripolar> blogic: this with the hd attached
Nov 18 15:31:50 <tripolar> http://paste.debian.net/66433/
Nov 18 15:32:33 <tripolar> the bridged devices are not created and therefore no interface has an ip address
Nov 18 15:38:17 <tripolar> logread gives - Failed to connect to ubus
Nov 18 15:42:33 <tripolar> [florian]: hi, you commented on this bug 8 years ago you will add traceroute6 to openwrts default config - is still valid or can i close the bug?
Nov 18 15:42:34 <tripolar> https://dev.openwrt.org/ticket/369
Nov 18 16:32:33 <builder> build #328 of iop32x is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/iop32x/builds/328
Nov 18 16:33:03 <jow_laptop> tripolar: the dial on deman stuff is indeed completely broken since the switch to netifd
Nov 18 16:33:16 <jow_laptop> technically not unsolvable but rather complex to implement
Nov 18 16:49:17 <tripolar> okay: okay
Nov 18 16:49:19 <tripolar> jow_laptop: okay
Nov 18 16:49:50 <tripolar> blogic: i found the error it seems that
Nov 18 16:49:50 <tripolar>         option log_file /var/log/messages
Nov 18 16:49:50 <tripolar>         option log_size 16000
Nov 18 16:50:07 <tripolar> in /etc/config/system are triggering the ubus crash
Nov 18 16:50:21 <tripolar> removing them brings the interfaces up normally
Nov 18 16:51:41 <blogic> ok
Nov 18 16:51:45 <blogic> let me look into it
Nov 18 17:24:05 <tripolar> blogic: it seems the problem is - that i removed the symlink from /var to write to actual device to keep the logs - when i don't remove the symlink it works
Nov 18 17:24:56 <blogic> ah
Nov 18 17:25:04 <blogic> that would also kill ubus
Nov 18 17:25:08 <blogic> thx, i will have a look into it
Nov 18 17:25:47 <tripolar> blogic: i would have to copy over the content of /tmp/run to /var/run?
Nov 18 17:26:29 <blogic> let me fix it in the code
Nov 18 17:27:42 <tripolar> blogic: maybe using /dev/shm for this? even /tmp could get umounted if the user wants to keep tmp over reboots
Nov 18 19:29:22 <v0n> I'm adding support for a AM1808 (TI DaVinci DA850 type) based board. I'm adding a da850 generic target to target/linux. Is is worth it to submit it to OpenWRT mainline?
Nov 18 19:30:40 <[florian]> sure
Nov 18 19:31:21 <KanjiMonster> depends on whether you plan to maintain the target
Nov 18 19:32:01 <v0n> KanjiMonster: what do you mean?
Nov 18 19:32:25 <groz> do you plan to submit and forget, or, submit and then keep it up to date ?
Nov 18 19:32:37 <KanjiMonster> v0n: staying current with the kernel, sending updates, fixing bugs found by others etc
Nov 18 19:43:13 <tripolar> groz KanjiMonster [florian] what's your opinion to 4 year old feature requests - should we really have them open? i think we should close them - some of them are even accepted but nothing happend for years
Nov 18 19:43:48 <[florian]> tripolar: depends if they are still relevant no?
Nov 18 19:43:59 <groz> 4 years old, it's either been done a long time ago, or, nobody cares
Nov 18 19:44:15 <tripolar> some of them are for dev boards - i mean who needs 4-6 year old dev boards - and who will maintain them?
Nov 18 19:44:38 <tripolar> and even port the 2.[4-6] patches
Nov 18 19:45:15 <tripolar> i would propse - i we close such old stuff and users can create new bug reports if these bugs are still valid
Nov 18 19:45:21 <jow_laptop> tripolar: I think we should mostly reject feature requests through tickets anyway, unless its a real important thing
Nov 18 19:45:48 <jow_laptop> like "add power management because otherwise my hardware burns"
Nov 18 19:46:04 <tripolar> jow_laptop this is not a feature this is a bug ;)
Nov 18 19:46:10 <jow_laptop> exactly
Nov 18 19:46:51 <jow_laptop> but for the sake of the arguments replace burns with "reduces lifetime" or something else not being an immediate showstopper
Nov 18 19:46:53 <groz> I have only ever submitted one feature request, and, that one was addressed in R00001
Nov 18 19:46:59 <groz> which I committed some years back
Nov 18 19:47:41 <groz> that request was 'boot with a telnet prompt, network up and nothing else' on a wrt54g
Nov 18 19:48:34 <groz> I suspect tho, over the years, svn numbers got reset to zero, and that was long lost
Nov 18 19:49:02 <DonkeyHotei> groz: i got a wrt54gl v1.1 and a wrt54gs v1.0 dropped on my doorstep a few months ago. are they good for anything?
Nov 18 19:49:22 <groz> I gave one to my dad when he was here visiting last week
Nov 18 19:49:41 <groz> he took it home, plugged it in, uses it as a router in his seniors home
Nov 18 19:49:44 <groz> works fine for his ipad
Nov 18 19:50:02 <groz> he's got a 10mbit internet connection, so, no need for anything more powerful
Nov 18 19:50:17 <groz> and I can deal with it remotely for him, from here
Nov 18 19:50:29 <groz> he's 80 , not about to learn how to deal with a wifi router
Nov 18 19:50:35 <jow_laptop> DonkeyHotei: the only good thing about them is the two uarts
Nov 18 19:50:55 <jow_laptop> apart from that nothing in the hardware is special by todays standards anymore
Nov 18 19:51:13 <jow_laptop> the only other plus side I see is that you can run almost any alternative firmware on it
Nov 18 19:51:22 <groz> no, they are 'nothing special', ram and flash constrained, stuck in 2.4 linux land
Nov 18 19:51:24 <DonkeyHotei> might not be special, but useful for anything?
Nov 18 19:51:37 <DonkeyHotei> 32MB ram
Nov 18 19:51:44 <groz> but, his comes up, starts a vpn connection to my place, and, I can deal with it for him, from anywhere
Nov 18 19:51:49 <groz> which makes it most useful for me
Nov 18 19:52:02 <jow_laptop> DonkeyHotei: well they're useful as 11b/g access points
Nov 18 19:52:12 <jow_laptop> or simple vlan switches
Nov 18 19:52:31 <jow_laptop> or vpn entry points (though very slow at that)
Nov 18 19:52:54 <groz> jow:  slow doesn't matter, when internet connection is the limiting factor anyways
Nov 18 19:53:01 <jow_laptop> or as serial console to debrick other routers :)
Nov 18 19:53:17 <jow_laptop> the 2nd uart is useful for that since one does not need to fiddle with the inittab etc.
Nov 18 19:53:38 <DonkeyHotei> i have a usb dongle for that
Nov 18 19:54:17 <tripolar> look at hackaday a lot of people are still using this device for a lot of hacks
Nov 18 19:54:17 <v0n> KanjiMonster groz: I cannot guarantee to "maintain" it, but the thing is we use this SoC on several board
Nov 18 19:54:38 <groz> they make a good 100mbit vlan capable switch
Nov 18 19:55:34 <v0n> btw, I get how OpenWRT works for patches (kind of overlay) but I'm not sure how it works with several kernel config files? what happens if I have config file in the target dir, the subtarget dir and/or the profile dir?
Nov 18 19:55:49 <jow_laptop> v0n: they get merged
Nov 18 19:55:55 <jow_laptop> v0n: subtarget > target > generic
Nov 18 19:56:10 <jow_laptop> most specific overrides less specific
Nov 18 19:57:20 <v0n> jow_laptop: how this "override" works? cp in the kernel dir and `make oldconfig` or something?
Nov 18 19:57:35 <jow_laptop> scripts/kconfig.pl
Nov 18 19:57:50 <v0n> thanks
Nov 18 19:58:41 <jow_laptop> the script simply merges all symbols of the fragments into one monolythic .config which is then expanded with make oldconfig
Nov 18 19:59:40 <v0n> ok that's clear
Nov 18 20:00:15 <jow_laptop> see Kernel/Configure/Default in include/kernel-defaults.mk
Nov 18 20:00:47 <OpenWrt-Commits> nbd r38854 trunk/package/kernel/mac80211/patches/ (10 files) * ath9k: merge a few reset / calibration fixes
Nov 18 20:01:58 <tripolar> blogic: any news by now or something i could test?
Nov 18 20:02:50 <v0n> Can a profile have a config file?
Nov 18 20:03:08 <jow_laptop> no
Nov 18 20:03:24 <jow_laptop> profiles are solely for package selection and maybe image generation
Nov 18 20:03:33 <jow_laptop> if you need a different kernel you need a subtarget
Nov 18 20:03:42 <v0n> ok
Nov 18 20:05:57 <v0n> So with my custom board, if I can keep the target kernel and simply provide a .dts and packages/drivers selection, I should do a profile. Otherwise, if I need a specific kernel, I should do a subtarget. correct?
Nov 18 20:06:07 <jow_laptop> correct
Nov 18 20:06:33 <jow_laptop> unless the changes need can be made generic enough to become part of the overall target kernel
Nov 18 20:08:30 <jow_laptop> but I guess such decisions can be made once there's an rfc patch outlining the require changed
Nov 18 20:08:36 <jow_laptop> *changes
Nov 18 20:10:28 <v0n> jow_laptop: yes, and I my case, this is a customer board with a da850 SoC and we need OpenWRT on it. So the subtarget/profile cannot be make generic
Nov 18 20:10:55 <groz> I would make it a whole new target
Nov 18 20:11:05 <groz> in a case like that, custom board for a customer
Nov 18 20:11:17 <jow_laptop> ok
Nov 18 20:11:28 <groz> and if it's a custom board, that wont ever see wide production
Nov 18 20:11:40 <groz> I'd send the tree to customer, not mainline
Nov 18 20:12:16 <groz> altho if it's just based on a reference design, and will work more or less with anything using same soc
Nov 18 20:12:20 <groz> that may be different
Nov 18 20:12:35 <v0n> I started doing this, but then I figured out that maybe the generic TI DA850/OMAP-L138/AM18x part can be pushed upstream
Nov 18 20:13:50 <v0n> groz: basically, this could work with the TI DA850 EVM (Evaluation Module/board)
Nov 18 20:13:59 <v0n> that's where I see a generic part
Nov 18 20:14:09 <groz> then it's useful
Nov 18 20:14:16 <groz> if it works with the vendors eval board
Nov 18 20:17:16 <groz> woohooo, got cubieboard netbooting now
Nov 18 20:17:18 <v0n> groz: the only thing to add is the MACH_DAVINCI_DA850_EVM symbol for this specific board, so this could be added in a subtarget config file
Nov 18 20:17:39 <groz> yes, that could
Nov 18 20:18:02 <groz> now I have my cubie netbooting with a ramdisk image
Nov 18 20:18:20 <groz> can start looking at what needs done to make various other parts work
Nov 18 20:18:38 <groz> but have to set it aside for now,a nd go do real work for a while :(
Nov 18 20:20:49 <v0n> So I was doing: Target (DA850) > Subtarget (DA850 EVM)
Nov 18 20:21:48 <v0n> I guess for a project, it is better to have a subtarget, so the profiles could be "production", "dev" or "debug" depending on packages you want for these various usages
Nov 18 20:35:50 <groz> has anybody here tried bringing up an octeon build on the ubiquity edge light ?
Nov 18 20:36:22 <[florian]> groz: I think blogic has
Nov 18 20:36:43 <groz> I am just starting to configure a fresh tree, to try
Nov 18 20:36:54 <groz> so, wondering if there are any 'helpful hints' available
Nov 18 20:37:26 <groz> also wondering if trunk, or aa is the place to start
Nov 18 20:38:10 <groz> hehe, and, in a couple hours I'll probably know anyways
Nov 18 20:38:19 <nbd> trunk is the place to start
Nov 18 20:39:01 <groz> I've got a console cable, and it's got removeable storage
Nov 18 20:39:07 <groz> shouldn't be to scary of a process
Nov 18 20:48:02 <groz> nbd:  do you use xcode, or something else for working on stuff ?
Nov 18 20:54:36 <nbd> groz: i use vim
Nov 18 20:54:46 <groz> hehe, ok, most basic
Nov 18 20:55:22 <groz> I'd like to get an environment working with integrated remote debugger, had that working nicely using codeblocks on the linux box
Nov 18 20:55:27 <groz> never succeeded on the mac
Nov 18 20:55:33 <groz> just curious if you use anything like that
Nov 18 20:56:21 <groz> starting a major re-write of some of our astronomy stuff, and, debating how I'm gonna do it
Nov 18 21:01:53 <russell--> emacs ftw, lol
Nov 18 21:02:37 <tripolar> jow_laptop: the too big image you just commented about is due to this limition its hardcoded, i use bigger images here aroung 10mb
Nov 18 21:02:46 <tripolar> see tools/firmware-utils/src/trx.c - #define TRX_MAX_LEN    0x720000
Nov 18 21:03:14 <tripolar> maybe we should make this option at least configureable
Nov 18 21:03:25 <jow_laptop> tp814nd is not using trx images as far as I am aware
Nov 18 21:03:43 <tripolar> ahh okay
Nov 18 21:03:55 <jow_laptop> also a too big trx wouldn't get generated at all
Nov 18 21:04:14 <jow_laptop> he generated a custom image, flashed it and wonders why his runtime changes do not stick
Nov 18 21:04:35 <jow_laptop> typical symptom of having less that four free erase blocks for jffs2
Nov 18 21:05:51 <tripolar> jow_laptop: but still some people reporting errors about the limit in squashfs - how should we handle this requests
Nov 18 21:06:30 <jow_laptop> we could increase the limit and get rid of those reports
Nov 18 21:06:42 <jow_laptop> then deal with the other reports stating that images get generated which are not flashable
Nov 18 21:06:48 <tripolar> :)
Nov 18 21:06:57 <tripolar> this was my first thought :D
Nov 18 21:07:34 <tripolar> so should we close them and say that they have to remove package from the configuration?
Nov 18 21:07:49 <jow_laptop> yes
Nov 18 21:08:05 <jow_laptop> there are only very few models where a larger trx would actually work
Nov 18 21:08:08 <builder> build #422 of uml is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/422
Nov 18 21:08:15 <jow_laptop> the only one I can think of is the wl500gp
Nov 18 21:08:42 <jow_laptop> but this one also only takes larger images via mtd write, the cfe refuses images > 3.5M
Nov 18 21:08:49 <tripolar> i use an image that is ~10mb on a wndr3800 without problems
Nov 18 21:09:14 <tripolar> i mean the complete image has this size
Nov 18 21:09:18 <jow_laptop> but that one does not use the trx format
Nov 18 21:09:34 <jow_laptop> there the limit is solely defined in the image makefile afair
Nov 18 21:09:55 <tripolar> okay good to know
Nov 18 22:01:39 <tripolar> [florian]: is this ticket still valid? https://dev.openwrt.org/ticket/9420
Nov 18 22:25:30 <OpenWrt-Commits> luka r38855 trunk/include/image.mk * image: remove spaces from toupper function
Nov 18 22:25:31 <OpenWrt-Commits> luka r38856 trunk/target/linux/imx6/config-3.10 * imx6: refresh kernel config
Nov 18 22:25:32 <OpenWrt-Commits> luka r38857 trunk/target/linux/ imx6/image/Makefile imx6/profiles/120-gateworks.mk * imx6: add support for more then one nand type per profile
Nov 18 22:25:34 <OpenWrt-Commits> luka r38858 trunk/target/linux/ imx6/image/Makefile imx6/profiles/120-gateworks.mk * imx6: merge all gateworks boards into one profile
Nov 18 22:25:35 <OpenWrt-Commits> luka r38859 trunk/target/linux/imx6/profiles/120-gateworks.mk * imx6: build images for ventana boards that are supported
Nov 18 22:37:28 <groz> hot diggity, I got the edgerouter to netboot an openwrt ramfs image
Nov 18 22:49:16 <DonkeyHotei> tripolar: hackaday doesn't actually have that much for a wrt54g
Nov 18 23:10:19 <tripolar> DonkeyHotei: are you searching the wrong page? http://hackaday.com/tag/wrt54g/
Nov 18 23:11:11 <groz> hehe, love the 'tankrouter'
Nov 18 23:11:38 <tripolar> :)
Nov 18 23:12:21 <DonkeyHotei> tripolar: i looked through all those, and they're all robots and sd cards, pretty much nothing else
Nov 18 23:13:07 <tripolar> DonkeyHotei feel free to come up with new ideas and post them on hackaday :)
Nov 18 23:13:32 <groz> blogic ping
Nov 18 23:13:49 <DonkeyHotei> i was asking for ideas because idk what to do with these things
Nov 18 23:14:09 <tripolar> buiild a remote temperature control
Nov 18 23:14:51 <tripolar> DonkeyHotei: you can heat your apartment on demand with your mobile phone :)
Nov 18 23:18:38 <DonkeyHotei> tripolar: i already have that on a timer and it suffices; i tolerate cold reasonably well
Nov 18 23:19:29 * groz has natural gas fireplace so I dont have to tolerate cold
Nov 18 23:19:56 * DonkeyHotei has natural gas central heating
Nov 18 23:20:04 <groz> it's interfaced with hi tech gadget called a thermostat
Nov 18 23:20:36 <DonkeyHotei> i have a low tolerance for heat, on the other hand
Nov 18 23:21:22 <groz> what part of the world do you live in ?
Nov 18 23:21:29 <DonkeyHotei> san francisco
Nov 18 23:21:33 <groz> cough
Nov 18 23:21:38 <groz> doesn't get cold in sf
Nov 18 23:21:59 <DonkeyHotei> sf is too cold for most people i talk to
Nov 18 23:22:19 <groz> dont even need to own a parka living that far south
Nov 18 23:22:42 <FriedZombie_> I'd rather hook it into the coffee maker :P and then maybe think about tempreature controll
Nov 18 23:23:02 <groz> I have an automatic coffee maker too
Nov 18 23:23:13 <groz> she gets up about half an hour before I do, makes sure coffee is ready
Nov 18 23:23:26 <FriedZombie_> hehe nice :)
Nov 18 23:23:31 <DonkeyHotei> yes, but the rest of california is so much warmer that people coming here just aren't used to the temps
Nov 18 23:25:05 <DonkeyHotei> 75F is my threshold of tolerability for heat, and thankfully it rarely gets that warm here
Nov 18 23:25:44 <FriedZombie_> groz: I wish this was possible :P http://translate.google.com/translate?sl=auto&tl=en&js=n&prev=_t&hl=nl&ie=UTF-8&u=http%3A%2F%2Farchief.retecool.com%2Fsenseo%2F (sorry it was in dutch)
Nov 18 23:29:57 <groz> hehe, I can read the translation, but, probably could do ok on the original too
Nov 18 23:30:46 <DonkeyHotei> i don't have a habit of consuming anything hot in the morning
Nov 18 23:30:50 <FriedZombie_> and the fun thing was it was published as helpdesk article of one of the first internet providers in the nl, and people actually phoned in about it
Nov 18 23:31:01 <groz> no kidding ?
Nov 18 23:31:25 <FriedZombie_> yeah, it was funny as hell. also that's why i remembered it :)
Nov 18 23:32:43 <FriedZombie_> the senseo was new, so was the internet. But I don't think people will fall it nowadays
Nov 18 23:32:59 <groz> you would be surprised what folks fall for these days
Nov 18 23:32:59 <FriedZombie_> *fall for it
Nov 18 23:34:46 <FriedZombie_> I guess
Nov 19 00:05:27 <OpenWrt-Commits> nbd r38860 trunk/scripts/gen-dependencies.sh
Nov 19 00:05:27 <OpenWrt-Commits> scripts/gen-dependencies.sh: prevent zero-length dep.* files from accumulating in tmp/
Nov 19 00:05:30 <OpenWrt-Commits> nbd r38861 trunk/package/base-files/files/sbin/hotplug-call * base-files: add the DEVICENAME variable for hotplug scripts
Nov 19 00:05:34 <OpenWrt-Commits> nbd r38862 trunk/package/system/procd/files/hotplug.json
Nov 19 00:05:34 <OpenWrt-Commits> procd: emit tty events for ttyUSB* even when they come from the usb-serial subsystem
Nov 19 00:11:13 <OpenWrt-Commits> nbd r38863 branches/attitude_adjustment/target/ linux/generic/patches-3.3/890-8250_optional_sysrq.patch linux/generic/config-3.3 * kernel: do not accept sysrq characters via serial port
Nov 19 01:37:00 <OpenWrt-Commits> tripolar r38864 packages/net/openssh/Makefile
Nov 19 01:37:01 <OpenWrt-Commits> [packages] openssh: remove ssh and scp symlinks to dropbear when openssh-client is
Nov 19 01:37:01 <OpenWrt-Commits> installed and create them again when openssh-client is removed and dropbear is installed
Nov 19 01:37:01 <OpenWrt-Commits> Signed-off-by: Peter Wagner <tripolar@gmx.at>
Nov 19 02:52:50 <builder> build #12 of mvebu is complete: Failure [failed compile_4]  Build details are at http://buildbot.openwrt.org:8010/builders/mvebu/builds/12
**** ENDING LOGGING AT Tue Nov 19 02:59:59 2013