| kees | hallyn: haven't filed one. if it's changing, it's probably not worth it. | 00:03 |
|---|---|---|
| hallyn | not changing in precise though | 00:04 |
| hallyn | so there it may be worth fixing | 00:04 |
| infinity | xnox: Well, comfortingly, it fails in my fresh sbuild chroot here too, so it's not something specifically broken with my buildd chroots. | 00:16 |
| xnox | infinity: we knew that. my bug comment is from my pbuilder | 00:16 |
| infinity | xnox: pbuilder? Ew. | 00:17 |
| xnox | infinity: personal scripts & hooks & break out shell | 00:17 |
| * xnox nom nom | 00:17 | |
| stgraber | xnox: will check later (at the pub) | 00:17 |
| xnox | it is slow, I will migrate to mk-sbuild | 00:17 |
| xnox | stgraber: ok. new bug number bug 1016778 | 00:18 |
| ubottu | Launchpad bug 1016778 in qpid-cpp (Ubuntu) "qpid-cpp version FTBFS ipv6 test case fails" [Undecided,Confirmed] https://launchpad.net/bugs/1016778 | 00:18 |
| infinity | stgraber: You mean, you'll check at the pub, or you're at the pub now and he should piss off? :) | 00:18 |
| stgraber | infinity: the later | 00:19 |
| hallyn | stgraber: bottoms up! | 00:38 |
| infinity | xnox: Further data point for your bug, an sbuild run on a debian chroot (on my Ubuntu system) works fine. So, it's definitely not the base system's network (or lack thereof) in any way. | 00:48 |
| xnox | infinity: ok | 00:49 |
| infinity | xnox: Which might make this a glibc bug... Cause I'm not sure what else would be involved in address resolution once we know the network itself is fine. | 00:49 |
| xnox | infinity: can you decruft rheolef on armel and armhf. It no longer builds for those arches and I want to get rid of boost1.48 | 00:50 |
| xnox | or shall we keep them around until all other boost packages are transitioned to boost1.49 | 00:51 |
| xnox | boost1.46 that is, well all old boosts | 00:51 |
| infinity | Leaf package, no rdeps. Sure. | 00:52 |
| xnox | infinity: thanks. | 00:52 |
| infinity | xnox: Done. | 00:56 |
| infinity | xnox: Of course, the right answer would be to fix the friggin' package to compile on ARM again, but I can't be bothered to argue with some random leaf node in universe that we're autosyncing. | 00:58 |
| xnox | infinity: true. can't wait for my arm hardware =) | 00:59 |
| xnox | i have yet to do any arm development | 00:59 |
| infinity | Chroot, qemu-user-static, go. | 00:59 |
| infinity | Hardware isn't required for most bugs. | 00:59 |
| xnox | ? | 01:03 |
| * xnox goes to search for armhf chrrot | 01:03 | |
| * xnox goes to search for armhf chroot | 01:03 | |
| infinity | xnox: ubuntu-core works. | 01:03 |
| infinity | xnox: Unpack core, apt-get install qemu-user-static, cp /usr/bin/qemu-arm-static chroot/usr/bin/qemu-arm-static && chroot chroot su - | 01:05 |
| infinity | xnox: And then note that you're in an ARM chroot, running ARM binaries. | 01:05 |
| infinity | xnox: And rejoice. | 01:05 |
| xnox | nice | 01:05 |
| hallyn | that is cool :) | 01:06 |
| hallyn | (presumably smaller than a arm lxc container too) | 01:07 |
| infinity | It's pretty slick when paired with sbuild and such too. | 01:07 |
| hallyn | (as that's a debootstraped image) | 01:07 |
| infinity | Although, if you have real hardware, a PandaES still outperforms any shiny new i7 with emulation. | 01:07 |
| infinity | The Intel box will come close, though. | 01:07 |
| infinity | hallyn: Core is "debootstrap --variant=minbase", not sure what lxc's default is. | 01:08 |
| infinity | hallyn: Probably bigger, since it likes to have a functional init system and things. | 01:08 |
| infinity | Though, maybe similar. | 01:08 |
| hallyn | i think we dropped minbase | 01:09 |
| infinity | "we" being the lxc setup? | 01:10 |
| hallyn | yeah i've tried a huge ec2 image emulating arm. was ... tolerable :) | 01:10 |
| hallyn | yup | 01:10 |
| infinity | Yeah, I should probably fiddle with lxc more sometime, but I so rarely need that level of isolation. | 01:11 |
| infinity | And chroots just feel cleaner when you don't actually need the process isolation. | 01:11 |
| xnox | infinity: wow! | 01:12 |
| xnox | i'm loving it! | 01:12 |
| infinity | xnox: Note that mk-sbuild will do that automagically for you (if you mk-sbuild --arch=armhf [...]) if the host can't run the target requested, it uses qemu-debootstrap, and gives you the shiny. | 01:13 |
| infinity | I assume lxc does the same. | 01:13 |
| * xnox likes mk-sbuild | 01:15 | |
| xnox | but that will not work for kfreebsd will it? | 01:15 |
| xnox | but still freaking awesome | 01:16 |
| infinity | xnox: Won't work for non-linux, no. For that, you need a full qemu, so you can boot another kernel. | 01:19 |
| infinity | xnox: qemu-user-static is just some really clever syscall trapping and emulation. | 01:19 |
| xnox | infinity: how does one become an archive admin? | 01:35 |
| infinity | xnox: We invite you to be trained and help out, based on how awesome we think you are. | 01:36 |
| infinity | Ish. | 01:36 |
| xnox | well, I am very green to do that yet. | 01:36 |
| xnox | I have never done a security update yet for a stable release. | 01:37 |
| xnox | infinity: can I steal sinfo merge? | 01:39 |
| xnox | tbh what is the expiry date on TIL | 01:39 |
| xnox | and is TIL: last upload or last merge | 01:40 |
| infinity | xnox: TIL is last upload, from the POV of automated tools, but I prefer to informally say it's last merge if it's something we carry a significant delta for. | 01:43 |
| infinity | xnox: YMMV. | 01:43 |
| infinity | xnox: On the other hand, the previous upload was also just a minor bugfix. | 01:43 |
| xnox | infinity: if bzr merge gives no conflicts and it's in universe and we only carry patches for --as-needed..... i'm just gonna do it. | 01:44 |
| xnox | nmu to debian =) kidding. needs forwarding. | 01:44 |
| infinity | I wish doko had fixed the non-RC as-needed bug in his RC gcc-4.7 NMU. :P | 01:45 |
| infinity | Given the upload history, I'd be tempted to NMU for the as-needed bug too, and just sync it. | 01:45 |
| infinity | But that might make someone grumpy. | 01:45 |
| xnox | btw for as-needed usertag is the user debian-gcc@ or some random guy's email address | 01:48 |
| xnox | and why is it not a release goal for debian! | 01:48 |
| xnox | wheezy+1?! | 01:48 |
| infinity | Because Debian's toolchain doesn't default to as-needed. | 01:48 |
| xnox | ok, but the usertag question is still valid | 01:49 |
| infinity | I might just NMU for Debian bug 638598. | 01:49 |
| ubottu | Debian bug 638598 in sinfo "sinfo: FTBFS with ld --as-needed" [Normal,Open] http://bugs.debian.org/638598 | 01:49 |
| infinity | The maintainer is unresponsive. | 01:49 |
| infinity | xnox: Hrm, what's wrong with the usertag? | 01:49 |
| xnox | well there are two | 01:49 |
| infinity | User: debian-gcc@lists.debian.org | 01:49 |
| infinity | Usertags: ld-as-needed | 01:49 |
| infinity | Seems reasonable. | 01:49 |
| infinity | You're not filing a bug that's already filed, are you? :P | 01:50 |
| xnox | http://wiki.debian.org/ToolChain/DSOLinking | 01:50 |
| xnox | says User: peter.fritzsche@gmx.de | 01:51 |
| infinity | as-needed and no-add-needed aren't the same thing | 01:52 |
| infinity | But yeah, weird that different tags are using different addresses. Whatever. | 01:52 |
| infinity | xnox: Meh, on second thought, I won't bother NMUing. Just merge. If this maintainer ever wakes up, we'll know, and if he doesn't, it doesn't matter. :P | 01:54 |
| xnox | mia ping | 01:54 |
| infinity | When as-needed becomes RC in Debian, I'll NMU the next day. | 01:55 |
| infinity | Don't much care for starting a potential flamewar right now if some pedant notices the upload on -changes and whines about NMUs for non-RC bugs. | 01:55 |
| infinity | Especially if it's someone Ubuntu-hostile who goes off about "why are we NMUing for things that only affect Ubuntu's toolchain?!" | 01:56 |
| xnox | well let's not go into the gcc4.7 'acceptance' by some | 01:57 |
| === sikon is now known as lucidfox | ||
| === chu_ is now known as chu | ||
| Kano | hi, did anybody really test secure boot yet? maybe using the intel testing platform | 10:29 |
| === vibhav is now known as Guest61908 | ||
| infinity | tumbleweed: Man, pypy sure hates armhf. Still building. Is it doing crazy on the fly optimisations or something, and having a field day with the realisation that armhf has 16 more registers to play with than armel? | 10:52 |
| tumbleweed | infinity: it doesn't jit for ARM yet | 10:58 |
| tumbleweed | the build is presumably not fitting in RAM at all | 10:59 |
| tumbleweed | do all the panda buildds have the same amount of RAM? | 10:59 |
| infinity | tumbleweed: Well, I'm just curious why the armhf build would be taking so much longer than the armel one. Same hardware. | 10:59 |
| tumbleweed | no idea :/ | 10:59 |
| infinity | tumbleweed: Identical hardware. The only difference is toolchain (armv5t, float=soft, versus armv7-a, float=hard) | 10:59 |
| infinity | Oh well. It's a curiosity more than anything else. If it doesn't timeout and eventually completes, yay. | 11:00 |
| tumbleweed | this stage of the build translation is just converting the python to C which should be identical between armel and armhf | 11:00 |
| tumbleweed | quite | 11:00 |
| tumbleweed | (should be, but we know it's not a predictable build so, probably isn't) | 11:00 |
| infinity | I was a 68k porter, waiting a week for a GCC build was the norm, this doesn't bug me. | 11:00 |
| penguin42 | infinity: Are you sure the same set of front ends are enabled on both of them? | 11:05 |
| infinity | penguin42: For pypy? I have no clue about it at all. :P | 11:07 |
| penguin42 | infinity: Oh sorry, I came in half way - I assumed it was the build of the toolchain you were comparing | 11:07 |
| infinity | No. | 11:08 |
| penguin42 | infinity: in that case, hmm - same optimisation levels? Same gcc versions? | 11:08 |
| infinity | It's the pypy build that's still trudging along on armhf a day after the armel one finished. ;) | 11:08 |
| infinity | And yeah, they started at the same time (ish) with the same GCC and glibc and such. And pypy itself appears to have no arch special casing for armel/armhf. | 11:09 |
| infinity | So, I guess it just comes down to GCC on armhf being slower (which it is, because it thinks a bit harder), and ridiculong builds really exposing that. | 11:09 |
| penguin42 | yeh it was the 'thinks a bit harder' I was curious about; does the hf build have some of the optimisations on by default? I hadn't thought the hf v el itself should make much difference | 11:10 |
| infinity | hf is v7, vfpv3-d16, hard-float, el is v5, soft. | 11:12 |
| infinity | So, there's a fair difference there. | 11:12 |
| infinity | From all the v7 optimisation, to suddenly, like, having a VFP, to oh hey, having 16 new registers to play with, etc. | 11:12 |
| tumbleweed | thing is, it probably hasn't spent that time with gcc yet | 11:13 |
| tumbleweed | that much time | 11:13 |
| infinity | Oh, and thumb2 by default on hf. | 11:13 |
| penguin42 | infinity: Yeh, although I wouldn't have thought the vfp stuff would make that much compile time difference for most code unless it's all heavy fp; hmm thumb2 might a bit | 11:13 |
| infinity | tumbleweed: Could be that python's grumpy on hf, but I've not noticed that in other contexts. | 11:14 |
| infinity | Anyhow. I need sleep. I'm sure the build will finish some day, and we can do a post-mortem. | 11:14 |
| infinity | If only it had timestamps, so we could see where it spent most of its time and use it as the ultimate toolchain benchmark. | 11:14 |
| penguin42 | infinity: You have timestamps on th e.o's | 11:16 |
| penguin42 | the .o's | 11:16 |
| === tomreyn_ is now known as tomreyn | ||
| cjwatson | penguin42: Only if those are preserved - we don't keep build trees | 11:32 |
| cjwatson | They wouldn't be in final executables/.sos would they? | 11:33 |
| penguin42 | true; also I wasn't sure from the bit of the conversation that I saw whether the builds were on the same host; ARM boards vary quite a bit in pretty much every measure of performance | 11:33 |
| cjwatson | Same type of board AIUI but not the same physical host | 11:34 |
| Kano | cjwatson: what do you think about grub 2.00 / bzr | 11:51 |
| Kano | cjwatson: it would help for better uefi support, mdadm/dmraid support | 11:52 |
| Kano | cjwatson: mdadm even for isw (intel raid) | 11:53 |
| Kano | also it is hard to get support for 1.99, the first comment is try latest beta or bzr | 11:56 |
| === Guest61908 is now known as vibhav | ||
| === vibhav is now known as Guest37517 | ||
| === Guest37517 is now known as vibhav | ||
| melodie_ | hi | 14:14 |
| melodie_ | I was wondering if someone could help me learn how to package configuration files for a program, one of these coming days ? | 14:15 |
| === m_3_ is now known as m_3-backstage | ||
| penguin42 | melodie_: There is a #ubuntu-packaging that might be more help for that | 14:26 |
| melodie_ | hi penguin42 : thank you very much ! | 14:28 |
| === bjsnider_ is now known as bjsnider | ||
| hippiehacker | https://gist.github.com/2978542 # live-build precise iso creation issue on precise... aany thoughts/direction? | 15:01 |
| vibhav | bryceh: ping | 16:12 |
| ClientAlive | Hi | 16:30 |
| ClientAlive | I'm wondering about internships with Ubuntu. Can anyone help me with this? | 16:31 |
| penguin42 | ClientAlive: Canonical is the company behind Ubuntu, see www.canonical.com | 16:35 |
| ClientAlive | right on | 16:37 |
| ClientAlive | I know sometimes the listings/ information is pretty... err, eloquently worded. This is all new to me and sometimes I find it a bit challenging to translate the information to whether I'm really qualified to apply (or if I'd just be wasting people's time). Anyone here actually done an internship or is working with Ubuntu? | 16:39 |
| tumbleweed | infinity: pypy failed :/ | 16:48 |
| alazare619 | is ubuntu built with live-build? | 18:24 |
| alazare619 | or some other means? | 18:25 |
| === vibhav is now known as Guest69218 | ||
| alazare619 | what method of image creation does ubuntu and the respins use for making of there iso's | 19:38 |
| alazare619 | do you guys use live-build or some other for the respins and stuff | 19:38 |
| === fedora is now known as ia | ||
| alazare619 | anyone in here!!! | 21:43 |
| directhex | alazare619, the relevant people aren't around on a saturday night | 21:44 |
| alazare619 | dang :( | 21:45 |
| infinity | tumbleweed: Aww. | 22:47 |
| Debolaz | alazare619: The disadvantage of having a community composed of people with social intelligence; They tend to be social. :-) | 22:55 |
| infinity | Debolaz: You take that back right now. | 23:07 |
| Debolaz | :O | 23:11 |
| infinity | ;) | 23:11 |
| * Debolaz ponders starting to blog about stuff he finds annoying with ubuntu development. Which granted, isn't a very long list. But its still bloggable. :) | 23:13 | |
| * stgraber reads scrollback and pretends not to be around | 23:14 | |
| infinity | stan: *grin* | 23:23 |
| xnox | infinity: stop talking to my housemate stan, instead of stgraber ! | 23:25 |
| xnox | =) | 23:25 |
| infinity | xnox: Hahaha. Oops. | 23:25 |
| infinity | People shouldn't be allowed to have st<tab> nicks. | 23:26 |
| xnox | infinity: yeah i get confused by that. I have switched xchat to autocomplete nicks based on last talked to instead of alphabetically | 23:26 |
| xnox | so I don't have that problem, as much... | 23:27 |
| penguin42 | oh that's a neat trick | 23:27 |
| infinity | Oh, I should see if irssi has a setting for that. Probably does. | 23:27 |
| * xnox goes back to reading weekend emails.... | 23:28 | |
| infinity | Ahh, I probably just need to crank up the value of completion_keep_publics | 23:29 |
| infinity | Or stop talking to more than 50 people between stgraber chats. | 23:29 |
| xnox | =) | 23:53 |
| * xnox wonders if I should start using irssi .... does it have emacs and remote messaging menu integration? | 23:54 | |
| stgraber | not sure for the emacs part (not an emacs user), for the messaging menu integration, I believe there are some scripts around for that and notify-osd integration | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!