[00:14] <yofel> worth a try indeed, lets see what happens
[00:31] <yofel> kde4libs - 4:4.10.90+git20130709-0~519~saucy1
[00:31] <yofel> yay
[00:32] <yofel> apachelogger: I'll leave designing a sane version number to you https://code.launchpad.net/~kubuntu-members/+recipe/kubuntu-kdelibs-stable
[00:40] <ScottK> yofel: What's the -0~519?
[00:41] <yofel> -0~{revno:packaging}
[00:42] <ScottK> For the stable builds, can we do release number instead of name?
[00:42] <yofel> no, ~<release>1 is appende by launchpad
[00:43] <yofel> I filed a bug for that like half a year ago
[00:43] <yofel> it's 'Low'
[00:43] <ScottK> OK.
[00:43] <ScottK> Low means send patches or wait for the heat death of the Universe.
[00:43] <yofel> well, in this case patches or until we actually reach u-series
[00:44] <yofel> not too far away
[01:16]  * yofel is off to bed - good night
[01:19] <smartboyhw> Good night yofel
[02:10] <ScottK> Quintasan: Re the firefox-en thing, installing kubuntu-desktop in a clean chroot doesn't pull it in, so likely the language thing.
[02:59] <ahoneybun> hey manchicken
[02:59] <manchicken> ahoneybun: Hiya
[02:59] <ahoneybun> did you get to test moindump?
[03:00] <manchicken> ahoneybun: Sorry, for some silly reason I thought you were doing that :)
[03:00] <manchicken> I'll try now
[03:01] <ahoneybun> reason I don't is I was confused with the thing
[03:01] <ahoneybun> sorry :)
[03:02] <manchicken> No worries :)
[03:04] <ahoneybun> yea I was just wondering
[03:05] <ahoneybun> if Ubuntu is moving to qml and Qt what does that mean for all the GtK/GNOME apps?
[03:06] <manchicken> I can't do this, I think it has to be done from the machine on which MoinMoin is installed.
[03:06] <manchicken> ahoneybun: I've heard a lot of people ask that question.
[03:07] <ahoneybun> I think that it will just be like how qt covers over gtk apps in KDE
[03:07] <manchicken> Yeah
[03:07] <manchicken> It'll finally be a reciprocal arrangement.
[03:07] <manchicken> Could result in *shock!* standards.
[03:08] <manchicken> Or at least conventions.
[03:11] <ahoneybun> that is one of the reasons I did not like Ubuntu Unity, no standards mix of GTK, Qt, and Nix?
[05:20] <shrini> hello all
[05:53] <ScottK> Riddell: Released the qt4-x11 revert to raring-updates.
[06:10] <soee> good morning
[06:11] <smartboyhw> soee, hey. Again, how's 4.10.5 in raring?
[06:11] <smartboyhw> ScottK, ^
[06:11] <soee> smartboyhw, smooth :)
[06:11] <ScottK> Quintasan or yofel have been working on that.
[06:11] <smartboyhw> ScottK, ooh
[06:12] <soee> smartboyhw, do you have expirience with multiple distros on one PC ?
[06:12] <ScottK> I'll approve it once it's uploaded.
[06:12] <smartboyhw> soee, no.
[07:16] <apachelogger> yofel, ScottK: 4:$UPSTREAM+git$DATE+bzr$REV~$SERIES$PACKAGINGREV I'd say
[08:24] <yofel> apachelogger: ~$SERIES$PACKAGINGREV isn't doable though (even if I very much like the idea)
[08:26] <yofel> apachelogger: +pkg{rev} or +kubuntu{rev} ?
[08:26] <apachelogger> why is it not doable?
[08:27] <yofel> there is no template for SERIES
[08:27] <yofel> the ~foo1 part isn't editable
[08:27] <apachelogger> oh
[08:27] <apachelogger> so it is always 1?
[08:27] <yofel> yes
[08:27] <apachelogger> quite the letdown
[08:28] <apachelogger> yofel: ~pkg{rev}+series1 then
[08:28] <apachelogger> or is that always ~series1?
[08:28] <yofel> ~series1
[08:28]  * apachelogger should get more coffee before talking about weird launchpad stuff
[08:28] <yofel> or +r{revno}+bzr{pkgrev} ?
[08:29] <apachelogger> IMO using bzr for the bzr import identifier of the source makes more sense
[08:29] <apachelogger> wellll
[08:29] <yofel> er, really o.O?
[08:30] <yofel> well, ok
[08:30] <yofel> from a certain POV, yes it does
[08:30] <apachelogger> if you tell me that version as upstream I will at least be able to deduce that bzr was involved :P
[08:31] <apachelogger> 4:$UPSTREAM+git$DATE+bzr$REV+pkg$PKGREV~SERIES
[08:31] <yofel> ack
[08:31] <apachelogger> new upstream will trigger upgrade, new day will trigger upgrade, new import will trigger upgrade, new packaging will trigger update
[08:32] <apachelogger> should be all fine
[08:32] <apachelogger> exceedingling long but sufficient layers of version sizing ^^
[08:34] <yofel> # bzr-builder format 0.3 deb-version 4:{debupstream}+git{date}+bzr{revno}+pkg{revno:packaging}
[08:34] <apachelogger>   Could NOT find JPEG (missing: JPEG_LIBRARY JPEG_INCLUDE_DIR)
[08:34] <apachelogger> awww
[08:34] <apachelogger> yofel: looks good
[08:34] <yofel> neeext
[08:35] <yofel> where to put the imports? (here I could actually be convinced that projects would be the sensible way  to go)
[08:36] <apachelogger> same as with neon, roll a dice :P
[08:36] <apachelogger> either many projects ~kubuntu-packager/kde-workspace/master (allowing for more than one branch to be imported)
[08:37] <apachelogger> or one project with many branches ~kubuntu-packager/kde-git-imports/kde-workspace (forcing other branches of the same repo to have some suffix or something e.g. kde-workspace.master and kde-workspace.framework-scratch)
[08:38] <yofel> then I would rather do the projects thing. And maybe me and shadeslayer_ can clean up neon next week if there's spare time
[08:38] <apachelogger> right
[08:38] <apachelogger> oh
[08:39] <apachelogger> there is one case that could be made for a single project
[08:39] <apachelogger> you can easily iterate everything
[08:39] <apachelogger> iff all imports are there
[08:39] <apachelogger> which is probably hard to get done seeing as a lot of stuff is imported all over the place on lunchpad
[08:39] <yofel> right
[08:39] <yofel> (latter I mean)
[08:40] <smartboyhw> yofel, how's 4.10.5 -> raring-proposed? ScottK said you or Quintasan are doing the work:)
[08:41] <apachelogger> -- The following REQUIRED packages have not been found:
[08:41] <apachelogger> -.-
[08:41] <apachelogger> and of course it's a qt library :@
[08:41] <yofel> smartboyhw: not done, somtime today
[08:41] <smartboyhw> :@@@@@@@@@@@@@@@@@@@@@@@
[08:41] <markey> apachelogger: should I check for OpenGL or QtOpenGL?
[08:42] <apachelogger> markey: that depends on whether you do native paintaing using opengl ... at the very least you'll need qtopengl though
[08:42] <markey> apachelogger: well I reckon QtOpenGL depends on OpenGL
[08:42] <markey> so that should suffice?
[08:42] <apachelogger> markey: qtopengl can also use GLES
[08:43] <markey> I think we're compatible with ES
[08:43] <apachelogger> markey: do you have beginNativePainting in your code somewhere?
[08:43] <markey> nope
[08:43] <apachelogger> then it doesn't matter anyway most likely
[08:43] <apachelogger> simply check for qtopengl
[08:43] <markey> ok
[08:43] <apachelogger> (either that or you are not telling Qt that you are about to do native gl painting :P)
[08:46] <apachelogger> hm
[08:46] <apachelogger> yofel: you don't have qimageblitz in neon?
[08:46] <yofel> we do, that's *still* in kdesupport
[08:47] <yofel> you need that for the oxygen-icons anyway
[08:47] <apachelogger> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaah
[08:47] <apachelogger> dunno why cmake talks about sourceforge then -.-
[08:48] <apachelogger> 844.1 MiB (41.22%) of 2.0 GiB
[08:48] <apachelogger> I am reasonable certain oxygen will eat all of that :O
[08:49] <yofel> no, that's like 250M source + some 30M binary
[08:50] <apachelogger> we'll see :P
[08:52]  * apachelogger is in a very vim mood
[08:52] <yofel> considering we've got the namespacing worked out you can just move it to the main ppa if you run out of space
[08:55] <apachelogger> we'll see
[08:56] <apachelogger> or just request a size bump :O
[09:48] <smartboyhw> ScottK, any time to approve an SRU for me?
[09:49] <ScottK> Not now.  Need to get ready to leave for a $work meeting.
[09:49] <smartboyhw> ScottK, :(
[10:14] <afiestas_> ScottK: thanks for your email with some "let's do it" feedback
[10:14] <afiestas_> made my morning :)
[10:29] <ScottK> I think it was a bit less enthusiastic than that.
[10:29] <ScottK> I think it was more of "we could live with it".
[10:31] <smartboyhw> ScottK, finished $work meeting already? That quick?
[10:31] <markey> this QtScript crash bug was fixed in Qt 4.8.3, IIRC?
[10:31] <ScottK> No, still getting ready to go.
[10:31] <smartboyhw> ScottK, that's long:P
[10:32] <smartboyhw> ScottK, just to tell you: The bugs are Bug 1189083 and Bug 1189085. The patch (same) is attached to the two bugs
[10:34] <smartboyhw> It's rather simple to review actually:P
[10:43] <yofel> TBH, some of the dependency update information for a new KDE SC release could be extracted from project-neon, as that was already updated there before beta1 is even tagged
[10:43] <yofel> except stuff that has daily builds there as well. E.g. SDO or akonadi
[11:31] <yofel>  kde4libs - 4:4.10.90+git20130709+bzr92221+pkg519~saucy1
[11:31] <yofel> looks reasonable
[11:35] <shadeslayer_> whats that
[11:36] <yofel> shadeslayer_: https://code.launchpad.net/~kubuntu-members/+recipe/kubuntu-kdelibs-stable
[11:37] <shadeslayer_> and that's being done why?
[11:37] <shadeslayer_> did anyone test 4.10.90 for quantal apart from me? should I move it?
 I'm thinking if we did that, maybe we could send a point release straight to proposed since we'd have tested it already.
 So it would ~replace the updates PPA.
