[00:49] <shadeslayer> wgrant: could you also enable arm for https://launchpad.net/~netrunner-arm/+archive/ubuntu/netrunner-odroid-c1-ci-patches and https://launchpad.net/~netrunner-arm/+archive/ubuntu/netrunner-odroid-c1-ci and https://launchpad.net/~netrunner-arm/+archive/ubuntu/netrunner-odroid-c1 please
[01:11] <wgrant> shadeslayer: The last was already done.
[01:12] <wgrant> The others are now too.
[01:12] <teward> wgrant: is there a suggested limit for ARM builds now?
[01:12] <teward> other than no more than 6 a week or w/e it is
[01:13] <teward> (I have 5 nginx packages to upload to the staging PPA that will build ARM)
[01:13] <wgrant> The suggested limit is that you be reasonable about things.
[01:13] <wgrant> How long does it take under qemu-user-static?
[01:13] <wgrant> Does it work?
[01:14] <wgrant> The limits (well, guidelines really) are in place mostly because qemu-user-static can be very slow.
[01:14] <teward> judging from prior it's about 45mins each for arm.
[01:14] <teward> give or take an hour system to system
[01:14] <teward> but not insane
[01:14] <wgrant> As long as they work, that sounds fine.
[01:14] <wgrant> (this'll all be much easier in a couple of months when we have actual ARM VMs)
[01:14] <teward> indeed
[01:15] <teward> ... i should probably not be on the computer, there's a really heavy evil storm outside... o.o
[01:15] <teward> wgrant: i bet there's people that upload things that take eons to build in arm, and that's why the limits exist?
[01:15] <teward> or people that would *want* to make those kinds of uploads
[01:16] <wgrant> Right.
[01:16] <wgrant> The rule is really "don't be stupid about it", but that's not very easy for people to objectively judge about themselves :)
[01:16] <teward> :P
[01:17] <wgrant> If something's valuable and not a hideous resource hog, ARM builds are probably fine.
[01:17] <teward> given that i've made stupid mistakes with the main repos on accident before, and then very quickly rectified, i'm used to judging something insane
[01:17] <wgrant> Heh
[01:17] <teward> i failed with an nginx security debdiff that was sponsored a while ago, that was definitely fun xD
[01:18] <teward> loooong while ago xD
[01:18] <teward> it caused SEGVs everywhere, and it was Debian's fault... xD
[01:18] <teward> anyways, thanks, wgrant, for answering :)
[01:21] <wgrant> np
[03:41] <sergio-br2> is it possible to ask arm64 build for PPA?
[03:43] <wgrant> sergio-br2: qemu-system-aarch64 doesn't work very reliably, so we don't recommend it at the moment.
[03:43] <wgrant> er
[03:43] <wgrant> qemu-user-aarch64, rather
[03:44] <sergio-br2> why canonical doesn't use real hardware for ARM ?
[03:44] <sergio-br2> isn't it easier?
[03:45] <Peng> like, a rack of cheap tablets? :P
[03:45] <sergio-br2> raspberry pi 2 cluster, heh
[03:45] <sergio-br2> dunno
[03:45] <wgrant> It's easier if you can get the hardware, sure.
[03:45] <wgrant> Server-class, virt-capable ARM hardware has been very difficult to come by until this year.
[03:45] <wgrant> We have some now, but it's not set up yet.
[03:46] <sergio-br2> hardkernel uses a cluster to compile the kernel
[03:46] <wgrant> Sure
[03:46] <sergio-br2> to odroid
[03:46] <wgrant> But they're not running code from random people as root.
[03:46] <wgrant> We have lots of ARM hardware for Ubuntu builds, but they can't run VMs efficiently.
[03:46] <wgrant> They're Cortex-A9s.
[03:47] <wgrant> hardkernel are probably using virt-capable ODROID-XUs, but they're not exactly server-class :)
[03:47] <sergio-br2> hum, VM for what? If it's already arm hardware?
[03:47] <wgrant> VMs for security.
[03:47] <sergio-br2> ah
[03:47] <wgrant> We don't *particularly* want to allow anyone with an email address to run code as root on bare metal...
[03:48] <sergio-br2> so i386 and amd64 uses VM for each build?
[03:48] <sergio-br2> dunno how these stuff works
[03:49] <wgrant> Yes.
[03:49] <wgrant> Every build runs in a VM, and that VM is destroyed afterwards.
[03:51] <sergio-br2> oh
[03:51] <sergio-br2> qemu too for them?
[03:52] <sergio-br2> canonical uses VM too to every build in the repo?
[03:52] <wgrant> All virtual PPA builds today run in a 64-bit x86 KVM OpenStack instance.
[03:52] <wgrant> armhf and arm64 run qemu-user-static on top of those VMs.
[03:53] <wgrant> Ubuntu's builds are currently on bare metal, but they'll be moved into VMs, just like PPAs, in the coming weeks.
[03:53] <sergio-br2> oh
[03:53] <sergio-br2> but just a few people has access, so what's the problem?
[03:53] <sergio-br2> does debian do it too?
[03:54] <wgrant> What's what problem?
[03:54] <sergio-br2> *about security?
[03:54] <wgrant> For official Ubuntu builds there are fewer security concerns. But there aren't none.
[03:54] <sergio-br2> hum
[03:54] <wgrant> And there are no obvious benefits to not using VMs for them, so we might as well use VMs for them.
[03:55] <wgrant> VMs have several benefits and minimal drawbacks.
[04:07] <sergio-br2> very interesting
=== anthonyf is now known as Guest97499
[14:05] <leitao> is  launchpad down? I am not able to create a bug....
[14:05] <leitao> I got ' (Error ID: OOPS-fad1e185aee71ff2d33ce6044b50c7b7) ' when creating a bug.
[14:05] <ubot5> https://oops.canonical.com/?oopsid=OOPS-fad1e185aee71ff2d33ce6044b50c7b7
[14:16] <dobey> no. at least, i can view merge proposals just fine
[16:34] <jafo> How do I decrypt the message PGP message Launchpad sends to confirm my key?  I am getting "gpg: CRC error".  Is launchpad sending invalid PGP data?  I saved off the message as text, and did "gpg -d 0.txt", also tried "gpg --armor -d 0.txt".
[16:35] <jafo> http://paste.debian.net/241524/
[16:39] <jafo> Aside: It sure would be nice if my PPA page said that I didn't have a key in my account and uploads would say they succeeded but would silently fail.  Or the PPA page would say "Hey, an upload was tried, but it failed."  Because searching I found something saying it could take hours to generate a PGP key for the PPA, so I waited all day yesterday for it to "catch up".
[16:44] <dobey> does your e-mail client not have pgp support?
[16:44] <jafo> Correct.
[16:45] <dobey> afaik, launchpad sends valid mime content in the e-mail
[16:49] <jafo> Oh, it is quoted printable.  I can convert it using Python.
[16:50] <jafo> It looks like it is just PGP data I can save and decrypt, but it isn't.
[16:50] <dobey> right
[16:52] <jafo> Yay, at least now I get an e-mail about why it failed!
[16:53] <dobey> yeah, lp can't really give you an e-mail if you don't sign the package with a key that's connected to your account. the uploads are anonymous ftp, and it has no way to connect the upload to a specific account in a reliable way
[16:54] <dobey> it might be good if it sent an e-mail to the owner of the ppa in such cases though
[16:57] <jafo> dobey: I'm telling dput that it is for "ppa:username/package".  It doesn't include that information in the FTP upload?
[16:58] <jafo> Yay, I have my package up there now!
[16:59] <dobey> jafo: it does, but you could be trying to upload to someone else's ppa, or a team-owned ppa.
[16:59] <jafo> Oh, it is building for precise.  How do I tell it to build for Precise *AND* trusty?
[16:59] <dobey> this is why i said it might be good to notify the owner of the ppa, rather than the uploader, in such question
[16:59] <jafo> dobey: Gotcha.
[16:59] <dobey> you have to upload a different source for each series
[16:59] <dobey> or copy to other series
[17:04] <jafo> dobey: How do you copy to another series.  I tried changing the changelog and uploading again, but it rejected that because of a file with an existing name but different contents.
[17:04] <dobey> you can't re-upload the orig.tar.gz with different contents
[17:04] <dobey> there's UI on the web page for the ppa to do a copy
[17:08] <jafo> I guess I just don't understand it.  I select "Copy packages" select the source, select a destination of "This PPA" and "Series: Trusty", and it fails: "Copied from libRETS. Target series: Trusty.  librets 1.6.1-1realgo in precise (same version already building in the destination archive for Precise)."
[17:11] <dobey> were you trying to copy the binaries, or did you select to rebuild?
[17:19] <jafo> dobey: I don't have binaries yet.
[17:20] <jafo> Yeah, I selected "rebuild the copied sources".
[17:22] <dobey> ok, i'm not sure
[17:23] <jafo> http://box.jafo.ca/launchpad.jpg
[17:23] <jafo> That's the page I submitted.
[17:25] <dobey> ok. i'm not sure what's wrong
[17:28] <jafo> I sure do miss having a good friend on the launchpad team...  :-/ :-)
[17:29] <jafo> Maybe it will work when the package builds...  I've also tried pushing up a "1" suffix package name with trusty specified, and that was accepted.  Not ideal, but workable.
[17:30] <dobey> is the code hosted in a bzr branch in launchpad? or mirrorable into a bzr branch on launchpad?
[17:32] <jafo> The code is not hosted in a bzr branch.  I guess it is possible to mirror it to launchpad, it is hosted on github.  I don't control the upstream, I'm just packaging it.
[17:36] <dobey> when i package things in PPAs, i've started just maintaining a branch which only contains the contents of the debian/ dir, and using source imports and source package recipes, so that it's mostly all automated
[17:37] <dobey> pretty nice, and makes having different builds for different series mostly trivial
=== dpm is now known as dpm-afk
[17:43] <jafo> I've got a github repo that has the debian dir.  Might submit it upstream once it stabilizes.
[17:44] <jafo> Sounds like what you are doing might be a good way to go for maintaining the PPA.
[17:44] <jafo> Is there something that documents making that happen?
[18:12] <dobey> there are docs on the launchpad help page for source package recipes, yeah