=== sinzui changed the topic of #launchpad to: Topic: https://launchpad.net/ | Help contacts: wgrant | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/
=== Lcawte is now known as Lcawte|Away
=== james_w` is now known as james_w
[03:41] <nawk> What are Blueprints?
[03:41] <nawk> from the looks of, for example, https://blueprints.launchpad.net/linaro
[03:42] <nawk> it looks the word "Blueprint" is a collective term for a set of related tasks
[03:42] <nawk> s/looks/& like/
[03:43] <spiv> nawk: https://blueprints.launchpad.net/ and https://help.launchpad.net/Blueprint hopefully answer that question
[03:44] <wgrant> nawk: Some projects (such as Ubuntu and Linaro) run a work items tracker on top of Launchpad's blueprint tracker. They embed the smaller tasks into the blueprint's whiteboard. This is implemented by external scripts, and is opaque to Launchpad.
[03:46] <nawk> I am kinda noob, the only project management software I ever used was unfuddle
[03:48] <nawk> wgrant: perhaps I need to stepback and start from the first page.   I don't know what a blueprint's whiteboard is.
[03:50] <wgrant> nawk: Taking https://blueprints.launchpad.net/linaro/+spec/packageselection-linaro-n-developer-image, for example.
[03:50] <wgrant> That is a single blueprint.
[03:50] <wgrant> However, it has many sub-tasks listed in the whiteboard field, as you can see.
[03:50] <wgrant> Is that the "set of related tasks" you mentioned initially?
[03:54] <nawk> wgrant: so "packageselection-linaro-n-developer-image" is a single blueprint, and within this EACH blueprint there is a whiteboard that lists the individual work items (what I learn to know from unfuddle as tickets) that make up this blueprint/?
[03:55] <wgrant> nawk: Right. Work items are in fact an Ubuntu invention, and Launchpad knows nothing of them.
[03:56] <wgrant> The whiteboard has traditionally been a freeform text field, with each blueprint representing a single task.
[03:56] <wgrant> Not a collection.
[03:58] <nawk> wgrant: but in the case of the Linaro example, the whiteboard lists a collection of work items, in effect subdividing a single blueprint.
[03:58] <wgrant> nawk: Right.
[03:59] <wgrant> Most modern Linaro and Ubuntu blueprints use work items.
[04:05] <nawk> wgrant: "review manifest of existing packages ..." manifest a file found  in each or most software packages?  (see, I want to learn expose myself to real-world stuff, and not confine myself to school project stuff heh)
[04:06] <wgrant> nawk: That's more of a Linaro question, but I believe it speaks of the list of packages and their versions that are installed.
[04:38] <CarlFK> W: GPG error: http://ppa.launchpad.net maverick Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 2EB11AEDA224C43C
[04:38] <CarlFK> http://launchpadlibrarian.net/65094607/buildlog_ubuntu-maverick-amd64.dvswitch_0.9~rc1-0.6pycon1_FAILEDTOBUILD.txt.gz
[04:38] <CarlFK> um, what?
[04:40] <CarlFK> gah: fail... /build/buildd/dvswitch-0.9~rc1/src/dvsource-firewire.cpp:22: fatal error: libraw1394/raw1394.h: No such file or directory
[04:41] <CarlFK> I know what that's about. swill wondering about NO_PUBKEY 2EB11AEDA224C43C
[04:41] <wgrant> CarlFK: The build farm doesn't know about PPA keys.
[04:41] <wgrant> That warning is normal.
[04:42] <CarlFK> ok, cool.. thanks
[05:04] <CarlFK> "Start in 13 hours" yeiks.
[05:04] <CarlFK> im going to bed.
[05:06] <wgrant> CarlFK: It looks like most of the builders are gone for the day to QA Ubuntu.
[05:09] <CarlFK> need to figure out how to hi-jack a botnet :)
[05:51] <nawk> wgrant: On each Launchpad user page, there is a section for SSH keys, what are those for really?  e.g. https://launchpad.net/~jamiebennett/+sshkeys   Note: I do use ssh on a regular basis
[05:51] <wgrant> nawk: They're for uploading Bazaar branches.
[05:55] <StevenK> And for uploading to Ubuntu with SFTP
[05:56] <wgrant> Nobody does that :P
[05:59] <StevenK> Shush you
[06:00] <ScottK> StevenK likes to feel Launchpad being even slower, so he does it all the time.
[06:01] <StevenK> Oh, sure, SFTP is SO much slower than FTP
[06:02] <lifeless> it should be faster than ftp
[06:02] <StevenK> ScottK: 2/10 See Me
[06:02] <lifeless> only one tcp socket to be affected by slow start
[06:02] <timrc> wgrant: re: https://bugs.launchpad.net/launchpad/+bug/724522 -- might a general solution be to add arguments to createPPA to set buildd_secret and make the ppa private?
[06:02] <StevenK> Whimper
[06:02] <ScottK> It's been most of a decade since I used ftp for anything other than package uploads, so I'm willing to believe you.
[06:02] <timrc> wgrant: this would be tremendously convenient to us :)
[06:03] <lifeless> buildd_secret should not be in the api, ever, AFAICT
[06:03] <timrc> lifeless: what if it's write only?
[06:03] <lifeless> timrc: its not needed.
[06:03] <lifeless> its generated by launchpad, its internal only.
[06:03] <lifeless> we're looking at getting rid of it
[06:04] <timrc> lifeless: ah I guess "Build Farm Secret (optional)" in the web ui is something different then?
[06:04] <lifeless> timrc: if this is particularly important, please escalate it via the stakeholder process
[06:04] <lifeless> timrc: it shouldn't be there either.
[06:04] <lifeless> some of our forms are autogenerated
[06:04] <wgrant> timrc: It used to be set manually.
[06:04] <wgrant> timrc: But now the form sets it automatically.
[06:04] <wgrant> We should remove the field.
[06:04] <wgrant> And set it automatically through the API too.
[06:04] <wgrant> Or someone will just set them all to 'foobar' again...
[06:04] <timrc> wgrant, lifeless: oem still sets it manually and we use it
[06:05] <wgrant> timrc: That would be a bug.
[06:05] <lifeless> timrc: why ?
[06:05] <lifeless> wgrant: can we please split the hang and the ppa api bug into two
[06:05] <lifeless> wgrant: its breaking my brain to talk about them on the same bug
[06:05] <timrc> lifeless: oem manages its own set of archives and pulls packages in from ppas and it requires that secret?
[06:06] <wgrant> lifeless: I didn't there was a PPA API bug.
[06:06] <wgrant> lifeless: But it turns out buildd_secret is not exposed.
[06:06] <wgrant> So there is in fact one.
[06:06] <wgrant> timrc: It requires a password to access the archive.
[06:06] <wgrant> timrc: It does not require the buildd secret.
[06:06] <nawk> Are sprints, real-life meetings or video conferences?
[06:06] <wgrant> nawk: normally the former.
[06:06] <lifeless> timrc: I'd want the technical details for how thats used; I strongly suspect it doesn't do what you think it does.
[06:07] <lifeless> wgrant: I'm splitting the bugs
[06:08] <wgrant> lifeless: Yeah, sorry, I hijacked the bug because I didn't think there was an underlying PPA API bug.
[06:08] <timrc> when we set up the ppa we set the Build Farm Secret and then update our reprepro config to point at  https://buildd:xxx@private-ppa.launchpad.net/...
[06:08] <timrc> lifeless: ^^
[06:08] <lifeless> wgrant: thats fair enough, ut I want a place for timrc to discuss this
[06:08] <StevenK> timrc: Which is wrong.
[06:09] <wgrant> timrc: You should create a user and subscribe it your P3As.
[06:09] <wgrant> The build farm secret is not for external use.
[06:09] <timrc> StevenK: I can't debate the merit of that, this is how it was setup before I ever joined
[06:09] <lifeless> timrc: ok, when can you change this?
[06:09] <timrc> we need Cody here, lol
[06:09] <timrc> lifeless: this probably warrants discussion with smagoun and Cody
[06:10] <lifeless> we are going to be removing the buildd secret as part of cleaning up internal code
[06:11] <lifeless> so you really do need to fix it
[06:11] <lifeless> we should make the API work, for sure. But thats different to exposing this problematic implementation detail.
[06:11] <lifeless> https://bugs.launchpad.net/launchpad/+bug/724740
[06:13] <timrc> lifeless: thank you, sir
[06:14] <timrc> lifeless: at any rate, do you guys have a time line for getting rid of the buildd secret?
[06:14] <lifeless> not fixed. it should be trivial for you to make a service account, subscribe it to all your ppas, and update the reprepo configs.
[06:15] <lifeless> we'll probably get rid of it the next time we do nontrivial feature work on the build farm - making that area of the system more agile and responsive.
[06:15] <lifeless> we've the infrastructure in place with the timelimitedtokens in the librarian to do this now.
[06:16] <StevenK> lifeless: Oh, your plan is the buildd grabs a token, and uses it to download the files and then the token expires?
[06:16] <lifeless> StevenK: julians plan, but yes.
[06:16] <StevenK> Sounds like a good plan
[06:16] <wgrant> That won't quite work.
[06:17] <wgrant> But it's a start.
[06:17] <timrc> lifeless: okay, I'll file the bug on our end and see to the changes
[06:17] <wgrant> (that was originally my plan)
[06:17] <lifeless> wgrants plan.
[06:17] <StevenK> Haha
[06:17]  * lifeless is wrong again :)
[06:18] <timrc> out of curiosity are we able to enable arm builders for a ppa via the api?
[06:18] <wgrant> timrc: Not at the moment.
[06:19] <timrc> We'd need to be able to do that, change the primary dependency, and add external dependencies (btw it's confusing that you add external dependencies from Adminster and all other dependencies from Edit PPA dependencies) :)
[06:22] <wgrant> timrc: External dependencies are a hack that are for migration of old OEM PPAs only :)
[06:22] <wgrant> If you are using them for anything new you are probably wrong :(
[06:22] <timrc> You people are starting to scare me :)
[06:24] <lifeless> timrc: we don't mean to scare you; we adding things to get oem by in the past, added better generic answers after that
[06:24] <lifeless> and we (reasonably) expect that you'll migrate to the generic facilities so that we can delete the special cased code
[06:24] <wgrant> "NOTE: This is for migration of OEM PPAs only!"
[06:25] <timrc> wgrant: that's in the dull gray text I find hard to read
[06:25] <timrc> :)
[06:26] <wgrant> Heh.
[06:29] <timrc> lifeless: maybe we should carve out some time at UDS and go over the special cased code and thumbs up/down it or set a timeline for its removal / our migration
[06:30] <lifeless> timrc: I don't see any reason to either wait for UDS or chew up time there - partly because I won't be at UDS (personal reasons preclude it), and also because its a pretty simple discussion
[06:32] <timrc> lifeless: okay
[09:57] <jtv> RawChid: the fix for that translation bug is currently in testing.  With any luck, it'll go onto our qastaging test server today.
[09:59] <jtv> RawChid: have you or hannie been able to find any instances of the problem on the qastaging or staging servers?  Because if you have, that means that you can test and—hopefully!—confirm the fix before it goes into production.
[09:59] <RawChid> \./
[09:59] <jtv> You'll know that the fix is on qastaging when bug 708385 gets tagged "qa-needstesting."
[09:59] <ubot5> Launchpad bug 708385 in Launchpad itself ""duplicate key value violates unique constraint" when uploading .po" [Critical,In progress] https://launchpad.net/bugs/708385
[10:00] <RawChid> I didn't look on staging. "stageing" is new for me. What is the address?
[10:00] <dpm> hi launchpadders. I've got a local branch that was created from a +junk branch in LP. Now the former +junk LP branch has moved to a project, and I'd like to submit a merge proposal from my local branch (originated from +junk) to the new project branch. What's the best way to do this?
[10:02] <RawChid> jtv, I'm looking on staging now..
[10:04] <jtv> Thanks!  The fix won't be there yet until… probably about the end of your working day.  But once it is, if you have an easy way to determine whether the problem is fixed, that'd be very helpful.
[10:04] <jtv> I'll be traveling tonight and busy with other things after that, so it could speed up deployment by a few days.
[10:04] <lifeless> dpm: push your branch to a project namespace branch - lp:~dpm/project/branchname
[10:05] <dpm> lifeless, ah, cool, thanks
[10:06] <jtv> stub: buttons pushed.  Apologies for the delay.
[10:11] <RawChid> jtv, I see hannie has updated the string which caused problems 18 hours ago on staging. I updated it now and it worked... Don't know if I can say 'bug fixxed' by this..
[10:12] <jtv> RawChid: ah yes, we ran into that yesterday: staging and qastaging have older copies of the database, so the problem in the specific cases you ran into didn't seem to exist there.  :/
[10:12] <jtv> I was hoping that maybe it was just one or two cases of the problem not happening there.
[10:12] <RawChid> I don't know of other cases of the problem
[10:13] <jtv> Hè bah.  The way the problem I fixed worked, it was basically impossible to tell what would be special enough about the data to trigger it.
[10:13] <jtv> But:
[10:14] <jtv> if at least translation still works normally on staging/qastaging after the bug goes qa-needstesting, that's enough to deploy it.
[10:14] <janimo> https://bugs.launchpad.net/ubuntu/+source/ktoon/+bug/642117 I cannot switch the last entry (skrooge) to Fix Released, I get timed out
[10:14] <jtv> janimo: did you get an oops id?
[10:15] <janimo> I'll get one now (I tried abot 4 times already)
[10:15] <jtv> :(
[10:15] <janimo> last night and today
[10:15] <janimo> hey at least it's reproducible :)
[10:15] <jtv> allenap: may be something for you?  ^^^
[10:15] <wgrant> I'm guessing is the bugnotification stuff.
[10:16] <janimo> with the AJAX stuff it just says timed out, no OOPS no, but with the dropdown I get  (Error ID: OOPS-1882B933)
[10:16] <ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=1882B933
[10:16]  * allenap looks
[10:16] <wgrant> We may need to delete all the bugsubscriptionfilters until we get the issues sorted out.
[10:17] <allenap> wgrant: You may be right :-/
[10:17] <lifeless> if it won't break anything, it would make me much more comfortable if we do that
[10:17] <lifeless> we can add them to qastaging
[10:18] <jtv> janimo: thanks—it'll be a few minutes before the oops data becomes available.
[10:18] <wgrant> We can delete the no-op ones.
[10:18] <lifeless> and test the performance there
[10:18] <wgrant> Let's do that.
[10:18] <lifeless> wgrant: can you and allenap coordinate that tonight? it would be nice not to be seeing pain over the weekend
[10:19] <wgrant> We don't seem to have any Yellowers around at the moment :(
[10:19] <allenap> lifeless: Okay.
[10:19] <lifeless> wgrant: no code has landed that makes the noops essential ?
[10:21] <allenap> lifeless: I think there might be, but we ought to check with danilo-afk.
[10:21] <wgrant> That OOPS indeed has the supermassive query.
[10:21] <lifeless> I leave it in your capable hands
[10:24] <lifeless> please be sure to make sure gary is kept in the loop, whatever the actions you agree with danilo
[10:24] <lifeless> I'm sure you would anyway, but he was looking at the bug in question
[10:39] <allenap> wgrant: Are you on danilo's squad?
[10:40] <wgrant> allenap: No, I'm on Curtis'.
[10:41] <wgrant> We may be waiting for the Americas.
[10:41] <wgrant> AFAICT it should be fine.
[10:43] <allenap> wgrant: To just delete all no-op filters? Yeah, should be fine. Do you know why they're being created anyway?
[10:44] <wgrant> allenap: There was a special rollout instruction to create one for every existing structural subscription.
[10:44] <wgrant> I do not know why.
[10:44] <wgrant> Nothing needs them yet.
[10:44] <allenap> wgrant: Okay. I guess I'll wait for danilo-afk et al.
=== danilo-afk is now known as danilo
[10:47] <danilo> allenap: hi
[10:47] <allenap> danilo: Hi there :)
[10:47] <allenap> danilo: It seems that the auto-created (no-op) bug subscription filters are causing problems, and lifeless would like us to delete them.
[10:47] <allenap> danilo: Is this going to break things?
[10:47] <danilo> allenap: what kind of problems?
[10:47] <allenap> Where problems = lots of timeouts.
[10:48] <danilo> allenap: yes, we were designing stuff with the assumption that every structuralsubscription has at least one bugsubscriptionfilter to simplify some linking tables
[10:48] <danilo> allenap: what kind of timeouts?
[10:48] <wgrant> The performance was never tested on staging, and the queries are 323 lines long.
[10:48] <wgrant> You can probably do it again once the query is optimised.
[10:49] <wgrant> But for now we need to get timeouts under control.
[10:49] <danilo> wgrant: the only thing I am missing is what query is problematic
[10:49] <allenap> danilo: The problem is that as soon as a filter exists, left joins to three other tables are done.
[10:49] <wgrant> Bug 723999
[10:49] <ubot5> Launchpad bug 723999 in Launchpad itself "BugNomination:+edit-form structural subscriptions taking 4.8 seconds during nomination editing POST" [Critical,Triaged] https://launchpad.net/bugs/723999
[10:49] <wgrant> danilo: THE query.
[10:49] <allenap> Hehe.
[10:49] <wgrant> The 300-line 10-way union :P
[10:50] <allenap> "Bertha"
[10:50] <danilo> :)
[10:51] <danilo> lifeless mentioned gary as well, let me see if he has emailed me anything re that
[10:53] <wgrant> rofl
[10:53] <wgrant> 826 lines in the plan.
[10:59] <danilo> allenap, wgrant: I'll spend an hour on this, and if I can't come up with a better solution, we'll do whatever necessary to get rid of the timeouts (even if that means dropping BSFs)
[10:59] <allenap> danilo: Cool.
[10:59] <danilo> allenap, wgrant: though, gary will have the final call, just so we are clear :)
[11:00] <wgrant> Great.
[11:00] <wgrant> Thanks.
=== Lcawte|Away is now known as Lcawte
=== yofel_ is now known as yofel
[13:31] <maxb> The current number of available PPA buildds is insufficent to keep up with the rate of new builds :-/
[14:05] <bigjools> maxb: I'm asking to see if the missing ones can go back
[14:05] <maxb> Thanks
[14:06] <maxb> If they can't before the weekend a blog and/or identi.ca note might be worthwhile
=== jcsackett changed the topic of #launchpad to: Topic: https://launchpad.net/ | Help contacts: jcsackett | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/
=== warp11 is now known as warp10
=== henninge_ is now known as henninge
=== doko__ is now known as doko
[15:19] <MTecknology> Adding this PPA to your system : Technical details about this PPA : inside the box | why is there an extra space at the end of each line? ..
[15:24] <jcsackett> MTecknology: i'm sorry, but i don't really follow. what are you looking at?
[15:27] <MTecknology> jcsackett: ppa details
[15:30] <jcsackett> MTecknology: ah, i see. it looks like the box is wrapping a complete line for an apt sources list.
[15:30] <jcsackett> the space is between the ppa url and YOUR_UBUNTU_VERSION_HERE
[15:31] <jcsackett> MTecknology: a complete line is like "deb [url] [ubuntu-version] main"
[15:31] <MTecknology> oh
[15:33] <jcsackett> MTecknology: that's really only meant if you're needing to add lines manually. if you're trying to install the PPA you can get directions by clicking the blue link slightly above the "Technical details" that reads "Read about installing".
[15:34] <jcsackett> that link is in the paragraph of text immediately below the "Adding this PPA to your system"
[15:35] <MTecknology> jcsackett: I always add the line myself and then add the key so I copy/paste then delete the trailing space
[15:35] <jcsackett> MTecknology: dig.
[15:35] <jcsackett> Mtecknology: i might be wrong, but i don't think the trailing space would be a problem.
[15:36] <jcsackett> i always just add-apt-repository though, so i'm not certain.
[15:36] <MTecknology> jcsackett: it's not; but I'm also the kind of person that goes through and tidies up fstab after an install :P
[15:36] <jcsackett> MTecknology: righto. :-)
[15:41] <MTecknology> jcsackett: someday it might bug me enough that I'll submit a patch :P
[15:42] <jcsackett> MTecknology: sounds like a plan. :-)
[15:42] <MTecknology> jcsackett: http://dpaste.com/448473/ :P
[15:43] <jcsackett> and that says all it needs to. :-P
=== deryck is now known as deryck[lunch]
=== beuno is now known as beuno-lunch
[16:36] <achiang> is there a way to un-dup bugs?
[16:37] <achiang> ah, found it
[16:43] <ivaldi> hi - i would like to import some bugs but if i validate my xml i got the following error:
[16:43] <ivaldi> foo.xml:8679:2: error: unfinished content of element https://launchpad.net/xmlns/2006/bugs^bug
[16:43] <ivaldi> required: element https://launchpad.net/xmlns/2006/bugs^comment
[16:43] <ivaldi> but there are no comments in my database...
[16:45] <jcsackett> invaldi: what bugtracker are you importing from?
[16:45] <ivaldi> flyspray
[16:45] <ivaldi> (i wrote my own export)
[16:47] <jcsackett> invaldi: you have already looked at https://help.launchpad.net/Bugs/ImportFormat
[16:48] <ivaldi> yes - and it works fine for 99% of my bugs - but there are a couple with just a description but no comments...
[16:48] <ivaldi> (i could add a dummy-comment - but is this the right way?)
[16:50] <ivaldi> or is the first comment equal the bug-entry?
[16:51] <jcsackett> invaldi: i believe the schema requires a comment; the example xml in the ImportFormat indicates the first comment can be a repeat of the bug description
[16:52] <ivaldi> okay - thank you
[16:53] <jcsackett> ivaldi: you're welcome.
=== beuno-lunch is now known as beuno
=== deryck[lunch] is now known as deryck
=== Ursinha is now known as Ursinha-lunch
[17:40] <MTecknology> how long does it usually take for deletion of packages to actually delete contents?
[17:49] <zyga> hi, does "release URL pattern" ever gets used in practice? if so how can I debug/test this feature on my project?
[17:51] <MTecknology> zyga: it does; http://wiki.debian.org/debian/watch/
[17:52] <zyga> MTecknology, so it's like the debian/watch file?
[17:52] <zyga> MTecknology, how often does lp.net check for new upstream releases?
[17:52] <MTecknology> zyga: oh.... sorry... I've been doing debian packaging so my mind was thinking that; not what you were talkign about
[17:53] <zyga> MTecknology, no, I'm talking about launchpad feature
[17:53] <zyga> you can see it if you go to any series of any project
[17:53] <MTecknology> zyga: but ya.. launchpad uses that url to go out and grab the tarball
[17:53] <zyga> there's a "Release URL pattern"
[17:53] <zyga> ok, how can I debug that
[17:54] <zyga> it does not seem to work for me
[17:54] <zyga> and how often does lp.net checks that url
[17:54] <MTecknology> daily i think
[17:56] <zyga> thanks
[17:56] <zyga> I'll try to debug that with debian/watch
=== sinzui changed the topic of #launchpad to: https://launchpad.net/ | Help contacts: sinzui | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/
[18:01] <MTecknology> sinzui: howdy
[18:01] <sinzui> hi MTecknology
[18:02] <sinzui> MTecknology: zyga: Lp checks everyday for upstream releases
[18:02] <sinzui> except for when I put the job in the wrong section it it gets no net access
[18:03] <sinzui> spm fixed that mistake last week, but we failed to pull releases for more than 2 weeks :(
[18:03] <sinzui> zyga: The lack of a log to explain failure and success is a known issue. There are open questions about how to implement it
[18:04] <zyga> sinzui, thanks for letting me know
[18:04] <zyga> sinzui, I'm re-doing my packages properly and I'll try to use debian/watch so I can ensure this works okay
[18:04] <sinzui> jcsackett: can you change the topic to put me on call. Maybe I am on call, but I cannot see that I am :(
[18:05] <zyga> sinzui, my workflow consists of bzr tree on lp.net, tarballs on pypi and all project information _except_ for documentation being hosted on lp.net
[18:05] <jcsackett> sinzui: you're already in the topic as help contact
[18:05] <sinzui> \o/ one more thing sucks on natty today
[18:06] <jcsackett> no channel info?
[18:06] <sinzui> zyga: I often test the release file glob by setting it my dev instance and running the file-release-finder. I can review the pattern if you like
[18:07] <zyga> sinzui, dev instance of lp.net?
[18:07] <sinzui> jcsackett: the topic seems to be stuck as to what loaded this morning
[18:07] <zyga> sinzui, no that's okay, I think my pattern is wrong right now (missing . before *) but I'll check that after I package the thing it points to
[18:07] <jcsackett> sinzui: ah, that sucks.
[18:08] <sinzui> zyga: oh, maybe not. the patter is file globs, to regexes. That trips me up sometimes
[18:08] <sinzui> s/patter is file globs, to regexes/pattern is file globs, not regexes/
[18:08] <zyga> sinzui, oh, really?
[18:08] <zyga> sinzui, then it's probably right then, I'll know soon
[18:09] <MTecknology> I can't upload this new package until old archive contents go buh-bye; but they no go buh-bye; me go grr
[18:09] <sinzui> zyga:  what series are you pulling released for?
[18:10] <zyga> sinzui, you ask about my project? it's here: https://launchpad.net/linaro-python-json/trunk
[18:10] <sinzui> MTecknology: archive cleanup is asyc from actions. Are you out of space?
[18:10] <MTecknology> sinzui: asyc?
[18:11] <sinzui> apparently my keyboard and spell checking are also knackered today.
[18:12] <sinzui> MTecknology: deletes are scheduled to happen. Deletes from the archive's file system and the librarian can happen hours after you tell Lp to delete
=== Ursinha-lunch is now known as Ursinha
[18:15] <sinzui> zyga: just looking at pypi, I do not see a match. To match the file I see I would change: s/linaro-python-json-*.tar.gz/linaro-json--*.tar.gz/
[18:16] <zyga> sinzui, right, thanks! I did change the name of my project some time ago and must have forgot about this part!
[18:21] <MTecknology> sinzui: File php5_5.3.5.orig.tar.gz already exists in PHP5 5.3.3, but uploaded version has different contents.
[18:23] <sinzui> MTecknology: I do not think you can delete that kind of mistake. Once it is published your only choice is to increment the version
[18:24] <MTecknology> sinzui: I never uploaded that version though.. i don't think..
[18:24] <sinzui> Let me see
[18:24] <MTecknology> http://ppa.launchpad.net/nginx/php5/ubuntu/pool/main/p/php5/
[18:24] <MTecknology> 5.3.5 doesn't exist in there anywhere and that's teh version I'm tryign to upload
[18:25] <MTecknology> I'm positive it's my mistake; just confused
[18:25] <zyga> sinzui, MTecknology, I'm puzzled, uscan uses regex yet lp.net uses globs, is that intentional?
[18:26] <zyga> I constructed a regrexp that works for my project, it omits alphas, betas and candidates and just looks at releases
[18:26] <zyga> http://pypi.python.org/packages/source/l/linaro-json/linaro-json-([^abc]*)\.tar\.gz
[18:26] <MTecknology> zyga: ignore what i said about debian/watch; i read your question wrong
[18:26] <zyga> should this work on lp.net as well?
[18:27] <sinzui> zyga: I /think/ the intent was to make this easier for users. We are using the python glob lib instead of re. I would have expected re since I believe packagers are the primary users of this featyre
[18:27] <MTecknology> zyga: this is what I use with nginx -      http://nginx.org/download/nginx-0.9.*.tar.gz Change details
[18:29] <zyga> MTecknology, sigh, then it's going to pick up all the non-final releases as well
[18:29] <zyga> ok, I'll see how this work out in practice
[18:29] <zyga> thanks
[18:31] <MTecknology> zyga: http://pypi.python.org/packages/source/l/linaro-json/linaro-json-1.*.tar.gz
[18:31] <sinzui> MTecknology: I am a bit confused too. I know lp will remember every package version ever uploaded and never let that package version be uploaded again because that could mean there are two different packages claiming to be the same. When I discover my package was built wrong, I quickly release a higher version because someone may have installed the bad version in the 30 minutes that may have passed
[18:32] <sinzui> I do delete the bad package BTW, so that someone does not pull the bad version
[18:33] <sinzui> zyga: that glob looks good
[18:33] <MTecknology> sinzui: I can try a higher version.. it might magically work..
[18:45] <MTecknology> sinzui: ya.... this is going to suck....
[18:46] <MTecknology> sinzui: there's an uploaded version of php5_5.3.5.orig.tar.gz but the correct contents are different..
[18:46] <sinzui> in your ppa, or in may archives?
[18:47] <MTecknology> in the ppa
[18:47] <MTecknology> I don't see it there though..
[18:48] <sinzui> I think the librarian knows about it. You are getting an email able the failure?
[18:48] <MTecknology> sinzui: http://dpaste.com/448922/
[18:48] <MTecknology> yup- there it is
[18:48] <sinzui> that really sucks
[18:49] <MTecknology> any way to easily fix it?
[18:50] <MTecknology> I don't even know how I could grab the original tarball
[18:50] <sinzui> I recall that this has happened before. I think the packager had to claim the version of the orig was higher. I do not know the naming rule offhand
[18:50] <MTecknology> I'd rather not though because it'd be wrong
[18:50]  * sinzui looks
[18:53] <sinzui> I think I am catching up with you know MTecknology. I see https://bugs.launchpad.net/launchpad/+bug/491165 in which Julian explain you need to introduce a new name
[18:54] <sinzui> MTecknology: The librarian will not be purged of that file for some time days/weeks
[18:55] <sinzui> MTecknology: I think php5_5.3.5~1.orig.tar.gz may be that name to use
[18:56] <MTecknology> ouchy..
[18:56] <MTecknology> sinzui: is there any way to get the correct file back?
[18:57] <MTecknology> the one lp sees as correct
[18:57] <sinzui> I am unsure of ~1, but I think that what someone used a few weeks ago to get a save version uploaded
[18:57] <sinzui> MTecknology: that can happen when the librarian really does the purge. The librarian is like a mark-ans-sweep memory scheme
[18:59] <MTecknology> sinzui: is there any way to purge that ppa and remake it?
[18:59] <sinzui> MTecknology: The other problem is that bad version could be in the wild now. That is why the emphasis is to increment the version so that users know there is something better. Since you have delete the bad package, you have done the responsible thing
[18:59] <MTecknology> hm....
[18:59] <sinzui> MTecknology: no. The name is taken. If you delete it. you cannot create a new one with the same name.
[19:00] <MTecknology> so I need to fight this until > php5_5.3.5 is released
[19:01] <MTecknology> so   php5-5.3.5-1-1ubuntu2ppa1~lucid
[19:01] <MTecknology> that's a long version string
[19:03] <MTecknology> sinzui: it takes a long while to build the package on this system... I'll let you know how it works after upload
[19:03] <sinzui> MTecknology: php5-5.3 is the release, we use ~ to indicate the package version
[19:05] <MTecknology> so that version string i have won't work?
[19:06] <sinzui> I think: php5-5.3.5~2ubuntu2ppa1~lucid means upstream php5-5.3.5 second packageing, for lucid
[19:06] <MTecknology> I thought I understood the versions... they're so easy at debian repo version...
[19:07] <sinzui> MTecknology: I could be wrong, I am not a motu,
[19:07] <MTecknology> 5.3.5-0; 5.3.5-1
[19:09] <sinzui> MTecknology: I think I am wrong, the ~ is for the series
[19:10]  * MTecknology waits for the reply from launchpad
[19:10] <MTecknology> just random... run and mountain dew is amazing..
[19:11] <MTecknology> sinzui: accepted :D
[19:11] <sinzui> \o/
[19:11] <MTecknology> now a few hours to build...
[19:12] <MTecknology> 17min is the longest wait.. not too bad
[19:12] <MTecknology> the build time blows
[19:15] <MTecknology> i mean 19min..
[19:20] <MTecknology> i mean only 33min
[19:21] <MTecknology> no.. I'm getting this wrong.. 47min
[19:21] <MTecknology> 48*
[19:24] <MTecknology> and building on everything
[19:25] <MTecknology> the time estimate drives me insane; but it makes sense why it'd be hard to estimate
=== Ursinha is now known as Ursinha-afk
[19:32] <MTecknology> sinzui: thanks for the help :)
[19:32] <sinzui> your welcome
[19:42] <jcsackett> lifeless: oh goodie.
[19:51] <MTecknology> abotu 30min left of build time...
[20:23] <bigon> hey https://bugs.staging.launchpad.net/ubuntu/+source/upower/+bug/722483 << I'm I the onlyone who have a Ã"demo" background?
[20:25] <bigon> argh I've used requestsync tool and it looks like i got the staging url
[20:26] <bigon> even better the bug has been opened on the staging db (I'm not supposed to have access to that I guess)
[20:27] <lifeless> staging and qastaging are sandpits
[20:27] <lifeless> we allow anyone to play there
[20:27] <lifeless> but make no guarantees about reliability/availability
[20:27] <lifeless> and the data is reset weekly
[20:28] <bigon> alright, still requestsync openend the bug on staging
[20:30] <bigon> lifeless: thx, so it's a bug against syncrequest, I've opened a bug there
[20:30] <lifeless> bigon: requestsync uses the launchpad API - if its talking to staging, you need to talk to the requesetsync developers
[20:30] <lifeless> yes
[20:41] <MTecknology> sinzui: well... it's done and out there; yippie
[20:43] <janimo> do bzr commits which contain (LP: #XXXXX) not mark a certain bug as Fix Committed? I was hoping it would do the equivalent of a package upload using the syntax which sets Fix Released
[20:43] <lifeless> janimo: they simply link the bug and branch
[20:50] <janimo> lifeless, ok thanks
[20:51] <lifeless> janimo: we can improve on this in the future (e.g. when it hits a series branch close) - but that would be wrong for many projects
[20:51] <lifeless> janimo: (if not most) - because 'in trunk' != 'released' for most people
[20:51] <lifeless> so, some thought would be needed
[20:52] <janimo> lifeless, right. This is a trunk commit that made me think about it. But committed != fix released anyway so it would not imply anything about release
[20:52] <janimo> in other news thanks for fixing the huge query timeout of today. I could now close those bugs
[20:53] <lifeless> janimo: danilo and wgrant and others did that, but I think they aren't here - so on their behalf, you're welcome
[20:53] <janimo> right, well I meant thanks to the team :)
=== lifeless changed the topic of #launchpad to: Buildds misbuilding - please do not upload | https://launchpad.net/ | Help contacts: sinzui | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/
=== Ursinha-afk is now known as Ursinha