[01:06] <EagleScreen> hi
[01:06] <EagleScreen> is there any channel to talk about launchpad development?
[01:06] <persia> Some stuff is on-topic here, details have #launchpad-dev
[01:07] <EagleScreen> does it envolves soyuz dvelopment?
[01:08] <wgrant> Soyuz is part of Launchpad, so it belongs in #launchpad-dev with the rest.
[01:08] <persia> What is your question?
[01:11] <EagleScreen> I only want to talk about this wishlist bug https://bugs.launchpad.net/soyuz/+bug/188564
[01:11] <ubot5> Launchpad bug 188564 in Soyuz "Build also packages for Debian in PPA's (affected: 41, heat: 310)" [Low,Triaged]
[01:11] <EagleScreen> some people think that adding unstable or testing Debian suits is as easy as adding a new Ubuntu suit, is it true?
[01:12] <persia> Not precisely, no.
[01:12] <wgrant> It's mostly an issue of build resources.
[01:12] <EagleScreen> what is the difference?
[01:12] <wgrant> Not a technical problem.
[01:12] <persia> wgrant, Well, there's the virtual/non-virtual game, and questions of build-environment, etc.  But yeah, only minor technical: mostly financial.
[01:13] <EagleScreen> if a new Ubuntu suit is added each 6 months, can't be a Debian siut added as the same way?
[01:15] <EagleScreen> at least for i386 and amd64 archs
[01:17] <persia> Non-trivially, and not without significantly more machines (as people would want to use them)
[01:18] <EagleScreen> do you think that more servers would be needed? more cost?
[01:18] <persia> Yes.
[01:19] <EagleScreen> really? it would be just one or two new suits..
[01:19] <Nafallo> we deprecate an ubuntu release every 6 months as well (usual case for non-LTS)
[01:20] <wgrant> EagleScreen: It would probably be two new series. And if most people are building for only two or three Ubuntu series already, that doubles the amount of hardware required.
[01:21] <lifeless> EagleScreen: we regularly use all our machines with a significant backlog
[01:21] <lifeless> EagleScreen: as wgrant says adding a new target would also need machines to build it to be feasible
[01:21] <EagleScreen> then I understand that it is a economic issue
[01:22] <persia> EagleScreen, I suspect that if you approached Canonical with significant financial incentive, you may be able to make that happen.  I do not believe that attempting to get the bug closed will achieve much, as the operators probably wouldn't enable the additional suites even if they were turned on.
[01:22] <persia> (alternately, if you run a private LP instance, it oughtn't be that hard to implement, to run on your machines)
[01:23] <EagleScreen> I see..
[01:23] <EagleScreen> is already natty available for PPA upload?
[01:24] <persia> Happens the same time as natty appears anywhere else.
[01:24] <EagleScreen> I have receibed this email:
[01:24] <EagleScreen> Launchpad failed to process the upload path '~<EagleScreen>/ppa/ubuntu/natty':
[01:25] <wgrant> EagleScreen: '<EagleScreen>' is not a valid Launchpad username.
[01:25] <EagleScreen> remove < > ?
[01:26] <wgrant> Right, but a Launchpad username is also lowercase.
[01:26] <wgrant> eg. 'eaglescreen'
[01:33] <EagleScreen> at upload:
[01:33] <EagleScreen> Unable to find distroseries: experimental
[01:33] <EagleScreen> this package was obtained from Debian experimental repo
[01:34] <EagleScreen> but doesn't launchpad allow upload it if I specify the subfolder to natty?
[01:34] <paultag> One last thing to bug the LP admins in here about -- I need to set the Bug Supervisor to the LoCo Council -- I am not an admin on the team ( council members are members of the team ), and I asked persia ( on the CC, which owns the LC ), and he was not able to see the pages. What should I do?
[01:34] <wgrant> EagleScreen: Yes. I suspect that you didn't specify it properly.
[01:34] <EagleScreen> ok
[01:35] <EagleScreen> will pastebin my dput.cf
[01:36] <persia> EagleScreen, it's not about dput: it's about your changelog entry.
[01:37] <EagleScreen> I think changelog can be experimental or unstable if I specify the Ubuntu suit upload subfolder
[01:37] <wgrant> persia: The dput path can override the changelog entry.
[01:37] <persia> wgrant, Sure, but does Soyuz process that?  I thought it just followed .changes
[01:38] <wgrant> persia: It respects the path in preference to .changes.
[01:38] <wgrant> This is, however, fairly widely regarded as evil.
[01:39] <persia> Ah, then I'll keep telling folk it works the way it should, and just wait for some Soyuz developer to unexpectedly fix it one day.
[01:39] <EagleScreen> this is http://pastebin.ca/1982382
[01:40] <wgrant> persia: The way it should?
[01:40] <wgrant> persia: It obeys the .changes unless you explicitly specify a distroseries in the upload path.
[01:40] <EagleScreen> I have uploaded packages to PPA with unstable in the chnagelog
[01:41] <EagleScreen> but some time ago
[01:41] <wgrant> EagleScreen: That's fine. But why are you regularly uploading packages with the wrong series in the changelog?
[01:41] <persia> wgrant, And about the evil bit?
[01:42] <wgrant> persia: It is often abused to upload unmodified Debian source packages, when this is not in fact an appropriate thing to do.
[01:42] <EagleScreen> wgrant: why not? time ago they were accepted, any change about this?
[01:42] <paultag> EagleScreen, it wastes time
[01:42] <wgrant> EagleScreen: It will be accepted, but it's not always the right thing to do.
[01:42] <persia> wgrant, Right, which is why I don't like path overrides.
[01:42] <paultag> EagleScreen, and you suck up the build farm time
[01:43] <paultag> EagleScreen, for a package that can be found upstream
[01:43] <persia> paultag, Not necessarily: binary package differences can be extreme even with the same source.
[01:43] <paultag> persia, if there is a distro check, yeah -- but then it would have been caught in the sync with Debian for Ubuntu it's self
[01:43] <EagleScreen> then usntable is not longer accepted?
[01:44] <paultag> right?
[01:44] <persia> paultag, Consider build-dependencies
[01:45] <paultag> hummm, true.
[02:01] <EagleScreen> Not permitted to upload to the RELEASE pocket in a series in the 'CURRENT' state. <-- what does this mean??
[02:03] <wgrant> EagleScreen: You tried to upload to Ubuntu itself.
[02:03] <wgrant> Not a PPA.
[02:04] <EagleScreen> how is it possible?
[02:04] <EagleScreen> this is my dput.cf: http://pastebin.ca/1982392
[02:05] <wgrant> EagleScreen: Why are there capital letters in your Launchpad username?
[02:05] <wgrant> Launchpad usernames cannot contain capital letters.
[02:05] <wgrant> I would also strongly encourage you to rethink how you are creating your packages.
[02:06] <wgrant> Using the path override should *not* be a normal occurrence.
[02:06] <EagleScreen> wgrant: this last error was with natty and maverick in changelog
[02:06] <EagleScreen> Checking now the capital letters ..
[02:07] <wgrant> EagleScreen: Which command did you use to upload?
[02:07] <wgrant> I suspect you omitted the target.
[02:08] <EagleScreen> lol; I put the targer after the .changes
[02:08] <EagleScreen> the target go first, right?
[02:09] <wgrant> Yes.
[02:12] <EagleScreen> one package didn't build due to a missing build-dependency, if I upload that dependency to my PPA, will the package build later if I retry?
[02:14] <wgrant> It should.
[02:16] <EagleScreen> nice
=== bac changed the topic of #launchpad to: Launchpad: https://launchpad.net/ | Read https://help.launchpad.net/ for help | On-call help contact: bac | Join https://launchpad.net/~launchpad-users | This channel is logged: http://irclogs.ubuntu.com/ | Launchpad is open source: https://dev.launchpad.net/
[02:49] <bac> Hello, I am the Launchpad help contact for today.  Please ping me if you have questions.
[06:01] <MTecknology> bac: https://launchpad.net/~hjgf
[06:01] <MTecknology> bac: I suspect spamming - adding all teams in LP ?
[06:02] <MTecknology> wgrant: you might wanna look too?
[06:05] <wgrant> MTecknology: Not another one :(
[06:05] <MTecknology> sorry..
[06:05] <wgrant> spm: ^^
[06:08] <spm> user suspended, team deleted
[06:08]  * spm wields the sledgehammer.
[06:17] <MTecknology> spm: yay
[06:18] <MTecknology> spm: that means now you help me with my package?
[06:18] <spm> hm?
[06:19] <MTecknology> I finally made it build without fail - but what's produced isn't at all what I was expecting
[06:21] <StevenK> That sounds like a packaging issue, rather than something that a LOSA can help with ...
[06:22] <MTecknology> StevenK: it is.. but you can't blame me for asking :D
[07:00] <bac> thanks MTecknology.
[07:01] <MTecknology> bac: :) Death to spam!
[07:05] <wgrant> spm: Could you also delete ~vishnu.team?
[07:05] <wgrant> spm: It's the same user, and similar members.
[07:06] <wgrant> Also ~ab2.team.
[07:06] <wgrant> WTF
[07:06] <lifeless> ?
[07:07] <wgrant> Those three spam teams all with similar members.
[07:07] <MTecknology> wgrant: probably the same person too?
[07:08] <wgrant> Yes.
[07:08] <wgrant> They're all owned by the suspended user.
[07:08] <spm> bah
[07:08] <MTecknology> I wonder what the goal of that was.. it's not exactly 'that' disruptive
[07:09] <spm> no idea
[07:10] <spm> wgrant: both removed
[07:10] <wgrant> spm: Thanks.
[07:11] <wgrant> Ohhh.
[07:11] <wgrant> It's this same guy again.
[07:11] <wgrant> He was at it a few months ago.
[07:11] <wgrant> And some of the teams from back then are in this web.
[07:15] <spm> lovely
[07:16] <wgrant> I thought that one of the teams was legit.
[07:16] <wgrant> (~india.launchpad.team)
[07:16] <wgrant> But most of its 100 members were added within a few minutes of each other.
[07:16] <wgrant> I suspect involuntarily.
[07:17] <MTecknology> perhaps a feature added that doesn't allow you to add a team to a team unless either a) you're a member (admin?) of both or b) an admin approves it?
[07:17] <wgrant> MTecknology: That's already the case.
[07:18] <MTecknology> oh..
[07:18] <wgrant> Those teams he added are also owned by him.
[07:18] <MTecknology> oh..except ~kernel-bugs - that got added
[07:18] <wgrant> Ah, true.
[07:19] <lifeless> we need rate limiting heuristics
[07:19] <lifeless> for many many things
[07:19] <MTecknology> oh!... I remember when he was doing that last - I think I even pointed it out that time :P
[07:19] <wgrant> You did, yes.
[07:21] <MTecknology> I need to toss in a little bit more spam control on wiki.nginx.org too...
[07:24] <MTecknology> lifeless: perhaps.. spam detection that.. once is 95% confident you're spamming.. 1) blocks you 2) warns losa 3) losa confirms spam 4) deletes teams 5) suspends user 6) reaches through the internet and blows up computer 7) if shrapnel causes extra dammage, oh well  ??
[07:25] <spm> we have orbital deathrays that a nameless person installed when he was in orbit, we can use.
[07:25] <MTecknology> vader?
[07:26] <spm> on the grounds I like my job very much thanks, I will strenuously deny that it's vader or a vader like person
[07:26] <twb> FYI, Debian's w3m maintainer has patched w3m to handle <BUTTON>, which was a show-stopped for launchpad logins.
[07:26] <MTecknology> :P
[07:26] <twb> LP: #628755, closes: #136810
[07:27] <spm> twb: good news! (have hit that one msyelf doing internal stuff)
[07:34] <MTecknology> g'night everyone
=== jtv1 is now known as jtv
[09:00] <mrevell> Morning
[09:00] <Tak> hello
=== LinuxJedi|away is now known as LinuxJedi
=== Guest26427 is now known as jelmer
=== bac changed the topic of #launchpad to: Launchpad: https://launchpad.net/ | Read https://help.launchpad.net/ for help | On-call help contact: - | Join https://launchpad.net/~launchpad-users | This channel is logged: http://irclogs.ubuntu.com/ | Launchpad is open source: https://dev.launchpad.net/
=== matsubara-afk is now known as matsubara
=== yofel_ is now known as yofel
[12:52] <ari-tczew> why this branch has been created? https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/therion/natty-201011040312
[13:02] <gnomefreak> i keep getting OOPS 1770g1142
[13:03] <gnomefreak> i keep getting OOPS 1770G1142
[13:04] <gnomefreak> anyway its a time out OOPS
=== mrevell is now known as mrevell-lunch
[13:09] <gnomefreak> ok the bug koads fine just when i try to add xulrunner-2.0 to it it times out
[13:09] <gnomefreak> s/koads/loads
[13:14] <falktx> hi there
[13:14] <falktx> i just noticed a bug on PPAs
[13:14] <falktx> when I try to copy many packages at once, I get a server timeout error
[13:21] <gnomefreak> i get one when trying to add a package to a bug filed on PPA
[13:22]  * gnomefreak finally gave up
[14:29] <geser> ari-tczew: this happens when the package importer notices a difference between an upload and an bzr push; james_w can probably explain it better
[14:30] <ari-tczew> that is a reason for me to not using bzr
[14:39] <tumbleweed> I'm guessing we don't have /dev/shm mounted in launchpad-buildd, right? bug 671441
[14:39] <ubot5> Launchpad bug 671441 in joblib (Ubuntu) "joblib FTBFS in Natty (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/671441
[14:41] <shane4ubuntu> I setup a ppa and imported a key (for signing and uploading my package) when I tried to import my ppa to my system I get this error:  Error: can't find signing_key_fingerprint
[14:42] <shane4ubuntu> Is that the same key as my uploading thing?  or is it different?
=== mrevell-lunch is now known as mrevell
=== LinuxJedi is now known as LinuxJedi|away
[15:04] <achiang> this is a rather stupid question, but can i add more um, entries, to a lazr Collection object?
[15:04] <achiang> looking at dir() doesn't tell me much
[15:10] <jml> achiang: it's not a stupid question
[15:10] <jml> achiang: but I don't know what the answer is
[15:10] <jml> dir() isn't very helpful on lazr objects in general.
[15:10] <achiang> jml: hi! you're back in england now?
[15:10] <jml> achiang: indeed I am.
[15:11] <achiang> jml: the weather can't be worse than here in boston. solid rain for the past few days
[15:11] <jml> achiang: it's been a little better than that.
[15:11]  * achiang is getting a little homesick, wants to return to http://bit.ly/a0gWxk
[15:13] <achiang> jml: my real issue is that i've discovered that in launchpadlib, searchTasks() by default won't tell you about tasks that are closed
[15:13] <jml> ahh yes
[15:13] <jml> achiang: you have to specify every status to get that
[15:14] <achiang> so my thought was i would do a pass with searchTasks(status="Fix Committed") and then add on the results from default searchTasks()
[15:14] <jml> achiang: here's one I prepared earlier: http://paste.ubuntu.com/526361/
=== Ursinha is now known as Ursinha-lunch
[15:15] <achiang> jml: that seems easy enough, but i want to avoid some DRY in my code. i guess it won't be so terrible if i just globally define a list of the statuses and just reference that list in each call to searchTasks
[15:15] <achiang> jml: your method is simple enough that even I can understand it though. :)
[15:15] <jml> achiang: yeah, that sounds right.
[15:16] <jml> achiang: it's arguably a bug that you have to have such a list
[15:16] <achiang> jml: i'm doing a little hacking on my tool that helps me write my status reports: tells you about all launchpad activity in the last week and dumps it out to copy/paste into an email
[15:17] <achiang> jml: the tool is not quite as useful if it doesn't tell you about bugs you've closed. ;)
[15:17] <jml> achiang: ahh, nice.
[15:18] <achiang> https://launchpad.net/laika
[15:18] <achiang> still in the extremely hacky stage right now. trying to find the proper home for it at some point.
[15:18] <achiang> perhaps it'll need a rewrite and integration into bughugger
[15:22] <jml> achiang: yeah, there's not really a good home for tools like that.
[15:22] <jml> maybe lptools
[15:23] <achiang> jml: yeah, that was my other thought
=== matsubara is now known as matsubara-lunch
=== Meths_ is now known as Meths
=== beuno is now known as beuno-lunch
=== vila is now known as Bernardo
=== Bernardo is now known as vila
[16:20] <jcastro> deryck: any idea why I can't linkify this here to the upstream url? https://bugs.launchpad.net/wajig/+bug/540740
[16:20] <ubot5> Launchpad bug 540740 in wajig (Ubuntu) "wajig installfoo gives misleading error message (affected: 1, heat: 6)" [Undecided,New]
[16:21] <deryck> hi jcastro.  looking now...
[16:21] <jcastro> the upstream bug is in google code so I don't think I need to register it?
[16:22] <deryck> jcastro, yeah, you'll still have to register their tracker on google code.
[16:23] <jcastro> k
[16:23] <jcastro> that wasn't so obvious
[16:23] <deryck> jcastro, and looking at https://bugs.launchpad.net/wajig it looks like the project is set up to have lp track its bugs.
[16:23]  * jcastro can fix that
[16:24] <sladen> could somebody ban  braulioareis  until we work out what's going on
[16:25] <sladen> they've been changing statuses and bug assignments all over the place
[16:25] <deryck> sinzui, ^^
[16:26] <jcastro> deryck: ok I just need to know where to link lp/wajig to the external tracker? I don't see anything in administer
[16:27] <deryck> jcastro, I think only the project maintainer can setup the tracker.  that project has an individual listed as the maintainer.
[16:27] <jcastro> ah ok
[16:27] <jcastro> but now that a bug tracker is registered I can still set a bug watch right?
[16:29] <sladen> hggdh: I see you've been clearing up after  braulioareis  too
[16:30] <sladen> hggdh: sinzui: are we able to do this in a more pragmatic way---I presume there are audit logs
[16:30] <sinzui> sladen, no there are no audi logs
=== LinuxJedi|away is now known as LinuxJedi
[16:32] <sladen> sinzui: joke or seriously?
[16:32] <sinzui> sladen, true
=== matsubara-lunch is now known as matsubara
[16:32] <hggdh> sladen: yes, I have, but I cannot work on the upstream projects
[16:32] <sinzui> sladen, deryck. I do not think the activity log can every be used to roll anything back
[16:33] <jcastro> deryck: hmm, still no place to paste a URL
[16:33] <sladen> hggdh: yeah, I've hit the same issue... not all the changes are reversible
[16:33] <deryck> jcastro, the upstream has to use the tracker you registered first
[16:33] <jcastro> ok so in this case, pasting it in a comment will probably work?
[16:34] <deryck> sinzui, sladen -- the activity log has the data, but we don't currently have a way to roll back based on that data
[16:34] <hggdh> sladen: yup. But at least we can clean those we have access to. I also emailed the braulioareis guy about his acitons
[16:34] <sinzui> sladen, deryck, allenap. I see there is already a question about braulioareis? If he has already been contacted I am tempted to suspend him right now
[16:34] <hggdh> sinzui: I just emailed him
[16:35] <deryck> sinzui, we haven't contacted him.  I thought you were, for some reason.
[16:35] <hggdh> sinzui: and I did that as a bugsquad/control admin, not as a LP person
[16:35] <allenap> sinzui: https://answers.launchpad.net/malone/+question/132396
[16:35] <sinzui> deryck, I do not see my involvement in https://answers.edge.launchpad.net/malone/+question/132396
[16:36] <sinzui> deryck, I worked with a user who lost control of his email this week. Maybe that is what you recall
[16:37] <deryck> sinzui, yes, I think so.  Sorry
[16:37] <deryck> I assumed that was this guy.
[16:37] <sinzui> I really wish we had standing working, or a CoC requirement to work across communities
=== deryck is now known as deryck[lunch]
[16:45] <sladen> sinzui: did we get them suspended yet?
[16:46] <sinzui> I have the screen open, I was going to wait 15 more minutes to hear if the user apologised.
[16:46] <allenap> I think we should suspend his account. I haven't seen any activity on his account that doesn't look like experimentation.
[16:47] <sinzui> sladen, suspend is very drastic. We cannot undo it. an Lp admin can and arranging that often takes weeks
[16:48] <allenap> sinzui: What is the difference between "Deactivated" and "Suspended"?
[16:49] <sinzui> allenap, users are reactivated on login. is SSO/authentication worked, it would also restore your email address and launchpad id
[16:49] <sinzui> allenape, deactivated is really governed by the user, not us.
[16:50] <allenap> sinzui: Ah, okay. The only hammer we have is a very very big one.
[16:51] <sinzui> allenap, suspend locks the email address, sets the user to http status to 410 and breaks SSO too. It is a great way to shutdown anyone using ubuntu or launchpad SSO
[16:52] <sinzui> allenap, this issue qualifies as "poor standing" Nothing uses standing, but the idea is that users with "poor" should not be permitted to cross communities. Users with great standing could cross post to lists without being members
[16:55] <allenap> sinzui: It would be nice to manually just stop the user from using Launchpad for a while, without breaking SSO.
[16:57] <sinzui> We were given access to suspend users to deal with spammers, and it does exactly what we intend. Standing was designed to solve community permission issues. My last two attempts to raise its priority failed :(
[16:57]  * sinzui suspends ~braulioareis
=== deryck[lunch] is now known as deryck
=== beuno-lunch is now known as beuno
=== oubiwann is now known as oubiwann-away
=== oubiwann-away is now known as oubiwann
[17:33] <alkisg> Hi, can I build-depend on something that is on universe when uploading to my launchpad PPA?
[17:34] <alkisg> Sorry, should have googled before asking - found it at https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage - it says "yes" :)
=== Ursinha-lunch is now known as Ursinha
=== zyga is now known as zyga-food
[18:59] <alkisg> Do packages on launchpad have internet access while they're building? E.g. debian win32-loader uses wget to download vmlinuz as part of its build process...
=== zyga-food is now known as zyga
[19:04] <micahg> alkisg: no
[19:05] <alkisg> micahg: thank you, so I have to patch it and include a vmlinuz inside the source tree
[19:06] <micahg> alkisg: or package it as a separate source
[19:06] <alkisg> micahg: sorry, can you elaborate?
[19:06] <alkisg> Ah, you mean the whole kernel as a dependency?
[19:07] <micahg> alkisg: yes
[19:07] <alkisg> No I'm looking to use gpxe.kdn to provide a "boot from network" option for windows PCs
[19:07] <alkisg> *krn
[19:07] <alkisg> So vmlinuz == gpxe.krn in my case, and that's not on debian/ubuntu yet
[19:07] <alkisg> (it's on fedora but not on debian)
[19:08] <alkisg> So I'll be forced to use a binary blob...
[19:08] <alkisg> Hm. Or not. You're right
[19:08] <alkisg> I've already packaged that to my ppa, so I can use it. Thanks!
[19:32] <cody-somerville> Is there a PRODUCTION_SERVICE_ROOT constant in launchpadlib or something? How do I access the production service root? :P
[19:32] <james_w> cody-somerville, LPNET_SERVICE_ROOT IIRC
[19:32] <james_w> not in old old versions of launchpadlib
[19:33] <cody-somerville> ah
[20:07] <cody-somerville> james_w, was it added in 1.6.5? I have 1.6.4 and it doesn't seem to have it.
[20:07] <james_w> cody-somerville, I don't remember
[20:07] <james_w> cody-somerville, does your version have a launchpadlib.uris module?
[20:08] <cody-somerville> yup
[20:08] <cody-somerville> ah
[20:08] <james_w> cody-somerville, then you can just use "lpnet" or something and it will translate for you
[20:08] <james_w> plus the variable can be imported from there
[20:18] <derks> hello... is it possible for a non subscriber to send to a launchpad team mailing list at all?  for example.. we have a hudson build system and want to send failure emails to a launchpad list...
=== almaisan-away is now known as al-maisan
=== zyga_ is now known as zyga
=== al-maisan is now known as almaisan-away
=== matsubara is now known as matsubara-afk
=== JanC_ is now known as JanC
=== Ursinha is now known as Ursinha-afk
[23:12] <wgrant> lamont: Did you hear about the buildd-manager fun yesterday?
=== LinuxJedi is now known as LinuxJedi|away