| === XenGi is now known as XenGi_ | ||
| === zz_chihchun is now known as chihchun | ||
| wookey | infinity: OK, with that stage2 patch and removing --enable-multiarch it at least completes a cross-build here | 01:29 |
|---|---|---|
| twb | Remind me, what's the SoC that's pre-armv7, but still being made? IIRC there's r-pi and one other. | 01:34 |
| wookey | I don;t suppose the rpi soc is still being made, just the boards, using up large stock of videocore 2xxx chips | 01:40 |
| wookey | pxa270 is still available I believe | 01:41 |
| twb | Hum, OK | 01:41 |
| wookey | and various marvell devices which are v6 | 01:41 |
| twb | The context is me telling people to stop getting excited about rpi because armv6 is obsolete and sucky :-) | 01:41 |
| wookey | yes, keep doing that. I do it too | 01:41 |
| twb | Ah, right. My memory said it was marvell dove, but that's v7 | 01:42 |
| wookey | OK I thought 'dove'. WHat about armada? Maybe it's an earlier one that is v6 | 01:42 |
| infinity | dove and armadap are all the same general family. | 01:44 |
| wookey | armada seems to be v7 | 01:44 |
| infinity | There are some v6 devices in said family, but none worth talking about. | 01:44 |
| twb | dove sucks because it has no NEON, not because it is pre-v7 | 01:44 |
| infinity | Anyhow, telling people to move to v7 is sane messaging, IMO. | 01:44 |
| wookey | so, yes it's geting hard to find things still made which aren;t v7 | 01:45 |
| infinity | Not that the Pi being v6 is a problem, per se, it's that it's v6 and being used as a general-purpose machine, instead of a fun pseudo-embedded student/hacker device. | 01:45 |
| infinity | Pretty much all general-purpose ARM computing should be moving/moved to v7 and v8, IMO. | 01:45 |
| wookey | and that we still haven't put ISA info into dpkg metadata | 01:45 |
| infinity | (I might be biased) | 01:45 |
| wookey | we're going to get the same prob with v8 32 bit ISA at some point... | 01:46 |
| infinity | wookey: What v8 32-bit ISA? | 01:46 |
| wookey | it'd be nice to put the machinery in so dpkg can just DTRT | 01:46 |
| wookey | aarch32 | 01:46 |
| infinity | wookey: Every single time I've brought this up in the past, I've been told there isn't one, and 32-bit on v8 is v7. | 01:46 |
| wookey | no there are a few extra instructions | 01:47 |
| wookey | so it's the same ABI, but new instructions | 01:47 |
| infinity | Well, yes, I'm sure it's possible to do an x32-like aarch32, I was told (repeatedly) that no one was going to. :/ | 01:47 |
| infinity | Oh, same ABI as v7? | 01:47 |
| infinity | Well, that's not a big deal. | 01:47 |
| wookey | and yes at some point people will want to do 'x32 for arm' - just watch them... | 01:47 |
| infinity | Same ABI and new insns just means glibc caps. | 01:48 |
| wookey | the point is that ABI is not sufficient to determine compatibility - you need ISA as well and we don;t write that down anywhere | 01:48 |
| wookey | agreed, but dpkg needs to know too so it can download the right version | 01:48 |
| infinity | We don't write that down because we intend for an entirely self-contained distro to have the same basline ISA. | 01:48 |
| infinity | Anything else is madness. | 01:48 |
| infinity | Err, no. | 01:49 |
| twb | infinity: doing x32 on x86 systems is already a dirty hack | 01:49 |
| infinity | "download the right version"? | 01:49 |
| wookey | well not try to install versions that won't run | 01:49 |
| infinity | wookey: You can't have two armhf debs in the same version. | 01:49 |
| infinity | This isn't actually a problem. At all. | 01:49 |
| wookey | i.e ubuntu armhf packages on RPis | 01:49 |
| infinity | If you don't want to install wrong-ISA debs, don't use the wrong apt source. | 01:49 |
| infinity | wookey: Or Ubuntu i386 debs on Debian. :P | 01:50 |
| wookey | why not make it possible to enforce that? | 01:50 |
| infinity | wookey: This isn't a problem. It's really not. | 01:50 |
| wookey | It's not hard to fix though either. | 01:50 |
| infinity | I disagree. | 01:50 |
| wookey | just write down the caps used in the metadata | 01:50 |
| infinity | You have zero idea what the contents of the deb are without disassembling. | 01:50 |
| infinity | You can make some sort of assumptions based on your custom copy of dpkg, if that's what you mean. | 01:51 |
| wookey | you know when you build it - or at least you know what you meant to build | 01:51 |
| infinity | But, again, I don't see how this is a problem. | 01:51 |
| infinity | You're running Raspbian, you install Raspbian debs. | 01:51 |
| infinity | People keep making this sound like a big deal and it's not. | 01:51 |
| wookey | No-one tries to install3rd party debs on their rpis? | 01:51 |
| infinity | I don't really care if they do. | 01:52 |
| wookey | from all those bazillions of ppas? | 01:52 |
| wookey | the users might care | 01:52 |
| infinity | In your scenario, people trying to install Ubuntu debs on Debian wouldn't be allowed. | 01:52 |
| infinity | (And they shouldn't anyway, but now dpkg would enforce it) | 01:52 |
| wookey | only if their debian hardware couldn't run v7 | 01:52 |
| wookey | in which case that would be good | 01:52 |
| infinity | I'm talking i386, actually. | 01:52 |
| wookey | and this is useful for mplayer-686 and other stuff currently bodged into the packagenames | 01:53 |
| infinity | Okay, so you're saying that dpkg should check the running system to determine caps at that moment. | 01:53 |
| infinity | That entirely breaks portability of system roots. | 01:53 |
| infinity | It's not useful for mplayer-686 at all. | 01:54 |
| wookey | If I told it to yes. I expect I'm allowed to turn it off for cross-choots | 01:54 |
| infinity | Because you can still only have one mplayer.deb in any apt source. | 01:54 |
| infinity | So if you want an optimised one, you need another package name. | 01:54 |
| === simon___ is now known as sim590 | ||
| wookey | but I can have more than one apt source | 01:54 |
| infinity | But mplayer-686 isn't in another source. | 01:54 |
| infinity | And shouldn't be. | 01:54 |
| infinity | That's user hostile. | 01:54 |
| infinity | I think you're trying to solve a problem "normal" people don't have with a nerd solution that only nerds will understand. And nerds don't need it. | 01:55 |
| wookey | I'm tryingto make it possible for dpkg to tell you that what you are instaling won;t run on this machine so are you sure you want to install it. | 01:55 |
| wookey | That doesn't seem user-hostile to me | 01:56 |
| infinity | Most of your use-cases are user-hostile. | 01:56 |
| infinity | Like, adding extra sources to get optimised packages. | 01:56 |
| sim590 | anyone knows how I can get the battery level on the TF101 under lilstevie's kernel (ubuntu/debian)? I looked up the folder "/sys/class/power_supply" for that information but all I can get is a % level. | 01:56 |
| wookey | I'm not forcing anyone to do that, but it would become possible. and you could now easily optimise _lots_ of stuff instead of just a few things | 01:57 |
| infinity | wookey: Either way, dpkg installs system roots. Saying "that won't run on the hardware you have RIGHT NOW" is meaningless. | 01:57 |
| infinity | wookey: I could install a sysroot on i686 and give it to someone with an i585 and it won't run. | 01:57 |
| infinity | wookey: And no, it wouldn't let you optimise anything in the primary archive any more than you already do. | 01:58 |
| wookey | sometimes. most of the time stuff is installed onthe system it's going to be run on. | 01:58 |
| infinity | wookey: And optimising out-of-archive is *drum rull* user-hostile. | 01:58 |
| wookey | you can check against the target if you know what it's going to be | 01:58 |
| infinity | wookey: That's a blatant lie in the Ubuntu case (or any live installer). | 01:58 |
| infinity | wookey: The install is always done on a system that isn't the target. | 01:58 |
| wookey | OK, so you don;t think it's useful. fair enough | 01:59 |
| infinity | I think people need to learn to detect CPU features. | 01:59 |
| infinity | Your example above (mplayer) actually has. | 01:59 |
| sim590 | I want W*h (Joules) or coulons (that's in french though.. its intensity (c/s) | 02:00 |
| infinity | When I run it on my machine, it turns on all sort of fancy SSE3 and other crap that it doesn't turn on on an older box. | 02:00 |
| wookey | OK, so then it doesn;t need to ask for caps it can live without | 02:00 |
| wookey | whichis fine | 02:00 |
| infinity | I guess my point is that this is solving a non-problem for pretty much all but the weird case of people mixing and matching distributions. | 02:01 |
| infinity | And the answer to that is "stop doing that". | 02:01 |
| wookey | but what if the server people start asking for lots of v8 optimised binaries because it's loads faster? | 02:01 |
| wookey | we can just say no | 02:02 |
| infinity | I've certainly seen people in #debian-arm whine that packages installed from debian-armhf don't work on Raspbian, I don't think the whining would change any if dpkg stopped them before installing. | 02:02 |
| wookey | but if we can easily accomodate it with a check I don;t see why that's bad | 02:02 |
| infinity | Do you think the "server people" are going to ask for 32-on-64 anytime soon anyway? | 02:02 |
| infinity | Anyhow. | 02:02 |
| infinity | This doesn't solve that. | 02:02 |
| infinity | You still need either a new dpkg arch, or a new distro. | 02:02 |
| twb | Can someone confirm that current ubuntu armel uses -mfpu=softfp (i.e. doesn't require hardware FPU)? | 02:02 |
| infinity | Cause you can't. Have. The. Same. Deb. Twice. In. The. Same. Archive. | 02:03 |
| wookey | don't know - they might do if they have a lot of 32-bit binaires they cant get 64-bit versions of. Hopefully not. | 02:03 |
| twb | It's not very clear on the wiki ARM article | 02:03 |
| infinity | twb: There is no ubuntu armel. | 02:03 |
| twb | infinity: hah, so it's just "arm" now? | 02:03 |
| infinity | twb: Did that help? | 02:03 |
| infinity | twb: armhf. We dropped armel. | 02:03 |
| infinity | twb: And armhf most definitely required an FPU. vfpv3-d16 | 02:04 |
| infinity | s/required/requires/ | 02:04 |
| twb | It would be nice if https://wiki.ubuntu.com/ARM made that more obvious | 02:04 |
| wookey | it's a wiki.... | 02:04 |
| infinity | wookey: If they want to install multiarch arm64/armhf, they're going to end up with baseline v7 armhf binaries unless they rebuild the archive. | 02:05 |
| infinity | wookey: And if they rebuild the archive, we're in "not the same distribution" land. | 02:05 |
| wookey | infinity: yes, but I don;t see why a distro _has_ to only support one baseline per ABI. If we labelled them we could provide more variants | 02:06 |
| wookey | that would have made the rasbian's people's lives a lot easier, for example | 02:06 |
| wookey | but OK. I get it that you're not keen :-) | 02:07 |
| raster | wookey: rpi is just a piece of pretty crappy hw. deal with it. its a very outdated instructionset versions pushed out for cheap. | 02:07 |
| raster | deal with it. you'll have to jump through hoops and make custom pkgs for it as everyone else has moved on to armv7 фі ф ифіудшту | 02:07 |
| raster | err | 02:07 |
| raster | armv7 as a baseline | 02:07 |
| wookey | I know. | 02:08 |
| wookey | it's just an example. | 02:08 |
| wookey | because people _have_ gone to the trouble of rebuilding the whole distro | 02:08 |
| wookey | for a different ISA | 02:08 |
| twb | Hm, arm builds are still on ports.ubuntu.com? I'd have thought it'd move to archive.ubuntu.com when it was blessed as a fully supported arch | 02:09 |
| raster | reality is armv7hf+neon should be the baseline | 02:09 |
| raster | and thats a very decent baseline with not much above it | 02:09 |
| wookey | twb: sadly not | 02:09 |
| infinity | wookey: Err, we can't do more than one without them being in separate archives. | 02:09 |
| raster | in x86 land we have also a wide range | 02:09 |
| infinity | twb: archive/ports has nothing to do with supported, but with popularity/traffic. | 02:09 |
| wookey | right, and it'd be nice if those archives were labelled with the capabilities needed to run them - that's all | 02:10 |
| raster | most of the compiling is fine-tuning small percentages of per increase | 02:10 |
| raster | the few where its big should be the task of the software itself to detect at runtime | 02:10 |
| infinity | raster: Exactly. | 02:10 |
| raster | most of that is in in either gfx/video/audio | 02:10 |
| raster | and the specific apps and/or libs already "compile all possibilities in" and auto-detect at runtime | 02:11 |
| infinity | Like the canonical examples of ffmpeg/libav, libjpeg-turbo, and mplayer. | 02:11 |
| raster | eg they probe for mmx/sse/sse3/4 or neon etc. | 02:11 |
| infinity | Which all do lovely autodetection these days. | 02:11 |
| raster | and they enable specific optimized codepaths for that | 02:11 |
| wookey | youre' not telling me anything I don;t already know | 02:11 |
| raster | they COULd recompile the same C code into multiple .o's and link them in with differingt entry symbols | 02:11 |
| raster | and pick the appropriate one based on detected cpu arch. this generally tho is a much lower gain than the hand-crafted simd asm they carry and detect for. | 02:12 |
| raster | then why does the PACKAGE SYSTEM need to have anything to do with this? | 02:13 |
| raster | if u already know it? | 02:13 |
| raster | and already know that its solved within the code of libs/binaries? | 02:13 |
| doko_ | you still can use hwcap for these cases | 02:13 |
| wookey | a few binaries do this - the great majority don't. | 02:14 |
| infinity | wookey: The vast majority don't need to. | 02:14 |
| raster | i just wish unxi had a better way to detect instrset caps than "try some code and see if u SIGILL" (/proc/cpuinfo is not portable) | 02:14 |
| wookey | agreed. | 02:14 |
| raster | then whats the point here? | 02:15 |
| wookey | but if we added simple hwcaps info then peope could if they wanted | 02:15 |
| raster | if those that need to (ie have a decent gain) do it already.. why does the pkgssystem need to bother? | 02:15 |
| wookey | just to save people from installing binaries they can;t run | 02:15 |
| raster | this should never be done at pkgs install time | 02:15 |
| raster | its horrible | 02:15 |
| wookey | e.g v7 on v5 hardware | 02:15 |
| infinity | And we're back to square one. Why would they be installing a distro they can't run? :P | 02:15 |
| wookey | why is it 'horrible' | 02:16 |
| raster | it is ASSUMINg the ultimate target system is the same one that is doing the installing now | 02:16 |
| wookey | raster: read the backlog :-) | 02:16 |
| raster | thats a horrid assumption i KNOw breaks continually | 02:16 |
| infinity | raster: You're making all my same arguments for me again. :) | 02:16 |
| wookey | I don't thin kthis conversation is getting anyone anwyhere | 02:16 |
| raster | things like scratchbox, OBS, making debootstrap chroots etc... | 02:16 |
| infinity | Which is great, I can just tag you in and go have dinner. | 02:16 |
| raster | heheheh | 02:16 |
| raster | :) | 02:16 |
| raster | tbh... pkg installation should be not much more than "unpack files" | 02:17 |
| twb | http://paste.debian.net/232365/ did I get everything right? | 02:17 |
| raster | anything more than that (other than handling dependencies) is a workaround broken software :) | 02:17 |
| wookey | it could be 'unpack best avaialble files' | 02:18 |
| raster | it shoudl just ship all possible needed files and choose at runtime | 02:18 |
| infinity | twb: Except for the "Ubuntu armel is supported" bit. It's not a supported arch in 12.04 or 12.10. Not in any official capacity. | 02:19 |
| raster | and that choice is in the hands of the sw devs to deal with | 02:19 |
| raster | not packaging | 02:19 |
| twb | infinity: thanks | 02:19 |
| wookey | but every package does actually _have_ a specified ISA | 02:19 |
| wookey | we just don;t write down what it is in the packages | 02:19 |
| infinity | twb: Also, the SATA comment is out-of-date WRT many modern SoCs. | 02:19 |
| infinity | twb: Lots of A15s have native SATA, and some A9 packages do. | 02:20 |
| twb | OK | 02:20 |
| infinity | twb: And some clever setups, like the Trimslice, use PCIe SATA on a native PCIe port. | 02:20 |
| infinity | wookey: If we specify the baseline ISA for the distro, we don't need it encoded at the packaging level and muddied up. | 02:21 |
| infinity | (Now, what we define and what gets spit out of the other end of people's broken Makefiles is another story, but that's no different in your world, and those are just bugs that need fixing) | 02:22 |
| wookey | do libc6 and libc6-686 have the same baseline ISA? | 02:24 |
| wookey | how does dpkg currently choose the best one? | 02:25 |
| infinity | wookey: dpkg doesn't, you do. | 02:25 |
| infinity | wookey: There's not mutually exclusive, you can install both. | 02:25 |
| wookey | right but I'm a clueless newbie - how should I know? | 02:25 |
| infinity | wookey: They use ld.so hwcaps. | 02:25 |
| infinity | wookey: We tend to just install both for you, to be fair. :P | 02:25 |
| infinity | wookey: The only reason it's two packages instead of one (like, say, libssl which ships several libs in one package) is for size reasons. | 02:26 |
| infinity | For people who really, really only want the baseline one and want a tiny system. | 02:26 |
| infinity | The only way to be remotely user-friendly and have portable roots is to ship code that works everywhere and optimised at runtime. | 02:28 |
| infinity | s/optimised/optimises/ | 02:28 |
| infinity | Rebuilding the distro 9 times for 9 different hwcap combinations also turns into a debugging nightmare. | 02:29 |
| wookey | right. but we probably wouldn't do 9 | 02:29 |
| infinity | If you isolate that to just a few select binaries with maintainers who actually care about the optimisations, they can also care about debugging the weirdness. | 02:29 |
| infinity | wookey: Who's "we"? If you gave this option to i386 users a decade ago, we'd have 386/486/486+(that insn I cant remember the name of)/586/686/686+cmov/686+3dnow123/686+sse123/etc by now. | 02:30 |
| infinity | wookey: Every new fancy, people would want an optimised build "just cause". | 02:31 |
| raster | -funroll-loops | 02:31 |
| raster | wewt | 02:31 |
| infinity | Even if, half the time, the auto-vectorisation and other bits are so mediocre that any gains you might have gotten are lost elsewhere and it's a wash. :P | 02:31 |
| raster | auto-vectorization candiates are mostly handled by hand-crafted asm anyway | 02:32 |
| infinity | As well they should be. | 02:32 |
| infinity | And once you're hand-crafting, runtime detection is, like, two extra instructions. | 02:32 |
| infinity | So, don't be a lazy git. | 02:32 |
| infinity | It's a shame that hwcaps isn't portable outside the GNU world. | 02:33 |
| infinity | Cause "you can just ask glibc" is also quite nice. | 02:33 |
| wookey | well distros get to choose how many falvours are worth supporting | 02:35 |
| wookey | but without this labelling you can only support one ISA flavour per ABI | 02:36 |
| wookey | yes that mostly works | 02:36 |
| wookey | but it's not hard to imagine a world where it might be reasonable to have 2 | 02:37 |
| wookey | hmm. I only came here to say that I'd build a libc, not to have a half-hour argument :-) | 02:39 |
| wookey | hmm. hour in fact | 02:39 |
| wookey | at least one of us is very argumentative :-) | 02:40 |
| infinity | I blame you. :) | 02:40 |
| infinity | And yeah, I know cross-base works now, I tested it before I committed the glibc fix. | 02:40 |
| infinity | It'll all get uploaded soon, but the buildds are currently having heart attacks. | 02:41 |
| infinity | So, I think I'll watch a movie, then do uploads. :P | 02:41 |
| infinity | wookey: You should be in bed, young man. | 02:42 |
| wookey | yeah it's getting that way. I'll just kick off another perl build before giving up for the night | 02:42 |
| wookey | getting it to cross _and_ multiarch is proving to be annoying | 02:42 |
| doko_ | young? | 02:43 |
| infinity | doko_: Compared to you, I'm sure he is. | 02:44 |
| doko_ | hmm, he doesn't look so | 02:44 |
| infinity | Doesn't he? He looks like the sort who probably started balding at 17. | 02:45 |
| infinity | He probably also hates it when people talk about him in the third person when he's right here. | 02:45 |
| wookey | I beat a young man at squash today | 02:53 |
| wookey | his age is about the same as number of years since I last played... | 02:53 |
| wookey | fortunatey he was rubbish at it... | 02:54 |
| wookey | infinity: want to guess how old I am ? :-) | 03:24 |
| infinity | wookey: My guess is "younger than doko". But that's a wide range. He remembers WWII. | 03:24 |
| === rsalveti_ is now known as rsalveti | ||
| === forcev is now known as FunkyPenguin | ||
| === hatake is now known as daenglinuxx | ||
| dholbach | good morning | 07:48 |
| === chihchun is now known as zz_chihchun | ||
| === zz_chihchun is now known as chihchun | ||
| ogra_ | xnox, awesome fix for usb-creator !!! | 09:24 |
| xnox | ogra_: not my idea ;-) but i'll take the credit for uploading. | 09:34 |
| ogra_ | heh | 09:35 |
| === yofel_ is now known as yofel | ||
| === daenglinuxx is now known as terlalu | ||
| === terlalu is now known as blackjack | ||
| janimo | ogra_, xnox does usb-creator start when a nexus is plugged in? | 11:20 |
| xnox | janimo: or package upgraded. | 11:21 |
| xnox | (the latter is a bug currently) | 11:21 |
| ogra_ | yes, and in on other occasions :) | 11:22 |
| ogra_ | -in | 11:22 |
| * xnox should fix it otherwise i'll be pinged about it all day long. | 11:22 | |
| ogra_ | haha | 11:23 |
| janimo | I was just wondering that for many users it may be just another android device they want to exchange files with and not necessarily flash ubuntu on | 11:24 |
| xnox | janimo: it checks for nexus7 only. and i was thinking to also check if fastboot detects it. | 11:25 |
| janimo | right, nexus7 only. | 11:26 |
| xnox | but yeah, it shouldn't popup unless nexus7 is in the fastboot bootloader mode. | 11:26 |
| janimo | ok, so no surprises for people who don't know what bootloader mode is | 11:27 |
| === doko_ is now known as doko | ||
| doko | ogra_, is there no 3.8 kernel for the panda board? | 12:00 |
| ogra_ | doko, ask ppsati ... iirc he works on devicetree support in our main kernel to make pandas work ... but thats not done yet | 12:08 |
| ogra_ | (and will stand and fall with support for the binary driver) | 12:08 |
| ogra_ | the current images are still on the quantal kernel until thats done | 12:10 |
| === mhaberler_ is now known as mhaberler | ||
| === XenGi is now known as XenGi_ | ||
| === chihchun is now known as zz_chihchun | ||
| === Quintasan_ is now known as Quintasan | ||
| === albert_ is now known as Phryq | ||
| sveinse | After debugging for a day of the failing initramfs script I've found that umount a loopback device in initramfs, leaves the losetup device bound to the target file. Shouldn't umount handle losetup -d itself? It certainly did so for binding/finding an available loop device | 17:55 |
| prpplague | if anyone is interested i have two brand new phytec omap4 kits for sale as well as a lightly used snowball board - give me a ping if you are interested | 21:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!