| === shuduo is now known as shuduo_afk | ||
| 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:16 |
| scientes | i found the plymouth assert that is being triggered, but can't really debug more than that | 06:17 |
| dholbach | good morning | 07:59 |
| scientes | morning | 08:05 |
| === zz_jackyalcine is now known as jackyalcine | ||
| === jackyalcine is now known as jackyalcine_ | ||
| === jackyalcine_ is now known as zz_jackyalcine | ||
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| marvin24 | and you may lose support for many embedded processors | 09:17 |
| ogra_ | well | 09:18 |
| 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:19 |
| 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:20 |
| ogra_ | its not a matter of making, but of spending :) | 09:21 |
| 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:22 |
| ogra_ | note that i would also vote for dropping non-NEON support if i wouldnt work for canonical | 09:23 |
| ogra_ | (and its not something that gets dictated or so, its simply a logical evolution to go along with recent hw changes) | 09:24 |
| marvin24 | I wonder if there is some code to emulate neon in the kernel | 09:33 |
| marvin24 | like no-fpu | 09:33 |
| === lool- is now known as lool | ||
| infinity | marvin24: neon emulation code in the kernel would be a Bad Idea. | 09:40 |
| 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:41 |
| 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:42 |
| infinity | marvin24: But it's usually applications that are the big offenders here and we waste a lot of time on, not libraries. | 09:43 |
| marvin24 | infinity: ok, maybe those apps could be blacklisted somehow on non-neon platforms | 09:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 | 09:59 |
| 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:02 |
| marvin24 | infinity: ok, ok - I got it | 10:03 |
| === yofel_ is now known as yofel | ||
| marvin24 | just wanted to cry a bit about it | 10:04 |
| infinity | Well, it hasn't happened yet. :) | 10:05 |
| infinity | I could be talked down from this position too. | 10:06 |
| 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:07 |
| === zz_jackyalcine is now known as jackyalcine | ||
| marvin24 | infinity: thanks for you efforts! | 10:19 |
| 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:09 |
| 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:10 |
| ogra_ | where do i put it | 11:11 |
| ogra_ | (and how) | 11:11 |
| 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:14 |
| ogra_ | i'm not in urgent need of suspend :) | 11:15 |
| === doko_ is now known as doko | ||
| === jackyalcine is now known as zz_jackyalcine | ||
| ogra_ | http://paste.ubuntu.com/1639292/ | 12:24 |
| ogra_ | infinity, ^^^ does that look ok to zou ? | 12:24 |
| ogra_ | *you | 12:24 |
| 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:25 |
| 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:26 |
| 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:27 | |
| infinity | And the filename needs to be the full path, yes. | 12:28 |
| ogra_ | k | 12:28 |
| ogra_ | aha, ok, its a three step thing, understood now | 12:29 |
| ogra_ | janimo, can i drop the acceld binary or do you need anything from it for the roataion stuff ? | 12:32 |
| janimo | ogra_, you can drop it, thanks | 12:33 |
| janimo | all should work fine without it | 12:33 |
| ogra_ | k | 12:33 |
| === 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 | ||
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:55 | |
| wookey | I'd happily strangle its config system which is v. horrid. | 15:56 |
| xnox | your queue ticket number is 4567 to stangle perl's config system. | 15:58 |
| === XenGi is now known as XenGi_ | ||
| 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:45 |
| wookey | I hate packages that only build once - it's increasingly common | 16:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| wookey | apt-get source udev; cd udev-175; dpkg-buildpackage -S; dpkg-buildpackage -B fails for me | 16:50 |
| 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:51 |
| wookey | but also quite borked | 16:52 |
| wookey | OK. I think I've fixed it. | 17:03 |
| wookey | OH look a new libffi so my build chroot broke again. Will you lot stop uploading new packages every 5 mins | 17:18 |
| ogra_ | lol | 17:23 |
| 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:28 |
| wookey | and if you have any moons on sticks that would be good too | 17:29 |
| scientes | "cannot install foo: the planets are not aligned" | 17:30 |
| ogra_ | wookey, i bet patches are accepted ;) | 17:33 |
| 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:46 |
| * 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:47 |
| 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:48 |
| 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:56 |
| ogra_ | dmart, thanks for letting us know :) | 17:58 |
| * dmart would an IRC client that automatically guesses the right channel :) | 18:04 | |
| ogra_ | :) | 18:05 |
| ogra_ | or a WM with "focus follows brain" mode | 18:05 |
| 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:06 |
| 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:07 |
| === jackyalcine is now known as zz_jackyalcine | ||
| mosasaur | my image is on a vfat device and can't grow bigger than 4 GB | 18:29 |
| mosasaur | suggestions? | 18:29 |
| === k1l_ is now known as k1l | ||
| === hggdh_ is now known as hggdh | ||
| ufsu_ | what is the directory that I can access .config file to see what kernel modules are disabled? | 22:37 |
| TheMuso | ufsu_: All kernels have their respective config files in /boot. | 22:44 |
| TheMuso | At least all kernels shipped in Ubuntu packages. | 22:45 |
| 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:49 |
| === zz_jackyalcine is now known as jackyalcine | ||
| === jackyalcine is now known as jackyalcine_ | ||
| === jackyalcine_ is now known as zz_jackyalcine | ||
| 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:55 |
| ufsu_ | do you know where are the kernel source codes for ubuntu-server for a beagleboard-xm? | 22:56 |
| ufsu_ | omap3 | 22:57 |
| TheMuso | You can have a look on kernel.ubuntu.com/git. | 22:58 |
| ufsu_ | do you have any idea which one is for beagleboard-xm? | 23:01 |
| === zz_jackyalcine is now known as zz_zz_jackyalcin | ||
| === zz_zz_jackyalcin is now known as jackyalcine | ||
| TheMuso | No sorry. | 23:02 |
| ufsu_ | thank you | 23:03 |
| TheMuso | I believe that hardware is OMAP based, so look for an omap tree I guess. | 23:03 |
| ufsu_ | ogra_ should know if he is there? | 23:07 |
| TheMuso | He is probably not around since its past midnight for him. | 23:11 |
| TheMuso | Although stranger things have happened in the past. :) | 23:12 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!