**** BEGIN LOGGING AT Wed Feb 06 02:59:58 2013
Feb 06 05:44:06 <hrw> infinity: will make such
Feb 06 07:52:58 <dholbach> good morning
Feb 06 11:35:10 <hrw> infinity: linux-meta-chromebook uploaded
Feb 06 14:39:56 <dholbach> can somebody please reply to the comment on  https://plus.google.com/u/0/109795858099658821877/posts/JKQWnaRVqC1?cfem=1 ?
Feb 06 14:40:58 <ogra_> will do if i'm on a sane machine
Feb 06 14:41:23 <ogra_> (nexus7 isnt so great for typing ;) )
Feb 06 14:55:25 <fly-away> any tablet isnt so great for typing afaik
Feb 06 14:55:32 <fly-away> even ipad
Feb 06 15:01:22 <ogra_> its fine, i use it for hours every evening (i banned all other machinery from my living room)
Feb 06 15:01:34 <ogra_> but not for answering posts with long texts :)
Feb 06 15:04:22 <VarmVaffel> I'm trying to use a regular C write() operation on a i2c bus, but it keeps timing out
Feb 06 15:04:59 <VarmVaffel> could this be because the bus is always too busy, or would I get other error messages then?
Feb 06 15:06:27 <VarmVaffel> Im' using the /dev/i2c interface
Feb 06 15:28:29 <dholbach> thanks ogra_
Feb 06 15:29:13 <ogra_> welcome
Feb 06 15:29:28 <ogra_> might be that he uses an old version of the dual boot image
Feb 06 15:29:41 <ogra_> that had issues with kernel updates
Feb 06 15:30:37 <dholbach> ah yes
Feb 06 15:31:42 <ogra_> (fixed in newer versions of that image, Tassadar is very responsive to fixes :) )
Feb 06 15:34:13 <Tassadar> well, at least that I can do)
Feb 06 15:50:08 <sveinse> Why wouldn't the kernel allow me to umount something I've just mounted in initramfs (local-premount)? I'm getting Device or resource busy
Feb 06 16:01:25 <ogra_> sveinse, lsof ?
Feb 06 16:01:28 <ogra_> or fuser
Feb 06 16:02:04 <sveinse> well neither is included in initramfs afaiks
Feb 06 16:05:44 <sveinse> hmmm. "error: couldn't mount because of unsupported optional features (240)" <-- that is probably why I can't umount it afterwards. Perhaps mount needs to be told explicitly that this is ext4 not ext2
Feb 06 16:07:00 <ogra_> no
Feb 06 16:07:19 <ogra_> if you dont specify a fs the kernel just loops over all the ext* ones
Feb 06 16:07:33 <ogra_> these messages are from probing, not from the actual mount
Feb 06 16:07:58 <sveinse> No, they come when I call mount
Feb 06 16:08:42 <sveinse> Ah. I see. Scratch that. EXT3-fs fails, EXT2-fs fails EXT4-fs mounts
Feb 06 16:09:25 <sveinse> sooo. how come I cant umount afterwards...
Feb 06 16:13:13 <ogra_> something has a file open in your mountpoint
Feb 06 16:22:51 <sveinse> I need a fresh set of eyes on this:
Feb 06 16:23:00 <sveinse>  mount -t vfat /tmp/sr/root/data.img /tmp/sr/data.img -o loop
Feb 06 16:23:29 <sveinse>  umount -f /tmp/sr/root/data.img
Feb 06 16:23:38 <sveinse> umount: can't forcibly umount /tmp/sr/root/data.img: Invalid argument
Feb 06 16:24:04 <sveinse> Does it require the mount device to be specified, not the mount point?
Feb 06 16:24:34 <Tassadar> umount requires the folder to which it was mounted to I think
Feb 06 16:25:32 <ogra_> either should work, though -f might not work on loop mounts, not sure
Feb 06 18:53:53 <wookey> infinity: Can you peruse https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1117602 and tell me if you understand what's going on?
Feb 06 18:53:54 <ubot2> Ubuntu bug 1117602 in eglibc (Ubuntu) "eglibc does not crossbuild for arm64" [Undecided,New]
Feb 06 18:56:28 <infinity> wookey: multiarch doesn't mean what you think it means.
Feb 06 18:57:10 <wookey> right. That's what I was thinking
Feb 06 18:57:32 <wookey> but it's turned on for all arches, I'm just trying what happens if I turn it off for arm64
Feb 06 18:57:46 <wookey> What will that break?
Feb 06 18:57:50 <infinity> wookey: Anyhow, I was going to rev cross-base stuff today.  Let me play with this.
Feb 06 18:58:32 <wookey> OK, there are a couple of patches in there that need merging I think.
Feb 06 18:58:57 <wookey> So that cross-building from the normal source works
Feb 06 18:59:41 <infinity> I'm on top of it.  Don't worry.
Feb 06 19:00:05 <wookey> I guess we should either fix whatever is wrong with dh_shlibdeps or put 'if cross-building don;t do this' round it properly
Feb 06 19:00:40 <wookey> the disable selinux patch is wrong (should be controlled by DEB_STAGE, not just nobbled)
Feb 06 19:01:08 <wookey> arm64 no profile is good
Feb 06 19:01:16 <infinity> The DEB_STAGE stuff all needs fiddling.
Feb 06 19:01:21 <infinity> And the no profile patch is obsolete.
Feb 06 19:01:28 <wookey> yes
Feb 06 19:02:10 <infinity> The dh_shlibdeps thing may or may not still be necessary, I fixed a bunch of things relating to that sort of thing in 2.17, but I'm not sure what the point of the patch was.
Feb 06 19:02:16 <wookey> I'm not sure about the others.
Feb 06 19:02:20 <infinity> Like I said, I'm fiddling with this today.
Feb 06 19:02:31 <wookey> OK. I'll let you poke and go back to perl :-)
Feb 06 19:02:52 <infinity> I'm not entirely sure what the point of the locales patch is either, except to very marginally speed up the build, perhaps.
Feb 06 19:02:57 <wookey> Keen to test though cos I can;t build anything automatically without a buildable libc. SO when yuo think it might go...
Feb 06 19:03:04 <wookey> yes. I'd ignore that
Feb 06 19:03:32 <wookey> Or at least it can stay in cross-base
Feb 06 19:11:44 <infinity> wookey: Wait, is this a cross-only issue, or is arm64 really the only arch that doesn't support IFUNC?
Feb 06 19:12:09 <plars> do we not continue to produce preinstalled images for omap4 on precise?
Feb 06 19:14:33 <infinity> plars: Nope.
Feb 06 19:21:51 <infinity> wookey: Anyhow, it's entirely possible we don't need enable-multiarch for arm64 at all right now, given that aarch64 only has one subarch.
Feb 06 19:36:39 <infinity> wookey: So, yeah, I'll disable multiarch on aarch64 for now.  That seems the sane and reasonable thing.  As Roland points out, any case of this "working" before when it shouldn't have was broken, so this isn't a regression, but a fix. :P
Feb 06 19:37:23 <infinity> wookey: I suspect ARM will probably want ifun/multi-arch madness when armv8 starts to rev with new features, but we'll cross that bridge when we get there.
Feb 06 19:37:28 <infinity> ifunc*
Feb 06 19:38:25 <infinity> wookey: (Basically, this isn't what you think multi-arch is, in the Debian sense, this is being able to build DSOs that contain multiple versions of symbols for different subarches)
Feb 06 19:38:54 <infinity> wookey: So, it was always a mistake that it was in the arm64.mk config in Debian/Ubuntu, it was just luck that it "worked" cause the test was broken.
Feb 06 19:39:03 <infinity> wookey: I'll push fixes for this to experimental/raring today.
Feb 06 19:46:47 <infinity> wookey: I had to do an experimental build to fix mips/mipsel anyway, so this makes me feel less bad about it if I have something else to upload for. :P
Feb 06 22:13:32 <wookey> infinity: right, yes as you say, confusion over what 'multi-arch' meant and luck that it built/worked on 2.16
Feb 06 22:13:47 <wookey> yes aarch64 probably is the only one without ifunc support
Feb 06 22:14:20 <wookey> ifunc is coming, I'm told, jus tnot done yet
Feb 06 22:14:41 <infinity> wookey: All fixed in Debian SVN, at any rate, and tested locally.  Just fixing one more thing before I upload.
Feb 06 22:15:17 <wookey> cool
Feb 07 01:29:39 <wookey> infinity: OK, with that stage2 patch and removing --enable-multiarch it at least completes a cross-build here
Feb 07 01:34:32 <twb> Remind me, what's the SoC that's pre-armv7, but still being made?  IIRC there's r-pi and one other.
Feb 07 01:40:36 <wookey> I don;t suppose the rpi soc is still being made, just the boards, using up large stock of videocore 2xxx chips
Feb 07 01:41:00 <wookey> pxa270 is still available I believe
Feb 07 01:41:12 <twb> Hum, OK
Feb 07 01:41:40 <wookey> and various marvell devices which are v6
Feb 07 01:41:40 <twb> The context is me telling people to stop getting excited about rpi because armv6 is obsolete and sucky :-)
Feb 07 01:41:53 <wookey> yes, keep doing that. I do it too
Feb 07 01:42:04 <twb> Ah, right.  My memory said it was marvell dove, but that's v7
Feb 07 01:42:41 <wookey> OK I thought 'dove'. WHat about armada? Maybe it's an earlier one that is v6
Feb 07 01:44:12 <infinity> dove and armadap are all the same general family.
Feb 07 01:44:14 <wookey> armada seems to be v7
Feb 07 01:44:22 <infinity> There are some v6 devices in said family, but none worth talking about.
Feb 07 01:44:24 <twb> dove sucks because it has no NEON, not because it is pre-v7
Feb 07 01:44:59 <infinity> Anyhow, telling people to move to v7 is sane messaging, IMO.
Feb 07 01:45:12 <wookey> so, yes it's geting hard to find things still made which aren;t v7
Feb 07 01:45:30 <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.
Feb 07 01:45:52 <infinity> Pretty much all general-purpose ARM computing should be moving/moved to v7 and v8, IMO.
Feb 07 01:45:59 <wookey> and that we still haven't put ISA info into dpkg metadata
Feb 07 01:45:59 <infinity> (I might be biased)
Feb 07 01:46:19 <wookey> we're going to get the same prob with v8 32 bit ISA at some point...
Feb 07 01:46:31 <infinity> wookey: What v8 32-bit ISA?
Feb 07 01:46:36 <wookey> it'd be nice to put the machinery in so dpkg can just DTRT
Feb 07 01:46:47 <wookey> aarch32
Feb 07 01:46:50 <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.
Feb 07 01:47:01 <wookey> no there are a few extra instructions
Feb 07 01:47:17 <wookey> so it's the same ABI, but new instructions
Feb 07 01:47:30 <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. :/
Feb 07 01:47:47 <infinity> Oh, same ABI as v7?
Feb 07 01:47:50 <infinity> Well, that's not a big deal.
Feb 07 01:47:51 <wookey> and yes at some point people will want to do 'x32 for arm' - just watch them...
Feb 07 01:48:21 <infinity> Same ABI and new insns just means glibc caps.
Feb 07 01:48:23 <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
Feb 07 01:48:48 <wookey> agreed, but dpkg needs to know too so it can download the right version
Feb 07 01:48:55 <infinity> We don't write that down because we intend for an entirely self-contained distro to have the same basline ISA.
Feb 07 01:48:58 <infinity> Anything else is madness.
Feb 07 01:49:04 <infinity> Err, no.
Feb 07 01:49:09 <twb> infinity: doing x32 on x86 systems is already a dirty hack
Feb 07 01:49:10 <infinity> "download the right version"?
Feb 07 01:49:22 <wookey> well not try to install versions that won't run
Feb 07 01:49:30 <infinity> wookey: You can't have two armhf debs in the same version.
Feb 07 01:49:41 <infinity> This isn't actually a problem.  At all.
Feb 07 01:49:43 <wookey> i.e ubuntu armhf packages on RPis
Feb 07 01:49:51 <infinity> If you don't want to install wrong-ISA debs, don't use the wrong apt source.
Feb 07 01:50:07 <infinity> wookey: Or Ubuntu i386 debs on Debian. :P
Feb 07 01:50:09 <wookey> why not make it possible to enforce that?
Feb 07 01:50:12 <infinity> wookey: This isn't a problem.  It's really not.
Feb 07 01:50:31 <wookey> It's not hard to fix though either.
Feb 07 01:50:40 <infinity> I disagree.
Feb 07 01:50:47 <wookey> just write down the caps used in the metadata
Feb 07 01:50:51 <infinity> You have zero idea what the contents of the deb are without disassembling.
Feb 07 01:51:07 <infinity> You can make some sort of assumptions based on your custom copy of dpkg, if that's what you mean.
Feb 07 01:51:09 <wookey> you know when you build it - or at least you know what you meant to build
Feb 07 01:51:20 <infinity> But, again, I don't see how this is a problem.
Feb 07 01:51:31 <infinity> You're running Raspbian, you install Raspbian debs.
Feb 07 01:51:38 <infinity> People keep making this sound like a big deal and it's not.
Feb 07 01:51:48 <wookey> No-one tries to install3rd party debs on their rpis?
Feb 07 01:51:59 <infinity> I don't really care if they do.
Feb 07 01:52:06 <wookey> from all those bazillions of ppas?
Feb 07 01:52:11 <wookey> the users might care
Feb 07 01:52:16 <infinity> In your scenario, people trying to install Ubuntu debs on Debian wouldn't be allowed.
Feb 07 01:52:25 <infinity> (And they shouldn't anyway, but now dpkg would enforce it)
Feb 07 01:52:41 <wookey> only if their debian hardware couldn't run v7
Feb 07 01:52:48 <wookey> in which case that would be good
Feb 07 01:52:53 <infinity> I'm talking i386, actually.
Feb 07 01:53:29 <wookey> and this is useful for mplayer-686 and other stuff currently bodged into the packagenames
Feb 07 01:53:31 <infinity> Okay, so you're saying that dpkg should check the running system to determine caps at that moment.
Feb 07 01:53:39 <infinity> That entirely breaks portability of system roots.
Feb 07 01:54:02 <infinity> It's not useful for mplayer-686 at all.
Feb 07 01:54:06 <wookey> If I told it to yes. I expect I'm allowed to turn it off for cross-choots
Feb 07 01:54:29 <infinity> Because you can still only have one mplayer.deb in any apt source.
Feb 07 01:54:37 <infinity> So if you want an optimised one, you need another package name.
Feb 07 01:54:41 <wookey> but I can have more than one apt source
Feb 07 01:54:51 <infinity> But mplayer-686 isn't in another source.
Feb 07 01:54:53 <infinity> And shouldn't be.
Feb 07 01:54:56 <infinity> That's user hostile.
Feb 07 01:55:22 <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.
Feb 07 01:55: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.
Feb 07 01:56:05 <wookey> That doesn't seem user-hostile to me
Feb 07 01:56:18 <infinity> Most of your use-cases are user-hostile.
Feb 07 01:56:27 <infinity> Like, adding extra sources to get optimised packages.
Feb 07 01:56:46 <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.
Feb 07 01:57:07 <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
Feb 07 01:57:24 <infinity> wookey: Either way, dpkg installs system roots.  Saying "that won't run on the hardware you have RIGHT NOW" is meaningless.
Feb 07 01:57:47 <infinity> wookey: I could install a sysroot on i686 and give it to someone with an i585 and it won't run.
Feb 07 01:58:05 <infinity> wookey: And no, it wouldn't let you optimise anything in the primary archive any more than you already do.
Feb 07 01:58:09 <wookey> sometimes. most of the time stuff is installed onthe system it's going to be run on.
Feb 07 01:58:19 <infinity> wookey: And optimising out-of-archive is *drum rull* user-hostile.
Feb 07 01:58:22 <wookey> you can check against the target if you know what it's going to be
Feb 07 01:58:35 <infinity> wookey: That's a blatant lie in the Ubuntu case (or any live installer).
Feb 07 01:58:48 <infinity> wookey: The install is always done on a system that isn't the target.
Feb 07 01:59:16 <wookey> OK, so you don;t think it's useful. fair enough
Feb 07 01:59:32 <infinity> I think people need to learn to detect CPU features.
Feb 07 01:59:39 <infinity> Your example above (mplayer) actually has.
Feb 07 02:00:00 <sim590> I want W*h (Joules) or coulons (that's in french though.. its intensity (c/s)
Feb 07 02:00:03 <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.
Feb 07 02:00:38 <wookey> OK, so then it doesn;t need to ask for caps it can live without
Feb 07 02:00:55 <wookey> whichis fine
Feb 07 02:01:14 <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.
Feb 07 02:01:19 <infinity> And the answer to that is "stop doing that".
Feb 07 02:01:49 <wookey> but what if the server people start asking for lots of v8 optimised binaries because it's loads faster?
Feb 07 02:02:03 <wookey> we can just say no
Feb 07 02:02:15 <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.
Feb 07 02:02:19 <wookey> but if we can easily accomodate it with a check I don;t see why that's bad
Feb 07 02:02:40 <infinity> Do you think the "server people" are going to ask for 32-on-64 anytime soon anyway?
Feb 07 02:02:46 <infinity> Anyhow.
Feb 07 02:02:49 <infinity> This doesn't solve that.
Feb 07 02:02:56 <infinity> You still need either a new dpkg arch, or a new distro.
Feb 07 02:02:59 <twb> Can someone confirm that current ubuntu armel uses -mfpu=softfp (i.e. doesn't require hardware FPU)?
Feb 07 02:03:08 <infinity> Cause you can't.  Have.  The.  Same.  Deb.  Twice.  In.  The.  Same.  Archive.
Feb 07 02:03:13 <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.
Feb 07 02:03:17 <infinity> twb: There is no ubuntu armel.
Feb 07 02:03:18 <twb> It's not very clear on the wiki ARM article
Feb 07 02:03:34 <twb> infinity: hah, so it's just "arm" now?
Feb 07 02:03:35 <infinity> twb: Did that help?
Feb 07 02:03:46 <infinity> twb: armhf.  We dropped armel.
Feb 07 02:04:03 <infinity> twb: And armhf most definitely required an FPU.  vfpv3-d16
Feb 07 02:04:10 <infinity> s/required/requires/
Feb 07 02:04:43 <twb> It would be nice if https://wiki.ubuntu.com/ARM made that more obvious
Feb 07 02:04:54 <wookey> it's a wiki....
Feb 07 02:05:09 <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.
Feb 07 02:05:19 <infinity> wookey: And if they rebuild the archive, we're in "not the same distribution" land.
Feb 07 02:06:28 <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
Feb 07 02:06:52 <wookey> that would have made the rasbian's people's lives a lot easier, for example
Feb 07 02:07:14 <wookey> but OK. I get it that you're not keen :-)
Feb 07 02:07:18 <raster> wookey: rpi is just a piece of pretty crappy hw. deal with it. its a very outdated instructionset versions pushed out for cheap.
Feb 07 02:07:45 <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 фі ф ифіудшту
Feb 07 02:07:49 <raster> err
Feb 07 02:07:53 <raster> armv7 as a baseline
Feb 07 02:08:05 <wookey> I know.
Feb 07 02:08:14 <wookey> it's just an example.
Feb 07 02:08:26 <wookey> because people _have_ gone to the trouble of rebuilding the whole distro
Feb 07 02:08:45 <wookey> for a different ISA
Feb 07 02:09:00 <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
Feb 07 02:09:01 <raster> reality is armv7hf+neon should be the baseline
Feb 07 02:09:08 <raster> and thats a very decent baseline with not much above it
Feb 07 02:09:11 <wookey> twb: sadly not
Feb 07 02:09:19 <infinity> wookey: Err, we can't do more than one without them being in separate archives.
Feb 07 02:09:31 <raster> in x86 land we have also a wide range
Feb 07 02:09:54 <infinity> twb: archive/ports has nothing to do with supported, but with popularity/traffic.
Feb 07 02:10:10 <wookey> right, and it'd be nice if those archives were labelled with the capabilities needed to run them - that's all
Feb 07 02:10:15 <raster> most of the compiling is fine-tuning small percentages of per increase
Feb 07 02:10:32 <raster> the few where its big should be the task of the software itself to detect at runtime
Feb 07 02:10:41 <infinity> raster: Exactly.
Feb 07 02:10:44 <raster> most of that is in in either gfx/video/audio
Feb 07 02:11:04 <raster> and the specific apps and/or libs already "compile all possibilities in" and auto-detect at runtime
Feb 07 02:11:10 <infinity> Like the canonical examples of ffmpeg/libav, libjpeg-turbo, and mplayer.
Feb 07 02:11:14 <raster> eg they probe for mmx/sse/sse3/4 or neon etc.
Feb 07 02:11:19 <infinity> Which all do lovely autodetection these days.
Feb 07 02:11:22 <raster> and they enable specific optimized codepaths for that
Feb 07 02:11:36 <wookey> youre' not telling me anything I don;t already know
Feb 07 02:11:37 <raster> they COULd recompile the same C code into multiple .o's and link them in with differingt entry symbols
Feb 07 02:12:12 <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.
Feb 07 02:13:19 <raster> then why does the PACKAGE SYSTEM need to have anything to do with this?
Feb 07 02:13:22 <raster> if u already know it?
Feb 07 02:13:33 <raster> and already know that its solved within the code of libs/binaries?
Feb 07 02:13:35 <doko_> you still can use hwcap for these cases
Feb 07 02:14:04 <wookey> a few binaries do this - the great majority don't.
Feb 07 02:14:37 <infinity> wookey: The vast majority don't need to.
Feb 07 02:14:42 <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)
Feb 07 02:14:42 <wookey> agreed.
Feb 07 02:15:05 <raster> then whats the point here?
Feb 07 02:15:08 <wookey> but if we added simple hwcaps info then peope could if they wanted
Feb 07 02:15:21 <raster> if those that need to (ie have a decent gain) do it already.. why does the pkgssystem need to bother?
Feb 07 02:15:37 <wookey> just to save people from installing binaries they can;t run
Feb 07 02:15:49 <raster> this should never be done at pkgs install time
Feb 07 02:15:50 <raster> its horrible
Feb 07 02:15:53 <wookey> e.g v7 on v5 hardware
Feb 07 02:15:57 <infinity> And we're back to square one. Why would they be installing a distro they can't run? :P
Feb 07 02:16:04 <wookey> why is it 'horrible'
Feb 07 02:16:06 <raster> it is ASSUMINg the ultimate target system is the same one that is doing the installing now
Feb 07 02:16:17 <wookey> raster: read the backlog :-)
Feb 07 02:16:21 <raster> thats a horrid assumption i KNOw breaks continually
Feb 07 02:16:43 <infinity> raster: You're making all my same arguments for me again. :)
Feb 07 02:16:44 <wookey> I don't thin kthis conversation is getting anyone anwyhere
Feb 07 02:16:47 <raster> things like scratchbox, OBS, making debootstrap chroots etc...
Feb 07 02:16:50 <infinity> Which is great, I can just tag you in and go have dinner.
Feb 07 02:16:56 <raster> heheheh
Feb 07 02:16:57 <raster> :)
Feb 07 02:17:33 <raster> tbh... pkg installation should be not much more than "unpack files"
Feb 07 02:17:34 <twb> http://paste.debian.net/232365/ did I get everything right?
Feb 07 02:17:53 <raster> anything more than that (other than handling dependencies) is a workaround broken software :)
Feb 07 02:18:05 <wookey> it could be  'unpack best avaialble files'
Feb 07 02:18:24 <raster> it shoudl just ship all possible needed files and choose at runtime
Feb 07 02:19:10 <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.
Feb 07 02:19:19 <raster> and that choice is in the hands of the sw devs to deal with
Feb 07 02:19:24 <raster> not packaging
Feb 07 02:19:33 <twb> infinity: thanks
Feb 07 02:19:42 <wookey> but every package does actually _have_ a specified ISA
Feb 07 02:19:50 <wookey> we just don;t write down what it is in the packages
Feb 07 02:19:50 <infinity> twb: Also, the SATA comment is out-of-date WRT many modern SoCs.
Feb 07 02:20:19 <infinity> twb: Lots of A15s have native SATA, and some A9 packages do.
Feb 07 02:20:20 <twb> OK
Feb 07 02:20:50 <infinity> twb: And some clever setups, like the Trimslice, use PCIe SATA on a native PCIe port.
Feb 07 02:21:43 <infinity> wookey: If we specify the baseline ISA for the distro, we don't need it encoded at the packaging level and muddied up.
Feb 07 02:22:50 <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)
Feb 07 02:24:35 <wookey> do libc6 and libc6-686 have the same baseline ISA?
Feb 07 02:25:10 <wookey> how does dpkg currently choose the best one?
Feb 07 02:25:19 <infinity> wookey: dpkg doesn't, you do.
Feb 07 02:25:28 <infinity> wookey: There's not mutually exclusive, you can install both.
Feb 07 02:25:34 <wookey> right but I'm a clueless newbie - how should I know?
Feb 07 02:25:35 <infinity> wookey: They use ld.so hwcaps.
Feb 07 02:25:49 <infinity> wookey: We tend to just install both for you, to be fair. :P
Feb 07 02:26:13 <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.
Feb 07 02:26:27 <infinity> For people who really, really only want the baseline one and want a tiny system.
Feb 07 02:28:12 <infinity> The only way to be remotely user-friendly and have portable roots is to ship code that works everywhere and optimised at runtime.
Feb 07 02:28:26 <infinity> s/optimised/optimises/
Feb 07 02:29:06 <infinity> Rebuilding the distro 9 times for 9 different hwcap combinations also turns into a debugging nightmare.
Feb 07 02:29:40 <wookey> right. but we probably wouldn't do 9
Feb 07 02:29:48 <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.
Feb 07 02:30:51 <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.
Feb 07 02:31:02 <infinity> wookey: Every new fancy, people would want an optimised build "just cause".
Feb 07 02:31:22 <raster> -funroll-loops
Feb 07 02:31:27 <raster> wewt
Feb 07 02:31:28 <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
Feb 07 02:32:01 <raster> auto-vectorization candiates are mostly handled by hand-crafted asm anyway
Feb 07 02:32:12 <infinity> As well they should be.
Feb 07 02:32:33 <infinity> And once you're hand-crafting, runtime detection is, like, two extra instructions.
Feb 07 02:32:36 <infinity> So, don't be a lazy git.
Feb 07 02:33:39 <infinity> It's a shame that hwcaps isn't portable outside the GNU world.
Feb 07 02:33:47 <infinity> Cause "you can just ask glibc" is also quite nice.
Feb 07 02:35:57 <wookey> well distros get to choose how many falvours are worth supporting
Feb 07 02:36:17 <wookey> but without this labelling you can only support one ISA flavour per ABI
Feb 07 02:36:32 <wookey> yes that mostly works
Feb 07 02:37:13 <wookey> but it's not hard to imagine a world where it might be reasonable to have 2
Feb 07 02:39:22 <wookey> hmm. I only came here to say that I'd build a libc, not to have a half-hour argument :-)
Feb 07 02:39:49 <wookey> hmm. hour in fact
Feb 07 02:40:09 <wookey> at least one of us is very argumentative :-)
Feb 07 02:40:42 <infinity> I blame you. :)
Feb 07 02:40:58 <infinity> And yeah, I know cross-base works now, I tested it before I committed the glibc fix.
Feb 07 02:41:17 <infinity> It'll all get uploaded soon, but the buildds are currently having heart attacks.
Feb 07 02:41:48 <infinity> So, I think I'll watch a movie, then do uploads. :P
Feb 07 02:42:04 <infinity> wookey: You should be in bed, young man.
Feb 07 02:42:26 <wookey> yeah it's getting that way. I'll just kick off another perl build before giving up for the night
Feb 07 02:42:44 <wookey> getting it to cross _and_ multiarch is proving to be annoying
Feb 07 02:43:40 <doko_> young?
Feb 07 02:44:35 <infinity> doko_: Compared to you, I'm sure he is.
Feb 07 02:44:55 <doko_> hmm, he doesn't look so
Feb 07 02:45:15 <infinity> Doesn't he?  He looks like the sort who probably started balding at 17.
Feb 07 02:45:32 <infinity> He probably also hates it when people talk about him in the third person when he's right here.
Feb 07 02:53:36 <wookey> I beat a young man at squash today
Feb 07 02:53:55 <wookey> his age is about the same as number of years since I last played...
Feb 07 02:54:20 <wookey> fortunatey he was rubbish at it...
**** ENDING LOGGING AT Thu Feb 07 02:59:58 2013