[11:38] <yofel> wrt. stable daily builds
[11:39] <shadeslayer_> I see
[11:50] <yofel> I just added https://trello.com/c/gj9wpF5W for that, still incomplete I think
[11:52] <apachelogger> yofel: do you have a neon policy on strict linking requirements?
[11:53] <apachelogger> e.g. linking against qtgui/qtcore requires libgl to be present, so anything builddeping qt needs to builddep libgl
[11:54] <apachelogger> I was thinking about a pseudo dev package... qt5-dev { depends: qt5, libgl1; files: null }
[11:54] <shadeslayer_> doubt it
[11:54] <shadeslayer_> Packaging for Neon 4 is very minimal
[11:54] <shadeslayer_> so unless shlibs:Depends or misc:Depends automagically add that, no
[11:55] <yofel> apachelogger: there is project-neon-kdelibs-dev for that
[11:55] <apachelogger> ah
[11:55] <yofel> not sure what that wasn't qt
[11:55] <BluesKaj> Hi all
[11:55] <yofel> *why
[11:55] <apachelogger> well, in qt5 we need that for qt as well
[11:56] <yofel> then just move it there and make project-neon5-kdelibs-dev depend on it (or junk it)
[11:56] <apachelogger> yah
[11:56] <yofel> apachelogger: and no, there's no strict linking policy in neon (we use the defaults mostly)
[11:57] <yofel> if anything there might be a place or two where rpath is forced
[11:59]  * apachelogger meows
[11:59] <apachelogger> shadeslayer_: did you actually look into the zic thing?
[11:59] <shadeslayer_> apachelogger: nope, I did not commit to doing that
[11:59] <apachelogger> good
[12:00] <apachelogger> because I removed it from my todo after asking you
[12:00]  * apachelogger sighs
[12:00] <shadeslayer_> -.-
[12:02] <apachelogger> taring the kdesupport takes forever
[12:02]  * apachelogger surely forgot a dep again
[12:02] <apachelogger> :S
[12:03] <yofel> can't you just fork what we have in neon4?
[12:04] <apachelogger> that's what I did I think
[12:04] <apachelogger> ECM is new though
[12:04] <yofel> ah
[12:04] <yofel> true
[12:19] <apachelogger> Riddell: bug 500936 :P
[12:22] <Riddell> apachelogger: we like to keep our users on their toes :)
[12:22] <apachelogger> I see :P
[13:25] <apachelogger> support should be building now, going to attempt workspace again tomorrow
[13:37] <apachelogger> yofel, shadeslayer_: did anyone actually subscribe kubuntu-bugs to the new packages btw?
[13:41] <apachelogger> kubotu: hi
[13:41] <kubotu> 'afternoon apachelogger
[13:41] <apachelogger> yofel: kubotu's back
[13:41] <apachelogger> -> dinner
[14:16] <smartboyhw> kubotu: help
[14:16] <kubotu> help topics: 10 core modules: auth, basics, config, filters, httputil, irclog, remote, unicode, userdata, wordlist; 57 plugins: alias, autoop, autorejoin, bans, bar, botsnack, chanserv, debug, dns, eightball, excuse, factoids, googlefight, greed, greet, hangman, host, identica, insult, iplookup, karma, keywords, lart, map, markov, modes, newpackage, nickrecover, nickserv, note, poll, q, quote, reaction, remind, ri, roshambo,
[14:16] <kubotu> rot, rss, salut, script, search, sed, seen, shiritori, spotify, time, topic, translator, tumblr, twitter, uno, urban, usermodes, wheeloffortune, wserver, youtube; 32 plugins ignored: use help ignored plugins to see why; 1 plugin failed to load: use help failed plugins to see why (help <topic> for more info)
[14:16] <smartboyhw> Yes!
[14:16] <smartboyhw> :P
[14:39] <agateau> Riddell: I think I fixed the icon issue in Ubiquity. Can't find a bug report for it. Do you know if there is one?
[14:39] <Riddell> agateau: no I don't think there is
[14:40] <agateau> Riddell: ok. Committing and filing merge request then
[14:58] <smartboyhw> ScottK, can you try to approve my SRUs a.s.a.p so I can test it tmr morning?
[14:58] <smartboyhw> It's Bug 1189083 and Bug 1189085.
[14:58] <smartboyhw> I'm leaving for London soon
[14:58] <smartboyhw> So...
[15:44] <yofel> apachelogger: at least not me, will look in a bit
[17:12] <Peace-> mm http://paste.ubuntu.com/5858978
[17:14] <Peace-> that was a comment on my blog
[17:14] <Peace-> :S
[17:14] <yofel> :/
[17:14] <Peace-> ah seen the paste :D
[17:15] <Peace-> it's not readable
[17:15] <yofel> rekonq at its best -.-
[17:16] <Peace-> http://pastebin.com/hbZd15z1
[17:17] <Peace-> well i personally did not get the point of this   Installing a second browser as you say is no option in my case.


