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