[01:41] <MTecknology> edge went away? :(
[01:46] <lifeless> MTecknology: iz going
[01:46] <lifeless> MTecknology: why so sad?
[01:47] <MTecknology> lifeless: I just noticed I can't do recipes - I was going to try again
[01:48] <lifeless> you should be able to on edge
[01:48] <MTecknology> oh.. I just don't have the automatic redirect anymore?
[01:48] <lifeless> right
[01:48] <lifeless> edge is going
[01:48] <MTecknology> oh
[01:48] <lifeless> its not gone yet
[01:49] <MTecknology> will recipes be available when it does go?
[01:49] <lifeless> recipes will be available to recipe beta testers on production before edge goes
[01:49] <MTecknology> yay
[01:50] <MTecknology> lifeless: what's the team name?
[01:52] <lifeless> dunno yet :)
[01:52] <MTecknology> alrighty
[02:06] <MTecknology> lifeless: dpkg-source: error: can't build with source format '3.0 (quilt)': no orig.tar file found
[02:06] <MTecknology> lifeless: Any idea what's up with that?
[02:07] <lifeless> there was a thread on the bzr list about this
[02:07] <lifeless> is a bug (obviously)
[02:07] <wgrant> I don't think it's a bug.
[02:07] <wgrant> dpkg in maverick just doesn't fall back any more.
[02:08] <wgrant> Launchpad's daily builds feature doesn't support orig tarballs yet.
[02:08] <lifeless> wgrant: its a usability issue for recipes
[02:08] <wgrant> It is.
[02:08] <MTecknology> Natty-> Could not build because of chroot problem
[02:08] <wgrant> MTecknology: That's because IS needs to set up natty bzr-builder packages.
[02:08] <MTecknology> so for now I still need to build each series by itself if I need to use quilt?
[02:09] <wgrant> You can't use quilt. You can only build a native package.
[02:09] <wgrant> <= lucid automatically fall back to native.
[02:09] <wgrant> maverick doesn't.
[02:09] <wgrant> So you need to specify 3.0 (native) or 1.0 to get the same behaviour.
[02:10] <MTecknology> ok
[02:10] <MTecknology> what are the changes of that breaking something else?
[02:11] <wgrant> It should have been building native packages anyway.
[02:11] <wgrant> So just about zero.
[02:11] <MTecknology> alrighty
[02:11] <MTecknology> so 3.0 (quilt) and 3.0 (native); those both use the same patch system or??
[02:11] <wgrant> 3.0 (native) doesn't have a patch system. Everything ends up in the tarball.
[02:12] <MTecknology> what about debian/patches/* ?
[02:12] <wgrant> Which recipe is this?
[02:12] <MTecknology> or am I utterly lost in the patching system?
[02:12] <MTecknology> https://code.edge.launchpad.net/~nginx/+recipe/nginx-development/
[02:13] <StevenK> The idea with recipes is the patches are directly applied, since you have version control
[02:13] <wgrant> dpkg-source: info: source format `3.0 (quilt)' discarded: no orig.tar file found
[02:13] <wgrant> dpkg-source: info: using source format `1.0'
[02:13] <wgrant> MTecknology: That's from the Lucid log.
[02:13] <wgrant> So it's using 1.0.
[02:13] <wgrant> And therefore probably not applying patches.
[02:14] <MTecknology> If I change source/format from 3.0 (quilt) to 3.0 (native) - would it apply patches the same way?
[02:14] <wgrant> The same way as 1.0, which is "not at all".
[02:14] <MTecknology> oh...
[02:15] <wgrant> 3.0 (quilt) applies patches.
[02:15] <wgrant> That's why 'quilt' is in the name.
[02:15] <MTecknology> so if I want to use the patching system.. I have to build nd upload myself?
[02:15] <wgrant> Why do you want to use a patch system?
[02:15] <wgrant> Why not have the changes directly in the branch that you merge in?
[02:15] <wgrant> s/branch/branches/
[02:16] <wgrant> I hear that bzr is good at this merging thing.
[02:16] <MTecknology> because the source is an exact copy of the upstream source; anything done to the package is inside debian/
[02:16] <wgrant> You could alternatively include a patch system in debian/rules.
[02:16] <wgrant> But I would be making the changes directly in another branch which is then merged on top of trunk.
[02:17] <MTecknology> how do you include the patching system in debian/rules?
[02:17] <StevenK> I would check, but I purged quilt from this machine for being crap
[02:18] <wgrant> Hah.
[02:18] <MTecknology> I'm not the biggest fan of quilt either..
[02:18] <wgrant> Woah, old-style debhelper rules file.
[02:18] <StevenK> Haha
[02:18] <MTecknology> but the debian maintainer uses quilt so if I send them a patch; it's easiest to keep it quilt
[02:19] <StevenK> quilt has a way to import a patch file into a quilt patch file, so meh
[02:22] <exarkun> If this release, <https://launchpad.net/pyopenssl/main/0.11>, was only registered 3 hours ago, how can some of its files have been downloaded 24 hours ago?
[02:22] <MTecknology> Is it going to be possible to use a patching system in a recipe someday?
[02:22] <wgrant> MTecknology: Yes.
[02:22] <wgrant> MTecknology: We just need to work out a nice way to handle orig.tar.*
[02:23] <MTecknology> wgrant: oh... I suppose since you can't just upload them as you do with the dput method..
[02:24] <wgrant> Right. We need to either extract them from bzr (using pristine-tar, probably), or find some other way to get them in there.
[02:24] <lifeless> MTecknology: in the bzr thread folk suggesting forcing them to native
[02:25] <MTecknology> lifeless: which means no patch system so any patches are dropped?
[02:30] <MTecknology> I can handle building them individually for now. I was just hoping
[02:30] <MTecknology> I'm excited for recipes to be ready for the big time
[02:30] <MTecknology> lifeless: so where's the mailing list?
[02:31] <MTecknology> alrighty - 8 builds waiting - 2 will die right away
[02:32] <MTecknology> I feel I annoying to many people that actually understand what's going on
[02:33] <lifeless> MTecknology: bzr@l.l.n
[02:33] <lifeless> erm
[02:33] <lifeless> bzr@l.c.c
[02:33] <MTecknology> thanks
[02:41] <MTecknology> If you upload a lot of packages to be built - can you be 'punished' and have to wait longer for it to build?
[02:42] <StevenK> #define a lot ?
[02:43] <MTecknology> attempting a recipe build for lucid/maverick/natty in two ppa's then after failing; trying the same thing again by building them myself
[02:43] <MTecknology> really.. I should only have built for one ppa and just copied
[02:43] <lifeless> MTecknology: at the moment queue scheduling is very static. This will change.
[03:03] <MTecknology> Would any of you kill be if I decided to upload all of python to be built?
[03:03] <wgrant> All of Python?
[03:04] <MTecknology> every single python package that's in main
[03:04] <MTecknology> or wait..
[03:04] <MTecknology> what was it that was really killing builds a while back that got uploaded a couple times?
[03:05] <MTecknology> sorry for the dumb attitude - I think I'm lacking on sleep pretty bad
[03:12] <wgrant> MTecknology: That was Python, yes.
[03:12] <wgrant> Not just main, though.
[03:12] <wgrant> 'twas the whole archive.
[03:13] <MTecknology> wgrant: that wasn't exactly a fun time for packaging :P
[04:55] <micahg> lamont: when you get a chance can you kill the build on iridium and prevent it from starting again? It's going to hang until bug 663294 is fixed
[04:56] <micahg> lamont: if you can't do that easily, let me know and I"ll delete the xulrunner build in the PPA
[08:35] <eagles0513875|2> hey guys i have a question is it possible to import a public key that i generated outside of linux such as with putty or xshell etc how can i upload my key?
[08:37] <persia> eagles0513875|2, You should be able to upload a key generated with any tool, although you may need to check the documentation for that tool to find the public key in local storage.  Once you identify the public key, the remainder of the procedure should be unchanged.
[08:38] <eagles0513875|2> persia: i have my keys on my pendrive for portability
[08:38] <eagles0513875|2> hummo k
[08:38] <eagles0513875|2> humm ok
[08:38] <eagles0513875|2> thanks persia
[08:47] <eagles0513875|2> hey guys for bugs in a bzr project i created where do i file bugs against the project
[08:47] <eagles0513875|2> of mine
[08:53] <odony> Hi, anyone familiar with the launchpadlib API here? I'm trying to get the number of bugs in a given status for a projects, but get this interesting error "TypeError('collection size is not available')" ... Am I supposed to iterate over the (huge) collection of matching bugs just to know how many there are?
[08:54] <odony> the API seems to indicate that you can query the length of collections: https://help.launchpad.net/API/launchpadlib#line-428
[09:01] <fta2> henninge, dpm: hi, did you get email wrt my chromium translations issue?
[09:01] <fta2> +my
[09:02] <henninge> fta2: yes, looking at it atm
[09:03] <henninge> at the issue, I mean
[09:03] <henninge> will get back to you
[09:03] <fta2> ok, excellent, thanks
[09:03] <dpm> morning fta2, I'm just reading all post-UDS e-mail right now, I haven't come to it yet, but I will in a few mins
[09:04] <fta2> henninge, btw, i mentioned only one change, but there are a few more (mostly encoding of \n and some xml entities i had to do to ensure the full bijection between grit and gettext)
[09:12] <odony> about my issue with sizing launchpadlib collections, seems to be an upstream bug from lazr, found a workaround here: https://bugs.launchpad.net/wadllib/+bug/274074 ... long outstanding issue apparently
[09:13] <odony> seems fixed in wadllib 1.5.5, gonna try that, otherwise monkeypatching lazr.restfulclient.resource.Collection.__len__ works for me
[09:33] <henninge> fta2: So, it must be an error in the export-to-branch script, AFAICT
[09:33] <henninge> fta2: A manual export of a po file produces correct data (i.e. without "<ph" in it)
[09:34] <fta2> henninge, without &amp;ph too?
[09:34] <henninge> Also, I notice that the exported files still reference the old POT-Creation-Date, whereas the manual export has the new date
[09:34]  * henninge looks
[09:34] <fta2> henninge, search for "ph path=" instead
[09:35] <henninge> fta2: you can do a manual download of a single file here https://translations.launchpad.net/chromium-browser/translations/+pots/chromium-strings/de/+export
[09:35] <fta2> henninge, i meant "ph name="
[09:35]  * henninge looks
[09:35] <henninge> fta2: nothing
[09:36] <henninge> in fact, "ph" only occurs twice in the whole file, but in only as part of other words.
[09:36] <fta2> ok. so the script populating the branch is broken
[09:36] <henninge> yup
[09:36] <henninge> fta2: can you please file a but about that?
[09:36] <fta2> ok
[09:37] <henninge> https://bugs.launchpad.net/rosetta/+filebug
[09:38] <henninge> fta: as a work-around you can download all the translations in a tarball from here: https://translations.launchpad.net/chromium-browser/translations/+export
[09:38] <henninge> fta2: ^
[09:39] <fta2> henninge, i guess the content on my email is good enough, right?
[09:39] <henninge> fta2: yes, but add that a manual export works as expected.
[09:39] <fta2> ok
[09:40] <henninge> fta2: with the tarball download, I am not sure if the file naming suites your branch ... :(
[09:40] <henninge> sorry about the inconvenience
[09:40] <fta2> as for the tarball, we already discussed that a few weeks ago, it won't work for me, due to different file names policy
[09:40] <henninge> what I feared ... :(
[09:41] <henninge> fta2: I will see that we find the reason and a fix for it asap.
[09:42] <fta2> bug 669831
[09:44] <fta2> henninge, thanks. would be nice. I just have a knob to flip in the chromium package to re-enable the translations merges
[13:51] <berco> hi
[13:51] <berco> anyone knows what to do if want a 3PA to build for natty as well as maverick?
[14:18] <persia> berco, Did you already try just uploading with "natty" in the changelog?  Did that not work?
[14:53] <Laney> berco: You can upload to M and then use the Launchpad PPA interface to copy the package to N.
[14:53] <Laney> Or upload to M and then N with a higher version.
[15:27] <micahg> deryck: convert to question is a no go: OOPS-1767E1152
[15:27] <berco> persia: I tried it but my package has been rejected
[15:28] <deryck> micahg, will it work on a reload?
[15:28] <berco> Laney: I thought I could specify both "maverick natty" in my changelog
[15:28] <persia> berco, Aha!  Then it is something awkward.  If nobody gets back to you here, file a question (answers.launchpad.net/soyuz)
[15:28] <persia> berco, No, you can only specify one.
[15:28] <micahg> deryck: no
[15:29] <deryck> micahg, ok.  Will take it up a notch.
[15:29] <berco> persia: pk. According to the debian policy I understood I could list both distri
[15:29] <deryck> lifeless, can you do feature flags, or do you need an admin like the rest of us?
[15:29] <berco> I'll try with just natty
[15:29] <micahg> deryck: thanks
[15:29] <persia> berco, Dunno if that's a bug in policy or a bug in Soyuz :)
[15:30] <lamalex> Is there any way to direct what bugmail goes to what email address?
[15:31] <lamalex> I'd like to send my Unity bugmail to my Canonical email address, but for the projects I do in my free time I'd prefer my gmail
[15:31] <deryck> lamalex, no, there's no way to do that.  We use the preferred email address for all bug mail.
[15:34] <Laney> You can filter by the X-Launchpad headers though
[15:35] <lifeless> deryck: the form requires Launchpad.ADMIN to make changes.
[15:35] <lifeless> deryck: e.g. ~admin only. Rubber ducky, you're the one.
[15:35] <deryck> k, thanks.
[15:36] <deryck> lifeless, micahg reports the 15 seconds doesn't help.  Perhaps he's on lp.net now.  Do you mind 20 secs on that page now?
[15:36] <lifeless> deryck: cross check the PPR
[15:36] <deryck> lifeless, PPR?
[15:36] <lifeless> deryck: page performance report
[15:36] <lifeless> that will show you the spread
[15:36] <deryck> ah
[15:36] <lifeless> then check a representative OOPS
[15:36] <lifeless> that will give you /some/ idea.
[15:37] <lifeless> if there is a big uptick at the right edge of the graph, it means incompleted requests are hitting the timeout in significant numbers
[15:37] <lifeless> that means that raising the timeout will spread the uptick out, but you may find it needs to be higher.
[15:40] <maxb> berco: Debian policy says you can list multiple distributions there. It does *not* however define what it means to do so, AFAIK, so it's up to each individual implementation of an upload processor to determine what to do
[15:40] <deryck> ok, thanks, lifeless.  We may need higher then.  I read it as, generally ok for everyone but Ubuntu. :-)  Waiting on OOPS to sample.
[15:43] <micahg> deryck: do you need me to try again or is the oops above ok?
[15:43] <deryck> micahg, it should be fine.  There's some delay between the OOPS generated and the web interface to review it.
[17:22] <nekohayo> hey there, I just got added to https://launchpad.net/~ubuntu-answer but I still can't create FAQs for https://answers.launchpad.net/ubuntu/+source/pitivi/+question/132140/+createfaq (for example); I get the same "Not allowed here" error. What's up?
[19:00] <MTecknology> Is there any chance somebody could look at why this is broken? https://code.launchpad.net/~nginx/nginx/echo-module
[19:13] <cjohnston> jamesh: ping
[19:16] <lifeless> MTecknology: file a question on answers.launchpad.net/launchpad-code ?
[19:24] <deryck> micahg, the page is in too bad a shape for me to raise the timeout.  Nothing will help until we fix the root cause of the timeout.
[19:24] <micahg> deryck: :(
[19:25] <deryck> micahg, sorry, man.
[19:25] <micahg> deryck: I understand, is it still at the top of the list?
[19:26] <deryck> micahg, yes.  next on my list for the bugs team, but that's still a few days off from being started.  Just no capacity yet.
[19:26] <lifeless> micahg: its in the timeout bucket, which is prioritised to the top of the 'current work backlog' for all LP teams.
[19:26] <micahg> deryck: ok, thanks, let me know if you need testing
[19:26] <deryck> micahg, definitely will.
[19:26] <deryck> thanks!