[04:37] <pitti> Good morning
[04:37] <pitti> smoser: thanks, will sort out the autopkgtest bug today
[05:43] <wasaby> hi guys. just dropping by to ask about crypt(3) blowfish support in libc6. before i make a feature request on launchpad i'd just like to know whether there is a particular reason for it not being supported or is it simply because nobody cares :)
[07:07] <dholbach> good morning
[08:57] <mvo_> jibel: good morning, did you had a chance to test the upgrade with https://launchpad.net/~mvo/+archive/ubuntu/lp1347721 yet?
[09:04] <jibel> mvo_, not yet. on my list for today when the machine is a bit less busy and responds to ssh
[09:09] <mvo_> jibel: thanks
[09:17] <pitti> jodh: hey James, how are you?
[09:17] <pitti> jodh: so what can we do about bug 1346337? it's blocking the new systemd version
[10:08] <tsdgeos> is wine installable for you in utopic?
[10:09] <cjwatson> tsdgeos: It would be more helpful to state the error you're seeing
[10:10] <cjwatson> Also what architecture you're using
[10:10] <tsdgeos> cjwatson: http://paste.ubuntu.com/7883421/ amd64
[10:10] <cjwatson> tsdgeos: Have you disabled multiarch?
[10:10] <tsdgeos> i *think* it may be because of this
[10:11] <cjwatson> dpkg --print-foreign-architectures
[10:11] <tsdgeos> cjwatson: http://paste.ubuntu.com/7883423/
[10:11] <tsdgeos> cjwatson: http://paste.ubuntu.com/7883425/
[10:12] <cjwatson> Looks like some of the libraries that are common between KDE and Wine aren't Multi-Arch: same, judging from 7883423
[10:12] <cjwatson> So that will have to be fixed before you can coinstall those two systems
[10:13] <tsdgeos> this used to work :/
[10:13] <tsdgeos> i don't even know what is libroar :D
[10:13] <cjwatson> I can fix dnprogs today at least
[10:14] <tsdgeos> roaraudio sound server
[10:14] <tsdgeos> :D
[10:17] <tsdgeos> seems to be an openal dependency
[10:18] <tsdgeos> cjwatson: who should i bug about this? open a bug? (not sure i understood your "I can fix dnprogs today at least" tbh)
[10:22] <cjwatson> tsdgeos: there are already bugs for this in Debian, by the looks of things, so it should really be sorted out there
[10:22] <tsdgeos> cjwatson: do you have a bugnumber/url?
[10:22] <cjwatson> tsdgeos: dnprogs is the source package that builds libdnet, and I'm going to convert it to multiarch in Debian which unblocks part of this
[10:23] <cjwatson> tsdgeos: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756032 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755846
[10:23] <tsdgeos> cjwatson: thanks :)
[10:24] <cjwatson> tsdgeos: oh and also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755935, which the bug states is in progress
[12:16] <pitti> jodh: cheers!
[12:46] <pitti> infinity, arges, bdmurray: can I ask any of you to review/accept the postgresql microrelease SRUs? (lucid/precise/trusty) people keep pinging..
[12:47] <infinity> pitti: Ask me again in an hour when I'm awake? ;)
[12:48] <pitti> infinity: heh, sleep well until then!
[13:01] <xnox> mvo_: i've sent you, some of your code from 2012 for review =) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756287
[13:03] <mvo_> xnox: heh :) thanks!
[13:05] <xnox> mvo_: i do have questions about cachedbs in apt-ftparchive, since there are some vague comments that dists/bin/src caches are incompatible with contents ones, hence in launchpad at the moment contents and Packages/Sources generation is separated and doesn't share caches.
[13:06] <mvo_> xnox: hm, that sounds like a bug if thats the case, does infinity or someone else knows more here?
[13:06] <xnox> is that actually true? how to validate that? (e.g. are cache structures / format published somewhere)
[13:07] <xnox> mvo_: right, well, it's vague comments from the past, in the launchpad code base.
[13:08] <mvo_> xnox: hm, maybe we can find out via bzr blame who wrote it so that we can find out more :) ?
[13:11] <xnox> Jeroen Vermeulen <jeroen.vermeulen@canonical.com>
[13:17] <mvo_> xnox: hm, he should still be around to ask
[13:17] <xnox> mvo_: well, let me dig the code a bit more.
[13:18] <mvo_> ok
[13:41] <smoser> pitti, i think that maybe /etc/environment might be required.
[13:41] <smoser> honestly, as you invoke that with env -i.
[13:41] <smoser> whatever you invoke will have no PATH if you dont get it from /etc/environment.
[13:42] <smoser> the reality is that most likely /etc/environment *will* exist, but in the case where it doesn't, somethings probably going to fail later.
[13:42] <pitti> smoser: couldn't PATH be set in some bash profile or PAM environment?
[13:42] <pitti> smoser: right, but then it will fail with something like "command not found", not some unintelligible gibberish within adt-run
[13:43] <smoser> well i dont think ti would get set. i dont think that ends up going through the bash login that gets all that set up.
[13:43] <pitti> smoser: anyway, by and large I agree that /etc/environment is a must; but who knows who will test that with strange VMs :)
[13:43] <smoser> maybe it does. and yeah, thats how it would normally get setup, but i suspect you were doing what you were doing for a while.
[13:43] <smoser> and fwiw, i'd still set LANG=C
[13:43] <smoser> so you dont get those silly messages
[13:43] <pitti> smoser: that's already handled; unless you run with --leave-lang, it sets LANG=C.UTF-8
[13:44] <smoser> about lang not set, but you are more knolwedgeable than i about how lang is supposed to work.
[13:44] <smoser> i dont think it is.
[13:44] <smoser> you run :
[13:44] <smoser>  env -i
[13:44] <smoser> which will clear LANG such.
[13:44] <pitti> smoser: yes; Testbed.execute() sets some extra environment
[13:45] <pitti> such as LANG, or (for mode "install") DEBIAN_FRONTEND and friends
[13:45] <smoser> ok. i'll trust you.
[13:45] <pitti> smoser: the LANG handling is test case'd already, just running LXC without /e/e or /e/d/locale wasn't
[13:45] <smoser> one random thing... when i do subprocesses, from shell or python, i always use long options where available.
[13:45] <smoser> http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=15faea
[13:45] <smoser> when i see 'sudo -E' there
[13:45] <smoser> i have to 'man sudo' to see what thta means.
[13:45] <smoser> but sudo --preserv-env
[13:45] <smoser> i dont have to man
[13:46] <smoser> as i said, random comment. feel free to ignore
[13:46] <pitti> ah, sure
[13:46] <smoser> thanks for taking a look.
[13:46] <pitti> no, good point, but that'll take some grepping
[14:15] <xnox> "You have 1 day to reopen this bug or I will make a new one."
[14:15] <xnox> sounds a legit threat! =)
[14:21] <highvoltage> I'm shaking in my space booties
[14:21] <wasaby> so this is how ubuntu devs treat bugs :)
[14:22] <wasaby> with ignorance
[14:23] <wasaby> why fix bugs when you can just dismiss them with no consideration
[14:25] <xnox> wasaby: i'm sorry, but I don't follow. Can you elaborate? Above quote was not from an ubuntu developer, but rather a bug reporter. Instead of providing justification for particular request, reporter said that.
[14:36] <Laney> bdmurray: could you look at my email about the nautilus sru please?
[14:46] <hallyn> good morning - could someone please take a look at the new qemu-user-binfmt binary package in utopic-proposed?  I assume a button needs to be hit to accept it for qemu to be promoted to utopic-release...
[14:49] <smoser> cjwatson, https://lists.ubuntu.com/archives/ubuntu-cloud/2014-July/000969.html
[14:50] <smoser> is that true? that i simply cannot reliably have a 2Tb partition and grub2 booting mbr ?
[14:50] <xnox> bios grub. UEFI will boot fine.
[14:51] <xnox> smoser: i totally hit that when I made a 2TB intel matrix raid-0 device from two 1TB drives and was puzzled as to why it's only bootable in UEFI mode =)
[14:52] <smoser> well, i can't just use uefi though.
[14:52] <xnox> smoser: stand-alone /boot partition also works, I believe.
[14:53] <smoser> right. and in start of the disk.
[14:53] <smoser> we've not done that before.
[14:53] <xnox> smoser: anywhere in the first 1TB =)
[14:53] <cjwatson> smoser: I know of no such limitation in GRUB
[14:53] <smoser> just to avoid the unnecessary complexity.
[14:53] <xnox> cjwatson: hu? hm.
[14:53] <smoser> i agree with xnox. hm.
[14:54] <smoser> ok. so some background on how this is put together:
[14:54] <cjwatson> smoser: You should use GPT, obviously, but even with MBR you should be able to address anything up to 2TB in GRUB, modulo BIOS limits.  I'd want a citation for this alleged limitation
[14:54] <cjwatson> OK, please don't make me understand the whole thing just now, doing other things :)
[14:54] <smoser>  * cloud-image is ~ 1.4G image. cloud provider truncates it to larger size, say 2TB.
[14:55] <cjwatson> I suggest just asking Patrick to provide more information on this limitation that he claims exists
[14:55] <smoser> ok. fair enough.
[14:56] <cjwatson> Because if it exists and isn't just a BIOS bug (those certainly exist ...), we'd consider it a bug
[14:56] <xnox> smoser: well, we know the bootloader and the system, thin-provision 2 TB and install ubuntu onto it with qemu.
[14:56] <xnox> smoser: naturally 2TB+ is beyond MBR limit, and thus would require GPT.
[14:56]  * xnox tries that.
[14:56] <smoser> right. and for 14.04, it will properly resize it to only 2TB.
[14:56] <cjwatson> Right, if it were actually slightly over 2TiB then you'd have a problem
[14:57] <cjwatson> But if it's 2TB in lying-disk-manufacturer-units, then it should be comfortably under the real limit
[14:57] <smoser> hm.. ok. well i'll give a quick try to reproduce.
[14:57] <xnox> =)))))))))) lovely manufacturer units ;-)
[14:58] <cjwatson> hallyn: no button should be needed
[14:58] <cjwatson> hallyn: you're stuck in the libav/gnutls28/etc. transition.  please wait
[15:11] <hallyn> cjwatson: oh - phew.  thanks.
[15:48] <pitti> hey hallyn, how are you?
[15:48] <hallyn> pitti: (on a call, few more mins)
[15:48] <pitti> hallyn: I noticed that the last cgmanager upload in ubuntu diverted from Debian; are these session upstart enablements safe for Debian and will go there, too?
[15:48] <pitti> hallyn: no hurry at all
[15:49] <xnox> they are upstream and will be in the next release.
[16:02] <hallyn> pitti: right, like xnox said, they're upstream.  I will sync from debian to utopic soon, but am waiting on slangasek to sponsor the 0.28-3...  that should be in prettu good shape
[16:02] <hallyn> actually i should probably release 0.29 soon
[16:02] <pitti> ah, nice
[16:02] <pitti> hallyn: I can help out with Debian sponsoring too, if needed
[16:02] <hallyn> but i'd first like to have sarnold review my new cgm :)
[16:02] <hallyn> sarnold: \o
[16:02] <hallyn> pitti: that'd be great;  it's at http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.28-3.dsc .  mainly fixes a bunch of bugs in my initscrfipts,
[16:02] <hallyn> but my sysvinit-foo is weak,
[16:03] <hallyn> so some good "this sucks bc (x)" feedback won't go amiss
[16:03] <hallyn> now, my btrfs-ioctl-foo is weak too, so back to that :(
[16:06] <pitti> hallyn: oh, mbiebl_ was busy filing reports (thanks Michael for catching all those!)
[16:07] <hallyn> pitti: yup, those should all be addressed
[16:23] <pitti> hallyn: followed up with some pointers which hopefully help
[16:24]  * pitti waves good night
[16:25] <hallyn> pitti: thanks - good night
[16:32] <LocutusOfBorg1> can anybody please sponsor?
[16:32] <LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/wxwidgets3.0/+bug/1349498
[16:33] <LocutusOfBorg1> I think this will become a serious bug tomorrow
[16:34] <LocutusOfBorg1> because of this https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752733
[16:34] <LocutusOfBorg1> and the gcc-4.9 default (doko is planning to upload tomorrow the default)
[16:41] <doko> LocutusOfBorg1, delaying. we should sync after 4.9 is the default, and check if the workaround is still needed
[16:42] <LocutusOfBorg1> ok wonderful
[16:42] <LocutusOfBorg1> thanks for caring ;)
[17:08] <bdmurray> xnox: could you have a look at bug 1291434?
[17:10] <xnox> bdmurray: i have noticed that. But I was going to consult cjwatson as to how grub.d snippets should be extending options.
[17:10] <xnox> bdmurray: cause imho, I'm not doing anything wrong, yet cmdline over-expands too much at update-grub time.
[17:14] <xnox> Sweetshark: do you have libreoffice rebuild?
[17:14] <cjwatson> xnox: I'm preparing it now, since it should just be no-change I think
[17:14] <xnox> cjwatson: all of the silly little libs renamed their .pc files.
[17:15] <cjwatson> Oh seriously?
[17:15] <Sweetshark> xnox: for utopic?
[17:15] <cjwatson> Sweetshark: yes
[17:15] <xnox> cjwatson: and e.g. libwpd-stream-0.9 is gone.
[17:15] <xnox> cjwatson: yeah, they encode version number in the pc file name, for what it seems like no reason. E.g. libwpg-0.2 -> libwpg-0.3
[17:15] <cjwatson> Sweetshark: it's got implicated in a massive transition that's holding back half of utopic and blocking nearly everything, which we need to fix before alpha-2 freezes
[17:15] <cjwatson> libcdr, libwpd, libwpg, and libwps are the connection points
[17:16] <cjwatson> xnox: presumably it's an API change as well as an ABI change
[17:16] <Sweetshark> well, I have a 4.3.0~rc4 build which should become final upstream in a few days. Im currently still testbuilding it on armhf ...
[17:16] <cjwatson> Do we *have* to have this with a new libreoffice upstream as well?
[17:16] <cjwatson> This is already horrendously complicated
[17:17] <cjwatson> It would be far preferable to keep the changes as minimal as possible ...
[17:17] <cjwatson> And "a few days" means after alpha-2, which further diminishes the probability of ever finishing this transition, and in particular probably eliminates the chance of landing it before phone RTM forks
[17:17] <xnox> yeah, ideally we'd do distro-patch / rebuild of the current libreoffice.
[17:18] <Sweetshark> cjwatson: whatever you prefer. I just always a bit weary of fixing up details on a e.g. 4.2.x build on utopic, when 4.3.0 comes along a few days after and we never see or need the 4.2.x tweaks again.
[17:19] <cjwatson> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt <- search for the first two occurrences of "Trying easy from autohinter" and you'll see why I'm trying to keep the complexity down
[17:19] <Sweetshark> cjwatson: urgh
[17:19] <cjwatson> Sweetshark: I understand the sentiment, but I think if we try to wait for 4.3.0 here then we'll be doomed
[17:20] <Sweetshark> cjwatson: agree :/
[17:20] <cjwatson> Ah, and indeed now it's just the first occurrence o fthat
[17:20] <cjwatson> *of that
[17:21] <cjwatson> The problem is basically that every time it takes us a few days to fix things, another transition gets itself tangled in the hairball
[17:22] <Sweetshark> cjwatson: you may find me bitching about the libwp{s,d,g} madness earlier today in the backlog
[17:23] <xnox> Sweetshark: yeap, we are on that atm.
[17:23] <cjwatson> Sweetshark: not in this channel, I guess
[17:23] <Sweetshark> cjwatson: eh, right, twas in -desktop, I guess.
[17:24] <cjwatson> Well, if there's anything you can do before we run out of day, it would be greatly appreciated.  I know that's rather a lot to ask in the case of libreoffice
[17:25] <cjwatson> But the a2 freeze is late tomorrow
[17:25] <bdmurray> doko: are you planning on uploading gdb to trusty-proposed?
[17:26] <doko> bdmurray, I can do that. are you planning to do the testing? ;-P
[17:27] <xnox> cjwatson: and like, i totally trust that nothing will be broken once everything migrates =)
[17:27] <Sweetshark> cjwatson: since you dont want LO4.3.0 in this mess, what exactly do you want "anything" to be? A no-change upload of libreoffice? Can do, but cant really do much testing of that before throwing it over the fence. So its fire-n-forget anyway.
[17:28] <xnox> Sweetshark: yeap, we want that. Apart from we know that no-change, will FTBFS most likely.
[17:28] <xnox> Sweetshark: so yeah, no-change rebuild / minimal amount of changes to get it build in utopic-proposed and throw it over.
[17:29] <bdmurray> doko: if there are good test cases then yeah
[17:29] <Sweetshark> xnox: were is the expectation of FTBFS coming from?
[17:29] <doko> ok, preparing ...
[17:30] <Sweetshark> xnox: other than "its libreoffice and we just changed ~all the world below it, that cant work"?
[17:30] <xnox> Sweetshark: e.g. libwpg-dev, pkg-config name changed from libwpg-0.2 to libwpg-0.3
[17:31] <xnox> ditto libwpd-dev libvisio-dev libwps-dev
[17:31] <xnox> i think.
[17:32] <Sweetshark> xnox: hmmm, that shouldnt harm per se. And if it does, I can just throw in an internal copy of libwpX etc. to get this transition over the hill, using the proper system version again later.
[17:32] <Sweetshark> xnox: thats just a oneline change.
[17:33]  * Sweetshark tries.
[17:33]  * Sweetshark originally had other plan for this evening.
[17:33] <xnox> Sweetshark: cool. Yeah, that would work as well. Basically, we don't want anything to depend on the old abi packages... either by building against new stuff or using local copy et.al.
[18:05] <cjwatson> xnox,Sweetshark: hm, another idea, if we can fix everything else then perhaps I can tell proposed-migration to ignore the NBS problem in the case of libreoffice
[18:05] <cjwatson> which would save having to fix that in a tearing hurry
[18:05] <cjwatson> then you could wait for 4.3.0
[18:05] <alexbligh1> Any ideas why packages.ubuntu.com is still showing pre 14.04.1 packages?
[18:06] <cjwatson> it's not ideal but it would be workable - proposed-migration is strict about NBS by default but it doesn't absolutely *have* to be
[18:11] <Sweetshark> cjwatson: sounds good to me.
[18:11] <Sweetshark> FWIW LO4.2.4 is FTBFS in proposed right now.
[18:12] <Sweetshark> cjwatson: ... and "fixing stuff in a hurry" never mixed well with a 3KLOC ./debian/rules file (which generates a ./debian/control file).
[18:18] <achiang> hallyn: dumb question, but is it expected that i can run an armhf container hosted on an amd64 (trusty) machine?
[18:22] <hallyn> achiang: I'm not sure.  I think yhou'll need qemu-user for that
[18:23] <alexbligh1> achiang, https://www.stgraber.org/2012/02/03/ever-wanted-an-armel-or-armhf-container-on-an-x86-machine-its-now-possible-with-lxc-in-ubuntu-precise/
[18:24] <alexbligh1> achiang, trusty being left as an exercise for the reader ...
[18:26] <stgraber> alexbligh1: also mentioned here: https://www.stgraber.org/2013/12/23/lxc-1-0-some-more-advanced-container-usage/
[18:27] <achiang> thanks, reading now
[18:31] <hallyn> yes but do those address armhf on arm64?
[18:31] <hallyn> oh, i misread :)
[18:31] <Sweetshark> cjwatson, xnox: so with http://pastebin.com/7fZK0bmW and a "./debian/rules control" call, "dpkg-buildpackage -B" gets through ./configure. That is most likely all that is needed to fix the FTBFS for 4.2.4.
[18:31] <hallyn> sorry, i thought you wanted to run on arm64.  WHO NAMES THESE
[18:31] <hallyn> achiang: for that you dont' even need to do anythign special;  install qemu-user-static and add '-a armhf' to the container template args.  but, guess your'e reading the blogs, so excellent
[18:33] <Sweetshark> cjwatson: as such, I would suggest to just go for it now with the transition and fix it up quickly then -- should be low risk as a/ LibreOffice 4.3.0~rc4 already finished building in -proposed and b/ LibreOffice 4.2.4 should be trivial to fix with the patch above.
[18:33] <achiang> hallyn: stgraber: ah, i was using -t download instead of -t ubuntu
[18:34] <achiang> perhaps that is why i was tripping over issues
[18:34] <Sweetshark> cjwatson, xnox: So, Ill not prepare an upload of 4.2.4 (hey, I dont have any uploader rights anyway) as discussed and will make this end of day in 10 minutes unless there is loud protest. ;)
[18:34] <stgraber> achiang: ah yeah, -t download just grabs an armhf (or whatever arch you pass) image from the server but this image won't run unless your kernel knows how to run arm code (so armhf, armel or arm64 box). You could manually copy qemu-user-static over to it though which should do the trick.
[18:35] <achiang> stgraber: how would i do that? attempting to start the container doesn't work
[18:35] <stgraber> achiang: it's actually a bit of a bug that -t download lists architectures that your system doesn't support, but figuring out a way to filter those in a distro-independent way and supporting all crazy piece of hardware out there is kinda hard...
[18:35] <achiang> $ lxc-start -n ubuntu-sdk-armhf
[18:35] <achiang> lxc_container: invalid sequence number 1. expected 4
[18:35] <achiang> lxc_container: failed to spawn 'ubuntu-sdk-armhf'
[18:36] <achiang> (that was my earlier issue)
[18:37] <stgraber> achiang: copying /usr/bin/qemu-arm-static to rootfs/usr/bin/qemu-arm-static would help a bit, though IIRC there are a bunch more tricks you need to do in there (which the ubuntu template does for you) such as enabling multi-arch and then install the host-arch version of upstart, mountall, isc-dhcp-client and iproute2
[18:37] <achiang> stgraber: ok. i'll just use -t ubuntu then. :)
[18:39] <achiang> sigh
[18:39] <achiang> no i won't.
[18:39] <achiang> http://pastebin.ubuntu.com/7887191/
[18:39]  * achiang will poke at this later, feeling a bit sick atm so need to go /away
[18:41] <stgraber> achiang: hmm, is lxc-create getting called as root and are you doing that directly on the host or within an existing unprivileged container?
[19:02] <davmor2> bdmurray: hey dude, on the phone if you click on previous errors it seems to take you to a blank errors.ubuntu.com page, is this a known bug?
[19:03] <danilos> heya all, I am trying to build ubuntu-keyboard (lp:~danilo/ubuntu-keyboard/serbian-layout, though the same happens with trunk) on my trusty install using "sbuild", but I am hitting a missing dependency (https://launchpad.net/ubuntu/+source/platform-api/2.1.0+14.10.20140721-0ubuntu1/+build/6202467 seems to be the problem); any suggestions on what to do or how to test this (I've got an up-to-date utopic on my nexus 4 fwiw) before even att
[19:03] <danilos> empting to propose a merge?
[19:04] <danilos> uhm, that was the wrong link, I am building for armhf
[19:04] <danilos> which seems to be built correctly, so I am clearly doing something wrong
[19:09] <danilos> it seems I was missing utopic-proposed in my chroot, let's try with that
[19:20] <xnox> Sweetshark: thanks a lot! I'll tend to that. Bug given how busy buildds are, proposed migrations output will be very cryptic for a while.
[20:40] <achiang> stgraber: no, calling lxc-create as user, directly on host
[21:15] <sarnold> hallyn: -new- cgm? I thought I just reviewed it? :) heh
[21:18] <hallyn> sarnold: i wrote it in C, so it wouldn't have to depend on the dbus package
[21:19] <hallyn> so it could go in with cgmanager, maybe even into /bin (so that sysvinit script can call it to verify cgmangae rhas started)
[21:23] <sarnold> hallyn: ahh, nice. did you re-implement the APIs you were using already or are they new too?
[21:23] <sarnold> hallyn: .. and did you quash that NULL+0-length bug you found in NIH? :)
[21:24] <hallyn> sarnold: no no, same apis
[21:24] <hallyn> lemme think.  I worked around it somehow.
[21:24] <hallyn> oh yeah, I detect the false error from libnih and decdie whether it's a real error or not;  return empty list myself if not.
[21:28] <sarnold> hallyn: ahh :)
[23:03] <bdmurray> infinity: could you have a look at bug 1348200 and bug 1348198?
[23:03] <infinity> bdmurray: I can, but (probably) not today, working on ARM stuff for trusty.
[23:04] <infinity> I assume those are utopic-only.
[23:08] <bdmurray> infinity: no rush, I just was notified of them today
[23:14] <slangasek> infinity, bdmurray: snort at bug #1348198; should probably be fixed with a merge from Debian
[23:16] <infinity> slangasek: We're well overdue for a two-way merge of f-k.
[23:46] <saiarcot895> What is the advantage of the scaling stack builders?
[23:47] <cjwatson> saiarcot895: They're running a trusty base system rather than hardy; and our sysadmins can scale them out horizontally (i.e. add more builders) nearly trivially
[23:47] <saiarcot895> cjwatson: oh, woohoo!
[23:48] <cjwatson> (The former is to some extent an artificially created situation, in that we could have put effort into upgrading the existing setup rather than developing scalingstack; but the latter makes a big difference)
[23:48] <cjwatson> saiarcot895: Also, the underlying system is much less fragile, and we expect builders to die a whole lot less
[23:49] <cjwatson> saiarcot895: And it will be much easier to upgrade them to new versions of launchpad-buildd; with the old system, that was a fairly terrifying process which could turn into a full-day job if the slightest thing went slightly wrong
[23:49] <cjwatson> saiarcot895: With the new system, it's a matter of building a new base image and then new builds just pick it up
[23:50] <saiarcot895> cjwatson: ah, ok. I was wondering about that. So when X comes out, the builders will be on the latest version and have the latest build tools
[23:51] <cjwatson> Should be much easier to do that, certainly; we won't necessarily do it right away
[23:51] <cjwatson> It only matters for stuff that comes from the host, but that includes the kernel, launchpad-buildd, bzr-builder (for recipes), and suchlike