**** BEGIN LOGGING AT Sun Feb 05 02:59:59 2012 Feb 05 03:14:17 joined Feb 05 03:15:42 excuse me Feb 05 03:18:42 excuse me Feb 05 04:23:24 I am trying to build ubuntu oneiric kernel in a armel cross chroot Feb 05 04:23:57 I am unable to build because of the following error: scripts/kconfig/zconf.tab.c:2505:0: internal compiler error: in insert_vi_for_tree, at tree-ssa-structalias.c:2740 Feb 05 04:24:06 I was wondering if anyone has seen this Feb 05 04:33:58 hmm... wouldn't it be easier to cross-compile it outside the qemu-environment with CROSS_COMPILE=arm-linux-gnueabi-? Feb 05 04:35:23 mythos: I thought using a cross chroot I can leave my host environment unmodified Feb 05 04:36:10 qemu does have some issues if a process needs to much memory (in my experience) Feb 05 04:36:33 hmm Feb 05 04:36:47 and you can set up a cross-compile-environment inside the chroot ;-) Feb 05 04:37:05 ;) Feb 05 04:40:22 but in fact, that was my my first shot/try also... it works, but has it's limits Feb 05 04:41:28 ok Feb 05 04:41:44 I tried removing -O2 from KBUILD_CFLAGS still no luck :) Feb 05 04:41:59 s/)/(/ Feb 05 04:42:16 yeah, that's the first hit google gives you, if you run in such problems ;-) Feb 05 04:42:48 i was lucky and it worked with python2.4... Feb 05 04:43:52 so, you should really try a cross-compilation or a native build Feb 05 04:44:08 I tried a native build Feb 05 04:44:12 I am seeing segfaults Feb 05 04:44:38 I already have the 768MB work around Feb 05 04:44:51 http://pastebin.com/pmSbm4pd Feb 05 04:45:47 oh, than your last shot is cross-compilation Feb 05 04:46:01 *then Feb 05 04:46:15 I am trying to avoid it if possible Feb 05 04:46:27 probably setup a chroot and cross build inside that Feb 05 04:47:39 wonder how the kernels are built in ports Feb 05 04:48:13 are they cross built or in cross chroot :p Feb 05 04:48:57 if you are idling long enough, one from canonical's arm-team will surely answer your question Feb 05 04:49:24 but, i'think, they said that they use panda-boards to compile their packages Feb 05 04:50:10 that would take forever Feb 05 04:50:20 compiling on the pandaboard is so slow Feb 05 04:50:33 look at the topic... Feb 05 04:52:41 interesting if they are building everything on pandaboards Feb 05 04:58:02 yeah... i have to consider this too... Feb 05 04:59:24 if they use native builds for everything, maybe i should that too for my projects Feb 05 05:03:51 probably some of the devs could answer this Feb 05 05:09:24 krosswindz, maybe out of context, but that's what i found in the channel history http://pastebin.com/DEcZvhj9 Feb 05 05:11:21 mythos: guess they are using pandaboards as buildd Feb 05 05:12:08 i guess so too Feb 05 05:14:06 guess I might switch precise and see if that solves my build issues Feb 05 05:14:38 go for it =) Feb 05 05:20:03 will try armhf if it doesnt work I can always revert back to oneiric Feb 05 05:20:17 should get a couple of more sd cards :p Feb 05 05:21:45 if possible, i would use a nfs configuration Feb 05 05:22:11 my board is able to load linux via tftp and rootfs via nfs Feb 05 05:22:51 but it is a uncommon ti board. i don't have a panda or anything else Feb 05 05:23:52 maybe all u-boots can do this... Feb 05 05:26:16 uboots can do it Feb 05 05:26:29 the x-loader has an option on the pandaboard to boot using tftp Feb 05 05:26:34 I havent tried it though Feb 05 05:27:27 it is a really neat feature =) Feb 05 05:41:45 where can i get debian-installer images for qemu? Feb 05 05:46:57 scientes_, i think, you are looking for this http://wiki.debian.org/ArmEabiHowto Feb 05 05:47:12 no, found what i needed: https://wiki.ubuntu.com/Core Feb 05 05:47:27 (if there are arm versions...) Feb 05 05:47:42 i am trying to install ubuntu arm in qemu Feb 05 05:47:59 to test some software that fails in debian arm and x86_64, but works in ubuntu x86_64 Feb 05 05:48:17 *debian armel, when compiled from source Feb 05 05:48:32 "Installing armel to qemu with d-i" <-- but if you found what you are looking for, that's also awesome =) Feb 05 05:48:43 hmmmm, actually, emulated compiling is probably too slow Feb 05 05:49:03 mythos, yes, but where is the d-i for UBUNTU Feb 05 05:49:12 i.e. alternate installer in ubuntu-land Feb 05 05:49:25 I guess i will need to use a chroot or something on my arm device Feb 05 05:49:36 that was not what you asked for ;-) Feb 05 05:49:52 well, this is #ubuntu-arm Feb 05 05:49:54 mythos: Sure it is. Feb 05 05:49:56 i thought it was implied Feb 05 05:50:05 mythos: debian-installer implies the software, not the distro. Feb 05 05:50:14 infinity, precisely Feb 05 05:50:26 scientes_: http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armel/current/images/linaro-vexpress/netboot/ Feb 05 05:50:54 infinity, hmm... i'm not sure, if i understood that? so debian-installer ist capable to install ubuntu? Feb 05 05:51:00 scientes_: Unfortunately, we don't provide vexpress netboot images for armhf yet. I should put that on my TODO before I forget again. Feb 05 05:51:20 mythos: debian-installer is the underlying technology for all our installers. Feb 05 05:51:23 infinity, which one would be faster for emulation? Feb 05 05:51:47 infinity, except liveCD IIRC Feb 05 05:52:04 scientes_: ubiquity uses d-i components to do all the "real work". Feb 05 05:52:16 scientes_: (ubiquity being the GUI livecd installer) Feb 05 05:52:23 infinity, ahh, now i know Feb 05 05:52:36 i though it just copied the image Feb 05 05:52:46 Copying is the easy part. ;) Feb 05 05:52:47 (ish) Feb 05 05:52:48 the squashfs image, with cp -a or something Feb 05 05:53:00 instead of installing every deb seperately Feb 05 05:53:00 It copies the squashfs, and then runs all the d-i bits inside the target. Feb 05 05:53:14 infinity, i don't want to argue against it. so i apologize Feb 05 05:53:33 fedora is differn't, cause their livecd doesn't support anything but ext4 Feb 05 05:53:41 mythos: I suppose you could argue if you wanted. ;) Feb 05 05:53:43 as a limitation of the way they are doing it IIRC Feb 05 05:53:55 infinity, sure... ;-) Feb 05 05:54:32 but on a differn't note: is compiling in qemu going to be horribly slow? Feb 05 05:54:40 scientes_: Yes. Feb 05 05:54:44 and will i have better luck with a chroot on a real, but slow, arm device Feb 05 05:54:57 scientes_: On the fastest hardware we can get our hands on, qemu barely beats out a pandaboard. Feb 05 05:55:03 scientes_: And you probably don't have that hardware. Feb 05 05:55:15 I have a sheevaplug Feb 05 05:55:20 but it has debian wheezy on it Feb 05 05:55:29 Oh, well, the sheeva's not exactly speedy either. Feb 05 05:56:19 infinity: do you have any suggestion for size of the sd card for building things natively on the pandaboard Feb 05 05:56:24 pandaboard at least supports VFP Feb 05 05:56:30 Wait, you can't even run Ubuntu on a sheeva, can you? Feb 05 05:56:42 Isn't in ARMv5? Feb 05 05:56:42 infinity, so which should I try, chroot on sheeva, or qemu? Feb 05 05:56:47 oh, your right Feb 05 05:56:57 s/in/it/ Feb 05 05:56:58 only old version Feb 05 05:57:05 it actually ships with some version of ubuntu Feb 05 05:57:17 (don't remember cause i replaced it very quickly with debian) Feb 05 05:57:23 krosswindz: I recommend a tiny SD card, a netboot image, and installing to a nice external USB drive. Feb 05 05:57:40 krosswindz: Honestly, while running from SD makes for cute demos, it's slow, and it kills SD cards. Feb 05 05:57:55 infinity: true Feb 05 05:57:57 infinity, ahhh, its bad to run embedded from SD? Feb 05 05:58:03 scientes_: Yeah, we used to support v5 for a while, then v6 for a while, but we've been v7-only for ages. Feb 05 05:58:21 with or without VFP? Feb 05 05:58:37 v7 implies vfp. Feb 05 05:58:43 so basically armhg Feb 05 05:58:45 *armhf Feb 05 05:58:46 infinity: if I install on to the usb drive I should be able to use the normal USB port right and not the OTG Feb 05 05:59:18 Out armel port uses softfp calling conventions (but still uses the vfp unit), and armhf uses hardfp calling conventions. Feb 05 05:59:32 krosswindz: Yeah, either of the two normal USB ports. Feb 05 05:59:33 why? if armv7 implies VFP? Feb 05 05:59:54 you would get 40% better performance on some hardware (armhf info page) Feb 05 06:00:04 scientes_: Hence the armhf port. Feb 05 06:00:05 nice I think thats what I will do then Feb 05 06:00:18 I should have an old 80G sata drive lying around some where Feb 05 06:00:30 seems like you should drop the soft float conventions all together Feb 05 06:00:47 scientes_: armel uses the softfp ABI because that's just the way things were done for compatibility (and sanity) reasons. Porting everything to the hardfp ABI was some effort. Feb 05 06:01:01 scientes_: The armel port will likely become unsupported this cycle. Feb 05 06:01:05 gotcha Feb 05 06:01:18 scientes_: We're trying to move the world to armhf. I've put a lot of work into this. :P Feb 05 06:02:14 krosswindz: http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armhf/current/images/omap4/netboot/ Feb 05 06:02:48 krosswindz: If you just write out one of those images (boot.img-serial or boot.img-fb) to an SD and boot, you should be able to install to an external drive and save a lot of pain. Feb 05 06:02:48 infinity: thanks for the link Feb 05 06:02:50 eek, it seems like testing this software will be a PITA Feb 05 06:03:02 infinity: thanks Feb 05 06:03:19 once I am done installing I dont need the sd card to boot or would I need it still Feb 05 06:03:22 maybe i can use the packages i built in debian Feb 05 06:03:30 krosswindz: It'll still need an SD card around to flash a bootloader to, so you don't get to go completely SD free (the Panda has no firmware), but reading a bootloader on boot is a heck of a lot better than running your whole OS from the card) Feb 05 06:03:47 agreed Feb 05 06:03:54 I can build natively on the pandaboard Feb 05 06:04:09 whats the package for qemu-arm? Feb 05 06:04:18 krosswindz, thx, its opencpn.org Feb 05 06:04:19 scientes_: qemu Feb 05 06:04:35 infinity, that just installs qemu-kvm now Feb 05 06:04:35 apt-file search qemu-arm Feb 05 06:04:49 scientes_: Or, if you want to do binfmt-misc emulation (which is much less annoying), qemu-user-static Feb 05 06:05:06 scientes_: Yeah, qemu-kvm should include qemu-system-arm, does it not? Feb 05 06:05:22 don't know i was trying to use virt-manager Feb 05 06:05:46 Oh, those may have been split off into qemu-system Feb 05 06:06:05 Anyhow, qemu system emulation is almost never what you want, unless you're debugging bootloaders. Feb 05 06:06:16 qemu binfmt emulation is much less annoying. Feb 05 06:08:44 infinity: are there md5sums for the files around some where Feb 05 06:09:09 http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armhf/current/images/MD5SUMS Feb 05 06:09:20 thans Feb 05 06:09:23 thanks* Feb 05 06:09:25 poof!, my computer randomly rebooted Feb 05 06:09:25 scientes_: Welcome back. Feb 05 06:09:27 wierd Feb 05 06:09:38 scientes_: So, as I was saying. ;) Feb 05 06:09:43 anyways, no infinity qemu-kvm only has qemu-system-i386 and -x86-64 Feb 05 06:09:58 apt-file search qemu-arm Feb 05 06:10:00 scientes_: Yeah, the others were broken out into qemu-system Feb 05 06:10:06 exactly Feb 05 06:10:12 installing now.... Feb 05 06:10:19 scientes_: However, you almost certainly don't want an actual qemu-system, unless you're debugging bootloaders. Feb 05 06:10:29 oh ok Feb 05 06:10:41 oh yes, there is multiarch !!!!! :):):) Feb 05 06:10:42 scientes_: If you install qemu-user-static, then you can work with ARM binaries as if they were native. Feb 05 06:11:30 I don't see -static, just qemu-user Feb 05 06:11:35 but that is OK Feb 05 06:11:55 search for qemu-arm-static Feb 05 06:12:07 krosswindz, should i just use what i built on my sheevaplug in debian wheezy, or do you want to build opencpn ( opencpn.org ) ? Feb 05 06:12:42 scientes_: I am sorry I guess you there was some miscommunication Feb 05 06:12:42 scientes_: qemu-user-static definitely exists (and is the required one in this case), I just installed it. Feb 05 06:13:10 ahh it does, what is the difference? Feb 05 06:13:39 oh, i read the desc, nvm Feb 05 06:14:06 wait, no I don't know why Feb 05 06:14:53 dpkg --add-architecture armel ? now Feb 05 06:14:55 scientes_: http://paste.ubuntu.com/829726/ <-- witness the magic. Feb 05 06:15:25 scientes_: You could do multiarch too, but that gets messy. Do you really do your builds in your base system, not in chroots? Feb 05 06:16:08 oh gotcha, that looks much cleaner Feb 05 06:18:26 krosswindz, oh, gotcha Feb 05 06:18:47 OK, all this talk about SD cards----so if I launch an embedded device, it is smart to not use a SD root? Feb 05 06:19:42 scientes_: If you're building an actual embedded device, hopefully that assumes you're taking great pains to make sure you're not doing things like logging to filesystems, etc. Feb 05 06:20:04 scientes_: If you never write to the card except to update software, SD's a fine choice. Feb 05 06:20:29 ok, so all the problems with SD are going to be the same with NAND flash? Feb 05 06:20:32 scientes_: If you run a general purpose OS on it, and call it "embedded" without making sure you neuter that sort of behaviour, you're going to kill a lot of flash. Feb 05 06:20:45 not the FTL? Feb 05 06:20:58 *do any come from the FTL? Feb 05 06:21:08 scientes_: Hrm? Feb 05 06:21:13 I'm not sure I understand what you're asking. Feb 05 06:21:21 flash translation layer---why SD is a block device, not a mtd Feb 05 06:21:39 Yes... But I'm not sure what you're asking about FTLs. Feb 05 06:21:51 well is that the source of SD problems? Feb 05 06:22:03 or are their problems shared with raw NAND flash? Feb 05 06:22:04 No, the source of problems is rewriting flash, full stop. Feb 05 06:22:12 ok, that is what i was asking Feb 05 06:22:31 And raw flash is usually worse than something with a decent FTL implementation, cause at least decent FTLs (like those found on SSD disks) do proper wear-leveling. Feb 05 06:22:43 But, at the end of the day, excessive writes kill flash, even SSD disks. Feb 05 06:22:57 infinity, ubifs does wear-leveling just great Feb 05 06:23:08 SD cards tend to die much faster than SSDs, though. :P Feb 05 06:23:18 (I've killed a lot of SD cards working on ARM porting...) Feb 05 06:23:26 ahh, very heavy usage Feb 05 06:23:32 would you recommend logging to tmpfs? Feb 05 06:23:55 Logging to a tmpfs is reasonable, sure. Means you don't get permanence, but it's enough for spot disagnostics. Feb 05 06:23:59 is it just the number of writes, or maybe to fast, etc? Feb 05 06:24:06 Most embedded projects really don't need logs, though. Feb 05 06:24:09 Or, really shouldn't? Feb 05 06:24:13 i think, a minimal logging into ram is fine. for the rest a log-server should be used Feb 05 06:24:21 Cause once you sell it to a customer, do you really expect them to be mailing you lofs? ;) Feb 05 06:24:24 logs* Feb 05 06:24:40 yes i do Feb 05 06:25:09 scientes_: Speed doesn't really matter, it's just the number of writes, period. And yeah, logs are the worst culprit right after atime (but sane people always disable atime on flash) Feb 05 06:26:23 mythos: If every set top box, phone, and smart TV in my parents' house expected them to be "informed and educated" users who filed bug reports with logs, I suspect they'd just stop buying these computers disguised as appliances. Feb 05 06:26:33 infinity, what about relatime? Feb 05 06:26:53 (mainly for completeness) Feb 05 06:26:55 infinity, i have to care about thinclients, so... ;-) Feb 05 06:27:52 scientes_: I've never seen the point in relatime. Feb 05 06:28:11 scientes_: But it would fall in betweenish, I suppose. Much less likely to update, but it's still unnecessary writes for a flash device. Feb 05 06:28:55 yeah, go with atime Feb 05 06:28:59 i mean noatime Feb 05 06:29:25 seems like btrfs might be smarter for a flash device---ugh Feb 05 06:29:32 i still hate that ugly FTL Feb 05 06:29:40 and would rather just put ubifs on it Feb 05 06:29:43 mythos: Well, I tend to view thinclients more like "really crappy computers" than appliances, in the enviroments where most people use them. That said, it would be much nicer if they were appliances. Feb 05 06:30:11 i don't like them either Feb 05 06:30:40 but what shall i say... somehow i have to earn money Feb 05 06:30:50 And back in the days when you could buy X terminals off the shelf from IBM and Wyse, and thin clients were much less fat than they are today, they were very appliancy. Feb 05 06:32:09 ;___; i'm sorry Feb 05 06:33:25 Oddly enough, I think we've almost come full circle. The full-features "appliance" IBM thin clients I used to work with that did seamless desktop convergence between X11 and WinNT/Metaframe were, if I recall, running StrongARM CPUs. Feb 05 06:33:32 Really, really slow ones. :P Feb 05 06:33:32 infinity, do you use udev in your chroots, or bind mount /dev ? Feb 05 06:33:59 scientes_: Neither, I just mount devpts. But if you actually need all the nodes, bindmounting /dev is the sane option, yes. Feb 05 06:36:06 Oh, no. Wikipedia has educated me. Those were PPC (first gen) and Pentium (second gen). Feb 05 06:36:10 how do i see what breaks a package without installing aptitude? Feb 05 06:36:35 nvm, it just printed it out Feb 05 06:39:50 infinity, as far as i know is arm rather new for thinclients.... i know a hp armv3-device, but that's it Feb 05 06:40:21 mythos, even if it is new, it seems like it would be the way to go in the long run, considering the power consumption Feb 05 06:40:36 mythos: Yeah, I'm trying to think of why I got confused about that one. Well, other than the part where it was 15 years ago and I'm old. :P Feb 05 06:40:52 *g Feb 05 06:41:02 scientes_, yes, you are right Feb 05 06:41:42 it is the new hot stuff for citrix and vmware... (lot of work for me... that's why i'm here) Feb 05 06:43:28 infinity, oh your right, multiarch wouldn't work because it doesn't include binaries Feb 05 06:44:02 *executables Feb 05 06:44:19 http://www.ebay.com/itm/IBM-07L8402-Network-Station-1000-/320556566601?pt=LH_DefaultDomain_0&hash=item4aa2a90849 Feb 05 06:44:23 ^-- Memories. Feb 05 06:44:40 And 95 bucks for nostalgia is tempting. Feb 05 06:45:01 is there a multiarch way to have the binaries put in a special place, and then you just set your $PATH approiately Feb 05 06:45:10 and have binfmtmisc with qemu do the rest?\ Feb 05 06:45:12 scientes_: No. Feb 05 06:45:37 scientes_: Multiarch pretty much assumes that you don't want the same binary twice. (which is a fair assumption, generally) Feb 05 06:45:50 infinity, i have to support the emulator for this device ;-) Feb 05 06:45:57 that way you could still use all your installed utilies in the not-chroot, like git, etc Feb 05 06:45:59 scientes_: Of course, for development, this isn't a big deal, as you usually only need the foreign-arch libraries, not binaries. Feb 05 06:46:09 scientes_: Still, chroots are much cleaner. Feb 05 06:46:15 instead of having to have two terminals open for the chroot :) Feb 05 06:46:21 infinity: is there a US mirror for ports Feb 05 06:46:24 yes, two terminals at once isn't that big of a deal Feb 05 06:46:40 infinity: netboot gives the otion of only UK Feb 05 06:46:42 krosswindz: There may be one or two, but I don't know of any. Feb 05 06:46:43 option* Feb 05 06:46:51 infinity: thanks Feb 05 06:46:52 krosswindz: The only official ports mirror is ports.ubuntu.com Feb 05 06:47:35 infinity: ok Feb 05 06:47:40 scientes_: Yeah, I guess I don't notice how or why it bugs people, because I've always done all my development in chroots, long before I could also do fancy emulated chroots. :) Feb 05 06:48:02 scientes_: My laptop has pretty much nothing installed in the base system, and each bit of software I work on gets a new clean chroot. Feb 05 06:48:13 (waste of space, maybe, but it helps maintain sanity) Feb 05 06:48:51 http://paste.ubuntu.com/829746/ Feb 05 06:49:26 scientes_: sed -i -e 's/main/main universe restricted multiverse/' /etc/apt/sources.list && apt-get update Feb 05 06:49:29 hmm, why don't you use vserver with vhashify then? Feb 05 06:49:43 so that all the duplicate files get hardlinked together in a sane way Feb 05 06:49:54 which reduces both disk AND ram consumption Feb 05 06:50:17 along with security which doesn't exist with chroots Feb 05 06:50:28 Security's a non-issue. Feb 05 06:50:32 For my use-case. Feb 05 06:50:41 but what about vhashify? Feb 05 06:50:45 This is just about not having junk in my base system, and not polluting package builds. Feb 05 06:51:04 The de-duping might be neat, but *shrug*... Don't care? ;) Feb 05 06:51:21 I build and delete chroots several times a day, it's not like they live long. Feb 05 06:51:35 are you at least running the ram consolidation thingy designed primarily for KVM? Feb 05 06:51:43 My workflow comes from more than a decade of buildd maintenance, it's not "sane" to most people, but it works for me. Feb 05 06:51:46 it just scans ram and loops for things that are the same Feb 05 06:52:07 sooo... chroot is a "good enough"-solution :o Feb 05 06:52:15 RAM consolodation doesn't matter, I'm not running long-running processes in these chroots. Feb 05 06:52:27 Build, compile, wipe. Feb 05 06:52:35 http://paste.ubuntu.com/829746/ <----help Feb 05 06:52:58 scientes_: sed -i -e 's/main/main universe multiverse/' /etc/apt/sources.list && apt-get update Feb 05 06:53:02 ^-- I did. Feb 05 06:53:25 infinity, ahh, yes universe needs to be on, thx Feb 05 06:53:54 no multiverse thxuverymuch however Feb 05 06:53:59 ;) Feb 05 06:54:17 You shouldn't need restricted either, but you have it on. Feb 05 06:54:32 (If you're trying to avoid non-free software sneaking up and biting you in your sleep) Feb 05 06:54:51 that was just the default for the ubuntu core tar.gz Feb 05 06:55:15 Yeah. I should revisit that. Feb 05 06:55:44 I picked "main restricted" pretty arbitrarily when I first put core together, just based on the fact that it used to be our default in, like, dapper? Feb 05 06:56:06 what is the default now? Feb 05 06:56:09 I sometimes live in the past. Feb 05 06:56:37 The default now is, I believe, all 4 components enabled after install. But I'm not positive of that either, I'd have to install a fresh Ubuntu. :P Feb 05 06:56:50 definitely not Feb 05 06:57:02 it just feels like that the way software-center works by default Feb 05 06:57:18 Yeah, maybe. Feb 05 06:57:32 Perhaps the default is still "main restricted", or possibly just "main". Feb 05 06:57:38 I'm too lazy to dig through code right now. Feb 05 06:57:57 Plus, "default" depends on how you install. Keeping those things in sync is annoying. Feb 05 06:58:30 infinity, I think you should just enable main Feb 05 06:58:36 oh wait, its not just armel Feb 05 06:58:46 It's all arches. Feb 05 06:58:57 i was thinking that the hardware that gets restricted put on default is not present with arm Feb 05 06:59:04 But, that said, people shouldn't need fancy binary opengl drivers in a minimal chroot. Feb 05 06:59:10 And if they do, they can edit sources.list. :P Feb 05 06:59:12 ^^ precisely Feb 05 06:59:22 so just put it main, and be done with it Feb 05 06:59:34 Well, I was tossing around the idea of going the other way too. Feb 05 06:59:54 Since people constantly say "I tried to install $foo and it's not found, is ubuntu-core crap somehow?" Feb 05 07:00:04 Or "is this built on ARM?!" Feb 05 07:00:12 i havn't looked for a while but it seemed like ubuntu was shipping some pretty schetchy stuff in multiverse Feb 05 07:00:15 When the answer is, invariably, "enable universe". Feb 05 07:00:38 compared to debian's non-free being pretty reasonable when i looked at it Feb 05 07:00:41 scientes_: Well, multiverse is just the non-free component of universe. So, sure. I guess that's sketchy on top of sketchy. :) Feb 05 07:00:55 But it's not like enabling it forces people to install things from it. Feb 05 07:00:59 infinity, but it was bigger than debian's non-free Feb 05 07:01:01 infinity: I am installing precise on an usb hard drive, I dont need a separate boot partition on it since that will come from the SD card right? Feb 05 07:01:15 And we don't allow dependencies from main to universe or from universe to multiverse, so... Feb 05 07:01:30 krosswindz: Right. Feb 05 07:01:31 debian was like: nasa worldwind (open source, but bad license), xtides-data-nonfree (asshole govmnts), and hardware support Feb 05 07:01:58 scientes_: Debian has, historically, been kinder to their mirrors with regard to non-free. Feb 05 07:02:16 scientes_: If something was widely non-redistributable in, say, several EU countries, or the US, or whatever, they wouldn't carry it. Feb 05 07:02:42 scientes_: multiverse, we just say "look, it's hosted in the UK, mirrors don't have to mirror it, if they do, we assume they've read the licenses, HTH, HAND". Feb 05 07:02:56 it drives me nuts how governments, that need good map data in order to do taxes, etc, double charge their citizens Feb 05 07:03:06 the US is like the only sane country in this regard Feb 05 07:03:34 scientes_: Yeah, well. The US and software sanity is a sore topic for Debian too. It took us FOREVER to get rid of the stupid "non-US" split for crypto. :( Feb 05 07:04:03 the NSA managed to hold back encryption for 10 years with that stupid shit Feb 05 07:04:13 And even then it involved something like 850 pages being sent to the US government. Feb 05 07:04:17 By hand. Feb 05 07:04:17 also: software patents Feb 05 07:04:31 StevenK: Yeah, it was tons of special. Feb 05 07:05:22 StevenK: I haven't kept up, do you know if Debian's finally managed to obtain a blanket waiver, or if ftpmaster is still automating an e-mail to the US govt for every NEW package? Feb 05 07:05:33 I think its the latter. Feb 05 07:05:42 Ridiculous. ;) Feb 05 07:08:53 infinity, what percentage of packages correctly cross-compile? Feb 05 07:09:24 scientes_: Like xdeb, cross-build the package style? Probably a much lower number than you'd like. Feb 05 07:09:40 scientes_: Building natively (or "natively" under emulation) is still the way to go. Feb 05 07:09:43 yeah, i just assumed that I should default to natively Feb 05 07:10:11 We've been working on improving the numbers for cross support for specific dependency chains. Feb 05 07:10:12 sure the kernel can do it, but not much else Feb 05 07:10:41 are there any list of what chains work? Feb 05 07:10:45 But, personally, I think it's wasted effort. ARM hardware is getting faster every day and, while I appreciate that people are spoiled and all, if I can build the entire armhf archive in ~15 days, it's not "slow". Feb 05 07:11:10 it supposedly fixes alot of bugs to get cross-compile working Feb 05 07:11:18 scientes_: Not sure how far that's gone. It was mostly being done by Linaro folks, IIRC. I'll be at Linaro Connect in, like, 2 days though, and I think we have a catch-up session on it. :P Feb 05 07:11:39 scientes_: Err, what? How would cross-compiling fix bugs? Feb 05 07:11:47 scientes_: That sounds a whole like like misinformation. Feb 05 07:11:54 probably is, only read it once Feb 05 07:11:54 s/a whole/a whole lot/ Feb 05 07:12:12 some random comment on lwn or something Feb 05 07:12:17 At best, cross-compiling will provide you with binary-identical output, at worst, the cross version will be horribly broken compared to the native. Feb 05 07:12:26 I can think of any scenario where it would be better. :) Feb 05 07:12:35 I built the linux kernel with distcc on x86_64 and arm at the same time, and it booted! Feb 05 07:12:38 s/can/can't/ Feb 05 07:13:08 In general, cross should get you binary-identical output these days. GCC and binutils are much saner than they used to be. Feb 05 07:13:11 But. Feb 05 07:13:14 There's always a but. Feb 05 07:13:21 And the buts never favour the cross environment. Feb 05 07:13:24 infinity: what about cross chroot using qemu Feb 05 07:13:37 krosswindz: That's essentially "native", for the purpose of this discussion. Feb 05 07:13:43 yes Feb 05 07:13:44 ok Feb 05 07:14:01 cross-compiling is much faster Feb 05 07:14:03 emulation is not Feb 05 07:14:44 but I was definitely impressed with i could use distcc with arm and x86_64 cross at the same time, and boot what came out Feb 05 07:15:56 infinity, oh geeze, you should have put no-install-recommend in the core..... Feb 05 07:16:15 oh wait, i guess it did that Feb 05 07:16:29 just alot of stuff Feb 05 07:19:28 scientes_: You can specify it on the command line. Feb 05 07:20:12 i know that, i thought it was installing a bunch of worthless stuff, but i scrolled up, and it listed the recommends sep, which IIRC means it didn't install them Feb 05 07:20:21 I type "apt-get --no-install-recommends --purge install $foo" so often that it's muscle memory. :P Feb 05 07:20:52 scientes_: No, it lists them even if they're also in the install list. If you didn't specify it, you got recommends. It's our default. Feb 05 07:21:11 ahh ok, tons of worthless stuff Feb 05 07:21:21 as i suspenected Feb 05 07:21:30 it was alrady installing when i was like O shi... i forgot Feb 05 07:21:43 Heh. Oh well, not world-ending. :P Feb 05 07:22:08 The only place where we actually have no-install-recommends in the apt config is our buildd chroots. Feb 05 07:22:11 For obvious reasons. Feb 05 07:22:38 i have added it to apt.conf.d so many times..... Feb 05 07:22:50 I also forgot to use my apt-cacher-ng..... Feb 05 07:22:56 infinity: I was trying to install using net boot to USB drive Feb 05 07:23:00 kernel fails to install Feb 05 07:23:17 any way to check the log over serial console? Feb 05 07:23:25 krosswindz: Weird. It definitely shouldn't. Feb 05 07:23:35 krosswindz: It logs to syslog. Feb 05 07:23:53 krosswindz: But I'm about to head out. You might try poking GrueMaster tomorrow about it, he netinstalls all day, every day. Feb 05 07:24:02 lol k Feb 05 07:24:22 if I want to check syslog Feb 05 07:24:30 is there any way over serial console Feb 05 07:24:47 I would have to quit installer right? Feb 05 07:25:04 If you're still in d-i, you can hit any "go back" button, and then scroll down to "start a terminal" Feb 05 07:25:15 Or "spawn a shell" or something like that. I forget the exact wording. Feb 05 07:25:35 or just switch to another virtual console with ctrl-shift...(if not on serial console) Feb 05 07:25:59