[01:32] lilstevie: I'm still losing 12%/hr, it really ought not to be the kb doing that :-/ [02:32] twb: 2% difference really isn't that much [02:32] and probably is the keyboard difference [02:32] OK [02:33] Just sayin, stinks that a kb uses 2%/hr [02:33] btw, earlier installs had a problem where halting (from ubuntu) didn't fully power off the tf, so it drained the battery after a week or so -- does the current prime image (as at a week ago) still have that problem? [02:34] it is still the same image [02:34] and that will always have that problem of if it doesn't shutdown properly that it will drain the battery [02:34] but if you suspend rather than halt, you should get 14 days, but I haven't pushed an image with suspend fix yet [02:37] k [02:37] What I am doing atm is if I won't be using it for a while, I boot into android and then halt from there [02:37] Hopefully that actually results in a proper hard off [02:38] yes that will [02:38] Yay [05:37] lilstevie: hey, is the adbd stuff open-source (client and/or server side)? [05:38] btw for writing your init.d scripts you might want to look at update-metainit or just upstart jobs [05:39] http://paste.debian.net/149355/ before; http://paste.debian.net/149356/ after [05:39] seriously [05:40] "after" is upstart job [05:40] I am sick of people saying "you can do this" or "you can do that" or "you should do this/that" instead of telling me, do it, then contribute [05:40] :) [05:40] so-rry [05:41] This is what happens when you pick a project that weenie end users are attracted to [05:41] if you were writing e.g. a replacement DNS server... [05:41] :-) [05:44] twb: But the thing is, things are so early in development such that such things are not really a priority right now. We are starting to talk about proper Ubuntu integration and getting packages into the archive, but we don't really have the basics sorted yet. [05:44] So whatever works now for testing that is quick and convenient is used. [05:44] Sure thing [05:45] I'm just pointing out stuff as its in front of me [05:45] Back to my question: is adbd free software? [05:46] adbd is part of AOSP yes [05:46] I dunno. [05:46] ah ok [05:47] Goody [05:47] and yeah, everything is quick [05:48] and hacky [05:48] I lived through some of that over on #debian-eeepc too, back when x86 EEEs needed extra magic for various things [05:49] everything is magic here [05:49] Deep magic [05:49] * XorA predicts he will have time to look at private projects in about 2042 [05:49] XorA: that when the gypsy said you'd die? [05:50] when Im 65 and I retire :-) [05:50] heh [05:51] by then things like tegra2 will be as retro as my zx81 [05:52] and I will still be trying to find this damn uart [05:53] Well, think about the oldest chip design you're actively using [05:53] * XorA unfortuneately doesnt yet have a tegra NDA so cant tell you where it is [05:53] There's a purple sparc pizza box in front of me, that's probably 25 years old [05:54] So in 2035ish I could expect to be babysitting tegra2s [05:54] XorA: uh, you know what NDA means, right? [05:54] twb: yes, why? [05:54] If you signed an NDA you *wouldn't* be able to tell [05:55] XorA: and it is the pinout on the board I am trying to find it with, changes vendor to vendor [05:55] NI adam has a really easily accessable one [05:56] twb: they are normally not that secretive, but do give nice easy access to docs [06:06] anyone have any idea why wireless would set the default route to end in .0 instead of .1. result i can access the world, but the local wireless network cannot be seen (ping, nslookup) other than the access point [06:30] MrCurious_: Because your DHCP server is handing out bogus information? [06:35] working with a bud on it, and we just came to that conclusion as no machines on the wireless can ping any other machine on wireless === Jack87|Away is now known as Jack87 [06:53] The NDAs I've signed basically say that you're not allowed to tell anybody anything [07:23] twb: yeah, like even "you may not mention this NDA" [07:23] Yeah [07:23] Although that's more defamation stuff [08:39] Guess what happens without keyboard repeat [08:39] Can't hold ^C to kill a tight sh loop :-/ [10:05] lilstevie: fyi, I think some of the funkiness with the onboard keyboard and holding down the mod keys, is specific to holding down the caps lock key, which I have set to be a control key [10:05] I *think* it's harder to reproduce some of the problems when using the key originally intended to be control [10:23] Just out of curiosity, if you guys don't mind me asking, how's the ARM version going? [10:24] pretty well, the switch to hardfloat has happpened (now it needs to provide stable until feature freeze) so we might drop support for armel [10:36] ogra_: thats a bit much isn't it :p [10:39] lilstevie, hmm ? [10:39] whats a bit much ? [10:39] dropping armel [10:39] the plan is to only support one arm flavour ... and that will likely be armhf by the looks of it [10:40] I see [10:40] 12.04 is an LTS isn't it [10:40] we wont wipe the armel archive :) [10:40] but we wont support it at all [10:40] ah ok [10:40] 12.04 is LTS for all arches but arm [10:41] just wondering cause you know L4T drivers and the likes [10:41] ah ok [10:41] is arm going to end up with an LTS any time soon? [10:41] it might *become* LTS for arm server if we recieve hardware in time [10:41] but thats server only [10:41] ok [10:42] desktop/client will be non LTS .... as well as all the images will [10:42] lilstevie: nvidia can if asked nicely provide armhf drivers if they find your usecase interesting enough [10:42] (though its not like you wouldnt get userspace updates fro free from x86 uploads indeed ;) ) [10:43] xranby: I know that, just that isn't their key build yet [10:43] :) [10:58] What is the status of ARMv6 support at the moment? [10:58] I know it will not be officially supported, but you always mention that you'll not *remove* the support [10:59] WaltherFI: not supported by ubuntu since ubuntu target armv7 [10:59] so If I understand that correctly, there is some sort of compatibility? [10:59] WaltherFI: debian armel work [11:00] WaltherFI: there exist some armv6 chips with thumb2 support that can in theory run some of the programs [11:00] WaltherFI, there is no compatibility and armv6 support isnt planned at all [11:00] with armhf we even move further away from v6 [11:01] since the hardfloat capabilities fully rely on v7 hardware [11:22] So no love for ARM11 that is. [11:23] WaltherFI: there has been no love for arm11 since karmic [11:23] no ubuntu love for the raspberryPI ;( [11:24] RaTTuS|BIG: Sad. Even more sad now that they will release the additional I/O board --> robots! === Jack87 is now known as Jack87|Away [11:26] it's a pity as I run ubuntu on everythign else [well apart from the obigitary windows machines for work] but we'll cope... [11:32] WaltherFI, well, i am telling you the same thing since 3 months, asking the same question over and over will not change reality [11:34] RaTTuS|BIG, if someone provides the resources (build machines, archive space on the servers etc cost a lot of money) and forms a team (a few people that constantly and reliable take responsibility ) to do a v6 port, nobody would stop you doing a community v6 archive ... [11:36] ubuntu did not support v6 since 2 years, that we supported it at all was not by plan but due to that fact that we started off the debian port initially, there was never a plan to keep pre-v7 support [11:38] (and this was communicated at all UDSes and in other public media, its not a secret or anything and never has been) [11:39] if you want to support old arm specs, simply use debian, its not like debian is *that* much different from ubuntu [11:44] ogra_: I'm sorry if I sound repetitive - I just wanted to know what is the level of compatibility, as there have been mentions about the support being 'dropped but not removed' [11:44] armel wont be removed [11:44] but nothing changed beyond that [11:45] And what is the status of armel at the moment? Do even the very essential packages build at least? [11:46] armel wasnt touched much this release, its the same as in oneiric [11:46] ogra_ - yeah it's something I may do .... anyway let see what my work load is in the new year ;-p [11:46] our focus was on building armhf [11:47] (which took a team of ~five people working full time constantly on it for a few months ... just to give you an impression how much work it is to change a port ... if someone wants to do v6 that will be similar) [11:47] So - does oneiric work then with armv6? Is it installable, that is [11:48] WaltherFI, you ask the same thing all the time ... ubuntu didnt support v6 since two years and wont support v6 in the future [11:49] if someone wants to do a community port and will pay the money for the resources too, a v6 port could happen but i wouldnt count on it [11:50] ogra_: I understand that there is no support, but I'm trying to ask about the level of the armel as it has been left; i.e. even though the support has been removed, what is the level of the last version you have touched [11:50] I'm sorry if I'm beginning to annoy you, sincerely [11:50] honestly* [11:51] (instead of paying money to have resources in the ubuntu infrastructure you can indeed run your own datacenter somewhere else, doesnt need to be money, but you will need teh resources) [11:51] I am just trying to figure out whether the said community project would have to be started from the beginning or do you have something done from the times it was supported [11:51] WaltherFI, as i said, armel didnt (and likely wont ever) change ... its v7 only [11:52] Ah, I'm sorry, I've somehow read your responses as there would have been support at some point, back the said two years ago or so [11:52] for starting such a port you would have to take armel, switch compiler defaults and rebuild the whole archive in the right order [11:52] and then fix all build failures (which can be 100s) [11:53] there was support for v6 three years ago when we pulled the arm port from debian [11:53] Sure, I understand that porting it would require a lot of resources [11:53] that support was never meant to stay and was dropped two yeras ago [11:54] and I appreciate all the work you've done for the armv7 support [11:54] it was just out of technical reasons that v6 was there at all [11:54] since we didnt want to directly switch to v7 when pulling from debian [11:55] Ah, so there is something that has been done already - is the work you did for building armv6 back then saved somewhere or is it deleted? [11:55] it happened six releases ago, its gone [11:56] Thank you, that was the information I was looking for. Sorry for this [11:56] jaunty was supporting v5, karmic was then switched to v6, with lucid we didnt the full switch to v7 [11:56] old release are somewhere on the web [11:56] s/didnt/did/ [11:56] right, there is the old-releases.ubuntu.com archive [11:56] that should have jaunty and karmic [11:57] Nice! I'll take a look at that then [11:57] that wont gain you anything if you want to be up to date though [11:58] just taking the existing armel port and re-rolling it somewhere is likely less work [11:58] all the SW in jaunty is long outdated [11:59] mmhmm [15:50] im trying to get ubuntu onto netbook with800 mhz telechip processor [22:38] infinity, do you think this would suffice to force the build ith gcc 4.5 ? http://paste.ubuntu.com/772746 [22:39] I am now trying locally with a cross build [22:39] the issue with non-booting ac100 kernel goes away if built with 4.5 vs 4.6 [22:39] it worked for me because I had not dist-upgraded yet, whereas the buildds had 4.6 already [23:02] janimo: *blink* [23:02] janimo: What do you mean "not dist-upgraded yet"? gcc-4.6 was the default in oneiric too. [23:03] janimo: And if there are bugs being exposed by 4.6, we should fix them, not paper over them. [23:03] infinity, not dist-upgraded from 4.6.1 to 4.6.2 gcc-arm [23:03] The 4.6.1 build worked too [23:03] I just tried with 4.5 now. So yes, the problem can be narrowed down maybe [23:04] janimo: Trying to narrow it down would be nice... [23:04] infinity, we should fix them indeed, but with the pace bugs get tracked down and fixed in gcc we may not get new kernels for a while [23:04] infinity, the fact that the machine shows the toshiba logo and does not boot makes it hard to debug [23:05] It's less likely to be a gcc bug and more likely a bug in your source tree, to be honest. [23:05] Forcing 4.5 is fine for now, though, since it's only a universe kernel. :/ [23:06] infinity, you mean a bug which building with 4.5 manages to be avoided? [23:07] We had a similar case with QT earlier this year. A volatile added made it work when built with 4.5 too but would only work with 4.4 otherwise [23:07] janimo: There were lots of sketchy bugs fixed in the kernel over the last couple of years to make it happier with 4.6. [23:08] janimo: Non-mainline trees often repeat the mistakes already learned in mainline, sadly. [23:09] (In fact, didn't we fix some ARM-specific kernel bugs just last cycle that people thought were GCC-related?) [23:09] Something about misaligned structs or some such. [23:09] Old person memory not working well here. :P [23:10] I am not familiar with kernel work from last cycle [23:10] Maybe I'm confusing the kernel with something else. [23:10] I'll see if there's some new warnings in the 4.6 build vs the 4.5 one [23:11] It's my vacation, I don't have to be smart. [23:11] But if you want to upload with a build-dep on 4.5 for now, go ahead. Just remember you've done so, cause we should fix it. [23:11] I honestly wish gcc stopped being upgraded besides bugfixes for a while and let apps go ahead [23:11] (And test your fix in a clean chroot to make sure it does what you think it does) [23:11] infinity, yeah, I'd remember, it is not many packages that I change to explicitly use another gcc :) [23:12] infinity, your memory is fine there were some weird packed structs in ehci code in the kernel that did not work with 4.6 [23:12] infinity, does debuild work with cross chroot? [23:12] janimo: I dunno. I don't cross compile anything. [23:13] jcrigby: So, fair chance we're seeing something similar in the ac100 tree. [23:14] jcrigby: Also, hey! [23:14] jcrigby: Any plans to get linaro-lt-mx5 updated to support armhf before Christmas? [23:15] I knew I should have remaind quiet [23:15] * infinity laughs. [23:15] when I think about that I think I should also move to newer kernel and that is more work [23:15] jcrigby: I don't care too terribly much, I'm off until Jan 3. [23:16] jcrigby: But the earlier we have everything working on armhf, the better. [23:16] so is same kernel as you have now just with armhf an ok first step? [23:16] if so easy [23:17] jcrigby: Yup. [23:17] ok then I am commited [23:18] jcrigby: A second step would be to talk to markos about having an mx5 that we know works on mx53-loco and both efika platforms. No pressure. ;) [23:18] (Cause I still intend to do hybrid boot media) [23:19] swell [23:23] janimo, so does cross building kernel work for you now, including tools? [23:24] jcrigby, no, I did not get around to trying tools yet since other issues popped up [23:24] like the kernel not booting at all [23:24] jcrigby, I learned how to cope with ABI bumps though. more or less [23:24] ok, I understand that would be a bigger issue [23:26] oh, good. That hurt my brain for a long time. === Crisco is now known as Crismas