=== yofel_ is now known as yofel
=== lifeless changed the topic of #launchpad to: http://launchpad.net/ | Read https://help.launchpad.net/ for help | Help contact: - |  Join https://launchpad.net/~launchpad-users | This channel is logged: http://irclogs.ubuntu.com/ | Launchpad is open source: https://dev.launchpad.net/
[01:36] <poolie> spiv after yesterday i want to write an auto bug deduper
[01:41] <spiv> What happened yesterday?  The symlinks-on-windows bug?
[03:13] <RAOF> lifeless: But of courset.
[03:14] <lifeless> so, you got 'could not connect to launchpad' ?
[03:14] <RAOF> “Please try again. Sorry, there was a problem connecting to the Launchpad server.”
[03:15] <lifeless> spm: ^
[03:15] <lifeless> spm: ha proxy queue size?
[03:15] <wgrant> Which URL?
[03:15] <lifeless> apport bug filing
[03:16] <wgrant> edge or production?
[03:16] <wgrant> After entering the description?
[03:16] <RAOF> wgrant: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+filebug/36e2e3cc-bedc-11df-98f4-0025b3df357a
[03:16] <RAOF> After entering description & hitting “submit bug”
[03:16] <spm> lifeless: 0 still
[03:17] <wgrant> OK, so it's the issue I was poking at last week.
[03:17] <lifeless> wgrant: have you filed a bug on this?
[03:17] <wgrant> No. I should.
[03:17] <lifeless> !!!!
[03:17] <wgrant> This one has lots of attachments, as expected.
[03:19] <RAOF> Is it likely to work later?
[03:20] <wgrant> I guess this is probably the only situation in which an appserver does upwards of 1000 INSERTs in a single transaction.
[03:20] <wgrant> Uh. Maybe.
[03:20] <wgrant> It apparently does occasionally work.
[03:21] <wgrant> I've never seen it work, though.
[03:21] <wgrant> RAOF: I believe the issue is the number of attachments in the apport blog.
[03:21] <wgrant> Removing most of them, or not using apport, will alleviate the issue.
[03:22] <RAOF> Ok.
[03:22] <RAOF> I filed a nearly-identical bug a couple of days ago, and that worked.
[03:22] <RAOF> It did have exactly one fewer attachments, though.
[03:23] <lifeless> 1000
[03:23] <lifeless> wtf
[03:23] <lifeless> wgrant: whats going on there
[03:25] <thumper> ??
[03:36] <wgrant> lifeless: Each attachment generates a BugNotification.
[03:36] <wgrant> lifeless: Each BugNotification generates a BugNotificationRecipient for all notified users.
[03:37] <wgrant> Which is slightly over 50.
[03:37] <wgrant> And the apport blob referenced there has 20ish attachments.
[03:38] <lifeless> holy mother of f****
[03:38] <lifeless> thats terible.
[03:38] <wgrant> It was designed back before apport existed... when each transaction could add at most one attachment.
[03:38] <wgrant> It still sucks.
[03:38] <wgrant> But it's less utterly OMFGworthy.
[03:39] <lifeless> can we just consolidate them ?
[03:39] <lifeless> the error received is particularly weird
[03:39] <lifeless> spm: and when you say 0 you're looking in the grey line, not the appserver-lines, right ?
[03:39] <wgrant> So, we should probably get a LOSA to watch staging.
[03:39] <wgrant> Since we can reproduce it there;
[03:40] <wgrant> And work out if the appserver is returning an error, or what.
[03:40] <wgrant> Since it comes back too quickly to be a timeout.
[03:40] <spm> losa(1) are kinda busy atm. watching is not something I have vast spares of right nooo
[03:40] <wgrant> Heh.
[04:59] <lifeless> wgrant: ok, so how do we fix this
[04:59] <lifeless> wgrant: I'm assuming that any package with many subscribers will fail consistently.
[05:09] <wgrant> lifeless: We need to first work out going wrong.
[05:09] <wgrant> I'm hoping that somebody just recently applied an INSERT limit to appserver DB users... that would be convenient.
[05:09] <wgrant> But sadly unlikely.
[05:09] <wgrant> (yes, we should reduce the query count... but there's something deeper going on here)
[05:10] <wgrant> It's easily reproducible on staging and lpnet.
[05:10] <lifeless> so, have you filed ze bug?
[05:10] <wgrant> Was considering it.
[05:10] <wgrant> Will do so now.
[05:10] <lifeless> wgrant: I'm amazed that you haven't. You normally are so effective at recording issues.
[05:11] <wgrant> Yes, but this issue is very unclear.
[05:11] <lifeless> I don't see how the lack of a place to discuss it makes it clearer
[05:11] <wgrant> Nowadays I tend to diagnose before I file, with LP bugs.
[05:11] <wgrant> But this one's too deep.
[05:11] <lifeless> bad habit to be in :)
[05:11] <wgrant> Shh.
[05:12] <lifeless> oh hahahhahha
[05:12] <lifeless> timeout.txt was so badly confused its not even slightly funny
[05:12] <wgrant> Hm?
[05:13] <lifeless> db_statement_timeout is in ms
[05:13] <lifeless> there is a test that sets it to '10'
[05:13] <lifeless> and then asks for the current timeout value, expecting it to be < 5
[05:14] <lifeless> yes, it will be < 5.
[05:14] <lifeless> but 10ms is apparently not enough to get through 5 lines of doctest.
[05:14] <lifeless> reliably.
[05:14] <lifeless> the newer timeout code which is a little more... robust, blew up.
[05:14] <wgrant> Haha.
=== Mobe_ is now known as Mobe
[05:16] <lifeless> oh
[05:16] <lifeless> and hahahhahahha
[05:17] <wgrant> Oh?
[05:18] <lifeless> we don't record all timeouts apparently
[05:19] <lifeless> because RequestExpired (used by the google search service timeout) doesn't record a timeout
[05:19] <wgrant> Hah.
[05:19] <lifeless> I may  be wrong
[05:20] <wgrant> Bug #636801
[05:20] <lifeless> am testing ze theorem now
[05:20] <ubot5> Launchpad bug 636801 in Launchpad Bugs "+filebug with lots of apport attachments results in a 502 (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/636801
[05:20] <wgrant> I thought everything was RequestExpired.
[05:20] <wgrant> But I haven't looked at that machinery in a while.
[05:20] <lifeless> TimeoutError
[05:20] <wgrant> Oh, right.
[05:20] <lifeless> They both implement IRequestExpired or some such
[05:21] <lifeless> anyhow -> #lp-dev
[05:24] <lifeless> wgrant: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/636804
[05:24] <ubot5> Launchpad bug 636804 in Launchpad Foundations "request expired being raised does not increased the opstats timeout count (affected: 1, heat: 6)" [Undecided,New]
[05:24] <Laibsch> what's up with launchpad?  It's almost completely unresponsive.  edge is a little better but still almost completely unusable.
[05:24] <lifeless> Laibsch: what page?
[05:24] <Laibsch> all
[05:24] <Laibsch> ;-)
[05:25] <lifeless> its pretty fast for me
[05:25] <lifeless> can you tell me more
[05:25] <Laibsch> I'm in China currently if that makes any difference
[05:25] <lifeless> are you on edge or lpnet
[05:25] <Laibsch> but I can use tsocks to get around that
[05:25] <lifeless> has it ever been faster for you in china before?
[05:25] <Laibsch> http://launchpad.net
[05:25] <Laibsch> that page will take several minutes
[05:26] <lifeless> that will do a redirect to https
[05:26] <lifeless> I just visited https://launchpad.net/ - it was a bit slow, it took 4 seconds.
[05:26] <lifeless> I'm in NZ
[05:26] <Laibsch> yes, usually it's been fairly responsive
[05:28] <Laibsch> how about https://bugs.edge.launchpad.net/ubuntu/+source/network-manager/+bug/411241 ?
[05:28] <ubot5> 'Error: Could not parse data returned by Launchpad: HTTP Error 401: Unauthorized\nResponse headers:\n---\ncontent-length: 21\ncontent-type: text/plain\ndate: Mon, 13 Sep 2010 04:28:10 GMT\nserver: zope.server.http (HTTP)\nstatus: 401\nvary: Accept-Encoding\nvia: 1.1 wildcard.edge.launchpad.net\nx-powered-by: Zope (www.zope.org), Python (www.python.org)\n---\nResponse body:\n---\nBug 411241 is private\n---\n (https://launchpad.net/bugs/411241)'
[05:28] <lifeless> 4 seconds
[05:28] <lifeless> NetworkManager crashed with SIGSEGV in strlen()
[05:28] <Laibsch> launchpad.net itself actually loaded up in about 10-15 seconds, so somewhat usable
[05:29] <Laibsch> Ok
[05:29] <lifeless> serverside that page took 'At least 126 queries/external actions issued in 2.40 seconds'
[05:29] <Laibsch> thank you for confirming
[05:29] <Laibsch> Chinese internet sucks
[05:29] <Laibsch> :-/
[05:29] <wgrant> LP is being unusually fast for me.
[05:29] <lifeless> wgrant: not unusual.
[05:30] <lifeless> you've just reminded me to check the dbr
[05:30] <lifeless> 30% reduction in DB load
[05:30] <lifeless> by doing the rollout
[05:30] <wgrant> Huh.
[05:30] <wgrant> That's handy.
[05:31] <wgrant> Are we back on the slaves?
[05:31] <wgrant> I recall we were not last night.
[05:31] <lifeless> we are yes
[05:32] <lifeless> wgrant: as we get more /efficient/ we'll gain speed on the backend because of less noddy queries
[05:32] <lifeless> wgrant: which will help everything.
[05:33] <wgrant> Yep.
[05:33] <lifeless> most of the stuff I've been doing and encouraging others to do is about efficiency.
[05:33] <lifeless> <- cunning planner
=== lag` is now known as lag
=== lag is now known as Guest58
[08:39] <hrw> hi
[08:40] <hrw> can someone help me with this? https://edge.launchpad.net/ubuntu/+source/armel-cross-toolchain-base/1.46/+build/1955387 - package got build but failed to upload and 'duplicated ancestry' says nothing to me
[08:40] <wgrant> hrw: That normally means that the source had its overrides changed just before the build finished.
[08:41] <hrw> wgrant: which means?
[08:41] <geser> wgrant: I don't see any promotion/demotion of that package in LP. It was the first and only upload
[08:41] <wgrant> That appears to not be the case here, however.
[08:42] <hrw> it is my first ubuntu uploaded package - previous version worked in ppa but many changes in between has made
[08:42] <wgrant> Indeed.
[08:42] <wgrant> So it's not the usual cause.
[08:42]  * wgrant digs.
[08:42] <lifeless> wgrant: file a bug, second time i've seen this
[08:42] <lifeless> first time I had no idea what was up, and was friday I think.
[08:42] <wgrant> There is already a bug for the other case.
[08:43] <wgrant> But not this one.
[08:43] <wgrant> That codepath is to be removed, fortunately, which will render the bugs obsolete.
[08:45] <wgrant> Oh.
[08:46] <wgrant> I think I see the problem.
[08:46] <wgrant> Yes.
[08:46] <wgrant> Remember how I told you last time that what you were doing was really bad?
[08:46] <wgrant> This time it's actually wrong too :P
[08:47] <wgrant>  Source: armel-toolchain-base (1.46)
[08:47] <wgrant> The source name is armel-cross-toolchain-base, not armel-toolchain-base.
[08:47] <wgrant> hrw: ^^
[08:47] <hrw> ok, thx
[08:47] <hrw> I missed that part
[08:47] <hrw> will fix and grab sponsor to upload next ver
[08:48] <wgrant> Why are you specifying that manually at all?
[08:49] <hrw> wgrant: my package uses gcc-4.5/eglibc/binutils/linux -source packages to build them for armel/cross with dpkg-buildpackage. so I have to dpkg-repack them to give proper Source: field value
[08:49] <wgrant> Ugh.
[08:52] <hrw> yeo
[08:53] <wgrant> What's so special about the armel cross-compiler that you can't do what other archs do?
[08:53] <wgrant> eg. like binutils-h8300-hms
[08:54] <wgrant> It's ugly, sure. But it doesn't require much evil.
[08:55] <hrw> binutils is not a problem
[08:56] <hrw> but gcc cross is as it needs eglibc-cross which needs gcc-cross
[08:56] <hrw> so I do full bootstrap of cross compiler in armel-cross-toolchain-base+armel-cross-toolchain packages
[08:57] <wgrant> I wonder how gcc-h8300-hms works, then...
[08:57]  * wgrant looks.
=== gord_ is now known as gord
[09:02] <fta> (4th try) please kill https://edge.launchpad.net/~chromium-daily/+archive/ppa/+build/1952454
=== mthaddon` is now known as mthaddon
=== LinuxJedi|away is now known as LinuxJedi
[09:05] <wgrant> lamont: ^^
[09:07] <danilos> jtv, henninge: hello, no internet again here
[09:08] <jtv> danilos: where is here?
[09:08] <jtv> and how are you talking to us?
[09:32] <Fauli> Hi
[09:32] <Fauli> I am the "owner" of the project page of Gentoo Linux in Launchpad.
[09:34] <Fauli> I disabled bug managment, but I get a mail for every bug in Launchpad that is linked to bug in the Gentoo bug tracker.  Now I enabled it and I can see all the bugs, but the supervisor and security contact fields are empty.  How can I get rid of all those notifications?
[09:36] <wgrant> Fauli: When you set a bug supervisor, they are by default notified of bugs, but can unsubscribe. When there's no bug supervisor set, the owner is notified, and cannot unsubscribe.
[09:37] <wgrant> Fauli: So you can set the bug supervisor to yourself, then unsubscribe at https://launchpad.net/gentoo/+subscribe
[09:37] <wgrant> This is a bit strange, but it should work.
[09:37] <Fauli> wgrant: Thanks, but even if bug tracking is disabled?
[09:38] <wgrant> I believe that just affects whether new bugs can be filed.
[09:38] <wgrant> At the moment, at least.
[09:40] <Fauli> wgrant: Thanks.
[09:47] <wgrant> Fauli: Bug #636918
[09:47] <ubot5> Launchpad bug 636918 in Launchpad Bugs "Owner can't unsubscribe from project's bugs without setting bug supervisor (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/636918
[09:50] <glatzor> hello I broke my aptdaemon branches performing an upgrade. How can I fix this?
[09:50] <glatzor>   File "/usr/lib/python2.6/dist-packages/bzrlib/fetch.py", line 249, in generate_root_texts
[09:50] <glatzor>     graph = self.source_repo.get_known_graph_ancestry(revs)
[09:50] <glatzor> AttributeError: 'Inter1and2Helper' object has no attribute 'source_repo'
[09:50] <glatzor> this is why the upgrade failed
[09:51] <glatzor> Now I cannot branch from the launchpad repositories anymore: ~/Entwicklung/aptdaemon$ bzr branch lp:aptdaemon
[09:51] <glatzor> bzr: ERROR: The branch lp:aptdaemon has no revision None.
[09:52] <glatzor> using sftp to connect to the repository is possbile but I am not allowed to rename the backup.bzr to .bzr
[09:52] <spiv> glatzor: which version of bzr?
[09:52] <glatzor> 2.2.0
[09:53] <spiv> Hmm, this bug rings a bell.  Perhaps due to a plugin, or something?
[09:53] <glatzor> spiv,The upgrade failed using Debian Sid and on Ubuntu
[09:53] <spiv> Anyway, to upgrade a branch on Launchpad it's simplest to use the link on the branch's page on Launchpad
[09:53] <glatzor> spiv, I tried it from a nearly fresh installed Ubutnu
[09:53] <spiv> Then Launchpad does all the work for you :)
[09:54] <spiv> I guess it's a bzr bug then, please file a report :(
[09:54] <glatzor> spiv, what about my branches?
[09:54] <glatzor> spiv, should I remove them and re-upload?
[09:54] <spiv> as far as restoring your branch, you should be able to rename the .bzr to something else (broken.bzr perhaps?) then rename backup.bzr to .bzr
[09:55] <glatzor> spiv, no I get a permissiondenied
[09:55] <glatzor> I tried sftp and hitchiker
[09:55] <spiv> (I forget exactly what the file naming restrictions were, but I thought maybe they got relaxed)
[09:55] <spiv> Ah,
[09:55] <spiv> Ok, try renaming to .bzr to .backup.bzr
[09:55] <wgrant> I think backup.bzr.~1~ should work.
[09:55]  * wgrant checks.
[09:55] <spiv> Which is definitely an allowed name (for older bzrs)
[09:55] <spiv> Or wgrant's suggestion
[09:55] <wgrant> .bzr.backup will work too.
[09:56] <glatzor> wgrant, spiv .bzr.backup.~1~is already the name of the backup from before upgrading
[09:56] <spiv> Well, .bzr.backup.~2~ then ;)
[09:59] <doko_> so what is this about lp not closing bug reports anymore on uploads?
[09:59] <wgrant> doko_: A case-sensitivity bug.
[09:59] <wgrant> jelmer: ^^
[10:02] <glatzor> wgrant, spiv: sftp> rename .bzr backup.bzr.~3~
[10:02] <glatzor> Couldn't rename file "/~aptdaemon-developers/aptdaemon/main/.bzr" to "/~aptdaemon-developers/aptdaemon/main/backup.bzr.~3~": Permission denied
[10:02] <wgrant> glatzor: Ahem. ~1~ and ~2~ are hardcoded; ~3~ and up will not work.
[10:04] <spiv> wgrant: !
[10:04] <glatzor> wgrant, and how to delete recursivly?
[10:04] <spiv> glatzor: lftp is an sftp client that can do that, so is nautilus
[10:04]  * spiv -> afk
[10:04] <wgrant> lftp is pretty nice.
[10:05] <spiv> glatzor: the other trick is to move it into directory under .bzr (or under backup.bzr...)
[10:07] <doko_> wgrant, jelmer: will the uploads after this bug be post-processed? not so nice tracking bugs targeted for the release ...
[10:08] <wgrant> doko_: It's fixed in trunk, not sure how the cherrypick is going.
[10:08] <wgrant> Reprocessing them is hard, but I don't know if there any plans there.
[10:08] <wgrant> bigjools: ^^?
[10:09] <doko_> wgrant: when was this introduced?
[10:09] <jelmer> doko_, wgrant: We're on our daily call, sorry for the slow response.
[10:09] <wgrant> doko_: The release last Thursday.
[10:09] <jelmer> doko_: The bug was introduced with the last Launchpad rollout.
[10:09] <glatzor> spiv, who long does an upgrade take if performed by Launchpad?
[10:10] <bigjools> doko_: it's best if you close them yourself for now
[10:17] <glatzor> spiv, thanks. I managed to repair it and filled a bug against bzr.
=== LinuxJedi is now known as LinuxJedi|away
=== bpeel_away is now known as bpeel
[11:36] <spiv> glatzor: thanks for filing the bug!
=== doko_ is now known as doko
[12:10] <lamont> wgrant: smacked
[12:10] <wgrant> lamont: Thanks.
=== mrevell is now known as mrevell-lunch
[12:50] <randomusername> hi there
[12:50] <randomusername> can someone provide me the current status of launchpad login case #00012729?
[12:58] <maxb> randomusername: Hi. The relevant people who can help are most likely to be found on #canonical-isd (that's for login stuff only)
=== Meths_ is now known as Meths
[13:00] <randomusername> maxb: thanks maxb
[13:00] <randomusername> I'll goto that channel then
=== mrevell-lunch is now known as mrevell
=== oubiwann is now known as oubiwann-away
=== oubiwann-away is now known as oubiwann
=== LinuxJedi|away is now known as LinuxJedi
=== Ursinha-afk is now known as Ursinha
[15:05] <Ddorda> hey guys, how do i connect my user in launchpad?
[15:05] <Ddorda> for some reason i can login only d-dorda and not ddorda
=== mbarnett` is now known as mbarnett
[15:07] <maxb> So, you have login problems on one account, but not the other, and would like to merge them?
[15:08] <maxb> My suggestion is that you may want to not do that, and try to get someone to figure out what's currently broken with your ~ddorda account before you merge anything
[15:24] <jelmer> maxb: Thanks for handling those KDE imports
[15:25] <maxb> hi
[15:25] <jelmer> maxb: That locking issue is getting a bit annoying :-/
[15:25] <maxb> we really need a solution to "determining revprop revisions" running for > 24 hours
[15:25] <maxb> One of them spend 31 hours figuring out what to fetch, then one hour fetching 5000 revisions of it
[15:27] <maxb> https://code.edge.launchpad.net/~neon/kdepim/trunk is going to be running for another week, I reckon :-/
[15:27] <maxb> based on it needing 9 batches of 5000 to complete
[15:30] <jelmer> I'm quite surprised that step is necessary actually
[15:30] <jelmer> don't the KDE server and Launchpad  both run svn >= 1.5 ?
[15:34] <maxb> Depends.... has Lucid arrived in the datacentre?
[15:36] <maxb> Hmm, I'm no longer seeing the "WARNING Upgrade to Subversion 1.5 or later..." in the import logs, so maybe. Regardless, it's still doing "discovering revprop revisions", though
=== Lcawte|Away is now known as Lcawte
=== LinuxJedi is now known as LinuxJedi|brb
[16:04] <SEJeff_work> Is it on the roadmap to do inter lp sync?
[16:05] <SEJeff_work> ie: If I'd like to setup a lp instance for some project, but have some federation or at least a way to sync bugs between them?
=== LinuxJedi|brb is now known as LinuxJedi
[16:35] <maxb> SEJeff_work: I'm fairly certain the answer is no.
[16:35] <SEJeff_work> I'd like to setup a gnome lp instance
[16:35] <SEJeff_work> To play with
[16:35] <SEJeff_work> But last time I asked about it, I was discouraged
[16:35] <SEJeff_work> Is that still the case?
[16:35] <maxb> That's still the official line, yes
[16:36] <SEJeff_work> So when is that going to change so lp can be a real oss project?
[16:36] <SEJeff_work> Is that even a year out on the roadmap?
[16:36] <maxb> Never?
[16:37] <SEJeff_work> I mean what is even the point of being open source if you discourage people from using it?
[16:38] <maxb> I've not heard any indication that Canonical wants to do things differently - they seem quite firmly behind launchpad-the-service, not launchpad-the-software
[16:38] <SEJeff_work> This isn't intended to flame. I'd really like to setup lp for gnome to see what it would work like
[16:38] <beuno> SEJeff_work, I think the main point is for people to be able to contribute to launchpad.net, fix bugs, audit security, etc
[16:38] <beuno> SEJeff_work, you could bring it up in the -dev mailing list  :)
[16:38] <maxb> Actually, I can't see how it would be advantageous to have a separate gnome lp
[16:38] <SEJeff_work> It almost seems like a charade
[16:38] <jelmer> maxb: perhaps the cache still has the revisions without the revision properties from when we were running svn 1.4
[16:38] <maxb> It would seem to be needlessly divisive
[16:38] <jelmer> maxb: After the first run they should be filled in then though
[16:38] <SEJeff_work> maxb, Easy, not depending on canonical/ubuntu specific things
[16:39] <SEJeff_work> I'd like to make git a first class citizen in lp. Right now it is not
[16:40] <SEJeff_work> Since the concepts of one dvcs to another transfer over fairly well (except bzr is easier to use than git) there is no reason it couldn't better support git. I'd like to do that for lp to work better for an env that doesn't use bzr much
[16:40] <maxb> jelmer: hmm. possibly. Though, it still seems impressively slow even after quite a few attempts (at least one per importd host, I'd guess)
[16:40] <SEJeff_work> And because as an integrated solution, lp is the best project management software out there so kudos to the team!
[16:41] <jelmer> maxb: Yeah, I guess we're retrieving the revision properties manually each time but then not storing them in the cache for some reason.
[16:41] <SEJeff_work> maxb, Well gnome and canonical don't always want the exact same things. If both had lp, both could benefit
[16:45] <maxb> SEJeff_work: Well, partly. However, it would be difficult to make work. Some launchpad features are predicated on the fact that there is only one instance. Some are Ubuntu-specific. Some integrate with Canonical infrastructure. I can't see it working without a forked codebase, and I fear that such a codebase could be sustained.
[16:45] <Ddorda> can anyone check what's the reason i can;t lgin ddorda?
[16:46] <Ddorda> oh. nvrm
[16:46] <SEJeff_work> maxb, Thats perfectly understandable. However, my point was that we don't need those canonical specific features (soyuz or rosetta likely). It would be really nice to have an instance that we could setup for the things lp is really good at (bug tracking, blueprints, mailinglists, etc).
[16:46] <maxb> Ddorda: It sounds like some bug that's also affecting a few others.
[16:46] <Ddorda> maxb: the problem is that i'm logged in in onother browser
[16:46] <SEJeff_work> maxb, I guess I had the wrong idea when I thought lp was open source. It is only open source by definition, not by nature.
[16:48] <maxb> SEJeff_work: The code is open. But, the code is not written to be friendly to run yourself in production, and the image licence is an additional barrier to entry.
[16:48] <SEJeff_work> It is clear that you (and canonical) don't work well with others
[16:48] <SEJeff_work> I was just hoping that misnomer was incorrect
[16:49] <maxb> This is sad, because a decent Bazaar branch management webapp is something that Bazaar could really use, to enhance its corporate applicability
[16:49] <SEJeff_work> maxb, Agreed
[16:49] <beuno> SEJeff_work, that is an unfair statement that broad. This only applies to launchpad.
[16:49] <SEJeff_work> maxb, I'd love to use lp's branch management features for gnome git
[16:49] <SEJeff_work> It rocks
[16:50] <maxb> Once you get past the major pains of the image licence and the secrecy of production deployment information, I think you'll then have to struggle with the UI mismatch between bzr and git's branching concepts
[16:50] <SEJeff_work> beuno, Well a few people have already mentioned people that don't work well with upstream. I was trying to ignore all of the crap about that.
[16:50] <SEJeff_work> maxb, Sure, my point was that it could be extended
[16:50] <SEJeff_work> And both could potentially benefit
[16:50] <SEJeff_work> Which makes both rock more
[16:51] <SEJeff_work> who's to say that lp couldn't become equally as awesome for hosted git repos as github is?
[16:51] <SEJeff_work> It certainly has the potential
[16:51] <beuno> SEJeff_work, I'm sure that is true in all projects. We also have many more examples of the opposite. Please don't tie your frustrations with Launchpad's goals with rumors and FUD  :)
[16:52] <SEJeff_work> beuno, Sadly, those numbers aren't rumors. FUD certainly, but they are factually grounded
[16:52] <SEJeff_work> It just saddens me to realize that I can't setup lp for gnome
[16:52] <SEJeff_work> Because you discourage it
[16:52] <maxb> Well, I somewhat see Canonical's point on not being interested in Git. They'd have to commit a large amount of resource to hosting such a feature, or even just to review code changes that they didn't intend to use on lpnet.
[16:53] <beuno> yes, because then we get a billion bugzilla's, and we haven't improved collaboration across open source
[16:53] <SEJeff_work> beuno, Well to be fair, lp beat the crap out of gnome's bugzilla
[16:53] <maxb> Launchpad's bugtracker is a great example of a service which is awesome because there is exactly one of them.
[16:54] <SEJeff_work> I remember adding the iptables drop to gnome's bugzilla when lp.net was doing 5G xmlrpc requests to it and killing apache
[16:55] <SEJeff_work> bugzilla is legacy crufy software
[16:55] <SEJeff_work> For what it is, lp is pretty good
[16:56] <SEJeff_work> maxb, But why would you guys care if I wanted a good bugtracker for $insert_project and wanted to use your already awesome software for that?
[16:56]  * maxb would like to clarify that he's not a Canonical employee
[16:56] <SEJeff_work> note taken
[16:57] <SEJeff_work> Bugzilla is bad to compare directly against lp because it is legacy and less featureful
[16:57] <maxb> I do, however, see what I assume to be Canonical's viewpoint, which is that they don't want to spend time turning Malone into a packaged bugtracker, when their true interests lie in making an awesome software collaboration website.
[16:58] <SEJeff_work> maxb, Thats fair, but at the same time, not everyone wants to host everything on stuff they don't control
[16:58] <SEJeff_work> I could almost see a business model (for canonical) in lp appliances for enterprises
[16:58] <SEJeff_work> It certainly beats Jira
=== matsubara is now known as matsubara-lunch
[16:58] <maxb> Oh, totally. I think several hours / month of Bazaar downtime it pretty poor, really
[16:59] <maxb> I certainly wouldn't recommend my company to keep code on Launchpad.
[16:59] <SEJeff_work> Exactly
[17:00] <SEJeff_work> And I wouldn't recommend that gnome host all of their code on lp unless we ran an instance ourself. I speak for myself only, but do manage the gnome servers
[17:00] <SEJeff_work> *ourselves
[17:01] <deryck> SEJeff_work, hi.  there's a lot of discussion here, but to be clear we don't discourage you from setting up your own instance of lp, not directly.  It's true our goals are to improve lp.net itself, but you're free to do what you wish with the code.
[17:01] <SEJeff_work> maxb, I've never seen an open source project where someone says, "Hey, your software rocks! I'd like to use it to do xys", and is told basically to go away.
[17:01] <SEJeff_work> deryck, At the same time, if the changes weren't blessed enough to eventually be merged, it would amount to a complete fork
[17:01] <SEJeff_work> which is a waste of everyone's time
[17:02] <deryck> SEJeff_work, true.  But that's any free software project's problem.  Nothing unique to our hosting of Launchpad there.
=== dendrobates is now known as dendro-afk
[17:02] <maxb> deryck: I think it's playing on technicalities to claim that Canonical doesn't discourage it, given the image licence, and the usual responses on launchpad-dev@ when someone brings up the idea of a separate instance
[17:03] <SEJeff_work> maxb, I asked months ago and just now the question vaguely along the lines of, "Can I setup an instance of lp for gnome.org". The response was basically, "no".
[17:04] <deryck> maxb, maybe that is the impression, but in terms of Launchpad being a legitimate open source project that prevents a user to use the code freely, I think we are legitimately free software.
[17:04] <SEJeff_work> Again, that is a technicality
[17:04] <SEJeff_work> Free to the letter, not the spirit completely
=== bjf[afk] is now known as bjf
[17:04] <SEJeff_work> I'd like to enhance your software
[17:04] <SEJeff_work> You say politely go away
[17:05] <deryck> SEJeff_work, I don't know of anyone who said this.  If they did, then on behalf of the Launchpad project, I appologize.  We welcome and will consider any patch.
=== salgado is now known as salgado-afk
[17:06] <SEJeff_work> deryck, Thanks
[17:06] <deryck> SEJeff_work, at the same time, you have to agree that any project is free to accept or reject any proposed patch, no?
[17:06] <SEJeff_work> Of course
[17:06] <SEJeff_work> deryck, Again, I think lp is better software than bugzilla
[17:07] <SEJeff_work> And would love the idea of playing with it in place of bugzilla for gnome and see if I'd survive the resulting flamewar
[17:07] <SEJeff_work> But if the lp project officially discourages that idea it seems stillborn to try
[17:08] <deryck> I don't think we as a project are doing anything to prevent you playing with that idea, are we?  Our goals as a project are clear that we don't want to be a bugzilla replacement.  We want to coordinate between trackers, but please play and have fun and let us know how it goes.
[17:08] <SEJeff_work> We already host some servers in one of the canonical servers
[17:08] <SEJeff_work> We could run it on Ubuntu :)
[17:08] <deryck> it runs well on Ubuntu ;)
[17:08] <maxb> deryck: I think people have in the past defended the remit of launchpad-dev@ as only applying to the launchpad.net instance, which may be part of the cause of these feelings.
[17:08] <SEJeff_work> heh, I bet
[17:09] <SEJeff_work> deryck, So say I spend 3 months making lp speak native git and do branching and everything else with just as much cowbell as it does with bzr
[17:09] <SEJeff_work> Then you say I hate your idea, we'll never accept it. That leaves me in a difficult situation
[17:09] <SEJeff_work> Because you've already pretty much said not interested go away
[17:10] <maxb> deryck: Also, whilst I agree it's completely within Canonical's rights, and I'm greatful that any of LP is open, it's hard to see the image licence as anything other than a deliberate discouragement against other instances.
[17:10] <SEJeff_work> Absolutely. LP is a great service to all of the community. The fact big open source projects such as mysql use it is a testament to that fact.
[17:10] <maxb> SEJeff_work: In fairness, all of the Launchpad developer docs are quite emphatic about the idea of talking about features before you implement them
[17:11] <SEJeff_work> which is what I'm trying to do now
[17:11] <SEJeff_work> switching to bzr won't happen for gnome
=== Lcawte is now known as Lcawte|Away
[17:11] <SEJeff_work> so why not make lp fit git better? If we did the work and made it up to snuff, whats the problem?
[17:11] <deryck> maxb, I don't see this as blocking you running it locally, but if you do, it has to be clear it's not really launchpad.net.  How is that denying software freedoms?
[17:12] <SEJeff_work> maxb, Also, lp.net is a brand as much as Ubuntu. They just want to protect their brand
[17:12] <SEJeff_work> Which makes sense
[17:12] <deryck> We may not be able to agree on all this, and I need to run to a call, but I want to be clear that we welcome any discussion and any contribution.
[17:12] <SEJeff_work> deryck, Alright. Thanks for your time
[17:12] <maxb> deryck: It's an effective deterrent to casual experimentation - you have to commit yourself to a rebranding project before you can consider doing anything
=== dendro-afk is now known as dendrobates
[17:13] <deryck> maxb, sure.  But it's a compete website after make run.  Other sites don't do that, do they? ;)
[17:13] <deryck> Even if they are quite heavy into OSS contributions.
=== zyga is now known as zyga-dinner
[17:13] <deryck> Anyway, I have a call.  Thanks for the discussion with me.
=== beuno is now known as beuno-lunch
=== Ursinha is now known as Ursinha-lunch
=== deryck is now known as deryck[lunch]
=== LinuxJedi is now known as LinuxJedi|dinner
=== Lcawte|Away is now known as Lcawte
=== LinuxJedi|dinner is now known as LinuxJedi
=== Ursinha-lunch is now known as Ursinha
=== matsubara-lunch is now known as matsubara
=== doko_ is now known as doko
=== beuno-lunch is now known as beuno
=== zyga-dinner is now known as zyga
=== deryck[lunch] is now known as deryck
=== Philip6 is now known as Philip5
=== bpeel is now known as bpeel_away
=== Ursinha is now known as Ursinha-brb
=== lool- is now known as lool-webchat
=== matsubara is now known as matsubara-afk
[22:48] <Laney> is auto bug closing still broken?
=== bpeel_away is now known as bpeel
=== bpeel is now known as bpeel_away
[23:29] <thumper> Laney: auto bug closing due to what?
[23:29] <Laney> uploads
[23:29] <thumper> Laney: I'd ask one of wgrant, bigjools, StevenK, or noodles
[23:29] <thumper> Laney: some of whom aren't on right now
[23:30] <Laney> I guess you just did that for me. Wasn't too concerned to ping loads of people — could have just dug up the bug
[23:31] <wgrant> Laney: It's still broken, yes.
[23:31] <wgrant> Fixed in trunk, but I don't know when it will be out on production.
[23:31] <Laney> thanks
=== LinuxJedi is now known as LinuxJedi|away