[01:48] <duflu> racarr: Can you please comment on (or fix!) bug 1260612? :)
[01:48] <duflu> Hmm, or is that for the nesting guys?
[09:41] <anpok> duflu: ping
[09:42] <duflu> anpok: pong
[09:46] <anpok> duflu: i tried to answer you comment on the mp
[09:47] <duflu> anpok: I saw. But officially have no more opinions till Monday :)
[09:47] <anpok> hehe
[09:47] <anpok> you already EOD?
[09:58] <duflu> anpok: Almost EOD
[09:58] <duflu> EOW
[09:58] <anpok> :)
[09:59] <anpok> as in end of world of course
[09:59] <duflu> ZOMG, no one told me
[15:03] <racarr> Morninng
[16:02] <kdub> good morning
[16:08] <racarr> Morningkdub
[18:48] <kdub> do platform-api and unity-mir need mir package version bumps?
[18:55] <kdub> why did we flatten out the pixel format types :(
[20:55] <kdub> mterry, so it looks like that fix for nested you're interested in has gone into lp:mir
[20:55] <kdub> but what is in lp:mir has not hit the images yet
[20:55] <mterry> kdub, ooh, good news. Thanks!


[01:09]  * thumper twiddles his thumbs while the tests run
[01:09] <spm> thumper: do you twiddle clockwise or anti? or switch from one t'other? enquiring minds wish to know.
[01:09] <thumper> spm: I alternate
[01:10] <thumper> like current, but not as fast
[01:10]  * spm looks for a report on the intrawebsfont-of-all-knowledge as to what that says about thumpers mental state of being
[01:10] <spm> sadly, reckon I could google for that and get a semi-credible answer.... :-)
[01:15] <thumper> spm: an answer yes, a semi-credible one? now that is a question all in itself
[01:15] <spm> ha
[01:25]  * mwhudson lunches
[01:56]  * thumper is having test failures with GpgmeError: (32, 176, 'Unknown error code')
[02:07] <wgrant> thumper: There is a patch needed for Lucid.
[02:08] <thumper> :(
[02:08] <wgrant> I think it's in trunk now.
[02:08] <wgrant> pygpgme trunk, that is.
[02:08] <thumper> is it in LP code somewhere?
[02:08] <thumper> I'm running the tests through ec2 now anyway
[02:09] <wgrant> mwhudson actually approved the sourcedeps.conf change a few days ago.
[02:09] <wgrant> It just hasn't been landed yet.
[02:10] <thumper> ok
[02:10] <thumper> I thought I had seen something about pygpgme fly past
[02:11] <mwhudson> bad jelmer
[03:06] <poolie> wgrant: re bug 549323, i did try to tell them so
[03:06] <mup> Bug #549323: Discourages bug fixes <Launchpad Bugs:New> <https://launchpad.net/bugs/549323>
[03:23]  * thumper has finally started writing the tests for iterReady
[03:30] <lifeless> wgrant: ugh, is this deliberate or a bug ?
[04:02] <thumper> mwhudson: happy with bug 532210?
[04:03] <mwhudson> thumper: yes
[04:03] <mwhudson> didn't i change the tag already?
[04:03] <mwhudson> no
[04:03] <thumper> not yet
[04:04] <mwhudson> ok
[04:04] <mwhudson> now i have :)
[04:04] <thumper> ta
[04:15] <thumper> mwhudson: do we have a reasonable branch to test https://bugs.edge.launchpad.net/launchpad-code/+bug/532402 on?
[04:15] <mup> Bug #532402: record last_revision used to determine partial success before doing import <code-import> <qa-needstesting> <trivial> <Launchpad Bazaar Integration:Fix Committed by mwhudson> <https://launchpad.net/bugs/532402>
[04:19] <mwhudson> thumper: not really
[04:20] <thumper> mwhudson: I suppose we should just test the imports on staging and see that they work still
[04:20] <mwhudson> thumper: i can think of some slightly contrived ways to test it by getting a losa to SIGSTOP the import processs
[04:20] <mwhudson> thumper: yeah
[04:20] <mwhudson> thumper: doing that already in fact :)
[04:20] <spm> if only there was a friendly losa around....
[04:20] <thumper> cool
[04:20] <thumper> spm: yeah, know any?
[04:20] <mwhudson> thumper:  https://code.staging.launchpad.net/~vcs-imports/gedit/head
[04:21] <spm> thumper: not on the key criteria no. losa's around? yup. friendly? no.
[04:21] <mwhudson> it's also a fiddle, the only public svn repo i can think of is codespeak, and bzr-svn tends to break on that
[04:21] <mwhudson> (thanks to svn bugs)
[04:29] <thumper> mwhudson: that subversion import is via cscvs, you knew that right?
[04:29]  * thumper afk for a bit
[04:36] <mwhudson> thumper: ah balls
[04:36] <mwhudson> thumper: thanks
[05:38]  * mwhudson stops
[06:56] <wgrant> lifeless: Is which deliberate?
[06:56] <wgrant> poolie: I decided not to. I've almost given up trying to convince people nicely.
[06:56] <lifeless> wgrant: bug 549323
[06:56] <mup> Bug #549323: confirmation dialog on bug status change discourages bug fixes <Launchpad Bugs:Confirmed> <https://launchpad.net/bugs/549323>
[06:56] <wgrant> lifeless: It's quite deliberate.
[06:56] <wgrant> If you're not a bug supervisor, you're not meant to change the status.
[06:57] <poolie> lifeless: read the other bug linked from it
[06:57] <poolie> wgrant :-(
[06:57] <lifeless> wgrant: if we're doing that, we should delete 'in progress'
[06:57] <poolie> ?
[06:58] <lifeless> poolie: so that there is no bug state that contributors who aren't bug supervisors need to set the bug to
[06:58] <poolie> oh i don't know
[06:58] <lifeless> I think 'assignee' is sufficient to indicate in progress
[06:58] <lifeless> confirmed|triaged + assigned
[06:58] <poolie> i see
[06:58] <poolie> this is a different issue
[06:59] <poolie> fwiw i think you can say "some work has been done on this but nobody owns it at the moment"
[06:59] <poolie> however
[06:59] <poolie> the point here is not that people cannot set the state
[06:59] <poolie> just an attempt to reduce erroneous settings
[06:59] <poolie> and a confirmation dialog is a very poor way to accomplish that
[07:00] <lifeless> poolie: arguably though, it won't progress when noone owns it.
[07:00] <lifeless> poolie: yes, I can see the dialog being a poor way issue
[07:00] <poolie> right, i don't think you should leave bugs in this state for long
[07:00] <poolie> but they can be there
[07:00] <poolie> it's like saying you shouldn't be allowed to have open critical unassigned bugs :)
[07:01] <lifeless> true
[07:01] <lifeless> I think it depends on what you take 'in progress' to mean.
[07:01] <lifeless> if you mean 'started but not finished', then I agree that it can be in that state.
[07:01] <wgrant> An alert() which users cannot bypass is a *particularly* poor way to accomplish it.
[07:01] <lifeless> if you mean 'being worked on', then I don't agree.
[07:02] <lifeless> And I think most users take 'in progress' to mean 'progressing' not 'started but not finished'
[07:05] <poolie> i don't think "actually being worked on now" is modelled very well by a single field on the task
[07:05] <poolie> it will be out of date
[07:06] <lifeless> agreed
[07:09] <poolie> wgrant: is it really 'bug supervisor' not, as promised in bug 531963, 'bug contributor'?
[07:09] <mup> Bug #531963: Add a confirmation step when setting the bug status if the user is not a bug contributor <qa-ok> <Launchpad Bugs:Fix Committed by intellectronica> <https://launchpad.net/bugs/531963>
[07:10] <wgrant> poolie: 'bug contributor' doesn't exist, except by karma.
[07:10] <wgrant> poolie: The review I snooped at checked for importance privileges.
[07:10]  * wgrant checks the source.
[07:12] <wgrant> +            'status_requires_confirmation': not self.user_can_edit_importance,
[07:12] <wgrant> poolie: ^^
[07:13] <poolie> ok, thanks
[07:13] <poolie> so there is no escape
[07:14] <lifeless> perhaps it would be better if it was more sophisticated than that
[07:14] <wgrant> Apart from Greasemonkey.
[07:14] <lifeless> \o/
[07:14] <wgrant> lifeless: Indeed.
[07:49] <adeuring> good morning
[07:53] <wgrant> noodles775: Morning.
[07:57] <noodles775> Hi wgrant and adeuring :)
[07:57] <adeuring> hi noodles775!
[07:57] <wgrant> Hi adeuring.
[07:57] <adeuring> hi wgrant!
[07:58] <wgrant> noodles775: Since LP won't have emailed anybody, again, have a https://bugs.edge.launchpad.net/soyuz/+bug/550233. Also https://bugs.edge.launchpad.net/soyuz/+bug/550049, but I've already poked Julian about that.
[07:58]  * noodles775 looks
[08:09] <poolie> wgrant: urk, now i get that dialog about bzr in ubuntu
[08:09] <wgrant> poolie: Ha ha ha.
[08:09] <wgrant> Give them hell.
[08:12]  * wgrant heads trainward.
[09:08]  * thumper is having trouble stopping
[09:10] <StevenK> thumper: Me too
[09:10] <lifeless> thumper: switch to your other project
[09:11] <bigjools> his wife?
[09:11] <bigjools> lifeless: congrats BTW
[09:11] <lifeless> bigjools: thanks :)
[09:12] <bigjools> lifeless: is this a hacking honeymoon? :)
[09:12] <lifeless> bigjools: honeymoon will be later this year
[09:12] <lifeless> waaay to much on right now to do it atm
[09:37] <mrevell> Morning
[09:50] <fayce> Hi all ! I'd like to install Launchpad on a Ubuntu box, but I wonder how hard it would be to make it scalable
[09:54] <lifeless> fayce: launchpad itself - depends on what you mean by scalable
[09:56] <fayce> thank you lifeless, I meant by "scalable" the fact that I can load balance it trough different physical (or virtual) servers without too much work
[09:57] <fayce> I guess that launchpad is designed that way... kind of stateless ?
[09:57] <lifeless> its not stateless
[09:57] <lifeless> but the state lives in a db
[09:57] <wgrant> bigjools: What in IBuildFarmJob says that it is a DB object?
[09:59] <wgrant> (I don't know how it manages to not live in the DB; that is Code magic.)
[10:00] <fayce> ok, thanx. I'm about to get the source code and try to install it.
[10:00] <jml> hello all
[10:00] <wgrant> Morning jml.
[10:08] <bigjools> wgrant: I don't understand your first comment, but the second one is exactly what bothers me
[10:08] <bigjools> I don't want magic
[10:08] <wgrant> bigjools: By calling Store.remove(some IBuildFarmJob), we are violating IBuildFarmJob.
[10:08] <bigjools> how?
[10:09] <wgrant> Nothing in the interface says that it can be removed from a store.
[10:09] <bigjools> it's no different to destroySelf, except I don't want any more of the latter
[10:09] <bigjools> IBuildFarmJob should have a concrete table behind it somewhere
[10:09] <wgrant> IBFJ now defines destroySelf. verifyObject will correctly catch if something is missing it.
[10:09] <bigjools> that's my point
[10:09] <wgrant> It should.
[10:10] <wgrant> And we should really work out a solution to that, true.
[10:10] <bigjools> right - so I prefer that to hacking something in
[10:11] <stub> create an IStorm interface and attach it to storm.base.Storm objects with ZCML.
[10:12] <wgrant> stub: I thought we couldn't do that.
[10:12] <stub> why not?
[10:14] <stub> You could also adapt the object to IMasterObject, which would give you a Storm object or fail.
[10:14] <wgrant> Didn't I see a comment suggesting that the I*Store adapters registered on Interface because you can't tell Zope that a class and all its derivatives implement an interface.
[10:14] <wgrant> ?
[10:15] <stub> maybe. I don't recall.
[10:15] <wgrant> lib/canonical/launchpad/webapp/adapter.py, just before get_store.
[10:16] <stub> Oh... that is classes.
[10:16] <stub> We adapt classes to I*Store, which is the problem. This would be adapting instances which is fine. Just declare Storm implements IStorm and all Storm instances will provide that interface.
[10:17] <wgrant> Oh, right.
[10:17] <wgrant> That makes more sense ow.
[10:17] <stub> But if a class provides an interface, subclasses don't automatically provide it too.
[10:17] <stub> (Which I think is a bug? Not sure, but it isn't going to be fixed any time soon if it is)
[10:21] <bigjools> sounds like a bug to me
[10:21] <bigjools> wgrant: anyway as I said on the bug I'm of a mind to mark it invalid
[10:21] <wgrant> bigjools: Well, when is the data model rework going to happen?
[10:21] <bigjools> wgrant: noodles775 is working on it right now
[10:21] <wgrant> Excellent.
[10:21] <bigjools> we need it for builder history
[10:22] <bigjools> and jtv needs to fix his stuff too :)
[10:22] <wgrant> Yep.
[10:22] <wgrant> But with that and my other Saturday fixes, translations jobs work perfectly.
[10:22] <noodles775> wgrant, bigjools: *was* going to start working on it today, but other things came up ;)
[10:22] <bigjools> :)
[10:22] <bigjools> have you ever been to a blackhat wgrant? :)
[10:23] <wgrant> bigjools: No.
[10:23] <bigjools> anyway, UI should drive all other features, not the other way around.  jml would agree with me.
[10:23] <wgrant> +inf
[10:23] <bigjools> heh
[10:24] <lifeless> bigjools: I would say user experience, not ui
[10:24] <lifeless> I think its closer to the spirit of the issue
[10:24] <bigjools> amounts to the same thing for me, but yeah
[11:00] <deryck> Morning, all.
[11:09] <wgrant> deryck: Hi. Can I please have your blessing for https://code.edge.launchpad.net/~wgrant/launchpad/bug-540819-fix-builder-list-icons/+merge/22288?
[11:09] <deryck> Hi wgrant.  Let me take a look....
[11:12] <deryck> wgrant, can you get the normal reviews from someone else first please?  Then I'll consider it for an RC.  But my initial reaction is I have no qualms about this going in.
[11:13] <deryck> I think we will also have someone from bugs back out the confirmation dialog for status change, until it has been correctly done.
[11:14] <wgrant> deryck: Ah, OK.
[11:14] <wgrant> deryck: +1 from me on backing out the confirmation dialog, clearly...
[12:22] <stub> Has meliae become a new dependency, but not been added to buildout or -dependencies?
[12:27] <stub> Ahh... forgot to rebuild my eggs.
[14:29] <jml> gror backlight
[15:34] <bac> hey salgado are you CHR today?
[15:35] <salgado> I should be but had completely forgotten about it
[15:35] <salgado> thanks for reminding me, bac
[15:35] <bac> salgado: there are some questions in #launchpad
[16:06] <adeuring> am I right that we now need a referer header for each POST request?
[16:06] <leonardr> adeuring: right
[16:07] <adeuring> leonardr: gah... I can't use firefox to edit any LP page...
[16:07] <leonardr> mwhudson, if you're around i have a question about<EMAIL_ADDRESS>[16:07] <adeuring> but the important detail:
[16:07] <adeuring> We don't get any longer new submissions to the HDWB
[16:08] <adeuring> since when do we have this referer check?
[16:10] <leonardr> adeuring: a couple weeks ago. it was a security measure
[16:10] <adeuring> leonardr: sure, I understand that. Is it possible to switch this off for selected forms?
[16:11] <leonardr> adeuring: yes, i'm finding the information for you now
[16:11] <leonardr> adeuring: the bug is https://bugs.edge.launchpad.net/launchpad-foundations/+bug/529348
[16:11] <adeuring> leonardr: thanks!
[16:12] <leonardr> np
[16:33] <adeuring> gary_poster: I just got a head-up from cr3 and jcastro that LP does not accept any longer ay HWDB submission. The reason is simple: The data is posted by checkbox, and the request does not contain a referer header. Can you give me a clue how to best fix this?
[16:34] <adeuring> there is this exemption for "/+storeblob" and a few other URLs, should we extend that?
[16:35] <gary_poster> adeuring: yes, I suppose so, with associated tests, and quite possibly with an associated bug or two against the webservice saying that whatever the HWDB is doing now should be doable with the webservice, at which point we can remove the exceptions.
[16:36] <gary_poster> adeuring: what do you mean "The data is posted by checkbox"?
[16:36] <adeuring> gary_poster: the program that collects the data on a user's machine is called checkbox.
[16:37] <gary_poster> ah, ok
[16:37] <adeuring> and it seems to POST without a referer
[16:37] <gary_poster> I thought it was a form element :-)
[16:37] <adeuring> gary_poster: ;)
[16:39] <gary_poster> adeuring: so...actually, I also suggest that they change their script now to include a REFERER.  That way eventually legacy clients will "just work," and sooner than if they wait to be able to do whatever it is they need to do through the webservice API
[16:40] <adeuring> gary_poster: yes, checkbox should do that. But it is installed by default on every Ubuntu system, and getting rid of old version will ned quite some time...
[16:41] <gary_poster> adeuring: ack, so let's get started ;-)  getting the change into lucid would be a *big* win in that regard
[16:41] <adeuring> right
[18:29] <deryck> sinzui, ping
[18:35] <sinzui> hi deryck
[18:37] <deryck> sinzui, hi.  should Bug #550980 be a registry bug instead of malone?  (I realize anyone can fix it, just curious who normally owns that script.)
[18:37] <mup> Bug #550980: Ordering of Bug importance is wrong <Launchpad Bugs:New> <https://launchpad.net/bugs/550980>
[18:37]  * deryck fixes the title
[18:38] <sinzui> It is a registry bug
[18:38] <sinzui> It is also browser based. webkit shows things very wrong. firefox is kind of right
[18:39] <deryck> ah, ok.  I'll retarget to you guys then.
[18:40] <sinzui> already done
[18:40] <deryck> and there's our friend the NotImplementedError. :-)  You did beat me
[18:41] <gary_poster> jml, james_w: I'd really rather leonardr and I not consider the adapter question until we've dealt with other things on our schedule, and I'd really rather decisions assuming a given solution (which is what I--perhaps mistakenly--understand the current resolution of your mail thread) to be postponed.  I understand that you want changes, but pushing for too much at once will lead to flailing, I'm afraid.
[18:43] <gary_poster> ah, disappointments: the local paneras no longer allows ssh connections apparently :-/
[18:45] <gary_poster> leonardr: my concern expressed about the adapter thread (and the original question about exposing newCodeImport), if you do have any quick wisdom or ideas to share with james_w and jml, please do.
[18:52] <sinzui> deryck: That bug was a duplicate of a foundations bug. I also found the same bug reported in malone. I duped them so that it was clear that there is one universal webkit js problem in launchpad
[18:52] <deryck> sinzui, excellent, thanks!
[19:09] <leonardr> gary, looking
[19:46] <james_w> gary_poster: I don't think I'm rushing ahead, I'm just responding to the only replies I have had on the topic. If you want to defer exposing anything that uses adapters until there is a general solution in place then please tell me and I shall go work on something else.
[19:54] <gary_poster> james_w: fair enough.  My concern is jml encouraging an approach when we don't have an agreement yet, and, as he said, we have (already too many) other things to focus on right now.  I don't know the API you are trying to expose.
[19:54] <gary_poster> If your approach to exposing does not assume a particular general solution, and is something that would really be a big win for you, then I'll not feel comfortable discouraging you.  If it is a minor win, or if it involves changes to launchpadlib itself, then I'll be skeptical that this should be pursued until Leonard and I have bandwidth to discuss it.
[19:55] <james_w> I can expose it anyway you like
[19:55] <james_w> I definitely do not intend to change launchpadlib
[19:56] <james_w> and the fact that I am working on LP rather than continue to wait for the change to bubble to the top of an LP developers stack should indicate that it is important for us
[19:59] <leonardr> james_w, gary: i've responded via email
[19:59] <james_w> thanks leonardr
[20:03] <gary_poster> james_w: "expose any way you like": if it is within the range of the current standard tools to expose APIs, please consider me out of your way.  The code team (and probably Jono, with his experience there) are the ones to guide you.
[20:03] <gary_poster> "do not intend to change launchpadlib": OK sorry, that was a question I had when I read that a change would be on the "client side."  A misunderstanding.
[20:03] <gary_poster> not waiting for LP developers: understood.
[20:03] <gary_poster> I don't want to be a hindrance.  It doesn't sound like I need to be one.  Sorry for the noise.
[20:09] <james_w> gary_poster: thanks, let's continue discussion on the mailing list to decide what the best way to proceed is, at least in the short-term.
[20:10] <gary_poster> james_w: cool.
[20:33] <leonardr> is there an easy way to look up a member of an enum by token?
[20:47] <mwhudson> leonardr: what do you mean by 'token' ?
[20:48] <leonardr> mwhudson: i'm looking at a dbenum value and it has a number of fields: .token, .sort_key, etc
[20:48] <leonardr> that's the token i mean
[20:52] <mwhudson> um
[20:52] <mwhudson> i don't see token on this dbitem
[20:53] <thumper> morning
[20:53] <thumper> leonardr: yes
[20:53] <thumper> leonardr: I think
[20:53] <mwhudson> leonardr: it looks like the class has a getTermByToken method though
[20:55] <leonardr> ok, let me get precise about what i'm seeing
[20:56] <leonardr> <DBEnumeratedType 'OAuthPermission'>
[20:57] <leonardr> it has a .description and an __iter__
[20:57] <leonardr> [x for x in OAuthPermission] is a bunch of lazr.enum._enum.TokenizedITem objects
[20:57] <leonardr> each has a .title, a .token, and a .value
[20:58]  * thumper nods
[20:58] <leonardr> i don't see any lookup methods anywhere. i get the feeling this is on a different level of abstraction from DBItem
[21:00] <thumper> leonardr: the item lookup is abstracted
[21:00] <thumper> leonardr: for no good reason
[21:00] <leonardr> i'm getting the feeling it's not worth figureing this out to save a couple lines of code
[21:01] <thumper> what are you wanting?
[21:01] <leonardr> here's my code
[21:01] <leonardr>         for check_permission in OAuthPermission:
[21:01] <leonardr>             if check_permission.token == permission:
[21:01] <leonardr>                 permission = check_permission.value
[21:01] <leonardr>                 break
[21:01] <thumper> to get the enuerated value from the token name?
[21:01] <leonardr> i'd like to write permission = OAuthPermission.getByToken(permission)
[21:02] <thumper> permission = OAuthPermission.items[permission]
[21:02] <thumper> assuming permission is the string
[21:03] <thumper> >>> i
[21:03] <thumper> <lazr.enum._enum.TokenizedItem object at 0x77526d0>
[21:03] <thumper> >>> i.token
[21:03] <thumper> 'WRITE_PRIVATE'
[21:03] <thumper> >>> t
[21:03] <thumper> <DBEnumeratedType 'OAuthPermission'>
[21:03] <thumper> >>> t.items[i.token]
[21:03] <thumper> <DBItem OAuthPermission.WRITE_PRIVATE, (50) Change Anything>
[21:05] <thumper> leonardr: that work for you?
[21:08] <leonardr> yes, that seems to work
[21:08] <thumper> coolio
[21:14] <leonardr> thanks
[21:44] <lifeless> moin
[22:27]  * mwhudson rebooting
[22:37] <thumper> ✁☹
[22:38] <thumper> that is for whoever decided that preferredemail was better than preferred_email
[22:38] <thumper> and while we're at it
[22:38] <thumper> displayname instead of display_name
[22:38] <mwhudson> thumper: ancient history isn't it?
[22:38] <thumper> probably
[22:38] <mwhudson> for a while _ wasn't allowed in column names in the db
[22:39] <thumper> stupid
[22:40] <thumper> every time I need to access preferredemail I get it wrong
[22:57] <thumper> mwhudson: got a minute to talk through something twisted?
[22:57] <thumper> hmm.. that could be a no
[23:07] <mwhudson> well, that was err, fun