=== shuduo is now known as shuduo_afk [06:16] http://nullr0ute.com/2012/11/fedora-arm-on-the-google-chromebook/ [06:16] I havn't been able to boot anything but precise [06:16] quantal and raring Xorg doesn't load, and when it tries it locks up the computer [06:16] and i get a plymouth error [06:17] i found the plymouth assert that is being triggered, but can't really debug more than that [07:59] good morning [08:05] morning === zz_jackyalcine is now known as jackyalcine === jackyalcine is now known as jackyalcine_ === jackyalcine_ is now known as zz_jackyalcine [09:12] [16:12:03] infinity, i would go with that too ... but #ac100 would hate us all [09:12] ^ if chromium is the only reason [09:12] instead of fixing it [09:13] marvin24, nah, many packages would benefit from using NEON [09:13] benchmarks? [09:13] not idea where they went, we did some in the past [09:14] using multiarch would be another solution [09:14] at least for the most important libraries which really care [09:14] and there are actually some packages that already have runtime switching ... i.e. pixman [09:15] multiarch would mean to have something like armhf-neon [09:15] i.e. a full new port just for say 20% of the archive [09:15] (or probably less) [09:16] marvin24, we will definitely switch some day. the question is just when [09:16] there is no more modern armv7 HW that laks NEON [09:16] I have no problem with this - I just think you should make sure that it give more than 5% for common apps [09:17] and you may lose support for many embedded processors [09:18] well [09:19] if we wanted to be general purpose (embedded, desktop, server etc) on ARM, we would have just gone with armel [09:19] but we focus on a single platform with only the desktop, mobile and server perspective atm [09:20] we never targeted embedded [09:20] yes, it is of course up to canonical to decide where to make money ;-) [09:20] (and i personally also dont know and new ARMv7 embedded chip that could currently run ubuntu and has no N|EON) [09:21] its not a matter of making, but of spending :) [09:22] 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] note that i would also vote for dropping non-NEON support if i wouldnt work for canonical [09:24] (and its not something that gets dictated or so, its simply a logical evolution to go along with recent hw changes) [09:33] I wonder if there is some code to emulate neon in the kernel [09:33] like no-fpu === lool- is now known as lool [09:40] marvin24: neon emulation code in the kernel would be a Bad Idea. [09:41] 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] 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] marvin24: But it's usually applications that are the big offenders here and we waste a lot of time on, not libraries. [09:49] infinity: ok, maybe those apps could be blacklisted somehow on non-neon platforms [09:50] if there is some mechanism already [09:50] 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] I still wonder where the problem is with neon in apps [09:51] some hand-optimization code? [09:51] (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] Sometimes it's hand-optimised code with broken (or non-existant) fallbacks, so we get to fix the fallbacks too. [09:52] 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] ok, that's just really sad ... [09:53] Sad that I don't want to deal with the mess, or sad that upstreams suck? [09:53] The former is just pragmatism, but I entirely agree with the latter. [09:54] And I yell at them every time I have to fix something. [09:54] But some just never learn. [09:54] And it's tiring. [09:54] marvin24, its not like we will switch next week ... but along the way to 14.04 it will happen [09:55] Well, there's "will happen" and "will happen", too. :P [09:55] infinity: it is sad you need to drop non-neon because of broken apps - and not for performance reasons [09:55] 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] But "not bothering to revert every silly upstream assumption" may happen at some point. [09:56] marvin24: Well, it's *also* for performance, to be fair. That's just not my primary concern. It may be for others. [09:56] ogra_: there are other distros of course - I will always find a way to boot the latest kernel ;-) [09:56] indeed [09:56] marvin24: precise userspace is supported for another 4+ years, still. No reason to not be booting the latest kernels there. :P [09:57] note that we arent enforcing non-neon (as infinity said above) but will at some point stop to apply hacks [09:57] you could try to form a community team to take care of the patches ;) [09:57] 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] But for now, it's hand-tuned or GTFO, as far as getting performance from NEON. [09:58] the simplest solution would be to upstream the "hacks" [09:58] which is whats being tried since 4 years [09:58] this way you wouldn't have to put more efforts in fixing it [09:58] 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] marvin24: Upstreaming the compiler assumptions tends to fall on deaf ears. [09:59] awwww [09:59] 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] upstream kills pm-utils for systemd [10:02] 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] 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] infinity: ok, ok - I got it === yofel_ is now known as yofel [10:04] just wanted to cry a bit about it [10:05] Well, it hasn't happened yet. :) [10:06] I could be talked down from this position too. [10:07] 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] 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. === zz_jackyalcine is now known as jackyalcine [10:19] infinity: thanks for you efforts! [11:09] 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] ogra_: kernel in NEW queue has suspend working [11:10] how do i install that ? [11:10] do we have some howto ? [11:10] grab it from new and build? [11:10] * ogra_ still runs the original cros one [11:10] hrw, heh, i know how to build it ... but lack the bits flash-kernel would do with the binary [11:11] where do i put it [11:11] (and how) [11:14] ah, signing etc [11:14] w8 half hour - meeting now [11:14] well, signing and i have no clue where i should put it [11:14] ok [11:14] no hurry at all [11:15] i'm not in urgent need of suspend :) === doko_ is now known as doko === jackyalcine is now known as zz_jackyalcine [12:24] http://paste.ubuntu.com/1639292/ [12:24] infinity, ^^^ does that look ok to zou ? [12:24] *you [12:25] ogra_: No. [12:25] ogra_: prior_version should be the one right before the one you're doing. [12:25] so 0.52 ? [12:26] ogra_: 0.52 is what you're doing now, no? [12:26] nope. 53 is [12:26] havent run dch yet [12:26] Ahh. [12:26] Kay. [12:26] ok, fixing [12:26] So, either 0.52 or 0.53~, if you're concerned about forked versions. [12:26] tegh filename needs to be the full path ? [12:26] the manpage isnt clear with that [12:26] ogra_: Also, it should be in preinst/postinst/postrm, not just postinst. [12:27] three times the same ? [12:27] ogra_: *and*, don't guard it in the $1 test, just leave it bare. [12:27] why do i need that [12:27] ogra_: Read the manpage to see what it does. [12:27] Search for "Current implementation". [12:27] It's not just removing the conffile, it's much more clever. [12:27] * ogra_ sighs about translated manpages [12:28] And the filename needs to be the full path, yes. [12:28] k [12:29] aha, ok, its a three step thing, understood now [12:32] janimo, can i drop the acceld binary or do you need anything from it for the roataion stuff ? [12:33] ogra_, you can drop it, thanks [12:33] all should work fine without it [12:33] k === zz_jackyalcine is now known as jackyalcine === jackyalcine is now known as jackyalcine_ === jackyalcine_ is now known as zz_jackyalcine === hatake is now known as blackjack === zz_jackyalcine is now known as jackyalcine === mrcan_ is now known as mrcan === plars_ is now known as plars === XenGi_ is now known as XenGi [15:48] xnox: what's the difference between NO_PKGS=-Nfoo and DH_OPTIONS=-Nfoo ? [15:48] is there any? [15:48] DH_OPTIONS should be tolerated by dh_* commands. [15:49] NO_PKGS sounds like either custom stuff or maybe in cdbs? [15:49] * xnox goes to double check cdbs [15:49] I saw it in udev [15:50] loks like doko put it in in 175-0ubuntu16 [15:50] 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] but yeah, it's the same - just used as a command line options instead of exporting environment variable. [15:51] ah yes I see [15:51] it does some cunning stuff with setting & unsetting DH_OPTIONS and juggling all sorts of packages left and right =) [15:51] We should write up all this 'best practice' somewhere [15:52] s/best/worst/ [15:52] 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] to the elite hall of unfortunate distro cross-build fixers? [15:53] I don't mind if some more people come and play [15:53] =))) well more like the torture dungeon =) but it's all fun and dandy. [15:55] you are very welcome to tell me why perl cross-build works OK, but perl multiarch cross-build doesn't... [15:55] http://wiki.debian.org/Multiarch/Perl [15:55] * xnox wishes I could apt-get remove --purge perl [15:56] I'd happily strangle its config system which is v. horrid. [15:58] your queue ticket number is 4567 to stangle perl's config system. === XenGi is now known as XenGi_ [16:45] 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] so you can only ever build it once [16:45] I suspect this happened when autoreconf fooery was added [16:45] its udev, who would build it more than once anyway :P [16:46] I hate packages that only build once - it's increasingly common [16:47] And I just spent some time wondering why my changes had broken the rules file... [16:47] they hadn't of course - it just came bust [16:47] yeah, systemd will solve that [16:47] 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] xnox: that is _not_ a solution [16:47] wookey: that way all my builds are "as if the first one" [16:47] yeah which is why lots of packages only work once [16:47] people like you who never try a second time [16:48] wookey: are you saying that if clean target is invoked between the builds it fails? [16:48] is it so hard to add an override in the rules file to keep configure in place ? [16:48] that's an RC bug. [16:49] wookey: ./debian/rules clean; ./debian/rules build; fakeroot ./debian/rules binary; cycles work just with with all standard dh_autoreconfigury helpers. [16:49] s/work just/just work/ [16:50] apt-get source udev; cd udev-175; dpkg-buildpackage -S; dpkg-buildpackage -B fails for me [16:51] hmm. it's worked now... [16:51] apt-get source udev; cd udev-175; dpkg-buildpackage -S -sa; dpkg-buildpackage -B fails for me [16:51] that seems odd [16:52] but also quite borked [17:03] OK. I think I've fixed it. [17:18] OH look a new libffi so my build chroot broke again. Will you lot stop uploading new packages every 5 mins [17:23] lol [17:28] 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] and if you have any moons on sticks that would be good too [17:30] "cannot install foo: the planets are not aligned" [17:33] wookey, i bet patches are accepted ;) [17:46] ogra_: yeah. I tried to fix something in apt recently and remembered that I totally don't grok C++ [17:46] I had to find someone significantly cleverer to do it for me [17:46] haha, i know what you mean [17:47] * ogra_ usually runs if there is C++ involved [17:47] I've spent 20 years not grokking OOP. I suspect it's too late to change [17:48] well, i bet if you really want it you can do it ... [17:48] not that i personallys would [17:48] -s [17:56] 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] 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] dmart, thanks for letting us know :) [18:04] * dmart would an IRC client that automatically guesses the right channel :) [18:05] :) [18:05] or a WM with "focus follows brain" mode [18:06] ogra_: nah, that would spray stuff into windows pretty much at random. Focus follows eyes would be pretty cool though [18:06] hehe, true [18:07] 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] LOL [18:07] though beside me isnt that bad with a laptop, behind me would be worse === jackyalcine is now known as zz_jackyalcine [18:29] my image is on a vfat device and can't grow bigger than 4 GB [18:29] suggestions? === k1l_ is now known as k1l === hggdh_ is now known as hggdh [22:37] what is the directory that I can access .config file to see what kernel modules are disabled? [22:44] ufsu_: All kernels have their respective config files in /boot. [22:45] At least all kernels shipped in Ubuntu packages. [22:49] 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] I am using beagleboard-xm if you need to know === zz_jackyalcine is now known as jackyalcine === jackyalcine is now known as jackyalcine_ === jackyalcine_ is now known as zz_jackyalcine [22:55] No. [22:55] You'd have to rebuild the kernel. [22:55] 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] TheMuso: thank you [22:56] do you know where are the kernel source codes for ubuntu-server for a beagleboard-xm? [22:57] omap3 [22:58] You can have a look on kernel.ubuntu.com/git. [23:01] do you have any idea which one is for beagleboard-xm? === zz_jackyalcine is now known as zz_zz_jackyalcin === zz_zz_jackyalcin is now known as jackyalcine [23:02] No sorry. [23:03] thank you [23:03] I believe that hardware is OMAP based, so look for an omap tree I guess. [23:07] ogra_ should know if he is there? [23:11] He is probably not around since its past midnight for him. [23:12] Although stranger things have happened in the past. :)