[06:16] <scientes> http://nullr0ute.com/2012/11/fedora-arm-on-the-google-chromebook/
[06:16] <scientes> I havn't been able to boot anything but precise
[06:16] <scientes> quantal and raring Xorg doesn't load, and when it tries it locks up the computer
[06:16] <scientes> and i get a plymouth error
[06:17] <scientes> i found the plymouth assert that is being triggered, but can't really debug more than that
[07:59] <dholbach> good morning
[08:05] <scientes> morning
[09:12] <marvin24> [16:12:03] <ogra_> infinity, i would go with that too ... but #ac100 would hate us all
[09:12] <marvin24> ^ if chromium is the only reason
[09:12] <marvin24> instead of fixing it
[09:13] <ogra_> marvin24, nah, many packages would benefit from using NEON
[09:13] <marvin24> benchmarks?
[09:13] <ogra_> not idea where they went, we did some in the past
[09:14] <marvin24> using multiarch would be another solution
[09:14] <marvin24> at least for the most important libraries which really care
[09:14] <ogra_> and there are actually some packages that already have runtime switching ... i.e. pixman
[09:15] <ogra_> multiarch would mean to have something like armhf-neon
[09:15] <ogra_> i.e. a full new port just for say 20% of the archive
[09:15] <ogra_> (or probably less)
[09:16] <ogra_> marvin24, we will definitely switch some day. the question is just when
[09:16] <ogra_> there is no more modern armv7 HW that laks NEON
[09:16] <marvin24> I have no problem with this - I just think you should make sure that it give more than 5% for common apps
[09:17] <marvin24> and you may lose support for many embedded processors
[09:18] <ogra_> well
[09:19] <ogra_> if we wanted to be general purpose (embedded, desktop, server etc) on ARM, we would have just gone with armel
[09:19] <ogra_> but we focus on a single platform with only the desktop, mobile and server  perspective atm
[09:20] <ogra_> we never targeted embedded
[09:20] <marvin24> yes, it is of course up to canonical to decide where to make money ;-)
[09:20] <ogra_> (and i personally also dont know and new ARMv7 embedded chip that could currently run ubuntu and has no N|EON)
[09:21] <ogra_> its not a matter of making, but of spending :)
[09:22] <ogra_> having to hack up apps like firefox or chromium with runtime sitches etc costs time and money for creation of that patch and its mainteance
[09:23] <ogra_> note that i would also vote for dropping non-NEON support if i wouldnt work for canonical
[09:24] <ogra_> (and its not something that gets dictated or so, its simply a logical evolution to go along with recent hw changes)
[09:33] <marvin24> I wonder if there is some code to emulate neon in the kernel
[09:33] <marvin24> like no-fpu
[09:40] <infinity> marvin24: neon emulation code in the kernel would be a Bad Idea.
[09:41] <infinity> marvin24: Because then you'd end up trapping attempts at run-time detection, and run neon code when you should be falling back.
[09:42] <infinity> marvin24: As for libraries, one doesn't need multiarch, glibc hwcaps already handles neon just fine (do an LD_DEBUG=libs when running a binary and see it search neon directories on your neon-capable CPU, and not on one that isn't).
[09:43] <infinity> marvin24: But it's usually applications that are the big offenders here and we waste a lot of time on, not libraries.
[09:49] <marvin24> infinity: ok, maybe those apps could be blacklisted somehow on non-neon platforms
[09:50] <marvin24> if there is some mechanism already
[09:50] <infinity> marvin24: There isn't, and you wouldn't want that, given that they comprise the two major web browsers, and a bunch of fun media things.
[09:51] <marvin24> I still wonder where the problem is with neon in apps
[09:51] <marvin24> some hand-optimization code?
[09:51] <infinity> (The status quo right now of patching those projects to tear out neon-by-default works fine, but it's non-trivial to maintain when upstream breaks it differently every 3 weeks)
[09:52] <infinity> Sometimes it's hand-optimised code with broken (or non-existant) fallbacks, so we get to fix the fallbacks too.
[09:52] <infinity> Sometimes it's upstreams assuming that v7 == neon, and setting a bunch of compiler flags they shouldn't.  Easy enough to back out, but a non-trivial effort to keep vigilant for.
[09:53] <marvin24> ok, that's just really sad ...
[09:53] <infinity> Sad that I don't want to deal with the mess, or sad that upstreams suck?
[09:53] <infinity> The former is just pragmatism, but I entirely agree with the latter.
[09:54] <infinity> And I yell at them every time I have to fix something.
[09:54] <infinity> But some just never learn.
[09:54] <infinity> And it's tiring.
[09:54] <ogra_> marvin24, its not like we will switch next week ... but along the way to 14.04 it will happen
[09:55] <infinity> Well, there's "will happen" and "will happen", too. :P
[09:55] <marvin24> infinity: it is sad you need to drop non-neon because of broken apps - and not for performance reasons
[09:55] <infinity> I don't intend to flip on -mfpu=neon as a compiler default.  The auto-vectorization code, at last glance, was actually pretty lousy.
[09:55] <infinity> But "not bothering to revert every silly upstream assumption" may happen at some point.
[09:56] <infinity> marvin24: Well, it's *also* for performance, to be fair.  That's just not my primary concern.  It may be for others.
[09:56] <marvin24> ogra_: there are other distros of course - I will always find a way to boot the latest kernel ;-)
[09:56] <ogra_> indeed
[09:56] <infinity> marvin24: precise userspace is supported for another 4+ years, still.  No reason to not be booting the latest kernels there. :P
[09:57] <ogra_> note that we arent enforcing non-neon (as infinity said above) but will at some point stop to apply hacks
[09:57] <ogra_> you could try to form a community team to take care of the patches ;)
[09:57] <infinity> Now, I'll revisit the -mfpu=neon statement if the auto-vectorizer in gcc-4.8 isn't crap.  I haven't had time to benchmark.
[09:57] <infinity> But for now, it's hand-tuned or GTFO, as far as getting performance from NEON.
[09:58] <marvin24> the simplest solution would be to upstream the "hacks"
[09:58] <ogra_> which is whats being tried since 4 years
[09:58] <marvin24> this way you wouldn't have to put more efforts in fixing it
[09:58] <infinity> And, if people were willing to put the effort into making every hand-tuned app have proper runtime detection and fallbacks, I'd happily even help push those patches upstream.
[09:59] <infinity> marvin24: Upstreaming the compiler assumptions tends to fall on deaf ears.
[09:59] <ogra_> awwww
[09:59] <infinity> marvin24: Upstreaming fixes to hand-tuned code usually goes over quite well, but in projects like libv8, they just move so quickly that they break three new things after we fix one.
[09:59] <ogra_> upstream kills pm-utils for systemd
[10:02] <infinity> marvin24: To be very, very clear here, if there was a compelling movement from various people to make sure this stuff always worked correctly, I wouldn't have any problem whatsoever with keeping the baseline at v7/no-neon forever (though, "correctly" would also mean that anything with neon code should actually RUN that neon code on neon CPUs, so proper runtime detection, not compile-time crippling, etc)
[10:02] <infinity> marvin24: But I've yet to get that sort of commitment from, well, anyone.  And it's not something we can sink the resources into.
[10:03] <marvin24> infinity: ok, ok - I got it
[10:04] <marvin24> just wanted to cry a bit about it
[10:05] <infinity> Well, it hasn't happened yet. :)
[10:06] <infinity> I could be talked down from this position too.
[10:07] <infinity> If someone puts some solid effort into upstreaming proper runtime detection into chrome/firefox, thus easing the burden on our security team, etc, those are the two biggies.
[10:07] <infinity> And while I don't like having to hack and slash at other minor packages, they're also less likely to "matter" if they're broken, and some keener can fix them when they notice.
[10:19] <marvin24> infinity: thanks for you efforts!
[11:09] <ogra_> hrw, do you have suspend working on your cb ? if so, how ? i get kernel messages that it couldnt stop some tasks if i try here
[11:10] <hrw> ogra_: kernel in NEW queue has suspend working
[11:10] <ogra_> how do i install that ?
[11:10] <ogra_> do we have some howto ?
[11:10] <hrw> grab it from new and build?
[11:10]  * ogra_ still runs the original cros one
[11:10] <ogra_> hrw, heh, i know how to build it ... but lack the bits flash-kernel would do with the binary
[11:11] <ogra_> where do i put it
[11:11] <ogra_> (and how)
[11:14] <hrw> ah, signing etc
[11:14] <hrw> w8 half hour - meeting now
[11:14] <ogra_> well, signing and i have no clue where i should put it
[11:14] <ogra_> ok
[11:14] <ogra_> no hurry at all
[11:15] <ogra_> i'm not in urgent need of suspend :)
[12:24] <ogra_> http://paste.ubuntu.com/1639292/
[12:24] <ogra_> infinity, ^^^ does that look ok to zou ?
[12:24] <ogra_> *you
[12:25] <infinity> ogra_: No.
[12:25] <infinity> ogra_: prior_version should be the one right before the one you're doing.
[12:25] <ogra_> so 0.52 ?
[12:26] <infinity> ogra_: 0.52 is what you're doing now, no?
[12:26] <ogra_> nope. 53 is
[12:26] <ogra_> havent run dch yet
[12:26] <infinity> Ahh.
[12:26] <infinity> Kay.
[12:26] <ogra_> ok, fixing
[12:26] <infinity> So, either 0.52 or 0.53~, if you're concerned about forked versions.
[12:26] <ogra_> tegh filename needs to be the full path ?
[12:26] <ogra_> the manpage isnt clear with that
[12:26] <infinity> ogra_: Also, it should be in preinst/postinst/postrm, not just postinst.
[12:27] <ogra_> three times the same ?
[12:27] <infinity> ogra_: *and*, don't guard it in the $1 test, just leave it bare.
[12:27] <ogra_> why do i need that
[12:27] <infinity> ogra_: Read the manpage to see what it does.
[12:27] <infinity> Search for "Current implementation".
[12:27] <infinity> It's not just removing the conffile, it's much more clever.
[12:27]  * ogra_ sighs about translated manpages
[12:28] <infinity> And the filename needs to be the full path, yes.
[12:28] <ogra_> k
[12:29] <ogra_> aha, ok, its a three step thing, understood now
[12:32] <ogra_> janimo, can i drop the acceld binary or do you need anything from it for the roataion stuff ?
[12:33] <janimo> ogra_, you can drop it, thanks
[12:33] <janimo> all should work fine without it
[12:33] <ogra_> k
[15:48] <wookey> xnox: what's the difference between NO_PKGS=-Nfoo  and DH_OPTIONS=-Nfoo ?
[15:48] <wookey> is there any?
[15:48] <xnox> DH_OPTIONS should be tolerated by dh_* commands.
[15:49] <xnox> NO_PKGS sounds like either custom stuff or maybe in cdbs?
[15:49]  * xnox goes to double check cdbs
[15:49] <wookey> I saw it in udev
[15:50] <wookey> loks like doko put it in in 175-0ubuntu16
[15:50] <xnox> wookey: so it's not exporting a DH_OPTIONS, because it conditionally uses -N for only some dh_* commands in the binary-arch target.
[15:51] <xnox> but yeah, it's the same - just used as a command line options instead of exporting environment variable.
[15:51] <wookey> ah yes I see
[15:51] <xnox> it does some cunning stuff with setting & unsetting DH_OPTIONS and juggling all sorts of packages left and right =)
[15:51] <wookey> We should write up all this 'best practice' somewhere
[15:52] <xnox> s/best/worst/
[15:52] <wookey> because it's not exactly obvious to your average packager wanting to DTRT
[15:52]  * xnox likes to call it barrier of entry
[15:52] <wookey> to the elite hall of unfortunate distro cross-build fixers?
[15:53] <wookey> I don't mind if some more people come and play
[15:53] <xnox> =))) well more like the torture dungeon =) but it's all fun and dandy.
[15:55] <wookey> you are very welcome to tell me why perl cross-build works OK, but perl multiarch cross-build doesn't...
[15:55] <wookey> http://wiki.debian.org/Multiarch/Perl
[15:55]  * xnox wishes I could apt-get remove --purge perl
[15:56] <wookey> I'd happily strangle its config system which is v. horrid.
[15:58] <xnox> your queue ticket number is 4567 to stangle perl's config system.
[16:45] <wookey> xnox: udev is quite broken. It has no configure: target so relies on configure file being present, but at the end of a dpkg-buildpackage -S build configure is removed.
[16:45] <wookey> so you can only ever build it once
[16:45] <wookey> I suspect this happened when autoreconf fooery was added
[16:45] <ogra_> its udev, who would build it more than once anyway :P
[16:46] <wookey> I hate packages that only build once - it's increasingly common
[16:47] <wookey> And I just spent some time wondering why my changes had broken the rules file...
[16:47] <wookey> they hadn't of course - it just came bust
[16:47] <ogra_> yeah, systemd will solve that
[16:47] <xnox> wookey: use bzr ;-) bzr branch lp:ubuntu/udev & then build using $ bzr bd, each time does export of the head with your changes and does a clean build.
[16:47]  * ogra_ shudders
[16:47] <wookey> xnox: that is _not_ a solution
[16:47] <xnox> wookey: that way all my builds are "as if the first one"
[16:47] <wookey> yeah which is why lots of packages only work once
[16:47] <wookey> people like you who never try a second time
[16:48] <xnox> wookey: are you saying that if clean target is invoked between the builds it fails?
[16:48] <ogra_> is it so hard to add an override in the rules file to keep configure in place ?
[16:48] <xnox> that's an RC bug.
[16:49] <xnox> wookey: ./debian/rules clean; ./debian/rules build; fakeroot ./debian/rules binary; cycles work just with with all standard dh_autoreconfigury helpers.
[16:49] <xnox> s/work just/just work/
[16:50] <wookey> apt-get source udev; cd udev-175; dpkg-buildpackage -S; dpkg-buildpackage -B fails for me
[16:51] <wookey> hmm. it's worked now...
[16:51] <wookey> apt-get source udev; cd udev-175; dpkg-buildpackage -S -sa; dpkg-buildpackage -B fails for me
[16:51] <wookey> that seems odd
[16:52] <wookey> but also quite borked
[17:03] <wookey> OK. I think I've fixed it.
[17:18] <wookey> OH look a new libffi so my build chroot broke again. Will you lot stop uploading new packages every 5 mins
[17:23] <ogra_> lol
[17:28] <wookey> It would be easier if apt produced more helpful messages like "Can't install foo: arches out of sync" rather than just "foo won't be installed"
[17:29] <wookey> and if you have any moons on sticks that would be good too
[17:30] <scientes> "cannot install foo: the planets are not aligned"
[17:33] <ogra_> wookey, i bet patches are accepted ;)
[17:46] <wookey> ogra_: yeah. I tried to fix something in apt recently and remembered that I totally don't grok C++
[17:46] <wookey> I had to find someone significantly cleverer to do it for me
[17:46] <ogra_> haha, i know what you mean
[17:47]  * ogra_ usually runs if there is C++ involved
[17:47] <wookey> I've spent 20 years not grokking OOP. I suspect it's too late to change
[17:48] <ogra_> well, i bet if you really want it you can do it ...
[17:48] <ogra_> not that i personallys would
[17:48] <ogra_> -s
[17:56] <dmart> It's possible that ARM support can answer the question about finding out how much RAM there is -- if the docs don't have it, I don't know how to answer that
[17:56] <dmart> It's possible that ARM support can answer the question about finding out how much RAM there is -- if the docs don't have it, I don't know how to answer that
[17:58] <ogra_> dmart, thanks for letting us know :)
[18:04]  * dmart would an IRC client that automatically guesses the right channel :)
[18:05] <ogra_> :)
[18:05] <ogra_> or a WM with "focus follows brain" mode
[18:06] <dmart> ogra_: nah, that would spray stuff into windows pretty much at random.  Focus follows eyes would be pretty cool though
[18:06] <ogra_> hehe, true
[18:07] <davmor2> ogra_: that's a stupidly dangerous suggestion, especially if you happen to working in a coffee shop with your wife beside you :D
[18:07] <ogra_> LOL
[18:07] <ogra_> though beside me isnt that bad with a laptop, behind me would be worse
[18:29] <mosasaur> my image is on a vfat device and can't grow bigger than 4 GB
[18:29] <mosasaur> suggestions?
[22:37] <ufsu_> what is the directory that I can access .config file to see what kernel modules are disabled?
[22:44] <TheMuso> ufsu_: All kernels have their respective config files in /boot.
[22:45] <TheMuso> At least all kernels shipped in Ubuntu packages.
[22:49] <ufsu_> TheMuso: e CONFIG_OMAP_RESET_CLOCKS=y is set on the configure file. If I disabled that module on configure file, will that module be disabled on the next boot?
[22:49] <ufsu_> I am using beagleboard-xm if you need to know
[22:55] <TheMuso> No.
[22:55] <TheMuso> You'd have to rebuild the kernel.
[22:55] <TheMuso> Config files are just a point of references to show whats configured. There may be a way to disable a module, but generally you would have to rebuild a kernel to disable it.
[22:55] <ufsu_> TheMuso: thank you
[22:56] <ufsu_> do you know where are the kernel source codes for ubuntu-server for a beagleboard-xm?
[22:57] <ufsu_> omap3
[22:58] <TheMuso> You can have a look on kernel.ubuntu.com/git.
[23:01] <ufsu_> do you have any idea which one is for beagleboard-xm?
[23:02] <TheMuso> No sorry.
[23:03] <ufsu_> thank you
[23:03] <TheMuso> I believe that hardware is OMAP based, so look for an omap tree I guess.
[23:07] <ufsu_> ogra_ should know if he is there?
[23:11] <TheMuso> He is probably not around since its past midnight for him.
[23:12] <TheMuso> Although stranger things have happened in the past. :)